Bug#1038625: firmware-realtek: Add configuration for stable connection (rtw88)

[Leandro Cunha]

Hi Ben,

On Tue, Jun 20, 2023 at 3:11 PM Ben Hutchings  wrote:
>
> Control: reassign -1 src:linux 6.1.27-1
> Control: retitle -1 rtw88_pci: RX DMA errors despite rx_no_aspm workaround
> Control: tag -1 upstream patch moreinfo
>
> On Mon, 2023-06-19 at 03:20 -0300, Leandro Cunha wrote:
> > Package: firmware-realtek
> > Version: 20230404-1
> > Severity: important
> >
> > This firmware contains the rtw88 module
>
> It doesn't - firmware and drivers are two different things.

In the upstream repository it mentions it as a module
https://github.com/lwfinger/rtw88.

Here explains about it:
https://www.debian.org/doc/manuals/debian-kernel-handbook/ch-modules.html

> > and needs some settings to
> > have a stable connection, like disabling the ASPM (Active State Power
> > Management)
> [...]
>
> OK, but if this is a general problem it should be fixed in the driver
> and not by adding a configuration file.
>
> This *was* supposed to have been fixed by
> 
> but apparently not.

Yes, I saw it. It really seems like a regression to me.

> Could you please test whether the attached patch fixes this (without
> also using disable_aspm=1)?  Instructions for rebuilding the kernel are
> at
> .

I'm going to test yes, but during the week I'm busy. Until now at 2:40
am I was still doing some things.
I'll have time over the weekend.

Thank you very much for your support!

-- 
Cheers,
Leandro Cunha
-BEGIN PGP PUBLIC KEY BLOCK-

mQINBF/gQ8gBEADHVKgoWsUWNGVvR6sMhBPUdBUEH+QALpr1QYXhetBfRwaY0HWN
pKgejHdxKO8H+kIhRMoh89CCKg3hAJ9LmOOTXkX7U5/Cya/zRMKk5zBD3rKIaugh
0XYT15Nz1jwL7TIDG25yPSloDtVgVXTep0ZzKsNYJjb4OAqa88cvUEJEhhqrldlR
gpNbkixEh5ituO8pMShEBWqLs3yt4Hr1VFWnTIm4dl/JLBHpexzubDOw/mKCTpNd
A1JGHTvce1wtJ2fMzCVzhEjd5pyjLZV/o8hVw2/ON/yXvpJuz0lV/hiW0M+cDcas
sKftErtsZpRy3wwXdkBcJt6soYuqfCHwgMfL2iC6mPviE8xWAHMOmhdC3wDskZpb
RcLfH5IMYajJAGRO/GCMcKKbq7WkEOeloivtg64xBlYuJf9aOcHKP/8R3EObiNp7
ubQAJtV3pEGD4mx1mhutFxDHB+CfnxE3dWvxZSV9y1n4UOzkDJ3kDx5Ee0MbRvJD
w6aXKc6dhYREgh7hLDcMFz+3LcBiZDLxI3g+SHe3Bl61vdsnPno+0HhCzvB+fL4S
eoy7Myfiunz9BrB2HPN+wNCT0YgV+Kv8QoDGzBwos5H1vUJSY4t59w6xoXAYUsAm
hjAM8s+rUtG40mcUWePd8kZtgE9IV1eQ+Qt8/SNpSdRnUunmIGl3JjHvEwARAQAB
tClMZWFuZHJvIEN1bmhhIDxsZWFuZHJvY3VuaGEwMTZAZ21haWwuY29tPokCTgQT
AQoAOBYhBLT5oBCvKN3HzFEPK8LZ4zKUW9A8BQJf4EPIAhsDBQsJCAcCBhUKCQgL
AgQWAgMBAh4BAheAAAoJEMLZ4zKUW9A8FjAQAKWYqiLpLUD+DLB+NSy3DI3rf9z3
k0vE7TLaEjdEM5CQWN+j4vBqMnAckdcARvSWPndTjp8K+mtFF4PyfhNbS64z/a7L
F3DdhmX73n7LKFG8Ow9NZwcrkmPwH5WcP7mXTh6R+6/+OSL/K85NB8MLlxQTJOni
julVax9JEZjwBaP2HLCu53Zq9gZcvJlXoAoTHyTxKdp8Mh8V+Qit26E78o9c6SQD
Dq9eyMRG8hYCRfreDjKceRkYHjECySlk+VoI1ssVs07Dqvxg6qSyP4RnW+1+W74C
s0yIyuC/eRJpMAf1PBQEOOrVcTfRfpN+go955t21yIAvT58vqotTM5eaqXYIQn/y
sC4lThZai/ZBZHxl5Mbv42WkkYdjisLQOCALIMBpj5nq4oh2C+kvMupcuBKfERgV
dguU51MzfQktKb6d5y777zYnDaFMQDD2IfiD/C7ln5A9LP/L54ixlA3uRmWx/yAx
/m+Zusws98j4Eq/jw5T54XW655m6lMCTE9WXLJkgxrRcEonHSllbgRSsToEmWq0Z
doxcnpagHdcGQzW+cu2VOGi1da73ZFmrn+ptJgc8cW2suO06IeArOi0TzIg7e65j
Xp2DbJCpFrfzEuBb1u71WvB8V2MkAfJZx/uZJPCA936B4HT8YGPEMzlQRIHI2Y9C
+DloyzlBLTS1EMKuuQINBF/gQ8gBEAC47o9u1Wm9jZ6RC+lfxEDEvVS7MmI5VzSy
q04rFttWwbKix13pc65aDlk47LxWrb84N3Gnf1E/OTsLTXqC7u5JZ7YJkC6CsPbo
D1sQkfCiJCFCTgf7dydEVt8ujS/Uu1kz86ufdRwaMRcvBZAORGdB58LEsLB65WN4
hLRYF7xvcxu6t7FGrIYereaxUAWLA2B/ZnCEdOY94w7s0uaPjHdf4lfHebuZ7T08
iG5ACDvKBjgaFArGfdNYWchXJgbOEg14bGj40/8LuBKQMZASiFSqLPZxoporK9FY
xBw+D080dUWWD5g868TZ3pkM3DXO9bdq22IBKqKOep8CnuKgoDpUvA8dTEY/UDCn
sdOlBUK/Y9zTGVmD/90cO/xkvkV78suqiBnwBSddPzVS0EuiWwrLGu8gaY4EyM/X
7khlbTcMgh4njzUCAE6Tq+TbXSxn86wuOybVY5Y+I99LNdsocI5SIn2nDh2IOi00
4dE/iwO2MatWIOLFBC7pw8Xv4UHZY+WIf3Y/6XjExpllhUkeB6BwZpTr1SXk+cug
q5Dj5i4aGn2LrvQJ57terqUWYyDUBFgXTc4SPOzT5og8CavBgHfrQoFwSnRZ2oyX
xtZhEDI5Pk2j1qTbOhXZ29po4rPNWHMq2HQgM0I+BqQndsoVdkPOFzS2wKkdXjCz
bNYcyanusQARAQABiQI2BBgBCgAgFiEEtPmgEK8o3cfMUQ8rwtnjMpRb0DwFAl/g
Q8gCGwwACgkQwtnjMpRb0Dzh6g//ZjXaWSzKmG5ZS6XJa/ZOokkE2hFOFusWX8Qa
hEwLAnTFEy02dLfV54rKwmu2jHPDKLhE+iYtusvytueZAzVRyQahv0RE4BH8Emqw
gQdBwyJ/L+QhUp/lMdJ6Hh/2ZSZmzU29U24vnY+U+haoB1fLnA3lXgOP59kMLGud
lERR2Vluuc7TcpzvcaRWgrQRU2vSrrBBEp6y07iVKbRM/9yhE/aHJahLbhKh2Dk9
WJvHPnhYJY5yU+Y5vTl3BiW5+EuzMBdPUawOWKhqCq9dswn0GL1g/vlt/bdU/6DO
jECQ6fssTAtDjRClXySsS3X0mh8y8qlGvMPB4anfvOy4+4nUV6IESdJftKn2SMGd
CA3MaQ+S7frWn5v7GIWSC9vumCsiu1JTOugLmbVmu5m5nFsyllavm/k9LtOtswuF
fHM/SlXLFuGBWU6XceqaM2dpP8i5jGz0vIGMhqoFNgXWGO1NhwR1rmeU1CMpnM5e
Wue4h/+mJiuEzuZcmzOcwq3HGMUXO0jZDgLEmlnenO9czhrLuGZaMXGdwnIk0G3O
+SqH36v7blnDh96RXpgaa+ifTHd0qKeoVXVwSq/9jNtHSQrI+NJcTpMhu73xtxhX
UFPr/31+IFLWepC5GDwdu/gQm5E6ntGyxE2p2v76pcjz7SGdXjPFZjqekBveEJuW
fNdY6Ns=
=rdCA
-END PGP PUBLIC KEY BLOCK-

Bug#1038450: patch probably available

[julien . puydt]

Le mercredi 21 juin 2023 à 22:56 +0200, Adrien Nader a écrit :
> On Wed, Jun 21, 2023, julien.pu...@gmail.com wrote:
> > Le mardi 20 juin 2023 à 22:38 +0200, Adrien Nader a écrit :
> > > 
> > > 
> > > The patch seems to fix the issue. I say "seem" because the build
> > > compiled the file that was failing to build but the build is not
> > > done
> > > yet: emulated armhf isn't fast. :) 
> > > 
> > > But since I reprocued the build failure before, I am fairly
> > > confident
> > > this build will succeed.
> > 
> > I took the commit and added it to the Debian packaging ; I now have
> > a
> > 20230420-4 almost ready for upload.
> > 
> > I'm waiting for two feedbacks before I do so :
> > 
> > 1. yours so I trust it fixes the 32-bit issue ;
> > 
> > 2. the sbuild I started on my box to check the patch on more usual
> > architectures.
> > 
> > Thanks for your help!
> 
> My build just finished. It only took 27 hours. It failed at the
> lintian step but that was due to network issues.

Uploaded, thanks again!

J

Bug#1038754: random hangs during boot inside qemu

[Johannes Schauer Marin Rodrigues]

Control: found -1 6.1.27-1

Quoting Ben Hutchings (2023-06-22 06:16:24)
> Which version are you using - is it 6.3.7-1 from unstable?

I added a uname call to the jenkins job:

https://jenkins.debian.net/job/mmdebstrap-jenkins-worker/316/consoleText

Linux osuosl3-amd64 6.1.0-9-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.27-1 
(2023-05-08) x86_64 GNU/Linux

The problems started happening once Holger updated jenkins to run bookworm. So
if this is indeed a kernel problem (as opposed to a qemu problem), then it's a
stable kernel problem.

> > Is there a chance to see a stable update with
> > e9523a0d81899361214d118ad60ef76f0e92f71d applied?
> 
> That's the *breaking* change, not the fix.

See, this is why I write to you instead of starting to randomly patch things
myself. :)

> The fix would seem to be
> 
> but that hasn't even reached mainline yet.

Thank you for looking into this!

cheers, josch

signature.asc
Description: signature

Bug#1038860: trafficserver: Wrong version for trafficserver security-update in DSA-5435-1

[Salvatore Bonaccorso]

Source: trafficserver
Version: 9.2.0+ds-1~deb12u1
Severity: serious
Justification: wrong version number, does not allow updates to fixed version
X-Debbugs-Cc: car...@debian.org,t...@security.debian.org
Control: affects -1 + security.debian.org,release.debian.org

Hi

The update for trafficserver in DSA-5435-1 for bookworm, while
sourcewise built on top of 9.2.0+ds-2, has an odd version going
backwards, 9.2.0+ds-1~deb12u1.

This should bee 9.2.0+ds-2+deb12u1 instead (as the patches are applied
on top of 9.2.0+ds-2).

Currently it's not possible to install the security update as

$ dpkg --compare-versions 9.2.0+ds-1~deb12u1 gt 9.2.0+ds-2
$ echo $?
1

Regards,
Salvatore

Bug#1038859: nss: Please package version 3.90

[Carsten Schoenert]

Source: nss
Version: 2:3.87.1-1
Severity: wishlist

Hello Mike,

I'm trying to get a first set of packages build for Thunderbird 115.0
beta.
This version requires NSS3 at version 3.90+.

Coudl you please package and upload the current most recent version of
NSS3? Thanks.

Regards
Carsten

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

Kernel: Linux 6.1.0-9-amd64 (SMP w/4 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

Bug#1034387: update youtube-dl control file to reflect? transitional package

[Andreas Tille]

Am Wed, Jun 21, 2023 at 06:13:27PM -0400 schrieb Andres Salomon:
> 
> Andreas, were you planning to do an upload? Because I was about to open a
> bug against ftp.debian.org to request removal of the package now that
> bookworm is released. I can wait if you want, but I don't see much point in
> keeping youtube-dl in sid.
> 
> I'm happy to request this change for a bookworm point release (via
> bookworm-proposed-updates), though, and do the upload. Seems like a pretty
> simple change, I can't imagine release managers opposing it.

I did not upload due to freeze policy.  Feel free to upload if you
consider a bookworm-proposed-updates sensible or just ask for removal. 
I have no preference over both options.

Kind regards
   Andreas.

-- 
http://fam-tille.de

Bug#1038158: Uses /etc/nullmailer/../mailname instead of /etc/mailname; misleading message

[David Bremner]

Andras Korn  writes:

>
> I'm running nullmailer-send via runit. stdout is definitely a pipe (and so is 
> stderr); somewhere it opens /dev/console explicitly.
>

If so, it does so in a somewhat non-obvious way, since the only mention
of /dev/console in the source is in README.Debian. As far as I can tell,
ferr is a buffer object opened on file descriptor 2.

>
>> > 2. if /etc/nullmailer/me doesn't exist, default to "/etc/mailname",
>> > not "/etc/nullmailer/../mailname".
>> 
>> Offhand I don't understand why it doesn't use an absolute path there. Maybe 
>> someone (tm) can change the appropriate line in hostname.cc and test the 
>> result.
>
> Well, that at least is easy. In 
> debian/patches/0005-Provide-for-etc-mailname.patch, you have:

I know where the code is changed, but I'm hoping for more understanding
/ analysis of why it is the way it is, since it long predates my taking
over maintenence.

Bug#1038754: random hangs during boot inside qemu

[Ben Hutchings]

Control: tag -1 upstream

On Tue, 2023-06-20 at 23:36 +0200, Johannes Schauer Marin Rodrigues
wrote:
> Source: linux
> Severity: normal
> Tags: patch
> 

Which version are you using - is it 6.3.7-1 from unstable?

> Hi,
> 
> the jenkins job of my package mmdebstrap spawns ~260 qemu virtual
> machines on amd64 to run the test cases in. For about a week now I'm
> seeing random (about every ~300) hangs during boot. The effect can be
> seen in these logs:
> 
>  - https://jenkins.debian.net/job/mmdebstrap-jenkins-worker/311/consoleText
>  - https://jenkins.debian.net/job/mmdebstrap-jenkins-worker/313/consoleText
>  - https://jenkins.debian.net/job/mmdebstrap-jenkins-worker/314/consoleText
> 
> Ctrl+F the logs for "qemu-system-x86_64: terminating on signal 15 from
> pid XXX (timeout)".
> 
> On #debian-devel, f_g suggested that this is a fixed problem:
> 
> https://lore.kernel.org/stable/c4724b40-89f6-5aa7-720d-c4a4af57c...@amazon.com/#r
> https://lore.kernel.org/all/5a56290d-806e-b9a5-f37c-f21958b5a...@grsecurity.net
> https://lore.kernel.org/stable/20230615091830.rxmv2...@linutronix.de/
> 
> Is there a chance to see a stable update with
> e9523a0d81899361214d118ad60ef76f0e92f71d applied?

That's the *breaking* change, not the fix.

The fix would seem to be

but that hasn't even reached mainline yet.

Ben.

-- 
Ben Hutchings
All the simple programs have been written, and all the good names taken



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

Bug#1038611: lightdm: Lightdm fails to start X after upgrade to 1.32.0

[Adilson dos Santos Dantas]

I tested with the nouveau driver and it worked.

Maybe there is something between 1.26 and 1.32 that conflicts with nvidia
driver.

And it is also similar to #996503 which affects sddm and it worked too with
nouveau.

I tried to fix this by removing some module options from
https://forums.developer.nvidia.com/t/display-manager-sddm-lightdm-not-starting-with-nvidia-driver/243992
but it had no effect.

Maybe forwarding this to nvidia-driver should get some hints about this
issue.

Regards,

Adilson

Em qua., 21 de jun. de 2023 às 15:23, Yves-Alexis Perez 
escreveu:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> On Wed, 2023-06-21 at 09:40 -0300, Adilson dos Santos Dantas wrote:
> > These messages are when I stop lightdm.
>
> Ah ok.
> > >
> > >
> > > Also is there something peculiar about your hardware (Nvidia/AMD GPU
> for
> > > example?) or software (specific configuration or something).
> >
> >
> > I'm using Nvidia GPU:
> >
> > 01:00.0 VGA compatible controller: NVIDIA Corporation TU117 [GeForce GTX
> > 1650] (rev a1)
> >
> > And it is using its official drivers:
> >
> > dpkg -l xserver-xorg
> > Desired=Unknown/Install/Remove/Purge/Hold
> > |
> Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-
> > pend
> > |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
> > ||/ Nome   Versão   Arquitectura Descrição
> > +++-==---
> > =
> > ii  xserver-xorg   1:7.7+23 amd64X.Org X server
> >
> > dpkg -l xserver-xorg-video-nvidia
> > Desired=Unknown/Install/Remove/Purge/Hold
> > |
> Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-
> > pend
> > |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
> > ||/ Nome  Versão   Arquitectura Descrição
> > +++-=---
> > =
> > ii  xserver-xorg-video-nvidia 530.41.03-1  amd64NVIDIA binary
> Xorg
> > driver
>
> Yup, that's likely  related. Honestly we (I) don't really support
> binary/proprietary drivers. It'd help if you could test with free drivers
> (nouveau or something maybe).
>
> Regards,
> - --
> Yves-Alexis
> -BEGIN PGP SIGNATURE-
>
> iQEzBAEBCAAdFiEE8vi34Qgfo83x35gF3rYcyPpXRFsFAmSTQAAACgkQ3rYcyPpX
> RFu7Ggf9FCsjsiXteQ+xDSolGEtK2a9eBlnCnI9MY3wY2OdOHJlNCpbEjamWVbw3
> CwEn4//IWPgFmLcKBD1A9ySYein2tY3CDdNH5fii7ZZ/MNAlL1vuKAVuV30ayQtU
> V/4xxQXgJ+1JUCPzzKNGMdLs/yumAiLGAs3XzhjUmjVPQWMRWanCOf8dFavDyFG3
> 4sPS6niMeFUWqM17K0ja7VPVj2QbQQSe34jec93W+zcbnxbWZZuJY9nQ2PsQjRDd
> /FY0fBQtzopnZMBgRUdYNj09QGuI8kn6dZdD93+/MS2uP95ES7v1nG0bKARrGor7
> pNaWlBMeMGI/+bL89SFEQdR52n/uFw==
> =tTX8
> -END PGP SIGNATURE-
>


-- 
Adilson dos Santos Dantas
http://www.adilson.net.br
http://twitter.com/adilsond

Bug#1038752: libjodycode2: A shared library package cannot be a transitional package on a different soversion

[Eriberto]

Em qua., 21 de jun. de 2023 às 23:58, Jody Bruchon
 escreveu:
>
> Thanks for all that information! While I'm here, I should also point out
> that another Debian package will eventually have to adopt libjodycode as
> well: winregfs [1]. Fortunately it doesn't use any of the APIs that
> changed between libjodycode 2 and 3 so changing what it needs to link to
> is as simple as recompiling and pointing it to the correct libjodycode.h
> header.
>
> [1] https://packages.debian.org/sid/utils/winregfs


Thanks again Jody. The winregfs is maintained by my close friend Giovani.

I am ending the revision libjodycode_3.0.1-3.


> On 2023-06-21 10:14 PM, Eriberto wrote:
> > Hi Jody!
> >
> > Em qua., 21 de jun. de 2023 às 21:09, Tritech - Jody
> >  escreveu:
> >> Hi! I'm upstream. Would it be helpful if I provided a way to build a 
> >> compatibility shim libjodycode.so.2 with the old API 2 interfaces that 
> >> translates and links to the API 3 version? I'd be happy to provide that if 
> >> desired.
> > I think this is not needed because all these new packages don't
> > arrived to Debian Testing yet. The jdupes 1.25.0 already killed the
> > 1.24.0, so libjodycode2 is no longer useful for Debian. I will follow
> > the changes purposed by Adrian. I will start changing the packaging of
> > the lib. Furthermore, I was wrong when making a -dev package with
> > soname number attached. It was a mistake. The changes will make the
> > lib arrives to NEW queue again.
> >
> > Thanks a lot Adrian and Jody.
> >
> > Cheers,
> >
> > Eriberto
>

Bug#1038752: libjodycode2: A shared library package cannot be a transitional package on a different soversion

[Jody Bruchon]

Thanks for all that information! While I'm here, I should also point out 
that another Debian package will eventually have to adopt libjodycode as 
well: winregfs [1]. Fortunately it doesn't use any of the APIs that 
changed between libjodycode 2 and 3 so changing what it needs to link to 
is as simple as recompiling and pointing it to the correct libjodycode.h 
header.


[1] https://packages.debian.org/sid/utils/winregfs

On 2023-06-21 10:14 PM, Eriberto wrote:

Hi Jody!

Em qua., 21 de jun. de 2023 às 21:09, Tritech - Jody
 escreveu:

Hi! I'm upstream. Would it be helpful if I provided a way to build a 
compatibility shim libjodycode.so.2 with the old API 2 interfaces that 
translates and links to the API 3 version? I'd be happy to provide that if 
desired.

I think this is not needed because all these new packages don't
arrived to Debian Testing yet. The jdupes 1.25.0 already killed the
1.24.0, so libjodycode2 is no longer useful for Debian. I will follow
the changes purposed by Adrian. I will start changing the packaging of
the lib. Furthermore, I was wrong when making a -dev package with
soname number attached. It was a mistake. The changes will make the
lib arrives to NEW queue again.

Thanks a lot Adrian and Jody.

Cheers,

Eriberto

Bug#1038858: modemmanager: Unknown option: runtime

[AlMa]

Package: modemmanager
Version: 1.20.4-1

While removing ModemManager (because I neither use nor intend to use 
WWAN), I get a message “Unknown option: runtime”:


Entfernen von libmbim-utils (1.28.2-1) ...
Entfernen von libqmi-utils (1.32.2-1) ...
Entfernen von modemmanager (1.20.4-1) ...
Unknown option: runtime
Entfernen von xbrlapi (6.5-7) ...

In plain English, what does this message tell me?  Who is the culprit, 
whom to blame, and what to do?


Gratefully,
AlMa

Bug#1038857: apt-utils: installed but aptitude claims not installed.

[peter]

Package: apt-utils
Version: 2.2.4
Severity: normal

Dear Maintainer,

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

   * What led up to the situation?
   I used aptitude to update the system.
   
   * What exactly did you do (or not do) that was effective (or ineffective)?
   Aptitude was OK but reported this.
   debconf: delaying package configuration, since apt-utils is not installed
   
   * What was the outcome of this action?
   Given that apt-utils is installed, puzzlement.
   
   * What outcome did you expect instead?
   With apt-utils installed it should work as intended rather than cause 
   a report of absence.
   
-- System Information:
Debian Release: 11.7
  APT prefers oldstable-updates
  APT policy: (500, 'oldstable-updates'), (500, 'oldstable-security'), (500, 
'oldstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages apt-utils depends on:
ii  apt2.2.4
ii  libapt-pkg6.0  2.2.4
ii  libc6  2.31-13+deb11u6
ii  libdb5.3   5.3.28+dfsg1-0.8
ii  libgcc-s1  10.2.1-6
ii  libstdc++6 10.2.1-6

apt-utils recommends no packages.

apt-utils suggests no packages.

-- no debconf information

- 
mobile: +1 778 951 5147
VoIP:   +1 604 670 0140

Bug#1036233: /usr/libexec/gdm-x-session[…]: dbus-daemon[…]: [session uid=… pid=…] Activated service 'org.freedesktop.systemd1' failed: Process org.freedesktop.systemd1 exited with status 1

[AlMa]

found 1036233 gdm3/43.0-3
severity 1036233 important
affects 1036233 gnome-settings-daemon
thanks

The bug still exists on Debian stable 12.  Here's an excerpt from the log:

Jun 22 04:11:23 AnonymizedMachineName org.gnome.Shell.desktop[1148]: 
Window manager warning: Failed to parse saved session file: Datei 
»/var/lib/gdm3/.config/mutter/sessions/104bd2034b485250601687399881594011001098.ms« 
konnte nicht geöffnet werden: Datei oder Verzeichnis nicht gefunden
Jun 22 04:11:23 AnonymizedMachineName /usr/libexec/gdm-x-session[1096]: 
dbus-daemon[1096]: [session uid=119 pid=1096] Successfully activated 
service 'org.gnome.Shell.Notifications'

Jun 22 04:11:23 AnonymizedMachineName kernel: rfkill: input handler disabled
Jun 22 04:11:23 AnonymizedMachineName /usr/libexec/gdm-x-session[1096]: 
dbus-daemon[1096]: [session uid=119 pid=1096] Activating service 
name='org.gtk.vfs.Daemon' requested by ':1.20' (uid=119 pid=1282 
comm="ibus-daemon --panel disable --xim")
Jun 22 04:11:23 AnonymizedMachineName /usr/libexec/gdm-x-session[1096]: 
dbus-daemon[1096]: [session uid=119 pid=1096] Activating service 
name='org.freedesktop.systemd1' requested by ':1.10' (uid=119 pid=1236 
comm="/usr/libexec/gsd-sharing")
Jun 22 04:11:23 AnonymizedMachineName /usr/libexec/gdm-x-session[1096]: 
dbus-daemon[1096]: [session uid=119 pid=1096] Activated service 
'org.freedesktop.systemd1' failed: Process org.freedesktop.systemd1 
exited with status 1
Jun 22 04:11:23 AnonymizedMachineName gsd-sharing[1236]: Failed to 
StopUnit service: 
GDBus.Error:org.freedesktop.DBus.Error.Spawn.ChildExited: Process 
org.freedesktop.systemd1 exited with status 1
Jun 22 04:11:23 AnonymizedMachineName gsd-sharing[1236]: Failed to 
StopUnit service: 
GDBus.Error:org.freedesktop.DBus.Error.Spawn.ChildExited: Process 
org.freedesktop.systemd1 exited with status 1


Raising severity because it causes an error report downstream by 
gsd-sharing.  (The hard error I observe outside the journal is that 
Wayland doesn't start (instead, X11 jumps in) and there may or may not 
be a connection between the two errors.)

Bug#1038752: libjodycode2: A shared library package cannot be a transitional package on a different soversion

[Eriberto]

Hi Jody!

Em qua., 21 de jun. de 2023 às 21:09, Tritech - Jody
 escreveu:
>
> Hi! I'm upstream. Would it be helpful if I provided a way to build a 
> compatibility shim libjodycode.so.2 with the old API 2 interfaces that 
> translates and links to the API 3 version? I'd be happy to provide that if 
> desired.

I think this is not needed because all these new packages don't
arrived to Debian Testing yet. The jdupes 1.25.0 already killed the
1.24.0, so libjodycode2 is no longer useful for Debian. I will follow
the changes purposed by Adrian. I will start changing the packaging of
the lib. Furthermore, I was wrong when making a -dev package with
soname number attached. It was a mistake. The changes will make the
lib arrives to NEW queue again.

Thanks a lot Adrian and Jody.

Cheers,

Eriberto

Bug#1023117: cups-filters: Permissions should be 755 or 644

[Zachary Harris]

Issue persists in
Version: 1.28.17-3 (Debian 12 bookworm)

Bug#1038343: fim: Depends on SDL 1.2

[Simon McVittie]

On Sun, 18 Jun 2023 at 22:27:26 +0200, Rafael Laboissière wrote:
> * Simon McVittie  [2023-06-18 17:10]:
> > In the meantime, please could you check whether fim works as
> > intended with libsdl1.2-compat-shim, which is meant to be a drop-in
> > replacement? I'm trying to track whether there are any blockers to
> > replacing "classic" SDL 1.2.
> 
> if you think I
> should upload a new version of the package with that build-dependency,
> please tell me

No, please *don't* change the build-dependency. I'm hoping to make
sdl12-compat take over the libsdl1.2debian and libsdl1.2-dev binary
package names from classic SDL 1.2, so that no source changes or
recompilation are needed.

smcv

Bug#1038856: libx11-xcb1: The package update modified some settings in gnome control center

[zezamoral]

Package: libx11-xcb1
Version: 2:1.8.4-2+deb12u1
Severity: normal
X-Debbugs-Cc: sazamor...@gmail.com, t...@security.debian.org

Dear Maintainer,

   * What led up to the situation?
security update
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
today apt update or upgrade the system for: libx11-xcb1/data/dev and
6:amd64
   * What was the outcome of this action?
two settings ( muted mic and the screen color profile ) in gnome
control center were resets due this update.
   * What outcome did you expect instead?
not to touch user custom settings on gnome desktop



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

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

Versions of packages libx11-xcb1 depends on:
ii  libx11-6  2:1.8.4-2+deb12u1

libx11-xcb1 recommends no packages.

libx11-xcb1 suggests no packages.

-- no debconf information

Bug#1038752: libjodycode2: A shared library package cannot be a transitional package on a different soversion

[Tritech - Jody]

Hi! I'm upstream. Would it be helpful if I provided a way to build a 
compatibility shim libjodycode.so.2 with the old API 2 interfaces that 
translates and links to the API 3 version? I'd be happy to provide that if 
desired.

Jody Bruchon

Bug#1038752: libjodycode2: A shared library package cannot be a transitional package on a different soversion

[Jody Bruchon]

Apologies, I sent my last email from the wrong account. j...@jodybruchon.com is 
the correct account if replying directly. Thanks!

On June 21, 2023 7:54:54 PM EDT, Tritech - Jody  wrote:

Bug#1038855: speaker-test.1: Some remarks and editing fixes for the manual

[Bjarni Ingi Gislason]

Package: alsa-utils
Version: 1.2.9-1
Severity: minor
Tags: patch

Dear Maintainer,

here are some notes and fixes for the manual.

Input file is speaker-test.1

Output from "mandoc -T lint speaker-test.1":

mandoc: speaker-test.1:30:2: ERROR: skipping all arguments: PP \fBaplay\fR's ...
mandoc: speaker-test.1:31:1: WARNING: skipping paragraph macro: sp after PP
mandoc: speaker-test.1:48:2: ERROR: skipping all arguments: PP Each ...
mandoc: speaker-test.1:100:177: STYLE: input text line longer than 80 bytes: 
Pink noise is percep...
mandoc: speaker-test.1:113:91: STYLE: input text line longer than 80 bytes: 
When \fB\-s\fP optio...
mandoc: speaker-test.1:118:87: STYLE: input text line longer than 80 bytes: Do 
a single-shot spe...
mandoc: speaker-test.1:119:82: STYLE: input text line longer than 80 bytes: The 
channel number c...
mandoc: speaker-test.1:122:92: STYLE: input text line longer than 80 bytes: For 
example, when 1 ...
mandoc: speaker-test.1:142:107: STYLE: input text line longer than 80 bytes: 
Allow supplied \fIFR...
mandoc: speaker-test.1:161:93: STYLE: input text line longer than 80 bytes: To 
send a nice low 7...

###

Change '-' (\-) to '\(en' (en-dash) for a numeric range.

speaker-test.1:142:Allow supplied \fIFREQ\fP to be outside the default range of 
30-8000Hz. A minimum of 1Hz is still enforced.

#

Change two HYPHEN-MINUSES (code 0x055, 2D) to an em-dash (\(em), if one
is intended.  An en-dash is usually surrounded by a space, while an em-dash
is used without spaces. "man" (1 byte characters) transforms an en-dash
(\(en ) to one HYPHEN-MINUS, and an em-dash to two HYPHEN-MINUSES without
considering the space around it.
If "--" are two single "-" (end of options) then use "\-\-".

speaker-test.1:100:Pink noise is perceptually uniform noise -- that is, it 
sounds like every frequency at once.  If you can hear any tone it may indicate 
resonances in your speaker system or room.

#

Wrong distance between sentences.

  Separate the sentences and subordinate clauses; each begins on a new
line.  See man-pages(7) ("Conventions for source file layout") and
"info groff" ("Input Conventions").

  The best procedure is to always start a new sentence on a new line,
at least, if you are typing on a computer.

Remember coding: Only one command ("sentence") on each (logical) line.

E-mail: Easier to quote exactly the relevant lines.

Generally: Easier to edit the sentence.

Patches: Less unaffected text.

  The amount of space between sentences in the output can then be
controlled with the ".ss" request.

23:\fBspeaker\-test\fP by default will test the \fIdefault\fP device. If you
26:those cards. Notice that there might be for example, one device for
50:and surround40. So, if you want to test the last device you can
51:run \fBspeaker\-test \-Dsurround40:ICH5 \-c 6\fR. The \fB\-c\fR option will
142:Allow supplied \fIFREQ\fP to be outside the default range of 30-8000Hz. A 
minimum of 1Hz is still enforced.

#

Split lines longer than 100 characters into two or more lines.
Appropriate break points are the end of a sentence and a subordinate
clause; after punctuation marks.

speaker-test.1: line 100length 177
Pink noise is perceptually uniform noise -- that is, it sounds like every 
frequency at once.  If you can hear any tone it may indicate resonances in your 
speaker system or room.

speaker-test.1: line 142length 107
Allow supplied \fIFREQ\fP to be outside the default range of 30-8000Hz. A 
minimum of 1Hz is still enforced.


#

Name of a manual is set in bold, the section in roman.
See man-pages(7).

177:.BR aplay(1)

#

--- speaker-test.1  2023-06-21 22:53:24.0 +
+++ speaker-test.1.new  2023-06-21 23:12:51.0 +
@@ -20,14 +20,17 @@ speaker\-test \- command\-line speaker t
 .SH DESCRIPTION
 \fBspeaker\-test\fP generates a tone that can be used to test the speakers of 
a computer.
 
-\fBspeaker\-test\fP by default will test the \fIdefault\fP device. If you
+\fBspeaker\-test\fP by default will test the \fIdefault\fP device.
+If you
 want to test another sound device you will have first to get a list of
 all of the sound cards in your system and the devices associated with
-those cards. Notice that there might be for example, one device for
-analog sound, one for digital sound and one for HDMI sound.
+those cards.
+Notice that there might be for example, one device for analog sound,
+one for digital sound and one for HDMI sound.
 To get the list of available cards and devices you can run \fBaplay \-L\fR.
 
-.P \fBaplay\fR's output will be similar to this one:
+.P
+\fBaplay\fR's output will be similar to this one:
 
 .nf
 $ aplay \-L
@@ -47,14 +50,12 @@ surround40:CARD=ICH5,DEV=0
 
 .P Each of the devices is listed in the beginning of the definition so,
 in the above example, there are four devices listed: null, default, front
-and surround40. So, if you want to test the last device you can
-run \fBspeaker\-test \-Dsurround40:ICH5 \-c 

Bug#1038343: fim: Depends on SDL 1.2

[Michele Martone]

On 20230618@22:27, Rafael Laboissière wrote:
> * Simon McVittie  [2023-06-18 17:10]:
> 
> > On Sat, 17 Jun 2023 at 21:11:25 +0200, Rafael Laboissière wrote:
> > > Thanks for this bug report. I forwarded it upstream and I am also sending
> > > this message with Cc to the upstream author.
> > 
> > Thanks. In the meantime, please could you check whether fim works as
> > intended with libsdl1.2-compat-shim, which is meant to be a drop-in
> > replacement? I'm trying to track whether there are any blockers to
> > replacing "classic" SDL 1.2.
> 
> The package builds fine against libsdl1.2-compat-dev on my sid amd64 system.
> All tests also passed, but I am not sure this would be enough. I would
> rather let the upstream author have the final word, but if you think I
> should upload a new version of the package with that build-dependency,
> please tell me.

Dear Rafael, dear Simon,

If using the compatibility layer and:

 * `make tests` passes
 * you can start `fim -o sdl $FILE` and move around by pressing
   n, p, then enlarging/shrinking with + and -, using the arrows
   to scroll, and : to start the console, and after : typing
   'quit' and it quits, plus the window is resizable

then I'd say this later is perfectly fine.

Can you verify if the above conditions are fulfilled?

Michele


signature.asc
Description: PGP signature

Bug#1015427: imx-code-signing-tool: ftbfs with LTO (link time optimization) enabled

[Jeremy Bícha]

Control: tags -1 +patch

Patch attached.

Thank you,
Jeremy Bícha
From 027fc9a9139e88f48f4b5bcd54d43b40f93150c7 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Jeremy=20B=C3=ADcha?= 
Date: Wed, 21 Jun 2023 19:22:29 -0400
Subject: [PATCH] debian/rules: Disable LTO

Closes: #1015427
---
 debian/rules | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/debian/rules b/debian/rules
index 67f94a4..096db5a 100755
--- a/debian/rules
+++ b/debian/rules
@@ -1,5 +1,7 @@
 #!/usr/bin/make -f
 
+export DEB_BUILD_MAINT_OPTIONS = optimize=-lto
+
 %:
 	dh $@
 
-- 
2.39.2

Bug#1038854: mimedefang: package missing Depend: libnet-dns-perl

[Paul Schulz]

Package: mimedefang
Version: 3.3-1
Severity: normal

Dear Maintainer,


   * What led up to the situation?
default configuration
systemctl start mimedefang
mail.log: mimedefang-multiplexor Undefined subroutine 
::do_main_loop called at /usr/bin/mimedefang.pl line 36

   * What exactly did you do (or not do) that was effective?
apt install libnet-dns-perl

   * What was the outcome of this action?
problem is resolved - operation is normal

   * What outcome did you expect instead?
package libnet-dns-perl included as Depend: on package mimedefang



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

Kernel: Linux 5.15.102-1-pve (SMP w/2 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE
Locale: LANG=en_NZ.UTF-8, LC_CTYPE=en_NZ.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages mimedefang depends on:
ii  adduser 3.134
ii  debconf [debconf-2.0]   1.5.82
ii  libc6   2.36-9
ii  libio-stringy-perl  2.111-3
ii  libmailtools-perl   2.21-2
ii  libmilter1.0.1  8.17.1.9-2
ii  libmime-tools-perl  5.510-1
ii  libperl5.36 5.36.0-7
ii  libunix-syslog-perl 1.1-4+b1
ii  perl [libmime-base64-perl]  5.36.0-7
ii  psmisc  23.6-1

mimedefang recommends no packages.

Versions of packages mimedefang suggests:
ii  clamav 1.0.1+dfsg-2
pn  graphdefang
pn  libarchive-zip-perl
ii  libhtml-parser-perl3.81-1
pn  libmail-spamassassin-perl  
ii  postfix3.7.5-2
pn  sanitizer  
pn  tk | wish  
pn  wv 

-- debconf information:
* mimedefang/embedperl: true

Bug#1037884: vfu: ftbfs with GCC-13

[Boian Bonev]

Hi,

I tried with gcc 13.1.0-6 and binutils 2.40.50.20230611-2 and couldn't
reproduce the problem.

Please advise if it is OK to close the bug

--
With best regards,
b.


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

Bug#1030850: Please stop creating /etc/timezone

[Luca Boccassi]

On Wed, 08 Feb 2023 13:03:35 +0100 Michael Biebl 
wrote:
> Source: tzsetup
> Version: 1:0.118
> Severity: normal
> X-Debbugs-Cc: 822...@bugs.debian.org
> 
> Hi,
> 
> regarding the latest changes in tzdata, which stopped creating
> /etc/timezone [1], it was recommended that tzsetup should be updated
> accordingly [2].

As requested by Benjamin, created bugs against packages that appear to
rely on /etc/timezone (ie, they mention /etc/timezone but not
/etc/localtime as found on codesearch):

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1038833
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1038834
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1038835
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1038836
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1038837
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1038838
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1038839
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1038840
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1038841
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1038842
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1038843
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1038844
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1038845
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1038846
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1038847
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1038848
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1038849
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1038850
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1038851
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1038852

-- 
Kind regards,
Luca Boccassi


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

Bug#1038853: usrmerge: clean up the unused empty biarch directories

[Andreas Beckmann]

Package: usrmerge
Version: 35
Severity: important
Tags: patch

bootstrapping a merged-/usr system or earlier conversions may have
created empty biarch directories and links to them, e.g.
  /usr/libx32
  /libx32 -> /usr/libx32

Since glibc 2.35-4 this is handled by the respective glibc packages
and usrmerge has stopped creating them.

So let's clean them up (once) on upgrades of the usrmerge/usr-is-merged
packages if they are not owned by any package according to the dpkg
database. Otherwise they might suddenly disappear after installation and
removal of a package "owning" them.

While the existence/disappearance of these directories and links is
harmless for a regular system, it is nasty for doing QA testing since
that may trigger an error on sudden disappearance of files/directories
(at non-volatile locations). Ignoring these locations is not a good
idea, since it might hide actual bugs mishandling the biarc locations.

I've been running piuparts bullseye -> bookworm upgrade tests with this
patch applied and that solved all the unexpected disappearance of biarch
directories and links.


Andreas
>From 6a07b047055ef2d05ab3381f9f7ce64c21f6b60b Mon Sep 17 00:00:00 2001
From: Andreas Beckmann 
Date: Sun, 28 May 2023 14:20:21 +0200
Subject: [PATCH] postinst: Clean up the unused empty biarch directories

bootstrapping or earlier conversions may have created empty biarch
directories and links. glibc 2.35-4 or later will create them if
needed, so clean up the unused (and unowned) ones

Closes: #
---
 debian/usr-is-merged.postinst | 28 
 debian/usrmerge.postinst  | 22 +-
 2 files changed, 49 insertions(+), 1 deletion(-)
 create mode 100644 debian/usr-is-merged.postinst

diff --git a/debian/usr-is-merged.postinst b/debian/usr-is-merged.postinst
new file mode 100644
index 000..3d0e0c5
--- /dev/null
+++ b/debian/usr-is-merged.postinst
@@ -0,0 +1,28 @@
+#!/bin/sh
+set -e
+
+cleanup_biarch_dirs() {
+  # bootstrapping or earlier conversions may have created empty biarch
+  # directories and links. glibc 2.35-4 or later will create them if needed,
+  # so clean up the unused (and unowned) ones
+  local arch_directories="/lib64 /lib32 /libo32 /libx32"
+  for dir in $arch_directories; do
+[ -e "$dir" ] || continue
+if ! dpkg-query -S $dir >/dev/null 2>&1; then
+  rm -v $dir
+  if [ -e /usr$dir ] && ! dpkg-query -S /usr$dir >/dev/null 2>&1 ; then
+rmdir --ignore-fail-on-non-empty -v /usr$dir
+  fi
+fi
+  done
+}
+
+case "$1" in
+configure)
+  if dpkg --compare-versions "$2" lt "36~" ; then
+cleanup_biarch_dirs
+  fi
+;;
+esac
+
+#DEBHELPER#
diff --git a/debian/usrmerge.postinst b/debian/usrmerge.postinst
index 257f0e5..057b7f1 100644
--- a/debian/usrmerge.postinst
+++ b/debian/usrmerge.postinst
@@ -1,4 +1,5 @@
-#!/bin/sh -e
+#!/bin/sh
+set -e
 
 is_fs() {
   local fs_type
@@ -49,6 +50,22 @@ END
   /usr/lib/usrmerge/convert-usrmerge || return $?
 }
 
+cleanup_biarch_dirs() {
+  # bootstrapping or earlier conversions may have created empty biarch
+  # directories and links. glibc 2.35-4 or later will create them if needed,
+  # so clean up the unused (and unowned) ones
+  local arch_directories="/lib64 /lib32 /libo32 /libx32"
+  for dir in $arch_directories; do
+[ -e "$dir" ] || continue
+if ! dpkg-query -S $dir >/dev/null 2>&1; then
+  rm -v $dir
+  if [ -e /usr$dir ] && ! dpkg-query -S /usr$dir >/dev/null 2>&1 ; then
+rmdir --ignore-fail-on-non-empty -v /usr$dir
+  fi
+fi
+  done
+}
+
 case "$1" in
 configure)
# Skip the conversion for buildds.
@@ -59,6 +76,9 @@ case "$1" in
  echo "W: /etc/unsupported-skip-usrmerge-conversion exists." >&2
else
  maybe_convert "$@" || { echo "E: usrmerge failed." >&2; exit 1; }
+ if dpkg --compare-versions "$2" lt "36~" ; then
+   cleanup_biarch_dirs
+ fi
  /usr/lib/usrmerge/convert-etc-shells
fi
 ;;
-- 
2.20.1

Bug#1034387: update youtube-dl control file to reflect transitional package

[Andres Salomon]

On Sun, 4 Jun 2023 13:42:23 +0200 Andreas Tille  
wrote:

> Control: tags -1 pending
>
> Am Sat, Jun 03, 2023 at 12:54:33PM -0400 schrieb Jesse Rhodes:
> > The debian/control fields for youtube-dl still have a lot of 
leftover
> > information from when it was a binary package, which should be 
cleaned
> > up to reflect what the package actually does at present. 
Specifically,
> > it does not need to Recommend any other packages past the 
dependency
> > on yt-dlp, and it also does not need ~1200 lines of a list of 
websites

> > supported by a tool which is no longer packaged.
> >
> > For convenience, I have attached an updated control file, which
> > includes the above request as well.
>
> Applied in Git.
>
> Thanks a lot for the fix
> Andreas.
>
> --
> http://fam-tille.de
>
>


Andreas, were you planning to do an upload? Because I was about to open 
a bug against ftp.debian.org to request removal of the package now that 
bookworm is released. I can wait if you want, but I don't see much 
point in keeping youtube-dl in sid.


I'm happy to request this change for a bookworm point release (via 
bookworm-proposed-updates), though, and do the upload. Seems like a 
pretty simple change, I can't imagine release managers opposing it.

Bug#1034867: smplayer always crashes in Debian 12

[Edward C. Jones]

Package: smplayer
Version: 22.7.0~ds0-1
Followup-For: Bug #1034867
X-Debbugs-Cc: 

Dear Maintainer,

I recently installed Debian 12 (bookworm) on my PC.  I use KDE.

Whenever I try to run smplayer, it does nothing.  If I try to delete the
smplayer window, smplay tells me it has crashed and points me to a log file
I suspect my bug may be the same as #1034867 because there are many X11
errors in the log.

Here is the log:
===

/usr/bin/mpv --no-quiet --terminal --no-msg-color 
--input-ipc-server=/tmp/smplayer-mpv-17e34 --msg-level=ffmpeg/demuxer=error 
--video-rotate=no --no-config --no-fs --hwdec=no --sub-auto=fuzzy --vo=x11, 
--no-input-default-bindings --input-vo-keyboard=no --no-input-cursor 
--cursor-autohide=no --no-keepaspect --wid=8 --monitorpixelaspect=1 
--osd-level=1 --osd-scale=1 --osd-bar-align-y=0.6 --sub-ass --embeddedfonts 
--sub-ass-line-spacing=0 --sub-scale=1 --sub-font=Arial --sub-color=# 
--sub-shadow-color=#ff00 --sub-border-color=#ff00 
--sub-border-size=0.75 --sub-shadow-offset=2.5 --sub-font-size=50 --sub-bold=no 
--sub-italic=no --sub-margin-y=8 --sub-margin-x=20 --sub-codepage=ISO-8859-1 
--sub-pos=100 --volume=55 --cache=auto --screenshot-template=cap_%F_%p_%02n 
--screenshot-format=jpg 
--screenshot-directory=/home/edcjones/Pictures/smplayer_screenshots 
--audio-pitch-correction=yes --volume-max=110 
--term-playing-msg=MPV_VERSION=${=mpv-version:}
INFO_VIDEO_WIDTH=${=width}
INFO_VIDEO_HEIGHT=${=height}
INFO_VIDEO_ASPECT=${=video-params/aspect}
INFO_VIDEO_FPS=${=container-fps:${=fps}}
INFO_VIDEO_FORMAT=${=video-format}
INFO_VIDEO_CODEC=${=video-codec}
INFO_DEMUX_ROTATION=${=track-list/0/demux-rotation}
INFO_AUDIO_FORMAT=${=audio-codec-name}
INFO_AUDIO_CODEC=${=audio-codec}
INFO_AUDIO_RATE=${=audio-params/samplerate}
INFO_AUDIO_NCH=${=audio-params/channel-count}
INFO_LENGTH=${=duration:${=length}}
INFO_DEMUXER=${=current-demuxer:${=demuxer}}
INFO_SEEKABLE=${=seekable}
INFO_TITLES=${=disc-titles}
INFO_CHAPTERS=${=chapters}
INFO_TRACKS_COUNT=${=track-list/count}
METADATA_TITLE=${metadata/by-key/title:}
METADATA_ARTIST=${metadata/by-key/artist:}
METADATA_ALBUM=${metadata/by-key/album:}
METADATA_GENRE=${metadata/by-key/genre:}
METADATA_DATE=${metadata/by-key/date:}
METADATA_TRACK=${metadata/by-key/track:}
METADATA_COPYRIGHT=${metadata/by-key/copyright:}
INFO_MEDIA_TITLE=${=media-title:}
INFO_STREAM_PATH=${stream-path}
 --audio-client-name=SMPlayer --term-status-msg=STATUS: ${=time-pos} / 
${=duration:${=length:0}} P: ${=pause} B: ${=paused-for-cache} I: ${=core-idle} 
VB: ${=video-bitrate:0} AB: ${=audio-bitrate:0} /data/pics/videos/trever/trever 
and chris grappling part 3.webm

 (+) Video --vid=1 (*) (vp8 640x480 30.000fps)
 (+) Audio --aid=1 (*) (vorbis 1ch 44100Hz)
[vo/x11/x11] X11 error: BadDrawable (invalid Pixmap or Window parameter)
[vo/x11/x11] Type: 0, display: 0x7febb40456b0, resourceid: 8, serial: 12
[vo/x11/x11] Error code: 9, request code: e, minor code: 0
[vo/x11/x11] X11 error: BadWindow (invalid Window parameter)
[vo/x11/x11] Type: 0, display: 0x7febb40456b0, resourceid: 8, serial: 13
[vo/x11/x11] Error code: 3, request code: 28, minor code: 0
[vo/x11/x11] X11 error: BadWindow (invalid Window parameter)
[vo/x11/x11] Type: 0, display: 0x7febb40456b0, resourceid: 8, serial: 16
[vo/x11/x11] Error code: 3, request code: 2, minor code: 0
[vo/x11/x11] X11 error: BadWindow (invalid Window parameter)
[vo/x11/x11] Type: 0, display: 0x7febb40456b0, resourceid: 8, serial: 18
[vo/x11/x11] Error code: 3, request code: 1, minor code: 0
[vo/x11/x11] X11 error: BadWindow (invalid Window parameter)
[vo/x11/x11] Type: 0, display: 0x7febb40456b0, resourceid: 322, serial: 1b
[vo/x11/x11] Error code: 3, request code: 12, minor code: 0
[vo/x11/x11] X11 error: BadWindow (invalid Window parameter)
[vo/x11/x11] Type: 0, display: 0x7febb40456b0, resourceid: 322, serial: 1e
[vo/x11/x11] Error code: 3, request code: 91, minor code: 3
[vo/x11/x11] X11 error: BadWindow (invalid Window parameter)
[vo/x11/x11] Type: 0, display: 0x7febb40456b0, resourceid: 322, serial: 20
[vo/x11/x11] Error code: 3, request code: 12, minor code: 0
[vo/x11/x11] X11 error: BadWindow (invalid Window parameter)
[vo/x11/x11] Type: 0, display: 0x7febb40456b0, resourceid: 322, serial: 21
[vo/x11/x11] Error code: 3, request code: 12, minor code: 0
[vo/x11] Warning: this legacy VO has bad performance. Consider fixing your 
graphics drivers, or not forcing the x11 VO.
[vo/x11/x11] X11 error: BadWindow (invalid Window parameter)
[vo/x11/x11] Type: 0, display: 0x7febb40456b0, resourceid: 322, serial: 23
[vo/x11/x11] Error code: 3, request code: 12, minor code: 0
[vo/x11/x11] X11 error: BadWindow (invalid Window parameter)
[vo/x11/x11] Type: 0, display: 0x7febb40456b0, resourceid: 322, serial: 24
[vo/x11/x11] Error code: 3, request code: 12, minor code: 0
[vo/x11/x11] X11 error: BadDrawable (invalid Pixmap or Window parameter)
[vo/x11/x11] Type: 0, display: 

Bug#1037190: re-introduction of epoch? #1037190 dhcpcd: version is lower than in wheezy

[Andreas Beckmann]

On 18/06/2023 04.41, Martin-Éric Racine wrote:

override_dh_gencontrol:
 dh_gencontrol --package=dhcpcd -- -v1:$(DEB_VERSION_UPSTREAM_REVISION)
 dh_gencontrol --remaining-packages

Would probably be enough to make this policy-compliant again.


Please do that.

While doing more piuparts tests starting from ancient releases, I found 
that the combination of dhcpcd/wheezy with dhcpcd5/bullseye prevents the 
installation of usrmerge (and thus the upgrade to bookworm) with


  FATAL ERROR:
  Both /sbin/dhcpcd and /usr/sbin/dhcpcd exist.

This package combination is e.g. achieved by installing wicd-daemon in 
wheezy and upgrading release by release to bookworm.


To solve that, we need to add Conflicts: dhcpcd (<< 1:5~) to usrmerge 
which will make dhcpcd in sid (and bookworm) uninstallable due to the 
missing epoch.



Andreas

Bug#1038832: usrmerge: more conflicts with ancient packages

[Andreas Beckmann]

Package: usrmerge
Version: 35
Severity: important
User: debian...@lists.debian.org
Usertags: piuparts

while doing piuparts upgrade tests starting from ancient releases (going
back to lenny), I found a few more packages incompatible with usrmerge.
Please add Conflicts against them, too.


lustre-utils (squeeze)
  FATAL ERROR:
  Both /sbin/mkfs.lustre and /usr/sbin/mkfs.lustre exist.

version in squeeze: 1.8.3-4, removed after squeeze
last version on snapshot.d.o: 1.8.5+dfsg-3.1
recommended Conflicts: lustre-utils (<< 1.8.5+dfsg-3.2~)


libparted1.8-10 (lenny)
  FATAL ERROR:
  Both /lib/libparted-1.8.so.10 and /usr/lib/libparted-1.8.so.10 exist.

(this probably only happens in combination with the -dev package)

version in lenny: 1.8.8.git.2008.03.24-11.1, removed after lenny
last version on snapshot.d.o: 1.8.8.git.2008.03.24-11.1+hurdfr1
recommended Conflicts: libparted1.8-10 (<< 1.8.8.git.2008.03.24-11.2~)


dhcpcd (wheezy) in combination with dhcpcd5
  FATAL ERROR:
  Both /sbin/dhcpcd and /usr/sbin/dhcpcd exist.

version in wheezy: 1:3.2.3-11+deb7u1
last version on snapshot.d.o: 1:3.2.3-11+deb7u1 (wheezy), 9.4.1-24 (sid)
recommended Conflicts: dhcpcd (<< 1:5~)
the missing epoch in dhcpcd is bug #1037190


Andreas

Bug#1038831: RM: spectral -- ROM; abandoned upstream & replaced by Neochat

[Andres Salomon]

Package: ftp.debian.org
Severity: normal

Spectral was dead upstream, and then forked and replaced by neochat. In 
bookworm I turned the spectral package into a dummy transitional 
package that depends on neochat. Now that bookworm is released, please 
remove the spectral package from sid/trixie.


It doesn't have any reverse dependencies.

Thanks,
Andres

Bug#1038829: python-websockets: CVE-2021-33880 fix for bullseye

[Bastian Germann]

Source: python-websockets
Version: 8.1-1
Tags: security

This is a backport of the CVE-2021-33880 fix to bullseye where it is missing.From 9428df4ba027dea422697cfae995568cd06cd06a Mon Sep 17 00:00:00 2001
From: Aymeric Augustin 
Date: Sun, 23 May 2021 18:51:27 +0200
Subject: [PATCH] Use constant-time comparison for passwords.

Backport of c91b4c2a to 8.1.
---
 src/websockets/auth.py | 29 -
 1 file changed, 16 insertions(+), 13 deletions(-)

diff --git a/src/websockets/auth.py b/src/websockets/auth.py
index ae204b8..aeaf15b 100644
--- a/src/websockets/auth.py
+++ b/src/websockets/auth.py
@@ -6,7 +6,9 @@
 
 
 import functools
+import hmac
 import http
+from typing import cast
 from typing import Any, Awaitable, Callable, Iterable, Optional, Tuple, Type, Union
 
 from .exceptions import InvalidHeader
@@ -137,24 +139,25 @@ def basic_auth_protocol_factory(
 
 if credentials is not None:
 if is_credentials(credentials):
-
-async def check_credentials(username: str, password: str) -> bool:
-return (username, password) == credentials
-
+credentials_list = [cast(Credentials, credentials)]
 elif isinstance(credentials, Iterable):
 credentials_list = list(credentials)
-if all(is_credentials(item) for item in credentials_list):
-credentials_dict = dict(credentials_list)
-
-async def check_credentials(username: str, password: str) -> bool:
-return credentials_dict.get(username) == password
-
-else:
+if not all(is_credentials(item) for item in credentials_list):
 raise TypeError(f"invalid credentials argument: {credentials}")
-
 else:
 raise TypeError(f"invalid credentials argument: {credentials}")
 
+credentials_dict = dict(credentials_list)
+
+async def check_credentials(username: str, password: str) -> bool:
+try:
+expected_password = credentials_dict[username]
+except KeyError:
+return False
+return hmac.compare_digest(expected_password, password)
+
 return functools.partial(
-create_protocol, realm=realm, check_credentials=check_credentials
+create_protocol,
+realm=realm,
+check_credentials=check_credentials,
 )
-- 
2.40.1

Bug#1038830: RFP: haskell-sdl2-mixer -- Haskell bindings for SDL2_mixer

[Simon McVittie]

Package: wnpp
Severity: wishlist
X-Debbugs-Cc: debian-hask...@lists.debian.org
Control: block 1038088 by -1

* Package name: haskell-sdl2-mixer
  Version : 1.2.0.0
  Upstream Contact: Siniša Biđin, Daniel Firth
* URL : https://hackage.haskell.org/package/sdl2-mixer
* License : MIT
  Programming Lang: Haskell
  Description : Haskell bindings for SDL2_mixer

A new upstream release of raincat has been ported to SDL2, but will
presumably need updated dependencies.

Bug#1038828: RFP: haskell-sdl2-image -- Haskell bindings for SDL2_image

[Simon McVittie]

Package: wnpp
Severity: wishlist
X-Debbugs-Cc: debian-hask...@lists.debian.org
Control: block 1038088 by -1

* Package name: haskell-sdl2-image
  Version : 2.1.0.0
  Upstream Contact: Siniša Biđin, Daniel Firth
* URL : https://hackage.haskell.org/package/sdl2-image
* License : MIT
  Programming Lang: Haskell
  Description : Haskell bindings for SDL2_image

A new upstream release of raincat has been ported to SDL2, but will
presumably need updated dependencies.

(It would probably also be useful if someone who knows Haskell can have
a look at updating raincat and other Haskell games.)

Bug#1038450: patch probably available

[Adrien Nader]

On Wed, Jun 21, 2023, julien.pu...@gmail.com wrote:
> Le mardi 20 juin 2023 à 22:38 +0200, Adrien Nader a écrit :
> > 
> > 
> > The patch seems to fix the issue. I say "seem" because the build
> > compiled the file that was failing to build but the build is not done
> > yet: emulated armhf isn't fast. :) 
> > 
> > But since I reprocued the build failure before, I am fairly confident
> > this build will succeed.
> 
> I took the commit and added it to the Debian packaging ; I now have a
> 20230420-4 almost ready for upload.
> 
> I'm waiting for two feedbacks before I do so :
> 
> 1. yours so I trust it fixes the 32-bit issue ;
> 
> 2. the sbuild I started on my box to check the patch on more usual
> architectures.
> 
> Thanks for your help!

My build just finished. It only took 27 hours. It failed at the lintian
step but that was due to network issues.

Bug#1038827: libwebm: Failed tests in big-endian architectures

[Boyuan Yang]

Source: libwebm
Version: 1.0.0.29-1
Tags: sid
Severity: important
X-Debbugs-CC: debian-s...@lists.debian.org debian-h...@lists.debian.org 
debian-powe...@lists.debian.org debian-sp...@lists.debian.org 
vasek.ge...@gmail.com

Hi all,

Package libwebm was introduced into Debian in 2021 for .webm support
(and to avoid library vendor copies). However, its unit test has been broken
on big-endian architectures since very beginning as shown in buildd page at
https://buildd.debian.org/status/package.php?p=libwebm (s390x/hppa/powerpc/
ppc64/sparc64 for 1.0.0.30-2 and earlier), causing FTBFS.

Currently an convenient copy of libwebm is bundled and embedded in src:aom,
and embedded libwebm lacks unit tests. When I am working on src:aom and
trying to replace bundled libwebm with the packaged one, current failed unit
tests in libwebm will need some handling, or at least in the release 
archtiecture
(s390x, such as
https://buildd.debian.org/status/fetch.php?pkg=libwebm=s390x=1.0.0.30-2=1687373358=0
):


==
./testing/mkvmuxer_tests.cc:863: Failure
Expected equality of these values:
  muxer_mm.luminance_min()
Which is: 30
  parser_mm->luminance_min
Which is: 0
./testing/mkvmuxer_tests.cc:864: Failure
Expected equality of these values:
  muxer_mm.luminance_max()
Which is: 40
  parser_mm->luminance_max
Which is: 0
./testing/mkvmuxer_tests.cc:865: Failure
Expected equality of these values:
  muxer_mm.r()->x()
Which is: 0.1
  parser_mm->r->x
Which is: 0
./testing/mkvmuxer_tests.cc:866: Failure
Expected equality of these values:
  muxer_mm.r()->y()
Which is: 0.2
  parser_mm->r->y
Which is: 0
./testing/mkvmuxer_tests.cc:867: Failure
Expected equality of these values:
  muxer_mm.g()->x()
Which is: 0.1
  parser_mm->g->x
Which is: 0
./testing/mkvmuxer_tests.cc:868: Failure
Expected equality of these values:
  muxer_mm.g()->y()
Which is: 0.2
  parser_mm->g->y
Which is: 0
./testing/mkvmuxer_tests.cc:869: Failure
Expected equality of these values:
  muxer_mm.b()->x()
Which is: 0.1
  parser_mm->b->x
Which is: 0
./testing/mkvmuxer_tests.cc:870: Failure
Expected equality of these values:
  muxer_mm.b()->y()
Which is: 0.2
  parser_mm->b->y
Which is: 0
./testing/mkvmuxer_tests.cc:871: Failure
Expected equality of these values:
  muxer_mm.white_point()->x()
Which is: 0.1
  parser_mm->white_point->x
Which is: 0
./testing/mkvmuxer_tests.cc:872: Failure
Expected equality of these values:
  muxer_mm.white_point()->y()
Which is: 0.2
  parser_mm->white_point->y
Which is: 0
[  FAILED  ] MuxerTest.Colour (0 ms)
[ RUN  ] MuxerTest.ColourPartial
[   OK ] MuxerTest.ColourPartial (0 ms)
[ RUN  ] MuxerTest.Projection
./testing/mkvmuxer_tests.cc:930: Failure
Expected equality of these values:
  muxer_proj.pose_yaw()
Which is: 1
  parser_proj->pose_yaw
Which is: 0
./testing/mkvmuxer_tests.cc:931: Failure
Expected equality of these values:
  muxer_proj.pose_pitch()
Which is: 2
  parser_proj->pose_pitch
Which is: 0
./testing/mkvmuxer_tests.cc:932: Failure
Expected equality of these values:
  muxer_proj.pose_roll()
Which is: 3
  parser_proj->pose_roll
Which is: 0
[  FAILED  ] MuxerTest.Projection (0 ms)

===


I am looking for help from porters with experience in big-endian architectures
on debugging of the test failures. Given the high popcon of reverse dependencies
(src:aom, 3+), I may allow unittest failures for now but still keep this bug
report open against src:libwebm. Any help would be appreciated.

Best,
Boyuan Yang


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

Bug#1038826: please drop usage of (deprecated in bullseye, removed in trixie) qemu-debootstrap

[Michael Tokarev]

Package: autopkgtest
Version: 5.28
Severity: important
X-Debbugs-Cc: pkg-qemu-de...@lists.alioth.debian.org

qemu-debootstrap script (part of qemu-user-static package) has been deprecated
for quite some time (it gave a warning at invocation), and has been removed for
trixie.  What it did was to print the warning and execute debootstrap directly
with all the same arguments as given to qemu-debootstrap itself.  qemu-user
works transparently these days, there's no need in qemu-debootstrap helper
anymore.  With new qemu in unstable, autopkgtest does not work anymore.
if you change call to qemu-debootstrap in autopkgtest to debootstrap, it
will work in trixie and in bookworm just fine.

Thanks,

/mjt

Bug#1038825: rust-zbus: please provide feature gvariant

[Jonas Smedegaard]

Source: rust-zbus
Version: 3.12.0-3
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Please provide feature gvariant.


-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmSTX30ACgkQLHwxRsGg
ASE1ABAAoIsXryyMXsHMfhhZApS2oDJ0BGpjOLb256Py6rIBII303WexgMqfst1S
bNSPy36viF1TImj8ad7vtJoPE9Ix49XBG4Me+0nQMuCLmW0obFViZ0hiKEx6yxl+
SqCTfJ7L+DuqAclVljzMo0yCi+DSKPhIG9QcDfNR7KudNmhxZwa3S57uyFxvzqXw
HJgspcyMuL5kRkvxS/BiMKz6/yco+5sbZpD5/WNaKldkKk/2Dke7hriNFhjX+QFe
hxyEC9TRfax75v3G9X0tnlhAw8I/6bhqN6G9bCqG+4bVCasupDRhSYjg/n4D7dYz
hwQFEeB4KYGF4bhaz6du5rKJojqbFq4Sj903Xqkaqh0m380y17rH5rxBN7JeR0bB
b/fxAChFfrmQ/eutiXNOJCB4MhYW9ByvcSpriThzHRZ3wqYEIeLbpxELwpS7B7df
pOHhCMnk0OmajbxDTSXRnm2Ydy4/NeZJG9Wj0n4/FaF8K2n/H7xHLL0Z+TT3p8Qa
0Ps7P+vFQZ6ic7YlmvswWSHQQCHk4MWajiKLbhTt6Dkd/lfFCk74igg41J9fGy03
m0F7o9j8DmJk41fSwwrIiKnkTssEVpK3GzpTk8IQOg1gm4SnCCcJfRWF9kYJw7B6
yY42tMSUNVRcUeqHaFHk++WjuSVTwbvr4QCLr4QEIN7V4QvZHhM=
=s1b0
-END PGP SIGNATURE-

Bug#1038813: bullseye-pu: package aide/0.17.3-4+deb11u2

[tommy reid]

okay huh?


On Wed, Jun 21, 2023, 9:45 AM Marc Haber 
wrote:

> Package: release.debian.org
> Severity: normal
> Tags: bullseye
> User: release.debian@packages.debian.org
> Usertags: pu
> X-Debbugs-Cc: a...@packages.debian.org
> Control: affects -1 + src:aide
>
> Dear stable releas team,
>
> this pre-upload request for the aide package is filed to ask for
> guidance whether this package is suitable for bullseye-proposed-updates.
> I have never done this before and am open for suggestions to improve and
> for documentation pointers.
>
> A fixed package has recently migrated to testing, the corresponding
> bookworm request is #1037945.
>
> [ Reason ]
> This update fixes #1037436, a "just" important bug that causes incorrect
> processing of extended attributes on symlinks that are monitored by
> aide. This is a fix suggested by upstream (who is also a DD).
>
> [ Impact ]
> Without this fix, Aide will wrongly process extended attributes for
> the file a symlink points to, which is not the intended behavior. The
> fixed aide will process the extended attributes of a symlink.
>
> [ Tests ]
> This bug is sadly not covered by automated tests. I created a symlink
> with extended attributes pointing to a file with different extended
> attributes and verified that actually the extended attributes of the
> symlink show up in the database.
>
> [ Risks ]
> Risks are that I goofed up in the fixes.
>
> [ 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 ]
> commit b1d036a82a336836f05ed0d6dcb0b4bab6c7501f (HEAD -> bullseye)
> Author: Marc Haber 
> Date:   Wed Jun 21 18:29:23 2023 +0200
>
> prepare upload to bullseye
>
> Git-Dch: ignore
>
> commit 60e63ac4052724be4a2b078940e266e835e89bf7
> Author: Marc Haber 
> Date:   Wed Jun 21 18:27:56 2023 +0200
>
> refresh patch for bullseye
>
> Git-Dch: ignore
>
> commit f2912c100a5d3d9b37d4ab9318d5b8b9bf45025c
> Author: Marc Haber 
> Date:   Wed Jun 14 04:15:51 2023 +0200
>
> Fix handling of extended attributes on symlinks
>
> Closes: #1037436
>
> This fixes wrong behavior regarding extended attributes on symlinks.
> Prior versions of aide would wrongly process the extended attributes
> of the file a symlink points to. This fix makes aide correctly process
> the extended attributes of the link itself, which is the intended
> behavior.
>
> The fix for extended attributes on symlinks might lead to reported
> changed entries during the next AIDE run. You can use the
> `report_ignore_changed_attrs` option (see aide.conf(5)) to ignore
> changes of the xattrs attribute; but be aware that this will not
> only exclude the expected changes (of the symlink files) but also
> the unexpected changes (of other files).
>
> [ Other info ]
> source debdiff attached. A binary debdiff will be delivered on request.
>
> Please indicate whether this package might be a valid candidate to be in
> the next bullseye point release.
>
> Greetings
> Marc
>

Bug#1031236: ifupdown: diff for NMU version 0.8.41+nmu1

[Uwe Kleine-König]

Hello Santiago,

On 6/21/23 19:58, Santiago Ruano Rincón wrote:

El 21/06/23 a las 19:10, Uwe Kleine-König escribió:

Control: tags 1031236 + pending

Dear maintainer,

I've prepared an NMU for ifupdown (versioned as 0.8.41+nmu1) and intend
to upload it to DELAYED/10 once I properly tested the patch.
(Unfortunately I locked myself out of the affected machine while
reconfiguring the network devices. So testing will have to wait until I
find someone with physical access to that machine.)

The change is effectively what Ken Milmore proposed.


Thanks for this. Would you like to prepare a MR instead. I would like to
handle the switch to dependency on dhcpcd-base along.


Sure:
https://salsa.debian.org/debian/ifupdown/-/merge_requests/20

Best regards
Uwe

Bug#1038824: bookworm-pu: package openvpn/2.6.3-1+deb12u1

[Bernhard Schmidt]

Package: release.debian.org
Severity: normal
Tags: bookworm
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: open...@packages.debian.org
Control: affects -1 + src:openvpn

This -pu cherry-picks two fixes from upstream. One fixing a memory
leak that is noticable on long running servers, and one dangling pointer that
might lead to crashes. Both have been in 2.6.3-2 for about a month now,
migrated to testing flawlessly and are part of the recent upstream stable
release. 

There is nothing else in 2.6.3-2 that is not suitable for bookworm, I have just
changed the version and set the correct branch in gbp.conf

[ Reason ]
Bugfix

[ Impact ]
Memory leak

[ Tests ]
Upstream has an extensive testsuite/CI coverage. Part of it is ran during
build.

[ Risks ]
Isolated fixes that have been vetted upstream and have been part of an upstream
release

[ 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

Bernhard
diff -Nru openvpn-2.6.3/debian/changelog openvpn-2.6.3/debian/changelog
--- openvpn-2.6.3/debian/changelog  2023-04-13 09:19:40.0 +0200
+++ openvpn-2.6.3/debian/changelog  2023-06-21 21:41:33.0 +0200
@@ -1,3 +1,12 @@
+openvpn (2.6.3-1+deb12u1) bookworm; urgency=medium
+
+  * Cherry-pick two bugfix commits from upstream
+- Memory leak in dco_get_peer_stats_multi for Linux
+- dangling pointer passed to pkcs11-helper
+  * d/gbp.conf: set branch to bookworm
+
+ -- Bernhard Schmidt   Wed, 21 Jun 2023 21:41:33 +0200
+
 openvpn (2.6.3-1) unstable; urgency=medium
 
   * New upstream version 2.6.2
diff -Nru openvpn-2.6.3/debian/gbp.conf openvpn-2.6.3/debian/gbp.conf
--- openvpn-2.6.3/debian/gbp.conf   2023-04-13 09:19:40.0 +0200
+++ openvpn-2.6.3/debian/gbp.conf   2023-06-21 21:41:33.0 +0200
@@ -1,2 +1,3 @@
 [DEFAULT]
 pristine-tar = True
+debian-branch = debian/bookworm
diff -Nru openvpn-2.6.3/debian/patches/fix-dangling-pointer-in-pkcs11.patch 
openvpn-2.6.3/debian/patches/fix-dangling-pointer-in-pkcs11.patch
--- openvpn-2.6.3/debian/patches/fix-dangling-pointer-in-pkcs11.patch   
1970-01-01 01:00:00.0 +0100
+++ openvpn-2.6.3/debian/patches/fix-dangling-pointer-in-pkcs11.patch   
2023-06-21 21:41:33.0 +0200
@@ -0,0 +1,37 @@
+From 7e4becb4cd8be7f0d5ff80cf80877ea152f99830 Mon Sep 17 00:00:00 2001
+From: Selva Nair 
+Date: Tue, 9 May 2023 13:05:17 -0400
+Subject: [PATCH] Bugfix: dangling pointer passed to pkcs11-helper
+
+Github: Fixes OpenVPN/openvpn#323
+
+Signed-off-by: Selva Nair 
+Acked-by: Gert Doering 
+Message-Id: <20230509170517.2637245-1-selva.n...@gmail.com>
+URL: 
https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg26640.html
+Signed-off-by: Gert Doering 
+(cherry picked from commit f4850745709c5b80ab7d09c03a86c5ceea6d10a2)
+---
+ src/openvpn/pkcs11_openssl.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/src/openvpn/pkcs11_openssl.c b/src/openvpn/pkcs11_openssl.c
+index eee86e17b6f..9b0ab39f9cf 100644
+--- a/src/openvpn/pkcs11_openssl.c
 b/src/openvpn/pkcs11_openssl.c
+@@ -165,6 +165,7 @@ xkey_pkcs11h_sign(void *handle, unsigned char *sig,
+ {
+ pkcs11h_certificate_t cert = handle;
+ CK_MECHANISM mech = {CKM_RSA_PKCS, NULL, 0}; /* default value */
++CK_RSA_PKCS_PSS_PARAMS pss_params = {0};
+ 
+ unsigned char buf[EVP_MAX_MD_SIZE];
+ size_t buflen;
+@@ -203,7 +204,6 @@ xkey_pkcs11h_sign(void *handle, unsigned char *sig,
+ }
+ else if (!strcmp(sigalg.padmode, "pss"))
+ {
+-CK_RSA_PKCS_PSS_PARAMS pss_params = {0};
+ mech.mechanism = CKM_RSA_PKCS_PSS;
+ 
+ if (!set_pss_params(_params, sigalg, cert))
diff -Nru 
openvpn-2.6.3/debian/patches/fix-memleak-in-dco_get_peer_stats_multi.patch 
openvpn-2.6.3/debian/patches/fix-memleak-in-dco_get_peer_stats_multi.patch
--- openvpn-2.6.3/debian/patches/fix-memleak-in-dco_get_peer_stats_multi.patch  
1970-01-01 01:00:00.0 +0100
+++ openvpn-2.6.3/debian/patches/fix-memleak-in-dco_get_peer_stats_multi.patch  
2023-06-21 21:41:33.0 +0200
@@ -0,0 +1,33 @@
+From 5e8a571af165c867ccb9c4c9e6334620f42013ac Mon Sep 17 00:00:00 2001
+From: Frank Lichtenheld 
+Date: Mon, 15 May 2023 16:21:16 +0200
+Subject: [PATCH] DCO: fix memory leak in dco_get_peer_stats_multi for Linux
+
+Leaks a small amount of memory every 15s.
+
+Signed-off-by: Frank Lichtenheld 
+Acked-by: Antonio Quartulli 
+Message-Id: <20230515142116.33135-1-fr...@lichtenheld.com>
+URL: 
https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg26659.html
+Signed-off-by: Gert Doering 
+(cherry picked from commit 276f7c86d70666bc2ab4e6192ef5f1dcbd6a230f)
+---
+ src/openvpn/dco_linux.c | 5 -
+ 1 file changed, 4 insertions(+), 1 deletion(-)
+
+diff --git a/src/openvpn/dco_linux.c b/src/openvpn/dco_linux.c
+index 

Bug#1002997: podman: Please provide a default /etc/containers/storage.conf

[Cian Donovan]

Hi,

This completed Pull Request upstream should solve the issue of needing
to manually add a storage.conf by adjusting the defaults to use the in-
kernel overlayfs by default instead of vfs which is slow and very heavy
on disk-space.

https://github.com/containers/storage/issues/1570
https://github.com/containers/storage/pull/1571

Is there any chance this fix could be backported/cherrypicked to Debian
Stable Bookworm? It's functionally equivalent to just setting the
storage driver in a storage.conf configuration file, but is just the
default instead.

Recently moved to Bookworm and the first thing I noticed was my disk
was completely full after only running a few containers since vfs was
the default.

Kind regards,
Cian. 

Bug#1038644: nfdump: segfault if started with -R option

[Bernhard Schmidt]

On 19/06/23 05:25 PM, Yury Shevchuk wrote:

> # /usr/bin/nfcapd -D -P /var/run/nfcapd/default.pid -w /var/cache/nfdump -S1 
> -b 120.0.1 -p 2055 -R 127.0.0.2 2055
> Segmentation fault
> The patch (trivial) is attached.

Thanks. For the record, this is included in the much larger

https://github.com/phaag/nfdump/commit/abfab42419117add44e1ea15ad9559d265642219#diff-c95665baa1999e70e29344d1dc05f3282cd1cf7f31b47341581cd1cf81b7d062R593

in v1.7.2

> A minor change in /etc/init.d/nfdump conffile (added return 0) fixes false
> "failed!" message from "/etc/init.d/nfdump start" which appears on systems
> using sysvinit-core rather than systemd.

I really don't get what this code is supposed to do though. And I don't
want to invest much time into sysvinit.  From my understanding

start-stop-daemon --start --quiet \
--pidfile "$PIDFILE" --exec "$NFCAPD" --test > /dev/null \
|| return 1

First we run with --test. If start-stop-daemon returns zero (process not
already running) we continue, else we return 1. So far so good.

start-stop-daemon --start --quiet \
--pidfile "$PIDFILE" \
--exec "$NFCAPD" -- \
-D -P "$PIDFILE" \
$options \
|| return 2

Now we really start it. If we can do it we continue, if we can't we
return 2 (could not be started)

sleep 1
start-stop-daemon --start --quiet \
--pidfile "$PIDFILE" --exec "$NFCAPD" --test > /dev/null \
&& return 2

Now we basically test again if the daemon is already running. If it
isn't, we return 2, 

At this point we have checked that 1 second after the start the process
is still running, and can return 0.

Could you please try the just uploaded 1.7.1-3 to verify the fix for
both bugs?

Bernhard

Bug#1038088: raincat: Indirectly depends on SDL 1.2

[Moritz Mühlenhoff]

tags fixed-upstream
thanks

Am Thu, Jun 15, 2023 at 02:08:04PM +0100 schrieb Simon McVittie:
> Source: raincat
> Tags: trixie sid
> User: pkg-sdl-maintain...@lists.alioth.debian.org
> Usertags: libsdl1.2
> 
> This package depends on libghc-sdl-dev, which is a language binding
> for SDL 1.2. SDL 1.2 has been superseded by SDL 2 and is unmaintained
> upstream.
> 
> If possible, please port this package to SDL 2. (This would probably
> require packaging a Haskell binding for SDL 2 first.)

https://github.com/styx/Raincat mentions that the latest upstream release
has been ported to SDL2:

| Changelog
|
| Version 1.2:
|  - Ported to SDL2

Cheers,
Moritz

Bug#1037244: dhcpcd-ui: new upstream 0.7.9 release

[Leandro Cunha]

Hi Roy,

On Wed, Jun 21, 2023 at 6:13 AM Roy  wrote:
>
> dhcpcd-ui no longer uses dhcpcd-dbus
>
> The dhcpcd-ui source has libdhcpcd in the src directory which is the raw C 
> replacement.
> The dhcpcd-ui binaries such as dhcpcd-qt use it when building.
>
> Does this help answer your question?
>
> Roy
>

Yes, I already switched to dhcpcd as a dependency on that package and
with that it won't install dhcpcd-dbus anymore.
I've also asked an acquaintance of mine who is a DD to upload the
change (which I consider more urgent).
Thanks!

[1] https://tracker.debian.org/pkg/dhcpcd5
[2] 
https://salsa.debian.org/debian/dhcpcd-ui/-/commit/3ca27368227960a2d97ca4fbd1a56314546d96d3

-- 
Cheers,
Leandro Cunha

Bug#1038823: pysdl2: autopkgtest failure with SDL 2.28.0: cannot create a Renderer

[Simon McVittie]

Source: pysdl2
Version: 0.9.9+dfsg1-6
Severity: serious
Tags: fixed-upstream
Justification: https://release.debian.org/testing/rc_policy.txt 6a
X-Debbugs-CC: debian...@lists.debian.org
User: debian...@lists.debian.org
Usertags: needs-update

pysdl2's autopkgtest is failing since I uploaded libsdl2 version 2.28.0
to unstable. This appears to be a test issue, rather than a regression
in libsdl2.

An example of one of the failures:

 70s self = 
 70s
 70s def test_SDL_CreateDestroyRenderer(self):
 70s failed = 0
 70s rcount = render.SDL_GetNumRenderDrivers()
 70s for i in range(rcount):
 70s window = video.SDL_CreateWindow(b"Test", 10, 10, 10, 10,
 70s video.SDL_WINDOW_SHOWN)
 70s assert isinstance(window.contents, video.SDL_Window)
 70s renderer = render.SDL_CreateRenderer(window, i, 
self._RENDERFLAGS)
 70s if not (renderer and renderer.contents):
 70s failed += 1
 70s video.SDL_DestroyWindow(window)
 70s continue
 70s assert isinstance(renderer.contents, render.SDL_Renderer)
 70s render.SDL_DestroyRenderer(renderer)
 70s
 70s # TODO: using -1 as index for the call below leads to random
 70s # access violations on Win32
 70s renderer = render.SDL_CreateRenderer(window, i,
 70s  
render.SDL_RENDERER_SOFTWARE)
 70s >   assert isinstance(renderer.contents, render.SDL_Renderer)
 70s E   ValueError: NULL pointer access

If I hack in some extra debug, it seems that the SDL error message is
"Surface already associated with window", which is related to:

- https://github.com/pygame-community/pygame-ce/issues/2190
- https://github.com/libsdl-org/SDL/issues/7793
- https://github.com/libsdl-org/SDL/pull/7795

Briefly, SDL upstream considers it to be a programming error to attempt
to create a Renderer for a window that already has a window surface,
and some video drivers imply creation of a window surface. SDL 2.28.0
is better at detecting and diagnosing this situation than previous
releases.

pysdl2/experimental seems to have fixed the test, so I'm going to upload
that to unstable if successful.

smcv

Bug#979982: emacsen-common: emacs -batch is noisy

[Dennis Filder]

X-Debbugs-CC: Michael Hoffman 
Control: tag -1 +patch

This bug still persists, and the attached patch should fix it while
still printing informative messages in interactive mode.

I might raise the severity to "serious" at some point since the stray
output renders GNU Emacs unsuitable as a script interpreter, thus
breaking it.

Regards.
--- a/debian-startup.el
+++ b/debian-startup.el
@@ -113,7 +113,7 @@
 (mapc
  (lambda (file)
(condition-case err
-   (load file nil)
+   (load file nil noninteractive)
  (error (message "Error while loading %s: %s"
  file (error-message-string err)
  base-names)

Bug#1038822: semctl(2): access permissions are for the semaphore set, not for a shared memory segment

[Xavier Delatour]

Package: manpages-dev
Version: 6.03-2
Severity: minor
X-Debbugs-Cc: delatour.xav...@orange.fr

Dear Maintainer,

Current manpage: "The least significant 9 bits of the mode field of the
ipc_perm  structure  define the access permissions for the shared memory
segment."

Expected: "The least significant 9 bits of the mode field of the  ipc_perm
structure  define the access permissions for the semaphore set."


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

Kernel: Linux 6.1.0-9-amd64 (SMP w/4 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

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

manpages-dev recommends no packages.

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

-- no debconf information

Bug#1038821: RM: mailavenger -- RoQA; RC-buggy, unmaintained, unused

[Moritz Muehlenhoff]

Package: ftp.debian.org
Severity: normal
User: ftp.debian@packages.debian.org
Usertags: remove
X-Debbugs-Cc: mailaven...@packages.debian.org
Control: affects -1 + src:mailavenger

Please remove mailavenger. It hasn't seen an upload since four years,
is RC-buggy since years (e.g. FTBFSes since GCC 10), has missed two
stable releases and popcon is practically non-existant.

Cheers,
Moritz

Bug#1034683: r-base: new upstream release unintentionally uploaded to unstable

[Dirk Eddelbuettel]

Hi Philip,

On 21 June 2023 at 20:15, Philip Rinn wrote:
| Hi,
| 
| could we please close this bug? We released bookworm some days ago and 
| propagating to testing should be fine now. [It blocks R packages to propagate 
to 
| testing currently.]

Thanks for the reminder. I think we had informal consensus to leave it open
during the freeze leading up to the release to avoid any last minute transfer
but this can now be closed -- especially as we by now have R 4.3.1 (released
at the end of last week) in unstable. So closing now.

Best,  Dirk

| Thanks
| Philip
| x[DELETED ATTACHMENT OpenPGP_signature, application/pgp-signature]

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

Bug#1038386: get_nprocs_conf value higher than is present CPUs.

[Aurelien Jarno]

Hi,

On 2023-06-17 21:19, Junichi Uekawa wrote:
> 
> Package: libc6
> Version: 2.36-9
> 
> Documentation tells me that 
>  
>   sysconf(_SC_NPROCESSORS_CONF)
>   get_nprocs_conf()
> 
> gives me the upper bound of CPUs and 
> 
>   sysconf(_SC_NPROCESSORS_ONLN)
>   get_nprocs()
> 
> gives the currently online CPUs.
> 
> get_nprocs_conf seems to return "possible" value, and it seems like
> the value is 32 on my system.  However from reading

That is correct, at least when /sys is mounted.

> Documentation/ABI/testing/sysfs-devices-system-cpu "present" might be
> more suited instead of "possible".

> (the value used to be 12 on bullseye kernel, and bookworm kernel
> started reporting 32 for possible, which maybe possible but not very
> useful as only 12 is present on my system.)

I am not convinced about that. As you said above, the
_SC_NPROCESSORS_CONF should gives the upper bound of CPUs. Using
"present" means this is not guaranteed anymore, so a process allocating
structures for "present" CPUs might fail, because at some point there
might be more "online" CPU than "present" CPU in the past.

Of course such a thing will not happen on your laptop, but it might
happen in the context of virtualisation where CPUs could be added
dynamically (in addition to bringing some cores from offline to online).

> I think one of the following could be useful
> 
> - use "present" instead of possible for get_nprocs_conf

As said above I don't think this is correct.

> - update get_nprocs_conf to document that it's a theoretical value and not 
> the number of present cpus.

I agree this could be updated, probably using the same terminology as in
Documentation/ABI/testing/sysfs-devices-system-cpu.

> - introduce another API for the present CPUs that may or may not be online.

Adding a newer API is something possible, but needs to be coordinated
with upstream. For that the use case should be clearly defined.

Regards
Aurelien

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

Bug#1036751: RFS: mini-httpd/1.30-4 [ITA] -- Small HTTP server

[Nicholas D Steeves]

Hi Alexandru,

Thanks for the ping.  I had forgotten that I had a WIP draft.

Alexandru Mihail  writes:

>> > remember the original NCSA httpd licence. P.S. It feels like
>> > archaeology to find missing documentation for something from the > > dawn 
>> > of
>
> Eureka ! 
> I present the original NCSA httpd license in its purest form after some 
> software archeology:
> https://web.archive.org/web/20060830015540/http://hoohoo.ncsa.uiuc.edu/docs-1.5/Copyright.html

Wow, you are good at this! :D

> (NCSA HTTPd Development Team / ht...@ncsa.uiuc.edu / Last Modified 08-01-95)
> == LICENSE START ===
> NCSA HTTPd Server
> Software Development Group
> National Center for Supercomputing Applications
> University of Illinois at Urbana-Champaign
> 605 E. Springfield, Champaign IL 61820
> ht...@ncsa.uiuc.edu
>
> Copyright (C) 1995, Board of Trustees of the University of Illinois
>
> NCSA HTTPd software, both binary and source (hereafter, Software) is 
> copyrighted by The Board of Trustees of the University of Illinois (UI), and 
> ownership remains with the UI.
>
> The UI grants you (hereafter, Licensee) a license to use the Software
> for academic, research and internal business purposes only, without a
> fee.

Hmm, the above grant looks like it may not be DFSG compatible.  Do you
see how?

https://www.debian.org/social_contract#guidelines
or https://wiki.debian.org/DebianFreeSoftwareGuidelines
or with a story
https://en.wikipedia.org/wiki/Debian_Free_Software_Guidelines

> Licensee may distribute the binary and source code (if released) to third 
> parties provided that the copyright notice and this statement appears on all 
> copies and that no charge is associated with such copies.

If Rob McCool didn't ever relicense the part of NCSA HTTPd that is part
of mini-httpd, then it looks like we might need to provide this notice,
and upstream mini-httpd should have been doing so.

> Licensee may make derivative works. However, if Licensee distributes any 
> derivative work based on or derived from the Software, then Licensee will (1) 
> notify NCSA regarding its distributing of the derivative work, and (2) 
> clearly notify users that such derivative work is a modified version and not 
> the original NCSA HTTPd Server software distributed by the UI by including a 
> statement such as the following:
>
> "Portions developed at the National Center for Supercomputing 
> Applications at the University of Illinois at Urbana-Champaign." 

Is this DFSG compatible?

> Any Licensee wishing to make commercial use of the Software should contact 
> the UI, c/o NCSA, to negotiate an appropriate license for such commercial 
> use. Commercial use includes (1) integration of all or part of the source 
> code into a product for sale or license by or on behalf of Licensee to third 
> parties, or (2) distribution of the binary code or source code to third 
> parties that need it to utilize a commercial product sold or licensed by or 
> on behalf of Licensee.

And is this DFSG compatible?

> Any commercial company wishing to use the software as their commercial World 
> Wide Web server and are not redistributing the software need not commercially 
> license the software but can use it free of charge.

and this?  Note the clause "and are not redistributing the software".
So you can't sell copies of this software?

> Should we include a mention of this under debian/copyright stating
> something along the lines of 'parts of mini_httpd.c under NCSA HTTPD
> and include a copy of the license somewhere?

Most likely, yes, but the bigger issue is if this license is not
DFSG-compatible.

> As far as I could dig, this is the license which should be attributed in our 
> case. This is the 1.15 htttpd license, and with 99.% certainty, this was 
> the chunk of code still found  in mini_httpd.c. The logic is, NCSA httpd had, 
> historically, two licenses (chronologically): one open and one proprietary. 
> mini_httpd is a fork of the open one, that we can be sure of. I think there 
> is little reason to involve debian-legal at this point.
> What's your opinion here?

Thank you for the note about this history.  I didn't know NCSA httpd had
two licenses.  I wonder if there was later a change to "everything that
was 'open' is now permissively licensed" at some point?

If the chunk of code is still big enough and original enough to meet the
minimum threshold for originality, then yes, the original copyright and
license would apply; however, I think this would mean that we need to
find documentation that someone contacted the U of I (and/or Rob
McCool).

A quick query of tldrlegal shows an NCSA license that is shorter and
more permissive:
https://www.tldrlegal.com/license/university-of-illinois-ncsa-open-source-license-ncsa

I suspect that NCSA httpd may have been relicensed to this shorter
version.  Yeah, this seems to be a case where it's worth contacting
debian-legal, especially given those bits that 

Bug#1038820: transition: glibc 2.37

[Aurelien Jarno]

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

Dear release team,

I would like to get a transition slot for glibc 2.37. It has been
available in experimental for a bit more than a month and does not have
any known issue. It has been built successfully on all release
architectures and many ports architectures (technically 2.37-2 hasn't
been built yet on mipsel and mips64el due to the buildds lagging, but
2.37-1 has been built successfully).

As glibc is using symbol versioning, there is no soname change. That
said a few packages are using libc internal symbols and have to be
rebuilt for this transition. Here is the corresponding ben file:

  title = "glibc";
  is_affected = .depends ~ /libc[0-9.]* \(<

Bug#1038762: [src:systemd]: login (gnome) uses wrong keyboard layout

[Lyndon Brown]

On Wed, 2023-06-21 at 03:06 +0200, Michael Biebl wrote:
> As a quick/temporary workaround, you can run
> 
> ln -s /etc/default/keyboard /etc/vconsole.conf

Indeed removing the the latter file and creating the suggested symlink
works. Thanks.

Should it be of interest to you, the `localectl` output before doing
this was as follows:

System Locale: LANG=en_GB.UTF-8
VC Keymap: uk
   X11 Layout: (unset)

And after:

System Locale: LANG=en_GB.UTF-8
VC Keymap: (unset)
   X11 Layout: gb
X11 Model: pc105

Bug#1038611: lightdm: Lightdm fails to start X after upgrade to 1.32.0

[Yves-Alexis Perez]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Wed, 2023-06-21 at 09:40 -0300, Adilson dos Santos Dantas wrote:
> These messages are when I stop lightdm.

Ah ok.
> > 
> > 
> > Also is there something peculiar about your hardware (Nvidia/AMD GPU for
> > example?) or software (specific configuration or something).
> 
>  
> I'm using Nvidia GPU:
> 
> 01:00.0 VGA compatible controller: NVIDIA Corporation TU117 [GeForce GTX
> 1650] (rev a1)
> 
> And it is using its official drivers:
> 
> dpkg -l xserver-xorg
> Desired=Unknown/Install/Remove/Purge/Hold
> | Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-
> pend
> |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
> ||/ Nome           Versão       Arquitectura Descrição
> +++-==---
> =
> ii  xserver-xorg   1:7.7+23     amd64        X.Org X server
> 
> dpkg -l xserver-xorg-video-nvidia
> Desired=Unknown/Install/Remove/Purge/Hold
> | Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-
> pend
> |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
> ||/ Nome                      Versão       Arquitectura Descrição
> +++-=---
> =
> ii  xserver-xorg-video-nvidia 530.41.03-1  amd64        NVIDIA binary Xorg
> driver

Yup, that's likely  related. Honestly we (I) don't really support
binary/proprietary drivers. It'd help if you could test with free drivers
(nouveau or something maybe).

Regards,
- -- 
Yves-Alexis
-BEGIN PGP SIGNATURE-

iQEzBAEBCAAdFiEE8vi34Qgfo83x35gF3rYcyPpXRFsFAmSTQAAACgkQ3rYcyPpX
RFu7Ggf9FCsjsiXteQ+xDSolGEtK2a9eBlnCnI9MY3wY2OdOHJlNCpbEjamWVbw3
CwEn4//IWPgFmLcKBD1A9ySYein2tY3CDdNH5fii7ZZ/MNAlL1vuKAVuV30ayQtU
V/4xxQXgJ+1JUCPzzKNGMdLs/yumAiLGAs3XzhjUmjVPQWMRWanCOf8dFavDyFG3
4sPS6niMeFUWqM17K0ja7VPVj2QbQQSe34jec93W+zcbnxbWZZuJY9nQ2PsQjRDd
/FY0fBQtzopnZMBgRUdYNj09QGuI8kn6dZdD93+/MS2uP95ES7v1nG0bKARrGor7
pNaWlBMeMGI/+bL89SFEQdR52n/uFw==
=tTX8
-END PGP SIGNATURE-

Bug#1038819: coq-unimath: Please re-enable support for riscv64

[Aurelien Jarno]

Source: coq-unimath
Version: 20230420-3
Severity: important
User: debian-ri...@lists.debian.org
Usertags: riscv64

Dear maintainer,

According to the changelog, coq-unimath version 20230420-3 dropped
support for 32-bit architectures, but at the same time also dropped
support for a few 64-bit architectures. At least riscv64 was building
fine before that change:

https://buildd.debian.org/status/logs.php?pkg=coq-unimath=riscv64

Therefore, could you please re-enable the build on riscv64?

Thanks,
Aurelien

Bug#1038812: ITP: sexp -- S-expressions parser and generator C++ library and command-line tool

[Victor Westerhuis]

Hi Daniel, 

Daniel Kahn Gillmor  schreef op 21 juni 2023 18:20:52 
CEST:
>Package: wnpp
>Severity: wishlist
>Owner: Daniel Kahn Gillmor 
>X-Debbugs-Cc: debian-de...@lists.debian.org, d...@fifthhorseman.net
>
>* Package name: sexp
>  Version : 0.8.5
>  Upstream Contact: Maxim Samsonov 
>* URL : https://github.com/rnp/sexp
This link does not work for me, it gives a 404 error. 
>* License : MIT
>  Programming Lang: C++
>  Description : S-expressions parser and generator C++ library and 
> command-line tool
>
>S-expressions are data structures fr representing complex data as a
>variation on LISP S-Expressions.  They are similar to (but older than)
>JSON.  There are a handful of variations in format and
>canonicalization that it can be useful to translate between, and to
>abstract away from.
>
>This C++ library inherits from the the original canonical MIT-licensed
>s-expression code offered by Rivest and Lampson, and is augmented to
>include parsing capabilities for extensions made by the GnuPG project.
>
>This library is used by the current upstream version of librnp
>(Ribose's OpenPGP implementation), for the purpose of interoperability
>with GnuPG's local file storage.
>


-- 
Groet, Regards,

Victor Westerhuis

Bug#1034683: r-base: new upstream release unintentionally uploaded to unstable

[Philip Rinn]

Hi,

could we please close this bug? We released bookworm some days ago and 
propagating to testing should be fine now. [It blocks R packages to propagate to 
testing currently.]


Thanks
Philip


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1038818: grub-pc: Empty device (??? MB) in list during postinst with ZFS on / or /boot

[Louis Sautier]

Package: grub-pc
Version: 2.06-13

Hi,
When ZFS is used for the / or /boot partitions on legacy boot servers 
(with vdevs using more than one disk/partition), grub-pc's postinst 
shows this during the configure phase:


    ┌──┤ Configuring grub-pc ├──┐
    │ GRUB install devices: │
    │   │
    │  [*] /dev/sda (240057 MB; SAMSUNG_MZ7LM240HMHQ-5) │
    │  [*] /dev/sdb (240057 MB; SAMSUNG_MZ7LM240HMHQ-5) │
    │  [ ] (??? MB; ???)    │
    │  [ ] /dev/md2 (1071 MB; md2)  │
    │   │
    │   │
    │  │
    │   │
    └───┘

Along with errors:

Unknown device "/dev/": No such device


To reproduce, on a legacy boot server:
* Create a zpool with a mirror vdev using two partitions.
* Create a dataset and use it as /.
* Install Debian Bookworm on the server.
* Run "dpkg-reconfigure grub-pc".

On my test server:
root@localhost:~# df -hT
Filesystem Type  Size  Used Avail Use% Mounted on
udev   devtmpfs  7.8G 0  7.8G   0% /dev
tmpfs  tmpfs 1.6G  820K  1.6G   1% /run
zp0/zd0    zfs   216G  1.5G  214G   1% /
tmpfs  tmpfs 7.8G 0  7.8G   0% /dev/shm
tmpfs  tmpfs 5.0M 0  5.0M   0% /run/lock
/dev/md2   ext4  988M   66M  855M   8% /boot
tmpfs  tmpfs 1.6G 0  1.6G   0% /run/user/1000
root@localhost:~# lsblk -f
NAME    FSTYPE    FSVER    LABEL 
UUID FSAVAIL FSUSE% MOUNTPOINTS

sda
├─sda1
├─sda2  linux_raid_member 1.2  md2 
371c03a8-59c4-5eb7-7fda-f6f5497ae463
│ └─md2 ext4  1.0  boot 
197e5606-e75e-4809-87f9-13fbc42ed36d  854.7M 7% /boot

├─sda3  zfs_member    5000 zp0 8324519610909055574
├─sda4  swap  1    swap-sda4 
08d6106d-f50d-4391-8515-5b2b8ffa1d6b    [SWAP]

└─sda5  iso9660   Joliet Extension config-2 2023-06-16-18-40-55-00
sdb
├─sdb1
├─sdb2  linux_raid_member 1.2  md2 
371c03a8-59c4-5eb7-7fda-f6f5497ae463
│ └─md2 ext4  1.0  boot 
197e5606-e75e-4809-87f9-13fbc42ed36d  854.7M 7% /boot

├─sdb3  zfs_member    5000 zp0 8324519610909055574
└─sdb4  swap  1    swap-sdb4 
55b30849-9949-4da0-9738-43e04b40a220    [SWAP]

root@localhost:~# zfs list
NAME  USED  AVAIL REFER  MOUNTPOINT
zp0  1.42G   214G   24K  none
zp0/zd0  1.42G   214G 1.42G  /
root@localhost:~# zpool list
NAME   SIZE  ALLOC   FREE  CKPOINT  EXPANDSZ   FRAG    CAP DEDUP    
HEALTH  ALTROOT
zp0    222G  1.42G   221G    - - 0% 0% 1.00x    
ONLINE  -

root@localhost:~# zpool status
  pool: zp0
 state: ONLINE
config:

    NAME    STATE READ WRITE CKSUM
    zp0 ONLINE   0 0 0
  mirror-0  ONLINE   0 0 0
    sda3    ONLINE   0 0 0
    sdb3    ONLINE   0 0 0

errors: No known data errors
root@localhost:~# cat /etc/fstab
UUID=197e5606-e75e-4809-87f9-13fbc42ed36d    /boot    ext4  defaults   
 0    0
UUID=08d6106d-f50d-4391-8515-5b2b8ffa1d6b    swap    swap  defaults   
 0    0
UUID=55b30849-9949-4da0-9738-43e04b40a220    swap    swap  defaults   
 0    0

root@localhost:~# dpkg-reconfigure grub-pc
# With set -x / set +x added around line 281 of 
/var/lib/dpkg/info/grub-pc.postinst

+++ grub-probe -t device /
++ partition='/dev/sda3
/dev/sdb3'
++ set +x
+++ grub-probe -t device /boot
++ partition=/dev/md2
++ set +x
+++ grub-probe -t device /boot/grub
++ partition=/dev/md2
++ set +x
Unknown device "/dev/": No such device
Unknown device "/dev/": No such device
Unknown device "/dev/": No such device
Unknown device "/dev/": No such device
grub-pc: Running grub-install ...
Installing for i386-pc platform.

Installation finished. No error reported.
  grub-install success for /dev/sda
Installing for i386-pc platform.
Installation finished. No error reported.
  grub-install success for /dev/sdb
Generating grub configuration file ...
Found linux image: /boot/vmlinuz-6.1.0-9-amd64
Found initrd image: /boot/initrd.img-6.1.0-9-amd64
done

My understanding is that the following happens:

* usable_partitions is called: 
https://salsa.debian.org/grub-team/grub/-/blob/debian/2.06-13/debian/postinst.in#L275
* partition="$(grub-probe -t device "$path" || true)" is called: 
https://salsa.debian.org/grub-team/grub/-/blob/debian/2.06-13/debian/postinst.in#L281

* It returns this:
  # grub-probe -t device /
  /dev/sda3
  /dev/sdb3
* partition_id="$(device_to_id "$partition" || true)" 

Bug#1031236: ifupdown: diff for NMU version 0.8.41+nmu1

[Santiago Ruano Rincón]

El 21/06/23 a las 19:10, Uwe Kleine-König escribió:
> Control: tags 1031236 + pending
> 
> Dear maintainer,
> 
> I've prepared an NMU for ifupdown (versioned as 0.8.41+nmu1) and intend
> to upload it to DELAYED/10 once I properly tested the patch.
> (Unfortunately I locked myself out of the affected machine while
> reconfiguring the network devices. So testing will have to wait until I
> find someone with physical access to that machine.)
> 
> The change is effectively what Ken Milmore proposed.

Thanks for this. Would you like to prepare a MR instead. I would like to
handle the switch to dependency on dhcpcd-base along.

Cheers,

 -- Santiago


signature.asc
Description: PGP signature

Bug#1038817: RM: dmtcp -- RoQA; unmaintained, RC-buggy

[Moritz Muehlenhoff]

Package: ftp.debian.org
Severity: normal
User: ftp.debian@packages.debian.org
Usertags: remove
X-Debbugs-Cc: dm...@packages.debian.org
Control: affects -1 + src:dmtcp

Please remove dmtcp. It's RC-buggy for a long time, there was only
a single upload by the new maitainer in 2019 and never made it
into a stable release. It's one of the last packages depending on
the removed Python 2.

Bug#1038814: RFP: python-mt-940 -- MT940 banking files parser

[Bastian Germann]

Also, please exclude the test files from the binary package.

Bug#1038816: RM: git-notifier -- RoQA; Depends on Python 2, unmaintained

[Moritz Muehlenhoff]

Package: ftp.debian.org
Severity: normal
User: ftp.debian@packages.debian.org
Usertags: remove
X-Debbugs-Cc: git-notif...@packages.debian.org
Control: affects -1 + src:git-notifier

Please remove git-notifier. It hasn't seen an upload since 2015, missed
two stable releases and is one of the last packages still depending on
the removed Python 2.

Cheers,
Moritz

Bug#1038814: RFP: python-mt-940 -- MT940 banking files parser

[Bastian Germann]

Hi Matthias,

On Wed, 21 Jun 2023 19:12:51 +0200 Bastian Germann wrote:

* Package name: python-mt-940
   Upstream Author : Rick van Hattem (Wolph) 
* URL : https://github.com/wolph/mt940
* License : BSD-3-clause
   Programming Lang: Python
   Description : python library parser for MT940 banking files

A library to parse MT940 files and returns smart Python collections for 
statistics and manipulation.


Please work on https://salsa.debian.org/python-team/packages/python-mt-940.
The docs package has to be created properly.

Thanks,
Bastian

Bug#1038815: xfce4-settings: Please expose keyboard layout management setting in Settings Manager

[Celejar]

Package: xfce4-settings
Version: 4.18.2-1
Severity: wishlist
Tags: upstream

Hello,

I've been using Xfce4 for years, with multiple keyboard layouts. Until
recently, the layouts were managed globally, across applications;
recently, this somehow switched to per application - I don't know why.
When I eventually realized what was going on, I looked for a setting
that controlled this, and it seems that such a configuration knob is
only available via the Properties of the Xfce4 xkb plugin. I suggest
that this setting be exposed in the Keyboard section of the Settings
Manager.

https://askubuntu.com/questions/938103/xubuntu-17-04-different-keyboard-layout-for-each-window

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

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

Versions of packages xfce4-settings depends on:
ii  exo-utils4.18.0-1
ii  libatk1.0-0  2.48.3-1
ii  libc62.36-9
ii  libcairo-gobject21.16.0-7
ii  libcairo21.16.0-7
ii  libcolord2   1.4.6-2.2
ii  libexo-2-0   4.18.0-1
ii  libfontconfig1   2.14.1-4
ii  libgarcon-1-04.18.1-1
ii  libgarcon-common 4.18.1-1
ii  libgdk-pixbuf-2.0-0  2.42.10+dfsg-1+b1
ii  libglib2.0-0 2.74.6-2
ii  libgtk-3-0   3.24.37-2
ii  libnotify4   0.8.2-1
ii  libpango-1.0-0   1.50.14+ds-1
ii  libpangocairo-1.0-0  1.50.14+ds-1
ii  libupower-glib3  0.99.20-2
ii  libx11-6 2:1.8.6-1
ii  libxcursor1  1:1.2.1-1
ii  libxfce4ui-2-0   4.18.4-1
ii  libxfce4util74.18.1-2
ii  libxfconf-0-34.18.1-1
ii  libxi6   2:1.8-1+b1
ii  libxklavier165.4-4
ii  libxrandr2   2:1.5.2-2+b1
ii  xfce4-helpers4.18.2-1
ii  xfconf   4.18.1-1

Versions of packages xfce4-settings recommends:
ii  colord 1.4.6-2.2
ii  x11-utils  7.7+5
ii  xiccd  0.3.0-2

xfce4-settings suggests no packages.

-- no debconf information

Bug#946879: git: please build package with libsecret credential helper

[Matt Hickford]

Brian’s patch looks good to me. Jonathan, is there any obstacle to merging?

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=946879#21

Bug#1031236: ifupdown: diff for NMU version 0.8.41+nmu1

[Uwe Kleine-König]

Control: tags 1031236 + pending

Dear maintainer,

I've prepared an NMU for ifupdown (versioned as 0.8.41+nmu1) and intend
to upload it to DELAYED/10 once I properly tested the patch.
(Unfortunately I locked myself out of the affected machine while
reconfiguring the network devices. So testing will have to wait until I
find someone with physical access to that machine.)

The change is effectively what Ken Milmore proposed.

Best regards
Uwe
diff -Nru ifupdown-0.8.41/debian/changelog ifupdown-0.8.41+nmu1/debian/changelog
--- ifupdown-0.8.41/debian/changelog	2023-01-24 14:07:32.0 +0100
+++ ifupdown-0.8.41+nmu1/debian/changelog	2023-06-21 18:18:20.0 +0200
@@ -1,3 +1,12 @@
+ifupdown (0.8.41+nmu1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix if-up.d/resolved hook to properly work with nameservers and search
+domains. Thanks to Dmytro Kolesnykov and Ken Milmore for the bug report
+and a proposed patch. (Closes: #1031236)
+
+ -- Uwe Kleine-König   Wed, 21 Jun 2023 18:18:20 +0200
+
 ifupdown (0.8.41) unstable; urgency=high
 
   * networking.service: Improve how to handle hotplug devices. Thanks to kibi,
diff -Nru ifupdown-0.8.41/debian/if-up.d/resolved ifupdown-0.8.41+nmu1/debian/if-up.d/resolved
--- ifupdown-0.8.41/debian/if-up.d/resolved	2022-12-09 21:37:03.0 +0100
+++ ifupdown-0.8.41+nmu1/debian/if-up.d/resolved	2023-06-21 18:17:47.0 +0200
@@ -43,11 +43,11 @@
 fi
 if  [ -n "$NEW_DNS" ]; then
 cat <"$mystatedir/ifupdown-${ADDRFAM}-$interface"
-"$DNS"="$NEW_DNS"
+$DNS="$NEW_DNS"
 EOF
 if  [ -n "$NEW_DOMAINS" ]; then
 cat <>"$mystatedir/ifupdown-${ADDRFAM}-$interface"
-"$DOMAINS"="$NEW_DOMAINS"
+$DOMAINS="$NEW_DOMAINS"
 EOF
 fi
 fi
@@ -66,7 +66,7 @@
 # ignore errors due to nonexistent file
 md5sum "$mystatedir/isc-dhcp-v4-$interface" "$mystatedir/isc-dhcp-v6-$interface" "$mystatedir/ifupdown-inet-$interface" "$mystatedir/ifupdown-inet6-$interface" > "$newstate" 2> /dev/null || true
 if ! cmp --silent "$oldstate" "$newstate" 2>/dev/null; then
-DNS DNS6 DOMAINS DOMAINS6 DEFAULT_ROUTE
+unset DNS DNS6 DOMAINS DOMAINS6 DEFAULT_ROUTE
 # v4 first
 if [ -e "$mystatedir/isc-dhcp-v4-$interface" ]; then
 . "$mystatedir/isc-dhcp-v4-$interface"


signature.asc
Description: PGP signature

Bug#1038814: RFP: python-mt-940 -- MT940 banking files parser

[Bastian Germann]

Package: wnpp
Severity: wishlist
X-Debbugs-Cc: debian-de...@lists.debian.org, debian-pyt...@lists.debian.org
Control: block 1024494 by -1

* Package name: python-mt-940
  Upstream Author : Rick van Hattem (Wolph) 
* URL : https://github.com/wolph/mt940
* License : BSD-3-clause
  Programming Lang: Python
  Description : python library parser for MT940 banking files

A library to parse MT940 files and returns smart Python collections for 
statistics and manipulation.

Bug#984879: podman does not work on Debian with selinux loaded

[Sam Morris]

On Wed, Jun 21, 2023 at 05:28:48PM +0100, Sam Morris wrote:
> refpolicy has a 'container' module that appears to work, it's just not
> built by default.

BTW, the existance of /etc/selinux/default/contexts/lxc_contexts is what
causes Podman to try to label containers. Which prevents it from being
able to start any container, since the container module is not
included in selinux-policy-default.

https://sources.debian.org/src/golang-github-opencontainers-selinux/1.10.0+ds1-1/go-selinux/selinux_linux.go/?hl=943#L943

> Any chance that module could be built by default?

So if the module is not suitable to be built by default, please remove
the `lxc_contexts` file; I have the feeling it might also cause problems
with libvirt and k8s...

https://sources.debian.org/src/libvirt/9.0.0-4/src/security/security_selinux.c/?hl=650#L650

https://sources.debian.org/src/kubernetes/1.20.5+really1.20.2-1.1/vendor/github.com/opencontainers/selinux/go-selinux/selinux_linux.go/?hl=887#L887

-- 
Sam Morris 
PGP: rsa4096/CAAA AA1A CA69 A83A 892B  1855 D20B 4202 5CDA 27B9

Bug#1038813: bullseye-pu: package aide/0.17.3-4+deb11u2

[Marc Haber]

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

Dear stable releas team,

this pre-upload request for the aide package is filed to ask for
guidance whether this package is suitable for bullseye-proposed-updates.
I have never done this before and am open for suggestions to improve and
for documentation pointers.

A fixed package has recently migrated to testing, the corresponding
bookworm request is #1037945.

[ Reason ]
This update fixes #1037436, a "just" important bug that causes incorrect
processing of extended attributes on symlinks that are monitored by
aide. This is a fix suggested by upstream (who is also a DD).

[ Impact ]
Without this fix, Aide will wrongly process extended attributes for
the file a symlink points to, which is not the intended behavior. The
fixed aide will process the extended attributes of a symlink.

[ Tests ]
This bug is sadly not covered by automated tests. I created a symlink
with extended attributes pointing to a file with different extended
attributes and verified that actually the extended attributes of the
symlink show up in the database.

[ Risks ]
Risks are that I goofed up in the fixes.

[ 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 ]
commit b1d036a82a336836f05ed0d6dcb0b4bab6c7501f (HEAD -> bullseye)
Author: Marc Haber 
Date:   Wed Jun 21 18:29:23 2023 +0200

prepare upload to bullseye

Git-Dch: ignore

commit 60e63ac4052724be4a2b078940e266e835e89bf7
Author: Marc Haber 
Date:   Wed Jun 21 18:27:56 2023 +0200

refresh patch for bullseye

Git-Dch: ignore

commit f2912c100a5d3d9b37d4ab9318d5b8b9bf45025c
Author: Marc Haber 
Date:   Wed Jun 14 04:15:51 2023 +0200

Fix handling of extended attributes on symlinks

Closes: #1037436

This fixes wrong behavior regarding extended attributes on symlinks.
Prior versions of aide would wrongly process the extended attributes
of the file a symlink points to. This fix makes aide correctly process
the extended attributes of the link itself, which is the intended
behavior.

The fix for extended attributes on symlinks might lead to reported
changed entries during the next AIDE run. You can use the
`report_ignore_changed_attrs` option (see aide.conf(5)) to ignore
changes of the xattrs attribute; but be aware that this will not
only exclude the expected changes (of the symlink files) but also
the unexpected changes (of other files).

[ Other info ]
source debdiff attached. A binary debdiff will be delivered on request.

Please indicate whether this package might be a valid candidate to be in
the next bullseye point release.

Greetings
Marc

Bug#984879: podman does not work on Debian with selinux loaded

[Sam Morris]

On Thu, May 13, 2021 at 10:14:38AM +0200, Laurent Bigonville wrote:
> From a SELinux policy perspective, the main problem is that the "container"
> policy is 100% Red Hat specific and has not been upstreamed and the
> difficulty is that the RH SELinux policy is heavily patched compared to the
> debian and upstream one.

Hi folks,

refpolicy has a 'container' module that appears to work, it's just not
built by default.

Steps taken to test it:

 1. Edit debian/modules.conf.default, adding 'container = module'
 2. Run 'debian/rules build-default-policy'
 3. Run 'semodule -i debian/build-default/container.pp'
 4. Start a container with 'podman run --rm -it docker.io/library/debian:11 
sleep inf'
 5. Check the context of the sleep process with 'ps -Z '

Any chance that module could be built by default?

-- 
Sam Morris 
PGP: rsa4096/CAAA AA1A CA69 A83A 892B  1855 D20B 4202 5CDA 27B9

Bug#1037306: ITP: apycula -- Tools to generate Gowin FPGA bitstreams

[Daniel Gröber]

Hi Simon,

I still haven't heard back since last week. Are you still interested in
sponsoring nextpnr related packages?

Since my last mail I've finished the prjtrellis integration so everything
should be ready for the first upload.

https://salsa.debian.org/electronics-team/apycula
https://salsa.debian.org/electronics-team/prjtrellis

Thanks,
--Daniel

Bug#1025075: faraday-typhoeus adapter to support faraday 2.0

[Pirate Praveen]

Control: forwarded -1 https://github.com/typhoeus/typhoeus/issues/717

On Sat, 10 Dec 2022 00:33:23 +0530 Vinay  
wrote:
> Since this is an upstream issue we need to wait until typhoeus 
updates

> to faraday 2.0
>
> https://github.com/typhoeus/typhoeus/issues/686
>
> faraday-typhoeus 2 adapter for typhoeus ->
> https://github.com/dleavitt/faraday-typhoeus

faraday should be replaced with faraday-typhoeus in tests
https://github.com/typhoeus/typhoeus/issues/717

Bug#1038789: Enable capabilities feature

[Mark Hindley]

[Cc dpkg maintainers]

Dennis,

Many thanks for this suggestion. I appreciate the advantages of capabilities
support.

However, the Debian packaging of openrc specifically excludes the openrc version
of start-stop-daemon[1] meaning systems continue to use src:dpkg's
start-stop-daemon. As far as I can tell that decision was taken because the 2
versions have slightly different options and syntax. It is difficult to be sure
that using the version from openrc would not cause problems with some
initscripts.

Openrc also has optional capabilities support in supervise-daemon which might be
an advantage to users, but isn't used by default in Debian.

It might be worth exploring adding capabilities support to src:dpkg
start-stop-daemon. Maybe the src:openrc code would be a starting point. I
haven't looked how much the two codebases have diverged.

Guillem,

What do you think?

Best wishes

Mark

[1]  https://salsa.debian.org/debian/openrc/-/blob/debian/debian/rules#L21

Bug#1038812: ITP: sexp -- S-expressions parser and generator C++ library and command-line tool

[Daniel Kahn Gillmor]

Package: wnpp
Severity: wishlist
Owner: Daniel Kahn Gillmor 
X-Debbugs-Cc: debian-de...@lists.debian.org, d...@fifthhorseman.net

* Package name: sexp
  Version : 0.8.5
  Upstream Contact: Maxim Samsonov 
* URL : https://github.com/rnp/sexp
* License : MIT
  Programming Lang: C++
  Description : S-expressions parser and generator C++ library and 
command-line tool

S-expressions are data structures fr representing complex data as a
variation on LISP S-Expressions.  They are similar to (but older than)
JSON.  There are a handful of variations in format and
canonicalization that it can be useful to translate between, and to
abstract away from.

This C++ library inherits from the the original canonical MIT-licensed
s-expression code offered by Rivest and Lampson, and is augmented to
include parsing capabilities for extensions made by the GnuPG project.

This library is used by the current upstream version of librnp
(Ribose's OpenPGP implementation), for the purpose of interoperability
with GnuPG's local file storage.

Bug#1038811: general: Unable to poweroff and suspend after upgrading to Debian 12 from Debian 11

[Johannes Wülk]

Package: general
Severity: important
X-Debbugs-Cc: bete...@web.de

Dear Maintainer,

   * What led up to the situation?
After upgrading to Debian 12 bookworm from Debian 11 I couldn't
shutdown or suspend anymore because of several components waiting
indefinitely like f.i.
- kvm authentication preventing shutdown
- systemd-udevd (waiting for process 405)
- modprobe (waiting for process modprobe 572)
- Booting up was also taking much longer than on Debian 11 because
of "ifupdown" package searching for entropy.
 
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
I tried downgrading affected packages and also disabling
services at boot - no success.
I upgraded my BIOS on my Thinkpad W540 - still same problem.
What led to success: Booting with lower/older Kernel solved it and 
everything works smoothly from then - Setting default Kernel: 5.10.0-23-amd64 
(instead of 6.1)
 
   * What was the outcome of this action?
Poweroff and suspend works smoothly like in previous Debian. I
no longer have to forcibly shut down my machine by interruption
of power.
Booting works fast again.
 
   * What outcome did you expect instead?
I expected everything to work with the new Kernel 6.1. Downgrading the 
kernel was my last resort. How is 6.1 an LTS when these issues are present?
 
 
Regards,
Johannes Wülk

Bug#1038810: RM: libsys-gamin-perl -- RoQA; depends on unmaintained gamin, no rdeps

[Simon McVittie]

Package: ftp.debian.org
Severity: normal
User: ftp.debian@packages.debian.org
Usertags: remove
X-Debbugs-Cc: libsys-gamin-p...@packages.debian.org
Control: affects -1 + src:libsys-gamin-perl

libsys-gamin-perl is an interface to Gamin, an unmaintained file access
monitor implementation.

Chris Hofstaedtler suggested that it should be removed more than 2 years
ago (#982088), and there has been no response to that bug. Now that
bookworm has been released, I think it's time to look at removing gamin,
which requires removing libsys-gamin-perl first.

I've confirmed that nothing in Debian has a dependency on this Perl
binding.

smcv

Bug#982088: libsys-gamin-perl: Please consider removal

[Simon McVittie]

Control: severity -1 serious
Control: block 1008205 by -1

> libsys-gamin-perl is, as you know, an interface to Gamin, a file access
> monitor implementation. Now, Gamin itself is mostly unmaintained, and
> only a handful of packages still need it. At a later time, I think we
> would want to remove it - see message #10 in #885011.
>
> libsys-gamin-perl currently has no reverse dependencies, so it could
> probably just go away?

I think it's time for this package to be removed. I'll open a ftp team bug.

smcv

Bug#1038809: doodle: Depends on unmaintained gamin

[Simon McVittie]

Source: doodle
Severity: important
Tags: trixie sid
User: pkg-gnome-maintain...@lists.alioth.debian.org
Usertags: oldlibs
Control: block 1008205 by -1

This package has a Depends or Build-Depends on gamin, which is unmaintained
upstream (see #1008205).

The Linux kernel's inotify interface is a good replacement.

We shouldn't really be shipping gamin in Debian 13, so this is likely to
become release-critical in future.

Thanks,
smcv

Bug#1038808: courier: Depends on unmaintained gamin

[Simon McVittie]

Source: courier
Severity: important
Tags: trixie sid
User: pkg-gnome-maintain...@lists.alioth.debian.org
Usertags: oldlibs
Control: block 1008205 by -1

This package has a Depends or Build-Depends on gamin, which is unmaintained
upstream (see #1008205).

The Linux kernel's inotify interface is a good replacement.

We shouldn't really be shipping gamin in Debian 13, so this is likely to
become release-critical in future.

Thanks,
smcv

Bug#1038807: codeblocks: Depends on unmaintained gamin

[Simon McVittie]

Package: codeblocks-contrib
Severity: important
Tags: trixie sid
User: pkg-gnome-maintain...@lists.alioth.debian.org
Usertags: oldlibs
Control: block 1008205 by -1

This package has a dependency on gamin, which is unmaintained upstream
(see #1008205).

For software that already depends on GLib (like this package), GFileMonitor
(g_file_monitor_file(), g_file_monitor_directory(), g_file_monitor())
is a good replacement.

We shouldn't really be shipping gamin in Debian 13, so this is likely to
become release-critical in future.

Thanks,
smcv

Bug#1038806: apachetop: Depends on unmaintained gamin

[Simon McVittie]

Source: apachetop
Severity: important
Tags: trixie sid
User: pkg-gnome-maintain...@lists.alioth.debian.org
Usertags: oldlibs
Control: block 1008205 by -1

This package has a Depends or Build-Depends on gamin, which is unmaintained
upstream (see #1008205).

The Linux kernel's inotify interface is a good replacement.

We shouldn't really be shipping gamin in Debian 13, so this is likely to
become release-critical in future.

Thanks,
smcv

Bug#1038805: gnubiff: Depends on unmaintained gamin

[Simon McVittie]

Source: gnubiff
Severity: important
Tags: trixie sid
User: pkg-gnome-maintain...@lists.alioth.debian.org
Usertags: oldlibs
Control: block 1008205 by -1

This package has a Depends or Build-Depends on gamin, which is unmaintained
upstream (see #1008205).

For software that already depends on GLib, GFileMonitor
(g_file_monitor_file(), g_file_monitor_directory(), g_file_monitor())
is a good replacement.

We shouldn't really be shipping gamin in Debian 13, so this is likely to
become release-critical in future.

Thanks,
smcv

Bug#918914: add -fstack-clash-protection to default buildflags

[Moritz Mühlenhoff]

Am Fri, May 27, 2022 at 09:48:05AM +0200 schrieb Guillem Jover:
> I don't think the issues presented by Florian were ever resolved, so
> my concerns in https://bugs.debian.org/918914#15 would still apply,
> even though Ubuntu has enabled this, but they have a different set of
> architectures.

I worked with Lucas last month who made an archive rebuild on amd64, the list
of FTBFSes is very small: http://qa-logs.debian.net/2023/05/24/

Since dpkg-buildflags supports different flags per arch, my proposal to be
posted to debian-devel would be to initially enable this for amd64 only
and solicit feedback from porters for other archs. Based on their feedback
this can then be enabled for amd64 and the other archs deemed compatible.

Cheers,
Moritz

Bug#1021292: Enabling branch protection on amd64 and arm64

[Emanuele Rocca]

Hey Moritz,

On 2022-10-26 08:20, Moritz Mühlenhoff wrote:
> I think this should rather be applied early after the Bookworm
> release (and ideally we can also finish off the necessary testing
> and add -fstack-clash-protection at least for amd64 and other archs
> which are ready for it (#918914)).

Can we go ahead with the dpkg patch now, any specific tests you had in
mind before applying it?

  ema

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

[Petter Reinholdtsen]

The upload to contrib / experimental was rejected by the ftpmasters with
the following comment:

> can you please explain how I can recreate the files *.tiktoken?  There
> seem to be some sources missing ...

The two files in question are 50k lines of ASCII text that seem to be
some kind of index / vocabulary, and I have no idea how they were
created.  I suspect they might be an artifact of the model training, but
do not know.  Anyone got a clue to spare on how these were created and
how to rebuild them?  If we lack the source to rebuild them, I currently
believe the whisper package will have to go to non-free, not contrib.
Any help to figure this out would be most appreciated.

-- 
Happy hacking
Petter Reinholdtsen

Bug#1038446: linux-image-6.1.0-9-amd64: hangs on "SGX disabled by BIOS" with _ at the bottom

[dino . slavik]

Package: src:linux
Followup-For: Bug #1038446

Dear Maintainer, yesterday, as usual, after closing all the programs, I turned
off the computer through the start button (I'm writing about this just in case,
because I've met people who just turn it off with the button on the case...).
However, today, when I decided to start it up, everything was stuck with the
text "SGX disabled by BIOS" and the _ symbol below. It used to happen before,
but it didn't last more than 1-2 seconds, but this time it lasted for 5-10
minutes, so I decided that something was wrong. I tried to restart using the
corresponding button on the case (since there was no other choice,
"Alt+Ctrl+F2" and other "F" didn't work), but nothing worked. In the end,
everything worked when I started from GRUB with version 6.1.0-5 (from which I
am writing about this). I don't usually do anything without googling it, so I
haven't tried anything with this yet, so I immediately started looking for
similar problems, but I didn't find anything, so I decided to write here.

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

   * What led up to the situation?
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
   * What was the outcome of this action?
   * What outcome did you expect instead?

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


-- Package-specific info:
** Kernel log: boot messages should be attached

** Model information
sys_vendor: Gigabyte Technology Co., Ltd.
product_name: Z490M
product_version: -CF
chassis_vendor: Default string
chassis_version: Default string
bios_vendor: American Megatrends Inc.
bios_version: F5
board_vendor: Gigabyte Technology Co., Ltd.
board_name: Z490M
board_version: x.x

** Network interface configuration:
*** /etc/network/interfaces:

source /etc/network/interfaces.d/*

auto lo
iface lo inet loopback

** PCI devices:
00:00.0 Host bridge [0600]: Intel Corporation Comet Lake-S 6c Host Bridge/DRAM 
Controller [8086:9b53] (rev 05)
DeviceName: Onboard - Other
Subsystem: Gigabyte Technology Co., Ltd Comet Lake-S 6c Host 
Bridge/DRAM Controller [1458:5000]
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- 
SERR- 
Kernel driver in use: skl_uncore

00:01.0 PCI bridge [0604]: Intel Corporation 6th-10th Gen Core Processor PCIe 
Controller (x16) [8086:1901] (rev 05) (prog-if 00 [Normal decode])
Subsystem: Gigabyte Technology Co., Ltd 6th-10th Gen Core Processor 
PCIe Controller (x16) [1458:5000]
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- 
SERR- TAbort- 
Reset- 
FastB2B-
PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
Capabilities: 
Kernel driver in use: pcieport

00:02.0 Display controller [0380]: Intel Corporation CometLake-S GT2 [UHD 
Graphics 630] [8086:9bc5] (rev 05)
DeviceName: Onboard - Video
Subsystem: Gigabyte Technology Co., Ltd CometLake-S GT2 [UHD 
Graphics 630] [1458:d000]
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- 
SERR- 
Kernel driver in use: i915
Kernel modules: i915

00:12.0 Signal processing controller [1180]: Intel Corporation Comet Lake PCH 
Thermal Controller [8086:06f9]
DeviceName: Onboard - Other
Subsystem: Gigabyte Technology Co., Ltd Comet Lake PCH Thermal 
Controller [1458:]
Control: I/O- Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- 
SERR- 
Kernel driver in use: intel_pch_thermal
Kernel modules: intel_pch_thermal

00:14.0 USB controller [0c03]: Intel Corporation Comet Lake USB 3.1 xHCI Host 
Controller [8086:06ed] (prog-if 30 [XHCI])
DeviceName: Onboard - Other
Subsystem: Gigabyte Technology Co., Ltd Comet Lake USB 3.1 xHCI 
Host Controller [1458:5007]
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- 
SERR- 
Kernel driver in use: xhci_hcd
Kernel modules: xhci_pci

00:14.2 RAM memory [0500]: Intel Corporation Comet Lake PCH Shared SRAM 
[8086:06ef]
DeviceName: Onboard - Other
Subsystem: Intel Corporation Comet Lake PCH Shared SRAM [8086:7270]
Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- 
SERR- 

00:16.0 Communication controller [0780]: Intel Corporation Comet Lake 

Bug#1038804: libxml++2.6: Old ABI, not recommended for new applications

[Simon McVittie]

Source: libxml++2.6
Severity: normal
Tags: upstream wontfix

libxml++2.6 is documented on its upstream website
 as:

> libxml++-2.6: Old ABI, not recommended for new applications. Uses
> Glib::ustring from the glibmm-2.4 ABI.

The suggested replacement is one of the newer, parallel-installable
versions libxml++-3.0, libxml++-4.0 or libxml++-5.0.

If someone wants to package one of those (as requested in #819562)
then they should be a separate source package, similar to the relationship
between GTK 2, 3 and 4. As a result I'm marking this bug as wontfix:
it will never be fixed *in the libxml++2.6 package*.

smcv

Bug#1038803: ffcall: FTBFS on riscv64

[Bo YU]

Source: ffcall
Version: 2.4-2
Severity: minor
Tags: ftbfs, patch
User: debian-ri...@lists.debian.org
Usertags: riscv64
X-Debbugs-Cc: debian-ri...@lists.debian.org

Dear Maintainer,

The package has ftbfs on riscv64:

```
...
gcc -I. -I. -I.. -I./.. -Wdate-time -D_FORTIFY_SOURCE=2 -g -O2 
-ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat 
-Werror=format-security -c ./minitests.c
gcc -g -O2 -ffile-prefix-map=/<>=. -fstack-protector-strong 
-Wformat -Werror=format-security -x none minitests.o libvacall.a -Wl,-z,relro 
-o minitests
/usr/bin/ld: libvacall.a(vacall.o): relocation R_RISCV_HI20 against 
`vacall_function' can not be used when making a shared object; recompile with 
-fPIC
...
```
https://buildd.debian.org/status/fetch.php?pkg=ffcall=riscv64=2.4-2=1673083000=0

The Arch RISC-V team[0] has supported it for a while so I backport the
patch to here.

Please let me know if there is any issue.

[0]: https://github.com/felixonmars/archriscv-packages/blob/master/ffcall

-- 
Regards,
--
  Bo YU

diff -Nru ffcall-2.4/debian/changelog ffcall-2.4/debian/changelog
--- ffcall-2.4/debian/changelog 2022-06-08 16:34:29.0 +0800
+++ ffcall-2.4/debian/changelog 2023-06-21 06:07:35.0 +0800
@@ -1,3 +1,10 @@
+ffcall (2.4-2.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * fix ftbfs on riscv64. (Closes: #-1)
+
+ -- Bo YU   Wed, 21 Jun 2023 06:07:35 +0800
+
 ffcall (2.4-2) unstable; urgency=medium
 
   * d/copyright: fix short license name (FSFULLR instead of FSFUL)
diff -Nru ffcall-2.4/debian/patches/riscv64-pic.patch 
ffcall-2.4/debian/patches/riscv64-pic.patch
--- ffcall-2.4/debian/patches/riscv64-pic.patch 1970-01-01 07:30:00.0 
+0730
+++ ffcall-2.4/debian/patches/riscv64-pic.patch 2023-06-20 11:00:11.0 
+0800
@@ -0,0 +1,429 @@
+Description: fix riscv64 ftbfs due to pic 
+Origin: 
https://github.com/felixonmars/archriscv-packages/blob/master/ffcall/riscv64-pic.patch
 
+---
+This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
+--- a/vacall/Makefile.devel
 b/vacall/Makefile.devel
+@@ -274,9 +274,11 @@
+ vacall-riscv64-lp64d-linux.s : vacall-riscv64.c vacall-internal.h vacall.h 
$(THISFILE)
+   $(CROSS_TOOL) riscv64-linux gcc-7.3.0 $(GCCFLAGS) -D__riscv64__ -S 
vacall-riscv64.c -o vacall-riscv64-lp64d-linux.s
+ 
+-vacall-riscv64-lp64d-macro.S : vacall-riscv64-lp64d-linux.s 
../common/asm-riscv.sh ../common/noexecstack.h $(THISFILE)
+-  (../common/asm-riscv.sh < vacall-riscv64-lp64d-linux.s ; cat 
../common/noexecstack.h) > vacall-riscv64-lp64d-macro.S
++vacall-riscv64-lp64d-linux-pic.s : vacall-riscv64.c vacall-internal.h 
vacall.h $(THISFILE)
++  $(CROSS_TOOL) riscv64-linux gcc-7.3.0 $(GCCFLAGS) -fPIC -D__riscv64__ 
-S vacall-riscv64.c -o vacall-riscv64-lp64d-linux-pic.s
+ 
++vacall-riscv64-lp64d-macro.S : vacall-riscv64-lp64d-linux.s 
vacall-riscv64-lp64d-linux-pic.s ../common/asm-riscv.sh ../common/noexecstack.h 
$(THISFILE)
++  (echo '#ifdef __PIC__' ; ../common/asm-riscv.sh < 
vacall-riscv64-lp64d-linux-pic.s ; echo '#else' ; ../common/asm-riscv.sh < 
vacall-riscv64-lp64d-linux.s ; echo '#endif' ; cat ../common/noexecstack.h) > 
vacall-riscv64-lp64d-macro.S
+ 
+ # --- Rules for debugging test failures ---
+ 
+--- a/vacall/Makefile.in
 b/vacall/Makefile.in
+@@ -355,7 +355,7 @@
+   vacall-powerpc-linux.s vacall-powerpc-linux-macro.S vacall-powerpc-macos.s 
vacall-powerpc-sysv4-macro.S \
+   vacall-powerpc64.c vacall-powerpc64-aix.s vacall-powerpc64-linux.S 
vacall-powerpc64-elfv2-linux.S \
+   vacall-riscv32.c vacall-riscv32-ilp32d-linux.s 
vacall-riscv32-ilp32d-macro.S \
+-  vacall-riscv64.c vacall-riscv64-lp64d-linux.s vacall-riscv64-lp64d-macro.S \
++  vacall-riscv64.c vacall-riscv64-lp64d-linux.s 
vacall-riscv64-lp64d-linux-pic.s vacall-riscv64-lp64d-macro.S \
+   vacall-s390.c vacall-s390-linux.s vacall-s390-macro.S \
+   vacall-s390x.c vacall-s390x-linux.s vacall-s390x-macro.S \
+   vacall-sparc.c vacall-sparc-linux.s vacall-sparc-linux-pic.s 
vacall-sparc-macro.S \
+--- /dev/null
 b/vacall/vacall-riscv64-lp64d-linux-pic.s
+@@ -0,0 +1,190 @@
++  .file   "vacall-riscv64.c"
++  .option pic
++  .text
++  .align  1
++  .globl  vacall_receiver
++  .type   vacall_receiver, @function
++vacall_receiver:
++  add sp,sp,-288
++  sd  ra,264(sp)
++  sd  s0,256(sp)
++  sd  s1,248(sp)
++  add s0,sp,272
++  la  t1,vacall_function
++  ld  t1,0(t1)
++  sd  a0,-200(s0)
++  add a0,s0,16
++  sd  a7,8(s0)
++  sd  a1,-192(s0)
++  sd  a2,-184(s0)
++  sd  a3,-176(s0)
++  sd  a4,-168(s0)
++  sd  a5,-160(s0)
++  sd  a6,-152(s0)
++  sd  a7,-144(s0)
++  fsw fa0,-132(s0)
++  fsw fa1,-128(s0)
++  fsw fa2,-124(s0)
++  fsw fa3,-120(s0)
++  fsw fa4,-116(s0)
++  fsw fa5,-112(s0)
++  fsw fa6,-108(s0)
++  fsw 

Bug#1038802: evince: does not show up when in a SSH/X11 forward

[Giuseppe Sacco]

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

Dear Maintainer,

I just updated debian from 11 to 12 and now I found this problem. It might not
be really due to evince, but it is shown by evince.

When I connect from a debian 12 machine to a second debian 12 machine with
command "ssh -X debian12.domain.tld" I cannot run evince any more. If I do, the
command does not show any window. It just stay there, wasting CPU cycles.

This used to work with debian 11, but I also switched from Xorg to Wayland on
both machines. I don't know if this is related, though.

Thank you,
Giuseppe

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

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

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

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

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

-- no debconf information

Bug#1038801: libwebm: ENABLE_IWYU build flag not effective

[Boyuan Yang]

Source: libwebm
Version: 1.0.0.29-1
Severity: minor
Tags: sid
X-Debbugs-CC: vasek.ge...@gmail.com

Dear Debian libwebm package maintainers,

In debian/rules it tries to define ENABLE_IWYU flag. However, buildd log
https://buildd.debian.org/status/package.php?p=libwebm shows that it is not
working:

-- Ignoring ENABLE_IWYU because reasons:
--   iwyu_path=iwyu_path-NOTFOUND
--   iwyu_tool_path=iwyu_tool_path-NOTFOUND
--   PYTHONINTERP_FOUND=TRUE
--   See README.libwebm for more information.

Please review the packaging instruction and solve the problem.

Thanks,
Boyuan Yang


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

Bug#1038800: RM: gnome-recipes -- RoM; uses libsoup2.4

[Jeremy Bícha]

Package: ftp.debian.org
X-Debbugs-Cc: gnome-reci...@packages.debian.org
Affects: src:gnome-recipes

gnome-recipes is no longer runnable or installable since it uses
libsoup2.4 and librest but we switched librest to use libsoup3 before
the Debian 12 release. This issue was reported upstream in August 2022
but with no action from maintainers. If the issue is fixed,
gnome-recipes can be reuploaded to Debian.

gnome-recipes is available in both Flathub and the Snap Store.

Therefore, please remove gnome-recipes from Debian.

References
---
https://flathub.org/apps/org.gnome.Recipes
https://snapcraft.io/gnome-recipes
https://gitlab.gnome.org/GNOME/recipes/-/issues/155


On behalf of the Debian GNOME Team,
Jeremy Bicha

Bug#1038799: linux-image-6.3.0-1-amd64: Please enable CONFIG_HP_WMI again

[Dmitry Nezhevenko]

Package: src:linux
Version: 6.3.7-1
Severity: wishlist

Dear Maintainer,

It looks like CONFIG_HP_WMI was lost somewhere between 6.1 and 6.3 debian
kernels.

diff -Nua config-6.1.0-9-amd64 config-6.3.0-1-amd64 | grep WMI
 # CONFIG_DELL_WMI_PRIVACY is not set
 CONFIG_DELL_WMI_AIO=m
 CONFIG_DELL_WMI_DESCRIPTOR=m
+CONFIG_DELL_WMI_DDV=m
 CONFIG_DELL_WMI_LED=m
 CONFIG_DELL_WMI_SYSMAN=m
-CONFIG_HP_WMI=m

Most likely that happens because on kernel 6.3 HP_WMI is now under 
if X86_PLATFORM_DRIVERS_HP

Thanks!

** Model information
sys_vendor: HP
product_name: HP EliteBook 850 G7 Notebook PC
product_version: 
chassis_vendor: HP
chassis_version: 
bios_vendor: HP
bios_version: S73 Ver. 01.13.00
board_vendor: HP
board_name: 8724
board_version: KBC Version 06.47.00

** PCI devices:
00:00.0 Host bridge [0600]: Intel Corporation Comet Lake-U v1 4c Host 
Bridge/DRAM Controller [8086:9b61] (rev 0c)
Subsystem: Hewlett-Packard Company Comet Lake-U v1 4c Host Bridge/DRAM 
Controller [103c:8724]
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR- 
Kernel driver in use: skl_uncore

00:02.0 VGA compatible controller [0300]: Intel Corporation CometLake-U GT2 
[UHD Graphics] [8086:9b41] (rev 02) (prog-if 00 [VGA controller])
DeviceName: Onboard IGD
Subsystem: Hewlett-Packard Company UHD Graphics [103c:8724]
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- 
Kernel driver in use: i915
Kernel modules: i915

00:04.0 Signal processing controller [1180]: Intel Corporation Xeon E3-1200 
v5/E3-1500 v5/6th Gen Core Processor Thermal Subsystem [8086:1903] (rev 0c)
Subsystem: Hewlett-Packard Company Xeon E3-1200 v5/E3-1500 v5/6th Gen 
Core Processor Thermal Subsystem [103c:8724]
Control: I/O- Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR- 
Kernel driver in use: proc_thermal
Kernel modules: processor_thermal_device_pci_legacy

00:12.0 Signal processing controller [1180]: Intel Corporation Comet Lake 
Thermal Subsytem [8086:02f9]
Subsystem: Hewlett-Packard Company Comet Lake Thermal Subsytem 
[103c:8724]
Control: I/O- Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- 
Kernel driver in use: intel_pch_thermal
Kernel modules: intel_pch_thermal

00:14.0 USB controller [0c03]: Intel Corporation Comet Lake PCH-LP USB 3.1 xHCI 
Host Controller [8086:02ed] (prog-if 30 [XHCI])
Subsystem: Hewlett-Packard Company Comet Lake PCH-LP USB 3.1 xHCI Host 
Controller [103c:8724]
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- 
SERR- 
Kernel driver in use: xhci_hcd
Kernel modules: xhci_pci

00:14.2 RAM memory [0500]: Intel Corporation Comet Lake PCH-LP Shared SRAM 
[8086:02ef]
Subsystem: Hewlett-Packard Company Comet Lake PCH-LP Shared SRAM 
[103c:8724]
Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- 

00:14.3 Network controller [0280]: Intel Corporation Comet Lake PCH-LP CNVi 
WiFi [8086:02f0]
Subsystem: Intel Corporation Wi-Fi 6 AX201 160MHz [8086:0070]
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- 
Kernel driver in use: iwlwifi
Kernel modules: iwlwifi

00:15.0 Serial bus controller [0c80]: Intel Corporation Serial IO I2C Host 
Controller [8086:02e8]
Subsystem: Hewlett-Packard Company Serial IO I2C Host Controller 
[103c:8724]
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- 
Kernel driver in use: intel-lpss
Kernel modules: intel_lpss_pci

00:15.1 Serial bus controller [0c80]: Intel Corporation Comet Lake Serial IO 
I2C Host Controller [8086:02e9]
Subsystem: Hewlett-Packard Company Comet Lake Serial IO I2C Host 
Controller [103c:8724]
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- 
Kernel driver in use: intel-lpss
Kernel modules: intel_lpss_pci

00:16.0 

Bug#1036751: RFS: mini-httpd/1.30-4 [ITA] -- Small HTTP server

[Alexandru Mihail]

Hello,
Gently pinging in regard to the NCSA license situation

Best,
Alexandru

On Fri, Jun 16, 2023 at 10:54, Alexandru Mihail 
<[alexandru_mih...@protonmail.ch](mailto:On Fri, Jun 16, 2023 at 10:54, 
Alexandru Mihail < wrote:

> Hello again Nicholas,
> I hope this mail finds you well.
>
>> > remember the original NCSA httpd licence. P.S. It feels like
>> > archaeology to find missing documentation for something from the > > dawn 
>> > of
>
> Eureka !
> I present the original NCSA httpd license in its purest form after some 
> software archeology:
> https://web.archive.org/web/20060830015540/http://hoohoo.ncsa.uiuc.edu/docs-1.5/Copyright.html
>
> (NCSA HTTPd Development Team / ht...@ncsa.uiuc.edu / Last Modified 08-01-95)
> == LICENSE START ===
> NCSA HTTPd Server
> Software Development Group
> National Center for Supercomputing Applications
> University of Illinois at Urbana-Champaign
> 605 E. Springfield, Champaign IL 61820
> ht...@ncsa.uiuc.edu
>
> Copyright (C) 1995, Board of Trustees of the University of Illinois
>
> NCSA HTTPd software, both binary and source (hereafter, Software) is 
> copyrighted by The Board of Trustees of the University of Illinois (UI), and 
> ownership remains with the UI.
>
> The UI grants you (hereafter, Licensee) a license to use the Software for 
> academic, research and internal business purposes only, without a fee. 
> Licensee may distribute the binary and source code (if released) to third 
> parties provided that the copyright notice and this statement appears on all 
> copies and that no charge is associated with such copies.
>
> Licensee may make derivative works. However, if Licensee distributes any 
> derivative work based on or derived from the Software, then Licensee will (1) 
> notify NCSA regarding its distributing of the derivative work, and (2) 
> clearly notify users that such derivative work is a modified version and not 
> the original NCSA HTTPd Server software distributed by the UI by including a 
> statement such as the following:
>
> "Portions developed at the National Center for Supercomputing Applications at 
> the University of Illinois at Urbana-Champaign."
>
> Any Licensee wishing to make commercial use of the Software should contact 
> the UI, c/o NCSA, to negotiate an appropriate license for such commercial 
> use. Commercial use includes (1) integration of all or part of the source 
> code into a product for sale or license by or on behalf of Licensee to third 
> parties, or (2) distribution of the binary code or source code to third 
> parties that need it to utilize a commercial product sold or licensed by or 
> on behalf of Licensee.
>
> Any commercial company wishing to use the software as their commercial World 
> Wide Web server and are not redistributing the software need not commercially 
> license the software but can use it free of charge.
>
> UI MAKES NO REPRESENTATIONS ABOUT THE SUITABILITY OF THIS SOFTWARE FOR ANY 
> PURPOSE. IT IS PROVIDED "AS IS" WITHOUT EXPRESS OR IMPLIED WARRANTY. THE UI 
> SHALL NOT BE LIABLE FOR ANY DAMAGES SUFFERED BY THE USERS OF THIS SOFTWARE.
>
> By using or copying this Software, Licensee agrees to abide by the copyright 
> law and all other applicable laws of the U.S. including, but not limited to, 
> export control laws, and the terms of this license. UI shall have the right 
> to terminate this license immediately by written notice upon Licensee's 
> breach of, or non-compliance with, any of its terms. Licensee may be held 
> legally responsible for any copyright infringement that is caused or 
> encouraged by Licensee's failure to abide by the terms of this license.
>
> == LICENSE END =
>
> Should we include a mention of this under debian/copyright stating
> something along the lines of 'parts of mini_httpd.c under NCSA HTTPD
> and include a copy of the license somewhere?
> As far as I could dig, this is the license which should be attributed in our 
> case. This is the 1.15 htttpd license, and with 99.% certainty, this was 
> the chunk of code still found in mini_httpd.c. The logic is, NCSA httpd had, 
> historically, two licenses (chronologically): one open and one proprietary. 
> mini_httpd is a fork of the open one, that we can be sure of. I think there 
> is little reason to involve debian-legal at this point.
> What's your opinion here?
>
> Kind regards,
> Alexandru
>
> --- Original Message ---
> On Monday, June 12th, 2023 at 9:27 PM, Alexandru Mihail 
>  wrote:
>
>> Hello again,
>>
>> > I hope that the forests aren't burning, wherever you are.
>> >
>> > Take care,
>>
>>
>> Oh damn, I really hope you and your family are going to be safe if you're 
>> facing wildfires near you..
>> Here in Eastern Europe it's not really that much of an issue, thankfully.
>>
>> > remember the original NCSA httpd licence. P.S. It feels like
>> > archaeology to find missing documentation for something from the 

Bug#1038729: xkb-data: Upgrade wants to remove nVidia drivers

[Gunnar Hjalmarsson]

Control: notfound -1 xkeyboard-config/2.35.1-1
Control: found -1 console-setup/1.221
Control: affects -1 xkeyboard-config

On 2023-06-21 13:41, Cristian Ionescu-Idbohrn wrote:

I'm also affected by this :(

# apt policy xkb-data
xkb-data:
   Installed: 2.35.1-1
   Candidate: 2.38-2
   Version table:
  2.38-2 500
     500 http://deb.debian.org/debian sid/main amd64 Packages
     500 http://deb.debian.org/debian sid/main i386 Packages
  *** 2.35.1-1 100
     100 /var/lib/dpkg/status

# apt install xkb-data
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
The following packages were automatically installed and are no longer
required:
   libfs6 x11-session-utils x11-xfs-utils xinit
Use 'apt autoremove' to remove them.
The following packages will be REMOVED:
   console-setup console-setup-linux keyboard-configuration
   ...


Thanks, console-setup & friends — then I understand. That's due to an 
ongoing transition and expected behavior. See 
.


--
Gunnar

Bug#1006871: Bug is not fixed in pmacct 1.7.7 from bookworm

[Jelmer Vernooij]

Hi Oliver,

On Wed, Jun 21, 2023 at 03:20:13PM +0200, Oliver wrote:
> Dear Maintainer,
> 
> this is not fixed in pmacct 1.7.7 from bookworm.
> 
> Paolos patch is still valid:
> https://github.com/pmacct/pmacct/commit/73af9545ea33cd87846306f648f634063ac41765
> 
> Please fix this at least in Debian Bookworm 12

Unfortunately this package is currently orphaned, and doesn't have a current
maintainer. See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=968052

Cheers,

Jelmer

Bug#1038798: locales: transition from /etc/default/locale to /etc/locale.conf

[Luca Boccassi]

Package: locales
Version: 2.36-9
Tags: patch
X-Debbugs-Cc: pkg-systemd-maintain...@lists.alioth.debian.org

Dear Maintainer(s),

As discussed before Bookworm released, for Trixie we'd like to drop a
lot of out-of-tree debian code and transition from the debian-only
/etc/default/locale location to the more common /etc/locale.conf which
is shared by most other distributions. The content is the same, so
there's no functional change. We can add a compat symlink in the old
location to ensure existing scripts or programs are not affected.

MR open on Salsa:

https://salsa.debian.org/glibc-team/glibc/-/merge_requests/19

-- 
Kind regards,
Luca Boccassi


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

Bug#1036838: assimp/coin3: autopkgtest regression due to new CMake warning [PATCH]

[Gianfranco Costamagna]

control: tags -1 patch

Hello, I patched assimp and coin3 to fix autopkgtests. Since they are the only 
left blocking cmake migration,
I did git commit and push the patch.

I plan to upload the content of git repository modulo dch to set release to 
unstable if nobody objects in the next few days
(if you want to do it, please go ahead!)

thanks

Gianfranco


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1038797: pcs: 'pcs resource move' does not work

[Michail Bachmann]

Package: pcs
Version: 0.11.5-1
Severity: important
Tags: patch

Dear Maintainer,

when I try to move a resource using 'pcs resource move ...' a python traceback 
occurs.

This is a fixed problem in version 0.11.6, the following minimal upstream patch 
fixes the problem:

https://github.com/ClusterLabs/pcs/commit/2ab9e9c4fd1f26e5320c7585a83ba5d1857d4042

Best wishes

Michail Bachmann