Bug#917323: transition: gdal

[Bas Couwenberg]

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

For the Debian GIS team I'd like to transition to GDAL 2.4.0.

Like the previous transition to GDAL 2.3.0 (#898566), there is no SONAME
bump, only the virtual ABI package changed to account for the C++ symbol
changes.

All reverse dependencies rebuilt successfully with GDAL 2.4.0 from
experimental as summarized below, except mysql-workbench due to an
unrelated issue (#914761).

libgdal-grass doesn't need a binNMU as the 2.4.0 version will be
uploaded to unstable instead. liblas likewise doesn't need a binNMU,
the version is experimental will be moved to unstable instead.


Ben file:

title = "gdal";
is_affected = .depends ~ "gdal-abi-2-3-0" | .depends ~ "gdal-abi-2-4-0";
is_good = .depends ~ "gdal-abi-2-4-0";
is_bad = .depends ~ "gdal-abi-2-3-0";


Kind Regards,

Bas

Bug#917321: distcc: [INTL:de] updated German debconf translation

[Helge Kreutzmann]

Package: distcc
Version: 3.3.2-3
Severity: wishlist
Tags: patch l10n

Please find the updated German debconf translation for distcc
attached.

Please place this file in debian/po/ as de.po for your next upload.

If you update your template, please use 
'msgfmt --statistics '
to check the po-files for fuzzy or untranslated strings.

If there are such strings, please contact me so I can update the 
German translation.

Greetings
Helge
# translation of distcc po-debconf template to German
# Copyright (C) 2006, Matthias Julius 
# Copyright (C) 2006, Bastian Venthur 
# Copyright (C) 2008, Helge Kreutzmann 
# Copyright (C) 2009, Thomas Mueller 
# This file is distributed under the same license as the distcc package.
#
# Thomas Mueller , 2010.
msgid ""
msgstr ""
"Project-Id-Version: distcc_3.2-2-3_de\n"
"Report-Msgid-Bugs-To: dis...@packages.debian.org\n"
"POT-Creation-Date: 2018-12-22 18:41+0100\n"
"PO-Revision-Date: 2018-12-26 08:24+0100\n"
"Last-Translator: Thomas Mueller \n"
"Language-Team: German \n"
"Language: de\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
"X-Generator: Lokalize 1.0\n"
"Plural-Forms:  nplurals=2; plural=(n != 1);\n"

#. Type: boolean
#. Description
#: ../distcc.templates:1001
msgid "Start the distcc daemon on startup?"
msgstr "Den Distcc-Daemon beim Rechnerstart starten?"

#. Type: boolean
#. Description
#: ../distcc.templates:1001
msgid ""
"distcc can be run as a daemon, listening on port 3632 for incoming "
"connections."
msgstr ""
"Distcc kann als Daemon betrieben werden, der an Port 3632 auf eingehende "
"Verbindungen wartet."

#. Type: boolean
#. Description
#: ../distcc.templates:1001
msgid ""
"You have the option of starting the distcc daemon automatically on the "
"computer startup. If in doubt, it's advised not to start it automatically on "
"startup. If you later change your mind, you can run: 'dpkg-reconfigure "
"distcc'."
msgstr ""
"Sie haben die Möglichkeit, den Distcc-Daemon beim Rechnerstart automatisch "
"starten zu lassen. Im Zweifelsfall wird empfohlen, dies nicht zu tun. Falls "
"Sie später Ihre Meinung ändern, können Sie »dpkg-reconfigure distcc« "
"aufrufen."

#. Type: string
#. Description
#: ../distcc.templates:2001
msgid "Allowed client networks:"
msgstr "Zugelassene Client-Netze:"

#. Type: string
#. Description
#: ../distcc.templates:2001
msgid ""
"The distcc daemon implements access control based on the IP address of the "
"client, that is trying to connect. Only the hosts or networks listed here "
"are allowed to connect."
msgstr ""
"Der Distcc-Daemon implementiert die Zugangskontrolle basierend auf der IP-"
"Adresse des Clients, der versucht, sich mit ihm zu verbinden. Nur "
"Verbindungen von Hosts oder Netzen, die hier aufgelistet sind, werden "
"zugelassen."

#. Type: string
#. Description
#: ../distcc.templates:2001
msgid ""
"You can list multiple hosts and/or networks, separated by spaces. Hosts are "
"represented by their IP address, networks have to be in CIDR notation, e.g. "
"\"192.168.1.0/24\"."
msgstr ""
"Sie können mehrere Hosts und/oder Netze durch Leerzeichen getrennt eingeben. "
"Hosts werden durch deren IP-Adresse repräsentiert. Netze müssen in CIDR-"
"Schreibweise eingegeben werden, z. B. »192.168.1.0/24«."

#. Type: string
#. Description
#: ../distcc.templates:2001
msgid ""
"To change the list at a later point, you can run: 'dpkg-reconfigure distcc'."
msgstr ""
"Um die Liste zu einem späteren Zeitpunkt zu ändern, rufen Sie »dpkg-"
"reconfigure distcc« auf."

#. Type: string
#. Description
#: ../distcc.templates:3001
msgid "Listen interfaces:"
msgstr "Netzschnittstellen:"

#. Type: string
#. Description
#: ../distcc.templates:3001
msgid "The distcc daemon can be bound to a specific network interface."
msgstr ""
"Der Distcc-Daemon kann an eine spezifische Netzschnittstelle gebunden werden."

#. Type: string
#. Description
#: ../distcc.templates:3001
msgid ""
"You probably want to choose the interface of your local network by entering "
"its IP address. If distccd should listen on all interfaces, just enter "
"nothing."
msgstr ""
"Möglicherweise möchten Sie die Netzschnittstelle zu Ihrem lokalen Netz "
"verwenden, indem Sie deren IP-Adresse eingeben. Falls distccd an alle "
"Schnittstellen gebunden werden soll, geben Sie hier nichts ein."

#. Type: string
#. Description
#: ../distcc.templates:3001
msgid ""
"Be sure to protect distccd from unauthorized access, by being careful in "
"your choice of the listen interface and allowed networks. distccd should  "
"never be accessible from untrusted networks. If that is needed, secureshell "
"should be used instead of the daemon."
msgstr ""
"Stellen Sie sicher, dass distccd vor unberechtigtem Zugang geschützt ist, "
"indem Sie Netzschnittstelle und die erlaubten Netze sorgfältig auswählen. "
"Distccd sollte niemals von nicht vertrauenswürdigen Netzen aus zugänglich "
"sein. Falls dies notwendig ist, sollte Secure-Shell anstatt des 

Bug#917322: radare2: CVE-2018-20457 CVE-2018-20459

[Salvatore Bonaccorso]

Source: radare2
Version: 3.1.2+dfsg-1.1
Severity: important
Tags: patch security upstream

Hi,

The following vulnerabilities were published for radare2.

CVE-2018-20457[0]:
| In radare2 through 3.1.3, the assemble function inside
| libr/asm/p/asm_arm_cs.c allows attackers to cause a denial-of-service
| (application crash via an r_num_calc out-of-bounds read) by crafting an
| arm assembly input because a loop uses an incorrect index in armass.c
| and certain length validation is missing in armass64.c, a related issue
| to CVE-2018-20459.

CVE-2018-20459[1]:
| In radare2 through 3.1.3, the armass_assemble function in
| libr/asm/arch/arm/armass.c allows attackers to cause a
| denial-of-service (application crash by out-of-bounds read) by crafting
| an arm assembly input because a loop uses an incorrect index in
| armass.c and certain length validation is missing in armass64.c, a
| related issue to CVE-2018-20457.

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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2018-20457
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-20457
[1] https://security-tracker.debian.org/tracker/CVE-2018-20459
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-20459
[1] https://github.com/radare/radare2/issues/12417
[2] https://github.com/radare/radare2/issues/12418

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#917320: ITP: ruby-kitchen-docker -- Docker Driver for Test Kitchen

[Mathieu Parent]

Package: wnpp
Severity: wishlist
Owner: Mathieu Parent 

* Package name: ruby-kitchen-docker
  Version : 2.7.0
  Upstream Author : Sean Porter, ...
* URL : https://github.com/test-kitchen/kitchen-docker
* License : Apache-2.0
  Programming Lang: Ruby
  Description : Docker Driver for Test Kitchen

 A Docker Driver for Test Kitchen.
 .
 Test Kitchen is a test harness tool to execute your configured code on one or
 more platforms in isolation. A driver plugin architecture is used which lets
 you run your code on various cloud providers and virtualization technologies
 such as Amazon EC2, Blue Box, CloudStack, Digital Ocean, Rackspace, OpenStack,
 Vagrant, Docker, LXC containers, and more. Many testing frameworks are already
 supported out of the box including Bats, shUnit2, RSpec, Serverspec, with
 others being created weekly.

Bug#917293: kinit: The kdeinit5 consumes and takes about 3 ~ 5 minutes to give me control of the environment.

[Santiago José López Borrazás]

El 26/12/18 a las 1:07, Lisandro Damián Nicanor Pérez Meyer escribió:
> Hi Santiago!
>
> El mar., 25 dic. 2018 19:57, Santiago José López Borrazás  > escribió:
>
> El 25/12/18 a las 23:31, Lisandro Damián Nicanor Pérez Meyer escribió:
> >
> > I mean your internet loopback device. Please send the output of
> >
> > ip addr
>
> sjlopezb@local:~$ ip addr
>
> (...)
> 2: eth0:  mtu 1500 qdisc pfifo_fast state
> UP group default qlen 1000
>     link/ether 00:1d:09:dd:a9:3e brd ff:ff:ff:ff:ff:ff
>     inet 192.168.1.45/24  brd 192.168.1.255
> scope global eth0
>    valid_lft forever preferred_lft forever
>     inet6 fe80::21d:9ff:fedd:a93e/64 scope link
>    valid_lft forever preferred_lft forever
> sjlopezb@local:~$
>
> It is not a problem of routes. It's not a network problem either, because
> I'm using wicd.
>
> Network works perfect.
>
>
> I'm not asking for eth0 but the loopback (lo) interface. KDE needs it up
> and running to work.
>
> These days it's normal to have it in place, but it's safer to check :-)

In local I have no problem (or loopback as you say). No way:

1: lo:  mtu 65536 qdisc noqueue state UNKNOWN group
default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
   valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
   valid_lft forever preferred_lft forever

I told you, everything is correct. It never fails me, nor in this position.
Everything is alright.

So. Why do you think I have something wrong? No way.

Thanks.

-- 
Saludos de Santiago José López borrazás.

Bug#917315: libtgvoip: FTBFS on several arches (i386, mips, ppc64el, s390x) after recent upload

[Коля Гурьев]

There are at least three different issues. The first thing you mentioned
relates to SSE2 extension on i386 and already has a fix[1] in Git. The
second one because of the lack of release architectures in files
webrtc_dsp/rtc_base/system/arch.h and webrtc_dsp/typedefs.h. Actually,
those lists need to be extended. The third issue is caused by system
headers on GNU/Hurd and kFreeBSD.

 [1]: 
https://salsa.debian.org/debian/libtgvoip/commit/5bb9a8bdf260b528f589bd83400ade1476c94702

Bug#914813: Same behaviour with newer kernel

[Bernhard]

Hello,

I tested it again with the latest daily installer image.
This is kernel 4.19.12.

The same behaviour.

Best regards
Bernhard



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

Bug#917319: libdovecot: Segfault -- service(dict) killed with signal 11

[Christian Schrötter]

Package: dovecot
Version: 1:2.3.4-2
Severity: important

Dear Maintainer,

the latest updates of Dovecot or some shared libraries at my Debian
Stretch system introduced a small bug. It's a nice new segfault... ;-)

> dovecot: dict: Fatal: master: service(dict):
> child 13578 killed with signal 11 (core dumped)
>
> dovecot: lda: Error: dict quota: Quota update failed:
> write(/var/run/dovecot/dict) failed: Broken pipe
> […] - Quota is now desynced

Core dump:

> Core was generated by `dovecot/dict'.
> Program terminated with signal SIGSEGV, Segmentation fault.
>
> #0  0x7f8d5b5efd82 in event_unref ()
> from /usr/lib/dovecot/libdovecot.so.0

Do you need more details about my (Postfixadmin with Sqlite3) setup
or is that enough information (for upstream) to fix this crash?

# doveconf -n service/dict
> service dict {
>   unix_listener dict {
> group = vmailuser
> mode = 0600
> user = vmailuser
>   }
> }

# doveconf -n dict
> dict {
>   quota = sqlite:/etc/dovecot/dovecot-dict-sql.conf.ext
> }

# cat /etc/dovecot/dovecot-dict-sql.conf.ext
> connect = /path/to/sqlite3.db
>
> map {
> pattern = priv/quota/storage
> table = quota2
> username_field = username
> value_field = bytes
> }
>
> map {
> pattern = priv/quota/messages
> table = quota2
> username_field = username
> value_field = messages
> }

-- 
With kind regards,
Christian Schrötter

Bug#917318: ruby-ronn: Please switch upstream to an active fork

[Boyuan Yang]

Source: ruby-ronn
Severity: important
Version: 0.7.3-5.1
X-Debbugs-CC: d...@martin-ueding.de

Dear ronn maintainers and those whom it might concern,

Someone forked ronn and is actively maintaining it as well as fixing
longstanding bugs. It considers itself as a drop-in replacement of
original ronn.

You may find its upstream here: https://github.com/apjanke/ronn-ng

Please consider switching the tracked upstream into the new fork, or at
least find fixes for existing issues there.

--
Regards,
Boyuan Yang


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

Bug#917317: rust-cbindgen: Please package version 0.6.7

[Mike Hommey]

Source: rust-cbindgen
Version: 0.6.6-1
Severity: wishlist

Firefox 65 requires 0.6.7.



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

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

Bug#917316: yatex: New upstream 1.81 has been released

[TSUCHIYA Masatoshi]

Package: yatex
Version: 1.77+dfsg1-4
Severity: normal

Dear Maintainer,

New upstream 1.81 has been released.  
The upstream author believes that its copyright condition is more
suitable for Debian than the older version.

Regards,

-- 
TSUCHIYA Masatoshi

Bug#917261: linux-image-4.19.0-1-amd64: /dev/mapper symlink for dm-crypt volume containing / not created on system startup

[Celejar]

On Tue, 25 Dec 2018 20:52:46 +
Ben Hutchings  wrote:

> Control: reassign -1 udev 240-1
> Control: forcemerge 917124 -1
> 
> This seems to be a bug in udev, not the kernel.  You will only have
> noticed it once you rebooted for the kernel upgrade.

Nope - in my system's current state, when rebooting into 4.19 there's
no /dev/mapper symlink, but when rebooting into 4.18 there is. I've
gone back and forth several times, and the behavior is consistent.
There's clearly something that 4.19 is doing differently from 4.18. [I
guess it might still be a udev bug, which is being exposed by some
change in 4.19.]

Celejar

Bug#917315: libtgvoip: FTBFS on several arches (i386, mips, ppc64el, s390x) after recent upload

[Simon Quigley]

Package: libtgvoip
Version: 2.4-1
Severity: serious

Dear Maintainer,

Your package fails to build from source on i386, mips, ppc64el, and
s390x after the upload of 2.4-1 to Sid. It all seems to be the same
error, in different spots:

error: inlining failed in call to always_inline '__m128
_mm_loadu_ps(const float*)': target specific option mismatch

Please fix this.

Thanks,
-- 
Simon Quigley
tsimo...@debian.org
tsimonq2 on freenode and OFTC
5C7A BEA2 0F86 3045 9CC8
C8B5 E27F 2CF8 458C 2FA4



signature.asc
Description: OpenPGP digital signature

Bug#917314: nxml-mode: C-c C-i says "Not in a start-tag" after an attribute

[Vincent Lefevre]

Package: emacs-common
Version: 1:26.1+1-2
Severity: normal
Tags: upstream

With "emacs -Q", open a file containing



in nXML mode.

Put the cursor after the second double-quote, and type C-c C-i.
One gets an error "Not in a start-tag".

This is a regression in GNU Emacs 26.1.

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

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

Versions of packages emacs-common depends on:
ii  emacsen-common  3.0.4
ii  install-info6.5.0.dfsg.1-4+b1

Versions of packages emacs-common recommends:
ii  emacs-el  1:26.1+1-2

Versions of packages emacs-common suggests:
pn  emacs-common-non-dfsg  
ii  ncurses-term   6.1+20181013-1

-- no debconf information

Bug#917313: dash: /bin/sh.distrib no longer exists, making autopkgtests fail

[Simon Quigley]

Package: dash
Version: 0.5.10.2-4
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu disco autopkgtest

Dear Maintainer,

Ubuntu runs autopkgtests on all six of its release architectures (amd64,
i386, armhf, arm64, ppc64el, and s390x), but your package fails its
autopkgtest on armhf. Unlike Debian, Ubuntu blocks a package from
migrating into the release pocket if a package fails its autopkgtest.

I reproduced this in a clean environment on armhf and amd64 porterbox
schroots, and both have the same result as the Ubuntu armhf builder.
Attached are all three of the logs. This seems to center around the
absence of /bin/sh.distrib, which makes the tests checking if it is:
 a) An executable
 b) An Essential shell, for debootstrap
fail.

Could those tests be invalid after the most recent upload?

Thanks,
-- 
Simon Quigley
tsimo...@debian.org
tsimonq2 on freenode and OFTC
5C7A BEA2 0F86 3045 9CC8
C8B5 E27F 2CF8 458C 2FA4


debian-amd64.log.gz
Description: application/gzip


debian-armhf.log.gz
Description: application/gzip


ubuntu-armhf.log.gz
Description: application/gzip


signature.asc
Description: OpenPGP digital signature

Bug#769188: nxml-mode: C-c C-i sometimes says "Not in a start-tag"

[Vincent Lefevre]

Control: reassign -1 emacs25-common 25.2+1-5
Control: tags -1 upstream fixed-upstream

since the issue with the original testcase has been fixed in 26.1.

On 2018-12-26 02:18:44 +0100, Vincent Lefevre wrote:
> On 2018-12-26 02:11:21 +0100, Vincent Lefevre wrote:
> > This bug is still present.
> 
> And here's a minimal example to reproduce the bug, using
> a vacuous schema:
> 
> 
> 
> Put the cursor after the second double-quote, and type C-c C-i.
> One gets an error "Not in a start-tag".

Sorry, this one is actually a different upstream bug, which is
a regression in 26.1. I'll report it in another bug.

So, I'm reassigning bug 769188 back to emacs25-common. And this
bug will be closed once emacs25-common is removed from Debian.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#917312: kinit: The kdeinit5 takes about some minutes to startup and crashed

[Martin Gummi]

Package: kinit
Version: 5.51.0-1
Severity: important

Dear Maintainer,

When I want to enter the KDE, it takes me a lot to finish the session ... 
mostly like https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=917293

Test of localhost:
~$ ip addr
1: lo:  mtu 65536 qdisc noqueue state UNKNOWN group 
default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
   valid_lft forever preferred_lft forever
inet6 ::1/128 scope host 
   valid_lft forever preferred_lft forever

~$ ping localhost
PING localhost(localhost (::1)) 56 data bytes
64 bytes from localhost (::1): icmp_seq=1 ttl=64 time=0.073 ms
64 bytes from localhost (::1): icmp_seq=2 ttl=64 time=0.118 ms
64 bytes from localhost (::1): icmp_seq=3 ttl=64 time=0.116 ms
^C
--- localhost ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 37ms
rtt min/avg/max/mdev = 0.073/0.102/0.118/0.022 ms
~$ ping 127.0.0.1
PING 127.0.0.1 (127.0.0.1) 56(84) bytes of data.
64 bytes from 127.0.0.1: icmp_seq=1 ttl=64 time=0.056 ms
64 bytes from 127.0.0.1: icmp_seq=2 ttl=64 time=0.079 ms
64 bytes from 127.0.0.1: icmp_seq=3 ttl=64 time=0.081 ms
^C
--- 127.0.0.1 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 36ms
rtt min/avg/max/mdev = 0.056/0.072/0.081/0.011 ms

get a crash report

Application: kdeinit5 (kdeinit5), signal: Segmentation fault
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[Current thread is 1 (Thread 0x7febbed4e780 (LWP 18054))]

Thread 3 (Thread 0x7febb89c5700 (LWP 18155)):
#0  0x7febc2b55bd9 in poll () from /lib/x86_64-linux-gnu/libc.so.6
#1  0x7febc1020e46 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#2  0x7febc1020f6c in g_main_context_iteration () from 
/lib/x86_64-linux-gnu/libglib-2.0.so.0
#3  0x7febc2ee4d2b in 
QEventDispatcherGlib::processEvents(QFlags) () 
from /lib/x86_64-linux-gnu/libQt5Core.so.5
#4  0x7febc2e91d0b in 
QEventLoop::exec(QFlags) () from 
/lib/x86_64-linux-gnu/libQt5Core.so.5
#5  0x7febc2ce10c6 in QThread::exec() () from 
/lib/x86_64-linux-gnu/libQt5Core.so.5
#6  0x7febbe30e545 in ?? () from /lib/x86_64-linux-gnu/libQt5DBus.so.5
#7  0x7febc2ceac97 in ?? () from /lib/x86_64-linux-gnu/libQt5Core.so.5
#8  0x7febc1bbbfa3 in start_thread () from 
/lib/x86_64-linux-gnu/libpthread.so.0
#9  0x7febc2b6088f in clone () from /lib/x86_64-linux-gnu/libc.so.6

Thread 2 (Thread 0x7febba4ca700 (LWP 18067)):
#0  0x7febc2b55bd9 in poll () from /lib/x86_64-linux-gnu/libc.so.6
#1  0x7febc3707cf7 in ?? () from /lib/x86_64-linux-gnu/libxcb.so.1
#2  0x7febc370991a in xcb_wait_for_event () from 
/lib/x86_64-linux-gnu/libxcb.so.1
#3  0x7febbae0b519 in ?? () from /lib/x86_64-linux-gnu/libQt5XcbQpa.so.5
#4  0x7febc2ceac97 in ?? () from /lib/x86_64-linux-gnu/libQt5Core.so.5
#5  0x7febc1bbbfa3 in start_thread () from 
/lib/x86_64-linux-gnu/libpthread.so.0
#6  0x7febc2b6088f in clone () from /lib/x86_64-linux-gnu/libc.so.6

Thread 1 (Thread 0x7febbed4e780 (LWP 18054)):
[KCrash Handler]
#6  0x7febb80de4f4 in ffmpegthumbnailer::MovieDecoder::seek 
(this=this@entry=0x7ffce9892810, timeInSeconds=) at 
./ffmpegthumbnailer/moviedecoder.cpp:202
#7  0x7febb80e020a in 
ffmpegthumbnailer::VideoThumbnailer::generateThumbnail 
(this=this@entry=0x5563d27746c8, videoFile=..., imageWriter=..., image=...) at 
./ffmpegthumbnailer/videothumbnailer.cpp:105
#8  0x7febb80e0359 in 
ffmpegthumbnailer::VideoThumbnailer::generateThumbnail 
(this=this@entry=0x5563d27746c8, videoFile=..., image=...) at 
./ffmpegthumbnailer/videothumbnailer.cpp:141
#9  0x7febb80dd793 in FFMpegThumbnailer::create (this=0x5563d27746b0, 
path=..., width=, img=...) at ./ffmpegthumbnailer.cpp:46
#10 0x7febc38fd9fe in ThumbnailProtocol::get (this=0x7ffce9892b80, url=...) 
at /usr/include/x86_64-linux-gnu/qt5/QtCore/qflags.h:120
#11 0x7febbe95cdf6 in KIO::SlaveBase::dispatch (this=0x7ffce9892b80, 
command=67, data=...) at ./src/core/slavebase.cpp:1119
#12 0x7febbe958196 in KIO::SlaveBase::dispatchLoop 
(this=this@entry=0x7ffce9892b80) at ./src/core/slavebase.cpp:318
#13 0x7febc38fb08d in kdemain (argc=, argv=) 
at ./thumbnail/thumbnail.cpp:130
#14 0x5563d22c4e1c in launch (argc=4, _name=0x5563d261d668 
"/usr/lib/x86_64-linux-gnu/qt5/plugins/kf5/kio/thumbnail.so", args=, cwd=, envc=0, envs=, reset_env=false, 
tty=0x0, avoid_loops=false, startup_id_str=0x5563d22c8187 "0") at 
./src/kdeinit/kinit.cpp:706
#15 0x5563d22c5eea in handle_launcher_request (sock=8, who=) 
at ./src/kdeinit/kinit.cpp:1146
#16 0x5563d22c68fb in handle_requests (waitForPid=0) at 
./src/kdeinit/kinit.cpp:1339
#17 0x5563d22c1645 in main (argc=5, argv=) at 
./src/kdeinit/kinit.cpp:1785
[Inferior 1 (process 18054) detached]




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

   * What led up to the situation?
   * What exactly did you do (or not do) that was 

Bug#769188: nxml-mode: C-c C-i sometimes says "Not in a start-tag"

[Vincent Lefevre]

On 2018-12-26 02:11:21 +0100, Vincent Lefevre wrote:
> This bug is still present.

And here's a minimal example to reproduce the bug, using
a vacuous schema:



Put the cursor after the second double-quote, and type C-c C-i.
One gets an error "Not in a start-tag".

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#769188: nxml-mode: C-c C-i sometimes says "Not in a start-tag"

[Vincent Lefevre]

Control: reassign -1 emacs-common 1:26.1+1-2

This bug is still present.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#917311: llvm: Multiple unversioned tools missing from the llvm package

[Mike Hommey]

Package: llvm
Version: 1:7.0-46
Severity: normal

$ comm -23 <(dpkg -L llvm-7 | grep /usr/bin/ | sed s/-7$//) <(dpkg -L llvm | 
grep /usr/bin/)
/usr/bin/dsymutil
/usr/bin/llvm-PerfectShuffle
/usr/bin/llvm-c-test
/usr/bin/llvm-cat
/usr/bin/llvm-cfi-verify
/usr/bin/llvm-cvtres
/usr/bin/llvm-cxxdump
/usr/bin/llvm-cxxfilt
/usr/bin/llvm-dlltool
/usr/bin/llvm-dwp
/usr/bin/llvm-exegesis
/usr/bin/llvm-lib
/usr/bin/llvm-lto
/usr/bin/llvm-lto2
/usr/bin/llvm-mca
/usr/bin/llvm-modextract
/usr/bin/llvm-mt
/usr/bin/llvm-objcopy
/usr/bin/llvm-opt-report
/usr/bin/llvm-pdbutil
/usr/bin/llvm-rc
/usr/bin/llvm-readelf
/usr/bin/llvm-readobj
/usr/bin/llvm-split
/usr/bin/llvm-stress
/usr/bin/llvm-strings
/usr/bin/llvm-strip
/usr/bin/llvm-undname
/usr/bin/llvm-xray
/usr/bin/sanstats


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

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

Versions of packages llvm depends on:
ii  llvm-71:7.0.1~+rc2-4
ii  llvm-runtime  1:7.0-46

llvm recommends no packages.

llvm suggests no packages.

-- no debconf information

Bug#838561: After such a long time the error continues to occur frequently

[Bruno Gonçalves Araujo]

After such a long time the error continues to occur frequently

Bug#880696: debian-refcard: PDFs have various problems (layout broken, missing spaces or line breaks ...) -- workaround

[Holger Wansing]

Hi all,

today I played around with refcard to get a solution (or a workaround) for this
problem (no progress for more than one year; sorry for this :-( )


The underlying problem seems to be somewhere in the tool chain, which is
somewhat complex here for the refcard, so this might somewhere between
dblatex, texlive-* and friends.
As it seems, strings within  ...  no longer get line
breaks, so several URLs are now too long to be correctly displayed on the
refcard.

Maybe someone can find the real cause of this, but I found a workaround
to fix this:
replacing all 'literal' tags by 'filename' !

The displayed output seems identical (means: apparently the same fonts are
used), and the URLs get their line breaks correctly as it was in version 9.0,
so there is no difference for the user, which looks as a sensible 
workaround/solution for this problem, at least for the moment.

Since the freeze for Buster is not so far away, I would be willing to consider
this as a way to go, at least for Buster.



Greetings
Holger



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

Bug#917226: systemd: systemd-machine-id-setup: error while loading shared libraries: libsystemd-shared-239.so: cannot open shared object file: No such file or directory

[Michael Biebl]

Control: reassign -1 usrmerge

Am 26.12.18 um 00:37 schrieb Chris Lamb:
> Hi Michael,
> 
> Yes, sorry, I should have been more complete here:
> 
>> Have you installed the "usrmerge" package on this particular system?
>> Do you remember the result of the installation process? Did it output
>> anything?
> 
> Yes, it failed halfway through IIRC. I did it on a whim and, alas, did
> not save the output. I *believe* it detected that something like
> molly-guard was installed so it bailed out, but it didn't clear up
> 100% after itself or something.
> 
>>>   $ ls -l /bin/systemd-machine-id-setup
>>>   -rwxr-xr-x 1 root root 22,696 2018-12-22 15:01 
>>> /bin/systemd-machine-id-setup
>>
>> Just for completeness sake, I assume, this binary works fine?
> 
> It does, yes.

Thanks for the confirmation.
With this information, I'm going to reassign this bug report to the
usrmerge package and leave it to Marco, to decide what to do about this.
Maybe there is a way how the error message can be improved in case of a
failure.

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#888549: chrome-gnome-shell: Please don't use /etc/opt, it's not FHS-compliant

[Jeremy Bicha]

Control: severity -1 serious
Control: notfound -1 9-2
Control: found -1 10.1-3

I couldn't get this to work using a postrm script (the script appeared
to run at the wrong time), so maybe we need a trigger after all.

Thanks,
Jeremy Bicha

Bug#917226: systemd: systemd-machine-id-setup: error while loading shared libraries: libsystemd-shared-239.so: cannot open shared object file: No such file or directory

[Marco d'Itri]

On Dec 26, Chris Lamb  wrote:

> Yes, it failed halfway through IIRC. I did it on a whim and, alas, did
> not save the output. I *believe* it detected that something like
> molly-guard was installed so it bailed out, but it didn't clear up
> 100% after itself or something.
Noticing an aborted conversion run is very easy: /bin would be full of 
symlinks. If usrmerge fails mid-conversion then it MUST be run again 
until the conversion is complete: if other packages are installed in 
that time then the system will be left in an inconsistent state.
All this is explained by the error message (which you actually reported 
in #914716 :-) ).

If you want to try a conversion on a temporary snapshot you may use 
https://salsa.debian.org/md/usrmerge/blob/initramfs/development/kvm .

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Bug#917310: wicd: wifi connection failure because wicd did not notice a change of configuration of an AP

[Vincent Lefevre]

Control: reassign -1 wicd-gtk 1.7.4+tb2-6
Control: retitle -1 wicd-gtk: bad wifi connection attempt and obscure failure 
because wicd did not notice a change of configuration of an AP

This is mainly an UI issue (though the daemon may also need changes),
at least this is what the user sees at the end.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#917293: kinit: The kdeinit5 consumes and takes about 3 ~ 5 minutes to give me control of the environment.

[Lisandro Damián Nicanor Pérez Meyer]

Hi Santiago!

El mar., 25 dic. 2018 19:57, Santiago José López Borrazás 
escribió:

> El 25/12/18 a las 23:31, Lisandro Damián Nicanor Pérez Meyer escribió:
> >
> > I mean your internet loopback device. Please send the output of
> >
> > ip addr
>
> sjlopezb@local:~$ ip addr
>
> (...)
> 2: eth0:  mtu 1500 qdisc pfifo_fast state
> UP group default qlen 1000
> link/ether 00:1d:09:dd:a9:3e brd ff:ff:ff:ff:ff:ff
> inet 192.168.1.45/24 brd 192.168.1.255 scope global eth0
>valid_lft forever preferred_lft forever
> inet6 fe80::21d:9ff:fedd:a93e/64 scope link
>valid_lft forever preferred_lft forever
> sjlopezb@local:~$
>
> It is not a problem of routes. It's not a network problem either, because
> I'm using wicd.
>
> Network works perfect.


I'm not asking for eth0 but the loopback (lo) interface. KDE needs it up
and running to work.

These days it's normal to have it in place, but it's safer to check :-)

Bug#917309: Please build against mozjs60

[Laurent Bigonville]

Source: policykit-1
Version: 0.115-3
Severity: normal

Hi,

mozjs52 is longer maintained upstream and deprecated.

policykit should be ported to use mozjs60 instead

Kind regards,

Laurent Bigonville

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

Kernel: Linux 4.19.0-1-amd64 (SMP w/8 CPU cores)
Locale: LANG=fr_BE.UTF-8, LC_CTYPE=fr_BE.UTF-8 (charmap=UTF-8), 
LANGUAGE=fr_BE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: SELinux: enabled - Mode: Permissive - Policy name: refpolicy

-- no debconf information

Bug#917310: wicd: wifi connection failure because wicd did not notice a change of configuration of an AP

[Vincent Lefevre]

Package: wicd
Version: 1.7.4+tb2-6
Severity: important

When I tried to connect to a wifi access point I already used, there
were no issues with my Android devices, but with wicd, it could not
work. After several days, I've eventually found the cause. In the
past, the AP was using encryption (WPA), but now it no longer does
(for some reason). But wicd was still trying to connect using WPA,
ending with the error message "bad password". This is non-sense.
Either wicd should switch to unsecured[*], or it should immediately
output a meaningful error message, like: "Encryption requested for
unsecured access point".

[*] There should be a way to disable this, in which case follow the
alternative.

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

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

Versions of packages wicd depends on:
ii  wicd-curses [wicd-client]  1.7.4+tb2-6
ii  wicd-daemon1.7.4+tb2-6
ii  wicd-gtk [wicd-client] 1.7.4+tb2-6

wicd recommends no packages.

wicd suggests no packages.

Versions of packages wicd-gtk depends on:
ii  python 2.7.15-3
ii  python-glade2  2.24.0-5.1+b1
ii  python-gtk22.24.0-5.1+b1
ii  wicd-daemon1.7.4+tb2-6

Versions of packages wicd-gtk recommends:
ii  menu   2.1.47+b1
ii  policykit-10.105-23
ii  python-notify  0.1.1-4

Versions of packages wicd-curses depends on:
ii  python2.7.15-3
ii  python-urwid  2.0.1-2+b1
ii  wicd-daemon   1.7.4+tb2-6

Versions of packages wicd-curses recommends:
ii  sudo  1.8.26-2

Versions of packages wicd-daemon depends on:
ii  adduser   3.118
ii  dbus  1.12.12-1
ii  debconf   1.5.69
ii  iputils-ping  3:20180629-2
ii  isc-dhcp-client   4.4.1-2
ii  lsb-base  10.2018112800
ii  psmisc23.2-1
ii  python2.7.15-3
ii  python-dbus   1.2.8-2+b3
ii  python-gobject-2  2.28.6-13+b1
ii  python-wicd   1.7.4+tb2-6+local1
ii  wireless-tools30~pre9-13
ii  wpasupplicant 2:2.6-21

Versions of packages wicd-daemon recommends:
ii  rfkill 2.33-0.2
ii  wicd-curses [wicd-client]  1.7.4+tb2-6
ii  wicd-gtk [wicd-client] 1.7.4+tb2-6

Versions of packages wicd-daemon suggests:
pn  pm-utils  

Versions of packages python-wicd depends on:
ii  net-tools  1.60+git20180626.aebd88e-1
ii  python 2.7.15-3

Versions of packages python-wicd suggests:
ii  ethtool   1:4.19-1
ii  iproute2  4.19.0-2

-- debconf information:
* wicd/users:

Bug#917226: systemd: systemd-machine-id-setup: error while loading shared libraries: libsystemd-shared-239.so: cannot open shared object file: No such file or directory

[Chris Lamb]

Hi Michael,

Yes, sorry, I should have been more complete here:

> Have you installed the "usrmerge" package on this particular system?
> Do you remember the result of the installation process? Did it output
> anything?

Yes, it failed halfway through IIRC. I did it on a whim and, alas, did
not save the output. I *believe* it detected that something like
molly-guard was installed so it bailed out, but it didn't clear up
100% after itself or something.

> >   $ ls -l /bin/systemd-machine-id-setup
> >   -rwxr-xr-x 1 root root 22,696 2018-12-22 15:01 
> > /bin/systemd-machine-id-setup
> 
> Just for completeness sake, I assume, this binary works fine?

It does, yes.


Regards,

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

Bug#917308: RM: libproxy1-plugin-mozjs [s390x] -- ANAIS; mozjs60 is not building on s390x anymore

[Laurent Bigonville]

Package: ftp.debian.org
Severity: normal

Hi,

In the last libproxy upload, libproxy1-plugin-mozjs is not built on this
architecture anymore as mozjs60 FTBFS on this architecture.

Please remove libproxy1-plugin-mozjs

Thanks

Laurent Bigonville

Bug#917193: wpasupplicant: missing newline character in error message

[Vincent Lefevre]

On 2018-12-25 20:57:44 +0100, Vincent Lefevre wrote:
> I still get the error message in bad format, but the error message
> now appears only in the system logs (journalctl).

Note that this bug is about the bad format of this error message.

> For the connection failure itself, I don't know yet. This may be a bug
> in wpasupplicant as I have no issue with Android.

I've eventually found out: the issue came from wicd, which is too
dumb to notice that authentication was not needed (the configuration
of the AP has changed; Android noticed that without needed manual
intervention, but not wicd).

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#917226: systemd: systemd-machine-id-setup: error while loading shared libraries: libsystemd-shared-239.so: cannot open shared object file: No such file or directory

[Michael Biebl]

Am 26.12.18 um 00:20 schrieb Chris Lamb:

> Hm, this might actually be a botched usr-merged system:

Have you installed the "usrmerge" package on this particular system?
Do you remember the result of the installation process? Did it output
anything? usrmerge iirc should

>   $ ls -l /usr/bin/systemd-machine-id-setup
>   -rwxr-xr-x 1 root root 22,592 2018-11-20 18:44 
> /usr/bin/systemd-machine-id-setup
> 
>   $ ls -l /bin/systemd-machine-id-setup
>   -rwxr-xr-x 1 root root 22,696 2018-12-22 15:01 /bin/systemd-machine-id-setup

Just for completeness sake, I assume, this binary works fine?


-- 
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#916054: procmeter3 FTBFS with glibc 2.28

[Aurelien Jarno]

control: tags -1 + pending

Dear Maintainer,

In order to allow the libsensors4 -> libsensors5 to finish, I have just
uploaded a source NMU fixing bug #916054 (debdiff attached) to
DELAYED/2.

I hope this does not cause any troubles, and please let me know if
this is an issue and would like me to cancel it.

Regards,
Aurelien

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net
diff -Nru procmeter3-3.6/debian/changelog procmeter3-3.6/debian/changelog
--- procmeter3-3.6/debian/changelog 2014-03-22 16:38:22.0 +0100
+++ procmeter3-3.6/debian/changelog 2018-12-26 00:22:40.0 +0100
@@ -1,3 +1,11 @@
+procmeter3 (3.6-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * debian/patches/loff_t.patch
+   + Fix build with glibc 2.28 Closes: #916054.
+
+ -- Aurelien Jarno   Wed, 26 Dec 2018 00:22:40 +0100
+
 procmeter3 (3.6-1) unstable; urgency=low
 
   * New upstream release
diff -Nru procmeter3-3.6/debian/patches/loff_t.patch 
procmeter3-3.6/debian/patches/loff_t.patch
--- procmeter3-3.6/debian/patches/loff_t.patch  1970-01-01 01:00:00.0 
+0100
+++ procmeter3-3.6/debian/patches/loff_t.patch  2018-12-21 22:52:13.0 
+0100
@@ -0,0 +1,18 @@
+Description: Fix compilation with newer glibc
+Fixes compilation with newer glibc.
+If _XOPEN_SOURCE is defined _DEFAULT_SOURCE needs to be defined explicit
+to have the definition of loff_t.
+Author: Aurelien Jarno 
+Bug-Debian: https://bugs.debian.org/916054
+Last-Update: 2018-12-21
+
+--- procmeter3-3.6.orig/modules/longrun.c
 procmeter3-3.6/modules/longrun.c
+@@ -15,6 +15,7 @@
+   ***/
+ 
+ #define _XOPEN_SOURCE 500
++#define _DEFAULT_SOURCE
+ 
+ #include 
+ #include 
diff -Nru procmeter3-3.6/debian/patches/series 
procmeter3-3.6/debian/patches/series
--- procmeter3-3.6/debian/patches/series2014-03-22 16:38:22.0 
+0100
+++ procmeter3-3.6/debian/patches/series2018-12-21 22:51:43.0 
+0100
@@ -6,3 +6,4 @@
 #include.patch
 dont-override-flags.patch
 libX11.patch
+loff_t.patch


signature.asc
Description: PGP signature

Bug#917291: libass9 issue

[Tommy Wu]

I think this is not bug in harfbuzz 2.x, it should be the libass9 issue, the 
API change after harfbuzz 2.0.0, it's not compatible with libass 0.14 now.
recompile libass9 with --disable-harfbuzz option will solve this issue.

-- 

Bug#917226: systemd: systemd-machine-id-setup: error while loading shared libraries: libsystemd-shared-239.so: cannot open shared object file: No such file or directory

[Chris Lamb]

Hi Michael,

> >   $ sudo systemd-machine-id-setup
> >   systemd-machine-id-setup: error while loading shared libraries: 
> > libsystemd-shared-239.so: cannot open shared object file: No such file or 
> > directory
> > 
> >   $ ldd /usr/bin/systemd-machine-id-setup
> 
> The Debian systemd package ships systemd-machine-id-setup in /bin.
> Is this a usr-merged system or actually an (outdated) copy in /usr/bin?
> Which architecture is this?

Hm, this might actually be a botched usr-merged system:

  $ ls -l /usr/bin/systemd-machine-id-setup
  -rwxr-xr-x 1 root root 22,592 2018-11-20 18:44 
/usr/bin/systemd-machine-id-setup

  $ ls -l /bin/systemd-machine-id-setup
  -rwxr-xr-x 1 root root 22,696 2018-12-22 15:01 /bin/systemd-machine-id-setup

(Is this even really recoverable at this stage?)


Regards,

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

Bug#917306: libopenvdb-dev should depend on libtbb-dev & libblosc-dev

[GSR]

Package: libopenvdb-dev
Version: 5.2.0-5
Severity: normal

Header files from libopenvdb-dev include headers from libtbb-dev, so
it should depend on it, similar to libilmbase-dev. One example:
openvdb.h includes own tree/Tree.h, which includes tbb/atomic.h.

And probably libblosc-dev should also be a dep, as libopenvdb5.2
depends on libblosc1 and while VDB can be compiled without Blosc, the
Debian version has it.

Thanks,
GSR


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

Kernel: Linux 4.17.0-1-amd64 (SMP w/8 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: sysvinit (via /sbin/init)

Versions of packages libopenvdb-dev depends on:
ii  libilmbase-dev  2.2.1-2
ii  libopenvdb5.2   5.2.0-5

libopenvdb-dev recommends no packages.

libopenvdb-dev suggests no packages.

-- no debconf information

Bug#917293: kinit: The kdeinit5 consumes and takes about 3 ~ 5 minutes to give me control of the environment.

[Santiago José López Borrazás]

El 25/12/18 a las 23:31, Lisandro Damián Nicanor Pérez Meyer escribió:
>
> I mean your internet loopback device. Please send the output of
>
> ip addr

sjlopezb@local:~$ ip addr

(...)
2: eth0:  mtu 1500 qdisc pfifo_fast state
UP group default qlen 1000
    link/ether 00:1d:09:dd:a9:3e brd ff:ff:ff:ff:ff:ff
    inet 192.168.1.45/24 brd 192.168.1.255 scope global eth0
   valid_lft forever preferred_lft forever
    inet6 fe80::21d:9ff:fedd:a93e/64 scope link
   valid_lft forever preferred_lft forever
sjlopezb@local:~$

It is not a problem of routes. It's not a network problem either, because
I'm using wicd.

Network works perfect.

-- 
Saludos de Santiago José López borrazás.

Bug#915407: libpam-systemd: please add a virtual package "logind" to allow alternatives

[Adam Borowski]

On Mon, Dec 24, 2018 at 05:37:56PM -0300, Felipe Sateler wrote:
> On Sat, Dec 22, 2018 at 5:33 PM Adam Borowski  wrote:
> > Could you please either take this patch or propose a different approach?
> > I have received no feedback other than a brief unconclusive remark on IRC.
> 
> Sorry for the radio silence. Let's try to remedy that.

Thank you for moving this forward!

> > opt-in for every depender on libpam-systemd
> 
> This is a good feature of the proposal: it requires explicit opt-in by
> reverse dependencies.

> > Thus: if package X and Y need APIs that elogind provides, they'd be changed
> > to:
> > Depends: default-logind | logind
> > while package Z that needs a "bring-me-pink-pony" function will not.
> 
> I (not speaking for the whole team), have no objection to this patch.
> However, it was pointed out to me that virtual packages require policy
> updates[1], first starting as a debian-devel discussion. So I'm starting
> this now

Right.  In the meantime, you can test using libpam-elogind-compat which is
a hack that Provides: a real package.  This lacks the opt-in effect, but
outside of packaging metadata should work the same.

> The proposed virtual packages are:
> 
> logind: a org.freedesktop.login1 D-Bus API implementation
> default-logind: should be provided by the distributions default logind
> provider (currently pam-systemd)
> 
> Background: currently libpam-systemd provides two features currently used
> by third parties: one is the necessary hooks to start the systemd
> implementation of login1. The second is hooking up the systemd --user
> service manager. This virtual package attempts to disentangle the two so
> that packages that only require logind can use an alternative
> implementation.

Not sure if it's worth noting that the Provides must, and Depends can, be
versioned.  This allows requiring a certain level of the API.

> Adam/other elogind maintainers, please clarify/improve wording if this was
> somehow inaccurate.

Looks good to me, thank you!


Meow.
-- 
⢀⣴⠾⠻⢶⣦⠀ 
⣾⠁⢠⠒⠀⣿⡁ Ivan was a worldly man: born in St. Petersburg, raised in
⢿⡄⠘⠷⠚⠋⠀ Petrograd, lived most of his life in Leningrad, then returned
⠈⠳⣄ to the city of his birth to die.

Bug#917226: systemd: systemd-machine-id-setup: error while loading shared libraries: libsystemd-shared-239.so: cannot open shared object file: No such file or directory

[Michael Biebl]

Hi Chris!

On Mon, 24 Dec 2018 13:08:20 + Chris Lamb  wrote:
> Package: systemd
> Version: 240-1
> Severity: normal
> 
> Hi,
> 
> I'm seeing the following error:
> 
>   $ sudo systemd-machine-id-setup
>   systemd-machine-id-setup: error while loading shared libraries: 
> libsystemd-shared-239.so: cannot open shared object file: No such file or 
> directory
> 
>   $ ldd /usr/bin/systemd-machine-id-setup

The Debian systemd package ships systemd-machine-id-setup in /bin.
Is this a usr-merged system or actually an (outdated) copy in /usr/bin?
Which architecture is this?

On my (amd64) system:

$ ldd /bin/systemd-machine-id-setup
linux-vdso.so.1 (0x7fffca95c000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7ffbb9e0)
libsystemd-shared-240.so => /lib/systemd/libsystemd-shared-240.so
(0x7ffbb9b75000)
...

-- 
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#917277: epstool: incorrect bounding box calculated

[David Bremner]

Russell Lang  writes:

> David,
>
> The input file has
>   %%BoundingBox: 71 540 176 721
> epstool 3.09 calculates this
>   %%BoundingBox: 71 541 172 721
>
> This looks like the correct bounding box.

I get the following output

╭─ rocinante:software/debian/sketch/Doc 
╰─ (git)-[master]-% epstool --copy --bbox input.eps output.eps
"gs"  -dNOPAUSE -dBATCH -sDEVICE=bbox   -c "<> setpagedevice" -f "/tmp/gsviewOi1xph"
GPL Ghostscript 9.26 (2018-11-20)
Copyright (C) 2018 Artifex Software, Inc.  All rights reserved.
This software comes with NO WARRANTY: see the file PUBLIC for details.
%%BoundingBox: 589 3541 3172 3721
%%HiResBoundingBox: 589.805982 3541.013892 3171.982263 3720.131886
OK

╭─ rocinante:software/debian/sketch/Doc 
╰─ (git)-[master]-% grep BoundingBox output.eps 
%%BoundingBox: -2411 541 172 721
%%HiResBoundingBox: -2410.193 541.014 171.982 720.132



Maybe it depends on the version of ghostscript?

Bug#901289: New upstream home?

[Jesse Smith]

If it would be of help, I'd be happy to adopt the logsave program
upstream in the SysV init tree. Seems like the sort of tool that would
be mostly used during start-up and initscript usage.

That way we could be pretty sure logsave was available whenever
initscripts were being used. Thoughts?

- Jesse

Bug#917270: texlive-latex-extra-doc: Please add dtx files for dtxgallery

[Karl Berry]

I think in this particular case it would be better to move them to the
docfiles?

Sure, agreed. Moved for tonight's build (in upstream TL). Thanks. -k

Bug#917305: ITP: dictzip-java -- DictZip library for Java

[Andrej Shadura]

Package: wnpp
Severity: wishlist
Owner: Andrej Shadura 

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

* Package name: dictzip-java
  Version : 0.8.2
  Upstream Author : Hiroshi Miura
* URL : https://github.com/dictzip/dictzip-java
* License : GPL-2+ with Classpath exception
  Programming Lang: Java
  Description : DictZip library for Java

This package provides a Java library to access dictionary databases
compressed with the LZ77 algorithm in a manner which is completely
compatible with gzip(1), but using an extension that allows for random
access to chunks of about 57kB without the overhead of decompressing
the entire file.

This package is a dependency of OmegaT, a CAT tool.

-BEGIN PGP SIGNATURE-

iQFIBAEBCAAyFiEEeuS9ZL8A0js0NGiOXkCM2RzYOdIFAlwisGIUHGFuZHJld3No
QGRlYmlhbi5vcmcACgkQXkCM2RzYOdIvNQf7B7RmyHsfS/tq7z6BPqo/7iTh3WpV
hnNGQT7V0eRftAYJFKpeHkiTIeIahGRbAlDYAGApNMa09GbIYqW5QG7Gd2DNE5j8
TmlUrlM8PWiy9YHEAqp0f80/4Sb4hLWtLBiyAdPEzPwO3n21WVJYzfhyNDzDyaau
1jpxGut3HnBONNydO6aV9EmtbS4xZrBgYc4AEOk41lhU+20ujRVYmD981FUDlgRN
FkhMeTz2q32J/yizG42NXrxLXmuKKAo7pPsEP5Wr1NdvspzYMAg4b2WHZa3MBuOb
IRZttX6c7C19SlATqFhhpUdq5cuclUwy9+6wIlRe213X9yyGH8xdxRzRyw==
=tsL+
-END PGP SIGNATURE-

Bug#917293: kinit: The kdeinit5 consumes and takes about 3 ~ 5 minutes to give me control of the environment.

[Lisandro Damián Nicanor Pérez Meyer]

El mar., 25 dic. 2018 18:35, Santiago José López Borrazás 
escribió:

> El 25/12/18 a las 21:07, Lisandro Damián Nicanor Pérez Meyer escribió:
> >
> > Just a wild guess: is your loopback interface working?
>
> No. I am using XDM, to enter directly to KDE.
>

I mean your internet loopback device. Please send the output of

ip addr

>

Bug#917304: apt-file: missing final newline in /etc/apt/apt.conf.d/50apt-file.conf

[Sven Joachim]

Package: apt-file
Version: 3.2
Severity: minor

The file /etc/apt/apt.conf.d/50apt-file.conf is not terminated properly
by a final newline.  At first check this does apparently not have any
negative consequences.

$0.02 tip for Emacs users to avoid this mistake:

(setq require-final-newline 'ask)


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

Kernel: Linux 4.20.0-nouveau (SMP w/2 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)

Versions of packages apt-file depends on:
ii  apt  1.8.0~alpha3
ii  libapt-pkg-perl  0.1.34+b1
ii  liblist-moreutils-perl   0.416-1+b4
ii  libregexp-assemble-perl  0.36-1
ii  perl 5.28.1-3

apt-file recommends no packages.

apt-file suggests no packages.

-- no debconf information

Bug#917303: libdbd-mysql-perl: FTBFS (test failures) against mariadb 10.3

[gregor herrmann]

Source: libdbd-mysql-perl
Version: 4.049-1
Severity: serious
Tags: upstream
Justification: fails to build from source (but built successfully in the past)
Forwarded: https://github.com/perl5-dbi/DBD-mysql/issues/275

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

libdbd-mysql-perl's test suite fails when built with mariadb 10.3:

t/15reconnect.t .
1..16
ok 1 - Connected to database
ok 2 - checking for active handle
ok 3 - enabling reconnect
ok 4 - enabling autocommit
ok 5 - disconnecting active handle
ok 6 - checking for inactive handle
ok 7 - implicitly reconnecting handle with 'do'
ok 8 - checking for reactivated handle
ok 9 - Connected to database
ok 10 - checking for active handle
ok 11 - enabling reconnect
ok 12 - enabling autocommit
ok 13 - disconnecting active handle
ok 14 - checking for inactive handle
Failed 2/16 subtests

#   Failed test at t/rt118977-zerofill.t line 22.
#  got: '1'
# expected: '1'
# Looks like you failed 1 test of 8.
t/rt118977-zerofill.t ...
1..8
ok 1
ok 2
ok 3
ok 4
ok 5
ok 6
ok 7
not ok 8
Dubious, test returned 1 (wstat 256, 0x100)
Failed 1/8 subtests


Test Summary Report
- ---
t/15reconnect.t   (Wstat: 139 Tests: 14 Failed: 0)
  Non-zero wait status: 139
  Parse errors: Bad plan.  You planned 16 tests but ran 14.
t/rt118977-zerofill.t (Wstat: 256 Tests: 8 Failed: 1)
  Failed test:  8
  Non-zero exit status: 1
Files=73, Tests=2297, 37 wallclock secs ( 0.54 usr  0.10 sys +  6.45 cusr  0.81 
csys =  7.90 CPU)
Result: FAIL


During autopkgtests the same failures show up, both in the test run
against mariadb and mysql (identical output as during build above).


The upstream issue is not very detailed unfortunately.


Cheers,
gregor

-BEGIN PGP SIGNATURE-

iQKTBAEBCgB9FiEE0eExbpOnYKgQTYX6uzpoAYZJqgYFAlwiq5FfFIAALgAo
aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEQx
RTEzMTZFOTNBNzYwQTgxMDREODVGQUJCM0E2ODAxODY0OUFBMDYACgkQuzpoAYZJ
qgbCEA/9EIArxOo2XNCOR/gI22NAlJQT7jVyMj7mv+1pvxchwlTVQbz4bn+PWhSf
ZvGRjIEzlgz/ok+gTgXshu+qO1MxNkO0klGIiijdQsZH87n65b9PINu5X+lVOqSk
ajqoN+eXElVeIXDl6ee7MnWgAwm9FO7jjNAeMiaWrs5Id+iATNGc39frqMvxZuLU
22VHXJkwdYB02RyI1ViiybwAM3C0m7sb2pLgZXpP9xTF/zks708yZDcfPzpoielW
CAQBK0K7wl19zMu3MunD4qjNq0skQkRUOYZEvZxdqLzB+hVv4osSqZ2rnsAoVDl8
kRbJ3a/tEzUl6N4ffXCb803ePoabyy4YfiNBKHvVOlnyHJ9GpPkN/sOwU8gbbqLv
fGP3pQ+jUTxs3qrLLX82Y11gi1e6Sn3D/9LA/xr0HRmtd+FdVOIzdBNifKTuwHH9
76gLkgtminziQbZXjZ/WTejj44r5l5NqdlQ0Kxgxgdi4QSC/PUZ/8bOpDcaeKRlb
gOjKk2QFArCQwZCJPd+9FUiH0xIRVbwx4lNOt+KnUpHdtW0+9DOy33RNFKY8Xwxu
DuCI5720oRBmGBFGBRz30pYta0fgyVCVV05Cw4Ne7A3Zd78WFbOso8rNtnrxlRTf
wz6+7ChnuFyFTPB7dIyiXSkXG2tadIPaxFe9Zrr2fiKaF6kP1Os=
=wBcW
-END PGP SIGNATURE-

Bug#917215: systemd: FTBFS on armel and armhf (failing test)

[Michael Biebl]

Control: forwarded -1 https://github.com/systemd/systemd/issues/11248


Hi,

thanks for the bug report.

Am 24.12.18 um 09:31 schrieb Salvatore Bonaccorso:
> Source: systemd
> Severity: serious
> Justification: FTBFS
> 
> Hi
> 
> systemd/240-1 FTBFS on armel and armhf due to one failing test
> accordin to the build log:
> 
> https://buildd.debian.org/status/fetch.php?pkg=systemd=armel=240-1=1545498332=0
> https://buildd.debian.org/status/fetch.php?pkg=systemd=armhf=240-1=1545495147=0
> 
> (not checked if this might be a transient issue only).

It's not a transient issue and upstream is already aware.

Marking the bug report accordingly.

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#917269: kinit: Crashes when navigating to home directory in dolphin

[Bernhard Übelacker]

Control: reassign 917269 ffmpegthumbs 4:17.08.3-1


Dear Maintainer, hello Braun Gábor,
some informations on where and how to retrieve the debug symbol packages
is described in [1]. Maybe with them you can confirm my findings which
are just based on the offsets of the function addresses.

To reproduce one seems to need a video file with less than 5 MB,
or it will not be taken as source for the folder thumbnail, which
contains that video [2]. With that information you may be able to
identify the causing file.

Even worse it seems it needs that special video file as
I did not receive the crash.
But I guess this crash happens in moviedecoder.cpp, line 202,
because "m_pFormatContext->streams[m_VideoStream]" contains
for some reason an invalid pointer.

Maybe you can also add the output of the "mediainfo" tool to
that bug, if the file causing it got identified.


Kind regards,
Bernhard



[1] https://wiki.debian.org/HowToGetABacktrace
[2] https://bugs.kde.org/show_bug.cgi?id=238690


(gdb) bt
#0  0x7f4e4a6654f4 in ffmpegthumbnailer::MovieDecoder::seek 
(this=this@entry=0x7fffa2933d00, timeInSeconds=) at 
./ffmpegthumbnailer/moviedecoder.cpp:202
#1  0x7f4e4a66720a in 
ffmpegthumbnailer::VideoThumbnailer::generateThumbnail 
(this=this@entry=0x555aa55aae58, 
videoFile="/home/benutzer/test/test/test2.mov", imageWriter=..., image=...) at 
./ffmpegthumbnailer/videothumbnailer.cpp:105
#2  0x7f4e4a667359 in 
ffmpegthumbnailer::VideoThumbnailer::generateThumbnail 
(this=this@entry=0x555aa55aae58, 
videoFile="/home/benutzer/test/test/test2.mov", image=...) at 
./ffmpegthumbnailer/videothumbnailer.cpp:141
#3  0x7f4e4a664793 in FFMpegThumbnailer::create (this=0x555aa55aae40, 
path="/home/benutzer/test/test/test2.mov", width=, img=...) at 
./ffmpegthumbnailer.cpp:46
#4  0x7f4e5c0ade80 in ThumbnailProtocol::createSubThumbnail 
(this=this@entry=0x7fffa29343c0, thumbnail=..., 
filePath="/home/benutzer/test/test/test2.mov", 
segmentWidth=segmentWidth@entry=108, segmentHeight=segmentHeight@entry=68) at 
./thumbnail/thumbnail.cpp:719
#5  0x7f4e5c0ae458 in ThumbnailProtocol::drawSubThumbnail 
(this=this@entry=0x7fffa29343c0, p=..., 
filePath="/home/benutzer/test/test/test2.mov", width=width@entry=108, 
height=height@entry=68, xPos=xPos@entry=128, yPos=76, frameWidth=3) at 
./thumbnail/thumbnail.cpp:751
#6  0x7f4e5c0aeb30 in ThumbnailProtocol::thumbForDirectory 
(this=this@entry=0x7fffa29343c0, 
directory="thumbnail:/home/benutzer/test/test") at ./thumbnail/thumbnail.cpp:557
#7  0x7f4e5c0b0041 in ThumbnailProtocol::get (this=0x7fffa29343c0, 
url="thumbnail:/home/benutzer/test/test") at ./thumbnail/thumbnail.cpp:225
#8  0x7f4e57135df6 in KIO::SlaveBase::dispatch (this=0x7fffa29343c0, 
command=67, data="\000\000\000\"thumbnail:/home/benutzer/test/test" = {...}) at 
./src/core/slavebase.cpp:1119
#9  0x7f4e57131196 in KIO::SlaveBase::dispatchLoop 
(this=this@entry=0x7fffa29343c0) at ./src/core/slavebase.cpp:318
#10 0x7f4e5c0ad08d in kdemain (argc=, argv=) 
at ./thumbnail/thumbnail.cpp:130
#11 0x555aa4fc7e1c in launch (argc=4, _name=0x555aa5380d68 
"/usr/lib/x86_64-linux-gnu/qt5/plugins/kf5/kio/thumbnail.so", args=, cwd=, envc=0, envs=, reset_env=false, 
tty=0x0, avoid_loops=false, startup_id_str=0x555aa4fcb187 "0") at 
./src/kdeinit/kinit.cpp:706
#12 0x555aa4fc8eea in handle_launcher_request (sock=8, who=) 
at ./src/kdeinit/kinit.cpp:1146
#13 0x555aa4fc98fb in handle_requests (waitForPid=0) at 
./src/kdeinit/kinit.cpp:1339
#14 0x555aa4fc4645 in main (argc=argc@entry=5, 
argv=argv@entry=0x7fffa2934bd8) at ./src/kdeinit/kinit.cpp:1785
#15 0x7f4e5b26409b in __libc_start_main (main=0x555aa4fc3c70 , argc=5, argv=0x7fffa2934bd8, init=, fini=, rtld_fini=, stack_end=0x7fffa2934bc8) at 
../csu/libc-start.c:308
#16 0x555aa4fc52ca in _start () at ./src/kdeinit/kinit.cpp:802


(gdb) disassemble /m 0x7f4e4a665490,0x7f4e4a665510
Dump of assembler code from 0x7f4e4a665490 to 0x7f4e4a665510:
...
198 }
199
200 int ret = av_seek_frame(m_pFormatContext, -1, timestamp, 0);
   0x7f4e4a6654b8 :  mov
0x8(%rdi),%rdi
   0x7f4e4a6654c3 :  mov
$0x0,%edx
   0x7f4e4a6654c8 :  mov
$0x,%esi
   0x7f4e4a6654cd :  test   
%rax,%rax
   0x7f4e4a6654d0 :  cmovns 
%rax,%rdx
   0x7f4e4a6654d4 :  xor
%ecx,%ecx
   0x7f4e4a6654d6 :  callq  
0x7f4e4a664280 

201 if (ret >= 0) {
   0x7f4e4a6654db :  test   
%eax,%eax
   0x7f4e4a6654dd :  js 
0x7f4e4a66555a 

202 
avcodec_flush_buffers(m_pFormatContext->streams[m_VideoStream]->codec);
   0x7f4e4a6654df :  mov
0x8(%rbx),%rax
   0x7f4e4a6654e3 :  movslq 
(%rbx),%rdx
   0x7f4e4a6654e6 :  mov
$0xc8,%r12d
   0x7f4e4a6654ec :  mov
0x30(%rax),%rax
   0x7f4e4a6654f0 :  mov
(%rax,%rdx,8),%rax
=> 0x7f4e4a6654f4 : mov
0x8(%rax),%rdi
   0x7f4e4a6654f8 : callq  
0x7f4e4a664130 
   0x7f4e4a6654fd : nopl   
(%rax)

203  

Bug#917277: epstool: incorrect bounding box calculated

[Russell Lang]

David,

The input file has
  %%BoundingBox: 71 540 176 721
epstool 3.09 calculates this
  %%BoundingBox: 71 541 172 721

This looks like the correct bounding box.

Russell

On Wed, 26 Dec 2018 at 00:09, David Bremner  wrote:

> Package: epstool
> Version: 3.09-1
> Severity: normal
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> epstool calculates a very wide bounding box for the attached eps
> file. The result is so wide that TeX cannot include it, which breaks
> the sketch build. It would be great if epstool could be fixed so that
> I can unbreak sketch.
>
>
> - -- System Information:
> Debian Release: buster/sid
>   APT prefers testing
>   APT policy: (500, 'testing'), (1, 'experimental')
> Architecture: amd64 (x86_64)
>
> Kernel: Linux 4.18.0-3-amd64 (SMP w/4 CPU cores)
> Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8),
> LANGUAGE=en_CA:en (charmap=UTF-8)
> Shell: /bin/sh linked to /usr/bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
>
> Versions of packages epstool depends on:
> ii  ghostscript  9.26~dfsg-1
> ii  libc62.28-2
>
> epstool recommends no packages.
>
> epstool suggests no packages.
>
> - -- no debconf information
>
> -BEGIN PGP SIGNATURE-
>
> iQGzBAEBCAAdFiEE3VS2dnyDRXKVCQCp8gKXHaSnniwFAlwiJQcACgkQ8gKXHaSn
> nizRvwv+IsSn/eyBudkFuL0UNsAz6l1lq69IZePHjIOEeJJNpdgsed/I31uduBGk
> q/pvIBhcgSjwuIdBZJMz6iUc2s+6hBNSf5dHuykrNxrRRdANg2g8Iacy1nv6OmxA
> qNtfcgple5juCAM9vc8LyEX5DIwVBoeFIIL+fdeG/OdQsaLecQ7+b5hs9gM9A0e7
> wAmXj8QuCkBftpoL49EfPPWjL/QC6G3bWaO8BiUXS5gOavsj793dOkYt/+jIrH/E
> Toc4zHJsl5vK4gl7MApSs/G/5ETKtGblY0m/50dykW258ThbISNZRqdxiN4d4mj2
> yjqz84mYc6u7AjntshyruSH0xy2lBSxJCyuzYLYXt83+dNTludHrVkgs3ezxg/LK
> GzJBP3xyWRUafte1NShXpS8BGp62+kHH+jB8235FHYPM3xilLG1PoN1PJ19xptF4
> ir5MwlE8NYd4KgD1Mrdg5/qJeuMEvSoliVEXIriIgoYnE0bkNSNL3gX0yY8FH5L8
> s3fLs8VY
> =8EgG
> -END PGP SIGNATURE-
>

Bug#917302: java common creates a hidden etc/.java directory

[shirish शिरीष]

Package: java-common
Version: 0.70
Severity: normal

Dear Maintainer,
According to cruft/cruft-ng java-common creates a hidden /etc/.java
directory. I came to know about it using rkhunter where it showed up
as a suspicious package. Asking on the debian-java ML came to know it
is due to java-common package
https://lists.debian.org/debian-java/2018/12/msg00010.html

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

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

java-common depends on no packages.

java-common recommends no packages.

Versions of packages java-common suggests:
ii  default-jre  2:1.11-70

-- no debconf information


-- 
  Regards,
  Shirish Agarwal  शिरीष अग्रवाल
  My quotes in this email licensed under CC 3.0
http://creativecommons.org/licenses/by-nc/3.0/
http://flossexperiences.wordpress.com
EB80 462B 08E1 A0DE A73A  2C2F 9F3D C7A4 E1C4 D2D8

Bug#917293: kinit: The kdeinit5 consumes and takes about 3 ~ 5 minutes to give me control of the environment.

[Santiago José López Borrazás]

El 25/12/18 a las 21:07, Lisandro Damián Nicanor Pérez Meyer escribió:
>
> Just a wild guess: is your loopback interface working?

No. I am using XDM, to enter directly to KDE.

-- 
Saludos de Santiago José López borrazás.

Bug#917297: debhelper: please use version numbers with at least a dot

[Mattia Rizzolo]

Control: tag -1 moreinfo

On Tue, Dec 25, 2018 at 06:50:08PM +, Thorsten Glaser wrote:
> Please release the first version of each major debhelper
> not as “12” but as, for example, “12.0”.
> 
> Rationale: backporting.
> 
> When backporting 12.0 it will be versioned 12.0~bpo9+1,
> when backporting 12   it will be versioned 12~bpo9+1.
> 
> Version constraints normally read like: debhelper (>= 12~)
> 
> Only 12.0~bpo9+1 fulfills this criterium, 12~bpo9+1 doesn’t.

That's not true:

mattia@warren ~ % dpkg --compare-versions 12~bpo9+1 gt 12~ && echo true
true


> This was a _real_ problem when debhelper 11 first entered
> stretch-backports.

The issue back then was because people used "debhelper (>= 11)" without
the trailing ~ (I know I didn't as well, and I keep not using it tbh).

-- 
regards,
Mattia Rizzolo

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


signature.asc
Description: PGP signature

Bug#901289: breaks boot in containers

[Adam Borowski]

On Tue, Dec 25, 2018 at 01:39:22PM +, Dmitry Bogatov wrote:
> [2018-12-23 22:58] Adam Borowski 
> > Uh oh...  looks like the logsave issue suddenly became RCish: it
> > prevents lxc containers from booting unattended:

> I can propose following ad-hoc solution. Objections? Better suggestions?

> +++ b/debian/src/initscripts/etc/init.d/checkfs.sh

> +# This function does not actually belong here; it is duct-tape solution
> +# for #901289.
> +logsave_best_effort () {
> + if [ -x /sbin/logsave ] ; then
> + logsave -s "${FSCK_LOGFILE}" "$@"
> + else
> + "$@"
> + fi
> +}

The other option is to ship our own implementation of logsave -- it's a
single-C-file tool, and initscripts is already arch:any.  On the other hand,
it would add some bloat to a mandatory package, and make it harder to
convert to arch:all later.

So I'm not objecting to your solution.


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀ 
⣾⠁⢠⠒⠀⣿⡁ Ivan was a worldly man: born in St. Petersburg, raised in
⢿⡄⠘⠷⠚⠋⠀ Petrograd, lived most of his life in Leningrad, then returned
⠈⠳⣄ to the city of his birth to die.

Bug#917301: [src:node-timers-browserify] use browserify

[Bastien Roucariès]

Package: src:node-timers-browserify
Version: 2.0.6+dfsg-1
Severity: normal
control: block -1 by 780357

Like upstream we should use browserify instead of browserify-lite


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

Bug#916899: linux-image-4.18.0-0.bpo.3-amd64: NULL pointer dereference in i915

[Ben Hutchings]

Control: forcemerge 914495 -1

This is fixed in Linux 4.19, currently available in unstable.

Ben.

-- 
Ben Hutchings
It is impossible to make anything foolproof
because fools are so ingenious.



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

Bug#917234: [initramfs-tools] Unable to detect root device

[Ben Hutchings]

Control: tag -1 moreinfo

On Mon, 2018-12-24 at 15:05 +0100, Paul Menzel wrote:
> Package: initramfs-tools
> Version: 0.132
> Severity: normal
> 
> Dear Debian folks,
> 
> 
> Updating the Linux kernel package fails with the error below.
[...]

I think this is bug #917124.  Try downgrading udev to version 239-15
(still in testing).

Ben.

-- 
Ben Hutchings
It is impossible to make anything foolproof
because fools are so ingenious.



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

Bug#917261: linux-image-4.19.0-1-amd64: /dev/mapper symlink for dm-crypt volume containing / not created on system startup

[Ben Hutchings]

Control: reassign -1 udev 240-1
Control: forcemerge 917124 -1

This seems to be a bug in udev, not the kernel.  You will only have
noticed it once you rebooted for the kernel upgrade.

Ben.

-- 
Ben Hutchings
It is impossible to make anything foolproof
because fools are so ingenious.



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

Bug#917280: kernel panic on intel gen4 gfx card

[Ben Hutchings]

On Tue, 2018-12-25 at 15:45 +, ? ? wrote:
> Hi, Greg
> 
> I found on Debian testing with kernel 4.18.20 fail boot, kernel panic
> on i915. and reported it to Debian bug 917280 [0], with panic log[1].
> 
> after revert:
> 
> commit 06e562e7f515292ea7721475950f23554214adde
> Author: Chris Wilson 
> Date:   Mon Nov 5 09:43:05 2018 +
> 
> drm/i915/ringbuffer: Delay after EMIT_INVALIDATE for gen4/gen5
> 
> System boots to desktop.
> 
> [0]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=917280
> [1]:
> https://bugs.debian.org/cgi-bin/bugreport.cgi?att=1;bug=917280;filename=dmesg.txt;msg=10

The 4.18 stable branch is no longer maintained.

I suspect this is the same as  and
, which is fixed
in 4.19 (currently in unstable).

Ben.

-- 
Ben Hutchings
It is impossible to make anything foolproof
because fools are so ingenious.



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

Bug#917293: kinit: The kdeinit5 consumes and takes about 3 ~ 5 minutes to give me control of the environment.

[Lisandro Damián Nicanor Pérez Meyer]

El mar., 25 dic. 2018 14:51, Santiago José López Borrazás 
escribió:

> Package: kinit
> Version: 5.51.0-1
> Severity: important
>
> Dear Maintainer,
>
> When I want to enter the KDE, it takes me a lot to finish the session. It
> consumes CPU and it takes, like an average of between 3 and 5 minutes to
> give me session control.
>
> I have tried creating another user and do the same.



Just a wild guess: is your loopback interface working?

Bug#917193: wpasupplicant: missing newline character in error message

[Vincent Lefevre]

On 2018-12-24 09:52:58 +0100, Andrej Shadura wrote:
> On Sun, 23 Dec 2018 at 23:54, Vincent Lefevre  wrote:
> > I got the following error (via wicd logs):
> >
> > 2018/12/23 22:11:27 :: wpa_cli -i wlp61s0 terminate
> > Failed to connect to non-global ctrl_ifname: wlp61s0  error: No such file 
> > or directory
> >
> > This should have been:
> >
> > Failed to connect to non-global ctrl_ifname: wlp61s0
> > error: No such file or directory
> 
> Thanks for reporting this and the other bug. Could you please try 2.7
> from experimental?

I still get the error message in bad format, but the error message
now appears only in the system logs (journalctl).

For the connection failure itself, I don't know yet. This may be a bug
in wpasupplicant as I have no issue with Android.

Here are the full logs:

Dec 25 20:39:44 zira kernel: IPv6: ADDRCONF(NETDEV_UP): wlp61s0: link is not 
ready
Dec 25 20:39:44 zira wicd[779]: Failed to connect to non-global ctrl_ifname: 
wlp61s0  error: No such file or directory
Dec 25 20:39:44 zira wicd[779]: Error for wireless request "Set Bit Rate" 
(8B20) :
Dec 25 20:39:44 zira wicd[779]: invalid argument "NoneM".
Dec 25 20:39:47 zira kernel: wlp61s0: authenticate with 00:1f:33:89:73:4e
Dec 25 20:39:47 zira kernel: wlp61s0: send auth to 00:1f:33:89:73:4e (try 1/3)
Dec 25 20:39:47 zira kernel: wlp61s0: authenticated
Dec 25 20:39:47 zira kernel: wlp61s0: aborting association with 
00:1f:33:89:73:4e by local choice (Reason: 3=DEAUTH_LEAVING)
Dec 25 20:39:47 zira kernel: wlp61s0: authenticate with 00:1f:33:89:73:4e
Dec 25 20:39:47 zira kernel: wlp61s0: send auth to 00:1f:33:89:73:4e (try 1/3)
Dec 25 20:39:47 zira kernel: wlp61s0: aborting authentication with 
00:1f:33:89:73:4e by local choice (Reason: 3=DEAUTH_LEAVING)
Dec 25 20:39:47 zira kernel: wlp61s0: authenticate with 00:1f:33:89:73:4e
Dec 25 20:39:47 zira kernel: wlp61s0: send auth to 00:1f:33:89:73:4e (try 1/3)
Dec 25 20:39:47 zira kernel: wlp61s0: send auth to 00:1f:33:89:73:4e (try 2/3)
Dec 25 20:39:47 zira kernel: wlp61s0: authenticated
Dec 25 20:39:47 zira kernel: wlp61s0: associate with 00:1f:33:89:73:4e (try 1/3)
Dec 25 20:39:47 zira kernel: wlp61s0: RX AssocResp from 00:1f:33:89:73:4e 
(capab=0x401 status=0 aid=5)
Dec 25 20:39:47 zira kernel: wlp61s0: associated
Dec 25 20:39:57 zira kernel: wlp61s0: deauthenticating from 00:1f:33:89:73:4e 
by local choice (Reason: 3=DEAUTH_LEAVING)

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#915950: workaround (dconf-service: /var/run/user//dconf/user switches ownership to root:root)

[Dr. A. Stammler]

Problems can be reduced by running a script to check and reset file ownerships 
every minute (/etc/crontab). Some processes (like ‘mate-panel’, 
‘mate-settings-demon’) still need to be killed, though.
#!/bin/bash

LOGTAG="$(basename $0)"

RUN_USER_DIR="/var/run/user"

#PROCESSES_TO_RESTART='mate-panel'

EXITVALUE=0

function test_D_Conf_user_file_permissions {
 DUFLISTING=$(ls -n "$DCONF_USER_FILE")

 #echo "$DUFLISTING"
 read DUFPERMISSIONS DUFLINKS DUFUID DUFGID DUFDETAILS <<<$(echo "$DUFLISTING")
 #echo "user & group: $RUN_UID:$RUN_GID; D Conf file: $DUFUID:$DUFGID"
 logger --tag "$LOGTAG" -p 'user.debug' "user & group: $RUN_UID:$RUN_GID; D 
Conf file: $DUFUID:$DUFGID"

 test "$DUFUID" == "$RUN_UID" -a "$DUFGID" == "$RUN_GID"
} # function test_D_Conf_user_file_permissions

function show_situation {
 top -b -n 1 | sed -e '12,$d'
 free
} # function show_situation

cd "$RUN_USER_DIR"
for RUN_UID in *
do
 if
  #test "$RUN_UID" != '0'
  test $RUN_UID -ge 1000
 then
  RUN_GID="$(id -g $RUN_UID)"
  DCONF_USER_DIR="$RUN_USER_DIR/$RUN_UID/dconf"
  DCONF_USER_FILE="$DCONF_USER_DIR/user"
  
  #ls -al "$DCONF_USER_DIR"

  if
   ! test_D_Conf_user_file_permissions
  then
   #echo -n "→ Permissions seem wrong. "
   #echo "→ Permissions seem wrong; processes accessing $DCONF_USER_DIR:"
   #fuser -v "$DCONF_USER_DIR"

   #echo "→ Trying to reset ownership of $DCONF_USER_FILE…"
   logger --tag "$LOGTAG" -p 'user.notice' "→ Trying to reset ownership of 
$DCONF_USER_FILE…"
   #chown -v "$RUN_UID:$RUN_GID" "$DCONF_USER_FILE"
   chown "$RUN_UID:$RUN_GID" "$DCONF_USER_FILE"

   #echo '→'
   #killall -v -SIGHUP $PROCESSES_TO_RESTART

   if
! test_D_Conf_user_file_permissions
   then
#echo '* ERROR: could not reset ownership.'
logger --tag "$LOGTAG" -p 'user.crit' '* could not reset ownership.'
EXITVALUE=1
   fi
  #else
   #echo '→ Permissions seem fine; no action taken.'
  fi
 #else
  ##echo "Super user (UID $RUN_UID) ignored."
  #echo "System user (UID $RUN_UID) ignored."
 fi
 #echo
done

#echo '⇒'
#show_situation
#echo

exit $EXITVALUE


signature.asc
Description: PGP signature

Bug#916834: freshplayerplugin: FTBFS on big-endian architectures: test fails

[Rinat Ibragimov]

I believe that the issue is addressed in the attached patch.
(Already applied in the upstream repository).

--
Rinat
From 58596f4745190654cff4a5ad6a2bd4ac37b74800 Mon Sep 17 00:00:00 2001
From: Rinat Ibragimov 
Date: Tue, 25 Dec 2018 22:22:41 +0300
Subject: [PATCH] tests: use uint16_t for UTF-16 code points in charset test

Charset-related APIs are using 16-bit uint16_t when referring to UTF-16,
and are not obligated to have any particular byte layout in memory. Those
are different for little- and big-endian machines, which caused test to
fail when compiling on mips and s390x.
---
 tests/test_ppb_char_set.c | 40 ++-
 1 file changed, 18 insertions(+), 22 deletions(-)

diff --git a/tests/test_ppb_char_set.c b/tests/test_ppb_char_set.c
index 8163b2dc..bb25d3f6 100644
--- a/tests/test_ppb_char_set.c
+++ b/tests/test_ppb_char_set.c
@@ -43,8 +43,8 @@ TEST(ppb_char_set, extract_relevant_part_from_locale_name)
 TEST(ppb_char_set, to_utf16_all_ASCII)
 {
 const char *in = "Hello, world!";
-const uint8_t out[] = {'H', 0, 'e', 0, 'l', 0, 'l', 0, 'o', 0, ',', 0, ' ', 0, 'w', 0,
-   'o', 0, 'r', 0, 'l', 0, 'd', 0, '!', 0};
+const uint16_t out[] = {'H', 'e', 'l', 'l', 'o', ',', ' ',
+'w', 'o', 'r', 'l', 'd', '!'};
 uint32_t res_len = ;
 uint16_t *res = ppb_char_set_char_set_to_utf16(0, in, strlen(in), "UTF-8",
PP_CHARSET_CONVERSIONERROR_FAIL, _len);
@@ -56,9 +56,8 @@ TEST(ppb_char_set, to_utf16_all_ASCII)
 TEST(ppb_char_set, to_utf16_basic_UTF_8)
 {
 const char *in = "Привет, мир!";
-const uint8_t out[] = {0x1f, 0x04, 0x40, 0x04, 0x38, 0x04, 0x32, 0x04, 0x35, 0x04,
-   0x42, 0x04, 0x2c, 0x00, 0x20, 0x00, 0x3c, 0x04, 0x38, 0x04,
-   0x40, 0x04, 0x21, 0x00};
+const uint16_t out[] = {0x41f, 0x440, 0x438, 0x432, 0x435, 0x442,
+0x2c,  0x20,  0x43c, 0x438, 0x440, 0x21};
 uint32_t res_len = ;
 uint16_t *res = ppb_char_set_char_set_to_utf16(0, in, strlen(in), "UTF-8",
PP_CHARSET_CONVERSIONERROR_FAIL, _len);
@@ -83,8 +82,7 @@ TEST(ppb_char_set, to_utf16_wrong_UTF_8_with_error)
 
 TEST(ppb_char_set, from_utf16_all_ASCII)
 {
-const uint8_t in[] = {'H', 0, 'e', 0, 'l', 0, 'l', 0, 'o', 0, ',', 0, ' ', 0, 'w', 0,
-  'o', 0, 'r', 0, 'l', 0, 'd', 0, '!', 0};
+const uint16_t in[] = {'H', 'e', 'l', 'l', 'o', ',', ' ', 'w', 'o', 'r', 'l', 'd', '!'};
 const char *out = "Hello, world!";
 uint32_t res_len = ;
 char *res = ppb_char_set_utf16_to_char_set(0, (const uint16_t *)in,
@@ -97,9 +95,8 @@ TEST(ppb_char_set, from_utf16_all_ASCII)
 
 TEST(ppb_char_set, to_utf16_non_ASCII_all_correct)
 {
-const uint8_t in[] = {0x1f, 0x04, 0x40, 0x04, 0x38, 0x04, 0x32, 0x04, 0x35, 0x04,
-  0x42, 0x04, 0x2c, 0x00, 0x20, 0x00, 0x3c, 0x04, 0x38, 0x04,
-  0x40, 0x04, 0x21, 0x00}; // "Привет, мир!"
+const uint16_t in[] = {0x41f, 0x440, 0x438, 0x432, 0x435, 0x442, 0x2c,
+   0x20,  0x43c, 0x438, 0x440, 0x21};  // "Привет, мир!"
 const char *out = "\xcf\xf0\xe8\xe2\xe5\xf2\x2c\x20\xec\xe8\xf0\x21"; // "Привет, мир!"
 uint32_t res_len = ;
 char *res = ppb_char_set_utf16_to_char_set(0, (const uint16_t *)in,
@@ -112,9 +109,9 @@ TEST(ppb_char_set, to_utf16_non_ASCII_all_correct)
 
 TEST(ppb_char_set, to_utf16_non_ASCII_PP_CHARSET_CONVERSIONERROR_FAIL)
 {
-const uint8_t in[] = {0x1f, 0x04, 0x40, 0x04, 0x38, 0x04, 0x32, 0x04, 0x35, 0x04,
-  0x42, 0x04, 0x2c, 0x00, 0x20, 0x00, 0x6b, 0x26, 0x3c, 0x04,
-  0x38, 0x04, 0x40, 0x04, 0x21, 0x00}; // "Привет, ♫мир!"
+const uint16_t in[] = {0x41f, 0x440,  0x438, 0x432, 0x435, 0x442, 0x2c,
+   0x20,  0x266b, 0x43c, 0x438, 0x440, 0x21};
+// "♫" in "Привет, ♫мир!" cannot be represented in cp1251.
 // const char *out = "\xcf\xf0\xe8\xe2\xe5\xf2\x2c\x20\xec\xe8\xf0\x21"; // "Привет, мир!"
 uint32_t res_len = ;
 char *res = ppb_char_set_utf16_to_char_set(0, (const uint16_t *)in,
@@ -127,9 +124,9 @@ TEST(ppb_char_set, to_utf16_non_ASCII_PP_CHARSET_CONVERSIONERROR_FAIL)
 
 TEST(ppb_char_set, to_utf16_non_ASCII_PP_CHARSET_CONVERSIONERROR_SKIP)
 {
-const uint8_t in[] = {0x1f, 0x04, 0x40, 0x04, 0x38, 0x04, 0x32, 0x04, 0x35, 0x04,
-  0x42, 0x04, 0x2c, 0x00, 0x20, 0x00, 0x6b, 0x26, 0x3c, 0x04,
-  0x38, 0x04, 0x40, 0x04, 0x21, 0x00}; // "Привет, ♫мир!"
+const uint16_t in[] = {
+0x41f, 0x440,  0x438, 0x432, 0x435, 0x442, 0x2c,
+0x20,  0x266b, 0x43c, 0x438, 0x440, 0x21};  // "Привет, ♫мир!"
 const char *out = "\xcf\xf0\xe8\xe2\xe5\xf2\x2c\x20\xec\xe8\xf0\x21"; // "Привет, мир!"
 uint32_t res_len = ;
 char *res 

Bug#917274: task-german: depends on transitional dummy package aspell-de-alt (should be aspell-de-1901)

[Holger Wansing]

Control: tags -1 + pending

Jonas Smedegaard  wrote:
> Package: task-german
> Version: 1:2-31
> Severity: minor
> 
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
> 
> Package task-german depends on aspell-de-alt, which describes itself as
> a "dummy transitional package" which can be safely removed.
> 
> task-german should instead depend (directly) on aspell-de-1901.

I have removed aspell-de-alt completely.
We don't need such a dictionary for the old orthography in default installations
anymore (it's obsolete for more than 20 years). Thanks for noticing!

Tagging this bug as pending.



Holger


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

Bug#895743: php-elisp package too old

[Ola Lundqvist]

Hi

I thought I had already filed an RFA for this package.

You are most welcome to take it over.

I have too little time to spend on this unfortunately.

But I should really try as the release is closing.

If you have the possibility to take it over I would be grateful.

/ Ola

Sent from a phone

Den sön 23 dec. 2018 10:45Eugen Dedu  skrev:

> Hi Ola,
>
> I use PHP within Emacs.  As far as I know, php-mode (php-elisp) is the
> only Emacs package to provide a PHP mode.  The current version of
> php-elisp in Debian does not even start in Emacs (I use 26.1).  This
> means that currently Emacs in Debian does not support PHP language.
>
> Would it be possible to update the php-elisp package in Debian?
>
> Alternatively, package another recent package providing PHP mode?
>
> Finally, if you do not have time to maintain this Debian package, can
> you orphan it or fill an RFA, cf. https://wiki.debian.org/Orphaning?
>
> Best regards,
> --
> Eugen Dedu
> Associate Professor / Maître de conférences HDR
> OMNI team leader
> FEMTO-ST Institute, Univ. Bourgogne Franche-Comté, CNRS
> Montbéliard, France
> tel. +33 3 81 99 47 75
> http://eugen.dedu.free.fr
>

Bug#917075: mariadb-10.3: libmariadb3 causes removal of default-libmysqlclient-dev

[Sebastiaan Couwenberg]

On 12/25/18 8:12 PM, Otto Kekäläinen wrote:
> ti 25. jouluk. 2018 klo 10.17 Sebastiaan Couwenberg
> (sebas...@xs4all.nl) kirjoitti:
>>
>> On 12/25/18 8:57 AM, Otto Kekäläinen wrote:
>>> Can you please provide an actual pbuilder command or something I can
>>> copy-paste to reproduce the actual problem (and not just the aptitude
>>> symptom)?
>>
>> Sure:
>>
>>  sudo cowbuilder --create \
>>  --distribution=sid \
>>  --basepath=/var/cache/pbuilder/base-sid.cow
>>  dget -u \
>>   http://deb.debian.org/debian/pool/main/g/gdal/gdal_2.3.3+dfsg-1.dsc
>>  cd gdal-2.3.3/
>>  dch -nm "Test rebuild"
>>  pdebuild --pbuilder cowbuilder -- \
>>   --basepath /var/cache/pbuilder/base-sid.cow/
>>
>> pbuilder will be unstable to install the build dependencies, causing the
>> configure target to disable MySQL support despite using the --with-mysql
>> option:
>>
>>MySQL support: no
> 
> I cannot reproduce this inside a Docker image (e.g. via Salsa
> gitlab-ci.yml) because the operation is too heavy, but basically this
> bug report is about how aptitude resolves build dependencies and that
> specific part can be reproduced with:
> 
> aptitude -y build-dep gdal
> 
> This, however, does not result in any problems either.

Have you checked the buildlog to see whether MySQL support is enabled or
not?

Also try building grass, vtk7, or any of the other affected packages.
Both grass & vtk7 FTBFS in my sid pbuilder chroots.

>> Please also answer my questions:
>>
>>> Isn't the appropriate fix to build libmariadbclient-dev-compat from
>>> the mariadb-10.3 instead of 10.1? Aren't you now transitioning from
>>> 10.1 to 10.3? And shouldn't mysql-defaults be updated for that too?
> 
> Of course, in due time, say 2-3 days after mariadb-10.3 is in unstable.

For the record, mysql-defaults (1.0.5) has been uploaded to unstable and
updated to depend on the mariadb-10.3 packages.
default-libmysqlclient-dev now depends on libmariadb-dev-compat instead
of libmariadbclient-dev.

Kind Regards,

Bas

-- 
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1

Bug#916877: lintian: check that 1.2-3~debXuY changelog stanza follows a 1.2-3 changelog stanza

[Chris Lamb]

Hi Salvatore,

> IIRC this particular change was actually not based on a rebuild of the
> unstable's one but an import of 3.4.2 on top of the previous stretch
> packaging.

Getcha. This sounds like a case that is special enough that it is fine
for Lintian to warn about normally, no?

(I mean, IMHO it's actually sometimes nice to see a Lintian warning
when you are know you are doing something slightly out of the
ordinary, if only for the confirmation that you are doing it as you
intend.)


Regards,

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

Bug#917296: emacs-gtk: Emacs GNUS can no longer use movemail

[Sven Joachim]

Control: forwarded -1 https://debbugs.gnu.org/cgi/bugreport.cgi?bug=31737
Control: tags -1 + patch

On 2018-12-25 19:43 +0100, Ronan KERYELL wrote:

> Package: emacs-gtk
> Version: 1:26.1+1-2
> Severity: normal
>
> Dear Maintainer,
>
> Emacs 26.1 just landed into Debian/unstable and it breaks GNUS reading
> local e-mail with the '(file)' method because the movemail configuration
> changed in 26.1 as explained in the NEWS:
>
>> ** The new option 'configure --with-mailutils' causes Emacs to rely on
>> GNU Mailutils to retrieve email.  It is recommended, and is the
>> default if GNU Mailutils is installed
>
> This problem seems to have been already discussed last June in
> http://permalink.gmane.org/gmane.emacs.gnus.general/88065
> but it seems difficult to access this information right now in Gmane.
>
> Since emacs-bin-common depends already on mailutils, configure Emacs
> with
> 'configure --with-mailutils'
> should probably fix the problem.

It does not, since Emacs is already configured that way.  In Emacs 26.2,
the issue will be fixed by the patch at[1] which should probably be
cherry-picked for the Debian package.

Cheers,
   Sven


1. 
https://git.savannah.gnu.org/cgit/emacs.git/commit/?h=emacs-26=63f1dc4f7c33cc7cc738dbfae3d8192ae448b2f6

Bug#917075: mariadb-10.3: libmariadb3 causes removal of default-libmysqlclient-dev

[Otto Kekäläinen]

ti 25. jouluk. 2018 klo 10.17 Sebastiaan Couwenberg
(sebas...@xs4all.nl) kirjoitti:
>
> On 12/25/18 8:57 AM, Otto Kekäläinen wrote:
> > Can you please provide an actual pbuilder command or something I can
> > copy-paste to reproduce the actual problem (and not just the aptitude
> > symptom)?
>
> Sure:
>
>  sudo cowbuilder --create \
>  --distribution=sid \
>  --basepath=/var/cache/pbuilder/base-sid.cow
>  dget -u \
>   http://deb.debian.org/debian/pool/main/g/gdal/gdal_2.3.3+dfsg-1.dsc
>  cd gdal-2.3.3/
>  dch -nm "Test rebuild"
>  pdebuild --pbuilder cowbuilder -- \
>   --basepath /var/cache/pbuilder/base-sid.cow/
>
> pbuilder will be unstable to install the build dependencies, causing the
> configure target to disable MySQL support despite using the --with-mysql
> option:
>
>MySQL support: no

I cannot reproduce this inside a Docker image (e.g. via Salsa
gitlab-ci.yml) because the operation is too heavy, but basically this
bug report is about how aptitude resolves build dependencies and that
specific part can be reproduced with:

aptitude -y build-dep gdal

This, however, does not result in any problems either.

> Please also answer my questions:
>
> > Isn't the appropriate fix to build libmariadbclient-dev-compat from
> > the mariadb-10.3 instead of 10.1? Aren't you now transitioning from
> > 10.1 to 10.3? And shouldn't mysql-defaults be updated for that too?

Of course, in due time, say 2-3 days after mariadb-10.3 is in unstable.

Bug#799626: RFP: beancount -- command line double-entry bookkeeping system

[Stefano Zacchiroli]

On Mon, Dec 24, 2018 at 07:30:31PM +0200, Martin Michlmayr wrote:
> So this issue was reported and fixed already upstream:
> 
> Here's the original bug report:
> 
> https://bitbucket.org/blais/beancount/issues/341/test_utilsfind_repository_root-doesnt-work

Thanks Martin for finding this, and thanks James for raising it upstream
after last time I tried it out.

I've updated the package to a hg snapshot of today (which includes the
commits with the fix, and more). The source package as it is on salsa
now builds fine on a fresh unstable chroot.

Testing welcome.

Cheers
-- 
Stefano Zacchiroli . z...@upsilon.cc . upsilon.cc/zack . . o . . . o . o
Computer Science Professor . CTO Software Heritage . . . . . o . . . o o
Former Debian Project Leader & OSI Board Director  . . . o o o . . . o .
« the first rule of tautology club is the first rule of tautology club »


signature.asc
Description: PGP signature

Bug#917300: olive: Incomplete debian/copyright?

[Chris Lamb]

Source: olive
Version: 20181130-1
Severity: serious
Justication: Policy §12.5
X-Debbugs-CC: Gürkan Myczko , 
ftpmas...@debian.org

Hi,

I just ACCEPTed olive from NEW but noticed it was missing attribution 
in debian/copyright for at least io/crc32.h.

This is in no way exhaustive so please check over the entire package 
carefully and address these on your next upload.


Regards,

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

Bug#917299: centreon-broker: Incomplete debian/copyright?

[Chris Lamb]

Source: centreon-broker
Version: 18.10.0-3
Severity: serious
Justication: Policy 12.5
X-Debbugs-CC: Sebastien Delafond , 
ftpmas...@debian.org

Hi,

I just ACCEPTed centreon-broker from NEW but noticed it was missing 
attribution in debian/copyright for at least Andreas Ericsson and Max
Schubert.

This is in no way exhaustive so please check over the entire package 
carefully and address these on your next upload.


Regards,

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

Bug#917298: trollsift: Incomplete debian/copyright?

[Chris Lamb]

Source: trollsift
Version: 0.3.1-1
Severity: serious
Justication: Policy 12.5
X-Debbugs-CC: Antonio Valentino , 
ftpmas...@debian.org

Hi,

I just ACCEPTed trollsift from NEW but noticed it was missing 
attribution in debian/copyright for at least Martin Raspaud.

This is in no way exhaustive so please check over the entire package 
carefully and address these on your next upload.


Regards,

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

Bug#917297: debhelper: please use version numbers with at least a dot

[Thorsten Glaser]

Package: debhelper
Version: 12
Severity: wishlist

Please release the first version of each major debhelper
not as “12” but as, for example, “12.0”.

Rationale: backporting.

When backporting 12.0 it will be versioned 12.0~bpo9+1,
when backporting 12   it will be versioned 12~bpo9+1.

Version constraints normally read like: debhelper (>= 12~)

Only 12.0~bpo9+1 fulfills this criterium, 12~bpo9+1 doesn’t.
This was a _real_ problem when debhelper 11 first entered
stretch-backports.

Thanks in advance!

Bug#917243: ghostwriter: Please suggest optional export tools: pandoc discount cmark

[Jonas Smedegaard]

Quoting Sebastien Chavaux (2018-12-25 19:15:57)
> Oki I take care of it with the upgrade to version 1.7.4.

Excellent!

 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: signature

Bug#917296: emacs-gtk: Emacs GNUS can no longer use movemail

[Ronan KERYELL]

Package: emacs-gtk
Version: 1:26.1+1-2
Severity: normal

Dear Maintainer,

Emacs 26.1 just landed into Debian/unstable and it breaks GNUS reading
local e-mail with the '(file)' method because the movemail configuration
changed in 26.1 as explained in the NEWS:

> ** The new option 'configure --with-mailutils' causes Emacs to rely on
> GNU Mailutils to retrieve email.  It is recommended, and is the
> default if GNU Mailutils is installed

This problem seems to have been already discussed last June in
http://permalink.gmane.org/gmane.emacs.gnus.general/88065
but it seems difficult to access this information right now in Gmane.

Since emacs-bin-common depends already on mailutils, configure Emacs
with
'configure --with-mailutils'
should probably fix the problem.

In the meantime, a workaround is to custom-set-variables with
'(mail-source-movemail-program "movemail.mailutils")


Thank you.

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

Kernel: Linux 4.19.0-1-amd64 (SMP w/12 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 emacs-gtk depends on:
ii  emacs-bin-common   1:26.1+1-2
ii  emacs-common   1:26.1+1-2
ii  libacl12.2.52-3+b1
ii  libasound2 1.1.7-2
ii  libatk1.0-02.30.0-2
ii  libc6  2.28-3
ii  libcairo-gobject2  1.16.0-2
ii  libcairo2  1.16.0-2
ii  libdbus-1-31.12.12-1
ii  libfontconfig1 2.13.1-2
ii  libfreetype6   2.9.1-3
ii  libgdk-pixbuf2.0-0 2.38.0+dfsg-7
ii  libgif75.1.4-3
ii  libglib2.0-0   2.58.1-2
ii  libgnutls303.6.5-2
ii  libgomp1   8.2.0-13
ii  libgpm21.20.7-5
ii  libgtk-3-0 3.24.2-3
ii  libice62:1.0.9-2
ii  libjpeg62-turbo1:1.5.2-2+b1
ii  liblcms2-2 2.9-3
ii  libm17n-0  1.8.0-2
ii  libmagickcore-6.q16-6  8:6.9.10.14+dfsg-7
ii  libmagickwand-6.q16-6  8:6.9.10.14+dfsg-7
ii  libotf00.9.13-4
ii  libpango-1.0-0 1.42.4-5
ii  libpangocairo-1.0-01.42.4-5
ii  libpng16-161.6.34-2
ii  librsvg2-2 2.44.10-1
ii  libselinux12.8-1+b1
ii  libsm6 2:1.2.2-1+b3
ii  libsystemd0240-1
ii  libtiff5   4.0.10-3
ii  libtinfo6  6.1+20181013-1
ii  libx11-6   2:1.6.7-1
ii  libx11-xcb12:1.6.7-1
ii  libxcb11.13.1-2
ii  libxext6   2:1.3.3-1+b2
ii  libxfixes3 1:5.0.3-1
ii  libxft22.3.2-2
ii  libxinerama1   2:1.1.4-1
ii  libxml22.9.4+dfsg1-7+b3
ii  libxpm41:3.5.12-1
ii  libxrandr2 2:1.5.1-1
ii  libxrender11:0.9.10-1
ii  zlib1g 1:1.2.11.dfsg-1

emacs-gtk recommends no packages.

Versions of packages emacs-gtk suggests:
pn  emacs-common-non-dfsg  

-- no debconf information

Bug#917295: [libjs-mocha] Use browserify

[Bastien Roucariès]

Package: libjs-mocha
Version: 4.1.0+ds2-2
Severity: wishlist
control: block -1 by 780357

Use browserify like upstream please

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

Bug#917294: [libjs-mocha] Does not build like upstream

[Bastien Roucariès]

Package: libjs-mocha
Version: 4.1.0+ds2-2
Severity: grave
control: block 887583 by -1

The libjs-mocha is unusable as is due to be build as udd not as a classical 
module.

Will fix ASAP

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

Bug#901438: bash: enable compile-time syslog shopt

[Luca Boccassi]

On Wed, 2018-11-28 at 17:56 +, Luca Boccassi wrote:
> On Wed, 2018-09-19 at 18:01 +0100, Luca Boccassi wrote:
> > On Wed, 13 Jun 2018 11:40:57 +0100 Luca Boccassi 
> > wrote:
> > > Package: bash
> > > Version: 5.0~alpha1-1
> > > Severity: wishlist
> > > Tags: patch
> > >  
> > > Dear Maintainer,
> > >  
> > > bash 5.0 introduced a new build-time config-top.h option to allow
> > 
> > users
> > > to optionally enable sending the bash history to syslog via a new
> > 
> > shopt
> > > variable.
> > > Given it's generally undesirable on user's machines, even if
> > > compiled
> > > in the feature is off by default at runtime. It can be checked
> > > trivially with "shopt -p | grep syslog".
> > >  
> > > But this feature is often necessary and required on mission
> > > critical
> > > equipment due to auditing rules For example in my
> > > case,
> > 
> > to
> > > use vanilla Debian on servers inside a large ISP we need this
> > > option.
> > > Given Debian aims to be a Universal Operating System, it would be
> > > really great if such option were available without having to
> > > rebuild
> > > bash manually. :-)
> > >  
> > > Please consider the inlined diff for the deb-bash-config.diff
> > > patch,
> > > that will build the support but of course will leave it disabled
> > > by
> > > default. I have tested it and it works as expected.
> > >  
> > > Thank you!
> > >  
> > > -- 
> > > Kind regards,
> > > Luca Boccassi
> > >  
> > > --- debian/patches/deb-bash-config.diff
> > > +++ debian/patches/deb-bash-config.diff
> > > @@ -14,6 +14,10 @@
> > >   # DP: 
> > >   # DP: - don't define a default DEFAULT_MAIL_DIRECTORY, because
> > > it
> > >   # DP:   can cause a timeout on NFS mounts.
> > > +# DP: 
> > > +# DP: - build with runtime option to enable sending history to
> > 
> > syslog
> > > +# DP:   and disable it by default. Can be enabled by a user with
> > > +# DP:   shopt -s syslog_history
> > >   
> > >   Index: b/config-bot.h
> > >   ===
> > > ==
> > > ==
> > > @@ -54,3 +58,21 @@
> > >    
> > >    /* Define if you want the case-capitalizing operators (~[~])
> > > and
> > 
> > the
> > >   `capcase' variable attribute (declare -c). */
> > > +@@ -117,7 +117,7 @@
> > > + 
> > > + /* Define if you want each line saved to the history list in
> > 
> > bashhist.c:
> > > +bash_add_history() to be sent to syslog(). */
> > > +-/* #define SYSLOG_HISTORY */
> > > ++#define SYSLOG_HISTORY
> > > + #if defined (SYSLOG_HISTORY)
> > > + #  define SYSLOG_FACILITY LOG_USER
> > > + #  define SYSLOG_LEVEL LOG_INFO
> > > +@@ -128,7 +128,7 @@
> > > +shell option; if defined, the value is the default for the
> > 
> > syslog_history
> > > +shopt option */
> > 
> > Dear Maintainer,
> > 
> > Bash 5.0-beta is out - I've just tested it to make sure this patch
> > still applies and works, and it does.
> > 
> > Would be fantastic if it could be considered for the eventual
> > upload
> > of
> > 5.0-beta.
> > 
> > Thank you!
> 
> Dear Maintainer,
> 
> bash 5.0-beta2 is out, I've tested the above small patch with it and
> I
> can confirm again that it works as expected. It would be great if it
> could be included in the next upload to experimental.
> 
> Thank you!

Dear Maintainer,

Just tested with 5.0-rc1 and it works fine as well. rc1 also fixes the
build failures on armhf/armel BTW.

Thanks and happy holidays!

-- 
Kind regards,
Luca Boccassi

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

Bug#917243: ghostwriter: Please suggest optional export tools: pandoc discount cmark

[Sebastien Chavaux]

Hello,
Oki I take care of it with the upgrade to version 1.7.4.

Sincerely.

Le lun. 24 déc. 2018 17:03, Jonas Smedegaard  a écrit :

> Package: ghostwriter
> Version: 1.7.3-1
> Severity: normal
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
>
> Ghostwriter supports optional alternative exporters, as documented at
> <
> https://github.com/wereturtle/ghostwriter/wiki/How-to-Add-Extra-Export-Formats
> >
>
> Please suggest all such helper tools.
>
> Seems at least the following: pandoc discount cmark
>
>
>  - Jonas
>
> -BEGIN PGP SIGNATURE-
>
> iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAlwhAuMACgkQLHwxRsGg
> ASFk9RAAoxH2AZ3ViyKnl2upaBV5BB1bIl5e454eeMV6OPbtlZTiH4Bnqq3DHxd0
> NtCPXlEh/SDb89YY0yCj9I7D4UJt22WyMG+0Bdzq9Kb5sEWmJXJ5PUapMDmwRhO7
> pKVgP70fPc6+laTGnpXt31rusPy5G+RNsTCbwbWQ8eD2vyv8Ce2DCysou0fb6dIS
> RbXwoqaInt30LhWuEBL9MmseQuZi4lpM2R8+xedvqn4hoCxrEIjTQJxijqe2bcBa
> 7DjxjEvGInrqHsKMir4N0A3TnqJ5X0fLLPzD8IafdA05Q+4Y0nfQ6PCP1c+Sz0fe
> 7pQLz/ZgCfuu/6/kSCEDL0QMS26gTHkJ8X57JncyXjbkGdC4S2JjWAPKHlzo5nme
> sGk9SvoTTaarEJwNmhL6NsK01bXGSd1cJH3jmgj8giqPSiLHYCTOh4qbeOte570/
> I4KDUfrK96EBjKh0HsarhdVylRR6CIYZA7nOzHo0eTHfQXaBzWch6HHzLdszLug/
> HngRqIiJJABFMujipQlQvfniewxLfKmjV+EuTJm+wAFDST4KcioJHrrdnxwLhXj6
> GmWWg8kbYEWUf9TUjUQfACBQfVxyLXYZUGZ7E8l4o5Or1ohU3JdkSVC9iTjWzcW+
> wec1px8VarEebYc+uVW5tDQrl9n96EeWsCA8mZY71nVGJjKANgc=
> =nax3
> -END PGP SIGNATURE-
>

Bug#917293: kinit: The kdeinit5 consumes and takes about 3 ~ 5 minutes to give me control of the environment.

[Santiago José López Borrazás]

Package: kinit
Version: 5.51.0-1
Severity: important

Dear Maintainer,

When I want to enter the KDE, it takes me a lot to finish the session. It 
consumes CPU and it takes, like an average of between 3 and 5 minutes to give 
me session control.

I have tried creating another user and do the same.

This bug has been playing for a week now. And it's pretty weird What I 
consider, that is a BUG, for that reason, and it is of great importance.

With htop I checked what it consumes, with this command when starting the 
graphical environment:

kdeinit5 --oom-pipe 4 --kded +kcminit_startup

I thought there was a package missing, but no. I do not miss any package in 
important dependencies.

This has never happened to me. In my life.

Thank you very much for your help.

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

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

Versions of packages kinit depends on:
ii  kio  5.51.0-1
ii  libc62.28-3
ii  libcap2  1:2.25-1.2
ii  libcap2-bin  1:2.25-1.2
ii  libkf5configcore55.51.0-1
ii  libkf5coreaddons55.51.0-1
ii  libkf5crash5 5.51.0-1
ii  libkf5i18n5  5.51.0-1
ii  libkf5kiocore5   5.51.0-1
ii  libkf5kiowidgets55.51.0-1
ii  libkf5service-bin5.51.0-1
ii  libkf5service5   5.51.0-1
ii  libkf5windowsystem5  5.51.0-1
ii  libqt5core5a 5.11.2+dfsg-7
ii  libqt5dbus5  5.11.2+dfsg-7
ii  libqt5gui5   5.11.2+dfsg-7
ii  libstdc++6   8.2.0-13
ii  libx11-6 2:1.6.7-1
ii  libxcb1  1.13.1-2

kinit recommends no packages.

kinit suggests no packages.

-- no debconf information

Bug#915419: debdiff for 915692, 915419

[Luca Boccassi]

On Tue, 2018-12-25 at 11:41 +0100, Luca Boccassi wrote:
> On Sat, 2018-12-22 at 22:34 +0100, Luca Boccassi wrote:
> > Control: tags -1 pending
> > 
> > On Wed, 19 Dec 2018 16:39:17 +0100 Luca Boccassi 
> > wrote:
> > > Dear Maintainer,
> > >  
> > > In order to allow the DPDK 17.11 -> 18.11 transition to happen
> > > [1],
> > > I
> > > intend to upload a source NMU fixing 915692 and 915419 (debdiff
> > > attached) either at the end of this week or at the beginning of
> > > the
> > > next to DELAYED/1.
> > >  
> > > I hope this does not cause any troubles, and please let me know
> > > if
> > 
> > this
> > > would be an issue, and/or if you prefer an alternative solution.
> > >  
> > > Thank you!
> > >  
> > > -- 
> > > Kind regards,
> > > Luca Boccassi
> > >  
> > > [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=916351
> > 
> > Dear Maintainers,
> > 
> > I have uploaded the aforementioned NMU to DELAYED/2 to allow for
> > the
> > DPDK transition to start on Monday. Please let me know if this is
> > an
> > issue and would like me to cancel it.
> > 
> > Thanks!
> 
> Hi,
> 
> Unfortunately a new version of mariadb was uploaded to unstable after
> my last build test but before the upload got through DELAYED, so the
> package does not build in unstable :-(
> 
> I have reported the issue with more details on the appropriate
> mariadb
> bug [1]. I do not believe there is any action that should be taken on
> collectd at the moment.

The above issue has been fixed in unstable, so I've uploaded another
NMU to fix 917202 to DELAYED/1.

-- 
Kind regards,
Luca Boccassi

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

Bug#917202: lm-sensors: Ability to install both libsensors4 and libsensors5?

[Luca Boccassi]

On Tue, 2018-12-25 at 12:14 +0100, Luca Boccassi wrote:
> On Mon, 24 Dec 2018 01:33:08 +0100 Aurelien Jarno  et
> > wrote:
> > control: reassign -1 collectd
> > control: retitle -1 collectd should be updated for libsensors5
> > control: severity -1 serious
> >  
> > On 2018-12-24 01:11, Xavier Guerrin wrote:
> > > Package: lm-sensors
> > > Version: 1:3.5.0-3
> > > Severity: normal
> > >  
> > > Dear Maintainer,
> > >  
> > > It does not seem possible to install both libsensors4 and
> 
> libsensors5 as
> > > "apt install libsensors5" will remove libsensors4. This is
> 
> apparently due to
> > > libsensors-config, which is marked as breaking and replacing
> 
> libsensors4.
> >  
> > True.
> >  
> > > Alas, this package does not effectively replace libsensors4 since
> 
> it no longer
> > > provides libsensors.so.4. This has the side-effect of breaking
> 
> collectd's
> > > "sensors" plugin, which relies on libsensors.so.4:
> > >    $ dpkg -L collectd-core | grep sensors
> > >    /usr/lib/collectd/sensors.so
> > >    $ ldd /usr/lib/collectd/sensors.so
> > >    linux-vdso.so.1 (0x7ffe949f2000)
> > >    libsensors.so.4 => not found
> > >    libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6
> 
> (0x7fc8b4c44000)
> > >    /lib64/ld-linux-x86-64.so.2 (0x7fc8b4e21000)
> > 
> >  
> > This is clearly a bug of collectd which should be updated to use
> > libsensors5. I am therefore reassigning the bug to this package.
> 
> Dear Maintainer,
> 
> collectd 5.8 fails to build with libsensors5 due to unnecessary
> checks
> that have been removed in the upstream 5.8 branch [1].
> Backporting that single patch fixes the build.
> 
> Given this will block the DPDK transition I'm looking after [2],
> unless
> it's an issue I'll do a source NMU to DELAYED/1 once the other bug
> affecting collectd from mariadb [3] is fixed. Let me know if this is
> an
> issue. The debdiff is attached.
> 
> Thank you!

Dear Maintainers,

The issue with mysql/mariad has been fixed in unstable so I've uploaded
the mentioned NMU to DELAYED/1. Please let me know if this is an issue
and would like it cancelled.

Thank you!

-- 
Kind regards,
Luca Boccassi

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

Bug#917075: [debian-mysql] Bug#917075: mariadb-10.3: libmariadb3 causes removal of default-libmysqlclient-dev

[Luca Boccassi]

On Tue, 25 Dec 2018 12:38:34 +0100 Luca Boccassi 
wrote:
> On Tue, 25 Dec 2018 12:51:40 +0200 =?UTF-
8?B?T3R0byBLZWvDpGzDpGluZW4=?= 
>  wrote:
> > I did this change yesterday but have not uploaded yet as I'd like
to
> first
> > write an automated gitlab-ci.yml test in mariadb-10.3 to detect the
> problem
> > first.
> > 
> > https://salsa.debian.org/mariadb-team/mysql/commit/41b7e55f1c5a3cb9
3d
> a2e2407230542cc9284222
> 
> Hi,
> 
> Thanks for the update. Do you happen to have a rough ETA? Rebuilding
> collectd is required for the DPDK transition [1] that I'm looking
after
> to progress.
> 
> Thank you!
> 
> -- 
> Kind regards,
> Luca Boccassi
> 
> [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=916351

Never mind, the last update of default-libmysqlclient-dev fixed the
issue, sorry for the noise.

-- 
Kind regards,
Luca Boccassi

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

Bug#917278: bitlbee-plugin-mastodon: Not installable with bitlbee-libpurple

[Antoine Beaupré]

Control: reassign -1 bitlbee-libpurple

bitlbee-libpurple has a versionned dependency against a bitlbee release
that is not in Debian unstable.

anarcat@curie:~(master)$ apt show bitlbee-libpurple | grep Depends
[...]
Depends: libc6 (>= 2.14), libgcrypt20 (>= 1.7.0), libglib2.0-0 (>= 2.24.0), 
libgnutls30 (>= 3.5.6), libpurple0 (>= 2.6.0), debianutils (>= 1.16), 
bitlbee-common (= 3.5.1-1)
anarcat@curie:~(master)$ rmadison bitlbee | grep unstable
bitlbee| 3.4.2-1| unstable| source, 
kfreebsd-amd64, kfreebsd-i386
[...]

Therefore the bug is not, as far as I understand this, in
bitlbee-mastodon, so reassigning.

A.

On 2018-12-25 15:21:57, Mykola Nikishov wrote:
> Package: bitlbee-plugin-mastodon
> Severity: normal
>
> $ sudo apt install bitlbee-plugin-mastodon bitlbee-libpurple
> The following packages have unmet dependencies:
>  bitlbee-libpurple : Depends: libpurple0 (>= 2.6.0) but it is not going 
> to be installed
>   bitlbee-plugin-mastodon : Depends: bitlbee but it is not going to be 
> installed
>   E: Unable to correct problems, you have held broken packages.
>
> -- System Information:
> Debian Release: buster/sid
>   APT prefers stable
>   APT policy: (900, 'stable'), (190, 'testing'), (180, 'unstable'), (170, 
> 'experimental')
> Architecture: amd64 (x86_64)
>
> Kernel: Linux 4.18.0-3-amd64 (SMP w/4 CPU cores)
> Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
> LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
>
> Versions of packages bitlbee-plugin-mastodon depends on:
> pn  bitlbee   
> ii  libc6 2.28-2
> ii  libglib2.0-0  2.58.1-6
>
> bitlbee-plugin-mastodon recommends no packages.
>
> bitlbee-plugin-mastodon suggests no packages.

-- 
Secrecy is the keystone to all tyranny. Not force, but secrecy and
censorship.
   -  Robert A. Heinlein

Bug#917292: ffmpeg: linking with libcrystalhd3 seem of no use at all

[Jonas Smedegaard]

Package: ffmpeg
Version: 7:4.1-1
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

ffmpeg currently links with libcrystalhd3.

It seems, however, that libcrystalhd3 is only really useful together
with firmware-crystalhd, which was never really usable in Debian,
leading to that package being dropped: https://bugs.debian.org/865978

If someone wants to revive CrystalHD in Debian, it seems a good place to
start is https://www.mythtv.org/wiki/Broadcom_Crystal_HD#Feb._2014_Update

I suggest to simply stop link with libcrystalhd3 until firmware-crystalhd
reappear in Debian.

 - Jonas

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAlwiZxoACgkQLHwxRsGg
ASFQrw//Wd0qLAUdH0nd8fx+PNVu5LtkXz5rBPjO2KaLHpaTQjQfVhgAbjaIaGrs
AgH7GBqg28gEkhyj85kDrXUAgg2BKMlWhTePUhi2QVxcXSjMUciL8susz5dO75Ye
Q+HJ0kFZ4V8O0fohGYUdukktKf+aES/mChO4U/GXJQfyE9c49HzCLgm7FHg7SN2D
mpG84rj+0pX9HEBCLjYGAtUChqd8ugyHD8PfRaIkH4i1+M1W4Zyt+oeicg1D1D4R
h1LAMRI7+GXtTv64OZ3/rnwe2YYPSALbK3mqB1aTD6wiYjw0aEL7hw05wQidupQ+
NV2XtRnsQ0UqZaSijyzxl708Yy8sxPGi97HxnnbgZjdhOQins/Tcvh/2/qwFenXE
3TykXcYMQ3YZx1v5Jq1wILG8OKnRyKPxpDtxN9ogXPLgVLn4JnAygEVthdzOw/93
1ewbJT3M3xcfXDGBQU2mJMZ4bRzz7M6tui1Q+L19zkm4P/4OcqDuRuVLV9/wmfCj
SWpGmDVSIiXRUH+qUGOtSGkno5OouFDTsirB2Zw+2QQTPboEcK3PXXhpWs19S+Ah
WdJpK0/F+9QdlGfy03iBAQ5ICbuoCcHO9YUBtaGkwWXhLGuaz58GtxQm/szLdzMH
1+lYuFUvcFm7FhlZfQxTN+Za/80pNuODzxB1uToLJrFeAk0MdoY=
=M67y
-END PGP SIGNATURE-

Bug#917291: libharfbuzz0b: wrong glyph for chinese word 小 (U+5C0F)

[Tommy Wu]

Package: libharfbuzz0b
Version: 2.3.0-1
Severity: normal

Dear Maintainer,

U+5C0F (小) is not render correctly after version 2.0.0.
It work fine for version under 1.9.0.

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

Kernel: Linux 4.18.0-3-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=zh_TW.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: systemd (via /run/systemd/system)

Versions of packages libharfbuzz0b depends on:
ii  libc6   2.28-2
ii  libfreetype62.9.1-3
ii  libglib2.0-02.58.1-2
ii  libgraphite2-3  1.3.12-1

libharfbuzz0b recommends no packages.

libharfbuzz0b suggests no packages.

-- no debconf information

Bug#907632: [ppc64-el] Breaks building aspectc++

[Steve Langasek]

Package: aspectc++
Version: 1:2.2+git20170823-7
Followup-For: Bug #907632
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu disco ubuntu-patch

Hello,

Based on the bug history, I don't think this is a bug in gcc-8 but in
aspectc++ (or in llvm), so I have reassigned.

I have also refined the patch provided by Frédéric, to avoid repetition in
the code; please find it attached.

I have uploaded this patch to Ubuntu, where I confirm it fixes the build
failure on ppc64el.

Cheers,
-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developer   https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org
diff -Nru aspectc++-2.2+git20170823/debian/control 
aspectc++-2.2+git20170823/debian/control
--- aspectc++-2.2+git20170823/debian/control2018-08-24 23:29:52.0 
-0500
+++ aspectc++-2.2+git20170823/debian/control2018-12-25 10:15:09.0 
-0600
@@ -1,8 +1,7 @@
 Source: aspectc++
 Section: devel
 Priority: optional
-Maintainer: Ubuntu Developers 
-XSBC-Original-Maintainer: Reinhard Tartler 
+Maintainer: Reinhard Tartler 
 Build-Depends: debhelper (>= 9), libxml2-dev, docbook-to-man, zlib1g-dev, 
libedit-dev, llvm-4.0-dev, libclang-4.0-dev
 Build-Depends-Indep: doxygen, graphviz, gsfonts
 Standards-Version: 4.0.0
diff -Nru aspectc++-2.2+git20170823/debian/patches/ppc64el-no-float128.patch 
aspectc++-2.2+git20170823/debian/patches/ppc64el-no-float128.patch
--- aspectc++-2.2+git20170823/debian/patches/ppc64el-no-float128.patch  
1969-12-31 18:00:00.0 -0600
+++ aspectc++-2.2+git20170823/debian/patches/ppc64el-no-float128.patch  
2018-12-25 10:15:01.0 -0600
@@ -0,0 +1,23 @@
+Description: adjust ppc64el compiler options for compatibility with gcc-8
+ gcc-8 now uses -mfloat128 by default on ppc64el, which results in
+ incompatible type definitions being passed in to llvm.  Override this by
+ explicitly passing -mno-float128 on ppc64el.
+Author: Frédéric Bonnard 
+Bug-Debian: https://bugs.debian.org/907632
+Last-Modified: 2018-12-25
+
+Index: aspectc++-2.2+git20170823/Ag++/PumaConfigFile.cc
+===
+--- aspectc++-2.2+git20170823.orig/Ag++/PumaConfigFile.cc
 aspectc++-2.2+git20170823/Ag++/PumaConfigFile.cc
+@@ -118,7 +118,10 @@
+ config_command_str = "\"" + _config.cc_bin() + "\" "
+ + _config.optvec().getString(
+ (OptionItem::OPT_GCC | OptionItem::OPT_CONFIG))
++#ifdef __powerpc__ && __powerpc64__ && __LITTLE_ENDIAN__
+++ " -mno-float128 "
++#endif
+ + " -E -dM -v -x c++ \"" + empty_file_name + "\"";
+   }
+ 
+   // get c compiler output
diff -Nru aspectc++-2.2+git20170823/debian/patches/series 
aspectc++-2.2+git20170823/debian/patches/series
--- aspectc++-2.2+git20170823/debian/patches/series 2018-06-25 
09:59:10.0 -0500
+++ aspectc++-2.2+git20170823/debian/patches/series 2018-12-25 
10:12:04.0 -0600
@@ -1,2 +1,3 @@
 0001-lexertl-Fix-FTBFS-with-gcc-8.patch
 auto-gitignore
+ppc64el-no-float128.patch

Bug#917289: transition: ntfs-3g

[GCS]

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

Hi RMs,

Small transition of ntfs-3g from 2017.3.23 to 2017.3.23AR.3 and
involves the following packages: partclone, testdisk and wimlib.
All three build fine with this ntfs-3g version as well.

Thanks,
Laszlo/GCS

Bug#917288: tidy reports "not a file" for existing file

[Thomas Dickey]

Package: tidy
Version: 2:5.6.0-9
Severity: important

Dear Maintainer,

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

I use a script that calls "tidy" for cleanup of format.
That does something like

tidy -ascii -i foo.html

The latest version says

Document: "foo.html" is not a file!

which is unexpected behavior.   This works:

tidy -ascii -i < foo.html

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


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

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

Versions of packages tidy depends on:
ii  libc6 2.28-2
ii  libtidy5deb1  2:5.6.0-9

tidy recommends no packages.

tidy suggests no packages.

-- no debconf information

-- 
Thomas E. Dickey 
https://invisible-island.net
ftp://ftp.invisible-island.net


signature.asc
Description: Digital signature

Bug#913864: kicad: Backtraces on opening cvpcb

[Carsten Schoenert]

Control: tags -1 wontfix

Hello Julien, happy Xmas!

Am 22.12.18 um 07:58 schrieb Julien Goodwin:
> On 15/12/18 5:34 pm, Carsten Schoenert wrote:
>> I tried to reproduce this issue on several machines in preparation for
>> 5.0.2. But I'm unable to get catched by your reported issue on any of my
>> machines. Even if I forced the install the packages python-wxgtk3.0 and
>> libwxgtk3.0-gtk3-0v5!
> 
> For me forcing python-wxgtk3.0_3.0.2.0+dfsg-4 is the way I make things work.

Reading your answer completely it's quite obvious why.

...
>> Are you really sure you are using a binary from the Debian archive? Can
> Yes.
> 
> I just upgraded to 5.0.2+dfsg1-1 last night, and before that played around.
> 
> Having a python plugin (in .kicad/scripting/plugins, and specifically
> InteractiveHtmlBom[1]) seems to be what triggers this.

I've looked into the symbol table while KiCad is running and there are
no GTK+3 related symbols loaded. So the clashing mus come from elsewhere.

Starting KiCad, open EEschema with some ordinary schematic and open
Cvpcb ...

> $ grep libwx /proc/$(pidof kicad)/maps
> 7fea4d7d7000-7fea4d802000 r--p  103:01 1057723   
> /usr/lib/x86_64-linux-gnu/libwx_gtk2u_stc-3.0.so.0.4.0
> 7fea4d802000-7fea4d9e1000 r-xp 0002b000 103:01 1057723   
> /usr/lib/x86_64-linux-gnu/libwx_gtk2u_stc-3.0.so.0.4.0
> 7fea4d9e1000-7fea4da17000 r--p 0020a000 103:01 1057723   
> /usr/lib/x86_64-linux-gnu/libwx_gtk2u_stc-3.0.so.0.4.0
> 7fea4da17000-7fea4da1e000 r--p 0023f000 103:01 1057723   
> /usr/lib/x86_64-linux-gnu/libwx_gtk2u_stc-3.0.so.0.4.0
> 7fea4da1e000-7fea4da1f000 rw-p 00246000 103:01 1057723   
> /usr/lib/x86_64-linux-gnu/libwx_gtk2u_stc-3.0.so.0.4.0
> 7fea4da22000-7fea4da26000 r--p  103:01 1056297   
> /usr/lib/x86_64-linux-gnu/libwx_baseu_xml-3.0.so.0.4.0
> 7fea4da26000-7fea4da2e000 r-xp 4000 103:01 1056297   
> /usr/lib/x86_64-linux-gnu/libwx_baseu_xml-3.0.so.0.4.0
> 7fea4da2e000-7fea4da31000 r--p c000 103:01 1056297   
> /usr/lib/x86_64-linux-gnu/libwx_baseu_xml-3.0.so.0.4.0
> 7fea4da31000-7fea4da32000 ---p f000 103:01 1056297   
> /usr/lib/x86_64-linux-gnu/libwx_baseu_xml-3.0.so.0.4.0
> 7fea4da32000-7fea4da33000 r--p f000 103:01 1056297   
> /usr/lib/x86_64-linux-gnu/libwx_baseu_xml-3.0.so.0.4.0
> 7fea4da33000-7fea4da34000 rw-p 0001 103:01 1056297   
> /usr/lib/x86_64-linux-gnu/libwx_baseu_xml-3.0.so.0.4.0
> 7fea4da34000-7fea4da96000 r--p  103:01 1052315   
> /usr/lib/x86_64-linux-gnu/libwx_baseu-3.0.so.0.4.0
> 7fea4da96000-7fea4dc38000 r-xp 00062000 103:01 1052315   
> /usr/lib/x86_64-linux-gnu/libwx_baseu-3.0.so.0.4.0
> 7fea4dc38000-7fea4dcc3000 r--p 00204000 103:01 1052315   
> /usr/lib/x86_64-linux-gnu/libwx_baseu-3.0.so.0.4.0
> 7fea4dcc3000-7fea4dcc4000 ---p 0028f000 103:01 1052315   
> /usr/lib/x86_64-linux-gnu/libwx_baseu-3.0.so.0.4.0
> 7fea4dcc4000-7fea4dccf000 r--p 0028f000 103:01 1052315   
> /usr/lib/x86_64-linux-gnu/libwx_baseu-3.0.so.0.4.0
> 7fea4dccf000-7fea4dcd3000 rw-p 0029a000 103:01 1052315   
> /usr/lib/x86_64-linux-gnu/libwx_baseu-3.0.so.0.4.0
> 7fea4dce-7fea4dcf1000 r--p  103:01 1054165   
> /usr/lib/x86_64-linux-gnu/libwx_baseu_net-3.0.so.0.4.0
> 7fea4dcf1000-7fea4dd18000 r-xp 00011000 103:01 1054165   
> /usr/lib/x86_64-linux-gnu/libwx_baseu_net-3.0.so.0.4.0
> 7fea4dd18000-7fea4dd25000 r--p 00038000 103:01 1054165   
> /usr/lib/x86_64-linux-gnu/libwx_baseu_net-3.0.so.0.4.0
> 7fea4dd25000-7fea4dd26000 ---p 00045000 103:01 1054165   
> /usr/lib/x86_64-linux-gnu/libwx_baseu_net-3.0.so.0.4.0
> 7fea4dd26000-7fea4dd28000 r--p 00045000 103:01 1054165   
> /usr/lib/x86_64-linux-gnu/libwx_baseu_net-3.0.so.0.4.0
> 7fea4dd28000-7fea4dd29000 rw-p 00047000 103:01 1054165   
> /usr/lib/x86_64-linux-gnu/libwx_baseu_net-3.0.so.0.4.0
> 7fea4dd2a000-7fea4df3d000 r--p  103:01 1057066   
> /usr/lib/x86_64-linux-gnu/libwx_gtk2u_core-3.0.so.0.4.0
> 7fea4df3d000-7fea4e20e000 r-xp 00213000 103:01 1057066   
> /usr/lib/x86_64-linux-gnu/libwx_gtk2u_core-3.0.so.0.4.0
> 7fea4e20e000-7fea4e30f000 r--p 004e4000 103:01 1057066   
> /usr/lib/x86_64-linux-gnu/libwx_gtk2u_core-3.0.so.0.4.0
> 7fea4e30f000-7fea4e381000 r--p 005e4000 103:01 1057066   
> /usr/lib/x86_64-linux-gnu/libwx_gtk2u_core-3.0.so.0.4.0
> 7fea4e381000-7fea4e389000 rw-p 00656000 103:01 1057066   
> /usr/lib/x86_64-linux-gnu/libwx_gtk2u_core-3.0.so.0.4.0
> 7fea4e395000-7fea4e3d5000 r--p  103:01 1057407   
> /usr/lib/x86_64-linux-gnu/libwx_gtk2u_html-3.0.so.0.4.0
> 7fea4e3d5000-7fea4e43e000 r-xp 0004 103:01 1057407   

Bug#917287: failure to install x32 port from iso netboot image: gpgv unknown digest algorithm

[Shawn Rutledge]

Package: gpgv
Version: 1.4.18

I’m trying to run the installer from http://debian-x32.org/d-i/netboot.iso .  
The mirror is set by default to ftp.debian-x32.org, directory /debian/.   It 
says “downloading a file failed”.  I hit alt-F4 to get to the error console to 
investigate, and the last few lines are (omitting timestamps)

choose-mirror: DEBUG: command: wget -q 
http://ftp.debian-x32.org/debian//dists/jessie/main/binary-x32/Release -O - | 
grep ^Architecture:
anna: WARNING **: bad d-i Packages file
net-retriever: gpgv: md_enable: algorithm 10 not available
net-retriever: gpgv: Signature made Sat Aug 25 17:05:17 2018 UTC using RSA key 
ID BED007F9
net-retriever: gpgv: Can’t check signature: unknown digest algorithm
net-retriever: error: Bad signature on /tmp/net-retriever-2779-Release

So maybe the signatures are done with a newer digest algorithm and therefore 
gpgv on the ISO image needs to be updated?

Bug#917286: [src:chai] Use browserify

[Bastien Roucariès]

Package: src:chai
Version: 4.2.0+ds-1
Severity: wishlist
control: block -1 by 780357

We should use browserify instead of webpack like upstream

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

Bug#917285: [chai] Please split libjs-chai

[Bastien Roucariès]

Package: chai
Version: 4.2.0+ds-1
Severity: important

A remainder to split package to libjs-chai and follow policy

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

Bug#917283: llvm-toolchain-6.0: external function __aeabi_unwind_cpp_pr0 missing [armhf]

[Daniel Stender]

Package: llvm-toolchain-6.0
Version: 1:6.0.1-9.2
Severity: important
Control: block 917252 by -1

Hi,

LLVMlite 0.26.0-1 [1] has a test failure with LLVM 6.0 on armhf [2]:


test_global_ctors_dtors (llvmlite.tests.test_binding.TestGlobalConstructors) 
... LLVM ERROR: Program used external function '__aeabi_unwind_cpp_pr0' which 
could not be resolved!
E: pybuild pybuild:338: test: plugin distutils failed with: exit code=1: cd 
/<>/.pybuild/cpython2_2.7_llvmlite/build; python2.7 -m unittest 
discover -v


Unfortunately the upstream code isn't ready for LLVM 7 yet [3].

Best,
Daniel Stender

[1] https://tracker.debian.org/pkg/llvmlite

[2] 
https://buildd.debian.org/status/fetch.php?pkg=llvmlite=armhf=0.26.0-1=1543651733=0

[3] https://bugs.debian.org/912790 llvmlite: Please switch to llvm-toolchain-7

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

Kernel: Linux 4.9.0-8-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)

Bug#917284: opendmarc: [INTL:de] Initial German debconf translation

[Chris Leick]

Package: opendmarc
Version: 1.3.2-5
Severity: wishlist
Tags: l10n patch



Hi,

please find attached the initial German debconf translation.

Kind regards,
Chris


de.po.gz
Description: application/gzip

Bug#917282: ITP: lz4json -- unpack lz4json files, usually generated by Mozilla programs

[Adam Borowski]

Package: wnpp
Severity: wishlist
Owner: Adam Borowski 

* Package name: lz4json
  Version : ?
  Upstream Author : Andi Kleen
* URL : https://github.com/andikleen/lz4json
* License : BSD-2 ish
  Programming Lang: C
  Description : unpack lz4json files, usually generated by Mozilla programs
 Instead of a standard .json.lz4, Firefox uses its own format to compress
 its bookmarks and session restore files.  This tool lets you read them,
 converting to json.  Going from json to a human-readable format is then
 up to you.

Bug#917196: transition: qtbase-opensource-src

[Lisandro Damián Nicanor Pérez Meyer]

We are ready to go.


-- 
¿Qué vamos a hacer esta noche Cerebro?
-Lo mismo que todas las noches Pinky...
¡¡¡tratar de conquistar el mundo!!!
  Pinky y Cerebro. Narf.

Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/


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

Bug#917270: texlive-latex-extra-doc: Please add dtx files for dtxgallery

[Norbert Preining]

Hi Karl,

On Tue, 25 Dec 2018, Braun Gábor wrote:
> Open the dtxgallery document with 'texdoc dtxgallery'.
> A PDF file opens, and on the very first page prominently lists four example 
> dtx files
> without any information how to open them:
> 
> single-source.dtx
> conditional-code.dtx
> rearrange.dtx
> dtxgallery.dtx
> 
> Note that on the top of the second page, the document explicitly recommends
> examining these dtx files directly, but the lack of any information where 
> these are make it
> very hard.  They don't seem to be included in the package, at least not in an 
> obvious location:

These files are in the source files part of dtxgallery:
**
name dtxgallery
category Package
revision 15878
shortdesc A small collection of minimal DTX examples
longdesc A collection of files that demonstrate simple things that are
longdesc possible with the flexible and under-appreciated docstrip file
longdesc format. Each file of the collection is provided as a .dtx file
longdesc and as the corresponding .pdf. The set is intended as a
longdesc companion to Scott Pakin's excellent and influential dtxtut
longdesc example of producing LaTeX packages in this way.
containersize 584
containerchecksum 
2c73069596d5c99c6f9f9ea9f9e65f5f731854068d1b56a6317e5966a023ad057c81d8c62ef38fc3af962b7307cbff45dbcd3867fdb4caf7bcd3a2c83a722674
doccontainersize 349372
doccontainerchecksum 
31e82752179fb78fd8db1871eee1b3c254e78f4254540c43d63a4243f59a0ec5efcfef6211c0d9012e2dc336164ad65e1ec38d9a1f0274208600b188ff86bdfa
docfiles size=95
 texmf-dist/doc/latex/dtxgallery/README details="Readme"
 texmf-dist/doc/latex/dtxgallery/conditional-code.pdf
 texmf-dist/doc/latex/dtxgallery/dtxgallery.pdf
 texmf-dist/doc/latex/dtxgallery/rearrange.pdf
 texmf-dist/doc/latex/dtxgallery/single-source.pdf
srccontainersize 3972
srccontainerchecksum 
60b1bd74afa60c36d7ebd522157a594cb62298c3638b28d589a84f8df08e37dfc923c063663b9a7202481bf8d80970d873b2cb055c8fbcaba71d55c109e8a89d
srcfiles size=5
 texmf-dist/source/latex/dtxgallery/conditional-code.dtx
 texmf-dist/source/latex/dtxgallery/dtxgallery.dtx
 texmf-dist/source/latex/dtxgallery/rearrange.dtx
 texmf-dist/source/latex/dtxgallery/single-source.dtx
**

I think in this particular case it would be better to move them to the
docfiles?

WDYT?

Norbert

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

Bug#917267: glx-diversions cannot be uninstalled

[Norbert Preining]

Hi Andreas,

> You shouldn't have /usr/lib/i386-linux-gnu/libGL.so.1 at this point ...
> Where does it come from? Did you try to "fix" some things manually?

No, I just de-selected all the relevant packages in aptitude, and then
pressed g ;-)

> Is it a file or symlink?
> ls -la, md5sum, timestamp, link target?

Sorry, since I need to use this computer I ended up doing
dpkg --force-depends --purge libgl1:amd64 libgl1:i386
dpkg --purge glx-diversions
apt install libgl1:amd64 libgl1:i386

> Any ideas how you got into this configuration? Didn't encounter
> something like this in my tests.

It is a bit special configuration: It is a laptop with Intel GPU, which
is synced to my main computer having an nvidia gpu. I install TensorFlow
with GPU support on the nvidia/main machine. I sync the stuff in
/usr/local with unison. 

I want to be able to run tensorflow on my laptop, too, but with the
installation from the nvidia machine it does not work due to missing
libraries. So installed the missing libraries from nvidia, but use the
intel driver.

Now, on the main desktop I can run tensorflow with GPU support, and on
the laptop I run the same, but due to missing nvidia card it falls back
to using CPU only.

I admit this is a special setup, but apt allowed me to install the
nvidia libraries in parallel to the intel driver and mesa gl stuff.

I tried to revert the whole bunch due to strange problems on my desktop
(Cinnamon) which does not properly show notifications, some programs
don't start with very strange exception related to X. So I thought that
the nvidia libs might be a problem and reverted ...

Happy and peaceful holidays, and a great start into the new year!

Norbert

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