Bug#980902: rmatrix: which reverse dependencies need rebuilds?

[Andreas Tille]

On Sun, Jan 24, 2021 at 06:08:52AM +0200, Graham Inggs wrote:
> I will schedule a binNMU for r-cran-tmb for now, but it still needs
> the versioned dependency added.  Is this something that dh-r could do?

dh-r injects versioned dependencies if this is specified in the
DESCRIPTION file of an r-* package.  If this is not specified we
need to add this manually (which I can do - but for sure the
automatic solution would be more convenient.

> The actual warning message is generated by r-base, is there a way to
> make this an error instead of a warning?

An error would be safer to make sure its not overlooked.  I have no
insight how sensible this is from an R maintainers perspective.

Kind regards

   Andreas.

-- 
http://fam-tille.de

Bug#970124: Patch prepared for NMU

[Bruno Kleinert]

Hi,

please find attached a patch. If Julian or nobody else objects or jumps
in, I can NMU in about one week.

Cheers,
Bruno
From 0fa6610179dfccadc82f135e8860c03378aa5b90 Mon Sep 17 00:00:00 2001
From: Bruno Kleinert 
Date: Sun, 24 Jan 2021 07:52:35 +0100
Subject: [PATCH] Add depedency on gpg

---
 debian/changelog |  9 +
 debian/control   |  1 +
 2 files changed, 10 insertions(+)

diff --git a/debian/changelog b/debian/changelog
index 22af59f..f1656de 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,12 @@
+software-properties (0.96.20.2-2.2) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Added dependency on gpg in binary package software-properties common. This
+fixes "software-properties-common: add-apt-repository: missing dependency
+gpg (gnupg)". Thanks to Felix Stupp for the report. (Closes: #970124)
+
+ -- Bruno Kleinert   Sun, 24 Jan 2021 07:47:27 +0100
+
 software-properties (0.96.20.2-2.1) unstable; urgency=medium
 
   * Non-maintainer upload.
diff --git a/debian/control b/debian/control
index fe3fb0d..829d8d0 100644
--- a/debian/control
+++ b/debian/control
@@ -36,6 +36,7 @@ Architecture: all
 Depends: ca-certificates,
  gir1.2-glib-2.0,
  gir1.2-packagekitglib-1.0 (>= 1.1.0-2),
+ gpg,
  python-apt-common (>= 0.9),
  python3,
  python3-dbus,
--
libgit2 1.1.0



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

Bug#980727: RFS: grap/1.46-1 [QA] -- program for typesetting graphs

[Sergio Durigan Junior]

Control: owner -1 !

On Thursday, January 21 2021, Leandro Cunha wrote:

> Changes since the last upload:
>
>  grap (1.46-1) unstable; urgency=medium
>  .
>* QA upload.
>* New upstream release.
>* Added debian/gbp.conf.

I don't see a reason to add a gbp.conf given that the package is not
maintained in git.  Moreover, the settings you're proposing seem
personal choices more suitable for a local ~/.gbp.conf than for a
project one.

>* Added debian/upstream/metadata.
>* Added debian/docs.

While at it, please add a newline at the end of d/docs.

>* debian/copyright:
>  - Added Upstream-Contact optional field according DEP-5.

Thanks,

-- 
Sergio
GPG key ID: 237A 54B1 0287 28BF 00EF  31F4 D0EB 7628 65FC 5E36
Please send encrypted e-mail if possible
https://sergiodj.net/


signature.asc
Description: PGP signature

Bug#980903: debhelper: doc-base doc-id deduplication does not work as documented with multiple "dh_installdocs -p" calls; causes /usr/share/doc-base/ to be installed multiple times

[Axel Beckert]

Control: tag -1 + patch

Hi again,

Axel Beckert wrote:
> Current idea is to _always_ use unique file names for
> /usr/share/doc-base/, i.e. always use . to be
> unique. This also avoids the need for caching and makes things easier.

I've now implemented this and the code is much simpler than beforehand:

https://salsa.debian.org/debian/debhelper/-/merge_requests/45

* The package builds fine and the build-time test suite passes
* The above mentioned zsh package now builds fine and as expected.
* doc-base behaves as expected on merging the two zsh-faq files after
  installing those built zsh* packages.
* Salsa pipeline passed.

Will keep that debhelper test build installed locally and see if I run
into any issues while using it until a new debhelper release is
uploaded.

> Then again, it changes the behaviour for other cases, too. Not sure
> how appreciated this is at this stage of the freeze.

Still curious on this. :-)

Going to bed now. ;-)

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#980905: fstrim: FITRIM ioctl failed: Device or resource busy on NTFS device

[ciwei100000]

Package: util-linux
Version: 2.36.1-6
Severity: normal

I encountered the same issue reported by this post
(https://bbs.archlinux.org/viewtopic.php?id=262243).

fstrim failed on NTFS device after upgrading to kernel 5.10. When I type the
command "sudo fstrim -av", it works on EXT4 device but not on NTFS. The error
message is listed below:

--
fstrim: /mnt/D: FITRIM ioctl failed: Device or resource busy
/: 3.5 GiB (3715059712 bytes) trimmed on /dev/sda4
--

I have ntfs3g installed and can confirm it worked on kernel 5.9.15. I am not
sure whether it is a kernel change or a bug of fstrim. Please let me know if
there is anything I could help.

util-linux version: 2.36.1-6



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

Kernel: Linux 5.10.4 (SMP w/8 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)
LSM: AppArmor: enabled

Versions of packages util-linux depends on:
ii  libaudit1  1:2.8.4-3
ii  libblkid1  2.36.1-6
ii  libc6  2.28-10
ii  libcap-ng0 0.7.9-2
ii  libmount1  2.36.1-6
ii  libpam0g   1.3.1-5
ii  libselinux12.8-1+b1
ii  libsmartcols1  2.36.1-6
ii  libsystemd0247.2-4~bpo10+1
ii  libtinfo6  6.1+20181013-2+deb10u2
ii  libudev1   247.2-4~bpo10+1
ii  libuuid1   2.36.1-6
ii  login  1:4.5-1.1
ii  zlib1g 1:1.2.11.dfsg-2

util-linux recommends no packages.

Versions of packages util-linux suggests:
ii  dosfstools  4.1-2
ii  kbd 2.0.4-4
ii  util-linux-locales  2.36.1-6

-- Configuration Files:
/etc/pam.d/su changed [not included]

-- no debconf information

Bug#979187: 977694 & 979187 fixed-upstream but remain in Debian :-

[Ryutaroh Matsumoto]

Control: severity -1 minor

The bug #979187 was the boot failure from the USB MSD
ID 056e:6a13 Elecom Co., Ltd ESD-EMN.

With the kernel .config

From: Ryutaroh Matsumoto 
> CONFIG_RESET_RASPBERRYPI=y
> CONFIG_ARM_RASPBERRYPI_CPUFREQ=y
> CONFIG_SENSORS_RASPBERRYPI_HWMON=y

Kernel mounted the root partition, but the USB MSD stopped
responding during the boot. The photo is
https://photos.app.goo.gl/QWMmrhyM9FT2WZ2f9

My impression is that this USB MSD is simply buggy...
But it worked with Debian kernel 5.9...

Since USB MSD looks very buggy, I lowered severity to minor...

Best regards, Ryutaroh Matsumoto

Bug#977694: 977694 & 979187 fixed-upstream but remain in Debian :-

[Ryutaroh Matsumoto]

Control: tags -1 + patch

> linux-config-5.10/sid, and the symptoms 977694 and 979187 are reproduced.
> My impression is that raspi4 USB-MSD boot failure can be fixed by properly
> changing .config. I will investigate what are required changes to the config.

I identified changes in .config enabling boot of raspi 4B from USB MSD.
The following script built a debian kernel package that can boot from
(not buggy) USB MSD. Build was done on raspi 4B.

#!/bin/bash
set -x
apt-get source linux/sid
cd linux-5.10.9
fakeroot make -f debian/rules.gen setup_arm64_none_arm64
cat >>debian/build/build_arm64_none_arm64/.config <<'EOF'
CONFIG_RESET_RASPBERRYPI=y
CONFIG_ARM_RASPBERRYPI_CPUFREQ=y
CONFIG_SENSORS_RASPBERRYPI_HWMON=y
EOF
yes | make -C debian/build/build_arm64_none_arm64 oldconfig
yes | fakeroot /usr/bin/make -j 12 -f debian/rules.gen 
binary-arch_arm64_none_arm64

I believe 
CONFIG_RESET_RASPBERRYPI=y
CONFIG_ARM_RASPBERRYPI_CPUFREQ=y
CONFIG_SENSORS_RASPBERRYPI_HWMON=y
fix 977694. On the other hand, the other issue 979187 remains.
I will report the situation of 979187 in a separete email.

Best regards, Ryutaroh Matsumoto
[0.00] Booting Linux on physical CPU 0x00 [0x410fd083]
[0.00] Linux version 5.10.0-2-arm64 (debian-ker...@lists.debian.org) 
(gcc-10 (Debian 10.2.1-6) 10.2.1 20210110, GNU ld (GNU Binutils for Debian) 
2.35.1) #1 SMP Debian 5.10.9-1 (2021-01-20)
[0.00] Machine model: Raspberry Pi 4 Model B Rev 1.4
[0.00] efi: UEFI not found.
[0.00] Reserved memory: created CMA memory pool at 0x3700, 
size 64 MiB
[0.00] OF: reserved mem: initialized node linux,cma, compatible id 
shared-dma-pool
[0.00] NUMA: No NUMA configuration found
[0.00] NUMA: Faking a node at [mem 
0x-0x0001]
[0.00] NUMA: NODE_DATA [mem 0x1ff019b00-0x1ff01bfff]
[0.00] Zone ranges:
[0.00]   DMA  [mem 0x-0x3fff]
[0.00]   DMA32[mem 0x4000-0x]
[0.00]   Normal   [mem 0x0001-0x0001]
[0.00] Movable zone start for each node
[0.00] Early memory node ranges
[0.00]   node   0: [mem 0x-0x3b2f]
[0.00]   node   0: [mem 0x4000-0xfbff]
[0.00]   node   0: [mem 0x0001-0x0001]
[0.00] Zeroed struct page in unavailable ranges: 256 pages
[0.00] Initmem setup node 0 [mem 0x-0x0001]
[0.00] On node 0 totalpages: 2061056
[0.00]   DMA zone: 3788 pages used for memmap
[0.00]   DMA zone: 0 pages reserved
[0.00]   DMA zone: 242432 pages, LIFO batch:63
[0.00]   DMA32 zone: 12288 pages used for memmap
[0.00]   DMA32 zone: 770048 pages, LIFO batch:63
[0.00]   Normal zone: 16384 pages used for memmap
[0.00]   Normal zone: 1048576 pages, LIFO batch:63
[0.00] percpu: Embedded 33 pages/cpu s95192 r8192 d31784 u135168
[0.00] pcpu-alloc: s95192 r8192 d31784 u135168 alloc=33*4096
[0.00] pcpu-alloc: [0] 0 [0] 1 [0] 2 [0] 3 
[0.00] Detected PIPT I-cache on CPU0
[0.00] CPU features: detected: EL2 vector hardening
[0.00] CPU features: kernel page table isolation forced ON by KASLR
[0.00] CPU features: detected: Kernel page table isolation (KPTI)
[0.00] CPU features: detected: Spectre-v2
[0.00] CPU features: detected: Spectre-v4
[0.00] CPU features: detected: ARM errata 1165522, 1319367, or 1530923
[0.00] Built 1 zonelists, mobility grouping on.  Total pages: 2028596
[0.00] Policy zone: Normal
[0.00] Kernel command line:  dma.dmachans=0x37f5 
bcm2709.boardrev=0xd03114 bcm2709.serial=0x488d2af3 bcm2709.uart_clock=4800 
bcm2709.disk_led_gpio=42 bcm2709.disk_led_active_low=0 
smsc95xx.macaddr=DC:A6:32:BB:99:D9 vc_mem.mem_base=0x3eb0 
vc_mem.mem_size=0x3ff0  root=LABEL=RASPIROOT rw fsck.repair=yes 
net.ifnames=0  rootwait
[0.00] Dentry cache hash table entries: 1048576 (order: 11, 8388608 
bytes, linear)
[0.00] Inode-cache hash table entries: 524288 (order: 10, 4194304 
bytes, linear)
[0.00] mem auto-init: stack:off, heap alloc:on, heap free:off
[0.00] software IO TLB: mapped [mem 
0x3300-0x3700] (64MB)
[0.00] Memory: 4911236K/8244224K available (11648K kernel code, 2420K 
rwdata, 6852K rodata, 5312K init, 588K bss, 282316K reserved, 65536K 
cma-reserved)
[0.00] random: get_random_u64 called from 
__kmem_cache_create+0x3c/0x590 with crng_init=0
[0.00] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=4, Nodes=1
[0.00] ftrace: allocating 37908 entries in 149 pages
[0.00] ftrace: allocated 149 pages with 4 groups
[0.00] rcu: Hierarchical RCU implementation.
[0.00] rcu: RCU restricting CPUs from NR_CPUS=256 

Bug#972747: Where is /usr/share/sbuild/create-chroot actually used?

[Bruno Kleinert]

Hi,

I looked into /usr/share/sbuild/create-chroot to create a patch, but
began to wonder where and if that script is actually used. I use sbuild
to locally build packages on my desktop computer, so it's installed,
and

grep -r create-chroot /usr/sbin/sbuild* /usr/bin/sbuild*

does not show any matches.

Reverse dependencies and reverse recommends of sbuild are:
   1. mini-buildd
   2. arriero
   3. xbuilder
   4. ubuntu-dev-tools
   5. schroot
   6. sbuild-debian-developer-setup
   7. ratt
   8. qemu-sbuild-utils
   9. pk4
  10. packaging-dev
  11. debomatic
  12. lava-dev
  13. git-buildpackage

I downloaded and extracted them and grepped for 'create-chroot' in
their contents: No matches.

Looking into create-chroot revealed:

[…]
OLDSTABLE="squeeze"
STABLE="wheezy"
TESTING="jessie"
[…]

That leaves the impression the script was last used a couple of
releases ago and could simply be removed to close this bug.

Cheers,
Bruno


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

Bug#975535: elpy's autopkg tests fail with Python 3.9

[Adrian Bunk]

On Fri, Dec 25, 2020 at 08:57:49PM -0500, Nicholas D Steeves wrote:
>...
> I've made progress with this, and encountered a couple blockers along
> the way (one outstanding at this time).  Currently the need for Jedi
> 0.18 means the work in git (Elpy 1.35 minus rope, plus cherrypicked
> support for Jedi refactoring) cannot yet be uploaded.
>...

Jedi 0.18.0 is now in unstable:
https://tracker.debian.org/pkg/python-jedi

> Regards,
> Nicholas

cu
Adrian

Bug#895462: asciidoc: deprecate in Debian

[Paul Wise]

On Wed, 11 Apr 2018 11:49:14 -0700 Joseph Herlant wrote:

> As announced by upstream in their last release[1], this is probably the
> last release of asciidoc and encourage people to move to alternate tools
> such as asciidoctor.
> 
> Asciidoc currently supports python2 only and the port to python3 [2] don't
> seem to receive enough effort to go through [3], [4].

Since then the Python 3 port reached Debian, does this mean that this
bug report should be closed or should packages still drop asciidoc?

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#980904: asciidoc: new upstream release 9.0.5

[Paul Wise]

Source: asciidoc
Version: 9.0.0~rc2-1
Severity: wishlist

Please updated asciidoc to the new upstream release 9.0.5.
There have been a lot of bug fixes since version 9.0.0rc2:

https://github.com/asciidoc/asciidoc-py3/releases

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#980903: debhelper: doc-base doc-id deduplication does not work as documented with multiple "dh_installdocs -p" calls; causes /usr/share/doc-base/ to be installed multiple times

[Axel Beckert]

Hi,

braindump after further analysing this issue:

Axel Beckert wrote:
> override_dh_installdocs-indep:
>   dh_installdocs -pzsh-doc --link-doc=zsh-common 
> --doc-main-package=zsh-common
>   dh_installdocs -pzsh-common
> 
> But the documented deduplication only happens within a single
> dh_installdocs call and is not spread over multiple calls.
> 
> So IMHO the value of %used_doc_ids needs to be cached somewhere under
> debian/.debhelper/ or similar and if that cache file exists, it needs to
> be read upon every dh_installdocs invocation.

This is uglier than I initially thought:

In the case above the doc-id is spread over two arch-indep packages,
so the all affected dh_installdocs calls are always either executed or
not, depending if only arch:all or only arch:any packages are built.

But if one dh_installdocs call is in override_dh_installdocs-arch and
one is in override_dh_installdocs-indep, the resulting package contents
differs depending if dpkg-buildpackage is building both, arch:all and
arch:any in one go, or separately.

This implies that you can scratch my initial idea of caching that
hash value.

Current idea is to _always_ use unique file names for
/usr/share/doc-base/, i.e. always use . to be
unique. This also avoids the need for caching and makes things easier.

Then again, it changes the behaviour for other cases, too. Not sure
how appreciated this is at this stage of the freeze.

Any comments on this are appreciated.

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#980902: rmatrix: which reverse dependencies need rebuilds?

[Dirk Eddelbuettel]

Graham,

On 24 January 2021 at 06:08, Graham Inggs wrote:
| Source: rmatrix
| Version: 1.3-2-1
| Severity: important
| Control: affects -1 src:r-cran-tmb
| X-Debbugs-CC: debia...@lists.debian.org
| 
| Hi R Maintainers

There is a confusion here. You filed this again rmatrix (aka "Matrix").
Matrix does not impose dependencies -- dependent packages do.

I as maintainer of Matrix aka r-cran-matrix aka souce package rmatrix (for
historical reasons) have no control over this.

I suggest we close this.
 
| While investigating #980809 [1], I found the following output in the
| autopkgtest logs of and r-cran-glmmtmb and r-cran-tmb:

So would you please consider assigning bugs to those packages?

Dirk, who is the messenger being shot at here

| Warning message:
| In checkMatrixPackageVersion() : Package version inconsistency detected.
| TMB was built with Matrix version 1.2.18
| Current Matrix version is 1.3.2
| Please re-install 'TMB' from source using install.packages('TMB', type
| = 'source') or ask CRAN for a binary version of 'TMB' matching CRAN's
| 'Matrix' package
| 
| This is a clear sign that at least r-cran-tmb needs a rebuild and
| should gain a versioned dependency on the version of r-cran-matrix
| that it was built against.
| 
| I will schedule a binNMU for r-cran-tmb for now, but it still needs
| the versioned dependency added.  Is this something that dh-r could do?
|   We also need to find other affected packages.
| 
| The actual warning message is generated by r-base, is there a way to
| make this an error instead of a warning?
| 
| Regards
| Graham
| 
| 
| [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=980809#14

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

Bug#980903: debhelper: doc-base doc-id deduplication does not work as documented with multiple "dh_installdocs -p" calls; causes /usr/share/doc-base/ to be installed multiple times

[Axel Beckert]

Package: debhelper
Version: 13.3.1
Severity: serious
Justification: Causes file conflicts within binary packages of the same source 
package
Control: block 961757 by -1

While trying to solve https://bugs.debian.org/961757 ("Please install
the FAQ") in zsh, I ran into the following IMHO severe issue reported by
lintian at "warning level":

W: zsh source: binaries-have-file-conflict zsh-common zsh-doc 
usr/share/doc-base/zsh-faq

Scenario: I have two documents which I want to register with doc-base:
the Zsh Manual and the Zsh FAQ. Both are available in different file
formats. The FAQ is split over two binary packages (plain text in
zsh-common, HTML in zsh-doc) and I tried to use this technique described
in dh_installdocs man page:

   debian/package.doc-base.*
   If your package needs to register more than one document, you
   need multiple doc-base files, and can name them like this. In
   the event that multiple doc-base files of this style in a
   single source package share the same doc-id, they will be
   installed to usr/share/doc-base/package-* instead of
   usr/share/doc-base/doc-id.

But this deduplication does not happen with zsh as the lintian warning
cited above shows.

I tried different file name combinations. Initially I had:

$ find debian -name '*doc-base*' | xargs fgrep Document:
debian/zsh-common.doc-base.faq:Document: zsh-faq
debian/zsh-doc.doc-base.faq:Document: zsh-faq
debian/zsh-doc.doc-base.manual:Document: zsh

Since there's only one document to register with in zsh-common, I tried
to use zsh-common.doc-base instead of zsh-common.doc-base.faq:

$ find debian -name '*doc-base*' | xargs fgrep Document:
debian/zsh-common.doc-base:Document: zsh-faq
debian/zsh-doc.doc-base.faq:Document: zsh-faq
debian/zsh-doc.doc-base.manual:Document: zsh

In both cases, there was indeed one file twice in the built binary
packages, as expected with different size:

$ debc | fgrep zsh-faq
-rw-r--r-- root/root   504 2021-01-24 00:45 ./usr/share/doc-base/zsh-faq
-rw-r--r-- root/root   519 2021-01-24 00:45 ./usr/share/doc-base/zsh-faq

After running the build with DH_VERBOSE=1, I found the reason: zsh's
debian/rules calls dh_installdocs multiple times with the -p
option due to different options:

override_dh_installdocs-indep:
dh_installdocs -pzsh-doc --link-doc=zsh-common 
--doc-main-package=zsh-common
dh_installdocs -pzsh-common

But the documented deduplication only happens within a single
dh_installdocs call and is not spread over multiple calls.

So IMHO the value of %used_doc_ids needs to be cached somewhere under
debian/.debhelper/ or similar and if that cache file exists, it needs to
be read upon every dh_installdocs invocation.

Setting severity to RC as I think that debhelper should not be released
in bullseye with this issue being present, except if (worst case)
documented in dh_installdocs(1) as exception or (obviously) if fixed. (I
think being one of the top 5 committers of debhelper, I still can claim
that this is the maintainer's opinion, even though I haven't really
committed something for a few years and still have way less commits than
Niels has. I also intend to have a look into a solution, but if Niels is
quicker, he's of course free to fix it first. Hints are also
appreciated. ;-)

P.S.: The zsh package triggering this issue can be found in git in the
install-faq-961757 branch since I didn't want to commit this to the
normal packaging branch (called "debian" in this repo):
https://salsa.debian.org/debian/zsh/-/tree/install-faq-961757

P.P.S.: According to "git blame" this bug is in there since that feature
(see #525821) was added in debhelper 9.20130504. I quite surprised
that nobody else seems to have ran into it so far.

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

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

Versions of packages debhelper depends on:
ii  autotools-dev20180224.1+nmu1
ii  dh-autoreconf19
ii  dh-strip-nondeterminism  1.10.0-1
ii  dpkg 1.20.7.1
ii  dpkg-dev 1.20.7.1
ii  dwz  0.13+20210118-1
ii  file 1:5.39-3
ii  libdebhelper-perl13.3.1
ii  libdpkg-perl 1.20.7.1
ii  man-db   2.9.3-2
ii  perl 5.32.0-6
ii  po-debconf   1.0.21+nmu1

debhelper recommends no packages.

Versions of packages debhelper suggests:
ii  dh-make  2.202003

-- no debconf information

Bug#980204: gdc: Resulting executables segfault on mipsel architecture (signal 11)

[Iain Buclaw]

Excerpts from Iain Buclaw's message of January 23, 2021 11:07 am:
> Excerpts from Iain Buclaw's message of January 23, 2021 2:36 am:
>> 
>> So the crux of the matter is that on MIPS, dynamic sections are read-only
>> (glibc sets DL_RO_DYN_SECTION 1), which requires special handling when 
>> pulling
>> data from dl_phdr_info.
>> 
>> Re-running with the attached patch applied.
>> 
>> Iain.
>> 
>> --- a/libphobos/libdruntime/gcc/sections/elf_shared.d
>> +++ b/libphobos/libdruntime/gcc/sections/elf_shared.d
>> @@ -22,6 +22,8 @@
>>  
>>  module gcc.sections.elf_shared;
>>  
>> +version (MIPS32)  version = MIPS_Any;
>> +version (MIPS64)  version = MIPS_Any;
>>  version (RISCV32) version = RISCV_Any;
>>  version (RISCV64) version = RISCV_Any;
>>  version (S390)version = IBMZ_Any;
>> @@ -763,6 +765,8 @@ version (Shared)
>>  // in glibc: #define DL_RO_DYN_SECTION 1
>>  version (RISCV_Any)
>>  strtab = cast(const(char)*)(info.dlpi_addr + 
>> dyn.d_un.d_ptr); // relocate
>> +else version (MIPS_Any)
>> +strtab = cast(const(char)*)(info.dlpi_addr + 
>> dyn.d_un.d_ptr); // relocate
>>  else
>>  strtab = cast(const(char)*)dyn.d_un.d_ptr;
>>  }
>> 
>> 
> 
> It's halfway through now, and confirm that I see no more failures in the
> testsuite, so I'm fairly confident that everything should be OK now,
> though I'll try building your package later.
> 
> In case I don't get round to doing it myself this weekend, could a PR be
> raised in gcc bugzilla about it?  This so I can reference it in
> backports to gdc-10 and gdc-9.
> 

The logmake application runs just fine here.  Fix has been committed to
gcc mainline, and backported to the version 9 and 10 release branches.

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

Regards
Iain.

Bug#980902: rmatrix: which reverse dependencies need rebuilds?

[Graham Inggs]

Source: rmatrix
Version: 1.3-2-1
Severity: important
Control: affects -1 src:r-cran-tmb
X-Debbugs-CC: debia...@lists.debian.org

Hi R Maintainers

While investigating #980809 [1], I found the following output in the
autopkgtest logs of and r-cran-glmmtmb and r-cran-tmb:

Warning message:
In checkMatrixPackageVersion() : Package version inconsistency detected.
TMB was built with Matrix version 1.2.18
Current Matrix version is 1.3.2
Please re-install 'TMB' from source using install.packages('TMB', type
= 'source') or ask CRAN for a binary version of 'TMB' matching CRAN's
'Matrix' package

This is a clear sign that at least r-cran-tmb needs a rebuild and
should gain a versioned dependency on the version of r-cran-matrix
that it was built against.

I will schedule a binNMU for r-cran-tmb for now, but it still needs
the versioned dependency added.  Is this something that dh-r could do?
  We also need to find other affected packages.

The actual warning message is generated by r-base, is there a way to
make this an error instead of a warning?

Regards
Graham


[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=980809#14

Bug#980901: python-scrapy: FTBFS in pbuilder without --use-network=yes due to tests in test_command_check.py

[Paul Wise]

Source: python-scrapy
Version: 2.4.1-1
Severity: important

When I rebuild python-scrapy in pbuilder, I get a FTBFS due to the
tests in tests/test_command_check.py failing unless I enable the use of
the network using the --use-network=yes option.

I had difficulty capturing the packets sent by the test suite, so I'm
not able to provide any information about the network access but from
the summary below and the attached full build log it seems like the
test suite is doing some DNS requests that are failing:

   ...
   tests/test_command_check.py FF   [  
0%]
   ...
   === short test summary info 

   FAILED tests/test_command_check.py::CheckCommandTest::test_SCRAPY_CHECK_set
   FAILED 
tests/test_command_check.py::CheckCommandTest::test_check_all_default_contracts
   FAILED 
tests/test_command_check.py::CheckCommandTest::test_check_cb_kwargs_contract
   FAILED 
tests/test_command_check.py::CheckCommandTest::test_check_returns_items_contract
   FAILED 
tests/test_command_check.py::CheckCommandTest::test_check_returns_requests_contract
   FAILED 
tests/test_command_check.py::CheckCommandTest::test_check_scrapes_contract
   ...
   === FAILURES 
===
    CheckCommandTest.test_SCRAPY_CHECK_set 

   
   self = 
   
   def test_SCRAPY_CHECK_set(self):
   parse_def = """
   import os
   if not os.environ.get('SCRAPY_CHECK'):
   raise Exception('SCRAPY_CHECK not set')
   """
   >   self._test_contract(parse_def=parse_def)
   
   
/build/python-scrapy-2.4.1/.pybuild/cpython3_3.9_scrapy/build/tests/test_command_check.py:97:
 
   _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
_ _ 
   
/build/python-scrapy-2.4.1/.pybuild/cpython3_3.9_scrapy/build/tests/test_command_check.py:36:
 in _test_contract
   self.assertIn('OK', err)
   _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
_ _ 
   
   self = 
   containee = 'OK'
   container = 
'E\n==\nERROR:
 [check_spider] parse 
(errback)\n---...\nRan
 0 contracts in 0.223s\n\nFAILED (errors=1)\n'
   msg = None
   
   def assertIn(self, containee, container, msg=None):
   """
   Fail the test if C{containee} is not found in C{container}.
   
   @param containee: the value that should be in C{container}
   @param container: a sequence type, or in the case of a mapping type,
 will follow semantics of 'if key in dict.keys()'
   @param msg: if msg is None, then the failure message will be
   '%r not in %r' % (first, second)
   """
   if containee not in container:
   >   raise self.failureException(msg or "%r not in %r"
   % (containee, container))
   E   twisted.trial.unittest.FailTest: 'OK' not in 
'E\n==\nERROR:
 [check_spider] parse 
(errback)\n--\nTraceback
 (most recent call last):\n  File 
"/usr/lib/python3/dist-packages/twisted/internet/defer.py", line 1416, in 
_inlineCallbacks\nresult = result.throwExceptionIntoGenerator(g)\n  File 
"/usr/lib/python3/dist-packages/twisted/python/failure.py", line 512, in 
throwExceptionIntoGenerator\nreturn g.throw(self.type, self.value, 
self.tb)\n  File 
"/build/python-scrapy-2.4.1/.pybuild/cpython3_3.9_scrapy/build/scrapy/core/downloader/middleware.py",
 line 45, in process_request\nreturn (yield download_func(request=request, 
spider=spider))\n  File 
"/usr/lib/python3/dist-packages/twisted/internet/defer.py", line 654, in 
_runCallbacks\ncurrent.result = callback(current.result, *args, **kw)\n  
File "/usr/lib/python3/dist-packages/twisted/internet/endpoints.py", line 981, 
in startConnectionAttempts\nraise 
error.DNSLookupError(\ntwisted.internet.error.DNSLookupError: DNS lookup 
failed: no results for hostname lookup: 
example.com.\n\n--\nRan
 0 contracts in 0.223s\n\nFAILED (errors=1)\n'
   
   /usr/lib/python3/dist-packages/twisted/trial/_synctest.py:493: FailTest
   __ CheckCommandTest.test_check_all_default_contracts 
___
   
   self = 
   
   def test_check_all_default_contracts(self):
   contracts = """
   @returns items 1
   @returns requests 1
   @scrapes key1 key2
   @cb_kwargs {"arg1": "val1", "arg2": "val2"}
   """
   parse_def = """
   yield {'key1': 'val1', 'key2': 'val2'}
   yield 

Bug#980893: [PATCH] Support SCRAM-SHA-1 etc via libgsasl

[Simon Josefsson]

Package: exim4
Tags: patch

Hi!

The patch below links exim4-daemon-heavy to libgsasl to enable the
'gsasl' authenticator support in exim, see:

https://exim.org/exim-html-current/doc/html/spec_html/ch-the_gsasl_authenticator.html

This makes it possible to enable SCRAM-SHA-1 and SCRAM-SHA-256 in Exim
via libgsasl.

Any chance this could make it into bullseye?  Thanks :)

I have done some testing using a minimal gsasl driver, and it seems to
work.  Configuration on the server side:

root@sid:/etc/exim4# cat conf.d/auth/50-sid
gsasl:
  driver = gsasl
  public_name = SCRAM-SHA-1
  server_password = foo
  server_set_id = ${quote:$auth1}
  server_condition = yes
root@sid:/etc/exim4# 

Client side works:

jas@latte:~$ LANG=C gsasl x.y.z.q 587 --no-starttls --mechanism SCRAM-SHA-1 -a 
jas --password foo -d
Trying 'x.y.z.q'...
220 sid ESMTP Exim 4.94 Sat, 23 Jan 2021 22:20:48 +
EHLO [127.0.0.1]
250-sid Hello ...
250-SIZE 52428800
250-8BITMIME
250-PIPELINING
250-PIPE_CONNECT
250-AUTH SCRAM-SHA-1
250-CHUNKING
250-STARTTLS
250-PRDR
250 HELP
AUTH SCRAM-SHA-1
334 
biwsbj1qYXMscj1oOEh0TmFxci9UclA4eDlrbHlOeFhQTWc=
334 
cj1oOEh0TmFxci9UclA4eDlrbHlOeFhQTWdPYkNqUnQ2OFU1Y0pJblR5ZWtyam12aVEscz15QnU1N3JNN3RwenFlNUpiLGk9NDA5Ng==
Yz1iaXdzLHI9aDhIdE5hcXIvVHJQOHg5a2x5TnhYUE1nT2JDalJ0NjhVNWNKSW5UeWVrcmptdmlRLHA9V1hVWGliY05tYTVZMk9UVExqQnlmWUNJT1NVPQ==
334 dj1pNkgzeW9IWWhVTXJxdERYd3VPaURYM0t6T2s9

235 Authentication succeeded
Client authentication finished (server trusted)...
Session finished...
QUIT
221 sid closing connection
jas@latte:~$ 

/Simon
diff --git a/debian/EDITME.exim4-heavy.diff b/debian/EDITME.exim4-heavy.diff
index b95c091d..d9943647 100644
--- a/debian/EDITME.exim4-heavy.diff
+++ b/debian/EDITME.exim4-heavy.diff
@@ -76,7 +76,7 @@
  
  # If you have content scanning you may wish to only include some of the scanner
  # interfaces.  Uncomment any of these lines to remove that code.
-@@ -757,8 +760,8 @@
+@@ -757,9 +760,9 @@
  # configuration to make use of the mechanism(s) selected.
  
  AUTH_CRAM_MD5=yes
@@ -85,8 +85,10 @@
 +AUTH_CYRUS_SASL=yes
 +AUTH_DOVECOT=yes
  # AUTH_EXTERNAL=yes
- # AUTH_GSASL=yes
+-# AUTH_GSASL=yes
++AUTH_GSASL=yes
  # AUTH_GSASL_PC=libgsasl
+ # AUTH_HEIMDAL_GSSAPI=yes
 @@ -766,8 +769,8 @@
  # AUTH_HEIMDAL_GSSAPI_PC=heimdal-gssapi
  # AUTH_HEIMDAL_GSSAPI_PC=heimdal-gssapi heimdal-krb5
@@ -103,7 +105,7 @@
  # Ditto for AUTH_HEIMDAL_GSSAPI(_PC).
  
 -# AUTH_LIBS=-lsasl2
-+AUTH_LIBS=-lsasl2
++AUTH_LIBS=-lsasl2 -lgsasl
  # AUTH_LIBS=-lgsasl
  # AUTH_LIBS=-lgssapi -lheimntlm -lkrb5 -lhx509 -lcom_err -lhcrypto -lasn1 -lwind -lroken -lcrypt
  
diff --git a/debian/changelog b/debian/changelog
index fa073995..681abcbd 100644
diff --git a/debian/control b/debian/control
index 31390e45..5ef32e4a 100644
--- a/debian/control
+++ b/debian/control
@@ -17,6 +17,7 @@ Build-Depends:
  docbook-xsl,
  libdb5.3-dev,
  libgnutls28-dev (>= 3.5.7),
+ libgsasl7-dev,
  libident-dev,
  libidn11-dev,
  libidn2-dev,


signature.asc
Description: PGP signature

Bug#979066: mangohud: Build fails on buster

[Stephan Lachnit]

Control: tags -1 wontfix buster

Thanks for reporting this, and thanks Stephen for looking into it.
I won't fix this since I never planned to support buster with this
package, especially since bullseye is just around the corner. If
the Vulkan backport works, that's nice, but please don't file bugs
regarding buster support, I won't test if it works on buster.

Regards,
Stephan Lachnit

Bug#980900: debian/watch doesn't find upstream releases

[John Scott]

Source: graphviz
Version: 2.42.2-4
Severity: minor
Tags: patch

It seems GitLab keeps changing their URLs around, and that they're apparently
notorious for this according to the wiki. Here's a solution that uses the
Quality Assurance team's redirector service, which uses the GitLab API and is
sure to be much more reliable:
version=4
https://qa.debian.org/cgi-bin/fakeupstream.cgi?upstream=gitlab_releases/graphviz/graphviz
 \
 .*/@PACKAGE@@ANY_VERSION@@ARCHIVE_EXT@

This detects version 2.46.0 correctly.

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

Kernel: Linux 5.10.0-1-amd64 (SMP w/2 CPU threads)
Kernel taint flags: TAINT_USER, TAINT_FIRMWARE_WORKAROUND
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

-- no debconf information


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

Bug#980777: FIT-PC: Fails to find driver for Ethernet, Realtek Semiconductor Co., Ltd. RTL-8100/8101L/8139 PCI

[Charles Curley]

On Sat, 23 Jan 2021 20:07:22 +
"Andrew M.A. Cater"  wrote:

> > > 8.6 is old - I'd be surprised that 10.7 firmware iso wouldn't
> > > work.  
> > 
> > I didn't try 10.x. 8.6 was what I had handy, i.e. it came up first
> > in the midden. However, debian-10.4.0-i386-netinst.iso also fails
> > to detect the NIC and gives the shortened menu of drivers to try.
> > 
> > -- 
> > Does anybody read signatures any more?
> > 
> > https://charlescurley.com
> > https://charlescurley.com/blog/  
> 
> Firmware-linux-free is usually installed by default. I would
> sincerely suggest that you try 10.7 unless you want to wait until
> 10.8 comes out (scheduled for the weekend of 6th February 2021.
> 
> I think you just hit a problematic install - I've had laptops with
> that particular Realtek Ethernet and they're normally just found.
> 
> All best, as ever,
> 
> Andy C.

I tried 10.7. Same problem.

This time I am attaching the syslog to this email.

I then did a search on the syslog, and got this:

root@hawk:/media/disk# grep 8139 syslog 
Jan 23 23:11:36 kernel: [0.416093] pci :00:0d.0: [10ec:8139] type 00 
class 0x02
Jan 23 23:11:36 kernel: [0.416722] pci :00:0e.0: [10ec:8139] type 00 
class 0x02
Jan 23 23:11:36 kernel: [   22.813925] usb 1-1.2: Product: DataTraveler 2.0
root@hawk:/media/disk# 

On another FIT-PC which is running Bullseye:

root@white:/var/log/apt# dmesg | grep 8139
[   10.897167] pci :00:0d.0: [10ec:8139] type 00 class 0x02
[   10.898147] pci :00:0e.0: [10ec:8139] type 00 class 0x02
[   44.971388] 8139cp: 8139cp: 10/100 PCI Ethernet driver v1.3 (Mar 22, 2004)
[   44.979230] 8139cp :00:0d.0: This (id 10ec:8139 rev 10) is not an 8139C+ 
compatible chip, use 8139too
[   45.141373] 8139cp :00:0e.0: This (id 10ec:8139 rev 10) is not an 8139C+ 
compatible chip, use 8139too
[   45.438841] 8139too: 8139too Fast Ethernet driver 0.9.28
[   45.534101] 8139too :00:0d.0 eth0: RealTek RTL8139 at 0xccfc2a96, 
00:01:c0:03:f4:11, IRQ 10
[   45.729725] 8139too :00:0e.0 eth1: RealTek RTL8139 at 0x2e6d8dc8, 
00:01:c0:03:d8:78, IRQ 5
[   48.858651] 8139too :00:0e.0 enp0s14: renamed from eth1
[   48.960869] 8139too :00:0d.0 enp0s13: renamed from eth0
[   56.400301] 8139too :00:0d.0 enp0s13: link up, 100Mbps, full-duplex, lpa 
0xC5E1
root@white:/var/log/apt# 

Considerably different.




-- 
Does anybody read signatures any more?

https://charlescurley.com
https://charlescurley.com/blog/


syslog
Description: Binary data

Bug#968181: 968181 and 968188 are fixed in 5.10.5-1,Re: Bug#968181: 968181 and 968188 are fixed in 5.10.5-1

[Ryutaroh Matsumoto]

> Indeed, CONFIG_DRM_VC4=m has been mistakenly removed from the arm64 kernel
> configuration. I’ll propose a merge request to fix this.
> 
> Cheers,
> Vincent

Thank you. I though that the kernel team decided to suspend vc4.ko,
because of the garbled unreadable screen as reported at
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=980785
originally found by Lucas.

Best regards, Ryutaroh

Bug#980886: [PATCH] Allow configuration of "dkim_timestamps" using new "DKIM_TIMESTAMPS"

[Simon Josefsson]

Package: exim4
Tags: patch

Hi!  The following patch allows me to configure the 'dkim_timestamps'
setting, which according to RFC 6376 is something you are RECOMMENDED to
set, see Exim4 manual (search for 'dkim_timestamps'):

https://exim.org/exim-html-current/doc/html/spec_html/ch-dkim_spf_and_dmarc.html

I tested it with exim4 on Debian stable by editing the installed
configuration file in the same way as my patch, and confirming that the
sent e-mail contains the 't' and 'x' DKIM parameters (in fact, this
e-mail should be an example of that unless I made a temporary
configuration mistake while sending this).

Thanks,
/Simon
From 90a1e015a2d35c81a61528181a0a58ee3c614759 Mon Sep 17 00:00:00 2001
From: Simon Josefsson 
Date: Sat, 23 Jan 2021 20:55:18 +0100
Subject: [PATCH] Add DKIM_TIMESTAMPS.

---
 debian/debconf/conf.d/transport/30_exim4-config_remote_smtp | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/debian/debconf/conf.d/transport/30_exim4-config_remote_smtp b/debian/debconf/conf.d/transport/30_exim4-config_remote_smtp
index c36ca055..f9b3a3ae 100644
--- a/debian/debconf/conf.d/transport/30_exim4-config_remote_smtp
+++ b/debian/debconf/conf.d/transport/30_exim4-config_remote_smtp
@@ -45,6 +45,9 @@ dkim_strict = DKIM_STRICT
 .ifdef DKIM_SIGN_HEADERS
 dkim_sign_headers = DKIM_SIGN_HEADERS
 .endif
+.ifdef DKIM_TIMESTAMPS
+dkim_timestamps = DKIM_TIMESTAMPS
+.endif
 .ifdef TLS_DH_MIN_BITS
 tls_dh_min_bits = TLS_DH_MIN_BITS
 .endif
-- 
2.20.1



signature.asc
Description: PGP signature

Bug#919320: RE: Bug#919320: nginx-extras: Would you please consider replacing Gzip module with Brotli for compression?

[Adrien CLERC]

On Tue, 30 Jun 2020 15:47:06 -0400 Thomas Ward  
wrote:


> Notes: rejected downstream in Ubuntu for Security concerns (BREACH, etc.)

OK, but having brotli_static can be really useful for pre-compressed 
assets. And for now, there is no solution in the packaged version :/


Adrien

Bug#980777: FIT-PC: Fails to find driver for Ethernet, Realtek Semiconductor Co., Ltd. RTL-8100/8101L/8139 PCI

[Charles Curley]

On Sat, 23 Jan 2021 17:53:30 +
"Andrew M.A. Cater"  wrote:

> > 
> > * The NIC finding software failed to detect the two NICs. This has
> >   worked in the past.
> >   
> You'll likely need the firmware .iso including the non-free firmwares
> - though I'm surprised that itr doesn't find the Ethernet devices,
> they're common.
> 

I don't think I need any firmware. On the working boxes, the only
firmware package present is firmware-linux-free, which does not include
any Realtek firmware. I don't know why it is present; it has nothing
depending on it. It was installed with the kernel.

firmware-realtek is absent from working boxes, and in any case does not
include firmware for these devices.

00:0d.0 Ethernet controller: Realtek Semiconductor Co., Ltd.
RTL-8100/8101L/8139 PCI Fast Ethernet Adapter (rev 10)

> > 
> > The first two problems are not new. I got the same with a Buster
> > 10.4 netinst CD. I then fell back to a Debian 8.6 netinst CD. That
> > correctly found and set up the two NICs.
> >   
> 8.6 is old - I'd be surprised that 10.7 firmware iso wouldn't work.

I didn't try 10.x. 8.6 was what I had handy, i.e. it came up first in
the midden. However, debian-10.4.0-i386-netinst.iso also fails to detect
the NIC and gives the shortened menu of drivers to try.

-- 
Does anybody read signatures any more?

https://charlescurley.com
https://charlescurley.com/blog/

Bug#980746: remove ath9k_htc, provided by libre package firmware-ath9k-htc

[John Scott]

Control: tags -1 patch

> Please provide a proper patch for firmware-nonfree to replace the
> currently included firmware with a dependency.
I couldn't figure out how to add a Recommends or a dependency; that templates 
are used to generate the control file seems to limit this. In any case I've 
sent an MR for firmware-linux-free to get the Recommends and would appreciate 
review of that.

Here's a patch for the removal from non-free firmware-atheros.diff -ru firmware-nonfree.orig/debian/changelog firmware-nonfree/debian/changelog
--- firmware-nonfree.orig/debian/changelog	2021-01-23 16:38:33.213649952 -0500
+++ firmware-nonfree/debian/changelog	2021-01-23 16:37:43.522844686 -0500
@@ -1,5 +1,10 @@
 firmware-nonfree (20201218-3) UNRELEASED; urgency=medium
 
+  [ John Scott ]
+  * Remove the ath9k_htc firmware which is superceded by the free
+firmware-ath9k-htc package.
+
+  [ maximilian attems ]
   * Add Realtek rtl8822cu config (closes: #971791)
   * Add Realtek RTL8812 firmwares (closes: #877667)
   * Add Realtek rtl8822cs config
diff -ru firmware-nonfree.orig/debian/config/atheros/copyright firmware-nonfree/debian/config/atheros/copyright
--- firmware-nonfree.orig/debian/config/atheros/copyright	2021-01-23 16:38:33.217650180 -0500
+++ firmware-nonfree/debian/config/atheros/copyright	2021-01-23 16:27:08.961488347 -0500
@@ -45,121 +45,6 @@
  TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE
  USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
 
-Files: ath9k_htc/htc_7010-1.4.0.fw, ath9k_htc/htc_9271-1.4.0.fw
-Copyright: 1998-2002, Red Hat, Inc.
-   2002, Gary Thomas
-   2002-2005, Sam Leffler, Errno Consulting
-   2002-2013, Qualcomm Atheros, Inc.
-   2013, Tensilica Inc.
-License: Open-ath9k-HTC-firmware
- All rights reserved.
- .
- Redistribution and use in source and binary forms, with or without
- modification, are permitted (subject to the limitations in the
- disclaimer below) provided that the following conditions are met:
- .
-  * Redistributions of source code must retain the above copyright
-notice, this list of conditions and the following disclaimer.
- .
-  * Redistributions in binary form must reproduce the above copyright
-notice, this list of conditions and the following disclaimer in the
-documentation and/or other materials provided with the
-distribution.
- .
-  * Neither the name of Qualcomm Atheros nor the names of its
-contributors may be used to endorse or promote products derived
-from this software without specific prior written permission.
- .
- NO EXPRESS OR IMPLIED LICENSES TO ANY PARTY'S PATENT RIGHTS ARE
- GRANTED BY THIS LICENSE.  THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT
- HOLDERS AND CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED
- WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
- MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
- DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE
- LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
- CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
- SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR
- BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY,
- WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE
- OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN
- IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
- .
- Permission to use, copy, modify, and/or distribute this software for any
- purpose with or without fee is hereby granted, provided that the above
- copyright notice and this permission notice appear in all copies.
- .
- THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES
- WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
- MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR
- ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
- WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
- ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF
- OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
- .
- Redistribution and use in source and binary forms are permitted
- provided that the following conditions are met:
- 1. The materials contained herein are unmodified and are used
-unmodified.
- 2. Redistributions of source code must retain the above copyright
-notice, this list of conditions and the following NO
-''WARRANTY'' disclaimer below (''Disclaimer''), without
-modification.
- 3. Redistributions in binary form must reproduce at minimum a
-disclaimer similar to the Disclaimer below and any redistribution
-must be conditioned upon including a substantially similar
-Disclaimer requirement for further binary redistribution.
- 4. Neither the names of the above-listed copyright holders nor the
-names of any contributors may be used to 

Bug#980899: php-illuminate-database: CVE-2021-21263 Query Binding Exploitation

[David Prévot]

Package: php-illuminate-database
Version: 5.7.27-1
Severity: important
Tags: security upstream
X-Debbugs-Cc: Robin Gustafsson , Debian Security Team 


Hi,

A quick look at the php-illuminate-database code, as shipped in stable,
makes me think that it is probably vulnerable to CVE-2021-21263 as fixed
in 6.20.11 (and its follow up in 6.20.14 since the initial fix was
incomplete) already fixed in Debian testing via php-laravel-framework
source.

Regards

David


signature.asc
Description: PGP signature

Bug#688228: python-gi: Add README.Debian explaining how to get information on the python bindings

[Stephan Lachnit]

Just reading through this issues, and this seems to be fixed a while ago.

1. The documentation for PyGObject is available now [1].
2. Gtk bindings are now in a separate package, e.g. gir1.2-gtk-3.0

I think this can be closed by now.

Regards,
Stephan Lachnit

[1] https://lazka.github.io/pgi-docs/

Bug#957317: gtkboard: diff for NMU version 0.11pre0+cvs.2003.11.02-10.1

[Sudip Mukherjee]

On Sat, Jan 23, 2021 at 4:50 PM Barak A. Pearlmutter
 wrote:
>
> Turns out I'd already uploaded a -11, but pristine-tar messed up and
> so the hash was wrong so it was rejected.
> Anyway I just re-uploaded that. So the -10.1 will disappear anyway.
> I think it has the same fix you had, if can put it in -12.

I have cancelled the NMU. And, just fyi, you have not closed this bug
in your changelog.


-- 
Regards
Sudip

Bug#980898: elogind: reduce Build-Depends

[Helmut Grohne]

Source: elogind
Version: 246.9.1-1+debian1
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap

elogind participates in dependency loops relevant to architecture
bootstrap. Instead of looking into such a difficult problem, I looked
for easily droppable dependencies:
 * libblkid-dev and libmount-dev are mentioned in multiple meson files
   as not needed by elogind. They can be dropped with no replacement.
 * dbus and libglib2.0-dev are used in unit tests only. They can be
   annotated .

Please consider applying the attached patch.

Helmut
diff --minimal -Nru elogind-246.9.1/debian/changelog 
elogind-246.9.1/debian/changelog
--- elogind-246.9.1/debian/changelog2020-12-22 17:53:57.0 +0100
+++ elogind-246.9.1/debian/changelog2021-01-23 19:03:38.0 +0100
@@ -1,3 +1,12 @@
+elogind (246.9.1-1+debian1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Reduce Build-Depends: (Closes: #-1)
++ libblkid-dev and libmount-dev are unused.
++ dbus and libglib2.0-dev are only used for tests. Mark .
+
+ -- Helmut Grohne   Sat, 23 Jan 2021 19:03:38 +0100
+
 elogind (246.9.1-1+debian1) unstable; urgency=medium
 
   * New upstream version 246.9.1
diff --minimal -Nru elogind-246.9.1/debian/control 
elogind-246.9.1/debian/control
--- elogind-246.9.1/debian/control  2020-12-22 17:53:57.0 +0100
+++ elogind-246.9.1/debian/control  2021-01-23 19:03:38.0 +0100
@@ -21,12 +21,11 @@
libudev-dev,
libmount-dev (>= 2.27.1),
libseccomp-dev (>= 2.3.1) [amd64 arm64 armel armhf i386 mips 
mipsel mips64 mips64el x32 powerpc ppc64 ppc64el s390x],
-   libblkid-dev (>= 2.24),
libpam0g-dev (>= 1.1.2),
libacl1-dev,
libselinux1-dev,
-   libglib2.0-dev,
-   dbus (>= 1.9.14)
+   libglib2.0-dev ,
+   dbus (>= 1.9.14) ,
 
 Package: elogind
 Section: admin

Bug#980897: sphinxbase: drop unused Build-Depends

[Helmut Grohne]

Source: sphinxbase
Version: 0.8+5prealpha+1-12
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap

sphinxbase participates in a number of dependency loops relevant to
architecture bootstrap. Rather than look into such a difficult problem,
I looked into easily droppable dependencies. It turns out that the
dependencies on libsamplerate-dev and libsndfile1-dev are entirely
unused. While libsndfile is mentioned in the changelog for 0.7, neither
of them is mentioned in the source anywhere. I think both can be dropped
with no replacement. Please consider applying the attached patch.

Helmut
diff --minimal -Nru sphinxbase-0.8+5prealpha+1/debian/changelog 
sphinxbase-0.8+5prealpha+1/debian/changelog
--- sphinxbase-0.8+5prealpha+1/debian/changelog 2021-01-02 16:13:23.0 
+0100
+++ sphinxbase-0.8+5prealpha+1/debian/changelog 2021-01-23 23:30:17.0 
+0100
@@ -1,3 +1,11 @@
+sphinxbase (0.8+5prealpha+1-12.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Drop unused libsamplerate-dev and libsndfile1-dev dependencies.
+(Closes: #-1)
+
+ -- Helmut Grohne   Sat, 23 Jan 2021 23:30:17 +0100
+
 sphinxbase (0.8+5prealpha+1-12) unstable; urgency=medium
 
   * Bump debhelper from 10 to 12.
diff --minimal -Nru sphinxbase-0.8+5prealpha+1/debian/control 
sphinxbase-0.8+5prealpha+1/debian/control
--- sphinxbase-0.8+5prealpha+1/debian/control   2020-11-01 01:16:57.0 
+0100
+++ sphinxbase-0.8+5prealpha+1/debian/control   2021-01-23 23:30:17.0 
+0100
@@ -3,7 +3,7 @@
 Maintainer: Debian Accessibility Team 
 Uploaders: Samuel Thibault 
 Build-Depends: debhelper-compat (= 12), bison, pkg-config,
- libpulse-dev, libsndfile1-dev, libsamplerate0-dev, libblas-dev, liblapack-dev,
+ libpulse-dev, libblas-dev, liblapack-dev,
  doxygen, python3-all-dev, dh-python, swig, libjs-jquery,
  strace [linux-any], ltrace [amd64 i386 mipsel s390x powerpc ppc64]
 Build-Conflicts: libjack-dev

Bug#980896: bluez: reduce Build-Depends

[Helmut Grohne]

Source: bluez
Version: 5.55-3
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap

bluez participates in dependency loops relevant to architecture
bootstrap. Instead of looking into such a difficult problem, I looked
for easily droppable dependencies. I found that check is only used for
tests and can be annotated . libcap-ng-dev was formerly used
for --enable-capng, but that option is no longer enabled nor available.
It can be dropped with no replacement. Please consider applying the
attached patch.

Helmut
diff --minimal -Nru bluez-5.55/debian/changelog bluez-5.55/debian/changelog
--- bluez-5.55/debian/changelog 2021-01-02 07:57:41.0 +0100
+++ bluez-5.55/debian/changelog 2021-01-23 19:13:21.0 +0100
@@ -1,3 +1,12 @@
+bluez (5.55-3.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Reduce Build-Depends: (Closes: #-1)
++ Annotate check with .
++ libcap-ng-dev is no longer used. We no longer pass --enable-capng.
+
+ -- Helmut Grohne   Sat, 23 Jan 2021 19:13:21 +0100
+
 bluez (5.55-3) unstable; urgency=medium
 
   * Add d/salsa-ci.yml.
diff --minimal -Nru bluez-5.55/debian/control bluez-5.55/debian/control
--- bluez-5.55/debian/control   2021-01-02 07:57:41.0 +0100
+++ bluez-5.55/debian/control   2021-01-23 19:13:09.0 +0100
@@ -8,7 +8,6 @@
bison,
libdbus-1-dev (>= 1.6),
libglib2.0-dev,
-   libcap-ng-dev,
   libdw-dev,
libudev-dev,
libreadline-dev,
@@ -17,7 +16,7 @@
libell-dev (>= 0.28),
libjson-c-dev (>= 0.13),
udev,
-   check,
+   check ,
systemd
 Standards-Version: 4.5.1
 Rules-Requires-Root: no

Bug#980895: zsh: reduce Build-Depends

[Helmut Grohne]

Source: zsh
Version: 5.8-5
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: cross-satisfiability

zsh cannot be cross built from source, because its cross Build-Depends
are unsatisfiable. Instead of looking into such a difficult problem, I
looked into easily droppable dependencies. It turns out that zsh only
builds the pdf documentation during an indep (or full) build. Therefore
the texlive and related dependencies can be demoted to
Build-Depends-Indep. Please consider applying the attached patch.

Helmut
diff --minimal -Nru zsh-5.8/debian/changelog zsh-5.8/debian/changelog
--- zsh-5.8/debian/changelog2020-06-30 17:42:41.0 +0200
+++ zsh-5.8/debian/changelog2021-01-23 23:19:56.0 +0100
@@ -1,3 +1,10 @@
+zsh (5.8-5.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Demote documentation dependencies to B-D-I. (Closes: #-1)
+
+ -- Helmut Grohne   Sat, 23 Jan 2021 23:19:56 +0100
+
 zsh (5.8-5) unstable; urgency=medium
 
   [ Axel Beckert ]
diff --minimal -Nru zsh-5.8/debian/control zsh-5.8/debian/control
--- zsh-5.8/debian/control  2020-06-30 12:53:08.0 +0200
+++ zsh-5.8/debian/control  2021-01-23 23:19:29.0 +0100
@@ -2,10 +2,8 @@
 Section: shells
 Priority: optional
 Build-Depends: bsdextrautils | bsdmainutils (<< 12~),
-   cm-super-minimal,
debhelper-compat (= 13),
dpkg-dev (>= 1.16.2~),
-   ghostscript,
groff,
groff-base,
libcap-dev [linux-any],
@@ -13,6 +11,9 @@
libgdbm-dev,
libncursesw5-dev,
libpcre3-dev,
+Build-Depends-Indep:
+   cm-super-minimal,
+   ghostscript,
texinfo (>= 5~),
texlive-fonts-recommended,
texlive-latex-base,

Bug#704180: Att

[Charles Alexander]

I'm Charles Alexander,  I'm from United State of America, I have very urgent business proposal that worth $ of big amount USD, please contact me to talk more better, Thanks
 
 Faithful,Mr Charles Alexander,ABSA Bank Plc.

Bug#980894: The single quote char (ASCII 39) is rendered as UTF apostrophe in roff

[Sergio de Almeida Cipriano Junior]

Package: ronn
Version: 0.9.1-1
Severity: minor
Tags: patch
X-Debbugs-Cc: sergios...@hotmail.com.br

Ronn translates single quote chars (this ') into apostrophe (this ´).

This bug is described at (https://github.com/apjanke/ronn-ng/issues/55).

The upstream has already resolved this bug at
(https://github.com/apjanke/ronn-ng/pull/58).

This is tentatively scheduled to go out in Ronn-NG 0.10.0, I suggest
cherry picking upstream commits and creating a patch for now.

Bug#961238: python3-gi: update to a version with better GTK 4 support

[Stephan Lachnit]

How about doing this now? Gtk4 is stable now, so there won't be major changes.

A git snapshot of pygobject in experimental would be nice for people to start 
migrating or at least test Gtk4.

Regards,
Stephan Lachnit

Bug#980039: More information, again....

[James Valleroy]

Hello Christian,

Could you please check if apt is configured to install recommended packages on 
your system?

You can run this command:

$ apt-config dump | grep Install-Recommends
APT::Install-Recommends "1";



OpenPGP_signature
Description: OpenPGP digital signature

Bug#946262: dochelp: Fatal error: out of memory

[Mehdi Dogguy]

On Sat, Jan 23, 2021 at 09:07:13PM +0100, Mehdi Dogguy  wrote:
> I wasn't able to reproduce this bug. Are you able to identify which
> package specifically made dochelp crash? It would help a lot to debug
> it.
>

FWIW, I've just uploaded dochelp 0.1.8 with a couple of bugfixes (none
is related to memory management though). Can you maybe test it and
report back if you still have the issue?

Thanks,

-- 
Mehdi Dogguy

Bug#980892: civicrm-common: CVE-2021-21252 embedded copy of jquery.validate.js vulnerable to ReDoS

[David Prévot]

Package: civicrm-common
Severity: important
Tags: security
X-Debbugs-Cc: Debian Security Team 

Hi,

civicrm-common embeds a copy of jquery.validate.js that is vulnerable to
CVE-2021-21252 (has been fixed in version 1.19.3.


signature.asc
Description: PGP signature

Bug#980891: otrs2: CVE-2021-21252 embedded copy of jquery.validate.js vulnerable to ReDoS

[David Prévot]

Package: otrs2
Severity: important
Tags: security
X-Debbugs-Cc: Debian Security Team 

Hi,

otrs2 embeds a copy of jquery.validate.js that is vulnerable to
CVE-2021-21252 (has been fixed in version 1.19.3.

Regards

David


signature.asc
Description: PGP signature

Bug#980890: Replace with mailman-web

[Jonas Meurer]

Source: mailman-suite
Version: 0+20200530-1
Severity: normal

Hello,

we should replace the mailman-suite source package with mailman-web[1]

Cheers
 jonas

[1] https://gitlab.com/mailman/mailman-web/

Bug#980825: debian-policy: Historical sign off dates in d/changelog and "single digit" day of the month

[Niels Thykier]

Control: forcemerge -1 971977

Guillem Jover:
> Hi!
> 
> [...]
> 
> Isn't this report a duplicate of #971977?
> 
> (I clarified the other report in deb-changelog(5) with
> .)
> 
> Thanks,
> Guillem
> 

Seems like it.  Thanks for the heads up.

~Niels

Bug#968244: [Pkg-mailman-hackers] Bug#968244: mailman3-web: Crash with: /usr/share/mailman3-web/manage.py runjobs daily

[Jonas Meurer]

Control: tag -1 moreinfo

Hello Athanasius,

Am 11.08.20 um 16:45 schrieb Athanasius:

After installing mailman3 I used migrated old Mailman 2.1 lists in using
'import21' and then their archives using 'python manage.py
hyperkitty_import -l ...'.

All seems to have gone OK, but the daily mailman3-web job in
/etc/cron.d/mailman3-web:

@daily www-data [ -f /usr/bin/django-admin ] && flock -n 
/var/run/mailman3-web/cron.daily /usr/share/mailman3-web/manage.py runjobs daily

is throwing errors:

Traceback (most recent call last):
   File 
"/usr/lib/python3/dist-packages/django_extensions/management/commands/runjobs.py",
 line 36, in runjobs
 job().execute()
   File "/usr/lib/python3/dist-packages/hyperkitty/jobs/sync_mailman.py", line 
35, in execute
 sync_with_mailman()
   File "/usr/lib/python3/dist-packages/hyperkitty/lib/mailman.py", line 145, 
in sync_with_mailman
 sender.set_mailman_id()
   File "/usr/lib/python3/dist-packages/hyperkitty/models/sender.py", line 54, 
in set_mailman_id
 mm_user = client.get_user(self.address)
   File "/usr/lib/python3/dist-packages/mailmanclient/client.py", line 322, in 
get_user
 return User(self._connection, content['self_link'], content)
KeyError: 'self_link'
ERROR OCCURED IN DAILY JOB: sync_mailman (APP: hyperkitty)
START TRACEBACK:
END TRACEBACK

Adding a little debug output:

Address: #.pleasegivegenerou...@hotmail.com
Response: {'date': 'Tue, 11 Aug 2020 14:35:42 GMT', 'server': 'WSGIServer/0.2 
CPython/3.7.3', 'content-length': '712742', 'content-type': 'application/json; 
charset=UTF-8', 'status': '200', 'content-location': 
'http://river-nat:8001/3.0/users/#.pleasegivegenerou...@hotmail.com'}

And the 'content' at that point is *huge* (693KiB), indeed without a
'self_link' key at its top level, although it contains an 'entries'
array in which each member has a 'self_link' key.

This appears to be code to sync up hyperkitty's idea of senders with
actual members of the list, so is probably relatively harmless, but I
don't know if *subsequent* more important code is being prevented from
running.


Could you please try out whether this bug has been fixed with the latest 
updates to mailman3 and hyperkitty? A lot of changes happened to the 
'import21' code, so I'm hopeful that this bug might have been fixed in 
the meantime. Unfortunately I lack the time to build a reproducer myself.


Cheers
 jonas




OpenPGP_signature
Description: OpenPGP digital signature

Bug#971084: [Pkg-mailman-hackers] Bug#971084: /usr/share/mailman3-web/manage.py mmclient does not observe $PYTHONSTARTUP

[Jonas Meurer]

Control: tag -1 moreinfo

Hello monochromec,

Am 27.09.20 um 16:45 schrieb monochromec:

Upstream patch @ https://gitlab.com/mailman/mailman/-/issues/469 seems to be in
place but invoking mmclient as described still fails to observe
$PYTHONSTARTUP environment variable.

Happy to provide additional information - just let me know.


Can you please elaborate on what bug exactly you experience and how to 
reproduce it? I fail to understand what you're refering to ;)


Kind regards
 jonas




OpenPGP_signature
Description: OpenPGP digital signature

Bug#980889: RFP: binutils-sh-elf -- cross binary utilities for SuperH bare-metal systems

[John Scott]

Package: wnpp
Severity: wishlist
X-Debbugs-Cc: pkg-electronics-de...@alioth-lists.debian.net

* Package name:binutils-sh-elf
  Version : 2.35.1
  Upstream Author : GNU Project
* URL : https://www.gnu.org/software/binutils/
* License : GPL
  Programming Lang: C
  Description : cross binary utilities for SuperH bare-metal systems

This package would provide GNU Binutils suited for embedded targets, and
would be suited for both SH-1 and SH-2 hardware at least [1]. This is needed
to build carl9170, the libre wireless firmware for AR9170 devices that's
currently in firmware-linux-free. That will require GCC and Newlib as well.

I don't have time to commit to this now, but might in the distant future.
In that case, I might would package it with the electronics or even the
kernel team. If others would help get this package started, I could
try maintaining it after it's off the ground.

[1] https://gcc.gnu.org/pipermail/gcc-help/2021-January/139838.html

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

Bug#980888: packages.debian.org: No list of files for arch:all packages

[Christian Kastner]

Package: www.debian.org
Severity: normal

As Scott Talbert pointed out in [1], the "list of files" page for
arch:all packages in bullseye and above currently seems to be broken.
All pages list a yellow notification box with the content

"No such package in this suite on this architecture."

See [2, 3, 4] for random examples.

The pages seem fine for buster and below.

[1] https://lists.debian.org/debian-www/2021/01/msg00061.html

[2] https://packages.debian.org/sid/all/debhelper/filelist

[3] https://packages.debian.org/sid/python3-pytest

[4] https://packages.debian.org/sid/all/git-buildpackage/filelist

Best,
Christian

Bug#980887: apt: Ability to reference a version also by its major number (e.g. 10) and not only by its name (e.g. buster) in sources.list

[sim]

Package: apt
Version: 1.8.2
Severity: wishlist

Dear Maintainer,

It would be nict to have the ability to reference a Debian version also by its
major number (e.g. 10) and not only by its name (e.g. buster) in sources.list.

E.g. right now `/etc/apt/sources.list` looks like this:

deb http://deb.debian.org/debian/ buster main non-free contrib

It should be possible to use `10` instead of `buster`:

deb http://deb.debian.org/debian/ 10 main non-free contrib


For those who do not know/remember the chronological sequence of the version
names - numbers tell more. It's also allows for a more neutral style - as not
everybody might like things like `potato` or `etch`...

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

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

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



-- Package-specific info:

-- (no /etc/apt/preferences present) --


-- (no /etc/apt/preferences.d/* present) --


-- (/etc/apt/sources.list present, but not submitted) --


-- (/etc/apt/sources.list.d/signal-xenial.list present, but not submitted) --


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

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

Versions of packages apt depends on:
ii  adduser 3.118
ii  debian-archive-keyring  2019.1
ii  gpgv2.2.12-1+deb10u1
ii  libapt-pkg5.0   1.8.2
ii  libc6   2.28-10
ii  libgcc1 1:8.3.0-6
ii  libgnutls30 3.6.7-4
ii  libseccomp2 2.3.3-4
ii  libstdc++6  8.3.0-6

Versions of packages apt recommends:
ii  ca-certificates  20190110

Versions of packages apt suggests:
pn  apt-doc  
pn  aptitude | synaptic | wajig  
ii  dpkg-dev 1.19.7
ii  gnupg2.2.12-1+deb10u1
ii  powermgmt-base   1.34

-- no debconf information

Bug#980633: python-llfuse: FTBFS: dh_auto_test: error: pybuild --test -i python{version} -p 3.9 returned exit code 13

[Gianfranco Costamagna]

control: fixed -1 1.3.8+dfsg-2
control: close -1

closing!

G.

On Wed, 20 Jan 2021 21:39:24 +0100 Lucas Nussbaum  wrote:
> Source: python-llfuse
> Version: 1.3.6+dfsg-2
> Severity: serious
> Justification: FTBFS on amd64
> Tags: bullseye sid ftbfs
> Usertags: ftbfs-20210120 ftbfs-bullseye
> 
> Hi,
> 
> During a rebuild of all packages in sid, your package failed to build
> on amd64.
> 
> Relevant part (hopefully):
> > make[1]: Entering directory '/<>'
> > dh_testdir
> > python3 setup.py build_cython
> > running build_cython
> > Compiling /<>/src/llfuse.pyx
> > touch build_cython
> > dh_testdir
> > python3 setup.py build_ext --inplace
> > running build_ext
> > building 'llfuse' extension
> > creating build
> > creating build/temp.linux-x86_64-3.9
> > creating build/temp.linux-x86_64-3.9/src
> > x86_64-linux-gnu-gcc -pthread -Wno-unused-result -Wsign-compare -DNDEBUG -g 
> > -fwrapv -O2 -Wall -g -fstack-protector-strong -Wformat 
> > -Werror=format-security -g -fwrapv -O2 -g -O2 
> > -ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat 
> > -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -fPIC 
> > -I/usr/include/python3.9 -c src/llfuse.c -o 
> > build/temp.linux-x86_64-3.9/src/llfuse.o -D_FILE_OFFSET_BITS=64 
> > -I/usr/include/fuse -DFUSE_USE_VERSION=29 -Wall -Wextra -Wconversion 
> > -Wsign-compare -DLLFUSE_VERSION="1.3.6" -Wno-unused-function 
> > -Wno-implicit-fallthrough -Wno-unused-parameter
> > src/llfuse.c: In function ‘__pyx_f_6llfuse_session_loop_mt’:
> > src/llfuse.c:42419:3: warning: ‘PyEval_InitThreads’ is deprecated 
> > [-Wdeprecated-declarations]
> > 42419 |   PyEval_InitThreads();
> >   |   ^~
> > In file included from /usr/include/python3.9/Python.h:145,
> >  from src/llfuse.c:4:
> > /usr/include/python3.9/ceval.h:130:37: note: declared here
> >   130 | Py_DEPRECATED(3.9) PyAPI_FUNC(void) PyEval_InitThreads(void);
> >   | ^~
> > x86_64-linux-gnu-gcc -pthread -Wno-unused-result -Wsign-compare -DNDEBUG -g 
> > -fwrapv -O2 -Wall -g -fstack-protector-strong -Wformat 
> > -Werror=format-security -g -fwrapv -O2 -g -O2 
> > -ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat 
> > -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -fPIC 
> > -I/usr/include/python3.9 -c src/lock.c -o 
> > build/temp.linux-x86_64-3.9/src/lock.o -D_FILE_OFFSET_BITS=64 
> > -I/usr/include/fuse -DFUSE_USE_VERSION=29 -Wall -Wextra -Wconversion 
> > -Wsign-compare -DLLFUSE_VERSION="1.3.6" -Wno-unused-function 
> > -Wno-implicit-fallthrough -Wno-unused-parameter
> > creating build/lib.linux-x86_64-3.9
> > x86_64-linux-gnu-gcc -pthread -shared -Wl,-O1 -Wl,-Bsymbolic-functions 
> > -Wl,-z,relro -g -fwrapv -O2 -Wl,-z,relro -g -O2 
> > -ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat 
> > -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 
> > build/temp.linux-x86_64-3.9/src/llfuse.o 
> > build/temp.linux-x86_64-3.9/src/lock.o -o 
> > build/lib.linux-x86_64-3.9/llfuse.cpython-39-x86_64-linux-gnu.so -lfuse 
> > -pthread -lpthread -lrt
> > copying build/lib.linux-x86_64-3.9/llfuse.cpython-39-x86_64-linux-gnu.so -> 
> > src
> > python3 setup.py build_sphinx
> > running build_sphinx
> > Running Sphinx v3.4.3
> > making output directory... done
> > loading intersphinx inventory from ../debian/python.inv...
> > building [mo]: targets for 0 po files that are out of date
> > building [html]: targets for 12 source files that are out of date
> > updating environment: [new config] 12 added, 0 changed, 0 removed
> > reading sources... [  8%] about
> > reading sources... [ 16%] changes
> > reading sources... [ 25%] data
> > reading sources... [ 33%] example
> > reading sources... [ 41%] fuse_api
> > reading sources... [ 50%] general
> > reading sources... [ 58%] gotchas
> > reading sources... [ 66%] index
> > reading sources... [ 75%] install
> > reading sources... [ 83%] lock
> > reading sources... [ 91%] operations
> > reading sources... [100%] util

Bug#946262: dochelp: Fatal error: out of memory

[Mehdi Dogguy]

Hi Laurent,

Thanks for the bugreport and sorry for not replying earlier!

On Fri, Dec 06, 2019 at 12:22:14PM +0100, Laurent Bonnaud 
 wrote:
> E: /usr/share/doc-base/scalapack-slug: Field "format" is not allowed in 
> section Document
> E: /usr/share/doc-base/scalapack-pblasqref: Field "format" is not allowed in 
> section Document
> E: /usr/share/doc-base/scalapack-scalapackqref: Field "format" is not allowed 
> in section Document
> E: /usr/share/doc-base/scalapack-faq: Field "format" is not allowed in 
> section Document
> Fatal error: out of memory
> dpkg: error processing package dochelp (--configure):
>  installed dochelp package post-installation script subprocess returned error 
> exit status 2
> Errors were encountered while processing:
>  dochelp
>

I wasn't able to reproduce this bug. Are you able to identify which
package specifically made dochelp crash? It would help a lot to debug
it.

> It can be reproduced with this command:
> 
> # dochelp update
> E: /usr/share/doc-base/scalapack-slug: Field "format" is not allowed in 
> section Document
> E: /usr/share/doc-base/scalapack-pblasqref: Field "format" is not allowed in 
> section Document
> E: /usr/share/doc-base/scalapack-scalapackqref: Field "format" is not allowed 
> in section Document
> E: /usr/share/doc-base/scalapack-faq: Field "format" is not allowed in 
> section Document
> Fatal error: out of memory
> 
> This system has 4GB of RAM and 1GB of swap.
> 
> 
> -- 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.4.0-trunk-amd64 (SMP w/2 CPU cores)
> Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
> LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /usr/bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
> 
> Versions of packages dochelp depends on:
> ii  libc6 2.29-4
> ii  libjs-jquery  3.3.1~dfsg-3
> ii  libpcre3  2:8.39-12+b1
> 
> dochelp recommends no packages.
> 
> dochelp suggests no packages.
> 
> -- no debconf information
> 
> -- 
> Laurent.

-- 
Mehdi Dogguy

Bug#980726: Seeing this too

[Helge Kreutzmann]

Hello Axel,
On Sat, Jan 23, 2021 at 08:38:50PM +0100, Axel Beckert wrote:
> Control: tag -1 pending

Thanks.

> Hi Helge,
> 
> Helge Kreutzmann wrote:
> > I'm seeing this too. Since I regularly use the console (and hence gpm)
> > and I'm rebooting my desktop machine daily, this is quite annyoing.
> 
> I've got a working fix in a feature branch. I just still have to
> cross-check if it doesn't break other init systems as this was very
> fine-tuned before I added the .service file and now I had to remove
> some the fine-tuning. (Yeah, I'm once again annoyed by systemd. Can't
> that thing just work?!? I'd really prefer to just kick out that
> .service file again as it worked well before without. But I'm sure
> that will be controversial at minimum. If it breaks other init
> systems, I'll revert that adding of a .service file.)

Well, I'm not fond of systemd either, but in Debian we've got little
choice (except maybe for corner cases), so your effort is highly
appreciated.

And yes, on several systems gpm just worked in the past, even after
systemd was introduced.

Greetings

 Helge

-- 
  Dr. Helge Kreutzmann deb...@helgefjell.de
   Dipl.-Phys.   http://www.helgefjell.de/debian.php
64bit GNU powered gpg signed mail preferred
   Help keep free software "libre": http://www.ffii.de/


signature.asc
Description: PGP signature

Bug#968181: 968181 and 968188 are fixed in 5.10.5-1

[Vincent Blut]

Hi Ryutaroh,

Le 2021-01-24 04:21, Ryutaroh Matsumoto a écrit :
> Control: reopen 968181
> Control: reopen 968188
> Control: found 968181 5.10.9-1
> Control: found 968188 5.10.9-1
> 
>  968181 missing DRI/DRM support on Raspberry Pi
>  968188 4K display resolution is not recognized with Raspberry Pi 4B
> 
> Since gpu/drm/vc4.ko is disabled in 5.10.9-1 while it was enabled in 5.10.5-1,
> the above two issues have come back (I unwelcome them...).

Indeed, CONFIG_DRM_VC4=m has been mistakenly removed from the arm64 kernel
configuration. I’ll propose a merge request to fix this.

> Best regards, Ryutaroh Matsumoto

Cheers,
Vincent


signature.asc
Description: PGP signature

Bug#980726: Seeing this too

[Axel Beckert]

Control: tag -1 pending

Hi Helge,

Helge Kreutzmann wrote:
> I'm seeing this too. Since I regularly use the console (and hence gpm)
> and I'm rebooting my desktop machine daily, this is quite annyoing.

I've got a working fix in a feature branch. I just still have to
cross-check if it doesn't break other init systems as this was very
fine-tuned before I added the .service file and now I had to remove
some the fine-tuning. (Yeah, I'm once again annoyed by systemd. Can't
that thing just work?!? I'd really prefer to just kick out that
.service file again as it worked well before without. But I'm sure
that will be controversial at minimum. If it breaks other init
systems, I'll revert that adding of a .service file.)

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#980784: Fwd: Bug#980784: Acknowledgement (pp_dpm_mclk Always at Maximun gpu memory clock frecuency)

[Sergio Zamora]

Package: linux-image-5.10.0-1-amd64
Version: 5.10.4-1


* Additional Information I

Back and re installed *buster* and I can confirm the ' memory clock (mclk)
' works dynamically
and correctly using  ' linux-image-5.9.0-0.bpo.2-amd64 '

*0: 400Mhz *  ( buster on battery )*
1: 933Mhz
2: 1067Mhz
3: 1200Mhz

0: 400Mhz
1: 933Mhz
2: 1067Mhz
*3: 1200Mhz *  ( bullseye on battery )*

These causes any simple app as pdf reader or web browser run the fan
constantly and
quickly raise the temperature of the processor



** Additional Information II*

Bullseye radeontop output when just started the laptop.

1,20G / 1,20G Memory Clock 100,00% ( no apps opened )




** Additional Information III*

root@debian:~# cat /sys/kernel/debug/dri/0/amdgpu_pm_info
GFX Clocks and Power:
1200 MHz (MCLK)
200 MHz (SCLK)
700 MHz (PSTATE_SCLK)
933 MHz (PSTATE_MCLK)

GPU Temperature: 40 C

VCN: Disabled




Best Regards,



PS : Only tlp installed after getting all this information ( buster and
bullseye ).


-- Forwarded message -
De: Debian Bug Tracking System 
Date: vie, 22 de ene. de 2021 a la(s) 02:18
Subject: Bug#980784: Acknowledgement (pp_dpm_mclk Always at Maximun gpu
memory clock frecuency)
To: Sergio Zamora 


Thank you for filing a new Bug report with Debian.

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

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

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

Your message has been sent to the package maintainer(s):
 Debian Kernel Team 

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

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

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

Bug#980423: 3.12.4 makes several packages FTBFS

[Sebastian Ramacher]

Control: reassign -1 libphonenumber-dev 7.1.0-7

On 2021-01-20 23:04:15 +0100, Jochen Sprickerhof wrote:
> Hi,
> 
> * Sebastian Ramacher  [2021-01-20 22:20]:
> > On 2021-01-19 00:05:36 +0100, László Böszörményi wrote:
> > > On Mon, Jan 18, 2021 at 10:24 PM Laurent Bigonville  
> > > wrote:
> > > > Several packages FTBFS since 3.12.4
> > > >
> > > > The autopkgtest catched ignition-msgs and ignition-transport, see
> > > > https://packages.qa.debian.org/p/protobuf.html
> > > >
> > > > I can see that evolution-data-server also FTBFS
> > > [...]
> > > > This is a bit unfortunate that it's happening so late in the 
> > > > developpement cycle.
> > >  Indeed, my fault. Investigating. Hope this can be resolved easily.
> > 
> > The autopkgtest failures indicate that ignition-msgs' and
> > ignition-transport's dependencies on libprotobuf-dev (>= X.Y), (<
> > X.{Y+1}) is not enough. It will need to be (>= X.Y.Z), (< X.Y.{Z+1})
> > instead.
> 
> I guess an other option would be to depend on the new API definition:
> Package: libprotobuf-dev
> Provides: protobuf-api-23-0
> 
> @László: would you agree? (We discussed this in #963247 before).

If the API is bumped whenever the generated headers would become
incompatible, this should be fine.

In any case, the headers included in libphonenumber-dev have also been
generated against the new version of protobuf. So the remaining build
issues should be fixed. However, libphonenumber-dev's dependency on
libprotobuf-dev is not tight enough. Hence I'm reassigning this bug to
libphonenumber-dev to tighten the dependency.

Cheers
-- 
Sebastian Ramacher


signature.asc
Description: PGP signature

Bug#968181: 968181 and 968188 are fixed in 5.10.5-1

[Ryutaroh Matsumoto]

Control: reopen 968181
Control: reopen 968188
Control: found 968181 5.10.9-1
Control: found 968188 5.10.9-1

 968181 missing DRI/DRM support on Raspberry Pi
 968188 4K display resolution is not recognized with Raspberry Pi 4B

Since gpu/drm/vc4.ko is disabled in 5.10.9-1 while it was enabled in 5.10.5-1,
the above two issues have come back (I unwelcome them...).

Best regards, Ryutaroh Matsumoto

Bug#980885: manpages-es-extra: Suitable for Bullseye?

[Helge Kreutzmann]

Package: manpages-es-extra
Version: 0.8a-19.1
Severity: important
X-Debbugs-Cc: Mario Blättermann 

Hello Javier,
as stated in the description, manpages-es-extra is really outdated
with no hope of receiving any further updates. Is this really suitable
for bullseye? Manpages-es is already (long) gone.

Manpages-l10n is in the process of importing all previous spanish
translations (where possible). By using po4a, we are able to keep all
pages up to date. If enough content (>= 80%) is still translated, the
page is shipped (with all outdated paragraphs in english), while the
remaining pages are not shipped (but might be reactivated later). We
also attempt to unfuzzy trivial strings (like version number changes
or updated markup), so some pages with only editorial changes might
actually still reach 80% (and thus being shipped). And if further
translators come along, they can much more easily pick up and
recomplete/update the pages.

So far, we haven't imported any of the pages from manpage-es-extra,
but this will happen soon, but too late before the freeze. 

So there are two possible approaches: 
1. If the release-managers agree we will update manpages-l10n in March
   *with* pages form manpages-es-extra (those which make 80%). Then
   they are proper in Bullseye.

2. We provide backports for manpages-es, which will include pages from
   manpages-es-extra (newer, but of course file conflicts).

So I suggest to remove manpages-es-extra from Bullseye. This would
ease 1. above (i.e. increase the chances for late acceptance in March
of a new version with updated pages). Also please consider if the
outdated manpages-es-extra still does users a service?

Of course, if 1. does not work out, these man pages will only be 
available via backports, i.e. 2.

Mario (the upstream maintainer of manpages-l10n and the primary
importer of the pages from manpages-es-extra) is in CC, he can give
more details where necessary.

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

manpages-es-extra depends on no packages.

Versions of packages manpages-es-extra recommends:
pn  manpages-es  

Versions of packages manpages-es-extra suggests:
ii  konqueror [man-browser]  4:20.12.0-4
ii  man-db [man-browser] 2.9.3-2

-- 
  Dr. Helge Kreutzmann deb...@helgefjell.de
   Dipl.-Phys.   http://www.helgefjell.de/debian.php
64bit GNU powered gpg signed mail preferred
   Help keep free software "libre": http://www.ffii.de/


signature.asc
Description: PGP signature

Bug#980634: [Debichem-devel] Bug#980634: gromacs: FTBFS: Errors while running CTest

[Nicholas Breen]

reassign 980634 src:mpich 3.4-4
affects 980634 src:gromacs
close 980634 3.4-5
thanks

On Wed, Jan 20, 2021 at 09:41:19PM +0100, Lucas Nussbaum wrote:
> Source: gromacs
> Version: 2020.4-2
> Severity: serious
> Justification: FTBFS on amd64
> Tags: bullseye sid ftbfs
> Usertags: ftbfs-20210120 ftbfs-bullseye
> 
> Hi,
> 
> During a rebuild of all packages in sid, your package failed to build
> on amd64.
[...]
> >  1/30 Test  #1: TestUtilsUnitTests ...***Exception: SegFault  
> > 0.10 sec
> > [1611165257.171056] [ip-172-31-13-129:15115:0]  rdmacm_cm.c:638  UCX  
> > ERROR rdma_create_event_channel failed: No such device
> > [1611165257.171089] [ip-172-31-13-129:15115:0] ucp_worker.c:1432 UCX  
> > ERROR failed to open CM on component rdmacm with status Input/output error
[...]
> If you reassign this bug to another package, please marking it as 
> 'affects'-ing
> this package. See https://www.debian.org/Bugs/server-control#affects

Reassigning to mpich and then closing, for the sake of bug tracking -
building against 3.4-4 fails, but the 3.4-5 upload from earlier today
resolves this bug (thanks Alistair!).

It's possible that this is another iteration of #980033 on ucx, except
that it affected MPICH instead of OpenMPI here.  Not sure enough about
that to merge the bugs.  I can successfully build the OpenMPI portion of
gromacs in sid right now.


-- 
Nicholas Breen
nbr...@debian.org

Bug#871621: Status of the ITP for virt-bootstrap

[Jakob Haufe]

Hi,

I just stumbled across this ITP.

Given that skopeo is packaged now I was wondering what the status of
the packaging for virt-bootstrap is.

Cheers,
sur5r

-- 
ceterum censeo microsoftem esse delendam.


pgpeD7GPipTgU.pgp
Description: OpenPGP digital signature

Bug#980726: Seeing this too

[Helge Kreutzmann]

Hello Axel,
I'm seeing this too. Since I regularly use the console (and hence gpm)
and I'm rebooting my desktop machine daily, this is quite annyoing.

Until a few days ago, I was seeing in the logs:
Jan 16 20:18:23 samd systemd[1]: Starting LSB: gpm sysv init script...

then I see
Jan 19 17:21:13 samd systemd[1]: gpm.service: Succeeded.

but on the 20th it seems to have stopped, i.e. no longer gpm starts.
And on this day gpm was updated in Testing (which I run).

If you need any further infos or if you want me to test something, do
not hesitate to ask me so.

Greetings

   Helge


-- 
  Dr. Helge Kreutzmann deb...@helgefjell.de
   Dipl.-Phys.   http://www.helgefjell.de/debian.php
64bit GNU powered gpg signed mail preferred
   Help keep free software "libre": http://www.ffii.de/


signature.asc
Description: PGP signature

Bug#980858: iputils-ping: ping handles link-local addresses in a too smart way

[Noah Meyerhans]

On Sat, Jan 23, 2021 at 10:27:24AM +0100, Marc SCHAEFER wrote:
>$ ping6 fe80::1
>PING fe80::1(fe80::1) 56 data bytes
>From fe80::9e8e:99ff:fe3c:5523%eth0: icmp_seq=1 Destination unreachable: 
> Address unreachable
> 
> Link-local addresses are ambiguous: they lack the scope ID, unless you specify
> the scope with a postfix %iface_name or %iface_id. So why does ping try to
> guess which interface is used?

This was done upstream here:

https://github.com/iputils/iputils/pull/100

> That's the only way it should work:
> 
>$ ping6 fe80::1%eth1
>PING fe80::1%eth0(fe80::1%eth1) 56 data bytes
> 
> (or with the -I option).

I agree that this is the normal way of fully specifying a link-local
address.  However, rfc 4291 does not prohibit inferring the scope based
on routing tables, as far as I can tell, so I'm not sure that ping's
behavior is outright wrong.

If you can find text in the standards that indicates that ping is
actually behaving incorrectly, then I'm very happy to raise this issue
with upstream, as I don't particularly like the current behavior either.
I just haven't been able to convince myself that it's actually
incorrect.

noah

Bug#980777: FIT-PC: Fails to find driver for Ethernet, Realtek Semiconductor Co., Ltd. RTL-8100/8101L/8139 PCI

[Andrew M.A. Cater]

On Thu, Jan 21, 2021 at 05:01:52PM -0700, Charles Curley wrote:
> 
> Package: installation-reports
> Severity: normal
> X-Debbugs-Cc: charlescur...@charlescurley.com
> 
> Dear Maintainer,
> 
> Please see Comments/Problems below.
> 
> -- Package-specific info:
> 
> Boot method: DVD
> Image version: debian-bullseye-DI-alpha3-i386-DVD-1.iso
> Date: Jan 20 2021 16:36 MST
> 
> Machine: FIT-PC 1 https://en.wikipedia.org/wiki/Fit-PC#fit-PC_1.0
> Partitions: 
> 
> root@white:~# df -Tl
> Filesystem Type  Size  Used Avail Use% Mounted on
> udev   devtmpfs  108M 0  108M   0% /dev
> tmpfs  tmpfs  23M  560K   22M   3% /run
> /dev/sda6  ext2   55G  1.1G   51G   3% /
> tmpfs  tmpfs 111M 0  111M   0% /dev/shm
> tmpfs  tmpfs 5.0M 0  5.0M   0% /run/lock
> tmpfs  tmpfs 4.0M 0  4.0M   0% /sys/fs/cgroup
> /dev/sda1  ext2  236M   20M  204M   9% /boot
> tmpfs  tmpfs  23M 0   23M   0% /run/user/0
> /dev/sdb   vfat  1.4M  209K  1.2M  15% /media/disk
> /dev/sdc1  vfat  2.0G  1.2G  748M  62% /mnt
> root@white:~# fdisk -l /dev/sda
> Disk /dev/sda: 55.89 GiB, 60011642880 bytes, 117210240 sectors
> Disk model: Hitachi HTS54166
> Units: sectors of 1 * 512 = 512 bytes
> Sector size (logical/physical): 512 bytes / 512 bytes
> I/O size (minimum/optimal): 512 bytes / 512 bytes
> Disklabel type: dos
> Disk identifier: 0x0005c92c
> 
> Device Boot   Start   End   Sectors  Size Id Type
> /dev/sda1  *   2048499711497664  243M 83 Linux
> /dev/sda2501758 117209087 116707330 55.7G  5 Extended
> /dev/sda5501760   1445887944128  461M 82 Linux swap / Solaris
> /dev/sda6   1447936 117209087 115761152 55.2G 83 Linux
> root@white:~# 
> 
> 
> Base System Installation Checklist:
> [O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it
> 
> Initial boot:   [O]
> Detect network card:[E]
> Configure network:  [ ]
> Detect media:   [O]
> Load installer modules: [O]
> Clock/timezone setup:   [ ]
> User/password setup:[O]
> Detect hard drives: [O]
> Partition hard drives:  [E]
> Install base system:[O]
> Install tasks:  [ ]
> Install boot loader:[O]
> Overall install:[ ]
> 
> Comments/Problems:
> 
> 
> I own three FIT-PC 1s, two of which provide network
> services. https://en.wikipedia.org/wiki/Fit-PC#fit-PC_1.0 I'd like to
> keep them running for a few more years yet. So I tried the alpha 3
> installer.
> 
> In the process, I hit several problems.
> 
> * The NIC finding software failed to detect the two NICs. This has
>   worked in the past.
> 
You'll likely need the firmware .iso including the non-free firmwares - though 
I'm surprised that itr doesn't find the Ethernet devices, they're common.


> * When I tried to select the driver manually, I was given a list of
>   two NICs, neither one of them appropriate. On other hardware, a much
>   longer list, including the ones I need (8139.*), appears.
> 
> * When I tried to read the drivers from a USB floppy device, the
>   software did not find the floppy. This, in spite of the fact that I
>   could mount the floppy manually and read the preseed file from
>   it. The floppy drive should be /dev/sdb or sdc, depending on what
>   else I have on the USB bus.
> 
> * When putting file systems on the hard drive, ext4 and ext3 were
>   absent from the menu of possible file systems. ext2 was there, and
>   that's what I selected and got.
> 
> Is something eating my menus?
> 
> The first two problems are not new. I got the same with a Buster 10.4
> netinst CD. I then fell back to a Debian 8.6 netinst CD. That
> correctly found and set up the two NICs.
> 
8.6 is old - I'd be surprised that 10.7 firmware iso wouldn't work.

> Just in case I had hardware issues, I have tried this on two machines,
> one of which has been in continuous service since I bought them.
> 
> -- 
> 
> Please make sure that the hardware-summary log file, and any other
> installation logs that you think would be useful are attached to this
> report. Please compress large files using gzip.
> 
> Once you have filled out this report, mail it to sub...@bugs.debian.org.
> 
> ==
> Installer lsb-release:
> ==
> DISTRIB_ID=Debian
> DISTRIB_DESCRIPTION="Debian GNU/Linux installer"
> DISTRIB_RELEASE="11 (bullseye) - installer build 20201202"
> X_INSTALLATION_MEDIUM=cdrom
> 
> ==
> Installer hardware-summary:
> ==
> uname -a: Linux (none) 5.9.0-4-686 #1 SMP Debian 5.9.11-1 (2020-11-27) i586 
> GNU/Linux
> lspci -knn: 00:01.0 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] 
> CS5536 [Geode companion] Host Bridge [1022:2080] (rev 33)
> lspci -knn:   Subsystem: Advanced Micro Devices, Inc. [AMD] CS5536 [Geode 
> companion] Host Bridge [1022:2080]
> 

Bug#980884: ITP: pyftdi -- user-space driver for popular FTDI devices

[Anton Gladky]

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

* Package name: pyftdi
  Version : 0.52.9
  Upstream Author : Emmanuel Blot
* URL : https://github.com/eblot/pyftdi/
* License : BSD
  Programming Lang: Python
  Description : user-space driver for popular FTDI devices

PyFtdi aims at providing a user-space driver for popular
FTDI devices, implemented in pure Python language.

Suported FTDI devices include:
UART and GPIO bridges
FT232R (single port, 3Mbps)
FT230X/FT231X/FT234X (single port, 3Mbps)
UART and multi-serial protocols (SPI, I2C, JTAG) bridges
FT2232C/D (dual port, clock up to 6 MHz)
FT232H (single port, clock up to 30 MHz)
FT2232H (dual port, clock up to 30 MHz)
FT4232H (quad port, clock up to 30 MHz)

  Features
  PyFtdi currently supports the following features:
  UART/Serial USB converter, up to 12Mbps (depending on the FTDI device 
capability)
  GPIO/Bitbang support, with 8-bit asynchronous, 8-bit synchronous and 
8-/16-bit MPSSE variants
  SPI master, with simultanous GPIO support, up to 12 pins per port, with 
support for non-byte sized transfer
  I2C master, with simultanous GPIO support, up to 14 pins per port
  Basic JTAG master capabilities
  EEPROM support (some parameters cannot yet be modified, only retrieved)
  Experimental CBUS support on selected devices, 4 pins per port

Bug#980883: fix uninitialized var

[PICCORO McKAY Lenz]

Package: src:courier-unicode
Version: 2.1-3
Severity: important
Tags: buster

Description: BUGFIX unicode::iconvert::convert, fix uninitialized
variable. (already soved in bullseye 2.2 but not in stable)

Origin: upstream,
https://github.com/svarshavchik/courier-libs/commit/181c424a834d13a27e6026d4d05ac49230372aba#diff-2fcf76a4c3c75b1fb5288d83d62dd114dc556d16fba206ab35d38bfe294a2857

--- courier-unicode-2.1.orig/unicodecpp.C
+++ courier-unicode-2.1/unicodecpp.C
@@ -180,7 +180,10 @@ std::string unicode::iconvert::convert(c
  int err;

  if (uc.empty())
+ {
+ errflag=false;
  return buf;
+ }

  if (unicode_convert_fromu_tobuf([0], uc.size(),
dstcharset.c_str(), , ,



Lenz McKAY Gerardo (PICCORO)
http://qgqlochekone.blogspot.com

Bug#980882: ITP: openiked -- Internet Key Exchange (IKEv2) daemon

[Ryan Kavanagh]

Package: wnpp
Severity: wishlist
Owner: Ryan Kavanagh 
X-Debbugs-Cc: debian-de...@lists.debian.org, r...@debian.org

* Package name: openiked
  Version : unreleased/git
  Upstream Author : OpenBSD project
* URL : https://www.openiked.org/
* License : ISC
  Programming Lang: C
  Description : Internet Key Exchange (IKEv2) daemon

A free implementation of the Internet Key Exchange (IKEv2) protocol
which performs mutual authentication and which establishes and maintains
IPsec VPN security policies and associations (SAs) between peers. It is
intended to be a lean, clean, secure, better configurable and
interoperable implementation that focusses on supporting the main
standards and most important features of IKEv2.

As this "portable" version is relatively new and still unreleased, I
intend to upload this package to experimental for the time being. The
portable port can be found here:
https://github.com/openiked/openiked-portable

-- 
|)|/  Ryan Kavanagh  | GPG: 4E46 9519 ED67 7734 268F
|\|\  https://rak.ac |  BD95 8F7B F8FC 4A11 C97A


signature.asc
Description: PGP signature

Bug#980881: courier unicode cone lib bugfix

[PICCORO McKAY Lenz]

Package: src:courier-unicode
Version: 2.1-3
Severity: important
Tags: buster
Usertags: cone

backport important bug agains cone in stable current release: Fix bug
triggered by cone. Parameters to memmove were reversed.  len is the
size of the buffer. len-pos-cnt characters were copied in error  to
position pos+cnt. As such this did not overflow. I.e. if len was 8
(eight chars), pos was 1 and cnt was 2, then 8-2-1=5 characters were
copied  to offset 3, right at the end of the buffer. This was just
plain wrong.

Origin: upstream,
https://github.com/svarshavchik/courier-libs/commit/b89f5f8dc09431bb345308b3a0ffd5f7d22cdfb2#diff-2fcf76a4c3c75b1fb5288d83d62dd114dc556d16fba206ab35d38bfe294a2857

--- courier-unicode-2.1.orig/unicodebuf.c
+++ courier-unicode-2.1/unicodebuf.c
@@ -89,7 +89,7 @@ void unicode_buf_remove(struct unicode_b
  cnt=p->len-pos;

  if (cnt)
- memmove(p->ptr+pos+cnt, p->ptr+pos, p->len-pos-cnt);
+ memmove(p->ptr+pos, p->ptr+pos+cnt, (p->len-pos-cnt) * sizeof(char32_t));
  p->len -= cnt;
 }

--- courier-unicode-2.1.orig/unicodetest.c
+++ courier-unicode-2.1/unicodetest.c
@@ -123,11 +123,30 @@ static void test2()
  exit(1);
 }

+void testunicodebuf()
+{
+ struct unicode_buf buf;
+
+ unicode_buf_init(, -1);
+ unicode_buf_append_char(, "01234567", 8);
+ unicode_buf_remove(, 1, 6);
+
+ if (unicode_buf_len() != 2 ||
+ unicode_buf_ptr()[0] != '0' ||
+ unicode_buf_ptr()[1] != '7')
+ {
+ fprintf(stderr, "unicode_buf_remove failed\n");
+ exit(1);
+ }
+ unicode_buf_deinit();
+}
+
 int main(int argc, char **argv)
 {
  const char *chset=unicode_x_imap_modutf7;
  int argn=1;

+ testunicodebuf();
  if (argn < argc && strcmp(argv[argn], "--smap") == 0)
  {
  chset=unicode_x_imap_modutf7 " ./~:";


Lenz McKAY Gerardo (PICCORO)
http://qgqlochekone.blogspot.com

Bug#980214: linux-image-5.10.0-1-arm64: please enable CONFIG_CRYPTO_NHPOLY1305_NEON

[Vincent Blut]

Le 2021-01-23 18:04, Diederik de Haas a écrit :
> On zaterdag 23 januari 2021 17:00:25 CET Vincent Blut wrote:
> > Hi,
> > 
> > Le 2021-01-23 15:00, Diederik de Haas a écrit :
> > > Control: reopen -1
> > > Control: found -1 5.10.9+1
> > > 
> > > On zaterdag 23 januari 2021 11:05:23 CET Ard Biesheuvel wrote:
> > > > On Sat, 16 Jan 2021 at 18:27, Ard Biesheuvel  wrote:
> > > > > On Sat, 16 Jan 2021 at 18:24, Diederik de Haas 
> > > 
> > > wrote:
> > > > > > On zaterdag 16 januari 2021 10:42:19 CET Ard Biesheuvel wrote:
> > > > > > > Please enable CONFIG_CRYPTO_NHPOLY1305_NEON as a module for arm64
> > > > > > > builds
> > > > > > 
> > > > > > Is there a reason why it shouldn't be included in armhf builds? If
> > > > > > not,
> > > > > > then I'd like to see it enabled there too.
> > > > > > (And possibly in linux-image-rpi on armel as well?)
> > > > > 
> > > > > Agreed for armhf, assuming CONFIG_CRYPTO_ADIANTUM is already enabled
> > > > > on those platforms too. For armel, it depends on whether kernel mode
> > > > > NEON is already enabled in the first place.
> > > > 
> > > > This is enabled now for armhf but not for arm64:
> > > > 
> > > > linux-signed-arm64 (5.10.9+1) unstable; urgency=medium
> > > > ...
> > > > * [arm] Enable CRYPTO_NHPOLY1305_NEON. (closes: #980214)
> > > 
> > > I first thought that '[arm]' was a shorthand for various ARM
> > > architectures, but I just confirmed that it is indeed not fixed/enabled
> > > in arm64:
> > > # grep CRYPTO_NHPOLY1305_NEON /boot/config-5.10.0-2-arm64
> > > # CONFIG_CRYPTO_NHPOLY1305_NEON is not set
> > 
> > Indeed. I just sent a MR¹ to fix this.
> > 
> > Cheers,
> > Vincent
> > 
> > ¹ https://salsa.debian.org/kernel-team/linux/-/merge_requests/312
> 
> $ grep CRYPTO_NHPOLY1305_NEON /boot/config-5.10.0-2-armmp
> 
> didn't give a result, so it looks like it's also not enabled on armhf?

Oh I see, support for NEON in kernel mode is disabled.


signature.asc
Description: PGP signature

Bug#975389: Review of dpf-plugins RFS

[Ross Gammon]

tag 975389 + moreinfo
owner 975389 !
thanks

Hi Dennis,

Thanks for packaging dpf-plugins for Debian. Here is a review:

Need fixing:
d/changelog:
1. This is the initial release in Debian, so the the changelog should be
empty except for the "Initial debian release (Closes: #953129)" entry.
The earlier packaging work for KXStudio & Ubuntu is at least credited in
d/copyright.

d/copyright:
2. The distrho/extra plugins seem to be using the ISC license (not
GPL2+), or at least that is the case for Thread.hpp.
3. dpf/distrho/extra/String.hpp has "Copyright (C) 2004-2008 René
Nyffenegger", and Rene is not listed at all in d/copyright.
4. I stopped checking the d/copyright file here. I recommend a thorough
check of d/copyright to ensure the package passes smoothly through the
ftp-master review.

Minor/optional stuff:
5. d/dpf-plugins-vst.lintian-overrides (and for the lv2, ladspa & dssi
packages):
"splitted" is not grammatically correct, and the lintian output should
not be overriden, but a patch sent upstream. "3 Band Equalizer, split
output version" would be better.
6. dpf-plugins-common emits a lintian warning about "no-manual-page" for
the binaries. I tried a couple of them and they seem to open gui's and
the normal -h & -v options do nothing. Maybe we could check the others
and override the warning?

Other comments:
7. I see version 1.4 is now available upstream. If you prefer, we could
update to a full release rather than the "1.3 plus git commit" we have
at the moment.

I would be happy to upload with at least the first four comments fixed!

Regards,

Ross
FBEE 0190 904F 1EA0 BA6A  300E 53FE 7BBD A689 10FC



signature.asc
Description: OpenPGP digital signature

Bug#980880: gpsd: The argument to --pidfile is not processed, while -P works fine

[Alexander Inyukhin]

Package: gpsd
Version: 3.22-2
Severity: normal

I am trying to run gpsd with --pidfile option.
When I run command as shown below, the --pidfile's argument
is treated as inaccessible device name, but after changing it to -P
gpsd starts and creates the pid file.

 /usr/sbin/gpsd --sockfile /run/gpsd.sock --pidfile /run/gpsd.pid --nowait

I think the problem here is 'no_argument' value in the long_options[]
array (gpsd/gpsd.c:1951).
Also, the same problem may affect --port option (the next line of array).

Bug#980515: dump1090-mutability: FTBFS with GCC 10

[tony mancill]

Applied and uploaded

Thank you Logan!

On Tue, Jan 19, 2021 at 10:44:36PM -0500, Logan Rosen wrote:
> Source: dump1090-mutability
> Version: 1.15~20180310.4a16df3+dfsg-6
> Severity: serious
> Tags: patch ftbfs
> Justification: fails to build from source (but built successfully in the past)
> User: ubuntu-de...@lists.ubuntu.com
> Usertags: origin-ubuntu hirsute ubuntu-patch


signature.asc
Description: PGP signature

Bug#960524: Please provide a startup script for installations not using systemd

[gregor herrmann]

Control: tag -1 + patch

On Wed, 13 May 2020 14:04:47 +, Rob J. Epping wrote:

> Debian allows for other init systems as well, please provide startup
> scripts for these too.
> 
> Looking at the script /usr/sbin/zramswap, a quick solution could be to
> move this script to /ets/init.d

It's not as simple as that, because /usr/sbin/zramswap has no
runlevel information.

Anyway, here's a simple init script (attached).

Cheers,
gregor

-- 
 .''`.  https://info.comodo.priv.at -- Debian Developer https://www.debian.org
 : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D  85FA BB3A 6801 8649 AA06
 `. `'  Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe
   `-   NP: Tracy Chapman: Cold Feet
#!/usr/bin/env /lib/init/init-d-script

### BEGIN INIT INFO
# Provides:  zramswap
# Required-Start:$syslog $time $remote_fs
# Required-Stop: $syslog $time $remote_fs
# Default-Start: 2 3 4 5
# Default-Stop:  0 1 6
# Short-Description: Linux zramswap setup
# Description:   Debian init script for zramswap
### END INIT INFO

DAEMON=/usr/sbin/zramswap
PIDFILE=none

_is_active() {
$DAEMON status >/dev/null 2>&1
return $?
}

do_start_prepare() {
if _is_active; then
log_warning_msg "$NAME is already active"
exit 3
fi
}

do_start_cmd_override() {
$DAEMON start
}

do_stop_prepare() {
if ! _is_active; then
log_warning_msg "$NAME is not active"
exit 3
fi
}

do_stop_cmd_override() {
$DAEMON stop
}

do_status_override() {
$DAEMON status
}

do_restart_override() {
if _is_active; then
$DAEMON restart
else
$DAEMON start
fi
}


signature.asc
Description: Digital Signature

Bug#980214: linux-image-5.10.0-1-arm64: please enable CONFIG_CRYPTO_NHPOLY1305_NEON

[Diederik de Haas]

On zaterdag 23 januari 2021 17:00:25 CET Vincent Blut wrote:
> Hi,
> 
> Le 2021-01-23 15:00, Diederik de Haas a écrit :
> > Control: reopen -1
> > Control: found -1 5.10.9+1
> > 
> > On zaterdag 23 januari 2021 11:05:23 CET Ard Biesheuvel wrote:
> > > On Sat, 16 Jan 2021 at 18:27, Ard Biesheuvel  wrote:
> > > > On Sat, 16 Jan 2021 at 18:24, Diederik de Haas 
> > 
> > wrote:
> > > > > On zaterdag 16 januari 2021 10:42:19 CET Ard Biesheuvel wrote:
> > > > > > Please enable CONFIG_CRYPTO_NHPOLY1305_NEON as a module for arm64
> > > > > > builds
> > > > > 
> > > > > Is there a reason why it shouldn't be included in armhf builds? If
> > > > > not,
> > > > > then I'd like to see it enabled there too.
> > > > > (And possibly in linux-image-rpi on armel as well?)
> > > > 
> > > > Agreed for armhf, assuming CONFIG_CRYPTO_ADIANTUM is already enabled
> > > > on those platforms too. For armel, it depends on whether kernel mode
> > > > NEON is already enabled in the first place.
> > > 
> > > This is enabled now for armhf but not for arm64:
> > > 
> > > linux-signed-arm64 (5.10.9+1) unstable; urgency=medium
> > > ...
> > > * [arm] Enable CRYPTO_NHPOLY1305_NEON. (closes: #980214)
> > 
> > I first thought that '[arm]' was a shorthand for various ARM
> > architectures, but I just confirmed that it is indeed not fixed/enabled
> > in arm64:
> > # grep CRYPTO_NHPOLY1305_NEON /boot/config-5.10.0-2-arm64
> > # CONFIG_CRYPTO_NHPOLY1305_NEON is not set
> 
> Indeed. I just sent a MR¹ to fix this.
> 
> Cheers,
> Vincent
> 
> ¹ https://salsa.debian.org/kernel-team/linux/-/merge_requests/312

$ grep CRYPTO_NHPOLY1305_NEON /boot/config-5.10.0-2-armmp

didn't give a result, so it looks like it's also not enabled on armhf?


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

Bug#940704: new error: Cannot find module 'babel-preset-env'

[Paolo Greppi]

Hi, I think I fixed the error:

  Cannot find module 'babel-plugin-transform-inline-imports-commonjs'

with this commit: 
https://salsa.debian.org/js-team/node-yarnpkg/-/commit/d055e01b6d1a7f6fad6df2ccdf6d0f7d01ddcbc2
but the tests still fail, all with this new error:

  FAIL __tests__/commands/licenses.js
● Test suite failed to run
  
  Cannot find module 'babel-preset-env'

  Require stack:
  - /usr/share/nodejs/@babel/core/lib/config/files/plugins.js
  - /usr/share/nodejs/@babel/core/lib/config/files/index.js
  - /usr/share/nodejs/@babel/core/lib/index.js
  - /usr/share/nodejs/babel-jest/build/loadBabelConfig.js
  - /usr/share/nodejs/babel-jest/build/index.js
  - /usr/share/nodejs/@jest/transform/build/ScriptTransformer.js
  - /usr/share/nodejs/@jest/transform/build/index.js
  - /usr/share/nodejs/jest-runtime/build/index.js
  - /usr/share/nodejs/jest-runner/build/testWorker.js
  - /usr/share/nodejs/jest-worker/build/workers/processChild.js
  - Did you mean "@babel/env"?
  
89 |

90 |   try {
  > 91 | return require.resolve(standardizedName, {
   |^
92 |   paths: [dirname]
93 | });
94 |   } catch (e) {
  
at resolveStandardizedName (../../../../../usr/share/nodejs/@babel/core/lib/config/files/plugins.js:91:20)

at resolvePreset 
(../../../../../usr/share/nodejs/@babel/core/lib/config/files/plugins.js:48:10)
at loadPreset 
(../../../../../usr/share/nodejs/@babel/core/lib/config/files/plugins.js:67:20)
at createDescriptor 
(../../../../../usr/share/nodejs/@babel/core/lib/config/config-descriptors.js:154:9)
at 
../../../../../usr/share/nodejs/@babel/core/lib/config/config-descriptors.js:109:50
at Array.map ()
at createDescriptors 
(../../../../../usr/share/nodejs/@babel/core/lib/config/config-descriptors.js:109:29)
at createPresetDescriptors 
(../../../../../usr/share/nodejs/@babel/core/lib/config/config-descriptors.js:101:10)

see: https://salsa.debian.org/js-team/node-yarnpkg/-/jobs/1373973

I tried the obvious fix in debian/tests/control:

  -Depends: @, jest
  +Depends: @, jest, node-babel-preset-env

but no change.

Paolo

Bug#980879: RM: libqinfinity/experimental -- ROM; dead upstream, unused

[Pino Toscano]

Package: ftp.debian.org
Severity: normal
X-Debbugs-Cc: pkg-kde-ext...@lists.alioth.debian.org

Hi,

please remove libqinfinity from experimental (the only suite where
it is now). The last release upstream was 0.5.2, released more than
7 years ago, and the project is archived upstream (on kde.org).
There were and still are no users of it.

Thanks,
-- 
Pino

Bug#980202: FTBFS: gscan2pdf tests fail

[Cristy]

Thanks for the problem report. We can reproduce it and will have a patch 
to fix it in the GIT main branch @ 
https://github.com/ImageMagick/ImageMagick6 later today. The patch will 
be available in the beta releases of ImageMagick @ 
https://imagemagick.org/download/beta/ by sometime tomorrow.


The problem was a performance optimization that broke text rendering. We 
reverted the patch. The official -58 release will be available within a 
few days.


The ImageMagick Development team

Bug#980878: should also depend on fonts-sil-annapurna

[Sébastien Villemot]

Package: fonts-deva
Version: 2:1.3
Severity: normal

Dear Maintainer,

Since fonts-deva claims to install all Devanāgarī fonts available in Debian, it
should also depend on fonts-sil-annapurna.

Cheers,

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

Bug#980877: rocksndiamonds: [INTL:de] updated German debconf translation

[Helge Kreutzmann]

Package: rocksndiamonds
Version: 4.2.2.0+dfsg-1
Severity: wishlist
Tags: patch l10n

Please find the updated German debconf translation for rocksndiamonds
attached.

Please place this file in debian/po/ as de.po for your next upload.

If you update your template, please use 
'msgfmt --statistics '
to check the po-files for fuzzy or untranslated strings.

If there are such strings, please contact me so I can update the 
German translation.

Greetings
Helge
# translation of po-debconf template to German
# Copyright (C) 2007, Matthias Julius
# This file is distributed under the same license as the rocksndiamonds package.
#
# Matthias Julius , 2007.
# Thomas Mueller , 2009.
# Helge Kreutzmann , 2021.
msgid ""
msgstr ""
"Project-Id-Version: rocksndiamonds 4.2.2.0+dfsg-1\n"
"Report-Msgid-Bugs-To: rocksndiamo...@packages.debian.org\n"
"POT-Creation-Date: 2020-12-25 21:14+0100\n"
"PO-Revision-Date: 2021-01-23 17:38+0100\n"
"Last-Translator: Helge Kreutzmann \n"
"Language-Team: German \n"
"Language: de\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
"Plural-Forms:  nplurals=2; plural=(n != 1);\n"

#. Type: boolean
#. Description
#: ../templates:2001
msgid "Download non-free game data?"
msgstr "Unfreie Spieledaten herunterladen?"

#. Type: boolean
#. Description
#: ../templates:2001
msgid ""
"The data files required by rocksndiamonds do not have licenses that would "
"allow them to be distributed as a package. However, they can be "
"automatically downloaded from the Internet and installed locally."
msgstr ""
"Die Datendateien, die von rocksndiamonds benötigt werden, stehen unter "
"keiner Lizenz, die eine Verteilung in einem Paket erlaubt. Sie können jedoch "
"automatisch aus dem Internet heruntergeladen und lokal installiert werden."

#. Type: boolean
#. Description
#: ../templates:2001
msgid ""
"Some of these require downloading large files: BD2K3 (4.5 MiB), BD Dream "
"(11 MiB), Contributions 1995 - 2006 (6 MiB), Emerald Mine Club (44 MiB), "
"Legend of Zelda (2.1 MiB), Legend of Zelda II (12 MiB), rnd_jue (18 MiB), "
"Snake Bite (6.3 MiB), Supaplex (7.2 MiB)."
msgstr ""
"Einige dieser Downloads sind recht groß: BD2K3 (4,5 MiB), BD "
"Dream (11 MiB), Contributions 1995 - 2006 (6 MiB), Emerald Mine Club (44 "
"MiB), Legend of Zelda (2,1 MiB), Legend of Zelda II (12 MiB), rnd_jue (18 "
"MiB), Snake Bite (6,3 MiB), Supaplex (7,2 MiB)."

#. Type: multiselect
#. Description
#: ../templates:3001
msgid "Games to download data for:"
msgstr "Spiele, für die Daten heruntergeladen werden sollen:"

#. Type: error
#. Description
#: ../templates:4001
msgid "Missing utilities for download or unpacking"
msgstr "Fehlende Werkzeuge zum Herunterladen oder Entpacken"

#. Type: error
#. Description
#: ../templates:4001
msgid ""
"Downloading and unpacking the game data requires the packages wget, p7zip, "
"and unzip, but not all of these are available."
msgstr ""
"Zum Herunterladen und Entpacken der Spieledaten werden die Pakete wget, "
"p7zip und unzip benötigt, aber nicht alle sind vorhanden."

#. Type: error
#. Description
#: ../templates:4001
msgid ""
"You should install them and then reconfigure this package by using \"dpkg-"
"reconfigure rocksndiamonds\"."
msgstr ""
"Sie sollten sie installieren und dann dieses Paket neu einrichten, indem Sie "
"»dpkg-reconfigure rocksndiamonds« aufrufen."

#. Type: error
#. Description
#: ../templates:5001
msgid "Cannot download required resources"
msgstr "Die benötigten Ressourcen konnten nicht heruntergeladen werden"

#. Type: error
#. Description
#: ../templates:5001
msgid ""
"An error occurred while downloading game data. You should check the network "
"connection and settings and retry later on."
msgstr ""
"Es ist ein Fehler beim Herunterladen der Spieledaten aufgetreten. Bitte "
"prüfen Sie die Netzwerkverbindung und Einstellungen und versuchen Sie es "
"später noch einmal."

Bug#980809: [R-pkg-team] Bug#980809: rmatrix: breaks autopkgtest of r-cran-glmmtmb on s390x

[Dirk Eddelbuettel]

Hi Graham,

On 23 January 2021 at 00:21, Graham Inggs wrote:
| On Fri, 22 Jan 2021 at 23:38, Dirk Eddelbuettel  wrote:
| > Can you still please talk to the corresponding Debian maintainer for glmmTMB
| > so that he/she can walk it upstream?
| 
| I have assigned this bug to both packages, until we can figure out
| where the fix needs to happen.
| 
| > The package is clean where it matters:
| > https://cloud.r-project.org/web/checks/check_results_glmmTMB.html
| 
| Are they doing any tests on big-endian architectures?  Remember s390x
| is our only big-endian release architecture, and r-cran-glltmb's
| autopkgtests have green lights on all our little-endian architectures,
| so this hints to an endianness bug to me.

No CRAN does not test on s390x or comparable.  But the change in Matrix was
also relatively small.

But I will contact its main maintainer and also CC the glmmTMB maintainer.

Dirk

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

Bug#894312: rrootage: New upstream version 0.24

[Markus Koschany]

I have pushed my preliminary work for 0.24 to the experimental branch of

https://salsa.debian.org/games-team/rrootage


The sources are targeted for the Windows platform and I had to rebase the
patches. There are still some issues with the path to /usr/share/games/rrootage
because upstream assumes all data files must be in the current working
directory when rrootage is executed. I suppose we could also try to use 
awrapper script to avoid patching the game. 

Markus


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

Bug#980876: dash: Document -- option particularly with sh -c and security implication

[Bastien Roucariès]

Package: dash
Version: 0.5.11+git20200708+dd9ef66-5
Severity: important
Control: tags -1 + security


Dear Maintainer,

The option -- is not documented

For instance, as every posix shell 
sh -c  -x 'echo "$@"' echo foo 
is equivalent to
sh -x -c 'echo "$@"' echo foo
and not
sh -c -- -x 'echo "$@"' echo foo
That will execute -x as expected

This corner case should be clearly documented and could have security 
implication if argument of sh -c is not filtered.
Therefore -- style is prefered

see https://www.austingroupbugs.net/view.php?id=1440#c5192

Bastien

Bug#980835: buster-pu: fcitx/1:4.2.9.6-5+deb10u1

[Adam D. Barratt]

Control: tags -1 + confirmed

On Fri, 2021-01-22 at 17:55 -0500, Boyuan Yang wrote:
> Current fcitx v4.2.9.6 in Debian 10 has a broken implementation to
> flatpak support. As a result, software installed via flatpak cannot
> enable fcitx as the active input method.

Please go ahead.

Regards,

Adam

Bug#980214: linux-image-5.10.0-1-arm64: please enable CONFIG_CRYPTO_NHPOLY1305_NEON

[Vincent Blut]

Hi,

Le 2021-01-23 15:00, Diederik de Haas a écrit :
> Control: reopen -1
> Control: found -1 5.10.9+1
> 
> On zaterdag 23 januari 2021 11:05:23 CET Ard Biesheuvel wrote:
> > On Sat, 16 Jan 2021 at 18:27, Ard Biesheuvel  wrote:
> > > On Sat, 16 Jan 2021 at 18:24, Diederik de Haas  
> wrote:
> > > > On zaterdag 16 januari 2021 10:42:19 CET Ard Biesheuvel wrote:
> > > > > Please enable CONFIG_CRYPTO_NHPOLY1305_NEON as a module for arm64
> > > > > builds
> > > > 
> > > > Is there a reason why it shouldn't be included in armhf builds? If not,
> > > > then I'd like to see it enabled there too.
> > > > (And possibly in linux-image-rpi on armel as well?)
> > > 
> > > Agreed for armhf, assuming CONFIG_CRYPTO_ADIANTUM is already enabled
> > > on those platforms too. For armel, it depends on whether kernel mode
> > > NEON is already enabled in the first place.
> > 
> > This is enabled now for armhf but not for arm64:
> > 
> > linux-signed-arm64 (5.10.9+1) unstable; urgency=medium
> > ...
> > * [arm] Enable CRYPTO_NHPOLY1305_NEON. (closes: #980214)
> 
> I first thought that '[arm]' was a shorthand for various ARM architectures, 
> but 
> I just confirmed that it is indeed not fixed/enabled in arm64:
> # grep CRYPTO_NHPOLY1305_NEON /boot/config-5.10.0-2-arm64 
> # CONFIG_CRYPTO_NHPOLY1305_NEON is not set

Indeed. I just sent a MR¹ to fix this.

Cheers,
Vincent

¹ https://salsa.debian.org/kernel-team/linux/-/merge_requests/312


signature.asc
Description: PGP signature

Bug#977520: buster-pu: package steam/1.0.0.59-4+deb10u1

[Adam D. Barratt]

Control: tags -1 + confirmed

On Mon, 2021-01-18 at 00:34 +, Simon McVittie wrote:
> On Sat, 16 Jan 2021 at 18:14:15 +, Adam D. Barratt wrote:
> > On Tue, 2020-12-15 at 23:36 +, Simon McVittie wrote:
> > > If the release team would accept it, a backport of the .deb from
> > > testing/unstable would be a reasonable alternative to this.
> > 
> > Does that include many changes that aren't in your proposed list?
> 
> Source package: yes, lots; the source package was reorganised
> upstream, with many files added or moved around, many of which don't
> actually contribute to the .deb that we provide.
> 
> Resulting binary package: not many:
> 
> - the proprietary binary /usr/lib/games/steam/steam is newer
>   (used to download even newer proprietary binaries into the
>   user's home directory to bootstrap the actual Steam installation)
> - minor changes to the /usr/games/steam script
> - export environment variables that are picked up by Steam's
>   diagnostic tool, to signal the version of the script in use
> - pre-create ~/.steam/steam and ~/.steam/root symlinks
> - Suggests nvidia-driver-libs (implicitly :i386) instead of
>   transitional nvidia-driver-libs-i386, which went away in bullseye
> - remove some redundancy from the udev rules
> - don't set /dev/uinput to mode 0660, it has that mode by default
> - don't set TAG+="uaccess" twice per device
> - improved Homepage, etc. URLs, with more https
> - remove an obsolete Lintian override
> - some comments

Thanks for this, and the debdiffs. Based on the descriptions, I'd be
happy to defer to your judgement as to which of the two options you'd
be happiest to support for the future. Please feel free to upload one
of them.

Regards,

Adam

Bug#979749: buster-pu: package emacs/1:26.1+1-3.2+deb10u1

[Adam D. Barratt]

Control: tags -1 + confirmed

On Tue, 2021-01-19 at 19:59 -0600, Rob Browning wrote:
> "Adam D. Barratt"  writes:
> 
> > The metadata for that bug implies that it still affects the package
> > in
> > unstable (hence the lack of any green on the version graph). I
> > suspect
> > this is simply because the "fixed" version doesn't correspond to an
> > actual Debian package version. Please could you add a fixed version
> > that indicates the earliest upload to Debian that included the fix.
> 
> Done, I think.

That looks better, thanks.

> > Also, while it's possibly slightly picky:
> > 
> > +emacs (1:26.1+1-3.2+deb10u2~1.gbp7c5887) UNRELEASED;
> > urgency=medium
> > +
> > +  ** SNAPSHOT build @7c5887c8ae064398fafa38b8fea4c5d500830d5f **
> > +
> > +  * UNRELEASED
> > +
> > + -- Rob Browning   Sun, 10 Jan 2021 19:22:48
> > -0600
> > 
> > could we have a finalised version of that, please? :-)
> 
> Oh, no, certainly.  I just submitted the UNRELEASED version for the
> pre-approval.  I'll of course finalize that before the actual upload.

Sorry for being unclear - I meant "could we have _before the upload_".

> If that all sounds fine, I'll proceed with a real upload.

Please go ahead, but attaching a final copy of the diff to this bug
report would also be appreciated.

Regards,

Adam

Bug#979323: please provide cross-compiler for or1k

[Nicolas Boulenguez]

> You may also contact Nicolas, who wanted to coordinate building of
> targets which are not Debian ports.

I have only suggested to share experience and possibly code.  The
advices I have received from you and others may be found at
https://wiki.debian.org/PackagingLessCommonBinutilsTargets

binutils-or1k and gcc-or1k packages are mostly ready, I should push
them to salsa soon.  newlib seems more tricky and I will not be able
to work on it before weeks at the very least.

Bug#980875: buster-pu: package gst-plugins-bad1.0/1.14.4-1+deb10u1

[Salvatore Bonaccorso]

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

Hi SRM,

As pointed out by Adam, since there was a binNMU for
gst-plugins-bad1.0, the version from the DSA DSA-4833-1 had a lower
version (usually the suffix would be choosen +debXuY for that, but
this was an oversight for the DSA).

Attached is the no-change change proposed to make the sorting work
(and is a no change rebuild of the DSA version).

Can you accept this for the next point release?

Regards,
Salvtore
diff -Nru gst-plugins-bad1.0-1.14.4/debian/changelog 
gst-plugins-bad1.0-1.14.4/debian/changelog
--- gst-plugins-bad1.0-1.14.4/debian/changelog  2021-01-18 16:52:16.0 
+0100
+++ gst-plugins-bad1.0-1.14.4/debian/changelog  2021-01-23 16:37:59.0 
+0100
@@ -1,3 +1,11 @@
+gst-plugins-bad1.0 (1.14.4-1+deb10u1) buster; urgency=medium
+
+  * Non-maintainer upload.
+  * No-change re-upload with version bumped to 1.14.4-1+deb10u1 to sort after
+binNMUs for 1.14.4-1 in buster (1.14.4-1+b1).
+
+ -- Salvatore Bonaccorso   Sat, 23 Jan 2021 16:37:59 +0100
+
 gst-plugins-bad1.0 (1.14.4-1deb10u1) buster-security; urgency=high
 
   * debian/patches/02_ref_pic_markings_overflow.patch:

Bug#979724: libmaxminddb 1.3.2-1+deb10u1 flagged for acceptance

[Adam D Barratt]

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

Hi,

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

Thanks for your contribution!

Upload details
==

Package: libmaxminddb
Version: 1.3.2-1+deb10u1

Explanation: fix heap-based buffer over-read [CVE-2020-28241]

Bug#980458: debian-installer-utils 1.132+deb10u1 flagged for acceptance

[Adam D Barratt]

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

Hi,

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

Thanks for your contribution!

Upload details
==

Package: debian-installer-utils
Version: 1.132+deb10u1

Explanation: list-devices-linux: Support partitions on USB UAS devices

Bug#980799: irssi-plugin-xmpp 0.54-3+deb10u1 flagged for acceptance

[Adam D Barratt]

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

Hi,

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

Thanks for your contribution!

Upload details
==

Package: irssi-plugin-xmpp
Version: 0.54-3+deb10u1

Explanation: do not trigger the irssi core connect timeout prematurely, thus 
fixing STARTTLS connections

Bug#980762: cacti 1.2.2+ds1-2+deb10u4 flagged for acceptance

[Adam D Barratt]

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

Hi,

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

Thanks for your contribution!

Upload details
==

Package: cacti
Version: 1.2.2+ds1-2+deb10u4

Explanation: fix SQL injection issue [CVE-2020-35701] and stored XSS issue

Bug#980453: silx 0.9.0+dfsg-3+deb10u1 flagged for acceptance

[Adam D Barratt]

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

Hi,

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

Thanks for your contribution!

Upload details
==

Package: silx
Version: 0.9.0+dfsg-3+deb10u1

Explanation: python{,3}-silx: Add dependency on python{,3}-scipy

Bug#977895: slirp 1.0.17-8+deb10u1 flagged for acceptance

[Adam D Barratt]

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

Hi,

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

Thanks for your contribution!

Upload details
==

Package: slirp
Version: 1.0.17-8+deb10u1

Explanation: fix buffer overflows [CVE-2020-7039 CVE-2020-8608]

Bug#977735: node-ini 1.3.5-1+deb10u1 flagged for acceptance

[Adam D Barratt]

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

Hi,

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

Thanks for your contribution!

Upload details
==

Package: node-ini
Version: 1.3.5-1+deb10u1

Explanation: do not allow invalid hazardous string as section name 
[CVE-2020-7788]

Bug#977511: edk2 0~20181115.85588389-3+deb10u3 flagged for acceptance

[Adam D Barratt]

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

Hi,

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

Thanks for your contribution!

Upload details
==

Package: edk2
Version: 0~20181115.85588389-3+deb10u3

Explanation: CryptoPkg/BaseCryptLib: fix NULL dereference [CVE-2019-14584]

Bug#980268: buster-pu: cjson/1.7.10-1.1+deb10u1

[Adam D. Barratt]

Control: tags -1 + confirmed

On Sat, 2021-01-16 at 17:45 -0500, Boyuan Yang wrote:
> I intend to fix https://bugs.debian.org/973442 in Buster. Under some
> circumstances, the user input will cause an infinite loop in libcjson
> library. This is a regression introduced by the patch of CVE-2019-
> 11835 and was fixed in cjson/1.7.12.

Please go ahead.

Regards,

Adam

Bug#980259: buster-pu: package cyrus-imapd/3.0.8-6+deb10u5

[Adam D. Barratt]

Control: tags -1 + confirmed

On Sat, 2021-01-16 at 21:39 +0100, Xavier Guimard wrote:
> The /etc/cron.daily/cyrus-imapd cron script is not executed because
> the Cyrus version check does not match the cyrus version installed on
> Debian Buster

Please go ahead.

Regards,

Adam

Bug#980874: ITP: python-cwcwidth -- Python bindings for wc(s)width

[Sebastian Ramacher]

Package: wnpp
Severity: wishlist
Owner: Sebastian Ramacher 
X-Debbugs-Cc: debian-de...@lists.debian.org, sramac...@debian.org

* Package name: python-cwcwidth
  Version : 0.1
  Upstream Author : Sebastian Ramacher
* URL : https://github.com/sebastinas/cwcwidth
* License : Expat
  Programming Lang: Python, C
  Description : Python bindings for wc(s)width

This module provides functions to compute the printable length of a unicode
character/string on a terminal. It leverages the wcwidth(3) and wcswidth(3)
functions as defined in POSIX.1-2001 and POSIX.1-2008. This module provides
the same functions as the pure Python implementation found in python3-wcwidth.

This package provides the module for Python 3.


This package will be a dependency of the upcoming python-curtsies and
bpython releases.

Cheers
-- 
Sebastian Ramacher


signature.asc
Description: PGP signature

Bug#980802: buster-pu: package nvidia-graphics-drivers/418.181.07-1

[Adam D. Barratt]

Control: tags -1 + confirmed

On Fri, 2021-01-22 at 18:08 +0100, Andreas Beckmann wrote:
> I'd like to update nvidia-graphics-drivers in buster again to a new
> upstream release from the Tesla 418 series to fix CVE-2021-1056.

Please go ahead.

Regards,

Adam

Bug#980491: [pre-approval] buster-pu: package debian-edu-config/2.10.65+deb10u7

[Adam D. Barratt]

Control: tags -1 + confirmed

On Tue, 2021-01-19 at 20:06 +0100, Wolfgang Schweer wrote:
> the Debian Edu team would like to get a fix for bug #935080 into
> Buster. 
> This bug has already been fixed in testing and has proven to work in
> a real world deployment. Actually, the fix stems from there.
> 
> The reason for the change is present in the changelog:
> 
>  share/debian-edu-config/tools/clean-up-host-keytabs: Add script.
>  Move host keytabs cleanup code out of gosa-modify-host into a
> standalone
>  script, but still call it from there (for now). Major script
> improvement:
>  Reduce LDAP calls to a single ldapsearch query which greatly
> improves the
>  execution speed of the code. (Closes: #935080).
> 

Please go ahead.

Regards,

Adam

Bug#980201: buster-pu: package nvidia-graphics-drivers-legacy-390xx/390.141-2~deb10u1

[Adam D. Barratt]

Control: tags -1 + confirmed

On Sat, 2021-01-16 at 00:09 +0100, Andreas Beckmann wrote:
> I'd like to upload a new upstream release of the nvidia legacy driver
> 390xx to buster in order to fix CVE-2021-1056.

Please go ahead.

Regards,

Adam

Bug#980609: odb: FTBFS: i386.h:2500:10: fatal error: common/config/i386/i386-cpuinfo.h: No such file or directory

[GCS]

Control: reassign -1 src:gcc-10
Control: retitle -1 missing i386-cpuinfo.h
Control: affects -1 src:odb

On Wed, Jan 20, 2021 at 9:33 PM Lucas Nussbaum  wrote:
> Source: odb
> Version: 2.4.0-13
> Severity: serious
[...]
> > In file included from 
> > /usr/lib/gcc/x86_64-linux-gnu/10/plugin/include/tm.h:26,
> >  from 
> > /usr/lib/gcc/x86_64-linux-gnu/10/plugin/include/backend.h:28,
> >  from 
> > /usr/lib/gcc/x86_64-linux-gnu/10/plugin/include/gcc-plugin.h:30,
> >  from ../odb/gcc.hxx:48,
> >  from cxx-lexer.cxx:5:
> > /usr/lib/gcc/x86_64-linux-gnu/10/plugin/include/config/i386/i386.h:2500:10: 
> > fatal error: common/config/i386/i386-cpuinfo.h: No such file or directory
> >  2500 | #include "common/config/i386/i386-cpuinfo.h"
> >   |  ^~~
> > compilation terminated.
 It's an overlook in src:gcc-10 as it adds the pr95842.diff patch
which contains common/config/i386/i386-cpuinfo.h and noted as a "new
file" [1][2].
Also noted that i386.h is going to include it [3][4], but it's not
installed in the gcc-10-plugin-dev package.

Regards,
Laszlo/GCS
[1] 
https://sources.debian.org/src/gcc-10/10.2.1-6/debian/patches/pr95842.diff/#L23
[2] 
https://sources.debian.org/src/gcc-10/10.2.1-6/debian/patches/pr95842.diff/#L394
[3] 
https://sources.debian.org/src/gcc-10/10.2.1-6/debian/patches/pr95842.diff/#L33
[4] 
https://sources.debian.org/src/gcc-10/10.2.1-6/debian/patches/pr95842.diff/#L981