Bug#685134: [s390-tools] please add patch from qemu

2016-02-03 Thread Viktor Mihajlovski
On 02.02.2016 01:01, Dimitri John Ledkov wrote:
> On Fri, 17 Aug 2012 11:21:04 +0200 bastien ROUCARIES
>  wrote:
>> Package: s390-tools
>> Severity: important
>> Tags: patch
>>
>> Please add http://repo.or.cz/w/s390-tools.git for booting s390 from qemu. it 
>> port virtio.
>>
>> I have ported the pach queue to recent s390-tools. Not tested only merge 
>> without conflict.
>>
>> Thanks
>>
>> Bastien
> 
> Hello,
> 
> Is this still required? I see that qemu-2.5 has support for booting El
> Torito .iso images, and it boots Debian off virtio block drives just
> fine.
> 
> Granted, it looks like debian packaging strips the s390 firmware file,
> and doesn't rebuild it. Maybe that should simply be fixed and that's
> it?
> 
> Regards,
> 
> Dimitri.
> 

Right, including the firmware file would be the proper way to enable
QEMU for booting on s390.

-- 

Mit freundlichen Grüßen/Kind Regards
   Viktor Mihajlovski

IBM Deutschland Research & Development GmbH
Vorsitzender des Aufsichtsrats: Martina Köderitz
Geschäftsführung: Dirk Wittkopp
Sitz der Gesellschaft: Böblingen
Registergericht: Amtsgericht Stuttgart, HRB 243294



Bug#813539: [Pkg-privacy-maintainers] Bug#813539: Bug#813539: tails-installer: tails installer fails to sense usb stick

2016-02-03 Thread intrigeri
Hi,

S. Banerian wrote (02 Feb 2016 23:22:42 GMT) :
> well, whenever I try the tails-installer-launcher, it never shows the
> usb stick.

OK, I got it this time :)

> that's why i tried CLI, to look for more debug information!  :)
> If there is a way to use the launcher, and get the installer to sense
> the usb stick, that would be nice

You can try:

 $ export DEBUG=1
 $ tails-installer-launcher

=> and then the stdout + stderr should hopefully have enough info.

Cheers,
-- 
intrigeri



Bug#813128: Fwd: Bug#813128: transition: openmpi

2016-02-03 Thread Alastair McKinstry

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256



On 03/02/2016 00:09, Michael Banck wrote:
> On Tue, Feb 02, 2016 at 12:19:10AM +0100, Matthias Klose wrote:
>> On 01.02.2016 15:38, Emilio Pozuelo Monfort wrote:
>>> On 01/02/16 12:41, Alastair McKinstry wrote:

 The upload of openmpi1.10 triggered an auto-openmpi transition, as
 expected and wanted.
 The rest, is premature.
>>>
>>> The problem is that you uploaded the package directly to unstable,
without
>>> asking for a transition slot and without fixing those problems you
mention
>>> beforehand. It'd have been better to upload it to experimental until
things were
>>> ready.
>>>
>>> Since that has already happened, it'd be good to know what packages
build fine
>>> against the new openmpi and which ones don't.
>>
>> fyi, I was surprised as well, tried to go forward, and ended up with
>> http://people.canonical.com/~ubuntu-archive/transitions/html/openmpi.html
>> (only tried dependency level 1 to build).
>
> Thanks!
>
> I look at some of mine and they seem to FTBFS due to scalapack on longer
> being installable, which in turn is due to blacs-mpi FTBFSing:
>
> /usr/bin/ld: cannot find -lmpi_f77
>
> That library has vanished from libopenmpi-dev, Alastair, was that
> intentional, and if so, how is Fortran linking supposed to work now?
The fortran front-ends have been merged. The two supported ways to link
fortran are:
(1) Use mpifort / mpif77 / mpif90. mpifort preferred, or
(2) Use pkg-config mpi-fort --libs (recommended).

Don't rely on the names of the libraries provided as they may change
across versions and architectures.
I've been submitting patches where necessary for this.
>
> I removed that library from blacs-mpi link line and it built fine, but I
> am not sure this is the right fix.
>
>
> Michael
>
Alastair

- -- 
Alastair McKinstry, , ,
https://diaspora.sceal.ie/u/amckinstry
Misentropy: doubting that the Universe is becoming more disordered.
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJWsatsAAoJEMvmu05dmtOlsJQP/jXYupdQRNCs9qZzkuuqDphz
AbY+J5cxKeDq9mE5yUxzrkV1hQTc2Q8F/UnMhas9f5H5RkBDqViC1y9t+IygkDf5
tY7apqMu6GbjqJqFcoyZm2G305cJ1AjuUBnf71wqqGTCHAfvKnspXanzkTZtwADQ
QHotNfb1TW+lHu5oICF+hhEhjlPxJ2lLHsGOheXmBzn1wt3ftoMFs2EXx1rtUEft
U8EjYQvQN01bOZZZ3xM7PzlP8uZ5fGBv3EMa3kNzbCKKZYuxNh0EFR+73LaFIadN
QzhmbnGa6+XlGkInnaLK9ZGOPU/arfQt1dRnkOAvfnKln6eG6g+yqGLYUETpzSHq
CvA3rTsvLYRrLU4ZObvxb9FV8iS2MTuImaNBSKXVGciiax9Cx2JewTY0BZNuJoBM
Idv4WGb65o6WsZDEameQua0OUwGW77eFpWft/B81zcqRnW4HtAxNH4ED76ps5q4B
v1w+IjMNygJ9b3xh97k3e50XaigOoHQj2dnk1qrT8zxcU9Rp4u5kOmDEY7rgIY8+
fAHXmnwbqViGMJ+oJwxUblTL2EWjj4DghuOMLoQlebRQVSJCnIc9lvtt7iQHs5+o
EQx6NfTVNCI7jx+UWSzVBjWzmZu4s7087VnG/38MdpRhJ/iZpmmJIC69KBde0rSF
AgbpKPHm8SOKUwW5iHym
=LEGc
-END PGP SIGNATURE-



Bug#791195: fixed in lttoolbox 3.3.2~r61000-3.1

2016-02-03 Thread Tino Didriksen
On 3 February 2016 at 02:57, Andreas Beckmann  wrote:

> On Thu, 20 Aug 2015 16:00:44 + Julien Cristau 
> wrote:
> >  lttoolbox (3.3.2~r61000-3.1) unstable; urgency=medium
> >  .
> >* Non-maintainer upload.
> >* Rename library packages for g++5 ABI transition (closes: 791195).
>
> This change was recently reverted and I'm not convinced that this was a
> good idea.



That was my doing, on the basis that the transition should never have
happened.

Because I wasn't properly subscribed to this bug (due to using my mail@
address which procmail can't handle), I never knew the transition was
pushed through against my wishes, until I went to update lttoolbox to a
newer release.

There are only 2 other packages that depend on lttoolbox: apertium and
apertium-lex-tools, and I maintain those as well. All 3 are part of the
same upstream project, and are updated together if there are breaking
changes.

And because lttoolbox 3.3 was not even in testing at the time, nothing
outside my control could have built up dependencies on it, and indeed
nothing has.

The v5 transition was entirely unnecessary for this package, and I very
strongly want it gone.

-- Tino Didriksen


Bug#802738: ckeditor package based on dev branch and not on stable release branch

2016-02-03 Thread Dmitry Smirnov
Dear Frederique,

> I then
> came to realisation that the ckeditor package is based on the dev branch:
> https://github.com/ckeditor/ckeditor-dev
> 
> And not the release branch:
> https://github.com/ckeditor/ckeditor-releases
> 
> Is there any reason why this is the case? Would it be possible to use the
> stable release branch?

No it won't be possible because in CKeditor terminology "ckeditor-releases" 
is a source-less binary distribution with compiled files.

CKeditor package is correctly based on (tagged) stable release, as described 
in https://github.com/ckeditor/ckeditor-dev#available-branches

However at the moment ckeditor_4.4.4+dfsg1-3 is fundamentally broken as 
unmodified source distribution can't be loaded on demand. CKeditor should be 
built using CKbuilder (#813577) that I've just packaged in attempt to fix 
CKeditor in Debian.

-- 
Cheers,
 Dmitry Smirnov
 GPG key : 4096R/53968D1B

---

Writing non-free software is not an ethically legitimate activity, so if
people who do this run into trouble, that's good! All businesses based
on non-free software ought to fail, and the sooner the better.
-- Richard Stallman


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


Bug#812261: (no subject)

2016-02-03 Thread octoploid
Building with -fsanitize=undefined shows:

markus@x4 bin % ./util-test
[==] Running 35 tests from 6 test cases.
[--] Global test environment set-up.
[--] 1 test from AllocatorTest
[ RUN  ] AllocatorTest.AllocatorRef
/var/tmp/cppformat/test/../gmock/gmock/gmock.h:10090:60: runtime error: member 
call on null pointer of type 'const struct ResultHolder'
[1]15511 segmentation fault  ./util-test



Bug#813573: [php-horde] XSS vulnerability in menu bar

2016-02-03 Thread Mathieu Parent
Package: php-horde
Version: 5.2.8+debian0-1

Hello,

According to: http://lists.horde.org/archives/announce/2016/001140.html

Regards
-- 
Mathieu Parent



Bug#812284: (no subject)

2016-02-03 Thread octoploid
The same issue as bug #812261.

This is a bug in googletest. I've opened:
https://github.com/google/googletest/issues/705



Bug#812261: (no subject)

2016-02-03 Thread octoploid
This is a bug in googletest. I've opened:
https://github.com/google/googletest/issues/705



Bug#791195: fixed in lttoolbox 3.3.2~r61000-3.1

2016-02-03 Thread Julien Cristau
On Wed, Feb  3, 2016 at 10:46:02 +0100, Tino Didriksen wrote:

> On 3 February 2016 at 02:57, Andreas Beckmann  wrote:
> 
> > On Thu, 20 Aug 2015 16:00:44 + Julien Cristau 
> > wrote:
> > >  lttoolbox (3.3.2~r61000-3.1) unstable; urgency=medium
> > >  .
> > >* Non-maintainer upload.
> > >* Rename library packages for g++5 ABI transition (closes: 791195).
> >
> > This change was recently reverted and I'm not convinced that this was a
> > good idea.
> 
> 
> 
> That was my doing, on the basis that the transition should never have
> happened.
> 
> Because I wasn't properly subscribed to this bug (due to using my mail@
> address which procmail can't handle), I never knew the transition was
> pushed through against my wishes, until I went to update lttoolbox to a
> newer release.
> 
> There are only 2 other packages that depend on lttoolbox: apertium and
> apertium-lex-tools, and I maintain those as well. All 3 are part of the
> same upstream project, and are updated together if there are breaking
> changes.
> 
> And because lttoolbox 3.3 was not even in testing at the time, nothing
> outside my control could have built up dependencies on it, and indeed
> nothing has.
> 
> The v5 transition was entirely unnecessary for this package, and I very
> strongly want it gone.
> 
You haven't given a single good reason to revert the change.  Maybe you
would have preferred it didn't, but you're coming 6 months late to that
party.

Cheers,
Julien



Bug#805498: systemd: Systemd errors in syslog: Failed to set cpu.cfs_{period,quota}_us

2016-02-03 Thread Ralf Jung
Hi,

>> I see the following errors frequently pop up in the syslog:
>>
>> Nov 18 18:30:21 bridge systemd[1]: Failed to set cpu.cfs_period_us on 
>> /system.slice/systemd-tmpfiles-clean.service: Permission denied
>> Nov 18 18:30:21 bridge systemd[1]: Failed to set cpu.cfs_quota_us on 
>> /system.slice/systemd-tmpfiles-clean.service: Permission denied
>>
>> Not sure whether that's a problem... but I probably shouldn't have errors in 
>> the log in the default config.
>>
> 
> I see that you have docker installed, which might be related [1].
> If you purge the docker (related) packages, does the problem go away?
> Afaics, the docker package tries to use kernel features which aren't
> supported by the Debian kernel in jessie [1].
> 
> 
> [1] https://github.com/docker/docker/issues/17587
> [2] https://lists.debian.org/debian-kernel/2015/10/msg00313.html

The errors started when I installed Docker. I cannot purge Docker, since
it is running services that users rely on ;-) .
The error message however do not look Docker-related at all, do they?

Kind regards,
Ralf



Bug#810521: obex-data-server: FTBFS with libopenobex 1.7.1: src/ods-obex.c:408: undefined reference to `OBEX_FindInterfaces'

2016-02-03 Thread Nobuhiro Iwamatsu
tags 810521 + patch
thanks

Hi,

I created a patch which fix this problem.
Could you check and apply this patch?

Best regards,
  Nobuhiro

-- 
Nobuhiro Iwamatsu
   iwamatsu at {nigauri.org / debian.org}
   GPG ID: 40AD1FA6


obex-data-server-0.4.5.debdiff
Description: Binary data


Bug#808216: Removal of debmirror from testing

2016-02-03 Thread Bob Proulx
Bernhard wrote:
> Do you see any chance to prevent the autoremoval?
> I see you have a patch because of bug #808216.
> For me, this package works fine, because i don't use the diff-files.

I don't think 'grave' "renders package unusable" is correct for this
since it seems to only affect those using diff files.  I also don't
use diff files and had not noticed any breakage.  It would be a
tragedy if it were removed from Testing for being unsuable since the
package isn't actually unusable.  It is quite usable to many.  Most?
Well... At least some of us.  Who knows how many since there is no way
to tell how many use --diff=none or not.

Bob



Bug#813471: network access to the loopback device should be allowed

2016-02-03 Thread Osamu Aoki

On Wed, Feb 03, 2016 at 12:22:14AM +0100, Guillem Jover wrote:
> Hi!
> This is probably too restrictive too. It would not allow local access
> through TAP device or other similar things. It might be better to just
> say something like:
> 
> | For packages in the main archive, no required targets may attempt
> | network access outside the current machine.
> 
> or something along those lines.

I agree with you.

Osamu



Bug#791195: fixed in lttoolbox 3.3.2~r61000-3.1

2016-02-03 Thread Kartik Mistry
On Wed, Feb 3, 2016 at 4:04 PM, Julien Cristau  wrote:
>> The v5 transition was entirely unnecessary for this package, and I very
>> strongly want it gone.
>>
> You haven't given a single good reason to revert the change.  Maybe you
> would have preferred it didn't, but you're coming 6 months late to that
> party.

Apologies!

What is the best way to fix this?

-- 
Kartik Mistry | IRC: kart_
{0x1f1f, kartikm}.wordpress.com



Bug#813582: RM: libzeitgeist -- RoQA; obsoleted, unused, abandoned, superseeded

2016-02-03 Thread Andreas Henriksson
Package: ftp.debian.org
Severity: normal
X-Debbugs-CC: ric...@ubuntu.com

Hello!

Please remove the src:libzeitgeist and all its binary packages from the
archive. It has been superseeded by src:zeitgeist a long time ago already.

There are no reverse dependencies in the archive as far as I can
see, except for the diodon-plugins package which is lingering
since it's no longer being built from src:diodon. Please removed
the diodon-plugins binary package as well.

This removal request brough to you on behalf of ricotz.

Regards,
Andreas Henriksson



Bug#813544: Pending fixes for bugs in the prometheus-node-exporter package

2016-02-03 Thread pkg-go-maintainers
tag 813544 + pending
thanks

Some bugs in the prometheus-node-exporter package are closed in
revision c673ae86b4f4a27ddea037e72e54a21171c674f1 in branch
'debian/sid' by Martín Ferrari

The full diff can be seen at
https://anonscm.debian.org/cgit/pkg-go/packages/prometheus-node-exporter.git/commit/?id=c673ae8

Commit message:

Stop ignoring some configuration values in initscript. Thanks to 
contamina...@baconmail.net for the patch. Closes: #813544.



Bug#812961: jessie-pu: package php-net-ldap2/2.0.12-1+deb8u1

2016-02-03 Thread Prach Pongpanich
Hi,

On Tue, Feb 02, 2016 at 06:37:19PM +0100, Julien Cristau wrote:
> Control: tag -1 = jessie confirmed
> 
> On Thu, Jan 28, 2016 at 11:13:23 +0700, Prach Pongpanich wrote:
> 
> > Package: release.debian.org
> > Severity: normal
> > Tags: jessie
> > User: release.debian@packages.debian.org
> > Usertags: pu
> > 
> > Hi,
> > 
> > 
> >   
> > Please accept the fixes for php5/5.6.17+dfsg-0+deb8u1 upgrade break 
> > php-net-ldap2 in jessie (#812892).
> > 
> > Source debdiff attached.
> > 
> Go ahead.
> 

Uploaded, thanks.

Regards,
Prach


signature.asc
Description: PGP signature


Bug#813553: gtk-redshift: Fails to start under awesome desktop enviroment

2016-02-03 Thread Ritesh Raj Sarraf
Control: tag -1 +moreinfo



On Wed, 2016-02-03 at 05:36 +0300, Alexander Trousevich wrote:
> 
> Dear Maintainer,
> 
> *** Reporter, please consider answering these questions, where
> appropriate ***
> 
>    * What led up to the situation?
> 
> 1. Install awesome window manager. Do not install gnome or anything
> else.
> 
> 2. Run command `gtk-redshift` in terminal emulator.
> 
> 3. Program silently terminates with exit code 255
> 
>    * What exactly did you do (or not do) that was effective (or
>  ineffective)?
> 
> doctor@trousev-debian-desktop:~$ redshift-gtk
> doctor@trousev-debian-desktop:~$ echo $?
> 255

Can you run plain redshift to confirm if that works ?


-- 
Ritesh Raj Sarraf
RESEARCHUT - http://www.researchut.com
"Necessity is the mother of invention."



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


Bug#813570: krita-1.2.8.5+dfsg-1: Krita crashes by creating a new workspace

2016-02-03 Thread Schano
Package: krita-1.2.8.5+dfsg-1
Version: krita-1.2.8.5+dfsg
Severity: normal

Dear Maintainer,

   * What led up to the situation?
First Start of Krita after installation
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
Started program and tried to create a new workspace
   * What was the outcome of this action?
The Program crashed and the KDE-Crash-Handler opened
   * What outcome did you expect instead?
start working with Krita

KDE-crash-handler output:
Application: Krita (krita), signal: Segmentation fault
Using host libthread_db library "/lib/arm-linux-gnueabihf/libthread_db.so.1".
[Current thread is 1 (Thread 0x733a8000 (LWP 2312))]

Thread 6 (Thread 0x6e8cc410 (LWP 2327)):
#0  0x742797a4 in __pthread_cond_wait (cond=0x17573c0, mutex=0x17573a8) at 
pthread_cond_wait.c:187
#1  0x76dc6688 in __pthread_cond_wait (cond=, mutex=) at forward.c:149
#2  0x75ac9318 in QWaitCondition::wait(QMutex*, unsigned long) () from 
/usr/lib/arm-linux-gnueabihf/libQtCore.so.4
#3  0x75ac4f54 in QSemaphore::acquire(int) () from 
/usr/lib/arm-linux-gnueabihf/libQtCore.so.4
#4  0x7556419c in ?? () from /usr/lib/libkritaimage.so.13
#5  0x755645ac in ?? () from /usr/lib/libkritaimage.so.13
Backtrace stopped: previous frame identical to this frame (corrupt stack?)

Thread 5 (Thread 0x6e0cc410 (LWP 2328)):
#0  0x742797a4 in __pthread_cond_wait (cond=0x1757608, mutex=0x17575f0) at 
pthread_cond_wait.c:187
#1  0x76dc6688 in __pthread_cond_wait (cond=, mutex=) at forward.c:149
#2  0x75ac9318 in QWaitCondition::wait(QMutex*, unsigned long) () from 
/usr/lib/arm-linux-gnueabihf/libQtCore.so.4
#3  0x75ac53dc in QSemaphore::tryAcquire(int, int) () from 
/usr/lib/arm-linux-gnueabihf/libQtCore.so.4
#4  0x75581a54 in KisTileDataSwapper::run() () from /usr/lib/libkritaimage.so.13
#5  0x75ac8d74 in ?? () from /usr/lib/arm-linux-gnueabihf/libQtCore.so.4
Backtrace stopped: previous frame identical to this frame (corrupt stack?)

Thread 4 (Thread 0x6ccff410 (LWP 2340)):
#0  0x74279b30 in __pthread_cond_timedwait (cond=0x1bc0398, mutex=0x1bc0380, 
abstime=0x6ccfed6c) at pthread_cond_timedwait.c:199
#1  0x76dc66e4 in __pthread_cond_timedwait (cond=, 
mutex=, abstime=) at forward.c:162
#2  0x75ac92f0 in QWaitCondition::wait(QMutex*, unsigned long) () from 
/usr/lib/arm-linux-gnueabihf/libQtCore.so.4
#3  0x75abc0a0 in ?? () from /usr/lib/arm-linux-gnueabihf/libQtCore.so.4
Backtrace stopped: previous frame identical to this frame (corrupt stack?)

Thread 3 (Thread 0x6c2ff410 (LWP 2341)):
#0  0x742797a4 in __pthread_cond_wait (cond=0x1ee0ef8, mutex=0x1ee0ee0) at 
pthread_cond_wait.c:187
#1  0x76dc6688 in __pthread_cond_wait (cond=, mutex=) at forward.c:149
#2  0x75ac9318 in QWaitCondition::wait(QMutex*, unsigned long) () from 
/usr/lib/arm-linux-gnueabihf/libQtCore.so.4


-- System Information:
Distributor ID: Raspbian on Raspberry Pi Version 2 B
Description:Raspbian GNU/Linux 8.0 (jessie)
Release:8.0
Codename:   jessie
Architecture: armv7l

Kernel: Linux 4.1.13-v7+ (SMP w/4 CPU cores; PREEMPT)
Locale: LANG=de_DE@euro, LC_CTYPE=de_DE@euro (charmap=ISO-8859-15)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)



Bug#813559: ngs-sdk: FTBFS: most platforms explicitly unsupported

2016-02-03 Thread Andreas Tille
Hi,

could someone possibly check on such an affected architecture after
disabling the patches?  If all else fails I would not mind just
uploading with deactivated tests and thus throw it on the auto builders.

I've commited a patch for the other bug #813557.

Kind regards

Andreas.

On Tue, Feb 02, 2016 at 11:22:12PM -0500, Aaron M. Ucko wrote:
> Source: ngs-sdk
> Version: 1.2.3-1
> Severity: important
> Justification: fails to build from source
> 
> ngs-sdk fails to build on most platforms because the build system
> explicitly refuses to support anything upstream hasn't confirmed to
> work -- e.g.,
> 
>   checking system type... Linux
>   checking machine architecture... aarch64
>   configure: error: unsupported architecture 'Linux'
> 
> (It looks like a copy-and-paste error resulted in citing Linux rather
> than aarch64 there.)
> 
> Please either restrict ngs-sdk's Architecture: setting accordingly, or
> comment out these checks in all four(!) of ngs-*/setup/konfigure.perl.
> 
> 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



Bug#813567: nmu: apertium-lex-tools_0.1.1~r60994-1+b1

2016-02-03 Thread Emilio Pozuelo Monfort
On 03/02/16 08:57, Kartik Mistry wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: binnmu
> 
> nmu apertium-lex-tools_0.1.1~r60994-1+b1 . ANY . unstable . -m "Rebuild for 
> lttoolbox"

Will you first explain, as asked earlier on #791195, why you reverted the
renamed package for the libstdc++ transition?

Cheers,
Emilio



Bug#776401: [Pkg-golang-devel] Bug#776401: Bug#776401: src:golang: Set CGO_ENABLED for all platforms

2016-02-03 Thread Tianon Gravi
On 7 March 2015 at 09:21, Hilko Bengen  wrote:
> As far as I can see, it does not. The only notable change is that
> cgo.a files are installed for more than one architecture.
>
>> Also, what's the impact on the future Go 1.5, especially the new,
>> simpler cross-compile[1] that no longer requires rebuilding the entire
>> standard library and toolchain up front like we do currently?
>
> I haven't really looked at what will become Go 1.5. Dave Cheney
> specifically writes that CGO-related things are out of scope of that
> article.

Now that 1.5 is actually out and in the archive (with significantly
simpler package layout -- only three binary packages instead of one
per os-arch combo), I've made some time to give this a whirl, and I
managed to get it working with the package as-is.

Here's the Go file I used to test:

package main

// #include 
import "C"

func main() {
C.fopen(C.CString("test.txt"), C.CString("r"))
}

Saved as "main.go", and compiled via "go build main.go" (on "linux/amd64").

The environment variables I set are as follows:

export GOOS="windows"
export GOARCH="386"
export CGO_ENABLED="1"
export CC="i686-w64-mingw32-gcc"
export CXX="i686-w64-mingw32-g++"

I'm not positive whether all were required for this to work, but given
that it _did_ work, I think this is in the realm of possible with the
changes of Go 1.5 and am inclined to close this bug as "fixed" --
thoughts? :)

♥,
- Tianon
  4096R / B42F 6819 007F 00F8 8E36  4FD4 036A 9C25 BF35 7DD4



Bug#813575: RM: nvidia-cuda-toolkit [i386] -- ROM; NBS; i386 no longer supported in CUDA 7

2016-02-03 Thread Andreas Beckmann
Package: ftp.debian.org
Severity: normal

Please remove the i386 binary packages build by nvidia-cuda-toolkit 6.5.
This platform is no longer supported in CUDA 7.


Andreas



Bug#813580: No Internet Connection with iptables-1.6.0-2

2016-02-03 Thread Tsu Jan

Package: iptables

Version: 1.6.0-2

Yesterday iptables was upgraded from v1.4.21-2+b1 to v1.6.0-2 in Debian 
Testing and today I had no Internet connection (connman.service: Main 
process exited, code=exited, status=1/FAILURE). Fortunately, I had 
another system and could download and then downgrade iptables to 
v1.4.21-2+b1.


System Information:

-- Debian Release: Testing Kernel: 4.3.3-7 libc6: 2.21-7 
(Architecture: amd64)




Bug#813569: profitbricks-client: FTBFS: Couldn't find index page for 'suds' (maybe misspelled?)

2016-02-03 Thread Chris Lamb
Source: profitbricks-client
Version: 1.0.0-2
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,

profitbricks-client fails to build from source in unstable/amd64:

  [..]
  
  Build finished. The manual pages are in _build/man.
  make[2]: Leaving directory 
'/home/lamby/temp/cdt.20160203085036.rmpR9BoqGE/profitbricks-client-1.0.0/docs'
  make[1]: Leaving directory 
'/home/lamby/temp/cdt.20160203085036.rmpR9BoqGE/profitbricks-client-1.0.0'
 dh_auto_test -O--buildsystem=pybuild
  I: pybuild base:184: python2.7 setup.py test 
  running test
  Searching for suds
  
  Note: Bypassing https://pypi.python.org/simple/suds/ (disallowed host; see 
http://bit.ly/1dg9ijs for details).
  
  Couldn't find index page for 'suds' (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 suds
  error: Could not find suitable distribution for Requirement.parse('suds')
  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:4: 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
   `-


profitbricks-client.1.0.0-2.unstable.amd64.log.txt.gz
Description: Binary data


Bug#813568: php-guzzle: FTBFS: DefaultCacheStorageTest::testCachesRequests strpos() expects parameter 1 to be string, array given

2016-02-03 Thread Chris Lamb
Source: php-guzzle
Version: 3.9.3+dfsg-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,

php-guzzle fails to build from source in unstable/amd64:

  [..]

  Autoload file vendor/autoload.php generated.
  
  make[1]: Leaving directory 
'/home/lamby/temp/cdt.20160203084908.RlfJUCZUHm/php-guzzle-3.9.3+dfsg'
 debian/rules override_dh_auto_test
  make[1]: Entering directory 
'/home/lamby/temp/cdt.20160203084908.RlfJUCZUHm/php-guzzle-3.9.3+dfsg'
  http_proxy= phpunit
  PHPUnit 5.1.3 by Sebastian Bergmann and contributors.
  
  .   61 / 1531 (  
3%)
  .  122 / 1531 (  
7%)
  .  183 / 1531 ( 
11%)
  .  244 / 1531 ( 
15%)
  .  305 / 1531 ( 
19%)
  .  366 / 1531 ( 
23%)
  .  427 / 1531 ( 
27%)
  .  488 / 1531 ( 
31%)
  .  549 / 1531 ( 
35%)
  .  610 / 1531 ( 
39%)
  .  671 / 1531 ( 
43%)
  .  732 / 1531 ( 
47%)
  ....S  793 / 1531 ( 
51%)
  S  854 / 1531 ( 
55%)
  .  915 / 1531 ( 
59%)
  .  976 / 1531 ( 
63%)
  E..E...FEE... 1037 / 1531 ( 
67%)
  . 1098 / 1531 ( 
71%)
  . 1159 / 1531 ( 
75%)
  . 1220 / 1531 ( 
79%)
  . 1281 / 1531 ( 
83%)
  ...S. 1342 / 1531 ( 
87%)
  . 1403 / 1531 ( 
91%)
  F...F 1464 / 1531 ( 
95%)
  . 1525 / 1531 ( 
99%)
  ..1531 / 1531 
(100%)
  
  Time: 9.1 seconds, Memory: 46.50Mb
  
  There were 4 errors:
  
  1) Guzzle\Tests\Plugin\Cache\DefaultCacheStorageTest::testCachesRequests
  strpos() expects parameter 1 to be string, array given
  
  
/home/lamby/temp/cdt.20160203084908.RlfJUCZUHm/php-guzzle-3.9.3+dfsg/tests/Guzzle/Tests/Plugin/Cache/DefaultCacheStorageTest.php:53
  
  2) 
Guzzle\Tests\Plugin\Cache\DefaultCacheStorageTest::testCachesMultipleRequestsWithVary
  strpos() expects parameter 1 to be string, array given
  
  
/home/lamby/temp/cdt.20160203084908.RlfJUCZUHm/php-guzzle-3.9.3+dfsg/tests/Guzzle/Tests/Plugin/Cache/DefaultCacheStorageTest.php:96
  
  3) 
Guzzle\Tests\Plugin\Cache\DefaultCacheStorageTest::testUsesStaleTimeDirectiveForTtd
 with data set #0 (Guzzle\Http\Message\Request Object (...), 
Guzzle\Http\Message\Response Object (...))
  strpos() expects parameter 1 to be string, array given
  
  
/home/lamby/temp/cdt.20160203084908.RlfJUCZUHm/php-guzzle-3.9.3+dfsg/tests/Guzzle/Tests/Plugin/Cache/DefaultCacheStorageTest.php:177
  
  4) 
Guzzle\Tests\Plugin\Cache\DefaultCacheStorageTest::testUsesStaleTimeDirectiveForTtd
 with data set #1 (Guzzle\Http\Message\Request Object (...), 
Guzzle\Http\Message\Response Object (...))
  strpos() expects parameter 1 to be string, array given
  
  
/home/lamby/temp/cdt.20160203084908.RlfJUCZUHm/php-guzzle-3.9.3+dfsg/tests/Guzzle/Tests/Plugin/Cache/DefaultCacheStorageTest.php:177
  
  --
  
  There were 3 failures:
  
  1) 
Guzzle\Tests\Plugin\Cache\DefaultCacheStorageTest::testEnsuresResponseIsStillPresent
  Failed asserting that Guzzle\Http\Message\Response Object 
&7235161d1a489634 (
  'body' => Guzzle\Http\EntityBody Object &723516141a489634 
(
  'contentEncoding' => false
  'rewindFunction' => null
  'stream' => resource(3521) of type (stream)
  'size' => null
  'cache' => Array &0 (
  'wrapper_type' => 'PHP'
  'stream_type' => 'TEMP'
  'mode' => 'w+b'
  'unread_bytes' => 0
  'seekable' => true
  'uri' => 'php://temp'

Bug#807294: golang-go: contains some but not all race-enabled packages

2016-02-03 Thread Michael Hudson-Doyle
On 3 February 2016 at 19:02, Tianon Gravi  wrote:
>> + # On linux/amd64 run.bash installs some race enabled standard library
>> + # packages. Delete them again to avoid accidentally including them in
>> + # the package.
>> + rm -rf "$(GOROOT)/pkg/linux_amd64_race/"
>
> This seems like the most correct solution to me, but I'm a little
> confused about why we're hard-coding "linux_amd64" here -- shouldn't
> this be "$(GOOS)_$(GOARCH)" so that it's whatever architecture we
> build on?  Or perhaps "$(GOROOT)"/pkg/*_race/ ?

It's because the race detector is only supported on amd64 (and I
alternate between forgetting about and not caring about
Debian/kFreeBSD, I guess). GOOS and GOARCH are not defined in
debian/rules any more, but I guess we could shell out to go tool dist
env like the invocation of run.bash does. I tried to use the wildcard
at first but it's annoying because make is not shell. Attaching a new,
slightly cleaner, patch.

Cheers,
mwh
diff --git a/debian/rules b/debian/rules
index ae235c7..e7d994c 100755
--- a/debian/rules
+++ b/debian/rules
@@ -34,6 +34,13 @@ ifeq (true, $(RUN_TESTS))
 		export PATH="$(GOROOT)/bin:$$PATH"; \
 		eval "$$(go tool dist env)"; \
 		bash run.bash --no-rebuild;
+	# On linux/amd64 run.bash installs some race enabled standard library
+	# packages. Delete them again to avoid accidentally including them in
+	# the package.
+	set -ex; \
+		export PATH="$(GOROOT)/bin:$$PATH"; \
+		eval "$$(go tool dist env)"; \
+		rm -rf "$(GOROOT)/pkg/$${GOOS}_$${GOARCH}_race/"
 else
 	# skip the tests on platforms where they fail
 endif


Bug#813537: [Pkg-privacy-maintainers] Bug#813537: tails-installer: tails installer fails with extlinux error

2016-02-03 Thread intrigeri
Control: retitle -1 tails-installer warns about missing extlinux while it is 
not needed
Control: tag -1 + upstream
Control: tag -1 - moreinfo
Control: severity -1 - minor
Control: found -1 4.4.7+dfsg-1

Hi,

Quoting bits that S. sent to me privately, and latter clarified that
the intent had been to email the BTS instead:

S. Banerian wrote (02 Feb 2016 21:58:08 GMT) :
> On 02/02/2016 01:54 PM, intrigeri wrote:
>> Did you see this message on stdout, or in the GUI?

> stdout, behind the gui (which i ran via commandline in a terminal)

>> If the latter, how exactly did you start Tails Installer?

> see above.

Thanks!

I can confirm this. For the record, the message I see is this warning:

[creator.py:1321 (get_extlinux_version)] WARNING: extlinux not found! Only FAT 
filesystems will be supported

Cheers,
-- 
intrigeri



Bug#813577: ITP: ckeditor -- command line builder for CKEditor

2016-02-03 Thread Dmitry Smirnov
Package: wnpp
Severity: wishlist
X-Debbugs-CC: debian-de...@lists.debian.org
Owner: Dmitry Smirnov 
Control: block 802738 by -1

   Package name: ckbuilder
Version: 2.3.0+dfsg
Upstream Author: CKSource - Frederico Knabben
License: Expat, BSD-2-Clause
URL: https://github.com/ckeditor/ckbuilder 
Vcs-Browser: https://anonscm.debian.org/cgit/collab-maint/ckbuilder.git
Description: command line builder for CKEditor
 CKBuilder builds CKEditor from its source code.


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


Bug#813581: debtags submit needs either removing or using client certificates

2016-02-03 Thread Enrico Zini
Package: debtags
Version: 2.0.1
Severity: normal

Hello,

I have disabled anonymous tag submissions on debtags.debian.org, and it
now requires the existance of a sso client certificate to accept tags.

debtags submit currently does not load client certificates, so it is
unable to submit tags to the site.

Very few people really use debtags submit, so a simple course of action
can just be to remove the feature.

Alternatively, a use could export certificates from their browser, or
manually generate a certificate on sso.debian.org[1], and pass it as a
new option to debtags; python-requests should support loading client
certificates: in [2] it says:

  You can also specify a local cert to use as client side certificate,
  as a single file (containing the private key and the certificate) or
  as a tuple of both file’s path:
  >>> requests.get('https://kennethreitz.com', cert=('/path/client.cert', 
'/path/client.key'))
  

If you go the python-requests way, be aware of this bug:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=801506


Thank you,

Enrico


[1] https://wiki.debian.org/DebianSingleSignOn#Getting_a_certificate
[2] 
http://docs.python-requests.org/en/latest/user/advanced/#ssl-cert-verification


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

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

Versions of packages debtags depends on:
ii  python3 3.5.1-1
ii  python3-apt 1.1.0~beta1
ii  python3-debian  0.1.27
pn  python3:any 

debtags recommends no packages.

Versions of packages debtags suggests:
pn  tagcoll  

-- no debconf information



Bug#801590: crash: fails to load 4.1 kernel dumps

2016-02-03 Thread Sandro Tosi
On Fri, Jan 15, 2016 at 3:12 PM, Troy Heber  wrote:
>  01/15/16 14:59, Juerg Haefliger wrote:
>
>> > I think to be able to load 4.1 dumps you need to use 7.1.1, that's
>> > exactly what we are about to do: backport that version to
>> > jessie-backports - Troy, do you want to handle the upload to Debian
>> > yourself or are you ok with me pushing it there?
>>
>> Is there an update for this?
>
> Hi Juerg,
>
> Sorry, it looks like I dropped the ball on this one. I had thought
> that Sandro was going to upload the backport so I forgot about it.
> Sandro, did you already have the backport done or do I need to take
> care of this?

gaah sorry I somehow missed your replies: yeah I'm in the process of
preparing the backport for 7.1.4, and at that point I'll upload that -
thanks!


-- 
Sandro "morph" Tosi
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi
G+: https://plus.google.com/u/0/+SandroTosi



Bug#808839: fop: Exception java.lang.IllegalArgumentException: URI is not hierarchical

2016-02-03 Thread Mathieu Malaterre
On Wed, Feb 3, 2016 at 10:00 AM, Sylvain Joubert  wrote:
[...]
> Thanks for taking a look at this.
> Unfortunately I already have this package installed so that does not change
> anything.

Great. In that case please upload a minimal example so that we can
reproduce it here, for now we only have your error message from your
very specific setup.

Include all necessary step (fop / docbook / xslt steps).

Thanks.



Bug#805517: [pkg-golang-devel] Bug#805517: golang: Panic when running go_test:runtime and go_test:cmd/go tests

2016-02-03 Thread Tianon Gravi
On 18 November 2015 at 18:39, Nathan Osman
 wrote:
> Therefore, I am attaching a small patch that sets this variable to 6,
> extending the timeout to 18 minutes (which seems to be enough for completing
> the tests). This variable is only set when compiling on ARM CPUs.

Thanks for the report and for taking the time to make a patch!  I'm a
little hesitant to apply it as-is without upstream applying it first
(since this is technically a bug in upstream's code, not in the
packaging); do you think that the fix for #807290
(DEB_BUILD_OPTIONS=nocheck) might be enough for your use case, or is
it important to how you're building/using the package that it runs the
tests?

♥,
- Tianon
  4096R / B42F 6819 007F 00F8 8E36  4FD4 036A 9C25 BF35 7DD4



Bug#813461: cqrlog: FTBFS: lcommon.pp(515,18) Error: (5038) identifier idents no member "family"

2016-02-03 Thread Petr Hlozek
This bug is caused by new fpc version 3.0. I'll fix it in next CQRLOG release.

-- 
http://HamQTH.com/ok2cqr
http://ok2cqr.com
http://cqrlog.com



Bug#813572: fop 2.1 is out !

2016-02-03 Thread Mathieu Malaterre
Source: fop
Severity: important

Please package it.



Bug#757327: systemtap-common: Installing systemtap-common emits an error (but does not fail)

2016-02-03 Thread Tim Ruehsen
Package: systemtap-common
Version: 2.9-3
Followup-For: Bug #757327

Dear Maintainer,

this annoying error message still exists.


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

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

systemtap-common depends on no packages.

Versions of packages systemtap-common recommends:
ii  systemtap  2.9-3

systemtap-common suggests no packages.

-- no debconf information



Bug#813570: krita-1.2.8.5+dfsg-1: Krita crashes by creating a new workspace

2016-02-03 Thread Mattia Rizzolo
control: reassign -1 krita 1:2.8.5+dfsg-1

On Wed, Feb 03, 2016 at 09:14:35AM +0100, Schano wrote:
> Package: krita-1.2.8.5+dfsg-1
> Version: krita-1.2.8.5+dfsg

please consider reading https://www.debian.org/Bugs/Reporting and how
you should have used the two fields above.

> Severity: normal
> 
> Dear Maintainer,
> 
>* What led up to the situation?
> First Start of Krita after installation
>* What exactly did you do (or not do) that was effective (or
>  ineffective)?
> Started program and tried to create a new workspace
>* What was the outcome of this action?
> The Program crashed and the KDE-Crash-Handler opened
>* What outcome did you expect instead?
> start working with Krita
> 
> KDE-crash-handler output:
> Application: Krita (krita), signal: Segmentation fault
> Using host libthread_db library "/lib/arm-linux-gnueabihf/libthread_db.so.1".
> [Current thread is 1 (Thread 0x733a8000 (LWP 2312))]
> 
> Thread 6 (Thread 0x6e8cc410 (LWP 2327)):
> #0  0x742797a4 in __pthread_cond_wait (cond=0x17573c0, mutex=0x17573a8) at 
> pthread_cond_wait.c:187
> #1  0x76dc6688 in __pthread_cond_wait (cond=, mutex= out>) at forward.c:149
> #2  0x75ac9318 in QWaitCondition::wait(QMutex*, unsigned long) () from 
> /usr/lib/arm-linux-gnueabihf/libQtCore.so.4
> #3  0x75ac4f54 in QSemaphore::acquire(int) () from 
> /usr/lib/arm-linux-gnueabihf/libQtCore.so.4
> #4  0x7556419c in ?? () from /usr/lib/libkritaimage.so.13
> #5  0x755645ac in ?? () from /usr/lib/libkritaimage.so.13
> Backtrace stopped: previous frame identical to this frame (corrupt stack?)
> 
> Thread 5 (Thread 0x6e0cc410 (LWP 2328)):
> #0  0x742797a4 in __pthread_cond_wait (cond=0x1757608, mutex=0x17575f0) at 
> pthread_cond_wait.c:187
> #1  0x76dc6688 in __pthread_cond_wait (cond=, mutex= out>) at forward.c:149
> #2  0x75ac9318 in QWaitCondition::wait(QMutex*, unsigned long) () from 
> /usr/lib/arm-linux-gnueabihf/libQtCore.so.4
> #3  0x75ac53dc in QSemaphore::tryAcquire(int, int) () from 
> /usr/lib/arm-linux-gnueabihf/libQtCore.so.4
> #4  0x75581a54 in KisTileDataSwapper::run() () from 
> /usr/lib/libkritaimage.so.13
> #5  0x75ac8d74 in ?? () from /usr/lib/arm-linux-gnueabihf/libQtCore.so.4
> Backtrace stopped: previous frame identical to this frame (corrupt stack?)
> 
> Thread 4 (Thread 0x6ccff410 (LWP 2340)):
> #0  0x74279b30 in __pthread_cond_timedwait (cond=0x1bc0398, mutex=0x1bc0380, 
> abstime=0x6ccfed6c) at pthread_cond_timedwait.c:199
> #1  0x76dc66e4 in __pthread_cond_timedwait (cond=, 
> mutex=, abstime=) at forward.c:162
> #2  0x75ac92f0 in QWaitCondition::wait(QMutex*, unsigned long) () from 
> /usr/lib/arm-linux-gnueabihf/libQtCore.so.4
> #3  0x75abc0a0 in ?? () from /usr/lib/arm-linux-gnueabihf/libQtCore.so.4
> Backtrace stopped: previous frame identical to this frame (corrupt stack?)
> 
> Thread 3 (Thread 0x6c2ff410 (LWP 2341)):
> #0  0x742797a4 in __pthread_cond_wait (cond=0x1ee0ef8, mutex=0x1ee0ee0) at 
> pthread_cond_wait.c:187
> #1  0x76dc6688 in __pthread_cond_wait (cond=, mutex= out>) at forward.c:149
> #2  0x75ac9318 in QWaitCondition::wait(QMutex*, unsigned long) () from 
> /usr/lib/arm-linux-gnueabihf/libQtCore.so.4
> 
> 
> -- System Information:
> Distributor ID:   Raspbian on Raspberry Pi Version 2 B
> Description:  Raspbian GNU/Linux 8.0 (jessie)
> Release:  8.0
> Codename: jessie
> Architecture: armv7l
> 
> Kernel: Linux 4.1.13-v7+ (SMP w/4 CPU cores; PREEMPT)
> Locale: LANG=de_DE@euro, LC_CTYPE=de_DE@euro (charmap=ISO-8859-15)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)

-- 
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#811300: FTBFS: error: 'OBEX_TRANS_CUST' undeclared

2016-02-03 Thread Nobuhiro Iwamatsu
tags 811300 + patch
thanks

Hi,

I created a patch which fix this problem.
Could you check and apply this patch?

Best regards,
  Nobuhiro
-- 
Nobuhiro Iwamatsu
   iwamatsu at {nigauri.org / debian.org}
   GPG ID: 40AD1FA6


libsyncml-0.5.4.debdiff
Description: Binary data


Bug#812804: blueman: File transfer does not work through tray icon menu

2016-02-03 Thread Christopher Schramm
Hi Ralf,

thanks for your report.

The first - not working - way you describe should invoke
`blueman-sendto` without any options.

The second should invoke `blueman-sendto --source=
--device=`.

Could you try those two variants manually and see if the result is the
same as through the applet and manager window? You can get the addresses
from `bluetoothctl` (adapter is called Controller there).

The crucial difference is probably the --device option, but I cannot
spot the possible problem. When you confirmed that option makes the
difference, please provide the output of blueman-sendto from start to
the point where the error occurs.

Regards



Bug#812487: Updated patch

2016-02-03 Thread Wouter Verhelst
Control: retitle -1 Please ensure that https://lkml.org/lkml/2016/2/2/416 
reaches Debian
thanks

After feedback from the udev maintainers, an updated patch was posted (which
turns it into a two-line patch, from a one-line one...)

-- 
It is easy to love a country that is famous for chocolate and beer

  -- Barack Obama, speaking in Brussels, Belgium, 2014-03-26



Bug#742999: Git Repo

2016-02-03 Thread Petter Reinholdtsen
I've clean up the git repo a bit and uploaded the package to NEW
processing.  The code is also available from
http://anonscm.debian.org/cgit/collab-maint/caldav-tester.git >.

-- 
Happy hacking
Petter Reinholdtsen



Bug#813578: obexpushd: Please update package name of libopenobex in B-D

2016-02-03 Thread Nobuhiro Iwamatsu
Package: obexpushd
Version: 0.11.2-1
Severity: important
Tags: patch

Dear Maintainer,

soname of libopenobex has been updated. 
libopenobex of obexpushd has been set libopenobex1, this will FTBFS on unsbtale 
of environment.
Please update package name from libopenobex1-dev to libopenobex2-dev.

Best regards,
  Nobuhiro

-- System Information:
Debian Release: stretch/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: armhf, armel, sh4, powerpc

Kernel: Linux 4.2.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=ja_JP.utf8, LC_CTYPE=ja_JP.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
diff -Nru obexpushd-0.11.2/debian/changelog obexpushd-0.11.2/debian/changelog
--- obexpushd-0.11.2/debian/changelog	2011-08-08 09:56:43.0 +0900
+++ obexpushd-0.11.2/debian/changelog	2016-02-03 18:15:53.0 +0900
@@ -1,3 +1,10 @@
+obexpushd (0.11.2-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Change B-D from libopenobex1-dev to libopenobex2-dev.
+
+ -- Nobuhiro Iwamatsu   Wed, 03 Feb 2016 18:15:15 +0900
+
 obexpushd (0.11.2-1) unstable; urgency=low
 
   * New upstream release.
diff -Nru obexpushd-0.11.2/debian/control obexpushd-0.11.2/debian/control
--- obexpushd-0.11.2/debian/control	2011-08-08 09:56:43.0 +0900
+++ obexpushd-0.11.2/debian/control	2016-02-03 18:16:06.0 +0900
@@ -2,7 +2,7 @@
 Section: comm
 Priority: optional
 Maintainer: Gabriele Giacone <1o5g4...@gmail.com>
-Build-Depends: debhelper (>= 7), libopenobex1-dev, libbluetooth-dev,
+Build-Depends: debhelper (>= 7), libopenobex2-dev, libbluetooth-dev,
  pkg-config, xmlto, cmake, cdbs
 Standards-Version: 3.9.2
 Homepage: http://www.gitorious.org/obexpushd/


Bug#812309: python-trollius: upgrade to version 2.0

2016-02-03 Thread Sandro Tosi
> trollius 2.0 has been released: https://pypi.python.org/pypi/trollius , please
> package it.

In the next few days, I will prepare the new upstream release and
upload it to unstable; if you prefer to handle it yourself, please do
that asap.

Thanks,
-- 
Sandro "morph" Tosi
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi
G+: https://plus.google.com/u/0/+SandroTosi



Bug#813382: systemd: journalctl shows no output with --since / --until unless --reverse is also specified

2016-02-03 Thread A Peters
Sorry, copy and paste mistake. Subject line said it all.

To summarize with correct command lines:

# journalctl --since '2016-01-29 08:08:00' --until '2016-01-29 08:09:00'
Produces no log output

# journalctl --since '2016-01-29 08:08:00' --until '2016-01-29 08:09:00'
--reverse
Produces log output

Kind regards,
-- 
Arno Peters


Bug#808839: fop: Exception java.lang.IllegalArgumentException: URI is not hierarchical

2016-02-03 Thread Sylvain Joubert
Package: fop
Version: 1:2.0+dfsg-5
Followup-For: Bug #808839

Dear Maintainer,

Thanks for taking a look at this.
Unfortunately I already have this package installed so that does not change
anything.

$ aptitude versions gsfonts-x11
Paquet gsfonts-x11 :
p   0.22  stable  800
i   0.24  testing,unstable990



-- System Information:
Debian Release: stretch/sid
  APT prefers testing
  APT policy: (990, 'testing'), (800, 'stable-updates'), (800, 'stable'), (700, 
'unstable'), (90, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 4.3.0-1-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 fop depends on:
ii  default-jre-headless [java2-runtime-headless]2:1.7-52.1
ii  libfop-java  1:2.0+dfsg-5
ii  openjdk-7-jre-headless [java2-runtime-headless]  7u91-2.6.3-1

Versions of packages fop recommends:
ii  libsaxon-java  1:6.5.5-10

Versions of packages fop suggests:
pn  fop-doc  

-- no debconf information



Bug#513368: ldirectord: emailalert produces invalid To: header

2016-02-03 Thread Christoph Berg
Control: tags -1 moreinfo

Re: Thijs Kinkhorst 2009-01-28 
<20090128121956.4599.63699.report...@volta.loeki.tv>
> Package: ldirectord
> Version: 2.1.4-3
> Severity: minor
> 
> Hi,
> 
> The emailalert option in ldirectord.cf is defined in the manual page
> to be used with quotes:
> 
> emailalert="th...@example.com"
> 
> However, these quotes are then used in the To: header of the generated
> email:
> To: "th...@example.com" <@test1.example.com>
> 
> The email arrives correctly because the envelope TO seems to be interpreted
> correctly. It seems what's needed is that the quotes used to specify the
> parameter value have to be stripped off before it's put into the To
> header.

Hi Thijs,

are you still using ldirectord? I've just uploaded a new
resource-agents version and was wondering if the above bug still
existed 7 years later. Can you reproduce it?

Christoph
-- 
c...@df7cb.de | http://www.df7cb.de/


signature.asc
Description: PGP signature


Bug#813567: nmu: apertium-lex-tools_0.1.1~r60994-1+b1

2016-02-03 Thread Kartik Mistry
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: binnmu

nmu apertium-lex-tools_0.1.1~r60994-1+b1 . ANY . unstable . -m "Rebuild for 
lttoolbox"

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

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

-- 
Kartik Mistry | IRC: kart_
{0x1f1f, kartikm}.wordpress.com


signature.asc
Description: PGP signature


Bug#810562: ircp-tray: FTBFS with libopenobex 1.7.1: src/ircp_server.c:273: undefined reference to `OBEX_UnicodeToChar'

2016-02-03 Thread Nobuhiro Iwamatsu
tags 810562 + patch
thanks

Hi,

I created a patch which fix this problem.
Could you check and apply this patch?

Best regards,
  Nobuhiro

-- 
Nobuhiro Iwamatsu
   iwamatsu at {nigauri.org / debian.org}
   GPG ID: 40AD1FA6


ircp-tray-0.7.6.debdiff
Description: Binary data


Bug#813538: please speed up checking multiple build profiles

2016-02-03 Thread Johannes Schauer
Hi,

Quoting Helmut Grohne (2016-02-02 22:55:02)
> By now, rebootstrap[1] is a heavy user of dose-builddebcheck and invoking it
> well over 50 times per run. This starts to manifest in the time it takes to
> run rebootstrap. Thus far I am always passing the same set of build profiles
> to dose, but in future I would like to ask it for building some packages with
> different profiles than others. Of course, I can simply run
> dose-builddebcheck for each profile combination, but each of those
> invocations incurs the parsing of Packages and Sources and thus increases the
> time to run rebootstrap.
> 
> For example, I would like to be able to ask dose-builddebcheck whether
> util-linux can be built under stage1 or tar can be built with no
> profiles.
> 
> Johannes suggested splitting the parsing phase into a separate step,
> such that multiple queries could be made against the same Packages file
> without incurring the cost of parsing multiple times.

more precisely, I see two problems with implementing the original proposal in
practice:

 a) how to implement the user interface so that the user is able to pass
 package specific profiles

 b) the information somehow has to be handed down all the way to the Sources
 parser, touching lots of code in the process

as a way to solve a), Helmut suggested the following command line format:

--profiles stage1 --check-only util-linux --profiles "" --check-only tar

Unfortunately it seems that this won't fly with dose3's current command line
parser (OptParse) which is unable to figure out the order of arguments.

My original idea to solve this (also mentioned by Helmut above) was to fix his
initial problem by finally implementing a way to re-use the data structures
created by an initial dose3 run by subsequent dose3 runs (given the underlying
Packages and Sources files didn't change). Unfortunately I now realize that
this idea won't fly either because the mentioned datastructures would also
store the build profiles with which source package were initially instructed to
be built but Helmut wants to change these in subsequent runs.

If nobody has a better idea, maybe this is a wontfix bug?

Thanks!

cheers, josch


signature.asc
Description: signature


Bug#813571: virtualenv: Broken dependencies

2016-02-03 Thread Francisco José Rodríguez Bogado
Package: virtualenv
Version: 1.11.6+ds-1
Severity: grave
Justification: renders package unusable

Dear Maintainer,

I'm trying to install virtualenv on Sid. It depends on python3-virtualenv, that
depends on python-setuptools-whl *and* python-pip-whl. But python-pip-whl
(8.0.2-2) breaks python-setuptools-whl >=18.8-1, which is the version in Sid
repo. If I install python-setuptools-whl, apt-get removes python-pip-whl. So I
can't install python3-virtualenv neither python-virtualenv.

Thanks in advance.



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

Kernel: Linux 4.3.0-1-amd64 (SMP w/8 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)



Bug#813576: RM: pycuda [i386] -- RoQA; NBS; i386 no longer supported in CUDA 7

2016-02-03 Thread Andreas Beckmann
Package: ftp.debian.org
Severity: normal

Please remove the i386 binary packages built by pycuda.
This platform is no longer supported in CUDA 7.

Andreas



Bug#813561: closed by Scott Kitterman <deb...@kitterman.com> (Next time fix the rdepends)

2016-02-03 Thread Vasudev Kamath
ow...@bugs.debian.org (Debian Bug Tracking System) writes:

> This is an automatic notification regarding your Bug report
> which was filed against the ftp.debian.org package:
>
> #813561: RM: fonts-droid -- RoM obsolete
>
> It has been closed by Scott Kitterman .
>
> Their explanation is attached below along with your original report.
> If this explanation is unsatisfactory and you have not received a
> better one in a separate message then please contact Scott Kitterman 
>  by
> replying to this email.

Sorry for the noise I didn't knew there was one already filed
report. And yes since blender is not uploaded yet but the maintainer
confirmed dropping of dependency I went on to file the report!.

Cheers,



Bug#812994: apt 1.2.1 fails to configure packages

2016-02-03 Thread Julian Andres Klode
On Thu, Jan 28, 2016 at 12:33:50PM +, Rohan Garg wrote:
> Package: apt
> Version: 1.2.1
> Severity: important
> 
> Dear Maintainer,
> 
> It seems like upgrading to apt 1.2.1 leads to problems with configuring 
> packages.
> The problem seems to be with apt itself since multiple unrelated packages are 
> affected.

Do you have a dpkg.log from the incident and can you reproduce it? We're trying 
to figure
out if it's a bug in APT or in dpkg.

Also, does libpipeline1_1.4.1-2_amd64.deb really contain libpipeline1 and if you
can reproduce it, does downgrading dpkg and/or libapt-pkg5.0 help?

-- 
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#743227: Reproduced today on Debian 7.9

2016-02-03 Thread Stéphane Gourichon

Reproduced today on Debian 7.9 Amd64, git 1:1.9.1-1~bpo70+2,
which means that the repository was not fixed in between.

LC_ALL=C git -c transfer.fsckobjects=true clone 
https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware


Cloning into 'linux-firmware'...
remote: Counting objects: 3966, done.
remote: Total 3966 (delta 0), reused 0 (delta 0)
error: object 087fbb748f50af6eac2248a445d25d666cc92c78:contains 
zero-padded file modes

fatal: Error in object
fatal: index-pack failed

Command exited with non-zero status 128

See also
[git - propagating repo corruption across 
clone](http://git.661346.n2.nabble.com/propagating-repo-corruption-across-clone-td7580504.html)
[#813157 - git: please default fsckobjects to true in transfer, fetch, 
and receive - Debian Bug report 
logs](https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=813157)


(link reference [git 
integrity - Google Groupes](https://groups.google.com/forum/#!topic/binary-transparency/f-BI4o8HZW0) 
)


--
Stéphane Gourichon



Bug#812173: in apt marked as pending

2016-02-03 Thread David Kalnischkies
Hi,

On Tue, Feb 02, 2016 at 10:35:09PM +0100, Balint Reczey wrote:
> Unfortunately this commit seems to break apt in the following test:
> (gdb) set args build-dep bzip2
> (gdb) run
> Starting program: /usr/bin/apt build-dep bzip2
> Reading package lists... Done
> 
> Program received signal SIGSEGV, Segmentation fault.

Thanks for testing & reporting!

git commit cd907113561d5eb75054f981be3bcc22eee8db27 should fix this (and
related) segfaults by avoiding an unneeded roundtrip over a pointer
which is no longer initialized at this point – as that is a very costly
operation we want to delay until after we have figured out all
build-dependencies as we would have to calculate it again then.
Before the rewrite it wasn't important then this calculation happened,
so the code did it very early on, so later parts "optimized" for code
length it seems…


Best regards

David Kalnischkies


signature.asc
Description: PGP signature


Bug#809806: ... and also writes logfile without honoring $destdir

2016-02-03 Thread Daniel Leidert
Package: devscripts
Version: 2.15.10
Followup-For: Bug #809806

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi,

I would like to request, that writing the logfile honors --destdir too,
independent from the on/off switch decision made here. ATM the logfile is
written to "../", which in my case is the development (VCS) directory. The
log files belong to the tarball(s).

Regards, Daniel



- -- Package-specific info:

- --- /etc/devscripts.conf ---

- --- ~/.devscripts ---
DEBSIGN_KEYID=C296D05D
DEBUILD_LINTIAN=yes
DEBUILD_LINTIAN_OPTS="-i -I -E --pedantic"
DEBCHANGE_RELEASE_HEURISTIC=changelog

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

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

Versions of packages devscripts depends on:
ii  dpkg-dev 1.18.4
ii  libc62.21-7
ii  perl 5.22.1-5
pn  python3:any  

Versions of packages devscripts recommends:
ii  apt 1.2.1
ii  at  3.1.18-2
ii  curl7.47.0-1
ii  dctrl-tools 2.24-2
ii  debian-keyring  2016.01.20
ii  dput0.9.6.4
ii  equivs  2.0.9+nmu1
ii  fakeroot1.20.2-1
ii  file1:5.25-2
ii  gnupg   1.4.20-1
ii  gnupg2  2.1.11-2
ii  libdistro-info-perl 0.14
ii  libencode-locale-perl   1.05-1
ii  libjson-perl2.90-1
ii  liblwp-protocol-https-perl  6.06-2
ii  libsoap-lite-perl   1.19-1
ii  liburi-perl 1.71-1
ii  libwww-perl 6.15-1
ii  lintian 2.5.40.2
ii  man-db  2.7.5-1
ii  patch   2.7.5-1
ii  patchutils  0.3.4-1
ii  python3-debian  0.1.27
pn  python3-magic   
ii  sensible-utils  0.0.9
ii  strace  4.11-1
ii  unzip   6.0-20
pn  wdiff   
ii  wget1.17.1-1+b1
ii  xz-utils5.1.1alpha+20120614-2.1

Versions of packages devscripts suggests:
ii  bsd-mailx [mailx]8.1.2-0.20160123cvs-2
ii  build-essential  12.2
pn  cvs-buildpackage 
pn  debbindiff   
pn  devscripts-el
ii  gnuplot  4.6.6-3
ii  gpgv 1.4.20-1
ii  libauthen-sasl-perl  2.1600-1
pn  libfile-desktopentry-perl
ii  libnet-smtp-ssl-perl 1.03-1
pn  libterm-size-perl
ii  libtimedate-perl 2.3000-2
ii  libyaml-syck-perl1.29-1+b1
pn  mozilla-devscripts   
ii  mutt 1.5.24-1+b1
ii  openssh-client [ssh-client]  1:7.1p2-2
ii  svn-buildpackage 0.8.5+nmu1
ii  w3m  0.5.3-26

- -- no debconf information

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBCgAGBQJWsgQoAAoJEEvNBWfCltBdRrsQALW8aAEBWkf9BrQKyVpqzL/k
UkO6NsVDT6wSunYxl1EBfU20sBQO0KtjtNXWiSNJDBnU1KdGd1yZijeSs14vaMsQ
FbIQUQ81eLhJkpTI/Ol+CzlG6vBa6yH8CW0u58+efM4PClq39f4l/XhKjpz4if1C
1XaRPm0MNZjXfzDlTz41/R1JZ41hKoJUjJVncy+lrF22R5z7FBAEIxfVhNgdDHHm
8OkkJ43O5/fKwJ1jw8Fpocy4d5nHCbyp/8DdRPZzzkCDIVLTcgzrwobMTBDEGxsb
yFO7LD+JFyoAcqgcg0ZSIeWpmNgJhGhxpoTPf3YN9bQ0bZud1+r8FjTuCzVOquvq
MLkRWbi5LCfTGu3j472W9ql5BUYmdpG16lXiAVmo8pYf5FwuPCDJNrgVcYUwJ1NB
TYXha63AT43DRR7+qBNeQ5snVIAfW4tM8Gvek8Grx+mtMsYfxW3ABZ49QF4UkBsg
PBLDtLipaDbX7yNNm79JpqweifwuThBKwXxEzaR3PmL7u/iNUMwz+6JdYQ8fkonJ
5oJ9lIAs+i5uCxdNn5/4qBH6S3EgQII3eegKIN+aY4ZAaoKFIPK1HkzhlAZfvv5A
9w0XoAwji5QMgO8w6pFAv3t84eiSDr8mJoL5IJHNKitzEmmobtBg+r1rwkPoqY6e
WbfZPMM66hWQrAkoXyg/
=r9lk
-END PGP SIGNATURE-



Bug#812289: Fwd: Re: Status of GCC 6 on x86_64 (Debian)

2016-02-03 Thread Martin Michlmayr
forwarded 812289 https://github.com/google/googletest/issues/705
thanks

A GCC developer reported this issue upstream.


- Forwarded message from Markus Trippelsdorf  -

Date: Wed, 3 Feb 2016 10:20:30 +0100
From: Markus Trippelsdorf 
To: Matthias Klose 
CC: Martin Michlmayr , g...@gcc.gnu.org
Subject: Re: Status of GCC 6 on x86_64 (Debian)

On 2016.02.03 at 01:13 +0100, Matthias Klose wrote:
> On 22.01.2016 08:27, Matthias Klose wrote:
> >On 22.01.2016 06:09, Martin Michlmayr wrote:
> >>In terms of build failures, I reported 520 bugs to Debian.  Most of them
> >>were new GCC errors or warnings (some packages use -Werror and many
> >>-Werror=format-security).
> >>
> >>Here are some of the most frequent errors see:
> >
> >[...]
> >Martin tagged these issues; https://wiki.debian.org/GCC6 has links with these
> >bug searches.
> 
> Now added the issues with the gcc6-unknown tag, including packages with
> build failures in running the test suites, which might point out wrong-code
> issues.

Looks like Google Mock (of googletest) invokes undefined behavior
(member call on null "this" pointer). So potentially all packages that
use googletest in their testsuite may be affected. 

I've opened: https://github.com/google/googletest/issues/705

-- 
Markus

- End forwarded message -

-- 
Martin Michlmayr
Linux for HPE Helion, Hewlett Packard Enterprise



Bug#813588: RM: libeliom-ocaml -- NBS; uninstallable

2016-02-03 Thread Stéphane Glondu
Package: ftp.debian.org
Severity: normal

Dear FTP masters,

Please remove libeliom-ocaml binaries. It used to be built by eliom,
but is no longer.

Cheers,

-- 
Stéphane



Bug#813256: flex: diff for NMU version 2.6.0-3.1

2016-02-03 Thread Salvatore Bonaccorso
Control: tags 813256 + pending

Dear Manoj,

I've prepared an NMU for flex (versioned as 2.6.0-3.1) and
uploaded it to DELAYED/5. Please feel free to tell me if I
should delay it longer.

Regards,
Salvatore
diff -u flex-2.6.0/debian/changelog flex-2.6.0/debian/changelog
--- flex-2.6.0/debian/changelog
+++ flex-2.6.0/debian/changelog
@@ -1,3 +1,12 @@
+flex (2.6.0-3.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Comments in C style in skeleton.
+Fixes "flex: C++ style comment in C output".
+Thanks to Tim R??hsen  (Closes: #813256)
+
+ -- Salvatore Bonaccorso   Wed, 03 Feb 2016 09:14:07 +0100
+
 flex (2.6.0-3) unstable; urgency=low
 
   * Revert the help2man fix; it was creating errors in the diff.gz
only in patch2:
unchanged:
--- flex-2.6.0.orig/src/flex.skl
+++ flex-2.6.0/src/flex.skl
@@ -2350,7 +2350,7 @@
 		 * scanner will even need a stack. We use 2 instead of 1 to avoid an
 		 * immediate realloc on the next call.
  */
-		num_to_alloc = 1; // After all that talk, this was set to 1 anyways...
+		num_to_alloc = 1; /* After all that talk, this was set to 1 anyways... */
 		YY_G(yy_buffer_stack) = (struct yy_buffer_state**)yyalloc
 (num_to_alloc * sizeof(struct yy_buffer_state*)
 M4_YY_CALL_LAST_ARG);


Bug#813589: pbuilder: please override maintainer in .changes when doing binNMUs

2016-02-03 Thread Mattia Rizzolo
Package: pbuilder
Version: 0.223
User: pbuil...@packages.debian.org
Usertags: pbuilder

binNMUs should not bother maintainers, so we should also pass
-m"$BINNMU_MAINTAINER", not just -e to dpkg-buildpackage.

Happened after my real first binNMU I've just done which triggered 3
emails to the maintainer list, and I didn't want them.


Do anybody disagree with this?  I'm pretty new to this world of
binNMUs...
-- 
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#813580: [Pkg-netfilter-devel] Bug#813580: No Internet Connection with iptables-1.6.0-2

2016-02-03 Thread Tsu Jan
On Wed, 3 Feb 2016 13:00:24 +0100 Arturo Borrero Gonzalez 
 wrote:

> On 3 February 2016 at 12:13, Tsu Jan  wrote:
> You were using connman? Or are you using iptables rules directly?
> Which version of connman are you running?
> --
> Arturo Borrero González
>

Yes, I use connman, which was upgraded alongside iptables from 
v1.21-1.2+b1 to v1.21-1.2+b2 (rebuild against libxtables11).


Downgrading connman alone didn't fix the issue, although I had 
libxtables10 too.




Bug#813580: [Pkg-netfilter-devel] Bug#813580: No Internet Connection with iptables-1.6.0-2

2016-02-03 Thread Arturo Borrero Gonzalez
On 3 February 2016 at 12:13, Tsu Jan  wrote:
> Package: iptables
>
> Version: 1.6.0-2
>
> Yesterday iptables was upgraded from v1.4.21-2+b1 to v1.6.0-2 in Debian
> Testing and today I had no Internet connection (connman.service: Main
> process exited, code=exited, status=1/FAILURE). Fortunately, I had another
> system and could download and then downgrade iptables to v1.4.21-2+b1.
>

You were using connman? Or are you using iptables rules directly?
Which version of connman are you running?
-- 
Arturo Borrero González



Bug#809960: openmsx: FTBFS with libpng16

2016-02-03 Thread Tobias Frost
Package: src:openmsx
Followup-For: Bug #809960
Control: Close -1 

The solution is now that libpng-dev will Depend via libpng16-dev on the Package
containing the pngtool. So no change needed from your side.
Closing this bug then.

-- 
tobi


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

Kernel: Linux 4.0.5-revert-done (SMP w/4 CPU cores)
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)



Bug#813586: libreoffice-writer: Images in PDF export broken

2016-02-03 Thread Jan Gerber
Package: libreoffice-writer
Version: 1:5.1.0~rc3-1
Severity: important

Dear Maintainer,

trying to export documents as pdf, some images are messed up in the
resulting pdf.

Here is a png image and an odt with that png image embedded:

https://r-w-x.org/tests/libreoffice/test.png
https://r-w-x.org/tests/libreoffice/test.odt

This generates the following output:

https://r-w-x.org/tests/libreoffice/test.pdf

Instead the image should look like the png and the odt does during
editing.

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

Kernel: Linux 4.3.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 libreoffice-writer depends on:
ii  libabw-0.1-1   0.1.1-2
ii  libc6  2.21-7
ii  libe-book-0.1-10.1.2-2+b1
ii  libetonyek-0.1-1   0.1.6-1
ii  libgcc11:5.3.1-7
ii  libicu55   55.1-7
ii  libmwaw-0.3-3  0.3.7-1
ii  libodfgen-0.1-10.1.6-1
ii  libreoffice-base-core  1:5.1.0~rc3-1
ii  libreoffice-core   1:5.1.0~rc3-1
ii  librevenge-0.0-0   0.0.4-1
ii  libstdc++6 5.3.1-7
ii  libwpd-0.10-10 0.10.1-1
ii  libwpg-0.3-3   0.3.1-1
ii  libwps-0.4-4   0.4.2-1
ii  libxml22.9.3+dfsg1-1
ii  uno-libs3  5.1.0~rc3-1
ii  ure5.1.0~rc3-1
ii  zlib1g 1:1.2.8.dfsg-2+b1

Versions of packages libreoffice-writer recommends:
ii  libreoffice-math  1:5.1.0~rc3-1

Versions of packages libreoffice-writer suggests:
ii  default-jre [java5-runtime]2:1.7-52.1
pn  fonts-crosextra-caladea
ii  fonts-crosextra-carlito20130920-1
ii  libreoffice-base   1:5.1.0~rc3-1
pn  libreoffice-gcj
ii  libreoffice-java-common1:5.1.0~rc3-1
ii  openjdk-7-jre [java5-runtime]  7u95-2.6.4-1
ii  openjdk-8-jre [java5-runtime]  8u72-b15-1

Versions of packages libreoffice-core depends on:
ii  fontconfig2.11.0-6.3
ii  fonts-opensymbol  2:102.7+LibO5.0.5~rc1-1
ii  libboost-date-time1.58.0  1.58.0+dfsg-4.1+b1
ii  libc6 2.21-7
ii  libcairo2 1.14.6-1
ii  libclucene-contribs1v52.3.3.4-4.1
ii  libclucene-core1v52.3.3.4-4.1
ii  libcmis-0.5-5v5   0.5.0-4
ii  libcups2  2.1.2-2+b1
ii  libcurl3-gnutls   7.47.0-1
ii  libdbus-1-3   1.10.6-1
ii  libdbus-glib-1-2  0.106-1
ii  libdconf1 0.24.0-2
ii  libeot0   0.01-3
ii  libexpat1 2.1.0-7
ii  libexttextcat-2.0-0   3.4.4-1
ii  libfontconfig12.11.0-6.3
ii  libfreetype6  2.6.1-0.1
ii  libgcc1   1:5.3.1-7
ii  libgl1-mesa-glx [libgl1]  11.1.1-2
ii  libglew1.13   1.13.0-2
ii  libglib2.0-0  2.46.2-3
ii  libgltf-0.0-0v5   0.0.2-4+b1
ii  libglu1-mesa [libglu1]9.0.0-2.1
ii  libgraphite2-31.3.5-1
ii  libharfbuzz-icu0  1.0.1-1+b1
ii  libharfbuzz0b 1.0.1-1+b1
ii  libhunspell-1.3-0 1.3.3-3+b2
ii  libhyphen02.8.8-2
ii  libice6   2:1.0.9-1+b1
ii  libicu55  55.1-7
ii  libjpeg62-turbo   1:1.4.2-2
ii  liblangtag1   0.5.7-2
ii  liblcms2-22.6-3+b3
ii  libldap-2.4-2 2.4.42+dfsg-2+b2
ii  libmythes-1.2-0   2:1.2.4-1
ii  libneon27-gnutls  0.30.1-3
ii  libnspr4  2:4.11-1
ii  libnss3   2:3.21-1
ii  libnss3-1d2:3.21-1
ii  libodfgen-0.1-1   0.1.6-1
ii  libpcre3  2:8.38-1
ii  libpng12-01.2.54-1
ii  librdf0   1.0.17-1+b1
ii  libreoffice-common1:5.1.0~rc3-1
ii  librevenge-0.0-0  0.0.4-1
ii  libsm62:1.2.2-1+b1
ii  libssl1.0.2   1.0.2f-2
ii  libstdc++65.3.1-7
ii  libx11-6  2:1.6.3-1
ii  libxext6  2:1.3.3-1
ii  libxinerama1  2:1.1.3-1+b1
ii  libxml2   2.9.3+dfsg1-1
ii  libxrandr22:1.5.0-1
ii  libxrender1   1:0.9.9-2
ii  libxslt1.11.1.28-2.1
ii  uno-libs3 5.1.0~rc3-1
ii  ure   5.1.0~rc3-1
ii  zlib1g1:1.2.8.dfsg-2+b1

-- no debconf information



Bug#813573: [pkg-horde] Bug#813573: [php-horde] XSS vulnerability in menu bar

2016-02-03 Thread Mathieu Parent
Control: tag -1 + security upstream fixed-upstream pending
Control: severity -1 grave
Control: forwarded -1 https://bugs.horde.org/ticket/14213

This is a security bug probably affecting jessie. I need to patch this
branch too.

Remark: No CVE, as usual with horde.

-- 
Mathieu Parent



Bug#757356: evtest: doesn't output scan codes for some keys

2016-02-03 Thread Vincent Lefevre
Control: retitle -1 Scan code event not generated for some keys of the Appple 
keyboard
Control: found -1 4.3.3-7

Things have improved since now the normal keys have their scan code.
This is not the case of the Fn key, but this may be normal since this
is a special key that modifies other keys. But this is not the case
either for Fn+F1, etc.

$ head /sys/module/hid_apple/parameters/*
==> /sys/module/hid_apple/parameters/fnmode <==
2

==> /sys/module/hid_apple/parameters/iso_layout <==
0

==> /sys/module/hid_apple/parameters/swap_opt_cmd <==
0

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



Bug#813523: RFS: h5py/2.6.0-1

2016-02-03 Thread PICCA Frederic-Emmanuel
Uploaded

thanks for your work

Frederic


Bug#813590: [php-horde-core] XSS in Horde_Core_VarRenderer_Html

2016-02-03 Thread Mathieu Parent
Package: php-horde-core
Version: 2.22.5+debian0-1

Will post more info later.

-- 
Mathieu



Bug#808821: asymptote: failing to build on mips

2016-02-03 Thread Norbert Preining
Hi Julian,

> It turns out that it is a compiler bug, or at least it is as far as we
> can tell: the code works fine with -O0 but bombs with -O1.  See
> https://sourceforge.net/p/asymptote/bugs/205/ for the full discussion.

BIG BIG BIG THANKS! I have followed the bug report from the very
beginning, and you have done an awful great job. Big thanks.

> I guess I should report this upstream - I guess against g++?  But
> finding a minimal example will be hard.

>From my experience with gcc bugs is that nobody cares as long as you
cannot reproduce it with the very very very latest gcc (6?) and
I guess you don't want to go to that length. But feel free.

> compile fine under MIPS, so please do upgrade to version 2.37.  This,

I just checked, not released by now, but as soon as it is I will update
the Debian repository.

Big thanks again, and also thanks for the heads up about the elisp patch.

All the best

Norbert


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




Bug#813566: imagemagick-6.q16: missing package dependency to librsvg2-bin

2016-02-03 Thread Vincent Fourmond
control: severity -1 wishlist
control: rename -1 "Make it clear that SVG support (and other) comes
from -extra ?"

  Dear Takahide,

  The problem comes from the fact that libmagickcore-6.q16-2-extra,
which contains support for the "more exotic and/or more demanding"
image formats such as SVG, is not installed. This is shown by:

> Versions of packages imagemagick-6.q16 recommends:
> ii  ghostscript  9.16~dfsg-2.1
> pn  libmagickcore-6.q16-2-extra  
> ii  netpbm   2:10.0-15.3

  You should keep in mind that if you don't have the recommended
packages installed, some of the standard functionalities may be
missing, so missing SVG support shouldn't be surprising.

  We cannot have the libmagickcore-6.q16-2-extra package installed by
default, the best we could do is to clarify for what the -extra
package is needed in the package description.

  Regards,

  Vincent



Bug#813591: ITP: baka-mplayer -- A libmpv based media player

2016-02-03 Thread Ximin Luo
Package: wnpp
Severity: wishlist
Owner: Ximin Luo 

* Package name: baka-mplayer
  Version : 2.0.4
  Upstream Author : Daniel Clarke 
* URL : http://bakamplayer.u8sand.net/
* License : GPL-2
  Programming Lang: C++
  Description : A libmpv based media player

Baka MPlayer is a free and open source, cross-platform, libmpv based multimedia
player. Its simple design reflects the idea for an uncluttered and enjoyable
environment for watching tv shows. Features:

 * Gesture seeking.
 * Smart playlist.
 * Dim Desktop.
 * Hardware accelerated playback (vdpau, vaapi, vda).
 * Youtube playback support (and others).
 * Multilingual support (we are looking for translators!).
 * And more...



Bug#807455: golang-src: includes race detector runtime files not built from source in the source package

2016-02-03 Thread Michael Hudson-Doyle
On 3 February 2016 at 19:08, Tianon Gravi  wrote:
> On 8 December 2015 at 18:24, Michael Hudson-Doyle
>  wrote:
>> The files installed as /usr/share/go/src/runtime/race/*.syso are not built
>> during package build, but rather come directly from the Go source 
>> distribution.
>> To ensure that they are built from what they claim to be, in Ubuntu we do not
>> distribute these files in the golang-src package but rather build them in a
>> separate golang-race-detector-runtime package which golang-go Recommends:. It
>> would be nice if Debian could steal this work :-)
>
> I'm definitely keen on this one!

Yay.

> I think my issue with making it happen (last I looked into it) was
> that the files in question needed to come from a separate source (LLVM
> was it? [1]), and the exact versioning necessary was a little strange,
> and it was sources that already exist in the Debian archive for
> another package so I wasn't really clear on whether that's kosher or
> whether we should be talking to the existing package maintainer to
> keep things sane.  Am I remembering this correctly?

Yes, your memory is pretty accurate. The source in question is the
"compiler-rt" runtime libraries: http://compiler-rt.llvm.org/. The
compiler-rt source is copied into the gcc and llvm trees -- although
on checking, the copy in the gcc source lacks the go integration bits.
The one in llvm-toolchain appears to have everything (in fact it's a
multi orig source package, and one of the orig tarballs is the
compiler-rt stuff), so the golang-race-detector-runtime could be built
from the llvm-toolchain source package. The only question is around
versioning then -- I don't have any intuition as to how much
difference there is between the revisions go builds they're objects
from and the revision for the compiler-rt that's part of the current
llvm package at all. I've just wussed out of thinking about that so
far. I guess I could ask upstream...

Cheers,
mwh

>  I really
> should've made some notes after I spent some time playing with this,
> sorry. :(
>
> [1]: https://github.com/golang/go/tree/go1.6rc1/src/runtime/race#readme
>
> ♥,
> - Tianon
>   4096R / B42F 6819 007F 00F8 8E36  4FD4 036A 9C25 BF35 7DD4



Bug#506764: siproxd: Problem with DNS resolution when in chroot jail

2016-02-03 Thread Richard van den Berg
I can confirm this problem stil exists in siproxd 1:0.8.1-4+b1 :

Feb  3 09:51:51 majoron siproxd[7025]: siproxd.c:526 received SIP type 
REQ:REGISTER
Feb  3 09:51:51 majoron siproxd[7025]: utils.c:197 
gethostbyname(sip.freevoipdeal.com) failed:
h_errno=1 [Unknown host]


Editing /etc/hosts and removing all entries for "localhost" (and restarting 
siproxd) fixes the problem:

Feb  3 09:57:00 majoron siproxd[7113]: siproxd.c:526 received SIP type 
REQ:REGISTER
Feb  3 09:57:00 majoron siproxd[7113]: utils.c:215 DNS lookup - resolved: 
sip.freevoipdeal.com ->
77.72.174.128

Kind regards,

Richard



Bug#739363: miredo: #739363 Problem w/ Network Manager?

2016-02-03 Thread Hilmar Preuße
Source: miredo
Version: 1.2.6-2
Followup-For: Bug #739363

Dear Maintainer,

I have a similar problem (at least it looks so): the miredo tunnel is not
properly activated due to DNS resolution.
My system uses Network Manager to get the network configured and the Network
Manager starts *after* miredo (see attached daemon.log).

Not sure how to solve that.

Hilmar

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

Kernel: Linux 4.3.0-1-686-pae (SMP w/1 CPU core)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to en_GB.UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)
Feb  2 11:43:15 debian dbus[494]: [system] Reloaded configuration
Feb  2 11:43:15 debian dbus[494]: [system] Reloaded configuration
Feb  2 11:43:15 debian dbus[494]: [system] Reloaded configuration
Feb  2 11:43:15 debian dbus[494]: [system] Reloaded configuration
Feb  2 11:43:15 debian dbus[494]: [system] Reloaded configuration
Feb  2 11:43:16 debian dbus[494]: [system] Reloaded configuration
Feb  2 11:43:16 debian dbus[494]: [system] Reloaded configuration
Feb  2 11:43:16 debian dbus[494]: [system] Reloaded configuration
Feb  2 11:43:16 debian dbus[494]: [system] Reloaded configuration
Feb  2 11:43:16 debian dbus[494]: [system] Reloaded configuration
Feb  2 11:43:16 debian dbus[494]: [system] Reloaded configuration
Feb  2 11:43:17 debian dbus[494]: [system] Reloaded configuration
Feb  2 11:43:17 debian dbus[494]: [system] Reloaded configuration
Feb  2 11:43:17 debian dbus[494]: [system] Reloaded configuration
Feb  2 11:43:17 debian dbus[494]: [system] Reloaded configuration
Feb  2 11:43:17 debian dbus[494]: [system] Reloaded configuration
Feb  2 11:43:17 debian dbus[494]: [system] Reloaded configuration
Feb  2 11:43:17 debian dbus[494]: [system] Reloaded configuration
Feb  2 11:43:19 debian dbus[494]: [system] Reloaded configuration
Feb  2 11:43:19 debian dbus[494]: [system] Reloaded configuration
Feb  2 11:43:19 debian dbus[494]: [system] Reloaded configuration
Feb  2 11:43:20 debian systemd[1]: Reexecuting.
Feb  2 11:43:40 debian systemd[821]: Stopping Default.
Feb  2 11:43:40 debian systemd[821]: Stopped target Default.
Feb  2 11:43:40 debian systemd[821]: Stopping Basic System.
Feb  2 11:43:40 debian systemd[821]: Stopped target Basic System.
Feb  2 11:43:40 debian systemd[821]: Stopping Paths.
Feb  2 11:43:40 debian systemd[821]: Stopped target Paths.
Feb  2 11:43:40 debian systemd[821]: Stopping Timers.
Feb  2 11:43:40 debian systemd[821]: Stopped target Timers.
Feb  2 11:43:40 debian systemd[821]: Stopping Sockets.
Feb  2 11:43:40 debian systemd[821]: Stopped target Sockets.
Feb  2 11:43:40 debian systemd[821]: Starting Shutdown.
Feb  2 11:43:40 debian systemd[821]: Reached target Shutdown.
Feb  2 11:43:40 debian systemd[821]: Starting Exit the Session...
Feb  2 11:43:40 debian systemd[821]: Received SIGRTMIN+24 from PID 13219 (kill).
Feb  2 11:44:11 debian exim4[15934]: Stopping MTA: exim4_listener.
Feb  2 11:44:55 debian exim4[21229]: Starting MTA: exim4.
Feb  2 11:45:38 debian dhclient: DHCPREQUEST on eth0 to 192.168.48.254 port 67
Feb  2 11:45:38 debian dhclient: DHCPACK from 192.168.48.254
Feb  2 11:45:38 debian NetworkManager[475]:  (eth0): DHCPv4 state changed 
bound -> renew
Feb  2 11:45:38 debian NetworkManager[475]:address 192.168.48.179
Feb  2 11:45:38 debian NetworkManager[475]:plen 24 (255.255.255.0)
Feb  2 11:45:38 debian NetworkManager[475]:gateway 192.168.48.254
Feb  2 11:45:38 debian NetworkManager[475]:server identifier 
192.168.48.254
Feb  2 11:45:38 debian NetworkManager[475]:lease time 600
Feb  2 11:45:38 debian NetworkManager[475]:nameserver '8.8.8.8'
Feb  2 11:45:38 debian dhclient: bound to 192.168.48.179 -- renewal in 237 
seconds.
Feb  2 11:45:38 debian dbus[494]: [system] Activating via systemd: service 
name='org.freedesktop.nm_dispatcher' 
unit='dbus-org.freedesktop.nm-dispatcher.service'
Feb  2 11:45:38 debian dbus[494]: [system] Successfully activated service 
'org.freedesktop.nm_dispatcher'
Feb  2 11:45:38 debian nm-dispatcher: Dispatching action 'dhcp4-change' for eth0
Feb  2 11:47:57 debian miredo[30087]: Starting...
Feb  2 11:47:57 debian miredo[30087]: miredo[30087]: Starting...
Feb  2 11:47:57 debian NetworkManager[475]:  (teredo): carrier is OFF
Feb  2 11:47:57 debian NetworkManager[475]:  (teredo): new Tun device 
(driver: 'unknown' ifindex: 3)
Feb  2 11:47:57 debian NetworkManager[475]:  (teredo): exported as 
/org/freedesktop/NetworkManager/Devices/2
Feb  2 11:47:57 debian NetworkManager[475]:  devices added (path: 
/sys/devices/virtual/net/teredo, iface: teredo)
Feb  2 11:47:57 debian NetworkManager[475]:  device added (path: 
/sys/devices/virtual/net/teredo, iface: teredo): no ifupdown configuration 
found.
Feb  2 11:47:57 debian miredo[30098]: New Teredo address/MTU
Feb  2 11:47:57 debian miredo[30098]: 

Bug#813164: coreutils: ls suddenly quotes output

2016-02-03 Thread Christoph Berg
Re: Jamie Heilman 2016-02-02 
<20160202211938.gb4...@cucamonga.audible.transient.net>
> This behavior needs to be reverted.  There are too many assumptions
> being made, the quoting used is shell-specific, and not universally
> supported.  For example, consider a file who's name contains a tab,
> like "ab".
> 
> $ ls
> 'a'$'\t''b'

Urgh. Similarly unreadable:

$ touch "o'really"
$ ls o*y
'o'\''really'

> OK, so that syntax is supported by bash and zsh, so if you're using
> one of those shells, maybe you know what it means, and you can cut and
> paste that and make use of it, but in csh or dash, it doesn't mean the
> same thing.

First of all I want to *read* the ls output. I'm not interested in
funky shell characters there.

Please revert this feature.

Christoph
-- 
c...@df7cb.de | http://www.df7cb.de/


signature.asc
Description: PGP signature


Bug#813579: virt-manager: Cloning ignores sparse disk

2016-02-03 Thread Klaus Fuerstberger
Package: virt-manager
Version: 1:1.0.1-5
Severity: important

Dear Maintainer,

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

When cloning a VM in virt-manager (right click - "Clone") the cloned disk file 
is fully allocated even when cloning a sparse disk.

The original disk:
# du -h asv1-jessie-clone.img 
3.9Gasv1-jessie-clone.img

The cloned disk:
# du -h asv1-jessie-clone1.img 
81G asv1-jessie-clone1.img

In the debug output it recognizes the allocation but obviously does not clone 
with the sparse option:

##
[Mi, 03 Feb 2016 11:38:10 virt-manager 22690] DEBUG (cloner:426) Starting 
duplicate.
[Mi, 03 Feb 2016 11:38:10 virt-manager 22690] DEBUG (storage:701) Creating 
storage volume 'asv1-jessie-clone1.img' with xml:

  asv1-jessie-clone1.img
  85899345920
  4064464896
  

  

##

In earlier versions of virt-manager cloning sparse files as sparse files was 
possible.

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

Kernel: Linux 3.16.0-4-amd64 (SMP w/12 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: sysvinit (via /sbin/init)

Versions of packages virt-manager depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.22.0-1
ii  gconf2   3.2.6-3
ii  gir1.2-gtk-3.0   3.14.5-1+deb8u1
ii  gir1.2-gtk-vnc-2.0   0.5.3-1.3
ii  gir1.2-libvirt-glib-1.0  0.1.9-4
ii  gir1.2-vte-2.90  1:0.36.3-1
ii  librsvg2-common  2.40.5-1
ii  python-dbus  1.2.0-2+b3
ii  python-gi3.14.0-1
ii  python-gi-cairo  3.14.0-1
ii  python-ipaddr2.1.11-2
ii  python-libvirt   1.2.9-1
ii  python-urlgrabber3.9.1-4.1
pn  python2.7:any
pn  python:any   
ii  virtinst 1:1.0.1-5

Versions of packages virt-manager recommends:
ii  gir1.2-spice-client-gtk-3.0  0.25-1+b1
ii  gnome-icon-theme 3.12.0-1
ii  libvirt-daemon-system1.2.9-9+deb8u1

Versions of packages virt-manager suggests:
ii  gnome-keyring3.14.0-1+b1
pn  python-gnomekeyring  
pn  python-guestfs   
ii  ssh-askpass  1:1.2.4.1-9
ii  virt-viewer  1.0-1

-- no debconf information



Bug#813574: ITP: libtemplate-stash-autoescaping-perl -- escape automatically in Template-Toolkit

2016-02-03 Thread Julian Maurice
Package: wnpp
Severity: wishlist
Owner: Julian Maurice 

* Package name: libtemplate-stash-autoescaping-perl
  Version : 0.0303
  Upstream Author : Shlomi Fish 
* URL : https://metacpan.org/release/Template-Stash-AutoEscaping
* License : Artistic or GPL-1+
  Programming Lang: Perl
  Description : escape automatically in Template-Toolkit

Template::Stash::AutoEscaping is a sub class of Template::Stash,
automatically escape all HTML strings and avoid XSS vulnerability.



Bug#813544: [pkg-go] Bug#813544: prometheus-node-exporter: cannot run as root

2016-02-03 Thread Martín Ferrari
Hi Anton,

On 02/02/16 23:10, Anton T wrote:

> It seems that setting USER=root in /etc/default/prometheus-node-exporter
> breaks the init script because HELPER_ARGS is defined before
> /etc/default/$NAME is included.

Thanks for the patch! I have already applied it in the git repository,
and will be uploaded soon.

Now, I would not recommend to run the node exporter as root, unless
absolutely necessary. Do you have a use case for it?

-- 
Martín Ferrari (Tincho)



Bug#813374: general: Menus and window popup does not work after recent upgrade

2016-02-03 Thread Thomas Goirand
On 02/01/2016 09:01 PM, Vincent Danjean wrote:
>   It worked well. I was able to move window between the two monitors.
> 
>   But, after the last upgrade (see below the upgraded packages), I suffer
> several problems after I enabled the external monitor:
> - window from iceweasel and icedove opened with a very small size (unless
>   before where they opened at their last size) [but correctly on the primary
>   external monitor]
> - popup windows from iceweasel and icedove (to ask for password or passphrase
>   or to ask to restore or not the session) all opened on the laptop monitor in
>   a small size (wheras the mouse was on the primary monitor)
> - more problematic (hence this bug report), menus in iceweasel and icedove do
>   not draw themselves. The heading is selected but nothing appears below. It 
> is
>   also true for menus from their toolbar (ie 'Tags' selector in icedove for
>   example)
> - for emacs, if the window is at a high where the secondary monitor have
>   pixels, the menu is opened on the left of the secondary monitor! Else, the
>   menu do not open at all.
> - other programs work correctly (at least the 'Applications' menu of XFCE that
>   I use as VM, menus from Thunar, menus and windows from GIMP, ...)
> - for problematic applications (at least Iceweasel, Icedove and Emacs), moving
>   the window onto the other monitor (without closing it) allows menus to be
>   correctlt drawn (on the other monitor). When the window is moved again onto
>   the primary external monitor, the problematic behavior occurs again.
> 
>   So, if someone have an idea of what happens, of where (in which softare) is
> the bug, or just want additionnal inputs, just say so. For now, this is really
> annoying.
> 
>   Regards,
> Vincent

Vincent,

This sounds like issues with your window manager, since you mostly
complain about issues with window placements and dispositions. Just to
be sure, you're using XFCE, right?

Cheers,

Thomas Goirand (zigo)



Bug#812444: aptitude: REQUEST: operator to version order test in "aptitude search" query syntax.

2016-02-03 Thread Manuel A. Fernandez Montecelo

Control: severity -1 wishlist


Hi,

2016-01-23 20:55 Oleksandr Gavenko:


I have Debian and Kali origins. Kali based on Debian stable.

So Kali follow Debian package naming schema but differ in version numbers.

They also respect Debian version numbering.

So it is possible to make queries to list difference between Debian and Kali
with "aptitude search".

For example to find command packages with same version:

 $ aptitude search '?narrow(?origin(Kali),?origin(Debian))'
 ...

To find packages that in Kali but not in Debian:

 $ aptitude search '?origin(Kali),!?origin(Debian)'
 ...

I would like to find packages that have newer version in Kali than in Debian.

Docs:

 https://www.debian.org/doc/manuals/aptitude/ch02s04s05.html

say nothing about direct version comparing.

Some indirect comparing possible via ?upgradable and setting priorities in
debootstrap'ed environment and chrooting and installing packages.

'?narrow' is equal operator for package version.

I need a strict greater operator:

 aptitude search '?gt(?origin(Kali),?origin(Debian))'

- any package version that greater.

Origins of my question come from (Russian text):

 http://permalink.gmane.org/gmane.linux.debian.user.russian/123271



I think that indeed the way to get this list of newer packages Kali than
in Debian is using ?upgradable, if pinning of the repositories (man
apt_preferences) is done correctly and if Kali's versions indeed show
higher numbers than Debian.  Is this not working properly?

Another way to get such a list would be to produce a list of packages
and versions of both Kali an Debian, and post-process it using "dpkg
--compare-versions".


In general, I don't know if the requested operator is very useful,
because aptitude and apt have different concept of how the system should
work, based on apt pinning.  Packages in Debian experimental or unstable
might have bigger version numbers than the ones in testing or stable,
but still the ones in testing and stable used by default, because the
user prefers to maintain most packages in the stable or testing version.

So "?upgradable" and other terms are more complex carry more meaning
than a simple "greather-than" comparison, and I think that it should be
that way.

And if it's just for that comparison, "dpkg --compare-versions" is the
authoritative source anyway, with its nuances when comparing
alphanumeric strings with symbols.


Cheers.
--
Manuel A. Fernandez Montecelo 



Bug#618560: Acknowledgement (/usr/sbin/service: Provide chkconfig (to enable/disable services))

2016-02-03 Thread Olaf van der Spek
2016-01-31 1:39 GMT+01:00 Michael Biebl :
> On Fri, 25 Mar 2011 12:50:18 +0100 Olaf van der Spek
>  wrote:
>> > If you need help, I'm willing to work on this one myself.
>>
>> Somebody?
>
> What exactly are you missing from the existing tools?

I don't remember..
Feel free to close.


-- 
Olaf



Bug#808821: asymptote: failing to build on mips

2016-02-03 Thread Julian Gilbey
On Fri, Jan 29, 2016 at 11:22:33PM +0900, Norbert Preining wrote:
> Hi Julian,
> 
> On Fri, 29 Jan 2016, Julian Gilbey wrote:
> > I've reported it upstream; John Bowman responded to the last report
> > very quickly indeed (thanks, John!), so I suggest we wait a couple of
> > days before disabling mips.
> 
> Ok, sure enough.
> 
> > Alternatively, one could argue that it is just this one bug - it is
> > not the whole package which is affected - and exclude this one
> 
> I guess all the 3d related files will fail, which is rather 
> disappointing.
> 
> For now let us wait for John's answer. Did you open a new bug
> or reopen the old one?

It turns out that it is a compiler bug, or at least it is as far as we
can tell: the code works fine with -O0 but bombs with -O1.  See
https://sourceforge.net/p/asymptote/bugs/205/ for the full discussion.
I guess I should report this upstream - I guess against g++?  But
finding a minimal example will be hard.

Anyway, a workaround has been applied, and the code now appears to
compile fine under MIPS, so please do upgrade to version 2.37.  This,
incidentally, includes the elisp documentation bug patch, so that will
no longer be needed in the Debian package, and nor will the recently
applied patch from the git repo.

Best wishes,

   Julian



Bug#776401: [Pkg-golang-devel] Bug#776401: Bug#776401: src:golang: Set CGO_ENABLED for all platforms

2016-02-03 Thread Hilko Bengen
* Tianon Gravi:

> I'm not positive whether all were required for this to work, but given
> that it _did_ work, I think this is in the realm of possible with the
> changes of Go 1.5 and am inclined to close this bug as "fixed" --
> thoughts? :)

Unfortunately, it's not that easy. :-(

Last time I checked, I was able to "go build" a package from $GOPATH,
but not "go install" because "go install" wanted to install the
cross-built standard library for the other architecture to $GOROOT, even
if no CGO was involved. This is still the case with golang 2:1.5.3-1.

For demonstration purposes, here's what I tried with something similar
to your test case:

1. Set up an empty GOPATH with a package directory structure:

,
| $ mkdir -p gopath/src/example.org/foo
| $ cat > gopath/src/example.org/foo/test.go
| package foo
| 
| // #include 
| import "C"
| 
| func Foo() {
| C.fopen(C.CString("test.txt"), C.CString("r"))
| }
`

2. "go install" for the native environment

,
| $ GOPATH=`pwd`/gopath go install -v -x  example.org/foo
| WORK=/tmp/go-build567075617
| example.org/foo
| mkdir -p $WORK/example.org/foo/_obj/
| mkdir -p $WORK/example.org/
| cd /home/bengen/tmp/go-cross-test/gopath/src/example.org/foo
| CGO_LDFLAGS="-g" "-O2" /usr/lib/go/pkg/tool/linux_amd64/cgo -objdir 
$WORK/example.org/foo/_obj/ -importpath example.org/foo -- -I 
$WORK/example.org/foo/_obj/ test.go
| gcc -I . -fPIC -m64 -pthread -fmessage-length=0 -print-libgcc-file-name
| gcc -I . -fPIC -m64 -pthread -fmessage-length=0 -I 
$WORK/example.org/foo/_obj/ -g -O2 -o $WORK/example.org/foo/_obj/_cgo_main.o -c 
$WORK/example.org/foo/_obj/_cgo_main.c
| gcc -I . -fPIC -m64 -pthread -fmessage-length=0 -I 
$WORK/example.org/foo/_obj/ -g -O2 -o $WORK/example.org/foo/_obj/_cgo_export.o 
-c $WORK/example.org/foo/_obj/_cgo_export.c
| gcc -I . -fPIC -m64 -pthread -fmessage-length=0 -I 
$WORK/example.org/foo/_obj/ -g -O2 -o $WORK/example.org/foo/_obj/test.cgo2.o -c 
$WORK/example.org/foo/_obj/test.cgo2.c
| gcc -I . -fPIC -m64 -pthread -fmessage-length=0 -o 
$WORK/example.org/foo/_obj/_cgo_.o $WORK/example.org/foo/_obj/_cgo_main.o 
$WORK/example.org/foo/_obj/_cgo_export.o $WORK/example.org/foo/_obj/test.cgo2.o 
-g -O2
| /usr/lib/go/pkg/tool/linux_amd64/cgo -objdir $WORK/example.org/foo/_obj/ 
-dynpackage foo -dynimport $WORK/example.org/foo/_obj/_cgo_.o -dynout 
$WORK/example.org/foo/_obj/_cgo_import.go
| gcc -I . -fPIC -m64 -pthread -fmessage-length=0 -o 
$WORK/example.org/foo/_obj/_all.o $WORK/example.org/foo/_obj/_cgo_export.o 
$WORK/example.org/foo/_obj/test.cgo2.o -g -O2 -Wl,-r -nostdlib 
/usr/lib/gcc/x86_64-linux-gnu/5/libgcc.a -Wl,--build-id=none
| /usr/lib/go/pkg/tool/linux_amd64/compile -o $WORK/example.org/foo.a -trimpath 
$WORK -p example.org/foo -buildid bd90e3598b891a30d744d0b538320556a1cbce19 -D 
_/home/bengen/tmp/go-cross-test/gopath/src/example.org/foo -I $WORK -pack 
$WORK/example.org/foo/_obj/_cgo_gotypes.go 
$WORK/example.org/foo/_obj/test.cgo1.go 
$WORK/example.org/foo/_obj/_cgo_import.go
| pack r $WORK/example.org/foo.a $WORK/example.org/foo/_obj/_all.o # internal
| mkdir -p /home/bengen/tmp/go-cross-test/gopath/pkg/linux_amd64/example.org/
| mv $WORK/example.org/foo.a 
/home/bengen/tmp/go-cross-test/gopath/pkg/linux_amd64/example.org/foo.a
| $ find gopath/pkg
| gopath/pkg
| gopath/pkg/linux_amd64
| gopath/pkg/linux_amd64/example.org
| gopath/pkg/linux_amd64/example.org/foo.a
`

3. "go install" for different GOOS/GOARCH:

,
| $ GOPATH=`pwd`/gopath GOOS=windows GOARCH=386 CGO_ENABLED=1 
CC=i686-w64-mingw32-gcc go install -v -x  example.org/foo
| runtime
| mkdir -p $WORK/runtime/_obj/
| mkdir -p $WORK/
| cd /usr/lib/go/src/runtime
| /usr/lib/go/pkg/tool/linux_amd64/compile -o $WORK/runtime.a -trimpath $WORK 
-p runtime -+ -buildid c465ba923d1f8f93ffbb38a56ab921e0ac0c161d -D 
_/usr/lib/go/src/runtime -I $WORK -pack -asmhdr $WORK/runtime/_obj/go_asm.h 
./alg.go ./arch1_386.go ./arch_386.go ./atomic_386.go ./atomic_pointer.go 
./cgo.go ./cgocall.go ./cgocallback.go ./chan.go ./compiler.go ./complex.go 
./cpuprof.go ./cputicks.go ./debug.go ./defs_windows_386.go ./env_posix.go 
./error.go ./extern.go ./hash32.go ./hashmap.go ./hashmap_fast.go ./heapdump.go 
./iface.go ./lfstack.go ./lfstack_32bit.go ./lock_sema.go ./malloc.go 
./mbarrier.go ./mbitmap.go ./mcache.go ./mcentral.go ./mem_windows.go 
./mfinal.go ./mfixalloc.go ./mgc.go ./mgcmark.go ./mgcsweep.go ./mgcwork.go 
./mheap.go ./mprof.go ./msize.go ./mstats.go ./netpoll.go ./netpoll_windows.go 
./os1_windows.go ./os2_windows.go ./os_windows.go ./panic.go ./panic1.go 
./parfor.go ./print1.go ./print1_write.go ./proc.go ./proc1.go ./race0.go 
./rdebug.go ./rune.go ./runtime.go ./runtime1.go ./runtime2.go ./select.go 
./sema.go ./signal_windows.go ./sigqueue.go ./slice.go ./softfloat64.go 
./sqrt.go ./stack1.go ./stack2.go ./string.go ./string1.go ./stubs.go 
./stubs32.go ./symtab.go ./sys_x86.go ./syscall_windows.go ./time.go ./trace.go 
./traceback.go ./type.go ./typekind.go 

Bug#808775: CKeditor: outstanding issues and maintenance; build system

2016-02-03 Thread roucaries bastien
On Wed, Feb 3, 2016 at 4:02 PM, Dmitry Smirnov  wrote:
> Guys, we have a problem with CKeditor.
> As I've recently realised, in its current source form CKeditor can't be
> loaded dynamically which breaks one of my packages after update. Therefore
> CKeditor badly needs maintenance.
>
> I took some time to learn how to build CKeditor from source. Current way is
> not safe and not compatible with official release. The best way to build
> CKeditor is to use CKbuilder that I've just packaged (#813577). As soon as it
> will be accepted I'd like to update CKeditor ASAP so I'm offering myself as
> (co-)maintainer.


Thanks help welcome.

How do you achieve to clean ckbuilder from source is missing and
license problem ?

Last time I give up...
> Knowing that package is in poor shape and not updated for a while I took
> liberty to introduce some improvements into "master" branch that I created in
> the package repository:
>
> https://anonscm.debian.org/cgit/collab-maint/ckeditor.git
Done pushed
>
> I did that because I found repository in bad shape -- one tag incorrectly
> applied (mismatch with uploaded package), two tags missing which comes down
> to three last uploads not committed. :(
>
> In master branch I was working only within "debian" directory and I did not
> touch upstream files as I'm not too sure about repository layout and I wanted
> to avoid introducing too many layout-related changes.

Layout is gitpkg. I have added debian directory above all. I use
debian/version branch for upstream+patches+debian directory
upstream/version for upstream and debian-patches/version for upstream+patch

> Bastien, would you be interested to help or would you rather leave CKeditor
> maintenance with me (at least for some time)?

I cannot work on it now. I need to care about my new born baby.

> Frank, are you still interested in maintaining CKeditor?
>
> Thanks.
>
> --
> Best wishes,
>  Dmitry Smirnov.
>
> ---
>
> There is not enough love and goodness in the world to permit giving any of
> it away to imaginary beings.
> -- Friedrich Nietzsche



Bug#805498: systemd: Systemd errors in syslog: Failed to set cpu.cfs_{period, quota}_us

2016-02-03 Thread Michael Biebl
Am 03.02.2016 um 22:24 schrieb Ralf Jung:
> Hi,
> 
>> Afaics, docker is using one of CPU* resource control features. This
>> requires a kernel that supports it.
>> You can either try to convince the kernel maintainers to enable that
>> support, compile a kernel on your own, or fix docker, to not make use of
>> that feature in jessie. I don't think there is a lot we can do in
>> systemd about this.
> 
> I agree. The units that show this error are entirely independent from
> Docker, so I still do not understand how installing Docker can trigger
> this - but that's at best a minor bug in the logging.

It's not really a bug in the logging. The log messages seem correct to me.
Which docker version is that btw?


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



signature.asc
Description: OpenPGP digital signature


Bug#813636: libmicrohttpd10: new version available upstream: 0.9.48

2016-02-03 Thread Ohm Base
Package: libmicrohttpd10
Version: 0.9.44+dfsg-1+b2
Severity: wishlist

Dear Maintainer,

As per

https://www.gnu.org/software/libmicrohttpd/

a new version ( 0.9.48 ) has been released on the GNU project's FTP server:

ftp://ftp.gnu.org/gnu/libmicrohttpd






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

Kernel: Linux 4.3.0-1-686-pae (SMP w/2 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 libmicrohttpd10 depends on:
ii  libc62.21-7
ii  libgcrypt20  1.6.4-5
ii  libgnutls30  3.4.8-3

libmicrohttpd10 recommends no packages.

libmicrohttpd10 suggests no packages.

-- no debconf information


Bug#813639: parallel: new version available upstream: 20151222

2016-02-03 Thread Ohm Base
Package: parallel
Version: 20141022+ds1-1
Severity: wishlist

Dear Maintainer,

As per

https://www.gnu.org/software/parallel/

a new version of GNU parallel (20151222) is available on the GNU project's
FTP
site at

http://ftp.gnu.org/gnu/parallel/




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

Kernel: Linux 4.3.0-1-686-pae (SMP w/2 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 parallel depends on:
ii  perl  5.22.1-5
ii  perl-modules-5.22 [perl-modules]  5.22.1-5
ii  sysstat   11.2.0-1

parallel recommends no packages.

parallel suggests no packages.

-- no debconf information


Bug#813640: Enable VMX crypto extensions module

2016-02-03 Thread Timothy Pearson
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA224

Package: linux-image-4.3.0-1-powerpc64
Version: 4.3.3-7
Severity: normal

The POWER8 processors use VMX to accelerate cryptographic functions.  
Linux supports the use of VMX for cryptographic acceleration, however
Debian does not build this module, leaving users of some systems (e.g.
OpenPOWER) unable to reach rated bandwidths e.g. in OpenSSL.

Please enable the VMX cryptographic extensions module with
CONFIG_CRYPTO_DEV_VMX=m in the kernel configuration.

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)

iFYEARELAAYFAlayfr0ACgkQLaxZSoRZrGG7jgDeJP6HVdTmuRbnBrMdM9JKxLFS
V0e4BLuRB2qp8gDdHQ2pcqsHPF1uxHHMag5N7c8GZgGv0N0a5vEgYQ==
=epAE
-END PGP SIGNATURE-



Bug#813629: libccaudio2-dev: new version available upstream: 2.2.0

2016-02-03 Thread Ohm Base
Package: libccaudio2-dev
Version: 2.1.3-1.1+b2
Severity: wishlist

Dear Maintainer,

There is a new version of ccaudio2 available upstream (2.2.0) at the GNU
project.

https://www.gnu.org/software/ccaudio/
ftp://ftp.gnu.org/pub/gnu/ccaudio/





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

Kernel: Linux 4.3.0-1-686-pae (SMP w/2 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 libccaudio2-dev depends on:
ii  libc6   2.21-7
ii  libccaudio2-2   2.1.3-1.1+b2
ii  libgcc1 1:5.3.1-7
ii  libgnutls30 3.4.8-3
ii  libgsm1 1.0.13-4
ii  libspeex1   1.2~rc1.2-1
ii  libstdc++6  5.3.1-7
ii  libucommon-dev  6.4.4-2
ii  libucommon7v5   6.4.4-2
ii  pkg-config  0.29-3

libccaudio2-dev recommends no packages.

libccaudio2-dev suggests no packages.

-- no debconf information


Bug#813630: [libphonenumber6-dev] Missing 'template_util.h' from "base/memory/scoped_ptr.h"

2016-02-03 Thread Leonhard Weber
Package: libphonenumber6-dev
Version: 6.3~svn698-3+b1
Severity: normal

Hi,

when attempting to compile against libphonenumber6-dev headers it fails:

In file included from /usr/include/phonenumbers/asyoutypeformatter.h:40:
/usr/include/phonenumbers/base/memory/scoped_ptr.h:25:10: fatal error:
'phonenumbers/base/template_util.h' file not found
#include "phonenumbers/base/template_util.h"
 ^
1 error generated.

Looks like it is missing from the contents of libphonenumber6-dev:
$> dpkg -L libphonenumber6-dev
/.
/usr
/usr/lib
/usr/lib/x86_64-linux-gnu
/usr/lib/x86_64-linux-gnu/libgeocoding.a
/usr/lib/x86_64-linux-gnu/libphonenumber.a
/usr/include
/usr/include/phonenumbers
/usr/include/phonenumbers/asyoutypeformatter.h
/usr/include/phonenumbers/base
/usr/include/phonenumbers/base/synchronization
/usr/include/phonenumbers/base/synchronization/lock.h
/usr/include/phonenumbers/base/memory
/usr/include/phonenumbers/base/memory/singleton.h
/usr/include/phonenumbers/base/memory/scoped_ptr.h
/usr/include/phonenumbers/base/basictypes.h
/usr/include/phonenumbers/geocoding
/usr/include/phonenumbers/geocoding/phonenumber_offline_geocoder.h
/usr/include/phonenumbers/phonenumbermatcher.h
/usr/include/phonenumbers/phonenumbermatch.h
/usr/include/phonenumbers/utf
/usr/include/phonenumbers/utf/unicodetext.h
/usr/include/phonenumbers/unicodestring.h
/usr/include/phonenumbers/shortnumberutil.h
/usr/include/phonenumbers/shortnumberinfo.h
/usr/include/phonenumbers/regexp_cache.h
/usr/include/phonenumbers/regexp_adapter.h
/usr/include/phonenumbers/phonenumberutil.h
/usr/include/phonenumbers/phonemetadata.pb.h
/usr/include/phonenumbers/phonenumber.pb.h
/usr/include/phonenumbers/logger.h
/usr/include/phonenumbers/callback.h
/usr/share
/usr/share/doc
/usr/share/doc/libphonenumber6-dev
/usr/share/doc/libphonenumber6-dev/changelog.Debian.gz
/usr/share/doc/libphonenumber6-dev/changelog.Debian.amd64.gz
/usr/share/doc/libphonenumber6-dev/copyright
/usr/share/doc/libphonenumber6-dev/CONTRIBUTORS
/usr/share/doc/libphonenumber6-dev/AUTHORS
/usr/lib/x86_64-linux-gnu/libphonenumber.so
/usr/lib/x86_64-linux-gnu/libgeocoding.so

There is no telling if there are more missing, this is maybe the first
of missing headers, could be more, did not probe further.

At the state of affairs, libphonenumber7(-dev) breaks a debian stable +
bpo's installation because of the dependency on newer libc(++?). So no
temporary workaround there. Did not try backports either because of the
huge pull on the Java realm.

Thank you very much for the packaging of this library in the first place.
I'd very much appreciate any help that can be provided.

Its my first bugreport, so please go easy on me ;). Maybe I'm just
overlooking something?.

Best Regards,
Leonhard Weber

--- System information. ---
Architecture: amd64
Kernel: Linux 4.3.0-0.bpo.1-amd64
Debian Release: 8.3




signature.asc
Description: OpenPGP digital signature


Bug#813631: Pending fixes for bugs in the libdatetime-timezone-perl package

2016-02-03 Thread pkg-perl-maintainers
tag 813631 + pending
thanks

Some bugs in the libdatetime-timezone-perl package are closed in
revision aa8ee0c81ddd01abc7583abe6d906643c1288de0 in branch 'master'
by gregor herrmann

The full diff can be seen at
https://anonscm.debian.org/cgit/pkg-perl/packages/libdatetime-timezone-perl.git/commit/?id=aa8ee0c

Commit message:

Fix spelling of Chita in the previous changelog entry.

Thanks: Stepan Golosunov for the bug report.
Closes: #813631



Bug#813631: libdatetime-timezone-perl: Chita is misspelled in the changelog

2016-02-03 Thread gregor herrmann
Control: found -1 1:1.75-2+2016a

On Thu, 04 Feb 2016 00:43:08 +0400, Stepan Golosunov wrote:

> Package: libdatetime-timezone-perl
> Version: 1:1.95-1+2016a
> Severity: minor
> 
> Chita is misspelled in the changelog:
> 
> >* Import upstream version 1.95.
> >  Based on version 2016a of the Olson database. This release includes
> >  contemporary changes for the Cayman Islands, Iran, and Chrita, Russia.

Thanks for the bug report, and sorry for the mistake, I copied this
from the upstream Changes file.
 
> (Looks like 1:1.75-2+2016a is affected too.)

Right. Both fixed in git, will be in the next upload.

Cheers,
gregor

-- 
 .''`.  Homepage https://info.comodo.priv.at/ - OpenPGP key 0xBB3A68018649AA06
 : :' : Debian GNU/Linux user, admin, and developer -  https://www.debian.org/
 `. `'  Member of VIBE!AT & SPI, fellow of the Free Software Foundation Europe
   `-   NP: John Zorn: Ravayah (Sparks)


signature.asc
Description: Digital Signature


Bug#813406: [Pkg-samba-maint] Bug#813406: ctdb, raw sockets and CVE-2015-8543

2016-02-03 Thread Adi Kriegisch
Hi!

> There are two set of patches:
> - yours that basically keep the same behavior as pre-CVE-2015-8543 (proto=0)
I just desperately tried to get my cluster going again... ;-)

> - Amitay's that restore the intented behavior (proto=255)
[...] 
> I think I'll got for Amitay's patch which probably fixes a lot of
> weird behaviors I've seen pre-CVE-2015-8543 (i.e TCP connections not
> reset, Ip not properly relocated).
This is -- of course -- the way better approach!

> I plan to fix this for wheezy and jessie. stretch will come with next
> upstream release.
> 
> Givent the importance of the bug, I think it can go thru -security.
I think so too -- especially as it is some kind of regression.

Thank you very much for taking care of this!

-- Adi


signature.asc
Description: Digital signature


Bug#813635: freeipmi: New version available upstream: 1.5.1

2016-02-03 Thread Ohm Base
Package: freeipmi
Version: 1.4.11-1
Severity: wishlist

Dear Maintainer,

As per

http://lists.gnu.org/archive/html/freeipmi-announce/2015-12/msg0.html

A new version of FreeIPMI has been released (1.5.1) and is available on the
GNU
project's FTP site.

http://ftp.gnu.org/gnu/freeipmi/freeipmi-1.5.1.tar.gz




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

Kernel: Linux 4.3.0-1-686-pae (SMP w/2 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 freeipmi depends on:
ii  freeipmi-bmc-watchdog  1.4.11-1
ii  freeipmi-common1.4.11-1
ii  freeipmi-ipmidetect1.4.11-1
ii  freeipmi-tools 1.4.11-1

freeipmi recommends no packages.

freeipmi suggests no packages.

-- no debconf information


Bug#813374: general: Menus and window popup does not work after recent upgrade

2016-02-03 Thread Vincent Danjean
Le 03/02/2016 12:31, Thomas Goirand a écrit :
> Vincent,
> 
> This sounds like issues with your window manager, since you mostly
> complain about issues with window placements and dispositions. Just to
> be sure, you're using XFCE, right?

Yes.
But is the WM involved in (the placement of) application menus ?
If yes, xfce seems indeed a good target.

  Regards,
Vincent

> Cheers,
> 
> Thomas Goirand (zigo)
> 


-- 
Vincent Danjean   GPG key ID 0xD17897FA vdanj...@debian.org
GPG key fingerprint: 621E 3509 654D D77C 43F5  CA4A F6AE F2AF D178 97FA
Unofficial pkgs: http://moais.imag.fr/membres/vincent.danjean/deb.html
APT repo:  deb http://people.debian.org/~vdanjean/debian unstable main



Bug#813619: closed by Michael Biebl <bi...@debian.org> (Re: Bug#813619: libgdata: aptitude build-dep libgdata19 fails to install libuhttpmock-dev)

2016-02-03 Thread Karl O. Pinc
On Wed, 03 Feb 2016 19:54:05 +
ow...@bugs.debian.org (Debian Bug Tracking System) wrote:

> It has been closed by Michael Biebl .

> -- 
> 813619: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=813619
> Debian Bug Tracking System
> Contact ow...@bugs.debian.org with problems


Karl 
Free Software:  "You don't pay back, you pay forward."
 -- Robert A. Heinlein



Bug#813631: libdatetime-timezone-perl: Chita is misspelled in the changelog

2016-02-03 Thread Stepan Golosunov
Package: libdatetime-timezone-perl
Version: 1:1.95-1+2016a
Severity: minor

Chita is misspelled in the changelog:

>* Import upstream version 1.95.
>  Based on version 2016a of the Olson database. This release includes
>  contemporary changes for the Cayman Islands, Iran, and Chrita, Russia.

(Looks like 1:1.75-2+2016a is affected too.)



Bug#813634: RFP: erlang-sd-notify -- Erlang bindings for systemd-notify subsystem

2016-02-03 Thread Heather Ellsworth
Package: wnpp
Severity: wishlist

* Package name: erlang-sd-notify
  Version : 0.9-1
  Upstream Author : Peter Lemenkov 
* URL : https://github.com/lemenkov/erlang-sd_notify.git
* License : MIT
  Programming Lang: Erlang
  Description : Erlang bindings for systemd-notify subsystem

With erlang-sd-notify installed, then packages like rabbitmq-server have access 
to using the type notify. Since some services like rabbitmq take a while to 
completely stop, using type notify becomes relevent to prevent issues when 
stopping and starting rabbimq in a short period of time. Without type notify, 
rabbit can incorrectly report it's status to systemd which can cause problems 
if stopped/started frequesntly. 

I don't believe there is an equivalent package that allows the use of similar 
notifications already in debian.

Note that the original author is Peter Lemenkov. However his branch was forked 
to create https://github.com/Gsantomaggio/erlang-sd_notify.git. Gsantomaggio's 
was forked to create Jan's https://github.com/jan-grant/erlang-sd_notify.git. 
Jan's version has an option to make deb packages.

Thank you for considering this package,
Heather Ellsworth



Bug#813641: multcomp: FTBFS: Error : package 'MASS' required by 'TH.data' could not be found

2016-02-03 Thread Chris Lamb
Source: multcomp
Version: 1.4-2-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,

multcomp fails to build from source in unstable/amd64:

  [..]

  * installing *source* package 'multcomp' ...
  ** package 'multcomp' successfully unpacked and MD5 sums checked
  ** R
  ** data
  *** moving datasets to lazyload DB
  ** demo
  ** inst
  ** preparing package for lazy loading
  Error : package 'MASS' required by 'TH.data' could not be found
  ERROR: lazy loading failed for package 'multcomp'
  * removing 
'/home/lamby/temp/cdt.20160203230629.amdKvAuzFF/multcomp-1.4-2/debian/r-cran-multcomp/usr/lib/R/site-library/multcomp'
  /usr/share/R/debian/r-cran.mk:98: recipe for target 'R_any_arch' failed
  make: *** [R_any_arch] Error 1

  [..]

The full build log is attached.


Regards,

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


multcomp.1.4-2-1.unstable.amd64.log.txt.gz
Description: Binary data


  1   2   3   >