Bug#955467: timeout not effective for proxy connection

[Eduard Bloch]

Package: wget
Version: 1.20.3-1+b2
Severity: important

Hi,

Repro: specify http_proxy on a valid IP but without a listening port.
Something like http_proxy=http://localhost:3142 strace wget --timeout=15 -q -O- 
http://mirrors.ubuntu.com/mirrors.txt

Result: it does NOT abort after 15 seconds. It takes a couple of minutes
instead. In the meantime, it keeps rotating around this syscalls, where
tv_sec keeps increasing from time to time.

Please note that IPv6 was turned off via procfs due to Vodafone's failure. This 
might cause the EADDRNOTAVAIL errno codes below.

stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2326, ...}) = 0
ioctl(0, TIOCGPGRP, [266607])   = 0
getpgrp()   = 266607
nanosleep({tv_sec=8, tv_nsec=0}, 0x7ffe3b114860) = 0
nanosleep({tv_sec=0, tv_nsec=0}, NULL)  = 0
stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2326, ...}) = 0
ioctl(0, TIOCGPGRP, [266607])   = 0
getpgrp()   = 266607
socket(AF_INET, SOCK_STREAM, IPPROTO_IP) = 3
rt_sigprocmask(SIG_BLOCK, NULL, [], 8)  = 0
rt_sigaction(SIGALRM, {sa_handler=0x55576100db70, sa_mask=[ALRM], 
sa_flags=SA_RESTORER|SA_RESTART, sa_restorer=0x7f607cf287e0}, 
{sa_handler=SIG_DFL, sa_mask=[ALRM], sa_flags=SA_RESTORER|SA_RESTART, 
sa_restorer=0x7f607cf287e0}, 8) = 0
setitimer(ITIMER_REAL, {it_interval={tv_sec=0, tv_usec=0}, it_value={tv_sec=15, 
tv_usec=0}}, NULL) = 0
connect(3, {sa_family=AF_INET, sin_port=htons(3142), 
sin_addr=inet_addr("127.0.0.1")}, 16) = -1 ECONNREFUSED (Verbindungsaufbau 
abgelehnt)
setitimer(ITIMER_REAL, {it_interval={tv_sec=0, tv_usec=0}, it_value={tv_sec=0, 
tv_usec=0}}, NULL) = 0
rt_sigaction(SIGALRM, {sa_handler=SIG_DFL, sa_mask=[ALRM], 
sa_flags=SA_RESTORER|SA_RESTART, sa_restorer=0x7f607cf287e0}, 
{sa_handler=0x55576100db70, sa_mask=[ALRM], sa_flags=SA_RESTORER|SA_RESTART, 
sa_restorer=0x7f607cf287e0}, 8) = 0
close(3)= 0
ioctl(0, TIOCGPGRP, [266607])   = 0
getpgrp()   = 266607
ioctl(0, TIOCGPGRP, [266607])   = 0
getpgrp()   = 266607
socket(AF_INET, SOCK_STREAM, IPPROTO_IP) = 3
rt_sigprocmask(SIG_BLOCK, NULL, [], 8)  = 0
rt_sigaction(SIGALRM, {sa_handler=0x55576100db70, sa_mask=[ALRM], 
sa_flags=SA_RESTORER|SA_RESTART, sa_restorer=0x7f607cf287e0}, 
{sa_handler=SIG_DFL, sa_mask=[ALRM], sa_flags=SA_RESTORER|SA_RESTART, 
sa_restorer=0x7f607cf287e0}, 8) = 0
setitimer(ITIMER_REAL, {it_interval={tv_sec=0, tv_usec=0}, it_value={tv_sec=15, 
tv_usec=0}}, NULL) = 0
connect(3, {sa_family=AF_INET, sin_port=htons(3142), 
sin_addr=inet_addr("127.0.0.1")}, 16) = -1 ECONNREFUSED (Verbindungsaufbau 
abgelehnt)
setitimer(ITIMER_REAL, {it_interval={tv_sec=0, tv_usec=0}, it_value={tv_sec=0, 
tv_usec=0}}, NULL) = 0
rt_sigaction(SIGALRM, {sa_handler=SIG_DFL, sa_mask=[ALRM], 
sa_flags=SA_RESTORER|SA_RESTART, sa_restorer=0x7f607cf287e0}, 
{sa_handler=0x55576100db70, sa_mask=[ALRM], sa_flags=SA_RESTORER|SA_RESTART, 
sa_restorer=0x7f607cf287e0}, 8) = 0
close(3)= 0
ioctl(0, TIOCGPGRP, [266607])   = 0
getpgrp()   = 266607
ioctl(0, TIOCGPGRP, [266607])   = 0
getpgrp()   = 266607
socket(AF_INET6, SOCK_STREAM, IPPROTO_IP) = 3
rt_sigprocmask(SIG_BLOCK, NULL, [], 8)  = 0
rt_sigaction(SIGALRM, {sa_handler=0x55576100db70, sa_mask=[ALRM], 
sa_flags=SA_RESTORER|SA_RESTART, sa_restorer=0x7f607cf287e0}, 
{sa_handler=SIG_DFL, sa_mask=[ALRM], sa_flags=SA_RESTORER|SA_RESTART, 
sa_restorer=0x7f607cf287e0}, 8) = 0
setitimer(ITIMER_REAL, {it_interval={tv_sec=0, tv_usec=0}, it_value={tv_sec=15, 
tv_usec=0}}, NULL) = 0
connect(3, {sa_family=AF_INET6, sin6_port=htons(3142), inet_pton(AF_INET6, 
"::1", &sin6_addr), sin6_flowinfo=htonl(0), sin6_scope_id=0}, 28) = -1 
EADDRNOTAVAIL (Die angeforderte Adresse kann nicht zugewiesen werden)
setitimer(ITIMER_REAL, {it_interval={tv_sec=0, tv_usec=0}, it_value={tv_sec=0, 
tv_usec=0}}, NULL) = 0
rt_sigaction(SIGALRM, {sa_handler=SIG_DFL, sa_mask=[ALRM], 
sa_flags=SA_RESTORER|SA_RESTART, sa_restorer=0x7f607cf287e0}, 
{sa_handler=0x55576100db70, sa_mask=[ALRM], sa_flags=SA_RESTORER|SA_RESTART, 
sa_restorer=0x7f607cf287e0}, 8) = 0
close(3)= 0
ioctl(0, TIOCGPGRP, [266607])   = 0
getpgrp()   = 266607
ioctl(0, TIOCGPGRP, [266607])   = 0
getpgrp()   = 266607
socket(AF_INET6, SOCK_STREAM, IPPROTO_IP) = 3
rt_sigprocmask(SIG_BLOCK, NULL, [], 8)  = 0
rt_sigaction(SIGALRM, {sa_handler=0x55576100db70, sa_mask=[ALRM], 
sa_flags=SA_RESTORER|SA_RESTART, sa_restorer=0x7f607cf287e0}, 
{sa_handler=SIG_DFL, sa_mask=[ALRM], sa_flags=SA_RESTORER|SA_RESTART, 
sa_restorer=0x7f607cf287e0}, 8) = 0
setitimer(ITIMER_REAL, {it_interval={tv_sec=0, tv_usec=0}, it_value={tv_sec=15, 
tv_usec=0}}, NULL) = 0
connect(3, {sa_family=AF_INET6, sin6_port=htons(3142), inet_pton(AF_INET6

Bug#955466: bind daemon crashes with assert

[Timothy Pearson]

Package: bind9
Version: 1:9.11.5.P4+dfsg-5.1

Latest Debian Buster ppc64le, bind9 keeps crashing every few days with an 
assert:

named[412]: ../../../lib/dns/rbtdb.c:10330: INSIST(((void 
*)((header)->link.prev) != (void *)(-1))) failed, back trace
named[412]: #0 0x10609cee8 in ??
named[412]: #1 0x7fffa206d6e8 in ??
named[412]: #2 0x7fffa2882f84 in ??
named[412]: #3 0x7fffa28899d8 in ??
named[412]: #4 0x7fffa288a17c in ??
named[412]: #5 0x7fffa280b224 in ??
named[412]: #6 0x1060b50f0 in ??
named[412]: #7 0x1060b5e08 in ??
named[412]: #8 0x7fffa20a5b4c in ??
named[412]: #9 0x7fffa1ed8b90 in ??
named[412]: #10 0x7fffa19e1018 in ??
named[412]: exiting (due to assertion failure)
systemd[1]: bind9.service: Main process exited, code=killed, status=6/ABRT
systemd[1]: bind9.service: Failed with result 'signal'.

This appeared after an upgrade from Stretch; the old bind version was not 
affected.

Bug#909963: xterm-256color: Corrupts first line in hexedit window

[Mathieu Malaterre]

Control: affects -1 src:hexedit

Here is the output of:

$ TERM=xterm-256color hexedit d
$ TERM=xterm-16color hexedit d
$ TERM=xterm hexedit d

they all give:

```
0   57 65 64 20  41 70 72 20  20 31 20 30  38 3A 31 32  3A 35 31 20
43 45 53 54  20 32 30 32  30 0A
  Wed Apr  1 08:12:51 CEST 2020.
002C
```

while

$ TERM=xterm-color hexedit d

gives:

```
   57 65 64 20  41 70 72 20  20 31 20 30  38 3A 31 32  3A 35
31 20  43 45 53 54  20 32 30 32  30 0A
  Wed Apr  1 08:12:51 CEST 2020.
002C
```

Bug#955393: popularity-contest: gpg: 5B1A07804DD558242CF5538215A07BA5233E3E85: skipped: unusable public key

[Thorsten Glaser]

severity 955393 wishlist
thanks

Bill Allombert dixit:

>Hello Thorsten,
>Could you investigate ? The key is in this file:
>/usr/share/popularity-contest/debian-popcon.gpg

Sure:

tglase@tglase-nb:~ $ gpg --import 
/usr/share/popularity-contest/debian-popcon.gpg
gpg: key 233E3E85: no valid user IDs
gpg: this may be caused by a missing self-signature
gpg: Total number processed: 1
gpg:   w/o user IDs: 1
2|tglase@tglase-nb:~ $ gpg2 --import 
/usr/share/popularity-contest/debian-popcon.gpg
gpg: keyserver option 'verbose' is unknown
gpg: keyserver option 'verbose' is unknown
gpg: key 15A07BA5233E3E85: public key "Debian popularity contest server (2020 
submission key) " imported

Turns out that the key is only compatible with gpg2.

Can you please change all calls to gpg in popcon to gpg2?
I know that gpg2 ships /usr/bin/gpg these days, but I had
to revert that to gpg1 locally for some reasons, and my
requests for them to handle that with update-alternatives
went nowhere, so I just set the symlink manually… but it
would be welcomed to not assume gpg is gpg2.

bye,
//mirabilos
-- 
15:41⎜ Somebody write a testsuite for helloworld :-)

Bug#909963: Corrupted first line

[Mathieu Malaterre]

Control: affects -1 src:ncurses-hexedit
Control: tags -1 confirmed

I do not believe the issue is in package hexedit, since I can
reproduce the symptoms also with `hexeditor`. Maybe this is related to
a specific TERM ?

Bug#955465: qtcreator: Unnecessary botan build dep

[Michael Weghorn]

Package: qtcreator
Version: 4.11.0-2
Severity: normal
Tags: patch

Dear Maintainer,

qtcreator has a now unnecessary build dependency on package
'libbotan-2-dev'.

Botan is no longer used since upstream commit
d7178b88c4b2572fb83b28f8178940766216deed
("SSH: Use OpenSSH tools").

Therefore, I suggest do drop that build dependency, in particular
since qtcreator is currently marked for autoremoval due to bug
#952951 ("botan: Replace PKCS11 headers provided by OASIS").

A patch to do so will be attached.

Kind regards,
Michael

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

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

Versions of packages qtcreator depends on:
ii  libc6  2.30-2
ii  libclang1-81:8.0.1-9
ii  libgcc-s1 [libgcc1]10-20200324-1
ii  libgcc11:10-20200324-1
ii  libkf5syntaxhighlighting5  5.62.0-3
ii  libllvm8   1:8.0.1-9
ii  libqbscore1.13 1.13.1-2
ii  libqt5concurrent5  5.12.5+dfsg-9
ii  libqt5core5a [qtbase-abi-5-12-5]   5.12.5+dfsg-9
ii  libqt5designer55.12.5-2+b2
ii  libqt5designercomponents5  5.12.5-2+b2
ii  libqt5gui5 5.12.5+dfsg-9
ii  libqt5help55.12.5-2+b2
ii  libqt5network5 5.12.5+dfsg-9
ii  libqt5printsupport55.12.5+dfsg-9
ii  libqt5qml5 [qtdeclarative-abi-5-12-5]  5.12.5-5
ii  libqt5quick5   5.12.5-5
ii  libqt5quickwidgets55.12.5-5
ii  libqt5script5  5.12.5+dfsg-2
ii  libqt5serialport5  5.12.5-1
ii  libqt5sql5 5.12.5+dfsg-9
ii  libqt5sql5-sqlite  5.12.5+dfsg-9
ii  libqt5widgets5 5.12.5+dfsg-9
ii  libqt5xml5 5.12.5+dfsg-9
ii  libstdc++6 10-20200324-1
ii  qml-module-qtqml-models2   5.12.5-5
ii  qml-module-qtquick-controls5.12.5-1+b1
ii  qml-module-qtquick25.12.5-5
ii  qtchooser  66-2
ii  qtcreator-data 4.11.0-2

Versions of packages qtcreator recommends:
ii  clang  1:9.0-49.1
ii  clang-tidy 1:9.0-49.1
ii  gdb9.1-2
ii  konsole [x-terminal-emulator]  4:19.08.1-2+b1
ii  make   4.2.1-1.2
ii  qmlscene   5.12.5-5
ii  qt5-doc5.12.5-1
ii  qt5-qmltooling-plugins 5.12.5-5
ii  qtbase5-dev-tools  5.12.5+dfsg-9
ii  qtcreator-doc  4.11.0-2
ii  qtdeclarative5-dev-tools   5.12.5-5
ii  qttools5-dev-tools 5.12.5-2+b2
ii  qttranslations5-l10n   5.12.5-1
ii  qtxmlpatterns5-dev-tools   5.12.5-1
ii  xterm [x-terminal-emulator]353-1

Versions of packages qtcreator suggests:
ii  clazy   1.6-2+b1
ii  cmake   3.16.3-1
ii  g++ 4:9.2.1-3.1
ii  git 1:2.25.1-1
pn  kate-data   
ii  subversion  1.13.0-2+b1
ii  valgrind1:3.15.0-1

-- no debconf information
From 2c75d9fd06b44e8e381a39af2e81fc38f4e01c37 Mon Sep 17 00:00:00 2001
From: Michael Weghorn 
Date: Tue, 31 Mar 2020 17:06:28 +0200
Subject: [PATCH] Drop unused botan build dependency

Botan has been removed upstream with

commit d7178b88c4b2572fb83b28f8178940766216deed
Author: Christian Kandeler 
Date:   Fri Nov 23 11:07:57 2018 +0100

SSH: Use OpenSSH tools

... instead of our own SSH library.

Advantages:
- Full compatibility with OpenSSH behavior guaranteed.
- Minimal maintenance effort.
- Less code to build.
- Big chunk of 3rd party sources can be removed from our repository.

One the downside, Windows users now need to install OpenSSH for
RemoteLinux support. Hoewever, people doing embedded development
probably have it installed anyway.

[ChangeLog] Switched SSH backend to OpenSSH

Fixes: QTCREATORBUG-15744
Fixes: QTCREATORBUG-15807
Fixes: QTCREATORBUG-19306
Fixes: QTCREATORBUG-20210
Change-Id: Ifcfefdd39401e45ba1f4aca35d2c5bf7046c7aab
Reviewed-by: Eike Ziller 
Reviewed-by: Ulf Hermann 
---
 debian/control | 1 -
 debian/rules   | 3 +--
 2 files changed, 1 insertion(+), 3 deletions(-)

diff --git a/debian/control b/debian/control
index 0b279a0..9529edb 100644
--- a/debian/control
+++ b/debian/control
@@ -7,7 +7,6 @@ Uploaders: Adam Majer ,
   

Bug#948969: wnpp.pl fix

[victory]

in wnpp.pl,
L107
push @rfa_bypackage_html, " , ";
L122
push @rfa_bymaint_html, " , ";
L136
push @rfa_byage_html, " , ";
L148
push @orphaned_html, " , ";
L160
push @orphaned_byage_html, " ";
L174
 " , ";
L191
 " , ";
L207
 " , ";
L286
 " , ";
L302
 " , ";
L314
" , , ";

these  need to be 1 by 1 as pdo site does not accept multiple 
stanza;;
I suggest most clear way, adding a sub routine named "pdolinks"
and replace these  tags w/ a snippet refering this, like:
  &pdolinks($pkg);
---
# this sub routine takes 1 arg, expects "pkg1, pkg2, ..." form
# and returns a scalar: "[, , ...]
# additional description for noob:
# 1st line: $packages takes the 1st arg
# 2nd line: @packages takes indivisual packages for each element
# 3rd-6th lines: cleanup and 'ifies every element in @packages
# 8th line: join concatenates array using specified separator as the 1st arg
# if it returns an array, the @..._html arrays will contain every links 1 by 1
sub pdolinks{
  my $packages = shift;
  my @packages = split(/[\s,]+/, $packages);
  for (my $i=0; $i<$#packages; $i++){
$packages[$i] =~ s/[\s,]//g;
$packages[$i] = "":
  }
  return join(", ", @packages);
}
---

note that I did no test;
additionally, popcon links may have the same issue

-- 
victory
no need to CC me :-)

Bug#955464: ITP: ruby-linked-list -- Ruby implementation of Doubly Linked List

[Anthony Fok]

Package: wnpp
Severity: wishlist
Owner: Anthony Fok 

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

* Package name: ruby-linked-list
  Version : 0.0.14
  Upstream Author : Yury Velikanau 
* URL : https://github.com/spectator/linked-list
* License : Expat
  Programming Lang: Ruby
  Description : Ruby implementation of Doubly Linked List

 Ruby implementation of Doubly Linked List, following some Ruby idioms.

More information:

ruby-linked-list is required by ruby-hrx (to be packaged),
which in turn is required by sass-spec 3.6.3-1 (to be upgraded).

ruby-linked-list is to be team-maintained with
Debian Ruby Extras Maintainers 



-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEFCQhsZrUqVmW+VBy6iUAtBLFms8FAl6EMJUACgkQ6iUAtBLF
ms+8Eg//TsCzCVJQVTVRHbG48gIpx+IBpJvx6ntsqgtwKfNGC/+yXsOgsSdsP4u+
We3VDUL/JVoQrLzJxST/vtvLydoyKoXoSeIliCpvMtvjUVz8fIuqhAoXxfMuXWur
byTt9Lp/Bb3G3BCKnIMgLObGJMQa8qYTHN0B+O5RZmfAaXvTB4FuZSLUK+dDqIxC
j+dt0Xa3UTWhMf/nJcSFQp/C/cRK5mJa7QU8COVSKlIjQVRkvpzrjGC8TSiK2Oen
2wCcAFKn+U9t5tfIjyJ5D6dWEXM6hY4iS68TAzPO7BW8k1udlm/ilqh+lBtvBZ2N
XiryeD+mCeCn+BAFDTWMlZ1cEYs/HT44+xzqNM5EJNTXKW3I4SpRlU8GwUg8lxqE
pGAcs8t76O2EtMbXXzpYJyC554BtO9L56jtL/qKZrs02oUT+3n1zSzKrgHYHGAVz
ibsDihjG19wzrQ8WI2hB7ByAzs2V6D+34sWFvlPFL1i//bZFXYCdCkoos79OGJdn
iLAqGivwwYw25z3VsiKOtQ3uvsdfLn86BDm1OOyyISzl6Zjo3fdewVnszCOUM2to
X2uEvlPGIeMBXtwE4iLFMw1m2kN7H6Nhpm9SwXObLKnWouDLIJPYGODnr/fKHx0G
JCG9xR0yWMeqNBEo53MD8QOT4425c/qk0xX+vUs6D66TxoHApp8=
=1Nng
-END PGP SIGNATURE-

Bug#938425: 938425

[JCF Ploemen]

Removing pygtk won't make sabnzbdplus uninstallable; python-gtk2 is a
suggested dependency used only for an optional tray icon.


pgpIYDtwPOiAw.pgp
Description: OpenPGP digital signature

Bug#955463: empathy: Can't add account

[Bill Wohler]

Package: empathy
Version: 3.25.90+really3.12.14-2
Severity: normal

1. Press Account settings button.
2. Press + button.
3. Select Google Talk account, enter credentials, and press Add button.
4. Nothing happens. Really, absolutely nothing. I'd expect my Google
   Talk account to be added and my Hangout buds to be visible and that I'd
   be able to chat with them.
5. However, I found the following that appeared in /var/log/syslog every
   time I pressed the Add button:

Mar 31 21:27:55 olgas mission-control[4177]: g_object_new_is_valid_property: 
object class 'McdAccount' has no property named 'connectivity-monitor'
Mar 31 21:27:55 olgas mission-control[4177]: object McdAccount 0x562f321bf460 
finalized while still in-construction
Mar 31 21:27:55 olgas mission-control[4177]: Custom constructor for class 
McdAccount returned NULL (which is invalid). Please use GInitable instead.

Looks like a patch is available at
https://gitlab.freedesktop.org/telepathy/telepathy-mission-control/commit/d8dab08fe8db137c6bbd8bbdc3d9b01d98c48910.

Maybe this needs to be passed on to libmission-control-plugins0, but as
long as empathy is fixed...

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

Kernel: Linux 5.4.0-4-amd64 (SMP w/3 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

Versions of packages empathy depends on:
ii  dbus-user-session [default-dbus-session-bus]  1.12.16-2
ii  dbus-x11 [dbus-session-bus]   1.12.16-2
ii  dconf-gsettings-backend [gsettings-backend]   0.36.0-1
ii  empathy-common3.25.90+really3.12.14-2
ii  geoclue-2.0   2.5.6-1
ii  gsettings-desktop-schemas 3.36.0-1
ii  gstreamer1.0-pulseaudio   1.16.2-3
ii  libc6 2.30-2
ii  libcairo2 1.16.0-4
ii  libcanberra-gtk3-00.30-7
ii  libcanberra0  0.30-7
ii  libchamplain-0.12-0   0.12.20-1
ii  libchamplain-gtk-0.12-0   0.12.20-1
ii  libcheese-gtk25   3.34.0-1+b1
ii  libclutter-1.0-0  1.26.4+dfsg-1
ii  libclutter-gst-3.0-0  3.0.27-1
ii  libclutter-gtk-1.0-0  1.8.4-4
ii  libcogl-path201.22.6-1
ii  libcogl20 1.22.6-1
ii  libdbus-glib-1-2  0.110-5
ii  libenchant-2-22.2.8-1
ii  libfarstream-0.2-50.2.8-5
ii  libfolks-telepathy25  0.13.2-1
ii  libfolks250.13.2-1
ii  libgcr-base-3-1   3.36.0-2
ii  libgcr-ui-3-1 3.36.0-2
ii  libgdk-pixbuf2.0-02.40.0+dfsg-3
ii  libgee-0.8-2  0.20.3-1
ii  libgeocode-glib0  3.26.2-2
ii  libglib2.0-0  2.64.1-1
ii  libgoa-1.0-0b 3.36.0-1
ii  libgstreamer-plugins-base1.0-01.16.2-4
ii  libgstreamer1.0-0 1.16.2-2
ii  libgtk-3-03.24.14-1
ii  libgudev-1.0-0233-1
ii  libmission-control-plugins0   1:5.16.5-1
ii  libnotify40.7.9-1
ii  libpango-1.0-01.42.4-8
ii  libpulse-mainloop-glib0   13.0-5
ii  libpulse0 13.0-5
ii  libsecret-1-0 0.20.2-1
ii  libsoup2.4-1  2.70.0-1
ii  libtelepathy-farstream3   0.6.2-1+b2
ii  libtelepathy-glib00.24.1-2+b1
ii  libtelepathy-logger3  0.8.2-4
ii  libwebkit2gtk-4.0-37  2.28.0-2
ii  libx11-6  2:1.6.9-2
ii  libxml2   2.9.10+dfsg-4
ii  telepathy-logger  0.8.2-4
ii  telepathy-mission-control-5   1:5.16.5-1

Versions of packages empathy recommends:
ii  gnome-contacts   3.36-1
ii  gvfs-backends1.44.0-1
ii  sound-theme-freedesktop  0.8-2
ii  telepathy-gabble 0.18.4-1+b1
ii  telepathy-haze   0.8.0-2.1
ii  telepathy-salut  0.8.1-5.1

Versions of packages empathy suggests:
ii  telepathy-idle  0.2.0-2+b1
ii  vino3.22.0-6

Versions of packages empathy is related to:
ii  telep

Bug#955462: ITP: memo -- unix-style note-taking software

[Francisco Vilmar Cardoso Ruviaro]

Package: wnpp
Severity: wishlist
Owner: Francisco Vilmar Cardoso Ruviaro 

* Package name: memo
  Version : 1.7
  Upstream Author : Niko Rosvall 
* URL : https://github.com/nrosvall/memo
* License : GPL-3+
  Programming Lang: C
  Description : unix-style note-taking software

 Memo is a note-taking and to-do software that runs on command line.
 With Memo, it's possible to concentrate on the tasks in your to-do list
 instead of spending time managing those tasks. After a while taking notes
 and keeping a to-do list is part of your daily life instead of some nasty
 thing you must remember to do.

Bug#955461: ITP: NNStreamer -- GStreamer plugin set for neural network processing

[MyungJoo Ham]

Package: wnpp
Version: N/A; reported 2020-04-01
Severity: wishlist

* Package name : NNStreamer
Version : 1.5.1
Upstream Author : MyungJoo Ham 
* URL : https://github.com/nnstreamer/nnstreamer
* License : LGPL 2.1
Description : NNStreamer is a set of gstreamer plugins to support general 
neural networks and their plugins in a gstreamer stream pipeline. NNStreamer 
allows to create a stream pipeline consisting of multiple neural networks, 
sensor inputs, pre/post-processors, and media processors with gstreamer APIs.

NNStreamer is a Linux Foundation AI project.

Github: https://github.com/nnstreamer/nnstreamer
Wiki: https://wiki.lfai.foundation/display/NNSTREAM/NNStreamer+Home
Website: http://nnstreamer.ai/
Announcements (mailing list): 
https://lists.lfai.foundation/g/nnstreamer-announce
Bug reports: https://github.com/nnstreamer/nnstreamer/issues
Techinical discussions (mailing list): 
https://lists.lfai.foundation/g/nnstreamer-technical-discuss

Bug#955460: RFP: scikit-build -- Improved build system generator for CPython C, C++, Cython and Fortran extensions

[Bas Couwenberg]

Package: wnpp
Severity: wishlist

* Package name: scikit-build
  Version : 0.10.0
  Upstream Author : The scikit-build team 
* URL : https://github.com/scikit-build/scikit-build
* License : Expat
  Programming Lang: Python
  Description : Improved build system generator for CPython C, C++, Cython 
and Fortran extensions

 Improved build system generator for CPython C/C++/Fortran/Cython
 extensions.
 .
 Better support is available for additional compilers, build systems,
 cross compilation, and locating dependencies and determining their
 build requirements.
 .
 The scikit-build package is fundamentally just glue between the
 setuptools Python module and CMake.


Debian Science already maintains other scikit packages and is likely
a good umbrella for this package too.

Bug#955459: PTS: please support new FTP Masters ACCEPTED emails sender/signed-by format

[Sandro Tosi]

Package: qa.debian.org
Severity: normal

Hello,
recently FTP Masters implemented a change in the mail dak sent: while previously
the From header was set to the Changed-By .changes field, now it's sent as
"From: Debian FTP Masters " and the entries in
"News" section of PTS report that instead of the 'human' behind the upload.

Tracker.d.o already supports this new format, so please extend PTS to support it
too.

Some example:

package straight out of NEW:
https://packages.qa.debian.org/s/sphinxcontrib-devhelp.html
[ with "(Debian FTP Masters)" ]
vs
https://tracker.debian.org/pkg/sphinxcontrib-devhelp
[ with "(Debian FTP Masters) (signed by: Sandro Tosi)" ]

normal upload:
https://packages.qa.debian.org/p/pytest.htm
[ with "(Debian FTP Masters)" ]
vs
https://tracker.debian.org/pkg/pytest
[ with "(Sandro Tosi)" ]

Thanks!

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

Kernel: Linux 4.19.0-5-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= 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Bug#955458: evolution: daily limit exceeded cannot connect to google calandar

[william l-k]

Package: evolution
Version: 3.36.0-1
Severity: grave
Justification: renders package unusable

Dear Maintainer,

I guess let me know if this needs to be reported "upstream". I'm getting this
error every day now. Sometime in the evening my evolution calendar becomes
unusable and I receive this message:

Daily Limit Exceeded. The quota will be reset at midnight Pacific Time (PT).
You may monitor your quota usage and adjust limits in the API Console:
https://console.developers.google.com/apis/api/caldav.googleapis.com/quotas?project=44438659992

For example right now I would still be using my calendar to plan my time.
Instead I seem to be locked out of using google calendar. Right now it is 11
central time. So it sounds like I'll be able to use it again at 1am.

I don't know if this has anything to do with this error:

https://developers.google.com/analytics/devguides/config/mgmt/v3/limits-quotas

50,000 requests per project per day, which can be increased.
10 queries per second (QPS) per IP address.
In the API Console, there is a similar quota referred to as Requests
per 100 seconds per user. By default, it is set to 100 requests per 100 seconds
per user and can be adjusted to a maximum value of 1,000. But the number of
requests to the API is restricted to a maximum of 10 requests per second per
user.
If your application makes all API requests from a single IP address
(i.e., on behalf of your users), use the user IP or quota User parameter with
each request to get full QPS quota for each user. See the standard query
parameters summary for details.



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

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

Versions of packages evolution depends on:
ii  dbus   1.12.16-2
ii  evolution-common   3.36.0-1
ii  evolution-data-server  3.36.0-1
ii  libc6  2.30-2
ii  libcamel-1.2-623.36.0-1
ii  libclutter-gtk-1.0-0   1.8.4-4
ii  libecal-2.0-1  3.36.0-1
ii  libedataserver-1.2-24  3.36.0-1
ii  libevolution   3.36.0-1
ii  libglib2.0-0   2.64.1-1
ii  libgtk-3-0 3.24.14-1
ii  libical3   3.0.8-1
ii  libnotify4 0.7.9-1
ii  libsoup2.4-1   2.70.0-1
ii  libwebkit2gtk-4.0-37   2.28.0-2
ii  libxml22.9.10+dfsg-4
ii  psmisc 23.3-1

Versions of packages evolution recommends:
ii  evolution-plugin-bogofilter  3.36.0-1
ii  evolution-plugin-pstimport   3.36.0-1
ii  evolution-plugins3.36.0-1
ii  yelp 3.34.0-1

Versions of packages evolution suggests:
pn  evolution-ews   
pn  evolution-plugins-experimental  
ii  gnupg   2.2.20-1
ii  network-manager 1.22.6-1

-- debconf-show failed

Bug#955457: nautilus: dpkg-source failure bug when building it again

[Seunghun Han]

Package: nautilus
Version: 3.30.5-2
Severity: minor

Dear Maintainer,

I'm building nautilus for testing some features of it. However, I got
a problem with building it using the debuild command.

Once building this package is a success or not, the next build process
fails because of unwanted binary files in debian/tmp-home.

Here is the message.
```
$> debuild -us -uc
 dpkg-buildpackage -us -uc -ui
dpkg-buildpackage: info: source package nautilus
dpkg-buildpackage: info: source version 3.30.5-1
...[snip]...
dpkg-source --before-build .
dpkg-buildpackage: info: host architecture amd64
 debian/rules clean
dh clean --with gir,gnome
   dh_auto_clean
   dh_gnome_clean
   dh_clean
 dpkg-source -b .
dpkg-source: error: unwanted binary file: debian/tmp-home/run/dconf/user
dpkg-source: error: unwanted binary file:
debian/tmp-home/.local/share/tracker/data/tracker-store.ontology.journal
dpkg-source: error: unwanted binary file:
debian/tmp-home/.local/share/tracker/data/tracker-store.journal
dpkg-source: error: unwanted binary file:
debian/tmp-home/.local/share/gvfs-metadata/root-f20b605a.log
dpkg-source: error: unwanted binary file:
debian/tmp-home/.local/share/gvfs-metadata/root
dpkg-source: error: unwanted binary file:
debian/tmp-home/.cache/tracker/ontologies.gvdb
dpkg-source: error: unwanted binary file:
debian/tmp-home/.cache/tracker/meta.db-shm
dpkg-source: error: unwanted binary file: debian/tmp-home/.cache/tracker/meta.db
dpkg-source: error: unwanted binary file:
debian/tmp-home/.cache/tracker/meta.db-wal
dpkg-source: error: detected 9 unwanted binary files (add them in
debian/source/include-binaries to allow their inclusion).
dpkg-source: info: using source format '3.0 (quilt)'
dpkg-buildpackage: error: dpkg-source -b . subprocess returned exit status 255
debuild: fatal error at line 1182:
dpkg-buildpackage -us -uc -ui failed
```

After analyzing debian/rules file, I found that there was no removing
command for debian/tmp-home when cleaning it. For fixing this bug, I
have changed debian/rules for removing debian/tmp-home when cleaning
it.

Please check my merge-request,
https://salsa.debian.org/gnome-team/nautilus/-/merge_requests/8.

Best regards,

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

Kernel: Linux 4.19.0-8-amd64 (SMP w/4 CPU cores)
Locale: LANG=ko_KR.UTF-8, LC_CTYPE=ko_KR.UTF-8 (charmap=UTF-8),
LANGUAGE=ko_KR.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 nautilus depends on:
ii  bubblewrap 0.3.1-4
ii  desktop-file-utils 0.23-4
ii  gsettings-desktop-schemas  3.28.1-1
ii  gvfs   1.38.1-5
ii  libatk1.0-02.30.0-2
ii  libc6  2.28-10
ii  libcairo-gobject2  1.16.0-4
ii  libcairo2  1.16.0-4
ii  libgdk-pixbuf2.0-0 2.38.1+dfsg-1
ii  libgexiv2-20.10.9-1
ii  libglib2.0-0   2.58.3-2+deb10u2
ii  libglib2.0-data2.58.3-2+deb10u2
ii  libgnome-autoar-0-00.2.3-2
ii  libgtk-3-0 3.24.5-1
ii  libnautilus-extension1a3.30.5-2
ii  libpango-1.0-0 1.42.4-7~deb10u1
ii  libpangocairo-1.0-01.42.4-7~deb10u1
ii  libseccomp22.3.3-4
ii  libselinux12.8-1+b1
ii  libtracker-sparql-2.0-02.1.8-2
ii  nautilus-data  3.30.5-2
ii  shared-mime-info   1.10-1
ii  tracker2.1.8-2

Versions of packages nautilus recommends:
ii  gnome-sushi  3.30.0-2
ii  gvfs-backends1.38.1-5
ii  librsvg2-common  2.44.10-2.1

Versions of packages nautilus suggests:
ii  eog 3.28.4-2+b1
ii  evince [pdf-viewer] 3.30.2-3+deb10u1
ii  nautilus-extension-brasero  3.12.2-5
ii  nautilus-sendto 3.8.6-3
ii  totem   3.30.0-4
ii  xdg-user-dirs   0.17-2

-- no debconf information

Bug#955456: bitshuffle: FTBFS: test file tmp_test_filters.h5 does not exist)

[Drew Parsons]

The last successful build gave a warning at the same point,

H5pyDeprecationWarning: The default file mode will change to 'r' 
(read-only) in h5py 3.0. To suppress this warning, pass the mode you 
need to h5py.File()


If the test file is being created here, then perhaps
  f = h5py.File(fname, 'w')
needs to be used here instead of
  f = h5py.File(fname)

Likewise for other uses of h5py.File(fname) elsewhere in the bitshuffle 
tests.

Bug#955456: FTBFS: test file tmp_test_filters.h5 does not exist

[Drew Parsons]

Package: bitshuffle
Version: 0.3.5-3
Severity: serious
Justification: FTBFS
Control: block 954654 by -1

bitshuffle fails to build against hdf5: 1.10.6+repack-1, because
tmp_test_filters.h5 does not exist

OSError: Unable to open file (unable to open file: name = 
'tmp_test_filters.h5', errno = 2, error message = 'No such file or directory', 
flags = 0, o_flags = 0)


The test filename 'tmp_test_filters.h5' is hardcoded in l.26 of
bitshuffle/tests/test_h5filter.py


-- 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.4.0-4-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_AU:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages bitshuffle depends on:
ii  cython30.29.14-0.1+b1
ii  libc6  2.30-4
ii  libgomp1   10-20200324-1
ii  libhdf5-openmpi-1031.10.4+repack-11
ii  python33.8.2-2
iu  python3-h5py   2.10.0-5
ii  python3-numpy  1:1.17.4-5
ii  python3-pkg-resources  44.0.0-1

bitshuffle recommends no packages.

bitshuffle suggests no packages.

Bug#933749: fail2ban: ever-growing fail2ban sqlite database

[Salvatore Bonaccorso]

Hi Cyril,

On Wed, Apr 01, 2020 at 05:01:22AM +0200, Cyril Brulebois wrote:
> Hi,
> 
> Salvatore Bonaccorso  (2020-03-06):
> > [disclaimer not part of maintainers of fail2ban but was looking as
> > issues in fail2ban and stumpbled over this bug]
> 
> Noted.
> 
> > there was an upload of fail2ban to unstable based on the 0.11 branch
> > now, and Jakob mentioned that there support for actually purging
> > entries from database were in that branch.
> > 
> > Is the issue fixed with with any of the 0.11.1-1~exp1 upload?
> > (0.11.1-1 was uploaded to unstable).
> 
> I'm a little reluctant to trying a package from unstable into
> production, with that amount of changes:
> 
>  214 files changed, 9409 insertions(+), 3757 deletions(-)
> 
> The bug closure doesn't even seem certain (“hopefully”)…

Understandable, would not do as as well to install unstable packages
into production systems. Was just hoping you have a way to
trigger/reproduce and confirm.

Syvestre did close the bug in https://bugs.debian.org/933749#27 so if
someone affected can confirm this would be great. Otherwise whoever
encounters it after 0.11.1-1 can re-open the bug.

Regards,
Salvatore

Bug#954256: python-pip-whl: Editable installs broken: can't find __main__ module

[Scott Kitterman]

On Tue, 31 Mar 2020 15:03:30 -0400 Scott Kitterman  
wrote:
> On Fri, 27 Mar 2020 08:50:28 -0400 Scott Kitterman  
> wrote:
> > On Fri, 27 Mar 2020 01:39:04 -0400 Scott Kitterman  
> > wrote:
> > > On Fri, 27 Mar 2020 01:25:28 -0400 Scott Kitterman 
 
> > > wrote:
> > > > I can replicate this with the current pip in unstable (which is the 
> > current 
> > > > upstream release).  We kept pep517 at version 0.7.0 because that's the 
> > > version 
> > > > that pip bundles and there are no other users of it in the archive.  I 
> > > > upgraded pep517 to the current release and the problem went away.  I 
> think 
> > > > this is a pep517 problem.  I even see what looks like a relevant 
commit 
> > > > (although I'm not sure).
> > > 
> > > I've uploaded the updated pep517.  This problem won't be fully solved 
> until 
> > > python-pip is rebuilt to update the provided wheel.  I'll do that 
> tomorrow.
> > 
> > Testing this again with the updated pep517 it still fails, just in a 
> slightly 
> > different way, so I reopened the bug.  I still think this is something in 
> > pep517, so the reassignment was correct.
> 
> I have confirmed that if we aren't using a debundled pep517 (the path is 
> different), it all works.  Upstream supports debundling so there is a bug 
here 
> somewhere and I still think it's in pep517.  I intend to leave this open to 
> track the issue, but I am changing our pip package to use the bundled pep517 
> to work around this for now.

The newer pep517 made changes to make it zip safe, but they were incomplete.  
That's why the error changes with the current pep517 release.  It almost 
works.

Scott K

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

Bug#912379: Bug #912379: /usr/bin/pip3: TypeError on "list --outdated": uses different Version implementations

[Scott Kitterman]

On Tue, 30 Oct 2018 21:50:36 +0100 Ben Wiederhake 
 wrote:
> Package: python3-pip
> Version: 9.0.1-2.3
> Severity: normal
> File: /usr/bin/pip3
> 
> Dear Maintainer,
> 
> I'm having trouble running this command:
> 
> pip3 list --outdated
> 
> Expected behavior: A list of outdated, local packages
> Actual behavior: TypeError
> 
> Full error message:
> 
> Traceback (most recent call last):
>   File "/usr/lib/python3/dist-packages/pip/basecommand.py", line 215, in
> main
> status = self.run(options, args)
>   File "/usr/lib/python3/dist-packages/pip/commands/list.py", line 157, 
in
> run
> packages = self.get_outdated(packages, options)
>   File "/usr/lib/python3/dist-packages/pip/commands/list.py", line 168, 
in
> get_outdated
> dist for dist in self.iter_packages_latest_infos(packages, options)
>   File "/usr/lib/python3/dist-packages/pip/commands/list.py", line 169, 
in
> 
> if dist.latest_version > dist.parsed_version
> TypeError: '>' not supported between instances of 'Version' and 
'Version'
> 
> This is not Debian #878082.
> 
> Arch had a similar problem, there it was a packaging error:
> 
> https://github.com/pypa/pip/issues/5429
> 
> Could it be that the Debian package has a similar issue?

The problem turns out to be that setuptools and pip have different approaches 
for managing the namespace for packages they vendor and they are incompatible.  
Thanks to the incomparable dstufft for figuring it out.  The attached patch 
works around this incompatibility.  I've tested it with pip 20.2 on unstable 
and it resolves the issue.  This or something similar should work on earlier 
versions too.

Scott K--- a/src/pip/_internal/commands/list.py	2019-12-09 04:01:21.0 +
+++ b/src/pip/_internal/commands/list.py	2020-04-01 03:10:23.480796645 +
@@ -22,6 +22,8 @@
 )
 from pip._internal.utils.packaging import get_installer
 
+from pip._vendor.packaging.version import parse
+
 logger = logging.getLogger(__name__)
 
 
@@ -164,13 +166,13 @@
 def get_outdated(self, packages, options):
 return [
 dist for dist in self.iter_packages_latest_infos(packages, options)
-if dist.latest_version > dist.parsed_version
+if parse(str(dist.latest_version)) > parse(str(dist.parsed_version))
 ]
 
 def get_uptodate(self, packages, options):
 return [
 dist for dist in self.iter_packages_latest_infos(packages, options)
-if dist.latest_version == dist.parsed_version
+if parse(str(dist.latest_version)) == parse(str(dist.parsed_version))
 ]
 
 def get_not_required(self, packages, options):


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

Bug#955455: poppler should be built with boost (headers only)

[Hubert Figuière]

Package: poppler
Version: 0.85.0-1

Hi,

Certain speed improvements in poppler's pdftoppm need boost (headers
only). This is since 0.80. If boost headers are available at build time,
they are used.

That would be nice to add this build dependency.

Without it you probably get a warning message during the configure
process (CMake): "Warning: Use of boost is recommended for better
performance."

Thanks,

Hub

Bug#933749: fail2ban: ever-growing fail2ban sqlite database

[Cyril Brulebois]

Hi,

Salvatore Bonaccorso  (2020-03-06):
> [disclaimer not part of maintainers of fail2ban but was looking as
> issues in fail2ban and stumpbled over this bug]

Noted.

> there was an upload of fail2ban to unstable based on the 0.11 branch
> now, and Jakob mentioned that there support for actually purging
> entries from database were in that branch.
> 
> Is the issue fixed with with any of the 0.11.1-1~exp1 upload?
> (0.11.1-1 was uploaded to unstable).

I'm a little reluctant to trying a package from unstable into
production, with that amount of changes:

 214 files changed, 9409 insertions(+), 3757 deletions(-)

The bug closure doesn't even seem certain (“hopefully”)…


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


signature.asc
Description: PGP signature

Bug#912379: Please update the pip package

[Scott Kitterman]

On Tue, 17 Mar 2020 10:38:23 -0400 Scott Kitterman  
wrote:
> On Fri, 10 Jan 2020 00:02:12 -0800 Nye Liu  wrote:
> > this bug is now more than a year old.
> > 
> > Please update python3-pip and python-pip packages to >19.1
> 
> The same problem still exists with 20.2 in unstable.  It appears that the 
> fundamental problem is that pip uses a modified pkg_resources copy (despite 
> their own rules to not modify vendored code) and then blames downstreams for 
> unbundling (which they do support).

This turned out to be nonsense.  Please ignore.

Scott K

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

Bug#955390: grub-install: error: failed to register the EFI boot entry: Bad address.

[Cyril Brulebois]

Hey,

and thanks for the triaging (sorry for the noise).

Steve McIntyre  (2020-03-31):
> On Tue, Mar 31, 2020 at 03:16:54AM +0200, Cyril Brulebois wrote:
> >This system was initially installed with jessie with grub-pc on MBR,
> >upgraded to stretch, switched to grub-efi-amd64 on UEFI (to handle
> >bigger disks), and that was working rather fine.
> >
> >Upgrading to buster, I'm now seeing this when trying to configure the
> >shim-signed-common package. I'm enclined to think it might be a GRUB
> >issue instead, but I'm filing this against the affected package anyway
> >since I don't know any better (maybe shim-* is triggering some GRUB
> >issue…) at the moment.
> 
> This is definitely an issue from grub-install rather than shim*. It's
> Colin's new code in grub-install that's throwing errors. As to why,
> I'm not sure I'm afraid...
> 
> >Setting up shim-signed-common (1.33+15+1533136590.3beb971-7) ...
> >Installing for x86_64-efi platform.
> >File descriptor 3 (pipe:[21154245]) leaked on vgs invocation. Parent PID 
> > 3633: grub-install
> >File descriptor 3 (pipe:[21154245]) leaked on vgs invocation. Parent PID 
> > 3633: grub-install
> >grub-install: warning: efivarfs_get_variable: 
> > open(/sys/firmware/efi/efivars/blk0-47c7b225-c42a-11d2-8e57-00a0c969723b): 
> > No such file or directory.
> >grub-install: warning: efi_get_variable: ops->get_variable failed: No 
> > such file or directory.
> >grub-install: warning: efi_va_generate_file_device_path_from_esp: could 
> > not open device for ESP: Bad address.
> >grub-install: warning: efi_generate_file_device_path_from_esp: could not 
> > generate File DP from ESP: Bad address.
> >grub-install: error: failed to register the EFI boot entry: Bad address.
> >dpkg: error processing package shim-signed-common (--configure):
> > installed shim-signed-common package post-installation script 
> > subprocess returned error exit status 1
> >dpkg: dependency problems prevent configuration of shim-signed:amd64:
> > shim-signed:amd64 depends on shim-signed-common (= 
> > 1.33+15+1533136590.3beb971-7); however:
> >  Package shim-signed-common is not configured yet.
> >
> >dpkg: error processing package shim-signed:amd64 (--configure):
> > dependency problems - leaving unconfigured
> >Errors were encountered while processing:
> > shim-signed-common
> > shim-signed:amd64
> >
> >Feel free to let me know if you'd rather see me file a bug report
> >against one of the GRUB binary instead…
> 
> I'd say reassign to grub2-common; that's where grub-install comes
> from. Doing that now.

I'm attaching data gathered by grub2-common's bug script, in case that
helps.


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

*** BEGIN /proc/mounts
/dev/mapper/data-root / ext4 rw,relatime,errors=remount-ro 0 0
/dev/md4 /boot/efi vfat 
rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=ascii,shortname=mixed,utf8,errors=remount-ro
 0 0
/dev/mapper/anchorage-glenfiddich /srv/anchorage/glenfiddich ext4 rw,relatime 0 0
/dev/mapper/data-hobbes /data/hobbes ext4 rw,relatime 0 0
/dev/mapper/anchorage-media /media ext4 rw,relatime 0 0
/dev/mapper/data-home /home ext4 rw,relatime 0 0
/dev/mapper/data-media /data/media xfs rw,relatime,attr2,inode64,noquota 0 0
/dev/mapper/anchorage-backups /backups ext4 rw,relatime 0 0
/dev/sde1 /mnt/borg-on-rdx ext4 rw,relatime 0 0
*** END /proc/mounts

*** BEGIN /boot/grub/grub.cfg
#
# DO NOT EDIT THIS FILE
#
# It is automatically generated by grub-mkconfig using templates
# from /etc/grub.d and settings from /etc/default/grub
#

### BEGIN /etc/grub.d/00_header ###
if [ -s $prefix/grubenv ]; then
  set have_grubenv=true
  load_env
fi
if [ "${next_entry}" ] ; then
   set default="${next_entry}"
   set next_entry=
   save_env next_entry
   set boot_once=true
else
   set default="0"
fi

if [ x"${feature_menuentry_id}" = xy ]; then
  menuentry_id_option="--id"
else
  menuentry_id_option=""
fi

export menuentry_id_option

if [ "${prev_saved_entry}" ]; then
  set saved_entry="${prev_saved_entry}"
  save_env saved_entry
  set prev_saved_entry=
  save_env prev_saved_entry
  set boot_once=true
fi

function savedefault {
  if [ -z "${boot_once}" ]; then
saved_entry="${chosen}"
save_env saved_entry
  fi
}
function load_video {
  if [ x$feature_all_video_module = xy ]; then
insmod all_video
  else
insmod efi_gop
insmod efi_uga
insmod ieee1275_fb
insmod vbe
insmod vga
insmod video_bochs
insmod video_cirrus
  fi
}

if [ x$feature_default_font_path = xy ] ; then
   font=unicode
else
insmod part_gpt
insmod part_gpt
insmod diskfilter
insmod mdraid1x
insmod lvm
insmod ext2
set 
root='lvmid/kUwcO4-Olzm-ff9s-hqBf-cVEL-9trv-EEfnhU/HFDoEk-MFug-WYeR-K0Fa-H3gp-H2O5-w6OyNy'
if [ x$feature

Bug#955434: tracker.d.o: please integrate information from buildinfos.debian.net

[Paul Wise]

On Tue, Mar 31, 2020 at 5:09 PM Holger Levsen wrote:

> The information we would like to have integrated into tracker.d.o is a
> link to .buildinfo files for source packages, based on the architecture
> the build was done.
...
> https://buildinfos.debian.net/buildinfo-pool/ provides a pool structure
> of this data, for example to 
> https://buildinfos.debian.net/buildinfo-pool/libf/libfakekey/libfakekey_0.1-10_hurd-i386.buildinfo

It sounds like something like this is what is wanted in the links panel?

buildd: logs, ... https://buildinfos.debian.net/buildinfo-pool/libf/libfakekey/";
title=".buildinfo files for official builds">info

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Bug#955454: bsdgames-nonfree: cannot spawn monster on same row as player

[William Chargin]

Package: bsdgames-nonfree
Version: 2.17-6build1
Severity: normal
Tags: patch

Dear Maintainer,

I was reading the source for Rogue when I noticed the following curious
condition in the `create_monster` function:

if (((row == rogue.row) && (col = rogue.col)) ||
(row < MIN_ROW) || (row > (DROWS-2)) ||
(col < 0) || (col > (DCOLS-1))) {
continue;
}

The `(col = rogue.col)` looks suspect to me; should this perhaps read
`(col == rogue.col)`?

All other callers of `rand_around` do properly check `col == rogue.col`
rather than assigning to it (if they attempt to check it at all).

I'm pretty sure that I actually just hit this bug in game. I was in a
1-high tunnel and read a scroll of create monster, which failed:

$ head rogue.screen
you hear a faint cry of anguish in the distance
   -
   |   +#@
|  | ##+  %|
|  +## |   |
---+   -
   #
   #
   #
   #

>From this code, we can see that the only place that the monster could
have spawned was the tile to the left of the player, but that iteration
of the loop was skipped because `(col = rogue.col)` evaluates to 65,
which is true.

Please find enclosed a patch, should you choose to use it. (Consider it
released into the public domain; let me know if you want a specific
license.)

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

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

Versions of packages bsdgames-nonfree depends on:
ii  libc62.23-0ubuntu11
ii  libncurses5  6.0+20160213-1ubuntu1
ii  libtinfo56.0+20160213-1ubuntu1

bsdgames-nonfree recommends no packages.

Versions of packages bsdgames-nonfree suggests:
pn  bsdgames  

-- no debconf information
>From 3b3ff8bfb04224866b7573e0bf620299313ca9b4 Mon Sep 17 00:00:00 2001
From: William Chargin 
Date: Tue, 31 Mar 2020 19:39:13 -0700
Subject: [PATCH] monster: permit spawning on same row as player

Due to a typo, the `(row == rogue.row) && (col = rogue.col)` check is
effectively equivalent to `(row == rogue.row)`. This prevents monsters
from spawning on the same row as the player when a scroll of create
monster is read.

To reproduce, play Rogue until you find a scroll of create monster, then
enter a horizontal tunnel such that the only adjacent spaces are in the
same row as the player. Read the scroll, and note that you "hear a faint
cry of anger in the distance".
---
 rogue/monster.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/rogue/monster.c b/rogue/monster.c
index 2bcc25d..30b0705 100644
--- a/rogue/monster.c
+++ b/rogue/monster.c
@@ -688,7 +688,7 @@ create_monster()
 
 	for (i = 0; i < 9; i++) {
 		rand_around(i, &row, &col);
-		if (((row == rogue.row) && (col = rogue.col)) ||
+		if (((row == rogue.row) && (col == rogue.col)) ||
 (row < MIN_ROW) || (row > (DROWS-2)) ||
 (col < 0) || (col > (DCOLS-1))) {
 			continue;
-- 
2.26.0

Bug#954460: remove mentions of "volatile" repo from sources.list

[Cyril Brulebois]

Hello Samuel,

Samuel Henrique  (2020-03-31):
> Hello Cyril,
> 
> > I'm wondering whether we should have a pointer to some documentation
> > that would explain what that is. I seem to have this in my web browser
> > history;
> >
> >   https://lists.debian.org/debian-devel-announce/2011/03/msg00010.html
> >
> > but there might better places, like this one?
> >
> >   https://wiki.debian.org/StableUpdates
> 
> I like your suggestion, this is a good opportunity to link some
> documentation explaining a little bit of how updates are done for
> stable releases.

OK, great.

> I would be reluctant to add any reference to the wiki at all because
> it has some ip addresses blacklisted and I remember having multiple
> cases of Brazilian users being unable to access it because they were
> under a blacklisted shared public ip.
> The debian-reference[0] seems like a good thing to point to instead,
> although not explaining "-updates" as well as the wiki, maybe that
> could be changed,
> 
> What are your thoughts?
> 
> [0]https://www.debian.org/doc/manuals/debian-reference/ch02.en.html#_updates_and_backports

Would the following look like some reasonable middle ground?

 1. Link to the wiki for the time being, getting rid of volatile, and
pointing users without any IP restrictions to some documentation.
 2. Get the ball rolling to update the devref.
 3. Switch the link from the wiki to the devref once the latter is
updated.


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


signature.asc
Description: PGP signature

Bug#955208: rustc: rustup is not available on Debian

[Ralph Giles]

I would also like to start off with a Debian-packaged rustup rather
than having to install it from upstream.

It's been discussed before, but I think no one was pursuaded to start
maintaining a package. IIRC one issue was that rustup likes to update
itself. You'd need to check how difficult it would be to have the
system rustup always just install any updates in the user's .cargo
subtree, without trying to write to the root filesytem. The user's
local version would then take precedence through the normal PATH
setting.

I think there was also some concern about support over the lifetime of
a debian release, should upstream change their API sufficiently to stop
the packaged version working.

 -r

On Sat, 2020-03-28 at 14:04 +0100, Martin Monperrus wrote:
> Package: rustc
> Version: 1.40.0+dfsg1-5
> Severity: normal
> 
> Dear Awesome Rust Debian Maintainers,
> 
> I notice that rustup is not packaged for Debian. One option is to go
> through
> snap (https://snapcraft.io/install/rustup/debian) but native packages
> are
> preferable.
> 
> Since rustup is used by many projects, it would be great to have it
> natively on
> Debian:
> 
> apt-get install rustup
> 
> What do you think?
> 
> Best regards,
> 
> --Martin
> 
> 
> 
> 
> 
> -- System Information:
> Debian Release: bullseye/sid
>   APT prefers unstable
>   APT policy: (500, 'unstable')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
> 
> Kernel: Linux 5.4.0-4-amd64 (SMP w/4 CPU cores)
> Kernel taint flags: TAINT_WARN, TAINT_CRAP, 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 rustc depends on:
> ii  binutils  2.34-5
> ii  gcc   4:9.2.1-3.1
> ii  libc6 2.30-2
> ii  libc6-dev [libc-dev]  2.30-2
> ii  libgcc-s1 [libgcc1]   10-20200324-1
> ii  libgcc1   1:10-20200324-1
> ii  libllvm9  1:9.0.1-10
> ii  libstd-rust-dev   1.40.0+dfsg1-5
> ii  libstdc++610-20200324-1
> 
> Versions of packages rustc recommends:
> ii  cargo 0.40.0-3
> ii  rust-gdb  1.40.0+dfsg1-5
> 
> Versions of packages rustc suggests:
> pn  lld-9 
> pn  rust-doc  
> pn  rust-src  
> 
> -- no debconf information
> 


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

Bug#955453: avoid pointing upstream metadata at mirror / old repository URLs

[Jelmer Vernooij]

Package: lintian-brush
Version: 0.59
Severity: normal

When determining the upstream repository URL, lintian-brush should try harder
to filter out (or perhaps just downgrade the certainty) for cases where the
upstream repository has moved. Example cases:

* https://salsa.debian.org/utopia-team/pipewire/-/merge_requests/2#note_151419
* https://salsa.debian.org/debian/iio-sensor-proxy/-/merge_requests/1

Some ideas for how to detect these:

* Check the GitHub description for the word "mirror"

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

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

Versions of packages lintian-brush depends on:
ii  devscripts   2.20.2
ii  python3  3.8.2-2
ii  python3-breezy   3.0.2-5
ii  python3-debian   0.1.36
ii  python3-distro-info  0.23
ii  python3-dulwich  0.19.15-1
ii  python3-iniparse 0.4-3
ii  python3-levenshtein  0.12.0-5
ii  python3-pkginfo  1.4.2-3
ii  python3-ruamel.yaml  0.15.89-3+b1

Versions of packages lintian-brush recommends:
ii  dos2unix   7.4.0-2
ii  gpg2.2.20-1
ii  libdebhelper-perl  12.10
ii  lintian2.61.0
ii  python3-asyncpg0.20.1-1
ii  python3-pyinotify  0.9.6-1.2

Versions of packages lintian-brush suggests:
pn  gnome-pkg-tools
ii  postgresql-common  214

-- no debconf information

Bug#915458: multibootusb builds multi-boot live-usb's, but it bundles compiled free software

[Calum McConnell]

I cracked open the package, and it seems almost straightforward, except
for two complications: it bundles a compiled version of GRUB for i386
and amd64, as well as some other compiled tools.  I think any working
package would need to rewrite that to use a version of GRUB installed
already on the machine: but I don't know enough about Debian packaging
or boot systems to comfortably rework this for full policy
compatability (ie, being able to build and use the arch-appropriate
GRUB version).

Some possibilities would be to (somehow) download the Grub package for
the appropriate arch, and use the compiled files from there during
runtime.  AFAIK, the software needs to download from the internet
anyways for its core functionality.

Guidance would be much appreciated.  Salsa link is:
https://salsa.debian.org/CalumMcConnell-guest/multibootusb


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

Bug#945875: openmw: Crash when saving

[Павел Алиев]

OpenMV package code also must be updated with code from git because
the current package can't be built with OSG 3.6.5.

With fresh OSG (3.6.5 stable) and latest OpenMW (from git) game save
process isn't caused to crash.

Bug#636977: Interest in packaging Boot-Repair

[Calum McConnell]

Hi! I have interest in packaging boot-repair, as it helped to save my
own dual-boot.  I started to repackage it, but I became unsure about
whether I should.  It is a maintained PPA, and so it already has a
functional control file.  I wasn't sure what I should put as (for
instance) the "maintainer".

This is my first package for debian, so guidance would be appreciated.


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

Bug#955452: Add example of running once every nth day, even across week, month, and year boundaries

[積丹尼 Dan Jacobson]

Package: cron
Version: 3.0pl1-136
Severity: minor
File: /usr/share/man/man5/crontab.5.gz

In section EXAMPLE CRON FILE please add
   # Run once every 9th day, even across week, month, and year boundaries:
   33 22 * * * expr $(date +\%s) / 60 / 60 / 24 \% 9 > /dev/null || 
echo Wax the floor.

Bug#816906: Still interested

[Daniel Leidert]

Hi there,

the packaging attempt for this ITP has stalled since 2016. Are you still
intersted in this ITP?

Regards, Daniel


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

Bug#955451: bug #955451

[Yetoo Happy]

Also, for clarification, the attached file is an example power point file
that was saved with powerpoint included in Microsoft Office Professional
Plus 2016. The text should be duplicated and shifted up. The line near the
top is an empty equation. Usually the text will overlap more, possibly due
to smaller text size.

I also would like to add, that the either kerning of the original text, the
antialiasing, or the clearness gets messed up and so it looks like the
characters cut if they extend out of their cells. Plus when zooming in, it
looks like the original text is more pixelated than the duplicate text. If
one saves the powerpoint viewed in Impress, the duplicated text will remain
when viewed in Microsoft Powerpoint and the original text also looks
blurry/jagged like when viewed in Impress.

Bug#916908: Still interested?

[Daniel Leidert]

Hi,

is this ITP still valid? The gem you are going to package is more then 9 years
old. What is the use case?

Regards, Daniel


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

Bug#955451: libreoffice-impress: Text gets duplicated and shifted if equation is in the same slide

[Scott Cohen]

Package: libreoffice-impress
Version: 1:6.1.5-3+deb10u5
Severity: important
Tags: a11y

Hello,

If an equation is in the same slide as text that was saved in a 
powerpoint 2007-2019 format (pptx) using a contemporary version of 
Microsoft Powerpoint (I personally tested with Microsoft Office 
Professional Plus 2016, but it probably also happens with other and 
later versions)), then all text in the slide will duplicate and the 
duplicate text will shift up and overlay ontop of the original text 
making the text  hard to read. I tested this on the latest version of 
LibreOffice (6.4.2.2 Windows 10 build) and it's not an issue in that 
version. I expect the text not to be duplicated to a point of being 
hard to read.  

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

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

Versions of packages libreoffice-impress depends on:
ii  libc62.28-10
ii  libepoxy01.5.3-0.1
ii  libetonyek-0.1-1 0.1.9-1
ii  libgcc1  1:8.3.0-6
ii  libmwaw-0.3-30.3.14-1
ii  libodfgen-0.1-1  0.1.7-1
ii  libreoffice-core 1:6.1.5-3+deb10u5
ii  libreoffice-draw 1:6.1.5-3+deb10u5
ii  librevenge-0.0-0 0.0.4-6
ii  libstaroffice-0.0-0  0.0.6-1
ii  libstdc++6   8.3.0-6
ii  libxml2  2.9.4+dfsg1-7+b3
ii  uno-libs36.1.5-3+deb10u5
ii  ure  6.1.5-3+deb10u5
ii  zlib1g   1:1.2.11.dfsg-1

Versions of packages libreoffice-impress recommends:
ii  libreoffice-avmedia-backend-gstreamer  1:6.1.5-3+deb10u5

Versions of packages libreoffice-impress suggests:
ii  bluez  5.50-1.2~deb10u1

Versions of packages libreoffice-core depends on:
ii  fontconfig2.13.1-2
ii  fonts-opensymbol  2:102.10+LibO6.1.5-3+deb10u5
ii  libboost-date-time1.67.0  1.67.0-13+deb10u1
ii  libboost-locale1.67.0 1.67.0-13+deb10u1
ii  libc6 2.28-10
ii  libcairo2 1.16.0-4
ii  libclucene-contribs1v52.3.3.4+dfsg-1
ii  libclucene-core1v52.3.3.4+dfsg-1
ii  libcmis-0.5-5v5   0.5.2-1
ii  libcups2  2.2.10-6+deb10u2
ii  libcurl3-gnutls   7.64.0-4+deb10u1
ii  libdbus-1-3   1.12.16-1
ii  libdbus-glib-1-2  0.110-4
ii  libdconf1 0.30.1-2
ii  libeot0   0.01-5
ii  libepoxy0 1.5.3-0.1
ii  libexpat1 2.2.6-2+deb10u1
ii  libexttextcat-2.0-0   3.4.5-1
ii  libfontconfig12.13.1-2
ii  libfreetype6  2.9.1-3+deb10u1
ii  libgcc1   1:8.3.0-6
ii  libglib2.0-0  2.58.3-2+deb10u2
ii  libgpgmepp6   1.12.0-6
ii  libgraphite2-31.3.13-7
ii  libharfbuzz-icu0  2.3.1-1
ii  libharfbuzz0b 2.3.1-1
ii  libhunspell-1.7-0 1.7.0-2
ii  libhyphen02.8.8-7
ii  libice6   2:1.0.9-2
ii  libicu63  63.1-6+deb10u1
ii  libjpeg62-turbo   1:1.5.2-2+b1
ii  liblcms2-22.9-3
ii  libldap-2.4-2 2.4.47+dfsg-3+deb10u1
ii  libmythes-1.2-0   2:1.2.4-3
ii  libneon27-gnutls  0.30.2-3
ii  libnspr4  2:4.20-1
ii  libnss3   2:3.42.1-1+deb10u2
ii  libnumbertext-1.0-0   1.0.5-1
ii  libodfgen-0.1-1   0.1.7-1
ii  liborcus-0.14-0   0.14.1-6
ii  libpng16-16   1.6.36-6
ii  libpoppler82  0.71.0-5
ii  librdf0   1.0.17-1.1+b1
ii  libreoffice-common1:6.1.5-3+deb10u5
ii  librevenge-0.0-0  0.0.4-6
ii  libsm62:1.2.3-1
ii  libstdc++68.3.0-6
ii  libx11-6  2:1.6.7-1
ii  libxext6  2:1.3.3-1+b2
ii  libxinerama1  2:1.1.4-2
ii  libxml2   2.9.4+dfsg1-7+b3
ii  libxmlsec11.2.27-2
ii  libxmlsec1-nss1.2.27-2
ii  libxrandr22:1.5.1-1
ii  libxrender1   1:0.9.10-1
ii  libxslt1.11.1.32-2.2~deb10u1
ii  uno-libs3 6.1.5-3+deb10u5
ii  ure   6.1.5-3+deb10u5
ii  zlib1g1:1.2.11.dfsg-1

Versions of packages libreoffice-core recommends:
ii  libpaper-utils  1.1.28

Versions of packages libreoffice-draw depends on:
ii  libavahi-client3 0.7-4+b1
ii  libavahi-common3 0.7-4+b1
ii  libc62.28-10
ii  libcdr-0.1-1 0.1.5-1
ii  libdbus-1-3  1.12.16-1
ii  libdbus-glib-1-2 0.110-4
ii  libfreehand-0.1-10.1.2-2
ii  libgcc1  1:8.3.0-6
ii  libglib2.0-0 2.58.3-2+deb10u2
ii  libicu63 63.1-6+deb10u1
ii  liblcms2-2   2.9-3
ii  libmspub-0.1-1   

Bug#955438: grpc: libupb.so.9 is not installed in any binary package

[GCS]

On Tue, Mar 31, 2020 at 8:12 PM Pirate Praveen  wrote:
> Severity: serious
> Justification: ftbfs on buster
>
> When building in buster (buster-backports branch on salsa), build fails
> with error
 Meaning it does _not_ FTBFS in Sid or Bullseye. Any pointers where
it's defined in our policy that backports must be buildable without
changes in normal packaging?

> dh_missing --list-missing
> dh_missing: warning: usr/lib/x86_64-linux-gnu/libupb.so exists in
> debian/tmp but is not installed to anywhere
> dh_missing: warning: usr/lib/x86_64-linux-gnu/libupb.so.9 exists in
> debian/tmp but is not installed to anywhere
> dh_missing: warning: usr/lib/x86_64-linux-gnu/libupb.so.9.0.0 exists in
> debian/tmp but is not installed to anywhere
> dh_missing: warning: usr/lib/x86_64-linux-gnu/libupb.a exists in
> debian/tmp but is not installed to anywhere
 Reason is simple. It's an _external_ project and does _not_ needed in
Sid / Bullseye as those use the normal protobuf packages.
Please see that it's a third_party library[1] in gRPC, developed
independently[2] and that it's _not_ a full implementation (but a
micro, subset one)[3].
In short it seems you might backported protobuf incorrectly or simply
don't use that for the backported grpc package - needs checking of
course.
I say a third party project should be packaged independently and I
might do it if you really need it, but no intention to ship that from
gRPC itself. Correct me if I'm wrong.

Regards,
Laszlo/GCS
[1] https://github.com/grpc/grpc/tree/master/third_party/upb
[2] https://github.com/protocolbuffers/upb
[3] https://github.com/protocolbuffers/upb/wiki

Bug#954742: evolution: Error performing TLS handshake: A packet with illegal or unsupported version was received.

[Hatem Masmoudi]

Hello,

After some analysis, it look like TLS1.0 and TLS 1.1 where disabled through 
glib-networking starting from version 2.64.x 
(https://gitlab.gnome.org/GNOME/glib-networking/-/commit/0f5938dbc7ac92913673c102b5707675ca8a0eb9)

As a workaround is to execute evolution as the following : > export 
G_TLS_GNUTLS_PRIORITY="NORMAL:%COMPAT:+VERS-TLS1.0" ; evolution

Best regard,
Hatem Masmoudi
On Tue, 31 Mar 2020 18:37:41 +0100 Hatem Masmoudi 
mailto:hatem.masmo...@groupe-telnet.net>> 
wrote:
> Hello,
>
> Same issue here using evolution 3.36.1 with MS exchange Server supprting only 
> TLS1.0.
>
> 
>
> < HTTP/1.1 6 Error performing TLS handshake: A packet with illegal or 
> unsupported version was received.
> < Soup-Debug-Timestamp: 1585676181
> < Soup-Debug: ESoapMessage 0 (0x55fd0188f770)
>
> 
>
> Any possiblity to enable TLS1.0 support ?
>
> Thanks.
>
> Best  Regard,
>
> Hatem Masmoudi

Bug#954371: [Pkg-openssl-devel] Bug#954371: libio-socket-ssl-perl: FTBFS since openssl 1.1.1e

[Kurt Roeckx]

On Tue, Mar 31, 2020 at 11:48:26PM +0200, Steffen Ullrich wrote:
> > You should fix your tests not to trigger an unexpected EOF. You
> > probably have code now that ignores the current error, you
> > shouldn't ignore that error, it's a real error.
> 
> Fixing the tests to only consider an ideal world of nicely behaving peers is
> in my opinion the wrong way to go.  Instead I think that it is very useful
> to have tests which include bad behaved peers since such peers are
> unfortunately a reality. And it would be good if IO::Socket::SSL would
> provide a defined and stable behavior in such situations and that the tests
> check this. As for how this behavior should exactly look like I'm not fully
> sure yet and I have to figure this out before OpenSSL 3.0.0 gets released.

I do agree that testing for errors is important. I assumed that some
tests failed because they ignored the error, but I guess they can
also fail because they a different error than the one they expected.


Kurt

Bug#955450: ITP: ruby-minitest-power-assert -- power assert implementation for minitest

[Daniel Leidert]

Package: wnpp
Severity: wishlist
Owner: Daniel Leidert 

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

* Package name: ruby-minitest-power-assert
  Version : 0.3.1
  Upstream Author : Hiroshi SHIBATA
* URL : https://github.com/hsbt/minitest-power_assert
* License : BSD-2-clause
  Programming Lang: Ruby
  Description : power assert implementation for minitest

The minitest-power_assert gem overrides the Ruby #assert method to provide
an implementation for Minitest.

This package is required for some Ruby libraries to run their test-suites.

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEvu1N7VVEpMA+KD3HS80FZ8KW0F0FAl6DvgIACgkQS80FZ8KW
0F2p9g//UTbqxO13mRCdVN/LTcFhQAwZS4+9ovNkPHfKsy+5p+k4lqdNYRUpAxhI
2AHHQ5Da4DayGfFV7xbhxwcSgZasMcR+dZOplh9CXbulUejk9ZXJB+dDSwCGy9jf
KHjK24w9XQzAT7sb5Vfx224zc+zINbUDLhP4IUDdyNyrnxh0RwETz8ICFQJE3zmk
sv7p3KFYfuyUi3RcgWtRyuc1MgB34ZGKMxH24o0ckU4Ftbqrr48khTVQh659tNG7
5usIEx9L+f+9sVQIKt2pwSXYYJ5YcgykxjSmcqTbkWoclkoomW5LMU+E3mksE8iK
tNgi64Yxs7WRMQ9n5qMbyDyhCVF9IoqdNnOIqp1H8JmNxRZu2ApUXvdWWeYlcF7p
c01Y7P0061gZL3SB/k0wAPLxf1fGttVJkYUuCFtUU8HsJTS79b4sAVSJtBuJG2KK
ktf1ebD7Q2LUKN/UpN1+z9f7gODMVU/z3DVfVRYM9W6R++fJMZtyijTpqGlIdS+O
Par8Oxdt6zZuOAH9V9mXXle17ZdtTSCLJ++sh23F8dEsgUK7pnsu0Bzdo+HSaRWV
sXPMYDjuYKsOfy4uatbHJzNlnWxtXD7CwhnMnmJ+kGhPnedOJtOJ5WqUHi3Y8m3w
XazRvvO4pkZUzIY/gBSxsiqM4ZphkU68R32IOdpXZOpZ0T44ToU=
=HitN
-END PGP SIGNATURE-

Bug#954371: [Pkg-openssl-devel] Bug#954371: libio-socket-ssl-perl: FTBFS since openssl 1.1.1e

[Steffen Ullrich]

> You should fix your tests not to trigger an unexpected EOF. You
> probably have code now that ignores the current error, you
> shouldn't ignore that error, it's a real error.

Fixing the tests to only consider an ideal world of nicely behaving peers is
in my opinion the wrong way to go.  Instead I think that it is very useful
to have tests which include bad behaved peers since such peers are
unfortunately a reality. And it would be good if IO::Socket::SSL would
provide a defined and stable behavior in such situations and that the tests
check this. As for how this behavior should exactly look like I'm not fully
sure yet and I have to figure this out before OpenSSL 3.0.0 gets released.

But in any case I rather have the tests fail early (like they also failed
with Python and Ruby) when OpenSSL changes behavior in edge cases than have
the users code fail somewhere later in production. 

Regards,
Steffen

-- 
Steffen Ullrich
Research, Projects and Products
steffen_ullr...@genua.de
PGP 0x3F84B1A6F7DEAF80

genua GmbH
Domagkstrasse 7, 85551 Kirchheim bei Muenchen
tel +49 89 991950-0, fax -999, www.genua.de
Geschaeftsfuehrer: Matthias Ochs, Marc Tesch
Amtsgericht Muenchen HRB 98238
genua ist ein Unternehmen der Bundesdruckerei-Gruppe.

Bug#719351: [mupdf] Please support to compile fitz as a .so

[Thierry HUCAHRD]

I don't understand why this bug is still open.
I know that some libraries like curl and openssl were not thread-safe, 
which could have explained it.

The argument used in the post is that fitz is not mature.
That was in 2013.
There are some patches to solve this problem : 
www.linuxfromscratch.org/patches/blfs/svn/mupdf-1.16.1-shared_libs-1.patch

Bug#955449: ITP: libsys-hostaddr-perl -- Get IP address information about this host

[Hilmar Preusse]

Package: wnpp
Severity: wishlist
Owner: Hilmar Preusse 

* Package name: libsys-hostaddr-perl
  Version : 0.993
  Upstream Author : Jeremy Kister
* URL : https://metacpan.org/release/Sys-HostAddr
* License : Artistic
  Programming Lang: Perl
  Description : Get IP address information about this host

Sys::HostAddr provides methods for determining IP address information about
a local host.

 - I intend to activate the test suite for package proftpd-basic.
   To run the test suite this perl module is needed.
 - I intend to maintain the package myself. I need a sponsor
   for initial upload. Once the package is in the archive one
   could give me the permit to upload new releases myself, I'm a DM.

Bug#955393: popularity-contest: gpg: 5B1A07804DD558242CF5538215A07BA5233E3E85: skipped: unusable public key

[Bill Allombert]

On Tue, Mar 31, 2020 at 10:38:15AM +0200, Bill Allombert wrote:
> On Tue, Mar 31, 2020 at 05:21:12AM +, Thorsten Glaser wrote:
> > Package: popularity-contest
> > Version: 1.70
> > Severity: normal
> > 
> > Just trying to trigger a run manually on this box before
> > shutting it down:
> > 
> > tg@leee:~ $ sudo cleanenv / /etc/cron.daily/popularity-contest
> > gpg: 5B1A07804DD558242CF5538215A07BA5233E3E85: skipped: unusable public key
> > gpg: /var/log/popularity-contest.new: encryption failed: unusable public key
> 
> Hello Thorsten,
> Could you investigate ? The key is in this file:
> /usr/share/popularity-contest/debian-popcon.gpg
> 
> I submitted several reports with it and I had no problem.

I received 24 encrypted submissions with this key today.
I have never see an 'unusable public key' error from gpg.
Could you try
gpg < /usr/share/popularity-contest/debian-popcon.gpg

Cheers,
-- 
Bill. 

Imagine a large red swirl here. 

Bug#953421: dash: Resident Set Size growth is unbound (memory leak) on an infinite shell loop

[Harald van Dijk]

Hi Vitaly,

On 31/03/2020 20:07, Vitaly Zuevsky wrote:

I must have confused two concepts: waited process in OS -vs- waited job inside 
shell interpreter. I am trying to see how it work in practice:

# true & false &
#
[2] + Done(1)false
[1] + Done   true
# wait 2
# echo $?
127

As we preserve job exit codes, I would expect wait command to read them and 
free associated jobtab slots. In above example I expect to see 1 in place of 
127. What do I miss here?


There are two problems here. The first is that waiting for jobs involves 
the % symbol. wait 2 always means "wait for process 2", never "wait for 
job 2". To wait for job 2, the syntax is "wait %2". The second problem 
is that as soon as you see that "[2] + Done(1)", the job has been 
removed the job table already, so "wait %2" no longer works after that. 
The blank line (except for the #) indicates that you pressed Return at 
that point. In interactive shells, jobs are checked for completion and 
removed from the job table automatically when prompting for input. Since 
it was practically impossible to press Return before the "true" and 
"false" commands had finished, when the next prompt would have been 
shown, the jobs were cleaned up. If you had typed "wait %2" before 
pressing Return, it would have worked and the subsequent "echo $?" would 
have printed "1".



Many thanks for your help.

Best,
Vitaly

Bug#955448: libmicrohttpd-dev: drop dependency on libgcrypt-dev

[Daniel Kahn Gillmor]

Package: libmicrohttpd-dev
Version: 0.9.66-1+b1
Control: tags -1 + patch

Back in 8fd1d4746ace319bff835baf420eb41212d9f43b libmicrohttpd-dev
dropped the build dependency on gcrypt, closing #883475.

But this failed to drop the dependency from libmicrohttpd-dev to
libgcrypt-dev.

I've supplied a series of minor packaging cleanups on salsa:

https://salsa.debian.org/debian/libmicrohttpd/-/merge_requests/2

The relevant one is attached here.

Thanks for maintaining libmicrohttpd-dev in debian!

--dkg

From 9f73678f4c84563c80437b61d30614147df3ff9f Mon Sep 17 00:00:00 2001
From: Daniel Kahn Gillmor 
Date: Tue, 31 Mar 2020 17:02:21 -0400
Subject: [PATCH] libmicrohttpd-dev: drop dependency on libgcrypt-dev

---
 debian/control | 1 -
 1 file changed, 1 deletion(-)

diff --git a/debian/control b/debian/control
index 8ed2a8f0..007ad15a 100644
--- a/debian/control
+++ b/debian/control
@@ -44,7 +44,6 @@ Package: libmicrohttpd-dev
 Section: libdevel
 Architecture: any
 Depends:
- libgcrypt-dev,
  libgnutls28-dev,
  libmicrohttpd12 (= ${binary:Version}),
  ${misc:Depends},
-- 
2.25.1



signature.asc
Description: PGP signature

Bug#953477: netkit-telnet: CVE-2020-10188

[Salvatore Bonaccorso]

Hi Moritz,

On Tue, Mar 31, 2020 at 10:21:12PM +0200, Moritz Mühlenhoff wrote:
> On Sun, Mar 29, 2020 at 03:24:57PM +, Marcos Marado wrote:
> > I'm not sure if someone has access to a more fine-grained diff, but,
> > from the Changelog, I'd guess the actual fix would match this:
> > 
> > +netkit-telnet (0.17-14) unstable; urgency=high
> > +
> > +  * Fixed netobuf buffer overflows.
> > +
> > + -- Herbert Xu   Sat, 11 Aug 2001 17:52:25 +1000
> > 
> > Best regards,
> > -- 
> > Marcos Marado
> > 
> > On Sun, Mar 29, 2020 at 3:51 PM Salvatore Bonaccorso  
> > wrote:
> > >
> > > On Sun, Mar 29, 2020 at 04:50:07PM +0200, Salvatore Bonaccorso wrote:
> > > > It might be possible that Debian is fixed for it since 0.17-18woody2
> > > > (for src:netkit-telnet).
> > >
> > > For reference the respective diff.
> > >
> > > Salvatore
> 
> Let's just use 0.17-14?
> 
> Also, tt doesn't really matter which precise version from almost two decades
> ago fixed this in the end anyway :-)

Thank you, I updated the security-tracker information on those issues.

Salvatore

Bug#954371: [Pkg-openssl-devel] Bug#954371: libio-socket-ssl-perl: FTBFS since openssl 1.1.1e

[Kurt Roeckx]

On Tue, Mar 31, 2020 at 09:49:51PM +0200, Salvatore Bonaccorso wrote:
> Hi Kurt,
> 
> On Tue, Mar 31, 2020 at 06:46:44PM +0200, Kurt Roeckx wrote:
> > On Tue, Mar 31, 2020 at 09:03:01AM +0200, Salvatore Bonaccorso wrote:
> > > On Sat, Mar 21, 2020 at 08:31:21PM +0100, gregor herrmann wrote:
> > > > On Fri, 20 Mar 2020 21:50:08 +0100, Sebastian Andrzej Siewior wrote:
> > > > 
> > > > > The package FTBFS since openssl has been updated to 1.1.1e because the
> > > > > testsuite fails. The failure is due to commit db943f43a60d ("Detect 
> > > > > EOF
> > > > > while reading in libssl") [0] in openssl. There an issue ticket [1]
> > > > > which introduced the changed behaviour.
> > > > 
> > > > There's a patch at
> > > > https://github.com/noxxi/p5-io-socket-ssl/issues/93
> > > > This also needs libnet-ssleay-perl_1.88-3 which I uploaded right now.
> > > 
> > > So I guess this should be threated as openssl issue and will reassign
> > > it to it. Upstream for IO::Socket::SSL has released a new version
> > > which will refuse to build with 1.1.1e:
> > > 
> > > 2.068 2020/03/31
> > > - treat OpenSSL 1.1.1e as broken and refuse to build with it in order to
> > >   prevent follow-up problems in tests and user code
> > >   https://github.com/noxxi/p5-io-socket-ssl/issues/93
> > >   https://github.com/openssl/openssl/issues/11388
> > >   https://github.com/openssl/openssl/issues/11378
> > 
> > There might be a misunderstanding. First, in 3.0, we will
> > reintroduce this new behaviour.
> > 
> > We always returned an error in case of an unexpected EOF. We
> > changed the error code of that case. Applications should never
> > trigger the unexpected EOF and should get fixed not to trigger it.
> 
> I see, but then I prefer to loop in Steffen Ullrich into the loop
> (upstream of IO::Socket::SSL). Steffen, see the above comment from
> Kurt in the Debian bug, so it looks we cannot close
> https://github.com/noxxi/p5-io-socket-ssl/issues/93 by marking 1.1.1e
> as broken only. What do you think?

If only https://github.com/openssl/openssl/issues/11388 is a
problem, I think only marking 1.1.1e as a problem is fine. But you
also point to https://github.com/openssl/openssl/issues/11378, which
talks about many different things, and the current plan is to
change back to that behaviour in 3.0. That is, react to an
unexpected EOF as the error it is, including the different error
code and marking the session as not reusable.

You should fix your tests not to trigger an unexpected EOF. You
probably have code now that ignores the current error, you
shouldn't ignore that error, it's a real error.

This might also affect reverse dependecies. And they need to get
fixed too.


Kurt

Bug#947589: wicd-gtk: [experimental] wicd-gtk probably broken: no GTK dependency, still uses 'import gtk'

[Guido Maria Serra]

Hi Moritz,I followed your recommendation and I got up to here
https://git.launchpad.net/wicd/commit/?h=gtk_Debian_Bug%23947589&id=358f5f11c64ed09838c607bf5c64d35b74c0ca75
Though I do now have a problem of testing now, as there are neither gtk
based tests, neither a way to test without involving my os...I've tried
some symlinking inside  /usr/share/wicd/gtk/ as wicd.ui gets copied
from the data/ folder within the source code there.
Now, if anybody has an idea or a system that he/she is fine to break
for testing... get in contact with me
Stacktrace follows... I already did substitute GtkProgressBar
with GtkProgressBarWindow 
best,GMS
$ python gtk/wicd-client.py py Importing pynotify failed, notifications
disabled.('Has notifications support', False)Loading...Connecting to
daemon...Connected.gtk/wicd-client.py:535: DeprecationWarning:
Gtk.UIManager.get_widget is deprecated  self.menu =
(self.manager.get_widget('/Menubar/Menu/Quit').gtk/wicd-client.py:944:
DeprecationWarning: Gtk.StatusIcon.set_visible is deprecated 
self.set_visible(True)gtk/wicd-client.py:960: DeprecationWarning:
Gtk.StatusIcon.set_from_icon_name is deprecated 
gtk.StatusIcon.set_from_icon_name(self, name)gtk/wicd-client.py:948:
DeprecationWarning: Gtk.StatusIcon.set_tooltip_text is deprecated 
self.set_tooltip_text("Initializing wicd...")Traceback (most recent
call last):  File "gtk/wicd-client.py", line 1204, in
main(sys.argv)  File "gtk/wicd-client.py", line 103, in
wrapperreturn func(*args, **kwargs)  File "gtk/wicd-client.py",
line 1172, in maintray_icon = TrayIcon(animate,
displaytray=use_tray, displayapp=display_app)  File "gtk/wicd-
client.py", line 162, in __init__self.tr.toggle_wicd_gui()  File
"gtk/wicd-client.py", line 864, in toggle_wicd_guiself.gui_win =
gui.appGui(tray=self)  File "/home/gms/tmp/wicd/gtk/gui.py", line 193,
in
__init__self.wTree.add_from_file(gladefile)gi.repository.GLib.Error
: gtk-builder-error-quark: /usr/share/wicd/gtk/wicd.ui:224:49 Invalid
property: GtkProgressBar.activity_mode (11)

Bug#954921: Fixed in upstread README

[John Eikenberry]

I removed the mention of Perl from the Readme that was used as the basis for
the description. The sentence in question was changed to..

"My goal in writing this script was to provide all the functionality of all
the various terminal color displaying scripts found around the web in one
place with some additional bells and whistles."

That is, I changed "various Perl and sh scripts" to "various terminal color
displaying scripts".

-- 

John Eikenberry
[ j...@zhar.net - http://zhar.net ]

"Perfection is attained, not when no more can be added, but when no more
 can be removed." -- Antoine de Saint-Exupery

Bug#955447: hurd: FTBFS with gcc-10

[Samuel Thibault]

Source: hurd
Severity: normal
Tags: upstream fixed-upstream pending

Just to document and for tracking: the hurd package currently FTBFS with
gcc-10 due to the now-default -fno-common option. A patch was committed
upstream, and will land in Debian soon.

Samuel

Bug#955446: ecflow: hardcoded library build dependencies

[Pino Toscano]

Source: ecflow
Version: 4.17.2-2
Severity: important
Tags: patch

Hi,

ecflow has few library packages directly specific as build
dependencies. This can be problematic e.g. in the (rare) case they bump
SONAME, but in general specifying directly a library as build
dependency is useless (its -dev will install the latest version of it).

Attached a patch that removes libqt5gui5, libqt5widgets5, libqt5core5a,
and libqt5network5, as all of them are installed by qtbase5-dev
already.

Thanks,
-- 
Pino
--- a/debian/control
+++ b/debian/control
@@ -12,10 +12,6 @@ Build-Depends: debhelper-compat (= 12),
   libxpm-dev,
   libssl-dev,
   qtbase5-dev,
-  libqt5gui5, 
-  libqt5widgets5,
-  libqt5core5a,
-  libqt5network5,
   libqt5svg5-dev,
   libqt5charts5-dev,
   libboost-test-dev, 

Bug#719351: [mupdf] Please support to compile fitz as a .so

[Thierry HUCAHRD]

Le 2020-03-31 21:25, Thierry HUCAHRD a écrit :

I don't understand why this bug is still open.
I know that some libraries like curl and openssl were not thread-safe,
which could have explained it.
The argument used in the post is that fitz is not mature.
That was in 2013.
There are some patches to solve this problem :
www.linuxfromscratch.org/patches/blfs/svn/mupdf-1.16.1-shared_libs-1.patch

https://github.com/ArtifexSoftware/mupdf/pull/12/files

Bug#955445: CVE-2019-15522

[Moritz Muehlenhoff]

Package: csync2
Severity: important
Tags: security

Please see https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-15522

Cheers,
Moritz

Bug#947589: wicd-gtk: [experimental] wicd-gtk probably broken: no GTK dependency, still uses 'import gtk'

[Guido Maria Serra]

Il giorno mar, 31/03/2020 alle 22.00 +0200, Axel Beckert ha scritto:
> Hi Moritz,
> 
> Moritz Mühlenhoff wrote:
> > has there been further development?
> 
> Not so much. :-/

sorry guys, I couldn't get my hands on it lately

GMS

Bug#955444: python-etesync: use the scrypt dependency instead of pyscrypt, or update to 0.11.1 which requires neither

[Tom Hacohen]

Package: python-etesync
Version: 0.9.2-1

Hi,

I'm the maintainer of the upstream package. While the pip dependency was
listed as pyscrypt, we've always supported both pyscrypt and scrypt,
with the latter being the recommended choice because it's much more
efficient (and still maintained). The former was the default because of
compatibility.

Additionally, if you update to version 0.11.1 (latest), you can even
remove both deps, because it now also supports the scrypt implementation
that's shipped in Python 3.6 and later.

Glad to see it in Debian, and thanks a lot for your great work!

--
Tom

Bug#953477: netkit-telnet: CVE-2020-10188

[Moritz Mühlenhoff]

On Sun, Mar 29, 2020 at 03:24:57PM +, Marcos Marado wrote:
> I'm not sure if someone has access to a more fine-grained diff, but,
> from the Changelog, I'd guess the actual fix would match this:
> 
> +netkit-telnet (0.17-14) unstable; urgency=high
> +
> +  * Fixed netobuf buffer overflows.
> +
> + -- Herbert Xu   Sat, 11 Aug 2001 17:52:25 +1000
> 
> Best regards,
> -- 
> Marcos Marado
> 
> On Sun, Mar 29, 2020 at 3:51 PM Salvatore Bonaccorso  
> wrote:
> >
> > On Sun, Mar 29, 2020 at 04:50:07PM +0200, Salvatore Bonaccorso wrote:
> > > It might be possible that Debian is fixed for it since 0.17-18woody2
> > > (for src:netkit-telnet).
> >
> > For reference the respective diff.
> >
> > Salvatore

Let's just use 0.17-14?

Also, tt doesn't really matter which precise version from almost two decades
ago fixed this in the end anyway :-)

Cheers,
Moritz

Bug#938852: xmms2: Python2 removal in sid/bullseye

[Moritz Mühlenhoff]

On Mon, Mar 16, 2020 at 05:44:50PM -0600, Nicholas D Steeves wrote:
> Hi Matthias,
> 
> Matthias Klose  writes:
> 
> > Package: src:xmms2
> > Version: 0.8+dfsg-18.2
> > Severity: normal
> > Tags: sid bullseye
> > User: debian-pyt...@lists.debian.org
> > Usertags: py2removal
> >
> > Python2 becomes end-of-live upstream, and Debian aims to remove
> > Python2 from the distribution, as discussed in
> > https://lists.debian.org/debian-python/2019/07/msg00080.html
> >
> > Your package either build-depends, depends on Python2, or uses Python2
> > in the autopkg tests.  Please stop using Python2, and fix this issue
> > by one of the following actions.
> >
> 
> What's the plan for this package?  It seems to me that upstream is dead,
> so I'm wondering if xmmsclient will be ported to Python 3, or if
> bin:python-xmmsclient will be dropped.

It's not just a matter of python-xmmsclient, the build system (waf) itself
it also using Python 2.

Cheers,
Moritz

Bug#955442: openssl breaks libio-socket-ssl-perl autopkgtest: 20 times "not ok"

[Paul Gevers]

Hi gregor,

On 31-03-2020 21:55, gregor herrmann wrote:
> On Tue, 31 Mar 2020 21:41:12 +0200, Paul Gevers wrote:
> 
>> With a recent upload of openssl the autopkgtest of libio-socket-ssl-perl
>> fails in testing when that autopkgtest is run with the binary packages
>> of openssl from unstable. 
> 
> Ack, cf. #954371 and the pointers to upstream discussions there.
> It's not clear yet how (and where) to proceed …

Yes, I noticed that bug too late. Sorry for the additional bug, you can
close it if it's not helpful.

Paul



signature.asc
Description: OpenPGP digital signature

Bug#953655: autopkgtest (lxc/lxd): wait for sysvinit services to finish before running the tests

[Paul Gevers]

Dear Lars,

On 11-03-2020 21:09, Lars Kruse wrote:
> The attached patch lets autopkgtest wait for the sysvinit runlevel script
> parent process (/etc/init.d/rc) to be finished/absent. This change does
> not affect other init systems, since /etc/init.d/rc is only shipped by
> the sysvinit-core package. In case of a timeout (60s) this waiting
> procedure would fail (just as it does, if the network-online.target is
> not reached by systemd).
> 
> I tested this patch succesfully. No further timing issues showed up
> afterwards.

I applied you patch, however...

> 
> Please tell me, whether this patch looks reasonable to you.
> I am happy to test other options, if you can think of a more suitable
> approach.

I get errors from our pycodetest:
paul@testavoira ~/autopkgtest $ tests/pycodestyle
/home/paul/debian-maint/autopkgtest/virt/autopkgtest-virt-lxc:128:212:
W605 invalid escape sequence '\.'
/home/paul/debian-maint/autopkgtest/virt/autopkgtest-virt-lxd:104:201:
W605 invalid escape sequence '\.'

as can be seen on salsa:
https://salsa.debian.org/ci-team/autopkgtest/-/jobs/638755

Do you have a test proposal and are you able to test it?

Paul



signature.asc
Description: OpenPGP digital signature

Bug#938425: 938425

[Moritz Mühlenhoff]

On Tue, Mar 31, 2020 at 01:01:31PM +0200, JCF Ploemen wrote:
> Moritz Mühlenhoff  wrote:
> > These seem to be in the archive now. Are there other blockers or
> > module pre requisites?
> 
> Upstream git has switched the develop branch to python3 and that seems
> to work fine, but there have been no tagged releases with that code
> yet. The holdup appears to be macos and windoze support [1].
> 
> I was hoping for a tagged release though, which would be easier to work
> with and less manual labour than a git snapshot. That said, it is a
> viable alternative if need be - and the packaging work mostly complete
> as well [2].

Next week we should be ready to request removal of pygtk. There are
a small number of packages which are still WIP (e.g. mirage is being
close to ready for the gi/gtk3 port), so I'll ask for the removal
despite a few rdeps still around.

I think it's fair enough to keep sabnzbdplus uninstallable for a few
months (or however long is takes for a release to emerge).

Cheers,
Moritz

Bug#947589: wicd-gtk: [experimental] wicd-gtk probably broken: no GTK dependency, still uses 'import gtk'

[Axel Beckert]

Hi Moritz,

Moritz Mühlenhoff wrote:
> has there been further development?

Not so much. :-/

> The removal of pygtk is now fairly close.
> Given that there's been some movement wrt PyGI/gtk3, we can ask to force
> the removal despite wicd still being around (but wicd-gtk would be rendered
> uninstallable).

Feel free to do so. Actually, that's what I would have expected.

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

Bug#953477: netkit-telnet: CVE-2020-10188

[Salvatore Bonaccorso]

Hi,

On Sun, Mar 29, 2020 at 03:24:57PM +, Marcos Marado wrote:
> I'm not sure if someone has access to a more fine-grained diff, but,
> from the Changelog, I'd guess the actual fix would match this:
> 
> +netkit-telnet (0.17-14) unstable; urgency=high
> +
> +  * Fixed netobuf buffer overflows.
> +
> + -- Herbert Xu   Sat, 11 Aug 2001 17:52:25 +1000

Unfortunately snapshot.debian.org has only

0.17-41.2
0.17-41.1
0.17-41
0.17-40
0.17-39
0.17-38
0.17-37
0.17-36
0.17-35
0.17-34
0.17-33
0.17-32
0.17-31
0.17-30
0.17-29
0.17-28
0.17-27
0.17-26
0.17-18woody3
0.17-18woody2
0.16-4potato.3
0.16-4potato.2
0.12-4slink.1

so some revisions are missed. The previous diff was the best I could get so
far.

Regards,
Salvatore

Bug#955442: [Pkg-openssl-devel] Bug#955442: openssl breaks libio-socket-ssl-perl autopkgtest: 20 times "not ok"

[Sebastian Andrzej Siewior]

On 2020-03-31 21:41:12 [+0200], Paul Gevers wrote:
>passfail
> opensslfrom testing1.1.1e-1
> libio-socket-ssl-perl  from testing2.067-1
> all others from testingfrom testing

there is more than just this. OpenSSL upstream released a new version 
today which brings back the old behaviour where openssl did not
reporting an error (properly).

I opened #954371 for libio-socket-ssl-perl but this has been reassigned
which is …

Anyway. With the upload the bug(s) could be downgraded to important but
should be addressed.

Sebastian

Bug#955442: openssl breaks libio-socket-ssl-perl autopkgtest: 20 times "not ok"

[gregor herrmann]

On Tue, 31 Mar 2020 21:41:12 +0200, Paul Gevers wrote:

> With a recent upload of openssl the autopkgtest of libio-socket-ssl-perl
> fails in testing when that autopkgtest is run with the binary packages
> of openssl from unstable. 

Ack, cf. #954371 and the pointers to upstream discussions there.
It's not clear yet how (and where) to proceed …

Cheers,
gregor

-- 
 .''`.  https://info.comodo.priv.at -- Debian Developer https://www.debian.org
 : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D  85FA BB3A 6801 8649 AA06
 `. `'  Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe
   `-   NP: Bob Dylan: Stuck inside of mobile with the Memphis blues again


signature.asc
Description: Digital Signature

Bug#947589: wicd-gtk: [experimental] wicd-gtk probably broken: no GTK dependency, still uses 'import gtk'

[Moritz Mühlenhoff]

On Sat, Dec 28, 2019 at 04:04:30PM +0100, Axel Beckert wrote:
> Control: forcemerge 946380 -1
> Control: tag -1 + confirmed
> 
> Simon McVittie wrote:
> > The Python 3 version of wicd-gtk in experimental doesn't seem to have
> > any dependency that would pull in GTK, which seems unlikely to be valid
> > for a GTK GUI.
> 
> This is #946380. Merging.
> 
> > A GTK 3 app using PyGI would normally have to depend on both python3-gi and
> > gir1.2-gtk-3.0, which are the necessary packages to be able to use this
> > import sequence:
> > 
> > #!/usr/bin/python3
> > import gi
> > gi.require_version('Gtk', '3.0')
> > from gi.repository import Gtk
> > 
> > ... use Gtk.Application, Gtk.Window, etc. ...
> > 
> > However, looking at the source code on sources.debian.org, it seems that
> > wicd-gtk in experimental is still using
> > 
> > import gtk
> > 
> > which was correct for PyGTK 2, but will not work with PyGI / GTK 3, which
> > are the only available GTK binding for Python 3.
> > 
> > src/d-feet.in in the d-feet source package is a typical example of
> > a correct PyGI / GTK 3 import sequence. gnome-tweaks is another good
> > example of a relatively small and simple PyGI / GTK 3 app, while sonata
> > and reportbug might be useful as examples of legacy PyGTK 2 applications
> > that were ported to PyGI / GTK 3.
> 
> Thanks for these hints!

Hi,
has there been further development? The removal of pygtk is now fairly close.
Given that there's been some movement wrt PyGI/gtk3, we can ask to force
the removal despite wicd still being around (but wicd-gtk would be rendered
uninstallable).

Cheers,
Moritz

Bug#954371: [Pkg-openssl-devel] Bug#954371: libio-socket-ssl-perl: FTBFS since openssl 1.1.1e

[Salvatore Bonaccorso]

Hi Kurt,

On Tue, Mar 31, 2020 at 06:46:44PM +0200, Kurt Roeckx wrote:
> On Tue, Mar 31, 2020 at 09:03:01AM +0200, Salvatore Bonaccorso wrote:
> > On Sat, Mar 21, 2020 at 08:31:21PM +0100, gregor herrmann wrote:
> > > On Fri, 20 Mar 2020 21:50:08 +0100, Sebastian Andrzej Siewior wrote:
> > > 
> > > > The package FTBFS since openssl has been updated to 1.1.1e because the
> > > > testsuite fails. The failure is due to commit db943f43a60d ("Detect EOF
> > > > while reading in libssl") [0] in openssl. There an issue ticket [1]
> > > > which introduced the changed behaviour.
> > > 
> > > There's a patch at
> > > https://github.com/noxxi/p5-io-socket-ssl/issues/93
> > > This also needs libnet-ssleay-perl_1.88-3 which I uploaded right now.
> > 
> > So I guess this should be threated as openssl issue and will reassign
> > it to it. Upstream for IO::Socket::SSL has released a new version
> > which will refuse to build with 1.1.1e:
> > 
> > 2.068 2020/03/31
> > - treat OpenSSL 1.1.1e as broken and refuse to build with it in order to
> >   prevent follow-up problems in tests and user code
> >   https://github.com/noxxi/p5-io-socket-ssl/issues/93
> >   https://github.com/openssl/openssl/issues/11388
> >   https://github.com/openssl/openssl/issues/11378
> 
> There might be a misunderstanding. First, in 3.0, we will
> reintroduce this new behaviour.
> 
> We always returned an error in case of an unexpected EOF. We
> changed the error code of that case. Applications should never
> trigger the unexpected EOF and should get fixed not to trigger it.

I see, but then I prefer to loop in Steffen Ullrich into the loop
(upstream of IO::Socket::SSL). Steffen, see the above comment from
Kurt in the Debian bug, so it looks we cannot close
https://github.com/noxxi/p5-io-socket-ssl/issues/93 by marking 1.1.1e
as broken only. What do you think?

Regards,
Salvatore

Bug#925747: libkibi: diff for NMU version 0.1.1-2.1

[Sudip Mukherjee]

Control: tags 925747 + patch
Control: tags 925747 + pending

Dear maintainer,

I've prepared an NMU for libkibi (versioned as 0.1.1-2.1) and
uploaded it to mentors for sponsoring. Please feel free to tell me if I
should remove it.

--
Regards
Sudip

diff -Nru libkibi-0.1.1/debian/changelog libkibi-0.1.1/debian/changelog
--- libkibi-0.1.1/debian/changelog  2016-12-25 15:27:55.0 +
+++ libkibi-0.1.1/debian/changelog  2020-03-31 19:34:31.0 +0100
@@ -1,3 +1,10 @@
+libkibi (0.1.1-2.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix ftbfs with GCC. (Closes: #925747)
+
+ -- Sudip Mukherjee   Tue, 31 Mar 2020 19:34:31 
+0100
+
 libkibi (0.1.1-2) unstable; urgency=medium
 
   * Move packaging to collab-maint git repository
diff -Nru libkibi-0.1.1/debian/patches/series 
libkibi-0.1.1/debian/patches/series
--- libkibi-0.1.1/debian/patches/series 1970-01-01 01:00:00.0 +0100
+++ libkibi-0.1.1/debian/patches/series 2020-03-31 19:34:31.0 +0100
@@ -0,0 +1 @@
+use_strdup.patch
diff -Nru libkibi-0.1.1/debian/patches/use_strdup.patch 
libkibi-0.1.1/debian/patches/use_strdup.patch
--- libkibi-0.1.1/debian/patches/use_strdup.patch   1970-01-01 
01:00:00.0 +0100
+++ libkibi-0.1.1/debian/patches/use_strdup.patch   2020-03-31 
19:34:00.0 +0100
@@ -0,0 +1,25 @@
+Description: Fix ftbfs with GCC
+ Use strdup() instead of using malloc() and then copying the full length
+ of the string.
+
+Author: Sudip Mukherjee 
+Bug-Debian: https://bugs.debian.org/925747
+
+---
+
+--- libkibi-0.1.1.orig/kibi/kibi.c
 libkibi-0.1.1/kibi/kibi.c
+@@ -313,12 +313,11 @@ static char *get_xdg_config_home(void) {
+ xdg_config_home = getenv("XDG_CONFIG_HOME");
+ if(xdg_config_home != NULL && strlen(xdg_config_home) > 0) {
+ length = strlen(xdg_config_home) + 1;
+-result = malloc(length);
++result = strdup(xdg_config_home);
+ if(unlikely(result == NULL)) {
+ malloc_error(length);
+ return NULL;
+ }
+-strncpy(result, xdg_config_home, length);
+ } else { // xdg_config_home == NULL || strlen(xdg_config_home) == 0
+ // Use $HOME/.config if XDG_CONFIG_HOME is not defined.
+ home = getenv("HOME");

Bug#955442: openssl breaks libio-socket-ssl-perl autopkgtest: 20 times "not ok"

[Paul Gevers]

Source: openssl, libio-socket-ssl-perl
Control: found -1 openssl/1.1.1e-1
Control: found -1 libio-socket-ssl-perl/2.067-1
Severity: serious
Tags: sid bullseye
X-Debbugs-CC: debian...@lists.debian.org
User: debian...@lists.debian.org
Usertags: breaks needs-update

Dear maintainer(s),

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

   passfail
opensslfrom testing1.1.1e-1
libio-socket-ssl-perl  from testing2.067-1
all others from testingfrom testing

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

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

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

Paul

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

https://ci.debian.net/data/autopkgtest/testing/amd64/libi/libio-socket-ssl-perl/4752372/log.gz

ok # [client] Client SSL Handshake OK
not ok # [client] Hi!
not ok # fatal error at ./t/testlib.pl line 171.

Dubious, test returned 1 (wstat 256, 0x100)
Failed 8/16 subtests



signature.asc
Description: OpenPGP digital signature

Bug#885265: Bug#936299: chirp: Python2 removal in sid/bullseye

[Christoph Berg]

Re: Moritz Muehlenhoff 2020-03-27 <20200327220044.s7cmyqmlnevty...@inutil.org>
> > There's a py3 branch in upstream Hg that's activish. I haven't tried
> > it yet, but it looks promising. I'll give it a try over the weekend
> > and report back here.

I've pushed the new branch to our git, but it's still so broken that I
don't think uploading makes sense.

I mailed some basic patches to upstream, hopefully they can get this
working soon.

Christoph

Bug#955443: RFS: libkibi/0.1.1-2.1 [NMU, RC] -- library for byte prefixes

[Sudip Mukherjee]

Package: sponsorship-requests
Severity: important

Dear mentors,

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

 * Package name: libkibi
   Version : 0.1.1-2.1
   Upstream Author : Benjamin Drung 
 * URL : https://launchpad.net/libkibi
 * License : ISC
 * Vcs : https://anonscm.debian.org/cgit/collab-maint/libkibi.git
   Section : libs

It builds those binary packages:

  libkibi0 - library for byte prefixes
  libkibi-dbg - library for byte prefixes (debugging symbols)
  libkibi-dev - library for byte prefixes (development files)

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

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

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

  dget -x 
https://mentors.debian.net/debian/pool/main/libk/libkibi/libkibi_0.1.1-2.1.dsc

Changes since the last upload:

   * Non-maintainer upload.
   * Fix ftbfs with GCC. (Closes: #925747)


-- 
Regards
Sudip

Bug#955440: passenger: FTBFS on armel and armhf

[Sebastian Ramacher]

Source: passenger
Version: 5.0.30-1.1
Severity: serious
Tags: ftbfs sid bullseye
Justification: fails to build from source (but built successfully in the past)

binNMUs of passenger failed on armel and armhf:
https://buildd.debian.org/status/fetch.php?pkg=passenger&arch=armel&ver=5.0.30-1.1%2Bb2&stamp=1584710127&raw=0
https://buildd.debian.org/status/fetch.php?pkg=passenger&arch=armhf&ver=5.0.30-1.1%2Bb2&stamp=1585045168&raw=0

Cheers
-- 
Sebastian Ramacher


signature.asc
Description: PGP signature

Bug#955441: CVE-2020-5291, GHSA-j2qp-rvxj-43vj: privilege escalation in some kernel configurations

[Simon McVittie]

Package: bubblewrap
Version: 0.4.0-1
Severity: critical
Tags: security upstream fixed-upstream
Justification: root security hole

bubblewrap 0.4.0 introduced a privilege escalation vulnerability on systems
where both of these are true:

- unprivileged users can create user namespaces:
- not true on Debian kernels by default
- true on Debian kernels if reconfigured
  with /proc/sys/kernel/unprivileged_userns_clone = 1
- true on upstream kernels (usually)
- true on Ubuntu kernels (usually)

- /usr/bin/bwrap is setuid root:
- true with Debian's bubblewrap package
- not true with Ubuntu's bubblewrap package

Mitigation:

- either disable unprivileged creation of user namespaces:
- set /proc/sys/kernel/unprivileged_userns_clone to 0, or
- set /proc/sys/user/max_user_namespaces to 0
- or make /usr/bin/bwrap not be setuid root
- use dpkg-statoverride or chmod

This is tracked as CVE-2020-5291 and GHSA-j2qp-rvxj-43vj.

The bubblewrap packages in Debian 10 'buster' and older releases are
not vulnerable.

The bubblewrap 0.4.0-1~bpo10+1 package in buster-backports is vulnerable.
This is fixed in 0.4.1-1~bpo10+1.

The bubblewrap 0.4.0-1 package in testing is vulnerable. This is fixed
in 0.4.1-1, currently in unstable.

If you have reconfigured the kernel to allow unprivileged creation of user
namespaces, it is unnecessary for /usr/bin/bwrap to be setuid. A
least-privilege approach is to reconfigure bwrap to have no special
privileges on such systems:

dpkg-statoverride --update --add root root 0755 /usr/bin/bwrap

However, if you do this, and subsequently reconfigure the kernel to
disallow unprivileged creation of user namespaces, programs like flatpak
will not work. To solve that, it will be necessary to make /usr/bin/bwrap
setuid again, for example:

dpkg-statoverride --remove /usr/bin/bwrap
dpkg-statoverride --update --add root root 4755 /usr/bin/bwrap

Regards,
smcv

Bug#955439: libpsl: Please make autopkgtests cross-test-friendly

[Steve Langasek]

Package: libpsl
Version: 0.21.0-1
Severity: minor
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu focal ubuntu-patch

Dear maintainers,

In Ubuntu, we are in the process of moving the i386 architecture to a
compatibility-only layer on amd64, and therefore we are also moving our
autopkgtest infrastructure to test i386 binaries in a cross-environment.

This requires changes to some tests so that they are cross-aware and can do
the right thing.

The libpsl tests currently fail in this environment, because of a declared
test dependency on diffutils which will try to pull in the cross-arch
version, which is not allowed since this is an essential package.

Because diffutils is an essential package, you do not have to declare a test
dependency on it in order to guarantee it's present on the test system; and
there is not a reason to need the cross-arch version of the package; so I
have uploaded the attached patch to Ubuntu which drops the declared test
dependency, letting the i386 tests successfully run on an amd64 host.

Thanks for considering,
-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developer   https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org
diff -Nru libpsl-0.21.0/debian/tests/control libpsl-0.21.0/debian/tests/control
--- libpsl-0.21.0/debian/tests/control  2020-03-04 09:36:26.0 -0800
+++ libpsl-0.21.0/debian/tests/control  2020-03-31 09:33:15.0 -0700
@@ -1,5 +1,4 @@
 Tests: psl-test
 Depends:
- diffutils,
  psl,
  publicsuffix,

Bug#952769: isc-dhcp-client: Package "isc-dhcp-client" is not installable in the Debian SID PowerPC Port. Unmet dependencies: "libdns1107" and "libisc1104"

[Sebastian Ramacher]

Control: severity -1 important

On 2020-02-28 22:44:30, Hugo Melder wrote:
> Package: isc-dhcp-client
> Version: 4.4.1-2.1
> Severity: grave
> Tags: d-i a11y
> Justification: renders package unusable

Uninstallable packages on ports are not RC, so downgrading accordingly.

Cheers

> 
> 
> 
> -- System Information:
> Debian Release: bullseye/sid
>   APT prefers unstable
>   APT policy: (500, 'unstable')
> Architecture: PowerPC
> 
> Kernel: Linux 5.4.0-4-amd64 (SMP w/16 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_GB.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 isc-dhcp-client depends on:
> ii  debianutils4.9.1
> ii  iproute2   5.5.0-1
> ii  libc6  2.29-10
> ii  libdns-export1107  1:9.11.14+dfsg-3
> ii  libisc-export1104  1:9.11.14+dfsg-3
> 
> Versions of packages isc-dhcp-client recommends:
> ii  isc-dhcp-common  4.4.1-2.1
> 
> Versions of packages isc-dhcp-client suggests:
> pn  avahi-autoipd 
> pn  isc-dhcp-client-ddns  
> pn  resolvconf
> 
> -- no debconf information

-- 
Sebastian Ramacher


signature.asc
Description: PGP signature

Bug#953421: dash: Resident Set Size growth is unbound (memory leak) on an infinite shell loop

[Vitaly Zuevsky]

Hi Harald,


>   set -- $(seq 1 100)
>   for i
>   do
> : &
> sleep .1
>   done
>   for i
>   do
> wait %$i
>   done
>
>This is a valid script and works fine in dash. Your change breaks this by not 
>keeping the jobs around long enough, and I hope this test script shows that 
>there is no way to keep the jobs around long enough but by allocating ever 
>more memory.

I must have confused two concepts: waited process in OS -vs- waited job inside 
shell interpreter. I am trying to see how it work in practice:

# true & false &
#
[2] + Done(1)false
[1] + Done   true
# wait 2
# echo $?
127

As we preserve job exit codes, I would expect wait command to read them and 
free associated jobtab slots. In above example I expect to see 1 in place of 
127. What do I miss here?

Many thanks for your help.

Best,
Vitaly  

Bug#906757: zsh-antigen: command not found: -antigen-env-setup

[Hans Joachim Desserud]

I took a look at this issue and discovered a couple of things.

First I tried to rebuild the package in Ubuntu, in case libraries or
build tools had changed in the meantime. This didn't work.

After a couple of other experiments which didn't lead anywhere
either, I started to wonder what would happen if I rebuilt the
package on Debian. So I did
$ apt source zsh-antigen
$ cd zsh-antigen-2.2.3/
$ debuild -us -uc
which gave me a newly rebuilt package on my Debian Sid system. Then
I could compare them.

This is with zsh-antigen installed from the package archives:
% grep -in "\-antigen-env-setup" /usr/share/zsh-antigen/antigen.zsh
431:-antigen-env-setup () {
2062:-antigen-env-setup

...and this is after installing the one I built locally:
% grep -in "\-antigen-env-setup" /usr/share/zsh-antigen/antigen.zsh
748:-antigen-env-setup

When I took the binary packages and unpackaged them to compare the
contents, the one built locally was missing large portions of the
code, which would explain the error message:
/usr/share/zsh-antigen/antigen.zsh:748: command not found: 
-antigen-env-setup


I'm not sure why this happens, but these parts seem to be
consistently missing after (re)building the package.

--
mvh / best regards
Hans Joachim Desserud
http://desserud.org

Bug#939171: xdeb: Please *don't* remove Lintian check; it is part of Lintian

[Tobias Schlemmer]

Package: xdeb
Version: 0.6.7
Followup-For: Bug #939171

Hi,

to increase confusion: the xdeb check has been removed from lintian in
https://salsa.debian.org/lintian/lintian/-/commit/a1dbe23dc95c8bf9b71d59894b97d9cd03b5ecc2

But I can't find why xdeb has been removed from debian testing.



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

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

Versions of packages xdeb depends on:
ii  apt-utils2.0.1
ii  build-essential  12.8
ii  devscripts   2.20.2
ii  dpkg-cross   2.6.15-3
ii  dpkg-dev 1.19.7
iu  lintian  2.61.0
ii  python   2.7.17-2
pn  python-apt   
pn  python-debian
ii  sudo 1.8.31-1
ii  wget 1.20.3-1+b2

Versions of packages xdeb recommends:
ii  fakeroot  1.24-1
ii  gcc   4:9.2.1-3.1

xdeb suggests no packages.

Bug#952742: mumble: start locks sound for all application (even the client itself)

[Sébastien Leblanc]

On 20-03-31 14 h 42, lemmel wrote:
> Well done !
>
> I was stupid: jackd was in the ouput, but as Pulse was selected I totally 
> ignored it ; and jackd doesn't even figure in the Mumble UI !
>
> I'm really sorry: I filled a bug, and waste your time.


It is actually a manifestation of an underlying bug: Mumble provides no
control in the GUI for Jack parameters, and by default starts it if it
is installed, whether you are actually using it or not.

--
Sébastien Leblanc



pEpkey.asc
Description: application/pgp-keys

Bug#952742: mumble: start locks sound for all application (even the client itself)

[lemmel]

Well done !

I was stupid: jackd was in the ouput, but as Pulse was selected I totally 
ignored it ; and jackd doesn't even figure in the Mumble UI !

I'm really sorry: I filled a bug, and waste your time.

Le mardi 31 mars 2020, 19:58:06 CEST Sébastien Leblanc a écrit :
> > ii  libjack-jackd2-0 [libjack-0.125]  1.9.12~dfsg-2+b1
> 
> I see you have Jack installed, have you checked if Mumble started it?
> Unfortunately, while Mumble supports Jack, it does not play nicely with
> it in this release, as there are no options in the GUI pertaining to
> disabling automatic connections or automatic startup of the Jack server.
> By default, it will attempt to start Jack if it is installed on the
> system, even if you set the output module to ALSA or PulseAudio.
> 
> 
> In `~/.config/Mumble/Mumble.conf`, you can add the following :
> 
> 
> %
> 
> [jack]
> startserver=false
> 
> %
> 
> 
> Please see if this does anything.
> 
> --
> Sébastien Leblanc
> 
> 

Bug#828190: pulseaudio fails to interact with alsa, hangs and spams syslog

[Harald Geyer]

retitle 828190 [pulseaudio] sometimes locks up
tag 828190 - moreinfo
stop

Dear Maintainer,

this report is tagged "moreinfo", but I don't see which info is
missing. AFAICS the original submitter provided everything he was
asked. Please add the tag again and clarify, if indeed some information
is missing.

Also I want to refute the theory, that this problem is mostly a bug
in the kernel driver: Everything works for me, if I use ALSA directly
instead of via pulseaudio and duckduckgo finds variants of this problem
reported on the internet related to many different drivers.

Here are my observations:

On my system audio mostly works fine for trivial things like beeps
or playing .wav files. However advanced uses (mostly VoIP software
like empathy, pidgin and baresip) cause pulseaudio to run at
100% CPU (one thread) and spam syslog with this message

Mar 31 00:19:02 teres pulseaudio[9099]: W: [alsa-source-1c22c00.dai-sun8i 
sun8i-0] alsa-source.c: Resume failed, couldn't restore original sample 
settings.

about 315 times per second.

The really fun part: After executing
pulseaudio -k; pulseaudio --log-level=4 --log-target=stderr

I can't reproduce the issue. Must be some race involved somewhere.

The system is set up with pulse as the default ALSA device. Interaction
with pulseaudio typically happens via the ALSA API.

From the difficulty in reproducing the behaviour and the content of the
message I gather, that the trigger depends on the state of the
audio HW/alsa and the properties of the audio data to be played.
Eg. Simply playing an audio file from baresip usually works fine from
a pristine state, but might fail if earlier activity caused the messages
to appear. Using "aplay" to play a .wav file might restore a working
state.

From reading [1] and [2] I understand, that mismatched sample rates
might cause such a problem. But pulseaudio should resample as needed
to avoid this. Upstream bug [3] might be related somewhat.

I focused my efforts for analyzing this problem with baresip, because it
has the most straight forward and easy to understand code. I can reproduce
this without any other audio applications running, so it really seems like
pulseaudio is stepping on its own toes. The versions in unstable and
experimental are both affected.

The code in baresip, responsible for handling audio is at:
https://github.com/alfredh/baresip/blob/be4448a54117cfd2cda69d4fc88e1c2802e8a5b6/modules/alsa/alsa_play.c#L53

If the ALSA API immediatly returns an error without blocking at all, this
code turns into a tight loop. Neatly explaining why the system hangs with
100% CPU.

I guess this code should be smarter about handling errors. OTOH I don't
see anything illegal happening there and pulseaudio should resample instead
of throwing errors, so the main problem must be with pulseaudio.

--- begin ---
static void *write_thread(void *arg)
{
struct auplay_st *st = arg;
int n;
int num_frames;

num_frames = st->prm.srate * st->prm.ptime / 1000;

while (st->run) {
const int samples = num_frames;
void *sampv;

st->wh(st->sampv, st->sampc, st->arg);

sampv = st->sampv;

n = snd_pcm_writei(st->write, sampv, samples);

if (-EPIPE == n) {
snd_pcm_prepare(st->write);

n = snd_pcm_writei(st->write, sampv, samples);
if (n != samples) {
warning("alsa: write error: %s\n",
snd_strerror(n));
}
}
else if (n < 0) {
warning("alsa: write error: %s\n", snd_strerror(n));
}
else if (n != samples) {
warning("alsa: write: wrote %d of %d samples\n",
n, samples);
}
}

snd_pcm_drain(st->write);

return NULL;
}
--- end ---

I might dig into this further in the coming days, but since I'm very much
not familiar with ALSA, pulseaudio and debugging threaded applications,
some help would be much appreciated.

I'm mostly writing this to tell you, that I can reproduce this issue at
will (mostly, considering I couln't get debug level logs) and can run
any tests you might need. But figuring out how to make pulseaudio
smarter about switching sample rates or how to make the debian package
detect, that alternate sample rates might not be a good idea on any given
system, is probably above my paygrade.

[1] 
https://pulseaudio-discuss.freedesktop.narkive.com/KCt6OOkP/testing-echo-cancellation-on-an-armhf-omap-phone

[2] https://arunraghavan.net/2011/10/alternate-sample-rates/

[3] https://gitlab.freedesktop.org/pulseaudio/pulseaudio/-/issues/374

-- 
Es gibt viele Maßnahmen gegen die Klimakrise, die leicht und ohne Verlierer
umsetzbar sind. Das Problem ist immer noch das Desinteresse der

Bug#955438: created a new branch with libupb9 and libupb-dev binaries

[Pirate Praveen]

I have created a libupb branch on salsa with new binaries that ships 
these missing files. I'm not sure if they should be part of libgrpc9 
and libgrpc-dev instead. Please review.


https://salsa.debian.org/debian/grpc/-/commit/b0475773f97957ca85d9958b644c923da316c4dc

Bug#955414: python3-pip: pip fails to install packages with pyproject.toml

[reiter . christoph]

Another option might be to stop running them from a wheel, as it's clearly not
supported by upstream.

Bug#955414: python3-pip: pip fails to install packages with pyproject.toml

[reiter . christoph]

On Tue, 31 Mar 2020 09:58:21 -0400 Scott Kitterman  wrote:
> On Tue, 31 Mar 2020 14:31:40 +0200 Christoph Reiter 
>  wrote:
> > Package: python3-pip
> > Version: 20.0.2-2
> > Severity: important
> > 
> > Dear Maintainer,
> > 
> > (Note: This doesn't affect upstream pip, only the Debian/Ubuntu version)
> > 
> > pip in Debian (and Ubuntu focal) fails to install Python packages which 
> contain
> > a pyproject.toml
> > file. I've initially reported this upstream, but it turns out this is only
> > broken in the Debian version of pip.
> > 
> > Related upstream issues:
> > 
> > * https://github.com/pypa/pip/issues/7946
> > * https://github.com/pypa/pip/issues/7874
> > 
> > I've created a minimal reproducer:
> > 
> > https://github.com/lazka/pip-pyproject-bug
> 
> This looks like another instance of #954256 [1].  It looks like it is related 
> to unvendoring pep517, but I don't have it entirely figured out yet.

Thanks, yes that look related.

So looking a bit into it (likely things you already know) this is because Debian
installs wheels of the vendored deps into the venv and pep517 0.7 doesn't
support its scripts being run from there. A newer pep517 got support for
running things from the wheel (https://github.com/pypa/pep517/pull/55),
but the wheel shipped by Debian still is at 0.7.

Replacing the wheel with a newer one leads to

  Traceback (most recent call last):
File "/tmp/tmp8w05syzc", line 26, in 
  import compat
  ModuleNotFoundError: No module named 'compat'

which is kinda expected as imports from the same package don't work in this
context.

On solution would be to inline the "compat.py" module into the "_in_process.py"
script.

Bug#955438: grpc: libupb.so.9 is not installed in any binary package

[Pirate Praveen]

Package: grpc
Version: 1.26.0-2
Severity: serious
Justification: ftbfs on buster

When building in buster (buster-backports branch on salsa), build fails 
with error


dpkg-shlibdeps: error: cannot find library libupb.so.9 needed by 
debian/libgrpc++1/usr/lib/x86_64-linux-gnu/libgrpc++_unsecure.so.1.26.0 
(ELF format: 'elf64-x86-64' abi: '0201003e'; RPATH: '')


looking at the sid build logs, I can see this 
https://buildd.debian.org/status/fetch.php?pkg=grpc&arch=amd64&ver=1.26.0-2&stamp=1584832677&raw=0


dh_missing --list-missing
dh_missing: warning: usr/lib/x86_64-linux-gnu/libupb.so exists in 
debian/tmp but is not installed to anywhere
dh_missing: warning: usr/lib/x86_64-linux-gnu/libupb.so.9 exists in 
debian/tmp but is not installed to anywhere
dh_missing: warning: usr/lib/x86_64-linux-gnu/libupb.so.9.0.0 exists in 
debian/tmp but is not installed to anywhere
dh_missing: warning: usr/lib/x86_64-linux-gnu/libupb.a exists in 
debian/tmp but is not installed to anywhere
The following debhelper tools have reported what they installed (with 
files per package)
 * dh_install: libgrpc++-dev (14), libgrpc++1 (10), libgrpc-dev (14), 
libgrpc9 (11), protobuf-compiler-grpc (7), python3-grpcio (0), 
ruby-grpc (0), ruby-grpc-tools (0)
 * dh_installdocs: libgrpc++-dev (0), libgrpc++1 (0), libgrpc-dev (1), 
libgrpc9 (0), protobuf-compiler-grpc (1), python3-grpcio (0), ruby-grpc 
(0), ruby-grpc-tools (0)
If the missing files are installed by another tool, please file a bug 
against it.
When filing the report, if the tool is not part of debhelper itself, 
please reference the
"Logging helpers and dh_missing" section from the "PROGRAMMING" guide 
for debhelper (10.6.3+).

  (in the debhelper package: /usr/share/doc/debhelper/PROGRAMMING.gz)
Be sure to test with dpkg-buildpackage -A/-B as the results may vary 
when only a subset is built

For a short-term work-around: Add the files to debian/not-installed

Bug#952742: mumble: start locks sound for all application (even the client itself)

[Sébastien Leblanc]

> ii  libjack-jackd2-0 [libjack-0.125]  1.9.12~dfsg-2+b1

I see you have Jack installed, have you checked if Mumble started it?
Unfortunately, while Mumble supports Jack, it does not play nicely with
it in this release, as there are no options in the GUI pertaining to
disabling automatic connections or automatic startup of the Jack server.
By default, it will attempt to start Jack if it is installed on the
system, even if you set the output module to ALSA or PulseAudio.


In `~/.config/Mumble/Mumble.conf`, you can add the following :


%

[jack]
startserver=false

%


Please see if this does anything.

--
Sébastien Leblanc



pEpkey.asc
Description: application/pgp-keys

Bug#918728: libvirt-daemon should provide iscsi-direct storage backend

[Matthew Gabeler-Lee]

Package: libvirt-daemon
Version: 6.0.0-4
Followup-For: Bug #918728

Any chance this can get addressed for bullseye?

FWIW, if I build the package from source with libiscsi-dev (and
corresponding libiscsi7) installed, it auto-detects that it should build
this backend.  Presumably then all that's needed to address this is to
update the build deps, possibly the configure invocation in rules, and the
.install file to include the generated library file?

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

Kernel: Linux 5.4.0-4-amd64 (SMP w/12 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 /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages libvirt-daemon depends on:
ii  libblkid1   2.34-0.1
ii  libc6   2.30-2
ii  libcap-ng0  0.7.9-2.1+b2
ii  libdbus-1-3 1.12.16-2
ii  libdevmapper1.02.1  2:1.02.167-1+b1
ii  libfuse22.9.9-2
ii  libgcc-s1   10-20200324-1
ii  libglib2.0-02.64.1-1
ii  libnetcf1   1:0.2.8-1+b3
ii  libparted2  3.3-4
ii  libpcap0.8  1.9.1-2
ii  libpciaccess0   0.14-1
ii  libselinux1 3.0-1+b1
ii  libudev1244.3-1
ii  libvirt-daemon-driver-qemu  6.0.0-4
ii  libvirt06.0.0-4
ii  libxml2 2.9.10+dfsg-4

Versions of packages libvirt-daemon recommends:
ii  libvirt-daemon-driver-lxc   6.0.0-4
ii  libvirt-daemon-driver-vbox  6.0.0-4
ii  libvirt-daemon-driver-xen   6.0.0-4
ii  libxml2-utils   2.9.10+dfsg-4
ii  netcat-openbsd  1.206-1
ii  qemu-kvm1:4.2-3

Versions of packages libvirt-daemon suggests:
pn  libvirt-daemon-driver-storage-gluster  
pn  libvirt-daemon-driver-storage-rbd  
pn  libvirt-daemon-driver-storage-zfs  
ii  libvirt-daemon-system  6.0.0-4
pn  numad  

-- no debconf information

Bug#914120: closed by Bastien Roucariès (Bug#914120: fixed in imagemagick 8:6.9.10.23+dfsg-1)

[Ryan Kavanagh]

Control: found -1 8:6.9.10.23+dfsg-2.1+b2

imagemagick seems to have lost its heic support. I am getting similar
errors as the reporter (message #5) when I try to use imagemagick on
heic images:

rak@zeta:~$ display /tmp/20200331_103325.heic
display: no decode delegate for this image format `HEIC' @ 
error/constitute.c/ReadImage/509.
rak@zeta:~$ identify /tmp/20200331_103325.heic
identify: no decode delegate for this image format `HEIC' @ 
error/constitute.c/ReadImage/509.
rak@zeta:~$ convert /tmp/20200331_103325.heic /tmp/foo.jpg
convert: no decode delegate for this image format `HEIC' @ 
error/constitute.c/ReadImage/509.
convert: no images defined `/tmp/foo.jpg' @ 
error/convert.c/ConvertImageCommand/3254.

Thanks,
Ryan

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


signature.asc
Description: PGP signature

Bug#954742: evolution: Error performing TLS handshake: A packet with illegal or unsupported version was received.

[Hatem Masmoudi]

Hello,

Same issue here using evolution 3.36.1 with MS exchange Server supprting only 
TLS1.0.



< HTTP/1.1 6 Error performing TLS handshake: A packet with illegal or 
unsupported version was received.
< Soup-Debug-Timestamp: 1585676181
< Soup-Debug: ESoapMessage 0 (0x55fd0188f770)



Any possiblity to enable TLS1.0 support ?

Thanks.

Best  Regard,

Hatem Masmoudi

Bug#953970: Taking over DPMT (Was: python-boto: autopkgtest failure with Python 3.8 as default)

[Andreas Tille]

On Tue, Mar 31, 2020 at 11:40:27AM -0500, Eric Evans wrote:
> > > python-boto, in stable point releases.  Having the team maintain these
> > > packages, as we do with other packages such as cloud-init, would help us
> > > with this goal.
> 
> I agree; cloud-team seems like the best fit
> 
> > I personally don't mind about the team that takes over as long as
> > its more than a single person.  Salvaging criteria
> > 
> > https://wiki.debian.org/PackageSalvaging
> > 
> > are fulfilled but I personally prefer if the maintainer does the move
> > and transfers the Salsa git repository (as described here[1]).
> 
> I'll take care of it.

Thanks a lot, Andreas. 

-- 
http://fam-tille.de

Bug#951222: scikit-learn breaks python-skbio autopkgtest: skbio.stats.distance._permdisp.permdisp

[Christian Kastner]

Control: reassign -1 python-skbio

On 2020-02-12 20:00:16 +0100 Paul Gevers wrote:
> With a recent upload of scikit-learn the autopkgtest of python-skbio
> fails in testing when that autopkgtest is run with the binary packages
> of scikit-learn from unstable. It passes when run with only packages
> from testing. In tabular form:
>passfail
> scikit-learn   from testing0.22.1+dfsg-1
> python-skbio   from testing0.5.5-3
> all others from testingfrom testing
> 
> I copied some of the output at the bottom of this report.
> 
> Currently this regression is blocking the migration of scikit-learn to
> testing [1]. Due to the nature of this issue, I filed this bug report
> against both packages. Can you please investigate the situation and
> reassign the bug to the right package?
As indicated in a previous reply, the test case itself runs fine with
scikit-learn 0.22.2.post1+dfsg-5 (and even earlier) when called through
pytest.

It's only when python-skbio's internal test runner is called that the
test fails. Therefore, one can probably safely assume that the issue
must originate there.

Furthermore, as python-skbio was already removed from testing and
therefore, a newer scikit-learn won't be an issue there, I'm reassigning
this to python-skbio only, so that scikit-learn can migrate.

Bug#635278: Fwd: /////// v Grüße

[Stephen . W L. PHALA]

*Grüße,Ich habe Ihnen diesen Brief vor einem Monat geschickt, aber ich bin
mir nicht sicher, ob Sie ihn erhalten haben. Ich habe keine Nachricht von
Ihnen erhalten, und deshalb werde ich ihn noch einmal wiederholen.Ich bin
ein Anwalt Stephen W. W. L. PHALA,, der persönliche Anwalt meines
verstorbenen Mandanten vor seinem unglücklichen Tod mit seiner Familie. Ich
erhielt von seiner Bank das Mandat, nahe Verwandte seines Fonds zu
beliefern (13.580.000 USD), weshalb ich Sie kontaktierte. Nach einem
erfolglosen Versuch, einen Verwandten meines verstorbenen Kunden zu finden,
habe ich beschlossen, Sie zu kontaktieren, da Sie denselben Namen und
dieselbe Nationalität bei sich haben.Bitte kontaktieren Sie mich für
weitere Informationen.Mit freundlichen GrüßenRechtsanwalt Stephen .esg*

Bug#955436: fping6 -6 gives misleading error message

[Marc Haber]

Package: fping
Version: 4.2-1+b1
Severity: minor

Hi,

look:

[1/5592]mh@drop:~ $ fping6 -6 2a01:238:42bc:a101::1
fping6: can't specify both -4 and -6
1 [2/5593]mh@drop:~ $ fping6 2a01:238:42bc:a101::1
2a01:238:42bc:a101::1 is alive
[3/5594]mh@drop:~ $ fping 2a01:238:42bc:a101::1
2a01:238:42bc:a101::1 is alive
[4/5595]mh@drop:~ $ fping -6 2a01:238:42bc:a101::1
2a01:238:42bc:a101::1 is alive
[5/5596]mh@drop:~ $ fping -6 -6 2a01:238:42bc:a101::1
fping: can't specify both -4 and -6
1 [6/5597]mh@drop:~ $

The code should handle the same address family option given twice in a
more graceful way.

Greetings
Marc


-- Package-specific info:
-rwxr-xr-x 1 root root 48032 Aug  7  2019 /usr/bin/fping
lrwxrwxrwx 1 root root 5 Aug  7  2019 /usr/bin/fping6 -> fping

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

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

Versions of packages fping depends on:
ii  libc62.30-4
ii  libcap2-bin  1:2.33-1
ii  netbase  6.1

fping recommends no packages.

fping suggests no packages.

-- no debconf information

Bug#878082: python3-pip: TypeError

[Laurent Bonnaud]

Hi,

thank you for this new package version and attempt to fix this bug!  

Unfortunately I am still getting an exception on my system:

Package: python3-pip
Version: 20.0.2-2

# pip3 list --outdated
WARNING: pip is being invoked by an old script wrapper. This will fail in a 
future version of pip.
Please see https://github.com/pypa/pip/issues/5599 for advice on fixing the 
underlying issue.
To avoid this problem you can invoke Python with '-m pip' instead of running 
pip directly.
ERROR: Exception:
Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/pip/_internal/cli/base_command.py", line 
186, in _main
status = self.run(options, args)
  File "/usr/lib/python3/dist-packages/pip/_internal/commands/list.py", line 
158, in run
packages = self.get_outdated(packages, options)
  File "/usr/lib/python3/dist-packages/pip/_internal/commands/list.py", line 
165, in get_outdated
return [
  File "/usr/lib/python3/dist-packages/pip/_internal/commands/list.py", line 
167, in 
if dist.latest_version > dist.parsed_version
TypeError: '>' not supported between instances of 'Version' and 'Version'

or

# python3 -m pip list --outdated 
ERROR: Exception:
Traceback (most recent call last):  

  File "/usr/lib/python3/dist-packages/pip/_internal/cli/base_command.py", line 
186, in _main   
status = self.run(options, args)

  File "/usr/lib/python3/dist-packages/pip/_internal/commands/list.py", line 
158, in run
packages = self.get_outdated(packages, options) 

  File "/usr/lib/python3/dist-packages/pip/_internal/commands/list.py", line 
165, in get_outdated   
return [

  File "/usr/lib/python3/dist-packages/pip/_internal/commands/list.py", line 
167, in  
if dist.latest_version > dist.parsed_version

TypeError: '>' not supported between instances of 'Version' and 'Version'   
  

-- 
Laurent.

Bug#955435: libopencv-features2d4.2: package cannot be installed with apt-get because of conflicting dependencies

[Julian Grahsl]

Package: libopencv-features2d4.2
Severity: grave
Justification: renders package unusable
Tags: a11y
 
Dear Maintainer,
 
   * What led up to the situation?
 
Install a fresh system, for example using a docker image with
—
# docker run —rm -it debian:unstable
—
 
Inside the container run:
 
— 
# apt-get update
# apt-get install libopencv-features2d4.2
—
 
   * What was the outcome of this action?
 
—
The following packages have unmet dependencies:
 libopencv-features2d4.2 : Depends: libopencv-highgui4.2 (= 4.2.0+dfsg-5+b2) 
but it is not going to be installed
E: Unable to correct problems, you have held broken packages.
— 
 
   * What outcome did you expect instead?
 
Successful installation of the package.
 
 
-- System Information:
Debian Release: bullseye/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: arm64 (aarch64)
 
Kernel: Linux 4.4.38+ (SMP w/6 CPU cores; PREEMPT)
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: unable to detect
 
Versions of packages libopencv-features2d4.2 depends on:
ii  libc6 2.30-4
ii  libgcc-s1 10-20200324-1
pn  libopencv-core4.2 
pn  libopencv-flann4.2
pn  libopencv-highgui4.2  
pn  libopencv-imgproc4.2  
pn  libopencv-ml4.2   
ii  libstdc++610-20200324-1
 
libopencv-features2d4.2 recommends no packages.
 
libopencv-features2d4.2 suggests no packages.
Report will be sent to Debian Bug Tracking System mailto:sub...@bugs.debian.org>>

Bug#955433: sahara-plugin-vanilla: FTBFS: AttributeError: 'NoneType' object has no attribute 'get_plugin'

[Andreas Beckmann]

Source: sahara-plugin-vanilla
Version: 2.0.0-1
Severity: serious
Tags: ftbfs
Justification: fails to build from source

sahara-plugin-vanilla/experimental FTBFS:

==
FAIL: 
sahara_plugin_vanilla.tests.unit.plugins.vanilla.v2_8_2.test_versionhandler.VersionHandlerTest.test_get_edp_engine
sahara_plugin_vanilla.tests.unit.plugins.vanilla.v2_8_2.test_versionhandler.VersionHandlerTest.test_get_edp_engine
--
testtools.testresult.real._StringException: Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/mock/mock.py", line 1330, in patched
return func(*args, **keywargs)
  File 
"/build/sahara-plugin-vanilla-2.0.0/sahara_plugin_vanilla/tests/unit/plugins/vanilla/v2_8_2/test_versionhandler.py",
 line 216, in test_get_edp_engine
ret = self.vh.get_edp_engine(self.cluster, job_type)
  File 
"/build/sahara-plugin-vanilla-2.0.0/sahara_plugin_vanilla/plugins/vanilla/v2_8_2/versionhandler.py",
 line 147, in get_edp_engine
return edp_engine.EdpOozieEngine(cluster)
  File "/usr/lib/python3/dist-packages/sahara/plugins/edp.py", line 64, in 
__init__
super(PluginsOozieJobEngine, self).__init__(cluster)
  File "/usr/lib/python3/dist-packages/sahara/service/edp/oozie/engine.py", 
line 48, in __init__
self.plugin = job_utils.get_plugin(self.cluster)
  File "/usr/lib/python3/dist-packages/sahara/service/edp/job_utils.py", line 
48, in get_plugin
return plugin_base.PLUGINS.get_plugin(cluster.plugin_name)
AttributeError: 'NoneType' object has no attribute 'get_plugin'


--
Ran 165 tests in 6.247s

FAILED (failures=1)


Andreas


sahara-plugin-vanilla_2.0.0-1.log.gz
Description: application/gzip

Bug#955434: tracker.d.o: please integrate information from buildinfos.debian.net

[Holger Levsen]

Package: tracker.debian.org
Severity: wishlist

Dear Maintainer,

please integrate information from buildinfos.debian.net into tracker.d.o,
which is a different view/aspect of reproducible builds of Debian packages than
the one currently integrated.

The current one is about the results from tests.reproducible-builds.org/debian
and shows the theoretical reproducibility of a given package. (Two builds are
done and compared.)

The information we would like to have integrated into tracker.d.o is a
link to .buildinfo files for source packages, based on the architecture
the build was done. These .buildinfo files are available on 
buildinfos.debian.net, here's some more background information on
that service:

https://buildinfos.debian.net/ provides .buildinfo files for packages
distributed on ftp.debian.org. Two views are available:

https://buildinfos.debian.net/ftp-master.debian.org/ is a public copy
of /srv/ftp-master.debian.org/buildinfo/ from ftp-master.debian.org.
This data is organized by build dates, which is little useful to most.

https://buildinfos.debian.net/buildinfo-pool/ provides a pool structure
of this data, for example to 
https://buildinfos.debian.net/buildinfo-pool/libf/libfakekey/libfakekey_0.1-10_hurd-i386.buildinfo

https://buildinfos.debian.net/buildinfo-pool.list is one 66mb file,
listing all currently known .buildinfo for Debian packages distributed
via ftp-master.d.o since 2016-12-22.

This excludes
- builds done before 2016-12-22.
- builds not done on buildds.
- security updates not yet re-released via a point update.
- and probably some more.

In future we probably would like to export a json dump of a postgresql
db, so that the data will become easier to parse. Not sure if this is
needed for the tracker.d.o side to get started?

Feedback welcome!


-- 
cheers,
Holger

---
   holger@(debian|reproducible-builds|layer-acht).org
   PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C


signature.asc
Description: PGP signature

Bug#954371: [Pkg-openssl-devel] Bug#954371: libio-socket-ssl-perl: FTBFS since openssl 1.1.1e

[Kurt Roeckx]

On Tue, Mar 31, 2020 at 09:03:01AM +0200, Salvatore Bonaccorso wrote:
> On Sat, Mar 21, 2020 at 08:31:21PM +0100, gregor herrmann wrote:
> > On Fri, 20 Mar 2020 21:50:08 +0100, Sebastian Andrzej Siewior wrote:
> > 
> > > The package FTBFS since openssl has been updated to 1.1.1e because the
> > > testsuite fails. The failure is due to commit db943f43a60d ("Detect EOF
> > > while reading in libssl") [0] in openssl. There an issue ticket [1]
> > > which introduced the changed behaviour.
> > 
> > There's a patch at
> > https://github.com/noxxi/p5-io-socket-ssl/issues/93
> > This also needs libnet-ssleay-perl_1.88-3 which I uploaded right now.
> 
> So I guess this should be threated as openssl issue and will reassign
> it to it. Upstream for IO::Socket::SSL has released a new version
> which will refuse to build with 1.1.1e:
> 
> 2.068 2020/03/31
> - treat OpenSSL 1.1.1e as broken and refuse to build with it in order to
>   prevent follow-up problems in tests and user code
>   https://github.com/noxxi/p5-io-socket-ssl/issues/93
>   https://github.com/openssl/openssl/issues/11388
>   https://github.com/openssl/openssl/issues/11378

There might be a misunderstanding. First, in 3.0, we will
reintroduce this new behaviour.

We always returned an error in case of an unexpected EOF. We
changed the error code of that case. Applications should never
trigger the unexpected EOF and should get fixed not to trigger it.


Kurt