Bug#807383: gcc-doc: Manpage documentation of -l is incorrect

2015-12-08 Thread Dima Kogan
Package: gcc-doc
Version: 5:4.9.2-1
Severity: normal

Hi. This relates to several details of linking, and I'm not sure if this
is a Debian or upstream bug.

The 'gcc' manpage says this:

   -llibrary
   ...
   The linker searches a standard list of directories for the
   library, which is actually a file named liblibrary.a. The
   linker then uses this file as if it had been specified
   precisely by name.
   ...
   Normally the files found this way are library files---archive
   files whose members are object files. ...

This is not what actually happens. For instance, I have libarpack2-dev
installed. This ships both libarpack.a and libarpack.so. I build a
simple application like this:

$ gcc -o tst -larpack tst.c

Using strace to see what files are actually opened, I see this:

[pid 13833] open("/usr/lib/gcc/x86_64-linux-gnu/5/libarpack.so", O_RDONLY) = -1 
ENOENT (No such file or directory)
[pid 13833] open("/usr/lib/gcc/x86_64-linux-gnu/5/libarpack.a", O_RDONLY) = -1 
ENOENT (No such file or directory)
[pid 13833] 
open("/usr/lib/gcc/x86_64-linux-gnu/5/../../../x86_64-linux-gnu/libarpack.so", 
O_RDONLY) = -1 ENOENT (No such file or directory)
[pid 13833] 
open("/usr/lib/gcc/x86_64-linux-gnu/5/../../../x86_64-linux-gnu/libarpack.a", 
O_RDONLY) = -1 ENOENT (No such file or directory)
[pid 13833] 
open("/usr/lib/gcc/x86_64-linux-gnu/5/../../../../lib/libarpack.so", O_RDONLY) 
= 9
[pid 13833] 
open("/usr/lib/gcc/x86_64-linux-gnu/5/../../../../lib/libarpack.so", O_RDONLY) 
= 10

So in each path in the list we look for the .so and then the .a. The
manpage however implies that we only look for the .a, and while we DO
look for it, this isn't the first choice.



Bug#807371: apt hostname resoloution failure

2015-12-08 Thread Julian Andres Klode
Control: severity -1 normal

On Tue, Dec 08, 2015 at 03:17:32AM +, peter green wrote:
> Package: apt
> Version: 1.1.3
> Severity: grave

It works everywhere else, including the buildds, so I'm downgrading
this to normal, as it must be a configuration issue on your side.

> 
> When running apt in a Debian stretch armhf chroot on my odriod u2 DNS
> resoloution fails. ping is able to resolve the hostname.

ping runs as root, the apt methods run as _apt.

> 
> root@odroidu2:/# apt-get update
> Err:1 http://mirror.bytemark.co.uk/debian stretch InRelease
>   Could not resolve 'mirror.bytemark.co.uk'
> Reading package lists... Done
> W: Failed to fetch
> http://mirror.bytemark.co.uk/debian/dists/stretch/InRelease  Could not
> resolve 'mirror.bytemark.co.uk'
> W: Some index files failed to download. They have been ignored, or old ones
> used instead.
> root@odroidu2:/# ping mirror.bytemark.co.uk
> PING mirror.bytemark.co.uk (212.110.161.69) 56(84) bytes of data.
> 64 bytes from mirror.bytemark.co.uk (212.110.161.69): icmp_seq=1 ttl=57
> time=20.8 ms
> 
> The chroot is on a host system running a vendor 3.0.90 kernel, no idea if
> that is relavent. At the very least if there is a problem running on older
> kernels there should be a warning before the updated packages are installed.
> 
> The issue seems to be new in the 1.1 series of apt versions.
> 
> The issue definately seems to be somehow related to dns lookups. If I add
> the hostname to /etc/resolv.conf then apt seems to work.
> 

You might want to try running the ping as the _apt user and check
if that works. Maybe the _apt user does not have access to 
/etc/resolv.conf?

-- 
Julian Andres Klode  - Debian Developer, Ubuntu Member

See http://wiki.debian.org/JulianAndresKlode and http://jak-linux.org/.

When replying, only quote what is necessary, and write each reply
directly below the part(s) it pertains to (`inline'). Thank you.



Bug#801784:

2015-12-08 Thread 林毅駿



Bug#805434: u-boot-tools: -T multi -d file1:file2:file3 no longer works

2015-12-08 Thread Nye Liu
On 12/6/2015 4:18 PM, Vagrant Cascadian wrote:
> It looks like this may be fixed upstream:
> 
> http://git.denx.de/?p=u-boot.git;a=commit;h=6ae6e16005252dbca0b4a06beea1be895df48e16
>
>
> Would you be able to confirm that the upstream patch fixes your
> issue? If it does, I'll be happy to include it in the next upload 
> to unstable.

It appears to be basically the same as my patch, so, yes, it should
work.. I don't generally build from upstream source, but applying
this patch to the deb src directly seems to work fine.

Thanks!



Bug#807097: [Pkg-linaro-lava-devel] Bug#807097: [Python-modules-team] Bug#807097: python-django: Undeclared removal of previously supported features causes crashes

2015-12-08 Thread Senthil Kumaran S


On Tuesday 08 December 2015 01:04 PM, Brian May wrote:
>>> From your stack trace it would appear that the calling application -
>>> django-hijack - doesn't actually use add_to_builtins, however it uses
>>> the file from django-compat that tries to import the symbol anyway.
>>
>> ARRRGGHHH! OK, that looks like hijack should test the import more
>> carefully to identify the right support.
> 
> Think the problem is in django-compat, not django-hijack???
> 
> Somebody needs to package the latest django-compat, and this problem
> should go away.

I shall take it up today.

Thank You.
-- 
Senthil Kumaran S
http://www.stylesen.org/
http://www.sasenthilkumaran.com/



signature.asc
Description: OpenPGP digital signature


Bug#786481: Please apply patch to jessie

2015-12-08 Thread Christian Salzmann

Dear package maintainers,

> Does this bugfix qualify for the next point release?

I suppose the proposed patch has matured sufficiently.
There would be an opportunity to fix this bug in the upcoming point release [1].
I know the timing is a bit optimistic and we all are approaching the end of the 
year faster than we would like to,
but maybe I could politely ask to include the patch in the next point release?

ciao
Christian


[1] https://lists.debian.org/debian-release/2015/12/msg00050.html


-- 
Christian Salzmann christian.salzm...@fu-berlin.de
IT-Dienst  Takustraße 9, 14195 Berlin
Fachbereich Mathematik und Informatik  http://www.mi.fu-berlin.de
Freie Universität Berlin




smime.p7s
Description: S/MIME Cryptographic Signature


Bug#807380: Regression for 'PKCS11Provider libsimple-tpm-pk11.so' - ignoring uninitialised token in slot 0

2015-12-08 Thread Didier 'OdyX' Raboud
Package: openssh-client
Version: 1:7.1p1-1
Severity: important

Hi,

I'm using the following SSH config to use my X220's TPM through
simple-tpm-pk11:

> Host test
>   PKCS11Provider libsimple-tpm-pk11.so

Working authentication:
> OpenSSH_6.9p1 Debian-3, OpenSSL 1.0.2e 3 Dec 2015
> …
> debug1: manufacturerID  cryptokiVersion 0.1 
> libraryDescription  libraryVersion 0.1
> debug1: label  manufacturerID  model  
> serial  flags 0x0
> debug1: have 1 keys
> …

Failing authentication:
> OpenSSH_7.1p1 Debian-1, OpenSSL 1.0.2e 3 Dec 2015
> …
> debug1: manufacturerID  cryptokiVersion 0.1 
> libraryDescription  libraryVersion 0.1
> debug2: pkcs11_add_provider: ignoring uninitialised token in slot 0
> no keys
> …

I haven't found a configuration stanza in ssh_config(5) that could solve that,
I'm therefore bound to assume it's a regression in how openssh-client and
libsimple-tpm-pk11.so interact.

Cheers, OdyX

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

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

Versions of packages openssh-client depends on:
ii  adduser   3.113+nmu3
ii  dpkg  1.18.3
ii  libc6 2.21-3
ii  libedit2  3.1-20150325-1+b1
ii  libgssapi-krb5-2  1.13.2+dfsg-4
ii  libselinux1   2.4-3
ii  libssl1.0.2   1.0.2e-1
ii  passwd1:4.2-3.1
ii  zlib1g1:1.2.8.dfsg-2+b1

Versions of packages openssh-client recommends:
ii  xauth  1:1.0.9-1

Versions of packages openssh-client suggests:
pn  keychain   
ii  ksshaskpass [ssh-askpass]  4:5.4.3-1
pn  libpam-ssh 
pn  monkeysphere   
ii  ssh-askpass1:1.2.4.1-9

-- no debconf information



Bug#807384: Realmd crashes when trying to join a FreeIPA domain

2015-12-08 Thread Marius Vollmer
Package: realmd
Version: 0.15.1-1+b2

Hi,

realmd is misconfigured in such a way that it crashes when trying to
join a FreeIPA domain.

It produces messages like this:

 ** (realmd:4770): CRITICAL **: No section found in settings: ipa-packages

and also segfaults.

To fix the crash one can include a empty [ipa-packages] section in
/usr/lib/realmd-default.conf but that of course doesn't make joining
work since ipa-client-install is not yet available outside of unstable
(I think).

A correct configuration would have this in realmd-distro.conf, I think:

  [providers]
  sssd = no



Bug#807364: RFP: supercollider-sc3-plugins -- Community collection of UGen plugins for SuperCollider

2015-12-08 Thread Hanno Zulla
Hi,

> A draft package is available from
>  http://ppa.launchpad.net/sonic-pi/ppa/ubuntu/pool/main/s/supercollider-sc3-plugins/
>  >

That draft package is a first packaging attempt. I intended to make it
acceptable for to the Debian archive, but it isn't ready yet. Help is
appreciated, as Debian compliance is a major goal for this packaging
attempt.

Status:

The plugins are maintained at
https://github.com/supercollider/sc3-plugins

The source package contains two convenience copies of code.

  1) libstk

  Which has been packaged by Debian, but with a bug that makes it
  unusable for compiling sc3-plugins with it.

  I have filed a bug at
  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=805549
  and the Debian Multimedia team has published an update (thanks!)
  which I haven't tested, yet.

  2) nova-simd

  Which has not been packaged by Debian yet. nova-simd is also
  contained as a convenience copy in the main supercollider Debian
  source package.

The current sc3-plugins release 3.7.0-alpha1 has a bug that has been
fixed in the git master version, see
https://github.com/supercollider/sc3-plugins/issues/45
for details. The developers plan to push out a new release soon.

Regards,

Hanno



Bug#798121: Successfully tested patch

2015-12-08 Thread Sébastien NOBILI
Hi,

Just to notice that the patch Heinrich Schuchardt submitted works for me (Debian
Jessie).

Sébastien



Bug#807382: base: 32-bit kernel does not see all network interfaces under Hyper-V (eg. 6 out of 8)

2015-12-08 Thread Pavel Stepanek
Package: base
Severity: normal

Dear Maintainer,
*** Please consider answering these questions, where appropriate ***

   * What led up to the situation?
Just run debian installer package (netinst) of any 32-bit version under Hyper-V 
with 8 network interfaces attached (not legacy one)
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
You can see just few of maximum of 8 interfaces. This does not happen on 64-bit 
installation / kernel.
   * What was the outcome of this action?
   * What outcome did you expect instead?
You can see all network interfaces.


-- System Information:
Debian Release: 7.9
  APT prefers oldstable-updates
  APT policy: (500, 'oldstable-updates'), (500, 'oldstable')
Architecture: i386 (i686)

Kernel: Linux 3.2.0-4-686-pae (SMP w/1 CPU core)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash



Bug#800574: Bug#807244: libegl1-nvidia: Programs crash due to elisian-unlock on skylake processor with nvidia driver 352.63-1 (experimental)

2015-12-08 Thread Aurelien Jarno
Hi,

On 2015-12-07 23:26, Andreas Beckmann wrote:
> Dear libc maintainers,
> 
> we recently got a bug report regarding the TSX-NI / lock elision bug in
> combination with the non-free nvidia driver (#807244). Since that is
> supposed to be fixed with the libc in experimental (and now sid as
> well), perhaps you could take a look why this still happens.
> Several forum posts denote that "compiling glibc without
> --enable-lock-elision" works around that issue.

I disagree it is supposed to be fixed. Intel got a few bugs in there
TSX-NI implementation for Haswell and Broadwell and possibly early
versions of Skylake, and to avoid data loss we have therefore disabled
lock elision for some CPU revisions. That said the bugs in the Intel
implementation are corner cases, and it took quite some time for them to
get discovered. If your program crashes reproducibly, it's definitely not
an issue with the TSX-NI implementation. Disabling --enable-lock-elision
it's just a workaround for the real issue. People now start to have CPUs
with a working TSX-NI implementation which is therefore not blacklisted
and thus the problem is appearing again.

> A few ideas from my side, but since I don't have the hardware to test, I
> cannot check anything:
> * that specific CPU needs to be blacklisted / is incorrectly whitelisted

As said above that couldn't be that.

> * nvidia utilizes a code path in libc that is not covered by the current
> patch (and that code path is not used by any other application)
> * nvidia does call something it shouldn't call directly ... thus
> circumenting the runtime-disabling of the specific routines in libc6

According to the backtrace the problem is typical of a call to
mutex_unlock() on a mutex which hasn't been locked with mutex_lock()
before. Nvidia should fix the bug there.

> * nvidia code does issue the problematic instructions itself (but the
> backtrace points to libc, so this sounds unlikely)
> 
> Is there some way to check at runtime how lock elision is handled by
> libc (on a concrete system)?

What do you mean by "how is it handled"? I have attached a small program
which demonstrate the issue. You can use it to check if your system is
using lock elision or not. Running this program with ltrace it's quite
easy the call to an already unlocked mutex. I wonder if it's doable to
do the same with the whole Nvidia stack.

Aurelien

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net
/* compile with gcc -o mutex_crash_tsx mutex_crash_tsx.c -lpthread */

#include 

int main()
{
pthread_mutex_t m =  PTHREAD_MUTEX_INITIALIZER;
pthread_mutex_lock();
pthread_mutex_unlock();
pthread_mutex_unlock();
}


Bug#807150: gubbins: FTBFS on i386: Invalid ALN file for multiple lines per seq

2015-12-08 Thread Andrew Page
Thanks,
Andrew

> On 6 Dec 2015, at 06:40, Andreas Tille  wrote:
> 
> Hi Andrew,
> 
> I hereby forward a build issue on i386 architecture.
> 
> Kind regards
> 
>   Andreas.
> 
> On Sat, Dec 05, 2015 at 10:30:32PM -0500, Aaron M. Ucko wrote:
>> Source: gubbins
>> Version: 1.4.3-1
>> Severity: important
>> Justification: fails to build from source
>> 
>> The i386 build of gubbins failed:
>> 
>>  FAIL: run_all_tests
>>  
>>  Testsuite summary for gubbins 1.4.3
>>  
>>  # TOTAL: 1
>>  # PASS:  0
>>  # SKIP:  0
>>  # XFAIL: 0
>>  # FAIL:  1
>>  # XPASS: 0
>>  # ERROR: 0
>>  
>>  See src/test-suite.log
>> 
>> I was able to reproduce the error in an i386 chroot, yielding the following
>> details:
>> 
>>  FAIL: run_all_tests
>>  ===
>> 
>>  Running suite(s): Creating_SNP_Sites
>>   Parsing a phylip file
>>   Parsing a vcf file
>>   checking branch sequences
>>   Checking the gubbins functionality
>>   snp_searching
>>  94%: Checks: 39, Failures: 2, Errors: 0
>>  
>> ../tests/check_snp_sites.c:73:F:snp_sites:valid_alignment_with_multiple_lines_per_sequence:0:
>>  Invalid ALN file for multiple lines per seq
>>  ../tests/check_snp_sites.c:85:F:snp_sites:two_sequences:0: Invalid ALN file 
>> for multiple lines per seq
>>  FAIL run_all_tests (exit status: 1)
>> 
>> Could you please take a look?
>> 
>> Thanks!
>> 
>> ___
>> Debian-med-packaging mailing list
>> debian-med-packag...@lists.alioth.debian.org
>> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-med-packaging
>> 
> 
> -- 
> http://fam-tille.de



--
 The Wellcome Trust Sanger Institute is operated by Genome Research
 Limited, a charity registered in England with number 1021457 and a
 company registered in England with number 2742969, whose registered
 office is 215 Euston Road, London, NW1 2BE.



Bug#807097: [Pkg-linaro-lava-devel] Bug#807097: [Python-modules-team] Bug#807097: python-django: Undeclared removal of previously supported features causes crashes

2015-12-08 Thread Neil Williams
reassign 807097 django-compat
found 807097 1.0.7-2
affects 807097 + python-django-hijack
thanks

On Tue, 8 Dec 2015 13:41:16 +0530
Senthil Kumaran S  wrote:

> On Tuesday 08 December 2015 01:04 PM, Brian May wrote:
> >>> From your stack trace it would appear that the calling
> >>> application - django-hijack - doesn't actually use
> >>> add_to_builtins, however it uses the file from django-compat that
> >>> tries to import the symbol anyway.  
> >>
> >> ARRRGGHHH! OK, that looks like hijack should test the import more
> >> carefully to identify the right support.  
> > 
> > Think the problem is in django-compat, not django-hijack???

Yes, hijack could be more careful about the test it uses for compat -
it can check for an available import without actually importing it.

> > Somebody needs to package the latest django-compat, and this problem
> > should go away.  
> 
> I shall take it up today.

Thanks, Senthil. Reassigning to django-compat so that a new upstream
release of django-compat can be uploaded with django1.9 support.

-- 


Neil Williams
=
http://www.linux.codehelp.co.uk/



pgpfOO4b1Atky.pgp
Description: OpenPGP digital signature


Bug#807379: kde-full: kdeinit, plasmashell crashes connected with libthread_db.so.1

2015-12-08 Thread Maciej Kotliński
Package: kde-full
Version: 5:90
Severity: grave
Justification: causes non-serious data loss

I've got numerous crasches connected with libthread_db.so.1. The most
problematic are crashes of kdeinit. When I suspend to RAM and resume, I should
get password prompt screen. Instead of that I usually get the screen with
active windows without title bars (looks like kwin not working). Visible
windows are functional, one can watch and modify its content it is also a
security thread.
I have to restart KDE to get system usable (going to init 3 and then init 5).

There is more crashing apps. Kwin stops quite frequently (windows without
titlebars, etc.) but it can be started manually.
I observe also crashes of other KDE apps like Dolpin, Konsole all connected
with libthread_db.so.1.

The crashes of kwin are usually connected with changing monitor setup. I work
with laptop and two external monitors at work (connected to DisplayPort and
D-SUB). When i connect or disconnect external monitors kwin usually crashes.
Application: kdeinit5 (kdeinit5), signal: Segmentation fault
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[KCrash Handler]
#6  0x7f0403eb928e in QXcbScreen::mapToNative(QRect const&) const () from 
/usr/lib/x86_64-linux-gnu/libQt5XcbQpa.so.5
#7  0x7f0403ebe463 in QXcbWindow::mapToNative(QRect const&, QXcbScreen 
const*) const () from /usr/lib/x86_64-linux-gnu/libQt5XcbQpa.so.5
#8  0x7f0403ebfc5b in QXcbWindow::propagateSizeHints() () from 
/usr/lib/x86_64-linux-gnu/libQt5XcbQpa.so.5
#9  0x7f0403ec4dec in QXcbWindow::setGeometry(QRect const&) () from 
/usr/lib/x86_64-linux-gnu/libQt5XcbQpa.so.5
#10 0x7f04164da9ef in QWidgetPrivate::setGeometry_sys(int, int, int, int, 
bool) () from /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5
#11 0x7f04164db5a0 in QWidget::setGeometry(QRect const&) () from 
/usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5
#12 0x7f0417a5873a in QMetaObject::activate(QObject*, int, int, void**) () 
from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#13 0x7f04164f956e in QDesktopWidget::resized(int) () from 
/usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5
#14 0x7f04164faa18 in ?? () from 
/usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5
#15 0x7f0417a5873a in QMetaObject::activate(QObject*, int, int, void**) () 
from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#16 0x7f0417d62132 in QGuiApplication::screenAdded(QScreen*) () from 
/usr/lib/x86_64-linux-gnu/libQt5Gui.so.5
#17 0x7f0403eabe29 in 
QXcbConnection::updateScreens(xcb_randr_notify_event_t const*) () from 
/usr/lib/x86_64-linux-gnu/libQt5XcbQpa.so.5
#18 0x7f0403eac923 in QXcbConnection::handleXcbEvent(xcb_generic_event_t*) 
() from /usr/lib/x86_64-linux-gnu/libQt5XcbQpa.so.5
#19 0x7f0403eacd83 in QXcbConnection::processXcbEvents() () from 
/usr/lib/x86_64-linux-gnu/libQt5XcbQpa.so.5
#20 0x7f0417a59601 in QObject::event(QEvent*) () from 
/usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#21 0x7f041649fffc in QApplicationPrivate::notify_helper(QObject*, QEvent*) 
() from /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5
#22 0x7f04164a54c6 in QApplication::notify(QObject*, QEvent*) () from 
/usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5
#23 0x7f0417a29bcb in QCoreApplication::notifyInternal(QObject*, QEvent*) 
() from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#24 0x7f0417a2bfc6 in QCoreApplicationPrivate::sendPostedEvents(QObject*, 
int, QThreadData*) () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#25 0x7f0417a7ff73 in ?? () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#26 0x7f04145ccfe7 in g_main_context_dispatch () from 
/lib/x86_64-linux-gnu/libglib-2.0.so.0
#27 0x7f04145cd240 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#28 0x7f04145cd2ec in g_main_context_iteration () from 
/lib/x86_64-linux-gnu/libglib-2.0.so.0
#29 0x7f0417a8037f in 
QEventDispatcherGlib::processEvents(QFlags) () 
from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#30 0x7f0417a2735a in 
QEventLoop::exec(QFlags) () from 
/usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#31 0x7f0417a2f43c in QCoreApplication::exec() () from 
/usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#32 0x7f0405cb31e6 in kdemain () from 
/usr/lib/x86_64-linux-gnu/libkdeinit5_ksmserver.so
#33 0x004085a6 in ?? ()
#34 0x00409e79 in ?? ()
#35 0x0040a50f in ?? ()
#36 0x004050ac in main ()
Application: Plazma (plasmashell), signal: Segmentation fault
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[Current thread is 1 (Thread 0x7f1925016940 (LWP 14437))]

Thread 8 (Thread 0x7f19100b6700 (LWP 14439)):
#0  0x7f191f76d52d in poll () at ../sysdeps/unix/syscall-template.S:81
#1  0x7f192380f252 in ?? () from /usr/lib/x86_64-linux-gnu/libxcb.so.1
#2  0x7f1923810ddf in xcb_wait_for_event () from 
/usr/lib/x86_64-linux-gnu/libxcb.so.1
#3  0x7f19113ac569 in ?? () from /usr/lib/x86_64-linux-gnu/libQt5XcbQpa.so.5
#4  0x7f191fe5987e in ?? () 

Bug#807374: libc-bin: localedef - Add EXAMPLES section to manual page

2015-12-08 Thread Aurelien Jarno
control: reassign manpages
control: retitle 807374 localedef.1: Add EXAMPLES section to manual

On 2015-12-08 06:13, Jari Aalto wrote:
> Package: libc-bin
> Version: 2.19-22
> Severity: wishlist
> 
> Please add EXAMPLES section to manual page demonstrating usage.
> Like:
> 
>   localedef -i en_US -c -f UTF-8 -A /usr/share/locale/locale.alias en_US.UTF-8
> 

This is the wrong package, this manpages comes from the manpages
package. Reassigning the bug.

Aurelien

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net



Bug#807381: Please enable smtp tls in Debian default configuration

2015-12-08 Thread Martin Wuertele
Package: postfix
Version: 2.11.3-1
Severity: wishlist

Could you please enable smtp tls alongside smtpd tls in Debians default
configuration by e.g. adding 

smtp_use_tls = yes
smtp_dns_support_level = dnssec
smtp_tls_security_level = dane
smtp_tls_note_starttls_offer = yes
smtp_tls_cert_file=/etc/ssl/certs/ssl-cert-snakeoil.pem
smtp_tls_key_file=/etc/ssl/private/ssl-cert-snakeoil.key

to /usr/share/postfix/main.cf.tls

Yours Martin



Bug#807358: locales: /usr/sbin/locale-gen: line 62: 31200 Killed (64 Mb RAM)

2015-12-08 Thread Aurelien Jarno
control: tag -1 + moreinfo

On 2015-12-07 22:57, Jari Aalto wrote:
> Package: locales
> Version: 2.19-22
> Severity: important
> 
> Unable to install package "locales" or generate locales manually on
> x86 with 64 Mb and plenty of free swap. Output of htop(1):
> 
>   CPU[|||  11.1%] Tasks: 38, 0 
> thr; 1 running
>   Mem[|||29/56MB] Load average: 
> 0.17 2.59 2.14
>   Swp[||21/760MB] Uptime: 634 
> days(!), 20:34:35
>  
> 
>   $ locale-gen
>   Generating locales (this might take a while)...
>   en_US.UTF-8.../usr/sbin/locale-gen: line 62: 31200 Killed
> localedef -i $input -c -f $charset -A /usr/share/locale/locale.alias 
> $locale
>  done
>  Generation complete.
> 
> System has only en_US.UTF-8 activated:
> 
>  $ grep -v '#' /etc/locale.gen
>  en_US.UTF-8 UTF-8
> 
> Debug listing:
> 
> 
>   $ sh -x locale-gen
>   [...]
>   + '[' -f /usr/local/share/i18n/locales/en_US ']'
>   + localedef -i en_US -c -f UTF-8 -A /usr/share/locale/locale.alias 
> en_US.UTF-8
>   /usr/sbin/locale-gen: line 62: 31157 Killed  localedef -i 
> $input -c -f $charset -A /usr/share/locale/locale.alias $locale
>   + :
>   + echo ' done'
> done
>   [...]
>   Killed
> 
> Manual try:
> 
>   $ localedef -i en_US -c -f UTF-8 -A /usr/share/locale/locale.alias 
> en_US.UTF-8
>   <... time passes>
>   Killed

localedef definitely needs more than 64MB of RAM, that said with
760MB swap it should run fine.

If the program gets killed, there is not a lot we can do on the libc
side, that's clearly a problem on your system.

> I don't have possibilities to install any trace tools in this low
> memory system.

I guess you can get some information from the kernel (using dmesg) about
why localedef gets killed. You should also look how the overcommit is
configured on your system:

https://www.kernel.org/doc/Documentation/vm/overcommit-accounting

Aurelien

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net



Bug#807323: gparted needs policykit-1 but its neither in depends or recommends

2015-12-08 Thread shirish शिरीष
at bottom :-

On 08/12/2015, Phillip Susi  wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
>
> On 12/07/2015 11:57 AM, shirish शिरीष wrote:
>> Yup, have udisks2 installed.
>
> Just to confirm, can you run /usr/lib/udisks2/udisks2-inhibit and
> verify that you get that error?

Philip,

You would have to share the whole command, because I'm not so familiar
with udisks2-inhibit. I tried to see if there was a manpage or
something but came up nada :(

>
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1
>
> iQEcBAEBCgAGBQJWZiC8AAoJEBB5UWFcu6UWdjoH/R9bl1ScxaDvNw0dAw5hYTjQ
> xVOJ/zbk9DiC11H4xrPC2sLCKlomQnP9Vd7OFbVgX7tOZs0ANly270/VuB1nzqlv
> AtfkOy1NEyoAuUXvLPh8CR/kV4a81qFej2wuh+PuyJuUyvBy4/pcSLkcWBvYCkQD
> cQZzzXFtxE44u7M3tWr3odYWcg0S7vduUVg12GmnB6yqZYTIVFmjv5FUo/S8IXFW
> Sw8WLE3Vzl/m8lLKjeh9Xk3whdcAoLWVpTUC5zbC5pCUw2/qGBUrEwR6hbYWDbim
> 9FSAnBHydoE8L+cDEh8mOl1IHLoqnWp7JdF0JWWFSZ58qFfAe6iGxGFU12x0xUQ=
> =t2mk
> -END PGP SIGNATURE-
>


-- 
  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#807380: Regression for 'PKCS11Provider libsimple-tpm-pk11.so' - ignoring uninitialised token in slot 0

2015-12-08 Thread Colin Watson
Control: reassign -1 simple-tpm-pk11

On Tue, Dec 08, 2015 at 09:34:07AM +0100, Didier 'OdyX' Raboud wrote:
> I'm using the following SSH config to use my X220's TPM through
> simple-tpm-pk11:
> 
> > Host test
> > PKCS11Provider libsimple-tpm-pk11.so
> 
> Working authentication:
> > OpenSSH_6.9p1 Debian-3, OpenSSL 1.0.2e 3 Dec 2015
> > …
> > debug1: manufacturerID  cryptokiVersion 0.1 
> > libraryDescription  libraryVersion 0.1
> > debug1: label  manufacturerID  model 
> >  serial  flags 0x0
> > debug1: have 1 keys
> > …
> 
> Failing authentication:
> > OpenSSH_7.1p1 Debian-1, OpenSSL 1.0.2e 3 Dec 2015
> > …
> > debug1: manufacturerID  cryptokiVersion 0.1 
> > libraryDescription  libraryVersion 0.1
> > debug2: pkcs11_add_provider: ignoring uninitialised token in slot 0
> > no keys
> > …
> 
> I haven't found a configuration stanza in ssh_config(5) that could solve that,
> I'm therefore bound to assume it's a regression in how openssh-client and
> libsimple-tpm-pk11.so interact.

This is because of the fix in
https://bugzilla.mindrot.org/show_bug.cgi?id=2427 - OpenSSH now checks
whether the token is initialised, but simple-tpm-pk11 doesn't set that
flag.  This is essentially the same as
https://github.com/ThomasHabets/simple-tpm-pk11/issues/13.  I think that
cherry-picking this commit would do it, or simply upgrading to
simple-tpm-pk11 0.04:

  
https://github.com/ThomasHabets/simple-tpm-pk11/commit/bd8202d0f270e02e89b7df84c7373fbe1ace3e9e

Cheers,

-- 
Colin Watson   [cjwat...@debian.org]



Bug#807310: RFS: network-manager-ssh/0.9.4-1 [ITP] - ssh vpn for network manager

2015-12-08 Thread Paul Wise
On Tue, 2015-12-08 at 08:45 +, Lennart Weller wrote:

> I know it's weird and somewhat unusual but all the other nm plugins do the 
> same. So I went with it:

Hmm, ok.

> So I guess the icon went x -> pptp -> openvpn -> ssh. 

Please do ask upstream about it.

> Most of them seem alright to me. 

Examples of what I mean: dz.po ug.po sl.po ro.po ps.po pa.po nb.po

> inetnum:1.1.1.0 - 1.1.1.255
...
> I know you are not supposed to use these. But the test is not executed and 
> won't be unless upstream changes it as it is useless right now.

I hadn't caught this issue, woops.

I was referring to this in test/Vagrantfile:

  config.vm.network :private_network, ip: "33.33.33.10"

> Following the links on the page it seems to be mostly used by scientific 
> libraries to reference algorithms used in the packages. All the basic 
> repository/issue/copyright information is already present in other files
> in my current version.

It isn't about scientific references, that is a common misconception.

At least these fields are probably applicable:

Bug-*
Changelog
Contact
Name
Repository
Repository-Browse
Screenshots
Security-Contact

-- 
bye,
pabs

https://wiki.debian.org/PaulWise




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


Bug#807310: RFS: network-manager-ssh/0.9.4-1 [ITP] - ssh vpn for network manager

2015-12-08 Thread Lennart Weller
Thank you for the extensive review. I went through your suggestions/comments 
and either fixed them or mentioned them here.

> I don't think the package descriptions should describe NetworkManager,
> that is a job for the network-manager package description. Instead,
> they should describe the network-manager-ssh packages.

I know it's weird and somewhat unusual but all the other nm plugins do the 
same. So I went with it:
http://anonscm.debian.org/cgit/pkg-utopia/network-manager-openvpn.git/tree/debian/control
http://anonscm.debian.org/cgit/pkg-utopia/network-manager-pptp.git/tree/debian/control
http://anonscm.debian.org/cgit/pkg-utopia/network-manager-vpnc.git/tree/debian/control

> It would be great if there were a DEP-8 test:
> 
> http://dep.debian.net/deps/dep8
> http://ci.debian.net

This would definitely be a nice-to-have but it would require a decent test in 
the source package or writing one myself. As of now the test under test/ really
doesn't do much. It basically just setups the env to actually start testing. 
So I'd say its more of a long term goal.

> I always wonder if screenshots like images/*.png should be generated
> at build time so they never get out of date.

Screenshots don't change all that often and even if they are slightly 
out-of-date 
most people won't care. I'd say many just check the screenshots to check if its
a GTK1 application last maintained in the 90s.

> I wonder what "PCF" in the icon means, probably it would be better to
> have "SSH" in there?

The icon seems to be from nm-pptp. But even there it doesn't really make sense.
So I guess the icon went x -> pptp -> openvpn -> ssh. 

> Upstream's po files look like they have poorly maintained or
> unmaintained copyright headers.

Most of them seem alright to me. A few have missing source package information 
but that information is available in debian/copyright anyhow. The translators 
seem
to be attributed in all of them.

> Upstream's test suite is using an IP address belonging to the USA
> Department of Defence. I would strongly suggest using a proper private
> IP address according to RFC 6761.
> 
> http://tools.ietf.org/html/rfc6761

inetnum:1.1.1.0 - 1.1.1.255
netname:APNIC-LABS
descr:  Research prefix for APNIC Labs
address:South Brisbane, QLD 4101
address:Australia
e-mail: ab...@apnic.net

I know you are not supposed to use these. But the test is not executed and 
won't be unless upstream changes it as it is useless right now.

> Please add some upstream metadata:
> 
> https://wiki.debian.org/UpstreamMetadata

Following the links on the page it seems to be mostly used by scientific 
libraries to reference algorithms used in the packages. All the basic 
repository/issue/copyright information is already present in other files
in my current version.

> Automated checks:
> 
> check-all-the-things:
> $ cppcheck -j1 --quiet -f . | grep -vF 'cppcheck: error: could not
> find or open any of the paths given.'
> [properties/nm-ssh.c:1287]: (error) Possible null pointer dereference: gateway
> [properties/nm-ssh.c:1289]: (error) Possible null pointer dereference: 
> remote_ip
> [properties/nm-ssh.c:1290]: (error) Possible null pointer dereference: 
> local_ip
> [properties/nm-ssh.c:1291]: (error) Possible null pointer dereference: netmask
> [properties/nm-ssh.c:1316]: (error) Possible null pointer dereference:
> preferred_authentication
> $ flawfinder -Q -c .
> 

I'll report these upstream as these check seems to be of valid concern.
Not security wise but to avoid errors.

Thanks again,

Lennart Weller



Bug#807258: Logged transaction

2015-12-08 Thread BERTRAND Joël
250-rayleigh.systella.fr Hello mta.partenaire.viadeo.com 
[136.147.180.10], pleased to meet you

250-ENHANCEDSTATUSCODES
250-PIPELINING
250-EXPN
250-VERB
250-8BITMIME
250-SIZE
250-DSN
250-ETRN
250-AUTH NTLM PLAIN LOGIN
250-STARTTLS
250-DELIVERBY
250 HELP

10:25:15.695375 IP mta.partenaire.viadeo.com.39783 > 
rayleigh.systella.fr.smtp: Flags [P.], seq 33:181, ack 471, win 131, 
options [nop,nop,TS val 704029822 ecr 312631110], length 148: SMTP: MAIL 
FROM: 
BODY=8BITMIME

EP@.-..
.g...>.._4.RM..
)..~.._FMAIL 
FROM: 
BODY=8BITMIME

RCPT TO:
DATA

10:25:15.733941 IP rayleigh.systella.fr.smtp > 
mta.partenaire.viadeo.com.39783: Flags [.], ack 181, win 234, options 
[nop,nop,TS val 312631148 ecr 704029822], length 0

E..4.l@.@.e
...g_4.R.>.G.z.
.._l)..~
10:25:16.471353 IP rayleigh.systella.fr.smtp > 
mta.partenaire.viadeo.com.39783: Flags [P.], seq 471:706, ack 181, win 
234, options [nop,nop,TS val 312631332 ecr 704029822], length 235: SMTP: 
250 2.1.0 
... 
Sender ok

Em@.@.d#...
...g_4.R.>.G...
..`$)..~250 2.1.0 
... 
Sender ok
550 ... 451 4.7.1 Greylisting in 
action, please come back in 00:10:00

503 5.0.0 Need RCPT (recipient)

I don't understand following line :
550 ... 451 4.7.1 Greylisting in 
action, please come back in 00:10:00


Why 550 and 451 on the _same_ line ?

Best regards,

JKB



Bug#807313: gnome-shell-extension-weather: The whole UI freezes when the network interface goes up

2015-12-08 Thread Alberto Garcia
Control: tags -1 patch upstream

On Mon, Dec 07, 2015 at 11:07:51AM +0100, Alberto Garcia wrote:

> When I bring up a network interface the whole UI often freezes for
> a few seconds. During that time I cannot switch windows or type
> anything.

It looks like this is fixed upstream:

https://github.com/jenslody/gnome-shell-extension-openweather/commit/a08629900a4bba241880cb55e831e93600de6e5c

Berto



Bug#807389: haskell-hslua: no longer builds on architectures without luajit

2015-12-08 Thread Colin Watson
Package: haskell-hslua
Version: 0.4.1-1
Severity: serious

haskell-hslua no longer builds on architectures without luajit (which
isn't Architecture: any, but only builds on a limited set of
architectures):

  https://buildd.debian.org/status/package.php?pkg=haskell-hslua

  $ grep-excuses haskell-hslua
  haskell-hslua (0.3.13-2 to 0.4.1-1)
  Maintainer: Debian Haskell Group
  Too young, only 3 of 5 days old
  missing build on arm64: libghc-hslua-dev, libghc-hslua-doc, 
libghc-hslua-prof (from 0.3.13-2)
  missing build on armel: libghc-hslua-dev, libghc-hslua-doc, 
libghc-hslua-prof (from 0.3.13-2)
  missing build on mipsel: libghc-hslua-dev, libghc-hslua-doc, 
libghc-hslua-prof (from 0.3.13-2)
  missing build on ppc64el: libghc-hslua-dev, libghc-hslua-doc, 
libghc-hslua-prof (from 0.3.13-2)
  missing build on s390x: libghc-hslua-dev, libghc-hslua-doc, 
libghc-hslua-prof (from 0.3.13-2)
  Not considered
  Depends: haskell-hslua ghc (not considered)

I don't think we can drop haskell-hslua on those architectures, because
pandoc needs it.  Can we avoid luajit in those cases?

-- 
Colin Watson   [cjwat...@debian.org]



Bug#807396: rpm2html: FTBFS: config.c:81:14: error: expected identifier or '(' before '__extension__'

2015-12-08 Thread Chris Lamb
Source: rpm2html
Version: 1.11.2-7
Severity: serious
Justification: fails to build from source
User: reproducible-bui...@lists.alioth.debian.org
Usertags: ftbfs
X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org

Dear Maintainer,

rpm2html fails to build from source in unstable/amd64:

  [..]

  In file included from /usr/include/string.h:634:0,
   from config.c:17:
  config.c:81:14: error: expected identifier or '(' before
  '__extension__'
   extern char *strndup (const char *source, size_t len);
^
  Makefile:514: recipe for target 'config.o' failed
  make[1]: *** [config.o] Error 1
  make[1]: Leaving directory
  '/home/lamby/temp/cdt.20151208135354.SpCErlN6CE/rpm2html-1.11.2'
  dh_auto_build: make -j1 returned exit code 2
  debian/rules:7: recipe for target 'build' failed
  make: *** [build] Error 2

  [..]

The full build log is attached.


Regards,

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



Bug#807397: trac-announcer: FTBFS: error: Could not find suitable distribution for Requirement.parse('Trac')

2015-12-08 Thread Chris Lamb
Source: trac-announcer
Version: 0.12.1+r14934-1
Severity: serious
Justification: fails to build from source
User: reproducible-bui...@lists.alioth.debian.org
Usertags: ftbfs
X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org

Dear Maintainer,

trac-announcer fails to build from source in unstable/amd64:

  [..]

 dh_auto_test -O--buildsystem=pybuild
  I: pybuild base:184: python2.7 setup.py test 
  running test
  Searching for Trac
  
  Note: Bypassing https://pypi.python.org/simple/Trac/ (disallowed host;
  see http://bit.ly/1dg9ijs for details).
  
  Couldn't find index page for 'Trac' (maybe misspelled?)
  Scanning index of all packages (this may take a while)
  
  Note: Bypassing https://pypi.python.org/simple/ (disallowed host; see
  http://bit.ly/1dg9ijs for details).
  
  No local packages or download links found for Trac
  error: Could not find suitable distribution for
  Requirement.parse('Trac')
  E: pybuild pybuild:274: test: plugin distutils failed with: exit
  code=1: python2.7 setup.py test 
  dh_auto_test: pybuild --test -i python{version} -p 2.7 --dir .
  returned exit code 13
  debian/rules:8: recipe for target 'build' failed
  make: *** [build] Error 25

  [..]

The full build log is attached.


Regards,

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


trac-announcer.0.12.1+r14934-1.unstable.amd64.log.txt.gz
Description: Binary data


Bug#807395: rpm2html: FTBFS: config.c:81:14: error: expected identifier or '(' before '__extension__'

2015-12-08 Thread Chris Lamb
Source: rpm2html
Version: 1.11.2-7
Severity: serious
Justification: fails to build from source
User: reproducible-bui...@lists.alioth.debian.org
Usertags: ftbfs
X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org

Dear Maintainer,

rpm2html fails to build from source in unstable/amd64:

  [..]

  In file included from /usr/include/string.h:634:0,
   from config.c:17:
  config.c:81:14: error: expected identifier or '(' before
  '__extension__'
   extern char *strndup (const char *source, size_t len);
^
  Makefile:514: recipe for target 'config.o' failed
  make[1]: *** [config.o] Error 1
  make[1]: Leaving directory
  '/home/lamby/temp/cdt.20151208135354.SpCErlN6CE/rpm2html-1.11.2'
  dh_auto_build: make -j1 returned exit code 2
  debian/rules:7: recipe for target 'build' failed
  make: *** [build] Error 2

  [..]

The full build log is attached.


Regards,

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


rpm2html.1.11.2-7.unstable.amd64.log.txt.gz
Description: Binary data


Bug#807394: orthanc-dicomweb: FTBFS: Plugin.cpp:167:87: error: invalid conversion from 'int32_t (*)(OrthancPluginRestOutp [..]

2015-12-08 Thread Chris Lamb
Source: orthanc-dicomweb
Version: 0.1+dfsg-1
Severity: serious
Justification: fails to build from source
User: reproducible-bui...@lists.alioth.debian.org
Usertags: ftbfs
X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org

Dear Maintainer,

orthanc-dicomweb fails to build from source in unstable/amd64:

  [..]
   ^
  
/home/lamby/temp/cdt.20151208135554.yE2P8vcjOm/orthanc-dicomweb-0.1+dfsg/Plugin/Plugin.cpp:167:87:
  error: invalid conversion from 'int32_t (*)(OrthancPluginRestOutput*,
  const char*, const OrthancPluginHttpRequest*) {aka int
  (*)(_OrthancPluginRestOutput_t*, const char*, const
  OrthancPluginHttpRequest*)}' to 'OrthancPluginRestCallback {aka
  OrthancPluginErrorCode (*)(_OrthancPluginRestOutput_t*, const char*,
  const OrthancPluginHttpRequest*)}' [-fpermissive]
 Register(root, "studies/([^/]*)/series/([^/]*)/metadata",
 RetrieveSeriesMetadata);

 ^
  
/home/lamby/temp/cdt.20151208135554.yE2P8vcjOm/orthanc-dicomweb-0.1+dfsg/Plugin/Plugin.cpp:84:13:
  note:   initializing argument 3 of 'void Register(const string&, const
  string&, OrthancPluginRestCallback)'
   static void Register(const std::string& root,
   ^
  
/home/lamby/temp/cdt.20151208135554.yE2P8vcjOm/orthanc-dicomweb-0.1+dfsg/Plugin/Plugin.cpp:182:77:
  error: invalid conversion from 'int32_t (*)(OrthancPluginRestOutput*,
  const char*, const OrthancPluginHttpRequest*) {aka int
  (*)(_OrthancPluginRestOutput_t*, const char*, const
  OrthancPluginHttpRequest*)}' to 'OrthancPluginRestCallback {aka
  OrthancPluginErrorCode (*)(_OrthancPluginRestOutput_t*, const char*,
  const OrthancPluginHttpRequest*)}' [-fpermissive]
 OrthancPluginRegisterRestCallback(context_, wado.c_str(),
 WadoCallback);
   ^
  In file included from
  
/home/lamby/temp/cdt.20151208135554.yE2P8vcjOm/orthanc-dicomweb-0.1+dfsg/Plugin/Plugin.h:23:0,
   from
   
/home/lamby/temp/cdt.20151208135554.yE2P8vcjOm/orthanc-dicomweb-0.1+dfsg/Plugin/Plugin.cpp:21:
  /usr/include/orthanc/OrthancCPlugin.h:1181:30: note:   initializing
  argument 3 of 'void
  OrthancPluginRegisterRestCallback(OrthancPluginContext*, const char*,
  OrthancPluginRestCallback)'
 ORTHANC_PLUGIN_INLINE void OrthancPluginRegisterRestCallback(
^
  CMakeFiles/OrthancDicomWeb.dir/build.make:353: recipe for target
  'CMakeFiles/OrthancDicomWeb.dir/Plugin/Plugin.cpp.o' failed
  make[3]: *** [CMakeFiles/OrthancDicomWeb.dir/Plugin/Plugin.cpp.o]
  Error 1
  make[3]: *** Waiting for unfinished jobs
  [ 75%] Building CXX object
  CMakeFiles/UnitTests.dir/Plugin/DicomResults.cpp.o
  /usr/bin/c++   -DBOOST_FILESYSTEM_VERSION=3 -DBOOST_HAS_DATE_TIME=1
  -DBOOST_HAS_FILESYSTEM_V3=1 -DBOOST_HAS_LOCALE=1 -DBOOST_HAS_REGEX=1
  -DORTHANC_DICOM_WEB_VERSION=\"0.1\" -DORTHANC_ENABLE_BASE64=0
  -DORTHANC_ENABLE_MD5=0 -DORTHANC_PUGIXML_ENABLED=1 -DORTHANC_STATIC=0
  -D_FILE_OFFSET_BITS=64 -D_LARGEFILE64_SOURCE=1 -g -O2
  -fstack-protector-strong -Wformat -Werror=format-security
  -D_FORTIFY_SOURCE=2  -Wall -pedantic -Wno-long-long
  -Wno-variadic-macros -I/usr/src/gtest -I/usr/include/jsoncpp
  -I/usr/include/gdcm-2.6-o
  CMakeFiles/UnitTests.dir/Plugin/DicomResults.cpp.o -c
  
/home/lamby/temp/cdt.20151208135554.yE2P8vcjOm/orthanc-dicomweb-0.1+dfsg/Plugin/DicomResults.cpp
  
/home/lamby/temp/cdt.20151208135554.yE2P8vcjOm/orthanc-dicomweb-0.1+dfsg/Orthanc/Core/Toolbox.cpp:
  In function 'Orthanc::Endianness
  Orthanc::Toolbox::DetectEndianness()':
  
/home/lamby/temp/cdt.20151208135554.yE2P8vcjOm/orthanc-dicomweb-0.1+dfsg/Orthanc/Core/Toolbox.cpp:871:33:
  warning: dereferencing type-punned pointer will break strict-aliasing
  rules [-Wstrict-aliasing]
   switch (*((uint32_t *)buffer)) 
   ^
  [ 78%] Building CXX object
  CMakeFiles/UnitTests.dir/Plugin/JpegWriter.cpp.o
  [ 81%] Building CXX object
  CMakeFiles/UnitTests.dir/usr/src/gtest/src/gtest-all.cc.o
  /usr/bin/c++   -DBOOST_FILESYSTEM_VERSION=3 -DBOOST_HAS_DATE_TIME=1
  -DBOOST_HAS_FILESYSTEM_V3=1 -DBOOST_HAS_LOCALE=1 -DBOOST_HAS_REGEX=1
  -DORTHANC_DICOM_WEB_VERSION=\"0.1\" -DORTHANC_ENABLE_BASE64=0
  -DORTHANC_ENABLE_MD5=0 -DORTHANC_PUGIXML_ENABLED=1 -DORTHANC_STATIC=0
  -D_FILE_OFFSET_BITS=64 -D_LARGEFILE64_SOURCE=1 -g -O2
  -fstack-protector-strong -Wformat -Werror=format-security
  -D_FORTIFY_SOURCE=2  -Wall -pedantic -Wno-long-long
  -Wno-variadic-macros -I/usr/src/gtest -I/usr/include/jsoncpp
  -I/usr/include/gdcm-2.6-o
  CMakeFiles/UnitTests.dir/Plugin/JpegWriter.cpp.o -c
  
/home/lamby/temp/cdt.20151208135554.yE2P8vcjOm/orthanc-dicomweb-0.1+dfsg/Plugin/JpegWriter.cpp
  /usr/bin/c++   -DBOOST_FILESYSTEM_VERSION=3 -DBOOST_HAS_DATE_TIME=1
  -DBOOST_HAS_FILESYSTEM_V3=1 -DBOOST_HAS_LOCALE=1 -DBOOST_HAS_REGEX=1
  

Bug#807400: libtext-aspell-perl: FTBFS with perl 5.22 in experimental (MakeMaker changes)

2015-12-08 Thread Dominic Hargreaves
Source: libtext-aspell-perl
Version: 0.09-1
Severity: serious
Justification: transition imminent
User: debian-p...@lists.debian.org
Usertags: perl-5.22-transition makemaker-prefix
Tags: sid stretch

This package FTBFS with perl 5.22.0-2, which removed support for a long-
obsolete way of overriding PREFIX when calling 'make install' with
ExtUtils::MakeMaker, as described in the lintian tag
debian-rules-makemaker-prefix-is-deprecated[1] and the Debian Perl
policy[2]:


ERROR: Can't create '/usr/lib/x86_64-linux-gnu/perl5/5.22/Text'
mkdir /usr/lib/x86_64-linux-gnu/perl5/5.22/Text: Permission denied at /usr/share
/perl/5.22/ExtUtils/Install.pm line 477.


 at -e line 1.

The fix is to use DESTDIR instead of PREFIX; please see the lintian
`description for examples. Alternatively, newer versions of debhelper
can automatically call make install with the correct arguments when
using the dh7 style rules files.

The perl 5.22 is due to start this week, so apologies for the late
submission of this bug; for some reason my previous testing of this
issue overlooked this package.

Cheers,
Dominic.

[1] 

[2] 




Bug#807402: kde-cli-tools: Missing dependency on libkf5su-bin

2015-12-08 Thread Martin Graesslin
Package: kde-cli-tools
Version: 4:5.4.3-1
Severity: normal

Dear Maintainer,

kdesu which is provided by kde-cli-tools needs to interact with kdesud,
which is provided by libkf5su-bin. But there is no direct dependency from
kde-cli-tools to said package defined. There is only a recommends from
libkf5su5 to libkf5su-bin.

I recommend to either change the recommends to a hard dependency or to
add another dependency from kde-cli-tools to libkf5su-bin to ensure it's
working.

Best Regards
Martin Gräßlin

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

Kernel: Linux 4.2.0-1-amd64 (SMP w/8 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.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)

Versions of packages kde-cli-tools depends on:
ii  kde-cli-tools-data  4:5.4.3-1
ii  kio 5.16.0-1
ii  libc6   2.19-22
ii  libkf5completion5   5.16.0-1
ii  libkf5configcore5   5.16.0-1
ii  libkf5configwidgets55.16.0-1
ii  libkf5coreaddons5   5.16.0-1
ii  libkf5i18n5 5.16.0-1
ii  libkf5iconthemes5   5.16.0-1
ii  libkf5kcmutils5 5.16.0-1
ii  libkf5kdelibs4support5  5.16.0-1
ii  libkf5kiocore5  5.16.0-1
ii  libkf5kiowidgets5   5.16.0-1
ii  libkf5service-bin   5.16.0-1
ii  libkf5service5  5.16.0-1
ii  libkf5su5   5.16.0-1
ii  libkf5widgetsaddons55.16.0-1
ii  libkf5windowsystem5 5.16.0-1
ii  libqt5core5a5.5.1+dfsg-8
ii  libqt5dbus5 5.5.1+dfsg-8
ii  libqt5gui5  5.5.1+dfsg-8
ii  libqt5svg5  5.5.1-2
ii  libqt5widgets5  5.5.1+dfsg-8
ii  libqt5x11extras55.5.1-3
ii  libstdc++6  5.2.1-23
ii  libx11-62:1.6.3-1

kde-cli-tools recommends no packages.

kde-cli-tools suggests no packages.

-- no debconf information



Bug#485008: aptitude: 'why' doesn't seem to work

2015-12-08 Thread Sam Morris
On Tue, 2015-12-08 at 01:14 +, Manuel A. Fernandez Montecelo wrote:
> Have you seen this problem more recently with other packages?

I don't think so, I suspect this was a rare bug to begin with, and/or
it has been fixed in the mean time.

-- 
Sam Morris 
CAAA AA1A CA69 A83A 892B  1855 D20B 4202 5CDA 27B9



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


Bug#807360: debci-worker: cronjob exits with error after package removal

2015-12-08 Thread Antonio Terceiro
Control: tag -1 + pending

On Mon, Dec 07, 2015 at 10:26:24PM +0100, Andreas Beckmann wrote:
> Package: debci-worker
> Version: 1.0
> Severity: important
> User: debian...@lists.debian.org
> Usertags: piuparts
> 
> Hi,
> 
> during a test with piuparts I noticed your packages cronjob exits with
> error after the package has been removed.
> 
> >From the attached log (scroll to the bottom...):
> 
> 1m51.0s INFO: Package debci-worker contains cron file: 
> /etc/cron.daily/debci-worker
> 1m51.0s DEBUG: Starting command: ['chroot', '/tmp/piupartss/tmpPXxCGe', 
> '/etc/cron.daily/debci-worker']
> 1m51.0s DUMP: 
>   /etc/cron.daily/debci-worker: 13: /etc/cron.daily/debci-worker: debci: not 
> found
> 1m51.0s ERROR: Command failed (status=127): ['chroot', 
> '/tmp/piupartss/tmpPXxCGe', '/etc/cron.daily/debci-worker']

thanks for reporting, this is fixed in git.

-- 
Antonio Terceiro 


signature.asc
Description: PGP signature


Bug#659465: nfs-common: need to restart nfs-common at the end of init on the NFS server

2015-12-08 Thread Dietrich Clauss
This problem is still present in jessie (8.1, with systemd).

The workaround (/etc/rc.local) still works as expected.



Bug#807380: Regression for 'PKCS11Provider libsimple-tpm-pk11.so' - ignoring uninitialised token in slot 0

2015-12-08 Thread Michael Stapelberg
If you could do an upload (possibly even of the new version), that’d be
appreciated.

On Tue, Dec 8, 2015 at 3:23 AM, Didier 'OdyX' Raboud 
wrote:

> Control: found -1 0.03-1
> Control: severity -1 serious
> Control: tags -1 +upstream +patch +fixed-upstream
>
> Le mardi, 8 décembre 2015, 09.47:04 Colin Watson a écrit :
> > Control: reassign -1 simple-tpm-pk11
> >
> > On Tue, Dec 08, 2015 at 09:34:07AM +0100, Didier 'OdyX' Raboud wrote:
> > > I'm using the following SSH config to use my X220's TPM through
> > >
> > > simple-tpm-pk11:
> > > > Host test
> > > >
> > > >   PKCS11Provider libsimple-tpm-pk11.so
> > >
> > This is because of the fix in
> > https://bugzilla.mindrot.org/show_bug.cgi?id=2427 - OpenSSH now checks
> > whether the token is initialised, but simple-tpm-pk11 doesn't set
> > that flag.  This is essentially the same as
> > https://github.com/ThomasHabets/simple-tpm-pk11/issues/13.  I think
> > that cherry-picking this commit would do it, or simply upgrading to
> > simple-tpm-pk11 0.04:
> >
> >
> > https://github.com/ThomasHabets/simple-tpm-pk11/commit/bd8202d0f270e0
> > 2e89b7df84c7373fbe1ace3e9e
>
> Good catch, thanks. I can confirm that simple-tpm-pk11 0.04 works!
>
> I'm rising the severity of that bug as the main use of simple-tpm-pk11
> is broken by the openssh in unstable.
>
> Michael: would you be up for upload, or should I proceed with a cherry-
> pick and upload to DELAYED ?
>
> Cheers,
>
> OdyX
>



-- 
Best regards,
Michael


Bug#807399: libkf5su-bin: kdesud not group suid and owned by root (instead of nobody)

2015-12-08 Thread Martin Graesslin
Package: libkf5su-bin
Version: 5.16.0-1
Severity: important

Dear Maintainer,

I noticed that the file
/usr/lib/x86_64-linux-gnu/libexec/kf5/kdesud

is group owned by "root" and not group suid.

Given the CMake snippet from the source package:
install(TARGETS kdesud DESTINATION ${KDE_INSTALL_LIBEXECDIR_KF5})
install(CODE "
set(KDESUD_PATH 
\"\$ENV{DESTDIR}${CMAKE_INSTALL_FULL_LIBEXECDIR_KF5}/kdesud\")
execute_process(COMMAND sh -c \"chgrp nogroup '\${KDESUD_PATH}' && chmod 
g+s '\${KDESUD_PATH}'\")
")

Without being suid for group the kdesud process is rather useless as kdesu from
kde-cli-tools reports:

kdesu(2626)/(org.kde.kdesu) startApp: Daemon not safe (not sgid), not using it.

Best Regards,
Martin Gräßlin

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

Kernel: Linux 4.2.0-1-amd64 (SMP w/8 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.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)

Versions of packages libkf5su-bin depends on:
ii  libc6  2.19-22
ii  libkf5coreaddons5  5.15.0-1
ii  libkf5i18n55.15.0-1
ii  libkf5su5  5.15.0-1
ii  libqt5core5a   5.5.1+dfsg-8
ii  libstdc++6 5.2.1-23
ii  libx11-6   2:1.6.3-1

libkf5su-bin recommends no packages.

libkf5su-bin suggests no packages.

-- no debconf information


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

Kernel: Linux 4.2.0-1-amd64 (SMP w/8 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.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)

Versions of packages libkf5su-bin depends on:
ii  libc6  2.19-22
ii  libkf5coreaddons5  5.15.0-1
ii  libkf5i18n55.15.0-1
ii  libkf5su5  5.15.0-1
ii  libqt5core5a   5.5.1+dfsg-8
ii  libstdc++6 5.2.1-23
ii  libx11-6   2:1.6.3-1

libkf5su-bin recommends no packages.

libkf5su-bin suggests no packages.

-- no debconf information



Bug#807380: Regression for 'PKCS11Provider libsimple-tpm-pk11.so' - ignoring uninitialised token in slot 0

2015-12-08 Thread Didier 'OdyX' Raboud
Le mardi, 8 décembre 2015, 03.35:33 Michael Stapelberg a écrit :
> If you could do an upload (possibly even of the new version), that’d
> be appreciated.

Uploaded 0.04-1 to unstable. Also pushed branches and tags to the 
collab-maint git.

I added a (hopefully) harmless change in the debian/watch to fit with 
more recent practices, that helped merging the new version in.

Cheers,
OdyX



Bug#778650: freerdp-x11: Alt key gets "stuck" with -grab-keyboard option when using Alt-Tab to switch between local X windows

2015-12-08 Thread Vladimir K
I've tested this patch on jessie. Judging by the description, it should release 
all keys if client loses focus.
But it does not help with stuck Super key in RDP session (when windows are 
switched by Super+Tab on local host). When switching back, Super key is still 
pressed on remote host).



Bug#807170: libQtUiTools.a(quiloader.o): unrecognized relocation (0x2a) in section `.text'

2015-12-08 Thread Daniel Hornung
Can reproduce this error on Testing when trying to build the git version of 
FreeCAD:

[ 13%] Linking CXX shared library ../../lib/libFreeCADGui.so
/usr/bin/ld: /usr/lib/gcc/x86_64-linux-gnu/5/../../../x86_64-linux-
gnu/libQtUiTools.a(quiloader.o): unrecognized relocation (0x2a) in section 
`.text'
/usr/bin/ld: final link failed: Bad value
collect2: error: ld returned 1 exit status

-- 
Max-Planck-Institute for Dynamics and Self-Organization
Research Group Biomedical Physics

Am Fassberg 17
D-37077 Goettingen
(+49) 551 5176 373

You can obtain my public key 0xF197B128 from all keyservers, e.g. pgp.mit.edu
Fingerprint: 9698 BDD4 71CC 1274 B7E2  2049 1EDD 012D F197 B128


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


Bug#778650: freerdp-x11: Alt key gets "stuck" with -grab-keyboard option when using Alt-Tab to switch between local X windows

2015-12-08 Thread Vladimir K
Related upstream bug: https://github.com/FreeRDP/FreeRDP/issues/2104



Bug#797793: samtools update seems to breaks even more tests

2015-12-08 Thread Andreas Tille
On Mon, Dec 07, 2015 at 09:57:10PM -0800, Afif Elghraoui wrote:
> 
> This error appears like you're somehow using an old version of pysam
> because AlignmentFile was introduced in 0.8.1. Are you sure you're not
> accidentally building with a Jessie chroot (where pysam is at version
> 0.7.7) rather than an Unstable one?

You are probably right - I can not reproduce myself ...
 
> I just made sure my working directory was clean and tried building
> again. It still works for me...

Thanks for the  pointer.  I've uploaded now after tweaking the expected
result a bit to let the single test pass.  Its not nice to do this without
upstream support ( :-( ) but I'm positive there is no harm done.

Kind regards

   Andreas.

-- 
http://fam-tille.de



Bug#800631: [Bug]: Re: [Pkg-nagios-devel] Bug#800631: check-mk-agent: CUPS printer queues are not detected anymore

2015-12-08 Thread Bastian Kuhn

Hello Matt,

this is already fixed.

Thanks for the Report,

Bastian


Bastian Kuhn

Mathias Kettner GmbH
Kellerstraße 29, 81667 München, Germany
Registergericht: Amtsgericht München, HRB 165902
Geschäftsführer: Mathias Kettner
http://mathias-kettner.de
Tel. +49 89 1890 435-0
Fax. +49 89 1890 435-29

On 02.10.2015 01:33, Matt Taggart wrote:

Ingo Rogalsky writes:

Package: check-mk-agent
Version: 1.2.6p12-1~bpo8+1
Severity: normal
Tags: patch

Dear Maintainer,

* What led up to the situation?

  update from 1.2.6p7-1~bpo8+1 -> 1.2.6p12-1~bpo8+1

* What was the outcome of this action?

  The detecting of CUPS printer queues does not work anymore.

This patch  should fix the issue:

--- check_mk_agent  2015-10-01 23:08:52.282483902 +0200
+++ /usr/bin/check_mk_agent 2015-10-01 23:09:42.886927038 +0200
@@ -420,7 +420,7 @@

  # Status of CUPS printer queues
  if type lpstat > /dev/null 2>&1; then
-if pgrep -x cups > /dev/null 2>&1; then
+if pgrep -x cupsd > /dev/null 2>&1; then
  # first define a function to check cups
  function cups_queues () {
  CPRINTCONF=/etc/cups/printers.conf


Hi,

Thanks for the report. Looks like this regression was introduced in
upstream git commit 53164e7600f28cb43a189dd8e4b1a624a6a5287b as part
of fixing #2504 where the '-x' exact match flag was added to fix
another case.

Upstream maintainers can you fix?

Thanks,





Bug#807310: RFS: network-manager-ssh/0.9.4-1 [ITP] - ssh vpn for network manager

2015-12-08 Thread Lennart Weller
> Examples of what I mean: dz.po ug.po sl.po ro.po ps.po pa.po nb.po

The files still contain the author information in the po header.
They are just missing in the  file header. I'll report it upstream anyway
so he can add the information to the file header.

> It isn't about scientific references, that is a common misconception.
> 
> At least these fields are probably applicable:
> 
> Bug-*
> Changelog
> Contact
> Name
> Repository
> Repository-Browse
> Screenshots
> Security-Contact

Yes. Those fields can be filled out, but technically the information is 
already available in debian/control and debian/copyright. Especially in cases 
of Github and other code hosting sites most of these entries would be the same. 
I added it anyway as it doesn't really require that much extra work in the end.

Well. Thanks again. I have some upstream reporting to do now to get this package
into better state, though I think it's already in a good enough state for debian
as of now.

Lennart



Bug#807385: grub-efi-amd64: GRUB2 EFI image should contain raid5rec module

2015-12-08 Thread Lee Trager
Package: grub-efi-amd64
Version: 2.02~beta2-29
Severity: important
Tags: patch

Dear Maintainer,

GRUB2 supports booting from filesystems running under RAID5 using the
raid5rec
module. Because GRUB2 modules are stored under /boot and not the EFI
partition,
like grubx64.efi, GRUB2 is unable to boot from volumes when /boot is on a
RAID5
volume without regenerating grubx64.efi by hand.

The attached patch includes raid5rec and raid6rec when building the EFI
images as is done with LVM and all other raid modules.

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

Kernel: Linux 4.2.0-19-generic (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
=== modified file 'debian/build-efi-images'
--- debian/build-efi-images	2015-09-04 12:35:59 +
+++ debian/build-efi-images	2015-11-10 01:55:26 +
@@ -137,6 +137,8 @@
 	lvm
 	mdraid09
 	mdraid1x
+raid5rec
+raid6rec
 	"
 NET_MODULES="$CD_MODULES
 	tftp



Bug#807388: din: Crash on startup

2015-12-08 Thread Lucio Crusca
Package: din
Version: 5.2.1-3
Severity: important

Here is all I get when I try to launch din:

$ din
+++ initialised random number generator +++
<<< using data files in /home/lucio/.din/ >>>
<<< loading globals, done >>>
terminate called after throwing an instance of 
'std::ios_base::failure[abi:cxx11]'
  what():  basic_filebuf::underflow error reading the file: iostream error


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

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

Versions of packages din depends on:
ii  libc6 2.19-22
ii  libfftw3-single3  3.3.4-2
ii  libgcc1   1:5.2.1-23
ii  libgl1-mesa-glx [libgl1]  10.6.8-1
ii  libircclient1 1.8-2
ii  libjack-jackd2-0 [libjack-0.116]  1.9.10+20150825git1ed50c92~dfsg-1
ii  liblo70.28-5
ii  libstdc++65.2.1-23
ii  libtcl8.5 8.5.18-2
ii  libx11-6  2:1.6.3-1

Versions of packages din recommends:
ii  jackd  5

din suggests no packages.

-- no debconf information



Bug#807336: [Python-modules-team] Bug#807336: python-psycopg2: double free or corruption

2015-12-08 Thread Fabien Harrang

Hi Scott,

Trying again with python-dbg as the interpreter command, I also have a 
"corrupted double-linked list".

Please see the 2 attachments (cleaned from security and privacy data).

Thanks,

Fabien$ gdb -ex r --args python-dbg -m trt.geolocate
GNU gdb (Debian 7.10-1) 7.10
Copyright (C) 2015 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from python-dbg...done.
Starting program: /usr/bin/python-dbg -m trt.geolocate
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[New Thread 0x7fffed94b700 (LWP 2756)]
[New Thread 0x7fffed14a700 (LWP 2757)]
[New Thread 0x7fffec949700 (LWP 2758)]
[New Thread 0x7fffd700 (LWP 2759)]
[New Thread 0x7fffdf7fe700 (LWP 2760)]
[New Thread 0x7fffdeffd700 (LWP 2761)]
[New Thread 0x7fffde7fc700 (LWP 2762)]
[New Thread 0x7fffddffb700 (LWP 2763)]
[New Thread 0x7fffdd7fa700 (LWP 2764)]
[New Thread 0x7fffdcff9700 (LWP 2765)]

*** Error in `/usr/bin/python-dbg': corrupted double-linked list: 
0x7fffe400a710 ***

Program received signal SIGABRT, Aborted.
[Switching to Thread 0x7fffec949700 (LWP 2758)]
0x76f28107 in raise () from /lib/x86_64-linux-gnu/libc.so.6
(gdb) bt
#0  0x76f28107 in raise () from /lib/x86_64-linux-gnu/libc.so.6
#1  0x76f294e8 in abort () from /lib/x86_64-linux-gnu/libc.so.6
#2  0x76f66214 in ?? () from /lib/x86_64-linux-gnu/libc.so.6
#3  0x76f6b9ee in ?? () from /lib/x86_64-linux-gnu/libc.so.6
#4  0x76f6c983 in ?? () from /lib/x86_64-linux-gnu/libc.so.6
#5  0x70db51e4 in pq_fetch (curs=0x7fffee5ac500, no_result=0) at 
psycopg/pqpath.c:1554
#6  0x70db3897 in pq_execute (curs=0x7fffee5ac500, query=0x7fffe4002344 
'\333' , ..., async=0, 
no_result=0, no_begin=0) at psycopg/pqpath.c:998
#7  0x70dbd215 in _psyco_curs_execute (self=0x7fffee5ac500, operation=
'UPDATE backup_building_coordinates SET "longitude" = %s, "datetime" = 
NOW(), "origine" = %s, "latitude" = %s WHERE "building" = %s AND "agency" = %s 
AND (NOT ((("longitude" IS NOT NULL) AND ("longitude" = %s)) AND (("datetime" 
IS NOT NULL) AND ("datetime" = NOW())) AND (("origine" IS NOT NULL) AND 
("origine" = %s)) AND (("latitude" IS NOT NULL) AND ("latitude" = %s;', 
vars=
[, u'P', , u'TMAI11616', 134, <...>, u'P', <...>], async=0, no_result=0) 
at psycopg/cursor_type.c:458
#8  0x70dbd57a in psyco_curs_execute (self=0x7fffee5ac500, args=
(u'UPDATE backup_building_coordinates SET "longitude" = %s, "datetime" = 
NOW(), "origine" = %s, "latitude" = %s WHERE "building" = %s AND "agency" = %s 
AND (NOT ((("longitude" IS NOT NULL) AND ("longitude" = %s)) AND (("datetime" 
IS NOT NULL) AND ("datetime" = NOW())) AND (("origine" IS NOT NULL) AND 
("origine" = %s)) AND (("latitude" IS NOT NULL) AND ("latitude" = %s;', 
[, u'P', , 
u'TMAI11616', 134, <...>, u'P', <...>]), kwargs=0x0) at 
psycopg/cursor_type.c:504
#9  0x00489922 in PyCFunction_Call (func=, 
arg=(u'UPDATE backup_building_coordinates SET "longitude" = %s, "datetime" 
= NOW(), "origine" = %s, "latitude" = %s WHERE "building" = %s AND "agency" = 
%s AND (NOT ((("longitude" IS NOT NULL) AND ("longitude" = %s)) AND 
(("datetime" IS NOT NULL) AND ("datetime" = NOW())) AND (("origine" IS NOT 
NULL) AND ("origine" = %s)) AND (("latitude" IS NOT NULL) AND ("latitude" = 
%s;', [, u'P', , u'TMAI11616', 134, <...>, u'P', <...>]), kw=0x0) at 
../Objects/methodobject.c:85
#10 0x00531550 in ext_do_call (func=, 
pp_stack=0x7fffec946728, flags=1, na=0, nk=0) at ../Python/ceval.c:4660
#11 0x0052ad02 in PyEval_EvalFrameEx (
f=Frame 0x7fffd0001a40, for file trt/__init__.py, line 500, in update_row 
(self=, _db_out=, _db_in=, db_out_model=<...>, env=u'dev', debug=False, _trts=[(<...>, 
None)]) at remote 0x7fffee567680>, title_detail=None, threads=10, 
datasource=Bug#807390: haskell-geniplate: FTBFS: At least the following dependencies are missing: template-haskell

Source: haskell-geniplate
Version: 0.6.0.4-3
Severity: serious
Justification: fails to build from source
User: reproducible-bui...@lists.alioth.debian.org
Usertags: ftbfs
X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org

Dear Maintainer,

haskell-geniplate fails to build from source in unstable/amd64:

  [..]

  /usr/share/cdbs/1/rules/buildcore.mk:110: CDBS WARNING:   
  DEB_COMPRESS_EXCLUDE is deprecated since 0.4.85
  . /usr/share/haskell-devscripts/Dh_Haskell.sh && \
  make_setup_recipe
  Running ghc --make Setup.hs -o debian/hlibrary.setup
  [1 of 1] Compiling Main ( Setup.hs, Setup.o )
  Linking debian/hlibrary.setup ...
  . /usr/share/haskell-devscripts/Dh_Haskell.sh && \
  configure_recipe
  Running debian/hlibrary.setup configure --ghc -v2
  --package-db=/var/lib/ghc/package.conf.d --prefix=/usr
  --libdir=/usr/lib/haskell-packages/ghc/lib --builddir=dist-ghc
  --ghc-option=-optl-Wl\,-z\,relro
  --haddockdir=/usr/lib/ghc-doc/haddock/geniplate-0.6.0.4/
  --datasubdir=geniplate
  --htmldir=/usr/share/doc/libghc-geniplate-doc/html/
  --enable-library-profiling --enable-tests
  Configuring geniplate-0.6.0.4...
  hlibrary.setup: At least the following dependencies are missing:
  template-haskell <2.10
  /usr/share/cdbs/1/class/hlibrary.mk:142: recipe for target
  'configure-ghc-stamp' failed
  make: *** [configure-ghc-stamp] Error 1

  [..]

The full build log is attached.


Regards,

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


haskell-geniplate.0.6.0.4-3.unstable.amd64.log.txt.gz
Description: Binary data


Bug#807392: libsendmail-milter-perl: FTBFS: Segmentation fault (core dumped)

Source: libsendmail-milter-perl
Version: 0.18-8
Severity: serious
Justification: fails to build from source
User: reproducible-bui...@lists.alioth.debian.org
Usertags: ftbfs
X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org

Dear Maintainer,

libsendmail-milter-perl fails to build from source in unstable/amd64:

  [..]

 dh_auto_test
make -j1 test TEST_VERBOSE=1
  make[1]: Entering directory
  '/home/lamby/temp/cdt.20151208135010.1cIlOB0yFG/libsendmail-milter-perl-0.18'
  Running Mkbootstrap for Sendmail::Milter ()
  chmod 644 Milter.bs
  PERL_DL_NONLAZY=1 /usr/bin/perl "-Iblib/lib" "-Iblib/arch" test.pl
  ---> Starting callback from interpreter: [0x7feeac0008e0].
  ---> Finished callback from interpreter: [0x7feeac0008e0].
  ---> Starting callback from interpreter: [0x7feeac0008e0].
  ---> Finished callback from interpreter: [0x7feeac0008e0].
  ---> Starting callback from interpreter: [0x7feeac0008e0].
  ---> Finished callback from interpreter: [0x7feeac0008e0].
  ---> Starting callback from interpreter: [0x7feeac0008e0].
  ---> Finished callback from interpreter: [0x7feeac0008e0].
  ---> Starting callback from interpreter: [0x7feeac0008e0].
  ---> Finished callback from interpreter: [0x7feeac0008e0].
  ---> Starting callback from interpreter: [0x7feeac0008e0].
  ---> Finished callback from interpreter: [0x7feeac0008e0].
  ---> Starting callback from interpreter: [0x7feea8e0].
  ---> Finished callback from interpreter: [0x7feea8e0].
  ---> Starting callback from interpreter: [0x7feea8e0].
  ---> Finished callback from interpreter: [0x7feea8e0].
  Segmentation fault (core dumped)
  Makefile:992: recipe for target 'test_dynamic' failed
  make[1]: *** [test_dynamic] Error 139
  make[1]: Leaving directory
  '/home/lamby/temp/cdt.20151208135010.1cIlOB0yFG/libsendmail-milter-perl-0.18'
  dh_auto_test: make -j1 test TEST_VERBOSE=1 returned exit code 2
  debian/rules:4: recipe for target 'build' failed
  make: *** [build] Error 2

  [..]

The full build log is attached.


Regards,

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


libsendmail-milter-perl.0.18-8.unstable.amd64.log.txt.gz
Description: Binary data


Bug#807391: libcommons-openpgp-java: FTBFS: BouncyCastleOpenPgpStreamingSignatureVerifier.java:92: error: cannot find symbol [..] sig.initVerify( key, "BC" );

Source: libcommons-openpgp-java
Version: 0+svn533492-5
Severity: serious
Justification: fails to build from source
User: reproducible-bui...@lists.alioth.debian.org
Usertags: ftbfs
X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org

Dear Maintainer,

libcommons-openpgp-java fails to build from source in unstable/amd64:

  [..]

  
  compile:
  [mkdir] Created dir:
  
/home/lamby/temp/cdt.20151208135006.z3zJFjQSjo/libcommons-openpgp-java-0+svn533492/build
  [javac]
  
/home/lamby/temp/cdt.20151208135006.z3zJFjQSjo/libcommons-openpgp-java-0+svn533492/debian/build.xml:50:
  warning: 'includeantruntime' was not set, defaulting to
  build.sysclasspath=last; set to false for repeatable builds
  [javac] Compiling 14 source files to
  
/home/lamby/temp/cdt.20151208135006.z3zJFjQSjo/libcommons-openpgp-java-0+svn533492/build
  [javac] warning: [options] bootstrap class path not set in
  conjunction with -source 1.6
  [javac]
  
/home/lamby/temp/cdt.20151208135006.z3zJFjQSjo/libcommons-openpgp-java-0+svn533492/src/main/java/org/apache/commons/openpgp/BouncyCastleOpenPgpStreamingSignatureVerifier.java:92:
  error: cannot find symbol
  [javac] sig.initVerify( key, "BC" );
  [javac]^
  [javac]   symbol:   method initVerify(PGPPublicKey,String)
  [javac]   location: variable sig of type PGPSignature
  [javac]
  
/home/lamby/temp/cdt.20151208135006.z3zJFjQSjo/libcommons-openpgp-java-0+svn533492/src/main/java/org/apache/commons/openpgp/BouncyCastleOpenPgpStreamingSigner.java:89:
  error: method extractPrivateKey in class PGPSecretKey cannot be
  applied to given types;
  [javac] PGPPrivateKey pgpPrivKey =
  pgpSec.extractPrivateKey( keyRing.getPassword(), PROVIDER );
  [javac]  ^
  [javac]   required: PBESecretKeyDecryptor
  [javac]   found: char[],String
  [javac]   reason: actual and formal argument lists differ in
  length
  [javac]
  
/home/lamby/temp/cdt.20151208135006.z3zJFjQSjo/libcommons-openpgp-java-0+svn533492/src/main/java/org/apache/commons/openpgp/BouncyCastleOpenPgpStreamingSigner.java:90:
  error: constructor PGPSignatureGenerator in class
  PGPSignatureGenerator cannot be applied to given types;
  [javac] sGen = new PGPSignatureGenerator(
  pgpSec.getPublicKey().getAlgorithm(), PGPUtil.SHA1, PROVIDER );
  [javac]^
  [javac]   required: PGPContentSignerBuilder
  [javac]   found: int,int,String
  [javac]   reason: actual and formal argument lists differ in
  length
  [javac]
  
/home/lamby/temp/cdt.20151208135006.z3zJFjQSjo/libcommons-openpgp-java-0+svn533492/src/main/java/org/apache/commons/openpgp/BouncyCastleOpenPgpStreamingSigner.java:91:
  error: cannot find symbol
  [javac] sGen.initSign( PGPSignature.BINARY_DOCUMENT,
  pgpPrivKey );
  [javac] ^
  [javac]   symbol:   method initSign(int,PGPPrivateKey)
  [javac]   location: variable sGen of type PGPSignatureGenerator
  [javac] Note: Some input files use or override a deprecated API.
  [javac] Note: Recompile with -Xlint:deprecation for details.
  [javac] Note:
  
/home/lamby/temp/cdt.20151208135006.z3zJFjQSjo/libcommons-openpgp-java-0+svn533492/src/main/java/org/apache/commons/openpgp/ant/OpenPgpSignerTask.java
  uses unchecked or unsafe operations.
  [javac] Note: Recompile with -Xlint:unchecked for details.
  [javac] 4 errors
  [javac] 1 warning
  
  BUILD FAILED
  
/home/lamby/temp/cdt.20151208135006.z3zJFjQSjo/libcommons-openpgp-java-0+svn533492/debian/build.xml:50:
  Compile failed; see the compiler error output for details.
  
  Total time: 1 second
  /usr/share/cdbs/1/class/ant.mk:40: recipe for target
  'debian/stamp-ant-build' failed
  make: *** [debian/stamp-ant-build] Error 1

  [..]

The full build log is attached.


Regards,

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


libcommons-openpgp-java.0+svn533492-5.unstable.amd64.log.txt.gz
Description: Binary data


Bug#752650: php-suhosin is licensed under the PHP license and is not PHP

Hi,

Reprising this old bug, it's a shame that a good security hardening
extension for PHP was kept out of Debian for two releases.

I think this turns out to be a different situation than other packages
(where things unrelated to PHP code had been put under the PHP license,
therefore not being able to satisfy the license terms).

On 2014-06-26, Ondřej Surý wrote:
| I did have a quite long and extensive chat with FTP Masters
| and our conclusion was that PHP License (any version) is
| suitable only for software that comes directly from "PHP Group",
| that basically means only PHP (src:php5) itself.

In the upstream bug[0] it is claimed by the author:
"Suhosin incorporates some PHP Code directly"
and that they can't relicense Suhosin because of that.

But does that mean Suhosin has fully complied with the license?

|  1. Redistributions of source code must retain the above copyright
| notice, this list of conditions and the following disclaimer.
|  2. Redistributions in binary form must reproduce the above copyright
| notice, this list of conditions and the following disclaimer in
| the documentation and/or other materials provided with the
| distribution.

Suhosin retains the same license.

|  3. The name "PHP" must not be used to endorse or promote products
| derived from this software without prior written permission. For
| written permission, please contact gr...@php.net.
|  4. Products derived from this software may not be called "PHP", nor
| may "PHP" appear in their name, without prior written permission
| from gr...@php.net.  You may indicate that your software works in
| conjunction with PHP by saying "Foo for PHP" instead of calling
| it "PHP Foo" or "phpfoo"

I don't think that was at issue, if the product is called "Suhosin".

|  5. The PHP Group may publish revised and/or new versions of the
| license from time to time. Each version will be given a
| distinguishing version number.
| Once covered code has been published under a particular version
| of the license, you may always continue to use it under the terms
| of that version. You may also choose to use such covered code
| under the terms of any subsequent version of the license
| published by the PHP Group. No one other than the PHP Group has
| the right to modify the terms applicable to covered code created
| under this License.

Suhosin hasn't modified the license terms.

|  6. Redistributions of any form whatsoever must retain the following
| acknowledgment:
| "This product includes PHP software, freely available from
| ".

The statement is reproduced in the Debian copyright file, and it seems
valid, if it really does include PHP software as claimed by upstream.

[0]: https://github.com/stefanesser/suhosin/issues/48

Thanks,
Regards,
-- 
Steven Chamberlain
ste...@pyro.eu.org


signature.asc
Description: Digital signature


Bug#805222: [Pkg-php-pecl] Bug#805222: php-apcu: FTBFS: PHP Fatal error: Call to a member function getFilelist() on null

JFTR this is not a correct fix and we need upstream to fix that, because
there are two different approaches of handling packagingroot at
different places and this is the main reason why it's causing the
errors.

PEAR_Command_Install is directly mangling the variables (channelsdir,
etc.), but the code below resets this to default value by calling
PEAR_Config::setInstallRoot($options['packagingroot']) followed by
PEAR_Config::setInstallRoot(false). This needs to be made consistent.

Cheers,
Ondrej

On Mon, Dec 7, 2015, at 17:21, Ondřej Surý wrote:
> Control: reassign -1 php-pear
> Control: found -1 php-pear/5.6.16+dfsg-1
> Control: affects -1 php5-apcu
> 
> Hi,
> 
> thank you for the report, after some debugging it seems this is a
> generic error in PEAR instead of bug just in the php-apcu. This should
> not affect no users, but it probably broke all PHP extensions, since it
> stops honoring packagingroot after calling PEAR_Registry->setConfig()
> 
> I have a fix ready and PHP building, and I am ccing Fedora and SuSE
> maintainers.
> 
> Mathieu, this also applies to your standalone src:php-pear:
> 
> diff --git a/PEAR/Command/Install.php b/PEAR/Command/Install.php
> index 9d572ed..3b1fec9 100644
> --- a/PEAR/Command/Install.php
> +++ b/PEAR/Command/Install.php
> @@ -848,7 +848,7 @@ Run post-installation scripts in package ,
> if any exist.
>  $pkg = &$instreg->getPackage($param->getPackage(),
>  $param->getChannel());
>  // $pkg may be NULL if install is a 'fake' install via
>  --packagingroot
>  if (is_object($pkg)) {
> -$pkg->setConfig($this->config);
> +$pkg->setConfig($this->config, false);
>  if ($list = $pkg->listPostinstallScripts()) {
>  $pn =
>  $reg->parsedPackageNameToString(array('channel' =>
> $param->getChannel(), 'package' =>
> $param->getPackage()), true);
> 
> 
> This fixes the issue right now, but it should be probably reported
> upstream to have a correct fix (since this might break other stuff :)),
> but my PEAR account doesn't work right now, so it might take me a while
> to report this to upstream.
> 
> Cheers,
> Ondrej
> 
> On Sun, Nov 15, 2015, at 22:18, Chris West (Faux) wrote:
> > Source: php-apcu
> > Version: 4.0.7-1
> > Severity: serious
> > Justification: fails to build from source
> > Tags: sid stretch
> > User: reproducible-bui...@lists.alioth.debian.org
> > Usertags: ftbfs
> > X-Debbugs-CC: reproducible-bui...@lists.alioth.debian.org
> > 
> > Dear Maintainer,
> > 
> > The package fails to build:
> > 
> > /usr/bin/pear -c debian/pearrc -d download_dir=/tmp -d 
> > include_path=/usr/share/php -d php_bin=/usr/bin/php -d bin_dir=/usr/bin -d 
> > php_dir=/usr/share/php -d data_dir=/usr/share/php/data -d 
> > doc_dir=/usr/share/doc/php5-apcu -d test_dir=/usr/share/php/tests install 
> > --offline --nodeps -P /php-apcu-4.0.7/debian/php5-apcu --nobuild 
> > ./apcu-4.0.7/package.xml
> > PHP Fatal error:  Call to a member function getFilelist() on null in
> > /usr/share/php/PEAR/Command/Install.php on line 747
> > dh_auto_install: /usr/bin/pear -c debian/pearrc -d download_dir=/tmp -d
> > include_path=/usr/share/php -d php_bin=/usr/bin/php -d bin_dir=/usr/bin
> > -d php_dir=/usr/share/php -d data_dir=/usr/share/php/data -d
> > doc_dir=/usr/share/doc/php5-apcu -d test_dir=/usr/share/php/tests install
> > --offline --nodeps -P /php-apcu-4.0.7/debian/php5-apcu --nobuild
> > ./apcu-4.0.7/package.xml returned exit code 255
> > debian/rules:9: recipe for target 'override_dh_auto_install' failed
> > make[1]: *** [override_dh_auto_install] Error 10
> > make[1]: Leaving directory '/php-apcu-4.0.7'
> > 
> > Full build log:
> > https://reproducible.debian.net/rb-pkg/unstable/amd64/php-apcu.html
> > 
> > -- System Information:
> > Debian Release: stretch/sid
> > APT prefers unstable
> > APT policy: (500, 'unstable')
> > Architecture: amd64 (x86_64)
> > 
> > ___
> > Pkg-php-pecl mailing list
> > pkg-php-p...@lists.alioth.debian.org
> > http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-php-pecl
> 
> 
> -- 
> Ondřej Surý 
> Knot DNS (https://www.knot-dns.cz/) – a high-performance DNS server


-- 
Ondřej Surý 
Knot DNS (https://www.knot-dns.cz/) – a high-performance DNS server



Bug#807368: polymake ticket notification: #879: polymake 2.14r1 fails to build with gmp 6.1

#879: polymake 2.14r1 fails to build with gmp 6.1
--+-
  Reporter:  bremner  |  Owner:  joswig
  Type:  defect   | Status:  new
  Priority:  major|  Milestone:  3.0
 Component:  UNKNOWN  |Version:  development
Resolution:   |   Keywords:
--+-

Comment (by benmuell):

 We have fixed the issue in our master and release/2.14 branch, since the
 next bugfix release for 2.14 will take some time I will upload a patch
 that should apply to 2.14r1 in a minute.

 Using the packaged libnormaliz is currently not feasible for us as we use
 the templated libnormaliz ({{{#include libnormaliz-all.cpp}}}) with our
 own number type to avoid conversions.

--
Ticket URL: 
polymake 
The polymake project



Bug#807368: polymake ticket notification: #879: polymake 2.14r1 fails to build with gmp 6.1

#879: polymake 2.14r1 fails to build with gmp 6.1
--+-
  Reporter:  bremner  |  Owner:  joswig
  Type:  defect   | Status:  new
  Priority:  major|  Milestone:  3.0
 Component:  UNKNOWN  |Version:  development
Resolution:   |   Keywords:
--+-
Changes (by benmuell):

 * Attachment "0001-fix-libnormaliz-for-gmp-6.1.patch" added.

 fix libnormaliz build with gmp 6.1

--
Ticket URL: 
polymake 
The polymake project



Bug#800448: (no subject)

Hi,

we hit this bug too. Any chance of pushing the patched package to the
"next point release" as mentionned in october ?

Arthur

-- 
Arthur Lutz - Logilab
http://www.logilab.fr/
Twitter @arthurlutz https://twitter.com/arthurlutz
@logilab https://twitter.com/logilab



Bug#807386: php-defaults: Substitution of @PHP_VERSION@ variable in package descriptions not working for some packages

Package: php-defaults
Severity: minor

Hi,

while working at packages' descriptions translations I noticed that most
(if not all) binary packages built from php-defaults package share one
last paragraph which is

"This package is a dependency package, which depends on Debian's default
PHP version (currently @PHP_VERSION@)."

The variable substitution though seems to work only for some packages,
for example php-fpm, php-dev; for other packages is not working and the
name of the variable is displayed verbatim in the package description
(at least in the DDTSS and in the web pages)
as you can see in the packages pages, like here:

https://packages.debian.org/sid/php-imap

or here

https://packages.debian.org/sid/php-gd

Aside php-imap and php-gd, this is true also for php-interbase php-intl
php-json php-tidy and several others.

Thanks,

beatrice



Bug#807380: Regression for 'PKCS11Provider libsimple-tpm-pk11.so' - ignoring uninitialised token in slot 0

Control: found -1 0.03-1
Control: severity -1 serious
Control: tags -1 +upstream +patch +fixed-upstream

Le mardi, 8 décembre 2015, 09.47:04 Colin Watson a écrit :
> Control: reassign -1 simple-tpm-pk11
> 
> On Tue, Dec 08, 2015 at 09:34:07AM +0100, Didier 'OdyX' Raboud wrote:
> > I'm using the following SSH config to use my X220's TPM through
> > 
> > simple-tpm-pk11:
> > > Host test
> > > 
> > >   PKCS11Provider libsimple-tpm-pk11.so
> > 
> This is because of the fix in
> https://bugzilla.mindrot.org/show_bug.cgi?id=2427 - OpenSSH now checks
> whether the token is initialised, but simple-tpm-pk11 doesn't set
> that flag.  This is essentially the same as
> https://github.com/ThomasHabets/simple-tpm-pk11/issues/13.  I think
> that cherry-picking this commit would do it, or simply upgrading to
> simple-tpm-pk11 0.04:
> 
>  
> https://github.com/ThomasHabets/simple-tpm-pk11/commit/bd8202d0f270e0
> 2e89b7df84c7373fbe1ace3e9e

Good catch, thanks. I can confirm that simple-tpm-pk11 0.04 works!

I'm rising the severity of that bug as the main use of simple-tpm-pk11 
is broken by the openssh in unstable.

Michael: would you be up for upload, or should I proceed with a cherry-
pick and upload to DELAYED ?

Cheers,

OdyX



Bug#807393: libupnp: FTBFS: UpnpString.c:47:15: error: expected identifier or '(' before '__extension__'

Source: libupnp
Version: 1:1.6.19+git20141001-1
Severity: serious
Justification: fails to build from source
User: reproducible-bui...@lists.alioth.debian.org
Usertags: ftbfs
X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org

Dear Maintainer,

libupnp fails to build from source in unstable/amd64:

  [..]

  libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I.. -I../upnp/inc -I./inc
  -I../threadutil/inc -I../ixml/inc -I./src/inc -D_FORTIFY_SOURCE=2
  -pthread -g -O2 -fstack-protector-strong -Wformat
  -Werror=format-security -Wall -c src/genlib/net/http/webserver.c -fPIE
  -o src/genlib/net/http/libupnp_la-webserver.o >/dev/null 2>&1
  In file included from /usr/include/string.h:634:0,
   from src/api/UpnpString.c:23:
  src/api/UpnpString.c:47:15: error: expected identifier or '(' before
  '__extension__'
extern char *strndup(__const char *__string, size_t __n);
 ^
  Makefile:1266: recipe for target 'src/api/libupnp_la-UpnpString.lo'
  failed
  make[5]: *** [src/api/libupnp_la-UpnpString.lo] Error 1
  make[5]: *** Waiting for unfinished jobs
  libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I.. -I../upnp/inc -I./inc
  -I../threadutil/inc -I../ixml/inc -I./src/inc -D_FORTIFY_SOURCE=2
  -pthread -g -O2 -fstack-protector-strong -Wformat
  -Werror=format-security -Wall -c src/genlib/net/http/httpreadwrite.c
  -fPIE -o src/genlib/net/http/libupnp_la-httpreadwrite.o >/dev/null
  2>&1
  libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I.. -I../upnp/inc -I./inc
  -I../threadutil/inc -I../ixml/inc -I./src/inc -D_FORTIFY_SOURCE=2
  -pthread -g -O2 -fstack-protector-strong -Wformat
  -Werror=format-security -Wall -c src/genlib/net/uri/uri.c -fPIE -o
  src/genlib/net/uri/libupnp_la-uri.o >/dev/null 2>&1
  libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I.. -I../upnp/inc -I./inc
  -I../threadutil/inc -I../ixml/inc -I./src/inc -D_FORTIFY_SOURCE=2
  -pthread -g -O2 -fstack-protector-strong -Wformat
  -Werror=format-security -Wall -c src/gena/gena_callback2.c -fPIE -o
  src/gena/libupnp_la-gena_callback2.o >/dev/null 2>&1
  libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I.. -I../upnp/inc -I./inc
  -I../threadutil/inc -I../ixml/inc -I./src/inc -D_FORTIFY_SOURCE=2
  -pthread -g -O2 -fstack-protector-strong -Wformat
  -Werror=format-security -Wall -c src/gena/gena_device.c -fPIE -o
  src/gena/libupnp_la-gena_device.o >/dev/null 2>&1
  libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I.. -I../upnp/inc -I./inc
  -I../threadutil/inc -I../ixml/inc -I./src/inc -D_FORTIFY_SOURCE=2
  -pthread -g -O2 -fstack-protector-strong -Wformat
  -Werror=format-security -Wall -c src/gena/gena_ctrlpt.c -fPIE -o
  src/gena/libupnp_la-gena_ctrlpt.o >/dev/null 2>&1
  make[5]: Leaving directory
  
'/home/lamby/temp/cdt.20151208135019.7ibfei3i5o/libupnp-1.6.19+git20141001/upnp'
  Makefile:1393: recipe for target 'all-recursive' failed
  make[4]: *** [all-recursive] Error 1
  make[4]: Leaving directory
  
'/home/lamby/temp/cdt.20151208135019.7ibfei3i5o/libupnp-1.6.19+git20141001/upnp'
  Makefile:523: recipe for target 'all-recursive' failed
  make[3]: *** [all-recursive] Error 1
  make[3]: Leaving directory
  '/home/lamby/temp/cdt.20151208135019.7ibfei3i5o/libupnp-1.6.19+git20141001'
  Makefile:424: recipe for target 'all' failed
  make[2]: *** [all] Error 2
  make[2]: Leaving directory
  '/home/lamby/temp/cdt.20151208135019.7ibfei3i5o/libupnp-1.6.19+git20141001'
  dh_auto_build: make -j8 returned exit code 2
  debian/rules:20: recipe for target 'override_dh_auto_build' failed
  make[1]: *** [override_dh_auto_build] Error 2
  make[1]: Leaving directory
  '/home/lamby/temp/cdt.20151208135019.7ibfei3i5o/libupnp-1.6.19+git20141001'
  debian/rules:14: recipe for target 'binary' failed
  make: *** [binary] Error 2

  [..]

The full build log is attached.


Regards,

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


libupnp.1:1.6.19+git20141001-1.unstable.amd64.log.txt.gz
Description: Binary data


Bug#807401: libtext-unaccent-perl: FTBFS with perl 5.22 in experimental (MakeMaker changes)

Source: libtext-unaccent-perl
Version: 1.08-1
Severity: serious
Justification: transition imminent
User: debian-p...@lists.debian.org
Usertags: perl-5.22-transition makemaker-prefix
Tags: sid stretch

This package FTBFS with perl 5.22.0-2, which removed support for a long-
obsolete way of overriding PREFIX when calling 'make install' with
ExtUtils::MakeMaker, as described in the lintian tag
debian-rules-makemaker-prefix-is-deprecated[1] and the Debian Perl
policy[2]:


ERROR: Can't create '/usr/lib/x86_64-linux-gnu/perl5/5.22/Text'
mkdir /usr/lib/x86_64-linux-gnu/perl5/5.22/Text: Permission denied at /usr/share
/perl/5.22/ExtUtils/Install.pm line 477.


 at -e line 1.
Makefile:808: recipe for target 'pure_vendor_install' failed

The fix is to use DESTDIR instead of PREFIX; please see the lintian
`description for examples. Alternatively, newer versions of debhelper
can automatically call make install with the correct arguments when
using the dh7 style rules files.

The perl 5.22 is due to start this week, so apologies for the late
submission of this bug; for some reason my previous testing of this
issue overlooked this package.

Cheers,
Dominic.

[1] 

[2] 




Bug#784944: jessie-pu: package redmine/3.0~20140825-8~deb8u1 (was 3.0~20140825-7~deb8u1)

On Fri, Dec 04, 2015 at 03:39:07PM +, Adam D. Barratt wrote:
> Control: tags -1 + confirmed
> 
> On Fri, 2015-12-04 at 12:10 -0200, Antonio Terceiro wrote:
> [...]
> > > > > This release fixes several bugs related to upgrades from wheezy. The
> > > > > equivalent version is already in testing. I have tested it 
> > > > > extensively,
> > > > > and received positive feedback from multiple bug submitters.
> [...]
> > This is my third ping, and since it was initially posted, this stable
> > update request received no feedback at all. As already mentioned, I have
> > been using this in production, and have pointed several users who
> > reported bugs after the jessie release to it, fixing some issues, and in
> > the worst case having no negative effects.
> 
> Apologies for the delay; I'm not sure how this managed to slip through
> the cracks for quite so long.
> 
> One comment:
> 
> +redmine (3.0~20140825-8~deb8u1) jessie; urgency=medium
> +
> +  * Backport as a stable update for Jessie.
> +
> + -- Antonio Terceiro   Sun, 10 May 2015 19:26:43 -0300
> +
> +redmine (3.0~20140825-8) unstable; urgency=medium
> +
> +  * Replace "interest" triggers with "interest-nowait" ones to avoid trigger
> +loops (Closes: #786763)
> +
> + -- Antonio Terceiro   Fri, 10 Jul 2015 20:07:20 -0300
> 
> Those dates look a little odd. I'm assuming that the date on the first
> stanza is from when the initial package was prepared, and hasn't been
> updated in line with later backporting.

Yes, that was exacly it.

> With that in mind, please go ahead.

Just uploaded, with the changelog entry timestamp updated to today.

Thanks

-- 
Antonio Terceiro 


signature.asc
Description: PGP signature


Bug#780363: Bug has been patched upstream

Hello,

I reported this bug also against drm-intel [1] and it has been fixed by a 
patch found in comment 51 of that bug [2]. Now, the patch has also entered 
kernel 4.4-rc4

I recompiled the module manually with the patch above on linux-4.2 from 
stable-bpo and it fixes the issue.

Do you think this could be backported to the kernel version present in jessie 
(3.16) ? The patch cannot be applied directly to that version.

Kind regards


[1] https://bugs.freedesktop.org/show_bug.cgi?id=90725
[2] 
http://cgit.freedesktop.org/drm-intel/commit/?id=a53f2afb7e3dfc2c7acbb0c015b44783d99d8119



Bug#807387: zookeeper: Hit by ZOOKEEPER-706


Subject: zookeeper: Hit by ZOOKEEPER-706
Package: zookeeper
Version: 3.4.5+dfsg-2
Severity: normal
Tag: upstream fixed-upstream

Dear Maintainer,

In situations where a large number of watches are in place (such as when 
heavy YARN + heavy HBase traffic takes place on a moderately busy 
cluster), zookeeper session re-establishment can fail.


As a consequence, YARN ResourceManager fails to start after a fail-over 
situation, causing all sort of trouble down the line.


This has been identified and fixed upstream in 
https://issues.apache.org/jira/browse/ZOOKEEPER-706, which made it into 
release 3.4.7


As a workaround, I have been able to add this to /etc/zookeeper/zoo.cf:

   #
   # 2015-12-08 -- workaround for ZOOKEEPER-706
   # default is 0xf
   https://zookeeper.apache.org/doc/r3.3.2/zookeeperAdmin.html
   # got issues with lengths as big as 1820946
   jute.maxbuffer=4194303
   # 0x3f

Although the messages from ZOOKEEPER-1162 suggested deploying the 
jute.maxbuffer increase in both client and server side settings, adding 
that just to zoo.cfg seemed enough to clear proceed on my workload.


-- Cyrille

-- System Information:
Debian Release: 8.1
  APT prefers stable
  APT policy: (950, 'stable'), (850, 'testing'), (800, 'unstable'), 
(500, 'stable-updates')

Architecture: amd64 (x86_64)

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

Versions of packages zookeeper depends on:
ii  adduser  3.113+nmu3
ii  libzookeeper-java3.4.6-8
ii  openjdk-8-jre-headless [java6-runtime-headless]  8u45-b14-2

zookeeper recommends no packages.

zookeeper suggests no packages.

-- Configuration Files:
/etc/zookeeper/conf_example/myid changed [not included]
/etc/zookeeper/conf_example/zoo.cfg changed [not included]

-- no debconf information



Bug#806816: webkit2gtk: FTBFS on sparc64

On Wed, Dec 02, 2015 at 07:57:36PM -0600, David Matthew Mattli wrote:

> The other potential issue with webkit2gtk is that bmalloc assumes 4k
> pages and sparc64 has 8k pages. Does the Debian package use bmalloc
> by default? If so it will have to be disabled for sparc64 and use
> the system malloc instead. If you're not sure I'll verify what it's
> doing after I look at gtk.

If you try webkit2gtk again please use this patch:

   https://trac.webkit.org/changeset/193648

I'll include it in the next release.

Berto



Bug#803644: fixed in julia 0.4.2-1

Control: reopen -1

On Mon, 07 Dec 2015 19:21:54 + Peter Colberg  wrote:
>  julia (0.4.2-1) unstable; urgency=medium
>  .
>* Imported Upstream version 0.4.2
>* Refresh patches.
>* Upload to unstable. (Closes: #803644)

Your package now build-depends on llvm-3.8 (as the first alternative). That is
built from src:llvm-toolchain-snapshot, which means it won't migrate to testing,
and thus your package won't either.

Please drop that, or at least make llvm-3.7 the first alternative.

@Sylvestre: I wonder if llvm-toolchain-snapshot could build a -snapshot package
instead of versioned packages, as people get confused and use that (this is not
the first time).

Cheers,
Emilio



Bug#806965: oclgrind: FTBFS on ppc64el -- conflict with altivec keyword bool

Hello, James.

J Price  wrote on 07/12/2015 22:32:48:

> From: J Price 
> To: Fernando Seiti Furusato/Brazil/IBM@IBMBR
> Cc: Andreas Beckmann , 806...@bugs.debian.org, 
cont...@bugs.debian.org
> Date: 07/12/2015 22:32
> Subject: Re: Bug#806965: oclgrind: FTBFS on ppc64el -- conflict with 
altivec 
> keyword bool
> 
> OK, the ppc64el build is still failing with the __vector patch. It's
> not clear to me where the errors are originating.
> 
The errors are pretty much the same.
But the problem is with keyword bool, not vector.

> Perhaps we need to #undef these macros in cl.h after  is
> included, to prevent them from causing problems in the source files
> that include cl.h?
Yes, the solution would be the same used with __vector, but for bool as 
well.
I can test it here. I will let you know.

Thanks.



Bug#807403: wine: Sound doesn't work anymore with Windows games

Package: wine
Version: 1.8~rc3-1
Severity: important

Dear Maintainer,

* What led up to the situation?

  Upgrading wine from 1.7.52 (wine-development) to 1.7.55. I have tested with
  wine 1.8~rc3 and the problem persist.

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

  I have seen that there is a new pulseaudio driver. I supose it doesn't work
  properly. When I execute some Windows game that worked perfectly with 1.7.52,
  I get all funcionality except sound.

  If I try to configure sound with winecfg the only option for output devide is
  System default or pulseaudio. Clicking on Test sound I hear the test without
  problems.

Thank you very much.

-- 
David

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

Kernel: Linux 4.2.0-1-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 wine depends on:
ii  wine32  1.8~rc3-1
ii  wine64  1.8~rc3-1

wine recommends no packages.

Versions of packages wine suggests:
ii  dosbox   0.74-4.2
ii  wine-binfmt  1.8~rc3-1

Versions of packages wine is related to:
ii  fonts-wine1.8~rc2-1
ii  libwine   1.8~rc3-1
pn  libwine-dbg   
pn  libwine-dev   
ii  wine  1.8~rc3-1
ii  wine321.8~rc3-1
ii  wine32-preloader  1.8~rc3-1
pn  wine32-tools  
ii  wine641.8~rc3-1
ii  wine64-preloader  1.8~rc3-1
pn  wine64-tools  

-- no debconf information



Bug#807405: ITP: python-senlinclient -- OpenStack Clustering API Client Library

Package: wnpp
Severity: wishlist
Owner: Thomas Goirand 

* Package name: python-senlinclient
  Version : 0.1.8
  Upstream Author : OpenStack Foundation 
* URL : https://github.com/openstack/python-senlinclient
* License : Apache-2.0
  Programming Lang: Python
  Description : OpenStack Clustering API Client Library

 This is a client library for Senlin built on the Senlin clustering API. It
 provides a Python API (the senlinclient module) and a command-line tool
 (senlin).

This is a new dependency for Heat: the autoscalling server of OpenStack.



Bug#807408: icewm: Tktray icons sometimes not fully visible

Package: icewm
Version: 1.3.8+githubmod+20150914+fa3fdef-2~bpo8+1
Severity: normal

Dear Maintainer,

to work around the problem with the system tray when applications requesting
the system tray are placed in ~/icewm/startup which is still there in
icewm-1.3.8-2 from Jessie I installed 1.3.8+githubmod+20150914+fa3fdef-2 from
Jessie-backports which apparently fixes this "startup-bug".
However, the new version introduces a new problem which seems to be specific to
tktray icons. Sometimes (not always, but according to my tests in most cases)
the icon is not displayed properly, but only a very small portion of the icon,
maybe 3 or 4 pixels in width, is visble on the screen. I never observed this
problem in older versions of IceWm, so it seems likely to me that this new bug
may be related to the changes in the system tray handling that helped fix the
"startup-bug" that was there in older versions of IceWM.

This may or may not be related to the problem described in bug #539490 .

A simple tcl script that exhibits the problem:

#!/usr/bin/wish
wm withdraw .
package require tktray
set imgdata "R0lGODlhEAAQAMIE/4CAgMDAwP///yH+\
FUNyZWF0ZWQgd2l0aCBUaGUgR0lNUAAh+QQBCgAHACwAEAAQAAADSHi63C4wx\
jeqrQIwQbrvkLZwQGkS4UYAQduimcq6ASwqJF2n4/dlkJFpWBIMRByfxxg7hIAAaM\
oIOFqrWE1S6TkqiOCSY+xIAAA7"
image create photo .i -data $imgdata
tktray::icon .t -image .i

This should put a (useless) icon into the system tray, which actually works
with 1.3.8-2 and older versions. OTOH a similar simple Python script that draws
a gtk tray icon seems to run flawlessly with
1.3.8+githubmod+20150914+fa3fdef-2:

#!/usr/bin/env python
import gtk
icon = gtk.status_icon_new_from_stock(gtk.STOCK_HELP)
gtk.main()

so it looks to me like this problem is specific to tktray icons.




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

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

Versions of packages icewm depends on:
ii  fonts-dejavu-core   2.34-1
ii  icewm-common1.3.8+githubmod+20150914+fa3fdef-2~bpo8+1
ii  libc6   2.19-18+deb8u1
ii  libesd0 0.2.41-11
ii  libfontconfig1  2.11.0-6.3
ii  libgcc1 1:4.9.2-10
ii  libgdk-pixbuf2.0-0  2.31.1-2+deb8u3
ii  libglib2.0-02.42.1-1
ii  libice6 2:1.0.9-1+b1
ii  libsm6  2:1.2.2-1+b1
ii  libx11-62:1.6.2-3
ii  libxext62:1.3.3-1
ii  libxft2 2.3.2-1
ii  libxinerama12:1.1.3-1+b1
ii  libxrandr2  2:1.4.2-1+b1
ii  ttf-dejavu-core 2.34-1

icewm recommends no packages.

icewm suggests no packages.

-- no debconf information



Bug#807392: libsendmail-milter-perl: FTBFS: Segmentation fault (core dumped)

Control: tag -1 + unreproducible

On Tue, 08 Dec 2015 14:14:40 +0200, Chris Lamb wrote:

> Source: libsendmail-milter-perl
> Version: 0.18-8
> Severity: serious
> Justification: fails to build from source
> User: reproducible-bui...@lists.alioth.debian.org
> Usertags: ftbfs
> X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org
> 
> Dear Maintainer,
> 
> libsendmail-milter-perl fails to build from source in unstable/amd64:
> 
>   [..]
> 
>  dh_auto_test
>   make -j1 test TEST_VERBOSE=1
>   make[1]: Entering directory
>   
> '/home/lamby/temp/cdt.20151208135010.1cIlOB0yFG/libsendmail-milter-perl-0.18'
>   Running Mkbootstrap for Sendmail::Milter ()
>   chmod 644 Milter.bs
>   PERL_DL_NONLAZY=1 /usr/bin/perl "-Iblib/lib" "-Iblib/arch" test.pl
>   ---> Starting callback from interpreter: [0x7feeac0008e0].
>   ---> Finished callback from interpreter: [0x7feeac0008e0].
>   ---> Starting callback from interpreter: [0x7feeac0008e0].
>   ---> Finished callback from interpreter: [0x7feeac0008e0].
>   ---> Starting callback from interpreter: [0x7feeac0008e0].
>   ---> Finished callback from interpreter: [0x7feeac0008e0].
>   ---> Starting callback from interpreter: [0x7feeac0008e0].
>   ---> Finished callback from interpreter: [0x7feeac0008e0].
>   ---> Starting callback from interpreter: [0x7feeac0008e0].
>   ---> Finished callback from interpreter: [0x7feeac0008e0].
>   ---> Starting callback from interpreter: [0x7feeac0008e0].
>   ---> Finished callback from interpreter: [0x7feeac0008e0].
>   ---> Starting callback from interpreter: [0x7feea8e0].
>   ---> Finished callback from interpreter: [0x7feea8e0].
>   ---> Starting callback from interpreter: [0x7feea8e0].
>   ---> Finished callback from interpreter: [0x7feea8e0].
>   Segmentation fault (core dumped)
>   Makefile:992: recipe for target 'test_dynamic' failed
>   make[1]: *** [test_dynamic] Error 139
>   make[1]: Leaving directory
>   
> '/home/lamby/temp/cdt.20151208135010.1cIlOB0yFG/libsendmail-milter-perl-0.18'
>   dh_auto_test: make -j1 test TEST_VERBOSE=1 returned exit code 2
>   debian/rules:4: recipe for target 'build' failed
>   make: *** [build] Error 2

This builds fine for me (cowbuilder sid amd64):

   dh_auto_test
make -j1 test TEST_VERBOSE=1
make[1]: Entering directory '/build/libsendmail-milter-perl-0.18'
Running Mkbootstrap for Sendmail::Milter ()
chmod 644 Milter.bs
PERL_DL_NONLAZY=1 /usr/bin/perl "-Iblib/lib" "-Iblib/arch" test.pl
---> Starting callback from interpreter: [0x7fbbc8e0].
---> Finished callback from interpreter: [0x7fbbc8e0].
---> Starting callback from interpreter: [0x7fbbc8e0].
---> Finished callback from interpreter: [0x7fbbc8e0].
---> Starting callback from interpreter: [0x7fbbc8e0].
---> Finished callback from interpreter: [0x7fbbc8e0].
---> Starting callback from interpreter: [0x7fbbc8e0].
---> Finished callback from interpreter: [0x7fbbc8e0].
---> Starting callback from interpreter: [0x7fbbb40008e0].
---> Finished callback from interpreter: [0x7fbbb40008e0].
---> Starting callback from interpreter: [0x7fbbc8e0].
---> Finished callback from interpreter: [0x7fbbc8e0].
---> Starting callback from interpreter: [0x7fbbc8e0].
---> Finished callback from interpreter: [0x7fbbc8e0].
---> Starting callback from interpreter: [0x7fbbb80008e0].
---> Finished callback from interpreter: [0x7fbbb80008e0].
---> Starting callback from interpreter: [0x7fbbb80008e0].
---> Finished callback from interpreter: [0x7fbbb80008e0].
---> Starting callback from interpreter: [0x7fbbb8e0].
---> Finished callback from interpreter: [0x7fbbb8e0].
---> Starting callback from interpreter: [0x7fbbb8e0].
---> Finished callback from interpreter: [0x7fbbb8e0].
---> Starting callback from interpreter: [0x7fbba80008e0].
---> Finished callback from interpreter: [0x7fbba80008e0].
---> Starting callback from interpreter: [0x7fbba80008e0].
---> Finished callback from interpreter: [0x7fbba80008e0].
---> Starting callback from interpreter: [0x7fbba80008e0].
---> Finished callback from interpreter: [0x7fbba80008e0].
---> Starting callback from interpreter: [0x7fbbc8e0].
---> Finished callback from interpreter: [0x7fbbc8e0].
---> Starting callback from interpreter: [0x7fbbc8e0].
---> Finished callback from interpreter: [0x7fbbc8e0].
---> Starting callback from interpreter: [0x7fbba80008e0].
---> Finished callback from interpreter: [0x7fbba80008e0].
---> Starting callback from interpreter: [0x7fbba80008e0].
---> Finished callback from interpreter: [0x7fbba80008e0].
---> Starting callback from interpreter: [0x7fbbc8e0].
---> Finished callback from interpreter: [0x7fbbc8e0].
---> Starting callback from interpreter: [0x7fbbc8e0].
---> Finished callback from interpreter: [0x7fbbc8e0].
test_wrapper: Original interpreter cloned: 0x020a7010
test_wrapper: Analysing callback...
test_wrapper: It's a code reference to: 0xc007ab20
test_wrapper: Calling 

Bug#807407: icedove: stable 38.4 seems to forget SMTP password, can't send email


Carsten, many thanks for your quick reply!

Quoting Carsten Schoenert :

Can you please enable some logging as explained on

  https://wiki.debian.org/Icedove#Debugging_Icedove_Activity

an investigate probably errors?


Yes, it shows that there is an SMTP login error. Log attached.
Thank you for the hint how to generate it!


But something like "EWS" looks like Calendar Exchange Provider?


You catched me! :~) Yes, this was a local, adhoc backport.
I removed the extension now to concentrate on the SMTP problem.
Note, that a colleague faced the same SMTP problem today, but
they does not have calendar-exchange-provider installed.
As for me, a downgrade solved their problem for now.


There is also a hint for iceowl-extension on not remebered passwords,
maybe this is issue?

https://wiki.debian.org/Icedove#Iceowl-extension_does_not_remember_credentials


This is problably the cause of the message, that I related
wrongly to the SMTP sending failure.

I wonder what your SMTP config is? Mine is:

Server: mydomain.com
Port: 587
Username: username
Auth method: NTLM
Security: STARTTLS

Cheers
SMTP Connecting to: mail.mydomain.com
SMTP entering state: 0
SMTP Response: 220 mail.mydomain.com Microsoft ESMTP MAIL Service ready at Tue, 
8 Dec 2015 15:33:36 +0100
SMTP entering state: 14
SMTP Send: EHLO [192.168.1.2]
SMTP entering state: 0
SMTP Response: 250-mail.mydomain.com Hello [192.168.1.2]
SMTP entering state: 0
SMTP Response: 250-SIZE 10485760
SMTP entering state: 0
SMTP Response: 250-PIPELINING
SMTP entering state: 0
SMTP Response: 250-DSN
SMTP entering state: 0
SMTP Response: 250-ENHANCEDSTATUSCODES
SMTP entering state: 0
SMTP Response: 250-STARTTLS
SMTP entering state: 0
SMTP Response: 250-AUTH GSSAPI NTLM
SMTP entering state: 0
SMTP Response: 250-8BITMIME
SMTP entering state: 0
SMTP Response: 250-BINARYMIME
SMTP entering state: 0
SMTP Response: 250 CHUNKING
SMTP entering state: 4
SMTP entering state: 21
SMTP Send: STARTTLS
SMTP entering state: 0
SMTP Response: 220 2.0.0 SMTP server ready
SMTP entering state: 19
SMTP entering state: 14
SMTP Send: EHLO [192.168.1.2]
SMTP entering state: 0
SMTP Response: 250-mail.mydomain.com Hello [192.168.1.2]
SMTP entering state: 0
SMTP Response: 250-SIZE 10485760
SMTP entering state: 0
SMTP Response: 250-PIPELINING
SMTP entering state: 0
SMTP Response: 250-DSN
SMTP entering state: 0
SMTP Response: 250-ENHANCEDSTATUSCODES
SMTP entering state: 0
SMTP Response: 250-AUTH GSSAPI NTLM LOGIN
SMTP entering state: 0
SMTP Response: 250-8BITMIME
SMTP entering state: 0
SMTP Response: 250-BINARYMIME
SMTP entering state: 0
SMTP Response: 250 CHUNKING
SMTP entering state: 4
SMTP entering state: 21
SMTP auth: server caps 0x24914, pref 0xC000, failed 0x0, avail caps 0x4000
(GSSAPI = 0x800, CRAM = 0x2000, NTLM = 0x4000, MSN =  0x8000, PLAIN = 0x200, 
LOGIN = 0x100, EXTERNAL = 0x400)
trying auth method 0x4000
SMTP entering state: 16
SMTP AuthLoginStep1() for username@whatever
NTLM/MSN auth, step 1
Logging suppressed for this command (it probably contained authentication 
information)
SMTP entering state: 0
SMTP Response: 334 ...
SMTP entering state: 18
SMTP Login response, code 334
SMTP entering state: 17
SMTP AuthLoginStep2
NTLM/MSN auth, step 2
Logging suppressed for this command (it probably contained authentication 
information)
SMTP entering state: 0
SMTP Response: 535 5.7.3 Authentication unsuccessful
SMTP entering state: 18
SMTP Login response, code 535
marking auth method 0x4000 failed
SMTP auth: server caps 0x24914, pref 0xC000, failed 0x4000, avail caps 0x0
(GSSAPI = 0x800, CRAM = 0x2000, NTLM = 0x4000, MSN =  0x8000, PLAIN = 0x200, 
LOGIN = 0x100, EXTERNAL = 0x400)
no auth method remaining
SMTP: ask user what to do (after login failed): new password, retry or cancel
new password button pressed
marking auth method 0x800 failed
marking auth method 0x400 failed
SMTP: login failed: failed C00, current 0
SMTP entering state: 21
SMTP auth: server caps 0x24914, pref 0xC000, failed 0xC00, avail caps 0x4000
(GSSAPI = 0x800, CRAM = 0x2000, NTLM = 0x4000, MSN =  0x8000, PLAIN = 0x200, 
LOGIN = 0x100, EXTERNAL = 0x400)
trying auth method 0x4000
SMTP entering state: 16
SMTP AuthLoginStep1() for username@whatever
NTLM/MSN auth, step 1
Logging suppressed for this command (it probably contained authentication 
information)
SMTP entering state: 0
SMTP Response: 334 ...
SMTP entering state: 18
SMTP Login response, code 334
SMTP entering state: 17
SMTP AuthLoginStep2
NTLM/MSN auth, step 2
Logging suppressed for this command (it probably contained authentication 
information)
SMTP entering state: 0
SMTP Response: 535 5.7.3 Authentication unsuccessful
SMTP entering state: 18
SMTP Login response, code 535
marking auth method 0x4000 failed
SMTP auth: server caps 0x24914, pref 0xC000, failed 0x4C00, avail caps 0x0
(GSSAPI = 0x800, CRAM = 0x2000, NTLM = 0x4000, MSN =  0x8000, PLAIN = 0x200, 
LOGIN = 0x100, EXTERNAL = 0x400)
no auth method remaining
SMTP: ask user what to do (after 

Bug#807258: For information


JKB  wrote:

>   I have a sendmail server (8.15.2) running debian linux, 
spamassasin,

>   clamav and milter-greylist (4.4.3 and I have tried 4.5.16). This
>   configuration ran like a charm until last sendmail upgrade.

So what are the changes in that "last sendmail upgrade"?
Is that an official sendmail version or something patched by the "vendor"?

If it is based on a 8.16.0 snapshot then maybe a version before .6
was used? There was a problem in one of those:

  sendmail snapshot 8.16.0.6 is available for testing. It fixes a
  regression in 8.16 which could generate bogus SMTP replies in some
  cases (and even with a 5xy error instead of 4xy).



Bug#807412: ITP: python-protobix -- Python implementation of Zabbix Sender protocol

Package: wnpp
Severity: wishlist
Owner: Jean Baptiste Favre 

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

* Package name: python-protobix
  Version : 0.0.9
  Upstream Author : Jean Baptiste Favre 
* URL : https://github.com/jbfavre/python-protobix
* License : GPL
  Programming Lang: Python
  Description : Python implementation of Zabbix Sender protocol

This module implements Zabbix Sender Protocol.
It allows one to build list of items and send items and send them as trapper.
It currently supports items as well as Low Level Discovery.

I'm the author of the module and use it on a daily basis.
I'm also already packaging it at work.
Maintenance will be done through Debian Python Modules Team
I'll need a sponsor to get package uploaded.

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQJ8BAEBCgBmBQJWZuS1XxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ0RTg0NUJBMjMwQ0I0RDQ0ODkwNjk4NDdC
NERENTM2QUNGN0Q4NzM3AAoJELTdU2rPfYc33BMQAIiLp1pqUF73RPCBXJFmXYRW
9WnKPFe0O45WiiRpfpEB9o2bX1qU9vVswbbVgyOAdxveD2vuXtRxXwrysoUvgTa3
y2F62YWHcTkqctPoVd9C8uGdZSI8GBhrH17ZTEwLX1fA/TJ8vqFszESSOF1znlbi
gT1x0mIv1GLxFwuPULMbvEwi+D5BkCKEVuYt9idqsXETBTp6xu5pGwNDTVLe0mK7
CpDhEa526hBRISYPqWBTEHseUuaKvsOyRdouMdHLegbN3oGYVYspZO4dabgSktsf
OcGvNxfhzP2vF4hbwcRxnnI0573jaDpgcRRymK4SgkjdT87DAd4HfWlK/9wb9vEZ
Ll0P8oZljCP51Xvb0h9ZInUWp4XFqB+3GPlOHF+Frl/NkWM5OR3pwnQcgdI9S6dE
Q9D4PgN+MIYZ7WHJX6NVdPjRsV8k/6EHVFPzR0zalUgpPDHSl+PmNZIkBZvEzSAs
SoATkBtDkNE1Ry6niX4/71Z3qf4khD7bdeD6EXkK1y16eflUHj5eIqLbwo+EWM/4
U1G2P+r/UWyA/RBtqKQPUjwuN6DOm5eXie/fVZYC7G/9FMrmeQFJ4g2svpgFlcsG
t1Lx/AWBDoBjQZnhX8Jp3JAw2axunfRqPbb5B6IHPo1e4UVEKQrbxjnolnkTFhOz
Lyy3AQDRitoyP6C0XD+A
=pm+X
-END PGP SIGNATURE-



Bug#807407: icedove: stable 38.4 seems to forget SMTP password, can't send email

Hello Martin,

I'm working here in my company also with a Exchange 2010 server via
IMAP/SMTP and have no trouble at all with Icedove from Jessie.

On Tue, Dec 08, 2015 at 02:48:17PM +0100, W. Martin Borgert wrote:
> When starting icedove, I get the following, unexpected dialog:
> 
> Microsoft Exchange EWS: Password request.
> 
> Enter password for mydomain\myusername on
> https://mymailserver/ews/exchange.asmx
> 
> 
> 
> [ ] Use Password Manager to remember this password.
> 
> [ Cancel ] [ OK ]
> 
> When I enter my supposed password and click on OK,
> the dialog appears again.
> 
> When I click on Cancel instead, the program continues,
> but sending email via SMTP to the MS server fails,
> probably because of the missing password.

Can you please enable some logging as explained on

  https://wiki.debian.org/Icedove#Debugging_Icedove_Activity

an investigate probably errors?

But something like "EWS" looks like Calendar Exchange Provider? Or do I
miss something? But as you use version 38.4.0-1~deb8u1 there is no
Debian package for this in backports.

  https://packages.debian.org/sid/mail/calendar-exchange-provider

There is also a hint for iceowl-extension on not remebered passwords,
maybe this is issue?

  https://wiki.debian.org/Icedove#Iceowl-extension_does_not_remember_credentials

Regards
Carsten



Bug#807413: apt: autoremoval of build-deps is broken

Package: apt
Version: 1.1.4
Severity: normal

Hello,

Recently my sid chroot started becoming cluttered, and afaict
autoremove is broken now. I cannot say when this started though.

(sid)root@argenau:/# dpkg -l > /tmp/0.before
(sid)root@argenau:/# DEBIAN_FRONTEND=noninteractive eatmydata apt-get --purge  
build-dep p11-kit
Reading package lists... Done
Building dependency tree   
Reading state information... Done
The following NEW packages will be installed:
  autoconf automake autopoint autotools-dev debhelper dh-autoreconf
  dh-strip-nondeterminism libffi-dev libfile-stripnondeterminism-perl
  libtasn1-6 libtasn1-6-dev libtool pkg-config po-debconf
0 upgraded, 14 newly installed, 0 to remove and 0 not upgraded.
Need to get 0 B/3244 kB of archives.
After this operation, 7939 kB of additional disk space will be used.
[...]
(sid)root@argenau:/# DEBIAN_FRONTEND=noninteractive eatmydata apt-get --purge 
autoremove
Reading package lists... Done
Building dependency tree   
Reading state information... Done
The following packages will be REMOVED:
  debhelper* dh-autoreconf* dh-strip-nondeterminism* libffi-dev*
  libfile-stripnondeterminism-perl* libtasn1-6* libtasn1-6-dev* pkg-config*
  po-debconf*
0 upgraded, 0 newly installed, 9 to remove and 0 not upgraded.
After this operation, 2836 kB disk space will be freed.
(sid)root@argenau:/# DEBIAN_FRONTEND=noninteractive eatmydata apt-get --purge 
autoremove
Reading package lists... Done
Building dependency tree   
Reading state information... Done
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
(sid)root@argenau:/# diff /tmp/0.before /tmp/1.after 
7a8,11
> ii  autoconf  2.69-9  all  
> automatic configure script builder
> ii  automake  1:1.15-3all  Tool 
> for generating GNU Standards-compliant Makefiles
> ii  autopoint 0.19.6-1all  The 
> autopoint program from GNU gettext
> ii  autotools-dev 20150820.1  all  Update 
> infrastructure for config.{guess,sub} files
152a157
> ii  libtool   2.4.2-1.11  all  
> Generic library support script
(sid)root@argenau:/# for i in autoconf automake autopoint autotools-dev libtool 
; do apt-mark showauto | grep $i || echo $i is manual ; done
autoconf
automake
autopoint
autotools-dev
libtool
(sid)root@argenau:/# DEBIAN_FRONTEND=noninteractive eatmydata apt-get --purge 
remove automake
Reading package lists... Done
Building dependency tree   
Reading state information... Done
The following packages will be REMOVED:
  automake*
0 upgraded, 0 newly installed, 1 to remove and 0 not upgraded.
After this operation, 1749 kB disk space will be freed.
Do you want to continue? [Y/n] 
(Reading database ... 14034 files and directories currently installed.)
Removing automake (1:1.15-3) ...
Processing triggers for man-db (2.7.5-1) ...
(sid)root@argenau:/# DEBIAN_FRONTEND=noninteractive eatmydata apt-get --purge 
autoremove
Reading package lists... Done
Building dependency tree   
Reading state information... Done
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
(sid)root@argenau:/# DEBIAN_FRONTEND=noninteractive eatmydata apt-get --purge 
remove autoconf
Reading package lists... Done
Building dependency tree   
Reading state information... Done
The following packages will be REMOVED:
  autoconf*
0 upgraded, 0 newly installed, 1 to remove and 0 not upgraded.
After this operation, 1914 kB disk space will be freed.
Do you want to continue? [Y/n] 
(Reading database ... 13903 files and directories currently installed.)
Removing autoconf (2.69-9) ...
Purging configuration files for autoconf (2.69-9) ...
Processing triggers for man-db (2.7.5-1) ...
(sid)root@argenau:/# DEBIAN_FRONTEND=noninteractive eatmydata apt-get --purge 
autoremove
Reading package lists... Done
Building dependency tree   
Reading state information... Done
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
(sid)root@argenau:/# DEBIAN_FRONTEND=noninteractive eatmydata apt-get --purge 
remove autopoint
Reading package lists... Done
Building dependency tree   
Reading state information... Done
The following packages will be REMOVED:
  autopoint*
0 upgraded, 0 newly installed, 1 to remove and 0 not upgraded.
After this operation, 459 kB disk space will be freed.
Do you want to continue? [Y/n] 
(Reading database ... 13824 files and directories currently installed.)
Removing autopoint (0.19.6-1) ...
Processing triggers for man-db (2.7.5-1) ...
(sid)root@argenau:/# DEBIAN_FRONTEND=noninteractive eatmydata apt-get --purge 
autoremove
Reading package lists... Done
Building dependency tree   
Reading state information... Done
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
(sid)root@argenau:/# DEBIAN_FRONTEND=noninteractive eatmydata apt-get --purge 
remove libtool
Reading package lists... Done

Bug#807410: phpgacl: [INTL: pt_BR] Brazilian Portuguese debconf templates translation

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256


Package: phpgacl
Tags: l10n patch
Severity: wishlist

Hello,

Please, Could you update the Brazilian Portuguese Translation?

Attached you will find the file pt_BR.po. It is UTF-8 encoded and it is
tested with msgfmt and podebconf-display-po.

Kind regards.

- -- 
Leonardo Rocha
4096R/7E7D1FE2
about.me/leonardo.rocha
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJWZuEbAAoJECRiL6p+fR/iAiMQAJi1IXpV/x4NW6N8XZlxngzK
8/AklyA09k+OaeFT1dW4ubU7rsM9SZb4dBqDVgFKCex7q9kS9Wzzv0yzLmjZIx3H
CaOIQyrUlZ5GmiGDVc46Lk2pKe80mpIMBim/7M4yFJMaLHLhKktOLnqH0VHumj+h
OMdj0Tkizqpsiz7VPWqK0GHCzZwTi5LaBAxxPDsc3dufiPkgw2fn0k4/hMXpGRZs
wzgYutGFlVTGCv8jaHKq+bY/hWF65umo0q2q08G0WxBCgLflNM20EQOa077qDYS+
zV+uN6at0v7lX/99NTQ7kbaPSu9GbcV6ellhrNstQzjftFKZ/RmJMsqAypnVUm8s
5+xQf/rmgNwBejm2jZ38OORjZOcbGl3SQ/s8IENMY/0tjEi3sYxUCM2S1pQFp8/Y
6mjMHduS1SvxRYMJh9y8ht9nrP4KnJANCybb13ZrzrptALyYtKQedvgUIKnwkd3L
diVY9pi9VRwHyfaXRkffyGOmHrFGWERnI3a7LnBDDho9rJ3J2Kcynu6hEzawN7VE
YO6LyK91d9Cm2MtDn6yhuNxxSGN8yXo6nakHoQnWksyc4L8rjEs9v0oVBFiywlcW
kXojy0UfqpRwLmvJzAwLLoZ/ulW//s7INdEuNML0wsRt2reUz8B4SEt5d/AdrHBs
WcUaybOi0qkR/XgzN+Tt
=5dCI
-END PGP SIGNATURE-


pt_BR.po.gz
Description: application/gzip


pt_BR.po.gz.sig
Description: PGP signature


Bug#807409: using python3 to run the pep8 binary


Package: src:pep8
Version: 1.6.2-0.1
Severity: wishlist
Tags: patch

trying to use python3 only, and running without a python (2.x) binary; 
converting the pep8 binary to use python3.


This introduces a python-pep8 package, and unfortunately breaking some packages 
which not only require the pep8 binary, but also the pep8 module.


among these are prospector, python-flake8, shortuuid, actdiag.

https://patches.ubuntu.com/a/actdiag/actdiag_0.5.3-5ubuntu1.patch
https://patches.ubuntu.com/p/python-flake8/python-flake8_2.2.2-1ubuntu4.patch
https://patches.ubuntu.com/s/shortuuid/shortuuid_0.4.2-4ubuntu1.patch
http://launchpadlibrarian.net/229121519/prospector_0.10.1%2Bgit20150706.a00e191-1_0.10.1%2Bgit20150706.a00e191-1ubuntu1.diff.gz
  * Let the pep8 binary use python3.
  * Build a python-pep8 package.
  * Don't depend on setuptools, pkg-resources is good enough.
 
diff -pruN 1.6.2-0.1/debian/control 1.6.2-0.1ubuntu2/debian/control
--- 1.6.2-0.1/debian/control	2015-10-25 20:06:09.0 +
+++ 1.6.2-0.1ubuntu2/debian/control	2015-10-25 20:06:09.0 +
@@ -8,15 +8,24 @@ Homepage: http://pypi.python.org/pypi/pe
 
 Package: pep8
 Architecture: all
-Depends: ${misc:Depends}, ${python:Depends}, python-setuptools
-Description: Python PEP 8 code style checker - python2
+Depends: ${misc:Depends}, ${python3:Depends}, python3-pep8
+Description: Python PEP 8 code style checker
+ Features a plugin architecture allowing for adding new checks is easily.
+ Parseable output listing line numbers of the error location.  Consists of
+ just one Python file, and requires only stdlib.
+
+Package: python-pep8
+Architecture: all
+Depends: ${misc:Depends}, ${python:Depends}, python-pkg-resources
+Replaces: pep8 (<< 1.6.2-0.1)
+Description: Python PEP 8 code style checker - python
  Features a plugin architecture allowing for adding new checks is easily.
  Parseable output listing line numbers of the error location.  Consists of
  just one Python file, and requires only stdlib.
 
 Package: python3-pep8
 Architecture: all
-Depends: ${misc:Depends}, ${python3:Depends}, python3-setuptools
+Depends: ${misc:Depends}, ${python3:Depends}, python3-pkg-resources
 Description: Python PEP 8 code style checker - python3
  Features a plugin architecture allowing for adding new checks is easily.
  Parseable output listing line numbers of the error location.  Consists of
diff -pruN 1.6.2-0.1/debian/rules 1.6.2-0.1ubuntu2/debian/rules
--- 1.6.2-0.1/debian/rules	2015-10-25 20:06:09.0 +
+++ 1.6.2-0.1ubuntu2/debian/rules	2015-10-25 20:06:09.0 +
@@ -17,11 +17,16 @@ PYTHON3S:=$(shell py3versions -vr)
 override_dh_auto_install:
 	set -e && for pyvers in $(PYTHONS); do \
 		python$$pyvers setup.py install --install-layout=deb \
-			--root $(CURDIR)/debian/pep8; \
+			--root $(CURDIR)/debian/python-pep8; \
 	done
 
 	set -e && for pyvers in $(PYTHON3S); do \
 		python$$pyvers setup.py install --install-layout=deb \
 			--root $(CURDIR)/debian/python3-pep8; \
 	done
-	rm -r $(CURDIR)/debian/python3-pep8/usr/bin
+	rm -rf debian/python-pep8/usr/bin
+	mkdir -p debian/pep8/usr
+	mv debian/python3-pep8/usr/bin debian/pep8/usr/.
+
+override_dh_python3:
+	dh_python3 --shebang=/usr/bin/python3


Bug#807371: apt hostname resoloution failure

On Tue, Dec 08, 2015 at 03:17:32AM +, peter green wrote:
> The chroot is on a host system running a vendor 3.0.90 kernel, no idea if
> that is relavent. At the very least if there is a problem running on older
> kernels there should be a warning before the updated packages are installed.

APT doesn't really care for kernel versions, it isn't THAT lowlevel.

> The issue seems to be new in the 1.1 series of apt versions.
> 
> The issue definately seems to be somehow related to dns lookups. If I add
> the hostname to /etc/resolv.conf then apt seems to work.

(I think you meant /etc/hosts)

My money is on Nils's suggestion, but if that isn't it the only recent
changes to resolving are IDN support (disable it via -o
Acquire::Connect::IDN=false) and support for SRV records (disable it via
-o Acquire::EnableSrvRecords=false). Neither should be responsible
through…


Best regards

David Kalnischkies


signature.asc
Description: PGP signature


Bug#806965: oclgrind: FTBFS on ppc64el -- conflict with altivec keyword bool

Fernando Seiti Furusato/Brazil/IBM wrote on 08/12/2015 09:13:26:

> From: Fernando Seiti Furusato/Brazil/IBM
> To: J Price 
> Cc: 806...@bugs.debian.org, Andreas Beckmann , 
> cont...@bugs.debian.org, Breno Henrique Leitao/Brazil/IBM@IBMBR
> Date: 08/12/2015 09:13
> Subject: Re: Bug#806965: oclgrind: FTBFS on ppc64el -- conflict with 
altivec 
> keyword bool
> 
> The errors are pretty much the same.
> But the problem is with keyword bool, not vector.

Turns out it is not as simple.
What helped a lot with vector is that it is being used to define a type
in a header, unlike bool which is used everywhere.
Also the first error is because it is used in an enum in a gcc header.
(/usr/include/c++/5/bits/cpp_type_traits.h)

Maybe it is worth (or possible?) trying to compile the parts that result
in error with the -mno-altivec part.
I am not sure how it all works, let me investigate further.

Regards



Bug#806898: RFS: roxterm/3.3.1-1

On Tue, Dec 08, 2015 at 01:59:56PM +, Tony Houghton wrote:
> I must remember to change the level in my lintian options as well as fixing

I believe (because I have a pbuilder hook that runs lintian for me, I
rarely run it manyally) just dumping the following in ~/.lintianrc is
enough:
info=yes
display-info=yes
display-experimental=yes
pedantic=yes
show-overrides=no
color=always

> this specific problem. It looks like a leftover from the deprecated debian
> menu entry, but for some reason I can't find it in debian/rules or the
> upstream build system.

just remove debian/dirs :)

-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
more about me:  http://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#805176: Please rebuild experimental version too

I have samba from experimental and the problem is still not fixed => I 
cannot rinstall the new lib without removing samba...


-- eric



Bug#807339: qgis: saga not available in processing toolbox

Control: tags -1 upstream

On 07-12-15 18:46, Sebastiaan Couwenberg wrote:
> On 07-12-15 17:53, Moritz Lennert wrote:
>> Installed qgis 2.8.3+dfsg-5 and saga 2.2.2-1 in current testing. Opened
>> toolbox, activated SAGA as service provider (there are two entries: SAGA
>> and SAGA (2.2.2), but only in the latter can you 'activate'). Then
>> opened the toolbox with the advanced interface.
> 
> The SAGA processing support is also missing from QGIS 2.8.4 available in
> experimental already and in unstable shortly.
> 
> @Johan, do you have any suggestions how to troubleshoot this?

It seems QGIS doesn't support SAGA 2.2.2 yet:

https://lists.osgeo.org/pipermail/qgis-developer/2015-December/040670.html

Kind Regards,

Bas

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



Bug#807406: pbuilder: drop all the 'xenial' hardcoding in debian/rules and make the selection of the distro dynamic

Package: pbuilder
Version: 0.221.2
Severity: wishlist
User: pbuil...@packages.debian.org
Usertags: pbuilder
X-Debbugs-Cc: locutusofb...@debian.org

With this upload I added a ifeq stanza in d/rules to automate the delta
that was done in ubuntu, including setting the default DISTRIBUTION to
xenial, the current development version.
They used to upload a new pbuilder at the start of every development
cycle to at least change that, that's bad.
In a sense this is not a regression, I just moved this hardcoding from
ubuntu to debian, but it'd be nice to get rid of it once and for all.

Suggestions includes using distro-info for getting the current
development version, but if run at runtime means a new dep (even if
light and most probably already installed on development machines), and
at build-time is still not granted to be run, ubuntu afaik does not
assure the packages to be rebuilt for every release.

-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
more about me:  http://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#807407: icedove: stable 38.4 seems to forget SMTP password, can't send email


Package: icedove
Version: 38.4.0-1~deb8u1
Severity: important

Why "important"? Can't send email anymore.

When starting icedove, I get the following, unexpected dialog:

Microsoft Exchange EWS: Password request.

Enter password for mydomain\myusername on  
https://mymailserver/ews/exchange.asmx




[ ] Use Password Manager to remember this password.

[ Cancel ] [ OK ]

When I enter my supposed password and click on OK,
the dialog appears again.

When I click on Cancel instead, the program continues,
but sending email via SMTP to the MS server fails,
probably because of the missing password.

Downgrading to 31.7.0-1~deb8u1 helps, but has the
disadvantage of exposing users to a dozen of CVEs.

I wonder whether this is related to #806918?



Bug#807411: f2fs-tools: New upstream version available (1.5.0)

Package: f2fs-tools
Version: 1.4.1-1
Severity: wishlist

According to
http://git.kernel.org/cgit/linux/kernel/git/jaegeuk/f2fs-tools.git
there's a 1.5.0 version available. Please consider packaging it.

Note: https://packages.qa.debian.org/f/f2fs-tools.html reports:
"There is a temporary or permanent problem with the debian/watch file
included in the package."

That seems to be a correct assesment ;-)

Regards,
  Diederik

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

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

Versions of packages f2fs-tools depends on:
ii  libc6 2.21-3
ii  libuuid1  2.27.1-1

f2fs-tools recommends no packages.

f2fs-tools suggests no packages.

-- no debconf information



Bug#759657: console-setup w/ systemd forgets font setting

Control: severity -1 important


On Thu, 19 Nov 2015 13:31:57 -0500 Eric Cooper wrote:

[...]
> I see the same problem on every reboot.
> 
> While booting, it looks like the font switches from VGA to Terminus
> during the boot messages.  But then the screen is cleared and the
> getty login prompts are back in VGA.  If I run "setupcon" manually, it
> changes to Terminus.

I am experiencing the same exact issue on the boxes where systemd is
PID 1.
I have different console settings, but they are not restored at boot,
until I manually issue the setupcon command.

I think the severity of this bug is at least important.
Failing to set the console configuration at boot with systemd (which is
the current default init system in Debian) is a really annoying
misbehavior.

Dear console-setup maintainers, this bug has been reported quite some
time ago: is there any progress on this?

Please fix this issue.
Thanks for your time!

Bye.


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


pgptvHZ_2t48m.pgp
Description: PGP signature


Bug#807404: python-matplotlib: Incomplete redraw after zoom-in -> zoom-out

Package: python-matplotlib
Version: 1.5.0~rc2-1
Severity: important

Dear Maintainer,

When using matplotlib in the standard configuration the figure is not
redrawn after an zoom-in/zoom out sequence or when zooming out using the
rigth mouse button. 


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

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

Versions of packages python-matplotlib depends on:
ii  libatk1.0-0   2.18.0-1
ii  libc6 2.19-22
ii  libcairo2 1.14.4-1
ii  libfontconfig12.11.0-6.3
ii  libfreetype6  2.6-2
ii  libgcc1   1:5.2.1-23
ii  libgdk-pixbuf2.0-02.32.2-1
ii  libglib2.0-0  2.46.2-1
ii  libgtk2.0-0   2.24.28-1
ii  libjs-jquery  1.11.3+dfsg-4
ii  libjs-jquery-ui   1.10.1+dfsg-1
ii  libpango-1.0-01.38.1-1
ii  libpangocairo-1.0-0   1.38.1-1
ii  libpangoft2-1.0-0 1.38.1-1
ii  libpng12-01.2.50-2+b2
ii  libstdc++65.2.1-23
ii  libtcl8.6 8.6.4+dfsg-2
ii  libtk8.6  8.6.4+dfsg-2
ii  python2.7.9-1
ii  python-cycler 0.9.0-1
ii  python-dateutil   2.2-2
ii  python-matplotlib-data1.5.0~rc2-1
ii  python-numpy [python-numpy-abi9]  1:1.9.2-5
ii  python-pyparsing  2.0.3+dfsg1-1
ii  python-tz 2012c+dfsg-0.1
pn  python:any

Versions of packages python-matplotlib recommends:
ii  python-glade2   2.24.0-4
ii  python-imaging  2.9.0-1
ii  python-tk   2.7.9-1

Versions of packages python-matplotlib suggests:
pn  dvipng 
ii  ghostscript9.16~dfsg-2
ii  gir1.2-gtk-3.0 3.18.2-1
ii  inkscape   0.91-6
ii  ipython2.3.0-2
ii  librsvg2-common2.40.11-1
pn  python-cairocffi   
pn  python-configobj   
pn  python-excelerator 
pn  python-gobject 
ii  python-gtk22.24.0-4
pn  python-matplotlib-doc  
ii  python-nose1.3.6-1
ii  python-qt4 4.11.4+dfsg-1+b2
ii  python-scipy   0.16.1-1
ii  python-sip 4.17+dfsg-1
pn  python-tornado 
pn  python-traits  
pn  python-wxgtk3.0
pn  texlive-extra-utils
pn  texlive-latex-extra
pn  ttf-staypuft   

-- no debconf information



Bug#807368: Fwd: Re: polymake ticket notification: #879: polymake 2.14r1 fails to build with gmp 6.1

Sending the attachment manually as it didn't come with the notification.

Benjamin Lorenz
>From f293923ae20196f34b1348bae9338fed0387388c Mon Sep 17 00:00:00 2001
From: Christof Soeger 
Date: Tue, 8 Dec 2015 12:04:40 +0100
Subject: [PATCH] fix libnormaliz for gmp 6.1

adapted from upstream 14b874f017:
Resolve ambiguous calls of gcd for gmp 6.1.0

gmp 6.1.0 introduced gcd and lcm in their c++ interface. This made the
call of gcd(mpz_class&, mpz_class&) ambiguous.
Resolved it by explicitly calling the libnormaliz version to keep
compatibility to older gmp versions.
---
 ChangeLog | 3 +++
 bundled/libnormaliz/external/libnormaliz/HilbertSeries.cpp| 2 +-
 bundled/libnormaliz/external/libnormaliz/integer.cpp  | 2 +-
 bundled/libnormaliz/external/libnormaliz/matrix.cpp   | 4 ++--
 bundled/libnormaliz/external/libnormaliz/simplex.cpp  | 2 +-
 .../libnormaliz/external/libnormaliz/sublattice_representation.cpp| 4 ++--
 bundled/libnormaliz/external/libnormaliz/vector_operations.cpp| 2 +-
 7 files changed, 11 insertions(+), 8 deletions(-)

diff --git a/ChangeLog b/ChangeLog
index f4c4012..ee2ea7d 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,5 +1,8 @@
 Changelog
 
+-- general --
+ * fix building of libnormaliz with gmp 6.1
+
 === Polymake 2.14r1 ===
 
 -- general --
diff --git a/bundled/libnormaliz/external/libnormaliz/HilbertSeries.cpp b/bundled/libnormaliz/external/libnormaliz/HilbertSeries.cpp
index 38b97f2..c38120d 100644
--- a/bundled/libnormaliz/external/libnormaliz/HilbertSeries.cpp
+++ b/bundled/libnormaliz/external/libnormaliz/HilbertSeries.cpp
@@ -355,7 +355,7 @@ void HilbertSeries::computeHilbertQuasiPolynomial() const {
 //divide by gcd //TODO operate directly on vector
 Matrix QP(quasi_poly);
 mpz_class g = QP.matrix_gcd();
-g = gcd(g,quasi_denom);
+g = libnormaliz::gcd(g,quasi_denom);
 quasi_denom /= g;
 QP.scalar_division(g);
 quasi_poly = QP.get_elements();
diff --git a/bundled/libnormaliz/external/libnormaliz/integer.cpp b/bundled/libnormaliz/external/libnormaliz/integer.cpp
index 91552b4..94016ab 100644
--- a/bundled/libnormaliz/external/libnormaliz/integer.cpp
+++ b/bundled/libnormaliz/external/libnormaliz/integer.cpp
@@ -88,7 +88,7 @@ Integer lcm(const Integer& a, const Integer& b){
 return 0;
 }
 else
-return Iabs(a*b/gcd(a,b));
+return Iabs(a*b/libnormaliz::gcd(a,b));
 }
 
 template<> mpz_class lcm(const mpz_class& a, const mpz_class& b) {
diff --git a/bundled/libnormaliz/external/libnormaliz/matrix.cpp b/bundled/libnormaliz/external/libnormaliz/matrix.cpp
index 8f27ab5..b5c2262 100644
--- a/bundled/libnormaliz/external/libnormaliz/matrix.cpp
+++ b/bundled/libnormaliz/external/libnormaliz/matrix.cpp
@@ -638,7 +638,7 @@ Integer Matrix::matrix_gcd() const{
 Integer g=0,h;
 for (size_t i = 0; i  1) {
 c /= g;
 B.scalar_division(g);
@@ -303,7 +303,7 @@ Matrix Sublattice_Representation::get_congruences() const {
 //new_row cannot be 

Bug#807369: apparmor: Apparmor "deny network" not working in Jessie

Hi,

Adam Jvok wrote (08 Dec 2015 06:49:23 GMT) :
> Does this imply that 'deny network' isn't going to work in any future debian
> unless someone has published a patch before the kernel is built
> (Or, unless this functionality goes in the kernel proper, eliminating the 
> need for
> a patch.)?

The latter.

> Are there any plans to rectify this?

It's been a longstanding item on AppArmor kernel hackers' todo list to
upstream this patch. I don't know what's the current best-case ETA.

> Without a fix it may be time to drop apparmor in favor of something else.

Mediating network access would be a welcome bonus feature, but it's
not part of the core set of functionality that made me personally
start working on AppArmor in Debian.

But if your needs are different, then of course nobody forces you to
use AppArmor instead of some more appropriate tool. For example,
a private network namespace should do the job.

Cheers,
-- 
intrigeri



Bug#807399: libkf5su-bin: kdesud not group suid and owned by root (instead of nobody)


¡Hola Martin!

El 2015-12-08 a las 13:22 +0100, Martin Graesslin escribió:
Package: libkf5su-bin 
Version: 5.16.0-1 
Severity: important


I noticed that the file 
/usr/lib/x86_64-linux-gnu/libexec/kf5/kdesud



is group owned by "root" and not group suid.



Given the CMake snippet from the source package:
install(TARGETS kdesud DESTINATION ${KDE_INSTALL_LIBEXECDIR_KF5}) 
install(CODE " 
   set(KDESUD_PATH \"\$ENV{DESTDIR}${CMAKE_INSTALL_FULL_LIBEXECDIR_KF5}/kdesud\") 
   execute_process(COMMAND sh -c \"chgrp nogroup '\${KDESUD_PATH}' && chmod g+s '\${KDESUD_PATH}'\") 
")


The permissions set by cmake are later tweaked in the package build process. I 
don't see any "gain" gaining the nogroup group as suggests the previous 
snippet. Is this to be able to write to global directory? If so, we would need 
to create a specific group.


--
Se necesitan voluntarios para dominar el mundo.
Saludos /\/\ /\ >< `/


signature.asc
Description: Digital signature


Bug#807041: logind: laptop unexpectedly auto-suspends after some time of inactivity

Am 08.12.2015 um 00:30 schrieb George B.:
> On 04/12/15 14:39, Michael Biebl wrote:
>>
>> Can you attach the output of (as root)
>> journalctl -u systemd-logind
>>
>> and mark the time when the auto-suspend happens.
> 
> ```
> -- Logs begin at Mon 2015-12-07 14:25:13 GMT, end at Mon 2015-12-07
> 23:26:59 GMT. --
> Dec 07 14:25:15 deli systemd[1]: Starting Login Service...
> Dec 07 14:25:15 deli systemd-logind[920]: New seat seat0.
> Dec 07 14:25:15 deli systemd[1]: Started Login Service.
> Dec 07 14:25:15 deli systemd-logind[920]: Watching system buttons on
> /dev/input/event9 (Power Button)
> Dec 07 14:25:15 deli systemd-logind[920]: Watching system buttons on
> /dev/input/event10 (Video Bus)
> Dec 07 14:25:15 deli systemd-logind[920]: Watching system buttons on
> /dev/input/event7 (Power Button)
> Dec 07 14:25:15 deli systemd-logind[920]: Watching system buttons on
> /dev/input/event6 (Lid Switch)
> Dec 07 14:25:15 deli systemd-logind[920]: Watching system buttons on
> /dev/input/event8 (Sleep Button)
> Dec 07 14:25:15 deli systemd-logind[920]: Watching system buttons on
> /dev/input/event14 (Dell WMI hotkeys)
> Dec 07 14:25:26 deli systemd-logind[920]: New session 1 of user borisov.
> Dec 07 19:37:36 deli systemd-logind[920]: Suspending...
> Dec 07 23:26:28 deli systemd-logind[920]: Operation 'sleep' finished.
> ```
> 
> The "Suspending" message would be around the time that the suspend
> happened (~15 minutes after I left it alone).

Have you set IdleAction= and IdleActionSec= in /etc/systemd/logind.conf?

If not, this looks like the suspend request is triggered externally and
logind simply executes the action.

Do you have a tool like xfce4-power-manager, mate-power-manager,
lxqt-powermanagement etc installed?

Does systemd-inhibit list anything?

Can you run dbus-monitor --system (as root) and check if you get any
dbus messages for org.freedesktop.login1 at the time the suspend happens.



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



Bug#807414: calendar-exchange-provider: Please provide backport for Jessie (stable)


Package: calendar-exchange-provider
Version: 3.4.0-1
Severity: wishlist

Thanks for maintaining this very useful plugin!

I use a local, adhoc backport without any source changes and
it works fine with Icedove 31.7. 38.4 is under investigation).

An official backport would be nice!



Bug#807045: winetricks output: wineserver not found!

Hi,

do you have wine32 installed? If not please execute:
  sudo dpkg --add-architecture i386 &&
  sudo apt update &&
  sudo apt install wine32

Greets
jre



Bug#671288: revalidación

Se requiere que vuelva a validar su cuenta debido al sistema de mantenimiento 
constante. Actualizar su cuenta haciendo clic en el siguiente enlace de 
revalidación.

"Clic aquí" para volver a validar tu 
cuenta.

Saludos,
Mesa de ayuda
@ 2015. Todos los derechos reservados.


Bug#807421: fsharp: crashes on invocation with old libfsharp-core4.3-cil

Package: fsharp
Version: 4.0.0.4+dfsg2-1

Dear Maintainer,

(Sorry to be reporting a bug in an experimental package, feel free to
close if you don't want to track this sort of issue here.)

In order to run Hypelib http://hypelib.github.io/Hype/ and DiffSharp
http://diffsharp.github.io/DiffSharp/index.html, which requires F# 4.x,
I did an "aptitude install fsharp/experimental" and then rejected
solutions until it got one that only removed old libraries, and
upgraded/installed a heap of stuff including in particular the
experimental mono packages.

Invoking fsharpi or fsharpc dumped core.

Then I noticed that

$ apt-cache policy libfsharp-core4.3-cil
libfsharp-core4.3-cil:
  Installed: 3.1.1.26+dfsg2-3
  Candidate: 3.1.1.26+dfsg2-3
  Version table:
 4.0.0.4+dfsg2-1 0
  1 http://ftp.ie.debian.org/debian/ experimental/main amd64 Packages
 *** 3.1.1.26+dfsg2-3 0
850 http://ftp.ie.debian.org/debian/ jessie/main amd64 Packages

When I installed libfsharp-core4.3-cil/experimental, fsharpi and fsharpc
stopped dumping core and started to work.

Currently the dependency on libfsharp-core4.3-cil is unversioned.
It should probably be versioned like the libmono* libraries.

Cheers,

--Barak.
--
Barak A. Pearlmutter 
 Dept Comp Sci & Hamilton Institute, Maynooth University, Co. Kildare, Ireland
 http://barak.pearlmutter.net



Bug#807413: apt: autoremoval of build-deps is broken

On Tue, Dec 08, 2015 at 04:08:55PM +0100, Andreas Metzler wrote:
> So after build-dep/autoremove five additional packages are installed, they are
> marked as autoinstalled and have no rdeps, but still autoremove does not grab
> them.

They probably have reverse Recommends or reverse Suggests keeping them
installed.

-- 
Julian Andres Klode  - Debian Developer, Ubuntu Member

See http://wiki.debian.org/JulianAndresKlode and http://jak-linux.org/.

When replying, only quote what is necessary, and write each reply
directly below the part(s) it pertains to (`inline'). Thank you.



Bug#807399: libkf5su-bin: kdesud not group suid and owned by root (instead of nobody)

> The permissions set by cmake are later tweaked in the package build process.
> I don't see any "gain" gaining the nogroup group as suggests the previous
> snippet. Is this to be able to write to global directory? If so, we would
> need to create a specific group.

I don't know why the nogroup is set. On my quick view I didn't see any reason 
for it.

I guess only svn history might tell us ;-)

Cheers
Martin


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


Bug#807413: apt: autoremoval of build-deps is broken

On 2015-12-08 Julian Andres Klode  wrote:
> On Tue, Dec 08, 2015 at 04:08:55PM +0100, Andreas Metzler wrote:
> > So after build-dep/autoremove five additional packages are installed, they 
> > are
> > marked as autoinstalled and have no rdeps, but still autoremove does not 
> > grab
> > them.

> They probably have reverse Recommends or reverse Suggests keeping them
> installed.

I see. Shouldn't Recommends/Suggests be ignored by autoremove when 
APT::Install-Recommends "false";
APT::Install-Suggests "false";
are set?

cu Andreas
-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'
Auto-Installed : libtool:amd64
Auto-Installed : autoconf:amd64
Auto-Installed : autopoint:amd64
Auto-Installed : automake:amd64
Auto-Installed : autotools-dev:amd64
AutoDep: libtool:amd64
AutoDep: autoconf:amd64
AutoDep: autopoint:amd64
AutoDep: automake:amd64
AutoDep: autotools-dev:amd64
Following dep: gcc:amd64 4:5.2.1-8 Suggests autoconf:amd64
Marking: autoconf:amd64 2.69-9, Curr=2.69-9, Inst=2.69-9
Following dep: autoconf:amd64 2.69-9 Depends perl:amd64 (> 5.005)
Following dep: autoconf:amd64 2.69-9 Depends perl:amd64 (> 5.005)
Following dep: autoconf:amd64 2.69-9 Depends m4:amd64 (>= 1.4.13)
Following dep: autoconf:amd64 2.69-9 Depends debianutils:amd64 (>= 1.8)
Following dep: autoconf:amd64 2.69-9 Recommends automake:amd64
Marking: automake:amd64 1:1.15-3, Curr=1:1.15-3, Inst=1:1.15-3
Following dep: automake:amd64 1:1.15-3 Depends autoconf:amd64 (>= 2.65)
Following dep: automake:amd64 1:1.15-3 Depends autotools-dev:amd64 (>= 
20020320.1)
Marking: autotools-dev:amd64 20150820.1, Curr=20150820.1, Inst=20150820.1
Following dep: automake:amd64 1:1.15-3 Suggests autoconf-doc:amd64
Following dep: automake:amd64 1:1.15-3 Suggests gnu-standards:amd64
Following dep: autoconf:amd64 2.69-9 Recommends automake:amd64
Following dep: autoconf:amd64 2.69-9 Recommends automaken:amd64 , provided by 
automake1.11:amd64 1:1.11.6-3
Following dep: autoconf:amd64 2.69-9 Recommends automaken:amd64 , provided by 
automake:amd64 1:1.15-3
Following dep: autoconf:amd64 2.69-9 Recommends automaken:amd64 , provided by 
automake:amd64 1:1.14.1-4
Following dep: autoconf:amd64 2.69-9 Suggests autoconf-archive:amd64
Following dep: autoconf:amd64 2.69-9 Suggests gnu-standards:amd64
Following dep: autoconf:amd64 2.69-9 Suggests autoconf-doc:amd64
Following dep: autoconf:amd64 2.69-9 Suggests libtool:amd64
Marking: libtool:amd64 2.4.2-1.11, Curr=2.4.2-1.11, Inst=2.4.2-1.11
Following dep: libtool:amd64 2.4.2-1.11 Depends gcc:amd64
Following dep: libtool:amd64 2.4.2-1.11 Depends c-compiler:amd64 , provided by 
clang-3.7:amd64 1:3.7.1~+rc2-1~exp1
Following dep: libtool:amd64 2.4.2-1.11 Depends c-compiler:amd64 , provided by 
tcc:amd64 0.9.27~git20140923.9d7fb33-3
Following dep: libtool:amd64 2.4.2-1.11 Depends c-compiler:amd64 , provided by 
clang-3.8:amd64 1:3.8~svn254193-1
Following dep: libtool:amd64 2.4.2-1.11 Depends c-compiler:amd64 , provided by 
clang-3.7:amd64 1:3.7-4
Following dep: libtool:amd64 2.4.2-1.11 Depends c-compiler:amd64 , provided by 
clang-3.6:amd64 1:3.6.2-3
Following dep: libtool:amd64 2.4.2-1.11 Depends c-compiler:amd64 , provided by 
clang-3.5:amd64 1:3.5.2-3
Following dep: libtool:amd64 2.4.2-1.11 Depends c-compiler:amd64 , provided by 
clang-3.4:amd64 1:3.4.2-16
Following dep: libtool:amd64 2.4.2-1.11 Depends c-compiler:amd64 , provided by 
bcc:amd64 0.16.17-3.1
Following dep: libtool:amd64 2.4.2-1.11 Depends c-compiler:amd64 , provided by 
gcc:amd64 4:5.2.1-8
Following dep: libtool:amd64 2.4.2-1.11 Depends c-compiler:amd64 , provided by 
gcc-5:amd64 5.3.1-3
Following dep: libtool:amd64 2.4.2-1.11 Depends c-compiler:amd64 , provided by 
gcc-4.9:amd64 4.9.3-9
Following dep: libtool:amd64 2.4.2-1.11 Depends c-compiler:amd64 , provided by 
gcc-4.8:amd64 4.8.5-2
Following dep: libtool:amd64 2.4.2-1.11 Depends cpp:amd64
Following dep: libtool:amd64 2.4.2-1.11 Depends libc6-dev:amd64
Following dep: libtool:amd64 2.4.2-1.11 Depends libc6-dev:amd64
Following dep: libtool:amd64 2.4.2-1.11 Depends libc-dev:amd64 , provided by 
libc6-dev:amd64 2.22-0experimental0
Following dep: libtool:amd64 2.4.2-1.11 Depends libc-dev:amd64 , provided by 
libc6-dev:amd64 2.21-3
Following dep: libtool:amd64 2.4.2-1.11 Depends file:amd64
Following dep: libtool:amd64 2.4.2-1.11 Depends autotools-dev:amd64
Following dep: libtool:amd64 2.4.2-1.11 Recommends libltdl-dev:amd64
Following dep: libtool:amd64 2.4.2-1.11 Suggests libtool-doc:amd64
Following dep: libtool:amd64 2.4.2-1.11 Suggests autoconf:amd64 (> 2.50)
Following dep: libtool:amd64 2.4.2-1.11 Suggests automaken:amd64 , provided by 
automake1.11:amd64 1:1.11.6-3
Following dep: libtool:amd64 2.4.2-1.11 Suggests automaken:amd64 , provided by 
automake:amd64 1:1.15-3
Following dep: libtool:amd64 2.4.2-1.11 Suggests automaken:amd64 , provided by 
automake:amd64 1:1.14.1-4
Following dep: libtool:amd64 

Bug#807418: iceweasel: missing/incorrect timestamps (for 3 files) in iceweasel*.deb package

Package: iceweasel
Version: 38.2.1esr-1~deb8u1
Severity: normal

Dear Maintainer,

Iceweasel package contains 3 files with incorrect timestamp.
All 3 files have a modification date of 2010, February 1st:

/usr/share/iceweasel/browser/defaults/preferences/firefox-branding.js
/usr/share/iceweasel/browser/defaults/preferences/firefox.js
/usr/share/iceweasel/browser/defaults/preferences/webide-prefs.js

This timestamps are the very same since numerous versions of iceweasel,
depite the fact that the content of the last 2 files changes with every
new version/update of Iceweasel.

This is especially annoying with backups using "rsync" without the "-c"
option for performance reasons. Those files are skipped and not transrferred,
even if the content has changed. This is only discovered when using checksums.

I think with current Debians "reproducible builds" aktivities such things
should not happen anymore.

-- Package-specific info:

-- Extensions information
Name: Classic Theme Restorer
Location: ${PROFILE_EXTENSIONS}/classicthemeresto...@arist2noia4dev.xpi
Status: enabled

Name: Deutsch (DE) Language Pack locale
Location: 
/usr/lib/iceweasel/browser/extensions/langpack...@iceweasel.mozilla.org.xpi
Package: iceweasel-l10n-de
Status: enabled

Name: Ghostery
Location: ${PROFILE_EXTENSIONS}/fire...@ghostery.com.xpi
Status: enabled

Name: HTTPS-Everywhere
Location: ${PROFILE_EXTENSIONS}/https-everywhere-...@eff.org
Status: enabled

Name: Privacy Badger
Location: ${PROFILE_EXTENSIONS}/jid1-mnnxcxisbpnsxq-...@jetpack.xpi
Status: enabled

Name: Standard theme
Location: 
/usr/lib/iceweasel/browser/extensions/{972ce4c6-7e08-4474-a285-3208198ce6fd}
Package: iceweasel
Status: enabled

-- Plugins information
Name: DivX Browser Plug-In
Location: /usr/lib/mozilla/plugins/gecko-mediaplayer-dvx.so
Package: gecko-mediaplayer
Status: enabled

Name: mplayerplug-in is now gecko-mediaplayer 1.0.9
Location: /usr/lib/mozilla/plugins/gecko-mediaplayer.so
Package: gecko-mediaplayer
Status: enabled

Name: QuickTime Plug-in 7.6.9
Location: /usr/lib/mozilla/plugins/gecko-mediaplayer-qt.so
Package: gecko-mediaplayer
Status: enabled

Name: RealPlayer 9
Location: /usr/lib/mozilla/plugins/gecko-mediaplayer-rm.so
Package: gecko-mediaplayer
Status: enabled

Name: Windows Media Player Plug-in
Location: /usr/lib/mozilla/plugins/gecko-mediaplayer-wmp.so
Package: gecko-mediaplayer
Status: enabled


-- Addons package information
ii  gecko-mediapla 1.0.9-2  amd64Multimedia plug-in for Gecko brow
ii  iceweasel  38.2.1esr-1~ amd64Web browser based on Firefox
ii  iceweasel-l10n 1:38.2.1esr- all  German language package for Icewe

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

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

Versions of packages iceweasel depends on:
ii  debianutils   4.5.1
ii  fontconfig2.11.0-6.3
ii  libasound21.0.29-1
ii  libatk1.0-0   2.18.0-1
ii  libc6 2.19-22
ii  libcairo2 1.14.4-1
ii  libdbus-1-3   1.10.4-1
ii  libdbus-glib-1-2  0.102-1
ii  libevent-2.0-52.0.21-stable-2+b1
ii  libffi6   3.2.1-3
ii  libfontconfig12.11.0-6.3
ii  libfreetype6  2.6.1-0.1
ii  libgcc1   1:5.2.1-23
ii  libgdk-pixbuf2.0-02.32.2-1
ii  libglib2.0-0  2.46.2-1
ii  libgtk2.0-0   2.24.28-1
ii  libhunspell-1.3-0 1.3.3-3+b2
ii  libpango-1.0-01.38.1-1
ii  libsqlite3-0  3.9.2-1
ii  libstartup-notification0  0.12-4
ii  libstdc++65.2.1-23
ii  libx11-6  2:1.6.3-1
pn  libxcomposite1
ii  libxdamage1   1:1.1.4-2+b1
ii  libxext6  2:1.3.3-1
ii  libxfixes31:5.0.1-2+b2
ii  libxrender1   1:0.9.9-2
ii  libxt61:1.1.5-1
ii  procps2:3.3.10-2
ii  zlib1g1:1.2.8.dfsg-2+b1

Versions of packages iceweasel recommends:
ii  gstreamer1.0-libav 1:1.6.1-dmo1
ii  gstreamer1.0-plugins-good  1.6.1-1

Versions of packages iceweasel suggests:
ii  fonts-mathjax  2.5.3-1
pn  fonts-oflb-asana-math  
ii  fonts-stix [otf-stix]  1.1.1-4
ii  libcanberra0   0.30-2.1
ii  libgnomeui-0   2.24.5-3
ii  libgssapi-krb5-2   1.13.2+dfsg-4
pn  mozplugger 

-- no debconf information



Bug#807420: lwjgl: FTBFS on ppc64el: error: wrong type argument to unary exclamation mark

Source: lwjgl
Version: 2.7.1+dfsg-4
Severity: normal
Tags: patch

Dear Maintainer,

I am aware that this package has a newer version available.
But since it is in the repository, it would be good to have it building on
ppc64el as well.

The reason for the failure is because altivec is enabled by default on
ppc64el so all gets compiled with flag -maltivec on.
Consequently, macros definitions from altivec.h such as bool, vector and 
pixel get replaced along the code.

I included -mcpu-powerpc if the arch is ppc64le, but I am not sure this is
the best way to do so.

I know it works, because I tested on x86_64 and ppc64el.

Regards.

Fernando

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

Kernel: Linux 3.16.0-4-amd64 (SMP w/1 CPU core)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
diff -Nru lwjgl-2.7.1+dfsg/debian/changelog lwjgl-2.7.1+dfsg/debian/changelog
--- lwjgl-2.7.1+dfsg/debian/changelog	2014-10-26 20:43:24.0 -0400
+++ lwjgl-2.7.1+dfsg/debian/changelog	2015-12-08 11:01:36.0 -0500
@@ -1,3 +1,11 @@
+lwjgl (2.7.1+dfsg-4.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * debian/patches/ppc64el.patch: patch adds cflag -mcpu=powerpc
+when on target compiledeb on ppc64le, to fix ftbfs on ppc64el 
+
+ -- Fernando Seiti Furusato   Tue, 08 Dec 2015 10:57:30 -0500
+
 lwjgl (2.7.1+dfsg-4) unstable; urgency=low
 
   * Update packaging standards.
diff -Nru lwjgl-2.7.1+dfsg/debian/patches/ppc64el.patch lwjgl-2.7.1+dfsg/debian/patches/ppc64el.patch
--- lwjgl-2.7.1+dfsg/debian/patches/ppc64el.patch	1969-12-31 19:00:00.0 -0500
+++ lwjgl-2.7.1+dfsg/debian/patches/ppc64el.patch	2015-12-08 11:01:36.0 -0500
@@ -0,0 +1,24 @@
+Index: lwjgl-2.7.1+dfsg/platform_build/linux_ant/build.xml
+===
+--- lwjgl-2.7.1+dfsg.orig/platform_build/linux_ant/build.xml
 lwjgl-2.7.1+dfsg/platform_build/linux_ant/build.xml
+@@ -23,6 +23,10 @@
+ 		
+ 			
+ 		
++		
++			
++		
++		
+ 		
+ 			
+ 		
+@@ -124,7 +128,7 @@
+ 	
+ 	
+ 	
+-			
++			
+ 			
+ 			
+ 			
diff -Nru lwjgl-2.7.1+dfsg/debian/patches/series lwjgl-2.7.1+dfsg/debian/patches/series
--- lwjgl-2.7.1+dfsg/debian/patches/series	2014-10-26 20:31:04.0 -0400
+++ lwjgl-2.7.1+dfsg/debian/patches/series	2015-12-08 11:01:36.0 -0500
@@ -2,3 +2,4 @@
 allarchs.patch
 systemjinput.patch
 javadoc.patch
+ppc64el.patch


Bug#807045: winetricks output: wineserver not found!

On 12/08/2015 05:52 PM, Jens Reyer wrote:
> do you have wine32 installed? If not please execute:
>   sudo dpkg --add-architecture i386 &&
>   sudo apt update &&
>   sudo apt install wine32

[Sorry, sent the mail to early]
The first two lines are unnecessary on your system.

Now, if you have wine32 installed and it still doesn't work, please try
the following (all in the same terminal):
  export WINEARCH=win32
  export WINE=/usr/bin/wine
  export WINESERVER=/usr/lib/i386-linux-gnu/wine/wineserver
  winetricks ...

Please tell us your findings

Greets
jre



Bug#805721: jessie-pu: package exim4/4.84-8+deb8u2

On 2015-11-28 Andreas Metzler  wrote:
> On 2015-11-21 Andreas Metzler  wrote:
>> Package: release.debian.org
>> Severity: normal
>> Tags: jessie
>> User: release.debian@packages.debian.org
>> Usertags: pu

>> I would like to fix 805576 for jessie:

> Please wait on that, I think I might need to add another MIME fix.

Nevermind, the MIME issue does not apply to jessie.

cu Andreas
-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'



  1   2   3   >