Bug#851341: ITP: python-bd2k -- general utility library for bd2k python package

[Steffen Möller]

Package: wnpp
Severity: wishlist
Owner: Steffen Moeller 

* Package name: python-bd2k
* URL : https://github.com/BD2KGenomics/bd2k-python-lib
* License : Apache
  Programming Lang: Python
  Description : general utility library for bd2k python package

The package is a 2nd degree dependency of the Toil workload distributor
expected in Debian any time soon. It is about to be group-maintained at
anonscm.debian.org/cgit/debian-med/python-bd2k

Bug#851305: onboard doesn't show any information in mate-session-properties

[shirish शिरीष]

at bottom :-

On 14/01/2017, Jeremy Bicha  wrote:
> On 13 January 2017 at 15:32, shirish शिरीष  wrote:
>> Onboard doesn't show/share any description when opened up in
>> mate-session-properties. Sharing a picture for the same. Look forward
>> to seeing this fixed.
>
> I thought /etc/xdg/autostart/onboard-autostart.desktop had
> NoDisplay=true set so you should not see it in the "Startup
> Applications" app or whatever MATE calls it.
>
> Thanks,
> Jeremy Bicha
>

While what you say is true, i.e. -

─[$] cat /etc/xdg/autostart/onboard-autostart.desktop | grep NoDisplay
 5  NoDisplay=true

But it's untrue that it is not displayed in MATE 'Startup Application
Preferences' as had shared  the screenshot yesterday.

Also, for sake for argument, why should it not be displayed ? It is a
legitimate service (for blind people hence accessibility) as well as
for people whose keyboard goes wonky (has happened once or twice in
the past) and not able to change keyboards in a jiffy. So it's a type
of self-insurance.

Also, it's part of the MATE universe so it should have a description
when it's installed, do know it comes from Priorty: 'optional' suite.

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

Bug#851340: vgimportclone: fails with duplicated volume group

[Brett Wuth]

Source: lvm2
Version: 2.02.111-2.2+deb8u1
Severity: normal
Tags: patch

Dear Maintainer,

vgimportclone's primary use is to import an attached media which is
has the same Volume Group as already exists.  Such a situation occurs
when attaching external media which is a backup (copy) of an existing
Physical Volume.

vgimportclone fails in such situations, with an error message like:

---cut---
root@arc:/# vgimportclone -vv /dev/loop0
...
 Duplicate PV V9fzvpn7u3cAnN8tLLKkd0FpzJLr on /dev/loop0 - using  
/dev/sda5
...
  Failed to find physical volume "/dev/loop0"
---cut---

The problem is that vgimportclone fails to detect that the device is a
Physical Volume, because 'pvs' rejects it because it has a duplicate
Volume Group.

The solution is to run 'pvs' with options to look only at the device
in question and ignore all other devices.  The following patch
accomplishes this fix:

---cut---
--- /sbin/vgimportclone 2016-05-27 03:08:32.0 -0600
+++ vgimportclone   2017-01-07 15:12:11.0 -0700
@@ -204,7 +204,7 @@
 do
 if [ -b "$ARG" ]
 then
-PVS_OUT=`"${LVM}" pvs ${LVM_OPTS} --noheadings -o vg_name "$ARG"`
+PVS_OUT=`"${LVM}" pvs ${LVM_OPTS} --config 'devices { filter = [ 
"a|^'$ARG'$|", "r|.*|" ] }' --noheadings -o vg_name "$ARG"`
 checkvalue $? "$ARG could not be verified to be a PV without errors."
 PV_VGNAME=$(echo $PVS_OUT | $GREP -v '[[:space:]]+$')
 [ -z "$PV_VGNAME" ] && die 3 "$ARG is not in a VG."
---cut---


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

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

Bug#848592: cable usbblaster ID 09fb:6001 Altera Blaster

[Geert Stappers]

Hello,

I did buy "in China" an Altera USBBlaster because it was cheap,
but it is becoming expensive.

`lsusb` shows 'Bus 001 Device 016: ID 09fb:6001 Altera Blaster'

In urtjag is the response on `cable usbblaster':
error: Couldn't connect to suitable USB device.
error: ftdi/ftd2xx error: ftdi_usb_open_desc() failed: device not found

So now I looking for messages like
* Works for me
* Works for me after ...addition_tweaking...
* Used to work, that was with version ...  and kernel ...



Groeten
Geert Stappers
-- 
Leven en laten leven

Bug#817521: libapache-mod-removeip: Removal of debhelper compat 4

[intrigeri]

Hi Micah,

Adrian Bunk:
> Can you anyway NMU this package?

> The alternative is that it will get removed from stretch soon.

Well, it's not a goal of mine to include as many packages in Stretch
as possible. So I really don't want to be the one who decides that
a given package will be part of a Debian stable release, if its
maintainers are not ready to support it there; in this case, I see
little indication that they are. (And backports are always an option
anyway :)

Micah, what do you think? If you're ready to support the package in
Stretch, I'm happy to give some one-shot help by NMU'ing it over the
week-end.

Cheers!

Bug#848316: [pkg-go] Bug#848316: etcd: I saw that A new upstream version is available: 3.0.15 - Is this possible to upgrade ?

[Dmitry Smirnov]

On Friday, 13 January 2017 1:57:33 PM AEDT TFAUCK wrote:
> So what do we do for that issue ?

Hopefully fix it eventually by updating "etcd" package...


> who's going to decide if there is a
> need for new package or just and upgrade ?

That would be me... :)
The matter is quite simple: if my understanding is correct, upstream no 
longer support Etcd v2... The question is only who is going to update the 
package and when.

Why do you think we need two packages and who is going to maintain 'em?

-- 
All the best,
 Dmitry Smirnov.


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

Bug#851339: fonts-firacode: package without source must not be in Debian

[Ben Finney]

Package: fonts-firacode
Version: 1.203-1
Severity: serious
Tags: upstream
Justification: Policy 2.1

Thank you for determining the absence of the source form for this
work; I see the comment in ‘debian/copyright’ added for this package
version, informing the reader the package in Debian does not have the
source form of the work.

Packages in Debian must be distributed with their entire corresponding
source form [0], so this package should not be in Debian. Because
building the work depends on other works that cannot be in Debian,
this package may be in the “contrib” archive section.


[0] , “Source missing”.

-- 
 \   “Working out the social politics of who you can trust and why |
  `\  is, quite literally, what a very large part of our brain has |
_o__)   evolved to do.” —Douglas Adams |
Ben Finney 


signature.asc
Description: PGP signature

Bug#850733: I confirm this bug

[Daniele Antonucci]

Hi All,

I would confirm this bug I am having the same issue:

Traceback (most recent call last):
  File "/usr/bin/reportbug", line 2233, in 
main()
  File "/usr/bin/reportbug", line 1107, in main
return iface.user_interface()
  File "/usr/bin/reportbug", line 2149, in user_interface
package, severity, mode, charset=charset, tags=tags)
  File "/usr/bin/reportbug", line 182, in handle_editing
editor, charset)
  File "/usr/lib/python3/dist-packages/reportbug/ui/gtk2_ui.py", line
1561, in func
op = klass(parent)
  File "/usr/lib/python3/dist-packages/reportbug/ui/gtk2_ui.py", line
539, in __init__
self.widget = self.create_widget()
  File "/usr/lib/python3/dist-packages/reportbug/ui/gtk2_ui.py", line
1173, in create_widget
expander = Gtk.Expander("Other system information")
TypeError: GObject.__init__() takes exactly 0 arguments (1 given)

I am using Debian Testing/Sid, kernel 4.8.0-2-amd64, and xfce4 4.12.3.
I would confirm also it's related with GTK in general, I switched from
a GTK3 theme to a GTK2 and the issue is always the one above.

Thanks,

Daniel

Bug#851026: ffmpeg: FTBFS: ffconf.bVIjAhhQ.c:2: undefined reference to `dlopen'

[Carl Eugen Hoyos]

The relevant lines in the build log are afaict:

src/libavformat/chromaprint.c: In function 'write_packet':
src/libavformat/chromaprint.c:113:1: error: control reaches end of non-void 
function [-Werror=return-type]
 }
 ^

The function looks like this:

static int write_packet(AVFormatContext *s, AVPacket *pkt)
{
ChromaprintMuxContext *cpr = s->priv_data;
return chromaprint_feed(cpr->ctx, pkt->data, pkt->size / 2) ? 0 : 
AVERROR(EINVAL);
}

I guess this is a compiler bug.

Carl Eugen

Bug#845784: RFS: dropwizard-metrics [ITP]

[Tobias Frost]

Am 4. Januar 2017 16:09:15 GMT+08:00 schrieb Christopher Hoskin 
:
>Dear Tobias and Tim,
>
>Tobias, thank you very much for your response - I'm afraid I've only
>just
>become aware of it. 
>
>> > Did you contact Tim? (CC'ed him with this mail; he still owns the
>ITP)
>
>No - as Tim placed this package under the maintainance of the pkg-java
>team
>I was following the pkg-java procedure [1]. Appologies if that wasn't
>the
>correct procedure to follow in this case.

You should have answered to the ITP, alone for transparency reasons and for 
avoiding that you syrup on each other's toes. (And also for the rest of Debian 
which is not part/aware of the Java procedures (I'm currently offline while 
writing this, so I could not check what it says. But I would be surprised if it 
says that normal Debian procedures can be ignored.)

>Since filing the RFS I've completed the DD application process, and now
>have
>upload rights. Prior to receiving Tim's e-mail, I went ahead and
>uploaded my
>package to the NEW queue [2]. However, as a new DD I still consider
>myself
>inexperienced, so any suggestions or corrections are gratefully
>received.

 Congrats!

>> I got seriously stuck packaging up dropwizard 
>
>Tim, do you recall what you got stuck with? Your package looked in good
>shape
>to my (inexperienced) eyes so I was surprised that it hadn't been
>uploaded. Did
>you find some show-stopper that I've overlooked? (I haven't attempted
>to build
>all of the modules, but I think it's considered acceptable for a
>pkg-java
>package to omit some tricky non-essential modules.)

Okay it's a new package... But still it seems to be the wrong order to upload 
first and then all later... 

>Thanks for your time.
>
>[1] https://pkg-java.alioth.debian.org/
>[2] https://ftp-master.debian.org/new/dropwizard-metrics_3.1.2-1.html
>
>Christopher


-- 
Tobias Frost
GPG fingerprint: 13C9 04F0 CE08 5E7C 3630 7985 DECF 849A A635 7FB7

Bug#851337: Desktop Integration Folder paths resets on upgrade

[duck]

Source: wine-development
Version: 2.0~rc4-1
Severity: minor
Control: found -1 2.0~rc2-1


Quack,

Since a few versions at least (but was away from gaming for some time), 
after the registry is upgraded when first running a new Wine version, my 
custom Desktop Integration paths are reset to default. Needless to say 
it is annoying.


I thought I made a mistake but for two version upgrades I paid 
attention, and had no configuration change except fixing the paths 
again.


Regards.
\_o<

--
Marc Dequènes

Bug#851336: python-schema-salad: man page consists of a traceback

[Daniel Shahaf]

Package: python-schema-salad
Version: 2.2.2017080227-1
Severity: important

Dear Maintainer,

The man page is broken:

[[[
% apt-get download python-schema-salad/sid 
Get:1 http://mirror.isoc.org.il/pub/debian/ sid/main python-schema-salad all 
2.2.2017080227-1 [228 kB]
% dpkg-deb --extract *.deb d 
% man d/usr/share/man/man1/schema-salad-tool.1.gz | cat 
:22: warning [p 1, 3.2i]: can't break line
SCHEMA-SALAD-TOOL2(1)User Commands   SCHEMA-SALAD-TOOL2(1)

NAME
   schema-salad-tool - Schema Annotations for Linked Avro Data (SALAD)

DESCRIPTION
   Traceback (most recent call last):
   ⋮
   ImportError: No module named ruamel.yaml

python2 2.2.2017080227   January 2017SCHEMA-SALAD-TOOL2(1)
]]]

Cheers,

Daniel

Bug#851335: apt: unable to fetch changelog while available

[duck]

Package: apt
Version: 1.0.9.8.4
Severity: minor


Quack,

# apt-get changelog libphp-phpmailer
Err Changelog for libphp-phpmailer 
(http://packages.debian.org/changelogs/pool/updates/main/libp/libphp-phpmailer/libphp-phpmailer_5.2.9+dfsg-2+deb8u3/changelog)

  404  Not Found [IP: 2001:41c8:1000:21::21:3 80]
Err Changelog for libphp-phpmailer 
(http://security.debian.org/pool/updates/main/libp/libphp-phpmailer/libphp-phpmailer_5.2.9+dfsg-2+deb8u3.changelog)

  404  Not Found [IP: 2001:a78:5:0:216:35ff:fe7f:be4f 80]

Nevertheless at that time I could read it using:
  
https://tracker.debian.org/media/packages/libp/libphp-phpmailer/changelog-5.2.9%2Bdfsg-2%2Bdeb8u3


So this is probably a problem with the old interface (and background 
scripts providing it), and maybe trying a third URL (using the new nice 
tracker) could work around this issue.


Regards
\_o<

--
Marc Dequènes

Bug#851334: ITP: magit-annex -- git-annex subcommands for magit

[Sean Whitton]

Package: wnpp
Severity: wishlist
Owner: Sean Whitton 

* Package name: magit-annex
  Version : 1.3.0
  Upstream Author : Kyle Meyer , Rémi Vanicat 

* URL : https://github.com/magit/magit-annex
* License : GPL-3+
  Programming Lang: Emacs Lisp
  Description : git-annex subcommands for magit

I intend to maintain this as part of the pkg-emacsen team.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#851333: ITP: git-annex-el -- Emacs integration for git-annex

[Sean Whitton]

Package: wnpp
Severity: wishlist
Owner: Sean Whitton 

* Package name: git-annex-el
  Version : 1.0+git20160215.e61ef24
  Upstream Author : John Wiegley 
* URL : https://github.com/jwiegley/git-annex-el/
* License : GPL-2+
  Programming Lang: Emacs Lisp
  Description : Emacs integration for git-annex

I intend to maintain this as part of the pkg-emacsen team.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#850108: needrestart: support python3

[Paul Wise]

On Fri, 2017-01-13 at 22:38 +0100, Thomas Liske wrote:

> this regex does match on /usr/bin/python3 since there is no
> end of string metacharacter ($). So it should not require any change in
> needrestart, shouldn't it?

Hmm, that is correct. Sorry for the noise. Could you test that it works
with python3 too and close the bug if it does work?

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#737016: Bug#834131: Video support still not working

[Steve Robbins]

On Friday, January 13, 2017 10:04:44 AM CST you wrote:

> Sorry for the delay!

That's no problem.  With Debian in freeze, I'm not in any hurry.


> If you are still interested please join the Qt/KDE team
> on alioth.

Done.

> Is qtav as repo name OK for you?

Sure.  

-S


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

Bug#851192: [Reportbug-maint] Bug#851192: reportbug: All UIs depend on python3 webbrowser which is failing with Bad magic number

[Scott Kitterman]

On Thu, 12 Jan 2017 15:48:51 -0500 Sandro Tosi  wrote:
> control: reassign -1 python3
> control: affects -1 reportbug
> 
> On Thu, Jan 12, 2017 at 3:44 PM, Akkana Peck  
wrote:
> > $ reportbug reportbug  ~/outsrc/stable-grep/grep-2.20/src
> > Traceback (most recent call last):
> >   File "/usr/bin/reportbug", line 43, in 
> > from reportbug import utils
> >   File "/usr/lib/python3/dist-packages/reportbug/utils.py", line 43, in 

> > from .urlutils import open_url
> >   File "/usr/lib/python3/dist-packages/reportbug/urlutils.py", line 33, in 

> > import webbrowser
> > ImportError: bad magic number in 'webbrowser': b'\x03\xf3\r\n'
> >
> >
> > Obviously this is a bug in python3's webbrowser module
> > (import webbrowser from the python3 console also fails).
> 
> that;s what is it: a bug in python3, so reassigning + affecting accordingly
> 
> > However, it's also a reportbug bug, because it makes reportbug
> > completely unusable with any UI. No matter whether I run reportbug
> > with -u text, -u gtk, or -u urwid, it dies with the same error.
> > Why is the text interface trying to call up the webbrowser module?
> 
> because UIs need to interact with URLs, and those are managed by the
> urlutils module, which import webbrowser. introducing conditional
> imports is a no go here

I can't reproduce this.  I tried reportbug on testing and it worked fine.  
Importing webbrowser works fine (on unstable too):

python3
Python 3.5.3rc1 (default, Jan  3 2017, 04:40:57)
[GCC 6.3.0 20161229] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import webbrowser
>>>

reassigning to libpython3.5-stdlib, since that's what provides webbrowser.  
Lowering severity since it's not consistently a problem.

Scott K

Bug#851332: xfce4-cpugraph-plugin: insane CPU use

[Adam Borowski]

Package: xfce4-cpugraph-plugin
Version: 1.0.5-1+b1
Severity: normal

To draw a tiny little widget, cpugraph takes:

  PID USER  PR  NIVIRTRESSHR S  %CPU %MEM TIME+ COMMAND
10912 kilobyte  20   0  158224  16436  11936 R  56.6  0.2  10:34.92 
panel-25-cpugra

The usage seems to increase if the system is loaded: 20ish% when the load is
a noise floor, more if there's something actually going on.  Not sure where
this could have come from -- both the update frequency and amount to draw is
the same whether you have near-zero noise or non-empty bars.


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

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

Versions of packages xfce4-cpugraph-plugin depends on:
ii  libatk1.0-0  2.22.0-1
ii  libc62.24-8
ii  libcairo21.14.8-1
ii  libfontconfig1   2.11.0-6.7
ii  libfreetype6 2.6.3-3+b1
ii  libgdk-pixbuf2.0-0   2.36.3-1
ii  libglib2.0-0 2.50.2-2
ii  libgtk2.0-0  2.24.31-1
ii  libpango-1.0-0   1.40.3-3
ii  libpangocairo-1.0-0  1.40.3-3
ii  libpangoft2-1.0-01.40.3-3
ii  libxfce4ui-1-0   4.12.1-2
ii  libxfce4util74.12.1-3
ii  xfce4-panel  4.12.1-2

xfce4-cpugraph-plugin recommends no packages.

xfce4-cpugraph-plugin suggests no packages.

-- no debconf information

Bug#844943: python-bleach: FTBFS: Tests failures

[Pirate Praveen]

On Fri, 13 Jan 2017 10:58:28 -0500 Barry Warsaw  wrote:
> Apologies.  Tags pushed.  Let me know when you have a repo or branch for me to
> test and I will do QA on pip and friends.

I have pushed it to https://git.fosscommunity.in/praveen/html5lib

Though two tests are failing because of deprecated usage. Can you try to
fix it? I don't know much of python :(

PYBUILD_TEST_ARGS="py.test" dh_auto_test --buildsystem=pybuild
I: pybuild base:184: py.test
= test session starts
==
platform linux2 -- Python 2.7.13, pytest-3.0.5, py-1.4.32, pluggy-0.4.0
rootdir: /<>, inifile:
plugins: expect-1.1.0
Testing tree builders cElementTree ElementTree lxml DOM
Testing tree walkers PullDOM DOM lxml_native cElementTree genshi ElementTree
collected 25977 items / 2 errors

 ERRORS

__ ERROR collecting html5lib/tests/test_sanitizer.py
___
/usr/lib/python2.7/dist-packages/_pytest/runner.py:163: in __init__
self.result = func()
/usr/lib/python2.7/dist-packages/_pytest/main.py:464: in _memocollect
return self._memoizedcall('_collected', lambda: list(self.collect()))
/usr/lib/python2.7/dist-packages/_pytest/main.py:335: in _memoizedcall
res = function()
/usr/lib/python2.7/dist-packages/_pytest/main.py:464: in 
return self._memoizedcall('_collected', lambda: list(self.collect()))
/usr/lib/python2.7/dist-packages/_pytest/python.py:412: in collect
return super(Module, self).collect()
/usr/lib/python2.7/dist-packages/_pytest/python.py:326: in collect
res = self.makeitem(name, obj)
/usr/lib/python2.7/dist-packages/_pytest/python.py:338: in makeitem
collector=self, name=name, obj=obj)
/usr/lib/python2.7/dist-packages/_pytest/vendored_packages/pluggy.py:745:
in __call__
return self._hookexec(self, self._nonwrappers + self._wrappers, kwargs)
/usr/lib/python2.7/dist-packages/_pytest/vendored_packages/pluggy.py:339:
in _hookexec
return self._inner_hookexec(hook, methods, kwargs)
/usr/lib/python2.7/dist-packages/_pytest/vendored_packages/pluggy.py:334:
in 
_MultiCall(methods, kwargs, hook.spec_opts).execute()
/usr/lib/python2.7/dist-packages/_pytest/vendored_packages/pluggy.py:613:
in execute
return _wrapped_call(hook_impl.function(*args), self.execute)
/usr/lib/python2.7/dist-packages/_pytest/vendored_packages/pluggy.py:250:
in _wrapped_call
wrap_controller.send(call_outcome)
/usr/lib/python2.7/dist-packages/_pytest/python.py:197: in
pytest_pycollect_makeitem
res = list(collector._genfunctions(name, obj))
/usr/lib/python2.7/dist-packages/_pytest/python.py:360: in _genfunctions
Function = self._getcustomclass("Function")
/usr/lib/python2.7/dist-packages/_pytest/main.py:280: in _getcustomclass
cls = getattr(self, name)
/usr/lib/python2.7/dist-packages/_pytest/main.py:197: in fget
PendingDeprecationWarning, stacklevel=2)
E   PendingDeprecationWarning: This usage is deprecated, please use
pytest.Function instead
_ ERROR collecting html5lib/tests/test_treeadapters.py
_
/usr/lib/python2.7/dist-packages/_pytest/runner.py:163: in __init__
self.result = func()
/usr/lib/python2.7/dist-packages/_pytest/main.py:464: in _memocollect
return self._memoizedcall('_collected', lambda: list(self.collect()))
/usr/lib/python2.7/dist-packages/_pytest/main.py:335: in _memoizedcall
res = function()
/usr/lib/python2.7/dist-packages/_pytest/main.py:464: in 
return self._memoizedcall('_collected', lambda: list(self.collect()))
/usr/lib/python2.7/dist-packages/_pytest/python.py:412: in collect
return super(Module, self).collect()
/usr/lib/python2.7/dist-packages/_pytest/python.py:326: in collect
res = self.makeitem(name, obj)
/usr/lib/python2.7/dist-packages/_pytest/python.py:338: in makeitem
collector=self, name=name, obj=obj)
/usr/lib/python2.7/dist-packages/_pytest/vendored_packages/pluggy.py:745:
in __call__
return self._hookexec(self, self._nonwrappers + self._wrappers, kwargs)
/usr/lib/python2.7/dist-packages/_pytest/vendored_packages/pluggy.py:339:
in _hookexec
return self._inner_hookexec(hook, methods, kwargs)
/usr/lib/python2.7/dist-packages/_pytest/vendored_packages/pluggy.py:334:
in 
_MultiCall(methods, kwargs, hook.spec_opts).execute()
/usr/lib/python2.7/dist-packages/_pytest/vendored_packages/pluggy.py:613:
in execute
return _wrapped_call(hook_impl.function(*args), self.execute)
/usr/lib/python2.7/dist-packages/_pytest/vendored_packages/pluggy.py:250:
in _wrapped_call
wrap_controller.send(call_outcome)
/usr/lib/python2.7/dist-packages/_pytest/python.py:197: in
pytest_pycollect_makeitem
res = list(collector._genfunctions(name, obj))
/usr/lib/python2.7/dist-packages/_pytest/python.py:360: in _genfunctions
Function = self._getcustomclass("Function")
/usr/lib/python2.7/dist-packages/_pytest/main.py:280: in _getcustomclass
cls = getattr(self, name)

Bug#843848: ifupdown2: diversion handling broken

[Julien Fortin]

Hi Andreas,

Thanks for reporting this issue.

Sorry again, for the delay. As I was saying I didn't see your email when I
got back from my new year vacations.
I added Roopa to the conversation.

You always want to install the diversion - it's a no-op if it is already
> there.
>

Ack. I thought I just needed to divert existing/installed files. See patch
bellow.

diff --git a/debian/ifupdown2.preinst b/debian/ifupdown2.preinst
index 07fc073..eddf429 100644
--- a/debian/ifupdown2.preinst
+++ b/debian/ifupdown2.preinst
@@ -3,7 +3,7 @@
 MYNAME="${0##*/}"

 report() { echo "${MYNAME}: $*" ; }
-report_err() { report "Error: $*" >&2 ; }
+report_err() { report "Error: $*" >&2 ; exit 1; }

 preinst_divert()
 {
@@ -12,13 +12,7 @@ preinst_divert()
 then
 report_err "existing diversion for $1"
 else
-if [ -e "$1" ] || [ -L "$1" ];
-then
-if [ $(dpkg-query -L ifupdown2 | grep "^$1$" | wc -l) -eq 0 ];
-then
-dpkg-divert --add --package ifupdown2 --rename --divert
"$1.disabled" "$1"
-fi
-fi
+dpkg-divert --add --package ifupdown2 --rename --divert
"$1.disabled" "$1"
 fi
 }

On Mon, Jan 2, 2017 at 5:21 PM, Andreas Beckmann  wrote:

> Control: found -1 1.0~git20161221-1
>
> Hi,
>
> most of the issues are fixed, but one is remaining:
>
> On 2016-11-11 21:09, Julien Fortin wrote:
> >> 2. unconditionally install the diversions, installing bash-completion
> >> after ifupdown2 breaks right now with a file overwrite error since the
> >> diversions are not in place (this is how I noticed the problems)
> >>
> >
> > I tried to reinstall bash-completion, didn't see any issue.
> > Then remove + install, didn't see any issues.
> > Can you please provide me the steps you are following?
>
> remove bash-completion
> install ifupdown2
> install bash-completion
>
> (best test this in a fresh minimal chroot)
>
>
> looking at ifupdown.preinst, I marked the wrong (i.e. superfluous) lines
> with #!!:
>
> preinst_divert()
> {
> diversions=$(dpkg-divert --list | grep "$1" | grep -v 'by ifupdown2$'
> | wc -l 2> /dev/null)
> if [ "$diversions" -gt 0 ];
> then
> report_err "existing diversion for $1"
> else
> #!!if [ -e "$1" ] || [ -L "$1" ];
> #!!then
> #!!if [ $(dpkg-query -L ifupdown2 | grep "^$1$" | wc -l) -eq 0
> ];
> #!!then
> dpkg-divert --add --package ifupdown2 --rename --divert
> "$1.disabled" "$1"
> #!!fi
> #!!fi
> #!!fi
> }
>
> You always want to install the diversion - it's a no-op if it is already
> there.
> You don't want to install the diversion only if a conflicting file is
> already present,
> but also to take care for the conflicting file to be installed later.
>
> And I'm pretty sure that you are missing an 'exit 1' in the
> report_err function - there is no point in continuing the
> installation if the system is in a broken state.
>
>
> Andreas
>

Bug#851331: file: error message gets written to stdout, not stderr, and exit code is still 0

[Jon Forsberg]

Package: file
Version: 1:5.22+15-2
Severity: important

Dear Maintainer,

file -b --mime-type NONEXISTING_FILE > mimetype.txt && echo "success"

will print "success" even though NONEXISTING_FILE does not exist, and
the string "cannot open `NONEXISTING_FILE' (No such file or directory)"
will be written to mimetype.txt, and nothing will be printed to
stderr.

What I expected:
Nothing be written to mimetype.txt, an error message be written to
stderr, "success" not be printed.

-- System Information:
Distributor ID: Raspbian
Description:Raspbian GNU/Linux 8.0 (jessie)
Release:8.0
Codename:   jessie
Architecture: armv7l

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

Versions of packages file depends on:
ii  libc6  2.19-18+deb8u1
ii  libmagic1  1:5.22+15-2
ii  zlib1g 1:1.2.8.dfsg-2

file recommends no packages.

file suggests no packages.

-- no debconf information

Bug#848839: AppStream metadata for Wine

[Jens Reyer]

Thanks again, also for the quick update of the documentation!

On 01/13/2017 06:26 PM, Matthias Klumpp wrote:
>>> P.S: Let me know when an updated Wine is uploaded, this will be the
>>> only app I know which does not use the metainfo file to augment a
>>> .desktop file, and I am curious to see if the file is handled
>>> correctly.

Just done, wine 1.8.6-2.

appstreamcli fails with a warning:
~
$ appstreamcli validate debian/org.winehq.wine.appdata.xml
W - org.winehq.wine.appdata.xml:org.winehq.wine:3
Component id belongs to a desktop-application, but does not resemble
the
.desktop file name: "org.winehq.wine"

Validation failed.
~

Now I'm curious if that works :)

Greets
jre

Bug#756522: ***SPAM*** Parcel ID5634528 delivery problems, please review

[USPS Delivery]

Dear Customer,

Your parcel was successfully delivered January 12 to USPS Station, but our 
courier cound not contact you.

You can find more details in this e-mail attachment!

Sincerely,
Fernando Page,
USPS Delivery Manager.


The WatchGuard Firebox that protects your network has detected a message that 
may not be safe.

Cause : The file type may not be safe.
Content type : application/zip
File name: Undelivered-Parcel-ID-5634528.doc.wsf
Status   : File Name violation
Action   : The Firebox deleted Undelivered-Parcel-ID-5634528.doc.wsf.

Your network administrator can not restore this attachment.

Bug#850421: libsqlcipher0: qTox segfaults with distro provided libsqlcipher0

[Vincent Pelletier]

On Fri, 13 Jan 2017 20:53:51 +0100, Hans-Christoph Steiner
 wrote:
> It would be good to get 3.4.0 included, perhaps that will help.

On the version topic, I was susprised the sqlcipher command reports a
version very different from the debian package (which I could
reproduce with the older package too):

  $ dpkg -l "*sqlcipher*"
  [...]
  ii  libsqlcipher0:amd64 3.2.0-1.1+b2 amd64
SQLCipher shared library
  ii  sqlcipher   3.2.0-2  amd64
Command line interface for SQLCipher

  $ sqlcipher test.sqlite
  SQLCipher version 3.8.6 2014-08-15 11:46:33

Maybe this is just sqlcipher being internally inconsistent ?

> I'm currently not using sqlcipher on the desktop at all, so I'm not well
> positioned to do this work.  I can definitely review and upload changes.

FWIW, reproducing the crash is trivial:

$ sqlcipher test.sqlite
sqlite> pragma key = "abcd";
sqlite> create table foo (bar int);
(Segfaults here)

Note: this is a different stack than what I got when (at least) skrooge
crashes, but it should only be skrooge reading from existing database
and this nutshell example creating one.

As for a fix, I am too unfamiliar with openssl to understand what is
supposed to be done (and I have a hard time digesting the idea that
there are so many initialisation functions, several not bothering to
signal errors to their caller... WTF ?).

All I could understand is that no loaded engine (I have rdrand and
dynamic) accept to handle cipher with nid 427 (ie, NID_aes_256_cbc, or
one of the most common ciphers around).
Naïvely trying to call a few init/load_all_* functions from inside gdb
and trying to fetch the engine again, without success.

Side note: debugging sqlite and (by extension) sqlcipher as packaged
relies on re-generating the same "sqlite3.c" as the one which was
compiled, which puzzled me for a while. Would it be a good
idea/debian-compliant/possible at all to somehow include the generated
file in what is retrieved by "apt-get source" ?
-- 
Vincent Pelletier

Bug#851330: truffle-dsl-processor: Package recent releases

[Miguel Landaeta]

Package: src:truffle-dsl-processor
Version: 0.6-2
Severity: wishlist

The version of truffle-dsl-processor available in the archive
is not enough to build the high-performance implementation of Ruby
using Truffle, available in recent releases of jruby 9.1.x.x.

I'll take care of it unless someone beat me to it.


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

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

-- 
Miguel Landaeta, nomadium at debian.org
secure email with PGP 0x6E608B637D8967E9 available at http://miguel.cc/key.
"Faith means not wanting to know what is true." -- Nietzsche


signature.asc
Description: Digital signature

Bug#851329: truffle: Package recent versions

[Miguel Landaeta]

Package: src:truffle
Version: 0.6-2
Severity: wishlist

The version of truffle available in the archive is not enough to
build the high-performance implementation of Ruby using Truffle,
available in recent releases of jruby 9.1.x.x.

I'll take care of it unless someone beat me to it.


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

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

-- 
Miguel Landaeta, nomadium at debian.org
secure email with PGP 0x6E608B637D8967E9 available at http://miguel.cc/key.
"Faith means not wanting to know what is true." -- Nietzsche


signature.asc
Description: Digital signature

Bug#844165: virtualbox: Virtualbox & guests windows moving "alone" when mouse pointer moves.

[Awtul]

Package: virtualbox
Version: 5.1.12-dfsg-2
Followup-For: Bug #844165

Dear Maintainer,

You may want to check https://gitlab.com/o9000/tint2/issues/619

The issue discussed there still present with Virtualbox 5.1.12-dfsg-2, only 
reproducible
combining openbox+tint2+virtualbox.

Regards,
Awtul

Bug#851328: invokebinder: Package recent releases

[Miguel Landaeta]

Package: src:invokebinder
Version: 1.5-1
Severity: normal

The version of invokebinder available in the archive is not enough to
build jruby 9.1.6.0, so it must be updated.

I'll take care of it unless someone beat me to it.


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

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

-- 
Miguel Landaeta, nomadium at debian.org
secure email with PGP 0x6E608B637D8967E9 available at http://miguel.cc/key.
"Faith means not wanting to know what is true." -- Nietzsche


signature.asc
Description: Digital signature

Bug#851327: debian-edu-install: [INTL:fr] French debconf translation

[jean-pierre giraud]

Package: debian-edu-install
Severity: wishlist
Tags: patch l10n

Hi!

Please find attached the french translation, proofread
by the debian-l10n-french mailing list contributors.

This file should be put as debian/po/fr.po in your package build tree.

Kind Regards

jipege


fr.po.gz
Description: application/gzip

Bug#849242: Virtualbox unusable under Openbox if autohide is enabled for tint2 panel.

[Awtul]

Package: openbox
Version: 3.6.1-4
Followup-For: Bug #849242

Dear Maintainer,

You may want to check https://gitlab.com/o9000/tint2/issues/619

Regards,

Awtul

Bug#841257: fixed in sendmail 8.15.2-7

[Moritz Mühlenhoff]

On Thu, Dec 08, 2016 at 07:11:27PM +0100, Andreas Beckmann wrote:
> On 2016-12-08 16:46, Axel 'the C.L.A.' Müller wrote:
> > Seems to work fine - at least I'm not getting those mails anymore.
> 
> I've now implemented a different way to aquire lockfiles for the
> cronjobs, let's hope that does work as well. Just uploaded to unstable.

Since this has settled a bit in unstable, could you also fix this
for the next jessie point release?

Cheers,
Moritz

Bug#851326: jnr-constants: Package recent releases

[Miguel Landaeta]

Package: src:jnr-constants
Version: 0.8.6-8
Severity: normal

The version of jnr-constants available in the archive is not enough to
build jruby 9.1.6.0, so it must be updated.

I'll take care of it unless someone beat me to it.


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

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

-- 
Miguel Landaeta, nomadium at debian.org
secure email with PGP 0x6E608B637D8967E9 available at http://miguel.cc/key.
"Faith means not wanting to know what is true." -- Nietzsche


signature.asc
Description: Digital signature

Bug#851325: jnr-unixsocket: Package recent releases

[Miguel Landaeta]

Package: src:jnr-unixsocket
Version: 0.8-1
Severity: normal

The version of jnr-posix available in the archive is not enough to
build jruby 9.1.6.0, so it must be updated.

I'll take care of it unless someone beat me to it.


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

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

-- 
Miguel Landaeta, nomadium at debian.org
secure email with PGP 0x6E608B637D8967E9 available at http://miguel.cc/key.
"Faith means not wanting to know what is true." -- Nietzsche


signature.asc
Description: Digital signature

Bug#850683: Merge duplicates

[Adrian Bunk]

Control: reassign -1 gerbv
Control: forcemerge 851190 -1
Control: severity 851190 serious
Control: affects 851190 src:pcb2gcode

The discussion regarding the fix is in #851190.

cu
Adrian

-- 

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

Bug#851324: python-debian: migrate to standard ‘unittest’ for test suite discovery

[Ben Finney]

Package: python-debian
Version: 0.1.29
Severity: minor
Control: tags -1 + patch

The test suite does not appear to use any ‘nose’ features that are not
already in the standard library ‘unittest’ module as of Python 2.7.
The dependency on ‘nose’ is evidently only to do automatic test suite
discovery.

The dependency on ‘nose’ can be removed, by migrating to use the
standard ‘unittest’ test suite discovery.

My proposed implementation for this is at
,
the ‘wip/maintenance/unittest’ branch.

-- 
 \ “I wish I had a dollar for every time I spent a dollar, because |
  `\   then, yahoo!, I'd have all my money back.” —Jack Handey |
_o__)  |
Ben Finney 


signature.asc
Description: PGP signature

Bug#851322: reportbug: bug script fails with non-ascii characters in reportbugrc

[Nis Martensen]

Package: reportbug
Version: 7.1.2
Severity: normal

Dear Maintainer,

Configure a realname with non-ascii characters, then try to report a
bug on reportbug itself with reportbug 7.1.2.

If you have no locale set, reportbug fails immediately. (But I'm not
sure this case should be supported. You really should have appropriate
locale settings if have non-ascii characters in your name...)  With
proper locale settings, only the bug script still fails:

Traceback (most recent call last):
  File "/usr/share/bug/reportbug/script", line 25, in 
for line in open(USERFILE, 'r'):
  File "/usr/lib/python3.5/encodings/ascii.py", line 26, in decode
return codecs.ascii_decode(input, self.errors)[0]
UnicodeDecodeError: 'ascii' codec can't decode byte 0xc3 in position 369: 
ordinal not in range(128)

This is because the bug script is executed with LC_ALL=C, so it can
only deal with ascii characters by default.

There are several options to fix this, among them:
  (a) execute the bug script in the user's locale -- this will affect
bug scripts of all packages, so it may break other bug scripts and
lead to localized output of others,
  (b) modify the reportbug bug script to cope with non-ascii characters,
for example like this:

@@ -4,7 +4,7 @@
 import os
 import re
 
-OUT=os.fdopen(3, 'w')
+OUT=os.fdopen(3, 'w', encoding='utf-8', errors='backslashreplace')
 
 envprint = False
 for var in ['EDITOR', 'PAGER', 'VISUAL', 'REPORTBUGEMAIL', 'DEBEMAIL', 'EMAIL',
@@ -22,7 +22,7 @@ if os.path.exists(USERFILE):
 if envprint:
 print(file=OUT)
 print('** %s:' % USERFILE, file=OUT)
-for line in open(USERFILE, 'r'):
+for line in open(USERFILE, 'r', encoding='utf-8', 
errors='backslashreplace'):
 line = line.strip()
 if line and not line.startswith('#'):
 m = passwdre.match(line)

Bug#851323: jnr-posix: Package recent releases

[Miguel Landaeta]

Package: src:jnr-posix
Version: 3.0.12-2
Severity: normal

The version of jnr-posix available in the archive is not enough to
build jruby 9.0.5.0, so it must be updated.

I'll take care of it unless someone beat me to it.


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

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

-- 
Miguel Landaeta, nomadium at debian.org
secure email with PGP 0x6E608B637D8967E9 available at http://miguel.cc/key.
"Faith means not wanting to know what is true." -- Nietzsche


signature.asc
Description: Digital signature

Bug#851320: trilinos: FTBFS on single-CPU machines (not enough slots available)

[Santiago Vila]

Well, I should better include the build log in the bug report.
Here it is:

https://people.debian.org/~sanvila/build-logs/trilinos/

The list of failed tests is too long:

The following tests FAILED:
 32 - TeuchosParameterList_FancyOutputting_test_MPI_4 (Failed)
 73 - TeuchosRemainder_SolverFactory_MPI_4 (Failed)
 93 - RTOp_SPMD_apply_op_UnitTests_parallel_MPI_4 (Failed)
 94 - RTOp_SPMD_apply_op_UnitTests_parallel_dump_rtops_MPI_4 (Failed)
 95 - RTOp_testLapackWrappers_0_MPI_4 (Failed)
 96 - RTOp_testLapackWrappers_1_MPI_4 (Failed)
 97 - RTOp_testLapackWrappers_2_MPI_4 (Failed)
 98 - RTOp_testLapackWrappers_3_MPI_4 (Failed)
101 - Sacado_FadCommTests_MPI_4 (Failed)
102 - Sacado_ELRFadCommTests_MPI_4 (Failed)
103 - Sacado_CacheFadCommTests_MPI_4 (Failed)
104 - Sacado_ELRCacheFadCommTests_MPI_4 (Failed)
105 - Sacado_TayCommTests_MPI_4 (Failed)
106 - Sacado_Fad_Kokkos_CommTests_Serial_MPI_4 (Failed)
379 - Triutils_read_test_MPI_4 (Failed)
380 - Triutils_read_test_LL_MPI_4 (Failed)
395 - TpetraTSQR_FullTsqr_Accuracy_MPI_4 (Failed)
396 - TpetraCore_ExpBlockMultiVector_MPI_4 (Failed)
398 - TpetraCore_ExpBlockCrsMatrix_MPI_4 (Failed)
399 - TpetraCore_ExpBlockMap_MPI_4 (Failed)
402 - TpetraCore_BugTests_MPI_4 (Failed)
403 - TpetraCore_BlankRowBugTest_MPI_2 (Failed)
404 - TpetraCore_CompilationTests_MPI_4 (Failed)
405 - TpetraCore_CrsGraph_UnitTests0_MPI_4 (Failed)
406 - TpetraCore_CrsGraph_UnitTests1_MPI_4 (Failed)
407 - TpetraCore_CrsGraph_ReindexColumns_MPI_4 (Failed)
[...]


Thanks.

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

[Antoine Beaupré]

On 2017-01-09 14:25:50, Ana C. Custura wrote:
> Hi,
>
> I was wondering if you're still interested in sponsoring this, it's
> still on mentors if you happen to have time to look at it. If not,
> that's ok as there's someone else I can potentially ask.
>
> Let me know and thanks again!

Hi,

Sorry for the delay, here's a quick review.

(1) The package description could be improved... Use more spaces between
paragraphs. In control files, paragraphs are marked like this:

"""
 Here is a set of tools to perform basic audits on your DNS requests and
 responses to make sure your DNS is working as you expect.  You can
 measure the response time of any given DNS server for arbitrary
 requests using dnsping. Just like traditional ping utility, it gives
 you similar functionality for DNS requests.
 .
 You can also trace the path your DNS request takes to destination to make sure
 it is not being redirected or hijacked. 
"""

Notice the line with a simple dot on it?

(2) Also, I would remove the series of questions on the first lines of
the description. We are aiming at more neutral description of what the
package does, not an advertisement. :)

(3) The Vcs-Git line is incorrect - it needs to be a proper git URL:

$ git clone https://anonscm.debian.org/git/pkg-netmeasure/dnsdiag.git
Clonage dans 'dnsdiag'...
fatal: repository 'https://anonscm.debian.org/git/pkg-netmeasure/dnsdiag.git/' 
not found

I suggest you use collab-maint as it is easy to get access to it. If you
already have access to the pkg-netmeasure group, that's fine too, but be
sure to push your changes there. See this page for collab-maint:

https://wiki.debian.org/CollaborativeMaintenance

(4) Why do you use a `.install` file instead of letting the regular
setup.py install targets do their thing?

(5) in the patches, I recommend you follow the patch tagging guidelines
documented here:

http://dep.debian.net/deps/dep3/

for example, i'd be curious to hear why the cmrywhois patch is required
or what the "test.diff" patch actually does (or why it's called
"test"!)...

(6) the watch file is a bit odd - there's a commented out line, but then
it still kind of works because the next line kicks in... it confuses the
mentors site as well, so you probably want to clean that up.

Otherwise I tested the package and it looks sound - the above is mostly
small details and changes, but those will sure be a problem when we do
the first upload, so make sure to followup on those. :)

Thanks for packaging dnsdiag! Unfortunately, it is too late to make it
into stretch, and that's my fault, but we will be able to backport this
fairly easily I believe...

Cheers,

A.

-- 
Je viens d'un pays où engagé veut dire que tu t'es trouvé une job.
- Patrice Desbiens

Bug#851321: import cv2 gives error with k5_buf_free

[Brent S. Elmer]

Package: python-opencv
Version: 2.4.9.1+dfsg-2.1
Severity: normal

When I try to import cv2, I get the following error:

$python
Python 2.7.13 (default, Dec 18 2016, 20:19:42)
[GCC 6.2.1 20161215] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import cv2
Traceback (most recent call last):
  File "", line 1, in 
ImportError: /usr/lib/x86_64-linux-gnu/libgssapi_krb5.so.2: symbol k5_buf_free, 
version krb5support_0_MIT not defined in file libkrb5support.so.0 with link 
time reference
>>>



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

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

Versions of packages python-opencv depends on:
ii  libc6 2.24-8
ii  libgcc1   1:6.2.1-5
ii  libopencv-calib3d2.4v52.4.9.1+dfsg-2.1
ii  libopencv-contrib2.4v52.4.9.1+dfsg-2.1
ii  libopencv-core2.4v5   2.4.9.1+dfsg-2.1
ii  libopencv-features2d2.4v5 2.4.9.1+dfsg-2.1
ii  libopencv-flann2.4v5  2.4.9.1+dfsg-2.1
ii  libopencv-highgui2.4-deb0 2.4.9.1+dfsg-2.1
ii  libopencv-imgproc2.4v52.4.9.1+dfsg-2.1
ii  libopencv-legacy2.4v5 2.4.9.1+dfsg-2.1
ii  libopencv-ml2.4v5 2.4.9.1+dfsg-2.1
ii  libopencv-objdetect2.4v5  2.4.9.1+dfsg-2.1
ii  libopencv-photo2.4v5  2.4.9.1+dfsg-2.1
ii  libopencv-video2.4v5  2.4.9.1+dfsg-2.1
ii  libpython2.7  2.7.13-1
ii  libstdc++66.2.1-5
ii  python2.7.13-1
ii  python-numpy [python-numpy-abi9]  1:1.12.0~b1-1
pn  python:any

python-opencv recommends no packages.

python-opencv suggests no packages.

-- no debconf information

Bug#850679: etckeeper cron job fails (if no domain name is set)

[Antoine Beaupré]

Control: tags -1 +moreinfo

On 2017-01-09 10:55:32, Ralf Jung wrote:
> fatal: unable to auto-detect email address (got 'root@r-schwarzschild.(none)')

This is odd.

What is in your /etc/hosts?

Here I have:

127.0.0.1   localhost
127.0.1.1   curie.anarc.at  curie

I have, of course, setup a domainname on this machine, but even if I
comment out the second line, I cannot reproduce your issue.

The "domain" part that etckeeper guesses comes from the output of
`dnsdomainname`. Here it is:

$ dnsdomainname 
anarc.at

If I remove the above /etc/hosts line, it is empty. I can't make it show
"(none)" like you have seen.. Where do you think that comes from?

Thanks for the feedback.

A.

-- 
A people that elect corrupt politicians, imposters, thieves & traitors
are not victims... but accomplices.
- George Orwell

Bug#851320: trilinos: FTBFS on single-CPU machines (not enough slots available)

[Santiago Vila]

Package: src:trilinos
Version: 12.10.1-2
Severity: serious

Dear maintainer:

I tried to build this package in stretch with "dpkg-buildpackage -A"
but it failed:


[...]

841/842 Test #841: PikeBlackBox_transient_stepper_MPI_2 
...***Failed 
   0.02 sec
--
There are not enough slots available in the system to satisfy the 2 slots
that were requested by the application:
  
/<>/obj-x86_64-linux-gnu/packages/pike/blackbox/test/core/PikeBlackBox_transient_stepper.exe

Either request fewer slots for your application, or make more slots available
for use.
--


I have not tried to build this a second time, but I've seen this to
happen in other mpi related programs when being built on single-CPU
machines, so I'm going to assume this is essentially the same kind of error.

(i.e. if you need a full build logs, please just say so, but I guess
this should be easy to reproduce on any single-core machine, real or
virtual).

Thanks.

Bug#850501: rerunning using diffoscope 67-21-gfe7ae15

[Maria Glukhova]

On Mon, 09 Jan 2017 17:11:39 + Chris Lamb  wrote:
> Fixed - so sorry about that! Now I wonder if we should insist on tests
> with patches... ;)

Added some tests for APK comparator, see attached patch.
However, please keep in mind apktool takes a lot of time to run even on toy
examples, so adding these tests would extend the time taken by the whole
testing process significantly (almost doubles it at my system). Which makes
me wonder if that was the reason such tests were not added together with
APK comparator in the first place...


Maria Glukhova
From ba61270f532e29fdaa990190dc7be50ae5c91e44 Mon Sep 17 00:00:00 2001
From: Maria Glukhova 
Date: Fri, 13 Jan 2017 23:22:10 +0200
Subject: [PATCH] Add some tests for APK comarator.

---
 tests/comparators/test_apk.py |  62 ++
 tests/data/apk_manifest_expected_diff |  11 ++
 tests/data/apk_zipinfo_expected_diff  |   6 
 tests/data/test1.apk  | Bin 0 -> 866 bytes
 tests/data/test2.apk  | Bin 0 -> 864 bytes
 5 files changed, 79 insertions(+)
 create mode 100644 tests/comparators/test_apk.py
 create mode 100644 tests/data/apk_manifest_expected_diff
 create mode 100644 tests/data/apk_zipinfo_expected_diff
 create mode 100644 tests/data/test1.apk
 create mode 100644 tests/data/test2.apk

diff --git a/tests/comparators/test_apk.py b/tests/comparators/test_apk.py
new file mode 100644
index 000..6253ace
--- /dev/null
+++ b/tests/comparators/test_apk.py
@@ -0,0 +1,62 @@
+# -*- coding: utf-8 -*-
+#
+# diffoscope: in-depth comparison of files, archives, and directories
+#
+# Copyright © 2017 Maria Glukhova 
+#
+# diffoscope is free software: you can redistribute it and/or modify
+# it under the terms of the GNU General Public License as published by
+# the Free Software Foundation, either version 3 of the License, or
+# (at your option) any later version.
+#
+# diffoscope is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with diffoscope.  If not, see .
+
+import pytest
+
+from diffoscope.comparators.apk import ApkFile
+
+from utils import skip_unless_tools_exist, data, load_fixture, \
+assert_non_existing
+
+apk1 = load_fixture(data('test1.apk'))
+apk2 = load_fixture(data('test2.apk'))
+
+def test_identification(apk1):
+assert isinstance(apk1, ApkFile)
+
+def test_no_differences(apk1):
+difference = apk1.compare(apk1)
+assert difference is None
+
+@pytest.fixture
+def differences(apk1, apk2):
+return apk1.compare(apk2).details
+
+@skip_unless_tools_exist('apktool', 'zipinfo')
+def test_compare_non_existing(monkeypatch, apk1):
+assert_non_existing(monkeypatch, apk1)
+
+@skip_unless_tools_exist('apktool', 'zipinfo')
+def test_zipinfo(differences):
+assert differences[0].source1 == 'zipinfo {}'
+assert differences[0].source2 == 'zipinfo {}'
+expected_diff = open(data('apk_zipinfo_expected_diff')).read()
+assert differences[0].unified_diff == expected_diff
+
+@skip_unless_tools_exist('apktool', 'zipinfo')
+def test_android_manifest(differences):
+assert differences[1].source1 == 'AndroidManifest.xml'
+assert differences[1].source2 == 'AndroidManifest.xml'
+expected_diff = open(data('apk_manifest_expected_diff')).read()
+assert differences[1].unified_diff == expected_diff
+
+@skip_unless_tools_exist('apktool', 'zipinfo')
+def test_apk_metadata_source(differences):
+assert differences[2].source1 == 'APK metadata'
+assert differences[2].source2 == 'APK metadata'
diff --git a/tests/data/apk_manifest_expected_diff b/tests/data/apk_manifest_expected_diff
new file mode 100644
index 000..9d37a92
--- /dev/null
+++ b/tests/data/apk_manifest_expected_diff
@@ -0,0 +1,11 @@
+@@ -1,9 +1,9 @@
+ 
+-http://schemas.android.com/apk/res/android;>
+ 
+ 
+ 
+ 
+ 
+ 
diff --git a/tests/data/apk_zipinfo_expected_diff b/tests/data/apk_zipinfo_expected_diff
new file mode 100644
index 000..d1810dc
--- /dev/null
+++ b/tests/data/apk_zipinfo_expected_diff
@@ -0,0 +1,6 @@
+@@ -1,3 +1,3 @@
+-Zip file size: 866 bytes, number of entries: 1
++Zip file size: 864 bytes, number of entries: 1
+ -rw 2.0 fat 2096 bl defN 80-Jan-01 02:00 AndroidManifest.xml
+-1 file, 2096 bytes uncompressed, 714 bytes compressed:  65.9%
++1 file, 2096 bytes uncompressed, 712 bytes compressed:  66.0%
diff --git a/tests/data/test1.apk b/tests/data/test1.apk
new file mode 100644
index ..45876d61fab82fc0c492af2cf60e56a3792f820f
GIT binary patch
literal 866
zcmWIWW@Zs#;Nak3U=UDbKnB7X*QGRBMZ(?3%T555LUPW%s+z|hKAxD|o!%laj

Bug#851319: reportbug: Reportbug should keep a list of reported bugs for review later

[Svein Engelsgjerd]

Package: reportbug
Version: 7.1.2
Severity: wishlist

Dear Maintainer,

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

   * What led up to the situation?
When I use reportbug I get frustrated that I can't easily see a list of all the 
bugs I have reported.

   * What exactly did you do (or not do) that was effective (or
 ineffective)?
I check the bugreport on email...

   * What was the outcome of this action?
Following up bugreports via mail can be a bit tedious...

   * What outcome did you expect instead?
If reportbug is started without parameters it should present a list of packages 
you already have reported bugs on.
It should also display their status.
It would be nice if I the reportee could cathegorize bugs in "important", 
"overdue", "forgotten" or something simmilar independent from the real 
bugreport.
That way I can easily keep an eye on bugs that are important to me, it would 
also be easier to add info to exsiting bugs in case you forget about them etc...
For example if a package is updated a bug may be resolved but not marked as 
such.


-- Package-specific info:
** Environment settings:
INTERFACE="text"

** /home/waxhead/.reportbugrc:
reportbug_version "6.4.4"
mode standard
ui text
realname "Svein Engelsgjerd"
email "waxh...@online.no"
no-cc
header "X-Debbugs-CC: waxh...@online.no"
smtphost reportbug.debian.org

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

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

Versions of packages reportbug depends on:
ii  apt1.4~beta2
ii  python3-reportbug  7.1.2
pn  python3:any

reportbug recommends no packages.

Versions of packages reportbug suggests:
pn  claws-mail 
pn  debconf-utils  
pn  debsums
pn  dlocate
pn  emacs23-bin-common | emacs24-bin-common
ii  exim4  4.88-2
ii  exim4-daemon-light [mail-transport-agent]  4.88-2
ii  file   1:5.29-2
ii  gir1.2-gtk-3.0 3.22.5-1
ii  gir1.2-vte-2.910.46.1-1
ii  gnupg  2.1.17-2
ii  python3-gi 3.22.0-2
pn  python3-gtkspellcheck  
pn  python3-urwid  
ii  xdg-utils  1.1.1-1

Versions of packages python3-reportbug depends on:
ii  apt1.4~beta2
ii  file   1:5.29-2
ii  python3-debian 0.1.29
ii  python3-debianbts  2.6.1
ii  python3-requests   2.12.4-1
pn  python3:any

python3-reportbug suggests no packages.

-- no debconf information

Bug#800367: How to say No!! in a polite though ridiculous way

[Kevin Brace]

Hi Andreas,

Throw this in your xorg.conf


Section "Module"
Load"vgahw"
EndSection


Other than that, your xorg.conf can be empty.
I hope it works.

Regards,

Kevin Brace
The OpenChrome Project maintainer / developer

Bug#851316: pyeapi: FTBFS randomly (failing tests)

[Santiago Vila]

Package: src:pyeapi
Version: 0.7.0-1
Severity: important

Dear maintainer:

I tried to build this package in stretch with "dpkg-buildpackage -A"
but it failed:


[...]
 debian/rules build-indep
dh build-indep --with python3,python2,sphinxdoc --buildsystem=pybuild
   dh_testdir -i -O--buildsystem=pybuild
   dh_update_autotools_config -i -O--buildsystem=pybuild
   dh_auto_configure -i -O--buildsystem=pybuild
I: pybuild base:184: python2.7 setup.py config 
running config
I: pybuild base:184: python3.5 setup.py config 
running config
   debian/rules override_dh_auto_build
make[1]: Entering directory '/<>'
dh_auto_build
I: pybuild base:184: /usr/bin/python setup.py build 
running build

[... snipped ...]

test_enable_authentication (test_client.TestNode) ... ok
test_enable_with_config_statement (test_client.TestNode) ... ok
test_enable_with_multiple_commands (test_client.TestNode) ... ok
test_enable_with_single_command (test_client.TestNode) ... ok
test_get_config (test_client.TestNode) ... ok
test_get_config_as_string (test_client.TestNode) ... ok
test_get_config_raises_type_error (test_client.TestNode) ... ok
test_no_enable_with_single_command (test_client.TestNode) ... ok
test_create (test_api_staticroute.TestApiStaticroute) ... ok
test_default (test_api_staticroute.TestApiStaticroute) ... ok
test_delete (test_api_staticroute.TestApiStaticroute) ... ok
test_get (test_api_staticroute.TestApiStaticroute) ... ok
test_getall (test_api_staticroute.TestApiStaticroute) ... ok
test_instance (test_api_staticroute.TestApiStaticroute) ... ok
test_set_route_name (test_api_staticroute.TestApiStaticroute) ... ok
test_set_tag (test_api_staticroute.TestApiStaticroute) ... ok
test_get (test_api_mlag.TestApiMlag) ... ok
test_set_domain_id (test_api_mlag.TestApiMlag) ... ok
test_set_local_interface (test_api_mlag.TestApiMlag) ... ok
test_set_mlag_id (test_api_mlag.TestApiMlag) ... ok
test_set_peer_address (test_api_mlag.TestApiMlag) ... ok
test_set_peer_link (test_api_mlag.TestApiMlag) ... ok
test_set_shutdown (test_api_mlag.TestApiMlag) ... ok

==
FAIL: test_set_mtu_invalid_value_raises_value_error 
(test_api_ipinterfaces.TestApiIpinterfaces)
--
Traceback (most recent call last):
  File 
"/<>/.pybuild/pythonX.Y_2.7/build/test/unit/test_api_ipinterfaces.py",
 line 128, in test_set_mtu_invalid_value_raises_value_error
self.eapi_exception_config_test(func, ValueError)
  File 
"/<>/.pybuild/pythonX.Y_2.7/build/test/unit/../lib/testlib.py", 
line 112, in eapi_exception_config_test
self.eapi_config_test(func, *args, **kwargs)
  File 
"/<>/.pybuild/pythonX.Y_2.7/build/test/unit/../lib/testlib.py", 
line 98, in eapi_config_test
self.assertEqual(self.node.config.call_count, 0)
AssertionError: 4 != 0

--
Ran 347 tests in 0.531s

FAILED (failures=1)
E: pybuild pybuild:276: test: plugin distutils failed with: exit code=1: cd 
/<>/.pybuild/pythonX.Y_2.7/build; python2.7 -m unittest discover 
-v test/unit
dh_auto_test: pybuild --test -i python{version} -p 2.7 returned exit code 13
debian/rules:6: recipe for target 'build-indep' failed
make: *** [build-indep] Error 25
dpkg-buildpackage: error: debian/rules build-indep gave error exit status 2


This is just how the build ends, not necessarily the relevant part.

I've put several build logs here:

https://people.debian.org/~sanvila/build-logs/pyeapi/

If this is really a bug in one of the build-depends, please use reassign and 
affects,
so that this is still visible in the page for this package.

The bug should be reproducible with sbuild on a single CPU virtual machine,
provided you try enough times (as the failure happens randomly).

Thanks.

Bug#851318: uglifyjs: FTBFS on slow machines (failing tests)

[Santiago Vila]

Package: src:uglifyjs
Version: 2.7.5-1
Severity: serious

Dear maintainer:

I tried to build this package in stretch with "dpkg-buildpackage -A"
but it failed:


[...]
 debian/rules build-indep
test -x debian/rules
mkdir -p "."

Scanning upstream source for new/changed copyright notices...

set -e; LC_ALL=C.UTF-8 /usr/bin/licensecheck --check '.*' --recursive 
--copyright --deb-fmt --ignore 
'^(debian/(changelog|copyright(|_hints|_newhints)))$' --lines 0 * | 
/usr/lib/cdbs/licensecheck2dep5 > debian/copyright_newhints
9 combinations of copyright and licensing found.
WARNING:New or changed notices discovered:

 package.json

To fix the situation please do the following:
  1) Examine debian/copyright_* and referenced files

[... snipped ...]

Running test [lift_sequences_3]
Running test [lift_sequences_4]
Running test [for_sequences]
--- string-literal.js
Running test [octal_escape_sequence]
--- switch.js
Running test [constant_switch_1]
Running test [constant_switch_2]
Running test [constant_switch_3]
Running test [constant_switch_4]
Running test [constant_switch_5]
Running test [constant_switch_6]
Running test [constant_switch_7]
Running test [constant_switch_8]
Running test [constant_switch_9]
Running test [drop_default_1]
Running test [drop_default_2]
Running test [keep_default]
--- typeof.js
Running test [typeof_evaluation]
Running test [typeof_in_boolean_context]
--- unicode.js
Running test [unicode_parse_variables]
--- wrap_iife.js
Running test [wrap_iife]
Running test [wrap_iife_in_expression]
Running test [wrap_iife_in_return_call]

  --- Sourcemaps tests
․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․
  
․․․․․․․․․․․․

  66 passing (34s)
  1 failing

  1) bin/uglifyjs should produce a functional build when using --self:
 Error: timeout of 5000ms exceeded
  at null. (/usr/lib/nodejs/mocha/lib/runnable.js:139:19)
  at Timer.listOnTimeout (timers.js:92:15)



debian/rules:52: recipe for target 'debian/stamp-build' failed
make: *** [debian/stamp-build] Error 1
dpkg-buildpackage: error: debian/rules build-indep gave error exit status 2


This is just how the build ends, not necessarily the relevant part.

I've put several build logs here:

https://people.debian.org/~sanvila/build-logs/uglifyjs/

If this is really a bug in one of the build-depends, please use reassign and 
affects,
so that this is still visible in the page for this package.

I can reproduce this in a lot of different computers, all being "slow",
but there is not a policy anywhere saying that autobuilders must be fast,
so I'm not treating this one as a FTBFS-randomly bug.

Thanks.

Bug#851317: ruby-sidekiq-cron: FTBFS randomly (failing tests)

[Santiago Vila]

Package: src:ruby-sidekiq-cron
Version: 0.4.2-6
Severity: important

Dear maintainer:

I tried to build this package in stretch with "dpkg-buildpackage -A"
but it failed:


[...]
 debian/rules build-indep
dh build-indep --buildsystem=ruby --with ruby
   dh_testdir -i -O--buildsystem=ruby
   dh_update_autotools_config -i -O--buildsystem=ruby
   dh_auto_configure -i -O--buildsystem=ruby
dh_ruby --configure
   dh_auto_build -i -O--buildsystem=ruby
dh_ruby --build
   dh_ruby --build
   dh_auto_test -i -O--buildsystem=ruby
dh_ruby --test
 fakeroot debian/rules binary-indep
dh binary-indep --buildsystem=ruby --with ruby
   dh_testroot -i -O--buildsystem=ruby

[... snipped ...]

  `-.__.-'   
  `-.__.-'   

32743:M 10 Jan 19:00:11.643 # WARNING: The TCP backlog setting of 511 cannot be 
enforced because /proc/sys/net/core/somaxconn is set to the lower value of 128.
32743:M 10 Jan 19:00:11.643 # Server started, Redis version 3.2.6
32743:M 10 Jan 19:00:11.643 # WARNING overcommit_memory is set to 0! Background 
save may fail under low memory condition. To fix this issue add 
'vm.overcommit_memory = 1' to /etc/sysctl.conf and then reboot or run the 
command 'sysctl vm.overcommit_memory=1' for this to take effect.
32743:M 10 Jan 19:00:11.643 # WARNING you have Transparent Huge Pages (THP) 
support enabled in your kernel. This will create latency and memory usage 
issues with Redis. To fix this issue run the command 'echo never > 
/sys/kernel/mm/transparent_hugepage/enabled' as root, and add it to your 
/etc/rc.local in order to retain the setting after a reboot. Redis must be 
restarted after THP is disabled.
32743:M 10 Jan 19:00:11.643 * The server is now ready to accept connections on 
port 6379
/usr/bin/ruby2.3 -I"lib:test"  
"/usr/lib/ruby/vendor_ruby/rake/rake_test_loader.rb" "test/unit/job_test.rb" 
"test/unit/web_extesion_test.rb" 
Run options: --seed 34567

# Running:

..F

Finished in 0.122728s, 643.7006 runs/s, 1262.9569 assertions/s.

  1) Failure:
Cron Job::cron test#test_0002_return previous hour 
[/<>/test/unit/job_test.rb:221]:
--- expected
+++ actual
@@ -1,2 +1,2 @@
 # encoding: UTF-8
-"2017-01-10-18-01-00"
+"2017-01-10-19-01-00"


79 runs, 155 assertions, 1 failures, 0 errors, 0 skips
rake aborted!
Command failed with status (1): [ruby -I"lib:test"  
"/usr/lib/ruby/vendor_ruby/rake/rake_test_loader.rb" "test/unit/job_test.rb" 
"test/unit/web_extesion_test.rb" ]

Tasks: TOP => test
(See full trace by running task with --trace)
+ cleanup
+ kill -9 32743
rake aborted!
Command failed with status (1): [./debian/start-redis-server.sh ruby2.3 -S ...]
/<>/debian/ruby-tests.rake:5:in `block in '
Tasks: TOP => default
(See full trace by running task with --trace)
ERROR: Test "ruby2.3" failed. Exiting.
dh_auto_install: dh_ruby --install /<>/debian/ruby-sidekiq-cron 
returned exit code 1
debian/rules:6: recipe for target 'binary-indep' failed
make: *** [binary-indep] Error 1
dpkg-buildpackage: error: fakeroot debian/rules binary-indep gave error exit 
status 2


This is just how the build ends, not necessarily the relevant part.

I've put several build logs here:

https://people.debian.org/~sanvila/build-logs/ruby-sidekiq-cron/

If this is really a bug in one of the build-depends, please use reassign and 
affects,
so that this is still visible in the page for this package.

The bug should be reproducible with sbuild on a single CPU virtual machine,
provided you try enough times (as the failure happens randomly).

Thanks.

Bug#851315: golang-github-cyberdelia-go-metrics-graphite: FTBFS randomly (failing tests)

[Santiago Vila]

Package: src:golang-github-cyberdelia-go-metrics-graphite
Version: 0.0~git20151204.0.7e54b5c-1
Severity: important

Dear maintainer:

I tried to build this package in stretch with "dpkg-buildpackage -A"
but it failed:


[...]
 debian/rules build-indep
dh build-indep --buildsystem=golang --with=golang
   dh_testdir -i -O--buildsystem=golang
   dh_update_autotools_config -i -O--buildsystem=golang
   dh_auto_configure -i -O--buildsystem=golang
   dh_auto_build -i -O--buildsystem=golang
go install -v -p 1 github.com/cyberdelia/go-metrics-graphite
github.com/rcrowley/go-metrics
github.com/cyberdelia/go-metrics-graphite
   dh_auto_test -i -O--buildsystem=golang
go test -v -p 1 github.com/cyberdelia/go-metrics-graphite
=== RUN   TestWrites
--- PASS: TestWrites (10.01s)
graphite_test.go:56: recv foobar.foo.count 2
graphite_test.go:56: recv foobar.bar.count 40
graphite_test.go:56: recv foobar.bar.one-minute 4
graphite_test.go:56: recv foobar.bar.five-minute 4
graphite_test.go:56: recv foobar.bar.fifteen-minute 4
graphite_test.go:56: recv foobar.bar.mean 4
graphite_test.go:56: recv foobar.baz.count 5
graphite_test.go:56: recv foobar.baz.min 1000
graphite_test.go:56: recv foobar.baz.max 5000
graphite_test.go:56: recv foobar.baz.mean 3000
graphite_test.go:56: recv foobar.baz.std-dev 1414.21
graphite_test.go:56: recv foobar.baz.50-percentile 3000
graphite_test.go:56: recv foobar.baz.75-percentile 4500
graphite_test.go:56: recv foobar.baz.99-percentile 5000
graphite_test.go:56: recv foobar.baz.999-percentile 5000
graphite_test.go:56: recv foobar.baz.one-minute 0
graphite_test.go:56: recv foobar.baz.five-minute 0
graphite_test.go:56: recv foobar.baz.fifteen-minute 0
graphite_test.go:56: recv foobar.baz.mean-rate 79991.04
graphite_test.go:48: dummy server error: accept tcp 127.0.0.1:36803: 
use of closed network connection
FAIL
exit status 1
FAILgithub.com/cyberdelia/go-metrics-graphite   10.012s
dh_auto_test: go test -v -p 1 github.com/cyberdelia/go-metrics-graphite 
returned exit code 1
debian/rules:4: recipe for target 'build-indep' failed
make: *** [build-indep] Error 1
dpkg-buildpackage: error: debian/rules build-indep gave error exit status 2


This is just how the build ends, not necessarily the relevant part.

I've put several build logs here:

https://people.debian.org/~sanvila/build-logs/golang-github-cyberdelia-go-metrics-graphite/

If this is really a bug in one of the build-depends, please use reassign and 
affects,
so that this is still visible in the page for this package.

The bug should be reproducible with sbuild on a single CPU virtual machine,
provided you try enough times (as the failure happens randomly).

Thanks.

Bug#851286: Fails to import libinotify-kqueue: tar: Options '-[0-7][lmh]' not supported by *this* tar

[Tomasz Buchert]

On 13/01/17 23:08, Tomasz Buchert wrote:
> On 13/01/17 18:38, Guido Günther wrote:
> > Package: pristine-tar
> > Version: 1.37
> > Severity: normal
> > 
> > Hi,
> > import of the package current fails with:
> > 
> > $ gbp import-dsc apt://libinotify-kqueue/sid
> > gbp:info: Downloading 'libinotify-kqueue/sid' using 'apt-get'...
> > gbp:info: No git repository found, creating one.
> > gbp:info: Tag upstream/20120419 not found, importing Upstream tarball
> > gbp:error: Couldn't commit to 'pristine-tar' with upstream 
> > '439296e20be4e7f5e9ad3e9d1d457d4a6e4d089f': tar: Options '-[0-7][lmh]' not 
> > supported by *this* tar
> > Try 'tar --help' or 'tar --usage' for more information.
> > tar: /tmp/pristine-tar._cKTs6ZH_V/manifest:1: location of the error
> > pristine-tar: command failed: tar cf 
> > /tmp/pristine-tar._cKTs6ZH_V/recreatetarball --owner 0 --group 0 
> > --numeric-owner -C /tmp/pristine-tar._cKTs6ZH_V/workdir --no-recursion 
> > --mode 0644 --files-from /tmp/pristine-tar._cKTs6ZH_V/manifest
> > 
> 
> That's a genuine bug. It boils down to --verbatim-files-from option to
> tar. I should fix it in the next release.
> 
> Tomasz

Fixed here: 
https://anonscm.debian.org/cgit/collab-maint/pristine-tar.git/commit/?id=f287f10b48c3ca5a30db13dbf3ba918c47a943bb.


signature.asc
Description: PGP signature

Bug#826044: needrestart: Hangs in apt hook with a zombie

[Thomas Liske]

unblock 850948 with 826044
unmerge 826044
severity 826044 important
thanks

Hi,

Jonas Smedegaard  writes:

> Hi,
>
> It seems I have another instance of this issue: piuparts hangs (as I 

piuparts does not use consolation, doesn't it? Please stop abusing this
issue focusing on needrestart vs. consolation for another issue.


> has more details - an interesting part is this extracted when piuparts 
> hangs:
>
> 30803 root   30  10  117M 63804  9816 T  0.0  0.2  0:11.84 │  │└─ 
> /usr/bin/python /srv/piuparts/sbin/piuparts --skip-logrotatefiles-test 
> --warn-on-others --no-eatmydata --scriptsdir /etc/piuparts/script
> 29515 root   30  10 84340 46992 32864 T  0.0  0.1  0:00.67 │  │   
> └─ apt-get -y install design-desktop=3.0.4
> 30238 root   30  10 84340 14128 0 T  0.0  0.0  0:00.00 │  │   
>└─ apt-get -y install design-desktop=3.0.4
> 30240 root   30  10  4288   752   676 T  0.0  0.0  0:00.00 │  │   
>   └─ sh -c test -x /usr/lib/needrestart/apt-pinvoke && 
> /usr/lib/needrestart/apt-pinvoke || true
> 30241 root   30  10 55276 1  4324 T  0.0  0.0  0:00.23 │  │   
>  └─ /usr/bin/perl -w /usr/share/debconf/frontend /usr/sbin/needrestart
> 30331 root   30  10 50124 17516  4148 T  0.0  0.1  0:00.40 │  │   
> └─ /usr/bin/perl /usr/sbin/needrestart
>  2846 root   30  10  4288   740   668 T  0.0  0.0  0:00.00 │  │   
>├─ sh -c resize 2>/dev/null
>  2847 root   30  10  4188   704   632 T  0.0  0.0  0:00.00 │  │   
>│  └─ resize
>  2838 root   30  10 0 0 0 Z  0.0  0.0  0:00.00 │  │   
>└─ 90-none

Maybe it is just a debconf frontend issue? In cases needrestart does
seems to hang it trackes down to:

- daemons hangig while restarting them (init scripts)
- the debconf pipe gets weirrd (consolation)
- needrestart and debconf thinks you call them interactive... but they
  are called non-interactive. As a result they wait forever for
  interaction.


Feel free to open a new bug to needrestart to track down this issue.


Thanks,
Thomas

-- 

::  WWW:https://fiasko-nw.net/~thomas/  ::
   :::  Jabber:   xmpp:tho...@jabber.fiasko-nw.net  :::
::  flickr: https://www.flickr.com/photos/laugufe/  ::

Bug#816989: tbb: FTBFS in testing (Build killed with signal TERM after 150 minutes of inactivity)

[Santiago Vila]

severity 816989 important
thanks

On Mon, 30 May 2016, Steven Capper wrote:

> On 28 May 2016 at 21:12, Tobias Frost  wrote:
>   Severity: -1 important
> 
>   On Sun, 17 Apr 2016 10:00:12 +0200 (CEST) Santiago Vila    s> wrote:
>   > retitle 816989 tbb: FTBFS in testing (Build killed with signal TERM
>   after 150 minutes of inactivity)
>   > severity 816989 serious
>   > thanks
>   > 
>   > This is a normal FTBFS, not related at all with "dpkg-buildpackage
>   -A"
>   > 
>   > The package is "blacklisted" in reproducible builds:
>   > 
>   > https://reproducible.debian.net/rb-pkg/unstable/amd64/tbb.html
>   > 
>   > so I'm not the only one to reproduce this.
>   > 
>   > 
> 
> I tried to reproduce this, but I was not able to do it in a local sid
> pbuilder envrioment, neither building nor when only building arch-
> independt. So I think we should downgrade it..
> 
> 
> 
> Hi,
> Sorry about getting back to this late.
> I am unable to reproduce the stall here on amd64.
> 
> I can see 4.3~20150611-1~exp3 passes the test?
> https://reproducible.debian.net/rbuild/experimental/amd64/tbb_4.3~20150611-1~exp3.rbuild.log
> 
> I will better familiarise myself with FTBFS; one thing I have found is that 
> the unit tests can hang on
> certain boxes.

I can't reproduce this any longer. I have the following build logs:

Status: successful  tbb_4.3~20150611-2_amd64-20161105T214911Z
Status: successful  tbb_4.3~20150611-2_amd64-20161106T001004Z
Status: successful  tbb_4.3~20150611-2_amd64-20161106T001006Z
Status: successful  tbb_4.3~20150611-2_amd64-20170113T115103Z

Holger, this package used to be banned in reproducible builds,
and it also hanged by sbuild.

But now it builds for me. Do you think it would be possible to unban it
temporarily in reproducible builds and see what happens?

Thanks.

Bug#851286: Fails to import libinotify-kqueue: tar: Options '-[0-7][lmh]' not supported by *this* tar

[Tomasz Buchert]

On 13/01/17 18:38, Guido Günther wrote:
> Package: pristine-tar
> Version: 1.37
> Severity: normal
> 
> Hi,
> import of the package current fails with:
> 
> $ gbp import-dsc apt://libinotify-kqueue/sid
> gbp:info: Downloading 'libinotify-kqueue/sid' using 'apt-get'...
> gbp:info: No git repository found, creating one.
> gbp:info: Tag upstream/20120419 not found, importing Upstream tarball
> gbp:error: Couldn't commit to 'pristine-tar' with upstream 
> '439296e20be4e7f5e9ad3e9d1d457d4a6e4d089f': tar: Options '-[0-7][lmh]' not 
> supported by *this* tar
> Try 'tar --help' or 'tar --usage' for more information.
> tar: /tmp/pristine-tar._cKTs6ZH_V/manifest:1: location of the error
> pristine-tar: command failed: tar cf 
> /tmp/pristine-tar._cKTs6ZH_V/recreatetarball --owner 0 --group 0 
> --numeric-owner -C /tmp/pristine-tar._cKTs6ZH_V/workdir --no-recursion --mode 
> 0644 --files-from /tmp/pristine-tar._cKTs6ZH_V/manifest
> 

That's a genuine bug. It boils down to --verbatim-files-from option to
tar. I should fix it in the next release.

Tomasz


signature.asc
Description: PGP signature

Bug#834921: python-ws4py: FTBFS on single CPU machines

[Santiago Vila]

On Fri, Jan 13, 2017 at 10:43:03PM +0200, Adrian Bunk wrote:
> On Thu, Dec 08, 2016 at 05:47:52PM +0100, Santiago Vila wrote:
> > retitle 834921 python-ws4py: FTBFS on single CPU machines
> > thanks
> > 
> > I tried to build this package 200 times today and it failed 200 times.
> > Then I tried once with a 2-CPU machine and it built ok.
> > 
> > Therefore, to reproduce, please try building on a single-CPU machine.
> 
> What Lucas has reported in #851043 looks like the same test failure.
> 
> Lucas, I assume you were not using a single CPU machine?

They seem do be the same bug, yes.

The fact that it worked for me once on a multi-core system does not
necessarily mean that "FTBFS on single CPU machines" is an accurate
description of the bug.

So, please feel free to retitle and merge.

However, I'm not adding this bug to my collection of FTBFS-randomly
bugs here:

https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=ftbfs-randomly;users=sanv...@debian.org

because this one is "reproducible enough" (always for me on
single-core systems). (Yes, I meant core when I said CPU).

Thanks.

Bug#851253: bootstrap build failure: install: cannot stat 'build-deb/.libs/test-udev': No such file or directory

[Felipe Sateler]

(Adding libtool maintainers to CC).

On 13 January 2017 at 09:03, Helmut Grohne  wrote:
> Source: systemd
> Version: 232-9
> User: helm...@debian.org
> Usertags: rebootstrap
>
> Since systemd 232-9 some architectures no longer bootstrap. An example
> is nios2:
>
> https://jenkins.debian.net/job/rebootstrap_nios2_gcc6/56/consoleText:
> | # ship test-udev, so that we have it for autopkgtests
> | install -D build-deb/.libs/test-udev 
> debian/libudev-dev/usr/lib/nios2-linux-gnu/udev/test-udev
> | install: cannot stat 'build-deb/.libs/test-udev': No such file or directory
> | debian/rules:247: recipe for target 'override_dh_install' failed
> | make[1]: Leaving directory '/tmp/buildd/systemd_1/systemd-232'
> | make[1]: *** [override_dh_install] Error 1
> | debian/rules:366: recipe for target 'binary-arch' failed
> | make: *** [binary-arch] Error 2
> | dpkg-buildpackage: error: fakeroot debian/rules binary-arch gave error exit 
> status 2

For libtool maintainers, what systemd is doing here is trying to copy
test-udev (part of upstream's testsuite) into the package dir, to be
able to run that on user systems in case udev breaks.

>
> The configuration is:
> * DEB_BUILD_ARCH=amd64
> * DEB_HOST_ARCH=nios2
> * DEB_BUILD_OPTIONS=nocheck noddebs parallel=1
> * DEB_BUILD_PROFILES=nocheck noudeb stage1
>
> In the full log, you can see that test-udev actually is being compiled.
>
> Simple native builds for single profiles stage1 or nocheck do not
> exhibit the failure mode.

test-udev links dynamically against libsystemd-shared, which is a
utility library that contains many helper functions. On most
architectures, this results in ./test-udev being a wrapper script that
sets up the environment and runs the real executable from
.libs/test-udev. However, it appears that on nios2 and sparc
(cross-built from amd64), this is not true, and the real binary is
stored in ./test-udev.

So the question would be, why would libtool not follow the convention
of placing the binary objects in .libs?

Dear libtool maintainers, do you have any idea?

>
> Reverting systemd packaging commit
> 943053a2c2fd8b153545eb410101e0e3616d4de9 makes the issue go away.

https://anonscm.debian.org/cgit/pkg-systemd/systemd.git/commit/?id=943053a2c2fd8b153545eb410101e0e3616d4de9
for reference.



-- 

Saludos,
Felipe Sateler

Bug#851288: Fails to import libopenusb: xdelta: warning: no matches found in from file, patch will apply without it

[Tomasz Buchert]

On 13/01/17 18:47, Guido Günther wrote:
> Package: pristine-tar
> Version: 1.37
> Severity: normal
> 
> Hi,
> libopenusb fails to import like:
> 
> $ gbp import-dsc  apt://libopenusb/sid 
> gbp:info: Downloading 'libopenusb/sid' using 'apt-get'...
> gbp:info: No git repository found, creating one.
> gbp:info: Tag upstream/1.1.11 not found, importing Upstream tarball
> gbp:debug: /usr/bin/pristine-tar [] ['commit', 
> '/tmp/tmptWZY2m/libopenusb_1.1.11.orig.tar.gz', 
> 'cc238ac43eeda94e0d3c232cb0293cdc414449ba']
> gbp:error: Couldn't commit to 'pristine-tar' with upstream 
> 'cc238ac43eeda94e0d3c232cb0293cdc414449ba': xdelta: warning: no matches found 
> in from file, patch will apply without it
> error: excessively large binary delta for 
> /tmp/tmpEcGB0O/libopenusb_1.1.11.orig.tar.gz
> (Probably the tarball is compressed with an unsupported form of compression.)
> pristine-tar: failed to generate delta
> 

This tarball is messed up:

[ /tmp/omg ] $ file libopenusb_1.1.11.orig.tar.gz
libopenusb_1.1.11.orig.tar.gz: compress'd data 16 bits

It's not compressed with gzip, but with "compress". A fix would be to
add support for that, although I doubt it makes sense (who makes such
tarballs, really?). It would be "solved" with the same trick that was
mentioned in https://bugs.debian.org/851285.

Tomasz


signature.asc
Description: PGP signature

Bug#846944: Installing libnss-resolve before libnss-mdns breaks mDNS name resolution

[Michael Biebl]

Control: clone -1 -2
Control: reassign -2 libnss-mymachines
Control: found -2 222-3
Control: retitle -2 libnss-mymachines should be ordered before resolve


Am 13.01.2017 um 22:48 schrieb Felipe Sateler:
> On 13 January 2017 at 18:24, Michael Biebl  wrote:
> libnss-mymachines - nss module to resolve hostnames for local container 
> instances
>>>
>>> This is meant to be after files but before resolve (so the same position
>>> as libnss-docker and libnss-gw-name). Are you deliberately installing it 
>>> with
>>> a lower priority than upstream's recommendation?
...

> This was the upstream recommendation at the time. That was changed in
> upstream commit 9053aaad4255a1d01a50f8e44784cd7eebe8f95c , with the
> following log message:
> 
> man: change recommended order of NSS modules in /etc/nsswitch.conf
> 
> So far we recommended placing "nss-mymachines" after "nss-resolve"
> in the order
> of preference in /etc/nsswitch.conf. This change reverse this
> order.

..
> 
> So I guess we just failed to update usage with upstream?
> 

I think so. Let's clone this for libnss-mymachines to get this updated.

Felipe, do you want to look into this?

Michael

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



signature.asc
Description: OpenPGP digital signature

Bug#834921: python-ws4py: FTBFS on single CPU machines

[Lucas Nussbaum]

On 13/01/17 at 22:43 +0200, Adrian Bunk wrote:
> On Thu, Dec 08, 2016 at 05:47:52PM +0100, Santiago Vila wrote:
> > retitle 834921 python-ws4py: FTBFS on single CPU machines
> > thanks
> > 
> > I tried to build this package 200 times today and it failed 200 times.
> > Then I tried once with a 2-CPU machine and it built ok.
> > 
> > Therefore, to reproduce, please try building on a single-CPU machine.
> 
> What Lucas has reported in #851043 looks like the same test failure.
> 
> Lucas, I assume you were not using a single CPU machine?

By, CPU, do you mean core? no, that Amazon EC2 VM had 63 cores.
If you mean CPU, I don't know what is exposed inside the VM. I could
check if needed. Maybe all 63 cores are seen as from the same CPU.

Lucas

Bug#846944: Installing libnss-resolve before libnss-mdns breaks mDNS name resolution

[Felipe Sateler]

On 13 January 2017 at 18:24, Michael Biebl  wrote:
 libnss-mymachines - nss module to resolve hostnames for local container 
 instances
>>
>> This is meant to be after files but before resolve (so the same position
>> as libnss-docker and libnss-gw-name). Are you deliberately installing it with
>> a lower priority than upstream's recommendation?
>
> We'll have to look into this. This change was made by Felipe in
> 7da95fd9f9a2330ffd3132c6673b25f929a78f09 for #789006. Maybe it was
> unintentional for mymachines (the original bug report was for myhostname)
>
> Felipe, can you chime in here?


This was the upstream recommendation at the time. That was changed in
upstream commit 9053aaad4255a1d01a50f8e44784cd7eebe8f95c , with the
following log message:

man: change recommended order of NSS modules in /etc/nsswitch.conf

So far we recommended placing "nss-mymachines" after "nss-resolve"
in the order
of preference in /etc/nsswitch.conf. This change reverse this
order.

Rationale: single-label names are resolved via LLMNR by resolved,
which has to
time out if no peer by that name exists. By placing
"nss-mymachines" first
(which always responds immediately) we avoid running into this
timeout for most
containers. Both modules should return the same data if LLMNR is
used by the
container anyway.

While we are at it, improve the man pages of the three NSS modules
in other
ways a bit.


So I guess we just failed to update usage with upstream?

-- 

Saludos,
Felipe Sateler

Bug#843052: fixed in libterm-filter-perl 0.03-2

[Santiago Vila]

found 843052 0.03-2
severity 843052 important
thanks

Still FTBFS randomly.

I'm using the same bug report because the end result is still the same
(random FTBFS failure).

Build logs here:

https://people.debian.org/~sanvila/build-logs/libterm-filter-perl/

Thanks.

Bug#851285: Fails to import lbzip2: failed to generate delta

[Tomasz Buchert]

On 13/01/17 18:56, Guido Günther wrote:
> On Fri, Jan 13, 2017 at 06:21:24PM +0100, Guido Günther wrote:
> > Package: pristine-tar
> > Version: 1.37
> > Severity: normal
> > 
> > Hi,
> > importing lbzip2 fails with:
> >
> [...]
> 
> libxfce4ui, nsis, thunar-volman, thunar, tumbler, xfce4-cpufreq-plugin,
> xfce4-dev-tools, xfce4-dict, xfce4-weather-plugin fail with the same
> error so I'm not filing separate reports.
> Cheers,
>  -- Guido

I didn't check all of these packages, but indeed they do not
reproduce.  However, note that these packages do not use pristine-tar
(or gbp, if my sample was significant), so nobody ever tried to
reproduce their tarballs with pristine-tar. :)

The issue we have here is that it is impossible to "gbp import-dsc
..." a random package, because in general tarballs are messy. Correct
me if I'm wrong, but it looks as if you don't intend to actually keep
pristine-tar for anything more than temporary help to use gbp with the
imported package?

If the answer is yes, then I propose to introduce a mode to
pristine-tar that will: (1) try to import the given tarball using the
standard machinery and if that fails (2) import the final tarball
as-it-is. This sort of defeats the whole idea of pristine-tar, but may
be a necessary evil for this sort of use and will not harm anyone if
people won't use it to actually import tarballs into long-term package
repositories. What do you think?

Tomasz


signature.asc
Description: PGP signature

Bug#851313: mirror listing update for mirror.nodesdirect.com

[Daniel Stephens]

Package: mirrors
Severity: minor
User: mirr...@packages.debian.org
Usertags: mirror-list

Submission-Type: update
Site: mirror.nodesdirect.com
Type: leaf
Archive-architecture: amd64 i386 
Archive-ftp: /debian/
Archive-http: /debian/
Archive-rsync: debian/
IPv6: yes
Archive-upstream: ftp.us.debian.org
Updates: four
Maintainer: Daniel Stephens 
Country: US United States
Location: Jacksonville, FL
Sponsor: Nodes Direct http://nodesdirect.com

Bug#851312: mirror submission for mirror.nodesdirect.com

[Daniel Stephens]

Package: mirrors
Severity: wishlist
User: mirr...@packages.debian.org
Usertags: mirror-submission

Submission-Type: new
Site: mirror.nodesdirect.com
Aliases: ndmirror01.jax.ndnx.net
Type: leaf
Archive-architecture: amd64 i386 
Archive-ftp: /debian/
Archive-http: /debian/
Archive-rsync: debian/
IPv6: yes
Archive-upstream: ftp.us.debian.org
Updates: four
Maintainer: Daniel Stephens 
Country: US United States
Location: Jacksonville, FL
Sponsor: Nodes Direct http://nodesdirect.com

Bug#851311: caja: invisible cursor in dark themes

[Ayke van Laethem]

Package: caja
Version: 1.16.1-1
Severity: minor
Tags: patch

Dear Maintainer,

When using a dark theme (E.g. BlackMATE), the cursor in the text box for
renaming files often has a barely visible cursor.
See the upstream bug: https://github.com/mate-desktop/caja/issues/688

It has been fixed upstream and backported to 1.16, so simply updating to
the latest version (of both caja and mate-themes) should fix the
problem.
Otherwise, the patches can be manually applied.

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

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

Versions of packages caja depends on:
ii  caja-common   1.16.1-1
ii  desktop-file-utils0.23-1
ii  gvfs  1.30.3-1
ii  libatk1.0-0   2.22.0-1
ii  libc6 2.24-8
ii  libcairo-gobject2 1.14.8-1
ii  libcairo2 1.14.8-1
ii  libcaja-extension11.16.1-1
ii  libexempi32.3.0-2
ii  libexif12 0.6.21-2
ii  libgail-3-0   3.22.5-1
ii  libgdk-pixbuf2.0-02.36.2-1
ii  libglib2.0-0  2.50.2-2
ii  libglib2.0-data   2.50.2-2
ii  libgtk-3-03.22.5-1
ii  libice6   2:1.0.9-1+b1
ii  libmate-desktop-2-17  1.16.1-1
ii  libpango-1.0-01.40.3-3
ii  libpangocairo-1.0-0   1.40.3-3
ii  libselinux1   2.6-3
ii  libsm62:1.2.2-1+b1
ii  libstartup-notification0  0.12-4
ii  libunique-3.0-0   3.0.2-2
ii  libx11-6  2:1.6.4-2
ii  libxext6  2:1.3.3-1
ii  libxml2   2.9.4+dfsg1-2.1
ii  libxrender1   1:0.9.10-1
ii  mate-desktop  1.16.1-1
ii  shared-mime-info  1.7-1

Versions of packages caja recommends:
ii  gvfs-backends  1.30.3-1

Versions of packages caja suggests:
ii  engrampa1.16.0-1
pn  gstreamer1.0-tools  
ii  meld3.16.4-1

-- no debconf information

Bug#840244: (no subject)

[Cristian Rigamonti]

Interestingly, the 3.7.2-1 amd64 package from stretch is not affected by the 
problem.
Maybe it was an interaction bug with some other component?

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

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

Versions of packages audacious depends on:
ii  audacious-plugins3.7.2-2+b1
ii  dbus 1.10.14-1
ii  dbus-x11 1.10.14-1
ii  gtk2-engines-pixbuf  2.24.31-1
ii  libaudcore3  3.7.2-1
ii  libc62.24-8
ii  libgcc1  1:6.2.1-5
ii  libglib2.0-0 2.50.2-2
ii  libstdc++6   6.2.1-5

Versions of packages audacious recommends:
ii  unzip  6.0-21

audacious suggests no packages.

Bug#850108: needrestart: support python3

[Thomas Liske]

Hi Paul,


Paul Wise  writes:

> Package: needrestart
> Version: 2.10-1
> Severity: important
>
> The Python interpreter support doesn't appear to check python3 processes:
>
> /usr/share/perl5/NeedRestart/Interp/Python.pm:return 1 if($bin =~ 
> m@/usr/(local/)?bin/python@);

this regex does match on /usr/bin/python3 since there is no
end of string metacharacter ($). So it should not require any change in
needrestart, shouldn't it?


HTH,
Thomas

> I think this really needs to be fixed in stretch and the freeze is soon:
>
> https://lists.debian.org/debian-devel-announce/2016/12/msg0.html
>
> -- System Information:
> Debian Release: stretch/sid
>   APT prefers testing-debug
>   APT policy: (900, 'testing-debug'), (900, 'testing'), (800, 
> 'unstable-debug'), (800, 'unstable'), (790, 'buildd-unstable'), (700, 
> 'experimental-debug'), (700, 'experimental'), (690, 'buildd-experimental')
> Architecture: amd64 (x86_64)
>
> Kernel: Linux 4.8.0-2-amd64 (SMP w/4 CPU cores)
> Locale: LANG=en_AU.utf8, LC_CTYPE=en_AU.utf8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
>
> Versions of packages needrestart depends on:
> ii  dpkg   1.18.18
> ii  gettext-base   0.19.8.1-1
> ii  libintl-perl   1.26-2
> ii  libmodule-find-perl0.13-1
> ii  libmodule-scandeps-perl1.22-1
> ii  libproc-processtable-perl  0.53-2
> ii  libsort-naturally-perl 1.03-1
> ii  libterm-readkey-perl   2.37-1
> ii  perl   5.24.1~rc4-1
> ii  xz-utils   5.2.2-1.2
>
> needrestart recommends no packages.
>
> Versions of packages needrestart suggests:
> ii  libnotify-bin0.7.7-1
> ii  needrestart-session  0.3-2
>
> -- no debconf information
>
> -- 
> bye,
> pabs
>
> https://wiki.debian.org/PaulWise

-- 

::  WWW:https://fiasko-nw.net/~thomas/  ::
   :::  Jabber:   xmpp:tho...@jabber.fiasko-nw.net  :::
::  flickr: https://www.flickr.com/photos/laugufe/  ::

Bug#849351: Pending fixes for bugs in the libimage-exiftool-perl package

[pkg-perl-maintainers]

tag 849351 + pending
thanks

Some bugs in the libimage-exiftool-perl package are closed in
revision 24f401fc57da2e1dce20ff609cf2376f595eb0a7 in branch 'master'
by gregor herrmann

The full diff can be seen at
https://anonscm.debian.org/cgit/pkg-perl/packages/libimage-exiftool-perl.git/commit/?id=24f401f

Commit message:

New upstream release. Fixes "exiftool: manual page does not document -All 
option" (Closes: #849351)

Bug#851291: Fails to import xz-utils: pristine-xz failed to reproduce build of /tmp/xz-utils_5.2.2.orig.tar.xz

[Tomasz Buchert]

On 13/01/17 19:02, Guido Günther wrote:
> On Fri, Jan 13, 2017 at 06:54:52PM +0100, Guido Günther wrote:
> > Package: pristine-tar
> > Version: 1.37
> > Severity: normal
> > 
> > Hi,
> > Importing xz-utils fails with:
> > 
> > $ gbp import-dsc --verbose apt://xz-utils/sid
> > gbp:info: Downloading 'xz-utils/sid' using 'apt-get'...
> > gbp:info: No git repository found, creating one.
> > gbp:info: Tag upstream/5.2.2 not found, importing Upstream tarball
> > gbp:debug: /usr/bin/pristine-tar [] ['commit', 
> > '/tmp/tmpePy8LE/xz-utils_5.2.2.orig.tar.xz', 
> > '78070151ccd87648d5f2c3b6a8c0ad4bf9685f03']
> > gbp:error: Couldn't commit to 'pristine-tar' with upstream 
> > '78070151ccd87648d5f2c3b6a8c0ad4bf9685f03': pristine-xz failed to reproduce 
> > build of /tmp/tmpePy8LE/xz-utils_5.2.2.orig.tar.xz
> > (Please file a bug report.)
> > pristine-tar: command failed: pristine-xz --no-verbose --no-debug --no-keep 
> > gendelta /tmp/tmpePy8LE/xz-utils_5.2.2.orig.tar.xz 
> > /tmp/pristine-tar.NLMdqskICv/wrapper
> > pristine-tar: failed to generate delta
> 
> Importing yad seems to have the same problem.
> 

Thanks for this report.

Things don't look good. I was not able to reproduce any xz-utils orig
tarballs we have e.g. in debian snapshot (or here
http://tukaani.org/xz/old.html). The default options to xz seem to be
"-6" or "-6e", but this produces a different output. This will need
more investigation...

It maybe that the debian's xz is producing something non-standard, I
don't know yet. That said, we must consider a way to force importing
a tarball as-it-is, to work around hopeless cases.

Tomasz


signature.asc
Description: PGP signature

Bug#828082: bind9: FTBFS with openssl 1.1

[Kurt Roeckx]

On Fri, Jan 13, 2017 at 07:31:03PM +0100, Bernhard Schmidt wrote:
> Hi,
> 
> > Your package is failing to build with openss 1.1:
> > checking for OpenSSL library... no
> > yes
> > checking for using OpenSSL for hash functions... no
> > [...]
> > checking for OpenSSL library... using OpenSSL from /usr/lib and /usr/include
> > checking whether linking with OpenSSL works... yes
> > [...]
> > configure: error: OpenSSL has unsupported dynamic loading
> > no
> > [...]
> > BIND 9 is being built without cryptography support. This means it will
> > not have DNSSEC support. Use --with-openssl, or --with-pkcs11 and
> > --enable-native-pkcs11 to enable cryptography.
> 
> src:bind9 still fails to rebuild in unstable. I understand that you
> would not want to import a large patch for this, so please switch
> build-deps to libssl1.0-dev for stretch.

Upstream has actually added a patch for this already in the stable
branch as far as I know, so I expect this to actually have been
fixed in 9.10.4-P5.

That being set, it's not using libssl, so either solution is fine
for me.


Kurt

Bug#851310: wordpress: Eight security issues in wordpress 4.7

[Craig Small]

Source: wordpress
Version: 4.7+dfsg-2
Severity: grave
Tags: upstream security
Justification: user security hole

There are a bunch of security holes in wordpress 4.7. Eight! security
issues!

The best summary of them is at [1] which lists them as:


WordPress 4.3-4.7 - Potential Remote Command Execution (RCE) in PHPMailer
WordPress 4.7 - User Information Disclosure via REST API
WordPress 2.9-4.7 - Authenticated Cross-Site scripting (XSS) in update-core.php
WordPress 4.7 - Cross-Site Request Forgery (CSRF) via Flash Upload
WordPress 3.4-4.7 - Stored Cross-Site Scripting (XSS) via Theme Name fallback
WordPress <= 4.7 - Post via Email Checks mail.example.com by Default
WordPress 2.8-4.7 - Accessibility Mode Cross-Site Request Forgery (CSRF)
WordPress 3.0-4.7 - Cryptographically Weak Pseudo-Random Number Generator (PRNG)

Wordpress 4.7.1 apparently fixes them.[2]

Sigh.

1: https://wpvulndb.com/wordpresses
2: 
https://wordpress.org/news/2017/01/wordpress-4-7-1-security-and-maintenance-release/


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

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

Bug#850769:

[Ingo Bauersachs]

tags 850769 patch

Attached patch is based on upstream diff [1], also available as a package on 
Mentors [2].

Ingo

[1] 
http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/trusty/libdbusmenu/trusty-updates/revision/51
[2] https://mentors.debian.net/package/libdbusmenu





replace-child-added-gtk3-debdiff.diff
Description: Binary data

Bug#844427:

[Gangster Femeli]

Bug#846944: Installing libnss-resolve before libnss-mdns breaks mDNS name resolution

[Michael Biebl]

Control: severity -1 normal

Hi Simon

Am 12.01.2017 um 20:10 schrieb Simon McVittie:
> Control: clone 846944 -2
> Control: reassign -2 libnss-mdns 0.10-7
> 
> On Thu, 08 Dec 2016 at 15:20:34 +0100, Michael Biebl wrote:
>> With multiple packages mangling nsswitch.conf, this feels like it's
>> becoming very brittle and maybe we need a proper API like pam-auth-update.
> 
> That would be nice, but let's not block on that for stretch.

Nod

> On Thu, 08 Dec 2016 at 15:30:53 +0100, Michael Biebl wrote:
>>> So maybe the "obvious" fix is to change libnss-mdns to always insert itself
>>> before dns *and* resolve? On the other hand, it's quite ugly that mdns 
>>> needs to
>>> be taught to cope with this new nss module.
> 
> Solving this in nss-mdns is pretty easy so I'd be OK with going ahead with
> that for stretch (and I'd be prepared to consider it RC). Cloning the
> bug accordingly. I've written autopkgtests and they seem to work.

Thanks for implementing that. Given this change in libnss-mdns, I'm
going to downgrade the severity to non-RC.


>> So, libnss-resolve's behaviour of using [!UNAVAIL=return] would break
>> LDAP hosts resolution as well.
> [...]
>> It seems like [!UNAVAIL=return] is generally not safe to use if you
>> don't know which NSS modules might come after yours.
> 
> Yes. However, I can't think of any other way to get the desired
> behaviour of nss-resolve, which is: if systemd-resolved responds
> "that name doesn't exist in DNS", don't ask the dns plugin to look it up
> in DNS again.
> 
> I think the real issue here is perhaps that we have modules that try to
> prioritize themselves lower than "dns", but are not a mere fallback like
> libnss-myhostname is.
> 
>>> libnss-lwres - NSS-Modul um bind9-lwres als Namensdienst zu nutzen
> 
> Installation is not automated, and I don't see why anyone would want to
> use this and systemd-resolved on the same system anyway (this one only
> does traditional port 53 DNS, so it's a strict subset of systemd-resolved).
> 
> Perhaps libnss-resolve should just have a Conflicts on it? Using both
> makes no sense.

There are a lot of packages which don't make sense to have installed
alongside systemd. Adding Conflicts to all of them is not a path I want
to go down

> 
>>> libnss-ldap - NSS-Modul für den Einsatz von LDAP als Namensdienst
> 
> Installation is not automated, but the example suggests appending ldap
> after dns, so libnss-resolve will indeed break it.
> 
> But it's orphaned, has many long-standing bugs that to be honest
> should probably be RC, and has enough design issues that libnss-ldapd
> was written as a replacement... so perhaps libnss-resolve should just
> conflict with it and move on. (Remember, this is the plugin that pulls
> libldap, GNUTLS, libsasl and Kerberos into every process that looks up
> usernames...)
> 
> The example configuration says
> 
>   # consult DNS first, we will need it to resolve the LDAP host. (If we
>   # can't resolve it, we're in infinite recursion, because libldap calls
>   # gethostbyname(). Careful!)
>   hosts:  dns ldap
> 
> which is just horrible tbh - as a bare minimum it should special-case
> its own server name to be skipped! libnss-ldapd fixes that design issue.
> 
>>> libnss-ldapd - NSS-Modul für den Einsatz von LDAP als Namensdienst
> 
> This goes at the end, so libnss-resolve will break it. But
> perhaps it shouldn't - its own documentation says
> 
>   # hostname lookups through ldap before dns should work now
>   hosts:  files ldap dns
> 
>>> libnss-myhostname - nss module providing fallback resolution for the 
>>> current hostname
> 
> This goes at the end of the line as a fallback, but systemd-resolved
> has all the functionality of libnss-myhostname, so not running it
> is harmless.
> 
>>> libnss-docker - nss module for finding Docker containers
>>> libnss-gw-name - nss module that names the current gateway’s IP address
> 
> These are prioritized slightly lower than 'files', so they come before
> both mdns and resolve - conceptually, it's as though you added all
> your containers, and your gateway, to /etc/hosts. That's fine.
> 
>>> libnss-mymachines - nss module to resolve hostnames for local container 
>>> instances
> 
> This is meant to be after files but before resolve (so the same position
> as libnss-docker and libnss-gw-name). Are you deliberately installing it with
> a lower priority than upstream's recommendation?

We'll have to look into this. This change was made by Felipe in
7da95fd9f9a2330ffd3132c6673b25f929a78f09 for #789006. Maybe it was
unintentional for mymachines (the original bug report was for myhostname)

Felipe, can you chime in here?


>>> libnss-libvirt - nss plugin providing IP add ress resolution for virtual 
>>> machines
> 
> Not set up automatically. I'm not sure where it's meant to go; presumably
> the same place as libnss-docker, in which case it's fine?
> 
>>> libnss-sss - Nss-Modul für den SSS-Daemon (System Security Services)
>>> libnss-cache - NSS 

Bug#851163: Update

[Simon Heath]

Update: tried it on a different system with the same OS, after <24 hours it
used up about 2 GB of memory.

Now I shall start removing plugins and track what happens.

Simon

Bug#848137: [Dbconfig-common-devel] Bug#848137: problem with the upgrade of tango-db

[Paul Gevers]

Control: tags 850190 pending

Hi Frederic-Emmanuel,

On 01/13/17 16:08, PICCA Frederic-Emmanuel wrote:
>> Once I fixed 850190, 
> 
> Do you think that you will fix this bug before next week in order to
> let me enought time to fix tango and upload it.

I really hope I can upload this weekend. I have code that I believe does
what I want. I am in the process of testing it.

>> I believe that ought to work, although that is
>> still a hack. I was thinking of doing the "DROP PROCEDURE IF EXISTS *"
>> calls with the administrator credentials and the rest of the upgrade
>> script with the proper tango credentials. But probably your solution is
>> easier to implement.
> 
> I am thinking about this, and I agreed thaht it would be nice to put the fic 
> in the postinst, just before the 
> dbc_go whcih does the upgrade.
> 
> Can you give me an example of how to execute this DROP PROCEDURES IF EXISTS *
> with the dbadmin right in this postinst

If you want to do it outside of dbconfig-common (you write "before the
dbc_go") than I am not going to advice you, because it would be too much
work to find out the proper code (and you would need to call
dbconfig-common internals or duplicate lots of code). What I meant,
instead of the mysql code that runs as user, run a script for the
upgrade (they are run with database administrator credentials) and in
that script do two things: call the DROP PROCEDURES... and then use the
user credentials to run the normal script.

> I am wondering if dbconfig-common could provide something in order to
> execute an sql script everywhen at the request of the maintainer,
> 
> dbc_dbuser = dbadmin
> dbc_custom_stript=
> dbc_go tango "runscript"
> 
> which run the script with the right database configuration extracted from the 
> configuration phase.

Apart from this repair, do you see more use cases? The problem is that
you would need nearly all the logic that is now in dbc_go for this to
work. What I am considering is if I could guarantee the order of
script/user mysql/admin mysql (or the last two reversed). I guess that
if I would guarantee the script to always come first, it would be easier
to solve the tango-db issue at hand (which was originally created by
dbconfig-common).

Paul



signature.asc
Description: OpenPGP digital signature

Bug#850444: auctex: context mode doesn't show subsubsections in outline

[Davide G. M. Salvetti]

tags 850444 +confirmed +fixed-upstream
thanks

I can reproduce this bug; it has been fixed upstream with commit
183959aea243c3bc26e44cafa0f0cae8b729f91a in date 2017-01-13.

I will backport the fix and include it into auctex version 11.90-1.

-- 
Thanks,
Davide

Bug#851309: ITP: rtl-433 -- Application using librtlsdr to decode information from a wireless sensor

[Martijn van Brummelen]

Package: wnpp
Severity: wishlist
Owner: Martijn van Brummelen 

* Package name: rtl-433
  Version : 0.1
  Upstream Author : Benjamin Larsson
* URL : https://github.com/merbanan/rtl_433
* License : GPL-2.0
  Programming Lang: C
  Description : Application using librtlsdr to decode information from
a wireless sensor

Bug#851300: unblock: utopia-documents/3.0.0-1

[Yaroslav Halchenko]

On Fri, 13 Jan 2017, Mattia Rizzolo wrote:
> > d'oh -- I should have noted that it wasn't in testing -- somehow
> > I was under impression (saw "jessie" -- thought "stretch")  that it was
> > in testing at that point.
> …
> > Thanks Mattia for the patience with my silly questions ;)

> Remember that I'm not from the Release Team; if they want to make an
> exception it's entirely up to them, I was just replying to explain why
> this didn't migrate when you expected it to do.

double thanks then ;)

I will leave it up to release team to decide if they are still reading
this report.

Cheers,
-- 
Yaroslav O. Halchenko
Center for Open Neuroscience http://centerforopenneuroscience.org
Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755
Phone: +1 (603) 646-9834   Fax: +1 (603) 646-1419
WWW:   http://www.linkedin.com/in/yarik

Bug#851308: [abi-dumper] New upstream release

[Bastien ROUCARIÈS]

Package: abi-dumper
Severity: wishlist

I could co maintain this one. I suppose they are some interest to put it on 
debian-qa umbrella

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

Bug#851307: [vtable-dumper] New upstream version fixing securities bug

[Bastien ROUCARIÈS]

Package: vtable-dumper
Severity: serious
Tags: patch security
X-Debbugs-CC: secure-testing-t...@lists.alioth.debian.org

Hi,

vtable dumper could be run from network process in order to test remote 
binaries.

Newer version fix some security bug like off-by-ones, segfault and memory leak

Thanks

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

Bug#847988: pd-libdir: does not respect current loader path

[Hans-Christoph Steiner]

IOhannes m zmölnig:
> On Mon, 12 Dec 2016 23:45:41 +0100
> =?UTF-8?Q?IOhannes_m_zm=c3=b6lnig_=28Debian/GNU=29?=
>   wrote:
>> On 12/12/2016 10:06 PM, IOhannes m zmoelnig wrote:
>>> please fix the loader, so it respects the 'path' argument.
>>
>>
>> afaict, this is fixed in the upstream-clone at
>>https://github.com/pure-data/libdir
>>
>> however, the code there needs review.
> 
> do you intend to fix this for stretch?
> 
> dgasndr
> IOhannes
> 

I looked at it, seems alright, but I can't really say much because I
haven't tracked the changes in Pd in the past couple years.  Feel free
to upload and make a release.

.hc

Bug#851300: unblock: utopia-documents/3.0.0-1

[Mattia Rizzolo]

On Fri, Jan 13, 2017 at 03:54:51PM -0500, Yaroslav Halchenko wrote:
> d'oh -- I should have noted that it wasn't in testing -- somehow
> I was under impression (saw "jessie" -- thought "stretch")  that it was
> in testing at that point.
…
> Thanks Mattia for the patience with my silly questions ;)

Remember that I'm not from the Release Team; if they want to make an
exception it's entirely up to them, I was just replying to explain why
this didn't migrate when you expected it to do.

-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
more about me:  https://mapreri.org : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


signature.asc
Description: PGP signature

Bug#851306: ITP: freebayes -- Bayesian haplotype-based polymorphism discovery and genotyping

[Andreas Tille]

Package: wnpp
Severity: wishlist
Owner: Andreas Tille 

* Package name: freebayes
  Version : 1.0.2
  Upstream Author : Erik Garrison
* URL : https://github.com/ekg/freebayes
* License : MIT
  Programming Lang: C++
  Description : Bayesian haplotype-based polymorphism discovery and 
genotyping
 FreeBayes is a Bayesian genetic variant detector designed to find
 small polymorphisms, specifically SNPs (single-nucleotide
 polymorphisms), indels (insertions and deletions), MNPs
 (multi-nucleotide polymorphisms), and complex events (composite
 insertion and substitution events) smaller than the length of a
 short-read sequencing alignment.


Remark: This package is maintained by the Debian Med team at
   https://anonscm.debian.org/git/debian-med/freebayes.git

Bug#842177: Bug#847974: xmds2: FTBFS in stretch

[Adrian Bunk]

On Mon, Dec 12, 2016 at 05:42:37PM +, Santiago Vila wrote:
> Package: src:xmds2
> Version: 2.2.2+dfsg-2
> Severity: serious
> 
> Dear maintainer:
> 
> I tried to build this package in stretch with "dpkg-buildpackage -A"
> (which is what the "Arch: all" autobuilder would do to build it)
> but it failed:
>...
> warning: the size of octave_hdf5_id is smaller than the size of HDF5 hid_t
> warning: called from
> lorenz.m at line 2 column 3
> HDF5-DIAG: Error detected in HDF5 (1.10.0-patch1) thread 140615878277440:
>   #000: ../../../src/H5G.c line 464 in H5Gopen2(): not a location
> major: Invalid arguments to routine
> minor: Inappropriate type
>   #001: ../../../src/H5Gloc.c line 253 in H5G_loc(): invalid object ID
> major: Invalid arguments to routine
> minor: Bad value
> HDF5-DIAG: Error detected in HDF5 (1.10.0-patch1) thread 140615878277440:
>   #000: ../../../src/H5Gdeprec.c line 796 in H5Gget_num_objs(): not a 
> location ID
> major: Invalid arguments to routine
> minor: Inappropriate type
>   #001: ../../../src/H5Gloc.c line 253 in H5G_loc(): invalid object ID
> major: Invalid arguments to routine
> minor: Bad value
> HDF5-DIAG: Error detected in HDF5 (1.10.0-patch1) thread 140615878277440:
>   #000: ../../../src/H5G.c line 725 in H5Gclose(): not a group
> major: Invalid arguments to routine
> minor: Inappropriate type
>...
> The build history I keep is like this:
> 
> Status: successful  xmds2_2.2.2+dfsg-2_amd64-20161118T125207Z
> Status: successful  xmds2_2.2.2+dfsg-2_amd64-20161123T025916Z
> Status: successful  xmds2_2.2.2+dfsg-2_amd64-20161128T001945Z
> Status: successful  xmds2_2.2.2+dfsg-2_amd64-20161202T231309Z
> Status: failed  xmds2_2.2.2+dfsg-2_amd64-20161207T065906Z
> Status: failed  xmds2_2.2.2+dfsg-2_amd64-20161208T214652Z
> Status: failed  xmds2_2.2.2+dfsg-2_amd64-20161208T214639Z
> Status: failed  xmds2_2.2.2+dfsg-2_amd64-20161208T214702Z
> 
> Something happened in stretch between 2016-12-02 and 2016-12-07
> that made this package to FTBFS.

What happened was the hdf5 transition.

Gilles, you seem to have somehow missed xmds2 in your transition 
planning?

> Please tell me if you need a full build log, and I will attach it.
> 
> (Using sbuild on a single CPU virtual machine, it always fails for me,
> on different machines, so it should be easy to reproduce).
> 
> Thanks.

cu
Adrian

-- 

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

Bug#851300: unblock: utopia-documents/3.0.0-1

[Mattia Rizzolo]

On Fri, Jan 13, 2017 at 03:24:12PM -0500, Yaroslav Halchenko wrote:
> Could you please clarify, since this package was in testing already and 
> wasn't kicked out, why it can't migrate now?

ahem, the package was removed more than one year ago¹, and until that
upload had 3 RC bugs (+1²).

¹ https://tracker.debian.org/news/726692
² https://bugs.debian.org/825703

> Jan 5: soft freeze
>  Deadline for: 
> * New (source) packages in stretch 
> * Letting packages re-enter stretch (if they have been removed) 
> Updates to existing packages in stretch will continue as normal.

Except that this was not an update to an existing package, it's NEW in
stretch.

-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
more about me:  https://mapreri.org : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


signature.asc
Description: PGP signature

Bug#851305: onboard doesn't show any information in mate-session-properties

[Jeremy Bicha]

On 13 January 2017 at 15:32, shirish शिरीष  wrote:
> Onboard doesn't show/share any description when opened up in
> mate-session-properties. Sharing a picture for the same. Look forward
> to seeing this fixed.

I thought /etc/xdg/autostart/onboard-autostart.desktop had
NoDisplay=true set so you should not see it in the "Startup
Applications" app or whatever MATE calls it.

Thanks,
Jeremy Bicha

Bug#834921: python-ws4py: FTBFS on single CPU machines

[Adrian Bunk]

On Thu, Dec 08, 2016 at 05:47:52PM +0100, Santiago Vila wrote:
> retitle 834921 python-ws4py: FTBFS on single CPU machines
> thanks
> 
> I tried to build this package 200 times today and it failed 200 times.
> Then I tried once with a 2-CPU machine and it built ok.
> 
> Therefore, to reproduce, please try building on a single-CPU machine.

What Lucas has reported in #851043 looks like the same test failure.

Lucas, I assume you were not using a single CPU machine?

> Thanks.

cu
Adrian

-- 

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

Bug#851253: bootstrap build failure: install: cannot stat 'build-deb/.libs/test-udev': No such file or directory

[Michael Biebl]

Control: tags -1  moreinfo

Am 13.01.2017 um 19:28 schrieb Helmut Grohne:
> Control: tags -1 - moreinfo
> 
> On Fri, Jan 13, 2017 at 05:02:15PM +0100, Michael Biebl wrote:
>> Control: tags -1 + moreinfo
> 
> Adding moreinfo without asking a question doesn't make any sense.
> 

Ok, then let's try again: Please find out why no .libs/test-udev is
created. I thought this was obvious but I'm happy to spell it out.


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



signature.asc
Description: OpenPGP digital signature

Bug#851305: onboard doesn't show any information in mate-session-properties

[shirish शिरीष]

Package: onboard
Version: 1.3.0-1
Severity: minor

Dear Maintainer,
Onboard doesn't show/share any description when opened up in
mate-session-properties. Sharing a picture for the same. Look forward
to seeing this fixed.

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

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

Versions of packages onboard depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.26.0-2
ii  gir1.2-gdkpixbuf-2.0 2.36.2-1
ii  gir1.2-glib-2.0  1.50.0-1
ii  gir1.2-gtk-3.0   3.22.5-1
ii  gir1.2-pango-1.0 1.40.3-3
ii  iso-codes3.72-1
ii  libc62.24-8
ii  libcairo-gobject21.14.8-1
ii  libcairo21.14.8-1
ii  libcanberra0 0.30-3
ii  libdconf10.26.0-2
ii  libgcc1  1:6.2.1-5
ii  libgdk-pixbuf2.0-0   2.36.2-1
ii  libglib2.0-0 2.50.2-2
ii  libgtk-3-0   3.22.5-1
ii  libhunspell-1.4-01.4.1-2+b1
ii  libpango-1.0-0   1.40.3-3
ii  libpangocairo-1.0-0  1.40.3-3
ii  librsvg2-common  2.40.16-1
ii  libstdc++6   6.2.1-5
ii  libx11-6 2:1.6.4-2
ii  libxi6   2:1.7.8-2
ii  libxkbfile1  1:1.0.9-2
ii  libxtst6 2:1.2.3-1
ii  onboard-common   1.3.0-1
ii  python3  3.5.1-4
ii  python3-cairo1.10.0+dfsg-5+b1
ii  python3-dbus 1.2.4-1
ii  python3-gi-cairo 3.22.0-2
pn  python3:any  

Versions of packages onboard recommends:
ii  gir1.2-appindicator3-0.1  0.4.92-4
ii  gir1.2-atspi-2.0  2.22.0-5
ii  onboard-data  1.3.0-1
ii  xdg-utils 1.1.1-1

Versions of packages onboard suggests:
ii  mousetweaks  3.12.0-1

-- no debconf information


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

Bug#851300: unblock: utopia-documents/3.0.0-1

[Yaroslav Halchenko]

On January 13, 2017 2:22:43 PM EST, Mattia Rizzolo  wrote:
>On Fri, Jan 13, 2017 at 02:11:03PM -0500, Yaroslav Halchenko wrote:
>> Please unblock package utopia-documents
>> 
>> It was uploaded in time to propagate to testing before the freeze
>point
>
>It wasn't.
>It was uploaded the 29th Dec, 3 days too late (last good day was the
>26th, so 10 days later would have been the 5th of Jan, day of the
>freeze).

Could you please clarify, since this package was in testing already and wasn't 
kicked out, why it can't migrate now?

Jan 5: soft freeze
 Deadline for: 
* New (source) packages in stretch 
* Letting packages re-enter stretch (if they have been removed) 
Updates to existing packages in stretch will continue as normal.

Bug#851304: tomcat8 use 100% cpu time

[RickLinux]

Package: tomcat8
Version: 8.0.14-1+deb8u6
Severity: important

Dear Maintainer,

I noticed a bump in CPU load up to 100% per CPU.
It appear from tomcat8-8.0.14-1+deb8u4 and up.

Here how to create the bug.

http://localhost:8080, no problem.
https://localhost:8443, no problem (need to create a certificate).
https://localhost:8080, 100% cpu load.

I use default config coming from stable without any modification to them.
The problem still exist.

If it can help, I tried with apache-tomcat-8.0.39 from apache's site and
the server operate normaly even if I try the requests above.

RickLinux

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

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

Versions of packages tomcat8 depends on:
ii  adduser3.113+nmu3
ii  debconf [debconf-2.0]  1.5.56
ii  tomcat8-common 8.0.14-1+deb8u6
ii  ucf3.0030

Versions of packages tomcat8 recommends:
ii  authbind  2.1.1

Versions of packages tomcat8 suggests:
pn  libtcnative-1 
pn  tomcat8-admin 
pn  tomcat8-docs  
pn  tomcat8-examples  
pn  tomcat8-user  

-- debconf information:
  tomcat8/groupname: tomcat8
  tomcat8/javaopts: -Djava.awt.headless=true -Xmx128m -XX:+UseConcMarkSweepGC
  tomcat8/username: tomcat8

Bug#850733: [Reportbug-maint] Bug#850733: Crashes with "TypeError: GObject.__init__() takes exactly 0 arguments (1 given)"

[Sandro Tosi]

Hey Simon,
would you be able to have a look at this? it looks like it's the
current issue every user of the GTK interface has. thanks in advance!

On Mon, Jan 9, 2017 at 2:21 PM, James Clarke  wrote:
> Package: reportbug
> Version: 7.1.2
> Tags: patch
> Severity: important
>
> When I try to use the GTK3 backend to report a bug, I get the following
> stack trace:
>
>> Traceback (most recent call last):
>>   File "/usr/bin/reportbug", line 2233, in 
>> main()
>>   File "/usr/bin/reportbug", line 1107, in main
>> return iface.user_interface()
>>   File "/usr/bin/reportbug", line 2149, in user_interface
>> package, severity, mode, charset=charset, tags=tags)
>>   File "/usr/bin/reportbug", line 182, in handle_editing
>> editor, charset)
>>   File "/usr/lib/python3/dist-packages/reportbug/ui/gtk2_ui.py", line 1561, 
>> in func
>> op = klass(parent)
>>   File "/usr/lib/python3/dist-packages/reportbug/ui/gtk2_ui.py", line 539, 
>> in __init__
>> self.widget = self.create_widget()
>>   File "/usr/lib/python3/dist-packages/reportbug/ui/gtk2_ui.py", line 1173, 
>> in create_widget
>> expander = Gtk.Expander("Other system information")
>> TypeError: GObject.__init__() takes exactly 0 arguments (1 given)
>
> This is because, while a lot of the constructors have been overridden by
> PyGObject to handle the deprecated form, Expander has not been
> overridden, so the explicit form has to be used. Patch attached.
> Unfortunately, after applying it, it now crashes with:
>
>> (reportbug:15278): Gtk-CRITICAL **: gtk_text_attributes_ref: assertion
>> 'values != NULL' failed
>>
>> (reportbug:15278): Gtk-CRITICAL **: gtk_text_attributes_ref: assertion
>> 'values != NULL' failed
>>
>> (reportbug:15278): Pango-CRITICAL **: pango_layout_new: assertion
>> 'context != NULL' failed
>> [1]15278 segmentation fault  reportbug src:pymongo
>
> Putting in prints doesn't seem to help; the exact location is
> non-deterministic from what I can tell. I would guess there are some UI
> interactions happening not on the main UI thread.
>
> Regards,
> James
>
> ___
> Reportbug-maint mailing list
> reportbug-ma...@lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reportbug-maint



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

Bug#751902: bug 751902

[Alexander Zangerl]

On Mon, 09 Jan 2017 23:17:05 +0100, Moritz Muehlenhoff writes:
>Given that this is unfixed upstream for years, let's exclude the backend from
>the Debian binary package?

no, i don't want to do that.

as of python-boto 2.6, certificate validation is auto-enabled. pity
that that's not in debian yet... 
http://docs.pythonboto.org/en/latest/releasenotes/v2.6.0.html (or is it 2.45? 
utter confusion seems to reign over there...)

having looked at this now it seems easy to simply hack
the 'mandatory not optional' part into the debian version.

regards
az



-- 
Alexander Zangerl + GPG Key 2FCCF66BB963BD5F + http://snafu.priv.at/
cc:Mail is a wonderful application, as long as you don't want to
read or send mail. -- Jan van den Broek


signature.asc
Description: Digital Signature

Bug#850790: cloud.debian.org: Distribute Debian cloud images to LXD

[Jeremy Bicha]

Ok, well not having openssh-server installed is a bit unexpected for me.

However, my main issue is with cloud-init being pre-installed. If
that's in place, I can easily add openssh-server and you can easily
remove it so it's not as important which is decided. Also, I'd prefer
to have root disabled from the beginning and log in with an admin user
account using an SSH key, which I can easily do with cloud-init.

I think cloud-init is more or less a standard for a basic Linux server
image these days.

Note that many of cloud-init's tasks are only run on the first boot.
So installing cloud-init later does not do any good. Instead I have to
configure everything by hand or by script when I already have a
cloud-init config I could have used.

Thanks,
Jeremy Bicha

Bug#851303: prints debug output

[Peter Palfrader]

Package: ipe
Version: 7.2.6-1
Severity: normal

Hi,

ipe in stretch currently prints debug output to stdout/err:

$ ipe figs/foo.pdf
wheel_zoom  0.47true
wheel_zoom  0.4 true
wheel_zoom  0.53true
wheel_zoom  0.67true
wheel_zoom  1.06667 true
wheel_zoom  0.47true
wheel_zoom  1.0 true
wheel_zoom  1.06667 true
wheel_zoom  1.0 true
wheel_zoom  1.06667 true
wheel_zoom  0.8 true
wheel_zoom  0.8 true
wheel_zoom  0.47true
wheel_zoom  0.53true
wheel_zoom  0.53true
wheel_zoom  0.067   true
wheel_zoom  -0.067  true
wheel_zoom  -0.067  true
wheel_zoom  -0.067  true

It probably shouldn't.
-- 
|  .''`.   ** Debian **
  Peter Palfrader   | : :' :  The  universal
 https://www.palfrader.org/ | `. `'  Operating System
|   `-https://www.debian.org/

Bug#850421: libsqlcipher0: qTox segfaults with distro provided libsqlcipher0

[Hans-Christoph Steiner]

Rolling back to 3.2.0-1 is not really an option for stretch, since it
ships with openssl 1.1, and the only change in 3.2.0-2 is making
sqlcipher work with openssl 1.1.  It would be good to get 3.4.0
included, perhaps that will help.

I'm currently not using sqlcipher on the desktop at all, so I'm not well
positioned to do this work.  I can definitely review and upload changes.

Bug#829180: appears to be failing because of fsck

[Daniel Pocock]

On 15/12/16 11:37, Michael Biebl wrote:
> Am 15.12.2016 um 07:31 schrieb Daniel Pocock:
>
>> Please look more closely ... 3 lines after that it says the fsck has
>> "Started" and then it gives another line about "cgroup is empty"
>>
>> Could that just be a fault with re-ordering the log entries in
>> journald?  Or maybe it is starting fsck twice?
>>
> No, that message is printed *after* the job has finished:
> Starting foo.service [job is about to be executed]
> ...do stuff...
> Started foo.service [job is finished]
>
> Note the Start*ing* vs Start*ed*
>
>


I had a closer look and used


tune2fs -C 26 /dev/mapper/vg00-foo


to increment the mount count and force a check on the next boot


Watching the console as it booted, I notice the "Started" line only
appears on the console as the fsck is finishing


The word "Started" seems out of place in this context


As suggested in the github discussion[1], I've put in a substitute
/bin/mount script to try and catch more details.  Can you suggest
anything else I should try either


a) to include in my /bin/mount script?

b) to test after the mount fails again?  (it doesn't happen every boot)


Regards,

Daniel



1. https://github.com/systemd/systemd/issues/4812#issuecomment-265928415

Bug#843848: ifupdown2: diversion handling broken

[Julien Fortin]

Hello Andreas,

Sorry, I totally missed this email as I was in vacation.
I will look at this issue today.

Thank you.
Julien

On Fri, Jan 13, 2017 at 1:38 PM, Andreas Beckmann  wrote:

> Ping? ifupdown2 is at the risk of being autoremoved ... and won't be in
> stretch if this bug is not fixed in time.
>
> Andreas
>

Bug#847935: [Pkg-fonts-devel] Bug#847935: Bug#847935: Bug#847935: Bug#847935: MICRO sign does not show

[Fabian Greffrath]

Erik,

could you please do me a favour and test a package for me? Please find
the debdiff attached.

Please download this package and install it. You should install it
directly using dpkg and downgrade to the official package from stable
immediately once the tests are over:

https://people.debian.org/~fabian/jessie/libpoppler46_0.26.5-2+deb8u1.1_amd64.deb

Then, please install the fonts-texgyre package again and see if the
"mu" glyph on the test page you pointed to in your initial bug report
renders properly. Please make sure that the text is rendered with the
TeX Gyre OTF fonts.

Also, while at it, could you please check if the PDFs pointed to in
these bug reports render properly as well -- in Evince, that is, not in
e.g. Iceweasel's integrated PDF viewer.

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=773271

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=807693

Thank you so much!

 - Fabian

diff -Nru poppler-0.26.5/debian/changelog poppler-0.26.5/debian/changelog
--- poppler-0.26.5/debian/changelog	2016-04-29 13:16:36.0 +0200
+++ poppler-0.26.5/debian/changelog	2017-01-13 17:09:17.0 +0100
@@ -1,3 +1,12 @@
+poppler (0.26.5-2+deb8u1.1) jessie; urgency=medium
+
+  * Non-maintainer upload.
+  * Backport upstream commit 8d5778feeb3c6cd932ecd7abeba7d1e670d2af66 to try
+finding glyphs in substitute fonts by unicode value.
+(Closes: #847935, #773271, #807693)
+
+ -- Fabian Greffrath   Fri, 13 Jan 2017 17:09:17 +0100
+
 poppler (0.26.5-2+deb8u1) jessie-security; urgency=medium
 
   * Backport upstream commit b3425dd3261679958cd56c0f71995c15d2124433 to fix
diff -Nru poppler-0.26.5/debian/patches/series poppler-0.26.5/debian/patches/series
--- poppler-0.26.5/debian/patches/series	2016-04-29 13:16:36.0 +0200
+++ poppler-0.26.5/debian/patches/series	2017-01-13 17:09:17.0 +0100
@@ -1,3 +1,4 @@
 upstream_Map-Standard-Expert-encoding-ligatures-to-AGLFN-name.patch
 qt-visibility.diff
 upstream_Do-not-crash-on-invalid-files.patch
+upstream_cairo-try-finding-glyphs-in-substitute-fonts-by-unic.patch
diff -Nru poppler-0.26.5/debian/patches/upstream_cairo-try-finding-glyphs-in-substitute-fonts-by-unic.patch poppler-0.26.5/debian/patches/upstream_cairo-try-finding-glyphs-in-substitute-fonts-by-unic.patch
--- poppler-0.26.5/debian/patches/upstream_cairo-try-finding-glyphs-in-substitute-fonts-by-unic.patch	1970-01-01 01:00:00.0 +0100
+++ poppler-0.26.5/debian/patches/upstream_cairo-try-finding-glyphs-in-substitute-fonts-by-unic.patch	2017-01-13 17:06:20.0 +0100
@@ -0,0 +1,29 @@
+From 8d5778feeb3c6cd932ecd7abeba7d1e670d2af66 Mon Sep 17 00:00:00 2001
+From: Adrian Johnson 
+Date: Tue, 19 Jul 2016 22:58:39 +0930
+Subject: [PATCH 01/91] cairo: try finding glyphs in substitute fonts by
+ unicode value
+
+if the glyph name can not be found in the substitute font, try
+converting the name to unicode value in see of the font cmap has a
+mapping for the character.
+
+Bug 96994
+---
+ poppler/CairoFontEngine.cc | 5 +
+ 1 file changed, 5 insertions(+)
+
+--- a/poppler/CairoFontEngine.cc
 b/poppler/CairoFontEngine.cc
+@@ -459,6 +459,11 @@ CairoFreeTypeFont *CairoFreeTypeFont::cr
+   if ((name = enc[i])) {
+ 	codeToGID[i] = FT_Get_Name_Index(face, (char*)name);
+ 	if (codeToGID[i] == 0) {
++	  Unicode u;
++	  u = globalParams->mapNameToUnicodeText (name);
++	  codeToGID[i] = FT_Get_Char_Index (face, u);
++	}
++	if (codeToGID[i] == 0) {
+ 	  name = GfxFont::getAlternateName(name);
+ 	  if (name) {
+ 	codeToGID[i] = FT_Get_Name_Index(face, (char*)name);


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