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#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#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#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#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#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#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#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#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#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#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#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#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#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 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#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#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#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#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#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#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#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#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#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#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#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#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#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#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#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#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#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#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#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#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#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#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#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#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#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#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#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#917266: default-libmysqlclient-dev: Uninstallable - depends on no longer built libmariadbclient-dev-compat

[Scott Kitterman]

Package: default-libmysqlclient-dev
Version: 1.0.4
Severity: grave
Justification: renders package unusable

 no longer found.

Since mariadb10.3 became the default this no longer works:

#include 

It has to be changed to:

#include 

You can experience this for yourself by rebuilding postfix, seeing it fail:

gcc -fPIC -I. -I../../include -DDEBIAN -DHAS_PCRE -DHAS_LDAP -DUSE_LDAP_SASL 
-DHAS_SQLITE -DMYORIGIN_FROM_FILE -DHAS_CDB -DHAS_LMDB -DHAS_MYSQL 
-I/usr/include/mysql -DHAS_PGSQL -I/usr/include/postgresql -DHAS_SQLITE 
-I/usr/include -DHAS_SSL -I/usr/include/openssl -DUSE_SASL_AUTH 
-I/usr/include/sasl -DUSE_CYRUS_SASL -DUSE_TLS -I/usr/include -DHAS_DEV_URANDOM 
-DDEF_DAEMON_DIR=\"/usr/lib/postfix/sbin\" 
-DDEF_HTML_DIR=\"/usr/share/doc/postfix/html\" 
-DDEF_MANPAGE_DIR=\"/usr/share/man\" 
-DDEF_README_DIR=\"/usr/share/doc/postfix\" -DUSE_DYNAMIC_LIBS 
-DUSE_DYNAMIC_MAPS -Wmissing-prototypes -Wformat -Wno-comment -fPIC -g -O2 -I. 
-I../../include -DLINUX3 -c dict_ldap.c
gcc -shared -Wl,--enable-new-dtags -Wl,-rpath,/usr/lib/postfix -o 
postfix-ldap.so dict_ldap.o -lldap -llber -L../../lib -L. -lpostfix-util 
-lpostfix-global
gcc -fPIC -I. -I../../include -DDEBIAN -DHAS_PCRE -DHAS_LDAP -DUSE_LDAP_SASL 
-DHAS_SQLITE -DMYORIGIN_FROM_FILE -DHAS_CDB -DHAS_LMDB -DHAS_MYSQL 
-I/usr/include/mysql -DHAS_PGSQL -I/usr/include/postgresql -DHAS_SQLITE 
-I/usr/include -DHAS_SSL -I/usr/include/openssl -DUSE_SASL_AUTH 
-I/usr/include/sasl -DUSE_CYRUS_SASL -DUSE_TLS -I/usr/include -DHAS_DEV_URANDOM 
-DDEF_DAEMON_DIR=\"/usr/lib/postfix/sbin\" 
-DDEF_HTML_DIR=\"/usr/share/doc/postfix/html\" 
-DDEF_MANPAGE_DIR=\"/usr/share/man\" 
-DDEF_README_DIR=\"/usr/share/doc/postfix\" -DUSE_DYNAMIC_LIBS 
-DUSE_DYNAMIC_MAPS -Wmissing-prototypes -Wformat -Wno-comment -fPIC -g -O2 -I. 
-I../../include -DLINUX3 -c dict_mysql.c
dict_mysql.c:171:10: fatal error: mysql.h: No such file or directory
 #include 
  ^
compilation terminated.

And then changing src/global/dict_mysql.c line 171

Alternately, I could update the include path, I guess, but isn't approximately
the whol point of providing a generic default so that every package in
Debian doesn't have to change when the default changes?

Scott K

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

[Otto Kekäläinen]

Hello!

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)?

Bug#917268: supertux: new upstream 0.6.0

[Jonatan Nyberg]

package: supertux
severity: normal

Please consider to upgrade to the current upstream version
(0.6.0).

Regards,
Jonatan

Bug#917267: glx-diversions cannot be uninstalled

[Norbert Preining]

Package: glx-diversions
Version: 0.9.0
Severity: serious
Justification: maintainer scripts should not error

Hi all

I recently purged all kind of nvidia* packages from my computer, and now
none of them is actually there, but I still cannot uninstall
glx-diversions:
$ aptitute 
...
Performing actions...
(Reading database ... 961080 files and directories currently installed.)
Removing glx-diversions (0.9.0) ...
dpkg-divert: error: rename involves overwriting 
'/usr/lib/i386-linux-gnu/libGL.so.1' with
  different file '/usr/lib/mesa-diverted/i386-linux-gnu/libGL.so.1', not allowed
dpkg: error processing package glx-diversions (--remove):
 installed glx-diversions package post-removal script subprocess returned error 
exit status 2
Removing glx-alternative-mesa (0.9.0) ...
Errors were encountered while processing:
 glx-diversions
E: Sub-process /usr/bin/dpkg returned an error code (1)
..

Same with dpkg --purge ...

Best

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

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

Versions of packages glx-diversions depends on:
ii  dpkg  1.19.2
pn  glx-alternative-mesa  
ii  nvidia-installer-cleanup  20151021+8

glx-diversions recommends no packages.

glx-diversions suggests no packages.

-- no debconf information

Bug#917266: Acknowledgement (default-libmysqlclient-dev: Uninstallable - depends on no longer built libmariadbclient-dev-compat)

[Scott Kitterman]

I quick look at codesearch.d.o suggests this will break 4 - 5 dozen packages.  

Scott K

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

[Sebastiaan Couwenberg]

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


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?

default-libmysqlclient-dev depends on libmariadbclient-dev-compat which
is built from the mariadb-10.1 source package.

libmariadbclient-dev-compat depends on libmariadbclient-dev (also built
from the mariadb-10.1 source package), which in turn depends on
libmariadbclient18 (= 1:10.1.37-3).

As long as the 10.3 packages Conflict or Break 10.1 packages, the
default-* packages cannot be installed along with the 10.3 packages, as
the default packages are depending on the 10.1 packages.

Kind Regards,

Bas

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

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

[Braun Gábor]

Package: texlive-latex-extra-doc
Version: 2018.20181214-1
Severity: normal

Dear Maintainer,

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:

$ dpkg -L texlive-latex-extra-doc | grep dtxgallery
/usr/share/doc/texlive-doc/latex/dtxgallery
/usr/share/doc/texlive-doc/latex/dtxgallery/README
/usr/share/doc/texlive-doc/latex/dtxgallery/conditional-code.pdf
/usr/share/doc/texlive-doc/latex/dtxgallery/dtxgallery.pdf
/usr/share/doc/texlive-doc/latex/dtxgallery/rearrange.pdf
/usr/share/doc/texlive-doc/latex/dtxgallery/single-source.pdf

To make dtxgallery useful please put the dtx files in the same directory as 
dtxgallery.pdf,
and make the names of the dtx files in dtxgallery.pdf a hyperlink to these 
files,
so that they can be easily opened by clicking on their names.

Best wishes,

Gábor

-- 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/4 CPU cores)
Locale: LANG=hu_HU.UTF-8, LC_CTYPE=hu_HU.UTF-8 (charmap=UTF-8), 
LANGUAGE=hu:en_US:de (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages texlive-latex-extra-doc depends on:
ii  tex-common6.10
ii  texlive-base  2018.20181214-1

texlive-latex-extra-doc recommends no packages.

texlive-latex-extra-doc suggests no packages.

Versions of packages tex-common depends on:
ii  dpkg  1.19.2
ii  ucf   3.0038

Versions of packages tex-common suggests:
pn  debhelper  

Versions of packages texlive-latex-extra-doc is related to:
ii  tex-common6.10
ii  texlive-binaries  2018.20181104.49075-2

-- no debconf information

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

[Tiziano Zito]

Hi!

I have the same issue. Not sure the problem is with the kernel package though, 
because even purging and/or reinstalling linux-image-4.18.0-3 fails (see 
below). Any suggestion which package may be responsible? The problem started 
after a dist-upgrade on Dec 24...

Thanks!
Tiziano

# aptitude purge linux-image-4.18.0-3-amd64
The following packages will be REMOVED:
 linux-image-4.18.0-3-amd64{p}
0 packages upgraded, 0 newly installed, 1 to remove and 0 not upgraded.
Need to get 0 B of archives. After unpacking 258 MB will be freed.
Do you want to continue? [Y/n/?] Y
(Reading database ... 420270 files and directories currently installed.)
Removing linux-image-4.18.0-3-amd64 (4.18.20-2) ...
I: /vmlinuz.old is now a symlink to boot/vmlinuz-4.19.0-1-amd64
I: /initrd.img.old is now a symlink to boot/initrd.img-4.19.0-1-amd64
/etc/kernel/postrm.d/initramfs-tools:
update-initramfs: Deleting /boot/initrd.img-4.18.0-3-amd64
/etc/kernel/postrm.d/zz-update-grub:
/usr/sbin/grub-probe: error: failed to get canonical path of 
`/dev/mapper/CRYPT-ROOT'.
run-parts: /etc/kernel/postrm.d/zz-update-grub exited with return code 1
dpkg: error processing package linux-image-4.18.0-3-amd64 (--remove):
installed linux-image-4.18.0-3-amd64 package post-removal script subprocess 
returned error exit status 1
Errors were encountered while processing:
linux-image-4.18.0-3-amd64
E: Sub-process /usr/bin/dpkg returned an error code (1)

# aptitude reinstall linux-image-4.18.0-3-amd64
The following packages will be REINSTALLED:
 linux-image-4.18.0-3-amd64
0 packages upgraded, 0 newly installed, 1 reinstalled, 0 to remove and 0 not 
upgraded.
Need to get 0 B/45.7 MB of archives. After unpacking 0 B will be used.
(Reading database ... 416025 files and directories currently installed.)
Preparing to unpack .../linux-image-4.18.0-3-amd64_4.18.20-2_amd64.deb ...
Unpacking linux-image-4.18.0-3-amd64 (4.18.20-2) over (4.18.20-2) ...
Setting up linux-image-4.18.0-3-amd64 (4.18.20-2) ...
I: /vmlinuz.old is now a symlink to boot/vmlinuz-4.18.0-3-amd64
I: /initrd.img.old is now a symlink to boot/initrd.img-4.18.0-3-amd64
/etc/kernel/postinst.d/dkms:
Error! Your kernel headers for kernel 4.18.0-3-amd64 cannot be found.
Please install the linux-headers-4.18.0-3-amd64 package,
or use the --kernelsourcedir option to tell DKMS where it's located
/etc/kernel/postinst.d/initramfs-tools:
update-initramfs: Generating /boot/initrd.img-4.18.0-3-amd64
cryptsetup: ERROR: Couldn't resolve device /dev/mapper/CRYPT-ROOT
cryptsetup: WARNING: Couldn't determine root device
Warning: couldn't identify filesystem type for fsck hook, ignoring.
/etc/kernel/postinst.d/zz-update-grub:
/usr/sbin/grub-probe: error: failed to get canonical path of 
`/dev/mapper/CRYPT-ROOT'.
run-parts: /etc/kernel/postinst.d/zz-update-grub exited with return code 1
dpkg: error processing package linux-image-4.18.0-3-amd64 (--configure):
installed linux-image-4.18.0-3-amd64 package post-installation script 
subprocess returned error exit status 1
Errors were encountered while processing:
linux-image-4.18.0-3-amd64
E: Sub-process /usr/bin/dpkg returned an error code (1)

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

[Luca Boccassi]

On Tue, 25 Dec 2018 09:16:57 +0100 Sebastiaan Couwenberg  wrote:
> 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
> 
> 
> 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?
> 
> default-libmysqlclient-dev depends on libmariadbclient-dev-compat
which
> is built from the mariadb-10.1 source package.
> 
> libmariadbclient-dev-compat depends on libmariadbclient-dev (also
built
> from the mariadb-10.1 source package), which in turn depends on
> libmariadbclient18 (= 1:10.1.37-3).
> 
> As long as the 10.3 packages Conflict or Break 10.1 packages, the
> default-* packages cannot be installed along with the 10.3 packages,
as
> the default packages are depending on the 10.1 packages.
> 
> Kind Regards,
> 
> Bas

Hi,

I just encountered a similar issue, causes a build regression in
collectd [1].

The issue is that build-depending on default-libmysqlclient-dev causes
libmariadbclient-dev-compat from 10.1 to be installed instead of
libmariadb-dev-compat from 10.3, which means the mysql_config binary is
missing and the configure step of collectd thus fails.
Manually installing libmariadb-dev-compat, which causes
libmariadbclient-dev-compat to be removed, fixes the issue.

-- 
Kind regards,
Luca Boccassi

[1] 
https://buildd.debian.org/status/fetch.php?pkg=collectd=amd64=5.8.1-1.1=1545690583=0

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

Bug#917241: libnss-unknown: Please provide more elaborate description in long description

[Petter Reinholdtsen]

[Ritesh Raj Sarraf]
> + .
> + This library is very useful in host <=> guest container build
> + environments, where shifting UIDs/GIDs result in a mismatch in
> + between

Did something fall out of this patch?  Could you perhaps also explain
_how_ it is very useful, in addition to explaining in what context it is
useful.

-- 
Happy hacking
Petter Reinholdtsen

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

[Jonas Smedegaard]

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.

 - Jonas

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAlwiFykACgkQLHwxRsGg
ASEYuRAArc4n/jFb525qH2mqu8Q8zbIZt323/jW7kkRuWz2OmXv8ZLuSuNXg+vLK
K8M+HLi3UQB54v9Wh7JgQ1QWFRo/jobgwRmBWT+l+Jv2HAfwrKFABkjvcEBE70VG
Ggo7Fi0I++y1BD37FQudiWviTdqLuYnfxCLWCM0EaTkhxpREiIe5pNfspuu1n9mU
fwvTdVhUAB2aGXXjVlx97tsOZSx3FrqIm3W3fbIJF/gE+Nl52ceNsC5BmoJaPYbJ
HWgwruWKqa7+kBcUs0+FMCHLqLAluJPVnUdViRWTUHdeMnTs6wqIZXt6mbX56rjD
TKcLu1VLjUHmxWKdmi3Py8lsV/2nLajvDncWdaLQN6UEwGhuxk4+9DbOjP65vtEv
Rnvv0ufb3zwmg9gnagfXDU1KxFpK//rCtj33aLVK2ttyESKy8x4ufyonPYXHQsdt
7t0606H7QQBytzun8fmdmoqx8SaNcYLDtytL7A8BI+alhejKUZW/+d8v1NyQ8W7z
RrUInUe1bWjzfpcy2HXewZevFpFbI6VIjiFCv0opKOJmKPabnsrAH192sz0cWJhO
bC0E1iBW/EkFf6Zghs/KUR90w0PplAfkk+XGDbzX2CWPvGdW6OADvA8AUdTMl1Fx
kOaBV8k6zMTn3sSdkfom0KCafKSH46NVVgXsuMBm/XFFQuGNyDA=
=JVoX
-END PGP SIGNATURE-

Bug#917250: RFS: dwarves/1.12-1

[Adam Borowski]

On Mon, Dec 24, 2018 at 06:49:34PM +0100, Domenico Andreoli wrote:
> I'm looking for a sponsor for this package:

Hi!  I assume you have a problem with your gpg key.

> * Package name: dwarves-dfsg
>   Version : 1.12-1

> dwarves-dfsg (1.12-1) unstable; urgency=medium
> 
>   [ Domenico Andreoli ]
>   * New upstram release. Closes: #908563, #779809, #693096,
>   * Migrate to salsa.d.o and enable CI. Closes: #908564.
>   * Migrate to DEP-14.
>   * Drop patch DW_TAG_mutable_type (merged upstream).
>   * Refresh patch no_shared_no_ebl.
>   * Improve package description. Closes: #914527.
>   * Add test executing pahole on itself.
>   * Set debhelper compatibility level to 10.
>   * Start using dh_strip_nondeterminism.
> 
>   [ Helmut Grohne ]
>   * Let dh_auto_configure pass cross flags to cmake. Closes: #903506.

I have no complaints other than what lintian says (yet?), but with so many
warnings that are trivially fixable it'd be better to give it at least some
heed.  Improper debhelper versioning hurts backports, using a ssh URL for
VCS- breaks QA pages, etc.

On the other hand, if you insist because of wanting the new release in while
you're not capable of caring for less important matters, please say so --
these are only warnings rather than show-stoppers.


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

[Braun Gábor]

Package: kinit
Version: 5.51.0-1
Severity: normal

Dear Maintainer,

Navigating to my home directory in Dolphin, a drkonqi message appears
"A(z) kdeinit5 váratlanul bezárult"
(meaning: kdeinit5 unexpectedly stopped) with buttons to report the bug and
restart the application.  Clicking on the button for reporting the bug,
a window with two tabs appears, and in th active tab the following message:
"Sajnáljuk, de a(z) kdeinit5 váratlanul eállt.
Nem jelentheti a hibát, mivel kdeinit5 nem adott meg gibajelentési címet."
Translated: Sorry, kdeiinit5 stopped unexpectedly.
The bug cannot be reported as kdeinit5 does not provide an address for it.

Selecting the other tab, a backtrace appears, see below, with the remark that 
it is not useful.
Clicking on the appropriate link, a window appears claiming that the debugging 
information for
the following files are missing:

/usr/bin/kdeinit5
/usr/lib/x86_64-linux-gnu/qt5/plugins/kf5/kio/thumbnail.so
/usr/lib/x86_64-linux-gnu/qt5/plugins/ffmpegthumbs.so
/usr/lib/x86_64-linux-gnu/libKF5KIOCore.so.5

I was unable to find the packages with the debugging symbols, e.g.,
I have not found a package named kinit-dbg or kinit-dbgsym.

This whole thing happens only with my home directory, and besides the drkonqi 
message
everything else seems to function correctly.

To summarize the problems:
1) There is a spurious drkonqi crash message.
2) Drkonqi claims that there is no address to report bugs of kdeinit5.
3) I haven't found the packages with debugging symbols.

Best wishes,

Gábor

Backtrace:

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 0x7fc5760d3780 (LWP 4547))]

Thread 3 (Thread 0x7fc56a1dc700 (LWP 4550)):
#0  0x7fc579ebdbd9 in poll () from /lib/x86_64-linux-gnu/libc.so.6
#1  0x7fc5783a5e46 in ?? () from /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
#2  0x7fc5783a5f6c in g_main_context_iteration () from 
/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
#3  0x7fc57a24cd2b in 
QEventDispatcherGlib::processEvents(QFlags) () 
from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#4  0x7fc57a1f9d0b in 
QEventLoop::exec(QFlags) () from 
/usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#5  0x7fc57a0490c6 in QThread::exec() () from 
/usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#6  0x7fc575690545 in ?? () from /usr/lib/x86_64-linux-gnu/libQt5DBus.so.5
#7  0x7fc57a052c97 in ?? () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#8  0x7fc579db0fa3 in start_thread () from 
/lib/x86_64-linux-gnu/libpthread.so.0
#9  0x7fc579ec888f in clone () from /lib/x86_64-linux-gnu/libc.so.6

Thread 2 (Thread 0x7fc571856700 (LWP 4548)):
#0  0x7fc579ebdbd9 in poll () from /lib/x86_64-linux-gnu/libc.so.6
#1  0x7fc57aa6fcf7 in ?? () from /usr/lib/x86_64-linux-gnu/libxcb.so.1
#2  0x7fc57aa7191a in xcb_wait_for_event () from 
/usr/lib/x86_64-linux-gnu/libxcb.so.1
#3  0x7fc5721a1519 in ?? () from /usr/lib/x86_64-linux-gnu/libQt5XcbQpa.so.5
#4  0x7fc57a052c97 in ?? () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#5  0x7fc579db0fa3 in start_thread () from 
/lib/x86_64-linux-gnu/libpthread.so.0
#6  0x7fc579ec888f in clone () from /lib/x86_64-linux-gnu/libc.so.6

Thread 1 (Thread 0x7fc5760d3780 (LWP 4547)):
[KCrash Handler]
#6  0x7fc5632d44f4 in ?? () from 
/usr/lib/x86_64-linux-gnu/qt5/plugins/ffmpegthumbs.so
#7  0x7fc5632d620a in ?? () from 
/usr/lib/x86_64-linux-gnu/qt5/plugins/ffmpegthumbs.so
#8  0x7fc5632d6359 in ?? () from 
/usr/lib/x86_64-linux-gnu/qt5/plugins/ffmpegthumbs.so
#9  0x7fc5632d3793 in ?? () from 
/usr/lib/x86_64-linux-gnu/qt5/plugins/ffmpegthumbs.so
#10 0x7fc57ae53e80 in ?? () from 
/usr/lib/x86_64-linux-gnu/qt5/plugins/kf5/kio/thumbnail.so
#11 0x7fc57ae54458 in ?? () from 
/usr/lib/x86_64-linux-gnu/qt5/plugins/kf5/kio/thumbnail.so
#12 0x7fc57ae54b30 in ?? () from 
/usr/lib/x86_64-linux-gnu/qt5/plugins/kf5/kio/thumbnail.so
#13 0x7fc57ae56041 in ?? () from 
/usr/lib/x86_64-linux-gnu/qt5/plugins/kf5/kio/thumbnail.so
#14 0x7fc575cdedf6 in KIO::SlaveBase::dispatch(int, QByteArray const&) () 
from /usr/lib/x86_64-linux-gnu/libKF5KIOCore.so.5
#15 0x7fc575cda196 in KIO::SlaveBase::dispatchLoop() () from 
/usr/lib/x86_64-linux-gnu/libKF5KIOCore.so.5
#16 0x7fc57ae5308d in kdemain () from 
/usr/lib/x86_64-linux-gnu/qt5/plugins/kf5/kio/thumbnail.so
#17 0x56107a404e1c in ?? ()
#18 0x56107a405eea in ?? ()
#19 0x56107a4068fb in ?? ()
#20 0x56107a401645 in ?? ()
#21 0x7fc579df309b in __libc_start_main () from 
/lib/x86_64-linux-gnu/libc.so.6
#22 0x56107a4022ca in _start ()
[Inferior 1 (process 4547) detached]


-- 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/4 CPU cores)
Locale: LANG=hu_HU.UTF-8, LC_CTYPE=hu_HU.UTF-8 (charmap=UTF-8), 

Bug#917167: systemd: 240 breaks kde (rakes ages to launch)

[Vincas Dargis]

On Sun, 23 Dec 2018 19:15:27 +0100 Michael Biebl  wrote:

For a (temporary) workaround you can create a file
/etc/security/limits.d/systemd.conf containing:

* hard nofile 524288


That did the trick, thanks!

Bug#917271: yamllint: requires module pkg_resources but does not depend on it

[Jack Henschel]

Package: yamllint
Version: 1.5.0-1
Severity: important
Tags: patch

Dear maintainer,

I just installed the `yamllint` package on a pretty fresh Debian Stretch
system. When running it for the first time the following error occured:

> yamllint etc/hiera.yaml
> Traceback (most recent call last):
>   File "/usr/bin/yamllint", line 6, in 
> from pkg_resources import load_entry_point
> ImportError: No module named 'pkg_resources'

Apparently the package requires the `pkg_resources` module, but the
package is missing the appropriate dependency.
From `/usr/bin/yamllint`:
> from pkg_resources import load_entry_point

The error was resolved after manually installing the
`python3-pkg-resources` package.

Please add the package `python3-pkg-resources` to the Depends-field of
`yamllint`.

Thanks!

Greetings
Jack



signature.asc
Description: OpenPGP digital signature

Bug#917266: [debian-mysql] Bug#917266: default-libmysqlclient-dev: Uninstallable - depends on no longer built libmariadbclient-dev-compat

[Otto Kekäläinen]

Hello!

ti 25. jouluk. 2018 klo 10.06 Scott Kitterman (deb...@kitterman.com) kirjoitti:
> Severity: grave
> Justification: renders package unusable
>
>  no longer found.
>
> Since mariadb10.3 became the default this no longer works:
>
> #include 
>
> It has to be changed to:
>
> #include 
>
> You can experience this for yourself by rebuilding postfix, seeing it fail:
>
> gcc -fPIC -I. -I../../include -DDEBIAN -DHAS_PCRE -DHAS_LDAP -DUSE_LDAP_SASL 
> -DHAS_SQLITE -DMYORIGIN_FROM_FILE -DHAS_CDB -DHAS_LMDB -DHAS_MYSQL 
> -I/usr/include/mysql -DHAS_PGSQL -I/usr/include/postgresql -DHAS_SQLITE 
> -I/usr/include -DHAS_SSL -I/usr/include/openssl -DUSE_SASL_AUTH 
> -I/usr/include/sasl -DUSE_CYRUS_SASL -DUSE_TLS -I/usr/include 
> -DHAS_DEV_URANDOM -DDEF_DAEMON_DIR=\"/usr/lib/postfix/sbin\" 
> -DDEF_HTML_DIR=\"/usr/share/doc/postfix/html\" 
> -DDEF_MANPAGE_DIR=\"/usr/share/man\" 
> -DDEF_README_DIR=\"/usr/share/doc/postfix\" -DUSE_DYNAMIC_LIBS 
> -DUSE_DYNAMIC_MAPS -Wmissing-prototypes -Wformat -Wno-comment -fPIC -g -O2 
> -I. -I../../include -DLINUX3 -c dict_ldap.c
> gcc -shared -Wl,--enable-new-dtags -Wl,-rpath,/usr/lib/postfix -o 
> postfix-ldap.so dict_ldap.o -lldap -llber -L../../lib -L. -lpostfix-util 
> -lpostfix-global
> gcc -fPIC -I. -I../../include -DDEBIAN -DHAS_PCRE -DHAS_LDAP -DUSE_LDAP_SASL 
> -DHAS_SQLITE -DMYORIGIN_FROM_FILE -DHAS_CDB -DHAS_LMDB -DHAS_MYSQL 
> -I/usr/include/mysql -DHAS_PGSQL -I/usr/include/postgresql -DHAS_SQLITE 
> -I/usr/include -DHAS_SSL -I/usr/include/openssl -DUSE_SASL_AUTH 
> -I/usr/include/sasl -DUSE_CYRUS_SASL -DUSE_TLS -I/usr/include 
> -DHAS_DEV_URANDOM -DDEF_DAEMON_DIR=\"/usr/lib/postfix/sbin\" 
> -DDEF_HTML_DIR=\"/usr/share/doc/postfix/html\" 
> -DDEF_MANPAGE_DIR=\"/usr/share/man\" 
> -DDEF_README_DIR=\"/usr/share/doc/postfix\" -DUSE_DYNAMIC_LIBS 
> -DUSE_DYNAMIC_MAPS -Wmissing-prototypes -Wformat -Wno-comment -fPIC -g -O2 
> -I. -I../../include -DLINUX3 -c dict_mysql.c
> dict_mysql.c:171:10: fatal error: mysql.h: No such file or directory
>  #include 
>   ^
> compilation terminated.
>
> And then changing src/global/dict_mysql.c line 171
>
> Alternately, I could update the include path, I guess, but isn't approximately
> the whol point of providing a generic default so that every package in
> Debian doesn't have to change when the default changes?

Yes, these #include mysql.h in Debian can be found via
https://codesearch.debian.net/search?q=%22mysql.h%22=1

In mariadb-10.1 the mysql.h was shipped in package
libmariadbclient-dev at path /usr/include/mysql/mysql.h. The package
libmariadbclient-dev-compat does not provide any symlinks or anything
related to /usr/include

In mariadb-connector-c mysql.h was shipped in package libmariadb-dev
at path /usr/include/mariadb/mysql.h

In mariadb-10.3, which now includes libmariadb3 (and no
libmariadbclient18 anymore), so basically same as mariadb-connector-c,
and ships mysql.h in package libmariadb-dev at path
/usr/include/mariadb/mysql.h.

I've attached file listing from the relevant libmariadb* packages
across mariadb-10.1, -10.3 and mariadb-connector-c so it is easier for
you to review and suggest how to proceed.

I tested the cmake flags used in mariadb-connector-c to modify the
file layout (DINSTALL_LAYOUT:STRING=DEB -DPLUGINDIR_DEB=mariadb3
-DWITH_MYSQLCOMPAT=ON)
[1] but they did not have any effect.

I don't think there is anything I can do. Feel free to open a merge
request[2] on mariadb-10.3 if you have a vision how to add symlinks or
something to solve this.

I've CC'd a few upstream developers in case they care about how
existing programs using mysql.h can build using MariaDB in the future
and if they want to suggest what to do here. The upstream Debian
packages don't currently support being used as a drop-in replacement
for libmysqlclient18 and I don't think anybody ever actually tested
using libmariadb3 for it, nor is there hardly any documentation at
mariadb.com/kb/ about libmariadb3 usage and compilation examples.


[1] 
https://salsa.debian.org/mariadb-team/mariadb-connector-c/blob/master/debian/rules#L14-16
[2] https://wiki.debian.org/Teams/MySQL/patches
libmariadb3
drwxr-xr-x ./
drwxr-xr-x ./usr/
drwxr-xr-x ./usr/lib/
drwxr-xr-x ./usr/lib/x86_64-linux-gnu/
-rw-r--r-- ./usr/lib/x86_64-linux-gnu/libmariadb.so.3
drwxr-xr-x ./usr/lib/x86_64-linux-gnu/mariadb19/
drwxr-xr-x ./usr/lib/x86_64-linux-gnu/mariadb19/plugin/
-rw-r--r-- ./usr/lib/x86_64-linux-gnu/mariadb19/plugin/client_ed25519.so
-rw-r--r-- ./usr/lib/x86_64-linux-gnu/mariadb19/plugin/dialog.so
-rw-r--r-- ./usr/lib/x86_64-linux-gnu/mariadb19/plugin/mysql_clear_password.so
-rw-r--r-- ./usr/lib/x86_64-linux-gnu/mariadb19/plugin/sha256_password.so
drwxr-xr-x ./usr/share/
drwxr-xr-x ./usr/share/doc/
drwxr-xr-x ./usr/share/doc/libmariadb3/
-rw-r--r-- ./usr/share/doc/libmariadb3/changelog.Debian.gz
-rw-r--r-- ./usr/share/doc/libmariadb3/copyright

libmariadbclient18
drwxr-xr-x ./
drwxr-xr-x ./usr/

Bug#880393: nmuing cyrus-sasl2

[Helmut Grohne]

Hi Ryan,

On Mon, Dec 24, 2018 at 03:48:19PM -0800, Ryan Tandy wrote:
> I don't see any conversation about it in the bugs, but that NMU doesn't seem
> to have happened, was there a reason?

The NMU went to delayed, but then Ondřej Surý did a maintainer upload
without including the fixes nor explaining why they shouldn't be used.
Since his (MU) version was higher than my (NMU) version, my upload was
rejected once it departed from delayed. Therefore this bug still affects
unstable despite having a solution. I'm unsure on how to best deal with
this non-communication and figured that I'd simply give up.

I'd appreciate if someone else could handle this. At least I dissected
the cause and provided a simple and backportable solution. Could you
move this forward?

Also given the simplicity of the fix, adding it to a stretch point
release would make a lot of sense.

Helmut

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

[Luca Boccassi]

On Mon, 24 Dec 2018 01:33:08 +0100 Aurelien Jarno  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!

-- 
Kind regards,
Luca Boccassi

[1] https://github.com/collectd/collectd/pull/3013
[2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=916351
[3] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=917075diff -Nru collectd-5.8.1/debian/changelog collectd-5.8.1/debian/changelog
--- collectd-5.8.1/debian/changelog	2018-12-19 15:52:36.0 +0100
+++ collectd-5.8.1/debian/changelog	2018-12-25 12:08:23.0 +0100
@@ -1,3 +1,12 @@
+collectd (5.8.1-1.2) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Backport removed_checks_for_upper_limit_of_SENSORS_API.patch from
+the upstream 5.8 release branch to fix build with libsensors5.
+(Closes: #917202)
+
+ -- Luca Boccassi   Tue, 25 Dec 2018 12:08:23 +0100
+
 collectd (5.8.1-1.1) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru collectd-5.8.1/debian/patches/removed_checks_for_upper_limit_of_SENSORS_API.patch collectd-5.8.1/debian/patches/removed_checks_for_upper_limit_of_SENSORS_API.patch
--- collectd-5.8.1/debian/patches/removed_checks_for_upper_limit_of_SENSORS_API.patch	1970-01-01 01:00:00.0 +0100
+++ collectd-5.8.1/debian/patches/removed_checks_for_upper_limit_of_SENSORS_API.patch	2018-12-25 12:07:43.0 +0100
@@ -0,0 +1,73 @@
+Author: Pavel Rochnyack 
+Origin: https://github.com/collectd/collectd/commit/d5a3c020d33cc33ee8049f54c7b4dffcd123bf83
+Forwarded: https://github.com/collectd/collectd/pull/3013
+Description: sensors: Removed checks for upper limit of SENSORS_API_VERSION
+ That makes no more sense after lm-sensors got new maintainers.
+--- a/src/sensors.c
 b/src/sensors.c
+@@ -149,7 +149,7 @@ typedef struct featurelist {
+ static char *conffile = SENSORS_CONF_PATH;
+ /* #endif SENSORS_API_VERSION < 0x400 */
+ 
+-#elif (SENSORS_API_VERSION >= 0x400) && (SENSORS_API_VERSION < 0x500)
++#elif (SENSORS_API_VERSION >= 0x400)
+ typedef struct featurelist {
+   const sensors_chip_name *chip;
+   const sensors_feature *feature;
+@@ -159,11 +159,6 @@ typedef struct featurelist {
+ 
+ static char *conffile = NULL;
+ static _Bool use_labels = 0;
+-/* #endif (SENSORS_API_VERSION >= 0x400) && (SENSORS_API_VERSION < 0x500) */
+-
+-#else /* if SENSORS_API_VERSION >= 0x500 */
+-#error "This version of libsensors is not supported yet. Please report this " \
+-	"as bug."
+ #endif
+ 
+ static featurelist_t *first_feature = NULL;
+@@ -223,7 +218,7 @@ static int sensors_config(const char *ke
+ if (IS_TRUE(value))
+   ignorelist_set_invert(sensor_list, 0);
+   }
+-#if (SENSORS_API_VERSION >= 0x400) && (SENSORS_API_VERSION < 0x500)
++#if (SENSORS_API_VERSION >= 0x400)
+   else if (strcasecmp(key, "UseLabels") == 0) {
+ use_labels = IS_TRUE(value) ? 1 : 0;
+   }
+@@ -353,7 +348,7 @@ static int sensors_load_conf(void) {
+   }   /* while sensors_get_detected_chips */
+ /* #endif SENSORS_API_VERSION < 0x400 */
+ 
+-#elif (SENSORS_API_VERSION >= 0x400) && (SENSORS_API_VERSION < 0x500)
++#elif (SENSORS_API_VERSION >= 0x400)
+   chip_num = 0;
+   while ((chip = sensors_get_detected_chips(NULL, _num)) != NULL) {
+ const sensors_feature *feature;
+@@ -410,7 +405,7 @@ static int sensors_load_conf(void) {
+   } /* while (subfeature) */
+ }   /* while (feature) */
+   } /* while (chip) */

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

[Hilmar Preuße]

On 25.12.18 10:38, Braun Gábor wrote:

Hi Norbert,

> 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:
> 
This is clearly an upstream bug (packager of TeX Live). Norbert: would
you be so kind to have a look at this?

Hilmar
-- 
#206401 http://counter.li.org

Bug#917272: Kernel module failed to load on 4.19 kernel.

[Gong S.]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Package: firmware-amd-graphics
Version: 20180825+dfsg-1

For some reason, from 4.19.0 onward, the kernel refuses to load the AMD 
modules. The screen defaults to 80*25 text mode and "startx" does not work.
Here is what I have tried:
linux-image-4.19.0-trunk-amd64-unsigned/now 4.19.5-1~exp1 amd64: WORKS
linux-image-4.19.0-1-amd64-unsigned/unstable 4.19.12-1 amd64: DOES NOT WORK
linux-image-4.20.0-trunk-amd64-unsigned/experimental 4.20-1~exp1 amd64: DOES 
NOT WORK ("dmesg" log attached)
It does not look like the kernel itself is the problem (as 4.19-trunk works but 
4.19 does not), so the problem is the firmware.
--
"And in the naked light, I saw ten thousand people, maybe more. People \
talking without speaking, people hearing without listening. People writ\
ing songs that voices never shared, no one dared disturb the sound of s\
ilence." --MA Bo'yong
-BEGIN PGP SIGNATURE-
Version: ProtonMail
Comment: https://protonmail.com

wsBcBAEBCAAGBQJcIg5HAAoJENi1YDlFXXQfqRAH/3NGXqLXLCWWOEAkRkHn
RXCYbILbBYqY9G1PTadc4ycce828Z9uwRytKkQ3C7rvulIjcYA6SD5Zv7Yl6
g9yhb0+ZW6gedIV86bGvQpwgY2NWyvDtm1FL+GUrEcrNMT9qJD1W4uQ2s+P9
YZCdEWcvBaj/mYuqLzHG9yA/2Kfv7BFjULbhq3+PDfBKiOGZdG3ufHd6NEP5
m7QN/PXV2F6K6BPQ/uGragb0/QHFUE6pyeCynh4rbDixMwe5Fb2mfRcDNTDg
J8GUH8J0CkLaqADVZK6zzrDiAy+MqlVK3zTSx3EBK6bDc8S9CNOgvXt34XRh
KwceEhcEsZpqKguUw3qlsQg=
=cy56
-END PGP SIGNATURE-



dmesg.0
Description: Binary data


dmesg.0.sig
Description: PGP signature


publickey - pthfdr@protonmail.ch - 0xAB77ABA4.asc
Description: application/pgp-keys


publickey - pthfdr@protonmail.ch - 0xAB77ABA4.asc.sig
Description: PGP signature

Bug#917273: overwritting files from libservlet2.5-java

[Eduard Bloch]

Package: libel-api-java
Version: 3.0.0-1
Severity: grave

The usual story, not installable, breaks upgrade.
Please resolve this conflict:

Unpacking libel-api-java (3.0.0-1) ...
dpkg: error processing archive 
/var/cache/apt/archives/libel-api-java_3.0.0-1_all.deb (--unpack):
 trying to overwrite 
'/usr/share/maven-repo/javax/el/el-api/debian/el-api-debian.pom', which is also 
in package libservlet2.5-java 6.0.45+dfsg-1
Errors were encountered while processing:
 /var/cache/apt/archives/libel-api-java_3.0.0-1_all.deb

-- 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.20.0-rc7 (SMP w/4 CPU cores; PREEMPT)
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/bash
Init: systemd (via /run/systemd/system)

-- 
"Lassen Sie sich 'Sklaventreiber' auf die Stirn tätowieren. Das ist
ehrlich, da wissen wir alle woran wir sind".
-- Volker Pispers

Bug#917276: mysql-defaults and MariaDB 10.3

[Otto Kekäläinen]

Source: mysql-defaults
Version: 1.0.5
Severity: serious
Justification: makes the package in question unusable or mostly so

The package has been updated to depend on Mariadb 10.3, which is
currently available only in Debian unstable. This serious bug report
is done to prevent mysql-defaults from entering Debian testing before
mariadb-10.3 has done so.

Bug#917250: RFS: dwarves/1.12-1

[Domenico Andreoli]

On Tue, Dec 25, 2018 at 12:59:20PM +0100, Adam Borowski wrote:
> On Mon, Dec 24, 2018 at 06:49:34PM +0100, Domenico Andreoli wrote:
> > I'm looking for a sponsor for this package:
> 
> Hi!  I assume you have a problem with your gpg key.

Hi Adam, Merry Christmas!

Indeed my old 1024 bit key has been dropped some time ago and the new
one has not enough signatures. And I've been very busy elsewhere in
the meanwhile :)

> > * Package name: dwarves-dfsg
> >   Version : 1.12-1
> 
> > dwarves-dfsg (1.12-1) unstable; urgency=medium
> > 
> >   [ Domenico Andreoli ]
> >   * New upstram release. Closes: #908563, #779809, #693096,
> >   * Migrate to salsa.d.o and enable CI. Closes: #908564.
> >   * Migrate to DEP-14.
> >   * Drop patch DW_TAG_mutable_type (merged upstream).
> >   * Refresh patch no_shared_no_ebl.
> >   * Improve package description. Closes: #914527.
> >   * Add test executing pahole on itself.
> >   * Set debhelper compatibility level to 10.
> >   * Start using dh_strip_nondeterminism.
> > 
> >   [ Helmut Grohne ]
> >   * Let dh_auto_configure pass cross flags to cmake. Closes: #903506.
> 
> I have no complaints other than what lintian says (yet?), but with so many
> warnings that are trivially fixable it'd be better to give it at least some
> heed.  Improper debhelper versioning hurts backports, using a ssh URL for
> VCS- breaks QA pages, etc.

my intention is to address as many as possible but I am not the fastest
bullet on the market and it may take some more time.

> On the other hand, if you insist because of wanting the new release in while
> you're not capable of caring for less important matters, please say so --
> these are only warnings rather than show-stoppers.

OTOH we are not far from the freeze and would not dislike to have a
first push, just to be sure Buster get a [dr]ecent version or that we
catch any real blocker earlier.

Thanks for your support.

Regards,
Domenico

-- 
3B10 0CA1 8674 ACBA B4FE  FCD2 CE5B CF17 9960 DE13


signature.asc
Description: PGP signature

Bug#917277: epstool: incorrect bounding box calculated

[David Bremner]

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-


input.eps.xz
Description: application/xz

Bug#863675: [debian-mysql] Bug#863675: libmariadbd-dev: fails to upgrade from 'sid' - trying to overwrite /usr/bin/mysql_config

[Otto Kekäläinen]

I made this extension to the gitlab-ci.yml file to be able to
automatically test for issues like this in the future:
https://salsa.debian.org/mariadb-team/mariadb-10.3/commit/0ec004b4e4fc7c98a7b16cbe1a821be12ace1110

Ideally it would actually also attempt to build something first with
MySQL and then with MariaDB and verify it actually works, but I don't
know any good example to do it with.

Bug#917018: wget: Unusable - permanent segmentation fault

[rwpenney]

Hello Bernhard,

I do indeed have a ~/.wget-hsts file, and it has permissions and 
contents that seem suspiciously linked with setup of unprivileged LXC 
containers. If I remove that file, wget seems to work fine. Obviously, 
wget shouldn't just be crashing when it fails to open this file, but at 
least you've given us a good work-around.


Thanks for finding the source of the problem.

Kind regards,

RW Penney

Bug#915419: debdiff for 915692, 915419

[Luca Boccassi]

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.

-- 
Kind regards,
Luca Boccassi

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=917075

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

[Otto Kekäläinen]

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/41b7e55f1c5a3cb93da2e2407230542cc9284222

Bug#917242: libreoffice-common: ships svg files in folder for png files

[Rene Engelhard]

Hi,

On Mon, Dec 24, 2018 at 04:50:51PM +0100, Jonas Smedegaard wrote:
> I noticed /usr/share/icons/hicolor/512x512/apps contains svg files,
> seemingly all belonging to libreoffice.
> 
> Example: /usr/share/icons/hicolor/512x512/apps/libreoffice-calc.svg
>
> That directory is meant only for bitmap graphics.
> 
> Perhaps they were intended for /usr/share/icons/hicolor/scalable?

Those exist there, too. With differing md5sums

$ find /usr/share/icons/hicolor/ -name "libreoffice-calc.svg" | xargs md5sum
c0f1c7eeb64645c34c869c39c177ed80 
/usr/share/icons/hicolor/128x128/apps/libreoffice-calc.svg
e3d76d0f7a24929f0fe1b841079148af 
/usr/share/icons/hicolor/16x16/apps/libreoffice-calc.svg 
c0f1c7eeb64645c34c869c39c177ed80 
/usr/share/icons/hicolor/scalable/apps/libreoffice-calc.svg

599700e319c5ffbc84652f625eee4686 
/usr/share/icons/hicolor/512x512/apps/libreoffice-calc.svg
^^^
7a97cada5c70fb9e00529f355f699060 
/usr/share/icons/hicolor/64x64/apps/libreoffice-calc.svg
df5ad249017d59b8d2f687b97734c7af 
/usr/share/icons/hicolor/24x24/apps/libreoffice-calc.svg
d31e64c26e7ed0d5bc0942fe8c5e0de0 
/usr/share/icons/hicolor/22x22/apps/libreoffice-calc.svg
cea352b03f1121c92734741761c39a98 
/usr/share/icons/hicolor/48x48/apps/libreoffice-calc.svg
257b05b635fda23468a8b8d569b25b99 
/usr/share/icons/hicolor/256x256/apps/libreoffice-calc.svg
4ce0a74376d62a4cd4c857d3882bcac3 
/usr/share/icons/hicolor/32x32/apps/libreoffice-calc.svg

Regards,

Rene

Bug#916745: web2py2po and po2web2py fail to work ("convertpy() got an unexpected keyword argument 'duplicatestyle'" and "'ascii' codec can't encode character")

[Petter Reinholdtsen]

I pulled the patch from the upstream pull request and created a
d/patches/ entry for it.  Please included in Debian to fix the web2py
support.  The test code can be skipped if you want to limit the size of
the patch.

-- 
Happy hacking
Petter Reinholdtsen
diff --git a/debian/patches/series b/debian/patches/series
index 290858707..9fee92537 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -8,3 +8,4 @@ storage_bzr
 poterminology_defaultstopfile
 sphinx-intersphinx.patch
 af-pootle.patch
+web2py-fixes.patch
diff --git a/debian/patches/web2py-fixes.patch b/debian/patches/web2py-fixes.patch
new file mode 100644
index 0..7e5a51547
--- /dev/null
+++ b/debian/patches/web2py-fixes.patch
@@ -0,0 +1,231 @@
+Description: Fix web2py support
+Author: Vinyl Darkscratch
+Origin: https://github.com/translate/translate/pull/3838
+Bug: https://github.com/translate/translate/issues/3254
+Bug-Debian: https://bugs.debian.org/916745
+Forwarded: not-needed
+Reviewed-By: 
+Last-Update: 2018-12-18
+
+diff --git a/translate/convert/po2web2py.py b/translate/convert/po2web2py.py
+index 07d61b358..c31f57fde 100755
+--- a/translate/convert/po2web2py.py
 b/translate/convert/po2web2py.py
+@@ -1,3 +1,4 @@
++#!/usr/bin/env python
+ # -*- coding: utf-8 -*-
+ #
+ # Copyright 2009-2010 Zuza Software Foundation
+@@ -24,7 +25,9 @@ See: http://docs.translatehouse.org/projects/translate-toolkit/en/latest/command
+ for examples and usage instructions.
+ """
+ 
+-from io import BytesIO
++import sys
++
++from io import StringIO
+ 
+ from translate.convert import convert
+ from translate.storage import factory
+@@ -36,7 +39,7 @@ class po2pydict(object):
+ return
+ 
+ def convertstore(self, inputstore, includefuzzy):
+-str_obj = BytesIO()
++str_obj = StringIO()
+ 
+ mydict = dict()
+ for unit in inputstore.units:
+@@ -49,29 +52,40 @@ class po2pydict(object):
+ # The older convention is to prefix with "*** ":
+ #mydict[unit.source] = '*** ' + unit.source
+ 
+-str_obj.write('{\n')
+-for source_str in mydict:
+-str_obj.write("%s:%s,\n" % (repr(str(source_str)), repr(str(mydict[source_str]
+-str_obj.write('}\n')
++str_obj.write(u'# -*- coding: utf-8 -*-\n')
++str_obj.write(u'{\n')
++for source_str, trans_str in sorted(mydict.items()):
++if sys.version_info[0] == 2:
++source_str = source_str.encode('utf-8')
++trans_str = trans_str.encode('utf-8')
++str_obj.write(u"%s: %s,\n" % (repr(source_str), repr(trans_str)))
++str_obj.write(u'}\n')
+ str_obj.seek(0)
+ return str_obj
+ 
+ 
+ def convertpy(inputfile, outputfile, templatefile=None, includefuzzy=False,
+-  outputthreshold=None):
++  outputthreshold=None, **kwargs):
+ inputstore = factory.getobject(inputfile)
+ 
+ if not convert.should_output_store(inputstore, outputthreshold):
+-return False
++return 0
+ 
+ convertor = po2pydict()
+ outputstring = convertor.convertstore(inputstore, includefuzzy)
+-outputfile.write(outputstring.read())
++
++if sys.version_info[0] == 2:
++outputfile.write(outputstring.read())
++elif sys.version_info[0] > 2:
++outputfile.write(bytes(outputstring.read(), 'utf-8'))
+ return 1
+ 
+ 
+ def main(argv=None):
+-formats = {("po", "py"): ("py", convertpy), ("po"): ("py", convertpy)}
++formats = {
++("po", "py"): ("py", convertpy),
++("po", None): ("py", convertpy)
++}
+ parser = convert.ConvertOptionParser(formats, usetemplates=False, description=__doc__)
+ parser.add_threshold_option()
+ parser.add_fuzzy_option()
+diff --git a/translate/convert/test_po2web2py.py b/translate/convert/test_po2web2py.py
+new file mode 100644
+index 0..7906a1230
+--- /dev/null
 b/translate/convert/test_po2web2py.py
+@@ -0,0 +1,55 @@
++# -*- coding: utf-8 -*-
++import sys
++
++from translate.convert import po2web2py
++from translate.misc import wStringIO
++from translate.storage import po
++
++
++class TestPO2WEB2PY(object):
++
++def po2web2py(self, po_source):
++"""helper that converts po source to web2py source without requiring files"""
++input_file = wStringIO.StringIO(po_source)
++input_po = po.pofile(input_file)
++convertor = po2web2py.po2pydict()
++output_web2py = convertor.convertstore(input_po, False)
++return output_web2py.read()
++
++def test_basic(self):
++"""test a basic po to web2py conversion"""
++input_po = '''#: .text
++msgid "A simple string"
++msgstr "Du texte simple"
++'''
++expected_web2py = '''# -*- coding: utf-8 -*-
++{
++'A simple string': 'Du texte simple',
++}
++'''
++web2py_out = self.po2web2py(input_po)
++assert web2py_out == expected_web2py
++
++def test_ordering_serialize(self):
++

Bug#916796: IEEEfull.bib: cannot be read in encoding 'utf8' by biber

[Hilmar Preuße]

On 25.12.18 03:00, Damir Islamov wrote:

Hi Damir,

> IEEEfull.bib wirks fine with bibtex.
> I will try to contact TeX group.
> 
So, I'll mark that bug for me as "submitter cares about the issue".
Please be so kind to call back, once you get an answer.

Many thanks!
  Hilmar
-- 
#206401 http://counter.li.org



signature.asc
Description: OpenPGP digital signature

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

[Luca Boccassi]

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/41b7e55f1c5a3cb93d
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

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

Bug#916231: Including sys/ioctl.h helps

[Sergei Golovan]

Hey Ralf,

Including sys/ioctl.h into ossp.h doesn't help as it is included into
osspd.c too late (sys/socket.h already did harm by undefining IOC_IN
and IOC_OUT).

But including sys/ioctl.h directly into osspd.c before sys/socket.h
works. Here is a possible patch:

--- a/osspd.c
+++ b/osspd.c
@@ -22,6 +22,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 

Hopefully, it won't cause damage for other architectures.

Cheers!
-- 
Sergei Golovan

Bug#917275: RM: racket [s390x] -- NBS; broken for 9 months

[David Bremner]

Package: ftp.debian.org
Severity: normal

Despite upstream's best efforts, we've not been able to get racket
working again on s390x after 6.12 broke it. At this point buster will
most likely have to release without s390x support for racket.

Bug#917241: libnss-unknown: Please provide more elaborate description in long description

[Ritesh Raj Sarraf]

On Tue, 2018-12-25 at 11:37 +0100, Petter Reinholdtsen wrote:
> [Ritesh Raj Sarraf]
> > + .
> > + This library is very useful in host <=> guest container build
> > + environments, where shifting UIDs/GIDs result in a mismatch in
> > + between
> 
> Did something fall out of this patch?  Could you perhaps also explain
> _how_ it is very useful, in addition to explaining in what context it
> is
> useful.

As I mentioned earlier, it is useful in an environment where you are
building packages in a containerized environment. In my case, the guest
environment is Docker. The host environment has Jenkins.

The library is useful if an admin shifts uid/gid ranges on the host,
resulting in a mismatch between the uids on the host and the guest.

AFAICS, this is mostly a problem with packages which are picky about
the uid mappings. Like, dbus, glib, systemd. If you are not building
such packages in a container environment (and your home/container
uids/gids are not shifted), you will not usually see this problem.


-- 
Ritesh Raj Sarraf | http://people.debian.org/~rrs
Debian - The Universal Operating System


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#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#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#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#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#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#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#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-