Bug#914370: cups-daemon: AppArmor profile allows cupsd to create setuid binaries under /etc

[debbug]

Package: cups-daemon
Version: 2.3~b5-2
Severity: normal

Dear Maintainer,

The AppArmor profile supplied with cupsd isn't much use against local
attackers, as it allows cupsd to create setuid binaries at paths it
can write to (e.g. under /etc/cups).  Since cupsd is run as root by
default, these binaries can be setuid root.

In the following example, I replace cupsd with a shell and run it as
root to test the confinement.  As you can see, AppArmor stops the
process writing to an unlisted path in /etc, but does allow it to
write and and set permissions under /etc/cups.

# mv -i /usr/sbin/cupsd /usr/sbin/cupsd.bak
# cp /bin/sh /usr/sbin/cupsd
# PS1='confined# ' /usr/sbin/cupsd
confined# cp /bin/true /etc
cp: cannot create regular file '/etc/true': Permission denied
confined# cp /bin/true /etc/cups
confined# chmod 4555 /etc/cups/true
confined# exit
# ls -l /etc/cups/true
-r-sr-xr-x 1 root root 35424 Nov 22 14:16 /etc/cups/true

(Creating a setuid binary at /etc/printcap also works, as does
removing any existing symlink there.)

In default installations /etc is not on a nosuid mount, so provided
that they have a suitable exploit, local attackers who are unconfined
but non-root can use cupsd to create a setuid binary, then run the
binary themselves to gain unconfined root privileges.


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

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

Versions of packages cups-daemon depends on:
ii  adduser   3.118
ii  bc1.07.1-2+b1
ii  libavahi-client3  0.7-4+b1
ii  libavahi-common3  0.7-4+b1
ii  libc6 2.27-8
ii  libcups2  2.3~b5-2
ii  libcupsmime1  2.3~b5-2
ii  libdbus-1-3   1.12.10-1
ii  libgssapi-krb5-2  1.16.1-1
ii  libpam0g  1.1.8-3.8
ii  libpaper1 1.1.24+nmu5
ii  libsystemd0   239-13
ii  lsb-base  9.20170808
ii  procps2:3.3.15-2
ii  ssl-cert  1.0.39

Versions of packages cups-daemon recommends:
ii  avahi-daemon  0.7-4+b1
ii  colord1.4.3-3+b1
ii  cups-browsed  1.21.3-3

Versions of packages cups-daemon suggests:
ii  cups   2.3~b5-2
ii  cups-bsd   2.3~b5-2
ii  cups-client2.3~b5-2
ii  cups-common2.3~b5-2
ii  cups-filters [foomatic-filters]1.21.3-3
pn  cups-pdf   
ii  cups-ppdc  2.2.9-2
ii  cups-server-common 2.3~b5-2
ii  foomatic-db-compressed-ppds [foomatic-db]  20180921-1
ii  ghostscript9.26~dfsg-1
pn  hplip  
ii  poppler-utils  0.69.0-2
ii  printer-driver-gutenprint  5.3.1-2
pn  printer-driver-hpcups  
pn  smbclient  
ii  udev   239-13

-- no debconf information

Bug#914303: mesa: [regression] Mesa 18.2.5 breaks Stellaris and Civilization VI for Radeon R9 380

[Ed Sweetman]

Same issues on the RX 480 using amdgpu.  Using my own build of
4.20-rc#, but otherwise the rest is debian unstable / experimental
pkgs and on Debian Unstable as the primary dist.


glxinfo snippet


OpenGL renderer string: AMD Radeon (TM) RX 480 Graphics (POLARIS10,
DRM 3.27.0, 4.20.0-rc1-csm, LLVM 7.0.1)
OpenGL core profile version string: 4.5 (Core Profile) Mesa 18.2.5


dmesg snippet

[drm] initializing kernel modesetting (POLARIS10 0x1002:0x67DF
0x1043:0x04FB 0xC7).
ATOM BIOS: 115-D000PIL-100
[3.951392] [drm] Found UVD firmware Version: 1.130 Family ID: 16
[3.952275] [drm] Found VCE firmware Version: 53.26 Binary ID: 3
[drm] Display Core initialized with v3.1.68!

[drm] Initialized amdgpu 3.27.0 20150101 for :0b:00.0 on minor 0


--

Package: mesa
Version: 18.2.5-2
Severity: important

Dear Maintainer,

Mesa 18.1.9 worked perfectly in my system to play Stellaris and
Civilization VI.

With the recent upgrade to 18.2.5-1 and 18.2.5-2, both games have very big
issues:
- Stellaris completely garbled start screen.
- Civilization VI only shows a white window.

My hardware is a Radeon R9 380.

82:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Tonga
PRO [Radeon R9 285/380] (rev f1)

This bug may be related to #914267, but I open a different issue since
the hardware mentioned is different.

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

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

Bug#907640: compiz: Migrating to compiz-reloaded?

[Samuel Thibault]

Hello,

Samuel Thibault, le jeu. 30 août 2018 17:26:27 +0200, a ecrit:
> The launchpad upstream for compiz has switched to light maintenance mode
> and will not make further development since Ubuntu has stopped using it.
> 
> How do people feel about switching to compiz-reloaded?
> 
> https://gitlab.com/compiz

No reaction, so we moved on :)

Compiz-reloaded 0.8.14 is currently in sid, and 0.8.16 is currently in
experimental, up for your testing :)

For debian-accessibility: a very interesting feature of 0.8.16 is the
ability of ezoom to track focus events, which makes it a very effective
screen magnifier.

Samuel

Bug#883245: Thunderbird Not Opening HTTP, HTTPS URLs With Vivaldi

[David Campbell]

 * Edit[1]
 * Report this post[2]
 * Quote[3]
#1[4] Post[5] by *caffinate[6]* » Thu Nov 22, 2018 12:00 pm


MK Linux 17.1 Thunderbird Version 52.9.1 64 Bit

One persistent problem I'm having is the inability of Thunderbird to
open http, https URLs in emails with the Vivaldi. I also had the same
problem with Chromium.
When I run Thunderbird in Safe Mode in a console and try to open a url
in Thunderbird email I get this message:
*** (thunderbird:961): WARNING **: Could not launch default application
for URI: Failed to execute child process "/usr/bin/vivaldi-stable"
(Permission denied)*
EDIT: When I try to open links from Evolution Email Client - works fine.*EDIT2: 
Problem Appears to Be Solved:*

Narrowed this down to some kind of permissions problem with
thunderbird:\Found this: https://bugs.debian.org/cgi-bin/bugrepo ... 
bug=883245[7]

.
I'm experiencing the same with the version that's currently in testing.However, 
I found a workaround: either install thunderbird/1:52.5.0-1 
from unstable, or disable the apparmor profile yourself:

*sudo ln -s /etc/apparmor.d/usr.bin.thunderbird /etc/apparmor.d/disable/
sudo apparmor_parser -R /etc/apparmor.d/usr.bin.thunderbird*
*Now Thunderbird URL links open correctly in Vivaldi*

Related bug is #882672.


Links:

  1. https://forum.mxlinux.org/posting.php?mode=edit=104=467920
  2. https://forum.mxlinux.org/app.php/post/467920/report
  3. https://forum.mxlinux.org/posting.php?mode=quote=104=467920
  4. https://forum.mxlinux.org/viewtopic.php?p=467920#p467920
  5. https://forum.mxlinux.org/viewtopic.php?p=467920#p467920
  6. https://forum.mxlinux.org/memberlist.php?mode=viewprofile=19985
  7. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=883245

Bug#914368: emacspeak-ss: Error on emacspeak-ss installation.

[Samuel Thibault]

Hello,

Zachary Kline, le jeu. 22 nov. 2018 09:37:57 -0800, a ecrit:
> apt installemacspeak-ss
> 
>* What was the outcome of this action?
> ERROR: emacspeak-ss is broken - called emacs-package-install as a new-style 
> add-on, but has no compat file.

I am not getting this. Could you run

dpkg -l \*emacs\*

so we know what flavors of emacs are installed on your system?

Samuel

Bug#914318: sleepyhead: new upstream release (v1.1)

[Sergio Durigan Junior]

On Wednesday, November 21 2018, Diederik de Haas wrote:

> Although there isn't a tag for it at 
> https://gitlab.com/sleepyhead/sleepyhead-code/ 
> if you look at master's version.h, it shows version 1.1.

Thanks for the report, I'll take care of this later today.

-- 
Sergio
GPG key ID: 237A 54B1 0287 28BF 00EF  31F4 D0EB 7628 65FC 5E36
Please send encrypted e-mail if possible
http://sergiodj.net/

Bug#914369: haskell-simple-templates: FTBFS with ghc-8.4

[Ilias Tsitsimpis]

Source: haskell-simple-templates
Version: 0.8.0.1-4
Severity: serious
Justification: fails to build from source (but built successfully in the past)

It should be patched to build with ghc-8.4.

-- 
Ilias

Bug#914368: emacspeak-ss: Error on emacspeak-ss installation.

[Zachary Kline]

Package: emacspeak-ss
Version: 1.12.1-8
Severity: normal

   * What led up to the situation?
I installed the emacspeak-ss package.

   * What exactly did you do (or not do) that was effective (or
 ineffective)?
apt installemacspeak-ss

   * What was the outcome of this action?
ERROR: emacspeak-ss is broken - called emacs-package-install as a new-style 
add-on, but has no compat file.

   * What outcome did you expect instead?
A clean install without obvious errors.



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

Kernel: Linux 4.18.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)
LSM: AppArmor: enabled

Versions of packages emacspeak-ss depends on:
ii  adduser3.118
ii  debconf [debconf-2.0]  1.5.69
ii  emacspeak  47.0+dfsg-5
ii  libc6  2.27-8
ii  perl   5.28.0-3
ii  tcl8.6.0+9
ii  tclx8.48.4.1-2

emacspeak-ss recommends no packages.

emacspeak-ss suggests no packages.

-- debconf information:
  shared/emacspeak/invaliduser:
* shared/emacspeak/port: none
  shared/emacspeak/invalidport:
  shared/emacspeak/tcl: tcl
* shared/emacspeak/device: espeak
  shared/emacspeak/fake:
  shared/emacspeak/database:
  shared/emacspeak/groupies:
  shared/emacspeak/rootgroup:
  shared/emacspeak/program: espeak

Bug#914172: [debian-mysql] Bug#914172: Bug#914172: Bug#914172: mariadb-server-10.1: mariadb-server sec-update (10.1.37-0+deb9u1) uninstalls default-mysql-server, mysql-server, mariadb-server-10.1 & ma

[Robie Basak]

On Thu, Nov 22, 2018 at 10:44:42AM +0100, David Escala wrote:
> Perhaps we should change the apt dist-upgrade command for security updates
> (suggestions?), but
> not adding new dependencies in a security update may also be a good policy.

You should use apt pinning to restrict package upgrades to security
updates only. See what the unattended-upgrades package does for an
example. Removing apt's visibility of stuff that it already has
installed on the system is a hack that will lead to the problem you've
discovered.

I'm interested for someone to confirm that pinning will solve this
problem correctly in this particular case. I believe that it will but am
not certain.

I don't know about Debian's policies in adding dependencies to security
updates. Clearly it is to be avoided, but there might be some situations
when it is necessary for security purposes. Therefore, I'm not sure that
this should be considered a bug at all from mariadb packaging's point of
view, unless there is some other reason that the dependency addition
should not have gone in.


signature.asc
Description: PGP signature

Bug#914367: emacspeak.sh does not include +x permission

[Zachary Kline]

Package: emacspeak
Version: 47.0+dfsg-5
Severity: important

Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
From: Zachary Kline 
To: Debian Bug Tracking System 
Subject: emacspeak.sh permissions don't include +x
Bcc: Zachary Kline 

Package: emacspeak
Version: 47.0+dfsg-5
Severity: important

   * What led up to the situation?
I installed the EMacspeak package.

   * What exactly did you do (or not do) that was effective (or
 ineffective)?
I ran "emacspeak," to get emacspeak temporarily working before adding it more 
perminently to my .emacs file.

   * What was the outcome of this action?
I got a "permission denied," error.

   * What outcome did you expect instead?
Emacspeak should have come up talking with the espeak synthesizer.



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

Kernel: Linux 4.18.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)
LSM: AppArmor: enabled

Versions of packages emacspeak depends on:
ii  adduser3.118
ii  debconf [debconf-2.0]  1.5.69
ii  emacs  1:25.2+1-11
ii  emacs-gtk [emacs]  1:25.2+1-11
ii  make   4.2.1-1.2
ii  perl   5.28.0-3
ii  tcl8.6.0+9
ii  tclx8.48.4.1-2

Versions of packages emacspeak recommends:
ii  emacspeak-espeak-server  47.0+dfsg-5
ii  sox  14.4.2-3

Versions of packages emacspeak suggests:
pn  eflite
pn  emacspeak-ss  
ii  espeak1.48.04+dfsg-7
pn  psgml 
pn  w3m-el
pn  xsltproc  

-- debconf information:
  shared/emacspeak/groupies:
  shared/emacspeak/rootgroup:
  shared/emacspeak/fake:
  shared/emacspeak/database:
  shared/emacspeak/invaliduser:
* shared/emacspeak/port: none
  shared/emacspeak/tcl: tcl
  shared/emacspeak/invalidport:
  shared/emacspeak/program: espeak
* shared/emacspeak/device: espeak

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

Kernel: Linux 4.18.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)
LSM: AppArmor: enabled

Versions of packages emacspeak depends on:
ii  adduser3.118
ii  debconf [debconf-2.0]  1.5.69
ii  emacs  1:25.2+1-11
ii  emacs-gtk [emacs]  1:25.2+1-11
ii  make   4.2.1-1.2
ii  perl   5.28.0-3
ii  tcl8.6.0+9
ii  tclx8.48.4.1-2

Versions of packages emacspeak recommends:
ii  emacspeak-espeak-server  47.0+dfsg-5
ii  sox  14.4.2-3

Versions of packages emacspeak suggests:
pn  eflite
pn  emacspeak-ss  
ii  espeak1.48.04+dfsg-7
pn  psgml 
pn  w3m-el
pn  xsltproc  

-- debconf information:
* shared/emacspeak/port: none
  shared/emacspeak/invalidport:
  shared/emacspeak/rootgroup:
* shared/emacspeak/device: espeak
  shared/emacspeak/database:
  shared/emacspeak/groupies:
  shared/emacspeak/program: espeak
  shared/emacspeak/tcl: tcl
  shared/emacspeak/fake:
  shared/emacspeak/invaliduser:

Bug#914301: tmux: CVE-2018-19387: NULL Pointer Dereference in format_cb_pane_tabs in format.c

[Romain Francoise]

Hi Salvatore,

On Wed, Nov 21, 2018 at 8:57 PM Salvatore Bonaccorso  wrote:
> The following vulnerability was published for tmux, the security
> impact is disputable, but just filling this bug for tracking a future
> fix.

Thanks for the report. Do you know who assigned the CVE id and what
their reasons were? Also, who noted that there is no security impact
in the tracker (if that is really the case I'd rather just close this
bug).

Regards,
-r

Bug#914366: CanvasShaderGLES3: Fragment Program Compilation Failed on Intel Ivybridge Mobile

[wargreen]

Source: mesa
Version: 18.2.5-2
Severity: important

Dear Maintainer,

Since the 18.1.9-1 to 18.2.5-1 upgrade, i got the error
> CanvasShaderGLES3: Fragment Program Compilation Failed:
> 0:89(2): error: invalid input layout qualifier used
at Godot engine startup, and Blender crash with
> blender[11430]: segfault at 20 ip 7fc48bf785e2 sp
7ffcd1e1bbc0 error
4 in libOpenColorIO.so.1.1.0[7fc48beb8000+ff000]

From https://github.com/godotengine/godot/issues/23423 this issue can
be
related to this regression in fedora
https://bugzilla.redhat.com/show_bug.cgi?id=1646150


Thank you



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

Kernel: Linux 4.18.0-2-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

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

Bug#914256: lintian: conflict between no-template-description and untranslatable-debconf-templates

[Chris Lamb]

Hi Vincent,

> E: hello source: not-using-po-debconf
> E: hello: no-template-description hello/all-languages
> E: hello: unknown-field-in-templates hello/all-languages _description
> 
> So still the same problem.

Sorry, please let us know exactly versions of Lintian you are using
rather than "the source package" or similar. It is very easy to get
them all mixed up and accidentally waste others time, alas.

> Still unclear why the lintian test cases are not failing.

I suspect it is something to do with debian/po/ or something like
that but, again, debconf & translations thereof are not something
I've ever really played with, sorry.


Regards,

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

Bug#914365: python3-speechd fails to list voices if version is different from speech-dispatcher

[Colomban Wendling]

Package: python3-speechd
Version: 0.9.0~rc2-1
Severity: normal
Owner: b...@hypra.fr
User: b...@hypra.fr
Usertags: hypra samuel

Dear Maintainer,

Installing speech-dispatcher from Experimental but failing to upgrade
python3-speechd results in Orca not able to list voices, because the
communication format changed and it requires a matching
python3-speechd.

I would ask to add a safeguard, like a conflict on speech-dispatcher
against python3-speechd < 0.9.0~ or something to the same effect, to
avoid any installation with a mismatched python3-speechd resulting on
non-working features.

Regards,
Colomban


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

Kernel: Linux 4.18.0-2-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 python3-speechd depends on:
ii  python3  3.6.7-1
ii  python3-xdg  0.25-4

python3-speechd recommends no packages.

python3-speechd suggests no packages.

-- debconf-show failed

Bug#874445: i3D.net - Ticket Reply: 'Bug#874445: Debian mirror mirror.i3d.net: trace file is empty' [T-366707-H7W8]

[i3D.net - Customer Care]

Hello Peter,

A new reply has been posted to your ticket with the title "Bug#874445: 
Debian mirror mirror.i3d.net: trace file is empty":

Reply posted 
by: Rogier


Hi Peter,

I'm currently migrating the mirror to a new server. There it will also be in 
/debian/ 



Best regards,

Rogier
 Contact: Telephone  Ticket at i3D.net
Helpdesk open Mon - Fri 08:00 - 24:00
 Helpdesk open Sat - Sun 10:00 - 18:00



You can follow up to this ticket by replying to this email directly, keeping 
the subject in-tact, or via the tickets page at https://customer.i3d.net/tickets/c10a5d92c4fb7f96e2bee1c0eb838e618a79cef9/T-366707-H7W8;>https://customer.i3d.net/tickets/c10a5d92c4fb7f96e2bee1c0eb838e618a79cef9/T-366707-H7W8

Bug#914364: srt: FTBFS when built with dpkg-buildpackage -A

[Santiago Vila]

Package: src:srt
Version: 1.3.1-1
Severity: serious
Tags: ftbfs

Dear maintainer:

I tried to build this package with "dpkg-buildpackage -A" but it failed:


[...]
   dh_installchangelogs -i
install -p -m0644 debian/changelog 
debian/libsrt-doc/usr/share/doc/libsrt-doc/changelog.Debian
rm -f debian/libsrt-doc.debhelper.log
   debian/rules override_dh_installman
make[1]: Entering directory '/<>'
help2man --no-discard-stderr --no-info --version-string="1.3.1-1" \
--name "" \
-o ./debian/srt-file-transmit.1 ./debian/srt-tools/usr/bin/srt-file-transmit
help2man: can't get `--help' info from 
./debian/srt-tools/usr/bin/srt-file-transmit
make[1]: *** [debian/rules:25: override_dh_installman] Error 2
make[1]: Leaving directory '/<>'
make: *** [debian/rules:10: binary-indep] Error 2
dpkg-buildpackage: error: fakeroot debian/rules binary-indep subprocess 
returned exit status 2


Hint: Try splitting override_dh_installman into override_dh_installman-arch and 
override_dh_installman-indep.

Thanks.

Bug#914363: pybel: FTBFS (UnicodeDecodeError: 'ascii' codec can't decode byte 0xe2 in position 30260)

[Santiago Vila]

Package: src:pybel
Version: 0.12.1-1
Severity: serious
Tags: ftbfs

Dear maintainer:

I tried to build this package in a clean chroot but it failed:


[...]
 debian/rules build-indep
dh build-indep --with python3 --buildsystem=pybuild
   dh_update_autotools_config -i -O--buildsystem=pybuild
   dh_autoreconf -i -O--buildsystem=pybuild
   dh_auto_configure -i -O--buildsystem=pybuild
I: pybuild base:217: python3.6 setup.py config 
running config
I: pybuild base:217: python3.7 setup.py config 
running config
   dh_auto_build -i -O--buildsystem=pybuild
I: pybuild base:217: /usr/bin/python3.6 setup.py build 
running build
running build_py
creating /<>/.pybuild/cpython3_3.6_pybel/build/pybel

[... snipped ...]

test_get_random_path 
(tests.test_struct.test_transformations.test_random.TestRandomPath)
Test getting random paths doesn't crash. ... ok
test_does_not_redo 
(tests.test_struct.test_transformations.test_transfer.TestTransfer)
Test that :func:`propagate_node_relations` does not add the same edges twice. 
... ok
test_get_children 
(tests.test_struct.test_transformations.test_transfer.TestTransfer)
Test iterating over the children of a node. ... ok
test_infer (tests.test_struct.test_transformations.test_transfer.TestTransfer)
Test inferring child relations. ... ok
test_bad_aminoAcid (tests.test_utils.TestRandom) ... ok
test_get_date (tests.test_utils.TestRandom) ... ok
test_nest_failure (tests.test_utils.TestRandom) ... ok
test_dev (tests.test_utils.TestTokenizeVersion)
Test when there's a dash after. ... ok
test_long (tests.test_utils.TestTokenizeVersion)
Test when the version pieces have more than 1 digit. ... ok
test_simple (tests.test_utils.TestTokenizeVersion)
Test the simplest version string case. ... ok
test_download_raises_on_empty (tests.test_utils.TestUtils)
Test that an error is thrown if an empty resource is downloaded. ... ok
test_download_url (tests.test_utils.TestUtils)
Test downloading a resource by URL. ... ok
test_expand_dict (tests.test_utils.TestUtils) ... ok
test_flatten_dict (tests.test_utils.TestUtils) ... ok
test_flatten_dict_withLists (tests.test_utils.TestUtils) ... ok

==
ERROR: test_jgif_interchange (tests.test_io.test_jgif.TestJgif)
Tests data from CBN
--
Traceback (most recent call last):
  File 
"/<>/.pybuild/cpython3_3.6_pybel/build/tests/test_io/test_jgif.py",
 line 126, in test_jgif_interchange
graph_jgif_dict = json.load(f)
  File "/usr/lib/python3.6/json/__init__.py", line 296, in load
return loads(fp.read(),
  File "/usr/lib/python3.6/encodings/ascii.py", line 26, in decode
return codecs.ascii_decode(input, self.errors)[0]
UnicodeDecodeError: 'ascii' codec can't decode byte 0xe2 in position 30260: 
ordinal not in range(128)

--
Ran 657 tests in 29.660s

FAILED (errors=1, skipped=1)
(, 2)
E: pybuild pybuild:338: test: plugin distutils failed with: exit code=1: cd 
/<>/.pybuild/cpython3_3.6_pybel/build; python3.6 -m unittest 
discover -v 
dh_auto_test: pybuild --test -i python{version} -p "3.6 3.7" returned exit code 
13
make: *** [debian/rules:7: build-indep] Error 25
dpkg-buildpackage: error: debian/rules build-indep subprocess returned exit 
status 2


The build was made in my autobuilder with "dpkg-buildpackage -A".
Most probably, it will also fail here:

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

but I can't test it yet.

If this is really a bug in one of the build-depends, please use reassign and 
affects,
so that this is still visible in the BTS web page for this package.

Thanks.

Bug#914362: gost-crypto: FTBFS (/lib/modules/4.9.0-8-amd64/build: No such file or directory)

[Santiago Vila]

Package: src:gost-crypto
Version: 0.1+streebog-1
Severity: serious
Tags: ftbfs

Dear maintainer:

I tried to build this package in a clean chroot but it failed:


[...]
dpkg-buildpackage: info: source distribution unstable
dpkg-buildpackage: info: source changed by Dmitry Eremin-Solenikov 

 dpkg-source --before-build .
 fakeroot debian/rules clean
dh clean
   dh_auto_clean
make V=1 -j1 clean
make[1]: Entering directory '/<>/gost-crypto-0.1+streebog'
make -C /lib/modules/4.9.0-8-amd64/build 
M=/<>/gost-crypto-0.1+streebog clean
make[2]: Entering directory '/<>/gost-crypto-0.1+streebog'
make[2]: *** /lib/modules/4.9.0-8-amd64/build: No such file or directory.  Stop.
make[2]: Leaving directory '/<>/gost-crypto-0.1+streebog'
make[1]: *** [Makefile:29: clean] Error 2
make[1]: Leaving directory '/<>/gost-crypto-0.1+streebog'
dh_auto_clean: make V=1 -j1 clean returned exit code 2
make: *** [debian/rules:11: clean] Error 2
dpkg-buildpackage: error: fakeroot debian/rules clean subprocess returned exit 
status 2


The build was made in my autobuilder with "dpkg-buildpackage -A".
Most probably, it will also fail here:

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

but I can't test it yet.

If this is really a bug in one of the build-depends, please use reassign and 
affects,
so that this is still visible in the BTS web page for this package.

Thanks.

Bug#914361: gdspy: FTBFS (There is a programable error in your configuration file)

[Santiago Vila]

Package: src:gdspy
Version: 1.3.1-1
Severity: serious
Tags: ftbfs

Dear maintainer:

I tried to build this package in a clean chroot but it failed:


[...]
 debian/rules build-indep
dh build-indep --with python2,python3,sphinxdoc --buildsystem=pybuild
   dh_update_autotools_config -i -O--buildsystem=pybuild
   dh_autoreconf -i -O--buildsystem=pybuild
   dh_auto_configure -i -O--buildsystem=pybuild
I: pybuild base:217: python2.7 setup.py config 
running config
I: pybuild base:217: python3.6 setup.py config 
running config
I: pybuild base:217: python3.7 setup.py config 
running config
   debian/rules override_dh_auto_build
make[1]: Entering directory '/<>'
dh_auto_build

[... snipped ...]

copying /<>/.pybuild/cpython3_3.7_gdspy/build/gdspy/data/05.xbm -> 
/<>/debian/python3-gdspy/usr/lib/python3.7/dist-packages/gdspy/data
copying /<>/.pybuild/cpython3_3.7_gdspy/build/gdspy/data/up.xbm -> 
/<>/debian/python3-gdspy/usr/lib/python3.7/dist-packages/gdspy/data
copying /<>/.pybuild/cpython3_3.7_gdspy/build/gdspy/viewer.py -> 
/<>/debian/python3-gdspy/usr/lib/python3.7/dist-packages/gdspy
creating 
/<>/debian/python3-gdspy/usr/lib/python3.7/dist-packages/gdspy/__pycache__
copying 
/<>/.pybuild/cpython3_3.7_gdspy/build/gdspy/__pycache__/__init__.cpython-37.pyc
 -> 
/<>/debian/python3-gdspy/usr/lib/python3.7/dist-packages/gdspy/__pycache__
copying 
/<>/.pybuild/cpython3_3.7_gdspy/build/gdspy/__pycache__/viewer.cpython-37.pyc
 -> 
/<>/debian/python3-gdspy/usr/lib/python3.7/dist-packages/gdspy/__pycache__
copying 
/<>/.pybuild/cpython3_3.7_gdspy/build/gdspy/boolext.cpython-37m-x86_64-linux-gnu.so
 -> /<>/debian/python3-gdspy/usr/lib/python3.7/dist-packages/gdspy
byte-compiling 
/<>/debian/python3-gdspy/usr/lib/python3.7/dist-packages/gdspy/__init__.py
 to __init__.cpython-37.pyc
byte-compiling 
/<>/debian/python3-gdspy/usr/lib/python3.7/dist-packages/gdspy/viewer.py
 to viewer.cpython-37.pyc
running install_egg_info
running egg_info
writing gdspy.egg-info/PKG-INFO
writing dependency_links to gdspy.egg-info/dependency_links.txt
writing requirements to gdspy.egg-info/requires.txt
writing top-level names to gdspy.egg-info/top_level.txt
reading manifest file 'gdspy.egg-info/SOURCES.txt'
reading manifest template 'MANIFEST.in'
warning: no files found matching '*' under directory 'docs/_build/html'
writing manifest file 'gdspy.egg-info/SOURCES.txt'
Copying gdspy.egg-info to 
/<>/debian/python3-gdspy/usr/lib/python3.7/dist-packages/gdspy-1.3.1.egg-info
Skipping SOURCES.txt
running install_scripts
make[1]: Leaving directory '/<>'
   dh_install -i -O--buildsystem=pybuild
   debian/rules override_dh_installdocs
make[1]: Entering directory '/<>'
cd build && PYTHONPATH=../debian/python3-gdspy/usr/lib/python3.6/dist-packages 
http_proxy='127.0.0.1:9' python3 -m sphinx -N -bhtml ../docs html # HTML 
generator
Running Sphinx v1.7.9

Configuration error:
There is a programable error in your configuration file:

Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/sphinx/config.py", line 161, in __init__
execfile_(filename, config)
  File "/usr/lib/python3/dist-packages/sphinx/util/pycompat.py", line 150, in 
execfile_
exec_(code, _globals)
  File "conf.py", line 80, in 
from gdspy import __version__ as vv
  File 
"/<>/debian/python3-gdspy/usr/lib/python3.6/dist-packages/gdspy/__init__.py",
 line 48, in 
from gdspy import boolext
ImportError: cannot import name 'boolext' from 'gdspy' 
(/<>/debian/python3-gdspy/usr/lib/python3.6/dist-packages/gdspy/__init__.py)

make[1]: *** [debian/rules:32: override_dh_installdocs] Error 2
make[1]: Leaving directory '/<>'
make: *** [debian/rules:12: binary-indep] Error 2
dpkg-buildpackage: error: fakeroot debian/rules binary-indep subprocess 
returned exit status 2


The build was made in my autobuilder with "dpkg-buildpackage -A".
Most probably, it will also fail here:

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

but I can't test it yet.

If this is really a bug in one of the build-depends, please use reassign and 
affects,
so that this is still visible in the BTS web page for this package.

Thanks.

Bug#914345: pcmanfm-qt: the desktop background should be compliant with desktop-base

[Alf Gaida]

Hi Wolfgang,

the problem is well known and your one-liner is not part of the solution.
a) there should be something depend on desktop-base
b) frost at all don't look well with debian - a debian theme is needed
c) i guess it was in 0.13 that we (i) moved all upstream configurations
to /usr/share/$foo - the reason was to have /etc/xdg/foo and /etc
available for distributions - so there is no need to touch pcmanfm-qt at
all.

Possible solution: Be our guest and provide your wished theme to
https://salsa.debian.org/lxqt-team/lxqt-themes-extra - i would suggest a
theme for debian-edu. The "only" thing we need after finishing is a DD
who want to sponsor the new package.

Cheers Alf

Bug#897841: [Pkg-middleware-maintainers] Bug#897841: Patch upstream doesn't fix

[Daniel Pocock]

On 20/07/18 11:38, Thomas Goirand wrote:
> Hi,
> 
> I tried applying the patch from upstream, unfortunately, the build still
> fails at the same moment. Maybe we should just disable this -Werror thing?
> 

Thanks for testing it

I notice that the fix didn't change every file with this problem, it
needed to be changed on 5 more lines to get a successful build.

Regards,

Daniel

Bug#914354: redis-server: Redis server won't start with default configuration if ipv6 is disabled in the system (with sysctl).

[Chris Lamb]

reopen 891432
forcemerge 891432 914354
retitle 900284 Fails to start if IPv6 is disabled
severity 900284 important
thanks

[Adding z...@debian.org to CC]

Hi Martin,

> Redis server won't start with default configuration if ipv6 is
> disabled in the system (with sysctl).

So this was "introduced" in #891432 and was originally reported in
#900284 but we ended up closing it.

(Merging, etc. to match)


Best wishes,

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

Bug#914360: tinc: Random segfault after connection drop

[Maximilian Stein]

Package: tinc
Version: 1.0.35-1
Severity: normal

Dear Maintainer,

One instance of the tinc daemon crashed after running for quite a
while.

Syslog shows a peer's connection had dropped immediately before the
crash:

Nov 22 10:08:38 hostname tincd[691]: Flushing meta data to abcd (1.2.3.4 port 
30458) failed: Connection reset by peer
Nov 22 10:08:38 hostname tincd[691]: Closing connection with abcd (1.2.3.4 port 
30458)
Nov 22 10:08:38 hostname tincd[691]: Got ANS_KEY from efgh (5.6.7.8 port 50551) 
destination abcd which is not reachable
Nov 22 10:08:38 hostname tincd[691]: Connection from 1.2.3.4 port 22087
Nov 22 10:08:38 hostname kernel: [52018.886642] tincd[691]: segfault at 98c ip 
557ae018e29d sp 7c40f5b0 error 4 in tincd[557ae0189000+19000]


This is the first and only time I have observed this behaviour. I hope
the provided information can help finding the issue.

Thanks!
Maximilian


-- System Information:
Debian Release: 9.6
  APT prefers stable
  APT policy: (900, 'stable'), (800, 'oldstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages tinc depends on:
ii  libc6  2.24-11+deb9u3
ii  liblzo2-2  2.08-1.2+b2
ii  libssl1.1  1.1.0f-3+deb9u2
ii  lsb-base   9.20161125
ii  zlib1g 1:1.2.8.dfsg-5

tinc recommends no packages.

tinc suggests no packages.

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

-- no debconf information

Bug#897023: [Pkg-javascript-devel] RFS: node-tar-fs

[Pirate Praveen]

On 2018, നവംബർ 22 9:19:51 PM IST, Paolo Greppi  wrote:
>Hi, I have packaged node-tar-fs:
>https://salsa.debian.org/js-team/node-tar-fs
>
>I am Cc-ing the ITP.
>
>Please someone sponsor the upload.

I think this is another candidate for embedding (no build steps required, not 
depended on by multiple packages).
-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Bug#914359: termbox: FTBFS (RuntimeError: generator raised StopIteration)

[Santiago Vila]

Package: src:termbox
Version: 1.1.2+dfsg-1
Severity: serious
Tags: ftbfs

Dear maintainer:

I tried to build this package but it failed:


[...]
 debian/rules build-arch
dh build-arch --with python3
   dh_update_autotools_config -a
   dh_autoreconf -a
   debian/rules override_dh_auto_configure
make[1]: Entering directory '/<>/termbox-1.1.2+dfsg'
python3 waf configure \
--prefix=/usr \
--libdir=usr/lib/x86_64-linux-gnu/
Traceback (most recent call last):
  File "/<>/termbox-1.1.2+dfsg/waflib/Node.py", line 285, in ant_iter
raise StopIteration
StopIteration

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

Traceback (most recent call last):
  File "/<>/termbox-1.1.2+dfsg/waflib/Scripting.py", line 98, in 
waf_entry_point
run_commands()
  File "/<>/termbox-1.1.2+dfsg/waflib/Scripting.py", line 155, in 
run_commands
parse_options()
  File "/<>/termbox-1.1.2+dfsg/waflib/Scripting.py", line 128, in 
parse_options
Context.create_context('options').execute()
  File "/<>/termbox-1.1.2+dfsg/waflib/Options.py", line 138, in 
execute
super(OptionsContext,self).execute()
  File "/<>/termbox-1.1.2+dfsg/waflib/Context.py", line 92, in execute
self.recurse([os.path.dirname(g_module.root_path)])
  File "/<>/termbox-1.1.2+dfsg/waflib/Context.py", line 133, in 
recurse
user_function(self)
  File "/<>/termbox-1.1.2+dfsg/wscript", line 11, in options
opt.load('compiler_c')
  File "/<>/termbox-1.1.2+dfsg/waflib/Context.py", line 89, in load
fun(self)
  File "/<>/termbox-1.1.2+dfsg/waflib/Tools/compiler_c.py", line 36, 
in options
opt.load_special_tools('c_*.py',ban=['c_dumbpreproc.py'])
  File "/<>/termbox-1.1.2+dfsg/waflib/Context.py", line 296, in 
load_special_tools
lst=self.root.find_node(waf_dir).find_node('waflib/extras').ant_glob(var)
  File "/<>/termbox-1.1.2+dfsg/waflib/Node.py", line 334, in ant_glob
ret=[x for x in 
self.ant_iter(accept=accept,pats=[to_pat(incl),to_pat(excl)],maxdepth=kw.get('maxdepth',25),dir=dir,src=src,remove=kw.get('remove',True))]
  File "/<>/termbox-1.1.2+dfsg/waflib/Node.py", line 334, in 

ret=[x for x in 
self.ant_iter(accept=accept,pats=[to_pat(incl),to_pat(excl)],maxdepth=kw.get('maxdepth',25),dir=dir,src=src,remove=kw.get('remove',True))]
RuntimeError: generator raised StopIteration
make[1]: *** [debian/rules:11: override_dh_auto_configure] Error 2
make[1]: Leaving directory '/<>/termbox-1.1.2+dfsg'
make: *** [debian/rules:5: build-arch] Error 2
dpkg-buildpackage: error: debian/rules build-arch subprocess returned exit 
status 2


Full log available here for several architectures:

http://buildd.debian.org/termbox

Thanks.

Bug#914357: hotspot: FTBFS (dh_auto_test fails)

[Santiago Vila]

Package: src:hotspot
Version: 1.1.0+git20180816-1
Severity: serious
Tags: ftbfs

Dear maintainer:

I tried to build this package but it failed:


[...]
 debian/rules build-arch
dh build-arch
   dh_update_autotools_config -a
   dh_autoreconf -a
   dh_auto_configure -a
install -d obj-x86_64-linux-gnu
cd obj-x86_64-linux-gnu && cmake -DCMAKE_INSTALL_PREFIX=/usr 
-DCMAKE_BUILD_TYPE=None -DCMAKE_INSTALL_SYSCONFDIR=/etc 
-DCMAKE_INSTALL_LOCALSTATEDIR=/var -DCMAKE_EXPORT_NO_PACKAGE_REGISTRY=ON 
-DCMAKE_FIND_PACKAGE_NO_PACKAGE_REGISTRY=ON -DCMAKE_INSTALL_RUNSTATEDIR=/run 
"-GUnix Makefiles" -DCMAKE_VERBOSE_MAKEFILE=ON 
-DCMAKE_INSTALL_LIBDIR=lib/x86_64-linux-gnu ..
-- The CXX compiler identification is GNU 8.2.0
-- The C compiler identification is GNU 8.2.0
-- Check for working CXX compiler: /usr/bin/c++
-- Check for working CXX compiler: /usr/bin/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features

[... snipped ...]

Test project /<>/hotspot-1.1.0+git20180816/obj-x86_64-linux-gnu
Start 1: tst_elfmap
1/6 Test #1: tst_elfmap ...   Passed7.04 sec
Start 2: tst_addresscache
2/6 Test #2: tst_addresscache .   Passed0.00 sec
Start 3: tst_kallsyms
3/6 Test #3: tst_kallsyms .***Failed0.40 sec
* Start testing of TestKallsyms *
Config: Using QtTest library 5.11.2, Qt 5.11.2 (x86_64-little_endian-lp64 
shared (dynamic) release build; by GCC 8.2.0)
PASS   : TestKallsyms::initTestCase()
PASS   : TestKallsyms::testResolve(__per_cpu_start:0)
PASS   : TestKallsyms::testResolve(_stext:0)
PASS   : TestKallsyms::testResolve(_stext:2)
PASS   : TestKallsyms::testResolve(xen_hypercall_set_gdt:0)
PASS   : TestKallsyms::testResolve(xen_hypercall_set_gdt:256)
PASS   : TestKallsyms::testResolve(xen_hypercall_set_gdt:256)
PASS   : TestKallsyms::testResolve(serio_interrupt:0)
PASS   : TestKallsyms::testResolve(zeros-only)
PASS   : TestKallsyms::testResolve(zeros-only2)
PASS   : TestKallsyms::testResolve(null-only)
PASS   : TestKallsyms::testResolve(null-only2)
XPASS  : TestKallsyms::testProc() 'kallsyms.parseMapping(path)' returned TRUE 
unexpectedly. ()
   Loc: 
[/<>/hotspot-1.1.0+git20180816/3rdparty/perfparser/tests/auto/kallsyms/tst_kallsyms.cpp(138)]
QDEBUG : TestKallsyms::testParseErrors() "Mapping is empty."
QDEBUG : TestKallsyms::testParseErrors() "Invalid address: this"
QDEBUG : TestKallsyms::testParseErrors() "No such file or directory"
PASS   : TestKallsyms::testParseErrors()
PASS   : TestKallsyms::benchmarkProc()
RESULT : TestKallsyms::benchmarkProc():
 129 msecs per iteration (total: 129, iterations: 1)
PASS   : TestKallsyms::cleanupTestCase()
Totals: 15 passed, 1 failed, 0 skipped, 0 blacklisted, 401ms
* Finished testing of TestKallsyms *

Start 4: tst_models
4/6 Test #4: tst_models ...   Passed0.04 sec
Start 5: tst_timelinedelegate
5/6 Test #5: tst_timelinedelegate .   Passed0.01 sec
Start 6: tst_perfparser
6/6 Test #6: tst_perfparser ...   Passed0.01 sec

83% tests passed, 1 tests failed out of 6

Total Test time (real) =   7.51 sec

The following tests FAILED:
  3 - tst_kallsyms (Failed)
Errors while running CTest
make[1]: *** [Makefile:87: test] Error 8
make[1]: Leaving directory 
'/<>/hotspot-1.1.0+git20180816/obj-x86_64-linux-gnu'
dh_auto_test: cd obj-x86_64-linux-gnu && make V=1 -j1 test ARGS\+=-j1 returned 
exit code 2
make: *** [debian/rules:9: build-arch] Error 2
dpkg-buildpackage: error: debian/rules build-arch subprocess returned exit 
status 2


Full log available here for several architectures:

http://buildd.debian.org/hotspot

Thanks.

Bug#914358: schroedinger-maeparser: FTBFS (cmake: not found)

[Santiago Vila]

Package: src:schroedinger-maeparser
Version: 1.0.1-1
Severity: serious
Tags: ftbfs

Dear maintainer:

I tried to build this package but it failed:


[...]
 debian/rules build-arch
dh build-arch
   dh_update_autotools_config -a
   dh_autoreconf -a
   debian/rules override_dh_auto_configure
make[1]: Entering directory '/<>'
mkdir build
cd build ; CXX=g++ cmake ..
/bin/sh: 1: cmake: not found
make[1]: *** [debian/rules:16: override_dh_auto_configure] Error 127
make[1]: Leaving directory '/<>'
make: *** [debian/rules:12: build-arch] Error 2
dpkg-buildpackage: error: debian/rules build-arch subprocess returned exit 
status 2


Full log available here for several architectures:

http://buildd.debian.org/schroedinger-maeparser

Thanks.

Bug#914296: ITP: node-path-parse -- Node.js path.parse() ponyfill

[Pirate Praveen]

On 2018, നവംബർ 22 9:15:16 PM IST, Nicolas Mora  wrote:
>Le 2018-11-22 03:54, Pirate Praveen a écrit :
>> I suggest you embed it inside (same for other simple dependencies)
>> node-istanbuljs. See
>>
>https://wiki.debian.org/Javascript/Nodejs/Npm2Deb#Embedding_some_modules
>
>Thanks, I will do that.
>
>One question about this process though.
>
>In this case, the package node-path-parse is a dependency of 
>node-istanbul on the install stage, but not on the build stage.
>
>So my idea is to copy node-path-parse to 
>node-istanbuljs/debian/components and append to the file 
>debian/node-istanbul-lib-report.install the new component:

No, debian/components/path-parse is only metadata. See the example packages.

>debian/components/node-path-parse/package.json 
>usr/lib/nodejs/path-parse/
>debian/components/node-path-parse/index.js usr/lib/nodejs/path-parse/
>
>There is no need for a build script.
>
>Do you agree?

You'll still need an install script to copy path-parse to 
node_modules/path-parse.

path-parse directory will be created with gbp import-dsc. I have added more 
steps to the wiki. Let me know if you need more info on any of the steps.
-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Bug#914354: redis-server: Redis server won't start with default configuration if ipv6 is disabled in the system (with sysctl).

[Martin Ždila]

Package: redis-server
Version: 5:5.0.1-1
Severity: normal

Dear Maintainer,

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

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

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

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

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

Versions of packages redis-server depends on:
ii  lsb-base 9.20170808
ii  redis-tools  5:5.0.1-1

redis-server recommends no packages.

redis-server suggests no packages.

-- Configuration Files:
/etc/init.d/redis-server changed:
PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin
DAEMON=/usr/bin/redis-server
DAEMON_ARGS=/etc/redis/redis.conf
NAME=redis-server
DESC=redis-server
RUNDIR=/var/run/redis
PIDFILE=$RUNDIR/redis-server.pid
test -x $DAEMON || exit 0
if [ -r /etc/default/$NAME ]
then
. /etc/default/$NAME
fi
. /lib/lsb/init-functions
set -e
if [ "$(id -u)" != "0" ]
then
log_failure_msg "Must be run as root."
exit 1
fi
case "$1" in
  start)
echo -n "Starting $DESC: "
mkdir -p $RUNDIR
touch $PIDFILE
chown redis:redis $RUNDIR $PIDFILE
chmod 755 $RUNDIR
if [ -n "$ULIMIT" ]
then
ulimit -n $ULIMIT || true
fi
if start-stop-daemon --start --quiet --oknodo --umask 007 --pidfile 
$PIDFILE --chuid redis:redis --exec $DAEMON -- $DAEMON_ARGS
then
echo "$NAME."
else
echo "failed"
fi
;;
  stop)
echo -n "Stopping $DESC: "
if start-stop-daemon --stop --retry forever/TERM/1 --quiet --oknodo 
--pidfile $PIDFILE --exec $DAEMON
then
echo "$NAME."
else
echo "failed"
fi
rm -f $PIDFILE
sleep 1
;;
  restart|force-reload)
${0} stop
${0} start
;;
  status)
status_of_proc -p ${PIDFILE} ${DAEMON} ${NAME}
;;
  *)
echo "Usage: /etc/init.d/$NAME 
{start|stop|restart|force-reload|status}" >&2
exit 1
;;
esac
exit 0

/etc/redis/redis.conf [Errno 13] Permission denied: '/etc/redis/redis.conf'

-- debconf-show failed

Bug#914355: gnucap-python: FTBFS (dh_auto_configure fails)

[Santiago Vila]

Package: src:gnucap-python
Version: 0.0.0-1
Severity: serious
Tags: ftbfs

Dear maintainer:

I tried to build this package but it failed:


[...]
 debian/rules build-arch
dh build-arch --with python2,python3
   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:54: installing './compile'
configure.ac:13: installing './missing'

[... snipped ...]

exec_prefix='NONE'
host=''
host_alias=''
host_cpu=''
host_os=''
host_vendor=''
htmldir='${docdir}'
includedir='${prefix}/include'
infodir='${prefix}/share/info'
install_sh='${SHELL} /<>/install-sh'
libdir='${prefix}/lib/x86_64-linux-gnu'
libexecdir='${prefix}/lib/x86_64-linux-gnu'
localedir='${datarootdir}/locale'
localstatedir='/var'
mandir='${prefix}/share/man'
mkdir_p='$(MKDIR_P)'
oldincludedir='/usr/include'
pdfdir='${docdir}'
pkgpyexecdir='${pyexecdir}/gnucap-python'
pkgpythondir='${pythondir}/gnucap-python'
prefix='/usr'
program_transform_name='s,x,x,'
psdir='${docdir}'
pyexecdir='${exec_prefix}/lib/python3.6/site-packages'
pythondir='${prefix}/lib/python3.6/site-packages'
runstatedir='/run'
sbindir='${exec_prefix}/sbin'
sharedstatedir='${prefix}/com'
sysconfdir='/etc'
target_alias=''

## --- ##
## confdefs.h. ##
## --- ##

/* confdefs.h */
#define PACKAGE_NAME "gnucap-python"
#define PACKAGE_TARNAME "gnucap-python"
#define PACKAGE_VERSION "0.0.0"
#define PACKAGE_STRING "gnucap-python 0.0.0"
#define PACKAGE_BUGREPORT "gnucap-de...@gnu.org"
#define PACKAGE_URL ""
#define PACKAGE "gnucap-python"
#define VERSION "0.0.0"
#define HAVE_LIBDL 1
#define HAVE_PYTHON "3.6"

configure: exit 1
dh_auto_configure: cd build3.6 && ../configure --build=x86_64-linux-gnu 
--prefix=/usr --includedir=\${prefix}/include --mandir=\${prefix}/share/man 
--infodir=\${prefix}/share/info --sysconfdir=/etc --localstatedir=/var 
--disable-silent-rules --libdir=\${prefix}/lib/x86_64-linux-gnu 
--libexecdir=\${prefix}/lib/x86_64-linux-gnu --runstatedir=/run 
--disable-maintainer-mode --disable-dependency-tracking PYTHON=python3.6 
returned exit code 1
make[1]: *** [debian/rules:30: ac-python3.6] Error 2
make[1]: Leaving directory '/<>'
make: *** [debian/rules:22: build-arch] Error 2
dpkg-buildpackage: error: debian/rules build-arch subprocess returned exit 
status 2


Full log available here for several architectures:

http://buildd.debian.org/gnucap-python

Thanks.

Bug#914356: dlt-daemon: FTBFS (ld: cannot find -lpthreads)

[Santiago Vila]

Package: src:dlt-daemon
Version: 2.17.0-1
Severity: serious
Tags: ftbfs

Dear maintainer:

I tried to build this package but it failed:


[...]
 debian/rules build-arch
dh build-arch
   dh_update_autotools_config -a
   dh_autoreconf -a
   debian/rules override_dh_auto_configure
make[1]: Entering directory '/<>'
dh_auto_configure --  -DWITH_SYSTEMD=ON -DWITH_SYSTEMD_JOURNAL=ON 
-DCMAKE_LIBRARY_PATH=x86_64-linux-gnu
install -d obj-x86_64-linux-gnu
cd obj-x86_64-linux-gnu && cmake -DCMAKE_INSTALL_PREFIX=/usr 
-DCMAKE_BUILD_TYPE=None -DCMAKE_INSTALL_SYSCONFDIR=/etc 
-DCMAKE_INSTALL_LOCALSTATEDIR=/var -DCMAKE_EXPORT_NO_PACKAGE_REGISTRY=ON 
-DCMAKE_FIND_PACKAGE_NO_PACKAGE_REGISTRY=ON "-GUnix Makefiles" 
-DCMAKE_VERBOSE_MAKEFILE=ON -DCMAKE_INSTALL_LIBDIR=lib/x86_64-linux-gnu 
-DWITH_SYSTEMD=ON -DWITH_SYSTEMD_JOURNAL=ON 
-DCMAKE_LIBRARY_PATH=x86_64-linux-gnu ..
-- The C compiler identification is GNU 8.2.0
-- The CXX compiler identification is GNU 8.2.0
-- Check for working C compiler: /usr/bin/cc
-- Check for working C compiler: /usr/bin/cc -- works
-- Detecting C compiler ABI info

[... snipped ...]

#endif
}

Determining if the function pthread_create exists in the pthreads failed with 
the following output:
Change Dir: /<>/obj-x86_64-linux-gnu/CMakeFiles/CMakeTmp

Run Build Command:"/usr/bin/make" "cmTC_2df6a/fast"
make[2]: Entering directory 
'/<>/obj-x86_64-linux-gnu/CMakeFiles/CMakeTmp'
/usr/bin/make -f CMakeFiles/cmTC_2df6a.dir/build.make 
CMakeFiles/cmTC_2df6a.dir/build
make[3]: Entering directory 
'/<>/obj-x86_64-linux-gnu/CMakeFiles/CMakeTmp'
Building C object CMakeFiles/cmTC_2df6a.dir/CheckFunctionExists.c.o
/usr/bin/cc   -g -O2 -fdebug-prefix-map=/<>=. 
-fstack-protector-strong -Wformat -Werror=format-security -Wdate-time 
-D_FORTIFY_SOURCE=2 -DCHECK_FUNCTION_EXISTS=pthread_create   -o 
CMakeFiles/cmTC_2df6a.dir/CheckFunctionExists.c.o   -c 
/usr/share/cmake-3.12/Modules/CheckFunctionExists.c
Linking C executable cmTC_2df6a
/usr/bin/cmake -E cmake_link_script CMakeFiles/cmTC_2df6a.dir/link.txt 
--verbose=1
/usr/bin/cc -g -O2 -fdebug-prefix-map=/<>=. 
-fstack-protector-strong -Wformat -Werror=format-security -Wdate-time 
-D_FORTIFY_SOURCE=2 -DCHECK_FUNCTION_EXISTS=pthread_create  -Wl,-z,relro  
-rdynamic CMakeFiles/cmTC_2df6a.dir/CheckFunctionExists.c.o  -o cmTC_2df6a 
-lpthreads 
/usr/bin/ld: cannot find -lpthreads
collect2: error: ld returned 1 exit status
make[3]: *** [CMakeFiles/cmTC_2df6a.dir/build.make:87: cmTC_2df6a] Error 1
make[3]: Leaving directory 
'/<>/obj-x86_64-linux-gnu/CMakeFiles/CMakeTmp'
make[2]: *** [Makefile:121: cmTC_2df6a/fast] Error 2
make[2]: Leaving directory 
'/<>/obj-x86_64-linux-gnu/CMakeFiles/CMakeTmp'


Determining if the function floor exists failed with the following output:
Change Dir: /<>/obj-x86_64-linux-gnu/CMakeFiles/CMakeTmp

Run Build Command:"/usr/bin/make" "cmTC_3de1c/fast"
make[2]: Entering directory 
'/<>/obj-x86_64-linux-gnu/CMakeFiles/CMakeTmp'
/usr/bin/make -f CMakeFiles/cmTC_3de1c.dir/build.make 
CMakeFiles/cmTC_3de1c.dir/build
make[3]: Entering directory 
'/<>/obj-x86_64-linux-gnu/CMakeFiles/CMakeTmp'
Building C object CMakeFiles/cmTC_3de1c.dir/CheckFunctionExists.c.o
/usr/bin/cc  -I/<>/systemd/3rdparty  -g -O2 
-fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat 
-Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -std=gnu99 
-DCHECK_FUNCTION_EXISTS=floor   -o 
CMakeFiles/cmTC_3de1c.dir/CheckFunctionExists.c.o   -c 
/usr/share/cmake-3.12/Modules/CheckFunctionExists.c
: warning: conflicting types for built-in function 'floor' 
[-Wbuiltin-declaration-mismatch]
/usr/share/cmake-3.12/Modules/CheckFunctionExists.c:7:3: note: in expansion of 
macro 'CHECK_FUNCTION_EXISTS'
   CHECK_FUNCTION_EXISTS(void);
   ^
Linking C executable cmTC_3de1c
/usr/bin/cmake -E cmake_link_script CMakeFiles/cmTC_3de1c.dir/link.txt 
--verbose=1
/usr/bin/cc -g -O2 -fdebug-prefix-map=/<>=. 
-fstack-protector-strong -Wformat -Werror=format-security -Wdate-time 
-D_FORTIFY_SOURCE=2 -std=gnu99 -DCHECK_FUNCTION_EXISTS=floor  -Wl,-z,relro  
-rdynamic CMakeFiles/cmTC_3de1c.dir/CheckFunctionExists.c.o  -o cmTC_3de1c 
/usr/bin/ld: CMakeFiles/cmTC_3de1c.dir/CheckFunctionExists.c.o: in function 
`main':
/usr/share/cmake-3.12/Modules/CheckFunctionExists.c:17: undefined reference to 
`floor'
collect2: error: ld returned 1 exit status
make[3]: *** [CMakeFiles/cmTC_3de1c.dir/build.make:87: cmTC_3de1c] Error 1
make[3]: Leaving directory 
'/<>/obj-x86_64-linux-gnu/CMakeFiles/CMakeTmp'
make[2]: *** [Makefile:121: cmTC_3de1c/fast] Error 2
make[2]: Leaving directory 
'/<>/obj-x86_64-linux-gnu/CMakeFiles/CMakeTmp'


dh_auto_configure: cd obj-x86_64-linux-gnu && cmake -DCMAKE_INSTALL_PREFIX=/usr 
-DCMAKE_BUILD_TYPE=None -DCMAKE_INSTALL_SYSCONFDIR=/etc 
-DCMAKE_INSTALL_LOCALSTATEDIR=/var -DCMAKE_EXPORT_NO_PACKAGE_REGISTRY=ON 
-DCMAKE_FIND_PACKAGE_NO_PACKAGE_REGISTRY=ON "-GUnix 

Bug#914238: libgl1-mesa-dri: browser stays white when opening a website (i965, Intel HD Graphics 520)

[Michael Biebl]

Hi Jochen

On Tue, 20 Nov 2018 21:21:05 +0100 Jochen Sprickerhof
 wrote:
> Package: libgl1-mesa-dri
> Version: 18.2.5-1
> Severity: normal
> 
> Hi,
> 
> the latest version libgl1-mesa-dri (18.2.5-1) break epiphany-browser and
> surf for me.
> 
> Steps to reproduce:
> 
> $ epiphany-browser kde.org
> $ surf kde.org
> 
> Both only produce a white page when the site is loaded. Some other site
> (like debian.org) do work, however. It works again when downgrading this
> package to 18.1.9-1.
> 
> I can also make it work by only downgrading i965_dri.so to the old
> version.

Might be another duplicate of #914267 which is an issue in gcc-8
miscompiling mesa.

You could try my patch in
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=914267#20 which
switches to gcc-7.
or use the pre-compiled binary packages from
https://people.debian.org/~biebl/mesa/

This worked for me.

Regards,
Michael


-- 
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#914267: mesa: [regression] with Mesa 18.2.5-2 the charackter model in Tomb Raider is no longer rendered.

[Michael Biebl]

Control: severity -1 serious

Hi mesa maintainers,

after further contemplating about this, I think this bug is ugly enough
and hard to diagnose for our users, that the package should not enter
testing in this state.
I'm thus raising the severity to RC which will prevent testing migration
and also make the bug more visible to users.

Regards,
Michael
-- 
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#826214: Bug#913247: Please provide a C implementation of /lib/init/init-d-script

[Ian Jackson]

Control: retitle -1 Please would 40-systemd honour __init_d_script_name
Control: reassign -1 src:systemd

Mert Dirik writes ("Re: Bug#826214: Bug#913247: Please provide a C 
implementation of /lib/init/init-d-script"):
> "__init_d_script_name" variable is set inside init-d-script before
> sourcing /lib/lsb/init-functions and it can be used for this purpose.

Now that I reread #913247 I see we are going round in circles.  Thanks
for your patience, Mert, in explaining it again.

Dmitry wrote in #913247:
>  As far as I know, there is no way to modify "$0". So we have two
>  options:
>
>   * have systemd folks use `${__init_d_script_name##*/}' in
> `40-systemd' instead of `$0'
>
>   * write wrapper in C, which sets $0 to value, expected by
> `40-systemd'.  Actually, there is number of utilities floating
> around, which set $0 to arbitrary value (`chpst' from bin:runit is
> one of them :)), but we do not want to add new dependency to
> essentail sysvinit-utils, don't we?

I think reimplementing init-d-script in C is the wrong solution to
this bug.  Certainly, if the only thing it is buying is us an ability
to manipulate $0.  I infer from Dmitry's closing of #913247 which
requests init-d-script in C, that he also doesn't like that idea.

So I think both Dmitry and I are in agreement that the right solution
here is the first of Dmitry's two bullet points above.  Ie, the
sysvinit maintainers are of the opinion that this should be fixed by
amending 40-systemd, which is part of the systemd package.

I'm therefore reassigning this bug.  Benda, if you disagree; or,
Dmitry, if I have misunderstood your view: please do say.

To the systemd maintainers: will you have time to look at this, and
make the appropriate change, soon ?  If not then one of us could
probably prepare a patch, if that would be helpful.

Thanks,
Ian.

-- 
Ian JacksonThese opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Bug#897023: RFS: node-tar-fs

[Paolo Greppi]

Hi, I have packaged node-tar-fs:
https://salsa.debian.org/js-team/node-tar-fs

I am Cc-ing the ITP.

Please someone sponsor the upload.

Paolo

Bug#914296: ITP: node-path-parse -- Node.js path.parse() ponyfill

[Nicolas Mora]

Le 2018-11-22 03:54, Pirate Praveen a écrit :

I suggest you embed it inside (same for other simple dependencies)
node-istanbuljs. See
https://wiki.debian.org/Javascript/Nodejs/Npm2Deb#Embedding_some_modules


Thanks, I will do that.

One question about this process though.

In this case, the package node-path-parse is a dependency of 
node-istanbul on the install stage, but not on the build stage.


So my idea is to copy node-path-parse to 
node-istanbuljs/debian/components and append to the file 
debian/node-istanbul-lib-report.install the new component:


debian/components/node-path-parse/package.json 
usr/lib/nodejs/path-parse/

debian/components/node-path-parse/index.js usr/lib/nodejs/path-parse/

There is no need for a build script.

Do you agree?

Bug#914353: hdbc-odbc: Missing build-dependency on concurrent-extra

[Ilias Tsitsimpis]

Source: hdbc-odbc
Version: 2.3.1.1-9
Severity: serious
Justification: fails to build from source

This package has no reverse dependencies and is not on LTS.
Do we want to continue maintaining it? If so, we will have to package
concurrent-extra.

-- 
Ilias

Bug#826214: Bug#913247: Please provide a C implementation of /lib/init/init-d-script

[Mert Dirik]

On 11/22/18, Ian Jackson  wrote:
> Mert Dirik writes ("Re: Bug#913247: Please provide a C implementation of
> /lib/init/init-d-script"):
>> On 11/22/18, Ian Jackson  wrote:
>> > So I think this would be fixed if /lib/init/init-d-script detected
>> > this situation and set $0 to the original script name (which it gets
>> > in $1).  That is probably desirable anyway.
>>
>> The problem is there is no way of setting $0 inside a shell script as
>> far as I know. So either init-d-script shouldn't be used in shebang or
>> 40-systemd should handle a special case for it (this is up to the
>> systemd maintainers as 40-systemd is in systemd package)
>
> Ah, yes.  I looked at the dash manpage and didn't see anything
> appropriate.  But it would be a simple matter to invent a new
> variable, surely.
>

"__init_d_script_name" variable is set inside init-d-script before
sourcing /lib/lsb/init-functions and it can be used for this purpose.

Bug#914285: dbus: system bus logs repeated denials for session buses calling GetDynamicUsers() on systemd Manager lines

[Francesco Potortì]

>The problem is, this file
>/etc/dbus-1/system.d/org.freedesktop.systemd-shim.conf was removed from
>systemd-shim a long time ago
...
>I'm not sure, why Francesco still had this file around, as there is a
>.maintscript file in systemd-shim which was supposed to clean that up:
...
>So I can only guess, that Francesco had removed, but not purged the
>package before the 8-4 update.

I usually do a manual "aptitude full-upgrade" every day.

>From time to time, I happen to remove packages: in that case I usually
purge them with "aptitude purge", but I see that their dependencies are
not purged, only removed.  Maybe I removed or purged a package that had
systemd-shim as a dependency, or maybe a full-upgrade removed it without
purging it.

Anyway, I just did:

# aptitude purge systemd-shim
The following packages will be REMOVED:
  systemd-shim{p}
0 packages upgraded, 0 newly installed, 1 to remove and 2 not upgraded.
Need to get 0 B of archives. After unpacking 0 B will be used.
Do you want to continue? [Y/n/?] 
(Reading database ... 903812 files and directories currently installed.)
Purging configuration files for systemd-shim (7-1) ...
No diversion 'diversion of 
/usr/share/dbus-1/system-services/org.freedesktop.systemd1.service to 
/usr/share/d\
bus-1/system-services/org.freedesktop.systemd1.service.systemd by 
systemd-shim', none removed.
Processing triggers for dbus (1.12.10-1) ...

and now /etc/dbus-1/system.d/org.freedesktop.systemd-shim.conf doe not
exist any more.

Should you need to know the contenst of any files before this operation,
just ask and I will recover them from backups.

Thanks for maintaining this

Bug#826214: Bug#913247: Please provide a C implementation of /lib/init/init-d-script

[Ian Jackson]

Mert Dirik writes ("Re: Bug#913247: Please provide a C implementation of 
/lib/init/init-d-script"):
> On 11/22/18, Ian Jackson  wrote:
> > So I think this would be fixed if /lib/init/init-d-script detected
> > this situation and set $0 to the original script name (which it gets
> > in $1).  That is probably desirable anyway.
> 
> The problem is there is no way of setting $0 inside a shell script as
> far as I know. So either init-d-script shouldn't be used in shebang or
> 40-systemd should handle a special case for it (this is up to the
> systemd maintainers as 40-systemd is in systemd package)

Ah, yes.  I looked at the dash manpage and didn't see anything
appropriate.  But it would be a simple matter to invent a new
variable, surely.

Ian.

-- 
Ian JacksonThese opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Bug#914352: haskell-hmt: Missing build-dependency on modular-arithmetic

[Ilias Tsitsimpis]

Source: haskell-hmt
Version: 0.15
Severity: serious
Justification: fails to build from source

This package has no reverse dependencies and is not on LTS.
Do we want to continue maintaining it? If so, we will have to package
modular-arithmetic.

-- 
Ilias

Bug#913119: linux-image-4.18.0-2-amd64: Hangs on lvm raid1

[Cesare Leonardi]

I've added some details in #913138, which I believe is the same bug as 
this one.
There a commenter suggested two kernel parameters that, so far, have 
resolved the problem for me.


Cesare.

Bug#914351: [INTL:sv] Swedish strings for ledgersmb debconf

[Martin Bagge / brother]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Package: ledgersmb
Severity: wishlist
Tags: l10n patch

Please consider to add this file to translation of debconf.

- -- 
brother
http://sis.bthstudent.se
-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEVlIsX3Eri6ICyZwJOIRDexPY/4sFAlv2wUgACgkQOIRDexPY
/4tT7Q//TfmQl9SHLUSrwWrzrkQxgypO5nh+i80VPRJYu6plBw29WOIJ0pHXyZ+M
7Ppucmot2QStiGx6qu7DyR4Lht4t/Q948byodJE2lrfpG6q76Hf71zU54rIPxCtj
1IRIvKWvE6B7aks0Az5rekB1KBqZ4DuR+zIpdNm6JrspihdTM9Spljd0X0WNoiON
gKZgXk7JEu69wIRPjCRySAYxnWRfDeFwo6rBPYZAmGgEHxuidkj9M0/qnQ8Ko4sl
Vy0s9aSx3C8SZZnQGMTl5wmms16/UnCAIEfxBkTN7e1+Ha7IpG5NPDUbQL2HQRFK
PZt+8rjWSlv1+eHg2x7MFeYP7CezDEN59FZJPyeJaVOWNGSMfOukjgImeBqd6UJQ
TdfKogvkDOR3s1ONvnUgOf5sYx0cnHGMJThsCWrK95G4V1YNxN8TmmeJ9UPGXlOB
8B2gb6lDZ1dhNfSXJT0ONRd8+tE0aW2m4aEWMAbm2j43CRV9OYQh2nkOLC0VwoQ6
Q7jjySEig/m+9KVOcG23e24vEPRIr6LNKzTfFy+6keyyVu7rAEmr3Z0C+nnN+KjR
/kS8oo0M0OruaJT90d8lOiyZ7QKW2000yGILXKdYpXYWIHFRfYYbob8mpTEmG9dD
G2u7ORBhQ1EjzbU8YFGkYCef09JXG0xLkNdO0kMP9SHLzHBRJkg=
=Ha6m
-END PGP SIGNATURE-
# Translation of ledgersmb debconf template to Swedish
# Copyright (C) 2012, 2018 Martin Bagge 
# This file is distributed under the same license as the ledgersmb package.
#
# Martin Bagge , 2012, 2018
msgid ""
msgstr ""
"Project-Id-Version: ledgersmb\n"
"Report-Msgid-Bugs-To: ledger...@packages.debian.org\n"
"POT-Creation-Date: 2018-03-23 21:01-0400\n"
"PO-Revision-Date: 2018-11-22 15:43+0100\n"
"Last-Translator: Martin Bagge / brother \n"
"Language-Team: Swedish \n"
"Language: sv\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
"X-Generator: Poedit 2.2\n"

#. Type: string
#. Description
#: ../templates:2001
msgid "Database administrative user login:"
msgstr "Administrativ användare för databasen:"

#. Type: string
#. Description
#: ../templates:2001
msgid ""
"Please enter the login of the LedgerSMB database administrative user. This "
"login is needed for the administrative web user interface, typically at "
"http://localhost:5762/setup.pl.;
msgstr ""
"Ange användarnamnet för administration av LedgerSMB-databasen. "
"Användarnamnet behövs för det administrativa webbgränssnittet, vanligen "
"tillgängligt på http://localhost:5762/setup.pl.;

#. Type: password
#. Description
#: ../templates:3001
msgid "Database administrative user password:"
msgstr "Lösenord för databasens administrativa användare:"

#. Type: password
#. Description
#: ../templates:3001
msgid ""
"Please enter the password of the LedgerSMB database administrative user. "
"This password is needed for the administrative web user interface, typically "
"at http://localhost:5762/setup.pl.;
msgstr ""
"Ange lösenordet för LedgerSMBs administrativa användare. Lösenordet behövs "
"för det administrativa webbgränssnittet, vanligen tillgängligt på http://;
"localhost:5762/setup.pl."

#. Type: select
#. Description
#: ../templates:4001
msgid "Web Reverse Proxy to configure?"
msgstr "Ska en baklängesproxy användas?"

#. Type: select
#. Description
#: ../templates:4001
msgid ""
"The LedgerSMB application now defaults to being made available on port 5762, "
"and being run directly by Starman. If other access is needed, a Reverse "
"Proxy can be configured using Apache or Nginx or Lighttpd or Varnish, or you "
"can leave the choice as None if it is not needed or if the web proxy will be "
"set up remotely."
msgstr ""
"LedgerSMB görs numera tillgängligt på port 5762 i standardutförande och körs "
"genom Starman. Det går att installera en baklängesproxy i Apache, Nginx, "
"Lighttpd eller Varnish automatiskt här. Lämna detta alternativt på \"None\" "
"om proxy inte behövs eller installeras på annat sätt."

#. Type: select
#. Description
#: ../templates:4001
msgid ""
"For more details, please see the Web Proxy section that can be found in the /"
"usr/share/doc/ledgersmb/README.Debian file."
msgstr ""
"Läs gärna den detaljerade informationen under avsnittet om Web Proxy i "
"filen /usr/share/doc/ledgersmb/README.Debian."

#, fuzzy
#~| msgid "Configure LedgerSMB automatically?"
#~ msgid "Configure LedgerSMB Database administrative user automatically?"
#~ msgstr "Ska inställningar för LedgerSMB göras automatiskt?"

#, fuzzy
#~| msgid ""
#~| "The configuration program for the package can automatically configure "
#~| "some aspects of LedgerSMB, such as the LedgerSMB database user."
#~ msgid ""
#~ "The configuration program for the package can automatically configure the "
#~ "LedgerSMB database user. Enable if you want to do that, disable if not."
#~ msgstr ""
#~ "Konfigurationsprogrammet för paketet kan göra automatiska inställningar "
#~ "för vissa delar av LedgerSMB, exempelvis LedgerSMBs databasanvändare."

#, fuzzy
#~| msgid ""
#~| "More general information about the initial configuration of the "
#~| "application can be found in /usr/share/doc/ledgersmb/README.Debian."
#~ msgid ""
#~ "More information about the configuration of the 

Bug#913138: linux: I/O on md RAID 6 hangs completely

[Cesare Leonardi]

On Thu, 08 Nov 2018 23:28:16 +0100 =?UTF-8?Q?Stanis=C5=82aw?= 
 wrote:

I suffer the same problem while running RAID1 with kernel 4.18.10-2.


Me too.
For me this happens since the switch from 4.16 to 4.17.x, with two 
different PCs, both with LVM based RAID1. I've already opened bug 
#913119, then I've found this bug report and the reply from Stanislav 
was really helpful for me.
To me this bug, mine and the already closed bug #904822 have the same 
root: the stack traces reported by dmesg are very similar. And the 
common denominators are some sort of LVM RAID and the range of kernel used.



"...Someone else suggested this might be related to using "blk-mq", so
could you try with these parameter:

dm_mod.use_blk_mq=0 scsi_mod.use_blk_mq=0


This seems to have solved the problem for me.
I've tested these boot parameters on one of the affected PC and now it's 
running for more than three days. Before, with kernel from 4.17.x to the 
current Debian's 4.18.10-2+b1, the system showed an oops within 0.5/1 day.


Disabling these parameters is plausible, since Debian's kernel enabled 
SCSI_MQ_DEFAULT and DM_MQ_DEFAULT with 4.17~rc7-1~exp1.



Also, do you have laptop-mode-tools installed?


No, not installed here.

I've checked with two other distributions I have here, to see what they 
have done with SCSI_MQ_DEFAULT and DM_MQ_DEFAULT parameters:


- Arch Linux (kernel 4.18.16-arch1-1-ARCH): both disabled.
- Arch Linux (kernel 4.19.2-arch1-1-ARCH): both enabled.

- Fedora server 29 (kernel 4.18.17-300.fc29.x86_64): both disabled.
- Fedora server 29 (kernel 4.19.2-301.fc29.x86_64): both disabled.

But I was unable to find if upstream is aware of this problem and if 
it's already resolved in 4.19.


Cesare.

Bug#914350: Work round

[Bernie Elbourn]

A complete theme https://addons.thunderbird.net/en-US/thunderbird/addon/phoenity-shredder/ does seem to fix the folder 
display. Screen shot https://drive.google.com/open?id=16gxRlgL0xN-XA7MffWE6GlSNuayRgw4M

Bug#914350: Further information

[Bernie Elbourn]

Screen shot showing faulty display: 
https://drive.google.com/open?id=1twOdSMG8mIC2lHHAmoA2khucXSpXn-Lq

Running from a terminal gives:

$ thunderbird

(thunderbird:27089): GLib-GObject-CRITICAL **: g_object_ref: assertion 
'object->ref_count > 0' failed

(thunderbird:27089): GLib-GObject-CRITICAL **: g_object_unref: assertion 
'object->ref_count > 0' failed

(thunderbird:27089): GLib-GObject-CRITICAL **: g_object_ref: assertion 
'object->ref_count > 0' failed

(thunderbird:27089): GLib-GObject-CRITICAL **: g_object_unref: assertion 
'object->ref_count > 0' failed

(thunderbird:27089): GLib-GObject-CRITICAL **: g_object_ref: assertion 
'object->ref_count > 0' failed

(thunderbird:27089): GLib-GObject-CRITICAL **: g_object_unref: assertion 
'object->ref_count > 0' failed

(thunderbird:27089): GLib-GObject-CRITICAL **: g_object_ref: assertion 
'object->ref_count > 0' failed

(thunderbird:27089): GLib-GObject-CRITICAL **: g_object_unref: assertion 
'object->ref_count > 0' failed

(thunderbird:27089): GLib-GObject-CRITICAL **: g_object_ref: assertion 
'object->ref_count > 0' failed

(thunderbird:27089): GLib-GObject-CRITICAL **: g_object_unref: assertion 
'object->ref_count > 0' failed

(thunderbird:27089): GLib-GObject-CRITICAL **: g_object_ref: assertion 
'object->ref_count > 0' failed

(thunderbird:27089): GLib-GObject-CRITICAL **: g_object_unref: assertion 
'object->ref_count > 0' failed

(thunderbird:27089): GLib-GObject-CRITICAL **: g_object_ref: assertion 
'object->ref_count > 0' failed

(thunderbird:27089): GLib-GObject-CRITICAL **: g_object_unref: assertion 
'object->ref_count > 0' failed

(thunderbird:27089): GLib-GObject-CRITICAL **: g_object_ref: assertion 
'object->ref_count > 0' failed

(thunderbird:27089): GLib-GObject-CRITICAL **: g_object_unref: assertion 
'object->ref_count > 0' failed

(thunderbird:27089): GLib-GObject-CRITICAL **: g_object_ref: assertion 
'object->ref_count > 0' failed

(thunderbird:27089): GLib-GObject-CRITICAL **: g_object_unref: assertion 
'object->ref_count > 0' failed

(thunderbird:27089): GLib-GObject-CRITICAL **: g_object_ref: assertion 
'object->ref_count > 0' failed

(thunderbird:27089): GLib-GObject-CRITICAL **: g_object_unref: assertion 
'object->ref_count > 0' failed

(thunderbird:27089): GLib-GObject-CRITICAL **: g_object_ref: assertion 
'object->ref_count > 0' failed

(thunderbird:27089): GLib-GObject-CRITICAL **: g_object_unref: assertion 
'object->ref_count > 0' failed

(thunderbird:27089): Gtk-CRITICAL **: gtk_icon_theme_lookup_icon_for_scale: 
assertion 'scale >= 1' failed

(thunderbird:27089): Gtk-CRITICAL **: gtk_icon_theme_lookup_icon_for_scale: 
assertion 'scale >= 1' failed

(thunderbird:27089): Gtk-CRITICAL **: gtk_icon_theme_lookup_icon_for_scale: 
assertion 'scale >= 1' failed

(thunderbird:27089): Gtk-CRITICAL **: gtk_icon_theme_lookup_icon_for_scale: 
assertion 'scale >= 1' failed

(thunderbird:27089): Gtk-CRITICAL **: gtk_icon_theme_lookup_icon_for_scale: 
assertion 'scale >= 1' failed

(thunderbird:27089): Gtk-CRITICAL **: gtk_icon_theme_lookup_icon_for_scale: 
assertion 'scale >= 1' failed

(thunderbird:27089): Gtk-CRITICAL **: gtk_icon_theme_lookup_icon_for_scale: 
assertion 'scale >= 1' failed

(thunderbird:27089): Gtk-CRITICAL **: gtk_icon_theme_lookup_icon_for_scale: 
assertion 'scale >= 1' failed

(thunderbird:27089): Gtk-CRITICAL **: gtk_icon_theme_lookup_icon_for_scale: 
assertion 'scale >= 1' failed

(thunderbird:27089): Gtk-CRITICAL **: gtk_icon_theme_lookup_icon_for_scale: 
assertion 'scale >= 1' failed

(thunderbird:27089): Gtk-CRITICAL **: gtk_icon_theme_lookup_icon_for_scale: 
assertion 'scale >= 1' failed

(thunderbird:27089): Gtk-CRITICAL **: gtk_icon_theme_lookup_icon_for_scale: 
assertion 'scale >= 1' failed

(thunderbird:27089): Gtk-CRITICAL **: gtk_icon_theme_lookup_icon_for_scale: 
assertion 'scale >= 1' failed

(thunderbird:27089): Gtk-CRITICAL **: gtk_icon_theme_lookup_icon_for_scale: 
assertion 'scale >= 1' failed

(thunderbird:27089): Gtk-CRITICAL **: gtk_icon_theme_lookup_icon_for_scale: 
assertion 'scale >= 1' failed

(thunderbird:27089): Gtk-CRITICAL **: gtk_icon_theme_lookup_icon_for_scale: 
assertion 'scale >= 1' failed

(thunderbird:27089): Gtk-CRITICAL **: gtk_icon_theme_lookup_icon_for_scale: 
assertion 'scale >= 1' failed

(thunderbird:27089): Gtk-CRITICAL **: gtk_icon_theme_lookup_icon_for_scale: 
assertion 'scale >= 1' failed

(thunderbird:27089): Gtk-CRITICAL **: gtk_icon_theme_lookup_icon_for_scale: 
assertion 'scale >= 1' failed

(thunderbird:27089): Gtk-CRITICAL **: gtk_icon_theme_lookup_icon_for_scale: 
assertion 'scale >= 1' failed

(thunderbird:27089): Gtk-CRITICAL **: gtk_icon_theme_lookup_icon_for_scale: 
assertion 'scale >= 1' failed

(thunderbird:27089): Gtk-CRITICAL **: gtk_icon_theme_lookup_icon_for_scale: 
assertion 'scale >= 1' failed

(thunderbird:27089): Gtk-CRITICAL **: gtk_icon_theme_lookup_icon_for_scale: 
assertion 'scale >= 1' failed

(thunderbird:27089): Gtk-CRITICAL **: 

Bug#912935: botch: the botch autopkgtest fails with Python 3.7

[Johannes Schauer]

Hi ,

On Mon, 05 Nov 2018 15:23:39 +1300 Michael Hudson-Doyle  
wrote:
> The botch autopkgtest fails with Python 3.7 as default, which is now the
> case in Ubuntu. Fortunately the reason is pretty trivial, patch
> attached.

thanks for reporting this bug!

But please, when supplying a patch, test the patch before you submit it or
otherwise I will spend time testing a patch even though it still results in a
FTBFS due to the changes made in the patch.

Alternatively, just point out that the patch you attached was not tested.

Thanks!

cheers, josch


signature.asc
Description: signature

Bug#912223: auto-wrapping in the web interface Bad

[Bernhard Übelacker]

Hello,

On Tue, 30 Oct 2018 18:47:41 -0700 Don Armstrong  wrote:
> On Mon, 29 Oct 2018, Peter Palfrader wrote:
> > debbugs tries to wrap messages such as
> >  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=912215#10
> > in its web interface.
> > 
> > This makes the message entirely unreadable.
> 
> Heh; that one shouldn't be wrapped. We need something to do
> wrapping because people send messages which aren't wrapped either, so
> I'm going to try to tweak this to not fire on messages which look
> rectangular and still follow the 80 column wide convention.

Could such unwrapped sentences and gdb backtraces just be separted
by ignoring lines starting with '#' ?

Kind regards,
Bernhard

Bug#898821: maven-plugin-tools: FTBFS with Java 10 due to com.sun.tools.doclets removal

[Emmanuel Bourg]

Control: tags -1 + fixed-upstream

This issue has been "solved" upstream in the version 3.6 by dropping
support for javadoc annotations. This means we have to convert the
plugins still using these javadoc annotations to use the Java
annotations instead [2].

[1] https://issues.apache.org/jira/browse/MPLUGIN-336
[2]
https://maven.apache.org/plugin-tools/maven-plugin-plugin/examples/using-annotations.html

Bug#914172: [debian-mysql] Bug#914172: Bug#914172: Bug#914172: Bug#914172: mariadb-server-10.1: mariadb-server sec-update (10.1.37-0+deb9u1) uninstalls default-mysql-server, mysql-server, mariadb-serv

[Faustin Lammler]

> This, plus the restriction in the apt command to only use security sources,
> makes dist-upgrade remove any package with a failed dependency.
Thanks David for this (and Olaf for your initial guess), it is now clear to me
what happened.

Let me check with Otto why this new dependence was added.

Regards,
Faustin

Bug#822753: /lib/init/init-d-script: exit 0 at end of script prevents all other exit codes

[Dmitry Bogatov]

[2018-11-20 21:25] Michael Biebl 
> fwiw, this is why I suggested to provide a C implementation of
> init-d-script which can be used as an interpreter
> 
> See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=913247
> 
> I consider the usage of /usr/bin/env only a kludge and hope the
> maintainers of /lib/init/init-d-script do reconsider, i.e. I don't
> consider #913247 to be solved.

I consider extra 13 chars in shebang to be less sacrifice for kFreeBSD
compatibility then need to write and maintain extra C program. Line
added, line spent.

By the way, what is your resolution about changes I proposed

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=913247#45

in regard systemctl forwarding?

Bug#914350: thunderbird: click arrows indicating sub-folders are not displayed

[Bernie Elbourn 07974226865]

Package: thunderbird
Version: 1:60.3.0-1~deb8u1
Severity: important

Dear Maintainer,

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

   * What led up to the situation?

apt-get upgrade

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

safe mode, backport intel screen driver,new profile - none fix
a simple downgrade fixes folder list display:
apt-get install thunderbird=1:52.8.0-1~deb8u1 
calendar-google-provider=1:52.8.0-1~deb8u1 lightning=1:52.8.0-1~deb8u1

   * Whatddd was the outcome of this action?

folder display restored

I will try to place a screen in your view to clarify

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

Kernel: Linux 4.9.0-0.bpo.6-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: systemd (via /run/systemd/system)

Versions of packages thunderbird depends on:
ii  debianutils   4.4+b1
ii  fontconfig2.11.0-6.3+deb8u1
ii  libatk1.0-0   2.14.0-1
ii  libc6 2.19-18+deb8u10
ii  libcairo-gobject2 1.14.0-2.1+deb8u2
ii  libcairo2 1.14.0-2.1+deb8u2
ii  libdbus-1-3   1.8.22-0+deb8u1
ii  libdbus-glib-1-2  0.102-1
ii  libevent-2.0-52.0.21-stable-2+deb8u1
ii  libffi6   3.1-2+deb8u1
ii  libfontconfig12.11.0-6.3+deb8u1
ii  libfreetype6  2.5.2-3+deb8u2
ii  libgcc1   1:4.9.2-10+deb8u1
ii  libgdk-pixbuf2.0-02.31.1-2+deb8u7
ii  libglib2.0-0  2.42.1-1+b1
ii  libgtk-3-03.14.5-1+deb8u1
ii  libgtk2.0-0   2.24.25-3+deb8u2
ii  libpango-1.0-01.36.8-3
ii  libpangocairo-1.0-0   1.36.8-3
ii  libpangoft2-1.0-0 1.36.8-3
ii  libstartup-notification0  0.12-4
ii  libstdc++64.9.2-10+deb8u1
ii  libx11-6  2:1.6.2-3+deb8u2
ii  libx11-xcb1   2:1.6.2-3+deb8u2
ii  libxcb-shm0   1.10-3+b1
ii  libxcb1   1.10-3+b1
ii  libxext6  2:1.3.3-1
ii  libxrender1   1:0.9.8-1+b1
ii  libxt61:1.1.4-1+b1
ii  psmisc22.21-2
ii  x11-utils 7.7+2
ii  zlib1g1:1.2.8.dfsg-2+b1

Versions of packages thunderbird recommends:
ii  hunspell-en-us [hunspell-dictionary]  20070829-6+deb8u1
ii  lightning 1:60.3.0-1~deb8u1
ii  myspell-en-gb [myspell-dictionary]1:3.3.0-4+deb8u1

Versions of packages thunderbird suggests:
pn  apparmor  
ii  fonts-lyx 2.1.2-2
ii  libgssapi-krb5-2  1.12.1+dfsg-19+deb8u4

-- no debconf information

Bug#913247: Please provide a C implementation of /lib/init/init-d-script

[Mert Dirik]

On 11/22/18, Ian Jackson  wrote:
> Mert Dirik writes ("Re: Bug#913247: Please provide a C implementation of
> /lib/init/init-d-script"):
>> On 11/22/18, Ian Jackson  wrote:
>> > I don't know what `systemd redirection' is.  Why does it not work ?
>> > Can it be fixed ?
>>
>> To sum it up, when /lib/lsb/init-functions is sourced from a script in
>> /etc/init.d, /lib/lsb/init-functions.d/40-systemd is also sourced and
>> the script is executed using a corresponding "systemctl " command
>> so that systemd can track the daemon. Relevant bug report is #826214.
>
> Thanks.
>
> This doesn't seem so difficult to fix.  (CCing that bug.)
>
>> The problem here is, 40-systemd uses the value of "$0" to figure out
>> whether the caller  was a script inside /etc/init.d/ and using
>
> I just experimented:
>
> mariner:d> pwd
> /u/iwj/junk/d
> mariner:d> egrep . init-d-script daemon
> init-d-script:#!/bin/sh
> init-d-script:echo "in init-d-script \$0=$0 \$*=$*"
> daemon:#!/usr/bin/env /u/iwj/junk/d/init-d-script
> daemon:some thing or other
> mariner:d> ./daemon start
> in init-d-script $0=/u/iwj/junk/d/init-d-script $*=./daemon start
> mariner:d>
>
> So I think this would be fixed if /lib/init/init-d-script detected
> this situation and set $0 to the original script name (which it gets
> in $1).  That is probably desirable anyway.

The problem is there is no way of setting $0 inside a shell script as
far as I know. So either init-d-script shouldn't be used in shebang or
40-systemd should handle a special case for it (this is up to the
systemd maintainers as 40-systemd is in systemd package)

Bug#914317: dgit: less than helpful error if debian/patches/ exists as untracked files

[Sean Whitton]

Hello,

On Thu 22 Nov 2018 at 11:04AM GMT, Ian Jackson wrote:

> Sean Whitton writes ("Bug#914317: dgit: less than helpful error if 
> debian/patches/ exists as untracked files"):
> ...
>> 4) Now you have uncommitted debian/patches, but ignore that, and instead
>>commit your upstream changes
>>
>> 5) dgit sbuild (or whatever), and you get:
>
> (Without looking at the source, or the docs:)
>
> Why does this not complain about the uncommitted files in
> debian/patches ?  Clearly you're not using --clean=git.  Are you using
> --clean=dpkg-source,no-check or something ?  Or is debian/patches in
> your .gitignore ?

I have clean-mode = git-ff in my ~/.gitconfig.  So, good question.

https://salsa.debian.org/haskell-team/git-annex is the repo.

c6dda1ee is the committed changes, so to try to reproduce, you would

git reset --hard c6dda1ee~1
git apply c6dda1ee

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#914349: grub-customizer: should hint that it enhances grub-pc grub-efi-ia32 grub-efi-amd64 etc.

[Jonas Smedegaard]

Package: grub-customizer
Version: 5.1.0-1
Severity: minor

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Long desription indicates that grub-customizer is a helper tool for GRUB.

As such, please add hint to control file that it "Enhances:" each of the
instances of GRUB available in Debian, so as to aid users in discovering
this addon package.

 - Jonas

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAlv2vb4ACgkQLHwxRsGg
ASGjfw/+LMA5cTYhof1WvWeCdrcht0SaSlAySrzZMSiad0L1DNdGaKG0bgUFg9F/
w19Z/KlzSFzhkm2kimHL3doRZ4VOLdQ+RlEpRDL15Jlxrg5PKI+mMxwMqo6tPgPr
YgnNV+HoV61IgY2P1+kNZ58iv/g/rId8lxaVQDenpvjgIZnTMhvjS2r5jpqYQoi6
3LBjmsoZrBUp72nQ8HByl4XK2ArEWqDKQSvgUwj5Z9H2zPx+7i1MUZS9GDAu8uPC
vL+PO0tpJVUJMQ/mTcW5undMQx+nk9nBNO/rjZKwvV0SxuG8ZMcJkCete5a5RRTp
oNP8P6pxCnJgXmM/2ok7aZhmnObjyrBAXHlh950HGAeMuWVAsgp32Rm178FXvcxD
XRcrnydb39C8fPAp7Iw6hPUIbZV87ipqfS9nO1U3fXRdsDOe7T3Ky93NknFxQpAg
hUjvhmqXcF/TEaTOUmf2YcjRRnYWS+KIN4HA5V4Y2oUDnvQpTA7/3/gDqBdfyIzI
HtOILdK9AWjgc8GoXIMjK8pODpSSvY67i1KxLEiYaoJFXTl4ZQ4Dxu17btPVj0+x
1FdxNsAv/HsFC0A7kkWow0HkZN80NDKE8Cy7UFN50067l/zk7tER0dWqB0wbbmWi
cdjKIZVuze0Fkna46KhETfGF03o3kTL+0CH/KlvHxNhm8mdOsp8=
=I325
-END PGP SIGNATURE-

Bug#914348: ndctl: fails to build on some architectures

[Jeremy Bicha]

Source: ndctl
Version: 63-1
Severity: important

ndctl fails to build on hppa and powerpc.

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

/usr/bin/ld: ../util/json.o: in function `compare_dimm_number':
./ndctl/../util/json.c:381: undefined reference to `ndctl_dimm_get_devname'
/usr/bin/ld: ./ndctl/../util/json.c:382: undefined reference to
`ndctl_dimm_get_devname'


This issue is a bit annoying for libblockdev. Since I can't use
negative wildcards in the Architecture field (like Architecture: !hppa
!powerpc), I have to include a very long list of whitelisted
architectures if I want libblockdev to build everywhere and build its
nvdimm plugin on architectures where it's available.

Thanks,
Jeremy Bicha

Bug#826214: Bug#913247: Please provide a C implementation of /lib/init/init-d-script

[Ian Jackson]

Mert Dirik writes ("Re: Bug#913247: Please provide a C implementation of 
/lib/init/init-d-script"):
> On 11/22/18, Ian Jackson  wrote:
> > I don't know what `systemd redirection' is.  Why does it not work ?
> > Can it be fixed ?
> 
> To sum it up, when /lib/lsb/init-functions is sourced from a script in
> /etc/init.d, /lib/lsb/init-functions.d/40-systemd is also sourced and
> the script is executed using a corresponding "systemctl " command
> so that systemd can track the daemon. Relevant bug report is #826214.

Thanks.

This doesn't seem so difficult to fix.  (CCing that bug.)

> The problem here is, 40-systemd uses the value of "$0" to figure out
> whether the caller  was a script inside /etc/init.d/ and using

I just experimented:

mariner:d> pwd
/u/iwj/junk/d
mariner:d> egrep . init-d-script daemon
init-d-script:#!/bin/sh
init-d-script:echo "in init-d-script \$0=$0 \$*=$*"
daemon:#!/usr/bin/env /u/iwj/junk/d/init-d-script
daemon:some thing or other
mariner:d> ./daemon start
in init-d-script $0=/u/iwj/junk/d/init-d-script $*=./daemon start
mariner:d>

So I think this would be fixed if /lib/init/init-d-script detected
this situation and set $0 to the original script name (which it gets
in $1).  That is probably desirable anyway.

Ian.

-- 
Ian JacksonThese opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Bug#913187: FTBFS on s390x

[Ilias Tsitsimpis]

Control: reassign 913187 libghc-libxml-sax-dev 0.7.5-9
Control: affects 913187 + haskell-dbus

This seems to be a bug either in libxml-sax, or in ghc itself. I am not
sure about this, but I have opened a bug against ghc here:

   https://ghc.haskell.org/trac/ghc/ticket/15933

The author of haskell-dbus is in the process of replacing libxml-sax,
since it is outdated and unmaintained.

In the meantime, I will patch libxml-sax to at least allow haskell-dbus
to build on s390x.

Cheers,

-- 
Ilias

Bug#913247: Please provide a C implementation of /lib/init/init-d-script

[Mert Dirik]

On 11/22/18, Ian Jackson  wrote:
> Mert Dirik writes ("Bug#913247: Please provide a C implementation of
> /lib/init/init-d-script"):
>> I noticed the new snippet in the man page of experimental version uses
>> the
>> #! /usr/bin/env /lib/init/init-d-script
>> shebang, which doesn't work with systemd redirection.
>
> I don't know what `systemd redirection' is.  Why does it not work ?
> Can it be fixed ?
>

To sum it up, when /lib/lsb/init-functions is sourced from a script in
/etc/init.d, /lib/lsb/init-functions.d/40-systemd is also sourced and
the script is executed using a corresponding "systemctl " command
so that systemd can track the daemon. Relevant bug report is #826214.

The problem here is, 40-systemd uses the value of "$0" to figure out
whether the caller  was a script inside /etc/init.d/ and using
/lib/init/init-d-script breaks that. We partially fixed this in
init-d-script so that using the old "set "$0" "$@";
INIT_D_SCRIPT_SOURCED=true . /lib/init/init-d-script" snippet (as it
was in the /etc/init.d/skeleton) works correctly, but if
/lib/init/init-d-script (or /usr/bin/env) is used as shebang there is
no way to fix it inside init-d-script since dash scripts can't change
the value of $0.

I'm in the process of writing a longer opinion mail on
/lib/init/init-d-script but it's not finished yet.

Bug#907105: Bug#909105: consider switching asciidoctor to Architecture: all

[Jeremy Bicha]

Could you go ahead and do this upload now?

Since asciidctor didn't build on ia64, this upload is blocking
packages like ndctl from being available on that architecture.

I see there is a new asciidoctor 1.5.8 release now if you want to do
multiple things in this upload. :)

Thanks,
Jeremy Bicha

Bug#914347: vtk7: FTBFS against python 3.7.1 (now the default for python3)

[Gilles Filippini]

Source: vtk7
Version: 7.1.1+dfsg1-9
Severity: serious
Justification: FTBFS

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi,

Python 3.7.1 is now the default for python3 [1], and vtk7 FTBFS [2] against 
this version:

/<>/vtk7-7.1.1+dfsg1/Wrapping/PythonCore/vtkPythonArgs.cxx: In 
instantiation of 'bool vtkPythonGetStringValue(PyObject*, T*&, const char*) 
[with T = char; PyObject = _object]':
/<>/vtk7-7.1.1+dfsg1/Wrapping/PythonCore/vtkPythonArgs.cxx:287:66:   
required from here
/<>/vtk7-7.1.1+dfsg1/Wrapping/PythonCore/vtkPythonArgs.cxx:105:25: 
error: invalid conversion from 'const char*' to 'char*' [-fpermissive]
 a = PyUnicode_AsUTF8(o);
 ^~~

[1] 
https://tracker.debian.org/news/1004786/accepted-python3-defaults-371-2-source-into-unstable/
[2] 
https://buildd.debian.org/status/fetch.php?pkg=vtk7=amd64=7.1.1%2Bdfsg1-9%2Bb1=1542847447=0
 

Thanks,

_g.

- -- System Information:
Debian Release: buster/sid
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.14.0-3-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

-BEGIN PGP SIGNATURE-

iQEzBAEBCgAdFiEEoJObzArDE05WtIyR7+hsbH/+z4MFAlv2tzgACgkQ7+hsbH/+
z4OytAgAnzaibDNKJjCUMSEdLLY/L4zEQOkxGkTc8EYN084aU8ndQK1XP/M9HVdO
lI47VlRGLJzPsUlpzH0/nLvD/0Z+TQZuibZMlq6unZSXqwmCcMmS6mEiOGqOL+yO
u6TyPeTfBpGRsnFycY7RT/1VbfcyHsxRLd9ipTf9/3OWU+DxmWjm0xCnzuJjfUa4
rQdv8BrEQbPHH3WWHNZkhCvbJ7nQSfLB2HQwwbt1FLlZS6o/QByGb64KLS1yfg3p
MBZ3Ct5oAQ6NX87BGu1tiYeM6E5OKggKYWyAzbZrziMojIMqiteNjcQSDV7pq7b6
iCtv/bUAFc2AhRywKQ5fSu+dGdyPAA==
=ohUZ
-END PGP SIGNATURE-

Bug#914346: rover: Please indent list items in long description

[Jonas Smedegaard]

Package: rover
Version: 0.3
Severity: minor

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

rover long description includes an enumeration of features.

Unfortunately that list is not recognized as such, likely (I didn't
check source) because those lines are not indented as desribed in
Debian Policy §5.6.13: Add an additional leading space to avoid
line-wrapping and merging of multiple lines.

 - Jonas

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAlv2tqYACgkQLHwxRsGg
ASHGmg//aoMbicMuASMu7maoUUaz/sD3/Lh7K8qrY2121IiRFAsJTeAqt8MMReaD
ZE0nSIxcWzi4TldIE+x7o/MX4Z8IwD/jwdk1TVA6suXJn0f6dW8jg+O3vUrn4A+9
oEio83UEVv/tMy0wyAAGGyXON1lzzmCzScDq+Msm+LFdx8tsCkrD+oPrcGPxOeuv
JSlMcfVpiySS02nDjyt2cgVvzqQBBfZMM6HPKqtmKry38mkKyFndE77y0ZcbI8Hn
SL3D5bVKup+56P8JJ++VIbPmis8v4TnOTgvOg8ScdhAHSMvX5MBrrst1EsYMtJh+
iQF7Ioa3JO6rDIEBlVCLn/OLT7XFEx6NR9cEXHj1sI9C/22IS/3E/dxPtxwQYlzz
DnVJlE66ZFrqW5OX3yhOvnVFFTtNuT7DaqawSClpaUyvwrxgFiHrQAq1ADY/lhBJ
2knmpBzO0Y659W7hFJn11nI2glW1YIJ9cDvbjIZpS5D+frWLWjRMabh8oL94953H
jQwe9BntBMPEiTc0oMLbPqprKxxO+OOPti6Je38W5dziHMH554S1hdrUJNxK/+bi
yvTj2FP6IHEtQnKPUE4Z2onQVYhmWRXnvilVVG40nN30MWtFofzYtTYA1ZkDFcXC
wIIr64rqD//9j1ZQJZk/xsoebKyHsJfzWWrD3jAqR/wWkEMZ2tU=
=erJG
-END PGP SIGNATURE-

Bug#914345: pcmanfm-qt: the desktop background should be compliant with desktop-base

[Wolfgang Schweer]

Package: pcmanfm-qt
Version: 0.13.0-2
Severity: wishlist

Hi Alf,

while testing Debian Edu Buster with LXQt, I noticed that the background image
can't be set systemwide w/o tweaking the settings.conf file (and we want to
avoid doing this). While users are free to choose the background image, there
should be a first Debian Edu branded one. 

Running 'update-alternatives --config desktop-theme' allows to choose the
Debian Edu theme as 'active-theme'. For other desktop environments the releated
background image is shown. LXQt is dfferent, but it would be nice if at least
settings.conf could be changed to show the active theme background (same
resolution as lxqt-origami-light.png).

diff --git a/config/pcmanfm-qt/lxqt/settings.conf.in 
b/config/pcmanfm-qt/lxqt/settings.conf.in
index b7ef002..599a7a3 100644
--- a/config/pcmanfm-qt/lxqt/settings.conf.in
+++ b/config/pcmanfm-qt/lxqt/settings.conf.in
@@ -15,7 +15,7 @@ ConfirmDelete=true
 
 [Desktop]
 WallpaperMode=stretch
-Wallpaper=@LXQT_SHARE_DIR@/themes/frost/lxqt-origami-light.png
+Wallpaper=/usr/share/desktop-base/active-theme/wallpaper/contents/images/1920x1080.svg
 BgColor=#00
 FgColor=#ff
 ShadowColor=#00 

Please check.

Wolfgang

Bug#914263: cabextract: -F option doesn't work correctly.

[Eric Sharkey]

On Thu, Nov 22, 2018 at 7:53 AM Eric Sharkey  wrote:

> No, I think this is a duplicate of bug 912687.
>

Or, if you prefer, I can add a versioned dependency for cabextract on
libmspack >= 0.9.1-1 to ensure that cabextract will function properly.

Eric

Bug#913247: Please provide a C implementation of /lib/init/init-d-script

[Ian Jackson]

Mert Dirik writes ("Bug#913247: Please provide a C implementation of 
/lib/init/init-d-script"):
> I noticed the new snippet in the man page of experimental version uses the
> #! /usr/bin/env /lib/init/init-d-script
> shebang, which doesn't work with systemd redirection.

I don't know what `systemd redirection' is.  Why does it not work ?
Can it be fixed ?

Ian.

-- 
Ian JacksonThese opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Bug#914344: gdb: record feature leads to Assertion `lwp_is_stopped (lwp)' failed

[Bernhard Übelacker]

Package: gdb
Version: 8.1-4+b1
Severity: normal
Tags: upstream

Dear Maintainer,

while trying to debug #914300 I wanted to use the record feature of gdb.

Unfortunately that stopped on me with an assertion failed.
See at the bottom of this mail for an example run.

I was able to find the issue starting between these debian packages.
- gdb-minimal_7.10-1.1 works
- gdb-minimal_7.11.1-1 fails

This upstream bug [1] seems to handle that exact issue.
There I have forwarded my findings and a git bisect result,
of which commit [2] has introduced this.

Kind regards,
Bernhard

[1] https://sourceware.org/bugzilla/show_bug.cgi?id=20456
[2] 
https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=patch;h=398e081380a204e3b9fb4eb4da069ccf471f930e


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

Kernel: Linux 4.18.0-2-amd64 (SMP w/8 CPU cores)
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 gdb depends on:
ii  libbabeltrace1  1.5.6-1
ii  libc6   2.27-8
ii  libexpat1   2.2.6-1
ii  libipt2 2.0-2
ii  liblzma55.2.2-1.3
ii  libncursesw66.1+20181013-1
ii  libpython3.63.6.7-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.27-8

Versions of packages gdb suggests:
pn  gdb-doc
pn  gdbserver  

-- no debconf information





benutzer@debian:~$ gdb -q --args kalgebra
Reading symbols from kalgebra...Reading symbols from 
/usr/lib/debug/.build-id/db/c25dd2c87a837265a5fccb742e0b65684c3166.debug...done.
done.
(gdb) b ConsoleHtml::clear
Breakpoint 1 at 0x1edc0: file ./src/consolehtml.cpp, line 225.
(gdb) run
Starting program: /usr/bin/kalgebra 
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[New Thread 0x7fffdce9d700 (LWP 22111)]
[New Thread 0x7fffd3078700 (LWP 22112)]
[New Thread 0x7fffd2877700 (LWP 22113)]
[New Thread 0x7fffd2076700 (LWP 22114)]
[New Thread 0x7fffd1875700 (LWP 22115)]
[New Thread 0x7fffd1074700 (LWP 22116)]
[New Thread 0x7fffd0873700 (LWP 22117)]
[New Thread 0x7fffbbfff700 (LWP 22118)]
[New Thread 0x7fffb37fe700 (LWP 22119)]
[New Thread 0x7fffbb7fe700 (LWP 22120)]
[New Thread 0x7fffba793700 (LWP 22122)]
[New Thread 0x7fffb9f92700 (LWP 22124)]
[New Thread 0x7fffb9791700 (LWP 22125)]
[New Thread 0x7fffb8f90700 (LWP 22126)]
[New Thread 0x7fffb3fff700 (LWP 22127)]
[New Thread 0x7fffb2ffd700 (LWP 22128)]
[New Thread 0x7fffb27fc700 (LWP 22129)]
[New Thread 0x7fffb1ffb700 (LWP 22130)]
[New Thread 0x7fffb17fa700 (LWP 22131)]
[New Thread 0x7fffb0ff9700 (LWP 22132)]
[New Thread 0x7fff83fff700 (LWP 22133)]
[New Thread 0x7fff837fe700 (LWP 22134)]
[New Thread 0x7fff82ffd700 (LWP 22135)]
[New Thread 0x7fff827fc700 (LWP 22136)]
[New Thread 0x7fff81ffb700 (LWP 22137)]
[New Thread 0x7fff817fa700 (LWP 22138)]
[New Thread 0x7fff80ff9700 (LWP 22139)]
[New Thread 0x7fff5700 (LWP 22140)]
[New Thread 0x7fff5f7fe700 (LWP 22141)]
[New Thread 0x7fff5effd700 (LWP 22142)]
[New Thread 0x7fff5e7fc700 (LWP 22143)]
[New Thread 0x7fff5dffb700 (LWP 22144)]
[New Thread 0x7fff5d7fa700 (LWP 22152)]
[New Thread 0x7fff43fff700 (LWP 22161)]
[Thread 0x7fff43fff700 (LWP 22161) exited]

Thread 1 "kalgebra" hit Breakpoint 1, ConsoleHtml::clear (this=0x55ab9ff0) 
at ./src/consolehtml.cpp:225
225 ./src/consolehtml.cpp: No such file or directory.
(gdb) record
(gdb) cont
Continuing.
/build/gdb-KOFU8D/gdb-8.1/gdb/nat/x86-linux-dregs.c:146: internal-error: void 
x86_linux_update_debug_registers(lwp_info*): Assertion `lwp_is_stopped (lwp)' 
failed.
A problem internal to GDB has been detected,
further debugging may prove unreliable.
Quit this debugging session? (y or n) 

Bug#914271: lintian: Rationale behind hyphen-in-upstream-part-of-debian-changelog-version

[Guillem Jover]

On Thu, 2018-11-22 at 13:24:04 +0100, Johannes Schauer wrote:
> Quoting Guillem Jover (2018-11-22 13:12:05)
> > > in your original commit you were talking about "some tools".
> > > 
> > > This suggests that you know tools that behave wrongly.
> > > 
> > > If you share the tools you know of, then we could file bugs.
> > 
> > I think that would be difficult, I'm afraid the bulk of these
> > tools are human brains! :D
> > 
> > See for example #911341 which is something I recently stumbled upon.
> > The tools here work as intended, but the human made a very
> > comprehensible mistake.
> > 
> > I mean, yes, we could improve lintian, perhaps even some of
> > dpkg-gensymbols, and similar to warn or maybe not propose this kind
> > of situation, but in the end, any time you strip the revision in any
> > dependency field or similar, you can end up with broken comparisons
> > given the current algorithm.
> 
> I then suggest two things:
> 
> Instead of checking whether the upstream version contains dashes, check 
> whether
> the .symbols file contains a version format that avoids bugs like #911341.
>
> Improve the tag description to be more explicit about which problem is being
> solved, for example by making the tag specific for the symbols file error.

The problem is that we have recommendations around to remove the
revision in some cases, for example from build-dependencies (I think
there's even a tag for that). And people do that also when declaring
dependencies when the relevant relationship is against the upstream
part and not the packaging part.

Having an explicit check for the symbols stuff would be nice, but I
think it's besides the point. In the same way epochs in upstream
version are problematic, dashes in upstream versions are too IMO.

> Additionally: I don't know how the machinery works that compares versions in
> symbols files, but maybe it could be improved to make sure that this kind of
> problem doesn't happen anymore?

Actually the dpkg-gensymols file does not strip the revision, so
that's human made. To try to cope with these cases the code in
dpkg-shlibdeps would need to traverse all debian/changelog entries
and try to _infer_ from the versions seen there which ones have had
their revisions stripped. This might not always work, I'm afraid,
f.ex. say we have this:

 1.0-1
 1.0-1-1

:) This is all very fuzzy.

Thanks,
Guillem

Bug#741356: unattended-upgrades: enhancements to InstallOnShutdown mode

[Balint Reczey]

Control: forwarded -1 https://github.com/mvo5/unattended-upgrades/issues/155
Control: retitle -1 Please support Offline System Updates
Control: tags -1 - patch + help

Hi Simon,

On Mon, Jul 17, 2017 at 12:05 AM Balint Reczey
 wrote:
>
> Hi Simon,
>
> On Thu, 9 Mar 2017 10:47:02 + Simon McVittie  wrote:
> > Control: retitle 741356 Do not rely on networking during InstallOnShutdown
> >
> > On Wed, 12 Mar 2014 at 19:39:25 +, Simon McVittie wrote:
> > > Any thoughts on this?
> >
> > For what it's worth, this and some other tweaks have been in production
> > use on SteamOS for quite a while. I attach less-outdated debdiffs in case
> > they are useful.
> >
> > I am not actively working on this module, and I have not reviewed the
> > forward-ports or the new changes; please let me know if there is any
> > possibility of getting this integrated, and I can try to get some time to
> > forward-port changes or respond to review, or have a colleague take over.
>
> Thanks for the bugreport and the patches!
> Part of your proposal has been implemented in apt 1.4.2 by separating
> the download and install phases. The u-u side reported in #863911
>  will be in
> next u-u upload.
>
> Since latest u-u NMU nattended-upgrades.service also contains
> After=network.target which ensures that network is up while u-u-s is
> running instead of not relying on network being available.
>
> You are very welcome to forward-port SteamOS updates here especially in
> a form of
> smaller commits, but please wait for the next update first because it
> merges many changes from Debian BTS and Ubuntu.

Since last time we discussed this bug some other problems surfaced
regarding how u-u handles the upgrades on shutdown, and I think 1.7
solved the solvable issues [1].
I also considered adding a mode that upgrades packages on shutdown
without networking enabled, but I did not find a solution that would
not break something else.
OTOH I'm open to adding a mode which would use systemd's
offline-updates and optionally always reboot again after the upgrade
steps answering the issue you raised in [2].

At the moment I'm satisfied with the modes u-u provides and I'd like
to work on other parts to make upgrades smoother thus I don't plan
working on this mode but as I said I'd be happy to merge patches and
have it implemented.

Cheers,
Balint

[1] 
https://tracker.debian.org/news/1001416/accepted-unattended-upgrades-17-source-into-unstable/
[2] https://lists.debian.org/debian-devel/2014/09/msg00501.html

--
Balint Reczey
Ubuntu & Debian Developer

Bug#914343: usrmerge did not install by default - some libs disturb

[Hans-J. Ullrich]

Package: usrmerge
Severity: important

Dear Maintainer,

today I installes usrmerge on my canary system, where I am testing new things.
After download usrmerge inihibites to install and mourned about existing libs.

These were 

/sbin/ebtables*
/usr/sbin/ebtables*

/lib/libntrack-qt4.so.1
/usr/lib/libntrack-qt4.so.1

After deleting them, installation (crossing fingers) of usrmerge went fine. 
Maybe the mentioned libs are rather old, as my systems are running since 
debian 2.2 and have only be dist-upgraded since that installation. (So you can 
also see, how nice debian is working!)

The mentioned libs: Must I reinstall them?
 
After the merge I did my weekly update and it looked everything as working fine.

Hope my little feedback helps.

Best regards

Hans

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

Kernel: Linux 4.18.0-2-686-pae (SMP w/2 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.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 usrmerge depends on:
ii  debconf [debconf-2.0]   1.5.69
pn  libfile-find-rule-perl  

usrmerge recommends no packages.

usrmerge suggests no packages.

Bug#906795: x2goserver 4.1.0.2-1 owncloud client won't start (TESTING)

[Mike Gabriel]

Control: reassign -1 x2goserver-x2goagent
Control: found -1 4.1.0.2-1

Hi,

On  Sa 10 Nov 2018 13:15:34 CET, Juri Grabowski wrote:


Hello together,

after some tests with texworks, nextcloud, owncloud, it looks like you
need to activate BIG-REQUESTS extension. ( Thanks to Mike and Uli )

/etc/x2go/x2goagent.options
X2GO_NXAGENT_DEFAULT_OPTIONS+=" +extension BIG-REQUESTS"

Next nxagent version should fix similar error with vscode.

Best Regards,
Juri Grabowski


This issue will likely be fixed with release of src:x2goserver 4.1.0.3  
which is due soon.


Mike
--

DAS-NETZWERKTEAM
mike gabriel, herweg 7, 24357 fleckeby
mobile: +49 (1520) 1976 148
landline: +49 (4354) 8390 139

GnuPG Fingerprint: 9BFB AEE8 6C0A A5FF BF22  0782 9AF4 6B30 2577 1B31
mail: mike.gabr...@das-netzwerkteam.de, http://das-netzwerkteam.de



pgp9NR2XIVgRx.pgp
Description: Digitale PGP-Signatur

Bug#843021: yarnpkg 1.12.3 is out, here is an update on how far are we from packaging it

[Paolo Greppi]

For an up-to-date overview on the TODOs see this wiki page on salsa:
https://salsa.debian.org/js-team/node-yarnpkg/wikis/home

Thanks to the new embedding policy, I think it is feasible to complete the job 
for the buster release.
I plan to resume working on it, any help welcome !

W.r.t. the previous time I looked (version 1.7.0) the dependencies have not 
changed much:
- Upgraded and OK in Debian:
  - request, needs 2.87.0 while 2.88.0 is in Debian
- Upgraded and must be upgraded in Debian: 
  - inquirer: 3.3.0 -> 6.2.0
  - tar-stream: 1.5.2 -> 1.6.0
  - validate-npm-package-license: 3.0.1 -> 3.0.4
- New and not in Debian yet:
  - cli-table3 (Pretty unicode tables for the command line. Based on the 
original cli-table); we could use cli-table ...
  - hash-for-dep (generates a hash that represents a module and its depenencies 
uniqueness)
- New and should be updated in Debian:
  - imports-loader: 0.7.1 -> 0.8.0
  - ssri: 5.2.4 -> 5.3.0

While for the build dependencies:
- Upgraded and must be upgraded in Debian: 
  - execa: 0.10.0 -> 0.11.0
  - fancy-log: 1.2.0 -> 1.3.2
  - gulp: 3.9.1 -> 4.0.0
- Removed:
  - gulp-util
  - gulp-watch

Paolo

Bug#822753: /lib/init/init-d-script: exit 0 at end of script prevents all other exit codes

[Ian Jackson]

Michael Biebl writes ("Bug#822753: /lib/init/init-d-script: exit 0 at end of 
script prevents all other exit codes"):
> I consider the usage of /usr/bin/env only a kludge

Are there practical problems with use of /usr/bin/env this way ?  This
is a very traditional technique for solving these kind of problems and
IME generally it works well.

I don't foresee any difficult-to-resolve problems with the env
technique, but maybe I don't have the right knowledge.

Ian.

-- 
Ian JacksonThese opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Bug#914263: cabextract: -F option doesn't work correctly.

[Eric Sharkey]

On Wed, Nov 21, 2018 at 9:29 PM Jactry Zeng  wrote:

> Hi Eric,
>
> 在 2018/11/22 上午3:59, Eric Sharkey 写道:
> > Perhaps your problem is in libmspack0 and not cabextract?  On my test
> > system, I have 0.9.1-1 installed.  Can you retest with an updated
> libmspack
> > package?
> Thanks for comment.
>
> OK, maybe. But libmspack0 0.9.1-1 still not ready for buster/testing so I
> didn't receive any update about it.
>

Strange.  libmspack0 is 5 days older than cabextract 1.9.


> Should I also file a bug for libmspack0 package?
>

No, I think this is a duplicate of bug 912687.

Eric

Bug#911542: ledgersmb 1.6.6+ds-2: Please update package po/sv.po debconf file

[Sebastian Rasmussen]

> I orig inally sent this request back in late July but to that one I
> received no response from you (although I did receive responses
> from 8 of the 15 I needed). Please send the updated file to me,
> or submit it as a wishlist bug against ledgersmb. The deadline for
> receiving the updated translation is Thu, 6 December 2018 19:51:03 -0400.

I took the liberty of updating the Swedish transltaion. I hope this helps! :)

 / Sebastian


sv.po
Description: Binary data

Bug#914341: hplip: Python dependancy problem

[Julian Andres Klode]

On Thu, Nov 22, 2018 at 09:32:12AM -0300, Ricardo F. Peliquero wrote:
> Package: hplip
> Version: 3.18.10+dfsg0-3
> Severity: normal
> 
> Dear Maintainer,
> 
> It is not possible to update Python from 3.6.7-1 to 3.7.1-2 without broking 
> hplip, which
> depends on python3 (< 3.7). Please consider updating this dependancy to the 
> new python
> version.

This is to be expected, this is unstable, and there is an ongoing
python3.7 transition. There is no need to file bugs like this - the
packages receive binNMUs, and the bugs just pointlessly add another
step of closing them (and they can't be closed with a proper version
as binNMUs are not tracked in the bug tracker).

If you don't want to see transitions like that, use testing.
-- 
debian developer - deb.li/jak | jak-linux.org - free software dev
ubuntu core developer  i speak de, en

Bug#914342: ruby-validate-email: Source doesn't contain testsuite.

[李健秋]

Package: ruby-validate-email
Version: 0.1.6-2
Severity: minor

Dear Maintainer,

The upstream github contains `spec` dir, however the source package
doesn't. As we wish to add tests for all the ruby packages. I've
re-fetched and imported the upstream tarball from github and added
`debian/ruby-tests.rake` to enable the tests. These changes has been
pushed into our git on salsa.d.o.

After I run the tests, it results one of the tests failed. I have
forwarded the issue upstream:
  https://github.com/perfectline/validates_email/issues/7

Just open a bug numbder here to track the issue.

Cheers,
-Andrew

Bug#914271: lintian: Rationale behind hyphen-in-upstream-part-of-debian-changelog-version

[Guillem Jover]

On Wed, 2018-11-21 at 16:44:29 +0100, Johannes Schauer wrote:
> Quoting Felix Lechner (2018-11-21 15:52:02)
> > Well, I also agree with Josch's well-articulated argument. A merge
> > request to remove the tag is pending (!72). Thank you for bringing
> > this to our attention!

I think the tag should stay TBH.

> in your original commit you were talking about "some tools".
> 
> This suggests that you know tools that behave wrongly.
> 
> If you share the tools you know of, then we could file bugs.

I think that would be difficult, I'm afraid the bulk of these
tools are human brains! :D

See for example #911341 which is something I recently stumbled upon.
The tools here work as intended, but the human made a very
comprehensible mistake.

I mean, yes, we could improve lintian, perhaps even some of
dpkg-gensymbols, and similar to warn or maybe not propose this kind
of situation, but in the end, any time you strip the revision in any
dependency field or similar, you can end up with broken comparisons
given the current algorithm.

Thanks,
Guillem

Bug#914341: hplip: Python dependancy problem

[Ricardo F. Peliquero]

Package: hplip
Version: 3.18.10+dfsg0-3
Severity: normal

Dear Maintainer,

It is not possible to update Python from 3.6.7-1 to 3.7.1-2 without broking 
hplip, which
depends on python3 (< 3.7). Please consider updating this dependancy to the new 
python
version.

Kind regards,

Ricardo Peliquero

-- Package-specific info:

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

Kernel: Linux 4.18.0-2-686-pae (SMP w/2 CPU cores)
Locale: LANG=es_AR.UTF-8, LC_CTYPE=es_AR.UTF-8 (charmap=UTF-8), 
LANGUAGE=es_AR:es (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages hplip depends on:
ii  adduser3.118
ii  cups   2.2.9-2
ii  hplip-data 3.18.10+dfsg0-3
ii  libc6  2.27-8
ii  libcups2   2.2.9-2
ii  libdbus-1-31.12.10-1
ii  libhpmud0  3.18.10+dfsg0-3
ii  libsane1.0.27-3.1
ii  libsane-hpaio  3.18.10+dfsg0-3
ii  libsnmp30  5.7.3+dfsg-4+b1
ii  libusb-1.0-0   2:1.0.22-2
ii  lsb-base   9.20170808
ii  printer-driver-hpcups  3.18.10+dfsg0-3
ii  python33.6.7-1
ii  python3-dbus   1.2.8-2+b1
ii  python3-gi 3.30.2-1
ii  python3-pexpect4.6.0-1
ii  python3-pil5.3.0-1
ii  python3-reportlab  3.5.9-1
ii  wget   1.19.5-2
ii  xz-utils   5.2.2-1.3

Versions of packages hplip recommends:
pn  avahi-daemon  
pn  policykit-1   
ii  printer-driver-postscript-hp  3.18.10+dfsg0-3
pn  sane-utils

Versions of packages hplip suggests:
pn  hplip-doc  
pn  hplip-gui  
pn  python3-notify2
pn  system-config-printer  

-- no debconf information

Bug#914269: google-i18n-address FTBFS: UnicodeDecodeError: 'ascii' codec can't decode byte 0xc4 in position 11

[Daniel Kahn Gillmor]

On Wed 2018-11-21 17:12:23 +0200, Adrian Bunk wrote:
> Fails:
> LC_ALL=C dpkg-buildpackage
>
> Builds:
> LC_ALL=C.UTF-8 dpkg-buildpackage
>
> Python 3.7 has a workaround for C locale.
>
> In debian/rules add:
> export LC_ALL=C.UTF-8

thank you, Adrian!

I've lost count of how many beers i owe you, but $beers++ on me whenever
we meet up :) (or alternate $beverages++ of your choice if you don't
drink beer).

regards,

  --dkg


signature.asc
Description: PGP signature

Bug#914271: lintian: Rationale behind hyphen-in-upstream-part-of-debian-changelog-version

[Johannes Schauer]

Hi,

Quoting Guillem Jover (2018-11-22 13:12:05)
> > in your original commit you were talking about "some tools".
> > 
> > This suggests that you know tools that behave wrongly.
> > 
> > If you share the tools you know of, then we could file bugs.
> 
> I think that would be difficult, I'm afraid the bulk of these
> tools are human brains! :D
> 
> See for example #911341 which is something I recently stumbled upon.
> The tools here work as intended, but the human made a very
> comprehensible mistake.
> 
> I mean, yes, we could improve lintian, perhaps even some of
> dpkg-gensymbols, and similar to warn or maybe not propose this kind
> of situation, but in the end, any time you strip the revision in any
> dependency field or similar, you can end up with broken comparisons
> given the current algorithm.

I then suggest two things:

Instead of checking whether the upstream version contains dashes, check whether
the .symbols file contains a version format that avoids bugs like #911341.

Improve the tag description to be more explicit about which problem is being
solved, for example by making the tag specific for the symbols file error.

Additionally: I don't know how the machinery works that compares versions in
symbols files, but maybe it could be improved to make sure that this kind of
problem doesn't happen anymore?

Thanks!

cheers, josch


signature.asc
Description: signature

Bug#914300: Bug #914300: kalgebra: Segfault when clearing empty calculator

[Bernhard Übelacker]

Dear Maintainer,
I tried to have a look at this issue.


This is the stack with debug symbols:

(gdb) bt
#0  QByteArray::QByteArray (a=..., this=0x7fffd4e8) at 
/usr/include/x86_64-linux-gnu/qt5/QtCore/qbytearray.h:492
#1  QList::takeLast (this=0x7fffd4e0) at 
/usr/include/x86_64-linux-gnu/qt5/QtCore/qlist.h:565
#2  ConsoleHtml::updateView (this=0x55ab9ac0) at ./src/consolehtml.cpp:182
#3  0x55572dd6 in ConsoleHtml::clear (this=) at 
./src/consolehtml.cpp:227
#4  0x55577da5 in ConsoleHtml::qt_static_metacall (_o=, 
_id=, _a=0x7fffd6a0, _c=) at 
./obj-x86_64-linux-gnu/src/kalgebra_autogen/EWIEGA46WW/moc_consolehtml.cpp:134
#5  0x769df28b in QMetaObject::activate(QObject*, int, int, void**) () 
at kernel/qobject.cpp:3771
#6  0x769df8a7 in QMetaObject::activate 
(sender=sender@entry=0x55be7820, m=m@entry=0x777f5840 
, local_signal_index=local_signal_index@entry=1, 
argv=argv@entry=0x7fffd6a0) at kernel/qobject.cpp:3633
#7  0x77325ee2 in QAction::triggered (this=this@entry=0x55be7820, 
_t1=) at .moc/moc_qaction.cpp:376
#8  0x773284f0 in QAction::activate (this=0x55be7820, 
event=) at kernel/qaction.cpp:1166
#9  0x77498e1c in QMenuPrivate::activateCausedStack 
(this=this@entry=0x55be3bb0, causedStack={...}, 
action=action@entry=0x55be7820, action_e=action_e@entry=QAction::Trigger, 
self=self@entry=true) at widgets/qmenu.cpp:1371
#10 0x774a03f0 in QMenuPrivate::activateAction 
(this=this@entry=0x55be3bb0, action=action@entry=0x55be7820, 
action_e=action_e@entry=QAction::Trigger, self=self@entry=true) at 
widgets/qmenu.cpp:1448
#11 0x774a141b in QMenu::mouseReleaseEvent (this=, 
e=0x7fffdcb0) at widgets/qmenu.cpp:2942
#12 0x7736a7c8 in QWidget::event (this=this@entry=0x55bbd0a0, 
event=event@entry=0x7fffdcb0) at kernel/qwidget.cpp:8925
#13 0x774a3aab in QMenu::event (this=0x55bbd0a0, e=0x7fffdcb0) 
at widgets/qmenu.cpp:3064
#14 0x7732c491 in QApplicationPrivate::notify_helper 
(this=this@entry=0x55784680, receiver=receiver@entry=0x55bbd0a0, 
e=e@entry=0x7fffdcb0) at kernel/qapplication.cpp:3727
#15 0x77333d18 in QApplication::notify(QObject*, QEvent*) () at 
kernel/qapplication.cpp:3203
#16 0x769b6039 in QCoreApplication::notifyInternal2(QObject*, QEvent*) 
() at 
../../include/QtCore/5.11.2/QtCore/private/../../../../../src/corelib/thread/qthread_p.h:307
#17 0x77333019 in QCoreApplication::sendEvent (event=, 
receiver=) at 
../../include/QtCore/../../src/corelib/kernel/qcoreapplication.h:234
#18 QApplicationPrivate::sendMouseEvent 
(receiver=receiver@entry=0x55bbd0a0, event=event@entry=0x7fffdcb0, 
alienWidget=0x0, alienWidget@entry=0x55bbd0a0, nativeWidget=0x55bbd0a0, 
buttonDown=buttonDown@entry=0x77824870 , 
lastMouseReceiver=..., spontaneous=true) at kernel/qapplication.cpp:2695
#19 0x773856c3 in QWidgetWindow::handleMouseEvent(QMouseEvent*) () at 
kernel/qwidgetwindow.cpp:556
#20 0x77387e8e in QWidgetWindow::event (this=0x7fffd8007910, 
event=0x7fffe0b0) at kernel/qwidgetwindow.cpp:281
#21 0x7732c491 in QApplicationPrivate::notify_helper 
(this=this@entry=0x55784680, receiver=receiver@entry=0x7fffd8007910, 
e=e@entry=0x7fffe0b0) at kernel/qapplication.cpp:3727
#22 0x77333ad0 in QApplication::notify(QObject*, QEvent*) () at 
kernel/qapplication.cpp:3486
#23 0x769b6039 in QCoreApplication::notifyInternal2(QObject*, QEvent*) 
() at 
../../include/QtCore/5.11.2/QtCore/private/../../../../../src/corelib/thread/qthread_p.h:307
#24 0x76d5fb2b in QCoreApplication::sendSpontaneousEvent 
(event=0x7fffe0b0, receiver=0x7fffd8007910) at 
../../include/QtCore/../../src/corelib/kernel/qcoreapplication.h:237
#25 QGuiApplicationPrivate::processMouseEvent (e=0x56940e70) at 
kernel/qguiapplication.cpp:2081
#26 0x76d61a25 in QGuiApplicationPrivate::processWindowSystemEvent 
(e=e@entry=0x56940e70) at kernel/qguiapplication.cpp:1816
#27 0x76d3bd8b in QWindowSystemInterface::sendWindowSystemEvents 
(flags=...) at kernel/qwindowsysteminterface.cpp:1032
#28 0x7fffddc4985b in QPAEventDispatcherGlib::processEvents 
(this=0x55800360, flags=...) at qeventdispatcher_glib.cpp:70
#29 0x769b4d0b in 
QEventLoop::exec(QFlags) () at 
../../include/QtCore/../../src/corelib/global/qflags.h:140
#30 0x769bce82 in QCoreApplication::exec() () at 
../../include/QtCore/../../src/corelib/global/qflags.h:120
#31 0x555661a9 in main (argc=, argv=) at 
./src/main.cpp:43


In ConsoleHtml::clear is unconditionally the last element retrieved,
even when the log is empty.

182 const auto newEntry = log.takeLast();


It looks like upstream have fixed this in commit [1].
This is contained in branch Applications/18.08.

Have not found a matching upstream bug.

Kind regards,
Bernhard

[1] 

Bug#913740: fetch-url does not use --no-check-certificate on HTTP to HTTPS redirects

[Mauricio Oliveira]

On Wed, Nov 21, 2018 at 7:02 PM Philipp Kern  wrote:
>
> Am 21.11.2018 um 15:47 schrieb Mauricio Oliveira:
> >> [...] I will note that it's also possible to copy additional
> >> root certificates into the initrd pre-install. (At least it used to work
> >> before HTTPS was generally available.)
> > It looks like this requires rebuilding the initrd, which is some extra work
> > (and unfortunately it does not allow using the already
> > distributed/official files out there), [...]
>
> Linux support specifying multiple files to be loaded as an initrd[1]. In

Interesting, I wasn't aware of that -- thanks for mentioning it.

> [snip]
>
> Yes, it requires extra work. So does preseeding.

Indeed. If you excuse an apparently pedantic comparison for a moment:
I'd think preseeding requires a bit less extra work than an initrd,
and also less than a proper HTTPS/SSL setup, thus it looks like
this is probably (one of) the reason(s) this workaround option exists. :- )

> Now maybe the argument is that there could be mirrors outside of your
> control that redirect you to HTTPS and the root of trust is the GPG key
> material embedded into the initrd. [...]

Indeed. Another example is the material in the initrd to become outdated
(e.g., expiration dates) but continues to be used (e.g., deployments that
must run an stabler/older release only, with that initrd) and the new web
servers with archives/mirrors do not work anymore.

> [... That's a fair point but I will note
> that you did not actually list a use case, you just reported what didn't
> work.

Sorry, I may have missed something, but I was under the impression
these two use cases in the bug report could be considered use cases.

Nonetheless, respectfully, I think it's not a problem to fix something
that doesn't work if it's available for users, and they may use it for
their own reasons and in their own ways on their own consideration
(you know, adopting good/secure practices or not).

"""
[...] there are cases when an user does not know for sure
whether the server uses/supports that, or the server might change its
behavior and start HTTP to HTTPS redirect after URLs have spread over
(e.g., scripts and infrastructure)
"""

> I guess I don't really object to your patch and am mostly questioning
> the existence of the option in this day and age, [...]

Yes, I completely understand it -- no worries at all.

> [...] which then means people
> are encouraged to enable that rather than setup their infrastructure
> correctly. But there might still be value in having that option
> available with some signage on how to do it right.

Right. One scenario I can think of is testing/proof-of-concept cases,
where not necessarily everything must be strictly correct and secure
at that stage, but will be considered/implemented properly later on,
if it's decided to move on with the implementation.

Unfortunately, if during that early stage, where not too many systems/
resources are available (e.g., uses a web server with HTTP(S) redirect
and an invalid certificate, because that's what's avaiable at that point)
things don't work well (e.g., this problem), it might even prevent the
concept from moving on, and never reach the actual/proper/secure
implementation, for example.

Thanks and best regards,

Bug#914339: python-rsa ftbfs, missing a b-d on mock

[Matthias Klose]

Package: src:python-rsa
Version: 4.0-1
Severity: serious
Tags: sid buster

python-rsa ftbfs, missing a b-d on mock:

==
ERROR: tests.test_load_save_keys (unittest.loader.ModuleImportFailure)
--
ImportError: Failed to import test module: tests.test_load_save_keys
Traceback (most recent call last):
  File "/usr/lib/python2.7/unittest/loader.py", line 254, in _find_tests
module = self._get_module_from_name(name)
  File "/usr/lib/python2.7/unittest/loader.py", line 232, in 
_get_module_from_name
__import__(name)
  File "tests/test_load_save_keys.py", line 20, in 
import mock
ImportError: No module named mock


--
Ran 76 tests in 4.204s

Bug#914340: webserver sometimes needs to be restarted

[Daniel Pocock]

Package: davical
Version: 1.1.5-1
Severity: important

>From time to time, the clients fail to sync with DAViCal.

Many of the clients don't indicate there is an error.  For example, the
Lightning plugin for Thunderbird logs errors like this to the console
where ordinary users would never see them:


Warning: CalDAV: No response status doing webdav sync for calendar foo
Warning: CalDAV: Error doing webdav sync: undefined
Warning: There has been an error reading data for calendar: foo.
However, this error is believed to be minor, so the program will attempt
to continue. Error code: DAV_REPORT_ERROR. Description: There has been
an error reading data for calendar:
https://foo.example.org/davical/caldav.php/foo/home/. It has been
disabled until it is safe to use it.
Warning: There has been an error reading data for calendar: foo.
However, this error is believed to be minor, so the program will attempt
to continue. Error code: READ_FAILED. Description:




but it doesn't show any error in the GUI until somebody tries to do
something like dismissing a reminder.  Other clients, like DAVdroid,
just fail to sync without showing any feedback.

Simply logging into the web server and doing

  systemctl restart apache2

resolves the issue and all the clients work again for another week or so.

Has anybody else observed this?

Where should I look for additional logging or clues next time this
happens?  Should I enable any extra logging options in DAViCal, Apache
or PostgreSQL?

Bug#891507: usbmuxd: Plugging device second time does not start usbmuxd

[Leo Soares]

Package: usbmuxd
Version: 1.1.0-2
Followup-For: Bug #891507
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu disco ubuntu-patch

Hi,

this patch fixes this problem by backporting the udev rule from 
1.1.1~git20181007.f838cf6-1

  * debian/patches/fix-on-reconnect.patch: backport udev rule from 1.1.1 (LP:
  #1778767) 


Thanks for considering the patch.


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

Kernel: Linux 4.15.0-39-generic (SMP w/32 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
diff -Nru usbmuxd-1.1.0/debian/patches/fix-on-reconnect.patch 
usbmuxd-1.1.0/debian/patches/fix-on-reconnect.patch
--- usbmuxd-1.1.0/debian/patches/fix-on-reconnect.patch 1970-01-01 
01:00:00.0 +0100
+++ usbmuxd-1.1.0/debian/patches/fix-on-reconnect.patch 2018-11-21 
17:40:27.0 +
@@ -0,0 +1,23 @@
+## Description: restart usbmuxd when reconnecting devices
+## Origin/Author: Leo Soares
+## Bug: https://bugs.launchpad.net/ubuntu/+source/usbmuxd/+bug/1778767
+Index: usbmuxd-1.1.0/udev/39-usbmuxd.rules.in
+===
+--- usbmuxd-1.1.0.orig/udev/39-usbmuxd.rules.in
 usbmuxd-1.1.0/udev/39-usbmuxd.rules.in
+@@ -1,7 +1,13 @@
+ # usbmuxd (Apple Mobile Device Muxer listening on /var/run/usbmuxd)
+ 
++# systemd should receive all events relating to device
++SUBSYSTEM=="usb", ENV{DEVTYPE}=="usb_device", 
ENV{PRODUCT}=="5ac/12[9a][0-9a-f]/*", TAG+="systemd"
++
+ # Initialize iOS devices into "deactivated" USB configuration state and 
activate usbmuxd
+-ACTION=="add", SUBSYSTEM=="usb", ATTR{idVendor}=="05ac", 
ATTR{idProduct}=="12[9a][0-9a-f]", ENV{USBMUX_SUPPORTED}="1", 
ATTR{bConfigurationValue}="0", OWNER="usbmux", @udev_activation_rule@
++SUBSYSTEM=="usb", ENV{DEVTYPE}=="usb_device", 
ENV{PRODUCT}=="5ac/12[9a][0-9a-f]/*", ACTION=="add", ENV{USBMUX_SUPPORTED}="1", 
ATTR{bConfigurationValue}="0", OWNER="usbmux", @udev_activation_rule@
++
++# Make sure properties don't get lost when bind action is called
++SUBSYSTEM=="usb", ENV{DEVTYPE}=="usb_device", 
ENV{PRODUCT}=="5ac/12[9a][0-9a-f]/*", ACTION=="bind", 
ENV{USBMUX_SUPPORTED}="1", OWNER="usbmux", @udev_activation_rule@
+ 
+ # Exit usbmuxd when the last device is removed
+-ACTION=="remove", SUBSYSTEM=="usb", ENV{PRODUCT}=="5ac/12[9a][0-9a-f]/*", 
ENV{INTERFACE}=="255/*", RUN+="@sbindir@/usbmuxd -x"
++SUBSYSTEM=="usb", ENV{DEVTYPE}=="usb_device", 
ENV{PRODUCT}=="5ac/12[9a][0-9a-f]/*", ACTION=="remove", RUN+="@sbindir@/usbmuxd 
-x"
diff -Nru usbmuxd-1.1.0/debian/patches/series 
usbmuxd-1.1.0/debian/patches/series
--- usbmuxd-1.1.0/debian/patches/series 2016-01-04 10:03:36.0 +
+++ usbmuxd-1.1.0/debian/patches/series 2018-11-21 17:33:33.0 +
@@ -1 +1,2 @@
 Fix-FTBFS-in-kfreebsd.patch
+fix-on-reconnect.patch

Bug#801234:

[蔡昆宏]

Control: tag 801234 - fixed

--

Carl Tsai

Bug#914317: dgit: less than helpful error if debian/patches/ exists as untracked files

[Ian Jackson]

Sean Whitton writes ("Bug#914317: dgit: less than helpful error if 
debian/patches/ exists as untracked files"):
...
> 4) Now you have uncommitted debian/patches, but ignore that, and instead
>commit your upstream changes
> 
> 5) dgit sbuild (or whatever), and you get:

(Without looking at the source, or the docs:)

Why does this not complain about the uncommitted files in
debian/patches ?  Clearly you're not using --clean=git.  Are you using
--clean=dpkg-source,no-check or something ?  Or is debian/patches in
your .gitignore ?

Ian.

Bug#914338: opensurgsim ftbfs with ld --as-needed

[Matthias Klose]

Package: src:opensurgsim
Version:0.7.0-7

opensurgsim ftbfs with ld --as-needed. ../../../GoogleMock/gtest/libgtest.so
should appear behind ../../Testing/libSurgSimTesting.so on the command line.

/usr/bin/c++  -g -O2 -fdebug-prefix-map=/<>=.
-fstack-protector-strong -Wdate-time -D_FORTIFY_SOURCE=2 -Wall  -std=gnu++11
-Wl,-Bsymbolic-functions -Wl,-z,relro -Wl,-z,now -rdynamic
CMakeFiles/SurgSimPhysicsTest.dir/BuildMlcpTests.cpp.o
CMakeFiles/SurgSimPhysicsTest.dir/CcdCollisionLoopTest.cpp.o
CMakeFiles/SurgSimPhysicsTest.dir/ComputationGroupTest.cpp.o
CMakeFiles/SurgSimPhysicsTest.dir/ComputationTests.cpp.o
CMakeFiles/SurgSimPhysicsTest.dir/ConstraintComponentTests.cpp.o
CMakeFiles/SurgSimPhysicsTest.dir/ConstraintImplementationFactoryTests.cpp.o
CMakeFiles/SurgSimPhysicsTest.dir/ConstraintImplementationTests.cpp.o
CMakeFiles/SurgSimPhysicsTest.dir/ConstraintTests.cpp.o
CMakeFiles/SurgSimPhysicsTest.dir/ContactConstraintDataTests.cpp.o
CMakeFiles/SurgSimPhysicsTest.dir/ContactConstraintGenerationTests.cpp.o
CMakeFiles/SurgSimPhysicsTest.dir/ContactFilteringTest.cpp.o
CMakeFiles/SurgSimPhysicsTest.dir/DcdCollisionTests.cpp.o
CMakeFiles/SurgSimPhysicsTest.dir/DeformableCollisionRepresentationTest.cpp.o
CMakeFiles/SurgSimPhysicsTest.dir/DeformableRepresentationTest.cpp.o
CMakeFiles/SurgSimPhysicsTest.dir/EigenGtestAsserts.cpp.o
CMakeFiles/SurgSimPhysicsTest.dir/Fem1DConstraintFixedPointTests.cpp.o
CMakeFiles/SurgSimPhysicsTest.dir/Fem1DConstraintFixedRotationVectorTests.cpp.o
CMakeFiles/SurgSimPhysicsTest.dir/Fem1DConstraintFrictionalSlidingTests.cpp.o
CMakeFiles/SurgSimPhysicsTest.dir/Fem1DConstraintFrictionlessContactTests.cpp.o
CMakeFiles/SurgSimPhysicsTest.dir/Fem1DConstraintFrictionlessSlidingTests.cpp.o
CMakeFiles/SurgSimPhysicsTest.dir/Fem1DElementBeamTests.cpp.o
CMakeFiles/SurgSimPhysicsTest.dir/Fem1DLocalizationTest.cpp.o
CMakeFiles/SurgSimPhysicsTest.dir/Fem1DMechanicalValidationTests.cpp.o
CMakeFiles/SurgSimPhysicsTest.dir/Fem1DPlyReaderDelegateTests.cpp.o
CMakeFiles/SurgSimPhysicsTest.dir/Fem1DRepresentationTests.cpp.o
CMakeFiles/SurgSimPhysicsTest.dir/Fem2DConstraintFixedPointTests.cpp.o
CMakeFiles/SurgSimPhysicsTest.dir/Fem2DConstraintFrictionalSlidingTests.cpp.o
CMakeFiles/SurgSimPhysicsTest.dir/Fem2DConstraintFrictionlessContactTests.cpp.o
CMakeFiles/SurgSimPhysicsTest.dir/Fem2DConstraintFrictionlessSlidingTests.cpp.o
CMakeFiles/SurgSimPhysicsTest.dir/Fem2DElementTriangleTests.cpp.o
CMakeFiles/SurgSimPhysicsTest.dir/Fem2DLocalizationTest.cpp.o
CMakeFiles/SurgSimPhysicsTest.dir/Fem2DMechanicalValidationTests.cpp.o
CMakeFiles/SurgSimPhysicsTest.dir/Fem2DPlyReaderDelegateTests.cpp.o
CMakeFiles/SurgSimPhysicsTest.dir/Fem2DRepresentationTests.cpp.o
CMakeFiles/SurgSimPhysicsTest.dir/Fem3DConstraintFixedPointTests.cpp.o
CMakeFiles/SurgSimPhysicsTest.dir/Fem3DConstraintFrictionalSlidingTests.cpp.o
CMakeFiles/SurgSimPhysicsTest.dir/Fem3DConstraintFrictionlessContactTests.cpp.o
CMakeFiles/SurgSimPhysicsTest.dir/Fem3DConstraintFrictionlessSlidingTests.cpp.o
CMakeFiles/SurgSimPhysicsTest.dir/Fem3DElementCorotationalTetrahedronTests.cpp.o
CMakeFiles/SurgSimPhysicsTest.dir/Fem3DElementCubeTests.cpp.o
CMakeFiles/SurgSimPhysicsTest.dir/Fem3DElementTetrahedronTests.cpp.o
CMakeFiles/SurgSimPhysicsTest.dir/Fem3DLocalizationTest.cpp.o
CMakeFiles/SurgSimPhysicsTest.dir/Fem3DPlyReaderDelegateTests.cpp.o
CMakeFiles/SurgSimPhysicsTest.dir/Fem3DRepresentationTests.cpp.o
CMakeFiles/SurgSimPhysicsTest.dir/FemElementTests.cpp.o
CMakeFiles/SurgSimPhysicsTest.dir/FemLocalizationTest.cpp.o
CMakeFiles/SurgSimPhysicsTest.dir/FemRepresentationTests.cpp.o
CMakeFiles/SurgSimPhysicsTest.dir/FixedConstraintFixedPointTests.cpp.o
CMakeFiles/SurgSimPhysicsTest.dir/FixedConstraintFixedRotationVectorTests.cpp.o
CMakeFiles/SurgSimPhysicsTest.dir/FixedConstraintFrictionlessContactTests.cpp.o
CMakeFiles/SurgSimPhysicsTest.dir/FixedRepresentationTest.cpp.o
CMakeFiles/SurgSimPhysicsTest.dir/FreeMotionTests.cpp.o
CMakeFiles/SurgSimPhysicsTest.dir/LinearSpringTest.cpp.o
CMakeFiles/SurgSimPhysicsTest.dir/MassSpringConstraintFixedPointTest.cpp.o
CMakeFiles/SurgSimPhysicsTest.dir/MassSpringConstraintFrictionlessContactTest.cpp.o
CMakeFiles/SurgSimPhysicsTest.dir/MassSpringLocalizationTest.cpp.o
CMakeFiles/SurgSimPhysicsTest.dir/MassSpringMechanicalValidationTests.cpp.o
CMakeFiles/SurgSimPhysicsTest.dir/MassSpringRepresentationTests.cpp.o
CMakeFiles/SurgSimPhysicsTest.dir/MassTest.cpp.o
CMakeFiles/SurgSimPhysicsTest.dir/MockObjects.cpp.o
CMakeFiles/SurgSimPhysicsTest.dir/ParticleCollisionResponseTests.cpp.o
CMakeFiles/SurgSimPhysicsTest.dir/PhysicsManagerStateTests.cpp.o
CMakeFiles/SurgSimPhysicsTest.dir/PhysicsManagerTests.cpp.o
CMakeFiles/SurgSimPhysicsTest.dir/PostUpdateTests.cpp.o
CMakeFiles/SurgSimPhysicsTest.dir/PrepareCollisionPairsTests.cpp.o
CMakeFiles/SurgSimPhysicsTest.dir/PreUpdateTests.cpp.o
CMakeFiles/SurgSimPhysicsTest.dir/PushResultsTests.cpp.o
CMakeFiles/SurgSimPhysicsTest.dir/RepresentationTest.cpp.o

Bug#914172: [debian-mysql] Bug#914172: Bug#914172: Bug#914172: mariadb-server-10.1: mariadb-server sec-update (10.1.37-0+deb9u1) uninstalls default-mysql-server, mysql-server, mariadb-server-10.1 & ma

[Olaf van der Spek]

On Thu, Nov 22, 2018 at 10:54 AM David Escala  wrote:
> Perhaps we should change the apt dist-upgrade command for security
> updates (suggestions?), but

https://wiki.debian.org/UnattendedUpgrades

> not adding new dependencies in a security update may also be a good policy.

I think that is / was policy already..


-- 
Olaf

Bug#801234:

[蔡昆宏]

Control: tag 801234 - Fixed

--

Carl Tsai

Bug#801234: cont...@bugs.debian.org

[蔡昆宏]

Control: tag 863304 - Fixed

--

Carl Tsai

Bug#914337: Hardcoded library name in libsparsehash-dev

[Александр Сапин]

Package: libsparsehash-dev
version: 2.0.2-1

When I'm trying to build my code with any modern compiler (clang++-6.0 and
higher) that uses this library I get error:

> /usr/include/sparsehash/dense_hash_map:106:10: fatal error:
> 'tr1/functional' file not found
> #include HASH_FUN_H // for hash<>
>  ^
> /usr/include/sparsehash/internal/sparseconfig.h:10:20: note: expanded from
> macro 'HASH_FUN_H'
> #define HASH_FUN_H 
>^~~~
> 1 error generated.
>
This caused by hardcoded config file

/usr/include/sparsehash/internal/sparseconfig.h

in https://packages.debian.org/en/sid/all/libsparsehash-dev/filelist.
 is not part of tr for a long time in c++. I think this
hardcoded config should be regenerated with newer compiler.

Bug#914099: mailman3-full: mailman3-web-qcluster causes high database load

[Stefan Tatschner]

On Mon, 2018-11-19 at 13:09 +0100, Stefan Tatschner wrote:
> I installed the mailman3-full package from the buster repository. The
> qcluster component generates a high database load with these queries:

The reason for this is that the django qcluster component polls the
database regularly:

https://github.com/Koed00/django-q/issues/139
https://django-q.readthedocs.io/en/latest/configure.html#poll

IMO it would make sense to make the qcluster component optional, since
there are cronjobs anyway. But that's an upstream issue...

In the meanwhile debian could configure a lower default poll rate. I
have set 5 seconds instead of the default 0.2 in order to reduce
database traffic.

Oh and the issue is related to hyperkitty, which is part of the
mailman3-full metapackage. Maybe someone could tag this issue
accordingly.

Thanks,
Stefan

Bug#914336: netperfmeter: bogus debian/tests/control file

[Paul Gevers]

Source: netperfmeter
Version: 1.8.0-1
X-Debbugs-CC: debian...@lists.debian.org
User: debian...@lists.debian.org
Usertags: issue

Dear maintainer,

Recently you added (or at least you tried to add) an autopkgtest to you
package. However, the current content of debian/tests/control is bogus.

Please read the spec [1] and adapt the control file or drop the file if
you didn't intent to add a test.

Paul

[1]
https://salsa.debian.org/ci-team/autopkgtest/raw/master/doc/README.package-tests.rst



signature.asc
Description: OpenPGP digital signature

Bug#914129: Docker issue with iptables 1.8.2

[Arturo Borrero Gonzalez]

Control: severity -1 normal
Control: unmerge -1
Control: retitle -1 possible issue with docker

Let's retitle this to something more meaningfull.

Downgrading severity until we see further details on this issue.
Also, unmerge this bug report from the unrelated #914129.

Bug#914074: Bug fixed

[Arturo Borrero Gonzalez]

Control: unmerge -1
Control: fixed -1 1.8.2-2

This bug is different from #914129, unmerging now.

Also, this bug is fixed by iptables 1.8.2-2, so closing it now as well.

Bug#788425: [epiphany-browser] Empty white page is displayed instead of really rendered one

[Igor Bogomazov]

downgrading everything *-mesa helped:

[DOWNGRADE] libegl-mesa0:amd64 18.2.5-2 -> 18.1.9-1
[DOWNGRADE] libegl1-mesa:amd64 18.2.5-2 -> 18.1.9-1
[DOWNGRADE] libegl1-mesa-dev:amd64 18.2.5-2 -> 18.1.9-1
[DOWNGRADE] libgbm-dev:amd64 18.2.5-2 -> 18.1.9-1
[DOWNGRADE] libgbm1:amd64 18.2.5-2 -> 18.1.9-1
[DOWNGRADE] libgl1-mesa-dev:amd64 18.2.5-2 -> 18.1.9-1
[DOWNGRADE] libgl1-mesa-dri:amd64 18.2.5-2 -> 18.1.9-1
[DOWNGRADE] libgl1-mesa-glx:amd64 18.2.5-2 -> 18.1.9-1
[DOWNGRADE] libglapi-mesa:amd64 18.2.5-2 -> 18.1.9-1
[DOWNGRADE] libgles2-mesa:amd64 18.2.5-2 -> 18.1.9-1
[DOWNGRADE] libgles2-mesa-dev:amd64 18.2.5-2 -> 18.1.9-1
[DOWNGRADE] libglx-mesa0:amd64 18.2.5-2 -> 18.1.9-1
[DOWNGRADE] libwayland-egl1-mesa:amd64 18.2.5-2 -> 18.1.9-1
[DOWNGRADE] mesa-common-dev:amd64 18.2.5-2 -> 18.1.9-1
[DOWNGRADE] mesa-utils:amd64 8.4.0-1 -> 8.3.0-3
[DOWNGRADE] mesa-va-drivers:amd64 18.2.5-2 -> 18.1.9-1
[DOWNGRADE] mesa-vdpau-drivers:amd64 18.2.5-2 -> 18.1.9-1

Bug#914329: mirror submission for debian.mirror.liquidtelecom.com

[Anthony Somerset]

Thanks

we have just updated FTPsync and also the upstream hostname from the 
ftp.uk to free.hands.com

also as per separate mail - we are running mirror of cdimage as well

at http://debian.mirror.liquidtelecom.com/debian-cd/ and 
rsync://debian.mirror.liquidtelecom.com/debian-cd/


Anthony Somerset
Group Head: Systems Engineering

[cid:image001.jpg@01D071D4.14B24FE0]



Liquid Telecommunications Limited, Innovate Park, 401 Old Pretoria Main Road, 
Midrand, South Africa.
T: +27 10 120 0437 M: +27 76 3371551   E: 
anthony.somer...@liquidtelecom.com
M (UK): +44 7595 568755

On 22 Nov 2018, at 10:30, Peter Palfrader 
mailto:wea...@debian.org>> wrote:

Hi Anthony!

This sounds like a very nice mirror, thanks for setting it up.

Two requests, please:
- Update your ftpsync version to something more recent
http://debian.mirror.liquidtelecom.com/debian/project/ftpsync/
should have the current version
- We recommend people not sync from ftp.*.debian.org, as 
those
service names might point to different mirrors if needed,
and the only service that is guaranteed to work on them is
http:// for /debian.

If you get pushed by free.hands.com, that's probably the 
mirror
you should configure as upstream.

Cheers!

On Thu, 22 Nov 2018, Anthony Somerset wrote:

> Site: debian.mirror.liquidtelecom.com
> Type: leaf
> Archive-architecture: ALL amd64 arm64 armel armhf hurd-i386 i386 
> kfreebsd-amd64 kfreebsd-i386 mips mips64el mipsel powerpc ppc64el s390x
> Archive-http: /debian/
> Archive-rsync: debian/
> Maintainer: Anthony Somerset 
> mailto:mir...@liquidtelecom.com>>
> Country: KE Kenya
> Location: EADC, Nairobi, Kenya
> Sponsor: Liquid Telecom 
> https://www.liquidtelecom.com
> Comment: 10GE Uplinks + IPv6
> can support most of Africa via AS30844
>
> Push Triggered from UK mirror with Manual fall back
>
> also carrying debian-cdimage and legacy debian-backports
>
> we would also like to become the official KE mirror and potentially support 
> being official mirror for any african nations not yet having one - 
> particularly southern and eastern africa countries listed: 
> ZA,ZW,ZM,BW,TZ,UG,RW,KE
>
>
>
>
> Trace Url: 
> http://debian.mirror.liquidtelecom.com/debian/project/trace/
> Trace Url: 
> http://debian.mirror.liquidtelecom.com/debian/project/trace/ftp-master.debian.org
> Trace Url: 
> http://debian.mirror.liquidtelecom.com/debian/project/trace/debian.mirror.liquidtelecom.com
>

--
| .''`. ** Debian **
Peter Palfrader | : :' : The universal
https://www.palfrader.org/ | `. `' Operating System
| `- https://www.debian.org/

Bug#913364: real bug, too low severity

[Marc Haber]

On Thu, Nov 22, 2018 at 02:15:59AM +0100, Arnt Karlsen wrote:
> > > It has the potential to bring down the system, thus one could even
> > > argue upon a RC severity, but they accumulate so slowly (apparently
> > > two per day) and take so little resources that I wonder what could
> > > have slowed down Arnt's machine so badly.  I've waited past only a
> > > single midnight though, so it's possible badness accumulates
> > > superlinearly.  
> 
> ..nah, all it takes is setting up systemctl restart loop cronjobs to
> juuust carry on looping.

systemctl restart is never executed on a sysvinit system.

> > The original bug reporter has yet failed to say what's going wrong
> > here. I am tired of running after poorly worded bug reports.
> 
> ..which part of:" # daily restart of atop at midnight
> 0 0 * * * root if [ -d "/run/systemd/system" ]; then systemctl \
> restart atop; else /usr/share/atop/atop.daily \& ; fi" "on a
> non-systemd box" did you miss?

a non-systemd box doesn't have /run/systemd/system, thus the then part
of the if statement is not executed, systemctl is never executed (and
would only fail since it doesn't exist on a non-systemdbox), and thus
/usr/share/atop/atop.daily is executed.

The only "bad" effect I see is that a cron process and a shell stay
around.

> > Adam, what exactly has the potential to bring down the system?
> 
> ..the cron job _loops_, because it cannot for very good reasons
> find /run/systemd/system nor systemctl, and therefore _loops_.

Explain how a loop can occur.

I don't see a loop on a freshly installed Debian unstable sysv system. I
also don't see how a loop can occur. But I might be wrong here.

> ..this bug is insisting on assuming systemctl etc systemd commands 

checking for /run/systemd/system is the canonical and documented way of
checking whether we have systemd or not.

If you don't want to have unused systemctl commands in Devuan packages,
then don't take Debian packages. You're free to do the work yourself
then.

Greetings
Marc

Bug#914335: apt-show-versions thinks gets tripped up by some package versions e.g. docker-ce

[Willem Basson]

Package: apt-show-versions
Version: 0.22.7
Severity: important

Dear Maintainer,

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

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

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

Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
From: Willem Basson 
To: Debian Bug Tracking System 
Subject: apt-show-versions is wrong about the status of some third-party 
packages e.g. docker-ce
Message-ID: 
<154287660879.4947.3652908988455149171.report...@pmm-staging1.jnb1.host-h.net>
X-Mailer: reportbug 7.1.7
Date: Thu, 22 Nov 2018 10:50:08 +0200

Package: apt-show-versions
Version: 0.22.7
Severity: normal

Dear Maintainer,

I installed docker-ce using their documentation:
https://docs.docker.com/install/linux/docker-ce/debian/#install-docker-ce-1

Afterwards, apt-show-versions thinkgs that the installed version is
newer than the latest available version:

apt-show-versions docker-ce -a
docker-ce:amd64 5:18.09.0~3-0~debian-stretch install ok installed
docker-ce:amd64 18.06.1~ce~3-0~debian stretch download.docker.com
No stable version
No stable-updates version
docker-ce:amd64 5:18.09.0~3-0~debian-stretch newer than version in archive

Other tools believe that the right version is intalled:
apt-cache policy docker-ce
docker-ce:
  Installed: 5:18.09.0~3-0~debian-stretch
  Candidate: 5:18.09.0~3-0~debian-stretch
  Version table:
 *** 5:18.09.0~3-0~debian-stretch 990
990 https://download.docker.com/linux/debian stretch/stable amd64 
Packages
100 /var/lib/dpkg/status
 18.06.1~ce~3-0~debian 990
990 https://download.docker.com/linux/debian stretch/stable amd64 
Packages
 18.06.0~ce~3-0~debian 990
990 https://download.docker.com/linux/debian stretch/stable amd64 
Packages
 18.03.1~ce-0~debian 990
990 https://download.docker.com/linux/debian stretch/stable amd64 
Packages
 18.03.0~ce-0~debian 990
990 https://download.docker.com/linux/debian stretch/stable amd64 
Packages
 17.12.1~ce-0~debian 990
990 https://download.docker.com/linux/debian stretch/stable amd64 
Packages
 17.12.0~ce-0~debian 990
990 https://download.docker.com/linux/debian stretch/stable amd64 
Packages
 17.09.1~ce-0~debian 990
990 https://download.docker.com/linux/debian stretch/stable amd64 
Packages
 17.09.0~ce-0~debian 990
990 https://download.docker.com/linux/debian stretch/stable amd64 
Packages
 17.06.2~ce-0~debian 990
990 https://download.docker.com/linux/debian stretch/stable amd64 
Packages
 17.06.1~ce-0~debian 990
990 https://download.docker.com/linux/debian stretch/stable amd64 
Packages
 17.06.0~ce-0~debian 990
990 https://download.docker.com/linux/debian stretch/stable amd64 
Packages
 17.03.3~ce-0~debian-stretch 990
990 https://download.docker.com/linux/debian stretch/stable amd64 
Packages
 17.03.2~ce-0~debian-stretch 990
990 https://download.docker.com/linux/debian stretch/stable amd64 
Packages
 17.03.1~ce-0~debian-stretch 990
990 https://download.docker.com/linux/debian stretch/stable amd64 
Packages
 17.03.0~ce-0~debian-stretch 990
990 https://download.docker.com/linux/debian stretch/stable amd64 
Packages

apt-cache madison docker-ce
 docker-ce | 5:18.09.0~3-0~debian-stretch | 
https://download.docker.com/linux/debian stretch/stable amd64 Packages
 docker-ce | 18.06.1~ce~3-0~debian | https://download.docker.com/linux/debian 
stretch/stable amd64 Packages
 docker-ce | 18.06.0~ce~3-0~debian | https://download.docker.com/linux/debian 
stretch/stable amd64 Packages
 docker-ce | 18.03.1~ce-0~debian | https://download.docker.com/linux/debian 
stretch/stable amd64 Packages
 docker-ce | 18.03.0~ce-0~debian | https://download.docker.com/linux/debian 
stretch/stable amd64 Packages
 docker-ce | 17.12.1~ce-0~debian | https://download.docker.com/linux/debian 
stretch/stable amd64 Packages
 docker-ce | 17.12.0~ce-0~debian | https://download.docker.com/linux/debian 
stretch/stable amd64 Packages
 docker-ce | 17.09.1~ce-0~debian | https://download.docker.com/linux/debian 
stretch/stable amd64 Packages
 docker-ce | 17.09.0~ce-0~debian | https://download.docker.com/linux/debian 
stretch/stable amd64 Packages
 docker-ce | 17.06.2~ce-0~debian | https://download.docker.com/linux/debian 
stretch/stable amd64 Packages
 docker-ce | 17.06.1~ce-0~debian | https://download.docker.com/linux/debian 
stretch/stable amd64 Packages
 docker-ce | 17.06.0~ce-0~debian | https://download.docker.com/linux/debian 
stretch/stable amd64 Packages
 docker-ce | 17.03.3~ce-0~debian-stretch | 
https://download.docker.com/linux/debian stretch/stable amd64 Packages
 docker-ce | 17.03.2~ce-0~debian-stretch |