Thomas Pöhnitzsch | 20 Dec 17:11 2014

Bug#773596: gajim: fails to connect when doing kerberos authentication (no fallback to password prompt)

Package: gajim
Version: 0.16-1
Severity: normal

Dear Maintainer,

when I have a valid Kerberos TGT and start gajim, it fails to
connect to the xmpp-server but prints the following error:

Traceback (most recent call last):
  File "/usr/lib/python2.7/dist-packages/nbxmpp/", line 497, in
    handler['func'](session, stanza)
  File "/usr/lib/python2.7/dist-packages/nbxmpp/", line 304, in
  File "/usr/lib/python2.7/encodings/", line 16, in decode
    return codecs.utf_8_decode(input, errors, True)
UnicodeDecodeError: 'utf8' codec can't decode byte 0x81 in position 1: invalid
start byte

klist shows that it already obtained new tickets for the xmpp-server.

This same setup works fine on a system running debian 7.7 with gajim

If I remove my TGT and start gajim anew, it asks me for a password and then

(Continue reading)

Jakub Wilk | 20 Dec 16:58 2014

Bug#773595: qprint: bogus error message on invalid 2-byte escape sequence

Package: qprint
Version: 1.1.dfsg-1
Severity: minor

This is a variation of #773185 that is still not fixed in 1.1:

$ printf '=a' | qprint -d
Error: bad equal sign escape "= 0x61 0xFFFFFFFF" at byte 18446744073709551615 (0xFFFFFFFFFFFFFFFF) of input.

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

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

Versions of packages qprint depends on:
ii  libc6  2.19-13


Jakub Wilk

Jakub Wilk | 20 Dec 16:47 2014

Bug#773594: qprint: invalid sign escape still produces output

Package: qprint
Version: 1.0.dfsg.2-2
Severity: minor

Sometimes qprint -d produces output, even though the input consists 
entirely of invalid sign escapes:

$ printf '=m4' | qprint -d | hd
Error: bad equal sign escape "=m4" at byte 0 (0x0) of input.
00000000  f4                                                |.|

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

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

Versions of packages qprint depends on:
ii  libc6  2.19-13


Jakub Wilk

(Continue reading)

Maximilian Engelhardt | 20 Dec 16:43 2014

Bug#770659: seems to be related to using the Debian srtp library

I did some tests to track this down a bit.

starting chromium with "--enable-logging --v=4" I do get this in my 

[49:62:1219/] Installing keys from DTLS-SRTP on audio RTP
[49:62:1219/] Failed to init SRTP, err=5
[49:62:1219/] DTLS-SRTP key installation failed

So the problem seems to be somewhere in or related to srtp. I had a quick look 
at the corresponding code, but I'm not sure what is the problem there. The 
error message from my log comes from here:

and is the return value of the srtp_init() function from the srtp source here:

The functions crypto_kernel_init() and crypto_kernel_load_debug_module() can 
be found here:

I couldn't see any obvious problem there but I only had a very rough look at 
the code.

So suspecting this might be caused by the system srtp library I disabled it by 
removing "use_system_libsrtp=1" from the debian/rules file and got a chromium 
with working webrtc.
(Continue reading)

Timothy Davenport | 20 Dec 16:09 2014

Bug#701680: Confirmation Re: [djmount] Segfault when attempting to read a file

I don't know how to reply on the Debian Bug report logs.

I want to confirm that I too had segfaults using djmount on amd64.
Applying the patch suggested by Bernhard Übelacker
[004-avoid-crash-by-using-size_t.patch (text/x-patch, attachment)]
solved the problem for me.


Tim Davenport
Gatlinburg, Tennessee  USA

JS | 20 Dec 16:20 2014

Bug#772471: closed by Michael Gilbert <mgilbert <at>> (Re: Bug#772471: chromium crash on startup)

I would say that there is still a problem with debian packaging in that it allows this chromium version

to be installed in a kernel earlier than 2.16, although the result is of no value since the new chromium

will not work.

Perhaps for versions 39.0.2171 and higher of chromium, the debian package should also require a

kernel version at least 3.16. This would be a rigorous way of implementing the requirement that

people running into this problem should upgrade their kernel.

[ I was able to avoid this issue by patching the debian source to avoid this check, as it currently

does in for this version, and rebuilding on my 32 bit linux with the additional flags:

defines+= remove_webcore_debug_symbols=1 \
              component=shared_library \

although at some later point will have to upgrade my kernel to 3.16.]


----- Original Message -----
From: Debian Bug Tracking System <owner <at>>
To: js <jshaio <at>>
Sent: Friday, December 19, 2014 7:45 PM
(Continue reading)

Jakub Wilk | 20 Dec 16:13 2014

Bug#773593: missing source for qprint.c

Source: qprint
Version: 1.1.dfsg-1
Severity: serious
Justification: Policy §2.2

qprint.c was automatically generated from qprint.w, but the latter is 
not included in the .orig.tar.

NB, this is a regression: qprint.w is included in the source tarball for 


Jakub Wilk

Adrian | 20 Dec 15:32 2014

Bug#773592: systemd: /etc/rc.local compatibility

Package: systemd
Version: 215-7
Severity: normal

Dear maintainer

I get "failed to start /etc/rc.local compatibility" at boot.
Can I migrate from /etc/rc.local to systemd?

I have two similar rc.local.service files.

-- Package-specific info:

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

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

Versions of packages systemd depends on:
ii  acl             2.2.52-2
ii  adduser         3.113+nmu3
ii  initscripts     2.88dsf-58
ii  libacl1         2.2.52-2
ii  libaudit1       1:2.4-1+b1
(Continue reading)

Michael Hanke | 20 Dec 15:23 2014

Bug#773589: additional information (baobab does not show mounted devices)

I just noticed that if I start baobab with sudo, I can see those 
partitions which are mounted in /media or have mountoption user in fstab.

Further investigation showed up that this even works if I start baobab 
with sudo -u <user> where <user> is the same as logged in, so it is 
obvious that it has to do something with the environment:

If I unset DBUS_SESSION_BUS_ADDRESS before starting baobab it works with 
all partitions with option 'user' or 'users' in fstab (not works if they 
are mounted with 'default')

Hope that helps.

Michael Tokarev | 20 Dec 13:45 2014

Bug#773591: new patch(1) in jessie refuses to work on symlinks

Package: patch
Version: 2.7.1-6
Severity: important

patch(1) utility in jessie refuses to work on symlinks.  When the file
to be patched is a symlink, it produces the following error message:

  File FOO is not a regular file -- refusing to patch
  1 out of 1 hunk ignored -- saving rejects to file FOO.rej

This makes patch(1) basically useless for many our users.

The problem is that our workflow is hugely based around "local patching"
of symlinked trees.  For example, given an original linux kernel source
tree, symlink it to a temp directory (maybe on a separate tmpfs) apply some
local patch and build it (with ccache).

wheezy version of patch(1) just replaced a symlink with a patched
file and all was well.  jessie version just refuses to work.

For now I downgraded patch(1) package to the one from wheezy and added
an apt-preferencs pin for it.



Dmitry Shachnev | 20 Dec 14:25 2014

Bug#773590: g++-4.9: incorrectly compiles moc on sparc

Package: g++-4.9
Version: 4.9.2-8
Control: affects -1 src:qtbase-opensource-src

Dear gcc maintainers,

In qtbase-opensource-src 5.4.0+dfsg, src/tools/moc/main.cpp contains the following code:

    if (output.size()) { // output file specified
        out = fopen(QFile::encodeName(output).constData(), "w"); // create output file
        if (!out)
            fprintf(stderr, "moc: Cannot create %s\n", QFile::encodeName(output).constData());
            return 1;
    } else { // use stdout
        out = stdout;

However, when moc is compiled, it behaves very strangely in this place:

* fopen does not seem to be called at all (at least there is no corresponding
  open syscall in strace output), so `out' remains a null pointer.
* Only the "%s\n" part is printed to stderr, without the "moc: Cannot create "

An example can be seen in qtbase-opensource-src/experimental build log.
A relevant part of it (simplified):

    ../bin/moc animation/qabstractanimation.h -o .moc/moc_qabstractanimation.cpp
(Continue reading)