Bug#985957: usrmerge has 47.3MB of dependencies

[Niko Tyni]

On Mon, Aug 16, 2021 at 12:11:26AM +0200, Marco d'Itri wrote:

> I see no reason to move the usrmerge dependencies to perl-base: usrmerge 
> is supposed to be installed, run and then removed again.
> If something is moved to perl-base then it will use space on every 
> Debian system.

My suggestion in #987615 (which I also copied to usrmerge@pdo, being
unaware of #985957) is to introduce separate packages of the usrmerge
dependencies, and limit their dependencies to perl-base only. This does
not grow perl-base and can be phased out later, so it does not impose
a permanent cost on everybody.
-- 
Niko Tyni   nt...@debian.org

Bug#992227: djview4: Please upgrade

[Janusz S . Bień]

Package: djview4
Version: 4.12-2
Severity: wishlist
X-Debbugs-Cc: none, Janusz S. Bień 

Dear Maintainer,

Please note in particular the upstream commit [e8cb9e] of 2021-06-09
"Added polish translation by Janusz S. Bień and Tomasz Świerczek".

Best regards

Janusz

P.S. This is the first time I report a bug from bullseye. Is the line
"X-Debbugs-Cc: none, Janusz S. Bień " correct? It
seems to me that earlier there was no "none".


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

Kernel: Linux 5.10.0-8-amd64 (SMP w/12 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 djview4 depends on:
ii  libc62.31-13
ii  libdjvulibre21   3.5.28-2
ii  libgcc-s110.2.1-6
ii  libqt5core5a 5.15.2+dfsg-9
ii  libqt5gui5   5.15.2+dfsg-9
ii  libqt5network5   5.15.2+dfsg-9
ii  libqt5opengl55.15.2+dfsg-9
ii  libqt5printsupport5  5.15.2+dfsg-9
ii  libqt5widgets5   5.15.2+dfsg-9
ii  libstdc++6   10.2.1-6
ii  libtiff5 4.2.0-1
ii  sensible-utils   0.0.14

Versions of packages djview4 recommends:
ii  djvulibre-desktop  3.5.28-2

Versions of packages djview4 suggests:
ii  djvulibre-bin  3.5.28-2

-- no debconf information

-- 
 ,   
Janusz S. Bien
emeryt (emeritus)
https://sites.google.com/view/jsbien

Bug#984798: Upload cmd2 to unstable

[Thomas Goirand]

Hi,

Can cmd2 1.5.0 (currently in Experimental) be uploaded to Unstable now
that Bullseye is out please? Let me know if you prefer that I NMU it.

Cheers,

Thomas Goirand (zigo)

Bug#992226: piuparts: bullseye is now stable

[Sebastian Ramacher]

Package: piuparts.debian.org
Severity: normal
X-Debbugs-Cc: sramac...@debian.org

Since bullseye was release on Saturday, please change all jobs that
start from stable (e.g., stable2sid) to use bullseye instead of buster.

Cheers
-- 
Sebastian Ramacher


signature.asc
Description: PGP signature

Bug#992224: gparted: unable to create exfat filesystem in gparted

[will]

Package: gparted
Version: 1.2.0-1
Severity: normal
X-Debbugs-Cc: wiiliamchung...@gmail.com

Dear Maintainer,

Gparted attempts to create an exfat filesystem with an invalid syntax for the
filesystem label flag -L. Changing the flag to -n fixes the problem.

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

Kernel: Linux 5.11.18-21.05.03.amdgpu (SMP w/32 CPU threads)
Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not
set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages gparted depends on:
ii  gparted-common1.2.0-1
ii  libatkmm-1.6-1v5  2.28.0-3
ii  libc6 2.31-13
ii  libcairomm-1.0-1v51.12.2-4
ii  libgcc-s1 10.2.1-6
ii  libglib2.0-0  2.66.8-1
ii  libglibmm-2.4-1v5 2.64.2-2
ii  libgtk-3-03.24.24-4
ii  libgtkmm-3.0-1v5  3.24.2-2
ii  libpangomm-1.4-1v52.42.1-1
ii  libparted-fs-resize0  3.4-1
ii  libparted23.4-1
ii  libsigc++-2.0-0v5 2.10.4-2
ii  libstdc++610.2.1-6
ii  libuuid1  2.36.1-7
ii  policykit-1   0.105-31

gparted recommends no packages.

Versions of packages gparted suggests:
pn  dmraid 
ii  dmsetup2:1.02.175-2.1
ii  dosfstools 4.2-1
ii  e2fsprogs  1.46.2-2
pn  gpart  
pn  jfsutils   
pn  kpartx 
pn  mtools 
ii  ntfs-3g1:2017.3.23AR.3-4
pn  reiser4progs   
pn  reiserfsprogs  
pn  udftools   
pn  xfsprogs   
ii  yelp   3.38.3-1
>From 84436d1e04cbeb1fc74beb738c15d87c3d8e9421 Mon Sep 17 00:00:00 2001
From: mrwm 
Date: Sun, 15 Aug 2021 22:00:36 -0700
Subject: [PATCH 1/1] Fix exfat label syntax

Changes mkfs.exfat -L to use -n
---
 src/exfat.cc | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/exfat.cc b/src/exfat.cc
index 41d0e72..0b1e841 100644
--- a/src/exfat.cc
+++ b/src/exfat.cc
@@ -55,7 +55,7 @@ FS exfat::get_filesystem_support()
 
 bool exfat::create(const Partition& new_partition, OperationDetail& 
operationdetail)
 {
-   return ! execute_command("mkfs.exfat -L " + 
Glib::shell_quote(new_partition.get_filesystem_label()) +
+   return ! execute_command("mkfs.exfat -n " + 
Glib::shell_quote(new_partition.get_filesystem_label()) +
 " " + 
Glib::shell_quote(new_partition.get_path()),
 operationdetail, 
EXEC_CHECK_STATUS|EXEC_CANCEL_SAFE);
 }
-- 
2.32.0

Bug#992219: [Pkg-zfsonlinux-devel] Bug#992219: zfs-dkms: Error! Bad return status for module build on kernel: 5.13.0-trunk-amd64 (x86_64)

[Antonio Russo]

Control: severity -1 wishlist
Control: retitle -1 Please backport support for 5.13

Hello,

ZFS 2.0.3 doesn't support 5.13.  Neither does 2.0.5, (which is a
matter of some friction).  You'll have to switch to 2.1 if you
can't wait -- and I haven't gotten around to packaging it yet.

- Antonio


OpenPGP_0xB01C53D5DED4A4EE.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Bug#754831: [apt-listchanges] Program Crashes On Konsole Sessions

[Brian Thompson]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Which pager are you using, or does this occur for all pagers in KDE
Konsole?

- -- 
Best regards,

Brian T.
-BEGIN PGP SIGNATURE-

iQJHBAEBCgAxFiEE9fpVo96/flopdKOfgw2Ncu3Nhn0FAmEZ7d8THGJyaWFuQGhh
c2h2YXVsdC5pbwAKCRCDDY1y7c2GfeUwD/9VG1VdWeT/oW07i3R5HLYddBX34Igk
9YbB9IzXNt+RqG1IR1Qz6ZtJkwokykknO+GOEOIqIfjiVn8Y0DO1FQhqxG1K/z5z
XKCuX/+A8HD751Syhf+wa+2TuVY6zaNsO+8HAK4vOyMWrUN9UTP9YNEEYvv1YF89
EjlCVrWvqaiAlbVae6h78Wmm37cfcTgSb1daGNQEdh/VNKgqWJ2X8zOW7kFsG1ch
WSjvj2Ysd1+w70fPCQug+C670JYamILGEAOyrwogBqwqXXGvCGY9ofjTGsz09ayh
Q5IHEi1BdakcMwMdMKeHsxNKFMMEcvKLV5YMp2RF+o+E8PrK5ZmFTkGIs1H0N4qX
Cf9LQ4qFDIhlh1j0UL6wBgZOnZt2V+8Nolau4wJZxhP2m4UAHTWM61d53qP/y7Dk
ONiMMiP4d6Bn4DEVpRbcv1XMw6Dre2Pn0fMEZFee1HkPs7dCBIext1DYaQ5aP4iF
jn5zqszXOGimuacDdAXOwQK270hdcM7W3u4JK12VWtxAXJmeMoELkZmG+OTcsxWD
FxfzGPEGmU1wPvoS4ou2tgCaxELcEXZGJHWvkpSRjOWLIlIDyeHbywHK/1s8cdAL
2AZvIuWyXuc5akUbMyXueMjMQ5yLJE/RA7lcMo7wB+LDEDmysjWZpOaRFF2LSHtM
drFWZhcF+8hH2A==
=lejN
-END PGP SIGNATURE-

Bug#989923: Tests fail when server is running 24x80 terminal

[nick black]

I've made the recommended change. We were still seeing
intermittent, unrelated failures after doing so, and thus I
removed the test back in July. I can no longer reproduce these
failures, so I've just uploaded 2.3.13+dfsg.1-2 with the
offending test enabled anew. Let's see how it goes.

The upstream Notcurses bug is 
https://github.com/dankamongmen/notcurses/issues/1784.

Ubuntu current has 2.3.13+dfsg.1-1, so things have been
progressing there naturally for the duration of the Debian
Bullseye freeze.

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

[Brian Thompson]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On Sat, 14 Aug 2021 14:18:34 -0400 =?utf-8?Q?Antoine_Beaupr=C3=A9?= <
anar...@orangeseeds.org> wrote:
> 
> It's not on the package name, but there's already a clash on the
binary
> name, which we should be mindful of:
>  gitsome provides direct integration with GitHub and GitHub Enterprise
in
>  a terminal.
> 
> Since it's a git (and github, even!) related tool, we might even want
to
> Conflict with it directly...

Since there is already a package that uses that binary name, who should
change it? Do we follow a first-come first-serve binary name reservation
strategy? I don't think it's a big deal to change the name.

I'm not sure what to rename it to. I don't like binaries with long,
descriptive names, but I don't know what we could use that is short. I
will raise awareness about this issue with the upstream developers.
- -- 
Best regards,

Brian T.
-BEGIN PGP SIGNATURE-

iQJHBAEBCgAxFiEE9fpVo96/flopdKOfgw2Ncu3Nhn0FAmEZ7NQTHGJyaWFuQGhh
c2h2YXVsdC5pbwAKCRCDDY1y7c2GfeX5EAChFZ4pCKTj1uvCuyAxCzr12dfdfIqC
U27Bc1UwT5DAKs9T2EjihTkhstinwN3ZKLmOOznH1+lnmbdlXccYRtV4BZvu3diD
iyzP4t+5voLnxViYzO8WjHcxSlA7qNUY1/16nmOuTvrNmpaxS/54gjOyFXjdOWVc
CGCHUm2TG3aMTaW+OfOizBG+T+ThNNrkRg/8cKStgcR2vB8gwa/gJdT4qccsLCHv
ufrxVg3p7VzjVvBD7W4Z5uczqwnYR7/3FK3M65FH1TKZTCxDIv3BYGKIIEM0nXnJ
sLzFCucItVVi/Cc7CJf/sH9T49BzVfL+GTGFbDhue70+NpfOa++z7p22qq211Zvd
5E2vRXSLpQVmMY8QZy8+xDgBvi1CP1hBx98XbSE1RquV902naHowsFxTa4nkAPiK
nYU81R8TbLGwdPUXO/SgnSLQ9IlA7IotwfXmEhPAge8rYIR+2TtE0Da6ROeT8Tj4
lDiH9p6RS78Y49wihatMkpxKNkypQdUwq5AZb8p3b2j/h7hFz6l9m0TcAxxkggjZ
HPFDt0n0hGr6KzAtemFMP04OyqurMVCEtwn84ySmUI3Sy9i42uT36c2M7+TOd2iu
C2R/kXr7ZJ9fWxwpAkyv4/4rPqu2AwSeCluzUPRLTxR/8zqlTIwGK3tDlNQH3bQD
aTB5+YZvyIHIeg==
=YHqO
-END PGP SIGNATURE-

Bug#992223: autopkgtests test packages from boost1.71

[Michael Hudson-Doyle]

Source: boost1.74
Version: 1.74.0-9
X-Debbugs-CC: mwhud...@debian.org

Hi, the tests for the boost1.74 source package binaries from the boost1.71 
source package:

https://salsa.debian.org/debian/boost/-/blob/master/debian/tests/control

That can't be intended :)

Cheers,
mwh

Bug#992222: Upstream issue

[Nelson A. de Oliveira]

See also https://github.com/fenrus75/powertop/issues/38

Running "powertop --auto-tune" doesn't seem to be suitable to run
automatically, especially when dealing with various types of hardware.

Bug#992222: powertop: Should not automatically run when upgrading

[Nelson A. de Oliveira]

Package: powertop
Version: 2.13-1
Severity: important

Hi!

Today while upgrading powertop from 2.11-1 to 2.13-1 my mouse simply
stopped, because powertop was run at the upgrade process.

===
(…)
Configurando powertop (2.13-1) ...
Created symlink /etc/systemd/system/multi-user.target.wants/powertop.service → 
/lib/systemd/system/powertop.service.
(…)
===

Running "systemctl status powertop" I can see that in fact it did run:

===
● powertop.service - Powertop tunings
 Loaded: loaded (/lib/systemd/system/powertop.service; enabled; vendor pres>
 Active: inactive (dead) since Mon 2021-08-16 00:39:46 -03; 6min ago
   Main PID: 391493 (code=exited, status=0/SUCCESS)
CPU: 435ms

ago 16 00:39:44 spades powertop[391493]: RAPL Using PowerCap Sysfs : Domain Mas>
ago 16 00:39:44 spades powertop[391493]: RAPL device for cpu 0
ago 16 00:39:44 spades powertop[391493]: RAPL Using PowerCap Sysfs : Domain Mas>
ago 16 00:39:44 spades powertop[391493]: Devfreq not enabled
ago 16 00:39:44 spades powertop[391493]: glob returned GLOB_ABORTED
ago 16 00:39:46 spades powertop[391493]: Leaving PowerTOP
ago 16 00:39:46 spades powertop[391493]:  the port is sda
ago 16 00:39:46 spades powertop[391493]:  the port is sdb
ago 16 00:39:46 spades systemd[1]: powertop.service: Succeeded.
ago 16 00:39:46 spades systemd[1]: Finished Powertop tunings.
===

And running "powertop" I can see that *everything* was enabled.

My mouse has issues¹ with powertop and I guess that some other people
might also have problematic hardware.

¹ if I enable "Autosuspend for USB device USB Optical Mouse [Logitech]"
(which was just automatically enabled by powertop), my mouse turns off.

Unless every tunable option is known to be safe, powertop shouldn't be
automatically enabled/run.


Thank you!

Best regards,
Nelson


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

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

Versions of packages powertop depends on:
ii  libc6 2.31-13
ii  libgcc-s1 11.2.0-1
ii  libncursesw6  6.2+20201114-2
ii  libnl-3-200   3.4.0-1+b1
ii  libnl-genl-3-200  3.4.0-1+b1
ii  libpci3   1:3.7.0-5
ii  libstdc++611.2.0-1
ii  libtinfo6 6.2+20201114-2

powertop recommends no packages.

Versions of packages powertop suggests:
ii  cpufrequtils   008-2
ii  laptop-mode-tools  1.74-1.1

-- no debconf information

Bug#992219: [Pkg-zfsonlinux-devel] Bug#992219: zfs-dkms: Error! Bad return status for module build on kernel: 5.13.0-trunk-amd64 (x86_64)

[Mike Hommey]

severity 992219 important
retitle 992219 Cannot open 
/usr/src/linux-headers-5.13.0-trunk-common/scripts/modules-check.sh: No such 
file
thanks

On Sun, Aug 15, 2021 at 06:48:02PM -0600, Antonio Russo wrote:
> Control: severity -1 wishlist
> Control: retitle -1 Please backport support for 5.13
> 
> Hello,
> 
> ZFS 2.0.3 doesn't support 5.13.  Neither does 2.0.5, (which is a
> matter of some friction).  You'll have to switch to 2.1 if you
> can't wait -- and I haven't gotten around to packaging it yet.
> 
> - Antonio

The bug was reassigned to the linux-headers package because before
reaching the point where it is made apparent that zfs 2.0.3 doesn't
support Linux 5.13, we hit an error coming from a missing file in the
linux-headers package.

Bug#992221: 5.13 FTBFS on armel (kernel-wedge find-dups)

[Daniel Baumann]

Package: linux
Version: 5.13.9-1~exp2

Hi,

on armel the package FTBFs'es when running kernel-wedge find-dups:

---snip---
kernel-wedge install-files 5.13.0-trunk
install -D -m 644
debian/linux-image-5.13.0-trunk-marvell/boot/vmlinuz-5.13.0-trunk-marvell 
debian/kernel-image-5.13.0-trunk-marvell-di/boot/vmlinuz-5.13.0-trunk-marvell
install -d
debian/kernel-image-5.13.0-trunk-marvell-di/lib/modules/5.13.0-trunk-marvell
install -m 644
debian/linux-image-5.13.0-trunk-marvell/lib/modules/5.13.0-trunk-marvell/modules.builtin
debian/linux-image-5.13.0-trunk-marvell/lib/modules/5.13.0-trunk-marvell/modules.order
debian/kernel-image-5.13.0-trunk-marvell-di/lib/modules/5.13.0-trunk-marvell/
install -D -m 644
debian/linux-image-5.13.0-trunk-marvell/boot/System.map-5.13.0-trunk-marvell
debian/kernel-image-5.13.0-trunk-marvell-di/boot/System.map-5.13.0-trunk-marvell
install -d debian/kernel-image-5.13.0-trunk-marvell-di/usr/lib
cp -a
debian/linux-image-5.13.0-trunk-marvell/usr/lib/linux-image-5.13.0-trunk-marvell
debian/kernel-image-5.13.0-trunk-marvell-di/usr/lib/linux-image-5.13.0-trunk-marvell
kernel-wedge copy-modules 5.13.0-trunk marvell 5.13.0-trunk-marvell
kernel-wedge find-dups 5.13.0-trunk-marvell
some modules are in more than one package
debian/squashfs-modules-5.13.0-trunk-marvell-di
lib/modules/5.13.0-trunk-marvell/kernel/lib/lz4/lz4_decompress.ko
debian/f2fs-modules-5.13.0-trunk-marvell-di
lib/modules/5.13.0-trunk-marvell/kernel/lib/lz4/lz4_decompress.ko
command exited with status 1
make[2]: *** [debian/rules.real:573: install-udeb_armel] Error 2
make[2]: Leaving directory '/<>'
make[1]: *** [debian/rules.gen:57: binary-arch_armel] Error 2
make[1]: Leaving directory '/<>'
make: *** [debian/rules:43: binary-arch] Error 2
dpkg-buildpackage: error: debian/rules binary-arch subprocess returned
exit status 2
---snap---

Regards,
Daniel

Bug#992208: firefox-esr: Advertises for proprietary services

[Antonio Russo]

Hello,

Those instructions don't quite work. It did, however, lead me how to figure
it out (thank you).

If you want to do this, you have to:

1. Open ANOTHER tab (try it if you don't believe me, you have to do this)

2. On that tab, a section called "top sites" will appear.  Tab to the site
you would like to get ride of, and then hit tab one more time.  A HIDDEN
... menu appears.

Alternatively, hover over the top right of the icon of the site to see the
... menu.

3. Click it, and then select dismiss.



This doesn't address my other points about non-freedom respecting sites
being advertised by Debian, nor about the ability to remove this for
deployed systems.

Should I open another bug, or are you indicating that is some kind 
"won't fix"?  I can provide the patches to fix this.

- Antonio


OpenPGP_0xB01C53D5DED4A4EE.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Bug#992220: linux-kbuild-5.13 misses modules-check.sh

[Daniel Baumann]

Package: linux
Version: 5.13.9-1~exp2

Hi,

linux-kbuild-5.13 is missing scripts/modules-check.sh which is needed to
build some dkms modules (e.g. virtualbox).

Regards,
Daniel

Bug#992207: Freeradius postgresql mod broken in Bullseye

[Nick Smith]

Hi Bernhard,

Thanks for the quick response, sounds good!

Nick


 > Ack, this has already been fixed upstream at 
 >  
 > https://github.com/FreeRADIUS/freeradius-server/commit/eef366956e2e4a689ab33a0d1f265eb15f749d8d
 >  
 >  
 > I will try to make a bullseye-pu upgrade before the next stable update. 
 >  
 > Bernhard 
 > 

Bug#992189: RM: mlocate -- ROM; replaced with plocate

[Paul Wise]

On Sun, 2021-08-15 at 15:25 +0200, Steinar H. Gunderson wrote:

> If so, I guess that's an RC bug on cruft-ng? It would need to be
> changed to call the locate binary. (I'm not sure whether the database
> format is part of mlocate's API, but in plocate, it's definitely
> private.)

I guess you'll need to discuss it with the cruft-ng maintainer and add
whatever extra APIs are needed to plocate. There is already an open bug
(#976367) about the depends on mlocate though.

Personally, I think instead of adding the mlocate binary package to
plocate, we should have done a proper transition from one to the other,
there aren't that many packages depending on mlocate but not plocate.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#992219: zfs-dkms: Error! Bad return status for module build on kernel: 5.13.0-trunk-amd64 (x86_64)

[Mike Hommey]

reassign 992219 linux-headers-5.13.0-trunk-common
thanks

On Mon, Aug 16, 2021 at 09:31:25AM +0900, Mike Hommey wrote:
> Package: zfs-dkms
> Version: 2.0.3-9
> Severity: important
> 
> Dear Maintainer,
> 
> Installing zfs-dkms with the linux kernel currently in experimental
> fails with:
> 
> Preparing to unpack .../zfs-dkms_2.0.3-9_all.deb ...
> Unpacking zfs-dkms (2.0.3-9) ...
> Setting up zfs-dkms (2.0.3-9) ...
> Loading new zfs-2.0.3 DKMS files...
> Building for 5.13.0-trunk-amd64
> Building initial module for 5.13.0-trunk-amd64
> configure: error:
>   *** Unable to build an empty module.
> 
> Error! Bad return status for module build on kernel: 5.13.0-trunk-amd64 
> (x86_64)
> Consult /var/lib/dkms/zfs/2.0.3/build/make.log for more information.
> dpkg: error processing package zfs-dkms (--configure):
>  installed zfs-dkms package post-installation script subprocess returned 
> error exit status 10
> 
> 
> The contents of /var/lib/dkms/zfs/2.0.3/build/make.log are:
> 
> DKMS make.log for zfs-2.0.3 for kernel 5.13.0-trunk-amd64 (x86_64)
> Mon Aug 16 09:29:50 JST 2021
> make: *** No targets specified and no makefile found.  Stop.

This turns out to be a problem with the
linux-headers-5.13.0-trunk-common package.

zfs-dkms's configure runs the following:
KBUILD_MODPOST_NOFINAL= KBUILD_MODPOST_WARN= make modules -k -j64 -C 
/lib/modules/5.13.0-trunk-amd64/build 
M=/var/lib/dkms/zfs/2.0.3/build/build/conftest >build/conftest/build.log 2>&1

That output log file contains:

  CC [M]  /var/lib/dkms/zfs/2.0.3/build/build/conftest/conftest.o
sh: 0: cannot open 
/usr/src/linux-headers-5.13.0-trunk-common/scripts/modules-check.sh: No such 
file
make[1]: *** [/usr/src/linux-headers-5.13.0-trunk-common/Makefile:1796: 
modules_check] Error 2
make[1]: Target 'modules' not remade because of errors.
make: *** [/usr/src/linux-headers-5.13.0-trunk-common/Makefile:232: __sub-make] 
Error 2
make: Target 'modules' not remade because of errors.
make: Leaving directory '/usr/src/linux-headers-5.13.0-trunk-amd64'

It turns out the modules-check.sh file is missing from the headers
package.

Mike

Bug#992219: zfs-dkms: Error! Bad return status for module build on kernel: 5.13.0-trunk-amd64 (x86_64)

[Mike Hommey]

Package: zfs-dkms
Version: 2.0.3-9
Severity: important

Dear Maintainer,

Installing zfs-dkms with the linux kernel currently in experimental
fails with:

Preparing to unpack .../zfs-dkms_2.0.3-9_all.deb ...
Unpacking zfs-dkms (2.0.3-9) ...
Setting up zfs-dkms (2.0.3-9) ...
Loading new zfs-2.0.3 DKMS files...
Building for 5.13.0-trunk-amd64
Building initial module for 5.13.0-trunk-amd64
configure: error:
*** Unable to build an empty module.

Error! Bad return status for module build on kernel: 5.13.0-trunk-amd64 (x86_64)
Consult /var/lib/dkms/zfs/2.0.3/build/make.log for more information.
dpkg: error processing package zfs-dkms (--configure):
 installed zfs-dkms package post-installation script subprocess returned error 
exit status 10


The contents of /var/lib/dkms/zfs/2.0.3/build/make.log are:

DKMS make.log for zfs-2.0.3 for kernel 5.13.0-trunk-amd64 (x86_64)
Mon Aug 16 09:29:50 JST 2021
make: *** No targets specified and no makefile found.  Stop.

(I need to use the version in experimental because the version in
bullseye has some bugs on my hardware that are fixed in that version)

-- System Information:
Debian Release: 11.0
  APT prefers stable-security
  APT policy: (500, 'stable-security'), (500, 'stable-debug'), (500, 
'proposed-updates-debug'), (500, 'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 5.13.0-trunk-amd64 (SMP w/64 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 zfs-dkms depends on:
ii  debconf [debconf-2.0]  1.5.77
ii  dkms   2.8.4-3
ii  file   1:5.39-3
ii  libc6-dev [libc-dev]   2.31-13
ii  libpython3-stdlib  3.9.2-3
ii  lsb-release11.1.0
ii  perl   5.32.1-4+deb11u1
ii  python3-distutils  3.9.2-1

Versions of packages zfs-dkms recommends:
ii  linux-libc-dev  5.10.46-4
iu  zfs-zed 2.0.3-9
ii  zfsutils-linux  2.0.3-9

Versions of packages zfs-dkms suggests:
ii  debhelper  13.3.4

-- debconf information:
* zfs-dkms/note-incompatible-licenses:
  zfs-dkms/stop-build-for-unknown-kernel: true
  zfs-dkms/stop-build-for-32bit-kernel: true

Bug#992208: firefox-esr: Advertises for proprietary services

[Antonio Russo]

Package: firefox-esr
X-Debbugs-Cc: aeru...@aerusso.net
Version: 78.13.0esr-1~deb11u1
Severity: normal

Dear Maintainer,

   * What led up to the situation?

Install firefox-esr, remove any old profiles, start the program,
and click in the URL bar.  Advertisements for several non-free
online platforms are displayed.

These cannot (apparently) be removed by accessing settings, at
least easily (see below).

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

Pressing the arrow keys to select any of the advertised sites,
and pressing delete and/or shift-delete do nothing.

Disabling Amazon in the search engines also failed to remove its
advertisement (though it did indeed remove it as an enabled search
engine).

   * What was the outcome of this action?

Debian is advertising non-free and non-freedom respecting services.

   * What outcome did you expect instead?

No such advertisements.  At a minimum, the ability to remove/preset
these sites, in particular in an automated fashion when deploying to
many machines.

If desired, I can provide the patch to remove these advertisements,
or, if we can agree on such a list, a replacement set of websites to
show.

- Antonio


OpenPGP_0xB01C53D5DED4A4EE.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Bug#992218: xfce4-clipman floods .xsession-errors

[Gregory]

Package: xfce4-clipman
Version: 2:1.4.3-1
Severity: important
Justification: log file files entire disk

Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
From: Gregory 
To: Debian Bug Tracking System 
Subject: xfce4-clipman: none
X-Debbugs-Cc: greg...@eeye.io

Package: xfce4-clipman
Version: 2:1.4.3-1
Severity: important

Dear Maintainer,

On a recently installed system xfce4-clipman floods ~/.xsession-errors with 
messages like:
  (xfce4-clipman:960): Gdk-CRITICAL **: 15:50:03.999: 
gdk_window_get_device_position_double: assertion 'GDK_IS_WINDOW (window)' failed
  (xfce4-clipman:960): Gdk-CRITICAL **: 15:50:09.277: 
gdk_window_get_device_position_double: assertion 'GDK_IS_WINDOW (window)' failed
  (xfce4-clipman:960): Gdk-CRITICAL **: 15:50:09.533: 
gdk_window_get_device_position_double: assertion 'GDK_IS_WINDOW (window)' failed
  (xfce4-clipman:960): Gdk-CRITICAL **: 15:50:09.875: 
gdk_window_get_device_position_double: assertion 'GDK_IS_WINDOW (window)' failed
  (xfce4-clipman:960): Gdk-CRITICAL **: 15:50:27.747: 
gdk_window_get_device_position_double: assertion 'GDK_IS_WINDOW (window)' failed
  (xfce4-clipman:960): Gdk-CRITICAL **: 15:50:30.150: 
gdk_window_get_device_position_double: assertion 'GDK_IS_WINDOW (window)' failed
  (xfce4-clipman:960): Gdk-CRITICAL **: 15:50:31.361: 
gdk_window_get_device_position_double: assertion 'GDK_IS_WINDOW (window)' failed
  (xfce4-clipman:960): Gdk-CRITICAL **: 15:50:48.705: 
gdk_window_get_device_position_double: assertion 'GDK_IS_WINDOW (window)' failed
  (xfce4-clipman:960): Gdk-CRITICAL **: 15:50:49.469: 
gdk_window_get_device_position_double: assertion 'GDK_IS_WINDOW (window)' failed

See the attached file for more.

Unfortunately, the .xsession-errors file eventually filled up the entire hard 
disk.
Disabling and removing the clipman plugin from the panel seems to have solved 
the issue.

A similar, or identical, bug was reported to the XFCE community in February 
2020 and apparently fixed.
See this link:
  https://gitlab.xfce.org/panel-plugins/xfce4-clipman-plugin/-/issues/24


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

Kernel: Linux 4.19.0-17-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages xfce4-clipman depends on:
ii  libc6   2.28-10
ii  libgdk-pixbuf2.0-0  2.38.1+dfsg-1
ii  libglib2.0-02.58.3-2+deb10u3
ii  libgtk-3-0  3.24.5-1
ii  libqrencode44.0.2-1
ii  libx11-62:1.6.7-1+deb10u2
ii  libxfce4ui-2-0  4.12.1-3
ii  libxfce4util7   4.12.1-3
ii  libxfconf-0-2   4.12.1-1
ii  libxtst62:1.2.3-1

xfce4-clipman recommends no packages.

xfce4-clipman suggests no packages.

-- no debconf information

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

Kernel: Linux 4.19.0-17-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages xfce4-clipman depends on:
ii  libc6   2.28-10
ii  libgdk-pixbuf2.0-0  2.38.1+dfsg-1
ii  libglib2.0-02.58.3-2+deb10u3
ii  libgtk-3-0  3.24.5-1
ii  libqrencode44.0.2-1
ii  libx11-62:1.6.7-1+deb10u2
ii  libxfce4ui-2-0  4.12.1-3
ii  libxfce4util7   4.12.1-3
ii  libxfconf-0-2   4.12.1-1
ii  libxtst62:1.2.3-1

xfce4-clipman recommends no packages.

xfce4-clipman suggests no packages.

-- no debconf information
** (xfce4-clipman:960): WARNING **: 23:00:15.240: Unable to register 
GApplication: An object is already exported for the interface 
org.gtk.Application at /org/xfce/clipman
(xfce4-clipman:960): GLib-GIO-CRITICAL **: 23:00:15.240: 
g_application_get_is_remote: assertion 'application->priv->is_registered' failed
(xfce4-clipman:960): GLib-WARNING **: 23:00:15.240: g_set_application_name() 
called multiple times
xfce4-panel-Message: 23:00:18.672: Plugin xfce4-clipman-plugin-6 has been 
automatically restarted after crash.
(xfce4-clipman:960): GLib-CRITICAL **: 23:00:42.707: Source ID 49 was not found 
when attempting to remove it
(xfce4-clipman:960): GLib-CRITICAL **: 23:02:01.496: Source ID 250 was not 
found when attempting to remove it
(xfce4-clipman:960): Gdk-CRITICAL **: 23:02:01.746: 
gdk_window_get_device_position_double: assertion 'GDK_IS_WINDOW (window)' failed
(xfce4-clipman:960): Gdk-CRITICAL **: 23:1

Bug#992207: Freeradius postgresql mod broken in Bullseye

[Nick Smith]

Package: freeradius
Version: 3.0.21+dfsg-2.2 amd64

I just built a new Bullseye VM to replace my Buster freeradius VM.  Upon trying 
to configure it for a postgres backend, 'freeradius -X' fails out with the 
following:

...
including configuration file /etc/freeradius/3.0/mods-enabled/mschap
including configuration file /etc/freeradius/3.0/mods-enabled/sql
including configuration file 
/etc/freeradius/3.0/mods-config/sql/main/postgresql/queries.conf
/etc/freeradius/3.0/mods-config/sql/main/postgresql/queries.conf[505]: Parse 
error: Unterminated string
Errors reading or parsing /etc/freeradius/3.0/radiusd.conf

Looking at line 505 of 
/etc/freeradius/3.0/mods-config/sql/main/postgresql/queries.conf, it does seem 
to be missing a line-extending terminator '\' that is present on surrounding 
lines (the context is that this is in the middle of a ~15-line SQL query):

...
504:AcctUpdateTime = 
${event_timestamp}, \
505:AcctSessionTime = 
COALESCE(%{%{Acct-Session-Time}:-NULL},
506:
(${event_timestamp_epoch} - EXTRACT(EPOCH FROM(AcctStartTime, \
...

Adding the '\' in at the end of the line seems to fix it.

This is a fully stable Bullseye installation, built from the official ISOs 
released yesterday.

Bug#982459:

[Felix Lechner]

Hi,

On Sun, Aug 15, 2021 at 2:45 AM Håkan T Johansson  wrote:
>
> I believe that I have been hit by this bug too.

Thanks for the bug amendment! The 4.1 release happened nearly three
years ago. With bullseye released, I just uploaded the latest release
candidate 4.2~rc2-2 from upstream to Debian unstable. Feel free to try
that too. Thank you!

Kind regards
Felix Lechner

Bug#985957: usrmerge has 47.3MB of dependencies

[Marco d'Itri]

On Aug 15, Niko Tyni  wrote:

> > > I think it would be a fair request to ask for usrmerge's dependencies
> > > to be included there if we install usrmerge by default on upgrades to
> > > covert existing systems.  The dependencies could probably be dropped
> > > again for bookworm+1 (with perl-base having `Breaks: usrmerge (<< X)`
> > > where `X` is the version of usrmerge depending on perl instead of perl-
> > > base again).
> Just a note that this #985957 is also #987615 (cc'd) on the perl side.
> 
> Now that bookworm development is open I'll see what we can do there.
I see no reason to move the usrmerge dependencies to perl-base: usrmerge 
is supposed to be installed, run and then removed again.
If something is moved to perl-base then it will use space on every 
Debian system.
usrmerge being installed DOES NOT mean that the system has been 
converted to merged-/usr, so there is no reason at all to keep it around 
after it has been used.

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Bug#992217: picard: should install NEWS.md file

[Jonas Smedegaard]

Package: picard
Version: 2.6.3-2
Severity: minor

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Upstream source contains a file NEWS.md, useful to be accessible at runtime.

Please install NEWS.md with the binary package.

 - Jonas

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmEZmeUACgkQLHwxRsGg
ASHYGA/5AdhTnPwXemo9syBEQmKKDFP25qqRhqA3UP+8PDLyaKrvam5k+Rw2/GSb
yqQmv09snfScsUiWIjdSL2+yTGytVzYe+T1EyWcIUP4mLYNqoTy2qcUTDr1aX/sG
K6eAG2CjGQXO5d6O/q7eJOyI6EMjNSDT7JuLt4ng0RE/Kw+21PgG6IAg7TnyA362
Jm+BIYjcH7VLshnwIuqQAFtu6JxTd5LlyjNWSFDZO/fmT5eDxHrGpxAiLGwc8nUd
Jo3e7OnOWLP6bZpJlYoj11hgJBIMNoPT/zu2OZ0XTVVzW7QPsPdqRpLoU68Ylj6k
yfG9ppc20HvbDbrVGhuLQ0ErQkmwqp5MeU0SRE4xH4KkK2f8uSOvTLtoRPy7/oT2
OS/G+g5rUPF0wDXByw3xWlPvlEdtyhTC6XWxgCkTthJoCxN3ml3t6ncfBgHZSWAi
XFiSgk9w2mAUOi6JOGMt3vWV/3bdOhz513Xqxm+ZCHS15+x88YqhXY0bzoDLa714
4DsWOSMOETmtYpXKCkJXk7rRCEEjUgr1r+Od+UkrtPNDCmJNcQYdCA10o49jZl2/
MZi86NgJ7N4C96zCBFeJ0ZTBZNAguu9dDkzvi68THvseNF4AMu1R5kiuFLjfrjpf
4o96/tFANOLks05Bskjrvopy3yrPWOAz1fX5IEiE4IJk2atZpe0=
=Fp8q
-END PGP SIGNATURE-

Bug#992216: thunderbird: Version 91 available upstream and fixes security problems

[Demi Marie Obenour]

Package: thunderbird
Version: 78
Severity: grave
Tags: security
Justification: user security hole
X-Debbugs-Cc: demioben...@gmail.com, Debian Security Team 


Dear Maintainer,

Mozilla has released Thunderbird 91, which fixes several security
holes.  Please upgrade the Thunderbird package.

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

Kernel: Linux 5.4.136-1.fc25.qubes.x86_64 (SMP w/1 CPU thread)
Kernel taint flags: TAINT_OOT_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=C.UTF-8 (charmap=locale: Cannot set 
LC_MESSAGES to default locale: No such file or directory
locale: Cannot set LC_ALL to default locale: No such file or directory
UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages thunderbird depends on:
ii  debianutils  4.11.2
ii  fontconfig   2.13.1-4.2
ii  libatk1.0-0  2.36.0-2
pn  libbotan-2-17
ii  libbz2-1.0   1.0.8-4
ii  libc62.31-13
ii  libcairo-gobject21.16.0-5
ii  libcairo21.16.0-5
ii  libdbus-1-3  1.12.20-2
pn  libdbus-glib-1-2 
ii  libevent-2.1-7   2.1.12-stable-1
ii  libffi7  3.3-6
ii  libfontconfig1   2.13.1-4.2
ii  libfreetype6 2.10.4+dfsg-1
ii  libgcc-s110.2.1-6
ii  libgdk-pixbuf-2.0-0  2.42.2+dfsg-1
ii  libglib2.0-0 2.66.8-1
ii  libgtk-3-0   3.24.24-4
ii  libicu67 67.1-7
ii  libjson-c5   0.15-2
ii  libnspr4 2:4.29-1
ii  libpango-1.0-0   1.46.2-3
ii  libstdc++6   10.2.1-6
ii  libvpx6  1.9.0-1
ii  libx11-6 2:1.7.2-1
ii  libx11-xcb1  2:1.7.2-1
ii  libxcb-shm0  1.14-3
ii  libxcb1  1.14-3
ii  libxext6 2:1.3.3-1.1
ii  libxrender1  1:0.9.10-1
ii  psmisc   23.4-2
pn  x11-utils
ii  zlib1g   1:1.2.11.dfsg-2

Versions of packages thunderbird recommends:
pn  myspell-en-us | hunspell-dictionary | myspell-dictionary  

Versions of packages thunderbird suggests:
ii  apparmor  2.13.6-10
pn  fonts-lyx 
ii  libgssapi-krb5-2  1.18.3-6
pn  libgtk2.0-0   

Bug#992215: rsync: please consider re-adding --copy-devices patch

[Kevin Locke]

Package: rsync
Version: 3.2.0-1
Severity: normal
Control: found -1 3.2.3-4

Dear Maintainer,

In [af31473f] for rsync 3.2.0-1, copy-devices.diff was dropped with
the note that "--copy-devices is now --write-devices".  Unfortunately,
that is only partially true.  Although --write-devices allows writing
to device files, it does not allow copying from devices files as
--copy-devices did.  For example, I could create sparse device images
using:

rsync -S --copy-devices /dev/sdX1 /tmp/sdX1.raw

Replacing --copy-devices with --write-devices produces:

skipping non-regular file "sdX1"

Note that [copy-devices.diff] is still maintained in rsync-patches and
was updated to be compatible with --write-devices in [c9d55ab].

Thanks for considering,
Kevin

[af31473f]: 
https://salsa.debian.org/debian/rsync/-/commit/921ddfb35c2641843cc4f671560d9056ea6b5a05
[c9d55ab]: 
https://git.samba.org/?p=rsync-patches.git;a=commitdiff;h=c9d55ab688df0067fd37d5199650615c6d675074#patch11
[copy-devices.diff]: 
https://git.samba.org/?p=rsync-patches.git;a=blob;f=copy-devices.diff


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

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

Versions of packages rsync depends on:
ii  init-system-helpers  1.60
ii  libacl1  2.2.53-10
ii  libc62.31-13
ii  liblz4-1 1.9.3-2
ii  libpopt0 1.18-2
ii  libssl1.11.1.1k-1
ii  libxxhash0   0.8.0-2
ii  libzstd1 1.4.8+dfsg-2.1
ii  lsb-base 11.1.0
ii  zlib1g   1:1.2.11.dfsg-2

rsync recommends no packages.

Versions of packages rsync suggests:
ii  openssh-client  1:8.4p1-5
ii  openssh-server  1:8.4p1-5
ii  python3 3.9.2-3

-- no debconf information

Bug#992214: RFS: nemo-audio-tab/5.0.0-1 [ITP] -- View audio tag information from Nemo's properties tab

[Joshua Peisach]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

I am looking for a sponsor for my package "nemo-audio-tab":

 * Package name: nemo-audio-tab
   Version : 5.0.0-1
   Upstream Author : Clement Lefebvre 
 * URL : https://community.linuxmint.com/software/view/nemo-audio-
tab
 * License : GPL-3+
 * Vcs : https://salsa.debian.org/cinnamon-team/nemo-audio-tab
   Section : utils

It builds those binary packages:

  nemo-audio-tab - View audio tag information from Nemo's properties tab

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

  https://mentors.debian.net/package/nemo-audio-tab/

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

  dget -x https://mentors.debian.net/debian/pool/main/n/nemo-audio-tab/nemo-
audio-tab_5.0.0-1.dsc

Or, to view the code as a whole, visit:

  https://salsa.debian.org/cinnamon-team/nemo-audio-tab

Changes for the initial release:

 nemo-audio-tab (5.0.0-1) unstable; urgency=medium
 .
   * Initial release. (Closes: #971971)

Regards,
--
  Joshua Peisach

Bug#992213: release-notes: Release notes should mention lxc issues with cgroups change

[Mike Hommey]

Package: release-notes
Severity: important

The release notes has a section about the issues with openstack, but
there are also problems with lxc. I'm not sure what the proper
workaround is, but setting `lxc.mount.auto = cgroup:mixed:force` fixed
it for me.

Mike

Bug#992212: shellcheck: upstream changelog not installed

[Jonas Smedegaard]

Package: shellcheck
Version: 0.7.2-2
Severity: minor

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Upstream source contains a file CHANGELOG.md, which would be helpful to have 
available at runtime.

Please include that file with binary package.


 - Jonas

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmEZfQsACgkQLHwxRsGg
ASHm1w//WBZCtsg7RcWFE4GY+IhOURnUMm0JgpKndavMAFKha3OBz7OVB7UK+wfx
0l/nPl4qQsgyl5/Yz1nMSinvgth5S40AyLwwF8sdm2T+SmWTVSkkp25j3FX4y2dS
iXIRT7D1mBW7QuE0An2JECzm/JiQxmczA4jVqHW1MTAo/OitbBpFydEIAMFq2hJk
kqsq5uwUtQ/wIFYtgGGnMqwEzAc9hIR2lUBa6xPhdhtdq4DffO0JPusgp1p+9KtI
HP6xgqg2Zb4e6JRnDPwkNSBFgL6ExKmk6Xq3DuYVV2Gq6gQ1QHVEv5kLl7CqTqVs
WExg5bn/HW8vcXagSQcYnFNZeY6ftdLGpKZIdfgE8unQlFnQocl8BMFX2/GsFMp6
njobj6WlZIMpAQlgC5vUBK0mTikJlVZ9CFf0IKZac1rmoXrlESG3MPhDJTrWX18X
Jku+/yODcTO9RNdNp1nMfHLGRZslpKhTtxBjB4GzovIgDMj+jAid4af8XvQ7yQL0
pID7jqYyDpCejqAuvB5r+hzUW0gFGH+dBwV4gvTyLWJ5WPAe0DO6zcHqfs1W47Lg
ba2orO9QiTUqoexMCcqhNdVaaCQl6/FzK0w9JwrQsM2MHMj40mqJ+N7N5o4LZGxa
S1/nra8aOMJh43SVv2eZTilJwtqGGVtJ8hkY4oGfh4g1uckhQs4=
=xWVU
-END PGP SIGNATURE-

Bug#992211: RFP: axolotl -- Signal Private Messenger unofficial client

[Federico Ceratto]

Package: wnpp
Severity: wishlist

* Package name: axolotl
  Version : 1.0.1.1
  Upstream Author : Aaron "nanu-c"
* URL : https://github.com/nanu-c/axolotl
* License : GPLv3
  Programming Lang: Go, Vuejs
  Description : Signal Private Messenger unofficial client

Complete Signal client suitable for desktops and mobile usage.
Unlike the desktop Signal client, Axolotl is completely autonomous and
does not require you to have created an account with the official
Signal application.
In supports contact discovery, IM, video and audio attachments and more

Bug#992207: Freeradius postgresql mod broken in Bullseye

[Bernhard Schmidt]

Control: tags -1 + confirmed patch upstream

Hi,

> I just built a new Bullseye VM to replace my Buster freeradius VM.  Upon 
> trying to configure it for a postgres backend, 'freeradius -X' fails out with 
> the following:>
> ...
> including configuration file /etc/freeradius/3.0/mods-enabled/mschap
> including configuration file /etc/freeradius/3.0/mods-enabled/sql
> including configuration file 
> /etc/freeradius/3.0/mods-config/sql/main/postgresql/queries.conf
> /etc/freeradius/3.0/mods-config/sql/main/postgresql/queries.conf[505]: Parse 
> error: Unterminated string
> Errors reading or parsing /etc/freeradius/3.0/radiusd.conf
> 
> Looking at line 505 of 
> /etc/freeradius/3.0/mods-config/sql/main/postgresql/queries.conf, it does 
> seem to be missing a line-extending terminator '\' that is present on 
> surrounding lines (the context is that this is in the middle of a ~15-line 
> SQL query):
> 
> ...
> 504:AcctUpdateTime = 
> ${event_timestamp}, \
> 505:AcctSessionTime = 
> COALESCE(%{%{Acct-Session-Time}:-NULL},
> 506:
> (${event_timestamp_epoch} - EXTRACT(EPOCH FROM(AcctStartTime, \
> ...
> 
> Adding the '\' in at the end of the line seems to fix it.

Ack, this has already been fixed upstream at

https://github.com/FreeRADIUS/freeradius-server/commit/eef366956e2e4a689ab33a0d1f265eb15f749d8d

I will try to make a bullseye-pu upgrade before the next stable update.

Bernhard

Bug#992210: RM: davs2/experimental -- NVIU; not picked up by automatic NVIU removal

[Sebastian Ramacher]

Package: ftp.debian.org
Severity: normal
X-Debbugs-Cc: sramac...@debian.org

Same as #992209 but for davs2.

Cheers
-- 
Sebastian Ramacher


signature.asc
Description: PGP signature

Bug#992209: RM: xavs2/experimental -- NVIU; not picked up by automatic NVIU removals

[Sebastian Ramacher]

Package: ftp.debian.org
Severity: normal
X-Debbugs-Cc: sramac...@debian.org

For some reason xavs2 does not seem to be picked up by automatic NVIU
removal from experimental. There is a newer version in unstable, so
please remove it from experimental.

Cheers
-- 
Sebastian Ramacher


signature.asc
Description: PGP signature

Bug#992195: Remove reference to undocumented APT feature

[Laura Smith]

Package: release-notes
Severity: normal

Re: 5.1.2 "which takes advantage of the undocumented feature of APT that it 
supports regular expressions (inside /)."

Why are we encouraging people to use undocumented features ?

It surely just sets you up for a future fail when people try to use the trick 
but find the developers have changed it.

Its a dangerous game to play !

Bug#992194: Need to reflect Debian project preferences on repo keys

[Laura Smith]

Package: release-notes
Severity: normal

The project really needs to make its mind up which way it is going in terms of 
managing repo keys.

The bullseye release notes, e.g. 5.3.2. Deprecated components for bullseye make 
reference to "Keys should be managed by dropping files into 
/etc/apt/trusted.gpg.d"

But this seems to contravene current Debian policy as stated elsewhere, namely:

"The key MUST be downloaded over a secure mechanism like HTTPS to a location 
only writable by root, which SHOULD be /usr/share/keyrings. The key MUST NOT be 
placed in /etc/apt/trusted.gpg.d or loaded by apt-key add. A sources.list entry 
SHOULD have the signed-by option set. The signed-by entry MUST point to a file, 
and not a fingerprint."

Source:
1. https://wiki.debian.org/DebianRepository/UseThirdParty
2. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=861695
3. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=877012

Please don't confuse people by encouraging different methods in different docs !

Bug#971329: qtav: diff for NMU version 1.13.0+ds-3.1

[Sebastian Ramacher]

Control: tags 971329 + patch
Control: tags 971329 + pending

Dear maintainer,

I intend to upload ffmpeg without libavresample-dev to unstable soon. As
qtav already supports swreample and only requires its build dependencies
to be changed, I've prepared an NMU for qtav (versioned as
1.13.0+ds-3.1) and uploaded it to DELAYED/7. Please feel free to tell me
if I should delay it longer.

Cheers
-- 
Sebastian Ramacher
diff -Nru qtav-1.13.0+ds/debian/changelog qtav-1.13.0+ds/debian/changelog
--- qtav-1.13.0+ds/debian/changelog	2020-10-21 12:10:45.0 +0200
+++ qtav-1.13.0+ds/debian/changelog	2021-08-15 21:18:07.0 +0200
@@ -1,3 +1,11 @@
+qtav (1.13.0+ds-3.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * debian/control: Build-Depend on libswresample-dev instead of
+libavreample-dev (Closes: #971329)
+
+ -- Sebastian Ramacher   Sun, 15 Aug 2021 21:18:07 +0200
+
 qtav (1.13.0+ds-3) unstable; urgency=medium
 
   * Team upload.
diff -Nru qtav-1.13.0+ds/debian/control qtav-1.13.0+ds/debian/control
--- qtav-1.13.0+ds/debian/control	2020-10-21 12:10:45.0 +0200
+++ qtav-1.13.0+ds/debian/control	2021-08-08 22:40:24.0 +0200
@@ -11,11 +11,11 @@
libqt5x11extras5-dev,
libass-dev,
libavutil-dev,
-   libavresample-dev,
libavcodec-dev,
libavformat-dev,
libavdevice-dev,
libavfilter-dev,
+   libswresample-dev,
libswscale-dev,
libopenal-dev,
libpulse-dev,


signature.asc
Description: PGP signature

Bug#992206: bullseye-pu: package ruby-rqrcode-rails3/0.1.7-1.1

[Pirate Praveen]

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

This rc bug was detected very late in freeze so it could not get into 
bullseye.


[ Reason ]
This package was broken with ruby-rqrcode 1.0 update. See #992040

[ Impact ]
They will have an incompatible and broken package.

[ Tests ]
This was found when testing 2FA authentication in gitlab package and 
the fix was tested in gitlab and the 2FA feature was working in the 
fixed versions.


[ Risks ]
gitlab is its only reverse dependency which is not in bullseye.

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

[ Changes ]
API is adjusted to work with ruby-rqrcode shipped with bullseye.

[ Other info ]
The patch was taken from an upstream issue (though upstream is not very 
active)


diff -Nru ruby-rqrcode-rails3-0.1.7/debian/changelog ruby-rqrcode-rails3-0.1.7/debian/changelog
--- ruby-rqrcode-rails3-0.1.7/debian/changelog	2021-01-05 20:52:02.0 +0530
+++ ruby-rqrcode-rails3-0.1.7/debian/changelog	2021-08-16 00:40:15.0 +0530
@@ -1,3 +1,10 @@
+ruby-rqrcode-rails3 (0.1.7-1.1+deb11u1) bullseye; urgency=medium
+
+  * Fix for ruby-rqrcode 1.0 compatibility (Thanks to Florence Foo) 
+(Closes: #992040)
+
+ -- Pirate Praveen   Mon, 16 Aug 2021 00:40:15 +0530
+
 ruby-rqrcode-rails3 (0.1.7-1.1) unstable; urgency=medium
 
   * Non maintainer upload by the Reproducible Builds team.
diff -Nru ruby-rqrcode-rails3-0.1.7/debian/patches/rqrcode-1.x-compat.patch ruby-rqrcode-rails3-0.1.7/debian/patches/rqrcode-1.x-compat.patch
--- ruby-rqrcode-rails3-0.1.7/debian/patches/rqrcode-1.x-compat.patch	1970-01-01 05:30:00.0 +0530
+++ ruby-rqrcode-rails3-0.1.7/debian/patches/rqrcode-1.x-compat.patch	2021-08-16 00:20:04.0 +0530
@@ -0,0 +1,36 @@
+https://github.com/samvincent/rqrcode-rails3/compare/master...pandamouse:rqrcode-core-0.1.1.patch
+
+From bc86ea646010ab0e6d089d80f1533b7836315776 Mon Sep 17 00:00:00 2001
+From: Florence Foo 
+Date: Thu, 2 Jan 2020 17:07:55 +1100
+Subject: [PATCH 1/2] RQRCode.render_qrcode raises NoMethodError #21
+
+- use RQRCodeCore
+  - is_dark? -> dark?
+---
+ lib/rqrcode-rails3.rb   | 2 +-
+ lib/rqrcode-rails3/renderers/svg.rb | 2 +-
+ 2 files changed, 2 insertions(+), 2 deletions(-)
+
+--- a/lib/rqrcode-rails3.rb
 b/lib/rqrcode-rails3.rb
+@@ -15,7 +15,7 @@
+ size   = options[:size]  || RQRCode.minimum_qr_size_from_string(string)
+ level  = options[:level] || :h
+ 
+-qrcode = RQRCode::QRCode.new(string, :size => size, :level => level)
++qrcode = RQRCodeCore::QRCode.new(string, :size => size, :level => level)
+ svg= RQRCode::Renderers::SVG::render(qrcode, options)
+ 
+ if format && format == :svg
+--- a/lib/rqrcode-rails3/renderers/svg.rb
 b/lib/rqrcode-rails3/renderers/svg.rb
+@@ -28,7 +28,7 @@
+   y = c*unit + offset
+   x = r*unit + offset
+ 
+-  next unless qrcode.is_dark(c, r)
++  next unless qrcode.checked?(c, r)
+   tmp << %{}
+ end 
+ result << tmp.join
diff -Nru ruby-rqrcode-rails3-0.1.7/debian/patches/series ruby-rqrcode-rails3-0.1.7/debian/patches/series
--- ruby-rqrcode-rails3-0.1.7/debian/patches/series	1970-01-01 05:30:00.0 +0530
+++ ruby-rqrcode-rails3-0.1.7/debian/patches/series	2021-08-16 00:20:04.0 +0530
@@ -0,0 +1 @@
+rqrcode-1.x-compat.patch

Bug#992187: Report invalid

[ValdikSS]

Sorry, this bug report is invalid. I didn't know that this is an 
intended debian-installer behavior and is present on all versions.

Bug#992205: ppp: pon fails if demand enabled with ipv6

[Luigi Baldoni]

Package: ppp
Version: 2.4.9-1+1
Severity: normal
Tags: ipv6 upstream
X-Debbugs-Cc: aloi...@gmx.com

Dear Maintainer,
after upgrading to bullseye, pon dsl-provider started failing with
the error:
'/usr/sbin/pppd: local/remote LL address required for demand-dialling'
Removing 'demand' from the peer definition or adding 'noipv6' in
/etc/ppp/options fix the problem, at least on ipv4.

Adding the commits mentioned in https://github.com/ppp-project/ppp/pull/238
removes the error. I couldn't test if things actually work on ipv6.

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

Kernel: Linux 5.10.0-8-amd64 (SMP w/2 CPU threads)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages ppp depends on:
ii  libc6   2.31-13
ii  libcrypt1   1:4.4.18-4
ii  libpam-modules  1.4.0-9
ii  libpam-runtime  1.4.0-9
ii  libpam0g1.4.0-9
ii  libpcap0.8  1.10.0-2
ii  libssl1.1   1.1.1k-1
ii  libsystemd0 247.3-6
ii  procps  2:3.3.17-5

ppp recommends no packages.

ppp suggests no packages.

-- Configuration Files:
/etc/ppp/ip-down.d/usepeerdns [Errno 2] No such file or directory: 
'/etc/ppp/ip-down.d/usepeerdns'
/etc/ppp/ip-up.d/usepeerdns [Errno 2] No such file or directory: 
'/etc/ppp/ip-up.d/usepeerdns'
/etc/ppp/ipv6-down [Errno 2] No such file or directory: '/etc/ppp/ipv6-down'
/etc/ppp/ipv6-up [Errno 2] No such file or directory: '/etc/ppp/ipv6-up'
/etc/ppp/options changed:
asyncmap 0
auth
crtscts
lock
hide-password
modem
noipv6
lcp-echo-interval 30
lcp-echo-failure 4
noipx
persist


-- no debconf information

Bug#663255: Bonjour

[Nina Grisot]

Une tentative de connexion a été effectuée sur votre boîte mail : Voici les 
informations dont nous disposons :Lieu : Moscou
IP: 168.195.206.93:3389
Application : Chrome 76.0.3809 (Windows 10)
Si ce n'était pas vous, veuillez vous connecter pour obtenir des instructions 
sur la sécurisation de votre compte. Si vous ne validez pas votre compte dans 
les 24 heures, vous ne pourrez pas envoyer ou recevoir de nouveau courrier tant 
que vous n'aurez pas revalidé votre boîte aux lettres, avant de conserver votre 
INBOX CLIQUEZ ICI pour vérifier.
Nous nous soucions de la sécurité de votre compte.Vérification du service 
d'assistance informatique
Copyright ©2020 Équipe technique, Inc.

Bug#992202: tmux doesn't read tmux.conf upon login

[Romain Francoise]

Hi,

On Sun, Aug 15, 2021 at 7:54 PM Allan Wind  wrote:
> I just upgraded to bullseye and on subsequent login tmux doesn't
> appear to read tmux.conf.  This worked fine in buster.

Can you check your display manager logs (or equivalent) for an error
message that would indicate what's happening?

> The work-around is to exit all 3 instances before a subsequent
> start of tmux will read my tmux.conf file and behave as expected.

Not sure I understand what you mean here...

> I ran strace -ff tmux and I did not see an access or open of
> the tmux.conf file.

If the server is already running, that would be expected.

Bug#992204: /usr/bin/yubikey-luks-open: Debian 11: Can't open device when passphrase is empty

[Asharas]

Package: yubikey-luks
Version: 0.5.1+29.g5df2b95-6
Severity: normal
File: /usr/bin/yubikey-luks-open

Hi,

After upgrading to Debian 11 both the keyscript or yubikey-luks-open fail to 
open a luks device.

Use of -v shows that the script gets no response from the key when sending an 
empty challenge (Yubikey response is empty).
Using ykchalresp via CLI work correctly.


Subsidiary info:
Both "CONCATENATE" and "HASH" are set to 0 in /etc/ykluks.cfg

Feel free to ask if more information is needed.

Regards,

Ash


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

Kernel: Linux 5.10.0-8-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 yubikey-luks depends on:
ii  cryptsetup-run   2:2.3.5-1
ii  initramfs-tools  0.140
ii  yubikey-personalization  1.20.0-3

Versions of packages yubikey-luks recommends:
ii  cryptsetup-initramfs  2:2.3.5-1
ii  expect5.45.4-2+b1

yubikey-luks suggests no packages.

-- no debconf information

Bug#910504: Long delay until kernel logs “random: crng init done” and allows eg. gdm3 to start

[Grzegorz Szymaszek]

Dear Roger,

I’ve tested this again on the same machine that caused this bug report.
Debian bullseye, upgraded from buster just today; neither rng-tools nor
haveged are installed. GDM (or, in general, any text console or
graphical display manager) starts immediately when broadcom-sta-dkms is
installed, as well as when it is not. From this point of view, the bug
is fixed.

Thanks!

-- 
Grzegorz Szymaszek


signature.asc
Description: PGP signature

Bug#971332: alsa-plugins: diff for NMU version 1.2.2-2.1

[Sebastian Ramacher]

Control: tags 971332 + patch
Control: tags 971332 + pending

Dear maintainer,

as I intend to upload ffmpeg without libavresample-dev soon, I've
prepared an NMU for alsa-plugins (versioned as 1.2.2-2.1) and uploaded
it to DELAYED/7. Please feel free to tell me if I should delay it
longer.

Cheers
-- 
Sebastian Ramacher
diff -Nru alsa-plugins-1.2.2/debian/changelog alsa-plugins-1.2.2/debian/changelog
--- alsa-plugins-1.2.2/debian/changelog	2020-08-20 21:37:42.0 +0200
+++ alsa-plugins-1.2.2/debian/changelog	2021-08-15 20:18:32.0 +0200
@@ -1,3 +1,11 @@
+alsa-plugins (1.2.2-2.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Apply upstream switch to support libswresample in favor of libavreample
+(Closes: #971332)
+
+ -- Sebastian Ramacher   Sun, 15 Aug 2021 20:18:32 +0200
+
 alsa-plugins (1.2.2-2) unstable; urgency=medium
 
   [ Sebastien Bacher ]
diff -Nru alsa-plugins-1.2.2/debian/control alsa-plugins-1.2.2/debian/control
--- alsa-plugins-1.2.2/debian/control	2020-02-29 17:15:35.0 +0100
+++ alsa-plugins-1.2.2/debian/control	2021-08-15 20:18:32.0 +0200
@@ -8,13 +8,13 @@
 Build-Depends: debhelper-compat (= 12),
libasound2-dev (>= 1.1.8),
libavcodec-dev,
-   libavresample-dev,
libavutil-dev,
libdbus-1-dev (>= 1.4.12-3~),
libjack-dev (>= 1:0.121.0+svn4538-2~),
libpulse-dev (>= 0.99.1-1~),
libsamplerate0-dev | libsamplerate-dev,
-   libspeexdsp-dev
+   libspeexdsp-dev,
+   libswresample-dev
 Standards-Version: 4.5.0
 Homepage: https://www.alsa-project.org/
 Vcs-Git: https://salsa.debian.org/alsa-team/alsa-plugins.git
diff -Nru alsa-plugins-1.2.2/debian/patches/rate-lab-convert-tolibswresample.patch alsa-plugins-1.2.2/debian/patches/rate-lab-convert-tolibswresample.patch
--- alsa-plugins-1.2.2/debian/patches/rate-lab-convert-tolibswresample.patch	1970-01-01 01:00:00.0 +0100
+++ alsa-plugins-1.2.2/debian/patches/rate-lab-convert-tolibswresample.patch	2021-08-08 22:33:02.0 +0200
@@ -0,0 +1,201 @@
+From: Takashi Iwai 
+Date: Wed, 16 Jun 2021 08:21:35 + (+0200)
+Subject: rate-lav: Convert to libswresample
+X-Git-Url: https://git.alsa-project.org/?p=alsa-plugins.git;a=commitdiff_plain;h=8a3c0d795fbef5700c8cedcc82c6a337170c76ee
+
+rate-lav: Convert to libswresample
+
+The libavresample has been deprecated.  Convert to the new API for
+libswresample.
+
+The phase shift and cutoff seem to be either redundant or not-working
+properly, so those are dropped.
+
+Signed-off-by: Takashi Iwai 
+Signed-off-by: Jaroslav Kysela 
+---
+
+diff --git a/configure.ac b/configure.ac
+index d5fe529..860daa9 100644
+--- a/configure.ac
 b/configure.ac
+@@ -93,7 +93,7 @@ AC_ARG_ENABLE([libav],
+   AS_HELP_STRING([--disable-libav], [Do not build plugins depending on libav/ffmpeg (a52,lavrate...)]))
+ 
+ if test "x$enable_libav" != "xno"; then
+-  PKG_CHECK_MODULES(LIBAV, [libavcodec libavutil libavresample], [HAVE_LIBAV=yes], [HAVE_LIBAV=no])
++  PKG_CHECK_MODULES(LIBAV, [libavcodec libavutil libswresample], [HAVE_LIBAV=yes], [HAVE_LIBAV=no])
+ fi
+ 
+ if test "x$HAVE_LIBAV" = "xno"; then
+diff --git a/doc/lavrate.txt b/doc/lavrate.txt
+index 6575183..fa6bbb0 100644
+--- a/doc/lavrate.txt
 b/doc/lavrate.txt
+@@ -2,7 +2,7 @@ Rate Converter Plugin Using libavresample
+ =0
+ 
+ The plugin in rate-lavr subdirectory is an external rate converter using
+-libavresample library. You can use this rate converter plugin by defining a
++libswresample library. You can use this rate converter plugin by defining a
+ rate PCM with "converter" parameter, such as:
+ 
+ 	pcm.my_rate {
+@@ -16,7 +16,7 @@ The plug plugin has also a similar field, "rate_converter".
+ Or, more easily, define a global variable "defaults.pcm.rate_converter",
+ which is used as the default converter type by plug and rate plugins:
+ 
+-	defaults.pcm.rate_converter "lavcrate"
++	defaults.pcm.rate_converter "lavrate"
+ 
+ Write the above in your ~/.asoundrc or /etc/asound.conf.
+ 
+diff --git a/rate-lav/rate_lavrate.c b/rate-lav/rate_lavrate.c
+index 2b992c5..e9c6740 100644
+--- a/rate-lav/rate_lavrate.c
 b/rate-lav/rate_lavrate.c
+@@ -1,5 +1,5 @@
+ /*
+- * Rate converter plugin using libavresample
++ * Rate converter plugin using libswresample
+  * Copyright (c) 2014 by Anton Khirnov
+  *
+  * This library is free software; you can redistribute it and/or
+@@ -17,7 +17,7 @@
+ #include 
+ #include 
+ 
+-#include 
++#include 
+ #include 
+ #include 
+ #include 
+@@ -25,11 +25,9 @@
+ 
+ 
+ static unsigned int filter_size = 16;
+-static unsigned int phase_shift = 10; /* auto-adjusts */
+-static double cutoff = 0; /* auto-adjusts */
+ 
+ struct rate_src {
+-	AVAudioResampleContext *avr;
++	SwrContext *avr;
+ 
+ 	unsigned int in_rate;
+ 	unsigned int out_rate;
+@@ -51,51 +49,38 @@ static snd_pcm_uframes_t output_

Bug#992203: buster-pu: package wims/2:4.17b+svn13454~dfsg2-1

[Adam D. Barratt]

Control: retitle -1 bullseye-pu: package wims/2:4.17b+svn13454~dfsg2-1
Control: tags -1 + moreinfo

On Sun, 2021-08-15 at 20:01 +0200, Georges Khaznadar wrote:
> The package wims got a bugreport (#992088, "contains two files with a
> non-free
> "disparaging to Sun" license") with severity "serious" on
> 11 August; I uploaded the fix on 13 August, but it was too late
> to take it in account for the unblock request.

So you mean bullseye-pu; retitling.

> [ Checklist ]
>   [x] *all* changes are documented in the d/changelog
>   [x] I reviewed all changes and I approve them
>   [x] attach debdiff against the package in (old)stable
>   [x] the issue is verified as fixed in unstable
> 
> [ Changes ]
> The directory containing the two non-free files was removed from the
> source
> package, debian patches and the Makefile were adjusted accordingly

A bunch of other stuff was also removed (and in one case - .gitignore -
added), as your debdiff shows:

 .gitignore|2 
 debian/not-installed  |1 
 wims/public_html/scripts/authors/jm.evers/js/geogebra2wims.js |   66 
 wims/src/Misc/chemeq/debian/README.debian |   10 
 wims/src/Misc/chemeq/debian/changelog |  245 ---
 wims/src/Misc/chemeq/debian/chlg  |   27 
 wims/src/Misc/chemeq/debian/compat|1 
 wims/src/Misc/chemeq/debian/control   |   21 
 wims/src/Misc/chemeq/debian/copyright |   20 
 wims/src/Misc/chemeq/debian/docs  |2 
 wims/src/Misc/chemeq/debian/rules |   92 -
 wims/src/Misc/chemeq/debian/semantic.cache|   15 
 wims/src/Misc/units-filter/debian/changelog   |  325 
 wims/src/Misc/units-filter/debian/compat  |1 
 wims/src/Misc/units-filter/debian/control |   30 
 wims/src/Misc/units-filter/debian/copyright   |   18 
 wims/src/Misc/units-filter/debian/docs|1 
 wims/src/Misc/units-filter/debian/rules   |   15 
 wims/src/Misc/units-filter/debian/source/format   |1 

What's going on there?

Additionally, the debdiff you've attached is for the upload to
unstable, not an upload to stable (which would either be
1:4.17b+svn13454~dfsg1-6+deb11u1 or 1:4.21f~dfsg1-2~deb11u1, depending
on whether it incorporates or replaces the stanza for the unstable
upload).

Regards,

Adam

Bug#971393: [FYI] New mbedtls LTS version upcoming in 2021 (likely 2.28)

[Dennis Filder]

X-Debbugs-CC: ant...@friki.cat, gs-debian@gluelogic.com

In [0,1] it was announced that 2021 will see a new LTS release (2.28)
for mbedtls:

Dave Rodgman <...> wrote on Thu Jul 29 13:05:10 UTC 2021:

> We expect to release an LTS later this year. It’s likely to be 2.27,
> and very likely will be supported for the usual LTS period of 3
> years.
>
> So if you are considering updating to a new LTS, you could use 2.26
> for prototyping in the short term until the LTS becomes
> available. The upcoming LTS will be API-compatible with 2.26.

Gilles Peskine <...> wrote on Thu Jul 29 13:24:58 UTC 2021:

> Off-by-one error! The current 2.x release is 2.27.0. Most
> development work is happening on 3.x but there will be at least one
> more 2.x release: 2.28.0. The last 2.x release will become an LTS.

Regards,
Dennis Filder.

0: https://lists.trustedfirmware.org/pipermail/mbed-tls/2021-July/000422.html
1: https://lists.trustedfirmware.org/pipermail/mbed-tls/2021-July/000423.html

Bug#992203: buster-pu: package wims/2:4.17b+svn13454~dfsg2-1

[Georges Khaznadar]

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

[ Reason ]
The package wims got a bugreport (#992088, "contains two files with a non-free
"disparaging to Sun" license") with severity "serious" on
11 August; I uploaded the fix on 13 August, but it was too late
to take it in account for the unblock request.

[ Impact ]
The popcon score for wims is low, but this package is used only by sysadmins.
Typically, when a sysadmin runs wims for an education group, it can reach
hundreds of users online.
.
Unlike the upstream wims distribution, the debian package can provide a
featureful server in minutes, as the only command is to type "apt install
wims". So, the Debian package (and the same in Ubuntu) are a good introduction
to this free software.

[ Tests ]
I tested manually the build and the installation of the new package.

[ Risks ]
Wims is a leaf package, so it cannot harm other parts of the distribution.

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

[ Changes ]
The directory containing the two non-free files was removed from the source
package, debian patches and the Makefile were adjusted accordingly

[ Other info ]
Thank you in advance for the update
diff -Nru wims-4.17b+svn13454~dfsg1/debian/changelog 
wims-4.17b+svn13454~dfsg2/debian/changelog
--- wims-4.17b+svn13454~dfsg1/debian/changelog  2021-01-02 16:54:11.0 
+0100
+++ wims-4.17b+svn13454~dfsg2/debian/changelog  2021-08-13 13:28:13.0 
+0200
@@ -1,3 +1,14 @@
+wims (1:4.17b+svn13454~dfsg2-1) unstable; urgency=medium
+
+  * created a Git branch debian/bugfix-992088
+  * made a new orig tarball without files
+wims/src/Misc/applets/Lattice/src/LatticeViewer.java and
+wims/src/Misc/applets/Lattice/src/Matrix3D.java
+(the subdirectory wims/src/Misc/applets/Lattice was removed)
+  * updated the debian pactch modifying java builds
+
+ -- Georges Khaznadar   Fri, 13 Aug 2021 13:28:13 +0200
+
 wims (1:4.17b+svn13454~dfsg1-6) unstable; urgency=medium
 
   * created the line "usr/share/man/man1/flydraw.1.gz" in
diff -Nru wims-4.17b+svn13454~dfsg1/debian/not-installed 
wims-4.17b+svn13454~dfsg2/debian/not-installed
--- wims-4.17b+svn13454~dfsg1/debian/not-installed  2021-01-02 
16:50:29.0 +0100
+++ wims-4.17b+svn13454~dfsg2/debian/not-installed  1970-01-01 
01:00:00.0 +0100
@@ -1 +0,0 @@
-usr/share/man/man1/flydraw.1.gz
diff -Nru wims-4.17b+svn13454~dfsg1/debian/patches/java.patch 
wims-4.17b+svn13454~dfsg2/debian/patches/java.patch
--- wims-4.17b+svn13454~dfsg1/debian/patches/java.patch 2020-04-19 
16:44:31.0 +0200
+++ wims-4.17b+svn13454~dfsg2/debian/patches/java.patch 2021-08-13 
13:28:13.0 +0200
@@ -277,19 +277,6 @@



-Index: wims/wims/src/Misc/applets/Lattice/build.xml
-===
 wims.orig/wims/src/Misc/applets/Lattice/build.xml
-+++ wims/wims/src/Misc/applets/Lattice/build.xml
-@@ -19,7 +19,7 @@
-   
-   
-   
--  
-+  
-   
-   
-   
 Index: wims/wims/src/Misc/applets/ThreeD/build.xml
 ===
 --- wims.orig/wims/src/Misc/applets/ThreeD/build.xml
diff -Nru wims-4.17b+svn13454~dfsg1/.gitignore 
wims-4.17b+svn13454~dfsg2/.gitignore
--- wims-4.17b+svn13454~dfsg1/.gitignore1970-01-01 01:00:00.0 
+0100
+++ wims-4.17b+svn13454~dfsg2/.gitignore2021-08-13 13:20:53.0 
+0200
@@ -0,0 +1,2 @@
+*~
+.pc/
diff -Nru 
wims-4.17b+svn13454~dfsg1/wims/public_html/scripts/authors/jm.evers/js/geogebra2wims.js
 
wims-4.17b+svn13454~dfsg2/wims/public_html/scripts/authors/jm.evers/js/geogebra2wims.js
--- 
wims-4.17b+svn13454~dfsg1/wims/public_html/scripts/authors/jm.evers/js/geogebra2wims.js
 2013-06-16 15:44:40.0 +0200
+++ 
wims-4.17b+svn13454~dfsg2/wims/public_html/scripts/authors/jm.evers/js/geogebra2wims.js
 1970-01-01 01:00:00.0 +0100
@@ -1,66 +0,0 @@
-/* 
-14/6/2013
-Changed to geogebra3 : OpenJDK was not able to export the java array 
getAllObjectNames()
-(as was already a problem for internet explorer version 6,7,8?) 
-Resulting in lockups of the browser and OpenJDK java virtual machine.
-getAllObjectNames() function is depreciated since geogebra > 2.7 (btw: Oracle 
/ Sun virtualmachine  & plugin were/are ok ! )
-
-getAllObjectNames() is replaced by a combination of
-int getObjectNumber() -> Returns the total number of objects in the 
construction.
-String getObjectName(int i) --> returns the construction name of the i-th 
object
-
-Added 'triangle','quadrilateral' 'etc' als alternatives for 'polygon' (p)
-Now this script recognizes : 
-list_of_things=['text','point','line','segment','circle','function','polygon','conic','ellipse',

Bug#989777: Re: Severity: High / Debian 10 & 11 with Kernel 5.10.x-amd64 => Intel AX210 Wifi & Bluetooth not work

[pham...@bluewin.ch]

Hello,
Debian 11 Bullseye has been released, unfortunately it does not include a patch 
for the Intel AX210 Wifi & Bluetooth network adapter.
Unless you have a functional solution, I hope the Bullseye Backports directory 
will be created soon and propose the 5.13 kernel...
https://packages.debian.org/fr/linux-image-amd64
Regards.
Philippe

Bug#992202: tmux doesn't read tmux.conf upon login

[Allan Wind]

Package: tmux
Version: 3.1c-1
Severity: normal

Dear Maintainer,

I just upgraded to bullseye and on subsequent login tmux doesn't 
appear to read tmux.conf.  This worked fine in buster.  I start 3 
instances via i3:

exec i3-msg "workspace 1; exec x-www-browser; exec x-terminal-emulator -e tmux"
exec i3-msg "workspace 2; exec x-terminal-emulator -e tmux; exec pidgin"
exec i3-msg "workspace 3; exec x-terminal-emulator -e tmux new mutt"

The 3 instances show up as `tmux ls` so it is running, and I can 
use the default C-b prefix instead (but my customized C-a does not 
work).

The work-around is to exit all 3 instances before a subsequent 
start of tmux will read my tmux.conf file and behave as expected.
(I moved ~/.tmux.conf to .config/tmux/.tmux.conf but neither 
location matters for the initial start-up).

I ran strace -ff tmux and I did not see an access or open of 
the tmux.conf file.

Please let me know what data I can provide to help.


/Allan

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

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

Versions of packages tmux depends on:
ii  libc6   2.31-13
ii  libevent-2.1-7  2.1.12-stable-1
ii  libtinfo6   6.2+20201114-2
ii  libutempter01.2.1-2

tmux recommends no packages.

tmux suggests no packages.

-- no debconf information

-- 
Allan Wind
Yaxto - Runs Your Business

Bug#987615: Bug#985957: usrmerge has 47.3MB of dependencies

[Niko Tyni]

On Tue, Apr 06, 2021 at 02:17:00PM +0100, Dimitri John Ledkov wrote:
> On Tue, 6 Apr 2021 at 14:04, Ansgar  wrote:
> >
> > On Fri, 26 Mar 2021 22:12:33 + Dimitri John Ledkov wrote:
> > > I don't know what is the correct process to follow here. For example,
> > > could the 5.32 things be promoted from modules to perl-base?
> >
> > What gets included in the (essential) perl-base package is decided by
> > Debian.
> >
> > I think it would be a fair request to ask for usrmerge's dependencies
> > to be included there if we install usrmerge by default on upgrades to
> > covert existing systems.  The dependencies could probably be dropped
> > again for bookworm+1 (with perl-base having `Breaks: usrmerge (<< X)`
> > where `X` is the version of usrmerge depending on perl instead of perl-
> > base again).

Just a note that this #985957 is also #987615 (cc'd) on the perl side.

Now that bookworm development is open I'll see what we can do there.
-- 
Niko

Bug#992201: nmu: libtfbs-perl_0.7.1-3

[Bas Couwenberg]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: binnmu
X-Debbugs-Cc: debian-med-packag...@lists.alioth.debian.org, 
pkg-perl-maintain...@lists.alioth.debian.org

Please rebuild libtfbs-perl with the new pdl in unstable to pick up the 
pdlapi-14 dependency.

nmu libtfbs-perl_0.7.1-3 . ANY . unstable . -m "Rebuild with pdl (>= 1:2.054)"

Kind Regards,

Bas

Bug#992200: perl: regen-configure orig tarball file exclusions

[Niko Tyni]

Source: perl
Version: 5.32.1-5

We're not including the metaconfig (= regen-configure) original tarball
in a consistent way.

We have uscan(1) machinery in debian/watch and debian/copyright
to filter out bin/ and repack to .xz, but it looks like we're not
using that. The filtering was added pretty early in

   commit a42e63561fdfa1ed091cabcfe2b176d1bcac33ff
   Author: Niko Tyni 
   Date:   Sat Oct 14 16:06:17 2017 +0300
   
   Add machinery for generating the regen-configure component tarball
   
   We filter out bin/* from the upstream repo with Files-Excluded because
   they are generated files from dist sources.  The aim is to use the
   Debian packaged dist binaries (mainly metaconfig) together with
   the unit probes that were taken from an earlier dist version
   (possibly 3.5.20).
   
Later I added the .xz repacking with

   commit 6f5580f38188e6b0c9b12c110058c2db758183c3
   Author: Niko Tyni 
   Date:   Thu May 17 21:14:30 2018 +0300
   
   Use xz compression for component tarball
   
   This makes the tarball reproducible
 
AFAICS the machinery was used for the 5.28 series, but all tarballs
after that were imported as .gz without filtering/repacking.

We need to decide what to do going forward.

Other things being equal, using the pristine .gz tarball from Github would
seem preferrable to me, assuming Github serves it in a reproducible way
(which it seems to do in my quick tests.)

The argument about bin/* being generated files from dist sources is still
true. OTOH looking at src:dist the sources seem to be just small shell
extraction wrappers around the scripts. FWIW if this is a DFSG violation,
it's present in bullseye too (but not buster).

Another reason for the filtering was to make sure we use the separately
packaged dist binaries rather than the ones in the tarball. Clearly
things have worked fine without this safeguard. If it still feels
necessary I suppose we could replace it with some mv(1) dance in the
update-configure-stamp target.

Using .gz tarballs for regen-configure and .xz for Perl itself leads
into some trouble around #898026, but we seem to have managed with
the workaround documented in README.source.

I'm somewhat at loss. While I'd like to drop the repacking, it seems
that keeping it is a safer course to make sure we ship things with their
source.

If we keep the repacking, we should at least add a sanity check to make
sure we don't accidentally import pristine tarballs anymore.

Thoughts?
-- 
Niko

Bug#992199: perl: bumping Breaks for small patches doesn't work with versioned Provides

[Niko Tyni]

Source: perl
Version: 5.32.1-5

While fixing https://security-tracker.debian.org/tracker/CVE-2021-36770 in
Encode, we noticed that we could not bump the Breaks in libperl5.32 the
way we expected to forbid a combination of a patched Perl core package
and an unpatched separate libencode-perl package. (The problem about
this combination is that the separate package has precedence on @INC,
so it hides the fixed version.)

Specifically, as perl Provides: libencode-perl (= 3.06) we couldn't make
libperl5.32 Break libencode-perl (<< 3.08-1+deb11u1) as that would have
made perl uninstallable. Bumping the Provides to 3.06-1+deb11u1 would
not help, and bumping them past 3.08 would be lying.  The best I came
up with would be to add an epoch, and that seemed too intrusive.

In the context of security updates, it does not seem surprising that a
partial upgrade can leave the system vulnerable. So we decided to live
with this.

I'm filing this mostly to document the general issue. I'm not sure if
there's a solution other than the epoch one, but maybe somebody else
finds one. If not, we can probably live with it in the future too.

The last time we needed this feature was in 5.26.1-4, before we adopted
versioned Provides.
-- 
Niko

Bug#992198: lutris: should recommend (or depend) on wine32

[Wolfgang Weisselberg]

Package: lutris
Version: 0.5.8.4-1
Severity: normal

Dear Maintainer,

lutris keeps putting 
| it looks like wine32 is missing, you should install it.
| as root, please execute "apt-get install wine32"
into the window it was started from.

Would it make sense to recommend wine32?


$ dpkg -l \*wine\* | egrep '^ii'
ii  fonts-wine   5.0.3-3all  Windows API 
implementation - fonts
ii  libkwineffects12a4:5.20.5-1 amd64KDE window manager 
effects library
ii  libwine:amd645.0.3-3amd64Windows API 
implementation - library
ii  libwine-dev:amd645.0.3-3amd64Windows API 
implementation - development files
ii  libwine-development:amd646.0+repack-1   amd64Windows API 
implementation - library
ii  q4wine   1.3.12-1   amd64Qt GUI for WINE
ii  wine 5.0.3-3all  Windows API 
implementation - standard suite
ii  wine-binfmt  5.0.3-3all  Register Wine as 
the interpreter for Windows executables
ii  wine-development 6.0+repack-1   all  Windows API 
implementation - standard suite
ii  wine64   5.0.3-3amd64Windows API 
implementation - 64-bit binary loader
ii  wine64-development   6.0+repack-1   amd64Windows API 
implementation - 64-bit binary loader
ii  wine64-tools 5.0.3-3amd64Windows API 
implementation - 64-bit developer tools
ii  winetricks   0.0+20210206-2 all  simple tool to 
work around common problems in Wine
$




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

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

Versions of packages lutris depends on:
ii  cabextract   1.9-3
ii  curl 7.74.0-1.3+b1
ii  fluid-soundfont-gs   3.1-5.2
ii  gir1.2-gnomedesktop-3.0  3.38.5-3
ii  gir1.2-gtk-3.0   3.24.24-4
ii  gir1.2-notify-0.70.7.9-3
ii  gir1.2-webkit2-4.0   2.32.3-1
ii  mesa-utils   8.4.0-1+b1
ii  p7zip16.02+dfsg-8
ii  psmisc   23.4-2
ii  python3  3.9.2-3
ii  python3-dbus 1.2.16-5
ii  python3-distro   1.5.0-1
ii  python3-gi   3.38.0-2
ii  python3-lxml 4.6.3+dfsg-0.1
ii  python3-magic2:0.4.20-3
ii  python3-pil  8.1.2+dfsg-0.3
ii  python3-requests 2.25.1+dfsg-2
ii  python3-setproctitle 1.2.1-1+b1
ii  python3-yaml 5.3.1-5
ii  unzip6.0-26
ii  x11-xserver-utils7.7+8

Versions of packages lutris recommends:
ii  gvfs-backends1.46.2-1
ii  libwine-development  6.0+repack-1
ii  python3-evdev1.4.0+dfsg-1+b1
ii  winetricks   0.0+20210206-2

Versions of packages lutris suggests:
pn  gamemode  

-- no debconf information

Bug#992197: gita: man page lists all example commands on a single line

[Jonas Smedegaard]

Package: gita
Version: 0.15.2-2
Severity: minor

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

The man page seems to loose newlines: Both DESCRIPTION and EXAMPLES sections 
lists on a single line what seemingly was intended as multiple lines:

1. display the status of multiple repos side by side 2. delegate git 
commands/aliases from any working directory

and

gita ls gita fetch gita stat myrepo2 gita super myrepo1 commit -am 'add some 
cool feature'


Kind regards,

 - Jonas

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmEZRPcACgkQLHwxRsGg
ASHiTg/9E1/tkFRSp01Lnfqood1ETfTyAkXc9rUsk7F3pFdK0If4LqrIK3B8Ye97
HjlQI4l9if6CYqV3caVn2/QM9QHMBesLS01kQnMnBfA8QvoPLHZwJxRcumwBLDXH
jIMvHAYDhdTc/FdrVGVHEW75R+srU6XfqamNHDyKzODnydOXKf1CkKp17kmFrdfc
u22Jq3i3UZqz31qD1j/jhYcHa8HPUzqED/eLJxQZjURBolEPKI3YLmQzu4qjru7m
gm6wvvO0G+bNMhPA66hqFTMtCF811gJEGysOgM93+zjtcB8pz6rdqGDfTyB3KhqV
drYEXDVCfL55f5FvyNqrxZjMyhKp/cu9sjuf9eU+DqFC7EzlvBeuuFsGBQTIXaTx
B/e851BUOBMnSa4//u1sXKmh8pG7jD3BgBFDZ0cCYykMTzB6AFwSRYyclTLkT5ty
PO/QU5PWUgwHhoLixg9XyiOfwe+oiTYCYPpmE2DyMg+wfawCJm1INfljJeYhRhT1
+94IS6M9dRHsTmZ5V/BWk8uZd1deA20D0H8B8gK291pRVa0awIBaQKp/zl5CEe3S
VyWJYUbmGdRvQxB1fzbZ5l+RtYJjjCpUDs69qAk0/az+v5XvEQk0wm9HG8N838DL
c5JB+qAjmUSlRVEcB4D1y5uhbcBoJ8zgu5orsDcEE4tJZbmOsHA=
=psAz
-END PGP SIGNATURE-

Bug#992196: ITP: opensmalltalk-vm -- High performance virtual machine for Smalltalk

[Phil Bellalouna]

Package: wnpp
Severity: wishlist
Owner: Phil Bellalouna 
X-Debbugs-Cc: debian-de...@lists.debian.org,
pkg-sugar-de...@lists.alioth.debian.org

* Package name: opensmalltalk-vm
  Version : 1.0
  Upstream Author : squeak.org
* URL : https://github.com/OpenSmalltalk/opensmalltalk-vm
* License : MIT
  Programming Lang: Smalltalk, C
  Description : High performance virtual machine for Smalltalk

(this is part of the Squeak project https://squeak.org)

Squeak is a full-featured implementation of the Smalltalk programming
language and environment based on (and largely compatible with)
the original Smalltalk-80 system.

This package contains just the Unix Squeak opensmalltalk virtual machine, a
modern implementation with significantly enhanced performance.  You will
likely need also an image file containing a "snapshot" of a live Squeak
session - e.g. from the Squeak, Pharo or Cuis projects.

--

This package is needed to provide Debian with a modern, high performance
implementation of the Squeak VM.  Recent Smalltalk images provided by
Squeak and related dialects require this VM in order to run. A few key
points:
- It complements the existing squeak-vm package[1].
- One of the key differences between the implementations is that squeak-vm
is a pure bytecode interpreter while opensmalltalk-vm includes a high
performance JIT implementation for x86 and ARM.
- There are some shared resources between opensmalltalk-vm and squeak-vm.
As a result, at least two supporting packages (a common package and a
metapackage) are also proposed.
- We are prepared to upstream at least the majority of changes needed to
satisfy Debian packaging requirements.

I am a long-time Smalltalk developer and have been working with the Squeak
project to produce at least the initial package for this VM.  The Squeak
project is open to whatever arrangement Debian maintainers feel is
appropriate (i.e. it's unclear at this time if the Sugar team would be
interested in taking on maintenance of the package, if I would continue to
do so etc... this is open for discussion) for the ongoing maintenance of
the package(s).

I am looking for a sponsor.  Obviously, I need someone to help me get the
package uploaded.  I could also use some packaging advice, given the
non-trivial nature of this package.  I am a long-term Debian user and
believe we are addressing the key issues related to Debian packaging, but
would appreciate another set of eyes to confirm.

[1] squeak-vm is the 'classic' VM, whose code is also maintained by the
Squeak project.  It is still required by legacy applications such as
Scratch and Etoys, so the plan is for both VMs to co-exist.

Bug#991274: Package libldap-2.4-2 was built without LDAP_CONNECTIONLESS

[Ryan Tandy]

Hi Gerald,

The following patch is supposed to make CLDAP optional for sssd again:

https://github.com/SSSD/sssd/issues/5720
https://github.com/SSSD/sssd/pull/5743

Would it be possible for you to test that patch and report your findings 
in the issue or pull request?


CCing the sssd maintainers in case the fix might be suitable for 
backporting to bullseye.


thanks
Ryan

Bug#992034: Acknowledgement (installation-guide: Include a note on how to change init system during install)

[Matthew Vernon]

Hi,

How is this, then? A single short paragraph, with a link to more 
detailed instructions on the wiki.


As well as the attached, I opened 
https://salsa.debian.org/installer-team/installation-guide/-/merge_requests/15 
on salsa.


Regards,

Matthew
>From 6e6b681d094294b2bd0eaf5c1f55da591935b91e Mon Sep 17 00:00:00 2001
From: Matthew Vernon 
Date: Sun, 15 Aug 2021 16:49:36 +0100
Subject: [PATCH] Short note on installing alternative inits (Closes: #992034)

Discussion on the BTS apropos this bug / !14 suggests that a shorter
note with a link to more detailed discussion on the wiki would be more
agreeable. To that end, I've made this MR, which is a single brief
paragraph.
---
 en/using-d-i/components.xml | 20 +++-
 1 file changed, 19 insertions(+), 1 deletion(-)

diff --git a/en/using-d-i/components.xml b/en/using-d-i/components.xml
index 702185e97..f6b3eddbf 100644
--- a/en/using-d-i/components.xml
+++ b/en/using-d-i/components.xml
@@ -188,4 +188,22 @@ user in case something goes wrong.
 &module-shell.xml;
   
 &module-network-console.xml;
- 
+
+
+
+  Installing an alternative init system
+
+  
+
+ &debian; uses systemd as its default init system. Other init
+ systems (such as sysvinit and OpenRC) are supported, and the
+ easiest time to select an alternative init system is during the
+ installation process. For detailed instructions on how to do so,
+ please see the https://wiki.debian.org/Init#Changing_the_init_system_-_at_install_time";>Init
+ page on the Debian wiki.
+
+  
+
+
+
-- 
2.11.0

Bug#992187: debian-installer: Debian 11.0.0 ISO downloads packages from network (internet) even when no network mirror selected

[ValdikSS]

Package: debian-installer
Severity: normal
Tags: d-i

Dear Maintainer,

Debian 11.0.0 ISO file (debian-11.0.0-amd64-DVD-1.iso) silently 
downloads package index and updated .deb files from debian-security 
repository upon installation, even when no network mirror option was chosen.


I believe this is a mistake due to recent distro/updates -> 
distro-security security repository naming transaction.


HOW TO REPRODUCE:

1. Install Debian 11.0.0 from DVD ISO file on the computer with the
   internet connection
2. Choose "do not use internet mirror" option
3. Check internet usage upon installation

ACTUAL RESULT:
Wireshark shows bullseye-security repository index update and
perl .deb packets download (perl-base, perl-modules etc).

EXPECTED RESULT:
Internet is not used when "do not use internet mirror" option is 
chosen.


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

Kernel: Linux 5.10.0-8-amd64 (SMP w/2 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

Bug#992193: RM: birdtray/1.5-1

[Adam Borowski]

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

Hi!
As thunderbird is an animal more equal than others and gets to update to
major new upstream releases inside stable, related packages are likely to
get broken.  This happened over a year ago to birdtray.  Naturally, it
got updated upstream -- but that's a mix of support for new thunderbird
and unrelated new developments.

That made birdtray ineligible for a stable update as-is -- unless I argued
for uploading to a major new upstream, or did the work of unentangling
changes to somehow extract just the needed bits.  Neither has happened,
and by now we have Bullseye released.

Cf. #959927

Thus, let's get rid of birdtray/buster -- and hope this won't happen again.


Meow!

Bug#929248: changed its 'Suite' value from 'buster' to 'testing' ...

[Csillag Tamas]

On Sun, Aug 15, 2021 at 04:00:07PM +0100, Adam D. Barratt wrote:
> On Sun, 2021-08-15 at 16:08 +0200, Csillag Tamas wrote:
[...]
> > E: Repository 'http://security.debian.org buster/updates InRelease'
> > changed its 'Suite' value from 'stable' to 'oldstable'
> > N: This must be accepted explicitly before updates for this
> > repository can be applied. See apt-secure(8) manpage for details.
> > E: Repository 'http://deb.debian.org/debian buster InRelease' changed
> > its 'Suite' value from 'stable' to 'oldstable'
> > N: This must be accepted explicitly before updates for this
> > repository can be applied. See apt-secure(8) manpage for details.
> > E: Repository 'http://ftp.de.debian.org/debian buster InRelease'
> > changed its 'Suite' value from 'stable' to 'oldstable'
> > N: This must be accepted explicitly before updates for this
> > repository can be applied. See apt-secure(8) manpage for details.
> > 
> > 100 # cat /etc/debian_version
> > 10.9
> 
> At the risk of asking a possibly silly question, why are you not
> running 10.*10*, which was released in June and contained an APT
> package that downgraded that particular change to a notice?

That is a fair question and the reason is:
I have machines auto upgrading and rebooting when they have their uptime over 30
days however this automation was temporary disabled for a few weeks because
I had my wedding.
(It is staggered and made with some ansible and a cronjob.)

If 10.10 fixes apt-get that explains why I see this only on a handful of 
machines (most are on 10.10).
This also means that indeed the ad-hoc fix should be only needed once and last,
but not for future releases. This is good.

Thanks,
 cstamas
-- 

Bug#992098: version -6 seems to have introduced another bug

[Diederik de Haas]

On zondag 15 augustus 2021 14:33:05 CEST Salvatore Bonaccorso wrote:
> On Sun, Aug 15, 2021 at 12:03:23PM +0200, Diederik de Haas wrote:
> > I don't know the best way to go about that though. Technically speaking,
> > the reported issue is resolved. But users got another RC bug for it back.
> I have no time in the nex few days, but if there is still an new issue
> uncovered present with -6 which is to be sondisered RC, then we should
> fill a new spearate bug for it. Havin it RC will make sure verison in
> unstable will not migrate to testing.

Filed as https://bugs.debian.org/992192

Cheers,
  Diederik


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

Bug#992025: release-notes: Add section on switching init system

[Matthew Vernon]

Hi,

On 14/08/2021 08:42, Paul Gevers wrote:

On 09-08-2021 22:53, Matthew Vernon wrote:

Not currently (I imagine something like it will end up there
eventually); I think it warrants being in the release notes because it's
quite a significant change from Buster (where non-systemd inits were
largely unusable on desktop systems).


If that's the case, it makes more sense to mention it in the whats-new
section, keep it short and link to a wiki.


I'm not sure I really agree, but _something_ would be better than 
nothing, so if that's what is necessary to get something into the 
release notes, then how about the attached?


I've also opened 
https://salsa.debian.org/ddp-team/release-notes/-/merge_requests/124 to 
apply this.


Is that agreeable?

Regards,

Matthew
>From 33b4b6a4717a002a6aa099d0d016bed9f7911a62 Mon Sep 17 00:00:00 2001
From: Matthew Vernon 
Date: Sun, 15 Aug 2021 16:26:27 +0100
Subject: [PATCH] Short note on improved init support, link to wiki (Closes:
 #992025)

Feedback on !119 / #992025 was that some people would rather a much
shorter note on the improved support for alternative inits, and a link
to the Debian wiki for more detailed instructions.

I think this approach is less helpful to our users, but something is
better than nothing...
---
 en/whats-new.dbk | 14 ++
 1 file changed, 14 insertions(+)

diff --git a/en/whats-new.dbk b/en/whats-new.dbk
index e7f6aedd..d008cc7a 100644
--- a/en/whats-new.dbk
+++ b/en/whats-new.dbk
@@ -549,5 +549,19 @@ Among many others, this release also includes the following software updates:
   
 
 
+
+  
+  Improved support for alternative init systems
+  
+The default init system in Debian is systemd. In bullseye, a
+number of alternative init systems are supported (such as
+System-V-style init and OpenRC), and most desktop environments now
+work well on systems running alternative inits. Details on how to
+switch init system (and where to get help with issues related to
+running inits other than systemd) are available https://wiki.debian.org/Init";>on the Debian wiki.
+  
+
+
 
 
-- 
2.11.0

Bug#992192: cpio: Cannot stat: No such file or directory errors on cpio operations

[Diederik de Haas]

Package: cpio
Version: 2.13+dfsg-6
Severity: grave
Tags: upstream
Justification: renders package unusable
Forwarded: https://lists.gnu.org/archive/html/bug-cpio/2021-08/msg5.html

The fix for bug #992098 introduced a new RC error. As bug #992098 is
technically fixed (and 'done'), here's a new RC bug report for the new
issue. Purpose is also to prevent transitioning to testing.

When building a kernel, various operations are done with cpio and I'll
post an excerpt below and will attach a log file with more.

make[3]: Entering directory '/home/diederik/dev/debian/salsa/kernel-team/linux'
dh_installdirs /usr/share/linux-support-5.13.0-trunk/lib/python/debian_linux 
/usr/share/linux-support-5.13.0-trunk/modules
mkdir -p debian/linux-doc-5.13/usr/share/doc/linux-doc-5.13
set -o pipefail; \
find CREDITS MAINTAINERS README Documentation \
-name '.gitignore' -prune -o -name DocBook -prune -o \
-path Documentation/media -prune -o \
-path Documentation/sphinx -prune -o \
-name 'Makefile*' -prune -o \
-print | \
cpio -pd --preserve-modification-time 
'/home/diederik/dev/debian/salsa/kernel-team/linux/debian/linux-doc-5.13/usr/share/doc/linux-doc-5.13'
cp debian/config.defines.dump 
debian/linux-support-5.13.0-trunk/usr/share/linux-support-5.13.0-trunk
cp -R debian/installer 
debian/linux-support-5.13.0-trunk/usr/share/linux-support-5.13.0-trunk/installer
cpio: s.rst: Cannot stat: No such file or directory
dh_installdocs --link-doc=linux-doc-5.13
dh_installdocs --link-doc=linux-source-5.13
cp debian/lib/python/debian_linux/*.py 
debian/linux-support-5.13.0-trunk/usr/share/linux-support-5.13.0-trunk/lib/python/debian_linux
dh_python3
cpio: xt: Cannot stat: No such file or directory
cpio: t: Cannot stat: No such file or directory
cpio: txt: Cannot stat: No such file or directory
/usr/bin/make -f debian/rules.real VERSION=5.13 UPSTREAMVERSION=5.13 
SOURCE_SUFFIX= SOURCE_BASENAME=linux SOURCEVERSION=5.13.9-1~exp1 
ALL_FEATURESETS=none ABINAME=5.13.0-trunk install-base BUILDDEB_ARGS='-Zgzip 
-z1'
cpio: xt: Cannot stat: No such file or directory
make[3]: Entering directory '/home/diederik/dev/debian/salsa/kernel-team/linux'
cpio: l-simple.yaml: Cannot stat: No such file or directory
cpio: h8300-bsc.txt: Cannot stat: No such file or directory
dh_installchangelogs

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=992098#34 has 2 log
files attached and I'll attach the 1st one here too.
I think cpio-bug992098-attempt1.log shows the whole problem.

Cheers,
  Diederik


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

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

Versions of packages cpio depends on:
ii  libc6  2.31-13

cpio recommends no packages.

Versions of packages cpio suggests:
pn  libarchive1  

-- no debconf information
diederik@bagend:~/dev/debian/salsa/kernel-team/linux$ export 
DEBIAN_KERNEL_JOBS=14
diederik@bagend:~/dev/debian/salsa/kernel-team/linux$ export ARCH=arm64
diederik@bagend:~/dev/debian/salsa/kernel-team/linux$ export 
CC=aarch64-linux-gnu-gcc-10
diederik@bagend:~/dev/debian/salsa/kernel-team/linux$ dpkg-architecture 
--host-arch arm64
DEB_BUILD_ARCH=amd64
DEB_BUILD_ARCH_ABI=base
DEB_BUILD_ARCH_BITS=64
DEB_BUILD_ARCH_CPU=amd64
DEB_BUILD_ARCH_ENDIAN=little
DEB_BUILD_ARCH_LIBC=gnu
DEB_BUILD_ARCH_OS=linux
DEB_BUILD_GNU_CPU=x86_64
DEB_BUILD_GNU_SYSTEM=linux-gnu
DEB_BUILD_GNU_TYPE=x86_64-linux-gnu
DEB_BUILD_MULTIARCH=x86_64-linux-gnu
DEB_HOST_ARCH=arm64
DEB_HOST_ARCH_ABI=base
DEB_HOST_ARCH_BITS=64
DEB_HOST_ARCH_CPU=arm64
DEB_HOST_ARCH_ENDIAN=little
DEB_HOST_ARCH_LIBC=gnu
DEB_HOST_ARCH_OS=linux
DEB_HOST_GNU_CPU=aarch64
DEB_HOST_GNU_SYSTEM=linux-gnu
DEB_HOST_GNU_TYPE=aarch64-linux-gnu
DEB_HOST_MULTIARCH=aarch64-linux-gnu
DEB_TARGET_ARCH=arm64
DEB_TARGET_ARCH_ABI=base
DEB_TARGET_ARCH_BITS=64
DEB_TARGET_ARCH_CPU=arm64
DEB_TARGET_ARCH_ENDIAN=little
DEB_TARGET_ARCH_LIBC=gnu
DEB_TARGET_ARCH_OS=linux
DEB_TARGET_GNU_CPU=aarch64
DEB_TARGET_GNU_SYSTEM=linux-gnu
DEB_TARGET_GNU_TYPE=aarch64-linux-gnu
DEB_TARGET_MULTIARCH=aarch64-linux-gnu
diederik@bagend:~/dev/debian/salsa/kernel-team/linux$ fakeroot debian/rules 
binary-indep
dh_testdir
/usr/bin/make -f debian/rules.gen build-indep
make[1]: Entering directory '/home/diederik/dev/debian/salsa/kernel-team/linux'
/usr/bin/make -f debian/rules.real build-indep ABINAME='5.13.0-trunk' 
ALL_FEATURESETS='none' SOURCEVERSION='5.13.9-1~exp1' SOURCE_BASENAME='linux' 
SOURCE_SUFFIX='' UPSTREAMVERSION='5.13' VERSION='5.13'
make[2]: Entering directory '/home/diederik/dev/debian/salsa/kernel-team/linux'
make[2]: Nothing to be done for

Bug#929248: changed its 'Suite' value from 'buster' to 'testing' ...

[Adam D. Barratt]

On Sun, 2021-08-15 at 16:08 +0200, Csillag Tamas wrote:
> Hi,
> 
> On Sun, Jul 07, 2019 at 06:27:02PM +0200, Julian Andres Klode wrote:
> > On Sun, Jul 07, 2019 at 05:26:27PM +0200, Adam Borowski wrote:
> > > But, it's worse than merely annoying users of unstable and
> > > testing.  Two
> > > years from now, millions of boxes will have "buster" change to
> > > "oldstable",
> > > and, with cron mails currently being null-routed by default, no
> > > one will see
> > > that[1].  Thus, a significant part of users will have security
> > > updates
> > > suddenly stopped despite nothing relevant to them happening.
> > > 
> > > And this particular piece deserves a high severity.
> > 
> > Luckily we have about two years to deal with this (well, let's say
> > 18
> > months or so, gotta give people time to update before the new
> > stable).
> 
> fwiw. what Adam predicted is exactly what happened today:
> 
> # apt-get update
> Get:1 http://security.debian.org buster/updates InRelease [65.4 kB]
> Get:2 http://deb.debian.org/debian buster InRelease [122 kB]
> Get:3 http://ftp.de.debian.org/debian buster InRelease [122 kB]
> Reading package lists... Done
> E: Repository 'http://security.debian.org buster/updates InRelease'
> changed its 'Suite' value from 'stable' to 'oldstable'
> N: This must be accepted explicitly before updates for this
> repository can be applied. See apt-secure(8) manpage for details.
> E: Repository 'http://deb.debian.org/debian buster InRelease' changed
> its 'Suite' value from 'stable' to 'oldstable'
> N: This must be accepted explicitly before updates for this
> repository can be applied. See apt-secure(8) manpage for details.
> E: Repository 'http://ftp.de.debian.org/debian buster InRelease'
> changed its 'Suite' value from 'stable' to 'oldstable'
> N: This must be accepted explicitly before updates for this
> repository can be applied. See apt-secure(8) manpage for details.
> 
> 100 # cat /etc/debian_version
> 10.9

At the risk of asking a possibly silly question, why are you not
running 10.*10*, which was released in June and contained an APT
package that downgraded that particular change to a notice?

Regards,

Adam

Bug#992183: [installation-guide] in example-preseed.txt file is missing a line for apt-setup

[Holger Wansing]

Package: installation-guide
Severity: wishlist
Tags: patch


Hi,

while playing around with fully automated installations (using a netinst or
DVD-1 image), I found that the example-preseed.txt file (like
https://www.debian.org/releases/bullseye/example-preseed.txt) is lacking a 
line for the apt-cdrom-setup: 
The question for 

---
Template: apt-setup/cdrom/set-first
Type: boolean
Default: false
#flag:translate!:3
# :sl1:
_Description: Scan extra installation media?
 Scanning your installation media finds the label:
 .
 ${LABEL}
 .
 You now have the option of scanning additional media for use by the package
 manager (apt). Normally these should be from the same set as the one you
 booted from. If you do not have any additional media, this step can just be
 skipped.
 .
 If you wish to scan more media, please insert another one now.
--

The only question being asked during such installation was the above, all the
rest worked via preseeding.


A patch for the installation-guide is attached.


Holger


-- 
Holger Wansing 
PGP-Finterprint: 496A C6E8 1442 4B34 8508  3529 59F1 87CA 156E B076
diff --git a/en/appendix/preseed.xml b/en/appendix/preseed.xml
index 4f984b33b..83a7a4d6d 100644
--- a/en/appendix/preseed.xml
+++ b/en/appendix/preseed.xml
@@ -1414,6 +1414,9 @@ earlier questions. You can optionally add other (local) repositories.
 
 
 
+# Choose, if you want to scan additional installation media
+# (default: false).
+d-i apt-setup/cdrom/set-first boolean false
 # You can choose to install non-free and contrib software.
 #d-i apt-setup/non-free boolean true
 #d-i apt-setup/contrib boolean true

Bug#992191: deborphan: deborphan --help unterminated last line

[Barak A. Pearlmutter]

Package: deborphan
Version: 1.7.33

The last line of "deborphan --help" is not terminated: no final EOL, aka
NL, aka 0x0A, aka C-j.

  $ deborphan --help | tail -1 ; echo '***UNTERMINATED LINE***'
  See also: deborphan(1), orphaner(8)***UNTERMINATED LINE***

Bug#929248: changed its 'Suite' value from 'buster' to 'testing' ...

[Csillag Tamas]

Hi,

On Sun, Jul 07, 2019 at 06:27:02PM +0200, Julian Andres Klode wrote:
> On Sun, Jul 07, 2019 at 05:26:27PM +0200, Adam Borowski wrote:
> > 
> > But, it's worse than merely annoying users of unstable and testing.  Two
> > years from now, millions of boxes will have "buster" change to "oldstable",
> > and, with cron mails currently being null-routed by default, no one will see
> > that[1].  Thus, a significant part of users will have security updates
> > suddenly stopped despite nothing relevant to them happening.
> > 
> > And this particular piece deserves a high severity.
> 
> Luckily we have about two years to deal with this (well, let's say 18
> months or so, gotta give people time to update before the new stable).

fwiw. what Adam predicted is exactly what happened today:

# apt-get update
Get:1 http://security.debian.org buster/updates InRelease [65.4 kB]
Get:2 http://deb.debian.org/debian buster InRelease [122 kB]
Get:3 http://ftp.de.debian.org/debian buster InRelease [122 kB]
Reading package lists... Done
E: Repository 'http://security.debian.org buster/updates InRelease' changed its 
'Suite' value from 'stable' to 'oldstable'
N: This must be accepted explicitly before updates for this repository can be 
applied. See apt-secure(8) manpage for details.
E: Repository 'http://deb.debian.org/debian buster InRelease' changed its 
'Suite' value from 'stable' to 'oldstable'
N: This must be accepted explicitly before updates for this repository can be 
applied. See apt-secure(8) manpage for details.
E: Repository 'http://ftp.de.debian.org/debian buster InRelease' changed its 
'Suite' value from 'stable' to 'oldstable'
N: This must be accepted explicitly before updates for this repository can be 
applied. See apt-secure(8) manpage for details.

100 # cat /etc/debian_version
10.9

why I use apt-get instead of apt you ask?
Because that is what ansible does.

I can solve this for myself, but everyone needs to deal with it on its own.
(I have no idea if other cfg management systems deal with this any better or 
not)
Looking at the manpages to check if apt-get is deprecated I found that apt-get
is still preferred for scripting in general.

I usually run an ad-hoc command on all hosts with: "apt-get 
--allow-releaseinfo-change update".
What should ansible do? What is a better solution than running this after every 
release?

Regards,
 cstamas
-- 

Bug#992189: RM: mlocate -- ROM; replaced with plocate

[Steinar H. Gunderson]

On Sun, Aug 15, 2021 at 08:31:12PM +0800, Paul Wise wrote:
>> mlocate in unstable has now been replaced with plocate, ie., plocate 
>> contains a
>> binary package “mlocate” that is a transitional package. Thus, please remove
>> the mlocate source package in unstable (but not the mlocate binary package,
>> which comes from the plocate source).
> That is going to break cruft-ng, which directly reads the mlocate database.

If so, I guess that's an RC bug on cruft-ng? It would need to be changed to
call the locate binary. (I'm not sure whether the database format is part of
mlocate's API, but in plocate, it's definitely private.)

/* Steinar */
-- 
Homepage: https://www.sesse.net/

Bug#991972: More information

[Xan Charbonnet]

Sorry, I should have checked this on more than one browser before reporting.

For some reason my ancient Firefox profile, when I browse to 
"backports.org", redirects to https://www.backports.org/.  Perhaps this 
was a cached permanent redirect, or something to do with HSTS.


On a naive profile (with seemingly any browser), browsing to 
"backports.org" fails, because backports.org has no A record.  Not 
terribly friendly but not a problem.  It sounds like your browser has 
some memory that points backports.org to backports.debian.org.  A naive 
browser has no way to return anything for https://backports.org/ or 
http://backports.org/.


www.backports.org does have a CNAME record: it points to 
backports.debian.org, which seems to have the same IP address as 
debian.org.  Browsing to http://www.backports.org/ is successful: the 
Debian webserver redirects the request to https://backports.debian.org/, 
and when accessed via that name, the Debian webserver correctly serves 
the backports page.


However, when you browse to https://www.backports.org/ (note the secure 
protocol), that's when it breaks.  The Debian webserver defaults to 
serving the Debian homepage, complete with the TLS certificate for 
debian.org.  This causes a nasty security error in the browser, and if 
bypassed, results in the Debian homepage loading at 
https://www.backports.org/ rather than the Backports page.


The only remaining mystery is why my Firefox profile is handling 
"backports.org" the way it is.  I'm trying to figure out how to diagnose 
that, but it doesn't seem like there's much visibility to that kind of 
thing.  It could be something that affects everybody who visited 
backports.org during a particular timeframe.

Bug#992181: software-properties-gtk: Security-Updates-Repository is only recognized when using URL security.debian.org

[Karel]

Package: software-properties-gtk
Version: 0.96.20.2-2.1
Severity: normal
X-Debbugs-Cc: karel-...@tutanota.com

Dear Maintainer,

with the upgrade from Buster to Bullseye the Security Archive Layout changed as 
mentioned here in the release notes:

https://www.debian.org/releases/bullseye/amd64/release-notes/ch-information.en.html#security-archive

When using the URL specified there (deb.debian.org) the checkbox for receiving 
security updates is not checked in the GUI and when checking it another line 
containing security.debian.org ... is added to sources.list. 

As both URLs work and deb.debian.org seems to be the recommended official one I 
would expect both URLs to be recognized as valid URLs for security updates!?


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

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

Versions of packages software-properties-gtk depends on:
ii  gir1.2-gtk-3.0   3.24.24-4
ii  python3  3.9.2-3
ii  python3-gi   3.38.0-2
ii  python3-software-properties  0.96.20.2-2.1
ii  software-properties-common   0.96.20.2-2.1

software-properties-gtk recommends no packages.

Versions of packages software-properties-gtk suggests:
ii  gnome-software  3.38.1-1

-- no debconf information

Bug#992190: xandikos 0.2.2 unusable with uwsgi

[Félix Sipma]

Package: xandikos
Version: 0.2.2-1
Severity: important

I upgraded a machine running xandikos to bullseye, and 0.2.2-1 seems to 
be affected by https://github.com/jelmer/xandikos/issues/124, which 
makes it unusable with uwsgi.

Could you include the fix in the next point release?



-- System Information:
Debian Release: 11.0
  APT prefers unstable
  APT policy: (990, 'unstable'), (500, 'stable'), (100, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.10.0-8-amd64 (SMP w/4 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 xandikos depends on:
ii  python3 3.9.2-3
ii  python3-aiohttp 3.7.4-1
ii  python3-defusedxml  0.6.0-2
ii  python3-dulwich 0.20.23-1
ii  python3-icalendar   4.0.3-4
ii  python3-jinja2  2.11.3-1
ii  python3-multidict   5.1.0-1

Versions of packages xandikos recommends:
ii  python3-prometheus-client  0.9.0-1

xandikos suggests no packages.

-- no debconf information

-- 
Félix


signature.asc
Description: PGP signature

Bug#992098: version -6 seems to have introduced another bug

[Salvatore Bonaccorso]

Hi Diederik, Aníbal,

On Sun, Aug 15, 2021 at 12:03:23PM +0200, Diederik de Haas wrote:
> On vrijdag 13 augustus 2021 13:42:33 CEST Aníbal Monsalve Salazar wrote:
> > The Debian bug report is at:
> > https://bugs.debian.org/992098
> 
> The bug is marked as fixed in 2.13+dfsg-6 and done and thereby the block for 
> a 
> transition to testing is lifted. I think it should be kept out of testing and 
> people warned through apt-listbugs until this issue is fully resolved.
> 
> I don't know the best way to go about that though. Technically speaking, the 
> reported issue is resolved. But users got another RC bug for it back.

I have no time in the nex few days, but if there is still an new issue
uncovered present with -6 which is to be sondisered RC, then we should
fill a new spearate bug for it. Havin it RC will make sure verison in
unstable will not migrate to testing.

Regards,
Salvatore

Bug#992189: RM: mlocate -- ROM; replaced with plocate

[Paul Wise]

On Sun, 15 Aug 2021 13:56:50 +0200 Steinar H. Gunderson wrote:

> mlocate in unstable has now been replaced with plocate, ie., plocate contains 
> a
> binary package “mlocate” that is a transitional package. Thus, please remove
> the mlocate source package in unstable (but not the mlocate binary package,
> which comes from the plocate source).

That is going to break cruft-ng, which directly reads the mlocate database.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#990409: ca-cacert: should this package be removed?

[Gero Treuner]

Hi all,

Short introduction: I'm involved in CAcert as former board member and
currently not holding any executive function. So not officially
speaking, but I can provide some insight.

On Wed, Aug 11, 2021 at 02:50:27PM +0200, Axel Beckert wrote:
> Timo Röhling wrote:
> > * Axel Beckert  [2021-08-11 13:27]:
> > > I strongly disagree. CAcert offers way more types of certificates than
> > > Let's Encrypt. For example does Let's Encrypt not provide any
> > > certificates suitable for use as personal S/MIME e-mail certificates.

Regarding the general discussion:
Server certificates for the public is no more a (near) target, as we
have little resources and efforts to be accepted by vendors are huge.
The main asset of the CAcert community is the web of trust with
assurances, allowing personal certificates for email, although it's true
that users need to install the root certificate.

Not true is that we didn't bother to update the certificate on our
main page. In reality, the work on critical systems here required
multiple visits to the data center with cross-border travels, which is
not easy these days for several reasons.

By reading our blog you get an impression about what is going on:
https://blog.cacert.org/

> > Have you tried creating a personal S/MIME e-mail certificate lately?
> 
> Nope.
> 
> > Because I tried, and neither IE nor Edge nor Firefox nor Chrome nor Opera
> > support the required HTML  tag any more.

Although this is slightly off-topic, this symptom illustrates that we
have a large backlog after many years with few persons being active in
development. Overall we gain momentum here, and also in other areas such
as infrastructure. So one can expect progress in the future, likely
seeing some small steps in the next months.

Regarding certificate creation:

* Providing a CSR created by other means is and ever was possible.
Please follow "The manual way" here:
https://wiki.cacert.org/EmailCertificates

* A proof of concept about creating a CSR in the browser using a library
exists, but this needs to be refined and will take some time to be
publicly available.

> > > But instead it offers longer living certificates for hosts not
> > > directly reachable from the internet — which is a hell to achieve with
> > > Let's Encrypt.
> >
> > Private hosts are usually managed with a private CA, which gives you
> > much more control and versatility.
> 
> Not everyone is capable of running their own CA. Have you every tried
> "easyrsa"? It's anything but easy. (And I personally rather run an
> internal CA based on CAcert's scripts — which I actually do — than on
> easyrsa. Tried easyrsa mostly for OpenVPN and nearly ditched OpenVPN
> just because they recommend this crap.)
> 
> > Many companies do this,
> 
> Yeah, and often with worse outcome than with CAcert...
> 
> > and CAcert offers no advantage, since you'd still have to distribute
> > their root certificates to all your clients.
> 
> If it's available as a Debian package, that's a clear advantage from
> my point of view. :-)

Correct. This helps partners in signed/encrypted email conversions,
because the trust can easily be installed by almost everyone, not only
people which are interested and skilled in encryption.

We'd love to have the package updated with the new class3
certificate and readded to Debian.

> > > Again, I strongly disagree. I rather hope that Dmitry gets it back
> > > into shape and then also offers it via bullseye-backports.
> >
> > Well, if you, Dmitry, or anyone else feels that their time is well
> > spent on this package, by all means, go ahead. I just happen to
> > think that your contributions would be more valuable elsewhere.
> 
> I already have too many packages, so yes, I agree here. This though
> does not change my opinion on this package (or on a lot of other
> packages in Debian which I don't maintain, but consider important for
> myself as well as the community in general).

Does it help if I provide a patch?


Kind regards,
   Gero

Bug#714726: wrong (as in: release-specific) "Suite:" entry in backports Release file

[Stefan Bühler]

Hi again,

small status update: it seems bookworm (now testing) backports was 
created correctly (yay \o/), but bullseye (now stable) wasn't fixed.

I still doubt release.txt contains the correct instructions to update 
bookworm-backports to suite stable-backports on bookworm release.

---
$ curl -s http://ftp.debian.org/debian/dists/buster-backports/Release | head -n4
Origin: Debian Backports
Label: Debian Backports
Suite: buster-backports
Codename: buster-backports

$ curl -s http://ftp.debian.org/debian/dists/bullseye-backports/Release | head 
-n4
Origin: Debian Backports
Label: Debian Backports
Suite: bullseye-backports
Codename: bullseye-backports

$ curl -s http://ftp.debian.org/debian/dists/bookworm-backports/Release | head 
-n4
Origin: Debian Backports
Label: Debian Backports
Suite: testing-backports
Codename: bookworm-backports
---

cheers,
Stefan

Bug#992189: RM: mlocate -- ROM; replaced with plocate

[Steinar H. Gunderson]

Package: ftp.debian.org
Severity: normal
X-Debbugs-Cc: tfh...@debian.org

Hi,

mlocate in unstable has now been replaced with plocate, ie., plocate contains a
binary package “mlocate” that is a transitional package. Thus, please remove
the mlocate source package in unstable (but not the mlocate binary package,
which comes from the plocate source).

bullseye still contains both mlocate and plocate.

Bug#988329: ITA: usbredir/0.9.0-1 -- Simple USB host TCP server

[Tobias Frost]

Hi Lin,

(- as said in the mail before, dont close the RFS bug in the changelog)

- you could add yourself to the debian/* section in d/copyright, 

- d/control
  - has still the old S-V of 4.2.1...
  - the long description for usbredirserver, the deprecation notice should
possibly have its own paragraph?
  - is the B-D on cmake necessary? (as the package uses meson)

As othewise the package looks good, so lets finish the polishing and then do 
the upload!

--
Cheers,
tobi

Bug#992179: chromium: honour several locations for master_preferences file

[Mike Gabriel]

Package: chromium
Severity: wishlist
Version: 90.0.4430.212-1

I recently looked into how to enterprise-deploy chromium on large  
scale networks and how to best fiddle with chromium's  
master_preferences (initial_preferences, see #992178) -> user  
Preferences dealings and the Chromium's policy system.


Chromium does not seem to be very admin friendly regarding overriding  
upstream/distro-maintained initial preferences (i.e. the  
master_preferences file). A site admin can only deploy Debian's  
chromium by fiddling with the distro version of  
/etc/chromium/master_preferences (i.e. by hand or by script or by some  
config management tool).


So, I (as a site-admin) cannot provision/modify Chromium's first-run  
preferences by dropping some package file to some location and let my  
master_preferences file override the distro maintainer's  
master_preferences file. Instead I need to fiddle with chromium'
s /etc/chromium/master_preferences conffile. As I prefer rolling out  
changes via extra DEB packages rather then tinkering with sensible  
config defaults, I see scope for improvement here.


(And yes, I have tried out Chromium's recommended policies, but  
settings in master_preferences after having been copied over to  
~/.config/chromium/Default/Preferences always take precendence over  
recommended policies. Recommended policies get ignored for settings  
already pre-configured via master_preferences.


My suggesting now for Debian's chromium is:

  * Read distro-config from /usr/share/chromium/master_preferences  
(or .../initial_preferences, see #992178)
  * Allow admin to place a file into /etc/chromium/master_preferences  
(or /etc/chromium/initial_preferences, see #992178 again)


If upstream gets involved with this, one could even consider:

  * Read upstream config from /usr/share/chromium/master_preferences  
(or .../initial_preferences, see #992178)
  * Merge-in distro config from /etc/chromium/master_preferences (or  
.../initial_preferences, see #992178)
  * Additionally merge in site-admin's individual JSON files from  
/etc/chromium/initial_preferences.d/ in alphanumerical order


Thanks for maintaining chromium and for your time reading this!

Mike

--

DAS-NETZWERKTEAM
c\o Technik- und Ökologiezentrum Eckernförde
Mike Gabriel, Marienthaler Str. 17, 24340 Eckernförde
mobile: +49 (1520) 1976 148
landline: +49 (4351) 850 8940

GnuPG Fingerprint: 9BFB AEE8 6C0A A5FF BF22  0782 9AF4 6B30 2577 1B31
mail: mike.gabr...@das-netzwerkteam.de, http://das-netzwerkteam.de



pgpg5FBVDGNm7.pgp
Description: Digitale PGP-Signatur

Bug#992185: release-notes: Confusion with "apt full-upgrade" and "apt-get dist-upgrade"

[Justin B Rye]

Hideki Yamane wrote:
>> 
>>Dist-upgrade fails with Could not perform immediate 
>> configuration

You're right, this got left behind.  Patch attached.
-- 
JBR with qualifications in linguistics, experience as a Debian
sysadmin, and probably no clue about this particular package
diff --git a/en/upgrading.dbk b/en/upgrading.dbk
index 7c6057d4..7b4af6fe 100644
--- a/en/upgrading.dbk
+++ b/en/upgrading.dbk
@@ -1054,7 +1054,7 @@ E: You don't have enough free space in 
/var/cache/apt/archives/.
   
 
   
-Dist-upgrade fails with Could not perform immediate 
configuration
+Full-upgrade fails with Could not perform immediate 
configuration
 
   In some cases the apt full-upgrade step can fail after
   downloading packages with:

Bug#992188: alien: Fails to create packages that place files in /usr/local

[Rob N]

Package: alien
Version: 8.95.4
Severity: normal
X-Debbugs-Cc: r...@despairlabs.com

Dear Maintainer,

Severity: normal

Dear Maintainer,

We build a number of local packages installing to /usr/local in a
chroot, creating a tarball, then running alien to produce a .deb file.

Since bullseye, packages fail to build, eg:

  # debian/rules binary
  dh binary
 dh_testroot
 dh_prep
 debian/rules override_dh_auto_install
  make[1]: Entering directory 
'/usr/src/nginx-build/nginx-fastmail-9:1fmbullseye75159-1.20.1-fastmail'
  mkdir -p debian/nginx-fastmail
  # Copy the packages's files.
  find . -maxdepth 1 -mindepth 1 -not -name debian -print0 | \
  >-sed -e s#'./'##g | \
  >-xargs -0 -r -i cp -a ./{} debian/nginx-fastmail/{}
  make[1]: Leaving directory 
'/usr/src/nginx-build/nginx-fastmail-9:1fmbullseye75159-1.20.1-fastmail'
 dh_installdocs
 dh_installchangelogs
 dh_perl
 dh_usrlocal
  dh_usrlocal: error: debian/nginx-fastmail/usr/local/nginx/conf/fastcgi.conf 
is not a directory
  make: *** [debian/rules:7: binary] Error 255

The easiest workaround seems to be to add:

  override_dh_usrlocal:

to the generated debian/rules.

I understand that files in /usr/local is against Debian policy, but
these aren't packages for Debian proper, and there's no telling what
might be included inside the source package.

Cheers,
Rob N.

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

Kernel: Linux 4.19.0-10-cloud-amd64 (SMP w/2 CPU threads)
Locale: LANG=en_US.UTF-8, LC_CTYPE=C.UTF-8 (charmap=locale: Cannot set 
LC_MESSAGES to default locale: No such file or directory
locale: Cannot set LC_ALL to default locale: No such file or directory
UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: unable to detect

Versions of packages alien depends on:
ii  cpio   2.13+dfsg-4
ii  debhelper  13.3.4
ii  dpkg-dev   1.20.9
ii  make   4.3-4.1
ii  perl   5.32.1-4
ii  rpm4.16.1.2+dfsg1-3
ii  rpm2cpio   4.16.1.2+dfsg1-3

alien recommends no packages.

Versions of packages alien suggests:
ii  bzip21.0.8-4
ii  lintian  2.104.0
ii  patch2.7.6-7
ii  xz-utils [lzma]  5.2.5-2

-- debconf information:
perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
LANGUAGE = (unset),
LC_ALL = (unset),
LC_CTYPE = "C.UTF-8",
LANG = "en_US.UTF-8"
are supported and installed on your system.
perl: warning: Falling back to the standard locale ("C").
locale: Cannot set LC_MESSAGES to default locale: No such file or directory
locale: Cannot set LC_ALL to default locale: No such file or directory

Bug#992178: chromium: master_preferences has been renamed to initial_preferences (which gets ignored by Debian's chromium build)

[Mike Gabriel]

Package: chromium
Severity: minor
Version: 90.0.4430.212-1
Tags: patch

For some customer project I did some research on the Chromium  
preferences and policy system recently. (Note, that this bug report  
does not have a patch attached, but points to a usable patch in  
openSUSE's packaging Git, see below).


While looking at parts of the chromium source code, I found that  
chromium renamed "master_preferences" to "initial_preferences" [1].


The "master_preferences" file is still legacy supported by chromium's  
code base, but might be removed later.


Chromium on Windows and openSUSE (and likely other distros) honours  
both files (initial_preferences, master_preferences) and  
initial_preferences takes precendence (I assume, haven't tested it).


Chromium upstream expects the initial_preferences (and  
master_preferences) file(s) next to the chromium executable [2]. In  
Linux distros, this does not work, distro maintainers patch in some  
/etc/chromium path here.


In Debian, Chromium simply honours /etc/chromium/master_preferences as  
the only possible file location, the path is hard-coded [3].


In openSUSE, for example, they ship a slightly more elegant patch [4]  
that I'd like to recommend for Debian's chromium, too:


```
Index:  
chromium-91.0.4472.57/chrome/browser/first_run/first_run_internal_linux.cc

===
---  
chromium-91.0.4472.57.orig/chrome/browser/first_run/first_run_internal_linux.cc

+++ chromium-91.0.4472.57/chrome/browser/first_run/first_run_internal_linux.cc
@@ -21,9 +21,7 @@ bool IsOrganicFirstRun() {
 base::FilePath InitialPrefsPath() {
   // The standard location of the initial prefs is next to the chrome binary.
   base::FilePath initial_prefs;
-  if (!base::PathService::Get(base::DIR_EXE, &initial_prefs))
-return base::FilePath();
-
+  initial_prefs = base::FilePath("/etc/chromium");
   base::FilePath new_path =  
initial_prefs.AppendASCII(installer::kInitialPrefs);

   if (base::PathIsReadable(new_path))
 return new_path;
```

Greets,
Mike

[1]  
https://github.com/chromium/chromium/commit/119506a6d70f0932c3808aea7327a4439c931667
[2]  
https://github.com/chromium/chromium/blob/d7da0240cae77824d1eda25745c4022757499131/chrome/browser/first_run/first_run_internal_linux.cc#L24
[3]  
https://salsa.debian.org/chromium-team/chromium/-/blob/master/debian/patches/debianization/master-preferences.patch
[4]  
https://build.opensuse.org/package/view_file/network:chromium/chromium/chromium-master-prefs-path.patch?expand=1




--

DAS-NETZWERKTEAM
c\o Technik- und Ökologiezentrum Eckernförde
Mike Gabriel, Marienthaler Str. 17, 24340 Eckernförde
mobile: +49 (1520) 1976 148
landline: +49 (4351) 850 8940

GnuPG Fingerprint: 9BFB AEE8 6C0A A5FF BF22  0782 9AF4 6B30 2577 1B31
mail: mike.gabr...@das-netzwerkteam.de, http://das-netzwerkteam.de



pgpCb__ztXmej.pgp
Description: Digitale PGP-Signatur

Bug#992186: mailman3-web: Quoting in postinst broken

[Uwe Kleine-König]

Package: mailman3-web
Version: 0+20200530-2
Severity: normal

Hello,

mailman3-web's postinst contains:

if [ -n "$su_name" ] && [ -n "$su_mail" ] && [ -n "$su_password" ]; then
$su_cmd "$django_admin shell $django_admin_args --command \
\"from django.contrib.auth.models import User; \
  User.objects.filter(username='$su_name').delete(); \
  User.objects.create_superuser('$su_name', \
  '$su_mail', '$su_password')\"" www-data
fi

This is not robust for su_password (or su_name or su_mail) containing "
or '. When in the debconf dialog such a password is provided, in the
simplest case the script terminates with

sh: 1: Syntax error: Unterminated quoted string 

But worse things can happen, see https://xkcd.com/327/. :-)

Best regards
Uwe

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

Kernel: Linux 5.10.0-8-amd64 (SMP w/2 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 mailman3-web depends on:
ii  dbconfig-sqlite3   2.0.19
ii  debconf [debconf-2.0]  1.5.77
ii  init-system-helpers1.60
ii  lsb-base   11.1.0
ii  python33.9.2-3
ii  python3-django-hyperkitty  1.3.4-4
ii  python3-django-postorius   1.3.4-2
ii  python3-psycopg2   2.8.6-2
ii  python3-whoosh 2.7.4+git6-g9134ad92-5
ii  ucf3.0043
ii  uwsgi-core 2.0.19.1-7.1
ii  uwsgi-plugin-python3   2.0.19.1-7.1

Versions of packages mailman3-web recommends:
ii  libapache2-mod-proxy-uwsgi  2.4.48-3.1

Versions of packages mailman3-web suggests:
ii  postgresql  13+225

-- debconf information excluded

Bug#992169: Cinnamon does not automatically start screen reader on login

[Fabio Fantoni]

orca .desktop file have cinnamon in "OnlyShowIn" field but orca is not 
started, seems blocked by "AutostartCondition=GSettings 
org.gnome.desktop.a11y.applications screen-reader-enabled"


enabling it in cinnamon control center works correctly, keybinding 
instead was missed and I did a PR upstream for it as default 
(https://github.com/linuxmint/cinnamon-desktop/pull/198)


I did a fast search but I don't found where/how should enable screen 
reader if enabled on login screen but is not  in the gsetting





OpenPGP_signature
Description: OpenPGP digital signature

Bug#988329: ITA: usbredir/0.9.0-1 -- Simple USB host TCP server

[Tobias Frost]

(Sorry, I've missed your mail.)

On Mon, Jul 19, 2021 at 04:38:26PM +, Lin Qigang wrote:
> retitle 911431 "ITA: usbredir/0.10.0 -- Simple USB host TCP server"
> tags 988329 - moreinfo
> thanks
> 
> Hi Tobi and everyone else,
> 
> I added #911431 and #988329 to the changelog. I hope retitling this bug
> solves the "package closes bug in a wrong way" lintian error. Otherwise could
> you please help me fix this?

RFSs bugs are not closed using the debian changelog, so remove that one from 
the changelog.

(I try to take a look later today on the package itself)

-- 
tobi

Bug#992185: release-notes: Confusion with "apt full-upgrade" and "apt-get dist-upgrade"

[Hideki Yamane]

Package: release-notes
Severity: minor
X-Debbugs-Cc: henr...@debian.org

Hi,

 In en/upgrading.dbk, one of its section title says about "Dist-upgrade",
 so it's about "apt-get dist-upgrade"
> 
>Dist-upgrade fails with Could not perform immediate 
> configuration

 However, paragraphs continue as

>
>  In some cases the apt full-upgrade step can fail after
>  downloading packages with:
 
 "apt full-upgrade", not apt-get. We should choose one to avoid confusion.

Bug#991919: Bioconductor API Bump to 3.13

[Andreas Tille]

Hi,

On Sun, Aug 15, 2021 at 10:01:21AM +0200, Dylan Aïssi wrote:
> 
> The transition tracker is on at
> https://release.debian.org/transitions/html/r-api-bioc-3.13.html
> 
> We are now waiting for the green-light from the release team (at
> https://bugs.debian.org/991919) to start the transition of
> bioconductor packages.

Thanks for triggering this.  Meanwhile I'm starting upgrading
r-cran-packages from the end of the alphabeth (as traveling
connection permits).

Kind regards

 Andreas. 

-- 
http://fam-tille.de

Bug#959892: RFS: awf-gtk/2.5.0-1 [ITP] -- A widget factory is a theme preview application for GTK

[Fabrice Creuzot]

I have added GTK version in short description.
I have removed the GTK 2 build, I'm sad :'(.

I updated patch description.

For the manpages, yes, it's in my futur todo list, but not yet done.
Mentors package updated.

Le 15/08/2021 à 12:20, Tobias Frost a écrit :

On Sun, Aug 15, 2021 at 11:52:59AM +0200, Tobias Frost wrote:

On Sun, Aug 15, 2021 at 11:21:21AM +0200, Fabrice Creuzot wrote:

Hi,

Thank you.

I hope I have fixed the crash with GTK 4.
I fixed the debian format.

I changed unstable to testing, good?


You want "experimental" :)

--
tobi



(I've merged the RFS and ITP bugs)

- Beside "experimental", lintian has:
   I duplicate-short-description
 Possibly ammend the short description by the intended GTK version?


- The patch has a "Bugs-Debian" entry, but the mentioned bug is the ITP.  This
   is not the intended usage of the field: The field should be used if that
   patch fixes a specific Debian-Bug, with information the bug being fixed the
   mentioned bug. (The ITP is not fixin a bug) TL;DR: Remove that field.

   Though, you should add "Fowarded:" entries (possibly not-needed if Debian 
specific)

   (Please read https://dep-team.pages.debian.net/deps/dep3/ for all those 
details
   about the dep3 format.)

   - BTW, https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=959434#10 … Possibly
 you should drop the gtk-2 version from your package to be nice to the GTK
 maintainers (it will create extra work for them if you introduce new GTK2
 packages)

- (Wishlist) Would it be possible to have some manpages for the binaries?

--
tobi


  

Bug#915246: [Aptitude-devel] Bug#915246: Bug#931536: aptitude update fails to cope with changed release info

[Axel Beckert]

Hi,

Francesco Poli wrote:
> this bug is still unfixed in aptitude...

Correct.

> Are there any plans to fix this bug in aptitude once and for all?

I assume so, yes. But not by myself as this is outside of my C/C++
capabilities. (In other words: I hope that Manuel — or someone else —
will find time to tackle this at some point with one of the next
upstream releases.)

Oh, and of course: Patches are welcome!

If there are well working patches, I can also apply them in the
upstream branches and do upstream releases with them. I just can't
write new C++ code from scratch. (I other words: Within the Aptitude
team, I'm primarily the package maintainer and Manuel does nearly all
of the upstream development.)

Regards, Axel
-- 
 ,''`.  |  Axel Beckert , https://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE

Bug#992184: linux: Should CONFIG_LEDS_TRIGGER_HEARTBEAT be builtin?

[Diederik de Haas]

Source: linux
Version: 5.13.9-1~exp2
Severity: wishlist

Currently there are some LED triggers builtin and some as modules:

$ grep 'CONFIG_LEDS_TRIGGER' /boot/config-5.13.0-trunk-arm64 
CONFIG_LEDS_TRIGGERS=y
CONFIG_LEDS_TRIGGER_TIMER=m
CONFIG_LEDS_TRIGGER_ONESHOT=m
CONFIG_LEDS_TRIGGER_DISK=y
CONFIG_LEDS_TRIGGER_MTD=y
CONFIG_LEDS_TRIGGER_HEARTBEAT=m
CONFIG_LEDS_TRIGGER_BACKLIGHT=m
CONFIG_LEDS_TRIGGER_CPU=y
CONFIG_LEDS_TRIGGER_ACTIVITY=m
CONFIG_LEDS_TRIGGER_GPIO=m
CONFIG_LEDS_TRIGGER_DEFAULT_ON=m
CONFIG_LEDS_TRIGGER_TRANSIENT=m
CONFIG_LEDS_TRIGGER_CAMERA=m
CONFIG_LEDS_TRIGGER_PANIC=y
CONFIG_LEDS_TRIGGER_NETDEV=m
CONFIG_LEDS_TRIGGER_PATTERN=m
CONFIG_LEDS_TRIGGER_AUDIO=m
# CONFIG_LEDS_TRIGGER_TTY is not set

While working on
https://salsa.debian.org/kernel-team/linux/-/merge_requests/384
I noticed that after enabling the modules, the heartbeat LED on my
Rock64 didn't turn 'on', while it is defined as the default trigger in
the DeviceTree. I noticed that `/sys/devices/platform/leds/leds/led-1/trigger`
didn't even contain 'heartbeat' as trigger.
After doing `modprobe ledtrig-heartbeat`, 'heartbeat' was available and
automatically selected as the current trigger.
Doing 'modprobe' is inconvenient, but that can be worked around by
creating a file in `/etc/modprobe.d/`.

But I use it in a similar way as 'panic', which is builtin. The Rock64
has a bit of a thermal problem and f.e. compiling a kernel is out of the
question without cooling (which I do not yet have). The CPU/device gets
so hot, it freezes and the only way out is pulling the plug. So when the
'heartbeat' LED stops blinking, I know it crashed.
Like 'panic', but with a slightly different cause.

As mentioned earlier, 'heartbeat' was defined as the default trigger in
the DeviceTree of the Rock64. It turns out, there are a lot more:
diederik@bagend:~/dev/debian/salsa/kernel-team/linux$ 
grep -r 'linux,default-trigger = "heartbeat";' arch/ | wc -l
281

Most are in arch arm*, but also in arc/powerpc/microblaze/mips.

Which raises the question (of this bug): 
Should `CONFIG_LEDS_TRIGGER_HEARTBEAT=m` be changed to `=y`?

Cheers,
  Diederik

PS: kernel is tainted as I'm running 5.13.9-1~exp3 which contain
modifications from MR 384, based off of current 'master'.
PS2: I sent this bug report earlier (against src:linux-config-5.13), but there 
was a problem with bugs.d.o, so I assume it went to /dev/null

-- System Information:
Debian Release: 11.0
  APT prefers stable
  APT policy: (990, 'stable'), (500, 'stable-security'), (500, 'unstable'), 
(101, 'experimental')
Architecture: arm64 (aarch64)

Kernel: Linux 5.13.0-trunk-arm64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_UNSIGNED_MODULE
Locale: LANG=C.UTF-8, LC_CTYPE=C.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

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

Bug#988346: RFS: fpart/1.3.0-1

[Tobias Frost]

On Sun, 16 May 2021 17:21:11 +0200 Ganael Laplanche
 wrote:
> 
> 
> Le 15/05/2021 à 08:15, Tobias Frost a écrit :
> 
> Hello Tobias,
> 

> Thanks *a lot* for your detailed review ! (I'll take time to have a look 
> at each point and come back to you).

Freeze is over :) If you want, we can start tackling the package now :). Let me
know!

Cheers,
--
tobi

Bug#971594: RFS: asciidoc/9.0.2-1 [ITA] -- Highly configurable text format for writing documentation

[Tobias Frost]

Hi Leon,

now that bullseye is released, we could tackle asciidoc... What do you think? 

-- 
tobi

Bug#959892: RFS: awf-gtk/2.5.0-1 [ITP] -- A widget factory is a theme preview application for GTK

[Tobias Frost]

On Sun, Aug 15, 2021 at 11:52:59AM +0200, Tobias Frost wrote:
> On Sun, Aug 15, 2021 at 11:21:21AM +0200, Fabrice Creuzot wrote:
> > Hi,
> > 
> > Thank you.
> > 
> > I hope I have fixed the crash with GTK 4.
> > I fixed the debian format.
> > 
> > I changed unstable to testing, good?
> 
> You want "experimental" :)
> 
> --
> tobi
>

(I've merged the RFS and ITP bugs)

- Beside "experimental", lintian has:
  I duplicate-short-description
Possibly ammend the short description by the intended GTK version?


- The patch has a "Bugs-Debian" entry, but the mentioned bug is the ITP.  This
  is not the intended usage of the field: The field should be used if that
  patch fixes a specific Debian-Bug, with information the bug being fixed the
  mentioned bug. (The ITP is not fixin a bug) TL;DR: Remove that field.

  Though, you should add "Fowarded:" entries (possibly not-needed if Debian 
specific)

  (Please read https://dep-team.pages.debian.net/deps/dep3/ for all those 
details
  about the dep3 format.)

  - BTW, https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=959434#10 … Possibly
you should drop the gtk-2 version from your package to be nice to the GTK
maintainers (it will create extra work for them if you introduce new GTK2
packages)

- (Wishlist) Would it be possible to have some manpages for the binaries?

--
tobi


 

Bug#992098: version -6 seems to have introduced another bug

[Diederik de Haas]

On vrijdag 13 augustus 2021 13:42:33 CEST Aníbal Monsalve Salazar wrote:
> The Debian bug report is at:
> https://bugs.debian.org/992098

The bug is marked as fixed in 2.13+dfsg-6 and done and thereby the block for a 
transition to testing is lifted. I think it should be kept out of testing and 
people warned through apt-listbugs until this issue is fully resolved.

I don't know the best way to go about that though. Technically speaking, the 
reported issue is resolved. But users got another RC bug for it back.




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

Bug#959892: RFS: awf-gtk/2.5.0-1 [ITP] -- A widget factory is a theme preview application for GTK

[Tobias Frost]

On Sun, Aug 15, 2021 at 11:21:21AM +0200, Fabrice Creuzot wrote:
> Hi,
> 
> Thank you.
> 
> I hope I have fixed the crash with GTK 4.
> I fixed the debian format.
> 
> I changed unstable to testing, good?

You want "experimental" :)

--
tobi

Bug#982459:

[Håkan T Johansson]

Hi,

I believe that I have been hit by this bug too.

What has happened for me is that the machine in question 'almost' locks 
up, with a read-only /, and such that most commands to debug further never 
complete due to waiting for filesystem action.  It then requires a reboot.


'dmesg' has worked, and then shows ext4-related issues.  However, they 
were not recorded to /var/log.  I generally do not find any corruption on 
the filesystem itself when running fsck afterwards.


On the machine I have a number of chroot debian installations of different 
releases. By pure chance I found that 'update-initramfs' was the trigger 
for the system hangs. I could then repeatably trigger the issue again.
(Before this, it would happen as part of system maintenance (unattended 
upgrades in the chroots), so just spuriously hang the machine.)


In my case, the chroot installations live on a ZFS filesystem.  But the 
host system itself is on (multiple; /, /usr/, /var/ ) MD raid1.


I have had /proc mounted in the chroots.  But had forgotten /dev .  After 
mounting /dev (and /dev/pts) in the chroots, the issue has not happened 
again.


The issue was when the host system ran Buster, I then upgraded to Bullseye 
~2 weeks ago, hoping it would be resolved, but the issue was still present 
after the upgrade.  Only after that upgrade I found the update-initramfs 
trigger.


I am running with sysvinit, both on host and chroots.

Currently, I do not have hands-on access to the system, so cannot inspect 
or reboot it reliably.  Should be able to do some further tests in a few 
weeks.


Best regards,
Håkan

Bug#992175: RFS: htmldoc/1.9.12-1 -- HTML processor that generates indexed HTML, PS, and PDF

[Håvard Flaget Aasen]

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

 * Package name: htmldoc
   Version : 1.9.12-1
   Upstream Author : Michael R Sweet 
 * URL : https://www.msweet.org/htmldoc/
 * License : Apache-2.0 with (L)GPL-2 exception, BSD-2-Clause,
GPL-2, bitstream, Apache-2.0, zlib, MIT-CMU, GPL-2 with document exception
 * Vcs : https://salsa.debian.org/haava/htmldoc
   Section : web

It builds those binary packages:

  htmldoc-common - Common arch-independent files for htmldoc
  htmldoc - HTML processor that generates indexed HTML, PS, and PDF

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

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

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

  dget -x
https://mentors.debian.net/debian/pool/main/h/htmldoc/htmldoc_1.9.12-1.dsc

Changes since the last upload:

 htmldoc (1.9.12-1) unstable; urgency=medium
 .
   * New upstream version 1.9.12
   * Update patches
   * d/rules: Prevent automake and autoheader being run.
   * d/copyright: Remove entries for third-party libraries.
   * d/copyright: Update copyright year and fixed a typo.
   * Run wrap-and-sort -at
   * Move package into Vcs repository

Regards,
Håvard

Bug#992182: ifmail: verbose option results in segmentation fault

[Björn Wiberg]

Package: ifmail
Version: 2.14tx8.10-26
Severity: normal

Hello Marco,

It appears that using the "verbose" option in /etc/ifmail/config results in a 
segmentation fault when ifcico is called. E.g.:

/etc/inetd.conf:

tfido   stream  tcp4nowait  ftn /usr/sbin/tcpd  
/usr/lib/ifmail/ifcico -t 1
tfido   stream  tcp6nowait  ftn /usr/sbin/tcpd  
/usr/lib/ifmail/ifcico -t 1
fidostream  tcp4nowait  ftn /usr/sbin/tcpd  
/usr/lib/ifmail/ifcico
fidostream  tcp6nowait  ftn /usr/sbin/tcpd  
/usr/lib/ifmail/ifcico

bbs@glimmer:~$ telnet scbbs.nsupdate.info 60177
Trying 188.149.138.116...
Connected to scbbs.nsupdate.info.
Escape character is '^]'.
Connection closed by foreign host.

bbs@glimmer:~$ telnet scbbs.nsupdate.info 60179
Trying 188.149.138.116...
Connected to scbbs.nsupdate.info.
Escape character is '^]'.
Connection closed by foreign host.
bbs@glimmer:~$

/var/log/messages shows:

Aug 15 11:28:33 glimmer kernel: [  997.807638] ifcico[2891]: segfault at 797854 
ip 7ffb07726ad1 sp 7fff6fb95ef8 error 4 in 
libc-2.31.so[7ffb075ec000+14b000]
Aug 15 11:28:33 glimmer kernel: [  997.807646] Code: 84 00 00 00 00 00 0f 1f 00 
31 c0 c5 f8 77 c3 66 2e 0f 1f 84 00 00 00 00 00 89 f9 48 89 fa c5 f9 ef c0 83 
e1 3f 83 f9 20 77 1f  fd 74 0f c5 fd d7 c1 85 c0 0f 85 df 00 00 00 48 83 c7 
20 83 e1

Aug 15 11:28:36 glimmer kernel: [ 1000.925952] ifcico[2896]: segfault at 797854 
ip 7fbce0605ad1 sp 7ffde9094898 error 4 in 
libc-2.31.so[7fbce04cb000+14b000]
Aug 15 11:28:36 glimmer kernel: [ 1000.925967] Code: 84 00 00 00 00 00 0f 1f 00 
31 c0 c5 f8 77 c3 66 2e 0f 1f 84 00 00 00 00 00 89 f9 48 89 fa c5 f9 ef c0 83 
e1 3f 83 f9 20 77 1f  fd 74 0f c5 fd d7 c1 85 c0 0f 85 df 00 00 00 48 83 c7 
20 83 e1

Could this possibly be related to Debian bug #872507?
"options" seem to work, but not "verbose".

I'll revert to non-verbose logging in the mean time.

Best regards
Björn


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

Kernel: Linux 5.10.0-8-amd64 (SMP w/4 CPU threads)
Locale: LANG=en_US.UTF-8, LC_CTYPE=sv_SE.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 ifmail depends on:
ii  adduser  3.118
ii  perl 5.32.1-4+deb11u1

ifmail recommends no packages.

Versions of packages ifmail suggests:
ii  ifcico  2.14tx8.10-26
pn  ifgate  

-- Configuration Files:
/etc/cron.weekly/ifmail changed:
exit 0

/etc/ifmail/config changed:
logfile /var/log/ifmail/iflog
debugfile   /var/log/ifmail/ifdebug
verbose7
address 21:1/202@fsxnet
address 2:201/137@fidonet
address 618:500/27@micronet
address 77:2/107@scinet
include /etc/ifmail/passwds
magicname   UUCP
inbound /mnt/bbs/echomail/in/unsecure
listinbound /mnt/bbs/echomail/in/unsecure
protinbound /mnt/bbs/echomail/in
outbound/mnt/bbs/echomail/out/fsxnet
public  /var/local/empty
reqmap  /etc/ifmail/reqmap
nodelist/mnt/bbs/echomail/nodelists/FSXNET
nodelistNODELIST2:201/137@fidonet
nodelistmicronet618:500/27@micronet
nodelistscinet  77:2/107@scinet
domtrans.z1.fidonet .z1.fidonet.org
domtrans.z2.fidonet .z2.fidonet.org
domtrans.z3.fidonet .z3.fidonet.org
domtrans.z4.fidonet .z4.fidonet.org
domtrans.fidonet.ftn
database/var/spool/ftn/ifdbm
sequencer   /var/spool/ftn/seq
gatebaugroupfido.
maxgroups   10
maptabdir   /usr/lib/ifmail/maptabs
defaultftnchar  cp437
defaultrfcchar  iso-8859-1
sendmail/usr/sbin/sendmail -oi -f $F $T
iftoss  /usr/lib/ifmail/iftoss
unzip   /usr/bin/unzip -Lojq $F
unarj   /usr/bin/arj e $F 2> /dev/null
unlzh   /usr/bin/lha xiq $F
unarc   /usr/bin/arc x $F
unzoo   /usr/bin/zoo -extract $F
unrar   /usr/bin/unrar e $F 2> /dev/null
packer  /usr/bin/zip -q9 $F $P
maxfsize50
maxpsize30
maxmsize 123000
msgidbm /var/spool/ftn/ifmsgids
ModemPort   (IBN) nomodem
ModemPort   (IFC|ITN|IVM) nomodem
ModemPort   (! 
(V22|V29|V32|V32B|V34|HST|H14|H16|MAX|CSP|V32T|VFC|ZYX|V90C|V90S|X2C|X2S|Z19)) 
nomodem
ModemPort   (! phone 46-) nomodem
PhoneTrans  46-18   /
PhoneTrans  46- /   0
PhoneTrans  /   00
ModemReset  \d\d\d\d\dATZ\r\d\d\d\d\d
ModemDial   (time Any2100-0800,We0800-1000) ATM0DT\T\r
ModemDial   ATDT\T\r
ModemOK OK
ModemConnectCONNECT
ModemError  BUSY
ModemError  NO\sCARRIER
ModemError  NO\sDIAL
ModemError  RING\r
ModemError  RING\s
ModemError  RING1
Mode