Bug#809198: maildirsync broken with perl 5.22

[Sebastian Schmidt]

Package: maildirsync
Version: 1.2-2
Severity: grave
Tags: upstream
Justification: renders package unusable

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

As of perl 5.22, “use UNIVERSAL (…)” is a fatal error:


% sed '13q;d' /usr/bin/maildirsync 
use UNIVERSAL qw(isa);
% /usr/bin/maildirsync
UNIVERSAL does not export anything at /usr/bin/maildirsync line 13.
BEGIN failed--compilation aborted at /usr/bin/maildirsync line 13.
%

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

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

Versions of packages maildirsync depends on:
ii  perl  5.22.1-3

Versions of packages maildirsync recommends:
ii  openssh-client [rsh-client]  1:7.1p1-5
ii  ssh  1:7.1p1-5

Versions of packages maildirsync suggests:
ii  bzip2  1.0.6-8

- -- no debconf information

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIVAwUBVoDrCvhx3EthBlqjAQj5+A//SBV+ucrjnZvbA7uTeyRppWYzeY2acIWg
FdWWQ+y9dlLOQN6DiI/2lBSDvnw7Rae7gIs4QPRV2xl2wZh1yvUVZ7NVU4EZAH03
t9ce7S6m4VPvDOokCnDPqOBLFJ6HwjUq2ahQymGVvjAW/dQh/1a0d2nfcsUbIyTU
eY/aToYZAMmVpF+zor9jeoo8+LliXUjwJQ3nHAB7wshNQhmPWaIYPJxsCAMhN/mU
BlwZCcrZeSO9o5QmfVOxDq8KiXRHbdnuhnDh1M64EyiUOM9czIVtwEISrvtAQhcZ
ULi8WWBI/v13OI9YeJz/9Ex77CgGe1XgaYs0eOP9lb8v5FQzgbLykyaX1Uqg6ukZ
N1lcNz1j8ZN7y40C3wLirnWTmMjJ4tEnwNdwgk7Vip5/cyMRCn0zz/LNP240ATC0
wxrtTzDcKBZl45dst/uABQbSI1ZWsphsfLN20qWbM05rmgkh9oiKnT5phr08vvZU
QWEt+5oN3jpSO+JJmP2zlE/4x1XhwnoypIvw1kHacwUKw+cneTfrlqft0kpd8Mfb
q4vsSxHhQr+rUTtibEIzurNtmUmZLilnnyUu3uQElivBeKgzhH7EKq6aTOCXESBC
ir01le7kBibugEV/ZAFX3k1F9woZ7aOdulKHpvrAq11jPjS2t/Ulq+Et1O/U9/KW
iwsTm6Z5nY8=
=kC6a
-END PGP SIGNATURE-

Bug#771838: [liblensfun0] New upstream version

[Torsten Bronger]

Hallöchen!

Evgeni Golov writes:

> On Wed, Aug 05, 2015 at 11:13:33PM +0200, Guus Sliepen wrote:
>
>> [...]
>> 
>> Ok, then I will cancel the current delayed upload and prepare one
>> with a version from git, and inform all reverse dependencies of
>> the impending change. Unless the real maintainers wake up of
>> course.
>
> was there any progress on this? I've not seen anything in the
> pkg-kde SVN.  (asking with my gimp-lensfun maintainer hat on, as
> the new g-l release needs newer lensfun)
>
> would be willing to help, not liking maintaining libs, though ;)

Well, Lensfun 0.3.2 passed the buck to the Debian maintainers.

FWIW, there is a branch debian-packaging in the original Lensfun Git
repo, in which the Lensfun maintainer made a provisional packaging
to see whether the Lensfun code and especially the build system are
Debian-compatible.  It is a throw-away branch by people not really
famliar with Debian packaging guidelines, but it may serve as a
starting point.

Tschö,
Torsten.

-- 
Torsten BrongerJabber ID: torsten.bron...@jabber.rwth-aachen.de

Bug#799674: Properly document l/ll length modifier for double/long double argument

[Mathieu Malaterre]

On Sat, Dec 26, 2015 at 4:54 PM, Michael Kerrisk (man-pages)
 wrote:
> (Upstream mainatiner here.)
>
> On 09/21/2015 03:08 PM, Mathieu Malaterre wrote:
>> Package: manpages-dev
>> Version: 3.65-1
>> Severity: wishlist
>>
>> Currenly the man page for *printf family is difficult to read with
>> regards to float, double and long double printing. The man page for
>> *scanf family is much clearer. AFAIK there is a confusion with an old
>> C89 behavior, since C99 the actual way to print a double is "lf" and
>> "llf" for long double.
>>
>> Right now it reads as:
>>
>>   l  (ell) A following integer conversion corresponds to a
>> long int or unsigned long int argument, or a following n conversion
>> corresponds to a pointer to a long int argument,  or  a  following  c
>>   conversion corresponds to a wint_t argument, or a
>> following s conversion corresponds to a pointer to wchar_t argument.
>>
>> Accordingly 'll' and 'L' may need to be updated.
>
> So, I looked at this report, and I can't understand what the problem
> is that is being reported. What precisely do you think needs fixing?

It should be clear from the documentation that one should use "lf" to
print/scan to/from a double.

I'll copy/paste a better written comment from SO

[...]
Since С99 the matching between format specifiers and floating-point
argument types in C is consistent between printf and scanf. It is

%f for float
%lf for double
%Lf for long double

However, when arguments of type float are passed to variadic functions
(as variadic parameters) such arguments are implicitly converted to
type double. This is the reason why in printf format specifiers %f and
%lf are equivalent and interchangeable. In printf you can "cross-use"
%lfwith float or %f with double.

But there's no reason to actually do it in practice. Don't use %f to
printf arguments of type double. It is a widespread habit born back in
C89/90 times, but it is a bad habit. Use %lf in printffor double and
keep %f reserved for float arguments.


http://stackoverflow.com/a/28222471/136285
[...]

Bug#809195: network-manager_1.0.10-1_amd64.deb does not update my I.P address correctly when I start my VPN

[peter]

Package: network-manager
Version: 1.0.10-1
Severity: important

Dear Maintainer,


Hallo

When I start my VPN network-manager_1.0.10-1 does not update my IP address
correctly , as shown by using  various IP address check sites i.e :

https://whoer.net/

http://www.iplocationfinder.com/


These websites continue to show my ISP provider IP address.

If I return to using network-manager_1.0.8-2 my VPN IP address is shown as
having been updated correctly .

My system is fully up to date



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

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

Versions of packages network-manager depends on:
ii  adduser3.113+nmu3
ii  dbus   1.10.6-1
ii  init-system-helpers1.24
ii  isc-dhcp-client4.3.3-5
ii  libbluetooth3  5.36-1
ii  libc6  2.21-6
ii  libdbus-1-31.10.6-1
ii  libdbus-glib-1-2   0.102-1
ii  libglib2.0-0   2.46.2-3
ii  libgnutls-deb0-28  3.3.18-1
ii  libgudev-1.0-0 230-2
ii  libmm-glib01.4.12-1
ii  libndp01.4-2
ii  libnewt0.520.52.18-1+b1
ii  libnl-3-2003.2.26-1
ii  libnl-genl-3-200   3.2.26-1
ii  libnl-route-3-200  3.2.26-1
ii  libnm0 1.0.10-1
ii  libpam-systemd 228-2+b1
ii  libpolkit-agent-1-00.105-14
ii  libpolkit-gobject-1-0  0.105-14
ii  libreadline6   6.3-8+b4
ii  libsoup2.4-1   2.52.2-1
ii  libsystemd0228-2+b1
ii  libteamdctl0   1.18-1
ii  libuuid1   2.27.1-1
ii  lsb-base   9.20150917
ii  policykit-10.105-14
ii  udev   228-2+b1
ii  wpasupplicant  2.3-2.3

Versions of packages network-manager recommends:
ii  crda3.13-1+b1
pn  dnsmasq-base
ii  iptables1.4.21-2+b1
pn  iputils-arping  
ii  modemmanager1.4.12-1
ii  ppp 2.4.7-1+1

Versions of packages network-manager suggests:
pn  avahi-autoipd  
pn  libteam-utils  

-- Configuration Files:
/etc/NetworkManager/NetworkManager.conf changed [not included]

-- no debconf information

Bug#809196: sip-tester: Update to current version 3.4

[Achim Schaefer]

Package: sip-tester
Version: 1:3.2-1+b2
Severity: normal

Dear Maintainer,

there is a new version availible: 3.4

Looks like upstream switched from sf to github:
https://github.com/SIPp/sipp/releases

Thanks

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

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

Versions of packages sip-tester depends on:
ii  libc62.21-6
ii  libgcc1  1:5.3.1-4
ii  libgsl0ldbl  1.16+dfsg-4
ii  libncurses5  6.0+20151024-2
ii  libpcap0.8   1.7.4-2
ii  libstdc++6   5.3.1-4
ii  libtinfo56.0+20151024-2

sip-tester recommends no packages.

sip-tester suggests no packages.

-- no debconf information

Bug#809166: networking.service does not prevent ifdown with network file systems

[Martin Pitt]

Hey Guus,

Guus Sliepen [2015-12-27 20:50 +0100]:
> Please check if the problem still exists with version 0.8.4. Version 0.8
> didn't correctly order itself with respect to network-online.target, but
> 0.8.4 should have fixed that.

This should be unrelated to network-online.target. networking.service
has "Conflicts=shutdown.target" and thus will always be stopped during
shutdown/reboot, you can see

  [  OK  ] Stopped Raise network interfaces.

So with NFS or iscsi this will now mean that shutdown will be rather
broken/hanging after that point.

I don't have an iscsi installation handy right now, but I can set one
up. I filed this as I was reviewing networking.service with Michael
and we noticed that this functionality was gone, and I also got a
report that this regressed with latest systemd
(https://launchpad.net/bugs/1492546) -- that's an independent
regression though, and I'll handle that.

So maybe the effects with this are bearable, I didn't yet investigate
it on an actually affected system. So please feel free to close if you
are convinced that this check isn't necessary any more, I mostly filed
this as a reminder.

Thanks,

Martin
-- 
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)


signature.asc
Description: Digital signature

Bug#806532: [Letsencrypt-devel] Bug#806532: FTBFS on jessie

[Francois Marier]

On 2015-12-28 at 07:44:01, Daniel Pocock wrote:
> Yes, I was in a repository with a ".git" directory
> 
> I frequently build packages that way when I am tinkering with them so it
> would be good to find a way to support that reliably.  Maybe upstream
> needs to test for some environment variable or the existence of some
> other file that tells it not to do this ChangeLog update.

Thanks for confirming. I agree that the check done upstream could be better
though I'm not sure exactly what it should be.

Francois

-- 
http://fmarier.org/

Bug#809169: [PATCH] Allow setting the MTU and HWADDR on manual interfaces

[Martin Pitt]

Hey Guus,

Guus Sliepen [2015-12-27 20:54 +0100]:
> Thanks a lot, I applied the patch and pushed it!

Cool, thanks! Please note that the patch did not add a changelog
entry, sorry about that. Can you please add that and Closes: #809169?

Thanks,

Martin
-- 
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)


signature.asc
Description: Digital signature

Bug#809171: Please handle network device hotplug events (move from udev)

[Martin Pitt]

Hello Guus,

Guus Sliepen [2015-12-27 23:11 +0100]:
> >  * An udev rule which reacts to adding or removing network devices.
> >This is currently shipped as /lib/udev/rules.d/80-networking.rules
> >but I propose that ifupdown ships it as
> >/lib/udev/rules.d/80-ifupdown.rules to avoid a package file
> >conflict and also to make it clearer that this applies to ifupdown
> >only. I attach this as 80-ifupdown.rules.
> 
> I think we can also keep it as it is and use Replaces and Breaks
> headers in the control file. Each has its drawbacks. If there is both
> 80-networking.rules and 80-ifupdown.rules, it seems to me like the
> ifupdown script will be called twice for each hotplug event. But I agree
> it will be clearer if it is called 80-ifupdown.rules.

Right, as we'll need a Breaks: between versions anyway it's fine to
rename it. These are not conffiles either. Also, the called script
is robust against being called several times, so if that happens
during the package upgrade it's fine.

> Ok, that's basically just a copy of /lib/udev/net.agent. Why was
> /lib/udev/hotplug.functions pasted into it instead of sourced?

In order to make the migration easier, I eliminated hotplug.functions
from udev yesterday and pasted the relevant parts into net.agent:

  http://anonscm.debian.org/cgit/pkg-systemd/systemd.git/commit/?id=018671ca10a

net.agent was the only thing that still used hotplug.functions, and
there's no point carrying this around further -- it's better for udev
helpers to be self-contained if they move to other binary packages.

> Ok, so we'll have a file conflict in any case.

Yes, unless we rename ifup@.service to something like
ifupdown@.service, or if-device@.service. Then we could even run the
two versions side by side. But as it's a bit of a waste to run both,
and people may have gotten used to/depending on ifup@.service, I think
it's cleaner to just keep the name and do that lockstep transition if
that's alright with you.

> I can do this in the next release of ifupdown (0.8.5). I'll need to
> know which version of the udev package to sync with.

How about this: When you upload this, you add a Breaks:/Replaces: udev
(<< current version + 1~) and notify me on this bug, and I'll remove
the above files from udev right away in git (I'll prepare and stash
that right now). If you plan to do it in the next days you can use
228-3~ (we want to upload that RSN anyway and the dpkg upload that
Michael was waiting one apparently happened now). I didn't commit that
yet as I wanted to ask you first and wait for a possible discussion.

Thank you!

Martin
-- 
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)


signature.asc
Description: Digital signature

Bug#806532: [Letsencrypt-devel] Bug#806532: FTBFS on jessie

[Daniel Pocock]

On 28/12/15 07:40, Francois Marier wrote:
> On 2015-12-06 at 09:00:06, Daniel Pocock wrote:
>>> Are you sure you're trying this on a clean and up-to-date jessie system?
>>
>> Yes
>>
>> I had noticed that the gnulib package was required and was not mentioned
>> in the build-deps.  Could there be any other missing build dependency
>> that you have on your system but I don't have on mine?
> 
> So I took another look at this. Are you running "git pbuilder" directly in
> the package directory by any chance?
> 
> I just noticed this in README.distributors:
> 
> "To make this as easy as possible, setup.py does the following:
>   - create or refresh (overwriting) ChangeLog from ChangeLog.init and the Git
> log if there is a .git subdirectory in the current directory. This is very
> quick and done every time setup.py is run. For this to work,
> gitlog-to-changelog must be in the PATH and executable."
> 
> So basically, it's detecting you're in a git repo and (wrongly) assuming
> that it's the upstream repo so it runs through this unnecessary Changelog
> generation.
> 
> On the other hand, if you create a jessie LXC container and build from there
> using "gbp buildpackage", it never sees a .git directory and works just
> fine.
> 

Yes, I was in a repository with a ".git" directory

I frequently build packages that way when I am tinkering with them so it
would be good to find a way to support that reliably.  Maybe upstream
needs to test for some environment variable or the existence of some
other file that tells it not to do this ChangeLog update.

Bug#806532: [Letsencrypt-devel] Bug#806532: FTBFS on jessie

[Francois Marier]

On 2015-12-06 at 09:00:06, Daniel Pocock wrote:
> > Are you sure you're trying this on a clean and up-to-date jessie system?
> 
> Yes
> 
> I had noticed that the gnulib package was required and was not mentioned
> in the build-deps.  Could there be any other missing build dependency
> that you have on your system but I don't have on mine?

So I took another look at this. Are you running "git pbuilder" directly in
the package directory by any chance?

I just noticed this in README.distributors:

"To make this as easy as possible, setup.py does the following:
  - create or refresh (overwriting) ChangeLog from ChangeLog.init and the Git
log if there is a .git subdirectory in the current directory. This is very
quick and done every time setup.py is run. For this to work,
gitlog-to-changelog must be in the PATH and executable."

So basically, it's detecting you're in a git repo and (wrongly) assuming
that it's the upstream repo so it runs through this unnecessary Changelog
generation.

On the other hand, if you create a jessie LXC container and build from there
using "gbp buildpackage", it never sees a .git directory and works just
fine.

Francois

-- 
http://fmarier.org/

Bug#809181: laptop-mode-tools: typo in /lib/udev/lmt-udev

[Ritesh Raj Sarraf]

On Sun, 2015-12-27 at 18:36 -0500, Kelsey Byers wrote:
> I've found a minor typo in /lib/udev/lmt-udev:
> 
> line 47 reads:
> 
>  exec > /dev/null 2>dev/null
> 
> which is missing the / before the second call of /dev/null
> 
> so it should read
> 
>  exec > /dev/null 2>/dev/null

Hello Kelsey,

Thank you for the bug report and the patch. This bug would have been
hard to spot. I've applied it on my git repo and it'll be part of next
release.

Ritesh

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



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

Bug#808626: boost1.58: ships empty binary packages on some archs

[Steve M. Robbins]

On Mon, 21 Dec 2015 17:56:12 +0200 Graham Inggs  wrote:
> Source: boost1.58
> Version: 1.58.0+dfsg-4.1
> 
> Hi Maintainer
> 
> In debian/rules it is made clear that libboost-context and
> libboost-coroutine are not built for all architectures:
> 
> # context is conditionally compiled because it is not supported yet on
> several architectures
> # coroutine depends on context, so it is also conditionally compiled
> 
> In particular, these libraries are not built for the supported
> architectures arm64 and s390x.
> However, boost1.58 still ships empty binary packages
> libboost-context1.58.0, libboost-context1.58-dev and
> libboost-coroutine1.58-dev for these architectures.
> 
> This causes FTBFS in packages that build-depend on
> libboost-context-dev and liboost-coroutine-dev.  Fortunately, only
> kicad seems to be affected so far, see bug #807483.

I understand that the lack of Boost.Context support for certain architectures 
will cause software using Boost.Context to fail to build on those 
architectures.

I don't follow how the empty binary package is involved in the FTBFS.

-Steve


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

Bug#665334: non-DFSG postscript embedded in fontforge

[Hideki Yamane]

Hi,

>The originals of several of these functions seem to appear (with
>non-DFSG-free licensing) in the appendices of
>http://partners.adobe.com/public/developer/en/font/5015.Type1_Supp.pdf
>
>In particular, the licensing says:
>
 This code, as well as the code in the following appendices, is copyrighted 
 by
 Adobe Systems Incorporated, and may not be reproduced except by
 permission of Adobe Systems Incorporated. Adobe Systems Incorporated
 grants permission to use this code in Type 1 font programs, as long as the
 code is used as it appears in this document, the copyright notice remains
 intact, and the character outline code included in such a font program is
 neither copied nor derived from character outline code in any Adobe Systems
 font program.


>> https://github.com/fontforge/fontforge/blob/master/fontforge/othersubrs.c

This code seems to be based on
https://github.com/adobe-type-tools/afdko/tree/master/FDK/Tools/Programs/public/lib/source/t1write/t1write_flexothers.*
and now Adobe Font Development Kit for OpenType (AFDKO) is licensed under
Apache-2.0 license. Fontforge is licensed under GPL-3, so it's not a
problem to embedded it.

Thanks, Read and other folks in Adobe :)
Bug#665334 "non-DFSG postscript embedded in fontforge" is solved.



However, I don't know it is okay for other pfb files with license conflicts.
Apache-2.0 conflicts with GPL-2, at least, and it may conflict with
other license,
too.

Just "type 1 fonts include Adobe all right reserved code" is not a problem, but
if those type 1 fonts would be licensed under certain license like GPL-2 that
conflict with Apache-2.0...?

And, how can I think about fontforge copies snippet to generate those
*.pfb files?

It's for Bug#694308.

Bug#809178: [Letsencrypt-devel] Bug#809178: python-letsencrypt: version 0.1.1-3 not installable, because of missing python-letsencrypt-apache >= 0.1.1

[Achim Schaefer]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi Harlan,

since this morning I have the new package available, so you can close
this bug (sorry I have some trouble with bts commands...)
Don't know what changed, but now everything is fine.

Thanks

Achim
On 28.12.2015 01:38, Harlan Lieberman-Berg wrote:
> Achim Schaefer  writes:
>> I can not install the latest version, because the package
>> python-letsencrypt breaks python-letsencrypt-apache < 0.1.1, but there
>> is no verion >= 0.1.1 in the archive.
>
> Hi Achim,
>
> Are you trying to install the version in unstable, or the version in
> testing?
>
> If your system has both testing and unstable, apt may be having problems
> figuring out which distribution to use.  Can you paste the output of
> `apt-cache policy python-acme python-letsencrypt
> python-letsencrypt-apache`?
>
> Sincerely,
>

-BEGIN PGP SIGNATURE-
Version: GnuPG v2
Comment: Using GnuPG with Icedove - http://www.enigmail.net/

iEYEARECAAYFAlaA0j8ACgkQC2SZD53MXQlJgQCeOGalPjY9K5MI5c/34cwR2gDG
6g4An0CHq7ulp00BtpLiBYbrHeHq5++f
=Mo+R
-END PGP SIGNATURE-

Bug#798021: Boost numeric ublas storage.hpp has bug and doesn't work with GCC5

[Steve M. Robbins]

On Fri, 04 Sep 2015 16:23:56 +0200 Leopold Palomo-Avellaneda 
 wrote:
> Package: libboost1.58-dev
> Version: 1.58.0+dfsg-3 
> 
> Using libboost trying to compile ompl I have fount that the package doesn't 
> compile in unstable.
> 
> This bug is known by upstream (ompl) [1] and is similar that another with 
> patch from upstream (boost)[2]. However, [2] is applied to the debian 
package 
> but still fails because is not complete.
> 
> With this trivial patch proposed by upstream, the bug is solved. Please, 
could 
> you apply it?

Your patch looks like the reverse of 
http://anonscm.debian.org/viewvc/pkg-boost/boost/trunk/debian/patches/numeric-ublas-storage.hpp.patch?revision=14917&view=markup
 that was  applied in version 
1.58.0+dfsg-3.1.  Can you confirm that ompl now builds?  Or is something more 
required?

Thanks,
-Steve


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

Bug#809194: ITP: golang-github-docopt-docopt-go -- An implementation of docopt in the Go programming language.

[gustavo panizzo]

Package: wnpp
Severity: wishlist
Owner: gustavo panizzo 

* Package name: golang-github-docopt-docopt-go
  Version : 0.6.1
  Upstream Author : Keith Batten
* URL : http://docopt.org
* License : MIT/X
  Programming Lang: Go
  Description : An implementation of docopt in the Go programming language.

docopt helps you define an interface for your command-line app and
automatically generate a parser for it. Its interface descriptions are
based on a formalization of the standard conventions used in help
messages and man pages.

This package provides an implementation of docopt in the Go programming
language.

Bug#799666: [Pkg-ime-devel] Bug#799666: m17n-db: rfc1345 input method captures unrelated keystrokes

[Harshula]

On 23/12/15 17:16, Ben Finney wrote:


Please reverse this change, and restore the behaviour of earlier
versions: only enable input methods explicitly requested by the user.


I've emailed upstream to get their thoughts on this bug.

cya,
#

Bug#809018: [Letsencrypt-devel] Bug#809018: Bug#809018: please backport letsencrypt to jessie-backports

[Harlan Lieberman-Berg]

Eric Dorland  writes:
> Sorry if this was a duplicate or expressed better somewhere else, I
> didn't see any related reports.

Nope, not a duplicate!  There are some other bugs that I filed against
different packages requesting backports, but that's not the sort of
thing that would have been sane to expect you to find.

Thanks for filing this.  It's good to have a bug tracking the progress
of the backports, as a way to keep prodding me to check in with people.
I do hate seeing the bug count on my packages. =)

Sincerely,

-- 
Harlan Lieberman-Berg
~hlieberman

Bug#809192: libterm-termkey-perl: FTBFS: 05flags.t: Non-zero wait status: 11

[Salvatore Bonaccorso]

Hi,

On Mon, Dec 28, 2015 at 12:06:54AM -0500, Aaron M. Ucko wrote:
> Salvatore Bonaccorso  writes:
> 
> > Can you please attach the full build log?
> 
> Thanks for the quick reply!  The logs are all publically available at
> https://buildd.debian.org/status/package.php?p=libterm-termkey-perl, but
> for the record, I'm attaching a full copy of the (arm64) log I
> originally quoted.

Thanks and sorry for not having checked the public buildd logs (It
worked for me on the first rebuild attempt on amd64, so didn't deduced
that it might be on other architectures).

Regards,
Salvatore

Bug#809187: [Debian-med-packaging] Bug#809187: transdecoder: please make the build reproducible

[Michael Crusoe]

Thanks Charles!

Lun, 28 dec. 2015, 04:57, Charles Plessy  a scris:

> Control: tak -1 pending
>
> Le Mon, Dec 28, 2015 at 02:18:47AM +, Chris Lamb a écrit :
> >
> > Whilst working on the "reproducible builds" effort [0], we noticed that
> transdecoder could not be built reproducibly.
> >
> > Patch attached.
>
> Thanks,
>
> I applied the patch and forwared it upstream.
>
> https://github.com/TransDecoder/TransDecoder/pull/10
>
> To other Debian Med people: I do not have access to my GPG key from work,
> so I
> will not upload right now.  Anybody feel free :)
>
> Happy new year,
>
> --
> Charles
>
> --
Michael R. Crusoe CWL Community Engineer cru...@ucdavis.edu

Common Workflow Language projectUniversity of California, Davis
https://impactstory.org/MichaelRCrusoe http://twitter.com/biocrusoe

Bug#809192: libterm-termkey-perl: FTBFS: 05flags.t: Non-zero wait status: 11

[Aaron M. Ucko]

$key is defined
ok 6 - $key has refcount 1 after getkey()
ok 7 - $tk has refcount 2 after getkey()
ok 8 - push_bytes consumes 1 byte
ok 9 - get_buffer_remaining after push_bytes
ok 10 - getkey yields RES_KEY after h
ok 11 - $key->termkey after h
ok 12 - $key->type_is_unicode after h
ok 13 - $key->codepoint after h
ok 14 - $key->modifiers after h
ok 15 - $key->utf8 after h
ok 16 - $key->format after h
ok 17 - get_buffer_remaining getkey
ok 18 - getkey yields RES_NONE a second time
ok 19 - getkey yields RES_KEY after C-a
ok 20 - $key->type_is_unicode after C-a
ok 21 - $key->codepoint after C-a
ok 22 - $key->modifiers after C-a
ok 23 - $key->format after C-a
ok 24 - getkey yields RES_KEY after Up
ok 25 - $key->type_is_keysym after Up
ok 26 - $key->keysym after Up
ok 27 - $key->modifiers after Up
ok 28 - $key->format after Up
ok 29 - $key has refcount 1 before dropping
ok 30 - $tk has refcount 2 before dropping key
ok 31 - $k has refcount 1 before EOF
ok
t/03read.t .. 
1..19
ok 1 - $rd has refcount 1 initially
ok 2 - $tk has refcount 1 initially
ok 3 - $rd has refcount 2 after Term::TermKey->new
ok 4 - getkey yields RES_NONE when empty
ok 5 - $key is defined
ok 6 - $key has refcount 1 after getkey()
ok 7 - $tk has refcount 2 after getkey()
ok 8 - getkey yields RES_NONE before advisereadable
ok 9 - getkey yields RES_KEY after h
ok 10 - $key->termkey after h
ok 11 - $key->type_is_unicode after h
ok 12 - $key->codepoint after h
ok 13 - $key->modifiers after h
ok 14 - $key->utf8 after h
ok 15 - $key->format after h
ok 16 - getkey yields RES_NONE a second time
ok 17 - $k has refcount 1 before EOF
ok 18 - $rd has refcount 2 before dropping $tk
ok 19 - $rd has refcount 1 before EOF
ok
t/04parse_format.t .. 
1..18
ok 1 - ->parse_key "A" defined
ok 2 - $key->type_is_unicode
ok 3 - $key->codepoint
ok 4 - $key->modifiers
ok 5 - ->format_key yields "A"
ok 6 - ->parse_key "Ctrl-b" defined
ok 7 - $key->type_is_unicode
ok 8 - $key->codepoint
ok 9 - $key->modifiers
ok 10 - ->format_key yields "Ctrl-b"
ok 11 - ->parse_key "NoSuchKey" not defined
ok 12 - ->parse_key_at_pos defined
ok 13 - $key->type_is_unicode
ok 14 - $key->codepoint
ok 15 - $key->modifiers
ok 16 - pos($str) after ->parse_key_at_pos
ok 17 - ->parse_key_at_pos defined upgrade
ok 18 - pos($str) after ->parse_key_at_pos upgrade
ok
t/05flags.t . 
1..4
ok 1 - Explicit UTF-8 flag preserved
ok 2 - Explicit RAW flag preserved
Failed 2/4 subtests 
t/06mouse.t . 
1..6
ok 1 - getkey yields RES_KEY after mouse press
ok 2 - $key->type_is_mouse after mouse press
ok 3 - $key->mouseev after mouse press
ok 4 - $key->button after mouse press
ok 5 - $key->line after mouse press
ok 6 - $key->col after mouse press
ok
t/07position.t .. 
1..4
ok 1 - getkey yields RES_KEY after cursor position report
ok 2 - $key->type_is_position after cursor position report
ok 3 - $key->line after cursor position report
ok 4 - $key->col after cursor position report
ok
t/08modereport.t  
1..10
ok 1 - getkey yields RES_KEY after ANSI mode report
ok 2 - $key->type_is_modereport after ANSI mode report
ok 3 - $key->initial after ANSI mode report
ok 4 - $key->mode after ANSI mode report
ok 5 - $key->value after ANSI mode report
ok 6 - getkey yields RES_KEY after DEC mode report
ok 7 - $key->type_is_modereport after DEC mode report
ok 8 - $key->initial after DEC mode report
ok 9 - $key->mode after DEC mode report
ok 10 - $key->value after DEC mode report
ok
t/09unknown_csi.t ... 
1..7
ok 1 - getkey yields RES_KEY after unrecognised CSI > v
ok 2 - $key->type_is_unknown_csi after unrecognised CSI > v
ok 3 - $cmd for unrecognised CSI > v
ok 4 - @args for unrecognised CSI > v
ok 5 - getkey yields RES_KEY after unrecognised CSI ? Sp w
ok 6 - $cmd for unrecognised CSI ? Sp w
ok 7 - @args for unrecognised CSI ? Sp w
ok
t/99pod.t ... skipped: Test::Pod 1.00 required for testing POD

Test Summary Report
---
t/05flags.t   (Wstat: 11 Tests: 2 Failed: 0)
  Non-zero wait status: 11
  Parse errors: Bad plan.  You planned 4 tests but ran 2.
Files=11, Tests=100,  1 wallclock secs ( 0.08 usr  0.01 sys +  0.52 cusr  0.04 
csys =  0.65 CPU)
Result: FAIL
Failed 1/11 test programs. 0/100 subtests failed.
dh_auto_test: perl Build test --verbose 1 returned exit code 255
debian/rules:4: recipe for target 'build-arch' failed
make: *** [build-arch] Error 255
dpkg-buildpackage: error: debian/rules build-arch gave error exit status 2

Build finished at 20151227-2332

Finished


E: Build failure (dpkg-buildpackage died)

┌──┐
│ Cleanup  

Bug#807922: slapd: Unable to use olcTLSVerifyClient

[Ryan Tandy]

Control: tag -1 upstream moreinfo
Control: severity -1 normal

Hello,

Thank you for the report, and sorry for not answering sooner.

On Mon, Dec 14, 2015 at 03:05:22PM +0100, Obspm wrote:

From a fresh install (the server is a virtual machine with VirtualBox), after 
basic configuration of slapd, without any configuration other than those make 
by apt-get, with no special data I can add this piece of ldif


dn: cn=config
changeType: modify
add: olcTLSVerifyClient
olcTLSVerifyClient: never
-

I always got a

root@debian:~# ldapmodify -Y EXTERNAL -H ldapi:/// -f toto.ldif
SASL/EXTERNAL authentication started
SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
SASL SSF: 0
modifying entry "cn=config"
ldap_modify: Server is unwilling to perform (53)


At the moment, I think this behaviour is intentional and by design.

First, I would note that this only happens when you haven't performed 
the minimal TLS configuration yet:


http://sources.debian.net/src/openldap/2.4.40%2Bdfsg-1%2Bdeb8u1/libraries/libldap/tls2.c/#L199-L202

In this case, "unwilling to perform" means that the change can't be 
applied and take effect immediately, because TLS isn't even active yet. 
After you configure a server certificate or CA certificate, then you can 
start setting TLS options.


You could argue that the change should be accepted and committed, as if 
it had been done offline, and saved for when TLS is next started. (I say 
"change" here intentionally, even though the value in your example is 
the same as the default.)


There is room on either side, to argue that a more informative error 
message could be returned along with the error code, or that there is 
precedent for cn=config changes that are accepted but not applied until 
some subsystem, or slapd itself, is restarted. I don't have any 
particular opinion on any of this, and would rather not argue with 
upstream about design choices.


I am not forwarding this upstream right now, but I'd be willing to, if 
you can say a few more words about how you think this should behave and 
why. Alternatively you could open a report yourself at 
http://openldap.org/its; if you do that, please link the report here.


thanks,
Ryan

Bug#809192: libterm-termkey-perl: FTBFS: 05flags.t: Non-zero wait status: 11

[Aaron M. Ucko]

Salvatore Bonaccorso  writes:

> Can you please attach the full build log?

Thanks for the quick reply!  The logs are all publically available at
https://buildd.debian.org/status/package.php?p=libterm-termkey-perl, but
for the record, I'm attaching a full copy of the (arm64) log I
originally quoted.

-- 
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu

--2015-12-28 00:02:13--  
https://buildd.debian.org/status/fetch.php?pkg=libterm-termkey-perl&arch=arm64&ver=0.16-1&stamp=1451259181
Resolving buildd.debian.org (buildd.debian.org)... 5.153.231.18, 
2001:41c8:1000:21::21:18
Connecting to buildd.debian.org (buildd.debian.org)|5.153.231.18|:443... 
connected.
HTTP request sent, awaiting response... 200 OK
Length: unspecified [text/html]
Saving to: 
‘fetch.php?pkg=libterm-termkey-perl&arch=arm64&ver=0.16-1&stamp=1451259181’

 0K .. .. .. .  563K=0.07s

2015-12-28 00:02:13 (563 KB/s) - 
‘fetch.php?pkg=libterm-termkey-perl&arch=arm64&ver=0.16-1&stamp=1451259181’ 
saved [40495]

Bug#809018: [Letsencrypt-devel] Bug#809018: please backport letsencrypt to jessie-backports

[Eric Dorland]

* Axel Beckert (a...@debian.org) wrote:
> Hi,
> 
> Eric Dorland wrote:
> > Package: letsencrypt
> > Severity: wishlist
> > 
> > This may already be in the works but I couldn't find any info to
> > that effect. This would be a useful package to backport to stable.
> 
> It's definitely planned. Even before it was in NEW, the plan was
> already to get letsencrypt into stable-backports.

Excellent. I expected as much but wanted to be sure.

> That plan may have been only mentioned on IRC (at least that's where I
> know it from), but there were IIRC at least two bug reports related to
> backporting itself.

Sorry if this was a duplicate or expressed better somewhere else, I
didn't see any related reports.

> There's even the idea (brought up by myself) to make backports to
> (wheezy|oldstable)-backports-sloppy, but that's much more work than
> for Jessie and I failed on it so far.
> 
> A promising alternative for Wheezy boxes may be
> https://github.com/lukas2511/letsencrypt.sh -- which implements the
> client in pure bash (not pure bourne shell as it seems). It's under
> MIT license, but not (yet) packaged. Haven't tried it yet, though.

-- 
Eric Dorland 
43CF 1228 F726 FD5B 474C  E962 C256 FBD5 0022 1E93


signature.asc
Description: PGP signature

Bug#793522: ruby-rails-assets-highlightjs: please use the highlight.js package to provide javascript part

[Balasankar C]

On Tue, 28 Jul 2015 09:32:12 +0200 Andreas Beckmann  wrote:
> There is no such package in Debian and I fail to guess which one you
> could have meant instead.

Use the package libjs-highlight.js .

-- 
Regards
Balasankar C
http://balasankarc.in

Bug#809193: kde-config-fcitx: Please install to default qt5 plugin search path

[Zhang Jingqiang]

Package: kde-config-fcitx
Version: 0.5.3-1
Severity: normal

Hello,
The plugin is currently installed to /usr/lib/x86_64-linux-gnu/plugins/,
please install it to /usr/lib/x86_64-linux-gnu/qt5/plugins.

Thanks

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

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

Versions of packages kde-config-fcitx depends on:
ii  libc6 2.21-6
ii  libfcitx-config4  1:4.2.9.1-1
ii  libfcitx-core01:4.2.9.1-1
ii  libfcitx-qt5-11.0.5-1
ii  libfcitx-utils0   1:4.2.9.1-1
ii  libkf5completion5 5.16.0-1
ii  libkf5configwidgets5  5.16.0-1
ii  libkf5coreaddons5 5.16.0-1
ii  libkf5i18n5   5.16.0-1
ii  libkf5itemviews5  5.16.0-1
ii  libkf5kiowidgets5 5.16.0-1
ii  libkf5newstuff5   5.16.0-1
ii  libkf5widgetsaddons5  5.16.0-1
ii  libqt5core5a  5.5.1+dfsg-10
ii  libqt5dbus5   5.5.1+dfsg-10
ii  libqt5gui55.5.1+dfsg-10
ii  libqt5widgets55.5.1+dfsg-10
ii  libstdc++65.3.1-4

kde-config-fcitx recommends no packages.

kde-config-fcitx suggests no packages.

-- no debconf information

Bug#809192: libterm-termkey-perl: FTBFS: 05flags.t: Non-zero wait status: 11

[Salvatore Bonaccorso]

Control: tags -1 + moreinfo

Hi Aaron,

On Sun, Dec 27, 2015 at 11:35:48PM -0500, Aaron M. Ucko wrote:
> Source: libterm-termkey-perl
> Version: 0.16-1
> Severity: serious
> Justification: fails to build from source
> 
> Automated builds of libterm-termkey-perl have been failing with errors
> of the form
> 
>   Test Summary Report
>   ---
>   t/05flags.t   (Wstat: 11 Tests: 2 Failed: 0)
> Non-zero wait status: 11
> Parse errors: Bad plan.  You planned 4 tests but ran 2.
>   Files=11, Tests=100,  1 wallclock secs ( 0.08 usr  0.01 sys +  0.52 cusr  
> 0.04 csys =  0.65 CPU)
>   Result: FAIL
> 
> (with some timing variation, of course).  Could you please take a look?

Can you please attach the full build log?

Regards,
Salvatore

Bug#686447: Summary of ZFS on Linux for Debian

[Aron Xu]

On Mon, Dec 28, 2015 at 7:16 AM, Petter Reinholdtsen  wrote:
> [Aron Xu]
>> It has been in NEW queue for more than a month, we need to wait FTP
>> team to review it.
>
> Very good to hear. I notice it is still listed on
> https://ftp-master.debian.org/new.html >.
>
> Where I can read the conclusion about how the the linux/kfreebsd duality
> of zfs, and the legal status of including zfs?
>

We end up using different package namespace to avoid archive
maintenance burden, otherwise all is good. Legal advices should not be
disclosed publicly, so I'd rather say nothing about that, ;-)

Cheers,
Aron

Bug#809192: libterm-termkey-perl: FTBFS: 05flags.t: Non-zero wait status: 11

[Aaron M. Ucko]

Source: libterm-termkey-perl
Version: 0.16-1
Severity: serious
Justification: fails to build from source

Automated builds of libterm-termkey-perl have been failing with errors
of the form

  Test Summary Report
  ---
  t/05flags.t   (Wstat: 11 Tests: 2 Failed: 0)
Non-zero wait status: 11
Parse errors: Bad plan.  You planned 4 tests but ran 2.
  Files=11, Tests=100,  1 wallclock secs ( 0.08 usr  0.01 sys +  0.52 cusr  
0.04 csys =  0.65 CPU)
  Result: FAIL

(with some timing variation, of course).  Could you please take a look?

Thanks!

Bug#808997: Processed: Re: Missing /usr path in modules-load.d(5)

[Felipe Sateler]

On 26 December 2015 at 06:06, Michael Biebl  wrote:
> Am 26.12.2015 um 08:37 schrieb martin f krafft:
>> also sprach Jörg Frings-Fürst  [2015-12-26 11:48 
>> +1300]:
>>> Care to elaborate why?
>>
>> Sorry, it's not terribly useful to augment the original bug report
>> that I first cloned.
>>
>> Basically, /usr/lib/modules-load.d is not supported by upstream.
>
> I don't think this is true. systemd-modules-load looks at both locations.
>
> I actually think we should move files to /usr/lib/modules-load.d and
> make that the preferred location (that's what other distros use that
> have done the usr-merge).

I only now notice that systemd.pc has:

modulesloaddir=/usr/lib/modules-load.d

So that means that the sed is too broad and we need to stop
documenting /lib/modules-load.d . I now notice the following other
paths that are inconsistent with the man pages:

systemduserunitdir=/usr/lib/systemd/user
systemduserpresetdir=/usr/lib/systemd/user-preset
systemdusergeneratordir=/usr/lib/systemd/user-generators



-- 

Saludos,
Felipe Sateler

Bug#809191: ITP: golang-github-creack-termios -- Multi Platform Golang terminal management: Raw mode, TTY size.

[gustavo panizzo]

Package: wnpp
Severity: wishlist
Owner: gustavo panizzo 

* Package name: golang-github-creack-termios
  Version : 0.0_git20140919
  Upstream Author : Guillaume J. Charmes 
* URL : https://github.com/creack/termios
* License : MIT/X
  Programming Lang: Go
  Description : Multi Platform Golang terminal management: Raw mode, TTY 
size.

This is a dependency of asciinema package.

Bug#809179: asciinema: Unusable when $HOME is ENOENT

[gustavo panizzo (gfa)]

On Sun, Dec 27, 2015 at 10:40:11PM +, Daniel Shahaf wrote:
> Package: asciinema
> Version: 0.9.8-1
> 
> Good morning again Gustavo,

Hi Daniel

> 
> When $HOME does not exist, asciinema fails to start.

newer asciinema version, written in go, fails too but more gracefully


gustavo-nb:(1)~$ HOME=/foo asciinema
open /foo/.config/asciinema/config: no such file or directory

if $HOME/.config exists, $HOME/.config/asciinema/config will be created.


gustavo-nb:(1)~$ unset HOME
gustavo-nb:~gust9547$ asciinema
Need $HOME

I don't think it is a bug, *in version 1.1.1*, in 0.9.8 (the version
currently in the archive) it may be a bug.


-- 
1AE0 322E B8F7 4717 BDEA BF1D 44BB 1BA7 9F6C 6333

keybase: http://keybase.io/gfa

Bug#809190: rancid should use 3des-cbc instead of 3des

[Anatoliy Kushner]

Package: rancid
Version: 3.2-2

After last upgrade openssh-client was upgraded and now rancid can not
login with default settings

user@server:~$ jlogin router.mxrouter.mx
spawn ssh -c 3des -x -l ranciduser router.mx
Unknown cipher type '3des'

Error: Couldn't login

Workaround is to add "add cyphertype * 3des-cbc" to .cloginrc

Bug#808610: libxapian22: xapian database corruption causes recollindex loop

[Olly Betts]

On Mon, Dec 21, 2015 at 01:14:40PM +, John Kozak wrote:
> I run recollindex from a crontab every night against a corpus of pdf
> files. After upgrading to jessie, every few days this update would go
> into a cpu busy loop, requiring the process to be killed and the
> database to be deleted and remade.  Rebuilding `xapian-core` using the
> 1.2.21_git68 version of xapian-core from the xapian project has fixed this.

To get this fixed in jessie, the SRMs aren't going to allow an update to
a new upstream version - they'll want a minimal patch.  So we're going
to need to work out which change fixed this.

There haven't been many backend changes since 1.2.19 - my guess is it's
this one:

http://trac.xapian.org/changeset/826d1a19cc356e7bf66c1681626e70af32967447/git

Can you test 1.2.19 plus that patch to see if this solves your problem?

(If that is the fix, then testing and unstable aren't affected).

You mention database corruption in the subject line - does the database
also get reported as corrupt if you run xapian-check on it?

Cheers,
Olly

Bug#809187: [Debian-med-packaging] Bug#809187: transdecoder: please make the build reproducible

[Charles Plessy]

Control: tak -1 pending

Le Mon, Dec 28, 2015 at 02:18:47AM +, Chris Lamb a écrit :
> 
> Whilst working on the "reproducible builds" effort [0], we noticed that 
> transdecoder could not be built reproducibly.
> 
> Patch attached.

Thanks,

I applied the patch and forwared it upstream.

https://github.com/TransDecoder/TransDecoder/pull/10

To other Debian Med people: I do not have access to my GPG key from work, so I
will not upload right now.  Anybody feel free :)

Happy new year,

-- 
Charles

Bug#808872: pysocks vs socksipy

[W. Martin Borgert]

Hi Jean-Michel, hi Thomas,

On 2015-12-28 01:19, Jean-Michel Vourgère wrote:
> W. Martin Borgert wrote:
> > The latest reincarnation of socksipy at
> > https://github.com/Anorov/PySocks
> > has released 1.5.0 on 2014-01-02
>
> You might want to check package python-pysocks that already contains
> that fork by Anorov.
>
> Ouch :(
>
> https://packages.qa.debian.org/p/python-pysocks.html
> https://packages.qa.debian.org/p/python-socksipy.html

Thanks for the information.
IMHO, one of the packages should be removed from unstable and testing.

I wonder, why pysocks has been packaged instead of updating socksipy?
After all, one seems to be the (compatible) successor of the other.

Where is the Debian packaging VCS for pysocks?
I didn't find it in the DPMT git repo.

Cheers

Bug#809184: "aptitude changelog" aborts with "Illegal instruction"

[Paul Wise]

On Mon, 28 Dec 2015 01:57:25 + Bjarni Ingi Gislason wrote:

>   aptitude changelog apt ...

Does this always produce the same outcome?

>   Output was "Illegal instruction" with a return value of 132.
...
> Architecture: i386 (i586)

There are some things that would help the aptitude maintainers figure
out what the problem is:

Send the output of this command:

cat /proc/cpuinfo

Enable the debug repo, install debug symbols, gdb and make a backtrace:

Create this file:

/etc/apt/sources.list.d/04-debian-debug.sources

Put this line in it:

deb http://debug.mirrors.debian.org/debian-debug/ unstable-debug main

Update the apt cache:

sudo apt-get update

Install the gdb debugger and debug symbols:

sudo apt-get install gdb aptitude-dbg libapt-pkg5.0-dbgsym libboost1.58-dbg 
libc6-dbg libncursesw5-dbg libgcc1-dbg libsqlite3-0-dbg libstdc++6-5-dbg 
libtinfo5-dbg libxapian22v5-dbg

Run the debugger and get a crash trace:

gdb -batch -n -ex 'set height 0' -ex run -ex bt -ex 'thread apply all bt full' 
--args aptitude changelog apt

-- 
bye,
pabs

https://wiki.debian.org/PaulWise




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

Bug#809189: O: mathomatic -- portable Computer Algebra System (CAS)

[Sandro Tosi]

Package: wnpp
Severity: normal

I intend to orphan the mathomatic package.

The package description is:
 Mathomatic implements most of the rules of algebra for the
 mathematical operators +, -, *, /, % (modulus), and power (including
 roots).
 .
 Mathomatic can symbolically:
 .
  * combine and solve equations,
  * completely simplify and compare expressions and equations,
  * do simple calculus transformations and series,
  * do standard, complex number, modular, and polynomial arithmetic,
  * generate optimized C, Java, and Python language code from
simplified equations,
  * plot expressions with gnuplot in two or three dimensions,
  * do quick calculations, colorize expressions, etc.

Bug#809187: transdecoder: please make the build reproducible

[Chris Lamb]

Source: transdecoder
Version: 2.0.1+dfsg-1
Severity: wishlist
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: randomness
X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org

Hi,

Whilst working on the "reproducible builds" effort [0], we noticed that 
transdecoder could not be built reproducibly.

Patch attached.

 [0] https://wiki.debian.org/ReproducibleBuilds


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-
--- a/debian/patches/reproducible-build 1970-01-01 01:00:00.0 +0100
--- b/debian/patches/reproducible-build 2015-12-28 03:17:11.152591794 +0100
@@ -0,0 +1,16 @@
+--- transdecoder-2.0.1+dfsg.orig/util/cufflinks_gtf_to_bed.pl
 transdecoder-2.0.1+dfsg/util/cufflinks_gtf_to_bed.pl
+@@ -68,11 +68,11 @@ main: {
+ 
+   my $genes_href = $genome_trans_to_coords{$scaff};
+ 
+-  foreach my $gene_id (keys %$genes_href) {
++  foreach my $gene_id (sort keys %$genes_href) {
+ 
+   my $trans_href = $genes_href->{$gene_id};
+ 
+-  foreach my $trans_id (keys %$trans_href) {
++  foreach my $trans_id (sort keys %$trans_href) {
+ 
+   my $coords_href = $trans_href->{$trans_id};
+ 
--- a/debian/patches/series 2015-12-28 03:15:02.514567260 +0100
--- b/debian/patches/series 2015-12-28 03:17:07.500534389 +0100
@@ -1,2 +1,3 @@
 cd-hit-est-rename
 fix-whatis
+reproducible-build

Bug#809188: unicode-data: allkeys.txt is from unicode 7.0

[Michael Gilbert]

package: src:unicode-data
version: 8.0-2

The version of allkeys.txt included is version 7.0.0 in the
unicode-data 8.0 package, not the expected version 8.0.0.

Best wishes,
Mike

Bug#809186: breathe: please make the output reproducible

[Chris Lamb]

Source: breathe
Version: 4.1.0-1
Severity: wishlist
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: toolchain
X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org

Hi,

Whilst working on the "reproducible builds" effort [0], we noticed that breathe 
can generate non-reproducible output. Patch attached.

 [0] https://wiki.debian.org/ReproducibleBuilds


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-
diff --git a/breathe/directives.py b/breathe/directives.py
index 07490e5..63bb424 100644
--- a/breathe/directives.py
+++ b/breathe/directives.py
@@ -156,7 +156,7 @@ class DoxygenFunctionDirective(BaseDirective):
 # TODO: We're cheating here with the set() as signatures has 
repeating entries for some
 # reason (failures in the matcher_stack code) so we consolidate 
them by shoving them in
 # a set to remove duplicates. Should be fixed!
-for i, entry in enumerate(set(error.signatures)):
+for i, entry in enumerate(sorted(set(error.signatures))):
 if i:
 literal_text += '\n'
 # Replace new lines with a new line & enough spacing to reach 
the appropriate

Bug#809185: supermin FTBFS on parisc/hppa, alpha and powerpc (with patch)

[Helge Deller]

Package: supermin
Version: 5.1.13-3
Tags: patch

supermin fails to build on hppa, alpha and ppc64 architectures
since the "test-build-bash.sh" test script fails.
Example log see:
https://buildd.debian.org/status/fetch.php?pkg=supermin&arch=hppa&ver=5.1.13-3&stamp=1451234479

The attached patch fixes it (at least!) for the hppa architecture.
The alpha addition to "debian/control" is untested, but most likely correct.
ppc64 needs at least a similar linux-image* entry in "debian/control".

Other than that, there is a bug in the src/bin2s.pl perl script, that it
wrongly exports the "_binary_init_size" constant, *and* that it's wrongly used
in the src/ext2init-c.c C-file.
I changed the coding so that it's correct and smaller.

It would be nice if you could apply the patch for the next upload.

Thanks,
Helge
diff -up ./debian/control.org ./debian/control
--- ./debian/control.org	2015-12-27 18:49:22.36000 +0100
+++ ./debian/control	2015-12-28 02:49:11.21200 +0100
@@ -13,12 +13,14 @@ Build-Depends: debhelper (>= 9),
  zlib1g-dev, liblzma-dev,
  cpio,
  augeas-tools, libhivex-bin, 
+ linux-image-alpha-generic [alpha],
  linux-image-versatile [armel],
  linux-image-armmp [armhf],
  linux-image-arm64 [arm64],
  linux-image-4kc-malta [mips mipsel] | linux-image-5kc-malta [mips mipsel],
  linux-image-5kc-malta [mips64 mips64el],
  linux-image-s390x [s390x],
+ linux-image-parisc [hppa hppa64],
  linux-image-powerpc [powerpc],
  linux-image-powerpc64le [ppc64el],
  linux-image-sparc64 [sparc],
diff -up ./src/bin2s.pl.org ./src/bin2s.pl
--- ./src/bin2s.pl.org	2015-12-28 02:28:04.00400 +0100
+++ ./src/bin2s.pl	2015-12-28 02:39:45.46000 +0100
@@ -43,11 +43,6 @@ print $ofh <<"EOF";
 
 _binary_${infile}_end:
 
-#if defined(__hppa__)
-\t_binary_${infile}_size: .equ $sz
-#else
-\t.equ _binary_${infile}_size, $sz
-#endif
 EOF
 
 close $ofh;
diff -up ./src/ext2init-c.c.org ./src/ext2init-c.c
--- ./src/ext2init-c.c.org	2015-12-28 02:31:19.3 +0100
+++ ./src/ext2init-c.c	2015-12-28 02:32:47.30400 +0100
@@ -28,14 +28,14 @@
 /* The init binary.
  * See: bin2s.pl, init.c.
  */
-extern char _binary_init_start, _binary_init_end, _binary_init_size;
+extern char _binary_init_start, _binary_init_end;
 
 value
 supermin_binary_init (value unitv)
 {
   CAMLparam1 (unitv);
   CAMLlocal1 (sv);
-  size_t n = (size_t) &_binary_init_size;
+  size_t n = ((size_t) &_binary_init_end) - ((size_t) &_binary_init_start);
 
   sv = caml_alloc_string (n);
   memcpy (String_val (sv), &_binary_init_start, n);
diff -up ./src/kernel.ml.org ./src/kernel.ml
--- ./src/kernel.ml.org	2015-12-27 18:05:03.36400 +0100
+++ ./src/kernel.ml	2015-12-27 18:13:51.09200 +0100
@@ -30,6 +30,7 @@ let patt_of_cpu host_cpu =
 | "ppc" | "powerpc" | "powerpc64" -> ["ppc"; "powerpc"; "powerpc64"]
 | "sparc" | "sparc64" -> ["sparc"; "sparc64"]
 | "amd64" | "x86_64" -> ["amd64"; "x86_64"]
+| "parisc" | "parisc64" -> ["hppa"; "hppa64"]
 | "ppc64el" -> ["powerpc64le"]
 | _ when host_cpu.[0] = 'i' && host_cpu.[2] = '8' && host_cpu.[3] = '6' -> ["?86"]
 | _ when String.length host_cpu >= 5 && String.sub host_cpu 0 5 = "armv7" ->  ["armmp"]
diff -up ./src/utils.ml.org ./src/utils.ml
--- ./src/utils.ml.org	2015-12-27 18:16:37.29600 +0100
+++ ./src/utils.ml	2015-12-28 02:42:22.50400 +0100
@@ -191,6 +191,8 @@ let compare_architecture a1 a2 =
 | a when string_prefix "armv6" a -> 32
 | a when string_prefix "armv7" a -> 32
 | a when string_prefix "armv8" a -> 64
+| "hppa" | "parisc" -> 32
+| "hppa64" | "parisc64" -> 64
 | "ppc" | "ppc32" -> 32
 | a when string_prefix "ppc64" a -> 64
 | "sparc" | "sparc32" -> 32

Bug#809184: "aptitude changelog" aborts with "Illegal instruction"

[Bjarni Ingi Gislason]

Package: aptitude
Version: 0.7.5-3
Severity: important

Dear Maintainer,

   * What led up to the situation?

  aptitude changelog apt ...

   * What was the outcome of this action?

  Output was "Illegal instruction" with a return value of 132.

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

Kernel: Linux 3.16.7-ckt9-3
Locale: LANG=is_IS, LC_CTYPE=is_IS (charmap=ISO-8859-1)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages aptitude depends on:
ii  aptitude-common0.7.5-3
ii  libapt-pkg5.0  1.1.4
ii  libboost-filesystem1.58.0  1.58.0+dfsg-4.1
ii  libboost-iostreams1.58.0   1.58.0+dfsg-4.1
ii  libboost-system1.58.0  1.58.0+dfsg-4.1
ii  libc6  2.21-4
ii  libcwidget3v5  0.5.17-4+b1
ii  libgcc11:5.3.1-3
ii  libncursesw5   6.0+20151024-2
ii  libsigc++-2.0-0v5  2.6.2-1
ii  libsqlite3-0   3.9.2-1
ii  libstdc++6 5.3.1-3
ii  libtinfo5  6.0+20151024-2
ii  libxapian22v5  1.2.21-1.2

Versions of packages aptitude recommends:
pn  aptitude-doc-en | aptitude-doc  
ii  libparse-debianchangelog-perl   1.2.0-8
ii  sensible-utils  0.0.9

Versions of packages aptitude suggests:
pn  apt-xapian-index  
pn  debtags   
ii  tasksel   3.34

-- no debconf information

-- 
Bjarni I. Gislason

Bug#809094: libencode-arabic-perl: warns on usage with Perl 5.22

[gregor herrmann]

On Sun, 27 Dec 2015 13:11:52 +0200, Niko Tyni wrote:

> Package: libencode-arabic-perl
> Versin: 14.1-3
> User: debian-p...@lists.debian.org
> Usertags: autopkgtest perl-5.22-transition
> Control: affects -1 libelixirfm-perl
> 
> This package now warns on usage:
> 
> /usr/share/pkg-perl-autopkgtest/runtime-deps.d/use.t .. 
> 1..2
> # Unescaped left brace in regex is deprecated, passed through in regex; 
> marked by <-- HERE in m/([\_\.\^]?\w)\\shadda{ <-- HERE }/ at 
> /usr/share/perl5/Encode/Arabic/ArabTeX/RE.pm line 63.

I've fixed these warnings with a patch in git, but

> # Replacement list is longer than search list at (eval 6) line 6.
> # Replacement list is longer than search list at (eval 8) line 6.
> # Replacement list is longer than search list at (eval 10) line 6.

that's still there. Needs further investigation.


Cheers,
gregor

-- 
 .''`.  Homepage: http://info.comodo.priv.at/ - OpenPGP key 0xBB3A68018649AA06
 : :' : Debian GNU/Linux user, admin, and developer -  https://www.debian.org/
 `. `'  Member of VIBE!AT & SPI, fellow of the Free Software Foundation Europe
   `-   NP: Mark Knopfler: Sailing To Philadelphia


signature.asc
Description: Digital Signature

Bug#807432: RFS: python-jellyfish/0.5.1-1 [ITP]

[Nicholas Breen]

On Tue, Dec 08, 2015 at 09:44:01PM +0100, Diego M. Rodriguez wrote:
> I am looking for a sponsor for my package "python-jellyfish"
> 
> * Package name: python-jellyfish
>   Version : 0.5.1-1
>   Upstream Author : James Turk 
> * URL : https://github.com/jamesturk/jellyfish
> * License : BSD-2-clause
>   Section : python

Hi Diego,

I believe the package also needs Build-Depends on libpython-all-dev and
libpython3-all-dev, or the C extensions fail (nonfatally) to compile in a clean
chroot environment.

Unfortunately, the tests also fail - it appears that pytest is not successfully
picking up any tests to run:

[...]
I: pybuild base:184: cd 
/tmp/buildd/python-jellyfish-0.5.1/.pybuild/pythonX.Y_2.7/build; python2.7 -m 
pytest 
= test session starts ==
platform linux2 -- Python 2.7.11, pytest-2.8.5, py-1.4.31, pluggy-0.3.1
rootdir: /tmp/buildd/python-jellyfish-0.5.1, inifile: 
collected 0 items

= no tests ran in 0.00 seconds =
E: pybuild pybuild:274: test: plugin distutils failed with: exit code=5: cd 
/tmp/buildd/python-jellyfish-0.5.1/.pybuild/pythonX.Y_2.7/build; python2.7 -m 
pytest 
[...]



-- 
Nicholas Breen
nbr...@debian.org

Bug#808872: new version 1.5.0 available

[Jean-Michel Vourgère]

W. Martin Borgert wrote:
> The latest reincarnation of socksipy at
> https://github.com/Anorov/PySocks
> has released 1.5.0 on 2014-01-02


You might want to check package python-pysocks that already contains
that fork by Anorov.

Ouch :(

https://packages.qa.debian.org/p/python-pysocks.html
https://packages.qa.debian.org/p/python-socksipy.html



signature.asc
Description: OpenPGP digital signature

Bug#809156: apt-show-source: Package doesn't provide an executable

[Giovani Ferreira]

Hello,

I made a NMU and Eriberto which sponsored the upload. The package has
been put into the NEW queue[1] because now provides a executable.

[1] https://ftp-master.debian.org/new.html

The debian/changelog is:

apt-show-source (0.10+nmu4) unstable; urgency=medium

  * Non-maintainer upload.
  * debian/rules:
  - Fixed the path to install the executable correctly. (Closes:
#809156)
  - Replaced dh_installmanpages to dh_installman.

I attached a debdiff.

regards,

-- 
Giovani Ferreira
http://softwarelivre.org/jova2
GNU/Linux user: 337388  GPG ID: 2375A66C
diff -Nru apt-show-source-0.10+nmu3/debian/changelog 
apt-show-source-0.10+nmu4/debian/changelog
--- apt-show-source-0.10+nmu3/debian/changelog  2015-12-12 09:04:30.0 
-0200
+++ apt-show-source-0.10+nmu4/debian/changelog  2015-12-27 17:03:31.0 
-0200
@@ -1,3 +1,12 @@
+apt-show-source (0.10+nmu4) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * debian/rules:
+  - Fixed the path to install the executable correctly. (Closes: #809156)
+  - Replaced dh_installmanpages to dh_installman.
+
+ -- Giovani Augusto Ferreira   Sun, 27 Dec 2015 16:31:43 
-0200
+
 apt-show-source (0.10+nmu3) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru apt-show-source-0.10+nmu3/debian/rules 
apt-show-source-0.10+nmu4/debian/rules
--- apt-show-source-0.10+nmu3/debian/rules  2015-12-11 19:21:55.0 
-0200
+++ apt-show-source-0.10+nmu4/debian/rules  2015-12-27 18:39:07.0 
-0200
@@ -13,7 +13,7 @@
 endif
 
 VERSION=`dpkg-parsechangelog | grep '^Version: ' | sed -e "s/^Version: //g"`
-TMP =`pwd`/debian/tmp
+#TMP =`pwd`/debian/tmp
 archlib =`$(PERL) -MConfig -e 'print $$Config{installarchlib}'`
 
 build: build-stamp
@@ -48,9 +48,9 @@
 
 # Add here commands to install the package into debian/tmp.
if grep ^install_vendor Makefile; then \
-   $(MAKE) install DESTDIR=$(PWD)/debian/tmp; \
+   $(MAKE) install DESTDIR=$(PWD)/debian/apt-show-source; \
else \
-   $(MAKE) pure_install DESTDIR=$(PWD)/debian/tmp; \
+   $(MAKE) pure_install DESTDIR=$(PWD)/debian/apt-show-source; \
fi
 
 # Build architecture-independent files here.
@@ -70,7 +70,7 @@
 #  dh_installpam
 #  dh_installinit
 #  dh_installcron
-   dh_installmanpages
+   dh_installman apt-show-source.1 apt-show-source.es.1 
apt-show-source.fr.1 apt-show-source.ja.1
 #  dh_installinfo
dh_installchangelogs
 #  dh_link

Bug#809029: apt: trusted=yes option in sources.list not recognized

[Christoph Anton Mitterer]

On Sun, 2015-12-27 at 11:44 +0100, Andreas Metzler wrote:
> Underlined square brackets do not render very well but it is an
> improvement.
Well that's just one formatting idea... but many manpages seem to use
it that way, e.g. mdadm(8)

Cheers,
Chris.

smime.p7s
Description: S/MIME cryptographic signature

Bug#809183: squeezelite: broken links in manpage

[tony mancill]

Package: squeezelite
Version: 1.8-1+b1
Severity: minor

Dear Maintainer,

The following links from the SEE ALSO section of the squeezelite manpage are
broken (they return 404s):

  http://www.communitysqueeze.org/squeezelite_about.jsp
  http://www.communitysqueeze.org/squeezelite_upsample.jsp

Maybe just remove them?

Thanks,
tony



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

Bug#809178: [Letsencrypt-devel] Bug#809178: python-letsencrypt: version 0.1.1-3 not installable, because of missing python-letsencrypt-apache >= 0.1.1

[Harlan Lieberman-Berg]

Achim Schaefer  writes:
> I can not install the latest version, because the package
> python-letsencrypt breaks python-letsencrypt-apache < 0.1.1, but there
> is no verion >= 0.1.1 in the archive.

Hi Achim,

Are you trying to install the version in unstable, or the version in
testing?

If your system has both testing and unstable, apt may be having problems
figuring out which distribution to use.  Can you paste the output of
`apt-cache policy python-acme python-letsencrypt
python-letsencrypt-apache`?

Sincerely,

-- 
Harlan Lieberman-Berg
~hlieberman

Bug#752337: setools: Logwatch script in wrong location, produces error when package is removed but not purged

[Laurent Bigonville]

On Sun, 22 Jun 2014 21:14:55 +0200 Willi Mann  wrote:
>
> Hi,
>
> I think the script /etc/logwatch/scripts/services/seaudit-report-service
> should be shipped in /usr/share/logwatch/scripts/services, unless it 
is really

> expected to be modified by the user like a configuration file.
>
> Additionally, the script should exit silently if 
/usr/bin/seaudit-report does
> not exist. This is especially bad as long as the script sits in /etc, 
since a

> removal without purge of setools-gui will lead to an error message being
> included in the logwatch output:
>
> - seaudit-report Begin 
>
> Date Range: yesterday
> Detail Level: 0
> Temp Dir: /tmp/logwatch.mTpaZLGy/
> Debug Level: 0
> /etc/logwatch/scripts/services/seaudit-report-service: line 14: 
/usr/bin/seaudit-report: No such file or directory

> Failed while executing seaudit-report.\n
>
> -- seaudit-report End -

Shouldn't all the files in /etc/logwatch be moved to /usr/share/logwatch?

Cheers,

Laurent Bigonville

Bug#807600: Which package?

[Ben Hutchings]

On Sun, 2015-12-27 at 15:49 +, John Talbut wrote:
> Thank you all for looking at this.
> 
> Ben, you think this is not a problem with initramfs-tools but it might 
> be in cryptsetup.  Jonas, you consider that it is not a problem with 
> cryptsetup.
> 
> The possibility that I might have something wrong with my kernel 
> configuration did occur to me in the first place.  I spent a 
> considerable amount of time both before submitting this bug and after 
> checking this and I cannot find anything missing.  As I wrote, I have 
> compiled kernels successfully many times before.

Based on this:

[custom kernel]
/dev/sdb: PTUUID="25169f0a-30ad-47e5-81a9-d74ae8286776" PTTYPE="gpt"

[standard kernel]
/dev/sda: PTUUID="25169f0a-30ad-47e5-81a9-d74ae8286776" PTTYPE="gpt"
/dev/sda1: PARTUUID="1e4484e1-1499-4f9a-bd2f-e0f4d61e9920"
/dev/sda2: UUID="48537739-1f62-4c12-8bf1-9d662d8cc74f" TYPE="crypto_LUKS" 
PARTLABEL="dk" PARTUUID="6b5c5648-1b4b-4be5-83d7-7c47eb8b53a6"
/dev/sda3: UUID="bf028ceb-d1fa-4f62-b41f-d9d44adbe65a" TYPE="ext4" 
PARTUUID="5970fa70-34fa-4eca-aaf7-f085c9b55a27"

I would guess that you didn't enable CONFIG_EFI_PARTITION and thus the
kernel can't decode the partition table.

> What I notice in the attached dmesgs is that the item:
> 
> device-mapper: ioctl: 4.33.0-ioctl (2015-8-18) initialised: 
> dm-de...@redhat.com
> 
> which occurs on the console immediately before "Please unlock disk 
> sda2_crypt:" comes after (at 3.128778) the items about ata, and sda when 
> the boot succeeds using a stock, modular kernel.
> 
> When using the static kernel and the boot the device-mapper: ioctl: item 
> (at 1.413366) comes before the ata and sda items.
> 
> In other words, it seems to me, that the system is trying to decrypt the 
> disk before it has been accessed.

That shouldn't be a problem, as it will be retried at intervals (as
you've seen).

> If this is the problem, then which package is causing it?  If not, what 
> else could the problem be?

It is your kernel configuration.

Ben.

-- 
Ben Hutchings
Power corrupts.  Absolute power is kind of neat.
   - John Lehman, Secretary of the US Navy 1981-1987

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

Bug#809182: [ethstats] Misreports "bytes out" also as "packets out"

[Peter Pentchev]

Package: ethstats
Version: 1.1.0-1
Severity: grave
Tags: upstream

Filing a bug report to prevent ethstats from migrating to testing.

I introduced a grave bug in my 1.1.0 refactoring of the Perl source of
ethstats - the wrong value is used for the number of packets sent out
on an interface, the same one as for the number of bytes sent out,
thus leading to some... intriguing reporting.  I've fixed it upstream:

  
https://gitlab.com/ethstats/ethstats/commit/80787035498a4a4c2d79943b36d045fde83b0947

...and I'll release ethstats-1.1.1 tomorrow and put up a Debian package
for sponsorship.

G'luck,
Peter

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

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

Versions of packages ethstats depends on:
ii  perl  5.20.2-6

ethstats recommends no packages.

ethstats suggests no packages.

-- no debconf information

-- 
Peter Pentchev  r...@ringlet.net r...@freebsd.org p...@storpool.com
PGP key:http://people.FreeBSD.org/~roam/roam.key.asc
Key fingerprint 2EE7 A7A5 17FC 124C F115  C354 651E EFB0 2527 DF13


signature.asc
Description: PGP signature

Bug#808486: dieharder: FTBFS: unistd.h: error: unknown type name 'intptr_t'

[Dirk Eddelbuettel]

On 20 December 2015 at 13:59, Chris West (Faux) wrote:
| Source: dieharder
| Version: 3.31.1-5
| Severity: serious
| Justification: fails to build from source
| Tags: sid stretch
| User: reproducible-bui...@lists.alioth.debian.org
| Usertags: ftbfs
| X-Debbugs-CC: reproducible-bui...@lists.alioth.debian.org
| 
| Dear Maintainer,
| 
| The package fails to build:
| 
| libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I.. -DVERSION=3.31.1 
-DLITTLE_ENDIAN=1 -I ../include -I /usr/include -std=c99 -Wall -pedantic -Wall 
-pipe -fexceptions -D_REENTRANT -g -O3 -MT libdieharder_la-bits.lo -MD -MP -MF 
.deps/libdieharder_la-bits.Tpo -c bits.c  -fPIC -DPIC -o 
.libs/libdieharder_la-bits.o
| In file included from ../include/dieharder/libdieharder.h:22:0,
|  from bits.c:7:
| /usr/include/unistd.h:1043:20: error: unknown type name 'intptr_t'
|  extern void *sbrk (intptr_t __delta) __THROW;
| ^
| bits.c: In function 'fill_uint_buffer':
| bits.c:407:15: warning: variable 'bufbits' set but not used 
[-Wunused-but-set-variable]
|   unsigned int bufbits,bdelta;
|^
| Makefile:687: recipe for target 'libdieharder_la-bits.lo' failed
| make[2]: *** [libdieharder_la-bits.lo] Error 1

Thanks for the report. I got distracted for a few days but now added the
missing #include  which the newer gcc version wants here.

Cheers, Dirk

| 
| Full build log:
| https://reproducible.debian.net/rb-pkg/unstable/amd64/dieharder.html
| 
| -- System Information:
| Debian Release: stretch/sid
| APT prefers unstable
| APT policy: (500, 'unstable')
| Architecture: amd64 (x86_64)

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

Bug#809131: [Letsencrypt-devel] Bug#809131: python-acme: FTBFS: No local packages or download links found for urllib3==1.12

[Harlan Lieberman-Berg]

Chris Lamb  writes:
> This is actually #809031, which has now been fixed. I am therefore closing 
> this bug in bcc.

Whoops, there we go.  Sorry about that; should have checked python-requests.

>> Can you please upload the complete build log
>
> Was one not attached, out of interest? :)

dpkg-buildpackage was, but not the actual dependency resolution that you
get out of pbuilder or sbuilder or whatever is calling d-bp.  Unless
you're building it directly, of course, in which case...

Thanks for your help, lamby.  I know the version in testing right now
fails reproducability; if the version in unstable does when it migrates,
I'll file the appropriate bugs upstream to get that fixed.

Sincerely,
-- 
Harlan Lieberman-Berg
~hlieberman

Bug#809181: laptop-mode-tools: typo in /lib/udev/lmt-udev

[Kelsey Byers]

Package: laptop-mode-tools
Version: 1.68-3
Severity: minor

Dear Maintainer,

I've found a minor typo in /lib/udev/lmt-udev:

line 47 reads:

exec > /dev/null 2>dev/null

which is missing the / before the second call of /dev/null

so it should read

exec > /dev/null 2>/dev/null

Thanks!

Kelsey Byers
kby...@mit.edu

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

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

Versions of packages laptop-mode-tools depends on:
ii  init-system-helpers  1.24
ii  lsb-base 9.20150917
ii  psmisc   22.21-2.1+b1
ii  util-linux   2.27.1-1

Versions of packages laptop-mode-tools recommends:
ii  ethtool 1:4.2-1
ii  hdparm  9.43-2
ii  net-tools   1.60+git20150829.73cef8a-2
ii  python-qt4  4.11.4+dfsg-1+b2
ii  sdparm  1.08-1
ii  udev228-2+b1
ii  wireless-tools  30~pre9-8

Versions of packages laptop-mode-tools suggests:
ii  acpid  1:2.0.25-1
ii  apmd   3.2.2-15

-- debconf-show failed

Bug#285338:

[ree little]

Sweet

Bug#686447: Summary of ZFS on Linux for Debian

[Petter Reinholdtsen]

[Aron Xu]
> It has been in NEW queue for more than a month, we need to wait FTP
> team to review it.

Very good to hear. I notice it is still listed on
https://ftp-master.debian.org/new.html >.

Where I can read the conclusion about how the the linux/kfreebsd duality
of zfs, and the legal status of including zfs?

-- 
Happy hacking
Petter Reinholdtsen

Bug#809165: Patch attached

[Paul Tagliamonte]

tags 809165 + patch moreinfo
thanks

Heyya,

Thinned out my patch to something a bit more digestable. Added a blank
changelog entry, so you can just `dch -rm` if it looks good. I had to
refresh the patch against the package, so the line offsets look
different than the PR. Content should match, though.

Added DEP3 headers, but I just noticed other patches don't have them.
Feel free to strip out the headers if they bother you.

I got most of the way through a compile, but I had to run. This patch
still needs testing. I'll try and get that done and follow up.

Cheers,
  Paul
diff -u gcc-5-5.3.1/debian/changelog gcc-5-5.3.1/debian/changelog
--- gcc-5-5.3.1/debian/changelog
+++ gcc-5-5.3.1/debian/changelog
@@ -1,3 +1,11 @@
+gcc-5 (5.3.1-5) UNRELEASED; urgency=medium
+
+  [ Paul Tagliamonte ]
+  * Apply PR 68668, which fixes a regression in detecting the type of an
+array of consts in some situations. (Closes: #809165)
+
+ -- Paul Tagliamonte   Sun, 27 Dec 2015 14:01:21 -0500
+
 gcc-5 (5.3.1-4) unstable; urgency=medium
 
   * Update to SVN 20151219 (r231847, 5.3.1) from the gcc-5-branch.
diff -u gcc-5-5.3.1/debian/rules.patch gcc-5-5.3.1/debian/rules.patch
--- gcc-5-5.3.1/debian/rules.patch
+++ gcc-5-5.3.1/debian/rules.patch
@@ -92,6 +92,7 @@
 	gcc-configure-pie \
 	ada-gnattools-ldflags \
 	libjit-ldflags \
+pr68668 \
 
 # this is still needed on powerpc, e.g. firefox and insighttoolkit4 will ftbfs.
 ifneq (,$(filter $(DEB_TARGET_ARCH),powerpc))
--- gcc-5-5.3.1.orig/debian/patches/pr68668.diff
+++ gcc-5-5.3.1/debian/patches/pr68668.diff
@@ -0,0 +1,19 @@
+Description: Clean up handling of arrays of constants not being groked
+ correctly.
+Forwarded: not-needed
+Origin: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68668
+Bug-Debian: https://bugs.debian.org/809165
+Author: Marek Polacek
+Reviewed-By: Paul Tagliamonte 
+
+--- a/src/gcc/c/c-decl.c
 b/src/gcc/c/c-decl.c
+@@ -6444,6 +6444,8 @@ grokdeclarator (const struct c_declarato
+ 	  {
+ 	/* Transfer const-ness of array into that of type pointed to.  */
+ 	type = TREE_TYPE (type);
++if (orig_qual_type != NULL_TREE)
++  orig_qual_type = TREE_TYPE (orig_qual_type);
+ 	if (type_quals)
+ 	  type = c_build_qualified_type (type, type_quals, orig_qual_type,
+ 	 orig_qual_indirect);


signature.asc
Description: PGP signature

Bug#809180: clang-3.8 is tuned for k8

[Vincent Lefevre]

Package: clang-3.8
Version: 1:3.8~svn254193-1
Severity: minor

clang-3.8 is tuned for k8:

$ clang-3.8 -dM -E -xc /dev/null | grep __tune_
#define __tune_k8__ 1

By default, it should not be tuned.

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

Kernel: Linux 4.3.0-1-amd64 (SMP w/12 CPU cores)
Locale: LANG=POSIX, 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 clang-3.8 depends on:
ii  binutils 2.25.90.20151209-1
ii  libc62.21-6
ii  libc6-dev2.21-6
ii  libclang-common-3.8-dev  1:3.8~svn254193-1
ii  libclang1-3.81:3.8~svn254193-1
ii  libedit2 3.1-20150325-1+b1
ii  libffi6  3.2.1-4
ii  libgcc-5-dev 5.3.1-4
ii  libgcc1  1:5.3.1-4
ii  libllvm3.8   1:3.8~svn254193-1
ii  libobjc-5-dev5.3.1-4
ii  libstdc++-5-dev  5.3.1-4
ii  libstdc++6   5.3.1-4
ii  libtinfo56.0+20151024-2
ii  zlib1g   1:1.2.8.dfsg-2+b1

Versions of packages clang-3.8 recommends:
ii  llvm-3.8-dev  1:3.8~svn254193-1
ii  python2.7.11-1

Versions of packages clang-3.8 suggests:
ii  clang-3.8-doc  1:3.8~svn254193-1
pn  gnustep
pn  gnustep-devel  

-- no debconf information

Bug#809179: asciinema: Unusable when $HOME is ENOENT

[Daniel Shahaf]

Package: asciinema
Version: 0.9.8-1

Good morning again Gustavo,

When $HOME does not exist, asciinema fails to start.

To reproduce:

[[[
$ HOME=/foo asciinema
Traceback (most recent call last):
  File "/usr/lib/python3.4/configparser.py", line 761, in get
value = d[option]
  File "/usr/lib/python3.4/collections/__init__.py", line 805, in __getitem__
return self.__missing__(key)# support subclasses that define 
__missing__
  File "/usr/lib/python3.4/collections/__init__.py", line 797, in __missing__
raise KeyError(key)
KeyError: 'token'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/asciinema/config.py", line 50, in 
api_token
return self._get_api_token()
  File "/usr/lib/python3/dist-packages/asciinema/config.py", line 64, in 
_get_api_token
return self.config.get('api', 'token')
  File "/usr/lib/python3.4/configparser.py", line 764, in get
raise NoOptionError(option, section)
configparser.NoOptionError: No option 'token' in section: 'api'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/usr/lib/python3.4/configparser.py", line 761, in get
value = d[option]
  File "/usr/lib/python3.4/collections/__init__.py", line 805, in __getitem__
return self.__missing__(key)# support subclasses that define 
__missing__
  File "/usr/lib/python3.4/collections/__init__.py", line 797, in __missing__
raise KeyError(key)
KeyError: 'token'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/asciinema/config.py", line 53, in 
api_token
return self._get_user_token()
  File "/usr/lib/python3/dist-packages/asciinema/config.py", line 67, in 
_get_user_token
return self.config.get('user', 'token')
  File "/usr/lib/python3.4/configparser.py", line 764, in get
raise NoOptionError(option, section)
configparser.NoOptionError: No option 'token' in section: 'user'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/usr/bin/asciinema", line 9, in 
load_entry_point('asciinema==0.9.8', 'console_scripts', 'asciinema')()
  File "/usr/lib/python3/dist-packages/asciinema/__main__.py", line 7, in main
get_command(sys.argv[1:], Config()).execute()
  File "/usr/lib/python3/dist-packages/asciinema/commands/builder.py", line 41, 
in get_command
return RecordCommand(config.api_url, config.api_token, cmd, title,
  File "/usr/lib/python3/dist-packages/asciinema/config.py", line 55, in 
api_token
return self._create_api_token()
  File "/usr/lib/python3/dist-packages/asciinema/config.py", line 73, in 
_create_api_token
self._ensure_base_dir()
  File "/usr/lib/python3/dist-packages/asciinema/config.py", line 61, in 
_ensure_base_dir
os.mkdir(dir)
FileNotFoundError: [Errno 2] No such file or directory: '/foo/.asciinema'
]]]

I would expect asciinema to operate even when $HOME doesn't exist.

Cheers,

Daniel


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

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

Versions of packages asciinema depends on:
ii  python3   3.4.3-7
ii  python3-requests  2.9.1-1
pn  python3:any   

asciinema recommends no packages.

asciinema suggests no packages.

-- debconf-show failed

Bug#809175: sbuild: Doesn't want to build pkg with only linux-any architecture

[Niko Tyni]

Control: tag -1 patch

On Sun, Dec 27, 2015 at 10:48:51PM +0100, Laurent Bigonville wrote:
> Package: sbuild
> Version: 0.67.0-1
> Severity: important
 
> This is probably also related to the perl transition.

No, just a regression introduced in the last upload.

> sbuild doesn't want to build a source package with only linux-any
> architecture binary packages:
> 
> Check architectures
> ---
> 
> Bareword "amd64" not allowed while "strict subs" in use at -e line 4.
> Bareword "linux" not allowed while "strict subs" in use at -e line 4.
> Bareword "any" not allowed while "strict subs" in use at -e line 4.
> Execution of -e aborted due to compilation errors.
> setools_3.3.8+20151215-1.dsc: amd64 not in arch list or does not match any 
> arch wildcards: linux-any -- skipping

The attached proposed patch should fix this.
-- 
Niko Tyni   nt...@debian.org
>From bc5a0813896a97c8908d346e2b32c25e1ce117d1 Mon Sep 17 00:00:00 2001
From: Niko Tyni 
Date: Mon, 28 Dec 2015 00:30:49 +0200
Subject: [PATCH] Fix quoting when checking architectures

The variables got interpolated into $command without any quoting,
essentially becoming barewords.

Regression introduced in 9162dd0d727facb2ebab0ab7008603c5fa8c36a1

Closes: #809175
---
 lib/Sbuild/Build.pm | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lib/Sbuild/Build.pm b/lib/Sbuild/Build.pm
index a6ac74c..95245ca 100644
--- a/lib/Sbuild/Build.pm
+++ b/lib/Sbuild/Build.pm
@@ -1139,7 +1139,7 @@ sub fetch_source_files {
 		use strict;
 		use warnings;
 		use Dpkg::Arch;
-		if (Dpkg::Arch::debarch_is($host_arch, $a)) {
+		if (Dpkg::Arch::debarch_is('$host_arch', '$a')) {
 		exit 0;
 		}
 		exit 1;
-- 
2.6.4

Bug#809160: apt: [doc] apt.conf(5) man page (file apt.conf.5.xml in source) possible minor mistakes

[David Kalnischkies]

On Sun, Dec 27, 2015 at 06:19:54PM +0100, Beatrice Torracca wrote:
> «The value should be a normal URI to a text file, expect that package 
> specific data is replaced with the placeholder 
> @CHANGEPATH@. The value for it is: 1. if the package is 
> from a component (e.g. main) this is the first part 
> otherwise it is omitted, 2. the first letter of source package name, expect 
> if the source package name starts with 'lib' in which case 
> it will be the first four letters. 3. The complete source package name. 4. 
> the complete name again and  5. the source version.»
> 
> I think both occurrence of "expect" should be instead "except".

Right!

> Afterwards in the same page there is:
> 
> «Package action lines consist of five fields in Version 2: old version, 
> direction of version change (< for upgrades, > for downgrades, = for no 
> change), new version, action.»
> 
> Unless I am missing something those are only 4 fields, not 5 (1 old version, 
> 2 direction of change, 3 new version, 4 action). (Maybe it was related to 
> Version 3 with the Multiarch field too??, just a thought, I am not sure).

You aren't missing something, the sentence is: The first (and therefore
fifth) field is the package name…


> Very shortly after that there is a quote missing (the opening quote for the 
> type "foreign" in
> «In Version 3 after each version field follows the architecture
>  of this version, which is "-" if there is no version, and a field showing
>  the MultiArch type "same", foreign", "allowed" or "none".»

Added.


> I hope I am not wasting your time.

Of course you aren't. These silly mistakes shouldn't be in files we hand
out – as that is wasting *your* time… so, sorry about that & thanks for
the report and [informal] patch!


Best regards

David Kalnischkies


signature.asc
Description: PGP signature

Bug#809171: Please handle network device hotplug events (move from udev)

[Guus Sliepen]

On Sun, Dec 27, 2015 at 08:58:32PM +0100, Martin Pitt wrote:

> for historical reasons the udev package has shipped the functionality
> for handling network device hotplug events. However, it's a bit weird
> to ship the coldplugging parts (/etc/init.d/networking and
> networking.service) in ifupdown, but not the hotplugging ones. It
> would be more consistent to ship both in ifupdown and also make it
> easier to do changes. Of course the systemd packagers are still happy
> to discuss changes to the udev bits and provide guidance.

That's totally fine with me.

> This involves three parts:
> 
>  * An udev rule which reacts to adding or removing network devices.
>This is currently shipped as /lib/udev/rules.d/80-networking.rules
>but I propose that ifupdown ships it as
>/lib/udev/rules.d/80-ifupdown.rules to avoid a package file
>conflict and also to make it clearer that this applies to ifupdown
>only. I attach this as 80-ifupdown.rules.

I think we can also keep it as it is and use Replaces and Breaks
headers in the control file. Each has its drawbacks. If there is both
80-networking.rules and 80-ifupdown.rules, it seems to me like the
ifupdown script will be called twice for each hotplug event. But I agree
it will be clearer if it is called 80-ifupdown.rules.

>  * The above rule just calls an udev helper script "ifupdown" which
>needs to be put into /lib/udev/. This does the actual work of
>calling either ifup $IFACE directly (under SysV init or upstart) or
>a systemd unit "ifup@IFACE.service" under systemd. The latter is
>necessary as udev rules must not start long-running programs (ifup
>can take quite long), and it also provides much nicer and cleaner
>logging, a proper shutdown order, etc.
> 
>I attach this as "ifupdown".

Ok, that's basically just a copy of /lib/udev/net.agent. Why was
/lib/udev/hotplug.functions pasted into it instead of sourced? Or is
this just a difference between the Ubuntu and Debian version of the udev
package?

>  * The ifup@.service helper unit. This should go into
> 
>  `pkg-config --variable=systemdsystemunitdir systemd`
> 
>aka /lib/systemd/system/. It does not need to be enabled in any way
>as the above udev helper rule will start/stop it.
> 
>Note that this will file-conflict with udev with this name, so
>if/once you accept this we'll need to remove the above bits from
>udev and add a Breaks:/Replaces: to ifupdown and a Breaks: to udev.

Ok, so we'll have a file conflict in any case. I can do this in the next
release of ifupdown (0.8.5). I'll need to know which version of the udev
package to sync with.

-- 
Met vriendelijke groet / with kind regards,
  Guus Sliepen 


signature.asc
Description: Digital signature

Bug#809131: [Letsencrypt-devel] Bug#809131: python-acme: FTBFS: No local packages or download links found for urllib3==1.12

[Chris Lamb]

> >   Searching for urllib3==1.12
> 
> This should only happen in the condition that urllib3 isn't installed in
> the system Python paths; it is a dependency of python-requests,
> which is a dependency of python-acme.

This is actually #809031, which has now been fixed. I am therefore closing this 
bug in bcc.
 
> Can you please upload the complete build log

Was one not attached, out of interest? :)


Regards,

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

Bug#809178: python-letsencrypt: version 0.1.1-3 not installable, because of missing python-letsencrypt-apache >= 0.1.1

[Achim Schaefer]

Package: python-letsencrypt
Version: 0.1.0-2
Severity: important

Dear Maintainer,

I can not install the latest version, because the package python-letsencrypt 
breaks 
python-letsencrypt-apache < 0.1.1, but there is no verion >= 0.1.1 in the 
archive.

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

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

Versions of packages python-letsencrypt depends on:
ii  python-acme0.1.0-3
ii  python-configargparse  0.10.0-1
ii  python-configobj   5.0.6-2
ii  python-cryptography1.1.1-1
ii  python-dialog  3.3.0-2
ii  python-mock1.3.0-2.1
ii  python-openssl 0.15.1-2
ii  python-parsedatetime   1.4-1
ii  python-pkg-resources   18.8-1
ii  python-psutil  2.2.1-3+b1
ii  python-requests2.8.1-1
ii  python-rfc3339 1.0-4
ii  python-six 1.10.0-1
ii  python-tz  2012c+dfsg-0.1
ii  python-zope.component  4.2.2-1
ii  python-zope.interface  4.1.3-1
pn  python:any 

Versions of packages python-letsencrypt recommends:
ii  letsencrypt  0.1.0-2

python-letsencrypt suggests no packages.

-- no debconf information

Bug#809177: mysql-server-5.6: Easily create master/slave configuration for replication

[Victor Porton]

Package: mysql-server-5.6
Version: 5.6.27-2
Severity: wishlist

Dear Maintainer,

Please make a shell script which will automatically process current
configuraton and create working master/slave replication settings
for ease of doing backups without pausing the system operations.

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

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

Versions of packages mysql-server-5.6 depends on:
ii  adduser3.113+nmu3
ii  debconf [debconf-2.0]  1.5.58
ii  init-system-helpers1.24
ii  initscripts2.88dsf-59.2
ii  libaio10.3.110-2
ii  libc6  2.21-4
ii  libdbi-perl1.634-1
ii  libgcc11:5.3.1-4
ii  libstdc++6 5.3.1-4
ii  libwrap0   7.6.q-25
ii  lsb-base   9.20150917
ii  mysql-client-5.6   5.6.27-2
ii  mysql-common   5.6.27-2
ii  mysql-server-core-5.6  5.6.27-2
ii  passwd 1:4.2-3.1
ii  perl   5.20.2-6
ii  psmisc 22.21-2.1
ii  zlib1g 1:1.2.8.dfsg-2+b1

Versions of packages mysql-server-5.6 recommends:
ii  libhtml-template-perl  2.95-2

Versions of packages mysql-server-5.6 suggests:
ii  bsd-mailx [mailx]  8.1.2-0.20150408cvs-1
pn  tinyca 

-- debconf information excluded

Bug#809176: vlc: Should depend upon libqt5xcbqpa5

[Lisandro Damián Nicanor Pérez Meyer]

Package: vlc
Version: 2.2.1-5+b1
Severity: normal

Hi! Sebastian Ramacher told me that vlc is a X11-only app. In other words,
even if it's built against Qt5 it depends upon X11 itself (Qt5 apps can run
without X11).

If that's the case then it should depend upon libqt5xcbqpa5, which is the
pluging used by Qt5 to use X11.

This is the case of a non-automatic dependency (ie, not catched by our
Debian tools) like QML stuff.

Kinds regards, Lisandro.


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

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

Versions of packages vlc depends on:
ii  fonts-freefont-ttf  20120503-4
ii  libaa1  1.4p5-44
ii  libavcodec-ffmpeg-extra56   7:2.8.4-1
ii  libavutil-ffmpeg54  7:2.8.4-1
ii  libc6   2.21-4
ii  libcaca00.99.beta19-2+b1
ii  libcairo2   1.14.4-1
ii  libegl1-mesa [libegl1-x11]  11.0.7-1
ii  libfreerdp-client1.11.1.0~git20140921.1.440916e+dfsg1-5+b1
ii  libfreerdp-core1.1  1.1.0~git20140921.1.440916e+dfsg1-5+b1
ii  libfreerdp-gdi1.1   1.1.0~git20140921.1.440916e+dfsg1-5+b1
ii  libfreetype62.6.1-0.1
ii  libfribidi0 0.19.7-1
ii  libgcc1 1:5.3.1-4
ii  libgl1-mesa-glx [libgl1]11.0.7-1
ii  libgles1-mesa [libgles1]11.0.7-1
ii  libgles2-mesa [libgles2]11.0.7-1
ii  libglib2.0-02.46.2-1
ii  libpulse0   7.1-2
ii  libqt5core5a5.5.1+dfsg-9
ii  libqt5gui5  5.5.1+dfsg-9
ii  libqt5widgets5  5.5.1+dfsg-9
ii  libqt5x11extras55.5.1-3
ii  librsvg2-2  2.40.12-1
ii  libsdl-image1.2 1.2.12-5+b5
ii  libsdl1.2debian 1.2.15-12
ii  libstdc++6  5.3.1-4
ii  libva-drm1  1.6.2-1
ii  libva-x11-1 1.6.2-1
ii  libva1  1.6.2-1
ii  libvlccore8 2.2.1-5+b1
ii  libvncclient1   0.9.10+dfsg-3
ii  libx11-62:1.6.3-1
ii  libxcb-composite0   1.11.1-1
ii  libxcb-keysyms1 0.4.0-1
ii  libxcb-randr0   1.11.1-1
ii  libxcb-shm0 1.11.1-1
ii  libxcb-xv0  1.11.1-1
ii  libxcb1 1.11.1-1
ii  libxext62:1.3.3-1
ii  libxi6  2:1.7.5-1
ii  libxinerama12:1.1.3-1+b1
ii  libxpm4 1:3.5.11-1+b1
ii  vlc-nox 2.2.1-5+b1
ii  zlib1g  1:1.2.8.dfsg-2+b1

Versions of packages vlc recommends:
ii  vlc-plugin-notify  2.2.1-5+b1
ii  vlc-plugin-samba   2.2.1-5+b1
ii  xdg-utils  1.1.1-1

vlc suggests no packages.

-- no debconf information

Bug#809175: sbuild: Doesn't want to build pkg with only linux-any architecture

[Laurent Bigonville]

Package: sbuild
Version: 0.67.0-1
Severity: important

Hi,

This is probably also related to the perl transition.

sbuild doesn't want to build a source package with only linux-any
architecture binary packages:

Check architectures
---

Bareword "amd64" not allowed while "strict subs" in use at -e line 4.
Bareword "linux" not allowed while "strict subs" in use at -e line 4.
Bareword "any" not allowed while "strict subs" in use at -e line 4.
Execution of -e aborted due to compilation errors.
setools_3.3.8+20151215-1.dsc: amd64 not in arch list or does not match any arch 
wildcards: linux-any -- skipping

This is pretty annoying

Cheers,

Laurent Bigonville

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

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

Versions of packages sbuild depends on:
ii  adduser 3.113+nmu3
ii  apt-utils   1.1.8
ii  libsbuild-perl  0.67.0-1
ii  perl5.22.1-3

Versions of packages sbuild recommends:
ii  debootstrap  1.0.75
ii  fakeroot 1.20.2-1

Versions of packages sbuild suggests:
ii  deborphan  1.7.28.8-0.2
ii  wget   1.17.1-1

-- no debconf information

Bug#809172: [libqt5xcbqpa5] lib libqt5xcbqpa5 will not be installed as a dependency

[Lisandro Damián Nicanor Pérez Meyer]

reassign 809172 kwin-x11
severity 809172 important
retitle 809172 kwin-x11 should depend upon libqt5xcbqpa5
thanks



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

Bug#809172: [libqt5xcbqpa5] lib libqt5xcbqpa5 will not be installed as a dependency

[Lisandro Damián Nicanor Pérez Meyer]

severity 809172 important
reassign 809172 kwin-x11
thanks

On Sunday 27 December 2015 21:50:14 Singer Michael wrote:
> Package: libqt5xcbqpa5
> Version: 5.5.1+dfsg-10
> Severity: grave
> 
> --- Please enter the report below this line. ---
> 
> Dear Maintainer,
> When you install the KDE desktop, the libqt5xcbqpa5 is not installed. A
> start of the KDE desktop thus aborts.
> 
> If you install the libqt5xcbqpa5 via apt after you can start the desktop
> again.

From here we can assert some things:

- The problem is not really libqt5xcbqpa5 but whoever needs it. No, it's not 
Qt itself (read below).
- There is a known workaround and no data is lost, so severity should be kept 
at most as important.
- Normally people who disable recommends will get this problem, and also some 
cases in where 

> A similar bug report (closed), there was already in October 2015 strongly
> #802656.

Right, but that "solution" actually created a circular dependency with 
libqt5gui5. And moreover Qt5 apps do not necessarily need this dependency, as 
they normally can work with other QPA plugins.

Apps who do really need X11 (kwin-x11 is a good example) should depend on this 
package.

I'm reassigning this bug to kwin-x11 for now. Maxy, feel free to reassign it 
as needed. Maybe some other KF5 lib is a better target.

Kinds regards, Lisandro.

-- 
Wiki is not WysiWyg. It's an intelligence test of sorts to be able to edit a
wiki page. It's not rocket science, but it doesn't appeal to the VideoAddicts.
If it doesn't appeal, they don't participate, which leaves those of us who
read and write to get on with rational discourse.
  http://www.c2.com/cgi/wiki?WhyWikiWorks

Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/


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

Bug#794238: how-can-i-help: provide a machine parsable output

[Lucas Nussbaum]

On 31/07/15 at 16:04 +0200, Raphaël Hertzog wrote:
> Package: how-can-i-help
> Version: 11
> Severity: wishlist
> User: de...@kali.org
> Usertags: origin-kali
> 
> In Kali we would like to detect when Debian package that we are using
> are at risk (mainly for testing autoremoval for now). Thus we want
> to run "how-can-i-help -s testing-autorm" as part of a jenkins job.
> We would benefit from a structured output to be able to do things like:
> 
> * fail only when when the removal date is less than 15 days
> * filter out some packages that we don't care about (because
>   we have our own fork, or because they are only recommends,
>   etc.)
> 
> Obviously we can parse the current output but it's sub-optimal.

Hi Raphael,

Wouldn't it be easier for you to use the data exported by UDD?
https://udd.debian.org/how-can-i-help.json.gz

the how-can-i-help simply downloads this and compare with the list of
locally installed packages.

Lucas

Bug#809174: dpkg-deb: "error: invalid integer for --(null)" in option parsing

[Daniel Shahaf]

Package: dpkg
Version: 1.18.4
Severity: minor

Dear Maintainer,

Consider the following error message:

$ dpkg-deb -z foo
dpkg-deb: error: invalid integer for --(null): 'foo'

Type dpkg-deb --help for help about manipulating *.deb files;
Type dpkg --help for help about installing and deinstalling packages.

The error message shouldn't be saying "--(null)", first of all because there's
no such option, and second of all because passing a NULL pointer to the %s
formatter of printf(3) is undefined behaviour.

Cheers,

Daniel


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

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

Versions of packages dpkg depends on:
ii  libbz2-1.0   1.0.6-8
ii  libc62.21-6
ii  liblzma5 5.1.1alpha+20120614-2.1
ii  libselinux1  2.4-3
ii  tar  1.28-2.1
ii  zlib1g   1:1.2.8.dfsg-2+b1

dpkg recommends no packages.

Versions of packages dpkg suggests:
ii  apt  1.1.8

-- debconf-show failed

Bug#728441: Now FTBFS everywhere

[Wouter Verhelst]

Source: mozart
Followup-For: Bug #728441

Hi,

Mozart now fails to build on all architectures, since it build-depends
on emacs23, which is no longer a thing (at least not in Debian).

Please update it to build-depend on modern emacs versions.

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

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

Bug#809173: gnupg: occasional error "key ... not found on keyserver"

[Vincent Lefevre]

Package: gnupg
Version: 1.4.20-1
Severity: normal

I got the following error:

cventin:~/software> gpg --verify gmp-6.1.0.tar.xz.sig
gpg: assuming signed data in `gmp-6.1.0.tar.xz'
gpg: Signature made 2015-11-01T17:04:59 CET using DSA key ID 501441DF
gpg: requesting key 501441DF from hkp server keys.gnupg.net
gpgkeys: key DDEF6956501441DF not found on keyserver
gpg: no valid OpenPGP data found.
gpg: Total number processed: 0
gpg: keyserver communications error: key not found
gpg: keyserver communications error: bad public key
gpg: Can't check signature: public key not found
zsh: exit 2 gpg --verify gmp-6.1.0.tar.xz.sig

Then I tried on another machine, where I got:

gpg: requesting key 501441DF from hkp server keys.gnupg.net
gpg: key C1A000B0: public key "Marco Bodrato " imported

showing that the key was really on the server.

I tried again on the first machine: same error.

After several dozens of minutes, I tried again on the first machine,
and the key could be imported.

In case there was some other error, this could be like the following
bug: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=642512
(note that I don't use a proxy).

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

Kernel: Linux 4.3.0-1-amd64 (SMP w/12 CPU cores)
Locale: LANG=POSIX, 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 gnupg depends on:
ii  gpgv  1.4.20-1
ii  libbz2-1.01.0.6-8
ii  libc6 2.21-6
ii  libreadline6  6.3-8+b4
ii  libusb-0.1-4  2:0.1.12-27
ii  zlib1g1:1.2.8.dfsg-2+b1

Versions of packages gnupg recommends:
pn  gnupg-curl 
ii  libldap-2.4-2  2.4.42+dfsg-2+b1

Versions of packages gnupg suggests:
ii  eog   3.18.1-1
ii  gnupg-doc 2003.04.06+dak1-1
ii  imagemagick   8:6.8.9.9-6+b1
ii  libpcsclite1  1.8.15-1
pn  parcimonie

-- no debconf information

Bug#809131: [Letsencrypt-devel] Bug#809131: python-acme: FTBFS: No local packages or download links found for urllib3==1.12

[Harlan Lieberman-Berg]

>   Searching for urllib3==1.12

This should only happen in the condition that urllib3 isn't installed in
the system Python paths; it is a dependency of python-requests,
which is a dependency of python-acme.

Can you please upload the complete build log, including dependency calculation
and installation?

Sincerely,
-- 
Harlan Lieberman-Berg
~hlieberman

Bug#805027: [Letsencrypt-devel] Bug#805027: [python-acme] not building on jessie

[Harlan Lieberman-Berg]

Hello everyone,

We are definitely planning on trying to get letsencrypt into
jessie-backports.  At the moment, we're waiting on the upload of a
couple of its dependencies into backports; I've been talking to the
maintainers of those packages to try and move that process along.

It will, unfortunately, FTBFS with some of the dependencies that are
currently in jessie and jessie-backports.

Sincerely,
-- 
Harlan Lieberman-Berg
~hlieberman

Bug#805835: voxbo: Fails to build with GSL 2

[peter green]

severity 805835 serious
tags 805835 +patch
thanks


Your package fails to build with GSL 2:
   

Ubuntu has a fix for this

https://launchpad.net/ubuntu/+source/voxbo
https://patches.ubuntu.com/v/voxbo/voxbo_1.8.5~svn1246-1.1ubuntu2.patch

Bug#809172: [libqt5xcbqpa5] lib libqt5xcbqpa5 will not be installed as a dependency

[Singer Michael]

Package: libqt5xcbqpa5
Version: 5.5.1+dfsg-10
Severity: grave

--- Please enter the report below this line. ---

Dear Maintainer,
When you install the KDE desktop, the libqt5xcbqpa5 is not installed. A start 
of the KDE desktop thus aborts.

If you install the libqt5xcbqpa5 via apt after you can start the desktop 
again.

A similar bug report (closed), there was already in October 2015 strongly 
#802656.

Regards 
Michael Singer

--- System information. ---
Architecture: amd64
Kernel:   Linux 4.3.3-towo.1-siduction-amd64

Debian Release: stretch/sid
  500 unstablehttpredir.debian.org 
  500 unstableftp.uni-stuttgart.de 

--- Package information. ---
Package's Depends field is empty.

Package's Recommends field is empty.

Package's Suggests field is empty.

Bug#807099: marked as done (RFS: corsix-th/0.50-1 ITP 610087 - A Theme Hospital engine reimplementation.)

[Markus Koschany]

Control: reopen -1

The package will close this bug report automatically when it enters the
archive. Please keep this bug report open until until corsix-th got
accepted.

Thanks,

Markus



signature.asc
Description: OpenPGP digital signature

Bug#805698: Info received (Bug#805698: Acknowledgement (gcc-4.8: FTBFS on hppa: Control dependency for binutils-hppa64 needs update for new package name))

[John David Anglin]

Sorry, ignore last message.

Dave
--
John David Anglin   dave.ang...@bell.net

Bug#808916: linux-image-4.3.0-1-amd64: non-blocking stack trace crash during startup (drm/i915) in drm_atomic_check_only+0x46f/0x540

[Sven Joachim]

On 2015-12-24 12:48 +0100, Christophe wrote:

> Package: src:linux
> Version: 4.3.3-2
> Severity: normal
> Tags: upstream
>
> Dear Maintainer,
>
> Having just updated my Debian Testing to the 4.3 kernel from 3.16, I
> have noticed the stack trace below during boot, which does not seem to
> disturb further operation.

I noticed a very similar stacktrace myself with a self-compiled 4.3
kernel, but...

> It may be worth reporting upstream, or it may be already fixed as
> there's been changes in this part?

...they went away when I upgraded to 4.4-rc5, so it might be a
good idea for you to try a 4.4.0-rc6 kernel from experimental.

Cheers,
   Sven

Bug#802212: Patch

[Chad Wallace]

Here's another version of that patch...  with a free(dotdir) after
we're done with it.


-- 

C. Chad Wallace, B.Sc.
The Lodging Company
http://www.lodgingcompany.com/
OpenPGP Public Key ID: 0x262208A0

Description: avoid NO_MODULE_DATA error
Author: Chad Wallace 
Last-Update: 2015-12-27

--- a/pam_ssh.c	2015-12-27 12:08:42.851136447 -0800
+++ b/pam_ssh.c	2015-12-27 12:12:47.619240920 -0800
@@ -1089,6 +1089,7 @@
 	const struct passwd *pwent;	/* user's passwd entry */
 	struct stat sb;			/* to check st_nlink */
 	const char *user;   /* username */
+	char *dotdir;		/* .ssh dir name */
 
 	pam_ssh_log(LOG_DEBUG, "close session");
 
@@ -1108,6 +1109,21 @@
 		return retval;
 	}
 
+	/* handle the per-user configuration directory and check its existence */
+
+	if (asprintf(&dotdir, "%s/%s", pwent->pw_dir, SSH_DIR) == -1) {
+		pam_ssh_log(LOG_CRIT, "out of memory");
+		openpam_restore_cred(pamh);
+		return PAM_SERVICE_ERR;
+	}
+	if ((access(dotdir,F_OK)) == -1) {
+		pam_ssh_log(LOG_DEBUG, "inexistent configuration directory");
+		free(dotdir);
+		openpam_restore_cred(pamh);
+		return PAM_SUCCESS;
+	}
+	free(dotdir);
+
 	if (pam_get_data(pamh, "ssh_agent_env_session",
 	(const void **)(void *)&env_file) == PAM_SUCCESS && env_file)
 		unlink(env_file);

Bug#805698: Acknowledgement (gcc-4.8: FTBFS on hppa: Control dependency for binutils-hppa64 needs update for new package name)

[John David Anglin]

Fixed by rebuild of shadow.

Dave
--
John David Anglin   dave.ang...@bell.net

Bug#807099: RFS: corsix-th/0.50-1 ITP 610087 - A Theme Hospital engine reimplementation.

[Markus Koschany]

Am 27.12.2015 um 09:35 schrieb Alexandre Detiste:
> Le samedi 26 décembre 2015, 22:46:05 Markus Koschany a écrit :
>> The package looks good to me. Please add the missing license of tinyxml
>> to debian/copyright. 
> 
> Done

Uploaded. Thanks for your contribution.

Markus




signature.asc
Description: OpenPGP digital signature

Bug#809161: Info received (Bug#809161: Acknowledgement (libaudit1: Segmention fault running su and no console access))

[John David Anglin]

Fixed by rebuild of shadow.

Dave
--
John David Anglin   dave.ang...@bell.net

Bug#802212: Patch

[Chad Wallace]

Hello,

I've created a patch that seems to fix this for me.  All I did was copy
the code that checks for ".ssh" from pam_sm_open_session() into
pam_sm_close_session() so it can just not do anything, and return 
PAM_SUCCESS.

I don't know if that's the right solution, but it seems appropriate to
me.  I've only tested that it works for me:  it avoids printing "su: No
module specific data is present" when I run /etc/cron.daily/dwww 
and logging in remotely using my SSH key still works.

Thanks!

-- 

C. Chad Wallace, B.Sc.
The Lodging Company
http://www.lodgingcompany.com/
OpenPGP Public Key ID: 0x262208A0

Description: avoid NO_MODULE_DATA error
Author: Chad Wallace 
Last-Update: 2015-12-27

--- a/pam_ssh.c	2015-12-27 10:54:47.985792204 -0800
+++ b/pam_ssh.c	2015-12-27 10:54:08.231097492 -0800
@@ -1089,6 +1089,7 @@
 	const struct passwd *pwent;	/* user's passwd entry */
 	struct stat sb;			/* to check st_nlink */
 	const char *user;   /* username */
+	char *dotdir;		/* .ssh dir name */
 
 	pam_ssh_log(LOG_DEBUG, "close session");
 
@@ -1108,6 +1109,20 @@
 		return retval;
 	}
 
+	/* handle the per-user configuration directory and check its existence */
+
+	if (asprintf(&dotdir, "%s/%s", pwent->pw_dir, SSH_DIR) == -1) {
+		pam_ssh_log(LOG_CRIT, "out of memory");
+		openpam_restore_cred(pamh);
+		return PAM_SERVICE_ERR;
+	}
+	if ((access(dotdir,F_OK)) == -1) {
+		pam_ssh_log(LOG_DEBUG, "inexistent configuration directory");
+		free(dotdir);
+		openpam_restore_cred(pamh);
+		return PAM_SUCCESS;
+	}
+
 	if (pam_get_data(pamh, "ssh_agent_env_session",
 	(const void **)(void *)&env_file) == PAM_SUCCESS && env_file)
 		unlink(env_file);

Bug#489466: gui-apt-key NMU uploaded to DELAYED/15

[Axel Beckert]

Control: tag -1 + pending

Hi,

after an e-mail discussion with Joey in private, I've just uploaded an
NMU to DELAYED/15 (see https://ftp-master.debian.org/deferred.html)
fixing this and some other "low-hanging fruit" bug reports in
gui-apt-key.

Full debdiff attached.

Regards, Axel
-- 
 ,''`.  |  Axel Beckert , http://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE
diff -u gui-apt-key-0.4/debian/rules gui-apt-key-0.4/debian/rules
--- gui-apt-key-0.4/debian/rules
+++ gui-apt-key-0.4/debian/rules
@@ -52,13 +52,13 @@
$(installbin) debian/{postinst,postrm} debian/tmp/DEBIAN/
$(installdoc) debian/changelog 
debian/tmp/usr/share/doc/$(package)/changelog.Debian
$(installdoc) debian/copyright debian/tmp/usr/share/doc/$(package)/
-   gzip -9f debian/tmp/usr/share/doc/$(package)/changelog.Debian
+   gzip -9fn debian/tmp/usr/share/doc/$(package)/changelog.Debian
#
$(installdoc) CHANGES debian/tmp/usr/share/doc/$(package)/changelog
-   gzip -9f debian/tmp/usr/share/doc/$(package)/changelog
+   gzip -9fn debian/tmp/usr/share/doc/$(package)/changelog
#
make prefix=`pwd`/debian/tmp/usr install
-   gzip -9 debian/tmp/usr/share/man/man?/*
+   gzip -9n debian/tmp/usr/share/man/man?/*
ln -s gak debian/tmp/usr/sbin/gui-apt-key
ln -s gak.8.gz debian/tmp/usr/share/man/man8/gui-apt-key.8.gz
#
diff -u gui-apt-key-0.4/debian/changelog gui-apt-key-0.4/debian/changelog
--- gui-apt-key-0.4/debian/changelog
+++ gui-apt-key-0.4/debian/changelog
@@ -1,3 +1,14 @@
+gui-apt-key (0.4-2.1) unstable; urgency=medium
+
+  * Non-maintainer upload with maintainer permission.
+  * Support /etc/apt/trusted.gpg.d/ (closes: Bug#746573, Bug#746574)
+  * Fix deprecation warning in Gtk2::AboutDialog (closes: Bug#499145,
+LP: #270836)
+  * Update Turkish translation by Mert Dirik. (closes: Bug#489466)
+  * Make the build reproducible. (closes: Bug#777240)
+
+ -- Axel Beckert   Sun, 27 Dec 2015 19:08:20 +0100
+
 gui-apt-key (0.4-2) unstable; urgency=low
 
   * Remove gksu recommends
only in patch2:
unchanged:
--- gui-apt-key-0.4.orig/GAK/Backend.pm
+++ gui-apt-key-0.4/GAK/Backend.pm
@@ -24,7 +24,8 @@
 do_add do_delete do_update/;
 
 use constant SECRING => '/etc/apt/secring.gpg';
-use constant KEYRING => '/etc/apt/trusted.gpg';
+use constant KEYRING => ('/etc/apt/trusted.gpg',
+ glob('/etc/apt/trusted.gpg.d/*.gpg'));
 use constant TRUSTDB => '/etc/apt/trustdb.gpg';
 
 use constant KEYSERVER => 'hkp://subkeys.pgp.net';
@@ -42,7 +43,7 @@
 --with-colons --list-keys
 2> /dev/null};
 $cmd =~ s/\r?\n//g;
-$cmd = sprintf ($cmd, SECRING, TRUSTDB, KEYRING);
+$cmd = sprintf ($cmd, SECRING, TRUSTDB, join(' --keyring ', KEYRING));
 
 if (open (G, "$cmd|")) {
while () {
@@ -68,7 +69,7 @@
 --keyring %s
 --with-colons --list-key %s};
 $cmd =~ s/\r?\n//g;
-$cmd = sprintf ($cmd, SECRING, TRUSTDB, KEYRING, $key);
+$cmd = sprintf ($cmd, SECRING, TRUSTDB, join(' --keyring ', KEYRING), 
$key);
 
 if (open (G, "$cmd|")) {
while () {
@@ -94,7 +95,7 @@
 --keyring %s
 --with-colons --fingerprint %s};
 $cmd =~ s/\r?\n//g;
-$cmd = sprintf ($cmd, SECRING, TRUSTDB, KEYRING, $key);
+$cmd = sprintf ($cmd, SECRING, TRUSTDB, join(' --keyring ', KEYRING), 
$key);
 
 if (open (G, "$cmd|")) {
while () {
only in patch2:
unchanged:
--- gui-apt-key-0.4.orig/GAK/GUI.pm
+++ gui-apt-key-0.4/GAK/GUI.pm
@@ -242,7 +242,7 @@
 sub callback_about
 {
 $about = new Gtk2::AboutDialog;
-$about->set_name (_('APT Key Manager'));
+$about->set_program_name (_('APT Key Manager'));
 $about->set_website_label ('http://www.infodrom.org/projects/gak/');
 $about->set_authors ('Joey Schulze ');
 $about->set_copyright ('(c) 2006-8 Joey Schulze ');
only in patch2:
unchanged:
--- gui-apt-key-0.4.orig/po/tr.po
+++ gui-apt-key-0.4/po/tr.po
@@ -7,21 +7,21 @@
 "Project-Id-Version: gui-apt-key\n"
 "Report-Msgid-Bugs-To: \n"
 "POT-Creation-Date: 2007-11-11 22:56+0100\n"
-"PO-Revision-Date: 2006-11-18 03:21+0200\n"
-"Last-Translator: Recai Oktaş \n"
+"PO-Revision-Date: 2008-07-06 02:47+0200\n"
+"Last-Translator: Mert Dirik \n"
 "Language-Team: Debian L10n Turkish \n"
 "MIME-Version: 1.0\n"
 "Content-Type: text/plain; charset=UTF-8\n"
 "Content-Transfer-Encoding: 8bit\n"
-"Plural-Forms:  nplurals=1; plural=0;\n"
+"Plural-Forms: nplurals=1; plural=0;\n"
 
 #: ../GAK/GUI.pm:38
 msgid "_Import File"
-msgstr "_Anahtar Dosyası"
+msgstr "_İçe Dosya Aktar"
 
 #: ../GAK/GUI.pm:43
 msgid "_Update Keys"
-msgstr " _Anahtarları Güncelle"
+msgstr "Anahtarları _Güncelle"
 
 #: ../GAK/GUI.pm:48
 msgid "E_xit"
@@ -45

Bug#809171: Please handle network device hotplug events (move from udev)

[Martin Pitt]

Package: ifupdown
Severity: wishlist
Version: 0.8.4

Hello,

for historical reasons the udev package has shipped the functionality
for handling network device hotplug events. However, it's a bit weird
to ship the coldplugging parts (/etc/init.d/networking and
networking.service) in ifupdown, but not the hotplugging ones. It
would be more consistent to ship both in ifupdown and also make it
easier to do changes. Of course the systemd packagers are still happy
to discuss changes to the udev bits and provide guidance.

This involves three parts:

 * An udev rule which reacts to adding or removing network devices.
   This is currently shipped as /lib/udev/rules.d/80-networking.rules
   but I propose that ifupdown ships it as
   /lib/udev/rules.d/80-ifupdown.rules to avoid a package file
   conflict and also to make it clearer that this applies to ifupdown
   only. I attach this as 80-ifupdown.rules.

 * The above rule just calls an udev helper script "ifupdown" which
   needs to be put into /lib/udev/. This does the actual work of
   calling either ifup $IFACE directly (under SysV init or upstart) or
   a systemd unit "ifup@IFACE.service" under systemd. The latter is
   necessary as udev rules must not start long-running programs (ifup
   can take quite long), and it also provides much nicer and cleaner
   logging, a proper shutdown order, etc.

   I attach this as "ifupdown".

 * The ifup@.service helper unit. This should go into

 `pkg-config --variable=systemdsystemunitdir systemd`

   aka /lib/systemd/system/. It does not need to be enabled in any way
   as the above udev helper rule will start/stop it.

   Note that this will file-conflict with udev with this name, so
   if/once you accept this we'll need to remove the above bits from
   udev and add a Breaks:/Replaces: to ifupdown and a Breaks: to udev.

Please let us know if you have any questions about these!

Thanks for considering,

Martin

-- 
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)
#!/bin/sh -e
#
# run /sbin/{ifup,ifdown} with the --allow=hotplug option.
#

PATH='/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin'

if [ -x /usr/bin/logger ]; then
LOGGER=/usr/bin/logger
elif [ -x /bin/logger ]; then
LOGGER=/bin/logger
else
unset LOGGER
fi

# for diagnostics
if [ -t 1 -a -z "$LOGGER" ] || [ ! -e '/dev/log' ]; then
mesg() {
echo "$@" >&2
}
elif [ -t 1 ]; then
mesg() {
echo "$@"
$LOGGER -t "${0##*/}[$$]" "$@"
}
else
mesg() {
$LOGGER -t "${0##*/}[$$]" "$@"
}
fi

if [ -z "$INTERFACE" ]; then
mesg "Bad ifupdown udev helper invocation: \$INTERFACE is not set"
exit 1
fi

check_program() {
[ -x $1 ] && return 0

mesg "ERROR: $1 not found. You need to install the ifupdown package."
mesg "ifupdown udev helper $ACTION event for $INTERFACE not handled."
exit 1
}

wait_for_interface() {
local interface=$1
local state

while :; do
read state /sys/class/net/$interface/operstate 2>/dev/null || true
if [ "$state" != down ]; then
return 0
fi
sleep 1
done
}

net_ifup() {
check_program /sbin/ifup

# exit if the interface is not configured as allow-hotplug
if ! ifquery --allow hotplug -l | grep -q "^${INTERFACE}\$"; then
exit 0
fi

if [ -d /run/systemd/system ]; then
exec systemctl --no-block start $(systemd-escape --template 
ifup@.service $INTERFACE)
fi

local out=$(ps -C ifup ho args)
if [ "${out%$INTERFACE*}" != "$out" ]; then
mesg "Already ifup-ing interface $INTERFACE"
exit 0
fi

wait_for_interface lo

exec ifup --allow=hotplug $INTERFACE
}

net_ifdown() {
check_program /sbin/ifdown

# systemd will automatically ifdown the interface on device
# removal by binding the instanced service to the network device
if [ -d /run/systemd/system ]; then
exit 0
fi

local out=$(ps -C ifdown ho args)
if [ "${out%$INTERFACE*}" != "$out" ]; then
mesg "Already ifdown-ing interface $INTERFACE"
exit 0
fi

exec ifdown --allow=hotplug $INTERFACE
}

do_everything() {

case "$ACTION" in
add)
# these interfaces generate hotplug events *after* they are brought up
case $INTERFACE in
ppp*|ippp*|isdn*|plip*|lo|irda*|ipsec*)
exit 0 ;;
esac

net_ifup
;;

remove)
# the pppd persist option may have been used, so it should not be killed
case $INTERFACE in
ppp*)
exit 0 ;;
esac

net_ifdown
;;

*)
mesg "NET $ACTION event not supported"
exit 1
;;
esac

}

# under systemd we don't do synchronous operations, so we can run in the
# foreground; we also need to, as forked children get killed right away under
# systemd
if [ -d /run/systemd/system ]; then

Bug#809169: [PATCH] Allow setting the MTU and HWADDR on manual interfaces

[Guus Sliepen]

On Sun, Dec 27, 2015 at 08:33:14PM +0100, Martin Pitt wrote:

> In https://launchpad.net/bugs/1294807 it was reported that the "mtu"
> and "hwaddress" options do not work with "manual" interfaces. Stéphane
> (CC'ed) fixed this in Ubuntu a while ago. This seems useful for Debian
> as well, so I adjusted this to current Debian git head.

Thanks a lot, I applied the patch and pushed it!

-- 
Met vriendelijke groet / with kind regards,
  Guus Sliepen 


signature.asc
Description: Digital signature

Bug#809170: False-positive source-is-missing for Midori (data/autosuggestcontrol.js)

[Sergio Durigan Junior]

Package: lintian
Version: 2.5.38.1
Severity: normal

Building the latest version of Midori on Debian (0.5.11-2) triggers a
false-positive source-is-missing error due to the file
data/autosuggestcontrol.js.  As can be seen here:

  

The source code is not missing.  I am overriding this error for now,
until you fix the problem on lintian.

Thanks,

-- 
Sergio
GPG key ID: 237A 54B1 0287 28BF 00EF  31F4 D0EB 7628 65FC 5E36
Please send encrypted e-mail if possible
http://sergiodj.net/


signature.asc
Description: PGP signature

Bug#809166: networking.service does not prevent ifdown with network file systems

[Guus Sliepen]

On Sun, Dec 27, 2015 at 07:58:06PM +0100, Martin Pitt wrote:

> Package: ifupdown
> Version: 0.8
> 
> /etc/init.d/networking has some functionality to check if the root
> file system or swap are on a network file system, in
> check_network_file_systems() and check_network_swap(). In that case,
> the interfaces are not ifdown'ed during shutdown, so that these
> network file systems can be cleanly unmouted at the very end.
> 
> However, the new networking.service does not do that.  So unmounting
> these network file systems will hang and fail as the interface is
> already down. Root on NFS or even more so iSCSI is rather popular, so
> this is quite an important regression.

Please check if the problem still exists with version 0.8.4. Version 0.8
didn't correctly order itself with respect to network-online.target, but
0.8.4 should have fixed that.

> Perhaps these checks can be put into ifdown itself and be done with
> "ifdown -a"? Then you can still ifdown an individual interface (which
> is usually deliberately done by the admin, even if it means shooting
> yourself into the foot), but it would DTRT when being called by the
> init.d script or the systemd unit. Alternatively this could become a
> new option such as --check-netfs that the init scripts use.

No, I won't put such checks in ifdown itself, it should be fixed now.
And if you manually ifdown an interface that is necessary for a network
mount, you can easily ifup it manually to fix it.

-- 
Met vriendelijke groet / with kind regards,
  Guus Sliepen 


signature.asc
Description: Digital signature

Bug#805894: jessie-pu: package mdadm/3.3.2-5+deb8u1

[Cyril Brulebois]

Adam D. Barratt  (2015-12-27):
> Control: tags -1 + confirmed
> 
> On 2015-11-23 17:29, Yann Soubeyrand wrote:
> >I prepared a package for mdadm containing a patch to fix bug #784070
> >(https://bugs.debian.org/784070) which prevents booting a software RAID
> >1 in degraded mode. The diff is attached to this message.
> >
> >The previous package maintainer (Michael Tokarev) confirmed the source of
> >the
> >problem (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=784070#49) and
> >several users confirmed that the patch fixes the bug. Moreover, the new
> >package maintainer (Dimitri John Ledkov, CC of this mail) agreed with this
> >solution and gave me his consent to proceed with the upload
> >(https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=784070#230).
> 
> I do slightly worry that this may re-introduce issues that the use of
> incremental assembly was intended to work around, but from reading the bug
> report it seems that the issues with incremental assembly are probably now
> affecting more users.
> 
> Please go ahead with the upload. I've CCed the installer list to ensure that
> they're aware of the change.

Can't really judge but if Dimitri is fine with it, let's go ahead
indeed. Thanks for the informational mail.

Mraw,
KiBi.


signature.asc
Description: Digital signature

Bug#807801: Sponsoring for upload CVE-2015-8547

[Salvatore Bonaccorso]

Hi Pierre,

Thanks for you quick reply, really appreciated.

On Sun, Dec 27, 2015 at 10:55:28AM +0100, Pierre Schweitzer wrote:
> Hi Salvatore,
> 
> On 27/12/2015 09:09, Salvatore Bonaccorso wrote:
> > Hi Pierre,
> > 
> > On Mon, Dec 14, 2015 at 10:28:26PM +0100, Pierre Schweitzer wrote:
> >> Dear all,
> >>
> >> After having asked for a CVE[0] for this Quassel issue [1], I've
> >> uploaded you (attached) a debdiff & dsc to the bug report for an upload.
> >> Would you be able to sponsor the upload, as I can't?
> >> Or perhaps the maintainers are available for the upload?
> > 
> > Can you help me evaluating the issue, since I'm not a quassel user
> > myself: From a quick search and a bit of testing with a
> > quassel-client/quassel-core setup, am I right that
> > 
> >  a/ multi-user setups with quassel-core are non-default and not
> > so frequent?
> 
> It's hard to say. However, there are no well-known Quassel providers (as
> you would have for ZNC/BNC).
> 
> >  b/ This issue can (only) be triggered by a client connected to a
> > quassel core?
> 
> Yes.

I think this then can be fixed via a Jessie point release, which is
around the corner. Can you contact the SRM to have it scheduled via
jessie-pu?

Cf.
https://www.debian.org/doc/manuals/developers-reference/ch05.en.html#upload-stable

You can add me to Cc when you fill the bug against release.debian.org,
if you then need a sponsor after the ack of the stable release
managers.

(n.b.: the targetting distribution needs to be changed to jessie in
the debdiff in this case).

Regards,
Salvatore

Bug#801973: [Pkg-roundcube-maintainers] Bug#801973: Bug#801973: error 255 on package configuration

[Sandro Knauß]

Control: severity -1 important

Hey,

I also tried to reproduce the problem with piuparts and it went through 
smoothly (1.1.2+dfsg.1-4~bpo8+2 -> 1.1.2+dfsg.1-5 -> 1.1.3+dfsg.1-1). The only 
difference is that in that case mysql-server is used instead of mariadb for 
piuparts. But the problems with the symbolic links shouldn't change with that.

Furthermore piuparts also reports about missing files on the system and there 
is no missing symbolic link in /usr/lib/roundcube and  /usr/share/roundcube/

So all mainatiners are unable to reproduce it. 

I lower the severity, because it looks like a special installation problem and 
not a general problem in the package.

regards,

sandro

used commad to test:

mk-sbuild jessie
(add the  apt -o Acquire::Check-Valid-Until=false to the schroot env )

/usr/sbin/piuparts \
 --log-level=dump \
 --warn-on-others \
 --no-eatmydata \
 --warn-on-leftovers-after-purge \
 --skip-logrotatefiles-test \
 --scriptsdir /etc/piuparts/scripts \
 -m http://snapshot.debian.org/archive/debian/20151020T033513Z \
 -d jessie-backports \
 -d stretch \
 -d sid \
 --do-not-verify-signatures \
 --schroot jessie-amd64 \
 --apt \
 --extra-old-packages=roundcube-core \
 roundcube 

Am Tuesday 01 December 2015, 00:44:52 schrieb Guilhem Moulin:
> Control: tags -1 + moreinfo unreproducible
> 
> Any news on that, e-mmanuel?  It would be great if we could avoid the
> autoremoval from testing ;-)
> 
> On Mon, 19 Oct 2015 at 21:15:00 +0200, e-mmanuel wrote:
> > the problem occurs on my other server.
> > Both are clean (production servers).
> 
> FWIW, it's not because a server is used in production that it is clean
> (in fact it most likely means it's not).  Vincent and I were not able
> able to reproduce your bug in a clean chroot.  I just double checked
> with a fresh jessie install (with the default settings and only standard
> system utilities):  I was able to upgrade both from 0.7.2-9+deb7u1 and
> 1.1.2+dfsg.1-4 to 1.1.3+dfsg.1-1.
> 
>   echo 'deb http://snapshot.debian.org/archive/debian/20150911T101115Z/
> unstable main' >/etc/apt/sources.list apt -o
> Acquire::Check-Valid-Until=false update
>   apt-get dist-upgrade
>   systemctl reboot
>   ###
>   apt install mariadb-server
>   apt install php5-{fpm,mysql} roundcube-{core,mysql,plugins}
>   echo 'deb http://ftp.se.debian.org/debian/ unstable main'
> >/etc/apt/sources.list apt update
>   apt upgrade
> 
> Also, reportbug showed only the version of roundcube-core's
> dependencies.  Could you do the same for roundcube-*?


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

Bug#802557: Several packages now using Build-Depends-Arch, FTBFS under pbuilder

[Daniel Schepler]

I now see FTBFS due to this issue in at least:
botch
mplayer
ncbi-tools6
-- 
Daniel Schepler

Bug#809169: [PATCH] Allow setting the MTU and HWADDR on manual interfaces

[Martin Pitt]

Package: ifupdown
Severity: wishlist
Version: 0.8.4
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu ubuntu-patch xenial

Hello,

In https://launchpad.net/bugs/1294807 it was reported that the "mtu"
and "hwaddress" options do not work with "manual" interfaces. Stéphane
(CC'ed) fixed this in Ubuntu a while ago. This seems useful for Debian
as well, so I adjusted this to current Debian git head.

Thanks for considering,

Martin

-- 
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)
From a0f0d508edacd262b51c2aee73909be6443e6d68 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?St=C3=A9phane=20Graber?= 
Date: Sun, 27 Dec 2015 20:29:11 +0100
Subject: [PATCH] Allow setting the MTU and HWADDR on manual interfaces

Bug-Ubuntu: https://launchpad.net/bugs/1294807
---
 inet.defn  | 10 ++
 inet6.defn | 10 ++
 2 files changed, 20 insertions(+)

diff --git a/inet.defn b/inet.defn
index 67d2a54..7f6f396 100644
--- a/inet.defn
+++ b/inet.defn
@@ -55,9 +55,19 @@ method manual
 is done by default.  Such interfaces can be configured manually by
 means of *up* and *down* commands or /etc/network/if-*.d scripts.
 
+  options
+hwaddress address   -- Link local address.
+mtu size-- MTU size
+
+  conversion
+hwaddress cleanup_hwaddress
+
   up
+ip link set dev %iface% [[mtu %mtu%]] [[address %hwaddress%]] up
 
   down
+ip link set dev %iface% down \
+if (iface_is_link())
 
 method dhcp
   description
diff --git a/inet6.defn b/inet6.defn
index e5dc06d..3f48602 100644
--- a/inet6.defn
+++ b/inet6.defn
@@ -94,9 +94,19 @@ method manual
 is done by default.  Such interfaces can be configured manually by
 means of *up* and *down* commands or /etc/network/if-*.d scripts.
 
+  options
+hwaddress address  -- Hardware address
+mtu size   -- MTU size
+
+  conversion
+hwaddress cleanup_hwaddress
+
   up
+ip link set dev %iface% [[mtu %mtu%]] [[address %hwaddress%]] up
 
   down
+ip link set dev %iface% down \
+if (iface_is_link())
 
 method dhcp
   description
-- 
2.6.4



signature.asc
Description: Digital signature

Bug#805634: jessie-pu: torbrowser-launcher/0.2.2-2~deb8u1

[Adam D. Barratt]

Control: tags -1 + confirmed

On 2015-11-20 13:10, Holger Levsen wrote:
torbrowser-launcher 0.1.9-1+deb8u1 in jessie is affected by 3 serious 
bugs

(#804184 #784041 #804274) which are all fixed in the version in stretch
(=0.2.1-2), plus there is one annoying bug left in stretch (#805078) 
which

is fixed in the sid version = 0.2.2-2.

[...]

 30 files changed, 353 insertions(+), 665 deletions(-)

If you want to look yourself in more detail, please use
git.debian.org/git/collab-maint/torbrowser-launcher.git and the tags
debian/$version.

(I've confirmed the tags correspond to what has been uploaded.
Attached is the output
of debdiff torbrowser-launcher_0.1.9-1+deb8u1.dsc
torbrowser-launcher_0.2.2-2.dsc>tbl-jessie-sid.diff)


That's obviously not exactly what you're planning to upload. However, 
assuming that the only difference between the attached diff and the 
actual uploaded source package is a changelog stanza for 0.2.2-2~deb8u1, 
please feel free to go ahead.


Regards,

Adam

Bug#805894: jessie-pu: package mdadm/3.3.2-5+deb8u1

[Adam D. Barratt]

Control: tags -1 + confirmed

On 2015-11-23 17:29, Yann Soubeyrand wrote:

I prepared a package for mdadm containing a patch to fix bug #784070
(https://bugs.debian.org/784070) which prevents booting a software RAID
1 in degraded mode. The diff is attached to this message.

The previous package maintainer (Michael Tokarev) confirmed the source 
of the
problem (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=784070#49) 
and

several users confirmed that the patch fixes the bug. Moreover, the new
package maintainer (Dimitri John Ledkov, CC of this mail) agreed with 
this

solution and gave me his consent to proceed with the upload
(https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=784070#230).


I do slightly worry that this may re-introduce issues that the use of 
incremental assembly was intended to work around, but from reading the 
bug report it seems that the issues with incremental assembly are 
probably now affecting more users.


Please go ahead with the upload. I've CCed the installer list to ensure 
that they're aware of the change.


Regards,

Adam