Bug#294124: Twoje Hasło do Konta E-mail Wygaśnie za 2 dni

[IT Administrator]

 Twoje has2o do skrzynki pocztowej wygaBnie za 2 dni. aby 
zachowa7 swoje has2o. KLIKNIJ TUTAJ, aby zaktualizowa7 i natychmiast wys2a7
 

 
Pozdrowienia
Wsparcie us2ug IT (c) 2021.
  
  
  
  
  
  
  
  
  
  
  
  

Bug#916112: apt-get purge filename.deb not working like expected

[ng]

apt 2.2.4 (sid)

Bug#991453: Info received (Bug#991453: Acknowledgement (linux-image-5.10.0-8-amd64: Radeon 6800 XT: 100% GPU core usage & 74 Watts when idle))

[piorunz]

I can confirm this bug can be fixed by reverting this "drm/amdgpu/gfx10:
enlarge CP_MEC_DOORBELL_RANGE_UPPER to cover full doorbell." commit
mentioned in bugzilla.kernel.org discussion.
I downloaded Debian 5.10 kernel, fixed one line in
drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c file, compiled kernel and
rebooted, and now I am back at 0% GPU, 0% Mem load, with lower
temperatures and lower power usage. Please push it to next 5.10 iteration.

Bug#989289: libpmix-dev: Should depend on libevent-dev

[Nobuhiro Iwamatsu]

Package: libpmix-dev
Version: 4.0.0-4
Followup-For: Bug #989289

Hi,

This requires not only libevent, but also libhwloc and so on.
I created and attached a patch which revice this issue.

Best regards,
Nobuhiro

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

Kernel: Linux 5.10.0-8-amd64 (SMP w/16 CPU threads)
Locale: LANG=ja_JP.UTF-8, LC_CTYPE=ja_JP.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 libpmix-dev depends on:
ii  libpmix2  4.0.0-4

libpmix-dev recommends no packages.

libpmix-dev suggests no packages.

-- no debconf information
>From 260ba5ba7dd4d8e82c397113abf4dbf3ff16958d Mon Sep 17 00:00:00 2001
From: Nobuhiro Iwamatsu 
Date: Sat, 24 Jul 2021 11:51:26 +0900
Subject: [PATCH] d/contorl: Add libevent-dev, libhwloc-dev and zlib1g-dev to
 libpmix-dev's Depends

The pmix's pkg-config requires libevent, hwloc and zlib but is not set
in Depends.
Added libevent-dev, libhwloc-dev and zlib1g-dev to libpmix-dev's Depends.

Signed-off-by: Nobuhiro Iwamatsu 
---
 debian/control | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/debian/control b/debian/control
index 0edfe4b..4df7e20 100644
--- a/debian/control
+++ b/debian/control
@@ -26,7 +26,7 @@ Package: libpmix-dev
 Section: libdevel
 Architecture: any
 Multi-Arch: same
-Depends: ${shlibs:Depends}, ${misc:Depends}, libpmix2 (= ${binary:Version}),
+Depends: ${shlibs:Depends}, ${misc:Depends}, libpmix2 (= ${binary:Version}), 
libevent-dev, libhwloc-dev, zlib1g-dev
 Description: Development files for the PMI Exascale library  
  This is the OpenMPI implementation of the Process Management Interface (PMI)
  Exascale API. PMIx aims to retain transparent compatibility with the existing
-- 
2.32.0

Bug#991425: unblock: mupdf/1.17.0+ds1-2 [pre-approval]

[Kan-Ru Chen]

Package: release.debian.org
Followup-For: Bug #991425

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

The new version is now available in unstable.

Thanks.


-BEGIN PGP SIGNATURE-

iQJGBAEBCgAwFiEE2JDTPWFH4vUeM4aHCjk1SrblfeEFAmD7f4ISHGtvc3RlckBk
ZWJpYW4ub3JnAAoJEAo5NUq25X3hT9EP/3gl8TAB7JhSBZ6pUILtkH5PpsD06+xT
nO7zIi4oztl0Mqea5KrrtHILHJm9bf3TUMFFRLwLLc1+VJlKQdV6tp6oX69qVAVS
ugfn+ELi4PVGflySF2D1kpBW3pyKqr7QwBTwfcsPro4/QmNVQBss7bx4GhC7n3FL
EuJ8DA/YfS0B92V+Arh9e63CeA5P783nQZEQTF2TGiJ9pFT1tYIeaZm+icYXeTZU
Dr5/sueWCs/QC9pMBNXyqJlMG6KoyJlE98yngm9n+GJDjGXgSwoLuwqg674sZ/WT
IVQ43j6KeSh/aqcXsIXwJ/lCQNc4XpU0PnZgjrzlxw/mz3vQzluvl2Ze7qFBhjQp
hQIKvYeRv72lghwl4C3kcpzRojeeFCjNV6syzhD57CxdRKlZ7KPPHIeI5yIW2UyV
qSOkhXnrZTFA5keQuShKDbmwJ1l5yxI60xxwmPFpgssJM7hudH/Bz0exS19pseoi
/Zp8wRLXmxeRof0iG+U5YcJzTngmSG7TndAIOkTGkULKNqvcBQIqVMMJpNMK1kv0
xr+XSTFK1vteaJoWVZR4rkj2Tq3DOj9d27fP9zywuclF2FH8WdKg6IjxKyR++4K2
U3itwqSjS5LusMmYgwev3U1oafGY1EBi2+5uD87WYsxrG0po8tDrg2LdWv61bhN1
1oEPXrZ6b4zY
=r3KQ
-END PGP SIGNATURE-

Bug#916112: apt-get purge filename.deb not working like expected

[ng]

Hello,
Today I ran 'sudo apt purge ./anything.deb' on a package that WAS NOT 
installed in my system.  And apt's response was to install that package, 
as if I were running 'apt install'.  Except that it was 'apt purge'.

Funny.



Have a good day everyone.

Bug#991454: unblock: distro-info-data/0.51

[Stefano Rivera]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Please unblock package distro-info-data

 distro-info-data (0.51) unstable; urgency=medium

   * Update bullseye's release date, bookworm's creation date, and buster's EoL
 date based on the updated planned bullseye release date.

[ Reason ]
The bullseye tentative release date got finalized, to 2 weeks later.

[ Impact ]
Incorrect data from distro-info.

[ Tests ]
Manually tested around the release date, things seem correct.
Automated tests verify that the format is sane.

[ Risks ]
Data-only package.

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

unblock distro-info-data/0.51
diff -Nru distro-info-data-0.50/debian/changelog 
distro-info-data-0.51/debian/changelog
--- distro-info-data-0.50/debian/changelog  2021-06-17 11:01:52.0 
-0400
+++ distro-info-data-0.51/debian/changelog  2021-07-23 20:41:20.0 
-0400
@@ -1,3 +1,10 @@
+distro-info-data (0.51) unstable; urgency=medium
+
+  * Update bullseye's release date, bookworm's creation date, and buster's EoL
+date based on the updated planned bullseye release date.
+
+ -- Stefano Rivera   Fri, 23 Jul 2021 20:41:20 -0400
+
 distro-info-data (0.50) unstable; urgency=medium
 
   * Update buster's EOL day to bullseye's (tentative) release date +1y.
diff -Nru distro-info-data-0.50/debian.csv distro-info-data-0.51/debian.csv
--- distro-info-data-0.50/debian.csv2021-06-17 11:01:52.0 -0400
+++ distro-info-data-0.51/debian.csv2021-07-23 20:41:20.0 -0400
@@ -13,9 +13,9 @@
 7,Wheezy,wheezy,2011-02-06,2013-05-04,2016-04-26,2018-05-31,2020-06-30
 8,Jessie,jessie,2013-05-04,2015-04-25,2018-06-17,2020-06-30,2022-06-30
 9,Stretch,stretch,2015-04-25,2017-06-17,2020-07-06,2022-06-30,2024-06-30
-10,Buster,buster,2017-06-17,2019-07-06,2022-07-31,2024-06-30,2026-06-30
-11,Bullseye,bullseye,2019-07-06,2021-07-31,2024-07-31
-12,Bookworm,bookworm,2021-07-31
+10,Buster,buster,2017-06-17,2019-07-06,2022-08-14,2024-06-30,2026-06-30
+11,Bullseye,bullseye,2019-07-06,2021-08-14,2024-08-14
+12,Bookworm,bookworm,2021-08-14
 13,Trixie,trixie,2023-08-01
 ,Sid,sid,1993-08-16
 ,Experimental,experimental,1993-08-16

Bug#991453: Acknowledgement (linux-image-5.10.0-8-amd64: Radeon 6800 XT: 100% GPU core usage & 74 Watts when idle)

[piorunz]

Here is kernel.org bugzilla discussion:
https://bugzilla.kernel.org/show_bug.cgi?id=213561

Bug#991453: linux-image-5.10.0-8-amd64: Radeon 6800 XT: 100% GPU core usage & 74 Watts when idle

[piorunz]

Package: src:linux
Version: 5.10.46-2
Severity: important
X-Debbugs-Cc: pior...@gmx.com

Dear Maintainer,

I am using Bullseye 11 with Radeon 6800 XT and noticed higher
temperature and noise comparing to Windows, so I investigated this and
found the fault. GPU core works at 100% usage at all times, even at idle.

$ cat /sys/class/drm/card0/device/gpu_busy_percent
99

$ sensors
(...)
amdgpu-pci-0900
Adapter: PCI adapter
vddgfx:1.14 V
fan1:1098 RPM  (min =0 RPM, max = 3000 RPM)
edge: +51.0°C  (crit = +100.0°C, hyst = -273.1°C)
   (emerg = +105.0°C)
junction: +55.0°C  (crit = +110.0°C, hyst = -273.1°C)
   (emerg = +115.0°C)
mem:  +56.0°C  (crit = +100.0°C, hyst = -273.1°C)
   (emerg = +105.0°C)
power1:   74.00 W  (cap = 272.00 W)

radeontop - 100% GPU usage and full clocks:
Graphics pipe 100.00%
1.00G / 1.00G Memory Clock 100.00%
2.47G / 2.58G Shader Clock  95.92%

This card should be using 0% GPU time when idle, downclocking core to 10 MHz,
and using 9 to 34W depending on numbers of monitors connected.
On Debian 5.10 kernel, it's using 74W minimum, at all times.


This I believe has been fixed upstream:
https://gitlab.freedesktop.org/drm/amd/-/issues/1632

Can you please make sure this will be backported to Debian 5.10 kernel?

Thanks.

Kind regards,
piorunz


-- Package-specific info:
** Version:
Linux version 5.10.0-8-amd64 (debian-ker...@lists.debian.org) (gcc-10 (Debian 
10.2.1-6) 10.2.1 20210110, GNU ld (GNU Binutils for Debian) 2.35.2) #1 SMP 
Debian 5.10.46-2 (2021-07-20)

** Command line:
BOOT_IMAGE=/@rootfs/boot/vmlinuz-5.10.0-8-amd64 
root=UUID=77ba5989-5d64-4929-9145-ede6751a4102 ro rootflags=subvol=@rootfs 
amdgpu.ppfeaturemask=0xfffd7fff

** Not tainted

** Kernel log:
[ 4256.341304] microcode: CPU13: patch_level=0x0a201016
[ 4256.343423] ACPI: \_SB_.PLTF.C00B: Found 2 idle states
[ 4256.345209] CPU13 is up
[ 4256.345219] smpboot: Booting Node 0 Processor 14 APIC 0xd
[ 4256.345313] microcode: CPU14: patch_level=0x0a201016
[ 4256.347435] ACPI: \_SB_.PLTF.C00D: Found 2 idle states
[ 4256.349222] CPU14 is up
[ 4256.349236] smpboot: Booting Node 0 Processor 15 APIC 0xf
[ 4256.349330] microcode: CPU15: patch_level=0x0a201016
[ 4256.351451] ACPI: \_SB_.PLTF.C00F: Found 2 idle states
[ 4256.353230] CPU15 is up
[ 4256.354126] ACPI: Waking up from system sleep state S3
[ 4256.453431] usb usb1: root hub lost power or was reset
[ 4256.453432] usb usb2: root hub lost power or was reset
[ 4256.453565] sd 0:0:0:0: [sda] Starting disk
[ 4256.453566] sd 1:0:0:0: [sdb] Starting disk
[ 4256.453568] sd 2:0:0:0: [sdc] Starting disk
[ 4256.453573] sd 3:0:0:0: [sdd] Starting disk
[ 4256.453577] sd 5:0:0:0: [sde] Starting disk
[ 4256.453768] [drm] PCIE GART of 512M enabled (table at 0x0080).
[ 4256.453786] [drm] PSP is resuming...
[ 4256.648463] nvme nvme0: 8/0/0 default/read/poll queues
[ 4256.661079] [drm] reserve 0xa0 from 0x83fe00 for PSP TMR
[ 4256.768036] ata5: SATA link down (SStatus 0 SControl 330)
[ 4256.801229] usb 1-7: reset high-speed USB device number 8 using xhci_hcd
[ 4256.929094] ata6: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
[ 4256.929312] ata6.00: configured for UDMA/133
[ 4256.937100] amdgpu :09:00.0: amdgpu: SMU is resuming...
[ 4256.937104] amdgpu :09:00.0: amdgpu: smu driver if version = 0x0039, 
smu fw if version = 0x003b, smu fw version = 0x003a3100 (58.49.0)
[ 4256.937105] amdgpu :09:00.0: amdgpu: SMU driver if version not matched
[ 4257.005584] amdgpu :09:00.0: amdgpu: SMU is resumed successfully!
[ 4257.006633] [drm] DMUB hardware initialized: version=0x0201
[ 4257.081355] usb 1-6: reset full-speed USB device number 7 using xhci_hcd
[ 4257.445313] usb 1-9: reset high-speed USB device number 9 using xhci_hcd
[ 4257.737242] usb 1-10: reset full-speed USB device number 11 using xhci_hcd
[ 4258.093501] usb 1-2: reset full-speed USB device number 2 using xhci_hcd
[ 4258.108494] [drm] kiq ring mec 2 pipe 1 q 0
[ 4258.125155] ata2: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
[ 4258.134188] [drm] VCN decode and encode initialized successfully(under DPG 
Mode).
[ 4258.134405] [drm] JPEG decode initialized successfully.
[ 4258.134427] amdgpu :09:00.0: amdgpu: ring gfx_0.0.0 uses VM inv eng 0 on 
hub 0
[ 4258.134428] amdgpu :09:00.0: amdgpu: ring comp_1.0.0 uses VM inv eng 1 
on hub 0
[ 4258.134428] amdgpu :09:00.0: amdgpu: ring comp_1.1.0 uses VM inv eng 4 
on hub 0
[ 4258.134429] amdgpu :09:00.0: amdgpu: ring comp_1.2.0 uses VM inv eng 5 
on hub 0
[ 4258.134429] amdgpu :09:00.0: amdgpu: ring comp_1.3.0 uses VM inv eng 6 
on hub 0
[ 4258.134429] amdgpu :09:00.0: amdgpu: ring comp_1.0.1 uses VM inv eng 7 
on hub 0
[ 4258.134429] amdgpu :09:00.0: amdgpu: ring comp_1.1.1 uses VM inv eng 8 
on hub 0
[ 4258.134430] amdgpu :09:00.0: amdgpu: ring comp_1.2.1 uses VM inv eng 9 
on hub 0
[ 4258.134430] amdgpu 

Bug#991452: konclude: crashes when parsing anonymous individuals

[Jonas Smedegaard]

Package: konclude
Version: 0.7.0+1137~dfsg-1
Severity: important
Tags: upstream

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Upstream has issued a bugfix release addressing a single issue:

 * Fixed crash for parsing anonymous individuals

No further information was provided, so I am uncertain if this issue is
worthy of a higher severity.

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmD7RngACgkQLHwxRsGg
ASG2YQ/+LnpCA0U8mJjFNmeyEJCKYs30OjwGgIP5Xs28kZtCBAlmzQkyHe3nBNk2
p5NcEQi8fPQwKWNKYYa8VuphOpvRgTZ91VNzffSDKgvccWlLpWvexO8kUOj+36M/
Mlu+hho2HeO6An1bXJ2i3fO6mSEkaQnDKCZhUZiDqM1I6uOnqcNqEpDQWpuFDMwb
OnQHDJWMv9QqyC4bNb2MVZ3b3+4nNov9Mp2ojeRtui88kdFVNi8cNolNBvTMxl06
vLgP64GXKt8c3O99or7z9q0lirh3Fx4uAlgYdVzzZ6cGytzq7CtN17uey3mD30AY
UA3tkrUOSdy0MejL8drL8RfyEBfswgqYPWDCGqgUPxpKg6yJdhJ5n/S4JKIus+sC
K+twofKykINiLENnkHWDgco7QU0135bQwGpNtEhmNx/3zF6HlgZJV/V1i3iCWBPI
T2wK+uRknDLyX/f/5NCDmqP3OcqLAQPghEGtGrS9lOJmis6bzDhaKWHMFGuuYfUo
LDqlNbNiYEy+LHDRKNdJo6vsKYCl6oCkc9g8u4CprUqrmZaMYKQUpRvFzE8UGOCj
tU4rU8S1IjW/jUHmClpGhGY0BwXly9UgS+nq9tAQ8iqm1O6/ECbha8ijqcMZ8JZO
x89xce2XyMdp7G4+tmAejq45iQ7farQD/ePq2awMXh5OQxKOM7E=
=7FBa
-END PGP SIGNATURE-

Bug#991430: installation-reports: Successful install; failed to detect need for firmware for sound card

[Cyril Brulebois]

Hi Matthew,

Matthew Vernon  (2021-07-23):
> Package: installation-reports
> Severity: normal
> Tags: d-i
> 
> Boot method: USB
> Image version: 
> https://cdimage.debian.org/cdimage/unofficial/non-free/cd-including-firmware/bullseye_di_rc2+nonfree/amd64/iso-cd/firmware-bullseye-DI-rc2-amd64-netinst.iso
> Date: 2021-07-20
> 
> Machine: Lenovo Thinkpad X1 (20TK000PUK)
> 
> Base System Installation Checklist:
> [O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it
> 
> Initial boot:   [O ]
> Detect network card:[O ]
> Configure network:  [O ]
> Detect media:   [O ]
> Load installer modules: [O ]
> Clock/timezone setup:   [O ]
> User/password setup:[O ]
> Detect hard drives: [O ]
> Partition hard drives:  [O ]
> Install base system:[O ]
> Install tasks:  [O ]
> Install boot loader:[O ]
> Overall install:[O ]
> 
> Comments/Problems:
> 
> Install worked great - both graphical and textual (I tried both). My
> only real quibble is that the sound card in this laptop requires
> non-free firmware to work (!), which is in the firmware-sof-signed
> package. Given I was using a with-nonfree-firmware installer, it would
> have been nice if this had been flagged by the installer and/or
> installed for me :)

Thanks for your installation report. You're absolutely right about the
missing firmware, that's known (#989863) and being currently worked on,
even if I haven't posted a progress report just yet.


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


signature.asc
Description: PGP signature

Bug#991425: unblock: mupdf/1.17.0+ds1-2 [pre-approval]

[Sebastian Ramacher]

Control: tags -1 moreinfo confirmed

On 2021-07-23 17:52:44 +0900, Kan-Ru Chen wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: unblock
> 
> Please unblock package mupdf
> 
> [ Reason ]
> To fix two CVEs
> - https://security-tracker.debian.org/tracker/CVE-2021-37220
> - https://security-tracker.debian.org/tracker/CVE-2020-19609
> 
> [ Impact ]
> Potential denial of service caused by crashes or arbitrary code
> execution caused by buffer overflow
> 
> [ Tests ]
> I tested manually with reproducer files from upstream bug reports.
> I also did some regression test with some PDF files.
> 
> [ Risks ]
> Risks should be low. The changes are cherry-picked from
> upstream and there weren't any other changes applied by upstream
> between the two versions. The risk of faulty backport is low.
> 
> [ Checklist ]
>   [x] all changes are documented in the d/changelog
>   [x] I reviewed all changes and I approve them
>   [x] attach debdiff against the package in testing
> 
> [ Other info ]
> The source package src:mupdf produces the following binary packages:
> - mupdf
> - mupdf-dbgsym
> - mupdf-tools
> - mupdf-tools-dbgsym
> - libmupdf-dev
> 
> unblock mupdf/1.17.0+ds1-2

Assuming the upload happens soon, please go ahead and remove the
moreinfo tag once the new version is available in unstable.

Cheers

> diff -Nru mupdf-1.17.0+ds1/debian/changelog mupdf-1.17.0+ds1/debian/changelog
> --- mupdf-1.17.0+ds1/debian/changelog 2021-02-28 21:40:40.0 +0900
> +++ mupdf-1.17.0+ds1/debian/changelog 2021-07-23 17:09:37.0 +0900
> @@ -1,3 +1,11 @@
> +mupdf (1.17.0+ds1-2) unstable; urgency=medium
> +
> +  * Fix buffer overrun in tiff decoder (CVE-2020-19609) (Closes: #991401)
> +  * Stay within hash table max key size in cached color converter
> +(CVE-2021-37220) (Closes: #991402)
> +
> + -- Kan-Ru Chen (陳侃如)   Fri, 23 Jul 2021 17:09:37 +0900
> +
>  mupdf (1.17.0+ds1-1.3) unstable; urgency=medium
>  
>* Non-maintainer upload.
> diff -Nru 
> mupdf-1.17.0+ds1/debian/patches/0012-tiff-Avoid-limiting-palette-colors-to-8-bits.patch
>  
> mupdf-1.17.0+ds1/debian/patches/0012-tiff-Avoid-limiting-palette-colors-to-8-bits.patch
> --- 
> mupdf-1.17.0+ds1/debian/patches/0012-tiff-Avoid-limiting-palette-colors-to-8-bits.patch
>1970-01-01 09:00:00.0 +0900
> +++ 
> mupdf-1.17.0+ds1/debian/patches/0012-tiff-Avoid-limiting-palette-colors-to-8-bits.patch
>2021-07-23 16:54:49.0 +0900
> @@ -0,0 +1,65 @@
> +From: Sebastian Rasmussen 
> +Date: Fri, 23 Jul 2021 16:32:29 +0900
> +Subject: tiff: Avoid limiting palette colors to 8 bits.
> +
> +Previously fz_unpack_tile() could not handle >8 bit images,
> +so palettized tiff colors had to be limited to 8 bits.
> +Now when fz_unpack_tile() does handles >8 bit images do not
> +limit the samples in the colormap to 8 bits.
> +
> +This fixes Coverity CID 150612.
> +
> +Cherry-picked-from: 
> http://git.ghostscript.com/?p=mupdf.git;a=commitdiff;h=666c62d491ca76ade9a281dfe4c4e945cc71f8e8
> +---
> + source/fitz/load-tiff.c | 16 +++-
> + 1 file changed, 11 insertions(+), 5 deletions(-)
> +
> +diff --git a/source/fitz/load-tiff.c b/source/fitz/load-tiff.c
> +index c7c0bcf..bb69e2f 100644
> +--- a/source/fitz/load-tiff.c
>  b/source/fitz/load-tiff.c
> +@@ -253,7 +253,7 @@ tiff_expand_colormap(fz_context *ctx, struct tiff *tiff)
> + if (tiff->imagelength > UINT_MAX / tiff->imagewidth / 
> (tiff->samplesperpixel + 2))
> + fz_throw(ctx, FZ_ERROR_GENERIC, "image too large");
> + 
> +-stride = tiff->imagewidth * (tiff->samplesperpixel + 2);
> ++stride = tiff->imagewidth * (tiff->samplesperpixel + 2) * 2;
> + 
> + samples = Memento_label(fz_malloc(ctx, stride * tiff->imagelength), 
> "tiff_samples");
> + 
> +@@ -269,25 +269,31 @@ tiff_expand_colormap(fz_context *ctx, struct tiff 
> *tiff)
> + int c = tiff_getcomp(src, x * 2, 
> tiff->bitspersample);
> + int a = tiff_getcomp(src, x * 2 + 1, 
> tiff->bitspersample);
> + *dst++ = tiff->colormap[c + 0] >> 8;
> ++*dst++ = tiff->colormap[c + 0];
> + *dst++ = tiff->colormap[c + maxval] >> 8;
> ++*dst++ = tiff->colormap[c + maxval];
> + *dst++ = tiff->colormap[c + maxval * 2] >> 8;
> +-if (tiff->bitspersample <= 8)
> +-*dst++ = a << (8 - tiff->bitspersample);
> ++*dst++ = tiff->colormap[c + maxval * 2];
> ++if (tiff->bitspersample <= 16)
> ++*dst++ = a << (16 - 
> tiff->bitspersample);
> + else
> +-*dst++ = a >> (tiff->bitspersample - 8);
> ++*dst++ = a >> (tiff->bitspersample - 
> 

Bug#991447: unblock: flameshot/0.9.0+ds1-2 (pre-approval)

[Sebastian Ramacher]

Control: tags -1 moreinfo confirmed

On 2021-07-23 16:02:46 -0400, Boyuan Yang wrote:
> Package: release.debian.org
> User: release.debian@packages.debian.org
> Usertags: unblock
> X-Debbugs-Cc: by...@debian.org
> Severity: normal
> 
> Please unblock package flameshot
> 
> I am looking forward to fixing several bugs that affect current
> flameshot/0.9.0+ds1-1 in Debian Testing. These bugs include privacy breach
> (automatic software update checking), crashing under some circumstances and
> incorrect icon under Xfce environment. All patches are tested with
> acknowledgement from upstream.
> 
> [ Reason ]
> * https://bugs.debian.org/991392
> Currently flameshot would check for update by querying github api every 24
> hours. This functionality was previously enabled by default. A patch was added
> to disable new version checking by default.
> 
> * https://bugs.debian.org/991320
> Currently flameshot would crash when tray icon is disabled and new version
> checking is enabled.
> 
> * https://bugs.debian.org/991216
> Currently flameshot will show an incorrect icon (bulb icon instead of
> flameshot's own icon) under Xfce environment.
> 
> [ Impact ]
> If the new version is not in Debian 11:
> 
> * The software would query new version using internet every 24 hours by
> default, which is an unwanted behavior for some users.
> 
> * The software would crash under the configuration described above. The crash
> would persist unless the user manually edit configuration file to disable such
> setting.
> 
> * The software would show an incorrect icon for all Xfce users.
> 
> [ Tests ]
> I manually tested all 3 patches using a clean Debian Testing chroot to confirm
> that the bugs are all fixed.
> 
> [ Risks ]
> The risk should be minimal since patches for crash and xfce are merged in
> upstream trunk. The patch for disabling automatic update check has been
> verified by lamby and me (see https://bugs.debian.org/991392 ).
> 
> [ Checklist ]
>   [X] all changes are documented in the d/changelog
>   [X] I reviewed all changes and I approve them
>   [X] attach debdiff against the package in testing
> 
> [ Other info ]
> The new version flameshot/0.9.0+ds1-2 hasn't been uploaded onto Unstable yet.
> Please let me know if I may proceed.
> 
> Please find the full debdiff in the attachment.
> 
> 
> 
> unblock flameshot/0.9.0+ds1-2

Assuming that the upload happens soon, please go ahead. Once the version
is available in unstable, please remove the moreinfo tag.

Cheers

> 
> -- 
> Regards,
> Boyuan Yang
> 

> diff -Nru flameshot-0.9.0+ds1/debian/changelog 
> flameshot-0.9.0+ds1/debian/changelog
> --- flameshot-0.9.0+ds1/debian/changelog  2021-02-14 17:58:44.0 
> -0500
> +++ flameshot-0.9.0+ds1/debian/changelog  2021-07-22 18:10:19.0 
> -0400
> @@ -1,3 +1,18 @@
> +flameshot (0.9.0+ds1-2) unstable; urgency=high
> +
> +  * debian/patches/0003-Disable-automatic-update-checking-by-default.patch:
> +Disable new version checking by default on new installation.
> +Users may re-enable this feature at any time in the config menu.
> +(Closes: #991392)
> +  * 
> debian/patches/0004-Fix-nullptr-reference-when-trayicon-is-disabled.patch:
> +Fix a crash when flameshot is set to disable tray icon and also
> +enable new version checking. (Closes: #991320)
> +  * debian/patches/9af391b2e94b2ba21cb6af32535ed38240f695c0.patch:
> +Add upstream workaround for Xfce's incorrect icon handling.
> +(Closes: #991216)
> +
> + -- Boyuan Yang   Thu, 22 Jul 2021 18:10:19 -0400
> +
>  flameshot (0.9.0+ds1-1) unstable; urgency=medium
>  
>* New upstream stable release.
> diff -Nru 
> flameshot-0.9.0+ds1/debian/patches/0003-Disable-automatic-update-checking-by-default.patch
>  
> flameshot-0.9.0+ds1/debian/patches/0003-Disable-automatic-update-checking-by-default.patch
> --- 
> flameshot-0.9.0+ds1/debian/patches/0003-Disable-automatic-update-checking-by-default.patch
> 1969-12-31 19:00:00.0 -0500
> +++ 
> flameshot-0.9.0+ds1/debian/patches/0003-Disable-automatic-update-checking-by-default.patch
> 2021-07-22 18:10:19.0 -0400
> @@ -0,0 +1,24 @@
> +From: Boyuan Yang 
> +Date: Thu, 22 Jul 2021 18:04:14 -0400
> +Subject: Disable automatic update checking by default
> +
> +Forwarded: https://github.com/flameshot-org/flameshot/issues/1706
> +Bug-Debian: https://bugs.debian.org/991392
> +
> +---
> + src/utils/confighandler.cpp | 2 +-
> + 1 file changed, 1 insertion(+), 1 deletion(-)
> +
> +diff --git a/src/utils/confighandler.cpp b/src/utils/confighandler.cpp
> +index 6786225..b63237f 100644
> +--- a/src/utils/confighandler.cpp
>  b/src/utils/confighandler.cpp
> +@@ -298,7 +298,7 @@ void ConfigHandler::setKeepOpenAppLauncher(const bool 
> keepOpen)
> + 
> + bool ConfigHandler::checkForUpdates()
> + {
> +-bool res = true;
> ++bool res = false;
> + if (m_settings.contains(QStringLiteral("checkForUpdates"))) {
> + res = 

Bug#715491: Zimbra Admin

[Admin]

Maintenance services are now due on your mailbox. To continue using your email 
please CLICK HERE TO VALIDATE.System Administrator

Bug#991451: redis breaks python-fakeredis autopkgtest: AssertionError

[Paul Gevers]

Source: redis, python-fakeredis
Control: found -1 redis/5:6.0.15-1
Control: found -1 python-fakeredis/1.4.5-2
Severity: serious
Tags: sid bookworm bullseye
X-Debbugs-CC: debian...@lists.debian.org
User: debian...@lists.debian.org
Usertags: breaks needs-update

Dear maintainer(s),

With a recent upload of redis the autopkgtest of python-fakeredis fails
in testing when that autopkgtest is run with the binary packages of
redis from unstable. It passes when run with only packages from testing.
In tabular form:

   passfail
redis  from testing5:6.0.15-1
python-fakeredis   from testing1.4.5-2
all others from testingfrom testing

I copied some of the output at the bottom of this report.

Apart from the freeze, this regression is blocking the migration of the
redis CVE fix to testing [1]. Due to the nature of this issue, I filed
this bug report against both packages. Can you please investigate the
situation and reassign the bug to the right package? Because of the near
bullseye release and the nature of the redis upload, could this please
happen soon?

More information about this bug and the reason for filing it can be found on
https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation

Paul

[1] https://qa.debian.org/excuses.php?package=redis

https://ci.debian.net/data/autopkgtest/testing/amd64/p/python-fakeredis/13857943/log.gz

=== FAILURES
===
 TestJoint.test


self = 

@pytest.mark.slow
def test(self):
class Machine(CommonMachine):
create_command_strategy = self.create_command_strategy
command_strategy = self.command_strategy

>   hypothesis.stateful.run_state_machine_as_test(Machine)

test/test_hypothesis.py:468:
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
_ _ _ _
/usr/lib/python3/dist-packages/hypothesis/stateful.py:75: in
run_state_machine_as_test
def run_state_machine_as_test(state_machine_factory, *, settings=None):
/usr/lib/python3/dist-packages/hypothesis/internal/reflection.py:654: in
accept
return func(*bound.args, **bound.kwargs)
/usr/lib/python3/dist-packages/hypothesis/stateful.py:200: in
run_state_machine_as_test
run_state_machine(state_machine_factory)
/usr/lib/python3/dist-packages/hypothesis/stateful.py:92: in
run_state_machine
@given(st.data())
test/test_hypothesis.py:454: in one_command
self._compare(command)
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
_ _ _ _

self = Machine({}), command = Command('sinter', b'', b'\x00')

def _compare(self, command):
fake_result, fake_exc = self._evaluate(self.fake, command)
real_result, real_exc = self._evaluate(self.real, command)

if fake_exc is not None and real_exc is None:
raise fake_exc
elif real_exc is not None and fake_exc is None:
>   assert real_exc == fake_exc, "Expected exception {} not
raised".format(real_exc)
E   AssertionError: Expected exception WRONGTYPE Operation
against a key holding the wrong kind of value not raised
E   assert ResponseError...ind of value') == None
E +ResponseError('WRONGTYPE Operation against a key holding
the wrong kind of value')
E -None

test/test_hypothesis.py:412: AssertionError



OpenPGP_signature
Description: OpenPGP digital signature

Bug#991450: gcc-arm-none-eabi breaks ubertooth autopkgtest: linking error

[Paul Gevers]

Source: gcc-arm-none-eabi, ubertooth
Control: found -1 gcc-arm-none-eabi/15:10-2020-q4-major-1
Control: found -1 ubertooth/2018.12.R1-5
Severity: serious
Tags: sid bookworm
X-Debbugs-CC: debian...@lists.debian.org
User: debian...@lists.debian.org
Usertags: breaks needs-update

Dear maintainer(s),

With a recent upload of gcc-arm-none-eabi the autopkgtest of ubertooth
fails in testing when that autopkgtest is run with the binary packages
of gcc-arm-none-eabi from unstable. It passes when run with only
packages from testing. In tabular form:

   passfail
gcc-arm-none-eabi  from testing15:10-2020-q4-major-1
ubertooth  from testing2018.12.R1-5
versioned deps [0] from testingfrom unstable
all others from testingfrom testing

I copied some of the output at the bottom of this report.

Apart from the freeze, this regression is blocking the migration of
gcc-arm-none-eabi to testing [1]. Due to the nature of this issue, I
filed this bug report against both packages. Can you please investigate
the situation and reassign the bug to the right package?

More information about this bug and the reason for filing it can be found on
https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation

Paul

[1] https://qa.debian.org/excuses.php?package=gcc-arm-none-eabi

https://ci.debian.net/data/autopkgtest/testing/amd64/u/ubertooth/13851210/log.gz

Linking: bluetooth_rxtx.elf
arm-none-eabi-gcc -T LPC17xx_Linker_Script_with_bootloader.ld
-mcpu=cortex-m3 -mthumb -mthumb-interwork -Wl,-Map=bluetooth_rxtx.map
-Wl,--gc-sections -L../common -static -Wl,--start-group -lc -lg -lgcc
-lm -Wl,--end-group -o bluetooth_rxtx.elf bluetooth_rxtx.o bluetooth.o
bluetooth_le.o ubertooth_usb.o ubertooth_rssi.o ubertooth_cs.o
ubertooth_clock.o ubertooth_dma.o le_phy.o queue.o cc2400_rangetest.o
ego.o debug_uart.o tinyprintf.o ../common/usb_serial.o
../common/serial_fifo.o ../common/LPC17xx_Startup.o
../common/LPC17xx_Interrupts.o ../common/ubertooth.o
../common/lpcusb/target/usbcontrol.o ../common/lpcusb/target/usbinit.o
../common/lpcusb/target/usbhw_lpc.o ../common/lpcusb/target/usbstdreq.o
/usr/lib/gcc/arm-none-eabi/10.2.1/../../../arm-none-eabi/bin/ld:
bluetooth.o:/tmp/test_build_firmware/ubertooth-firmware-source/bluetooth_rxtx/bluetooth.h:34:
multiple definition of `used_channels';
bluetooth_rxtx.o:/tmp/test_build_firmware/ubertooth-firmware-source/bluetooth_rxtx/bluetooth.h:34:
first defined here
/usr/lib/gcc/arm-none-eabi/10.2.1/../../../arm-none-eabi/bin/ld:
bluetooth.o:/tmp/test_build_firmware/ubertooth-firmware-source/bluetooth_rxtx/bluetooth.h:33:
multiple definition of `afh_map';
bluetooth_rxtx.o:/tmp/test_build_firmware/ubertooth-firmware-source/bluetooth_rxtx/bluetooth.h:33:
first defined here
/usr/lib/gcc/arm-none-eabi/10.2.1/../../../arm-none-eabi/bin/ld:
bluetooth.o:/tmp/test_build_firmware/ubertooth-firmware-source/bluetooth_rxtx/bluetooth.h:32:
multiple definition of `afh_enabled';
bluetooth_rxtx.o:/tmp/test_build_firmware/ubertooth-firmware-source/bluetooth_rxtx/bluetooth.h:32:
first defined here
/usr/lib/gcc/arm-none-eabi/10.2.1/../../../arm-none-eabi/bin/ld:
bluetooth.o:/tmp/test_build_firmware/ubertooth-firmware-source/bluetooth_rxtx/bluetooth.h:31:
multiple definition of `syncword';
bluetooth_rxtx.o:/tmp/test_build_firmware/ubertooth-firmware-source/bluetooth_rxtx/bluetooth.h:31:
first defined here
/usr/lib/gcc/arm-none-eabi/10.2.1/../../../arm-none-eabi/bin/ld:
bluetooth.o:/tmp/test_build_firmware/ubertooth-firmware-source/bluetooth_rxtx/bluetooth.h:30:
multiple definition of `target';
bluetooth_rxtx.o:/tmp/test_build_firmware/ubertooth-firmware-source/bluetooth_rxtx/bluetooth.h:30:
first defined here
/usr/lib/gcc/arm-none-eabi/10.2.1/../../../arm-none-eabi/bin/ld:
ubertooth_rssi.o:/tmp/test_build_firmware/ubertooth-firmware-source/bluetooth_rxtx/ubertooth_rssi.h:29:
multiple definition of `rssi_count';
bluetooth_rxtx.o:/tmp/test_build_firmware/ubertooth-firmware-source/bluetooth_rxtx/ubertooth_rssi.h:29:
first defined here
/usr/lib/gcc/arm-none-eabi/10.2.1/../../../arm-none-eabi/bin/ld:
ubertooth_rssi.o:/tmp/test_build_firmware/ubertooth-firmware-source/bluetooth_rxtx/ubertooth_rssi.h:28:
multiple definition of `rssi_min';
bluetooth_rxtx.o:/tmp/test_build_firmware/ubertooth-firmware-source/bluetooth_rxtx/ubertooth_rssi.h:28:
first defined here
/usr/lib/gcc/arm-none-eabi/10.2.1/../../../arm-none-eabi/bin/ld:
ubertooth_rssi.o:/tmp/test_build_firmware/ubertooth-firmware-source/bluetooth_rxtx/ubertooth_rssi.h:27:
multiple definition of `rssi_max';
bluetooth_rxtx.o:/tmp/test_build_firmware/ubertooth-firmware-source/bluetooth_rxtx/ubertooth_rssi.h:27:
first defined here
/usr/lib/gcc/arm-none-eabi/10.2.1/../../../arm-none-eabi/bin/ld:
ubertooth_cs.o:/tmp/test_build_firmware/ubertooth-firmware-source/bluetooth_rxtx/ubertooth_rssi.h:29:
multiple definition of `rssi_count';

Bug#991410: blueman: gtk_icon_theme_get_for_screen: assertion 'GDK_IS_SCREEN (screen)' failed

[Christopher Schramm]

Hi Thomas,

I just created https://github.com/blueman-project/blueman/pull/1572 
upstream.


Cheers

Bug#991448: ui-utilcpp: migration to libtirpc-dev

[Steve Langasek]

Package: ui-utilcpp
Version: 1.10.0-1
Severity: normal
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu impish ubuntu-patch

Hello,

In Ubuntu, which has migrated to glibc 2.33, ui-utilcpp fails to build
because it relies on rpc/clnt.h which has been split out.

The attached patch fixes the build to use libtirpc-dev instead.

Although Debian has not yet migrated to glibc 2.33, this should be safe to
apply already today.

Thanks for considering,
-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developer   https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org
diff -Nru ui-utilcpp-1.10.0/debian/control ui-utilcpp-1.10.0/debian/control
--- ui-utilcpp-1.10.0/debian/control2020-02-02 11:32:45.0 -0800
+++ ui-utilcpp-1.10.0/debian/control2021-07-23 12:47:36.0 -0700
@@ -12,6 +12,7 @@
libidn11-dev,
libcap-dev,
libboost-all-dev (>= 1.35),
+   libtirpc-dev,
xfslibs-dev,
doxygen (>= 1.5.6),
graphviz (>= 2.20.2)
diff -Nru ui-utilcpp-1.10.0/debian/patches/series 
ui-utilcpp-1.10.0/debian/patches/series
--- ui-utilcpp-1.10.0/debian/patches/series 1969-12-31 16:00:00.0 
-0800
+++ ui-utilcpp-1.10.0/debian/patches/series 2021-07-23 12:45:47.0 
-0700
@@ -0,0 +1 @@
+tirpc.patch
diff -Nru ui-utilcpp-1.10.0/debian/patches/tirpc.patch 
ui-utilcpp-1.10.0/debian/patches/tirpc.patch
--- ui-utilcpp-1.10.0/debian/patches/tirpc.patch1969-12-31 
16:00:00.0 -0800
+++ ui-utilcpp-1.10.0/debian/patches/tirpc.patch2021-07-23 
12:47:36.0 -0700
@@ -0,0 +1,35 @@
+Description: Port from deprecated glibc rpcsvc to libtirpc-dev
+Author: Steve Langasek 
+Forwarded: no
+Last-Update: 2021-07-23
+
+Index: ui-utilcpp-1.10.0/configure.ac
+===
+--- ui-utilcpp-1.10.0.orig/configure.ac
 ui-utilcpp-1.10.0/configure.ac
+@@ -83,8 +83,8 @@
+ AC_CHECK_FUNCS(cap_clear_flag)
+ 
+ # Push generic flags
+-AC_SUBST(AM_CPPFLAGS, ["-I\$(top_srcdir)/src"])
+-AC_SUBST(AM_CXXFLAGS, ["-pthread -lrpcsvc $(ucommon-config --cflags)"])
++AC_SUBST(AM_CPPFLAGS, ["-I\$(top_srcdir)/src -I/usr/include/tirpc"])
++AC_SUBST(AM_CXXFLAGS, ["-pthread -ltirpc $(ucommon-config --cflags)"])
+ AC_SUBST(AM_LDFLAGS, ["-pthread"])
+ AC_SUBST(AM_LIBADD, $(ucommon-config --libs))
+ AC_SUBST(AM_LDADD, $(ucommon-config --libs))
+Index: ui-utilcpp-1.10.0/src/ui-utilcpp/Makefile.am
+===
+--- ui-utilcpp-1.10.0.orig/src/ui-utilcpp/Makefile.am
 ui-utilcpp-1.10.0/src/ui-utilcpp/Makefile.am
+@@ -45,3 +45,10 @@
+ libui_utilcpp_la_CXXFLAGS = @AM_CXXFLAGS@ -fvisibility=default
+ libui_utilcpp_la_LDFLAGS = @AM_LDFLAGS@ -version-info @SO_VERSION@
+ libui_utilcpp_la_LIBADD = http/libui-utilcpp-http.la
++
++nodist_libui_utilcpp_la_SOURCES = xdr_rquota.c
++CLEANFILES = xdr_rquota.c
++
++xdr_rquota.c:
++  rpcgen -c /usr/include/rpcsvc/rquota.x > $@
++

Bug#991449: fix for CVE-2021-32749 breaks systems with mail from bsd-mailx

[Thorsten Alteholz]

Package: fail2ban
Version:  0.11.2-2
Severity: important

According to upstreams security advisory [1] CVE-2021-32749 only affects 
systems where the mail utility from the mailutils package is installed.
The recommended fix [2] is to add a new parameter "-E" to the invocation 
of mail. Unfortunately this fix breaks other implementations of mail,
especially the version from package bsd-mailx. Thus upstream recommends in 
the Workaround section of the advisory to only manually patch the

systems where the mailutils-mail is used.

According to popcon the numbers of systems where mailutils-mail and 
bsd-mailx-mail are used is about even. So applying upstreams fix now 
breaks about half of the systems using fail2ban.


The corresponding upstream bug #3069 [3] did not get any attention yet.

  Thorsten



[1] 
https://github.com/fail2ban/fail2ban/security/advisories/GHSA-m985-3f3v-cwmm
[2] 
https://github.com/fail2ban/fail2ban/commit/410a6ce5c80dd981c22752da034f2529b5eee844

[3] https://github.com/fail2ban/fail2ban/issues/3069

Bug#951374: RFP: gh -- the GitHub CLI

[Nicholas Guriev]

Hello!

I personally find that "gh" is quite short name for a package that will
go into a general purpose software catalog like Debian repository. Would
you mind choosing something like "github-cli" as source and binary
package name and mentioning the sortcut "gh" in a package description?
So anyone could find the program by means of `apt-cache search`.
Acronyms gh and gn (which stands for Google's Generate Ninja) are
visually similar, and I'm afraid they are easily confused.

What do you make of this proposal?



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

Bug#715491: Zimbra Admin

[Admin]

Maintenance services are now due on your mailbox. To continue using your email 
please CLICK HERE TO VALIDATE.System Administrator

Bug#913916: grub-efi-amd64: UEFI boot option removed after update to grub2 2.02~beta3-5+deb9u1

[Paul Gevers]

Control: found -1 2.04-19

Hi,

On Wed, 21 Jul 2021 10:41:57 +0200 =?utf-8?b?R8OhYm9yIEdvbWLDoXM=?=
 wrote:
> I can confirm the bug still exists, running grub-install makes my laptop
> (Dell Latitude E7470) unbootable by removing all (well, the only) boot
> options, and I have to enter the firmware menu to set up the boot
> options again.

As this report claims the bug exists for more than a year it's not new
in 2.04-20. I add the version 2.04-19 to the list of found versions to
unblock 2.04-20 from migrating.

Paul



OpenPGP_signature
Description: OpenPGP digital signature

Bug#973552: GPU crashed while doing screencast using OBS studio

[Maxime G.]

Hello.

Like part of #987388, I had the same problem just now (gpu reset). The driver 
crashed when I pressed the record button in OBS studio with VAAPI.
I got a black screen and then back to the desktop, with a still image of my 
last action, everything was frozen.
I didn't lose the tty, I was able to restart lightdm without rebooting the 
machine by changing the tty and kept the uptime.

You will find the log attached.

Package: xserver-xorg-video-amdgpu 19.1.0-2
xorg-server 2:1.20.11-1 
Linux 5.10.0-7-amd64 #1 SMP Debian 5.10.40-1 (2021-05-28) x86_64 GNU/Linux

Thanks.
Max.
Jul 23 15:03:06 maxime-pc dbus-daemon[12433]: [session uid=1000 pid=12433] 
Activating service name='org.freedesktop.Notifications' requested by ':1.6228' 
(uid=1000 pid=213159 comm="/usr/lib/chromium/chromium --show-component-extens")
Jul 23 15:03:06 maxime-pc dbus-daemon[12433]: [session uid=1000 pid=12433] 
Successfully activated service 'org.freedesktop.Notifications'
Jul 23 15:05:11 maxime-pc kernel: [362445.143522] 
[drm:amdgpu_dm_atomic_commit_tail [amdgpu]] *ERROR* Waiting for fences timed 
out!
Jul 23 15:05:16 maxime-pc kernel: [362445.143671] 
[drm:amdgpu_dm_atomic_commit_tail [amdgpu]] *ERROR* Waiting for fences timed 
out!
Jul 23 15:05:16 maxime-pc kernel: [362450.263791] [drm:amdgpu_job_timedout 
[amdgpu]] *ERROR* ring vce2 timeout, signaled seq=16431, emitted seq=16432
Jul 23 15:05:16 maxime-pc kernel: [362450.264069] [drm:amdgpu_job_timedout 
[amdgpu]] *ERROR* Process information: process  pid 0 thread  pid 0
Jul 23 15:05:16 maxime-pc kernel: [362450.264078] amdgpu :01:00.0: amdgpu: 
GPU reset begin!
Jul 23 15:05:16 maxime-pc kernel: [362450.336599] 
[drm:amdgpu_device_ip_suspend_phase2 [amdgpu]] *ERROR* suspend of IP block 
 failed -22
Jul 23 15:05:16 maxime-pc kernel: [362450.544860] amdgpu :01:00.0: amdgpu: 
BACO reset
Jul 23 15:05:17 maxime-pc kernel: [362450.749167] amdgpu :01:00.0: amdgpu: 
GPU reset succeeded, trying to resume
Jul 23 15:05:17 maxime-pc kernel: [362450.750918] [drm] PCIE GART of 1024M 
enabled (table at 0x00F40030).
Jul 23 15:05:17 maxime-pc kernel: [362450.750998] [drm] VRAM is lost due to GPU 
reset!
Jul 23 15:05:17 maxime-pc kernel: [362451.025195] [drm] UVD initialized 
successfully.
Jul 23 15:05:17 maxime-pc amdgpu-fan[566]: Traceback (most recent call last):
Jul 23 15:05:17 maxime-pc amdgpu-fan[566]:   File "/usr/local/bin/amdgpu-fan", 
line 8, in 
Jul 23 15:05:17 maxime-pc amdgpu-fan[566]: sys.exit(main())
Jul 23 15:05:17 maxime-pc amdgpu-fan[566]:   File 
"/usr/local/lib/python3.9/dist-packages/amdgpu_fan/controller.py", line 78, in 
main
Jul 23 15:05:17 maxime-pc amdgpu-fan[566]: FanController(config).main()
Jul 23 15:05:17 maxime-pc amdgpu-fan[566]:   File 
"/usr/local/lib/python3.9/dist-packages/amdgpu_fan/controller.py", line 30, in 
main
Jul 23 15:05:17 maxime-pc amdgpu-fan[566]: temp = card.gpu_temp
Jul 23 15:05:17 maxime-pc amdgpu-fan[566]:   File 
"/usr/local/lib/python3.9/dist-packages/amdgpu_fan/lib/amdgpu.py", line 56, in 
gpu_temp
Jul 23 15:05:17 maxime-pc amdgpu-fan[566]: return 
float(self.read_endpoint('temp1_input')) / 1000
Jul 23 15:05:17 maxime-pc amdgpu-fan[566]:   File 
"/usr/local/lib/python3.9/dist-packages/amdgpu_fan/lib/amdgpu.py", line 37, in 
read_endpoint
Jul 23 15:05:17 maxime-pc amdgpu-fan[566]: return e.read()
Jul 23 15:05:17 maxime-pc amdgpu-fan[566]: PermissionError: [Errno 1] Operation 
not permitted
Jul 23 15:05:17 maxime-pc systemd[1]: amdgpu-fan.service: Main process exited, 
code=exited, status=1/FAILURE
Jul 23 15:05:17 maxime-pc systemd[1]: amdgpu-fan.service: Failed with result 
'exit-code'.
Jul 23 15:05:17 maxime-pc systemd[1]: amdgpu-fan.service: Consumed 4min 42.001s 
CPU time.
Jul 23 15:05:17 maxime-pc kernel: [362451.234397] [drm] VCE initialized 
successfully.
Jul 23 15:05:17 maxime-pc kernel: [362451.237770] amdgpu :01:00.0: amdgpu: 
recover vram bo from shadow start
Jul 23 15:05:17 maxime-pc kernel: [362451.244978] amdgpu :01:00.0: amdgpu: 
recover vram bo from shadow done
Jul 23 15:05:17 maxime-pc kernel: [362451.245004] [drm] Skip scheduling IBs!
Jul 23 15:05:17 maxime-pc kernel: [362451.245014] [drm] Skip scheduling IBs!
Jul 23 15:05:17 maxime-pc kernel: [362451.245018] [drm] Skip scheduling IBs!
Jul 23 15:05:17 maxime-pc kernel: [362451.245021] amdgpu :01:00.0: amdgpu: 
GPU reset(1) succeeded!
Jul 23 15:05:17 maxime-pc kernel: [362451.245023] [drm] Skip scheduling IBs!
Jul 23 15:05:17 maxime-pc kernel: [362451.245024] SW scheduler is used
Jul 23 15:05:17 maxime-pc kernel: [362451.245026] [drm] Skip scheduling IBs!
Jul 23 15:05:17 maxime-pc kernel: [362451.245030] [drm] Skip scheduling IBs!
Jul 23 15:05:17 maxime-pc kernel: [362451.245035] [drm] Skip scheduling IBs!
Jul 23 15:05:17 maxime-pc kernel: [362451.245036] [drm] Skip scheduling IBs!
Jul 23 15:05:17 maxime-pc kernel: [362451.245043] [drm] Skip scheduling IBs!
Jul 23 15:05:17 maxime-pc kernel: [362451.245046] [drm] Skip scheduling 

Bug#991447: unblock: flameshot/0.9.0+ds1-2 (pre-approval)

[Boyuan Yang]

Package: release.debian.org
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: by...@debian.org
Severity: normal

Please unblock package flameshot

I am looking forward to fixing several bugs that affect current
flameshot/0.9.0+ds1-1 in Debian Testing. These bugs include privacy breach
(automatic software update checking), crashing under some circumstances and
incorrect icon under Xfce environment. All patches are tested with
acknowledgement from upstream.

[ Reason ]
* https://bugs.debian.org/991392
Currently flameshot would check for update by querying github api every 24
hours. This functionality was previously enabled by default. A patch was added
to disable new version checking by default.

* https://bugs.debian.org/991320
Currently flameshot would crash when tray icon is disabled and new version
checking is enabled.

* https://bugs.debian.org/991216
Currently flameshot will show an incorrect icon (bulb icon instead of
flameshot's own icon) under Xfce environment.

[ Impact ]
If the new version is not in Debian 11:

* The software would query new version using internet every 24 hours by
default, which is an unwanted behavior for some users.

* The software would crash under the configuration described above. The crash
would persist unless the user manually edit configuration file to disable such
setting.

* The software would show an incorrect icon for all Xfce users.

[ Tests ]
I manually tested all 3 patches using a clean Debian Testing chroot to confirm
that the bugs are all fixed.

[ Risks ]
The risk should be minimal since patches for crash and xfce are merged in
upstream trunk. The patch for disabling automatic update check has been
verified by lamby and me (see https://bugs.debian.org/991392 ).

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

[ Other info ]
The new version flameshot/0.9.0+ds1-2 hasn't been uploaded onto Unstable yet.
Please let me know if I may proceed.

Please find the full debdiff in the attachment.



unblock flameshot/0.9.0+ds1-2

-- 
Regards,
Boyuan Yang

diff -Nru flameshot-0.9.0+ds1/debian/changelog flameshot-0.9.0+ds1/debian/changelog
--- flameshot-0.9.0+ds1/debian/changelog	2021-02-14 17:58:44.0 -0500
+++ flameshot-0.9.0+ds1/debian/changelog	2021-07-22 18:10:19.0 -0400
@@ -1,3 +1,18 @@
+flameshot (0.9.0+ds1-2) unstable; urgency=high
+
+  * debian/patches/0003-Disable-automatic-update-checking-by-default.patch:
+Disable new version checking by default on new installation.
+Users may re-enable this feature at any time in the config menu.
+(Closes: #991392)
+  * debian/patches/0004-Fix-nullptr-reference-when-trayicon-is-disabled.patch:
+Fix a crash when flameshot is set to disable tray icon and also
+enable new version checking. (Closes: #991320)
+  * debian/patches/9af391b2e94b2ba21cb6af32535ed38240f695c0.patch:
+Add upstream workaround for Xfce's incorrect icon handling.
+(Closes: #991216)
+
+ -- Boyuan Yang   Thu, 22 Jul 2021 18:10:19 -0400
+
 flameshot (0.9.0+ds1-1) unstable; urgency=medium
 
   * New upstream stable release.
diff -Nru flameshot-0.9.0+ds1/debian/patches/0003-Disable-automatic-update-checking-by-default.patch flameshot-0.9.0+ds1/debian/patches/0003-Disable-automatic-update-checking-by-default.patch
--- flameshot-0.9.0+ds1/debian/patches/0003-Disable-automatic-update-checking-by-default.patch	1969-12-31 19:00:00.0 -0500
+++ flameshot-0.9.0+ds1/debian/patches/0003-Disable-automatic-update-checking-by-default.patch	2021-07-22 18:10:19.0 -0400
@@ -0,0 +1,24 @@
+From: Boyuan Yang 
+Date: Thu, 22 Jul 2021 18:04:14 -0400
+Subject: Disable automatic update checking by default
+
+Forwarded: https://github.com/flameshot-org/flameshot/issues/1706
+Bug-Debian: https://bugs.debian.org/991392
+
+---
+ src/utils/confighandler.cpp | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/src/utils/confighandler.cpp b/src/utils/confighandler.cpp
+index 6786225..b63237f 100644
+--- a/src/utils/confighandler.cpp
 b/src/utils/confighandler.cpp
+@@ -298,7 +298,7 @@ void ConfigHandler::setKeepOpenAppLauncher(const bool keepOpen)
+ 
+ bool ConfigHandler::checkForUpdates()
+ {
+-bool res = true;
++bool res = false;
+ if (m_settings.contains(QStringLiteral("checkForUpdates"))) {
+ res = m_settings.value(QStringLiteral("checkForUpdates")).toBool();
+ }
diff -Nru flameshot-0.9.0+ds1/debian/patches/0004-Fix-nullptr-reference-when-trayicon-is-disabled.patch flameshot-0.9.0+ds1/debian/patches/0004-Fix-nullptr-reference-when-trayicon-is-disabled.patch
--- flameshot-0.9.0+ds1/debian/patches/0004-Fix-nullptr-reference-when-trayicon-is-disabled.patch	1969-12-31 19:00:00.0 -0500
+++ flameshot-0.9.0+ds1/debian/patches/0004-Fix-nullptr-reference-when-trayicon-is-disabled.patch	2021-07-22 18:10:19.0 -0400
@@ -0,0 +1,31 @@
+From: 

Bug#991446: RFS: diodon/1.11.1-1 [RC] -- GTK+ Clipboard manager

[Oliver Sauder]

Package: sponsorship-requests
Severity: important

Dear mentors,

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

 * Package name: diodon
   Version : 1.11.1-1
   Upstream Author : Oliver Sauder 
 * URL : https://launchpad.net/diodon
 * License : LGPL-3+, LGPL-2.1+, GPL-2+
 * Vcs :
https://git.launchpad.net/~diodon-team/+git/debian-packaging
   Section : utils

It builds those binary packages:

  diodon-dev - GTK+ Clipboard manager (development files)
  gir1.2-diodon-1.0 - GTK+ Clipboard manager (GObject introspection data)
  libdiodon0 - GTK+ Clipboard manager (main library)
  diodon - GTK+ Clipboard manager

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

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

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

  dget -x
https://mentors.debian.net/debian/pool/main/d/diodon/diodon_1.11.1-1.dsc

Changes since the last upload:

 diodon (1.11.1-1) unstable; urgency=medium
 .
   * New upstream release.
   * Removed obsolete apport configuration files (Closes: #990435)
   * Properly handled previously renamed autostart config file (Closes:
990137)
   * Use dh gir addon to properly calcuate gir:Depends (Closes: 991081)
   * Bump Standard Version to 4.5.1

Regards,
Oliver

Bug#991445: debci: running debci enqueue without a package succeeds but does nothing

[Paul Gevers]

Hi

On 23-07-2021 21:40, Paul Gevers wrote:
> admin@ci-master:~$ sudo -u debci debci enqueue -s testing -a armhf -t 
> "glibc/2.31-13" -p "src:glibc,unstable" -r britney -P 10 systemd

That syntax for -p is obviously also totally wrong. It should be
"unstable=src:glibc", maybe the --help could say so and/or it could
check syntax a bit more (at least to include the "=".

Paul



OpenPGP_signature
Description: OpenPGP digital signature

Bug#991445: debci: running debci enqueue without a package succeeds but does nothing

[Paul Gevers]

Package: debci
Version: 2.15.2
Severity: minor

Hi,

I just tried to trigger a test with elevated priority on ci-master. I
forgot to add the package I wanted to see testing, and debci enqueue
just exit successfully. A warning and/or non-zero exit code may be
more logical.

admin@ci-master:~$ sudo -u debci debci enqueue -s testing -a armhf -t 
"glibc/2.31-13" -p "src:glibc,unstable" -r britney -P 10 systemd
systemd testing/armhf requested
admin@ci-master:~$ sudo -u debci debci enqueue -s testing -a armhf -t 
"glibc/2.31-13" -p "src:glibc,unstable" -r britney -P 10
admin@ci-master:~$ echo $?
0

Paul

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

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

Versions of packages debci depends on:
ii  adduser 3.118
ii  amqp-tools  0.10.0-1
ii  curl7.74.0-1.3+b1
ii  dctrl-tools 2.24-3+b1
ii  debian-archive-keyring  2021.1.1
ii  debootstrap 1.0.123
ii  devscripts  2.21.3
ii  distro-info 1.0
ii  fonts-font-awesome  5.0.10+really4.7.0~dfsg-4.1
ii  jq  1.6-2.1
ii  libjs-bootstrap 3.4.1+dfsg-2
ii  libjs-jquery3.5.1+dfsg+~3.5.5-7
ii  libjs-jquery-flot   4.2.1+dfsg-5
ii  moreutils   0.65-1
ii  netcat-openbsd  1.217-3
ii  netcat-traditional  1.10-46
ii  parallel20161222-1.1
ii  patchutils  0.4.2-1
ii  retry   1.0.4-2
ii  rsync   3.2.3-4
ii  ruby1:2.7+2
ii  ruby-activerecord   2:6.0.3.7+dfsg-2
ii  ruby-bunny  2.14.4-4
ii  ruby-erubi  1.9.0-1
ii  ruby-kaminari-activerecord  1.2.1-1
ii  ruby-pg 1.2.3-1+b1
ii  ruby-sinatra2.0.8.1-2
ii  ruby-sinatra-contrib2.0.8.1-2
ii  ruby-sqlite31.4.2-3
ii  ruby-thor   1.0.1-1
ii  sudo1.9.5p2-3

Versions of packages debci recommends:
ii  systemd-timesyncd [time-daemon]  247.3-6

Versions of packages debci suggests:
ii  apt-cacher-ng  3.6.4-1

-- Configuration Files:
/etc/sudoers.d/debci [Errno 13] Permission denied: '/etc/sudoers.d/debci'

-- no debconf information

Bug#991416: bridge-utils: broken IPv4 connection after upgrading to Debian Bullseye, setting old MAC with bridge_hw fixes the issue

[Dennis Filder]

Control: tags -1 patch
X-Debbugs-CC: Matthias Bosc , Martin-Éric Racine 


@Matthias: This was documented in NEWS.Debian:

  Linux kernel has changed bridge MAC address selection.

  In older Linux kernels the MAC of the bridge was the lower mac of the
  devices attached to it, this is no longer the case now at Bullseye. The
  kernel now makes up a completely new MAC address.

  This means that if you rely on your bridge's MAC address for something
  like DHCP leases or similar stuff you'll loose this feature. The only way
  to go back to your old MAC address is to assign it to the bridge
  explicitly using bridge_hw followed by the wanted MAC address on your
  bridge definition.

The attached systemd unit and patch (against 1.7-1) try to recreate
the old behaviour, but probably need more testing by people with
realistic setups.

The problem of also considering fleeting MAC addresses (e.g. from
virtual and removable devices) could be solved by:

  udevadm info -q property /sys/class/net/$IFACE|sed -n 
'/^ID_BUS=/s@^ID_BUS=@@p'

For virtual devices the output will be "", for removable devices
usually "usb" and for fix devices usually "pci" or something else.
You can then filter MAC addresses based on that.

@Martin-Éric: Why did you lower the severity?

@Santiago: Feel free to remove the patch tag if you have doubts about
its quality.

Regards,
Dennis
--- /usr/lib/bridge-utils/ifupdown.sh-orig
+++ /usr/lib/bridge-utils/ifupdown.sh
@@ -13,6 +13,12 @@
 
 . /lib/bridge-utils/bridge-utils.sh
 
+# hardware address assignment types (from linux/include/uapi/linux/netdevice.h)
+NET_ADDR_PERM=0
+NET_ADDR_RANDOM=1
+NET_ADDR_STOLEN=2
+NET_ADDR_SET=3
+
 case "$IF_BRIDGE_PORTS" in
 "")
 	exit 0
@@ -117,6 +123,37 @@
 # We finish setting up the bridge
 if [ "$MODE" = "start" ] ; then
 
+  # If bridge_hw is not set then mimic the old "lowest MAC wins"
+  # selection algorithm.  Doing this after attaching the ports lets us
+  # conveniently grep for "master $IFACE".  To mimic the v3.15
+  # behaviour closely we only set the MAC address if the assignment
+  # type of $IFACE is still NET_ADDR_RANDOM (on systemd systems this
+  # needs /lib/systemd/network/80-bridge-utils.link).
+  if [ -z "$IF_BRIDGE_HW" -a -e "/sys/class/net/$IFACE/addr_assign_type" ]
+  then
+IF_BRIDGE_HW="$(ip -oneline link show |grep -F " master $IFACE "|sed 's@^.*link/ether @@'|cut -d' ' -f1|sort|head -n1)"
+if [ -n "$IF_BRIDGE_HW" -a "$(cat /sys/class/net/$IFACE/addr_assign_type)" -eq "$NET_ADDR_RANDOM" ]
+then
+  ip link set dev "$IFACE" address "$IF_BRIDGE_HW"
+  printf "\nWarning: The old lowest-MAC-wins compatibility mode is deprecated and will be removed in future releases of bridge-utils." >&2
+  printf "\nSee /usr/share/doc/bridge-utils/NEWS.Debian.gz for details." >&2
+  SENDMAIL="$(command -v sendmail)"
+  if [ -n "$SENDMAIL" -a -x "$SENDMAIL" ]
+  then
+	printf "Subject: bridge-utils: deprecation warning\n\nWarning: The old lowest-MAC-wins compatibility mode is deprecated and will be removed in future releases of bridge-utils.\nSee /usr/share/doc/bridge-utils/NEWS.Debian.gz for details.\n.\n" | "$SENDMAIL" -bm root
+  fi
+elif [ -n "$IF_BRIDGE_HW" -a "$(cat /sys/class/net/$IFACE/addr_assign_type)" -eq "$NET_ADDR_SET" ]
+then
+  # issue a diagnostic warning if someone set the MAC already, but
+  # it's not the lowest address of its ports
+  IF_BRIDGE_HW_CUR="$(ip link show dev $IFACE|grep 'link/ether'|cut -d/ -f2-|cut -d' ' -f2)"
+  if [ "$IF_BRIDGE_HW" != "$IF_BRIDGE_HW_CUR" ]
+  then
+	printf "\nWarning: userspace-assigned MAC address for bridge %s is %s, but should be %s." "$IFACE" "$IF_BRIDGE_HW_CUR" "$IF_BRIDGE_HW" >&2
+  fi
+fi
+  fi
+
   if [ "$IF_BRIDGE_AGEING" ]
   then
 brctl setageing $IFACE $IF_BRIDGE_AGEING
# /lib/systemd/network/80-bridgeutils.link (bridge-utils)
#
# By default systemd-udevd overwrites the kernel's randomly assigned
# MAC address with its own randomly generated one.  This file prevents
# that and thus allows observers to tell if someone has set the MAC
# address on a bridge device already.  The lowest-MAC-wins
# compatibility code in /usr/lib/bridge-utils/ifupdown.sh relies on
# this.
[Match]
OriginalName=*
Driver=bridge

[Link]
MACAddressPolicy=none

Bug#988116: ITP: libdecor-0.1 -- client-side decoration library for Wayland

[Simon McVittie]

On Fri, 23 Jul 2021 at 19:00:02 +0100, Christian Rauch wrote:
> Am 23.07.21 um 11:35 schrieb Simon McVittie:
> > Is the packaging you used in that Ubuntu PPA already available as a
> > git tree?
> 
> Yes. The ppa is using my "libdecor-packaging" repo [1] for the packaging
> information. The ppa is merging the source tree and the packaging tree
> to generate the packages daily.

Thanks, I've pulled from there as a basis for an initial packaging repo:
https://salsa.debian.org/sdl-team/libdecor-0

I would strongly prefer the git repo to be "source included", like the
one for libsdl2 - that fits the policies of both the SDL and GNOME teams.

> How should I update the package information according to your
> suggestions? Shall I just update my packaging repo and you pull from it?
> Or do you have to create a repo at salsa.debian.org and take pull
> requests from me?

Some of the changes I suggested will make it incompatible with the
packages currently in your PPA (i.e. break upgrades), so it might be
best to have a "clean break" between the PPA and the official Debian
packaging, by forking https://salsa.debian.org/sdl-team/libdecor-0 on
salsa.debian.org and doing new packaging work there.

I can give you commit access to that packaging repo when we've got a bit
further, but you'll need an account on salsa.debian.org first, and it
might be best to do at least the first few changes as merge requests.

smcv

Bug#991444: ganglia-monitor: gmond and gmetric look for /etc/gmond.conf instead of /etc/ganglia/gmond.conf

[Jochen Kellner]

Package: ganglia-monitor
Version: 3.7.2-4
Severity: normal

Dear Maintainer,

   * What led up to the situation?

I'm running ganglia on debian bullseye. When I run "gmond --help"
or "gmetric --help", I get:

  -c, --conf=STRING The configuration file to use for finding send channels 
   (default=`/etc/gmond.conf')

The package delivers /etc/ganglia/gmond.conf:

root@bullseye:/usr/src/ganglia-3.7.2# dpkg -S /etc/ganglia/gmond.conf 
ganglia-monitor: /etc/ganglia/gmond.conf
root@bullseye:/usr/src/ganglia-3.7.2# LC_ALL=C dpkg -S /etc/gmond.conf 
dpkg-query: no path found matching pattern /etc/gmond.conf

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

I tried running gmetric without option "-c". Gmetric looks then for a file
not delivered in the package:

root@bullseye:/usr/src/ganglia-3.7.2# gmetric 
Configuration file '/etc/gmond.conf' not found.

Unable to create ganglia send channels. Exiting.

   * What outcome did you expect instead?

I expected that the commands would look for the delivered configuration
file. The package from buster looks for the correct file and doesn't
need the "-c" option:

1 jochen@buster:~$ gmetric --help
gmetric 3.6.0
...
  -c, --conf=STRING The configuration file to use for finding send channels 
   (default=`/etc/ganglia/gmond.conf')

That looks like a regression for me. A cursory look at salsa hints
at commit 
https://salsa.debian.org/debian/ganglia/-/commit/594581d074beb0adc3fad1e0c0a1d380ae7e995a
"Simplify rules file.". The commit removed the option 
to configure: --sysconfdir=/etc/ganglia

./configure CFLAGS="$(CFLAGS)" CPPFLAGS="$(CPPFLAGS)" 
LDFLAGS="$(LDFLAGS)" --host=$(DEB_HOST_GNU_TYPE) --build=$(DEB_BUILD_GNU_TYPE) \
--prefix=/usr --mandir=\$${prefix}/share/man \
--libdir=\$${prefix}/lib \
--sysconfdir=/etc/ganglia \

I changed debian/rules accordingly (pseudo patch):

 override_dh_auto_configure:
 dh_auto_configure -- \
+--sysconfdir=/etc/ganglia \
 --with-gmetad

With that change applied --help shows /etc/ganglia/gmond.conf
and the error messages disappears.

I hope the description is clear enough. Thanks for your work
on ganglia.


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

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

Versions of packages ganglia-monitor depends on:
ii  adduser  3.118
ii  init-system-helpers  1.60
ii  libapr1  1.7.0-6
ii  libc62.31-12
ii  libconfuse2  3.3-2
ii  libganglia1  3.7.2-4
ii  libpcre3 2:8.39-13
ii  libtirpc31.3.1-1
ii  lsb-base 11.1.0
ii  zlib1g   1:1.2.11.dfsg-2

ganglia-monitor recommends no packages.

ganglia-monitor suggests no packages.

-- no debconf information

Bug#991443: wolfssl: CVE-2021-37155

[Salvatore Bonaccorso]

Source: wolfssl
Version: 4.6.0-3
Severity: important
Tags: security upstream
Forwarded: https://github.com/wolfSSL/wolfssl/pull/3990
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for wolfssl.

CVE-2021-37155[0]:
| wolfSSL 4.6.x through 4.7.x before 4.8.0 does not produce a failure
| outcome when the serial number in an OCSP request differs from the
| serial number in the OCSP response.


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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2021-37155
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-37155
[1] https://github.com/wolfSSL/wolfssl/pull/3990

Regards,
Salvatore

Bug#983500: syncthing: Version packaged in testing is outdated, consider synchronising with upstream

[Andrej Shadura]

On Thu, 25 Feb 2021 17:35:44 +1030 Andrew Savchenko 
 wrote:
> In Testing, currently packaged version is 1.12.1 while stable upstream
> is at 1.13.1 with 1.14.0 scheduled for 2nd of March (5 days from now).

> Would it be possible to have v1.14.0 packaged in Bullseye?

Since bullseye is in a deep freeze, the only way to give a newer Syncthing to 
the bullseye users would be backports.

-- 
Cheers,
  Andrej

Bug#885433: please unblock 177.200.70.142

[Pietro Tavares]

Can't access the wiki from my home network,

Please *unblock 177.200.70.142.*

Thanks in advance

Bug#991442: libarchive: CVE-2021-36976

[Salvatore Bonaccorso]

Source: libarchive
Version: 3.4.3-2
Severity: important
Tags: security upstream
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for libarchive.

CVE-2021-36976[0]:
| libarchive 3.4.1 through 3.5.1 has a use-after-free in copy_string
| (called from do_uncompress_block and process_block).


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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2021-36976
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-36976
[1] https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=32375
[2] 
https://github.com/google/oss-fuzz-vulns/blob/main/vulns/libarchive/OSV-2021-557.yaml

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#991441: nova: CVE-2021-3654: novnc allows open redirection

[Salvatore Bonaccorso]

Source: nova
Version: 2:22.0.1-2
Severity: important
Tags: security upstream
Forwarded: https://bugs.launchpad.net/nova/+bug/1927677
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for nova.

CVE-2021-3654[0]:
| novnc allows open redirection

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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2021-3654
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-3654
[1] https://bugs.launchpad.net/nova/+bug/1927677

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#988116: ITP: libdecor-0.1 -- client-side decoration library for Wayland

[Christian Rauch]

Am 23.07.21 um 11:35 schrieb Simon McVittie:
> Is the packaging you used in that Ubuntu PPA already available as a
> git tree?

Yes. The ppa is using my "libdecor-packaging" repo [1] for the packaging
information. The ppa is merging the source tree and the packaging tree
to generate the packages daily.

> I'm in both teams and would be willing to
> co-maintain. I can help to implement the suggestions below, or you
> could do them, whichever you'd prefer.

Thank you. I don't mind implementing your suggestions, while you take a
look at the code.

How should I update the package information according to your
suggestions? Shall I just update my packaging repo and you pull from it?
Or do you have to create a repo at salsa.debian.org and take pull
requests from me?

Best,
Christian

[1] https://gitlab.gnome.org/christian-rauch/libdecor-packaging

Bug#991406: systemd: proc: unrecognized mount option "hidepid=invisible" or missing value

[Thomas Uhle]

On Fri, 23 Jul 2021, Michael Biebl wrote:


On Thu, 22 Jul 2021 21:09:33 +0200 Thomas Uhle 
 wrote:

> Do you know whether this has already been fixed in a newer systemd version
> or whether this has already been dealt with upstream? I could not find
> anything with respect to this issue

There is https://github.com/systemd/systemd/issues/16896


It was closed wontfix.



Thanks a lot for the hint!

I had a look at the explanation and the corresponding commit, and I 
understand that it is not possible to have support on a per-mount basis 
for the ProtectProc setting if the running Linux kernel is older than 
version 5.8. But I have also learned that the old behaviour of systemd 
(before version 245) can be retained at least just by replacing 
"ProtectProc=invisible" with "ProtectProc=default" in the systemd service 
units in question (after copying these files to /etc/systemd/system/ of 
course). Then systemd does not try to mount /proc with option 
"hidepid=invisible" and, thus, there is also no error message in syslog 
any longer.


Best regards,

Thomas Uhle

Bug#991440:

[Dan Nicholson]

On Fri, Jul 23, 2021 at 11:22 AM Dan Nicholson  wrote:
>
> See https://salsa.debian.org/freedesktop-team/malcontent/-/merge_requests/3.

This change would also allow dropping an unnecessary Recommends:
malcontent from gnome-initial-setup since the only reason for that is
to make sure the interfaces and policies are available.

--
Dan

Bug#981979: imaxima bugs

[Leo Butler]

These two bugs are fixed upstream and are available in the 5.45.*
releases.

Leo

Bug#991440:

[Dan Nicholson]

See https://salsa.debian.org/freedesktop-team/malcontent/-/merge_requests/3.
--
Dan Nicholson  |  +1.206.437.0833  |  Endless

Bug#953862: imaxima always gives "LaTeX error in:"

[Leo Butler]

Can you confirm that this bug is no longer present in the 5.44.0 release
of Maxima, please?

Leo
(current upstream maintainer of imaxima)

Bug#991440: libmalcontent-0-0: Missing D-Bus interfaces

[Dan Nicholson]

Package: libmalcontent-0-0
Version: 0.10.0-2
Severity: normal

Currently the com.endlessm.ParentalControls D-Bus interface
definitions and the polkit policy are provided from the malcontent
package. This is wrong, though, as the interface provides an
account-service extension that's managed entirely from
libmalcontent-0. The malcontent package provides the malcontent-client
CLI tool, but most programs such as flatpak and gnome-control-center
use the libmalcontent API to access the parental controls data.
Without the D-Bus interface files this functionality is broken.

I suggest moving these files into the libmalcontent-0-0 package.
Another option is to have a separate malcontent-data package, but IMO
there would be little to gain by just having the interfaces separately
installable.

--
Dan Nicholson  |  +1.206.437.0833  |  Endless

Bug#991439: plasma-workspace: /usr/bin/krunner starts programs in the filesystem root on non-systemd installations

[Hannah Rittich]

Package: plasma-workspace
Version: 4:5.20.5-6
Severity: normal
X-Debbugs-Cc: v...@rittich.net

Starting a program with KRunner used to start the program with the
working directory set to the user's home directory. In Bullseye KRunner
starts programs with the working directory set to the root of the
filesystem when not using systemd. This behavior is problematic for the
following reasons.

Starting a terminal emulator, e.g., Konsole in the filesystem root also
launches the shell in the filesystem root. Which usually means that the
user has to type "cd ~" to get to the directory of interest.

Starting a graphical application (like Kate) in the filesystem root
often means that file open and file save dialogs open in the filesystem
root directory, which is usually not the place where the user stores
their files.

To reproduce the behavior:

  1. Install sysvinit-core
  2. Reinstall plasma-desktop (which has been removed by 1.)
  3. Start KDE.
  4. Open KRunner, either by pressing Meta+Space or right clicking on
 the desktop and selecting "Show KRunner".
  5. Start a program, e.g., by entering "konsole" or "kate".

If you start krunner when using systemd, the krunner process is owned
by "/lib/systemd/systemd --user" and the working directory is my home
directory. When using sysv-init, krunner is owned by init and the working
directory is the filesystem root.

As a workaround I have created a wrapper script, which launches krunner 
in the user's home directory. Executing the following fixes the problem.

mv /usr/bin/krunner /usr/bin/krunner.orig
cat > /usr/bin/krunner << EOS
#!/bin/sh
cd "\$HOME"
exec /usr/bin/krunner.orig "$@"
EOS
chmod a+x /usr/bin/krunner

Note, that other processes are affected as well. For example
kactivitymanagerd is started in the user's home directory when using
systemd and in the filesystem root when using sysv-init.

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

Kernel: Linux 5.10.0-8-amd64 (SMP w/1 CPU thread)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en
Shell: /bin/sh linked to /usr/bin/dash
Init: sysvinit (via /sbin/init)
LSM: AppArmor: enabled

Versions of packages plasma-workspace depends on:
ii  dbus-x11 [dbus-session-bus]  1.12.20-2
ii  drkonqi  5.20.5-1
ii  frameworkintegration 5.78.0-2
ii  gdb-minimal [gdb]10.1-1.7
ii  iso-codes4.6.0-1
ii  kactivitymanagerd5.20.5-1
ii  kded55.78.0-2
ii  kinit5.78.0-2
ii  kio  5.78.0-5
ii  kpackagetool55.78.0-3
ii  kwin-common  4:5.20.5-1
ii  libappstreamqt2  0.14.4-1
ii  libc62.31-12
ii  libcolorcorrect5 4:5.20.5-6
ii  libegl1  1.3.2-1
ii  libfontconfig1   2.13.1-4.2
ii  libfreetype6 2.10.4+dfsg-1
ii  libgcc-s110.2.1-6
ii  libgl1   1.3.2-1
ii  libgps28 3.22-3
ii  libice6  2:1.0.10-1
ii  libkf5activities55.78.0-2
ii  libkf5activitiesstats1   5.78.0-2
ii  libkf5archive5   5.78.0-2
ii  libkf5authcore5  5.78.0-2
ii  libkf5baloo5 5.78.0-3
ii  libkf5bookmarks5 5.78.0-2
ii  libkf5calendarevents55.78.0-2
ii  libkf5completion55.78.0-3
ii  libkf5config-bin 5.78.0-4
ii  libkf5configcore55.78.0-4
ii  libkf5configgui5 5.78.0-4
ii  libkf5configwidgets5 5.78.0-2
ii  libkf5coreaddons55.78.0-4
ii  libkf5crash5 5.78.0-3
ii  libkf5dbusaddons55.78.0-2
ii  libkf5declarative5   5.78.0-2
ii  libkf5globalaccel-bin5.78.0-3
ii  libkf5globalaccel5   5.78.0-3
ii  libkf5guiaddons5 5.78.0-3
ii  libkf5holidays5  1:5.78.0-2
ii  libkf5i18n5  5.78.0-2
ii  libkf5iconthemes55.78.0-2
ii  libkf5idletime5  5.78.0-2
ii  libkf5itemmodels55.78.0-2
ii  libkf5jobwidgets55.78.0-2
ii  libkf5kcmutils5  5.78.0-3
ii  libkf5kdelibs4support5   5.78.0-2
ii  libkf5kiocore5   5.78.0-5

Bug#991438: gnome-shell: client bug: event processing lagging behind by 13ms, your system is too slow

[tkoeck]

Package: gnome-shell
Version: 3.38.4-1
Severity: normal

Dear Maintainer,

I have a lot of messages like

-
Jul 23 17:45:38 tron-nb slack.desktop[2679]: [07/23/21, 17:45:38:993]
info: [API-Q] (T040L9WRG) 0a4fdafa-1627055138.759
subscriptions.thread.mark is RESOLVED
Jul 23 17:45:40 tron-nb gnome-shell[2479]: libinput error: event4  -
Logitech G Pro : client bug: event processing lagging behind by 11ms,
your system is too slow
Jul 23 17:45:42 tron-nb slack.desktop[2679]: [07/23/21, 17:45:42:281]
info: [FOCUS-EVENT] Client window blurred
Jul 23 17:45:43 tron-nb gnome-shell[2479]: libinput error: event4  -
Logitech G Pro : client bug: event processing lagging behind by 13ms,
your system is too slow
Jul 23 17:45:44 tron-nb gnome-shell[2479]: libinput error: event4  -
Logitech G Pro : client bug: event processing lagging behind by 14ms,
your system is too slow
Jul 23 17:45:50 tron-nb gnome-shell[2479]: libinput error: event4  -
Logitech G Pro : client bug: event processing lagging behind by 15ms,
your system is too slow
Jul 23 17:46:04 tron-nb gnome-shell[2479]: libinput error: event4  -
Logitech G Pro : client bug: event processing lagging behind by 12ms,
your system is too slow
-

in my /var/log/syslog.

My system isn't too slow for it.

Greetings
Tobias

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

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

Versions of packages gnome-shell depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.38.0-2
ii  evolution-data-server3.38.3-1
ii  gir1.2-accountsservice-1.0   0.6.55-3
ii  gir1.2-atspi-2.0 2.38.0-4
ii  gir1.2-freedesktop   1.66.1-1+b1
ii  gir1.2-gcr-3 3.38.1-2
ii  gir1.2-gdesktopenums-3.0 3.38.0-2
ii  gir1.2-gdm-1.0   3.38.2.1-1
ii  gir1.2-geoclue-2.0   2.5.7-3
ii  gir1.2-glib-2.0  1.66.1-1+b1
ii  gir1.2-gnomebluetooth-1.03.34.3-2
ii  gir1.2-gnomedesktop-3.0  3.38.5-3
ii  gir1.2-gstreamer-1.0 1.18.4-2
ii  gir1.2-gtk-3.0   3.24.24-4
ii  gir1.2-gweather-3.0  3.36.1-3
ii  gir1.2-ibus-1.0  1.5.23-2
ii  gir1.2-mutter-7  3.38.4-1
ii  gir1.2-nm-1.01.30.0-2
ii  gir1.2-nma-1.0   1.8.30-1
ii  gir1.2-pango-1.0 1.46.2-3
ii  gir1.2-polkit-1.00.105-31
ii  gir1.2-rsvg-2.0  2.50.3+dfsg-1
ii  gir1.2-soup-2.4  2.72.0-2
ii  gir1.2-upowerglib-1.00.99.11-2
ii  gjs  1.66.2-1
ii  gnome-backgrounds3.38.0-1
ii  gnome-settings-daemon3.38.2-1
ii  gnome-shell-common   3.38.4-1
ii  gsettings-desktop-schemas3.38.0-2
ii  gstreamer1.0-pipewire0.3.19-4
ii  libatk-bridge2.0-0   2.38.0-1
ii  libatk1.0-0  2.36.0-2
ii  libc62.31-12
ii  libcairo21.16.0-5
ii  libecal-2.0-13.38.3-1
ii  libedataserver-1.2-253.38.3-1
ii  libgcr-base-3-1  3.38.1-2
ii  libgdk-pixbuf-2.0-0  2.42.2+dfsg-1
ii  libgirepository-1.0-11.66.1-1+b1
ii  libgjs0g 1.66.2-1
ii  libgles2 1.3.2-1
ii  libglib2.0-0 2.66.8-1
ii  libglib2.0-bin   2.66.8-1
ii  libgnome-autoar-0-0  0.2.4-3
ii  libgnome-desktop-3-193.38.5-3
ii  libgraphene-1.0-01.10.4+dfsg1-1
ii  libgtk-3-0   3.24.24-4
ii  libical3 3.0.9-2
ii  libjson-glib-1.0-0   1.6.2-1
ii  libmutter-7-03.38.4-1
ii  libnm0   1.30.0-2
ii  libpango-1.0-0   1.46.2-3
ii  libpangocairo-1.0-0  1.46.2-3
ii  libpolkit-agent-1-0  0.105-31
ii  libpolkit-gobject-1-00.105-31
ii  libpulse-mainloop-glib0  14.2-2
ii  libpulse0 

Bug#991437: ganglia-modules-linux: user module missing

[Benjamin Nacar]

Package: ganglia-modules-linux
Version: 1.3.6-5
Severity: wishlist
Tags: fixed-upstream

An additional module for keeping track of logged-in users was accepted into 
upstream in 2016. At the time of writing I don't see the corresponding files 
mod_user.conf and moduser.so in the list of files for ganglia-modules-linux 
under any Debian release.

Can the "user" module be incorporated into the Debian package for testing 
and/or unstable?

Thanks,
~~ Ben

Bug#991436: ITP: easycrypt -- EasyCrypt: Computer-Aided Cryptographic Proofs

[Marcel Fourné]

Package: wnpp
Severity: wishlist
Owner: Marcel Fourné 
X-Debbugs-Cc: debian-de...@lists.debian.org

* Package name: easycrypt
  Version : 1.0
  Upstream Author : Easycrypt-club mailing list 

* URL : https://www.easycrypt.info
* License : CECILL-C, parts under CECILL-B
  Programming Lang: Ocaml
  Description : EasyCrypt: Computer-Aided Cryptographic Proofs

EasyCrypt is a toolset for reasoning about relational properties of 
probabilistic computations with adversarial code. Its main application is the 
construction and verification of game-based cryptographic proofs.

The package is relevant to implementors as well as researchers in cryptography. 
It can be used to check proofs extracted from Jasmin programs, but is useful in 
itself as a framework for cryptographic protocol proofs.

I plan to maintain the packages myself, but I am also very open to team 
maintenance for example among the Debian Ocaml Group. Since I am not a Debian 
Developer, I need a sponsor.

Bug#991435: ITP: jasmin-lang -- Jasmin is a workbench for high-assurance and high-speed cryptography. Jasmin implementations aim at being efficient, safe, correct, and secure.

[Marcel Fourné]

Package: wnpp
Severity: wishlist
Owner: Marcel Fourné 
X-Debbugs-Cc: debian-de...@lists.debian.org

* Package name: jasmin-lang
  Version : 0.1
  Upstream Author : jasmin-users and developers mailing list 

* URL : https://github.com/jasmin-lang/jasmin/wiki
* License : CECILL-B
  Programming Lang: Coq, Ocaml
  Description : Jasmin is a workbench for high-assurance and high-speed 
cryptography. Jasmin implementations aim at being efficient, safe, correct, and 
secure.

The Jasmin programming language smoothly combines high-level and low-level 
constructs, so as to support “assembly in the head” programming. Programmers 
can control many low-level details that are performance-critical: instruction 
selection and scheduling, what registers to spill and when, etc. They can also 
rely on high-level abstractions (variables, functions, arrays, loops, etc.) to 
structure their code and make it more amenable to formal verification.

The package is relevant to implementors as well as researchers in cryptography. 
It can be used to compile, interpret and extract programs to EasyCrypt, which 
is then used for the cryptographic proofs.

I plan to maintain the packages myself, but I am also very open to team 
maintenance for example among the Debian Ocaml Group. Since I am not a Debian 
Developer, I need a sponsor.

Bug#991269: guymager: "AvoidEncaseProblems" is set to off in config file

[Michael Prokop]

Hi,

* Zack Lau [Mon Jul 19, 2021 at 10:11:44AM +]:

> Tags: patch

I don't see any patch in the BTS nor a MR at
https://salsa.debian.org/pkg-security-team/guymager/, so I'll
remove this tag

>* What led up to the situation?
> I believe the root cause is the default config file "guymager.cfg" from the
> offical repo does not have the option "AvoidEncaseProblems" enabled. The
> majority of forensic images created using the latest Guymager with
> "AvoidEncaseProblems" disabled causes error. Thus, cannot be be added to a 
> case
> in EnCase v8 or up.

>* What exactly did you do (or not do) that was effective (or
>  ineffective)?
> As I use Guymager from live CD, I have to change the "AvoidEncaseProblems"
> option in line 426 of "/etc/guymager/guymager.cfg" from "off" to "on" 
> everytime
> I launch Guymager.

>* What was the outcome of this action?
> After setting the "AvoidEncaseProblems" option to "on", forensic images 
> created
> by Guymager can be loaded in EnCase v8 or up with no issue.

>* What outcome did you expect instead?
> I expect the "AvoidEncaseProblems" option can be set to "on" by default.
> Suprisingly, this option is not known by a lot of people.

Well, the configuration option is clearly documented in the
configuration file and also explains the situation:

| REM AvoidEncaseProblems  Encase produces strange error messages if the 
EWF internal fields "Imager Version" and
| REM  "OS Version" contain more than 11 or 23 
characters, respectively. Leave this flag OFF
| REM  if you don't work with Encase (default setting). 
Set it to ON if ever you work with
| REM  Encase and want to avoid the Encase problems.

So I don't see how this could be enabled by default, given that not
everybody uses Encase by default. But I'll ask upstream, whether
they are aware of any possible better solutions.

regards
-mika-


signature.asc
Description: Digital signature

Bug#991434: unblock: six/1.16.0-2 (pre-approval)

[Andreas Beckmann]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Please unblock package six

This is the last bit in the series of adding more Breaks to help the
removal of the unversioned python packages along with the packaged
python2 modules on upgrades from buster to bullseye. (Other packages
involved were python2.7 and pyyaml, maybe more.) Unfortunately I had
missed filing the bug against src:six (#991433), otherwise the fix
should have landed in sid already some time ago.

unblock six/1.16.0-2
diff -Nru six-1.16.0/debian/changelog six-1.16.0/debian/changelog
--- six-1.16.0/debian/changelog 2021-05-09 12:40:54.0 +0200
+++ six-1.16.0/debian/changelog 2021-06-11 15:49:07.0 +0200
@@ -1,3 +1,18 @@
+six (1.16.0-2) UNRELEASED; urgency=medium
+
+  * python-six/python3-six: Copy Breaks: python (<< 2.7.18),
+python-minimal (<< 2.7.18), libpython-stdlib (<< 2.7.18),
+python-iso8601 (<< 0.1.12-2~), python-pbr (<< 5.4.5) from python2.7 to
+ensure removal of the unversioned python packages (and some persisting
+obsolete Python 2 module packages) on upgrades from buster. In some
+upgrade scenarios (mostly involving openstack packages) these Breaks in
+python2.7 were ineffective because the unversioned python packages got
+higher scores than python2.7. python-six/python3-six are usually very
+high scoring Python module packages in these cases, making them ideal
+candidates for such copies of the Breaks.  (Closes: #-1)
+
+ -- Andreas Beckmann   Fri, 11 Jun 2021 15:49:07 +0200
+
 six (1.16.0-1) unstable; urgency=medium
 
   * New upstream release.
diff -Nru six-1.16.0/debian/control six-1.16.0/debian/control
--- six-1.16.0/debian/control   2021-05-09 12:40:54.0 +0200
+++ six-1.16.0/debian/control   2021-06-11 15:49:07.0 +0200
@@ -26,6 +26,11 @@
 Multi-Arch: foreign
 Depends: ${misc:Depends},
  ${python:Depends},
+Breaks: python (<< 2.7.18),
+python-minimal (<< 2.7.18),
+libpython-stdlib (<< 2.7.18),
+python-iso8601 (<< 0.1.12-2~),
+python-pbr (<< 5.4.5),
 Description: Python 2 and 3 compatibility library (Python 2 interface)
  Six is a Python 2 and 3 compatibility library. It provides utility
  functions for smoothing over the differences between the Python versions
@@ -40,6 +45,9 @@
 Multi-Arch: foreign
 Depends: ${misc:Depends},
  ${python3:Depends},
+Breaks: python (<< 2.7.18),
+python-minimal (<< 2.7.18),
+libpython-stdlib (<< 2.7.18),
 Description: Python 2 and 3 compatibility library (Python 3 interface)
  Six is a Python 2 and 3 compatibility library. It provides utility
  functions for smoothing over the differences between the Python versions

Bug#991433: six: please add Breaks against unversioned python packages from buster

[Andreas Beckmann]

Source: six
Version: 1.16.0-1
Severity: serious
Tags: patch

Hi,

I'm trying to solve some incomplete upgrades from buster to bullseye.
I.e. apt tries to keep some obsolete packages from buster installed and
therefore cannot upgrade some other packages instead of removing the
obsolete bits and upgrading everything upgradable. This usually needs
some additional Breaks to be added to guide apt to the right way.

One challenge upgrading from buster is to get rid of the unversioned
python and friends along with most of the packaged Python 2 modules.
The openstack stack is a bit problematic here, but this can be solved by
adding some Breaks in python-six/python3-six. (Sounds a bit non-intuitive
to add them to a python3-* package, but there is no better fitting
package with a sufficiently high score involved in these scenarios.)

I've run a lot of upgrade tests and the results look very promising that
we can improve the number of clean upgrade paths with this patch.


Andreas

PS: I thought I had sent this bug report a month ago together with all
the related fixes, but somewhere I must have missed this one.
I'll file an unblock request right away, too.
diff -Nru six-1.16.0/debian/changelog six-1.16.0/debian/changelog
--- six-1.16.0/debian/changelog 2021-05-09 12:40:54.0 +0200
+++ six-1.16.0/debian/changelog 2021-06-11 15:49:07.0 +0200
@@ -1,3 +1,18 @@
+six (1.16.0-2) UNRELEASED; urgency=medium
+
+  * python-six/python3-six: Copy Breaks: python (<< 2.7.18),
+python-minimal (<< 2.7.18), libpython-stdlib (<< 2.7.18),
+python-iso8601 (<< 0.1.12-2~), python-pbr (<< 5.4.5) from python2.7 to
+ensure removal of the unversioned python packages (and some persisting
+obsolete Python 2 module packages) on upgrades from buster. In some
+upgrade scenarios (mostly involving openstack packages) these Breaks in
+python2.7 were ineffective because the unversioned python packages got
+higher scores than python2.7. python-six/python3-six are usually very
+high scoring Python module packages in these cases, making them ideal
+candidates for such copies of the Breaks.  (Closes: #-1)
+
+ -- Andreas Beckmann   Fri, 11 Jun 2021 15:49:07 +0200
+
 six (1.16.0-1) unstable; urgency=medium
 
   * New upstream release.
diff -Nru six-1.16.0/debian/control six-1.16.0/debian/control
--- six-1.16.0/debian/control   2021-05-09 12:40:54.0 +0200
+++ six-1.16.0/debian/control   2021-06-11 15:49:07.0 +0200
@@ -26,6 +26,11 @@
 Multi-Arch: foreign
 Depends: ${misc:Depends},
  ${python:Depends},
+Breaks: python (<< 2.7.18),
+python-minimal (<< 2.7.18),
+libpython-stdlib (<< 2.7.18),
+python-iso8601 (<< 0.1.12-2~),
+python-pbr (<< 5.4.5),
 Description: Python 2 and 3 compatibility library (Python 2 interface)
  Six is a Python 2 and 3 compatibility library. It provides utility
  functions for smoothing over the differences between the Python versions
@@ -40,6 +45,9 @@
 Multi-Arch: foreign
 Depends: ${misc:Depends},
  ${python3:Depends},
+Breaks: python (<< 2.7.18),
+python-minimal (<< 2.7.18),
+libpython-stdlib (<< 2.7.18),
 Description: Python 2 and 3 compatibility library (Python 3 interface)
  Six is a Python 2 and 3 compatibility library. It provides utility
  functions for smoothing over the differences between the Python versions

Bug#968195: keyboard-configuration: cannot set specific layout Français (Bépo, ergonomique, façon Dvorak, AFNOR) for tty console

[Sébastien Villemot]

Le lundi 10 août 2020 à 11:49 +0300, Jean-Louis Biasini a écrit :
> Package: keyboard-configuration
> Version: 1.196
> Severity: important

> * What exactly did you do (or not do) that was effective (or
> ineffective)?
> console tty:
> $ sudo dpkg-reconfigure keyboard-configuration
> choosing Français (Bépo, ergonomique, façon Dvorak, AFNOR)
> $ sudo systemctl restart keyboard-setup
> * What was the outcome of this action?
> still in en us
> 
> * Additional info:
> - settings any other layout works (included other bépo variants)
> therefore not #955215
> - this specific layout works fine in X

I was also hit by this bug. I confirm that setupcon is unable to load
the “fr(bepo_afnor)” keymap.

The problem is that loadkeys fails to load the keymap generated by
ckbcomp. It errors out with this message:

 too many (160) entries on one line

-- 
⢀⣴⠾⠻⢶⣦⠀  Sébastien Villemot
⣾⠁⢠⠒⠀⣿⡁  Debian Developer
⢿⡄⠘⠷⠚⠋⠀  https://sebastien.villemot.name
⠈⠳⣄  https://www.debian.org



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

Bug#991431: Acknowledgement (password-store: Please move Emacs mode in separate package)

[Martin]

The debian/changelog in the patch is broken, it seems.
Correction attached.
diff --git a/debian/changelog b/debian/changelog
index b4c3dc6..65b118a 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+password-store (1.7.4-1.1) UNRELEASED; urgency=medium
+
+  [ Martin ]
+  * Move Emacs mode in separate package
+
+ -- Martin   Fri, 23 Jul 2021 10:18:26 +
+
 password-store (1.7.4-1) unstable; urgency=medium
 
   * New upstream release:
diff --git a/debian/control b/debian/control
index 67500f2..84e5bae 100644
--- a/debian/control
+++ b/debian/control
@@ -3,7 +3,7 @@ Maintainer: Colin Watson 
 Section: admin
 Priority: optional
 Standards-Version: 3.9.8
-Build-Depends: debhelper-compat (= 9), gnupg, tree (>= 1.7.0), git
+Build-Depends: debhelper-compat (= 9), gnupg, tree (>= 1.7.0), git, dh-elpa
 Homepage: https://www.passwordstore.org/
 Vcs-Git: https://salsa.debian.org/debian/password-store.git
 Vcs-Browser: https://salsa.debian.org/debian/password-store
@@ -17,3 +17,10 @@ Suggests: python, python3, perl, libxml-simple-perl, ruby
 Description: lightweight directory-based password manager
  Stores, retrieves, generates, and synchronizes passwords securely using
  gpg and git.
+
+Package: elpa-password-store
+Architecture: all
+Depends: ${elpa:Depends}, ${misc:Depends}, pass
+Description: Emacs support for the lightweight directory-based password manager
+ Stores, retrieves, generates, and synchronizes passwords securely using
+ gpg and git in Emacs.
diff --git a/debian/elpa-password-store.docs b/debian/elpa-password-store.docs
new file mode 100644
index 000..d8b7c85
--- /dev/null
+++ b/debian/elpa-password-store.docs
@@ -0,0 +1,2 @@
+./contrib/emacs/README.md
+./contrib/emacs/CHANGELOG.md
diff --git a/debian/elpa-password-store.elpa b/debian/elpa-password-store.elpa
new file mode 100644
index 000..e8fde88
--- /dev/null
+++ b/debian/elpa-password-store.elpa
@@ -0,0 +1 @@
+./contrib/emacs/password-store.el
diff --git a/debian/examples b/debian/examples
index 180e762..2eb42a2 100644
--- a/debian/examples
+++ b/debian/examples
@@ -1,3 +1,2 @@
 contrib/dmenu
-contrib/emacs
 contrib/vim
diff --git a/debian/rules b/debian/rules
index 6920439..8653d72 100755
--- a/debian/rules
+++ b/debian/rules
@@ -1,6 +1,6 @@
 #!/usr/bin/make -f
 %:
-	dh $@
+	dh $@ --with elpa
 
 override_dh_auto_test:
 	set -e; \

Bug#991382: udev: cdr-drive opens after suspend

[M G Berberich]

Am Donnerstag, den 22. Juli schrieb Michael Biebl:
> Control: tags -1 + moreinfo
> 
> Am 22.07.21 um 08:53 schrieb M G Berberich:
> > Package: udev
> > Version: 247.3-6
> > Severity: normal
> > 
> > Dear Maintainer,
> > 
> > for some days the cdrom-drive opens after the system wakes up from
> > suspend.  This occured after installing kernel 5.13.X, but this might
> > be a coincidence.
> > 
> > The kernel is a stock kernel:
> > Linux 5.13.4 #3 SMP PREEMPT Tue Jul 20 21:09:45 CEST 2021 x86_64 GNU/Linux
> > 
> 
> What makes you conclude this is a udev bug?

This is an assumption, Udev is the subsystem that handles media eject
button events. The problem can be circumvented by commenting out the
“media eject button pressed” handling in
/lib/udev/rules.d/60-cdrom_id.rules.

  # ENV{DISK_EJECT_REQUEST}=="?*", RUN+="cdrom_id --eject-media $devnode", 
GOTO="cdrom_end"

(which does prove nothing). This might be a problem elsewhere,
p.e. the kernel issuing a spurious media eject button press event.
(https://bugzilla.kernel.org/show_bug.cgi?id=213795).

MfG
bmg

-- 
„Des is völlig wurscht, was heut beschlos- | M G Berberich
 sen wird: I bin sowieso dagegn!“  | m...@m-berberich.de
(SPD-Stadtrat Kurt Schindler; Regensburg)  | 

Bug#991432: unblock: freeradius/3.0.21+dfsg-2.1

[Jochen Sprickerhof]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Please unblock package freeradius

[ Reason ]
Misleading comment in systemd service file about how to get capabilities
for privileged ports: #985967.

[ Impact ]
Users could have a hard time how to use freeradius.

[ Tests ]
To test manually:
$ sudo apt install freeradius-dhcp
$ sed 's/port = 6700/port = 67/' /etc/freeradius/3.0/sites-available/dhcp > 
/etc/freeradius/3.0/sites-enabled/dhcp
$ systemctl restart freeradius

[ Risks ]
This only changes a commented line in a service file, I don't see a
risk.

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

[ Other info ]
Send upstream as
https://github.com/FreeRADIUS/freeradius-server/pull/4150

unblock freeradius/3.0.21+dfsg-2.1
diff -Nru freeradius-3.0.21+dfsg/debian/changelog 
freeradius-3.0.21+dfsg/debian/changelog
--- freeradius-3.0.21+dfsg/debian/changelog 2020-08-24 10:46:49.0 
+0200
+++ freeradius-3.0.21+dfsg/debian/changelog 2021-07-23 13:19:03.0 
+0200
@@ -1,3 +1,13 @@
+freeradius (3.0.21+dfsg-2.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix capabilities in service file.
+As freeradius is not run as root we need to request extra capabilities
+wiht AmbientCapabilities instead of limiting the set with
+CapabilityBoundingSet. (Closes: #985967)
+
+ -- Jochen Sprickerhof   Fri, 23 Jul 2021 13:19:03 +0200
+
 freeradius (3.0.21+dfsg-2) unstable; urgency=medium
 
   * Cherry-Pick upstream fixes to build with Python3.8 (Closes: #966860)
diff -Nru freeradius-3.0.21+dfsg/debian/freeradius.service 
freeradius-3.0.21+dfsg/debian/freeradius.service
--- freeradius-3.0.21+dfsg/debian/freeradius.service2020-08-24 
10:46:49.0 +0200
+++ freeradius-3.0.21+dfsg/debian/freeradius.service2021-07-23 
13:13:11.0 +0200
@@ -41,7 +41,7 @@
 NoNewPrivileges=true
 
 # Allow binding to secure ports, broadcast addresses, and raw interfaces.
-#CapabilityBoundingSet=CAP_NET_ADMIN CAP_NET_BIND_SERVICE CAP_NET_BROADCAST 
CAP_NET_RAW CAP_SETUID CAP_SETGID CAP_CHOWN CAP_DAC_OVERRIDE
+#AmbientCapabilities=CAP_NET_ADMIN CAP_NET_BIND_SERVICE CAP_NET_BROADCAST 
CAP_NET_RAW CAP_SETUID CAP_SETGID CAP_CHOWN CAP_DAC_OVERRIDE
 
 # Private /tmp that isn't shared by other processes
 PrivateTmp=true

Bug#991431: password-store: Please move Emacs mode in separate package

[Martin]

Source: password-store
Version: 1.7.4-1
Severity: wishlist
X-Debbugs-Cc: debian-emac...@lists.debian.org
Tags: patch

Dear Colin,

please consider moving the the Emacs mode from examples into a separate
package, which integrates nicely with the Debian Emacs infrastructure.
A patch is attached. Many thanks in advance!

Cheers, Martin
diff --git a/debian/changelog b/debian/changelog
index b4c3dc6..2207e67 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,10 +1,9 @@
-password-store (1.7.4-1) unstable; urgency=medium
+password-store (1.7.4-1.1) UNRELEASED; urgency=medium
 
-  * New upstream release:
-- Add support for wl-clipboard (closes: #958150).
-  * Use debhelper-compat instead of debian/compat.
+  [ Martin ]
+  * Move Emacs mode in separate package
 
- -- Colin Watson   Sun, 13 Jun 2021 11:57:38 +0100
+ -- Martin   Fri, 23 Jul 2021 10:18:26 +
 
 password-store (1.7.3-2) unstable; urgency=medium
 
diff --git a/debian/control b/debian/control
index 67500f2..84e5bae 100644
--- a/debian/control
+++ b/debian/control
@@ -3,7 +3,7 @@ Maintainer: Colin Watson 
 Section: admin
 Priority: optional
 Standards-Version: 3.9.8
-Build-Depends: debhelper-compat (= 9), gnupg, tree (>= 1.7.0), git
+Build-Depends: debhelper-compat (= 9), gnupg, tree (>= 1.7.0), git, dh-elpa
 Homepage: https://www.passwordstore.org/
 Vcs-Git: https://salsa.debian.org/debian/password-store.git
 Vcs-Browser: https://salsa.debian.org/debian/password-store
@@ -17,3 +17,10 @@ Suggests: python, python3, perl, libxml-simple-perl, ruby
 Description: lightweight directory-based password manager
  Stores, retrieves, generates, and synchronizes passwords securely using
  gpg and git.
+
+Package: elpa-password-store
+Architecture: all
+Depends: ${elpa:Depends}, ${misc:Depends}, pass
+Description: Emacs support for the lightweight directory-based password manager
+ Stores, retrieves, generates, and synchronizes passwords securely using
+ gpg and git in Emacs.
diff --git a/debian/elpa-password-store.docs b/debian/elpa-password-store.docs
new file mode 100644
index 000..d8b7c85
--- /dev/null
+++ b/debian/elpa-password-store.docs
@@ -0,0 +1,2 @@
+./contrib/emacs/README.md
+./contrib/emacs/CHANGELOG.md
diff --git a/debian/elpa-password-store.elpa b/debian/elpa-password-store.elpa
new file mode 100644
index 000..e8fde88
--- /dev/null
+++ b/debian/elpa-password-store.elpa
@@ -0,0 +1 @@
+./contrib/emacs/password-store.el
diff --git a/debian/examples b/debian/examples
index 180e762..2eb42a2 100644
--- a/debian/examples
+++ b/debian/examples
@@ -1,3 +1,2 @@
 contrib/dmenu
-contrib/emacs
 contrib/vim
diff --git a/debian/rules b/debian/rules
index 6920439..8653d72 100755
--- a/debian/rules
+++ b/debian/rules
@@ -1,6 +1,6 @@
 #!/usr/bin/make -f
 %:
-	dh $@
+	dh $@ --with elpa
 
 override_dh_auto_test:
 	set -e; \

Bug#991421: unblock: lemonldap-ng/2.0.11+ds-4

[Salvatore Bonaccorso]

Hi,

On Fri, Jul 23, 2021 at 08:00:25AM +0200, Yadd wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: unblock
> X-Debbugs-Cc: secur...@debian.org
> 
> Please unblock package lemonldap-ng
> 
> [ Reason ]
> lemonldap-ng 2.0.11+ds-3 has several vulnerabilities fixed in 2.0.12.
> This update fixes:
>  * Session cache corruption can lead to authorization bypass or spoofing
>(Closes: CVE-2021-35472)
>  * OAuth2 handler does not verify access token validity
>(Closes: CVE-2021-35473)
>  * XSS on register form
>  * Bad behavior which displays TOTP secret to connected user and debug logs
> 
> [ Impact ]
> One high vulnerability (CVE-2021-35472) and medium others

Additionaly, this one did affect as well buster and fixes were
released today with DSA 4943-1.

Regards,
Salvatore

Bug#991430: installation-reports: Successful install; failed to detect need for firmware for sound card

[Matthew Vernon]

Package: installation-reports
Severity: normal
Tags: d-i

Boot method: USB
Image version: 
https://cdimage.debian.org/cdimage/unofficial/non-free/cd-including-firmware/bullseye_di_rc2+nonfree/amd64/iso-cd/firmware-bullseye-DI-rc2-amd64-netinst.iso
Date: 2021-07-20

Machine: Lenovo Thinkpad X1 (20TK000PUK)

Base System Installation Checklist:
[O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it

Initial boot:   [O ]
Detect network card:[O ]
Configure network:  [O ]
Detect media:   [O ]
Load installer modules: [O ]
Clock/timezone setup:   [O ]
User/password setup:[O ]
Detect hard drives: [O ]
Partition hard drives:  [O ]
Install base system:[O ]
Install tasks:  [O ]
Install boot loader:[O ]
Overall install:[O ]

Comments/Problems:

Install worked great - both graphical and textual (I tried both). My
only real quibble is that the sound card in this laptop requires
non-free firmware to work (!), which is in the firmware-sof-signed
package. Given I was using a with-nonfree-firmware installer, it would
have been nice if this had been flagged by the installer and/or
installed for me :)

Thanks,

Matthew

-- Package-specific info:

==
Installer lsb-release:
==
DISTRIB_ID=Debian
DISTRIB_DESCRIPTION="Debian GNU/Linux installer"
DISTRIB_RELEASE="11 (bullseye) - installer build 20210606"
X_INSTALLATION_MEDIUM=cdrom

==
Installer hardware-summary:
==
uname -a: Linux tsk 5.10.0-7-amd64 #1 SMP Debian 5.10.40-1 (2021-05-28) x86_64 
GNU/Linux
lspci -knn: 00:00.0 Host bridge [0600]: Intel Corporation 10th Gen Core 
Processor Host Bridge/DRAM Registers [8086:9b44] (rev 02)
lspci -knn: Subsystem: Lenovo Device [17aa:22c0]
lspci -knn: 00:01.0 PCI bridge [0604]: Intel Corporation Xeon E3-1200 
v5/E3-1500 v5/6th Gen Core Processor PCIe Controller (x16) [8086:1901] (rev 02)
lspci -knn: Kernel driver in use: pcieport
lspci -knn: 00:02.0 VGA compatible controller [0300]: Intel Corporation UHD 
Graphics [8086:9bc4] (rev 05)
lspci -knn: Subsystem: Lenovo Device [17aa:22c1]
lspci -knn: 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 
02)
lspci -knn: Subsystem: Lenovo Device [17aa:22c0]
lspci -knn: 00:08.0 System peripheral [0880]: Intel Corporation Xeon E3-1200 
v5/v6 / E3-1500 v5 / 6th/7th/8th Gen Core Processor Gaussian Mixture Model 
[8086:1911]
lspci -knn: Subsystem: Lenovo Device [17aa:22c0]
lspci -knn: 00:12.0 Signal processing controller [1180]: Intel Corporation 
Comet Lake PCH Thermal Controller [8086:06f9]
lspci -knn: Subsystem: Lenovo Device [17aa:22c0]
lspci -knn: 00:14.0 USB controller [0c03]: Intel Corporation Comet Lake USB 3.1 
xHCI Host Controller [8086:06ed]
lspci -knn: Subsystem: Lenovo Device [17aa:22c0]
lspci -knn: Kernel driver in use: xhci_hcd
lspci -knn: Kernel modules: xhci_pci
lspci -knn: 00:14.2 RAM memory [0500]: Intel Corporation Comet Lake PCH Shared 
SRAM [8086:06ef]
lspci -knn: Subsystem: Lenovo Device [17aa:22c0]
lspci -knn: 00:14.3 Network controller [0280]: Intel Corporation Wi-Fi 6 AX201 
[8086:06f0]
lspci -knn: Subsystem: Intel Corporation Device [8086:0070]
lspci -knn: Kernel driver in use: iwlwifi
lspci -knn: Kernel modules: iwlwifi
lspci -knn: 00:16.0 Communication controller [0780]: Intel Corporation Comet 
Lake HECI Controller [8086:06e0]
lspci -knn: Subsystem: Lenovo Device [17aa:22c0]
lspci -knn: 00:16.3 Serial controller [0700]: Intel Corporation Device 
[8086:06e3]
lspci -knn: Subsystem: Lenovo Device [17aa:22c0]
lspci -knn: Kernel driver in use: serial
lspci -knn: 00:1c.0 PCI bridge [0604]: Intel Corporation Device [8086:06b8] 
(rev f0)
lspci -knn: Kernel driver in use: pcieport
lspci -knn: 00:1c.6 PCI bridge [0604]: Intel Corporation Device [8086:06be] 
(rev f0)
lspci -knn: Kernel driver in use: pcieport
lspci -knn: 00:1c.7 PCI bridge [0604]: Intel Corporation Device [8086:06bf] 
(rev f0)
lspci -knn: Kernel driver in use: pcieport
lspci -knn: 00:1d.0 PCI bridge [0604]: Intel Corporation Comet Lake PCI Express 
Root Port #9 [8086:06b0] (rev f0)
lspci -knn: Kernel driver in use: pcieport
lspci -knn: 00:1f.0 ISA bridge [0601]: Intel Corporation Device [8086:068e]
lspci -knn: Subsystem: Lenovo Device [17aa:22c0]
lspci -knn: 00:1f.3 Multimedia audio controller [0401]: Intel Corporation Comet 
Lake PCH cAVS [8086:06c8]
lspci -knn: Subsystem: Lenovo Device [17aa:22c1]
lspci -knn: 00:1f.4 SMBus [0c05]: Intel Corporation Comet Lake PCH SMBus 
Controller [8086:06a3]
lspci -knn: Subsystem: Lenovo Device [17aa:22c0]
lspci -knn: 00:1f.5 Serial bus controller [0c80]: Intel Corporation Comet Lake 
PCH SPI Controller [8086:06a4]
lspci -knn: Subsystem: Lenovo Device 

Bug#985941: Fix available (attached): Bug#985941: Acknowledgement (libcgicc3: wrong file length if file upload via POST as "multipart/form-data")

[Romeyke, Andreas]

Dear Maintainer,

the fix is very easy:

The problem is the line 494 in Cgicc.cpp, the '-2' is wrong, because at end of 
file content there is no trailing \r\n. The comment in lin 492 is wrong, too.

The fix is easy:

Index: cgicc/Cgicc.cpp
===
RCS file: /sources/cgicc/cgicc/cgicc/Cgicc.cpp,v
retrieving revision 1.34
diff -b -d -u -r1.34 Cgicc.cpp
--- cgicc/Cgicc.cpp 23 Apr 2014 20:55:04 - 1.34
+++ cgicc/Cgicc.cpp 23 Jul 2021 10:25:58 -
@@ -489,9 +489,9 @@
   if(std::string::npos == headLimit)
 throw std::runtime_error("Malformed input");

-  // Extract the value - there is still a trailing CR/LF to be subtracted off
+  // Extract the value
   std::string::size_type valueStart = headLimit + end.length();
-  std::string value = data.substr(valueStart, data.length() - valueStart - 2);
+  std::string value = data.substr(valueStart, data.length() - 
+ valueStart);

   // Parse the header - pass trailing CR/LF x 2 to parseHeader
   MultipartHeader head = parseHeader(data.substr(0, valueStart));


With best regards

Andreas
--
team member “long-term preservation“

Saxon State- and University Library Dresden (SLUB)
Department 2 (IT), Division 2.3 (infrastructure and digital long-term 
preservation) 
Zellescher Weg 18 | 01069 Dresden
phone: +49 351 4677 763
E-Mail: andreas.rome...@slub-dresden.de 
http://www.slub-dresden.de/ | @slubdresden


-Ursprüngliche Nachricht-
Von: Debian Bug Tracking System  
Gesendet: Freitag, 26. März 2021 14:27
An: Romeyke, Andreas 
Betreff: Bug#985941: Acknowledgement (libcgicc3: wrong file length if file 
upload via POST as "multipart/form-data")

Thank you for filing a new Bug report with Debian.

You can follow progress on this Bug here: 985941: 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=985941.

This is an automatically generated reply to let you know your message has been 
received.

Your message is being forwarded to the package maintainers and other interested 
parties for their attention; they will reply in due course.

Your message has been sent to the package maintainer(s):
 Chris Butler 

If you wish to submit further information on this problem, please send it to 
985...@bugs.debian.org.

Please do not send mail to ow...@bugs.debian.org unless you wish to report a 
problem with the Bug-tracking system.

--
985941: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=985941
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#991359: unblock: liquidsoap/1.4.3-3

[Kyle Robbertze]

Control: tags -1 - moreinfo

Thanks, the new version has been uploaded to unstable and built.

Cheers
Kyle

-- 

⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Kyle Robbertze
⢿⡄⠘⠷⠚⠋⠀ Debian Developer
⠈⠳⣄ https://wiki.debian.org/KyleRobbertze

Bug#988116: ITP: libdecor-0.1 -- client-side decoration library for Wayland

[Simon McVittie]

On Thu, 06 May 2021 at 00:11:37 +0100, Christian Rauch wrote:
> I am already maintaining an Ubuntu ppa at:
> https://launchpad.net/~christianrauch/+archive/ubuntu/libdecoration
> but would like to upstream the package into Debian.

Is the packaging you used in that Ubuntu PPA already available as a
git tree?

> Since this is my first time packaging a library for Debian, I could use
> support from a co-maintainer who is familiar with Wayland

More important would be to have a co-maintainer who is familiar with
packaging shared libraries, I think. There are some subtleties that are
important to get right.

It would probably make sense for the SDL team and/or the GNOME team to
be in Maintainer and/or Uploaders for this package - SDL wants to use it,
and it comes from GNOME infrastructure and uses GNOME-adjacent libraries
and coding conventions. I'm in both teams and would be willing to
co-maintain. I can help to implement the suggestions below, or you
could do them, whichever you'd prefer.

I haven't yet reviewed the upstream code at all (except for the build
system MR), but a Debian Developer will need to do that before upload,
to check for legality/licensing issues and make sure the code isn't
malicious or obviously broken (I'm sure it isn't, but someone should check).

Some quick review of the version from the PPA:

Package naming:
- Source package name should be libdecor-0 now that upstream has
  co-installable naming conventions
- libdecor binary package should be renamed libdecor-0-0 to match the
  SONAME libdecor-0.so.0, with Conflicts: libdecor, Replaces: libdecor
  to avoid conflicts with the unofficial PPA package
- libdecor-dev binary package should be renamed libdecor-0-dev to match
  the .pc file, with Conflicts: libdecor-dev, Replaces: libdecor-dev
- libdecor-plugin-cairo should maybe be renamed libdecor-plugin-1-cairo
  or something, to reflect plugin_api_version

d/control:
- libdecor dependency on libwayland-client0 should be unnecessary, you
  should find that ${shlibs:Depends} adds a suitable dependency
- Similarly libdecor-plugin-cairo dependency on libcairo2 and
  libpangocairo-1.0-0 should come from ${shlibs:Depends}
- libdecor-plugin-cairo should probably have Provides: libdecor-plugin-1
- libdecor-0-0 should probably have
  Recommends: libdecor-plugin-1-cairo | libdecor-plugin-1
  so that third-party plugins (if any) can Provides: libdecor-plugin-1
- The Standards-Version is very out of date, please check that the package
  follows current Debian Policy and then set it to the current Policy
  version (4.5.1 at time of writing)
- libdecor-plugin-cairo needs a long Description

d/compat:
- Please use the recommended debhelper compat level (13) for new packages,
  unless there is a very good reason to require an older compat level.
  The preferred way to do this is to add
  Build-Depends: debhelper-compat (= 13) and delete d/compat.

d/copyright:
- The version of the MIT/X11 license quoted here is called "Expat" in
  d/copyright files, to distinguish it from the many other licenses
  used by MIT and X11.
- You can probably use

  Files: *
  Copyright: (the same as you have now)
  License: Expat

  on the assumption that .gitignore, README, meson.build, etc. have the
  same copyright holders and licensing as the rest of the package.
- Please declare a copyright holder (you or your employer) and a license
  (probably Expat) for the debian directory.
- The copyright file isn't following copyright-format 1.0 syntax yet.
  Please see the python3-vdf package (which I maintain) for an example of
  a copyright file for a package with the same license as this one.

d/README.Debian:
- If you don't have anything to say here, please delete it

d/rules:
- Probably best to remove the commented-out stuff
- I would suggest enabling the demos and installing them in a new
  libdecor-tests package - otherwise it'll be hard to do manual testing
  on this package without having the patched SDL available. This will
  need some extra build-dependencies.

  If this package later gains automated tests, the libdecor-tests package
  could contain those too.

  Ideally the libdecor-tests package would have Build-Profiles: 
  (I can help with this).

d/source/format:
- Should be 3.0 (quilt) instead of 3.0 (native) for a package with an
  upstream developer outside Debian

d/git-build-recipe.manifest:
- This should be removed for an official Debian package.

Other:
- There should be a debian/watch to download the latest official upstream
  release. If upstream doesn't release tarballs then use something similar
  to 
https://salsa.debian.org/gnome-team/gnome-desktop-testing/-/blob/debian/2018.1+git20210629-1/debian/watch
  to download it directly from git.
- I think all shared library packages should have at least a superficial
  autopkgtest, for example similar to the ones in
  

  or 

Bug#991428: Consider migrating to original 7-Zip for Linux

[Amr Ibrahim]

Package: p7zip

The developer of 7-Zip released a Linux command-line version as part of
7-Zip 21.01 alpha:
https://sourceforge.net/p/sevenzip/discussion/45797/thread/cec5e63147/

This is a suggestion to migrate to 7-Zip for Linux if the development
of p7zip is dead upstream.

7-Zip ChangeLog:
https://www.7-zip.org/history.txt

7-Zip Source:
https://sourceforge.net/projects/sevenzip/



There is also a p7zip fork with additional codecs and improvements:
https://github.com/jinfeihan57/p7zip

Bug#991400: systemd: Failed to migrate controller cgroups from /user.slice/user-1000.slice/user@1000.service

[Michael Biebl]

Am 22.07.21 um 23:26 schrieb Thomas Uhle:

On Thu, 22 Jul 2021, Michael Biebl wrote:


Kernel: Linux 3.16.85-odroidc2 (SMP w/4 CPU threads; PREEMPT)

Oh, right.

This is not a Debian supported kernel. Please ask your vendor to 
update it to something more recent.




Unfortunately, Hardkernel won't put any more effort into upgrading the 
Linux kernel for Odroid-C2 at the moment (according to 
https://forum.odroid.com/viewtopic.php?t=39474#p298277). That is why I 
asked for cherrypicking the patch from Github for the systemd version in 
bullseye because I hoped that this would also be a suitable solution for 
this issue.


We are in deep freeze for bullseye atm.
I don't think this issue qualifies for a freeze exception, given that 
this happens with a non-Debian supported kernel.


That said, we will likely provide backports of newer systemd versions 
for bullseye. So you can pull them from there, once they are available.


Michael



OpenPGP_signature
Description: OpenPGP digital signature

Bug#991406: systemd: proc: unrecognized mount option "hidepid=invisible" or missing value

[Michael Biebl]

On Thu, 22 Jul 2021 21:09:33 +0200 Thomas Uhle
 wrote:

> Do you know whether this has already been fixed in a newer systemd version
> or whether this has already been dealt with upstream? I could not find 
> anything with respect to this issue

There is https://github.com/systemd/systemd/issues/16896


It was closed wontfix.


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

Bug#991419: new upstream (0.7.1)

[Daniel Baumann]

clone 991419 -1
retitle -1 ITA: ck -- Concurrency Kit
reassign -1 wnpp
owner -1 Daniel Baumann 
thanks

Hi Robert

On 7/23/21 8:20 AM, Robert Edmonds wrote:
> Unfortunately I don't have much time to spend on ck these days, and I
> don't have any packages that need it as a build dependency. Feel free to
> ITA.

no problem, thanks!

Regards,
Daniel

Bug#991426: release-notes: Recommend user.max_user_namespaces over kernel.unprivileged_userns_clone?

[Simon McVittie]

Package: release-notes
Severity: normal
Tags: patch moreinfo
X-Debbugs-Cc: debian-ker...@lists.debian.org

If I understand correctly, user.max_user_namespaces is an upstream kernel
feature, but kernel.unprivileged_userns_clone comes from a Debian-specific
patch that might be removed in future releases. It seems better to recommend
the upstream version (also used in e.g. RHEL).

A possible patch is attached, but I'd prefer to get confirmation from
a kernel maintainer before applying this, hence tagged +moreinfo.

smcv
>From 4f306c09371023ff71f921e4e4adec09233325bd Mon Sep 17 00:00:00 2001
From: Simon McVittie 
Date: Fri, 23 Jul 2021 10:21:12 +0100
Subject: [PATCH] Recommend user.max_user_namespaces over
 kernel.unprivileged_userns_clone

If I understand correctly, user.max_user_namespaces is an upstream kernel
feature, but kernel.unprivileged_userns_clone comes from a Debian-specific
patch that might be removed in future releases.

Signed-off-by: Simon McVittie 
---
 en/issues.dbk | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/en/issues.dbk b/en/issues.dbk
index d0918474..ec8b75e8 100644
--- a/en/issues.dbk
+++ b/en/issues.dbk
@@ -307,7 +307,7 @@ password [success=1 default=ignore] pam_unix.so obscure yescrypt
 If you prefer to keep this feature restricted, set the sysctl:
   
   
-kernel.unprivileged_userns_clone = 0
+user.max_user_namespaces = 0
   
   
 	Note that various desktop and container features will not work
@@ -315,6 +315,11 @@ kernel.unprivileged_userns_clone = 0
 	WebKitGTK, Flatpak and
 	GNOME thumbnailing.
   
+  
+The Debian-specific sysctl
+kernel.unprivileged_userns_clone=0
+has a similar effect, but is deprecated.
+  
 
 
 
-- 
2.32.0

Bug#991416: bridge-utils: broken IPv4 connection after upgrading to Debian Bullseye, setting old MAC with bridge_hw fixes the issue

[Martin-Éric Racine]

Package: bridge-utils
Followup-For: Bug #991416

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

I've had similar problems in the past. IIRC this is caused by occasional 
changes in how the kernel does interface discovery. In my particular case, the 
bridge took on the nasty habit of adopting the MAC address of a removable 
interface. Removing the device made the bridge collapse. The fix indeed was to 
specificy the MAC address I want it to use using bridge_hw.

Martin-Éric

-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEyJACx3qL7GpObXOQrh+Cd8S017YFAmD6g2AACgkQrh+Cd8S0
17a0qxAAuAAYpas+x9BIvJdgd6I6Mxh+iVFzlCwuUwE351eDfzDcSDAFepUQ/r8m
+HGL0bn6pJDgfOF1xWHLWKB85YGjENu0M1AaI3ABxu/wA3KTHmhPP5932KbqM6Lz
yfEpvBonsD6La7R1zBqp/n/n+/NHmkJt8JFVd4ltQ3na3gIShKdc71CiuHoe0ZRU
v07JobiDnxJyz/RwdJUKKKiqLn1y6HeexEz42sT0u6nd16h/vqjF1THKhlfg9n6x
5iUK7djWMzijsz81wduHUIku+0ac8yrjGgCqjBkyFVeZV0AZypWD/jDXV1bPNnm7
MfUXauUgjdHa9aW7RIwHL3xuDUUWGIoaoH8AnVlgBu7I4yH9yf3Se6L4+uzaLsMh
EJ4ABZaYKZLh598XNR8owCrJaYErUSJoAX91KwmmCZrHaNI6mAB+UDW5sjtvjHox
acfskUi/WjE5EjKJMX7ZONuloctzVVqY5s1QtT2j7laBDVyTWBnPFV0iG0vopyqS
Qkp2io7eKwjEp9BLd/e6pkCeW5zWm87CMDQClTOgQZ6PPkbMhiyLAwNrjWJddN+h
yjAagiM5om4akJ3VwTmBVsNDFjz8FQPKAlBvgaVGyCH+Ql5IWfaK68gjc+exCcpt
/3H+TTTLloQ0m2BYTrMhD2TVfU5yDTOHFCjndmlNxzRmEPfSo9o=
=h3CF
-END PGP SIGNATURE-

Bug#991425: unblock: mupdf/1.17.0+ds1-2 [pre-approval]

[陳侃如]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Please unblock package mupdf

[ Reason ]
To fix two CVEs
- - https://security-tracker.debian.org/tracker/CVE-2021-37220
- - https://security-tracker.debian.org/tracker/CVE-2020-19609

[ Impact ]
Potential denial of service caused by crashes or arbitrary code
execution caused by buffer overflow

[ Tests ]
I tested manually with reproducer files from upstream bug reports.
I also did some regression test with some PDF files.

[ Risks ]
Risks should be low. The changes are cherry-picked from
upstream and there weren't any other changes applied by upstream
between the two versions. The risk of faulty backport is low.

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

[ Other info ]
The source package src:mupdf produces the following binary packages:
- - mupdf
- - mupdf-dbgsym
- - mupdf-tools
- - mupdf-tools-dbgsym
- - libmupdf-dev

unblock mupdf/1.17.0+ds1-2


-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEE2JDTPWFH4vUeM4aHCjk1SrblfeEFAmD6g1sACgkQCjk1Srbl
feE/yQ/+KQEr5VOfJhJabt13ZZKLwE2ktpOgU4OwkfwlZy5Z5VoBC+r2WpIdL/TP
k1VbDEXgc57Yd+ZlHRe1baIYc9oiz7YnYyGpnUUVLOGrILqKqFOOtWLFpoa3fzwL
9uQu0trzUahJawdQDQq7Fp5GBkA3U/+KCtZ7+f9/33ACVioxv3S3LIsfDLnLztN3
E68ZjdasSXPX3GGWbUgkY7RG8h+47CNb3Vw+4Y50kN3zucM7PjP/8pdc6d4p6SoC
B6ad3bGyI1t9leaTwB9XRGDlCPNo1I73LcTNM1Uw9WCuPzSyavnpwL/lEATJLfuQ
nsfT3+9yNv+lgCtIEzG/UABFP6FpEqwOcna4zwCRSH78Q3UiICSULEr/nx9H/DRj
+vDwuWKXp7+Y/0CwVyJASf9YiSmcj0m2SJ/Z0GHRvytwtpQKEyRVjisYGDb9gJJ0
X/3gTyvwvox6OKY4Oh8qUgdLfPZUUeIAvwTZCRONNXss8SXKvSdopfq1RrdAnNy1
fVCvp9CvsGX34e11ZU0Fnna+9Ze+eAjFykssv3En1hgGdWoIMDNo+aSP68W9GtGb
FmxCwP2o39B4Uu7cU8WWcTPe8GgJBFNHZmqW9VBxO/zwFJNBrOM1Mz0aNbKwfsXz
X6dW7PlonVR2M0rwhlgRgYp0ir2+hK87HEiQJvbnS5gabTAFyBo=
=C38i
-END PGP SIGNATURE-
diff -Nru mupdf-1.17.0+ds1/debian/changelog mupdf-1.17.0+ds1/debian/changelog
--- mupdf-1.17.0+ds1/debian/changelog   2021-02-28 21:40:40.0 +0900
+++ mupdf-1.17.0+ds1/debian/changelog   2021-07-23 17:09:37.0 +0900
@@ -1,3 +1,11 @@
+mupdf (1.17.0+ds1-2) unstable; urgency=medium
+
+  * Fix buffer overrun in tiff decoder (CVE-2020-19609) (Closes: #991401)
+  * Stay within hash table max key size in cached color converter
+(CVE-2021-37220) (Closes: #991402)
+
+ -- Kan-Ru Chen (陳侃如)   Fri, 23 Jul 2021 17:09:37 +0900
+
 mupdf (1.17.0+ds1-1.3) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru 
mupdf-1.17.0+ds1/debian/patches/0012-tiff-Avoid-limiting-palette-colors-to-8-bits.patch
 
mupdf-1.17.0+ds1/debian/patches/0012-tiff-Avoid-limiting-palette-colors-to-8-bits.patch
--- 
mupdf-1.17.0+ds1/debian/patches/0012-tiff-Avoid-limiting-palette-colors-to-8-bits.patch
 1970-01-01 09:00:00.0 +0900
+++ 
mupdf-1.17.0+ds1/debian/patches/0012-tiff-Avoid-limiting-palette-colors-to-8-bits.patch
 2021-07-23 16:54:49.0 +0900
@@ -0,0 +1,65 @@
+From: Sebastian Rasmussen 
+Date: Fri, 23 Jul 2021 16:32:29 +0900
+Subject: tiff: Avoid limiting palette colors to 8 bits.
+
+Previously fz_unpack_tile() could not handle >8 bit images,
+so palettized tiff colors had to be limited to 8 bits.
+Now when fz_unpack_tile() does handles >8 bit images do not
+limit the samples in the colormap to 8 bits.
+
+This fixes Coverity CID 150612.
+
+Cherry-picked-from: 
http://git.ghostscript.com/?p=mupdf.git;a=commitdiff;h=666c62d491ca76ade9a281dfe4c4e945cc71f8e8
+---
+ source/fitz/load-tiff.c | 16 +++-
+ 1 file changed, 11 insertions(+), 5 deletions(-)
+
+diff --git a/source/fitz/load-tiff.c b/source/fitz/load-tiff.c
+index c7c0bcf..bb69e2f 100644
+--- a/source/fitz/load-tiff.c
 b/source/fitz/load-tiff.c
+@@ -253,7 +253,7 @@ tiff_expand_colormap(fz_context *ctx, struct tiff *tiff)
+   if (tiff->imagelength > UINT_MAX / tiff->imagewidth / 
(tiff->samplesperpixel + 2))
+   fz_throw(ctx, FZ_ERROR_GENERIC, "image too large");
+ 
+-  stride = tiff->imagewidth * (tiff->samplesperpixel + 2);
++  stride = tiff->imagewidth * (tiff->samplesperpixel + 2) * 2;
+ 
+   samples = Memento_label(fz_malloc(ctx, stride * tiff->imagelength), 
"tiff_samples");
+ 
+@@ -269,25 +269,31 @@ tiff_expand_colormap(fz_context *ctx, struct tiff *tiff)
+   int c = tiff_getcomp(src, x * 2, 
tiff->bitspersample);
+   int a = tiff_getcomp(src, x * 2 + 1, 
tiff->bitspersample);
+   *dst++ = tiff->colormap[c + 0] >> 8;
++  *dst++ = tiff->colormap[c + 0];
+   *dst++ = tiff->colormap[c + maxval] >> 8;
++  *dst++ = tiff->colormap[c + maxval];
+   *dst++ = tiff->colormap[c + maxval * 2] >> 8;
+-  if (tiff->bitspersample <= 8)
+-  

Bug#991394: proftpd-basic: mod_sftp is missing an upstream fix: #866 "mod_sftp crashes when using pubkey-auth with DSA keys"

[Hilmar Preuße]

Am 22.07.2021 um 17:38 teilte Anishchuk, Igor mit:

Hi,


When connecting to proftpd daemon using SFTP protocol and authenticating
using a DSS key, the server process crashes with segmentation fault.
This is caused by an upstream issue #866
(https://github.com/proftpd/proftpd/issues/866) that is fixed in PR #867
(https://github.com/proftpd/proftpd/pull/867).

The issue happens in module mod_sftp that has an obvious copy-paste
error in the code. The upstream fix #867 reliably solves the issue.


I've put new packages on https://freeshell.de/hille42/991394/ .

Could you test them?

Hilmar
--
sigfault




OpenPGP_signature
Description: OpenPGP digital signature

Bug#991417: simple-cdd generated iso: No kernel modules were found

[John Paul Adrian Glaubitz]

Hi Mike!

On 7/23/21 3:23 AM, Mike Depot wrote:
> Machine: qemu kvm, on top of bullseye amd64
> Processor: QEMU Virtual CPU version 2.5+ (over i7-6920HQ physical)
> Memory: 4G in QEMU (64G physical)
> 
> I've been using simple-cdd running on my bullseye host to generate a custom 
> iso (also bullseye). 
> My simple-cdd config had been working fine until a couple days ago.  Now I am 
> getting an error
> early in debian-installer when I boot from the generated ISO:
> 
> "No kernel modules were found. This probably is due to a mismatch between the 
> kernel used by this
> version of the installer and the kernel version available in the archive."

This happens when the kernel ABI version that debian-installer booted into does 
not match the kernel
ABI version of the debian-installer module udebs on the installation medium.

I assume that simple-cdd is just re-using the d-i images which contain a 
certain kernel version while
retrieving the d-i module udebs from the archives which then can lead to the 
version mismatch in
case the kernel is updated in the archives.

Thus, the bug lies in simple-cdd which should pick the d-i images and the d-i 
module udebs from Debian
testing or stable where such a mismatch cannot occur. Alternatively, it could 
also rebuild debian-installer
itself to make sure the d-i images use the kernel ABI version that matches the 
one of the d-i module
udebs.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Bug#991414: volk no longer supports neon on armhf

[Johannes Demel]

Hi all,

I had a quick look at the issue. Let me summarize some info I gathered.
It started with raspbian not having NEON support enabled but current 
Debian disables it as well. Is this a 32bit or 64bit issue? Or both? 
Which compiler is this exactly?


Does it only fail with this one kernel 
`volk_16i_max_star_horizontal_16i`? This is one of the few, "legacy" 
kernels [0].

We might really want to remove them in a major release.

I know I could build VOLK on an ARM Chromebook in a Linux container. It 
works on M1 MacOS (with some CMake fixes). I think I was able to compile 
it on a RPi3 some time ago. I know cross-compiles are preferable but 
let's start small.


I have a suspicion that

> Error: selected processor does not support `vld2.16 {d16-d19},[r4]!' 
in ARM mode


really tells us that the target arch and the instruction really aren't 
compatible. If this would only be an issue for this particular kernel, 
we might just remove the NEON version (it's 'one-of-those-legacy' ones 
after all).
It sounds weird to state we have NEON but... And then again, we have [1] 
where we need to fix things depending on the NEON version.


Cheers
Johannes


[0] 
https://github.com/gnuradio/volk/blob/237a6fc9242ea8c48d2bbd417a6ea14feaf7314a/lib/kernel_tests.h#L165
[1] 
https://github.com/gnuradio/volk/blob/237a6fc9242ea8c48d2bbd417a6ea14feaf7314a/include/volk/volk_neon_intrinsics.h#L289


On 23.07.21 00:16, Marcus Müller wrote:

Hi Peter,

thanks for digging in so deeply!

First thing I'm going to do: Loop Johannes Demel in here, he's the most 
knowledgeable
person on the CPU detection and build issues.

Johannes, see below. There's two things to unpack here:

1. It looks like debian disables NEON. Do we need to check with Mait on that? 
Or is this
somehow "right"?
2. see the build problem; that looks like an archi/µarch mismatch, but I don't 
know how to
interpret it.

Maybe you can shine some light on this?

Best regards,
Marcus


On 23.07.21 00:07, peter green wrote:

Package: volk
Version: 2.0.0-1
Severity: important
X-debbugs-cc: mmuel...@gnuradio.org

Hi,

While raspbian and Debian armhf have different baselines what they share in
common is that neon is not part of the baseline configuration but is present on
a large proportion of the systems people use in practice (for Debian armhf I
suspect nearly all users have neon, for raspbian it's less because we still
have pi1/pi0 users around) . So where upstream supports runtime detection
of neon said runtime detection should be enabled and used.

Back in 2015 I disabled neon in raspbian's volk package, I can't remember why
but I suspect it was because at the time I had no means of determining whether
the package had runtime CPU   detection.

alle_die_mit_der from gnuradio upstream came into #raspbian on irc (to ask about
options for building stuff) and I took the opportunity to talk about the issue
of runtime CPU detection. He guided me on how to test volk (quotes below) and
I thus decided to revert our raspbian neon-disabling changes and build a package
for testing on raspbian bullseye.


 The volk package in raspbian currently has neon disabled. from what 
you have
said I strongly suspect it could be re-enabled but before I actually re-enable 
it I need
a test plan that I can use to make sure i'm not breaking anything.
 VOLK has a unit test for every single "kernel"
 `make test` is your friend :)
 is there a way to run the tests against an installed version of volk?
 yeah
 `volk_profile` essentially does the same, while benchmarking 
them
<--snip-->
 does volk_profile use the same runtime cpu detection as normal use 
of volk?
 yes
 it should
<--snip-->
 you can query the runtime-available platforms with 
`volk-config-info
--avail-machines`


However to my surprise I discovered that the package built on raspbian from
unmodified Debian sources didn't have any neon support either. I discovered that
the CMake scripts were failing to detect Neon because they were not using
-mfpu=neon when building test programs.

I have confirmed this is not a raspbian specific issue and it seems to have
been this way since version 2.0.0, this makes it a regression between buster
and bullseye.

I modified the cmake scripts to use -mfpu=neon when detecting neon support
but then the build itself failed with.


cd /volk-2.4.1.new/obj-arm-linux-gnueabihf/lib && /usr/bin/cc -DHAVE_DLFCN_H
-DHAVE_FENV_H -D_GLIBCXX_USE_CXX11_ABI=1 -I/volk-2.4.1.new/kernels/volk/asm/neon
-I/usr/include/orc-0.4 -I/volk-2.4.1.new/obj-arm-linux-gnueabihf/include
-I/volk-2.4.1.new/include -I/volk-2.4.1.new/kernels
-I/volk-2.4.1.new/obj-arm-linux-gnueabihf/lib -I/volk-2.4.1.new/lib
-I/usr/include/cpu_features -O2 -g -DNDEBUG -fPIC -o
CMakeFiles/volk_obj.dir/__/kernels/volk/asm/neon/volk_16i_max_star_horizontal_16i.s.o
 -c
/volk-2.4.1.new/kernels/volk/asm/neon/volk_16i_max_star_horizontal_16i.s
/volk-2.4.1.new/kernels/volk/asm/neon/volk_16i_max_star_horizontal_16i.s: 
Assembler
messages:

Bug#991366: nmu: varnish-modules_0.16.0-2.1

[Stig Sandbeck Mathisen]

Adrian Bunk  writes:

> I am not a member of the release team, but shouldn't #991348 be a
> release critical bug in any case?
>
> An security update of varnish after bullseye became stable could cause
> to same problem, breaking production systems of our users.

[...]

> Doing first an NMU and then the proper fix of varnish-modules for 
> bullseye is not faster than doing the proper fix for varnish-modules
> right away.

Good points, I'll adjust the severity of #991348, do a proper update and
request an unblock. Thanks for the feedback.

-- 
Stig Sandbeck Mathisen
Debian Developer

Bug#991424: mirror submission for debian.mithril.re

[Jean-Noel Rouchon]

Package: mirrors
Severity: wishlist
User: mirr...@packages.debian.org
Usertags: mirror-submission

Submission-Type: new
Site: debian.mithril.re
Type: leaf
Archive-architecture: amd64
Archive-http: /debian/
Maintainer: Jean-Noel Rouchon 
Country: RE Réunion
Location: Reunion (Indian Ocean)
Sponsor: Mithril Informatique https://mithril.re




Trace Url: http://debian.mithril.re/debian/project/trace/
Trace Url: http://debian.mithril.re/debian/project/trace/ftp-master.debian.org
Trace Url: http://debian.mithril.re/debian/project/trace/debian.mithril.re

Bug#986462: (no subject)

[Ludovic Pouzenc]

Hi,

I confirm that I didn't see any troubles since then with the proposed 
patch. I ran this only on single a amd64 VM but it's shell script func 
call with numbered args... so should be fine for any arch.


Regards,

--
Ludovic Pouzenc
Ingénieur Informatique de Gestion
Direction du Numérique, DN : Applications
04 79 75 83 54

Bug#991366: nmu: varnish-modules_0.16.0-2.1

[Adrian Bunk]

On Wed, Jul 21, 2021 at 05:48:52PM +0200, Stig Sandbeck Mathisen wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: binnmu
> 
> Hello,
> 
> Please do a BinNMU of "varnish-modules" to ensure that the "varnish" security
> fix can migrate to testing.
> 
> Background: After upgrading "varnish" from 6.5.1 to 6.5.2, the module
> "bodyaccess" in this package fails to load, which was discovered with
> autopkgtest. The "bodyaccess" module has a stricter dependency on the Varnish
> version than the dependency declared in the "varnish-modules" package.
> 
> Getting the correct dependency into "varnish-modules" is tracked in
> https://bugs.debian.org/991348,

I am not a member of the release team, but shouldn't #991348 be a
release critical bug in any case?

An security update of varnish after bullseye became stable could cause
to same problem, breaking production systems of our users.

> but a rebuild of "varnish-modules" against the
> new varnish package may be a faster fix due to the freeze.
>...

Doing first an NMU and then the proper fix of varnish-modules for 
bullseye is not faster than doing the proper fix for varnish-modules
right away.

cu
Adrian

Bug#991423: xmltooling: autopkgtest regression since mid-July 2021

[Graham Inggs]

Source: xmltooling
Version: 3.2.0-2
Severity: serious
User: debian...@lists.debian.org
Usertags: regression
X-Debbugs-CC: debian...@lists.debian.org

Hi Maintainer

Sometime around mid-July 2021, xmltooling's autopkgtests started to
fail in testing [1].
I've copied what I hope is the relevant part of the log below.

Regards
Graham


[1] https://ci.debian.net/packages/x/xmltooling/testing/amd64/


FAIL: xmltoolingtest
=
   xmltooling 3.2.0: xmltoolingtest/test-suite.log
=

# TOTAL: 1
# PASS:  0
# SKIP:  0
# XFAIL: 0
# FAIL:  1
# XPASS: 0
# ERROR: 0

.. contents:: :depth: 2

FAIL: xmltoolingtest


Running cxxtest tests (125 tests)..1627022354 WARN
XMLTooling.XMLHelper : DEPRECATED: attribute "ignoreCase" encountered
in configuration. Use "caseSensitive".
1627022354 WARN XMLTooling.XMLHelper : DEPRECATED: attribute
"ignoreCase" encountered in configuration. Use "caseSensitive".
1627022354 WARN XMLTooling.XMLHelper : DEPRECATED: attribute
"ignoreCase" encountered in configuration. Use "caseSensitive".
1627022354 WARN XMLTooling.XMLHelper : Attribute "ignoreCase" and
"caseSensitive" should not be used in the same element.
.1627022354 WARN DirectoryWalkerTest : Unable to open directory (invalid)
...1627022354 ERROR XMLTooling.ParserPool : fatal error on
line 2, column 10, message: invalid document structure
.1627022354 ERROR XMLTooling.XMLObject : no default builder
installed, found unknown child element (test:UnknownElement)
..1627022354 WARN XMLTooling.KeyInfoResolver.Inline : skipping
invalid ds:KeyValue (Modulus must have TextContent.)
.1627022354 WARN XMLTooling.KeyInfoResolver.Inline : skipping invalid
ds:KeyValue (Exponent must have TextContent.)
.1627022354 WARN XMLTooling.KeyInfoResolver.Inline : skipping invalid
ds:KeyValue (Modulus must have TextContent.)
.1627022354 WARN XMLTooling.KeyInfoResolver.Inline : skipping invalid
ds:KeyValue (RSAKeyValue must have Modulus.)
1627022354 WARN XMLTooling.KeyInfoResolver.Inline : skipping
invalid ds:KeyValue (DSKeyValue cannot have P without Q.)
.1627022354 WARN XMLTooling.KeyInfoResolver.Inline : skipping invalid
ds:KeyValue (P must have TextContent.)
...1627022354 WARN XMLTooling.KeyInfoResolver.Inline : skipping
invalid ds:KeyValue (DSKeyValue cannot have P without Q.)
..1627022354 WARN XMLTooling.KeyInfoResolver.Inline : skipping invalid
ds:KeyValue (Q must have TextContent.)
.1627022354 WARN XMLTooling.KeyInfoResolver.Inline : skipping invalid
ds:KeyValue (P must have TextContent.)
1627022354 WARN XMLTooling.KeyInfoResolver.Inline : skipping
invalid ds:KeyValue (G must have TextContent.)
.1627022354 WARN XMLTooling.KeyInfoResolver.Inline : skipping
invalid ds:KeyValue (DSAKeyValue must have Y.)
.1627022354 WARN XMLTooling.KeyInfoResolver.Inline : skipping invalid
ds:KeyValue (Y must have TextContent.)
.1627022354 WARN XMLTooling.KeyInfoResolver.Inline : skipping invalid
ds:KeyValue (J must have TextContent.)
.1627022354 WARN XMLTooling.KeyInfoResolver.Inline : skipping
invalid ds:KeyValue (DSKeyValue cannot have Seed without PgenCounter.)
.1627022354 WARN XMLTooling.KeyInfoResolver.Inline : skipping invalid
ds:KeyValue (Seed must have TextContent.)
..1627022354 WARN XMLTooling.KeyInfoResolver.Inline : skipping invalid
ds:KeyValue (DSKeyValue cannot have Seed without PgenCounter.)
.1627022354 WARN XMLTooling.KeyInfoResolver.Inline : skipping invalid
ds:KeyValue (PgenCounter must have TextContent.)
.1627022354 WARN XMLTooling.KeyInfoResolver.Inline : resolving ds11:ECKeyValue
.1627022354 ERROR XMLTooling.KeyResolver.Inline : caught XML-Security
exception loading certificate: OpenSSL:EC - Error translating Base64
octets into OpenSSL EC_KEY structure
1627022354 WARN XMLTooling.KeyInfoResolver.Inline : resolving ds11:ECKeyValue
1627022354 ERROR XMLTooling.KeyInfoResolver.Inline : caught
XML-Security exception loading key: OpenSSL:EC - Error translating
Base64 octets into OpenSSL EC_KEY structure
.1627022354 ERROR XMLTooling.KeyResolver.Inline : caught XML-Security
exception loading certificate: OpenSSL:EC - Error translating Base64
octets into OpenSSL EC_KEY structure
1627022354 WARN XMLTooling.KeyInfoResolver.Inline : resolving ds11:ECKeyValue
1627022354 ERROR XMLTooling.KeyInfoResolver.Inline : caught
XML-Security exception loading key: OpenSSL:EC - Error translating
Base64 octets into OpenSSL EC_KEY structure
.1627022354 WARN XMLTooling.KeyInfoResolver.Inline : skipping invalid
ds:KeyValue (PublicKey must have TextContent.)
.1627022354 WARN XMLTooling.KeyInfoResolver.Inline : skipping invalid
ds:KeyValue (ECKeyValue must have PublicKey.)
.1627022354 ERROR XMLTooling.KeyResolver.Inline : caught XML-Security
exception loading certificate: OpenSSLCryptoProvider::curveNameToNID -
curve name not recognized
1627022354 WARN XMLTooling.KeyInfoResolver.Inline : resolving ds11:ECKeyValue
1627022354 ERROR 

Bug#991422: aws-shell missing dependency for groff

[hans]

Package: aws-shell
Version: 0.2.1-1
Severity: normal

Dear Maintainer,

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

   * What led up to the situation?
   tried running "aws help" on a minimalistic debian installation
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
   sudo apt install aws-shell; aws help;
   * What was the outcome of this action?
   root@e8ef7b122f01:/temp# aws help
   Could not find executable named "groff"
   * What outcome did you expect instead?
   argument documentation.

   PS as a workaround one can just run "sudo apt install groff"
*** End of the template - remove these template lines ***


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

Kernel: Linux 5.4.0-77-generic (SMP w/4 CPU cores)
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: unable to detect

Versions of packages aws-shell depends on:
ii  awscli  1.16.113-1
ii  python3 3.7.3-1
ii  python3-boto3   1.9.86-1
ii  python3-configobj   5.0.6-3
ii  python3-prompt-toolkit  1.0.15-1
ii  python3-pygments2.3.1+dfsg-1+deb10u2

aws-shell recommends no packages.

aws-shell suggests no packages.

-- no debconf information

Bug#990083: Further testing

[Vasyl Gello]

Control: close -1

Hi Fabrice!

>I suggest you close this bug, sorry to have wasted your time.

No problem! Feel free to reopen the bug if you find something worth our 
attention!
-- 
Vasyl Gello
==
Certified SolidWorks Expert

Mob.:+380 (98) 465 66 77

E-Mail: vasek.ge...@gmail.com

Skype: vasek.gello
==
호랑이는 죽어서 가죽을 남기고 사람은 죽어서 이름을 남긴다

Bug#991419: new upstream (0.7.1)

[Robert Edmonds]

Daniel Baumann wrote:
> Package: ck
> 
> Hi Robert
> 
> Thank you for maintaining "ck" in Debian.
> 
> One of my packages (dnsperf) requires ck which unfortunately is
> currently not build on armel. I've locally built and verified the
> current "ck" upstream version (0.7.1) on amd64/i386 and all arm*
> architectures.
> 
> I saw that your last upload of it was in 2017 and collected some dust
> since. Are you still interested in maintaining "ck"? Do you like some help?
> 
> Given it's a build-dependency of dnsperf (and a few other packages of
> mine), I'd be happy to take the package over in case you're not
> interested anymore.
> 
> Regards,
> Daniel

Hi, Daniel:

Unfortunately I don't have much time to spend on ck these days, and I
don't have any packages that need it as a build dependency. Feel free to
ITA.

Thanks!

-- 
Robert Edmonds
edmo...@debian.org

Bug#991421: unblock: lemonldap-ng/2.0.11+ds-4

[Yadd]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: secur...@debian.org

Please unblock package lemonldap-ng

[ Reason ]
lemonldap-ng 2.0.11+ds-3 has several vulnerabilities fixed in 2.0.12.
This update fixes:
 * Session cache corruption can lead to authorization bypass or spoofing
   (Closes: CVE-2021-35472)
 * OAuth2 handler does not verify access token validity
   (Closes: CVE-2021-35473)
 * XSS on register form
 * Bad behavior which displays TOTP secret to connected user and debug logs

[ Impact ]
One high vulnerability (CVE-2021-35472) and medium others

[ Tests ]
New upstream test not imported here. Current tests passed (both build
and autopkgtest)

[ Risks ]
Low risk. lemonldap-ng is developed following BDD/TDD, so most features
are tested.

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

[ Other info ]
(Anything else the release team should know.)

unblock lemonldap-ng/2.0.11+ds-4
diff --git a/debian/changelog b/debian/changelog
index d3c338880..a56d54279 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,15 @@
+lemonldap-ng (2.0.11+ds-4) unstable; urgency=high
+
+  * Import security fixes from 2.0.12
+* Session cache corruption can lead to authorization bypass or spoofing
+  (Closes: CVE-2021-35472)
+* OAuth2 handler does not verify access token validity
+  (Closes: CVE-2021-35473)
+* Fix XSS on register form
+* Don't display TOTP secret to connected user, neither in logs
+
+ -- Yadd   Thu, 22 Jul 2021 22:13:38 +0200
+
 lemonldap-ng (2.0.11+ds-3) unstable; urgency=medium
 
   * Add Breaks+Replaces in lemonldap-ng-handler for
diff --git a/debian/patches/CVE-2021-35472.patch 
b/debian/patches/CVE-2021-35472.patch
new file mode 100644
index 0..16a4e4c10
--- /dev/null
+++ b/debian/patches/CVE-2021-35472.patch
@@ -0,0 +1,30 @@
+Description: fix session cache corruption
+Author: Yadd 
+Origin: upstream, 
https://gitlab.ow2.org/lemonldap-ng/lemonldap-ng/-/commit/b6a1f946
+Bug: https://gitlab.ow2.org/lemonldap-ng/lemonldap-ng/-/issues/2539
+Forwarded: not-needed
+Last-Update: 2021-06-25
+
+--- a/lemonldap-ng-handler/lib/Lemonldap/NG/Handler/Main/Run.pm
 b/lemonldap-ng-handler/lib/Lemonldap/NG/Handler/Main/Run.pm
+@@ -139,7 +139,9 @@
+ }
+ 
+ # Try to recover cookie and user session
+-if ($id = $class->fetchId($req)
++$id = $class->fetchId($req);
++$class->data( {} ) unless($id);
++if ($id
+ and $session = $class->retrieveSession( $req, $id ) )
+ {
+ 
+--- a/lemonldap-ng-portal/t/75-2F-Registers.t
 b/lemonldap-ng-portal/t/75-2F-Registers.t
+@@ -439,6 +439,7 @@
+ ),
+ 'Push U2F signature'
+ );
++$id = expectCookie($res);
+ ok(
+ $res = $client->_get(
+ '/2fregisters',
diff --git a/debian/patches/CVE-2021-35473.patch 
b/debian/patches/CVE-2021-35473.patch
new file mode 100644
index 0..535252b03
--- /dev/null
+++ b/debian/patches/CVE-2021-35473.patch
@@ -0,0 +1,69 @@
+Description: Add missing access token expiration check in OAuth2 handler
+Author: Maxime Besson 
+Origin: upstream, 
https://gitlab.ow2.org/lemonldap-ng/lemonldap-ng/-/commit/23a8a100
+Bug: https://gitlab.ow2.org/lemonldap-ng/lemonldap-ng/-/issues/2549
+Forwarded: not-needed
+Reviewed-By: Yadd 
+Last-Update: 2021-06-25
+
+--- a/lemonldap-ng-handler/lib/Lemonldap/NG/Handler/Lib/OAuth2.pm
 b/lemonldap-ng-handler/lib/Lemonldap/NG/Handler/Lib/OAuth2.pm
+@@ -10,16 +10,17 @@
+ 
+ # Retrieve regular session if this is not an offline access token
+ unless ($offlineId) {
+-my $data = {
+-%{
+-$class->Lemonldap::NG::Handler::Main::retrieveSession( $req,
+-$id )
+-},
+-$class->_getTokenAttributes($req)
+-};
++my $data =
++  $class->Lemonldap::NG::Handler::Main::retrieveSession( $req, $id );
++if ( ref($data) eq "HASH" ) {
++$data = { %{$data}, $class->_getTokenAttributes($req) };
+ 
+-# Update cache
+-$class->data($data);
++# Update cache
++$class->data($data);
++}
++else {
++$req->data->{oauth2_error} = 'invalid_token';
++}
+ return $data;
+ }
+ 
+@@ -87,6 +88,10 @@
+ 
+ # Get access token session
+ my $infos = $class->getOIDCInfos($access_token);
++unless ($infos) {
++$req->data->{oauth2_error} = 'invalid_token';
++return;
++}
+ 
+ # Store scope and rpid for future session attributes
+ if ( $infos->{rp} ) {
+@@ -141,6 +146,20 @@
+ unless ( $oidcSession->error ) {
+ $class->logger->debug("Get OIDC session $id");
+ 
++# Verify that session is valid
++unless ( $oidcSession->data->{_utime} ) {
++