Bug#814577: nemiver: Local variables not shown

[Anders Andersson]

Package: nemiver
Version: 0.9.6-1+b1
Severity: normal

Dear Maintainer,

After installing and starting Nemiver, I can't find the local variables
pane anywhere.

I created a small test program which I compiled like this:
gcc -O0 -ggdb -o hello hello.c

Then I started nemiver:
nemiver ./hello

I expected to find a pane or tab listing all the variables in scope.
Quoting from the help file which I get if I press F1:

"Nemiver displays a list of all local variables in the Variables tab
 of the Status Notebook."

There is no such thing as a Variables tab. The closest I can find is the
"Expression Monitor", which has two entries: "In scope expressions" and
"Out of scope expressions". Both are empty.

I posted a screenshot of what I'm seeing here:

http://i.imgur.com/B0CUgJF.png

Hovering with the mouse over the variable called "accumulator" causes a
popup window to appear, with the correct value, indicating that Nemiver
indeed knows about this variable. Using this popup window is however
much too slow to be of any use for debugging.

Kind regards,
Anders





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

Kernel: Linux 4.3.0-1-amd64 (SMP w/4 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 nemiver depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.24.0-2
ii  gdb  7.10-1+b1
ii  gsettings-desktop-schemas3.18.1-1
ii  libatk1.0-0  2.18.0-1
ii  libatkmm-1.6-1v5 2.24.2-1
ii  libc62.21-7
ii  libcairo-gobject21.14.6-1
ii  libcairo21.14.6-1
ii  libcairomm-1.0-1v5   1.12.0-1
ii  libgcc1  1:5.3.1-8
ii  libgdk-pixbuf2.0-0   2.32.3-1.2
ii  libglib2.0-0 2.46.2-3
ii  libglibmm-2.4-1v52.46.3-1
ii  libgnutls30  3.4.9-2
ii  libgtk-3-0   3.18.7-1
ii  libgtkhex-3-03.18.0-1
ii  libgtkmm-3.0-1v5 3.18.0-1
ii  libgtksourceview-3.0-1   3.18.2-1
ii  libgtksourceviewmm-3.0-0v5   3.18.0-1
ii  libgtop-2.0-10   2.32.0-1
ii  libpango-1.0-0   1.38.1-1
ii  libpangocairo-1.0-0  1.38.1-1
ii  libpangomm-1.4-1v5   2.38.1-1
ii  libsigc++-2.0-0v52.6.2-1
ii  libsqlite3-0 3.10.2-1
ii  libstdc++6   5.3.1-8
ii  libvte-2.91-00.42.3-1
ii  libxml2  2.9.3+dfsg1-1
ii  zlib1g   1:1.2.8.dfsg-2+b1

nemiver recommends no packages.

nemiver suggests no packages.

-- no debconf information

Bug#814576: gosa-desktop: Uninstallable due to missing /etc/gosa/

[Petter Reinholdtsen]

Package: gosa-desktop
Version: 2.7.4+reloaded2-8
Severity: serious

As can be seen from
https://jenkins.debian.net/job/chroot-installation_sid_install_education-workstation/468/console
 >,
the new version of gosa-desktop fail to install with this error:


  Setting up gosa-desktop (2.7.4+reloaded2-8) ...
  /var/lib/dpkg/info/gosa-desktop.postinst: 12: 
/var/lib/dpkg/info/gosa-desktop.postinst: cannot create /etc/gosa/desktoprc: 
Directory nonexistent
  dpkg: error processing package gosa-desktop (--configure):
   subprocess installed post-installation script returned error exit status 2
  Setting up gperiodic (2.0.10-7) ...

Setting severity to serious as this make the package uninstallable.

-- 
Happy hacking
Petter Reinholdtsen

Bug#813256: [cc74879] Fix for Bug#813256 committed to git

[Salvatore Bonaccorso]

Hi,

To reproduce:

$ cat >/tmp/t.l <

Bug#814575: python-csvkit: package does not install CLI utilities properly

[Matthew Hall]

Package: python-csvkit
Severity: important

The python-csvkit package fails to install these critical utilities into 
/usr/bin. Because csvkit is primarily intended for CLI data analysis, it 
renders the package essentially useless. When the package is installed from 
pip, the utilities are placed into /usr/local/bin and the package is usable.

/usr/lib/python2.7/dist-packages/csvkit/utilities/csvstat.py
/usr/lib/python2.7/dist-packages/csvkit/utilities/csvstack.py
/usr/lib/python2.7/dist-packages/csvkit/utilities/csvsql.py
/usr/lib/python2.7/dist-packages/csvkit/utilities/csvjson.py
/usr/lib/python2.7/dist-packages/csvkit/utilities/csvsort.py
/usr/lib/python2.7/dist-packages/csvkit/utilities/sql2csv.py
/usr/lib/python2.7/dist-packages/csvkit/utilities/in2csv.py
/usr/lib/python2.7/dist-packages/csvkit/utilities/csvpy.py
/usr/lib/python2.7/dist-packages/csvkit/utilities/csvclean.py
/usr/lib/python2.7/dist-packages/csvkit/utilities/csvgrep.py
/usr/lib/python2.7/dist-packages/csvkit/utilities/csvformat.py
/usr/lib/python2.7/dist-packages/csvkit/utilities/csvlook.py
/usr/lib/python2.7/dist-packages/csvkit/utilities/csvcut.py
/usr/lib/python2.7/dist-packages/csvkit/utilities/csvjoin.py

Since I prefer using the Debian Python package items when possible for 
elegance and simplicity I thought it was important to report this issue.

Sincerely,
Matthew.

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

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

Bug#768772: What is the status of the packaging ‘xkcdpass’?

[Ben Finney]

Howdy Dmitry,

On 13-Feb-2016, Dmitry Smirnov wrote:
> 
> I shall be happy to upload for you but few corrections are to be
> made first:

Thank you for the offer! I'm happy to work with you to get this
package ready.


For the changes you describe:

>  * changelog: let's upload to "unstable" instead of "experimental".

Done now. “experimental” was IIRC only chosen because at the time of
that package release, Jessie was in freeze.

>  * New upstream release: let's package it please. There are only 10
> different files comparing to currently packaged version so there
> should not be much of an effort to update the packaging.

Yes, that's my plan. I have begun work on packaging the newer
upstream, and also using Pybuild properly and other packaging
improvements.


>  * changelog: please replace "Closes: bug#768772" with "Closes:
> #768772" (I'm not too sure if "bug#768772" works but as far as I can
> tell this notation is unusual.

I prefer to follow the Policy §4.4 recommendation (“[…] by including
the string: closes: Bug#n in the change details.”).

This is partly because it is the Policy recommendation, and partly
because “Bug#n” is more explicit and reads better IMO.


>  * rules: Ben, please move your copyright attribution to
> "debian/copyright". The latter should mention licensing for debian
> packaging.

Even if the license conditions are deliberately the same as the
“Files: *” paragraph? I thought one good reason to choose to grant
license on ‘debian/*’ the same as the upstream work, was to not need
those exceptions described.

>  * rules: optional targets "get-(packaged-)orig-source" are
> redundant and merely invoke `uscan`.

The ‘get-orig-source’ is strongly recommended by Debian Policy §4.9,
so I don't think it's a good idea to remove it until Policy no longer
has that clause.

The ‘get-packaged-orig-source’ is needed because the Policy-conformant
‘get-orig-source’ behaviour doesn't match what most people expect (and
the way ‘foo-buildpackage’ expects).

So until Policy drops that recommendation, I'd prefer to keep those
targets in order to conform with Policy as much as feasible.


>  * control: Vcs links do not work.

Thanks, I will fix this in the next release.

> I'd very much like if you could consider converting repository to
> Git.

Good, that's a medium-term goal. I learned Git only recently and most
of my packages are maintained in Bazaar still.

I do plan to migrate them all to Git once I have a better handle on
the changes to the packaging workflow.

I am learning steadily with my packaging work on ‘dput’, which already
uses a Git repository. Perhaps you can sponsor my work on that too?

-- 
 \  “Begin with false premises and you risk reaching false |
  `\   conclusions. Begin with falsified premises and you forfeit your |
_o__)  authority.” —Kathryn Schulz, 2015-10-19 |
Ben Finney 


signature.asc
Description: PGP signature

Bug#812838: docker.io: please package 1.9.0 or later

[Michael D]

Sorry about the subject, not really familiar with replying to a bug that
isn't already in my mailbox.

I'll take a look at the packaging process. Since upstream already produces
Debian packages, it can't be too difficult to apply the Debian changes.
On 13 Feb 2016 18:00, "Dmitry Smirnov"  wrote:

> On Sat, 13 Feb 2016 06:15:34 AM Michael D wrote:
> > Seconding this, 1.10.1 was just released. Quite disappointing to see the
> > Debian packages so far behind :(
>
> Please be patient or consider helping us. Every new release of Docker is
> quite disruptive as every we have to package heaps of its new dependencies
> as
> well as to update existing ones. Docker is still young and rapidly changing
> software...
>
> P.S. Please maintain meaningful subject.
> P.P.S. I'm sure maintainers would appreciate sponsorship for their efforts.
>
> --
> Cheers,
>  Dmitry Smirnov.
>
> ---
>
> Good luck happens when preparedness meets opportunity.
>

Bug#814574: hugin: [testing] fails to start (error while loading shared libraries: libvigraimpex.so.6)

[Andreas Metzler]

Package: hugin
Version: 2015.0.0+dfsg-1+b1
Severity: serious
Tags: jessie

Hello,

I am submitting this for documentation purposes, it cannot be fixed on
hugin's side:

hugin in testing currently fails to run:
hugin: error while loading shared libraries: libvigraimpex.so.6: cannot
open shared object file: No such file or directory

The reason for this is  - The new
libvigraimpex version has a soname bump, but the package name was not
changed and the package dependencies are incorrect.

What is broken:
hugin/testing (2015.0.0+dfsg-1+b1) + libvigraimpex5v5/testing
(1.10.0+dfsg-11)

Sid users will not experience this issue.

Best workaround for testing users:
Upgrade to hugin 2016.0.0~beta1+dfsg-1 from experimental which was
built against the older non-broken libvigraimpex.

cu Andreas

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

Bug#814511: tupi: Please package new upstream version

[Dmitry Smirnov]

On Fri, 12 Feb 2016 12:26:49 PM Kristof Csillag wrote:
> A new version of Tupi has been released. See here:
> 
>   http://www.maefloresta.com/portal/node/791
> 
> It would be great the the package could be updated.

Thanks for reminder. I'm uploading package right now.
Please consider helping to maintain it. ;)

-- 
Cheers,
 Dmitry Smirnov.

---

Truth — Something somehow discreditable to someone.
-- H. L. Mencken, 1949


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

Bug#813782: python-matplotlib-venn: FTBFS: [failed test] Intersection with the arc along the same circle (which means infinitely many points usually) is reported as no intersection at all.

[Andreas Tille]

Hi,

as you can read below,  one test of the test suite fails.  As far as I
can see it is possibly a rounding issue rather than a failure.  I wonder
how the test could be tweaked to pass successfully if you share my
opinion or what else could be done to pass the test suite successfully.

Kind regards

 Andreas.

On Fri, Feb 05, 2016 at 09:37:32AM +0100, Chris Lamb wrote:
> Source: python-matplotlib-venn
> Version: 0.11-2
> Severity: serious
> 
> Dear Maintainer,
> 
> python-matplotlib-venn fails to build from source in unstable/amd64:
> 
>   [..]
> 
>   running test
>   running egg_info
>   creating matplotlib_venn.egg-info
>   writing requirements to matplotlib_venn.egg-info/requires.txt
>   writing matplotlib_venn.egg-info/PKG-INFO
>   writing top-level names to matplotlib_venn.egg-info/top_level.txt
>   writing dependency_links to matplotlib_venn.egg-info/dependency_links.txt
>   writing manifest file 'matplotlib_venn.egg-info/SOURCES.txt'
>   warning: manifest_maker: standard file 'setup.py' not found
>   
>   reading manifest file 'matplotlib_venn.egg-info/SOURCES.txt'
>   writing manifest file 'matplotlib_venn.egg-info/SOURCES.txt'
>   running build_ext
>   = test session starts 
> ==
>   platform linux2 -- Python 2.7.11, pytest-2.8.5, py-1.4.31, pluggy-0.3.1 -- 
> /usr/bin/python2.7
>   cachedir: ../../../.cache
>   rootdir: 
> /home/lamby/temp/cdt.20160205085405.L1EHTA93Fx/python-matplotlib-venn-0.11, 
> inifile: setup.cfg
>   collecting ... collected 49 items
>   
>   matplotlib_venn/_arc.py::matplotlib_venn._arc.Arc.__init__ PASSED
>   matplotlib_venn/_arc.py::matplotlib_venn._arc.Arc.angle_as_point PASSED
>   ...
>   matplotlib_venn/_venn3.py::matplotlib_venn._venn3.venn3 PASSED
>   matplotlib_venn/_venn3.py::matplotlib_venn._venn3.venn3_circles PASSED
>   
>   === FAILURES 
> ===
>   ___ [doctest] matplotlib_venn._arc.Arc.intersect_arc 
> ___
>   339 Intersection with the arc along the same circle (which means 
> infinitely many points usually) is reported as no intersection at all.
>   340 
>   341 >>> a = Arc((0, 0), 1, -90, 90, True)
>   342 >>> a.intersect_arc(Arc((1, 0), 1, 90, 270, True))
>   343 [array([ 0.5  , -0.866...]), array([ 0.5  ,  0.866...])]
>   344 >>> a.intersect_arc(Arc((1, 0), 1, 90, 180, True))
>   345 [array([ 0.5  ,  0.866...])]
>   346 >>> a.intersect_arc(Arc((1, 0), 1, 121, 239, True))
>   347 []
>   348 >>> a.intersect_arc(Arc((1, 0), 1, 120, 240, True))
>   Expected:
>   [array([ 0.5  , -0.866...]), array([ 0.5  ,  0.866...])]
>   Got:
>   [array([ 0.5  ,  0.8660254])]
>   
>   
> /home/lamby/temp/cdt.20160205085405.L1EHTA93Fx/python-matplotlib-venn-0.11/.pybuild/pythonX.Y_2.7/build/matplotlib_venn/_arc.py:348:
>  DocTestFailure
>   = 1 failed, 48 passed in 0.51 seconds 
> ==
>   E: pybuild pybuild:274: test: plugin custom failed with: exit code=1: cp -a 
> README.rst 
> /home/lamby/temp/cdt.20160205085405.L1EHTA93Fx/python-matplotlib-venn-0.11/.pybuild/pythonX.Y_2.7/build
>  && cd 
> /home/lamby/temp/cdt.20160205085405.L1EHTA93Fx/python-matplotlib-venn-0.11/.pybuild/pythonX.Y_2.7/build
>  && python2.7 
> /home/lamby/temp/cdt.20160205085405.L1EHTA93Fx/python-matplotlib-venn-0.11/setup.py
>  test && rm README.rst
>   dh_auto_test: pybuild --test --test-pytest -i python{version} -p 2.7 --test 
> --system=custom --test-args=cp -a README.rst {home_dir}/build && cd 
> {home_dir}/build && {interpreter} 
> /home/lamby/temp/cdt.20160205085405.L1EHTA93Fx/python-matplotlib-venn-0.11/setup.py
>  test && rm README.rst --dir . returned exit code 13


-- 
http://fam-tille.de

Bug#812838: docker.io: please package 1.9.0 or later

[Dmitry Smirnov]

On Sat, 13 Feb 2016 06:15:34 AM Michael D wrote:
> Seconding this, 1.10.1 was just released. Quite disappointing to see the
> Debian packages so far behind :(

Please be patient or consider helping us. Every new release of Docker is 
quite disruptive as every we have to package heaps of its new dependencies as 
well as to update existing ones. Docker is still young and rapidly changing 
software...

P.S. Please maintain meaningful subject.
P.P.S. I'm sure maintainers would appreciate sponsorship for their efforts.

-- 
Cheers,
 Dmitry Smirnov.

---

Good luck happens when preparedness meets opportunity.


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

Bug#814573: duplicity: Clarify passphrase prompt

[Daniel Shahaf]

Package: duplicity
Version: 0.7.06-1
Severity: minor
Tags: upstream patch

Dear Maintainer,

When backups are both encrypted and signed, duplicity prompts as
follows:

% duplicity --sign-key= foo file://$PWD/bar
Local and Remote metadata are synchronized, no sync needed.
Last full backup date: Sat Feb 13 06:22:53 2016
GnuPG passphrase: 
GnuPG passphrase for signing key: 

It is unclear what the purpose of the first prompt is.  (I initially
assumed it was prompting for the signing key's passphrase twice.)
Please consider the following patch:

--- a/bin/duplicity
+++ b/bin/duplicity
@@ -195,7 +195,7 @@ def get_passphrase(n, action, for_signing=False):
 if use_cache and globals.gpg_profile.passphrase:
 pass1 = globals.gpg_profile.passphrase
 else:
-pass1 = getpass_safe(_("GnuPG passphrase:") + " ")
+pass1 = getpass_safe(_("GnuPG passphrase for 
decryption:") + " ")
 
 if n == 1:
 pass2 = pass1

Thanks,

Daniel

Bug#813256: [cc74879] Fix for Bug#813256 committed to git

[Salvatore Bonaccorso]

Control: reopen -1
Control: found -1 2.6.0-1

Hi Manoj

It looks that with 2.6.0-4 and 2.6.0-6 it still generates C++ syle
comments in C output. I'm quite sure that this was not the case with
my proposed debdiff when testing (tested it while building
boxes/1.1.2-4).

If I just do a rebuild flex/2.6.0-6 on amd64 it behaves correctly, is
the amd64 build incorrect?

Regards,
Salvatore

Bug#813415: libvigraimpex5v5: soname bump without package name change

[Andreas Metzler]

On 2016-02-12 Daniel Stender  wrote:
> Sorry for the delay, a fix is coming up.

You are going for 1.11 rc1, I assume?

Is there something I can do to help? Currently reverse dependencies are
broken, due to a binNMU hugin in *testing* will not run at all.

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

Bug#813842: radcli: diff for NMU version 1.2.4-2.1

[Aron Xu]

Control: tags 813842 + patch
Control: tags 813842 + pending

Dear maintainer,

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

Regards,
Aron
diff -Nru radcli-1.2.4/debian/changelog radcli-1.2.4/debian/changelog
--- radcli-1.2.4/debian/changelog	2015-10-26 19:06:00.0 +0800
+++ radcli-1.2.4/debian/changelog	2016-02-13 14:34:18.0 +0800
@@ -1,3 +1,10 @@
+radcli (1.2.4-2.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Install radcli.pc (Closes: #813842)
+
+ -- Aron Xu   Sat, 13 Feb 2016 14:33:25 +0800
+
 radcli (1.2.4-2) unstable; urgency=high
 
   * Does not conflict with libfreeradius-client2
diff -Nru radcli-1.2.4/debian/libradcli-dev.install radcli-1.2.4/debian/libradcli-dev.install
--- radcli-1.2.4/debian/libradcli-dev.install	2015-10-23 00:59:55.0 +0800
+++ radcli-1.2.4/debian/libradcli-dev.install	2016-02-13 14:34:31.0 +0800
@@ -1,3 +1,4 @@
 usr/include/*
 usr/lib/*/lib*.a
 usr/lib/*/lib*.so
+usr/lib/*/pkgconfig/radcli.pc


signature.asc
Description: Digital signature

Bug#814572: Please print information output to stderr

[Erik de Castro Lopo]

Package: wine
Version: 1.8.1-1
Severity: normal

Wrapper scripts like /usr/bin/wineserver print informational
info to stdout instead of stderr.

My main usecase for Wine is to run program test suites when I
cross compile from Linux to Windows. Having these informational
messages on stdout and then having to remove them in my test
suite is inconvienient. If instead these messages were on stderr
I could just pipe stderr to /dev/null. In addition, I would be 
able to do it once in the test wrapper script instead of having
to deal with each program output separately.

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

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

Versions of packages wine depends on:
ii  wine32  1.8.1-1
ii  wine64  1.8.1-1

wine recommends no packages.

Versions of packages wine suggests:
pn  dosbox   
pn  wine-binfmt  

Versions of packages wine is related to:
ii  fonts-wine1.8.1-1
ii  libwine   1.8.1-1
pn  libwine-dbg   
pn  libwine-dev   
ii  wine  1.8.1-1
ii  wine321.8.1-1
pn  wine32-preloader  
pn  wine32-tools  
ii  wine641.8.1-1
pn  wine64-preloader  
pn  wine64-tools  

-- no debconf information

-- debsums errors found:
debsums: changed file /usr/bin/wine (from wine package)

Bug#812401: cpio: diff for NMU version 2.11+dfsg-4.2

[Salvatore Bonaccorso]

Control: tags 812401 + pending

Hi Anibal,

I've prepared an NMU for cpio (versioned as 2.11+dfsg-4.2) and uploaded
it to DELAYED/2. Please feel free to tell me if I should delay it longer
or cancel it if you would like to do it yourself. I choosed to upload to
DELAYED/2 instead of DELAYED/5 since you seem to be listed on LowNMU.

Regards,
Salvatore
diff -Nru cpio-2.11+dfsg/debian/changelog cpio-2.11+dfsg/debian/changelog
--- cpio-2.11+dfsg/debian/changelog	2015-03-05 11:47:10.0 +0100
+++ cpio-2.11+dfsg/debian/changelog	2016-02-13 07:15:04.0 +0100
@@ -1,3 +1,10 @@
+cpio (2.11+dfsg-4.2) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * CVE-2016-2037: 1-byte out-of-bounds write (Closes: #812401)
+
+ -- Salvatore Bonaccorso   Sat, 13 Feb 2016 06:53:01 +0100
+
 cpio (2.11+dfsg-4.1) unstable; urgency=medium
 
   * Apply patch by Vitezslav Cizek of SuSE to fix CVE-2015-1197.
diff -Nru cpio-2.11+dfsg/debian/patches/CVE-2016-2037.patch cpio-2.11+dfsg/debian/patches/CVE-2016-2037.patch
--- cpio-2.11+dfsg/debian/patches/CVE-2016-2037.patch	1970-01-01 01:00:00.0 +0100
+++ cpio-2.11+dfsg/debian/patches/CVE-2016-2037.patch	2016-02-13 07:15:04.0 +0100
@@ -0,0 +1,44 @@
+Description: fix 1-byte out-of-bounds write (CVE-2016-2037)
+ Other calls to cpio_safer_name_suffix seem to be safe.
+ .
+ * src/copyin.c (process_copy_in):  Make sure that file_hdr.c_name
+ has at least two bytes allocated.
+ * src/util.c (cpio_safer_name_suffix): Document that use of this
+ function requires to be careful.
+Origin: upstream, https://lists.gnu.org/archive/html/bug-cpio/2016-01/msg5.html
+Bug-Debian: https://bugs.debian.org/812401
+Forwarded: not-needed
+Author: Pavel Raiskup 
+Reviewed-by: Salvatore Bonaccorso 
+Last-Update: 2016-02-12
+
+---
+ src/copyin.c | 2 ++
+ src/util.c   | 5 -
+ 2 files changed, 6 insertions(+), 1 deletion(-)
+
+--- a/src/copyin.c
 b/src/copyin.c
+@@ -1433,6 +1433,8 @@ process_copy_in ()
+ 	  break;
+ 	}
+ 
++  if (file_hdr.c_namesize <= 1)
++file_hdr.c_name = xrealloc(file_hdr.c_name, 2);
+   cpio_safer_name_suffix (file_hdr.c_name, false, !no_abs_paths_flag,
+ 			  false);
+   
+--- a/src/util.c
 b/src/util.c
+@@ -1374,7 +1374,10 @@ set_file_times (int fd,
+ }
+ 
+ /* Do we have to ignore absolute paths, and if so, does the filename
+-   have an absolute path?  */
++   have an absolute path?
++   Before calling this function make sure that the allocated NAME buffer has
++   capacity at least 2 bytes to allow us to store the "." string inside.  */
++
+ void
+ cpio_safer_name_suffix (char *name, bool link_target, bool absolute_names,
+ 			bool strip_leading_dots)
diff -Nru cpio-2.11+dfsg/debian/patches/series cpio-2.11+dfsg/debian/patches/series
--- cpio-2.11+dfsg/debian/patches/series	2015-03-05 11:49:50.0 +0100
+++ cpio-2.11+dfsg/debian/patches/series	2016-02-13 07:15:04.0 +0100
@@ -17,3 +17,4 @@
 fd262d11.patch
 f6a8a2cb.patch
 CVE-2015-1197.patch
+CVE-2016-2037.patch

Bug#814571: python-setuptools-whl and python-pip-whl: error when trying to install together

[Ralf Treinen]

Package: python-pip-whl,python-setuptools-whl
Version: python-pip-whl/8.0.2-6
Version: python-setuptools-whl/20.0-2
Severity: serious
User: trei...@debian.org
Usertags: edos-file-overwrite

Date: 2016-02-13
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 python-pip-whl.
(Reading database ... 10940 files and directories currently installed.)
Preparing to unpack .../python-pip-whl_8.0.2-6_all.deb ...
Unpacking python-pip-whl (8.0.2-6) ...
Selecting previously unselected package python-setuptools-whl.
Preparing to unpack .../python-setuptools-whl_20.0-2_all.deb ...
Unpacking python-setuptools-whl (20.0-2) ...
dpkg: error processing archive 
/var/cache/apt/archives/python-setuptools-whl_20.0-2_all.deb (--unpack):
 trying to overwrite 
'/usr/share/python-wheels/setuptools-20.0-py2.py3-none-any.whl', which is also 
in package python-pip-whl 8.0.2-6
dpkg-deb: error: subprocess paste was killed by signal (Broken pipe)
Errors were encountered while processing:
 /var/cache/apt/archives/python-setuptools-whl_20.0-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/python-wheels/setuptools-20.0-py2.py3-none-any.whl

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#812838:

[Michael D]

Seconding this, 1.10.1 was just released. Quite disappointing to see the
Debian packages so far behind :(

Bug#814570: debdiff: (minor) regression: bash completion with files not in current directory does not working

[Salvatore Bonaccorso]

Package: devscripts
Version: 2.15.10
Severity: normal

Hi

Recently (I think since 2.15.10 where bash completions were
reorganized), debdiff cannot bash complete anymore to files if they
are not in the current directory. Example

$ ls source-devscripts/devscripts_2.15.10.dsc devscripts_2.16.1.dsc 
devscripts_2.16.1.dsc  source-devscripts/devscripts_2.15.10.dsc
$ debdiff source-devscripts/

not completing.

Regards,
Salvatore

Bug#768772: What is the status of the packaging ‘xkcdpass’?

[Dmitry Smirnov]

Hi Ben,

On Sat, 13 Feb 2016 08:55:11 AM Ben Finney wrote:
> The package has been examined and it's ready for upload, but still
> needs a Debian Developer to sponsor its upload.
> 
> The initial release is now at ‘mentors.debian.net’ again, seeking a
> sponsor https://mentors.debian.net/package/xkcdpass>.
> 
> A newer upstream version exists, but the 1.2.3-1 release works fine
> now and can be uploaded without further work. Do you know a Debian
> Developer who can help?

I shall be happy to upload for you but few corrections are to be made first:

 * changelog: let's upload to "unstable" instead of "experimental".

 * changelog: please replace "Closes: bug#768772" with "Closes: #768772" (I'm 
not too sure if "bug#768772" works but as far as I can tell this notation is 
unusual.

 * control: Vcs links do not work. I'd very much like if you could consider 
converting repository to Git.

 * rules: Ben, please move your copyright attribution to "debian/copyright". 
The latter should mention licensing for debian packaging.

 * rules: optional targets "get-(packaged-)orig-source" are redundant and 
merely invoke `uscan`. Since those targets don't do anything useful on top of 
what `uscan` does I recommend to remove those targets. I'm guessing they were 
introduced to memorise uscan parameters?

 * New upstream release: let's package it please. There are only 10 different 
files comparing to currently packaged version so there should not be much of 
an effort to update the packaging.

Thanks.

-- 
All the best,
 Dmitry Smirnov.

---

Reality is that which, when you stop believing in it, doesn't go away.
-- Philip K. Dick



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

Bug#814569: wheezy-pu: package libclamunrar/0.99-0+deb7u1

[Scott Kitterman]

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

This is the other source change required to go with clamav (#814544).  It to
has a so name bump.  Debdiff attached.

Scott K
diff -Nru libclamunrar-0.98.5/aclocal.m4 libclamunrar-0.99/aclocal.m4
--- libclamunrar-0.98.5/aclocal.m4	2014-11-18 16:22:36.0 -0500
+++ libclamunrar-0.99/aclocal.m4	2015-12-03 15:26:49.0 -0500
@@ -1,6 +1,6 @@
-# generated automatically by aclocal 1.14.1 -*- Autoconf -*-
+# generated automatically by aclocal 1.15 -*- Autoconf -*-
 
-# Copyright (C) 1996-2013 Free Software Foundation, Inc.
+# Copyright (C) 1996-2014 Free Software Foundation, Inc.
 
 # This file is free software; the Free Software Foundation
 # gives unlimited permission to copy and/or distribute it,
@@ -20,7 +20,283 @@
 If you have problems, you may need to regenerate the build system entirely.
 To do so, use the procedure documented by the package, typically 'autoreconf'.])])
 
-# Copyright (C) 2002-2013 Free Software Foundation, Inc.
+dnl pkg.m4 - Macros to locate and utilise pkg-config.   -*- Autoconf -*-
+dnl serial 11 (pkg-config-0.29)
+dnl
+dnl Copyright © 2004 Scott James Remnant .
+dnl Copyright © 2012-2015 Dan Nicholson 
+dnl
+dnl This program is free software; you can redistribute it and/or modify
+dnl it under the terms of the GNU General Public License as published by
+dnl the Free Software Foundation; either version 2 of the License, or
+dnl (at your option) any later version.
+dnl
+dnl This program is distributed in the hope that it will be useful, but
+dnl WITHOUT ANY WARRANTY; without even the implied warranty of
+dnl MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+dnl General Public License for more details.
+dnl
+dnl You should have received a copy of the GNU General Public License
+dnl along with this program; if not, write to the Free Software
+dnl Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA
+dnl 02111-1307, USA.
+dnl
+dnl As a special exception to the GNU General Public License, if you
+dnl distribute this file as part of a program that contains a
+dnl configuration script generated by Autoconf, you may include it under
+dnl the same distribution terms that you use for the rest of that
+dnl program.
+
+dnl PKG_PREREQ(MIN-VERSION)
+dnl ---
+dnl Since: 0.29
+dnl
+dnl Verify that the version of the pkg-config macros are at least
+dnl MIN-VERSION. Unlike PKG_PROG_PKG_CONFIG, which checks the user's
+dnl installed version of pkg-config, this checks the developer's version
+dnl of pkg.m4 when generating configure.
+dnl
+dnl To ensure that this macro is defined, also add:
+dnl m4_ifndef([PKG_PREREQ],
+dnl [m4_fatal([must install pkg-config 0.29 or later before running autoconf/autogen])])
+dnl
+dnl See the "Since" comment for each macro you use to see what version
+dnl of the macros you require.
+m4_defun([PKG_PREREQ],
+[m4_define([PKG_MACROS_VERSION], [0.29])
+m4_if(m4_version_compare(PKG_MACROS_VERSION, [$1]), -1,
+[m4_fatal([pkg.m4 version $1 or higher is required but ]PKG_MACROS_VERSION[ found])])
+])dnl PKG_PREREQ
+
+dnl PKG_PROG_PKG_CONFIG([MIN-VERSION])
+dnl --
+dnl Since: 0.16
+dnl
+dnl Search for the pkg-config tool and set the PKG_CONFIG variable to
+dnl first found in the path. Checks that the version of pkg-config found
+dnl is at least MIN-VERSION. If MIN-VERSION is not specified, 0.9.0 is
+dnl used since that's the first version where most current features of
+dnl pkg-config existed.
+AC_DEFUN([PKG_PROG_PKG_CONFIG],
+[m4_pattern_forbid([^_?PKG_[A-Z_]+$])
+m4_pattern_allow([^PKG_CONFIG(_(PATH|LIBDIR|SYSROOT_DIR|ALLOW_SYSTEM_(CFLAGS|LIBS)))?$])
+m4_pattern_allow([^PKG_CONFIG_(DISABLE_UNINSTALLED|TOP_BUILD_DIR|DEBUG_SPEW)$])
+AC_ARG_VAR([PKG_CONFIG], [path to pkg-config utility])
+AC_ARG_VAR([PKG_CONFIG_PATH], [directories to add to pkg-config's search path])
+AC_ARG_VAR([PKG_CONFIG_LIBDIR], [path overriding pkg-config's built-in search path])
+
+if test "x$ac_cv_env_PKG_CONFIG_set" != "xset"; then
+	AC_PATH_TOOL([PKG_CONFIG], [pkg-config])
+fi
+if test -n "$PKG_CONFIG"; then
+	_pkg_min_version=m4_default([$1], [0.9.0])
+	AC_MSG_CHECKING([pkg-config is at least version $_pkg_min_version])
+	if $PKG_CONFIG --atleast-pkgconfig-version $_pkg_min_version; then
+		AC_MSG_RESULT([yes])
+	else
+		AC_MSG_RESULT([no])
+		PKG_CONFIG=""
+	fi
+fi[]dnl
+])dnl PKG_PROG_PKG_CONFIG
+
+dnl PKG_CHECK_EXISTS(MODULES, [ACTION-IF-FOUND], [ACTION-IF-NOT-FOUND])
+dnl ---
+dnl Since: 0.18
+dnl
+dnl Check to see whether a particular set of modules exists. Similar to
+dnl PKG_CHECK_MODULES(), but does not set variables or print errors.
+dnl
+dnl Please remember that m4 expands AC_REQUIRE([PKG_PROG_PKG_CONFIG])
+dnl only at the first occurence in configure.ac, so if the first place
+dnl it's called might be skipped (such as if it is wit

Bug#811411: I Am Interested

[Gage Morgan]

I still need to set up shop on my system. I am new to the actual community, 
though I've been in the woodworks on my own for quite a bit. 
I'd like to try and maintain this package for some time if I get the chance. I 
loved this command when I used to use Ubuntu. Here's my scheduling issue:
I'm a junior in HS with divorced parents. So I am only able to do serious stuff 
every other weekend, unfortunately. But I still do have free time. One side 
doesn't care that I experiment with technology, while the other side absolutely 
hates my guts for it. 
So, with that being said, I want to contribute when I do have time. I would 
probably start a week from now. I need to go back over some of Debian's guides 
on the matter, so I will do that on my iPhone. 
Thanks in advance for understanding. :-)

Sent from Outlook Mobile

Bug#814568: cython: FTBFS [amd64]: Testsuite failure in EndToEndTest

[Daniel Schepler]

Source: cython
Version: 0.23.2+git16-ga8fbae1-1
Severity: serious

>From my pbuilder build log:

...
doublefunc (cppwrap)
Doctest: cppwrap.doublefunc ... ok
transmogrify_from_cpp (cppwrap)
Doctest: cppwrap.transmogrify_from_cpp ... ok
voidfunc (cppwrap)
Doctest: cppwrap.voidfunc ... ok
test_embed (__main__.EmbedTest) ... runtests.py:1463: DeprecationWarning: 
Please use assertTrue instead.
  "make PYTHON='%s' CYTHON='%s' LIBDIR1='%s' test > make.output" % 
(sys.executable, cython, libdir)) == 0)
ok

==
FAIL: runTest (__main__.EndToEndTest)
End-to-end asyncio_generators
--
Traceback (most recent call last):
  File "runtests.py", line 1417, in runTest
self.assertEqual(0, res, "non-zero exit status")
AssertionError: 0 != 1 : non-zero exit status

--
Ran 10022 tests in 1860.381s

FAILED (failures=1)
Following tests excluded because of missing dependencies on your system:
   Cython.Coverage
   run.coverage_api
   run.coverage_cmd
   run.coverage_nogil
ALL DONE
debian/rules:104: recipe for target 'override_dh_auto_test' failed
make[1]: *** [override_dh_auto_test] Error 1
make[1]: Leaving directory '/build/cython-0.23.2+git16-ga8fbae1'
debian/rules:20: recipe for target 'build' failed
make: *** [build] Error 2
dpkg-buildpackage: error: debian/rules build gave error exit status 2

(reproducible.debian.net is also showing the same failure.)
-- 
Daniel Schepler

Bug#814567: python-pil-doc-html

[Brian Sammon]

Package: python-pil-doc
Severity: normal

The package python-pil-doc "suggests" python-pil-doc-html.
I would like to have a such a package, but debian does not seem to provide
it.

Potential fixes , in order of preference:
1) create/build/provide a python-pil-doc-html package
2) provide a README.Debian that documents how I could build HTML docs for
   pillow
3) remove the "suggests" that references a nonexistent (I think?) package

There's a similar situation for python-pil-doc-pdf .

-- System Information:
Debian Release: 7.7
  APT prefers stable
  APT policy: (990, 'stable'), (990, 'oldstable')
Architecture: i386 (i686)

Kernel: Linux 3.16.0-4-686-pae (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
-- 
Brian Sammon 

Bug#814566: networkd >= 229-1 starts assigning IPv6 addresses/ routes to lower bridge members

[Stefan Lippers-Hollmann]

Package: systemd
Version: 229-1
Severity: normal

Hi

After upgrading from systemd 228-6 to 229-1, I'm experiencing IPv6
connectivity issues. Debugging this shows some changes in the way 
systemd-networkd (systemd-resolved is also in use) deals with bridges
and IPv6 addresses - apparently the lower bridge members (physical 
ethernet cards) suddenly get their own IPv6 addresses/ routes assigned.
This messes up the routing table (lost packets) and also causes the 
DHCPv6 address reservations to fail/ get mis-assigned.

I have attached my networkd configuration (/etc/systemd/network/) as 
network.tar.gz; all virtual bridge member definitions (tap interfaces) 
have been removed before debugging this for clarity. systemd-networkd 
is the only active networking daemon, neither ifupdown nor 
network-manager are installed on the system(s) in question.

[ I've partially obfuscated the he.net /48 prefix with '1234' instead 
  of the real one ]

My router hands out IP addresses via DHCP (10.0.0.0/8) and DHCPv6 
(he.net tunnel 2001:470:1234:10::/64 (subset of a routed /48 prefix), 
ULA prefix fd01:470:1234:10::/64), running a recent OpenWrt trunk 
snapshot (r48686) on the ar71xx platform. There is no dhcpd/ dhcpv6d
running on the subnet connected to the br1 interface, nor any route
to the outside or any other network.

systemd 228-6:
$ ip a
1: lo:  mtu 65536 qdisc noqueue state UNKNOWN group 
default 
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
   valid_lft forever preferred_lft forever
inet6 ::1/128 scope host 
   valid_lft forever preferred_lft forever
2: enp2s0:  mtu 1500 qdisc pfifo_fast master 
br0 state UP group default qlen 1000
link/ether 94:de:80:02:ca:42 brd ff:ff:ff:ff:ff:ff
inet6 fe80::96de:80ff:fe02:ca42/64 scope link 
   valid_lft forever preferred_lft forever
3: enp4s0:  mtu 1500 qdisc pfifo_fast master 
br1 state UP group default qlen 1000
link/ether 00:08:54:57:18:2c brd ff:ff:ff:ff:ff:ff
inet6 fe80::208:54ff:fe57:182c/64 scope link 
   valid_lft forever preferred_lft forever
4: br1:  mtu 1500 qdisc noqueue state UP group 
default qlen 1000
link/ether 00:08:54:57:18:2c brd ff:ff:ff:ff:ff:ff
inet 192.168.20.20/24 brd 192.168.20.255 scope global br1
   valid_lft forever preferred_lft forever
inet6 fe80::208:54ff:fe57:182c/64 scope link 
   valid_lft forever preferred_lft forever
5: br0:  mtu 1500 qdisc noqueue state UP group 
default qlen 1000
link/ether 94:de:80:02:ca:42 brd ff:ff:ff:ff:ff:ff
inet 10.10.20.0/8 brd 10.255.255.255 scope global dynamic br0
   valid_lft 43075sec preferred_lft 43075sec
inet6 fd01:470:1234:10::10:2000/128 scope global noprefixroute 
   valid_lft forever preferred_lft forever
inet6 fd01:470:1234:10:ec7c:da74:ab3e:a43/64 scope global temporary dynamic 
   valid_lft 604677sec preferred_lft 85677sec
inet6 fd01:470:1234:10:96de:80ff:fe02:ca42/64 scope global mngtmpaddr 
dynamic 
   valid_lft forever preferred_lft forever
inet6 2001:470:1234:10:ec7c:da74:ab3e:a43/64 scope global temporary dynamic 
   valid_lft 604677sec preferred_lft 85677sec
inet6 2001:470:1234:10:96de:80ff:fe02:ca42/64 scope global mngtmpaddr 
dynamic 
   valid_lft forever preferred_lft forever
inet6 fe80::96de:80ff:fe02:ca42/64 scope link 
   valid_lft forever preferred_lft forever

$ ip r
default via 10.0.0.1 dev br0  proto dhcp  src 10.10.20.0  metric 1024 
10.0.0.0/8 dev br0  proto kernel  scope link  src 10.10.20.0 
10.0.0.1 dev br0  proto dhcp  scope link  src 10.10.20.0  metric 1024 
192.168.20.0/24 dev br1  proto kernel  scope link  src 192.168.20.20

$ ip -6 r
2001:470:1234:10::/64 dev br0  proto kernel  metric 256  mtu 1424 pref medium
fd01:470:1234:10::/64 dev br0  proto kernel  metric 256  mtu 1424 pref medium
fe80::/64 dev enp2s0  proto kernel  metric 256  pref medium
fe80::/64 dev br0  proto kernel  metric 256  mtu 1424 pref medium
fe80::/64 dev enp4s0  proto kernel  metric 256  pref medium
fe80::/64 dev br1  proto kernel  metric 256  pref medium
default via fe80::92f6:52ff:fef6:c88 dev br0  proto ra  metric 1024  expires 
65480sec mtu 1424 hoplimit 64 pref medium

# systemctl status -l systemd-networkd.service 
● systemd-networkd.service - Network Service
   Loaded: loaded (/lib/systemd/system/systemd-networkd.service; enabled; 
vendor preset: enabled)
   Active: active (running) since Sa 2016-02-13 04:22:36 CET; 3min 55s ago
 Docs: man:systemd-networkd.service(8)
 Main PID: 493 (systemd-network)
   Status: "Processing requests..."
Tasks: 1 (limit: 512)
   CGroup: /system.slice/systemd-networkd.service
   └─493 /lib/systemd/systemd-networkd

Feb 13 04:22:41 poseidon systemd-networkd[493]: enp4s0: Gained IPv6LL
Feb 13 04:22:41 poseidon systemd-networkd[493]: enp4s0: Configured
Feb 13 04:22:41 poseidon systemd-networkd[493]: br1: Gained IPv6LL
Feb 13 04:22:41 poseidon systemd-networkd[493]: br1: Configured
Feb 13 04:22:42

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

[intrigeri]

Control: retitle -1 Document which AppArmor features are not support in Debian

Hi,

apparently users are confused by upstream documentation (that assumes
all out-of-tree kernel patches are applied), or by the documentation
we ship (that also advertises features we can't support with a kernel
as close to mainline as the Debian one) — not sure which of those, but
regardless, the best we can do is probably:

 * patch apparmor.d(5) to add an introduction that lists some of the
   features we can't provide on Debian, and makes it clear that the
   list may be incomplete;

 * add something in README.Debian about it.

If someone feels strongly about how making the userspace tools behave
differently, patches are welcome (but a mere warning would just get us
back to Wheezy-area, that thankfully we've escaped, so IMO the warning
should be non-scary, point to some understandable and up-to-date
documentation, and not be spammed repeatedly to the user; UX matters).

I personally would be happy enough would a purely
documentation-based solution.

Cheers,
-- 
intrigeri

Bug#814489: [Pkg-privacy-maintainers] Bug#814489: tails-installer: fails with "Could not find the 'ifcpu64.c32' COM32 module"

[intrigeri]

Control: tag -1 + pending

> The bug is that 'syslinux-common' is not in Depends list of 'tails-installer'.

Exactly, good catch!

Fixed in Git, will be 4.4.8+dfsg-1, or 4.4.7+dfsg-2 if we upload any
such thing.

Bug#668081: RFP: wmcore -- a dockapp that shows the usage of each core in the system.

[Doug Torrance]

Control: retitle -1 ITP: wmcore -- a dockapp that shows the usage of each core 
in the system.

I intend to package wmcore as a member of the Debian Window Maker Team.

Bug#814559: mk-origtargz: uscan “Successfully downloaded”, then “Can't open” the same tarball

[Ben Finney]

Control: fixed -1 devscripts/2.16.1

On 12-Feb-2016, James McCoy wrote:
> On Sat, Feb 13, 2016 at 11:37:34AM +1100, Ben Finney wrote:
> > After ‘uscan’ successfully downloads an upstream tarball file, it then
> > exits with an error complaining it can't find the file it just downloaded:
> 
> This is #809662, fixed in yesterday's 2.16.1 upload.

Confirmed, I've installed that version and now ‘uscan’ with the same
configuration happily downloads the upstream source.

Thank you for the prompt response!

-- 
 \ “Pinky, are you pondering what I'm pondering?” “I think so, |
  `\ Brain, but isn't a cucumber that small called a gherkin?” |
_o__)   —_Pinky and The Brain_ |
Ben Finney 


signature.asc
Description: PGP signature

Bug#814565: kde-full: Have to install kde-full, kde-standard dependencies manually

[Rares Marian]

Package: kde-full
Version: 5:90
Severity: important

I have to install dependencies of kde-full, kde-standard manually since 
kde-full depends on kde-standard and kde-network, which depend on number 
of applications, which depend on these:

libkabc4
libkresources4
akonadi-kde4
all version 4:4.14.10-1

which conflict with kdepimlibs-data

The apps I can't install are:
kopete
kgpg
libakonadi-kde4

Installing packages manually makes it more difficult to track what 
packages are needed or need to be upgraded.

Bug#814508: initramfs-tools: bluetooth/hci fails

[Ben Hutchings]

Control: reassign -1 src:linux 4.3.5-1

On Sat, 2016-02-13 at 02:07 +0100, Stefano Callegari wrote:
[...]
> But
> 
> I have done as follow:
> 
> 1) added 'debug' into grub;
> 
> 2) reboot with 0.122 - bluetooth ko, system setting told me 'no bluetooth
> device found', but rfkill has showed me hci0;
> 
> 3) update to 0.123 and reboot - bluetooth works!
> 
> Yesterday I have rebooted more times, before to search the problem and
> after for reportbug, but only when I had the 0.122 the bluetooth has
> worked.
> 
> So I think I have more problems...

Yes, this sounds like a bug in either the rfkill driver or the BIOS.
Check whether there's a BIOS update available that mentions fixes to
Bluetooth or flight mode.

There is also a module parameter that can be used to always force
rfkill off, which might possibly make a difference.  Try adding a .conf
file under /etc/modprobe.d containing:

    options ideapad-laptop no_bt_rfkill=1

Ben.

-- 
Ben Hutchings
Sturgeon's Law: Ninety percent of everything is crap.

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

Bug#814403: ckeditor: FTBFS: /usr/bin/ckbuilder: 2: /usr/bin/ckbuilder: Syntax error: Unterminated quoted string

[Dmitry Smirnov]

I think I've found a clue:

update-binfmts: warning: Couldn't load the binfmt_misc module.

`ckbuilder` is really a .jar file which is executable thanks to "jarwrapper":

Jarwrapper sets up binfmt-misc to run executable jar files
using the installed java runtime.

For some reason this does not work on build servers... :(

-- 
All the best,
 Dmitry Smirnov.

---

Science embraces facts and debates opinion; religion embraces opinion
and debates the facts.
-- Tom Heehler, The Well-Spoken Thesaurus.


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

Bug#814560: [Pkg-mozext-maintainers] Bug#814560: Abandoned upstream

[Dmitry Smirnov]

On Fri, 12 Feb 2016 08:42:51 PM David Prévot wrote:
> > [...] because it stopped working with the latest
> > version of Firefox.
> > 
> > It's too bad, it's a fairly useful extension.
> 
> https://github.com/kevinjacobs/HTTPS-Finder/issues/18#issuecomment-75471662
> 
> If the situation doesn’t change, there is a priori little point shipping
> it in the next stable release (Stretch). It may even stop being useful
> in the current stable release (Jessie) since iceweasel is being updated
> to more recent LTS versions once they become available (thus the current
> tags may soon be useless).
> 
> I intend to follow up with an RM request in a few months if nobody
> objects, ditto for Jessie if this add-on stop being useful (but feel
> free to beat me to it).

It is unfortunate that upstream is dormant but plugin still works (with 
Iceweasel 44.0-1) and quite useful. Please do not remove it until it stops 
working. I therefore downgraded severity of this bug.

Thanks.

P.S. Please CC to me for any updates regarding this package.

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

---

The surest way to corrupt a youth is to instruct him to hold in higher
esteem those who think alike than those who think differently.
-- Friedrich Nietzsche


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

Bug#813562: Project maintainer here

[James R Barlow]

On Fri, 12 Feb 2016 at 17:05 Sean Whitton  wrote:

> Hello,
>
> On Fri, Feb 12, 2016 at 03:23:39AM -0800, James R Barlow wrote:
> > Let me know if you'd like to see any changes to help with packaging.
>
> Thank you for your input, and for OCRmyPDF.
>
> I have a non-packaging question that I'd like to take this opportunity
> to ask you: in your changelog entry for 3.2, it's explained that the new
> "lossless reconstruction" feature is disabled by --deskew and
> --clean-final but otherwise PDF contents are now added to but not
> modified by OCRmyPDF.  I had observed that OCRmyPDF makes my PDFs much
> smaller without making them any harder to read, presumably by changing
> the content, and I rather liked this feature.  Can I turn it back on?
> Or was --clean-final doing this and turning that on would be enough?
>
>
Oh, interesting. By smaller I take it mean the file size was reduced, not
resampling of images. Any chance you can send me an example input PDF?
(Dropbox is best.)

I did increase the JPEG quality that Ghostscript uses when transcoding
JPEGs, mostly as an added safety margin, but I can make that optional.
Maybe that affects file size more than I thought.


> > If you are packaging around 3.1.1, versions older than 3.2.1 are
> > incompatible with the recently released img2pdf 0.2.0; they require
> > 0.1.5, and they do not enforce this dependency on their own.
>
> I've got a working package for 3.1 but I'm now trying to update my
> packaging for the 3.2 series before I try to find a sponsor DD to upload
> to Debian.  I'm figuring out how your change to use setuptools-scm can
> be made to work with the Debian toolchain.
>
>
If you build the package around a wheel or tarball obtained from PyPI,
setuptools_scm should be able to get the version out. It will fail to
determine the version from a Github tarball.

> My current development branch adds a new dependency on cffi (libffi) to
> access
> > leptonica (also a tesseract dependency), and automatic fixing of page
> rotation.
>
> Cool!


> --
> Sean Whitton
>

Bug#814533: texlive-latex-extra: dpkg fails parsing package status

[Norbert Preining]

reassign 814533 dpkg
thanks

> MySQL database support detected, but apparently missing Depends on
> dbconfig-mysql packages. Please report this issue to the package maintainer..
> MySQL database support detected, but apparently missing Depends on
> dbconfig-mysql packages. Please report this issue to the package maintainer..

Was this a message from dpkg *during* the configuration of texlive-latex-extra?
We don't have anything sql related in our package, so this
looks like a message from a different pacakge.

> dpkg: error: parsing file '/var/lib/dpkg/status' near line 14427 package
> 'texlive-latex-extra':
>  newline in field name '!.'

This is a problem with dpkg, reassigning it.

Norbert


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

Bug#814559: mk-origtargz: uscan “Successfully downloaded”, then “Can't open” the same tarball

[James McCoy]

Control: forcemerge 809662 -1

On Sat, Feb 13, 2016 at 11:37:34AM +1100, Ben Finney wrote:
> After ‘uscan’ successfully downloads an upstream tarball file, it then
> exits with an error complaining it can't find the file it just downloaded:
> 
> --- ~/.devscripts ---
> . $HOME/.profile
> USCAN_DESTDIR="../tarballs"

This is #809662, fixed in yesterday's 2.16.1 upload.

Cheers,
-- 
James
GPG Key: 4096R/331BA3DB 2011-12-05 James McCoy 

Bug#814564: projectcenter.app: projectcenter crashes when editing code with braces

[Svetlana Tkachenko]

Package: projectcenter.app
Version: 0.6.1-1
Severity: normal

Dear Maintainer,

I opened projectcenter.
I typed "f{{}};" and pressed the left arrow key a few times.
ProjectCenter crashed, all of its windows closed.
I expected it to highlight the brackets and stay open.

This happens every time I try to edit code and move the cursor to a brace.


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

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

Versions of packages projectcenter.app depends on:
ii  gnustep-back0.24   0.24.0-4
ii  gnustep-base-runtime   1.24.7-1+b2
ii  gnustep-common [gnustep-fslayout-fhs]  2.6.6-3
ii  gnustep-gui-runtime0.24.0-3.1
ii  libc6  2.19-18
ii  libgcc11:5.3.1-7
ii  libgnustep-base1.241.24.7-1+b2
ii  libgnustep-gui0.24 0.24.0-3.1
ii  libobjc4   5.3.1-7

Versions of packages projectcenter.app recommends:
ii  gdb 7.7.1+dfsg-5
ii  gorm.app1.2.20-2
ii  libgnustep-gui-dev  0.24.0-3.1

projectcenter.app suggests no packages.

-- no debconf information

Bug#814563: Abandoned upstream

[David Prévot]

Package: xul-ext-searchload-options
Version: 0.8.0-3
Severity: serious
Tag: sid stretch

[Filled as RC by the maintainer to see it autore-moved from testing if
 nobody disagrees. Please, do downgrade it with an explanation if you
 disagree.]

Hi,

As shown on the homepage, “This add-on has been removed by its author.”
If the situation doesn’t change, there is a priori little point shipping
it in the next stable release (Stretch). It may even stop being useful
in the current stable release (Jessie) since iceweasel is being updated
to more recent LTS versions once they become available (thus the current
tags may soon be useless).

I intend to follow up with an RM request in a few months if nobody
objects, ditto for Jessie if this add-on stops being useful (but feel
free to beat me to it).

Regards

David


signature.asc
Description: PGP signature

Bug#814508: initramfs-tools: bluetooth/hci fails

[Stefano Callegari]

Il Fri, Feb 12, 2016 at 07:41:18PM +, Ben Hutchings scrisse:
> Control: tag -1 moreinfo
> 
> On Fri, 2016-02-12 at 11:45 +0100, Stefano wrote:
> > Package: initramfs-tools
> > Version: 0.123
> > Severity: normal
> > 
> > Dear Maintainer,
> > 
> > after upgrade initramfs-tools and initramfs-tools-core from 0.122 (and 
> > others),
> > this morning my bluetooth mouse doesn't work anymore.
> > 
> > Downgraded both to 0.122 (and reboot), the mouse works again.
> > 
> > With 0.123 the kde5 System Settings can't find a bluetooth device:
> > 
> > ~ <-su> # rfkill list
> > 0: ideapad_wlan: Wireless LAN
> > Soft blocked: yes
> > Hard blocked: no
> > 1: ideapad_bluetooth: Bluetooth
> > Soft blocked: no
> > Hard blocked: no
> > 2: phy0: Wireless LAN
> > Soft blocked: yes
> > Hard blocked: no
> >
> >
> > With 0.122 I have
> > 
> > ~ <-su> # rfkill list
> > 0: ideapad_wlan: Wireless LAN
> > Soft blocked: yes
> > Hard blocked: no
> > 1: ideapad_bluetooth: Bluetooth
> > Soft blocked: no
> > Hard blocked: no
> > 2: phy0: Wireless LAN
> > Soft blocked: yes
> > Hard blocked: no
> > 3: hci0: Bluetooth
> > Soft blocked: no
> > Hard blocked: no
> 
> Could you please send, for the initramfs generated by v0.123:
> 
> 1. The output of 'lsinitramfs /boot/initrd.img-4.3.0-1-amd64'
> 2. The contents of '/run/initramfs/initramfs.debug' after booting with
>    the additional kernel parameter 'debug'
> 
> And the same for the working initramfs generated by v0.122.
> 
> Ben.
> 
> -- 
> Ben Hutchings
> I say we take off; nuke the site from orbit.  It's the only way to be sure.

Hi,

attached you find the debug.

But

I have done as follow:

1) added 'debug' into grub;

2) reboot with 0.122 - bluetooth ko, system setting told me 'no bluetooth
device found', but rfkill has showed me hci0;

3) update to 0.123 and reboot - bluetooth works!

Yesterday I have rebooted more times, before to search the problem and
after for reportbug, but only when I had the 0.122 the bluetooth has
worked.

So I think I have more problems...

Thanks
-- 
Stefano Callegari 
+ [ -z  ]
+ BOOT=local
+ [ -n  ]
+ resume=UUID=31a97f90-f608-43db-8634-d7434f87cdd8
+ maybe_break top
+ run_scripts /scripts/init-top
+ initdir=/scripts/init-top
+ [ ! -d /scripts/init-top ]
+ shift
+ . /scripts/init-top/ORDER
+ /scripts/init-top/all_generic_ide
+ [ -e /conf/param.conf ]
+ /scripts/init-top/blacklist
+ [ -e /conf/param.conf ]
+ /scripts/init-top/keymap
+ [ -e /conf/param.conf ]
+ /scripts/init-top/udev
calling: trigger
device-enumerator: scan all dirs
  device-enumerator: scanning /sys/bus
  device-enumerator: scanning /sys/class
calling: settle
+ [ -e /conf/param.conf ]
+ maybe_break modules
+ [ n != y ]
+ log_begin_msg Loading essential drivers
+ _log_msg Begin: Loading essential drivers ... 
+ [ n = y ]
+ printf Begin: Loading essential drivers ... 
Begin: Loading essential drivers ... + [ -n  ]
+ load_modules
+ [ -e /conf/modules ]
+ cat /conf/modules
+ read m
+ [ -z scsi:t-0x00 ]
+ printf %.1s scsi:t-0x00
+ com=s
+ [ s = # ]
+ modprobe scsi:t-0x00
+ read m
+ [ -z sd_mod ]
+ printf %.1s sd_mod
+ com=s
+ [ s = # ]
+ modprobe sd_mod
+ read m
+ [ -z pci:v1022d7801sv17AAsd3801bc01sc06i01 ]
+ printf %.1s pci:v1022d7801sv17AAsd3801bc01sc06i01
+ com=p
+ [ p = # ]
+ modprobe pci:v1022d7801sv17AAsd3801bc01sc06i01
+ read m
+ [ -z ahci ]
+ printf %.1s ahci
+ com=a
+ [ a = # ]
+ modprobe ahci
+ read m
+ [ -z microcode ]
+ printf %.1s microcode
+ com=m
+ [ m = # ]
+ modprobe microcode
+ read m
+ [ n != y ]
+ log_end_msg
+ _log_msg done.\n
+ [ n = y ]
+ printf done.\n
done.
+ maybe_break premount
+ [ n != y ]
+ log_begin_msg Running /scripts/init-premount
+ _log_msg Begin: Running /scripts/init-premount ... 
+ [ n = y ]
+ printf Begin: Running /scripts/init-premount ... 
Begin: Running /scripts/init-premount ... + run_scripts /scripts/init-premount
+ initdir=/scripts/init-premount
+ [ ! -d /scripts/init-premount ]
+ shift
+ . /scripts/init-premount/ORDER
+ /scripts/init-premount/amd64_microcode
+ [ -e /conf/param.conf ]
+ [ n != y ]
+ log_end_msg
+ _log_msg done.\n
+ [ n = y ]
+ printf done.\n
done.
+ maybe_break mount
+ log_begin_msg Mounting root file system
+ _log_msg Begin: Mounting root file system ... 
+ [ n = y ]
+ printf Begin: Mounting root file system ... 
Begin: Mounting root file system ... + . /scripts/local
+ . /scripts/nfs
+ . /scripts/local
+ parse_numeric UUID=fd709365-bd5b-44c2-91ec-423898a4ac6a
+ return
+ maybe_break mountroot
+ mount_top
+ local_top
+ [  != yes ]
+ [ n != y ]
+ log_begin_msg Running /scripts/local-top
+ _log_msg Begin: Running /scripts/local-top ... 
+ [ n = y ]
+ printf Begin: Running /scripts/local-top ... 
Begin: Running /scripts/local-top ... + run_scripts /scripts/local-top
+ initdir=/scripts/local-top
+ [ ! -d /scripts/local-top ]
+ return
+ [ n != y ]
+ log_end_msg
+ _log_msg don

Bug#813562: Project maintainer here

[Sean Whitton]

Hello,

On Fri, Feb 12, 2016 at 03:23:39AM -0800, James R Barlow wrote:
> Let me know if you'd like to see any changes to help with packaging.

Thank you for your input, and for OCRmyPDF.

I have a non-packaging question that I'd like to take this opportunity
to ask you: in your changelog entry for 3.2, it's explained that the new
"lossless reconstruction" feature is disabled by --deskew and
--clean-final but otherwise PDF contents are now added to but not
modified by OCRmyPDF.  I had observed that OCRmyPDF makes my PDFs much
smaller without making them any harder to read, presumably by changing
the content, and I rather liked this feature.  Can I turn it back on?
Or was --clean-final doing this and turning that on would be enough?

> If you are packaging around 3.1.1, versions older than 3.2.1 are
> incompatible with the recently released img2pdf 0.2.0; they require
> 0.1.5, and they do not enforce this dependency on their own.

I've got a working package for 3.1 but I'm now trying to update my
packaging for the 3.2 series before I try to find a sponsor DD to upload
to Debian.  I'm figuring out how your change to use setuptools-scm can
be made to work with the Debian toolchain.

> My current development branch adds a new dependency on cffi (libffi) to access
> leptonica (also a tesseract dependency), and automatic fixing of page 
> rotation.

Cool!

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#814562: New upstream release

[David Prévot]

Package: xul-ext-ubiquity
Version: 0.6.4~pre20140729-1
Control: found -1 0.6.4~pre20141206-1

Hi Gabriele,

You might have missed it since the watch file is broken, but a new
release of Ubiquity (0.6.5b) has been published [0] recently. Would be
nice to have the package updated in time for Stretch.

0: https://addons.mozilla.org/en-US/firefox/addon/mozilla-labs-ubiquity/

Regards

David


signature.asc
Description: PGP signature

Bug#814561: New upstream release

[David Prévot]

Package: xul-ext-google-tasks-sync
Version: 0.5.1-1

Hi Michael,

You might have missed it since the watch file is broken, but a new
release of Google Tasks Sync (0.5.2) has been published [0] almost a
year ago. Would be nice to have the package updated in time for Stretch.

0: https://addons.mozilla.org/thunderbird/addon/google-tasks-sync/

Regards

David


signature.asc
Description: PGP signature

Bug#812131: krb5: Please package 1.14 (willing to provide assistance)

[Sam Hartman]

I've done the import and rebase and have confirmed the result builds.
I need to adjust symbols files, pull in a few patches from the 1.14
branch, etc.
But progress is happening here.

Bug#814560: Abandoned upstream

[David Prévot]

Package: xul-ext-https-finder
Version: 091-1
Severity: serious
Tag: sid stretch

[Filled as RC by a team member to see it autoremoved from testing if
 nobody disagrees. Please, do downgrade it with an explanation if you
 disagree.]

Hi,

The following seem to explain well enough the current situation:

> It seems this add-on has been abandoned, considering the lack of
> update and the unanswered issues opened both here and on Google Code.
> I assume the author just doesn't have time to develop it anymore,
> which is why it was removed from the Addons website. Either by the
> author or automatically because it stopped working with the latest
> version of Firefox.
>
> It's too bad, it's a fairly useful extension.

https://github.com/kevinjacobs/HTTPS-Finder/issues/18#issuecomment-75471662

If the situation doesn’t change, there is a priori little point shipping
it in the next stable release (Stretch). It may even stop being useful
in the current stable release (Jessie) since iceweasel is being updated
to more recent LTS versions once they become available (thus the current
tags may soon be useless).

I intend to follow up with an RM request in a few months if nobody
objects, ditto for Jessie if this add-on stop being useful (but feel
free to beat me to it).

Regards

David


signature.asc
Description: PGP signature

Bug#814559: mk-origtargz: uscan “Successfully downloaded”, then “Can't open” the same tarball

[Ben Finney]

Package: devscripts
Version: 2.15.10
Severity: normal

After ‘uscan’ successfully downloads an upstream tarball file, it then
exits with an error complaining it can't find the file it just downloaded:

=
$ uscan --download-current-version --force
uscan: uscan (version 2.15.10) See uscan(1) for help
uscan: Scan watch files in .
uscan: ./debian/changelog sets package="xkcdpass" version="1.4.3"
uscan: Newest version on remote site is 1.4.3, specified download version is 
1.4.3
uscan: Downloading upstream package: xkcdpass-1.4.3.tar.gz
uscan: Start checking for common possible upstream OpenPGP signature files
uscan: End checking for common possible upstream OpenPGP signature files
uscan: Successfully downloaded package xkcdpass-1.4.3.tar.gz
Can't open 'xkcdpass-1.4.3.tar.gz': No such file or directory at /usr/bin/uscan 
line 3705.
=

By enabling ‘--verbose’ on the command line, it appears the failure is
actually from ‘mk-origtargz’:

=
$ uscan --verbose --download-current-version --force
uscan: uscan (version 2.15.10) See uscan(1) for help
uscan: Scan watch files in .
uscan info: Check debian/watch and debian/changelog in .
uscan info: package="xkcdpass" version="1.4.3-1" (as seen in debian/changelog)
uscan info: package="xkcdpass" version="1.4.3" (no epoch/revision)
uscan: ./debian/changelog sets package="xkcdpass" version="1.4.3"
uscan info: Process ./debian/watch (package=xkcdpass version=1.4.3)
uscan info: Last orig.tar.* tarball version (from debian/changelog): 1.4.3
uscan info: Download the --download-current-version specified version: 1.4.3
uscan info: Requesting URL:
   https://github.com/redacted/XKCD-password-generator/releases/
uscan info: Matching pattern:
   
(?:(?:https://github.com)?\/redacted\/XKCD\-password\-generator\/releases\/)?/redacted/XKCD-password-generator/archive/xkcdpass-(\S+)\.tar\.(?:gz|bz2|xz)
uscan info: Found the following matching hrefs on the web page (newest first):
   /redacted/XKCD-password-generator/archive/xkcdpass-1.4.3.tar.gz (1.4.3) 
index=1.4.3.1 matched with the download version
   /redacted/XKCD-password-generator/archive/xkcdpass-1.4.2.tar.gz (1.4.2) 
index=1.4.2.1
   /redacted/XKCD-password-generator/archive/xkcdpass-1.4.1.tar.gz (1.4.1) 
index=1.4.1.1
   /redacted/XKCD-password-generator/archive/xkcdpass-1.4.0.tar.gz (1.4.0) 
index=1.4.0.1
   /redacted/XKCD-password-generator/archive/xkcdpass-1.2.5.tar.gz (1.2.5) 
index=1.2.5.1
   /redacted/XKCD-password-generator/archive/xkcdpass-1.2.4.tar.gz (1.2.4) 
index=1.2.4.1
   /redacted/XKCD-password-generator/archive/xkcdpass-1.2.3.tar.gz (1.2.3) 
index=1.2.3.1
   /redacted/XKCD-password-generator/archive/xkcdpass-1.2.2.tar.gz (1.2.2) 
index=1.2.2.1
   /redacted/XKCD-password-generator/archive/xkcdpass-1.2.1.tar.gz (1.2.1) 
index=1.2.1.1
   /redacted/XKCD-password-generator/archive/xkcdpass-1.2.0.tar.gz (1.2.0) 
index=1.2.0.1
uscan info: Matching target for downloadurlmangle: 
https://github.com/redacted/XKCD-password-generator/archive/xkcdpass-1.4.3.tar.gz
uscan info: Upstream URL (downloadurlmangled):
   
https://github.com/redacted/XKCD-password-generator/archive/xkcdpass-1.4.3.tar.gz
uscan info: Newest upstream tarball version selected for download 
(uversionmangled): 1.4.3
uscan info: Download filename (filenamemangled): xkcdpass-1.4.3.tar.gz
uscan: Newest version on remote site is 1.4.3, specified download version is 
1.4.3
uscan: Downloading upstream package: xkcdpass-1.4.3.tar.gz
uscan info: Requesting URL:
   
https://github.com/redacted/XKCD-password-generator/archive/xkcdpass-1.4.3.tar.gz
uscan: Start checking for common possible upstream OpenPGP signature files
uscan: End checking for common possible upstream OpenPGP signature files
uscan info: Missing OpenPGP signature.
uscan info: New orig.tar.* tarball version (oversionmangled): 1.4.3
uscan: Successfully downloaded package xkcdpass-1.4.3.tar.gz
uscan info: Executing internal command:
   mk-origtargz --package xkcdpass --version 1.4.3 --compression gzip 
--directory ../tarballs --copyright-file debian/copyright 
../tarballs/xkcdpass-1.4.3.tar.gz
uscan info: New orig.tar.* tarball version (after mk-origtargz): 1.4.3
Can't open 'xkcdpass-1.4.3.tar.gz': No such file or directory at /usr/bin/uscan 
line 3705.
=

Any settings that affect where ‘uscan’ puts its files should be obeyed
by the ‘mk-origtargz’ command invoked by ‘uscan’ in the same session.

Possibly ‘mk-origtargz’ should also obey any relevant ‘uscan’
configuration when running ‘mk-origtargz’ stand alone.


-- Package-specific info:

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

--- ~/.devscripts ---
. $HOME/.profile
USCAN_DESTDIR="../tarballs"
USCAN_SYMLINK=symlink

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

Kernel: Linux 4.3.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_AU.utf8, LC_CTYPE=en_AU.utf8 (charmap=UTF-8) (ignored: LC_ALL 
set to en_AU.utf8)
Shell: /bin/sh linked to /bin/

Bug#814554: octave: Saving figure to a PNG or PDF file gives black plot area when using gnuplot graphics

[Mike Miller]

On Sat, Feb 13, 2016 at 01:13:56 +0300, Andrei Demekhov wrote:
> I obtain plots with fully black plot area when using gnuplot backend and
> saving figures to PNG or PDF files (by either saveas or print). It probably
> started to happen after upgrading to gnuplot5. It is pity because the
> gnuplot toolkit is superior to FLTK or QT with respect to special font and
> font effects (sub/superscripts) handling. Note that gnuplot
> itself/standalone works fine.
> 
> According to http://savannah.gnu.org/bugs/?42838, something similar (but only
> for PDFs) was discussed upstream and was considered fixed.

Yes, this is the same issue as the bug you reference. I have asked on
that bug report whether it could be applied to the next stable release.
Untested, but the patch looks simple enough to apply to the Debian
package to fix this incompatibility.

-- 
mike

Bug#814478: cups: OKI 320 print drivers not working correctly

[Kurt Theis]

Thanks for looking at this issue.

> Do any of the parallel port settings in the BIOS have an effect?

Since this is running on a Raspberry Pi I don't believe I have any
immediate access to the BIOS. At least I'm not aware of any way to access
it.

> I believe the printer has an Emulation Mode. What is being used now?
> Does changing it have any effect?

There are two emulation modes: IBM PPR and Epson FX. Per the manual I have
IBM Proprinter II/XL and IBM Graphics. The Epson options are FX86/286 and
EX800/1000.

I tried these emulation modes (after setting the mode in the printer front
panel menu) using IBM and Epson drivers. I Also tried Oki drivers in each
mode.

After several tries I got this message from the CUPS localhost webpage:
(See image). This came across while using the "Print Test Page" option in
printer maintenance dropdown.

I set the printer back to OKI mL (microline) mode and changed the driver
back to generic 9 pin. a "ls -la | lpr" command on the command line prints
OK as it should. The Print Test Page drop down still gives me the indicated
error.

> Which particular feature is important to you?

There are different font styles (pitch/letter styles,
subscript/superscript) that I am trying to use.

>Please post what you get for

  grep NickName /etc/cups/ppd/

pi@kurts_office:/media/extstorage/pi/simulators/8080 $ l /etc/cups/ppd
total 20
drwxr-xr-x 2 root lp 4096 Feb 12 16:28 .
drwxr-xr-x 5 root lp 4096 Feb 12 16:28 ..
-rw-r- 1 root lp 1401 Feb 12 16:28 OKI_DATA_CORP_ML320_1TURBO.ppd
-rw-r- 1 root lp 5503 Feb 12 16:24 OKI_DATA_CORP_ML320_1TURBO.ppd.O
pi@kurts_office:/media/extstorage/pi/simulators/8080 $


pi@kurts_office:/media/extstorage/pi/simulators/8080 $ sudo cat
/etc/cups/ppd/OKI*.ppd
*PPD-Adobe: "4.3"
*%
*% Text-only printer definition
*%
*FormatVersion: "4.3"
*FileVersion: "1.1"
*LanguageVersion: English
*LanguageEncoding: ISOLatin1
*PCFileName: "TEXTONLY.PPD"
*Manufacturer: "Generic"
*Product: "(Generic)"
*cupsVersion:   1.0
*cupsManualCopies: True
*cupsModelNumber:  2
*cupsFilter:"text/plain 0 textonly"
*cupsFilter2:"text/plain text/plain 0 textonly"
*ModelName: "Generic text-only printer"
*ShortNickName: "Generic text-only printer"
*NickName:  "Generic text-only printer"
*PSVersion: "(2017.000) 0"
*LanguageLevel: "2"
*ColorDevice: False
*DefaultColorSpace: Gray
*FileSystem: False
*Throughput: "8"
*LandscapeOrientation: Plus90
*VariablePaperSize: False
*TTRasterizer: Type42
*DefaultImageableArea: Letter
*ImageableArea Letter/US Letter: "18 36 594 756"
*DefaultPaperDimension: Letter
*PaperDimension Letter/Letter: "612 792"
*OpenUI *PageSize/Media Size: PickOne
*OrderDependency: 10 AnySetup *PageSize
*DefaultPageSize: Letter
*PageSize Letter/Letter: "<>setpagedevice"
*CloseUI: *PageSize
*OpenUI *PageRegion: PickOne
*OrderDependency: 10 AnySetup *PageRegion
*DefaultPageRegion: Letter
*PageRegion Letter/Letter: "<>setpagedevice"
*CloseUI: *PageRegion

*OpenUI *SendFF: Boolean
*DefaultSendFF: False
*SendFF True/True:""
*SendFF False/False:   ""
*CloseUI: *SendFF
pi@kurts_office:/media/extstorage/pi/simulators/8080 $


The "Text Only Printer" is the current generic setup.

I get the following when I set the printer driver (thru CUPS local webpage)
to Oki 9 pin:

*PCFileName: "okidata9.ppd"
*Product: "(9-Pin Series)"
*Manufacturer: "Oki"
*ModelName: "Oki 9-Pin Series"
*ShortNickName: "Oki 9-Pin Series"
*NickName: "Oki 9-Pin Series"
*PSVersion: "(3010.000) 0"


This setting gives me gibberish when printing.

Hope this helps a bit.

Kurt



Print Test Page OKI_DATA_CORP_ML320_1TURBO Error

Unable to print test page:

Unsupported format "application/vnd.cups-pdf-banner".


On Fri, Feb 12, 2016 at 7:31 AM, Brian Potkin 
wrote:

> severity 814478 normal
> tags 814478 moreinfo
> thanks
>
>
>
> Thank you for the report, Kurt, I think because you can print to the
> printer a reduced severity is justified.
>
> On Thu 11 Feb 2016 at 19:47:40 -0500, Kurt Theis wrote:
>
> > The printer driver for the OKI Microline 320 turbo printer does not send
> > any recognizable output to the printer. This is a dot matrix printer.
> >
> > In installing cups, I chose the USB connected OKI 320 driver. When I
> printed a
> > text file (a listing of ls-a) random characters were printed out along
> with a LOT
> > of FF's.
>
> Do any of the parallel port settings in the BIOS have an effect?
>
> > When I switched the driver to generic the printer worked just fine. I
> switched back to the OKI
> > driver, got the same bad result. I switched back to generic and all
> works well.
>
> I believe the printer has an Emulation Mode. What is being used now?
> Does changing it have any effect?
>
> > FYI - Since 1994 the drivers NEVER worked for ANY oki dot matrix printer
> > I tried to use. This is not a new occurance. Guessing the old drivers
> were just copied
> > every time since then (yes, i have had a working Linux installation
> since '94)
> >
> > I very much want to use the driver for t

Bug#814558: libglib2.0-0-dbg: GDB backtrace decoration broken

[anon]

Package: libglib2.0-0-dbg
Version: 2.47.5-1
Severity: normal

Dear Maintainer,

whenever I have GDB output a backtrace containing GLib functions, I get
something like this instead of informative lines about said functions:

Python Exception  
returned a result with an error set:

After setting GDB's ``python print-stack`` option to ``full``, I get this
additional detail:

#0  0x in OverflowError: Python int too large to convert to C long

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/usr/share/gdb/python/gdb/FrameDecorator.py", line 97, in function
if not isinstance(self._base, gdb.Frame):
SystemError:  returned a result with an error
set

I can provide a minimal example if you want, but really on my system this
happens with any program containing GLib or related functions (including GTK+).
Just set a breakpoint on one of them and tell GDB to print a backtrace. It
doesn't happen with any other library's functions that I know of.

I figured I'd file this bug for libglib2.0-0-dbg because it probably has
something to do with those GDB auto-load Python scripts, e.g.
libglib-2.0.so.0.4705.0-gdb.py. Not 100% sure though, what do you think? Might
well be my fault.

Tested this with the "testing" (2.46.2-3) as well as "experimental" (2.47.5-1)
package versions.

Cheers



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

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

Versions of packages libglib2.0-0-dbg depends on:
ii  libglib2.0-0  2.47.5-1

libglib2.0-0-dbg recommends no packages.

libglib2.0-0-dbg suggests no packages.

-- no debconf information

Bug#814557: drop support for libmatroska and libebml in squeeze (and wheezy?)

[Antoine Beaupré]

Package: debian-security-support
Version: 2016.01.07~deb6u1
Severity: wishlist

I am not sure exactly how to maintain this package, so I file this as
a bug for now, as I was informed we may or may not need multiple
uploads (to all suites!) to update this... (See also #762594.)

Basically, VLC and other similar packages are EOL in squeeze, but
libebml and matroska still show up on our radars. As discussed here, I
believe those two packages should be marked as unsupported here:

https://lists.debian.org/debian-lts/2016/02/msg00018.html

I'll do this as soon as I figure out how to do this myself, otherwise
feel free to bundle this in the next uploads.

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

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

Bug#814556: nvidia-modprobe: Can not build nvidia-modprobe_358.09-1 on Wheezy

[Wylda]

Package: nvidia-modprobe
Version: 358.09-1
Severity: normal

Dear Maintainer,
i have a problem with source package nvidia-modprobe. I own
Nvidia GTX 970 and i already built nvidia-driver including all
its dependecies. The last one, which can not be built cleanly
is nvidia-modprobe. It _probably_ fails somewhere in MANPAGE.

I somehow rip that part from Makefile and it built finaly.
But i don't know what i was doing ;) and i would appreciate
a clean build. There is the problem:


$ dpkg-buildpackage -b -tc -us -uc

dpkg-buildpackage: source package nvidia-modprobe
dpkg-buildpackage: source version 358.09-1
dpkg-buildpackage: source changed by Andreas Beckmann 
 dpkg-source --before-build nvidia-modprobe-358.09
dpkg-buildpackage: host architecture i386
 fakeroot debian/rules clean
dh clean
dpkg-parsechangelog: unknown option `-S'

   dh_testdir
   debian/rules override_dh_auto_clean
make[1]: Entering directory `/build/nvidia/nvidia-modprobe-358.09'
dh_auto_clean
dpkg-parsechangelog: unknown option `-S'

make[2]: Entering directory `/build/nvidia/nvidia-modprobe-358.09'
rm -rf _out/Linux_x86/nvidia-modprobe _out/Linux_x86/nvidia-modprobe.1.gz *~ 
_out/Linux_x86/g_stamp.c \
  _out/Linux_x86/*.o _out/Linux_x86/*.d \
  /build/nvidia/nvidia-modprobe-358.09/_out/Linux_x86/gen-manpage-opts 
_out/Linux_x86/options.1.inc
make[2]: Leaving directory `/build/nvidia/nvidia-modprobe-358.09'
rm -f -r _out */_out
make[1]: Leaving directory `/build/nvidia/nvidia-modprobe-358.09'
   dh_clean
 debian/rules build
dh build
dpkg-parsechangelog: unknown option `-S'

   dh_testdir
   dh_auto_configure
   debian/rules override_dh_auto_build
make[1]: Entering directory `/build/nvidia/nvidia-modprobe-358.09'
CC_ONLY_CFLAGS="-D_FORTIFY_SOURCE=2" dh_auto_build -O--parallel
dpkg-parsechangelog: unknown option `-S'

make[2]: Entering directory `/build/nvidia/nvidia-modprobe-358.09'
cc -g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat 
-Werror=format-security -fno-strict-aliasing -fno-omit-frame-pointer -Wformat=2 
-Wno-unused-parameter -Wno-format-zero-length -DNV_LINUX -DNV_X86 
-DNV_ARCH_BITS=32 -D_FORTIFY_SOURCE=2 -I _out/Linux_x86 -I common-utils -I 
modprobe-utils -DPROGRAM_NAME=\""nvidia-modprobe"\" -D_BSD_SOURCE -ansi 
-pedantic -c nvidia-modprobe.c -o _out/Linux_x86/nvidia-modprobe.o && cc -MM -g 
-O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat 
-Werror=format-security -fno-strict-aliasing -fno-omit-frame-pointer -Wformat=2 
-Wno-unused-parameter -Wno-format-zero-length -DNV_LINUX -DNV_X86 
-DNV_ARCH_BITS=32 -D_FORTIFY_SOURCE=2 -I _out/Linux_x86 -I common-utils -I 
modprobe-utils -DPROGRAM_NAME=\""nvidia-modprobe"\" -D_BSD_SOURCE -ansi 
-pedantic nvidia-modprobe.c | sed -e "s,: ,: $\(wildcard ," -e 
"s,\([^\\]\)$,\1)," -e "s;^nvidia-modprobe.o: ; 
_out/Linux_x86/nvidia-modprobe.o: ;" > _out/Linux_x86/nvidia-modprobe.d
cc -g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat 
-Werror=format-security -fno-strict-aliasing -fno-omit-frame-pointer -Wformat=2 
-Wno-unused-parameter -Wno-format-zero-length -DNV_LINUX -DNV_X86 
-DNV_ARCH_BITS=32 -D_FORTIFY_SOURCE=2 -I _out/Linux_x86 -I common-utils -I 
modprobe-utils -DPROGRAM_NAME=\""nvidia-modprobe"\" -D_BSD_SOURCE -ansi 
-pedantic -c common-utils/nvgetopt.c -o _out/Linux_x86/nvgetopt.o && cc -MM -g 
-O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat 
-Werror=format-security -fno-strict-aliasing -fno-omit-frame-pointer -Wformat=2 
-Wno-unused-parameter -Wno-format-zero-length -DNV_LINUX -DNV_X86 
-DNV_ARCH_BITS=32 -D_FORTIFY_SOURCE=2 -I _out/Linux_x86 -I common-utils -I 
modprobe-utils -DPROGRAM_NAME=\""nvidia-modprobe"\" -D_BSD_SOURCE -ansi 
-pedantic common-utils/nvgetopt.c | sed -e "s,: ,: $\(wildcard ," -e 
"s,\([^\\]\)$,\1)," -e "s;^nvgetopt.o: ; _out/Linux_x86/nvgetopt.o: ;" > 
_out/Linux_x86/nvgetopt.d
common-utils/nvgetopt.c: In function ‘nvgetopt’:
common-utils/nvgetopt.c:219:19: warning: ignoring return value of ‘strtol’, 
declared with attribute warn_unused_result [-Wunused-result]
cc -g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat 
-Werror=format-security -fno-strict-aliasing -fno-omit-frame-pointer -Wformat=2 
-Wno-unused-parameter -Wno-format-zero-length -DNV_LINUX -DNV_X86 
-DNV_ARCH_BITS=32 -D_FORTIFY_SOURCE=2 -I _out/Linux_x86 -I common-utils -I 
modprobe-utils -DPROGRAM_NAME=\""nvidia-modprobe"\" -D_BSD_SOURCE -ansi 
-pedantic -c common-utils/common-utils.c -o _out/Linux_x86/common-utils.o && cc 
-MM -g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat 
-Werror=format-security -fno-strict-aliasing -fno-omit-frame-pointer -Wformat=2 
-Wno-unused-parameter -Wno-format-zero-length -DNV_LINUX -DNV_X86 
-DNV_ARCH_BITS=32 -D_FORTIFY_SOURCE=2 -I _out/Linux_x86 -I common-utils -I 
modprobe-utils -DPROGRAM_NAME=\""nvidia-modprobe"\" -D_BSD_SOURCE -ansi 
-pedantic common-utils/common-utils.c | sed -e "s,: ,: $\(wildcard ," -e 
"s,\([^\\]\)$,\1)," -e "s;^common-utils.o: ; _out/Linux_x86/common-utils.o: ;" 
> _out/L

Bug#812207: linux: AUFS can hang up; Please update to v20160111 or later

[Ben Hutchings]

On Fri, 2016-02-12 at 14:41 -0800, Zachary Loafman wrote:
> Ben -
> 
> Thanks for queueing these. I've been trying to figure out the process from
> this point forward, though, and wondering if you can help educate me.
> Looking at
> http://metadata.ftp-master.debian.org/changelogs/main/l/linux/?C=M;O=A, it
> looks like there has been at least (4.3.5-1) unstable and (4.4.1-1~exp1)
> experimental builds since the patches were queued, but I don't think I saw
> the aufs patches in those changelogs. I also haven't yet seen any builds
> beyond those, and those are both lower urgency, it looks like.

Those versions of the kernel package do not include aufs at all.  (They
do have a few supporting changes that allow aufs to be built separately
as a module.)

> If these were queued for a security update, is there a deadline timer
> before they go out for jessie-security and wheezy-backports, or does it
> just mean they're on a security train that goes out with the next CVE?

The latter.

Ben.

-- 
Ben Hutchings
I say we take off; nuke the site from orbit.  It's the only way to be sure.

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

Bug#812049: zeromq3: FTBFS with GCC 6: dereferencing type-punned pointer

[Luca Boccassi]

Control: tag -1 fixed-upstream

On Tue, 19 Jan 2016 20:51:29 -0800 Martin Michlmayr  wrote:
> Package: zeromq3
> Version: 4.0.5+dfsg-3
> Severity: important
> User: debian-...@lists.debian.org
> Usertags: ftbfs-gcc-6
>
> This package fails to build with GCC 6.  GCC 6 has not been released
> yet, but it's expected that GCC 6 will become the default compiler for
> stretch.
>
> Note that only the first error is reported; there might be more.  You
> can find a snapshot of GCC 6 in experimental.  To build with GCC 6,
> you can set CC=gcc-6 CXX=g++-6 explicitly.
>
> You may be able to find out more about this issue at
> https://gcc.gnu.org/gcc-6/changes.html
>
> > sbuild (Debian sbuild) 0.67.0 (26 Dec 2015) on dl580gen9-02.hlinux
> ...
> > libtool: compile:  g++ -DHAVE_CONFIG_H -I. -pedantic -Werror -Wall 
> > -D_GNU_SOURCE -D_REENTRANT -D_THREAD_SAFE -Wdate-time -D_FORTIFY_SOURCE=2 
> > -DZMQ_FORCE_EPOLL -I/usr/include/pgm-5.1 -I/usr/lib/pgm-5.1/include 
> > -fvisibility=hidden -g -O2 -fstack-protector-strong -Wformat 
> > -Werror=format-security -c zmq.cpp  -fPIC -DPIC -o .libs/libzmq_la-zmq.o
> > zmq.cpp: In function 'int zmq_recviov(void*, iovec*, size_t*, int)':
> > zmq.cpp:559:49: error: dereferencing type-punned pointer will break 
> > strict-aliasing rules [-Werror=strict-aliasing]
> >  recvmore = ((zmq::msg_t*) (void *) &msg)->flags () & 
> > zmq::msg_t::more;
> >  ^~
> >
> > cc1plus: all warnings being treated as errors
> > Makefile:1204: recipe for target 'libzmq_la-zmq.lo' failed

Hello,

FYI: fixed upstream in stable branches 4.0 [1] and 4.1 [2].

Kind regards,
Luca Boccassi

[1] https://github.com/zeromq/zeromq4-1/pull/101
[2] https://github.com/zeromq/zeromq4-x/pull/149

Bug#813858: gcc-5: [mips] regression: miscompilation caused by -fexpensive-optimizations

[Andreas Cadhalpun]

Control: forwarded -1 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69714
Control: tags -1 patch

Hi Aurelien,

On 08.02.2016 23:59, Aurelien Jarno wrote:
> On 2016-02-06 02:38, Andreas Cadhalpun wrote:
>> This works correctly with gcc-5 5.3.1-6, so it is a regression in 5.3.1-7.
> 
> In my case I am able to reproduce the issue with both version 5.3.1-6
> and 5.3.1-7, as well as 5.3.1-8.

This is very strange, as ffmpeg 7:2.8.5-1 built successfully with gcc-5 5.3.1-6
on the mips buildd.

> That said I don't think that GCC is broken here, instead the source code is 
> wrong.

I beg to differ.

>> static uint32_t av_bswap32(uint32_t x)
>> {
>> return x) << 8 & 0xff00) | ((x) >> 8 & 0x00ff)) << 16 | x) >> 
>> 16) << 8 & 0xff00) | (((x) >> 16) >> 8 & 0x00ff)));
>> }
> 
> Note that this doesn't really produce optimized code.  has a
> better code which calls __builtin_bswap32 on a (not that) recent GCC.

ffmpeg has it's own optimized versions for more common architectures.

>> return av_bswap32(*((uint32_t *) (&preamble[2])));
> 
> This is dereferencing a type-punned pointer, as reported by using -Wall.
> This means that GCC can now assume that the value to fetch in preamble is
> 32-bit aligned, and that's why it generates code to bswap the aligned
> 32-bit code starting at position 4 instead of the one starting at position
> 2.
> 
> Note that this undefined behavior can be reproduced on amd64 by using
> the -fsanitize=undefined option (ubsan):
> 
> | test.c:32:12: runtime error: load of misaligned address 0xffdf50da for type 
> 'uint32_t', which requires 4 byte alignment
> | 0xffdf50da: note: pointer points here
> |  04 08  21 10 f0 2d 00 00 00 00  48 d1 df ff 60 c1 75 f7  eb 15 74 f7 d4 99 
> 04 08  00 00 00 00 c0 84
> | 
> |   ^ 

These warnings are a red herring, as they are only an artifact from reducing
the testcase. They don't happen with the ffmpeg code and avoiding them in
the testcase, e.g. with the following diff, doesn't fix the problem:
--- a/test.c
+++ b/test.c
@@ -16,6 +16,8 @@
 void *a;
 } AVPacket;
 
+union unaligned_32 { uint32_t l; } __attribute__((packed)) 
__attribute__((may_alias));
+
 static uint32_t av_bswap32(uint32_t x)
 {
 return x) << 8 & 0xff00) | ((x) >> 8 & 0x00ff)) << 16 | x) >> 16) 
<< 8 & 0xff00) | (((x) >> 16) >> 8 & 0x00ff)));
@@ -29,5 +31,5 @@
 preamble[i] = s->pb->buf_ptr[0];
 s->pb->buf_ptr += 1;
 }
-return av_bswap32(*((uint32_t *) (&preamble[2])));
+return av_bswap32(((const union unaligned_32 *) (&preamble[2]))->l);
 }

On the other hand, gcc-5 5.3.1-7 also regressed on hppa, causing different test 
failures
of ffmpeg. I've reported this to debian-hppa, where it was analyzed and 
forwarded
upstream. The patch [1] fixing that also fixes the regression on mips.

Best regards,
Andreas


1: https://gcc.gnu.org/bugzilla/attachment.cgi?id=37655&action=diff

Bug#814555: libopenscenegraph-dev: New stable upstream available

[The GZeus]

Package: libopenscenegraph-dev
Version: 3.2.1-9
Severity: important
Tags: upstream

Dear Maintainer,

The latest stable OpenSceneGraph fixes a number of bugs, some of which can 
trigger crashes in applications which use it.
One in particular (openmw) is unlikely to work with this version past version 
0.38

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

   * What led up to the situation?
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
   * What was the outcome of this action?
   * What outcome did you expect instead?

*** End of the template - remove these template lines ***


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

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

Versions of packages libopenscenegraph-dev depends on:
ii  libgl1-mesa-dev [libgl-dev]11.1.1-2
ii  libglu1-mesa-dev [libglu-dev]  9.0.0-2.1
ii  libopenscenegraph100v5 3.2.1-9
ii  libopenthreads-dev 3.2.1-9

libopenscenegraph-dev recommends no packages.

Versions of packages libopenscenegraph-dev suggests:
pn  openscenegraph-doc   
pn  openscenegraph-examples  

-- no debconf information

Bug#814531: CAFF: signing on airgapped machines

[Guilhem Moulin]

On Fri, 12 Feb 2016 at 23:08:12 +0100, Guilhem Moulin wrote:
> How about an option ‘--signed-key-file’ (and ‘--lsigned-key-file’ for
> local sigs)?  Caff would export all signed keys in the specified file.

By the way, this is essentially

  gpg --homedir ~/.caff/gnupghome --export 

-- 
Guilhem.


signature.asc
Description: PGP signature

Bug#814554: octave: Saving figure to a PNG or PDF file gives black plot area when using gnuplot graphics

[Andrei Demekhov]

Package: octave
Version: 4.0.0-5+b3
Severity: important

Dear Maintainer,

I obtain plots with fully black plot area when using gnuplot backend and 
saving figures to PNG or PDF files (by either saveas or print). It 
probably started to happen after upgrading to gnuplot5. It is pity because 
the gnuplot toolkit is superior to FLTK or QT with respect to special font 
and font effects (sub/superscripts) handling. Note that gnuplot 
itself/standalone works fine.


According to http://savannah.gnu.org/bugs/?42838, something similar (but only
for PDFs) was discussed upstream and was considered fixed.

Best regards
Andrei



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

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

Versions of packages octave depends on:
ii  libamd2.4.1  1:4.4.6-1
ii  libarpack2   3.1.3-3+b1
ii  libasound2   1.0.28-1
ii  libatlas3-base [liblapack.so.3]  3.10.2-9+b1
ii  libblas3 [libblas.so.3]  3.6.0-2
ii  libc62.21-3
ii  libcamd2.4.1 1:4.4.6-1
ii  libccolamd2.9.1  1:4.4.6-1
ii  libcholmod3.0.6  1:4.4.6-1
ii  libcolamd2.9.1   1:4.4.6-1
ii  libcxsparse3.1.4 1:4.4.6-1
ii  libfftw3-double3 3.3.4-1
ii  libfftw3-single3 3.3.4-1
ii  libfltk-gl1.31.3.3-4
ii  libfltk1.3   1.3.3-4
ii  libfontconfig1   2.11.0-6.3
ii  libfreetype6 2.6.1-0.1
ii  libgcc1  1:5.3.1-3
ii  libgl1-mesa-glx [libgl1] 11.1.1-2
ii  libglpk364.53-1
ii  libglu1-mesa [libglu1]   9.0.0-2
ii  libgomp1 5.3.1-3
ii  libgraphicsmagick++-q16-12   1.3.23-1
ii  libgraphicsmagick-q16-3  1.3.23-1
ii  liblapack3 [liblapack.so.3]  3.6.0-2
ii  liboctave3v5 4.0.0-5+b3
ii  libosmesa6   11.1.1-2
ii  libportaudio219+svn20140130-1
ii  libqhull62012.1-4
ii  libqrupdate1 1.1.2-1
ii  libqscintilla2-12v5  2.9+dfsg-8
ii  libqt4-network   4:4.8.7+dfsg-5
ii  libqt4-opengl4:4.8.7+dfsg-5
ii  libqtcore4   4:4.8.7+dfsg-5
ii  libqtgui44:4.8.7+dfsg-5
ii  libsndfile1  1.0.25-10
ii  libstdc++6   5.3.1-3
ii  libumfpack5.7.1  1:4.4.6-1
ii  libx11-6 2:1.6.3-1
ii  octave-common4.0.0-5
ii  texinfo  5.1.dfsg.1-5

Versions of packages octave recommends:
ii  default-jre-headless   2:1.7-52
ii  gnuplot-qt [gnuplot-x11]   4.6.6-3
ii  gnuplot5-qt [gnuplot-qt]   5.0.3+dfsg1-1
ii  libatlas3-base 3.10.2-9+b1
ii  octave-info4.0.0-5
ii  oracle-java8-installer [default-jre-headless]  8u66+8u65arm-1~webupd8~1
ii  pstoedit   3.62-2+b4

Versions of packages octave suggests:
pn  octave-doc  
pn  octave-htmldoc  

-- debconf information:
Unescaped left brace in regex is deprecated, passed through in regex; marked by 
<-- HERE in m/^(.*?)(\\)?\${ <-- HERE ([^{}]+)}(.*)$/ at 
/usr/share/perl5/Debconf/Question.pm line 72.
Unescaped left brace in regex is deprecated, passed through in regex; marked by 
<-- HERE in m/\${ <-- HERE ([^}]+)}/ at /usr/share/perl5/Debconf/Config.pm line 
30.

Bug#814446: tomcat8: wants to overwrite admin configuration on upgrade

[Emmanuel Bourg]

Hi Thorsten,

Thank you for reporting this issue. I've also encountered this case when
upgrading tomcat7 and I agree this is rather annoying.

However I'm not sure to know what should be done here. I was under the
impression this dialog was actually expected when a package updates a
modified configuration file. The Policy §10.7.3 states (about
configuration files handled by maintainer scripts):

   "...it is the responsibility of the package maintainer to provide
   maintainer scripts which correctly create, update and maintain the
   file and remove it on purge. [...] These scripts must be idempotent
   [...], must cope with all the variety of ways dpkg can call
   maintainer scripts, must not overwrite or otherwise mangle the
   user's configuration without asking"

So I'm tempted to think that asking if the file should be overwritten or
not is actually compliant with the policy.

What behavior would you expect in this situation? Ignoring the update?
Merging the changes? (ucf has a --three-way option to allow merging the
changes, I don't know if it would help here).

Emmanuel Bourg

Bug#814553: Not possible to use arch armhf with debboostrap > 1.0.76

[Brian Murray]

Package: debootstrap
Version: 1.0.78
Severity: normal #http://www.debian.org/Bugs/Developer#severities
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu xenial

I discovered that I was no longer able to use mk-sbuild to create armhf
chroots with deboostrap version 1.0.78. The process ends with the
following:

I: Extracting zlib1g...
I: Running command: chroot /tmp/schroot-XJCj5b /debootstrap/debootstrap
--second-stage
I: Keyring file not available at
/usr/share/keyrings/ubuntu-archive-keyring.gpg; switching to https
mirror https://mirrors.kernel.org/debian

Manually running the chroot and debootstrap command listed above ends
with the same error even when using the --verbose switch.  Downgrading
debootstrap to version 1.0.75 fixes the issue and using 1.0.76 recreates
it. So it seems to be an issue caused by the changes between 1.0.75 and
1.0.76. Here is the full mk-sbuild command I'm using.

DEBOOTSTRAP_MIRROR=http://ports.ubuntu.com mk-sbuild --vg=virtual-vg
--arch armhf --name snapper vivid

--
Brian Murray @ubuntu.com


signature.asc
Description: Digital signature

Bug#814552: chromium-browser: Please allow spelling to use user’s word lists

[Reuben Thomas]

Package: chromium-browser
Version: 48.0.2564.82-0ubuntu0.14.04.1.1108
Severity: normal

Chromium, like many other Debian programs, uses hunspell for spelling.
However, unlike most other apps that use hunspell directly or indirectly
(e.g. Firefox, Pidgin, LibreOffice), Chromium uses a custom personal word
list format, and hence can’t share a per-user word list. (The other programs
mentioned can simply have their user wordlist file symlinked to a single
file, e.g. ~/.hunspell_en_GB.)

Would it be possible to patch Chromium to integrate it better with Debian in
this respect?

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

Kernel: Linux 3.19.0-47-generic (SMP w/4 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages chromium-browser depends on:
ii  bash  4.3-7ubuntu1.5
ii  chromium-codecs-ffmpeg-extra  48.0.2564.82-0ubuntu0.14.04.1.1108
ii  dpkg  1.17.5ubuntu5.5
ii  gconf-service 3.2.6-0ubuntu2
ii  libasound21.0.27.2-3ubuntu7
ii  libatk1.0-0   2.10.0-2ubuntu2
ii  libc6 2.19-0ubuntu6.6
ii  libcairo2 1.13.0~20140204-0ubuntu1.1
ii  libcomerr21.42.9-3ubuntu1.3
ii  libcups2  1.7.2-0ubuntu1.7
ii  libdbus-1-3   1.6.18-0ubuntu4.3
ii  libexpat1 2.1.0-4ubuntu1.1
ii  libfontconfig12.11.0-0ubuntu4.1
ii  libfreetype6  2.5.2-1ubuntu2.5
ii  libgcc1   1:4.9.3-0ubuntu4
ii  libgconf-2-4  3.2.6-0ubuntu2
ii  libgcrypt11   1.5.3-2ubuntu4.2
ii  libgdk-pixbuf2.0-02.30.7-0ubuntu1.2
ii  libglib2.0-0  2.40.2-0ubuntu1
ii  libgnome-keyring0 3.8.0-2
ii  libgssapi-krb5-2  1.12+dfsg-2ubuntu5.2
ii  libgtk2.0-0   2.24.23-0ubuntu1.3
ii  libk5crypto3  1.12+dfsg-2ubuntu5.2
ii  libkrb5-3 1.12+dfsg-2ubuntu5.2
ii  libnspr4  2:4.10.10-0ubuntu0.14.04.1
ii  libnspr4-0d   2:4.10.10-0ubuntu0.14.04.1
ii  libnss3   2:3.19.2.1-0ubuntu0.14.04.2
ii  libpam0g  1.1.8-1ubuntu2
ii  libpango-1.0-01.36.3-1ubuntu1.1
ii  libpangocairo-1.0-0   1.36.3-1ubuntu1.1
ii  libpangoft2-1.0-0 1.36.3-1ubuntu1.1
ii  libstdc++65.2.1-15ubuntu1
ii  libx11-6  2:1.6.2-1ubuntu2
ii  libxcomposite11:0.4.4-1
ii  libxcursor1   1:1.1.14-1
ii  libxdamage1   1:1.1.4-1ubuntu1
ii  libxext6  2:1.3.2-1ubuntu0.0.14.04.1
ii  libxfixes31:5.0.1-1ubuntu1.1
ii  libxi62:1.7.1.901-1ubuntu1.1
ii  libxrandr22:1.4.2-1
ii  libxrender1   1:0.9.8-1build0.14.04.1
ii  libxss1   1:1.2.2-1
ii  libxtst6  2:1.2.2-1
ii  xdg-utils 1.1.0~rc1-2ubuntu7.1
ii  zlib1g1:1.2.8.dfsg-1ubuntu1

Versions of packages chromium-browser recommends:
ii  chromium-browser-l10n  48.0.2564.82-0ubuntu0.14.04.1.1108

Versions of packages chromium-browser suggests:
pn  adobe-flashplugin   
pn  unity-chromium-extension
pn  webaccounts-chromium-extension  

-- Configuration Files:
/etc/chromium-browser/default changed [not included]
/etc/default/chromium-browser [Errno 2] No such file or directory: 
u'/etc/default/chromium-browser'

-- no debconf information

Bug#814551: birdfont: error while loading shared libraries: libxmlbird.so.1.0

[Arthur Marsh]

Package: birdfont
Version: 2.14.0-1
Severity: serious
Justification: Policy 3.5

Dear Maintainer,

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

   * What led up to the situation?

Any attempt to run the executable

$ birdfont -h
birdfont: error while loading shared libraries: libxmlbird.so.1.0: cannot open 
shared object file: No such file or directory

Although libxmlbird1 is installed, it only provides the shared library names:

/usr/lib/x86_64-linux-gnu/libxmlbird.so.1
/usr/lib/x86_64-linux-gnu/libxmlbird.so.1.3

and not libxmlbird.so.1.0

   * What exactly did you do (or not do) that was effective (or
 ineffective)?
   * What was the outcome of this action?
   * What outcome did you expect instead?

*** End of the template - remove these template lines ***


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

Kernel: Linux 4.5.0-rc3+ (SMP w/4 CPU cores)
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: sysvinit (via /sbin/init)

Versions of packages birdfont depends on:
ii  fonts-roboto2:0~20160106-1
ii  libatk1.0-0 2.18.0-1
ii  libc6   2.21-7
ii  libcairo-gobject2   1.14.6-1
ii  libcairo2   1.14.6-1
ii  libfontconfig1  2.11.0-6.3
ii  libfreetype62.6.1-0.1
ii  libgdk-pixbuf2.0-0  2.32.3-1.2
ii  libgee-0.8-20.18.0-1
ii  libglib2.0-02.46.2-3
ii  libgtk-3-0  3.18.7-1
ii  libjavascriptcoregtk-3.0-0  2.4.9-3
ii  libnotify4  0.7.6-2
ii  libpango-1.0-0  1.38.1-1
ii  libpangocairo-1.0-0 1.38.1-1
ii  libsoup2.4-12.52.2-1
ii  libsqlite3-03.10.2-1
ii  libwebkitgtk-3.0-0  2.4.9-3
ii  libxmlbird1 1.2.0-1

Versions of packages birdfont recommends:
ii  unicode-data  8.0-3

birdfont suggests no packages.

-- debconf-show failed

-- debsums errors found:
prelink: /usr/bin/birdfont: Could not find one of the dependencies
prelink: /usr/bin/birdfont: at least one of file's dependencies has changed 
since prelinking
debsums: changed file /usr/bin/birdfont (from birdfont package)
prelink: /usr/bin/birdfont-autotrace: Could not find one of the dependencies
prelink: /usr/bin/birdfont-autotrace: at least one of file's dependencies has 
changed since prelinking
debsums: changed file /usr/bin/birdfont-autotrace (from birdfont package)
prelink: /usr/bin/birdfont-export: Could not find one of the dependencies
prelink: /usr/bin/birdfont-export: at least one of file's dependencies has 
changed since prelinking
debsums: changed file /usr/bin/birdfont-export (from birdfont package)
prelink: /usr/bin/birdfont-import: Could not find one of the dependencies
prelink: /usr/bin/birdfont-import: at least one of file's dependencies has 
changed since prelinking
debsums: changed file /usr/bin/birdfont-import (from birdfont package)
prelink: /usr/lib/x86_64-linux-gnu/libbirdfont.so.36.0: Could not find one of 
the dependencies
debsums: changed file /usr/lib/x86_64-linux-gnu/libbirdfont.so.36.0 (from 
birdfont package)
prelink: /usr/lib/x86_64-linux-gnu/libbirdgems.so.0.0: at least one of file's 
dependencies has changed since prelinking
debsums: changed file /usr/lib/x86_64-linux-gnu/libbirdgems.so.0.0 (from 
birdfont package)

Bug#750586: syslinux-common: Boot fails. Failed to load ldlinux.c32. File must be in /. Upstream bug

[Diretoria de Pós-Graduação - PRPPG - UFVJM]

Hi,

An iso-dvd (debian-testing-amd64-DVD-1.iso 2016-02-08 08:31) will be in the
same issue? Lack the ldlinux.c32 ?

Or I need to wait the maintainers to apply the patch?

My two notebook, different brand, have the same problem.

Thank you very much.

--
Marcelo

Bug#814531: CAFF: signing on airgapped machines

[Guilhem Moulin]

On Fri, 12 Feb 2016 at 15:34:27 +0100, Lachlan Gunn wrote:
> I am interested in using CAFF on an airgapped machine, which at the
> moment is somewhat non-obvious. If I can find the time, I would like to
> develop some kind of CSR-like workflow, would others be interested in this?
 
> The kind of workflow that I was thinking of would go something like this:
> 
> [connected machine]
> caff --write-csr csr.tar.gz 

The gzipped tarball format looks really overkill.  How about an OpenPGP
keyring (possibly armored)?  No need for caff here, gpg(1) can do this
alone:

  gpg --export  >/tmp/keyring.gpg

(you could also add ‘--export-options export-minimal’)
 
> [airgapped machine]
> caff --sign-csr csr.tar.gz --output csr.signed.tar.gz

Then it's just

  caff --key-file /tmp/keyring.gpg 
 
> [connected machine]
> caff --mail-from-csr csr.signed.tar.gz

I guess this is the most cumbersome step with the current workflow,
since one needs to export the signed keys from caff's own GNUPGHOME.
How about an option ‘--signed-key-file’ (and ‘--lsigned-key-file’ for
local sigs)?  Caff would export all signed keys in the specified file.
Then on the online machine, you could run

  caff -SR --key-file /tmp/signed-keyring.gpg 

-- 
Guilhem.


signature.asc
Description: PGP signature

Bug#810379: [Xen-devel] [BUG] pci-passthrough generates "xen:events: Failed to obtain physical IRQ" for some devices

[Tommi Airikka]

Yes, you can put the 'Tested-by' from me, I'm perfectly fine with that.

Thank you for your help!

Br,
Tommi
On Fri, Feb 05, 2016 at 12:35:10AM +0100, Tommi Airikka wrote:
> Hi,
>
> I patched the deb8u2 source with all four patches and built a new deb.
.. snip..
>
> Next, I upgraded dom0 with the new linux-image deb and rebooted the
machine.
>
> dom0 "uname -a":
> Linux dom0 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt20-1+deb8u2a~test
> (2016-02-04) x86_64 GNU/Linux
>
> domU 'bug' "uname -a":
> Linux bug 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt20-1+deb8u2a~test
> (2016-02-04) x86_64 GNU/Linux
>
> And now everything seems to work. No more "Failed to obtain physical IRQ",
> I can mount my usb flash stick using the passthroughed usb controller. No
> call traces in dmesg.

Awesome!

Are you OK if I put 'Tested-by' on the patches from you?

Bug#768772: What is the status of the packaging ‘xkcdpass’?

[Ben Finney]

On 12-Feb-2016, Ghislain Vaillant wrote:
> Any news from this submission ?

The package has been examined and it's ready for upload, but still
needs a Debian Developer to sponsor its upload.

The initial release is now at ‘mentors.debian.net’ again, seeking a
sponsor https://mentors.debian.net/package/xkcdpass>.

A newer upstream version exists, but the 1.2.3-1 release works fine
now and can be uploaded without further work. Do you know a Debian
Developer who can help?

-- 
 \“That's the essence of science: Ask an impertinent question, |
  `\and you're on the way to the pertinent answer.” —Jacob |
_o__) Bronowski, _The Ascent of Man_, 1973 |
Ben Finney 


signature.asc
Description: PGP signature

Bug#722132: closed by Sylvestre Ledru (Bug#722132: fixed in iwyu 3.3-2)

[Anders Kaseorg]

On Thu, 11 Feb 2016, Paul Wise wrote:
> I'm imagining it Build-Depending on a package produced by llvm-defaults 
> rather than a version-specific package.
> 
> Not building with any version other than 3.7 sounds like a bug too.

Alright, well, that’s just how it works upstream.  The documentation says 
that iwyu “makes heavy use of Clang internals, and will occasionally break 
when Clang is updated”.  The project home page says that the last seven 
upstream releases have been tied to llvm+clang 2.9, 3.0, 3.3, 3.4, 3.5, 
3.6, and 3.7, respectively.  Meanwhile, I would like to get this very 
simple bug solved without attempting to shave the entire upstream clang 
internal API compatibility yak stack.  What do you propose?

Anders

Bug#813232: debootstrap: Two-staged bootstrapping with --second-stage broken

[Marco d'Itri]

On Feb 06, Marco d'Itri  wrote:

> > Since the content of /dev is architecture independent, a possible fix 
> > would be to move the call to setup_devices() in every release script 
> > from the very beginning of the second stage to the very end of the first 
> > stage.
> The attached untested patch attempts to do this.
So, does anybody mind if I NMU with this patch?

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Bug#814550: RFS: codecrypt/1.7.3-1 (ITP #814462)

[Miroslav Kratochvil]

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

 * Package name: codecrypt
   Version : 1.7.3-1
   Upstream Author : Mirek Kratochvil 
 * URL : https://github.com/exaexa/codecrypt
 * License : LGPL3
   Section : utils

It builds those binary packages:

  codecrypt  - post-quantum encryption&signing tool

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

  http://mentors.debian.net/package/codecrypt


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

  dget -x 
http://mentors.debian.net/debian/pool/main/c/codecrypt/codecrypt_1.7.3-1.dsc


More information about codecrypt can be obtained from the quick README on the
GitHub page (see URL). The software is a simplified post-quantum-only workalike
of GnuPG, useful mainly for working with some non-mainstream and non-RSA crypto
in a human-friendly way. Debianization process is watched in github issue #10.


With regards,
 Mirek Kratochvil

Bug#814403: ckeditor: FTBFS: /usr/bin/ckbuilder: 2: /usr/bin/ckbuilder: Syntax error: Unterminated quoted string

[Dmitry Smirnov]

On Fri, 12 Feb 2016 12:43:47 AM Chris Lamb wrote:
> The Reproducible Builds can also reproduce it in the same way; the log
> there should contain enough detail:
> 
>  
> https://reproducible.debian.net/rbuild/unstable/amd64/ckeditor_4.5.6+dfsg-> 
> 1.rbuild.log

Thank you. I also found the following build log:

   https://tests.reproducible-builds.org/rb-pkg/unstable/amd64/ckeditor.html

From build logs I could not find a slightest difference. I've never seen this 
error on my side and package builds reliably. I can't think of anything that 
could cause the problem. It seems to be one of those weird problems with 
build environment but I'm unable to identify the culprit...

-- 
Best wishes,
 Dmitry Smirnov.

---

No person, no idea, and no religion deserves to be illegal to insult,
not even the Church of Emacs.
-- Richard Stallman


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

Bug#814549: ITP: osmose-emulator -- Sega Master System and Game Gear console emulator

[Carlos Donizete Froes]

Package: wnpp
Severity: wishlist
Owner: Carlos Donizete Froes 

* Package name: osmose-emulator
  Version : 0.9.96
  Upstream Author : Bruno Vedder 
* URL : http://bcz.asterope.fr/osmose.htm
* License : GPL-3+
  Programming Lang: C++
  Description : Sega Master System and Game Gear console emulator

 A multi-machine emulator for platforms of Sega consoles
 (Master System and Game Gear) and compatible for all games.
 .
 Simulates hardware extremely accurately which ensures that these
 classic games are represented exactly like they were on the real systems.
 .
 Osmose owns a clean graphical user interface based on QT and easy setup
 understand. It is not necessary to unpack the zip roms that will work.
 Support in archive format: SMS and GG.

Bug#814548: RFS: todotxt-cli/2.10-2

[Ondrej Novy]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "todotxt-cli"

* Package name: todotxt-cli
  Version : 2.10-2
  Upstream Author : Gina Trapani 
* URL : http://todotxt.com/
* License : GPL-3+
  Section : misc

  It builds those binary packages:

todotxt-cli - simple and extensible shell script for managing todo.txt file

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

  http://mentors.debian.net/package/todotxt-cli


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

dget -x 
http://mentors.debian.net/debian/pool/main/t/todotxt-cli/todotxt-cli_2.10-2.dsc

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

  Changes since the last upload:

  * Removed wrong Vcs URLs.
  * Standards-Version is 3.9.7 now (no change).
  * Added generated upstream changelog.
  * Added Debian tests.
  * Fixed description (Closes: #814399).

  Regards,
   Ondřej Nový

Bug#814547: Fix FTBFS on s390x

[dann frazier]

Package: perftest
Version: 3.0+0.16.gb2f2e82-1
Severity: important
Tags: patch

In addition to the patch in #814537, the attached patch is needed to
fix building on s390x.
From: dann frazier 
Subject: [PATCH] perftest: Fix typos in s390x support

Commit 472171fbd5a8 added support for s390x systems, but it looks like the
changeset got corrupted between submit and commit, resulting in a compile
failure. The version on the mailing list looks fine:

http://www.spinics.net/lists/linux-rdma/msg19592.html

Signed-off-by: dann frazier 
Bug-Ubuntu: 1545010
Forwarded: http://www.spinics.net/lists/linux-rdma/msg33357.html
Last-Update: 2016-02-12

Index: perftest-3.0+0.9.g214990b/README
===
--- perftest-3.0+0.9.g214990b.orig/README
+++ perftest-3.0+0.9.g214990b/README
@@ -237,7 +237,7 @@ Special feature detailed explanation in
 ./configure --disable-verbs_exp
 make
 
- 6. In te x390x platform virtualized environment the results shown by package test applications can be incorrect.
+ 6. In the s390x platform virtualized environment the results shown by package test applications can be incorrect.
 
  7. perftest-2.3 release includes support for dualport VPI test - port1-Ethernet , port2-IB. (in addition to Eth:Eth, IB:IB)
 Currently, running dualport when port1-IB , port2-Ethernet still not working.
Index: perftest-3.0+0.9.g214990b/src/get_clock.c
===
--- perftest-3.0+0.9.g214990b.orig/src/get_clock.c
+++ perftest-3.0+0.9.g214990b/src/get_clock.c
@@ -205,7 +205,7 @@ static double proc_get_cpu_mhz(int no_cp
 double get_cpu_mhz(int no_cpu_freq_fail)
 {
 	#ifdef __s390x__
-	return sample_get_cpu_mgz();
+	return sample_get_cpu_mhz();
 	#else
 	double sample, proc, delta;
 	sample = sample_get_cpu_mhz();

Bug#814546: Fix problem with parallel builds

[Julián Moreno Patiño]

Source: opensips
Version: 2.1.1-1
Severity: important
Justification: fails to build from source

Hello,

Opensips fails to build from source in several arches due parallel issue.

Please apply the attached patch.

Kind regards,

-- 
Julián Moreno Patiño
Debian Developer
 .''`. Debian GNU/{Linux,KfreeBSD}
: :' : Free Operating Systems
`. `'  http://debian.org/
  `-   GPG Fingerprint:
C2C8 904E 314C D8FA 041D 9B00 D5FD FC15 6168 BF60
Registered GNU Linux User ID 488513
--- a/debian/rules	2015-08-28 02:18:08.0 -0500
+++ b/debian/rules	2016-02-12 15:23:36.928546090 -0500
@@ -189,8 +189,7 @@
 
 # support parallel compiling
 ifneq (,$(filter parallel=%,$(DEB_BUILD_OPTIONS)))
- NUMJOBS = $(patsubst parallel=%,%,$(filter parallel=%,$(DEB_BUILD_OPTIONS)))
- MAKEFLAGS += -j$(NUMJOBS)
+	NJOBS := -j $(patsubst parallel=%,%,$(filter parallel=%,$(DEB_BUILD_OPTIONS)))
 endif
 
 override_dh_auto_build:


signature.asc
Description: PGP signature

Bug#814539: [Pkg-bazaar-maint] Bug#814539: bzrtools: Uninstallable with current sid bzr and python-bzrlib (2.7.0-2)

[Vincent Ladeuil]

> Agustin Martin  writes:

> Package: bzrtools
> Version: 2.6.0-2
> Severity: serious
> Justification: uninstallable in sid

> Dear Maintainer,

> Seems that bzrtools needs upgrading for newer bzr package (2.7.0-2),

Fix pushed at
https://anonscm.debian.org/bzr/pkg-bazaar/bzrtools/unstable/ as revno
761

patch attached.

Tested locally with adt-run .// -U --- lxc -es adt-sid

Please upload ;)

Thanks in advance,

   Vincent

Using parent branch bzr+ssh://bzr.debian.org/bzr/pkg-bazaar/bzrtools/unstable/
=== modified file 'debian/changelog'
--- debian/changelog	2014-06-02 02:45:06 +
+++ debian/changelog	2016-02-12 20:12:51 +
@@ -1,3 +1,10 @@
+bzrtools (2.6.0-3) unstable; urgency=medium
+
+  * Drop checking compatibility via deps, this has failed for wrong
+reasons. Rely on Dep8 tests instead (Closes: #814539).
+
+ -- Vincent Ladeuil   Fri, 12 Feb 2016 20:57:32 +0100
+
 bzrtools (2.6.0-2) unstable; urgency=medium
 
   * debian/tests/control: Add Restrictions: allow-stderr

=== modified file 'debian/control'
--- debian/control	2014-01-13 18:41:04 +
+++ debian/control	2016-02-12 19:54:50 +
@@ -6,8 +6,7 @@
Andrew Starr-Bochicchio 
 Build-Depends: debhelper (>> 7.0.50~), python (>= 2.6.6-3)
 Build-Depends-Indep: bzr,
- python-bzrlib (<< 2.7.0),
- python-bzrlib (>= 2.6~),
+ python-bzrlib,
  python-bzrlib.tests,
  python-subunit,
  rsync
@@ -20,8 +19,7 @@
 
 Package: bzrtools
 Architecture: all
-Depends: bzr (<< 2.7.0),
- bzr (>= 2.6~),
+Depends: bzr,
  patch,
  ${misc:Depends},
  ${python:Depends}

HPSS calls: 5 (0 vfs) SmartSSHClientMedium(bzr+ssh://bzr.debian.org/)

Bug#813995: Affects D-Link DNS-320 NAS (Rev A1) in jessie

[Uwe Kleine-König]

Control: tag 813995 + jessie sid

Hello,

among the supported machines (i.e. those in flash-kernel's db) there is
only a single type affected by this bug. That is "D-Link DNS-320 NAS
(Rev A1)" which has the respective mtd partitions on nand.

IMHO this means we should fix jessie's flash-kernel, too. (Even if there
were no affected machine, I'd consider this.) Tagging accordingly.

Best regards
Uwe

Bug#814539: [Pkg-bazaar-maint] Bug#814539: bzrtools: Uninstallable with current sid bzr and python-bzrlib (2.7.0-2)

[Vincent Ladeuil]

> Agustin Martin  writes:

> Package: bzrtools
> Version: 2.6.0-2
> Severity: serious
> Justification: uninstallable in sid

> Dear Maintainer,

> Seems that bzrtools needs upgrading for newer bzr package (2.7.0-2),

Fix pushed at
https://anonscm.debian.org/bzr/pkg-bazaar/bzrtools/unstable/ as revno
761

patch attached.

Tested locally with adt-run -U, tests pass.

Please upload ;)

Thanks in advance,

   Vincent

Using parent branch bzr+ssh://bzr.debian.org/bzr/pkg-bazaar/bzrtools/unstable/
=== modified file 'debian/changelog'
--- debian/changelog	2014-06-02 02:45:06 +
+++ debian/changelog	2016-02-12 20:12:51 +
@@ -1,3 +1,10 @@
+bzrtools (2.6.0-3) unstable; urgency=medium
+
+  * Drop checking compatibility via deps, this has failed for wrong
+reasons. Rely on Dep8 tests instead (Closes: #814539).
+
+ -- Vincent Ladeuil   Fri, 12 Feb 2016 20:57:32 +0100
+
 bzrtools (2.6.0-2) unstable; urgency=medium
 
   * debian/tests/control: Add Restrictions: allow-stderr

=== modified file 'debian/control'
--- debian/control	2014-01-13 18:41:04 +
+++ debian/control	2016-02-12 19:54:50 +
@@ -6,8 +6,7 @@
Andrew Starr-Bochicchio 
 Build-Depends: debhelper (>> 7.0.50~), python (>= 2.6.6-3)
 Build-Depends-Indep: bzr,
- python-bzrlib (<< 2.7.0),
- python-bzrlib (>= 2.6~),
+ python-bzrlib,
  python-bzrlib.tests,
  python-subunit,
  rsync
@@ -20,8 +19,7 @@
 
 Package: bzrtools
 Architecture: all
-Depends: bzr (<< 2.7.0),
- bzr (>= 2.6~),
+Depends: bzr,
  patch,
  ${misc:Depends},
  ${python:Depends}

HPSS calls: 5 (0 vfs) SmartSSHClientMedium(bzr+ssh://bzr.debian.org/)

Bug#814544: Acknowledgement (wheezy-pu: package clamav/0.99+dfsg-0+deb7u1)

[Scott Kitterman]

Correct, not havp.  It's not in wheezy.

Bug#814545: lists.debian.org: Please remove me as an admin for debian-news-portuguese

[Gustavo Noronha Silva]

Package: lists.debian.org
Severity: normal

Hey,

It's been a while since I did any actual administration of the list,
I would like to stop receiving admin-related mail from it.

Thanks!

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

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

Bug#814544: wheezy-pu: package clamav/0.99+dfsg-0+deb7u1

[Scott Kitterman]

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

This is the follow-up to #807969 for wheezy.  Equivalent debdiff will be
attached as a reply to the bug (since it's huge) to make sure the doesn't get
blocked.

As with Jessie, this will require a small transition.  Clamav and libclamunrar
will both need source uploads (prepared) and will hit New due to bumped so
name. I'll file a separate bug for libclamunrar.  Additionally, four packages
will need binNMUs:

* c-icap-modules
* dansguardian
* havp
* python-clamav

These have all been tested by the team.

Scott K

Bug#814536: vsftpd: add dh_apport for vsftpd

[Jörg Frings-Fürst]

Hi Chris,

apport isn't in stretch/sid now.

So I close this bug.

CU
Jörg

-- 
New:
GPG Fingerprint: 63E0 075F C8D4 3ABB 35AB  30EE 09F8 9F3C 8CA1 D25D
GPG key (long) : 09F89F3C8CA1D25D
GPG Key: 8CA1D25D
CAcert Key S/N : 0E:D4:56

Old pgp Key: BE581B6E (revoked since 2014-12-31).

Jörg Frings-Fürst
D-54538 Bausendorf

Threema: SYR8SJXB

IRC: j_...@freenode.net
 j_...@oftc.net

My wish list: 
 - Please send me a picture from the nature at your home.




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

Bug#812513: please add E1M8b.wad to the doom-wad_*.deb package

[Stephen Kitt]

On Thu, 11 Feb 2016 19:18:26 +0100, Fabian Greffrath 
wrote:
> Am Sonntag, den 24.01.2016, 17:39 +0200 schrieb Alexandre Detiste:
> > maybe someone wants to play this level with freedoom?  
> 
> Hm, on the other hand one could argue that this map was clearly meant
> as a replacement for E1M8 of the original Doom and thus owners of the
> original version should get it added to their package.
> 
> If people want to play the map with Freedoom, they most probably have
> read about it somewhere and are able to figure out where to download it
> on their own. 
> 
> TL/DR: I think this map is really explicitely meant as an Addon to
> Doom, not Freedoom.

I agree. In addition, the E1M8 license isn't DFSG-free so we couldn't add it
to freedoom anyway...

There is one caveat that would need to be made explicit: the new E1M8 breaks
chocolate-doom. (Fabian, do you plan on packaging crispy-doom?)

Regards,

Stephen


pgp0NPyR3ZEe2.pgp
Description: OpenPGP digital signature

Bug#814508: initramfs-tools: bluetooth/hci fails

[Ben Hutchings]

Control: tag -1 moreinfo

On Fri, 2016-02-12 at 11:45 +0100, Stefano wrote:
> Package: initramfs-tools
> Version: 0.123
> Severity: normal
> 
> Dear Maintainer,
> 
> after upgrade initramfs-tools and initramfs-tools-core from 0.122 (and 
> others),
> this morning my bluetooth mouse doesn't work anymore.
> 
> Downgraded both to 0.122 (and reboot), the mouse works again.
> 
> With 0.123 the kde5 System Settings can't find a bluetooth device:
> 
> ~ <-su> # rfkill list
> 0: ideapad_wlan: Wireless LAN
> Soft blocked: yes
> Hard blocked: no
> 1: ideapad_bluetooth: Bluetooth
> Soft blocked: no
> Hard blocked: no
> 2: phy0: Wireless LAN
> Soft blocked: yes
> Hard blocked: no
>
>
> With 0.122 I have
> 
> ~ <-su> # rfkill list
> 0: ideapad_wlan: Wireless LAN
> Soft blocked: yes
> Hard blocked: no
> 1: ideapad_bluetooth: Bluetooth
> Soft blocked: no
> Hard blocked: no
> 2: phy0: Wireless LAN
> Soft blocked: yes
> Hard blocked: no
> 3: hci0: Bluetooth
> Soft blocked: no
> Hard blocked: no

Could you please send, for the initramfs generated by v0.123:

1. The output of 'lsinitramfs /boot/initrd.img-4.3.0-1-amd64'
2. The contents of '/run/initramfs/initramfs.debug' after booting with
   the additional kernel parameter 'debug'

And the same for the working initramfs generated by v0.122.

Ben.

-- 
Ben Hutchings
I say we take off; nuke the site from orbit.  It's the only way to be sure.

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

Bug#813852: ITP: knowl.js -- JavaScript library for transclusion of supplementary information

[Doug Torrance]

On Fri, 05 Feb 2016 18:13:19 -0500 Doug Torrance
 wrote:
> Package: wnpp
> Severity: wishlist
> Owner: Doug Torrance 
>
> * Package name : knowl.js
> Upstream Author : American Institute of Mathematics
> * URL : http://aimath.org/knowlepedia/
> * License : GPL-3+
> Programming Lang: JavaScript
> Description : JavaScript library for transclusion of supplementary
information
>
> Like the familiar hyperlink, knowls can be used to provide relevant,
> supplementary information and are referenced from within the body of a web
> page. But unlike the hyperlink, which simply takes you to a new web
page, the
> knowl conveniently serves up the information at your original location
with the
> click of a mouse button. With a similar click, the knowl then disappears.
>
> I plan to maintain knowl.js as a member of the Debian JavaScript Team.

Since it's been a week, I figured I would inquire...

Is uploading to mentors and opening an RFS bug CC'ed to the list the
correct way to request a sponsorship of a new JavaScript package?  I
know that some other teams have other methods (e.g., PET, SoB).

If it's merely that no one's had time to get around to it yet, then
that's fine too.  :)

Thanks!
Doug

P.S.  The packaging is also in git:
https://anonscm.debian.org/git/pkg-javascript/knowl.js.git

Bug#796752: libsres: could not bind to random port above [port]

[Raphaël]

Getting the same message with IRCnet, but not IPv6 related in my case.

Bug#814542: vnstat not starting on boot on device without Real-time Clock

[Linus Lüssing]

On Fri, Feb 12, 2016 at 07:58:35PM +0100, Linus Lüssing wrote:
> A quick and dirty solution would be to simply add the line 
> "Restart=on-failure"
> to the vnstat unit, I guess.

PS: And maybe, if that solution were chosen, adding a "RestartSec=10" there too
for a 10 seconds restart wait instead of the default 100ms wait.

Bug#813399: [Python-modules-team] Bug#813399: python-pip-whl: fails to upgrade from 'testing' - trying to overwrite /usr/share/python-wheels/six-1.10.0-py2.py3-none-any.whl

[Barry Warsaw]

On Feb 12, 2016, at 01:11 PM, Andreas Beckmann wrote:

>the Breaks+Replaces against python-six-whl are insufficiently versioned,
>that package was removed in six 1.10.0-3, it is still present in -2.

I'm not sure I can make piuparts cooperate for me locally, but it's obvious
the Replaces/Breaks for python-six-whl should be bumped to 1.10.0-2, so I am
going to upload python-pip 8.0.2-6 that fixes this.

Bug#813875: castxml: diff for NMU version 0.1+git20160202-1.1

[Gianfranco Costamagna]

Control: tags -1 pending

Hi Gert and Steve.
Since this bug is almost one week old, you are on the lowNMU threshold, and 
this is preventing insighttoolkit4 from being built
correctly on i386, I did wget the upstream fix and uploaded on unstable a few 
seconds ago.


Following the debdiff.

What I did was bascically:
wget 
https://github.com/CastXML/CastXML/commit/5cfebb0f904131d1df8e36fcb9c290.patch

add-patch 5cfebb0f904131d1df8e36fcb9c290.patch
and upload after tweaking the changelog.
(add-patch added three commented lines on the patch, I removed them).

cheers,

Gianfranco

debdiff
Description: Binary data

Bug#814543: ITP: asset-collector -- collect information about the used hardware/software

[Benjamin Drung]

Package: wnpp
Severity: wishlist
Owner: Benjamin Drung 

* Package name: asset-collector
  Version : 0.1
  Upstream Author : Benjamin Drung 
* URL : to be released on Github
* License : ISC
  Programming Lang: Python 3
  Description : collect information about the used hardware/software

The asset-collector gathers information about the hardware components in
the system, the installed software and the configuration of both. The
information is collected from various places like the Direct Media
Interface (DMI) table, the Intelligent Platform Management Interface
(IPMI) Field Replaceable Units (FRU), the kernel or the APT package
manager.

The collected information can be printed in different formats (JSON,
pprint, text) and/or transmitted via representational state transfer
(REST) to an asset management system.

The asset-collector tries to make every hardware component identifiable
by serial number for tracking the components and assisting return
merchandise authorization (RMA) processes. The collected information can
be used to get an overview of the hardware products and software
versions in use (in case they are transmitted to an asset management
system).

I started writing the asset-collector, because I found no other tool for
this purpose (correct me if I am wrong). I invite everyone who is
interested in this topic to join the project.

-- 
Benjamin Drung
System Developer
Debian & Ubuntu Developer

ProfitBricks GmbH
Greifswalder Str. 207
D - 10405 Berlin

Email: benjamin.dr...@profitbricks.com
URL:  http://www.profitbricks.com

Sitz der Gesellschaft: Berlin.
Registergericht: Amtsgericht Charlottenburg, HRB 125506B.
Geschäftsführer: Andreas Gauger, Achim Weiss.

Bug#814542: vnstat not starting on boot on device without Real-time Clock

[Linus Lüssing]

Package: vnstat
Version: 1.12-2
Severity: important

Dear Maintainer,

On an Alix board without an RTC I am currently having trouble to get vnstat 
running
on boot, I always get the following error:

-
$ systemctl status vnstat
● vnstat.service - vnStat network traffic monitor
   Loaded: loaded (/lib/systemd/system/vnstat.service; enabled)
   Active: failed (Result: exit-code) since Sa 2000-01-01 01:02:07 CET; 16 
years 1 months ago
 Docs: man:vnstatd(1)
   man:vnstat(1)
   man:vnstat.conf(5)
  Process: 466 ExecStart=/usr/sbin/vnstatd -n (code=exited, status=1/FAILURE)
 Main PID: 466 (code=exited, status=1/FAILURE)

Jan 01 01:02:06 nm-alix systemd[1]: Started vnStat network traffic monitor.
Jan 01 01:02:06 nm-alix vnstatd[466]: Info: Monitoring: eth0 (100 Mbit) eth1 
(100 Mbit) ppp0 (100 Mbit)
Jan 01 01:02:06 nm-alix vnstatd[466]: Error: Interface "eth0" has previous 
update date too much in the future, exiting. (1455245147 / 946684926)
Jan 01 01:02:07 nm-alix systemd[1]: vnstat.service: main process exited, 
code=exited, status=1/FAILURE
Jan 01 01:02:07 nm-alix systemd[1]: Unit vnstat.service entered failed state.
-

Starting vnstat manually ("$ systemctl start vnstat") works as at that time NTP 
has fetched
the correct time for me.

On embedded devices it is rather common to not have an RTC and with
ARM based devices running Debian on the rise, I thought I'd mark this
bug as "important".


I guess either vnstat should retry instead of exiting. And/or maybe the
neat, new dependancy system available thanks to systemd could be used.
The mysqld unit does something like that, e.g. units depending on it
will be started not after mysqld has started, but once mysqld reports
being ready to receive queries. This is done through 
"ExecStartPost=/usr/libexec/mysqld-wait-ready" in the mysqld unit.
Maybe something like that could be done with NTP and vnstat too?

A quick and dirty solution would be to simply add the line "Restart=on-failure"
to the vnstat unit, I guess.

Regards, Linus


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

Kernel: Linux 3.16.0-4-586
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 vnstat depends on:
ii  adduser  3.113+nmu3
ii  init-system-helpers  1.22
ii  libc62.19-18+deb8u2

vnstat recommends no packages.

Versions of packages vnstat suggests:
pn  vnstati  

-- no debconf information

Bug#807969: jessie-pu: package clamav/0.99+dfsg-0+deb8u1

[Adam D. Barratt]

On Wed, 2016-02-10 at 23:53 +0100, Sebastian Andrzej Siewior wrote:
> On 2016-02-03 23:05:27 [+], Adam D. Barratt wrote:
> > > Okay. Uploaded the current package which hits first s-p-u. I hope to be
> > > able to test the remaining two packages this weekend.
> > 
> > Thanks. It should end up in NEW, as libclamav7 doesn't exist in stable.
> > Once it does, we can ask the ftp-team to have a look.
> 
> So it took a longer than expected to test the remaining two. So from
> what I can tell here, python-pyclamav +  libc-icap-mod-clamav (libclamav
> inerface) seem still to work in s-p-u on i386.

Thanks for the update.

Regards,

Adam

Bug#807969: jessie-pu: package clamav/0.99+dfsg-0+deb8u1

[Adam D. Barratt]

On Wed, 2016-02-10 at 23:59 +0100, Sebastian Andrzej Siewior wrote:
> On 2016-02-10 20:08:51 [+], Adam D. Barratt wrote:
> > > > - dansguardian
[...]
> > Built and accepted.
> 
> Thank you. This was the last one. So it looks like we are done here :)

Next stop wheezy? :-)

Regards,

Adam

Bug#814540: Please enable TTY_PRINTK as module for debug

[Ben Hutchings]

Control: found -1 4.3.5-1

On Sat, 2016-02-13 at 02:25 +0900, Roger Shimizu wrote:
> Package: src:linux
> Version: 3.16.7-ckt20-1+deb8u3
> Severity: wishlist
> X-Debbugs-Cc: rogershim...@gmail.com
> 
> Dear Maintainer,
> 
> Please enable TTY_PRINTK as module.
> It's also requested in lists:
> - https://lists.debian.org/debian-kernel/2016/02/msg00034.html

This isn't suitable for jessie, but please go ahead with this change on
the master branch.

In fact, let's make it built-in - it's tiny, and I think we should use
it by default in the initramfs which means everyone will have it loaded
anyway.

Ben.

-- 
Ben Hutchings
I say we take off; nuke the site from orbit.  It's the only way to be sure.


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

Bug#812585: Acknowledgement (exim4: Exim crashing when comparing password created with "htpaswwd" without "-d" -- segmentation fault.)

[Andreas Metzler]

On 2016-02-08 Leszek Dubiel  wrote:

> I have cut down my report to bare minimum:



> # exim -be '${if crypteq{xxx}{aaa}{yes}{no}}'
> no


> # exim -be '${if crypteq{xxx}{$aaa}{yes}{no}}'
> Failed: unknown variable name "aaa"


> # exim -be '${if crypteq{xxx}{\$aaa}{yes}{no}}'
> Segmentation fault

Thanks for stripping this down. Afaict this is fixed by
http://git.exim.org/exim.git/commit/9dc2b215e83a63efa242f6acd3ab7af8b608e5a1
which is included in RC3.

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

Bug#814278: quassel-data contains a far outdated version of inxi

[Alf Gaida]

> Adding inxi to Suggests and creating a symlink to inxi on the other hand 
> seems reasonable to me.
> That way /sysinfo will work once you manually install inxi.
sounds good, full ack

-- 
Alf Gaida
BDBF C688 EFAD BA89 5A9F  464B CD28 0A0B 4D72 827C


pgpD3mlIUNR4h.pgp
Description: Digitale Signatur von OpenPGP

Bug#813916: transition: gdal

[Emilio Pozuelo Monfort]

On 12/02/16 18:52, Sebastiaan Couwenberg wrote:
> On 12-02-16 18:28, Emilio Pozuelo Monfort wrote:
>> On 06/02/16 17:43, Bas Couwenberg wrote:
>>> Package: release.debian.org
>>> For the Debian GIS team I'd like to transition to the recently released
>>> GDAL 1.11.4. Only the packages using C++ symbols need to be rebuilt.
>>>
>>> GDAL 2.0.2 was released along with 1.11.4, but we still don't have
>>> support for GDAL 2.0 in all reverse dependencies. Since the transition
>>> to GDAL 1.11.3, support for GDAL 2.0 was added to all reverse
>>> depedencies except Fiona [0]. Upstream has recently included changes for
>>> GDAL 2.0, but these differ from the initial GDAL 2.0 changes available
>>> as a patch in #802808. The improved GDAL 2.0 changes are entangled with
>>> other changes for the upcoming Fiona 1.7 release, which I've not been
>>> able to successfully backport. This will not be a blocker for the GDAL
>>> 2.0 transition, as discussed with the maintainer on the debian-gis list
>>> [1].
>>>
>>> Because the transition for GDAL 1.11.4 is ready now, I'd like to do that
>>> first before preparing the transition to GDAL 2.0. All reverse
>>> dependencies rebuilt successfully with GDAL 1.11.4, the summary of
>>> rebuilds is included below.
>>>
>>
>> This would get entangled with the openmpi transition, so it will have to 
>> wait.
>> After openmpi, I'm thinking about doing libpng, but we'll see.
> 
> Waiting for openmpi is no problem, but if the libpng transition is going
> to happen first, I think it's better to use that time the prepare the
> transition to GDAL 2.0 instead of 1.11.4. Last week the last blocker was
> resolved [0], so we're also pretty much ready to transition to GDAL 2.0.
> The 2.0 packages will have to pass the NEW queue again, because of the
> delay that will cause I've opted to transition to 1.11.4 which is ready now.
> 
> If you can confirm that the libpng transition is going to happen first,
> I'll upload the packages for GDAL 2.0 to experimental, and we can switch
> to that in unstable after the libpng transition and the new gdal has
> passed NEW.

Sure, let's do that.

Cheers,
Emilio

Bug#768772: What is the status of the packaging ?

[Ghislain Vaillant]

Any news from this submission ?

Ghis

Bug#813916: transition: gdal

[Sebastiaan Couwenberg]

On 12-02-16 18:28, Emilio Pozuelo Monfort wrote:
> On 06/02/16 17:43, Bas Couwenberg wrote:
>> Package: release.debian.org
>> For the Debian GIS team I'd like to transition to the recently released
>> GDAL 1.11.4. Only the packages using C++ symbols need to be rebuilt.
>>
>> GDAL 2.0.2 was released along with 1.11.4, but we still don't have
>> support for GDAL 2.0 in all reverse dependencies. Since the transition
>> to GDAL 1.11.3, support for GDAL 2.0 was added to all reverse
>> depedencies except Fiona [0]. Upstream has recently included changes for
>> GDAL 2.0, but these differ from the initial GDAL 2.0 changes available
>> as a patch in #802808. The improved GDAL 2.0 changes are entangled with
>> other changes for the upcoming Fiona 1.7 release, which I've not been
>> able to successfully backport. This will not be a blocker for the GDAL
>> 2.0 transition, as discussed with the maintainer on the debian-gis list
>> [1].
>>
>> Because the transition for GDAL 1.11.4 is ready now, I'd like to do that
>> first before preparing the transition to GDAL 2.0. All reverse
>> dependencies rebuilt successfully with GDAL 1.11.4, the summary of
>> rebuilds is included below.
>>
> 
> This would get entangled with the openmpi transition, so it will have to wait.
> After openmpi, I'm thinking about doing libpng, but we'll see.

Waiting for openmpi is no problem, but if the libpng transition is going
to happen first, I think it's better to use that time the prepare the
transition to GDAL 2.0 instead of 1.11.4. Last week the last blocker was
resolved [0], so we're also pretty much ready to transition to GDAL 2.0.
The 2.0 packages will have to pass the NEW queue again, because of the
delay that will cause I've opted to transition to 1.11.4 which is ready now.

If you can confirm that the libpng transition is going to happen first,
I'll upload the packages for GDAL 2.0 to experimental, and we can switch
to that in unstable after the libpng transition and the new gdal has
passed NEW.

[0]
https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=gdal-2.0;users=debian-...@lists.debian.org

Kind Regards,

Bas

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

Bug#813722: [Debichem-devel] Bug#813722: Bug#813722: aces3: FTBFS on powerpc

[Michael Banck]

On Fri, Feb 12, 2016 at 07:27:59PM +0200, Graham Inggs wrote:
> On 8 February 2016 at 23:31, Michael Banck  wrote:
> > Hi,
> >
> > On Mon, Feb 08, 2016 at 11:26:17PM +0200, Graham Inggs wrote:
> >> On 4 February 2016 at 19:52, Mattia Rizzolo  wrote:
> >> > your package FTBFS on powercpc on the buildds.
> >>
> >> The same happens with petsc, as soon as the mpi test programs are
> >> launched they use 100% cpu and stop responding.
> >> See bug #814183.
> >
> > Hrm, ok.  But clearly aces3 is more broken on newer MPIs and GCC5.
> >
> > I'm in contact with upstream now, and hopefully they try to reproduced
> > with gfortran-5.3 and openmpi-1.10.
> 
> FWIW, after several give-backs, aces3 built successfully on one of the
> Ubuntu powerpc buildds (full build log [1]).

Hrm, interesting.

> You can silence many of the warnings during the build by replacing:
> 
> OMPI_MCA_orte_rsh_agent=/bin/false
> 
> with:
> 
> OMPI_MCA_plm_rsh_agent=/bin/false

Right, I've done that now in svn, thanks.


Michael

Bug#790756: transition: libstdc++6 cxx11

[Emilio Pozuelo Monfort]

On 01/07/15 16:30, Matthias Klose wrote:

> This is the libstdc++6 cxx11 transition as outlined in [1].  It will trigger 
> up
> to 400 other transitions once GCC 5 is made the default (see [2] for the
> probably affected packages).

AFAICS none of the few remaining packages with RC transition bugs are in
testing. Thus I think we can close this now.

Thoughts?

Cheers,
Emilio

Bug#807742: developer-reference: Italian Translation

[Pierangelo Mancusi]

Dear Maintainer,

count_month=2;


Cheers,
Pierangelo

Bug#814540: Please enable TTY_PRINTK as module for debug

[Roger Shimizu]

Package: src:linux
Version: 3.16.7-ckt20-1+deb8u3
Severity: wishlist
X-Debbugs-Cc: rogershim...@gmail.com

Dear Maintainer,

Please enable TTY_PRINTK as module.
It's also requested in lists:
- https://lists.debian.org/debian-kernel/2016/02/msg00034.html

Thank you!

-- 
Roger Shimizu, GMT +9 Tokyo
PGP/GPG: 17B3ACB1