Bug#923889: google-compute-image-packages - DoS via serial console write

[Thomas Goirand]

On 3/7/19 11:25 PM, Ross Vandegrift wrote:
> On Wed, Mar 06, 2019 at 07:49:38PM +0100, Bastian Blank wrote:
>> This package instructs journald to duplicate everything sent to the
>> journal to the serial console.  The serial console is a pretty rate
>> limited log output device and blocking there will make all software with
>> any log output block.
> 
> This doesn't seem to affect all software - I tried to reproduce with
> logger, but it doesn't block.  Maybe this only affects some logging
> transports?
> 
> I agree it's a problematic default - GCE serial console data is
> currently stored unencrypted.  That could be an unpleasent surprise.
> 
> Ross

Ross,

Bastian is right that what's been done is a very bad idea. I would
suggest that you the issue is taken seriously, and the change be
reverted. In many situation, the serial port wont be fast enough.

Cheers,

Thomas Goirand (zigo)

Bug#924001: evince cannot decrypt PDFs using 256-bit keys

[Josh Triplett]

Package: evince
Version: 3.31.91-1
Severity: normal

Steps to reproduce:

- Install qpdf
- Have an unencrypted PDF "test.pdf"
- qpdf --encrypt 123456789 123456789 256 -- test.pdf test-256.pdf
- Try to open test-256.pdf with evince. Enter the password "123456789".
  Notice that evince fails and prompts for the password again.
- qpdf --encrypt 123456789 123456789 128 -- test.pdf test-128.pdf
- Try to open test-128.pdf with evince. Enter the password "123456789".
  Notice that evince succeeds.

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

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

Versions of packages evince depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.30.1-2
ii  evince-common3.31.91-1
ii  gsettings-desktop-schemas3.28.1-1
ii  libatk1.0-0  2.30.0-2
ii  libc62.28-8
ii  libcairo-gobject21.16.0-3
ii  libcairo21.16.0-3
ii  libevdocument3-4 3.31.91-1
ii  libevview3-3 3.31.91-1
ii  libgdk-pixbuf2.0-0   2.38.1+dfsg-1
ii  libglib2.0-0 2.58.3-1
ii  libgnome-desktop-3-173.30.2.1-1
ii  libgtk-3-0   3.24.5-1
ii  libnautilus-extension1a  3.30.5-1
ii  libpango-1.0-0   1.42.4-6
ii  libpangocairo-1.0-0  1.42.4-6
ii  libsecret-1-00.18.7-1
ii  shared-mime-info 1.10-1

Versions of packages evince recommends:
ii  dbus-user-session [default-dbus-session-bus]  1.12.12-1
ii  dbus-x11 [dbus-session-bus]   1.12.12-1

Versions of packages evince suggests:
ii  gvfs 1.38.1-3
ii  nautilus-sendto  3.8.6-3
ii  poppler-data 0.4.9-2
pn  unrar

-- no debconf information

Bug#924000: cdimage.debian.org: Live images /usr/sbin/policy-rc.d disables daemons

[Daniel Lewart]

Package: cdimage.debian.org
Severity: normal
Tags: patch

Images Team,

Weekly Live Image:
  https://cdimage.debian.org/cdimage/weekly-live-builds/amd64/iso-hybrid/
  debian-live-testing-amd64-gnome.iso  2019-03-04

"apt update; apt upgrade" generates errors like those below.

I believe that the root cause is that live-setup
available/live-customise.sh is missing "remove_daemon_block".

vmdebootstrap/README.devel says:
> All scripts need to use remove_daemon_block after package
> installation is complete.

An *untested* patch is attached.

Thank you!
Dan

$ grep -B1 'rc\.d' apt-upgrade.log
Setting up apt (1.8.0~rc4) ...
/usr/sbin/policy-rc.d returned 101, not running 'restart
apt-daily-upgrade.timer apt-daily.timer'
--
Preparing to unpack .../00-cron_3.0pl1-132_amd64.deb ...
invoke-rc.d: policy-rc.d denied execution of stop.
--
Setting up cron (3.0pl1-132)
invoke-rc.d: policy-rc.d denied execution of restart.
/usr/sbin/policy-rc.d returned 101, not running 'restart cron.service'
--
Setting up udev (241-1)
invoke-rc.d: policy-rc.d denied execution of restart.
--
Setting up upower (0.99.10-1)
/usr/sbin/policy-rc.d returned 101, not running 'restart upower.service'
--
Setting up exim4-daemon-light (4.92-2) ...
invoke-rc.d: policy-rc.d denied execution of start.

diff -ru a/available/live-customise.sh b/available/live-customise.sh
--- a/available/live-customise.sh   2019-02-14 19:57:33.0 -0600
+++ b/available/live-customise.sh   2019-03-08 00:00:00.0 -0600
@@ -66,7 +66,7 @@
 
 echo "blacklist bochs-drm" > $rootdir/etc/modprobe.d/qemu-blacklist.conf
 
+remove_daemon_block
 replace_apt_source
 
 mv ${rootdir}/etc/resolv.conf ${rootdir}/etc/resolv.conf.bak
-

Bug#923226: Compiling shader doesn't work - game doesn't work

[Julien Puydt]

Hi,

Le 07/03/2019 à 18:39, Simon McVittie a écrit :

On Thu, 07 Mar 2019 at 13:30:57 +0100, Julien Puydt wrote:

Just changing the ioquake3 binary package (which makes dpkg complain about
ioquake3-server, but it's normal):
1.36+u20181017.09166ba~dfsg-2 works
1.36+u20181222.e5da13f~dfsg-1 fails


What graphics stack are you using, in particular your kernel and Mesa
driver? Running `reportbug --template ioquake3` will summarize the most
relevant packages.

It looks as though the problem might be that your driver only provides
GLSL 1.20 (either on your hardware or in general), whereas the hitCube()
function introduced between 09166ba and e5da13f assumes GLSL 1.30
or later.



To give more information about the GL stack here, here are exerpts from 
running glxinfo:


direct rendering: Yes
server glx vendor string: SGI
server glx version string: 1.4

client glx vendor string: Mesa Project and SGI
client glx version string: 1.4

GLX version: 1.4

Extended renderer info (GLX_MESA_query_renderer):
Vendor: Intel Open Source Technology Center (0x8086)
Device: Mesa DRI Intel(R) Ironlake Mobile  (0x46)
Version: 18.3.4
Accelerated: yes
Video memory: 1536MB
Unified memory: yes
Preferred profile: compat (0x2)
Max core profile version: 0.0
Max compat profile version: 2.1
Max GLES1 profile version: 1.1
Max GLES[23] profile version: 2.0
OpenGL vendor string: Intel Open Source Technology Center
OpenGL renderer string: Mesa DRI Intel(R) Ironlake Mobile
OpenGL version string: 2.1 Mesa 18.3.4
OpenGL shading language version string: 1.20

OpenGL ES profile version string: OpenGL ES 2.0 Mesa 18.3.4
OpenGL ES profile shading language version string: OpenGL ES GLSL ES 1.0.16


Hope that helps,

jpuydt on irc.debian.org

Bug#923226: Compiling shader doesn't work - game doesn't work

[Julien Puydt]

Le 07/03/2019 à 18:39, Simon McVittie a écrit :

On Thu, 07 Mar 2019 at 13:30:57 +0100, Julien Puydt wrote:

Just changing the ioquake3 binary package (which makes dpkg complain about
ioquake3-server, but it's normal):
1.36+u20181017.09166ba~dfsg-2 works
1.36+u20181222.e5da13f~dfsg-1 fails


What graphics stack are you using, in particular your kernel and Mesa
driver? Running `reportbug --template ioquake3` will summarize the most
relevant packages.

>

It looks as though the problem might be that your driver only provides
GLSL 1.20 (either on your hardware or in general), whereas the hitCube()
function introduced between 09166ba and e5da13f assumes GLSL 1.30
or later.


Here is what seems relevant in reportbug:

Kernel: Linux 4.17.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), 
LANGUAGE=fr_FR.UTF-8 (charmap=UTF-8) 


Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages ioquake3 depends on:
ii  ioquake3-server  1.36+u20181222.e5da13f~dfsg-1
ii  libc62.28-8
ii  libcurl3-gnutls  7.64.0-2
ii  libgl1   1.1.0-1
ii  libjpeg62-turbo  1:1.5.2-2+b1
ii  libogg0  1.3.2-1+b1
ii  libopenal1   1:1.19.1-1
ii  libopus0 1.3-1
ii  libopusfile0 0.9+20170913-1
ii  libsdl2-2.0-02.0.9+dfsg1-1
ii  libvorbis0a  1.3.6-2
ii  libvorbisfile3   1.3.6-2
ii  zlib1g   1:1.2.11.dfsg-1

Versions of packages ioquake3 recommends:
ii  x11-utils  7.7+4
ii  zenity 3.30.0-2

ioquake3 suggests no packages.

Versions of packages ioquake3 is related to:
ii  libgl1-mesa-dri  18.3.4-2


The following should also tell more about the graphics hardware:
# lspci -s  00:02.0 -vvv
00:02.0 VGA compatible controller: Intel Corporation Core Processor 
Integrated Graphics Controller (rev 02) (prog-if 00 [VGA controller])

Subsystem: Dell Latitude E6410
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- 
ParErr- Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- 
SERR- 
Latency: 0
Interrupt: pin A routed to IRQ 26
Region 0: Memory at f000 (64-bit, non-prefetchable) [size=4M]
Region 2: Memory at e000 (64-bit, prefetchable) [size=256M]
Region 4: I/O ports at 70b0 [size=8]
[virtual] Expansion ROM at 000c [disabled] [size=128K]
Capabilities: [90] MSI: Enable+ Count=1/1 Maskable- 64bit-
Address: fee01004  Data: 4023
Capabilities: [d0] Power Management version 2
Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA 
PME(D0-,D1-,D2-,D3hot-,D3cold-)

Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [a4] PCI Advanced Features
AFCap: TP+ FLR+
AFCtrl: FLR-
AFStatus: TP-
Kernel driver in use: i915
Kernel modules: i915


Hope that helps,

jpuydt on irc.debian.org

Bug#923541: [debian-mysql] Bug#923541: libdbd-mysql-perl: FTBFS against mariadb-10.3 1:10.3.13-1

[Otto Kekäläinen]

Thanks!

Bug#919825: systemd: local filesystems other than '/' and '/usr' not checked and mounted -- emergency mode

[Bob Tracy]

On Thu, Mar 07, 2019 at 10:52:13AM +0100, Michael Biebl wrote:
> Sounds a bit like
> https://github.com/systemd/systemd/issues/3446#issuecomment-224046140
> 
> Please check that your kernel has all options enabled that are listed in
> /usr/share/doc/systemd/README.gz
> 
> Are you currently missing any of those options?

I'll admit to getting bitten by CONFIG_FHANDLE not being set a long time
ago.  Back then, I was directed toward the systemd "README" file to see
if there were any other kernel config options that I hadn't set
correctly.  I'm pretty sure none of the required options are missing,
but an extra set of eyes looking at it couldn't hurt.  My ".config" file
for 5.0.0 is attached.

Do please note at least one fundamental difference (philosophical?)
between my hand-built kernels and the usual distro-provided kernels.  I
like to build-in the drivers that are needed at boot time, *including*
any required firmware.  I don't know if "systemd/udev" would (or should)
be affected by the disk device drivers being built-in instead of modules,
but it might be interesting to see if the Debian generic kernel for alpha
configures the qlogic SCSI driver as built-in or modular (because it
requires firmware that loads at driver initialization).

I heard back concerning availability of a fixed generic kernel for
Alpha.  The latest upload of linux failed to build on a number of
architectures, including Alpha.


alpha_config.gz
Description: application/gunzip

Bug#923999: unblock: lammps/0~20181211.gitad1b1897d+dfsg1-2

[Andreas Tille]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Please unblock package lammps


diff -Nru lammps-0~20181211.gitad1b1897d+dfsg1/debian/changelog 
lammps-0~20181211.gitad1b1897d+dfsg1/debian/changelog
--- lammps-0~20181211.gitad1b1897d+dfsg1/debian/changelog   2018-12-20 
21:27:37.0 +0100
+++ lammps-0~20181211.gitad1b1897d+dfsg1/debian/changelog   2019-03-08 
07:18:57.0 +0100
@@ -1,3 +1,11 @@
+lammps (0~20181211.gitad1b1897d+dfsg1-2) unstable; urgency=medium
+
+  * Team upload.
+  * Build-Depends: gfortran
+Closes: #923466
+
+ -- Andreas Tille   Fri, 08 Mar 2019 07:18:57 +0100
+
 lammps (0~20181211.gitad1b1897d+dfsg1-1) unstable; urgency=medium

   * [63546ae] Fix typo in d/copyright
diff -Nru lammps-0~20181211.gitad1b1897d+dfsg1/debian/control 
lammps-0~20181211.gitad1b1897d+dfsg1/debian/control
--- lammps-0~20181211.gitad1b1897d+dfsg1/debian/control 2018-12-20 
19:30:47.0 +0100
+++ lammps-0~20181211.gitad1b1897d+dfsg1/debian/control 2019-03-08 
07:18:57.0 +0100
@@ -6,7 +6,7 @@
 Build-Depends: debhelper (>= 11~),
libeigen3-dev,
cmake,
-   fortran-compiler,
+   gfortran | fortran-compiler,
libfftw3-dev,
libjpeg-dev,
mpi-default-bin,



unblock lammps/0~20181211.gitad1b1897d+dfsg1-2

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

Kernel: Linux 4.9.0-6-amd64 (SMP w/1 CPU core)
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)

Bug#923998: openvpn: Openvpn tun0 loses IP and route

[Stefan Monnier]

Package: openvpn
Version: 2.4.7-1
Severity: normal

Dear Maintainer,

My OpenVPN client setup just stopped working, maybe/likely linked to a recent
update of Debian (testing).

The end result is that the openvpn daemon looks happy and gives me the right
syslog messages, yet the interface gets no IP address (and no routes either, of
course):

# ifconfig tun0
tun0: flags=4305  mtu 1500
inet6 fe80::e580:a6b8:6f2:dd5  prefixlen 64  scopeid 0x20
unspec 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00  txqueuelen
100  (UNSPEC)
RX packets 0  bytes 0 (0.0 B)
RX errors 0  dropped 0  overruns 0  frame 0
TX packets 7  bytes 336 (336.0 B)
TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

The syslog includes the expected lines such as:

Jan 25 11:12:41 ceviche ovpn-foo[9570]: /sbin/ip addr add dev tun0
NN.MM.OO.PP/24 broadcast NN.MM.OO.255
Jan 25 11:12:41 ceviche ovpn-foo[9570]: /sbin/ip route add HOSTIP1/32 via
NN.MM.OO.1

and if I run these lines by hand, then things go back to working (until the VPN
is restarted, obviously).

So my impression is that the interface is setup correctly but is later "undone"
by some external thing.  This impression comes from some suspicious extra
messages mentioning `tun0` that appear a bit further in the log:

Jan 25 11:12:41 ceviche systemd[1]: Unnecessary job for
/sys/subsystem/net/devices/tun0 was removed.
Jan 25 11:12:41 ceviche systemd[1]: Started Netscript ifup for tun0.
[...]
Jan 25 11:12:41 ceviche sh[9617]: Configuring interface: tun0.

Any idea what might be going on, how to track it down, or how to fix it?

This is a Debian testing system that's been following Debian testing for many
years.



-- System Information:
Debian Release: buster/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'stable')
Architecture: i386 (i686)

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

Versions of packages openvpn depends on:
ii  debconf [debconf-2.0]  1.5.71
ii  iproute2   4.20.0-2
ii  libc6  2.28-7
ii  liblz4-1   1.8.3-1
ii  liblzo2-2  2.10-0.1
ii  libpam0g   1.3.1-5
ii  libpkcs11-helper1  1.25.1-1
ii  libssl1.1  1.1.1a-1
ii  libsystemd0241-1
ii  lsb-base   10.2018112800

Versions of packages openvpn recommends:
pn  easy-rsa  

Versions of packages openvpn suggests:
ii  openssl   1.1.1a-1
pn  openvpn-systemd-resolved  
ii  resolvconf1.79

-- Configuration Files:
/etc/default/openvpn changed [not included]

-- debconf information:
  openvpn/vulnerable_prng:
  openvpn/create_tun: false

Bug#850288: python-scipy: bug in scipy._lib._threadsafety.py, decorator function name wrong

[Drew Parsons]

Package: python-scipy
Followup-For: Bug #850288

As far as I can read the code, it is correct to use decorate on a
function rather than decorator. The source says it is obsolete
behaviour to use decorator() with a function.

Can you explain why you think it needs to be done?

Note you've given the arguments in the reverse order. The signature for
decorator is decorator(caller, _func=None), not decorator(func, caller).

Drew

Bug#923662: mark lua-say Multi-Arch: foreign

[Helmut Grohne]

On Thu, Mar 07, 2019 at 09:08:37PM -0500, Jason Pleau wrote:
> Do you think this warrants an unblock request? I can arrange for an
> upload, but will request an unblock if this blocks another package from
> working correctly.

I'm pretty sure that it doesn't. Multiarch is still considered an
optional feature with limited adoption. This is just one drop in the
bucket. However, if you need to do an upload anyway, I'd expect that
such a change could be piggy-backed. In general, "normal" bugs are not
unblock material.

Helmut

Bug#786885: Broken gettext check in the build system of bison

[Helmut Grohne]

Control: clone -1 -2
Control: reassign -2 gettext
Control: retitle -2 broken gettext check in gettext.m4
Control: tags -2 + upstream
Control: affects -2 + src:attr

On Tue, May 26, 2015 at 02:46:06PM +0200, Szabolcs Nagy wrote:
> When building bison on a musl libc based system, creating
> the package fails because it incorrectly assumes that the
> libc has no gettext support.
> 
> The bison configure.ac uses
> 
>  AM_GNU_GETTEXT([external], [need-ngettext])
> 
> which ends up checking for glibc internal symbols
> _nl_msg_cat_cntr and _nl_domain_bindings instead of just
> checking for the API in use (gettext and ngettext).
> 
> This issue is reported upstream at
> http://lists.gnu.org/archive/html/bug-gettext/2015-04/msg2.html
> 
> More discussions at the musl-libc mailing list:
> http://www.openwall.com/lists/musl/2015/04/16/3

This actually holds for the copy of gettext.m4 as shipped by gettext it
self.

> To fix it, remove _nl_* checks from m4/gettext.m4.

Yes please. Alternatively, if AM_GNU_GETTEXT is really meant to exclude
non-GNU implementations, please add some AM_ANY_GETTEXT macro such that
we can easily switch all Debian consumers to a portable version.

Helmut

Bug#923661: (no subject)

[Nazar Zhuk]

This is also happening on a fresh buster install.

-- 
Nazar

Bug#923457: test_likelihood_nh (Failed)

[Andreas Tille]

Hi Julien,

after fixing bug #923457 I realised that the package does not
build on all architectures[1]. S390x fails with[2]

 4/14 Test  #5: test_likelihood_nh ...***Failed2.44 sec

/ 1
- 2
\ 3
- 4
/ 5
- 6
\ 7
- 8
/ 9
- 10
\ 11 nodes loaded.
Theta0 set to 0.444785
Theta1 set to 0.137341
Theta2 set to 0.219281
Theta3 set to 0.759382
Theta4 set to 0.549516
Theta5 set to 0.925583
Theta6 set to 0.527333
Theta7 set to 0.891561
Theta8 set to 0.331932
Theta9 set to 0.523327
Initializing data structure: Done.
Number of distinct sites...: 363
Initializing data structure: Done.
Number of distinct sites...: 363

Optimizing... / 1
Optimizing... - 2
Optimizing... \ 3
Optimizing... - 4
Optimizing... / 5
Optimizing... - 6
Optimizing... \ 7
Optimizing... - 8
Optimizing... / 9
Optimizing... - 10
Optimizing... \ 11
Optimizing... - 12
Optimizing... / 13
Optimizing... - 14


Optimizing... / 1
Optimizing... - 2
Optimizing... \ 3
Optimizing... - 4
Optimizing... / 5
Optimizing... - 6
Optimizing... \ 7
Optimizing... - 8
Optimizing... / 9
Optimizing... - 10
Optimizing... \ 11
Optimizing... - 12
Optimizing... / 13
Optimizing... - 14

15: 5347.92 15: 5347.92
0.516673 0.516673
0.184681 0.184681
0.209158 0.209158
0.795359 0.795359
0.489372 0.489372
0.918414 0.918414
0.489537 0.489537
0.913968 0.913968
0.180359 0.180359
0.797456 0.797456
Initializing data structure: Done.
Number of distinct sites...: 365
Initializing data structure: Done.
Number of distinct sites...: 365

Optimizing... / 1
Optimizing... - 2
Optimizing... \ 3
Optimizing... - 4
Optimizing... / 5
Optimizing... - 6
Optimizing... \ 7
Optimizing... - 8
Optimizing... / 9
Optimizing... - 10
Optimizing... \ 11
Optimizing... - 12
Optimizing... / 13
Optimizing... - 14
Optimizing... \ 15
Optimizing... - 16
Optimizing... / 17


Optimizing... / 1
Optimizing... - 2
Optimizing... \ 3
Optimizing... - 4
Optimizing... / 5
Optimizing... - 6
Optimizing... \ 7
Optimizing... - 8
Optimizing... / 9
Optimizing... - 10
Optimizing... \ 11
Optimizing... - 12
Optimizing... / 13
Optimizing... - 14
Optimizing... \ 15
Optimizing... - 16
Optimizing... / 17

18: 5391.43 18: 5391.43
0.60777 0.60777
0.127151 0.127151
0.189039 0.189039
0.788612 0.788612
0.564763 0.564763
0.941319 0.941319
0.565297 0.565297
0.844854 0.844854
0.357532 0.357532
0.717998 0.717998
Initializing data structure: Done.
Number of distinct sites...: 375
Initializing data structure: Done.
Number of distinct sites...: 375

Optimizing... / 1
Optimizing... - 2
Optimizing... \ 3
Optimizing... - 4
Optimizing... / 5
Optimizing... - 6
Optimizing... \ 7
Optimizing... - 8
Optimizing... / 9
Optimizing... - 10
Optimizing... \ 11
Optimizing... - 12
Optimizing... / 13
Optimizing... - 14


Optimizing... / 1
Optimizing... - 2
Optimizing... \ 3
Optimizing... - 4
Optimizing... / 5
Optimizing... - 6
Optimizing... \ 7
Optimizing... - 8
Optimizing... / 9
Optimizing... - 10
Optimizing... \ 11
Optimizing... - 12
Optimizing... / 13
Optimizing... - 14

15: 5401.83 15: 5401.83
0.419181 0.419181
0.140299 0.140299
0.295 0.295
0.900203 0.900203
0.411605 0.411605
0.919716 0.919716
0.563041 0.563041
0.813833 0.813833
0.194868 0.194868
0.801315 0.801315
0.444785 0.514541 0.514541
0.137341 0.15071 0.15071
0.219281 0.231066 0.231066
0.759382 0.828058 0.828058
0.549516 0.48858 0.48858
0.925583 0.926483 0.926483
0.527333 0.539292 0.539292
0.891561 0.857552 0.857552
0.331932 0.244253 0.244253
0.523327 0.772256 0.772256


...

93% tests passed, 1 tests failed out of 14

Total Test time (real) =  31.15 sec

The following tests FAILED:
   5 - test_likelihood_nh (Failed)


I remember that I once had even a test failure on my local amd64 - so
this test might be a bit undetermined.  Please confirm this and I'd be
happy if you could send an *as simple as possible* patch or simply
deactivate the patch.  We are in deep freeze and need to find a quick
and also simple solution.

Kind regards

   Andreas.


[1] https://buildd.debian.org/status/package.php?p=libbpp-phyl
[2] 
https://buildd.debian.org/status/fetch.php?pkg=libbpp-phyl=s390x=2.4.1-2=1551477555=0

-- 
http://fam-tille.de

Bug#923996: diffoscope: --exclude doesn't work too well with sub-archives

[Mike Hommey]

Package: diffoscope
Version: 113
Severity: normal

Take the following testcase:

$ mkdir a b c
$ echo 0 > c/0
$ zip a/0.zip c/0
$ echo 1 > c/0
$ zip b/0.zip c/0
$ diffoscope a b --exclude-directory-metadata=recursive
--- a
+++ b
├── 0.zip
│ ├── c/0
│ │ @@ -1 +1 @@
│ │ -0
│ │ +1

The only way I found to exclude c/0 is: "--exclude c/0", which makes it
ignore under which archive it was found, so if there is, in fact,
another archive with the same path, both are excluded.

And because the result of "--exclude c/0" is that there is no content
difference found between the archives, diffoscope now thinks it should
display format-specific differences:

--- a
+++ b
├── 0.zip
│┄ Format-specific differences are supported for this file format but no 
file-specific differences were detected; falling back to a binary diff. file(1) 
reports: Zip archive data, at least v1.0 to extract
│ @@ -1,10 +1,10 @@
│ -: 504b 0304 0a00   3170 684e 12cd  PK1phN..
│ -0010: 4a7e 0200  0200  0300 1c00 632f  J~c/
│ +: 504b 0304 0a00   3170 684e 53fc  PK1phNS.
│ +0010: 5167 0200  0200  0300 1c00 632f  Qgc/
│  0020: 3055 5409 0003 2ef7 815c 2ef7 815c 7578  0UT..\...\ux
│ -0030: 0b00 0104 e803  04e8 0300 0030 0a50  .0.P
│ -0040: 4b01 021e 030a   0031 7068 4e12  K..1phN.
│ -0050: cd4a 7e02  0002  0003 0018   .J~.
│ +0030: 0b00 0104 e803  04e8 0300 0031 0a50  .1.P
│ +0040: 4b01 021e 030a   0031 7068 4e53  K..1phNS
│ +0050: fc51 6702  0002  0003 0018   .Qg.
│  0060:  0001  00a4 8100  0063 2f30  .c/0
│  0070: 5554 0500 032e f781 5c75 780b 0001 04e8  UT..\ux.
│  0080: 0300 0004 e803  504b 0506    PK..
│  0090: 0100 0100 4900  3f00     I...?.

Mike

Bug#923548: unblock: postfix/3.4.1-1

[Scott Kitterman]

On Wednesday, March 06, 2019 07:39:07 PM Jonathan Wiltshire wrote:
> Control: tag -1 moreinfo
> 
> On Fri, Mar 01, 2019 at 02:46:41PM -0500, Scott Kitterman wrote:
> > Given the outstanding track record this upstream has for delivering
> > mature,
> > well tested code I believe this change is appropriate for this stage of
> > the
> > release cycle given the benefits it will provide, but it is definitely not
> > minor, so I'd like release team feedback before uploading to unstable.
> 
> I agree. Please go ahead and remove moreinfo when it is ready to be
> unblocked.
> 
> Thanks.

Built on all release archs, so I think it's ready to be unblocked.  moreinfo 
tag removed.  Please:

unblock postfix/3.4.1-1

Scott K

Bug#922120: annoying messages from systemd.unit

[Daniel Baumann]

On 3/7/19 11:16 PM, Daniel Kahn Gillmor wrote:
> Weird!  This bug was reported against 3.2.0-1 in the first place, so i'm
> pretty confused :/

yes, that was totally my fault and I'm sorry for the confusion (wasn't
my intention).

I didn't double-checked the version I'm running when reporting the bug
and just naturally go with sid because for ~20 years I always run sid on
my notebook.. but for different reasons for the first time actually used
testing instead.

Regards,
Daniel

Bug#922120: annoying messages from systemd.unit

[Daniel Baumann]

On 3/7/19 11:16 PM, Daniel Kahn Gillmor wrote:
> Weird!  This bug was reported against 3.2.0-1 in the first place, so i'm
> pretty confused :/

yes, that was totally my fault and I'm sorry for the confusion (wasn't
my intention).

I didn't double-checked the version I'm running when reporting the bug
and just naturally go with sid because for ~20 years I always run sid on
my notebook.. but for different reasons for the first time actually used
testing instead.

Regards,
Daniel

Bug#923995: diffoscope: --exclude GLOB_PATTERN doesn't affect file lists

[Mike Hommey]

Package: diffoscope
Version: 113
Severity: normal

Take the following example:

$ mkdir a b
$ echo 0 > a/0
$ echo 0 > b/0
$ echo 1 > b/1

$ diffoscope a b --exclude-directory-metadata=recursive
--- a
+++ b
├── file list
│ @@ -1 +1,2 @@
│ -0
│ +0
│ +1

(BTW, note how weird this diff is)

First, it's worth noting that --new-file doesn't make a difference: the
contents of the new file are not displayed as a diff against an empty
file.

Now let's say I want to ignore `1` entirely. The logical way to do so
would be:

$ diffoscope a b --exclude-directory-metadata=recursive --new-file --exclude b/1
--- a
+++ b
├── file list
│ @@ -1 +1,2 @@
│ -0
│ +0
│ +1

but that doesn't yield the expected result.

If I do create an empty a/1 file, I do get what I'd expect without the
empty file existing.

Mike

Bug#923662: mark lua-say Multi-Arch: foreign

[Jason Pleau]

Hi

On 2019-03-03 7:35 a.m., Helmut Grohne wrote:
> Source: lua-say
> Version: 1.3-1-4
> Tags: patch
> User: debian-cr...@lists.debian.org
> Usertags: cross-satisfiability
> Control: affects -1 + src:prosody
> 
> prosody fails to cross build from source, because its transitive
> dependency on lua-say is unsatisfiable. It seems that marking lua-say
> Multi-Arch: foreign is part of the solution here. It is an
> architecture-independent package with no dependencies or maintainer
> scripts. That usually means that marking it Multi-Arch: foreign is safe.
> Please consider applying the attached patch.

The repo has been updated: https://salsa.debian.org/lua-team/lua-say

Do you think this warrants an unblock request? I can arrange for an
upload, but will request an unblock if this blocks another package from
working correctly.

Thanks.

> 
> Helmut
> 

-- 
Jason Pleau

Bug#919929: python-scipy: autopkgtest fails (Re: bug#919929)

[Drew Parsons]

On 2019-03-07 20:46, Paul Gevers wrote:


If you upload now, your package will not migrate to testing before the
full freeze becomes effective so it would need an unblock. If you want
to fix this issue with the three lines I saw in the bug report, you can
go ahead. However, it is probably worth waiting for a resolution of bug
915738 and combine it with that.



Alas, the deprecation patch (in python-scipy 1.1.0-3) doesn't actually 
prevent emission of the deprecation warnings, so they're still spamming 
the debci log.  On the bright side, s390x is now using gfortran-8 
successfully (#915738).


To remove the deprecation warnings we'd need to deal with them at the 
source. Upstream has patches

https://github.com/scipy/scipy/commit/614847c5fc8d5f8a618980df3c1b93540428ae46
https://github.com/scipy/scipy/commit/e0cfa29e2fbe86f994924c0c7514ff5bbfffd514
and for completeness
https://github.com/scipy/scipy/commit/87e48c3c54d7a85bc6628c88c1de98ac0469b6fa

The deprecation problem (matrix API) appears in many places, but the fix 
is straightfoward: replace np.matrix with matrix from from 
scipy.sparse.sputils


Can you authorise an unblock to apply these 3 upstream patches to 
python-scipy 1.1.0 ?
That won't necessarily fix the debci failure, but it will make it a lot 
easier to see what's actually failing.


Drew

Bug#923991: Avoid embedding a copy of dygraphs

[Daniel Kahn Gillmor]

Package: src:knot-resolver
Version: 3.2.1-2
Control: block -1 with 749603
Control: user p...@debian.org
Control: usertag + embed
Control: clone -1 -2 -3 -4
Control: retitle -1 knot-resolver: Avoid embedding a copy of dygraphs
Control: reassign -2 src:r-cran-dygraphs 1.1.1.6+dfsg-1
Control: retitle -2 r-cran-dygraphs: Avoid embedding a copy of dygraphs
Control: reassign -3 src:netdata 1.12.0-1
Control: retitle -3 netdata: Avoid embedding a copy of dygraphs
Control: reassign -4 src:tsung 1.7.0-3
Control: retitle -4 tsung: Avoid embedding a copy of dygraphs
Control: affects 749603 + src:knot-resolver src:tsung src:netdata 
src:r-cran-dygraphs

knot-resolver, tsung, r-cran-dygraphs, and netdata all embed a copy of
the dygraphs javascript library.  Some of them ship the library already
minified, others ship it un-minified.  several different versions are
shipped, and some of them do not appear to be well-maintained.  It would
be preferable for debian to ship a single well-maintained dygraph
package that these packages could all point to.

It would be great if the RFP for libjs-dygraphs were resolved!

   --dkg



signature.asc
Description: PGP signature

Bug#855811: release.debian.org: release.d.o WWW should explicitly recommend against uploading to sid during the freeze

[Sean Whitton]

Hello Paul,

On Thu 07 Mar 2019 at 09:37PM +01, Paul Gevers wrote:

> On Tue, 21 Feb 2017 15:04:39 -0700 Sean Whitton
>  wrote:
>> I'd like to suggest that this recommendation be stated explicitly on the
>> release team's website, to reduce the number of blocking uploads to
>> unstable made during the freeze.
>
> Is the current text good enough for this purpose?
> """
> We strongly prefer changes that can be done via unstable instead of
> testing-proposed-updates. If there are unrelated changes in unstable,
> you should consider reverting these instead of making an upload to
> testing-proposed-updates.
> """

No, I don't think so.  You have to think moderately hard to infer, "oh,
stop uploading to sid" from that text.  I would suggest appending
"I.e. only upload to sid changes for which you plan to request an unblock."

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#923990: Failure: TypeError: str() argument 2 must be str, not None

[Sandro Tosi]

Package: dh-python
Version: 3.20180927
Severity: critical

(severity it's because it breaks other packages)

i just uploaded python-dmidecode, and it fails on the buildds with:

I: dh_python2 fs:343: renaming dmidecodemod.so to 
dmidecodemod.aarch64-linux-gnu.so
Traceback (most recent call last):
  File "/usr/share/dh-python/dh_python2", line 545, in 
main()
  File "/usr/share/dh-python/dh_python2", line 430, in main
stats = Scanner(interpreter, package, private_dir, options).result
  File "/usr/share/dh-python/dhpython/fs.py", line 230, in __init__
ver = self.handle_ext(fpath)
  File "/usr/share/dh-python/dh_python2", line 57, in handle_ext
so_version = so2pyver(fpath)
  File "/usr/share/dh-python/dhpython/tools.py", line 139, in so2pyver
match = SHAREDLIB_RE.search(str(process.stdout.read(), encoding=encoding))
TypeError: str() argument 2 must be str, not None
make: *** [debian/rules:11: binary-arch] Error 1

logs at 
https://buildd.debian.org/status/fetch.php?pkg=python-dmidecode=arm64=3.12.2-8=1552005709=0
shows it's using version 3.20190307, which was just uploaded today.

could you have a look please?

thanks,
Sandro

-- System Information:
Debian Release: buster/sid
  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.14.0-3-amd64 (SMP w/8 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_WARN, TAINT_OOT_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

Versions of packages dh-python depends on:
ii  python33.7.1-3
ii  python3-distutils  3.7.1-1

dh-python recommends no packages.

Versions of packages dh-python suggests:
ii  dpkg-dev  1.19.0.4
ii  libdpkg-perl  1.19.0.4

-- no debconf information

Bug#923989: unblock: python-dmidecode/3.12.2-8

[Sandro Tosi]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Please unblock package python-dmidecode

This upload fix the poor handling of the dir-to-symlink transition for the doc
directories

unblock python-dmidecode/3.12.2-8

-- System Information:
Debian Release: buster/sid
  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.14.0-3-amd64 (SMP w/8 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_WARN, TAINT_OOT_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
diff -Nru python-dmidecode-3.12.2/debian/changelog 
python-dmidecode-3.12.2/debian/changelog
--- python-dmidecode-3.12.2/debian/changelog2019-01-28 23:09:03.0 
-0500
+++ python-dmidecode-3.12.2/debian/changelog2019-03-07 17:51:40.0 
-0500
@@ -1,3 +1,12 @@
+python-dmidecode (3.12.2-8) unstable; urgency=medium
+
+  * debian/rules
+- remove doc/ directories, to actually use dir_to_symlink; Closes: #919442
+  * debian/*.maintscript
+- use prior-of tag at the end of the command-line
+
+ -- Sandro Tosi   Thu, 07 Mar 2019 17:51:40 -0500
+
 python-dmidecode (3.12.2-7) unstable; urgency=medium
 
   * debian/*.maintscript
diff -Nru python-dmidecode-3.12.2/debian/python3-dmidecode-dbg.maintscript 
python-dmidecode-3.12.2/debian/python3-dmidecode-dbg.maintscript
--- python-dmidecode-3.12.2/debian/python3-dmidecode-dbg.maintscript
2019-01-28 23:09:03.0 -0500
+++ python-dmidecode-3.12.2/debian/python3-dmidecode-dbg.maintscript
2019-03-07 17:51:40.0 -0500
@@ -1 +1 @@
-dir_to_symlink /usr/share/doc/python3-dmidecode-dbg python3-dmidecode
+dir_to_symlink /usr/share/doc/python3-dmidecode-dbg python3-dmidecode 3.12.2-8~
diff -Nru python-dmidecode-3.12.2/debian/python-dmidecode-dbg.maintscript 
python-dmidecode-3.12.2/debian/python-dmidecode-dbg.maintscript
--- python-dmidecode-3.12.2/debian/python-dmidecode-dbg.maintscript 
2019-01-28 23:09:03.0 -0500
+++ python-dmidecode-3.12.2/debian/python-dmidecode-dbg.maintscript 
2019-03-07 17:51:40.0 -0500
@@ -1 +1 @@
-dir_to_symlink /usr/share/doc/python-dmidecode-dbg python-dmidecode
+dir_to_symlink /usr/share/doc/python-dmidecode-dbg python-dmidecode 3.12.2-8~
diff -Nru python-dmidecode-3.12.2/debian/rules 
python-dmidecode-3.12.2/debian/rules
--- python-dmidecode-3.12.2/debian/rules2019-01-28 23:09:03.0 
-0500
+++ python-dmidecode-3.12.2/debian/rules2019-03-07 17:51:40.0 
-0500
@@ -38,9 +38,12 @@
 endif
 
 override_dh_installdocs:
-   dh_installdocs -A README doc/AUTHORS doc/changelog doc/README.types 
doc/AUTHORS.upstream doc/README.upstream
dh_installdocs -p$(P2)-dbg --link-doc=$(P2)
dh_installdocs -p$(P3)-dbg --link-doc=$(P3)
+   dh_installdocs -p$(P2) README doc/AUTHORS doc/changelog 
doc/README.types doc/AUTHORS.upstream doc/README.upstream
+   dh_installdocs -p$(P3) README doc/AUTHORS doc/changelog 
doc/README.types doc/AUTHORS.upstream doc/README.upstream
+   mkdir -p $(CURDIR)/debian/$(P2)-data/usr/share/doc/
+   cp -r $(CURDIR)/debian/$(P2)/usr/share/doc/$(P2) 
$(CURDIR)/debian/$(P2)-data/usr/share/doc/$(P2)-data
 
 override_dh_strip:
 ifeq (,$(filter nostrip,$(DEB_BUILD_OPTIONS)))

Bug#636339: Missing directory structure in /var/run

[Pierre Ynard]

retitle 636339 Please provide mechanism to create directory structure in 
/var/run tmpfs
severity 636339 wishlist
thanks

Hello,

> I don't use init scripts, and even if i did, the runit FastCGI
> services might still get started before my init script.

I don't know how runit services work, but if this is supported, the best
in your case might be to modify your FastCGI service to let it create
its socket directory right when it's going to be needed. Otherwise,
I surmise you can create another service doing just that with proper
dependencies to ensure they're run in the right order.

> So I need a simple way to have a persistent directory tree under
> /var/run (I guess we can agree that writing new rcS.d scripts isn't an
> option).

Nothing prevents you from creating your own new rcS.d script or editing
an existing one, like /etc/init.d/mountkernfs.sh, to create your
directory structure right after it mounts /run.

I agree that a general-purpose tmpfiles.d or equivalent could be a good
thing to have. However, initscripts can already be edited to add in such
small setups, any external tool providing such a configurable feature
can already plug itself into the boot sequence, and tmpfs /run and
/var/run are long standard now, so I'm downgrading this to wishlist.

Michael, how hard does systemd-tmpfiles depend on systemd, and what
would you think of splitting it into a separate binary package?

-- 
Pierre Ynard

Bug#923367: [pkg-apparmor] Bug#923367: AppArmor: Profile for journald

[Seth Arnold]

On Thu, Mar 07, 2019 at 09:41:40PM +0100, intrigeri wrote:
> I would suggest trying to use the AppArmorProfile= directive in the
> journald unit. I suspect it'll fail because some other stuff (normally
> set up by apparmor.service) is not ready yet at the time journald
> starts, but it'll be interesting to know what that stuff is and

You could try amending the systemd unit file in question with:

ExecStartPre=apparmor_parser --replace 
/etc/apparmor.d/

Perhaps in case the profile may not exist and you still want the journal
service to start:

ExecStartPre=-apparmor_parser --replace ...

When the full apparmor.service unit runs, it'll try to load that profile
from the binary cache, and the kernel will notice it's unchanged and skip
further processing. So this shouldn't affect boot speed all that much.

Of course if the journal service is started before the necessary
filesystems are mounted, that's something else.

Thanks


signature.asc
Description: PGP signature

Bug#923988: /boot/vmlinuz-4.19.0-2-arm64: dmidecode causes kernel panic (puma-rk3399)

[Vagrant Cascadian]

Package: src:linux
Version: 4.19.16-1
Severity: normal
File: /boot/vmlinuz-4.19.0-2-arm64
X-Debbugs-Cc: klaus.go...@theobroma-systems.com

When running dmidecode as root on puma-rk3399, it consistantly causes a
kernel panic.

Other similar rockchip rk3399 boards do not seem to have this
problem. All older (maybe 4.16-4.18) and newer (v4.20) kernels I've
tried seem to be affected.

live well,
  vagrant

Kernel panic:

[  209.234792] SError Interrupt on CPU4, code 0xbf00 -- SError
[  209.234796] CPU: 4 PID: 829 Comm: dmidecode Not tainted 4.19.0-2-arm64 #1 
Debian 4.19.16-1
[  209.234798] Hardware name: Theobroma Systems RK3399-Q7 SoM (DT)
[  209.234801] pstate: 2000 (nzCv daif -PAN -UAO)
[  209.234802] pc : afeff28c
[  209.234804] lr : d7f49a0c
[  209.234806] sp : d355d260
[  209.234808] x29: d355d260 x28: 
[  209.234814] x27: 0001 x26: afe6c000
[  209.234819] x25: 0003 x24: 000f
[  209.234824] x23:  x22: 0001
[  209.234829] x21: d7f63000 x20: ece51490
[  209.234834] x19: d7f4c3b8 x18: 
[  209.234838] x17: afeff190 x16: d7f63e50
[  209.234843] x15: 0002 x14: 
[  209.234848] x13:  x12: 
[  209.234852] x11:  x10: 
[  209.234857] x9 :  x8 : 00de
[  209.234861] x7 :  x6 : 
[  209.234866] x5 : ece61490 x4 : afe7c000
[  209.234871] x3 : ece51490 x2 : 0001
[  209.234875] x1 : afe6c000 x0 : ece51490
[  209.234881] Kernel panic - not syncing: Asynchronous SError Interrupt
[  209.234884] CPU: 4 PID: 829 Comm: dmidecode Not tainted 4.19.0-2-arm64 #1 
Debian 4.19.16-1
[  209.234886] Hardware name: Theobroma Systems RK3399-Q7 SoM (DT)
[  209.234888] Call trace:
[  209.234890]  dump_backtrace+0x0/0x180
[  209.234892]  show_stack+0x24/0x30
[  209.234894]  dump_stack+0x90/0xb4
[  209.234895]  panic+0x128/0x290
[  209.234897]  nmi_panic+0x7c/0x80
[  209.234899]  arm64_serror_panic+0x80/0x8c
[  209.234901]  is_valid_bugaddr+0x0/0x1c
[  209.234903]  el0_error_naked+0x10/0x18
[  209.234935] SMP: stopping secondary CPUs
[  209.234937] Kernel Offset: disabled
[  209.234939] CPU features: 0x0,2180600c
[  209.234941] Memory Limit: none
[  209.435889] ---[ end Kernel panic - not syncing: Asynchronous SError 
Interrupt ]---
[  214.345190] WARNING: CPU: 4 PID: 829 at kernel/sched/core.c:1162 
set_task_cpu+0x1b0/0x1c0
[  214.345193] Modules linked in: cpufreq_conservative cpufreq_powersave 
cpufreq_userspace cpufreq_ondemand binfmt_misc aes_ce_blk crypto_simd cryptd 
aes_ce_cipher sg ghash_ce gf128mul sha2_ce sha256_arm64 sha1_ce rockchipdrm 
dw_hdmi leds_gpio analogix_dp drm_kms_helper dw_wdt drm nvmem_rockchip_efuse 
pwm_rockchip rockchip_io_domain rockchip_thermal pl330 cpufreq_dt ip_tables 
x_tables autofs4 ext4 crc16 mbcache jbd2 crc32c_generic fscrypto ecb aes_arm64 
sd_mod uas usb_storage scsi_mod xhci_plat_hcd xhci_hcd dwc3 rtc_rk808 
rk808_regulator micrel clk_rk808 udc_core ulpi rk808 fan53555 ohci_platform 
dwc3_of_simple sdhci_of_arasan ehci_platform dwmac_rk sdhci_pltfm 
stmmac_platform ohci_hcd dw_mmc_rockchip stmmac cqhci dw_mmc_pltfm ehci_hcd 
phy_rockchip_pcie phy_rockchip_emmc of_mdio phy_rockchip_inno_usb2
[  214.345297]  usbcore phy_rockchip_typec fixed_phy dw_mmc sdhci libphy 
i2c_rk3x usb_common fixed
[  214.345313] CPU: 4 PID: 829 Comm: dmidecode Not tainted 4.19.0-2-arm64 #1 
Debian 4.19.16-1
[  214.345315] Hardware name: Theobroma Systems RK3399-Q7 SoM (DT)
[  214.345318] pstate: 2085 (nzCv daIf -PAN -UAO)
[  214.345320] pc : set_task_cpu+0x1b0/0x1c0
[  214.345322] lr : try_to_wake_up+0x1a0/0x4b0
[  214.345324] sp : 08023b60
[  214.345325] x29: 08023b60 x28: 80007d81c400
[  214.345330] x27: 80007d807000 x26: 0001
[  214.345335] x25: 09089738 x24: 08d2a840
[  214.345340] x23: 0080 x22: 0004
[  214.345344] x21: 09089708 x20: 0001
[  214.345349] x19: 80007d0fe3c0 x18: 0010
[  214.345353] x17:  x16: 
[  214.345358] x15:  x14: 0720072007200720
[  214.345363] x13: 0720072007200720 x12: 0720072007200720
[  214.345367] x11: 0720072007200720 x10: 0040
[  214.345372] x9 : 090a6c40 x8 : 800077c034a0
[  214.345376] x7 : 80007ff81840 x6 : 11adb43d
[  214.345381] x5 : 00ff x4 : 0015
[  214.345385] x3 : 02c9 x2 : 0001
[  214.345390] x1 : 09089f88 x0 : 0008
[  214.345395] Call trace:
[  214.345397]  set_task_cpu+0x1b0/0x1c0
[  214.345399]  try_to_wake_up+0x1a0/0x4b0
[  214.345401]  wake_up_process+0x28/0x38
[  214.345402]  insert_work+0xa8/0xc8
[  214.345404]  

Bug#923367: AppArmor: Profile for journald

[Jörg Sommer]

intrigeri hat am Do 07. Mär, 21:41 (+0100) geschrieben:
> Jörg Sommer:
> > But journald starts before the AppArmor profiles get loaded.
> 
> I would suggest trying to use the AppArmorProfile= directive in the
> journald unit. I suspect it'll fail because some other stuff (normally
> set up by apparmor.service) is not ready yet at the time journald
> starts, but it'll be interesting to know what that stuff is and
> possibly we can set it up earlier.

These are the profiles itself. They get loaded by apparmor.service.

> E.g. some of the work currently
> done by apparmor.service could be moved to another service, that
> starts earlier in the boot process.

That's difficult, because apparmor.service depends on local-fs.target and
journald get started very early before any filesystem is available.

The other difficult process would be systemd itself. You can only apply an
apparmor profile by restarting the process.

Do you know if Fedora or Suse have done something similar?

Regards Jörg

-- 
“It's been said you aren't a real UNIX system administrator until you've
edited a sendmail.cf file. It's also been said that you are crazy if you
attempted to do so twice.”


signature.asc
Description: PGP signature

Bug#923476: webkit2gtk: FTBFS for unknown reasons (maybe Makefile bug)

[Santiago Vila]

Hi. I built version 2.23.92-1 in experimental in four different
autobuilders and it worked ok the four times:

https://people.debian.org/~sanvila/build-logs/webkit2gtk/

So even if we don't really understand at this moment the reason it
failed before, I would consider ok to do an upload for unstable
(having an equivalent fix) and close the bug.

Thanks.

Bug#862073: Uploading buildinfo files to buildinfo.debian.net

[Samuel Thibault]

Control: clone -1 -2
Control: reassign -2 sbuild
Control: retitle -2 Should also send the buildinfo in the build mail

Hello,

Mattia Rizzolo, le sam. 16 févr. 2019 19:02:05 +0100, a ecrit:
> On Sat, Feb 16, 2019 at 08:48:27AM -0800, Vagrant Cascadian wrote:
> > On 2019-02-16, Mattia Rizzolo wrote:
> > > Do you think you could provide more info about the kbsd and hurd
> > > buildinfo that are unsigned?
> > 
> > Looks like kfreebsd were fixed at some point.
> > 
> > I'm not sure what more information is needed ... the .buildinfo files
> > available on coccia are unsigned. The only current ones still failing
> > are hurd-i386 or the infrequent developer uploads, for example:
> 
> ACK, I've asked youpi to have a look at his signing script (remember
> that kbsd and hurd uploads are all manually signed by a DD).
> Hopefully this will greatly reduce the number of unsigned buildinfo :)
> 
> > I've privately emailed some of the individual developer uploads when
> > I've noticed, but haven't done a systematic look. Maybe it's time to do 
> > that.
> 
> Maybe after youpi confirms he improved his script.

I had a look, and as mentioned on IRC the .build part is not in the mail
sent by sbuild. kbsd builds are signed by hand with debsign so that
doesn't matter, but I use a script in my mailer to sign easily progressively,
so I need the .buildinfo in the mail send by sbuild.

Samuel

Bug#923986: ruby-pygments.rb: FTBFS randomly (failing tests)

[Santiago Vila]

Package: src:ruby-pygments.rb
Version: 1.2.0-2
Severity: serious
Tags: ftbfs

Dear maintainer:

I tried to build this package in buster but it failed:


[...]
 debian/rules build-indep
dh build-indep --buildsystem=ruby --with ruby
   dh_update_autotools_config -i -O--buildsystem=ruby
   dh_autoreconf -i -O--buildsystem=ruby
   dh_auto_configure -i -O--buildsystem=ruby
dh_ruby --configure
   debian/rules override_dh_auto_build
make[1]: Entering directory '/<>'
dh_auto_build
dh_ruby --build
   dh_ruby --build
# build documention
rdoc lib
Parsing sources...
 20% [ 1/ 5]  lib/pygments.rb
 40% [ 2/ 5]  lib/pygments/lexer.rb
 60% [ 3/ 5]  lib/pygments/mentos.py
 80% [ 4/ 5]  lib/pygments/popen.rb
100% [ 5/ 5]  lib/pygments/version.rb

Generating Darkfish format into /<>/doc...


  Files:   5

  Classes: 3 (2 undocumented)
  Modules: 1 (0 undocumented)
  Constants:   1 (1 undocumented)
  Attributes:  0 (0 undocumented)
  Methods:27 (5 undocumented)

  Total:  32 (8 undocumented)
   75.00% documented

  Elapsed: 0.5s

make[1]: Leaving directory '/<>'
   dh_auto_test -i -O--buildsystem=ruby
dh_ruby --test
   create-stamp debian/debhelper-build-stamp
 fakeroot debian/rules binary-indep
dh binary-indep --buildsystem=ruby --with ruby
   dh_testroot -i -O--buildsystem=ruby
   dh_prep -i -O--buildsystem=ruby
   debian/rules override_dh_auto_install
make[1]: Entering directory '/<>'
dh_auto_install
dh_ruby --install /<>/debian/ruby-pygments.rb
   dh_ruby --install

┌──────────────────────────────────────────────────────────────────────────────┐
│ Install files   
 │
└──────────────────────────────────────────────────────────────────────────────┘

install -d /<>/debian/ruby-pygments.rb/usr/lib/ruby/vendor_ruby
install -D -m644 /<>/lib/pygments.rb 
/<>/debian/ruby-pygments.rb/usr/lib/ruby/vendor_ruby/pygments.rb
install -D -m644 /<>/lib/pygments/version.rb 
/<>/debian/ruby-pygments.rb/usr/lib/ruby/vendor_ruby/pygments/version.rb
install -D -m644 /<>/lib/pygments/mentos.py 
/<>/debian/ruby-pygments.rb/usr/lib/ruby/vendor_ruby/pygments/mentos.py
install -D -m644 /<>/lib/pygments/lexer.rb 
/<>/debian/ruby-pygments.rb/usr/lib/ruby/vendor_ruby/pygments/lexer.rb
install -D -m644 /<>/lib/pygments/popen.rb 
/<>/debian/ruby-pygments.rb/usr/lib/ruby/vendor_ruby/pygments/popen.rb
dh_installchangelogs -pruby-pygments.rb /<>/CHANGELOG.md upstream

┌──────────────────────────────────────────────────────────────────────────────┐
│ Install Rubygems integration metadata   
 │
└──────────────────────────────────────────────────────────────────────────────┘

generating gemspec at 
/<>/debian/ruby-pygments.rb/usr/share/rubygems-integration/all/specifications/pygments.rb-1.2.0.gemspec
/usr/bin/ruby2.5 /usr/bin/gem2deb-test-runner

┌──────────────────────────────────────────────────────────────────────────────┐
│ Checking Rubygems dependency resolution on ruby2.5  
 │
└──────────────────────────────────────────────────────────────────────────────┘

GEM_PATH=debian/ruby-pygments.rb/usr/share/rubygems-integration/all:/var/lib/gems/2.5.0:/usr/lib/x86_64-linux-gnu/rubygems-integration/2.5.0:/usr/share/rubygems-integration/2.5.0:/usr/share/rubygems-integration/all
 ruby2.5 -e gem\ \"pygments.rb\"

┌──────────────────────────────────────────────────────────────────────────────┐
│ Run tests for ruby2.5 from debian/ruby-tests.rb 
 │

Bug#740894: closed by Nico Schlömer ()

[Francesco Poli]

Control: fixed -1 gmsh/4.1.3+ds1-1


On Thu, 07 Mar 2019 11:10:12 +0100 Nico Schlömer wrote:

> The tetgen dependency is now removed.

Hey, this is great news!
Thanks a lot to Nico and Kurt for addressing this issue.  :-)

I am not sure which is the first version of the package with no
dependency on libtet: I'll assume it is 4.1.3+ds1-1 ...

Bye and thanks again.

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


pgpVu9GO8n_N0.pgp
Description: PGP signature

Bug#923985: gdb: gcore man page doesn't document -a

[Mike Hommey]

Package: gdb
Version: 8.2.1-2
Severity: normal

```
$ gcore --help
usage:  gcore [-a] [-o filename] pid

$ man gcore | head -9
gcore(1)GNU Tools   
 gcore(1)

NAME
   gcore - Generate a core file for a running process

SYNOPSIS
   gcore [-o filename] pid

DESCRIPTION
```

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

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

Versions of packages gdb depends on:
ii  libbabeltrace1  1.5.6-2
ii  libc6   2.28-3
ii  libexpat1   2.2.6-1
ii  libipt2 2.0-2
ii  liblzma55.2.2-1.3
ii  libncursesw66.1+20181013-1
ii  libpython3.73.7.2~rc1-1
ii  libreadline77.0-5
ii  libtinfo6   6.1+20181013-1
ii  zlib1g  1:1.2.11.dfsg-1

Versions of packages gdb recommends:
ii  libc6-dbg [libc-dbg]  2.28-3

Versions of packages gdb suggests:
pn  gdb-doc
ii  gdbserver  8.2-1

-- no debconf information

Bug#923984: dnssec-keymgr immediately inactivates/deletes old keys

[Bernhard Schmidt]

Package: bind9utils
Version: 1:9.11.2+dfsg-1
Severity: important
Tags: upstream

This is a copy of my upstream bugreport at
https://gitlab.isc.org/isc-projects/bind9/issues/117 in order to get the fix
into Buster

When you run dnssec-keymgr with keys that are older (Activation Time further in
the past) than the configured (or default) roll-period, the keys are set to be
inactive/deleted at a date way in the past. You can easily test this with the
default policy by creating a ZSK that has been activated 2 years in the past

---
# dnssec-keygen -f KSK -A -2y -a RSASHA256 -b 2048 example.com
Generating key pair..+++ 
.+++ 
Kexample.com.+008+37477

# dnssec-keygen -A -2y -a RSASHA256 -b 2048 example.com
Generating key pair+++ 
+++ 
Kexample.com.+008+19905

# dnssec-coverage 
WARNING: Maximum TTL value was not specified.  Using 1 week
 (604800 seconds); re-run with the -m option to get more
 accurate results.
PHASE 1--Loading keys to check for internal timing problems

PHASE 2--Scanning future key events for coverage failures
Checking scheduled KSK events for zone example.com, algorithm RSASHA256...
  Sun Feb 28 16:02:23 UTC 2016:
Publish: example.com/RSASHA256/37477 (KSK)
Activate: example.com/RSASHA256/37477 (KSK)

No errors found

Checking scheduled ZSK events for zone example.com, algorithm RSASHA256...
  Sun Feb 28 16:02:25 UTC 2016:
Publish: example.com/RSASHA256/19905 (ZSK)
Activate: example.com/RSASHA256/19905 (ZSK)

No errors found
---
; This is a zone-signing key, keyid 19905, for example.com.
; Created: 20180227160225 (Tue Feb 27 17:02:25 2018)
; Publish: 20160228160225 (Sun Feb 28 17:02:25 2016)
; Activate: 20160228160225 (Sun Feb 28 17:02:25 2016)

Now running dnssec-keymgr sets the key to Inactivate at Publish+1y (which is 1
year in the past) and delete a month later. Additionally there the generation
of the NEW ZSK fails with a Python error, which leaves the zone without any
active ZSK

---
# dnssec-keymgr 
# /usr/sbin/dnssec-settime -K . -I 20170227160225 -D 20170329160225 
Kexample.com.+008+19905
# /usr/sbin/dnssec-keygen -q -K . -S Kexample.com.+008+19905 -L 3600 -i 2592000
Unable to apply policy: example.com/RSASHA256: Can't convert 'bytes' object to 
str implicitly
---

; This is a zone-signing key, keyid 19905, for example.com.
; Created: 20180227160225 (Tue Feb 27 17:02:25 2018)
; Publish: 20160228160225 (Sun Feb 28 17:02:25 2016)
; Activate: 20160228160225 (Sun Feb 28 17:02:25 2016)
; Inactive: 20170227160225 (Mon Feb 27 17:02:25 2017)
; Delete: 20170329160225 (Wed Mar 29 18:02:25 2017) 

The next run of dnssec-keymgr generates a new ZSK.

In the end this creates a completely messed up ZSK rollover where the DNSKEY is
pulled immediately without a new ZSK being present.

Bug#923983: dahdi-dkms: prerm fails if module was not on the system at remove time

[Tzafrir Cohen]

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


dahdi-dkms includes packaging from an patch from Ubuntu. It seems that
the Debian packaging has since become more robust.

The package has included its own postinst and prerm scripts and did not
use the ones provided by dh_dkms.

Specifically, if the package does not install the module at postinst
(e.g. because it is a container running on a different kernel) or if
it was manually removed before the package was removed, the prerm
script doesn't check. It tries to remove, fails, and gives an error.

This has caused the failure of puiparts (but only after a newer version
was uploaded:

https://piuparts.debian.org/sid/fail/dahdi-linux_1:2.11.1.0.20170917~dfsg-6.log

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

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

Versions of packages dahdi-dkms depends on:
ii  dkms   2.6.1-4
ii  dpkg-dev   1.19.5
ii  gawk   1:4.2.1+dfsg-1
ii  gcc4:8.2.0-2
ii  libc6-dev  2.28-7
ii  make   4.2.1-1.2
ii  wget   1.20.1-1

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

dahdi-dkms suggests no packages.

-- no debconf information

Bug#923889: google-compute-image-packages - DoS via serial console write

[Ross Vandegrift]

On Wed, Mar 06, 2019 at 07:49:38PM +0100, Bastian Blank wrote:
> This package instructs journald to duplicate everything sent to the
> journal to the serial console.  The serial console is a pretty rate
> limited log output device and blocking there will make all software with
> any log output block.

This doesn't seem to affect all software - I tried to reproduce with
logger, but it doesn't block.  Maybe this only affects some logging
transports?

I agree it's a problematic default - GCE serial console data is
currently stored unencrypted.  That could be an unpleasent surprise.

Ross

Bug#922120: annoying messages from systemd.unit

[Daniel Kahn Gillmor]

On Thu 2019-03-07 21:37:30 +0100, Daniel Baumann wrote:
> i've verified this with another vanilla system that wasn't upgraded and
> i can reproduce it there: 3.2.0-1 fixed it.

Weird!  This bug was reported against 3.2.0-1 in the first place, so i'm
pretty confused :/  But at least it's gone away :)

Thanks for double-checking and for following up here, Daniel.

Regards,

--dkg


signature.asc
Description: PGP signature

Bug#581907: sysv-rc: performance regression with CONCURRENCY=makefile

[Pierre Ynard]

Hello,

> I notice Xorg starts after 27 seconds with parallel booting, and 40
> seconds with sequencial boot.  This make me suspect the regression is
> really an artifact of how you measure the boot duration, and not a
> result of the real boot speed slowdown.

Reading thid thread, I would be enclined to believe that too.

> Kel is working on a new bootchart package, which make it a bit easier
> to measure it accurately.  With this, we look for when the CPU settles
> down after boot.

Did that give anything?

This investigation into a possible regression hasn't been conclusive and
isn't likely to get anywhere further now, but I wanted to check with
you. Shall we close this?

-- 
Pierre Ynard

Bug#923982: RM: gcc-7, gcc-7-cross, gcc-7-cross-ports -- old version not used anymore

[Matthias Klose]

Package: ftp.debian.org

Please remove the gcc-7, gcc-7-cross, gcc-7-cross-ports packages, superseded by
GCC 8.

Bug#921232: mono: Internal compiler error building libsbml on s390x

[Jo Shields]

Neale, can you try building libsbml (http://sbml.org/Software/libSBML)
on s390x against a Mono revision you trust? It could be something bad in
out 5.18 s390x backports, or it could be unrelated to that.

On 07/03/2019 16:16, Petter Reinholdtsen wrote:
> [Adrian Bunk]
>> We dn't have any kind of CI coverage on s390x,
>> it is therefore not obvious whether this is
>> a problem confined to one package or whether
>> Mono is completely broken on s390x.
> I guess that is just another way to say that no-one know if anyone is using
> mono on s390x?  Perhaps it is best to drop mono from s390x until it can
> be confimed to be working there, instead of risking mono to be dropped from
> buster on all the working architectures?

Bug#923926: Acknowledgement (proftpd-basic: proftpd 1.3.5b has memory leaks, allows Denial-Of-Service attack)

[esbeeb]

Great, OpenMediaVault has the "unattended-upgrades" package installed by 
default, so your security update should apply itself automatically, once it's 
published.
I'll try my OpenMediaVault proftpd upload again once the security fix arrives, 
and watch the RAM usage, with htop.  I'll let you know if any memory leak 
remains.  If any memory leak remains (albeit a slower leak), then this DOS 
still exisits...

-- 
Cheers,
Subharo Bhikkhu
https://bhikkhu.ca



Mar 7, 2019, 6:30 PM by ow...@bugs.debian.org:

> Thank you for filing a new Bug report with Debian.
>
> You can follow progress on this Bug here: 923926: > 
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=923926 
> > .
>
> This is an automatically generated reply to let you know your message
> has been received.
>
> Your message is being forwarded to the package maintainers and other
> interested parties for their attention; they will reply in due course.
>
> As you requested using X-Debbugs-CC, your message was also forwarded to
>  > esb...@tuta.io > , Debian Security Team <> 
> t...@security.debian.org > >
> (after having been given a Bug report number, if it did not have one).
>
> Your message has been sent to the package maintainer(s):
>  ProFTPD Maintainance Team <> pkg-proftpd-maintain...@alioth-lists.debian.net 
> > >
>
> If you wish to submit further information on this problem, please
> send it to > 923...@bugs.debian.org > .
>
> Please do not send mail to > ow...@bugs.debian.org 
> >  unless you wish
> to report a problem with the Bug-tracking system.
>
> -- 
> 923926: > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=923926 
> 
> Debian Bug Tracking System
> Contact > ow...@bugs.debian.org >  with problems
>

Bug#923972: openvpn: OpenVPN 2.4.7 incompatible with OpenSSL 1.1.1a due to TLS 1.3

[Matt Horan]

On Thu, Mar 07, 2019 at 09:35:59PM +0100, Bernhard Schmidt wrote:
> I cannot really reproduce this. OpenVPN 2.4.7 in testing successfully
> connects (in tls-client mode) to an OpenVPN 2.4.0 on Stretch.
> 
> Thu Mar  7 21:28:49 2019 Control Channel: TLSv1.2, cipher TLSv1.2
> ECDHE-RSA-AES256-GCM-SHA384, 2048 bit RSA
> 
> Could it be possible that your server is quite old?
> 
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=912650 suggests there
> might be an issue connecting to an OpenVPN version that only does
> TLSv1.0 by default.
> 
> > A workaround is to add "tls-version-max 1.2" to the OpenVPN config file.
> 
> If you use that workaround, what TLS version is negotiated?

Hi Bernhard,

You are absolutely correct. I had thought that the "tls-version-max 1.2"
was making it into the config file (thus resolving my issue), but it
turns out I was mistaken.

The connection is indeed being made with TLS 1.3, and it works just
fine. There seems to be a problem with the tool I use to connect, and
when executing it a different way (the way I thought was injecting the
tls-max-version), all works fine.

I'm working with the author of the tool to figure out what's going on
there, but I do believe the Debian packages are just fine.

Thanks,
Matt

Bug#921232: mono: Internal compiler error building libsbml on s390x

[Petter Reinholdtsen]

[Adrian Bunk]
> We dn't have any kind of CI coverage on s390x,
> it is therefore not obvious whether this is
> a problem confined to one package or whether
> Mono is completely broken on s390x.

I guess that is just another way to say that no-one know if anyone is using
mono on s390x?  Perhaps it is best to drop mono from s390x until it can
be confimed to be working there, instead of risking mono to be dropped from
buster on all the working architectures?
-- 
Happy hacking
Petter Reinholdtsen

Bug#923981: dansguardian: Add support for clamav 0.101.1

[Sebastian Andrzej Siewior]

Package: dansguardian
Version: 2.10.1.1-5.1
Severity: important
Tags: patch

Please add support for clamav 0.101.1. The attached patch adds this and
has been lightly tested.

Sebastian
#! /bin/sh /usr/share/dpatch/dpatch-run
## 90_clamav111_support.dpatch by Sebastian A. Siewior
##
## All lines beginning with `## DP:' are a description of the patch.
## DP: Adds support for clamav 0.101.1

@DPATCH@
diff --git a/src/contentscanners/clamav.cpp b/src/contentscanners/clamav.cpp
index cb5e5be1b3fc..7af3c9383e60 100644
--- a/src/contentscanners/clamav.cpp
+++ b/src/contentscanners/clamav.cpp
@@ -172,7 +172,13 @@ int clamavinstance::scanMemory(HTTPHeader * requestheader, 
HTTPHeader * docheade
}
 
 #ifdef CL_INIT_DEFAULT
-   rc = cl_scandesc(fd, , NULL, engine, CL_SCAN_STDOPT);
+   struct cl_scan_options cl_options;
+
+   memset(_options, 0, sizeof(struct cl_scan_options));
+   cl_options.general = CL_SCAN_GENERAL_ALLMATCHES;
+   cl_options.parse = ~0;
+
+   rc = cl_scandesc(fd, NULL, , NULL, engine, _options);
 #else
rc = cl_scandesc(fd, , NULL, engine, , CL_SCAN_STDOPT);
 #endif
@@ -201,7 +207,13 @@ int clamavinstance::scanFile(HTTPHeader * requestheader, 
HTTPHeader * docheader,
lastmessage = lastvirusname = "";
const char *vn = NULL;
 #ifdef CL_INIT_DEFAULT
-   int rc = cl_scanfile(filename, , NULL, engine, CL_SCAN_STDOPT );
+   struct cl_scan_options cl_options;
+
+   memset(_options, 0, sizeof(struct cl_scan_options));
+   cl_options.general = CL_SCAN_GENERAL_ALLMATCHES;
+   cl_options.parse = ~0;
+
+   int rc = cl_scanfile(filename, , NULL, engine, _options);
 #else
int rc = cl_scanfile(filename, , NULL, engine, , 
CL_SCAN_STDOPT );
 #endif
-- 
2.20.1

Bug#923964: systemd-sysv: shutdown should accept a date

[Barak A. Pearlmutter]

Will do.

Bug#923980: claws-mail-gdata-plugin: gdata plugin crashes after update to 3.17.3-1

[Christian Beier]

Package: claws-mail-gdata-plugin
Version: 3.17.3-1
Severity: normal

Dear Maintainer,

I recently upgraded from stretch to buster, now claws-mail with gdata plugin
enabled segfaults.

Runs fine without gdata plugin enabled.

Also runs fine with `LANG=C claws-mail`

It seems the locale makes a difference, please see attached backtrace for the
default de_DE.UTF-8:

```

Thread 1 "claws-mail" received signal SIGSEGV, Segmentation fault.
__strlen_sse2 () at ../sysdeps/x86_64/multiarch/../strlen.S:120
120 ../sysdeps/x86_64/multiarch/../strlen.S: Datei oder Verzeichnis nicht
gefunden.
(gdb) bt
#0  0x76019436 in __strlen_sse2 () at
../sysdeps/x86_64/multiarch/../strlen.S:120
#1  0x75fd2bef in _IO_vfprintf_internal (s=s@entry=0x7fffb9f0,
format=format@entry=0x7133450f "GData-Plugin: Erneuern der Autorisierung
erfolgreich: %s\n", ap=ap@entry=0x7fffbbb8)
at vfprintf.c:1638
#2  0x76089549 in ___vsnprintf_chk
(s=0x7fffbbdb "GData-Plugin: Erneuern der Autorisierung erfolgreich: ",
maxlen=, flags=1, slen=, format=0x7133450f
"GData-Plugin: Erneuern der Autorisierung erfolgreich: %s\n",
args=0x7fffbbb8) at vsnprintf_chk.c:63
#3  0x005fde64 in log_message ()
#4  0x701b6025 in  () at /usr/lib/x86_64-linux-gnu/claws-
mail/plugins/gdata.so
#5  0x76d4a719 in  () at /usr/lib/x86_64-linux-gnu/libgio-2.0.so.0
#6  0x76d4a759 in  () at /usr/lib/x86_64-linux-gnu/libgio-2.0.so.0
#7  0x76b5cdd8 in g_main_context_dispatch () at /usr/lib/x86_64-linux-
gnu/libglib-2.0.so.0
#8  0x76b5d1c8 in  () at /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
#9  0x76b5d4c2 in g_main_loop_run () at /usr/lib/x86_64-linux-
gnu/libglib-2.0.so.0
#10 0x77c798e7 in gtk_main () at /usr/lib/x86_64-linux-
gnu/libgtk-x11-2.0.so.0
#11 0x00449ccf in main ()

```




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

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

Versions of packages claws-mail-gdata-plugin depends on:
ii  claws-mail   3.17.3-1
ii  libatk1.0-0  2.30.0-2
ii  libc62.28-7
ii  libcairo21.16.0-3
ii  libcurl3-gnutls  7.64.0-1
ii  libdb5.3 5.3.28+dfsg1-0.3
ii  libetpan20   1.9.3-1
ii  libexpat12.2.6-1
ii  libfontconfig1   2.13.1-2
ii  libfreetype6 2.9.1-3
ii  libgdata22   0.17.9-3
ii  libgdk-pixbuf2.0-0   2.38.0+dfsg-7
ii  libglib2.0-0 2.58.3-1
ii  libgnutls30  3.6.6-2
ii  libgtk2.0-0  2.24.32-3
ii  libjson-glib-1.0-0   1.4.4-2
ii  liblockfile1 1.14-1.1
ii  libpango-1.0-0   1.42.4-6
ii  libpangocairo-1.0-0  1.42.4-6
ii  libpangoft2-1.0-01.42.4-6
ii  libsasl2-2   2.1.27+dfsg-1
ii  libsoup2.4-1 2.64.2-2
ii  libxml2  2.9.4+dfsg1-7+b3

claws-mail-gdata-plugin recommends no packages.

claws-mail-gdata-plugin suggests no packages.

-- no debconf information

Bug#915370: Please drop anacron from task-desktop

[David Bremner]

Holger Wansing  writes:
>
> Any thoughts on this?
>
> Is there still a broad necessity for anacron?
> Are there still many packages, that don't rely on systemd timer units?
>

Presumably packages that work without systemd, but still need to
periodic activity?

d

Bug#923541: libdbd-mysql-perl: FTBFS against mariadb-10.3 1:10.3.13-1

[gregor herrmann]

On Thu, 07 Mar 2019 16:28:15 +0100, gregor herrmann wrote:

> I've pushed this to salsa but I'd like to wait a day or two and see
> of the PR gets merged and/or if other solutions arise (there's a
> second patch around, and also a MariaDB bug report:
> https://jira.mariadb.org/browse/MDEV-18823 )

Uploaded now as per request of the release team in order to unblock
MariaDB. We still can improve the fix in case newer developments
happen upstream.


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: U2: Zooropa


signature.asc
Description: Digital Signature

Bug#923979: python-rdflib-tools: Missing depends on python3-pkg-resources

[Brian May]

Package: python-rdflib-tools
Version: 4.2.2-2
Severity: normal

(sid-amd64-default)root@silverfish:/home/brian# csv2rdf
Traceback (most recent call last):
  File "/usr/bin/csv2rdf", line 6, in 
from pkg_resources import load_entry_point
ModuleNotFoundError: No module named 'pkg_resources'

I suspect this happened as a result of the fix in #921751
for CVE-2019-7653.

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

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

Versions of packages python-rdflib-tools depends on:
ii  python 2.7.13-2
pn  python-rdflib  

python-rdflib-tools recommends no packages.

python-rdflib-tools suggests no packages.

Bug#923964: systemd-sysv: shutdown should accept a date

[Michael Biebl]

Am 07.03.19 um 18:39 schrieb Barak A. Pearlmutter:
> Perhaps this functionality can be accessed with "systemctl poweroff
> --some-option=TIMESPEC", although I didn’t see it in systemctl(1). It
> might make sense to add that, either the option or the documentation. It
> might also make sense for shutdown(1) to mention "systemctl shutdown".

The current code is at
https://github.com/systemd/systemd/blob/master/src/systemctl/systemctl.c#L8430

Afaics, it provides minimal compatibility with the old, legacy shutdown
utility.

I can see your use case though.
Would you mind filing this upstream as a feature request at
https://github.com/systemd/systemd/issues/new/choose



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



signature.asc
Description: OpenPGP digital signature

Bug#923978: unblock: refcard/10.4

[Holger Wansing]

Package: release.debian.org
Usertags: unblock


I would like to request an unblock for version 10.4 of the Debian
reference card (source package 'refcard'). 
I have just uploaded the 10.4 version to unstable.

The changings include updates of the Finnish, Italian and Japanese translations
and a refresh of the publication date.

The debdiff is attached.


Thanks
Holger

-- 
Holger Wansing 
PGP-Fingerprint: 496A C6E8 1442 4B34 8508  3529 59F1 87CA 156E B076


refcard-10.4.debdiff
Description: Binary data

Bug#923977: Fails with python3-markdown >= 3

[chrysn]

Package: darkslide
Version: 4.0.1-1
Severity: important
Forwarded: https://github.com/ionelmc/python-darkslide/issues/10

There was a non-backwards compatible change in python3-markdown version
3 (allegedly; it happened on my system with the below dependencies
installed) that makes conversion from markdown fail like this:

$ darkslide slides.md
Adding   'slides.md' (markdown)
Error: markdown() takes 1 positional argument but 2 were given

This has already been reported upstream at
https://github.com/ionelmc/python-darkslide/issues/10, and can be fixed
by setting line 60 of parser.py to

return markdown.markdown(text, extension=self.md_extensions)

as suggested by the github reporter.

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

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

Versions of packages darkslide depends on:
ii  python3   3.7.2-1
ii  python3-docutils  0.14+dfsg-4
ii  python3-jinja22.10-1
ii  python3-markdown  3.0.1-3
ii  python3-pygments  2.3.1+dfsg-1
ii  python3-qrcode6.1-1
ii  python3-six   1.12.0-1

darkslide recommends no packages.

darkslide suggests no packages.

-- no debconf information

-- debsums errors found:
debsums: changed file /usr/lib/python3/dist-packages/darkslide/parser.py (from 
darkslide package)

-- 
To use raw power is to make yourself infinitely vulnerable to greater powers.
  -- Bene Gesserit axiom


signature.asc
Description: PGP signature

Bug#409271: Workaround

[Ivan Baldo]

On Thu, 4 Aug 2016 17:54:10 -0500 "Timothy Pearson" <
kb9...@pearsoncomputing.net> wrote:
> For now, since klibc does not have NFSV4 support, the attached file works
> around the problem (place in /usr/share/initramfs-tools/hooks/nfsv4).

Thanks a lot for the workaround!!!
Though it doesn't work with read-only NFSv4.1 and OverlayFS with TmpFS on
Stretch, both kernels 4.9 and 4.19.
Any ideas?
In the hook I added your workaround and:
manual_add_modules overlay

Then on /etc/initramfs-tools/scripts/init-bottom/local:
mkdir -m 700 /ovl
mkdir /ovl/lower /ovl/ram /ovl/merged
mount -n -o move $rootmnt /ovl/lower
mount -n -t tmpfs -o 'mode=755,size=75%' tmpfs /ovl/ram
mkdir /ovl/ram/upper /ovl/ram/work
mount -n -t overlay -o
"lowerdir=/ovl/lower,upperdir=/ovl/ram/upper,workdir=/ovl/ram/work,_netdev"
overlay /ovl/merged
mount -n -o move /ovl/merged $rootmnt
mkdir -m 700 $rootmnt/ovl
mkdir $rootmnt/ovl/lower $rootmnt/ovl/ram
mount -n -o move /ovl/lower $rootmnt/ovl/lower
mount -n -o move /ovl/ram $rootmnt/ovl/ram

This works with NFSv3.
Also, if I test it on an already booted system with mounting NFSv4.1
manually and doing the overlay it works.
So, something in the initramfs is different to the booted up system that
causes the problem, but couldn't find it.
If anyone has any idea of things to try I can report back the results and
try to provide a fully working solution afterwards.
Thanks!

Bug#923367: AppArmor: Profile for journald

[intrigeri]

Hi,

[I thought I had sent this on Feb 27, it's in my Sent folder,
but for some reason it did not make it to the BTS.]

Jörg Sommer:
> I've created a profile for journald to restrict the possible capabilities
> the process has.

Interesting!

> But journald starts before the AppArmor profiles get loaded.

I would suggest trying to use the AppArmorProfile= directive in the
journald unit. I suspect it'll fail because some other stuff (normally
set up by apparmor.service) is not ready yet at the time journald
starts, but it'll be interesting to know what that stuff is and
possibly we can set it up earlier. E.g. some of the work currently
done by apparmor.service could be moved to another service, that
starts earlier in the boot process.

> I've created a service to run after apparmor.service to restart all
> unconfined services having a profile. What do you think about this?
> Would you include this in the package?

This feels like a workaround and the potential for problematic side
effects kind of scares me. I'd rather see us work towards a nicer
solution for confining services that start before apparmor.service.

It's too late for Buster anyway so we have plenty of time to think
about it and experiment with various ideas for Bullseye :)

Cheers,
-- 
intrigeri

Bug#922120: annoying messages from systemd.unit

[Daniel Baumann]

close 922120 3.2.0-1
thanks

Hi,

On 3/7/19 6:41 PM, Daniel Kahn Gillmor wrote:
> I'm trying to replicate this, and having difficulty.  Where exactly do
> you see this message? on the terminal?  in the journal?  on the console?

both when typing e.g. 'service ssh restart' in gnome-terminal or tty1.

> Can you help me replicate the problem?

it was absolutely reproducible on any system (default vanilla d-i 'next,
next, finish'-setup). i've tried to reproduce it now, and suprisingly
for the first time i failed. after looking at dpkg.log, i saw that
knot-resolver was upgraded a couple of days ago (2.3.0->3.2.0).

i've verified this with another vanilla system that wasn't upgraded and
i can reproduce it there: 3.2.0-1 fixed it.

> Can you also show me the output of this command on your affected system:
> 
>find /etc/systemd -iname 'kres*' -ls

   262714  0 lrwxrwxrwx   1 root root   36 Jan  6 21:00
/etc/systemd/system/sockets.target.wants/kresd-tls.socket ->
/lib/systemd/system/kresd-tls.socket
   262715  0 lrwxrwxrwx   1 root root   32 Jan  6 21:00
/etc/systemd/system/sockets.target.wants/kresd.socket ->
/lib/systemd/system/kresd.socket

jftr, above output is the same, before and after the upgrade of
knot-resolver.

Regards,
Daniel

Bug#923972: openvpn: OpenVPN 2.4.7 incompatible with OpenSSL 1.1.1a due to TLS 1.3

[Bernhard Schmidt]

Control: tags -1 moreinfo

Am 07.03.19 um 19:46 schrieb Matthew Horan:

Hi Matthew,

> The version of OpenVPN in Debian buster (2.4.7) seems to be incompatible
> with the version of OpenSSL (1.1.1a) in Debian buster. This seems to be
> due to TLS 1.3 support in OpenSSL 1.1.1, which OpenVPN 2.4.7 does not
> support.
> 
> This was also reported on the debian-user mailing list [1].
> 
> Using this combination will result in the following errors:
> 
> Mon Sep  3 11:19:34 2018 us=634070 TLS_ERROR: BIO read tls_read_plaintext 
> error
> Mon Sep  3 11:19:34 2018 us=634074 TLS Error: TLS object -> incoming 
> plaintext read error
> Mon Sep  3 11:19:34 2018 us=634079 TLS Error: TLS handshake failed 
> 
> and the connection will be closed.

Thanks for your report.

I cannot really reproduce this. OpenVPN 2.4.7 in testing successfully
connects (in tls-client mode) to an OpenVPN 2.4.0 on Stretch.

Thu Mar  7 21:28:49 2019 Control Channel: TLSv1.2, cipher TLSv1.2
ECDHE-RSA-AES256-GCM-SHA384, 2048 bit RSA

Could it be possible that your server is quite old?

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=912650 suggests there
might be an issue connecting to an OpenVPN version that only does
TLSv1.0 by default.

> A workaround is to add "tls-version-max 1.2" to the OpenVPN config file.

If you use that workaround, what TLS version is negotiated?

Best Regards,
Bernhard

Bug#923907: Acknowledgement (webext-browserpass: No toolbar icon in Firefox 60)

[Alexander Dahl]

I'm a little emberassed, but after reboot the extension works now in
Firefox. No idea, was has happened, but I guess this can be closed.
o.O

-- 
/"\ ASCII RIBBON | »With the first link, the chain is forged. The first
\ / CAMPAIGN | speech censured, the first thought forbidden, the
 X  AGAINST  | first freedom denied, chains us all irrevocably.«
/ \ HTML MAIL| (Jean-Luc Picard, quoting Judge Aaron Satie)


signature.asc
Description: PGP signature

Bug#712953: sysvinit: System Restarts Instead of Powering Off

[Pierre Ynard]

reassign 712953 src:linux
thanks

> You are correct - its the kernel. I installed the 3.2.0-4 kernel 
> from wheezy into my sid system and booted from it and it shuts down 
> perfectly 

Since it was established that this was most likely a problem in the
kernel and not in sysvinit, I'm reassigning.

I'm sorry for your troubles :(

-- 
Pierre Ynard

Bug#855811: release.debian.org: release.d.o WWW should explicitly recommend against uploading to sid during the freeze

[Paul Gevers]

Hi Sean,

Sorry it took so long to get a reply.

On Tue, 21 Feb 2017 15:04:39 -0700 Sean Whitton
 wrote:
> I'd like to suggest that this recommendation be stated explicitly on the
> release team's website, to reduce the number of blocking uploads to
> unstable made during the freeze.

Is the current text good enough for this purpose?
"""
We strongly prefer changes that can be done via unstable instead of
testing-proposed-updates. If there are unrelated changes in unstable,
you should consider reverting these instead of making an upload to
testing-proposed-updates.
"""

Paul



signature.asc
Description: OpenPGP digital signature

Bug#915370: Please drop anacron from task-desktop

[Holger Wansing]

[ Forwarding this to -devel ]


Hi,

Laurent Bigonville  wrote:
> On Mon, 03 Dec 2018 09:44:05 +0100 Michael Biebl  wrote:
> 
> Hello,
> 
>  >
>  > anacron was added to the desktop-task a long time ago.
>  > The changelog doesn't mention why it was added, but I assume it was to
>  > support systems which are not running 24/7 and to ensure that cron jobs
>  > have a chance to run.
>  >
>  > Nowadays, we have systemd .timer units, which handle this issue much
>  > nicer. I checked a default desktop installation, and all important cron
>  > jobs have a corresponding .timer unit.
>  > It thus seems safe to drop anacron from task-desktop.
>  >
> 
> I'm actually wondering if this is a good idea..
> 
> There are lot of other packages installing cronjobs and people, I would 
> assume, expect that they will run.
> 
> I would personally revert his patch as long as all the cronjobs have not 
> a corresponding systemd .timer

Any thoughts on this?

Is there still a broad necessity for anacron?
Are there still many packages, that don't rely on systemd timer units?


Holger




-- 
Holger Wansing 
PGP-Fingerprint: 496A C6E8 1442 4B34 8508  3529 59F1 87CA 156E B076

Bug#923444: bacula: autopkgtest regressed in buster

[Sven Hartge]

On 07.03.19 20:37, Paul Gevers wrote:
> On 03-03-2019 18:31, Carsten Leonhardt wrote:
>> Paul Gevers  writes:
>>> On 02-03-2019 15:34, Carsten Leonhardt wrote:

 maybe using a trigger can help us:
>>>
>>> This sounds like an idea we should try to implement in dbconfig-common,
>>> to enable other packages to benefit from it as well. If done, this is
>>> for after buster release though.
>>
>> I already found that we're not the first to run into this problem.
> 
> Where did you find that? I.e. which other packages are suffering?

Quoting Carsten:
Bareos has run into this problem before, btw:

https://salsa.debian.org/pkg-bareos-team/bareos/commit/82a4ffcc18b5b79259394c1571944d2b0b882944

If I had time right now, I'd use codesearch to find packages listing
postgresql in their debian/tests/control and then check if they
currently fail in the same manner as Bacula and Bareos.

 An simple but stupid and unelegant alternative would be to generate meta
 packages "bacula-director-local-psql/mysql" that _depend_ on the database
 server packages.
>>>
>>> I rather propose that we accept the current regression of the bacula
>>> autopkgtest and we fix the situation properly (in autopkgtest and/or
>>> dbconfig-common) after the buster release. Can you live with that?
>>
>> Yes, we can live with that as long as the CI-people can, as Sven
>> already said.
> 
> Who do you mean by CI-people?

The people running ci.debian.net and filing bugs on behalf of failing
tests, for example: you :)

Grüße,
Sven.




signature.asc
Description: OpenPGP digital signature

Bug#923444: bacula: autopkgtest regressed in buster

[Paul Gevers]

Hi all,

On 03-03-2019 18:31, Carsten Leonhardt wrote:
> Paul Gevers  writes:
>> On 02-03-2019 15:34, Carsten Leonhardt wrote:
>>> maybe using a trigger can help us:
>>
>> This sounds like an idea we should try to implement in dbconfig-common,
>> to enable other packages to benefit from it as well. If done, this is
>> for after buster release though.
> 
> I already found that we're not the first to run into this problem.

Where did you find that? I.e. which other packages are suffering?

>>> An simple but stupid and unelegant alternative would be to generate meta
>>> packages "bacula-director-local-psql/mysql" that _depend_ on the database
>>> server packages.
>>
>> I rather propose that we accept the current regression of the bacula
>> autopkgtest and we fix the situation properly (in autopkgtest and/or
>> dbconfig-common) after the buster release. Can you live with that?
> 
> Yes, we can live with that as long as the CI-people can, as Sven
> already said.

Who do you mean by CI-people?

> Would you like me to file a wishlist bug against dbconfig-common?

Yes please. Although, the remark of Sven in his last response did
resonate a bit:

> Or are we trying to fix a problem at the whole wrong level?

I am not sure about the answer. If anybody has the time and energy,
maybe they can check with the dpkg maintainers if they are aware of the
situation and if that is intentional. Maybe they consider this issue
something they can (and should) fix.

Paul



signature.asc
Description: OpenPGP digital signature

Bug#905014: I'm adopting dhcpy6d

[Moritz Schlarb]

Control: retitle -1 ITA: dhcpy6d -- MAC address aware DHCPv6 server
written in Python
Control: owner -1 !
Control: affects -1 = dhcpy6d

Hi everyone,

I'm willing to adopt dhcpy6d.

I will create a project in the Salsa PAPT namespace for it.
Someone needs to add me to the upload ACL though.

Regards,
Moritz

Bug#923975: task files should not recommend removed packages

[Wolfgang Schweer]

Source: tasksel
Version: 3.50
Severity: normal
User: debian-...@lists.debian.org
Usertags: debian-edu

Dear maintainers,

while working at Debian Edu installation media I noticed that various
tasks are recommending packages that are not (or no longer) available:

task-catalan-desktop:myspell-ca (see also: #910615)
task-chinese-s:  fortune-zh
task-finnish-desktop:xul-ext-mozvoikko
task-french: doc-linux-fr-text, doc-debian-fr
task-greek-desktop:  fonts-mgopen (see also: #823150)
task-gujarati-kde-desktop:   kde-l10n-gu
task-hungarian-desktop:  libreoffice-thesausus-hu
task-italian-desktop:myspell-it
task-kannada-kde-desktop:kde-l10n-kn
task-kurdish-desktop:libreoffice-l10n-ku, myspell-ku
task-lithuanian-desktop: myspell-lt
task-macedonian-kde-desktop: kde-l10n-mk
task-malayalam-kde-desktop:  kde-l10n-ml
task-polish: doc-linux-pl, doc-linux-pl-html 
task-sinhala-kde-desktop:kde-l10n-si
task-slovenian-desktop:  myspell-sl
task-spanish:doc-debian-es
task-thai-desktop:   myspell-th
task-thai-kde-desktop:   kde-l10n-th
task-ukrainian:  doc-debian-uk
task-vietnamese-kde-desktop: kde-l10n-vi

Also, while at it: some inconsistency?

--- a/debian-tasks.desc 2019-03-07 19:20:48.179994586 +0100
+++ b/debian-tasks.desc 2019-03-07 19:28:48.227824535 +0100
@@ -1278,7 +1278,7 @@
 Enhances: kde-desktop, ukrainian-desktop
 Section: l10n
 
-Task: sinhala-desktop
+Task: uyghur-desktop
 Key: 
   task-uyghur-desktop
 Enhances: desktop

Please check.

Wolfgang

Bug#923974: packages.debian.org filelist incorrect (for some archs)

[Laura Arjona Reina]

Package: www.debian.org
User: www.debian@packages.debian.org
Usertag: packages
Severity: normal
X-Debbugs-CC: andr...@fatal.se

Hi Andreas
Thanks for the report. I have created a bug report about it, if you want
to follow you can subscribe to the bug sending a mail to
-subscr...@bugs.debian.org (being  the bug number).

Kind regards


 Mensaje reenviado 
Asunto: packages.debian.org filelist incorrect (for some archs)
Resent-Date: Sun,  3 Mar 2019 10:17:04 + (UTC)
Resent-From: debian-...@lists.debian.org
Fecha: Sun, 3 Mar 2019 11:08:47 +0100
De: Andreas Henriksson 
Para: debian-...@lists.debian.org

Hi,

I happened to look at this page and spotted multiple problems (and it
had your contact information on it):
https://packages.debian.org/sid/arm64/sysvinit-utils/filelist

1. The file list is not correct
   - eg. /usr/sbin/service et.al. are not in the package (anymore since
   several years).
2. It doesn't say with actual version of the package it's showing
   only a vague " in sid" statement so it's not obvious when
   the filelist is outdated information.

Compare this other archs page which seems more up to date:
https://packages.debian.org/sid/amd64/sysvinit-utils/filelist

Regards,
Andreas Henriksson

Bug#923771: unblock: pandas/0.23.3+dfsg-3

[Rebecca N. Palmer]

Control: tags -1 - moreinfo

Built on every release architecture, autopkgtest good.

As discussed, please also give back statsmodels, as the new pandas 
should allow it to build.

Bug#923891: Root cause

[Soren Stoutner]

This bug appears to be caused by the packaging switch in the JQuery 
library as described by this line in the 4.0.1-1 changelog.


"Use system jquery libs instead of source-less embedded aggregated file."

--
Soren Stoutner
623-262-6169
so...@stoutner.com

Bug#923972: openvpn: OpenVPN 2.4.7 incompatible with OpenSSL 1.1.1a due to TLS 1.3

[Matthew Horan]

Package: openvpn
Version: 2.4.7-1
Severity: normal

Dear Maintainer,

The version of OpenVPN in Debian buster (2.4.7) seems to be incompatible
with the version of OpenSSL (1.1.1a) in Debian buster. This seems to be
due to TLS 1.3 support in OpenSSL 1.1.1, which OpenVPN 2.4.7 does not
support.

This was also reported on the debian-user mailing list [1].

Using this combination will result in the following errors:

Mon Sep  3 11:19:34 2018 us=634070 TLS_ERROR: BIO read tls_read_plaintext error
Mon Sep  3 11:19:34 2018 us=634074 TLS Error: TLS object -> incoming plaintext 
read error
Mon Sep  3 11:19:34 2018 us=634079 TLS Error: TLS handshake failed 

and the connection will be closed.

A workaround is to add "tls-version-max 1.2" to the OpenVPN config file.

I do *believe* that this a client side issue, but it could be a
misconfiguration on the server side. Regardless, the error message is
pretty vague, and it took me a while to figure out what was going on.

[1] https://lists.debian.org/debian-user/2018/09/msg00044.html


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

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

Versions of packages openvpn depends on:
ii  debconf [debconf-2.0]  1.5.70
ii  iproute2   4.20.0-2
ii  libc6  2.28-7
ii  liblz4-1   1.8.3-1
ii  liblzo2-2  2.10-0.1
ii  libpam0g   1.3.1-5
ii  libpkcs11-helper1  1.25.1-1
ii  libssl1.1  1.1.1a-1
ii  libsystemd0241-1
ii  lsb-base   10.2018112800

Versions of packages openvpn recommends:
ii  easy-rsa  3.0.6-1

Versions of packages openvpn suggests:
ii  openssl   1.1.1a-1
pn  openvpn-systemd-resolved  
pn  resolvconf

-- debconf information excluded

Bug#923973: /usr/bin/spectacle: Spectacle does not work when using windows mode. Other mode OK (rectangulr, full screen, ...)

[Eric Valette]

Package: kde-spectacle
Version: 18.04.0-1
Severity: important
File: /usr/bin/spectacle

It is the most usefull mode and the one that does not work. It is not new but 
several
kde version have been released with no progress.

In previous version it carshed. Now it just hangs (does not come back form 
hiding).

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

Kernel: Linux 4.19.27 (SMP w/8 CPU cores; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE
Locale: LANG=fr_FR.UTF8, LC_CTYPE=fr_FR.UTF8 (charmap=UTF-8), LANGUAGE= 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages kde-spectacle depends on:
ii  kio   5.54.1-1
ii  libc6 2.28-8
ii  libkf5configcore5 5.54.0-1
ii  libkf5configgui5  5.54.0-1
ii  libkf5configwidgets5  5.54.0-1
ii  libkf5coreaddons5 5.54.0-1
ii  libkf5dbusaddons5 5.54.0-1
ii  libkf5declarative55.54.0-1
ii  libkf5i18n5   5.54.0-1
ii  libkf5kiocore55.54.1-1
ii  libkf5kiowidgets5 5.54.1-1
ii  libkf5kipi32.0.0  4:17.08.3-1
ii  libkf5newstuff5   5.54.0-2
ii  libkf5notifications5  5.54.0-1
ii  libkf5purpose-bin 5.54.0-1
ii  libkf5purpose55.54.0-1
ii  libkf5service-bin 5.54.0-1
ii  libkf5service55.54.0-1
ii  libkf5widgetsaddons5  5.54.0-1
ii  libkf5windowsystem5   5.54.0-1
ii  libkf5xmlgui5 5.54.0-1
ii  libqt5core5a  5.11.3+dfsg-5
ii  libqt5dbus5   5.11.3+dfsg-5
ii  libqt5gui55.11.3+dfsg-5
ii  libqt5printsupport5   5.11.3+dfsg-5
ii  libqt5qml55.11.3-4
ii  libqt5quick5  5.11.3-4
ii  libqt5widgets55.11.3+dfsg-5
ii  libqt5x11extras5  5.11.3-2
ii  libstdc++68.3.0-2
ii  libxcb-cursor00.1.1-4
ii  libxcb-image0 0.4.0-1+b2
ii  libxcb-util0  0.3.8-3+b2
ii  libxcb-xfixes01.13.1-2
ii  libxcb1   1.13.1-2

kde-spectacle recommends no packages.

kde-spectacle suggests no packages.

-- no debconf information

Bug#923967: RFS: chkboot/1.2-3

[Baptiste BEAUPLAT]

On 3/7/19 7:19 PM, Baptiste BEAUPLAT wrote:> More information about
chkboot can be obtained from https://www.example.com.

More information about chkboot can be obtained from
https://salsa.debian.org/debian/chkboot.

-- 
Baptiste BEAUPLAT - lyknode



signature.asc
Description: OpenPGP digital signature

Bug#923971: caja: Display issue when renaming files in icon mode

[Matthew Horan]

Package: caja
Version: 1.20.3-1+b1
Severity: normal

Dear Maintainer,

With caja 1.20.3 on Debian buster, renaming files in icon mode leads to
a display issues [1].

When renaming a file, the original text is not cleared out, and the
renamed text is simply written over the original text, rending it
difficult to read.

I have not been able to find a workaround for the issue. It seems to
have been reported upstream, but some time ago. I do not experience this
on my Debian stretch system, which is also running caja 1.20.3.

[1] https://github.com/mate-desktop/caja/issues/791


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

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

Versions of packages caja depends on:
ii  caja-common   1.20.3-1
ii  desktop-file-utils0.23-4
ii  gvfs  1.38.1-3
ii  libatk1.0-0   2.30.0-2
ii  libc6 2.28-7
ii  libcairo-gobject2 1.16.0-3
ii  libcairo2 1.16.0-3
ii  libcaja-extension11.20.3-1+b1
ii  libexempi82.5.0-2
ii  libexif12 0.6.21-5.1
ii  libgail-3-0   3.24.5-1
ii  libgdk-pixbuf2.0-02.38.0+dfsg-7
ii  libglib2.0-0  2.58.3-1
ii  libglib2.0-bin2.58.3-1
ii  libglib2.0-data   2.58.3-1
ii  libgtk-3-03.24.5-1
ii  libice6   2:1.0.9-2
ii  libmate-desktop-2-17  1.20.4-2
ii  libnotify40.7.7-4
ii  libpango-1.0-01.42.4-6
ii  libpangocairo-1.0-0   1.42.4-6
ii  libselinux1   2.8-1+b1
ii  libsm62:1.2.3-1
ii  libstartup-notification0  0.12-6
ii  libx11-6  2:1.6.7-1
ii  libxml2   2.9.4+dfsg1-7+b3
ii  mate-desktop  1.20.4-2
ii  shared-mime-info  1.10-1

Versions of packages caja recommends:
ii  gvfs-backends  1.38.1-3

Versions of packages caja suggests:
ii  engrampa1.20.2-1
pn  gstreamer1.0-tools  
pn  meld

-- no debconf information

Bug#923931: upgrade breaks old containers

[Antonio Terceiro]

On Thu, Mar 07, 2019 at 12:49:21PM +0100, Harald Dunkel wrote:
> Package: lxc
> Version: 1:3.1.0+really3.0.3-5
> 
> After the upgrade to lxc 3 the old containers created by
> lxc 2 don't work anymore, even though lxc-update-config has
> been run (manually). The config files still contain template
> specific include statements, e.g.
> 
>   lxc.include = /usr/share/lxc/config/debian.common.conf
> 
> These files are not included in lxc 3. They are included in
> lxc-templates, but this package was not installed during the
> upgrade.
> 
> I would suggest to either add "Depends: lxc-templates" to
> the package dependencies, or to move the lost template specific
> include files back into the lxc 3 package.

This only happens if you turn recommends off.

templates are considered deprecated by upstream, and while we are
keepking them around I don't think we should have a hard dependency on
them. Under the default APT settings lxc-templates will come together
with lxc on upgrades, but maybe we could add a NEWS entry about needing
lxc-templates if you have legacy containers *and* turns recommends off.


signature.asc
Description: PGP signature

Bug#923970: libkres-dev: cannot build anything meaningful against libkres-dev

[Daniel Kahn Gillmor]

Package: libkres-dev
Version: 3.2.1-1
Severity: grave
Justification: renders package unusable

A little over half of the header files shipped in libkres-dev contain
an #include line that refers to other files in "lib/…", for example:

#include "lib/defines.h"

You can see these with:

grep -n 'include "lib' /usr/include/libkres/*.h

This breaks anything that tries to #include these files directly, with
errors like this:

gcc -o kres-test kres-test.c -lkres
In file included from kres-test.c:1:
/usr/include/libkres/module.h:23:10: fatal error: lib/defines.h: No such 
file or directory
 #include "lib/defines.h"
  ^~~
compilation terminated.
make: *** [Makefile:4: kres-test] Error 1


Of the files that don't include such a broken #include, they are
either not particularly useful on their own
(e.g. /usr/include/libkres/defines.h) or they refer to functions not
actually exported by libkres.so
(e.g. /usr/include/libkres/signature.h, which exposes a C header for
kr_authenticate_referral, which is not in libkres.so).

So libkres-dev doesn't really work at all right now, and the
distributed shared object libkres.so.* itself doesn't seem to be
useful for anything other than knot-resolver.

Upstream is planning to eventually produce some sort of functional
library, but they're not clear on what it looks like:

https://gitlab.labs.nic.cz/knot/knot-resolver/merge_requests/770

So i think my earlier attempt at splitting out libkres was overly
optimistic, and will probably roll it back so that we're not shipping
a useless package.  When libkres matures, i'm sure we'll be able to
split it out again!

  --dkg



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

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

Versions of packages libkres-dev depends on:
ii  libkres9  3.2.1-1

libkres-dev recommends no packages.

libkres-dev suggests no packages.

-- no debconf information

Bug#923967: RFS: chkboot/1.2-3

[Baptiste BEAUPLAT]

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

  * Package name: chkboot
Version : 1.2-3
Upstream Author : Giancarlo Razzolini 
  * URL : https://github.com/grazzolini/chkboot
  * License : GPL-2+
Section : utils

It builds those binary packages:

  chkboot - detection of malicious changes for boot files

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

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

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

  dget -x
https://mentors.debian.net/debian/pool/main/c/chkboot/chkboot_1.2-3.dsc

More information about chkboot can be obtained from https://www.example.com.

Changes since the last upload:

  * Fix url in Vcs-Browser
  * Bump policy version to 4.3.0
  * Bump debian-compat to 12. Remove debian/compat

Regards,

-- 
Baptiste BEAUPLAT - lyknode



signature.asc
Description: OpenPGP digital signature

Bug#923956: [Pkg-alsa-devel] Bug#923956: libasound2: with libasound2:i386 a call to snd_rawmid_open() on amd64 platform always aborts

[Elimar Riesebieter]

Control: severity -1 minor
Control: tags -1 wontfix

* Donald Kayser  [2019-03-07 16:09 +]:

> 
> Package: libasound2
> Version: 1.1.3-5
> Severity: important
> 
> Dear Maintainer,
> 
> I have a test program that only calls snd_rawmidi_open() with
> appropriate parameters. In an amd64 system, the open call always
> ends with "snd_rawmidi_open_conf: Assertion `err >= 0' failed."

To discuss software development interna please contact alsa
upstream. FYI the latest alsa-lib version in Debian is 1.1.8-1. And
yes, this bug is not important to Debian users at all and wont be
fixed by Debian's alsa maintainers.

Elimar
-- 
  Obviously the human brain works like a computer.
  Since there are no stupid computers humans can't be stupid.
  There are just a few running with Windows or even CE ;-)


signature.asc
Description: PGP signature

Bug#923969: RFS: vitetris/0.57.2-3

[Baptiste BEAUPLAT]

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

  * Package name: vitetris
Version : 0.57.2-3
Upstream Author : Victor Geraldsson
  * URL : http://www.victornils.net/tetris/
  * License : BSD-2-Clause
Section : games

It builds those binary packages:

  vitetris - Virtual terminal *tris clone

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

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

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

  dget -x
https://mentors.debian.net/debian/pool/main/v/vitetris/vitetris_0.57.2-3.dsc

More information about vitetris can be obtained from
https://salsa.debian.org/lyknode-guest/vitetris.

Changes since the last upload:

  * Convert repo to DEP-14
  * Move binary stripping from Makefile to debhelper
  * Bump policy version to 4.3.0
  * Bump debian-compat to 12. Remove debian/compat

Regards,

-- 
Baptiste BEAUPLAT - lyknode



signature.asc
Description: OpenPGP digital signature

Bug#923968: RFS: monitorix/3.10.1-2

[Baptiste BEAUPLAT]

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

  * Package name: monitorix
Version : 3.10.1-2
Upstream Author : Jordi Sanfeliu
  * URL : https://www.monitorix.org
  * License : GPL-2
Section : utils

It builds those binary packages:

  monitorix - lightweight system monitoring tool

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

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

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

  dget -x
https://mentors.debian.net/debian/pool/main/m/monitorix/monitorix_3.10.1-2.dsc

More information about monitorix can be obtained from
https://salsa.debian.org/debian/monitorix.

Changes since the last upload:

  * debian-compat to 12. Remove debian/compat

Regards,

-- 
Baptiste BEAUPLAT - lyknode



signature.asc
Description: OpenPGP digital signature

Bug#923966: unblock: libncl/2.1.21+git20180827.c71b264-2

[Andreas Tille]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Please unblock package libncl


 libncl (2.1.21+git20180827.c71b264-2) unstable; urgency=medium
 .
   * Rebuild for new version of gcc to fix symbols
 Closes: #923955
   * Standards-Version: 4.3.0



unblock libncl/2.1.21+git20180827.c71b264-2

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

Kernel: Linux 4.9.0-6-amd64 (SMP w/1 CPU core)
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)
diff -Nru libncl-2.1.21+git20180827.c71b264/debian/changelog 
libncl-2.1.21+git20180827.c71b264/debian/changelog
--- libncl-2.1.21+git20180827.c71b264/debian/changelog  2018-12-04 
19:10:38.0 +0100
+++ libncl-2.1.21+git20180827.c71b264/debian/changelog  2019-03-07 
19:13:02.0 +0100
@@ -1,3 +1,11 @@
+libncl (2.1.21+git20180827.c71b264-2) unstable; urgency=medium
+
+  * Rebuild for new version of gcc to fix symbols
+Closes: #923955
+  * Standards-Version: 4.3.0
+
+ -- Andreas Tille   Thu, 07 Mar 2019 19:13:02 +0100
+
 libncl (2.1.21+git20180827.c71b264-1) unstable; urgency=medium
 
   * Update symbols
diff -Nru libncl-2.1.21+git20180827.c71b264/debian/control 
libncl-2.1.21+git20180827.c71b264/debian/control
--- libncl-2.1.21+git20180827.c71b264/debian/control2018-12-04 
19:10:38.0 +0100
+++ libncl-2.1.21+git20180827.c71b264/debian/control2019-03-07 
19:13:02.0 +0100
@@ -6,7 +6,7 @@
 Build-Depends: debhelper (>= 11~),
d-shlibs,
python
-Standards-Version: 4.2.1
+Standards-Version: 4.3.0
 Vcs-Browser: https://salsa.debian.org/med-team/libncl
 Vcs-Git: https://salsa.debian.org/med-team/libncl.git
 Homepage: https://github.com/mtholder/ncl
diff -Nru libncl-2.1.21+git20180827.c71b264/debian/libncl2.symbols.amd64 
libncl-2.1.21+git20180827.c71b264/debian/libncl2.symbols.amd64
--- libncl-2.1.21+git20180827.c71b264/debian/libncl2.symbols.amd64  
2018-12-04 19:10:38.0 +0100
+++ libncl-2.1.21+git20180827.c71b264/debian/libncl2.symbols.amd64  
2019-03-07 19:13:02.0 +0100
@@ -852,7 +852,6 @@
  _ZNK24NxsTransformationManager7IsEmptyEv@Base 2.1.18
  
_ZNK24NxsTransformationManager9IsIntTypeERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEE@Base
 2.1.18
  _ZNK25NxsDiscreteDatatypeMapper10DebugPrintERSo@Base 2.1.18
- (optional)_ZNK25NxsDiscreteDatatypeMapper13FirstIsSubsetEiib@Base 2.1.18
  _ZNK25NxsDiscreteDatatypeMapper13IsPolymorphicEi@Base 2.1.18
  _ZNK25NxsDiscreteDatatypeMapper17PositionInSymbolsEc@Base 2.1.18
  _ZNK25NxsDiscreteDatatypeMapper17ValidateStateCodeEi@Base 2.1.18
@@ -916,12 +915,11 @@
  _ZNK9NxsString9IsADoubleEv@Base 2.1.18
  _ZNKSt5ctypeIcE8do_widenEc@Base 2.1.18
  
_ZNKSt8_Rb_treeINSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEES5_St9_IdentityIS5_ESt4lessIS5_ESaIS5_EE4findERKS5_@Base
 2.1.18
+ 
_ZNKSt8_Rb_treeINSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEESt4pairIKS5_16NxsIntStepMatrixESt10_Select1stIS9_ESt4lessIS5_ESaIS9_EE4findERS7_@Base
 2.1.21+git20180827.c71b264
  
(optional)_ZNKSt8_Rb_treeINSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEESt4pairIKS5_17NxsRealStepMatrixESt10_Select1stIS9_ESt4lessIS5_ESaIS9_EE4findERS7_@Base
 2.1.21+git20171002.4becff7
  
_ZNKSt8_Rb_treeINSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEESt4pairIKS5_NS0_4listIS6_IS5_St3setIjSt4lessIjESaIjEEESaISE_St10_Select1stISH_ESA_IS5_ESaISH_EE4findERS7_@Base
 2.1.18
  
_ZNKSt8_Rb_treeINSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEESt4pairIKS5_St6vectorIdSaIdEEESt10_Select1stISB_ESt4lessIS5_ESaISB_EE4findERS7_@Base
 2.1.18
  
(optional)_ZNKSt8_Rb_treeINSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEESt4pairIKS5_jESt10_Select1stIS8_ESt4lessIS5_ESaIS8_EE4findERS7_@Base
 2.1.21+git20171002.4becff7
- (optional)_ZNSt11_Deque_baseIjSaIjEED1Ev@Base 2.1.21+git20171002.4becff7
- (optional)_ZNSt11_Deque_baseIjSaIjEED2Ev@Base 2.1.21+git20171002.4becff7
  
_ZNSt11__copy_moveILb0ELb0ESt26random_access_iterator_tagE8__copy_mIPPKcSt20back_insert_iteratorISt6vectorINSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEESaISD_ET0_T_SI_SH_@Base
 2.1.18
  
_ZNSt12_Destroy_auxILb0EE9__destroyIPSt4pairI25NxsDiscreteDatatypeMapperSt3setIjSt4lessIjESaIjEvT_SB_@Base
 2.1.18
  _ZNSt13_Bvector_baseISaIbEE13_M_deallocateEv@Base 2.1.18
@@ -931,7 +929,6 @@
  
(optional)_ZNSt20__uninitialized_copyILb0EE13__uninit_copyIN9__gnu_cxx17__normal_iteratorIPKSt6vectorIiSaIiEES4_IS6_SaIS6_PS6_EET0_T_SE_SD_@Base
 2.1.18
  
_ZNSt20__uninitialized_copyILb0EE13__uninit_copyIPK9NxsStringPS2_EET0_T_S7_S6_@Base
 2.1.18
  
_ZNSt20__uninitialized_copyILb0EE13__uninit_copyIPKSt4pairI25NxsDiscreteDatatypeMapperSt3setIjSt4lessIjESaIjEEEPS9_EET0_T_SE_SD_@Base
 2.1.18
- 

Bug#444980: udev not restarted after exiting runlevel 1

[Pierre Ynard]

Hello Michael,

> I don't think there is anything to fix on the udev side, as the
> process is killed by "/etc/init.d/rc single".

It's my understanding that this means that you believe udev shouldn't be
stopped in runlevel 1? I know that arguments have been brought forward
by others 10 years ago, but I wanted to know, what are your reasons
behind this opinion now?

Surely the technical hindrances with the init script aren't a blocker
anymore like they were back then? Are you opposed to adding LSB headers
to cleanly stop udev in runlevel 1 and restart it in runlevel 2? Why?

-- 
Pierre Ynard

Bug#923226: Compiling shader doesn't work - game doesn't work

[Simon McVittie]

On Thu, 07 Mar 2019 at 13:30:57 +0100, Julien Puydt wrote:
> Just changing the ioquake3 binary package (which makes dpkg complain about
> ioquake3-server, but it's normal):
> 1.36+u20181017.09166ba~dfsg-2 works
> 1.36+u20181222.e5da13f~dfsg-1 fails

What graphics stack are you using, in particular your kernel and Mesa
driver? Running `reportbug --template ioquake3` will summarize the most
relevant packages.

It looks as though the problem might be that your driver only provides
GLSL 1.20 (either on your hardware or in general), whereas the hitCube()
function introduced between 09166ba and e5da13f assumes GLSL 1.30
or later.

Thanks,
smcv

Bug#923964: systemd-sysv: shutdown should accept a date

[Barak A. Pearlmutter]

Package: systemd-sysv
Version: 241-1
Severity: wishlist

Dear Maintainer,

Thanks to the diligent effort of people like yourself, my Debian
computers usually run without rebooting for months and sometimes even
years.

But sometimes some external issue, like a scheduled power outage,
mandates a clean scheduled shut down. This just happened to me: there is
a scheduled power outage at my workplace at 04:00 about two weeks from
today, so I need to power down a handful of machines beforehand.

Naturally I’d wish to

$ sudo shutdown --poweroff '2019-03-19 03:00'

But that doesn’t work, shutdown only accepts a time, or a delay in
minutes. Instead I end up converting the delay to minutes:

$ sudo shutdown --poweroff +$(echo "($(date --date='2019-03-19 03:00' '+%s') - 
$(date '+%s')) / 60" | bc)

Yuck. The shutdown executable (which is just a symlink to systemctl, so
in fact already links to date parsing routines) really should take a
proper date string.

Perhaps this functionality can be accessed with "systemctl poweroff
--some-option=TIMESPEC", although I didn’t see it in systemctl(1). It
might make sense to add that, either the option or the documentation. It
might also make sense for shutdown(1) to mention "systemctl shutdown".

Bug#922624: Bug#922642: possible implementation

[Christoph Biedl]

Control: 922624 -patch
Control: 922642 +patch

Beware, this should go to #922642 not #922624. Changelog (below) still
needs to be adjusted.

Christoph

Dmitry Bogatov wrote...

control: tags -1 +patch

Hello! Here is debdiff with implementation of proposal -- `execlineb' is
moved to /usr/bin and it includes /usr/lib/execline/bin into PATH. Every
binary in /usr/bin needs a manual, so I conjured one with `help2man',
but it definitely need polishing.

Thank you for packaging and maintaining `execline'.

diff -Nru execline-2.5.0.1/debian/changelog execline-2.5.0.1/debian/changelog
--- execline-2.5.0.1/debian/changelog   2019-02-08 14:36:23.0 +
+++ execline-2.5.0.1/debian/changelog   2019-03-06 17:53:53.0 +
@@ -1,3 +1,11 @@
+execline (2.5.0.1-4) UNRELEASED; urgency=medium
+
+  * Add `/usr/lib/execline/bin' into PATH for scripts, invoked by `execlineb'.
+(Closes: #922624)
+  * Move execlineb into `/usr/bin'.
+
+ -- Dmitry Bogatov   Wed, 06 Mar 2019 17:53:53 +
+
 execline (2.5.0.1-3) unstable; urgency=medium
 
   * Add dep8 autopkgtest script
diff -Nru execline-2.5.0.1/debian/execlineb.1 
execline-2.5.0.1/debian/execlineb.1
--- execline-2.5.0.1/debian/execlineb.1 1970-01-01 00:00:00.0 +
+++ execline-2.5.0.1/debian/execlineb.1 2019-03-06 17:53:53.0 +
@@ -0,0 +1,401 @@
+.\" DO NOT MODIFY THIS FILE!  It was generated by help2man 1.47.8.
+.TH EXECLINEB "1" "March 2019" "Debian" "User Commands"
+.SH NAME
+execlineb \- manual page for execlineb execline
+.SH DESCRIPTION
+execline
+Software
+skarnet.org
+.PP
+The execlineb program
+.PP
+execlineb reads and executes a script.
+.PP
+Interface
+.IP
+execlineb [ \fB\-q\fR | \fB\-w\fR | \fB\-W\fR ] [ \fB\-p\fR | \fB\-P\fR | 
\fB\-S\fR nmin | \fB\-s\fR nmin ] \fB\-c\fR script [ args... ]
+.PP
+or
+.IP
+execlineb [ \fB\-q\fR | \fB\-w\fR | \fB\-W\fR ] [ \fB\-p\fR | \fB\-P\fR | 
\fB\-S\fR nmin | \fB\-s\fR nmin ] scriptfile [ args... ]
+.PP
+or in an executable file:
+.PP
+#!/command/execlineb [ \fB\-qwWpPSnmin\fR ]
+script
+.PP
+Parsing phase.
+.IP
+* execlineb reads and parses the script it is given. It exits 100 on a
+.IP
+syntax error and 111 on a temporary error. It makes an argv, i.e. a
+system command line, with the parsed script. If the argv is empty,
+execlineb exits 0.
+.PP
+Environment management phase.
+.IP
+* Pushing the current stack frame. If none of the \fB\-p\fR, \fB\-P\fR, 
\fB\-S\fR or \fB\-s\fR
+.IP
+options is set: execlineb pushes the current positional parameters,
+i.e. environment variables that start with #, 0, 1, ..., 9. To get the
+previous values back, use emptyenv \fB\-P\fR.
+.IP
+* Setting the new stack frame. If none of the \fB\-P\fR, \fB\-S\fR or 
\fB\-s\fR options is
+.IP
+set:
+.IP
++ execlineb sets the # environment variable to the number n of args
+.IP
+it is given.
+.IP
++ It sets the 0 environment variable to the name of the script \- or
+.IP
+to the execlineb invocation name if the \fB\-c\fR option is used.
+.IP
++ It sets the 1, 2, ... n environment variables to the different
+.IP
+args.
+.PP
+Execution phase.
+.IP
+* execlineb executes into the argv it has built from the script. There
+.IP
+is only one command line for the whole script: the execlineb binary is
+a launcher, whose sole purpose is to execute into that command line.
+It does not stay in memory like a traditional interpreter would.
+.PP
+Options
+.IP
+* \fB\-c\fR script : execute script, do not look for a file.
+.PP
+See below for the other options.
+.PP
+Syntax of scripts
+.PP
+An execlineb script is a string that must not contain the null character.
+execlineb parses it and divides it into words. The parser recognizes the
+following components:
+.IP
+* whitespace is defined as spaces, tabs, newlines and carriage returns.
+.IP
+Words are always separated by whitespace.
+.IP
+* A quoted string begins with a doublequote (") and ends with another
+.IP
+doublequote. Quoted doublequotes must be prefixed by a backslash (\e).
+Quoted strings always evaluate to exactly one word. For instance, ""
+evaluates to the empty word.
+.IP
+* The \ea, \eb, \et, \en, \ev, \ef, and \er sequences are recognized in quoted
+.IP
+strings, and are converted to the ASCII numbers 7, 8, 9, 10, 11, 12
+and 13 respectively.
+.IP
+* Inside a quoted string, backslashed newlines disappear completely.
+* \e0xab sequences are recognized in quoted strings and evaluate to ASCII
+.IP
+hexadecimal number ab.
+.IP
+* \e0abc sequences are recognized in quoted strings and evaluate to ASCII
+.IP
+octal number abc.
+.IP
+* \eabc sequences are recognized in quoted strings and evaluate to ASCII
+.IP
+decimal number abc. a must not be zero.
+.IP
+* A comment starts with a # and ends with the line. Comments are not
+.IP
+recognized inside quoted strings.
+.IP
+* Anything else is an unquoted string, that can evaluate to zero or more
+.IP
+words.
+.IP
+* Any character can be escaped in unquoted strings by prepending it with
+.IP
+a backslash. It works the same way 

Bug#923965: unblock: libbpp-seq/2.4.1-3

[Andreas Tille]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Please unblock package libbpp-seq


 libbpp-seq (2.4.1-3) unstable; urgency=medium
 .
   * Rebuild for new version of gcc to fix symbols
 Closes: #923954
   * Standards-Version: 4.3.0


unblock libbpp-seq/2.4.1-3

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

Kernel: Linux 4.9.0-6-amd64 (SMP w/1 CPU core)
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)
diff -Nru libbpp-seq-2.4.1/debian/changelog libbpp-seq-2.4.1/debian/changelog
--- libbpp-seq-2.4.1/debian/changelog   2018-12-03 08:15:45.0 +0100
+++ libbpp-seq-2.4.1/debian/changelog   2019-03-07 18:56:16.0 +0100
@@ -1,3 +1,11 @@
+libbpp-seq (2.4.1-3) unstable; urgency=medium
+
+  * Rebuild for new version of gcc to fix symbols
+Closes: #923954
+  * Standards-Version: 4.3.0
+
+ -- Andreas Tille   Thu, 07 Mar 2019 18:56:16 +0100
+
 libbpp-seq (2.4.1-2) unstable; urgency=medium
 
   [ Jelmer Vernooij ]
diff -Nru libbpp-seq-2.4.1/debian/control libbpp-seq-2.4.1/debian/control
--- libbpp-seq-2.4.1/debian/control 2018-12-03 08:15:45.0 +0100
+++ libbpp-seq-2.4.1/debian/control 2019-03-07 18:56:16.0 +0100
@@ -8,7 +8,7 @@
cmake,
d-shlibs (>= 0.80),
libbpp-core-dev (>= 2.4.1)
-Standards-Version: 4.2.1
+Standards-Version: 4.3.0
 Vcs-Browser: https://salsa.debian.org/med-team/libbpp-seq
 Vcs-Git: https://salsa.debian.org/med-team/libbpp-seq.git
 Homepage: http://biopp.univ-montp2.fr/wiki/index.php/Main_Page
diff -Nru libbpp-seq-2.4.1/debian/libbpp-seq12.symbols 
libbpp-seq-2.4.1/debian/libbpp-seq12.symbols
--- libbpp-seq-2.4.1/debian/libbpp-seq12.symbols2018-12-03 
08:15:45.0 +0100
+++ libbpp-seq-2.4.1/debian/libbpp-seq12.symbols2019-03-07 
18:56:16.0 +0100
@@ -328,7 +328,6 @@
  
_ZN3bpp16AbstractAlphabet8getStateERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEE@Base
 2.4.1
  _ZN3bpp16AbstractAlphabet8getStateEi@Base 2.4.1
  _ZN3bpp16AbstractAlphabet8setStateEmPNS_13AlphabetStateE@Base 2.4.1
- _ZN3bpp16AbstractAlphabetC2ERKS0_@Base 2.4.1
  _ZN3bpp16AbstractAlphabetD2Ev@Base 2.4.1
  _ZN3bpp16AbstractCoreSite11setPositionEi@Base 2.4.1
  
_ZN3bpp16ApplicationTools12getParameterIjEET_RKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEERKSt3mapIS8_S8_St4lessIS8_ESaISt4pairIS9_S8_EEES2_SA_bi@Base
 2.4.1
@@ -1710,13 +1709,13 @@
  _ZNKSt5ctypeIcE8do_widenEc@Base 2.4.1
  
_ZNKSt8_Rb_treeINSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEESt4pairIKS5_S5_ESt10_Select1stIS8_ESt4lessIS5_ESaIS8_EE4findERS7_@Base
 2.4.1
  
_ZNKSt8_Rb_treeINSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEESt4pairIKS5_mESt10_Select1stIS8_ESt4lessIS5_ESaIS8_EE4findERS7_@Base
 2.4.1
+ 
_ZNSt11_Deque_baseINSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEESaIS5_EED1Ev@Base
 2.4.1
+ 
_ZNSt11_Deque_baseINSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEESaIS5_EED2Ev@Base
 2.4.1
  _ZNSt11_Deque_baseIiSaIiEE17_M_initialize_mapEm@Base 2.4.1
  _ZNSt11_Deque_baseIiSaIiEED1Ev@Base 2.4.1
  _ZNSt11_Deque_baseIiSaIiEED2Ev@Base 2.4.1
  _ZNSt13_Bvector_baseISaIbEE13_M_deallocateEv@Base 2.4.1
  
_ZNSt3mapINSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEES5_St4lessIS5_ESaISt4pairIKS5_S5_EEEixEOS5_@Base
 2.4.1
- 
_ZNSt3mapINSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEES5_St4lessIS5_ESaISt4pairIKS5_S5_EEEixERS9_@Base
 2.4.1
- 
_ZNSt3mapINSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEESt6vectorImSaImEESt4lessIS5_ESaISt4pairIKS5_S8_EEEixERSC_@Base
 2.4.1
  _ZNSt3mapIiiSt4lessIiESaISt4pairIKiiEEEixEOi@Base 2.4.1
  
_ZNSt5dequeINSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEESaIS5_EED1Ev@Base
 2.4.1
  
_ZNSt5dequeINSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEESaIS5_EED2Ev@Base
 2.4.1
@@ -1813,7 +1812,6 @@
  
_ZNSt8_Rb_treeINSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEESt4pairIKS5_PN3bpp8SequenceEESt10_Select1stISB_ESt4lessIS5_ESaISB_EE11equal_rangeERS7_@Base
 2.4.1
  
_ZNSt8_Rb_treeINSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEESt4pairIKS5_PN3bpp8SequenceEESt10_Select1stISB_ESt4lessIS5_ESaISB_EE12_M_erase_auxESt23_Rb_tree_const_iteratorISB_E@Base
 2.4.1
  
_ZNSt8_Rb_treeINSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEESt4pairIKS5_PN3bpp8SequenceEESt10_Select1stISB_ESt4lessIS5_ESaISB_EE14_M_insert_nodeEPSt18_Rb_tree_node_baseSJ_PSt13_Rb_tree_nodeISB_E@Base
 2.4.1
- 
(optional)_ZNSt8_Rb_treeINSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEESt4pairIKS5_PN3bpp8SequenceEESt10_Select1stISB_ESt4lessIS5_ESaISB_EE16_M_insert_uniqueIS6_IS5_SA_EEES6_ISt17_Rb_tree_iteratorISB_EbEOT_@Base
 2.4.1
  

Bug#923963: dnsmasq: listen-address option is ignored, always listens on 0.0.0.0:domain / [::]:domain

[Andreas Metzler]

On 2019-03-07 Andreas Metzler  wrote:
> Package: dnsmasq
> Version: 2.80-1
> Severity: important

> Hello,

> the listen-address option is ignored:

> root@argenau:/etc# service dnsmasq stop
> root@argenau:/etc# netstat -ul
> Active Internet connections (only servers)
> Proto Recv-Q Send-Q Local Address   Foreign Address State
> root@argenau:/etc# dnsmasq  --listen-address=127.0.0.1 
> --resolv-file=/etc/resolv.conf.static --no-daemon 
[...]

Looks like I need to set 

interface=
bind-interfaces

instead of listen-address to limit listening on 127.0.0.1/:i:

cu Andreas

Bug#923213: squid: Please disable the "Test apparmor" autopkgtest

[Paul Gevers]

Luigi,

On 07-03-2019 17:51, Luigi Gangitano wrote:
> 4.6-2 has just been uploaded with a fix for 923213. I really appreciate
> the opportunity to let it in Buster.

Please file an unblock bug. I have one question about the proposed
solution: you preinst doesn't honor local changes if the package is
uninstalled (but not purged) and installed again AFAICT. I stopped
reviewing there and like others to be able to chime in as well.

Personally I rather have just the test disabled or ignored. I feel
slightly uncomfortable with the proposed changes.

Paul



signature.asc
Description: OpenPGP digital signature

Bug#922120: annoying messages from systemd.unit

[Daniel Kahn Gillmor]

Control: tags 922120 + moreinfo

Hi Daniel--

On Tue 2019-02-12 11:54:55 +0100, Daniel Baumann wrote:
> thank you so much for maintaining knot-resolver, it's wonderful.

Glad you find it useful!

> Unfortunately, whenever *any* service is reladed on my system (vanilla
> debian with 'apt install knot-resolver'), I always get the following
> message:
>
>   Failed to get properties: Unit name kresd-control@.socket is neither a
>   valid invocation ID nor unit name.
>
> It would be nice if this could be fixed.

I'm trying to replicate this, and having difficulty.  Where exactly do
you see this message? on the terminal?  in the journal?  on the console?

You say "whenever *any* service is reladed" -- i assume that means, for
example: "systemctl reload ssh"

but when i do that i don't see any such message in any of these places:

  * the terminal where i run "systemctl reload ssh"
  * anywhere in journald
  * the system console

Can you help me replicate the problem?

Can you also show me the output of this command on your affected system:

   find /etc/systemd -iname 'kres*' -ls

Thanks,

--dkg


signature.asc
Description: PGP signature

Bug#922614: mini-buildd: Doesn't actually call sbuild with --jobs option

[Stephan Sürken]

Hi Magnus,

On Mon, 2019-02-18 at 13:59 +0100, Magnus Holmgren wrote:
> Package: python-mini-buildd
> Version: 1.0.36~bpo9+1
> 
> The Change daemon page states about the Sbuild jobs option: "Degree of 
> parallelism per build (via sbuild's '--jobs' option)." but the option is only 
> passed via the DEB_BUILD_OPTIONS variable, not --jobs, meaning that no -j 
> option will be added to the dpkg-buildpackage command line nor MAKEFLAGS. 
> Packages using dh with --parallel or compat >= 10 will automatically use the 
> parallel option in DEB_BUILD_OPTIONS, but not other packages that don't parse 
> DEB_BUILD_OPTIONS by hand.
> 
> Perhaps it's actually not desirable to always set -j in MAKEFLAGS but in that 
> case the documentation should be changed to match reality.

hmm yes, you are completely right. And also I think --jobs is the
better choice here.

I did some research ;), and it seems I changed it from --jobs to env
back in 2013 due to <=etch compatibility issues:

commit 355893eb0202f507246569a0b922e89474f27369
Author: Stephan Sürken 
Date:   Thu Jan 3 17:02:26 2013 +0100

builder: Use env. DEB_BUILD_OPTIONS='parallel=N' instead of 'd-p -jN' 
(Fixes: Builds for <= etch).

Will fix the doc in stable (1.0.x), and switch to '--jobs' again in current 
development.

Thanks!

Stephan

Bug#921945: sylpheed: Sylpheed uses the wrong application for opening pdf files

[Jean-Marc]

Thu, 7 Mar 2019 10:15:39 +0100
Ricardo Mones  écrivait :

> control: forwarded -1 https://sylpheed.sraoss.jp/redmine/issues/312
> control: severity -1 wishlist
> 
> Hi Jean-Marc,

Hi Ricardo,

> On Sun, Feb 10, 2019 at 01:57:28PM +0100, Jean-Marc wrote:
> > Package: sylpheed
> > Version: 3.7.0-4
> > Severity: normal
> > 
> > Dear Maintainer,
> > 
> > Sylpheed does not take into account the XDG default application the
> > desktop environment should use for opening files of a specific
> > MIME/Filetype.
> > 
> > Example: . when I tried to open a PDF file, Sylpheed uses gimp to open
> > the file.
> > 
> > Gimp is the first application in the
> > /usr/share/applications/mimeinfo.cache entry defining which
> > application(s) can read/open/associate with pdf files.
> > 
> > $ grep application/pdf  /usr/share/applications/mimeinfo.cache
> > application/pdf=gimp.desktop;inkscape.desktop;org.gnome.Evince.desktop;libreoffice-draw.desktop;
> > 
> > It should use my desktop's default application from Debian Gnome
> > default spec in /usr/share/applications/gnome-mimeapps.list to open
> > PDF files.
> 
> AFAIK Sylpheed is not a GNOME application, is just a GTK+2 application.

I am speaking about taking into account the Cross-Desktop Group (XDG) spec.

I had mentionned the file containing the Debian default values for my desktop 
as example.

It has nothing to do with Gnome in particular.

See https://www.freedesktop.org/ for more info.
. Association between MIME types and applications
https://specifications.freedesktop.org/mime-apps-spec/latest/
or in this one-page:
https://specifications.freedesktop.org/mime-apps-spec/mime-apps-spec-1.0.1.html

> Anyway I'm forwarding this upstream, just in case they may consider
> worth to implement it for a better user experience.

Thank you.

> thanks for reporting,
> -- 
>   Ricardo Mones 


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


pgpR9g_iS3NCv.pgp
Description: PGP signature

Bug#923963: dnsmasq: listen-address option is ignored, always listens on 0.0.0.0:domain / [::]:domain

[Andreas Metzler]

Package: dnsmasq
Version: 2.80-1
Severity: important

Hello,

the listen-address option is ignored:

root@argenau:/etc# service dnsmasq stop
root@argenau:/etc# netstat -ul
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address   Foreign Address State
root@argenau:/etc# dnsmasq  --listen-address=127.0.0.1 
--resolv-file=/etc/resolv.conf.static --no-daemon &
[1] 2423
root@argenau:/etc# dnsmasq: started, version 2.80 cachesize 150
dnsmasq: compile time options: IPv6 GNU-getopt DBus i18n IDN DHCP DHCPv6 no-Lua 
TFTP conntrack ipset auth DNSSEC loop-detect inotify dumpfile
dnsmasq: reading /etc/resolv.conf.static
dnsmasq: using nameserver 195.3.96.67#53
dnsmasq: using nameserver 213.33.98.136#53
dnsmasq: read /etc/hosts - 8 addresses
root@argenau:/etc# netstat -ul
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address   Foreign Address State  
udp0  0 0.0.0.0:domain  0.0.0.0:*  
udp6   0  0 [::]:domain [::]:* 


cu Andreas
-- System Information:
Debian Release: buster/sid
  APT prefers testing-debug
  APT policy: (500, 'testing-debug'), (500, 'testing'), (1, 'experimental')
Architecture: amd64 (x86_64)

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

Versions of packages dnsmasq depends on:
ii  dnsmasq-base [dnsmasq-base]  2.80-1
ii  init-system-helpers  1.56+nmu1
ii  lsb-base 10.2018112800
ii  netbase  5.6

dnsmasq recommends no packages.

Versions of packages dnsmasq suggests:
pn  resolvconf  

Bug#923962: tigervnc-standalone-server: crashes on ARM after VncAuth

[Fabian Pietsch]

Package: tigervnc-standalone-server
Version: 1.9.0+dfsg-3
Severity: important

Dear Maintainer,

on our Raspberry Pi 3B+ test system, with an arm64 buster preview
from https://wiki.debian.org/RaspberryPi3 ,
Xtigervnc crashes reproducibly after VncAuth,
with the following ~/.vnc/rpi3:1.log output excerpt:

| [...]
|
| Xvnc TigerVNC 1.9.0 - built Dec  1 2018 21:51:29
| Copyright (C) 1999-2018 TigerVNC Team and many others (see README.rst)
| See http://www.tigervnc.org for information on TigerVNC.
| Underlying X server release 12003000, The X.Org Foundation
|
|
| Thu Mar  7 17:19:57 2019
|  vncext:  VNC extension running!
|  vncext:  Listening for VNC connections on local interface(s), port 5901
|  vncext:  created VNC server for screen 0
|
| Thu Mar  7 17:20:25 2019
|  Connections: accepted: [::1]::49280
|  SConnection: Client needs protocol version 3.8
|  SConnection: Client requests security type VncAuth(2)
| terminate called after throwing an instance of 'rdr::Exception'
| terminate called recursively
| (EE)
| (EE) Backtrace:
| (EE) 0: /usr/bin/Xtigervnc (OsLookupColor+0x1a8) [0xb38169d0]
| (EE) unw_get_proc_info failed: no unwind info found [-10]
| (EE)
| (EE)
| Fatal server error:
| (EE) Caught signal 6 (Aborted). Server aborting
| (EE)
| XIO:  fatal IO error 11 (Resource temporarily unavailable) on X server ":1"
|   after 175 requests (175 known processed) with 0 events remaining.
| Killing Xtigervnc process ID 1204... which was already dead
| Cleaning stale pidfile '/home/vncuser/.vnc/rpi3:1.pid'!

(The test Xtigervnc is accessed via an SSH port forwarding,
tested with both RealVNC and TightVNC, running on Windows.)


Xtigervnc works fine (on the same RPi 3B+) in Raspbian stretch,
but crashes in the same way after upgrading the package
to Raspbian buster.

Xtigervnc also works fine in a Debian buster container
on a different system/architecture (amd64).

Xtigervnc also works fine with SecurityTypes set to None,
skipping the authentication step entirely.

Note that Xtigervnc also crashes on our test system
(in a different way) with SecurityTypes set to Plain or TLSPlain.
This bug report is made against the general use case, though.

Please advise on the next steps to track down what is happening.
More logs could be provided, the system is not set up for development,
yet, though.


Here is the /etc/vnc.conf and ~/.vnc/vnc.conf essence:

| $ grep -v -E '^(#|$)' /etc/vnc.conf
| $fontPath = undef;
| $vncStartup = "/etc/X11/Xvnc-session";
| $geometry = "1900x1200";
| 1;
| $

| $ grep -v -E '^(#|$)' ~/.vnc/vnc.conf
| $SecurityTypes = "VncAuth";
| 1;
| $


-- System Information:
Debian Release: buster/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: arm64 (aarch64)

Kernel: Linux 4.19.0-2-arm64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_CRAP
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C.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 tigervnc-standalone-server depends on:
ii  libaudit1   1:2.8.4-2
ii  libbsd0 0.9.1-1
ii  libc6   2.28-7
ii  libfile-readbackwards-perl  1.05-2
ii  libgcc1 1:8.2.0-21
ii  libgcrypt20 1.8.4-5
ii  libgl1  1.1.0-1
ii  libgnutls30 3.6.6-2
ii  libjpeg62-turbo 1:1.5.2-2+b1
ii  libpam0g1.3.1-5
ii  libpixman-1-0   0.36.0-1
ii  libselinux1 2.8-1+b1
ii  libstdc++6  8.2.0-21
ii  libsystemd0 240-6
ii  libunwind8  1.2.1-8
ii  libx11-62:1.6.7-1
ii  libxau6 1:1.0.8-1+b2
ii  libxdmcp6   1:1.1.2-3
ii  libxfont2   1:2.0.3-1
ii  libxshmfence1   1.3-1
ii  perl5.28.1-4
ii  x11-xkb-utils   7.7+4
ii  xauth   1:1.0.10-1
ii  xkb-data2.26-2
ii  zlib1g  1:1.2.11.dfsg-1

Versions of packages tigervnc-standalone-server recommends:
ii  libgl1-mesa-dri18.3.2-1
ii  tigervnc-common1.9.0+dfsg-3
ii  x11-xserver-utils  7.7+8
ii  xfonts-base1:1.0.4+nmu1

Versions of packages tigervnc-standalone-server suggests:
pn  xfonts-100dpi | xfonts-75dpi  
ii  xfonts-scalable   1:1.0.3-1.1

-- no debconf information

Bug#923961: newsbeuter: causes 'autoremove' of newsboat

[Boruch Baum]

Package: newsbeuter
Version: 2.9-8+b1
Severity: normal

Dear Maintainer,

I recently observed that apt-get was notifying me that performing an
'apt-get autoremove' would de-install package 'newsboat' - which would
be quite undesirable for me.

What seems to have occurred is that package newsbeuter 'recommends' the
actively-maintained package newsboat, and so when after transitioning to the
newer package I removed the unmaintained package newsbeuter, apt flagged
the package newsboat for auto-removal.

Maybe change newsboat to a 'suggests'? Maybe just drop newsbeuter and
turn it into a transitional package for newsboat? Maybe change newsboat
to a 'suggests' along with an apt message that the upstream package is
not being maintained, but has been forked to newsboat?

-- System Information:
Distributor ID: Devuan
Description:Devuan GNU/Linux 2.0.0 (ascii)
Release:2.0.0
Codename:   ascii
Architecture: x86_64

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


-- no debconf information

-- 
hkp://keys.gnupg.net
CA45 09B5 5351 7C11 A9D1  7286 0036 9E45 1595 8BC0

Bug#923213: squid: Please disable the "Test apparmor" autopkgtest

[Luigi Gangitano]

Hi Paul,

> On Mon, 25 Feb 2019 07:31:42 +0100 intrig...@debian.org 
>  wrote:
>> If I got it right, on Debian we don't ship
>> /etc/apparmor.d/usr.sbin.squid, so none of the tests in the
>> test_zz_apparmor function are meaningful in this context.
>> So I think this entire test case should be skipped on Debian.
> 
> I have decided to accept this regression to migrate to buster for
> apparmor to migrate to buster. Targeted fixes to fix the squid
> autopkgtest can be reason for an unblock.

4.6-2 has just been uploaded with a fix for 923213. I really appreciate the 
opportunity to let it in Buster.

Regards,

L

--
Luigi Gangitano -- mailto:lu...@debian.org>> -- 
mailto:gangit...@lugroma3.org>>
GPG: 1024D/924C0C26: 12F8 9C03 89D3 DB4A 9972  C24A F19B A618 924C 0C26
GPG: 4096R/2BA97CED: 8D48 5A35 FF1E 6EB7 90E5  0F6D 0284 F20C 2BA9 7CED

Bug#922675: segfault on dir chroot prepare (in sqlite)

[Stephan Sürken]

Hi Marc,

On Tue, 2019-02-19 at 11:34 +0100, Marc Haber wrote:
> Package: mini-buildd
> Version: 1.0.36
> Severity: important
> 
> Hi,
> 
> I log in to my mini-buildd instance, start configuring, call up the
> Dir
> chroots, mark one, click on "prepare". The browser immediately
> returns a
> "connection reset", no mini-buildd process is there any more, and the
> syslog shows:
> 
> Feb 19 11:27:10 spinturn kernel: mini-buildd[1368]: segfault at 8 ip
> 7f25f375ef91 sp 7f25daff88f0 error 4 in
> libsqlite3.so.0.8.6[7f25f36f8000+da000]

I just ran the whole testsuite (and also did some manual chroot
prepares) on the 1.0.x branch with current sid/amd64 -- could not
produce the problem.

Same libsqlite afaics (/usr/lib/x86_64-linux-gnu/libsqlite3.so.0.8.6).

However, I hope this

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=923038

is the same issue; then it might have been fixed in sqlite3 3.27.2-1
(w/o updating the so version)...

Could you recheck?

Thx!

S

Bug#923953: Acknowledgement (unblock: giada/0.15.2+ds1-2)

[Debian/GNU]

Control: block -1 by 923952
Thanks

Since giada currently has two causes for FTBFSing, unblocking this
package only makes sense if  juce/5.4.1+really5.4.1~repack-3 has been
unblocked before.

fgmasdr
IOhannes

Bug#922416: cache.commit() doesn't release the archives lock

[Julian Andres Klode]

On Thu, Mar 07, 2019 at 04:42:04PM +, Marga Manterola wrote:
> Any news here?
> 
> I thought my reproduction case was good enough to show what the problem was.

Sorry, yes. I was at a work sprint on your previous email, and then forgot
about it later! I'll try to solve it this week.

> 
> In the meantime, I've solved my problem by explicitly closing the lock after 
> the call to commit, but I think this shouldn't be 
> needed.

It will probably also fail afterwards :-)

FWIW, one thing about your reproducer is that you should be keeping an
apt_pkg.SystemLock() right from the start until the program ends, so p-a
keeps the frontend lock all the time, preventing race conditions.

(unless you call apt_pkg.init_system() again in which case things
gets screwed up, as it owns the lock, so you'll have to unlock, re-init
and then lock again...).


-- 
debian developer - deb.li/jak | jak-linux.org - free software dev
ubuntu core developer  i speak de, en

Bug#923960: udisks2 frantic security (ata-smart-update, suspend when inactive)

[siyia]

Package: udisks2
Version: 2.8.1-4
Severity: normal
Tags: patch

Dear Maintainer,

Hello, when psensors requests the lib-ata-smart-update action to update for
sudo users, it brings the user a password prompt,same happens for suspend when
inactive.I expected no password prompt for sudo users concerning the above
actions.

To remedy the situation i created 2 .pkla files in
/etc/polkit-1/localauthority/10-vendor.d/ :

[New sudo Permissions for udisks2]
Identity=unix-group:sudo
Action=org.freedesktop.login1.suspend
ResultAny=yes
ResultInactive=yes
ResultActive=yes


[New sudo Permissions for udisks2]
Identity=unix-group:sudo
Action=org.freedesktop.udisks2.ata-smart-update
ResultAny=yes
ResultInactive=yes
ResultActive=yes




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

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

Versions of packages udisks2 depends on:
ii  dbus   1.12.12-1
ii  libacl12.2.52-5
ii  libatasmart4   0.19-5
ii  libblockdev-fs22.20-6
ii  libblockdev-loop2  2.20-6
ii  libblockdev-part2  2.20-6
ii  libblockdev-swap2  2.20-6
ii  libblockdev-utils2 2.20-6
ii  libblockdev2   2.20-6
ii  libc6  2.28-7
ii  libglib2.0-0   2.58.3-1
ii  libgudev-1.0-0 232-2
ii  libmount1  2.33.1-0.1
ii  libpam-systemd 241-1
ii  libpolkit-agent-1-00.105-25
ii  libpolkit-gobject-1-0  0.105-25
ii  libsystemd0241-1
ii  libudisks2-0   2.8.1-4
ii  parted 3.2-24
ii  udev   241-1

Versions of packages udisks2 recommends:
ii  dosfstools   4.1-2
ii  e2fsprogs1.44.5-1
ii  eject2.1.5+deb1+cvs20081104-13.2
ii  exfat-utils  1.3.0-1
ii  libblockdev-crypto2  2.20-6
ii  ntfs-3g  1:2017.3.23AR.3-2
ii  policykit-1  0.105-25

Versions of packages udisks2 suggests:
ii  btrfs-progs  4.20.1-2
pn  f2fs-tools   
pn  libblockdev-mdraid2  
pn  mdadm
pn  nilfs-tools  
pn  reiserfsprogs
pn  udftools 
pn  udisks2-bcache   
pn  udisks2-btrfs
pn  udisks2-lvm2 
pn  udisks2-vdo  
pn  udisks2-zram 
pn  xfsprogs 

-- no debconf information

Bug#923810: ITP: ruby-sassc -- Use libsass with Ruby

[Manas Kashyap]

sure , i will thanks for the guidance.

On Tue, Mar 5, 2019 at 10:57 PM Jonas Smedegaard  wrote:

> Quoting Manas Kashyap (2019-03-05 17:50:50)
> > Package: wnpp
> > Severity: wishlist
> > Owner: Manas Kashyap 
> > X-Debbugs-CC: debian-de...@lists.debian.org,
> debian-r...@lists.debian.org
> >
> > * Package name: ruby-sassc
> >   Version : 2.0.1
> >   Upstream Author : Ryan Boland.
> > * URL : https://github.com/sass/sassc-ruby
> > * License : MIT
> >   Programming Lang: Ruby
> >   Description : It combines the speed of libsass, the Sass C
> > implementation, with the ease of use of the original Ruby Sass library. .
> >  This library utilizes libsass to allow you to compile SCSS or SASS
> syntax
> > to CSS
>
> Great!
>
> Please consider joining the Sass team, and maintain it there :-)
>
> https://tracker.debian.org/teams/sass/
>
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-sass-devel
>
>
>  - Jonas
>
> --
>  * Jonas Smedegaard - idealist & Internet-arkitekt
>  * Tlf.: +45 40843136  Website: http://dr.jones.dk/
>
>  [x] quote me freely  [ ] ask before reusing  [ ] keep private
>

Bug#923784: update-ca-certificates: corrupts ca-certificates.crt on full root file system

[Michael Shuler]

On 3/5/19 11:47 AM, Arthur de Jong wrote:
> I have created a merge request in Salsa for this:
> https://salsa.debian.org/debian/ca-certificates/merge_requests/2

Thank for the MR. I'll take a look.

-- 
Kind regards,
Michael

Bug#923959: afflib: FTBFS (dh_makeshlibs fails)

[Santiago Vila]

Package: src:afflib
Version: 3.7.17-4
Severity: serious
Tags: ftbfs

Dear maintainer:

I tried to build this package in buster but it failed:


[...]
 debian/rules build-arch
dh build-arch --with autoreconf
   dh_update_autotools_config -a
   dh_autoreconf -a
libtoolize: putting auxiliary files in '.'.
libtoolize: copying file './ltmain.sh'
libtoolize: putting macros in AC_CONFIG_MACRO_DIRS, 'm4'.
libtoolize: copying file 'm4/libtool.m4'
libtoolize: copying file 'm4/ltoptions.m4'
libtoolize: copying file 'm4/ltsugar.m4'
libtoolize: copying file 'm4/ltversion.m4'
libtoolize: copying file 'm4/lt~obsolete.m4'
configure.ac:20: installing './compile'
configure.ac:26: installing './config.guess'

[... snipped ...]

make[2]: Leaving directory '/<>'
chrpath -d debian/tmp/usr/bin/*
set -e; for file in `ls debian/tmp/usr/lib/*/*.la`; do \
sed -i "/dependency_libs/ s/'.*'/''/" $file ; \
done
make[1]: Leaving directory '/<>'
   dh_install -a
   dh_installdocs -a
   dh_installchangelogs -a
   dh_installman -a
   dh_perl -a
   dh_link -a
   dh_strip_nondeterminism -a
   dh_compress -a
   dh_fixperms -a
   dh_missing -a
   dh_strip -a
   debian/rules override_dh_makeshlibs
make[1]: Entering directory '/<>'
dh_makeshlibs -- -v3.7.17
dpkg-gensymbols: warning: some new symbols appeared in the symbols file: see 
diff output below
dpkg-gensymbols: error: some symbols or patterns disappeared in the symbols 
file: see diff output below
dpkg-gensymbols: warning: debian/libafflib0v5/DEBIAN/symbols doesn't match 
completely debian/libafflib0v5.symbols
--- debian/libafflib0v5.symbols (libafflib0v5_3.7.17_amd64)
+++ dpkg-gensymbolsSIEKs1   2019-03-07 14:37:18.703845582 +
@@ -373,9 +373,13 @@
  
(optional)_ZNSt6vectorIPN2s36BucketESaIS2_EE19_M_emplace_back_auxIJS2_EEEvDpOT_@Base
 3.7.17
  
_ZNSt6vectorIPN2s38ContentsESaIS2_EE17_M_realloc_insertIJS2_EEEvN9__gnu_cxx17__normal_iteratorIPS2_S4_EEDpOT_@Base
 3.7.16
  
(optional)_ZNSt6vectorIPN2s38ContentsESaIS2_EE19_M_emplace_back_auxIJS2_EEEvDpOT_@Base
 3.7.17
- 
_ZNSt8_Rb_treeINSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEES5_St9_IdentityIS5_ESt4lessIS5_ESaIS5_EE16_M_insert_uniqueIS5_EESt4pairISt17_Rb_tree_iteratorIS5_EbEOT_@Base
 3.7.16
+ 
_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE12_M_constructIPKcEEvT_S8_St20forward_iterator_tag@Base
 3.7.17
+ 
_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE12_M_constructIPcEEvT_S7_St20forward_iterator_tag@Base
 3.7.17
+#MISSING: 3.7.17# 
_ZNSt8_Rb_treeINSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEES5_St9_IdentityIS5_ESt4lessIS5_ESaIS5_EE16_M_insert_uniqueIS5_EESt4pairISt17_Rb_tree_iteratorIS5_EbEOT_@Base
 3.7.16
  
_ZNSt8_Rb_treeINSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEES5_St9_IdentityIS5_ESt4lessIS5_ESaIS5_EE8_M_eraseEPSt13_Rb_tree_nodeIS5_E@Base
 3.7.16
  
_ZNSt8_Rb_treeINSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEESt4pairIKS5_S5_ESt10_Select1stIS8_ESt4lessIS5_ESaIS8_EE14_M_insert_nodeEPSt18_Rb_tree_node_baseSG_PSt13_Rb_tree_nodeIS8_E@Base
 3.7.16
+ 
_ZNSt8_Rb_treeINSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEESt4pairIKS5_S5_ESt10_Select1stIS8_ESt4lessIS5_ESaIS8_EE22_M_emplace_hint_uniqueIJRKSt21piecewise_construct_tSt5tupleIJOS5_EESJ_IJESt17_Rb_tree_iteratorIS8_ESt23_Rb_tree_const_iteratorIS8_EDpOT_@Base
 3.7.17
+ 
_ZNSt8_Rb_treeINSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEESt4pairIKS5_S5_ESt10_Select1stIS8_ESt4lessIS5_ESaIS8_EE22_M_emplace_hint_uniqueIJRKSt21piecewise_construct_tSt5tupleIJRS7_EESJ_IJESt17_Rb_tree_iteratorIS8_ESt23_Rb_tree_const_iteratorIS8_EDpOT_@Base
 3.7.17
  
_ZNSt8_Rb_treeINSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEESt4pairIKS5_S5_ESt10_Select1stIS8_ESt4lessIS5_ESaIS8_EE24_M_get_insert_unique_posERS7_@Base
 3.7.16
  
_ZNSt8_Rb_treeINSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEESt4pairIKS5_S5_ESt10_Select1stIS8_ESt4lessIS5_ESaIS8_EE29_M_get_insert_hint_unique_posESt23_Rb_tree_const_iteratorIS8_ERS7_@Base
 3.7.16
  
_ZNSt8_Rb_treeINSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEESt4pairIKS5_S5_ESt10_Select1stIS8_ESt4lessIS5_ESaIS8_EE8_M_eraseEPSt13_Rb_tree_nodeIS8_E@Base
 3.7.16
dh_makeshlibs: failing due to earlier errors
make[1]: *** [debian/rules:27: override_dh_makeshlibs] Error 2
make[1]: Leaving directory '/<>'
make: *** [debian/rules:9: binary-arch] Error 2
dpkg-buildpackage: error: fakeroot debian/rules binary-arch subprocess returned 
exit status 2


(The above is just how the build ends and not necessarily the most relevant 
part)

The build was made in my autobuilder with "dpkg-buildpackage -B"
and it also fails here:

https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/afflib.html

where you can get a full build log if you need it.

If this is really a bug in one of the build-depends, please use reassign and 
affects,
so that this is still