Bug#970351: installation-reports: System installed on encrypted temporary partitions destroys partitions on hosts

[Axel Stammler]

Package: installation-reports
Severity: important

Dear Maintainer,

the installer created these lines in /etc/crypttab:

sdb2_crypt /dev/sdb2 /dev/urandom cipher=aes-xts-plain64,size=256,swap,discard
sdb5_crypt /dev/sdb5 /dev/urandom cipher=aes-xts-plain64,size=256,tmp,discard
sdb8_crypt UUID=7bc39f4e-4efe-4494-acbb-fd276296a29e none luks,discard

After installation, I used the USB key as intended to work on different 
machines. If a
machine contained an /dev/sdb disk (so that the USB key was now at /dev/sdc), 
its
/dev/sdb5 partition was overwritten.

I changed /etc/crypttab like this, which removed the problem:

deb_usb_2_crypt PARTUUID=a81b4eec-02 /dev/urandom 
cipher=aes-xts-plain64,size=256,swap,discard
deb_usb_5_crypt PARTUUID=a81b4eec-05 /dev/urandom 
cipher=aes-xts-plain64,size=256,tmp,discard
deb_usb_8_crypt UUID=7bc39f4e-4efe-4494-acbb-fd276296a29e none luks,discard

(Obviously I also adapted /etc/fstab.)



-- Package-specific info:

Boot method: CD image on memory card
Image version: Buster 10 5 0 dated 7 Sept 2020 netinstall
Date: 

Machine: X230 with 60 GB USB key
Partitions: 

FilesystemType 1K-blocks Used Available Use% 
Mounted on
udev  devtmpfs9930400993040   0% 
/dev
tmpfs tmpfs   203172 6276196896   4% 
/run
/dev/sda1 ext4   377861685992   3480964   3% /
/dev/sda6 ext4  10506488  4802424   5150644  49% 
/usr
tmpfs tmpfs  10158520   1015852   0% 
/dev/shm
tmpfs tmpfs 51204  5116   1% 
/run/lock
tmpfs tmpfs  10158520   1015852   0% 
/sys/fs/cgroup
/dev/sda7 ext4   2817056   578964   2075276  22% 
/var
/dev/mapper/deb_teach_usb_5_crypt ext2960504 1344910368   1% 
/tmp
/dev/mapper/deb_teach_usb_8_crypt ext4  40412656 23129776  15200320  61% 
/home
tmpfs tmpfs   203168   20203148   1% 
/run/user/1001

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

Initial boot:   [O]
Detect network card:[O]
Configure network:  [O]
Detect CD:  [O]
Load installer modules: [O]
Clock/timezone setup:   [O]
User/password setup:[O]
Detect hard drives: [O]
Partition hard drives:  [O] — but see problem description above
Install base system:[O]
Install tasks:  [O]
Install boot loader:[O]
Overall install:[O] — but see above

Comments/Problems:

see top

-- 

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="10 (buster) - installer build 20190702+deb10u5"
X_INSTALLATION_MEDIUM=cdrom

==
Installer hardware-summary:
==
uname -a: Linux deb-teach-usb 4.19.0-10-amd64 #1 SMP Debian 4.19.132-1 
(2020-07-24) x86_64 GNU/Linux
lspci -knn: 00:00.0 Host bridge [0600]: Intel Corporation Atom Processor 
D4xx/D5xx/N4xx/N5xx DMI Bridge [8086:a010] (rev 02)
lspci -knn: Subsystem: ASUSTeK Computer Inc. Device [1043:83ac]
lspci -knn: 00:02.0 VGA compatible controller [0300]: Intel Corporation Atom 
Processor D4xx/D5xx/N4xx/N5xx Integrated Graphics Controller [8086:a011] (rev 
02)
lspci -knn: Subsystem: ASUSTeK Computer Inc. Device [1043:83ac]
lspci -knn: 00:02.1 Display controller [0380]: Intel Corporation Atom Processor 
D4xx/D5xx/N4xx/N5xx Integrated Graphics Controller [8086:a012] (rev 02)
lspci -knn: Subsystem: ASUSTeK Computer Inc. Device [1043:83ac]
lspci -knn: 00:1b.0 Audio device [0403]: Intel Corporation NM10/ICH7 Family 
High Definition Audio Controller [8086:27d8] (rev 02)
lspci -knn: Subsystem: ASUSTeK Computer Inc. Device [1043:84d3]
lspci -knn: 00:1c.0 PCI bridge [0604]: Intel Corporation NM10/ICH7 Family PCI 
Express Port 1 [8086:27d0] (rev 02)
lspci -knn: Kernel driver in use: pcieport
lspci -knn: 00:1c.1 PCI bridge [0604]: Intel Corporation NM10/ICH7 Family PCI 
Express Port 2 [8086:27d2] (rev 02)
lspci -knn: Kernel driver in use: pcieport
lspci -knn: 00:1c.3 PCI bridge [0604]: Intel Corporation NM10/ICH7 Family PCI 
Express Port 4 [8086:27d6] (rev 02)
lspci -knn: Kernel driver in use: pcieport
lspci -knn: 00:1d.0 USB controller [0c03]: Intel Corporation NM10/ICH7 Family 
USB UHCI Controller #1 [8086:27c8] (rev 02)
lspci -knn: Subsystem: ASUSTeK Computer Inc. Device [1043:83ad]
lspci -knn: 

Bug#970352: unprivileged podman dies with gibberish

[Harald Dunkel]

Package: podman
Version: 2.0.6+dfsg1-1

Unprivileged podman dies with some gibberish instead of a readable
error message:

% podman run -it debian /bin/bash
Trying to pull quay.io/debian...
  error parsing HTTP 404 response body: invalid character '<' looking for beginning of value: "\n404 Not Found\nNot Found\nThe requested URL was not found on the server. If you entered the URL manually please check 
your spelling and try again.\n"

Trying to pull docker.io/library/debian...
Getting image source signatures
Copying blob 57df1a1f1ad8 done
Copying config f6dcff9b59 done
Writing manifest to image destination
Storing signatures
ERRO[0010] Error while applying layer: ApplyLayer exit status 1 stdout:  
stderr: there might not be enough IDs available in the namespace (requested 
0:42 for /etc/gshadow): lchown /etc/gshadow: invalid argument
  ApplyLayer exit status 1 stdout:  stderr: there might not be enough IDs 
available in the namespace (requested 0:42 for /etc/gshadow): lchown 
/etc/gshadow: invalid argument
Error: unable to pull debian: 2 errors occurred:
* Error initializing source docker://quay.io/debian:latest: Error reading manifest latest in quay.io/debian: error parsing HTTP 404 response body: invalid character '<' looking for beginning of value: "\n404 Not 
Found\nNot Found\nThe requested URL was not found on the server. If you entered the URL manually please check your spelling and try again.\n"
* Error committing the finished image: error adding layer with blob "sha256:57df1a1f1ad841deaf50c8f662d77e93b4b17af776ed66148116607f9aceffa8": ApplyLayer exit status 1 stdout:  stderr: there might not be enough IDs available in the namespace (requested 0:42 for /etc/gshadow): lchown 
/etc/gshadow: invalid argument



Regards
Harri

Bug#970350: linux: Enable CONFIG_NET_SWITCHDEV in Buster kernel

[Vasudev Kamath]

Source: linux
Version: 4.19.132-1
Severity: normal

Dear Maintainer,

The regression issue which I reported in [1] has been fixed by Mellanox upstream
[2] and is now part of linux-4.19.145-1 [3]. So can we now enable the 
CONFIG_NET_SWITCHDEV
support in Debian Buster?

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=949863#43
[2] https://lkml.org/lkml/2020/8/7/451
[3] https://cdn.kernel.org/pub/linux/kernel/v4.x/ChangeLog-4.19.145


Cheers,
Vasudev


-- 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.7.0-3-amd64 (SMP w/8 CPU threads)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Bug#970349: buster-pu: package icinga2/2.10.3-2+deb10u1

[Bas Couwenberg]

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

icinga2 is buster is affected by CVE-2020-14004 as reported in #970252.

As it was deemed no-dsa it should be fixed via stable update.

Kind Regards,

Bas
diff -Nru icinga2-2.10.3/debian/changelog icinga2-2.10.3/debian/changelog
--- icinga2-2.10.3/debian/changelog 2019-03-01 12:18:30.0 +0100
+++ icinga2-2.10.3/debian/changelog 2020-09-14 06:47:22.0 +0200
@@ -1,3 +1,12 @@
+icinga2 (2.10.3-2+deb10u1) buster; urgency=medium
+
+  * Team upload.
+  * Update branch in gbp.conf & Vcs-Git URL.
+  * Add upstream patch to fix CVE-2020-14004.
+(closes: #970252)
+
+ -- Bas Couwenberg   Mon, 14 Sep 2020 06:47:22 +0200
+
 icinga2 (2.10.3-2) unstable; urgency=medium
 
   * Team upload.
diff -Nru icinga2-2.10.3/debian/control icinga2-2.10.3/debian/control
--- icinga2-2.10.3/debian/control   2018-12-25 23:27:26.0 +0100
+++ icinga2-2.10.3/debian/control   2020-09-14 06:47:22.0 +0200
@@ -29,7 +29,7 @@
po-debconf
 Standards-Version: 4.3.0
 Vcs-Browser: https://salsa.debian.org/nagios-team/pkg-icinga2
-Vcs-Git: https://salsa.debian.org/nagios-team/pkg-icinga2.git
+Vcs-Git: https://salsa.debian.org/nagios-team/pkg-icinga2.git -b buster
 Homepage: https://icinga.com
 
 Package: icinga2
diff -Nru icinga2-2.10.3/debian/gbp.conf icinga2-2.10.3/debian/gbp.conf
--- icinga2-2.10.3/debian/gbp.conf  2018-12-12 08:10:41.0 +0100
+++ icinga2-2.10.3/debian/gbp.conf  2020-09-14 06:47:22.0 +0200
@@ -6,7 +6,7 @@
 
 # The default name for the Debian branch is "master".
 # Change it if the name is different (for instance, "debian/unstable").
-debian-branch = master
+debian-branch = buster
 
 # git-import-orig uses the following names for the upstream tags.
 # Change the value if you are not using git-import-orig
diff -Nru 
icinga2-2.10.3/debian/patches/0001-prepare-dirs-combine-mkdir-and-chmod.patch 
icinga2-2.10.3/debian/patches/0001-prepare-dirs-combine-mkdir-and-chmod.patch
--- 
icinga2-2.10.3/debian/patches/0001-prepare-dirs-combine-mkdir-and-chmod.patch   
1970-01-01 01:00:00.0 +0100
+++ 
icinga2-2.10.3/debian/patches/0001-prepare-dirs-combine-mkdir-and-chmod.patch   
2020-09-14 06:47:22.0 +0200
@@ -0,0 +1,23 @@
+Description: prepare-dirs: combine mkdir and chmod
+ Fixes CVE-2020-14004
+Author: "Alexander A. Klimov" 
+Origin: 
https://github.com/Icinga/icinga2/commit/2f0f2e8c355b75fa4407d23f85feea037d2bc4b6
+Bug: https://github.com/Icinga/icinga2/pull/8046
+
+--- a/etc/initsystem/prepare-dirs.cmake
 b/etc/initsystem/prepare-dirs.cmake
+@@ -26,12 +26,10 @@ getent group $ICINGA2_GROUP >/dev/null 2
+ getent group $ICINGA2_COMMAND_GROUP >/dev/null 2>&1 || (echo "Icinga command 
group '$ICINGA2_COMMAND_GROUP' does not exist. Exiting." && exit 6)
+ 
+ if [ ! -e "$ICINGA2_INIT_RUN_DIR" ]; then
+-  mkdir "$ICINGA2_INIT_RUN_DIR"
+-  mkdir "$ICINGA2_INIT_RUN_DIR"/cmd
++  mkdir -m 755 "$ICINGA2_INIT_RUN_DIR"
++  mkdir -m 2750 "$ICINGA2_INIT_RUN_DIR"/cmd
+ fi
+ 
+-chmod 755 "$ICINGA2_INIT_RUN_DIR"
+-chmod 2750 "$ICINGA2_INIT_RUN_DIR"/cmd
+ chown -R $ICINGA2_USER:$ICINGA2_COMMAND_GROUP "$ICINGA2_INIT_RUN_DIR"
+ 
+ test -e "$ICINGA2_LOG_DIR" || install -m 750 -o $ICINGA2_USER -g 
$ICINGA2_COMMAND_GROUP -d "$ICINGA2_LOG_DIR"
diff -Nru icinga2-2.10.3/debian/patches/series 
icinga2-2.10.3/debian/patches/series
--- icinga2-2.10.3/debian/patches/series2019-03-01 12:17:29.0 
+0100
+++ icinga2-2.10.3/debian/patches/series2020-09-14 06:47:22.0 
+0200
@@ -1,3 +1,4 @@
 21_config_changes
 postgres-checkcommand.patch
 comparepasswords_issafe.patch
+0001-prepare-dirs-combine-mkdir-and-chmod.patch

Bug#969324: mutt feature request add configure option --enable-autocrypt

[Arsen STASIC]

Dear package maintainers,

autocrypt is a cryptographic protocol for email clients aiming to simplify key 
exchange and enabling encryption on basis of OpenPGP and due to the fact that 
WoT (Web of Trust) is broken [0] since June 2019 [1] (Daniel Kahn Gillmor 
(dkg)) it's a needed feature.

These MUAs (Mail User Agents) support autocrypt already:
Thunderbird, Mailpile, Delta Chat Messenger, K-9 Mail and Mutt.

Please consider my patch.

cheers,
Arsen

[0] https://lwn.net/Articles/792366/
[1] https://dkg.fifthhorseman.net/blog/openpgp-certificate-flooding.html

Bug#970252: [Pkg-nagios-devel] Bug#970252: Bug#970252: CVE-2020-14004

[Salvatore Bonaccorso]

Hi Sebastiaan,

On Mon, Sep 14, 2020 at 07:09:05AM +0200, Sebastiaan Couwenberg wrote:
> On 9/14/20 6:38 AM, Sebastiaan Couwenberg wrote:
> > On 9/14/20 5:41 AM, Sebastiaan Couwenberg wrote:
> >> On 9/13/20 10:39 PM, Moritz Muehlenhoff wrote:
> >>> Please see https://www.openwall.com/lists/oss-security/2020/06/12/1
> >>
> >> This is fixed upstream in:
> >>
> >>  v2.12.0 v2.11.5 v2.11.4
> >>
> >> The former is already in experimental, and the 2.11 package in unstable
> >> will be updated to .5 to have the fix as well.
> > 
> > icinga2 (2.11.5-1) has been uploaded to unstable.
> 
> The update for buster is also available:
> 
>  https://salsa.debian.org/nagios-team/pkg-icinga2/-/commits/buster
> 
> Is it alright to upload the -sa build to security-master?

This is likely a no-dsa candidate, but can you fix the issue via the
upcoming point release?

The window for uploads should be closing the upcoming weekend for
inclusion in 10.6.

Regards,
Salvatore

Bug#970282: O: python-inflect -- Generate plurals, singular nouns, ordinals, indefinite articles

[Arto Jantunen]

"Iain R. Learmonth"  writes:
> Package: wnpp
> Severity: normal
> X-Debbugs-Cc: debian-pyt...@lists.debian.org
>
> I intend to orphan the python-inflect package. This would be a good
> candidate for the Python team. It has reverse dependencies in Debian:
> python3-jaraco.itertools and sqlacodegen.
>
> The package description is:
>  The inflect Python module correctly generates plurals, singular nouns,
>  ordinals and indefinite articles. It can also convert numbers to words.

Agreed, this should be transferred to the Python team. I can be an
uploader for it (I already maintain sqlacodegen, even though it appears
to have been abandoned upstream).

-- 
Arto Jantunen

Bug#970347: keepassxc: file handles leaking, until keepassxc can no longer open its database

[Noel]

Package: keepassxc
Version: 2.3.4+dfsg.1-1
Severity: normal

KeepassXC leaks file handles during normal operation. After running for a few
days it exhausts the allowed file handles and cannot open the password database 
until it
is restarted. When you try to unlock KeepassXC displays a red backgrounded 
message
saying "Too many open files".

Sometimes, this is logged in /var/log/messages and keepassxc crashes:

Sep 15 12:31:00 moriarty kernel: [1819009.252670] traps: keepassxc[13185] trap 
int3 ip:7f95e9478c75 sp:7f95c65b76c0 error:0 in 
libglib-2.0.so.0.5800.3[7f95e944+7e000]
Sep 15 12:31:00 moriarty org.keepassxc.KeePassXC.desktop[28230]: 
(keepassxc:30366): GLib-ERROR **: 12:31:00.468: Creating pipes for GWakeup: Too 
many open files

$ ps -fC keepassxc
UIDPID  PPID  C STIME TTY  TIME CMD
noeld30366 28230  0 Aug31 tty2 00:01:46 keepassxc

$ ulimit -n
1024

# lsof -p 30366|wc -l
1194

lsof shows lots and lots of open FIFOs (662) plus a further 338 open timerfd
objects:

keepassxc 30366 noeld   71r FIFO   0,12  0t0  8985395 pipe
keepassxc 30366 noeld   72w FIFO   0,12  0t0  8985395 pipe
keepassxc 30366 noeld   73u  a_inode   0,130 9262 
[timerfd]
keepassxc 30366 noeld   74r FIFO   0,12  0t0  8984435 pipe
keepassxc 30366 noeld   75w FIFO   0,12  0t0  8984435 pipe
keepassxc 30366 noeld   76u  a_inode   0,130 9262 
[timerfd]
keepassxc 30366 noeld   77r FIFO   0,12  0t0  9003187 pipe
keepassxc 30366 noeld   78w FIFO   0,12  0t0  9003187 pipe
keepassxc 30366 noeld   79u  a_inode   0,130 9262 
[timerfd]
keepassxc 30366 noeld   80r FIFO   0,12  0t0  9009935 pipe
keepassxc 30366 noeld   81w FIFO   0,12  0t0  9009935 pipe
keepassxc 30366 noeld   82u  a_inode   0,130 9262 
[timerfd]
keepassxc 30366 noeld   83r FIFO   0,12  0t0  9022897 pipe
keepassxc 30366 noeld   84w FIFO   0,12  0t0  9022897 pipe
keepassxc 30366 noeld   85u  a_inode   0,130 9262 
[timerfd]
keepassxc 30366 noeld   86r FIFO   0,12  0t0  9023162 pipe
keepassxc 30366 noeld   87w FIFO   0,12  0t0  9023162 pipe
keepassxc 30366 noeld   88u  a_inode   0,130 9262 
[timerfd]
keepassxc 30366 noeld   89r FIFO   0,12  0t0  9023295 pipe
keepassxc 30366 noeld   90w FIFO   0,12  0t0  9023295 pipe
keepassxc 30366 noeld   91u  a_inode   0,130 9262 
[timerfd]
keepassxc 30366 noeld   92r FIFO   0,12  0t0  9039327 pipe
keepassxc 30366 noeld   93w FIFO   0,12  0t0  9039327 pipe
keepassxc 30366 noeld   94u  a_inode   0,130 9262 
[timerfd]
keepassxc 30366 noeld   95r FIFO   0,12  0t0  9046512 pipe
keepassxc 30366 noeld   96w FIFO   0,12  0t0  9046512 pipe
keepassxc 30366 noeld   97u  a_inode   0,130 9262 
[timerfd]
keepassxc 30366 noeld   98r FIFO   0,12  0t0  9047996 pipe
keepassxc 30366 noeld   99w FIFO   0,12  0t0  9047996 pipe
keepassxc 30366 noeld  100u  a_inode   0,130 9262 
[timerfd]
keepassxc 30366 noeld  101r FIFO   0,12  0t0  9048550 pipe
keepassxc 30366 noeld  102w FIFO   0,12  0t0  9048550 pipe
keepassxc 30366 noeld  103u  a_inode   0,130 9262 
[timerfd]
keepassxc 30366 noeld  104r FIFO   0,12  0t0  9051557 pipe
keepassxc 30366 noeld  105w FIFO   0,12  0t0  9051557 pipe
keepassxc 30366 noeld  106u  a_inode   0,130 9262 
[timerfd]
keepassxc 30366 noeld  107r FIFO   0,12  0t0  9051867 pipe
keepassxc 30366 noeld  108w FIFO   0,12  0t0  9051867 pipe
keepassxc 30366 noeld  109u  a_inode   0,130 9262 
[timerfd]
keepassxc 30366 noeld  110r FIFO   0,12  0t0  9054205 pipe
keepassxc 30366 noeld  111w FIFO   0,12  0t0  9054205 pipe
keepassxc 30366 noeld  112u  a_inode   0,130 9262 
[timerfd]
keepassxc 30366 noeld  113r FIFO   0,12  0t0  9059108 pipe
keepassxc 30366 noeld  114w FIFO   0,12  0t0  9059108 pipe
keepassxc 30366 noeld  115u  a_inode   0,130 9262 
[timerfd]
keepassxc 30366 noeld  116r FIFO   0,12  0t0  9059311 pipe
keepassxc 30366 noeld  117w FIFO   0,12  0t0  9059311 pipe
keepassxc 30366 noeld  118u  a_inode   0,130 9262 
[timerfd]
keepassxc 30366 noeld  119r FIFO   0,12  0t0  9068847 pipe
keepassxc 

Bug#970214: RFS: rednotebook/2.20+ds-1 [ITP] [Team] -- Modern desktop diary and personal journaling tool

[Adam Borowski]

On Sun, Sep 13, 2020 at 05:11:52AM +0100, Phil Wyett wrote:
>  * Package name: rednotebook
>Version : 2.20+ds-1

> Changes since the last upload:
> 
>  rednotebook (2.20+ds-1) unstable; urgency=medium
>  .
>* Team upload.
>* New upstream version 2.20.
>* Reintroduction to debian - ITP. (Closes: #970204)

Fails to build:

.[ Build Type: source ]
Command: dpkg-buildpackage -us -uc -S -rfakeroot
dpkg-buildpackage: info: source package rednotebook
dpkg-buildpackage: info: source version 2.20+ds-1
dpkg-buildpackage: info: source distribution unstable
dpkg-buildpackage: info: source changed by Phil Wyett 

 dpkg-source --before-build .
 debian/rules clean
dh clean --with python3 --buildsystem=pybuild
dh: error: unable to load addon python3: Can't locate 
Debian/Debhelper/Sequence/python3.pm in @INC (you may need to install the 
Debian::Debhelper::Sequence::python3 module) (@INC contains: /etc/perl 
/usr/local/lib/x86_64-linux-gnu/perl/5.30.3 /usr/local/share/perl/5.30.3 
/usr/lib/x86_64-linux-gnu/perl5/5.30 /usr/share/perl5 
/usr/lib/x86_64-linux-gnu/perl-base /usr/lib/x86_64-linux-gnu/perl/5.30 
/usr/share/perl/5.30 /usr/local/lib/site_perl) at (eval 13) line 1.
BEGIN failed--compilation aborted at (eval 13) line 1.

make: *** [debian/rules:8: clean] Error 25
dpkg-buildpackage: error: debian/rules clean subprocess returned exit status 2
`

(I haven't looked any further.)


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ “Exegi monumentum aere perennius” -- “I made a monument more
⢿⡄⠘⠷⠚⠋⠀ durable than bronze”.
⠈⠳⣄   -- Horace (65-8 BC), leaving the loo, constipated

Bug#968620:

[Francisco M Neto]

Control: retitle 968620 'ITA: wiki2beamer -- Tool to create LaTeX beamer 
presentations in wiki syntax'



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

Bug#954816: mdadm: Debian stable system does not boot after kernel upgrade, RAID0 not activated

[Felix Lechner]

Hi Răzvan,

> systemctl status lvm2-pvscan

Are you having an interaction with device mapper facilities for RAID
(i.e. dmraid or lvm2)?

> the same system boots normally if, during boot, one chooses manually the 
> 4.19.0-6 kernel
> in grub's boot menu.

What are the kernel options for the different boot paths in GRUB, i.e.
the manual and the automatic setting?

Kind regards
Felix Lechner

Bug#855871: mdadm: maximum of 27 block devices for RAID assembly

[Felix Lechner]

Hi Ian,

Thank you for the informative details in your bug report. At this
point, I am trying to figure out if your issue still exists.

> quote: "MD_SB_DISKS indicates that each software array is limited to 27
member disks."

Have you tried it with a more recent kernel?

> mdadm won't allow the v1.2 superblock type with a non-metadata array:

Or that, with a more recent version of mdadm? Thank you!

Kind regards
Felix Lechner

Bug#857284: mdadm: subprocess installed post-installation script returned error exit status 128

[Felix Lechner]

Hi Asensu,

> if [ ! "$DEBIAN_HAS_FRONTEND" ]; then

The postinst script was totally rewritten [1] since you filed your
bug. Do you still experience this issue?

Kind regards
Felix Lechner

[1] https://sources.debian.org/src/mdadm/4.1-6/debian/mdadm.postinst/

Bug#864145: mdadm will only start root device degraded

[Felix Lechner]

Hi Felix,

> An entry in
> /etc/crypttab is created and the device is apparently unlocked as I
> don't need to enter the password after the boot process.

Do you still use this setup, and do you still have the issue?

What is in your /etc/crypttab? Do you perhaps need an offset to
preserve mdadm metadata? For example, I have 'offset=8' for an
encrypted swap partition, but it is not an mdadm device:

cryptswap /dev/mapper/optivg-swap /dev/urandom
swap,offset=8,cipher=aes-cbc-essiv:sha256,size=256,hash=ripemd160

The last suggestion is just a guess.

Kind regards
Felix Lechner

Bug#905968: mdadm can assemble wrong version, when write-mostly feature used

[Felix Lechner]

Hi Ian,

> [0001-Assemble.c-Use-MD_-names-when-checking-state-for-mos.patch (text/plain, 
> inline)]

This patch applies to the version in unstable (no one bothered to
touch the '6') but it brings no functional change. I am happy to
forward it upstream. Unfortunately, I am not sure they will respond.

> [0002-Assemble.c-Do-not-disregard-write-mostly-disks.patch (text/plain, 
> inline)]

This change, which fixes your bug,  was cherry-picked from upstream
some time ago. [1] It is already available in stable (4.1-1).

[1] 
https://sources.debian.org/src/mdadm/4.1-6/debian/patches/0007-Assemble-mask-FAILFAST-and-WRITEMOSTLY-flags-when-fi.patch/

> [0003-Assemble.c-Do-not-disregard-to-be-replaced-disks.patch (text/plain, 
> inline)]

The source prompting your change was totally rewritten. Do you feel
like taking another look?

Other than that, would you be okay if I close this bug after accepting
the first patch (using string constants instead of '6')? Thanks!

Kind regards
Felix Lechner

Bug#962844: mdadm: Assembling RAID using IMSM in initrd fails due to lack of module efivarfs

[Felix Lechner]

Hi Colin,

> The efivarfs module was not found in the initrd

I would like to make sure any new module requirements are also
compatible with systems booting in legacy BIOS mode. The Wikipedia
article for Intel RST states:

> When booting in a BIOS environment (legacy) and some / EFI, the RST option
> ROM is used. When booting in a true UEFI environment the Option ROM is not
> used as a SataDriver with the RST version takes over. In BIOS mode the
> legacy/BIOS booting is under CSMCORE. In true UEFI mode the RST is
> controlled under SataDriver in BIOS. [1]

The article suggests that some people use IMSM arrays in legacy BIOS
mode. Does mdadm support IMSM only when the system is booted in UEFI
mode?

Sorry that I do not know the answer to that question. I just assumed
maintenance of mdadm and do not use IMSM. At this point, I am reading
code. Thank you!

Kind regards
Felix Lechner

[1] 
https://en.wikipedia.org/wiki/Intel_Rapid_Storage_Technology#Matrix_Storage_Manager_option_ROM

Bug#969596:

[Michael Hudson-Doyle]

The attached patch appears to fix the build in Ubuntu.
diff -Nru minimap2-2.17+dfsg/debian/changelog minimap2-2.17+dfsg/debian/changelog
--- minimap2-2.17+dfsg/debian/changelog	2020-07-07 21:32:26.0 +1200
+++ minimap2-2.17+dfsg/debian/changelog	2020-09-15 12:34:50.0 +1200
@@ -1,3 +1,10 @@
+minimap2 (2.17+dfsg-11ubuntu1) groovy; urgency=medium
+
+  * d/patches/python-sse4-arch.patch: Only pass -msse4.1 to the compiler on
+amd64.
+
+ -- Michael Hudson-Doyle   Tue, 15 Sep 2020 12:34:50 +1200
+
 minimap2 (2.17+dfsg-11) unstable; urgency=medium
 
   * Add lintian-override
diff -Nru minimap2-2.17+dfsg/debian/control minimap2-2.17+dfsg/debian/control
--- minimap2-2.17+dfsg/debian/control	2020-07-07 21:32:26.0 +1200
+++ minimap2-2.17+dfsg/debian/control	2020-09-15 12:34:50.0 +1200
@@ -1,5 +1,6 @@
 Source: minimap2
-Maintainer: Debian Med Packaging Team 
+Maintainer: Ubuntu Developers 
+XSBC-Original-Maintainer: Debian Med Packaging Team 
 Uploaders: Andreas Tille 
 Section: science
 Priority: optional
diff -Nru minimap2-2.17+dfsg/debian/patches/python-sse4-arch.patch minimap2-2.17+dfsg/debian/patches/python-sse4-arch.patch
--- minimap2-2.17+dfsg/debian/patches/python-sse4-arch.patch	1970-01-01 12:00:00.0 +1200
+++ minimap2-2.17+dfsg/debian/patches/python-sse4-arch.patch	2020-09-15 12:34:50.0 +1200
@@ -0,0 +1,11 @@
+--- a/setup.py
 b/setup.py
+@@ -26,7 +26,7 @@
+ if platform.machine() in ["aarch64", "arm64"]:
+ 	include_dirs.append("sse2neon/")
+ 	extra_compile_args.extend(['-ftree-vectorize', '-DKSW_SSE2_ONLY', '-D__SSE2__'])
+-else:
++elif platform.machine() == "x86_64":
+ 	extra_compile_args.append('-msse4.1') # WARNING: ancient x86_64 CPUs don't have SSE4
+ 
+ def readme():
diff -Nru minimap2-2.17+dfsg/debian/patches/series minimap2-2.17+dfsg/debian/patches/series
--- minimap2-2.17+dfsg/debian/patches/series	2020-07-07 21:32:26.0 +1200
+++ minimap2-2.17+dfsg/debian/patches/series	2020-09-15 12:34:42.0 +1200
@@ -3,3 +3,4 @@
 simde
 ar.patch
 link_mappy_to_libminimap.patch
+python-sse4-arch.patch

Bug#970344: ncbi-blast+: tblastn segfaults intermittently with multiple threads

[Aaron M. Ucko]

Étienne Mollier  writes:

>   * temp_gene_seqs.fasta, which I try to attach to the present
> report if the engine accepts attachments of 264 kiB; it is

FTR, the BTS accepted this attachment, thanks!  As proposed on -med, I
will try to reproduce the bug under rr, though doing so isn't quite as
straightforward as I'd hoped because rr emulates a single CPU; to
compensate, I must temporarily patch out BLAST+'s logic to limit the
thread count accordingly.

-- 
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu

Bug#970083: multiple spaces in symbols files

[Guillem Jover]

Hi!

On Fri, 2020-09-11 at 11:04:33 +0200, Matthias Klose wrote:
> Package: src:dpkg
> Version: 1.20.5
> Severity: minor

> symbols files with more than one space between the symbol name and the minor
> version are rejected. This should either be documented in deb-symbols(5), or
> accepted in symbols files.

Right, I'll document it in deb-symbols(5). Adding support now would mean
that older version would not accept those, and also that the spacing
would need to be normalized before comparing the files, which seems
suboptimal.

> while looking for the documentation, I saw that dpkg-gensymbols(1) refers to
> deb-symbols(5) for the format, however comments in symbols files are only
> documented in dpkg-gensymbols(1).

To avoid this kind of confusion this was moved out to
deb-src-symbols(5), I guess you might have checked on an older dpkg
version? I'll also add an explicit ref to deb-symbols(5) in the
deb-src-symbols(5) to make the format layering more clear.

Thanks,
Guillem

Bug#970323: dpkg-deb fails to create package > 2 GB

[Guillem Jover]

Hi!

On Mon, 2020-09-14 at 18:52:57 +0200, Francois Gouget wrote:
> Package: dpkg
> Version: 1.19.7
> Severity: normal

> dpkg-deb fails to create a package with a size greater than 2 GB.
> To reproduce this issue use the attached file to create a 2.4 GB
> package, this despite being on a 64-bit system:
> 
> $ tar xfz testpkg.tar.gz
> $ cd testpkg
> $ fakeroot ./build
> [...]
> + dh_builddeb --destdir=.
> dpkg-deb: building package 'testpkg' in './testpkg_1.0-1_all.deb'.
> dpkg-deb (subprocess): compressing tar member: lzma write error: No space 
> left on device
> dpkg-deb: error:  from tar -cf subprocess returned error exit 
> status 2
> dh_builddeb: dpkg-deb --build debian/testpkg . returned exit code 2
> dh_builddeb: Aborting due to earlier error
> 
> Note that neither tar nor ar have any trouble dealing with archives with
> a size greater than 2 GB.
> Also this is not specific to the lzma compressor: using gzip instead
> produces the same error.

From the error message printed, it looks like your temporary directory
is not big enough. If you set TMPDIR to something else it should work
I guess?

Thanks for the test case, although this is already part of the
external dpkg functional test suite:

  

Perhaps the temporary filename should be printed to give a better
hint, even though that file gets unlinked so it would not be present
in the filesystem and so it might be even more confusing. Ideally
though no temporary file would be used, and these would be streamed
directly into the generated .deb archive (which AFAIR is on the TODO
list :).

Thanks,
Guillem

Bug#959518: apt-transport-http: Repeatable 'Undetermined Error' during package download from snapshot.debian.org

[James Addison]

Package: snapshot.debian.org
Followup-For: Bug #959518
X-Debbugs-Cc: j...@jp-hosting.net

(sorry: I realized I meant 'compile ... using bullseye' in that previous 
message, not buster (stable))

Bug#970332: libcurl4: Public key authentication failure

[Sam Kemp]

Package: libcurl4
Version: 7.72.0-1
Severity: normal

Dear maintainer

The version of libcurl4 in testing (7.72.0-1) fails to successfully negotiate
public key authentication and closes the connection early.

I have tested using the attached script against both stable and testing
versions of openssh-server (1:7.9p1-10+deb10u2 and 1:8.3p1-1).

Testing with the same script and the stable version of libcurl4
(7.64.0-4+deb10u1) is successful so this looks like a regression?

I have attached openssh-server logs from a machine running openssh-server
1:8.3p1-1, showing success from "old" libcurl4 and "failure" from new libcurl4.

(Note that the stable version was tested using a TCP connection to localhost so
the IPs of server and client are the same in that case.)

Not sure what the next diagnostic / debugging steps are here but happy to
provide any assistance?

Many thanks,

Sam Kemp




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

Kernel: Linux 5.7.0-3-amd64 (SMP w/4 CPU threads)
Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8), LANGUAGE=en_GB:en
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages libcurl4 depends on:
ii  libbrotli11.0.9-2
ii  libc6 2.31-3
ii  libgssapi-krb5-2  1.17-10
ii  libidn2-0 2.3.0-1
ii  libldap-2.4-2 2.4.53+dfsg-1
ii  libnghttp2-14 1.41.0-3
ii  libpsl5   0.21.0-1.1
ii  librtmp1  2.4+20151223.gitfa8646d.1-2+b2
ii  libssh2-1 1.8.0-2.1
ii  libssl1.1 1.1.1g-1
ii  zlib1g1:1.2.11.dfsg-2

Versions of packages libcurl4 recommends:
ii  ca-certificates  20200601

libcurl4 suggests no packages.

-- no debconf information
debug3: oom_adjust_restore
debug1: Set /proc/self/oom_score_adj to 0
debug1: rexec start in 5 out 5 newsock 5 pipe 7 sock 8
debug1: inetd sockets after dupping: 3, 3
Connection from [CLIENT IP] port [CLIENT PORT] on [SERVER IP] port 22
debug1: Client protocol version 2.0; client software version libssh2_1.8.0
debug1: no match: libssh2_1.8.0
debug1: Local version string SSH-2.0-OpenSSH_7.9p1 Debian-10+deb10u2
debug2: fd 3 setting O_NONBLOCK
debug3: ssh_sandbox_init: preparing seccomp filter sandbox
debug2: Network child is on pid 20979
debug3: preauth child monitor started
debug3: privsep user:group 106:65534 [preauth]
debug1: permanently_set_uid: 106/65534 [preauth]
debug3: ssh_sandbox_child: setting PR_SET_NO_NEW_PRIVS [preauth]
debug3: ssh_sandbox_child: attaching seccomp filter program [preauth]
debug1: list_hostkey_types: 
rsa-sha2-512,rsa-sha2-256,ssh-rsa,ecdsa-sha2-nistp256,ssh-ed25519 [preauth]
debug3: send packet: type 20 [preauth]
debug1: SSH2_MSG_KEXINIT sent [preauth]
debug3: receive packet: type 20 [preauth]
debug1: SSH2_MSG_KEXINIT received [preauth]
debug2: local server KEXINIT proposal [preauth]
debug2: KEX algorithms: 
curve25519-sha256,curve25519-sha...@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512,diffie-hellman-group14-sha256,diffie-hellman-group14-sha1
 [preauth]
debug2: host key algorithms: 
rsa-sha2-512,rsa-sha2-256,ssh-rsa,ecdsa-sha2-nistp256,ssh-ed25519 [preauth]
debug2: ciphers ctos: 
chacha20-poly1...@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-...@openssh.com,aes256-...@openssh.com
 [preauth]
debug2: ciphers stoc: 
chacha20-poly1...@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-...@openssh.com,aes256-...@openssh.com
 [preauth]
debug2: MACs ctos: 
umac-64-...@openssh.com,umac-128-...@openssh.com,hmac-sha2-256-...@openssh.com,hmac-sha2-512-...@openssh.com,hmac-sha1-...@openssh.com,umac...@openssh.com,umac-...@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1
 [preauth]
debug2: MACs stoc: 
umac-64-...@openssh.com,umac-128-...@openssh.com,hmac-sha2-256-...@openssh.com,hmac-sha2-512-...@openssh.com,hmac-sha1-...@openssh.com,umac...@openssh.com,umac-...@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1
 [preauth]
debug2: compression ctos: none,z...@openssh.com [preauth]
debug2: compression stoc: none,z...@openssh.com [preauth]
debug2: languages ctos:  [preauth]
debug2: languages stoc:  [preauth]
debug2: first_kex_follows 0  [preauth]
debug2: reserved 0  [preauth]
debug2: peer client KEXINIT proposal [preauth]
debug2: KEX algorithms: 
diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
 [preauth]
debug2: host key algorithms: ssh-rsa,ssh-dss [preauth]
debug2: ciphers ctos: 
aes128-ctr,aes192-ctr,aes256-ctr,aes256-cbc,rijndael-...@lysator.liu.se,aes192-cbc,aes128-cbc,blowfish-cbc,arcfour128,arcfour,cast128-cbc,3des-cbc
 [preauth]
debug2: ciphers stoc: 
aes128-ctr,aes192-ctr,aes256-ctr,aes256-cbc,rijndael-...@lysator.liu.se,aes192-cbc,aes128-cbc,blowfish-cbc,arcfour128,arcfour,cast128-cbc,3des-cbc
 [preauth]
debug2: MACs ctos: 

Bug#946035: Request fo sponsor to uplad python-jsonrpc-server

[Pablo Mestre]

Hi

This packages is already done but I need some DD upload the pkg.

https://salsa.debian.org/elMor3no-guest/python-jsonrpc-server

Regards,

Pablo

-- 
  ⢀⣴⠾⠻⢶⣦⠀  Pablo Mestre Drake
  ⣾⠁⢠⠒⠀⣿⡁  --
  ⢿⡄⠘⠷⠚⠋   https://debian.org
  ⠈⠳⣄  Debian, the universal operating system.

Bug#968603: memcached should enable TLS by default

[Chris Lamb]

Hi Tomas,

> debian unstable. But unfortunately i do not have a powerful
> debian machine so maybe i do not encounter some race condition
> that you do.

(Out of interest, why do you believe it is a race condition?)


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org  chris-lamb.co.uk
   `-

Bug#968620:

[Francisco M Neto]

Control: retitle 968620 "ITA: wiki2beamer -- Tool to create LaTeX beamer
presentations in wiki syntax"
-- 
[]'s,

Francisco M Neto 
www.fmneto.com

3E58 1655 9A3D 5D78 9F90
CFF1 D30B 1694 D692 FBF0


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

Bug#968620:

[Francisco M Neto]

Control: owner -1 !
-- 
[]'s,

Francisco M Neto 
www.fmneto.com

3E58 1655 9A3D 5D78 9F90
CFF1 D30B 1694 D692 FBF0


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

Bug#925358: qemu-user-static: mis-emulates something to do with process/signal handling

[Thorsten Glaser]

Version: 1:5.1+dfsg-4

On Sun, 10 May 2020, Michael Tokarev wrote:

> ( https://bugs.debian.org/925358 )

> Can we check please if the issue is still present with qemu 5.0?
> Lots of changes has been made in qemu-user emulation..

It does:

tglase@tglase:~ $ tar xaf 925358.txz   # attachment from Message #47
tglase@tglase:~ $ cd 925358
tglase@tglase:~/925358 $ ll bin/
total 992
-rwxr-xr-x 1 tglase tglase 1014688 25. Okt 2019  mksh*
tglase@tglase:~/925358 $ file bin/mksh
bin/mksh: ELF 32-bit MSB executable, Motorola m68k, 68020, version 1 (SYSV), 
statically linked, BuildID[sha1]=e648be88d597dadd2481ab324cd673fe961ceac4, with 
debug_info, not stripped
tglase@tglase:~/925358 $ bin/mksh -c '/bin/echo foo; echo bar'
foo
_

Here it hangs.

While my host is x32, I have qemu-user-static:i386 installed,
so this is reproducible on release architectures.

bye,
//mirabilos
-- 
«MyISAM tables -will- get corrupted eventually. This is a fact of life. »
“mysql is about as much database as ms access” – “MSSQL at least descends
from a database” “it's a rebranded SyBase” “MySQL however was born from a
flatfile and went downhill from there” – “at least jetDB doesn’t claim to
be a database”  ‣‣‣ Please, http://deb.li/mysql and MariaDB, finally die!

Bug#970017: README.Debian refers to the obsolete AllowSupplementaryGroups option for clamav-daemon

[Brian May]

Charles Goyard  writes:

> Please find attached a patch that updates the documentation with this
> respect.

Thanks. Now uploaded new version.
-- 
Brian May 

Bug#912889: tinyca: Depends on libgtk2-perl, that won't be part of Bullseye

[Christoph Ulrich Scholler]

It appears that porting TinyCA to Gtk3 is doable and I have a working
version. Before publishing the code on Salsa I'd like to clean it up a
bit, though. I hope to get that done in the next week.

Bug#859140: /usr/bin/xdg-open[938]: : can't execute: Is a directory

[Nicholas Guriev]

On Thu, 30 Mar 2017 21:37:42 +0200 Thorsten Glaser  wrote:
> tglase@tglase-nb:~ $ xdg-open http://www.mirbsd.org/
> /usr/bin/xdg-open[938]: : can't execute: Is a directory
> 
> It still _works_ as is, but this error message is weird.

It seems you have a broken .desktop file which causes this error message. I do
not think the issue should be fixed in the xdg-open utility if present here.



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

Bug#969355: cups-browsed.service Hangs on Shutdown

[Jonathan Rubenstein]

Control: severity -1 critical

I am upgrading this bug to critical since it is a bug that halts the 
shutdown procedure, and cups-browsed is rank #1116 on 
popularity-contest's inst rank https://popcon.debian.org/by_inst.gz


Please excuse me if this is an incorrect action.

Bug#970346: undertow: should not be part of Debian 11

[Markus Koschany]

Source: undertow
Severity: normal
Tags: security
X-Debbugs-Cc: Debian Security Team 

I believe we should remove undertow from testing again for the same
reasons as last time. Although the package is up-to-date no other
package in Debian (except syncany in experimental) is currently using
it. Undertow would be an essential requirement if someone wanted to
introduce the Wildfly application server to Debian.

https://bugs.debian.org/752018

There was apparently some interest in the past but no progress has
been made so far. Since we already have two excellent alternatives in
Debian, tomcat and jetty, maintaining yet another Java web server in
Debian stable releases (without any reverse-dependencies) does not seem to be
a good way to use our resources.

I still intend to maintain undertow in unstable, perhaps someday there will
be a contributor who wants to complete the work and maintain undertow
in stable. Compared to tomcat and jetty, I also find the information
policy of security vulnerabilites disappointing which makes
maintaining undertow in stable releases unnecessarily difficult.

Markus

Bug#969559: curl segmentation fauls on any https URL

[Bruce Momjian,,,]

On Fri, Sep 11, 2020 at 06:28:20PM +0200, Bernhard Übelacker wrote:
> Dear Maintainer, hello Bruce Momjian,
> with the last informations the issue is perfectly reproducible.
> 
> It looks like a use after free caused by statically stored
> function pointers in libengine-pkcs11-openssl / libp11.
> 
> That led to following upstream bug:
>   https://github.com/OpenSC/libp11/issues/328
> 
> This got fixed in this commit:
>   
> https://github.com/OpenSC/libp11/commit/e64496a198d4d2eb0310a22dc21be8b81367d319
> 
> This commit is not yet included in an upstream release tag.
> Therefore this error is also visible in current testing.
> 
> I hope it is ok to reassign to libengine-pkcs11-openssl.

Yes, thank you for researching this and closing it.

-- 
  Bruce Momjian  https://momjian.us
  EnterpriseDB https://enterprisedb.com

  The usefulness of a cup is in its emptiness, Bruce Lee

Bug#969259: python3-regex: Please upload a new upstream release (needed for black)

[Antonio Terceiro]

On Mon, Sep 14, 2020 at 05:27:20PM -0400, Sandro Tosi wrote:
> > I need a more recent black, so I tried this. I imported the new upstream
> > release in the git repository, and noted that it was doing two builds
> > for python3 and two for python3-dbg. My changes are pushed to the
> > repository.
> 
> i would have preferred if you didnt change the repo and just pinged
> this bug. now i need to backtrace what you did, which is not a good
> use of my time.

I'm sorry for the inconvenience. If you want I can revert all my work
and save you the burden of reviewing my changes.


signature.asc
Description: PGP signature

Bug#964949: Cannot open files beginning with a dash ('-')

[Nicholas Guriev]

Control: severity -1 wishlist

On Mon, 13 Jul 2020 10:50:34 +0200 Enrico Zini  wrote:
> There seems to be no way to use it to open a file whose name begins with
> a dash:
> 
> $ sh -x `which xdg-open` -test.pdf

Prepend filename with dot-slash: xdg-open ./-test.pdf

> I also tried the usual double-dash approach, which doesn't seem to be
> supported:
> 
> $ sh -x `which xdg-open` -- -test.pdf

On the other hand, it might make sense to implement a special double-dash option
to get consistent behavior between various command line utilities.



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

Bug#970345: cl-usocket: autopkgtests depend on unrestricted access to the internet

[Michael Hudson-Doyle]

Package: cl-usocket
Version: 0.8.3-1
Severity: normal

Dear Maintainer,

The package's tests are now run during autopkgtests but they make
connections to internet hosts (specifically "common-lisp.net") which
does not work on the Ubuntu autopkgtest infrastructure.

Cheers,
mwh

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

Kernel: Linux 5.4.0-47-generic (SMP w/8 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_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 cl-usocket depends on:
pn  cl-split-sequence  

Versions of packages cl-usocket recommends:
pn  cl-rt  

cl-usocket suggests no packages.

Bug#959518: apt-transport-http: Repeatable 'Undetermined Error' during package download from snapshot.debian.org

[Johannes Schauer]

Quoting Julian Andres Klode (2020-09-14 21:49:15)
> >  - allow to specify a maximum bytes per second value for downloads (this
> >  has the largest effect if set low enough)
> 
> That's Acquire::http::Dl-Limit
> 
> >  - allow to set an option that makes apt automatically retry when a 
> > transient
> >error occurs
> 
> That's Acquire::Retries - well it retries in general I suppose. It misses a 
> bits
> like DNS rotation, SRV rotation, but the goal is that this becomes the default
> sometime next year, with 3 retries per URL or something to work with flaky 
> mirrors.
> 
> > 
> >  - allow to set custom resolve addresses for domains like done in my code 
> > below
> 
> That we don't have. Gotta use /etc/hosts
> 
> Anyway, if you know you use snapshots.d.o, and it's flaky, maybe make use of
> Dl-Limit and Retries option?

I stand corrected. I think apt already offers all the tools needed to use
snapshot.debian.org. Setting Acquire::http::Dl-Limit indeed does the job. And
the option is even documented in apt-transport-http(1)

Thanks!

cheers, josch

signature.asc
Description: signature

Bug#969608: makeblastdb 2.10.x on 32-bit architectures

[Aaron M. Ucko]

Étienne Mollier  writes:

> I worked within an arm64 schroot built with sbuild-createchroot,
> on a native amd64 machine.

Thanks for clarifying.  AFAICT, this environment imposes a tighter limit
than native arm64 hardware, and versions 2.10.0-1 and 2.10.0-3 both hit
it.  Rough bisection via the BLASTDB_LMDB_MAP_SIZE environment variable
gives an empirical limit of 20,073,607,168 bytes (4,900,783 4K pages).
This number isn't particularly round, so it presumably reflects what
remains of some cumulative limit.  As such, the default should probably
be at most 20,000,000,000 bytes (4,882,812½ pages ;-) to build in more
of a margin.  That's 1/15 upstream's default, but with any luck should
be plenty in practice, so I'm open to making that adjustment.  Also,
this reduced limit would still be well more than we (can) allow on
32-bit architectures, which is in turn much more than upstream's trunk
allows on Windows:

https://www.ncbi.nlm.nih.gov/IEB/ToolBox/CPP_DOC/lxr/source/include/objtools/blast/seqdb_writer/writedb_lmdb.hpp#L51

-- 
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu

Bug#970333: abseil: autopkgtest needs update for new version of cmake: warning on stderr

[Benjamin Barenblat]

Control: owner 970333 !
Control: tags 970333 + pending upstream fixed-upstream
Control: forwarded 970333 https://github.com/abseil/abseil-cpp/issues/668

This is a bug in upstream’s CMake support. I’ll patch in their fix
(https://github.com/abseil/abseil-cpp/commit/68494aae959dfbbf781cdf03a988d2f5fc7e4802).

Bug#969259: python3-regex: Please upload a new upstream release (needed for black)

[Sandro Tosi]

> I need a more recent black, so I tried this. I imported the new upstream
> release in the git repository, and noted that it was doing two builds
> for python3 and two for python3-dbg. My changes are pushed to the
> repository.

i would have preferred if you didnt change the repo and just pinged
this bug. now i need to backtrace what you did, which is not a good
use of my time.

-- 
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
Twitter: https://twitter.com/sandrotosi

Bug#969259: python3-regex: Please upload a new upstream release (needed for black)

[Antonio Terceiro]

Hello Sandro,

On Sun, Aug 30, 2020 at 11:42:13AM +0200, Sylvestre Ledru wrote:
> Package: python3-regex
> Version: 0.1.20190819-2+b1
> Severity: wishlist
> 
> Dear Maintainer,
> 
> black 20.8 needs regex>=2020.1.8. We have 20190819 in the archive.
> 
> Many more recent version can be found here:
> https://pypi.org/project/regex/
> 
> Even if the Debian watch says "0.1.20191220" here:
> https://tracker.debian.org/pkg/python-regex
> 
> Current failure:
> 
> No local packages or working download links found for regex>=2020.1.8
> error: Could not find suitable distribution for 
> Requirement.parse('regex>=2020.1.8')
> 

I need a more recent black, so I tried this. I imported the new upstream
release in the git repository, and noted that it was doing two builds
for python3 and two for python3-dbg. My changes are pushed to the
repository.

I also changed the package to not build an explicit -dbg package, and
use the autogenrated -dbgsym package, but I'm not sure that this is
correct. What do you think?

The generated packages look like this:

python3-regex-dbgsym_0.1.20200714-1_amd64.deb
-

drwxr-xr-x root/root 0 2020-09-14 15:27 ./
drwxr-xr-x root/root 0 2020-09-14 15:27 ./usr/
drwxr-xr-x root/root 0 2020-09-14 15:27 ./usr/lib/
drwxr-xr-x root/root 0 2020-09-14 15:27 ./usr/lib/debug/
drwxr-xr-x root/root 0 2020-09-14 15:27 ./usr/lib/debug/.build-id/
drwxr-xr-x root/root 0 2020-09-14 15:27 ./usr/lib/debug/.build-id/ea/
-rw-r--r-- root/root473912 2020-09-14 15:27 
./usr/lib/debug/.build-id/ea/9eda7f458c20c50898cef7a953871318973d1f.debug
drwxr-xr-x root/root 0 2020-09-14 15:27 ./usr/share/
drwxr-xr-x root/root 0 2020-09-14 15:27 ./usr/share/doc/
lrwxrwxrwx root/root 0 2020-09-14 15:27 
./usr/share/doc/python3-regex-dbgsym -> python3-regex

python3-regex_0.1.20200714-1_amd64.deb
--
drwxr-xr-x root/root 0 2020-09-14 15:27 ./
drwxr-xr-x root/root 0 2020-09-14 15:27 ./usr/
drwxr-xr-x root/root 0 2020-09-14 15:27 ./usr/lib/
drwxr-xr-x root/root 0 2020-09-14 15:27 ./usr/lib/python3/
drwxr-xr-x root/root 0 2020-09-14 15:27 ./usr/lib/python3/dist-packages/
drwxr-xr-x root/root 0 2020-09-14 15:27 
./usr/lib/python3/dist-packages/regex/
-rw-r--r-- root/root65 2020-09-14 15:27 
./usr/lib/python3/dist-packages/regex/__init__.py
-rw-r--r-- root/root738080 2020-09-14 15:27 
./usr/lib/python3/dist-packages/regex/_regex.cpython-38-x86_64-linux-gnu.so
-rw-r--r-- root/root140155 2020-09-14 15:27 
./usr/lib/python3/dist-packages/regex/_regex_core.py
-rw-r--r-- root/root 31907 2020-09-14 15:27 
./usr/lib/python3/dist-packages/regex/regex.py
-rw-r--r-- root/root213182 2020-09-14 15:27 
./usr/lib/python3/dist-packages/regex/test_regex.py
drwxr-xr-x root/root 0 2020-09-14 15:27 
./usr/lib/python3/dist-packages/regex-2020.7.14.egg-info/
-rw-r--r-- root/root 47570 2020-09-14 15:27 
./usr/lib/python3/dist-packages/regex-2020.7.14.egg-info/PKG-INFO
-rw-r--r-- root/root 1 2020-09-14 15:27 
./usr/lib/python3/dist-packages/regex-2020.7.14.egg-info/dependency_links.txt
-rw-r--r-- root/root 6 2020-09-14 15:27 
./usr/lib/python3/dist-packages/regex-2020.7.14.egg-info/top_level.txt
drwxr-xr-x root/root 0 2020-09-14 15:27 ./usr/share/
drwxr-xr-x root/root 0 2020-09-14 15:27 ./usr/share/doc/
drwxr-xr-x root/root 0 2020-09-14 15:27 ./usr/share/doc/python3-regex/
-rw-r--r-- root/root131554 2020-09-14 15:27 
./usr/share/doc/python3-regex/Features.html
-rw-r--r-- root/root 10480 2020-09-14 15:27 
./usr/share/doc/python3-regex/Features.rst.gz
-rw-r--r-- root/root 10480 2020-09-14 15:27 
./usr/share/doc/python3-regex/README.rst.gz
-rw-r--r-- root/root  7589 2020-09-14 15:27 
./usr/share/doc/python3-regex/UnicodeProperties.rst.gz
-rw-r--r-- root/root  2653 2020-09-14 15:27 
./usr/share/doc/python3-regex/changelog.Debian.gz
-rw-r--r-- root/root  2805 2020-09-14 15:27 
./usr/share/doc/python3-regex/copyright


signature.asc
Description: PGP signature

Bug#970337: fonts-open-sans: warning when purging the package

[Jean-Marc]

Apparently, there are already other bugs related to similar problems.

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=897040
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=898522
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=920928

These 3 have references to each other.

This one has not : https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=909541

And this bug is being worked on:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=897040

Regards,

Jean-Marc 
https://6jf.be/keys/ED863AD1.txt
https://6jf.be/keys/ED0B8558.txt


pgpZHxB5UhTcJ.pgp
Description: PGP signature

Bug#970329: mdadm: exit gracefully when md is not a block device

[Felix Lechner]

Hi Martin,

> This is a separate bug which would also deserves fixing (at least
> by a printing an error message instead of crash)

How does the attached patch look to you, please?

Kind regards
Felix Lechner
Description: Exit gracefully when md device not found
Author: Felix Lechner 
Bug-Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=970329
Forwarded: no
---
This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
--- a/Monitor.c
+++ b/Monitor.c
@@ -477,8 +477,14 @@ static int check_array(struct state *st,
 	if (fd < 0)
 		goto disappeared;
 
-	if (st->devnm[0] == 0)
-		strcpy(st->devnm, fd2devnm(fd));
+	if (st->devnm[0] == 0) {
+		char *found = fd2devnm(fd);
+		if (!found) {
+			alert("DeviceDisappeared", dev, NULL, ainfo);
+			goto out;
+		}
+		strcpy(st->devnm, found);
+	}
 
 	for (mse2 = mdstat; mse2; mse2 = mse2->next)
 		if (strcmp(mse2->devnm, st->devnm) == 0) {

Bug#959518: apt-transport-http: Repeatable 'Undetermined Error' during package download from snapshot.debian.org

[James Addison]

Package: snapshot.debian.org
Followup-For: Bug #959518
X-Debbugs-Cc: j...@jp-hosting.net

Understood.  The environment I'd like to get this working for is based on 
Debian stable, so we might be at an impasse unless I can compile the latest apt 
sources using buster.  I'm making progress on that and attempting to resolve 
some time64-related compilation issues (unrelated to this bug).

I'd like to keep this issue open against the snapshot.debian.org meta package 
since that seems a good way to resolve the problem assuming it is purely 
server-side.

Given the discussion so far would it make sense if I use BTS to attempt to 
(re)assign this bug from packages {apt,snapshot.debian.org} -> 
{snapshot.debian.org}?

Bug#970339: libobject-pad-perl breaks libtickit-widget-tabbed-perl autopkgtest: Failed test 'all modules in libtickit-widget-tabbed-perl pass the syntax check'

[gregor herrmann]

Control: reassign -1 libobject-pad-perl 0.32-1
Control: reassign 970338 libobject-pad-perl 0.32-1
Control: merge -1 970338
Control: affects -1 libtickit-widget-tabbed-perl libtickit-console-perl
Control: forwarded -1 https://rt.cpan.org/Public/Bug/Display.html?id=133190

On Mon, 14 Sep 2020 22:00:02 +0200, Paul Gevers wrote:
> With a recent upload of libobject-pad-perl the autopkgtest of
> libtickit-widget-tabbed-perl fails in testing when that autopkgtest is
> run with the binary packages of libobject-pad-perl from unstable. It
> passes when run with only packages from testing. In tabular form:

Thanks for the bug report. Looking at the upstream tickets, I think
this is Object::Pad's fault and probably the same problem.

Tracked upstream at https://rt.cpan.org/Public/Bug/Display.html?id=133190
(or maybe (also) https://rt.cpan.org/Public/Bug/Display.html?id=133258 )
 

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: Neil Young: Alabama


signature.asc
Description: Digital Signature

Bug#970228: nemo: Can no longer copy files

[Simon McVittie]

On Mon, 14 Sep 2020 at 09:09:34 +0100, Simon McVittie wrote:
> If you run it as `strace -efile nemo`, does the bug still happen? What
> output does it produce?

Ugh, I hadn't realised nemo is single-instance.

Please see whether you can reproduce this bug by installing libglib2.0-bin
and running

gio copy /path/to/some/file /path/to/other/file

which is independent of any particular GUI file managers.

If that command exhibits the same bug, then try

strace gio copy /path/to/some/file /path/to/other/file

and see what that produces.

Or try killing/exiting all nemo processes, or using a different GTK file
manager like thunar or nautilus. The goal is to get some output from
strace that only appears when you actually try (and presumably fail)
to copy the file, and refers specifically to the file you are trying to
copy. I'm a lot less interested in what happens during startup.

> I was unable to reproduce this bug: nemo copies files successfully from
> btrfs to btrfs for me.

I tried adding a ZFS volume to a test VM and I can't reproduce the bug
there either, with either nemo or `gio copy`.

On https://gitlab.gnome.org/GNOME/glib/-/issues/2189 there is some
suggestion that this might happen when copying from a read-only filesystem,
but I haven't been able to reproduce the bug that way either.

Are the filesystem you are copying from, and the filesystem you are
copying to, mounted with any non-default options? (For example, ro,
relatime or noatime.)

I have some vague ideas of places in GLib to try patching, but fixing a
bug without being able to reproduce it is a really slow process, so I
won't be able to prioritize it.

smcv

Bug#970343: guile-3.0: possibly miscompilation of md5.scm in guile-lib

[Göran Weinholt]

Package: guile-3.0
Version: 3.0.4-1.2
Severity: normal

Hello!

I'm working on updating guile-lib to guile 3.0 and found that one of
the tests doesn't pass. The md5 library appears to be miscompiled.

There's a loop in general-read-string!/partial that never terminates.
Change (+ read 1) to (- read -1) and suddenly it does terminate. The
only way that this makes sense to me is if the loop with (+ read 1) is
miscompiled.

(Unfortunately this workaround isn't enough, there is later a
mysterious stack overflow as well, that wasn't present with Guile
2.2).

<#part type="text/x-diff" filename="/tmp/guile-lib-workaround.diff" 
disposition=inline>
<#/part>


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

Kernel: Linux 5.8.0-1-amd64 (SMP w/32 CPU threads)
Locale: LANG=en_DK.UTF-8, LC_CTYPE=en_DK.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to en_DK.UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages guile-3.0 depends on:
ii  guile-3.0-libs  3.0.4-1.2

guile-3.0 recommends no packages.

Versions of packages guile-3.0 suggests:
pn  guile-3.0-doc  

-- no debconf information

Bug#952026: fixed in node-handlebars

[Pirate Praveen]

Control: reassign -1 node-handlebars
Control: affects -1 ruby-handlebars-assets
Control: found -1 3:4.7.6-2

> I debugged this case and looked into the FTBFS of 
ruby-handlebas-assets. I
> checked out the upstream git repository and it tests just fine even 
when I
> raise the haml and rake gem versions to match the ones in Debian. 
But it fails

> with exactly the same error if I replace the javascript files in
> vendor/assets/javascript by the javascript files provided by 
libjs-handlebars.
> So there seems to be some incompatbility or difference with these 
files
> actually causing the build issue (and I don't believe it's the 
version

> difference of 4.7.2 vs 4.7.3).
> Regards, Daniel

Hi Daniel,

Thanks for this information. It gave me an idea to diff between the two 
files and I found the embedded handlebars files were using 'this' and 
our builds were using 'window'.


@@ -33,5178 +7,476 @@ THE SOFTWARE.
   exports["Handlebars"] = factory();
   else
   root["Handlebars"] = factory();
-})(this, function() {
+})(window, function() {
return /**/ (function(modules) { // webpackBootstrap
/**/ // The module cache
/**/ var installedModules = {};

Looking around I found  webpack option to pass globalObject: 'this' to 
match this format. This option allows the code to run same code on both 
node and browser.


Fixed node-handlebars and will upload now.

Bug#970342: sapphire FTCBFS: does not pass cross tools to make

[Helmut Grohne]

Source: sapphire
Version: 0.15.8-9.1
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

sapphire fails to cross build from source, because it does not pass
cross tools to make. The easiest way of fixing that would be using
dh_auto_build if sapphire's Makefile were using the standard variables
with the standard meanings. Unfortunately, it uses CC, which is normally
used for the C compiler, for a C++ compiler and that's not what
dh_auto_build passes there. The attached patch makes sapphire cross
buildable anyhow. Please consider applying it.

Helmut
diff -u sapphire-0.15.8/debian/changelog sapphire-0.15.8/debian/changelog
--- sapphire-0.15.8/debian/changelog
+++ sapphire-0.15.8/debian/changelog
@@ -1,3 +1,11 @@
+sapphire (0.15.8-9.2) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: Let dh_auto_build pass cross tools to make, but pass a C++
+compiler via CC. (Closes: #-1)
+
+ -- Helmut Grohne   Mon, 14 Sep 2020 22:21:11 +0200
+
 sapphire (0.15.8-9.1) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -u sapphire-0.15.8/debian/rules sapphire-0.15.8/debian/rules
--- sapphire-0.15.8/debian/rules
+++ sapphire-0.15.8/debian/rules
@@ -23,10 +23,7 @@
 build: build-stamp
 build-stamp:
dh_testdir
-
-   # compile the package
-   $(MAKE) $(COMPILER_FLAGS)
-
+   dh_auto_build -- CC='$$(CXX)' $(COMPILER_FLAGS)
/usr/bin/docbook-to-man debian/sapphire.sgml > debian/sapphire.1
 
touch build-stamp

Bug#959518: apt-transport-http: Repeatable 'Undetermined Error' during package download from snapshot.debian.org

[James Addison]

Package: snapshot.debian.org
Followup-For: Bug #959518
X-Debbugs-Cc: j...@jp-hosting.net

The issue appears reproducible at the moment with apt 1.8.2.1 compiled from 
source and the 'x.tar' configuration provided earlier.

# apt source directory, post-build
$ cmdline/apt -o Dir=$PWD/x -o Dir::Bin::Methods=$PWD/methods update && \
$ cmdline/apt -o Dir=$PWD/x -o Dir::Bin::Methods=$PWD/methods install -y 
openjdk-11-jdk

...

Get:261 http://snapshot.debian.org/archive/debian-security/20200502T085134Z 
buster/updates/main amd64 openjdk-11-jdk-headless amd64 11.0.7+10-3~deb10u1 
[215 MB]
Err:261 http://snapshot.debian.org/archive/debian-security/20200502T085134Z 
buster/updates/main amd64 openjdk-11-jdk-headless amd64 11.0.7+10-3~deb10u1
  Undetermined Error [IP: 193.62.202.27 80]

This has occurred for a couple of different server IP addresses, including 
185.17.185.185.

Bug#970341: rampler: autopkgtest failure on arm64:

[Paul Gevers]

Source: rampler
Version: 1.1.1-2
X-Debbugs-CC: debian...@lists.debian.org
Severity: serious
User: debian...@lists.debian.org
Usertags: fails-always

Dear maintainer(s),

You recently added an autopkgtest to your package rampler, great.
However, it fails on arm64. Currently this failure is blocking the
migration to testing [1]. Can you please investigate the situation and
fix it?

I copied some of the output at the bottom of this report. The test could
be a bit more verbose?

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

Paul

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

https://ci.debian.net/data/autopkgtest/testing/amd64/r/rampler/6794192/log.gz

autopkgtest [03:14:35]: test run-unit-test: [---
Preparation
Passed

Test 1
autopkgtest [03:14:35]: test run-unit-test: ---]



signature.asc
Description: OpenPGP digital signature

Bug#970340: rna-star: autopkgtest regression: --genomeSAindexNbases 8 is too large for the genome size=99940

[Paul Gevers]

Source: rna-star
Version: 2.7.5c+dfsg-1
X-Debbugs-CC: debian...@lists.debian.org
Severity: serious
User: debian...@lists.debian.org
Usertags: regression

Dear maintainer(s),

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

   passfail
rna-star   from testing2.7.5c+dfsg-1
all others from testingfrom testing

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

Currently this regression is blocking the migration to testing [1]. Can
you please investigate the situation and fix it?

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

Paul

[1] https://qa.debian.org/excuses.php?package=rna-star

https://ci.debian.net/data/autopkgtest/testing/amd64/r/rna-star/7008363/log.gz

autopkgtest [20:08:01]: test command1: [---
Sep 13 20:08:01 . started STAR run
Sep 13 20:08:01 ... starting to generate Genome files
Sep 13 20:08:01 . processing annotations GTF
! WARNING: --genomeSAindexNbases 8 is too large for the genome
size=99940, which may cause seg-fault at the mapping step. Re-run genome
generation with recommended --genomeSAindexNbases 7
Sep 13 20:08:01 ... starting to sort Suffix Array. This may take a long
time...
Sep 13 20:08:01 ... sorting Suffix Array chunks and saving them to disk...
Sep 13 20:08:01 ... loading chunks from disk, packing SA...
Sep 13 20:08:01 ... finished generating suffix array
Sep 13 20:08:01 ... generating Suffix Array index
Sep 13 20:08:01 ... completed Suffix Array index
Sep 13 20:08:01 ... writing Genome to disk ...
Sep 13 20:08:01 ... writing Suffix Array to disk ...
Sep 13 20:08:01 ... writing SAindex to disk
Sep 13 20:08:01 . finished successfully
Sep 13 20:08:01 . started STAR run
Sep 13 20:08:01 . loading genome
Sep 13 20:08:01 . started mapping
Sep 13 20:08:02 . finished mapping
Sep 13 20:08:02 . finished successfully
autopkgtest [20:08:02]: test command1: ---]
autopkgtest [20:08:02]: test command1:  - - - - - - - - - - results - -
- - - - - - - -
command1 FAIL stderr: ! WARNING: --genomeSAindexNbases 8
is too large for the genome size=99940, which may cause seg-fault at the
mapping step. Re-run genome generation with recommended
--genomeSAindexNbases 7



signature.asc
Description: OpenPGP digital signature

Bug#963620: nanolyse_1.1.1-1_amd64.changes REJECTED

[Andreas Tille]

Hi Thorsten,

On Sun, Sep 13, 2020 at 05:00:08PM +, Thorsten Alteholz wrote:
> 
> LICENSE says GPL-3, setup.py says MIT license. But none says GPL-3+.
> Maybe upstream can help here ..

I'm pretty sure GPL-3 is intended to be used for all files but I asked
for clarification in

https://github.com/wdecoster/nanolyse/issues/11

Thanks a lot for thorough checking
Andreas.

-- 
http://fam-tille.de

Bug#970339: libobject-pad-perl breaks libtickit-widget-tabbed-perl autopkgtest: Failed test 'all modules in libtickit-widget-tabbed-perl pass the syntax check'

[Paul Gevers]

Source: libobject-pad-perl, libtickit-widget-tabbed-perl
Control: found -1 libobject-pad-perl/0.32-1
Control: found -1 libtickit-widget-tabbed-perl/0.023-1
Severity: serious
Tags: sid bullseye
X-Debbugs-CC: debian...@lists.debian.org
User: debian...@lists.debian.org
Usertags: breaks needs-update

Dear maintainer(s),

With a recent upload of libobject-pad-perl the autopkgtest of
libtickit-widget-tabbed-perl fails in testing when that autopkgtest is
run with the binary packages of libobject-pad-perl from unstable. It
passes when run with only packages from testing. In tabular form:

 passfail
libobject-pad-perl   from testing0.32-1
libtickit-widget-tabbed-perl from testing0.023-1
all others   from testingfrom testing

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

Currently this regression is blocking the migration of
libobject-pad-perl to testing [1]. Due to the nature of this issue, I
filed this bug report against both packages. Can you please investigate
the situation and reassign the bug to the right package?

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

Paul

[1] https://qa.debian.org/excuses.php?package=libobject-pad-perl

https://ci.debian.net/data/autopkgtest/testing/amd64/libt/libtickit-widget-tabbed-perl/7009729/log.gz


Test Summary Report
---
/usr/share/pkg-perl-autopkgtest/runtime-deps-and-recommends.d/syntax.t
(Wstat: 256 Tests: 4 Failed: 1)
  Failed test:  4
  Non-zero exit status: 1
Files=1, Tests=4,  0 wallclock secs ( 0.01 usr  0.01 sys +  0.18 cusr
0.03 csys =  0.23 CPU)
Result: FAIL



signature.asc
Description: OpenPGP digital signature

Bug#970228: nemo: Can no longer copy files

[J Rowan]

On Mon, 14 Sep 2020 12:16:05 +0200 =?UTF-8?Q?Holger_Schr=c3=b6der?=
 wrote:
> Am 14.09.20 um 11:31 schrieb Simon McVittie:
> > Control: retitle -1 nemo: Can no longer copy files on zfs since
> > GLib 2.66.x Control: retitle 970263 glib2.0: nemo can no longer
> > copy files on zfs since 2.66.x
> >
> > On Mon, 14 Sep 2020 at 11:19:04 +0200, Holger Schröder wrote:
> >> I have zfs only.
> > zfs implemented how? The zfs-dkms kernel module, or zfs-fuse?
> 
> 
> zfs-dkms, zfs-initramfs    (zfs rootfs)
> 
> https://github.com/openzfs/zfs
> 
> As said, there is only zfs and no other file system.
> 
> 
> dpkg -l | grep zfs
> ii  libzfs2linux 0.8.4-2 amd64    
> OpenZFS filesystem library for Linux
> ii  zfs-dkms 0.8.4-2 all  OpenZFS 
> filesystem kernel modules for Linux
> ii  zfs-initramfs 0.8.4-2 all  
> OpenZFS root filesystem capabilities for Linux - initramfs
> ii  zfsutils-linux 0.8.4-2 amd64    
> command-line tools to manage OpenZFS filesystems
> 

I'm seeing this with Nautilus and Thunar on sid. Source and destination
on Samba shares on ext4. No problem copying on local hard drive. 

Running Nautilus from the command line makes no difference. First
noticed today, was OK three days ago.

-- 
Joe

Bug#970338: libobject-pad-perl breaks libtickit-console-perl autopkgtest: Failed test 'all modules in libtickit-console-perl pass the syntax check'

[Paul Gevers]

Source: libobject-pad-perl, libtickit-console-perl
Control: found -1 libobject-pad-perl/0.32-1
Control: found -1 libtickit-console-perl/0.09-1
Severity: serious
Tags: sid bullseye
X-Debbugs-CC: debian...@lists.debian.org
User: debian...@lists.debian.org
Usertags: breaks needs-update

Dear maintainer(s),

With a recent upload of libobject-pad-perl the autopkgtest of
libtickit-console-perl fails in testing when that autopkgtest is run
with the binary packages of libobject-pad-perl from unstable. It passes
when run with only packages from testing. In tabular form:

   passfail
libobject-pad-perl from testing0.32-1
libtickit-console-perl from testing0.09-1
all others from testingfrom testing

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

Currently this regression is blocking the migration of
libobject-pad-perl to testing [1]. Due to the nature of this issue, I
filed this bug report against both packages. Can you please investigate
the situation and reassign the bug to the right package?

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

Paul

[1] https://qa.debian.org/excuses.php?package=libobject-pad-perl

https://ci.debian.net/data/autopkgtest/testing/amd64/libt/libtickit-console-perl/7008360/log.gz


Test Summary Report
---
/usr/share/pkg-perl-autopkgtest/runtime-deps-and-recommends.d/syntax.t
(Wstat: 256 Tests: 4 Failed: 1)
  Failed test:  4
  Non-zero exit status: 1
Files=1, Tests=4,  0 wallclock secs ( 0.02 usr  0.00 sys +  0.12 cusr
0.04 csys =  0.18 CPU)
Result: FAIL



signature.asc
Description: OpenPGP digital signature

Bug#970228: nemo: Can no longer copy files

[Joe]

Further info:

No problem copying the same file when logged into the host of the
shares, using mc (no GUI).

No problem copying the file via Samba from another workstation using
Unison.

Other people are not using Samba, so presumably the problem isn't with
Samba itself but the interface between graphical file managers and
Samba, and between them and zfs.

-- 
Joe

Bug#962451: auditd: Timeout during first start when auditd is installed

[von Obernitz, Daniel]

Dear maintainer,

I can confirm this bug and want to add, that the timouts also happen randomly 
at restarts of the service.

Best regards
Daniel

smime.p7s
Description: S/MIME cryptographic signature

Bug#959518: apt-transport-http: Repeatable 'Undetermined Error' during package download from snapshot.debian.org

[Julian Andres Klode]

On Mon, Sep 14, 2020 at 09:35:01PM +0200, Johannes Schauer wrote:
> Hi,
> 
> On Mon, 14 Sep 2020 18:50:44 +0200 Julian Andres Klode  
> wrote:
> > On Mon, Sep 14, 2020 at 05:18:20PM +0100, James Addison wrote:
> > > Package: snapshot.debian.org
> > > Followup-For: Bug #959518
> > > X-Debbugs-Cc: j...@jp-hosting.net
> > > 
> > > The issue appears reproducible at the moment with apt 1.8.2.1 compiled 
> > > from source and the 'x.tar' configuration provided earlier.
> > > 
> > > # apt source directory, post-build
> > > $ cmdline/apt -o Dir=$PWD/x -o Dir::Bin::Methods=$PWD/methods update && \
> > > $ cmdline/apt -o Dir=$PWD/x -o Dir::Bin::Methods=$PWD/methods install -y 
> > > openjdk-11-jdk
> > > 
> > > ...
> > > 
> > > Get:261 
> > > http://snapshot.debian.org/archive/debian-security/20200502T085134Z 
> > > buster/updates/main amd64 openjdk-11-jdk-headless amd64 
> > > 11.0.7+10-3~deb10u1 [215 MB]
> > > Err:261 
> > > http://snapshot.debian.org/archive/debian-security/20200502T085134Z 
> > > buster/updates/main amd64 openjdk-11-jdk-headless amd64 
> > > 11.0.7+10-3~deb10u1
> > >   Undetermined Error [IP: 193.62.202.27 80]
> > > 
> > > This has occurred for a couple of different server IP addresses, 
> > > including 185.17.185.185.
> > 
> > We only care about unstable for this bug. There is a whole bunch of
> > changes in http code and they won't be backported to stable releases.
> > 
> > Also, the previous comment by Alex Thiessen indicated that this is not a
> > bug in apt, but the server seems to close the connection, which means
> > there is nothing actionable here.
> > 
> > If you can produce an issue with the version of apt in unstable,
> > and it does not reproduce with wget or curl, please open a new bug report 
> > for
> > it.
> 
> I'm very familiar with snapshot.d.o from the client perspective. Julian is
> correct, that it's the server closing the connection. But that doesn't mean
> that it's not at least a wishlist bug or feature request in apt. Let me 
> explain
> a bit more.
> 
> For several projects (debrebuild, debbisect, buildprofile QA,
> bootstrap.debian.net...) I regularly interact with snapshot.d.o. Doing this
> plainly with apt is deemed to fail miserably with errors like:
> 
> # E: Failed to fetch [...]  Error reading from server. Remote end closed 
> connection
> # E: Failed to fetch [...]  Hash Sum mismatch
> # E: Failed to fetch [...]  Bad header line Bad header data
> # Err:118 [...] Connection timed out
> 
> Yes, this is because of how snapshot.d.o throttles connections. For example
> without additional measures, the following will fail:

Frankly, it should throttle connections not kill them. Generally you do that
by refusing new GET requests or sending less data per time.

> 
> $ curl 
> http://snapshot.debian.org/archive/debian/20200909T084102Z/pool/main/q/qtwebengine-opensource-src/qtwebengine-opensource-src_5.14.2+dfsg1.orig.tar.xz
>  >/dev/null
> curl: (18) transfer closed with 217347024 bytes remaining to read
> 
> There are a couple of things that can be done to work around this problem when
> using curl by adding options like:
> 
> --limit-rate=800k # this has the biggest effect
> --retry 10 --retry-connrefused
> --resolve snapshot.debian.org:80:193.62.202.27
> 
> But even those are not sufficient as snapshot.d.o will also cut the connection
> early enough such that curl will fail with "network unreachable" which is not 
> a
> transient error, so curl will not retry establishing the connection.
> 
> The only thing that reliably worked for me with snapshot.d.o was the pycurl
> based Python code at the end of this E-Mail. With that code, I can even
> download for a full day reliably from snapshot.d.o without ever having hit the
> Exception in the last line.
> 
> But as things stand, it is impossible to reliably use apt together with
> snapshot.d.o. I'm not sure how to solve this problem. One way could surely be
> to approach snapshot.d.o and ask them to somehow lift their very heavy
> throttling policies. But another way to solve this problem would be to make 
> apt
> more resilient about mirrors with heavy throttling policies. I can think of
> these wishlist bugs against apt:
> 
>  - allow to specify a maximum bytes per second value for downloads (this has
>the largest effect if set low enough)

That's Acquire::http::Dl-Limit

>  - allow to set an option that makes apt automatically retry when a transient
>error occurs

That's Acquire::Retries - well it retries in general I suppose. It misses a bits
like DNS rotation, SRV rotation, but the goal is that this becomes the default
sometime next year, with 3 retries per URL or something to work with flaky 
mirrors.

> 
>  - allow to set custom resolve addresses for domains like done in my code 
> below

That we don't have. Gotta use /etc/hosts

Anyway, if you know you use snapshots.d.o, and it's flaky, maybe make use
of Dl-Limit and Retries option?


-- 
debian developer - deb.li/jak | jak-linux.org - free 

Bug#970337: fonts-open-sans: warning when purging the package

[Jean-Marc]

Package: fonts-open-sans
Version: 1.11-1
Severity: normal

Dear Maintainer,

apt mentioned fonts-open-sans was automatically installed but not needed 
anymore.

I then ran an apt autoremove --purge.

During the purge, I got a warning because dpkg was not able to remove the 
directory /usr/share/fonts/truetype/open-sans, this directory being not empty.

Indeed, it still contained one file named .uuid:

$ ls -la /usr/share/fonts/truetype/open-sans
total 12
drwxr-xr-x  2 root root 4096 sep 14 21:30 .
drwxr-xr-x 21 root root 4096 jui 12 22:14 ..
-rw-r--r--  1 root root   36 fév 13  2020 .uuid

Maybe something to manage in one of the control files.

Regards,

Jean-Marc

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

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

Bug#970228: nemo: Can no longer copy files

[Simon McVittie]

On Mon, 14 Sep 2020 at 09:09:34 +0100, Simon McVittie wrote:
> If you run it as `strace -efile nemo`, does the bug still happen? What
> output does it produce?

>From the strace log sent by private email due to containing personal
filenames etc., statx() is basically functional on the bug reporter's
system:

openat(AT_FDCWD, "[redacted]", O_RDONLY) = 16
statx(16, "", AT_STATX_SYNC_AS_STAT|AT_EMPTY_PATH, STATX_TYPE,
  {stx_mask=STATX_TYPE|STATX_MODE|STATX_NLINK|STATX_UID|STATX_GID|
   STATX_MTIME|STATX_CTIME|STATX_INO|STATX_SIZE|STATX_BLOCKS|0x1000,
   stx_attributes=0, stx_mode=S_IFREG|0644, stx_size=[redacted], ...}) = 0

but I think we might be hitting this:

  retval = statx (dirfd, pathname, flags, mask, stat_buf);
  if (retval == 0 && (stat_buf->stx_mask & mask_required) != mask_required)
{
  /* Not all required fields could be returned. */
  errno = ERANGE;
  return -1;
}

It looks like the STATX_ATIME and STATX_BTIME are not coming back from the
kernel, and STATX_ATIME is on GLib's "required" list (for feature parity
with plain stat(), which always puts *something* in struct stat->st_atime,
even if it's nonsense.)

Additionally, the kernel is telling us the STATX_MNT_ID (0x1000), which
we didn't even ask for, but presumably it has that information so easily
available that it might as well tell us.

Holger, do you happen to know whether ZFS implements last-accessed time
(st_atime) like e.g. ext4 and btrfs do, or does it not have that concept?

 says

 * Items in STATX_BASIC_STATS may be marked unavailable on return, but they
 * will have values installed for compatibility purposes so that stat() and
 * co. can be emulated in userspace.

so perhaps GLib shouldn't be checking against mask_required in the way it
is here.

I'll try to get a ZFS filesystem on a test VM to reproduce this.

smcv

Bug#970336: ecl breaks cl-contextl autopkgtest: not of the expected type SYMBOL

[Paul Gevers]

Source: ecl, cl-contextl
Control: found -1 ecl/20.4.24+ds-1
Control: found -1 cl-contextl/1:20160313.git5894fba-1
Severity: serious
Tags: sid bullseye
X-Debbugs-CC: debian...@lists.debian.org
User: debian...@lists.debian.org
Usertags: breaks needs-update

Dear maintainer(s),

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

   passfail
eclfrom testing20.4.24+ds-1
cl-contextlfrom testing1:20160313.git5894fba-1
all others from testingfrom testing

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

Currently this regression is blocking the migration of ecl to testing
[1]. Due to the nature of this issue, I filed this bug report against
both packages. Can you please investigate the situation and reassign the
bug to the right package?

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

Paul

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

https://ci.debian.net/data/autopkgtest/testing/amd64/c/cl-contextl/7008359/log.gz

;;;
;;; Compiling figure-editor-2.lisp.
;;; OPTIMIZE levels: Safety=2, Space=0, Speed=3, Debug=0
;;;
;;; End of Pass 1.
;;; Finished compiling figure-editor-2.lisp.
;;;
real time : 17.420 secs
run time  : 20.101 secs
gc count  : 612 times
consed: 2707204576 bytes
real time : 18.996 secs
run time  : 21.757 secs
gc count  : 652 times
consed: 2886437424 bytes

:DONE
:DONE An error occurred during initialization:
In function SYMBOL-VALUE, the value of the only argument is
  "Dr. Jekyll"
which is not of the expected type SYMBOL.



signature.asc
Description: OpenPGP digital signature

Bug#970335: ecl breaks cffi autopkgtest: Don't know how to REQUIRE rt..

[Paul Gevers]

Source: ecl, cffi
Control: found -1 ecl/20.4.24+ds-1
Control: found -1 cffi/1:0.22.1-1
Severity: serious
Tags: sid bullseye
X-Debbugs-CC: debian...@lists.debian.org
User: debian...@lists.debian.org
Usertags: breaks needs-update

Dear maintainer(s),

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

   passfail
eclfrom testing20.4.24+ds-1
cffi   from testing1:0.22.1-1
all others from testingfrom testing

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

Currently this regression is blocking the migration of ecl to testing
[1]. Due to the nature of this issue, I filed this bug report against
both packages. Can you please investigate the situation and reassign the
bug to the right package?

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

Paul

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

https://ci.debian.net/data/autopkgtest/testing/amd64/c/cffi/7008137/log.gz

;;; Compiling
/usr/share/common-lisp/source/bordeaux-threads/src/impl-ecl.lisp.
;;; OPTIMIZE levels: Safety=2, Space=0, Speed=3, Debug=0
;;;
;;; End of Pass 1.
;;; Finished compiling
/usr/share/common-lisp/source/bordeaux-threads/src/impl-ecl.lisp.
;;;
;;;
;;; Compiling
/usr/share/common-lisp/source/bordeaux-threads/src/default-implementations.lisp.
;;; OPTIMIZE levels: Safety=2, Space=0, Speed=3, Debug=0
;;;
;;; End of Pass 1.
;;; Finished compiling
/usr/share/common-lisp/source/bordeaux-threads/src/default-implementations.lisp.
;;;
An error occurred during initialization:
Module error: Don't know how to REQUIRE rt..



signature.asc
Description: OpenPGP digital signature

Bug#959518: apt-transport-http: Repeatable 'Undetermined Error' during package download from snapshot.debian.org

[Johannes Schauer]

Hi,

On Mon, 14 Sep 2020 18:50:44 +0200 Julian Andres Klode  wrote:
> On Mon, Sep 14, 2020 at 05:18:20PM +0100, James Addison wrote:
> > Package: snapshot.debian.org
> > Followup-For: Bug #959518
> > X-Debbugs-Cc: j...@jp-hosting.net
> > 
> > The issue appears reproducible at the moment with apt 1.8.2.1 compiled from 
> > source and the 'x.tar' configuration provided earlier.
> > 
> > # apt source directory, post-build
> > $ cmdline/apt -o Dir=$PWD/x -o Dir::Bin::Methods=$PWD/methods update && \
> > $ cmdline/apt -o Dir=$PWD/x -o Dir::Bin::Methods=$PWD/methods install -y 
> > openjdk-11-jdk
> > 
> > ...
> > 
> > Get:261 http://snapshot.debian.org/archive/debian-security/20200502T085134Z 
> > buster/updates/main amd64 openjdk-11-jdk-headless amd64 11.0.7+10-3~deb10u1 
> > [215 MB]
> > Err:261 http://snapshot.debian.org/archive/debian-security/20200502T085134Z 
> > buster/updates/main amd64 openjdk-11-jdk-headless amd64 11.0.7+10-3~deb10u1
> >   Undetermined Error [IP: 193.62.202.27 80]
> > 
> > This has occurred for a couple of different server IP addresses, including 
> > 185.17.185.185.
> 
> We only care about unstable for this bug. There is a whole bunch of
> changes in http code and they won't be backported to stable releases.
> 
> Also, the previous comment by Alex Thiessen indicated that this is not a
> bug in apt, but the server seems to close the connection, which means
> there is nothing actionable here.
> 
> If you can produce an issue with the version of apt in unstable,
> and it does not reproduce with wget or curl, please open a new bug report for
> it.

I'm very familiar with snapshot.d.o from the client perspective. Julian is
correct, that it's the server closing the connection. But that doesn't mean
that it's not at least a wishlist bug or feature request in apt. Let me explain
a bit more.

For several projects (debrebuild, debbisect, buildprofile QA,
bootstrap.debian.net...) I regularly interact with snapshot.d.o. Doing this
plainly with apt is deemed to fail miserably with errors like:

# E: Failed to fetch [...]  Error reading from server. Remote end closed 
connection
# E: Failed to fetch [...]  Hash Sum mismatch
# E: Failed to fetch [...]  Bad header line Bad header data
# Err:118 [...] Connection timed out

Yes, this is because of how snapshot.d.o throttles connections. For example
without additional measures, the following will fail:

$ curl 
http://snapshot.debian.org/archive/debian/20200909T084102Z/pool/main/q/qtwebengine-opensource-src/qtwebengine-opensource-src_5.14.2+dfsg1.orig.tar.xz
 >/dev/null
curl: (18) transfer closed with 217347024 bytes remaining to read

There are a couple of things that can be done to work around this problem when
using curl by adding options like:

--limit-rate=800k # this has the biggest effect
--retry 10 --retry-connrefused
--resolve snapshot.debian.org:80:193.62.202.27

But even those are not sufficient as snapshot.d.o will also cut the connection
early enough such that curl will fail with "network unreachable" which is not a
transient error, so curl will not retry establishing the connection.

The only thing that reliably worked for me with snapshot.d.o was the pycurl
based Python code at the end of this E-Mail. With that code, I can even
download for a full day reliably from snapshot.d.o without ever having hit the
Exception in the last line.

But as things stand, it is impossible to reliably use apt together with
snapshot.d.o. I'm not sure how to solve this problem. One way could surely be
to approach snapshot.d.o and ask them to somehow lift their very heavy
throttling policies. But another way to solve this problem would be to make apt
more resilient about mirrors with heavy throttling policies. I can think of
these wishlist bugs against apt:

 - allow to specify a maximum bytes per second value for downloads (this has
   the largest effect if set low enough)

 - allow to set an option that makes apt automatically retry when a transient
   error occurs

 - allow to set custom resolve addresses for domains like done in my code below

I'm not saying that we shouldn't look into maybe making snapshot.d.o throttle
less, because as things stand, it's impossible to use it together with apt. But
there certainly also some things that apt can do and which will not only
benefit people working with snapshot.d.o but also people who are otherwise
using a mirror or proxy with heavy throttling.

Thanks!

cheers, josch





def download(url):
f = BytesIO()
maxretries = 10
for retrynum in range(maxretries):
try:
c = pycurl.Curl()
c.setopt(
c.URL, url,
)
# even 100 kB/s is too much sometimes
c.setopt(c.MAX_RECV_SPEED_LARGE, 800 * 1024)  # bytes per second
c.setopt(c.CONNECTTIMEOUT, 30)  # the default is 300
# sometimes, curl stalls forever and even ctrl+c doesn't work
start = time.time()
def progress(*data):
  

Bug#970334: wslay: autopkgtest needs update for new version of cmake: warning on stderr

[Paul Gevers]

Source: wslay
Version: 1.1.1-1
Severity: serious
X-Debbugs-CC: debian...@lists.debian.org, cm...@packages.debian.org
Tags: sid bullseye
User: debian...@lists.debian.org
Usertags: needs-update
Control: affects -1 src:cmake

Dear maintainer(s),

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

   passfail
cmake  from testing3.18.2-1
wslay  from testing1.1.1-1
all others from testingfrom testing

I copied some of the output at the bottom of this report. The output
contains a warning that's written to stderr. By default that fails a
test. If you can't fix the underlying cause, you can have the output to
stderr ignored by adding an allow-stderr restriction to the test
specification.

Currently this regression is blocking the migration of cmake to testing
[1]. Of course, cmake shouldn't just break your autopkgtest (or even
worse, your package), but it seems to me that the change in cmake was
intended and your package needs to update to the new situation.

If this is a real problem in your package (and not only in your
autopkgtest), the right binary package(s) from cmake should really add a
versioned Breaks on the unfixed version of (one of your) package(s).
Note: the Breaks is nice even if the issue is only in the autopkgtest as
it helps the migration software to figure out the right versions to
combine in the tests.

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

Paul

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

https://ci.debian.net/data/autopkgtest/testing/amd64/w/wslay/7008132/log.gz

autopkgtest [18:08:26]: test build1:  - - - - - - - - - - results - - -
- - - - - - -
build1   FAIL stderr: CMake Warning (dev) at
/usr/share/cmake-3.18/Modules/FindPackageHandleStandardArgs.cmake:273
(message):
autopkgtest [18:08:26]: test build1:  - - - - - - - - - - stderr - - - -
- - - - - -
CMake Warning (dev) at
/usr/share/cmake-3.18/Modules/FindPackageHandleStandardArgs.cmake:273
(message):
  The package name passed to `find_package_handle_standard_args` (NETTLE)
  does not match the name of the calling package (Nettle).  This can lead to
  problems in calling code that expects `find_package` result variables
  (e.g., `_FOUND`) to follow a certain pattern.
Call Stack (most recent call first):
  FindNettle.cmake:15 (find_package_handle_standard_args)
  CMakeLists.txt:10 (find_package)
This warning is for project developers.  Use -Wno-dev to suppress it.



signature.asc
Description: OpenPGP digital signature

Bug#970333: abseil: autopkgtest needs update for new version of cmake: warning on stderr

[Paul Gevers]

Source: abseil
Version: 0~20200225.2-3
Severity: serious
X-Debbugs-CC: debian...@lists.debian.org, cm...@packages.debian.org
Tags: sid bullseye
User: debian...@lists.debian.org
Usertags: needs-update
Control: affects -1 src:cmake

Dear maintainer(s),

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

   passfail
cmake  from testing3.18.2-1
abseil from testing0~20200225.2-3
all others from testingfrom testing

I copied some of the output at the bottom of this report. The output
contains a warning that's written to stderr. By default that fails a
test. If you can't fix the underlaying cause, you can have the output to
stderr ignored by adding an allow-stderr restriction to the test
specification.

Currently this regression is blocking the migration of cmake to testing
[1]. Of course, cmake shouldn't just break your autopkgtest (or even
worse, your package), but it seems to me that the change in cmake was
intended and your package needs to update to the new situation.

If this is a real problem in your package (and not only in your
autopkgtest), the right binary package(s) from cmake should really add a
versioned Breaks on the unfixed version of (one of your) package(s).
Note: the Breaks is nice even if the issue is only in the autopkgtest as
it helps the migration software to figure out the right versions to
combine in the tests.

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

Paul

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

https://ci.debian.net/data/autopkgtest/testing/amd64/a/abseil/7009726/log.gz

autopkgtest [22:32:41]: test cmake:  - - - - - - - - - - results - - - -
- - - - - -
cmakeFAIL stderr: CMake Warning (dev) at
/usr/share/cmake-3.18/Modules/FindPackageHandleStandardArgs.cmake:273
(message):
autopkgtest [22:32:41]: test cmake:  - - - - - - - - - - stderr - - - -
- - - - - -
CMake Warning (dev) at
/usr/share/cmake-3.18/Modules/FindPackageHandleStandardArgs.cmake:273
(message):
  The package name passed to `find_package_handle_standard_args` (Threads)
  does not match the name of the calling package (absl).  This can lead to
  problems in calling code that expects `find_package` result variables
  (e.g., `_FOUND`) to follow a certain pattern.
Call Stack (most recent call first):
  /usr/share/cmake-3.18/Modules/FindThreads.cmake:234
(FIND_PACKAGE_HANDLE_STANDARD_ARGS)
  /usr/lib/x86_64-linux-gnu/cmake/absl/abslConfig.cmake:3 (include)
  CMakeLists.txt:5 (find_package)
This warning is for project developers.  Use -Wno-dev to suppress it.




signature.asc
Description: OpenPGP digital signature

Bug#970228: nemo: Can no longer copy files

[Holger Schröder]

I have tested Thunar from XFCE, same problem.


...

Bug#970331: kubernetes: Please expose kubernetes sources to dependant packages

[Reinhard Tartler]

Source: kubernetes
Version: 1.18.6-1
Severity: wishlist
X-Debbugs-Cc: siret...@gmail.com

I'm looking at packaging github.com/cri-o/cri-o, and noticed that it vendors
kubernetes sources:

 - https://github.com/cri-o/cri-o/tree/master/vendor/k8s.io

Additionally, I note that the 'libpod' package contains a copy of some sources,
cf. https://sources.debian.org/src/libpod/2.0.4+dfsg2-5/vendor/k8s.io/

I'd like to avoid copying source code and suggest to have the required source
code exposed in a kubernetes-dev package so that code duplication becomes
unnecessary.

Let me know what you think.

-rt


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

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

Bug#970330: src:r-cran-mice: fails to migrate to testing for too long: autopkgtest regression

[Paul Gevers]

Source: r-cran-mice
Version: 3.9.0-2
Severity: serious
Control: close -1 3.10.0-1
Tags: sid bullseye
User: release.debian@packages.debian.org
Usertags: out-of-sync
Control: block -1 by 969494

Dear maintainer(s),

As recently announced [1], the Release Team now considers packages that
are out-of-sync between testing and unstable for more than 60 days as
having a Release Critical bug in testing. Your package src:r-cran-mice
in its current version in unstable has been trying to migrate for 60
days [2]. Hence, I am filing this bug.

If a package is out of sync between unstable and testing for a longer
period, this usually means that bugs in the package in testing cannot be
fixed via unstable. Additionally, blocked packages can have impact on
other packages, which makes preparing for the release more difficult.
Finally, it often exposes issues with the package and/or
its (reverse-)dependencies. We expect maintainers to fix issues that
hamper the migration of their package in a timely manner.

This bug will trigger auto-removal when appropriate. As with all new
bugs, there will be at least 30 days before the package is auto-removed.

I have immediately closed this bug with the version in unstable, so if
that version or a later version migrates, this bug will no longer affect
testing. I have also tagged this bug to only affect sid and bullseye, so
it doesn't affect (old-)stable.

If you believe your package is unable to migrate to testing due to
issues beyond your control, don't hesitate to contact the Release Team.

Paul

[1] https://lists.debian.org/debian-devel-announce/2020/02/msg5.html
[2] https://qa.debian.org/excuses.php?package=r-cran-mice




signature.asc
Description: OpenPGP digital signature

Bug#969608: makeblastdb 2.10.x on 32-bit architectures

[Étienne Mollier]

Hi Aaron,

Aaron M. Ucko, on 2020-09-13 22:44:00 -0400:
> Étienne Mollier  writes:
> 
> > regression looks still there in version 2.10.0-3, at least on
> > arm64 architecture.
> 
> How can I reproduce it?

I worked within an arm64 schroot built with sbuild-createchroot,
on a native amd64 machine.  The reproducer is the test from
Biopython stored in Tests/test_NCBI_BLAST_tools.py, which boils
down to running the command:

makeblastdb \
-in NC_005816.faa \
-dbtype prot \
-hash_index \
-max_file_sz 20MB \
-parse_seqids \
-taxid 10

where NC_005816.faa can be obtained from the Biopython test
suite on Salsa:


https://salsa.debian.org/med-team/python-biopython/-/raw/master/Tests/GenBank/NC_005816.faa

When I run it within that arm64 environment, I get the following
output, and the error code 255 sent back to the shell:

Building a new DB, current time: 09/14/2020 18:35:05
New DB name:   /tmp/NC_005816.faa
New DB title:  NC_005816.faa
Sequence type: Protein
Keep MBits: T
Maximum file size: 2000B

No volumes were created.

Error: mdb_env_open: Cannot allocate memory

while specifying "-blastdb_version 4" in additions restores the
former behavior:

Building a new DB, current time: 09/14/2020 18:44:51
New DB name:   /tmp/NC_005816.faa
New DB title:  NC_005816.faa
Sequence type: Protein
Deleted existing Protein BLAST database named /tmp/NC_005816.faa
Keep MBits: T
Maximum file size: 2000B
Adding sequences from FASTA; added 10 sequences in 0.0821829 seconds.

I haven't straced the execution of the program to check the
amount of memory in map, so maybe the issue is different but
with similar symptoms as previously?

> AFAICT python-biopython's autopkgtest boils
> down to the upstream test suite, which runs fine as part of a build of
> revision 15084ca (immediately preceding your patch to drop back to
> version 4 on selected architectures) on the porterbox amdahl.  Perhaps
> system limits come into play in some other environments, but then I
> expect they would have done the same on 2.10.0-1.  Also, the telltale
> warning
> 
>   
> /<>/c++/include/objtools/blast/seqdb_writer/writedb_lmdb.hpp:52:59:
>  warning: integer overflow in expression of type ‘int’ results in 
> ‘-647710720’ [-Woverflow]
> 
> occurs only in the logs for 2.10.0-2.

Ouch, looks good to know, thank you for the warning.

Kind Regards,
-- 
Étienne Mollier 
Old rsa/3072: 5ab1 4edf 63bb ccff 8b54  2fa9 59da 56fe fff3 882d
New rsa/4096: 8f91 b227 c7d6 f2b1 948c  8236 793c f67e 8f0d 11da
Sent from /dev/pts/2, please excuse my verbosity.


signature.asc
Description: PGP signature

Bug#969241: RFS: hydrapaper/1.12 [ITP]] -- sets desktop wallpaper on different monitors

[Francisco M Neto]

Hello Tobias,

On Mon, 2020-09-14 at 19:38 +0200, Tobias Frost wrote:
> 
> It still has stray version 2 in the version 3 text… Look at line 17 and 29.
> 
> New stuff I found:
> d/rules:
> - the dh_auto_clean override is not needed. This can be done by listing the
> files to be deleted in d/clean.
> - Calling dh_clean in an override for dh_*auto*_clean is not correct, you need
>   to match those.
> --> go for d/clean and delete the override.
> 
> Copyright review: ✔
> 
> Please fix the remaining issues and then ping me.

Done. I've already uploaded the new version to m.d.o and updated Salsa
as well. Thank you for the review!

-- 
[]'s,

Francisco M Neto 
www.fmneto.com

3E58 1655 9A3D 5D78 9F90
CFF1 D30B 1694 D692 FBF0



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

Bug#958060: mdadm segfaults when run from cron.daily

[Felix Lechner]

control: clone 958060 -1
control: retitle 958060 mdadm: look for md device in /dev/md
control: retitle -1 mdadm: exit gracefully when md is not a block device

Hi Martin,

Thank you for your detailed detective work. Please have a look at the
other unsolved bugs against mdadm when you have the chance. [1] :)

[1] https://bugs.debian.org/cgi-bin/pkgreport.cgi?repeatmerged=no=mdadm

> Apparently, the outer strcpy was meant to be a strcat.

This will be fixed in the next upload.

> However "fd" refers to a directory, not to a block device, so we return NULL

I have not looked in detail at how to best solve the second issue, but
hope to address it also.

Thanks for working so hard to make mdadm better for everyone!

Kind regards
Felix Lechner

Bug#970328: CVE-2020-10688

[Moritz Muehlenhoff]

Source: resteasy
Severity: important
Tags: security
X-Debbugs-Cc: Debian Security Team 

This was assigned CVE-2020-10688:

https://bugzilla.redhat.com/show_bug.cgi?id=1814974
https://github.com/quarkusio/quarkus/issues/7248
https://issues.redhat.com/browse/RESTEASY-2519

Cheers,
Moritz
   

Bug#969673: g-wrap: please upgrade to guile-3.0 soon, if feasible

[Göran Weinholt]

Tommi Höynälänmaa  writes:

> su, 2020-09-06 kello 15:21 -0500, Rob Browning kirjoitti:
>> Source: g-wrap
>> Severity: wishlist
>> 
>> Please migrate to guile-3.0 as soon as it's feasible. If we can, I'd
>> like to have the option to drop guile-2.2 from bullseye, so that we
>> won't have to maintain two versions throughout that release.

> Is this my task or should this be done by the upstream authors?

Hello Tommi,

Upstream needs to support guile-3.0 before this is possible. Then
g-wrap's dependencies need to be built for guile-3.0 as well. Once that
is in place you can switch to 3.0 in debian/control.

> There is another problem in updating this package and related packages:
> My sponsor has not been responding to my mails for half a year.

I can sponsor your uploads of Scheme packages.

Rob has filed a similar request for src:guile-lib and g-wrap depends on
it, so both need to be updated at the same time. I maintain the
guile-lib package and will try to prepare it for guile-3.0. Upstream
supposedly supports 3.0 so it should be as simple as switching to 3.0 in
debian/control, but something's breaking at the moment... I will get
back to you when I have something you can test with g-wrap.

-- 
Göran Weinholt   | https://weinholt.se/
Debian Developer | 73 de SA6CJK

Bug#909436: libdrm 2.4.102-1: FTBFS on hurd-i386 (updated patches)

[Timo Aaltonen]

On 14.9.2020 18.44, Svante Signell wrote:
> found 909436 2.4.102-1
> thanks
> 
> Hello again,
> 
> libdrm still FTBFS on GNU/Hurd now due to bug #970304 and still missing
> support for Hurd in drm.h and xf86drm.h. Attached is a patch, hurd-
> port.diff, to fix this. The rest of that patch address PATH_MAX issues
> in xf86dri.c as PATH_MAX is not defined for GNU/Hurd.
> 
> Note: hurd-port.diff depends on that xf86drm.c.diff in #970304 is
> applied before!


these would need to go upstream..


-- 
t

Bug#970327: cups: make apparmor abort at startup

[JP]

Package: cups
Version: 2.2.10-6+deb10u3
Severity: normal

Dear Maintainer,

When looking for apparmor "denied" messages I found that apparmor is not
running ant cannot start as an error lies in the usr.bin.cups file. When I use
the simple parser :
apparmor_parser -vQ usr.sbin.cupsd
I get the message :
AppArmor parser error for usr.sbin.cupsd in usr.sbin.cupsd at line 173: syntax
error, unexpected TOK_CLOSE, expecting TOK_END_OF_RULE
If I try to start apparmor through systemctl I get an abort, as "normal"
nothing to see in systemctl status apparmor, except that something get wrong
...
I remove "usr.bin.cupsd" from /etc/apparmor.d and all is clear ...
systemctl restart apparmor is clean and apparmor is running.

Regards

JP P



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

Kernel: Linux 5.7.0-0.bpo.2-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_UNSIGNED_MODULE
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE=C 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages cups depends on:
ii  cups-client2.2.10-6+deb10u3
ii  cups-common2.2.10-6+deb10u3
ii  cups-core-drivers  2.2.10-6+deb10u3
ii  cups-daemon2.2.10-6+deb10u3
ii  cups-filters   1.21.6-5
ii  cups-ppdc  2.2.10-6+deb10u3
ii  cups-server-common 2.2.10-6+deb10u3
ii  debconf [debconf-2.0]  1.5.71
ii  ghostscript9.27~dfsg-2+deb10u4
ii  libavahi-client3   0.7-4+b1
ii  libavahi-common3   0.7-4+b1
ii  libc6  2.28-10
ii  libcups2   2.2.10-6+deb10u3
ii  libcupsimage2  2.2.10-6+deb10u3
ii  libgcc11:8.3.0-6
ii  libstdc++6 8.3.0-6
ii  libusb-1.0-0   2:1.0.22-2
ii  poppler-utils  0.71.0-5
ii  procps 2:3.3.15-2

Versions of packages cups recommends:
pn  avahi-daemon 
ii  colord   1.4.3-4
ii  cups-filters [ghostscript-cups]  1.21.6-5
ii  printer-driver-gutenprint5.3.1-7

Versions of packages cups suggests:
ii  cups-bsd   2.2.10-6+deb10u3
pn  foomatic-db-compressed-ppds | foomatic-db  
pn  hplip  
ii  printer-driver-cups-pdf [cups-pdf] 3.0.1-5
pn  printer-driver-hpcups  
ii  smbclient  2:4.9.5+dfsg-5+deb10u1
ii  udev   246.4-1~bpo10+1

-- debconf information:
  cupsys/backend: lpd, socket, usb, snmp, dnssd
  cupsys/raw-print: true

Bug#970326: firewall-config: after inputing root password, firewall-config throws an error unknownmethodexceptoin

[Joe McEntire]

Package: firewall-config
Version: 0.9.0-1
Severity: important
X-Debbugs-Cc: get...@live.com

Dear Maintainer,

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

   * What led up to the situation? Launched firewall-config
   * What exactly did you do (or not do) that was effective (or
 ineffective)? relaunch
   * What was the outcome of this action? no effect
   * What outcome did you expect instead? working firewall-config for firewalld

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



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

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

Versions of packages firewall-config depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.36.0-1
ii  firewalld0.9.0-1
ii  gir1.2-glib-2.0  1.64.1-1
ii  gir1.2-gtk-3.0   3.24.23-1
ii  gir1.2-nm-1.01.26.2-1
ii  gir1.2-pango-1.0 1.46.1-1
ii  python3  3.8.2-3
ii  python3-dbus 1.2.16-3
ii  python3-firewall 0.9.0-1
ii  python3-gi   3.36.1-1

firewall-config recommends no packages.

firewall-config suggests no packages.

-- no debconf information

Bug#969241: RFS: hydrapaper/1.12 [ITP]] -- sets desktop wallpaper on different monitors

[Tobias Frost]

Control: tags -1 moreinfo
Control: owner -1 !

Hi Francisco,

On Tue, Sep 08, 2020 at 06:42:23PM -0300, Francisco M Neto wrote:

(Note: I'm removing stuff from the that have been resolved, to keep it short)
- new upstream version 2.0
- dep3 header of patch
- extra B-D on cmake
- d/watch updated
- d/copytright partially fixed.
- nitpicks about lintian overrides fixed.
- orig tarballs shasum now matching with the on on mentors.

> On Tue, 2020-09-08 at 22:01 +0200, Tobias Frost wrote:
> > Control: tags -1 moreinfo
> > 
> > Hi Francisco,
> > 
> > d/copyright:
> > - 1st files section says License: GPL3+, but License text says "Version 2" 
> > at
> > two locations.

It still has stray version 2 in the version 3 text… Look at line 17 and 29.

New stuff I found:
d/rules:
- the dh_auto_clean override is not needed. This can be done by listing the 
files
to be deleted in d/clean.
- Calling dh_clean in an override for dh_*auto*_clean is not correct, you need
  to match those.
--> go for d/clean and delete the override.

Copyright review: ✔

Please fix the remaining issues and then ping me.

-- 
tobi


signature.asc
Description: PGP signature

Bug#970325: tpm2-pkcs11: Provide buster-backports

[Bastian Germann]

Source: tpm2-pkcs11
Version: 1.2.0-1
Severity: wishlist

Please provide a buster-backports version of tpm2-pkcs11, preferably
after updating to the current upstream release 1.4.0.

Bug#970305: dh-autoreconf: support -Wl,--whole-archive in libtool

[Luca Boccassi]

On Mon, 2020-09-14 at 18:51 +0200, Julian Andres Klode wrote:
> On Mon, Sep 14, 2020 at 02:58:02PM +0100, Luca Boccassi wrote:
> > Package: dh-autoreconf
> > Version: 19
> > Tags: patch
> > X-Debbugs-CC: pkg-dpdk-de...@lists.alioth.debian.org
> > 
> > Dear Maintainer(s),
> > 
> > dh-autoreconf provides an --as-needed option to allow packages to
> > use
> > -Wl,---as-needed with libtool, since libtool otherwise reorders the
> > flags and breaks compilation.
> > 
> > The same reordering problem affects programs building with --whole-
> > archive, in the exact same way. I've come across this when building
> > src:openvswitch with src:dpdk.
> > 
> > I have opened an MR on Salsa to add a --whole-archive autoreconf
> > option
> > that works exactly as --as-needed to fix this. It fixes the build
> > of
> > openvswitch with a new version of dpdk that is in development.
> > 
> > https://salsa.debian.org/debian/dh-autoreconf/-/merge_requests/2
> 
> I'm not supposed to have the --as-needed stuff in there in the first
> place, so I'd rather not make it even worse.
> 
> Could you take this up with libtool upstream and come to a solution
> there?

Hi,

Given these issues have been lingering for about a decade if not
longer, with no progress, I don't have much hope for that to ever
happen, sadly. Besides, last release of libtool was more than five
years ago, even if it was still worked on it seems unlikely a fix could
 make its way into Debian via that route in time.

We could replicate the same monkey-patching directly in all the
affected packages, but that doesn't feel like the best solution?

Thanks!

-- 
Kind regards,
Luca Boccassi


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

Bug#970321: tracker should display related ITS bugs

[Antoine Beaupré]

On 2020-09-14 19:06:39, Mattia Rizzolo wrote:
> On Mon, Sep 14, 2020 at 12:19:57PM -0400, Antoine Beaupre wrote:
>> But, critically, it does not show ITS (Intent To Salvage) bugs, which
>> are (arguably) even more important.
>> 
>> This should be fixed, and, in general, I think that any WNPP bug
>> related to a package should be displayed in the dashboard.
>
> Techinically, ITS are not WNPP bugs (in the sense, they are not filed
> against the WNPP pseudo-package).

Oh! Interesting. I stand corrected. :)

>> So it might
>> be worth going over the different categories to make sure we cover
>> them all (and not forget one in the future).
>
> I haven't checked right now, but I'm positive tracker already deals with
> all WNPP bugs (at the very least, O/ITA/RFA).  It also includes RFS,
> which is another thing that is not a WNPP bug.

I see. Good to know!

a.

-- 
It is not enough to fight for the land; it is even more important to
enjoy it. While you can. While it’s still here.
- Edward Abbey

Bug#970324: libgstreamer-plugins-base1.0-dev should probably depend on or recommend libwayland-dev

[Dmitry Shachnev]

Package: libgstreamer-plugins-base1.0-dev
Version: 1.18.0-2

Dear Maintainer,

/usr/include/gstreamer-1.0/gst/gl/wayland/gstgldisplay_wayland.h includes
, which is available in libwayland-dev package.

I think that package should be added to Depends or Recommends. Or, if it is
intentional to not pull in extra dependencies, at least to Suggests.

--
Dmitry Shachnev


signature.asc
Description: PGP signature

Bug#970321: tracker should display related ITS bugs

[Mattia Rizzolo]

On Mon, Sep 14, 2020 at 12:19:57PM -0400, Antoine Beaupre wrote:
> But, critically, it does not show ITS (Intent To Salvage) bugs, which
> are (arguably) even more important.
> 
> This should be fixed, and, in general, I think that any WNPP bug
> related to a package should be displayed in the dashboard.

Techinically, ITS are not WNPP bugs (in the sense, they are not filed
against the WNPP pseudo-package).

> So it might
> be worth going over the different categories to make sure we cover
> them all (and not forget one in the future).

I haven't checked right now, but I'm positive tracker already deals with
all WNPP bugs (at the very least, O/ITA/RFA).  It also includes RFS,
which is another thing that is not a WNPP bug.

-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
More about me:  https://mapreri.org : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


signature.asc
Description: PGP signature

Bug#970323: dpkg-deb fails to create package > 2 GB

[Francois Gouget]

Package: dpkg
Version: 1.19.7
Severity: normal

Dear Maintainer,

dpkg-deb fails to create a package with a size greater than 2 GB.
To reproduce this issue use the attached file to create a 2.4 GB
package, this despite being on a 64-bit system:

$ tar xfz testpkg.tar.gz
$ cd testpkg
$ fakeroot ./build
[...]
+ dh_builddeb --destdir=.
dpkg-deb: building package 'testpkg' in './testpkg_1.0-1_all.deb'.
dpkg-deb (subprocess): compressing tar member: lzma write error: No space left 
on device
dpkg-deb: error:  from tar -cf subprocess returned error exit status 2
dh_builddeb: dpkg-deb --build debian/testpkg . returned exit code 2
dh_builddeb: Aborting due to earlier error

Note that neither tar nor ar have any trouble dealing with archives with
a size greater than 2 GB.
Also this is not specific to the lzma compressor: using gzip instead
produces the same error.


-- Package-specific info:

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

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

Versions of packages dpkg depends on:
ii  libbz2-1.0   1.0.6-9.2~deb10u1
ii  libc62.28-10
ii  liblzma5 5.2.4-1
ii  libselinux1  2.8-1+b1
ii  tar  1.30+dfsg-6
ii  zlib1g   1:1.2.11.dfsg-1

dpkg recommends no packages.

Versions of packages dpkg suggests:
ii  apt1.8.2.1
pn  debsig-verify  

-- no debconf information


testpkg.tar.gz
Description: application/gzip

Bug#970305: dh-autoreconf: support -Wl,--whole-archive in libtool

[Julian Andres Klode]

On Mon, Sep 14, 2020 at 02:58:02PM +0100, Luca Boccassi wrote:
> Package: dh-autoreconf
> Version: 19
> Tags: patch
> X-Debbugs-CC: pkg-dpdk-de...@lists.alioth.debian.org
> 
> Dear Maintainer(s),
> 
> dh-autoreconf provides an --as-needed option to allow packages to use
> -Wl,---as-needed with libtool, since libtool otherwise reorders the
> flags and breaks compilation.
> 
> The same reordering problem affects programs building with --whole-
> archive, in the exact same way. I've come across this when building
> src:openvswitch with src:dpdk.
> 
> I have opened an MR on Salsa to add a --whole-archive autoreconf option
> that works exactly as --as-needed to fix this. It fixes the build of
> openvswitch with a new version of dpdk that is in development.
> 
> https://salsa.debian.org/debian/dh-autoreconf/-/merge_requests/2

I'm not supposed to have the --as-needed stuff in there in the first
place, so I'd rather not make it even worse.

Could you take this up with libtool upstream and come to a solution
there?
-- 
debian developer - deb.li/jak | jak-linux.org - free software dev
ubuntu core developer  i speak de, en

Bug#959518: apt-transport-http: Repeatable 'Undetermined Error' during package download from snapshot.debian.org

[Julian Andres Klode]

On Mon, Sep 14, 2020 at 05:18:20PM +0100, James Addison wrote:
> Package: snapshot.debian.org
> Followup-For: Bug #959518
> X-Debbugs-Cc: j...@jp-hosting.net
> 
> The issue appears reproducible at the moment with apt 1.8.2.1 compiled from 
> source and the 'x.tar' configuration provided earlier.
> 
> # apt source directory, post-build
> $ cmdline/apt -o Dir=$PWD/x -o Dir::Bin::Methods=$PWD/methods update && \
> $ cmdline/apt -o Dir=$PWD/x -o Dir::Bin::Methods=$PWD/methods install -y 
> openjdk-11-jdk
> 
> ...
> 
> Get:261 http://snapshot.debian.org/archive/debian-security/20200502T085134Z 
> buster/updates/main amd64 openjdk-11-jdk-headless amd64 11.0.7+10-3~deb10u1 
> [215 MB]
> Err:261 http://snapshot.debian.org/archive/debian-security/20200502T085134Z 
> buster/updates/main amd64 openjdk-11-jdk-headless amd64 11.0.7+10-3~deb10u1
>   Undetermined Error [IP: 193.62.202.27 80]
> 
> This has occurred for a couple of different server IP addresses, including 
> 185.17.185.185.

We only care about unstable for this bug. There is a whole bunch of
changes in http code and they won't be backported to stable releases.

Also, the previous comment by Alex Thiessen indicated that this is not a
bug in apt, but the server seems to close the connection, which means
there is nothing actionable here.

If you can produce an issue with the version of apt in unstable,
and it does not reproduce with wget or curl, please open a new
bug report for it.
-- 
debian developer - deb.li/jak | jak-linux.org - free software dev
ubuntu core developer  i speak de, en

Bug#911411: general: Computer freezes after suspend/hibernate

[Vladimir K]

It may be that in my case the problem occurs during getting into suspend. 
System appears to stop in every way but power indicator.
It also MAY be caused by r8169 module.

I configured unloading r8169 for suspend, and haven't had any freeze since 
that. Although due to rarity of those freezes, it's hard to say for sure.

$ cat /lib/systemd/system-sleep/unload_eth_r8169 
#!/bin/sh
case $1 in
  pre)
/sbin/modprobe -r r8169
;;
  post)
/sbin/modprobe r8169
;;
esac

Bug#970322: additional information

[jmho]

Dear maintainers,

the ethernet adapter I use is the "Startech GIGABIT ETHERNET ADAPTER" 
which

has a USB 3 type A plug and supports speeds up to 5 GBit/s.

I compiled the sources of linux-image-5.8.0-1-amd64 following the recipe 
in the
Debian documentation. The only changes were enable the module 
(CONFIG_USB_NET_AQC111=m)

and disabling the signing to work around a build problem.

The adapter has been working nicely for two days now and the reported 
link speed is 5G,

also confirmed in switch status page.

best regards,
Jens-Michael

Bug#970322: linux-image-5.8.0-1-amd64: Please add support for USB 5G ethernet adapter (Aquantia AQC111U chipset)

[Jens-Michael Hoffmann]

Package: linux-image-5.8.0-1-amd64
Version: 5.8.7-jmho-1
Severity: wishlist
X-Debbugs-Cc: j...@posteo.net

Dear Maintainer,

I could build the linux-image-5.8.0-1-amd64 kernel with the 
CONFIG_USB_NET_AQC111 set to "m" to enable this adapter.

The SKU of the adapter is US5GA30.


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

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

-- no debconf information

Bug#970321: tracker should display related ITS bugs

[Antoine Beaupre]

Package: tracker.debian.org
Severity: important

The tracker.debian.org site displays some bugs in the WNPP
pseudo-package that are related. For example, it will display RFH
bugs.

But, critically, it does not show ITS (Intent To Salvage) bugs, which
are (arguably) even more important.

This should be fixed, and, in general, I think that any WNPP bug
related to a package should be displayed in the dashboard. So it might
be worth going over the different categories to make sure we cover
them all (and not forget one in the future).

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

Kernel: Linux 5.7.0-0.bpo.2-amd64 (SMP w/4 CPU cores)
Locale: LANG=fr_CA.UTF-8, LC_CTYPE=fr_CA.UTF-8 (charmap=UTF-8), 
LANGUAGE=fr_CA.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Bug#970319: bootp FTCBFS: does not pass cross tools to make

[Helmut Grohne]

Source: bootp
Version: 2.4.3-19
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

bootp fails to cross build from source, because it does not pass cross
tools to make. The easiest way of fixing that - using dh_auto_build -
makes bootp cross buildable. Please consider applying the attached
patch.

Helmut
diff --minimal -Nru bootp-2.4.3/debian/changelog bootp-2.4.3/debian/changelog
--- bootp-2.4.3/debian/changelog2020-07-09 05:40:44.0 +0200
+++ bootp-2.4.3/debian/changelog2020-09-14 17:58:57.0 +0200
@@ -1,3 +1,10 @@
+bootp (2.4.3-19.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: Let dh_auto_build pass cross tools to make. (Closes: #-1)
+
+ -- Helmut Grohne   Mon, 14 Sep 2020 17:58:57 +0200
+
 bootp (2.4.3-19) unstable; urgency=medium
 
   * Source format is 3.0 (quilt)
diff --minimal -Nru bootp-2.4.3/debian/rules bootp-2.4.3/debian/rules
--- bootp-2.4.3/debian/rules2020-07-09 04:19:36.0 +0200
+++ bootp-2.4.3/debian/rules2020-09-14 17:58:56.0 +0200
@@ -7,8 +7,7 @@
 
 build:
dh_testdir
-
-   $(MAKE) SYSDEFS=-DETC_ETHERS
+   dh_auto_build -- SYSDEFS=-DETC_ETHERS
 
 clean:
dh_testdir

Bug#909436: libdrm 2.4.102-1: FTBFS on hurd-i386 (updated patches)

[Svante Signell]

found 909436 2.4.102-1
thanks

Hello again,

libdrm still FTBFS on GNU/Hurd now due to bug #970304 and still missing
support for Hurd in drm.h and xf86drm.h. Attached is a patch, hurd-
port.diff, to fix this. The rest of that patch address PATH_MAX issues
in xf86dri.c as PATH_MAX is not defined for GNU/Hurd.

Note: hurd-port.diff depends on that xf86drm.c.diff in #970304 is
applied before!

Additionally the patches debian_rules.diff and debian_control.diff adds
Hurd to the architecture list.

Thanks!
Index: libdrm-2.4.102/include/drm/drm.h
===
--- libdrm-2.4.102.orig/include/drm/drm.h
+++ libdrm-2.4.102/include/drm/drm.h
@@ -42,6 +42,22 @@
 #include 
 typedef unsigned int drm_handle_t;
 
+#elif defined(__GNU__)
+
+#include 
+#include 
+#include 
+typedef __int8_t   __s8;
+typedef __uint8_t  __u8;
+typedef __int16_t  __s16;
+typedef __uint16_t __u16;
+typedef __int32_t  __s32;
+typedef __uint32_t __u32;
+typedef __int64_t  __s64;
+typedef __uint64_t __u64;
+typedef size_t   __kernel_size_t;
+typedef unsigned int drm_handle_t;
+
 #else /* One of the BSDs */
 
 #include 
Index: libdrm-2.4.102/xf86drm.h
===
--- libdrm-2.4.102.orig/xf86drm.h
+++ libdrm-2.4.102/xf86drm.h
@@ -56,6 +56,16 @@ extern "C" {
 #define DRM_IOC_READWRITE	_IOC_READ|_IOC_WRITE
 #define DRM_IOC(dir, group, nr, size) _IOC(dir, group, nr, size)
 
+#elif defined(__GNU__)
+#include 
+#include 
+#define DRM_IOCTL_NR(n) ((n) & 0xff)
+#define DRM_IOC_VOIDIOC_VOID
+#define DRM_IOC_READIOC_OUT
+#define DRM_IOC_WRITE   IOC_IN
+#define DRM_IOC_READWRITE   IOC_INOUT
+#define DRM_IOC(dir, group, nr, size) _IOC(dir, group, nr, size)
+
 #else /* One of the *BSDs */
 
 #include 
Index: libdrm-2.4.102/xf86drm.c
===
--- libdrm-2.4.102.orig/xf86drm.c
+++ libdrm-2.4.102/xf86drm.c
@@ -2980,7 +2980,8 @@ static char *drmGetMinorNameForFD(int fd
 return strdup(name);
 #else
 struct stat sbuf;
-char buf[PATH_MAX + 1];
+char *buf = NULL;
+int len = 0;
 const char *dev_name = drmGetDeviceName(type);
 unsigned int maj, min;
 int n;
@@ -2997,11 +2998,18 @@ static char *drmGetMinorNameForFD(int fd
 if (!dev_name)
 return NULL;
 
-n = snprintf(buf, sizeof(buf), dev_name, DRM_DIR_NAME, min);
-if (n == -1 || n >= (int)sizeof(buf))
+len = snprintf(NULL, 0, dev_name, DRM_DIR_NAME, min);
+if (len < 0)
 return NULL;
+len++;
+buf = malloc(len);
+n = snprintf(buf, len, dev_name, DRM_DIR_NAME, min);
+if (n == -1 || n >= len) {
+free(buf);
+return NULL;
+}
 
-return strdup(buf);
+return buf;
 #endif
 }
 
@@ -3947,17 +3955,30 @@ process_device(drmDevicePtr *device, con
bool fetch_deviceinfo, uint32_t flags)
 {
 struct stat sbuf;
-char node[PATH_MAX + 1];
+char *node = NULL;
 int node_type, subsystem_type;
+int len = 0, n, ret = 0;
 unsigned int maj, min;
 
 node_type = drmGetNodeType(d_name);
 if (node_type < 0)
 return -1;
 
-snprintf(node, PATH_MAX, "%s/%s", DRM_DIR_NAME, d_name);
-if (stat(node, ))
+len = snprintf(NULL, 0, "%s/%s", DRM_DIR_NAME, d_name);
+if (len < 0)
+  return -1;
+len++;
+node = malloc(len);
+n = snprintf(node, len, "%s/%s", DRM_DIR_NAME, d_name);
+if (n == -1 || n >= len) {
+free(node);
 return -1;
+}
+
+if (stat(node, )) {
+free(node);
+return -1;
+}
 
 maj = major(sbuf.st_rdev);
 min = minor(sbuf.st_rdev);
@@ -3972,18 +3993,27 @@ process_device(drmDevicePtr *device, con
 switch (subsystem_type) {
 case DRM_BUS_PCI:
 case DRM_BUS_VIRTIO:
-return drmProcessPciDevice(device, node, node_type, maj, min,
+ret = drmProcessPciDevice(device, node, node_type, maj, min,
fetch_deviceinfo, flags);
+	free(node);
+	return ret;
 case DRM_BUS_USB:
-return drmProcessUsbDevice(device, node, node_type, maj, min,
+ret = drmProcessUsbDevice(device, node, node_type, maj, min,
fetch_deviceinfo, flags);
+	free(node);
+	return ret;
 case DRM_BUS_PLATFORM:
-return drmProcessPlatformDevice(device, node, node_type, maj, min,
+ret = drmProcessPlatformDevice(device, node, node_type, maj, min,
 fetch_deviceinfo, flags);
+	free(node);
+	return ret;
 case DRM_BUS_HOST1X:
-return drmProcessHost1xDevice(device, node, node_type, maj, min,
+ret = drmProcessHost1xDevice(device, node, node_type, maj, min,
   fetch_deviceinfo, flags);
+	free(node);
+	return ret;
 default:
+free(node);
 return -1;
}
 }
@@ -4306,10 +4336,10 @@ drm_public char 

Bug#970291: golang-github-avast-apkverifier-dev misses description in Translation-en.bz2 for Sid

[s3v]

Package: ftp.debian.org
Severity: minor
Control: affects -1 golang-github-avast-apkverifier-dev

Dear Maintainers,

I just find out golang-github-avast-apkverifier-dev [1] has not
description in Translation-en.bz2 file [2].

 $ bzgrep golang-github-avast-apkverifier-dev Translation-en.bz2
 $

I don't know if this issue is related either to
golang-github-avast-apkverifier-dev package itself or to FTP-side
gears, so please feel free to route this report on the right track.
ATM golang-github-avast-apkverifier-dev is the only package misses
description in Translation-en.bz2 file for Sid.

Thanks for reading.

Kind Regards.

[1] https://tracker.debian.org/pkg/golang-github-avast-apkverifier
[2] http://ftp.debian.org/debian/dists/sid/main/i18n/Translation-en.bz2

Bug#970318: O: dmrconfig -- Configuration utility for DMR radios

[Iain R. Learmonth]

Package: wnpp
Severity: normal
User: i...@debian.org
Usertags: refactor2020
X-Debbugs-Cc: debian-h...@lists.debian.org

I intend to orphan the dmrconfig package.

The package description is:
 DMRconfig is a utility for programming digital radios via USB programming
 cable. It can read and write codeplug, configuration and contacts from and to
 the radio. Various TYT, Baofeng, Radioddity, Anytone, BTECH, Zastone and Radtel
 radios are supported.

Bug#970317: plymouth can cause initrd creation to fail.

[Sven Mueller]

Package: plymouth
Version: 0.9.4-3

We encountered a way how plymouth can cause initrd creation to fail:

/usr/share/initramfs-tools/hooks/plymouth
contains a call to plymouth-set-default-theme, reading the set theme name.
plymouth-set-default-theme fails back to "text" apparently, if the desired
theme (set via plymouthd.conf) is unknown.

If this name is not "text" or "details", the script later on tries to copy
/etc/fonts/fonts.conf

However, if fontconfig-config isn't yet installed (and thus plymouth-themes
isn't installed yet), then the following sequence can (and for us
reproducibly did) happen:

- Configuration file plymouthd.conf was written, setting theme "lines".
- Installation of kernel, plymouth, plymouth-themes, desktop-base,
fontconfig-config requested
- packages are unpacked by dpkg (which doesn't copy conffiles to their
destination)
- Note: plymouth hook script is now active (not a conffile)
- kernel gets configured. tries to build initrd
- plymouth hook gets executed
- plymouth hook reads desired theme, finds "lines" (installed by
desktop-base)
- plymouth hook fails to copy /etc/fonts/fonts.conf and aborts

I'll describe multiple options. The first two are the most sensible IMHO.

Option 1:

Let the hook script or plymouth-set-default-theme fall back to the "text"
or "details" theme if required files are not available yet. At least in our
case, the initrd would have gotten rebuilt again later on, eliminating the
issue of a silent fallback.

Option 2:

Let plymouth declare a "Pre-Depends: fontconfig-config" to ensure that the
conffile from fontconfig-config is actually available at the time plymouth
gets installed and thus activates the initramfs-tools hook script. This
introduces an indirect dependency on various fonts, but seems reasonable
anyways. Would eliminate the silent fallback and would thus probably come
closest to user expectation.

Option 3:

Let both desktop-base and plymouth-themes Pre-Depend on fontconfig-config -
This would move the responsibility to whoever provides a plymouth theme. As
the set of such packages is not necessarily a closed set, I'm not sure if
this is maintainable in the long run.

My personal preference would probably be Option 2: It would get the issue
fixed for everyone at little extra cost.

Bug#970316: vanguards: please remove irl from uploaders

[Iain R. Learmonth]

Package: vanguards
Severity: normal
User: i...@debian.org
Usertags: refactor2020

Hi,

I am taking a step back from Debian for a while. To keep the list of
uploaders as an accurate list of people that you can talk to about this
package, please remove me from that list on the next upload.

Thanks,
Iain.

Bug#970315: txtorcon: please remove irl from uploaders

[Iain R. Learmonth]

Source: txtorcon
Severity: normal
User: i...@debian.org
Usertags: refactor2020
X-Debbugs-Cc: pkg-privacy-maintain...@lists.alioth.debian.org

Hi,

I am taking a step back from Debian for a while. To keep the list of
uploaders as an accurate list of people that you can talk to about this
package, please remove me from that list on the next upload.

Thanks,
Iain.

Bug#970314: pmix: Please extend the fix for #970194 for m68k and sh4

[John Paul Adrian Glaubitz]

Source: pmix
Severity: normal
User: debian-...@lists.debian.org
Usertags: m68k
X-Debbugs-Cc: debian-...@lists.debian.org

Hello!

Thanks for addressing #970194 [1]. While this fixes pmix on armel and mipsel,
the bug is still present on m68k and sh4 and therefore the architecture list
for linking against libatomic in debian/rules needs to be extended with
m68k and sh4.

Could you do that for the next upload? For the time being, I just patched and
built the pmix package for m68k and sh4 locally and uploaded it to the archive
to unlock the build of openmpi on m68k and sh4.

Thanks,
Adrian

> [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=970194

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

Bug#970313: slib: syntax error loading mzscheme.init

[Nick Gasson]

Package: slib
Version: 3b6-1
Severity: normal

Dear Maintainer,

Welcome to Racket v7.8.
> (load "/usr/share/slib/mzscheme.init")
; /usr/share/slib/mzscheme.init:307:6: if: missing an "else" expression
;   in: (if (provided? (quote trace)) (print-call-stack cep))
; [,bt for context]
> 

-- System Information:
Debian Release: bullseye/sid
  APT prefers testing
  APT policy: (650, 'testing'), (600, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages slib depends on:
ii  dpkg1.19.7
ii  install-info6.7.0.dfsg.2-5
ii  sensible-utils  0.0.12+nmu1

slib recommends no packages.

slib suggests no packages.

-- no debconf information

Bug#970312: src:intake: Please provide autopkgtest

[Nilesh Patra]

Source: intake
Version: 0.6.0-3
Severity: wishlist
Tags: newcomer

Dear Maintainer,

Please provide autopkgtest for this package.


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

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