Bug#984910: pam: [INTL:fr] French templates translation

[Jean-Pierre Giraud]

Package: pam
Severity: wishlist
Tags: patch l10n

Hi!

Please find attached the french templates translation, proofread
by the debian-l10n-french mailing list contributors.

This file should be put as debian/po/fr.po in your package build tree.

Kind Regards

Jean-Pierre Giraud


fr.po.gz
Description: application/gzip

Bug#984909: linux-image-5.10.0-0.bpo.3-amd64: Kernel 5.10 have regression which breaks Kodi play from NFS share

[Daniel Smolik]

Package: src:linux
Version: 5.10.13-1~bpo10+1
Severity: normal

Dear Maintainer,

Please include this fix to new package version:
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=v5.10.15=8e081627f3a7f733a4955ee40b385c972f010f05
Wihout this Kodi on RPi cannot play media shared ovre NFS

Regards
Dan Smolik



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

** Model information
sys_vendor: Gigabyte Technology Co., Ltd.
product_name: Z170-D3H
product_version: To be filled by O.E.M.
chassis_vendor: To Be Filled By O.E.M.
chassis_version: To Be Filled By O.E.M.
bios_vendor: American Megatrends Inc.
bios_version: F2
board_vendor: Gigabyte Technology Co., Ltd.
board_name: Z170-D3H-CF
board_version: x.x

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

source /etc/network/interfaces.d/*

auto lo
iface lo inet loopback


auto eth0
iface eth0 inet static
address 192.168.3.13
netmask 255.255.255.0
gateway 192.168.3.1
dns-nameservers   192.168.3.1



iface eth0:1 inet static
address 192.168.0.100
netmask 255.255.255.0

iface eth0:2 inet static
address 192.168.1.100
netmask 255.255.255.0


iface eth0:3 inet static
address 192.168.150.10
netmask 255.255.255.0





** PCI devices:
00:00.0 Host bridge [0600]: Intel Corporation Skylake Host Bridge/DRAM 
Registers [8086:191f] (rev 07)
Subsystem: Gigabyte Technology Co., Ltd Xeon E3-1200 v5/E3-1500 v5/6th 
Gen Core Processor Host Bridge/DRAM Registers [1458:5000]
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR- 
Kernel driver in use: skl_uncore

00:01.0 PCI bridge [0604]: Intel Corporation Skylake PCIe Controller (x16) 
[8086:1901] (rev 07) (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:14.0 USB controller [0c03]: Intel Corporation Sunrise Point-H USB 3.0 xHCI 
Controller [8086:a12f] (rev 31) (prog-if 30 [XHCI])
Subsystem: Gigabyte Technology Co., Ltd 100 Series/C230 Series 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:14.2 Signal processing controller [1180]: Intel Corporation Sunrise Point-H 
Thermal subsystem [8086:a131] (rev 31)
Subsystem: Gigabyte Technology Co., Ltd 100 Series/C230 Series Chipset 
Family Thermal Subsystem [1458:]
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- 
Kernel driver in use: intel_pch_thermal
Kernel modules: intel_pch_thermal

00:16.0 Communication controller [0780]: Intel Corporation Sunrise Point-H CSME 
HECI #1 [8086:a13a] (rev 31)
Subsystem: Gigabyte Technology Co., Ltd 100 Series/C230 Series Chipset 
Family MEI Controller [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 Sunrise Point-H SATA 
controller [AHCI mode] [8086:a102] (rev 31) (prog-if 01 [AHCI 1.0])
Subsystem: Gigabyte Technology Co., Ltd 
Q170/Q150/B150/H170/H110/Z170/CM236 Chipset 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:1b.0 PCI bridge [0604]: Intel Corporation Sunrise Point-H PCI Root Port #17 
[8086:a167] (rev f1) (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:1b.2 PCI bridge [0604]: Intel Corporation Sunrise Point-H PCI Root Port #19 
[8086:a169] (rev f1) (prog-if 00 [Normal decode])
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- 

Bug#984908: cbonsai FTCBFS: multiple reasons

[Helmut Grohne]

Source: cbonsai
Version: 0.0~git20210208.41fdd6e-1
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

cbonsai fails to cross build from source. The immediate failure is
failing to locate the .pc file for ncurses using the build architecture
pkg-config. dh_auto_build already passes a suitable PKG_CONFIG, so the
Makefile should simply use that. Beyond this, use of help2man breaks
cross building. In this case, the package can simply be built twice.
Please consider applying the attached patch.

Helmut
diff --minimal -Nru cbonsai-0.0~git20210208.41fdd6e/debian/changelog 
cbonsai-0.0~git20210208.41fdd6e/debian/changelog
--- cbonsai-0.0~git20210208.41fdd6e/debian/changelog2021-02-08 
16:44:14.0 +0100
+++ cbonsai-0.0~git20210208.41fdd6e/debian/changelog2021-03-09 
21:33:56.0 +0100
@@ -1,3 +1,12 @@
+cbonsai (0.0~git20210208.41fdd6e-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: (Closes: #-1)
++ cross.patch: make pkg-config substitutable.
++ Build twice. Once for help2man and once for real.
+
+ -- Helmut Grohne   Tue, 09 Mar 2021 21:33:56 +0100
+
 cbonsai (0.0~git20210208.41fdd6e-1) unstable; urgency=medium
 
   * Initial release (Closes: #981965)
diff --minimal -Nru cbonsai-0.0~git20210208.41fdd6e/debian/control 
cbonsai-0.0~git20210208.41fdd6e/debian/control
--- cbonsai-0.0~git20210208.41fdd6e/debian/control  2021-02-05 
14:58:55.0 +0100
+++ cbonsai-0.0~git20210208.41fdd6e/debian/control  2021-03-09 
21:33:56.0 +0100
@@ -6,6 +6,7 @@
  debhelper-compat (= 13),
  help2man,
  libncurses-dev,
+ libncurses-dev:native,
  pkg-config,
 Standards-Version: 4.5.1
 Homepage: https://gitlab.com/jallbrit/cbonsai
diff --minimal -Nru cbonsai-0.0~git20210208.41fdd6e/debian/patches/cross.patch 
cbonsai-0.0~git20210208.41fdd6e/debian/patches/cross.patch
--- cbonsai-0.0~git20210208.41fdd6e/debian/patches/cross.patch  1970-01-01 
01:00:00.0 +0100
+++ cbonsai-0.0~git20210208.41fdd6e/debian/patches/cross.patch  2021-03-09 
21:33:56.0 +0100
@@ -0,0 +1,12 @@
+--- cbonsai-0.0~git20210208.41fdd6e.orig/Makefile
 cbonsai-0.0~git20210208.41fdd6e/Makefile
+@@ -1,7 +1,8 @@
+ .POSIX:
+ CC= cc
+ CFLAGS= -Wall -pedantic
+-LDLIBS= $(shell pkg-config --libs ncurses panel)
++PKG_CONFIG ?= pkg-config
++LDLIBS= $(shell $(PKG_CONFIG) --libs ncurses panel)
+ PREFIX= /usr/local
+ 
+ cbonsai: cbonsai.c
diff --minimal -Nru cbonsai-0.0~git20210208.41fdd6e/debian/patches/series 
cbonsai-0.0~git20210208.41fdd6e/debian/patches/series
--- cbonsai-0.0~git20210208.41fdd6e/debian/patches/series   1970-01-01 
01:00:00.0 +0100
+++ cbonsai-0.0~git20210208.41fdd6e/debian/patches/series   2021-03-09 
21:33:43.0 +0100
@@ -0,0 +1 @@
+cross.patch
diff --minimal -Nru cbonsai-0.0~git20210208.41fdd6e/debian/rules 
cbonsai-0.0~git20210208.41fdd6e/debian/rules
--- cbonsai-0.0~git20210208.41fdd6e/debian/rules2021-02-05 
15:07:15.0 +0100
+++ cbonsai-0.0~git20210208.41fdd6e/debian/rules2021-03-09 
21:33:56.0 +0100
@@ -1,5 +1,7 @@
 #!/usr/bin/make -f
 
+include /usr/share/dpkg/architecture.mk
+
 export DEB_BUILD_MAINT_OPTIONS = hardening=+all
 export DEB_CFLAGS_MAINT_APPEND = -Wall -pedantic
 export DEB_LDFLAGS_MAINT_APPEND = -Wl,--as-needed
@@ -8,11 +10,15 @@
dh $@
 
 override_dh_auto_build:
-   dh_auto_build -- CFLAGS="$(CFLAGS)"
+   dpkg-architecture -a$(DEB_BUILD_ARCH) -f -c dh_auto_build -- 
CFLAGS="$(CFLAGS)"
 
 execute_after_dh_auto_build:
help2man --no-info --name 'random bonsai tree generator' \
--version-string $(shell dpkg-parsechangelog -S version) \
--section 6 --output cbonsai.6 ./cbonsai
+ifneq ($(DEB_BUILD_ARCH),$(DEB_HOST_ARCH))
+   dh_auto_clean
+   dh_auto_build -- CFLAGS="$(CFLAGS)"
+endif
 
 override_dh_auto_install:

Bug#984721: Report already obsolete

[andrew glaeser]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1



I have re-checked the situation, and the problem is no longer reproducible,

it is now possible to log in three times in a row:

> andrew@a68n:~$ x2goclient
> x2go-INFO-1> "Starting X2Go Client 4.1.2.1..."
> x2go-WARNING-1> English language requested, not loading translator.
> x2go-WARNING-1> English language requested, not loading translator.
> QObject::connect: No such slot ONMainWindow::slotCheckAgentProcess()
> x2go-INFO-3> "Started X2Go Client."
> x2go-INFO-8> "Starting connection to server: bulls-eye:22"
> Generating public/private rsa key pair.
> Your identification has been saved in /home/andrew/.x2go/ssh/gen/key.jYUNNC.
> Your public key has been saved in /home/andrew/.x2go/ssh/gen/key.jYUNNC.pub.
> The key fingerprint is:
> SHA256:aNhrCXUszZRiBkhcKFQoJ3/EfB97H885SEEZ3esunrs X2Go Client RSA user key
> The key's randomart image is:
> +---[RSA 4096]+
> |.++Bo.  .. .o+ . |
> |+.= + ==o   o . .|
> |.= . +oo=o   .  .|
> |  . .+ +o . o  . |
> |   .o + S. o =.. |
> | o oo =. |
> |  +   .. |
> | .   ... |
> |.E+  |
> +[SHA256]-+
> x2go-INFO-8> "Starting connection to server: bulls-eye:22"
> Generating public/private rsa key pair.
> Your identification has been saved in /home/andrew/.x2go/ssh/gen/key.ZjtFXC.
> Your public key has been saved in /home/andrew/.x2go/ssh/gen/key.ZjtFXC.pub.
> The key fingerprint is:
> SHA256:uvDKzDbQtgirsRSFhbliebRdfZEiVZx5pjFesdjnVlE X2Go Client RSA user key
> The key's randomart image is:
> +---[RSA 4096]+
> |  o.o.oo=...E|
> | oo.   o o Oo+. .|
> | .+.o . . +.Bo ..|
> |.+.o . o  o .|
> |o...S  o |
> |. o o  .  .  |
> |.+ +...  |
> |oo.++o . |
> |+  .=oo  |
> +[SHA256]-+
> x2go-INFO-8> "Starting connection to server: bulls-eye:22"
> Generating public/private rsa key pair.
> Your identification has been saved in /home/andrew/.x2go/ssh/gen/key.MunRXq.
> Your public key has been saved in /home/andrew/.x2go/ssh/gen/key.MunRXq.pub.
> The key fingerprint is:
> SHA256:oMeOHRJOi4Akkr4IWzCgFnjS+csu4EFjzfD4hJVf8UE X2Go Client RSA user key
> The key's randomart image is:
> +---[RSA 4096]+
> |*= ..  .oE   |
> |%.=o   .. .  |
> |=*O.+ o  .   |
> |oO.O.* . |
> |=o*.=.+ S|
> |+o .o* . |
> |. o  |
> | .. .|
> |   . |
> +[SHA256]-+
> 

There was a kernel-update and some other updates in the meantime, maybe I

am doing too sloppy in updates-tracing, so it is sometimes hard to tell,

what exactly resolved the problem.

-BEGIN PGP SIGNATURE-

iF0EARECAB0WIQTF9uNaslvnJpWt8kXn6sEfJS3nCwUCYEhsMQAKCRDn6sEfJS3n
C+eKAJoDSbIAf4oZ1UNv5QIHKGkKiXPYXQCfSY5Xd16ltkUBoYAVhThbZA9iVf4=
=eMwT
-END PGP SIGNATURE-

Bug#984907: Debian Installer 10.8.0 will not Write to Disk with 2021 HP Notebook 17"

[Bug Reports]

Package:  Debian stable installer

Version:   10.8.0

Severity:  Critical

Report submitted on behalf of  from #xfce Freenode Network.


Svartoyg reports that Debian installer 10.8.0 would not write file 
systems to disk if an EFI partition was installed first.  His report 
consists of -notebook with 17''-display and Ryzen5-CPU. had problems 
with EFI and IOMMU

https://forums.linuxmint.com/viewtopic.php?t=302902

This problems with the installer not writing file system to disk have 
been observed also with the Dell XPS 15 7590, and other newer systems.

Bug#984905: Partitions/File System Will Not Write to Disk with EFI Disk Installed First

[Bug Reports]

Package:  Debian stable installer

Version:   10.7.0, and 10.8.0

Severity:  Critical


Hard drive was formated as GPT.  Installer will not write to disk after 
setting up file system/partitions if an EFI partition is created first.  
Error message indicates "Can't write to disk". Once the EFI partition is 
removed then the installer will write to disk.  This presents a problem 
to people wishing to dual boot with EFI partitions on a GPT formatted drive.


Hardware that this occurred on is a Dell XPS 15 7590. This laptop came 
out in late 2019.


One of the key benefits of a GPT formatted partition is being able to 
install windows in any order -- first or last.  But that won't be 
possible on this laptop because Linux has problems with EFI if installed 
first.  No test was done to see if a problem would occur if the EFI was 
installed last.

Bug#970635: moosic: new upstream now supports Python 3

[Arto Jantunen]

The Wanderer  writes:
> (Apologies for breaking threading; I don't seem to have received the
> original mail, and my Web browser appears to be treating the mailto:
> links as something like file://mailto: links, and reports that it can't
> find any file by the given name.)
>
> On 2021-01-02 at 13:34, Arto Jantunen wrote:
>
>> The package has been uploaded and is in NEW awaiting processing by
>> the FTP team.
>
> Last night (as far as I can judge), this package disappeared from
> https://ftp-master.debian.org/new.html (which I take to be the NEW
> queue).
>
> As of a few minutes ago, it did not seem to be in the archive. A
> packages.debian.org search didn't find it in anything newer than stable
> (with the old version, of course), and the tracker.debian.org page for
> this package showed the last change being the removal this past April.
>
> I'm not sure whether this is normal (package approved, processing to get
> it actually into unstable doesn't happen right away, no visible sign of
> package's status in the meantime), or whether it may mean that the
> package has been rejected.
>
> If the former, then all is well. If the latter, I'd be interested to
> know the status, both so I know what to expect and in case there's
> anything I can do to help the package get in on a subsequent try.
>

Indeed the package was rejected after two months in the queue, due to
things missing from the copyright file:

> +--+
> |   REJECT reasoning   |
> +--+
> 
> examples/completion seems to be copyright Etienne PIERRE and there does not
> seem to be reason that they too have relinquished copyright.
> 
> moosic/server/xmlrpc_registry.py has a different license.
> 
> +--+
> | N.B. |
> +--+
> 
> This review may not be exhaustive.  Please check your source package
> against your d/copyright and the ftpmaster REJECT-FAQ, throughly,
> before uploading to NEW again.

I'll try to find the time to go through the source and update this,
unless you beat me to it of course. :)

In any case we have missed the freeze by a mile, so we have a couple of
years to get this done before the next round.

-- 
Arto Jantunen

Bug#979010: libqalculate20: crashes cantor due to symbol conflict with poppler

[Vincent Legout]

Hi,

On Tue, Mar 09, 2021 at 05:32:20PM +0900, Norbert Preining wrote :
> Please put me or the Qt/KDE Team into Cc so that we can take appropriate
> actions.

I opened the 2 bugs just after my previous email:

- https://bugs.debian.org/984850
- https://bugs.debian.org/984851

Thanks,
Vincent

Bug#984884: libgcrypt20: Unknown error executing apt-key [Bullseye]

[Andreas Metzler]

Control: tags -1 moreinfo
Control: severity -1 normal

On 2021-03-09 Davide Prina  wrote:
[...]
> Some users in Italian mailing list have reported that they have an error
> when they try upgrade/install packages:
[...]
> dig the problem we found that they have the following files on their system:
[...]
> $ ls -l /lib/x86_64-linux-gnu/libgcrypt.so.20.1.5
> -rw-r--r-- 1 root root 1112184 14 gen  2017
> /lib/x86_64-linux-gnu/libgcrypt.so.20.1.5

> but these files are from package migrated to testing in:
> [2017-01-25] libgcrypt20 1.7.5-3 MIGRATED to testing (Debian testing
> watch)[¹]

> So for some reason when the library path change they have not been deleted.

Hello Davide,

1.7.5 is ancient, it was shipped in Debian during the development cycle
of Debian 9 (stretch) but was not part of the Debian 9 (stretch)
release. So the actual breakage happened when the user upgraded from
1.7.5-1/2/3 to some later version, using the Debian infrastructure
(dpkg, apt, kernel, filesystem) at this point of time, probably in
2017.

Another possibility would be that the user tried to upgrade from
pre-oldstable directly to current-testing, skipping releases. If that is
the case he/she is doing something we do not support.

Do you have any further information on the upgrade, which version of
libgcrypt was upgraded with what version of dpkg/apt to which version?

[...]
> I suggest to check that those file are removed from
> /lib/x86_64-linux-gnu/
> in all new libgcrypt20 new version, elsewhere when Bullseye become stable
> more user can have that problem.
[...]

Sure it is possible to apply a bandaid but this just scale. Packages
normally need to be able to rely on dpkg to work. If it is a wide-spread
problem the cost/benefit ration can make sense.

cu Andreas
-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'

Bug#983365: linphone-desktop: chat messages

[Dennis Filder]

I haven't had success in making that gitlab account.  It's probably
not possible for outsiders anymore (if it ever was).  I have not
gotten a reply yet on the linphone-users list either.

Bill has not responded to #984534 either in BTS or in private.

While looking through the linphone.org wiki I found the attached PHP
script which can be used to run your own instant messaging file
transfer server.  Maybe you could include it in your changes for the
freeze exception next to the READMEs where it can't do any harm.
Including it would be nice just to make users aware of the option.

Regards,
Dennis.


lft.php.gz
Description: application/gzip

Bug#984904: reportbug: differing behaviour between src:samba and --source samba

[Paul Wise]

Package: reportbug
Version: 7.10.3
Severity: normal

The reportbug behaviour differs between src:samba and --source samba,
the former asks for which binary package the bug is about while the
latter just goes directly to listing bugs in the samba source package,
ideally both would just go to the bug listing.

In case it matters, I don't have the samba binary package installed,
but I do have other binary packages from src:samba installed, see below

   $ reportbug src:samba
   Detected character set: UTF-8
   Please change your locale if this is incorrect.
   
   Using 'Paul Wise ' as your from address.
   Getting status for samba...
   Which of the following packages is the bug in?
   
1 ctdbclustered database to store temporary data
2 libnss-winbind  Samba nameservice integration plugins
3 libpam-winbind  Windows domain authentication integration plugin
4 libsmbclientshared library for communication with SMB/CIFS servers
5 libsmbclient-devdevelopment files for libsmbclient
6 libwbclient-dev Samba winbind client library - development files
7 libwbclient0Samba winbind client library
8 python3-samba   Python 3 bindings for Samba
9 registry-tools  tools for viewing and manipulating the Windows 
registry
   10 samba   SMB/CIFS file, print, and login server for Unix
   11 samba-commoncommon files used by both the Samba server and client
   12 samba-common-binSamba common files used by both the server and the 
client
   13 samba-dev   tools for extending Samba
   14 samba-dsdb-modules  Samba Directory Services Database
   15 samba-libs  Samba core libraries
   16 samba-testsuite test suite from Samba
   17 samba-vfs-modules   Samba Virtual FileSystem plugins
   18 smbclient   command-line SMB/CIFS clients for Unix
   19 winbind service to resolve user and group information from 
Windows NT servers
   
   Select one of these packages: 
   ...
   
   $ reportbug --source samba
   Detected character set: UTF-8
   Please change your locale if this is incorrect.
   
   Using 'Paul Wise ' as your from address.
   Getting status for samba...
   Will send report to Debian (per lsb_release).
   Querying Debian BTS for reports on samba (source)...
   112 bug reports found:
   
   Bugs with severity grave
   1) #971048  samba: CVE-2020-1472  [RESOLVED]
   
   Bugs with severity serious
   2) #927747  bind9_dlz backend is entirely broken in Debian
   
   Bugs with severity important
   3) #855918  samba: connection refused after reboot, fixable by systemctl 
restart smbd
   4) #864291  samba: CVE-2017-9461: infinite loop on bad-symlink resolution
   5) #866823  samba: does not follow symbolic links
   6) #883939  smbclient failing to connect with default protocol SMB3_11
   7) #912340  src:samba: Fails To Build Reproducibly
   8) #926474  smbclient: Can browse samba shares  as root but not as user
   9) #931717  samba: CUPS printing fails with NT_STATUS_LOGON_FAILURE in 
4.9.11+dfsg-1
  10) #942433  samba: Cannot mount share on samba3 server from samba4 
client: protocol negotiation failed
  11) #946419  samba-vfs-modules: Resource forks are truncated when written 
to fruit-enabled share
  12) #948671  libsmbclient: mounting a share from Windows XP fails on 
timeout
  13) #949697  samba4: samba 4 with ntpd wrong permission on 
/var/lib/samba/ntp_signd/socket
  14) #974868  samba: can't serve size-limited Time Machine shares on i386
  15) #984486  libsmbclient-dev: ffmpeg 4.3.2 FTBFS against libsmbclient.h
   (1-15/112) Is the bug you found listed above [y|N|b|m|r|q|s|f|e|?]?
   ...
   
   $ aptitude search '?source-package(^samba$)!dbgsym'  
   p   ctdb- clustered database to store temporary 
dat
   p   libnss-winbind  - Samba nameservice integration plugins  
  
   p   libpam-winbind  - Windows domain authentication 
integration
   i A libsmbclient- shared library for communication with 
SMB
   p   libsmbclient-dev- development files for libsmbclient 
  
   p   libwbclient-dev - Samba winbind client library - 
developmen
   i A libwbclient0- Samba winbind client library   
  
   i A python3-samba   - Python 3 bindings for Samba
  
   p   registry-tools  - tools for viewing and manipulating the 
Wi
   p   samba   - SMB/CIFS file, print, and login server 
fo
   i A samba-common- common files used by both the Samba 
serve
   i A samba-common-bin- Samba common files used by both the 
serve
   p   samba-dev   - tools for extending Samba  
  
   p   samba-dsdb-modules  - Samba Directory Services Database  
  
   i A samba-libs 

Bug#984903: gnome: Sound output device changes unexpectedly. It keeps changing back to Digitial Output (S/PDIF) -USB Audio despite being changed to another device.

[Joshua Brickel]

Package: gnome
Version: 1:3.38+3
Severity: normal
Tags: a11y
X-Debbugs-Cc: joshua.bric...@gmail.com

Under settings in gnome when I change to a different Audio Source it for some
reason at what seems like random times switches back to
its default of Digitial Output (S/PDIF).  This affects other sofware like VLC
which then all of a sudden stops playing the audio portion.


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

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

Versions of packages gnome depends on:
ii  avahi-daemon 0.8-5
ii  cheese   3.38.0-3
ii  cups-pk-helper   0.2.6-1+b1
ii  desktop-base 11.0.1
ii  evolution3.38.3-1
ii  evolution-plugins3.38.3-1
ii  file-roller  3.38.0-1
ii  gedit-plugins3.38.1-1
ii  gnome-calendar   3.38.2-1
ii  gnome-clocks 3.38.0-1
ii  gnome-color-manager  3.36.0-1
ii  gnome-core   1:3.38+3
ii  gnome-documents  3.34.0-2
ii  gnome-getting-started-docs   3.38.0-1
ii  gnome-maps   3.38.2-1
ii  gnome-music  3.36.7-1
ii  gnome-screenshot 3.38.0-1
ii  gnome-sound-recorder 3.38.0-3
ii  gnome-todo   3.28.1-6
ii  gnome-tweaks 3.34.0-4
ii  gnome-weather3.36.1-1
ii  gstreamer1.0-libav   1.18.3-1
ii  gstreamer1.0-plugins-ugly1.18.3-1
ii  libgsf-bin   1.14.47-1
ii  libproxy1-plugin-networkmanager  0.4.17-1
ii  libreoffice-calc 1:6.1.5-3+deb10u6
ii  libreoffice-gnome1:6.1.5-3+deb10u6
ii  libreoffice-impress  1:6.1.5-3+deb10u6
ii  libreoffice-writer   1:6.1.5-3+deb10u6
ii  network-manager-gnome1.20.0-3
ii  orca 3.38.2-1
ii  rhythmbox3.4.4-4
ii  rhythmbox-plugin-cdrecorder  3.4.4-4
ii  rhythmbox-plugins3.4.4-4
ii  rygel-playbin0.40.0-1
ii  rygel-tracker0.40.0-1
ii  seahorse 3.38.0.1-1
ii  shotwell 0.30.11-1
ii  simple-scan  3.38.1-1
ii  totem-plugins3.38.0-2
ii  xdg-user-dirs-gtk0.10-3

Versions of packages gnome recommends:
ii  gnome-games 1:3.38+3
ii  gnome-remote-desktop0.1.9-4
ii  nautilus-extension-brasero  3.12.2-6
ii  transmission-gtk3.00-1

Versions of packages gnome suggests:
pn  alacarte 
pn  empathy  
pn  firefox-esr-l10n-all | firefox-l10n-all  
pn  goobox | sound-juicer
pn  polari   
ii  vinagre  3.22.0-8
pn  webext-ublock-origin 

Versions of packages gnome-core depends on:
ii  adwaita-icon-theme3.38.0-1
ii  at-spi2-core  2.38.0-2
ii  baobab3.38.0-1
ii  caribou   0.4.21-7.1
ii  dconf-cli 0.38.0-2
ii  dconf-gsettings-backend   0.38.0-2
ii  eog   3.38.2-1
ii  evince3.38.2-1
ii  evolution-data-server 3.38.3-1
ii  firefox-esr   78.8.0esr-1
ii  fonts-cantarell   0.111-3
ii  gdm3  3.38.2.1-1
ii  gedit 3.38.1-1
ii  gkbd-capplet  3.26.1-1
ii  glib-networking   2.66.0-2
ii  gnome-backgrounds 3.38.0-1
ii  gnome-bluetooth   3.34.3-2
ii  gnome-calculator  3.38.2-1
ii  gnome-characters  3.34.0-1
ii  gnome-contacts3.38.1-1+b1
ii  gnome-control-center  1:3.38.4-1
ii  gnome-disk-utility3.38.2-1
ii  gnome-font-viewer 3.34.0-2+b1
ii  gnome-keyring 3.36.0-1
ii  gnome-logs3.36.0-2
ii  gnome-menus   3.36.0-1
ii  gnome-online-accounts 3.38.0-3
ii  gnome-online-miners   3.34.0-2
ii  gnome-session 3.38.0-3
ii  gnome-settings-daemon 3.38.1-3
ii  gnome-shell   3.38.3-3
ii  gnome-shell-extensions3.38.2-1
ii  gnome-software3.38.1-1
ii  gnome-sushi   3.38.0-1
ii  gnome-system-monitor  3.38.0-1
ii  gnome-terminal3.38.3-1
ii  gnome-themes-extra3.28-1
ii  gnome-user-docs   3.38.2-1
ii  gnome-user-share  

Bug#984902: mirror submission for mirror.sabay.com.kh

[Sabay]

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

Submission-Type: new
Site: mirror.sabay.com.kh
Type: leaf
Archive-architecture: amd64 arm64 armel armhf i386 mips mips64el mipsel powerpc 
ppc64el s390x
Archive-http: /debian/
Maintainer: Sabay 
Country: KH Cambodia
Location: Phnom Penh, Cambodia
Sponsor: Sabay https://sabay.com
Comment: Sync schedule: Every 6 hours (from ftp.th.debian.org/debian/)
 International connectivity: 300Mbps
 Domestic connectivity: 2x10Gbps
 IPv4 addresses: 118.67.201.33 & 118.67.200.33
 IPv6 addresses: 2405:aa00:1::33 & 2405:aa00:2::33
 




Trace Url: http://mirror.sabay.com.kh/debian/project/trace/
Trace Url: http://mirror.sabay.com.kh/debian/project/trace/ftp-master.debian.org
Trace Url: http://mirror.sabay.com.kh/debian/project/trace/mirror.sabay.com.kh

Bug#982998: chkrootkit chkproc uses incorrect value for max_pid

[Adrien CLERC]

On Wed, 17 Feb 2021 19:23:30 -0500 Greg Schmidt 
 wrote:


>
> grabbed the source and see that while reading thru the output from a 
'ps maux'

> the pid field is checked against MAX_PROCESSES
>
> ret = atol(p);
> if ( ret < 0 || ret > MAX_PROCESSES )
> {
> fprintf (stderr, " OooPS, not expected %ld value\n", ret);
> exit (2);
> }
>
> and

> #define MAX_PROCESSES 9

It *seems* that it should be set to the correct value: 
https://salsa.debian.org/pkg-security-team/chkrootkit/-/blob/debian/master/chkproc.c#L93


But I have the same issue here. So maybe __x86_64 isn't set as it should?

Adrien

Bug#984901: RFS: open-ath9k-htc-firmware/1.4.0-106-gc583009+dfsg1-2 -- firmware for AR7010 and AR9271 USB wireless adapters

[John Scott]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "open-ath9k-htc-firmware":

 * Package name    : open-ath9k-htc-firmware
   Version : 1.4.0-106-gc583009+dfsg1-2
   Upstream Author : Qualcomm Atheros and contributors
 * URL : https://github.com/qca/open-ath9k-htc-firmware
 * License : mostly Clear BSD 3 Clause
 * Vcs : https://salsa.debian.org/jscott/open-ath9k-htc-firmware
   Section : kernel

It builds those binary packages:

  firmware-ath9k-htc-udeb - firmware for AR7010 and AR9271 USB wireless
adapters
  firmware-ath9k-htc - firmware for AR7010 and AR9271 USB wireless
adapters

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

  https://mentors.debian.net/package/open-ath9k-htc-firmware/

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

  dget -x
https://mentors.debian.net/debian/pool/main/o/open-ath9k-htc-firmware/open-ath9k-htc-firmware_1.4.0-106-gc583009+dfsg1-2.dsc

Changes since the last upload:

 open-ath9k-htc-firmware (1.4.0-106-gc583009+dfsg1-2) experimental;
urgency=medium
 .
   * Add package version control info.
   * Clean up the copyright file.
 - Distinguish the BSD 3-Clause Clear variant from the conventional
one.
 - Make conformant to DEP-5 specification for machine readability.
   * Add a udeb for incorporation into the Debian Installer.
   * Build cross toolchain with Binutils 2.36 and GCC 11 with patch.

I cleaned up debian/rules somewhat as well. I've also written improved
AppStream metadata, but I'm waiting for that to be accepted upstream.
The principal purpose of this upload is to get the udeb through NEW,
although more work needs to be done in the Kernel Team's tooling before
it can be part of the installer.


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

Bug#984862: iptables-netflow-dkms: module wants to build with gcc instead of kernel's compiler

[Axel Beckert]

Hi Andreas,

Andreas Beckmann wrote:
> That error is very cryptic ... so let's run dkms manually

Ack.

> Check for working gcc: No
> ! You need gcc to install module from source
[...]
> Oh, your package insists on building the kernel module with gcc instead of
> getting the correct compiler (i.e. the same versioned gcc-X that was used to
> build the kernel and that is depended upon by the kernel header package used)
> from kbuild. A kernel module built with a different compiler version than the
> kernel itself may not work. The kernel is not neccessarily built with the
> same compiler version as gcc points to.

Correct. But how do I determine that kernel-specific compiler without
tracking down package dependencies? linux-compiler-gcc-10-x86 seems
not to provide a symlink or similar.

→ dpkg -L linux-compiler-gcc-10-x86
/.
/usr
/usr/share
/usr/share/doc
/usr/share/doc/linux-compiler-gcc-10-x86
/usr/share/doc/linux-compiler-gcc-10-x86/changelog.Debian.gz
/usr/share/doc/linux-compiler-gcc-10-x86/copyright

Or is tracking down package dependencies the way to go?

Actually I would have expected that DKMS already takes care of this.
Because I deliberately added this patch to avoid this situation:

-CC = gcc
+CC ?= gcc

> There are more dkms packages looking for a proper solution for this problem:
>   openafs-modules-dkms (#945506)
>   zfs-dkms (#946497)

I see. Thanks! Doesn't look very promising though.

> Please depend on gcc if you cannot find a way to use the kernel
> compiler.

Actually I thought that DKMS does this already, but I see that _any_ C
compiler can fulfil it's dependency. Hrm.

> You cannot expect build-essential to be available.

Correct. But that's also not needed, given dkms' dependencies.

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

Bug#984716: gocryptfs: data loos upon full root file system

[Felix Lechner]

Control: forwarded -1 https://github.com/rfjakob/gocryptfs/issues/550
Control: severity -1 important

Hi Matthias,

On Sun, Mar 7, 2021 at 8:39 AM Matthias Jäger  wrote:
>
> the encrypted data was missing.

Both upstream and I are stymied by your experience. I forwarded your
report upstream [1] where you can find a response from Jakob. Since
you are using the version in Debian stable, your issue is presumably
present in all versions of gocryptfs and therefore best tracked
upstream. Of course, you are still welcome to comment here.

[1] https://github.com/rfjakob/gocryptfs/issues/550

> I'm using a gocryptfs container.

It would be helpful if the bug could be reproduced—ideally, with
version 1.8.0-1.

> I can not be sure that this is caused by gocryptfs

Your loss of data warrants the highest severity, but your report is
about the stable version. Debian is currently in a release freeze,
which means your filing is also severe enough to keep version 1.8.0-1
out of bullseye. Meanwhile, I have used gocryptfs without problems for
several years in another complex setup (with kerberized NFSv4). We
also do not know for sure, as you stated, that gocryptfs is at fault.
For those reasons, I am downgrading this report to the highest non-RC
level—at least until bullseye is released.

Kind regards
Felix Lechner

Bug#984900: debhelper command printing buildsystem detection

[Jelmer Vernooij]

Package: debhelper
Version: 13.3.4
Severity: wishlist

For lintian-brush, it would be great if there was a command that printed the
buildsystem that debhelper would use in a directory.

At the moment, lintian-brush runs something like:

perl -w -MDebian::Debhelper::Dh_Lib -MDebian::Debhelper::Dh_Buildsystems -e 

Bug#984497: weasels and doves

[George N. White III]

On Mon, 8 Mar 2021 at 12:36, Andrius Merkys  wrote:

> Hi,
>
> On 2021-03-08 15:44, Albert van der Horst wrote:
> > I don't see the problem here. If there is a bug in an old version
> supplied with Debian, the bug report lands with Debian.
>
> Not necessary. Many users cannot tell whether a bug is caused by
> upstream code or Debian packaging. Many users do not know about Debian
> BTS. Thus Debian-specific bugs land in upstream trackers, and some
> upstreams do not want to provide support outside what they consider
> "canonical" use of their software.
>
> > Then Debian can solve the bug report by renewing upstream. Sot that bug
> report is not against the package, but against the packaging.
>
> True, but this might be slowed down by the update process in stable.
>
> > If it persists in the newest version, the bug can be passed to
> > upstream.
>
> Again - if the report ends up in Debian BTS.
>
> > Bug reports will not land at the developpers desk, or Debian has to take
> measures that they don't, e.g. by replacing e-mail addresses. No reasonable
> upstream developer will object to such an arrangement.
>
> Many users will not look into e-mail addresses. They will search online
> using the name of the software, and will arrive at the same developers'
> desk. This might be offset by renaming entire pieces of software, but
> renamed packages become hardly visible and all valuable online material
> related to the original name becomes hidden from users.
>

Renaming should be like "debian-sid-" for supported
by Debian packages.   There are, however, use-cases where packaging is not
helpful to users:

1. a package that relies on "customized" configurations of widely used
libraries
(hdf4 and gdal are examples of libraries with many optional extensions).

2. a package whose purpose is to provide highly optimized versions of common
libraries for low volume hardware (such as large HPC systems).   There are
many potential hardware configurations with new configurations being
released
multiple times a year.   There are complicated issues of reproducibility
and
testing that don't have one size fits all answers.

-- 
George N. White III

Bug#984899: buster-pu: package hwloc-contrib/1.11.12-3+deb10u1

[Samuel Thibault]

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

Hello,

I have uploaded a proposed 1.11.12-3+deb10u1 version of hwloc-contrib
for buster.

[ Reason ]
PowerPC systems provide much better bandwidth between CPUs and NVIDIA
GPUs thanks to NVLink, they are thus currently very often used for
running NVIDIA GPUs (top500.org has a lot of them for instance). But
hwloc currently does not show NVIDIA GPUs on ppc64el because the
hwloc-contrib package is not getting built there.  This makes it much
harder for applications to determine the locality of GPUs in the system
and thus where to place data etc. to get efficient execution.

This is not a regression over oldstable, which did not have it built on
ppc64el either.

[ Impact ]
If this isn't included, people will have to build hwloc by hand to get
the locality information and thus efficient execution.

[ Tests ]
The hwloc-contrib package has a full testsuite which I could run on a
ppc64el system.

[ Risks ]
There is no risk for the only other arch (amd64), because the change
disables the libcuda1 build-dep only on ppc64el, and it drops libcuda
from the link of a test which is not getting shipped anyway.

[ 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 ]
There is no libcuda1 on ppc64el, so this dependency had to be disabled.
This disables one test (cuda), but otherwise the functionalities of the
built package are the same.

The cudart test used to be linked against libcuda, but that was actually
spurious, upstream doesn't link it against libcuda any more since a long
time actually.

With regards,
Samuel
diff -Nru hwloc-contrib-1.11.12/debian/changelog 
hwloc-contrib-1.11.12/debian/changelog
--- hwloc-contrib-1.11.12/debian/changelog  2019-02-09 00:46:55.0 
+0100
+++ hwloc-contrib-1.11.12/debian/changelog  2021-03-10 00:22:29.0 
+0100
@@ -1,3 +1,11 @@
+hwloc-contrib (1.11.12-3+deb10u1) buster; urgency=medium
+
+  * control: Enable build on ppc64el with libcuda1 build-dep disabled.
+  * patches/cuda-ppc64el: Upstream fix for cudart test that does not actually
+need libcuda1.
+
+ -- Samuel Thibault   Wed, 10 Mar 2021 00:22:29 +0100
+
 hwloc-contrib (1.11.12-3) unstable; urgency=medium
 
   * control: Add libcuda1 dependency, not brought by nvidia-cuda-dev any more.
diff -Nru hwloc-contrib-1.11.12/debian/control 
hwloc-contrib-1.11.12/debian/control
--- hwloc-contrib-1.11.12/debian/control2019-02-09 00:46:06.0 
+0100
+++ hwloc-contrib-1.11.12/debian/control2021-03-09 23:55:17.0 
+0100
@@ -3,7 +3,7 @@
 Maintainer: Samuel Thibault 
 Build-Depends: debhelper (>= 9), libltdl-dev,
   valgrind [amd64 arm64 armhf i386 mips mipsel powerpc ppc64el s390x mips64el 
ppc64],
-  libx11-dev, libxext-dev, nvidia-cuda-dev, libcuda1, libxnvctrl-dev,
+  libx11-dev, libxext-dev, nvidia-cuda-dev, libcuda1 [!ppc64el], 
libxnvctrl-dev,
   libpciaccess-dev, pkg-config,
   libibverbs-dev [linux-any],
   ocl-icd-opencl-dev [!hurd-i386] | opencl-dev, opencl-headers,
@@ -18,7 +18,7 @@
 Vcs-Browser: https://github.com/open-mpi/hwloc-debian/tree/contrib
 
 Package: libhwloc-contrib-plugins
-Architecture: amd64
+Architecture: amd64 ppc64el
 Multi-Arch: same
 Depends: ${shlibs:Depends}, ${misc:Depends}, libhwloc5 (>= 
${source:Upstream-Version}~), libhwloc5 (<< ${source:Upstream-Version}A)
 Description: Hierarchical view of the machine - contrib plugins
diff -Nru hwloc-contrib-1.11.12/debian/patches/cuda-ppc64el 
hwloc-contrib-1.11.12/debian/patches/cuda-ppc64el
--- hwloc-contrib-1.11.12/debian/patches/cuda-ppc64el   1970-01-01 
01:00:00.0 +0100
+++ hwloc-contrib-1.11.12/debian/patches/cuda-ppc64el   2021-03-10 
00:21:15.0 +0100
@@ -0,0 +1,21 @@
+commit 542fb5677723e13980056ea5f1023b5120bd2e0d
+Author: Samuel Thibault 
+Date:   Wed Mar 10 00:20:05 2021 +0100
+
+tests/cudart: Do not link against libcuda
+
+ppc64el doesn't have libcuda and the cudart test does not need it anyway.
+
+diff --git a/tests/Makefile.am b/tests/Makefile.am
+index cc9ce5039..5129b8a34 100644
+--- a/tests/Makefile.am
 b/tests/Makefile.am
+@@ -104,7 +104,7 @@ openfabrics_verbs_LDADD = $(LDADD) -libverbs
+ myriexpress_LDADD = $(LDADD) -lmyriexpress
+ opencl_LDADD = $(LDADD) $(HWLOC_OPENCL_LIBS) $(HWLOC_OPENCL_LDFLAGS)
+ cuda_LDADD = $(LDADD) -lcuda
+-cudart_LDADD = $(LDADD) -lcuda -lcudart
++cudart_LDADD = $(LDADD) -lcudart
+ nvml_LDADD = $(LDADD) -lnvidia-ml
+ hwloc_bind_LDADD = $(LDADD)
+ if HWLOC_HAVE_PTHREAD
diff -Nru hwloc-contrib-1.11.12/debian/patches/series 
hwloc-contrib-1.11.12/debian/patches/series
--- hwloc-contrib-1.11.12/debian/patches/series 2019-02-09 00:46:08.0 
+0100
+++ hwloc-contrib-1.11.12/debian/patches/series 2021-03-10 00:02:11.0 
+0100
@@ -1,2 +1,3 @@
 

Bug#984898: ITP: elpa-docbook -- Info-like viewer for DocBook

[Martin]

Package: wnpp
Severity: wishlist
Owner: Martin 
X-Debbugs-Cc: debian-de...@lists.debian.org, debian-emac...@lists.debian.org

* Package name: elpa-docbook
  Version : 0.1
  Upstream Author : Chong Yidong 
* URL : https://elpa.gnu.org/packages/docbook.html
* License : GPL3+
  Programming Lang: Emacs-Lisp
  Description : Info-like viewer for DocBook

A simple, Info-like viewer for DocBook files.
Entry point: M-x docbook-find-file

Bug#984831: bugs.debian.org: should not emit semicolon as query param separator

[Don Armstrong]

Control: retitle -1 switch from semicolon ';' to ampersand '&' for query 
parameter separation

On Mon, 08 Mar 2021, Phil Morrell wrote:
> As reported on #debian-til, python can no longer parse bugs.d.o URLs
> correctly out of the box. The change was backported as a security update
> to 3.6+ so also affects buster.
> 
> https://bugs.python.org/issue42967

This looks like an issue in python's urllib. ';' are perfectly valid
query parameter separators for URIs and anything consuming debbugs URIs
should pass appropriate options to support them. That said, we probably should
switch away from semicolons as they are no longer recommended.

> From what I can tell, the search form and msg= use semicolon and I
> actually can't find any with ampersand.

Everything uses semicolon, but we can probably just make Debbugs::URI
call query_form instead of query_param.


-- 
Don Armstrong  https://www.donarmstrong.com

I would like to be the air
that inhabits you for a moment
only. I would like to be that unnoticed
& that necessary.
 -- Margaret Atwood "Poetry in Motion" p140

Bug#984897: Problems in a setup with two conflicting binary packages which share the same service name

[Santiago Garcia Mantinan]

Package: debhelper
Version: 13.3.4
Severity: normal
Tags: patch

Recently we decided to ship two binary versions of squid, one compiled with
gnutls and the other with openssl, as the code provides different features
depending with what is compiled.

I decided to produce two binary packages conflicting with each other, squid
and squid-openssl but that provide the same service squid.service

The problem comes when we purge one that is removed when the other is
installed, I see the problem on the automatic added sections of the postrm
script.

I have filled a bug on squid explaining the problem (#984880) and tried to
explain this here:

https://lists.debian.org/debian-mentors/2021/03/msg00022.html

The problem is with both dh_installinit and dh_installsystemd, I have
prepared a patch based on the dh_apparmor's code which does have checks for
this.

I don't know debhelper's code, and even tough this patch works ok for me,
the plural of #UNITFILES# makes me think that it can have several files on
it wich would make my patch fail on this case, I hope the patch gives you
the idea of what would be needed.

Fixing this bug would be needed to fix bug #984880 on squid for Bullseye, I
don't know if it is possible to have a fix for this on debhelper or if we
should try to woraround this on squid's postrm script, I hope that you can
have a look at this and let me know.

Regards.

-- System Information:
Debian Release: bullseye/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable'), (500, 'stable'), (101, 
'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 5.10.0-4-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_WARN, TAINT_FIRMWARE_WORKAROUND, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=gl_ES.UTF-8, LC_CTYPE=gl_ES.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 debhelper depends on:
ii  autotools-dev20180224.1+nmu1
ii  dh-autoreconf20
ii  dh-strip-nondeterminism  1.11.0-1
ii  dpkg 1.20.7.1
ii  dpkg-dev 1.20.7.1
ii  dwz  0.13+20210201-1
ii  file 1:5.39-3
ii  libdebhelper-perl13.3.4
ii  libdpkg-perl 1.20.7.1
ii  man-db   2.9.4-2
ii  perl 5.32.1-3
ii  po-debconf   1.0.21+nmu1

debhelper recommends no packages.

Versions of packages debhelper suggests:
ii  dh-make  2.202003

-- no debconf information
diff --git a/autoscripts/postrm-init b/autoscripts/postrm-init
index 1c292982..acd7dc76 100644
--- a/autoscripts/postrm-init
+++ b/autoscripts/postrm-init
@@ -1,3 +1,3 @@
-if [ "$1" = "purge" ] ; then
+if [ "$1" = "purge" ] && ! [ -e "/etc/init.d/#SCRIPT#" ]; then
update-rc.d #SCRIPT# remove >/dev/null
 fi
diff --git a/autoscripts/postrm-systemd b/autoscripts/postrm-systemd
index d95013b6..3850e016 100644
--- a/autoscripts/postrm-systemd
+++ b/autoscripts/postrm-systemd
@@ -4,7 +4,8 @@ if [ "$1" = "remove" ]; then
fi
 fi
 
-if [ "$1" = "purge" ]; then
+UNITFILES=#UNITFILES#
+if [ "$1" = "purge" ] && ! [ -e "/lib/systemd/system/$UNITFILES" ]; then
if [ -x "/usr/bin/deb-systemd-helper" ]; then
deb-systemd-helper purge #UNITFILES# >/dev/null || true
deb-systemd-helper unmask #UNITFILES# >/dev/null || true

Bug#982682: ansible: some syntax errors appear in the installation

[Lee Garrett]

On 09/03/2021 06:38, Louis-Philippe Véronneau wrote:
> I can confirm I can reproduce this bug. Had the same error message while
> upgrading to ansible 2.10.7-1 on a sid machine.
> 

Thanks for the update! I'll try to fix it with the next upload, however
I'm currently waiting for an unblock request to go through.

Bug#984896: buster-pu: package jquery/3.3.1~dfsg-3

[Roberto C. Sanchez]

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

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Dear Release Team,

[ Reason ]

I would like to fix CVE-2020-11022 and CVE-2020-11023.  The same fix has
been prepared for stretch and will be uploaded concurrently with the
buster fix.  The security team has marked these issues as no-dsa.

[ Impact ]

jquery would be vulnerable if not approved.

[ Tests ]

Backported patch was reviewed and approved by the Debian package
maintainers.  Sadly, no reproducers were released.

[ Checklist ]
  [x] *all* changes are documented in the d/changelog
  [x] I reviewed all changes and I approve them, along with the
  maintainers of jquery
  [x] attach debdiff against the package in (old)stable
  [N/A] the issue is verified as fixed in unstable (jquery is not
present in unstable/testing)

Regards,

- -Roberto

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEIYZ1DR4ae5UL01q7ldFmTdL1kUIFAmBH//4ACgkQldFmTdL1
kULu7w/+KzQq0SMV/rDPj/BUs+wyoeqGfvLiMhOcA019wDblB17wW2x/4kWQWCMa
75tXD7kep+6b1lLNBPj75fcC9xHNiV9XTGgAwViHOBQ85bxfbc1Zi0YEnXfrgjeG
vi1xtHeLUNgDrCG/+UQP8qJn7+asURfism9v1WhmH93jd8+J9AleHOvUR0WjUVz2
tKIHXPBNQ0yDbJO34HXzvXio7IvJxXlNZ+ivK0AlUQVwam1LThy+tCk4hob8NXQg
JGvomGG/GDbMnQ/yNMc3IRHVDas0nLbmaa026kcHE05pQjhdPYOYckL/Jl5MW84s
5L+foc1dfAi7A4a3Bo898FDkaJqD41VCAgKjUbjD0aBc38D310ksqGlep3scOqn0
uX5GUCWcvTg05OHCKGrd28YyYckUDDRaL1Ln0MtSfYGQGgG3DyXqAGpAPCxA6PeW
gGMuBDy3t68kkCQoAqYzqkpn/oTS+3T6LWm35/c2X5FJAChM9gsDAaJ3IaofX84x
pzPu6VX7O3cPLMaV7cBKj4Ix85iBdKNHKRZlbruiCxRtzWgiMyyDLhsaj4Fbp989
hWddYqdb6Wj01CCAoDkHvsfg6GuSd/WGiEt1MCP0EqDUQ6WRJjmugELCThYj7c3U
PXxNmveHtehpN7+5MG1lNlLJ8hLydLS5CfphwwCrsOF2+MfRzRk=
=WoIV
-END PGP SIGNATURE-
diff -Nru jquery-3.3.1~dfsg/debian/changelog jquery-3.3.1~dfsg/debian/changelog
--- jquery-3.3.1~dfsg/debian/changelog  2019-04-19 02:52:35.0 -0400
+++ jquery-3.3.1~dfsg/debian/changelog  2021-03-09 14:42:16.0 -0500
@@ -1,3 +1,13 @@
+jquery (3.3.1~dfsg-3+deb10u1) buster; urgency=high
+
+  * Non-maintainer upload by the LTS Team.
+  * Prevent untrusted code execution when passing untrusted HTML to DOM
+manipulation methods.  (CVE-2020-11022)
+  * Prevent untrusted code execution when passing HTML containing 
+elements to DOM manipulation methods.  (CVE-2020-11023)
+
+ -- Roberto C. Sánchez   Tue, 09 Mar 2021 14:42:16 -0500
+
 jquery (3.3.1~dfsg-3) unstable; urgency=medium
 
   * Team upload
diff -Nru jquery-3.3.1~dfsg/debian/patches/CVE-2020-11022.patch 
jquery-3.3.1~dfsg/debian/patches/CVE-2020-11022.patch
--- jquery-3.3.1~dfsg/debian/patches/CVE-2020-11022.patch   1969-12-31 
19:00:00.0 -0500
+++ jquery-3.3.1~dfsg/debian/patches/CVE-2020-11022.patch   2021-03-09 
14:42:16.0 -0500
@@ -0,0 +1,1749 @@
+From 1d61fd9407e6fbe82fe55cb0b938307aa0791f77 Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?Micha=C5=82=20Go=C5=82=C4=99biowski-Owczarek?=
+ 
+Date: Mon, 16 Mar 2020 21:49:29 +0100
+Subject: [PATCH] Manipulation: Make jQuery.htmlPrefilter an identity function
+
+Closes gh-4642
+
+(cherry picked from 90fed4b453a5becdb7f173d9e3c1492390a1441f)
+---
+ src/manipulation.js   |   9 +--
+ test/data/testinit.js |   2 +-
+ test/localfile.html   |   2 +-
+ test/unit/ajax.js |   8 +--
+ test/unit/attributes.js   |  46 ++---
+ test/unit/basic.js|  24 +++
+ test/unit/core.js |  14 ++--
+ test/unit/css.js  | 112 +++
+ test/unit/data.js |  20 +++---
+ test/unit/deprecated.js   |   2 +-
+ test/unit/dimensions.js   |  30 -
+ test/unit/effects.js  |  22 +++---
+ test/unit/event.js|  26 +++
+ test/unit/manipulation.js | 138 ++
+ test/unit/offset.js   |  10 +--
+ test/unit/selector.js |   4 +-
+ test/unit/traversing.js   |  22 +++---
+ test/unit/wrap.js |  12 ++--
+ 18 files changed, 246 insertions(+), 257 deletions(-)
+
+--- a/src/manipulation.js
 b/src/manipulation.js
+@@ -32,13 +32,6 @@
+ 
+ var
+ 
+-  /* eslint-disable max-len */
+-
+-  // See https://github.com/eslint/eslint/issues/3229
+-  rxhtmlTag = 
/<(?!area|br|col|embed|hr|img|input|link|meta|param)(([a-z][^\/\0>\x20\t\r\n\f]*)[^>]*)\/>/gi,
+-
+-  /* eslint-enable */
+-
+   // Support: IE <=10 - 11, Edge 12 - 13 only
+   // In IE/Edge using regex groups here causes severe slowdowns.
+   // See https://connect.microsoft.com/IE/feedback/details/1736512/
+@@ -235,7 +228,7 @@
+ 
+ jQuery.extend( {
+   htmlPrefilter: function( html ) {
+-  return html.replace( rxhtmlTag, "<$1>" );
++  return html;
+   },
+ 
+   clone: function( elem, dataAndEvents, deepDataAndEvents ) {
+--- a/test/data/testinit.js
 b/test/data/testinit.js
+@@ -244,7 +244,7 @@
+   }
+   wrapper.call( QUnit, title, function( assert ) {
+   var done = assert.async(),
+-  

Bug#969521: closed by Mike Hommey (Re: Bug#969174: firefox: FF80 broke webext-* add-ons on existing profiles and new profiles after three restarts)

[Vincent Bernat]

 ❦  9 mars 2021 21:03 GMT, Debian Bug Tracking System:

> This is not the same issue at all, and this is not new in FF80 either.
> It has been this way for, essentially, ever. If you want to file a
> separate bug for this, fine, but piling on this unrelated bug, with all
> its history being unrelated to this, is not helpful.

The original issue is in Browserpass web extension. Upgrading
Browserpass it fixes this issue.
-- 
Whenever you find that you are on the side of the majority, it is time
to reform.
-- Mark Twain

Bug#895055: ITP: python-sounddevice -- Python module to play and record sound

[Yaroslav Halchenko]

retitle -1 RFP: python3-sounddevice -- Python module to play and record sounds 
thanks
thanks

On Tue, 09 Mar 2021, Paul Menzel wrote:

> I also found an application requiring this Python library.

> The current version is 0.4.1 and probably the name now should be
> python3-sounddevice.

Thanks for chiming in

FWIW, unlikely I would find time to package it, so retitling to RFP

-- 
Yaroslav O. Halchenko
Center for Open Neuroscience http://centerforopenneuroscience.org
Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755
WWW:   http://www.linkedin.com/in/yarik

Bug#955540: chromium: Using ozone

[Guillem Jover]

Hi!

On Sat, 2021-03-06 at 15:50:44 +0100, Guillem Jover wrote:
> On Thu, 2021-01-21 at 16:31:29 +0100, Michel Le Bihan wrote:
> > I built Chromium with ozone, but I'm not sure if it's ready for Debian
> > yet. It will need testing. You can test it, if you want:
> > https://lebihan.pl/chromium/chromium_88.0.4324.96-ozone.tar
> > Currently, I only built for amd64.
> 
> Could you provide the patch needed to build with Ozone enabled? Even
> if it's trivial (which I assume it might be), it might make it easier
> for the maintainers to simply apply it?
> 
> Missing Ozone support means Chromium currently has bogus behavior with
> its tab handling, and it shows artifacts when watching videos in
> fullscreen mode in Wayland, so it would be nice to get this support
> uploaded, even if into experimental. I was having the same exact
> artifacts with Firefox using Xwayland, and enabling its Wayland support,
> made these disappear.

Ahem, I see that *you* are one of the maintainers! Sorry about
that. :)

Thanks,
Guillem

Bug#984846: netcfg: Default hostname hardcoded in netcfg-common

[Raphael Hertzog]

Hi,

Le mardi 09 mars 2021, Cyril Brulebois a écrit :
> My first reaction was “we could make that configurable on a per-vendor
> fashion” (e.g. via debian/rules) but reading you are already patching
> debian/netcfg-common.templates, why aren't you patching the two harcoded
> locations in the first place?

We are patching it because there's no other clean way to change the
default hostname for a derivative, see #719101 for another kali report
related to this.

But it would be really nice if we didn't have to patch any this udeb
(even though it's really not hardwork).

Le mardi 09 mars 2021, Arnaud Rebillout a écrit :
> It would be nice if instead it would default to the value that is set in
> 'netcfg/get_hostname'. However I'm nost sure how to achieve that, as
> I'm not familiar with the netcfg code at all, and it's not clear if we
> can still get this value at this moment in the code, or if it has been
> overwritten by the user's input.

Actually in #719101 I suggested to use a dedicated debconf variable to
control the default value... that value could be used in both places.

Cheers,
-- 
Raphaël Hertzog

Bug#984895: unblock: geeqie/1.6-8

[Andreas Rönnquist]

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

Please unblock package geeqie

The version in unstable has a patch cherry-picked from upstream which
fixes showing images when using wayland, which has been problematic
before, and it hasn't worked with some combinations of wayland and
libclutter. This fixes two bugs (#983207, #977189) with severity
important (and I fully believe that more bugs would be reported on the
package if the fix isn't included).

The patch fixes showing only a white image on some setups (wayland),
which before the patch needs a setting change, or cli option to fix.

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


unblock geeqie/1.6-8

-- Andreas Rönnquist
gus...@debian.org
diff -Nru geeqie-1.6/debian/changelog geeqie-1.6/debian/changelog
--- geeqie-1.6/debian/changelog	2021-02-27 13:36:57.0 +0100
+++ geeqie-1.6/debian/changelog	2021-03-09 20:17:40.0 +0100
@@ -1,3 +1,11 @@
+geeqie (1:1.6-8) unstable; urgency=medium
+
+  * Add patch to make image visible on wayland too, independent on
+if we are using the clutter library or not
+(Closes: #983207, #977189)
+
+ -- Andreas Rönnquist   Tue, 09 Mar 2021 20:17:40 +0100
+
 geeqie (1:1.6-7) unstable; urgency=medium
 
   * Add patch fixing regression --remote option failing
diff -Nru geeqie-1.6/debian/patches/0007-Fix-644-Images-fail-to-render-on-MacOS.patch geeqie-1.6/debian/patches/0007-Fix-644-Images-fail-to-render-on-MacOS.patch
--- geeqie-1.6/debian/patches/0007-Fix-644-Images-fail-to-render-on-MacOS.patch	1970-01-01 01:00:00.0 +0100
+++ geeqie-1.6/debian/patches/0007-Fix-644-Images-fail-to-render-on-MacOS.patch	2021-03-09 20:17:16.0 +0100
@@ -0,0 +1,317 @@
+From: Colin Clark 
+Date: Sat, 6 Mar 2021 13:23:46 +
+Subject: Fix #644: Images fail to render on MacOS
+
+https://github.com/BestImageViewer/geeqie/issues/644
+
+Change the way the "draw" signal is handled.
+
+Overlay guidelines are disabled.
+
+This patch also fixes showing the image on Wayland, without it we often
+only get a white rectangle where the image was supposed to show.
+
+---
+ src/image-overlay.c  |  51 +++--
+ src/renderer-tiles.c | 127 +++
+ 2 files changed, 143 insertions(+), 35 deletions(-)
+
+diff --git a/src/image-overlay.c b/src/image-overlay.c
+index 6116b5a..ff377e8 100644
+--- a/src/image-overlay.c
 b/src/image-overlay.c
+@@ -202,7 +202,6 @@ gint image_osd_histogram_get_mode(ImageWindow *imd)
+ void image_osd_toggle(ImageWindow *imd)
+ {
+ 	OsdShowFlags show;
+-
+ 	if (!imd) return;
+ 
+ 	show = image_osd_get(imd);
+@@ -522,30 +521,32 @@ static GdkPixbuf *image_osd_guidelines_render(OverlayStateData *osd)
+ 	GdkPixbuf *rectangles;
+ 	ImageWindow *imd = osd->imd;
+ 
+-	pixbuf_renderer_get_scaled_size((PixbufRenderer *)imd->pr, , );
+-
+-	if (width && height)
+-		{
+-		rectangles = gdk_pixbuf_new(GDK_COLORSPACE_RGB, TRUE, 8, width, height);
+-		if (rectangles)
+-			{
+-			pixbuf_set_rect_fill(rectangles, 0, 0, width, height, 255, 255, 255, 0);
+-			pixbuf_set_rect(rectangles, 0, 0 + (height / 3), width, height / 3,
+-0, 0, 0, 255,
+-1, 1, 1, 1);
+-			pixbuf_set_rect(rectangles, 0, 0 + (height / 3 + 1), width, height / 3 - 2,
+-255, 255, 255, 255,
+-1, 1, 1, 1);
+-
+-			pixbuf_set_rect(rectangles, 0 + width / 3, 0 , width / 3, height,
+-0, 0, 0, 255,
+-1, 1, 1, 1);
+-			pixbuf_set_rect(rectangles, 0 + width / 3 + 1, 0, width / 3 - 2, height,
+-255, 255, 255, 255,
+-1, 1, 1, 1);
+-			return rectangles;
+-			}
+-		}
++/* FIXME: guidelines does not work with revised draw signal handling
++ */
++	//~ pixbuf_renderer_get_scaled_size((PixbufRenderer *)imd->pr, , );
++
++	//~ if (width && height)
++		//~ {
++		//~ rectangles = gdk_pixbuf_new(GDK_COLORSPACE_RGB, TRUE, 8, width, height);
++		//~ if (rectangles)
++			//~ {
++			//~ pixbuf_set_rect_fill(rectangles, 0, 0, width, height, 255, 255, 255, 0);
++			//~ pixbuf_set_rect(rectangles, 0, 0 + (height / 3), width, height / 3,
++//~ 0, 0, 0, 255,
++//~ 1, 1, 1, 1);
++			//~ pixbuf_set_rect(rectangles, 0, 0 + (height / 3 + 1), width, height / 3 - 2,
++//~ 255, 255, 255, 255,
++//~ 1, 1, 1, 1);
++
++			//~ pixbuf_set_rect(rectangles, 0 + width / 3, 0 , width / 3, height,
++//~ 0, 0, 0, 255,
++//~ 1, 1, 1, 1);
++			//~ pixbuf_set_rect(rectangles, 0 + width / 3 + 1, 0, width / 3 - 2, height,
++//~ 255, 255, 255, 255,
++//~ 1, 1, 1, 1);
++			//~ return rectangles;
++			//~ }
++		//~ }
+ 
+ 	return NULL;
+ }
+diff --git a/src/renderer-tiles.c b/src/renderer-tiles.c
+index 9b4f049..cc0483a 100644
+--- a/src/renderer-tiles.c
 b/src/renderer-tiles.c
+@@ -1,6 +1,6 @@
+ /*
+  * Copyright (C) 2006 John Ellis
+- * 

Bug#895055: ITP: python-sounddevice -- Python module to play and record sound

[Paul Menzel]

Dear Yaroslav,


Am 06.04.18 um 21:47 schrieb Yaroslav Halchenko:

Package: wnpp
Severity: wishlist
Owner: Yaroslav Halchenko 

* Package name: python-sounddevice
   Version : 0.3.10
   Upstream Author : Matthias Geier 
* URL : http://python-sounddevice.readthedocs.io/
* License : MIT/X
   Programming Lang: Python
   Description : Python module to play and record sound

  This Python module provides bindings for the PortAudio library and a
  few convenience functions to play and record NumPy arrays containing
  audio signals.

  Needed for upcoming updated package of PsychoPy


I also found an application requiring this Python library.

The current version is 0.4.1 and probably the name now should be 
python3-sounddevice.



Kind regards,

Paul

Bug#982865:

[Jussi Pakkanen]

On Tue, 9 Mar 2021 at 21:51, Nicholas Brown  wrote:

> Will 0.57.1 be migrated to unstable? Or perhaps even to testing?
> (I'm keen to see the parallel LTO support in 0.57 available in Bullseye)

Unstable is frozen for build systems so 0.57 won't be allowed in
Bullseye. The version in unstable will only be updated after the
release.

Bug#984745: Processed: Bug#984745 marked as pending in snowball

[stefanor]

Whoops, debcommit doesn't handle --author correctly, it thought it was a
file, and left the other debian/* behind.

SR

-- 
Stefano Rivera
  http://tumbleweed.org.za/
  +1 415 683 3272

Bug#984894: python-azure: flaky autopkgtest: You need to call 'result' or 'wait' on all LROPoller you have created

[Paul Gevers]

Source: python-azure
Version: 20201208+git-3
Severity: serious
Tags: sid bullseye
X-Debbugs-CC: debian...@lists.debian.org
User: debian...@lists.debian.org
Usertags: flaky

Dear maintainer(s),

Your package has an autopkgtest, great. However, I looked into
the history of your autopkgtest [1] (because it is blocking
sphinx) and I noticed it fails regularly, while a rerun passes. I
copied some of the output at the bottom of this report.

Because the unstable-to-testing migration software now blocks on
regressions in testing, flaky tests, i.e. tests that flip between
passing and failing without changes to the list of installed packages,
are causing people unrelated to your package to spend time on these
tests.

Paul

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


=== FAILURES
===
 MgmtResourceLinksTest.test_application

pylib/devtools_testutils/mgmt_testcase.py:97: in tearDown
return super(AzureMgmtTestCase, self).tearDown()
pylib/devtools_testutils/azure_testcase.py:193: in tearDown
return super(AzureTestCase, self).tearDown()
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
_ _ _ _

self = 

def tearDown(self):
os.environ = self.original_env
# Autorest.Python 2.x
assert not [t for t in threading.enumerate() if
t.name.startswith("AzureOperationPoller")], \
"You need to call 'result' or 'wait' on all
AzureOperationPoller you have created"
# Autorest.Python 3.x
>   assert not [t for t in threading.enumerate() if
t.name.startswith("LROPoller")], \
"You need to call 'result' or 'wait' on all LROPoller you
have created"
E   AssertionError: You need to call 'result' or 'wait' on all
LROPoller you have created

pylib/azure_devtools/scenario_tests/base.py:158: AssertionError
-- Captured log call
---



OpenPGP_signature
Description: OpenPGP digital signature

Bug#982865:

[Nicholas Brown]

> Yes. You can test it yourself if you want, 0.57.1 is in experimental.

Fab, thanks.
Will 0.57.1 be migrated to unstable? Or perhaps even to testing?
(I'm keen to see the parallel LTO support in 0.57 available in Bullseye)

Bug#984891: pam: [INTL:sk] Slovak po-debconf translation

[Ladislav Michnovič]

Hi.
Yes, it's identical. I wrote to Ivan to submit my file as he is assigned
person assuming  there might be some internal check from automation.

You can keep Ivan's name for now.

Regards, Ladislav.

Dňa ut 9. 3. 2021, 20:32 Sam Hartman  napísal(a):

> > "helix84" == helix84   writes:
>
>
> helix84> .po attached
>
> I'm a bit confused.
> This po looks identical to the one  I received from
> Ladislav the other day and already checked in.
> (I didn't tag it pending because there was not a bug)
>
> Is there supposed to be a difference or are you just filing a bug to
> make sure  it gets included?
>
> Also, should I update the last translator to Ladislav?
>
>

Bug#984867: grub-pc reports "grub_verify_string not found"

[Carsten Wolf]

indeed this was a configuration problem.

while repeating: "dpkg-reconfigure grub-pc" the misconfiguration happened 
at the decition where to write grub to. either into the partition of 
rootfs or outside into raw-dev. which was the correct one.

thank you giving me the tipp - system is booting now perfectly
carsten :) 

Bug#984891: pam: [INTL:sk] Slovak po-debconf translation

[Sam Hartman]

> "helix84" == helix84   writes:


helix84> .po attached

I'm a bit confused.
This po looks identical to the one  I received from
Ladislav the other day and already checked in.
(I didn't tag it pending because there was not a bug)

Is there supposed to be a difference or are you just filing a bug to
make sure  it gets included?

Also, should I update the last translator to Ladislav?

Bug#981374: electrum: Ledger wallet not found: Library version for 'ledger' is incompatible.

[Adrian Bunk]

On Wed, Mar 10, 2021 at 01:44:00AM +0800, Shengjing Zhu wrote:
>...
> @bunk, why the severity is raised to serious? The package itself is
> functional for basic usage.

Missing dependencies are usually RC, and I was suspecting the severity 
might have been too low.

cu
Adrian

Bug#984893: python3-setuptools: Depends on uninstallable python3.7

[Paul Menzel]

Package: python3-setuptools
Version: 20.3.4-1
Severity: normal
Control: affects -1 python3-pip

Dear Debian folks,


Trying to install the package *python3-pip* it fails with the error below.

```
$ sudo LANG=C apt install python3-pip
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies:
 python3-setuptools : Depends: python3.7 but it is not installable
E: Unable to correct problems, you have held broken packages.
$ sudo LANG=C apt install python3-setuptools
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies:
 python3-setuptools : Depends: python3.7 but it is not installable
E: Unable to correct problems, you have held broken packages.
$ LANG=C apt show python3-setuptools
Package: python3-setuptools
Version: 53.0.0
Priority: optional
Section: python
Maintainer: Python Packaging Authority 
Installed-Size: 2867 kB
Depends: python3.7
Download-Size: 400 kB
APT-Sources: http://repo.vitexsoftware.cz sid/main amd64 Packages
Description: Python package setuptools converted by py2deb on February 
18, 2021 at 15:54


N: There is 1 additional record. Please use the '-a' switch to see it
```


Kind regards,

Paul

Bug#984892: unblock: libbio-db-ncbihelper-perl/1.7.6-4

[Étienne Mollier]

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

Please unblock package libbio-db-ncbihelper-perl

[ Reason ]
Current version of libbio-db-ncbihelper-perl in Testing, in
version 1.7.6-2, is affected by release critical bugs #983239
and #984475.  Due to the autopkgtest now marked "superficial",
I don't expect it will reach Testing on it's own past the hard
freeze date this Friday.

[ Impact ]
Removal of libbio-db-ncbihelper-perl from Testing would trigger
the removal of bioperl, and the entire ecosystem of Med packages
which are based on bioperl.  That represents more than 40 source
packages, some with relatively high popcon by Debian Med
standards.

[ Tests ]
I manually ran the test needing Internet on version 1.7.6-4 in
Sid and Testing, architectures amd64 and arm64 (schroot + qemu),
and modulo the minor failing test which is triggered by events
outside of our control and documented in #983239, they ran fine.
I also ran the build and autopkgtest suite in normal conditions
(superficial) without any issues on Sid and Testing, amd64 and
arm64, just in case.

[ Risks ]
Changes affect diverse test suites to not depend on the network
anymore, so should be more stable, yet superficial.  Also, I
don't see how the Breaks+Replace statement added to the control
file could break the package (but I might be surprised of
course).  Overall I think the risk of upgrading the package in
Testing is rather low.

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

[ Other info ]
The similar libbio-db-embl-perl, which had the same transitive
removal implications, made it's way to Testing fortunately.  But
I'm not too sure of the timing yet for libbio-db-biofetch-perl,
nor it's impact on the bioperl ecosystem.  I might open one
other unblock request for libbio-db-biofetch-perl this week end
if it turns out to be necessary.

unblock libbio-db-ncbihelper-perl/1.7.6-4


Have a nice day,  :)
-- 
Étienne Mollier 
Fingerprint:  8f91 b227 c7d6 f2b1 948c  8236 793c f67e 8f0d 11da
Sent from /dev/pts/1, please excuse my verbosity.
diff -Nru libbio-db-ncbihelper-perl-1.7.6/debian/changelog 
libbio-db-ncbihelper-perl-1.7.6/debian/changelog
--- libbio-db-ncbihelper-perl-1.7.6/debian/changelog2020-01-05 
07:56:13.0 +0100
+++ libbio-db-ncbihelper-perl-1.7.6/debian/changelog2021-03-04 
09:01:01.0 +0100
@@ -1,3 +1,24 @@
+libbio-db-ncbihelper-perl (1.7.6-4) unstable; urgency=medium
+
+  * Team upload.
+  * Breaks+Replaces: bioperl (<< 1.7.3)
+Closes: #984475
+
+ -- Andreas Tille   Thu, 04 Mar 2021 09:01:01 +0100
+
+libbio-db-ncbihelper-perl (1.7.6-3) unstable; urgency=medium
+
+  * Team upload.
+  * Prevent build time tests and autodep8-perl test to fetch resources on the
+Internet.
+Closes: #983238
+  * Ensured autopkgtest remained offline, and marked the smoke test as
+superficial, since all tests within are skipped without Internet access.
+  * Side-tracked maintainer notifications from debian-...@lists.debian.org to
+debian-med-packag...@lists.alioth.debian.org like the other packages.
+
+ -- Étienne Mollier   Mon, 22 Feb 2021 22:45:11 
+0100
+
 libbio-db-ncbihelper-perl (1.7.6-2) unstable; urgency=medium
 
   * Be more strict about the libbio-asn1-entrezgene-perl dependency
diff -Nru libbio-db-ncbihelper-perl-1.7.6/debian/control 
libbio-db-ncbihelper-perl-1.7.6/debian/control
--- libbio-db-ncbihelper-perl-1.7.6/debian/control  2020-01-05 
07:55:51.0 +0100
+++ libbio-db-ncbihelper-perl-1.7.6/debian/control  2021-03-04 
09:01:01.0 +0100
@@ -1,8 +1,7 @@
 Source: libbio-db-ncbihelper-perl
-Maintainer: Debian Med team 
-Uploaders: Michael R. Crusoe 
+Maintainer: Debian Med Packaging Team 

+Uploaders: Michael R. Crusoe 
 Section: perl
-Testsuite: autopkgtest-pkg-perl
 Priority: optional
 Build-Depends: debhelper-compat (= 12)
 Build-Depends-Indep: libbio-perl-perl,
@@ -34,6 +33,8 @@
  liburi-perl,
  libwww-perl,
  libxml-twig-perl
+Breaks: bioperl (<< 1.7.3)
+Replaces: bioperl (<< 1.7.3)
 Description: collection of routines useful for queries to NCBI databases
  Provides a single place to setup some common methods for querying NCBI web
  databases. Bio::DB::NCBIHelper just centralizes the methods for constructing
diff -Nru libbio-db-ncbihelper-perl-1.7.6/debian/rules 
libbio-db-ncbihelper-perl-1.7.6/debian/rules
--- libbio-db-ncbihelper-perl-1.7.6/debian/rules2020-01-04 
12:44:53.0 +0100
+++ libbio-db-ncbihelper-perl-1.7.6/debian/rules2021-03-04 
09:01:01.0 +0100
@@ -1,10 +1,7 @@
 #!/usr/bin/make -f
 
-ifneq (,$(DEB_MAINTAINER_MODE))
-NETWORK = --network
-else()
-export NO_NETWORK_TESTING
-endif
+# prevent the test suite to fetch resources on the Internet at build time.
+export NO_NETWORK_TESTING=1
 
 %:
dh $@
diff -Nru 

Bug#984890: assembly-stats FTCBFS: uses DEB_BUILD_GNU_TYPE

[Nilesh Patra]

Package: assembly-stats
Version: 1.0.1+ds-2
Severity: normal
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs
X-Debbugs-Cc: nil...@debian.org

Dear Maintainer,

assembly-stats FTCBFS due to two reasons:

* It forces compilation of test files, report with patch has
  been submitted in #984889
* It uses DEB_BUILD_GNU_TYPE for installing. Using this is never
  right and it should and must be replaced with DEB_HOST_GNU_TYPE

Patch for the first reason is attached in the corresponding bug report #984889
The patch for the latter is attached below:

diff --git a/debian/rules b/debian/rules
index 9f13e4b..2a1e95a 100755
--- a/debian/rules
+++ b/debian/rules
@@ -15,4 +15,4 @@ override_dh_auto_configure:
dh_auto_configure -- -DBUILD_TESTS=$(if $(filter 
nocheck,$(DEB_BUILD_OPTIONS)),OFF,ON)

 override_dh_auto_install:
-   dh_install obj-$(DEB_BUILD_GNU_TYPE)/assembly-stats usr/bin
+   dh_install obj-$(DEB_HOST_GNU_TYPE)/assembly-stats usr/bin

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

Kernel: Linux 5.7.0-2-amd64 (SMP w/8 CPU threads)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: unable to detect

Versions of packages assembly-stats depends on:
ii  libc6   2.31-3
ii  libgcc-s1   11-20210220-1
ii  libstdc++6  11-20210220-1

assembly-stats recommends no packages.

assembly-stats suggests no packages.

-- no debconf information

Bug#984891: pam: [INTL:sk] Slovak po-debconf translation

[helix84]

Package: pam
Priority: wishlist
Tags: l10n patch
Version: 1.4.0-6

.po attached

~~helix84


sk.po
Description: Binary data

Bug#984889: assembly-stats natively FTBFS: error: gtest/gtest.h: No such file or directory

[Nilesh Patra]

Package: assembly-stats
Version: 1.0.1+ds-2
Severity: important
X-Debbugs-Cc: nil...@debian.org
Control: tags -1 patch

Dear Maintainer,

assembly-stats natively FTBFS reason being it forcefully compiles test
files, while the test dependency libgtest-dev is annotated with 

It should respect the nocheck option, and not compile the test files in
such a case.

In order to reproduce this, pass DEB_BUILD_OPTIONS=nocheck and set build
profile to nocheck as well. With sbuild:

$ DEB_BUILD_OPTIONS=nocheck sbuild -j5 -d unstable --source-only-changes 
--run-lintian --lintian-opts='--color always --display-info 
--display-experimental --pedantic' --profiles=nocheck

and it results in error:
/usr/bin/c++  -I/usr/include/gtest -Wall -O3 -pthread -o 
CMakeFiles/runUnitTests.dir/stats_unittest.cpp.o -c 
/<>/stats_unittest.cpp
/<>/filetype_unittest.cpp:2:10: fatal error: gtest/gtest.h: No 
such file or directory
2 | #include "gtest/gtest.h"
  |  ^~~
compilation terminated.
make[3]: *** [CMakeFiles/runUnitTests.dir/build.make:111: 
CMakeFiles/runUnitTests.dir/filetype_unittest.cpp.o] Error 1
make[3]: *** Waiting for unfinished jobs
/<>/stats_unittest.cpp:2:10: fatal error: gtest/gtest.h: No such 
file or directory
2 | #include "gtest/gtest.h"
  |  ^~~
compilation terminated.
/<>/fastq_unittest.cpp:5:10: fatal error: gtest/gtest.h: No such 
file or directory
5 | #include "gtest/gtest.h"
  |  ^~~
compilation terminated.
make[3]: *** [CMakeFiles/runUnitTests.dir/build.make:124: 
CMakeFiles/runUnitTests.dir/stats_unittest.cpp.o] Error 1
make[3]: *** [CMakeFiles/runUnitTests.dir/build.make:98: 
CMakeFiles/runUnitTests.dir/fastq_unittest.cpp.o] Error 1
/<>/fasta_unittest.cpp:3:10: fatal error: gtest/gtest.h: No such 
file or directory
3 | #include "gtest/gtest.h"
  |  ^~~
compilation terminated.
make[3]: *** [CMakeFiles/runUnitTests.dir/build.make:85: 
CMakeFiles/runUnitTests.dir/fasta_unittest.cpp.o] Error 1
make[3]: Leaving directory '/<>/obj-x86_64-linux-gnu'
make[2]: *** [CMakeFiles/Makefile2:251: CMakeFiles/runUnitTests.dir/all] Error 2
make[2]: *** Waiting for unfinished jobs

The patch for the same is given below:

diff --git a/debian/patches/do-not-test-forcefully.patch 
b/debian/patches/do-not-test-forcefully.patch
new file mode 100644
index 000..1fc749f
--- /dev/null
+++ b/debian/patches/do-not-test-forcefully.patch
@@ -0,0 +1,23 @@
+--- a/CMakeLists.txt
 b/CMakeLists.txt
+@@ -5,11 +5,15 @@
+
+ file(COPY test_files DESTINATION ${CMAKE_CURRENT_BINARY_DIR})
+ #add_subdirectory(gtest-1.7.0)
+-enable_testing()
+-include_directories(/usr/include/gtest)
+-add_executable(runUnitTests fasta_unittest.cpp fastq_unittest.cpp 
filetype_unittest.cpp stats_unittest.cpp)
+-target_link_libraries(runUnitTests gtest gtest_main fasta fastq filetype 
stats)
+-add_test(runUnitTests runUnitTests)
++option(BUILD_TESTS "Parameter to enable/disable build time tests" ON)
++
++if(BUILD_TESTS)
++  enable_testing()
++  include_directories(/usr/include/gtest)
++  add_executable(runUnitTests fasta_unittest.cpp fastq_unittest.cpp 
filetype_unittest.cpp stats_unittest.cpp)
++  target_link_libraries(runUnitTests gtest gtest_main fasta fastq 
filetype stats)
++  add_test(runUnitTests runUnitTests)
++endif()
+
+ add_library(fasta fasta.cpp)
+ add_library(fastq fastq.cpp)
diff --git a/debian/patches/series b/debian/patches/series
index 9fc23ad..49aafd6 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -1 +1,2 @@
 use_debian_packages_gtest.patch
+do-not-test-forcefully.patch
diff --git a/debian/rules b/debian/rules
index aae41d2..9f13e4b 100755
--- a/debian/rules
+++ b/debian/rules
@@ -11,5 +11,8 @@ export DEB_BUILD_MAINT_OPTIONS=hardening=+all
 %:
dh $@

+override_dh_auto_configure:
+   dh_auto_configure -- -DBUILD_TESTS=$(if $(filter 
nocheck,$(DEB_BUILD_OPTIONS)),OFF,ON)
+
 override_dh_auto_install:
dh_install obj-$(DEB_BUILD_GNU_TYPE)/assembly-stats usr/bin


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

Kernel: Linux 5.7.0-2-amd64 (SMP w/8 CPU threads)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: unable to detect

Versions of packages assembly-stats depends on:
ii  libc6   2.31-3
ii  libgcc-s1   11-20210220-1
ii  libstdc++6  11-20210220-1

assembly-stats recommends no packages.

assembly-stats suggests no packages.

-- no debconf information

Bug#982274: usr.lib.libreoffice.program.soffice.bin: temporary files are not allowed due to length change

[Vincas Dargis]

2021-03-09 20:40, Rene Engelhard rašė:

I've looked at the
https://salsa.debian.org/libreoffice-team/libreoffice/libreoffice/-/commit/03ba395bbe21154efc8a05dfbb9f7c16946eb4d2
diff linked in one of the posts and I see 11 question marks, not 9.
> Hmm, indeed. My bad.


That means we need to do some distinction like you suggested? The
original report just said basically "works if I add another digit", so
that was what I did :-)


Best would be to find source code and see how these random paths are actually generated, instead of guessing. If it's 
really 9-to-11, my solution fits.



Complain-by-default is really bad policy, is there a hope to change
that (having it without complain mode, but with "disabled" symlink)?


Personal opinion: I actually consider "ship a profile disabled" even
worse than "complain" since stuff won't even be seen. As of now you see
ALLOWED in  the logs at least.


I disagree, as in my case, you can *lose* confinement (security) "silently" after upgrade (when flags=complain returns), 
as in this my LibreOffice case. And, for example, Thunderbird package does upgrade it's AppArmor profile, probably 
because it's allowed do get new upstream Thunderbird version too, as a exception?


As for visibility, I agree it could be better. For example, maybe `aa-status` could list disabled profiles too. Of 
course, profile might be corrupted/buggy/unparsable (and that's why disabled) so care should be taken, but maybe that 
would help a bit.


ALLOWED is useful, but maybe we who cares about AppaArmor profiles can just use profiles enforced and report bugs in 
Sid, as expected. Well, I did, but got silently "complained"...

Bug#984888: pam-mysql: Newly added test with 323 hashed passwords fail on s390x

[Balint Reczey]

Source: pam-mysql
Version: 0.8.1-4
Severity: normal

Dear Maintainer,

Autopkgtests are failing in CI on s390x due to the following newly added tests:

debian/tests/auth:
...
'mysql': { 'crypt':  2, '323': 'false', 'hash':
'*1A8A8D8A90F03E8A15D4FFB3FC91A4693F077A84' }, # select
PASSWORD('foopwd')

...

https://ci.debian.net/packages/p/pam-mysql/testing/s390x/
https://ci.debian.net/data/autopkgtest/testing/s390x/p/pam-mysql/10949034/log.gz
:
...
OK: Y_MD5: correct password accepted
OK: Y_MD5: incorrect password refused
FAIL: mysql: correct password refused
OK: mysql: incorrect password refused
...

Cheers,
Balint

-- 
Balint Reczey
Ubuntu & Debian Developer

Bug#983390: mesa-vulkan-drivers: bad interactions between VkLayer_MESA_device_select and other layers

[Simon McVittie]

On Tue, 23 Feb 2021 at 12:20:08 +, Simon McVittie wrote:
> The device selection layer in Mesa 20.3.x >= 20.3.4 and 21.0.x >= 21.0.0~rc2
> has problematic interactions with other Vulkan layers, in particular
> MangoHUD. The bad interactions seem to be relatively complicated (dependent
> on other components), and particularly likely to be triggered when using
> Wine with DXVK.
...
> The attached patch from upstream appears to resolve this. I'm talking to
> an upstream Mesa maintainer about getting this into point releases, but
> it would also be great if you could make sure this gets into Debian 11.0.

A follow-up fix for this seems to be needed to avoid regressions:
https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9462

smcv

Bug#982274: usr.lib.libreoffice.program.soffice.bin: temporary files are not allowed due to length change

[Rene Engelhard]

Hi,

Am 09.03.21 um 19:27 schrieb Vincas Dargis:
> Changing rule into this:
>>>
>>> owner @{libo_user_dirs}/{,**/}lu?{,?,??}.tmp rwk, #Temporary
>>> file used when saving
>>>
>>> Did the trick (needed 9 symbol variant).
>>
>> As was done.
>>
>>
>> If you would actually have read the bug you would have seen that.
>
> I've looked at the
> https://salsa.debian.org/libreoffice-team/libreoffice/libreoffice/-/commit/03ba395bbe21154efc8a05dfbb9f7c16946eb4d2
> diff linked in one of the posts and I see 11 question marks, not 9.
>
Hmm, indeed. My bad.

That means we need to do some distinction like you suggested? The
original report just said basically "works if I add another digit", so 
that was what I did :-)


>> No one claimed this was fixed in 7.0.4.
>>
>> 7.0.x is in freeze. (It is in git for 7.0.x though should  there ever be
>> an  upload,)
>
>
> So this means that's it, profile will be defunct as users will not be
> able to save on Bullseye with profile enabled? :(
>
Jup, unfortunately.

> Complain-by-default is really bad policy, is there a hope to change
> that (having it without complain mode, but with "disabled" symlink)?

Personal opinion: I actually consider "ship a profile disabled" even
worse than "complain" since stuff won't even be seen. As of now you see
ALLOWED in  the logs at least.


Regards,


Rene

Bug#984887: ceres-solver: move documentation dependencies to Build-Depends-Indep

[Helmut Grohne]

Source: ceres-solver
Version: 1.14.0-14
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: cross-satisfiability

ceres-solver cannot be cross built from source, because its
Build-Depends are not satisfiable. A relatively simple technique to
reduce them is demote documentation dependencies to Build-Depends-Indep.
Doing so is not entirely trivial here, because an arch-only build still
builds the documentation. The attached patch achieves the reduction in a
reproducible way (i.e. an amd64 full build exactly reproduces the .debs
of an arch-only build). Please consider applying it.

Helmut
diff --minimal -Nru ceres-solver-1.14.0/debian/changelog 
ceres-solver-1.14.0/debian/changelog
--- ceres-solver-1.14.0/debian/changelog2021-02-22 21:34:16.0 
+0100
+++ ceres-solver-1.14.0/debian/changelog2021-03-09 07:53:14.0 
+0100
@@ -1,3 +1,10 @@
+ceres-solver (1.14.0-14.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Move documentation dependencies to B-D-I. (Closes: #-1)
+
+ -- Helmut Grohne   Tue, 09 Mar 2021 07:53:14 +0100
+
 ceres-solver (1.14.0-14) unstable; urgency=medium
 
   * [9cb79f7] Disable failure on file remove. (Closes: #983101)
diff --minimal -Nru ceres-solver-1.14.0/debian/control 
ceres-solver-1.14.0/debian/control
--- ceres-solver-1.14.0/debian/control  2021-02-22 21:34:16.0 +0100
+++ ceres-solver-1.14.0/debian/control  2021-03-09 07:52:50.0 +0100
@@ -11,16 +11,16 @@
libgflags-dev,
libeigen3-dev (>= 3.3.4),
libsuitesparse-dev (>= 1:4.4.3),
-   python3,
-   python3-sphinx,
-   python3-sphinx-rtd-theme,
-   libjs-jquery,
-   libjs-mathjax,
-   libjs-modernizr,
-   libjs-underscore,
-   libjs-sphinxdoc,
-   node-html5shiv,
awk
+Build-Depends-Indep: python3,
+ python3-sphinx,
+ python3-sphinx-rtd-theme,
+ libjs-jquery,
+ libjs-mathjax,
+ libjs-modernizr,
+ libjs-underscore,
+ libjs-sphinxdoc,
+ node-html5shiv,
 Standards-Version: 4.5.0
 Vcs-Browser: https://salsa.debian.org/science-team/ceres-solver
 Vcs-Git: https://salsa.debian.org/science-team/ceres-solver.git
diff --minimal -Nru ceres-solver-1.14.0/debian/rules 
ceres-solver-1.14.0/debian/rules
--- ceres-solver-1.14.0/debian/rules2021-02-22 21:34:16.0 +0100
+++ ceres-solver-1.14.0/debian/rules2021-03-09 07:51:47.0 +0100
@@ -39,7 +39,7 @@
-DSUITESPARSE_INCLUDE_DIR_HINTS=/usr/include/suitesparse/ \
-DCXSPARSE_LIBRARY_DIR_HINTS=/usr/lib/${DEB_HOST_MULTIARCH}/ \
-DCXSPARSE_INCLUDE_DIR=/usr/include/suitesparse/ \
-   -DBUILD_DOCUMENTATION=ON \
+   -DBUILD_DOCUMENTATION=$(if $(filter ceres-solver-doc,$(shell 
dh_listpackages)),ON,OFF) \
-DCMAKE_BUILD_TYPE=Release
dh_auto_build
dh_auto_test
@@ -66,7 +66,7 @@
mv -v ${CURDIR}/debian/config.h 
${CURDIR}/debian/libceres-dev/usr/include/ceres/internal/
dh_install
 
-override_dh_installdocs:
+override_dh_installdocs-indep:
# make lintian happy
# https://cdnjs.cloudflare.com/ajax/libs/mathjax/2.7.0 -> 
/usr/share/javascript/mathjax
sed -i 
's/https:\/\/cdnjs.cloudflare.com\/ajax\/libs\/mathjax\/2.7.1/\/usr\/share\/javascript\/mathjax/g'
 $(CURDIR)/debian/tmp/usr/share/doc/ceres/html/*.html

Bug#827479: newgrp: use CAP_SETGID instead of setuid on platforms that support it

[Laurent Bigonville]

Package: login
Version: 1:4.8.1-1
Followup-For: Bug #827479

Hello,

The executables installed by newgrp and uidmap are still today setuid
instead of using capabilities

When looking at the build system, it seems tha the newuidmap and
newgidmap are actually meant use the file capabilities instead of being
setuid:


src/Makefile.am:setcap cap_setuid+ep $(DESTDIR)$(ubindir)/newuidmap
src/Makefile.am:setcap cap_setgid+ep $(DESTDIR)$(ubindir)/newgidmap

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

Kernel: Linux 5.10.0-4-amd64 (SMP w/8 CPU threads)
Locale: LANG=fr_BE.UTF-8, LC_CTYPE=fr_BE.UTF-8 (charmap=UTF-8), 
LANGUAGE=fr_BE:fr
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: SELinux: enabled - Mode: Permissive - Policy name: refpolicy

Versions of packages login depends on:
ii  libaudit1   1:3.0-2
ii  libc6   2.31-9
ii  libcrypt1   1:4.4.17-1
ii  libpam-modules  1.4.0-6
ii  libpam-runtime  1.4.0-6
ii  libpam0g1.4.0-6

login recommends no packages.

login suggests no packages.

-- no debconf information

Bug#982274: usr.lib.libreoffice.program.soffice.bin: temporary files are not allowed due to length change

[Vincas Dargis]

2021-03-08 21:51, Rene Engelhard wrote:

Yes, it is done.

In 7.1. As the version tracking info clearly showed.


Ouch.. I've missed the version number, sorry...


Changing rule into this:

owner @{libo_user_dirs}/{,**/}lu?{,?,??}.tmp rwk, #Temporary
file used when saving

Did the trick (needed 9 symbol variant).


As was done.


If you would actually have read the bug you would have seen that.


I've looked at the 
https://salsa.debian.org/libreoffice-team/libreoffice/libreoffice/-/commit/03ba395bbe21154efc8a05dfbb9f7c16946eb4d2 diff 
linked in one of the posts and I see 11 question marks, not 9.



No one claimed this was fixed in 7.0.4.

7.0.x is in freeze. (It is in git for 7.0.x though should  there ever be
an  upload,)



So this means that's it, profile will be defunct as users will not be able to 
save on Bullseye with profile enabled? :(

I wish I enabled it before.. I *was* using it in enforce mode some time ago, and even proposed some fixes upsteam, but 
probably forgot to re-enforce after some upgrade.


Complain-by-default is really bad policy, is there a hope to change that (having it without complain mode, but with 
"disabled" symlink)?

Bug#984886: buster-pu: package xcftools/1.0.7-6

[Markus Koschany]

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

Dear release team,

[ Reason ]

I would like to fix CVE-2019-5086 and CVE-2019-5087. The same fix has
been applied in unstable and stretch already. The security team marked
these issues as no-dsa.

[ Impact ]

xcftools would still be vulnerable if not approved.

[ Tests ]
Tested with a manipulated xcf file.

[ 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

Regards,

Markus
diff -Nru xcftools-1.0.7/debian/changelog xcftools-1.0.7/debian/changelog
--- xcftools-1.0.7/debian/changelog 2016-05-18 12:34:05.0 +0200
+++ xcftools-1.0.7/debian/changelog 2021-02-09 23:17:14.0 +0100
@@ -1,3 +1,16 @@
+xcftools (1.0.7-6+deb10u1) buster; urgency=medium
+
+  * Non-maintainer upload by the LTS team.
+  * Fix CVE-2019-5086 and CVE-2019-5087:
+An exploitable integer overflow vulnerability exists in the
+flattenIncrementally function in the xcf2png and xcf2pnm binaries of
+xcftools. An integer overflow can occur while walking through tiles that
+could be exploited to corrupt memory and execute arbitrary code. In order
+to trigger this vulnerability, a victim would need to open a specially
+crafted XCF file.
+
+ -- Markus Koschany   Tue, 09 Feb 2021 23:17:14 +0100
+
 xcftools (1.0.7-6) unstable; urgency=medium
 
   * Team upload (collab-maint)
diff -Nru xcftools-1.0.7/debian/patches/CVE-2019-5086-and-CVE-2019-5087.patch 
xcftools-1.0.7/debian/patches/CVE-2019-5086-and-CVE-2019-5087.patch
--- xcftools-1.0.7/debian/patches/CVE-2019-5086-and-CVE-2019-5087.patch 
1970-01-01 01:00:00.0 +0100
+++ xcftools-1.0.7/debian/patches/CVE-2019-5086-and-CVE-2019-5087.patch 
2021-02-09 23:17:14.0 +0100
@@ -0,0 +1,53 @@
+From: Markus Koschany 
+Date: Mon, 8 Feb 2021 17:57:56 +0100
+Subject: CVE-2019-5086 and CVE-2019-5087
+
+Patch by Anton Gladky and Markus Koschany.
+
+Bug-Debian: https://bugs.debian.org/945317
+Origin: https://github.com/j-jorge/xcftools/pull/15
+---
+ xcf-general.c | 23 +++
+ 1 file changed, 23 insertions(+)
+
+diff --git a/xcf-general.c b/xcf-general.c
+index 9d0b4dc..7cb1613 100644
+--- a/xcf-general.c
 b/xcf-general.c
+@@ -19,6 +19,8 @@
+ #include "xcftools.h"
+ #include 
+ #include 
++#include 
++#include 
+ #ifdef HAVE_ICONV
+ # include 
+ #elif !defined(ICONV_CONST)
+@@ -182,6 +184,27 @@ xcfString(uint32_t ptr,uint32_t *after)
+ void
+ computeDimensions(struct tileDimensions *d)
+ {
++  // [ CVE-2019-5086 and CVE-2019-5087 ]
++  // This part of the code is the check to prevent integer overflow, see 
CVE-2019-5086 and CVE-2019-5087
++
++  if (d->c.l < INT_MIN/4) {
++fprintf(stderr,("d->c.l is too small (%d)! Stopping execution...\n"), 
(d->c.l));
++exit(0);
++  }
++  if (d->c.t < INT_MIN/4) {
++fprintf(stderr,("d->c.t is too small (%d)! Stopping execution...\n"), 
(d->c.t));
++exit(0);
++  }
++  if (d->width > (INT_MAX - d->c.l)/4) {
++fprintf(stderr,("Width is too large (%d)! Stopping execution...\n"), 
(d->c.l + d->width));
++exit(0);
++  }
++  if (d->height > (INT_MAX - d->c.t)/4) {
++fprintf(stderr,("Height is too large (%d)! Stopping execution...\n"), 
(d->c.t + d->height));
++exit(0);
++  }
++  // [ CVE-2019-5086 and CVE-2019-5087 ]
++
+   d->c.r = d->c.l + d->width ;
+   d->c.b = d->c.t + d->height ;
+   d->tilesx = (d->width+TILE_WIDTH-1)/TILE_WIDTH ;
diff -Nru xcftools-1.0.7/debian/patches/series 
xcftools-1.0.7/debian/patches/series
--- xcftools-1.0.7/debian/patches/series2016-05-18 12:27:32.0 
+0200
+++ xcftools-1.0.7/debian/patches/series2021-02-09 23:17:14.0 
+0100
@@ -4,3 +4,4 @@
 fix-as-needed-linking
 libpng16.patch
 fix-test-UTF8.patch
+CVE-2019-5086-and-CVE-2019-5087.patch

Bug#981374: electrum: Ledger wallet not found: Library version for 'ledger' is incompatible.

[Shengjing Zhu]

Control: reassign -1 python3-btchip 0.1.31-1
Control: retitle -1 Miss python3-ecdsa in Depends

On Wed, Mar 10, 2021 at 1:44 AM Shengjing Zhu  wrote:
>
> Hi,
>
> On Sat, Jan 30, 2021 at 12:16:36PM +0200, Vincas Dargis wrote:
> > Latest electrum version failds to find Ledger wallet, Install Wizard
> > shows this:
> >
> > ```
> >  ledger: (error getting device infos)
> > Library version for 'ledger' is incompatible.
> > Installed: 0.1.31, Needed: 0.1.30 <= x < inf
> > Make sure you install it with python3
> > ```
> >
>
> How can I reproduce this? TBH, I never use the ledger plugin, and I
> don't known how to use this.

I read the issue on https://github.com/spesmilo/electrum/issues/6928,
It seems it's python3-btchip that misses python3-ecdsa in Depends.

$ rg ecdsa
usr/lib/python3/dist-packages/btchip/btchipKeyRecovery.py
3:import ecdsa
4:from ecdsa.curves import SECP256k1
5:from ecdsa.ellipticcurve import Point
6:from ecdsa.util import string_to_number, number_to_string
8:class MyVerifyingKey(ecdsa.VerifyingKey):
12:from ecdsa import util, numbertheory

usr/lib/python3/dist-packages/btchip_python-0.1.31.egg-info/requires.txt
3:ecdsa>=0.9

-- 
Shengjing Zhu

Bug#981010: rxvt-unicode: urxvt segfaults at exit

[Felix C. Stegerman]

Hi,

I can reproduce this after a "xrdb -load /dev/null".

However, I only seem to be able to reproduce it when I start urxvt via
an i3 keybinding.  If I start it via dmenu or by running "urxvt" from
another terminal, I don't see a segfault in the logs.

- Felix

Bug#984648: unblock: packages with unversioned python dependencies

[Matthias Klose]

linkchecker is fixed in 10.0.1-2

Bug#984885: unblock: vlc/3.0.12-3

[Sebastian Ramacher]

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

Please unblock package vlc/3.0.12-3.

[ Reason ]
vlc 3.0.x suffers from a long standing issue that causes vlc to freeze
on exit when running with a mesa GPU driver. A proper fix would also
require changes to mesa (cf
https://gitlab.freedesktop.org/mesa/mesa/-/issues/116 for the mesa bug),
but attempts to fix mesa caused other regressions, so this fix was
reverted. vlc upstream now added a workaround to no longer trigger the
condition that leads to the freeze.

[ Impact ]
Users with affected drivers can reenable hardware accelerated video
decoding.

[ Tests ]
No automated test coverage, but manually tested.

[ Risks ]
Even if the fix was incomplete, users can continue to disable hardware
acceleration or kill the stuck vlc process.

vlc is a key package, so requires an unblock.

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

unblock vlc/3.0.12-3
-- 
Sebastian Ramacher
diff --git a/debian/changelog b/debian/changelog
index b96fc96a8..1b3237d27 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+vlc (3.0.12-3) unstable; urgency=medium
+
+  * debian/patches: Apply upstream patches to prevent process freeze on exit
+(Closes: #916595) (LP: #1819543)
+
+ -- Sebastian Ramacher   Tue, 09 Mar 2021 17:42:00 +0100
+
 vlc (3.0.12-2) unstable; urgency=medium
 
   * debian/: Disable live555 plugin due to #981439
diff --git 
a/debian/patches/0004-qt-add-a-private-structure-for-window-provider.patch 
b/debian/patches/0004-qt-add-a-private-structure-for-window-provider.patch
new file mode 100644
index 0..7788dd33b
--- /dev/null
+++ b/debian/patches/0004-qt-add-a-private-structure-for-window-provider.patch
@@ -0,0 +1,88 @@
+From: =?utf-8?q?R=C3=A9mi_Denis-Courmont?= 
+Date: Sat, 6 Feb 2021 15:00:02 +0200
+Subject: qt: add a private structure for window provider
+
+---
+ modules/gui/qt/qt.cpp | 33 ++---
+ 1 file changed, 22 insertions(+), 11 deletions(-)
+
+diff --git a/modules/gui/qt/qt.cpp b/modules/gui/qt/qt.cpp
+index ab912fd..d5a22d9 100644
+--- a/modules/gui/qt/qt.cpp
 b/modules/gui/qt/qt.cpp
+@@ -708,6 +708,10 @@ static void ShowDialog( intf_thread_t *p_intf, int 
i_dialog_event, int i_arg,
+  */
+ static int WindowControl( vout_window_t *, int i_query, va_list );
+ 
++typedef struct {
++MainInterface *mi;
++} vout_window_qt_t;
++
+ static int WindowOpen( vout_window_t *p_wnd, const vout_window_cfg_t *cfg )
+ {
+ if( cfg->is_standalone )
+@@ -737,21 +741,26 @@ static int WindowOpen( vout_window_t *p_wnd, const 
vout_window_cfg_t *cfg )
+ if (unlikely(!active))
+ return VLC_EGENERIC;
+ 
+-MainInterface *p_mi = p_intf->p_sys->p_mi;
++vout_window_qt_t *sys = new vout_window_qt_t;
++
++sys->mi = p_intf->p_sys->p_mi;
+ msg_Dbg( p_wnd, "requesting video window..." );
+ 
+-if( !p_mi->getVideo( p_wnd, cfg->width, cfg->height, cfg->is_fullscreen ) 
)
++if (!sys->mi->getVideo(p_wnd, cfg->width, cfg->height, 
cfg->is_fullscreen))
++{
++delete sys;
+ return VLC_EGENERIC;
++}
+ 
+ p_wnd->info.has_double_click = true;
+ p_wnd->control = WindowControl;
+-p_wnd->sys = (vout_window_sys_t*)p_mi;
++p_wnd->sys = (vout_window_sys_t *)sys;
+ return VLC_SUCCESS;
+ }
+ 
+ static int WindowControl( vout_window_t *p_wnd, int i_query, va_list args )
+ {
+-MainInterface *p_mi = (MainInterface *)p_wnd->sys;
++vout_window_qt_t *sys = (vout_window_qt_t *)p_wnd->sys;
+ QMutexLocker locker ();
+ 
+ if (unlikely(!active))
+@@ -759,12 +768,12 @@ static int WindowControl( vout_window_t *p_wnd, int 
i_query, va_list args )
+ msg_Warn (p_wnd, "video already released before control");
+ return VLC_EGENERIC;
+ }
+-return p_mi->controlVideo( i_query, args );
++return sys->mi->controlVideo(i_query, args);
+ }
+ 
+ static void WindowClose( vout_window_t *p_wnd )
+ {
+-MainInterface *p_mi = (MainInterface *)p_wnd->sys;
++vout_window_qt_t *sys = (vout_window_qt_t *)p_wnd->sys;
+ QMutexLocker locker ();
+ 
+ /* Normally, the interface terminates after the video. In the contrary, 
the
+@@ -776,11 +785,13 @@ static void WindowClose( vout_window_t *p_wnd )
+  * That assumes the video output will behave sanely if it window is
+  * destroyed asynchronously.
+  * XCB and Xlib-XCB are fine with that. Plain Xlib wouldn't, */
+-if (unlikely(!active))
++if (likely(active))
+ {
+-msg_Warn (p_wnd, "video already released");
+-return;
++msg_Dbg(p_wnd, "releasing video...");
++sys->mi->releaseVideo();
+ }
+-msg_Dbg (p_wnd, "releasing video...");
+-p_mi->releaseVideo();
++else
++msg_Warn (p_wnd, "video already released");
++
++

Bug#981374: electrum: Ledger wallet not found: Library version for 'ledger' is incompatible.

[Shengjing Zhu]

Hi,

On Sat, Jan 30, 2021 at 12:16:36PM +0200, Vincas Dargis wrote:
> Latest electrum version failds to find Ledger wallet, Install Wizard
> shows this:
> 
> ```
>  ledger: (error getting device infos)
> Library version for 'ledger' is incompatible.
> Installed: 0.1.31, Needed: 0.1.30 <= x < inf
> Make sure you install it with python3
> ```
> 

How can I reproduce this? TBH, I never use the ledger plugin, and I
don't known how to use this.

@bunk, why the severity is raised to serious? The package itself is
functional for basic usage.


signature.asc
Description: PGP signature

Bug#984884: libgcrypt20: Unknown error executing apt-key [Bullseye]

[Davide Prina]

Package: libgcrypt20
Version: 1.8.7-3
Severity: critical

I set it as critical because user cannot anymore upgrade their system, 
please adjust Severity if you think it not correct. Note that this can 
be also a security problem because very old libgcrypt20 is in use.


Some users in Italian mailing list have reported that they have an error 
when they try upgrade/install packages:


# apt update
Get:1 http://deb.debian.org/debian bullseye InRelease [142 kB]
Err:1 http://deb.debian.org/debian bullseye InRelease
  Unknown error executing apt-key
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
All packages are up to date.
W: An error occurred during the signature verification. The repository 
is not updated and the previous index files will be used. GPG error: 
http://deb.debian.org/debian bullseye InRelease: Unknown error executing 
apt-key
W: Failed to fetch http://deb.debian.org/debian/dists/bullseye/InRelease 
 Unknown error executing apt-key
W: Some index files failed to download. They have been ignored, or old 
ones used instead.


dig the problem we found that they have the following files on their system:

$ /sbin/ldconfig -p | grep libgcrypt
libgcrypt.so.20 (libc6,x86-64) => /lib/x86_64-linux-gnu/libgcrypt.so.20
libgcrypt.so.20 (libc6,x86-64) => 
/usr/lib/x86_64-linux-gnu/libgcrypt.so.20


$ ls -l /lib/x86_64-linux-gnu/libgcrypt.so.20
lrwxrwxrwx 1 root root 19 17 mar  2020 
/lib/x86_64-linux-gnu/libgcrypt.so.20 -> libgcrypt.so.20.1.5

$ ls -l /lib/x86_64-linux-gnu/libgcrypt.so.20.1.5
-rw-r--r-- 1 root root 1112184 14 gen  2017 
/lib/x86_64-linux-gnu/libgcrypt.so.20.1.5


but these files are from package migrated to testing in:
[2017-01-25] libgcrypt20 1.7.5-3 MIGRATED to testing (Debian testing 
watch)[¹]


So for some reason when the library path change they have not been deleted.

All users with that problem cannot use apt to solve the issue.

I know that the user that report the problem has not the security 
repository in its sources.list file.


I suggest to check that those file are removed from
/lib/x86_64-linux-gnu/
in all new libgcrypt20 new version, elsewhere when Bullseye become 
stable more user can have that problem.


Ciao
Davide

[¹]
https://tracker.debian.org/pkg/libgcrypt20/news/?page=3
https://snapshot.debian.org/archive/debian/20170114T162918Z/pool/main/libg/libgcrypt20/libgcrypt20_1.7.5-3_amd64.deb

Bug#984869: ITP: node-cron-validator -- cron-validator is a util that allows to validate cron expression

[Vivek K J]

Package: wnpp
Severity: wishlist
Owner: Vivek K J 
X-Debbugs-Cc: debian-de...@lists.debian.org, vive...@protonmail.com

* Package name: node-cron-validator
  Version : 1.2.1
  Upstream Author : Guillaume Rochat
* URL : https://github.com/TheCloudConnectors/cron-validator
* License : Expat
  Programming Lang: Javascript
  Description : cron-validator is a util that allows to validate cron 
expression
 Cron Validator is a util that allows you to validate a cron expression,
 similar to what crontab guru does, but in your code base. This node package 
will be maintained by debian javascript maintainers.

Bug#962921: Please fix spam for bullseye

[Felix Lechner]

Dear maintainer,

The release team will accept this patch for bullseye. They raised the
bug status to "serious" after I asked on your behalf. Please upload a
patched version and ask for unblocking in a bug against release.d.o.

Thanks for your contributions to Debian!

Kind regards
Felix Lechner

Bug#983445:

[Anya Annetova]

https://github.com/rclone/rclone/issues/3980#issuecomment-654415017

Bug#984761: dcraw: buffer-overflow caused by integer-overflow in foveon_load_camf()

[Filip Hroch]

Dear Wooseok,

I'll look on this.

Note, that I'm maintaining only Debian packaging.
I am not upstream autor; I can fix only the bugs
which does not induce extensive changes in whole
structure of the source code.

FH
--
F. Hroch , Masaryk University, Brno, 
Czechia.

Dept. of theor. physics and astrophysics, Kotlarska 2, CZ-611 37.

Bug#984881: libnvidia-ml-dev: missing libnvidia-ml.so in library search path?

[Samuel Thibault]

Package: libnvidia-ml-dev
Version: 11.2.67~11.2.1-2
Severity: important

Hello,

While trying to build a program that uses nvml, I am getting:

$ gcc transfers.c -o transfers -lnvidia-ml
/usr/bin/ld: cannot find -lnvidia-ml
collect2: error: ld returned 1 exit status

indeed libnvidia-ml-dev doesn't provide a libnvidia-ml.so link in
/usr/lib/x86_64-linux-gnu

Samuel

-- System Information:
Debian Release: bullseye/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 
'testing-debug'), (500, 'stable-debug'), (500, 'proposed-updates-debug'), (500, 
'proposed-updates'), (500, 'oldoldstable'), (500, 'buildd-unstable'), (500, 
'unstable'), (500, 'stable'), (500, 'oldstable'), (1, 'experimental-debug'), 
(1, 'buildd-experimental'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.11.0 (SMP w/8 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 libnvidia-ml-dev depends on:
ii  libnvidia-ml1 [libnvidia-ml.so.1]  460.39-1

libnvidia-ml-dev recommends no packages.

libnvidia-ml-dev suggests no packages.

-- no debconf information

-- 
Samuel
il y a 10 catégories de personnes dans le monde : ceux qui comprennent le
binaire, et ceux qui ne le comprennent pas

Bug#946497: [Pkg-zfsonlinux-devel] Bug#946497: zfs-dkms: module wants to build with gcc instead of kernel's compiler

[Aron Xu]

Control: severity -1 important

On Tue, Mar 9, 2021 at 6:51 PM Andreas Beckmann  wrote:
>
> Followup-For: Bug #946497
> Control: severity -1 serious
>
> Please depend on gcc if you cannot find a way to use the kernel
> compiler. You cannot expect build-essential to be available.
>

Depending directly on gcc or build-essential will not actually resolve
the issue, sometimes it works coincidentally when kernel gcc is the
same as default gcc, which isn't guaranteed by the kernel team's
design. This is true for almost all dkms packages, and you might want
to raise this issue to the dkms package and kernel team one more time.

Regards,
Aron

Bug#983236: magics++: FTBFS with PROJ 8.0.0

[Iain Russell]

It's worth noting that the next release of Magics (4.6.0) has this issue
fixed in a similar but not identical way to that proposed in the patch. We
expect to release this version in the next 2 weeks.

Thanks,
Iain Russell, ECMWF

Bug#984883: RFS: python-tuf/0.17.0-1 [ITP] -- library for securing a software updater

[Philippe Coval]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

I am looking for a sponsor for my package "python-tuf":

* Package name : python-tuf
  Version : 0.17.0-1
  Upstream Author : https://github.com/theupdateframework,
* URL : https://theupdateframework.com
* License : Apache-2.0
* Vcs : https://github.com/theupdateframework/tuf
* Section : python

It builds those binary packages:

python3-tuf - plug-and-play library for securing a software updater

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

https://mentors.debian.net/package/python-tuf/

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

dget -x 
https://mentors.debian.net/debian/pool/main/p/python-tuf/python-tuf_0.17.0-1.dsc

Changes for the initial release:

python-tuf (0.17.0-1) unstable; urgency=low
.
[Lukas Puehringer]
* Initial packaging effort on 0.11.2.dev3-1
.
[Philippe Coval]

* Initial release. (Closes: #934151)

Extra Notes:

Since bullseyes entered the freeze period,
may I ask to upload to experimental branch?

This integration task is tracked upstream at this address:

https://github.com/theupdateframework/tuf/issues/263

History of packaging is preserved and available in this branch:

https://github.com/CrossStream/tuf/tree/debian/master

Which could be relocated to salsa, please create

https://salsa.debian.org/python-team/packages/python-tuf

My request to join python team is still pending

https://lists.debian.org/debian-python/2021/03/msg5.html

Feel free to reach me (RzR on IRC)

Regards

Bug#984882: unblock: debian-science/1.14.1

[Andreas Tille]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: debian-science-maintain...@lists.alioth.debian.org

Please unblock package debian-science

(Please provide enough (but not too much) information to help
the release team to judge the request efficiently. E.g. by
filling in the sections below.)

[ Reason ]
The debian-science metapackages should have been uploaded right before
the freeze.  Due to an unfortunate sequence of blockers (specifically an
additional binary (meta)package) it was to late to meet the deadline.

[ Impact ]
I consider it important to have this version in testing right now to
have a potentially minimum diff (or may be no need for another upload)
in case some of the dependencies will be removed in the deep freeze
period.

[ Tests ]
The metapackages do not contain any real code, just dependencies.
So there are no real tests.

[ Risks ]
The code is trivial - I do not see any risk.

[ Checklist ]
  [x] all changes are documented in the d/changelog
  [x] I reviewed all changes and I approve them
  [ ] attach debdiff against the package in testing
  (I do not see any reason for a debdiff of the autogenerated package)


unblock debian-science/1.14.1

Bug#984880: Purging squid when squid-openssl is installed disables service

[Santiago Garcia Mantinan]

Package: squid
Version: 4.13-6
Severity: normal

Looks like we still have a problem, the postrm auto added hooks by debhelper
are disabling the service when you purge squid and squid-openssl is installed.

The problem lays here, but as I said, this is auto added code :-(

if [ "$1" = "purge" ]; then
  if [ -x "/usr/bin/deb-systemd-helper" ]; then
 deb-systemd-helper purge 'squid.service' >/dev/null || true
 deb-systemd-helper unmask 'squid.service' >/dev/null || true
  fi
fi


Don't really know how to solve this in code right now, I'll have to think
about it, I'm accepting ideas.

Meanwhile, if you encounter this bug, just do: systemctl enable squid

Regards.

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

Kernel: Linux 5.10.0-4-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=gl_ES.UTF-8, LC_CTYPE=gl_ES.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 squid depends on:
ii  adduser  3.118
ii  init-system-helpers  1.60
ii  libc62.31-9
ii  libcap2  1:2.44-1
ii  libcom-err2  1.46.2-1
ii  libcrypt11:4.4.17-1
ii  libdb5.3 5.3.28+dfsg1-0.8
ii  libdbi-perl  1.643-3+b1
ii  libecap3 1.0.1-3.2+b1
ii  libexpat12.2.10-2
ii  libgcc-s110.2.1-6
ii  libgnutls30  3.7.0-7
ii  libgssapi-krb5-2 1.18.3-4
ii  libkrb5-31.18.3-4
ii  libldap-2.4-22.4.57+dfsg-2
ii  libltdl7 2.4.6-15
ii  libnetfilter-conntrack3  1.0.8-3
ii  libnettle8   3.7-2.1
ii  libnsl2  1.3.0-2
ii  libpam0g 1.4.0-6
ii  libsasl2-2   2.1.27+dfsg-2.1
ii  libstdc++6   10.2.1-6
ii  libsystemd0  247.3-2
ii  libxml2  2.9.10+dfsg-6.3+b1
ii  logrotate3.18.0-2
ii  lsb-base 11.1.0
ii  netbase  6.2
ii  squid-common 4.13-6

Versions of packages squid recommends:
ii  ca-certificates  20210119
ii  libcap2-bin  1:2.44-1

Versions of packages squid suggests:
ii  apparmor 2.13.6-9
pn  resolvconf   
pn  smbclient
pn  squid-cgi
pn  squid-purge  
pn  squidclient  
pn  ufw  
pn  winbind  

-- no debconf information

Bug#984642: unblock refpolicy / policycoreutils

[Graham Inggs]

Hi Russell

Neither refpolicy nor policycoreutils are in the list of key packages.
In the upcoming hard freeze, for non-key packages with (non-trivial)
autopkgtests, the rules of the soft freeze still apply [1].

So you could avoid the need for unblocks for these packages by adding
an autopkgtest that tests the as-installed packages in a new upload.

Regards
Graham


[1] https://release.debian.org/bullseye/freeze_policy.html#hard

Bug#984879: podman: Error: failed to mount shm tmpfs

[Laurent Bigonville]

Package: podman
Version: 3.0.1+dfsg1-1
Severity: serious

Hello,

I'm trying to run a container using podman (podman run -ti debian
/bin/bash) as root and as non-root and I get the same error in both
cases:

Error: failed to mount shm tmpfs 
"/var/lib/containers/storage/overlay-containers/aeb3feb433b8cc40e61afb534c04b5ace9afbc519a4b0030407e08c405989ec4/userdata/shm":
 invalid argument

or 

Error: failed to mount shm tmpfs 
"/home/bigon/.local/share/containers/storage/overlay-containers/b96996612a424cddcb1d38f20071c974eb185d678a882d952b338cfa18e59abb/userdata/shm":
 invalid argument

Not sure what's happening, I don't remember changing anything to the
default configuration.

An idea?

Kind regards,
Laurent Bigonville


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

Kernel: Linux 5.10.0-4-amd64 (SMP w/8 CPU threads)
Locale: LANG=fr_BE.UTF-8, LC_CTYPE=fr_BE.UTF-8 (charmap=UTF-8), 
LANGUAGE=fr_BE:fr
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: SELinux: enabled - Mode: Permissive - Policy name: refpolicy

Versions of packages podman depends on:
ii  conmon   2.0.25+ds1-1
ii  containernetworking-plugins  0.9.0-1+b1
ii  crun 0.17+dfsg-1
ii  golang-github-containers-common  0.33.4+ds1-1
ii  init-system-helpers  1.60
ii  libc62.31-9
ii  libdevmapper1.02.1   2:1.02.175-2.1
ii  libgpgme11   1.14.0-1+b2
ii  libseccomp2  2.5.1-1
ii  runc 1.0.0~rc93+ds1-2

Versions of packages podman recommends:
ii  buildah   1.19.6+dfsg1-1
ii  fuse-overlayfs1.4.0-1
ii  golang-github-containernetworking-plugin-dnsname  1.1.1+ds1-4+b2
ii  slirp4netns   1.0.1-1
ii  tini  0.19.0-1
ii  uidmap1:4.8.1-1

Versions of packages podman suggests:
pn  containers-storage  
ii  docker-compose  1.25.0-1

-- no debconf information

Bug#983632: Backport to buster

[Elimar Riesebieter]

Dear maintainers,

is there any chance to get an appropriate backport for buster?
According to [1] buster is vulnerable.

[1] https://security-tracker.debian.org/tracker/source-package/salt

Thanks in advance

Elimar
-- 
  Numeric stability is probably not all that
  important when you're guessing;-)

Bug#984665: [Pkg-rust-maintainers] Bug#984665: CVE-2021-25900

[Peter Green]

On 07/03/2021 02:30, plugwash-urgent wrote:

my tentative conclusion is that the insert_many
operation in rust-arrayvec does not seem to actually be used.


While I can't find any applications that uses the broken function
in rust-smallvec (saying arrayvec above was a brainfart), I
still think we should apply the fix. The fix doesn't
contain any code changes outside of the function in question so
the risk seems minimal.

I notice that kpcyrd has packaged the new version of smallvec on
a branch. I'm not sure what his intentions are regarding that branch
but given where we are in the release cycle and given that
rust-smallvec is a key package it does not seem appropriate
to me to upload it to unstable at this time.

I have applied the upstream patch to the version of the package
in Debian and it applies cleanly and tests (including the newly
added one) pass. I have pushed the changes to the debcargo-conf
repository.

If noone objects I will likely upload in a few days
and request an unblock from the release team. I intend to make
the upload with debcargo 2.4.3 to keep the diff minimal for the
release team.

Bug#980809: rmatrix: breaks autopkgtest of r-cran-glmmtmb on s390x

[Martin Maechler]

On Tue, Mar 9, 2021 at 2:23 PM Dirk Eddelbuettel  wrote:
>
>
> On 9 March 2021 at 14:26, Graham Inggs wrote:
> | Control: tags -1 - fixed-upstream + upstream
> | Control: notforwarded -1
> |
> |
> | >From TMB upstream [1]:
> |
> | > Digging a bit deeper I found that after calling
> | >
> | > M_cholmod_factorize_p(A, mm, (int*)NULL, 0 /*fsize*/, f, )
> | >
> | > the cholmod_common struct contains bogus, e.g. c.status=14903956 and 
> c.dtype=15216988.
> |
> |
> | [1] https://github.com/kaskr/adcomp/issues/340#issuecomment-790606775
>
> Appreciate the hard-core digging Graham!
>
> And said call is made by glmmTMB in error, or is the call done by Matrix as
> part of exposing CHOLMOD?

Indeed, that's the question ...
If  glmmTMB calls Matrix-exported C functions and something goes wrong
does not necessarily point the finger to Matrix,
even though it did not happen for previous versions of Matrix.

In this case, it could be that glmmTMB  relied on an undocumented
Matrix behavior which I had decided to change...
though I must say, I would still be surprised..  I'd rather expect
something more complicated where at least two factors are leading to
the problem you see..

Martin

-- 
Martin Maechler,
Seminar fuer Statistik, ETH Zurich

Bug#984878: pam: [INTL:ru] Russian debconf templates translation update

[shilin . aleksej]

Package: pam
Version: 1.4.0-6
Tags: l10n patch
Severity: wishlist

Hi,

Updated Russian translation for pam debconf templates is attached.
# translation of ru.po to Russian
# Copyright (C) YEAR THE PACKAGE'S COPYRIGHT HOLDER
# This file is distributed under the same license as the pam package.
#
# Yuri Kozlov , 2007.
# Max Kosmach , 2009.
# Yuri Kozlov , 2009, 2011.
# Алексей Шилин , 2021.
#
msgid ""
msgstr ""
"Project-Id-Version: pam 1.4.0-6\n"
"Report-Msgid-Bugs-To: p...@packages.debian.org\n"
"POT-Creation-Date: 2021-02-26 10:32-0500\n"
"PO-Revision-Date: 2021-03-07 19:17+0300\n"
"Last-Translator: Алексей Шилин \n"
"Language-Team: русский \n"
"Language: ru\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
"X-Generator: Gtranslator 3.30.1\n"
"Plural-Forms: nplurals=3; plural=(n%10==1 && n%100!=11 ? 0 : n%10>=2 && n"
"%10<=4 && (n%100<10 || n%100>=20) ? 1 : 2)\n"

#. Type: string
#. Description
#: ../libpam0g.templates:1001
msgid "Services to restart for PAM library upgrade:"
msgstr "Службы, которые будут перезапущены после обновления библиотеки PAM:"

#. Type: string
#. Description
#: ../libpam0g.templates:1001
#| msgid ""
#| "Most services that use PAM need to be restarted to use modules built for "
#| "this new version of libpam.  Please review the following space-separated "
#| "list of init.d scripts for services to be restarted now, and correct it "
#| "if needed."
msgid ""
"Most services that use PAM need to be restarted to use modules built for "
"this new version of libpam.  Please review the following space-separated "
"list of  services to be restarted now, and correct it if needed."
msgstr ""
"Чтобы задействовать новые версии модулей из libpam, нужно перезапустить "
"большинство служб, использующих PAM. Внимательно просмотрите и при "
"необходимости отредактируйте следующий список служб, которые будут "
"перезапущены. Элементы списка разделяются пробелом."

#. Type: error
#. Description
#: ../libpam0g.templates:2001
msgid "Display manager must be restarted manually"
msgstr "Программу входа в систему нужно перезапустить вручную"

#. Type: error
#. Description
#: ../libpam0g.templates:2001
msgid ""
"The wdm and xdm display managers require a restart for the new version of "
"libpam, but there are X login sessions active on your system that would be "
"terminated by this restart.  You will therefore need to restart these "
"services by hand before further X logins will be possible."
msgstr ""
"Для работы с новой версией libpam программам для входа в систему wdm и xdm "
"требуется перезапуск, но это прервёт все запущенные X-сеансы. Поэтому вам "
"нужно перезапустить эти службы вручную, для того чтобы можно было снова "
"входить в систему через X."

#. Type: error
#. Description
#: ../libpam0g.templates:3001
msgid "Failure restarting some services for PAM upgrade"
msgstr "При обновлении PAM перезапуск некоторых служб завершился неудачно"

#. Type: error
#. Description
#: ../libpam0g.templates:3001
msgid ""
"The following services could not be restarted for the PAM library upgrade:"
msgstr ""
"При обновлении библиотеки PAM не удалось перезапустить следующие службы:"

#. Type: error
#. Description
#: ../libpam0g.templates:3001
msgid ""
"You will need to start these manually by running '/etc/init.d/ "
"start'."
msgstr "Вам нужно запустить их вручную, выполнив «/etc/init.d/<служба> start»."

#. Type: boolean
#. Description
#: ../libpam0g.templates:4001
msgid "Restart services during package upgrades without asking?"
msgstr "Перезапускать службы при обновлении пакета, не задавая вопросов?"

#. Type: boolean
#. Description
#: ../libpam0g.templates:4001
msgid ""
"There are services installed on your system which need to be restarted when "
"certain libraries, such as libpam, libc, and libssl, are upgraded. Since "
"these restarts may cause interruptions of service for the system, you will "
"normally be prompted on each upgrade for the list of services you wish to "
"restart.  You can choose this option to avoid being prompted; instead, all "
"necessary restarts will be done for you automatically so you can avoid being "
"asked questions on each library upgrade."
msgstr ""
"В системе установлены службы, которые требуют перезапуска после обновления "
"определённых библиотек (например, libpam, libc и libssl). Поскольку это "
"может вызвать перерыв в работе служб, то обычно при каждом обновлении вам "
"будет предложено указать список служб, которые вы хотите перезапустить. "
"Чтобы этот вопрос не задавался, вы можете ответить утвердительно; в этом "
"случае все необходимые службы будут перезапущены автоматически."

#. Type: title
#. Description
#: ../libpam-runtime.templates:1001
msgid "PAM configuration"
msgstr "Настройка PAM"

#. Type: multiselect
#. Description
#: ../libpam-runtime.templates:2001
msgid "PAM profiles to enable:"
msgstr "Активируемые профили PAM:"

#. Type: multiselect
#. Description
#: ../libpam-runtime.templates:2001
msgid ""

Bug#983574:

[Nicholas Brown]

This is caused by the following backward incompatible change in GNU 4.3:

https://lists.gnu.org/archive/html/info-gnu/2020-01/msg4.html

* WARNING: Backward-incompatibility!
  Previously appending using '+=' to an empty variable would result in a
value
  starting with a space.  Now the initial space is only added if the
variable
  already contains some value.  Similarly, appending an empty string does
not
  add a trailing space.

Bug#983695: ibus-anthy: does not work out of the box on the GNOME desktop

[Gunnar Hjalmarsson]

On 2021-03-09 15:55, YOSHINO Yoshihito wrote:

On Tue, Mar 9, 2021 at 11:36 PM Gunnar Hjalmarsson  wrote:

On 2021-03-09 14:58, osamu.a...@gmail.com wrote:

For Japanese, kkc is the only choice gnome-initial-setting offers.

No anthy/no kkc/no skk/ ...

So this is not an option for Japanese.


So annoying. :( But maybe gnome-initial-setup can be patched to bypass
whatever whitelist or blacklist they use to restrict the options. So you
can choose whatever IBus IM is installed - just as you can in Settings.


At least for Japanese users, the list offered by gnome-initial-setup
is severely broken, and the default "kkc" IM option is offered by
libgnome-desktop3; patching both of them is hard.


Would patching gnome-desktop3 help? Replacing "kkc" with e.g. "mozc-jp" 
wouldn't be very hard after all.



So I have proposed the auto setup script, which is IMO a much saner,
safer, and modular approach.


Maybe. I'm waiting for your response to a question I asked at your MR.

--
Gunnar Hjalmarsson
https://launchpad.net/~gunnarhj



OpenPGP_signature
Description: OpenPGP digital signature

Bug#984877: cubature FTCBFS: multiple reasons

[Helmut Grohne]

Source: cubature
Version: 1.0.3+ds-4
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

cubature fails to cross build from source. The failure varies a bit with
the architecture combination. For instance cross building from amd64 to
mipsel results in a failure about finding -lfftw3l. Cross building from
amd64 to arm64 results in an Exec format error.

There are multiple causes at work here. The tool clencurt_gen is a build
tool and therefore should be built with the build architecture compiler,
not the host architecture compiler.

Once fixing that, the relevant fftw library is missing. It is a bit
special here, because fftw is needed for both the build architecture
(for clencurt_gen) and for the host architecture (for the actual
libcubature). Thus a dependency is required for both architectures.

Then, depending on the architecture combination, linking fftw fails
again. This time, it happens during the later host architecture compiler
invocations. The relevant fftw library to use depends on the
architecture. Thus we need the FFTWLIB variable for both build and host.

Please consider applying the attached patch to make cross building work.

Helmut
diff --minimal -Nru cubature-1.0.3+ds/debian/changelog 
cubature-1.0.3+ds/debian/changelog
--- cubature-1.0.3+ds/debian/changelog  2021-02-20 11:14:12.0 +0100
+++ cubature-1.0.3+ds/debian/changelog  2021-03-09 08:25:25.0 +0100
@@ -1,3 +1,13 @@
+cubature (1.0.3+ds-4.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: (Closes: #-1)
++ Build build tool clencurt_gen with the build arch compiler.
++ Add missing libfftw3-dev:native build dependency.
++ Detect fftw/fftwl for the host objects using the host library.
+
+ -- Helmut Grohne   Tue, 09 Mar 2021 08:25:25 +0100
+
 cubature (1.0.3+ds-4) unstable; urgency=medium
 
   * Replace DEB_BUILD_MULTIARCH with DEB_HOST_MULTIARCH
diff --minimal -Nru cubature-1.0.3+ds/debian/control 
cubature-1.0.3+ds/debian/control
--- cubature-1.0.3+ds/debian/control2021-02-20 11:13:22.0 +0100
+++ cubature-1.0.3+ds/debian/control2021-03-09 08:25:25.0 +0100
@@ -3,7 +3,7 @@
 Priority: optional
 Maintainer: Debian Science Team 

 Uploaders: Ole Streicher , Nilesh Patra 

-Build-Depends: debhelper-compat (= 12), dh-exec, libfftw3-dev
+Build-Depends: debhelper-compat (= 12), dh-exec, libfftw3-dev, 
libfftw3-dev:native
 Standards-Version: 4.4.1
 Vcs-Git: https://salsa.debian.org/science-team/cubature.git
 Vcs-Browser: https://salsa.debian.org/science-team/cubature
diff --minimal -Nru cubature-1.0.3+ds/debian/rules 
cubature-1.0.3+ds/debian/rules
--- cubature-1.0.3+ds/debian/rules  2021-02-20 11:04:04.0 +0100
+++ cubature-1.0.3+ds/debian/rules  2021-03-09 08:25:25.0 +0100
@@ -3,12 +3,18 @@
 
 # Uncomment this to turn on verbose mode.
 #export DH_VERBOSE=1
--include /usr/share/dpkg/buildtools.mk
+include /usr/share/dpkg/buildtools.mk
 
 %:
dh $@
 
 ifeq (,$(wildcard /usr/lib/$(DEB_BUILD_MULTIARCH)/libfftw3l*))
+FFTWDEF_FOR_BUILD=-DNO_LONG_DOUBLE_FFTW
+FFTWLIB_FOR_BUILD=-lfftw3
+else
+FFTWLIB_FOR_BUILD=-lfftw3l
+endif
+ifeq (,$(wildcard /usr/lib/$(DEB_HOST_MULTIARCH)/libfftw3l*))
 FFTWDEF=-DNO_LONG_DOUBLE_FFTW
 FFTWLIB=-lfftw3
 else
@@ -16,7 +22,7 @@
 endif
 
 override_dh_auto_build:
-   $(CC) $(CFLAGS) $(CPPFLAGS) $(FFTWDEF) $(LDFLAGS) -o clencurt_gen 
clencurt_gen.c $(FFTWLIB) -lm
+   $(CC_FOR_BUILD) $(CFLAGS) $(CPPFLAGS) $(FFTWDEF_FOR_BUILD) $(LDFLAGS) 
-o clencurt_gen clencurt_gen.c $(FFTWLIB_FOR_BUILD) -lm
./clencurt_gen 19 > clencurt.h
$(CC) $(CFLAGS) $(CPPFLAGS) -fPIC -c hcubature.c pcubature.c
$(CC) $(LDFLAGS) -shared -o libcubature.so.0 
-Wl,-soname,libcubature.so.0 hcubature.o pcubature.o -lm

Bug#984876: openssh-server: logs unsightly errors from pam_env due to missing /etc/default/locale

[Ferenc Wágner]

Package: openssh-server
Version: 1:8.4p1-4
Severity: minor

Dear Maintainer,

I installed openssh-server in an autopkgtest VM for debugging.  It works
fine, but pollutes the logs with red messages like

sshd[2122]: pam_env(sshd:session): Unable to open env file: 
/etc/default/locale: No such file or directory

The locales package is not installed on this VM, but I didn't do
anything for that.

In my opinion it would be nice to get rid of that error is possible.
Apparently it comes from /etc/pam.d/sshd:

# In Debian 4.0 (etch), locale-related environment variables were moved to
# /etc/default/locale, so read that as well.
sessionrequired pam_env.so user_readenv=1 envfile=/etc/default/locale

Or should (for example) base-files make sure it exists?
-- 
Thanks,
Feri.

Bug#848945: grub-common: Empty rpool leaves ZFS systems unbootable

[наб]

Control: found -1 2.04-16

GRUB still runs
  /usr/sbin/grub-probe --device /dev/vdb1 /dev/vda3 /dev/vdd1 /dev/vde1 
--target=fs_label
for me which writes
(started writing recently? possibly something to do with pool upgrade)
  /usr/sbin/grub-probe: error: unknown filesystem.
to the stderr and leaves me with
  LINUX_ROOT_DEVICE=ZFS=/root
which means I need to mount /sysroot manually from the dracut shell.
Suboptimal.

Here's a simple way to work around this:
-- >8 --
diff --git a/10_linux.orig b/10_linux
index b018819..086401c 100755
--- a/10_linux.orig
+++ b/10_linux
@@ -89,9 +89,8 @@ case x"$GRUB_FS" in
GRUB_CMDLINE_LINUX="rootflags=subvol=${rootsubvol} 
${GRUB_CMDLINE_LINUX}"
fi;;
 xzfs)
-   rpool=`${grub_probe} --device ${GRUB_DEVICE} --target=fs_label 
2>/dev/null || true`
-   bootfs="`make_system_path_relative_to_its_root / | sed -e "s,@$,,"`"
-   LINUX_ROOT_DEVICE="ZFS=${rpool}${bootfs%/}"
+   bootfs=`awk '$2 == "/" {print $1; exit}' /proc/mounts`
+   LINUX_ROOT_DEVICE="ZFS=${bootfs}"
;;
 esac
-- >8 --

And a properer way:
-- >8 --
diff --git a/10_linux.orig b/10_linux
index b018819..e8cfd71 100755
--- a/10_linux.orig
+++ b/10_linux
@@ -89,9 +89,9 @@ case x"$GRUB_FS" in
GRUB_CMDLINE_LINUX="rootflags=subvol=${rootsubvol} 
${GRUB_CMDLINE_LINUX}"
fi;;
 xzfs)
-   rpool=`${grub_probe} --device ${GRUB_DEVICE} --target=fs_label 
2>/dev/null || true`
-   bootfs="`make_system_path_relative_to_its_root / | sed -e "s,@$,,"`"
-   LINUX_ROOT_DEVICE="ZFS=${rpool}${bootfs%/}"
+   bpool=`awk '$2 == "/" {FS="/"; $0 = $1; print $1; exit}' /proc/mounts`
+   bootfs=`zpool get -Ho value bootfs ${bpool}`
+   LINUX_ROOT_DEVICE="ZFS=${bootfs}"
;;
 esac
-- >8 --

Or one that should work best for all cases:
-- >8 --
diff --git a/10_linux.orig b/10_linux
index b018819..600c1db 100755
--- a/10_linux.orig
+++ b/10_linux
@@ -89,9 +89,13 @@ case x"$GRUB_FS" in
GRUB_CMDLINE_LINUX="rootflags=subvol=${rootsubvol} 
${GRUB_CMDLINE_LINUX}"
fi;;
 xzfs)
-   rpool=`${grub_probe} --device ${GRUB_DEVICE} --target=fs_label 
2>/dev/null || true`
-   bootfs="`make_system_path_relative_to_its_root / | sed -e "s,@$,,"`"
-   LINUX_ROOT_DEVICE="ZFS=${rpool}${bootfs%/}"
+   mounted=`awk '$2 == "/" {print $1; exit}' /proc/mounts`
+   bpool=`echo ${mounted} | cut -d/ -f1`
+   bootfs=`zpool get -Ho value bootfs ${bpool}`
+   if [ "$bootfs" = "-" ]; then
+   bootfs="${mounted}"
+   fi
+   LINUX_ROOT_DEVICE="ZFS=${bootfs}"
;;
 esac
-- >8 --

Same applies to 20_linux_xen.

Please consider this vague inspiration and a thread bump.

Best,
наб


signature.asc
Description: PGP signature

Bug#984873: linux-image-5.10.0-4-arm64: RPi4 8 GB lost USB support (doesn't start with / on USB device)

[Diederik de Haas]

On dinsdag 9 maart 2021 15:17:01 CET Jan Huijsmans wrote:
> Updating from linux-image-5.9.0-4-arm64 to linux-image-5.10.0-3/4-arm64
> resulted in a non-booting system due to missing/incorrect USB support
> for the RPi4 8GB. (system has / on USB SSD)
> 
> Only method to get the system booting again is to change config.txt to
> boot the available 5.9.0-4 kernel. System came up as expected.
> 
> With the 5.10 kernels I tested (-3 and -4 packages) the boot halted
> after detecting the partitions on mmcblk1 , on 5.9.0-4 it continues
> to detect the storange via USB and boots from it.

This is possibly a duplicate of bug #977694 and a possible solution can be 
found here: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=977694#67

Could you try whether that fixes it for you too?


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

Bug#983695: ibus-anthy: does not work out of the box on the GNOME desktop

[Shengjing Zhu]

Control: clone -1 -2
Control: reassign -2 gnome-initial-setup 3.38.4-1
Control: retitle -2 choice of Japanese input methods is not useful
Control: severity -2 important

Let's at least make gnome-initial-setup maintainer aware of this chaos.

On Tue, Mar 9, 2021 at 10:56 PM YOSHINO Yoshihito  wrote:
>
> Hi,
>
> On Tue, Mar 9, 2021 at 1:19 AM Shengjing Zhu  wrote:
> > Back to this issue only(ibus doesn't have a working default). I find
> > task-korean-gnome-desktop Recommends gnome-initial-setup,
> > And above the Recommends, it has a comment that says:
> >
> > > GNOME doesn't set the working Korean IM by default
> >
> > https://salsa.debian.org/installer-team/tasksel/-/blob/002c2a97/debian/control#L1547
> >
> > So I think this is the workaround by Korean users. Which now GNOME
> > defaults ibus, and ibus doesn't pick up the right defaults for all.
> > Maybe we should find a universal solution?
>
> Maybe, but this is not suitable for at least Japanese users.
>
> Actually first I tried the Korean workaround. However, unfortunately
> for Japanese users it is very hard to use gnome-initial-setup.
> This shows an insane ordering for Japanese input methods and keyboard
> layouts. Its "入力" (Input) page shows the following choices:
> - "Japanese (PC-98)", a mostly-dead Japanese keyboard layout, listed at the 
> top
> - "kkc", meaning ibus-kkc which is rarely used in a distro other than
> Fedora, listed next; this default value is hardcoded in the dependent
> libgnome-desktop3, so patching it is also hard:
> https://sources.debian.org/src/gnome-desktop3/3.38.4-1/libgnome-desktop/default-input-sources.h/#L38
> Scrolling farther down, other Japanese choices are found, but ...
> - "日本語", meaning "Japanese", is listed first, which looks like "the
> default Japanese input method" but is NOT an input method ...
> actually a JP keyboard layout
> - Other "日本語 (...)" choices including Anthy and Mozc are listed next,
> either a keyboard layout or an input method, are mixed alphabetically,
> where a Japanese user must select the appropriate input method.
> It is practically impossible for other than GNOME experts, and this is
> far from out-of-the-box.
>
> So IMO gnome-initial-setup (at least, in the current state) must not
> be installed in the Japanese GNOME desktop by default.
> Perhaps this is not suitable for a language where multiple input
> methods or keyboard layouts are widely used.
>
> On Tue, Mar 9, 2021 at 11:36 PM Gunnar Hjalmarsson  
> wrote:
> > Hi Osamu,
> >
> > On 2021-03-09 14:58, osamu.a...@gmail.com wrote:
> > > For Japanese, kkc is the only choice gnome-initial-setting offers.
> > >
> > > No anthy/no kkc/no skk/ ...
> > >
> > > So this is not an option for Japanese.
> >
> > So annoying. :( But maybe gnome-initial-setup can be patched to bypass
> > whatever whitelist or blacklist they use to restrict the options. So you
> > can choose whatever IBus IM is installed - just as you can in Settings.
>
> At least for Japanese users, the list offered by gnome-initial-setup
> is severely broken, and the default "kkc" IM option is offered by
> libgnome-desktop3; patching both of them is hard.
> So I have proposed the auto setup script, which is IMO a much saner,
> safer, and modular approach.
>
> Regards,
> --
> YOSHINO Yoshihito 

-- 
Shengjing Zhu

Bug#926394: Fwd: Re: fonts-amiga_1.02-1_amd64.changes REJECTED

[Gürkan Myczko]

for the record

 Original Message 
Subject: Re: fonts-amiga_1.02-1_amd64.changes REJECTED
Date: 05.03.2021 13:52
From: Gürkan Myczko 
To: Joerg Jaspert 
Cc: kilob...@angband.pl, Debian Fonts Task Force 



Hello Joerg,

13:46 < tarzeau> i have a small problem about copyright ftp-master 
handling understanding, how can fonts-pc be free, and fonts-amiga can't 
be accepted?
13:46 < tarzeau> https://int10h.org/oldschool-pc-fonts/ the vga format 
file to be loaded by vga registers, does not hold a copyright, however 
the bios roms
 do, if they include the font data, or not, is out of my 
knowledge, and if bitmap fotns can be protected or not, as well
13:47 < tarzeau> i have this for reference: 
https://github.com/rewtnull/amigafonts/issues
13:47 < tarzeau> and now i could start dumping the already in main 
included fonts from .h files from libansilove (in the archive) and 
create another binary
 package of it called fonts-amiga (which could or not 
could be accepted by ftp-master)
13:47 < bremner> are you one of the maintainers involved? if so, reply 
to the reject message with your questions
13:48 < tarzeau> (using bdf2fnt and pstools it's easy to create vector 
fonts of the bitmap fonts)
13:48 < tarzeau> bremner: yes i got the ITP. i feel like i don't get 
heard, but i'll try once more



On 31.10.2020 16:00, Joerg Jaspert wrote:

Hi Maintainer,

rejected, until the concerns from the "Comments regarding
fonts-amiga_1.02-1_amd64.changes" discussion in April are cleared, see
latest mail from Sean there.

--
bye Joerg



===

Please feel free to respond to this email if you don't understand why
your files were rejected, or if you upload new files which address our
concerns.

Bug#983695: ibus-anthy: does not work out of the box on the GNOME desktop

[YOSHINO Yoshihito]

Hi,

On Tue, Mar 9, 2021 at 1:19 AM Shengjing Zhu  wrote:
> Back to this issue only(ibus doesn't have a working default). I find
> task-korean-gnome-desktop Recommends gnome-initial-setup,
> And above the Recommends, it has a comment that says:
>
> > GNOME doesn't set the working Korean IM by default
>
> https://salsa.debian.org/installer-team/tasksel/-/blob/002c2a97/debian/control#L1547
>
> So I think this is the workaround by Korean users. Which now GNOME
> defaults ibus, and ibus doesn't pick up the right defaults for all.
> Maybe we should find a universal solution?

Maybe, but this is not suitable for at least Japanese users.

Actually first I tried the Korean workaround. However, unfortunately
for Japanese users it is very hard to use gnome-initial-setup.
This shows an insane ordering for Japanese input methods and keyboard
layouts. Its "入力" (Input) page shows the following choices:
- "Japanese (PC-98)", a mostly-dead Japanese keyboard layout, listed at the top
- "kkc", meaning ibus-kkc which is rarely used in a distro other than
Fedora, listed next; this default value is hardcoded in the dependent
libgnome-desktop3, so patching it is also hard:
https://sources.debian.org/src/gnome-desktop3/3.38.4-1/libgnome-desktop/default-input-sources.h/#L38
Scrolling farther down, other Japanese choices are found, but ...
- "日本語", meaning "Japanese", is listed first, which looks like "the
default Japanese input method" but is NOT an input method ...
actually a JP keyboard layout
- Other "日本語 (...)" choices including Anthy and Mozc are listed next,
either a keyboard layout or an input method, are mixed alphabetically,
where a Japanese user must select the appropriate input method.
It is practically impossible for other than GNOME experts, and this is
far from out-of-the-box.

So IMO gnome-initial-setup (at least, in the current state) must not
be installed in the Japanese GNOME desktop by default.
Perhaps this is not suitable for a language where multiple input
methods or keyboard layouts are widely used.

On Tue, Mar 9, 2021 at 11:36 PM Gunnar Hjalmarsson  wrote:
> Hi Osamu,
>
> On 2021-03-09 14:58, osamu.a...@gmail.com wrote:
> > For Japanese, kkc is the only choice gnome-initial-setting offers.
> >
> > No anthy/no kkc/no skk/ ...
> >
> > So this is not an option for Japanese.
>
> So annoying. :( But maybe gnome-initial-setup can be patched to bypass
> whatever whitelist or blacklist they use to restrict the options. So you
> can choose whatever IBus IM is installed - just as you can in Settings.

At least for Japanese users, the list offered by gnome-initial-setup
is severely broken, and the default "kkc" IM option is offered by
libgnome-desktop3; patching both of them is hard.
So I have proposed the auto setup script, which is IMO a much saner,
safer, and modular approach.

Regards,
--
YOSHINO Yoshihito 

Bug#984874: Upgrading via apt-get results in module amdgpu 'possible missing firmware' errors

[Daniel Rees]

Package: firmware-amd-graphics
Version: 20210208-3
Severity: minor

Upgrading the system via apt-get upgrade results in 'missing firmware' errors 
linked to the module amdgpu. There is no obvious impact on performance of the 
machine / graphics on my system. GPU is AMD Radeon 540X.

I am using Debian Bullseye, kernel 5.10.0-3-amd64.

Output from apt below:

update-initramfs: Generating /boot/initrd.img-5.10.0-3-amd64
W: Possible missing firmware /lib/firmware/amdgpu/arcturus_gpu_info.bin for 
module amdgpu
W: Possible missing firmware /lib/firmware/amdgpu/navy_flounder_ta.bin for 
module amdgpu
W: Possible missing firmware /lib/firmware/amdgpu/navy_flounder_sos.bin for 
module amdgpu   W: Possible 
missing firmware /lib/firmware/amdgpu/arcturus_ta.bin for module amdgpu
W: Possible missing firmware /lib/firmware/amdgpu/arcturus_asd.bin for module 
amdgpu
W: Possible missing firmware /lib/firmware/amdgpu/arcturus_sos.bin for module 
amdgpu
W: Possible missing firmware /lib/firmware/amdgpu/green_sardine_ta.bin for 
module amdgpu
W: Possible missing firmware /lib/firmware/amdgpu/green_sardine_asd.bin for 
module amdgpu
W: Possible missing firmware /lib/firmware/amdgpu/green_sardine_rlc.bin for 
module amdgpu
W: Possible missing firmware /lib/firmware/amdgpu/green_sardine_mec2.bin for 
module amdgpu
W: Possible missing firmware /lib/firmware/amdgpu/green_sardine_mec.bin for 
module amdgpu
W: Possible missing firmware /lib/firmware/amdgpu/green_sardine_me.bin for 
module amdgpu
W: Possible missing firmware /lib/firmware/amdgpu/green_sardine_pfp.bin for 
module amdgpu
W: Possible missing firmware /lib/firmware/amdgpu/green_sardine_ce.bin for 
module amdgpu
W: Possible missing firmware /lib/firmware/amdgpu/arcturus_rlc.bin for module 
amdgpu
W: Possible missing firmware /lib/firmware/amdgpu/arcturus_mec2.bin for module 
amdgpu
W: Possible missing firmware /lib/firmware/amdgpu/arcturus_mec.bin for module 
amdgpu
W: Possible missing firmware /lib/firmware/amdgpu/navy_flounder_rlc.bin for 
module amdgpu
W: Possible missing firmware /lib/firmware/amdgpu/navy_flounder_mec2.bin for 
module amdgpu
W: Possible missing firmware /lib/firmware/amdgpu/navy_flounder_mec.bin for 
module amdgpu
W: Possible missing firmware /lib/firmware/amdgpu/navy_flounder_me.bin for 
module amdgpu
W: Possible missing firmware /lib/firmware/amdgpu/navy_flounder_pfp.bin for 
module amdgpu
W: Possible missing firmware /lib/firmware/amdgpu/navy_flounder_ce.bin for 
module amdgpu
W: Possible missing firmware /lib/firmware/amdgpu/green_sardine_sdma.bin for 
module amdgpu
W: Possible missing firmware /lib/firmware/amdgpu/arcturus_sdma.bin for module 
amdgpu
W: Possible missing firmware /lib/firmware/amdgpu/navy_flounder_sdma.bin for 
module amdgpu
W: Possible missing firmware /lib/firmware/amdgpu/sienna_cichlid_mes.bin for 
module amdgpu
W: Possible missing firmware /lib/firmware/amdgpu/navi10_mes.bin for module 
amdgpu
W: Possible missing firmware /lib/firmware/amdgpu/navy_flounder_vcn.bin for 
module amdgpu
W: Possible missing firmware /lib/firmware/amdgpu/green_sardine_vcn.bin for 
module amdgpu
W: Possible missing firmware /lib/firmware/amdgpu/arcturus_vcn.bin for module 
amdgpu
W: Possible missing firmware /lib/firmware/amdgpu/navy_flounder_smc.bin for 
module amdgpu
W: Possible missing firmware /lib/firmware/amdgpu/arcturus_smc.bin for module 
amdgpu
W: Possible missing firmware /lib/firmware/amdgpu/green_sardine_dmcub.bin for 
module amdgpu
W: Possible missing firmware /lib/firmware/amdgpu/navy_flounder_dmcub.bin for 
module amdgpu

Bug#984846: netcfg: Default hostname hardcoded in netcfg-common

[Cyril Brulebois]

Hello,

Arnaud Rebillout  (2021-03-09):
> Dear Maintainer,
> 
> the default hostname "debian" is hardcoded in two places in the file
> netcfg-common.c:
> 
> https://salsa.debian.org/installer-team/netcfg/-/blob/master/netcfg-common.c#L1043
> https://salsa.debian.org/installer-team/netcfg/-/blob/master/netcfg-common.c#L1069
> 
> This was reported in the Kali Linux bugtracker [1].
> 
> For Kali, we set the default hostname to 'kali' in the file
> 'debian/netcfg-common.templates', key 'netcfg/get_hostname', so that
> the installer proposes it as the default hostname. It works well,
> however one of our user noticed that if they enter an invalid
> hostname, the default hostname is set back to 'debian' (since it's
> hardcoded in netcfg-common.c).
> 
> It would be nice if instead it would default to the value that is set
> in 'netcfg/get_hostname'. However I'm nost sure how to achieve that,
> as I'm not familiar with the netcfg code at all, and it's not clear if
> we can still get this value at this moment in the code, or if it has
> been overwritten by the user's input.

My first reaction was “we could make that configurable on a per-vendor
fashion” (e.g. via debian/rules) but reading you are already patching
debian/netcfg-common.templates, why aren't you patching the two harcoded
locations in the first place?

That would mean updating a patch on your side, without changing any code
or logic?


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


signature.asc
Description: PGP signature

Bug#984852: firmware-amd-graphics: Please add cezanne ("green sardine")

[Gedalya]

On 3/9/21 5:31 PM, maximilian attems wrote:
>
>> the display stopped updating as soon as amdgpu took over, and it never came 
>> back.
>> The firmware is needed of course, and as a side note, it could be nice if 
>> the kernel could fail more gracefully, somehow bringing the display back (it 
>> works fine with amdgpu blacklisted, just no acceleration) such that it takes 
>> me less than two days to figure it all out.
> this is a linux bug, you might want to submit it upstream to AMD guys.

Yea, I actually wasn't sure if this would be regarded as such, thanks for the 
encouragement. I'll look that up.

>> The relevant files are amdgpu/green_sardine_*
> right, they only got pushed upstream in linux-firmware git on 11/2/2021
> after the latest 20210208 release, hence unfortunately they miss out the
> next debian release
> https://release.debian.org/bullseye/freeze_policy.html
>
> They will land in the next upstream release upload of 202103XX to
> experimental, backports and then after bullseye release to unstable
> (plus next testing).
>  
I sure hope it would also end up in some point release? Or maybe a freeze 
exception could be made?

It would be unfortunate if a new computer won't be usable (without backports) 
on stable Debian which is to be finally released presumably several months 
after the computer hit the market, for want of a rather minor fix.

Bug#970635: moosic: new upstream now supports Python 3

[The Wanderer]

(Apologies for breaking threading; I don't seem to have received the
original mail, and my Web browser appears to be treating the mailto:
links as something like file://mailto: links, and reports that it can't
find any file by the given name.)

On 2021-01-02 at 13:34, Arto Jantunen wrote:

> The package has been uploaded and is in NEW awaiting processing by
> the FTP team.

Last night (as far as I can judge), this package disappeared from
https://ftp-master.debian.org/new.html (which I take to be the NEW
queue).

As of a few minutes ago, it did not seem to be in the archive. A
packages.debian.org search didn't find it in anything newer than stable
(with the old version, of course), and the tracker.debian.org page for
this package showed the last change being the removal this past April.

I'm not sure whether this is normal (package approved, processing to get
it actually into unstable doesn't happen right away, no visible sign of
package's status in the meantime), or whether it may mean that the
package has been rejected.

If the former, then all is well. If the latter, I'd be interested to
know the status, both so I know what to expect and in case there's
anything I can do to help the package get in on a subsequent try.



signature.asc
Description: OpenPGP digital signature

Bug#984873: linux-image-5.10.0-4-arm64: RPi4 8 GB lost USB support (doesn't start with / on USB device)

[Jan Huijsmans]

Package: src:linux
Version: 5.10.19-1
Severity: critical
Justification: breaks the whole system

Dear Maintainer,

Updating from linux-image-5.9.0-4-arm64 to linux-image-5.10.0-3/4-arm64
resulted in a non-booting system due to missing/incorrect USB support
for the RPi4 8GB. (system has / on USB SSD)

Only method to get the system booting again is to change config.txt to
boot the available 5.9.0-4 kernel. System came up as expected.

With the 5.10 kernels I tested (-3 and -4 packages) the boot halted
after detecting the partitions on mmcblk1 , on 5.9.0-4 it continues
to detect the storange via USB and boots from it.

Regards,

Jan Huijsmans

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

** Model information
Device Tree model: Raspberry Pi 4 Model B Rev 1.4

** PCI devices:
not available

** USB devices:
Bus 002 Device 002: ID 0578:0578 Intrinsix Corp. KingSpec Z3-128
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 003: ID 413c:2003 Dell Computer Corp. Keyboard SK-8115
Bus 001 Device 002: ID 2109:3431 VIA Labs, Inc. Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub


-- System Information:
Debian Release: bullseye/sid
  APT prefers testing
  APT policy: (1001, 'testing'), (100, 'stable')
Architecture: arm64 (aarch64)

Kernel: Linux 5.9.0-4-arm64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_CRAP
Locale: LANG=en_US.ISO8859-15, LC_CTYPE=en_US.ISO8859-15 (charmap=ISO-8859-15) 
(ignored: LC_ALL set to en_US.ISO8859-15), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages linux-image-5.10.0-4-arm64 depends on:
ii  initramfs-tools [linux-initramfs-tool]  0.139
ii  kmod28-1
ii  linux-base  4.6

Versions of packages linux-image-5.10.0-4-arm64 recommends:
ii  apparmor 2.13.6-9
ii  firmware-linux-free  20200122-1

Versions of packages linux-image-5.10.0-4-arm64 suggests:
pn  debian-kernel-handbook  
pn  linux-doc-5.10  

Versions of packages linux-image-5.10.0-4-arm64 is related to:
pn  firmware-amd-graphics 
pn  firmware-atheros  
pn  firmware-bnx2 
pn  firmware-bnx2x
ii  firmware-brcm8021120210208-3
pn  firmware-cavium   
pn  firmware-intel-sound  
pn  firmware-intelwimax   
pn  firmware-ipw2x00  
pn  firmware-ivtv 
pn  firmware-iwlwifi  
pn  firmware-libertas 
pn  firmware-linux-nonfree
pn  firmware-misc-nonfree 
pn  firmware-myricom  
pn  firmware-netxen   
pn  firmware-qlogic   
pn  firmware-realtek  
pn  firmware-samsung  
pn  firmware-siano
pn  firmware-ti-connectivity  
pn  xen-hypervisor

-- no debconf information

Bug#983695: ibus-anthy: does not work out of the box on the GNOME desktop

[Gunnar Hjalmarsson]

Hi Osamu,

On 2021-03-09 14:58, osamu.a...@gmail.com wrote:

For Japanese, kkc is the only choice gnome-initial-setting offers.

No anthy/no kkc/no skk/ ...

So this is not an option for Japanese.


So annoying. :( But maybe gnome-initial-setup can be patched to bypass 
whatever whitelist or blacklist they use to restrict the options. So you 
can choose whatever IBus IM is installed - just as you can in Settings.


--
Gunnar Hjalmarsson
https://launchpad.net/~gunnarhj



OpenPGP_signature
Description: OpenPGP digital signature

Bug#984729: libgtk builds fine in bullseye

[Bart Martens]

Control: tag -1 + moreinfo unreproducible
Control: severity -1 normal
Control: notfound -1 3.24.24-3

Hi ZenWalker,

I have today successfully built this package in bullseye, on my amd64
(pbuilder) and on tests.reproducible-builds.org.
https://tests.reproducible-builds.org/debian/rb-pkg/bullseye/amd64/gtk+3.0.html
Could you try again in a new and minimal bullseye environment please?

Cheers,

Bart

Bug#984872: xtl-dev: new upstream release 0.7

[Drew Parsons]

Package: xtl-dev
Version: 0.6.23-1
Severity: normal

Hi, I'm aiming to revive xtensor.  The latest version of xtensor
(0.23.1) requires xtl >= 0.7.0

Would it be possible to upload the latest version of xtl-dev to
experimental?


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

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

-- no debconf information

Bug#984871: ncbi-blast+: Missing headers for shared libraries

[Benjamin Buchfink]

Package: ncbi-blast+
Version: 2.9.0-2
Severity: wishlist

Dear Maintainer,

this package contains various shared libraries from the NCBI toolkit, but the 
corresponding
header files to compile using these libraries are missing. I request that all 
headers be
provided that can be obtained by building BLAST from source, tarball available 
at:
https://ftp.ncbi.nlm.nih.gov/blast/executables/blast+/

Best regards,

Benjamin Buchfink


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

Kernel: Linux 5.8.0-44-generic (SMP w/48 CPU cores)
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=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages ncbi-blast+ depends on:
ii  libbz2-1.0   1.0.8-2
ii  libc62.31-0ubuntu9.2
ii  libgcc-s1 [libgcc1]  10.2.0-5ubuntu1~20.04
ii  libgcc1  1:10.2.0-5ubuntu1~20.04
ii  libgomp1 10.2.0-5ubuntu1~20.04
ii  liblmdb0 0.9.24-1
ii  libmbedcrypto3   2.16.4-1ubuntu2
ii  libmbedtls12 2.16.4-1ubuntu2
ii  libpcre3 2:8.39-12build1
ii  libstdc++6   10.2.0-5ubuntu1~20.04
ii  ncbi-data6.1.20170106+dfsg1-8
ii  perl 5.30.0-9ubuntu0.2
ii  python3  3.8.2-0ubuntu2
ii  zlib1g   1:1.2.11.dfsg-2ubuntu1.2

ncbi-blast+ recommends no packages.

ncbi-blast+ suggests no packages.

-- no debconf information

Bug#983695: ibus-anthy: does not work out of the box on the GNOME desktop

[osamu . aoki]

Hi,

For Japanese, kkc is the only choice gnome-initial-setting offers.

No anthy/no kkc/no skk/ ...

So this is not an option for Japanese.  (Probably good for Korean)

On Mon, 2021-03-08 at 18:41 +0100, Gunnar Hjalmarsson wrote:
> On 2021-03-08 17:19, Shengjing Zhu wrote:
> > Hi,
> > 
> > On Sun, Feb 28, 2021 at 11:12 PM YOSHINO Yoshihito
> >  wrote:
> > > 
> > > Package: ibus-anthy
> > > Version: 1.5.11-2
> > > Severity: important
> > > Tags: patch
> > > 
> > > Dear Maintainer,
> > > 
> > > On the GNOME desktop, manual set-up in GNOME Settings is required
> > > in order to make ibus-anthy to work.
> > > 
> > > I have prepared an XDG Autostart .desktop file which should be
> > > installed to
> > > /etc/xdg/autostart/ibus-anthy-gnome-initial-setup.desktop
> > > and its corresponding script to be installed to
> > > /usr/share/ibus-anthy/ibus-anthy-gnome-initial-setup.sh
> > > to automatically set-up ibus-anthy immediately after each user's
> > > next login.
> > > 
> > > Sorry for the tight schedule, but hopefully this should be
> > > included in
> > > the bullseye release
> > > (See also Bug#983653.)
> > > 
> > > Thanks in advance,
> > 
> > Back to this issue only(ibus doesn't have a working default). I
> > find
> > task-korean-gnome-desktop Recommends gnome-initial-setup,
> > And above the Recommends, it has a comment that says:
> > 
> > > GNOME doesn't set the working Korean IM by default
> > 
> > https://salsa.debian.org/installer-team/tasksel/-/blob/002c2a97/debian/control#L1547
> > 
> > So I think this is the workaround by Korean users. Which now GNOME
> > defaults ibus, and ibus doesn't pick up the right defaults for all.
> > Maybe we should find a universal solution?
> 
> To me that sounds as a good idea, especially given how late we are in
> the cycle. I just run gnome-initial-setup, and even if it starts with
> a 
> redundant question (about locale), the second question is about
> typing.
> 
> So provided that the release-team approves the creation of a bunch of
> new task-*-gnome-desktop packages, I suppose that adding 
> gnome-initial-setup as a dependency in those would be easier than
> adding 
> the proposed auto setup script to several ibus-* packages.
> 

Bug#984870: error: unrecognizable insn when compiling Linux kernel 5.12.0-rc2

[Arthur Marsh]

Package: gcc-11
Version: 11-20210306-1
Severity: normal
Tags: upstream

Dear Maintainer,

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

   * What led up to the situation?

Attempting to build Linux kernel 5.12.0-rc2 with gcc-11

   * What exactly did you do (or not do) that was effective (or
 ineffective)?
   * What was the outcome of this action?

drivers/net/ethernet/broadcom/tg3.c: In function ‘tg3_start_xmit’:
drivers/net/ethernet/broadcom/tg3.c:8159:1: error: unrecognizable insn:
 8159 | }
  | ^
(insn 251 1381 1452 24 (parallel [
(set (reg:SI 0 ax [orig:522 sum ] [522])
(asm_operands:SI ("  addl %1, %0
  adcl %2, %0
  adcl %3, %0
  adcl $0, %0
") ("=r") 0 [
(mem:SI (plus:DI (mem/c:DI (plus:DI (reg/f:DI 7 sp)
(const_int 80 [0x50])) [565 %sfp+-24 S8 
A64])
(const_int 16 [0x10])) [4 MEM[(struct iphdr *)_2
61].daddr+0 S4 A32])
(mem:SI (plus:DI (mem/c:DI (plus:DI (reg/f:DI 7 sp)
(const_int 80 [0x50])) [565 %sfp+-24 S8 
A64])
(const_int 12 [0xc])) [4 MEM[(struct iphdr *)_26
1].saddr+0 S4 A32])
(const_int 1536 [0x600])
(reg:SI 0 ax [orig:522 sum ] [522])
]
 [
(asm_input:SI ("g") ./arch/x86/include/asm/checksum_64.h
:91)
(asm_input:SI ("g") ./arch/x86/include/asm/checksum_64.h
:91)
(asm_input:SI ("g") ./arch/x86/include/asm/checksum_64.h
:91)
(asm_input:SI ("0") ./arch/x86/include/asm/checksum_64.h
:91)
]
 [] ./arch/x86/include/asm/checksum_64.h:91))
(clobber (reg:CC 17 flags))
]) "./arch/x86/include/asm/checksum_64.h":91:2 -1
 (nil))
during RTL pass: reload
drivers/net/ethernet/broadcom/tg3.c:8159:1: internal compiler error: in extract_
constrain_insn, at recog.c:2670
0xcd039b _fatal_insn(char const*, rtx_def const*, char const*, int, char const*)
../../src/gcc/rtl-error.c:108
0xcd052b _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
../../src/gcc/rtl-error.c:116
0x954af4 extract_constrain_insn(rtx_insn*)
../../src/gcc/recog.c:2670
0x954af4 extract_constrain_insn(rtx_insn*)
../../src/gcc/recog.c:2666
0x954af4 check_rtl
../../src/gcc/lra.c:2087
0x176d87c lra(_IO_FILE*)
../../src/gcc/lra.c:2505
0x176c249 do_reload
../../src/gcc/ira.c:5827
0x176c249 execute
../../src/gcc/ira.c:6013


   * What outcome did you expect instead?

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

This appears to be the same or similar bug to:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99461

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

Kernel: Linux 5.12.0-rc2+ (SMP w/4 CPU threads)
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB
Shell: /bin/sh linked to /bin/bash
Init: sysvinit (via /sbin/init)

Versions of packages gcc-11 depends on:
ii  binutils   2.36.1-5
ii  cpp-11 11-20210306-1
ii  gcc-11-base11-20210306-1
ii  libc6  2.31-9
ii  libcc1-0   11-20210306-1
ii  libgcc-11-dev  11-20210306-1
ii  libgcc-s1  11-20210306-1
ii  libgmp10   2:6.2.1+dfsg-1
ii  libisl23   0.23-1
ii  libmpc31.2.0-1
ii  libmpfr6   4.1.0-3
ii  libstdc++6 10.2.1-6
ii  libzstd1   1.4.8+dfsg-2.1
ii  zlib1g 1:1.2.11.dfsg-2

Versions of packages gcc-11 recommends:
ii  libc6-dev  2.31-9

Versions of packages gcc-11 suggests:
pn  gcc-11-doc   
pn  gcc-11-locales   
pn  gcc-11-multilib  

-- no debconf information

Bug#984753: towncrier: Manual page needed for 'towncrier(1)'

[Sérgio Cipriano]

Thanks for the tips and the links, they helped a lot.

I created a merge request [1] for your repository with the manpage and 
forwarded it to upstream [2].

[1]: https://salsa.debian.org/bignose/pkg-towncrier/-/merge_requests/1
[2]: https://github.com/twisted/towncrier/pull/326

--
Sérgio Cipriano

Bug#978650: podman: please provide a default container registry for looking up short image names

[Reinhard Tartler]

Control: reassign -1 golang-github-containers-common
Control: tag -1 wontfix
Control: severity -1 normal
Control: affects -1 podman

On Mon, Jan 4, 2021 at 3:47 PM Antonio Terceiro  wrote:

> On Thu, Dec 31, 2020 at 11:26:49AM -0300, Antonio Terceiro wrote:
> > Control: done -1 2.2.1+dfsg1-1
> >
> > On Thu, Dec 31, 2020 at 08:14:08AM -0500, Reinhard Tartler wrote:
> > > Can you please try the podman version in experimental? I believe what
> you
> > > describe (the shortnames) should work with version 2.2 just fine
> thanks to
> > > the shortnames.conf file.
> >
> > Ah yes the version in exprimental does fix this. Thanks!
>
> Actually, this only solves the issue for the few official images that
> are listed by default in
> /etc/containers/registries.conf.d/shortnames.conf
>
> Other image names still won't work. But I guess unqualified names are an
> anti-pattern in general?
>
In short, yes.

podman does support what you are asking for, it is just not enabled
by default.

If you wish to, you may set the option "unqualified-search-registries" for
your user
in $HOME/.config/containers/registries.conf, or system-wide
in /etc/containers/registries.conf.
This is documented in great detail on
http://manpages.debian.org/containers-registries.conf

In general, I would find it a reasonable choice to not trust the images on
docker.io
in general. You may want to prefer another container registry, possibly a
local one, over the
one hosted by hub.docker.com. Possibly you require encryption or other
security features.
Podman offers a lot of knobs that are documented in that manpage.

As package maintainer, setting the option of an unqualified path makes
decisions on behalf
of the local system administrator that I'm not necessarily comfortable
making in general. By
refusing to set this, I am trying to raise awareness of the security
implication and hope this
encourages users that may not be familiar with the security implications of
using OCI images
from untrusted sources to do some additional research.

I hope this reasoning makes sense to you. I'm happy to discuss this further
and consider
additional thoughts and input on the matter.

-- 
regards,
Reinhard

Bug#984868: ensmallen ftbfs on arm64, ppc64el, s390x

[Matthias Klose]

Package: src:ensmallen
Version: 2.16.1-2
Severity: serious
Tags: sid

ensmallen ftbfs on arm64, ppc64el, s390x, test failures:

The following tests FAILED:
  1 - ensmallen_tests (Failed)
Errors while running CTest
make[2]: *** [Makefile:119: test] Error 8
make[2]: Leaving directory '/<>/obj-aarch64-linux-gnu'
dh_auto_test: error: cd obj-aarch64-linux-gnu && make -j4 test ARGS\+=-j4
returned exit code 2
failure
Test Run 3
cd obj-aarch64-linux-gnu && make -j4 test ARGS\+=-j4
make[2]: Entering directory '/<>/obj-aarch64-linux-gnu'
Running tests...
/usr/bin/ctest --force-new-ctest-process -j4
Test project /<>/obj-aarch64-linux-gnu
Start 1: ensmallen_tests
1/1 Test #1: ensmallen_tests ..***Failed  493.76 sec
ensmallen version: 2.16.1 (Severely Dented Can Of Polyurethane)
armadillo version: 10.1.2 (Orchid Ambush)

~~~
ensmallen_tests is a Catch v2.4.1 host application.
Run with -? for options

---
AdamSchafferFunctionN2Test
---
./tests/adam_test.cpp:331
...

./tests/test_function_tools.hpp:114: FAILED:
  REQUIRE( objective == Approx(expectedObjective).margin(objectiveMargin) )
with expansion:
  0.4988660434 == Approx( 0.0 )

===
test cases:   274 |   273 passed | 1 failed
assertions: 13331 | 13330 passed | 1 failed



0% tests passed, 1 tests failed out of 1

Total Test time (real) = 493.76 sec

The following tests FAILED:
  1 - ensmallen_tests (Failed)
Errors while running CTest
make[2]: *** [Makefile:119: test] Error 8

Bug#980809: rmatrix: breaks autopkgtest of r-cran-glmmtmb on s390x

[Dirk Eddelbuettel]

On 9 March 2021 at 14:26, Graham Inggs wrote:
| Control: tags -1 - fixed-upstream + upstream
| Control: notforwarded -1
| 
| 
| >From TMB upstream [1]:
| 
| > Digging a bit deeper I found that after calling
| >
| > M_cholmod_factorize_p(A, mm, (int*)NULL, 0 /*fsize*/, f, )
| >
| > the cholmod_common struct contains bogus, e.g. c.status=14903956 and 
c.dtype=15216988.
| 
| 
| [1] https://github.com/kaskr/adcomp/issues/340#issuecomment-790606775

Appreciate the hard-core digging Graham!

And said call is made by glmmTMB in error, or is the call done by Matrix as
part of exposing CHOLMOD? 

Dirk

-- 
https://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

Bug#984867: grub-pc reports "grub_verify_string not found"

[Colin Watson]

On Tue, Mar 09, 2021 at 01:57:07PM +0100, Carsten Wolf wrote:
> after rebooting grub report an error 
> 
> GRUB-loading
> Welcome to GRUB!
> error: symbol 'grub_verfy_string' not found
> grub rescue> 
> 
> try to boot manualy:
> 
> grub rescue> ls (hd0,1)/
> ./ ../ lost+found/ opt/ etc/ tmp/ vmlinuz /boot /bin ...
> 
> grub rescue> set root=(hd0,1)
> grub rescue> set prefix=(hd0,1)/boot/grub
> grub rescue> insmod normal
> error: symbol 'grub_verfy_string' not found
> grub rescue> 

The GRUB packaging is almost certainly configured to install GRUB to the
wrong place, i.e. not the place from which your firmware actually boots.
I suggest running "sudo dpkg-reconfigure grub-pc" and fixing its
configuration in whatever way is appropriate to your system.

-- 
Colin Watson (he/him)  [cjwat...@debian.org]

Bug#984472: e2fsprogs: resize2fs on inconsistent filesystem (in a way that e2fsck doesn't detect) completely corrupts MMP data (in a way e2fsck can't recover from)

[наб]

On Sat, Mar 06, 2021 at 11:07:53PM -0500, Theodore Ts'o wrote:
> 1.  e2image -r rbd13.e2i.qcow2 /tmp/rbd13
> 2.  truncate -s 10T /tmp/rbd13
> 3.  e2fsck -fy /tmp/rbd13
> 4.  resize2fs /tmp/rbd13
> 5.  e2fsck -fy /tmp/rbd13
>   
(FTR: the report specified these instructions almost exactly
  (the first fsck step is noted as optional,
   since the corruption happened regardless thereof))

> The bug report was also incorrect by saying that resizing the file
> system to 4T was sufficient; that is not true.
I must've conflated the results during testing somehow, apologies.

> I suppose we can add some "are you sure?  ARE YOU REALLY SURE?"
> question to "tune2fs -f -E clear_mmp", [...]

> Another workaround is to simply do an online resize (that is, on the
> node where the file system is mounted, run resize2fs on the mounted
> file system).
This was all performed on a snapshot, which by definition is not mounted
on any node, even if it had been when snapped.

Indeed, there was no possibility of another node in my local non-ceph
testing, purely because it was a local, unexported zvol,
and I'm rather sure it wasn't mounted at any point when e2fsck/resize2fs
were running, hence why I obliged to clearing the MMP in the first place.

I've tried the patches and they appear to work pefectly,
and I can no longer trigger this in any configuration
in either environment.

Thanks!
наб


signature.asc
Description: PGP signature