Bug#843129: ncbi-vdb: Use wildcard instead of $(CPU) in install to fix FTBFS on i386

[Logan Rosen]

Package: ncbi-vdb
Version: 2.7.0+dfsg-4
Severity: normal
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu zesty ubuntu-patch

Dear Maintainer,

ncbi-vdb currently fails to build from source on the i386 architecture because 
there's a discrepancy in architecture naming.

In Ubuntu, the attached patch was applied to achieve the following:

  * debian/rules: Use wildcard instead of $(CPU) in install logic. Fixes FTBFS
on i386.

Thanks for considering the patch.

Logan Rosen

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

Kernel: Linux 4.4.0-21-generic (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to en_US.utf8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
diff -Nru ncbi-vdb-2.7.0+dfsg/debian/rules ncbi-vdb-2.7.0+dfsg/debian/rules
--- ncbi-vdb-2.7.0+dfsg/debian/rules	2016-09-01 05:49:14.0 -0400
+++ ncbi-vdb-2.7.0+dfsg/debian/rules	2016-11-04 01:20:41.0 -0400
@@ -58,30 +58,30 @@
 		--multiarch \
 		--devunversioned \
 		--exclude-la \
-		--movedev debian/tmp/usr/$(DEBPKGNAME)/$(OS)/gcc/$(CPU)/dbg/lib/libncbi-ngs-c++.a usr/lib/$(BUILDTYPE) \
-		--movedev debian/tmp/usr/$(DEBPKGNAME)/$(OS)/gcc/$(CPU)/dbg/ilib/libkapp.a usr/lib/$(BUILDTYPE) \
-		--movedev debian/tmp/usr/$(DEBPKGNAME)/$(OS)/gcc/$(CPU)/dbg/ilib/libkapp-norsrc.a usr/lib/$(BUILDTYPE) \
-		--movedev debian/tmp/usr/$(DEBPKGNAME)/$(OS)/gcc/$(CPU)/dbg/ilib/libkff.a usr/lib/$(BUILDTYPE) \
-		--movedev debian/tmp/usr/$(DEBPKGNAME)/$(OS)/gcc/$(CPU)/dbg/ilib/libktst.a usr/lib/$(BUILDTYPE) \
-		--movedev debian/tmp/usr/$(DEBPKGNAME)/$(OS)/gcc/$(CPU)/dbg/ilib/libkxfs.a usr/lib/$(BUILDTYPE) \
-		--movedev debian/tmp/usr/$(DEBPKGNAME)/$(OS)/gcc/$(CPU)/dbg/ilib/libkxml.a usr/lib/$(BUILDTYPE) \
---movedev debian/tmp/usr/$(DEBPKGNAME)/$(OS)/gcc/$(CPU)/dbg/ilib/libload.a usr/lib/$(BUILDTYPE) \
-		--movedev debian/tmp/usr/$(DEBPKGNAME)/$(OS)/gcc/$(CPU)/dbg/ilib/libtui.a usr/lib/$(BUILDTYPE) \
---movedev debian/tmp/usr/$(DEBPKGNAME)/$(OS)/gcc/$(CPU)/dbg/ilib/libtui_cpp.a usr/lib/$(BUILDTYPE) \
+		--movedev debian/tmp/usr/$(DEBPKGNAME)/$(OS)/gcc/*/dbg/lib/libncbi-ngs-c++.a usr/lib/$(BUILDTYPE) \
+		--movedev debian/tmp/usr/$(DEBPKGNAME)/$(OS)/gcc/*/dbg/ilib/libkapp.a usr/lib/$(BUILDTYPE) \
+		--movedev debian/tmp/usr/$(DEBPKGNAME)/$(OS)/gcc/*/dbg/ilib/libkapp-norsrc.a usr/lib/$(BUILDTYPE) \
+		--movedev debian/tmp/usr/$(DEBPKGNAME)/$(OS)/gcc/*/dbg/ilib/libkff.a usr/lib/$(BUILDTYPE) \
+		--movedev debian/tmp/usr/$(DEBPKGNAME)/$(OS)/gcc/*/dbg/ilib/libktst.a usr/lib/$(BUILDTYPE) \
+		--movedev debian/tmp/usr/$(DEBPKGNAME)/$(OS)/gcc/*/dbg/ilib/libkxfs.a usr/lib/$(BUILDTYPE) \
+		--movedev debian/tmp/usr/$(DEBPKGNAME)/$(OS)/gcc/*/dbg/ilib/libkxml.a usr/lib/$(BUILDTYPE) \
+--movedev debian/tmp/usr/$(DEBPKGNAME)/$(OS)/gcc/*/dbg/ilib/libload.a usr/lib/$(BUILDTYPE) \
+		--movedev debian/tmp/usr/$(DEBPKGNAME)/$(OS)/gcc/*/dbg/ilib/libtui.a usr/lib/$(BUILDTYPE) \
+--movedev debian/tmp/usr/$(DEBPKGNAME)/$(OS)/gcc/*/dbg/ilib/libtui_cpp.a usr/lib/$(BUILDTYPE) \
 		--movedev interfaces usr/include \
-		debian/tmp/usr/$(DEBPKGNAME)/$(OS)/gcc/$(CPU)/dbg/lib/libncbi-vdb.so
+		debian/tmp/usr/$(DEBPKGNAME)/$(OS)/gcc/*/dbg/lib/libncbi-vdb.so
 	mv debian/libncbi-vdb-dev/usr/include/interfaces debian/libncbi-vdb-dev/usr/include/$(DEBPKGNAME)
 	d-shlibmove --commit \
 		--multiarch \
 		--devunversioned \
 		--exclude-la \
 		--override s/libhdf5_serial[0-9]*-dev/libhdf5-dev/ \
-		debian/tmp/usr/$(DEBPKGNAME)/$(OS)/gcc/$(CPU)/dbg/lib/libkdf5.so
+		debian/tmp/usr/$(DEBPKGNAME)/$(OS)/gcc/*/dbg/lib/libkdf5.so
 	d-shlibmove --commit \
 		--multiarch \
 		--devunversioned \
 		--exclude-la \
-		debian/tmp/usr/$(DEBPKGNAME)/$(OS)/gcc/$(CPU)/dbg/lib/libncbi-wvdb.so
+		debian/tmp/usr/$(DEBPKGNAME)/$(OS)/gcc/*/dbg/lib/libncbi-wvdb.so
 	find debian/lib* -name .gitignore -delete
 	# move schemata from development packages to library packages since these are used in executables
 	mkdir -p $(SCHEMADIR)

Bug#842681: mediawiki: upgraded wiki (from squeeze) fails due to missing PSR-3

[Kunal Mehta]

On 11/01/2016 04:24 AM, Jonathan Dowland wrote:
> Some more info: it's an sqlite-backended mediawiki, I'm not sure how it was
> originally set up but it exists in a user's home directory with a lot of
> symlinks into /usr/share/mediawiki. (was this a recommended way of deploying
> mediawiki on Debian? I'm not sure, I didn't originally set this up.) I suppose
> there may be some necessary symlinks for the newer package version that are 
> not
> present yet.  We use lighttpd as the HTTPD with php-cgi via FastCGI.

Okay...that's a bit weird. Where is the webserver root for the wiki
then? Is the vendor directory present there? If symlinks are set up
manually I'm going to guess not, since vendor was introduced recently.
(basically every directory in the second line of
,
I think serialized is new as well, though it's only required when
logging in IIRC).

In general, I would recommend spending some time getting your wiki out
of a user's home directory and using the normal filesystem layout the
package sets up (documented at
), it
will make things a lot easier.

-- Kunal



signature.asc
Description: OpenPGP digital signature

Bug#843127: notmuch: race condition in `notmuch new`?

[Paul Wise]

Package: notmuch
Version: 0.23.1-1
Severity: normal

Last night I got this error from my `notmuch new --quiet` cron job. The
file that the error message complains about is now in the cur directory
of the maildir at the following path.

/path/to/mail/cur/1478190211.H80553P18378.chianamo:2,

I wonder if this some kind of race condition in `notmuch new` processing.
Perhaps it should be using inotify to find out about file movements?

Unexpected error with file /path/to/mail/new/1478190211.H80553P18378.chianamo
add_file: Something went wrong trying to read or write a file
Error opening /path/to/mail/new/1478190211.H80553P18378.chianamo: No such file 
or directory
Note: A fatal error was encountered: Something went wrong trying to read or 
write a file

-- System Information:
Debian Release: stretch/sid
  APT prefers testing-debug
  APT policy: (900, 'testing-debug'), (900, 'testing'), (800, 
'unstable-debug'), (800, 'unstable'), (790, 'buildd-unstable'), (700, 
'experimental-debug'), (700, 'experimental'), (690, 'buildd-experimental')
Architecture: amd64 (x86_64)

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

Versions of packages notmuch depends on:
ii  libc6   2.24-5
ii  libglib2.0-02.50.1-1
ii  libgmime-2.6-0  2.6.20-8
ii  libnotmuch4 0.23.1-1
ii  libtalloc2  2.1.8-1
ii  zlib1g  1:1.2.8.dfsg-2+b3

Versions of packages notmuch recommends:
ii  alot   0.3.6-1
ii  gnupg-agent2.1.15-4
pn  gpgsm  
ii  notmuch-emacs  0.23.1-1
ii  notmuch-mutt   0.23.1-1

notmuch suggests no packages.

-- no debconf information

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#824742: dpkg: Please add arm64ilp32 to cputable

[Guillem Jover]

Control: tags -1 moreinfo

On Thu, 2016-05-19 at 12:06:58 +0100, Wookey wrote:
> Package: dpkg
> Version: 1.18.7
> Severity: wishlist

> There is a new ABI for arm64 which is the equivalent of x32 on amd64.
> It uses the armv8 instruction set for a 32-bit ABI (32-bit
> instructions, longs and pointers). Generally referred-to is 'ILP32' in
> comparison to the 'LP64' standard arm64 ABI.
> 
> This is only expected to be used in quite rare circumstances, but we
> do want to make it possible to build in a debian or debian-derived
> context, which needs dpkg support.

As I mentioned on IRC at the time, I see several problems here:

> Attached is a patch to provide that. It also add existing arm64
> big-endian so that people can 'easily' build that too if need be.
> 
> diff -Nru dpkg-1.18.1/cputable dpkg-1.18.1+nmu1/cputable
> --- dpkg-1.18.1/cputable  2015-05-22 01:17:44.0 +0100
> +++ dpkg-1.18.1+nmu1/cputable 2015-06-18 02:12:22.0 +0100
> @@ -21,6 +21,8 @@
>  armebarmeb   arm.*b  32  big
>  arm  arm arm.*   32  little
>  arm64aarch64 aarch64 64  little
> +arm64be  aarch64_be  aarch64_be  64  big
> +arm64ilp32   aarch64 aarch64_ilp32   32  little
> +arm64ilp32be aarch64_be  aarch64_be_ilp3232  big
>  avr32avr32   avr32   32  big
>  hppa hppahppa.*  32  big
>  m32r m32rm32r32  big

The convention for endianness disambiguation has been «el» or «eb»,
I'd appreciate consistency here. I also updated the FAQ to clarify
this at the time.


Then there's the ossue with the ilp32 stuff. First you are usig the
same name as the normal arm64 architectures, which in a way makes
sense because this is simply part of the ABI. But then this means to
me the upstream name is wrong, and it should not be encoded in the CPU
name but in the ABI name. Which we also covered on IRC.

In any case, marking as moreinfo, until these are clarified and/or
fixed.

Thanks,
Guillem

Bug#841341: closed by Paulo Henrique de Lima Santana (phls) <p...@softwarelivre.org> (Bug#841341: fixed in bd 1.01-2)

[Vigneshwaran]

Hi Paulo,

I have accepted the pull request and released version v1.02

Link: https://github.com/vigneshwaranr/bd/releases/tag/v1.02

Please let me know if you need anything else.

Thank you,
Vigneshwaran

2016-11-04 2:03 GMT+08:00 Paulo Henrique de Lima Santana <
p...@softwarelivre.org>:

> Hi Gerardo,
>
> - Mensagem original -
> > De: "Gerardo Martín Chaves" 
> > Para: 841...@bugs.debian.org, p...@softwarelivre.org,
> eribe...@debian.org
> > Enviadas: Quinta-feira, 3 de novembro de 2016 15:41:29
> > Assunto: Bug#841341: closed by Paulo Henrique de Lima Santana (phls) <
> p...@softwarelivre.org> (Bug#841341: fixed in bd
> > 1.01-2)
>
> > Paulo, the current fix just add bash as a dependency, but the problem
> > persist.
> >
> > IMO the proper fix should be change the shebang to /bin/bash as bd is a
> > bash script.
> >
> > I submit a pull request to upstream to change it (
> > https://github.com/vigneshwaranr/bd/pull/31)
>
> It's clear to me now how to solve this.
> I'm copying Vigneshwaran to accept your pull request and I will can update
> the package.
>
> Best regards,
>
> --
> Paulo Henrique de Lima Santana (phls)
> Membro da Comunidade Curitiba Livre
> Fone: +55 (41) 9198-1897
> Site: http://www.phls.com.br
> GNU/Linux user: 228719  GPG ID: 0443C450
>
> Apoie a campanha pela igualdade de gênero #HeForShe (#ElesPorElas)
> http://www.heforshe.org/pt
>

Bug#816346: dpkg-dev: dpkg-shlibdeps should recognize both host and target objects

[Guillem Jover]

Control: tag -1 moreinfo

Hi!

On Tue, 2016-03-01 at 02:00:16 +0100, Samuel Thibault wrote:
> Package: dpkg-dev
> Version: 1.18.4
> Severity: normal

> When building a cross-compiler, this is however not working. The
> cross-compiler itself is fine (since it's host), but the cross-compiler
> package also ships a few *target* objects, and for them one would have
> to use something like
> 
> debarch_to_gnutriplet(get_target_arch()).'-objdump';
> 
> That however doesn't seem to exist in libdpkg-perl yet. Also, dpkg-shlibdeps
> will probably need to try both, because it can't know which objects are
> for the host or for the target.
> 
> Otherwise, we for instance get this while building a cross gcc:
> 
> dpkg-shlibdeps -Tdebian/gcc-5-x86-64-linux-gnu.substvars 
> debian/gcc-5-x86-64-linux-gnu/usr/bin/x86_64-linux-gnu-gcc-5 
> debian/gcc-5-x86-64-linux-gnu/usr/bin/x86_64-linux-gnu-gcov-5 
> debian/gcc-5-x86-64-linux-gnu/usr/bin/x86_64-linux-gnu-gcov-tool-5 
> debian/gcc-5-x86-64-linux-gnu/usr/bin/x86_64-linux-gnu-gcc-ar-5 
> debian/gcc-5-x86-64-linux-gnu/usr/bin/x86_64-linux-gnu-gcc-ranlib-5 
> debian/gcc-5-x86-64-linux-gnu/usr/bin/x86_64-linux-gnu-gcc-nm-5 
> debian/gcc-5-x86-64-linux-gnu/usr/lib/gcc/x86_64-linux-gnu/5/collect2 
> debian/gcc-5-x86-64-linux-gnu/usr/lib/gcc/x86_64-linux-gnu/5/lto1 
> debian/gcc-5-x86-64-linux-gnu/usr/lib/gcc/x86_64-linux-gnu/5/lto-wrapper 
> debian/gcc-5-x86-64-linux-gnu/usr/lib/gcc/x86_64-linux-gnu/5/plugin/libcc1plugin.so.0.0.0
> /usr/bin/objdump: debian/libgcc1/lib/x86_64-linux-gnu/libgcc_s.so.1: File 
> format not recognized
>
> That happens when the build and host are a 32bit architecture which
> doesn't have multilib support and target is a 64bit architecture, and
> thus its native objdump probably does not understand 64bit binaries.

I'm assuming that this libgcc_s.so.1 (and other) target files are ending
up on a package for the "wrong" architecture compared to what they
really are (say libgcc1_VERSION_HOST.deb instead of
libgcc1_VERSION_TARGET.deb)?

If so, I'd probably say that this is the same problem as with multilib
in general, trying to inject objects into packages that claim to be
for another architecture. And if so, I know this is not going to help
you, but I think trying to support the multilib model is just broken
and requires adding all kinds of hacks and ugly logic to cover what
to me seems to be broken by design.

IMO canadian-cross compilers need to be built so that you end up with
stuff like:

  build == i386
  host == amd64
  target == mips

  compiler-mips_VERSION_amd64.deb
  libsupportN_VERSION_mips.deb

And compiler-mips would end up having a cross-arch dependency on
libsupportN.

Thanks,
Guillem

Bug#843125: ITP: python3-openflow -- low level library to parse OpenFlow messages

[Paulo Henrique de Lima Santana]

Hi Sandro,

This is pointed on requirements.txt file.
But to confirmed, I asked to the upstream and he said it's to python 3.

Best regards,


- Mensagem original -
> De: "Sandro Tosi" 
> Para: "Paulo Henrique de Lima Santana (phls)" , 
> 843...@bugs.debian.org
> Enviadas: Sexta-feira, 4 de novembro de 2016 1:14:51
> Assunto: Bug#843125: ITP: python3-openflow -- low level library to parse 
> OpenFlow messages

> On Thu, Nov 3, 2016 at 11:04 PM, Paulo Henrique de Lima Santana (phls)
>  wrote:
>> * Package name: python3-openflow
>>   Version : 1.1.0~alpha2
>>   Upstream Author : Kytos Development Team 
>> * URL : https://github.com/kytos/python-openflow
>> * License : MIT
>>   Programming Lang: Python
>>   Description : low level library to parse OpenFlow messages
> 
> the module appears to support also python 2, if so please do package
> also a python2 module for debian. thanks
> 
> --
> Sandro "morph" Tosi
> My website: http://sandrotosi.me/
> Me at Debian: http://wiki.debian.org/SandroTosi
> G+: https://plus.google.com/u/0/+SandroTosi

-- 
Paulo Henrique de Lima Santana (phls)
Membro da Comunidade Curitiba Livre
Fone: +55 (41) 9198-1897
Site: http://www.phls.com.br
GNU/Linux user: 228719  GPG ID: 0443C450

Apoie a campanha pela igualdade de gênero #HeForShe (#ElesPorElas)  
http://www.heforshe.org/pt

Bug#812783: dpkg: Please use ASAN, UBSAN and bindnow on hardened1-linux-amd64

[Guillem Jover]

Hi!

On Mon, 2016-05-23 at 11:45:46 +0100, Steven Chamberlain wrote:
> This may be a silly / obvious question to ask, but:
> do any of the proposed hardening options _really_ change the ABI?

I don't think it's silly at all! I've actually wondered this myself
and asked Bálint in person and at least in #812782, perhaps somewhere
else.

> I think LLVM/Clang's ASan implementation does (for Feature: "symbol size
> changing for global variables" on
> https://github.com/google/sanitizers/wiki/AddressSanitizerClangVsGCC)
> but couldn't confirm if that is the case with GCC (which seems to not
> implement that particular feature, at least).

I think the problem Bálint described with ASAN was something else,
but TBH I cannot remember what was it. In any case I've found the
documentation about the various *SAN very lacking. :( And this specific
part was not covered at all when I looked at the time.

> If there's no ABI change, creation of a new arch and gnuhardened*-*-*
> triplet wouldn't be needed;  hardened packages would be co-installable
> with official ones without using multi-arch;  and perhaps all that is
> needed is a separate archive suite, to achieve what was suggested on
> http://balintreczey.hu/blog/proposing-amd64-hardened-architecture-for-debian/
> 
> (Or, packages in the main archive could enable those hardening options?).

Exactly my thoughts, and what I also told Bálint at the time.

Thanks,
Guillem

Bug#837118: Link Update

[Jamil Said, AdoraDeal LLC]

The URL has been changed to: https://www.adoradeal.com/powerzz 

Jamil

Bug#842879: vserver thread

[積丹尼 Dan Jacobson]

OK see more discussion now in
http://list.linux-vserver.org/archive?mss:7091
http://list.linux-vserver.org/archive?iis:7091:201611#b

Bug#812783: dpkg: Please use ASAN, UBSAN and bindnow on hardened1-linux-amd64

[Guillem Jover]

Control: forcemerge 812782 -1

Hi!

On Tue, 2016-01-26 at 15:33:40 +0100, Balint Reczey wrote:
> Package: dpkg
> Version: 1.18.4
> Severity: wishlist
> Tags: patch
> User: bal...@balintreczey.hu
> Usertags: hardened1-linux-amd64

> This is the second patch enabling extra flags in dpkg in case the
> hardened1-linux-amd64 port is accepted in #812782.

I'm merging these two bugs, because they are really the same request,
and the defining trait of this new arch (if it ever materializes) are
the haredening settings, which should be enabled (or not) at the time
the port is defined and added to dpkg.

Thanks,
Guillem

Bug#837120: Link update

[Jamil Said, AdoraDeal LLC]

The URL has been updated to: https://www.adoradeal.com/upshutzz 

Jamil

Bug#840308: dpkg: extraction of additional orig archives into nested subdirectory

[Guillem Jover]

Control: tags -1 moreinfo

Hi!

On Mon, 2016-10-10 at 14:53:40 +0200, Simon Richter wrote:
> Package: dpkg
> Version: 1.18.10
> Severity: wishlist

> I have several packages that use additional .orig archives for program
> modules, but these are almost always expected in a nested subdirectory for
> the package build, e.g. "modules/foo". It would be nice if there was a way
> to ship this as a separate archive instead of repacking the source.

As I asked on IRC at the time, why is creating symlinks on the
expected locations to the base directories not good enough?

Adding support for this seems to me would be a very special case,
would require to specify this somewhere, and you might as well just
add that as part of the debian/rules already. So I'm kind of failing
a bit to see the need for this.

If there's no convincing arguments put forward I'll probably be
closing this request in a bit.

Thanks,
Guillem

Bug#783270: shorewall: Triggers deprecation warning for automatic helper assignment

[Roberto C . Sánchez]

On Tue, Jul 12, 2016 at 09:24:26PM +0200, Dominic Hargreaves wrote:
> On Sat, Jul 02, 2016 at 03:42:54PM -0400, Roberto C. Sánchez wrote:
> > On Fri, Apr 24, 2015 at 10:33:11PM +0100, Dominic Hargreaves wrote:
> > > Package: shorewall
> > > Version: 4.6.4.3-2
> > > Severity: normal
> > > 
> > > [note: I originally sent this on Tuesday but it doesn't seem to have
> > > made it to the BTS; apologies if this somehow becomes a duplicate.]
> > > 
> > > When shorewall loads its rules it triggers the following kernel warning:
> > > 
> > > [  112.699592] nf_conntrack: automatic helper assignment is deprecated 
> > > and it will be removed soon. Use the iptables CT target to attach helpers 
> > > instead.
> > > 
> > > There are no odd rules relating to connection tracking in the shorewall
> > > config.
> > > 
> > Hi Dominic,
> > 
> > I cannot seem to reproduce this behavior with the information you
> > provided.  Could you confirm that you can stil reproduce this and
> > perhaps provide your /etc/shorewall directory as a tarball?  Feel free
> > to email it to me directly if you don't want to post it in a reply to
> > the bug report.
> 
> The problem still occurs on systems with a minimimal config - but I don't
> have a tarball to hand. The systems are jessie, so perhaps the issue is
> fixed in sid (maybe even with a sid kernel the original version of
> shorewall?)
> 
Hi Dominic,

Do you have libnetfilter-cthelper0 installed?  If not, does installing
it cause the message to stop appearing?

Regards,

-Roberto

-- 
Roberto C. Sánchez
http://people.connexer.com/~roberto
http://www.connexer.com


signature.asc
Description: Digital signature

Bug#843125: ITP: python3-openflow -- low level library to parse OpenFlow messages

[Sandro Tosi]

On Thu, Nov 3, 2016 at 11:04 PM, Paulo Henrique de Lima Santana (phls)
 wrote:
> * Package name: python3-openflow
>   Version : 1.1.0~alpha2
>   Upstream Author : Kytos Development Team 
> * URL : https://github.com/kytos/python-openflow
> * License : MIT
>   Programming Lang: Python
>   Description : low level library to parse OpenFlow messages

the module appears to support also python 2, if so please do package
also a python2 module for debian. thanks

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

Bug#842845: dpkg-dev: please consider doing parallel build (~= -Jauto) by default

[Guillem Jover]

Hi!

On Tue, 2016-11-01 at 18:05:08 +, Simon McVittie wrote:
> Package: dpkg-dev
> Version: 1.18.10
> Severity: wishlist

> I've just reported the FTBFS bug for a slang2 upload that failed on all
> buildds due to a non-parallel-safe upstream build system. It appears that
> all our official buildds build with DEB_BUILD_OPTIONS=parallel=n for n >= 2,
> so any Architecture: any package that fails when built like that is de
> facto RC-buggy already.
> 
> It occurs to me that if dpkg-buildpackage defaulted to a parallel build
> on hardware with multiple cores, then in practice maintainers would never
> upload packages with this failure mode, because in practice maintainers
> are using PCs with two or more cores. Also, test builds and final-upload
> builds by maintainers who do not yet know about the -J option would go
> faster, saving them time.
>
> Unlike -jauto, -Jauto respects "dh --no-parallel", making it relatively safe
> to use everywhere - particularly since our buildds are already using
> DEB_BUILD_OPTIONS=parallel=n anyway.

Ah, nice suggestion. And the main issue that came to my mind when I
read the Subject gets neutralized if the buildds are already doing
this! I'm enabling this for 1.18.11.

> The one difference that I would advocate in a default behaviour (and
> perhaps for -Jauto itself) is that according to its documentation,
> -Jauto falls back to an unlimited number of threads (make -j) if the
> number of CPU cores cannot be determined. For memory-hungry compilations,
> particularly C++, this causes everything to grind to a halt or even get
> hit with the OOM killer. It seems to me that using some arbitrary number
> of threads, perhaps the equivalent of -J2 or -J4, might be a better
> fallback behaviour if the number of cores cannot be determined.

Hmm perhaps this should be done indeed. Maybe even to 1. Although this
should only happen on systems were neither «getconf _NPROCESSORS_ONLN»
nor «getconf _NPROC_ONLN» return a value, which should not happen on most
Unix systems.

Thanks,
Guillem

Bug#843126: RFS: freight/0.3.9-2 [ITP] -- easy-to-understand shell scripts to handle APT repositories

[Nicolas Braud-Santoni]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

I am looking for a sponsor for my package "freight":

* Package name: freight
  Version : 0.3.9
  Upstream Author : The Freight Team
* URL : https://github.com/freight-team/freight#freight
* License : BSD-2-clause
* Section : utils
  Programming Lang: SH
  Description : easy-to-understand shell script to handle APT repositories
 freight is an easy-to-use and to understand shell script for
 building packages and keeping them in an up-to-date and signed
 reporitory.
 .
 freight can be compared, in terms of scope and features,
 to reprepro(1), but is simpler to setup and maintain.

I am adopting the source package from my friend Christian Pointner,
with the intent to maintain it inside Debian.


The source and binary (Architecture: all) packages are available here:

  https://nicolas.braud-santoni.eu/tmp/deb

I also uploaded it to mentors.d.n, but it doesn't seem to be visible
there yet.


Best,

  nicoo


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

Kernel: Linux 4.6.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)

Bug#843125: ITP: python3-openflow -- low level library to parse OpenFlow messages

[Paulo Henrique de Lima Santana (phls)]

Package: wnpp
Severity: wishlist
Owner: "Paulo Henrique de Lima Santana (phls)" 

* Package name: python3-openflow
  Version : 1.1.0~alpha2
  Upstream Author : Kytos Development Team 
* URL : https://github.com/kytos/python-openflow
* License : MIT
  Programming Lang: Python
  Description : low level library to parse OpenFlow messages

 If you want to read an OpenFlow packet from an open socket or send a message
 to an OpenFlow switch, this is your best friend. The main features are:
 high performance, latest specification compliance, short learning curve and
 free software license.
 .
 This library is part of Kytos project, a collaborative project between
 SPRACE (from São Paulo State University, Unesp) and Caltech (California
 Institute of Technology). python-openflow was developed to be used with
 Kytos controller, but feel free to use this simple and intuitive library
 in another project with another controller.

Bug#843124: ITP: r-cran-viridis -- GNU R package with color maps from matplotlib

[Dirk Eddelbuettel]

Package: wnpp
Owner: Dirk Eddelbuettel 
Severity: wishlist

* Package name: r-cran-viridis
  Version : 0.3.4-1
  Upstream Author : Simon Garnier 
* URL or Web page : https://cran.r-project.org/package=viridis
* License : MIT
  Description : GNU R package with color maps from matplotlib

This is a new dependency of the existing package r-cran-hmisc.

Dirk

-- 
http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

Bug#843104: firefox: gtk3 makes fonts tiny on hi-dpi display

[Jeff King]

On Thu, Nov 03, 2016 at 04:31:54PM -0400, Jeff King wrote:

> Since the move to GTK3 in 49.0-5, the fonts and widgets on my hi-dpi
> (3840x2160, 240dpi) display are tiny. The actual rendered content is
> sized as it was with GTK2.

A few other data points:

 - the rendered content is sized appropriately with GTK3 only because
   I had previously set layout.css.devPixelsPerPx to "2". Setting it
   back to the default of "-1.0" makes the rendered content small with
   GTK3.

 - Setting the font size in .config/gtk-3.0/settings.ini like:

 [Settings]
 gtk-font-name=Sans 24

   helps quite a bit, but is just working around the issue (the
   resulting size is closer to what "Sans 10" looks like in an XTerm,
   not 24pt).

 - Using a large font _without_ setting devPixelsPerPx looks quite bad,
   as the tab titles do not fit inside the tabs themselves.

So I _think_ the root cause of all of this is that GTK3 for whatever
reason is not getting an accurate DPI for my system. Possibly because
I'm not running GNOME or any modern desktop environment (I'm using
AwesomeWM, FWIW).

With the two tweaks (an oversized font setting, and devPixelsPerPx)
things seem usable, but those really feel like workarounds.

-Peff

Bug#843105: firefox: gtk3 causes extension popups to have odd size/placement

[Jeff King]

On Thu, Nov 03, 2016 at 04:42:16PM -0400, Jeff King wrote:

> Given that this worked in 49.0-4 and has to do with window creation, I
> can guess it's related to the switch to gtk3.

After some experimenting, this actually looks like it's related to
setting GDK_SCALE=2 in the environment. Unsetting that makes the problem
go away (but makes widgets and fonts tiny with gtk3, as described in
#843104).

-Peff

Bug#843122: Minor fix for apt-file man page

[Potter, Tim (HPE Linux Support)]

Source: apt-file
Severity: wishlist
Tags: patch

Hi there. I found a small typo in the manual page for apt-file.  Patch is 
attached.


Thanks,

Tim.



apt-file-manpage.patch
Description: Binary data


signature.asc
Description: Message signed with OpenPGP using GPGMail

Bug#843123: ITP: r-cran-htmltable -- GNU R package for advanced html tables

[Dirk Eddelbuettel]

Package: wnpp
Owner: Dirk Eddelbuettel 
Severity: wishlist

* Package name: r-cran-htmltable
  Version : 1.7-1
  Upstream Author : Max Gordon
* URL or Web page : https://cran.r-project.org/package=htmlTable
* License : GPL-3
  Description : GNU R package for advanced html tables

This is a new dependency of the existing package r-cran-hmisc.

Dirk

-- 
http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

Bug#138409: dpkg-dev: please add support for .buildinfo files

[Guillem Jover]

Hi!

On Thu, 2016-11-03 at 11:01:28 +, Chris Lamb wrote:
> > Control: tag 138409 pending
> 
> Firstly, this is really great to see; thanks to you (and everyone else)
> for your work on this.

No problem, it took probably longer than it should have though. :/

> This is just a quick message to query whether the applied patch fixes
> the "duplicate Installed-Build-Depends" issue that I raised a week or
> so ago?

I should have fixed this in principle, but out of code staring, I
didn't try to reproduce it.

> If not, am very happy to file a bug so it gets captured. No point
> uploading with known issues, after all.

If you notice this is still a problem, please do file a bug!

Thanks,
Guillem

Bug#843121: RFS: ifmetric/0.3-4

[Michael Shuler]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I would appreciate a sponsor for this maintenance upload of ifmetric.
This release updates the packaging standards to be current for Stretch.

  * Package name: ifmetric
Version : 0.3-4
Upstream Author : Lennart Poettering 
  * URL : http://0pointer.de/lennart/projects/ifmetric/
  * License : GPL-2+
Section : net

It builds those binary packages:

  ifmetric - Set routing metrics for a network interface

To access further information about this package, please visit the
following URL:

  https://mentors.debian.net/package/ifmetric

Alternatively, one can download the package with dget using this command:

  dget -x
https://mentors.debian.net/debian/pool/main/i/ifmetric/ifmetric_0.3-4.dsc

Changes since the last upload:

ifmetric (0.3-4) unstable; urgency=low

  * debian/control:
Set Architecture: linux-any to exclude kfreebsd/hurd builds.
Update to Standards-Version: 3.9.8.
Update Vcs-Browser/Vcs-Git: https URLs.
  * debian/copyright:
Drop recurrent license text for lintian.
  * debian/rules:
Add hardening build flag for all options.
  * debian/patches/ifmetric.8_typo:
Fix typo in man page.

 -- Michael Shuler   Thu, 03 Nov 2016 18:09:20 -0500

Thanks for your time!
-- 
Kind regards,
Michael



signature.asc
Description: OpenPGP digital signature

Bug#842952: firefox: Things that are still bad with GTK+3 enabled

[Jeff King]

On Thu, Nov 03, 2016 at 09:18:15PM -0400, Matthew Gabeler-Lee wrote:

> I do run GNOME, and it works fine on my HiDPI screen there.
> 
> Do you have some value set for layout.css.devPixelsPerPx, or is it the
> default -1?

I do have it set, though restoring it to "-1.0" does not change anything
with the widgets (it just makes the rendered content look really tiny,
too). Interestingly, GTK2 sizes things reasonably even with "-1.0" (many
versions back I set it manually, but apparently that is no longer
necessary). So it seems like GTK2 figures out the DPI issues
automatically, but GTK3 does not.

> > I don't run GNOME, but I do have "dconf" installed. Tweaking
> > "/org/gnome/desktop/interface/scaling-factor" (and text-scaling-factor)
> > has no effect.
> 
> In my GNOME environment, the first is 0 and the second is 1, and yet I get
> proper sized stuff in HiDPI nonetheless.
> 
> However, the gnome-tweak-tool shows the "Window scaling" as 2.

Thanks for the input. I tried installing gnome-tweak-tool, but changing
the settings had no effect (I imagine this is because I'm not running
some other component, like the compositing window manager, that does the
heavy lifting).

I opened #843104 to to split this issue into its own bug.

-Peff

Bug#842939: WOT found guilty to sell user data

[ilf]

kpcyrd:
I think this project doesn't align with the debian goals and I would 
welcome if it's getting removed from current and future releases.


Mozilla removed it from addons.mozilla.org: 
http://www.faz.net/aktuell/politik/skandal-um-datenschnueffler-mozilla-loescht-web-of-trust-erweiterung-14511304.html


I think Debian should do the same.

--
ilf

Über 80 Millionen Deutsche benutzen keine Konsole. Klick dich nicht weg!
-- Eine Initiative des Bundesamtes für Tastaturbenutzung


signature.asc
Description: PGP signature

Bug#843114: cups-filters: cups changes shared printers with underscores (_) in their names to dashes (-)

[Brian Potkin]

On Thu 03 Nov 2016 at 16:14:18 -0700, Alex Schumann wrote:

> Package: cups-filters
> Version: 1.0.61-5+deb8u3
> Severity: important
> Tags: newcomer
> 
> Dear Maintainer,
> 
> Printers shared from other cups systems with _ in their names appear with the 
> name changed so all underscores '_' become dashes '-'.
> 
> There is a similar bug-report in rhel7 
> (https://bugzilla.redhat.com/show_bug.cgi?id=1230862) solved by an update.
> > Our EL7 clients are using cups-browsed to discover printers shared
> > from our central EL7 cups server.  Most of our queues have underscores
> > in their names, and for some reason cups-browsed is changing the
> > underscores to dashes.  This breaks the queues for our EL7 clients.
> 
> I think this same fix should be applied to jessie. This causes serious 
> breakage when printer names are saved 
> in work processes or applications, or when users move between systems. 
> (wheezy does not have the bug)
> 
>* What led up to the situation?
> 
> Upgraded a server from wheezy to jessie. Printing in our in-house application 
> stopped working.
> Investigation found that the printers in jessie all had the wrong name 
> (ZZ2-office-2844) instead of correct name (ZZ2_office_2844)

   CHANGES IN V1.0.62

- cups-browsed: Allow underscore characters in print queue names.
  Thanks to Tim Waugh from Red Hat for the bug report (Bug
  #1241).

cups-filters and cups-filters-core-drivers (1.0.62-1) from
http://snapshot.debian.org/ will install on Jessie. Tested.

How does that suit?

Regards,

Brian.

Bug#842952: firefox: Things that are still bad with GTK+3 enabled

[Matthew Gabeler-Lee]

On Wed, 2 Nov 2016, Jeff King wrote:


On Wed, Nov 02, 2016 at 11:00:34AM -0400, Matthew Gabeler-Lee wrote:


Some things I've noticed going from 49.0-4 to 49.0-5 that I'm inferring are
related to turning on GTK+3:


One thing I've noticed that you didn't mention: on my hi-dpi display the
widget fonts are tiny after the move to GTK+3 (e.g., address bar, tab
titles, anything not rendered HTML).


I do run GNOME, and it works fine on my HiDPI screen there.

Do you have some value set for layout.css.devPixelsPerPx, or is it the 
default -1?



I don't run GNOME, but I do have "dconf" installed. Tweaking
"/org/gnome/desktop/interface/scaling-factor" (and text-scaling-factor)
has no effect.


In my GNOME environment, the first is 0 and the second is 1, and yet I 
get proper sized stuff in HiDPI nonetheless.


However, the gnome-tweak-tool shows the "Window scaling" as 2.

--
-Matt
"Reality is that which, when you stop believing in it, doesn't go away".
-- Philip K. Dick
GPG fingerprint: 0061 15DF D282 D4A9 57CE  77C5 16AF 1460 4A3C C4E9

Bug#722451: Compiz team/package status.

[Cyril Brulebois]

Control: tag -1 pending

Jean-Philippe MENGUAL  (2016-11-02):
> 1. Compiz in Debian
> 
> Yes, latest Compiz from Canonical will be in Debian 9. Upload is
> coming soon, Hypra paid for a Debian dev to do it. We choosed Compiz
> from Canonical because it's tested and mainstream. We don't use
> Compiz-reloaded (0.8), as so few users, plugins, etc.
> 
> So yes, upload comes very soon (this month).

There we go (see below). Of course it's going to land in NEW, and will
need ftpmasters to review the packaging. Maybe we'll need a few rounds
of uploads, we'll see.

Uploading to ftp-master (via ftp to ftp.upload.debian.org):
  Uploading compiz_0.9.13.0+16.10.20160818.2-1.dsc: done.
  Uploading compiz_0.9.13.0+16.10.20160818.2.orig.tar.gz: done.
  Uploading compiz_0.9.13.0+16.10.20160818.2-1.diff.gz: done.
  Uploading compiz-core-dbgsym_0.9.13.0+16.10.20160818.2-1_amd64.deb: done.
  Uploading compiz-core_0.9.13.0+16.10.20160818.2-1_amd64.deb: done.
  Uploading compiz-dev_0.9.13.0+16.10.20160818.2-1_amd64.deb: done.
  Uploading compiz-gnome-dbgsym_0.9.13.0+16.10.20160818.2-1_amd64.deb: done.
  Uploading compiz-gnome_0.9.13.0+16.10.20160818.2-1_amd64.deb: done.
  Uploading compiz-mate_0.9.13.0+16.10.20160818.2-1_amd64.deb: done.
  Uploading compiz-plugins-dbgsym_0.9.13.0+16.10.20160818.2-1_amd64.deb: done.
  Uploading 
compiz-plugins-default-dbgsym_0.9.13.0+16.10.20160818.2-1_amd64.deb: done.
  Uploading compiz-plugins-default_0.9.13.0+16.10.20160818.2-1_amd64.deb: done.
  Uploading compiz-plugins-extra_0.9.13.0+16.10.20160818.2-1_all.deb: done.
  Uploading compiz-plugins-main-default_0.9.13.0+16.10.20160818.2-1_all.deb: 
done.
  Uploading compiz-plugins-main-dev_0.9.13.0+16.10.20160818.2-1_all.deb: done.
  Uploading compiz-plugins-main_0.9.13.0+16.10.20160818.2-1_all.deb: done.
  Uploading compiz-plugins_0.9.13.0+16.10.20160818.2-1_amd64.deb: done.
  Uploading compiz_0.9.13.0+16.10.20160818.2-1_all.deb: done.
  Uploading compizconfig-settings-manager_0.9.13.0+16.10.20160818.2-1_all.deb: 
done.
  Uploading libcompizconfig0-dbgsym_0.9.13.0+16.10.20160818.2-1_amd64.deb: done.
  Uploading libcompizconfig0-dev_0.9.13.0+16.10.20160818.2-1_amd64.deb: done.
  Uploading libcompizconfig0_0.9.13.0+16.10.20160818.2-1_amd64.deb: done.
  Uploading libdecoration0-dbgsym_0.9.13.0+16.10.20160818.2-1_amd64.deb: done.
  Uploading libdecoration0-dev_0.9.13.0+16.10.20160818.2-1_amd64.deb: done.
  Uploading libdecoration0_0.9.13.0+16.10.20160818.2-1_amd64.deb: done.
  Uploading python-compizconfig-dbgsym_0.9.13.0+16.10.20160818.2-1_amd64.deb: 
done.
  Uploading python-compizconfig_0.9.13.0+16.10.20160818.2-1_amd64.deb: done.
  Uploading compiz_0.9.13.0+16.10.20160818.2-1_amd64.changes: done.
Successfully uploaded packages.


A bit more info:
  https://compiz.alioth.debian.org/


Cheers,
Cyril.
-- 
Cyril Brulebois -- Debian Consultant @ DEBAMAX -- https://debamax.com/


signature.asc
Description: Digital signature

Bug#843120: ITP: freight -- easy-to-understand shell script to handle APT repositories

[Nicolas Braud-Santoni]

Package: wnpp
Severity: wishlist
Owner: Nicolas Braud-Santoni 

* Package name: freight
  Version : 0.3.9
  Upstream Author : The Freight Team
* URL : https://github.com/freight-team/freight#freight
* License : BSD-2-clause
  Programming Lang: SH
  Description : easy-to-understand shell script to handle APT repositories
 freight is an easy-to-use and to understand shell script for
 building packages and keeping them in an up-to-date and signed
 reporitory.
 .
 freight can be compared, in terms of scope and features,
 to reprepro(1), but is simpler to setup and maintain.

I am adopting the source package from my friend Christian Pointner,
with the intent to maintain it inside Debian.

Bug#843119: RFS: wordplay/7.22-18 [QA]

[David Davies-Jones]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "wordplay"

 * Package name: wordplay
   Version : 7.22-18
   Upstream Author : Evans A Criswell 
 * URL :
http://hsvmovies.com/static_subpages/personal_orig/wordplay/index.html
 * License : Custom
   Section : games

It builds those binary packages:

 wordplay   - anagram generator

To access further information about this package, please visit the
following URL:

 https://mentors.debian.net/package/wordplay


Alternatively, one can download the package with dget using this command:

 dget -x 
https://mentors.debian.net/debian/pool/main/w/wordplay/wordplay_7.22-18.dsc

More information about wordplay can be obtained from
ttp://hsvmovies.com/static_subpages/personal_orig/wordplay/index.html.

Changes since the last upload:

  * QA upload.
  * Moved changes previously applied directly to source
to patches
  * Bumped to debhelper 10
  * Set maintainer to Debian QA Group
  * Add patch to include stdlib.h (Closes: #821064)
  * Removed hardcoded compiler
  * Converted debian/copyright to DEP-5
  * Modernise debian/rules file (Closes: #438280)


Regards,
 David William Richmond Jones

Bug#843099: boto package outdated because of authentification encryption "upgrade"

[Charles Plessy]

Le Thu, Nov 03, 2016 at 08:36:10PM +0100, Reiner Keller a écrit :
> 
> I have since months problems using Saltstack provision in a single setup
> run on the Debian AWS images because it delivers only with an outdated
> python-boto package which is sadly actually also the only public
> available version for Jessie:
> 
> Package: python-boto
> Version: 2.34.0-2

Hi Reiner,

it looks like what you need is a "backport" of 2.40.0-1 to Jessie
(https://backports.debian.org/).  Perhaps you can first ask to the package
maintainer if he would like to prepare one and if not, please do not
hesitate to ask here.  If you are familiar with Debian packaging, you
are also welcome to prepare a backport yourself and ask for sponsorship
here.

Note also that version 2.38.0-1 will always be available from our "snaphot"
archive.  Since it is a frozen snapshot, there is no support for it (which
means no correction of security bugs), but provided that you understand the
issues with installing unsupported packages, it still may be useful for your
purposes.  http://snapshot.debian.org/package/python-boto/2.38.0-1/

I hope it helps.

Have a nice day,

Charles

-- 
Charles Plessy
Tsurumi, Kanagawa, Japan

Bug#843118: seabios: Unable to boot KVM guest with "-display none"

[Gregory Auzanneau]

Package: seabios
Version: 1.9.3-2
Severity: normal

Dear Maintainer,

Since the latest update of seabios 1.9.3-2, a guest machine can't start with 
qemu parameter "-display none".
The guest hang immediatly at boot with all vCPU at 100%.

If I revert back to seabios 1.8.2-1, the problem is solved.
If I add a virtual graphic card, the is problem is also solved.

Best regards,
Gregory

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

Kernel: Linux 4.7.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)

-- no debconf information

Bug#840189: fixed in texlive-extra 2016.20161103-1

[Norbert Preining]

> #840189 was the bug in dblatex itself (already closed in October).
> This should have been #840229:

Argg, indeed.

> fixed: the bug title says "dblatex (<< 0.3.9-1~)", but I can see for
> texlive-latex-extra 2016.20161103-1:
> 
> Breaks: dblatex (<< 0.3.8-2~), [...]

Well, when I committed the change it was 0.3.8-2~, and nobody informed
me that there was 0.3.9-1 since then.

The version is still correct, as between the fixed version and 
the version against the package breaks there is no other version
in existence.

So I consider this a bug that should be closed (with the correct
bug number, though ;-)

Don't you agree?

Norbert

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

Bug#842919: transition: xen

[Ian Jackson]

Emilio Pozuelo Monfort writes ("Re: Bug#842919: transition: xen"):
> On 02/11/16 11:47, Ian Jackson wrote:
...
> > All that is needed from the build-rdeps is a rebuild.  That is, of:
> >   libvirt qemu xenwatch python-pyxenstore collectd grub2
> > 
> > I have checked that they all build against the new libxen{-4.8,-dev},
> > at least on amd64.  I don't anticipate trouble on other architectures.
> 
> The ben tracker only lists qemu and libvirt as rdeps of the binaries
> that are removed in the new version. Why do the other packages need
> a rebuild? Do any of them statically link libxen or something?

(Hi.  Thanks for your attention.  I am somewhat full of wine right
now, so my answers may be wrong.  It seemed better to reply sooner.
My work hat can produce more sober replies tomorrow:)

I got the list from "build-rdeps".  Is it wrong ?  It's the list of
things which have libxen-dev as a build-dep.

Hrm.  I looked at xenwatch and python-pyxenstore and though the source
packages Build-Depend on libxen, the binaries Depend only libxenstore
whose ABI version and package name have not changed.  So I think,
then, that there is actually no need to recompile those two, although
it would probably be best to do so as a precaution (in case the ABI
has unwittingly changed, in which case it would be somewhat better for
stretch to be internally consistent).

In my test rebuild, collectd.deb Depends libxen-4.8.  My apt-cache
show thinks that sid's current collectd Depends libxen-4.6.  I'm not
sure why a collectd rebuild would not be needed.

grub2 is more complicated.  I am going to reply separately about that,
CC grub2@p.d.o.

Thanks,
Ian.

-- 
Ian Jackson    These opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Bug#842919: transition: xen (vs. grub2)

[Ian Jackson]

Hi, grub2 maintainers.  I'm CCing you into this conversation in the
hope you can help explain the semantics of the grub2 package's
build-dependency on libxen-dev.

I will quote the whole transition mail:

Emilio Pozuelo Monfort writes ("Re: Bug#842919: transition: xen"):
> On 02/11/16 11:47, Ian Jackson wrote:
> > Package: release.debian.org
> > Severity: normal
> > User: release.debian@packages.debian.org
> > Usertags: transition
> > 
> > Hi.  This is the update from Xen 4.6 to Xen 4.8, as previously
> > discussed.  (Currently, Xen 4.8.0 RC3.  I expect the Xen 4.8.0 release
> > to be out by the time Debian freezes.)
> > 
> > libxen-* contains libraries needed for management tools.   The
> > corresponding xen-utils-* packages are intended to be coinstallable,
> > so perhaps a "smooth" transition may still be possible ?  (Contrary to
> > what the autogenerated transition tracker thinks.)
> > 
> > All that is needed from the build-rdeps is a rebuild.  That is, of:
> >   libvirt qemu xenwatch python-pyxenstore collectd grub2
> > 
> > I have checked that they all build against the new libxen{-4.8,-dev},
> > at least on amd64.  I don't anticipate trouble on other architectures.
> 
> The ben tracker only lists qemu and libvirt as rdeps of the binaries
> that are removed in the new version. Why do the other packages need
> a rebuild? Do any of them statically link libxen or something?

(Emilio will see that I discussed other the packages in another mail.
Also, I am somewhat full of wine right now, so my answers may be
wrong.  It seemed better to reply sooner.  My work hat can produce
more sober replues tomorrow.  Regarding grub2:)

I don't know why grub2 Build-Depends libxen-dev.  None of the binaries
in my test-rebuild end up Depending on libxen-4.8.

Perhaps the B-D is just because it needs a copy of the Xen public
headers for the hypervisor API.  I doubt it statically links against
libxen* libraries, but I don't think I can entirely rule it out.
There is a binary grub-xen-bin which is probably relevant.

grub-xen-bin contains grub compiled for the Xen PV environment: that
is, to run directly under Xen as part of a guest startup.  It will
need header files describing the Xen public ABI.  These are the "Xen
public headers", and because of Xen's ABI compatibility guarantees the
normal upstream recommendation is to actually copy those into the
trees of projects which are building binaries to run on Xen.  (So for
example Linux has its own - modified - copies.)

If this is the only reason why grub2 Build-Depends libxen-dev then
there is no need to rebuild grub2.

It seems unlikely to me that grub2 could somehow statically link
actual libxen-dev library code (and statically embed it into a grub
binary), but perhaps I'm just not being imaginative enough.

And I guess it is possible that grub2 has some other function which
somehow embeds pieces from libxen-dev.

I hope the grub2 maintainers will be able to shed some light.

Thanks,
Ian.

-- 
Ian Jackson    These opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
. 

Bug#843117: lintian does not warn on Essential dependencies

[Nicolas Braud-Santoni]

Package: lintian
Version: 2.5.49
Severity: normal

Dear Maintainer,

According to the Debian Policy, packages should not declare dependencies
on packages tagged Essential:

  https://www.debian.org/doc/debian-policy/ch-binary.html#s-dependencies

However, I noticed that lintian does not warn if, for instance,
one declares a dependency upon dash.


Best,

  nicoo


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

Kernel: Linux 4.6.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)

Versions of packages lintian depends on:
ii  binutils  2.27-9+b1
ii  bzip2 1.0.6-8
ii  diffstat  1.61-1
ii  file  1:5.28-4
ii  gettext   0.19.8.1-1
ii  intltool-debian   0.35.0+20060710.4
ii  libapt-pkg-perl   0.1.30
ii  libarchive-zip-perl   1.59-1
ii  libclass-accessor-perl0.34-1
ii  libclone-perl 0.38-2+b1
ii  libdpkg-perl  1.18.10
ii  libemail-valid-perl   1.202-1
ii  libfile-basedir-perl  0.07-1
ii  libipc-run-perl   0.94-1
ii  liblist-moreutils-perl0.416-1+b1
ii  libparse-debianchangelog-perl 1.2.0-11
ii  libperl5.24 [libdigest-sha-perl]  5.24.1~rc3-3
ii  libtext-levenshtein-perl  0.13-1
ii  libtimedate-perl  2.3000-2
ii  liburi-perl   1.71-1
ii  libyaml-libyaml-perl  0.63-1+b1
ii  man-db2.7.5-1
ii  patchutils0.3.4-1
ii  perl  5.24.1~rc3-3
ii  t1utils   1.39-2
ii  xz-utils  5.2.2-1.2

Versions of packages lintian recommends:
ii  dpkg 1.18.10
pn  libperlio-gzip-perl  
ii  perl 5.24.1~rc3-3
ii  perl-modules-5.24 [libautodie-perl]  5.24.1~rc3-3

Versions of packages lintian suggests:
pn  binutils-multiarch 
ii  dpkg-dev   1.18.10
ii  libhtml-parser-perl3.72-2+b1
ii  libtext-template-perl  1.46-1

-- no debconf information

Bug#840189: fixed in texlive-extra 2016.20161103-1

[Vincent Lefevre]

Control: notfixed 840189 texlive-extra/2016.20161103-1

(wrong bug number, see below)

Hi Norbert,

On 2016-11-03 07:56:07 +, Norbert Preining wrote:
> Source: texlive-extra
> Source-Version: 2016.20161103-1
> 
> We believe that the bug you reported is fixed in the latest version of
> texlive-extra, which is due to be installed in the Debian FTP archive.
[...]
>* break against old dblatex (Closes: #840189)

#840189 was the bug in dblatex itself (already closed in October).
This should have been #840229:

  texlive-latex-extra should Breaks: dblatex (<< 0.3.9-1~)

But before closing this bug, I'm wondering whether it has really been
fixed: the bug title says "dblatex (<< 0.3.9-1~)", but I can see for
texlive-latex-extra 2016.20161103-1:

Breaks: dblatex (<< 0.3.8-2~), [...]

This doesn't match!

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

Bug#843113: better missing kernel headers message

[Ben Hutchings]

Control: reassign -1 dkms

On Fri, 2016-11-04 at 07:37 +0800, 積丹尼 Dan Jacobson wrote:
> Package: src:linux
> Version: 4.8.5-1
> Severity: wishlist
> 
> Setting up linux-image-4.8.0-1-686-pae (4.8.5-1) ...
> I: /vmlinuz.old is now a symlink to boot/vmlinuz-4.7.0-1-686-pae
> I: /initrd.img.old is now a symlink to boot/initrd.img-4.7.0-1-686-pae
> I: /vmlinuz is now a symlink to boot/vmlinuz-4.8.0-1-686-pae
> I: /initrd.img is now a symlink to boot/initrd.img-4.8.0-1-686-pae
> /etc/kernel/postinst.d/dkms:
> Error! Your kernel headers for kernel 4.8.0-1-686-pae cannot be found.
> Please install the linux-headers-4.8.0-1-686-pae package,
> or use the --kernelsourcedir option to tell DKMS where it's located
> 
> 1. That error message is not coming from that file.
[...]

That's the hook script the kernel's postint script is running, that
(indirectly) generates the error message.  The error message *does*
come from dkms.

Ben.

-- 
Ben Hutchings
The world is coming to an end.  Please log off.

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

Bug#843079: Bug#843107: python-mpop: FTBFS: ImportError: No module named trollsift.parser

[Antonio Valentino]

Il 03/11/2016 22:52, Sebastiaan Couwenberg ha scritto:
> severity 843079 serious
> merge 843079 843107
> thanks
> 
> On 11/03/2016 10:30 PM, Chris Lamb wrote:
>> python-mpop fails to build from source in unstable/amd64:
>> [...]
>> File "/usr/lib/python2.7/dist-packages/PIL/Image.py", line 2001, in 
>> _check_size
>>   raise ValueError("Width and Height must be > 0")
> 
> On Thu, 3 Nov 2016 18:44:47 +0100 Matthias Klose wrote:
>> the autopkg tests are failing:
>> [...]
>>   File "/usr/lib/python2.7/dist-packages/PIL/Image.py", line 2001, in
> _check_size
>> raise ValueError("Width and Height must be > 0")
> 
> You can thank yesterdays Pillow 3.4.2 upload for that.
> 
> Antonio, can you have a look at this?
> 
> Kind Regards,
> 
> Bas
> 


New bug opened to upstream:

https://github.com/pytroll/mpop/issues/38

-- 
Antonio Valentino

Bug#843116: avahi-daemon: adequate reports broken sym-link in /if-up.d/avahi-daemon

[shirish शिरीष]

Package: avahi-daemon
Version: 0.6.32-1
Severity: normal

Dear Maintainer,
I got the following -

[$] adequate avahi-daemon

avahi-daemon: broken-symlink /etc/network/if-post-down.d/avahi-daemon
-> ../if-up.d/avahi-daemon

This was easily seen by not seeing the expected file in if-up.d/ directory

┌─[shirish@debian] - [/etc/network/if-up.d] - [2963]
└─[$] ls

00check-network-cable  10check-duplicate-ip  10check-duplicate-ip6
openvpn  wpasupplicant

can this be fixed please one way or the other.

I actually reinstalled the package with the same results. I got to
know of it when using ifdown.

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

Kernel: Linux 4.7.0-1-amd64 (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 avahi-daemon depends on:
ii  adduser  3.115
ii  bind9-host [host]1:9.10.3.dfsg.P4-10.1
ii  dbus 1.10.12-1
ii  host 1:9.10.3.dfsg.P4-10.1
ii  init-system-helpers  1.45
ii  libavahi-common3 0.6.32-1
ii  libavahi-core7   0.6.32-1
ii  libc62.24-5
ii  libcap2  1:2.25-1
ii  libdaemon0   0.14-6
ii  libdbus-1-3  1.10.12-1
ii  libexpat12.2.0-1
ii  lsb-base 9.20161016

Versions of packages avahi-daemon recommends:
ii  libnss-mdns  0.10-7

Versions of packages avahi-daemon suggests:
pn  avahi-autoipd  

-- Configuration Files:
/etc/network/if-up.d/avahi-daemon [Errno 2] No such file or directory:
u'/etc/network/if-up.d/avahi-daemon'

-- no debconf information

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

Bug#843115: add --exclude-directories

[積丹尼 Dan Jacobson]

Package: dlocate
Version: 1.07
Severity: wishlist

We read

   --filename-only
  Only output file names when searching for files

Yes, but add a note:

  "File names here refer to directory names and file names.

   To really only get file names, use an additional
   "--exclude-directories".


which functionality please add.

Bug#843114: cups-filters: cups changes shared printers with underscores (_) in their names to dashes (-)

[Alex Schumann]

Package: cups-filters
Version: 1.0.61-5+deb8u3
Severity: important
Tags: newcomer

Dear Maintainer,

Printers shared from other cups systems with _ in their names appear with the 
name changed so all underscores '_' become dashes '-'.

There is a similar bug-report in rhel7 
(https://bugzilla.redhat.com/show_bug.cgi?id=1230862) solved by an update.
> Our EL7 clients are using cups-browsed to discover printers shared
> from our central EL7 cups server.  Most of our queues have underscores
> in their names, and for some reason cups-browsed is changing the
> underscores to dashes.  This breaks the queues for our EL7 clients.

I think this same fix should be applied to jessie. This causes serious breakage 
when printer names are saved 
in work processes or applications, or when users move between systems. (wheezy 
does not have the bug)

   * What led up to the situation?

Upgraded a server from wheezy to jessie. Printing in our in-house application 
stopped working.
Investigation found that the printers in jessie all had the wrong name 
(ZZ2-office-2844) instead of correct name (ZZ2_office_2844)

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

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

Versions of packages cups-filters depends on:
ii  bc 1.06.95-9
ii  cups-filters-core-drivers  1.0.61-5+deb8u3
ii  ghostscript9.06~dfsg-2+deb8u4
ii  libc6  2.19-18+deb8u6
ii  libcups2   1.7.5-11+deb8u1
ii  libcupsfilters11.0.61-5+deb8u3
ii  libcupsimage2  1.7.5-11+deb8u1
ii  libfontconfig1 2.11.0-6.3+deb8u1
ii  libfontembed1  1.0.61-5+deb8u3
ii  libgcc11:4.9.2-10
ii  libijs-0.350.35-10
ii  liblcms2-2 2.6-3+b3
ii  libpoppler46   0.26.5-2+deb8u1
ii  libqpdf13  5.1.2-2
ii  libstdc++6 4.9.2-10

Versions of packages cups-filters recommends:
ii  colord  1.2.1-1+b2

Versions of packages cups-filters suggests:
pn  foomatic-db-compressed-ppds | foomatic-db  

-- debconf-show failed

Bug#843113: better missing kernel headers message

[積丹尼 Dan Jacobson]

Package: src:linux
Version: 4.8.5-1
Severity: wishlist

Setting up linux-image-4.8.0-1-686-pae (4.8.5-1) ...
I: /vmlinuz.old is now a symlink to boot/vmlinuz-4.7.0-1-686-pae
I: /initrd.img.old is now a symlink to boot/initrd.img-4.7.0-1-686-pae
I: /vmlinuz is now a symlink to boot/vmlinuz-4.8.0-1-686-pae
I: /initrd.img is now a symlink to boot/initrd.img-4.8.0-1-686-pae
/etc/kernel/postinst.d/dkms:
Error! Your kernel headers for kernel 4.8.0-1-686-pae cannot be found.
Please install the linux-headers-4.8.0-1-686-pae package,
or use the --kernelsourcedir option to tell DKMS where it's located

1. That error message is not coming from that file. In fact from no
file with dkms in its name:
$ dlocate --filename-only dkms|xargs grep Error.*You 2>&-|wc -l
0

2. Please also have the message mention if one then needs to reinstall
linux-image-4.8.0-1-686-pae .

(Seen when offine installing from a /var/cache/apt/archives/ that has
some, but not all packages...)

Bug#843112: ledger deb package should suggest ledger-el

[Thierry]

Source: ledger
Version: 3.1
Severity: minor

Dear Maintainer,

* What led up to the situation?

When using org-mode / babel, and using #+begin_src ledger, the key
binding C-c ', that should normally start to edit in ledger-mode, is
failing if ledger-el is not installed.

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

Installing ledger-el is solving the issue.

* What did you expect?

One of the solution, is at least to suggest the installation of
ledger-el in the deb package of ledger.

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

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

Bug#842288: transition: gdal

[Emilio Pozuelo Monfort]

On 03/11/16 20:12, Sebastiaan Couwenberg wrote:
> On 10/30/2016 11:48 AM, Emilio Pozuelo Monfort wrote:
>> On 29/10/16 21:59, Sebastiaan Couwenberg wrote:
>>> On 10/29/2016 10:26 AM, Emilio Pozuelo Monfort wrote:
 On 28/10/16 21:38, Sebastiaan Couwenberg wrote:
> On 10/28/2016 01:39 AM, Sebastiaan Couwenberg wrote:
>> On 10/27/2016 11:58 PM, Emilio Pozuelo Monfort wrote:
>>> On 27/10/16 20:10, Bas Couwenberg wrote:
 Package: release.debian.org
 Severity: normal
 User: release.debian@packages.debian.org
 Usertags: transition

 Dear Release Team,

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

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

 All reverse dependencies rebuilt successfully with GDAL 2.1.2 from
 experimental as summarized below, except mysql-workbench whose build
 dependencies are not installable (#840786), but it's not in testing due
 to (#839356).

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

 Please also binNMU osgearth in experimental as part of the transition.
>>>
>>> Sounds good. Go ahead.
>>
>> Thanks for the super quick feedback again!
>>
>> gdal (2.1.2+dfsg-1), liblas (1.8.1-3) & libgdal-grass (2.1.2-1) have
>> been uploaded to unstable, and gdal was just accepted. Sometime tomorrow
>> the buildds should have installed the packages.
>
> The mips64el buildd just installed gdal (2.1.2+dfsg-1), it's now
> available on all release architectures and all ports where the build
> dependencies are installable.
>
> Looks like we're ready for the binNMUs.

 Scheduling them.
>>>
>>> The binNMUs are looking good so far, except vtk6 which FTFBS on mips due
>>> to a g++ segfault.
>>>
>>> Can the build be retried (on another buildd)?
>>
>> Given back. I can't pick a specific buildd (not sure I want to in this case
>> anyway), so let's see.
> 
> Everything built now, but has not migrated to testing yet.
> 
> I'm not seeing the problem in the dose-debcheckout failures, I thought
> it was the gdcm FTBFS on mipsel which affects vtk6, but that doesn't
> seem to be it though.
> 
> Can you clarify why the packages rebuilt for the gdal transition aren't
> migrating?

vtk6/armhf picked a dependency on the new ffmpeg, so it's waiting for that to be
old enough. I will check again when that becomes a valid candidate in a couple
of days, but hopefully that's all that's needed at this point.

Cheers,
Emilio

Bug#842919: transition: xen

[Emilio Pozuelo Monfort]

Hi Ian,

On 02/11/16 11:47, Ian Jackson wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: transition
> 
> Hi.  This is the update from Xen 4.6 to Xen 4.8, as previously
> discussed.  (Currently, Xen 4.8.0 RC3.  I expect the Xen 4.8.0 release
> to be out by the time Debian freezes.)
> 
> libxen-* contains libraries needed for management tools.   The
> corresponding xen-utils-* packages are intended to be coinstallable,
> so perhaps a "smooth" transition may still be possible ?  (Contrary to
> what the autogenerated transition tracker thinks.)
> 
> All that is needed from the build-rdeps is a rebuild.  That is, of:
>   libvirt qemu xenwatch python-pyxenstore collectd grub2
> 
> I have checked that they all build against the new libxen{-4.8,-dev},
> at least on amd64.  I don't anticipate trouble on other architectures.

The ben tracker only lists qemu and libvirt as rdeps of the binaries that are
removed in the new version. Why do the other packages need a rebuild? Do any of
them statically link libxen or something?

Cheers,
Emilio

Bug#828299: fetchmail: FTBFS with openssl 1.1.0

[Sebastian Andrzej Siewior]

On 2016-11-03 23:39:32 [+0100], László Böszörményi (GCS) wrote:
>  OK, it remained the same then. May you try the work in progress
> update[1]? I'm off for sleeping. :-/

yup, worked.

> Thanks,
> Laszlo/GCS

Sebastian

Bug#843111: llvm-toolchain-3.7: FTBFS on i386

[Emilio Pozuelo Monfort]

Source: llvm-toolchain-3.7
Version: 1:3.7.1-3
Severity: serious

Hi,

Your package failed to build on i386. We need llvm 3.7 in testing/stretch
for ghc 8 (then we can remove llvm 3.5), thus opening this bug.

Cheers,
Emilio

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

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

Bug#843110: greenbone-security-assistant: please make the build reproducible

[Reiner Herrmann]

Source: greenbone-security-assistant
Version: 6.0.11+dfsg.1-1
Severity: wishlist
Tags: patch upstream
User: reproducible-bui...@lists.alioth.debian.org
Usertags: locale environment
X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org

Hi!

While working on the "reproducible builds" effort [1], we have noticed
that greenbone-security-assistant could not be built reproducibly.
One shell script does not normalize the locale while sorting, and
another one relies on echo interpreting escape sequences by default.

The attached patch fixes this.

Regards,
 Reiner

[1]: https://wiki.debian.org/ReproducibleBuilds
diff --git a/debian/patches/reproducible-build.patch b/debian/patches/reproducible-build.patch
new file mode 100644
index 000..e9e28a2
--- /dev/null
+++ b/debian/patches/reproducible-build.patch
@@ -0,0 +1,26 @@
+Author: Reiner Herrmann 
+Description: Fix reproducibility issues
+ - implementation of echo differs between shells
+   (bash's echo doesn't interpret the \n by default)
+ - use C locale for sorting, as order can vary between locales
+
+--- a/tools/generate-cpe-icon-dict.sh
 b/tools/generate-cpe-icon-dict.sh
+@@ -152,4 +152,5 @@
+ fi
+ 
+ # Close root element
+-echo "\n"
++echo
++echo ""
+--- a/tools/generate-zone-dict.sh
 b/tools/generate-zone-dict.sh
+@@ -98,7 +98,7 @@
+ fi
+ 
+ echo "  "
+-sed '/^\#/d' /usr/share/zoneinfo/zone.tab | cut -s -f 3 | sort | sed -e "s;\(.*\);  \1;"
++sed '/^\#/d' /usr/share/zoneinfo/zone.tab | cut -s -f 3 | LC_ALL=C sort | sed -e "s;\(.*\);  \1;"
+ 
+ # Append manual zones.
+ if [ -r "$APPEND_FILE" ]
diff --git a/debian/patches/series b/debian/patches/series
new file mode 100644
index 000..55077d0
--- /dev/null
+++ b/debian/patches/series
@@ -0,0 +1 @@
+reproducible-build.patch


signature.asc
Description: PGP signature

Bug#828299: fetchmail: FTBFS with openssl 1.1.0

[GCS]

On Thu, Nov 3, 2016 at 11:16 PM, Sebastian Andrzej Siewior
 wrote:
> On 2016-11-03 22:02:23 [+0100], László Böszörményi (GCS) wrote:
>>  Nope. Tried in a loop of ten with -j2, other ten with -j4 and another
>> ten with -j8 and it was working correctly. What's the result / current
>> problem at your end?
>
> As you see in [0]:
 OK, it remained the same then. May you try the work in progress
update[1]? I'm off for sleeping. :-/

Thanks,
Laszlo/GCS
[1] dget -x http://www.barcikacomp.hu/gcs/fetchmail_6.3.26-3.dsc

Bug#843109: zathura-ps: please make the build reproducible

[Reiner Herrmann]

Source: zathura-ps
Version: 0.2.3-1
Severity: wishlist
Tags: patch upstream
User: reproducible-bui...@lists.alioth.debian.org
Usertags: fileordering
X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org

Hi!

While working on the "reproducible builds" effort [1], we have noticed
that zathura-ps could not be built reproducibly.
During build objects are linked in non-deterministic order.

The attached patch fixes this by sorting the list of source files.

Regards,
 Reiner

[1]: https://wiki.debian.org/ReproducibleBuilds
diff --git a/debian/patches/reproducible-build.patch b/debian/patches/reproducible-build.patch
new file mode 100644
index 000..8f5c785
--- /dev/null
+++ b/debian/patches/reproducible-build.patch
@@ -0,0 +1,14 @@
+Author: Reiner Herrmann 
+Description: Sort list of source files for deterministic linking order
+
+--- a/Makefile
 b/Makefile
+@@ -5,7 +5,7 @@
+ 
+ PROJECT  = zathura-ps
+ PLUGIN   = ps
+-SOURCE   = $(shell find . -iname "*.c")
++SOURCE   = $(shell find . -iname "*.c" | LC_ALL=C sort)
+ HEADER   = $(shell find . -iname "*.h")
+ OBJECTS  = ${SOURCE:.c=.o}
+ DOBJECTS = ${SOURCE:.c=.do}
diff --git a/debian/patches/series b/debian/patches/series
new file mode 100644
index 000..55077d0
--- /dev/null
+++ b/debian/patches/series
@@ -0,0 +1 @@
+reproducible-build.patch


signature.asc
Description: PGP signature

Bug#828299: fetchmail: FTBFS with openssl 1.1.0

[Sebastian Andrzej Siewior]

On 2016-11-03 22:02:23 [+0100], László Böszörményi (GCS) wrote:
> On Thu, Nov 3, 2016 at 8:48 PM, Sebastian Andrzej Siewior
>  wrote:
> > On 2016-11-03 07:45:16 [+0100], Andreas Henriksson wrote:
> > fetchmail builds against openssl 1.1.0. So we are good here.
> > fetchmail fails to build with -j4.
> > What do we do now? I retitled the bug. Can you reproduce this on your
> > end?
>  Nope. Tried in a loop of ten with -j2, other ten with -j4 and another
> ten with -j8 and it was working correctly. What's the result / current
> problem at your end?

As you see in [0]:

|dpkg-buildpackage: info: host architecture amd64
| fakeroot debian/rules clean
|dh_testdir
|dh_testroot
|rm -f build-stamp configure-stamp
|[ ! -f Makefile ] || /usr/bin/make distclean
|rm -f po/*.gmo config.sub config.guess config.status
|dh_clean -X.orig -X.rej
| debian/rules build-arch
|set -e
|set -e
|dh_testdir
|dh_testdir
|/usr/bin/make
|make[1]: Entering directory '/<>'
|make[1]: *** No targets specified and no makefile found.  Stop.
|make[1]: Leaving directory '/<>'
|cp /usr/share/misc/config.sub config.sub
|debian/rules:138: recipe for target 'build-stamp' failed
|make: *** [build-stamp] Error 2
|make: *** Waiting for unfinished jobs
|cp /usr/share/misc/config.guess config.guess
|./configure  --build x86_64-linux-gnu --prefix=/usr --enable-nls \
|   --disable-fallback  --with-ssl=/usr --enable-NTLM --enable-SDPS 
--with-kerberos5 --with-gssapi=/usr
…
|sed -e "s/-lcrypt//; s/-lk5crypto//g;"  < Makefile > Makefile.tmp
|mv Makefile.tmp Makefile
|touch configure-stamp
|dpkg-buildpackage: error: debian/rules build-arch gave error exit status 2
|
|Build finished at 2016-08-26T18:31:07Z

The build-arch and clean rule run in parallel. This was triggered by "sbuild 
-j4 fetch….dsc"

[0] 
https://breakpoint.cc/openssl-1.1-rebuild-2016-08-26/failed/fetchmail_6.3.26-2_amd64-2016-08-26T18%3A30%3A26Z

> Laszlo/GCS

Sebastian

Bug#842961: add missing backtrace

[stefan esterer]

the attachement contains the backtrace collected via  (gdb) thread apply
all bt
(gdb)  thread apply all bt

Thread 106 (Thread 0x7fffcaeff700 (LWP 9843)):
#0  pthread_cond_timedwait@@GLIBC_2.3.2 () at ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_timedwait.S:225
#1  0x75ea27d8 in ?? () from /usr/lib/x86_64-linux-gnu/libnspr4.so
#2  0x75ea2cee in PR_WaitCondVar () from /usr/lib/x86_64-linux-gnu/libnspr4.so
#3  0x72257225 in ?? () from /usr/lib/icedove/libxul.so
#4  0x7225d069 in ?? () from /usr/lib/icedove/libxul.so
#5  0x7225ea53 in ?? () from /usr/lib/icedove/libxul.so
#6  0x72278ae9 in ?? () from /usr/lib/icedove/libxul.so
#7  0x7245be9b in ?? () from /usr/lib/icedove/libxul.so
#8  0x7244bf62 in ?? () from /usr/lib/icedove/libxul.so
#9  0x72260742 in ?? () from /usr/lib/icedove/libxul.so
#10 0x75ea8758 in ?? () from /usr/lib/x86_64-linux-gnu/libnspr4.so
#11 0x77bc4464 in start_thread (arg=0x7fffcaeff700) at pthread_create.c:333
#12 0x76e679df in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:105

Thread 87 (Thread 0x7fffba6ff700 (LWP 9805)):
#0  pthread_cond_timedwait@@GLIBC_2.3.2 () at ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_timedwait.S:225
#1  0x75ea27d8 in ?? () from /usr/lib/x86_64-linux-gnu/libnspr4.so
#2  0x75ea3192 in PR_Wait () from /usr/lib/x86_64-linux-gnu/libnspr4.so
#3  0x721407f1 in ?? () from /usr/lib/icedove/libxul.so
#4  0x7214cc87 in ?? () from /usr/lib/icedove/libxul.so
#5  0x7214ce79 in ?? () from /usr/lib/icedove/libxul.so
#6  0x7225ea53 in ?? () from /usr/lib/icedove/libxul.so
#7  0x72278ae9 in ?? () from /usr/lib/icedove/libxul.so
#8  0x7245be4c in ?? () from /usr/lib/icedove/libxul.so
#9  0x7244bf62 in ?? () from /usr/lib/icedove/libxul.so
#10 0x72260742 in ?? () from /usr/lib/icedove/libxul.so
#11 0x75ea8758 in ?? () from /usr/lib/x86_64-linux-gnu/libnspr4.so
#12 0x77bc4464 in start_thread (arg=0x7fffba6ff700) at pthread_create.c:333
#13 0x76e679df in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:105

Thread 65 (Thread 0x7fffbd3ff700 (LWP 9775)):
#0  pthread_cond_timedwait@@GLIBC_2.3.2 () at ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_timedwait.S:225
#1  0x75ea27d8 in ?? () from /usr/lib/x86_64-linux-gnu/libnspr4.so
#2  0x75ea3192 in PR_Wait () from /usr/lib/x86_64-linux-gnu/libnspr4.so
#3  0x721407f1 in ?? () from /usr/lib/icedove/libxul.so
#4  0x7214cc87 in ?? () from /usr/lib/icedove/libxul.so
#5  0x7214ce79 in ?? () from /usr/lib/icedove/libxul.so
#6  0x7225ea53 in ?? () from /usr/lib/icedove/libxul.so
#7  0x72278ae9 in ?? () from /usr/lib/icedove/libxul.so
#8  0x7245be4c in ?? () from /usr/lib/icedove/libxul.so
#9  0x7244bf62 in ?? () from /usr/lib/icedove/libxul.so
#10 0x72260742 in ?? () from /usr/lib/icedove/libxul.so
#11 0x75ea8758 in ?? () from /usr/lib/x86_64-linux-gnu/libnspr4.so
#12 0x77bc4464 in start_thread (arg=0x7fffbd3ff700) at pthread_create.c:333
#13 0x76e679df in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:105

Thread 64 (Thread 0x7fffc0fff700 (LWP 9774)):
#0  pthread_cond_wait@@GLIBC_2.3.2 () at ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185
#1  0x75ea2d70 in PR_WaitCondVar () from /usr/lib/x86_64-linux-gnu/libnspr4.so
#2  0x72257225 in ?? () from /usr/lib/icedove/libxul.so
#3  0x72259635 in ?? () from /usr/lib/icedove/libxul.so
#4  0x7225e9ec in ?? () from /usr/lib/icedove/libxul.so
#5  0x72278ae9 in ?? () from /usr/lib/icedove/libxul.so
#6  0x7245be9b in ?? () from /usr/lib/icedove/libxul.so
#7  0x7244bf62 in ?? () from /usr/lib/icedove/libxul.so
#8  0x72260742 in ?? () from /usr/lib/icedove/libxul.so
#9  0x75ea8758 in ?? () from /usr/lib/x86_64-linux-gnu/libnspr4.so
#10 0x77bc4464 in start_thread (arg=0x7fffc0fff700) at pthread_create.c:333
#11 0x76e679df in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:105

Thread 63 (Thread 0x7fffbe6ff700 (LWP 9773)):
#0  pthread_cond_wait@@GLIBC_2.3.2 () at ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185
#1  0x75ea2d70 in PR_WaitCondVar () from /usr/lib/x86_64-linux-gnu/libnspr4.so
#2  0x7334d5f7 in ?? () from /usr/lib/icedove/libxul.so
#3  0x73350aa2 in ?? () from /usr/lib/icedove/libxul.so
#4  0x7336bb19 in ?? () from /usr/lib/icedove/libxul.so
#5  0x7333bde6 in ?? () from /usr/lib/icedove/libxul.so
#6  0x7225ea53 in ?? () from /usr/lib/icedove/libxul.so
#7  0x72278ae9 in ?? () from /usr/lib/icedove/libxul.so
#8  0x7245be9b in ?? () from /usr/lib/icedove/libxul.so
#9  0x7244bf62 in ?? () from /usr/lib/icedove/libxul.so
#10 0x72260742 in ?? () from /usr/lib/icedove/libxul.so
#11 

Bug#837201:

[Antonio Trueba]

Hi,



> Andreas Kloeckner  writes:
> > Michael Biebl  writes:
> >
> >> [ Unknown signature status ]
> >> Am 10.09.2016 um 02:27 schrieb Andreas Kloeckner:
> >>> Package: systemd
> >>> Version: 231-4
> >>> Severity: normal
> >>>
> >>> Dear Maintainer,
> >>>
> >>> on my system, the following happens (from journalctl -e) on trying to
> start the
> >>> services in the subject.
> >>>
> >>> --
> >>> Sep 09 19:04:17 bolt systemd[2685]: systemd-hostnamed.service: Failed
> at step NAMESPACE spawning /lib/systemd/systemd-hostnamed: Too many levels
> of symbolic links
> >>
> >> Is /home or /tmp a symbolic link?
> >> How exactly does the /var/run symlink look like
> >>
> >> Please post the output of
> >> # ls -ld /home /tmp /var/run
> >
> > Thanks for your response!
> >
> > # ls -ld /home /tmp /var/run
> > drwxr-xr-x 3 root root 4096 Jun 25 13:38 /home
> > drwxrwxrwt 13 root root 36864 Sep 10 11:40 /tmp
> > lrwxrwxrwx 1 root root 5 Sep 9 19:25 /var/run -> /run/
> So, it turns out that my /root directory was a symlink. And that's what
> was causing all this grief. Fixed now, thanks for your help.
> Andreas


I've also been bitten by this bug, in my case /home was a symlink.

Upstream reports the bug as closed[1] few weeks ago, but it seems to be
still present in latest Debian package (231-10). Can anyone confirm that
this patch is included in that version, or will it be included in a future
one?


[1] https://github.com/systemd/systemd/issues/567


Thanks,

-- 
Antonio Trueba
atga...@gmail.com

Bug#831591: ffmpeg: kodi crash

[Andreas Cadhalpun]

Hi Bálint,

On 03.11.2016 13:00, Bálint Réczey wrote:
> 2016-11-03 12:54 GMT+01:00 Balint Reczey :
>> Thank you for the triaging and extensive description of the problem.
>> I have now forwarded the patch to upstream under your name since I did
>> not really add anything to the patch.

The patch looks good, thanks for forwarding it upstream. (Even though
one of the upstream developers has some peculiar ideas about correct
code.)

> If someone having the test file could test latest kodi in unstable
> that  would be geat.

There is a test file[1] in one of the merged bugs.
However, testing the latest kodi in unstable is of limited use, since
it was built against the same ffmpeg version currently in unstable.

If you want to verify that the problem is fixed, you'd have to recompile
kodi against 3.0.1 and test it with the current ffmpeg libraries (or
the ones from 3.1.1).

Best regards,
Andreas


1: 
https://bugs.debian.org/cgi-bin/bugreport.cgi?att=1;bug=832364;filename=test2.ts.gz;msg=67

Bug#842961: crash reproducable when sending mail

[stefan esterer]

I'm getting a segmentation fault error in icedove when sending a mail
via smtp.riseup.net. Sending via gmail does not trigger the crash.

Here is a log which was collected as this page [1] suggests:
Thread 1 "icedove-bin" received signal SIGSEGV, Segmentation fault.
0x7fffc6e1d060 in ?? ()

This crash is reproducable for me, the crash happens every time I try to
send a mail. I suppose this could be linked with the risup service not
accesible at this time?

[1] https://wiki.debian.org/de/Icedove

Bug#818962: fix the php-script-but-no-phpX-cli-dep error

[Antonio Ospite]

On Tue, 1 Nov 2016 10:51:41 +0100
Antonio Ospite  wrote:

> On Tue, 1 Nov 2016 00:10:15 +0100
> Antonio Ospite  wrote:
[...]
> [...]
> >
> > This also demote the case of when the interpreter uses a version number
> > in the interpreter to a "unusual-interpreter" warning.
> > 
> 
> After thinking a little more about it, this still isn't right, we
> should get the php-script-but-no-php-cli-dep error also when the
> shebang line has an "unusual" interpreter, like /usr/bin/php7.0.
> 

OK, the updated patches are attached.

The changes since v1 are:
 - the dependency checks are now triggered also when an unusual
   interpreter is found

Ondřej do you have any comment?

Thanks,
   Antonio

-- 
Antonio Ospite
https://ao2.it
https://twitter.com/ao2it

A: Because it messes up the order in which people normally read text.
   See http://en.wikipedia.org/wiki/Posting_style
Q: Why is top-posting such a bad thing?
>From 4a5a744c15efc15bdbd6f1baab510fd3811c80f0 Mon Sep 17 00:00:00 2001
From: Antonio Ospite 
Date: Thu, 3 Nov 2016 22:51:08 +0100
Subject: [PATCHv2 1/2] Give error for packages shipping php scripts but not
 depending on php-cli

The PHP maintainers recommend to have PHP dependencies without
specifying the PHP version explicitly, e.g.:

  Depends: php-cli, php-curl, php-xsl

instead of:

  Depends: php7.0-cli, php7.0-curl, php7.0-xsl

This is a safe thing to do considering that each Debian stable version
is going to ship with only one major version of PHP.

However in the case of packages shipping php scripts, lintian now
wrongly suggests to depend on a versioned phpX-cli package.

Fix this by triggering the lintian error when the package ships a script
and but does not depend on the unversioned php-cli dependency.

This also covers the deprecated case of using a versioned phpX-cli
dependency. To confirm that, a dependency to php7.0-cli has been added
to t/tests/legacy-scripts/debian/debian/control and it has been verified
that the package still gives the error.

Moving php from the "versioned interpreters" to the unversioned
interpreters also results in an "unusual-interpreter" warning when, for
example, an interpreter with a version number in the filename is used.

In a future commit the "unusual-interpreter" warning will be turned into
a more specific warning suggesting to use the unversioned php
interpreter in the shebang line.

The changes pass these tests:
  debian/rules runtests onlyrun=scripts-missing-dep
  debian/rules runtests onlyrun=legacy-scripts

Closes: #818962
Thanks: Mathieu Parent 

Signed-off-by: Antonio Ospite 
---
 checks/scripts.desc  | 14 +++---
 checks/scripts.pm| 18 +++---
 data/scripts/interpreters|  1 +
 data/scripts/versioned-interpreters  |  1 -
 t/tests/legacy-scripts/debian/debian/control |  2 +-
 t/tests/legacy-scripts/debian/debian/rules   |  4 ++--
 t/tests/legacy-scripts/tags  |  5 +++--
 t/tests/scripts-missing-dep/desc |  2 +-
 t/tests/scripts-missing-dep/tags |  2 +-
 9 files changed, 23 insertions(+), 26 deletions(-)

diff --git a/checks/scripts.desc b/checks/scripts.desc
index 12a642b..d2c14b8 100644
--- a/checks/scripts.desc
+++ b/checks/scripts.desc
@@ -217,24 +217,16 @@ Info: Packages that use mawk scripts must depend on the mawk package.
  In some cases a weaker relationship, such as Suggests or Recommends, will
  be more appropriate.
 
-Tag: php-script-but-no-phpX-cli-dep
+Tag: php-script-but-no-php-cli-dep
 Severity: important
 Certainty: certain
-Info: Packages with PHP scripts must depend on a phpX-cli package such as
- php5-cli.  Note that a dependency on a php-cgi package (such as php5-cgi)
+Info: Packages with PHP scripts must depend on the php-cli package.
+ Note that a dependency on a php-cgi package (such as php-cgi or php7.0-cgi)
  is needlessly strict and forces the user to install a package that isn't
  needed.
  .
  In some cases a weaker relationship, such as Suggests or Recommends, will
  be more appropriate.
- .
- Lintian can only recognize phpX-cli dependencies for values of X that it
- knows are available in the archive.  You will get this warning if you
- allow, as alternatives, versions of PHP that are so old they're not
- available in stable.  The correct fix in those cases is probably to drop
- the old alternative.  If this package depends on a newer php-cli package
- that Lintian doesn't know about, please file a bug against Lintian so
- that it can be updated.
 
 Tag: python-script-but-no-python-dep
 Severity: important
diff --git a/checks/scripts.pm b/checks/scripts.pm
index f40fddd..8dd0e3c 100644
--- a/checks/scripts.pm
+++ b/checks/scripts.pm
@@ -390,6 +390,12 @@ sub run {
 }
 script_tag('unusual-interpreter', $filename, "#!$interpreter")
   unless $pinter;
+
+# This 

Bug#843079: Bug#843107: python-mpop: FTBFS: ImportError: No module named trollsift.parser

[Sebastiaan Couwenberg]

severity 843079 serious
merge 843079 843107
thanks

On 11/03/2016 10:30 PM, Chris Lamb wrote:
> python-mpop fails to build from source in unstable/amd64:
> [...]
> File "/usr/lib/python2.7/dist-packages/PIL/Image.py", line 2001, in 
> _check_size
>   raise ValueError("Width and Height must be > 0")

On Thu, 3 Nov 2016 18:44:47 +0100 Matthias Klose wrote:
> the autopkg tests are failing:
> [...]
>   File "/usr/lib/python2.7/dist-packages/PIL/Image.py", line 2001, in
_check_size
> raise ValueError("Width and Height must be > 0")

You can thank yesterdays Pillow 3.4.2 upload for that.

Antonio, can you have a look at this?

Kind Regards,

Bas

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

Bug#835437: pycurl: FTBFS too much often (failing tests)

[Sandro Tosi]

> I believe this bug to be essentially the same as the one regarding
> network access.

yeah i believe that's the case too, as looking at the logs you
attached to the bug there are several instances of trying to access
remote resources and the error out.

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

Bug#842264: Wrong OS version detected

[Hideki Yamane]

Hi,

 Thanks for the log, it runs "lsb_release -sirc" and it returns your
 system is squeeze.

> -- System Information:
> Debian Release: stretch/sid
>   APT prefers oldoldstable
>   APT policy: (500, 'oldoldstable'), (500, 'unstable'), (500, 'testing'),
> (1,
> 'experimental')

 lsb-release package probably detects your system as squeeze due to
 apt policy setting. Could you show me "apt-cache policy | grep release"?
 

-- 
Regards,

 Hideki Yamane henrich @ debian.or.jp/org
 http://wiki.debian.org/HidekiYamane

Bug#838622: needrestart: systemctl combine, stdio, list mode: do not wrap systemctl restart commands

[Thomas Liske]

Paul Wise  writes:

tags 838622 upstream fixed-upstream
thanks


Hi Paul,

> When using systemctl_combine=1, ui=NeedRestart::UI::stdio and restart=l
> and there are many services to restart, the resulting systemctl restart
> command is wrapped according to the terminal size instead of letting
> the terminal itself wrap the command. The needrestart wrapping prevents
> copy-paste of the whole command-line including the parts after the wrap
> but the terminal wrapping of long lines allows this. It appears that
> the fix would be for the UI modules to grow a 'command' function and
> for the stdio module to *not* use wprint for that function.

I've added a special command print option which does *not* use
Text::Wrap to make long lines working. Thanks for the hint, since I'm
not using list mode at all I was not aware of this issue, yet.


HTH,
Thomas


> -- System Information:
> Debian Release: stretch/sid
>   APT prefers testing-debug
>   APT policy: (900, 'testing-debug'), (900, 'testing'), (800, 
> 'unstable-debug'), (800, 'unstable'), (790, 'buildd-unstable'), (700, 
> 'experimental-debug'), (700, 'experimental'), (690, 'buildd-experimental')
> Architecture: amd64 (x86_64)
>
> Kernel: Linux 4.7.0-1-amd64 (SMP w/4 CPU cores)
> Locale: LANG=en_AU.utf8, LC_CTYPE=en_AU.utf8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
>
> Versions of packages needrestart depends on:
> ii  dpkg   1.18.10
> ii  gettext-base   0.19.8.1-1
> ii  libintl-perl   1.26-2
> ii  libmodule-find-perl0.13-1
> ii  libmodule-scandeps-perl1.21-1
> ii  libproc-processtable-perl  0.53-1+b1
> ii  libsort-naturally-perl 1.03-1
> ii  libterm-readkey-perl   2.33-1+b1
> ii  perl   5.22.2-5
> ii  xz-utils   5.1.1alpha+20120614-2.1
>
> needrestart recommends no packages.
>
> Versions of packages needrestart suggests:
> ii  libnotify-bin0.7.6-2
> ii  needrestart-session  0.3-2
>
> -- no debconf information
>
> -- 
> bye,
> pabs
>
> https://wiki.debian.org/PaulWise

-- 
supp...@ibh.de  Tel. +49 351 477 77 30
www.ibh.de  Fax  +49 351 477 77 39

---
Dipl.-Ing. Thomas Liske
Teamleiter DataCenter Services


IBH IT-Service GmbH  Amtsgericht Dresden
Heilbronner Str. 20  HRB 13626
01189 DresdenGF: Prof. Dr. T. Horn, S. Horn
Germany  VAT DE182302907
---
Ihr Partner für: LAN, WAN IP-Quality, Security, VoIP, SAN, Backup, USV
---
   professioneller IT-Service - kompetent und zuverlässig
---

Bug#838849: rdflib: newer upstream version available

[Olivier Berger]

Hi.

chrysn  writes:

> Hi Ghis, hello Olivier,
>
> On Mon, Oct 31, 2016 at 09:46:21AM +, Ghislain Vaillant wrote:
>> The new upstream release of rdflib is now a blocker for both inclusion of
>> new packages (#838840) and update of existing packages (#842661).
>
> I'm on it.
>
>> Please consider addressing this issue to allow work on the above mentioned
>> packages to resume. If maintenance time is short, you might want to consider
>> moving this package to team-maintenance under the Python Modules Team, where
>> it would benefit from greater visibility.
>>
>> CC-ing Olivier Berger just in case he is not subscribed to his own packages.
>
> I'd like to join the team with this package. I had considered this but
> was not comfortable with the Python Modules Teams's methods back then
> (SVN), but things have changed.
>
> Just: Me being entered as the packages' maintainer does not accurately
> reflect reality; I did some major rewriting in early 2013, and Olivier
> has largely taken over since then. Thus:
>
> Olivier, if you have strong objections against moving this package to
> team maintainership with the Python Modules Team, please voice them (in
> which case I'd prefer you to hand maintainership over to you), otherwise
> I'll finish the currently urgent changes and then join the team to
> maintain it in together.
>

Same as per #761177 for sqparql-wrapper, I'd be glad to hand over the
work, since I don't have the time at the moment to work on updating the
package.

Team work would be great, provided enough people care for RDF in Python
;-)

Please, do what's best.

Thanks in advance.

Best regards,
-- 
Olivier BERGER 
http://www-public.telecom-sudparis.eu/~berger_o/ - OpenPGP-Id: 2048R/5819D7E8
Ingenieur Recherche - Dept INF
Institut Mines-Telecom, Telecom SudParis, Evry (France)

Bug#838355: needrestart: Automatic restart mode doesn't work

[Thomas Liske]

tags 838355 upstream fixed-upstream
severity 838355 important
thanks


Hi Georg,


"ge...@riseup.net"  writes:

> needrestart tells me that it restarted a service, however, this doesn't
> seem to be true:

absolutely! The codepath for list and automatic mode was missing the
composite command execution for systemd. The upstream fix will be part
of needrestart 2.10.

Thanks for reporting!


HTH,
Thomas

> # Date && systemctl status ganeti.service | grep Active && needrestart -v -m 
> a -r a && date && systemctl status ganeti.service | grep Active
> Tue Sep 20 09:19:10 UTC 2016
>Active: active (running) since Tue 2016-09-20 09:07:09 UTC; 12min ago
> [main] eval /etc/needrestart/needrestart.conf
> [main] running in root-mode
> [Core] Using UI 'NeedRestart::UI::stdio'...
> [main] detected systemd
> [Core] #1209 is a NeedRestart::Interp::Java
> [Core] #1376 is a NeedRestart::Interp::Python
> [Core] #1575 is a NeedRestart::Interp::Ruby
> [main] #3023 uses deleted /usr/lib/x86_64-linux-gnu/libxenguest-4.4.so
> [main] #3023 is not a child
> [main] #3141 uses deleted /usr/lib/x86_64-linux-gnu/libxenguest-4.4.so
> [main] #3141 is not a child
> [main] # uses deleted /usr/lib/x86_64-linux-gnu/libxenguest-4.4.so
> [main] # is not a child
> [Core] #14391 is a NeedRestart::Interp::Python
> [Core] #14442 is a NeedRestart::Interp::Python
> [main] #3023 exe => /usr/bin/qemu-system-x86_64
> [main] #3023 is ganeti.service
> [main] #3141 exe => /usr/bin/qemu-system-x86_64
> [main] #3141 is ganeti.service
> [main] # exe => /usr/bin/qemu-system-x86_64
> [main] # is ganeti.service
> [Kernel] Linux: kernel release 4.6.0-0.bpo.1-amd64, kernel version #1 SMP 
> Debian 4.6.4-1~bpo8+1 (2016-08-11)
> Failed to load NeedRestart::Kernel::kFreeBSD: [Kernel/kFreeBSD] Not running 
> on GNU/kFreeBSD!
> [Kernel/Linux] /boot/vmlinuz-4.6.0-0.bpo.1-amd64 => 4.6.0-0.bpo.1-amd64 
> (debian-ker...@lists.debian.org) #1 SMP Debian 4.6.4-1~bpo8+1 (2016-08-11) 
> [4.6.0-0.bpo.1-amd64]*
> [Kernel/Linux] /boot/vmlinuz-4.5.0-0.bpo.2-amd64 => 4.5.0-0.bpo.2-amd64 
> (debian-ker...@lists.debian.org) #1 SMP Debian 4.5.4-1~bpo8+1 (2016-05-13) 
> [4.5.0-0.bpo.2-amd64]
> [Kernel/Linux] Expected linux version: 4.6.0-0.bpo.1-amd64
> Running kernel seems to be up-to-date.
> Restarting services...
>  systemctl restart ganeti.service
> No containers need to be restarted.
> No user sessions are running outdated binaries.
> Tue Sep 20 09:19:10 UTC 2016
>Active: active (running) since Tue 2016-09-20 09:07:09 UTC; 12min ago
>
> -- System Information:
> Debian Release: 8.5
>   APT prefers stable
>   APT policy: (900, 'stable')
> Architecture: amd64 (x86_64)
>
> Kernel: Linux 4.6.0-0.bpo.1-amd64 (SMP w/12 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 needrestart depends on:
> ii  dpkg   1.17.27
> ii  gettext-base   0.19.3-2
> ii  libintl-perl   1.23-1+deb8u1
> ii  libmodule-find-perl0.12-1
> ii  libmodule-scandeps-perl1.16-1
> ii  libproc-processtable-perl  0.51-1
> ii  libsort-naturally-perl 1.03-1
> ii  libterm-readkey-perl   2.32-1+b1
> ii  perl   5.20.2-3+deb8u6
> ii  xz-utils   5.1.1alpha+20120614-2+b3
>
> needrestart recommends no packages.
>
> Versions of packages needrestart suggests:
> pn  needrestart-session | libnotify-bin  
>
> -- no debconf information
>
> If there is anything I can do / provide to debug this further, please
> let me know.
>
> Thanks in advance and for your work!
> All the best,
> Georg

-- 
supp...@ibh.de  Tel. +49 351 477 77 30
www.ibh.de  Fax  +49 351 477 77 39

---
Dipl.-Ing. Thomas Liske
Teamleiter DataCenter Services


IBH IT-Service GmbH  Amtsgericht Dresden
Heilbronner Str. 20  HRB 13626
01189 DresdenGF: Prof. Dr. T. Horn, S. Horn
Germany  VAT DE182302907
---
Ihr Partner für: LAN, WAN IP-Quality, Security, VoIP, SAN, Backup, USV
---
   professioneller IT-Service - kompetent und zuverlässig
---

Bug#828550: socat: FTBFS with openssl 1.1.0

[Sandro Tosi]

On Thu, Nov 3, 2016 at 3:59 PM, László Böszörményi (GCS)  
wrote:
> On Thu, Nov 3, 2016 at 8:42 PM, Sandro Tosi  wrote:
>> On Mon, 5 Sep 2016 10:53:05 +0200 Gerhard Rieger
>>  wrote:
>>> Thank you, I will check!
>>
>> hey Gerhard, do you have a plan to look at this soon (now that openssl
>> 1.1.0 bugs are RC)? thanks!
>  Anything wrong with Sebastian Andrzej Siewior's patch? I plan to use
> if no one objects.

not from me (but i dont know anything about it :) ) i was just
checking if there was some problem that prevented Gerhard to update
the pkg. László if you have time and can prepare an updated pkg that'd
be great!

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

Bug#761177: python-sparqlwrapper: New version [...] available

[Olivier Berger]

Hi Christian.

(responding with my other address... my other laptop a bit out of reach
at the moment).

chrysn  writes:

>
> Can you spare some time to update it, shall I turn to DPMT for
> assistance with the SVN for a team upload, or would you prefer me to
> prepare an NMU (which I'd still need a sponsor for)?
>

I'm afraid I don't have much time available at the moment (and probably
in the future) for working on an update of the package.

I'd then be OK for anyone taking over, or updating as member of the team
(directly in SVN).

However, I'd recommend to perform some tests on the real functionality
of sparqlwrapper (making sure its tests pass) instead of just updating
it because of some dependency in rdflib, since it's not a completely
minor version change.

However, I'm not sure there are many folks able to test the package in
realistic conditions anyway...

Please do whatever seems best.

Thanks for caring.

Best regards,
-- 
Olivier BERGER 
http://www-public.telecom-sudparis.eu/~berger_o/ - OpenPGP-Id: 2048R/5819D7E8
Ingenieur Recherche - Dept INF
Institut Mines-Telecom, Telecom SudParis, Evry (France)

Bug#836248: Re-open

[Neil Williams]

On Thu, 3 Nov 2016 22:06:17 +0300
Dmitry Shachnev  wrote:

> Hi Neil,
> 
> On Thu, Nov 03, 2016 at 06:37:23PM +, Neil Williams wrote:
> > [...]
> >
> > That results in a package containing:
> >
> >  Built-Using: python-sphinx-bootstrap-theme, sphinx (= 1.4.8-1)
> >
> > The problem with that is:
> > $ apt-cache show sphinx
> > N: Unable to locate package sphinx
> > E: No packages found
> >
> > So dh_sphinxdoc should be putting in python-sphinx (= 1.4.8-1)  
> 
> No. Let me quite the Debian Policy § 7.8 (the emphasis is mine):
> 
>   A Built-Using field must list the corresponding *source* package
> for any such binary package incorporated during the build […]

That was my error, yes.

> > Also, wasn't the original intention from the bug report that I'd be
> > able to use it as:
> >
> >  Built-Using: python-sphinx-bootstrap-theme (=
> > ${sphinxdoc:Built-Using})
> >
> > [...]
> >
> > It's the theme which adds the CSS. Having Built-Using for sphinx is
> > fine but the version of the theme is unrelated to the version of
> > sphinx.  
> 
> The original bug was asking about Alabaster, which is the default
> theme, and thus much more popular than the bootstrap theme.

The bug mentioned python3-alabaster which comes from the alabaster
source package, not sphinx. Currently at versio 0.7.8-1 - that's why I
thought it could relate to themes packaged separately from sphinx
itself. i.e.:

Built-Using: python3-alabaster (= foo)

Correcting for the misconception about binary vs source package, my
expectation of the original bug report was that the fix would allow the
package to contain:

Built-Using: alabaster (= 0.7.8-1)

python-sphinx depends on python-alabaster in unstable but not in
jessie. The source package is still separate though and building docs
using alabaster doesn't create a dependency on python-alabaster.

The current helper produces

Built-Using: sphinx (= 1.4.8-1)

That seems inaccurate to me as the files come from a dependency of
sphinx? Or is this only meant to relate to files in libjs-sphinxdoc?

> I can try to detect whether the documentation contains embedded
> CSS/JS files from any theme, but that would be quite complicated. The
> only way that comes to my mind is comparing the file names in the
> theme package (extracted from build-dependencies) and in the built
> package, and searching for *_t → * renamings.
> 
> However, this sounds like a huge hack to me, so I am not sure I want
> to do this.

The theme needs to be specified in the conf.py and the package
providing it needs to be installed for the theme to be active, isn't
there a way of mapping that instead of looking at the output files?

> In your particular case (lava-server-doc), you have the JS, CSS and
> fonts files not symlinking, which sounds like a much bigger issue for
> me. In dh_sphinxdoc, I cannot support every existing Sphinx theme, so
> you need to symlink these files manually.


> In lava-server-doc, there are > 5 MB of files that can be symlinked,
> and only two files (8.1 kB) that are generated from templates, so I
> don't even think it makes sense to care about them.

Specifically about lava-server-doc, there is duplication because we're
migrating to a whole new model. We expect to drop the v1 directory
during 2017.

> > Finally, can we have some documentation of how to use
> > ${sphinxdoc:Built-Using} in man dh_sphinxdoc please?  
> 
> Leaving this bug open for this part of your message.

Thanks. The process of building from the theme is quite opaque - it's
not clear whether Built-Using: sphinx (= 1.4.8-1) is accurate for a
package using an external theme. Some help in the manpage would be
appreciated to clarify things like which files need to be symlinked to
the theme package and why Built-Using should refer to sphinx and not
the theme.

-- 


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



pgpUiUNzF3H1m.pgp
Description: OpenPGP digital signature

Bug#761177: python-sparqlwrapper: New version [...] available

[Olivier Berger]

Btw, Christian,

The patch provided in #761186 might also be worth considering since it
seems someone might have already done the work in Ubunntu land (?).

Hope this helps,

Best regards,

Olivier Berger  writes:

> Hi Christian.
>
> (responding with my other address... my other laptop a bit out of reach
> at the moment).
>
> chrysn  writes:
>
>>
>> Can you spare some time to update it, shall I turn to DPMT for
>> assistance with the SVN for a team upload, or would you prefer me to
>> prepare an NMU (which I'd still need a sponsor for)?
>>
>
> I'm afraid I don't have much time available at the moment (and probably
> in the future) for working on an update of the package.
>
> I'd then be OK for anyone taking over, or updating as member of the team
> (directly in SVN).
>
> However, I'd recommend to perform some tests on the real functionality
> of sparqlwrapper (making sure its tests pass) instead of just updating
> it because of some dependency in rdflib, since it's not a completely
> minor version change.
>
> However, I'm not sure there are many folks able to test the package in
> realistic conditions anyway...
>
> Please do whatever seems best.
>
> Thanks for caring.
>
> Best regards,
> -- 
> Olivier BERGER 
> http://www-public.telecom-sudparis.eu/~berger_o/ - OpenPGP-Id: 2048R/5819D7E8
> Ingenieur Recherche - Dept INF
> Institut Mines-Telecom, Telecom SudParis, Evry (France)

-- 
Olivier BERGER 
http://www-public.telecom-sudparis.eu/~berger_o/ - OpenPGP-Id: 2048R/5819D7E8
Ingenieur Recherche - Dept INF
Institut Mines-Telecom, Telecom SudParis, Evry (France)

Bug#843107: python-mpop: FTBFS: ImportError: No module named trollsift.parser

[Chris Lamb]

Source: python-mpop
Version: 1.3.0-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,

python-mpop fails to build from source in unstable/amd64:

  […]

  creating build/lib.linux-x86_64-2.7/mpop/tests
  copying mpop/tests/test_geo_image.py -> build/lib.linux-x86_64-2.7/mpop/tests
  copying mpop/tests/test_doc.py -> build/lib.linux-x86_64-2.7/mpop/tests
  copying mpop/tests/__init__.py -> build/lib.linux-x86_64-2.7/mpop/tests
  copying mpop/tests/test_mipp.py -> build/lib.linux-x86_64-2.7/mpop/tests
  copying mpop/tests/test_scene.py -> build/lib.linux-x86_64-2.7/mpop/tests
  copying mpop/tests/test_plugin.py -> build/lib.linux-x86_64-2.7/mpop/tests
  copying mpop/tests/test_seviri.py -> build/lib.linux-x86_64-2.7/mpop/tests
  copying mpop/tests/test_channel.py -> build/lib.linux-x86_64-2.7/mpop/tests
  copying mpop/tests/test_image.py -> build/lib.linux-x86_64-2.7/mpop/tests
  copying mpop/tests/test_visir.py -> build/lib.linux-x86_64-2.7/mpop/tests
  copying mpop/tests/test_satin_helpers.py -> 
build/lib.linux-x86_64-2.7/mpop/tests
  copying mpop/tests/test_nc_pps_l2.py -> build/lib.linux-x86_64-2.7/mpop/tests
  copying mpop/tests/test_satellites.py -> build/lib.linux-x86_64-2.7/mpop/tests
  copying mpop/tests/test_pp_core.py -> build/lib.linux-x86_64-2.7/mpop/tests
  copying mpop/tests/test_projector.py -> build/lib.linux-x86_64-2.7/mpop/tests
  copying mpop/tests/test_viirs_sdr.py -> build/lib.linux-x86_64-2.7/mpop/tests
  env 
PYTHONPATH=/home/lamby/temp/cdt.20161103212915.XxOo8TNjqe.db.python-mpop/python-mpop-1.3.0
 
PPP_CONFIG_DIR=/home/lamby/temp/cdt.20161103212915.XxOo8TNjqe.db.python-mpop/python-mpop-1.3.0/etc
 \
/usr/bin/make -C doc html
  make[2]: Entering directory 
'/home/lamby/temp/cdt.20161103212915.XxOo8TNjqe.db.python-mpop/python-mpop-1.3.0/doc'
  sphinx-build -b html -d build/doctrees   source build/html
  Running Sphinx v1.4.8
  making output directory...
  loading pickled environment... not yet created
  loading intersphinx inventory from 
/usr/share/doc/python-doc/html/objects.inv...
  building [mo]: targets for 0 po files that are out of date
  building [html]: targets for 7 source files that are out of date
  updating environment: 7 added, 0 changed, 0 removed
  reading sources... [ 14%] image
  reading sources... [ 28%] index
  reading sources... [ 42%] input
  reading sources... [ 57%] install
  reading sources... [ 71%] pp
  reading sources... [ 85%] quickstart
  reading sources... [100%] saturn
  
  
/home/lamby/temp/cdt.20161103212915.XxOo8TNjqe.db.python-mpop/python-mpop-1.3.0/mpop/satin/viirs_sdr.py:docstring
 of mpop.satin.viirs_sdr.ViirsSDRReader.get_sunsat_angles:4: ERROR: Unexpected 
indentation.
  
/home/lamby/temp/cdt.20161103212915.XxOo8TNjqe.db.python-mpop/python-mpop-1.3.0/mpop/satin/viirs_sdr.py:docstring
 of mpop.satin.viirs_sdr.ViirsSDRReader.get_sunsat_angles:5: WARNING: Block 
quote ends without a blank line; unexpected unindent.
  
/home/lamby/temp/cdt.20161103212915.XxOo8TNjqe.db.python-mpop/python-mpop-1.3.0/doc/source/input.rst:58:
 WARNING: autodoc: failed to import module u'mpop.satin.hdfeos_l1b'; the 
following exception was raised:
  Traceback (most recent call last):
File "/usr/lib/python2.7/dist-packages/sphinx/ext/autodoc.py", line 519, in 
import_object
  __import__(self.modname)
File 
"/home/lamby/temp/cdt.20161103212915.XxOo8TNjqe.db.python-mpop/python-mpop-1.3.0/mpop/satin/hdfeos_l1b.py",
 line 41, in 
  from trollsift.parser import Parser, globify
  ImportError: No module named trollsift.parser
  
/home/lamby/temp/cdt.20161103212915.XxOo8TNjqe.db.python-mpop/python-mpop-1.3.0/doc/source/input.rst:85:
 WARNING: autodoc: failed to import module u'mpop.satin.hrpt'; the following 
exception was raised:
  Traceback (most recent call last):
File "/usr/lib/python2.7/dist-packages/sphinx/ext/autodoc.py", line 519, in 
import_object
  __import__(self.modname)
File 
"/home/lamby/temp/cdt.20161103212915.XxOo8TNjqe.db.python-mpop/python-mpop-1.3.0/mpop/satin/hrpt.py",
 line 48, in 
  SATPOS_DIR = 
os.path.sep.join(os.environ["AAPP_PREFIX"].split(os.path.sep)[:-1])
File "/usr/lib/python2.7/UserDict.py", line 40, in __getitem__
  raise KeyError(key)
  KeyError: 'AAPP_PREFIX'
  
/home/lamby/temp/cdt.20161103212915.XxOo8TNjqe.db.python-mpop/python-mpop-1.3.0/doc/source/input.rst:94:
 WARNING: autodoc: failed to import module u'mpop.satin.eps1a'; the following 
exception was raised:
  Traceback (most recent call last):
File "/usr/lib/python2.7/dist-packages/sphinx/ext/autodoc.py", line 519, in 
import_object
  __import__(self.modname)
File 
"/home/lamby/temp/cdt.20161103212915.XxOo8TNjqe.db.python-mpop/python-mpop-1.3.0/mpop/satin/eps1a.py",
 line 45, in 
  SATPOS_DIR = 
os.path.sep.join(os.environ["AAPP_PREFIX"].split(os.path.sep)[:-1])
File 

Bug#843108: python-django-horizon: not compatible with Django 1.10 or JQuery 3.1.1-1

[Václav Ovsík]

Package: python-django-horizon
Version: 3:10.0.0-1
Severity: normal

Dear Maintainer,
while I'm experimenting with Newton OS release on Sid the two problems
revealed.
 * Django 1.10 - some actions don't work because of CSRF missing
 [Thu Nov 03 16:31:18.604797 2016] [wsgi:error] [pid 10577:tid 139689449191168] 
[client 192.168.29.70:50192] UserWarning: A {% csrf_token %} was used in a 
template, but the context did not provide the value.  Th is is usually caused 
by not using RequestContext., referer: 
http://controller.os2.i.cz/project/network_topology/
 * JQuery 3.1.1-1 - drop-down menus don't work.

Downgrade Django to 1.8.15-1~bpo8+1 and libjs-jquery to 1.11.3+dfsg-4~bpo8+1
solve the problems.
-- 
Zito


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

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

Versions of packages python-django-horizon depends on:
ii  python-babel 2.3.4+dfsg.1-2
ii  python-ceilometerclient  2.6.1-2
ii  python-cinderclient  1:1.9.0-2
ii  python-django1:1.10.1-1
ii  python-django-babel  0.5.1-2
ii  python-django-compressor 2.0-4
ii  python-django-openstack-auth 2.4.1-2
ii  python-django-pyscss 2.0.2-6
ii  python-glanceclient  1:2.5.0-3
ii  python-heatclient1.4.0-2
ii  python-iso8601   0.1.11-1
ii  python-keystoneclient1:3.2.0-2
ii  python-memcache  1.57-2
ii  python-netaddr   0.7.18-2
ii  python-neutronclient 1:6.0.0-2
ii  python-novaclient2:6.0.0-2
ii  python-oslo.concurrency  3.14.0-2
ii  python-oslo.config   1:3.17.0-3
ii  python-oslo.i18n 3.9.0-3
ii  python-oslo.policy   1.14.0-2
ii  python-oslo.serialization2.13.0-2
ii  python-oslo.utils3.16.0-2
ii  python-pbr   1.10.0-1
ii  python-pint  0.7.2-3
ii  python-pyscss1.3.5-2
ii  python-six   1.10.0-3
ii  python-swiftclient   1:3.1.0-2
ii  python-tz2015.7+dfsg-0.1
ii  python-xstatic   1.0.0-4
ii  python-xstatic-angular   1.3.7.0-2
ii  python-xstatic-angular-bootstrap 0.11.0.3-1
ii  python-xstatic-angular-fileupload12.0.4.0+dfsg1-1
ii  python-xstatic-angular-gettext   2.1.0.2-2
ii  python-xstatic-angular-lrdragndrop   1.0.2.2-1
ii  python-xstatic-angular-schema-form   0.8.13.0-2
ii  python-xstatic-bootstrap-datepicker  0.0.0.1-3
ii  python-xstatic-bootstrap-scss3.2.0.1-1
ii  python-xstatic-bootswatch3.3.5.2-2
ii  python-xstatic-d33.4.11-3
ii  python-xstatic-font-awesome  4.1.0-1
ii  python-xstatic-hogan 2.0.0.2-1
ii  python-xstatic-jasmine   2.1.2.0-1
ii  python-xstatic-jquery1.7.2.0+dfsg1-3
ii  python-xstatic-jquery-migrate1.2.1.1+dfsg1-1
ii  python-xstatic-jquery-ui 1.10.1.1+debian+dfsg1-5
ii  python-xstatic-jquery.quicksearch2.0.4.1-1
ii  python-xstatic-jquery.tablesorter2.14.5.1-2
ii  python-xstatic-jsencrypt 2.0.0.2-1
ii  python-xstatic-magic-search  0.2.5.1-1
ii  python-xstatic-mdi   1.4.57.0-1
ii  python-xstatic-objectpath1.2.1.0-2
ii  python-xstatic-rickshaw  1.5.0.2-2
ii  python-xstatic-roboto-fontface   0.4.3.2-1
ii  python-xstatic-smart-table   1.4.5.3-1
ii  python-xstatic-spin  1.2.8.0+dfsg1-1
ii  python-xstatic-term.js   0.0.4.2-2
ii  python-xstatic-tv4   1.2.7.0-2
ii  python-yaml  3.12-1
pn  python:any   

python-django-horizon recommends no packages.

Versions of packages python-django-horizon suggests:
ii  memcached  1.4.31-1

-- no debconf information

Bug#843096: kodi-pvr-vdr-vnsi: Incompatible xbmc API version for 17.beta

[Tobias Grimm]

I'm working on it and will upload a new version soon.

Tobias

On 03.11.2016 19:53, Thomas Renard wrote:

> Package: kodi-pvr-vdr-vnsi
> Version: 1.11.15-1
> Severity: normal
> 
> Dear Maintainer,
> 
> with upgrade to 17.0~beta5 this addon does not work anymore. Log output:
> 
> ERROR: PVR - Add-on 'VDR VNSI Client' is using an incompatible API
> version. XBMC minimum API version = '5.2.0', add-on API version '4.1.0'
> 
> At the frontend:
> 
>  * select tv
>  * (No pvr addon enabled dialog -> Ok)
>  * Select Enter add-on browser
>  * Select VDR Vnsi Client
>  * (if not done in former version:) Config server settings
>  * Select Activate
> 
> Expected:
> 
>  * TV database is setup
>  * You can play vdr stuff
> 
> Actual behavior:
> 
>  * Dialog: Add-on could'nt be loaded (check the log)
> 
> -- System Information:
> Debian Release: stretch/sid
>   APT prefers testing
>   APT policy: (990, 'testing'), (500, 'unstable')
> Architecture: amd64 (x86_64)
> 
> Kernel: Linux 3.16.0-4-amd64 (SMP w/2 CPU cores)
> Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
> 
> Versions of packages kodi-pvr-vdr-vnsi depends on:
> ii  kodi  17.0~beta5+dfsg1-1
> ii  libc6 2.24-5
> ii  libgcc1   1:6.2.0-10
> ii  libgl1-mesa-glx [libgl1]  12.0.3-3
> ii  libp8-platform2   2.0.1+dfsg1-2
> ii  libstdc++66.2.0-10
> 
> kodi-pvr-vdr-vnsi recommends no packages.
> 
> kodi-pvr-vdr-vnsi suggests no packages.
> 
> -- no debconf information
> 
> ___
> pkg-multimedia-maintainers mailing list
> pkg-multimedia-maintain...@lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
> 




signature.asc
Description: OpenPGP digital signature

Bug#819488: gparted crash with a libparted backtrace

[Sandro Tosi]

control: severity -1 important

On Thu, Nov 3, 2016 at 1:48 PM, Mattia Rizzolo  wrote:
> On Thu, Nov 03, 2016 at 11:37:02AM -0400, Sandro Tosi wrote:
>> Mattia, do you still consider this bug RC? thanks!
>
> I don't think so, no.  Though it's still a crash, it's important, but
> probably not RC indeed.

yup agreed on this, setting the severity accordingly


On Thu, Nov 3, 2016 at 4:34 PM, Phil Susi  wrote:
> On 11/3/2016 11:37 AM, Sandro Tosi wrote:
>> Phillip, did you have a chance to look at making parted not crashing
>> if there is only one unallocated sector between partitions? Mattia, do
>> you still consider this bug RC? thanks!
>
> I have not had time to work on it yet.

no worries!


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

Bug#843064: [Pkg-openssl-devel] Bug#843064: openssl: incompatibility for enc command between openssl 1.1.0b-2 and previous 1.0.x versions

[Marek Lukaszuk]

On 2016-11-03 21:12:10PM +0100, Sebastian Andrzej Siewior wrote:
> On 2016-11-03 15:59:25 [+0100], Marek Lukaszuk wrote:
> > passphrase I'm getting below error:
> > 
> >   > cat file_encrypted.dat | openssl enc -d -aes-256-cbc
> >   enter aes-256-cbc decryption password:
> >   bad decrypt
> >   139814539760704:error:06065064:digital envelope
> >   routines:EVP_DecryptFinal_ex:bad decrypt:crypto/evp/evp_enc.c:529:
> 
> bah. They changed the default digest from md5 to sha256 to create the
> key. If you add '-md md5' to your 1.1. openssl then it will work. The
> other way around you need '-md sha256' to keep 1.0 happy.

Thanks, it works, I feel like an idiot for not finding this.

> Let me see what upstream says…

It is a bit of a surprise, normally I would argue for a bit more clear error
message but in this case I'm not sure if that would be ok.

Either way, thank you for a very quick answer.

Marek 

Bug#843106: ITP: libjloda-java -- Java library of data structures and algorithms for bioinformatics

[Andreas Tille]

Package: wnpp
Severity: wishlist
Owner: Andreas Tille 

* Package name: libjloda-java
  Version : 0.0+20161018
  Upstream Author : Daniel Huson 
* URL : https://github.com/danielhuson/jloda
* License : GPL
  Programming Lang: Java
  Description : Java library of data structures and algorithms for 
bioinformatics
 The jloda Java library provides some basic data structures and
 algorithms used by bioinformatics applications like SplitsTree,
 Dendroscope and MEGAN.


Remark: This Java library is needed to package MALT and MEGAN which are
two well known programs in bioinformatics and recently published under
a free license.  It will be maintained by the Debian Med team at
   https://anonscm.debian.org/git/debian-med/libjloda-java.git

Bug#828299: fetchmail: FTBFS with openssl 1.1.0

[GCS]

On Thu, Nov 3, 2016 at 8:48 PM, Sebastian Andrzej Siewior
 wrote:
> On 2016-11-03 07:45:16 [+0100], Andreas Henriksson wrote:
> fetchmail builds against openssl 1.1.0. So we are good here.
> fetchmail fails to build with -j4.
> What do we do now? I retitled the bug. Can you reproduce this on your
> end?
 Nope. Tried in a loop of ten with -j2, other ten with -j4 and another
ten with -j8 and it was working correctly. What's the result / current
problem at your end?

Laszlo/GCS

Bug#828299: fetchmail: FTBFS with openssl 1.1.0

[Andreas Henriksson]

Hello Sebastian Andrzej Siewior.

On Thu, Nov 03, 2016 at 08:48:04PM +0100, Sebastian Andrzej Siewior wrote:
> control: retitle: -1 fetchmail: FTBFS if building in parallel
> 
> On 2016-11-03 07:45:16 [+0100], Andreas Henriksson wrote:
> > Hello Kurt Roeckx.
> Hi,
> 
> > The failure in this build log didn't look like it was really openssl 
> > related.
> > I've tried rebuilding the package which succeded for me.
> > 
> > Could you please double-check here and possibly close this bug report
> > if there's no issue?
> 
> fetchmail builds against openssl 1.1.0. So we are good here.
> fetchmail fails to build with -j4.
> What do we do now? I retitled the bug. Can you reproduce this on your
> end?

Disclaimer: I'm not the maintainer.

(And your retitle seems to have failed? One too many : after retitle?)
(And as already mentioned to Kurt, you might want to unblock the openssl
transition as well as this bug is not related to openssl.)

It seems build-arch depends on configure-stamp and build-stamp. The
latter two gets executed in parallel which results in build-stamp
getting executer before configure-stamp and thus the failure.

Since the fetchmail packaging currently uses a deprecated debhelper compat
level 7, preferrably it would get updated to a current level (and
switched to use the debhelper sequencer while at it).
While doing that upgrading/cleanup work on the packaging this bug will
likely go away.

Another (quick and dirty) option would be to completely disable parallel
execution of debian/rules, eg. by adding ".NOTPARALLEL:".

Another option that could also work is to make the build-stamp target
depend on configure-stamp hopefully fixes the parallelism bug and
probably a theoretically correct change no matter what.

Regards,
Andreas Henriksson

PS. Not volunteering for any of the above myself.

Bug#841904: [PKG-Openstack-devel] Bug#841904: swift: FTBFS with eatmydata (failing tests)

[Ondrej Novy]

Hi,

I have eatmydata in my env too and I can build this package fine. Sry, I
can't reproduce. Can you try it again please?

-- 
Best regards
 Ondřej Nový

Email: n...@ondrej.org
PGP: 3D98 3C52 EB85 980C 46A5  6090 3573 1255 9D1E 064B

Bug#819488: gparted crash with a libparted backtrace

[Phil Susi]

On 11/3/2016 11:37 AM, Sandro Tosi wrote:
> Phillip, did you have a chance to look at making parted not crashing
> if there is only one unallocated sector between partitions? Mattia, do
> you still consider this bug RC? thanks!

I have not had time to work on it yet.

Bug#821517: Fix from Ubuntu for the libgraphite-php FTBFS

[Adrian Bunk]

Control: tags -1 patch

The fix I found in Ubuntu for this bug is attached.

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

diff -pruN 1.5-1/debian/control 1.5-1ubuntu1/debian/control
--- 1.5-1/debian/control	2012-07-05 16:13:37.0 +
+++ 1.5-1ubuntu1/debian/control	2016-03-24 23:30:00.0 +
@@ -11,7 +12,7 @@ Homepage: http://graphite.ecs.soton.ac.u
 
 Package: libgraphite-php
 Architecture: all
-Depends: ${misc:Depends}, php5 (>= 5.0.0), libarc-php
+Depends: ${misc:Depends}, php, libarc-php
 Description: PHP Linked Data Library
  Graphite is a PHP RDF library, built on top of ARC2, which has been
  developed to make working with RDF easier and more fun.

Bug#843105: firefox: gtk3 causes extension popups to have odd size/placement

[Jeff King]

Package: firefox
Version: 49.0-5
Severity: normal

When I open a popup by clicking on an extension icon in a toolbar, the
new window is placed near the center of the screen, and is often too
small to hold the contents of the popup (whereas in 49.0-4, the window
is placed next to the icon and sized appropriately).

If I run in --safe-mode, obviously I have no extension icons, but if I
click the hamburger button or the boomarks button, the behavior is
similar. It appears in the center of the screen, though in both cases
the size is big enough to hold the contents (however, it's the same size
as the non-working cases. It may just be that this is big enough for
those dialogs, whereas something like uMatrix needs more space).

Given that this worked in 49.0-4 and has to do with window creation, I
can guess it's related to the switch to gtk3.

-- Package-specific info:

-- Extensions information
Name: BugMeNot Plugin
Location: ${PROFILE_EXTENSIONS}/{987311C6-B504-4aa2-90BF-60CC49808D42}.xpi
Status: enabled

Name: Dactyl Binary Utils
Location: ${PROFILE_EXTENSIONS}/binary
Status: user-disabled

Name: Default theme
Location: 
/usr/lib/firefox/browser/extensions/{972ce4c6-7e08-4474-a285-3208198ce6fd}.xpi
Package: firefox
Status: enabled

Name: Google Redirects Fixer
Location: ${PROFILE_EXTENSIONS}/jid1-zurvdcat3xo...@jetpack.xpi
Status: enabled

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

Name: Multi-process staged rollout
Location: ${PROFILE_EXTENSIONS}/e10sroll...@mozilla.org.xpi
Status: enabled

Name: PassFF
Location: ${PROFILE_EXTENSIONS}/pas...@invicem.pro.xpi
Status: enabled

Name: Pentadactyl
Location: ${PROFILE_EXTENSIONS}/pentadac...@dactyl.googlecode.com.xpi
Status: enabled

Name: Pocket
Location: ${PROFILE_EXTENSIONS}/fire...@getpocket.com.xpi
Status: user-disabled

Name: uBlock Origin
Location: ${PROFILE_EXTENSIONS}/ublo...@raymondhill.net.xpi
Status: enabled

Name: uMatrix
Location: ${PROFILE_EXTENSIONS}/umat...@raymondhill.net.xpi
Status: enabled

Name: Web Compat
Location: ${PROFILE_EXTENSIONS}/webcom...@mozilla.org.xpi
Status: enabled

-- Plugins information
Name: Shockwave Flash (11.2.202.643)
Location: /usr/lib/flashplayer-mozilla/libflashplayer.so
Package: flashplayer-mozilla
Status: enabled


-- Addons package information
ii  firefox49.0-5   amd64Mozilla Firefox web browser
ii  flashplayer-mo 3:11.2.202.6 amd64Macromedia Flash Player

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

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

Versions of packages firefox depends on:
ii  debianutils   4.8
ii  fontconfig2.11.0-6.7
ii  libasound21.1.2-1
ii  libatk1.0-0   2.22.0-1
ii  libc6 2.24-5
ii  libcairo-gobject2 1.14.6-1+b1
ii  libcairo2 1.14.6-1+b1
ii  libdbus-1-3   1.10.12-1
ii  libdbus-glib-1-2  0.108-1
ii  libevent-2.0-52.0.21-stable-2.1
ii  libffi6   3.2.1-6
ii  libfontconfig12.11.0-6.7
ii  libfreetype6  2.6.3-3+b1
ii  libgcc1   1:6.2.0-10
ii  libgdk-pixbuf2.0-02.36.0-1
ii  libglib2.0-0  2.50.1-1
ii  libgtk-3-03.22.2-1
ii  libgtk2.0-0   2.24.31-1
ii  libhunspell-1.4-0 1.4.1-2+b1
ii  libnspr4  2:4.12-6
ii  libnss3   2:3.26.2-1
ii  libpango-1.0-01.40.3-3
ii  libsqlite3-0  3.15.0-1
ii  libstartup-notification0  0.12-4
ii  libstdc++66.2.0-10
ii  libvpx4   1.6.0-2
ii  libx11-6  2:1.6.3-1
ii  libxcomposite11:0.4.4-1
ii  libxdamage1   1:1.1.4-2+b1
ii  libxext6  2:1.3.3-1
ii  libxfixes31:5.0.2-1
ii  libxrender1   1:0.9.9-2
ii  libxt61:1.1.5-1
ii  procps2:3.3.12-2
ii  zlib1g1:1.2.8.dfsg-2+b3

firefox recommends no packages.

Versions of packages firefox suggests:
pn  fonts-lmodern  
pn  fonts-stix | otf-stix  
pn  libcanberra0   
pn  libgnomeui-0   
ii  libgssapi-krb5-2   1.15~beta1-1
pn  mozplugger 

-- no debconf information

Bug#843055: sndio FTCBFS: uses build architecture compiler

[Peter Piwowarski]

On Thu, 3 Nov 2016 14:35:48 +0100
Helmut Grohne  wrote:

> Source: sndio
> Version: 1.1.0-2
> Tags: patch
> User: helm...@debian.org
> Usertags: rebootstrap
> 
> sndio fails to cross build from source, because it uses the build
> architecture compiler and ultimately fails finding libraries which are
> requested for the host architecture. Simply passing a triplet-prefixed
> compiler (which works both cross and natively) to configure fixes the
> build. Please consider applying the attached patch.
> 
> Helmut

Thank you for the report and patch. I've been busy enough lately that I
can't make any promises, but I think I can have an upload prepared
sometime this weekend.

Bug#843104: firefox: gtk3 makes fonts tiny on hi-dpi display

[Jeff King]

Package: firefox
Version: 49.0-5
Severity: normal

Since the move to GTK3 in 49.0-5, the fonts and widgets on my hi-dpi
(3840x2160, 240dpi) display are tiny. The actual rendered content is
sized as it was with GTK2.

This is the case even when run in --safe-mode; the dialog asking to
confirm running in safe-mode has small fonts and buttons.

Setting GDK_SCALE=2 improves the situation, but my understanding is that
this is supposed to happen automatically. This seems to be a gtk3 thing,
as installing gtk-3-examples and running gtk3-demo shows the same
problem. So I doubt there's a particular bug to fix on the _firefox_
side, but it is a potential data point against enabling gtk3 (i.e., from
my perspective it's a regression in firefox).

-- Package-specific info:

-- Extensions information
Name: BugMeNot Plugin
Location: ${PROFILE_EXTENSIONS}/{987311C6-B504-4aa2-90BF-60CC49808D42}.xpi
Status: enabled

Name: Dactyl Binary Utils
Location: ${PROFILE_EXTENSIONS}/binary
Status: user-disabled

Name: Default theme
Location: 
/usr/lib/firefox/browser/extensions/{972ce4c6-7e08-4474-a285-3208198ce6fd}.xpi
Package: firefox
Status: enabled

Name: Google Redirects Fixer
Location: ${PROFILE_EXTENSIONS}/jid1-zurvdcat3xo...@jetpack.xpi
Status: enabled

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

Name: Multi-process staged rollout
Location: ${PROFILE_EXTENSIONS}/e10sroll...@mozilla.org.xpi
Status: enabled

Name: PassFF
Location: ${PROFILE_EXTENSIONS}/pas...@invicem.pro.xpi
Status: enabled

Name: Pentadactyl
Location: ${PROFILE_EXTENSIONS}/pentadac...@dactyl.googlecode.com.xpi
Status: enabled

Name: Pocket
Location: ${PROFILE_EXTENSIONS}/fire...@getpocket.com.xpi
Status: user-disabled

Name: uBlock Origin
Location: ${PROFILE_EXTENSIONS}/ublo...@raymondhill.net.xpi
Status: enabled

Name: uMatrix
Location: ${PROFILE_EXTENSIONS}/umat...@raymondhill.net.xpi
Status: enabled

Name: Web Compat
Location: ${PROFILE_EXTENSIONS}/webcom...@mozilla.org.xpi
Status: enabled

-- Plugins information
Name: Shockwave Flash (11.2.202.643)
Location: /usr/lib/flashplayer-mozilla/libflashplayer.so
Package: flashplayer-mozilla
Status: enabled


-- Addons package information
ii  firefox49.0-5   amd64Mozilla Firefox web browser
ii  flashplayer-mo 3:11.2.202.6 amd64Macromedia Flash Player

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

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

Versions of packages firefox depends on:
ii  debianutils   4.8
ii  fontconfig2.11.0-6.7
ii  libasound21.1.2-1
ii  libatk1.0-0   2.22.0-1
ii  libc6 2.24-5
ii  libcairo-gobject2 1.14.6-1+b1
ii  libcairo2 1.14.6-1+b1
ii  libdbus-1-3   1.10.12-1
ii  libdbus-glib-1-2  0.108-1
ii  libevent-2.0-52.0.21-stable-2.1
ii  libffi6   3.2.1-6
ii  libfontconfig12.11.0-6.7
ii  libfreetype6  2.6.3-3+b1
ii  libgcc1   1:6.2.0-10
ii  libgdk-pixbuf2.0-02.36.0-1
ii  libglib2.0-0  2.50.1-1
ii  libgtk-3-03.22.2-1
ii  libgtk2.0-0   2.24.31-1
ii  libhunspell-1.4-0 1.4.1-2+b1
ii  libnspr4  2:4.12-6
ii  libnss3   2:3.26.2-1
ii  libpango-1.0-01.40.3-3
ii  libsqlite3-0  3.15.0-1
ii  libstartup-notification0  0.12-4
ii  libstdc++66.2.0-10
ii  libvpx4   1.6.0-2
ii  libx11-6  2:1.6.3-1
ii  libxcomposite11:0.4.4-1
ii  libxdamage1   1:1.1.4-2+b1
ii  libxext6  2:1.3.3-1
ii  libxfixes31:5.0.2-1
ii  libxrender1   1:0.9.9-2
ii  libxt61:1.1.5-1
ii  procps2:3.3.12-2
ii  zlib1g1:1.2.8.dfsg-2+b3

firefox recommends no packages.

Versions of packages firefox suggests:
pn  fonts-lmodern  
pn  fonts-stix | otf-stix  
pn  libcanberra0   
pn  libgnomeui-0   
ii  libgssapi-krb5-2   1.15~beta1-1
pn  mozplugger 

-- no debconf information

Bug#786433: NMU in RFS

[Dan Mick]

I've created an update to the package, and requested a sponsor:

https://bugs.debian.org/842429

Bug#843088: RFS: golang-github-fatih-color/1.0.0-2~bpo8+1

[Gianfranco Costamagna]

Hi,

>  * Rebuild for jessie-backports.


soon


G.

Bug#843103: RM: polybori -- ROM; NVIU

[Tobias Hansen]

Package: ftp.debian.org
Severity: normal

Dear FTP team,

please remove the source package polybori from unstable. The package was
renamed to brial, but brial does not build all the binary packages of
polybori.

Thanks,
Tobias

Bug#827160: jessie-pu: package dosfstools/3.0.27-1+deb8u1

[Petter Reinholdtsen]

Control: tags -1 -moreinfo

I believe I have provided all the requested information, and is
unsure how much of my proposed changes is accepted by the release
managers.  Can someone let me know what the status of this proposal is?

-- 
Happy hacking
Petter Reinholdtsen

Bug#843037: python-testtools: New upstream 2.2.0 available

[Free Ekanayaka]

Hi Thomas,

On 3 November 2016 at 20:25, Thomas Goirand  wrote:

> On 11/03/2016 12:08 PM, Free Ekanayaka wrote:
> > Package: python-testtools
> > Version: 1.8.0-4
> > Severity: normal
> >
> > The 1.8.0 release is over a year old. In the meantime several bug
> > fixes and improvements have landed upstream and are available in
> > the 2.2.0 release, so we should upgrade the Debian package.
> >
> > If you wish, I volunteer for co-maintainership or even simply an
> > ad-hoc NMU.
>
> I'm not sure if it is such a good idea to upgrade testtools just before
> the freeze of Stretch. Maybe we'd better upload it to Experimental?
>

As mentioned, the 2.2.0 release is definitely an improvement over the
1.8.0, with bug fixes even. For a stable release like Stretch, I would
rather prefer to see 2.2.0 in it than 1.8.0.

For example unit tests for 2.2.0 are fully green on Debian/sid, both on
Python 2 and Python 3, while unit tests for 1.8.0 have several breakages.

See these links to see the bugs that have been address in over a year:

https://launchpad.net/testtools/+milestone/1.9.0
https://launchpad.net/testtools/trunk/1.8.1
https://launchpad.net/testtools/trunk/2.0.0
https://launchpad.net/testtools/trunk/2.1.0
https://github.com/testing-cabal/testtools/issues?q=is%3Aissue+is%3Aclosed

Free

Bug#843064: [Pkg-openssl-devel] Bug#843064: openssl: incompatibility for enc command between openssl 1.1.0b-2 and previous 1.0.x versions

[Sebastian Andrzej Siewior]

On 2016-11-03 15:59:25 [+0100], Marek Lukaszuk wrote:
> passphrase I'm getting below error:
> 
>   > cat file_encrypted.dat | openssl enc -d -aes-256-cbc
>   enter aes-256-cbc decryption password:
>   bad decrypt
>   139814539760704:error:06065064:digital envelope
>   routines:EVP_DecryptFinal_ex:bad decrypt:crypto/evp/evp_enc.c:529:

bah. They changed the default digest from md5 to sha256 to create the
key. If you add '-md md5' to your 1.1. openssl then it will work. The
other way around you need '-md sha256' to keep 1.0 happy.

Let me see what upstream says…

Sebastian

Bug#833754: xerces-c: FTBFS on s390x with gcc6/icu57

[Sandro Tosi]

On Mon, 8 Aug 2016 13:24:48 + Mattia Rizzolo  wrote:
> source: xerces-c
> version: 3.1.3+debian-2.1
> severity: serious
>
> Dear maintainer,
>
> your package failed to build on buildds on the s390x architecure only
> during a rebuild for the transition to icu57, using gcc6 as compiler.
> You can see the build log at:
> https://buildd.debian.org/status/fetch.php?pkg=xerces-c=s390x=3.1.3%2Bdebian-2.1%2Bb1=1470418530

Hey William, did you have a chance to look at this bug? i couldnt find
much on the upstream bug tracker but there is also a 3.1.4 new release
you might want to test if fixes this bug else report it upstream.
thanks!!

Bug#840942: jessie-pu: package isenkram/0.18+deb8u1

[Petter Reinholdtsen]

Hi.  Did anyone have time to look at the isenkram patch for Jessie?

-- 
Happy hacking
Petter Reinholdtsen

Bug#843091: otrs2: CVE-2016-9139

[Patrick Matthäi]

Am 03.11.2016 um 19:48 schrieb Salvatore Bonaccorso:
> Source: otrs2
> Version: 3.3.9-1
> Severity: important
> Tags: security upstream fixed-upstream
>
> Hi,
>
> the following vulnerability was published for otrs2.
>
> CVE-2016-9139[0]:
> |An attacker could trick an authenticated agent or customer into opening
> |a malicious attachment which could lead to the execution of JavaScript
> |in OTRS context
>
> If you fix the vulnerability please also make sure to include the
> CVE (Common Vulnerabilities & Exposures) id in your changelog entry.
>
> For further information see:
>
> [0] https://security-tracker.debian.org/tracker/CVE-2016-9139
> [1] https://www.otrs.com/security-advisory-2016-02-security-update-otrs/
>
> Please adjust the affected versions in the BTS as needed.
>

Hi,

yeah already saw it and stable is affected also. Upstream says the
severity is low and I also would say IMHO that this is no candidate for
a jessie security update. What do you think?

Bug#843102: exiv2 FTCBFS: build-depends on host architecture python

[Helmut Grohne]

Source: exiv2
Version: 0.25-3
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap

exiv2 fails to cross build from source, because it build depends on the
host architecture python, which is neither installable nor executable.
Fortunately, python is only needed as a build tool, so we should request
it for the build architecture by annotating it with :native or :any.
After doing so, exiv2 cross builds successfully. Please consider
applying the attached patch.

Helmut
diff --minimal -Nru exiv2-0.25/debian/changelog exiv2-0.25/debian/changelog
--- exiv2-0.25/debian/changelog 2016-05-18 18:38:05.0 +0200
+++ exiv2-0.25/debian/changelog 2016-11-03 21:00:09.0 +0100
@@ -1,3 +1,10 @@
+exiv2 (0.25-3.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: Annotate python build dependency with :native (Closes: #-1)
+
+ -- Helmut Grohne   Thu, 03 Nov 2016 20:59:56 +0100
+
 exiv2 (0.25-3) unstable; urgency=medium
 
   [ Norbert Preining ]
diff --minimal -Nru exiv2-0.25/debian/control exiv2-0.25/debian/control
--- exiv2-0.25/debian/control   2016-05-18 18:38:05.0 +0200
+++ exiv2-0.25/debian/control   2016-11-03 20:59:55.0 +0100
@@ -7,7 +7,7 @@
chrpath,
debhelper (>= 9~),
libexpat1-dev,
-   python,
+   python:native,
xsltproc,
zlib1g-dev,
pkg-kde-tools

Bug#797236: cifs-utils: share disconnects after time

[Mathieu Parent]

On Fri, 28 Aug 2015 15:34:54 -0400 westlake  wrote:
> Package: cifs-utils
> Version: 2:6.4-1
> Severity: normal

Hello,

Sorry for this late reply.

> the network shares auto-disconnect themselves after a certain amount of
> time, happens after a couple of hourse but it occurs at least twice a
> day.. not sure why this happens but it's never showed up on wheezy.

All shares at the same time?

Anything in /var/log/syslog?

> this has actually been going on ever since I updated to jessie, .. not
> sure where to look in the logs, but nothing seems to show up

Which machine was upgraded to jessie? server or client?

> i'd really like to investigate this but I double checked things -- the
> mountpoints automatically load up properly on systemboot, the system
> does not go to sleep when these mountpoints get disconnected, and the
> servers on the otherside are always on, there's nothing between 2
> servers and this workstation other than a switch box so there can't be a
> networking issue.
>
> anyone else experience this issue?  couldn't find another bug related to
> this.
>
> here i'm using the following with /etc/fstab
[snip]

Regards

Mathieu Parent

Bug#815231: cmake: FTBFS on kfreebsd, hurd: 2 tests fail: BuildDepends, RunCMake.Configure

[Julian Andres Klode]

On Thu, Nov 03, 2016 at 04:57:00PM +, Steven Chamberlain wrote:
> Hello,
> 
> > Julian Andres Klode wrote:
> > > Any update on this? This bug is preventing the kFreeBSD platforms
> > > from getting a newer APT version, as APT requires cmake (>= 3.4)
> > > to build. Because of this, APT is at 1.3~pre3 from two months
> > > ago, whereas the other platforms are at 1.3.1 already.
> 
> Steven Chamberlain wrote:
> > In the meantime, I believe I *could* build cmake on the porterboxes,
> > perhaps with DEB_BUILD_OPTS=nocheck and nmu those binaries.  It doesn't
> > fix the bug, would come back again with the next build, but it should
> > fix *many* reverse-deps that are FTBFS or BD-Uninstallable waiting for a
> > newer cmake.
> 
> I did that, but now apt FTBFS on kfreebsd-* with this test failure:
> 
> https://buildd.debian.org/status/fetch.php?pkg=apt=kfreebsd-amd64=1.3.1=1478121955
> 
> | [ RUN  ] FileUtlTest.GetTempDir
> | /«PKGBUILDDIR»/test/libapt/fileutl_test.cc:260: Failure
> | Value of: GetTempDir()
> |   Actual: "/tmp"
> | Expected: "/var/tmp"
> | [  FAILED  ] FileUtlTest.GetTempDir (0 ms)

Seems like /var/tmp is not rwx for the buildd user. It worked fine
on Linux and (real) FreeBSD last time I tried

-- 
Debian Developer - deb.li/jak | jak-linux.org - free software dev

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

Bug#828550: socat: FTBFS with openssl 1.1.0

[GCS]

On Thu, Nov 3, 2016 at 8:42 PM, Sandro Tosi  wrote:
> On Mon, 5 Sep 2016 10:53:05 +0200 Gerhard Rieger
>  wrote:
>> Thank you, I will check!
>
> hey Gerhard, do you have a plan to look at this soon (now that openssl
> 1.1.0 bugs are RC)? thanks!
 Anything wrong with Sebastian Andrzej Siewior's patch? I plan to use
if no one objects.

Laszlo/GCS

Bug#843101: python-hiredis: please make the build reproducible

[Reiner Herrmann]

Source: python-hiredis
Version: 0.2.0-1
Severity: wishlist
Tags: patch upstream
User: reproducible-bui...@lists.alioth.debian.org
Usertags: fileordering
X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org

Hi!

While working on the "reproducible builds" effort [1], we have noticed
that python-hiredis could not be built reproducibly.
During build objects are linked in non-deterministic order.

The attached patch fixes this by sorting the list of source files.

Regards,
 Reiner

[1]: https://wiki.debian.org/ReproducibleBuilds
diff --git a/debian/patches/reproducible-build.patch b/debian/patches/reproducible-build.patch
new file mode 100644
index 000..a5eb6f0
--- /dev/null
+++ b/debian/patches/reproducible-build.patch
@@ -0,0 +1,14 @@
+Author: Reiner Herrmann 
+Description: Sort source files for deterministic linking order
+
+--- a/setup.py
 b/setup.py
+@@ -44,7 +44,7 @@
+   "sources": ["vendor/hiredis/%s.c" % src for src in ("read", "sds")]})
+ 
+ ext = Extension("hiredis.hiredis",
+-  sources=glob.glob("src/*.c"),
++  sources=sorted(glob.glob("src/*.c")),
+   include_dirs=["vendor"],
+   extra_link_args=["-lhiredis"])
+ 
diff --git a/debian/patches/series b/debian/patches/series
index 6b075bc..1ab1e46 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -1,2 +1,3 @@
 0001-Use-system-libhiredis.patch
 fix_build_dir_in_tests.patch
+reproducible-build.patch


signature.asc
Description: PGP signature

Bug#841610: statsmodels: FTBFS: TypeError: cannot sort an Index object in-place, use sort_values instead

[Sandro Tosi]

* the Anova errors seem related to
https://github.com/statsmodels/statsmodels/issues/3228

* "ValueError: Inferred frequency MS from passed dates does not
conform to passed frequency M" could be related to the absence of
tzdata (but the last function of the stacktrace is in pandas so the
bug may be there)

* "TypeError: cannot sort an Index object in-place, use sort_values
instead" may or may not be a problem in pandas (since there was a
recent update of pandas you might want to retry and see if that fixed
them, if not maybe you can ask statsmodels upstream what they think

thanks!

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

Bug#828299: fetchmail: FTBFS with openssl 1.1.0

[Sebastian Andrzej Siewior]

control: retitle: -1 fetchmail: FTBFS if building in parallel

On 2016-11-03 07:45:16 [+0100], Andreas Henriksson wrote:
> Hello Kurt Roeckx.
Hi,

> The failure in this build log didn't look like it was really openssl related.
> I've tried rebuilding the package which succeded for me.
> 
> Could you please double-check here and possibly close this bug report
> if there's no issue?

fetchmail builds against openssl 1.1.0. So we are good here.
fetchmail fails to build with -j4.
What do we do now? I retitled the bug. Can you reproduce this on your
end?

> Regards,
> Andreas Henriksson

Sebastian

Bug#832260: closed by Youhei SASAKI <uwab...@gfd-dennou.org> (Bug#832260: fixed in tmuxinator 0.9.0-1)

[Ben Finney]

On 02-Nov-2016, Debian Bug Tracking System wrote:
> From: Youhei SASAKI 
> Subject: Bug#832260: fixed in tmuxinator 0.9.0-1
> […]
>* Change section: utils (Closes: #832260)

Thank you for addressing this in the source package.

Which bug report is requesting the correct section in the Debian
archive?

> Since the package is already in Debian with a different section, you
> will also need to submit a request to override the existing section
> .
> 
> Then mark this bug report as blocked by that new one, and be sure not
> to close this one until that new one is completed.

-- 
 \“[R]ightful liberty is unobstructed action, according to our |
  `\will, within limits drawn around us by the equal rights of |
_o__) others.” —Thomas Jefferson, 1819 |
Ben Finney 


signature.asc
Description: PGP signature