Bug#943924: pandas2?

2019-11-10 Thread Rebecca N. Palmer

Matthias disagrees:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=942106#73

It should be technically straightforward to make a pandas2 package 
(start from the debian-v023 branch and drop the python2 part), but you'd 
have to upload it because DMs can't upload NEW packages.


(Only pandas would need to be split - our current statsmodels version 
still can support Python 2.)




Bug#944513: opendkim: Signing via TCP socket works, unix socket fails with SSL error

2019-11-10 Thread Cameron L Spitzer
Package: opendkim
Version: 2.11.0~alpha-12
Severity: normal

Dear Maintainer,

I'm using opendkim to sign outbound messages in Postfix.
My previous installation used a TCP socket, that configuration still
works.   According to Debian Wiki and upstream, we should use a unix
socket now, not TCP.   Postfix is in a chroot at /var/spool/postfix.

I switched the socket, as advised, to
local:/var/spool/postfix/var/run/opendkim/opendkim.sock
in /etc/opendkim.conf and gave
smtpd_milters = unix:/var/run/opendkim/opendkim.sock
non_smtpd_milters = unix:/var/run/opendkim/opendkim.sock
in /etc/postfix/main.cf.

After restarting postfix and opendkim, signing outbound messages fails.
The postfix submission process returns an error to the client.
The error message in /var/log/mail.info is
Nov 10 20:47:03 seed10 opendkim[24709]: 120F6205B0: SSL error:0D06B08E:asn1 
encoding routines:asn1_d2i_read_bio:not enough data
Nov 10 20:47:03 seed10 opendkim[24709]: 120F6205B0: dkim_eom(): resource 
unavailable: d2i_PrivateKey_bio() failed

I expected a localhost:TCP socket and a unix socket would behave the
same.   It looks as if SSL is not receiving all the information
it needs from opendkim.

I worked around the failure by reverting the socket change.


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

Kernel: Linux 4.19.0-6-cloud-amd64 (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 opendkim depends on:
ii  adduser3.118
ii  dns-root-data  2019031302
ii  libbsd00.9.1-2
ii  libc6  2.28-10
ii  libdb5.3   5.3.28+dfsg1-0.5
ii  libldap-2.4-2  2.4.47+dfsg-3+deb10u1
ii  liblua5.1-05.1.5-8.1+b2
ii  libmemcached11 1.0.18-4.2
ii  libmemcachedutil2  1.0.18-4.2
ii  libmilter1.0.1 8.15.2-14~deb10u1
ii  libopendbx11.4.6-13+b1
ii  libopendkim11  2.11.0~alpha-12
ii  librbl12.11.0~alpha-12
ii  libssl1.1  1.1.1d-0+deb10u2
ii  libunbound81.9.0-2+deb10u1
ii  libvbr22.11.0~alpha-12
ii  lsb-base   10.2019051400

opendkim recommends no packages.

Versions of packages opendkim suggests:
ii  opendkim-tools  2.11.0~alpha-12
pn  unbound 

-- Configuration Files:
/etc/default/opendkim changed:
RUNDIR=/var/spool/postfix/var/run/opendkim
SOCKET=local:$RUNDIR/opendkim.sock
USER=opendkim
GROUP=opendkim
PIDFILE=$RUNDIR/$NAME.pid
EXTRAAFTER=

/etc/dkimkeys/README.PrivateKeys [Errno 13] Permission denied: 
'/etc/dkimkeys/README.PrivateKeys'
/etc/opendkim.conf changed:
Syslog  yes
UMask   007
KeyFile /etc/dkimkeys/truffula.private
Domain  truffula.us
Selectormail
Socket  inet:12301@localhost
PidFile   /run/opendkim/opendkim.pid
OversignHeaders From
TrustAnchorFile   /usr/share/dns/root.key
UserIDopendkim


-- no debconf information



Bug#937867: python-kaptan: diff for NMU version 0.5.10-1.1

2019-11-10 Thread Ondřej Nový
Control: tags 937867 + patch
Control: tags 937867 + pending


Dear maintainer,

I've prepared an NMU for python-kaptan (versioned as 0.5.10-1.1) and
uploaded it to DELAYED/5. Please feel free to tell me if I
should delay it longer.

Regards.

diff -Nru python-kaptan-0.5.10/debian/control 
python-kaptan-0.5.10/debian/control
--- python-kaptan-0.5.10/debian/control 2018-08-04 08:09:11.0 +0200
+++ python-kaptan-0.5.10/debian/control 2019-11-11 08:01:01.0 +0100
@@ -2,20 +2,12 @@
 Maintainer: Sebastien Delafond 
 Section: python
 Priority: optional
-Build-Depends: dh-python, python-setuptools, python3-setuptools, python-all, 
python3-all, python-yaml, python3-yaml, debhelper (>= 9)
+Build-Depends: dh-python, python3-setuptools, python3-all, python3-yaml, 
debhelper (>= 9)
 Standards-Version: 4.1.3
 Homepage: https://github.com/emre/kaptan
 Vcs-Git: https://salsa.debian.org/debian/python-kaptan.git
 Vcs-Browser: https://salsa.debian.org/debian/python-kaptan
 
-Package: python-kaptan
-Architecture: all
-Depends: ${misc:Depends}, ${python:Depends}
-Description: Python configuration manager in various formats
- Configuration manager that allows users to transparently access
- configuration data stored in various formats (INI, JSON, YAML, dict,
- file).
-
 Package: python3-kaptan
 Architecture: all
 Depends: ${misc:Depends}, ${python3:Depends}
diff -Nru python-kaptan-0.5.10/debian/changelog 
python-kaptan-0.5.10/debian/changelog
--- python-kaptan-0.5.10/debian/changelog   2018-08-04 08:09:11.0 
+0200
+++ python-kaptan-0.5.10/debian/changelog   2019-11-11 08:01:17.0 
+0100
@@ -1,3 +1,10 @@
+python-kaptan (0.5.10-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Drop Python 2 support (Closes: #937867).
+
+ -- Ondřej Nový   Mon, 11 Nov 2019 08:01:17 +0100
+
 python-kaptan (0.5.10-1) unstable; urgency=medium
 
   * New upstream version 0.5.10
diff -Nru python-kaptan-0.5.10/debian/rules python-kaptan-0.5.10/debian/rules
--- python-kaptan-0.5.10/debian/rules   2018-08-04 08:09:11.0 +0200
+++ python-kaptan-0.5.10/debian/rules   2019-11-11 08:01:17.0 +0100
@@ -3,7 +3,5 @@
 # This file was automatically generated by stdeb 0.8.5 at
 # Sun, 01 Jan 2017 16:03:12 +0300
 export PYBUILD_NAME=kaptan
-export PYBUILD_AFTER_INSTALL_python2=rm -rf '{destdir}/usr/bin'
 %:
-   dh $@ --with python2,python3 --buildsystem=pybuild
-
+   dh $@ --with python3 --buildsystem=pybuild



Bug#937890: python-libtmux: diff for NMU version 0.8.0-1.1

2019-11-10 Thread Ondřej Nový
Control: tags 937890 + patch
Control: tags 937890 + pending


Dear maintainer,

I've prepared an NMU for python-libtmux (versioned as 0.8.0-1.1) and
uploaded it to DELAYED/5. Please feel free to tell me if I
should delay it longer.

Regards.

diff -Nru python-libtmux-0.8.0/debian/control 
python-libtmux-0.8.0/debian/control
--- python-libtmux-0.8.0/debian/control 2018-03-30 13:33:10.0 +0200
+++ python-libtmux-0.8.0/debian/control 2019-11-11 07:36:47.0 +0100
@@ -2,21 +2,12 @@
 Maintainer: Sebastien Delafond 
 Section: python
 Priority: optional
-Build-Depends: dh-python, python-setuptools, python3-setuptools, python-all, 
python3-all, debhelper (>= 9)
+Build-Depends: dh-python, python3-setuptools, python3-all, debhelper (>= 9)
 Standards-Version: 4.1.3
 Homepage: https://github.com/tony/libtmux/
 Vcs-Git: https://salsa.debian.org/debian/python-libtmux.git
 Vcs-Browser: https://salsa.debian.org/debian/python-libtmux
 
-Package: python-libtmux
-Architecture: all
-Depends: ${misc:Depends}, ${python:Depends}
-Description: Python scripting library and ORM for tmux
- libtmux is the tool behind tmuxp, a tmux workspace manager in python.
- .
- Builds upon tmux's target and formats to create an object mapping to
- traverse, inspect and interact with live tmux sessions.
-
 Package: python3-libtmux
 Architecture: all
 Depends: ${misc:Depends}, ${python3:Depends}
diff -Nru python-libtmux-0.8.0/debian/changelog 
python-libtmux-0.8.0/debian/changelog
--- python-libtmux-0.8.0/debian/changelog   2018-03-30 13:33:10.0 
+0200
+++ python-libtmux-0.8.0/debian/changelog   2019-11-11 07:38:38.0 
+0100
@@ -1,3 +1,10 @@
+python-libtmux (0.8.0-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Drop Python 2 support (Closes: #937890).
+
+ -- Ondřej Nový   Mon, 11 Nov 2019 07:38:38 +0100
+
 python-libtmux (0.8.0-1) unstable; urgency=medium
 
   * New upstream version 0.8.0
diff -Nru python-libtmux-0.8.0/debian/rules python-libtmux-0.8.0/debian/rules
--- python-libtmux-0.8.0/debian/rules   2018-03-30 13:33:10.0 +0200
+++ python-libtmux-0.8.0/debian/rules   2019-11-11 07:38:38.0 +0100
@@ -4,5 +4,4 @@
 # Sun, 01 Jan 2017 16:08:32 +0300
 export PYBUILD_NAME=libtmux
 %:
-   dh $@ --with python2,python3 --buildsystem=pybuild
-
+   dh $@ --with python3 --buildsystem=pybuild



Bug#916202: ITP: golang-github-mmarkdown-mmark -- Mmark: a powerful markdown processor in Go geared towards the IETF

2019-11-10 Thread Anthony Fok
Package: wnpp
Severity: wishlist
Owner: Anthony Fok 
X-Debbugs-CC: debian-de...@lists.debian.org, debian...@lists.debian.org

* Package name: golang-github-mmarkdown-mmark
  Version : 2.2.0-1
  Upstream Author : Miek Gieben
* URL : https://github.com/mmarkdown/mmark
* License : BSD-2-Clause
  Programming Lang: Go
  Description : Mmark: a powerful markdown processor in Go geared towards 
the IETF

Rationale: There has been interests to see Mmark v2.0.0 packaged.


signature.asc
Description: PGP signature


Bug#944512: duplicity: shouldn't be able to create a backup chain with two different passwords

2019-11-10 Thread Michael Terry
Package: duplicity
Version: 0.8.04-2ubuntu1
Severity: normal

Dear Maintainer,

Many years ago, duplicity had a bug that allowed you to resume a backup with a 
different
password than the one with which you started the backup. This left your backup 
chain
in an unrecoverable state, since duplicity doesn't know how to restore from a 
chain like
that.

It was fixed upstream. But the fix didn't properly handle using a gpg 
encryption key
(rather than a symmetric password). So Debian added the patch 01-reverify that 
disabled
the fix upstream.

But then duplicity fixed the issue with gpg encryption keys and Debian never 
dropped its
patch. Which left the original password-swap bug in place.

Can Debian drop 01-reverify please? I've attached two scripts that demonstrate 
each bug
and you can test that both work after dropping the patch.

You can run switchpass.sh to test the original password-swap bug. And run 
gpgkey.sh to
test the gpg encryption key issue (this one needs you to specify both KEY and 
PASSPHRASE
environment variables -- your gpg key id and passphrase respectively).

Both should report "Everything worked!" at the end if the bugs are fixed.
Or "Bug exists! :(" if the bug is present.

Upstream password-swap bug: https://bugs.launchpad.net/duplicity/+bug/878964
Upstream gpg-key bug: https://bugs.launchpad.net/duplicity/+bug/946988

Thanks!

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

Kernel: Linux 5.3.0-19-generic (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 duplicity depends on:
ii  gnupg  2.2.12-1ubuntu3
ii  gnupg1 1.4.23-1
ii  libc6  2.30-0ubuntu2
ii  librsync2  2.0.2-1ubuntu1
ii  python33.7.5-1
ii  python3-fasteners  0.12.0-5
ii  python3-future 0.16.0-1
ii  python3-lockfile   1:0.12.2-2ubuntu1

Versions of packages duplicity recommends:
ii  python3-oauthlib  2.1.0-1
ii  python3-paramiko  2.6.0-1
ii  python3-pexpect   4.6.0-1
ii  python3-urllib3   1.24.1-1ubuntu1
ii  rsync 3.1.3-6

Versions of packages duplicity suggests:
pn  lftp 
pn  ncftp
ii  par2 0.8.0-1
pn  python3-boto 
ii  python3-pip  18.1-5
pn  python3-swiftclient  
pn  tahoe-lafs   

-- no debconf information
#!/bin/sh

rm -rf /tmp/dupbadpass /tmp/dupbadrestore

echo "Making first, interrupted backup"
PASSPHRASE=testpass duplicity /usr/bin file:///tmp/dupbadpass --name dupbadpass 
--volsize 1 --fail-on-volume 2 --verbosity 1

echo "Finishing that backup with the wrong password"
PASSPHRASE=badpass duplicity /usr/bin file:///tmp/dupbadpass --name dupbadpass 
--volsize 1 --fail-on-volume 3 --verbosity 1

echo -n "Now, is vol1 encrypted with right pass?  "
if gpg --decrypt --passphrase testpass --pinentry-mode=loopback 
/tmp/dupbadpass/duplicity-full*.vol1.difftar.gpg >/dev/null 2>&1; then
  echo "Yes!"
else
  echo "Nope...? Something is deeply wrong"
fi

echo -n "And vol3 with the wrong one?  "
if [ -z "$(ls /tmp/dupbadpass/duplicity-full*.vol3.difftar.gpg 2>/dev/null)" ]; 
then
  echo "No vol3 exists"
  echo "Everything worked!"
elif gpg --decrypt --passphrase badpass --pinentry-mode=loopback 
/tmp/dupbadpass/duplicity-full*.vol3.difftar.gpg >/dev/null 2>&1; then
  echo "Yes!"
  echo "Bug exists! :("
else
  echo "Nope...? Something is deeply wrong"
fi


#!/bin/sh

killall gpg-agent
rm -rf ~/.cache/duplicity/dupbadpass /tmp/dupbadpass /tmp/dupbadrestore

echo "Making first, interrupted backup"
duplicity /usr/bin file:///tmp/dupbadpass --name dupbadpass --volsize 1 
--fail-on-volume 2 --encrypt-key $KEY

echo "Finishing that backup"
duplicity /usr/bin file:///tmp/dupbadpass --name dupbadpass --volsize 1 
--fail-on-volume 3 --encrypt-key $KEY

if [ -n "$(ls /tmp/dupbadpass/duplicity-full*.vol3.difftar.gpg 2>/dev/null)" ]; 
then
  echo "Everything worked!"
else
  echo "Bug exists! :("
fi



Bug#940902: doesn't read the data

2019-11-10 Thread Andreas Tille
On Sun, Nov 10, 2019 at 05:32:48PM +0100, Ana Guerrero Lopez wrote:
> > 
> > Welcome to the team, Andreas. 
> 
> Thanks!
> Good news, I've tested and it works fine. I'm doing a team upload right now.
> 
> I think we shouldn't give up in getting this ported to python3, but I think a
> re-write keeping the possibility to read the all data is the best way to go.

Thanks a lot for caring

Andreas.

-- 
http://fam-tille.de



Bug#944511: libgpg-error FTBFS when built with gawk

2019-11-10 Thread Helmut Grohne
Source: libgpg-error
Version: 1.36-7
Severity: important
Tags: ftbfs
User: helm...@debian.org
Usertags: rebootstrap

libgpg-error fails to build from source when built in a chroot that
happens to use gawk rather than mawk. This can happen as base-files
Pre-Depends on awk, which is a virtual package provided by both
implementations. It seems that currently the buildd chroots happen to
use mawk while the rebootstrap chroot happens to use gawk. To reproduce
the failure in sbuild, you can issue "sbuild -d sid --add-depends=gawk
libgpg-error".

| Making all in src
| make[4]: Entering directory '/<>/build/src'
| gawk -f ../../src/mkstrtable.awk -v textidx=3 \
| ../../src/err-sources.h.in >../../src/err-sources.h
| gawk: ../../src/mkstrtable.awk:113: warning: regexp escape sequence `\#' is 
not a known regexp operator
| gawk -f ../../src/mkstrtable.awk -v textidx=3 \
| ../../src/err-codes.h.in >../../src/err-codes.h
| gawk: ../../src/mkstrtable.awk:113: warning: regexp escape sequence `\#' is 
not a known regexp operator
| gawk -f ../../src/mkerrnos.awk ../../src/errnos.in >code-to-errno.h
| gawk: ../../src/mkerrnos.awk:86: warning: regexp escape sequence `\#' is not 
a known regexp operator
| gawk -f ../../src/mkerrcodes1.awk ../../src/errnos.in >_mkerrcodes.h
| gawk: ../../src/mkerrcodes1.awk:84: warning: regexp escape sequence `\#' is 
not a known regexp operator
| gcc -E -Wdate-time -D_FORTIFY_SOURCE=2  -P _mkerrcodes.h | grep GPG_ERR_ | \
|gawk -f ../../src/mkerrcodes.awk >mkerrcodes.h
| gawk: ../../src/mkerrcodes.awk:88: warning: regexp escape sequence `\#' is 
not a known regexp operator
| rm _mkerrcodes.h
| gcc -g -O2 -fdebug-prefix-map=/<>=. -fstack-protector-strong 
-Wformat -Werror=format-security -Wl,-z,relro -Wl,-z,now -I. -I../../src -o 
mkerrcodes ../../src/mkerrcodes.c
| ./mkerrcodes | gawk -f ../../src/mkerrcodes2.awk >code-from-errno.h
| gawk: ../../src/mkerrcodes2.awk:94: warning: regexp escape sequence `\#' is 
not a known regexp operator
| gawk -f ../../src/mkstrtable.awk -v textidx=2 -v nogettext=1 \
| ../../src/err-sources.h.in >err-sources-sym.h
| gawk: ../../src/mkstrtable.awk:113: warning: regexp escape sequence `\#' is 
not a known regexp operator
| gawk -f ../../src/mkstrtable.awk -v textidx=2 -v nogettext=1 \
| ../../src/err-codes.h.in >err-codes-sym.h
| gawk: ../../src/mkstrtable.awk:113: warning: regexp escape sequence `\#' is 
not a known regexp operator
| gawk -f ../../src/mkstrtable.awk -v textidx=2 -v nogettext=1 \
| -v prefix=GPG_ERR_ -v namespace=errnos_ \
| ../../src/errnos.in >errnos-sym.h
| gawk: fatal: cannot use gawk builtin `namespace' as variable name
| make[4]: *** [Makefile:1720: errnos-sym.h] Error 2
| make[4]: Leaving directory '/<>/build/src'
| make[3]: *** [Makefile:515: all-recursive] Error 1
| make[3]: Leaving directory '/<>/build'
| make[2]: *** [Makefile:447: all] Error 2
| make[2]: Leaving directory '/<>/build'
| dh_auto_build: cd build && make -j1 returned exit code 2
| make[1]: *** [debian/rules:19: override_dh_auto_build-arch] Error 255
| make[1]: Leaving directory '/<>'
| make: *** [debian/rules:8: binary] Error 2
| dpkg-buildpackage: error: debian/rules binary subprocess returned exit status 
2

When available, libgpg-error specifically selects and prefers gawk and
fails.

I think this is where you need "Build-Conflicts: gawk" or make it work.
Renaming the relevant variable should be relatively easy and might even
be fixed upstream though.

No particular urgency attached as it is trivial to work around.

Helmut



Bug#944510: deja-dup: Cannot back up to Google Drive (no pydrive packaged)

2019-11-10 Thread Michael Terry
Package: deja-dup
Version: 40.1-4
Severity: normal

Dear Maintainer,

I'm the upstream maintainer of deja-dup. I noticed that due to the absence of
pydrive in Debian (RFP: https://bugs.debian.org/922076), deja-dup's default
backend (Google Drive) does not work at all.

Ideally, pydrive would be packaged and -Dpydrive_pkgs=python3-pydrive would be
specified. But until that happens, I'd appreciate Google Drive being disabled.

Better to not provide a broken option (especially a default!). Less bug reports
for me, anyway.

I've attached a patch to do disable it from the UI.


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

Kernel: Linux 5.3.0-19-generic (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 deja-dup depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.34.0-1
ii  duplicity0.8.04-2ubuntu1
ii  libatk1.0-0  2.34.0-1
ii  libc62.30-0ubuntu2
ii  libglib2.0-0 2.62.1-1
ii  libgoa-1.0-0b3.34.0-1ubuntu1
ii  libgpg-error01.36-7
ii  libgtk-3-0   3.24.12-1ubuntu1
ii  libjson-glib-1.0-0   1.4.4-2
ii  libnautilus-extension1a  1:3.34.1-1ubuntu1
ii  libpackagekit-glib2-18   1.1.12-5ubuntu4
ii  libpango-1.0-0   1.42.4-7
ii  libsecret-1-00.18.8-2
ii  libsoup2.4-1 2.68.2-0ubuntu1

Versions of packages deja-dup recommends:
ii  gvfs-backends  1.42.1-1ubuntu1
ii  packagekit 1.1.12-5ubuntu4
ii  policykit-10.105-26ubuntu1

Versions of packages deja-dup suggests:
pn  python3-boto 
pn  python3-cloudfiles   
pn  python3-swiftclient  
diff --git a/deja-dup/widgets/ConfigLocation.vala 
b/deja-dup/widgets/ConfigLocation.vala
index a3313af9..ff67cba8 100644
--- a/deja-dup/widgets/ConfigLocation.vala
+++ b/deja-dup/widgets/ConfigLocation.vala
@@ -192,7 +192,7 @@ public class ConfigLocation : ConfigWidget
  new ConfigLocationS3(label_sizes, all_settings[S3_ROOT])) 
|
 insert_cloud("gcs", _("Google Cloud Storage"), show_deprecated, 
"deja-dup-cloud",
  new ConfigLocationGCS(label_sizes, 
all_settings[GCS_ROOT])) |
-insert_cloud("google", _("Google Drive"), true, 
"deja-dup-google-drive",
+insert_cloud("google", _("Google Drive"), false, 
"deja-dup-google-drive",
  new ConfigLocationGoogle(label_sizes, 
all_settings[GOOGLE_ROOT])) |
 insert_cloud("rackspace", _("Rackspace Cloud Files"), show_deprecated, 
"deja-dup-cloud",
  new ConfigLocationRackspace(label_sizes, 
all_settings[RACKSPACE_ROOT])) |
diff --git a/libdeja/BackendAuto.vala b/libdeja/BackendAuto.vala
index 588622a0..e15e2cb1 100644
--- a/libdeja/BackendAuto.vala
+++ b/libdeja/BackendAuto.vala
@@ -55,7 +55,7 @@ public class BackendAuto : Backend
 // 3) Google Drive via GNOME Online Accounts
 // 4) Google Drive (relying on packagekit support to install dependencies)
 var settings = get_settings();
-settings.set_string(BACKEND_KEY, "google");
+settings.set_string(BACKEND_KEY, "local");
   }
 }
 


Bug#944509: libportaudio2: random crashes in pa_linux_alsa.c: Assertion failed - fix available

2019-11-10 Thread Norbert Preining
Package: libportaudio2
Version: 19.6.0-1
Severity: important

Dear PA maintainers,

our RaspberryPi based smart speaker software started crashing with the
update to buster - the reason is not really clear, but pyaudio started
to crash with
python3: src/hostapi/alsa/pa_linux_alsa.c:3641: 
PaAlsaStreamComponent_BeginPolling: Assertion `ret == self->nfds' failed.
I could reproduce this bug 100% with our pyaudio based application on
arm, but I guess it might show up in other areas, too.

Fortunately, there is a patch posted to the portaudio mailing list
already back in July 2019 (but I only found it recently).

https://lists.columbia.edu/pipermail/portaudio/2019-July/001888.html

I rebuild the arm version of libportaudio2 locally and after installing
it on our system, with nothing else changed, the crashed went away.
(patch attached)

I have already contacted upstream mailing list to include the patch, but
the activity level of development there is rather low.

Could you be so nice and include this patch into the Debian sources,
ideally backporting/uploading it also to buster?

Thanks a lot and all the best

Norbert



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

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

Versions of packages libportaudio2 depends on:
ii  libasound21.1.9-1
ii  libc6 2.29-3
ii  libjack0 [libjack-0.125]  1:0.125.0-3+b1

libportaudio2 recommends no packages.

libportaudio2 suggests no packages.

-- no debconf information
diff --git a/src/hostapi/alsa/pa_linux_alsa.c b/src/hostapi/alsa/pa_linux_alsa.c
index 584cde8..643198c 100644
--- a/src/hostapi/alsa/pa_linux_alsa.c
+++ b/src/hostapi/alsa/pa_linux_alsa.c
@@ -3628,12 +3628,18 @@ error:
 
 /** Fill in pollfd objects.
  */
-static PaError PaAlsaStreamComponent_BeginPolling( PaAlsaStreamComponent* 
self, struct pollfd* pfds )
+static PaError PaAlsaStreamComponent_BeginPolling( PaAlsaStreamComponent* 
self, struct pollfd* pfds, int *xrunOccurred )
 {
 PaError result = paNoError;
 int ret = alsa_snd_pcm_poll_descriptors( self->pcm, pfds, self->nfds );
-(void)ret;  /* Prevent unused variable warning if asserts are turned off */
-assert( ret == self->nfds );
+if( -EPIPE == ret )
+{
+  *xrunOccurred = 1;
+}
+else
+{
+  assert( ret == self->nfds );
+}
 
 self->ready = 0;
 
@@ -3794,17 +3800,22 @@ static PaError PaAlsaStream_WaitForFrames( PaAlsaStream 
*self, unsigned long *fr
 if( pollCapture )
 {
 capturePfds = self->pfds;
-PA_ENSURE( PaAlsaStreamComponent_BeginPolling( >capture, 
capturePfds ) );
+PA_ENSURE( PaAlsaStreamComponent_BeginPolling( >capture, 
capturePfds,  ) );
 totalFds += self->capture.nfds;
 }
 if( pollPlayback )
 {
 /* self->pfds is in effect an array of fds; if necessary, index 
past the capture fds */
 playbackPfds = self->pfds + (pollCapture ? self->capture.nfds : 0);
-PA_ENSURE( PaAlsaStreamComponent_BeginPolling( >playback, 
playbackPfds ) );
+PA_ENSURE( PaAlsaStreamComponent_BeginPolling( >playback, 
playbackPfds,  ) );
 totalFds += self->playback.nfds;
 }
 
+if ( xrun )
+{
+  break;
+}
+
 #ifdef PTHREAD_CANCELED
 if( self->callbackMode )
 {

Bug#944508: RFS: vtun/3.0.4-2 -- virtual tunnel over TCP/IP networks

2019-11-10 Thread Rodrigo Carvalho
Package: sponsorship-requests
Severity: normal

Dear mentors,

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

 * Package name: vtun
   Version : 3.0.4-2
   Upstream Author : Maxim Krasnyansky 
 * URL : http://vtun.sourceforge.net/
 * License : GPL-2+
 * Vcs : None
   Section : net

It builds those binary packages:

  vtun - virtual tunnel over TCP/IP networks

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

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

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

  dget -x https://mentors.debian.net/debian/pool/main/v/vtun/vtun_3.0.4-2.dsc

Changes since the last upload:

   * Fix HAVE_WORKING_FORK configure check. Patch by Sylvain Rochet.
 (Closes: #943436).

Regards,

--
  Rodrigo Carvalho



Bug#762266: glib-2.0 GDateTime locale tests

2019-11-10 Thread Changwoo Ryu
The test code needs to be corrected: setlocale() is required before
calling POSIX locale-aware functions.

--- glibtestold.c2019-11-11 11:27:21.489271420 +0900
+++ glibtest.c2019-11-11 11:27:09.737139535 +0900
@@ -1,3 +1,4 @@
+#include 
 #include 
 #include 

@@ -6,6 +7,8 @@
 gchar *time;
 gchar *date;
 gchar *str;
+
+setlocale(LC_ALL, "");

 datetime=g_date_time_new_now_local();
 time=g_date_time_format(datetime, "%X");

After this changes,

$ env LANG=th_TH ./glibtest
11:24:34
(null)
$

"(null)" matches the original bug report. No idea which part of glib
and/or th_TH locale make this wrong result.



Bug#944506: gnome-shell-extension-show-ip: Show the primary IP address when no interface was chosen

2019-11-10 Thread Paul Wise
Package: gnome-shell-extension-show-ip
Version: 8-3
Severity: wishlist
Forwarded: https://github.com/sgaraud/gnome-extension-show-ip/pull/19

Please apply the attached patch from upstream pull request #19 to
show the primary IP address when no interface was chosen.

-- System Information:
Debian Release: bullseye/sid
  APT prefers testing-debug
  APT policy: (900, 'testing-debug'), (900, 'testing'), (800, 
'unstable-debug'), (800, 'unstable'), (790, 'buildd-unstable'), (700, 
'experimental-debug'), (700, 'experimental'), (690, 'buildd-experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 5.3.0-2-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_FIRMWARE_WORKAROUND, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_AU.utf8, LC_CTYPE=en_AU.utf8 (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 gnome-shell-extension-show-ip depends on:
ii  gnome-shell  3.34.1+git20191024-1

gnome-shell-extension-show-ip recommends no packages.

gnome-shell-extension-show-ip suggests no packages.

-- no debconf information

-- 
bye,
pabs

https://wiki.debian.org/PaulWise
From 795e42e1b3c43ec81c4226a5db3fe31e00c2fc4a Mon Sep 17 00:00:00 2001
From: Paul Wise 
Date: Thu, 2 Mar 2017 18:07:14 +0800
Subject: [PATCH] Show the primary IP address when no interface was chosen

Makes it easier to see all IP addresses at a glance.

Uses NM to get which interface(s) are in the default route.
---
 README.md|  1 +
 extension.js | 53 +---
 2 files changed, 43 insertions(+), 11 deletions(-)

diff --git a/README.md b/README.md
index 0fafb7a..eec47e3 100644
--- a/README.md
+++ b/README.md
@@ -83,6 +83,7 @@ issues](https://github.com/sgaraud/gnome-extension-show-ip/issues).
 ### License
 
 Copyright (C) 2015 Sylvain Garaud
+Copyright 2017 Paul Wise
 
 This program is free software: you can redistribute it and/or modify
 it under the terms of the GNU General Public License as published by
diff --git a/extension.js b/extension.js
index d9a7940..d998737 100644
--- a/extension.js
+++ b/extension.js
@@ -3,6 +3,7 @@
  * https://github.com/sgaraud/gnome-extension-show-ip
  * 
  * Copyright (C) 2015 Sylvain Garaud
+ * Copyright 2017 Paul Wise
  *
  * This file is part of Show-IP GNOME extension.
  * Show IP GNOME extension is free software: you can redistribute it and/or modify
@@ -170,17 +171,30 @@ const IpMenuBase = new Lang.Class({
 }
 });
 
+this._getPrimaryDevices(this.client);
+let selectedIp = '';
+let primaryIp = '';
+let firstIp = '';
 for (let device of this._devices) {
-if (device.ifc == this.selectedDevice) {
-if (Schema.get_boolean("menu")) {
-this.label.set_text(_("IP: %s").format(device.ip));
-} else {
-this.label.set_text(device.ip);
-}
-break;
+if (!selectedIp && device.ifc == this.selectedDevice) {
+selectedIp = device.ip;
+}
+if (!primaryIp && device.primary) {
+primaryIp = device.ip;
+}
+if (!firstIp) {
+firstIp = device.ip;
 }
 }
-if ('' == this.selectedDevice) {
+let ip = selectedIp ? selectedIp : primaryIp ? primaryIp : firstIp;
+if (ip) {
+if (Schema.get_boolean("menu")) {
+this.label.set_text(_("IP: %s").format(device.ip));
+} else {
+this.label.set_text(device.ip);
+}
+this.label.set_text(device.ip);
+} else {
 this.label.set_text(NOT_CONNECTED);
 }
 },
@@ -207,6 +221,26 @@ const IpMenuBase = new Lang.Class({
 this._createPopupMenu();
 },
 
+_getPrimaryDevices: function (nmc) {
+let primary_conn = nmc.get_primary_connection();
+let primary_devices = primary_conn.get_devices();
+let primary_ifcs = [];
+let i = 0;
+if (primary_devices) {
+for (let device of primary_devices) {
+primary_ifcs[i++] = device.get_iface();
+}
+}
+for (let device of this._devices) {
+device.primary = false;
+for (let ifc of primary_ifcs) {
+if (device.ifc == ifc) {
+device.primary = true;
+}
+}
+}
+},
+
 _getNetworkDevices: function (nmc) {
 let _device;
 this.devices = nmc.get_devices();
@@ -290,9 +324,6 @@ const IpMenuBase = new Lang.Class({
 } else {
 device.ip = this._decodeIp4(ipadd);
 }
-if ('' == this.selectedDevice) {
-this.selectedDevice = device.ifc;
-}
 break;
 }

Bug#944507: gnome-shell-extension-show-ip: Show IP addresses on the interface selection list

2019-11-10 Thread Paul Wise
Package: gnome-shell-extension-show-ip
Version: 8-3
Severity: wishlist
Tags: patch upstream
Forwarded: https://github.com/sgaraud/gnome-extension-show-ip/pull/20

Please apply the attached patch from upstream pull request #20 to
show IP addresses on the interface selection list.

-- System Information:
Debian Release: bullseye/sid
  APT prefers testing-debug
  APT policy: (900, 'testing-debug'), (900, 'testing'), (800, 
'unstable-debug'), (800, 'unstable'), (790, 'buildd-unstable'), (700, 
'experimental-debug'), (700, 'experimental'), (690, 'buildd-experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 5.3.0-2-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_FIRMWARE_WORKAROUND, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_AU.utf8, LC_CTYPE=en_AU.utf8 (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 gnome-shell-extension-show-ip depends on:
ii  gnome-shell  3.34.1+git20191024-1

gnome-shell-extension-show-ip recommends no packages.

gnome-shell-extension-show-ip suggests no packages.

-- no debconf information

-- 
bye,
pabs

https://wiki.debian.org/PaulWise
From 14ab34cf53150bca946cd7a47b6bfbc486904c5c Mon Sep 17 00:00:00 2001
From: Paul Wise 
Date: Thu, 2 Mar 2017 17:36:33 +0800
Subject: [PATCH] Show IP addresses on the interface selection list

This is useful to get the full list of IPs at a glance.
---
 extension.js | 13 ++---
 1 file changed, 10 insertions(+), 3 deletions(-)

diff --git a/extension.js b/extension.js
index d9a7940..ae848c7 100644
--- a/extension.js
+++ b/extension.js
@@ -186,20 +186,27 @@ const IpMenuBase = new Lang.Class({
 },
 
 _addToPopupMenu: function (dev) {
-this.item = new PopupMenu.PopupMenuItem(dev);
+let text = dev + ' ';
+for (let device of this._devices) {
+if (device.ifc == dev) {
+text += device.ip;
+}
+}
+this.item = new PopupMenu.PopupMenuItem(text);
+this.item.ifc = dev;
 this.menu.addMenuItem(this.item);
 this._manualUpdateId = this.item.connect('activate', Lang.bind(this, this._manualUpdate));
 },
 
 _manualUpdate: function (it) {
 for (let device of this._devices) {
-if (device.ifc == it.label.get_text()) {
+if (device.ifc == it.ifc) {
 this.selectedDevice = device.ifc;
 Schema.set_string('last-device', device.ifc);
 break;
 }
 }
-if (PUBLIC_IP == it.label.get_text()) {
+if (PUBLIC_IP == it.ifc) {
 this.selectedDevice = PUBLIC_IP;
 Schema.set_string('last-device', PUBLIC_IP);
 }
-- 
2.24.0



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


Bug#944504: User-service tries to use /run instead of /run/user/$UID

2019-11-10 Thread Shengjing Zhu
Hi,

The use of /run is expected, as the socket is created by system scope
service anbox-container-manager.service.

Have you read the instructions in README.Debian?

You need some extra steps to make  anbox-container-manager.service work.

// send from my mobile device

martin f krafft  于 2019年11月11日周一 08:24写道:

> Package: anbox
> Version: 0.0~git20191022-1
> Severity: minor
>
> Trying to use the provided systemd user unit, anbox just dies with an
> error on startup:
>
> anbox: Failed to connect to socket /run/anbox-container.socket: No such
> file or directory
>
> This is probably because in per-user mode, it should be using
> /run/user/$UID instead of the 755 /run directory directly.
>
> -- 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.3.0-1-amd64 (SMP w/4 CPU cores)
> Kernel taint flags: TAINT_CRAP
> Locale: LANG=en_NZ, LC_CTYPE=en_NZ.UTF-8 (charmap=UTF-8),
> LANGUAGE=en_NZ:en (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
>
> Versions of packages anbox depends on:
> ii init-system-helpers 1.57
> ii iptables 1.8.3-2
> ii libboost-filesystem1.67.0 1.67.0-13
> ii libboost-iostreams1.67.0 1.67.0-13
> ii libboost-log1.67.0 1.67.0-13
> ii libboost-program-options1.67.0 1.67.0-13
> ii libboost-system1.67.0 1.67.0-13
> ii libboost-thread1.67.0 1.67.0-13
> ii libc6 2.29-3
> ii libegl1 1.1.0-1+b1
> ii libgcc1 1:9.2.1-16
> ii libgles2 1.1.0-1+b1
> ii liblxc1 1:3.1.0+really3.0.4-2
> ii libprotobuf-lite17 3.6.1.3-2
> ii libsdl2-2.0-0 2.0.10+dfsg1-1
> ii libsdl2-image-2.0-0 2.0.5+dfsg1-1
> ii libstdc++6 9.2.1-16
> ii libsystemd0 242-7
> ii lxc 1:3.1.0+really3.0.4-2
>
> Versions of packages anbox recommends:
> ii dbus-user-session 1.12.16-2
>
> anbox suggests no packages.
>
> -- no debconf information
> --
> .''`. martin f. krafft @martinkrafft
> : :' : proud Debian developer
> `. `'` http://people.debian.org/~madduck
> `- Debian - when you have better things to do than fixing systems
>


Bug#944505: FTBFS: E: Build killed with signal TERM after 150 minutes of inactivity

2019-11-10 Thread Adam Borowski
Source: fonts-beteckna
Version: 0.5-2
Severity: serious
Tags: ftbfs
Justification: fails to build from source

Hi!
I'm afraid that fonts-beteckna fails to build:
** (process:53089): WARNING **: 22:56:10.699: GlyfData.vala:407: Point on point 
in TTF. Index 50 Path: 1 in 9
E: Build killed with signal TERM after 150 minutes of inactivity

Same happens both on a fat amd64 and a low-end arm64.

Full log attached.


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

Kernel: Linux 5.4.0-rc6-00053-g729694c1a413 (SMP w/64 CPU cores)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)
sbuild (Debian sbuild) 0.78.1 (09 February 2019) on valinor.angband.pl

+==+
| fonts-beteckna (amd64)   Sun, 10 Nov 2019 22:55:49 + |
+==+

Package: fonts-beteckna
Distribution: unstable
Machine Architecture: amd64
Host Architecture: amd64
Build Architecture: amd64
Build Type: binary

I: NOTICE: Log filtering will replace 
'var/run/schroot/mount/unstable-amd64-sbuild-e7a44aad-019d-4522-ab69-da5957dbc7b3'
 with '<>'
I: NOTICE: Log filtering will replace 
'build/fonts-beteckna-5CJmIK/resolver-UgUo7l' with '<>'

+--+
| Update chroot|
+--+

Hit:1 http://apt-rosy.angband.pl:3142/debian unstable InRelease
Reading package lists...
Reading package lists...
Building dependency tree...
Reading state information...
Calculating upgrade...
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.

+--+
| Fetch source files   |
+--+


Check APT
-

Checking available source versions...

Download source files with APT
--

Reading package lists...
Need to get 2125 kB of source archives.
Get:1 http://apt-rosy.angband.pl:3142/debian unstable/main fonts-beteckna 0.5-2 
(dsc) [1884 B]
Get:2 http://apt-rosy.angband.pl:3142/debian unstable/main fonts-beteckna 0.5-2 
(tar) [2119 kB]
Get:3 http://apt-rosy.angband.pl:3142/debian unstable/main fonts-beteckna 0.5-2 
(diff) [3432 B]
Fetched 2125 kB in 0s (109 MB/s)
Download complete and in download only mode
I: NOTICE: Log filtering will replace 
'build/fonts-beteckna-5CJmIK/fonts-beteckna-0.5' with '<>'
I: NOTICE: Log filtering will replace 'build/fonts-beteckna-5CJmIK' with 
'<>'

+--+
| Install package build dependencies   |
+--+


Setup apt archive
-

Merged Build-Depends: debhelper (>= 11), birdfont, build-essential, fakeroot
Filtered Build-Depends: debhelper (>= 11), birdfont, build-essential, fakeroot
dpkg-deb: building package 'sbuild-build-depends-main-dummy' in 
'/<>/apt_archive/sbuild-build-depends-main-dummy.deb'.
Ign:1 copy:/<>/apt_archive ./ InRelease
Get:2 copy:/<>/apt_archive ./ Release [957 B]
Ign:3 copy:/<>/apt_archive ./ Release.gpg
Get:4 copy:/<>/apt_archive ./ Sources [373 B]
Get:5 copy:/<>/apt_archive ./ Packages [456 B]
Fetched 1786 B in 0s (161 kB/s)
Reading package lists...
Reading package lists...

Install main build dependencies (apt-based resolver)


Installing build dependencies
Reading package lists...
Building dependency tree...
Reading state information...
The following additional packages will be installed:
  adwaita-icon-theme birdfont bubblewrap dbus dbus-user-session
  dconf-gsettings-backend dconf-service dictionaries-common dmsetup
  emacsen-common fontconfig fontconfig-config fonts-dejavu-core
  fonts-roboto-unhinted glib-networking glib-networking-common
  glib-networking-services gsettings-desktop-schemas gtk-update-icon-cache
  hicolor-icon-theme hunspell-en-us iso-codes libapparmor1 libargon2-1
  libaspell15 libatk-bridge2.0-0 libatk1.0-0 libatk1.0-data libatspi2.0-0
  libavahi-client3 libavahi-common-data libavahi-common3 libbrotli1
  libcairo-gobject2 libcairo2 libcap2 libcap2-bin libcolord2 libcryptsetup12
  libcups2 libdatrie1 libdbus-1-3 libdconf1 libdevmapper1.02.1 libdrm-amdgpu1
  libdrm-common libdrm-intel1 libdrm-nouveau2 libdrm-radeon1 libdrm2 libedit2
  libegl-mesa0 libegl1 

Bug#944437: RFS: rpl/1.0-3 [QA] -- replace strings in files

2019-11-10 Thread Adam Borowski
On Sun, Nov 10, 2019 at 10:33:06PM +0100, Adam Borowski wrote:
> And the tool doesn't seem to work either:
> .
> [~/tmp/pkg/some-other-random-package/debian]$ rpl Package Pąckagę *
> 
> rpl: Replacing "Package" with "Pąckagę" (case sensitive; partial words 
> matched)

Alas, it looks like mutt fails to escape a lone dot (ie, SMTP terminator).

The output was:
.
| $ rpl Package Pąckagę *
| 
| rpl: Replacing "Package" with "Pąckagę" (case sensitive; partial words 
matched)
| .
| rpl: could not guess encoding; using locale default 'UTF-8'
| 
| rpl: Could not replace /tmp/.tmp.yl3o48fk with changelog; error: [Errno 18] 
Invalid cross-device link: '/tmp/.tmp.yl3o48fk' -> 'changelog'
| .
| rpl: Could not replace /tmp/.tmp.df0h2nph with control; error: [Errno 18] 
Invalid cross-device link: '/tmp/.tmp.df0h2nph' -> 'control'
| ..
| rpl: A total of 0 matches replaced in 8 files searched
`

-- 
⢀⣴⠾⠻⢶⣦⠀ A MAP07 (Dead Simple) raspberry tincture recipe: 0.5l 95% alcohol,
⣾⠁⢠⠒⠀⣿⡁ 1kg raspberries, 0.4kg sugar; put into a big jar for 1 month.
⢿⡄⠘⠷⠚⠋⠀ Filter out and throw away the fruits (can dump them into a cake,
⠈⠳⣄ etc), let the drink age at least 3-6 months.



Bug#944504: User-service tries to use /run instead of /run/user/$UID

2019-11-10 Thread martin f krafft
Package: anbox
Version: 0.0~git20191022-1
Severity: minor

Trying to use the provided systemd user unit, anbox just dies with 
an error on startup:

  anbox: Failed to connect to socket /run/anbox-container.socket: No 
  such file or directory

This is probably because in per-user mode, it should be using 
/run/user/$UID instead of the 755 /run directory directly.

--
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.3.0-1-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_CRAP
Locale: LANG=en_NZ, LC_CTYPE=en_NZ.UTF-8 (charmap=UTF-8), LANGUAGE=en_NZ:en 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages anbox depends on:
ii  init-system-helpers 1.57
ii  iptables1.8.3-2
ii  libboost-filesystem1.67.0   1.67.0-13
ii  libboost-iostreams1.67.01.67.0-13
ii  libboost-log1.67.0  1.67.0-13
ii  libboost-program-options1.67.0  1.67.0-13
ii  libboost-system1.67.0   1.67.0-13
ii  libboost-thread1.67.0   1.67.0-13
ii  libc6   2.29-3
ii  libegl1 1.1.0-1+b1
ii  libgcc1 1:9.2.1-16
ii  libgles21.1.0-1+b1
ii  liblxc1 1:3.1.0+really3.0.4-2
ii  libprotobuf-lite17  3.6.1.3-2
ii  libsdl2-2.0-0   2.0.10+dfsg1-1
ii  libsdl2-image-2.0-0 2.0.5+dfsg1-1
ii  libstdc++6  9.2.1-16
ii  libsystemd0 242-7
ii  lxc 1:3.1.0+really3.0.4-2

Versions of packages anbox recommends:
ii  dbus-user-session  1.12.16-2

anbox suggests no packages.

--
no debconf information


-- 
 .''`.   martin f. krafft  @martinkrafft
: :'  :  proud Debian developer
`. `'`   http://people.debian.org/~madduck
  `-  Debian - when you have better things to do than fixing systems


digital_signature_gpg.asc
Description: Digital GPG signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)


Bug#893253: Is it still reproducible?

2019-11-10 Thread Changwoo Ryu
2019년 11월 10일 (일) 오후 7:06, 님이 작성:
>
> On 2019-11-09 11:19 Changwoo Ryu  wrote:
> > Is it still reproducible with recent versions of ibus and clients?
>
> My main problem with JabRef is gone. I can insert 日本語 without a
> problem.
>
> But "Anki" (current upstream and official-deb-repository version) still
> does not work. Do not understand why. Maybe this is a app specific
> problem.

Your problems don't seem to related with this bug #893253. Please post
to relevant bug or file a new bug if there isn't one.



Bug#938444: pymvpa2: Python2 removal in sid/bullseye

2019-11-10 Thread Matthias Klose

On 10.11.19 14:55, Rebecca N. Palmer wrote:

On 10/11/2019 13:45, Matthias Klose wrote:
I'm preparing a NMU for scikit-learn, based on the new subminor upstream 
release 0.20.3


I don't know why Ubuntu has 0.20.3 and Debian only .2, but it doesn't look 
related to either python3.8 or py2removal:

https://scikit-learn.org/0.20/whats_new.html#version-0-20-3


there's also a bug report requesting the update to 0.21.

The Ubuntu fix I was referring to is the explicit "Drop python2 support" i.e. 
https://launchpadlibrarian.net/438042402/scikit-learn_0.20.3+dfsg-0ubuntu1_0.20.3+dfsg-0ubuntu2.diff.gz 



(Probably the python-sklearn*.install files should have been removed as well?)


yes, that's what I had done for the NMU.



Bug#944190: release.debian.org: Allow britney to consider installability of dependencies of essential packages

2019-11-10 Thread Niels Thykier
Control: tags -1 confirmed patch

Niels Thykier:
> [...]
> 
> I looking forward to your test case as it will make this issue a lot
> easier to debug.
> 

Hi,

Thanks for the test case. :)

I have pushed it to britney2-tests and flagged it as a known failure.

> What is supposed to happen is that:
> 
>  * Britney "should" rewrite the relation on "libsystemd0" as
>"libsystemd0 | libelogin0" when building the BinaryPackageUniverse
>(actually as libsystemd0//arch | libsystemd0//arch
> tuples).
> 
>- This is also based on the assumption that the Conflicts/Provides
>  setup in libelogin0 is done correctly.  I /think/ it is - I am just
>  being explicit about the assumption.
> 

Indeed, I have looked through the state of the test and the relations
are as I expected here.

> [...]>  * It /could/ be related to the caching of the pseudo-essential set.
>AFAIUI, the cache should "just work(tm)" if the previous point
>does not have a flaw.  At least the current cache code assumes that
>libsystemd0 and libelogin0 will not be resolved by
>_get_min_pseudo_ess_set.  Though, it could also be a point where the
>bug hides.
> 
> [...]

I think this ends up being the winner.  The _get_min_pseudo_ess_set
method builds a set that includes libtest (libsystemd0) from the beginning.
  This is technically correct and valid at the start because libprovider
(libelogind0) is *not* in testing at that point (so any selection for
the essential set will always include libtest at the start).
Unfortunately, the cache is never invalidated by adding the alternative
and thus libprovider is immediately rejected as broken.

I have attached the following patch that passes the provided test and
(AFAICT) does what we want. Please feel free to review it; I will come
back to this in a few days.

Note: I do not expect to have a lot of spare time for Debian the coming
week; please ping me on this bug if I have not replied by next Sunday.

Thanks,
~Niels
From 0d5ea5eb8c0276e48f1394f233e1441ab87dcfbc Mon Sep 17 00:00:00 2001
From: Niels Thykier 
Date: Sun, 10 Nov 2019 23:08:47 +
Subject: [PATCH] Improve cache invalidation of (pseudo-)essential set

If a new pseudo-essential package was added to testing *and* it is
mutually-exclusive with an existing member, britney would incorrectly
flag it as uninstallable (unless another change triggered a cache
invalidation of the pseudo-essential set).

With this commit, the cache invalidation is now done based on whether
we add something that *might* be in the (effective) pseudo-essential
set.  It is an overapproximation as there are cases where the
invalidation is unnecessary, but at the moment it is not a performance
concern.

Closes: https://bugs.debian.org/944190
Signed-off-by: Niels Thykier 
---
 britney2/installability/tester.py | 12 
 britney2/utils.py | 21 -
 2 files changed, 28 insertions(+), 5 deletions(-)

diff --git a/britney2/installability/tester.py b/britney2/installability/tester.py
index 5ac6ef2..4687cc0 100644
--- a/britney2/installability/tester.py
+++ b/britney2/installability/tester.py
@@ -17,7 +17,7 @@ from functools import partial
 import logging
 from itertools import chain, filterfalse
 
-from britney2.utils import iter_except
+from britney2.utils import iter_except, add_transitive_dependencies_flatten
 
 
 class InstallabilityTester(object):
@@ -52,12 +52,16 @@ class InstallabilityTester(object):
 # are essential and packages that will always follow.
 #
 # It may not be a complete essential set, since alternatives
-# are not always resolved.  Noticably cases like "awk" may be
+# are not always resolved.  Noticeably cases like "awk" may be
 # left out (since it could be either gawk, mawk or
 # original-awk) unless something in this sets depends strictly
 # on one of them
 self._cache_ess = {}
 
+essential_w_transitive_deps = set(universe.essential_packages)
+add_transitive_dependencies_flatten(universe, essential_w_transitive_deps)
+self._cache_essential_transitive_dependencies = essential_w_transitive_deps
+
 def compute_installability(self):
 """Computes the installability of all the packages in the suite
 
@@ -137,8 +141,8 @@ class InstallabilityTester(object):
 # Re-add broken packages as some of them may now be installable
 self._suite_contents |= self._cache_broken
 self._cache_broken = set()
-if pkg_id in self._universe.essential_packages and pkg_id.architecture in self._cache_ess:
-# Adds new essential => "pseudo-essential" set needs to be
+if pkg_id in self._cache_essential_transitive_dependencies and pkg_id.architecture in self._cache_ess:
+# Adds new possibly pseudo-essential => "pseudo-essential" set needs to be
 # recomputed
 del 

Bug#944503: lshw: Can switch from pciutils and usbitils to pci.ids and usb.ids

2019-11-10 Thread Guillem Jover
Source: lshw
Source-Version: 02.18.85-0.3
Severity: normal

Hi!

The PCI and USB ID databases have been split into their own source and
binary packages so that they can be updated more regularly, and can be
depended on w/o having to pull in the tools. The Recommends could be
switched to a Depends (or be kept as Recommends if that's deemed too
strong) from to a pciutils to pci.ids and from usbutils to usb.ids.

Thanks,
Guillem



Bug#944485: mmdebstrap: please implement the creation of QEMU/KVM images for autopkgtest-virt-qemu

2019-11-10 Thread Francesco Poli
On Sun, 10 Nov 2019 23:17:04 +0100 Johannes Schauer wrote:

[...]
> Quoting Francesco Poli (wintermute) (2019-11-10 18:44:47)
[...]
> > Could this feature be implemented? It would really be awesome to have
> > a tool that allows a regular user to create a QEMU/KVM minimal Debian
> > image...
> 
> it does not need to be implemented because it is already possible.
[...]

Wow! Thanks for your super-prompt reply!   :-)
And above all, thanks for implementing this already!

I think I will look into mmdebstrap in more depth and then get back to
you to let you know how it went...


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


pgpm5UwU7X6lC.pgp
Description: PGP signature


Bug#298994: Investment Proposal

2019-11-10 Thread Nael M. Al Homoud
Good day,

My associate from China wants to discuss a business investment deal with
you. I awaiting your response to enable us discuss about this business
investment

Nael M. Al Homoud
Executive Director & High Investment Committee Member@
The Arab Investment Co
www.taic.com [1]

  

Links:
--
[1] http://www.taic.com

Bug#944502: libosinfo: Can switch from pciutils and usbitils to pci.ids and usb.ids

2019-11-10 Thread Guillem Jover
Source: libosinfo
Source-Version: 1.6.0-1
Severity: normal

The PCI and USB ID databases have been split into their own source and
binary packages so that they can be updated more regularly, and can be
depended on w/o having to pull in the tools. The Build-Depends and the
Depends in libosinfo-1.0-0 could be switched from pciutils to pci.ids
and from usbutils to usb.ids.

Thanks,
Guillem



Bug#861876: cups-filters: imagetoraster messes up output

2019-11-10 Thread Karl H. Beckers


> On 10. Nov 2019, at 21:01, Brian Potkin  wrote:
> 
> tags 861876 moreinfo
> thanks
> 
> 
> 
> On Fri 05 May 2017 at 11:37:30 +0200, Karl Beckers wrote:
> 
>> unfortunately, I'm not sure what led to the situation. It may have been 
>> some dist-upgrade in the past after which I hadn't tried the functionality. 
>> 
>> I have an image that I scanned and am trying to print via CUPS using splix 
>> and tracked down my issues with that to the output of imagetoraster being 
>> wrong. 
>> 
>> The output of scanimage either as a pnm or tiff looks good, here. But when 
>> I use imagetoraster and try to process it further it gets printed out 
>> distorted.
>> If I view the result of imagetoraster with rasterview, it looks distorted 
>> already.
>> 
>> a.out is the original image as scanned
>> b.out is the result of imagetoraster created like this:
>> cat /scratch/a.out | /usr/lib/cups/filter/imagetoraster - - "copy button 
>> pressed" 1 - > /scratch/b.out
> 
> Thank you for your report, Karl.
> 
> You appear to have done everything right here, but would you test again
> on a testing/unstable installation, preferably with a different scanned
> image.
> 
> Thanks,
> 
> Brian.


Hi Brian,

unfortunately, 2.5 yrs later, I have no part of that setup, anymore. Frankly, I 
don’t even remember how I worked around the issue.
If you wish to close this, feel free.

Cheers,

Karl.


Bug#944336: [Pkg-net-snmp-devel] Bug#944336: snmpd flood syslog when ipv6 disabled

2019-11-10 Thread Craig Small
On Fri, 8 Nov 2019 at 16:12, Giorgos Sakellaropoulos 
wrote:

> Nov  8 06:16:42 hostname snmpd[744]: ipaddress_linux: could not open
> /proc/net/if_inet6: No such file or directory
>

Hi George,
  This has been fixed in the upstream repository[1] where it will only log
once. I'll see where they are up to with their release cycle and if its a
while off, add a patch in Debian.

 - Craig


1:
https://sourceforge.net/p/net-snmp/code/ci/cd09fd82522861830aaf9d237b26eef5f9ba50d2


Bug#886332: autopkgtest-virt-qemu: how to make persistent dist-upgrades

2019-11-10 Thread Johannes Schauer
Hi Francesco,

Quoting Francesco Poli (2019-11-10 16:38:56)
> On Sat, 27 Jan 2018 22:45:37 +0100 Martin Pitt  wrote:
> 
> [...]
> > Johannes Schauer [2018-01-12 14:27 +0100]:
> [...]
> > > When I added the autopkgtest backend to sbuild in addition to schroot, I 
> > > did
> > > this with the long term goal in mind that at some point I could also 
> > > update the
> > > sbuild-update program to support the autopkgtest backend.
> > 
> > It's not what I would recommend doing actually, as with backends like LXC, 
> > lxd,
> > or qemu it's actually more reliable and presumably not even slower to just
> > download a current daily image than upgrading existing ones. With schroots 
> > it
> > makes a lot more sense, but there's already mk-sbuild for that job. Of 
> > course
> > you can work with upgraded testbeds, but by nature they are less reliable.
> 
> Hello,
> I am a "passerby" with respect to this bug report, so to speak.
> 
> I would like to ask a question: Martin, do I understand correctly that
> you are saying that recreating the QEMU/KVM testbed from scratch (with
> autopkgtest-build-qemu) is faster than upgrading an existing QEMU/KVM
> testbed? Despite the debootstrap step, which is notoriously slow?!?
> 
> Johannes, have you found a solution in the meanwhile?

well, my favourite solution is of course if autopkgtest would gain a
functionality to disable the read-only overlay and thus become capable of
making persisting changes to the backend. But I understood that Martin prefers
to rather re-create the underlying backend rather than upgrading it. He does
not seem to be alone either. You might find the following thread on
debian-devel interesting to read:

https://lists.debian.org/20191007102902.ga9...@espresso.pseudorandom.co.uk

I don't have enough free time to maintain an autopkgtest fork or plugin that
does what I want so instead I went the opposite way and created a tool that can
do the "re-bootstrap, don't upgrade" thing reasonably fast. I wrote to you
about that in #944485.

So basically my solution is to work around this bug by using mmdebstrap to
always re-create my base image instead of upgrading it.

Thanks!

cheers, josch


signature.asc
Description: signature


Bug#944501: Missing ppc64le builds

2019-11-10 Thread Timothy Pearson
Package: reptyr
Version: 0.6.2-1.2

Upstream reptyr 0.70 now has support for PowerPC.  We tested it earlier today 
to great success, however the older 0.6.2 version in Debian lacks this support 
and we had to build from GIT.

Please update to the latest reptyr release and enable ppc64le builds.

Thank you!



Bug#944500: hwdata: Can switch from pciutils and usbitils to pci.ids and usb.ids

2019-11-10 Thread Guillem Jover
Package: hwdata
Version: 0.290-1
Severity: normal

The PCI and USB ID databases have been split into their own source and
binary packages so that they can be updated more regularly, and can be
depended on w/o having to pull in the tools. The Depends could be
switched from pciutils to pci.ids and from usbutils to usb.ids.

(BTW the patch in the source diff.gz could now be dropped as that file
is not shipped from this package anymore.)

Thanks,
Guillem



Bug#943924: Processed: it no longer exists Re: please stop build-depending on python-pandas

2019-11-10 Thread Sandro Tosi
Rebecca, please revert this. pandas has still 9 rdeps
http://sandrotosi.me/debian/py2removal/python-pandas_1.svg and it's
not appropriate to drop it like this.

if you need to support py2 and py3 and upstream already dropped py2
support, you need to split it into 2 sources packages.

On Sun, Nov 10, 2019 at 5:15 PM Debian Bug Tracking System
 wrote:
>
> Processing control commands:
>
> > severity -1 serious
> Bug #943924 [python-matplotlib] matplotlib2: please stop build-depending on 
> python-pandas
> Severity set to 'serious' from 'important'
>
> --
> 943924: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=943924
> Debian Bug Tracking System
> Contact ow...@bugs.debian.org with problems



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



Bug#944498: libpciaccess0: Can switch from Suggests pciutils to Depends pci.ids

2019-11-10 Thread Guillem Jover
Package: libpciaccess0
Version: 0.14-1
Severity: normal

Hi!

I've split the pci.ids database into its own source and binary
package, which means this package could switch to a Depends (or
perhaps a Recommends if that's too much), w/o having to pull in
any tools package anymore.

Thanks,
Guillem



Bug#944499: FTBFS: IndexError: list index out of range

2019-11-10 Thread Adam Borowski
Source: fonts-alegreya-sans
Version: 2.008-1
Severity: serious
Tags: ftbfs
Justification: fails to build from source

Hi!
I'm afraid your package fails to build from source:

.
INFO:fontmake.font_project:Generating instance UFO for "Alegreya Sans Light"
Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/fontmake/instantiator.py", line 314, in 
generate_instance
glyph_instance = glyph_mutator.instance_at(location_normalized)
[...]
  File "/usr/lib/python3/dist-packages/fontMath/mathGlyph.py", line 499, in 
_processMathOneContours
points2 = contours2[index]["points"]
IndexError: list index out of range

The above exception was the direct cause of the following exception:

Traceback (most recent call last):
  File "/usr/bin/fontmake", line 11, in 
load_entry_point('fontmake==2.0.4', 'console_scripts', 'fontmake')()
[...]
  File "/usr/lib/python3/dist-packages/fontmake/instantiator.py", line 329, in 
generate_instance
) from e
fontmake.instantiator.InstantiatorError: Failed to generate instance of glyph 
'colonsign.BRACKET.75'.
`

On another run (full log attached) the glyph was 'longs.l' instead.


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

Kernel: Linux 5.4.0-rc6-00053-g729694c1a413 (SMP w/64 CPU cores)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)
sbuild (Debian sbuild) 0.78.1 (09 February 2019) on valinor.angband.pl

+==+
| fonts-alegreya-sans 2.008-1 (amd64)  Sun, 10 Nov 2019 18:31:25 + |
+==+

Package: fonts-alegreya-sans
Version: 2.008-1
Source Version: 2.008-1
Distribution: unstable
Machine Architecture: amd64
Host Architecture: amd64
Build Architecture: amd64
Build Type: binary

I: NOTICE: Log filtering will replace 
'var/run/schroot/mount/unstable-amd64-sbuild-6868024d-89bd-4b78-9d21-4c3a4471c7a0'
 with '<>'
I: NOTICE: Log filtering will replace 
'build/fonts-alegreya-sans-LiDCKh/resolver-b4Dc2K' with '<>'

+--+
| Fetch source files   |
+--+


Local sources
-

/mnt/optane/f/fonts-alegreya-sans_2.008-1.dsc exists in /mnt/optane/f; copying 
to chroot
I: NOTICE: Log filtering will replace 
'build/fonts-alegreya-sans-LiDCKh/fonts-alegreya-sans-2.008' with 
'<>'
I: NOTICE: Log filtering will replace 'build/fonts-alegreya-sans-LiDCKh' with 
'<>'

+--+
| Install package build dependencies   |
+--+


Setup apt archive
-

Merged Build-Depends: debhelper (>= 11), fontmake (>= 1.8.0), sfnt2woff-zopfli, 
woff2, build-essential, fakeroot
Filtered Build-Depends: debhelper (>= 11), fontmake (>= 1.8.0), 
sfnt2woff-zopfli, woff2, build-essential, fakeroot
dpkg-deb: building package 'sbuild-build-depends-main-dummy' in 
'/<>/apt_archive/sbuild-build-depends-main-dummy.deb'.
Ign:1 copy:/<>/apt_archive ./ InRelease
Get:2 copy:/<>/apt_archive ./ Release [957 B]
Ign:3 copy:/<>/apt_archive ./ Release.gpg
Get:4 copy:/<>/apt_archive ./ Sources [394 B]
Get:5 copy:/<>/apt_archive ./ Packages [475 B]
Fetched 1826 B in 0s (21.3 kB/s)
Reading package lists...
Reading package lists...

Install main build dependencies (apt-based resolver)


Installing build dependencies
Reading package lists...
Building dependency tree...
Reading state information...
The following additional packages will be installed:
  fontconfig fontconfig-config fontmake fonts-dejavu-core glyphsinfo libblas3
  libbrotli1 libdbus-1-3 libdouble-conversion3 libdrm-amdgpu1 libdrm-common
  libdrm-intel1 libdrm-nouveau2 libdrm-radeon1 libdrm2 libedit2 libegl-mesa0
  libegl1 libevdev2 libexpat1 libfontconfig1 libfreetype6 libgbm1 libgfortran5
  libgl1 libgl1-mesa-dri libglapi-mesa libglvnd0 libglx-mesa0 libglx0
  libgraphite2-3 libgudev-1.0-0 libharfbuzz0b libice6 libinput-bin libinput10
  libjpeg62-turbo liblapack3 liblbfgsb0 libllvm9 libmpdec2 libmtdev1
  libpciaccess0 libpcre2-16-0 libpng16-16 libpython3-stdlib
  libpython3.7-minimal libpython3.7-stdlib libqt5core5a libqt5dbus5 libqt5gui5
  libqt5network5 libqt5widgets5 libreadline8 libsensors-config libsensors5
  libsm6 libsqlite3-0 libssl1.1 libttfautohint1 libwacom-common libwacom2
  libwayland-client0 libwayland-server0 

Bug#944497: core: cammand-not-found db crash

2019-11-10 Thread Mark H. Webb
Package: core
Version: Buster
Severity: normal

Dear Maintainer,

I was compiling cilantro from githug Kampaz/cilantro and I missed one of the
dependant programs, tiny.py or tinyply in github.  I downloaded tiny.py and ran
cmake and then make and got the message below. 
I re-booted and went to  the root and typed in: update-command-not-found as the
error suggested, but I got the same message.  now any command not a core command
generates this same message. 

the first line on the first time the message appears is the report a bug and
that the command-not-found DB has crashed.

Mark Webb

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

Kernel: Linux 4.19.0-6-686-pae (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)
LSM: AppArmor: enabled


-- message of error
command-not-found version: 0.3
Python version: 3.7.3 final 0
Distributor ID: Debian
Description:Debian GNU/Linux 10 (buster)
Release:10
Codename:   buster
Exception information:

local variable 'cnf' referenced before assignment
Traceback (most recent call last):
  File "/usr/share/command-not-found/CommandNotFound/util.py", line 23, in 
crash_guard
callback()
  File "/usr/lib/command-not-found", line 93, in main
if not cnf.advise(args[0], options.ignore_installed) and not 
options.no_failure_msg:
UnboundLocalError: local variable 'cnf' referenced before assignment



Bug#944485: mmdebstrap: please implement the creation of QEMU/KVM images for autopkgtest-virt-qemu

2019-11-10 Thread Johannes Schauer
Hi Francesco,

Quoting Francesco Poli (wintermute) (2019-11-10 18:44:47)
> Hello and thanks for developing/packaging this tool!
> 
> I wonder whether it can be used to create (without superuser privileges!)
> a QEMU/KVM image.
> I am especially interested in QEMU/KVM images suitable as autopkgtest
> testbeds (autopkgtest-virt-qemu), but the feature could perhaps be
> useful for building other minimal Debian base QEMU/KVM images as well...
> 
> As you most probably know, autopkgtest-build-qemu uses vmdb2 under the
> hood, and vmdb2 [requires] to be run as root. I wonder whether mmdebstrap
> can be used in stead of vmdb2, in order to lift the superuser privilege
> requirement.
> 
> [requires]: 
> 
> Could this feature be implemented? It would really be awesome to have
> a tool that allows a regular user to create a QEMU/KVM minimal Debian
> image...

it does not need to be implemented because it is already possible.

It works through currently undocumented options that allow for hooks. Well,
actually the documentation already exists but is commented out, so you don't
see it in the man page that is generated from Perl POD. You can read the
documentation by reading the POD at the end of /usr/bin/mmdebstrap. For your
convenience I'll paste you the missing docs at the end of this mail. Part of
the docs is precisely what you were asking for: how to use mmdebstrap to
replace autopkgtest-build-qemu.

Thanks!

cheers, josch


   --setup-hook=command
   Execute arbitrary commands right after initial setup (directory 
creation,
   configuration of apt and dpkg, ...) but before any packages are 
downloaded
   or installed. At that point, the chroot directory does not 
contain any
   executables and thus cannot be chroot-ed into.  The option can be
   specified multiple times and the commands are executed in the 
order in
   which they are given on the command line. If command is an 
existing
   executable file or if command does not contain any shell 
metacharacters,
   then command is directly exec-ed with the path to the chroot 
directory
   passed as the first argument. Otherwise, command is executed 
under sh and
   the chroot directory can be accessed via $1. All environment 
variables
   used by mmdebstrap (like "APT_CONFIG", "DEBIAN_FRONTEND", 
"LC_ALL" and
   "PATH") are preserved.

   Example: Setup merged-/usr via symlinks

   --setup-hook='for d in bin sbin lib; do ln -s usr/$d 
"$1/$d"; mkdir -p "$1/usr/$d"; done'

   Example: Setup chroot for installing a sub-essential 
busybox-based chroot
   with --variant=custom
   
--include=dpkg,busybox,libc-bin,base-files,base-passwd,debianutils

   --setup-hook='mkdir -p "$1/bin"'
   --setup-hook='for p in awk cat chmod chown cp diff echo env 
grep less ln mkdir mount rm rmdir sed sh sleep sort touch uname; do ln -s 
busybox "$1/bin/$p"; done'
   --setup-hook='echo root:x:0:0:root:/root:/bin/sh > 
"$1/etc/passwd"'
   --setup-hook='printf "root:x:0:\nmail:x:8:\nutmp:x:43:\n" > 
"$1/etc/group"'

   --essential-hook=command
   Execute arbitrary commands after the Essential:yes packages have 
been
   installed but before installing the remaining packages. The hook 
is not
   executed for the extract and custom variants. The option can be 
specified
   multiple times and the commands are executed in the order in 
which they
   are given on the command line. If command is an existing 
executable file
   or if command does not contain any shell metacharacters, then 
command is
   directly exec-ed with the path to the chroot directory passed as 
the first
   argument. Otherwise, command is executed under sh and the chroot 
directory
   can be accessed via $1. All environment variables used by 
mmdebstrap (like
   "APT_CONFIG", "DEBIAN_FRONTEND", "LC_ALL" and "PATH") are 
preserved.

   Example: Enable unattended upgrades

   --essential-hook='echo unattended-upgrades 
unattended-upgrades/enable_auto_updates boolean true | chroot "$1" 
debconf-set-selections'

   Example: Select Europe/Berlin as the timezone

   --essential-hook='echo tzdata tzdata/Areas select Europe | 
chroot "$1" debconf-set-selections'
   --essential-hook='echo tzdata tzdata/Zones/Europe select 
Berlin | chroot "$1" debconf-set-selections'
   --customize-hook=command
   Execute arbitrary commands after the chroot is set up and all 
packages got
   installed but before final cleanup actions are carried out.  The 
option
   can be specified multiple times and the commands 

Bug#943923: it no longer exists Re: please stop build-depending on python-pandas

2019-11-10 Thread Rebecca N. Palmer

Control: severity -1 serious

python-pandas has now been removed, so these packages are now 
BD-Uninstallable.




Bug#874853: [cmtk] Future Qt4 removal from Buster

2019-11-10 Thread Moritz Mühlenhoff
On Thu, Oct 31, 2019 at 08:11:31PM -0700, Torsten Rohlfing wrote:

> > There hasn't been any followup on this bug since two years and we're now
> > moving
> > forward with the Qt4 removal, are the immediate plans to port cmtk to Qt5
> > or
> > should we remove it from the archive?
> >
> No plans for Qt5 whatsoever.
> 
> The only thing to note here is that Qt is actually optional for the vast
> majority of CMTK's tools. The package config could probably be changed to
> build without GUI support, which would remove the dependency on Qt.

I'm attaching a patch which disables the GUI tools in the package build.

Cheers,
Moritz
diff -aur cmtk-3.3.1p1+dfsg.orig/debian/control cmtk-3.3.1p1+dfsg/debian/control
--- cmtk-3.3.1p1+dfsg.orig/debian/control	2019-01-25 09:24:56.0 +0100
+++ cmtk-3.3.1p1+dfsg/debian/control	2019-11-10 22:43:57.518788563 +0100
@@ -13,8 +13,6 @@
libbz2-dev,
libfftw3-dev,
liblzma-dev,
-   libqt4-dev,
-   qt4-qmake,
libpng-dev,
libtiff-dev | libtiff4-dev,
libwrap0-dev,
diff -aur cmtk-3.3.1p1+dfsg.orig/debian/rules cmtk-3.3.1p1+dfsg/debian/rules
--- cmtk-3.3.1p1+dfsg.orig/debian/rules	2019-01-25 09:24:56.0 +0100
+++ cmtk-3.3.1p1+dfsg/debian/rules	2019-11-10 22:48:57.444774239 +0100
@@ -38,7 +38,7 @@
 		-DCMAKE_VERBOSE_MAKEFILE:BOOL=ON \
 		-DBUILD_APPS:BOOL=ON \
 		-DBUILD_DOCUMENTATION:BOOL=OFF \
-		-DBUILD_GUI:BOOL=ON \
+		-DBUILD_GUI:BOOL=OFF \
 		-DBUILD_SHARED_LIBS:BOOL=ON \
 		-DBUILD_TESTING:BOOL=$(TESTING) \
 		-DCMTK_BUILD_DCMTK:BOOL=OFF \
@@ -49,7 +49,7 @@
 		-DCMTK_ROOT_PATH_SRI24:PATH=/usr/share/data/sri24-atlas \
 		-DCMTK_USE_DCMTK:BOOL=ON \
 		-DCMTK_USE_FFTW:BOOL=ON \
-		-DCMTK_USE_QT:BOOL=ON \
+		-DCMTK_USE_QT:BOOL=OFF \
 		-DCMTK_USE_SMP:BOOL=ON \
 		-DCMTK_USE_SQLITE:BOOL=ON \
 		-DDART_TESTING_TIMEOUT:STRING=15000 \



Bug#942493: 5000 is a tad too small (was Re: lintian: Please warn about overly-long header fields)

2019-11-10 Thread Thorsten Glaser
Hi *,

I understand that 5000 is a lot for most fields, but my
Description field is a mere 7526 chars long, and the original
request was for a warning above 16384 chars(? bytes?).

Please reconsider: adjust limits depending on which field it is.

bye,
//mirabilos
-- 
Stéphane, I actually don’t block Googlemail, they’re just too utterly
stupid to successfully deliver to me (or anyone else using Greylisting
and not whitelisting their ranges). Same for a few other providers such
as Hotmail. Some spammers (Yahoo) I do block.



Bug#944138: ITP: libtraceevent -- The libtraceevent library provides APIs to access kernel tracepoint events

2019-11-10 Thread Ben Hutchings
On Sun, 2019-11-10 at 21:29 +, Sudip Mukherjee wrote:
> On Fri, Nov 08, 2019 at 07:56:55PM +, Ben Hutchings wrote:
> > On Mon, 2019-11-04 at 21:44 +, Sudip Mukherjee wrote:
> > [...]
> > > The code for libtracevent lives in the kernel tree at
> > > git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git in 
> > > tools/lib/traceevent folder.
> > > And so, it will be great if kernel team will like to package and maintain 
> > > it, if not, then I will
> > > be happy to do it. But, if I am doing it then I will need a sponsor to 
> > > upload it.
> > 
> > If kernel.org's kernel source repository is the canonical location for
> > this code, not just a convenience copy, then the binary package should
> > be built from src:linux and not a separate source package.
> > 
> > I think src:linux already builds the library, but only as a static
> > library that's linked into perf.
> > 
> > I don't know exactly what changes you would need to make, but they
> > should be roughly along these lines:
> > 
> 
> > 4. Generate the debian/libtraceevent.symbols file recording
> >the shared library's exported symbols.
> 
> Thanks for your reply Ben.
> I will try these steps and see how it goes.
> 
> > 5. (Not sure if this is needed.)  Modify
> >debian/rules.d/tools/perf/Makefile to make perf use the shared
> >library.  Add libtraceevent to the dependencies of
> >linux-perf- in debian/templates/control.tools-versioned.in.
> 
> This should not be needed as perf does not yet depend on libtraceevent.
> The libtraceevent that perf is creating is only having the plugins.

I'm pretty sure it does; look for "libtraceevent.a" in
.

Ben.

-- 
Ben Hutchings
Humans are not rational beings; they are rationalising beings.



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


Bug#900787: nvidia-graphics-drivers-legacy-304xx: does not support Xorg Xserver 1.20

2019-11-10 Thread Pierre Bernhardt
Package: xserver-xorg-video-nvidia-legacy-304xx
Version: 304.137-7
Followup-For: Bug #900787

Dear Maintainer,

I use a Dell Inspiron 9400 Laptop with a nvidia 7900 Go
graphics adapter which is not changegable to a newer
gpu card.
This 64 bit laptop is for the trash bin if I cannot
use it any more like with freecad which supports
also nouveau driver, but is not really working with
all needed hw acceleration.
So also freecad as an example is not really usuable
with nouveau on this laptop and other accelerations
looks like not further usuable like video decoding via
gpu.

Please add support for the legacy driver for my
card (which is still only available by 304xx).
It looks like the installation could be only
possible by using stretch and not buster?
And what is if the support for stretch ends?
So downgrade to stretch is also not the optimal
option.
Is it not really possible to use xserver version
1.20 for this driver or must I downgrade xserver
to 1.19?

Save the world from electronic trash by eol
supported software.

Cheers,

PS: I installed only the 304xx from unstable.
All the rest is still from stable.

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

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

Versions of packages xserver-xorg-video-nvidia-legacy-304xx depends
on:
ii  libc6
2.28-10
ii  libnvidia-legacy-304xx-glcore
304.137-7
ii  nvidia-installer-cleanup
20151021+9
ii  nvidia-legacy-304xx-alternative
304.137-7
ii  nvidia-support
20151021+9
pn  xorg-video-abi-23 | xorg-video-abi-20 | xorg-video-abi-19 | xor

ii  xserver-xorg-core
2:1.20.4-1
ii  xserver-xorg-legacy
2:1.20.4-1

Versions of packages xserver-xorg-video-nvidia-legacy-304xx
recommends:
pn  nvidia-legacy-304xx-driver

ii  nvidia-legacy-304xx-kernel-dkms [nvidia-legacy-304xx-kernel-304.
304.137-7
ii  nvidia-legacy-304xx-vdpau-driver
304.137-7
ii  nvidia-settings-legacy-304xx
304.137-2



Bug#944496: FTBFS: Assigning non-zero to $[ is no longer possible at tools/hex2bdf

2019-11-10 Thread Adam Borowski
Source: xfonts-efont-unicode
Version: 0.4.2-11
Severity: serious
Tags: ftbfs
Justification: fails to build from source

Hi!
I'm afraid that the package fails to build, with a bunch of:
Assigning non-zero to $[ is no longer possible at tools/hex2bdf line 17, <> 
line 7446.

Additionally, there's some binary spew to the terminal.

Full log attached.


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

Kernel: Linux 5.4.0-rc6-00053-g729694c1a413 (SMP w/64 CPU cores)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)


xfonts-efont-unicode_amd64.build
Description: Binary data


Bug#875250: Bug#875258: [scim] Future Qt4 removal from Buster

2019-11-10 Thread Moritz Mühlenhoff
On Sun, Sep 08, 2019 at 03:31:29AM +0800, Tz-Huan Huang wrote:
> On Fri, Aug 30, 2019 at 4:39 AM Moritz Mühlenhoff  wrote:
> 
> > On Sat, Sep 09, 2017 at 11:09:36PM +0200, Lisandro Damián Nicanor Pérez
> > Meyer wrote:
> > > Source: scim
> > >
> > > Hi! As you might know we the Qt/KDE team are preparing to remove Qt4
> > > as [announced] in:
> > >
> > > [announced] <
> > https://lists.debian.org/debian-devel-announce/2017/08/msg6.html>
> > >
> > > Currently Qt4 has been dead upstream and we are starting to have problems
> > > maintaining it, like for example in the [OpenSSL 1.1 support] case.
> > >
> > > [OpenSSL 1.1 support] <
> > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=828522>
> > >
> > > In order to make this move, all packages directly or indirectly
> > depending on
> > > the Qt4 libraries have to either get ported to Qt5 or eventually get
> > > removed from the Debian repositories.
> > >
> > > Therefore, please take the time and:
> > > - contact your upstream (if existing) and ask about the state of a Qt5
> > > port of your application
> > > - if there are no activities regarding porting, investigate whether
> > there are
> > > suitable alternatives for your users
> > > - if there is a Qt5 port that is not yet packaged, consider packaging it
> > > - if both the Qt4 and the Qt5 versions already coexist in the Debian
> > > archives, consider removing the Qt4 version
> >
> > Given upstream's comments on https://github.com/scim-im/scim/issues/21,
> > let's
> > move forward by dropping the scim-qt-immodule binary package? It can still
> > be re-added if a Qt5 port appears at a later time.
> >
> 
> Sure. I have made the update and been waiting for maintainer's review.
> 
>   https://github.com/leggewie-DM/scim/pull/1

Hi Rolf,
could you have a look/do an upload? Once the qscintilla migration is complete,
scim will be the last remaining key package blocking the removal of Qt4
from testing.

Cheers,
Moritz



Bug#944399: ccache: Building aosp-10 bionic leads to ld.lld: error: undefined symbol: strcpy_a9

2019-11-10 Thread Joel Rosdahl
Thanks for the bug report.

On Sat, 9 Nov 2019 at 08:06, Stefan Rücker 
wrote:
> I can provide you files or infos from the failing build if you need
those, the
> problem is reproducible.

Yes, I will need assistance to investigate this. From
https://github.com/sonyxperiadev/bug_tracker/issues/492 I followed the
trail to
https://github.com/stefanhh0/aosp-10/blob/master/ and then to
https://developer.sony.com/develop/open-devices/guides/aosp-build-instructions
but failed at the "Initialise the AOSP tree" step. "repo sync" said this:

fatal: remove-project element specifies non-existent project:
device/google/marlin

Could you perhaps share more or less exactly which commands to use to get
the
AOSP source code and build it to reproduce the problem?

Also, could you report the bug in ccache's GitHub project
(https://github.com/ccache/ccache)?

Thanks,
-- Joel


Bug#944437: RFS: rpl/1.0-3 [QA] -- replace strings in files

2019-11-10 Thread Adam Borowski
On Sun, Nov 10, 2019 at 01:46:22AM -0300, Thiago wrote:
>  * Package name: rpl
>Version : 1.6.3-1

> Changes since the last upload:
> 
>* QA upload.
>* New upstream version 1.6.3.
>* debian/control:
>- Added 'Rules-Requires-Root: no' in source stanza.
>- Bumped Standards-Version to 4.4.1.
>- Reorganized long description.
>* debian/copyright: added new rights in debian/* block.
>* debian/patches/20_fixed_upstream_version.patch: created
>to fixed the upstream version program.
>* debian/salsa-ci.yml: added to provide CI tests for Salsa.
>* debian/watch: updated, using new variables.

The man page is corrupted:
.--[ man rpl ]
DESCRIPTION
   Basic  usage is to specify two strings and one or more filenames or 
directories on the command line.  The first string is the string to replace, 
and the second string is
   the replacement string.

   Traceback (most recent call last):
  File "./rpl", line 29, in 

  from chardet.universaldetector import UniversalDetector

   ModuleNotFoundError: No module named 'chardet'

  File "./rpl", line 29, in 

  from chardet.universaldetector import UniversalDetector

   ModuleNotFoundError: No module named 'chardet'
`

And the tool doesn't seem to work either:
.
[~/tmp/pkg/some-other-random-package/debian]$ rpl Package Pąckagę *

rpl: Replacing "Package" with "Pąckagę" (case sensitive; partial words matched)
.
rpl: could not guess encoding; using locale default 'UTF-8'

rpl: Could not replace /tmp/.tmp.yl3o48fk with changelog; error: [Errno 18] 
Invalid cross-device link: '/tmp/.tmp.yl3o48fk' -> 'changelog'
.
rpl: Could not replace /tmp/.tmp.df0h2nph with control; error: [Errno 18] 
Invalid cross-device link: '/tmp/.tmp.df0h2nph' -> 'control'
..
rpl: A total of 0 matches replaced in 8 files searched

`


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀ A MAP07 (Dead Simple) raspberry tincture recipe: 0.5l 95% alcohol,
⣾⠁⢠⠒⠀⣿⡁ 1kg raspberries, 0.4kg sugar; put into a big jar for 1 month.
⢿⡄⠘⠷⠚⠋⠀ Filter out and throw away the fruits (can dump them into a cake,
⠈⠳⣄ etc), let the drink age at least 3-6 months.



Bug#944138: ITP: libtraceevent -- The libtraceevent library provides APIs to access kernel tracepoint events

2019-11-10 Thread Sudip Mukherjee


On Fri, Nov 08, 2019 at 07:56:55PM +, Ben Hutchings wrote:
> On Mon, 2019-11-04 at 21:44 +, Sudip Mukherjee wrote:
> [...]
> > The code for libtracevent lives in the kernel tree at
> > git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git in 
> > tools/lib/traceevent folder.
> > And so, it will be great if kernel team will like to package and maintain 
> > it, if not, then I will
> > be happy to do it. But, if I am doing it then I will need a sponsor to 
> > upload it.
> 
> If kernel.org's kernel source repository is the canonical location for
> this code, not just a convenience copy, then the binary package should
> be built from src:linux and not a separate source package.
> 
> I think src:linux already builds the library, but only as a static
> library that's linked into perf.
> 
> I don't know exactly what changes you would need to make, but they
> should be roughly along these lines:
> 

> 
> 4. Generate the debian/libtraceevent.symbols file recording
>the shared library's exported symbols.

Thanks for your reply Ben.
I will try these steps and see how it goes.

> 
> 5. (Not sure if this is needed.)  Modify
>debian/rules.d/tools/perf/Makefile to make perf use the shared
>library.  Add libtraceevent to the dependencies of
>linux-perf- in debian/templates/control.tools-versioned.in.

This should not be needed as perf does not yet depend on libtraceevent.
The libtraceevent that perf is creating is only having the plugins.


--
Regards
Sudip



Bug#944475: [PATCH] email-print-mime-structure: change --use-gpg-agent to a simple flag

2019-11-10 Thread Sean Whitton
Hello Daniel,

On Sun 10 Nov 2019 at 11:47AM -05, Daniel Kahn Gillmor wrote:

> Turns out that type=bool doesn't really do what we want it to do (see
> https://bugs.python.org/issue37564), and there is no built-in easy
> answer for argparse to accept a boolean value sensibly
> (e.g. type='bool', which might be able to handle "yes" and "no" and
> "1" and "0" and "on" and "off" as well as "true" and "false", etc)

This is a frustrating limitation, indeed.

> So rather than implement all of that here, we'll just have
> --use-gpg-agent as a simple flag.  This is an API change, but the
> previous API has only been out for a few days, and the tool is
> documented for interactive use.

Can you add the --no-use-gpg-agent option now, please?

I'd like to give users the option of immunising themselves from any
defaults change if they embed a call to email-print-mime-structure in
some sort of script.

We've said that machines should not try to parse the output of
email-print-mime-structure, but someone might still use a wrapper to
call email-print-mime-structure, even if that wrapper does nothing with
the output other than show it to a human.

-- 
Sean Whitton


signature.asc
Description: PGP signature


Bug#919619: network-manager: should support iwd as wpasupplicant alternative

2019-11-10 Thread Andreas Henriksson
Hi,

On Thu, Nov 07, 2019 at 12:21:45AM +0100, Jonas Smedegaard wrote:
> Please relax to only _recommend_ wpasupplicant, to allow (even if not 
> recommend) use with IWD.

Since iwd 1.0 is now out, it should (hopefully) atleast provide a stable
(dbus) interface. Here's my updated view on things related to NM with my
personal view of severity in brackets:

- iwd support in NM is still immature (minor features that I would
  count as essential missing, eg. NM still actively refuse to connect
  to hidden SSIDs with iwd backend. No way to provision hidden networks,
  many other similar missing features which might not be used by all but
  is critical for a connection for some.) [minor]
- NM upstream developers seems still very hesitant to support iwd at
  all, e.g. last I talked to them they still think NOTHING is a better
  fallback than falling back on iwd if wpasupplicant is not
  available/installed. Recent upstream comments like "those unfortunate
  enough to run IWD" doesn't give me confidence they'll change they're
  about to change their mind very soon either. [major]
- debian kernel options still missing to be able to use iwd with
  WPA2 Enterprise networks. (And no idea about status of NM with iwd and
  Enterprise networks.) [medium]

At this point in time I personally find it hard to argue for supporting
using NM without having wpasupplicant installed (in favour of iwd).
The extra support burden for people who blindly install without
recommends simply isn't worth it. IMHO a better option would be to
eventually just add iwd as an alternative on the wpasupplicant
dependency (but I don't think we're quite there yet either).
Those that want to use iwd (with NM), still need to manually configure
NM and while doing so stopping/disabling the wpasupplicant service
(while keeping it installed in case of emergencies) isn't a big extra
burden IMHO.

Once using iwd can actually be considered to "just work" for common
operations I'm all for getting rid of the wpasupplicant baggage, but for
now I think efforts are needed (mainly) in NM upstream to get there. (Help
welcome! ;-P)

PS. The required kernel option has now atleast been discussed with
debian kernel team, but unfortunately I find it quite depressing that
their latest feedback was that they say they don't have time to enable a
single Kconfig option (off -> module). I have no idea why shipping yet
another module would be something they would have to think so hard about
or why enabling the option would take more time than talk about it.

.oO( So close, but yet so far away )

Regards,
Andreas Henriksson



Bug#826543: cupsd fails to remove job files at end of PreserveJobFiles interval

2019-11-10 Thread Sergio Gelato
Earlier I pointed out that upstream commit

[53cac1d08bba395942df638d74526470c9fc7975] Fix parentheses in cupsdCleanJobs

isn't in buster. I've now given some more thought to the implications of this. 
In the typical case (default settings) job->history_time is INT_MAX. The 
misplaced parenthesis makes the code behave as

if (1 < JobHistoryUpdate || !JobHistoryUpdate) JobHistoryUpdate = 
job->history_time;

which means JobHistoryUpdate will nearly always be updated. It will therefore 
most likely (until 2038, anyway) end up with the file_time value of the last 
job in the array. I haven't checked how the jobs array is sorted; I think the 
code should avoid relying on a particular ordering. The correct result is of 
course the earliest file_time value of all jobs in the array, so the misplaced 
parenthesis could result in cleanup being unduly delayed.

By the way, the way in which history_time and file_time are calculated in 
cupsdLoadJob() and cupsdUpdateJobs() could result in wraparound on platforms 
with signed 32-bit time_t. For plausible values of PreserveJobHistory and 
PreserveJobFiles this isn't going to bite until 2038 or maybe late 2037, but 
what if one  now were to test with "1000w" on a 32-bit platform?


Bug#944489: Info received (Bug#944489: Acknowledgement (dietlibc: FTBFS on new hppa kernels - Invalid setsockopt argument))

2019-11-10 Thread Thorsten Glaser
Hi Dave,

>The following change fixes the setsockopt problem.
>
>I also hacked unified.S.  Implicit space register selection should be
>used in the loads and stores.

thanks! Testing on the porterbox, will upload then.

bye,
//mirabilos
-- 
[...] if maybe ext3fs wasn't a better pick, or jfs, or maybe reiserfs, oh but
what about xfs, and if only i had waited until reiser4 was ready... in the be-
ginning, there was ffs, and in the middle, there was ffs, and at the end, there
was still ffs, and the sys admins knew it was good. :)  -- Ted Unangst über *fs



Bug#923009: fixed 923009 seafile/7.0.2-1

2019-11-10 Thread Salvatore Bonaccorso
Hi Moritz,

Sorry for the late reply.

On Thu, Oct 31, 2019 at 11:39:52AM +0100, Moritz Schlarb wrote:
> Hi Salvatore,
> 
> thanks for following up!
> 
> On 30.10.19 17:33, Salvatore Bonaccorso wrote:
> > On Wed, Oct 30, 2019 at 11:27:34AM +0100, Moritz Schlarb wrote:
> >> fixed 923009 seafile/7.0.2-1
> > 
> > I guess I have lost some context here. Can you clarify the following
> > before I proceed to mark the fixed version for the CVE as well in the
> > security-tracker?
> > 
> > The question is following: 923009, respective CVE-2013-7469 is
> > associated with upstream issue
> > https://github.com/haiwen/seafile/issues/350 . But there ws o closure
> > of this issue. In the previous BTS message you mentioned that the CVE
> > assignment was inaccurate, is the issue fixed with the new 0003 patch?
> 
> Now that I think harder about it, it is probably not totally fixed since
> it is still possible to use libraries encrypted with the older
> encryption format version ( < 3 ). The patch just makes the new
> encryption version ( 3 ) work with GPL_CRYPTO. Since libraries are
> created by the server side component (not yet/ever in Debian), the used
> encryption version is not really configurable by the user here.
> 
> What would be your interpretation of the relevant Debian guidelines in
> this case, where the foot-gun is still there, but at least the default
> should be better now?

It depends, and there is not rule written in stone. In this case I was
thinking of concluding to keep the issue open until at least upstream
clarifies on
https://github.com/haiwen/seafile/issues/350#issuecomment-548307815
(respectively if there will be a step towards not only making version
3 the fefault but disalowing as well the older formats).

Do you disagree or agree on that?

> > Were you able to reach out to MITRE (via the webform) to have the
> > references and description updated?
> 
> I filled it out (on 06.03.19 as CVE Request 652193 FWIW), but did never
> receive a response and it doesn't look like any changes were made... :(

Can you reping the autoreply you got asking for a status update?

Regards,
Salvatore



Bug#944404: libsedlex-ocaml: sedlex should depend on ocaml-uchar

2019-11-10 Thread Kyle Robbertze
Hi Andy,

On 2019/11/10 04:33, Andy Li wrote:
> Hi Kyle,
> 
> On Sat, Nov 9, 2019 at 5:15 PM Kyle Robbertze  wrote:
>> It seems that sedlex should depend on ocaml-uchar[1], which needs to be
>> packaged for Debian. According to sedlex opam file, this is already done
>> for opam builds of sedlex [2].
>>
>> [1] https://github.com/ocaml/uchar
>> [2] https://github.com/ocaml-community/sedlex/blob/master/sedlex.opam#L32
> 
> I've packaged uchar last week:
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=944085
> It's in the NEW queue right now.
> 
> Since it's a compatibility package, which is effectively empty for
> OCaml 4.08, I've just removed sedlex's dependency on uchar and
> uploaded ocaml-sedlex 2.1-2.
> Will close this bug once uchar is accepted into unstable and the
> sedlex dependency on uchar is restored.

Thanks. It is now working for me.

Cheers

-- 

⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Kyle Robbertze
⢿⡄⠘⠷⠚⠋⠀ Debian Developer
⠈⠳⣄ https://wiki.debian.org/KyleRobbertze



Bug#943653: thrift: fails to clean after build: cannot find java

2019-11-10 Thread GCS
Hi Andreas,

On Sun, Oct 27, 2019 at 3:45 PM Andreas Beckmann  wrote:
> thrift/experimental fails to clean after a successful build (I haven't
> checked whether the version in sid has the same problem).
> The build succeeds, but a subsequent 'make distclean' fails. (This does
> not happen during the first build, since the tree is unconfigured and
> 'make distclean' does not get called.)
 Please point me where's in the policy that a package must be
buildable several times from the same source tree and that
experimental is a supported branch (target for filing RC bugs).

Thanks,
Laszlo/GCS



Bug#944495: golang-github-keltia-archive: autopkgtest regression: --- FAIL: TestGpg_Extract4 (0.00s)

2019-11-10 Thread Paul Gevers
Source: golang-github-keltia-archive
Version: 0.7.0-1
X-Debbugs-CC: debian...@lists.debian.org
User: debian...@lists.debian.org
Usertags: regression

Dear maintainers,

With a recent upload of golang-github-keltia-archive the autopkgtest of
golang-github-keltia-archive fails in testing when that autopkgtest is
run with the binary packages of golang-github-keltia-archive from
unstable. It passes when run with only packages from testing. In tabular
form:
  passfail
golang-github-keltia-archive  from testing0.7.0-1
all othersfrom testingfrom testing

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

Currently this regression is blocking the migration to testing [1]. Can
you please investigate the situation and fix it? If needed, please
change the bug's severity.

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=golang-github-keltia-archive

https://ci.debian.net/data/autopkgtest/testing/amd64/g/golang-github-keltia-archive/3374734/log.gz

2019/11/09 22:24:22 Decrypting testdata/notempty.zip.asc
--- FAIL: TestGpg_Extract4 (0.00s)
archive_test.go:496:
Error Trace:archive_test.go:496
Error:  Not equal:
expected:
"PK\x03\x04\n\x00\x00\x00\x00\x00\x02\xa0[O\x15\xafPf\x0f\x00\x00\x00\x0f\x00\x00\x00\f\x00\x1c\x00notempty.txtUT\t\x00\x03E\xf7\xb5]E\xf7\xb5]ux\v\x00\x01\x04\x00\x00\x00\x00\x04\x00\x00\x00\x00this
is a
file\nPK\x01\x02\x1e\x03\n\x00\x00\x00\x00\x00\x02\xa0[O\x15\xafPf\x0f\x00\x00\x00\x0f\x00\x00\x00\f\x00\x18\x00\x00\x00\x00\x00\x01\x00\x00\x00\xa4\x81\x00\x00\x00\x00notempty.txtUT\x05\x00\x03E\xf7\xb5]ux\v\x00\x01\x04\x00\x00\x00\x00\x04\x00\x00\x00\x00PK\x05\x06\x00\x00\x00\x00\x01\x00\x01\x00R\x00\x00\x00U\x00\x00\x00\x00\x00"
actual  :
"PK\x03\x04\n\x00\x00\x00\x00\x00\u05c9HM\x15\xafPf\x0f\x00\x00\x00\x0f\x00\x00\x00\f\x00\x1c\x00notempty.txtUT\t\x00\x03ft\xbb[\xacz\xbb[ux\v\x00\x01\x04\xf5\x01\x00\x00\x04\x14\x00\x00\x00this
is a
file\nPK\x01\x02\x1e\x03\n\x00\x00\x00\x00\x00\u05c9HM\x15\xafPf\x0f\x00\x00\x00\x0f\x00\x00\x00\f\x00\x18\x00\x00\x00\x00\x00\x01\x00\x00\x00\xa4\x81\x00\x00\x00\x00notempty.txtUT\x05\x00\x03ft\xbb[ux\v\x00\x01\x04\xf5\x01\x00\x00\x04\x14\x00\x00\x00PK\x05\x06\x00\x00\x00\x00\x01\x00\x01\x00R\x00\x00\x00U\x00\x00\x00\x00\x00"

Diff:
--- Expected
+++ Actual
@@ -1,4 +1,4 @@
 PK
-��[O�Pf��������notempty.txtUT
�E��]E��]ux�this is a file
+�׉HM�Pf��������notempty.txtUT
�ft�[�z�[ux�������this is a file
 PK

-��[O�Pf���������notempty.txtUT�E��]ux
�PK��R���U�

+�׉HM�Pf���������notempty.txtUT�ft�[ux
�������PK��R���U�
Test:   TestGpg_Extract4
=== RUN   TestGpg_Extract4_Debug
2019/11/09 22:24:22 Decrypting testdata/notempty.zip.asc
--- FAIL: TestGpg_Extract4_Debug (0.00s)
archive_test.go:512:
Error Trace:archive_test.go:512
Error:  Not equal:
expected:
"PK\x03\x04\n\x00\x00\x00\x00\x00\x02\xa0[O\x15\xafPf\x0f\x00\x00\x00\x0f\x00\x00\x00\f\x00\x1c\x00notempty.txtUT\t\x00\x03E\xf7\xb5]E\xf7\xb5]ux\v\x00\x01\x04\x00\x00\x00\x00\x04\x00\x00\x00\x00this
is a
file\nPK\x01\x02\x1e\x03\n\x00\x00\x00\x00\x00\x02\xa0[O\x15\xafPf\x0f\x00\x00\x00\x0f\x00\x00\x00\f\x00\x18\x00\x00\x00\x00\x00\x01\x00\x00\x00\xa4\x81\x00\x00\x00\x00notempty.txtUT\x05\x00\x03E\xf7\xb5]ux\v\x00\x01\x04\x00\x00\x00\x00\x04\x00\x00\x00\x00PK\x05\x06\x00\x00\x00\x00\x01\x00\x01\x00R\x00\x00\x00U\x00\x00\x00\x00\x00"
actual  :
"PK\x03\x04\n\x00\x00\x00\x00\x00\u05c9HM\x15\xafPf\x0f\x00\x00\x00\x0f\x00\x00\x00\f\x00\x1c\x00notempty.txtUT\t\x00\x03ft\xbb[\xacz\xbb[ux\v\x00\x01\x04\xf5\x01\x00\x00\x04\x14\x00\x00\x00this
is a
file\nPK\x01\x02\x1e\x03\n\x00\x00\x00\x00\x00\u05c9HM\x15\xafPf\x0f\x00\x00\x00\x0f\x00\x00\x00\f\x00\x18\x00\x00\x00\x00\x00\x01\x00\x00\x00\xa4\x81\x00\x00\x00\x00notempty.txtUT\x05\x00\x03ft\xbb[ux\v\x00\x01\x04\xf5\x01\x00\x00\x04\x14\x00\x00\x00PK\x05\x06\x00\x00\x00\x00\x01\x00\x01\x00R\x00\x00\x00U\x00\x00\x00\x00\x00"

Diff:
--- Expected
+++ Actual
@@ -1,4 +1,4 @@
 PK
  

Bug#944260: lintian: Add a detection/tag for when compat is >> 10 and cdbs in build-depends

2019-11-10 Thread Mattia Rizzolo
On Wed, Nov 06, 2019 at 06:08:15PM -0500, Thomas Ward wrote:
> Possibly.  Perhaps I should go the Policy route and inquire whether we
> should consider CDBS obsolete by later versions of Debian policy...

"Obviously" the Policy has nothing at all to do with things such as
debhelper and cdbs, since it's describing the lower-level side of those
tools.

That said, I also agree that lintian has nothing to do at this time,
packages using cdbs will just FTBFS and that's it.  And you can just
move from cdbs to dh and most likely everybody else will only be
happier :)
https://trends.debian.net/#build-systems

You also should not bother with people not test building their packages
before uploading (personal suggestion).

-- 
regards,
Mattia Rizzolo

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


signature.asc
Description: PGP signature


Bug#929574: corrected in squid version 4.7

2019-11-10 Thread Boursin Olivier

Dear Maintainer,

This bug has been corrected in version 4.7 as showed in the changelog

https://github.com/squid-cache/squid/blob/master/ChangeLog

ð  Bug 4796: comm.cc !isOpen(conn->fd) assertion when rotating logs

I also have this problem with Buster package, and have successfully tested it 
corrected in SID package (4.8.1).

Regards,

O. Boursin



Bug#932743: pbuilder: pdebuild --auto-debsign does not sign _source_changes file created after SOURCE_ONLY_CHANGES=yes

2019-11-10 Thread Mattia Rizzolo
Hi,

sorry for not answering earlier.

On Thu, Nov 07, 2019 at 12:51:26PM +0100, Agustin Martin wrote:
> > On Mon, Jul 22, 2019 at 05:48:13PM +0100, James Clarke wrote:
> > > On 22 Jul 2019, at 17:16, Agustin Martin  wrote:
> > > > However, when using pdebuild --auto-debsign to sign files, only .changes
> > > > file is signed, but not its _source.changes counterpart, which is the 
> > > > file
> > > > I would have to upload. This results in pbuilder not creating properly
> > > > uploadable packages once source-only uploads are mandatory for 
> > > > bullseye. 
> > > > This is why I use severity "important".
> 
> I am attaching a minimal patch that just reverses check ordering, trying
> source.changes first and arch.changes later. I have been also playing
> with changes caring about SOURCE_ONLY_CHANGES, but they need more
> ellaboration.

Personally, I think we should just sign them both.
I tend to agree with James in which I don't consider having pdebuild
automatically sign is necessarily good practice, but guess it works in
some cases.  With that, signing both would both not break whoever is
using this in some kind of automatic build system (I can imagine
somebody running pdebuild and then automatically dput somewhere with
binaries).  And, one extra signature shouldn't bother anybody.

I'm using undocumented (yay…) options of debsign to prevent messages
about files already signed (the .dsc and .buildinfo in our case).

Could you please see the following untested patch and share your
opinions?

--- a/pdebuild
+++ b/pdebuild
@@ -110,15 +110,20 @@ fi
 # do signing with optional key specifier
 if [ "${AUTO_DEBSIGN}" = "yes" ]; then
 unset DEBSIGN_PARAM || true
+declare -a DEBSIGN_PARAM
 if [ -n "${DEBSIGN_KEYID}" ]; then
-DEBSIGN_PARAM[1]="-k${DEBSIGN_KEYID}"
+DEBSIGN_PARAM[${#DEBSIGN_PARAM[@]}]="-k${DEBSIGN_KEYID}"
 fi
-if [ -f "${BUILDRESULT}/${CHANGES}" ]; then
-DEBSIGN_PARAM[2]="${BUILDRESULT}/${CHANGES}"
-elif [ -f "${BUILDRESULT}/${SOURCE_CHANGES}" ]; then
-DEBSIGN_PARAM[2]="${BUILDRESULT}/${SOURCE_CHANGES}"
-else
-log.e "the .changes file can't be found, debsign not done"
+DEBSIGN_PARAM[${#DEBSIGN_PARAM[@]}]="--no-re-sign"
+DEBSIGN_PARAM[${#DEBSIGN_PARAM[@]}]="--"
+for file in "$BUILDRESULT/$CHANGES" "$BUILDRESULT/$SOURCE_CHANGES"; do
+if [ -f "$file" ]; then
+DEBSIGN_PARAM[${#DEBSIGN_PARAM[@]}]="$file"
+found=yes
+fi
+done
+if [ -z "${found:-}" ]; then
+log.e "No .changes file(s) can't be found, debsign not done."
 exit 1
 fi
 debsign "${DEBSIGN_PARAM[@]}"


-- 
regards,
Mattia Rizzolo

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


signature.asc
Description: PGP signature


Bug#926915: RFS: fossology/3.5.0-1 [ITP] -- OSS license compliance tool

2019-11-10 Thread Kyle Robbertze
Hi,

I tried building fossology, but it FTBFS wit the following error:

dh_installdirs -s
dh_installdirs: -s/--same-arch has been removed; please use -a/--arch
instead
dh_installdirs: This feature was removed in compat 12.
dh_installdirs: unknown option or error during option parsing; aborting
make: *** [debian/rules:76: install-arch] Error 255
dpkg-buildpackage: error: fakeroot debian/rules binary subprocess
returned exit status 2

dh_installdirs -s is called in your debian/rules line 76.\

I would also suggest removing the commented out commands - they only add
noise to the file.

There are also embedded libraries in ./src/vendor. Are any of these
already in Debian. Can they be packaged separately? If you intend to
keep them embedded, you need to include their licence grants in
debian/copyright.

I see some are licenced under the LGPL, BSD (2 clause) and (3 clause)
and MIT/X11. There are also some source (./src/www/ui/template/,
./src/decider/, etc.) are licenced under FSF All Permissive, which are
missing in the debian/copyright.

In postrm, are you sure you wish to delete the user and group? See [1]
for discussion on the subject.

[1] https://wiki.debian.org/AccountHandlingInMaintainerScripts

Is debian/fossology-common.README.Debian up to date? The comment says
that it is from 2008...

Thanks for your work

Cheers
-- 

⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Kyle Robbertze
⢿⡄⠘⠷⠚⠋⠀ Debian Developer
⠈⠳⣄ https://wiki.debian.org/KyleRobbertze



Bug#926915: RFS: fossology/3.5.0-1 [ITP] -- OSS license compliance tool

2019-11-10 Thread Kyle Robbertze
Further please see the following about unconditionally restarting
apache2 in maintainer scripts.

https://lintian.debian.org/tags/apache2-reverse-dependency-calls-invoke-rc.d.html

Cheers

-- 

⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Kyle Robbertze
⢿⡄⠘⠷⠚⠋⠀ Debian Developer
⠈⠳⣄ https://wiki.debian.org/KyleRobbertze



Bug#931640: webext-ublock-origin: confirmation

2019-11-10 Thread Markus Koschany


Am 10.11.19 um 20:36 schrieb wim:
> Package: webext-ublock-origin
> Version: 1.18.4+dfsg-2
> Followup-For: Bug #931640
> 
> Hello,
> 
> confirmation:
> the extension/addon
> is not active or visible in firefox-esr
> on the installed addons/extensions page

Please disable and reenable the addon and then restart Firefox.

Thanks,

Markus



signature.asc
Description: OpenPGP digital signature


Bug#861876: cups-filters: imagetoraster messes up output

2019-11-10 Thread Brian Potkin
tags 861876 moreinfo
thanks



On Fri 05 May 2017 at 11:37:30 +0200, Karl Beckers wrote:

> unfortunately, I'm not sure what led to the situation. It may have been 
> some dist-upgrade in the past after which I hadn't tried the functionality. 
> 
> I have an image that I scanned and am trying to print via CUPS using splix 
> and tracked down my issues with that to the output of imagetoraster being 
> wrong. 
> 
> The output of scanimage either as a pnm or tiff looks good, here. But when 
> I use imagetoraster and try to process it further it gets printed out 
> distorted.
> If I view the result of imagetoraster with rasterview, it looks distorted 
> already.
> 
> a.out is the original image as scanned
> b.out is the result of imagetoraster created like this:
> cat /scratch/a.out | /usr/lib/cups/filter/imagetoraster - - "copy button 
> pressed" 1 - > /scratch/b.out

Thank you for your report, Karl.

You appear to have done everything right here, but would you test again
on a testing/unstable installation, preferably with a different scanned
image.

Thanks,

Brian.



Bug#944489: Info received (Bug#944489: Acknowledgement (dietlibc: FTBFS on new hppa kernels - Invalid setsockopt argument))

2019-11-10 Thread John David Anglin
The following change fixes the setsockopt problem.

I also hacked unified.S.  Implicit space register selection should be used in 
the
loads and stores.

Dave

--- /dev/null   2019-11-08 20:11:47.96000 -0500
+++ __setsockopt.S  2019-11-10 14:25:58.291898985 -0500
@@ -0,0 +1,3 @@
+#include "syscalls.h"
+
+syscall5_weak(setsockopt, setsockopt, __libc_setsockopt);
--- setsockopt.S2019-11-10 14:48:34.979705577 -0500
+++ /dev/null   2019-11-08 20:11:47.96000 -0500
@@ -1,3 +0,0 @@
-#include "syscalls.h"
-
-syscall5(setsockopt, setsockopt);
--- unified.S.save  2019-11-10 14:44:32.131897343 -0500
+++ unified.S   2019-11-10 13:26:15.216075262 -0500
@@ -42,9 +42,9 @@
nop

 __unified_syscall6:
-   ldw -0x38(%sr0, %sp), %r21
+   ldw -0x38(%sp), %r21
 __unified_syscall5:
-   ldw -0x34(%sr0, %sp), %r22
+   ldw -0x34(%sp), %r22
 __unified_syscall:
be,l 0x100(%sr2, %r0), %sr0, %r31
nop
@@ -56,12 +56,12 @@
copy %r2, %r23
bl __errno_location, %r2
copy %ret0, %r20
-   stw %r20, 0(%sr0, %ret0)
+   stw %r20, 0(%ret0)
copy %r23, %r2
 #else
ldil LP%errno, %r26
ldo  RP%errno(%r26), %r26
-   stw  %ret0, 0(%r0, %r26)
+   stw  %ret0, 0(%r26)
 #endif
ldi -1, %ret0
 .Lnoerr:



Bug#943667: python-oslo.messaging 8.1.4-1+deb10u1 flagged for acceptance

2019-11-10 Thread Adam D Barratt
package release.debian.org
tags 943667 = buster pending
thanks

Hi,

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

Thanks for your contribution!

Upload details
==

Package: python-oslo.messaging
Version: 8.1.4-1+deb10u1

Explanation: new upstream stable release; fix switch connection destination 
when a rabbitmq cluster node disappears



Bug#939166: node-fstream 1.0.10-1+deb10u1 flagged for acceptance

2019-11-10 Thread Adam D Barratt
package release.debian.org
tags 939166 = buster pending
thanks

Hi,

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

Thanks for your contribution!

Upload details
==

Package: node-fstream
Version: 1.0.10-1+deb10u1

Explanation: fix arbitrary file overwrite issue [CVE-2019-13173]



Bug#931640: webext-ublock-origin: confirmation

2019-11-10 Thread wim
Package: webext-ublock-origin
Version: 1.18.4+dfsg-2
Followup-For: Bug #931640

Hello,

confirmation:
the extension/addon
is not active or visible in firefox-esr
on the installed addons/extensions page

hth,
Wim

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

Kernel: Linux 5.2.0-0.bpo.3-amd64 (SMP w/16 CPU cores)
Locale: LANG=nl_BE.UTF-8, LC_CTYPE=nl_BE.UTF-8 (charmap=UTF-8), 
LANGUAGE=nl_BE:nl (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

webext-ublock-origin depends on no packages.

Versions of packages webext-ublock-origin recommends:
ii  firefox-esr  68.2.0esr-1~deb10u1

Versions of packages webext-ublock-origin suggests:
pn  ublock-origin-doc  

-- no debconf information



Bug#944489: Acknowledgement (dietlibc: FTBFS on new hppa kernels - Invalid setsockopt argument)

2019-11-10 Thread John David Anglin
I think the issue is caused by __setsockopt.o:

__setsockopt.o:
 T __libc_setsockopt
 U __unified_syscall
 W setsockopt

which appears before

setsockopt.o:
 U __unified_syscall5
 T setsockopt

-- 
John David Anglin  dave.ang...@bell.net



Bug#906083: nosexcover: Python2 removal in sid/bullseye, python3-nosexcover shouldn't depend on python-nose and python-coverage

2019-11-10 Thread Bálint Réczey
Control: tags -1 pending

Hi,

I have uploaded the attached fix to DELAYED/5.

Cheers,
Balint
diff -Nru nosexcover-1.0.11/debian/changelog nosexcover-1.0.11/debian/changelog
--- nosexcover-1.0.11/debian/changelog	2018-05-02 09:21:57.0 +0200
+++ nosexcover-1.0.11/debian/changelog	2019-11-10 18:07:13.0 +0100
@@ -1,3 +1,11 @@
+nosexcover (1.0.11-1.2) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Drop Python 2 dependencies, build-dependencies and binary package
+(Closes: #937159, #906083)
+
+ -- Balint Reczey   Sun, 10 Nov 2019 18:07:13 +0100
+
 nosexcover (1.0.11-1.1) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru nosexcover-1.0.11/debian/control nosexcover-1.0.11/debian/control
--- nosexcover-1.0.11/debian/control	2018-05-02 09:21:57.0 +0200
+++ nosexcover-1.0.11/debian/control	2019-11-10 18:07:13.0 +0100
@@ -4,32 +4,16 @@
 Maintainer: Guido Günther 
 Build-Depends: debhelper (>= 10.0.0~),
  dh-python,
- python-all,
- python3,
- python-nose,
+ python3-all,
  python3-nose,
- python-setuptools,
  python3-setuptools,
 Standards-Version: 4.1.1
 Homepage: http://pypi.python.org/pypi/nosexcover
 
-Package: python-nosexcover
-Architecture: all
-Depends: ${misc:Depends},
- ${python:Depends}, python-nose, python-coverage (>= 3.4)
-Description: Add Cobertura-style XML coverage report to nose (Python2 version)
- A companion to the built-in nose.plugins.cover, this plugin will write
- out an XML coverage report to a file named coverage.xml.
- .
- It will honor all the options you pass to the Nose coverage plugin,
- especially --cover-package.
- .
- This package contains the Python 2 version of the module.
-
 Package: python3-nosexcover
 Architecture: all
 Depends: ${misc:Depends},
- ${python3:Depends}, python-nose, python-coverage (>= 3.4)
+ ${python3:Depends}, python3-nose, python3-coverage (>= 3.4)
 Description: Add Cobertura-style XML coverage report to nose (Python3 version)
  A companion to the built-in nose.plugins.cover, this plugin will write
  out an XML coverage report to a file named coverage.xml.
diff -Nru nosexcover-1.0.11/debian/python3-nosexcover.install nosexcover-1.0.11/debian/python3-nosexcover.install
--- nosexcover-1.0.11/debian/python3-nosexcover.install	2015-02-19 13:02:36.0 +0100
+++ nosexcover-1.0.11/debian/python3-nosexcover.install	1970-01-01 01:00:00.0 +0100
@@ -1 +0,0 @@
-usr/lib/python3.?
diff -Nru nosexcover-1.0.11/debian/python-nosexcover.install nosexcover-1.0.11/debian/python-nosexcover.install
--- nosexcover-1.0.11/debian/python-nosexcover.install	2015-02-19 13:02:32.0 +0100
+++ nosexcover-1.0.11/debian/python-nosexcover.install	1970-01-01 01:00:00.0 +0100
@@ -1 +0,0 @@
-usr/lib/python2.?
diff -Nru nosexcover-1.0.11/debian/rules nosexcover-1.0.11/debian/rules
--- nosexcover-1.0.11/debian/rules	2015-02-19 13:37:49.0 +0100
+++ nosexcover-1.0.11/debian/rules	2019-11-10 18:07:13.0 +0100
@@ -1,4 +1,4 @@
 #!/usr/bin/make -f
 
 %:
-	dh $@ --with python2,python3 --buildsystem=pybuild
+	dh $@ --with python3 --buildsystem=pybuild


Bug#857870: cups-filters: unused lp modules are still loaded if /etc/default/cups does not exist

2019-11-10 Thread Brian Potkin
On Sun 10 Nov 2019 at 17:53:58 +, Brian Potkin wrote:

> Please would you do the following, preferably on an unstable/testing
> installation:
> 
> 1. Comment out the entries in /etc/modules-load.d/cups-filters.conf.
> 
> 2. Reboot without a parallel port printer attached to the machine.
> 
> 3. Do 'lsmod | grep parport' and 'lsmod | grep lp' and report on which
>modules are loaded by the kernel.
> 
> 4. Attach a parallel port printer, switch it on  and report on the output
>of 'lsmod | grep lp'
> 
> 5. Give the kernel version used ('uname -a').

After following my own advice I find that parport_pc and ppdev are
loaded. lp doesn't get loaded, even when the printer is attached.

It seems to me that the ppdev and parport_pc lines in cups-filters.conf
are superfluous with kernel 5.3.0-1. Whether the lp module should be
loaded for everyone is a decision I leave to someone else.

Cheers,

Brian.



Bug#565626: Investment Proposal

2019-11-10 Thread Nael M. Al Homoud
Good day,

My associate from China wants to discuss a business investment deal with
you. I awaiting your response to enable us discuss about this business
investment

Nael M. Al Homoud
Executive Director & High Investment Committee Member@
The Arab Investment Co
www.taic.com [1]

  

Links:
--
[1] http://www.taic.com

Bug#937665: fixed in python-coverage 4.5.2+dfsg.1-2

2019-11-10 Thread Ben Finney
Control: reopen -1
Control: tags -1 + pending

On 10-Nov-2019, Sandro Tosi wrote:
> please restore python-coverage, it has still plenty of rdeps,
> http://sandrotosi.me/debian/py2removal/python-coverage_1.svg

You're right! I prepared the release for removing Python 2 binary
packages, and then waited; but later uploaded it by mistake.

I will make a new release to restore those binary packages.

-- 
 \“You can't have everything; where would you put it?” —Steven |
  `\Wright |
_o__)  |
Ben Finney 

signature.asc
Description: PGP signature


Bug#942106: python3.8 / pandas py2removal

2019-11-10 Thread Rebecca N. Palmer

I have uploaded pandas and statsmodels.

On 10/11/2019 14:18, Matthias Klose wrote:

https://people.debian.org/~doko/tmp/


The patsy one has a bug: as debian/tests/nosetests3 was a symlink to 
nosetests2, it should have deleted this link and renamed nosetests2 to 
nosetests3, not deleted nosetests2.




Bug#944494: jami aborts when the media sub-menu is entered from the settings menu

2019-11-10 Thread Alexander Necheff
Package: jami
Version: 20190215.1.f152c98~ds1-1

When selecting the Settings gear menu, then selecting the Media sub-menu,
jami displays the Media settings menu momentarily and then aborts.

Running jami from the command line and performing these steps shows the
following messages:

"
(jami:9721): libnotify-WARNING **: 13:34:45.148: Failed to connect to proxy
QDBusMarshaller: type `VectorString' attempts to redefine basic D-BUS type
'as' (QStringList) (Did you forget to call beginStructure() ?)
QDBusMarshaller: type `MapStringVectorString' produces invalid D-BUS
signature `a{s}' (Did you forget to call beginStructure() ?)
QDBusMarshaller: type `QMap' produces
invalid D-BUS signature `a{s}' (Did you forget to call beginStructure() ?)

(jami:9721): Gtk-CRITICAL **: 13:34:45.463: gtk_scrolled_window_add:
assertion 'child_widget == NULL' failed
No profile selected or none exists
could not open shm area "" , shm_open failed: Invalid argument
QObject: Cannot create children for a parent that is in a different thread.
(Parent is Video::ShmRenderer(0x55fb8e2c2980), parent's thread is
QThread(0x55fb8dfcb7d0), current thread is QThread(0x55fb8dd62b70)
Terminated
"

I am running Debian 10.1, using kernel "4.19.0-6-amd64 #1 SMP Debian
4.19.67-2+deb10u1", and glibc "ldd (Debian GLIBC 2.28-10) 2.28".

I am assuming that "could not open shm area "" , shm_open failed: Invalid
argument" is the critical message here. Though, I have confirmed that
/dev/shm is mounted with the df command, but it appears empty with an ls
-la.

I do not explicitly mount /dev/shm in /etc/fstab; but, it seems like
systemd is supposed to automatically take care of this now? At least
according to the Arch Wiki.


Bug#944124: apt fails to verify certificate when using https and ocsp stapling

2019-11-10 Thread Andreas Metzler
On 2019-11-09 David Kalnischkies  wrote:
> On Mon, Nov 04, 2019 at 05:49:53PM +0100, Robert Senger wrote:
>> We are running several debian repositories for custom kernel and
>> patched deb packages. We use apache2 on Buster, with https enabled,
>> to serve the repos.
>> 
>> This worked fine, until we decided to enable ocsp stapling in
>> apache2, which runs other vhosts besides the repos.
>> 
>> Since then, apt fails to validate the server's certificate. Error
>> message is:
>> 
>> Fehl:15 https://microscopium.de/repos/apt/debian/common buster/patched 
>> Release
>>   Certificate verification failed: The certificate is NOT trusted.
>>   The received OCSP status response is invalid.  Could not
>>   handshake: Error in the certificate verification. [IP:
>>   fd10:2842:f0d1:101:222:4dff:feb8:17c 8000]
>> 
>> Restarting apache2 helps for a while (apt works, at least once), but
>> the error comes up again when apt is run later.

> The (part of the) error message is from libgnutls30:
> | The certificate is NOT trusted. The received OCSP status response is 
> invalid.
> and is the stringyified GNUTLS_E_CERTIFICATE_VERIFICATION_ERROR error returned
> by gnutls_handshake.

Hello,

currently gnutls-cli connects successfully.
I think it is very fishy that restarting the server lets apt succeed for
some time.

> apts https method is a thin gnutls-powered wrapper around our http method, the
> code lives in the TlsFd struct and the UnwrapTLS method, both here:
> https://salsa.debian.org/apt-team/apt/blob/master/methods/connect.cc#L802

> As you can see, we have no code dealing with OCSP directly and we do
> not keep state ourselves by caching responses or some such, so I am
> completely at a lose what apt could be doing wrong here or how its
> behaviour would change over multiple runs.

> So it is either a bug in gnutls or in how we use it; in both cases I hope the
> gnutls maintainers can shine some light on the issue better than I could and
> hence I reassign to them.

GnuTLS is supposed to handle OCSP stapling transparently, without special
client code.
https://gnutls.org/manual/gnutls.html#index-OCSP-stapling
| Since GnuTLS 3.5.1 the client certificate verification will consider
| the [RFC7633] OCSP-Must-staple certificate extension, and will consider
| it while checking for stapled OCSP responses. If the extension is
| present and no OCSP staple is found, the certificate verification will
| fail and the status code GNUTLS_CERT_MISSING_OCSP_STATUS will returned
| from the verification function. 

The apt code seems to be basically ex-client-x509.c
https://gnutls.org/manual/gnutls.html#Client-example-with-X_002e509-certificate-support
however ex-client-x509.c can connect to / verify the example host.

I have not tried apt. But if it really does not succeed finding the
difference to ex-client-x509.c should help.

>> All web tools tell us that certificate installation and ocsp
>> stapling are correct. No other problems with other https clients
>> have been observed so far.

[...]
> It might also help if you could provide a public testcase as
[...]

AFAIUI microscopium.de is a public testcase.

cu Andreas

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



Bug#944493: Please disable parallel install

2019-11-10 Thread Florian Weimer
Package: src:ghc
Version: 8.8.1+dfsg1+is+8.6.5+dfsg1-2

Something like this seems to be needed because the install target does
not ensure that directories are created before files that are
installed into them:

diff -Nru ghc-8.8.1+dfsg1+is+8.6.5+dfsg1/debian/rules 
ghc-8.8.1+dfsg1+is+8.6.5+dfsg1/debian/rules
--- ghc-8.8.1+dfsg1+is+8.6.5+dfsg1/debian/rules 2019-09-21 12:06:31.0 
+0200
+++ ghc-8.8.1+dfsg1+is+8.6.5+dfsg1/debian/rules 2019-11-10 19:03:00.0 
+0100
@@ -174,7 +174,7 @@
 PROF_FILE = \( -name "*.p_*" -o -name "lib*_p.a" \)
 
 override_dh_auto_install:
-   dh_auto_install
+   dh_auto_install --no-parallel
 
# Delete all the library LICENSE files
rm -f debian/tmp/usr/share/doc/ghc-doc/html/libraries/*/LICENSE

I saw a build failure due to a missing debian/tmp/usr/bin directory
when symlinking haddock, and after the change above, it was gone.



Bug#944492: RFS: dav-text/0.9.0-1 -- minimalist ncurses-based text editor

2019-11-10 Thread Adam Bilbrough
Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "dav-text"

 * Package name: dav-text
   Version : 0.9.0-1
   Upstream Author : Adam Bilbrough 
 * URL : https://github.com/atsb/dav-text
 * License : GPLv2
 * Vcs : None
   Section : text

It builds those binary packages:

  dav-text - minimalist ncurses-based text editor

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

  https://mentors.debian.net/package/dav-text

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

  dget -x 
https://mentors.debian.net/debian/pool/main/d/dav-text/dav-text_0.9.0-1.dsc

Changes since the last upload:

   * New upstream release.
   * Tested using boundary value analysis, no longer appears (closes: #715788)

Regards,

--
  Adam Bilbrough



Bug#944258: lintian 2.32.0~bpo9+1 in stretch-backports depends on coreutils (>= 8.30), but stretch has only 8.26-3

2019-11-10 Thread Chris Lamb
tags 944258 + pending
thanks

Felix,

> Was this not resolved by the following?

I didn't see this commit; I likely assumed you would followup to the
bug explicitly and the lack of automatic "pending" is likely due to
"(Closes #944258)" vs. "(Closes: #944258)" with the colon. No matter,
doing it manually above - these things happen.

> Or, do I need to backport the patch to that specific version?

If you mean backport it to that particular branch... then no; we just
need to do a regular backport upload. I do that after its migrated to
testing to follow the rules, so we are a few days off this landing in
stretch alas. (As in; I need to do an unstable upload first that
includes this commit and let that migrate...)


Regards,

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



Bug#944491: firmware-iwlwifi: firmware does not load with error -110 with Intel 7260

2019-11-10 Thread Christophe Garion
Package: firmware-iwlwifi
Version: 20190717-2
Severity: grave

Dear Maintainer,

After upgrading to the 5.2.0-3 kernel, module iwlwifi cannot be loaded
as there is an error in the microcode. Here are the related kernel.log
messages:

[   12.689939] iwlwifi :3d:00.0: Failed to load firmware chunk!
[   12.690990] iwlwifi :3d:00.0: iwlwifi transaction failed, dumping 
registers
[   12.692217] iwlwifi :3d:00.0: iwlwifi device config registers:
[   12.693323] iwlwifi :3d:00.0: : 08b18086 00100406 0280006b 
0010 d014   
[   12.695108] iwlwifi :3d:00.0: 0020:    
c0608086  00c8  0100
[   12.696916] iwlwifi :3d:00.0: iwlwifi device memory mapped registers:
[   12.698169] iwlwifi :3d:00.0: : 40489204 8040 2000 
0800    
[   12.699981] iwlwifi :3d:00.0: 0020: 0009 080003c5 0144 
 8000 803a 80008040 00080046
[   12.701777] iwlwifi :3d:00.0: iwlwifi device AER capability structure:
[   12.703006] iwlwifi :3d:00.0: : 14010001 4000  
00462031 2000 2000 000e 
[   12.703861] iwlwifi :3d:00.0: 0020:   
[   12.704382] iwlwifi :3d:00.0: iwlwifi parent port (:3c:01.0) config 
registers:
[   12.704921] iwlwifi :3c:01.0: : 240412d8 00180407 06040005 
00010010   003d3d3c 01f1
[   12.705580] iwlwifi :3c:01.0: 0020: d010d010 0001fff1  
  0040  0002010a
[   12.706300] iwlwifi :3d:00.0: Could not load the [0] uCode section
[   12.706786] iwlwifi :3d:00.0: Failed to start INIT ucode: -110
[   12.707189] iwlwifi :3d:00.0: Collecting data: trigger 16 fired.
[   12.954147] iwlwifi :3d:00.0: Not valid error log pointer 0x for 
Init uCode
[   12.954692] iwlwifi :3d:00.0: Fseq Registers:
[   12.954710] iwlwifi :3d:00.0: Hardware error detected.  Restarting.
[   12.955004] iwlwifi :3d:00.0: 0x | FSEQ_ERROR_CODE
[   12.955813] iwlwifi :3d:00.0: 0x | FSEQ_TOP_INIT_VERSION
[   12.956215] iwlwifi :3d:00.0: 0x | FSEQ_CNVIO_INIT_VERSION
[   12.956627] iwlwifi :3d:00.0: 0x | FSEQ_OTP_VERSION
[   12.957002] iwlwifi :3d:00.0: 0x | FSEQ_TOP_CONTENT_VERSION
[   12.957420] iwlwifi :3d:00.0: 0x | FSEQ_ALIVE_TOKEN
[   12.957795] iwlwifi :3d:00.0: 0x | FSEQ_CNVI_ID
[   12.958208] iwlwifi :3d:00.0: 0x | FSEQ_CNVR_ID
[   12.958569] iwlwifi :3d:00.0: 0x | CNVI_AUX_MISC_CHIP
[   12.958964] iwlwifi :3d:00.0: 0x | CNVR_AUX_MISC_CHIP
[   12.959359] iwlwifi :3d:00.0: 0x | 
CNVR_SCU_SD_REGS_SD_REG_DIG_DCDC_VTRIM
[   12.959865] iwlwifi :3d:00.0: 0x | 
CNVR_SCU_SD_REGS_SD_REG_ACTIVE_VDIG_MIRROR
[   12.960407] iwlwifi :3d:00.0: Firmware not running - cannot dump error
[   12.979731] iwlwifi :3d:00.0: Failed to run INIT ucode: -110

The firmware works perfectly with a 4.19 kernel.

Notice that this is surely related to
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=939262, but as I have
an unreported error (Failed to run INIT ucode: -110), I have submitted a
new bug report.

Notice also that manually installing 20190815 version does not solve the
problem.

Best,

Christophe

-- System Information:
Debian Release: bullseye/sid
  APT prefers testing
  APT policy: (986, 'testing'), (984, 'stable'), (982, 'stable'), (98, 
'unstable'), (96, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

firmware-iwlwifi depends on no packages.

firmware-iwlwifi recommends no packages.

Versions of packages firmware-iwlwifi suggests:
ii  initramfs-tools  0.135

-- no debconf information



Bug#913080: profanity: please provide a package for stretch-backports

2019-11-10 Thread Jonas Meurer
Package: profanity
Version: 0.7.1-1
Followup-For: Bug #913080

Hello,

I as well would be interested in a backport of latest profanity (0.7.1-1). With
version 0.7.0, profanity got OMEMO support added. Now that Buster is the stable
Debian release, would you be willed to upload profanity to buster-backports?

If you're not interested, then I could take care of the backport.

Cheers
 jonas



Bug#944258: lintian 2.32.0~bpo9+1 in stretch-backports depends on coreutils (>= 8.30), but stretch has only 8.26-3

2019-11-10 Thread Felix Lechner
Hi Chris,

On Sun, Nov 10, 2019 at 10:06 AM Chris Lamb  wrote:
>
> Felix, can you do the "honours" here?

Was this not resolved by the following?


https://salsa.debian.org/lintian/lintian/commit/33bd1434f0c160770a26bea55328e5bf7545322f

As you can see, I marked the bug as closed. The BTS never switched to
pending, presumably due to the version restriction via 'found'.

Or, do I need to backport the patch to that specific version?

Kind regards,
Felix Lechner



Bug#944490: Multiple errors that make the package unusable

2019-11-10 Thread Gilles MOREL
Package: postfixadmin
Version: 3.2.1-2
Severity: important

Hello,

I installed the postfixadmin package on Debian 10, but when I try to use it, 
there are several mistakes that make the package unusable.

The first is the alias in the apache configuration that makes show a error on 
the index page:
The Postfix Admin directory layout changed.
Please update your webserver config so that the DocumentRoot or Alias points to 
the directory "public".

The second is when I correct the first by going to public subdirectory :
ERROR: the templates_c directory doesn't exist or isn't writeable for the 
webserver
Doing a "mkdir -m 0777 /usr/share/postfixadmin/templates_c" (ugly), I correct 
the error, and then.

The third is that:
DEBUG INFORMATION:
MySQL 3.x / 4.0 functions not available! (php5-mysql installed?)
database_type = 'mysql' in config.inc.php, are you using a different database?
The database is actually a mysql database and the packaage php-mysql is 
installed (because postfixadmin depends on it), but the php5-mysql package is 
not available.

I can't go any futher because I don't know how to resolve this error.
--
Gilles MOREL 
Le hasard a fait que ce message vient de mon téléphone portable. Curieux, non ?



Bug#940726: linux-source-5.2: Enable SOF audio driver and back-port fixes required to 5.2 kernel

2019-11-10 Thread David Ward
Unfortunately, this has caused a regression. The SST and SOF drivers 
cannot both be enabled for the same Intel platform in the kernel 
configuration, according to Intel. 
https://bugzilla.kernel.org/show_bug.cgi?id=204237#c15


As described in the bug, this change causes a loss of sound on the Intel 
Broadwell platform (and even significantly degrades system performance 
when attempting to play sound).




Bug#795186: portsentry is starting too early

2019-11-10 Thread Winston Sorfleet
On Tue, 2 Jan 2018 09:46:09 -0700 TheSin  wrote:
> This bug is really old and really annoying, is there any plans at all
on fixing portsentry to start later?
>
> Currently snmp has a race condition and will start after portsentry
50% of the time, cyrus and dovecot also have a race condition and start
after it some of the time. Obviously this is less then optimal as it
means some servers won’t come back up properly on reboot or power
failure and manual intervention is required, log in turn off portsentry,
start the service that where late, restart portsentry.
>
> Could this issue me looked at? Or at least acknowledged since it’s
going on 3 years old now.

>


Confirmed this is *still* happening on Debian 10 on boot.  The manual
workaround as stated by TheSin is to systemctl stop portsentry;
systemctl (re)start snmpd; systemctl start portsentry.  This is hardly
fatal but as TheSin writes, really annoying.



Bug#857870: cups-filters: unused lp modules are still loaded if /etc/default/cups does not exist

2019-11-10 Thread Brian Potkin
On Sun 10 Nov 2019 at 17:53:58 +, Brian Potkin wrote:

> tags 857870 moreinfo
> thanks

I received:

  This message was created automatically by mail delivery software.
  A message that you sent could not be delivered to one or more of its
  recipients. This is a permanent error. The following address(es) failed:

   a...@bootes.telenet.ru
   Unrouteable address

-- 
Brian.



Bug#944489: dietlibc: FTBFS on new hppa kernels - Invalid setsockopt argument

2019-11-10 Thread John David Anglin
Source: dietlibc
Version: 0.34~cvs20160606-11
Severity: normal

Dear Maintainer,

The testsuite fails with the following errors:

RUN ERROR for debian/unittests/socketfns.c in variant bare (rc = 1), test 
output is:

parent: setsockopt: Invalid argument



RUN ERROR for debian/unittests/socketfns.c in variant pthreads (rc = 1), test 
output is:

parent: setsockopt: Invalid argument


make[1]: *** [debian/rules:100: override_dh_auto_test-arch] Error 1

Full bulild log is here:
https://buildd.debian.org/status/fetch.php?pkg=dietlibc=hppa=0.34%7Ecvs20160606-11=1572208826=0

I believe the syscall argument setup is wrong for the 5th and 6th arguments.
In a syscall, these arguments are passed in registers %r22 ans %r21,
respectively.  However, these arguments are passed on the stack in the
32-bit Linux runtime.  So, we have the following code for the setsockopt
call:

=> 0x00010430 : ldo f4(r3),r20
   0x00010434 : ldo -20(sp),ret0
   0x00010438 : ldo -14(ret0),ret0
   0x0001043c : ldi 4,r19
   0x00010440 : stw r19,0(ret0)
   0x00010444 : copy r20,r23
   0x00010448 : ldi 1002,r24
   0x0001044c : depwi,z -1,31,16,r25
   0x00010450 : ldo 0(r3),ret0
   0x00010454 : ldo -24(ret0),ret0
   0x00010458 : ldw 0(ret0),r26
   0x0001045c : b,l 0x11354 ,rp
   0x00010460 : nop

The sizeof(optlen) argument is stored to the stack in the instruction
at 0x00010440.

(gdb) disass
Dump of assembler code for function setsockopt:
=> 0x00011354 <+0>: b,l 0x112cc <__unified_syscall>,r0
   0x00011358 <+4>: ldi b5,r20

__unified_syscall () at parisc/unified.S:49
49  parisc/unified.S: No such file or directory.
(gdb) disass
Dump of assembler code for function __unified_syscall:
=> 0x000112cc <+0>: be,l 100(sr2,r0),sr0,r31
   0x000112d0 <+4>: nop
   0x000112d4 <+8>: ldi -100,r1
   0x000112d8 <+12>:cmpb,>>=,n r1,ret0,0x112f8 
   0x000112dc <+16>:sub r0,ret0,ret0

So, the 5th argument to the setsockopt call never gets loaded into %r22.

The test program works when glibc is used.

Regards,
Dave Anglin


-- System Information:
Debian Release: bullseye/sid
  APT prefers buildd-unstable
  APT policy: (500, 'buildd-unstable'), (500, 'unstable')
Architecture: hppa (parisc64)

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



Bug#944258: lintian 2.32.0~bpo9+1 in stretch-backports depends on coreutils (>= 8.30), but stretch has only 8.26-3

2019-11-10 Thread Chris Lamb
Hi,

> lintian 2.32.0~bpo9+1 in stretch-backports depends on coreutils
> (>= 8.30), but stretch has only 8.26-3

I'd like to resolve this issue and as a new upload of coreutils seems
to be neither warranted, 100% essential and (practically-speaking)
forthcoming, I would request that we do whatever we need to do to weaken
this dependency. Felix, can you do the "honours" here?


Regards,

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



Bug#944478: suboptimal handling of tmpfiles if dh_installsystemd is called multiple times

2019-11-10 Thread Michael Biebl
Am 10.11.19 um 17:48 schrieb Michael Biebl:
> Package: debhelper
> Version: 12.7.1
> Severity: normal
> 
> Hi,
> 
> I'm currently working on updating the debhelper compat level in systemd
> from 10 to 12:
> 
> https://salsa.debian.org/systemd-team/systemd/commits/wip/compat-12


I renamed that branch to
https://salsa.debian.org/systemd-team/systemd/commits/biebl/compat-12


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature


Bug#857870: cups-filters: unused lp modules are still loaded if /etc/default/cups does not exist

2019-11-10 Thread Brian Potkin
tags 857870 moreinfo
thanks



On Thu 16 Mar 2017 at 01:11:11 +0500, Alex Volkov wrote:

> postinst script analyzes the presence of lp, parport etc. modules only if the 
> legacy /etc/default/cups is in place. If there isn't, provided cups-
> modules.conf is used regardless of the fact whether the modules are needed or 
> even available. 

Hello Alex,

Please would you do the following, preferably on an unstable/testing
installation:

1. Comment out the entries in /etc/modules-load.d/cups-filters.conf.

2. Reboot without a parallel port printer attached to the machine.

3. Do 'lsmod | grep parport' and 'lsmod | grep lp' and report on which
   modules are loaded by the kernel.

4. Attach a parallel port printer, switch it on  and report on the output
   of 'lsmod | grep lp'

5. Give the kernel version used ('uname -a').

Thanks,

Brian.



Bug#944488: dirvish: Please include btrfs patch

2019-11-10 Thread Markus Grunwald
Package: dirvish
Version: 1.2.1-1.3
Severity: wishlist

Dear Maintainer,

please consider including this patch which adds an option to use the
benefits of btrfs for dirvish:

http://dirvish.org/pipermail/dirvish/2010-December/002357.html

The patch was not accepted, it seems, in 2010 because btrfs was not
mature at all. This situation has changed and the patch would improve
dirvish's performance very much.

Thank you,
Markus


-- System Information:
Debian Release: 9.11
  APT prefers oldstable-updates
  APT policy: (996, 'oldstable-updates'), (996, 'oldstable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.9.0-11-amd64 (SMP w/4 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: sysvinit (via /sbin/init)

Versions of packages dirvish depends on:
ii  libtime-modules-perl  2015.103-2
ii  libtime-period-perl   1.20-8.2
ii  perl  5.24.1-3+deb9u5
ii  perl-modules-5.24 [perl-modules]  5.24.1-3+deb9u5
ii  rsync 3.1.2-1+deb9u2

Versions of packages dirvish recommends:
ii  ssh  1:7.4p1-10+deb9u7

dirvish suggests no packages.

-- Configuration Files:
/etc/cron.d/dirvish changed [not included]
/etc/dirvish/dirvish-cronjob changed [not included]

-- no debconf information



Bug#944487: dirvish: Please fix "Homepage" field of the dpkg

2019-11-10 Thread Markus Grunwald
Package: dirvish
Version: 1.2.1-1.3
Severity: minor

Dear Maintainer,

apt-cache show dirvish | grep Homepage:
Homepage: http://freecode.com/projects/dirvish

That homepage is outdated. It seems http://dirvish.org/ is the correct
one.

cu
Markus

-- System Information:
Debian Release: 9.11
  APT prefers oldstable-updates
  APT policy: (996, 'oldstable-updates'), (996, 'oldstable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.9.0-11-amd64 (SMP w/4 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: sysvinit (via /sbin/init)

Versions of packages dirvish depends on:
ii  libtime-modules-perl  2015.103-2
ii  libtime-period-perl   1.20-8.2
ii  perl  5.24.1-3+deb9u5
ii  perl-modules-5.24 [perl-modules]  5.24.1-3+deb9u5
ii  rsync 3.1.2-1+deb9u2

Versions of packages dirvish recommends:
ii  ssh  1:7.4p1-10+deb9u7

dirvish suggests no packages.

-- Configuration Files:
/etc/cron.d/dirvish changed [not included]
/etc/dirvish/dirvish-cronjob changed [not included]

-- no debconf information



Bug#944486: libtrilinos-belos-dev: missing Breaks+Replaces: libtrilinos-muelu-dev (<< 12.14)

2019-11-10 Thread Andreas Beckmann
Package: libtrilinos-belos-dev
Version: 12.14.1-1
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package fails to upgrade from
'testing'.
It installed fine in 'testing', then the upgrade to 'sid' fails
because it tries to overwrite other packages files without declaring a
Breaks+Replaces relation.

See policy 7.6 at
https://www.debian.org/doc/debian-policy/ch-relationships.html#overwriting-files-and-replacing-packages-replaces

>From the attached log (scroll to the bottom...):

  Preparing to unpack .../libtrilinos-belos-dev_12.14.1-1_amd64.deb ...
  Unpacking libtrilinos-belos-dev:amd64 (12.14.1-1) ...
  dpkg: error processing archive 
/var/cache/apt/archives/libtrilinos-belos-dev_12.14.1-1_amd64.deb (--unpack):
   trying to overwrite '/usr/include/trilinos/BelosOperatorT.hpp', which is 
also in package libtrilinos-muelu-dev:amd64 12.12.1-8
  Errors were encountered while processing:
  dpkg-deb: error: paste subprocess was killed by signal (Broken pipe)
   /var/cache/apt/archives/libtrilinos-belos-dev_12.14.1-1_amd64.deb


cheers,

Andreas


libtrilinos-muelu-dev=12.12.1-8_libtrilinos-belos-dev=12.14.1-1.log.gz
Description: application/gzip


Bug#944485: mmdebstrap: please implement the creation of QEMU/KVM images for autopkgtest-virt-qemu

2019-11-10 Thread Francesco Poli (wintermute)
Package: mmdebstrap
Version: 0.5.1-2
Severity: wishlist

Hello and thanks for developing/packaging this tool!

I wonder whether it can be used to create (without superuser privileges!)
a QEMU/KVM image.
I am especially interested in QEMU/KVM images suitable as autopkgtest
testbeds (autopkgtest-virt-qemu), but the feature could perhaps be
useful for building other minimal Debian base QEMU/KVM images as well...

As you most probably know, autopkgtest-build-qemu uses vmdb2 under the
hood, and vmdb2 [requires] to be run as root. I wonder whether mmdebstrap
can be used in stead of vmdb2, in order to lift the superuser privilege
requirement.

[requires]: 

Could this feature be implemented? It would really be awesome to have
a tool that allows a regular user to create a QEMU/KVM minimal Debian
image...

Please let me know your thoughts!
Thanks for your time and patience.
Bye.



Bug#944484: siril-common: missing Breaks+Replaces: siril (<< 0.9.12)

2019-11-10 Thread Andreas Beckmann
Package: siril-common
Version: 0.9.12-1
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package fails to upgrade from
'testing'.
It installed fine in 'testing', then the upgrade to 'sid' fails
because it tries to overwrite other packages files without declaring a
Breaks+Replaces relation.

See policy 7.6 at
https://www.debian.org/doc/debian-policy/ch-relationships.html#overwriting-files-and-replacing-packages-replaces

>From the attached log (scroll to the bottom...):

  Preparing to unpack .../siril-common_0.9.12-1_all.deb ...
  Unpacking siril-common (0.9.12-1) ...
  dpkg: error processing archive 
/var/cache/apt/archives/siril-common_0.9.12-1_all.deb (--unpack):
   trying to overwrite '/usr/share/doc/siril/AUTHORS', which is also in package 
siril 0.9.11-1+b3
  dpkg-deb: error: paste subprocess was killed by signal (Broken pipe)
  Errors were encountered while processing:
   /var/cache/apt/archives/siril-common_0.9.12-1_all.deb


cheers,

Andreas


siril=0.9.11-1+b3_siril-common=0.9.12-1.log.gz
Description: application/gzip


Bug#931309: Multiple security issues (CVE-2018-14449..14459, CVE-2018-18192..18197)

2019-11-10 Thread Markus Koschany
Hello libgig maintainers and security team,

I have verified that all CVE still affect the latest version in Debian.
Most of them just lead to a denial of service (application crash).
CVE-2018-18193 leads to memory exhaustion and almost completely freezes
the system. The heap-based buffer overflows may have a more serious
impact depending on the situation. The upstream maintainer of libgig,
Christian Schoenebeck (CCed), was not aware of them. In a private
conversation Christian stated that

"The file types I mentioned above are always consciously, manually
opened by users (all in pro-audio context) with these applications, and
(except of .sf2 probably) are rather quite exotic file formats from an
average user's point of view. Most of our users either create those
files by themselves with our tools (e.g. with gigedit and/or gigtools)
or they are loading files from commercial sample library CDs dating back
between mid 1980s - mid 2000s (libgig started in 2003), and yet some
users share their files with close/trusted persons.

In short: the chance that somebody successfully attempts to use these
file types for security exploits that would really harm somebody
seriously in reality, is quite low."

I have the same impression and the risk of being affected by one of
these vulnerabilities is low because of the special file format and how
those files are created.

libgig was not designed to be secure and to process untrusted files.
Christian asked me that we should notify users about the situation, to
open only trusted files or in a sandboxed environment, and I suggested
to add a README.Debian file to libgig for clarification. I hereby
forward this request to the maintainers of libgig.

I have come to the conclusion that we won't spend time on fixing these
issues in Jessie because of the low security risk. Fixing those bugs is
not a development priority of upstream currently and Christian asked for
help and patches.

Regards,

Markus



signature.asc
Description: OpenPGP digital signature


Bug#944190: release.debian.org: Allow britney to consider installability of dependencies of essential packages

2019-11-10 Thread Mark Hindley
Niels,

On Sun, Nov 10, 2019 at 10:49:00AM +, Niels Thykier wrote:
> I looking forward to your test case as it will make this issue a lot
> easier to debug.

A test case is attached. It fails without the patch I submitted (inadequate
though it is, as you pointed out), but succeeds with it. I hope it is helpful
and I have not missed something.

> What is supposed to happen is that:
> 
>  * Britney "should" rewrite the relation on "libsystemd0" as
>"libsystemd0 | libelogin0" when building the BinaryPackageUniverse
>(actually as libsystemd0//arch | libsystemd0//arch
> tuples).
> 
>- This is also based on the assumption that the Conflicts/Provides
>  setup in libelogin0 is done correctly.  I /think/ it is - I am just
>  being explicit about the assumption.

I think so too. Certainly the binaries from src:elogind are manually installable
into bullseye and satisfy the necessary dependencies of essential packages.

Thanks very much for looking at this.

Let me know if there is anything else I can do to help.

Mark
>From e7e78b251beaba5182377a15f6af226ccf950710 Mon Sep 17 00:00:00 2001
From: Mark Hindley 
Date: Sun, 10 Nov 2019 17:16:34 +
Subject: [PATCH] Test case for #944190.

The test requires that a dependency of an essential package can be satisfied by
another package which Provides it.
---
 t/bug-944190/description |  2 ++
 t/bug-944190/expected|  5 +
 t/bug-944190/expected-excuses.yaml   | 29 
 t/bug-944190/var/data/testing/Packages_i386  | 15 ++
 t/bug-944190/var/data/testing/Sources|  5 +
 t/bug-944190/var/data/unstable/Packages_i386 | 25 
 t/bug-944190/var/data/unstable/Sources   | 11 +++
 7 files changed, 92 insertions(+)
 create mode 100644 t/bug-944190/description
 create mode 100644 t/bug-944190/expected
 create mode 100644 t/bug-944190/expected-excuses.yaml
 create mode 100644 t/bug-944190/var/data/testing/Packages_i386
 create mode 100644 t/bug-944190/var/data/testing/Sources
 create mode 100644 t/bug-944190/var/data/unstable/Packages_i386
 create mode 100644 t/bug-944190/var/data/unstable/Sources

diff --git a/t/bug-944190/description b/t/bug-944190/description
new file mode 100644
index 000..54418fd
--- /dev/null
+++ b/t/bug-944190/description
@@ -0,0 +1,2 @@
+Test case for ensuring a package with Conflicts/Provides/Replaces can satisfy a
+dependency of essential set.
diff --git a/t/bug-944190/expected b/t/bug-944190/expected
new file mode 100644
index 000..c249f4b
--- /dev/null
+++ b/t/bug-944190/expected
@@ -0,0 +1,5 @@
+test 1.0-1 i386
+libtest1 1.0-1 i386
+test-src 1.0-1 source
+libprovider1 1.0-1 i386
+provider 1.0-1 source
diff --git a/t/bug-944190/expected-excuses.yaml b/t/bug-944190/expected-excuses.yaml
new file mode 100644
index 000..9ea638c
--- /dev/null
+++ b/t/bug-944190/expected-excuses.yaml
@@ -0,0 +1,29 @@
+generated-date: 2018-12-28 22:32:22.868333
+sources:
+- excuses:
+  - Cannot be tested by piuparts (not a blocker) - (no link yet)
+  is-candidate: true
+  item-name: provider
+  maintainer: The R-Team
+  migration-policy-verdict: PASS
+  new-version: 1.0-1
+  old-version: '-'
+  policy_info:
+age:
+  age-requirement: 10
+  current-age: 17892
+  verdict: PASS
+autopkgtest:
+  verdict: PASS
+build-depends:
+  verdict: PASS
+piuparts:
+  test-results: cannot-be-tested
+  verdict: PASS
+rc-bugs:
+  shared-bugs: []
+  unique-source-bugs: []
+  unique-target-bugs: []
+  verdict: PASS
+  reason: []
+  source: provider
diff --git a/t/bug-944190/var/data/testing/Packages_i386 b/t/bug-944190/var/data/testing/Packages_i386
new file mode 100644
index 000..d6cec70
--- /dev/null
+++ b/t/bug-944190/var/data/testing/Packages_i386
@@ -0,0 +1,15 @@
+Package: test
+Section: devel
+Architecture: i386
+Source: test-src
+Maintainer: The R-Team 
+Version: 1.0-1
+Depends: libtest1
+Essential: yes
+
+Package: libtest1
+Section: devel
+Architecture: i386
+Source: test-src
+Maintainer: The R-Team 
+Version: 1.0-1
diff --git a/t/bug-944190/var/data/testing/Sources b/t/bug-944190/var/data/testing/Sources
new file mode 100644
index 000..cfd24bb
--- /dev/null
+++ b/t/bug-944190/var/data/testing/Sources
@@ -0,0 +1,5 @@
+Package: test-src
+Binary: test, libtest1
+Version: 1.0-1
+Section: devel
+Maintainer: The R-Team 
diff --git a/t/bug-944190/var/data/unstable/Packages_i386 b/t/bug-944190/var/data/unstable/Packages_i386
new file mode 100644
index 000..ff60b43
--- /dev/null
+++ b/t/bug-944190/var/data/unstable/Packages_i386
@@ -0,0 +1,25 @@
+Package: test
+Source: test-src
+Version: 1.0-1
+Maintainer: The R-Team 
+Depends: libtest1
+Architecture: i386
+Section: devel
+Essential: yes
+
+Package: libtest1
+Source: test-src
+Version: 1.0-1
+Maintainer: The R-Team 
+Architecture: i386
+Section: devel
+
+Package: libprovider1
+Source: provider
+Version: 

Bug#774274: fontforge: please use SOURCE_DATE_EPOCH for

2019-11-10 Thread Hideki Yamane
 reproducible font modification time
Message-Id: <2019015420.1a5a24be8c24f5b668ebe...@iijmio-mail.jp>
In-Reply-To: 

X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.32; x86_64-pc-linux-gnu)
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

Hi,

On Sat, 21 Sep 2019 12:35:07 +0700 Theppitak Karoonboonyanan 
 wrote:
> However, as there have already been three 2019 releases (March, April, 
> August),
> updating from official release could be another choice.

 Could you try to check it with new fontforge package in experimental?


-- 
Regards,

 Hideki Yamane henrich @ debian.org/iijmio-mail.jp



Bug#944483: moon-lander: consider remaining fuel when a bonus ship is given

2019-11-10 Thread Asher Gordon
Package: moon-lander
Version: 1:1.0-7
Severity: normal
Tags: patch

Dear Maintainer,

When a player reaches 1 points, a bonus ship is supposed to be
given. However, if the player is currently at, say, 8000 points and
lands on an 1800 point pad but has 300 fuel left, the score will then be
8000 + 1800 + 300 = 10100, which is greater than 1 but no bonus ship
will be given.

This is because the new score is calculated considering the remaining
fuel (a feature added by Debian in 20_fix-score.patch), but the bonus
ship does not consider the remaining fuel. Please see the following
patch for a simple fix:
Description: Fix bonus ship calculation to account for remaining fuel.
Author: Asher Gordon 
---
This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
--- moon-lander-1.0.orig/moon_lander.c
+++ moon-lander-1.0/moon_lander.c
@@ -1686,7 +1686,7 @@ void gameloop(Game *game){
 
 	// Bonus ship every 1 points
 	if( (game->score / 1) < 
-		((game->score + game->current_level.landing_score[count]) / 1 ) ) {
+		((game->score + game->current_level.landing_score[count] + game->fuel) / 1 ) ) {
 	  // (MLH) This would be a good place to play a sound
 	  
 	  game->landing_pad = count;

To reproduce this bug, follow these steps:

Compile for easier debugging (you'll be using this value for CFLAGS
again, so put it in the environment):

  $ export CFLAGS="$(sdl-config --cflags) -O0 -ggdb3"
  $ make clean all
  [...]

Now run it under GDB (or your favorite front-end):

  $ gdb moon-lander
  [...]
  (gdb) run
  [...]

Go to the moon-lander window, and start a new game with  and pause
it immediately after it starts with P. Now go back to GDB, and type
^C. Then go up until you reach the bottom most frame in moon-lander (not
libSDL).

  ^C
  Thread 1 "moon-lander" received signal SIGINT, Interrupt.
  0x77f0dd97 in ?? () from /usr/lib/x86_64-linux-gnu/libSDL-1.2.so.0
  (gdb) up
  #1  0x77f02470 in ?? ()
 from /usr/lib/x86_64-linux-gnu/libSDL-1.2.so.0
  (gdb) 
  #2  0x77f16b46 in SDL_LowerBlit ()
 from /usr/lib/x86_64-linux-gnu/libSDL-1.2.so.0
  (gdb) 
  #3  0x77f18812 in SDL_Flip ()
 from /usr/lib/x86_64-linux-gnu/libSDL-1.2.so.0
  (gdb) 
  #4  0xa928 in gameloop (game=0x7fffdc00)
  at moon_lander.c:1733
  1733SDL_Flip(game->screen);

Now set the fuel to some huge value so that your new score will be
greater than 1 because of the fuel left:

  (gdb) call game->fuel = 15000
  $1 = 15000
  (gdb) cont
  Continuing.

Go back to the moon-lander window, unpause the game (with P again), and
land on a pad (you can cheat with GDB if you're really bad at this
game). Your new score should be greater than 1, but you will not get
a bonus ship.

This can happen in real life (i.e. without GDB) and you won't get a
bonus ship until 2 points (and even then you might not). If you
repeat the steps above with my patch applied (and don't forget to
recompile--that's why you exported CFLAGS), you will find that it will
give you a bonus ship.

Thanks,
Asher

-- 
If at first you don't succeed, redefine success.


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

Kernel: Linux 5.2.0-3-amd64 (SMP w/2 CPU cores)
Kernel taint flags: TAINT_FIRMWARE_WORKAROUND
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 moon-lander depends on:
ii  libc6 2.29-2
ii  libsdl-image1.2   1.2.12-12
ii  libsdl-mixer1.2   1.2.12-16
ii  libsdl1.2debian   1.2.15+dfsg2-5
ii  moon-lander-data  1:1.0-7

moon-lander recommends no packages.

moon-lander suggests no packages.

-- no debconf information


signature.asc
Description: PGP signature


Bug#944482: lv2-dev: Missing "lv2_util.h" header

2019-11-10 Thread Yruama Lairba
Package: lv2-dev
Version: 1.14.0~dfsg1-2
Severity: normal

Dear Maintainer,

When i tried to build "eg-midigate.lv2" from 
http://lv2plug.in/git/cgit.cgi/lv2.git/tree/plugins
the build fail because the header "lv2/lv2plug.in/ns/lv2core/lv2_util.h"
is missing.

I was able to solve the problem by installing the original framework by
doing this :
- downloading lv2-1.14.0.tar.xz from http://lv2plug.in/git/cgit.cgi/lv2.git/
- unpacking it somewhere in my home directory
- going inside the root directory of the newly extracted tree
- running ./waf configure --no-plugins --copy-headers
- running sudo ./waf install --no-plugins --copy-headers. this seems to install
  headers, libs and documentations.

I also checked on https://packages.debian.org, this issue seems to be
fixed in testing and sid as i can find the "lv2_util.h" in the package
file list.

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

Kernel: Linux 4.19.0-6-amd64 (SMP w/2 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)
LSM: AppArmor: enabled

-- no debconf information


Bug#943555: wireguard-dkms: Kernel modules don't build with kernel 5.3.0-1-arm64 on Raspberry Pi3

2019-11-10 Thread Christian Haul
Hi Daniel,
thanks for caring!

On 10.11.19 14:51, Daniel Kahn Gillmor wrote:
> On Sat 2019-10-26 12:51:47 +, Chris. wrote:
>> on Raspberry Pi3 kernel module stops building since updating to kernel
>> 5.3.0.1.

> I'm not sure this is a wireguard-specific issue...

I have added another DKMS package (iptables-netflow-dkms) and it runs
into the same issue.

# cat /var/lib/dkms/ipt-netflow/2.4/build/make.log
DKMS make.log for ipt-netflow-2.4 for kernel 5.3.0-1-arm64 (aarch64)
Sun Nov 10 14:16:57 UTC 2019
Compiling for kernel 5.3.7
make -C /lib/modules/5.3.0-1-arm64/build
M=/var/lib/dkms/ipt-netflow/2.4/build modules CONFIG_DEBUG_INFO=y
make[1]: warning: jobserver unavailable: using -j1.  Add '+' to parent
make rule.
make[1]: Entering directory '/usr/src/linux-headers-5.3.0-1-arm64'
arch/arm64/Makefile:58: *** arm-linux-gnueabihf-gcc not found, check
CROSS_COMPILE_COMPAT.  Stop.
make[1]: *** [/usr/src/linux-headers-5.3.0-1-common/Makefile:179:
sub-make] Error 2
make[1]: Leaving directory '/usr/src/linux-headers-5.3.0-1-arm64'
make: *** [Makefile:25: ipt_NETFLOW.ko] Error 2


> This looks to me like you don't have the arm64-specific compiler
> installed, which ought to have been installed correctly by
> linux-headers-5.3.0-1-arm64.

Not an expert here, but I can still run

root@rpi3:~# dkms build wireguard/0.0.20191012 -k 5.2.0-3-arm64

Kernel preparation unnecessary for this kernel.  Skipping...

Building module:
cleaning build area
make -j4 KERNELRELEASE=5.2.0-3-arm64 -C /lib/modules/5.2.0-3-arm64/build
M=/var/lib/dkms/wireguard/0.0.20191012/build.

cleaning build area.

DKMS: build completed.

I.E. compilation works in general. Something in kernel 5.3 changed that
breaks DKMS on Raspberry Pi3. Looking for a gcc-9 for abihf I can onle
find packages marked "crosscompile" (plus it's missing a dependency so I
can't install)

Should I file a bug against the linux-headers package instead?

Cheers,
Chris.



Bug#944481: exim4: [Dummy bug] Enforce longer testing period for new upstream

2019-11-10 Thread Andreas Metzler
Source: exim4
Version: 4.93~RC2-1
Severity: serious

One of 4.93's changes

|
| JH/32 Introduce a general tainting mechanism for values read from the
|   input channel, and values derived from them. Refuse to expand any
|   tainted values, to catch one form of exploit.
|

has a relatively high potential for breaking stuff. Let's give this
version some additional time for testing sid and delay migration to
testing.

cu Andreas

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



Bug#944480: transition: libdvdread

2019-11-10 Thread Sebastian Ramacher
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: transition
Control: forwarded -1 
https://release.debian.org/transitions/html/auto-libdvdread.html

libdvdread bumped its SONAME from 4 to 7. All reverse dependencies build
fine against the new version.

Cheers
-- 
Sebastian Ramacher


signature.asc
Description: PGP signature


Bug#944479: EDAC amd64 regression

2019-11-10 Thread Antonio Russo
Package: linux-image-5.3.0-2-amd64
Version: 5.3.9-1
Severity: normal

--- Please enter the report below this line. ---

Upgraded from kernel 5.2.17, and started getting lines like

Nov 10 09:13:08 REDACTED kernel: EDAC amd64: Node 0: DRAM ECC enabled.
Nov 10 09:13:08 REDACTED kernel: EDAC amd64: F17h detected (node 0).
Nov 10 09:13:08 REDACTED kernel: EDAC amd64: Error: F0 not found, device 0x1460 
(broken BIOS?)
Nov 10 09:13:08 REDACTED kernel: EDAC amd64: Error: Error probing instance: 0

I do have ECC ram, and it claims to be supported, lshw shows 
"errordetection=multi-bit-ecc",
on both 5.2.17 and 5.3.9.

This would seem to be a regression, since I didn't have this error on 5.2.17.

--- System information. ---
Motherboard: X470 Taichi Ultimate
Processor: AMD Ryzen 7 3700X

Architecture:
Kernel: Linux 5.3.0-2-amd64

Debian Release: bullseye/sid



  1   2   >