Bug#1034501: ITP: luametatex -- New generation processing Engine for ConTeXt

[Hilmar Preusse]

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

I'm not fully sure about the final name of the source package. The OpenSuSE
people name it texlive-context-bin, maybe I'll use a similar naming.

* Package name: luametatex
  Version : 2.10.07
  Upstream Contact: Hans Hagen 
* URL : https://github.com/contextgarden/luametatex
* License : GPL, MIT/X
  Programming Lang: C, CWeb, C++
  Description : New generation processing Engine for ConTeXt

This is a follow up on the LuaTeX project. The source is considered part
of the ConTeXt distribution and managed by the ConTeXt development team
and the ConTeXt user group. That way we can guarantee that the engine and
this TeX macro package work together as expected. The idea is that users
can easily compile the source themselves and that way have a guaranteed
long term (minimal) TeX based installation. Because the management scripts
are in Lua, only one binary is needed to serve the ConTeXt distribution.

In the source code we try to stay close to the ancestors, LuaTeX, pdfTeX,
eTeX and TeX, but in the meantime due to additions there is quite some
diverge. There are new primitives and submechanisms, there is more control
over the inner workings, font handling is mostly delegated to Lua and there
is no built-in backend. The code base is all-inclusive and has no (nor will
have) dependencies on external libraries.

 - The TeX engine in this package will be (probably) the default processing
   engine of ConTeXt. The upcoming 2023 release of Context will hence depend
   on it.
 - I'm a member of the Debian TeX Task force, I'll maintain the package as
   a member of the team. As I'm not a DD, I'd a sponsor for the initial
   upload.

-- 
sigmentation fault


signature.asc
Description: PGP signature

Bug#1034380: unblock: opm-models/2022.10+ds-4

[Markus Blatt]

Hi Paul,

Am Sun, Apr 16, 2023 at 10:03:07PM +0200 schrieb Paul Gevers:


On 13-04-2023 22:56, Markus Blatt wrote:

None, because no real code is changed


Can you elaborate why this is needed? I confirm I see nothing of interest.



you are right, there are no real changes in here.

The only changes are:
- Bump to 4.6.2 standard
- Limit architectures for running tests. (That was my failed attempt to
  convince britney that the autopkgtests have run)

I am perfectly fine with keeping this blocked and closing the bug.

Best,

Markus


signature.asc
Description: PGP signature

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

[Dmitry Baryshkov]

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

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

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

firmware-qcom-dragonboard845c.install:

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

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

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

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

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

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

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

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

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

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

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

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

renesas_usb_fw.mem lib/firmware

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

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

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

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

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

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

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

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

-- 
With best wishes
Dmitry

Bug#1024523: yad packaging

[grin]

Hello Alexis,

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

Thanks
Peter

Bug#1031909: RC Bug tagged patch since more than one month (Was: python3-tk: bytecode not removed on upgrade)

[Andreas Tille]

Hi Matthias,

thanks to James Addison this RC bug is tagged patch.  It would help if
you could comment on this patch (either in Bug report or MR[1]).

Kind regards
   Andreas.


[1] https://salsa.debian.org/cpython-team/python3-stdlib/-/merge_requests/5

-- 
http://fam-tille.de

Bug#1034506: Request to enable CONFIG_HSR as module

[Yoann Congal]

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

Hi maintainers,

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

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

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

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

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

Thank you for considering this request.

Best regards,

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

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

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

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

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

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

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

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

[Emmanuel Bourg]

Package: diffoscope
Version: 240
Severity: normal

diffoscope recommends procyon-decompiler, but calls the wrong binary.
The procyon-decompiler package installs /usr/bin/procyon, and diffoscope
calls 'procyon-decompiler' instead of 'procyon'.

This issue was reported on StackOverflow:
https://stackoverflow.com/questions/51216673/how-to-use-procyon-decompiler-with-diffoscope

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

[Mattia Rizzolo]

Control: tag -1 moreinfo

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

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

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


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

-- 
regards,
Mattia Rizzolo

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


signature.asc
Description: PGP signature

Bug#1034502: dhclient-script doesn't handle resolv.conf in network namespaces

[Santiago R.R.]

Package: isc-dhcp-client
Version: 4.4.3-P1-1.1
Severity: important
Tags: patch pending

As described in this merged MR [0], dhclient-script fails to handle
the resolv.conf when an dhclient is called inside a network namespace.

[0] https://salsa.debian.org/debian/isc-dhcp/-/merge_requests/8

This is an example from an autopkgetst [1] (to be merged):

ip netns exec client dhclient ptp-veth-client
mv: cannot move '/etc/resolv.conf.dhclient-new.1207' to '/etc/resolv.conf': 
Device or resource busy

[1] https://salsa.debian.org/santiago/isc-dhcp/-/jobs/4139012#L323

Cheers,

 -- Santiago

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

Kernel: Linux 6.1.0-0-amd64 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_UNSIGNED_MODULE, TAINT_LIVEPATCH
Locale: LANG=es_CO.UTF-8, LC_CTYPE=es_CO.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 isc-dhcp-client depends on:
ii  debianutils  5.7-0.4
ii  iproute2 6.1.0-2
ii  libc62.36-8

Versions of packages isc-dhcp-client recommends:
ii  isc-dhcp-common  4.4.3-P1-1.1

Versions of packages isc-dhcp-client suggests:
ii  avahi-autoipd 0.8-9
pn  isc-dhcp-client-ddns  
pn  resolvconf

-- Configuration Files:
/etc/apparmor.d/sbin.dhclient changed [not included]

-- no debconf information


signature.asc
Description: PGP signature

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

[Andreas Tille]

Hi Tiziano and Yaroslav,

I'd volunteer to

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

I'm not interested in just doing b) and hope you will find the time to
care for the package if you are not happy with a).  Please note that
there was an NMU which is not taken over in your repository at Github.

Kind regards
Andreas.

-- 
http://fam-tille.de

Bug#1034503: telegram-desktop: segmentation fault at ../sysdeps/x86_64/dl-machine.h:463

[Brian]

Package: telegram-desktop
Version: 3.1.1+ds-1~deb11u2
Severity: grave
Justification: renders package unusable

Dear Maintainer,

Was using telegram-desktop(3.1.1+ds-1~deb11u2) for a while then it stopped 
working.

When I tried to use it again, it got a segmentation fault.

I then used GDB to figure out if it can tell me what failed.
Looks like it died somewhere at ../sysdeps/x86_64/dl-machine.h:463 due to no 
such file or directory.

```bash
$ gdb telegram-desktop 
GNU gdb (Debian 10.1-1.7) 10.1.90.20210103-git
Copyright (C) 2021 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from telegram-desktop...
(No debugging symbols found in telegram-desktop)
(gdb) r
Starting program: /usr/bin/telegram-desktop 

Program received signal SIGSEGV, Segmentation fault.
0x77fde89b in elf_machine_rela (skip_ifunc=, 
reloc_addr_arg=0x58b4a758, version=, 
sym=0x55564688, reloc=0x558ed4b8, map=0x77ffe180)
at ../sysdeps/x86_64/dl-machine.h:463
463 ../sysdeps/x86_64/dl-machine.h: No such file or directory.
```

-- Package-specific info:

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

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

Versions of packages telegram-desktop depends on:
ii  libavcodec58  7:4.3.5-0+deb11u1
ii  libavformat58 7:4.3.5-0+deb11u1
ii  libavutil56   7:4.3.5-0+deb11u1
ii  libc6 2.31-13+deb11u5
ii  libdbusmenu-qt5-2 0.9.3+16.04.20160218-2+b1
ii  libgcc-s1 10.2.1-6
ii  libglib2.0-0  2.66.8-1
ii  libglibmm-2.4-1v5 2.64.2-2
ii  libhunspell-1.7-0 1.7.0-3
ii  libjpeg62-turbo   1:2.0.6-4
ii  libkf5waylandclient5  4:5.78.0-2
ii  liblz4-1  1.9.3-2
ii  libminizip1   1.1-8+b1
ii  libopenal11:1.19.1-2
ii  libopus0  1.3.1-0.1
ii  libqrcodegencpp1  1.6.0-1
ii  libqt5core5a [qtbase-abi-5-15-2]  5.15.2+dfsg-9
ii  libqt5dbus5   5.15.2+dfsg-9
ii  libqt5gui55.15.2+dfsg-9
ii  libqt5network55.15.2+dfsg-9
ii  libqt5svg55.15.2-3
ii  libqt5waylandclient5 [qtwayland-client-abi-5-15-  5.15.2-3
ii  libqt5widgets55.15.2+dfsg-9
ii  librlottie0-1 0.1+dfsg-2
ii  libsigc++-2.0-0v5 2.10.4-2
ii  libssl1.1 1.1.1n-0+deb11u4
ii  libstdc++610.2.1-6
ii  libswresample37:4.3.5-0+deb11u1
ii  libswscale5   7:4.3.5-0+deb11u1
ii  libx11-6  2:1.7.2-1
ii  libxcb-keysyms1   0.4.0-1+b2
ii  libxcb-record01.14-3
ii  libxcb-screensaver0   1.14-3
ii  libxcb1   1.14-3
ii  libxcomposite11:0.4.5-1
ii  libxdamage1   1:1.1.5-2
ii  libxext6  2:1.3.3-1.1
ii  libxfixes31:5.0.3-2
ii  libxrandr22:1.5.1-1
ii  libxtst6  2:1.2.3-1
ii  libxxhash0 

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

[Dmitry Baryshkov]

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

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


-- 
With best wishes
Dmitry

Bug#1033570: unblock: kdenlive/22.12.3-2

[Patrick Matthäi]

Am 15.04.2023 um 21:51 schrieb Paul Gevers:

Control: tags -1 confirmed

Hi Patrick,

Thanks.

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


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


Paul


Thank you, I have uploaded it :)

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

Bug#1034500: Nheko crashes after a few seconds after launch, bug fixed upstream

[Alain Knaff]

Package: nheko
Version: 0.8.0+really0.7.2-4

Hi,

After a couple of seconds, and after displaying its UI correctly, nheko
crashes with the following messages:

terminate called after throwing an instance of 'std::invalid_argument'
  what():  v1.1: invalid version
Aborted


Apparently, this bug is known upstream since 2022:

https://github.com/Nheko-Reborn/nheko/issues/957

Thanks,

Alain

Bug#1028149: bookworm: ntp has been replaced by ntpsec

[Miroslav Lichvar]

On Sat, Apr 15, 2023 at 04:31:45PM +0100, Richard Lewis wrote:
> Isnt that effectively what debian has done by setting systemd-timesync
> to "standard" priority?
> 
> if that's a bad decision, you should make the case to debian to change
> it i would think?
> (standard = installed by default, per debian policy)

Isn't it too late to fix this in bookworm?

I can provide data showing problems that some pool.ntp.org servers had
in the past, but as the upstream maintainer of chrony I'm probably not
the best person to be proposing changes in the priority of NTP
packages in Debian.

Another option would be to change the default servers of timesyncd,
e.g. to time.cloudflare.com, which is very reliable and has a great
coverage around the world from what I have seen so far. I suspect
people would not find it acceptable to rely on a commercial providers.

> if no-one else does,  i can draft some text that says
> - ntp is dropped (do we know why?).

I think the main reason is very slow upstream development with a large
number of known unfixed security issues.

> ntpsec is a direct replacement,
> but there is also chrony

openntpd is another NTP client that I think should be recommended.
(Not as a server though.)

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

[Isaac True]

> Why would you have to run flash-kernel again?

When it's being initially installed it won't have the additional command line 
flag that forces it to ignore the EFI check, so it won't run and you would have 
to run it manually afterwards with the flag. I agree that an env 
variable/config file would be better here.

> The name FK_FORCE_EFI=yes seems a bit backwards; it is ignoring 
the presence of EFI, not forcing it to behave like EFI. FK_FORCE_NO_EFI? 
FK_IGNORE_EFI? Names are hard.

My intention behind the name was something like "force *despite* EFI", but I 
think FK_IGNORE_EFI does indeed fit a lot better.  

> I overall like this approach, although the main drawback is having to write 
> to /etc/default/flash-kernel 

I agree with this - it's a bit more awkward having to create and write a file, 
but I like that it opens the door to allow both methods to work. The user can 
either set the env variable, or it can be set in the file itself. I'm not sure 
if it makes sense to add the "! ischroot" check like in that merge request 
though, as I feel like that's a different topic. What do you think?

Cheers,
Isaac

Bug#1034462: Pipewire: Inappropriate ioctl for device

[Dylan Aïssi]

Hello,

Le dim. 16 avr. 2023 à 01:42, Al Ma  a écrit :
>
> $ sudo aptitude show pipewire| grep Version
>
> Version: 0.3.56-1

This version is not available in Bullseye, can you upgrade to the latest version
available in bullseye-backports (i.e. 0.3.65-2~bpo11+1)?

> $ sudo aptitude show pipewire-media-session | grep Version
>
> Version: 0.4.1-3

pipewire-media-session is dead upstream, instead it would be better to switch to
wireplumber. 0.4.13-1~bpo11+1 is available in bullseye-backports.

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

[Theppitak Karoonboonyanan]

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

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

Bug#1033424: Please upload to delayed (Was: image-factory: FTBFS in testing: AssertionError: pylint found issues)

[Andreas Tille]

Hi Josef,

thanks for finding a patch for this problem.  I'd recommend to upload to
DELAYED (may be with 3 or up to 7 days).  We are in deep freeze and having
RC bugs closed helps everybody.

Kind regards
   Andreas.

-- 
http://fam-tille.de

Bug#1034505: unblock (pre-approval): libsdl2/2.26.5+dfsg-1

[Simon McVittie]

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

I've prepared a libsdl2 update for upstream stable release 2.26.5 and
I'd like to include it in bookworm if possible.

The most serious bug fixed here is a crash for fcitx users if libdbus
cannot be initialized (src/core/linux/SDL_fcitx.c, 1-line change). If
this upstream stable update is considered too large, I'll cherry-pick
that change and anything else the release team is willing to accept into
a 2.26.4-2 instead; but I'd prefer to take the whole release if we can.

[ Reason ]
New upstream stable release with various bug fixes

[ Impact ]
If not accepted, bookworm users will continue to suffer from various
fixable bugs, and taking further fixes from upstream's 2.26.x branch
will become more difficult.

[ Tests ]
Manually tested with some SDL games (openarena, 0ad, opentyrian,
nexuiz). There are autopkgtests and they pass, but they're marked
superficial because most of SDL is not really practical to test
automatically.

Corresponding changes are also included in libsdl2/experimental already.

A backported version of this package is likely to be included in the
next round of updates to Valve's Steam Runtime, providing wider end-user
testing.

[ Risks ]
I would say that the most likely regression from this update would be
an incorrect change to a game controller button/axis mapping, which is
easily fixed and can also be overridden with an environment variable.

The change in src/audio/SDL_audiocvt.c is probably not something I
would have included in a stable-branch if I was the upstream release
manager, but I'm not, and it does have new automated test coverage
(in test/testautomation_audio.c) so it seems safe enough.

All changes in src/joystick/iphoneos, src/video/cocoa, src/video/windows
are in code that Debian doesn't compile, so there's no risk for us
there. I filtered those out from the diff contents (they're still in
the diffstat).

Similarly, the changes in SDL_gamecontrollerdb.h from "GPD XD Plus"
down to end-of-file are #ifdef __ANDROID__ and so can be disregarded
in Debian (for simplicity I didn't filter these out from the diff), and
src/joystick/sort_controllers.py is used by upstream maintainers to help
to maintain that file but I don't think we run it during the Debian build.

[ Checklist ]
  [x] all changes are documented in the d/changelog
  [x] I reviewed all changes and I approve them
  [x] attach debdiff against the package in testing
  (lightly filtered to exclude files irrelevant to Debian, and the
  diff for a patch that is no longer applied)

[ Other info ]
If there are changes here that the release team would prefer not to see
in stable-branch updates, please let me know, and I can give feedback
to upstream. The stable-branches mainly exist for distros' benefit,
so if we're unable to accept them, that defeats their purpose.

unblock libsdl2/2.26.5+dfsg-1
debdiff *.dsc | filterdiff -p1 \
 -x'debian/patches/*.patch' \
 -x'src/joystick/iphoneos/*' \
 -x'src/main/windows/*' \
 -x'src/video/cocoa/*' \
 -x'src/video/windows/*' \
 -xMakefile.os2 \
 -xMakefile.w32

diffstat for libsdl2-2.26.4+dfsg libsdl2-2.26.5+dfsg

 CMakeLists.txt  |4 
 Makefile.os2|2 
 Makefile.w32|2 
 SDL2.spec   |2 
 VERSION.txt |2 
 configure   |2 
 configure.ac|2 
 debian/changelog|   42 
 debian/gbp.conf |2 
 debian/patches/Fixed-handling-simple-mode-PS4-reports.patch |   83 
 debian/patches/series   |1 
 include/SDL_assert.h|   12 -
 include/SDL_revision.h  |4 
 include/SDL_version.h   |2 
 src/audio/SDL_audiocvt.c|   56 +++--
 src/core/linux/SDL_fcitx.c  |3 
 src/events/SDL_events.c |2 
 src/joystick/SDL_gamecontrollerdb.h |   59 +++---
 src/joystick/hidapi/SDL_hidapi_ps4.c|   14 +
 src/joystick/hidapi/SDL_hidapi_ps5.c|   24 ++
 src/joystick/hidapi/SDL_hidapi_steam.c  |8 
 src/joystick/iphoneos/SDL_mfijoystick.m |   30 ---
 src/joystick/sort_controllers.py|   44 +++-
 src/main/windows/version.rc |8 
 src/render/SDL_render.c  

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

[Chris Lamb]

forwarded 1034504 
https://salsa.debian.org/reproducible-builds/diffoscope/-/issues/338
thanks

I've forwarded this 'upstream' here:

  https://salsa.debian.org/reproducible-builds/diffoscope/-/issues/338


Regards,

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

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

[Danial Behzadi]

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

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

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

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

[Andreas Beckmann]

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

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

Andreas

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

[Helmut Grohne]

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

[ Reason ]

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

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

[ Impact ]

Ideally, a user wouldn't notice anything changed.

[ Tests ]

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

[ Risks ]

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

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

[ Changes ]

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

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

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

[Lukas Märdian]

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

Hello Jan,

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

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

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


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

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


Thanks for considering the patch.

-- Lukas


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


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

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

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

[Pascal Hambourg]

Control: tags -1 patch

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


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


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


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

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

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

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

[Merlin Cooper]

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

Dear Maintainer,

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

Here is the log:

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

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


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

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

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

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

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

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

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


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

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

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

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

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

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

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


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

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

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

Bug#1034508: unblock: sdop/0.90-2

[Bastian Germann]

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

Please unblock package sdop.

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

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

[ Tests ]
Building the package twice in a row.

[ Risks ]
None.

[ Checklist ]
  [x] all changes are documented in the d/changelog
  [x] I reviewed all changes and I approve them
  [x] attach debdiff against the package in testing

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

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

[richardn]

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

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

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

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

Brackets with quotes are needed e.g.

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

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

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

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


-- Package-specific info:

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

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

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

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

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

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

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

Bug#1033755: heimdal: CVE-2022-3116

[Salvatore Bonaccorso]

Hi Brian,

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

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

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

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

Regards,
Salvatore

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

[Thomas Schwinge]

Hi!

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


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


Grüße
 Thomas

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

[Cyril Brulebois]

Hi,

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

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

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

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

… before considering a real/better fix after bookworm.

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

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


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


signature.asc
Description: PGP signature

Bug#1024523: yad packaging

[grin]

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

Peter

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

[Antoine Beaupré]

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

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

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

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

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

[Christian Marillat]

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

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

Patch is here :

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

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

Christian

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

[Thomas Goirand]

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

Please unblock package openvswitch

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

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

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

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

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

[ Checklist ]
  [x] all changes are documented in the d/changelog
  [x] I reviewed all changes and I approve them
  [x] attach debdiff against the package in testing

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

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

[Simon Deziel]

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


> systemctl show --property MainPID --value unbound

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

HTH,
Simon

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

[Raphael Hertzog]

Hello Holger,

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

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

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

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

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


signature.asc
Description: PGP signature

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

[Ryan Govostes]

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

Dear Maintainer,

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

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

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

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

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

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

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

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

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

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

[Helge Kreutzmann]

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

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

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

Greetings

  Helge


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

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

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

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

sgt-puzzles suggests no packages.

-- no debconf information

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


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


signature.asc
Description: PGP signature

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

[Andreas Beckmann]

Control: tag -1 moreinfo

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

Package: nvidia-driver
Version: 525.89.02-1


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


Thanks

Andreas

Bug#1034521: clasp: FTBFS with LTO enabled

[Lukas Märdian]

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

Dear Maintainer,

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

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

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

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


Thanks for considering the patch.

-- Lukas


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

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

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

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

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


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

End testing: Apr 12 14:19 UTC

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

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


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

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

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

[Dan Jacobson]

Perhaps most are also applicable to the current lynx package.

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

[Jakub Wilk]

Package: python3-fastimport
Version: 0.9.14-2.1

Please mention "git" somewhere in the package description.

--
Jakub Wilk

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

[Bernhard Reiter]

Hi Lisandro,

thanks for your response!

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

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

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

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

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

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

Thanks again,
Bernhard


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

Bug#984623: pychess: Fails to switch off sound

[Sebastian Pipping]

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

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

[Lukas Märdian]

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

Hello Jan,

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


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

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


Thanks for considering the patch.

-- Lukas


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

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

Bug#1034520: python3-cairo: unhelpful upstream changelog

[Jakub Wilk]

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

This is unhelpful:

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

   .. currentmodule:: cairo

   .. include:: ../NEWS


--
Jakub Wilk

Bug#1034523: pychess: Please update PyChess to 1.0.4

[Sebastian Pipping]

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


Hi!

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

Thanks and best, Sebastian

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

[Peymaneh]

Hi

Am 16.04.23 um 17:37 schrieb Nilesh Patra:

Can you take care of this?


thanks for the mail Nilesh, I missed the bugreport.

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


OpenPGP_signature
Description: OpenPGP digital signature

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

[Michael Below]

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

Dear Maintainer,

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

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

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

Any ideas what to try next?

Thanks for your work!

Cheers
Michael

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

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

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

darktable recommends no packages.

darktable suggests no packages.

-- no debconf information

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

[Drew Parsons]

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

Bug#1023820 reported a failure in h5py:


import h5py

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


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


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


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

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

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


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

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

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

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

[Thomas Goirand]

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

Please unblock package openstack-pkg-tools

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

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

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

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

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

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

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

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

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

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

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

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

[ Checklist ]
  [x] all changes are documented in the d/changelog
  [x] I reviewed all changes and I approve them
  [x] attach debdiff against the package in testing

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

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

Bug#987999: pychess: Puzzles don't open

[Sebastian Pipping]

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

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

[Nilesh Patra]

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

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

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

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

-- 
Best,
Nilesh


signature.asc
Description: PGP signature

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

[David Bremner]

Michael Below  writes:

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

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

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

d

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

[Johannes Schauer Marin Rodrigues]

Hi,

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

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

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

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

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

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

Thanks!

cheers, josch

signature.asc
Description: signature

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

[Joao Eriberto Mota Filho]

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

This bug was taken from dcfldd project[1].

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

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

Prepare:

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

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

Default option (without diffwr) isn't affected.

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

Eriberto

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

[Pascal Hambourg]

Package: debian-installer
Severity: minor

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

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

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

 prohibited by secure boot policy
 no video mode activated

and displays the menu in text mode.

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

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

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


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

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


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


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

Bug#1034525: pymongo: uses invalid architecture wildcards

[Graham Inggs]

Source: pymongo
Version: 3.11.0-1
Severity: important

Hi Maintainer

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

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

Regards
Graham


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

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

[Bernd Zeimetz]

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


Hi!

I intend to orphan the gpsd package.

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

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

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



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



Thanks,

Bernd

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

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

[Bernd Zeimetz]

Hi,


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

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


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

Then -n would be a workaround...

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

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


Bernd



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

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

[Michael Below]

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

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

Michael

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

[Graham Inggs]

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

Hi Maintainer

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

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

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

Regards
Graham


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

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

[Patrice Duroux]

Package: mtrg
Version: 2.17.10-4
Severity: normal

Dear Maintainer,

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

Regards,
Patrice


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

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

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

[andrew bezella]

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

Dear Maintainer,

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

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

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

thanks in advance.

andy

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

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

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

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

gnome-terminal suggests no packages.

-- no debconf information

Bug#1034446: unblock: linux/6.1.24-1

[Salvatore Bonaccorso]

Hi Paul,

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

Yes confirmed.

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

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

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

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

Regards,
Salvatore

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

[Michael Below]

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

Cheers
Michael

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

[Petter Reinholdtsen]

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

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

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

-- 
Happy hacking
Petter Reinholdtsen

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

[Petter Reinholdtsen]

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

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

-- 
Happy hacking
Petter Reinholdtsen

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

[Matthijs van Duin]

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

Dear Maintainer,

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

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

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

This worked correctly in debian bullseye (vim 8.2).


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

syn region perlSubDeclaration ...

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

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

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


The issue can alternatively be fixed by reverting the

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

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



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

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

vim-runtime depends on no packages.

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

vim-runtime suggests no packages.

-- no debconf information

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

[Bastian Germann]

Source: pyethash
Severity: wishlist

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

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

[Joao Eriberto Mota Filho]

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

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

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

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

 Some features:

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

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

[Vincent Blut]

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

Hi Ryan,

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

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

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

Cheers,
Vincent

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


signature.asc
Description: PGP signature

Bug#1034533: unblock: connman/1.41-3

[Bastian Germann]

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

Please unblock package connman.

[ Reason ]
Open CVE-2023-28488 in bookworm

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

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

[ Risks ]
None.

[ Checklist ]
  [x] all changes are documented in the d/changelog
  [x] I reviewed all changes and I approve them
  [x] attach debdiff against the package in testing

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

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

[Michael Below]

Hi,

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

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

I am attaching the XMP file.

Cheers
Michael



DSCF8970.RAF.xmp
Description: XML document

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

[Peymaneh]

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

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

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

[Gregor Riepl]

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

Dear Maintainer,

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

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

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

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

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

Thank you for your consideration.


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

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

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

azure-cli recommends no packages.

azure-cli suggests no packages.

-- no debconf information

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

[Petter Reinholdtsen]

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

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

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

-- 
Happy hacking
Petter Reinholdtsen

Bug#1034527: unblock: nageru/2.2.1-1

[Steinar H. Gunderson]

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

Please unblock package nageru

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

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

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

[ Checklist ]
  [x] all changes are documented in the d/changelog
  [x] I reviewed all changes and I approve them
  [x] attach debdiff against the package in testing

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

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

[Ben Westover]

Hello,

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


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


Thanks,
--
Ben Westover


OpenPGP_signature
Description: OpenPGP digital signature

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

[Roger Shimizu]

Dear Dmitry,

Thanks for your response!
Very informative.

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

Let me reply to you inline below.

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

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

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

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

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

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

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

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

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

Yes, we need to integrate this into the installer.

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

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

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

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

[J]

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

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

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

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

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

[Jamie Bainbridge]

Package: kmod
Version: 28-1
Severity: important

Hello,

I have a laptop with iwlwifi wireless card:

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

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

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

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

Adding this file to Debian resolves the problem.

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

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

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

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

Thank you,
Jamie

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

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

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

kmod recommends no packages.

kmod suggests no packages.

-- no debconf information

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

[Timothy Pearson]

Package: gox
Version: 0.3.0-8+b5

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

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

[Bastian Blank]

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

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

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

Bastian

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

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

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

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

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

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

-- no debconf information

Bug#1034540: rhvoice: out of date language list

[Jakub Wilk]

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

The package description reads:

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


There are many other supported languages these days.

--
Jakub Wilk

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

[Vincent Blut]

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

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Control: affects -1 chrony

Hi,

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

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

Cheers,
Vincent

-BEGIN PGP SIGNATURE-

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

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

[Aurelien Jarno]

Hi,

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

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

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

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

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

Yes, definitely.

Cheers
Aurelien

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


signature.asc
Description: PGP signature

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

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

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

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

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

The source builds the following binary packages:

  torctl - Redirect all traffic through tor network

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

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

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

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

Changes for the initial release:

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

Regards,

Bug#1034545: crashed while exporting a PDF

[Marco d'Itri]

Package: qvge
Version: 0.6.3-2
Severity: normal

I think that the destination directory was not writeable.

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

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

[Hilmar Preusse]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

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

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

The source builds the following binary packages:

  luametatex - Next generation ConTeXt processing engine

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

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

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

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

Changes for the initial release:

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

Regards,
-- 
  Hilmar Preusse


signature.asc
Description: PGP signature

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

[Aurelien Jarno]

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

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

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

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

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

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

[ Changes ]
Let me comment the changelog:

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

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

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

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

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

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

 - Fix a segfault in printf handling thousands separator.

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

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

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

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

[A. F. Cano]

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

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

Complete output of dmesg after booting 6.1.20-2 follows:

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

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

[Vagrant Cascadian]

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

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

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

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

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


live well,
  vagrant


signature.asc
Description: PGP signature

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

[Yaroslav Halchenko]

Hi Andreas,

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

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

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

Cheers,

On Mon, 17 Apr 2023, Andreas Tille wrote:

> Hi Tiziano and Yaroslav,

> I'd volunteer to

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

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



signature.asc
Description: PGP signature

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

[Dmitry Baryshkov]

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

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


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

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

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

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

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

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

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

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

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

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

[Holger Wansing]

Package: xfce4
Version: 4.18
Severity: normal

Dear Maintainer,

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

Logging into the XFCE user session works fine too.

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

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

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


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


Holger



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

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

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

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

Versions of packages xfce4 suggests:
pn  xfce4-goodies


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

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

[Holger Wansing]

Package: xfce4
Version: 4.18
Severity: normal

Dear Maintainer,

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

Logging into the XFCE user session works fine too.

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

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

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


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


Holger



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

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

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

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

Versions of packages xfce4 suggests:
pn  xfce4-goodies


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

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

[Steve Langasek]

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

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

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

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