Bug#991967: Simply ACPI powerdown/reset issue?

[Fr. Chuck Zmudzinski, C.P.M.]

On 9/25/2021 11:27 PM, Elliott Mitchell wrote:

On Tue, Sep 21, 2021 at 06:33:20AM -0400, Chuck Zmudzinski wrote:

I presume you are suggesting I try booting 4.19.181-1 on the
current version of Xen-4.14 for bullseye as a dom0. I am not
inclined to try it until an official Debian developer endorses
your opinion that the bug I am seeing is distinct
from #991967, at which point I will report the bug I am
seeing as a new bug.

Chuck Zmudzinski you are getting rather close to my threshold for calling
harrassment.  You're not /quite/ there, but I'm concerned.


Sorry if I offended you in some way, I didn't mean to.


Since the purpose of the bug reports is to find and diagnose bugs, I did
a bit of experimentation and made some observations.

I checked out the Debian Xen source via git.  I got the current
"master" branch which is presently the candidate 4.14.3-1 version,
which includes urgent fixes.  The hash is:
e7a17db0305c8de891b366ad3528e5a43015

On top of this I cherry-picked 3 commits from Xen's main branch:
5a4087004d1adbbb223925f3306db0e5824a2bdc
0f089bbf43ecce6f27576cb548ba4341d0ec46a8
bc141e8ca56200bdd0a12e04a6ebff3c19d6c27b


By main branch, I presume you mean the unstable
4.16 branch of Xen. Correct?

(these can be retrieved via Xen's gitweb at
https://xenbits.xen.org/gitweb/?p=xen.git;a=patch;h=<$hash> which is
suitable for the `git am` command)

With these I built 4.14.3-1 and then tried kernels 4.19.181-1 and
4.19.194-3 (this system is presently mostly on oldstable).  The results
were:

Xen 4.14.3-1 with Linux 4.19.181-1: system reboots were successful

Xen 4.14.3-1 with Linux 4.19.194-3: system reboots hung



Interesting. Looks like you are honing in on solving this bug. I notice
at the beginning of this message you quoted an older message of mine
which does not take into account that I have reported a new bug
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=994899
because I did come to the conclusion, as you did, that there are
in fact two bugs.

I wonder if the results of your modified Xen 4.14.3-1 with
4.19.181-1 and 4.19.194-3 on my hardware would be of help.
I have, as you might recall, older (Haswell) intel, EFI boot
system, and systemd for init/shutdown services.
If I get the same result, then I would agree we are seeing a
regression between those two versions of Linux. Otherwise,
then there may also be some tests involving EFI vs. BIOS to
do. Or, based on what I have learned at #994899, also possibly
we need to check systemd vs. sysv-init. Do you want me to
do the test on my hardware?


Unfortunately I was too quick at installing the rebuilt 4.14.3-1 and I
missed trying the vanilla Debian 4.14.2+25-gb6a8c4f72d-2 with
Linux 4.19.181-1. I believe this combination would have hung during
reboot.


I can confirm it did hang on my hardware with this combination of
Xen and Linux versions.


As such, I believe there are in fact two distinct bugs being observed.
The presence of EITHER of these is sufficient to cause hangs during
powerdown or reboot.


And we already have two distinct bugs on BTS.

First, some patch originally from Linux's main branch breaks Xen reboots
was backported somewhere between 4.19.181-1 and 4.19.194-3.  This may
either have been introduced before 5.10 diverged from main, or may also
have been backported to 5.10.  THIS is Debian bug #991967.


I agree. I believe you.

Second, the Xen patch 3c428e9ecb1f290689080c11e0c37b793425bef1 which is
valuable to ARM devices breaks reboots and powerdowns on x86.  This is
correctly fixed by 0f089bbf43ecce6f27576cb548ba4341d0ec46a8.

Presently
this has no Debian bug report.


That looks a lot like #994889. Have you ruled out the possibility that
this bug is #994889 in disguise? If so, how? Or do you think #994889
is a third bug?


The first is presently unidentified, someone enthusiastic either needs to
read git logs/source code, or bisect and build to find where it got
broken.


Yeah, that's alot of work. That's how I found my solution for #994889.
For that bug, since the working version was Xen 4.11 and the broken
version was Xen 4.14, the cause could have been in 4.12, 4.13, or 4.14.
So that required a bit of detective work studying git logs, but in the
end, I just tested 4.12, and it was good, then 4.13 and it was good.
I also tested the first Debian version of 4.14, which was actually
experimental on Debian if I recall correctly. It did not include the
RPI4 patches, and it was good too. So I knew the bug was introduced
sometime after that, and I soon identified the RPI4 patches as the place
where the bug (#994889) first appeared on my hardware.

The second we seem to have a fix.  The only question is how many patches
to cherry pick?  bc141e8ca562 is non-urgent as it is merely superficial
and not needed for functionality.
5a4087004d1a is a workaround for Linux kernel breakage, but how likely
are we to see that fixed in the Linux kernel packages?  The fix is
well-contained and needed for some highly popular ARM devices.

Bug#995096: RM: node-millstone -- ROM; Unusable due to broken dependency

[Yadd]

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

node-millstone is broken due to node-srs break. Please remove it.

Cheers,
Yadd

Bug#995097: RM: node-carto -- ROM; Useless and broken

[Yadd]

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

node-carto is broken due to node-srs bug. Please remove it.

Cheers,
Yadd

Bug#995095: RM: node-srs -- ROM; Incompatible with gdal update and useless

[Yadd]

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

Hi,

following #992527, please remove this useless package.

Bug#995094: linux-image-5.10.0-8-amd64: wifi won't connect

[Tanmoy]

Package: src:linux
Version: 5.10.46-5
Severity: important
X-Debbugs-Cc: bum@gmail.com

Dear Maintainer,

 * What led up to the situation?
After upgrading to Bullseye --- my wifi stop connecting ( forever trying 
to connect!)
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
I booted into 4.19 kernel and the wifi is working as usual! The 
last kernel upgrade of 5.10 does not solve my problem! ( the same thing
has occured with another distribution I am using - there too kernel 5.10
failed to connect to wifi but kernel 5.4 does it normally!)
  
 * What was the outcome of this action?
One curious thing if I connect my Android phone beforehand to wifi --- then
the kernel 5.10 connects to wifi normally! Otherwise it kept searching 4
ip adress (dhcp)!


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

** Model information
sys_vendor: Gigabyte Technology Co., Ltd.
product_name: H310M S2 2.0
product_version: Default string
chassis_vendor: Default string
chassis_version: Default string
bios_vendor: American Megatrends Inc.
bios_version: F12
board_vendor: Gigabyte Technology Co., Ltd.
board_name: H310M S2 2.0
board_version: x.x

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

00:02.0 VGA compatible controller [0300]: Intel Corporation CoffeeLake-S GT1 
[UHD Graphics 610] [8086:3e90] (prog-if 00 [VGA controller])
DeviceName: Onboard - Video
Subsystem: Gigabyte Technology Co., Ltd Device [1458:d000]
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- 
Kernel driver in use: i915
Kernel modules: i915

00:08.0 System peripheral [0880]: Intel Corporation Xeon E3-1200 v5/v6 / 
E3-1500 v5 / 6th/7th/8th Gen Core Processor Gaussian Mixture Model [8086:1911]
DeviceName: Onboard - Other
Subsystem: Gigabyte Technology Co., Ltd Xeon E3-1200 v5/v6 / E3-1500 v5 
/ 6th/7th/8th Gen Core Processor Gaussian Mixture Model [1458:5000]
Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- 

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

00:16.0 Communication controller [0780]: Intel Corporation 200 Series PCH CSME 
HECI #1 [8086:a2ba]
DeviceName: Onboard - Other
Subsystem: Gigabyte Technology Co., Ltd 200 Series PCH CSME HECI 
[1458:1c3a]
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- 
Kernel driver in use: mei_me
Kernel modules: mei_me

00:17.0 SATA controller [0106]: Intel Corporation 200 Series PCH SATA 
controller [AHCI mode] [8086:a282] (prog-if 01 [AHCI 1.0])
DeviceName: Onboard - SATA
Subsystem: Gigabyte Technology Co., Ltd 200 Series PCH SATA controller 
[AHCI mode] [1458:b005]
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- 
SERR- 
Kernel driver in use: ahci
Kernel modules: ahci

00:1c.0 PCI bridge [0604]: Intel Corporation 200 Series PCH PCI Express Root 
Port #5 [8086:a294] (rev f0) (prog-if 00 [Normal decode])
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- TAbort- Reset- FastB2B-
PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
Capabilities: 
Kernel driver in use: pcieport

00:1c.5 PCI bridge [0604]: Intel Corporation 200 Series PCH PCI Express Root 
Port #6 [8086:a295] (rev f0) (prog-if 00 [Normal decode])
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast 

Bug#992527: [Pkg-javascript-devel] Bug#992527: node-srs: FTBFS with GDAL 3.3.1

[Sebastiaan Couwenberg]

On Wed, 15 Sep 2021 18:49:12 +0200 Yadd  wrote:
> Le 15/09/2021 à 16:10, Sebastiaan Couwenberg a écrit :
> > Since this only exists as part of the node-carto dependency chain,
> > removing this package along with node-millstone and node-carto is
> > probably a better idea than spending time fixing this issue.
> 
> Hi JS Team,
> 
> OK to remove node-srs, node-miilstone and node-carto ?

Yes, please. I was about to send an intent to RM these packages to
pkg-javascript-devel@. As long as this issue is not fixed (either by
switching to node-gdal-async or removing the package), the rdeps of the
old gdal library cannot be removed.

Kind Regards,

Bas

-- 
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1

Bug#995089: debian-11.0.0-amd64-netinst.iso: install yes ; reboot no

[r]

Package: debian-11.0.0-amd64-netinst.iso
Version: bullseye
Severity: important

Dear Reader,

1 Using debian-11.0.0-amd64-netinst.iso on a key to install debian 11 on a new
and empty machine :
- Intel Core i3-10100
- Gigabyte B560 HD3
- Kingston Fury beast 16 Go
- Crucial P2 M.2 PCIe NVMe 500 Go (SSD)

2 Install (graphical) works fine but
- can't reboot
- power off then on and Bios seas the SSD with the right name
- exiting the Bios manually, few lines appear very fast (RAM something,
processor something ...) and the machine is blocked
- tried several times the whole thing

3 Trying to boot on the key leads to install dialog ; whatever the option the
result is the same

Many thanks
Renaud Roche (Marseille France)



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

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

Bug#991967: Simply ACPI powerdown/reset issue?

[Elliott Mitchell]

On Tue, Sep 21, 2021 at 06:33:20AM -0400, Chuck Zmudzinski wrote:
> I presume you are suggesting I try booting 4.19.181-1 on the
> current version of Xen-4.14 for bullseye as a dom0. I am not
> inclined to try it until an official Debian developer endorses
> your opinion that the bug I am seeing is distinct
> from #991967, at which point I will report the bug I am
> seeing as a new bug.

Chuck Zmudzinski you are getting rather close to my threshold for calling
harrassment.  You're not /quite/ there, but I'm concerned.


Since the purpose of the bug reports is to find and diagnose bugs, I did
a bit of experimentation and made some observations.

I checked out the Debian Xen source via git.  I got the current
"master" branch which is presently the candidate 4.14.3-1 version,
which includes urgent fixes.  The hash is:
e7a17db0305c8de891b366ad3528e5a43015

On top of this I cherry-picked 3 commits from Xen's main branch:
5a4087004d1adbbb223925f3306db0e5824a2bdc
0f089bbf43ecce6f27576cb548ba4341d0ec46a8
bc141e8ca56200bdd0a12e04a6ebff3c19d6c27b

(these can be retrieved via Xen's gitweb at
https://xenbits.xen.org/gitweb/?p=xen.git;a=patch;h=<$hash> which is
suitable for the `git am` command)

With these I built 4.14.3-1 and then tried kernels 4.19.181-1 and
4.19.194-3 (this system is presently mostly on oldstable).  The results
were:

Xen 4.14.3-1 with Linux 4.19.181-1: system reboots were successful

Xen 4.14.3-1 with Linux 4.19.194-3: system reboots hung

Unfortunately I was too quick at installing the rebuilt 4.14.3-1 and I
missed trying the vanilla Debian 4.14.2+25-gb6a8c4f72d-2 with
Linux 4.19.181-1.  I believe this combination would have hung during
reboot.


As such, I believe there are in fact two distinct bugs being observed.
The presence of EITHER of these is sufficient to cause hangs during
powerdown or reboot.

First, some patch originally from Linux's main branch breaks Xen reboots
was backported somewhere between 4.19.181-1 and 4.19.194-3.  This may
either have been introduced before 5.10 diverged from main, or may also
have been backported to 5.10.  THIS is Debian bug #991967.

Second, the Xen patch 3c428e9ecb1f290689080c11e0c37b793425bef1 which is
valuable to ARM devices breaks reboots and powerdowns on x86.  This is
correctly fixed by 0f089bbf43ecce6f27576cb548ba4341d0ec46a8.  Presently
this has no Debian bug report.


The first is presently unidentified, someone enthusiastic either needs to
read git logs/source code, or bisect and build to find where it got
broken.

The second we seem to have a fix.  The only question is how many patches
to cherry pick?  bc141e8ca562 is non-urgent as it is merely superficial
and not needed for functionality.
5a4087004d1a is a workaround for Linux kernel breakage, but how likely
are we to see that fixed in the Linux kernel packages?  The fix is
well-contained and needed for some highly popular ARM devices.


-- 
(\___(\___(\__  --=> 8-) EHM <=--  __/)___/)___/)
 \BS (| ehem+sig...@m5p.com  PGP 87145445 |)   /
  \_CS\   |  _  -O #include  O-   _  |   /  _/
8A19\___\_|_/58D2 7E3D DDF4 7BA6 <-PGP-> 41D1 B375 37D0 8714\_|_/___/5445

Bug#995092: guile-3.0: reproducible builds: parallelism triggers differences

[Vagrant Cascadian]

Source: guile-3.0
Severity: normal
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: randomness toolchain
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

The order of references to various .scm files used when building guile
(or using guile to build various .go files) may appear in arbitrary
order, or sometimes even missing (in the example below):

  
https://tests.reproducible-builds.org/debian/rb-pkg/bookworm/amd64/diffoscope-results/guile-3.0.html

  /usr/lib/x86_64-linux-gnu/guile/3.0/ccache/ice-9/deprecated.go

  26 ice-9/deprecated.scm vs. 26 ice-9/deprecated.scm
  27 ice-9/boot-9.scm 27 ice-9/boot-9.scm
  28 ice-9/psyntax.scm


The attached patch fixes this by disabling parallelism in debian/rules.

With this patch applied, guile-3.0 should become reproducible on
tests.reproducible-builds.org once it migrates to bookworm (in the
unstable and experimental suites build paths will still trigger issues).

Though, the underlying issue is also triggered when using guile to build
other packages... so it would be good to fix in guile upstream as well,
as this is part of a toolchain used to build other packages...


Thanks for maintaining guile-3.0!


live well,
  vagrant
From e87d944f8f0330f89a2a9d2c8028b9383f78031b Mon Sep 17 00:00:00 2001
From: Vagrant Cascadian 
Date: Sun, 26 Sep 2021 02:01:07 +
Subject: [PATCH] debian/rules: Disable parallelism to avoid embedding
 references to .scm files in arbitrary order.

---
 debian/rules | 7 ++-
 1 file changed, 2 insertions(+), 5 deletions(-)

diff --git a/debian/rules b/debian/rules
index 2024c94..dfe8068 100755
--- a/debian/rules
+++ b/debian/rules
@@ -27,10 +27,7 @@ export HOME := $(CURDIR)/debian/no-trespassing
 # Keep this in sync with guile-doc.install
 expected_info := guile.info $(foreach n,1 2 3 4 5 6 7 8 9 10 11,guile.info-$(n))
 
-joblimit := $(patsubst parallel=%,%,$(filter parallel=%,$(DEB_BUILD_OPTIONS)))
-ifeq (,$(joblimit))
-  joblimit := 1
-endif
+joblimit := 1
 
 # Uncomment this to turn on verbose mode.
 #export DH_VERBOSE := 1
@@ -101,7 +98,7 @@ define checkdir
 endef
 
 %:
-	dh $@ --parallel --with autoreconf
+	dh $@ --no-parallel --with autoreconf
 
 .PHONY: check-vars
 check-vars:
-- 
2.30.2



signature.asc
Description: PGP signature

Bug#995042: pidgin: new upstream releases 2.14.2 to 2.14.7

[Richard Laager]

Thanks for your report. I was finally able to find some time today for 
Debian work. I've updated to the latest Pidgin release. I do have a lot 
more work to do on modernizing the packaging, but at least we're 
shipping the latest upstream release now.


--
Richard

Bug#976960: systemd: Please package systemd-userdbd and systemd-homed - bookworm

[Andrea Pappacoda]

Package: systemd
Version: 247.9-1
Followup-For: Bug #976960

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

> This can be reconsidered in bookworm.

Hi Michael, now that bullseye has been out for a while, do you believe this
could be part of the next release?

While enabling it by default is not yet possible (even though the SSH issues
are not unsolvable, see
https://www.freedesktop.org/software/systemd/man/userdbctl.html#Integration%20with%20SSH
and https://wiki.archlinux.org/title/systemd-homed#SSH_remote_unlocking) I
think that this could really be useful in multi-user workstations or in
schools, and to setups where security is important in general.

I'm trying to become a maintainer, and since working in a team is a good place
to start I could help you with the packaging of this particular part of systemd


- -- Package-specific info:

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

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

Versions of packages systemd depends on:
ii  adduser  3.118
ii  libacl1  2.3.1-1
ii  libapparmor1 3.0.3-2
ii  libaudit11:3.0.5-1
ii  libblkid12.37.2-1
ii  libc62.32-4
ii  libcap2  1:2.44-1
ii  libcrypt11:4.4.25-2
ii  libcryptsetup12  2:2.4.0-1
ii  libgcrypt20  1.9.4-3+b1
ii  libgnutls30  3.7.2-2
ii  libgpg-error01.42-3
ii  libip4tc21.8.7-1
ii  libkmod2 29-1
ii  liblz4-1 1.9.3-2
ii  liblzma5 5.2.5-2
ii  libmount12.37.2-1
ii  libpam0g 1.4.0-10
ii  libseccomp2  2.5.1-1
ii  libselinux1  3.1-3
ii  libsystemd0  247.9-1
ii  libzstd1 1.4.8+dfsg-2.1
ii  mount2.37.2-1
ii  systemd-timesyncd [time-daemon]  247.9-1
ii  util-linux   2.37.2-1

Versions of packages systemd recommends:
ii  dbus  1.12.20-2

Versions of packages systemd suggests:
ii  policykit-10.105-31
ii  systemd-container  247.9-1

Versions of packages systemd is related to:
pn  dracut   
ii  initramfs-tools  0.140
ii  libnss-systemd   247.9-1
ii  libpam-systemd   247.9-1
ii  udev 247.9-1

- -- no debconf information

-BEGIN PGP SIGNATURE-

iIoEARYIADIWIQRm3vFSgpkMIZnvqAGooSioqxzuSQUCYU+TnRQcYW5kcmVhQHBh
cHBhY29kYS5pdAAKCRCooSioqxzuSVJMAP42QiyPs3uRZ+02tZ06UlQ8B7YSzX77
ehhUrbuq77NWYQEA1oFr85/d4wg2aHLPzz/0GBOYo2yRIYewAh6UKvN+WAQ=
=wuJc
-END PGP SIGNATURE-

Bug#995086: RFS: color-picker/1.0.2-2 -- Powerful screen color picker based on Qt

[Hugo Torres]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "color-picker":

 * Package name: color-picker
   Version : 1.0.2-2
   Upstream Author : https://github.com/keshavbhatt/ColorPicker/issues
 * URL : https://github.com/keshavbhatt/ColorPicker
 * License : MIT
 * Vcs : https://salsa.debian.org/debian/colorpicker
   Section : graphics

It builds those binary packages:

  color-picker - Powerful screen color picker based on Qt

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

  https://mentors.debian.net/package/color-picker/

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

  dget -x 
https://mentors.debian.net/debian/pool/main/c/color-picker/color-picker_1.0.2-2.dsc

Changes since the last upload:

 color-picker (1.0.2-2) unstable; urgency=medium
 .
   * debian/control: Updated Vcs-* URLs.
   * debian/upstream/io.github.keshavbhatt.color_picker.metainfo.xml:
   - Added caption tag in images.
   - Added content_rating tag.

Regards,
--
  Hugo Torres de Lima

Bug#977835: Please package the lastest version >= 3.5.2

[Thorsten Glaser]

John Scott dixit:

>It's been a little while. Do you still plan on working on this?

Yes, as time permits. I’m even keeping my ear on a possible
inofficial (as the new Muse Group management is disinterested)
3.7 which is accumulating over a hundred fixes still. I’m
still wary of the regressions relative to 3.2 though which
I fear will require a nōntrivial amount of original work on
my side.

bye,
//mirabilos
-- 
Yes, I hate users and I want them to suffer.
-- Marco d'Itri on gmane.linux.debian.devel.general

Bug#990798: Switch to fork?

[Nick Black (Public gmail account)]

Source: libsixel
Version: 1.8.6-2
Followup-For: Bug #990798
X-Debbugs-Cc: dankamong...@gmail.com

Dear Maintainer,

Hi. I'm the maintainer of the new fork of libsixel at libsixel/libsixel on
GitHub. I've been maintaining it for several months now.

I see you merged my PR on salsa:

  https://salsa.debian.org/debian/libsixel/-/merge_requests/2

We just need a new release now to switch to the new fork, with its
many security fixes (it would close several outstanding Important
bugs on this package). With that said, you might as well pull down
the newest version, 1.10.2, just released tonight. You can go
ahead and drop `libbsd-dev` from the Build-Dependencies when you
do so, as it is no longer used.

Please make a new release.

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

Kernel: Linux 5.13.18nlbschwarzgerat (SMP w/64 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 /bin/dash

Bug#988696: No network management in LXDE task

[Holger Wansing]

Hi,

Michael Biebl  wrote (Sat, 25 Sep 2021 22:17:48 +0200):
> Am 25.09.21 um 22:05 schrieb Holger Wansing:
> > A patch to address this issue for LXDE is attached.
> 
> 
> So now you have 3 network configuration systems involved:
> 
> - ifupdown, which is still installed by default
> - connman, which is pulled in by the lxde package (via connman-gtk)
> - network-manager(-gnome), which is pulled in via task-lxde-desktop
> 
> that doesn't sound like a good solution.

Hmm, as there are no Conflicts dependencies set for those, I assumed this
is no problem... ?


Holger

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

Bug#988696: No network management in LXDE task

[Holger Wansing]

Control: retitle -1 LXDE: Please include a user-friendly network management tool
Control: tags -1 + patch


[ Returning back to #988696 as the correct bug for this issue; dropping 994875 
from CC ]

Jaycee Santos  wrote (Thu, 23 Sep 2021 20:42:05 +):
> On Thursday, September 23rd, 2021 at 1:05 PM, Michael Biebl 
>  wrote:
> > Am 23.09.21 um 21:35 schrieb Jaycee Santos:
> > >  Is there a reason why to choose gnome-network-manager over something like
> > >  nm-tray for LXDE?
> >
> > I think nm-tray (being based on Qt5) is a reasonable choice for LXQT (which 
> > is also Qt5 based). LXDE on the other hand uses GTK, so I think 
> > network-manager-gnome is a better fit there. (both disk footprint and 
> > memory usage wise)
> 
> Ah. My apologies. I thought nm-applet was provided by nm-tray. I was wrong.
> I did not know that nm-applet was part of network-manager-gnome!
> 
> So I agree with network-manager-gnome being a better fit for LXDE.

Regarding LXQT: this DE already installs cmst by default (an Qt based
GUI for connman, which also has a system tray icon), and since there were
no complains so far from LXQT users related to the network management tool 
used, I would not touch LXQT for this.


A patch to address this issue for LXDE is attached.

Holger



diff --git a/debian/changelog b/debian/changelog
index 148cd82d..f4fba03e 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,21 +1,22 @@
 tasksel (3.69) UNRELEASED; urgency=medium
 
   * Install CUPS for all *-desktop tasks, now that task-print-service is no
 longer existing. Closes: #993668
+  * Install network-manager-gnome in LXDE environment. Closes: #988696
 
  -- Holger Wansing   Wed, 08 Sep 2021 22:20:05 +0200
 
 tasksel (3.68) unstable; urgency=medium
diff --git a/debian/control b/debian/control
index 1f469e86..ec6ced7e 100644
--- a/debian/control
+++ b/debian/control
@@ -208,34 +208,36 @@ Package: task-lxde-desktop
 Architecture: all
 Description: LXDE
  This task package is used to install the Debian desktop, featuring
  the LXDE desktop environment, and with other packages that Debian users
  expect to have available on the desktop.
 Depends: ${misc:Depends},
task-desktop,
lightdm,
lxde,
 Recommends:
lxtask,
lxlauncher,
xsane,
 # libreoffice widgets using just gtk, and also accessibility needs the GTK 
frontend
libreoffice-gtk3,
 # Package management.
synaptic,
+# desktop network setup
+   network-manager-gnome,
 # libreoffice is the best word processor / office suite at the moment
libreoffice-writer,
libreoffice-calc,
libreoffice-impress,
 # make help menu work
libreoffice-help-en-us,
 # make thesaurus work
mythes-en-us,
 # make spellchecker work
hunspell-en-us,
 # make hyphenation work
hyphen-en-us,
 # gui for configuration of the print service
system-config-printer,
 # orca works with lxde, adding accessibility
orca,
 




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

Bug#995088: closed by "Adam D. Barratt" (Re: Bug#995088: dnsmasq: Dnsmasq package doesn't include dnsmasq binaries)

[Biprodeep Roy]

Hi Adam,

Thanks for the explanation. It is my bad, sorry for the confusion. :)

Regards,
Biprodeep.

On Sun, Sep 26, 2021 at 3:48 AM Debian Bug Tracking System <
ow...@bugs.debian.org> wrote:

> This is an automatic notification regarding your Bug report
> which was filed against the dnsmasq package:
>
> #995088: dnsmasq: Dnsmasq package doesn't include dnsmasq binaries
>
> It has been closed by "Adam D. Barratt" .
>
> Their explanation is attached below along with your original report.
> If this explanation is unsatisfactory and you have not received a
> better one in a separate message then please contact "Adam D. Barratt" <
> a...@adam-barratt.org.uk> by
> replying to this email.
>
>
> --
> 995088: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=995088
> Debian Bug Tracking System
> Contact ow...@bugs.debian.org with problems
>
>
>
> -- Forwarded message --
> From: "Adam D. Barratt" 
> To: Biprodeep 
> Cc: 995088-d...@bugs.debian.org
> Bcc:
> Date: Sat, 25 Sep 2021 23:14:26 +0100
> Subject: Re: Bug#995088: dnsmasq: Dnsmasq package doesn't include dnsmasq
> binaries
> On Sun, 2021-09-26 at 03:33 +0530, Biprodeep wrote:
> > Package: dnsmasq
> > Version: 2.80-1+rpt1+deb10u1
> > Severity: important
> >
> > Dear Maintainer,
> >
> > Dnsmasq which was installed from raspbian repository with exact
> > debian version:
> >
> >   dnsmasq_2.80-1+rpt1+deb10u1_all.deb
> >
> > doesn't include any dnsmasq binaries i.e. the /usr/sbin or /usr/bin
> > directories were not packaged and pushed upstream.
> >
>
> Indeed, those directories are in the arch-dependent "dnsmasq-base"
> package, and have been since 2008.
>
> The "dnsmasq" package depends on the "dnsmasq-base" package, so
> installing it will always get you the binaries.
>
> Regards,
>
> Adam
>
>
> -- Forwarded message --
> From: Biprodeep 
> To: Debian Bug Tracking System 
> Cc:
> Bcc:
> Date: Sun, 26 Sep 2021 03:33:24 +0530
> Subject: dnsmasq: Dnsmasq package doesn't include dnsmasq binaries
> Package: dnsmasq
> Version: 2.80-1+rpt1+deb10u1
> Severity: important
>
> Dear Maintainer,
>
> Dnsmasq which was installed from raspbian repository with exact debian
> version:
>
> dnsmasq_2.80-1+rpt1+deb10u1_all.deb
>
> doesn't include any dnsmasq binaries i.e. the /usr/sbin or /usr/bin
> directories were not packaged and pushed upstream.
>
> -- System Information:
> Distributor ID: Raspbian
> Description:Raspbian GNU/Linux 10 (buster)
> Release:10
> Codename:   buster
> Architecture: aarch64
>
> Kernel: Linux 5.10.63-v8+ (SMP w/4 CPU cores; PREEMPT)
> Kernel taint flags: TAINT_CRAP
> Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8),
> LANGUAGE=en_GB.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
>
> Versions of packages dnsmasq depends on:
> ii  dnsmasq-base [dnsmasq-base]  2.80-1+rpt1
> ii  init-system-helpers  1.56+nmu1
> ii  lsb-base 10.2019051400+rpi1
> ii  netbase  5.6
>
> dnsmasq recommends no packages.
>
> Versions of packages dnsmasq suggests:
> ii  openresolv [resolvconf]  3.8.0-1
>
> -- no debconf information
>


-- 
*Thanks & Regards,*
*Biprodeep Roy.*
*Mobile - +91 9748582303*
*LinkedIn - BIPRO *
*Github - Biprodeep *

Bug#995091: d-i: partman-efi allows method "efi" on wrong device types

[Pascal Hambourg]

Package: partman-efi
Version: 94
Tags: patch

Hello d-i team,

Partman allows to use any type of device as "EFI System Partition": not 
only regular partition but also LVM logical volume, encrypted device, 
RAID array... It should be allowed only on partitions which actually 
support an "EFI System Partition" type.


The attached patch enables method "efi" only if flag "esp" is valid for 
the partition. I hope the patch has the proper format.
diff -ur a/choose_method/efi/choices b/choose_method/efi/choices
--- a/choose_method/efi/choices	2021-09-13 22:12:05.0 +0200
+++ b/choose_method/efi/choices	2021-09-26 00:42:06.655800689 +0200
@@ -1,6 +1,6 @@
 #!/bin/sh
 
-. /usr/share/debconf/confmodule
+. /lib/partman/lib/base.sh
 
 dev=$1
 id=$2
@@ -13,6 +13,19 @@
 	exit 0
 fi
 
+cd "$dev"
+
+valid_esp=no
+open_dialog VALID_FLAGS $id
+while { read_line flag; [ "$flag" ]; }; do
+	if [ "$flag" = esp ]; then
+		valid_esp=yes
+	fi
+done
+close_dialog
+
+[ "$valid_esp" = yes ] || exit 0
+
 db_metaget partman-efi/text/efi description
 
 printf "efi\t${RET}\n"

Bug#977835: Please package the lastest version >= 3.5.2

[John Scott]

On Tue, 22 Dec 2020 00:42:36 + (UTC) Thorsten Glaser  wrote:
> >thanks for considering
> 
> Not before bullseye. There are many regressions and problems
> with the new releases. I plan on doing (at least) one more
> upload with more individual fixes backported, though ☺
> 
> My current plan is to package 3.6.x after bullseye, providing
> them to users via bullseye-backports and buster-backports-sloppy
> as usual.
> 
> With enough time I’ll begin packaging these in experimental.

Hi Thorsten,

It's been a little while. Do you still plan on working on this?


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

Bug#995090: systemd_system_unit_dir should be /usr/lib/systemd/system

[Richard Laager]

Package: systemd
Version: 247.9-2+b1
Severity: normal

$ pkg-config --variable systemd_system_unit_dir systemd
/lib/systemd/system

This should be /usr/lib/systemd/system instead.  debhelper and lintian
now use/expect this path.  See:
  lintian-explain-tags systemd-service-in-odd-location
which references:
  * Bug#992465
  * Bug#987989
  * 
https://salsa.debian.org/debian/debhelper/-/commit/d70caa69c64b124e3611c967cfab93aef48346d8

  * https://lists.debian.org/debian-devel/2021/08/msg00275.html

I am the maintainer for ntpsec.  Upstream ntpsec uses pkg-config to
determine the proper path for unit files, because historically RedHat
and Debian differed.  If Debian now wants to prefer
/usr/lib/systemd/system over /lib/systemd/system, then the installed
systemd.pc file should be adjusted accordingly.

--
Richard

Bug#988696: connman does not respect /etc/network/interfaces when upgrading from buster to bullseye and more general considerations

[Michael Biebl]

Am 23.09.21 um 20:17 schrieb Holger Wansing:


I have just installed an LXDE system to test this, and now adding
network-manager-gnome, installs 24 new packages, taking 39 MB of additional
disk space, according to the apt-get output 
I might consider splitting off network-manager's /usr/share/locale into 
an (optional, Recommends/Suggests) network-manager-l10n package. The 
locales take up about 8,5 MB of disk space.
While I don't necessarily think that 8,5 MB are actually that much of an 
issue for desktop installations, trimming down the on disk footprint 
might make network-manager more suitable for more constrained environments.


There is also a (somewhat stale) MR [1] for network-manager asking for 
the individual plugins to be split into separate packages to make it 
possible to trim down the dependency chain.


If there is real demand for it, we could revisit that.


Michael

[1] https://salsa.debian.org/utopia-team/network-manager/-/merge_requests/4



OpenPGP_signature
Description: OpenPGP digital signature

Bug#995088: dnsmasq: Dnsmasq package doesn't include dnsmasq binaries

[Biprodeep]

Package: dnsmasq
Version: 2.80-1+rpt1+deb10u1
Severity: important

Dear Maintainer,

Dnsmasq which was installed from raspbian repository with exact debian version:
 
dnsmasq_2.80-1+rpt1+deb10u1_all.deb

doesn't include any dnsmasq binaries i.e. the /usr/sbin or /usr/bin directories 
were not packaged and pushed upstream.

-- System Information:
Distributor ID: Raspbian
Description:Raspbian GNU/Linux 10 (buster)
Release:10
Codename:   buster
Architecture: aarch64

Kernel: Linux 5.10.63-v8+ (SMP w/4 CPU cores; PREEMPT)
Kernel taint flags: TAINT_CRAP
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages dnsmasq depends on:
ii  dnsmasq-base [dnsmasq-base]  2.80-1+rpt1
ii  init-system-helpers  1.56+nmu1
ii  lsb-base 10.2019051400+rpi1
ii  netbase  5.6

dnsmasq recommends no packages.

Versions of packages dnsmasq suggests:
ii  openresolv [resolvconf]  3.8.0-1

-- no debconf information

Bug#995074: ITP: ruby-humanize -- A gem that converts numbers to strings

[Mohd Bilal]

Package: wnpp
Severity: wishlist
Owner: Mohammed Bilal 

* Package name: ruby-humanize
  Version : 2.5.1
  Upstream Author : Ryan Bigg
* URL : https://github.com/radar/humanize/
* License : Expat
  Programming Lang: Ruby
  Description : Extension to Numeric to humanize numbers
 This gem converts 1001 -> "one thousand and one".
 
 This gem is a dependency of pupilfirst(pupilfirst.com)

Bug#995087: autoproject: autopkgtest fails since texinfo 3.8

[Hilmar Preusse]

Package: autoproject
Version: 0.20-13
Severity: important
Tags: patch

Dear Maintainer,

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

   * What led up to the situation?

Upload of texinfo 3.8. Last year the command @refill was moved to the list of
obsolete @-Commands see [1] . Now the autopkgtest of autoproject fails, b/c
it prints a warning message on stderr, see [2]:

autopkgtest [06:11:52]: test test:  - - - - - - - - - - results - - - - - - - - 
- -
test FAIL stderr: squeegee.texinfo:189: warning: @refill is 
obsolete.
autopkgtest [06:11:52]: test test:  - - - - - - - - - - stderr - - - - - - - - 
- -

The attached patch removes the @refill commands from the docs and fixes the
autopkgtest. I dit not check if the document rendering is somehow impacted.

Currently the new texinfo packages won't migrate to testing b/c of this
regression, so please be so kind to fix the issue.

Hilmar

[1] https://git.savannah.gnu.org/cgit/texinfo.git/plain/ChangeLog
[2] 
https://ci.debian.net/data/autopkgtest/testing/armhf/a/autoproject/15487918/log.gz

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

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

Versions of packages autoproject depends on:
ii  automake [automaken]  1:1.16.4-2

autoproject recommends no packages.

autoproject suggests no packages.
Index: autoproject-0.20/lib/cli/all/argp/program.texinfo
===
--- autoproject-0.20.orig/lib/cli/all/argp/program.texinfo	2001-02-28 02:49:38.0 +0100
+++ autoproject-0.20/lib/cli/all/argp/program.texinfo	2021-09-25 18:30:47.463527619 +0200
@@ -252,7 +252,7 @@
 If you find a bug in @command{#NAME#}, please send electronic mail to
 @email{#EEMAIL#}.  Include the version number, which you can find by
 running @w{@samp{#NAME# --version}}.  Also include in your message the
-output that the program produced and the output you expected.@refill
+output that the program produced and the output you expected.
 
 If you have other questions, comments or suggestions about
 @command{#NAME#}, contact the author via electronic mail to
Index: autoproject-0.20/lib/cli/all/none/program.texinfo
===
--- autoproject-0.20.orig/lib/cli/all/none/program.texinfo	2001-02-28 02:49:39.0 +0100
+++ autoproject-0.20/lib/cli/all/none/program.texinfo	2021-09-25 18:31:33.747498011 +0200
@@ -252,7 +252,7 @@
 If you find a bug in @command{#NAME#}, please send electronic mail to
 @email{#EEMAIL#}.  Include the version number, which you can find by
 running @w{@samp{#NAME# --version}}.  Also include in your message the
-output that the program produced and the output you expected.@refill
+output that the program produced and the output you expected.
 
 If you have other questions, comments or suggestions about
 @command{#NAME#}, contact the author via electronic mail to


signature.asc
Description: PGP signature

Bug#995073: gitlab: yarnpkg fails with error An unexpected error occurred: "Release not found: 2.4.2".

[Pirate Praveen]

On 25/9/21 11:11 PM, Ondrej Zary wrote:
> Package: gitlab
> Version: 13.12.9+ds1-1~fto10+1
> Severity: grave
> Justification: renders package unusable
>
> Dear Maintainer,
> installing gitlab 13.12.9+ds1-1~fto10+1 on buster amd64 fails with:
>
> Installing node modules...
> Resolving 2.4.2 to a url...
> error An unexpected error occurred: "Release not found: 2.4.2".
> info If you think this is a bug, please open a bug report with the 
> information provided in "/var/lib/gitlab/yarn-error.log".
> info Visit https://yarnpkg.com/en/docs/cli/policies for documentation about 
> this command.

yarn 3.0 needs nodejs 12. So this was a work around used to force yarn
2.x. Looks like there is no way to install 2.x versions of yarn anymore :(

So we will have to update minimum version of nodejs to 12 (already done
for latest versions in bullseye) and use yarn set version berry. I guess
you will have to use nodejs from official repos or we will have to
backport nodejs 12 to buster.




signature.asc
Description: OpenPGP digital signature

Bug#994551: libcifpp1: please split off static files to separate package

[Étienne Mollier]

Hi Nilesh,

Nilesh Patra, on 2021-09-25:
> 
> Hi Étienne, all,
> 
> > I took the liberty to implement the change you suggest, and push
> > to Salsa [1].
> 
> I do not see your changes on salsa, the last commit is 3 months old
> there.
> Did you forget to push?

Yes, I forgot, sorry about that; I just pushed as soon as I
realized it.

Thanks for the notice,  :)
-- 
  .''`.  Étienne Mollier 
 : :' :  gpg: 8f91 b227 c7d6 f2b1 948c  8236 793c f67e 8f0d 11da
 `. `'   sent from /dev/tty1, please excuse my verbosity
   `-


signature.asc
Description: PGP signature

Bug#995046: 3.2.3-7 fails with libc6-2.30

[Samuel Henrique]

Hello Eugene,

> > 1) Do you know how is it possible that you were running Debian testing
> > with libc6 2.30-4? Even Debian stable has a newer version, I believe
> > you could have missed running apt full-upgrade at some point.
>
>  I have several hosts with old kernels (like 4.17) and their headers,
>  and gcc-7, which are tied to libc6-2.30 by their dependences.
>  On "aptitude install libc6" first resolver's proposal was to remove
>  these packages. I agreed with this choice to install libc6-2.32.

Interesting, so I will assume the system is in a consistent state.

>  I have a copy of one such system on backup, it may be studied for
>  more details if need... However, it looks pointless, because support
>  for lchown() is definitely a new feature, so the right way, IMHO,
>  is to correct dependences for rsync package: "libc6 (>= 2.31)".

I don't think it's as simple as that, I understand your issue now, but
I wouldn't just bump the dependency requirement without understanding
it better.
As it stands now, the version requirement is automatically set by
debhelper, based on the symbols rsync uses.
The bug we are facing comes from libc6, as we can see in the upstream
bug report, and rsync is trying to workaround that issue (the patch I
introduced on 3.2.3-7).

> > 2) Is your system under a chroot and/or without /proc mounted?
>
>  No, fault happens with physical hosts (not VMs or containers),
>  where /proc is mounted. However, they are all running SysV init.

Cool, I think SysV init won't take a role in this, but good to know the details.

> > > Upgrade libc6 to 2.32-4 solves the problem.
> > That's the current version available in testing and unstable, so
> > anybody running those will be fine.
>
>  Right. I also have some similar hosts with libc-2.32, probably they were
>  upgraded to last version due to absence of old kernels, old gcc, etc.
>  Rsync runs fine on them.

Good to know.

> > If anything, 3.2.3-7 is fixing the very same issue you reported, which
> > should have been happening in rsync 3.2.3 + libc6 2.32 (but you
> > mention you had an older libc6).
> >
> > Overall I believe there might be something wrong in your system,
> > related to libc6.
>
>  Every system with periodic updates might have outdated packages,
>  generally it's not a problem (and should not be a problem) if binary API
>  is compatible and all package dependences are correct.

Having outdated packages is not a problem, but having only a subset of
them is an indicator of something wrong. Rsync 3.2.3-7 migrated to
testing after libc6 2.32, so this issue will not happen unless the
person purposely holds libc back. I thought your system was running
like that by accident.
I'm not judging here, I just meant to explain that the trigger to the
issue will not affect every Debian user.

My current guess is that rsync's workaround accidentally moved the
regression from libc 2.32 to libc < 2.32. I've added a comment to
rsync's issue, you can follow the discussion there as well:
https://github.com/WayneD/rsync/issues/109

To be clear, I agree that as it stands right now, rsync should depend
on libc >= 2.32, but I don't wanna make this change before confirming
with upstream that this is not being caused by a regression from the
workaround.
Being able to keep the current version requirement will be important
in the long term as I want to be able to upload new releases to
backports. I also think that there's a chance rsync's upstream solves
the new regression soon (if confirmed), which would deem the version
bump unneeded.

What do you think?

Thank you,

-- 
Samuel Henrique 

Bug#995053: dh_assistant command for listing installed files

[Niels Thykier]

Control: tags -1 moreinfo

Jelmer Vernooij:
> Package: debhelper
> Version: 13.5.2
> Severity: wishlist
> 
> Dear debhelper maintainers,
> 
> For lintian-brush, it would be really useful if it was possible to discover
> which patterns it would be installing, why and where.
> 
> I have no idea how hard this would be to implement, and whether this
> information is readily available in debhelper - but figured it's at least 
> worth
> starting the discussion and seeing where it goes. I suspect there are some
> corner cases where it's impossible to discover like where dh-exec is in use
> (but even some information would be great).
> 
> I imagine something like a "dh_assistant installed-files" that then reports:
> 
> [...]

I can definitely see how that would be interesting to you.
Unfortunately, debhelper is a bunch of "black box" tools that knows
nothing about each other. Even figuring out which dh_tools will be run
is non-trivial (but I might be able to do that).

The best I can offer is a "post build" list of which tools installed
what where.  But I am pretty sure that would not be helpful to your case
(because that would be "did install" and not "would install").

Even if I did find a solution, it would rely on each tool "helping out"
somehow.  In other words, the solution would be incomplete or "unsafe"
with third party tools involved (or both).


Can you describe the use cases where you see the use for this?  Maybe we
can meet somewhere in the middle for them.

~Niels

Bug#993564: bullseye-pu: package dlt-viewer/2.21.2+dfsg-2+deb11u1

[Gianfranco Costamagna]

control: tags -1 -moreinfo

On Tue, 7 Sep 2021 14:40:34 +0100 Jonathan Wiltshire  wrote:
> Control: tag -1 confirmed moreinfo
> 
> On Fri, Sep 03, 2021 at 08:48:41AM +0200, Gianfranco Costamagna wrote:
> > Hello, for some reasons some headers in the -dev file were not
> > installed, leading to an error in building external plugins.
> > I opened RC: #993562 to track this issue, and I would like to fix also
> > bullseye since the fix is trivial
> 
> I'm fine with this change, but your changelog doesn't mention the bug
> number that it fixes and you uploaded a binary amd64 package with it. I'm
> not bothered by the binary package but I do want the changelog fixed, so we
> may as well do both.
> 
> You will receive a REJECT message from the archive. Once you have that,
> please re-upload with the changelog updated and make it a source-only
> upload. Then remove the wontfix tag from this request bug.
> 

thanks!

reuploaded

Gianfranco

Bug#995085: dlt-viewer: missing installed headers in -dev packages

[Gianfranco Costamagna]

Source: dlt-viewer
Version: 2.21.2+dfsg-2
Severity: serious
tags: patch
Fixed: 2.21.2+dfsg-3

Hello, the package doesn't install lots of header files, see 
https://bugs.debian.org/993564 for more information.

G.

Bug#995084: mnemosyne: After installing, Mnemosyne fails to start: fails to import PasswordHasher from argon2

[Kit Haines]

Package: mnemosyne
Version: 2.8+ds1-1
Severity: important

Dear Maintainer,

I just installed mnemosyne on my machine.  When I launch it (mnemosyne & in the 
terminal), I get the following message:

kit@gelfly:~/writing/al$ mnemosyne &
[1] 466123
kit@gelfly:~/writing/al$ Log body:
 An unexpected error has occurred.
Please forward the following info to the developers:

Traceback (innermost last):
  File "/usr/bin/mnemosyne", line 278, in 
mnemosyne.initialise(data_dir=data_dir, filename=filename,
  File "/usr/lib/python3/dist-packages/mnemosyne/libmnemosyne/__init__.py", 
line 400, in initialise
self.register_components()
  File "/usr/lib/python3/dist-packages/mnemosyne/libmnemosyne/__init__.py", 
line 465, in register_components
importlib.import_module(module_name), class_name)
  File "/usr/lib/python3.9/importlib/__init__.py", line 127, in import_module
return _bootstrap._gcd_import(name[level:], package, level)
  File "", line 1030, in _gcd_import
  File "", line 1007, in _find_and_load
  File "", line 986, in _find_and_load_unlocked
  File "", line 680, in _load_unlocked
  File "", line 850, in exec_module
  File "", line 228, in _call_with_frames_removed
  File "/usr/lib/python3/dist-packages/mnemosyne/pyqt_ui/qt_sync_server.py", 
line 15, in 
from mnemosyne.libmnemosyne.sync_server import SyncServer
  File "/usr/lib/python3/dist-packages/mnemosyne/libmnemosyne/sync_server.py", 
line 9, in 
from argon2 import PasswordHasher
 ImportError: cannot import name 'PasswordHasher' from 'argon2' 
(/home/kit/.local/lib/python3.9/site-packages/argon2.py)

An unexpected error has occurred.
Please forward the following info to the developers:

Traceback (innermost last):
  File "/usr/bin/mnemosyne", line 278, in 
mnemosyne.initialise(data_dir=data_dir, filename=filename,
  File "/usr/lib/python3/dist-packages/mnemosyne/libmnemosyne/__init__.py", 
line 400, in initialise
self.register_components()
  File "/usr/lib/python3/dist-packages/mnemosyne/libmnemosyne/__init__.py", 
line 465, in register_components
importlib.import_module(module_name), class_name)
  File "/usr/lib/python3.9/importlib/__init__.py", line 127, in import_module
return _bootstrap._gcd_import(name[level:], package, level)
  File "", line 1030, in _gcd_import
  File "", line 1007, in _find_and_load
  File "", line 986, in _find_and_load_unlocked
  File "", line 680, in _load_unlocked
  File "", line 850, in exec_module
  File "", line 228, in _call_with_frames_removed
  File "/usr/lib/python3/dist-packages/mnemosyne/pyqt_ui/qt_sync_server.py", 
line 15, in 
from mnemosyne.libmnemosyne.sync_server import SyncServer
  File "/usr/lib/python3/dist-packages/mnemosyne/libmnemosyne/sync_server.py", 
line 9, in 
from argon2 import PasswordHasher
 ImportError: cannot import name 'PasswordHasher' from 'argon2' 
(/home/kit/.local/lib/python3.9/site-packages/argon2.py)

[1]+  Exit 1  mnemosyne
kit@gelfly:~/writing/al$ 

I also get a window pop-up, with the same error as above showing.

I've tried installing argon2 with pip, to no change in the error message,

Best regards,
- Kit

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

Kernel: Linux 5.10.0-7-amd64 (SMP w/8 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 /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages mnemosyne depends on:
ii  libjs-sphinxdoc 3.5.4-2
ii  libqt5sql5-sqlite   5.15.2+dfsg-12
ii  python3 3.9.2-3
ii  python3-cheroot 8.5.2+ds1-3
ii  python3-cherrypy3   18.6.1-2
ii  python3-gtts2.0.3-1
ii  python3-matplotlib  3.3.4-1
ii  python3-pil 8.1.2+dfsg-0.3
ii  python3-pyqt5   5.15.4+dfsg-3
ii  python3-pyqt5.qtsql 5.15.4+dfsg-3
ii  python3-pyqt5.qtwebchannel  5.15.4+dfsg-3
ii  python3-pyqt5.qtwebengine   5.15.4-2+b1
ii  python3-webob   1:1.8.6-1.1

mnemosyne recommends no packages.

mnemosyne suggests no packages.

-- no debconf information

Bug#995070: ITP: ruby-attribute-normalizer -- A gem that adds the ability to normalize attributes

[Mohd Bilal]

Package: wnpp
Severity: wishlist
Owner: Mohammed Bilal 

* Package name: ruby-attribute-normalizer
  Version : 1.2.0
  Upstream Author : Michael Deering
* URL : https://github.com/mdeering/attribute_normalizer
* License : Expat
  Programming Lang: Ruby
  Description : Adds the ability to normalize attributes
 This gem adds the ability to normalize attributes cleanly with code blocks
 and predefined normalizers.
 
 This gem is a dependency of pupilfirst(pupilfirst.com)

Bug#988696: No network management in LXDE task

[Michael Biebl]

Am 25.09.21 um 22:05 schrieb Holger Wansing:

Control: retitle -1 LXDE: Please include a user-friendly network management tool
Control: tags -1 + patch


[ Returning back to #988696 as the correct bug for this issue; dropping 994875 
from CC ]

Jaycee Santos  wrote (Thu, 23 Sep 2021 20:42:05 +):

On Thursday, September 23rd, 2021 at 1:05 PM, Michael Biebl  
wrote:

Am 23.09.21 um 21:35 schrieb Jaycee Santos:

  Is there a reason why to choose gnome-network-manager over something like
  nm-tray for LXDE?


I think nm-tray (being based on Qt5) is a reasonable choice for LXQT (which is 
also Qt5 based). LXDE on the other hand uses GTK, so I think 
network-manager-gnome is a better fit there. (both disk footprint and memory 
usage wise)


Ah. My apologies. I thought nm-applet was provided by nm-tray. I was wrong.
I did not know that nm-applet was part of network-manager-gnome!

So I agree with network-manager-gnome being a better fit for LXDE.


Regarding LXQT: this DE already installs cmst by default (an Qt based
GUI for connman, which also has a system tray icon), and since there were
no complains so far from LXQT users related to the network management tool
used, I would not touch LXQT for this.


A patch to address this issue for LXDE is attached.



So now you have 3 network configuration systems involved:

- ifupdown, which is still installed by default
- connman, which is pulled in by the lxde package (via connman-gtk)
- network-manager(-gnome), which is pulled in via task-lxde-desktop

that doesn't sound like a good solution.



OpenPGP_signature
Description: OpenPGP digital signature

Bug#992847: systemd: systemctl preset-all fails to handle /lib/systemd -> /usr/lib/systemd transition

[Michael Biebl]

On Tue, 24 Aug 2021 10:07:59 +0200 Michael Prokop  wrote:
> Package: systemd
> Version: 247.9-1
> Severity: important
> 
> Hi,
> 
> this seems to be related to the "dh_installsystemd: Prefer
> /usr/lib/systemd/ to /lib/systemd" change from debhelper v13.4.
> 

Seems this change was reverted in debhelper 13.5.2 so I wonder what to do
about this bug report.

I guess the solution here is to wait for mandatory merged-/usr in bookworm,
in wich case this will be moot anyway.

I suppose, your Grml ISO build didn't have a merged-/usr file system, so the
/etc/systemd/system/syslog.service was dangling, pointing at a file 
/lib/systemd/system/rsyslog.service which was now
/usr/lib/systemd/system/rsyslog.service ?


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

Bug#995083: libavresample4: uninstallable because of a wrong dependency

[Xavier Brochard]

Package: libavresample4
Version: 7:4.3.2-0+deb11u2
Severity: important

Dear Maintainer,

This version depends on libavutil56 = 7:4.3.2-0+deb11u2 which is outdated and 
no more available
because current libavutil56 = 7:4.4-6 

Please update libavresample4 to 7:4.4-6

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

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

Versions of packages libavresample4 depends on:
ii  libavutil56  7:4.4-6+b2
ii  libc62.32-4

libavresample4 recommends no packages.

libavresample4 suggests no packages.

Bug#995014: linux/linux-signe-* break zfs-linux autopkgtest: None of the expected "capability" interfaces were detected

[Paul Gevers]

Hi,

On 24-09-2021 22:02, Salvatore Bonaccorso wrote:
> zfs-linux needs an update to be compatible with Linux 5.14 and above.
> This should be resolved in the 2.0.6 version upstream which was
> uploaded earlier to unstable, at least according to
> 
> https://github.com/openzfs/zfs/releases/tag/zfs-2.0.6

With version 2.0.6-1, the test still fails on ppc64el [1], but with a
different error. Please investigate.

Paul

[1]
https://ci.debian.net/data/autopkgtest/testing/ppc64el/z/zfs-linux/15513926/log.gz

ERROR: modpost: GPL-incompatible module zfs.ko uses GPL-only symbol
'mmu_feature_keys'



OpenPGP_signature
Description: OpenPGP digital signature

Bug#992914: libassa: FTBFS due to RPC removal from glibc

[Shane McDonald]

Thanks for the bug report and patch.  I've come up with an alternate patch
that only affects the utils/ directory.  This patch will show up in my
next upload in the next few days (currently on mentors.debian.net).

On Wed, 25 Aug 2021 00:03:42 +0200 Aurelien Jarno  wrote:
> Source: libassa
> Version: 3.5.1-7
> Severity: serious
> Tags: patch ftbfs
> Justification: fails to build from source (but built successfully in the past)
>
> The glibc SunRPC implementation has been marked obsolete for some time.
> It has been removed upstream from glibc 2.32, and it got disabled in the
> recent glibc uploads. The TI RPC implementation should be used instead.
>
> libassa was already supposed to use libtirpc, but in practice was still
> linked to glibc due a missing entry in Makefile.am. Please find attach a
> patch fixing the FTBFS.

Bug#995020: macaulay2: autopkgtest regression and flaky test: SIGSEGV

[Paul Gevers]

Hi Torrance,

On 25-09-2021 04:56, Torrance, Douglas wrote:
> There's a problem though -- this macaulay2 autopkgtest regression is now
> preventing ntl from migrating to testing! [1]  This seems like a chicken
> and
> egg situation -- we need it to migrate for the tests to pass, but we need
> the tests to pass for it to migrate...

I must confess that transitions aren't perfectly handled by the
migration software (britney) of the release team yet. britney tries to
figure which packages should come from unstable and adds them as pinned
packages, but hasn't any special notion of transitions.

> Is there a good solution for this?

Not yet.

> One very hacky idea would be to upload
> a new macaulay2 package with a very basic autopkgtest that's guaranteed to
> pass for the time being until everything migrates.  Is there a better
> solution?

Yes:
* macaulay2 could (temporarily) add *versioned* test dependencies on
libsingular4m1 and libflint-2.8.0 (then autopkgtest will do the right
thing).
* macaulay2 could add *versioned* dependencies on libsingular4m1 and
libflint-2.8.0
* I could manually trigger the test with the combination.

Let's pick the last option for now and see if it works.

Paul



OpenPGP_signature
Description: OpenPGP digital signature

Bug#995066: [debian-mysql] Bug#995066: mariadb-server: Incorrect warning about corrupt tables on mysql start

[Otto Kekäläinen]

Thanks for the report and patch!

Would you want to submit it as a MR at
https://salsa.debian.org/mariadb-team/mariadb-10.5 ?

Bug#989649: libjs-mathjax: integrate with dh_sphinxdoc

[Dmitry Shachnev]

Hi Drew, Antonio and all!

On Wed, Jun 09, 2021 at 03:13:47PM +0200, Drew Parsons wrote:
> Package: libjs-mathjax
> Version: 2.7.9+dfsg-1
> Severity: normal
>
> dh_sphinxdoc provides aids for automatically updating references to
> .js scripts used in docs generated through sphinx.  In particular it
> helps maintain privacy policies by removing the need to reference
> external websites such as
> https://cdnjs.cloudflare.com/ajax/libs/mathjax/2.7.9/MathJax.js
> from documentation.
>
> At the moment mathjax is not integrating into the dh_sphinxdoc
> capabilities. This means privacy hacks need to be made manually for
> every package that uses math formatting in its rst or md docs.
>
> Can mathjax be introduced to the dh_sphinxdoc system?

My recommendation is to add this line to your conf.py (using a patch):

  mathjax_path = 
'file:///usr/share/javascript/mathjax/MathJax.js?config=TeX-AMS-MML_HTMLorMML'

This is better than letting Sphinx generate URLs to some CDN and then
replacing them in dh_sphinxdoc. Any code to do automatic replacement is
error-prone, may not always detect the tags correctly, and may break
when something in Sphinx changes.

With this approach you will have correct URLs in tags from the very
beginning.

--
Dmitry Shachnev


signature.asc
Description: PGP signature

Bug#995082: atftp: [INTL:nl] Dutch translation of debconf messages

[Frans Spiesschaert]

 
 
Package: atftp 
Severity: wishlist 
Tags: l10n patch 
 
 
 
Dear Maintainer, 
 
 
Please find attached the updated Dutch translation of atftp debconf
messages. 
It has been submitted for review to the debian-l10n-dutch mailing list. 
Please add it to your next package revision. 
It should be put as debian/po/nl.po in your package build tree. 
 

-- 
Kind regards,
Frans Spiesschaert



nl.po.gz
Description: application/gzip

Bug#995081: mysql-8.0: [INTL:nl] Dutch translation of debconf messages

[Frans Spiesschaert]

 
 
Package: mysql-8.0 
Severity: wishlist 
Tags: l10n patch 
 
 
 
Dear Maintainer, 
 
 
Please find attached the updated Dutch translation of mysql-8.0 debconf
messages. 
It has been submitted for review to the debian-l10n-dutch mailing list. 
Please add it to your next package revision. 
It should be put as debian/po/nl.po in your package build tree. 
 

-- 
Kind regards,
Frans Spiesschaert



nl.po.gz
Description: application/gzip

Bug#995080: deborphan: [INTL:nl] Dutch translation for the deborphan package

[Frans Spiesschaert]

 
 
Package: deborphan 
Severity: wishlist 
Tags: l10n patch 
 
 
 
Dear Maintainer, 
 
 
Please find attached the updated Dutch po file for the deborphan package. 
It has been submitted for review to the debian-l10n-dutch mailing list. 
Please add it to your next package revision. 
It should be put as "po/nl.po" in your package build tree. 
 

-- 
Kind regards,
Frans Spiesschaert



nl.po.gz
Description: application/gzip

Bug#995079: Can't upgrade to upstream - no pybuild poetry support

[David Steele]

Package: aiofiles
Severity: important
Block: -1 by 984824
thanks

Upstream has replaced setup.{py|cfg} with a pyproject.toml 
configuration, using poetry. This is not yet supported by dh-python - 
pybuild does not recognize poetry, and cannot complete the build.


pybuild does support a toml build via flit. Looking at plugin_flit.py, 
it looks very much like a full PEP517 implementation, except that it 
looks explicitly for "flit" in the toml "build-system".


Why can't pybuild work with the same API that pip uses?

The workaround appears to be adding a patch to create a setup.py file. 
That seems like more than should be necessary.




OpenPGP_signature
Description: OpenPGP digital signature

Bug#995078: RFA: deluge -- bittorrent client written in Python/PyGTK

[Andrew Starr-Bochicchio]

Package: wnpp
Severity: normal

As neither Cristian nor myself have time to maintain
this package, I am requesting an adopter. I have also
filed an RFA for libtorrent-rasterbar which is an
essential dependency for deluge. Ideally, a new
maintainer would adopt both.

As I was not personally a user of the web front-end or
the daemon, there is a lot of room for improvement to
those parts of this package.

I'd be happy to sponsr uploads for any perspective
maintainers.

Thanks,

asb

Bug#995076: RFA: libtorrent-rasterbar - C++ bittorrent library

[Andrew Starr-Bochicchio]

Package: wnpp
Severity: normal

As neither Cristian nor myself have the time needed to
maintain this package anymore, I'm opening an RFA.

I am opening RFAs for both deluge and qbittorrent as
well. As these packages are both part of the libtorrent-rasterbar
ecosystem, ideally the adoptor would be someone interested
in maintaining those clients as well.

I'm happy to sponsor uploads for prospective new
maintainers.

Thanks,

asb

Bug#995077: RFA: qbittorrent -- bittorrent client based on libtorrent-rasterbar with a Qt5 GUI

[Andrew Starr-Bochicchio]

Package: wnpp
Severity: normal

As neither Cristian nor myself have time to maintain 
this package, I am requesting an adopter. I have also
filed an RFA for libtorrent-rasterbar which is an
essential dependency for qbittorent. Ideally, a new
maintainer would adopt both.

 
I'd be happy to sponsr uploads for any perspective 
maintainers.
 
Thanks,

asb

Bug#995075: bullseye-pu: package rsync/3.2.3-4+deb11u1

[Samuel Henrique]

Package: release.debian.org
User: release.debian@packages.debian.org
Usertags: pu
Tags: bullseye
X-Debbugs-Cc: samuel...@debian.org
Severity: normal

[ Reason ]
I would like to update rsync based on issues we detected after
releasing bullseye and on upstream commits done after 3.2.3 was
released.
Most of the changes are fixing regressions that showed up between the
version we ship in buster and the one we ship in bullseye. The ones
who don't fit into this category are either improvements to the docs
or bugs that existed before the version we have in buster.

[ Impact ]
There are multiple changes here, but the most impactful ones are
fixing regressions, thus the impact being that Debian users updating
from buster to bullseye could have unexpected breakages when using
rsync.

[ Tests ]
Some of the changes also contain their own tests, for the other ones I
manually tested to confirm they're working fine (most of the bug
reports from upstream had instructions on how to reproduce)

[ Risks ]
The risks are somewhat low as the changes were tested and they seem
well contained in their domains. As in, any possible breakages would
only affect those use cases and not extend to broader ones.

[ 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 ]
1) Re-add upstream patch for --copy-devices, the --write-devices
option is not fully equivalent (closes: #992215):
https://bugs.debian.org/992215
This change will require me to update the release notes, which I'll do
after the upload goes through:
https://www.debian.org/releases/stable/amd64/release-notes/ch-information.en.html#rsync-parameter-deprecation

2) d/rsync.docs: Add NEWS.md file (previously named NEWS) (closes: #993697):
Simple fix to a regression that happened when upstream renamed the file:
https://bugs.debian.org/993697

3) d/p/fix_delay_updates.patch: New patch from upstream (closes: #992231):
Pick upstream patch to fix a regression in the parameter --fix-delay,
the patch has a low footprint and comes with a unit test:
https://bugs.debian.org/992231
https://github.com/WayneD/rsync/issues/192

4) d/p/fix_mkpath.patch: New upstream patch to fix an edge case on --mkpath.
Fix an issue when using rsync with mkpath when the folder exists and
the file has a different name:
https://github.com/WayneD/rsync/issues/96

5) d/p/fix_rsync-ssl_RSYNC_SSL_CERT_feature: New upstream patch to fix
an edge case on rsync-ssl.
Fix a shellscript's simple mistake:
https://github.com/WayneD/rsync/commit/592c6bc3e5e93f36c2fdc0a491a9fb43a41cf688

6) d/p/fix_sparse_inplace.patch: New upstream patch to fix --sparse +
--inplace options.
Fix issue that happens when both --sparse and --inplace are used together:
https://github.com/WayneD/rsync/issues/114

7) d/p/manpage_upstream_fixes.patch: Import multiple upstream patches
to fix manpage.
I merged multiple manpage fixes from upstream into a single patch,
they should all be simple enough that no further details are needed.

8) d/p/update_rrsync_options.patch: New upstream patch to update rrsync options.
rrsync was a bit outdated with regards to the options it supported,
this simple patch updates it by adding support for the parameters
mkpath, msgs2stderr and no-msgs2stderr. Note that the patch only lets
rrsync receive those parameters, the support itself for those are
already implemented in rsync.

[ Other info ]
Due to the nature of change number 1, I would appreciate it if we
could ship this in time for 11.1.

Thank you,

--
Samuel Henrique 


rsync_3.2.3-4+deb11u1.debdiff
Description: Binary data

Bug#994971: NVENC issue

[Alejandro Bringas]

It has also affected the NVENC compatibility, using OBS-Studio it
simply does not detect it and gives an error when wanting to record,
it had to be reverted to the previous version.

Bug#995059: ITP: cubeb -- cross platform audio library

[Andrea Pappacoda]

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

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

* Package name: cubeb
  Version : 0.0~git20210801.6ce9596+ds-1
  Upstream Author : Mozilla Foundation
* URL : https://github.com/mozilla/cubeb
* License : ISC
  Programming Lang: C++, C
  Description : Cross platform audio library

cubeb is a cross platform audio library most notable for its use as the audio
backend within Gecko, Mozilla's browser engine. It supports multiple audio
backends and allows enumeration of audio devices and opening audio streams with
control over latency, sample rate and more.

This is a dependency of the yuzu emulator, see https://bugs.debian.org/947399

I'll upload the package to mentors soon.


-BEGIN PGP SIGNATURE-

iIoEARYIADIWIQRm3vFSgpkMIZnvqAGooSioqxzuSQUCYU8nlRQcYW5kcmVhQHBh
cHBhY29kYS5pdAAKCRCooSioqxzuSW64AQD24d7gTbE/jpXmO4uwIfqNvlvNkdy1
5vJuIk81nphCvgD+JcWY6C3kV7VM9O0BfAA/MoFjoBM+5mmnPbMzqEU5Wws=
=gpwq
-END PGP SIGNATURE-

Bug#995073: gitlab: yarnpkg fails with error An unexpected error occurred: "Release not found: 2.4.2".

[Ondrej Zary]

Package: gitlab
Version: 13.12.9+ds1-1~fto10+1
Severity: grave
Justification: renders package unusable

Dear Maintainer,
installing gitlab 13.12.9+ds1-1~fto10+1 on buster amd64 fails with:

Installing node modules...
Resolving 2.4.2 to a url...
error An unexpected error occurred: "Release not found: 2.4.2".
info If you think this is a bug, please open a bug report with the information 
provided in "/var/lib/gitlab/yarn-error.log".
info Visit https://yarnpkg.com/en/docs/cli/policies for documentation about 
this command.


-- System Information:
Debian Release: 10.10
  APT prefers oldstable-proposed-updates-debug
  APT policy: (500, 'oldstable-proposed-updates-debug'), (500, 
'oldstable-debug'), (500, 'oldstable'), (100, 'buster-fasttrack'), (100, 
'buster-backports')
Architecture: amd64 (x86_64)

Kernel: Linux 5.10.0-0.bpo.8-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=sk_SK.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: unable to detect

Versions of packages gitlab depends on:
ii  asciidoctor 2.0.10-2~bpo10+1
pn  bc  
ii  bundler 2.1.4-2~bpo10+1
ii  bzip2   1.0.6-9.2~deb10u1
pn  dbconfig-pgsql | dbconfig-no-t  
ii  debconf [debconf-2.0]   1.5.71
pn  gitlab-common   
pn  gitlab-workhorse
ii  libruby2.7 [ruby-rexml] 2.7.3-2~fto10+1
ii  lsb-base10.2019051400
ii  msmtp-mta [mail-transport-agen  1.8.3-1
ii  nginx-full [nginx]  1.14.2-2+deb10u4
pn  node-autosize   
pn  node-axios  
pn  node-babel-loader   
pn  node-babel-plugin-lodash
pn  node-babel7 
pn  node-bootstrap  
ii  node-brace-expansion1.1.8-1
ii  node-cache-loader   4.1.0-6~bpo10+1
pn  node-chart.js   
pn  node-clipboard  
pn  node-codemirror 
pn  node-compression-webpack-plugi  
pn  node-copy-webpack-plugin
ii  node-core-js3.6.1-2~bpo10+2
ii  node-css-loader 5.0.1+~cs14.0.5-1~bpo10+1
pn  node-d3 
pn  node-d3-scale   
pn  node-d3-selection   
pn  node-dateformat 
pn  node-exports-loader 
ii  node-file-loader6.2.0-2~bpo10+1
pn  node-font-awesome   
pn  node-fuzzaldrin-plus
ii  node-glob   7.1.6-1~bpo10+1
ii  node-imports-loader 0.8.0-2~bpo10+1
pn  node-jed
ii  node-jquery 3.5.1+dfsg-4~bpo10+1
pn  node-jquery-ujs 
pn  node-js-cookie  
ii  node-js-yaml3.13.1+dfsg-2~bpo10+1
pn  node-jszip  
pn  node-jszip-utils
pn  node-katex  
ii  node-lodash 4.17.21+dfsg+~cs8.31.189.20210220-1~bpo10+1
pn  node-marked 
pn  node-mermaid
ii  node-minimatch  3.0.4-3
pn  node-mousetrap  
pn  node-pdfjs-dist 
pn  node-popper.js  
pn  node-prismjs
pn  node-prosemirror-markdown   
pn  node-prosemirror-model  
pn  node-raven-js   
ii  node-raw-loader 4.0.2-2~bpo10+1
pn  node-style-loader   
pn  node-three-orbit-controls   
pn  node-three-stl-loader   
ii  node-timeago.js 4.0.2-2~bpo10+1
pn  node-underscore 
ii  node-url-loader 4.1.1-3~bpo10+1
ii  node-uuid   8.3.2+~8.3.0-1~bpo10+1
pn  node-vue
pn  node-vue-resource   
pn  node-vue-template-compiler  
pn  node-webpack-stats-plugin   
ii  node-worker-loader  3.0.5-2~bpo10+1
pn  node-xterm  
ii  nodejs  10.24.0~dfsg-1~deb10u1
pn  ohai
ii  openssh-client  1:7.9p1-10+deb10u2
ii  postgresql-client   11+200+deb10u4
ii  postgresql-client-11 [postgres  11.12-0+deb10u1
pn  postgresql-contrib  
pn  puma
ii  rake12.3.1-3+deb10u1
pn  redis-server
pn  ruby-ace-rails-ap   
pn  ruby-acme-client
ii  ruby-actioncable [node-rails-a  2:6.0.3.7+dfsg-1~fto10+1
pn  ruby-activerecord-explain-anal  
ii  ruby-acts-as-taggable-on7.0.0-1~bpo10+1
pn  ruby-addressable
ii  ruby-akismet3.0.0-1~bpo10+1
pn  ruby-apollo-upload-server   
ii  ruby-asana  0.10.3-1~bpo10+1
pn  ruby-asciidoctor-include-ext
pn  ruby-asciidoctor-kroki  
ii  ruby-asciidoctor-plantuml   0.0.12-1~bpo10+1
pn  

Bug#995072: nmu: tripwire_2.4.3.7-3

[Russ Allbery]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: binnmu
X-Debbugs-Cc: 994...@bugs.debian.org

tripwire now segfaults when it tries to read information about a file.
Rebuilding the package from source makes the problem go away.  The
problem appeared to start after the libc6 update to 2.32.

I suspect this is because tripwire is statically linked, and there are
known issues with static linking with libc6 across version releases
because the internal API to nsswitch modules changes.  This is
consistent with the pattern of segfaults, since it appears to happen
around the point where tripwire would try to resolve a numeric UID or
GID to a name.  If this is correct, a binNMU against the latest libc6
should fix the problem.

I have tested this by rebuilding the source package with no changes
in a sid chroot and confirmed the resulting package works correctly.

nmu tripwire_2.4.3.7-3 . ANY . unstable . -m "Rebuild with libc6 2.32"

Bug#995071: argyll: USB devices not found on big-endian (powerpc)

[Wyatt Ward]

Package: argyll
Version: 2.2.0+repack-1
Severity: important
Tags: upstream

Dear Maintainer,

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

After installing argyll and enabling the appropriate udev rules, argyll fails
to enumerate USB-based colorimeters and spectrometers on PowerPC
(big-endian, 32-bit).

Specifically, 'spotread -?' does not list any usb devices connected to the
system.

I can find no means of debugging why the device (an i1Display Pro Plus) fails
to be detected, but it enumerates fine on my i386 and amd64 machines with the
same udev rules.

Manually setting the permissions on the appropriate /dev/bus/usb/*/* node does
not fix things, either, so I am relatively sure this is not a simple
permissions problem.

I suspect that USB PID's and Vendor ID's are being read in an endian-specific
(and incorrect) manner.

Argyll should be able to run on big-endian machines as well as little-endian
ones. The only way I was able to profile this machine was to run Argyll on
an i386 system with X forwarding to the powerbook's display.

As a side-note, I noticed that my argyll-ref package was out of date when
I ran reportbug; I just upgraded it to 2.2.0+repack-1 and nothing changed.

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

Kernel: Linux 5.13.0-rc2-wyatt
Kernel taint flags: 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 /bin/dash
Init: sysvinit (via /sbin/init)
LSM: AppArmor: enabled

Versions of packages argyll depends on:
ii  argyll-ref   2.0.1+repack-2
ii  libc62.31-12
ii  libjpeg62-turbo  1:2.0.6-2
ii  libpng16-16  1.6.37-3
ii  libssl1.11.1.1k-1
ii  libtiff5 4.2.0-1
ii  libx11-6 2:1.7.1-1
ii  libxext6 2:1.3.3-1.1
ii  libxinerama1 2:1.1.4-2
ii  libxrandr2   2:1.5.1-1
ii  libxss1  1:1.2.3-1
ii  libxxf86vm1  1:1.1.4-1+b2

Versions of packages argyll recommends:
ii  libpam-elogind-compat [libpam-systemd]  1.3
ii  udev247.3-1

Versions of packages argyll suggests:
pn  argyll-doc
ii  colord1.4.5-3
pn  gir1.2-colordgtk-1.0  

-- no debconf information

Bug#993655: gnome-shell 3.38.6-1~deb11u1 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 993655 = bullseye pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian bullseye.

Thanks for your contribution!

Upload details
==

Package: gnome-shell
Version: 3.38.6-1~deb11u1

Explanation: new upstream stable release; fix freeze after cancelling (some) 
system-modal dialogs; fix word suggestions in on-screen keyboard; fix crashes

Bug#993656: mutter 3.38.6-2~deb11u1 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 993656 = bullseye pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian bullseye.

Thanks for your contribution!

Upload details
==

Package: mutter
Version: 3.38.6-2~deb11u1

Explanation: new upstream stable release; kms: Improve handling of common video 
modes that might exceed the possible bandwidth; ensure valid window texture 
size after viewport changes

Bug#993396: flatpak 1.10.3-0+deb11u1 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 993396 = bullseye pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian bullseye.

Thanks for your contribution!

Upload details
==

Package: flatpak
Version: 1.10.3-0+deb11u1

Explanation: new upstream stable release; don't inherit an unusual 
$XDG_RUNTIME_DIR setting into the sandbox

Bug#994628: gexiv2: Please package 0.12.2 or higher

[Jacob Boerema]

On Sat, 18 Sep 2021 19:02:16 -0400 Jeremy Bicha  
wrote:
> Please package the new version of gexiv2.

For GIMP master branch we are also waiting for at least version 0.12.2 to 
land. We have a long standing bug with many duplicates that requires 0.12.2, 
see:

https://gitlab.gnome.org/GNOME/gimp/-/issues/5863

--
Jacob Boerema

Bug#993898: btrbk 0.27.1-1+deb10u1 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 993898 = buster pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian buster.

Thanks for your contribution!

Upload details
==

Package: btrbk
Version: 0.27.1-1+deb10u1

Explanation: fix arbitrary code execution issue [CVE-2021-38173]

Bug#993228: gthumb 3.6.2-4+deb10u1 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 993228 = buster pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian buster.

Thanks for your contribution!

Upload details
==

Package: gthumb
Version: 3.6.2-4+deb10u1

Explanation: fix heap-based buffer overflow issue [CVE-2019-20326]

Bug#991768: wireguard-dkms: wireguard-dmks autoinstall fails, not matching BUILD_EXCLUSIVE directive in Bullesye

[Dario Andres Susman]

Package: wireguard-dkms
Version: 1.0.20210219-1
Followup-For: Bug #991768

Still an issue. However, wireguard works.

root@fgx-laptop:~# dpkg-reconfigure wireguard-dkms

--
Deleting module version: 1.0.20210219
completely from the DKMS tree.
--
Done.
Loading new wireguard-1.0.20210219 DKMS files...
Building for 5.10.0-8-amd64
Building initial module for 5.10.0-8-amd64
Error!  The 
/var/lib/dkms/wireguard/1.0.20210219/5.10.0-8-amd64/x86_64/dkms.conf for module 
wireguard includes a BUILD_EXCLUSIVE directive which
does not match this kernel/arch.  This indicates that it should not be built.
Skipped.
root@fgx-laptop:~# 

Best regards,

Dario Susman


-- System Information:
Debian Release: 11.0
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (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_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB:en
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages wireguard-dkms depends on:
ii  dkms  2.8.4-3
ii  perl  5.32.1-4+deb11u1

Versions of packages wireguard-dkms recommends:
ii  wireguard1.0.20210223-1
ii  wireguard-tools  1.0.20210223-1

wireguard-dkms suggests no packages.

-- no debconf information

Bug#993034: sabnzbdplus 2.3.6+dfsg-1+deb10u2 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 993034 = buster pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian buster.

Thanks for your contribution!

Upload details
==

Package: sabnzbdplus
Version: 2.3.6+dfsg-1+deb10u2

Explanation: prevent directory escape in renamer function [CVE-2021-29488]

Bug#992863: modsecurity-crs 3.1.0-1+deb10u2 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 992863 = buster pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian buster.

Thanks for your contribution!

Upload details
==

Package: modsecurity-crs
Version: 3.1.0-1+deb10u2

Explanation: fix request body bypass issue [CVE-2021-35368]

Bug#994969: jackd2: segfaults after today's upgrade of other Debian testing packages

[Sebastian Ramacher]

On 2021-09-25 15:31:31 +0200, Francesco Poli wrote:
> On Sat, 25 Sep 2021 12:25:16 +0200 Sebastian Ramacher wrote:
> 
> [...]
> > So this is crashing somewhere during the initialization of libglibmm.
> > Hence I'm reassigning to libglibmm.
> [...]
> 
> Thanks, Sebastian!
> 
> 
> By the way, I am now wondering whether I really need jackd2-firewire.
> Maybe I can keep it out of my system, even after this bug gets fixed?!?
> I don't think I have a FireWire port, hence maybe the JACK FireWire
> support is useless to me.
> Could you please confirm?

If you don't have a firewire port, then jackd2-firewire is of no use.

Cheers

> 
> -- 
>  http://www.inventati.org/frx/
>  There's not a second to spare! To the laboratory!
> . Francesco Poli .
>  GnuPG key fpr == CA01 1147 9CD2 EFDF FB82  3925 3E1C 27E1 1F69 BFFE



-- 
Sebastian Ramacher


signature.asc
Description: PGP signature

Bug#995006: init-system-helpers: deb-systemd-helper does not call daemon-reload despite unit files were changed

[Vasyl Gello]

> Again, you you have any bug reports where users actually ask for this?

No, I am experiencing this as a user who builds development version of Xpra for 
company and personal use.
Version 4.x is not in Debian yet, and I haven't seen any reports from users 
making use of Xpra proxy server on Debian yet.
-- 
Vasyl Gello
==
Certified SolidWorks Expert

Mob.:+380 (98) 465 66 77

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

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

Bug#995006: init-system-helpers: deb-systemd-helper does not call daemon-reload despite unit files were changed

[Michael Biebl]

Am 25.09.21 um 18:46 schrieb Vasyl Gello:

Hi Michael,

 >daemon-reload is a costly operation, so we should try to avoid calling it
too excessively.
 >
 >So I'm not convinced it is a good idea to generate a daemon-reload (via
dh_installsystemd in postinst) for packages which do not actually (re)start
a unit as part of the upgrade process.
 >
 >By using "--no-enable --no-start" you are basically leaving the
management of the life cycle of the service entirely to the administrator.
Wouldn't you agree?
 >
 >Shouldn't the administrator then call "systemctl daemon-reload" as well?
 >systemd will even warn him in cases a .service file has changed (which
thankfully doesn't happen too often)
 >
 >Is this actually an issue in practice? Do you have bug reports where
users of your xpra package have asked for this?

I realize daemon-reload is a costly operation, and I also realize the unit
in question is used by proxy module of Xpra, which is optional.

That's why Dmitry intentionally left it for system administrators to
configure.

Your point that typically units are not changed daily is also perfectly
valid.

However, speaking of "Shouldn't the administrator then call "systemctl 
daemon-reload" as well?"…
No, if one uses unattended-upgrades or any other automation like auter 
or puppet etc.


Server gets rebooted or service gets restarted and start-up fails due to 
requirement of
"daemon-reload" or worse, starts with previous configuration which fails 
too.


A reboot is not relevant here.
And if you use an automation framework like puppet, you can just as well 
add a daemon-reload there if you manage the service via puppet.


What I suggest is slightly different Debian-wise. We do have list of 
conffiles and list of files
installable by the package. What prevents us from scanning the list for 
known locations
of systemd units ({/usr}/lib/systemd/{system,user}?) and compare them by 
hash or by diff
just like we do it with conffiles? If the units, timers, etc differ, we 
call daemon-reload and
issue a warning to stderr so both user or script catches it. Of course 
it may need some additions
to dpkg and debhelper (or to plain debhelper only?) but this issue will 
be eradicated for all packages

rebuilt after the update.


systemd already warns you, if you (manually) try to restart a service 
that has been modified on disk.

So I don't see the use case here.

Again, you you have any bug reports where users actually ask for this?




OpenPGP_signature
Description: OpenPGP digital signature

Bug#995006: init-system-helpers: deb-systemd-helper does not call daemon-reload despite unit files were changed

[Vasyl Gello]

Hi Michael,

>daemon-reload is a costly operation, so we should try to avoid calling it 
too excessively.
>
>So I'm not convinced it is a good idea to generate a daemon-reload (via 
dh_installsystemd in postinst) for packages which do not actually (re)start 
a unit as part of the upgrade process.
>
>By using "--no-enable --no-start" you are basically leaving the 
management of the life cycle of the service entirely to the administrator. 
Wouldn't you agree?
>
>Shouldn't the administrator then call "systemctl daemon-reload" as well?
>systemd will even warn him in cases a .service file has changed (which 
thankfully doesn't happen too often)
>
>Is this actually an issue in practice? Do you have bug reports where 
users of your xpra package have asked for this?

I realize daemon-reload is a costly operation, and I also realize the unit
in question is used by proxy module of Xpra, which is optional.

That's why Dmitry intentionally left it for system administrators to 
configure.

Your point that typically units are not changed daily is also perfectly 
valid.

However, speaking of "Shouldn't the administrator then call "systemctl 
daemon-reload" as well?"… 
No, if one uses unattended-upgrades or any other automation like auter or 
puppet etc.

Server gets rebooted or service gets restarted and start-up fails due to 
requirement of
"daemon-reload" or worse, starts with previous configuration which fails too.

What I suggest is slightly different Debian-wise. We do have list of conffiles 
and list of files
installable by the package. What prevents us from scanning the list for known 
locations
of systemd units ({/usr}/lib/systemd/{system,user}?) and compare them by hash 
or by diff
just like we do it with conffiles? If the units, timers, etc differ, we call 
daemon-reload and
issue a warning to stderr so both user or script catches it. Of course it may 
need some additions
to dpkg and debhelper (or to plain debhelper only?) but this issue will be 
eradicated for all packages
rebuilt after the update.

Of course I can implement the same check in postinst script of Xpra, but I 
decided to discuss
my idea with involved colleagues.

What do you think?
-- 
Vasyl Gello
==
Certified SolidWorks Expert

Mob.:+380 (98) 465 66 77

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

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

Bug#993236: Acknowledgement (calibre: in calibredb --timeout parameter seems to be ignored)

[Kamil Jońca]

I do not know how to classify it.
It seems that calibredb timeout is determined by timeout setting at
calibre server side.
I.e if I set at server side I set timeout to 600 seconds calibredb
started to behave as expected.
So maybe calibredb behaviour is correct, but information about server
timeout should be put in calibredb manual.


KJ

-- 
http://stopstopnop.pl/stop_stopnop.pl_o_nas.html

Bug#995050: ecere-sdk FTBFS with gcc 10

[Jérôme St-Louis]

Thank you Adrian for reporting this.

We have fixes for this upstream:

commit *c94efd6390599a4a291b7fe8b3d2d62699247380*
Author: Jerome St-Louis 
Date:   Sun Sep 6 03:35:01 2020 -0400

    compiler/bootstrap: Updated for GCC 10 Common fixes

commit *7d835dd5c6e17ad1626ec7b6f1725e0f7f8a9371*
Author: Rejean Loyer 
Date:   Mon Aug 3 13:18:51 2020 -0400

    compiler/ecs: add -no-attribute-common for targetting wasm. 
workaround "Common symbols are not yet implemented for Wasm" message 
coming from emscripten-releases\llvm-project\llvm\li

b\MC\MCWasmStreamer.cpp's MCWasmStreamer::emitCommonSymbol function.

commit *ca58cfa4e26e03271e32ee6aae3206956fdc26fd*
Author: Jerome St-Louis 
Date:   Wed May 20 07:25:49 2020 -0400

    compiler/libec: Fixed multiple definitions issues breaking on GCC 
10 without -fcommon


There is also a more recent commit fixes for GCC 11 which will surely 
show up sooner or later:


commit *53ec01de1c42cf342a35dc125a4fef01ffb5fced* (origin/master, master)
Author: Jerome St-Louis 
Date:   Thu Aug 5 21:07:56 2021 -0400

    compiler/libec/lexer.l: Initial fix for failure to build on GCC 11
    - bootstrap updated
    - # 0 instead of # 1 generated by preprocessor triggered problem in 
lexer's preprocessor()
    - NOTE: This was likely resulting in declMode, defaultDeclMode and 
structDeclMode not being set properly

    - It may also be related to #1135

There are other important fixes on master since 0.44.15, including fixes 
for #898832 .


In general, the master branch of our repo is currently (HEAD: 
53ec01de1c42cf342a35dc125a4fef01ffb5fced) very conservatively stable, 
and would be a good candidate for a patch 0.44.15 release.


On our side we are overdue for a new release, but we hope to bring in a 
lot of new improvements and functionality for the next 0.44.16 release, 
which is proving difficult to complete given that our development branch 
(/lates//t/) is now more than 1200 commits ahead of master. We are also 
quite busy with our geospatial software endeavours (making use of the 
Ecere SDK).


If someone is willing to help with the Debian packaging / update to 
close these bugs, myself and possibly others in our community will be 
more than happy to provide assistance and otherwise contribute to the 
effort.


Thank you!

Best regards,

-Jerome

On 9/25/21 6:27 AM, Adrian Bunk wrote:

Source: ecere-sdk
Version: 0.44.15-1
Severity: serious
Tags: ftbfs

https://buildd.debian.org/status/logs.php?pkg=ecere-sdk=0.44.15-1%2Bb4

...
gcc -Wl,-z,relro  -Wl,--no-undefined   -Wl,--no-undefined   -Wl,--no-undefined  
 -Wl,--no-undefined  -L../ecere/obj/bootstrap.linux 
-L../libec/obj/bootstrap.linux obj/bootstrap.linux/ecp.o 
obj/bootstrap.linux/ecp.main.o-lecereBootstrap -lecBootstrap -lm -ldl -o 
obj/bootstrap.linux/ecp
/usr/bin/ld: 
obj/bootstrap.linux/ecp.main.o:./compiler/bootstrap/ecp/bootstrap/ecp.main.c:52:
 multiple definition of 
`__ecereVMethodID___ecereNameSpace__ecere__sys__File_Eof'; 
obj/bootstrap.linux/ecp.o:./compiler/bootstrap/ecp/bootstrap/ecp.c:388: first 
defined here
/usr/bin/ld: 
obj/bootstrap.linux/ecp.main.o:./compiler/bootstrap/ecp/bootstrap/ecp.main.c:54:
 multiple definition of 
`__ecereVMethodID___ecereNameSpace__ecere__sys__File_Puts'; 
obj/bootstrap.linux/ecp.o:./compiler/bootstrap/ecp/bootstrap/ecp.c:384: first 
defined here
/usr/bin/ld: 
obj/bootstrap.linux/ecp.main.o:./compiler/bootstrap/ecp/bootstrap/ecp.main.c:56:
 multiple definition of 
`__ecereVMethodID___ecereNameSpace__ecere__sys__File_Read'; 
obj/bootstrap.linux/ecp.o:./compiler/bootstrap/ecp/bootstrap/ecp.c:390: first 
defined here
/usr/bin/ld: 
obj/bootstrap.linux/ecp.main.o:./compiler/bootstrap/ecp/bootstrap/ecp.main.c:58:
 multiple definition of 
`__ecereVMethodID___ecereNameSpace__ecere__sys__File_Seek'; 
obj/bootstrap.linux/ecp.o:./compiler/bootstrap/ecp/bootstrap/ecp.c:396: first 
defined here
/usr/bin/ld: 
obj/bootstrap.linux/ecp.main.o:./compiler/bootstrap/ecp/bootstrap/ecp.main.c:60:
 multiple definition of 
`__ecereVMethodID___ecereNameSpace__ecere__sys__File_Write'; 
obj/bootstrap.linux/ecp.o:./compiler/bootstrap/ecp/bootstrap/ecp.c:392: first 
defined here
...
/usr/bin/ld: 
../libec/obj/bootstrap.linux/libecBootstrap.a(shortcuts.o):./compiler/bootstrap/libec/bootstrap/shortcuts.c:298:
 multiple definition of 
`__ecereVMethodID___ecereNameSpace__ecere__sys__File_Write'; 
obj/bootstrap.linux/ecp.o:./compiler/bootstrap/ecp/bootstrap/ecp.c:392: first 
defined here
/usr/bin/ld: 
../libec/obj/bootstrap.linux/libecBootstrap.a(shortcuts.o):./compiler/bootstrap/libec/bootstrap/shortcuts.c:300:
 multiple definition of 
`__ecereVMethodID___ecereNameSpace__ecere__sys__File_Seek'; 
obj/bootstrap.linux/ecp.o:./compiler/bootstrap/ecp/bootstrap/ecp.c:396: first 
defined here
/usr/bin/ld: 
../libec/obj/bootstrap.linux/libecBootstrap.a(type.o):./compiler/bootstrap/libec/bootstrap/type.c:392:
 multiple definition of 
`__ecereVMethodID___ecereNameSpace__ecere__sys__File_Seek'; 

Bug#994910: tripwire segfaults while reading files in /etc

[Russ Allbery]

Package: tripwire
Version: 2.4.3.7-3+b3
Followup-For: Bug #994910

Reproduced here following a libc6 upgrade.  I suspect this is because
tripwire is statically linked and there has been a new release of libc6,
so I suspect the nsswitch interface has broken (which is a standard
problem with statically linking with libc6 on Linux).

This would also explain why rebuilding the package made the problem go
away.

If this is correct, a BinNMU should fix the problem.


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

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 not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages tripwire depends on:
ii  debconf [debconf-2.0]   1.5.77
ii  postfix [mail-transport-agent]  3.5.6-1+b1

tripwire recommends no packages.

tripwire suggests no packages.

-- Configuration Files:
/etc/tripwire/twcfg.txt changed [not included]
/etc/tripwire/twpol.txt changed [not included]

-- debconf information:
* tripwire/installed:
* tripwire/use-sitekey: true
  tripwire/local-passphrase-incorrect: false
  tripwire/broken-passphrase:
  tripwire/upgrade: true
  tripwire/email-report:
  tripwire/change-in-default-policy:
* tripwire/use-localkey: true
  tripwire/site-passphrase-incorrect: false
* tripwire/rebuild-config: true
* tripwire/rebuild-policy: true

Bug#993903: Acknowledgement (xfce4-session: After resuming from suspend, the synaptic touchpad was no longer working)

[Wirawan Purwanto]

Ok, I found the solution. With the "xinput" command, I got the following output:

/ Virtual core pointer id=2[master pointer  (3)]
|   +--> Virtual core XTEST pointerid=4[slave  pointer  (2)]
|   +--> HID 062a: id=13   [slave  pointer  (2)]
|   +--> Synaptics TM3053-004  id=12   [slave  pointer  (2)]
\ Virtual core keyboardid=3[master keyboard (2)]
+--> Virtual core XTEST keyboard   id=5[slave  keyboard (3)]
+--> Power Button  id=6[slave  keyboard (3)]
+--> Video Bus id=7[slave  keyboard (3)]
+--> Sleep Button  id=8[slave  keyboard (3)]
+--> Integrated Camera: Integrated C   id=9[slave  keyboard (3)]
+--> AT Translated Set 2 keyboard  id=10   [slave  keyboard (3)]
+--> ThinkPad Extra Buttonsid=11   [slave  keyboard (3)]

then the "xinput --list-props 12" command gives:

Device 'Synaptics TM3053-004':
Device Enabled (154):1
Coordinate Transformation Matrix (156):1.00, 0.00,
0.00, 0.00, 1.00, 0.00, 0.00, 0.00, 1.00
Device Accel Profile (286):1
Device Accel Constant Deceleration (287):2.50
Device Accel Adaptive Deceleration (288):1.00
Device Accel Velocity Scaling (289):12.50
Synaptics Edges (290):77, 1863, 57, 1005
Synaptics Finger (291):25, 30, 0
Synaptics Tap Time (292):180
Synaptics Tap Move (293):97
Synaptics Tap Durations (294):180, 180, 100
Synaptics ClickPad (295):1
Synaptics Middle Button Timeout (296):0
Synaptics Two-Finger Pressure (297):282
Synaptics Two-Finger Width (298):7
Synaptics Scrolling Distance (299):44, 44
Synaptics Edge Scrolling (300):0, 0, 0
Synaptics Two-Finger Scrolling (301):1, 0
Synaptics Move Speed (302):1.00, 1.75, 0.090457, 0.00
Synaptics Off (303):1
Synaptics Locked Drags (304):0
Synaptics Locked Drags Timeout (305):5000
Synaptics Tap Action (306):0, 0, 0, 0, 1, 3, 2
Synaptics Click Action (307):1, 3, 2
Synaptics Circular Scrolling (308):0
Synaptics Circular Scrolling Distance (309):0.10
Synaptics Circular Scrolling Trigger (310):0
Synaptics Circular Pad (311):0
Synaptics Palm Detection (312):0
Synaptics Palm Dimensions (313):10, 200
Synaptics Coasting Speed (314):20.00, 50.00
Synaptics Pressure Motion (315):30, 160
Synaptics Pressure Motion Factor (316):1.00, 1.00
Synaptics Grab Event Device (317):0
Synaptics Gestures (318):1
Synaptics Capabilities (319):1, 0, 0, 1, 1, 1, 0
Synaptics Pad Resolution (320):20, 20
Synaptics Area (321):0, 0, 0, 0
Synaptics Soft Button Areas (322):970, 0, 870, 0, 0, 0, 0, 0
Synaptics Noise Cancellation (323):11, 11
Device Product ID (278):1739, 0
Device Node (277):"/dev/input/event7"

Wait! Why the "Synaptics Off" value (property 303) is 1?? I turned
that off: "xinput set-prop 12 303 0"  -- and voila, the trackpad
worked again (mouse movement & taps).

So, the problem is solved! BUT there is a lingering question. Which
program turned off the touchpad and then not turn it on again? Here is
my theory: In the "Mouse and Touchpad" setting, I have the "Disable
touchpad while typing" option checked. I set a shortcut key to suspend
the laptop, calling "xfce4-session-logout -s" . Once this shortcut
combination was invoked, the suspend action began immediately, yet
there was not enough time for the touchpad to be re-enabled. As a
result, the trackpad was stuck in the "disabled" position even after
resuming from sleep.

So this should be filed as a bug with the XFCE4 settings daemon, I
think (xfce4-settings). The bugfix should be fairly easy, I suppose,
but it will require a hook that is invoked when the computer going to
sleep: when the touchpad is supposed to be disabled only temporarily,
it should be re-enabled upon resumption from sleep.

Wirawan

On Tue, Sep 7, 2021 at 6:27 PM Debian Bug Tracking System
 wrote:
>
> Thank you for filing a new Bug report with Debian.
>
> You can follow progress on this Bug here: 993903: 
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=993903.
>
> This is an automatically generated reply to let you know your message
> has been received.
>
> Your message is being forwarded to the package maintainers and other
> interested parties for their attention; they will reply in due course.
>
> As you requested using X-Debbugs-CC, your message was also forwarded to
>   wiraw...@gmail.com
> (after having been given a Bug report number, if it did not have one).
>
> Your message has been sent to the 

Bug#815231: cmake: FTBFS on kfreebsd, hurd: 2 tests fail: BuildDepends, RunCMake.Configure

[Timo Röhling]

Control: severity -1 wishlist

On Fri, 14 Oct 2016 14:03:48 -0400 Brad King  wrote:

FWIW I would not consider this test failure to be a blocking issue for
packaging a new CMake on this platform.  The behavior of this logic is
the same as it has been for years in CMake.  It is just that this test
case did not exist before.

Given this statement and the fact that the test failure seems to be
quite elusive and difficult to reproduce outside the buildd environment,
I ignored the failing tests for now.

I'll leave this bug open, as it is technically not fixed, but
drop the severity to wishlist.

Cheers
Timo

--
⢀⣴⠾⠻⢶⣦⠀   ╭╮
⣾⠁⢠⠒⠀⣿⡁   │ Timo Röhling   │
⢿⡄⠘⠷⠚⠋⠀   │ 9B03 EBB9 8300 DF97 C2B1  23BF CC8C 6BDD 1403 F4CA │
⠈⠳⣄   ╰╯


signature.asc
Description: PGP signature

Bug#990501: connman: Connman disrupted network during upgrade on system where it does not manage network

[Amy Kos]

Hi,

in case you have plasma-nm installed, cmst (connman) shouldn't have been 
installed at all.

Lxqt metapackage recommends cmst (connman) or nm-tray (network-manager) or 
network-manager-gnome (network-manager) or plasma-nm (network-manager) or wicd 
(wicd-daemon).

In case you have network-manager without plasma-nm installed, avoid the lxqt 
metapackage, or add network-manager to its recommends.

Cheers,
Amy

Bug#995069: libclc-12: tahiti-amdgcn-mesa-mesa3d.bc is missing

[Giuseppe Bilotta]

Package: libclc-12
Version: 1:12.0.1-9
Followup-For: Bug #993904

To add to this bug report, I'm getting a similer error message when trying to
use OpenCL on my machine, that has a Polaris10 card. Trying to run even just
clinfo gives the following error message:

=== CL_PROGRAM_BUILD_LOG ===
fatal error: cannot open file '/usr/lib/clc/polaris10-amdgcn-mesa-mesa3d.bc': 
No such file or directory

As it turns out, /usr/lib/clc _does_ contain the .bc files; however,
most of them are missing the 'mesa ' and/or 'mesa3d' part in the name,
as shown by this listing of the directory:

total 70M
drwxr-xr-x   2 root root 4.0K Sep 21 20:51 .
drwxr-xr-x 170 root root  36K Sep 24 22:14 ..
-rw-r--r--   1 root root 7.8M Sep 18 11:03 amdgcn--amdhsa.bc
lrwxrwxrwx   1 root root   16 Sep 18 11:03 aruba-r600--.bc -> cayman-r600--.bc
-rw-r--r--   1 root root 4.3M Sep 18 11:03 barts-r600--.bc
lrwxrwxrwx   1 root root   18 Sep 18 11:03 bonaire-amdgcn--.bc -> 
tahiti-amdgcn--.bc
lrwxrwxrwx   1 root root   15 Sep 18 11:03 caicos-r600--.bc -> barts-r600--.bc
lrwxrwxrwx   1 root root   18 Sep 18 11:03 carrizo-amdgcn--.bc -> 
tahiti-amdgcn--.bc
-rw-r--r--   1 root root 4.3M Sep 18 11:03 cayman-r600--.bc
-rw-r--r--   1 root root 4.3M Sep 18 11:03 cedar-r600--.bc
-rw-r--r--   1 root root 4.3M Sep 18 11:03 cypress-r600--.bc
lrwxrwxrwx   1 root root   18 Sep 18 11:03 fiji-amdgcn--.bc -> 
tahiti-amdgcn--.bc
lrwxrwxrwx   1 root root   18 Sep 18 11:03 gfx900-amdgcn--.bc -> 
tahiti-amdgcn--.bc
lrwxrwxrwx   1 root root   18 Sep 18 11:03 gfx902-amdgcn--.bc -> 
tahiti-amdgcn--.bc
lrwxrwxrwx   1 root root   18 Sep 18 11:03 gfx904-amdgcn--.bc -> 
tahiti-amdgcn--.bc
lrwxrwxrwx   1 root root   18 Sep 18 11:03 gfx906-amdgcn--.bc -> 
tahiti-amdgcn--.bc
lrwxrwxrwx   1 root root   18 Sep 18 11:03 hainan-amdgcn--.bc -> 
tahiti-amdgcn--.bc
lrwxrwxrwx   1 root root   18 Sep 18 11:03 hawaii-amdgcn--.bc -> 
tahiti-amdgcn--.bc
lrwxrwxrwx   1 root root   17 Sep 18 11:03 hemlock-r600--.bc -> 
cypress-r600--.bc
lrwxrwxrwx   1 root root   18 Sep 18 11:03 iceland-amdgcn--.bc -> 
tahiti-amdgcn--.bc
lrwxrwxrwx   1 root root   15 Sep 18 11:03 juniper-r600--.bc -> cedar-r600--.bc
lrwxrwxrwx   1 root root   18 Sep 18 11:03 kabini-amdgcn--.bc -> 
tahiti-amdgcn--.bc
lrwxrwxrwx   1 root root   18 Sep 18 11:03 kaveri-amdgcn--.bc -> 
tahiti-amdgcn--.bc
lrwxrwxrwx   1 root root   18 Sep 18 11:03 mullins-amdgcn--.bc -> 
tahiti-amdgcn--.bc
-rw-r--r--   1 root root 8.0M Sep 18 11:03 nvptx64--.bc
-rw-r--r--   1 root root 8.0M Sep 18 11:03 nvptx64--nvidiacl.bc
-rw-r--r--   1 root root 7.9M Sep 18 11:03 nvptx--.bc
-rw-r--r--   1 root root 7.9M Sep 18 11:03 nvptx--nvidiacl.bc
lrwxrwxrwx   1 root root   18 Sep 18 11:03 oland-amdgcn--.bc -> 
tahiti-amdgcn--.bc
lrwxrwxrwx   1 root root   15 Sep 18 11:03 palm-r600--.bc -> cedar-r600--.bc
lrwxrwxrwx   1 root root   18 Sep 18 11:03 pitcairn-amdgcn--.bc -> 
tahiti-amdgcn--.bc
lrwxrwxrwx   1 root root   18 Sep 18 11:03 polaris10-amdgcn--.bc -> 
tahiti-amdgcn--.bc
lrwxrwxrwx   1 root root   18 Sep 18 11:03 polaris11-amdgcn--.bc -> 
tahiti-amdgcn--.bc
lrwxrwxrwx   1 root root   15 Sep 18 11:03 redwood-r600--.bc -> cedar-r600--.bc
-rw-r--r--   1 root root 2.5M Sep 18 11:03 spirv64-mesa3d-.spv
-rw-r--r--   1 root root 2.5M Sep 18 11:03 spirv-mesa3d-.spv
lrwxrwxrwx   1 root root   18 Sep 18 11:03 stoney-amdgcn--.bc -> 
tahiti-amdgcn--.bc
lrwxrwxrwx   1 root root   15 Sep 18 11:03 sumo2-r600--.bc -> cedar-r600--.bc
lrwxrwxrwx   1 root root   15 Sep 18 11:03 sumo-r600--.bc -> cedar-r600--.bc
-rw-r--r--   1 root root 7.8M Sep 18 11:03 tahiti-amdgcn--.bc
lrwxrwxrwx   1 root root   18 Sep 18 11:03 tonga-amdgcn--.bc -> 
tahiti-amdgcn--.bc
lrwxrwxrwx   1 root root   15 Sep 18 11:03 turks-r600--.bc -> barts-r600--.bc
lrwxrwxrwx   1 root root   18 Sep 18 11:03 verde-amdgcn--.bc -> 
tahiti-amdgcn--.bc

This seems to be only a naming issue, as adding a symlink with the appropriate 
name fixes it for me.


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

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:en
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages libclc-12 depends on:
ii  libclang-common-12-dev  1:12.0.1-9
ii  libclc-12-dev   1:12.0.1-9

libclc-12 recommends no packages.

libclc-12 suggests no packages.

-- no debconf information

Bug#994875: connman does not respect /etc/network/interfaces when upgrading from buster to bullseye and more general considerations

[Amy Kos]

Hi,

as far as I remember connman ignores /etc/network/interfaces by design.

Lxde metapackage in buster recommends wicd which is not available in bullseye 
due to the deprecation of python 2.
Therefore lxde metapackage in bullseye recommends connman-gtk (connman).

Cheers,
Amy

Bug#995023: improved patch: take care that the file doesn't exist on filesystems where link() fails

[Andreas B. Mundt]

Hi,

the patch provided before does not take into account that the file
may exists before we call link() on a file system where link() fails 
(and not with EEXIST).  In that case, we would use the already existing
file.

The attached patch makes sure we try a new file name in that case.

Regards,

  Andi

>From 0482adf516a914d9215ebd00b93ee63a15976836 Mon Sep 17 00:00:00 2001
From: "Andreas B. Mundt" 
Date: Fri, 24 Sep 2021 21:10:52 +0200
Subject: [PATCH] Fix for sshfs.

---
 debian/patches/series  |  1 +
 debian/patches/sshfs.patch | 23 +++
 2 files changed, 24 insertions(+)
 create mode 100644 debian/patches/sshfs.patch

diff --git a/debian/patches/series b/debian/patches/series
index e1ee4dfc..8c81fbe2 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -1,2 +1,3 @@
 03_kfreebsd.patch
 05_skip-known-test-failures.patch
+sshfs.patch
diff --git a/debian/patches/sshfs.patch b/debian/patches/sshfs.patch
new file mode 100644
index ..a1f6ab5f
--- /dev/null
+++ b/debian/patches/sshfs.patch
@@ -0,0 +1,23 @@
+--- a/pkcs11/gkm/gkm-transaction.c
 b/pkcs11/gkm/gkm-transaction.c
+@@ -294,16 +294,16 @@
+ 			 * stat, the check on the increased link count
+ 			 * will fail.  Fortunately the case for
+ 			 * hardlinks are not working solves it.  */
+-			if (link (filename, result) && errno == EEXIST) {
++			if (!access (result, F_OK) || (link (filename, result) && errno == EEXIST)) {
+ /* This is probably a valid error.
+  * Let us try another temporary file.  */
+ 			} else if (stat (filename, )) {
+ stat_failed = 1;
+ 			} else {
+-if ((sb.st_nlink == nlink + 1)
++if ((sb.st_nlink == nlink + 1) || !access (result, F_OK)
+ || !copy_to_temp_file (result, filename)) {
+-	/* Either the link worked or
+-	 * the copy succeeded.  */
++	/* Either the link worked (on sshfs, a copy is made
++	 * instead) or the final copy_to_temp_file succeeded.  */
+ 	gkm_transaction_add (self, NULL,
+ 	 complete_link_temporary,
+ 	 result);
-- 
2.30.2

Bug#614051: Fine Morning. Is Mrs. Anna.

[Mr. Peter Edem]

Can we talk please, is urgent, is about Mrs. Anna,

Bug#995068: gnome-games-app: Rename to highscore

[Jeremy Bicha]

Source: gnome-games-app
Version: 40.0-3

gnome-games-app appears to have been renamed to highscore so we should
rename our Debian packaging to match, once there is a new release.

I'm filing this bug as a reminder because our debian/watch won't pick
up the new release automatically.

https://gitlab.gnome.org/World/highscore

Background is at https://gitlab.gnome.org/Archive/gnome-games/-/issues/243

Thanks,
Jeremy Bicha

Bug#975524: cmst/connman system-tray applet: please start automatically when installed

[Amy Kos]

Control: reassign -1 cmst


Hi,

lxde uses connman-gtk not cmst. Sorry, my mistake.

Cheers,
Amy

Bug#992990: systemd: Does not clean up user session

[Michael Biebl]

On Thu, 26 Aug 2021 17:21:39 +0200 Samuel Thibault 
wrote:
> Control: tags -1 wontfix
> 
> So AIUI, to get a proper cleanup when the X server happens to go away
> (lightdm restart, or main session process exit), the processes have to
> notice that the X server went away?


Not sure what to do about this bug report.
Do you want to keep it open asking for `KillUserProcesses=yes` to be the new
default?
If not, is there a benefit to keep it open?

Michael



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

Bug#989600: /usr/bin/swift-container-reconciler: reconciler's memcache connections fail when using hostnames

[Filippo Giunchedi]

On Fri, Sep 10, 2021 at 09:50:42PM +0200, Thomas Goirand wrote:
> On 9/10/21 11:40 AM, Filippo Giunchedi wrote:
> > On Thu, Sep 09, 2021 at 09:32:34AM +0200, Thomas Goirand wrote:
> >> Hi,
> >>
> >> Thanks a lot for working on this, it really is helpful.
> >>
> >> The pull request you're pointing at contains multiple commits. Would you
> >> be able to transform this into a patch against the Eventlet versions
> >> 0.26.1 (currently in Stable) and 0.30.2 (in Unstable and Testing)? If
> >> you provide it, then I'll be very happy to add the patches to these
> >> Debian packages. If I'm asking it's not because I don't want to do it
> >> myself, but because you wrote it, you may be better at understanding how
> >> to backport the patches.
> > 
> > Certainly, I did port the patch to our internal repo for Bullseye. You can 
> > find
> > the commit below, which modulo the changelog version obviously should work 
> > as-is.
> > 
> > https://github.com/wikimedia/operations-debs-python-eventlet/commit/a93d2e0cd2cdf3efcd7915cb781355d58e5728ab
> > 
> > I didn't change 
> > 'Replace-dnspython-_compute_expiration-by-_compute_times.patch'
> > for a cleaner diff, although that patch a whole I think can be replaced with
> > the PR's diff. What do you think?
> > 
> > best,
> > Filippo
> > 
> 
> Hi,
> 
> I'll try to get this in Bullseye proper. Thanks a lot for your work,
> this is definitively very helpful, and may solve troubles with swift's
> cname middleware also.

You are welcome, and thank you for pushing to get the update in Bullseye

> 
> I'm not sure about
> Replace-dnspython-_compute_expiration-by-_compute_times.patch, though
> it's probably better, from the Debian Stable perspective, to not touch
> the patches that are already there, so it is easier for the Stable
> release team to review it.

Agreed

> I will also need a patch against the version 0.30.2-2 currently in
> unstable/bookworms (again: otherwise the Debian Stable release team may
> complain about it). Could you provide one?

For sure, I have added the patches in this MR. Let me know what you think!

https://salsa.debian.org/python-team/packages/python-eventlet/-/merge_requests/2

best,
Filippo

Bug#995067: bitlbee-libpurple: Crash if not stable connection

[Jean-Philippe MENGUAL]

Package: bitlbee-libpurple
Version: 3.6-1.2
Severity: important

Dear Maintainer,

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

   * What led up to the situation?

I discovered the problem during a non stable Wifi connection. The network
tends to be down during 30 seconds or 1 minute then bbe up

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

Sometimes, using weechat to connect to bitbeee on a local network, bitlbee 
crashes

   * What was the outcome of this action?

The main problem is that the crash.log file is more than 4GB. I dont know
how to send it, perhaps via the people./debian.org machine?

   * What outcome did you expect instead?

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

Regards


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

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

Versions of packages bitlbee-libpurple depends on:
ii  bitlbee-common  3.6-1.2
ii  debianutils 5.5-1
ii  libc6   2.32-4
ii  libgcrypt20 1.9.4-3+b1
ii  libglib2.0-02.70.0-1+b1
ii  libgnutls30 3.7.2-2
ii  libpurple0  2.14.1-1+b1

bitlbee-libpurple recommends no packages.

bitlbee-libpurple suggests no packages.

-- no debconf information

Bug#995046: 3.2.3-7 fails with libc6-2.30

[Eugene Berdnikov]

  Hi Samuel.
  
On Sat, Sep 25, 2021 at 03:08:47PM +0100, Samuel Henrique wrote:
> 1) Do you know how is it possible that you were running Debian testing
> with libc6 2.30-4? Even Debian stable has a newer version, I believe
> you could have missed running apt full-upgrade at some point.

 I have several hosts with old kernels (like 4.17) and their headers,
 and gcc-7, which are tied to libc6-2.30 by their dependences.
 On "aptitude install libc6" first resolver's proposal was to remove
 these packages. I agreed with this choice to install libc6-2.32.

 I have a copy of one such system on backup, it may be studied for
 more details if need... However, it looks pointless, because support
 for lchown() is definitely a new feature, so the right way, IMHO,
 is to correct dependences for rsync package: "libc6 (>= 2.31)".

> 2) Is your system under a chroot and/or without /proc mounted?

 No, fault happens with physical hosts (not VMs or containers),
 where /proc is mounted. However, they are all running SysV init.

> > Upgrade libc6 to 2.32-4 solves the problem.
> That's the current version available in testing and unstable, so
> anybody running those will be fine.

 Right. I also have some similar hosts with libc-2.32, probably they were
 upgraded to last version due to absence of old kernels, old gcc, etc.
 Rsync runs fine on them.

> If anything, 3.2.3-7 is fixing the very same issue you reported, which
> should have been happening in rsync 3.2.3 + libc6 2.32 (but you
> mention you had an older libc6).
> 
> Overall I believe there might be something wrong in your system,
> related to libc6.

 Every system with periodic updates might have outdated packages,
 generally it's not a problem (and should not be a problem) if binary API
 is compatible and all package dependences are correct.
-- 
 Eugene Berdnikov

Bug#995066: mariadb-server: Incorrect warning about corrupt tables on mysql start

[Alexander Kirillov]

Package: mariadb-server
Version: 1:10.5.11-1
Severity: normal
Tags: l10n patch

Dear Maintainer,

/etc/mysql/debian-start incorrectly warns about corrupt tables if there're 
databases and tables with non-ascii names.

ТемаWARNING: mysqlcheck has found corrupt tables
От  root
Комуroot@neva.localnet
ДатаСегодня 13:45

ERROR 1146 (42S02) at line 1: Table '??? .??? ??' doesn't exist
ERROR 1146 (42S02) at line 1: Table '??? .GDP' doesn't exist
ERROR 1146 (42S02) at line 1: Table '??? .' doesn't exist
ERROR 1146 (42S02) at line 1: Table '??? .??' doesn't exist
ERROR 1146 (42S02) at line 1: Table '??? .??' doesn't exist
ERROR 1146 (42S02) at line 1: Table '??? .???' doesn't exist
ERROR 1146 (42S02) at line 1: Table '??? .bugs-old' doesn't exist
ERROR 1146 (42S02) at line 1: Table '??? .? ?? ??' doesn't exist
ERROR 1146 (42S02) at line 1: Table '??? .??? ???' doesn't exist
ERROR 1146 (42S02) at line 1: Table '??? .??' doesn't exist
ERROR 1146 (42S02) at line 1: Table '??? .?? ??' doesn't exist
ERROR 1146 (42S02) at line 1: Table '??? .?? ???' doesn't exist
ERROR 1146 (42S02) at line 1: Table '??? .bugs' doesn't exist
ERROR 1146 (42S02) at line 1: Table '??? .?' doesn't exist
ERROR 1146 (42S02) at line 1: Table '??? .?' doesn't exist

 Improperly closed tables are also reported if clients are accessing
 the tables *now*. A list of current connections is below.

+-+--+---++-+--+--+--+--+
| Id  | User | Host  | db | Command | Time | State| Info | 
Progress |
+-+--+---++-+--+--+--+--+
| 441 | root | localhost || Query   | 0| starting | show processlist | 
0.000|
+-+--+---++-+--+--+--+--+
Uptime: 6  Threads: 1  Questions: 879  Slow queries: 0  Opens: 428  Open 
tables: 421  Queries per second avg: 146.500

Suggested fix:

--- /usr/share/mysql/debian-start.inc.sh2021-09-25 16:15:00.757459188 
+0300
+++ /usr/share/mysql/debian-start.inc.sh2021-09-25 16:16:05.448573230 
+0300
@@ -23,7 +23,7 @@
   # If a crashed table is encountered, the "mysql" command will return with a 
status different from 0
   set +e
 
-  LC_ALL=C $MYSQL --skip-column-names --batch -e  '
+  $MYSQL --skip-column-names --batch -e  '
   select concat('\''select count(*) into @discard from `'\'',
 TABLE_SCHEMA, '\''`.`'\'', TABLE_NAME, '\''`'\'')
   from information_schema.TABLES where 
TABLE_SCHEMA<>'\''INFORMATION_SCHEMA'\'' and 
TABLE_SCHEMA<>'\''PERFORMANCE_SCHEMA'\'' and ( ENGINE='\''MyISAM'\'' or 
ENGINE='\''Aria'\'' )' | \

-- System Information:
Debian Release: 11.0
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (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, 
TAINT_UNSIGNED_MODULE
Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.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 mariadb-server depends on:
ii  mariadb-server-10.5  1:10.5.11-1

mariadb-server recommends no packages.

mariadb-server suggests no packages.

-- no debconf information

Bug#995065: unrar-free: CVE-2017-11190 fix

[Bastian Germann]

Package: unrar-free
Severity: minor
Version: 1:0.0.1+cvs20140707-4

At https://gitlab.com/bgermann/unrar-free/-/commit/e4b3d2d974780af1 you 
can find a fix for CVE-2017-11190 which is unproblematic because the 
debug code is not compiled in Debian.

Bug#995064: golang-github-containers-storage: Please upgrade to upstream version 1.36

[Reinhard Tartler]

Package: golang-github-containers-storage
Severity: wishlist
X-Debbugs-Cc: none, Reinhard Tartler 

This is needed for podman 3.4, cf. #994601


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

Kernel: Linux 5.10.0-8-amd64 (SMP w/4 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 /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Bug#987336: update ITP description

[clay stan]

Control: retitle 987336 ITP: dtkcommon -- A public project for building DTK 
Library

Bug#994551: libcifpp1: please split off static files to separate package

[Nilesh Patra]

Hi Étienne, all,

> I took the liberty to implement the change you suggest, and push
> to Salsa [1].

I do not see your changes on salsa, the last commit is 3 months old
there.
Did you forget to push?

> Since this is an RC bug which propagates on
> several packages, and since it would have to go through NEW, for
> manual review;

Actually, this bug is now triggering an ugly autorm on several packages.
And since it needs to travel via NEW, they might end up getting removed
from testing.

@Andrius, since you wrote:

> So far, there has not been other libcifppX binary package, thus no
> damage is done. However, future libcifppX packages should not contain
> static files, in particular these:

and since this is not doing any damage for now, do you think we could
reduce the severity to important for now?
We cannot do another upload on top of the one we will be sending to NEW
w/o hooping via NEW again, anyway,
so I find it safe to drop the severity for now.

Let me know?

Nilesh


signature.asc
Description: PGP signature

Bug#995006: init-system-helpers: deb-systemd-helper does not call daemon-reload despite unit files were changed

[Michael Biebl]

Am 25.09.21 um 16:50 schrieb Michael Biebl:
daemon-reload is a costly operation, so we should try to avoid calling 
it too excessively.


I've been trying hard to get rid of "daemon-reload" calls where not 
absolutely necessary, see e.g. [1-3]


So I'd be very wary re-adding them too liberally.

Regards,
Michael


[1] https://salsa.debian.org/debian/debhelper/-/merge_requests/43
[2] 
https://salsa.debian.org/systemd-team/systemd/commit/54ebb5500e75562d77fc5668ef7194af579f85bd
[3] 
https://salsa.debian.org/debian/init-system-helpers/commit/f0cac594ab79ebe72c53529046304037cf5c09b8




OpenPGP_signature
Description: OpenPGP digital signature

Bug#995006: init-system-helpers: deb-systemd-helper does not call daemon-reload despite unit files were changed

[Michael Biebl]

Am 24.09.21 um 21:36 schrieb Vasyl Gello:
retitle -1 dh_installsystemd should call daemon-reload in postinst if 
unit files changed

reassign -1 debhelper 13.5.1

 >No, my point is that i-s-h is not called as part of the upgrade 
process, since you explicititly asked not to. So i-s-h can not call 
daemon-reload.
 >Whether dh_installsystemd should generate a blank "daemon-reload" in 
this case is another matter.


OK, so I am re-assigning the bug to debhelper and temporary add the 
daemon-reload step into xpra postinst.


So far, we call daemon-reload in the following cases:



autoscripts/postrm-systemd-reload-only: systemctl --system daemon-reload 
>/dev/null || true
autoscripts/postinst-systemd-restartnostart:systemctl --system 
daemon-reload >/dev/null || true
autoscripts/postinst-systemd-restart:   systemctl --system daemon-reload 
>/dev/null || true
autoscripts/postinst-systemd-start: systemctl --system daemon-reload 
>/dev/null || true



So, it is currently tied to start/restart requests, i.e. we only call 
daemon-reload at the exact point when it's actually needed before we 
(re)start a service and need the updated configuration, i.e. in cases 
where dh_installsystemd controls the life cycle of the service.


daemon-reload is a costly operation, so we should try to avoid calling 
it too excessively.


So I'm not convinced it is a good idea to generate a daemon-reload (via 
dh_installsystemd in postinst) for packages which do not actually 
(re)start a unit as part of the upgrade process.


By using  "--no-enable --no-start" you are basically leaving the 
management of the life cycle of the service entirely to the 
administrator. Wouldn't you agree?


Shouldn't the administrator then call "systemctl daemon-reload" as well?
systemd will even warn him in cases a .service file has changed (which 
thankfully doesn't happen too often)


Is this actually an issue in practice? Do you have bug reports where 
users of your xpra package have asked for this?



Regards,
Michael




OpenPGP_signature
Description: OpenPGP digital signature

Bug#995063: os-prober fails to detect partition when the device name is a substring of another device

[Mike]

Package: os-prober
Version: 1.77
Severity: important
Tags: patch

Dear Maintainer,

My system has another linux install located on /dev/sde1, which os-prober 
should detect
There is also a /dev/sde127 which is part of a raid array

In this case, os-prober line 141 incorrectly believes that /dev/sde1 is part of 
a raid array, because
grep -q "^/dev/sde1" $OS_PROBER_TMP/raided-map 
returns true as it matches the /dev/sde127 line.

This can be fixed by changing the line to read
 if grep -q "^$mapped\$" "$OS_PROBER_TMP/raided-map" ; then

Thanks

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

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

Versions of packages os-prober depends on:
ii  grub-common  2.02+dfsg1-20+deb10u4
ii  libc62.28-10

os-prober recommends no packages.

os-prober suggests no packages.

-- no debconf information

Bug#987336: add more information

[clay stan]

Package: wnpp
Severity: wishlist
Owner: clay stan 
Control: retitle 987336 ITP: dtkcommon -- A public project for
building DTK Library

* Package name: dtkcommon
  Version : 5.5.2
  Upstream Author : linuxdeepin
* URL : https://github.com/linuxdeepin/dtkcommon
  License : GPL-3+
  Programming Lang: CPP
  Description : A public project for building DTK Library
DTK is short name of deepin tool kit,It is a set of beautiful
and practical UI graphics library developed based on Qt5

Bug#995062: bullseye-pu: package speech-dispatcher/0.10.2-2+deb11u1

[Samuel Thibault]

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

Hello,

[ Reason ]
We have recently noticed that one cannot choose between the various
mbrola speech synthesis voices in the orca screen reader.

This is not a regression from previous releases.

[ Impact ]
This prevents users from being able to switch between e.g. male/female
voices to efficiently mark different contents.

[ Tests ]
This was tested in a VM as well as on the end-user system where the bug
was noticed first.

[ Risks ]
The code is very simple: it just moves a single line of code, and adds a
few debugging prints to make sure this gets effect.

[ 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 bug comes from the fact that there are several ways to specify the
voice to be used: either through language + voice type, or precise voice
name. The second way is of course very precise, but unfortunately it was
coming first, and thus overwritten by the other ways. The change is just
to use the voice name last, so that one takes precedence over the other
(more generic) types.
diff -Nru speech-dispatcher-0.10.2/debian/changelog 
speech-dispatcher-0.10.2/debian/changelog
--- speech-dispatcher-0.10.2/debian/changelog   2020-12-16 01:17:56.0 
+0100
+++ speech-dispatcher-0.10.2/debian/changelog   2021-09-19 15:55:15.0 
+0200
@@ -1,3 +1,10 @@
+speech-dispatcher (0.10.2-2+deb11u1) bullseye; urgency=medium
+
+  * patches/generic-set-voice-name: Fix setting voice name for the generic
+module.
+
+ -- Samuel Thibault   Sun, 19 Sep 2021 15:55:15 +0200
+
 speech-dispatcher (0.10.2-2) unstable; urgency=medium
 
   * speech-dispatcher: Handle moving configuration file from main package to
diff -Nru speech-dispatcher-0.10.2/debian/patches/generic-set-voice-name 
speech-dispatcher-0.10.2/debian/patches/generic-set-voice-name
--- speech-dispatcher-0.10.2/debian/patches/generic-set-voice-name  
1970-01-01 01:00:00.0 +0100
+++ speech-dispatcher-0.10.2/debian/patches/generic-set-voice-name  
2021-09-19 15:55:15.0 +0200
@@ -0,0 +1,41 @@
+commit 2aff49e3b8eb49dceb2c135025bc19cea6b0fd2e
+Author: Samuel Thibault 
+Date:   Sun Sep 19 15:52:31 2021 +0200
+
+generic: Set voice name after setting voice language and type
+
+E.g. when using various mbrola languages, we want to be able to specify
+a precise voice name. Setting the voice language/type after the voice
+name would override that choice.
+
+diff --git a/src/modules/generic.c b/src/modules/generic.c
+index 5072867d..b62cdb58 100644
+--- a/src/modules/generic.c
 b/src/modules/generic.c
+@@ -205,9 +205,9 @@ int module_speak(const gchar * data, size_t bytes, 
SPDMessageType msgtype)
+   DBG("Speaking when requested to write");
+   return 0;
+   }
+-  UPDATE_STRING_PARAMETER(voice.name, generic_set_synthesis_voice);
+   UPDATE_STRING_PARAMETER(voice.language, generic_set_language);
+   UPDATE_PARAMETER(voice_type, generic_set_voice);
++  UPDATE_STRING_PARAMETER(voice.name, generic_set_synthesis_voice);
+   UPDATE_PARAMETER(punctuation_mode, generic_set_punct);
+   UPDATE_PARAMETER(pitch, generic_set_pitch);
+   UPDATE_PARAMETER(pitch_range, generic_set_pitch_range);
+@@ -707,6 +707,7 @@ void generic_set_language(char *lang)
+ 
+ void generic_set_voice(SPDVoiceType voice)
+ {
++  DBG("Setting voice type %d", voice);
+   assert(generic_msg_language);
+   generic_msg_voice_str =
+   module_getvoice(generic_msg_language->code, voice);
+@@ -717,6 +718,7 @@ void generic_set_voice(SPDVoiceType voice)
+ 
+ void generic_set_synthesis_voice(char *name)
+ {
++  DBG("Setting voice name %s (%s)", name, msg_settings.voice.name);
+   assert(msg_settings.voice.name);
+   if (module_existsvoice(msg_settings.voice.name))
+   generic_msg_voice_str = msg_settings.voice.name;
diff -Nru speech-dispatcher-0.10.2/debian/patches/series 
speech-dispatcher-0.10.2/debian/patches/series
--- speech-dispatcher-0.10.2/debian/patches/series  2020-11-25 
00:43:56.0 +0100
+++ speech-dispatcher-0.10.2/debian/patches/series  2021-09-19 
15:55:15.0 +0200
@@ -1,3 +1,4 @@
 doc-figures
 systemd-debian
 mbrola-paths
+generic-set-voice-name

Bug#994789: rsync: Errors out with "deflate on token returned 0 (8864 bytes left)" when tranferring 3GB file

[Samuel Henrique]

Hello Faheem,

> I did some investigation, but forgot to update the bug report. Based on
> priors, I was not expecting to get a reply.

Yeah, sometimes it's hard to keep up with the bug reports, thanks for
not giving up!

> The problem is that I'm connecting to a remote VPS, which is an OpenVZ
> VM, and currently runs a badly outdated version of Debian, Debian 8
> (jessie). It was running the default version of rsync for that release
> (3.1.1-3+deb8u2), which appears to be too old to do the handshake that
> rsync expects for compression.

Wow, that is quite outdated yes, at this point the only support there
is for Jessie is the paid one by the Debian LTS project[0][1].
Since you're a customer, I would kindly suggest cutting a ticket to
them, asking for an updated release.

> However, as an error message, this really sucked. Unless the rsync
> maintainers consider compatibility with older rsync versions not worth
> bothering with, it would be good to have a more intelligible error
> message. But I don't know if it is worth trying to follow up with the
> rsync project.

My experience with rsync upstream is that they would improve the error
message if possible, so it might be worth reporting it.

> I managed to backport the current version of rsync to Debian 8 on the
> OpenVZ VPS, and the error went away. Other workarounds I tried (like
> --compress-choice) all failed, because the rsync version seemed to be
> too old.

Happy to know your workaround fixed the issue, I always try to upload
an updated rsync release to the backports repository as well, but that
didn't happen with Jessie

> The output of `apt-cache policy rsync` on that server now looks like
>
>  rsync:
>Installed: 3.2.3-7
>Candidate: 3.1.1-3+deb8u2
>Package pin: (not found)
>Version table:
>   3.2.3-7 1001
>   50 http://ftp.us.debian.org/debian/ testing/main amd64 Packages
>   50 http://ftp.us.debian.org/debian/ unstable/main amd64 Packages
>   *** 3.2.3-7 1001
>  100 /var/lib/dpkg/status
>   3.1.1-3+deb8u2 1001
>  500 http://security.debian.org/ jessie/updates/main amd64 
> Packages
>   3.1.1-3+deb8u1 1001
>  500 http://ftp.us.debian.org/debian/ jessie/main amd64 Packages

By looking at these, it seems like your VPS provider is not using ELTS
so it's possible they're not updating their images for more than a
year now. However, this is just a guess, I suggest contacting them and
explaining your concerns with outdated images.

> If you don't think it's worth following up upstream regarding the
> quality of their error messages, you can close this bug report.

I think it's worth it, but I will let this up for you, so I'm
resolving this bug report.

[0] https://wiki.debian.org/LTS/Extended
[1] https://deb.freexian.com/extended-lts/

Thank you,

-- 
Samuel Henrique 

Bug#987335: add more information

[clay stan]

Package: wnpp
Severity: wishlist
Owner: clay stan 

* Package name: dpa-ext-gnomekeyring
  Version : 5.0.4
  Upstream Author : linuxdeepin
* URL : https://github.com/linuxdeepin/dpa-ext-gnomekeyring
  License : GPL-3+
  Programming Lang: CPP
  Description :GNOME keyring extension for dde-polkit-agent.
DDE Polkit Agent extension to automatically do some thing with GNOME keyring

Bug#698996: unrar-free: obsolete information in Description

[Bastian Germann]

This issue was already addressed and it should be closed.

Bug#995026: Update

[Jeremy Hendricks]

I confirmed this also happens in Testing (bookworm) aside from it pulling
in Nvidia 470 packages instead. I tested this on the same machine but in a
bookworm chroot with: apt install nvidia-legacy-390xx-driver -s

Bug#995046: 3.2.3-7 fails with libc6-2.30

[Samuel Henrique]

Control: severity -1 normal

Hello Eugene, thanks for your bug report :)

I think I still need to understand a few things before proceeding,
seems like there's something weird going on in your system.

1) Do you know how is it possible that you were running Debian testing
with libc6 2.30-4? Even Debian stable has a newer version, I believe
you could have missed running apt full-upgrade at some point.

2) Is your system under a chroot and/or without /proc mounted? We've
had this issue in the near past [0], but it should be patched for
3.2.3-7 [1], even with older libc6.

> Upgrade libc6 to 2.32-4 solves the problem.
That's the current version available in testing and unstable, so
anybody running those will be fine.

Stable currently has libc6 2.31, and I plan on having a backports of
rsync at some point in the future, so this issue could affect that,
though I don't see how the changes between 3.2.3-4 and 3.2.3-7 could
trigger this bug. I'm also considering that upstream's bug reports
says this issue only started with libc6 2.32 [0][2].

If anything, 3.2.3-7 is fixing the very same issue you reported, which
should have been happening in rsync 3.2.3 + libc6 2.32 (but you
mention you had an older libc6).

Overall I believe there might be something wrong in your system,
related to libc6.

I will lower the priority to normal, considering all of these, and
will increase it if needed once we understand your issue better.

[0] https://github.com/WayneD/rsync/issues/109
[1] 
https://salsa.debian.org/debian/rsync/-/commit/3320a1c1b9e9fcf4b4b759a194a6059380c56b88
[2] https://sourceware.org/bugzilla/show_bug.cgi?id=26401

Thank you,

-- 
Samuel Henrique 

Bug#994560: Bug#995032: GNOME components segfault as a result of libffi transition

[Sebastian Ramacher]

On 2021-09-25 14:55:23 +0100, Simon McVittie wrote:
> On Sat, 25 Sep 2021 at 15:01:46 +0200, Sebastian Ramacher wrote:
> > Regardless of future transitions of libffi, if glib and the
> > introspection ecosystems are closely tied to the the libffi ABI, the
> > affected packages need to express that with the proper dependencies.
> 
> It's not that they are closely tied to any specific libffi ABI - to the
> best of my knowledge, they're all fine with any reasonable version of
> libffi, old or new. The problem is that gobject-introspection and all
> users of girffi.h[1] (gjs, pygobject, etc.) all need to be using the
> *same* libffi, because girffi.h has functions that return pointers to ffi
> types or take pointers to ffi types as parameters.

Sorry, that's not what I meant. they are tightly coupled in the sense
that the whole gobject-introspection ecosystem needs to use the same
libffi version. It's the same as boost and icu where also icu's ABI
leaks into boost's ABI (via some icu structs that are passed around).
Hence everything that uses Boost.Regex needs also be tracked in icu
transitions. To track that, libboost-regexX provides
libboost-regexX-icuY and reverse dependencies have dependencies on
libboost-regexX-icuY.

For libgirepository1.0-1 that would mean that
libgirepository1.0-1 provides libgirepository1.0-1-ffiX and symbols from
girffi that depend on the specific libffi ABI then declare in the
symbols files that dependencies on libgirepository1.0-1-ffiX need to be
generated.

Cheers

> 
> I don't know whether it is important that glib2.0 and gobject-introspection
> are *also* using the same libffi; in the past we assumed that they should,
> but it is probably not critical.
> 
> [1] https://codesearch.debian.net/search?q=girffi.h=1
> 
> smcv

-- 
Sebastian Ramacher


signature.asc
Description: PGP signature

Bug#986783: add more information

[clay stan]

Package: wnpp
Severity: wishlist
Owner: clay stan 

* Package name: cpufetch
  Version : 0.97
  Upstream Author : Dr-Noob
* URL : https://github.com/Dr-Noob/cpufetch
  License : MIT
  Programming Lang: C
  Description : cpufetch is a command-line tool written in C that
displays the CPU information in a clean and beautiful way

Bug#994923: add more infomation

[clay stan]

Package: wnpp
Severity: wishlist
Owner: clay stan 

* Package name:  dirsearch
  Version : 0.4.2
  Upstream Author : maurosoria
* URL : https://github.com/maurosoria/dirsearch
  License : GPL-2
  Programming Lang: Python
  Description : An advanced command-line tool designed to brute
force directories and files in webservers, AKA web path scanner