Bug#826707: ITP: golang-github-bowery-prompt -- Cross platform prompting library

[Anthony Fok]

Package: wnpp
Severity: wishlist
Owner: Anthony Fok 

* Package name: golang-github-bowery-prompt
  Version : 0.0~git20150722.0.3a76720-1
  Upstream Author : Bowery, Inc.
* URL : https://github.com/Bowery/prompt
* License : MIT (Expat)
  Programming Lang: Go
  Description : Cross platform prompting library for Go

 Prompt is a cross platform line-editing prompting library.
 .
 Features:
  * Keyboard shortcuts in prompts
  * History support
  * Secure password prompt
  * Custom prompt support
  * Fallback prompt for unsupported terminals
  * ANSI conversion for Windows

Reason for packaging: Needed by govendor 1.0.3

Bug#826708: gnuplot5-doc and gnuplot-doc: error when trying to install together

[Ralf Treinen]

Package: gnuplot-doc,gnuplot5-doc
Version: gnuplot-doc/4.6.6-3
Version: gnuplot5-doc/5.0.3+dfsg2-2
Severity: serious
User: trei...@debian.org
Usertags: edos-file-overwrite

Date: 2016-06-08
Architecture: amd64
Distribution: sid

Hi,

automatic installation tests of packages that share a file and at the
same time do not conflict by their package dependency relationships has
detected the following problem:


Selecting previously unselected package gnuplot-doc.
(Reading database ... 10960 files and directories currently installed.)
Preparing to unpack .../gnuplot-doc_5.0.3+dfsg3-1_all.deb ...
Unpacking gnuplot-doc (5.0.3+dfsg3-1) ...
Selecting previously unselected package gnuplot5-doc.
Preparing to unpack .../gnuplot5-doc_5.0.3+dfsg2-2_all.deb ...
Unpacking gnuplot5-doc (5.0.3+dfsg2-2) ...
dpkg: error processing archive 
/var/cache/apt/archives/gnuplot5-doc_5.0.3+dfsg2-2_all.deb (--unpack):
 trying to overwrite '/usr/share/info/gnuplot5.info.gz', which is also in 
package gnuplot-doc 5.0.3+dfsg3-1
dpkg-deb: error: subprocess paste was killed by signal (Broken pipe)
Processing triggers for install-info (6.1.0.dfsg.1-8) ...
Errors were encountered while processing:
 /var/cache/apt/archives/gnuplot5-doc_5.0.3+dfsg2-2_all.deb
E: Sub-process /usr/bin/dpkg returned an error code (1)


This is a serious bug as it makes installation fail, and violates
sections 7.6.1 and 10.1 of the policy. An optimal solution would
consist in only one of the packages installing that file, and renaming
or removing the file in the other package. Depending on the
circumstances you might also consider Replace relations or file
diversions. If the conflicting situation cannot be resolved then, as a
last resort, the two packages have to declare a mutual
Conflict. Please take into account that Replaces, Conflicts and
diversions should only be used when packages provide different
implementations for the same functionality.

Here is a list of files that are known to be shared by both packages
(according to the Contents file for sid/amd64, which may be
slightly out of sync):

  /usr/share/info/gnuplot5.info.gz

This bug has been filed against both packages. If you, the maintainers of
the two packages in question, have agreed on which of the packages will
resolve the problem please reassign the bug to that package. You may then
also register in the BTS that the other package is affected by the bug.

-Ralf.

PS: for more information about the detection of file overwrite errors
of this kind see http://qa.debian.org/dose/file-overwrites.html.

Bug#826120: sendmail queue runner dies due to an assertion violation in libldap

[Piper Andreas]

Hello Andreas,

Am 04.06.2016 um 14:11 schrieb Andreas Beckmann:
> Control: fixed -1 8.14.8-1
>
> On 2016-06-02 13:50, Andreas Piper wrote:
>> The same bug has been reported and fixed on RedHat-Linux with
>> package sendmail-8.14.4-9.el6, see
https://access.redhat.com/solutions/1979993
>> Could it be possible to implement this fix also on debian?
>
> Can you test a proposed package with this fix on jessie?
> I've pushed the changes to the git repository on alioth in branch
> "jessie".

I tested your patch on jessie: it fixes my problem! sendmail-ldap-lookup
works now as expected and without crashes.

Thanks alot for your fast reaction.

Best regards,
Andreas





smime.p7s
Description: S/MIME Cryptographic Signature

Bug#826689: yquake2: Limited Architextures

[Simon McVittie]

Control: forwarded 826689 https://github.com/yquake2/yquake2/issues/138
Control: severity 826689 normal

On Tue, 07 Jun 2016 at 17:54:08 -0500, danfun64 wrote:
> They said that in theory it can be
> ported into other architextures, and that I should ask you guys why it's only
> available for amd64 and i386. They said that if you address this bug, that 
> they
> would be willing to implement any changes you make into their codebase.

The reason why we don't provide packages for other architectures is that
yquake2's Makefile specifically and deliberately fails on anything other
than i386, amd64, sparc64 and ia64. sparc64 isn't a release architecture
yet, and ia64 is dead; we build packages for the other two.

I've responded on the upstream bug report and asked about removing that
check and making Linux architecture support generic, similar to a commit
I made in ioquake3.

I see you're running yquake2 on amd64. Which non-i386, non-amd64
architecture(s) have you tested, or which ones can you test? Portability
doesn't happen by magic, it happens because someone who had a need for
the feature did the work.

S

Bug#826328: util-linux: losetup -d disfunctional for cloop and similar loop-compatible block devices

[Prof. Dipl.-Ing. Klaus Knopper]

Hello Andreas,

On Mon, Jun 06, 2016 at 12:26:11PM +0200, Andreas Henriksson wrote:
> Hello Klaus Knopper.
> 
> Thanks for your bug report.
> 
> On Sat, Jun 04, 2016 at 05:35:43PM +0200, Klaus Knopper wrote:
> [...]
> > Losetup was able to setup compressed loopback (cloop) devices, which
> > have a similar ioctl API, until recently the code in sys-utils/losetup.c
> > and lib/loopdev.c was changed to only accept devices with loopbacks
> > major device id.
> [...]
> > Suggestion: Remove the check for
> > 
> > major(st.st_rdev) == LOOPDEV_MAJOR);
> > 
> > in is_loopdev() in lib/loopdev.c.
> 
> Could you please raise your issue on the upstream mailing list
> on vger.kernel.org directly?

I thought that forwarding a problem to the programs authors is what the
"upstream" marker in reportbug was meant for?

Will do.

Regards
-Klaus

Bug#825431: vlc: SIGFPE (divide by zero) while transcoding in line 551 of modules/stream_out/transcode/video.c (transcode_video_encoder_init)

[Sebastian Ramacher]

Hi Will

On 2016-05-26 14:58:29, Will Aoki wrote:
> Package: vlc
> Version: 2.2.1-1~deb8u1
> Severity: normal
> Tags: patch
> 
> We run VLC as a daemon to transcode an MJPEG stream from a StarDot camera and
> pipe it into another program. After upgrading from wheezy to jessie, VLC began
> to crash with SIGFPE.
> 
> Although the root cause may be elsewhere in VLC, the patch at
> https://patches.videolan.org/patch/10246/ resolves the problem.

2.2.4 got released to jessie-security. Could you please try again with that
version? It is supposed to fix various issues in the encoders.

Regards
-- 
Sebastian Ramacher


signature.asc
Description: PGP signature

Bug#826703: gvfs-common: Trying to overwrite gvfs.mo which is also in package gvfs

[Simon McVittie]

On Wed, 08 Jun 2016 at 07:51:08 +0200, Andreas Mohr wrote:
> dpkg: Fehler beim Bearbeiten des Archivs 
> /var/cache/apt/archives/gvfs-common_1.28.2-1_all.deb (--unpack):
>  Versuch, »/usr/share/locale/af/LC_MESSAGES/gvfs.mo« zu überschreiben, 
> welches auch in Paket gvfs 1.8.2-2 ist

You appear to be upgrading from gvfs 1.8.2-2 (2011) to 1.28.2-1.  1.8.2 is
older than oldstable (Debian 7, wheezy), which has 1.12. Were you upgrading
directly from squeeze (Debian 6) to stretch (the future Debian 9)?

Debian does not support upgrades larger than one stable version
(approximately 2 years of development). If you have a very old system
with testing or unstable, you should upgrade to the corresponding stable
release, then upgrade through stable releases until you reach current
stable (Debian 8), *then* upgrade to current testing.

Most maintainers actively remove the metadata that would be needed for
upgrades across more than two stable versions, because it makes the
dependency solver's job harder, which can cause supported upgrades to
fail or take a very long time. The relevant changelog entry here is

  * Drop obsolete Breaks/Replaces/Conflicts from pre-wheezy.

in version 1.24.1-2.

Regards,
S

Bug#826628: Include the string "nicefrac" in the package description

[Preuße]

On 07.06.2016 14:34, Ingo Blechschmidt wrote:

Hi,

> On Tue, Jun 07, 2016 at 07:35:52PM +0900, Norbert Preining wrote:
>> Yes, and there are probably thousands of other .sty files that are not
>> mentioned. I cannot (and do not want) to add all of them to the description,
>> especially since the description is *auto*generated.
>>
>> So this will remain a wontfix unless nicefrac becomes a separate package
>> n CTAN.
> 
> thank you for your quick reply! I understand. :-)
> 
You may use apt-file to search for single files in the archive.

Hilmar
-- 
http://www.hilmar-preusse.de.vu/   #206401 http://counter.li.org

Bug#826709: debootstrap: fail early when debootstrapping foreign arches whose binaries cannot be run

[Paul Wise]

Package: debootstrap
Version: 1.0.81
Severity: wishlist
X-Debbugs-CC: ma...@python.it

On #debian-mentors we had a person (CCed) who was trying to create an
armhf chroot like this:

  $ sudo debootstrap --arch=armhf testing /mnt

This failed with this non-intuitive reason:

  ...
  W: Failure trying to run: chroot /mnt mount -t proc proc /proc
  W: See /mnt/debootstrap/debootstrap.log for details
  $ cat /mnt/debootstrap/debootstrap.log 
  ...
  chroot: failed to run command 'mount': No such file or directory

It would be great if debootstrap would fail early with a message like this:

  This machine cannot run binaries for architecture armhf
  There are two options to work around this:

  Use qemu-debootstrap instead of debootstrap

  Use debootstrap --foreign here and
  use debootstrap --second-stage on armhf

A tool for determining which arches can be run on the current system:

  $ arch-test
  amd64
  i386

When arch-test is not installed, debootstrap could consult a hardcoded
list of typically compatible architectures.

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

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

Versions of packages debootstrap depends on:
ii  wget  1.17.1-2

Versions of packages debootstrap recommends:
ii  debian-archive-keyring  2014.3
ii  gnupg   1.4.20-6

debootstrap suggests no packages.

-- no debconf information

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#819153: libreoffice: LibreOffice crashes when trying to edit diagrams: "does not expose __driDriverGetExtensions_swrast()"

[Rene Engelhard]

Hi,

On Thu, Mar 24, 2016 at 10:34:40AM +0100, Rene Engelhard wrote:
> 10:25 < _rene_> but apparently charts are still using opengl in any case?
> 10:25 < _rene_> (or he turned it on, don't believe so, though)
> 10:27 -!- Rohan_Kumar [~rohan@27.255.171.122] has joined #libreoffice-dev
> 10:28 <@moggi> only for one diagram type
> 10:28 <@moggi> and that one is actually hidden behind the experimental flags
> 10:29 <@moggi> I don't see any problem on the LibO side here
> 10:29 < _rene_> except it using OpenGL at all, yes ;)
> 
> Which chart type was that and did you enable Experimental options in the UI?

So in contrast to what he claimed all the way to a few days ago this happened:

https://cgit.freedesktop.org/libreoffice/core/commit/?h=libreoffice-5-2&id=dc4b01a5a937565b1d6491850c922e1b7de0e949

That at least should fix the symptoms for your case (assuming you don't
use anything which really requires OpenGL).

Can you please try with 5.2.0 beta2 if it's uploaded? I'd give you a package
to test but you use i386 from what I see in the reportbug info in the initial
report and I am not going to build it on i386 extra - sorry.

The rest still is a mesa bug imho. and will get no action. I'd even think we
should close this when the above fix makes the symptom you have go away.

Regards,

Rene

Bug#826710: libapache2-mod-security2: Default rules provided with mod-security contain an error

[Manuel Iwansky]

Package: libapache2-mod-security2
Version: 2.6.6-6+deb7u2
Severity: normal
Tags: patch

Dear Maintainer,

after installing mod-security I tried to deploy all default rules found in 
/usr/share/modsecurity-crs/ .

When running 'apachectl configtest' the following error appears:

"Syntax error on line 52 of 
/etc/modsecurity/activated_rules/modsecurity_crs_16_session_hijacking.conf:
ModSecurity: Disruptive actions can only be specified by chain starter rules.
Action 'configtest' failed."


This is one of the optional rulesets.


A fix could be found at the following URL:
https://www.mail-archive.com/owasp-modsecurity-core-rule-set@lists.owasp.org/msg00955.html


line 49 of jessie's modsecurity_crs_16_session_hijacking.conf has to be changed 
from:

SecRule TX:1 ".*" 
"chain,t:sha1,t:hexEncode,setvar:session.ip_hash=%{matched_var}"

to:
SecRule TX:1 ".*" 
"t:sha1,t:hexEncode,setvar:session.ip_hash=%{matched_var}"


After that apache2 starts without error, with all mod-security rules enabled.



Kind regards

Manuel Iwansky



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

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

Bug#825112: (no subject)

[Gordon Ball]

On 07/06/16 22:49, Barry Warsaw wrote:
> On Jun 07, 2016, at 10:00 PM, Gordon Ball wrote:
> 
>>> The packaging looks really good.  I noticed the setting of http_proxy in
>>> override_dh_auto_build.  You probably don't strictly need that because I
>>> believe pybuild does that automatically.  It can't hurt though and some
>>> maintainers prefer to be explicit about that.  
>>
>> The http_proxy bit was cargo-culted from
>> https://wiki.debian.org/Python/LibraryStyleGuide
> 
> Ah, I'd forgotten that this was still needed for sphinx-build.
> 
>> Good idea. The test suite is extensive but it hadn't occurred to me that
>> it is entirely based on importing it as a library rather than actually
>> running the binary. I'd tested the installed package but clearly on a
>> system with python3-pkg-resources already installed.
>>
>> I found that this fails in an autopkgtest schroot though - xonsh fails
>> to start if $HOME is not writable (which is possibly a bug), so I've
>> added a wrapper which sets $HOME=$ADTTMP (and added a couple of extra
>> examples).
> 
> Looks great, much better than my quick hack. :)
> 
>> On hold for the moment then. I'm happy to have it listed as team maintained
>> at a future point though. I'm already subscribed to debian-python, I'll apply
>> to join the relevant teams soon.
> 
> Cool.  It'll be easy to move later.
> 
> One possible minor issue is that DPMT did adopt git-dpm for packages, but
> since that decision several years ago, git-dpm has apparently stopped being
> developed.  It hasn't quite bitrotted yet, but I am advocating that DPMT drop
> git-dpm and use gbp-pq for patch management.  I don't see any reason other
> than (hopefully temporary) consistency for PAPT to adopt git-dpm once that
> switch happens.  We'll have to see what the team says.
> 
> For now, let's just assume gbp-pq will be adopted for PAPT.
> 
>> Given the script is generated based on `entry_points` in setup.py,
>> shouldn't this dependency be generated by pybuild/dh_python?
> 
> Actually, that should come from an install_requires section or a
> requirements.txt file.  I don't see either of those in the xonsh repo.  But
> also pkg_resources is kind of a special case on Debian.  It really comes as
> part of setuptools, but in Debian we split it out into a separate binary
> package, so I don't know that it would be automatically detected in any case.
> Clearly it doesn't since it crashes without an explicit Depends, but we'd have
> to ask Piotr on debian-python@ to know whether that's intended behavior or
> not.  TBH, I always just add it explicitly.
> 
>> There are a couple of remaining (possibly non-) issues:
>>
>> * lintian reports privacy-breach-generic on the documentation (google
>> webfont links). I can't see this explicitly configured anywhere in the
>> rst files or conf.py, so I *think* this is being added by
>> sphinx/cloud-sptheme
> 
> Interesting.  I built the package from the git repo on unstable and ran
> lintian over the amd64.changes file.  I don't get any lintian warnings.

I don't see anything locally, but I do see it when uploading a binary
package to mentors.d.n - I'm unsure how their setup differs from
`lintian --pedantic`. Anyway.

> 
>> * building the documentation generates (I think) inconsequential errors
>> since the xonsh pygments lexer is not available at build time; this
>> could be fixed by build-depending on itself, but I'm not sure this is
>> worth adding a dependency cycle for.
> 
> I see that too.  Agreed it's probably not worth worrying about right now.
> 
>> * xonsh supports installing itself as a jupyter kernel, which I'm
>> interested to include but for the moment (parts of) jupyter is only in
>> experimental, so it can probably wait until a future xonsh upload
> 
> +1
> 
> Everything else lgtm.  Let me know when you want me to sponsor an upload; I'm
> happy to do it any time.  It will have to go through NEW of course, but it
> would be nice to get this into peoples hands soon.  (I know I'm not the only
> Debuntunista who wants to use it after watching the Pycon talk. :)
> 

If you think it looks in good shape, let's go for an upload. Thanks for
your time reviewing the packaging.

Bug#826711: diffoscope: please add argument completion

[Paul Wise]

Package: diffoscope
Severity: wishlist
Tags: newcomer

Please add argument completion. Using the Python 3 argcomplete module
makes this relatively simple. This project can be used as an example:

https://anonscm.debian.org/cgit/collab-maint/check-all-the-things.git/

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#826713: The keys in the keyrings don't fall under any copyright.

[Mathieu Malaterre]

Package: debian-keyring
Version: 2016.04.22

Currently the package copyright file states:

[...]
The keys in the keyrings don't fall under any copyright.
[...]

this is inaccurate as key(s) can have JPEG copyright strings attached.

Thanks.

Bug#826398: dump crashes with SIGSEGV

[Alexander Zangerl]

On Sun, 05 Jun 2016 11:45:05 +0200, Andreas Pommer writes:
>Tried to make a backup, which failed. The investigation then showed that the
>new version of dump caused the failure, dump crashes with a segment violation.
>This was observed on amd64 and i386 architectures, as well as on a raspbian
>system (arm).

thanks for your testing. i've narrowed it down to a problem in
the reworked indexing/qfa code, but haven't found the exact root cause
just yet.

as a workaround i've just built 0.4b45-2 with qfa disabled, which 
serves to temporarily return the dump package to the working state.

i'll upload that within the hour, then get in touch with upstream
to properly solve the issue.

regards
az


-- 
Alexander Zangerl + GPG Key 0xB963BD5F + http://snafu.priv.at/
Never meddle in the affairs of NT. It is slow to boot
and quick to crash. -- Stephen Harris


signature.asc
Description: Digital Signature

Bug#826714: jessie-pu: package biber/1.9-3+deb8u1

[Dominic Hargreaves]

Package: release.debian.org
Severity: normal
Tags: jessie
User: release.debian@packages.debian.org
Usertags: pu

As per #826667 the last perl update unfortunately broke biber too
(at least it causes a test failure; the actual cause is a bit unclear,
but the fix is taken straight from the upstream perl 5.22 fixes).

Please find attached a proposed patch; let me know if it's okay to upload.

This was discovered by automated rebuild testing of all packages depending
on perl:

this testing is not yet completed, but no other failures have been
found yet.

Thanks,
Dominic.
diff -Nru biber-1.9/debian/changelog biber-1.9/debian/changelog
--- biber-1.9/debian/changelog	2014-12-24 23:45:26.0 +
+++ biber-1.9/debian/changelog	2016-06-07 16:56:37.0 +0100
@@ -1,3 +1,10 @@
+biber (1.9-3+deb8u1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix breakage triggered by point release update of perl
+
+ -- Dominic Hargreaves   Tue, 07 Jun 2016 16:56:10 +0100
+
 biber (1.9-3) unstable; urgency=medium
 
   * cherry pick upstream fix for hyphenation fixes (Closes: #773872)
diff -Nru biber-1.9/debian/patches/fix-5.20.3 biber-1.9/debian/patches/fix-5.20.3
--- biber-1.9/debian/patches/fix-5.20.3	1970-01-01 01:00:00.0 +0100
+++ biber-1.9/debian/patches/fix-5.20.3	2016-06-07 16:55:50.0 +0100
@@ -0,0 +1,14 @@
+diff -urN biber-1.9/lib/Biber/Input/file/bibtex.pm biber-1.9.new/lib/Biber/Input/file/bibtex.pm
+--- biber-1.9/lib/Biber/Input/file/bibtex.pm	2016-06-07 16:55:35.0 +0100
 biber-1.9.new/lib/Biber/Input/file/bibtex.pm	2016-06-07 16:55:13.402781198 +0100
+@@ -1214,8 +1214,8 @@
+ 
+ sub _hack_month {
+   my $in_month = shift;
+-  if ($in_month =~ m/\A\s*((?:jan|feb|mar|apr|may|jun|jul|aug|sep|oct|nov|dec).*)\s*\z/i) {
+-return $months{lc(Unicode::GCString->new($1)->substr(0,3)->as_string)};
++  if (my ($m) = $in_month =~ m/\A\s*((?:jan|feb|mar|apr|may|jun|jul|aug|sep|oct|nov|dec).*)\s*\z/i) {
++return $months{lc(Unicode::GCString->new($m)->substr(0,3)->as_string)};
+   }
+   else {
+ return $in_month;
diff -Nru biber-1.9/debian/patches/series biber-1.9/debian/patches/series
--- biber-1.9/debian/patches/series	2014-12-24 23:45:26.0 +
+++ biber-1.9/debian/patches/series	2016-06-07 16:56:02.0 +0100
@@ -5,3 +5,4 @@
 fix-slurp-unknown
 fix-perl-warning
 biber-fix-hyphenation
+fix-5.20.3

Bug#804964: setserial: Please drop dependency on initscripts package

[Martin Pitt]

Control: tag -1 patch

bi...@debian.org [2015-11-13  7:53 +0100]:
> your package setserial declares a dependency on the initscripts
> package.
> 
> Please check, if this dependency is actually needed and remove it
> otherwise.

This was introduced in https://bugs.debian.org/734496 because
/etc/init.d/etc-setserial has "Required-Start: checkfs". IMHO this
should just say "$local_fs" instead, and drop the initscripts
dependency again. Corresponding patch attached.

Note that /etc/init.d/setserial has a corresponding systemd unit, but
/etc/init.d/etc-setserial does not. Could this be systemd-ified too?
Or is it not necessary under systemd, and etc-setserial.service should
simply be masked?

Thanks,

Martin

-- 
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)
diff -Nru setserial-2.17/debian/changelog setserial-2.17/debian/changelog
--- setserial-2.17/debian/changelog 2015-09-22 23:32:05.0 +0200
+++ setserial-2.17/debian/changelog 2016-06-08 11:33:30.0 +0200
@@ -1,3 +1,10 @@
+setserial (2.17-49ubuntu1) yakkety; urgency=medium
+
+  * 10_rc_etc_setserial.patch: Change etc-setserial's "checkfs" dependency to
+$local_fs, and drop initscripts dependency. (Closes: #734496)
+
+ -- Martin Pitt   Wed, 08 Jun 2016 11:32:31 +0200
+
 setserial (2.17-49) unstable; urgency=medium
 
   * as upstream archive vanished, watch file is useless
diff -Nru setserial-2.17/debian/control setserial-2.17/debian/control
--- setserial-2.17/debian/control   2015-09-22 23:20:55.0 +0200
+++ setserial-2.17/debian/control   2016-06-08 11:32:28.0 +0200
@@ -7,7 +7,7 @@
 
 Package: setserial
 Architecture: any
-Depends: ${shlibs:Depends}, ${misc:Depends}, initscripts
+Depends: ${shlibs:Depends}, ${misc:Depends}
 Description: controls configuration of serial ports
  Set and/or report the configuration information associated with
  a serial port. This information includes what I/O port and which IRQ
diff -Nru setserial-2.17/debian/patches/10_rc_etc_setserial.patch 
setserial-2.17/debian/patches/10_rc_etc_setserial.patch
--- setserial-2.17/debian/patches/10_rc_etc_setserial.patch 2015-09-22 
23:30:40.0 +0200
+++ setserial-2.17/debian/patches/10_rc_etc_setserial.patch 2016-06-08 
11:32:14.0 +0200
@@ -11,7 +11,7 @@
 +#
 +### BEGIN INIT INFO
 +# Provides: etc-setserial
-+# Required-Start:   checkfs
++# Required-Start:   $local_fs
 +# Required-Stop:$remote_fs
 +# Default-Start:S
 +# Default-Stop: 0 1 6

Bug#826715: RFS: lua-torch-torch7/0~20160604-g69d7a01-1 [ITP]

[lumin]

Package: sponsorship-requests
Severity: wishlist
X-Debbugs-CC: debian-scie...@lists.debian.org, a...@debian.org

  Dear mentors,

  This package is the very core part of "Torch", a
  state-of-the-art machine learning framework.
  Note, this package requires luajit from experimental,
  and the basic functionality seems to be working, 
  but there are still some problems.

  * the test_sharedmem.lua fails and it seems to be an upstream bug
  * the package complexity far surpassed the assumption of dh-lua,
so the rules file of this package is somewhat convolved,
mixing cmake build and the dh-lua build together, but it should
not be hard to understand. :-)

  It's project homepage is http://torch.ch

  I am looking for a sponsor for my package "lua-torch-torch7"

 * Package name: lua-torch-torch7
   Version : 0~20160604-g69d7a01-1
   Upstream Author : Torch Devs
 * URL : github.com/torch/torch7
 * License : BSD-3-Clause
   Section : interpreters

  It builds those binary packages:

libtorch-luat - libluaT.so of Torch Package for Torch Framework
 libtorch-luat-dev - libluaT.so of Torch Package for Torch Framework (dev)
 libtorch-th - libTH.so of Torch Package for Torch Framework
 libtorch-th-dev - libTH.so of Torch Package for Torch Framework (dev)
 lua-torch-torch7 - Torch Package for Torch Framework
 lua-torch-torch7-dev - Torch Package for Torch Framework (dev)

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

  https://mentors.debian.net/package/lua-torch-torch7


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

dget -x 
https://mentors.debian.net/debian/pool/main/l/lua-torch-torch7/lua-torch-torch7_0~20160604-g69d7a01-1.dsc

  More information about hello can be obtained from https://www.example.com.

  Changes since the last upload:

lua-torch-torch7 (0~20160604-g69d7a01-1) experimental; urgency=low

  * Initial release. Closes: #826532

Bug#826667: biber: breaks with perl 5.20.2-3+deb8u5

[Dominic Hargreaves]

On Wed, Jun 08, 2016 at 03:05:36PM +0900, Norbert Preining wrote:
> Hi Dominic,
> 
> > Right now, I can't spot which change in 5.20.2-3+deb8u5 caused the
> > problem, but applying the change reference in that bug report, attached,
> > fixes the FTBFS.
> 
> That is a *very* strange fix ...
> 
> > libdevel-declare-perl (see #826622); let me know if you'd like me to
> > prepare a similar NMU for biber or whether you'd like to handle it.
> 
> Please go ahead, I am completely fine with that. You can upload
> directly to the archive.

Okay, opened release.debian.org bug #826714

Cheers,
Dominic.

Bug#804973: mdadm: Please drop dependency on initscripts package

[Martin Pitt]

bi...@debian.org [2015-11-13  7:53 +0100]:
> your package mdadm declares a dependency on the initscripts package.

The only references that I can find to it is

  [ from 3.2.2-1, 01 Aug 2011 ]
  * move initscript metadata from /lib/init/rw/.mdadm to /run/mdadm,
and depend on initscripts (>= 2.88dsf-13.3) for /run (Closes: #633054)

  https://anonscm.debian.org/cgit/pkg-mdadm/mdadm.git/commit/?id=d98f009ef88664

  [ from 3.2.5-4+mdmon, 20 Oct 2012]
  * /etc/init.d/mdadm: change RUNDIR to /run instead of /var/run.
Mdadm itself uses /run internally, we properly depend on initscripts
version which creates /run, and the initscript itself is started
after local_fs is processed, so this is merely a no-op, but let's
do it for consistency.

and the versioned dependency was dropped in
https://anonscm.debian.org/cgit/pkg-mdadm/mdadm.git/commit/?id=dda76c9f8
because that version is in pre-wheezy only.

debian/mdadm.init's dependencies are

  # Required-Start:$local_fs $syslog mdadm-raid

I'm not entirely sure what provides mdadm-raid, but it's *not*
initscripts. So it looks like the initscripts dependency can just be
dropped without any problem.

Thanks,

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

Bug#826712: [nvidia-legacy-304xx-kernel-dkms] Does not build for kernel 4.6.0-1, -rt (also 4.4.0-1-rt)

[Luca Boccassi]

Control: tags -1 pending

On Wed, 2016-06-08 at 11:41 +0300, David Baron wrote:
> Package: nvidia-legacy-304xx-kernel-dkms
> Version: 304.131-4
> Severity: normal
> 
> --- Please enter the report below this line. ---
> Newly installed kernels and  headers 4.6.0-1 and 4.6.0-1-rt, the driver did 
> not build.
> Including error log: /var/lib/dkms/nvidia-legacy-304xx/304.131/build/make.log
> 
> Notes.
> 1. Had this problem previously, corrected in newer kernel updates for version.

The updates to fix the build in 4.6 are in the SVN repo pending uploads
to unstable.

> 2. The 4.4.0-1-rt version did not build. May assume log was similar. Do not 
> have the old ones.

If memory serves, I think we already discussed supporting -rt and
decided not to, due to the need for massive and very invasive changes
and patches that would be needed. Unfortunately the time and resources
we have is limited so we have to pick our battles.

Kind regards,
Luca Boccassi


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

Bug#826712: [nvidia-legacy-304xx-kernel-dkms] Does not build for kernel 4.6.0-1, -rt (also 4.4.0-1-rt)

[David Baron]

On Wednesday 08 June 2016 10:46:25 Luca Boccassi wrote:
> Control: tags -1 pending
> 
> On Wed, 2016-06-08 at 11:41 +0300, David Baron wrote:
> > Package: nvidia-legacy-304xx-kernel-dkms
> > Version: 304.131-4
> > Severity: normal
> > 
> > --- Please enter the report below this line. ---
> > Newly installed kernels and  headers 4.6.0-1 and 4.6.0-1-rt, the driver
> > did
> > not build.
> > Including error log:
> > /var/lib/dkms/nvidia-legacy-304xx/304.131/build/make.log
> > 
> > Notes.
> > 1. Had this problem previously, corrected in newer kernel updates for
> > version.
> The updates to fix the build in 4.6 are in the SVN repo pending uploads
> to unstable.
Great!

> > 2. The 4.4.0-1-rt version did not build. May assume log was similar. Do
> > not
> > have the old ones.
> 
> If memory serves, I think we already discussed supporting -rt and
> decided not to, due to the need for massive and very invasive changes
> and patches that would be needed. Unfortunately the time and resources
> we have is limited so we have to pick our battles.
True. I remember editing sources to do so in the "distant" past (simple stuff, 
however).

The only reason I am using the nvidia-legacy is problems in KDE, Iceweasel 
hangups and segfaults. Responders to these bugs said forget Nouveau, which BTW 
I do like, and go to the proprietary NVidia. May or may not still be the case.

At one time, I had boot command lines to choose Nvidia vs Nouveau, but things 
have changed, i.e. systemd, no more Xorg.conf, etc. If someone could tell me 
how to accomplish this now, I would be a happy camper. Apparently, a blacklist 
file is all that controls whether or not the included Nouveau driver is 
activated. Simply a missing nvidia driver dkms update will produce an error.

Bug#826716: network-manager-gnome: nm-applet show mac address

[Max]

Package: network-manager-gnome
Version: 1.2.2-1
Severity: minor

Hello, show on which AP I connected showing mac address of AP.
thanks

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

Kernel: Linux 4.5.0-2-686-pae (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 network-manager-gnome depends on:
ii  dbus-x11 1.10.8-1
ii  dconf-gsettings-backend [gsettings-backend]  0.26.0-1
ii  gnome-icon-theme 3.12.0-2
ii  libatk1.0-0  2.20.0-1
ii  libc62.22-9
ii  libcairo21.14.6-1+b1
ii  libgdk-pixbuf2.0-0   2.34.0-1
ii  libglib2.0-0 2.48.1-1
ii  libgtk-3-0   3.20.6-1
ii  libmm-glib0  1.4.14-1
ii  libnm0   1.2.2-1
ii  libnma0  1.2.2-1
ii  libnotify4   0.7.6-2
ii  libpango-1.0-0   1.40.1-1
ii  libpangocairo-1.0-0  1.40.1-1
ii  libsecret-1-00.18.3-1
ii  mate-polkit [policykit-1-gnome]  1.14.0-1
ii  network-manager  1.2.2-1
ii  policykit-1-gnome0.105-2

Versions of packages network-manager-gnome recommends:
ii  gnome-keyring   3.20.0-1
ii  iso-codes   3.68-1
ii  mate-notification-daemon [notification-daemon]  1.14.0-1
ii  mobile-broadband-provider-info  20140317-1
ii  notification-daemon 3.20.0-1

Versions of packages network-manager-gnome suggests:
pn  network-manager-openconnect-gnome  
pn  network-manager-openvpn-gnome  
pn  network-manager-pptp-gnome 
pn  network-manager-vpnc-gnome 

-- no debconf information

Bug#826366: [Pkg-utopia-maintainers] Bug#826366: network-manager: does not remove resolv.conf symlink on package removal

[Julian Gilbey]

On Sun, Jun 05, 2016 at 11:44:35PM +0200, Michael Biebl wrote:
> Hi Julian

Hi Michael,

> Am 05.06.2016 um 01:56 schrieb Julian Gilbey:
> > [...]
> > 
> > So when network-manager shuts down, it should revert /etc/resolv.conf
> > to a regular file.  This should also be checked when the package is
> > removed (and unarguably when the package is purged).
> 
> I'm not convinced replacing /etc/resolv.conf on stop is a good idea, so
> I won't do that.
> [...]

Interesting point.  As /var/run/NetworkManager/resolv.conf still
exists after stop, it would be OK.  But if the machine is then
rebooted with network-manager still disabled, the problem resurfaces.

Question: If the symlink is reverted to an empty file on stop, but the
/var/run version is kept intact, would NM pick it up again on restart,
just by recreating the symlink?  Or does NM recreate the /var/run
version on startup anyway?  If either of these are the case, then it
seems that it would be fine to revert /etc/resolv.conf on stop, as it
should have no bad effects (and possibly some good ones).

Incidentally, it seems as though NM obliterates any previously
existing resolv.conf when it is first run, so there is no hope of
reinstating the previous version.  This does not seem ideal, either.

Best wishes, and thanks for your quick response.

   Julian

Bug#826717: firefox: Native notifications no longer working after upgrade

[Joel Cross]

Package: firefox
Version: 46.0.1-1+b1
Severity: normal

Since last upgrading my system, I am no longer receiving native system
notifications (GNOME) from Firefox. Instead I am seeing the built-in Firefox
XUL-based notifications.



-- Package-specific info:

-- Extensions information
Name: 1Password
Location: ${PROFILE_EXTENSIONS}/onepasswo...@agilebits.com.xpi
Status: enabled

Name: A Web Browser Renaissance theme
Status: user-disabled

Name: BetterPrivacy
Location: ${PROFILE_EXTENSIONS}/{d40f5e7b-d2cf-4856-b441-cc613eeffbe3}.xpi
Status: enabled

Name: Decentraleyes
Location: ${PROFILE_EXTENSIONS}/jid1-bofifl9vbdl...@jetpack.xpi
Status: enabled

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

Name: English (GB) Language Pack locale
Location: 
/usr/lib/firefox/browser/extensions/langpack-en...@firefox.mozilla.org.xpi
Package: firefox-l10n-en-gb
Status: enabled

Name: Firebug
Location: ${PROFILE_EXTENSIONS}/fire...@software.joehewitt.com.xpi
Status: enabled

Name: Firefox Hello
Location: ${PROFILE_EXTENSIONS}/l...@mozilla.org.xpi
Status: enabled

Name: FireQuery
Location: ${PROFILE_EXTENSIONS}/firequ...@binaryage.com.xpi
Status: user-disabled

Name: FXChrome theme
Location: ${PROFILE_EXTENSIONS}/{c0c588b6-b11d-4898-af00-079fed05aa32}.xpi
Status: user-disabled

Name: HeaderControlRevived
Location: ${PROFILE_EXTENSIONS}/headercontrolrevi...@torvin.xpi
Status: enabled

Name: HTTP/2 and SPDY indicator
Location: ${PROFILE_EXTENSIONS}/spdyindica...@chengsun.github.com.xpi
Status: enabled

Name: IdentFavIcon
Location: ${PROFILE_EXTENSIONS}/identfavi...@david.hanak.hu.xpi
Status: enabled

Name: JSONView
Location: ${PROFILE_EXTENSIONS}/jsonv...@brh.numbera.com.xpi
Status: enabled

Name: LeechBlock
Location: ${PROFILE_EXTENSIONS}/{a95d8332-e4b4-6e7f-98ac-20b733364387}
Status: enabled

Name: Link Alert
Location: ${PROFILE_EXTENSIONS}/linkalert.con...@addons.mozilla.com.xpi
Status: enabled

Name: MailtoWebmails
Location: ${PROFILE_EXTENSIONS}/mailtowebma...@jetpack.xpi
Status: enabled

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

Name: Nimbus Screen Capture - editable screenshots.
Location: ${PROFILE_EXTENSIONS}/nimbusscreencaptur...@everhelper.me.xpi
Status: enabled

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

Name: ProfileSwitcher
Location: ${PROFILE_EXTENSIONS}/{fa8476cf-a98c-4e08-99b4-65a69cb4b7d4}.xpi
Status: enabled

Name: Web Developer
Location: ${PROFILE_EXTENSIONS}/{c45c406e-ab73-11d8-be73-000a95be3b12}.xpi
Status: enabled

Name: ZenMate Security, Privacy & Unblock VPN
Location: ${PROFILE_EXTENSIONS}/fire...@zenmate.com.xpi
Status: user-disabled

-- Plugins information
Name: GNOME Shell Integration
Location: /usr/lib/mozilla/plugins/libgnome-shell-browser-plugin.so
Package: gnome-shell
Status: enabled

Name: Google Talk Plugin
Location: /opt/google/talkplugin/libnpgoogletalk.so
Package: google-talkplugin
Status: enabled

Name: Google Talk Plugin Video Renderer
Location: /opt/google/talkplugin/libnpo1d.so
Package: google-talkplugin
Status: enabled

Name: iTunes Application Detector
Location: /usr/lib/mozilla/plugins/librhythmbox-itms-detection-plugin.so
Package: rhythmbox-plugins
Status: enabled

Name: Shockwave Flash (11.2.202.491)
Location: /usr/lib/adobe-flashplugin/libflashplayer.so
Package: adobe-flashplugin
Status: enabled


-- Addons package information
ii  adobe-flashplugin  1:20150716.1-0utopic1 amd64Adobe Flash Player 
plugin
ii  firefox46.0.1-1+b1   amd64Mozilla Firefox web 
browser
ii  firefox-l10n-en-gb 46.0.1-1  all  English (United 
Kingdom) language package for Firefox
ii  gnome-shell3.20.2-3  amd64graphical shell for 
the GNOME desktop
ii  google-talkplugin  5.41.0.0-1amd64Google Talk Plugin
ii  rhythmbox-plugins  3.3.1-2   amd64plugins for rhythmbox 
music player

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

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

Versions of packages firefox depends on:
ii  debianutils   4.7
ii  fontconfig2.11.0-6.4
ii  libasound21.1.0-1
ii  libatk1.0-0   2.20.0-1
ii  libc6 2.22-10
ii  libcairo2 1.14.6-1+b1
ii  libdbus-1-3   1.10.8-1
ii  libdbus-glib-1-2  0.106-1
ii  libevent-2.0-52.0.21-stable-2+b1
ii  libffi6   3.2.1-4
ii  libfontconfig12.11.0-6.4
ii  libfreetype6  2.6.3-3+b1
ii  libgc

Bug#826718: Please update fwknop

[Christian Schrötter]

Source: fwknop
Version: 2.6.0-2.2

Please update the fwknop packages in unstable/testing. Version 2.6.0 is
very old and it's missing UDP server mode and other important features.

Bug#824935: sbuild: better support for running autopkgtests

[Sean Whitton]

Dear Johannes,

On Tue, Jun 07, 2016 at 10:12:54PM +0200, Johannes Schauer wrote:
> To be able to run autopkgtests, one needs to have a chroot configured,
> needs to know which backend to use and needs to know which
> distribution to use. The sbuild wiki just plainly assumes that the
> user is using schroot, has a chroot configured and is always building
> for unstable. But people using sbuild are neither only building for
> unstable, nor do they necessarily use the schroot backend and might
> thus not have a schroot-style chroot configured.
> 
> Now one could say that one could add a similar command line argument
> like --piuparts-opts for piuparts or --lintian-opts for lintian. But
> this then would mean that users that do not use the defaults (schroot
> and unstable) would have to pass these options all the time which gets
> us back to the original situation where users had to manually add a
> --post-build-command.
> 
> So is there an elegant way to solve this dilemma and execute adt-run
> with the right options with the least amount of user intervention per
> build?

So the problem is to come up with a sensible default set of options to
pass to adt-run that will Just Work?  This should work without any
schroot:

adt-run --changes foo.changes --- null

Someone who *does* have a schroot will want to override this default to
use their schroot: in my experience, the null test is useful but it
doesn't catch some failures such as missing test dependencies.

So we also need --adt-run-opts.  The user will want to use %a in this,
and ideally a percent escape sequence representing the
suite/distribution -- this would also be useful in $piuparts_opts but I
don't believe it is currently supported.

If we assume that sbuild implicitly passes the changes file to adt-run
as it currently does with lintian and piuparts, I could have

$adt_run_opts = [ '---', 'schroot', '%D-%a-sbuild'];

where %D is my imagined escape sequence giving the distribution.  If I
need to do a build for a distribution that I don't have a schroot
prepared for, I could use `--no-run-adt-run --no-run-piuparts` to
disable those steps.

Does this address your concerns?

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#826719: firefox-esr: font-family monospace does not use monospace font after Iceweasel upgrade

[Paul Boddie]

Package: firefox-esr
Version: 45.2.0esr-1~deb7u1
Severity: important

The firefox-esr package got upgraded today (in wheezy) and bug #388478 seems to 
have returned. In short, font-family set to "monospace" causes a proportional 
font to be used, so I imagine that the mapping from monospace to a suitable 
font has been lost in the upgrade from iceweasel.

(Indeed, the general font usage appears to have changed, but I more or less
expect Firefox upgrades to change the visual style arbitrarily, anyway.)

I have not changed any preferences since the package was upgraded.

Paul


-- Package-specific info:

-- Extensions information
Name: Adblock Plus
Location: 
/usr/share/mozilla/extensions/{ec8030f7-c20a-464f-9b0e-13a3a9e97384}/{d10d0bf8-f5b5-c8b4-a8b2-2b9879e08c5d}
Package: xul-ext-adblock-plus
Status: user-disabled

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

Name: English (GB) Language Pack locale
Location: 
/usr/lib/firefox-esr/browser/extensions/langpack-en...@firefox-esr.mozilla.org.xpi
Package: firefox-esr-l10n-en-gb
Status: enabled

Name: Firefox Hello Beta
Location: ${PROFILE_EXTENSIONS}/l...@mozilla.org.xpi
Status: enabled

Name: Norsk bokmål ordliste dictionary
Location: ${PROFILE_EXTENSIONS}/nb...@dictionaries.addons.mozilla.org
Status: enabled

-- Plugins information
Name: Gnome Shell Integration
Location: /usr/lib/mozilla/plugins/libgnome-shell-browser-plugin.so
Package: gnome-shell
Status: enabled

Name: iTunes Application Detector
Location: /usr/lib/mozilla/plugins/librhythmbox-itms-detection-plugin.so
Package: rhythmbox-plugins
Status: enabled

Name: Skype Buttons for Kopete
Location: /usr/lib/mozilla/plugins/skypebuttons.so
Package: kopete
Status: enabled


-- Addons package information
ii  firefox-esr45.2.0esr-1~ i386 Mozilla Firefox web browser - Ext
ii  firefox-esr-l1 45.2.0esr-1~ all  English (United Kingdom) language
ii  gnome-shell3.4.2-7+deb7 i386 graphical shell for the GNOME des
ii  kopete 4:4.8.4-1+b1 i386 instant messaging and chat applic
ii  rhythmbox-plug 2.97-2.1 i386 plugins for rhythmbox music playe
ii  xul-ext-adbloc 2.1-1+deb7u1 all  Advertisement blocking extension 

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

Kernel: Linux 3.2.0-4-486
Locale: LANG=en_GB.ISO-8859-15, LC_CTYPE=en_GB.ISO-8859-15 (charmap=ISO-8859-15)
Shell: /bin/sh linked to /bin/dash

Versions of packages firefox-esr depends on:
ii  debianutils   4.3.2
ii  fontconfig2.9.0-7.1
ii  libasound21.0.25-4
ii  libatk1.0-0   2.4.0-2
ii  libc6 2.13-38+deb7u11
ii  libcairo2 1.12.2-3
ii  libdbus-1-3   1.6.8-1+deb7u6
ii  libdbus-glib-1-2  0.100.2-1
ii  libevent-2.0-52.0.19-stable-3+deb7u1
ii  libffi5   3.0.10-3
ii  libfontconfig12.9.0-7.1
ii  libfreetype6  2.4.9-1.1+deb7u3
ii  libgcc1   1:4.7.2-5
ii  libgdk-pixbuf2.0-02.26.1-1+deb7u5
ii  libglib2.0-0  2.33.12+really2.32.4-5
ii  libgtk2.0-0   2.24.10-2
ii  libhunspell-1.3-0 1.3.2-4
ii  libpango1.0-0 1.30.0-1
ii  libsqlite3-0  3.7.13-1+deb7u2
ii  libstartup-notification0  0.12-1
ii  libstdc++64.7.2-5
ii  libx11-6  2:1.5.0-1+deb7u2
ii  libxcomposite11:0.4.3-2
ii  libxdamage1   1:1.1.3-2
ii  libxext6  2:1.3.1-2+deb7u1
ii  libxfixes31:5.0-4+deb7u1
ii  libxrender1   1:0.9.7-1+deb7u2
ii  libxt61:1.1.3-1+deb7u1
ii  procps1:3.3.3-3
ii  zlib1g1:1.2.7.dfsg-13

Versions of packages firefox-esr recommends:
ii  gstreamer0.10-ffmpeg0.10.13-5
ii  gstreamer0.10-plugins-good  0.10.31-3+nmu1

Versions of packages firefox-esr suggests:
pn  fonts-lmodern  
ii  fonts-stix [otf-stix]  1.1.0-1
ii  libcanberra0   0.28-6
ii  libgnomeui-0   2.24.5-2
ii  libgssapi-krb5-2   1.10.1+dfsg-5+deb7u7
pn  mozplugger 

-- no debconf information

Bug#826720: linux-headers-4.4.0-22-generic: Missing .make files ftom headers

[Corcodel Marian]

Package: linux-headers-4.4.0-22-generic
Version: 4.4.0-22.40
Severity: normal

Hi
I need  to compile one modules but not find Rules.make on my Makefile want to
add this line
 include $(TOPDIR)/Rules.make
 but without success.



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

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

Versions of packages linux-headers-4.4.0-22-generic depends on:
ii  libc6   2.23-0ubuntu3
ii  libssl1.0.0 1.0.2g-1ubuntu4.1
ii  linux-headers-4.4.0-22  4.4.0-22.40

linux-headers-4.4.0-22-generic recommends no packages.

linux-headers-4.4.0-22-generic suggests no packages.

-- no debconf information

Bug#826721: gnuplot-x11: update-alternatives: error: alternative link /usr/share/gnuplot/gnuplot.gih is already managed by gnuplot4

[Sven Joachim]

Package: gnuplot-x11
Version: 5.0.3+dfsg3-1
Severity: serious

Your package failed to configure:

,
| # LANG=C dpkg --configure --pending
| Setting up gnuplot-x11 (5.0.3+dfsg3-1) ...
| update-alternatives: error: alternative link /usr/share/gnuplot/gnuplot.gih 
is already managed by gnuplot4
| dpkg: error processing package gnuplot-x11 (--configure):
|  subprocess installed post-installation script returned error exit status 2
| Errors were encountered while processing:
|  gnuplot-x11
`

There is a file gnuplot4 in /var/lib/dpkg/alternatives dated 2015-08-27
which contains alternatives for gnuplot4:

,
| auto
| /usr/bin/gnuplot4
| gnuplot4.1.gz
| /usr/share/man/man1/gnuplot4.1.gz
| gnuplot4.gih
| /usr/share/gnuplot/gnuplot.gih
| 
| /usr/bin/gnuplot4-x11
| 30
| /usr/share/man/man1/gnuplot4-x11.1.gz
| /usr/share/gnuplot/gnuplot4-x11.gih
`

AFAICS these alternatives were set up by the previous version (4.6.6-3)
of gnuplot-x11 which does not remove them on upgrades, so gnuplot-x11's
responsibility is to remove them in the new postinst.


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

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

Versions of packages gnuplot-x11 depends on:
ii  gnuplot-data 5.0.3+dfsg3-1
ii  libc62.22-11
ii  libcairo21.14.6-1+b1
ii  libedit2 3.1-20150325-1+b1
ii  libgcc1  1:6.1.1-5
ii  libgd3   2.2.1-1
ii  libglib2.0-0 2.48.1-1
ii  liblua5.1-0  5.1.5-8
ii  libpango-1.0-0   1.40.1-1
ii  libpangocairo-1.0-0  1.40.1-1
ii  libstdc++6   6.1.1-5
ii  libwxbase3.0-0v5 3.0.2+dfsg-1.4
ii  libwxgtk3.0-0v5  3.0.2+dfsg-1.4
ii  libx11-6 2:1.6.3-1

gnuplot-x11 recommends no packages.

Versions of packages gnuplot-x11 suggests:
ii  gnuplot-doc  5.0.3+dfsg3-1

-- no debconf information

Bug#826366: [Pkg-utopia-maintainers] Bug#826366: Bug#826366: network-manager: does not remove resolv.conf symlink on package removal

[Michael Biebl]

Am 08.06.2016 um 11:47 schrieb Julian Gilbey:
> Question: If the symlink is reverted to an empty file on stop, but the
> /var/run version is kept intact, would NM pick it up again on restart,
> just by recreating the symlink?  Or does NM recreate the /var/run
> version on startup anyway? 

The latter

 If either of these are the case, then it
> seems that it would be fine to revert /etc/resolv.conf on stop, as it
> should have no bad effects (and possibly some good ones).
> 
> Incidentally, it seems as though NM obliterates any previously
> existing resolv.conf when it is first run, so there is no hope of
> reinstating the previous version.  This does not seem ideal, either.

Well, the /etc/resolv.conf interface is simply an aweful one. We have
multiple programs writing to the file. Restoring the old
/etc/resolv.conf is not necessarily the best idea, as it might contain
stale data.
So the problem seems to be, that programs behave different if
/etc/resolv.conf is a symlink and not a file.
Couldn't wicd be changed to takeover the symlink?
-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Bug#826366: [Pkg-utopia-maintainers] Bug#826366: Bug#826366: network-manager: does not remove resolv.conf symlink on package removal

[Michael Biebl]

Thinking more about it, if we restore the /etc/resolv.conf file on stop,
then there doesn't remain a good reason why NM uses a symlink in the
first place and I guess upstream did have a reason why it used a
distinct file in /var/run and a symlink.
I guess at this point it's best to involve upstream and we should file
this as an upstream bug report.


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



signature.asc
Description: OpenPGP digital signature

Bug#826722: [systemd] insserv-generator does not generate target file for additional system facilities

[Andre Naujoks]

Package: systemd
Version: 215-17+deb8u4
Severity: normal
Tags: patch

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

When creating a new system facility via /etc/insserv.conf.d/, the
insserv generator generates drop-in files with ordering info for the
sysv-generator-created service files (which correspond to the
init-scripts with a "Required-Start: $" line in their
LSB-headers). The problem is, that the ordering is in relation to a
non-existent target and the ordering info is just ignored.

The attached patch creates this target via the insserv-generator.

The same bug is present in sids version, but the attached patch alone
does not seem to solve the problem completely for sid. For jessie
everything is well after this. I suspect some changes in the
sysv-generator, which might cause this.

One more thing. I don't know if this is actually the right approach to
make this work i.e. creating an almost empty .target file. If
there is a better/correct way of doing this, then I am very open to that.

I created a test setup to demonstrate the issue in the attached tarball.

It contains:
# the definition of the system factility: $testsysfac
etc/insserv.conf.d/testsysfac
# the first member of the system facility (basically a "sleep 2")
etc/init.d/testsysmem1
# the second member of the system facility (basically a "sleep 2")
etc/init.d/testsysmem2
# a service depending on the system facility (also a "sleep 2")
etc/init.d/testsysdep

to enable all of this:
update-rc.d testsysmem1 defaults; update-rc.d testsysmem2 defaults;
update-rc.d testsysdep defaults;

After this the links in /etc/rc*.d should have the right order i.e.
testsysdep after the testsysmems, which are basically irrelevant for
systemd.

However, when I boot with systemd the following happens (journalctl -b,
edited to only include relevant lines):

> Jun 08 12:34:40 jessie-vm systemd[1]: Cannot add dependency job for unit 
> testsysfac.target, ignoring: Unit testsysfac.target failed to load: No such 
> file or directory.
> Jun 08 12:34:40 jessie-vm systemd[1]: Cannot add dependency job for unit 
> testsysfac.target, ignoring: Unit testsysfac.target failed to load: No such 
> file or directory.
> ...
> Jun 08 12:34:42 jessie-vm systemd[1]: Starting LSB: test system fac mem 2...
> Jun 08 12:34:42 jessie-vm systemd[1]: Starting LSB: test system fac mem 1...
> ...
> Jun 08 12:34:42 jessie-vm systemd[1]: Starting LSB: test system fac 
> dependency...
> ...
> Jun 08 12:34:44 jessie-vm systemd[1]: Started LSB: test system fac mem 1.
> Jun 08 12:34:44 jessie-vm systemd[1]: Started LSB: test system fac mem 2.
> Jun 08 12:34:44 jessie-vm systemd[1]: Started LSB: test system fac dependency.

The plain ordering here is accidentally correct, but "test system fac
dependency" should not even have been started without first reaching the
testsysfac.target. Note that the 2 second pauses are also missing
between the starting of the services. Depending on the load order of
files, I have also seen a completely random order on another boot.

After the patch is applied:

> Jun 08 12:42:33 jessie-vm systemd[1]: Starting LSB: test system fac mem 2...
> ...
> Jun 08 12:42:33 jessie-vm systemd[1]: Starting LSB: test system fac mem 1...
> ...
> Jun 08 12:42:35 jessie-vm systemd[1]: Started LSB: test system fac mem 2.
> Jun 08 12:42:35 jessie-vm systemd[1]: Started LSB: test system fac mem 1.
> Jun 08 12:42:35 jessie-vm systemd[1]: Starting testsysfac.target.
> Jun 08 12:42:35 jessie-vm systemd[1]: Reached target testsysfac.target.
> Jun 08 12:42:35 jessie-vm systemd[1]: Starting LSB: test system fac 
> dependency...
> Jun 08 12:42:37 jessie-vm systemd[1]: Started LSB: test system fac dependency.

Which honours the order of the services and actually uses the target.
The 2 second pauses are there and everything looks good.

Regards
  Andre


--- System information. ---
Architecture: amd64
Kernel:   Linux 4.6.0-trunk-amd64

Debian Release: stretch/sid
  500 unstableftp.de.debian.org 1 experimental
ftp.de.debian.org
--- Package information. ---
Depends(Version) | Installed
-+-==
libacl1(>= 2.2.51-8) | 2.2.52-3
libapparmor1   (>= 2.9.0-3+exp2) | 2.10-4
libaudit1   (>= 1:2.2.1) | 1:2.5.2-1
libblkid1(>= 2.19.1) | 2.28-5
libcap2  (>= 1:2.10) | 1:2.25-1
libcryptsetup4  (>= 2:1.4.3) | 2:1.7.0-2
libgpg-error0  (>= 1.14) | 1.22-2
libkmod2 (>= 5~) | 22-1.1
libmount1(>= 2.26.2) | 2.28-5
libpam0g   (>= 0.99.7.1) | 1.1.8-3.3
libseccomp2   (>= 2.1.0) | 2.3.1-2
libselinux1   (>= 2.1.9) | 2.5-3
libsystemd0(= 230-2) | 230-2
util-linux   (>= 2.27.1) | 2.28-5
mount  (>= 2.26) | 2.28-5
adduser  | 3.114
libcap2-bin  | 1:2.25-1


Package Status  (Version) | Insta

Bug#826723: surf: download file pdfmyurl.com

[Fulano Diego Perez]

Package: surf
Version: 0.7-2
Severity: normal


-<

can you ?

i cant find it if it does - not in runtime DIR..



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

Kernel: Linux 4.5.0-2-amd64
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages surf depends on:
ii  curl7.47.0-1
ii  libc6   2.22-7
ii  libglib2.0-02.48.1-1
ii  libgtk-3-0  3.20.6-1
ii  libjavascriptcoregtk-3.0-0  2.4.9-3
ii  libsoup2.4-12.54.1-1
ii  libwebkitgtk-3.0-0  2.4.9-3
ii  libx11-62:1.6.3-1
ii  stterm  0.6-1
ii  suckless-tools  42-1
ii  x11-utils   7.7+3

surf recommends no packages.

surf suggests no packages.

-- no debconf information

Bug#826724: RFS: pyoperators/0.13.11-1 [RC]

[Ghislain Vaillant]

Package: sponsorship-requests
Severity: important

Dear mentors,

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

* Package name: pyoperators
  Version : 0.13.11-1
  Upstream Author : Pierre Chanial
* URL : http://pchanial.github.io/pyoperators/
* License : CeCILL-B
  Section : python

It builds those binary packages:

  python-pyoperators - Operators and solvers for high-performance 
computing (Python 2)
  python3-pyoperators - Operators and solvers for high-performance 
computing (Python 3)


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


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

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

  dget -x 
https://mentors.debian.net/debian/pool/main/p/pyoperators/pyoperators_0.13.11-1.dsc


Successful build logs on debomatic:

  [amd64] 
http://debomatic-amd64.debian.net/distribution#unstable/pyoperators/0.13.11-1/buildlog


Changes since the last upload:

  * New upstream release. (Closes: #805678)
  * Add gbp.conf file.
  * Use better patch for distutils setup requirements.
  * cme fix d/control:
- Wrap and sort Build-Depends.
- Bump Standards-Version to 3.9.8, no changes required.
- Use secure Vcs-Git URI.
  * d/control: add missing Build-Depends on Cython and pkg-resources.
  * d/control: fix list of recommended / suggested dependencies:
- Drop numexpr from Recommends, picked as Depends instead.
- Add mpi4py, pyfftw, pywt to Suggests.
  * d/{clean,rules}: use auto-clean target.
  * d/rules: move calls to dh_numpy to dh_python overrides.
  * d/rules: use standard formatting for DH_VERBOSE.
  * d/{control,rules}: disable testing due to upstream bug.

Regards,
Ghislain Vaillant

Bug#826722: Wrong system information in initial bug report

[Andre Naujoks]

The additional package versions and system information in the initial
bug report are wrong. I used reportbug-ng on the host, that runs the vm,
where the testing took place. Please ignore.

Bug#826725: KDE bugs that causes KDE freeze unexpectly

[M0xkLurk3r]

Package: plasma-desktop
Version: 4:5.4.3-1
Severity: grave
Tags: patch

I don't know what happened but my KDE desktop always crash or I should call
that 'freeze' when I open the "Settings -> Fonts" and choose an type of fonts
for modify. Same bugs happenes again when I open my tor browser, and I have to
switch back to tty1 and restart the sddm.



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

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

Versions of packages plasma-desktop depends on:
ii  breeze  4:5.4.3-1
ii  kactivities 5.16.0-1
ii  kde-cli-tools   4:5.6.4-1
ii  kded5   5.22.0-1
ii  kio 5.22.0-1
ii  libc6   2.22-9
ii  libcanberra00.30-3
ii  libfontconfig1  2.11.0-6.4
ii  libgcc1 1:6.1.1-4
ii  libkf5activities5   5.22.0-2
ii  libkf5activitiesexperimentalstats1  4:5.4.3-1
ii  libkf5archive5  5.22.0-1
ii  libkf5auth5 5.22.0-1
ii  libkf5baloo55.22.0-1
ii  libkf5bookmarks55.22.0-2
ii  libkf5codecs5   5.22.0-1
ii  libkf5completion5   5.22.0-1
ii  libkf5configcore5   5.22.0-1
ii  libkf5configgui55.22.0-1
ii  libkf5configwidgets55.22.0-1
ii  libkf5coreaddons5   5.22.0-1
ii  libkf5dbusaddons5   5.22.0-1
ii  libkf5emoticons55.22.0-1
ii  libkf5globalaccel5  5.22.0-1
ii  libkf5guiaddons55.22.0-1
ii  libkf5i18n5 5.22.1-1
ii  libkf5iconthemes5   5.22.0-1
ii  libkf5itemviews55.22.0-1
ii  libkf5jobwidgets5   5.22.0-1
ii  libkf5kcmutils5 5.22.0-1
ii  libkf5kdelibs4support5  5.22.0-2
ii  libkf5kiocore5  5.22.0-1
ii  libkf5kiofilewidgets5   5.22.0-1
ii  libkf5kiowidgets5   5.22.0-1
ii  libkf5newstuff5 5.22.0-1
ii  libkf5notifications55.22.0-1
ii  libkf5notifyconfig5 5.22.0-1
ii  libkf5parts55.22.0-1
ii  libkf5people5   5.22.0-1
ii  libkf5peoplewidgets55.22.0-1
ii  libkf5plasma5   5.22.0-1
ii  libkf5plasmaquick5  5.22.0-1
ii  libkf5quickaddons5  5.22.0-1
ii  libkf5runner5   5.22.0-1
ii  libkf5service-bin   5.22.0-1
ii  libkf5service5  5.22.0-1
ii  libkf5solid55.22.0-1
ii  libkf5sonnetui5 5.22.0-2
ii  libkf5wallet-bin5.22.0-1
ii  libkf5wallet5   5.22.0-1
ii  libkf5widgetsaddons55.22.0-1
ii  libkf5windowsystem5 5.22.0-1
ii  libkf5xmlgui5   5.22.0-1
ii  libkfontinst5   4:5.4.3-1
ii  libkfontinstui5 4:5.4.3-1
ii  libkworkspace5-54:5.6.4-2
ii  libphonon4qt5-4 4:4.9.0-2
ii  libpulse-mainloop-glib0 8.0-2+b2
ii  libpulse0   8.0-2+b2
ii  libqt5concurrent5   5.5.1+dfsg-17
ii  libqt5core5a5.5.1+dfsg-17
ii  libqt5dbus5 5.5.1+dfsg-17
ii  libqt5gui5  5.5.1+dfsg-17
ii  libqt5network5  5.5.1+dfsg-17
ii  libqt5printsupport5 5.5.1+dfsg-17
ii  libqt5qml5  5.5.1-3
ii  libqt5quick55.5.1-3
ii  libqt5svg5  5.5.1-2
ii  libqt5widgets5  5.5.1+dfsg-17
ii  libqt5x11extras55.5.1-3
ii  libqt5xml5  5.5.1+dfsg-17
ii  libstdc++6  6.1.1-4
ii  libtaskmanager5 4:5.6.4-2
ii  libx11-62:1.6.3-1
ii  libx11-xcb1 2:1.6.3-1
ii  libxcb-record0  1.11.1-1
ii  libxcb-xkb1 1.11.1-1
ii  libxcb1 1.11.1-1
ii  libxcursor1 1:1.1.14-1+b1
ii  libxfixes3  1:5.0.1-2+b2
ii  libxi6  2:1.7.6-1
ii  libxkbfile1 1:1.0.9-2
ii  oxygen-sounds   4:5.6.4-1
ii  phonon4qt5  4:4.9.0-2
ii  plasma-desktop-data 4:5.4.3-1
ii  plasma-framework 

Bug#826601: ITP: itty -- the itty-bitty python web framework

[Gilles Dubuc]

I won't be packaging this after all. I thought I needed it for a
hidden dependency of remotecv (which I'm packaging, see #825893), but
after discussing this with the remotecv maintainers, we ended up
removing the code that used itty entirely:
https://github.com/thumbor/remotecv/commit/ba17ea3ee065b28ede21b6a87c8a4d1297f9455c

On Mon, Jun 6, 2016 at 11:14 PM, Gilles Dubuc  wrote:
> Package: wnpp
> Severity: wishlist
> Owner: Gilles Dubuc 
>
> * Package name: python-itty
>   Version : 0.8.2
>   Upstream Author : Daniel Lindsley 
> * URL : https://github.com/toastdriven/itty
> * License : BSD License
>   Programming Lang: Python
>   Description : itty.py is a little experiment, an attempt at a
> Sinatra influenced micro-framework that does just enough to be useful
> and nothing more.
>
> Currently supports:
>
> Routing
> Basic responses
> Content-types
> HTTP Status codes
> URL Parameters
> Basic GET/POST/PUT/DELETE support
> User-definable error handlers
> Redirect support
> File uploads
> Header support
> Static media serving

Bug#826726: Please drop Suggests: mountall

[Michael Biebl]

Package: cgroupfs-mount
Version: 1.2
Severity: normal

Hi,

upstart has been removed from the archive and mountall along with it [1]

The scripts in cgroupfs-mount don't use any facilities provided by
mountall. So I don't see why cgroupfs-mount had a Depends or Suggests:
mountall in the first place.
Please consider dropping the remaining Suggests: mountall from
cgroupfs-mount.

Thanks for considering,
Michael

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=810673
-- System Information:
Debian Release: stretch/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (200, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.5.0-2-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)

Bug#824933: [Android-tools-devel] Bug#824933: Bug#824933: apktool: crashes with every APK

[Hans-Christoph Steiner]

Perhaps we could include a script that makes it easy to fetch
framework-res.apk from any connected device or emulator?  Its just a
matter of doing `adb pull` as far as I know.

Bug#826727: anki: Anki does not start anymore

[Matthias Wimmer]

Package: anki
Version: 2.0.32+dfsg-1
Severity: grave
Justification: renders package unusable

Anki does not start anymore. When called from the command line, I get the
following traceback:

=
Traceback (most recent call last):
  File "/usr/bin/anki", line 7, in 
import aqt
  File "/usr/share/anki/aqt/__init__.py", line 12, in 
from aqt.qt import *
  File "/usr/share/anki/aqt/qt.py", line 22, in 
from PyQt4.QtWebKit import QWebPage, QWebView, QWebSettings
ImportError: No module named QtWebKit
=


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

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

Versions of packages anki depends on:
ii  libjs-jquery  1.12.3-1
ii  libjs-jquery-flot 0.8.3+dfsg-1
ii  libjs-jquery-ui   1.10.1+dfsg-1
ii  python2.7.11-2
ii  python-beautifulsoup  3.2.1-1
ii  python-httplib2   0.9.1+dfsg-1
ii  python-pyaudio0.2.8-1+b3
ii  python-qt44.11.4+dfsg-2
ii  python-simplejson 3.8.2-2
ii  python-sqlalchemy 1.0.13+ds1-1
pn  python:any

Versions of packages anki recommends:
ii  python-matplotlib  1.5.2~rc2-1

Versions of packages anki suggests:
pn  dvipng
ii  lame  3.99.5+repack1-9+b1
ii  mplayer2  2:1.3.0-2

-- no debconf information

Bug#783652: Bug #783652: apt-transport-tor: retry downloading for interrupted packages

[Tim Retout]

tags 783652 wontfix
thanks

Hi again,

Although I regret that errors occur more frequently when using tor, I don't
believe this is one to be fixed in every apt transport.  Apt provides the
config value "Apt::Acquire::Retries" that should retry downloads whether
it's HTTP, HTTPS or any other mechanism.

Unless there is a specific issue that is tor-specific, that can be fixed
automatically by the transport code (i.e. doesn't require restarting the
tor daemon?), I think it should be left to that config variable.

I would, however, accept a patch to mention the above config value in the
apt-transport-tor documentation - and when that happens, I would close this
bug.

Kind regards,

-- 
Tim Retout 

Bug#824933: [Android-tools-devel] Bug#824933: Bug#824933: apktool: crashes with every APK

[Paul Wise]

On Wed, 2016-06-08 at 13:59 +0200, Hans-Christoph Steiner wrote:

> Perhaps we could include a script that makes it easy to fetch
> framework-res.apk from any connected device or emulator?  Its just a
> matter of doing `adb pull` as far as I know.

That sounds good for folks who have a device or already installed the
SDK via some means. I don't own any device so this won't work for me.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#824930: [Android-tools-devel] Bug#824930: Bug#824930: Bug#824930: apktool: creates directories and an empty 1.apk file in $HOME

[Hans-Christoph Steiner]

I think it might be more honest to help the user fetch framework-res.apk
from a connected device or emulator using `adb pull` rather than
including one in Debian, since for many use cases, it'll require a
different framework-res.apk.  Like the example in the apktool docs,
where it talks about an HTC-specific framework-res.apk:
https://ibotpeaches.github.io/Apktool/documentation/

Perhaps `apktool install-framework` could modified to do this? Or just a
standalone script?

I think we should definitely patch apktool to set an XDG dir.  I prefer
~/.local/share/apktool since the file is required for apktool to work,
but ~/.cache/apktool would be OK.

Bug#813096: ITP: logdata-anomaly-miner -- lightweight tool for log checking, log analysis

[Fiedler Roman]

> Von: Gianfranco Costamagna [mailto:costamagnagianfra...@yahoo.it]
>
> Hi
>
> > I still don't see "python" in build-dependencies.
>
> >I tried that already, but somehow it did not work out (that's why the
> >manual
> >"python2.6 | python2.7" is kept).
>
> the reason should be the missing python dependency and the missing
> dh_python2 call

I must be somehow missing the obvious:

I had already added it already to

* control

Depends: ${python:Depends}, python-tz, ${misc:Depends}

which was mangled (with warning) to:

Depends: python-tz, init-system-helpers (>= 1.18~)

Thus dh_python fails to pick up the correct dependency information.


I have not found a complete solution, but following gets rid of the warnings
during dh_gencontrol ("Depends field of package logdata-anomaly-miner: unknown
substitution variable ${python:Depends}") and creates a correct control file:

override_dh_gencontrol:
# Invoke dh_python2 manually to be sure it was run. It does not extract the
correct dependency information anyway.
/usr/share/dh-python/dh_python2 -p logdata-anomaly-miner -V 2.6-
usr/lib/aminer/AMiner usr/lib/aminer/AMinerRemoteControl
# Set the information manually so that dh_gencontrol and downstream parameter
substitution will work.
echo "python:Depends=python2.7" >>
debian/logdata-anomaly-miner.substvars
dh_gencontrol


Also just to make lintian happy, I will apply following patch to Debian
branch:

diff --git a/source/root/usr/lib/aminer/AMiner
b/source/root/usr/lib/aminer/AMiner
index 2dee083..e64de05 100755
--- a/source/root/usr/lib/aminer/AMiner
+++ b/source/root/usr/lib/aminer/AMiner
@@ -1,4 +1,4 @@
-#!/usr/bin/python2 -BEsSt
+#!/usr/bin/python2.7 -BEsSt

Everything seems to work without it also and the same package could have been
used for python2.6 and python2.7 systems but lintian does not understand that.

> >I'll stay on that one (see todos), at the moment I am trying to figure out
> >with strace what the rule
> >
> >/usr/share/dh-python/dh_python2 -p logdata-anomaly-miner
> >usr/lib/aminer/AMiner usr/lib/aminer/AMinerRemoteControl
> >
> >is doing and why it does not detect the correct version to pass it on to
> >dpkg-gencontrol.
>
>
> don't know, dh --python2 should do the job.
> not sure why you override that

I do not want to override anything, just something seems to block dh_python2
from correct operation and man pages/debugging output is not conclusive, what
the problem could be. As the above fixes get rid of all warnings and seem to
produce functional package, I would let that topic rest now as I do not see a
simpler solution.

> [Snip]
> >Would that split of old postinst solve all problems without provoking new
> >ones?
>
> I guess so
> >a) new preinst: the user/creation (with #DEBHELPER#)
> >b) postinst: chmod/chown, .. changes to files (WITHOUT the #DEBHELPER#)
>
> with DEBHELPER too.
>
> preinst <-- user creation

Moved user creation from post to preinst

> postinst <-- systemd start (automatically)

Kept the file perm changes, ... here. But the automatic startup WITHOUT
specific manually created configuration is not wanted. Unless there is a more
policy-compliant way to archive that, I would keep the "exit 0" before the 
"#DEBHELPER#" stanza, which also makes lintian happy.

> prerm <-- systemd stop (automatically)
> postrm <-- user del and whatever
>
> I'm not completely sure, just try, test and look at the policy
> https://www.debian.org/doc/debian-policy/ch-maintainerscripts.html

Adjusted "rm" phase according to that. Reverting all install changes in
remove, so "purge" will only delete the configuration files (without script
action).

> >OK, I have deleted for now. What about the suggestion with the
> CHANGELOG?
> >
> >Currently debian/changelog is the "packaging changelog". But the software
> has
> >also a "feature/version changelog". Where should that be kept best?
> Options:
>
> dh_installchangelogs is your friend :)
> (but files that has similar names are added automatically I guess, just
> check if
> it is added or not

OK, I have moved the "feature" changelog to the usr/share/doc. The
"debian/changelog "packaging" changelog starts now with just a single entry,
containing the latest version of the upstream code.

> >I have removed that part, both unused options and the error handling.
>
> it should already be handled in the DEBHELPER macro, right?

Seems the DEBHELPER macro does not handle it (just generates some empty lines
when nothing to do), but I guess typos, specification changes, ... will be
caught by other means, so skipping the input validation as suggested will not
hurt.

> >Thanks for the pointer to quilt. Seems to make sense, is on the todo list.
>
> ok
>
> >Understood, quilt will do here also.
>
> yes

I have changed the format from "native" to "quilt". According to source of
"Dpkg::Source::Package", it is impossible to preserve parts of the content of
the "debian/" directory included in the upstream orig.tar.gz, they will be
always deleted

Bug#824933: [Android-tools-devel] Bug#824933: Bug#824933: apktool: crashes with every APK

[Hans-Christoph Steiner]

framework-res.apk is not included in the SDK, only the OS.  Packaging
parts of the OS means we are making packages that upstream is not.
There are plenty of places to download framework-res.apk, including the
apktool website itself.

Bug#826728: percona-toolkit: (CVE-2014-2029) scripts call back home and leak information

[Guillem Jover]

Package: percona-toolkit
Version: 2.2.11-1~dfsg1
Severity: grave
Tags: security

Hi!

This package contains many scripts which call back home to check for
a new upstream versions. In addition they also report back things such
as hostname and port and similar. It seems this was previously disabled
or removed due to CVE-2014-2029 (#740846), but the patch got lost
somewhere?

This affects the current stable/testing/unstable distributions AFAICS.

Thanks,
Guillem

Bug#826729: ITP: python-cymruwhois -- python library for interfacing with the whois.cymru.com service

[Ana Custura]

Package: wnpp
Severity: wishlist
Owner: Ana Custura 

* Package name: python-cymruwhois
  Version : 1.5
  Upstream Author : Justin Azoff 
* URL : https://github.com/JustinAzoff/python-cymruwhois
* License : X11
  Programming Lang: Python
  Description : python library for interfacing with the whois.cymru.com 
service

I would like to package dnsdiag, which in turn depends on this library.

Bug#826730: puppet: conffiles not removed

[Paul Wise]

Package: puppet
Version: 4.5.0-4
Severity: normal
User: debian...@lists.debian.org
Usertags: obsolete-conffile adequate

The recent upgrade did not deal with obsolete conffiles properly.
Please use the dpkg-maintscript-helper support provided by
dh_installdeb to remove these obsolete conffiles on upgrade.
I upgraded from puppet 3.8.5-2 to 4.5.0-4 and purged version 3.8.5-2 of
puppet-common at the same time.

https://www.debian.org/doc/debian-policy/ch-files.html#s-config-files
http://manpages.debian.org/man/1/dh_installdeb

This bug report brought to you by adequate:

http://bonedaddy.net/pabs3/log/2013/02/23/inadequate-software/

$ pkg=puppet ; adequate $pkg ; dpkg-query -W -f='${Conffiles}\n' $pkg | grep 
obsolete
puppet: obsolete-conffile /etc/init.d/puppet
 /etc/init.d/puppet 9eb2754a651af8a0ad2091fbba775bcc obsolete

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

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

Versions of packages puppet depends on:
ii  adduser  3.114
ii  facter   2.4.6-1
ii  hiera2.0.0-2
ii  lsb-base 9.20160601
ii  ruby 1:2.3.0+4
ii  ruby-augeas  1:0.5.0-3+b4
ii  ruby-deep-merge  1.0.1+gitf9df6fdb-1
ii  ruby-rgen0.8.0-1
ii  ruby-safe-yaml   1.0.4-1
ii  ruby-shadow  2.4.1-1+b3
ii  sysv-rc  2.88dsf-59.4

Versions of packages puppet recommends:
ii  debconf-utils  1.5.59
ii  lsb-release9.20160601
pn  ruby-selinux   

Versions of packages puppet suggests:
pn  ruby-rrd  

-- no debconf information

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#826731: RM: clutter-gst-2.0 -- ROM; superseded by clutter-gst-3.0

[Michael Biebl]

Package: ftp.debian.org
Severity: normal

clutter-gst-2.0 has been superseded by clutter-gst-3.0. We've been
tracking the process of removing clutter-gst-2.0 at [1].

Please remove clutter-gst-2.0 now that there are no more blockers left.

Regards,
Michael


[1] 
https://bugs.debian.org/cgi-bin/pkgreport.cgi?users=pkg-gnome-maintain...@lists.alioth.debian.org;tag=clutter-gst-2.0

Bug#826732: gnuplot-nox: gnuplot-nox uninstallable

[Félix Sipma]

Package: gnuplot-nox
Version: gnuplot-nox uninstallable
Severity: important
File: gnuplot-nox

gnuplot-nox seems to be uninstallable on sid:

$ sudo apt install gnuplot-nox
Reading package lists... Done
Building dependency tree   
Reading state information... Done
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies:
 gnuplot-nox : Depends: gnuplot-data (= 5.0.3+dfsg3-2) but it is not going 
to be installed
E: Unable to correct problems, you have held broken packages.


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

Kernel: Linux 4.5.0-2-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 /usr/bin/dash
Init: systemd (via /run/systemd/system)


signature.asc
Description: PGP signature

Bug#682929: equivs: Confused by symlinks in Files

[Rhonda D'Vine]

Hi,

 any news on this?

* Ian Zimmerman  [2012-07-27 08:28:22 CEST]:
> When I make foo a trivial shell script instead, it works:
>  [52+1]transitional-foo cat foo
> #! /bin/sh
> 
> exec /usr/bin/bar "$@"

 That workaround only works for when you want to do a symlink to
something you want to have executed.  If it's about something else than
things to execute this workaround doesn't help at all. :/

 So long,
Rhonda
-- 
Fühlst du dich mutlos, fass endlich Mut, los  |
Fühlst du dich hilflos, geh raus und hilf, los| Wir sind Helden
Fühlst du dich machtlos, geh raus und mach, los   | 23.55: Alles auf Anfang
Fühlst du dich haltlos, such Halt und lass los|

Bug#745615: dcraw maintenance

[GCS]

Hi,

I do _not_ want to step on anyone's toe, but how dcraw packaging goes?
There's a new upstream release for three weeks, probably fixing the
open vulnerability, CVE-2015-8366.
Also it prevents removing Jasper which transitively causing other
package removals. As it's a small package, updating it is easy and
shouldn't take more than a hour or so.
May you do it Filip or should I take it instead?

Thanks in advance,
Laszlo/GCS

Bug#826733: libcap2-bin: please move some man page content to libcap2-bin

[Adam Borowski]

Package: libcap2-bin
Version: 1:2.25-1
Severity: minor

Hi!
I'm afraid libcap2-bin lacks some documentation required to use it.  Could
you please make at least the section "ᴛᴇxᴛᴜᴀʟ ʀᴇᴘʀᴇꜱᴇɴᴛᴀᴛɪᴏɴ" from
cap_from_text(3) available in the main package?  It describes the syntax
needed to set capabilities.

It could be done by:
* moving that entire manpage.  Slightly inappropriate (C interface belongs
  in libcap-dev) but least amount of work.
* moving just the section
* paraphrasing most relevant parts ("man setcap" is a stub)


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

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

Versions of packages libcap2-bin depends on:
ii  libc62.22-11
ii  libcap2  1:2.25-1

Versions of packages libcap2-bin recommends:
pn  libpam-cap  

libcap2-bin suggests no packages.

-- no debconf information

Bug#826734: mh_install doesn't work with dh-exec

[Ondřej Surý]

Package: maven-repo-helper
Version: 1.8.12
Severity: normal

Dear maintainer(s),

I have recently helped with zeroc-ice packaging and the debian/*.poms
contains an upstream version number, so it would be very convenient if
dh-exec would work, so I could dynamically replace ${VERSION} at the
build time.

Unfortunately the build breaks as it looks like mh_install is not
using standard debhelper mechanisms to access the files:

14:39 < algernon> ondrej: hm, perhaps mh_install is doing its own
magic, and doesn't go through debhelpers thing that makes executable
files work :/ │

Could you perhaps work with dh-exec maintainer to resolve this?

Cheers,
Ondrej

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

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

Bug#826735: ITP: haskell-monadplus -- Haskell98 partial maps and filters over MonadPlus

[Sean Whitton]

Package: wnpp
Severity: wishlist
Owner: Sean Whitton 

* Package name: haskell-monadplus
  Version : 1.4.2
  Upstream Author : Hans Hoglund 
* URL : https://hackage.haskell.org/package/monadplus
* License : BSD-3-clause
  Programming Lang: Haskell
  Description : Haskell98 partial maps and filters over MonadPlus

This is a library providing functions to work with the MonadPlus
typeclass (which is part of core Haskell).

I'm packaging this on behalf of the Haskell team, as a new dependency
for the latest version of agda.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#826736: network-manager-ssh-gnome: Fails to upgrade from 0.9.4-1 to 1.2.0-1 due to missing Replaces header

[Axel Beckert]

Package: network-manager-ssh-gnome
Version: 1.2.0-1
Severity: serious

Hi,

sorry for the late bug report, had no time to write it when I
encountered it the first time a few weeks ago and put the package(s) on
hold since then.

Upgrading network-manager-ssh-gnome and network-manager-ssh in the same
run fails for me since network-manager-ssh-gnome 1.2.0-1 is unpacked
first and tries to overwrite a file from the not yet upgraded
network-manager-ssh 0.9.4-1:

Preparing to unpack .../network-manager-ssh-gnome_1.2.0-1_amd64.deb ...
Unpacking network-manager-ssh-gnome (1.2.0-1) over (0.9.4-1) ...
dpkg: error processing archive 
/var/cache/apt/archives/network-manager-ssh-gnome_1.2.0-1_amd64.deb (--unpack):
 trying to overwrite '/usr/lib/NetworkManager/nm-ssh-auth-dialog', which is 
also in package network-manager-ssh 0.9.4-1
Preparing to unpack .../network-manager-ssh_1.2.0-1_amd64.deb ...
Unpacking network-manager-ssh (1.2.0-1) over (0.9.4-1) ...
Processing triggers for dbus (1.10.8-1) ...
Errors were encountered while processing:
 /var/cache/apt/archives/network-manager-ssh-gnome_1.2.0-1_amd64.deb

This likely can be fixed by adding the following two headers to
network-manager-ssh-gnome's stanza in debian/control:

Replaces: network-manager-ssh (<< 1.2.0-1~)
Breaks: network-manager-ssh (<< 1.2.0-1~)

-- System Information:
Debian Release: stretch/sid
  APT prefers unstable
  APT policy: (990, 'unstable'), (980, 'unstable-debug'), (600, 'testing'), 
(111, 'buildd-unstable'), (111, 'buildd-experimental'), (110, 'experimental'), 
(105, 'experimental-debug')
Architecture: amd64 (x86_64)

Kernel: Linux 4.6.0-trunk-amd64 (SMP w/4 CPU cores)
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 network-manager-ssh depends on:
ii  libc6   2.22-11
ii  libglib2.0-02.48.1-1
ii  libnm0  1.2.2-2
ii  openssh-client  1:7.2p2-5
ii  sshpass 1.05-1

Versions of packages network-manager-ssh recommends:
ii  network-manager-ssh-gnome  0.9.4-1

network-manager-ssh suggests no packages.

-- no debconf information

Bug#824670: ITP: dnsdiag -- DNS Diagnostics and Performance Measurement Tools

[Ana C. Custura]

retitle 824670 ITP: dnsdiag -- DNS Diagnostics and Performance
Measurement Tools
owner 824670 !
block 824670 by 826729
thanks

Bug#826737: Please package paramiko >= 2.0 in Experimental

[Thomas Goirand]

Source: paramiko
Version: 1.16.0-1
Severity: normal

Hi,

For OpenStack Newton, I need python-paramiko >= 2.0. Nova (ie: OpenStack
compute) requires that version. For the moment I only need it into Debian
Experimental, until Newton is released after this summer. However, this is a
blocking issue for me, as the API in 2.x changed, and therefore, Nova is now
incompatible with Paramiko in Sid.

Alternatively, if you don't have the time to take care of it, I can do the
needed work, and upload to Experimental. Please let me know.

Having a quick look, the below non-OpenStack packages need Paramiko:
  Reverse Depends: ansible (2.0.2.0-1)
  Reverse Depends: fabric (>= 1.10.2-1)
  Reverse Depends: fdroidserver (0.6.0-2)
  Reverse Depends: freeipa-tests (4.0.5-6+b1)
  Reverse Depends: ganeti-2.15 (2.15.2-3)
  Reverse Depends: jeepyb (0+20151217-1)
  Reverse Depends: mysql-workbench (6.3.4+dfsg-3+b4)
  Reverse Depends: obnam (1.19.1-1)
  Reverse Depends: python-fs-plugin-sftp (0.5.4-1)
  Reverse Depends: python-gerritlib (0.4.0+git20150319-2)
  Reverse Depends: python-junos-eznc (1.3.1-1)
  Reverse Depends: python-ncclient (0.4.7-1)
  Reverse Depends: python-netmiko (0.5.1-1)
  Reverse Depends: python-pushy (0.5.1-1.1)
  Reverse Depends: python-pyfg (0.47-1)
  Reverse Depends: python-roswtf (1.11.16-5)
  Reverse Depends: python-scp (0.10.2-1)
  Reverse Depends: python-spur (0.3.17-1)
  Reverse Depends: python-x2go (>= 0.5.0.4-1)

And here's the list of OpenStack packages that need it:
  Reverse Depends: sftpcloudfs (0.12.2-2)
  Reverse Depends: python-cinder (>= 2:8.0.0-4)
  Reverse Depends: python-ironic (1:5.1.0-2)
  Reverse Depends: python-magnum (>= 2.0.0-5)
  Reverse Depends: python-manila (>= 1:2.0.0-4)
  Reverse Depends: python-mistral (2.0.0-2)
  Reverse Depends: python-rally (0.2.0-1)
  Reverse Depends: python-nova (2:13.0.0-3)
  Reverse Depends: python-ryu (3.30+dfsg1-2)
  Reverse Depends: python-sahara (1:4.0.0-2)
  Reverse Depends: python-tempest (1:12.0.0-2)
  Reverse Depends: python-tempest-lib (0.14.0-2)
  Reverse Depends: tempest (6-1)

So, very much, we need to handle a transition here. Which is another (non-
OpenStack) reason why we should handle a transition through Experimental. IMO,
it'd be nice to have that transition done for Stretch.

Your thoughts?

Cheers,

Thomas Goirand (zigo)

Bug#826738: chkrootkit: false positive for Linux/Ebury - Operation Windigo -> due to now existing "ssh -G" parameter

[cruncher]

Package: chkrootkit
Version: 0.50-3.2
Severity: normal
Tags: upstream

Now that the parameter -G exists for ssh, we get daily a false positive.



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

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

Versions of packages chkrootkit depends on:
ii  binutils   2.26-10
ii  debconf [debconf-2.0]  1.5.59
ii  libc6  2.22-11
ii  net-tools  1.60+git20150829.73cef8a-2
ii  openssh-client 1:7.2p2-5
ii  procps 2:3.3.11-3

chkrootkit recommends no packages.

chkrootkit suggests no packages.

-- debconf information:
  chkrootkit/run_daily: true
  chkrootkit/diff_mode: false
  chkrootkit/run_daily_opts: -q -n

Bug#826739: transition: libconfuse

[Michael Biebl]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: transition

Hi release team,

looks like there was an uncoordinated library transition when libconfuse
3.0 was uploaded to unstable bumping the soname.

I guess we should start binNMUing packages found by the autotracker [¹].

Regards,
Michael


[¹] https://release.debian.org/transitions/html/auto-confuse.html
-- System Information:
Debian Release: stretch/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (200, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.5.0-2-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)

Bug#826740: override: libfwupd1:libs/optional

[Michael Biebl]

Package: ftp.debian.org
Severity: normal

Hi,

please change the section of libfwupd1 from admin to libs.

Thanks,
Michael

Bug#826739: transition: libconfuse

[Aurelien Jarno]

control: forcemerge 826593 -1

On 2016-06-08 15:03, Michael Biebl wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: transition
> 
> Hi release team,
> 
> looks like there was an uncoordinated library transition when libconfuse
> 3.0 was uploaded to unstable bumping the soname.

This transition has been acknowledged by a release team member in bug
#826593. Merging the bugs.

Aurelien

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

Bug#826734: mh_install doesn't work with dh-exec

[Emmanuel Bourg]

Hi Ondřej,

What kind of substitution would you like to perform in the debian/*.poms
files? Could you post an example please?

Emmanuel Bourg

Bug#826734: mh_install doesn't work with dh-exec

[Ondřej Surý]

Hi Emmanuel,

this is the debian/libzeroc-ice-java.poms:

$ cat debian/libzeroc-ice-java.poms
java/lib/ice-3.6.2.pom --artifact=java/lib/ice-3.6.2.jar
java/lib/icebox-3.6.2.pom --artifact=java/lib/icebox-3.6.2.jar
java/lib/icediscovery-3.6.2.pom
--artifact=java/lib/icediscovery-3.6.2.jar
java/lib/icelocatordiscovery-3.6.2.pom
--artifact=java/lib/icelocatordiscovery-3.6.2.jar
java/lib/icegrid-3.6.2.pom --artifact=java/lib/icegrid-3.6.2.jar
java/lib/icestorm-3.6.2.pom --artifact=java/lib/icestorm-3.6.2.jar
java/lib/icepatch2-3.6.2.pom --artifact=java/lib/icepatch2-3.6.2.jar
java/lib/glacier2-3.6.2.pom --artifact=java/lib/glacier2-3.6.2.jar
java/lib/freeze-3.6.2.pom --artifact=java/lib/freeze-3.6.2.jar

and here's f.e. debian/libzeroc-ice-java.links:

$ cat debian/libzeroc-ice-java.links 
#!/usr/bin/dh-exec
usr/share/java/freeze-${VERSION}.jar usr/share/java/freeze.jar
usr/share/java/glacier2-${VERSION}.jar usr/share/java/glacier2.jar
usr/share/java/ice-${VERSION}.jar usr/share/java/ice.jar
usr/share/java/icebox-${VERSION}.jar usr/share/java/icebox.jar
usr/share/java/icediscovery-${VERSION}.jar
usr/share/java/icediscovery.jar
usr/share/java/icelocatordiscovery-${VERSION}.jar
usr/share/java/icelocatordiscovery.jar
usr/share/java/icegrid-${VERSION}.jar usr/share/java/icegrid.jar
usr/share/java/icepatch2-${VERSION}.jar usr/share/java/icepatch2.jar
usr/share/java/icestorm-${VERSION}.jar usr/share/java/icestorm.jar
usr/share/java/freeze-${VERSION}-source.jar
usr/share/java/freeze-source.jar
usr/share/java/glacier2-${VERSION}-source.jar
usr/share/java/glacier2-source.jar
usr/share/java/ice-${VERSION}-source.jar usr/share/java/ice-source.jar
usr/share/java/icebox-${VERSION}-source.jar
usr/share/java/icebox-source.jar
usr/share/java/icediscovery-${VERSION}-source.jar
usr/share/java/icediscovery-source.jar
usr/share/java/icelocatordiscovery-${VERSION}-source.jar
usr/share/java/icelocatordiscovery-source.jar
usr/share/java/icegrid-${VERSION}-source.jar
usr/share/java/icegrid-source.jar
usr/share/java/icepatch2-${VERSION}-source.jar
usr/share/java/icepatch2-source.jar
usr/share/java/icestorm-${VERSION}-source.jar
usr/share/java/icestorm-source.jar

With upstream bump to 3.6.3, I will have to modify *.poms, but *.links
will be ok, as I export VERSION from the d/rules.

(P.S.: I have no clue about Java at all, so this is what the package has
and I only used dh-exec to make it simpler).

Cheers,
-- 
Ondřej Surý 
Knot DNS (https://www.knot-dns.cz/) – a high-performance DNS server
Knot Resolver (https://www.knot-resolver.cz/) – secure, privacy-aware,
fast DNS(SEC) resolver

On Wed, Jun 8, 2016, at 15:15, Emmanuel Bourg wrote:
> Hi Ondřej,
> 
> What kind of substitution would you like to perform in the debian/*.poms
> files? Could you post an example please?
> 
> Emmanuel Bourg
> 

Bug#826741: tcl nonblocking "gets" has serious spinning bug

[Ian Jackson]

Package: libtcl8.6
Version: 8.6.2+dfsg-2+iwj1
Tags: + fixed-upstream
Control: fixed -1 8.6.5+dfsg-2

Running the attached script demonstrates that gets(3tcl) has a serious
bug in jessie's tcl.  See attached transcript.

I used gdb on tcl8.6 and the bug seems to be that in TclGetsObjBinary,
if CHANNEL_BLOCKED is set on entry, and the buffer does not already
contain a newline, TclGetsObjBinary doesn't attempt to read from the
underlying fd.  It simply indicates "nothing ready now".

The fd remains readable, so the fileevent re-triggers.

In a real application this means that the event loop will spin.  It
will not only use excessive CPU use, but this spinning can prevent
other events being processed, resulting in nonfunctional applications.

I found this bug report in the upstream bug tracker which seems
relevant:
  https://core.tcl.tk/tcl/tktview/10dc6daa375d45051a3c
Particularly, the comment "anonymous added on 2014-10-17 08:43:43"
contains a code change which looks to me like it would fix the
problem (although this code is very tangled).

A good approach for Debian might be to update stable's tcl8.6 to a
more recent upstream stable branch.  stretch's tcl8.6 does not have
the bug, and AFAICT is very similar to upstream 8.6.5.

Thanks,
Ian.

#!/usr/bin/tclsh8.6

file delete -force p
exec mkfifo -m 600 p

set writer [open p r+]
set reader [open p r]

fconfigure $reader -blocking false -translation binary
fconfigure $writer -buffering none

set counter 0

proc readable-gets {args} {
global reader counter
puts stderr readable
set got [gets $reader l]
puts stderr "readable got=$got l=$l"
if {[incr counter] > 20} { puts stderr BUG; exit 1 }
}

proc do-write {s} {
global writer
puts stderr "writing `$s'"
puts -nonewline $writer $s
}

proc do-read-read {n} {
global reader
puts stderr "reading-with-read n=$n"
set got [read $reader $n]
puts stderr "reading-with-read n=$n got=$got"
}

fileevent $reader readable readable-gets

#do-read-read 30

do-write "half a line"

after 1000 { do-write "half a line more" }
after 2000 { do-write "rest of the line\n" }
after 3000 { puts stderr OK; exit 0 }

vwait forever


-- 
Ian JacksonThese opinions are my own.

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

Bug#792227: dup of 617818

[Mathieu Malaterre]

Actually relax.jp2 can be found in #617818

Bug#826743: introspection typelib file needs to be split out into a separate binary package

[Michael Biebl]

Package: libfwupd1
Version: 0.7.0-1
Severity: important
Tags: patch

Hi,

the gobjection introspection file 
/usr/lib/$(MULTIARCH_PATH)/girepository-1.0/Fwupd-1.0.typelib
should to be split out into a separate binary package following the
gobject-introspection policy [1].

In this case the package would be named gir1.2-fwupd-1.0

Patch is attached.

Thanks for considering,
Michael


[1] 
https://anonscm.debian.org/viewvc/pkg-gnome/desktop/unstable/gobject-introspection/debian/policy.txt?view=markup
-- System Information:
Debian Release: stretch/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (200, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.5.0-2-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 libfwupd1 depends on:
ii  libc6 2.22-11
ii  libglib2.0-0  2.48.1-1

libfwupd1 recommends no packages.

libfwupd1 suggests no packages.

-- no debconf information
diff --git a/debian/changelog b/debian/changelog
index 3d20da4..9cae1f9 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+fwupd (0.7.0-2) UNRELEASED; urgency=medium
+
+  * Split GObject introspection files into a separate package named
+gir1.2-fwupd-1.0.
+
+ -- Michael Biebl   Wed, 08 Jun 2016 15:25:48 +0200
+
 fwupd (0.7.0-1) unstable; urgency=medium
 
   * New upstream version (0.7.0)
diff --git a/debian/control b/debian/control
index a1ca72a..1bccec9 100644
--- a/debian/control
+++ b/debian/control
@@ -84,6 +84,7 @@ Package: libfwupd-dev
 Architecture: linux-any
 Multi-Arch: same
 Depends: libfwupd1 (= ${binary:Version}),
+ gir1.2-fwupd-1.0 (= ${binary:Version}),
  ${misc:Depends}
 Breaks: fwupd-dev (<< 0.5.4-2~)
 Replaces: fwupd-dev (<< 0.5.4-2~)
@@ -98,6 +99,21 @@ Description: development files for libfwupd
  .
  This package provides the development files for libfwupd
 
+Package: gir1.2-fwupd-1.0
+Architecture: linux-any
+Multi-Arch: same
+Depends: ${shlibs:Depends},
+ ${misc:Depends},
+ ${gir:Depends}
+Breaks: libfwupd1 (<< 0.7.0-2~)
+Replaces: libfwupd1 (<< 0.7.0-2~)
+Section: introspection
+Description: GObject introspection data for libfwupd
+ This package provides the introspection data for libfwupd.
+ .
+ It can be used by packages using the GIRepository format to generate
+ dynamic bindings.
+
 Package: libdfu-dev
 Architecture: linux-any
 Multi-Arch: same
diff --git a/debian/gir1.2-fwupd-1.0.install b/debian/gir1.2-fwupd-1.0.install
new file mode 100644
index 000..5386272
--- /dev/null
+++ b/debian/gir1.2-fwupd-1.0.install
@@ -0,0 +1 @@
+usr/lib/*/girepository-1.0/Fwupd-1.0.typelib
diff --git a/debian/libfwupd1.install b/debian/libfwupd1.install
index b1173c8..6467ff9 100644
--- a/debian/libfwupd1.install
+++ b/debian/libfwupd1.install
@@ -1,2 +1 @@
 usr/lib/*/libfwup*.so.*
-usr/lib/*/girepository-1.0/Fwup*.typelib
diff --git a/debian/rules b/debian/rules
index 1d0ef9d..8f3b293 100755
--- a/debian/rules
+++ b/debian/rules
@@ -13,7 +13,7 @@ ifeq "1.2.12" "$(word 1, $(sort 1.2.12 $(COLORHUG_VERSION)))"
 endif
 
 %:
-	dh $@ --with autoreconf
+	dh $@ --with autoreconf,gir
 
 override_dh_autoreconf:
 	NOCONFIGURE=1 dh_autoreconf ./autogen.sh

Bug#826734: mh_install doesn't work with dh-exec

[Emmanuel Bourg]

Le 8/06/2016 à 15:18, Ondřej Surý a écrit :

> java/lib/icepatch2-3.6.2.pom --artifact=java/lib/icepatch2-3.6.2.jar
> java/lib/glacier2-3.6.2.pom --artifact=java/lib/glacier2-3.6.2.jar
> java/lib/freeze-3.6.2.pom --artifact=java/lib/freeze-3.6.2.jar

Thank you for the example. mh_install supports wildcards for the
--artifact parameter. You can write something like this:

path/to/pom.xml --artifact=lib/foo-*.jar

But this won't work with your example since the path of the pom also
contains the version number.

I'm not sure we can easily interface mh_install with dh-exec, but it
should be possible to teach him to expand the environment variables.

Emmanuel Bourg

Bug#826739: transition: libconfuse

[Michael Biebl]

Am 08.06.2016 um 15:12 schrieb Aurelien Jarno:
> control: forcemerge 826593 -1
> 
> On 2016-06-08 15:03, Michael Biebl wrote:
>> Package: release.debian.org
>> Severity: normal
>> User: release.debian@packages.debian.org
>> Usertags: transition
>>
>> Hi release team,
>>
>> looks like there was an uncoordinated library transition when libconfuse
>> 3.0 was uploaded to unstable bumping the soname.
> 
> This transition has been acknowledged by a release team member in bug
> #826593. Merging the bugs.

Oops, my bad. I didn't see any binNMUs scheduled and and my search for
libconfuse didn't turn up any hits.

Sorry for the noise.

Michael


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



signature.asc
Description: OpenPGP digital signature

Bug#826717: firefox: Native notifications no longer working after upgrade

[Matthew Gabeler-Lee]

Package: firefox
Version: 46.0.1-1+b1
Followup-For: Bug #826717

This is A OK with me, because the GNOME notifications didn't work most of
the time.  With some websites (Google Calendar for one), it was 100%
failure.  I believe I found a page somewhere where someone had tracked it
down to a problem with notifications that gave a custom image URL that
required traversing an HTTP 302 redirect to retrieve the actual image.

This was a common enough bug that there's this add-on:
https://addons.mozilla.org/en-US/firefox/addon/no-native-notifications/

Bug#826741: tcl nonblocking "gets" has serious spinning bug [and 2 more messages]

[Ian Jackson]

Control: found -1 8.6.2+dfsg-2

Ian Jackson writes ("tcl nonblocking "gets" has serious spinning bug"):
> Package: libtcl8.6
> Version: 8.6.2+dfsg-2+iwj1
> Tags: + fixed-upstream
> Control: fixed -1 8.6.5+dfsg-2

The version number there was c&p from the actual version I had on my
test setup, of course.  But it was a private build with some extra
debugging.

I have reinstalled the stock jessie tcl8.6 (which is where the problem
first occurred in a production daemon) and repro'd the problem using
the small test script.

Thanks,
Ian.

Bug#826205: Please move /lib/init/{vars.sh, init-d-script} to sysv-rc -- NMUed

[Martin Pitt]

Martin Pitt [2016-06-04  0:30 +0200]:
> Attached git formatted patch does that.

I pushed this to git now, and NMUed to DELAYED/5. If/when this lands,
I'll push the release changelog/tag to git too.

Thanks,

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

Bug#825937: sysvinit-utils: Please drop startpar dependency -- NMUed

[Martin Pitt]

Hello all,

Martin Pitt [2016-06-04  0:35 +0200]:
> Note that I'd like to NMU this together with bug #826205. While this
> is just cleanup, #826205 is to avoid breakage once procps gets
> uploaded and initscripts' priority gets dropped so that it drops from
> the default install.

I pushed this to git now, and NMUed to DELAYED/5. If/when this lands,
I'll push the release changelog/tag to git too.

Thanks,

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

Bug#791907: [Pkg-sysvinit-devel] Bug#791907: bootlogd RC bug now on my radar.

[Martin Pitt]

Andreas Henriksson [2016-05-25 16:02 +0200]:
> Thanks for looking at this! I've pushed the changes to pkg-sysvinit git.
> Hopefully someone comes along and does an upload soon, but otherwise
> I might just go ahead with a NMU after a while to get these bug reports
> off my RC bug radar

I NMUed this change together with #826205 and #825937 to DELAYED/5.
I'll push the corresponding release commit/tags if/when this lands.

Thanks,

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

Bug#825658: [Pkg-xfce-devel] Bug#825658: Bug#825658: release.debian.org: XFWM4 Compositor Issue - Patches released for LightDM-GTK-Greeter and XFWM4

[Jeff Mills]

Yves,
The lightdm-gtk-greeter patch is:
https://bugs.launchpad.net/xfwm4/+bug/1232804/+attachment/3899352/+files
/xsetroot.patch
Not sure if this is of any use to you.
The Xfwm unified commit here:
https://github.com/ali1234/xfwm4/commit/b7baa7aa60cdb80759e0872d0ab5a7cb
59ec5c10
The above link was from the xfwm4 email here:
https://mail.xfce.org/pipermail/xfce4-dev/2013-November/030529.html
If none of that helps I am really at a loss here, and maybe that
the Xubuntu package of xfwm was the only package that applied the fix.
Sorry to waste your time.
On Mon, 2016-06-06 at 21:28 +0200, Yves-Alexis Perez wrote:
> On dim., 2016-06-05 at 18:00 +1000, Jeff Mills wrote:
> > Not sure you got my last reply.  By upstream do you mean patched
> > released packages?
> 
> At least committed in upstream repository.
> 
> > If so I am aware that the package has been updated in Xubuntu 16.04,
> > this is a link to the related issue on Xfce4 Forum:
> > https://forum.xfce.org/viewtopic.php?id=10859
> > Patch log for Xfwm4 in the change logs here:
> > Xfwm4
> > http://changelogs.ubuntu.com/changelogs/pool/universe/x/xfwm4/xfwm4_
> > 4.12
> > .3-1ubuntu2/changelog
> > I could not find a patch entry for the LightDM-gtk-greeter package.
> > Hoping this is what you need.
> 
> Unfortunately those links are not exploitable. It's random mess of
> people
> saying “me too” here and there, which I don't have time to review.
> 
> If you want something to be fixed, please provide a simple, unique
> link, for
> each issue, pointing to a tested patch, preferably vetted by upstream.
> 
> Regards,
-- 
Regards

Jeff Mills @ QuartzDev.Net

Bug#745615: dcraw maintenance

[Filip Hroch]

Hi Laszlo,

thank you for your worry about dcraw. I've prepared
dcraw update (Jasper is removed from dependencies,
upstream version is updated, CI suite is included, 
autotools improved,..) some time ago. Unfortunately, 
it is out of my capabilities to push the changes to 

 collab-maint/dcraw.git

on Alioth, because I am not a member of collab-maint 
yet. I issued of membership request a week ago
via web form on Alioth (confirmed by Mr.Streicher). 
Now, I'm waiting for acceptation.

If the request will not be accepted in a near future,
Plan B is prepared: Mr.Fros will update dcraw repository
by Mike's patch (solving the Jasper stigma).

Best regards
FH



On Wed, 2016-06-08 at 14:38 +0200, László Böszörményi (GCS) wrote:
> Hi,
> 
> I do _not_ want to step on anyone's toe, but how dcraw packaging goes?
> There's a new upstream release for three weeks, probably fixing the
> open vulnerability, CVE-2015-8366.
> Also it prevents removing Jasper which transitively causing other
> package removals. As it's a small package, updating it is easy and
> shouldn't take more than a hour or so.
> May you do it Filip or should I take it instead?
> 
> Thanks in advance,
> Laszlo/GCS

-- 
F. Hroch  e-mail, jabber: hr...@physics.muni.cz, tel.: +420549494470
Dept. of theor. physics and astrophysics, MU Brno, Kotlarska 2,CZ-611 37

Bug#826737: Please package paramiko >= 2.0 in Experimental

[Jeremy T. Bouse]

Thank you for the report Thomas; however, if you'd taken a beat to check
or even contact the maintainer (ie- me) you would have found that this
is already being worked on... That said I'm not bothering with
experimental as it's a released version of Paramiko.

https://github.com/jbouse-debian/paramiko/tree/upstream/2.0.0

On 6/8/2016 9:02 AM, Thomas Goirand wrote:
> Source: paramiko
> Version: 1.16.0-1
> Severity: normal
>
> Hi,
>
> For OpenStack Newton, I need python-paramiko >= 2.0. Nova (ie: OpenStack
> compute) requires that version. For the moment I only need it into Debian
> Experimental, until Newton is released after this summer. However, this is a
> blocking issue for me, as the API in 2.x changed, and therefore, Nova is now
> incompatible with Paramiko in Sid.
>
> Alternatively, if you don't have the time to take care of it, I can do the
> needed work, and upload to Experimental. Please let me know.
>
> Having a quick look, the below non-OpenStack packages need Paramiko:
>   Reverse Depends: ansible (2.0.2.0-1)
>   Reverse Depends: fabric (>= 1.10.2-1)
>   Reverse Depends: fdroidserver (0.6.0-2)
>   Reverse Depends: freeipa-tests (4.0.5-6+b1)
>   Reverse Depends: ganeti-2.15 (2.15.2-3)
>   Reverse Depends: jeepyb (0+20151217-1)
>   Reverse Depends: mysql-workbench (6.3.4+dfsg-3+b4)
>   Reverse Depends: obnam (1.19.1-1)
>   Reverse Depends: python-fs-plugin-sftp (0.5.4-1)
>   Reverse Depends: python-gerritlib (0.4.0+git20150319-2)
>   Reverse Depends: python-junos-eznc (1.3.1-1)
>   Reverse Depends: python-ncclient (0.4.7-1)
>   Reverse Depends: python-netmiko (0.5.1-1)
>   Reverse Depends: python-pushy (0.5.1-1.1)
>   Reverse Depends: python-pyfg (0.47-1)
>   Reverse Depends: python-roswtf (1.11.16-5)
>   Reverse Depends: python-scp (0.10.2-1)
>   Reverse Depends: python-spur (0.3.17-1)
>   Reverse Depends: python-x2go (>= 0.5.0.4-1)
>
> And here's the list of OpenStack packages that need it:
>   Reverse Depends: sftpcloudfs (0.12.2-2)
>   Reverse Depends: python-cinder (>= 2:8.0.0-4)
>   Reverse Depends: python-ironic (1:5.1.0-2)
>   Reverse Depends: python-magnum (>= 2.0.0-5)
>   Reverse Depends: python-manila (>= 1:2.0.0-4)
>   Reverse Depends: python-mistral (2.0.0-2)
>   Reverse Depends: python-rally (0.2.0-1)
>   Reverse Depends: python-nova (2:13.0.0-3)
>   Reverse Depends: python-ryu (3.30+dfsg1-2)
>   Reverse Depends: python-sahara (1:4.0.0-2)
>   Reverse Depends: python-tempest (1:12.0.0-2)
>   Reverse Depends: python-tempest-lib (0.14.0-2)
>   Reverse Depends: tempest (6-1)
>
> So, very much, we need to handle a transition here. Which is another (non-
> OpenStack) reason why we should handle a transition through Experimental. IMO,
> it'd be nice to have that transition done for Stretch.
>
> Your thoughts?
>
> Cheers,
>
> Thomas Goirand (zigo)

Bug#826734: mh_install doesn't work with dh-exec

[Ondřej Surý]

My understanding from what algernon said in IRC, it's just a matter of
using standard debhelper interface to access to debian/.poms file.

Perhaps a small dh/mh helper like this:

$ cat mh_readpoms
#!/usr/bin/perl -w
use strict;
use Debian::Debhelper::Dh_Lib;

my $package = $ARGV[0];

init();

if ($package) {
  my $file = pkgfile($package,"poms");
  if ($file) {
  my @poms=filedoublearray($file);
  foreach my $pom (@poms) {
print join(" ", @$pom) . "\n";
  }
  }
}

and do:

mh_readpoms $p | while read ...

in the main mh_install function.

This might just do the trick as filedoublearray call is needed for
dh-exec to kick-in.

Cheers,
-- 
Ondřej Surý 
Knot DNS (https://www.knot-dns.cz/) – a high-performance DNS server
Knot Resolver (https://www.knot-resolver.cz/) – secure, privacy-aware,
fast DNS(SEC) resolver

On Wed, Jun 8, 2016, at 15:28, Emmanuel Bourg wrote:
> Le 8/06/2016 à 15:18, Ondřej Surý a écrit :
> 
> > java/lib/icepatch2-3.6.2.pom --artifact=java/lib/icepatch2-3.6.2.jar
> > java/lib/glacier2-3.6.2.pom --artifact=java/lib/glacier2-3.6.2.jar
> > java/lib/freeze-3.6.2.pom --artifact=java/lib/freeze-3.6.2.jar
> 
> Thank you for the example. mh_install supports wildcards for the
> --artifact parameter. You can write something like this:
> 
> path/to/pom.xml --artifact=lib/foo-*.jar
> 
> But this won't work with your example since the path of the pom also
> contains the version number.
> 
> I'm not sure we can easily interface mh_install with dh-exec, but it
> should be possible to teach him to expand the environment variables.
> 
> Emmanuel Bourg
> 

Bug#825849: powerdns 100% CPU usage

[Markus Koschany]

On 07.06.2016 20:13, Martin wrote:
> Hi Markus,
> 
> It's a pretty basic Powerdns installation with a MySQL backend. We're
> using one cryptokey for our domain names to serve DNSSEC to the world.
> Keys are signed with RSASHA256, and Powerdns generates domain name
> specific keys using this global key on the fly.
> 
> You could start by installing the latest pdns-server and
> pdns-backend-mysql packages together with the latest libbotan package
> and see if pdns starts using 100% CPU.

Hi Martin,

I installed pdns-server and the mysql backend but apparently there are
more steps involved to reproduce the issue. Can you or Christian provide
some minimal instructions how to setup a powerdns server with DNSSEC? I
have searched for some online documentation and tutorials but without
knowing your exact setup this is rather futile.

> Upgrading libbotan doesn't break pdns instantly, only after you restart
> pdns. That probably makes sense, but, just saying.

Yes, that makes sense. The old process is still available in your memory
and must be replaced by restarting the server.

Regards,

Markus




signature.asc
Description: OpenPGP digital signature

Bug#811565: [uscan] git mode: allow for scanning repositories without tags

[Paul Wise]

On Tue, 19 Jan 2016 16:30:01 -0500 Alexandre Viau wrote:

> It does not have to be this exact versioning scheme, others can work too.

I would recommend using the output of `git describe` where there are
tags and there is no tag, act as if there were a 0 tag at the root.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#794971: lvm2: Volume group not found, unable to find LVM during boot

[Teemu Likonen]

Ertuğrul Harman [2015-08-08 23:51:11+03] wrote:

> During every boot time after a fresh installation of debian jessie, I
> get following errors after grub screen passes:
>
> Volume group "ert-debian-vg" not found.
> Skipping volume group "ert-debian-vg"
> Unable to find LVM "volume ert-debian-vg/root"
> Volume group "ert-debian-vg" not found
> Skipping volume group "ert-debian-vg"
> Unable to find LVM "volume ert-debian-vg/swap_1"
> Please unlock disk sd3_crypt:
>
> I enter my password and boot continues.

Just another user here. This cosmetic bug has always been in Debian.
LVM inside encrypted partition causes those errors.

It seems that bugs #794971 and #544651 are the same.

I guess the error message can be removed just by removing one echo
command from file /usr/share/initramfs-tools/scripts/local-top/lvm2.


signature.asc
Description: PGP signature

Bug#817798: fixed in crash 7.1.5-1

[Troy Heber]

On 2016-06-07 02:20, Juerg Haefliger wrote:


Is there anything I can help with to get this backported to Jessie?


Sorry for the delay, I have been traveling for the last three weeks and 
just didn't have much free time to do it, crash 7.1.5-1 is now in 
jessie-backports.


Troy

Bug#826744: ne: Pressing F11 after F1 or F10 produces a segmentation fault

[Alvaro Steiger]

Package: ne
Version: 2.5-1
Severity: normal

Dear Maintainer,

While in ne menu or command help and you press F11 to make gnome-terminal full
screen, ne aborts with a segmentation fault.

To reproduce:

1. Start ne
2. Press F1 or F10
3. Press F11

Thanks,
Alvaro



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

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

Versions of packages ne depends on:
ii  libc62.19-18+deb8u4
ii  libncurses5  5.9+20140913-1+b1
ii  libtinfo55.9+20140913-1+b1

Versions of packages ne recommends:
ii  ne-doc  2.5-1

ne suggests no packages.

-- no debconf information

Bug#825827: ITP: python-should-dsl -- improve readability for should-style expectations

[Gilles Dubuc]

I thought I needed this as a subdependency to package Thumbor
(#723778), but this is actually not required, as it's only for running
the tests a certain way that the debian build phase doesn't need.

Bug#825823: ITP: python-nose-focus -- decorators and nose plugin for focusing on particular tests when running nosetests

[Gilles Dubuc]

I thought I needed this as a subdependency to package Thumbor
(#723778), but this is actually not required, as it's only for running
the tests a certain way that the debian build phase doesn't need.

On Mon, May 30, 2016 at 1:38 PM, Gilles Dubuc  wrote:
> Package: wnpp
> Severity: wishlist
> Owner: Gilles Dubuc 
>
> * Package name: python-nose-focus
>   Version : 0.1.2
>   Upstream Author : Stephen Moore 
> * URL : https://github.com/delfick/nose-focus
> * License : WTFPL
>   Programming Lang: Python
>   Description : decorators and nose plugin for focusing on
> particular tests when running nosetests
>
> This provides a nice little decorator and a nose-tests switch to make
> nose only run the tests that you are focusing on right now.

Bug#825826: ITP: python-nose-of-yeti -- nose plugin that provides an RSpec inspired dsl for python

[Gilles Dubuc]

I thought I needed this as a subdependency to package Thumbor
(#723778), but this is actually not required, as it's only for running
the tests a certain way that the debian build phase doesn't need.

Bug#825892: ITP: python-nose-pattern-exclude -- nose plugin for excluding directories and files from test discovery by paths and glob patterns

[Gilles Dubuc]

I thought I needed this as a subdependency to package Thumbor
(#723778), but this is actually not required, as it's only for running
the tests a certain way that the debian build phase doesn't need.

Bug#435829: aptitude-[create|run]-state-bundle commands very annoying

[Lennart Sorensen]

On Tue, Jun 07, 2016 at 10:23:03PM +0100, Manuel A. Fernandez Montecelo wrote:
> After almost a decade, things got worse over the years after this report
> (with the binary named aptitude-curses and the now-disabled
> aptitude-gtk, etc).  I think that it's too late to address this now.
> 
> The solution is simple anyway, just adding the extra space, or creating
> aliases if the same mistakes happen too often, etc.
> 
> It's a common problem with command-line interfaces that this issues
> arise when programs / options / files change between systems, appear in
> newer versions, etc.  Even if we prevent this today, maybe tomorrow
> somebody comes up with aptitude-on-steroids and "breaks" things again.
> 
> So closing the bug now.

Well I must admit my solution was to stop using aptitude entirely and
just use apt-get.  aptitude's resolver got too noisy and annoying to
put up with years ago so it stopped being at all useful as a tool to me.

-- 
Len Sorensen

Bug#825440: [Pkg-kde-extras] Bug#825440: K3b obsolete in TEsting

[Mauro Sacchetto]

In data venerdì 27 maggio 2016 10:02:04, Dominique Dumont ha scritto:
> On Thursday 26 May 2016 23:26:55 Mauro Sacchetto wrote:
> > I don't find any reason
> > for K3b was eliminated in Testing...
> > Is it right or there ia a big mistake?
> 
> k3b was automatically removed from testing because of #807853
> 
> it will be back once the issue with ffmpeg is fixed.
> 
> All the best



Is that issue fixed n Testing too,
with the recent update of ffmpeg
at 7:3.0.2-3 versione?

thanx
ms

Bug#825828: ITP: python-pinocchio -- set of extensions to the nose unit testing framework

[Gilles Dubuc]

I thought I needed this as a subdependency to package Thumbor
(#723778), but this is actually not required, as it's only for running
the tests a certain way that the debian build phase doesn't need.

Bug#824957: Raising severities

[Lisandro Damián Nicanor Pérez Meyer]

severity 808697 serious
severity 824965 serious
severity 824957 serious
severity 824959 serious
thanks

Hi! Qt 5.6.1 has been released and we started working on it. We will first 
push it to experimental and then ask a transition slot to push it to unstable. 

Kinds regards, Lisandro.

-- 
If you realize that you are in a hole... stop digging.
  Anonimous, thanks to ScottK.

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#826745: Potential typo in debian/patches/0001-Adjust-default-paths.patch

[Alexander Kurtz]

Package: src:puppet
Version: 4.5.0-4
Severity: minor

Hi!

It seems like debian/patches/0001-Adjust-default-paths.patch contains a
small typo in line 52 [0]:

-which_dir("/var/log/puppetlabs/puppet", "~/.puppetlabs/var/log")
+which_dir("/var/log/puppet", "~/.puppetlabs/var/log")


Best regards

Alexander Kurtz

[0] 
https://anonscm.debian.org/cgit/pkg-puppet/puppet.git/tree/debian/patches/0001-Adjust-default-paths.patch#n52

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

Bug#824788: FTBFS in sid: recipe for target 'rheolef.pdf' failed

[Pierre Saramito]

Dear Sébastien Villemot,

Many thanks for your bug report.
The new upstream version rheolef-6.7 should fix it now.

Best wishes,

Pierre
--
pierre.saram...@imag.fr
Directeur de Recherche CNRS
Laboratoire Jean Kuntzmann, Grenoble, France
http://www-ljk.imag.fr/membres/Pierre.Saramito

Bug#811590: FTBFS with GCC 6: statement indented as if it were guarded by version graph

[Pierre Saramito]

Dear Martin Michlmayr,

Many thanks for your bug report.
A new upstream version rheolef-6.7 of the source package
should now compile with g++-6 and fix this bug.

Best wishes,

Pierre
--
pierre.saram...@imag.fr
Directeur de Recherche CNRS
Laboratoire Jean Kuntzmann, Grenoble, France
http://www-ljk.imag.fr/membres/Pierre.Saramito

Bug#825112: (no subject)

[Barry Warsaw]

On Jun 08, 2016, at 10:23 AM, Gordon Ball wrote:

>I don't see anything locally, but I do see it when uploading a binary
>package to mentors.d.n - I'm unsure how their setup differs from
>`lintian --pedantic`. Anyway.

Interesting.  Oh well, that's why version numbers never run out. :)

>If you think it looks in good shape, let's go for an upload. Thanks for
>your time reviewing the packaging.

Awesome!  I'll upload it now.  I can't wait to start using it for real.
Thanks for all your great work.


pgpjbmCWhweSg.pgp
Description: OpenPGP digital signature

Bug#826654: libreoffice-gtk3: to little distance for single scrolling by mouse wheel

[Christoph Anton Mitterer]

Hmm, since "a while" (guess it came around or at the upgrade to 5.1) I
suffer from a similar issue:

When I scroll via mouse/touchpad, the document (e.g. a spreadsheet)
jumps around wildly, back and forth, as if the transformation from
touchpad-gesture-scroll-movement to actual document movement would be
far too sensitive.
This happens especially when I scroll (i.e. move the fingers on the
touchpad) very slow.

I just tried it with -gtk3 removed and -gtk installed, but then soffice
goes to 100% CPU when I start scrolling by touchpad and it take
extremely long till it moves for a bit.


Cheers,
Chris.

smime.p7s
Description: S/MIME cryptographic signature

Bug#435829: aptitude-[create|run]-state-bundle commands very annoying

[Manuel A. Fernandez Montecelo]

2016-06-08 15:38 GMT+01:00 Lennart Sorensen :
> On Tue, Jun 07, 2016 at 10:23:03PM +0100, Manuel A. Fernandez Montecelo wrote:
>> After almost a decade, things got worse over the years after this report
>> (with the binary named aptitude-curses and the now-disabled
>> aptitude-gtk, etc).  I think that it's too late to address this now.
>>
>> The solution is simple anyway, just adding the extra space, or creating
>> aliases if the same mistakes happen too often, etc.
>>
>> It's a common problem with command-line interfaces that this issues
>> arise when programs / options / files change between systems, appear in
>> newer versions, etc.  Even if we prevent this today, maybe tomorrow
>> somebody comes up with aptitude-on-steroids and "breaks" things again.
>>
>> So closing the bug now.
>
> Well I must admit my solution was to stop using aptitude entirely and
> just use apt-get.  aptitude's resolver got too noisy and annoying to
> put up with years ago so it stopped being at all useful as a tool to me.

Good solution as well, I have to admit :-)


Cheers.
-- 
Manuel A. Fernandez Montecelo 

Bug#826486: flatpak: Rhythmbox won't launch without libpython3.4

[Liban Hannan]

I can't reproduce this error with Flatpak 0.6.4-1:
I've uninstalled libpython3.4, and made sure there is no file at
/usr/lib/libpython3.4.
Removed and reinstalled Rhythmbox3.
Rhythmbox3 launches without errors.

So as far as I can tell the issue is fixed :)

On Mon, Jun 6, 2016 at 10:23 PM, Simon McVittie  wrote:

> On Sun, 05 Jun 2016 at 19:51:11 +0100, Liban Hannan wrote:
> > After installing libpython3.4 through apt, Rhythmbox3 launches
> successfully.
> >
> > However, my understanding is that a flatpak app shouldn't require extra
> > dependencies.
>
> I'm a little surprised this is even possible - it's unexpected for a
> Flatpak
> app to be able to see the system-wide copy of Python at all, never mind
> requiring it.
>
> I'll look into this soon and work out whether it's a Flatpak bug or a
> bug in the upstream-distributed bundle. (Or both :-)
>
> S
>



-- 
Liban Hannan
ICT
InformAction |  +447512220348

-- 




*NOTICE:*
This email is confidential and only intended for those involved in 
InformAction (IFA) operations. If you have no significant involvement with 
the organisation’s operations this email may have been sent to you in error 
or may be unauthorised.

Accidental or unauthorised transmission of IFA’s electronic communications 
in no way constitutes permission to distribute or disclose information 
contained in those communications to accidental or unauthorised recipients.

Bug#826747: ITP: involucro -- build and deliver software with containers

[Jonas Weber]

Package: wnpp
Owner: Jonas Weber 
Severity: wishlist

* Package name : involucro
  Version : 1.0.2-1
  Upstream Author : Jonas Weber 
* URL : https://github.com/thriqon/involucro
* License : Apache-2.0
  Programming Lang: Go
  Description : build and deliver software with containers

 Building and delivering software is a complex task that can be made
 easier with proper encapsulation: Containers. They are able to pack all
 required dependencies (bitwise version controlled) so that you can
 release code with the confidence that everything works the same way it
 worked on the developers machine. Involucro makes invocation and
 creation of images as painless as possible, enabling reproducible
 software builds.

Involucro is a custom client for the Docker engine. It is used to manage
containers orchestrated by a workflow script, for example to build
software
from source using containerized compilers.

The software is used by some projects already, and more are ready to
pick it up. But for that to happen it needs to get visibility.

I'm going to maintain this by myself. Since I'm the original author
myself, there is no time lost in communication. Of course, I'm always
happy to receive contributions, both in packaging and in upstream code.