Bug#961479: ardour has broken dependencies

[anon63]

Package: ardour
Version: 5.12.0-3
Severity: important

Dear Ardour Maintainer,

Ardour team announced recently the Ardour 6.0 release.
https://ardour.org/whatsnew.html

https://github.com/Ardour
And the current debian ardour binary package 5.12.0-3 depends on
an obsolete libfluidsynth.so from libfluidsynth1 removed from unstable

---
The following packages have unmet dependencies:
 ardour : Depends: libfluidsynth1 (>= 1.1.6-4~) but it is not installable
  Recommends: ardour-video-timeline but it is not going to be installed
E: Unable to correct problems, you have held broken packages.
---

This is problematic since Ardour also fails to build from source
cause of python-isodate and python-rdflib

---
The following information may help to resolve the situation:

The following packages have unmet dependencies:
 builddeps:ardour : Depends: python-isodate but it is not installable
Depends: python-rdflib but it is not installable
E: Unable to correct problems, you have held broken packages.
---

cf
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=946989
cf
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=942906
cf
https://salsa.debian.org/multimedia-team/ardour/commit/54e96b656cc0292d1b64bacc48ca49d2a2b8786f
However, building upstream ardour 6.0 with all the other build-dep packages 
suceeded

Best,

anon63

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

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

Versions of packages ardour depends on:
pn  ardour-data   
ii  jackd 5+nmu1
ii  libarchive13  3.4.2-1
ii  libasound21.2.2-2.1
ii  libatkmm-1.6-1v5  2.28.0-2
ii  libaubio5 0.4.9-4+b1
ii  libc6 2.30-8
ii  libcairo2 1.16.0-4
ii  libcairomm-1.0-1v51.12.2-4
ii  libcurl3-gnutls   7.68.0-1
ii  libcwiid1 0.6.00+svn201-5
ii  libfftw3-single3  3.3.8-2
pn  libfluidsynth1
ii  libfontconfig12.13.1-4.2
ii  libgcc-s1 [libgcc1]   10.1.0-2
ii  libgdk-pixbuf2.0-02.40.0+dfsg-4
ii  libglib2.0-0  2.64.2-1
ii  libglibmm-2.4-1v5 2.64.2-1
ii  libgtk2.0-0   2.24.32-4
ii  libgtkmm-2.4-1v5  1:2.24.5-4
ii  libjack-jackd2-0 [libjack-0.125]  1.9.12~dfsg-2+b1
ii  liblilv-0-0   0.24.8~dfsg0-1
ii  liblo70.30-3
ii  liblrdf0  0.6.1-2
ii  libltc11  1.3.1-1
ii  libpango-1.0-01.44.7-4
ii  libpangocairo-1.0-0   1.44.7-4
ii  libpangoft2-1.0-0 1.44.7-4
ii  libpangomm-1.4-1v52.42.1-1
ii  libqm-dsp01.7.1-4
ii  librubberband21.8.2-1
ii  libsamplerate00.1.9-2
ii  libsigc++-2.0-0v5 2.10.2-1
ii  libsndfile1   1.0.28-7
ii  libstdc++610.1.0-2
ii  libsuil-0-0   0.10.6-1
ii  libtag1v5 1.11.1+dfsg.1-2
ii  libusb-1.0-0  2:1.0.23-2
ii  libvamp-hostsdk3v52.9.0-1
ii  libvamp-sdk2v52.9.0-1
ii  libx11-6  2:1.6.9-2+b1
ii  libxml2   2.9.10+dfsg-5

Versions of packages ardour recommends:
pn  ardour-video-timeline   
ii  firefox [www-browser]   76.0.1-2
ii  google-chrome-stable [www-browser]  83.0.4103.61-1
ii  lynx [www-browser]  2.9.0dev.5-1

Versions of packages ardour suggests:
pn  jamin 
ii  qjackctl  0.6.2-1

Bug#961484: linkchecker: Linkchecker has new upstream

[Peter Chubb]

Package: linkchecker
Version: 9.4.0-2
Severity: normal

Dear Maintainer,
 the version of linkchecker packaged for Debian comes from
  https://github.com/wummel/linkchecker
 This version hasn't been maintained for years.  It was forked and 
 is now maintained at https://github.com/linkchecker/linkchecker

 The new version runs with Python 3,


-- Systes Information:
Debian Release: 10.3
  APT prefers stable
  APT policy: (990, 'stable'), (800, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 4.19.0-8-amd64 (SMP w/28 CPU cores)
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_AU.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages linkchecker depends on:
ii  libc6 2.28-10
ii  python2.7.16-1
ii  python-dnspython  1.16.0-1
ii  python-requests   2.21.0-1
ii  python-urllib31.24.1-1
ii  python-xdg0.25-5

linkchecker recommends no packages.

Versions of packages linkchecker suggests:
pn  clamav-daemon   
pn  linkchecker-web 
pn  python-argcomplete  
pn  python-cssutils 
pn  python-gconf
pn  python-geoip
pn  python-meliae   

-- no debconf information

Bug#846050: libvirt-daemon-system: Cannot create VM - cannot load AppArmor profile

[toby cabot]

Package: libvirt-daemon-system
Version: 5.0.0-4+deb10u1
Followup-For: Bug #846050

Dear Maintainer,

I hit the same error that the original poster does if I run this example 
command from the Debian wiki KVM page:

> tobyc@refectory:~$ virt-install --virt-type kvm --name buster-amd64 \
> > --location http://deb.debian.org/debian/dists/stable/main/installer-amd64/ \
> > --extra-args "console=ttyS0" -v --os-variant debian10 \
> > --disk size=10 --memory 1000
> 
> Starting install...
> Retrieving file linux...  
>   
> | 5.0 MB  00:00:00
> Retrieving file initrd.gz...  
>   
> |  29 MB  00:00:00
> Allocating 'buster-amd64.qcow2'   
>   
> |  10 GB  00:00:00
> ERRORinternal error: cannot load AppArmor profile 
> 'libvirt-7b5d99f5-b3f4-48a5-828f-7411b9e59ce7'
> Removing disk 'buster-amd64.qcow2'
>   
> |0 B  00:00:00
> Domain installation does not appear to have been successful.
> If it was, you can restart your domain by running:
>   virsh --connect qemu:///session start buster-amd64
> otherwise, please restart your installation.

If I add my user to the libvirt and kvm groups and "export 
LIBVIRT_DEFAULT_URI='qemu:///system'", however, I no longer get that error.

> tobyc@refectory:~$ virt-install --virt-type kvm --name buster-amd64 
> --location http://deb.debian.org/debian/dists/stable/main/installer-amd64/ 
> --extra-args "console=ttyS0" -v --os-variant debian10 --disk size=10 --memory 
> 1000
> 
> Starting install...
> Retrieving file linux...  
>   
> | 5.0 MB  00:00:00
> Retrieving file initrd.gz...  
>   
> |  29 MB  00:00:00
> Allocating 'virtinst-linux.5gs_3p8e'  
>   
> | 5.0 MB  00:00:00
> Transferring virtinst-linux.5gs_3p8e  
>   
> | 5.0 MB  00:00:00
> Allocating 'virtinst-initrd.gz.93yf6kgn'  
>   
> |  29 MB  00:00:00
> Transferring virtinst-initrd.gz.93yf6kgn  
>   
> |  29 MB  00:00:00
> Allocating 'buster-amd64.qcow2'   
>   
> |  10 GB  00:00:00
> ERRORRequested operation is not valid: network 'default' is not active
> Removing disk 'buster-amd64.qcow2'
>   
> |0 B  00:00:00
> Domain installation does not appear to have been successful.
> If it was, you can restart your domain by running:
>   virsh --connect qemu:///system start buster-amd64
> otherwise, please restart your installation.

HTH,
Toby


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

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

Versions of packages libvirt-daemon-system depends on:
ii  adduser3.118
ii  debconf [debconf-2.0]  1.5.71
ii  gettext-base   0.19.8.1-9
ii  iptables   1.8.2-4
ii  

Bug#961482: Drawing in backports request

[Leandro Cunha]

Package: drawing
Version: 0.4.11-1
Severity: normal
Tags: backports
Justification: Package already exists in testing

I did a rebuild of Drawing with the same version of testing for backports
in accordance with https://backports.debian.org/Contribute/ and sent an
email to the debian-backports mailing list a request in
https://lists.debian.org/debian-backports/2020/05/msg00055.html.

I just need access to Salsa to send the changes to a
debian/buster-backports branch in https://salsa.debian.org/debian/drawing.

Thanks!

Format: 1.8
Date: Sun, 24 May 2020 20:19:29 -0300
Source: drawing
Binary: drawing
Architecture: amd64
Version: 0.4.11-1~bpo10+1
Distribution: buster-backports
Urgency: medium
Maintainer: Andrej Shadura 
Changed-By: Leandro Cunha 
Description:
 drawing- simple drawing application for the GNOME desktop
Changes:
 drawing (0.4.11-1~bpo10+1) buster-backports; urgency=medium
 .
   * Rebuild for buster-backports.
Checksums-Sha1:
 3c9dfb85451a3461c57b74baa1bd34685dc18983 8924
drawing_0.4.11-1~bpo10+1_amd64.buildinfo
 699d24c544d114f8d873dff800fcf0d37b852f27 1029096
drawing_0.4.11-1~bpo10+1_amd64.deb
Checksums-Sha256:
 4581aa067d4bac32ed8e6d297251b67f3ff6e1b0a4cdf432145ccdfb61506c3b 8924
drawing_0.4.11-1~bpo10+1_amd64.buildinfo
 bcedf4448768400450120d7d8ea49452a6cdc12dc63c4aa7d842ac306bb7d692 1029096
drawing_0.4.11-1~bpo10+1_amd64.deb
Files:
 116905da1541aad929c5933ab82f51c8 8924 graphics optional
drawing_0.4.11-1~bpo10+1_amd64.buildinfo
 67c5cd14231317ea934d88c1c5e8cda6 1029096 graphics optional
drawing_0.4.11-1~bpo10+1_amd64.deb

Bug#961481: ceph: Protocol incompatibility between armhf and amd64

[Val Lorentz]

Package: ceph
Version: 14.2.9-1~bpo10+1

Dear maintainers,

I run a cluster made of armhf and amd64 OSDs, and amd64 monitors and
manager.

I recently updated my cluster from Luminous (12, in buster) to Nautilus
(14, in buster-backports), following the instructions here:
https://docs.ceph.com/docs/master/releases/nautilus/#upgrading-from-mimic-or-luminous

At some point (and after hot-fixing for #956293 on armhf machines), I
noticed something was off, as my OSDs kept flipping between up and down,
with all machines of one arch up and the others down.

Eventually, the armhf went down definitively down (in the monitors'
view). (This might be when I enabled msgr2, but I do not remember the
exact timing.)

Starting one of the armhf OSDs causes this kind of line to appear in
monitors' logs:

2020-05-25 02:07:55.681 7f142df5b700 -1 --2-
[v2:[fdfc:0:0:2::e]:3300/0,v1:[fdfc:0:0:2::e]:6789/0] >>
conn(0x55f003781a80 0x55f004589b80 unknown :-1 s=HELLO_ACCEPTING pgs=0
cs=0 l=0 rx=0 tx=0).run_continuation failed decoding of frame header:
buffer::bad_alloc


Moving the disk and config from an armhf to an arm64 machine fixes the
issue.

Bug#961044:

[patrick . peronny]

I found the problem upstream and a workaround : 
https://github.com/clementine-player/Clementine/issues/6522#issuecomment-588275235
 

Bug#961476: closed by Debian FTP Masters (reply to Clint Adams ) (Bug#961476: fixed in debianutils 4.10)

[Norbert Preining]

On Mon, 25 May 2020, Debian Bug Tracking System wrote:
>  debianutils (4.10) unstable; urgency=medium
>  .
>* installkernel: stay in /sbin. closes: #961476.
>* tempfile: add run-time deprecation warning.

Thanks for the quick fix!

Best

Norbert

--
PREINING Norbert  https://www.preining.info
Accelia Inc. + IFMGA ProGuide + TU Wien + JAIST + TeX Live + Debian Dev
GPG: 0x860CDC13   fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13

Bug#952284: mupdf: Include upstream html docs in the package

[John Scott]

I would appreciate inclusion to the HTML docs. The manpage seems out of date 
and doesn't include information on 'mutool sign' for example.

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

Bug#961480: adplug: Please package new upstream release (2.3.2)

[Boyuan Yang]

Source: adplug
Version: 2.3.1+dfsg-2
Tags: sid bullseye
Severity: important
X-Debbugs-CC: mmyan...@gmail.com

Dear Debian adplug maintainer,

The upstream developer of adplug has released a new version of adplug
(2.3.2), which contains several security fixes (CVE fixes). Please
consider packaging it in Debian.

-- 
Regards,
Boyuan Yang


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

Bug#961478: RFS: arc/5.21q-8 -- Archive utility based on the MSDOS ARC program

[Sudip Mukherjee]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "arc"

 * Package name: arc
   Version : 5.21q-8
   Upstream Author : Thom Henderson
 * URL : https://github.com/ani6al/arc
 * License : GPL-2
 * Vcs : https://salsa.debian.org/debian/arc
   Section : utils

It builds those binary packages:

  arc - Archive utility based on the MSDOS ARC program

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

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

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

  dget -x https://mentors.debian.net/debian/pool/main/a/arc/arc_5.21q-8.dsc

Changes since the last upload:

   * QA upload.
   * Update compat level to 13.
   * Fix FTBFS with gcc-10. (Closes: #957005)


-- 
Regards
Sudip

Bug#961477: libshairplay

[Vasyl Gello]

CC: bal...@balintreczey.hu, sramac...@debian.org

This is also for Kodi 19.0 "Matrix" targeting experimental.
-- 
Vasyl Gello

Bug#886642: fixed? (please default to a larger /boot for guided partitioning)

[McIntyre, Vincent (CASS, Marsfield)]

Hi

I thought this would have been fixed by this commit

https://salsa.debian.org/installer-team/partman-auto/-/commit/79bea1c75d2fd9fbd6eb01c1bea6de2914d24d22

which will be available in the 'daily' build of the installer.
I don't know what the prospects are for having this applied to
the 'stable' installer.

Kind regards
Vince

Bug#961477: RFS: libshairplay/1.0-1 [ITP] -- AirPort Express server emulator

[Vasyl Gello]

Package: sponsorship-requests
Severity: normal [important for RC bugs, wishlist for new packages]

Dear mentors,

I am looking for a sponsor for my package "libshairplay"

 * Package name: libshairplay
   Version : 0.9.0-1
   Upstream Author : juh...@iki.fi
 * URL : https://github.com/juhovh/shairplay
 * License : LGPL-2.1+
 * Vcs : https://salsa.debian.org/basilgello-guest/libshairplay
   Section : libs

It builds those binary packages:

  libshairplay0 - AirPort Express server emulator (shared library).
  shairplay - AirPort Express Server emulator (executable file).
  libshairplay-dev - AirPort Express Server emulator (development files).

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

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

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

  dget -x 
https://mentors.debian.net/debian/pool/main/libs/libshairplay/libshairplay_0.9.0-1.dsc

Changes since the last upload:

   * Initial release

Regards,

--
Vasyl Gello

Bug#961476: debianutils: installkernel in /usr/sbin is not found by kernel installation

[Norbert Preining]

Package: debianutils
Version: 4.9.3
Severity: important

Hi

I just did run a
make install
in the kernel source git repo, and was greeted with
sh ./arch/x86/boot/install.sh 5.7.0-rc7 arch/x86/boot/bzImage \
System.map "/boot"
Cannot find LILO.
The problem is that the install script uses
if [ -x ~/bin/${INSTALLKERNEL} ]; then exec ~/bin/${INSTALLKERNEL} 
"$@"; fi
if [ -x /sbin/${INSTALLKERNEL} ]; then exec /sbin/${INSTALLKERNEL} 
"$@"; fi
and thus this breaks.

Linking /sbin/installkernel -> /usr/sbin/installkernel fixes this
problem.

Best

Norbert

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

Kernel: Linux 5.7.0-rc6+ (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages debianutils depends on:
ii  libc6  2.30-8

debianutils recommends no packages.

debianutils suggests no packages.

-- no debconf information

Bug#961475: clusterssh: ssh_args doesn't work any more

[Samuel Thibault]

Package: clusterssh
Version: 4.15-1
Severity: important
Tags: patch upstream

Hello,

With the new update, cssh was not working any more with 

  ssh_args = -x -o ConnectTimeout=30

because for "cssh mysshbox" it'd run

  ssh -x -o ConnectTimeout=30mysshbox

The attached patch fixes this.

Samuel

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

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

Versions of packages clusterssh depends on:
ii  libexception-class-perl 1.44-1
ii  libtry-tiny-perl0.30-1
ii  libx11-protocol-other-perl  31-1
ii  libx11-protocol-perl0.56-7
ii  openssh-client  1:8.2p1-4
ii  perl5.30.2-1
ii  perl-tk 1:804.033-2+b4
ii  xterm   356-1

clusterssh recommends no packages.

clusterssh suggests no packages.

-- no debconf information

-- 
Samuel
 what the fuck is wtf
--- a/lib/App/ClusterSSH/Helper.pm
+++ b/lib/App/ClusterSSH/Helper.pm
@@ -71,7 +71,7 @@ sub script {
my \$user=shift;
my \$port=shift;
my \$mstr=shift;
-   my \$command="$command_pre $comms $comms_args";
+   my \$command="$command_pre $comms $comms_args ";
open(PIPE, ">", \$pipe) or die("Failed to open pipe: \$!\\n");
print PIPE "\$\$:\$ENV{WINDOWID}" 
or die("Failed to write to pipe: $!\\n");

Bug#961474: nut-client can't be run without nut-server installed

[David Engel]

Package: nut-client
Version: 2.7.4-12
Severity: important

Dear Maintainer,

I have two systems connected to a single UPS.  The first system
running both nut-server and nut-client packages works fine.  The
second system running only nut-client experiences this problem.

Systemd can't sucessfully start the nut-monitor.service.  The reason
is that the /run/nut directory does not exist for upsmon to write its
pid file.  Even though upsmon starts and connects to the remote
server, systemd eventually kills it becuase the pid file never gets
written.

The undesirable work around is to install the nut-server package so
that something run by it creates /run/nut before upsmon is run.  This
also results in systemd attempting and failing to start the nut-driver
service.  The nut-server service is started but it benignly succeeds
without starting upsd becaue MODE is set to netclient in
/etc/nut/nut.conf.  The nut-driver service failure causes systemd to
that the system is in a degraded state because the unnecessary
nut-driver.service failed to start.

Ideally, upsmon should create the /run/nut directory if needed so the
nut-server package doesn't not need to be installed.  Alternatively,
the nut-driver service should succeed benignly when not needed in the
same way the nut-server service does.

David Engel
da...@istwok.net

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

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

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


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

Kernel: Linux 5.6.0-1-amd64 (SMP w/16 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE= 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages nut-client depends on:
ii  adduser  3.118
ii  init-system-helpers  1.57
ii  libc62.30-8
ii  libupsclient42.7.4-12
ii  lsb-base 11.1.0

Versions of packages nut-client recommends:
ii  bash-completion  1:2.10-1

Versions of packages nut-client suggests:
pn  nut-monitor  

-- Configuration Files:
/etc/nut/nut.conf [Errno 13] Permission denied: '/etc/nut/nut.conf'
/etc/nut/upsmon.conf [Errno 13] Permission denied: '/etc/nut/upsmon.conf'
/etc/nut/upssched.conf [Errno 13] Permission denied: '/etc/nut/upssched.conf'

-- no debconf information

Bug#961454: dahdi-dkms: Cannot compile using DKMS on kernel 5.4 backport and latter

[Patrick ZAJDA]

Package: dahdi-dkms
Version: 1:2.11.1.0.20170917~dfsg-7
Severity: important

Dear Maintainer,

When installing kernel 5.4 or 5.5 from buster-backports or running 
dpkg-reconfigure dahdi-dkms, there is an error inviting to consulte make.log.
This is the make.log I had after the error: http://ix.io/2n8n
It looks like there is an incompatibility with kernel 5.4 and 5.5 which 
prevents the compilation of DAHDI kernel modules.


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

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

Versions of packages dahdi-dkms depends on:
ii  dkms   2.6.1-4
ii  dpkg-dev   1.19.7
ii  gawk   1:4.2.1+dfsg-1
ii  gcc4:8.3.0-1
ii  libc6-dev  2.28-10
ii  make   4.2.1-1.2
ii  wget   1.20.1-1.1

Versions of packages dahdi-dkms recommends:
ii  dahdi-linux  1:2.11.1.0.20170917~dfsg-7

dahdi-dkms suggests no packages.

-- no debconf information

Bug#961044:

[Thomas Pierson]

forwarded 961044 https://github.com/clementine-player/Clementine/issues/6522
thanks

Hi Patrick,

24 mai 2020 23:51:08 patrick.pero...@laposte.net:
> I found the problem upstream and a workaround : 
> https://github.com/clementine-player/Clementine/issues/6522#issuecomment-588275235

Thank you for the report and the upstream issue link. I link it here and I will 
follow that.

Best regards,
Thomas Pierson

Bug#961097: Despite all odds, this turned out to be a problem in ncurses; it's good, I promise

[наб]

reassign 961097 libncurses6 6.2-1
retitle 961097 libncurses6: unloads libgpm2 in SIGTSTP handler, process returns 
to unmapped address on resume
severity 961097 normal
thanks


I tested this with the following package versions:
-- >8 --
nabijaczleweli@szarotka:~$ dpkg -l htop* *gpm* libncurses6*
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name   Version  Architecture Description
+++-==---==
ii  gpm1.20.7-6.8   x32  General Purpose Mouse 
interface
ii  gpm-dbgsym 1.20.7-6.8   x32  debug symbols for gpm
ii  htop   2.2.0-2  x32  interactive processes 
viewer
ii  htop-dbgsym2.2.0-2  x32  debug symbols for htop
ii  libgpm2:x321.20.7-6.8   x32  General Purpose Mouse - 
shared library
ii  libgpm2-dbgsym:x32 1.20.7-6.8   x32  debug symbols for libgpm2
ii  libncurses6:x326.2-1x32  shared libraries for 
terminal handling
ii  libncurses6-dbgsym:x32 6.2-1x32  debug symbols for 
libncurses6

misio@aqq:~$ dpkg -l htop* *gpm* libncurses6*
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name  Version  Architecture Description
+++-=---==
ii  gpm   1.20.7-6 amd64General Purpose Mouse interface
ii  htop  2.2.0-2  amd64interactive processes viewer
ii  libgpm2:amd64 1.20.7-6 amd64General Purpose Mouse - shared 
library
ii  libncurses6:amd64 6.2-1amd64shared libraries for terminal 
handling
-- >8 --

The setup required:
1. One (preferably two) virtual terminals you can write to,
   likely by logging in
   (here /dev/tty1 will be the main one,
and  /dev/tty2 will be a dump terminal);
   this is of critical importance ‒
   you *need* to be on a teletype to reproduce this
   (presumably an X session that uses gpm for the mouse would also work?
I haven't tried that, I'm not sure how I'd even set that up,
especially in a.d. 2020)
2. gpm running in the main terminal,
   verify that it works by copy-pasting something;
   (this will *not* happen if the controlling tty is not a tty
e.g. redirected via script(1));
3. htop (presumably any ncurses program that uses the mouse,
none came to mind; would love to try some ‒ suggestions?)


The base repro:

The optional redirection does not affect any part of this,
but makes the output palatable.

However, if you click about on the *main* terminal,
you should see the selection update on the *output* one;
this is obvious if they're one and the same (no redirection),
less obvious if they are not.

-- >8 --
$ htop [> /dev/tty2]
^Z
fg
htop 2.2.0 aborting. Please report bug at http://hisham.hm/htop
Segmentation fault
-- >8 --

That is, of course, if you're lucky ‒ this only happens on my x32 system
with no additional output on amd64, press Enter to get a shell prompt.


Verifying that this is what happens:

Build override.c:
-- >8 --
// cc -ooverride.so override.c -fPIC -shared
#include 
int dlclose(void * handle) {
  fprintf(stderr, "dlclose(%p)\n", handle);
  return 0;
}
-- >8 --

Invoke (no address sanitiser):
-- >8 --
$ LD_PRELOAD=./noclose.so htop
nabijaczleweli@szarotka:/mnt/zest/htop$ LD_PRELOAD=./override.so htop > 
/dev/tty2
^Zdlclose(0x57da5520)

[1]+  Stopped LD_PRELOAD=./override.so htop > /dev/tty2
nabijaczleweli@szarotka:/mnt/zest/htop$ fg
LD_PRELOAD=./override.so htop > /dev/tty2
^Zdlclose(0x57da5520)

[1]+  Stopped LD_PRELOAD=./override.so htop > /dev/tty2
nabijaczleweli@szarotka:/mnt/zest/htop$ fg
LD_PRELOAD=./override.so htop > /dev/tty2
^Zdlclose(0x57da5520)

[1]+  Stopped LD_PRELOAD=./override.so htop > /dev/tty2
nabijaczleweli@szarotka:/mnt/zest/htop$ fg
LD_PRELOAD=./override.so htop > /dev/tty2
q
dlclose(0x57da5520)
nabijaczleweli@szarotka:/mnt/zest/htop$
-- >8 --

Invoke (ASAN htop build):
-- >8 --
nabijaczleweli@szarotka:/mnt/zest/htop$ 
LD_PRELOAD=/lib/x86_64-linux-gnux32/libasan.so.5:./override.so ./htop/htop > 
/dev/tty2
^Zdlclose(0xf4802e00)

[1]+  Stopped 
LD_PRELOAD=/lib/x86_64-linux-gnux32/libasan.so.5:./override.so ./htop/htop > 
/dev/tty2
nabijaczleweli@szarotka:/mnt/zest/htop$ fg
LD_PRELOAD=/lib/x86_64-linux-gnux32/libasan.so.5:./override.so ./htop/htop > 
/dev/tty2
^Zdlclose(0xf4802e00)

[1]+  Stopped 
LD_PRELOAD=/lib/x86_64-linux-gnux32/libasan.so.5:./override.so ./htop/htop > 
/dev/tty2
nabijaczleweli@szarotka:/mnt/zest/htop$ fg

Bug#961472: libmail-dkim-perl: dkimproxy-sign breaks RFC with hardcoded deprecated signing algo

[Christer Mjellem Strand]

[..]

While ideally the user should be allowed to choose, if it is going to
be hardcoded, at least the hardcoded value should be SHA-256 rather
than SHA-1. The supplied patch addresses this, and I would appreciate
if it could be applied.


Actually, looking a bit more closely at the code, it turns out the user 
*is* allowed to choose, by applying the --algorithm argument. This, 
however, appears entirely undocumented, as there's no mention of it in 
neither the man page nor with dkimproxy-sign --help. I suppose that's 
worthy of another report, as there are apparently a slew of 
undocumented arguments:


my $type = "dkim";
my $selector = "selector1";
my $algorithm = "rsa-sha1";
my $method = "simple";
my $domain; # undef => auto-select domain
my $expiration;
my $identity;
my $key_file = "private.key";
my $key_protocol;
my @extra_tag;
my $debug_canonicalization;
my $binary;
my $help;

I still think the patch should be applied, though (even with its 
mis-spelled name..), as it at least updates the default to a sane and 
RFC-conformant level.


Cheers

--
Christer Mjellem Strand
System Administrator

pgpDILXEDpD4O.pgp
Description: PGP signature

Bug#960832: notfixed in ubuntu...

[Gianfranco Costamagna]

control: unarchive -1
control: reopen -1

Hello, I tried 0.65 and testsuite failed with:
==
FAIL: test_add_new (lintian_brush.tests.test_run.ChangelogAddEntryTests)
lintian_brush.tests.test_run.ChangelogAddEntryTests.test_add_new
--
testtools.testresult.real._StringException: log: {{{
2.311  creating repository in 
file:///tmp/testbzr-6n26vnuu.tmp/lintian_brush.tests.test_run.ChangelogAddEntryTests.test_add_new/work/.bzr/.
2.312  creating branch  in 
file:///tmp/testbzr-6n26vnuu.tmp/lintian_brush.tests.test_run.ChangelogAddEntryTests.test_add_new/work/
2.316  trying to create missing lock 
'/tmp/testbzr-6n26vnuu.tmp/lintian_brush.tests.test_run.ChangelogAddEntryTests.test_add_new/work/.bzr/checkout/dirstate'
2.318  opening working tree 
'/tmp/testbzr-6n26vnuu.tmp/lintian_brush.tests.test_run.ChangelogAddEntryTests.test_add_new/work'
}}}

Traceback (most recent call last):
  File "/<>/lintian_brush/tests/test_run.py", line 913, in 
test_add_new
self.assertEqual([
  File "/usr/lib/python3/dist-packages/breezy/tests/__init__.py", line 1315, in 
assertEqual
raise AssertionError("%snot equal:\na = %s\nb = %s\n"
AssertionError: not equal:
a = ['lintian-brush (0.36) UNRELEASED; urgency=medium', '', '  * Add a foo', '']
b = ['lintian-brush (0.35ubuntu1) UNRELEASED; urgency=medium',
 '',
 '  * Add a foo',
 '']


--
Ran 581 tests in 39.308s

FAILED (failures=1, expected failures=1)
Test failed: 
error: Test failed: 
E: pybuild pybuild:352: test: plugin distutils failed with: exit code=1: 
python3.8 setup.py test 
dh_auto_test: error: pybuild --test -i python{version} -p 3.8 returned exit 
code 13
make: *** [debian/rules:6: binary] Error 25
dpkg-buildpackage: error: debian/rules binary subprocess returned exit status 2


Can you please have another deeper look?

thanks!

G.

Bug#881719: libcdio 2.1.0 and lubcdio++

[Vasyl Gello]

Hi Gabriel!

May 24, 2020 9:40:59 PM UTC, "Gabriel F. T. Gomes"  
написав(-ла):
>
>Initially, and because I was a little
>uncomfortable with the soname change, I thought about uploading to
>experimental first. Would that work for you?
>

Yes experimental is OK for me, even though I uploaded libshairplay & libudfread 
to unstable queue. Balint asked me initially to target Kodi 19.0 to 
experimental so I will probably re-upload both libraries to experimental to 
keep everything consistent.

I will dedicate some time to check iso9660 & udf images processing within Kodi 
and let you know how it goes!

Sincerely,
-- 
Vasyl Gello

Bug#961296: mirrors: apt not working on an IPv6 only host with a ipv6 only (local) resolver

[Marco d'Itri]

On May 24, Max Grobecker  wrote:

> This is a growing problem and
[citation needed]

> if Fastly is not able to fix it, you 
> maybe should stop making "deb.debian.org" the default mirror.
Or maybe you should use a different mirror, if the current default does 
not work for you. This is one of the reasons why we have many.

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Bug#961450: changelog.gz is different between amd64 and i386 packages

[Andriy Ushakov]

apt --fix-broken install
...
Preparing to unpack .../libsqlite3-0_3.32.0-1_amd64.deb ...
Unpacking libsqlite3-0:amd64 (3.32.0-1) over (3.31.1-5) ...
dpkg: error processing archive 
/var/cache/apt/archives/libsqlite3-0_3.32.0-1_amd64.deb (--unpack):
 trying to overwrite shared '/usr/share/doc/libsqlite3-0/changelog.gz', which 
is different from other instances of package libsqlite3-0:amd64
dpkg-deb: error: paste subprocess was killed by signal (Broken pipe)
Errors were encountered while processing:
 /var/cache/apt/archives/libsqlite3-0_3.32.0-1_amd64.deb
E: Sub-process /usr/bin/dpkg returned an error code (1)

The installation and removal of any packages are failing too:
...
The following packages have unmet dependencies:
 libsqlite3-0 : Breaks: libsqlite3-0:i386 (!= 3.31.1-5) but 3.32.0-1 is to be 
installed
 libsqlite3-0:i386 : Breaks: libsqlite3-0 (!= 3.32.0-1) but 3.31.1-5 is to be 
installed
 libsqlite3-dev : Depends: libsqlite3-0 (= 3.32.0-1) but 3.31.1-5 is to be 
installed
 sqlite3 : Depends: libsqlite3-0 (= 3.32.0-1) but 3.31.1-5 is to be installed
E: Unmet dependencies. Try 'apt --fix-broken install' with no packages (or 
specify a solution).

What can be done until the issue with libsqlite3-0 will be fixed, to be able to 
install/remove packages?

Regards,
Andriy

Bug#961473: libreoffice-kde5: The libreoffice templates in /usr/share/templates are set to Letter page size

[Steve Russell]

Package: libreoffice-kde5
Version: 1:6.1.5-3+deb10u6
Severity: normal

Dear Maintainer,

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

When I create a new LibreOffice Writer document using the Create New function 
in Dolphin, the
new document has the page size set to Letter. When I attempt to print this 
document it fails
because my printer does not have Letter size paper.

I would expect that the installer should detect whether my localization 
settings are using Letter
or A4 and install the appropriate template for this paper size.


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

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

Versions of packages libreoffice-kde5 depends on:
ii  kio5.54.1-1
ii  libatk1.0-02.30.0-2
ii  libboost-filesystem1.67.0  1.67.0-13+deb10u1
ii  libc6  2.28-10
ii  libcairo-gobject2  1.16.0-4
ii  libcairo2  1.16.0-4
ii  libdbus-1-31.12.16-1
ii  libdbus-glib-1-2   0.110-4
ii  libepoxy0  1.5.3-0.1
ii  libgcc11:8.3.0-6
ii  libgdk-pixbuf2.0-0 2.38.1+dfsg-1
ii  libglib2.0-0   2.58.3-2+deb10u2
ii  libgraphite2-3 1.3.13-7
ii  libgtk-3-0 3.24.5-1
ii  libharfbuzz-icu0   2.3.1-1
ii  libharfbuzz0b  2.3.1-1
ii  libice62:1.0.9-2
ii  libkf5configcore5  5.54.0-1+deb10u1
ii  libkf5coreaddons5  5.54.0-1
ii  libkf5i18n55.54.0-1
ii  libkf5kiocore5 5.54.1-1
ii  libkf5kiofilewidgets5  5.54.1-1
ii  libkf5kiowidgets5  5.54.1-1
ii  libkf5windowsystem55.54.0-1
ii  libpango-1.0-0 1.42.4-8~deb10u1
ii  libpangocairo-1.0-01.42.4-8~deb10u1
ii  libqt5core5a   5.11.3+dfsg1-1+deb10u3
ii  libqt5gui5 5.11.3+dfsg1-1+deb10u3
ii  libqt5network5 5.11.3+dfsg1-1+deb10u3
ii  libqt5widgets5 5.11.3+dfsg1-1+deb10u3
ii  libqt5x11extras5   5.11.3-2
ii  libreoffice-core   1:6.1.5-3+deb10u6
ii  libsm6 2:1.2.3-1
ii  libstdc++6 8.3.0-6
ii  libx11-6   2:1.6.7-1
ii  libxcb11.13.1-2
ii  libxext6   2:1.3.3-1+b2
ii  uno-libs3  6.1.5-3+deb10u6
ii  ure6.1.5-3+deb10u6

Versions of packages libreoffice-kde5 recommends:
ii  libreoffice-style-breeze  1:6.1.5-3+deb10u6

libreoffice-kde5 suggests no packages.

-- debconf-show failed

Bug#881719: libcdio 2.1.0 and lubcdio++

[Gabriel F. T. Gomes]

Hi, Vasyl,

on 24 May 2020, Vasyl Gello wrote:
>
>Gabriel has prepared 2.1.0 in his Salsa repo and I added C++ interfaces needed 
>by Kodi 19.0: 
>https://salsa.debian.org/gabrielftg-guest/libcdio/-/merge_requests/1

Thank you so much for writing this pull requests. I wasn't aware that
there was a C++ interface in libcdio. I'm actually very new to libcdio;
I only came across it because it is a dependency of another project
(pragha) that I mantain.

I'll review your merge request as soon as possible, then I'll prepare a
package for uploading. Initially, and because I was a little
uncomfortable with the soname change, I thought about uploading to
experimental first. Would that work for you?

>Can the version 2.1.0 be pushed into distribution?

Please bear in mind that we will have to go through the NEW queue,
because of the new binary packages (not just the C++ libraries, but
also because of the soname bump on the C library).


Cheers,
Gabriel

Bug#951722: autopkgtest suite flaky on arm64

[Nis Martensen]

control: tags -1 patch

Michael sent me his draft patch. Slightly modified version with added
commit message attached. Diff is against latest upstream git version.

Thanks Michael!
>From 89399122692823bc215cf1097b05da4ee2201e0e Mon Sep 17 00:00:00 2001
From: Nis Martensen 
Date: Sun, 24 May 2020 22:05:42 +0200
Subject: [PATCH 1/2] systemd integration: notify service manager when ready

With Type=simple or Type=forking, systemd does not really know when the
service is ready to accept connections and might start depending
services too early. Use Type=notify to explicitly tell the service
manager when the service is ready.

For a real problem caused by assuming readiness too early, please see
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=951722

For the meaning of the service type and details of the readiness
protocol, see also the following links:
https://www.freedesktop.org/software/systemd/man/systemd.service.html#Type=
https://www.freedesktop.org/software/systemd/man/sd_notify.html

As discussed in the last link, more elaborate state notifications are
possible. This patch only implements the most basic part.

Original patch prepared by Michael Biebl, with slight modification.
---
 dovecot.service.in   | 3 +--
 src/lib-master/master-service-settings.c | 2 +-
 src/master/main.c| 6 ++
 3 files changed, 8 insertions(+), 3 deletions(-)

diff --git a/dovecot.service.in b/dovecot.service.in
index 5c45f590b..a1df992c5 100644
--- a/dovecot.service.in
+++ b/dovecot.service.in
@@ -14,9 +14,8 @@ Documentation=http://wiki2.dovecot.org/
 After=local-fs.target network-online.target
 
 [Service]
-Type=simple
+Type=notify
 ExecStart=@sbindir@/dovecot -F
-PIDFile=@rundir@/master.pid
 ExecReload=@bindir@/doveadm reload
 ExecStop=@bindir@/doveadm stop
 PrivateTmp=true
diff --git a/src/lib-master/master-service-settings.c b/src/lib-master/master-service-settings.c
index 657ef66bc..c7b8b369c 100644
--- a/src/lib-master/master-service-settings.c
+++ b/src/lib-master/master-service-settings.c
@@ -62,7 +62,7 @@ static const struct setting_define master_service_setting_defines[] = {
 
 /*  */
 #ifdef HAVE_SYSTEMD
-#  define ENV_SYSTEMD " LISTEN_PID LISTEN_FDS"
+#  define ENV_SYSTEMD " LISTEN_PID LISTEN_FDS NOTIFY_SOCKET"
 #else
 #  define ENV_SYSTEMD ""
 #endif
diff --git a/src/master/main.c b/src/master/main.c
index 6e0e68fe7..08bea05ed 100644
--- a/src/master/main.c
+++ b/src/master/main.c
@@ -26,6 +26,9 @@
 #include "service-process.h"
 #include "service-log.h"
 #include "dovecot-version.h"
+#ifdef HAVE_SYSTEMD
+#include "sd-daemon.h"
+#endif
 
 #include 
 #include 
@@ -544,6 +547,9 @@ static void main_init(const struct master_settings *set)
 	master_clients_init();
 
 	services_monitor_start(services);
+#ifdef HAVE_SYSTEMD
+	sd_notify(0, "READY=1");
+#endif
 	startup_finished = TRUE;
 }
 
-- 
2.20.1

Bug#949638: tesseract: uses -march=native

[Adrian Bunk]

On Sun, May 24, 2020 at 10:14:49PM +0200, Stefan Weil wrote:
> Adrian, I am afraid that there is a misunderstanding.
> 
> The code part which is compiled with -march=native is never executed by
> default.

I get that point.

> There is a command line option which allows users to select the code
> which is used for certain time critical calculations (dot product). A
> wrong choice is not a security problem

You misunderstand the part about the security update,
security updates are just the most common reason why
a package gets updated (and therefore rebuilt) in a
stable distribution.

Example:
Debian 11 will be released in summer 2021.
In autumn 2021 a user sets up a new system and selects "native"
for an important production setup with an Intel CPU.
In spring 2022 a (security or other) update for Tesseract happens
in Debian 11, built on a buildd with the latest AMD CPU.
The working production setup suddenly always crashes.

> That's quite common for other packages including the standard C
> library and scientific libraries, too. They all contain optimized
> functions which require certain hardware and which crash otherwise.

With proper runtime autodetection of the hardware, if you manage to get 
a crash it is a bug in these packages. It is quite rare that packages 
offer manual selection in addition to autodetection.

> but simply will crash the
> application, no matter whether the user selected "native", "avx" or
> "neon".

Even when built on the same computer I would have doubts whether
automatic vectorization[1] of the trivial C code really beats the 
hand-written AVX2 code, but when the code is not even built for
the computer in question what's the point?

A "native" option meaning "some random buildd somewhere" is just
confusing, it doesn't make sense for distributions.

> Regards
> 
> Stefan

cu
Adrian

[1] if it happens at all, the Debian package build currently overwrites
the -O3 with a subsequent -O2

Bug#961146: systemd-logind sometimes ignores a systemd-inhibit lock

[Vincent Lefevre]

On 2020-05-23 16:53:06 +0200, Michael Biebl wrote:
> Am 23.05.20 um 02:59 schrieb Vincent Lefevre:
> > On 2020-05-22 23:53:58 +0200, Michael Biebl wrote:
> >> This is strange. Something is triggering the start of systemd-logind
> > 
> > What do you mean by "start of systemd-logind"?
> > 
> > On my machine, systemd-logind is started early at boot time and
> > never quits.
> 
> You said:
> 
> > The running instance cannot be stopped as it is automatically
> > restarted. 
> 
> when I adviced you to stop the running systemd-logind.service and
> starting logind by hand.

OK, if I do "service systemd-logind stop", it is effectively
stopped. Then I start

  SYSTEMD_LOG_LEVEL=debug /lib/systemd/systemd-logind

from VT 1. I log in on VT 2, start the inhibitor and log out, then
I close the lid. Nothing happens. Then I switch to VT 3, and the
system suspends immediately. So, same issue. In the logs:

May 24 23:12:50 zira dhclient[2527]: DHCPREQUEST for 192.168.1.3 on eth0 to 
192.168.1.1 port 67
May 24 23:12:50 zira dhclient[2527]: DHCPACK of 192.168.1.3 from 192.168.1.1
May 24 23:12:50 zira root[568208]: 
/etc/dhcp/dhclient-enter-hooks.d/google-tcp-dns with reason=RENEW
May 24 23:12:50 zira root[568219]: 
/etc/dhcp/dhclient-exit-hooks.d/0google-tcp-dns with reason=RENEW
May 24 23:12:50 zira dhclient[2527]: bound to 192.168.1.3 -- renewal in 33912 
seconds.
May 24 23:13:09 zira login[158128]: pam_unix(login:auth): Couldn't open 
/etc/securetty: No such file or directory
May 24 23:13:12 zira login[158128]: pam_unix(login:auth): Couldn't open 
/etc/securetty: No such file or directory
May 24 23:13:12 zira login[158128]: pam_unix(login:session): session opened for 
user vinc17 by LOGIN(uid=0)
May 24 23:13:12 zira systemd[1]: Created slice User Slice of UID 1000.
May 24 23:13:12 zira systemd[1]: Starting User Runtime Directory 
/run/user/1000...
May 24 23:13:12 zira systemd[1]: Finished User Runtime Directory /run/user/1000.
May 24 23:13:12 zira systemd[1]: Starting User Manager for UID 1000...
May 24 23:13:12 zira systemd[568233]: pam_unix(systemd-user:session): session 
opened for user vinc17 by (uid=0)
May 24 23:13:12 zira systemd[568238]: gpgconf: error running 
'/usr/lib/gnupg/scdaemon': probably not installed
May 24 23:13:12 zira systemd[568233]: Reached target Paths.
May 24 23:13:12 zira systemd[568233]: Reached target Timers.
May 24 23:13:12 zira systemd[568233]: Starting D-Bus User Message Bus Socket.
May 24 23:13:12 zira systemd[568233]: Listening on GnuPG network certificate 
management daemon.
May 24 23:13:12 zira systemd[568233]: Listening on GnuPG cryptographic agent 
and passphrase cache (access for web browsers).
May 24 23:13:12 zira systemd[568233]: Listening on GnuPG cryptographic agent 
and passphrase cache (restricted).
May 24 23:13:12 zira systemd[568233]: Listening on GnuPG cryptographic agent 
(ssh-agent emulation).
May 24 23:13:12 zira systemd[568233]: Listening on GnuPG cryptographic agent 
and passphrase cache.
May 24 23:13:12 zira systemd[568233]: Listening on Sound System.
May 24 23:13:12 zira systemd[568233]: Listening on D-Bus User Message Bus 
Socket.
May 24 23:13:12 zira systemd[568233]: Reached target Sockets.
May 24 23:13:12 zira systemd[568233]: Reached target Basic System.
May 24 23:13:12 zira systemd[1]: Started User Manager for UID 1000.
May 24 23:13:12 zira systemd[568233]: Starting Sound Service...
May 24 23:13:12 zira systemd[1]: Started Session 919 of user vinc17.
May 24 23:13:12 zira rtkit-daemon[793]: Successfully made thread 568253 of 
process 568253 owned by '1000' high priority at nice level -11.
May 24 23:13:12 zira rtkit-daemon[793]: Supervising 1 threads of 1 processes of 
1 users.
May 24 23:13:12 zira systemd[568233]: Started D-Bus User Message Bus.
May 24 23:13:12 zira kernel: snd_hda_codec_hdmi hdaudioC1D0: HDMI: invalid ELD 
data byte 57
May 24 23:13:12 zira rtkit-daemon[793]: Supervising 1 threads of 1 processes of 
1 users.
May 24 23:13:12 zira rtkit-daemon[793]: Successfully made thread 568375 of 
process 568253 owned by '1000' RT at priority 5.
May 24 23:13:12 zira rtkit-daemon[793]: Supervising 2 threads of 1 processes of 
1 users.
May 24 23:13:13 zira rtkit-daemon[793]: Supervising 2 threads of 1 processes of 
1 users.
May 24 23:13:13 zira rtkit-daemon[793]: Successfully made thread 568376 of 
process 568253 owned by '1000' RT at priority 5.
May 24 23:13:13 zira rtkit-daemon[793]: Supervising 3 threads of 1 processes of 
1 users.
May 24 23:13:13 zira rtkit-daemon[793]: Supervising 3 threads of 1 processes of 
1 users.
May 24 23:13:13 zira rtkit-daemon[793]: Successfully made thread 568377 of 
process 568253 owned by '1000' RT at priority 5.
May 24 23:13:13 zira rtkit-daemon[793]: Supervising 4 threads of 1 processes of 
1 users.
May 24 23:13:13 zira systemd[568233]: Started Sound Service.
May 24 23:13:13 zira systemd[568233]: Reached target Main User Target.
May 24 23:13:13 zira systemd[568233]: Startup finished in 684ms.
May 24 23:13:13 zira bluetoothd[773]: 

Bug#961377: raspi3-firmware: recent stable update causes non-booting systems

[Gunnar Wolf]

tags 961377 + confirmed,pending
thanks

Thorsten Glaser dijo [Sat, May 23, 2020 at 08:55:01PM +0200]:
> Package: raspi3-firmware
> Version: 1.20190215-1+deb10u3
> Severity: critical
> Tags: patch buster
> Justification: breaks the whole system
> 
> /etc/kernel/postinst.d/z50-raspi3-firmware in +deb10u3 contains:
> 
>67   for dtn in ${dtb_path}/bcm*.dtb; do
>68 [ -e "${dtb}" ] && cp "${dtb}" /boot/firmware/
>69   done
> 
> It’s hard to see, a typo, and not in unstable (where commit
> 165f43a6ca14d240f199e8ab8924e503ca5f427d got it right), but
> commit fc3df0e8c64c2c62a54e0efcd226e36f28ccd3a4 uses “dtn”,
> not “dtb”, as for variable, but refers to “dtb”.

VERY GOOD CATCH! Thanks a lot for this. I'm pushing it to Git right
away, and will try to push a new version soon. It slipped under my
nose :-(

I will try to build+test+upload this in the next couple of days.


https://salsa.debian.org/debian/raspi-firmware/-/commit/2bf38f62de0514c2759f2c33d147c935e4d044bf

Bug#961472: libmail-dkim-perl: dkimproxy-sign breaks RFC with hardcoded deprecated signing algo

[Christer Mjellem Strand]

Package: libmail-dkim-perl
Version: 0.54-1
Severity: normal

Dear Maintainer,

This package ships with /usr/bin/dkimproxy-sign, from dkim-proxy, which is 
hardcoded to use rsa-sha1 for signing.
Beyond being generally weak, SHA-1 is now explicitly banned for DKIM use by RFC 
8301:

"Due to the recognized weakness of the SHA-1 hash algorithm (see [RFC6194]) and 
the wide availability of the SHA-256
hash algorithm (it has been a required part of DKIM [RFC6376] since it was 
originally standardized in 2007), the
SHA-1 hash algorithm MUST NOT be used."

While ideally the user should be allowed to choose, if it is going to be 
hardcoded, at least the hardcoded value
should be SHA-256 rather than SHA-1. The supplied patch addresses this, and I 
would appreciate if it could be
applied.

Thanks.

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

Kernel: Linux 4.19.0-0.bpo.5-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages libmail-dkim-perl depends on:
ii  libcrypt-openssl-rsa-perl 0.31-1+b1
ii  libdigest-sha-perl6.02-1+b1
ii  liberror-perl 0.17027-2
ii  libmailtools-perl 2.18-1
ii  libnet-dns-perl   1.19-1
ii  libperl5.24 [libdigest-sha-perl]  5.24.1-3+deb9u5
ii  perl [libdigest-sha-perl] 5.28.1-6

libmail-dkim-perl recommends no packages.

libmail-dkim-perl suggests no packages.

-- no debconf information
--- /usr/bin/dkimproxy-sign 2018-12-04 21:15:55.0 +0100
+++ /usr/local/bin/dkimproxy-sign   2020-05-24 22:34:35.585654976 +0200
@@ -16,7 +16,7 @@
 
 my $type = "dkim";
 my $selector = "selector1";
-my $algorithm = "rsa-sha1";
+my $algorithm = "rsa-sha256";
 my $method = "simple";
 my $domain; # undef => auto-select domain
 my $expiration;

Bug#961458: ippusbxd: Please consider installing a systemd service file by default

[Till Kamppeter]

I have done this already for Ubuntu in the 1.34-2ubuntu1 package. "dpkg 
-L ippusbxd" gives the following 4 non-documentation files in the package:


/.
/etc
/etc/apparmor.d
/etc/apparmor.d/usr.sbin.ippusbxd
/lib
/lib/systemd
/lib/systemd/system
/lib/systemd/system/ippusbxd@.service
/lib/udev
/lib/udev/rules.d
/lib/udev/rules.d/55-ippusbxd.rules
/usr
/usr/sbin
/usr/sbin/ippusbxd

With this USB printers supporting IPP-over-USB will get their ippusbxd 
started when plugged in. And as ALL IPP-over-USB support driverless 
printing (and scanning if they have a scanner) you can easily print and 
scan via the emulated IPP device. Note that for scanning you need SANE 
1.0.29 or sane-airscan, and for auto-discovery (independent of whether 
you want to print or scan) you need Avahi 0.8.0 or newer.


You can even fax without driver (at least from the command line) 
following my simple test described in this GSoC project listing:


https://wiki.linuxfoundation.org/gsoc/google-summer-code-2020-openprinting-projects#support_for_ipp_fax_out

So you simply need to sync with this Ubuntu package ...

Also make sure to overtake the latest changes on system-config-printer 
from Ubuntu (version 1.5.11-4ubuntu2 or newer, replace 
33_ipp-over-usb-support.patch by 
33_no-usb-queues-for-ipp-over-usb-printers.patch), so that 
system-config-printer does not try to start ippusbxd or auto-create 
print queues for IPP-over-USB-capable printers. Due to not being sure 
about Debian's system-config-printer I did the ippusbxd change 
Ubuntu-only, also as it was close before our Feature Freeze for 20.04.


   Till

Bug#959501: luabind: std::terminate called on luabind:error

[Andreas Grob]

Dear Maintainer,

this is now fixed in upstream https://github.com/ValyriaTear/luabind at commit 
a9287d342c70a37b68beca694ee75f2d5c747db4.
I have also included a regression test there.
Link to commit in upstream: 
https://github.com/ValyriaTear/luabind/commit/7555d9c7f20d7cb37628870e9b7e3eb9c0bb32fb

The mentioned snapshot (a9287d34) also includes a patch I provided previously, 
as well as a regression test for that patch.
Link to patch: 
https://sources.debian.org/patches/luabind/0.9.1+git20150823+dfsg-3/02_fix_potential_null_ptr_dereference_in_adopt_policy.patch/
Link to commit in upstream: 
https://github.com/ValyriaTear/luabind/commit/2fb1f5e35b3aec06539fe4df7e357d3010ddf3f2

Kind regards,
Andreas Grob

Bug#949638: tesseract: uses -march=native

[Stefan Weil]

Adrian, I am afraid that there is a misunderstanding.

The code part which is compiled with -march=native is never executed by
default.

There is a command line option which allows users to select the code
which is used for certain time critical calculations (dot product). A
wrong choice is not a security problem but simply will crash the
application, no matter whether the user selected "native", "avx" or
"neon". That's quite common for other packages including the standard C
library and scientific libraries, too. They all contain optimized
functions which require certain hardware and which crash otherwise.

Regards

Stefan

Bug#961431: apt: [INTL:nl] Dutch po file for the apt package's documentation

[Frans Spiesschaert]

Hi David,

David Kalnischkies schreef op zo 24-05-2020 om 21:27 [+0200]:
> On Sun, May 24, 2020 at 04:43:05PM +0200, Frans Spiesschaert wrote:
> > Please find attached the updated Dutch po file for the apt package's
> > documentation. It has been submitted for review to the […]
> 
> Just to be sure: After reflowing the file the diff is "just" removing
> the fuzzy indication from 3 messages, no message is actually changed in
> any way.
> 
> Is this correct or went something wrong?

Thank you for checking.
Nothing went wrong. Those three messages were marked fuzzy
because of minor changes/rewordings to the original templates.
I checked the translation of all three, but all the translations
were still valid.
So I unfuzzied those messages, but didn't change anything else.

Best regards,
Frans Spiesschaert

> 
> (I have not checked why these msgs were fuzzy to begin with, so that
> might be perfectly fine that they aren't anymore, I just wanted to ask).
> 
> 
> Best regards
> 
> David Kalnischkies

Bug#961460: src:newsboat: build depends on librust-xdg-2-dev which doesn't exist (anymore)

[Paul Gevers]

Hi Nikos,

On 24-05-2020 21:17, Nikos Tsipinakis wrote:
> I'm confused here, I just did a test build in a fresh unstable chroot and it
> seems like newsboat builds just fine.

Oops, sorry.

> librust-xdg-2-dev is provided by librust-xdg[1]. Is this a false positive of
> some build script? Or perhaps the rebuild was run in testing rather than
> unstable (librust-xdg hasn't migrated yet).

Yes, that. I look regularly at
https://qa.debian.org/dose/debcheck/src_testing_main/ as we (the release
team) require packages to be buildable in testing (we have some
tolerance as the migration of build dependencies isn't guaranteed when
checking if a package may migrate). Please help the rust maintainers
such that that package can migrate.

Paul



signature.asc
Description: OpenPGP digital signature

Bug#961447: bup: 0.30.1 released, fixing notable bugs

[Robert Edmonds]

Rob Browning wrote:
> Just released 0.30.1, including some notable bug fixes.  I'd recommend
> replacing the version in sid if feasible:
> 
>   https://github.com/bup/bup/blob/0.30.x/note/0.30.1-from-0.30.md
> 
> Perhaps worth mentioning that 0.30.* still doesn't support python 3.
> We're finishing up python 3 support for the next non-Z version (likely
> 0.31, hopefully "soon").

Hi, Rob:

One of our build dependencies python-pylibacl has already removed its
python2 module (#938073). It looks like bup can function without
pylibacl. Is it safe to ship a bup 0.30.1 package without pylibacl
support?

-- 
Robert Edmonds
edmo...@debian.org

Bug#961471: docker.io: docker network create gets IPv6 gateway wrong

[docker network create assumes IPv6 gateway will be within subnet]

Package: docker.io
Version: 18.09.1+dfsg1-7.1+rpi1+rpt1
Severity: important
Tags: ipv6

Dear Maintainer,

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

   * What led up to the situation?

eth0: flags=4163  mtu 1500
inet 10.74.3.189  netmask 255.255.255.252  broadcast 10.74.3.191
inet6 2a00:1098:8:bf::1  prefixlen 64  scopeid 0x0
inet6 fe80::ba27:ebff:feeb:6b01  prefixlen 64  scopeid 0x20
ether b8:27:eb:eb:6b:01  txqueuelen 1000  (Ethernet)
RX packets 33609450  bytes 2152188359 (2.0 GiB)
RX errors 2  dropped 0  overruns 0  frame 2
TX packets 33742813  bytes 1964729036 (1.8 GiB)
TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

Since docker wants to manage the IP addresses itself, I can not give it the 
entire subnet.
That would also be wrong in many ways.  So I must give it part of the subnet to 
use.

galadriel# docker network create -d macvlan \
--subnet=10.0.1.0/24 \   
--subnet=2a00:1098:8:bf::1:0/116 --gateway=2a00:1098:8:bf::2 \  
-o parent=eth0 \
--ipv6 \
mythic0 

no matching subnet for gateway 2a00:1098:8:bf::2

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

Unresolved. 

   * What was the outcome of this action?

the network is not created

   * What outcome did you expect instead?

the network should have been created.

Docker thinks that IPv6 works like IPv4, and it does not.
The default gateway in IPv6 can be anything, and is often an IPv6 Link-Local 
address (scoped to that interface).
There is no requirement that the addresses be on-link, so it is entirely 
reasonable to specify a gateway that is
not within the provided subnet.

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


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

Kernel: Linux 4.19.97-v7+ (SMP w/4 CPU cores)
Kernel taint flags: TAINT_CRAP
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to en_CA.UTF-8), LANGUAGE=en_CA:en (charmap=UTF-8) (ignored: LC_ALL set to 
en_CA.UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages docker.io depends on:
ii  adduser 3.118
ii  iptables1.8.2-4
ii  libc6   2.28-10+rpi1
ii  libdevmapper1.02.1  2:1.02.155-3
ii  libltdl72.4.6-9
ii  libnspr42:4.20-1
ii  libnss3 2:3.42.1-1+deb10u2
ii  libseccomp2 2.3.3-4
ii  libsystemd0 241-7~deb10u4+rpi1
ii  lsb-base10.2019051400+rpi1
ii  runc1.0.0~rc6+dfsg1-3
ii  tini0.18.0-1

Versions of packages docker.io recommends:
ii  ca-certificates  20190110
ii  cgroupfs-mount   1.4
ii  git  1:2.20.1-2+deb10u3
ii  needrestart  3.4-5
ii  xz-utils 5.2.4-1

Versions of packages docker.io suggests:
pn  aufs-tools   
pn  btrfs-progs  
pn  debootstrap  
pn  docker-doc   
ii  e2fsprogs1.44.5-1+deb10u3
pn  rinse
pn  xfsprogs 
pn  zfs-fuse | zfsutils  

-- no debconf information

Bug#961469: Example of the impact

[Sylvestre Ledru]

I should have mentioned that is impacting about 150 packages in the Archive:

https://clang.debian.net/status.php?version=9.0.1=CHANGE_SYM_LIB

S

Bug#961469: dpkg-dev: dpkg-gensymbols should ignore C++ virtual destructors

[Sylvestre Ledru]

Package: dpkg-dev
Version: 1.19.7
Severity: normal

Hello,

As part of the rebuild of the Debian archive using clang (instead of gcc),
I found a difference in the way clang exports represent its virtual destructor
in the library.

I reported the issue upstream:
https://bugs.llvm.org/show_bug.cgi?id=45322

It seems that it doesn't any practical effect in the binary/lib. So, in
theory, we should ignore it.

I know it is hard (out of scope?) for dpkg-gensymbols to manage this case.
But reporting it for posterity (and if others face the same issue).

Cheers,
Sylvestre

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

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

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


-- Package-specific info:

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

Kernel: Linux 5.4.0-4-amd64 (SMP w/4 CPU cores)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), 
LANGUAGE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages dpkg-dev depends on:
ii  binutils  2.34-4
ii  bzip2 1.0.8-2
ii  libdpkg-perl  1.19.7
ii  make  4.2.1-1.2
ii  patch 2.7.6-6
ii  perl  5.30.0-9
ii  tar   1.30+dfsg-6+b1
ii  xz-utils  5.2.4-1+b1

Versions of packages dpkg-dev recommends:
ii  build-essential  12.8
ii  clang-10 [c-compiler]1:10.0.0-4
ii  clang-5.0 [c-compiler]   1:5.0.2-2
ii  clang-6.0 [c-compiler]   1:6.0.1-12
ii  clang-7 [c-compiler] 1:7.0.1-12
ii  clang-8 [c-compiler] 1:8.0.1-9
ii  clang-9 [c-compiler] 1:9.0.1-12
ii  fakeroot 1.24-1
ii  gcc [c-compiler] 4:9.2.1-3.1
ii  gcc-6 [c-compiler]   6.5.0-2
ii  gcc-7 [c-compiler]   7.5.0-5
ii  gcc-8 [c-compiler]   8.3.0-29
ii  gcc-9 [c-compiler]   9.2.1-30
ii  gnupg2.2.19-2
ii  gnupg2   2.2.19-2
ii  gpgv 2.2.19-2
pn  libalgorithm-merge-perl  

Versions of packages dpkg-dev suggests:
ii  debian-keyring  2020.02.02

-- no debconf information

Bug#949638: tesseract: uses -march=native

[Adrian Bunk]

Control: severity -1 serious

On Fri, Jan 24, 2020 at 10:28:36PM +0100, Stefan Weil wrote:
> Am 24.01.20 um 21:53 schrieb peter green:
> 
> > I still don't think -march=native is appropriate for a binary
> > distribution though. If you want to offer different versions of the
> > code built with different CPU requirements, that is fine, but please
> > don't let them depend on what CPU happens to be in the autobuilder.
> 
> Better ideas are welcome.
> 
> Tesseract is used for mass processing of books which can take many weeks
> or even months. Therefore it is very important that the time critical
> code (dot product calculation) runs as fast as possible.
> 
> For x86_64 we know the available SIMD instructions (SSE, AVX, ...) which
> can be used, add code for all variants and check at runtime what is
> supported by the CPU.
> 
> For all other architectures (including ARM) there is currently no such
> special code, and the default code is rather slow. By using
> -march=native for the alternate code, hopefully the compiler will
> produce code which runs faster on any machine which is similar to the
> build machine.

And which will crash on any machine that is not compatible.

If Debian gets an AMD Threadripper buildd, then -march=native code built 
on that buildd will not run on any CPU from Intel.

The same is true for other architectures like ARM - if a buildd happens 
to be the latest server hardware and uses some uncommon CPU extension, 
it is not compatible with many machines.

> Users who build Tesseract on the machine which is also
> used for the mass production will get the best result like that. Users
> using a distribution can try the "native" option and either crash the
> program or get a possibly faster result.
> 
> I see the problem of builds which depend on an autobuilder which may be
> different for each build.

"each build" might be a security update in stable on a much newer buildd,
the tested setup running in production might then just crash.

As user I can handle a quirk or two when setting up a machine,
but anything that breaks out of the void is a huge pain.

If Tesseract is the main usage of the machine and every percetage point 
of performance matters, I would likely build it myself instead of using 
the distribution package.

> What would be the best solution for
> distributions? Suppress the code using a new configure option or some
> magic which detects that the build is for a Debian distribution? Choose
> compiler flags manually for the "native" option (that is already
> possible, see my previous answer)? Other solutions?

The important point is that manual installations and distributions have
different needs.

When a user is manually compiling and installing a software on a machine 
-march=native can be used for everything, not just the most time 
critical part - it is faster with no real downside.

For a distribution you want several variants like what you already
have for x86_64, and no -march=native ever.

If 32bit ARM still matters for your users they might want to use NEON,
many Debian buildds have CPUs that do not support NEON.

For 64bit ARM they might want armv8.2-a+dotprod,
I do not think any current Debian buildd supports that.

You should know best which extensions actually make a difference,
and when the fastest option is autodetected at runtime it is most
likely to benefit the user of a distribution package.

> Stefan

cu
Adrian

Bug#961378: -v causes Temporary failure in name resolution

[積丹尼 Dan Jacobson]

Sure, now that I am online, I have a working resolver.
But not when I made the report. I was offline.
Anyway it is 100% the fault of the program for
not having been tested offline without a resolver running.

Bug#961399: seaview: autopkgtest regression: gzip: *.gz: No such file or directory

[Andreas Tille]

On Sun, May 24, 2020 at 09:18:01PM +0530, Nilesh Patra wrote:
> I tried implementing this, and modifying the tests in a way that made sense
> to me.
> Could you please have a look at this, and let me know if this is OK?

Works for me - thus uploaded.

Thanks a lot for your contribution
Andreas.

-- 
http://fam-tille.de

Bug#961468: pyzmq FTCBFS: please reduce Build-Depends

[Helmut Grohne]

Source: pyzmq
Version: 18.1.1-3
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: cross-satisfiability

pyzmq fails to cross build from source, because its Build-Depends are
not satisfiable. Since cross builds usually don't run tests, the nocheck
build profile is a very good way to trim Build-Depends. Please consider
applying the attached patch to make a lot of Build-Depends optional
using . I verified that a nocheck build produces bit-identical
artifacts to a full build.

Helmut
diff --minimal -Nru pyzmq-18.1.1/debian/changelog pyzmq-18.1.1/debian/changelog
--- pyzmq-18.1.1/debian/changelog   2020-03-06 22:33:39.0 +0100
+++ pyzmq-18.1.1/debian/changelog   2020-05-24 14:35:20.0 +0200
@@ -1,3 +1,10 @@
+pyzmq (18.1.1-3.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Annotate Build-Depends with . (Closes: #-1)
+
+ -- Helmut Grohne   Sun, 24 May 2020 14:35:20 +0200
+
 pyzmq (18.1.1-3) unstable; urgency=medium
 
   * Patch an endian-specific test which was failing on big-endian
diff --minimal -Nru pyzmq-18.1.1/debian/control pyzmq-18.1.1/debian/control
--- pyzmq-18.1.1/debian/control 2020-03-06 22:33:39.0 +0100
+++ pyzmq-18.1.1/debian/control 2020-05-24 14:35:20.0 +0200
@@ -9,17 +9,17 @@
dh-python,
libzmq3-dev,
cython3,
-   cython3-dbg,
+   cython3-dbg ,
python3-all-dbg,
python3-all-dev,
-   python3-cffi,
-   python3-cffi-backend-dbg,
-   python3-nose,
-   python3-numpy,
-   python3-numpy-dbg,
-   python3-pytest,
-   python3-setuptools,
-   python3-tornado,
+   python3-cffi ,
+   python3-cffi-backend-dbg ,
+   python3-nose ,
+   python3-numpy ,
+   python3-numpy-dbg ,
+   python3-pytest ,
+   python3-setuptools ,
+   python3-tornado ,
 Standards-Version: 4.5.0
 Homepage: http://www.zeromq.org/bindings:python
 Vcs-Git: https://salsa.debian.org/python-team/modules/pyzmq.git

Bug#961466: netplan.io FTCBFS: unsatisfiable Build-Depends

[Helmut Grohne]

Source: netplan.io
Version: 0.99-1
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: cross-satisfiability

netplan.io fails to cross build from source, because its Build-Depends
are not cross-satisfiable. netplan.io has quite a number of
Build-Depends, so solving this is not easy. Fortunately, a big chunk is
only used for testing netplan.io. Those can be dropped for cross
building using the nocheck build profile and build option. So a big
chunk of the problem goes away if one simply annotates droppable
dependencies with . I used reproducible builds to verify that
doing so indeed produces the same binary artifact. Please consider
applying the attached patch.

Helmut
diff --minimal -Nru netplan.io-0.99/debian/changelog 
netplan.io-0.99/debian/changelog
--- netplan.io-0.99/debian/changelog2020-04-27 11:01:26.0 +0200
+++ netplan.io-0.99/debian/changelog2020-05-24 14:22:14.0 +0200
@@ -1,3 +1,10 @@
+netplan.io (0.99-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Annotate Build-Depends with . (Closes: #-1)
+
+ -- Helmut Grohne   Sun, 24 May 2020 14:22:14 +0200
+
 netplan.io (0.99-1) unstable; urgency=medium
 
   [ Andrej Shadura ]
diff --minimal -Nru netplan.io-0.99/debian/control 
netplan.io-0.99/debian/control
--- netplan.io-0.99/debian/control  2020-04-27 11:01:26.0 +0200
+++ netplan.io-0.99/debian/control  2020-05-24 14:22:14.0 +0200
@@ -14,15 +14,15 @@
  libglib2.0-dev,
  uuid-dev,
  python3 (>= 3.1),
- python3-coverage,
- python3-yaml,
- python3-netifaces,
+ python3-coverage ,
+ python3-yaml ,
+ python3-netifaces ,
  libsystemd-dev,
  systemd,
- dbus-x11,
- pyflakes3,
- pycodestyle | pep8,
- python3-nose,
+ dbus-x11 ,
+ pyflakes3 ,
+ pycodestyle  | pep8 ,
+ python3-nose ,
  pandoc,
 Vcs-Git: https://salsa.debian.org/debian/netplan.io.git
 Vcs-Browser: https://salsa.debian.org/debian/netplan.io

Bug#961465: wmcore FTCBFS: hard codes the build architecture pkg-config

[Helmut Grohne]

Source: wmcore
Version: 0.0.3-1
Tags: patch upstream
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

wmcore fails to cross build from source, because the upstream Makefile
hard codes the build architecture pkg-config. After making it
substitutable, wmcore cross builds successfully. Please consider
applying the attached patch.

Helmut
--- wmcore-0.0.3.orig/Makefile
+++ wmcore-0.0.3/Makefile
@@ -3,18 +3,19 @@
 
 INSTALL	 = /usr/bin/install
 LD	 = $(CC)
+PKG_CONFIG ?= pkg-config
 
 CFLAGS	+= -Wall -O3 \
-	   $(shell pkg-config dockapp --cflags) \
-	   $(shell pkg-config x11 --cflags) \
-	   $(shell pkg-config xext--cflags) \
-	   $(shell pkg-config xpm --cflags)
+	   $(shell $(PKG_CONFIG) dockapp --cflags) \
+	   $(shell $(PKG_CONFIG) x11 --cflags) \
+	   $(shell $(PKG_CONFIG) xext--cflags) \
+	   $(shell $(PKG_CONFIG) xpm --cflags)
 LDFLAGS += -Wall
 
-LIBS	 = $(shell pkg-config dockapp --libs) \
-	   $(shell pkg-config x11 --libs) \
-	   $(shell pkg-config xext--libs) \
-	   $(shell pkg-config xpm --libs)
+LIBS	 = $(shell $(PKG_CONFIG) dockapp --libs) \
+	   $(shell $(PKG_CONFIG) x11 --libs) \
+	   $(shell $(PKG_CONFIG) xext--libs) \
+	   $(shell $(PKG_CONFIG) xpm --libs)
 
 OBJS	 = wmcore.o
 

Bug#961467: king-probe FTCBFS: upstream Makefiles hard code the build architecture compiler

[Helmut Grohne]

Source: king-probe
Version: 2.16.160404+git20200121.9b198c1-1
Tags: patch upstream
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

king-probe fails to cross build from source, because the upstream
Makefiles hard code the build architecture compiler. After making it
substitutable, king-probe cross builds successfully. Please consider
applying the attached patch.

Helmut
--- king-probe-2.16.160404+git20200121.9b198c1.orig/Makefile
+++ king-probe-2.16.160404+git20200121.9b198c1/Makefile
@@ -5,10 +5,10 @@
 	 parse.o atomprops.o stdconntable.o autobondrot.o hybrid_36_c.o
 
 .c.o:
-	cc -c $*.c $(CFLAGS)
+	$(CC) -c $*.c $(CFLAGS)
 
 probe: probe.o $(OBJLIST)
-	cc -o $@ probe.o $(OBJLIST) $(LFLAGS)
+	$(CC) -o $@ probe.o $(OBJLIST) $(LFLAGS)
 
 clean:
 	@rm -f *.o *.ckp
--- king-probe-2.16.160404+git20200121.9b198c1.orig/Makefile.linux
+++ king-probe-2.16.160404+git20200121.9b198c1/Makefile.linux
@@ -5,10 +5,10 @@
 	 parse.o atomprops.o stdconntable.o autobondrot.o hybrid_36_c.o
 
 .c.o:
-	cc -c $*.c $(CFLAGS)
+	$(CC) -c $*.c $(CFLAGS)
 
 probe: probe.o $(OBJLIST)
-	cc -o $@ probe.o $(OBJLIST) $(LFLAGS) $(LDFLAGS)
+	$(CC) -o $@ probe.o $(OBJLIST) $(LFLAGS) $(LDFLAGS)
 
 clean:
 	@rm -f *.o *.ckp

Bug#961431: apt: [INTL:nl] Dutch po file for the apt package's documentation

[David Kalnischkies]

On Sun, May 24, 2020 at 04:43:05PM +0200, Frans Spiesschaert wrote:
> Please find attached the updated Dutch po file for the apt package's
> documentation. It has been submitted for review to the […]

Just to be sure: After reflowing the file the diff is "just" removing
the fuzzy indication from 3 messages, no message is actually changed in
any way.

Is this correct or went something wrong?

(I have not checked why these msgs were fuzzy to begin with, so that
might be perfectly fine that they aren't anymore, I just wanted to ask).


Best regards

David Kalnischkies


signature.asc
Description: PGP signature

Bug#961462: ppp: Buster pppoe-discovery -U is broken

[Pali Rohár]

Package: ppp
Version: 2.4.7-2+4.1+deb10u1
Control: subscribe -1

Hello!

pppoe-discovery with -U option (Use Host-Unique to allow multiple PPPoE
sessions) is in Debian Buster currently broken.

Its output on PPPoE network via eth0 interface is just:

  # pppoe-discovery -U -I eth0
  Timeout waiting for PADO packets

But tcpdump on eth0 interface confirms that PADO packets were received:

  # tcpdump -n -p - -i eth0
  tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 262144 
bytes
  ...
  21:04:23.835174 PPPoE PADI [Service-Name] [Host-Uniq 0x0DCC]
  21:04:23.853135 PPPoE PADO [Service-Name] [AC-Name "ke-pols-bras-1"] 
[Host-Uniq 0x0DCC] [AC-Cookie 0x37591CD0FA31C63720E0CF08D4340C61]
  21:04:23.853396 PPPoE PADO [Service-Name] [AC-Name "po-maue-bras-1"] 
[Host-Uniq 0x0DCC] [AC-Cookie 0xEC3CB571EEF00E875E46F71059CA58F9]
  21:04:26.853685 PPPoE PADO [Service-Name] [AC-Name "ba-jros-bras-3"] 
[Host-Uniq 0x0DCC] [AC-Cookie 0x7D802A631A6DC4F1F3C70737DA71678A]
  21:04:31.858854 PPPoE PADI [Service-Name] [Host-Uniq 0x0DCC]
  21:04:31.868204 PPPoE PADO [Service-Name] [AC-Name "ke-pols-bras-1"] 
[Host-Uniq 0x0DCC] [AC-Cookie 0x37591CD0FA31C63720E0CF08D4340C61]
  21:04:31.868358 PPPoE PADO [Service-Name] [AC-Name "po-maue-bras-1"] 
[Host-Uniq 0x0DCC] [AC-Cookie 0xEC3CB571EEF00E875E46F71059CA58F9]
  21:04:34.948714 PPPoE PADO [Service-Name] [AC-Name "ba-jros-bras-3"] 
[Host-Uniq 0x0DCC] [AC-Cookie 0x7D802A631A6DC4F1F3C70737DA71678A]
  21:04:39.953858 PPPoE PADI [Service-Name] [Host-Uniq 0x0DCC]
  21:04:39.962591 PPPoE PADO [Service-Name] [AC-Name "ke-pols-bras-1"] 
[Host-Uniq 0x0DCC] [AC-Cookie 0x37591CD0FA31C63720E0CF08D4340C61]
  21:04:39.962649 PPPoE PADO [Service-Name] [AC-Name "po-maue-bras-1"] 
[Host-Uniq 0x0DCC] [AC-Cookie 0xEC3CB571EEF00E875E46F71059CA58F9]
  21:04:43.048720 PPPoE PADO [Service-Name] [AC-Name "ba-jros-bras-3"] 
[Host-Uniq 0x0DCC] [AC-Cookie 0x7D802A631A6DC4F1F3C70737DA71678A]
  ...

Without -U option pppoe-discovery is working fine:

  # pppoe-discovery -I eth0
  Access-Concentrator: ke-pols-bras-1
  Got a cookie: 37 59 1c d0 fa 31 c6 37 20 e0 cf 08 d4 34 0c 61
  --
  AC-Ethernet-Address: 24:21:24:e9:be:3f
  Access-Concentrator: po-maue-bras-1
  Got a cookie: ec 3c b5 71 ee f0 0e 87 5e 46 f7 10 59 ca 58 f9
  --
  AC-Ethernet-Address: 20:e0:9c:3e:98:01
  Access-Concentrator: ba-jros-bras-3
  Got a cookie: 7d 80 2a 63 1a 6d c4 f1 f3 c7 07 37 da 71 67 8a
  --
  AC-Ethernet-Address: 24:21:24:b9:76:3f

It looks like that ppp package in Debian Buster has custom patch which
implements -U option [1] which differs from upstream implementation of
-U option [2] [3].

I compiled pppoe-discovery from upstream ppp project with upstream -U
patch [3] and this is working fine. Output is:

  # ./pppd/plugins/rp-pppoe/pppoe-discovery -U -I eth0
  Access-Concentrator: ke-pols-bras-1
  Got a cookie: 37 59 1c d0 fa 31 c6 37 20 e0 cf 08 d4 34 0c 61
  AC-Ethernet-Address: 24:21:24:e9:be:3f
  --
  Access-Concentrator: po-maue-bras-1
  Got a cookie: ec 3c b5 71 ee f0 0e 87 5e 46 f7 10 59 ca 58 f9
  AC-Ethernet-Address: 20:e0:9c:3e:98:01
  --
  Access-Concentrator: ba-jros-bras-3
  Got a cookie: 7d 80 2a 63 1a 6d c4 f1 f3 c7 07 37 da 71 67 8a
  AC-Ethernet-Address: 24:21:24:b9:76:3f
  --

So it means that Debian's custom patch in Buster [1] is broken. Please
replace this broken Debian patch by working upstream patch [3]. To make
pppoe-discovery from ppp package in Debian working.

[1] - 
https://sources.debian.org/patches/ppp/2.4.7-2+4.1+deb10u1/pr-28-pppoe-custom-host-uniq-tag.patch/
[2] - https://github.com/paulusmack/ppp/pull/97
[3] - 
https://github.com/paulusmack/ppp/commit/c9d9dbfb8459b528ab56bd1cf0c41460801bbfdf

-- 
Pali Rohár
pali.ro...@gmail.com

Bug#961460: src:newsboat: build depends on librust-xdg-2-dev which doesn't exist (anymore)

[Nikos Tsipinakis]

Hi,

I'm confused here, I just did a test build in a fresh unstable chroot and it
seems like newsboat builds just fine.

librust-xdg-2-dev is provided by librust-xdg[1]. Is this a false positive of
some build script? Or perhaps the rebuild was run in testing rather than
unstable (librust-xdg hasn't migrated yet).

[1] https://tracker.debian.org/media/packages/r/rust-xdg/control-2.2.0-2

- Nikos

On 24/05, Paul Gevers wrote:
> Source: newsboat
> Version: 2.19-1
> Severity: serious
> User: trei...@debian.org
> Usertags: -1 edos-uninstallable
> 
> Dear maintainer(s),
> 
> Your package Build-Depends on librust-xdg-2-dev but that package isn't
> available in Debian (anymore). You should probably Build-Depends on
> librust-xdg-dev instead.
> 
> Paul
> 

Bug#961461: transmission: CVE-2018-10756

[Salvatore Bonaccorso]

Source: transmission
Version: 2.94-2
Severity: important
Tags: security upstream
Control: found -1 2.92-2+deb9u1
Control: found -1 2.92-2

Hi,

The following vulnerability was published for transmission.

CVE-2018-10756[0]:
| Use-after-free in libtransmission/variant.c in Transmission before
| 3.00 allows remote attackers to cause a denial of service (crash) or
| possibly execute arbitrary code via a crafted torrent file.


If you fix the vulnerability please also make sure to include the
CVE (Common Vulnerabilities & Exposures) id in your changelog entry.

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2018-10756
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-10756
[1] 
https://github.com/transmission/transmission/commit/2123adf8e5e1c2b48791f9d22fc8c747e974180e
[2] https://tomrichards.net/2020/05/cve-2018-10756-transmission/

Regards,
Salvatore

Bug#961454: dahdi-dkms: Cannot compile using DKMS on kernel 5.4 backport and latter

[Geert Stappers]

On Sun, May 24, 2020 at 08:11:36PM +0200, Patrick ZAJDA via 
Pkg-voip-maintainers wrote:
> Package: dahdi-dkms
> Version: 1:2.11.1.0.20170917~dfsg-7
> 
> Dear Maintainer,
> 
> When installing kernel 5.4 or 5.5 from buster-backports or running
> dpkg-reconfigure dahdi-dkms, there is an error inviting
> to consult make.log.
> 
> This is the make.log I had after the error: http://ix.io/2n8n

Among other lines
 sh: 0: Can't open 
/usr/src/linux-headers-5.5.0-0.bpo.2-common/scripts/mkmakefile


> It looks like there is an incompatibility with kernel 5.4 and 5.5
> which prevents the compilation of DAHDI kernel modules.

To me it looks a generic DKMS thing.


Hope this helps
Geert Stappers

P.S.
What is behind  http://ix.io ?
As in "What source code runs at the ix.io  server?"
-- 
Silence is hard to parse

Bug#961398: src:quantlib-swig: fails to migrate to testing for too long: FTBFS on mipsel

[Dirk Eddelbuettel]

Hi Paul,

On 24 May 2020 at 20:31, Paul Gevers wrote:
| Hi Dirk,
| 
| On 24-05-2020 20:19, Dirk Eddelbuettel wrote:
| > Hm. Easy to implement but won't it create a permanent 'fail' on that 
platform?
| > (But then maybe that is the goal once I ask the release team to drop the old
| > binary...)
| 
| That's exactly what I meant. What did you think I meant?

I was mostly thinking out loud chewing over how it can be seen as outright
"sabotage" on the architecture ensuring success of a build.

So it reflected my surprise. Nothing more.

Dirk

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

Bug#961460: src:newsboat: build depends on librust-xdg-2-dev which doesn't exist (anymore)

[Paul Gevers]

Source: newsboat
Version: 2.19-1
Severity: serious
User: trei...@debian.org
Usertags: -1 edos-uninstallable

Dear maintainer(s),

Your package Build-Depends on librust-xdg-2-dev but that package isn't
available in Debian (anymore). You should probably Build-Depends on
librust-xdg-dev instead.

Paul



signature.asc
Description: OpenPGP digital signature

Bug#961459: linux-signed-arm64: option that might support raspberry pi 4 usb

[Rob Browning]

Package: linux-signed-arm64
Version: 5.7~rc5-1~exp1

At least from this comment,

  https://github.com/lategoodbye/rpi-zero/issues/43#issuecomment-611780458

it looks like we might need

  CONFIG_PCIE_BRCMSTB=m

to allow USB to work on the pi 4.  I can verify that 5.7~rc5-1~exp1
boots fine on one, all the way to a tt1 login, but there appears to be
no USB power, i.e. a keyboard or mouse plugged in does not respond, and
the normal power leds on the keboard and mouse don't light.

If I get a chance and figure out how, I can try to build a local kernel
with that option and test it, or I could fairly quickly test any version
uploaded somewhere like experimental.

Thanks
-- 
Rob Browning
rlb @defaultvalue.org and @debian.org
GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C4 C0F0 39E9 ED1B 597A
GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4

Bug#961412: fetchmail: restart silently fails, then start doesn't help

[Matthias Andree]

README.Debian mentions:

  /etc/init.d/fetchmail debug-run 

what does this get you?

Bug#961332: Fwd: Bug#961332: gnome-flashback: System indicators (volume, bluetooth, ...) do not appear

[Timothy Allen]

On 24/5/20 7:46 pm, Alberts Muktupāvels wrote:
> Mentioned things where turned into gnome-panel applet - System Indicators.

Ah, I see - and if I look in Debian's "NEWS" file, I see version 3.35.2
includes "New system indicators applet for gnome-panel". It wasn't clear
to me that "system indicators" included things like the volume control,
or that "new applet" implied that the old indicator icons were removed.

I feel like this change could have been announced a more loudly, but
thank you for explaining - I've switched from i3's built-in status-bar
to gnome-panel, and now I've got my volume slider back.

Thank you again for all the hard work you do maintaining gnome-flashback!

Bug#961457: idle3-tools: autopkgtest regression: idle3ctl: command not found

[Paul Gevers]

Source: idle3-tools
Version: 0.9.1-4
X-Debbugs-CC: debian...@lists.debian.org, leandrora...@debxp.org
Severity: serious
User: debian...@lists.debian.org
Usertags: regression

Dear maintainer(s),

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

   passfail
idle3-toolsfrom testing0.9.1-4
all others from testingfrom testing

I copied some of the output at the bottom of this report. It seems that
either you need the needs-root restriction or need to provide the full
path to /usr/sbin/idle3ctl. Without needs-root, the test is run as a
regular user. Please also mark this test as superficial.

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=idle3-tools

https://ci.debian.net/data/autopkgtest/testing/amd64/i/idle3-tools/5507695/log.gz

autopkgtest [03:18:58]: test command1: idle3ctl -V | grep idle
autopkgtest [03:18:58]: test command1: [---
bash: idle3ctl: command not found
autopkgtest [03:18:58]: test command1: ---]



signature.asc
Description: OpenPGP digital signature

Bug#961458: ippusbxd: Please consider installing a systemd service file by default

[Brian Potkin]

Package: ippusbxd
Version: 1.34-2
Severity: wishlist


An installed ippusbxd can be started by a user with root privileges with
'ippusbxd'. The ippusbxd package contains

 /usr/share/doc/ippusbxd/examples/ippusbxd@.service

Having the package installation put this file in /lib/systemd/system/
should give automatic access to IPP-over-USB printers when the printer
is plugged in.

This would put a modern USB-connected printer on the same par as a
network-connected printer.

Regards,

Brian.

Bug#961398: src:quantlib-swig: fails to migrate to testing for too long: FTBFS on mipsel

[Paul Gevers]

Hi Dirk,

On 24-05-2020 20:19, Dirk Eddelbuettel wrote:
> Hm. Easy to implement but won't it create a permanent 'fail' on that platform?
> (But then maybe that is the goal once I ask the release team to drop the old
> binary...)

That's exactly what I meant. What did you think I meant?

Paul



signature.asc
Description: OpenPGP digital signature

Bug#961456: pwget: autopkgtest regression: Can't locate LWP/UserAgent.pm in @INC

[Paul Gevers]

Source: pwget
Version: 2016.1019+git75c6e3e-3
X-Debbugs-CC: debian...@lists.debian.org, elimar.henri...@yahoo.com.br
Severity: serious
User: debian...@lists.debian.org
Usertags: regression

Dear maintainer(s),

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

   passfail
pwget  from testing2016.1019+git75c6e3e-3
all others from testingfrom testing

I copied some of the output at the bottom of this report. Seems like you
are missing a (test) dependency? Please also mark this test as superficial.

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=pwget

https://ci.debian.net/data/autopkgtest/testing/amd64/p/pwget/5507726/log.gz

autopkgtest [03:27:21]: test command2: pwget -h
autopkgtest [03:27:21]: test command2: [---
Can't locate LWP/UserAgent.pm in @INC (you may need to install the
LWP::UserAgent module) (@INC contains: /etc/perl
/usr/local/lib/x86_64-linux-gnu/perl/5.30.0 /usr/local/share/perl/5.30.0
/usr/lib/x86_64-linux-gnu/perl5/5.30 /usr/share/perl5
/usr/lib/x86_64-linux-gnu/perl/5.30 /usr/share/perl/5.30
/usr/local/lib/site_perl /usr/lib/x86_64-linux-gnu/perl-base) at
/usr/bin/pwget line 87.
BEGIN failed--compilation aborted at /usr/bin/pwget line 87.
autopkgtest [03:27:21]: test command2: ---]





signature.asc
Description: OpenPGP digital signature

Bug#961455: ngetty: autopkgtest regression: ngetty-helper: command not found

[Paul Gevers]

Source: ngetty
Version: 1.1-5
X-Debbugs-CC: debian...@lists.debian.org, guilherme@gmail.com
Severity: serious
User: debian...@lists.debian.org
Usertags: regression

Dear maintainer(s),

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

   passfail
getty  from testing1.1-5
all others from testingfrom testing

I copied some of the output at the bottom of this report. It seems that
either you need the needs-root restriction or need to provide the full
path to /sbin/ngetty-helper. Without needs-root, the test is run as a
regular user. Please also mark this test as superficial.

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=ngetty

https://ci.debian.net/data/autopkgtest/testing/amd64/n/ngetty/5502710/log.gz

autopkgtest [21:50:06]: test command1: ngetty-helper --version | grep
version
autopkgtest [21:50:06]: test command1: [---
bash: ngetty-helper: command not found
autopkgtest [21:50:07]: test command1: ---]



signature.asc
Description: OpenPGP digital signature

Bug#961398: src:quantlib-swig: fails to migrate to testing for too long: FTBFS on mipsel

[Dirk Eddelbuettel]

Hi Paul,

On 24 May 2020 at 19:54, Paul Gevers wrote:
| Hi Dirk,
| 
| On 24-05-2020 19:09, Dirk Eddelbuettel wrote:
| > But how I prevent the build in the future?
| > 
| > Via 'Architecture: any [!xyx]' ?  Last I checked I though we had no such
| > explicit white/black listing mechanisms (but then I may have forgotten...)
| 
| I also don't think blacklisting exists. I just checked policy and it

Right.

| doesn't mention anything like it. Instead of listing all archs except
| for mipsel, I would just check the architecture in debian/rules and exit
| non-zero if the architecture is mipsel.

Hm. Easy to implement but won't it create a permanent 'fail' on that platform?
(But then maybe that is the goal once I ask the release team to drop the old
binary...)

Dirk

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

Bug#961428: RFS: python-discord/1.3.3+dfsg-1 [ITP] -- API wrapper for Discord written in Python

[Robin Gustafsson]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

I am looking for a sponsor for my package "python-discord"

 * Package name: python-discord
   Version : 1.3.3+dfsg-1
   Upstream Author : Rapptz
 * URL : https://github.com/Rapptz/discord.py
 * License : Expat
 * Vcs : https://salsa.debian.org/rgson/python-discord
   Section : python

It builds those binary packages:

  python3-discord - API wrapper for Discord written in Python

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

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

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

  dget -x 
https://mentors.debian.net/debian/pool/main/p/python-discord/python-discord_1.3.3+dfsg-1.dsc

Changes since the last upload:

   * Initial release (Closes: #961427)

Regards,

--
  Robin Gustafsson

Bug#961411: apt search -- output NOT grepable

[David Kalnischkies]

On Sun, May 24, 2020 at 12:49:21PM -0400, Lee wrote:
> On 5/24/20, Leszek Dubiel  wrote:
> > I've completely switched to using "apt" for all debian package management.
> > I'm fine with the "apt" tool, it fits all my needs except one... serarching.

It's no problem to use "apt-cache search" if you prefer that. apt-cache
and friends aren't going away and if they do what you like, use them!
I don't know where this notion that they shouldn't be used anymore
is coming from. If only people would do that with tools which really are
not to be used (looking at you apt-key…).

The same people are maintaining them all and so if you peak under the
lid you would notice that it tends to be even the very same code just
with an option here or there flipping a default… so, without promising
any backward compatibility:
$ apt search perl -o APT::Cache::Search::Version=1

If you want to set this in a config file use:
Binary::apt::APT::Cache::Search::Version "1";


As said, no promise that this will work forever. The various things
Julian hints at might be better choices in the future.


> $ apt search perl | awk -v RS="" '{gsub("\n",""); print $0}' | grep JSON | 
> grep -i data

awk is certainly powerful, but at least I can never type out such
commands without a least one trip to the manpage, websearch or
frantically grepping in my shell history files…

So I tend to prefer combinations of far less powerful tools.
I like `cut` and it has an even less known sibling with `paste`:

apt search -qq perl | paste -d' ' - - - | …

`-qq` disables the progress reporting in apt which is two lines which
would confuse the rest. `paste` takes three lines from stdin (`-`) and
separates them each with a space (`-d' '`).

One day I will learn awk – if cut and paste fail me 


Best regards

David Kalnischkies


signature.asc
Description: PGP signature

Bug#954089: libplack-perl: Please verify server identity via SSL

[gregor herrmann]

On Sun, 24 May 2020 17:38:54 +0100, Dominic Hargreaves wrote:

> I rebuilt perl with the patch at [1] and rebuild perl dependencies
> against it, and did not see any related failures [2].

Thanks alot!
 
> So, what are people's thoughts? Do we want to take this position
> and change the default in Debian? Extending distribution to debian-perl
> for wider visibility.

A tentative "yes" from me :)

Maybe we should seek communication with upstream in
https://github.com/chansen/p5-http-tiny/issues/68 (or a new issue
since that one is closed) as a next step?


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: Tom Waits: Warm Beer and Cold Women


signature.asc
Description: Digital Signature

Bug#961453: RFS: sane-backends/1.0.30-1~experimental1 [RC] -- API library for scanners -- utilities

[Jörg Frings-Fürst]

Package: sponsorship-requests
Severity: important

Dear mentors,

I am looking for a sponsor for my package "sane-backends"

   Package name: sane-backends
   Version : 1.0.30-1~experimental1 
   Upstream Author : sane-de...@alioth-lists.debian.net
   URL : http://www.sane-project.org
   License : GPL-2+ with sane exception
   Vcs : https://jff.email/cgit/sane-backends.git
   Section : graphics

It builds those binary packages:

  sane-utils - API library for scanners -- utilities
  libsane-common - API library for scanners -- documentation and support files
  libsane1 - API library for scanners
  libsane-dev - API development library for scanners [development files]

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

  https://mentors.debian.net/package/sane-backends

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

  dget -x 
https://mentors.debian.net/debian/pool/main/s/sane-backends/sane-backends_1.0.30-1~experimental1.dsc

or from git

  
https://jff.email/cgit/sane-backends.git?h=release%2Fexperimental%2F1.0.30-1_experimental1


Changes since the last upload:

   * New upstream release (Closes: #961302):
 - fixes CVE-2020-12867, CVE-2020-12862, CVE-2020-12863, CVE-2020-12865,
   CVE-2020-12861, CVE-2020-12864.
   * Migrate to debhelper 13:
 - Bump minimum debhelper-compat version in debian/control to = 13.
   * debian/watch: Fix to new gitlab download structure.
   * debian/rules:
 - Remove DEB_LDFLAGS_MAINT_APPEND after lintian warning.
 - Add override_dh_installman-arch to remove obsolete man page 
sane-config.1.
   * debian/control:
 - Replace Conflicts with Breaks.
   * Remove debian/libsane-dev.preinst because sane-config was removed in
 oldstable.

CU
Jörg Frings-Fürst


-- 
New:
GPG Fingerprint: 63E0 075F C8D4 3ABB 35AB  30EE 09F8 9F3C 8CA1 D25D
GPG key (long) : 09F89F3C8CA1D25D
GPG Key: 8CA1D25D
CAcert Key S/N : 0E:D4:56

Old pgp Key: BE581B6E (revoked since 2014-12-31).

Jörg Frings-Fürst
D-54470 Lieser


git:  https://jff.email/cgit/

Threema:  SYR8SJXB
Wire: @joergfringsfuerst
Skype:joergpenguin
Ring: jff
Telegram: @joergfringsfuerst


My wish list: 
 - Please send me a picture from the nature at your home.





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

Bug#961398: src:quantlib-swig: fails to migrate to testing for too long: FTBFS on mipsel

[Paul Gevers]

Hi Dirk,

On 24-05-2020 19:09, Dirk Eddelbuettel wrote:
> But how I prevent the build in the future?
> 
> Via 'Architecture: any [!xyx]' ?  Last I checked I though we had no such
> explicit white/black listing mechanisms (but then I may have forgotten...)

I also don't think blacklisting exists. I just checked policy and it
doesn't mention anything like it. Instead of listing all archs except
for mipsel, I would just check the architecture in debian/rules and exit
non-zero if the architecture is mipsel.

Paul



signature.asc
Description: OpenPGP digital signature

Bug#961411: apt search -- output NOT grepable

[Leszek Dubiel]

W dniu 24.05.2020 o 18:49, Lee pisze:


You can use awk to put the lines together and then grep:

$ apt search perl | awk -v RS="" '{gsub("\n",""); print $0}' | grep
JSON | grep -i data


Yes... you're right.. but it's hard to remember... and I find myself 
going back to "apt-cache" ...




W dniu 24.05.2020 o 15:35, Julian Andres Klode pisze:


It's a feature, not a bug. It's significantly easier to read. Future versions
of apt search will also


I would suggest to change status to "feature request/whish list".




* pipe output through a pager, so just search in there
* support searching via patterns, so just search that way (see apt-patterns 
manpage,
   plus there'll be ?description pattern)

As to scriptable interfaces - we're still working on how to make apt usable
in scripts while maintaining our ability to break the behavior and output
formats. There will probably be some sort of compat levels and/or output
format specifiers at a future point, at which point apt will be useful
in scripts.


I suggest adding option "--raw" to print raw search results, same as 
with "apt-cache", so:


apt search perl --raw | grep -i json | grep -i data | ... and other 
filters user like to apply

Bug#961427: ITP: python-discord -- API wrapper for Discord written in Python

[Robin Gustafsson]

Package: wnpp
Severity: wishlist
Owner: Robin Gustafsson 

* Package name: python-discord
  Version : 1.3.3 
  Upstream Author : Rapptz
* URL : https://github.com/Rapptz/discord.py
* License : MIT
  Programming Lang: Python
  Description : API wrapper for Discord written in Python

A modern, easy to use, feature-rich, and async ready API wrapper for Discord
written in Python.

Key Features:
 * Modern Pythonic API using async and await.
 * Proper rate limit handling.
 * 100% coverage of the supported Discord API.
 * Optimised in both speed and memory.

If accepted, I intend to maintain this within the Python Modules team.

Bug#961452: CVE-2020-6096

[Moritz Muehlenhoff]

Source: glibc
Severity: important

Please see
https://sourceware.org/bugzilla/show_bug.cgi?id=25620
https://talosintelligence.com/vulnerability_reports/TALOS-2020-1019

Cheers,
Moritz

Bug#625696: debmirror: needs fixing for security.debian.org

[Kees Cook]

Package: debmirror
Version: 1:2.33
Followup-For: Bug #625696

This needs fixing for security.debian.org. Right now I'm forced to use
"--rsync-extra none" which seems sub-optimal. :)

Bug#961450: changelog.gz is different between amd64 and i386 packages

[Felix Zielcke]

Package: libsqlite3-0
Version: 3.32.0-1
Severity: important

Now that changelog.gz is generated on build time to fix #959983 it can't be 
co-installed for amd64 and i386:

Preparing to unpack .../libsqlite3-dev_3.32.0-1_amd64.deb ...
Unpacking libsqlite3-dev:amd64 (3.32.0-1) over (3.31.1-5) ...
Preparing to unpack .../libsqlite3-0_3.32.0-1_i386.deb ...
De-configuring libsqlite3-0:amd64 (3.31.1-5) ...
Unpacking libsqlite3-0:i386 (3.32.0-1) over (3.31.1-5) ...
Preparing to unpack .../libsqlite3-0_3.32.0-1_amd64.deb ...
Unpacking libsqlite3-0:amd64 (3.32.0-1) over (3.31.1-5) ...
dpkg: error processing archive 
/var/cache/apt/archives/libsqlite3-0_3.32.0-1_amd64.deb (--unpack):
 trying to overwrite shared '/usr/share/doc/libsqlite3-0/changelog.gz', which 
is different from other instances of package libsqlite3-0:amd64
dpkg-deb: error: paste subprocess was killed by signal (Broken pipe)
Errors were encountered while processing:
 /var/cache/apt/archives/libsqlite3-0_3.32.0-1_amd64.deb
E: Sub-process /usr/bin/dpkg returned an error code (1)


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

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

Versions of packages libsqlite3-0 depends on:
ii  libc6  2.30-8

libsqlite3-0 recommends no packages.

libsqlite3-0 suggests no packages.

-- no debconf information

Bug#961451: CVE-2020-12829

[Moritz Muehlenhoff]

Source: qemu
Severity: normal
Tags: security

This was originally reported in Red Hat Bugzilla:

https://bugzilla.redhat.com/show_bug.cgi?id=1808510
https://bugzilla.redhat.com/show_bug.cgi?id=1786026

Cheers,
Moritz

Bug#961432: RFP: picom -- lightweight compositor for X11

[Nikos Tsipinakis]

retitle -1 ITP: picom -- lightweight compositor for X11
owner -1
thanks

My initial thought was that the compton maintainer should be the one to take
this over, but it looks like[1] compton was orphaned as its maintainer moved on
to wayland.

In which case, I'm interested in packaging this.

- Nikos

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

Bug#961398: src:quantlib-swig: fails to migrate to testing for too long: FTBFS on mipsel

[Dirk Eddelbuettel]

On 24 May 2020 at 18:47, Paul Gevers wrote:
| Hi Dirk,
| 
| On 24-05-2020 13:43, Dirk Eddelbuettel wrote:
| > This used to build. It just takes a long as it is a library with old-school
| > many templates "big C++".
| > 
| > There is nothing I can do here. If it ends being removed because nobody can
| > change the build toggle on that platform so be it.
| > 
| > I understand the concern and agree with it.  But there is nothing I think I
| > can do.
| 
| There is. If you think you can't reliably fix the issue, you can ask the
| ftp-masters to remove the mipsel binary. Once the mipsel binary is gone,
| the package can migrate. Please make sure that the binary isn't build by
| accident in the future in that case.

I can happily do either.

But how I prevent the build in the future?

Via 'Architecture: any [!xyx]' ?  Last I checked I though we had no such
explicit white/black listing mechanisms (but then I may have forgotten...)

Dirk

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

Bug#961422: [Pkg-erlang-devel] Bug#961422: yaws: CVE-2020-12872

[Sergei Golovan]

Hi Salvatore,

On Sun, May 24, 2020 at 4:09 PM Salvatore Bonaccorso  wrote:
>
> The following vulnerability was published for yaws.
>
> CVE-2020-12872[0]:
> | yaws_config.erl in Yaws through 2.0.2 and/or 2.0.7 loads obsolete TLS
> | ciphers, as demonstrated by ones that allow Sweet32 attacks.
>

As far as I can see, YAWS just uses the ciphersuite offered by the Erlang ssl
application. It indeed includes 3DES based ciphers in Erlang 19.2.1 (in stretch)
and in Erlang 17.3 (in jessie), but doesn't do so in Erlang 21.2.6 (in
buster) and
in later versions (in bullseye, sid and experimental).

So, currently, YAWS is vulnerable for jessie and stretch only.

>
> If you fix the vulnerability please also make sure to include the
> CVE (Common Vulnerabilities & Exposures) id in your changelog entry.

I would rather suggest to reassign this bug to erlang-ssl, and fix it there
(as not only YAWS can use this list of ciphers).

I've already prepared a patch for erlang in stretch, and if you think
it's an acceptable way
of fixing this bug, I'll inform the release team about it.

I wouldn't like to do anything about jessie, since its LTS support
comes to an end soon.

Sheers!
-- 
Sergei Golovan

Bug#961398: src:quantlib-swig: fails to migrate to testing for too long: FTBFS on mipsel

[Paul Gevers]

Hi Dirk,

On 24-05-2020 13:43, Dirk Eddelbuettel wrote:
> This used to build. It just takes a long as it is a library with old-school
> many templates "big C++".
> 
> There is nothing I can do here. If it ends being removed because nobody can
> change the build toggle on that platform so be it.
> 
> I understand the concern and agree with it.  But there is nothing I think I
> can do.

There is. If you think you can't reliably fix the issue, you can ask the
ftp-masters to remove the mipsel binary. Once the mipsel binary is gone,
the package can migrate. Please make sure that the binary isn't build by
accident in the future in that case.

Paul



signature.asc
Description: OpenPGP digital signature

Bug#961449: network-manager: fails to connect to wifi after upgrading to sid

[Hill Ma]

Package: network-manager
Version: 1.24.0-1
Severity: important

Dear Maintainer,

After upgrading to sid from Debian 10, I my home WiFi does not connect any more.
Booting from the 4.19 kernel that worked does not solve the problem.

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

Kernel: Linux 5.6.0-1-686-pae (SMP w/1 CPU core)
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 network-manager depends on:
ii  adduser  3.118
ii  dbus 1.12.16-2
ii  init-system-helpers  1.57
ii  libaudit11:2.8.5-3+b1
ii  libbluetooth35.50-1.2
ii  libc62.30-8
ii  libcurl3-gnutls  7.68.0-1
ii  libglib2.0-0 2.64.2-1
ii  libgnutls30  3.6.13-2
ii  libjansson4  2.12-1
ii  libmm-glib0  1.12.8-1.1
ii  libndp0  1.6-1+b1
ii  libnewt0.52  0.52.21-4+b1
ii  libnm0   1.24.0-1
ii  libpam-systemd   245.5-3
ii  libpsl5  0.21.0-1
ii  libreadline8 8.0-4
ii  libselinux1  3.0-1+b3
ii  libsystemd0  245.5-3
ii  libteamdctl0 1.30-1
ii  libudev1 245.5-3
ii  libuuid1 2.35.2-2
ii  policykit-1  0.105-26
ii  udev 245.5-3
ii  wpasupplicant2:2.9.0-13

Versions of packages network-manager recommends:
ii  crda 4.14+git20191112.9856751-1
ii  dnsmasq-base [dnsmasq-base]  2.81-3
ii  iptables 1.8.4-3
ii  modemmanager 1.12.8-1.1
ii  ppp  2.4.7-2+4.1+deb10u1

Versions of packages network-manager suggests:
ii  isc-dhcp-client  4.4.1-2.1+b2
pn  libteam-utils

-- no debconf information
-- Logs begin at Thu 2020-05-21 22:26:58 PDT. --
May 24 09:20:10 debian NetworkManager[436]:   [1590337210.1949] device 
(wlan0): set-hw-addr: set MAC address to 5E:95:36:8F:B8:2A (scanning)
May 24 09:20:10 debian kernel: b43-phy0: Loading firmware version 784.2 
(2012-08-15 21:35:19)
May 24 09:20:10 debian NetworkManager[436]:   [1590337210.5670] manager: 
NetworkManager state is now DISCONNECTED
May 24 09:20:10 debian NetworkManager[436]:   [1590337210.5861] device 
(wlan0): supplicant interface state: associated -> disconnected
May 24 09:20:10 debian NetworkManager[436]:   [1590337210.7030] device 
(wlan0): supplicant interface state: disconnected -> interface_disabled
May 24 09:20:10 debian NetworkManager[436]:   [1590337210.7040] device 
(wlan0): supplicant interface state: interface_disabled -> disconnected
May 24 09:20:14 debian sudo[3238]: pam_unix(sudo:auth): Couldn't open 
/etc/securetty: No such file or directory
May 24 09:20:17 debian sudo[3238]: pam_unix(sudo:auth): Couldn't open 
/etc/securetty: No such file or directory
May 24 09:20:17 debian sudo[3238]:   hillma : TTY=pts/1 ; PWD=/home/hillma ; 
USER=root ; COMMAND=/usr/bin/journalctl -f
May 24 09:20:17 debian sudo[3238]: pam_unix(sudo:session): session opened for 
user root by (uid=0)
May 24 09:20:20 debian systemd[1]: NetworkManager-dispatcher.service: Succeeded.
May 24 09:20:23 debian NetworkManager[436]:   [1590337223.0060] device 
(wlan0): Activation: starting connection 'Autobahn' 
(625bfd1f-277b-425f-972d-f2f9de3984c6)
May 24 09:20:23 debian NetworkManager[436]:   [1590337223.0091] audit: 
op="connection-activate" uuid="625bfd1f-277b-425f-972d-f2f9de3984c6" 
name="Autobahn" pid=2329 uid=1000 result="success"
May 24 09:20:23 debian NetworkManager[436]:   [1590337223.0114] device 
(wlan0): state change: disconnected -> prepare (reason 'none', sys-iface-state: 
'managed')
May 24 09:20:23 debian NetworkManager[436]:   [1590337223.0180] manager: 
NetworkManager state is now CONNECTING
May 24 09:20:23 debian NetworkManager[436]:   [1590337223.1077] device 
(wlan0): set-hw-addr: reset MAC address to 00:14:A5:8C:93:5A (preserve)
May 24 09:20:23 debian kernel: b43-phy0: Loading firmware version 784.2 
(2012-08-15 21:35:19)
May 24 09:20:23 debian NetworkManager[436]:   [1590337223.4791] device 
(wlan0): state change: prepare -> config (reason 'none', sys-iface-state: 
'managed')
May 24 09:20:23 debian NetworkManager[436]:   [1590337223.4915] device 
(wlan0): Activation: (wifi) access point 'Autobahn' has security, but secrets 
are required.
May 24 09:20:23 debian NetworkManager[436]:   [1590337223.4923] device 
(wlan0): state change: config -> need-auth (reason 'none', sys-iface-state: 
'managed')
May 24 09:20:23 debian NetworkManager[436]:   [1590337223.6248] device 
(wlan0): supplicant interface state: disconnected -> interface_disabled
May 24 09:20:23 debian NetworkManager[436]:   [1590337223.6264] device 
(wlan0): supplicant interface state: interface_disabled -> disconnected
May 24 09:20:23 debian NetworkManager[436]:   [1590337223.6370] 

Bug#961411: apt search -- output NOT grepable

[Lee]

On 5/24/20, Leszek Dubiel  wrote:
> Package: apt
> Version: 1.8.2.1
> Severity: normal
>
> I've completely switched to using "apt" for all debian package management.
> I'm fine with the "apt" tool, it fits all my needs except one... serarching.
>
> For example I look for package to read/write JSON data in perl. In old days
> I used the command "apt-cache search" like this:
>
>   leszek@len530:~$ apt-cache search perl | egrep JSON | egrep -i data
>
> and the result was simple:
>
>   libjson-perl - module for manipulating JSON-formatted data
>   libjson-xs-perl - module for manipulating JSON-formatted data
> (C/XS-accelerated)
>   libcatmandu-importer-getjson-perl - load JSON-encoded data from a server
> using a GET HTTP request
>   libjson-pp-perl - module for manipulating JSON-formatted data (Pure 
> Perl)
>   libjson-validator-perl - module to validate data against a JSON schema
>   libtest-deep-json-perl - Test::Deep plugin for comparing JSON data
>   libtest-json-perl - module for testing JSON data
>
>
> Because "apt search" (not "apt-cache search", just "apt") shows each package
> on two lines, then grepping results is not possible.

You can use awk to put the lines together and then grep:

$ apt search perl | awk -v RS="" '{gsub("\n",""); print $0}' | grep
JSON | grep -i data

WARNING: apt does not have a stable CLI interface. Use with caution in scripts.

libcatmandu-importer-getjson-perl/oldstable 0.50-1 all  load
JSON-encoded data from a server using a GET HTTP request
libjson-perl/oldstable 2.90-1 all  module for manipulating JSON-formatted data
libjson-pp-perl/oldstable 2.27400-1 all  module for manipulating
JSON-formatted data (Pure Perl)
libjson-validator-perl/oldstable 0.92+dfsg-1 all  module to validate
data against a JSON schema
libjson-xs-perl/oldstable 3.030-1 i386  module for manipulating
JSON-formatted data (C/XS-accelerated)
libtest-deep-json-perl/oldstable 0.03-1 all  Test::Deep plugin for
comparing JSON data
libtest-json-perl/oldstable 0.11-2 all  module for testing JSON data

Regards,
Lee

Bug#961351: r-cran-bms: autopkgtest failure

[Adrian Bunk]

On Sat, May 23, 2020 at 04:13:55PM +0200, Sebastian Ramacher wrote:
> Source: r-cran-bms
> Version: 0.3.4-5
> Severity: serious
> 
> The autopkgtest of r-cran-bms fails in unstable:
> | autopkgtest [07:20:33]: test run-unit-test: [---
> | gzip: *.gz: No such file or directory
> | autopkgtest [07:20:33]: test run-unit-test: ---]
> | autopkgtest [07:20:33]: test run-unit-test:  - - - - - - - - - - results - 
> - - - - - - - - -
> | run-unit-testFAIL non-zero exit status 1
>...

Examples are no longer compressed with dh compat 12.

cu
Adrian

Bug#961448: r-cran-learnbayes: autopkgtest failure

[Adrian Bunk]

Source: r-cran-learnbayes
Version: 2.15.1-3
Severity: serious

https://ci.debian.net/data/autopkgtest/testing/amd64/r/r-cran-learnbayes/5625650/log.gz

...
autopkgtest [08:07:53]: test run-unit-test: [---
gzip: *.gz: No such file or directory
autopkgtest [08:07:53]: test run-unit-test: ---]
autopkgtest [08:07:53]: test run-unit-test:  - - - - - - - - - - results - - - 
- - - - - - -
run-unit-testFAIL non-zero exit status 1



Examples are no longer compressed with dh compat 12.

Bug#954089: libplack-perl: Please verify server identity via SSL

[Dominic Hargreaves]

On Wed, May 20, 2020 at 11:02:20PM +0100, Dominic Hargreaves wrote:
> Hello everyone, I just caught up with this. (Side note - please don't
> assume I will see a message sent to a random pkg-perl bug report[1].)
> 
> On Sun, May 17, 2020 at 06:39:34PM +0300, Damyan Ivanov wrote:
> > -=| gregor herrmann, 15.05.2020 21:14:35 +0200 |=-
> > > On Thu, 19 Mar 2020 14:39:13 +0200, Damyan Ivanov wrote:
> > > 
> > > > > > But to fully measure the impact, it would be nice to have the 
> > > > > > number 
> > > > > > of failing packages built with a patched HTTP::Tiny.
> > > > > I have one small concern: As the change is about checking remote SSL
> > > > > certs, and tests don't/can't/must not call out to the internet, is it
> > > > > possible that we won't really catch all potential issues?
> > > > Noted. The test rebuilds should be done without the usual isolation 
> > > > from the Internet.
> > > > I guess a closer inspection of the affected packages is needed.
> > > 
> > > Hi Dam and all,
> > > 
> > > did you or anyone else get to look into this rebuild effort?
> > 
> > I haven't. I am still at the stage of "(re-)invent an easy way to 
> > rebuild a list of packages with a crafted chroot". I don't see this 
> > changing soon, so please Dom, anybody, feel free to take the job.
> > 
> > > If not, Dom said that he could also try the rebuilds on
> > > perl.debian.net.
> > > 
> > > Notes:
> > > - HTTP::Tiny is in perl core and in libhttp-tiny-perl;
> > > - The required change looks like a one-character-patch:
> > >   lib/HTTP/Tiny.pm:verify_SSL   => $args{verify_SSL} || 
> > > $args{verify_ssl} || 0, # no verification by default
> > > - The tests should be run with internet enabled as much as possible.
> 
> I am happy to do this, but I want to add a large caution: I do not
> think that a clean bill of health from rebuild testing by itself
> will allow us to draw any meaningful conclusions. It'd tell us that 
> the unit tests were correctly disabling SSL verification in their test
> suites, or their test suites don't test SSL-related functionality, or
> their test suites (inappropriately) rely on external servers with
> correct SSL setups.
> 
> But what's much more important here, surely, is what effect such a
> change will have on our users in the real world, who will be using
> this module to talk to the internet, and not to mention their own
> internal services. I don't really see a way to know the scale of
> breakage this will cause without trying it and seeing how much noise
> there is from our (unstable) users.
> 
> Note that this is not a reason to avoid making the change. I just want
> to make sure we're going into this with our eyes open.

I rebuilt perl with the patch at [1] and rebuild perl dependencies
against it, and did not see any related failures [2].

NB: probably perl should grow a suggestion (at least) on
on libnet-ssleay-perl and libio-ssl-socket-perl which are required
to use HTTP::Tiny with https URLs.

So, what are people's thoughts? Do we want to take this position
and change the default in Debian? Extending distribution to debian-perl
for wider visibility.

Cheers
Dominic

[1] 

[2] 

Bug#961447: bup: 0.30.1 released, fixing notable bugs

[Rob Browning]

Package: bup
Version: 0.29.3

Just released 0.30.1, including some notable bug fixes.  I'd recommend
replacing the version in sid if feasible:

  https://github.com/bup/bup/blob/0.30.x/note/0.30.1-from-0.30.md

Perhaps worth mentioning that 0.30.* still doesn't support python 3.
We're finishing up python 3 support for the next non-Z version (likely
0.31, hopefully "soon").

Thanks much
-- 
Rob Browning
rlb @defaultvalue.org and @debian.org
GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C4 C0F0 39E9 ED1B 597A
GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4

Bug#961446: r-cran-nozzle.r1 lost dependencies on libjs-jquery, libjs-jquery-tablesorter

[Adrian Bunk]

Package: r-cran-nozzle.r1
Version: 1.1-1+dfsg-3
Severity: serious
Control: affects -1 src:r-cran-nozzle.r1

https://salsa.debian.org/r-pkg-team/r-cran-nozzle.r1/-/commit/7d7b872597ffa83f453db4d3b43c0e66d49bd479

This is also the root cause of the autopkgtest failure:
https://ci.debian.net/data/autopkgtest/testing/amd64/r/r-cran-nozzle.r1/5625651/log.gz

Bug#961445: grcompiler FTBFS on big endian

[Adrian Bunk]

Source: grcompiler
Version: 5.2-1
Severity: serious
Tags: ftbfs

https://buildd.debian.org/status/package.php?p=grcompiler=sid

...
1/15 Test  #1: compile_SchTest .***Failed0.06 sec
Frexx C Preprocessor v1.5 Copyright (C) by FrexxWare 1993 - 1997.
Revised by SIL International for Graphite Description Language, May 24 2020
Graphite Compiler Version 5.2  [release build]
Copyright (c) 2002-2020, by SIL International.  All rights reserved.
Reading input font...

GDL file: /<>/test/GrcRegressionTest/fonts/SchMain.gdl
PreProcessor: /<>/obj-s390x-linux-gnu/preprocessor/gdlpp
Input TT file: /<>/test/GrcRegressionTest/fonts/SchInput.ttf
Output TT file: SchTest.ttf
Output font name: unknown (unchanged)
Silf table version requested: 4.0

Parsing file /<>/test/GrcRegressionTest/fonts/SchMain.gdl...
Parsing failed.
2 errors have been output to 
/<>/obj-s390x-linux-gnu/test/GrcRegressionTest/SchTest.gdlerr.txt.
...


debian-s390 is Cc'ed.

Bug#961444: grcompiler FTBFS on architectures where char is unsigned

[Adrian Bunk]

Source: grcompiler
Version: 5.2-1
Severity: serious
Tags: ftbfs

https://buildd.debian.org/status/package.php?p=grcompiler=sid

...
 7/15 Test #13: compile_PadaukTest_v3 ...Child aborted***Exception: 
  0.20 sec
Frexx C Preprocessor v1.5 Copyright (C) by FrexxWare 1993 - 1997.
Revised by SIL International for Graphite Description Language, May 24 2020
grcompiler: /<>/compiler/GdlExpression.cpp:3259: virtual void 
GdlSlotRefExpression::GenerateEngineCode(int, std::vector&, int, 
std::vector*, int, bool, int, int*): Assertion `(int)bOffset == nOffset' 
failed.
...


The build passes if I rewrite the line above the assert to
  signed char bOffset = (signed char)nOffset;
but someone who knows the code better should check what
is actually the correct fix.

Bug#961416: dh-make: Typo in Python sphinxdoc instructions

[Robin Gustafsson]

Package: dh-make
Version: 2.202001
Severity: minor
Tags: patch

Dear Maintainer,

There's a typo in the instructions for how to build Sphinx docs in
Python packages.

> # If you need to rebuild the Sphinx documentation
> # Add spinxdoc to the dh --with line

Following these instructions result in the error message
> dh: unable to load addon spinxdoc
because the sequence is actually named 'sphinxdoc'.

The patch is trivial:

--- /usr/bin/dh_make2020-02-29 01:14:18.0 +
+++ /tmp/zshKFkKBv  2020-05-24 12:01:54.130417637 +
@@ -662,3 +662,3 @@
 # If you need to rebuild the Sphinx documentation
-# Add spinxdoc to the dh --with line
+# Add sphinxdoc to the dh --with line
 #

Regards,
Robin

Bug#961443: buster-pu: package perl/5.28.2

[Dominic Hargreaves]

Package: release.debian.org
User: release.debian@packages.debian.org
Usertags: pu
Tags: buster
X-Debbugs-Cc: nt...@debian.org, debian-p...@lists.debian.org

Hi release team,

The perl interpreter team would like to move to a model where we
attempt to keep Debian stable releases more or less in sync with
upstream maint branches - which are conservatively maintained along the
lines of the policies here, which match pretty well with Debian's:

https://perldoc.perl.org/5.30.0/perlpolicy.html#MAINTENANCE-BRANCHES

In the past we have done a more or less complete import of new
upstream releases (excluding patches which do not affect Debian) whilst
keeping the previous version number intact[1]. This was done out of
an abundance of caution (not knowing the risks of the upstream version
number changing in stable) but, after a few more years of relatively
pain free transitions in unstable, we think that the cost/risk of the
manual cherry-picking procedure, together with the lack of transparency
to users about which version they are running, outweighs the potential
benefits of keeping the upstream version unchanged.

Therefore, we propose to apply the 5.28.2 release to buster at the next
opportunity (is the next stable update scheduled?)

A tentative branch is at [2], and an abbreviated patch (excluding
churn caused by version numbers and developer documentation) and
separately, the upstream changelog, is attached.

One complicating factor would be the need to binnmu four packages
that are sensitive to the upstream version number as part of the
stable update, as we routinely do for updates in unstable. Beyond that,
we don't anticipate any major issues. We would do a complete test
rebuild of perl-related packages in advance to catch any other
issues (an learning point from the update in [1]).

Thanks for your consideration.

[1] 
[2] 

=encoding utf8

=head1 NAME

perldelta - what is new for perl v5.28.2

=head1 DESCRIPTION

This document describes differences between the 5.28.1 release and the 5.28.2
release.

If you are upgrading from an earlier release such as 5.28.0, first read
L, which describes differences between 5.28.0 and 5.28.1.

=head1 Incompatible Changes

=head2 Any set of digits in the Common script are legal in a script run of
another script

There are several sets of digits in the Common script.  C<[0-9]> is the most
familiar.  But there are also C<[\x{FF10}-\x{FF19}]> (FULLWIDTH DIGIT ZERO -
FULLWIDTH DIGIT NINE), and several sets for use in mathematical notation, such
as the MATHEMATICAL DOUBLE-STRUCK DIGITs.  Any of these sets should be able to
appear in script runs of, say, Greek.  But the previous design overlooked all
but the ASCII digits C<[0-9]>, so the design was flawed.  This has been fixed,
so is both a bug fix and an incompatibility.

All digits in a run still have to come from the same set of ten digits.

L<[perl #133547]|https://rt.perl.org/Ticket/Display.html?id=133547>

=head1 Modules and Pragmata

=head2 Updated Modules and Pragmata

=over 4

=item *

L has been upgraded from version 5.20181129_28 to 5.20190419.

=item *

L has been upgraded from version 0.29 to 0.30.

=item *

L has been upgraded from version 3.08 to 3.08_01.

=back

=head1 Platform Support

=head2 Platform-Specific Notes

=over 4

=item Windows

The Windows Server 2003 SP1 Platform SDK build, with its early x64 compiler and
tools, was accidentally broken in Perl 5.27.9.  This has now been fixed.

=item Mac OS X

Perl's build and testing process on Mac OS X for C<-Duseshrplib> builds is now
compatible with Mac OS X System Integrity Protection (SIP).

SIP prevents binaries in F (and a few other places) being passed the
C environment variable.  For our purposes this prevents
C from being passed to the shell, which prevents that
variable being passed to the testing or build process, so running C
couldn't find F.

To work around that, the initial build of the F executable expects to
find F in the build directory, and the library path is then
adjusted during installation to point to the installed library.

L<[perl #126706]|https://rt.perl.org/Ticket/Display.html?id=126706>

=back

=head1 Selected Bug Fixes

=over 4

=item *

If an in-place edit is still in progress during global destruction and the
process exit code (as stored in C<$?>) is zero, perl will now treat the
in-place edit as successful, replacing the input file with any output produced.

This allows code like:

  perl -i -ne 'print "Foo"; last'

to replace the input file, while code like:

  perl -i -ne 'print "Foo"; die'

will not.  Partly resolves [perl #133659].

L<[perl #133659]|https://rt.perl.org/Ticket/Display.html?id=133659>

=item *

A regression in Perl 5.28 caused the following code to fail

 close(STDIN); open(CHILD, "|wc -l")'

because the child's stdin would be closed on exec.  This has now been fixed.

=item 

Bug#961440: stretch-pu: package clamav/0.102.3+dfsg-0~deb9u1

[Sebastian Andrzej Siewior]

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

ClamAV upstream released 0.102.3 fixing two CVEs. From their news:

|ClamAV 0.102.3 is a bug patch release to address the following issues.
|
|- 
[CVE-2020-3327](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-3327):
|  Fix a vulnerability in the ARJ archive parsing module in ClamAV 0.102.2 that
|  could cause a Denial-of-Service (DoS) condition. Improper bounds checking of
|  an unsigned variable results in an out-of-bounds read which causes a crash.
|
|  Special thanks to Daehui Chang and Fady Othman for helping identify the ARJ
|  parsing vulnerability.
|
|- 
[CVE-2020-3341](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-3341):
|  Fix a vulnerability in the PDF parsing module in ClamAV 0.101 - 0.102.2 that
|  could cause a Denial-of-Service (DoS) condition. Improper size checking of
|  a buffer used to initialize AES decryption routines results in an out-of-
|  bounds read which may cause a crash. Bug found by OSS-Fuzz.
|
|- Fix "Attempt to allocate 0 bytes" error when parsing some PDF documents.
|
|- Fix a couple of minor memory leaks.

The 0.102.3 version is in unstable since 16th and migrated to testing.

Sebastian
diff -Nru clamav-0.102.2+dfsg/configure clamav-0.102.3+dfsg/configure
--- clamav-0.102.2+dfsg/configure	2020-02-04 15:59:26.0 +0100
+++ clamav-0.102.3+dfsg/configure	2020-05-12 03:54:49.0 +0200
@@ -1,6 +1,6 @@
 #! /bin/sh
 # Guess values for system-dependent variables and create Makefiles.
-# Generated by GNU Autoconf 2.69 for ClamAV 0.102.2.
+# Generated by GNU Autoconf 2.69 for ClamAV 0.102.3.
 #
 # Report bugs to .
 #
@@ -592,8 +592,8 @@
 # Identity of this package.
 PACKAGE_NAME='ClamAV'
 PACKAGE_TARNAME='clamav'
-PACKAGE_VERSION='0.102.2'
-PACKAGE_STRING='ClamAV 0.102.2'
+PACKAGE_VERSION='0.102.3'
+PACKAGE_STRING='ClamAV 0.102.3'
 PACKAGE_BUGREPORT='https://bugzilla.clamav.net/'
 PACKAGE_URL='https://www.clamav.net/'
 
@@ -1601,7 +1601,7 @@
   # Omit some internal or obsolete options to make the list less imposing.
   # This message is too long to be a string in the A/UX 3.1 sh.
   cat <<_ACEOF
-\`configure' configures ClamAV 0.102.2 to adapt to many kinds of systems.
+\`configure' configures ClamAV 0.102.3 to adapt to many kinds of systems.
 
 Usage: $0 [OPTION]... [VAR=VALUE]...
 
@@ -1682,7 +1682,7 @@
 
 if test -n "$ac_init_help"; then
   case $ac_init_help in
- short | recursive ) echo "Configuration of ClamAV 0.102.2:";;
+ short | recursive ) echo "Configuration of ClamAV 0.102.3:";;
esac
   cat <<\_ACEOF
   --enable-dependency-tracking
@@ -1911,7 +1911,7 @@
 test -n "$ac_init_help" && exit $ac_status
 if $ac_init_version; then
   cat <<\_ACEOF
-ClamAV configure 0.102.2
+ClamAV configure 0.102.3
 generated by GNU Autoconf 2.69
 
 Copyright (C) 2012 Free Software Foundation, Inc.
@@ -2539,7 +2539,7 @@
 This file contains any messages produced by compilers while
 running configure, to aid debugging if configure makes a mistake.
 
-It was created by ClamAV $as_me 0.102.2, which was
+It was created by ClamAV $as_me 0.102.3, which was
 generated by GNU Autoconf 2.69.  Invocation command line was
 
   $ $0 $@
@@ -4297,7 +4297,7 @@
 
 # Define the identity of the package.
  PACKAGE='clamav'
- VERSION='0.102.2'
+ VERSION='0.102.3'
 
 
 # Some tools Automake needs.
@@ -6025,7 +6025,7 @@
 $as_echo "#define PACKAGE PACKAGE_NAME" >>confdefs.h
 
 
-VERSION="0.102.2"
+VERSION="0.102.3"
 
 major=`echo $PACKAGE_VERSION |cut -d. -f1 | sed -e "s/^0-9//g"`
 minor=`echo $PACKAGE_VERSION |cut -d. -f2 | sed -e "s/^0-9//g"`
@@ -31630,7 +31630,7 @@
 # report actual input values of CONFIG_FILES etc. instead of their
 # values after options handling.
 ac_log="
-This file was extended by ClamAV $as_me 0.102.2, which was
+This file was extended by ClamAV $as_me 0.102.3, which was
 generated by GNU Autoconf 2.69.  Invocation command line was
 
   CONFIG_FILES= $CONFIG_FILES
@@ -31697,7 +31697,7 @@
 cat >>$CONFIG_STATUS <<_ACEOF || ac_write_fail=1
 ac_cs_config="`$as_echo "$ac_configure_args" | sed 's/^ //; s/[\\""\`\$]/&/g'`"
 ac_cs_version="\\
-ClamAV config.status 0.102.2
+ClamAV config.status 0.102.3
 configured by $0, generated by GNU Autoconf 2.69,
   with options \\"\$ac_cs_config\\"
 
@@ -34548,7 +34548,7 @@
 # report actual input values of CONFIG_FILES etc. instead of their
 # values after options handling.
 ac_log="
-This file was extended by ClamAV $as_me 0.102.2, which was
+This file was extended by ClamAV $as_me 0.102.3, which was
 generated by GNU Autoconf 2.69.  Invocation command line was
 
   CONFIG_FILES= $CONFIG_FILES
@@ -34615,7 +34615,7 @@
 cat >>$CONFIG_STATUS <<_ACEOF || ac_write_fail=1
 ac_cs_config="`$as_echo "$ac_configure_args" | sed 's/^ //; s/[\\""\`\$]/&/g'`"
 ac_cs_version="\\
-ClamAV config.status 0.102.2
+ClamAV config.status 0.102.3
 configured by $0, generated by GNU 

Bug#961439: buster-pu: package clamav/0.102.3+dfsg-0+deb10u1

[Sebastian Andrzej Siewior]

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

ClamAV upstream released 0.102.3 fixing two CVEs. From their news:

|ClamAV 0.102.3 is a bug patch release to address the following issues.
|
|- 
[CVE-2020-3327](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-3327):
|  Fix a vulnerability in the ARJ archive parsing module in ClamAV 0.102.2 that
|  could cause a Denial-of-Service (DoS) condition. Improper bounds checking of
|  an unsigned variable results in an out-of-bounds read which causes a crash.
|
|  Special thanks to Daehui Chang and Fady Othman for helping identify the ARJ
|  parsing vulnerability.
|
|- 
[CVE-2020-3341](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-3341):
|  Fix a vulnerability in the PDF parsing module in ClamAV 0.101 - 0.102.2 that
|  could cause a Denial-of-Service (DoS) condition. Improper size checking of
|  a buffer used to initialize AES decryption routines results in an out-of-
|  bounds read which may cause a crash. Bug found by OSS-Fuzz.
|
|- Fix "Attempt to allocate 0 bytes" error when parsing some PDF documents.
|
|- Fix a couple of minor memory leaks.

The 0.102.3 version is in unstable since 16th and migrated to testing. I
have the Buster version deployed on a machine.

Sebastian
diff -Nru clamav-0.102.2+dfsg/configure clamav-0.102.3+dfsg/configure
--- clamav-0.102.2+dfsg/configure	2020-02-04 15:59:26.0 +0100
+++ clamav-0.102.3+dfsg/configure	2020-05-12 03:54:49.0 +0200
@@ -1,6 +1,6 @@
 #! /bin/sh
 # Guess values for system-dependent variables and create Makefiles.
-# Generated by GNU Autoconf 2.69 for ClamAV 0.102.2.
+# Generated by GNU Autoconf 2.69 for ClamAV 0.102.3.
 #
 # Report bugs to .
 #
@@ -592,8 +592,8 @@
 # Identity of this package.
 PACKAGE_NAME='ClamAV'
 PACKAGE_TARNAME='clamav'
-PACKAGE_VERSION='0.102.2'
-PACKAGE_STRING='ClamAV 0.102.2'
+PACKAGE_VERSION='0.102.3'
+PACKAGE_STRING='ClamAV 0.102.3'
 PACKAGE_BUGREPORT='https://bugzilla.clamav.net/'
 PACKAGE_URL='https://www.clamav.net/'
 
@@ -1601,7 +1601,7 @@
   # Omit some internal or obsolete options to make the list less imposing.
   # This message is too long to be a string in the A/UX 3.1 sh.
   cat <<_ACEOF
-\`configure' configures ClamAV 0.102.2 to adapt to many kinds of systems.
+\`configure' configures ClamAV 0.102.3 to adapt to many kinds of systems.
 
 Usage: $0 [OPTION]... [VAR=VALUE]...
 
@@ -1682,7 +1682,7 @@
 
 if test -n "$ac_init_help"; then
   case $ac_init_help in
- short | recursive ) echo "Configuration of ClamAV 0.102.2:";;
+ short | recursive ) echo "Configuration of ClamAV 0.102.3:";;
esac
   cat <<\_ACEOF
   --enable-dependency-tracking
@@ -1911,7 +1911,7 @@
 test -n "$ac_init_help" && exit $ac_status
 if $ac_init_version; then
   cat <<\_ACEOF
-ClamAV configure 0.102.2
+ClamAV configure 0.102.3
 generated by GNU Autoconf 2.69
 
 Copyright (C) 2012 Free Software Foundation, Inc.
@@ -2539,7 +2539,7 @@
 This file contains any messages produced by compilers while
 running configure, to aid debugging if configure makes a mistake.
 
-It was created by ClamAV $as_me 0.102.2, which was
+It was created by ClamAV $as_me 0.102.3, which was
 generated by GNU Autoconf 2.69.  Invocation command line was
 
   $ $0 $@
@@ -4297,7 +4297,7 @@
 
 # Define the identity of the package.
  PACKAGE='clamav'
- VERSION='0.102.2'
+ VERSION='0.102.3'
 
 
 # Some tools Automake needs.
@@ -6025,7 +6025,7 @@
 $as_echo "#define PACKAGE PACKAGE_NAME" >>confdefs.h
 
 
-VERSION="0.102.2"
+VERSION="0.102.3"
 
 major=`echo $PACKAGE_VERSION |cut -d. -f1 | sed -e "s/^0-9//g"`
 minor=`echo $PACKAGE_VERSION |cut -d. -f2 | sed -e "s/^0-9//g"`
@@ -31630,7 +31630,7 @@
 # report actual input values of CONFIG_FILES etc. instead of their
 # values after options handling.
 ac_log="
-This file was extended by ClamAV $as_me 0.102.2, which was
+This file was extended by ClamAV $as_me 0.102.3, which was
 generated by GNU Autoconf 2.69.  Invocation command line was
 
   CONFIG_FILES= $CONFIG_FILES
@@ -31697,7 +31697,7 @@
 cat >>$CONFIG_STATUS <<_ACEOF || ac_write_fail=1
 ac_cs_config="`$as_echo "$ac_configure_args" | sed 's/^ //; s/[\\""\`\$]/&/g'`"
 ac_cs_version="\\
-ClamAV config.status 0.102.2
+ClamAV config.status 0.102.3
 configured by $0, generated by GNU Autoconf 2.69,
   with options \\"\$ac_cs_config\\"
 
@@ -34548,7 +34548,7 @@
 # report actual input values of CONFIG_FILES etc. instead of their
 # values after options handling.
 ac_log="
-This file was extended by ClamAV $as_me 0.102.2, which was
+This file was extended by ClamAV $as_me 0.102.3, which was
 generated by GNU Autoconf 2.69.  Invocation command line was
 
   CONFIG_FILES= $CONFIG_FILES
@@ -34615,7 +34615,7 @@
 cat >>$CONFIG_STATUS <<_ACEOF || ac_write_fail=1
 ac_cs_config="`$as_echo "$ac_configure_args" | sed 's/^ //; s/[\\""\`\$]/&/g'`"
 ac_cs_version="\\
-ClamAV config.status 0.102.2
+ClamAV 

Bug#961399: seaview: autopkgtest regression: gzip: *.gz: No such file or directory

[Nilesh Patra]

On Sun, 24 May 2020, 19:06 Andreas Tille,  wrote:

> On Sun, May 24, 2020 at 08:02:56AM +0200, Paul Gevers wrote:
> > gzip: *.gz: No such file or directory
>
> I've fixed this one but the test has changed and seems to require a
> running X server.  Either this can be changed via command line options
> or by using xvfb-run to provide some X server.
>

That's a nice idea indeed!

I tried implementing this, and modifying the tests in a way that made sense
to me.
Could you please have a look at this, and let me know if this is OK?

Kind regards
Nilesh

>

Bug#961438: grcompiler FTBFS on i386: compare_PigLatinTest_v2 failed

[Adrian Bunk]

Source: grcompiler
Version: 5.2-1
Severity: serious
Tags: ftbfs

https://buildd.debian.org/status/fetch.php?pkg=grcompiler=i386=5.2-1=1590331683=0

...
  Start  9: compare_PigLatinTest_v2
 4/15 Test  #9: compare_PigLatinTest_v2 .***Failed0.01 sec
Files "PigLatinTest_v2.ttf" to 
"/<>/test/GrcRegressionTest/fonts/PigLatinBenchmark_v2.ttf" are 
different.
...
93% tests passed, 1 tests failed out of 15

Total Test time (real) =   3.91 sec

The following tests FAILED:
  9 - compare_PigLatinTest_v2 (Failed)
Errors while running CTest
make[1]: *** [Makefile:121: test] Error 8



Something corrupts "RegTestV2-Regular" to "ReTesstV2Regullar":

@@ -1413,9 +1413,9 @@
 Offset: 670
 00 50 00 69 00 67 00 4c 00 61  >  .P.i.g.L.a
 00 74 00 69 00 6e 00 47 00 72  >  .t.i.n.G.r
-00 52 00 65 00 67 00 54 00 65  >  .R.e.g.T.e
-00 73 00 74 00 56 00 32 00 2d  >  .s.t.V.2.-
-00 52 00 65 00 67 00 75 00 6c  >  .R.e.g.u.l
+00 52 00 65 00 54 00 65 00 73  >  .R.e.T.e.s
+00 73 00 74 00 56 00 32 00 52  >  .s.t.V.2.R
+00 65 00 67 00 75 00 6c 00 6c  >  .e.g.u.l.l
 00 61 00 72> .a.r
 Name table   7. PlatformID: 0
 EncodingID: 0
@@ -1512,8 +1512,8 @@
 Length: 27
 Offset: 1059
 50 69 67 4c 61 74 69 6e 47 72  >  PigLatinGr
-52 65 67 54 65 73 74 56 32 2d  >  RegTestV2-
-52 65 67 75 6c 61 72   > Regular
+52 65 54 65 73 73 74 56 32 52  >  ReTesstV2R
+65 67 75 6c 6c 61 72   > egullar
 Name table  16. PlatformID: 1
 EncodingID: 0
 LanguageID: 0
@@ -1643,9 +1643,9 @@
 Offset: 1756
 00 50 00 69 00 67 00 4c 00 61  >  .P.i.g.L.a
 00 74 00 69 00 6e 00 47 00 72  >  .t.i.n.G.r
-00 52 00 65 00 67 00 54 00 65  >  .R.e.g.T.e
-00 73 00 74 00 56 00 32 00 2d  >  .s.t.V.2.-
-00 52 00 65 00 67 00 75 00 6c  >  .R.e.g.u.l
+00 52 00 65 00 54 00 65 00 73  >  .R.e.T.e.s
+00 73 00 74 00 56 00 32 00 52  >  .s.t.V.2.R
+00 65 00 67 00 75 00 6c 00 6c  >  .e.g.u.l.l
 00 61 00 72> .a.r
 Name table  25. PlatformID: 3
 EncodingID: 1

Bug#953537: unable to open '/sbin/xfsdump.dpkg-new': No such file or directory

[Lampshade]

Sorry for badly formatted last message. Webmail messed things up.

I get this error trying to upgrade package:
dpkg: error processing archive 
/var/cache/apt/archives/xfsdump_3.1.9_amd64.deb (--unpack):

 unable to open '/sbin/xfsdump.dpkg-new': No such file or directory


~# ls -l /bin /sbin
lrwxrwxrwx 1 root root 7 lis 30  2018 /bin -> usr/bin
lrwxrwxrwx 1 root root 8 lis 30  2018 /sbin -> usr/sbin

~# readlink /bin /sbin
usr/bin
usr/sbin

~# LANGUAGE="en" LANG="en_US.UTF-8"  apt-cache policy usrmerge
usrmerge:
  Installed: (none)
  Candidate: 23
  Version table:
 23 502
502 http://ftp.icm.edu.pl/pub/Linux/debian sid/main amd64 Packages
502 http://ftp.icm.edu.pl/pub/Linux/debian sid/main i386 Packages

~# LANGUAGE="en" LANG="en_US.UTF-8"  apt-cache policy xfsdump
xfsdump:
  Installed: 3.1.6+nmu2+b2
  Candidate: 3.1.9
  Version table:
 3.1.9 502
502 http://ftp.icm.edu.pl/pub/Linux/debian sid/main amd64 Packages
 *** 3.1.6+nmu2+b2 100
100 /var/lib/dpkg/status

~# LANGUAGE="en" LANG="en_US.UTF-8" apt-get --reinstall install xfsdump
Reading package lists... Done
Building dependency tree
Reading state information... Done
Suggested packages:
  acl attr quota
The following packages will be upgraded:
  xfsdump
1 upgraded, 0 newly installed, 0 to remove and 196 not upgraded.
Need to get 0 B/254 kB of archives.
After this operation, 19.5 kB of additional disk space will be used.
Retrieving bug reports... Done
Parsing Found/Fixed information... Done
grave bugs of xfsdump (3.1.6+nmu2+b2 → 3.1.9) 
 b1 - #953537 - xfsdump_3.1.9: Fails to install with usrmerge
Summary:
 xfsdump(1 bug)
Are you sure you want to install/upgrade the above packages? [Y/n/?/...] y
(Reading database ... 164656 files and directories currently installed.)
Preparing to unpack .../xfsdump_3.1.9_amd64.deb ...
Unpacking xfsdump (3.1.9) over (3.1.6+nmu2+b2) ...
dpkg: error processing archive 
/var/cache/apt/archives/xfsdump_3.1.9_amd64.deb (--unpack):

 unable to open '/sbin/xfsdump.dpkg-new': No such file or directory
Errors were encountered while processing:
 /var/cache/apt/archives/xfsdump_3.1.9_amd64.deb
E: Sub-process /usr/bin/dpkg returned an error code (1)

Bug#961437: kstars: Several icons are empty

[Ramiro Aceves]

Subject: kstars: Several icons are empty
Package: kstars
Version: 5:3.0.0-1
Severity: important

Dear Maintainer,


Some icons were empty in kstars running "xplanet" or "solar system". I 
am using XFCE desktop.


I found that installing breeze-icon-theme package fixed the problem.

Many thanks.
Regards.
Ramiro.



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

Kernel: Linux 4.19.0-9-amd64 (SMP w/8 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=es_ES.UTF-8, LC_CTYPE=es_ES.UTF-8 (charmap=UTF-8), 
LANGUAGE=es_ES.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 kstars depends on:
ii  kio   5.54.1-1
ii  kstars-data   5:3.0.0-1
ii  libc6 2.28-10
ii  libcfitsio7   3.450-3
ii  libgcc1   1:8.3.0-6
ii  libgsl23  2.5+dfsg-6
ii  libkf5configcore5 5.54.0-1+deb10u1
ii  libkf5configgui5  5.54.0-1+deb10u1
ii  libkf5configwidgets5  5.54.0-1
ii  libkf5coreaddons5 5.54.0-1
ii  libkf5crash5  5.54.0-1
ii  libkf5i18n5   5.54.0-1
ii  libkf5kiocore55.54.1-1
ii  libkf5kiowidgets5 5.54.1-1
ii  libkf5newstuff5   5.54.0-2
ii  libkf5notifications5  5.54.0-1
ii  libkf5notifyconfig5   5.54.0-1
ii  libkf5plotting5   5.54.0-1
ii  libkf5widgetsaddons5  5.54.0-1
ii  libkf5xmlgui5 5.54.0-1
ii  libqt5concurrent5 5.11.3+dfsg1-1+deb10u3
ii  libqt5core5a  5.11.3+dfsg1-1+deb10u3
ii  libqt5dbus5   5.11.3+dfsg1-1+deb10u3
ii  libqt5gui55.11.3+dfsg1-1+deb10u3
ii  libqt5keychain1   0.9.1-2
ii  libqt5network55.11.3+dfsg1-1+deb10u3
ii  libqt5printsupport5   5.11.3+dfsg1-1+deb10u3
ii  libqt5qml55.11.3-4
ii  libqt5quick5  5.11.3-4
ii  libqt5sql55.11.3+dfsg1-1+deb10u3
ii  libqt5sql5-sqlite 5.11.3+dfsg1-1+deb10u3
ii  libqt5svg55.11.3-2
ii  libqt5websockets5 5.11.3-5
ii  libqt5widgets55.11.3+dfsg1-1+deb10u3
ii  libraw19  0.19.2-2
ii  libstdc++68.3.0-6
ii  libwcs6   6.2-2
ii  zlib1g1:1.2.11.dfsg-1

Versions of packages kstars recommends:
ii  astrometry.net  0.76+dfsg-3
ii  indi-bin1.7.5+dfsg-1
ii  xplanet 1.3.0-5.1

Versions of packages kstars suggests:
pn  khelpcenter  
ii  konqueror4:18.12.0-1

-- no debconf information

Bug#961436: wrong project

[Jens Korte]

I am sorry, I sent this to the wrong project.

Bug#961436: installer: mount options missing

[Jens Korte]

Package: installer
Version: 3.0.0RC

The mount options selectable in the installer of
devuan_beowulf_3.0.0_RC_netinstall-i386 lacks (btrfs) options like
* compress[=lzo|zlib|zstd]
* autodefrag
* lazytime
* a line for entering additional options

Bug#961435: ITP: ggtags -- improved Emacs interface to GNU GLOBAL

[Sean Whitton]

Package: wnpp
Severity: wishlist
Owner: Sean Whitton 

* Package name: ggtags
  Version : 0.8.13
  Upstream Author : Leo Liu 
* URL : https://github.com/leoliu/ggtags
* License : GPL-3+
  Programming Lang: Emacs Lisp
  Description : improved Emacs interface to GNU GLOBAL

GNU GLOBAL comes with gtags.el, but ggtags.el is a fair bit easier to
use.  It can automatically invoke gtags(1) for you, and its default
keybindings are more intuitive, at least for me.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#961301: util-linux: column from util-linux is not available at runtime

[jules . sam . randolph]

Hi Chris,

Thank you for the follow up.

Bellow is a quick compatibility analysis from man pages [1][2]. Two flags,
-n and -e are not compatible. The first, because it is a Debian extension,
the second, because util-linux has not implemented it and replaced its meaning.

╔╤═══╤══╤╗
║│ bsdmainutils  │ util-linux   │ Analysis   ║
╠╪═══╪══╪╣
║ -c │ Output is formatted for a │ Output is formatted  │ OK ║
║│ display columns wide. │ to a width specified │║
║│   │ as number of │║
║│   │ characters. The original │║
║│   │ name of this option is   │║
║│   │ --columns; this name │║
║│   │ is deprecated since  │║
║│   │ v2.30. Note that input   │║
║│   │ longer than width is not │║
║│   │ truncated by default.│║
╟┼───┼──┼╢
║ -s │ Specify a set of  │ Specify the possible │ OK ║
║│ characters to be used to  │ input item delimiters│║
║│ delimit columns for the   │ (default is whitespace). │║
║│ -t option.│  │║
╟┼───┼──┼╢
║ -t │ Determine the number  │ Determine the number │ OK ║
║│ of columns the input  │ of columns the input │║
║│ contains and create   │ contains and create  │║
║│ a table. Columns  │ a table.  Columns│║
║│ are delimited with│ are delimited with   │║
║│ whitespace, by default,   │ whitespace, by default,  │║
║│ or with the characters│ or with the characters   │║
║│ supplied using the│ supplied using the   │║
║│ -s option. Useful │ --output-separator   │║
║│ for pretty-printing   │ option.  Table output│║
║│ displays. │ is useful for│║
║│   │ pretty-printing. │║
╟┼───┼──┼╢
║ -x │ Fill columns before   │ Fill rows before filling │ OK [3] ║
║│ filling rows. │ columns. │║
╟┼───┼──┼╢
║ -n │ By default, the column│ Specify the table│ Not OK ║
║│ command will merge│ name used for JSON   │║
║│ multiple adjacent │ output. The default is   │║
║│ delimiters into a single  │ "table". │║
║│ delimiter when using  │  │║
║│ the -t option; this   │  │║
║│ option disables that  │  │║
║│ behavior. This option │  │║
║│ is a Debian GNU/Linux │  │║
║│ extension.│  │║
╟┼───┼──┼╢
║ -e │ Do not ignore empty   │ Print header line for│ Not OK [4] ║
║│ lines.│ each page.   │║
╚╧═══╧══╧╝

[1] (bsdmainutils) https://manned.org/column/58858679
[2] (util-linux)   https://manned.org/column/256d2d15
[3] BSD manual page is misleading, see:
https://github.com/karelzak/util-linux/pull/758
[4] util-linux version has no option to ignore empty lines

Bug#961434: baresip-core: stack smashing detected with evdev module

[Alexander Inyukhin]

Package: baresip-core
Version: 0.6.1-1
Severity: normal



-- System Information:
Debian Release: 10.4
  APT prefers stable
  APT policy: (185, 'stable'), (183, 'stable-updates'), (175, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.6.0-1-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.UTF-8 (charmap=UTF-8), 
LANGUAGE=ru_RU:en_US (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)
LSM: AppArmor: enabled

Versions of packages baresip-core depends on:
ii  libasound21.1.8-1
ii  libavahi-client3  0.7-4+b1
ii  libavahi-common3  0.7-4+b1
ii  libc6 2.30-4
ii  libcodec2-0.8.1   0.8.1-2
ii  libdirectfb-1.7-7 1.7.7-9
ii  libgsm1   1.0.18-2
ii  libjack-jackd2-0 [libjack-0.125]  1.9.12~dfsg-2
ii  libmosquitto1 1.5.7-1+deb10u1
ii  libmpg123-0   1.25.10-2
ii  libopencore-amrnb00.1.3-2.1+b2
ii  libopencore-amrwb00.1.3-2.1+b2
ii  libopus0  1.3-1
ii  libpng16-16   1.6.36-6
ii  libportaudio2 19.6.0-1
ii  libre00.6.0-2
ii  librem0   0.6.0-1
ii  libsndfile1   1.0.28-6
ii  libsndio7.0   1.5.0-3
ii  libspandsp2   0.0.6+dfsg-2
ii  libspeexdsp1  1.2~rc1.2-1+b2
ii  libssl1.1 1.1.1d-0+deb10u3
ii  libtwolame0   0.3.13-4
ii  libvo-amrwbenc0   0.1.3-1+b1
ii  libvpx5   1.7.0-3+deb10u1
ii  zlib1g1:1.2.11.dfsg-1

Versions of packages baresip-core recommends:
pn  avahi-daemon  

Versions of packages baresip-core suggests:
ii  baresip-ffmpeg 0.6.1-1
pn  baresip-gstreamer  
ii  baresip-gtk0.6.1-1
pn  baresip-x11

-- no debconf information