Bug#833371:

2016-08-03 Thread derzis
also colors of the graph in the message tray and in system monitor are 
not the same both on processor and ram.


roman călin



Bug#833419: midori gives black screen on one of my couputers

2016-08-03 Thread 積丹尼 Dan Jacobson
Package: midori
Version: 0.5.12~wk2-exp1

On my j2 computer
$ mv .config/midori .elsewhere
$ midori
juat gives a black FAQ file, or a black anyfile I can't browse anything
with it. Same as doing
$ HOME=/tmp midori

However doing
# su - nobody -c 'HOME=/tmp/ZP; midori'
works fine.

Other browsers work fine.

Yes I know you cannot reproduce it.

Nor can I -- on my other machines.

Only this Thinkpad R50e.

As I move the mouse over the black area, link previews flash at the
bottom, meaning they are still there.

Even if I do
$ chmod 0 ~
$ midori
it is still black.


Bug#833418: Debian version is 0.5.12 but midori says it is 0.5.11

2016-08-03 Thread 積丹尼 Dan Jacobson
Package: midori
Version: 0.5.12~wk2-exp1
Severity: minor

MENU->About says midori 0.5.11,
despite the Debian version.



Bug#833417: mupdf: CVE-2016-6525: heap overflow in pdf_load_mesh_params()

2016-08-03 Thread Salvatore Bonaccorso
Source: mupdf
Version: 1.5-1
Severity: important
Tags: security upstream patch

Hi,

the following vulnerability was published for mupdf.

CVE-2016-6525[0]:
heap overflow in pdf_load_mesh_params()

If you fix the vulnerability please also make sure to include the
CVE (Common Vulnerabilities & Exposures) id in your changelog entry.

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2016-6525

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore



Bug#833416: icu FTCBFS: cross build support was removed in debhelper conversion

2016-08-03 Thread Helmut Grohne
Source: icu
Version: 57.1-1
Severity: important
Justification: FTCBFS but built before, transitive build closure of essential
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap

Hi,

It seems that cross build support got discarded in converting icu from
cdbs to debhelper. Can you put it back? Patch attached.

Helmut
diff --minimal -Nru icu-57.1/debian/changelog icu-57.1/debian/changelog
--- icu-57.1/debian/changelog   2016-08-03 20:49:39.0 +0200
+++ icu-57.1/debian/changelog   2016-08-04 06:23:24.0 +0200
@@ -1,3 +1,10 @@
+icu (57.1-1.2) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Implement cross build support again for debhelper packaging (closes: #-1).
+
+ -- Helmut Grohne   Thu, 04 Aug 2016 06:01:25 +0200
+
 icu (57.1-1.1) unstable; urgency=medium
 
   * Non-maintainer upload.
diff --minimal -Nru icu-57.1/debian/control icu-57.1/debian/control
--- icu-57.1/debian/control 2016-08-03 20:49:39.0 +0200
+++ icu-57.1/debian/control 2016-08-04 06:09:30.0 +0200
@@ -3,7 +3,7 @@
 Priority: optional
 Maintainer: Laszlo Boszormenyi (GCS) 
 Standards-Version: 3.9.8
-Build-Depends: debhelper (>> 9~), dpkg-dev (>= 1.16.1~), autotools-dev, g++ 
(>= 4:5-0), g++-5 (>= 5.2.1-10)
+Build-Depends: debhelper (>> 9~), dpkg-dev (>= 1.16.1~), autotools-dev
 Build-Depends-Indep: doxygen (>= 1.7.1)
 Build-Conflicts: clang
 Homepage: http://www.icu-project.org
diff --minimal -Nru icu-57.1/debian/rules icu-57.1/debian/rules
--- icu-57.1/debian/rules   2016-03-27 18:25:14.0 +0200
+++ icu-57.1/debian/rules   2016-08-04 06:28:55.0 +0200
@@ -1,6 +1,8 @@
 #!/usr/bin/make -f
 # -*- makefile -*-
 
+include /usr/share/dpkg/architecture.mk
+
 # Uncomment this to turn on verbose mode.
 #export DH_VERBOSE=1
 
@@ -10,9 +12,16 @@
dh_clean
find $(CURDIR)/source/ \( -name Makefile -o -name pkgdataMakefile \) \
-exec rm {} \;
+   rm -Rf build-native
 
 override_dh_auto_configure:
+ifeq ($(DEB_BUILD_ARCH),$(DEB_HOST_ARCH))
dh_auto_configure -- --enable-static
+else
+   dh_auto_configure -B build-native -- --host=$(DEB_BUILD_GNU_TYPE)
+   dh_auto_build -B build-native
+   dh_auto_configure -- --enable-static 
--with-cross-build=$(CURDIR)/build-native
+endif
 
 override_dh_auto_build:
dh_auto_build --parallel


Bug#833415: ring: no dialpad

2016-08-03 Thread Fulano Diego Perez

sorry - should mention i found where to enter a number

(i thought the search bar was something else, not where to enter digits)

then made a call, but could not find a DTMF - touch pad to enter numbers
- impossible to call a hotline where they are required to continue call



Bug#833415: ring: no dialpad

2016-08-03 Thread Fulano Diego Perez


Package: ring
Version: 20160726.1.da5343f~dfsg1-1
Severity: normal









where is the dialpad ?

i have a SIP account configured and signed in, can't make a call...



Re Versions of packages ring depends on: (reportbug doesn't list them
properly)

libclutter-1.0-0 is already the newest version (1.26.0-2).
libclutter-1.0-0 set to manually installed.
libclutter-gtk-1.0-0 is already the newest version (1.8.0-1).
libclutter-gtk-1.0-0 set to manually installed.
dconf-gsettings-backend is already the newest version (0.26.0-1).
dconf-gsettings-backend set to manually installed.
libjson-glib-1.0-0 is already the newest version (1.2.0-1).
libjson-glib-1.0-0 set to manually installed.
libnotify4 is already the newest version (0.7.6-2).
libsecret-1-0 is already the newest version (0.18.3-1).
libxkbcommon0 is already the newest version (0.5.0-1).
libwayland-cursor0 is already the newest version (1.11.0-2).
libwayland-cursor0 set to manually installed.






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

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

Versions of packages ring depends on:
pn  dconf-gsettings-backend | gsettings-backend  
ii  libappindicator3-1   0.4.92-4
ii  libatk1.0-0  2.20.0-1
ii  libc62.23-4
ii  libcairo-gobject21.14.6-1+b1
ii  libcairo21.14.6-1+b1
ii  libcamel-1.2-57  3.20.4-2
pn  libclutter-1.0-0 
pn  libclutter-gtk-1.0-0 
ii  libcogl-pango20  1.22.0-2
ii  libcogl-path20   1.22.0-2
ii  libcogl201.22.0-2
ii  libdbus-1-3  1.10.8-1
ii  libdbus-glib-1-2 0.106-1
ii  libdbusmenu-glib412.10.2-1
ii  libdrm2  2.4.70-1
ii  libebackend-1.2-10   3.20.4-2
ii  libebook-1.2-16  3.20.4-2
ii  libebook-contacts-1.2-2  3.20.4-2
ii  libedata-book-1.2-25 3.20.4-2
ii  libedataserver-1.2-213.20.4-2
ii  libegl1-mesa [libegl1-x11]   11.2.2-1
ii  libgbm1  11.2.2-1
ii  libgcc1  1:6.1.1-10
ii  libgdk-pixbuf2.0-0   2.34.0-1
ii  libglib2.0-0 2.48.1-2
ii  libgtk-3-0   3.20.6-2
pn  libjson-glib-1.0-0   
ii  libnm-glib4  1.2.2-2
ii  libnm-util2  1.2.2-2
pn  libnotify4   
ii  libnspr4 2:4.12-2
ii  libnss3  2:3.23-2
ii  libpango-1.0-0   1.40.1-1
ii  libpangocairo-1.0-0  1.40.1-1
ii  libqrencode3 3.4.4-1+b1
ii  libqt5core5a 5.6.1+dfsg-3
ii  libqt5dbus5  5.6.1+dfsg-3
pn  libsecret-1-0
ii  libsoup2.4-1 2.54.1-1
ii  libsqlite3-0 3.13.0-1
ii  libstdc++6   6.1.1-10
ii  libwayland-client0   1.11.0-2
pn  libwayland-cursor0   
ii  libwayland-egl1-mesa [libwayland-egl1]   11.2.2-1
ii  libwayland-server0   1.11.0-2
ii  libx11-6 2:1.6.3-1
ii  libxcomposite1   1:0.4.4-1
ii  libxdamage1  1:1.1.4-2+b1
ii  libxext6 2:1.3.3-1
ii  libxfixes3   1:5.0.2-1
ii  libxi6   2:1.7.6-1
pn  libxkbcommon0
ii  libxml2  2.9.4+dfsg1-1
ii  libxrandr2   2:1.5.0-1
ii  ring-daemon  20160726.1.da5343f~dfsg1-1

ring recommends no packages.

ring suggests no packages.

-- no debconf information



Bug#833414: RFS: 9wm/1.3.7-1

2016-08-03 Thread Jacob Adams
Package: sponsorship-requests
Severity: normal

  Dear mentors,

  I am looking for a sponsor for my package "9wm"

 * Package name: 9wm
   Version : 1.3.7-1
   Upstream Author : Neale Pickett 
 * URL : https://github.com/nealey/9wm
 * License : Expat
   Section : x11

  It builds those binary packages:

9wm   - X11 window manager inspired by the Plan 9's rio

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

  https://mentors.debian.net/package/9wm


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

dget -x
https://mentors.debian.net/debian/pool/main/9/9wm/9wm_1.3.7-1.dsc

  Changes since the last upload:

9wm (1.3.7-1) unstable; urgency=medium

  * New upstream version
  * Bump standards version to 3.9.8, no changes
  * md extension on README
 -- Jacob Adams   Wed, 03 Aug 2016 22:32:34 -0400

  Regards,

-- 
Jacob Adams
GPG Key: AF6B 1C26 E2D0 A988 432B  94F4 24C0 2B85 B59F E5A9



signature.asc
Description: OpenPGP digital signature


Bug#833409: libbson: please make the build reproducible

2016-08-03 Thread Chris Lamb
> Thanks, as with Bug#831659 for the dependent library libmongoc, I've
> filed this upstream here:
> 
> https://jira.mongodb.org/browse/CDRIVER-1399
> 
> It's fixed in upstream and will be released in the next couples weeks
> as libbson 1.4.0 and libmongoc 1.4.0, and re-uploaded to Debian.

Wow, fast work. Thanks!


Regards,

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



Bug#805414: gdm3: disable pulseaudio to prevent capturing A2DP sink on session start

2016-08-03 Thread Matthew Gabeler-Lee
Package: gdm3
Version: 3.20.1-1
Followup-For: Bug #805414

It seems like gdm3 should not be claiming the A2DP audio interface, or
really _any_ audio interface when it is not 'active' / visible.

It needs the keyboard to accept passwords, but it doesn't prevent me from
using my keyboard after I log in ;)

I realize the PA bits are going to be (much) more complicated than the
keyboard example, but the principle applies I think.

Being ignorant of PA, I'm also a bit confused as to why A2DP is special
here.  Other sound devices aren't broken by gdm3 wanting to have sound
services available for accessibility, why is A2DP different here?



Bug#833409: libbson: please make the build reproducible

2016-08-03 Thread A. Jesse Jiryu Davis
Thanks, as with Bug#831659 for the dependent library libmongoc, I've
filed this upstream here:

https://jira.mongodb.org/browse/CDRIVER-1399

It's fixed in upstream and will be released in the next couples weeks
as libbson 1.4.0 and libmongoc 1.4.0, and re-uploaded to Debian.

On Wed, Aug 3, 2016 at 8:18 PM, Chris Lamb  wrote:
> Source: libbson
> Version: 1.3.5-1
> Severity: wishlist
> Tags: patch
> User: reproducible-bui...@lists.alioth.debian.org
> Usertags: timestamps
> X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org
>
> Hi,
>
> Whilst working on the "reproducible builds" effort [0], we noticed
> that libbson could not be built reproducibly.
>
> Patch attached.
>
>  [0] https://wiki.debian.org/ReproducibleBuilds
>
>
> Regards,
>
> --
>   ,''`.
>  : :'  : Chris Lamb
>  `. `'`  la...@debian.org / chris-lamb.co.uk
>`-



Bug#833413: flashplugin-nonfree: get-upstream-version.pl fails without updating

2016-08-03 Thread Jesse Weinstein
Package: flashplugin-nonfree
Version: 1:3.6.1
Severity: important

Dear Maintainer,

If the cached version of get-upstream-version.pl uses the old, wrong 
User-Agent, it will not update itself, preventing users from receving updates.
I think the only way around this is to release an update to the package, that 
deletes the cached version of get-upstream-version.pl.



Bug#833412: opencl-headers: OpenCL 2.1 headers are out

2016-08-03 Thread Andreas Kloeckner
Package: opencl-headers
Version: 2.0~svn32091-2
Severity: wishlist

Dear Maintainer,

The OpenCL 2.1 headers have been released, and ICDs are starting to implement
it (clCreateProgramWithIL is what I'm interested in--reportedly present in the
Intel implementation).

Thanks!
Andreas

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

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

-- no debconf information



Bug#832973: vile-filters: vile filter for mail broken

2016-08-03 Thread Thomas Dickey
On Wed, Aug 03, 2016 at 04:22:38PM +1000, Brendan O'Dea wrote:
> On Tue, Aug 02, 2016 at 09:30:38PM -0400, Thomas Dickey wrote:
> >(got to that point - attaching a diff which built with 2.6.0)
> 
> I'm not entirely convinced that this change captures what you're trying to
> achieve with 2.6.0, as the second expression to sed makes LEX_SUBVERSION in
> this case equal to 2, which is the major version, and the following

fixed...

> comparisons don't make sense in that case.  My inclination would be to change
> the test for 2006000 to -ge and be done with it:
> 
>   elif test $cf_lex_version -ge 2006000
> 
> You should probably then also drop this:
> 
> -e 's/\.[0-9.]*//'`

agreed - it seems to be superfluous with the long line just before
 
> 
> as I'm not sure that it adds anything in the 2.5.x case.  This is all mostly
> cosmetic, as the changes to filters.h actually fixed the problem for 2.6.0.

actually part of configure.in was needed (the line where I added "maybe").
The rest of the scripting was of course to try to generalize for the next 
version.

> To add to the hilarity, Debian unstable just upgraded to flex 2.6.1 which
> elicits:
> 
>   checking version of flex... 2.6.1
>   configure: WARNING: Sorry - your version of flex is too unstable: 2.6.1
> 
> which would be the same message you would see for 2.6.0 if you make the change
> suggested above.

I tidied this up (attached)

-- 
Thomas E. Dickey 
http://invisible-island.net
ftp://invisible-island.net


vile-9.8r4.patch.gz
Description: Binary data


signature.asc
Description: Digital signature


Bug#833116: fgetty: Incorrect keystroke interpretation

2016-08-03 Thread Dmitry Bogatov

> > > When trying to login with fgetty, I could read my password on the screen 
> > > while typing. Did not continue.
> > > ngetty + login behaves good
> > > ngetty + login1 will get in well, but no key press will echo on the 
> > > console.
> >
> > Sorry, I assumed you read C. This is intended behaviour. Please,
> > continue and tell, whether rest is OK. I expect terminal to be not in
> > good shape, but after `reset` I expect fancy letter to work.
>
> fgetty_patched + login1: � doesn't show up, (arg: 1) instead, even after 
> reset.
>
> ngetty + login1: no letter will show up after logging in, but they are
> there (except �); that is, if I (blindly) type

I am almost out of ideas. Let me sum all we have done:

 - problem raises in /bin/bash and /usr/bin/rc, but not in /bin/sh.
   Noteworthy, that /bin/sh does not link to libreadline.
 - problem still present, even if we remove every terminal-manipulation
   code from fgetty, login1, login2
 - problem happens with root and non-root logins
 - problem disappear in child process, and this child process have a bit
   different terminal configuration: -isig vs isig
 - problem happens without fgetty binary, with only login1 and login2.
 - `reset' does not help

Please, do following things:

 - set emacs (or anything that is interactive and does not link
   readline) as login shell and tell, whether bug arises
 - since you said that good shell and bad shell differs in terminal
   configuration, use `stty(1)' to configure bad shell as good one,
   and via-verse.
 - replace login1 with following shell script (extremely insecure,
   do not forget to revert)
#!/bin/bash
/bin/bash
   and test following cases:
 + ngetty with such login1
 + fgetty with such login1

-- 
Accept: text/plain, text/x-diff
Accept-Language: eo,en,ru
X-Web-Site: sinsekvu.github.io



Bug#833411: pam-python: accesses the internet during build

2016-08-03 Thread Chris Lamb
Source: pam-python
Version: 1.0.4-1
Severity: serious
Justification: Policy 4.9
User: la...@debian.org
Usertags: network-access

Dear Maintainer,

Whilst pam-python builds successfully on unstable/amd64, according to
Debian Policy 4.9 packages may not attempt network access during
a build.

  00:00:00.00 IP c99733671a81.45859 > 192.168.43.1.domain: 58524+ A? 
docs.python.org. (33)
  00:00:00.59 IP c99733671a81.45859 > 192.168.43.1.domain: 42317+ ? 
docs.python.org. (33)

  [..]

This appears to be caused by (at least) Sphinx's intersphinx mapping extension.
Please see #830186 for more information, including suggestions on how to fix it.

The full build log (including tcpdump output) is attached.


Regards,

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


pam-python.1.0.4-1.unstable.amd64.log.txt.gz
Description: Binary data


Bug#833410: dapl: please make the build reproducible

2016-08-03 Thread Chris Lamb
Source: dapl
Version: 2.1.8-1
Severity: wishlist
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: timestamps
X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org

Hi,

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

Patch attached.

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


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-
--- a/debian/control2016-08-03 18:45:47.592784395 -0400
--- b/debian/control2016-08-03 19:10:42.845894375 -0400
@@ -3,7 +3,7 @@
 Section: net
 Maintainer: OFED and Debian Developement and Discussion 

 Uploaders: Ana Beatriz Guerrero Lopez 
-Build-Depends: debhelper (>= 9), librdmacm-dev, libibverbs-dev (>= 1.1.2), 
autotools-dev
+Build-Depends: debhelper (>= 9), librdmacm-dev, libibverbs-dev (>= 1.1.2), 
autotools-dev, dh-autoreconf
 Standards-Version: 3.9.7
 Vcs-Git: git://anonscm.debian.org/pkg-ofed/dapl.git
 Vcs-Browser: https://anonscm.debian.org/gitweb/?p=pkg-ofed/dapl.git
--- a/debian/patches/0003-reproducible-build.patch  1969-12-31 
19:00:00.0 -0500
--- b/debian/patches/0003-reproducible-build.patch  2016-08-03 
19:07:55.795936660 -0400
@@ -0,0 +1,15 @@
+Description: Make the build reproducible
+Author: Chris Lamb 
+Last-Update: 2016-08-03
+
+--- dapl-2.1.8.orig/Makefile.am
 dapl-2.1.8/Makefile.am
+@@ -48,7 +48,7 @@ AM_CFLAGS = -g -Wall -D_GNU_SOURCE -DDAT
+ endif
+ 
+ AM_CFLAGS += -DMPXYD_CONF="\"$(sysconfdir)/mpxyd.conf\""
+-AM_CFLAGS += -DPACKAGE_DATE=$$(date +'%Y%m%d')
++AM_CFLAGS += -DPACKAGE_DATE=$$(date --utc 
--date="@$${SOURCE_DATE_EPOCH:-$$(date +%s)}" +'%Y%m%d')
+ 
+ sysconf_DATA = doc/dat.conf
+ 
--- a/debian/patches/series 2016-08-03 18:45:47.592784395 -0400
--- b/debian/patches/series 2016-08-03 19:07:54.187916559 -0400
@@ -1,2 +1,3 @@
 0001-Fix-typos-unkown-unknown.patch
 0002-typos-manpages.patch
+0003-reproducible-build.patch
--- a/debian/rules  2016-08-03 18:45:47.592784395 -0400
--- b/debian/rules  2016-08-03 19:10:33.165786669 -0400
@@ -4,4 +4,4 @@
 export DEB_BUILD_MAINT_OPTIONS = hardening=+all
 
 %:
-   dh $@ --with autotools-dev
+   dh $@ --with autotools-dev,autoreconf


Bug#833409: libbson: please make the build reproducible

2016-08-03 Thread Chris Lamb
Source: libbson
Version: 1.3.5-1
Severity: wishlist
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: timestamps
X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org

Hi,

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

Patch attached.

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


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-
--- a/debian/patches/0002_reproducible_build.patch  1969-12-31 
19:00:00.0 -0500
--- b/debian/patches/0002_reproducible_build.patch  2016-08-03 
19:59:31.672795427 -0400
@@ -0,0 +1,29 @@
+Description: Make the build reproducible
+Author: Chris Lamb 
+Last-Update: 2016-08-03
+
+--- libbson-1.3.5.orig/doc/mallard2man.py
 libbson-1.3.5/doc/mallard2man.py
+@@ -163,7 +163,12 @@ class Convert(object):
+ self._write('\n')
+ 
+ def _generateHeader(self):
+-year = datetime.utcnow().year
++try:
++mtime = 
datetime.utcfromtimestamp(int(os.environ['SOURCE_DATE_EPOCH']))
++year = mtime.year
++except KeyError:
++mtime = datetime.fromtimestamp(int(os.stat(self.inFile).st_mtime))
++year = datetime.utcnow().year
+ self._writeComment('This manpage is Copyright (C) %s %s' % (year, 
COPYRIGHT_HOLDER))
+ self._writeComment('')
+ self._writeComment(
+@@ -175,7 +180,7 @@ class Convert(object):
+ "Free Documentation License\".")
+ self._writeComment('')
+ 
+-date = 
datetime.fromtimestamp(int(os.stat(self.inFile).st_mtime)).strftime('%Y-%m-%d')
++date = mtime.strftime('%Y-%m-%d')
+ title = self.title.replace('()','').upper()
+ self._write('.TH "%s" "%s" "%s" "%s"\n' % (title, self.section, date, 
GROUP))
+ self._write('.SH NAME\n')
--- a/debian/patches/series 2016-08-03 18:45:56.764275847 -0400
--- b/debian/patches/series 2016-08-03 19:59:45.473071418 -0400
@@ -1 +1,2 @@
 0001_use_system_yajl.patch
+0002_reproducible_build.patch


Bug#833408: amora-server: please make the build reproducible

2016-08-03 Thread Chris Lamb
Source: amora-server
Version: 1.2~svn+git2015.04.25-1
Severity: wishlist
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: timestamps
X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org

Hi,

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

Patch attached.

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


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-
--- a/debian/patches/reproducible_build.patch   1969-12-31 19:00:00.0 
-0500
--- b/debian/patches/reproducible_build.patch   2016-08-03 20:09:08.470954312 
-0400
@@ -0,0 +1,19 @@
+Description: Make the build reproducible
+Author: Chris Lamb 
+Last-Update: 2016-08-03
+
+--- amora-server-1.2~svn+git2015.04.25.orig/amora-cli/m4/auxdevel.m4
 amora-server-1.2~svn+git2015.04.25/amora-cli/m4/auxdevel.m4
+@@ -123,7 +123,11 @@ fi
+ AC_DEFUN([AC_DEVEL_MACROS],
+ [
+ 
+-ac_isodate="`date +%Y-%m-%d`"
++if test -n "$SOURCE_DATE_EPOCH"; then
++ac_isodate="`date --utc --date="@$SOURCE_DATE_EPOCH" +%Y-%m-%d`"
++else
++ak_isodate="`date +%Y-%m-%d`"
++fi
+ AC_SUBST(ac_isodate)
+ 
+ AC_ARG_ENABLE(warnings,
--- a/debian/patches/series 1969-12-31 19:00:00.0 -0500
--- b/debian/patches/series 2016-08-03 20:09:06.998940699 -0400
@@ -0,0 +1 @@
+reproducible_build.patch


Bug#794778: gcc-6 now

2016-08-03 Thread Adam Borowski
Control: retitle -1 Should update to gcc-6-doc packages

Now that the compiler itself defaults to gcc-6, the docs should follow suit.

-- 
An imaginary friend squared is a real enemy.



Bug#833405: nvidia-vulkan-icd: Missing conflict: /usr/share/vulkan/icd.d/nvidia_icd.json provided by 2 packages

2016-08-03 Thread Diederik de Haas
On donderdag 4 augustus 2016 01:52:28 CEST Andreas Beckmann wrote:
> are you upgrading from locally built packages that were built from SVN
> some time ago?

I am indeed. 



Bug#833405: nvidia-vulkan-icd: Missing conflict: /usr/share/vulkan/icd.d/nvidia_icd.json provided by 2 packages

2016-08-03 Thread Andreas Beckmann
On 2016-08-04 01:26, Diederik de Haas wrote:
> The mentioned file is also provide by nvidia-vulkan-common thus a
> conflicts relation should be added.
> 
> Unpacking nvidia-vulkan-common (364.19-1) ...
> dpkg: error processing archive
> /var/cache/apt/archives/nvidia-vulkan-common_364.19-1_amd64.deb
> (--unpack):
>  trying to overwrite '/usr/share/vulkan/icd.d/nvidia_icd.json', which is
>  also in package nvidia-vulkan-icd 364.19-1

are you upgrading from locally built packages that were built from SVN
some time ago?


Andreas



Bug#833407: Please put adt-virt-* binaries back onto PATH

2016-08-03 Thread Ian Jackson
Package: autopkgtest
Version: 4.0.2

I see that after installing a recent autopkgtest, I no longer have
adt-virt-schroot, adt-virt-null, etc.  I would like to suggest that
this change be reverted, for the following reasons:

My original design intent was that:

0. The autopkgtest virt server protocol is a generally useful
   protocol, both sides of which might reasonably be implemented by
   software outside of (and even unconnected with) autopkgtest.

1. Programs and packages other than autopkgtest - and even users -
   would be able to provide virt servers.  They are fairly simple to
   write (although it is somewhat easier with the the VirtSubproc
   python module).

2. Programs other than autopkgtest which could make use of the
   facilities provided by virt servers could support the adt virt
   server interface, to support a wide range of virt servers.

3. Users would be able to invoke a virt server by hand for debugging.
   (This is slightly annoying because of the url encoding, but this
   is not entirely fatal to this approach.)

4. Ultimately programs which had nothing to do with testing might
   speak the autopkgtest virt server protocol to virt servers which
   were written without testing in mind.

I see that 2 and half of 4 has already happened: sbuild has an
--adt-virt-server option.  sbuild expects to find the corresponding
program on PATH.

For 1 and the other half of 4 to work, the out-of-autopkgtest-tree
virt server ought to be on PATH, too.  And autopkgtest(1) ought to
find the server there.  Otherwise the out-of-tree server has to go in
/usr/share/autopkgtest/virt, which is not really its bailiwick.  (And
what if the virt server is a compiled machine executable and unsuitable
for /usr/share?)

I suggest that:
  - the virt servers should be moved back to /usr/bin/adt-virt-*
  - autopkgtest(1) should treat hyphen-less virt server names
the same way as chroot does: prefix them with `adt-virt-'.

The latter is a slightly annoying wrinkle, because it means that it is
no longer possible to have a virt server whose name does not contain a
hyphen.  One possible response to this difficulty would be to:
  - declare in the virt server spec that all virt server names
must contain hyphens
  - specify that programs which take a virt server name should
prepend `adt-virt-' to names which do not contain a hyphen

Thanks,
Ian.

-- 
Ian Jackson    These opinions are my own.

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



Bug#828663: Patch to fix

2016-08-03 Thread Thomas Goirand
Hi,

The attached patch fixes the issue. Please add it to the package and
upload. If you can't do it yourself, let me know, and I will.

Cheers,

Thomas Goirand (zigo)
Description: [Django 1.10] define TEMPLATES
Author: Thomas Goirand 
Forwarded: no
Bug-Debian: http://bugs.debian.org/828663
Last-Update: 2016-08-04

--- a/contact_form/runtests.py	2016-08-03 23:29:36.091231635 +
+++ b/contact_form/runtests.py	2016-08-03 23:28:32.184772423 +
@@ -44,13 +44,6 @@
 'SITE_ID': 1,
 'DEFAULT_FROM_EMAIL': 'cont...@example.com',
 'MANAGERS': [('Manager', 'nore...@example.com')],
-'TEMPLATES': [
-{
-'BACKEND': 'django.template.backends.django.DjangoTemplates',
-'DIRS': [ os.path.join(CONTACT_FORM_DIR, 'tests/templates'), ],
-'APP_DIRS': True,
-},
-]
 }
 
 


Bug#832713: systemd: after "systemd (231-1) unstable" update systemd-jurnald.service fails to start

2016-08-03 Thread Rick Thomas

> On Aug 3, 2016, at 3:58 PM, Felipe Sateler  wrote:
> 
> On 3 August 2016 at 16:44, Rick Thomas  wrote:
>> 
>> On Aug 3, 2016, at 9:06 AM, Felipe Sateler  wrote:
>> 
>>> On 1 August 2016 at 18:32, Rick Thomas  wrote:
 
 Thanks, Filipe!
 
 What do we have to do at this point to test this and then translate it 
 into a patch?
>>> 
>>> OK, so I have a proof-of-concept patch. Rick, could you test it in your 
>>> machine?
>> 
>> I’m afraid I don’t have the facilities or the expertise to turn this into a 
>> loadable kernel .deb .
>> 
>> If someone can provide an installable kernel .deb file for a Cuboxi4-Pro 
>> machine, I’ll he happy to test it.
> 
> This is a patch for systemd, not the kernel. I prepared a source
> package for easier testing. Do the following:
> 
> apt-get install dpkg-dev devscripts
> apt-get build-dep systemd
> dget https://people.debian.org/~fsateler/systemd_231-2.dsc
> cd systemd-231
> dpkg-buildpackage
> 
> That should leave you with several .debs (after a long time). Install
> libsystemd0 and systemd from those debs.

Great!  Thanks for the instructions.  I’ll give it a try soon.
Rick


Bug#833406: ITP: libgap -- A C library version of the GAP kernel

2016-08-03 Thread Jerome Benoit
Package: wnpp
Severity: wishlist
Owner: Jerome Benoit 

* Package name: libgap
  Version : 4.8.4
  Upstream Author : Volker Braun 
* URL : https://bitbucket.org/vbraun/libgap
* License : GPL-2+
  Programming Lang: C
  Description : A C library version of the GAP kernel

GAP is a system fo computational group theory. LibGAP contains a shared
library version of the GAP kernel, allowing you to directly talk to GAP
from your own C/C++ code.

Much of the group theory in SageMath is implemented using LibGAP.



Bug#833405: nvidia-vulkan-icd: Missing conflict: /usr/share/vulkan/icd.d/nvidia_icd.json provided by 2 packages

2016-08-03 Thread Diederik de Haas
Package: nvidia-vulkan-icd
Version: 364.19-1
Severity: grave
Justification: renders package unusable

The mentioned file is also provide by nvidia-vulkan-common thus a
conflicts relation should be added.

Unpacking nvidia-vulkan-common (364.19-1) ...
dpkg: error processing archive
/var/cache/apt/archives/nvidia-vulkan-common_364.19-1_amd64.deb
(--unpack):
 trying to overwrite '/usr/share/vulkan/icd.d/nvidia_icd.json', which is
 also in package nvidia-vulkan-icd 364.19-1

...

Errors were encountered while processing:
 /var/cache/apt/archives/nvidia-vulkan-common_364.19-1_amd64.deb
E: Sub-process /usr/bin/dpkg returned an error code (1)

...

dpkg: dependency problems prevent configuration of
nvidia-vulkan-icd:amd64:
 nvidia-vulkan-icd:amd64 depends on nvidia-vulkan-common; however:
   Package nvidia-vulkan-common is not installed.

 dpkg: error processing package nvidia-vulkan-icd:amd64 (--configure):
dependency problems - leaving unconfigured


Cheers,
  Diederik

-- Package-specific info:
uname -a:
Linux bagend 4.6.0-1-amd64 #1 SMP Debian 4.6.2-2 (2016-06-25) x86_64 GNU/Linux

/proc/version:
Linux version 4.6.0-1-amd64 (debian-ker...@lists.debian.org) (gcc version 5.4.0 
20160609 (Debian 5.4.0-4) ) #1 SMP Debian 4.6.2-2 (2016-06-25)

/proc/driver/nvidia/version:
NVRM version: NVIDIA UNIX x86_64 Kernel Module  364.19  Tue Apr 19 14:44:55 PDT 
2016
GCC version:  gcc version 5.4.0 20160609 (Debian 5.4.0-6) 

lspci 'VGA compatible controller [0300]':
05:00.0 VGA compatible controller [0300]: NVIDIA Corporation GF108 [GeForce GT 
430] [10de:0de1] (rev a1) (prog-if 00 [VGA controller])
Subsystem: Micro-Star International Co., Ltd. [MSI] GF108 [GeForce GT 
430] [1462:2304]
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- 
Kernel driver in use: nvidia
Kernel modules: nvidia

dmesg:
[0.00] AGP: No AGP bridge found
[0.00] AGP: Checking aperture...
[0.00] AGP: No AGP bridge found
[0.00] AGP: Node 0: aperture [bus addr 0x609200-0x6093ff] (32MB)
[0.00] AGP: Your BIOS doesn't leave an aperture memory hole
[0.00] AGP: Please enable the IOMMU option in the BIOS setup
[0.00] AGP: This costs you 64MB of RAM
[0.00] AGP: Mapping aperture over RAM [mem 0xc400-0xc7ff] 
(65536KB)
[0.00] Console: colour VGA+ 80x25
[0.934854] vgaarb: setting as boot device: PCI::05:00.0
[0.934855] vgaarb: device added: 
PCI::05:00.0,decodes=io+mem,owns=io+mem,locks=none
[0.934857] vgaarb: loaded
[0.934858] vgaarb: bridge control possible :05:00.0
[2.115483] PCI-DMA: Disabling AGP.
[2.115562] PCI-DMA: Reserving 64MB of IOMMU area in the AGP aperture
[2.189948] Linux agpgart interface v0.103
[7.430312] nvidia: module license 'NVIDIA' taints kernel.
[7.436767] nvidia: module verification failed: signature and/or required 
key missing - tainting kernel
[7.441358] vgaarb: device changed decodes: 
PCI::05:00.0,olddecodes=io+mem,decodes=none:owns=io+mem
[7.441460] nvidia-nvlink: Nvlink Core is being initialized, major device 
number 249
[7.441473] NVRM: loading NVIDIA UNIX x86_64 Kernel Module  364.19  Tue Apr 
19 14:44:55 PDT 2016
[8.873609] snd_hda_intel :05:00.1: Handle vga_switcheroo audio client
[9.773265] input: HDA NVidia HDMI/DP,pcm=3 as 
/devices/pci:00/:00:02.0/:05:00.1/sound/card1/input14
[9.773462] input: HDA NVidia HDMI/DP,pcm=7 as 
/devices/pci:00/:00:02.0/:05:00.1/sound/card1/input15
[9.773645] input: HDA NVidia HDMI/DP,pcm=8 as 
/devices/pci:00/:00:02.0/:05:00.1/sound/card1/input16
[9.773824] input: HDA NVidia HDMI/DP,pcm=9 as 
/devices/pci:00/:00:02.0/:05:00.1/sound/card1/input17
[   25.369401] nvidia-modeset: Loading NVIDIA Kernel Mode Setting Driver for 
UNIX platforms  364.19  Tue Apr 19 14:15:03 PDT 2016
[   25.370345] nvidia-modeset: Allocated GPU:0 
(GPU-69778117-302d-2df8-182e-caf6d1913d25) @ PCI::05:00.0

Device node permissions:
crw-rw-rw- 1 root root 195, 254 Aug  4 00:34 /dev/nvidia-modeset
crw-rw-rw- 1 root root 195,   0 Aug  4 00:34 /dev/nvidia0
crw-rw-rw- 1 root root 195, 255 Aug  4 00:34 /dev/nvidiactl
video:x:44:diederik,sddm

OpenGL and NVIDIA library files installed:
lrwxrwxrwx 1 root root   15 Aug  4 01:15 /etc/alternatives/glx -> 
/usr/lib/nvidia
lrwxrwxrwx 1 root root   51 Aug  4 01:15 
/etc/alternatives/glx--libEGL.so.1-x86_64-linux-gnu -> 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libEGL.so.1
lrwxrwxrwx 1 root root   48 Feb  7 06:39 
/etc/alternatives/glx--libGL.so-x86_64-linux-gnu -> 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libGL.so
lrwxrwxrwx 1 root root   48 Feb  7 06:39 
/etc/alternatives/glx--libGL.so-x86_64-linux-gnu -> 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libGL.so
lrwxrwxrwx 1 root root   43 Aug  

Bug#830268: linux: please make the build reproducible

2016-08-03 Thread Ben Hutchings
On Thu, 2016-07-07 at 20:52 +0200, Reiner Herrmann wrote:
> Source: linux
> Version: 4.6.3-1
> Severity: wishlist
> User: reproducible-bui...@lists.alioth.debian.org
> Usertags: environment randomness
> X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org
> 
> Hi!
> 
> While working on the "reproducible builds" effort [1], we have noticed
> that linux could not be built reproducibly.
> Since we started varying the shell used for /bin/sh (bash vs. dash),
> linux no longer builds reproducibly.
> 
> The following differences are in linux-headers packages:
> 
> ── 
> ./usr/src/linux-headers-4.6.0-1-686/arch/x86/include/generated/asm/.syscalls_32.h.cmd
>  @@ -1 +1 @@
>  -cmd_arch/x86/entry/syscalls/../../include/generated/asm/syscalls_32.h := 
> /bin/bash '/build/linux-4.6.3/arch/x86/entry/syscalls/syscalltbl.sh' 
> /build/linux-4.6.3/arch/x86/entry/syscalls/syscall_32.tbl 
> arch/x86/entry/syscalls/../../include/generated/asm/syscalls_32.h
>  +cmd_arch/x86/entry/syscalls/../../include/generated/asm/syscalls_32.h := 
> /bin/sh '/build/linux-4.6.3/arch/x86/entry/syscalls/syscalltbl.sh' 
> /build/linux-4.6.3/arch/x86/entry/syscalls/syscall_32.tbl 
> arch/x86/entry/syscalls/../../include/generated/asm/syscalls_32.h
> ── 
> ./usr/src/linux-headers-4.6.0-1-686/arch/x86/include/generated/uapi/asm/.unistd_32.h.cmd
>  @@ -1 +1 @@
>  -cmd_arch/x86/entry/syscalls/../../include/generated/uapi/asm/unistd_32.h := 
> /bin/bash '/build/linux-4.6.3/arch/x86/entry/syscalls/syscallhdr.sh' 
> '/build/linux-4.6.3/arch/x86/entry/syscalls/syscall_32.tbl' 
> 'arch/x86/entry/syscalls/../../include/generated/uapi/asm/unistd_32.h' 'i386' 
> '' ''
>  +cmd_arch/x86/entry/syscalls/../../include/generated/uapi/asm/unistd_32.h := 
> /bin/sh '/build/linux-4.6.3/arch/x86/entry/syscalls/syscallhdr.sh' 
> '/build/linux-4.6.3/arch/x86/entry/syscalls/syscall_32.tbl' 
> 'arch/x86/entry/syscalls/../../include/generated/uapi/asm/unistd_32.h' 'i386' 
> '' ''
> ── 
> ./usr/src/linux-headers-4.6.0-1-686/arch/x86/include/generated/uapi/asm/.unistd_64.h.cmd
>  @@ -1 +1 @@
>  -cmd_arch/x86/entry/syscalls/../../include/generated/uapi/asm/unistd_64.h := 
> /bin/bash '/build/linux-4.6.3/arch/x86/entry/syscalls/syscallhdr.sh' 
> '/build/linux-4.6.3/arch/x86/entry/syscalls/syscall_64.tbl' 
> 'arch/x86/entry/syscalls/../../include/generated/uapi/asm/unistd_64.h' 
> 'common,64' '' ''
>  +cmd_arch/x86/entry/syscalls/../../include/generated/uapi/asm/unistd_64.h := 
> /bin/sh '/build/linux-4.6.3/arch/x86/entry/syscalls/syscallhdr.sh' 
> '/build/linux-4.6.3/arch/x86/entry/syscalls/syscall_64.tbl' 
> 'arch/x86/entry/syscalls/../../include/generated/uapi/asm/unistd_64.h' 
> 'common,64' '' ''
> ── 
> ./usr/src/linux-headers-4.6.0-1-686/arch/x86/include/generated/uapi/asm/.unistd_x32.h.cmd
>  @@ -1 +1 @@
>  -cmd_arch/x86/entry/syscalls/../../include/generated/uapi/asm/unistd_x32.h 
> := /bin/bash '/build/linux-4.6.3/arch/x86/entry/syscalls/syscallhdr.sh' 
> '/build/linux-4.6.3/arch/x86/entry/syscalls/syscall_64.tbl' 
> 'arch/x86/entry/syscalls/../../include/generated/uapi/asm/unistd_x32.h' 
> 'common,x32' '' '__X32_SYSCALL_BIT'
>  +cmd_arch/x86/entry/syscalls/../../include/generated/uapi/asm/unistd_x32.h 
> := /bin/sh '/build/linux-4.6.3/arch/x86/entry/syscalls/syscallhdr.sh' 
> '/build/linux-4.6.3/arch/x86/entry/syscalls/syscall_64.tbl' 
> 'arch/x86/entry/syscalls/../../include/generated/uapi/asm/unistd_x32.h' 
> 'common,x32' '' '__X32_SYSCALL_BIT'
> 
> Are those .cmd files actually needed in the packages?

I don't think so, but I'm not certain.

> They are caused by the SYSTBL and SYSHDR commands if I undertand it
> correctly. If they should be kept in the package, this can probably be
> solved by setting CONFIG_SHELL to a static value (/bin/bash).
> 
> And the linux-source package has differences (randomly orderes elements)
> in the file usr/src/linux-source-4.6/tools/usb/usbip/autom4te.cache/requests
> (which I think doesn't need to be included either).

It certainly doesn't.  We try to build everything in suubdirectories of
debian/build/ and never modify any files outside of the debian/
directory, so linux-source- should be clean   Unfortunately we
need to run autotools for the usbip userland which creates lots of
files in the source directory.  We'll have to make a temporary copy of
the source.

Ben.

-- 

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


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


Bug#811993: terminatorx: FTBFS with GCC 6: call overloaded is ambiguous

2016-08-03 Thread Alexander Koenig
James,

On Wed, Aug 03, 2016, James Cowgill wrote:
<..> 
> I've updated the Debian packaging to 4.0.1 in the git repo here:
> https://anonscm.debian.org/cgit/pkg-multimedia/terminatorx.git

Thanks a lot for updating the package!

> Is it possible for you to look at some of the patches?
<..>

Yes, they all look very reasonable and I will merge them with the next
release, thanks a lot - especially for replacing the obsolete
gnome-doc-utils!

Thanks,
Alex


signature.asc
Description: Digital signature


Bug#814584: gnupg2: gpg2 --card-status fail on armel / Raspberry Pi - "Card error"

2016-08-03 Thread NIIBE Yutaka
On 08/03/2016 10:10 PM, Petter Reinholdtsen wrote:
> My original test was done using a Freedombox image, which was armel.
> 
> Todays test was done using some random RPi and SD card I found on my
> desk and I did not notice it was using a different architecture.  I can
> try again on armel, if you believe it mattes.

I see the situation.  I have no idea about the segmentation fault.

I don't know if the difference of armel/armhf matters or not.  My
point was that in order to narrow down an issue (to be fixed), in
general, it would be better not to change other factors.

While I guess that the major problem is hardware related, I modified
the ccid-driver of GnuPG so that the difference between PC/SC service
can be smaller (less factors involved).

Well, if you would like to change other factors to get success anyway,
I'd recommend to take some hardware approach which possibly may
stabilize the USB communication:

  (1) Use good voltage supply to RPi board.

  (2) Only connect the card reader (+ the smart card) to USB port of
  RPi so that we can minimize the load of USB.  If you connect
  keyboard and mouse, try good ones (or none by using the
  network).

  (3) Use a USB HUB with an external voltage supply to connect the
  card reader.

My daily development environment and desktop environment is Wandboard
(armhf).  I test on BeagleBone Green (armhf) and SheevaPlug clone
(armel), too.

For those boards, USB host is not as good as PC, signal-wise and
power-wise.  For example, I can reproduce USB communication failure on
my Wandboard by inserting an additional USB Hub with no voltage supply
(while the USB specification allows many).
-- 



Bug#832713: systemd: after "systemd (231-1) unstable" update systemd-jurnald.service fails to start

2016-08-03 Thread Felipe Sateler
On 3 August 2016 at 16:44, Rick Thomas  wrote:
>
> On Aug 3, 2016, at 9:06 AM, Felipe Sateler  wrote:
>
>> On 1 August 2016 at 18:32, Rick Thomas  wrote:
>>>
>>> Thanks, Filipe!
>>>
>>> What do we have to do at this point to test this and then translate it into 
>>> a patch?
>>
>> OK, so I have a proof-of-concept patch. Rick, could you test it in your 
>> machine?
>
> I’m afraid I don’t have the facilities or the expertise to turn this into a 
> loadable kernel .deb .
>
> If someone can provide an installable kernel .deb file for a Cuboxi4-Pro 
> machine, I’ll he happy to test it.

This is a patch for systemd, not the kernel. I prepared a source
package for easier testing. Do the following:

apt-get install dpkg-dev devscripts
apt-get build-dep systemd
dget https://people.debian.org/~fsateler/systemd_231-2.dsc
cd systemd-231
dpkg-buildpackage

That should leave you with several .debs (after a long time). Install
libsystemd0 and systemd from those debs.

-- 

Saludos,
Felipe Sateler



Bug#833116: fgetty: Incorrect keystroke interpretation

2016-08-03 Thread Ricardo Fabian Peliquero
On Wed, Aug 03, 2016 at 11:52:57AM +0300, Dmitry Bogatov wrote:
> 
> > When trying to login with fgetty, I could read my password on the screen 
> > while typing. Did not continue.
> > ngetty + login behaves good
> > ngetty + login1 will get in well, but no key press will echo on the console.
> 
> Sorry, I assumed you read C. This is intended behaviour. Please,
> continue and tell, whether rest is OK. I expect terminal to be not in
> good shape, but after `reset` I expect fancy letter to work.

fgetty_patched + login1: ñ doesn't show up, (arg: 1) instead, even after reset.

ngetty + login1: no letter will show up after logging in, but they are there 
(except ñ); that is, if I (blindly) type "echo ñandú", it will return "and". 
But, after reset, I can see "echo and" while typing "echo ñandú" with the same 
result "and". This time, (arg: 1) appears when typing "ñ", and just a beep 
while typing key stroke sequence for "ú".

> 
> (Sure, it is not secure and you are encouraged to reinstall version
> from sid afterward).  Probably I have one idea for your case.

OK. Let me know if there is anything I can do.

> 
> -- 
> Accept: text/plain, text/x-diff
> Accept-Language: eo,en,ru
> X-Web-Site: sinsekvu.github.io



Bug#696332: lsb-release: release/codename depend on a successful apt-get

2016-08-03 Thread Axel Beckert
Hi again,

Axel Beckert wrote:
> > How does your /etc/debian_version look like ? And what is the output
> > of `apt-cache policy` ?
> 
> → cat /etc/debian_version
> stretch/sid
> → apt-cache policy
> E: Problem renaming the file /var/cache/apt/pkgcache.bin.JkcuIW to
> /var/cache/apt/pkgcache.bin - rename (1: Operation not permitted)
> W: You may want to run apt-get update to correct these problems
> E: The package cache file is corrupted

There's another fact which is required to let that happen:
/var/cache/apt needs to be world-writable.

Yes, that sounds like a bad idea, but happened if it is a tmpfs mount
point with the default options, like e.g. this /etc/fstab entry:

  none /var/cache/apt tmpfs size=8G 0 0

(Thanks to juliank for the right hint! :-)

So in this case, you can consider it a configuration issue, but still
a nice way to reproduce the effect of erroring out "apt-cache policy".
:-)

Regards, Axel
-- 
 ,''`.  |  Axel Beckert , http://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE



Bug#833404: AttributeError: 'NoneType' object has no attribute 'discid'

2016-08-03 Thread Ryan Kavanagh
Package: morituri
Version: 0.2.3-1
Severity: normal
Tags: upstream

Trying to rip a CD using the "-U" flag causes:

$ rip cd rip -o 6 --track-template="%r/%A/%t. %n" --disc-template="%r/%A" -U
Checking device /dev/sr0
CDDB disc id: 32090804
MusicBrainz disc id 4qK3yXQqtuS98cLEb5bUWIfW3Cs-
MusicBrainz lookup URL 
http://mm.musicbrainz.org/bare/cdlookup.html?toc=1+4+173617+150+54373+105673+127263=4=4qK3yXQqtuS98cLEb5bUWIfW3Cs-
Disc duration: 00:38:32.893, 4 audio tracks
Error: NotFoundException(ResponseError(),)
Continuing without metadata
Submit this disc to MusicBrainz at the above URL.

FreeDB identifies disc as Leningrad Philharmonic Orchestra & Evgeny Mravinsky / 
Evgeny Mravinsky conducts the Leningrad Philharmonic Orchestra (Disc 3)
Traceback (most recent call last):
  File "/usr/bin/rip", line 41, in 
sys.exit(main.main(sys.argv[1:]))
  File "/usr/lib/python2.7/dist-packages/morituri/rip/main.py", line 45, in main
ret = c.parse(argv)
  File "/usr/lib/python2.7/dist-packages/morituri/rip/main.py", line 123, in 
parse
logcommand.LogCommand.parse(self, argv)
  File "/usr/lib/python2.7/dist-packages/morituri/extern/command/command.py", 
line 401, in parse
return self.subCommands[command].parse(args[1:])
  File "/usr/lib/python2.7/dist-packages/morituri/extern/command/command.py", 
line 401, in parse
return self.subCommands[command].parse(args[1:])
  File "/usr/lib/python2.7/dist-packages/morituri/extern/command/command.py", 
line 363, in parse
ret = self.do(args)
  File "/usr/lib/python2.7/dist-packages/morituri/rip/cd.py", line 126, in do
self.program.metadata.discid = self.ittoc.getMusicBrainzDiscId()
AttributeError: 'NoneType' object has no attribute 'discid'

Best,
Ryan

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

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

Versions of packages morituri depends on:
ii  cdparanoia  3.10.2+debian-11
ii  cdrdao  1:1.2.3-3
ii  gstreamer0.10-plugins-good  0.10.31-3+nmu4+b2
ii  python  2.7.11-2
ii  python-cddb 1.4-5.2
ii  python-gobject  3.20.1-1
ii  python-gst0.10  0.10.22-3
ii  python-musicbrainzngs   0.5-2
ii  python-pkg-resources20.10.1-1.1

Versions of packages morituri recommends:
pn  gstreamer0.10-ffmpeg  
pn  gstreamer0.10-tools   
ii  python-xdg0.25-4

Versions of packages morituri suggests:
pn  gstreamer0.10-plugins-ugly  
ii  python-gtk2 2.24.0-5
pn  python-pycdio   

-- no debconf information

-- 
|_)|_/  Ryan Kavanagh  | GPG: 4E46 9519 ED67 7734 268F
| \| \  https://ryanak.ca/ |  BD95 8F7B F8FC 4A11 C97A


signature.asc
Description: PGP signature


Bug#739452: [debian-mysql] Bug#739452: Bug#739452: libmariadbclient18: arch-dependent files in "Multi-Arch: same" package

2016-08-03 Thread Otto Kekäläinen
Hello!

I noticed Daniel Schepler already implemented this for the
mariadb-connector-c in
https://anonscm.debian.org/cgit/pkg-mysql/mariadb-client-lgpl.git/commit/?id=d6326dc57c042c4ab91ef448c959db853e374384

The same thing should be ported over the libmariadbclient18 in the
mariadb-10.0.git repo and tested that it works and that all links to
the plugins become updated.

Any takers?



Bug#816865: closed by Nobuhiro Iwamatsu <iwama...@debian.org> (Bug#816865: fixed in bluez 5.40-1~exp0)

2016-08-03 Thread Jérôme de Bretagne
Thank you very much Nobuhiro.

I can confirm that the newly added btattach command works as intended
in your bluez (5.40-1~exp0) experimental package. It allows me to run
the following command manually to enable the Bluetooth chipset on my
Lenovo ThinkPad 8 tablet:
   $ btattach --bredr /dev/ttyS1 -P bcm

However, compared to some existing USB-based Bluetooth dongles, the
Bluetooth stack is not enabled automatically at boot time yet on that
setup. I guess the btattach command needs to be plugged with other
parts of the system as well?

To answer fully the original Bug report and its second part "how to
configure btattach in a way that it will enable such Bluetooth
chipsets directly at boot time?", should this report remain open? Or
would you prefer me to open a separate one?

It is unclear to me how Bluetooth dongles are enabled automatically
upon detection so if you prefer a new Bug report, I would appreciate
to get some hints to find which component in the system (BlueZ,
another part) needs to be modified to take benefit of this new
btattach command.

Thanks a lot,
Jérôme



Bug#833328: [Pkg-openssl-devel] Bug#833328: Bug#833328: openssl does not start on x86_64: version `OPENSSL_1.0.1s' not found

2016-08-03 Thread Kurt Roeckx
On Wed, Aug 03, 2016 at 10:48:42PM +0200, Sebastian Andrzej Siewior wrote:
> On 2016-08-03 17:06:22 [+0200], Kurt Roeckx wrote:
> > You're using openssl from stable but libssl1.0.0 from backports.
> > 
> > It's rather annoying, but I wasn't sure how to deal with it.  I
> > guess I should add a Breaks in the backports version.
> 
> I think the linker version script is wrong. In stable we have:
> 
> OPENSSL_1.0.1s {
> global:
>   SRP_VBASE_get1_by_user;
>   SRP_user_pwd_free;
> }
> 
> and bpo we have
> 
> OPENSSL_1.0.2g {
> global:
>   SRP_VBASE_get1_by_user;
>   SRP_user_pwd_free;
> }
> 
> I think we have to use 1.0.1s unless there was a ABI change. If there
> was a change we would need to update the symbols files.
> nginx (bpo) picked up the correct dependency due to the ALPN symbols so
> that worked as planned :)
> 
> If I read codesearch.d.n right then openssl is the only use of those two
> symbols so nothing else should be affected.

The problem is that both 1.0.1s and 1.0.2g introduced those symbol
in a security update, and I didn't know what to do with it.

For things in unstable that want to use the symbols, you really
want to have at least 1.0.2g.

I still don't see a good solution for this, other than packages
that make use of those symbols to break on the 1.0.1 version.


Kurt



Bug#833349: mirror listing update for ftp.man.szczecin.pl

2016-08-03 Thread Donald Norwood
control: tag -1 +moreinfo

Hello,

Thank you for your support and for mirroring debian.

The mirror needs to update at a frequency of 4 times per day in ensure
that it is in sync with the rest of the archive.

Please let us know if these changes can be made and we can move forward
with the listing.

Best regards,

Donald Norwood
-Debian Mirrors Team



On Wed, 03 Aug 2016 11:26:48 + "Academic Center of Computer Science"
 wrote:
> Package: mirrors
> Severity: minor
> User: mirr...@packages.debian.org
> Usertags: mirror-list
>
> Submission-Type: update
> Site: ftp.man.szczecin.pl
> Type: leaf
> Archive-architecture: ALL amd64 arm64 armel armhf hurd-i386 i386
kfreebsd-amd64 kfreebsd-i386 mips mips64el mipsel powerpc ppc64el s390x
> Archive-ftp: /pub/Linux/debian/
> CDImage-ftp: /pub/Linux/debian-cd/
> IPv6: yes
> Archive-upstream: ftp2.de.debian.org
> CDImage-upstream: ftp2.de.debian.org
> Updates: twice
> Maintainer: Academic Center of Computer Science

> Country: PL Poland
>
>

-- 
--Donald Norwood
www.debian.org





signature.asc
Description: OpenPGP digital signature


Bug#833403: disper: Uses max refresh rate instead of default

2016-08-03 Thread Lisette
Package: disper
Version: 0.3.1-2
Severity: important

When I run

disper -d LVDS1,HDMI1 -e -t right

I see that it has set the refresh rate for HDMI1 to 119.99 instead of to 60.00.
My projector simply does not detect a signal.  If I use lxrandr's auto
selector, or disper and then lxrandr to switch to refresh rate of 60, then that
works.  But just running disper results in no display.



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

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

Versions of packages disper depends on:
ii  libx11-62:1.6.2-3
ii  libxrandr2  2:1.4.2-1+b1
pn  python:any  

Versions of packages disper recommends:
pn  libnotify-bin  

disper suggests no packages.

-- no debconf information



Bug#801959: Fwd: debtags: proposed tag: suite::mysql

2016-08-03 Thread Otto Kekäläinen
Issue closed via #830626



Bug#808421: [debian-mysql] Bug#808421: proposed solution

2016-08-03 Thread Otto Kekäläinen
Thanks!

Commited as 
https://anonscm.debian.org/cgit/pkg-mysql/mariadb-10.0.git/commit/?id=d258bf46d85f77a60417adc139289b674aabeb73



Bug#833402: wpasupplicant: wpa_supplicant does not start because it could not read the interface p2p-dev-wlp1s0

2016-08-03 Thread Jeremie Salvucci
Package: wpasupplicant
Version: 2.5-1
Severity: grave
Justification: renders package unusable

Dear Maintainer,

After upgrading the system, wpasupplicant does not start because
it could not read the interface p2p-dev-wlp1s0.  When running,

 wpa_supplicant -B -i wlp1s0 -c /etc/wpa_supplicant/wpa_supplicant.conf

I get,

wpa_supplicant could not read the interface p2p-dev-wlp1s0.

Current solution involves downgrading to version 2.3-2.4 from the
testing branch.

Might be related to this other bug report, https://bugs.archlinux.org/task/44731

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

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

Versions of packages wpasupplicant depends on:
ii  adduser   3.115
ii  libc6 2.23-4
ii  libdbus-1-3   1.10.8-1
ii  libnl-3-200   3.2.27-1
ii  libnl-genl-3-200  3.2.27-1
ii  libpcsclite1  1.8.17-1
ii  libreadline6  6.3-8+b4
ii  libssl1.0.2   1.0.2h-1
ii  lsb-base  9.20160629

wpasupplicant recommends no packages.

Versions of packages wpasupplicant suggests:
pn  libengine-pkcs11-openssl  
pn  wpagui

-- no debconf information



Bug#832908: Security update of mongodb

2016-08-03 Thread Ola Lundqvist
Hi Jérémy, Laszlo and LTS team

You have probably seen my latest emails about "Bug#832908: mongodb:
CVE-2016-6494: world-readable .dbshell history file: LTS update and upgrade
handling".

I have now prepared a security update of this CVE-2016-6494 and in addition
to that TEMP-0833087-C5410D.

For https://security-tracker.debian.org/tracker/CVE-2016-6494 you can find
the patch in bug 832908.

For https://security-tracker.debian.org/tracker/TEMP-0833087-C5410D I could
not easily backport the fix for sid as the code was considerably different.
So I made a simpler solution. The upstream fix was to mangle only the the
sensitive data. In wheezy I replaced the whole sensitive string with XXX.
This means that the logging is not that good anymore but this should not
impact any application functionality. I do not think most people will
notive this anyway so I think it is safe.

Upstream fix looks something like this in the logs:
Tue Aug  2 11:41:13 [conn4]  authenticate: { authenticate: 1.0, user:
"foo", nonce: "", key: "" }

My fix looks like this:
Wed Aug  3 21:18:52 [conn1]  authenticate: 

I made the short-cut as I do not think it is worth the effort to do a full
back-port.

You can find the debdiff here:
http://apt.inguza.net/wheezy-security/mongodb/mongodb.debdiff

And the prepared package here:
http://apt.inguza.net/wheezy-security/mongodb/

Regarding testing I have done a simple regression test bu installing the
new packages, checking that the database is there and that I can access the
server.

I have also been able to reproduce both issues and been able to verify that
both fixes do really solve the problem.

If I do not hear any objections I will upload the corrected packages in
four (4) days, that is on Sunday (maybe on monday after).

Best regards

// Ola

-- 
 --- Inguza Technology AB --- MSc in Information Technology 
/  o...@inguza.comFolkebogatan 26\
|  o...@debian.org   654 68 KARLSTAD|
|  http://inguza.com/Mobile: +46 (0)70-332 1551 |
\  gpg/f.p.: 7090 A92B 18FE 7994 0C36 4FE4 18A1 B1CF 0FE5 3DD9  /
 ---


Bug#651741: Bug#801348: xserver-xorg: X server controls wrong backlight device

2016-08-03 Thread Kalle Olavi Niemitalo
This Bug #801348 looks pretty similar to Bug #651741, which I
reported originally in 2011.  The hardware is different though.

You can probably make it work by putting this in /etc/X11/xorg.conf:

Section "Device"
Option  "Backlight" "intel_backlight"
Identifier  "Card0"
Driver  "intel"
BusID   "PCI:0:2:0"
EndSection

This requires xserver-xorg-video-intel 2.20.7 or later;
you have 2:2.21.15-2+b2, which is new enough.

Linux apparently has a blacklist for buggy ACPI backlight
interfaces nowadays:
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/acpi/video.c?id=refs/tags/v3.16#n418
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/acpi/acpi_video.c?id=refs/tags/v4.7#n409

I should finally file a bug in the kernel Bugzilla and ask them
to add my Sony Vaio VPCYA1V9E to the blacklist.


pgpSTcZOr6Vj3.pgp
Description: PGP signature


Bug#833333: Amarok crash probably due to gstreamer

2016-08-03 Thread Sebastian Dröge
Hi,

it's a bug in ffmpeg for which a patch exists already, and which is
also going to be worked around in the next release of gst-libav1.0.

See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=831529 which is
fixed in ffmpeg 7:3.1.1-4


Sebastian

On Wed, 2016-08-03 at 17:36 +0200, Giovanni Mascellani wrote:
> Hi.
> 
> I reported bug #83 against the Amarok package, but it is probably
> due to gstreamer. So gstreamer maintainers are in Cc.
> 
>   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=83
> 
> I found how to intercept amarok's backtrace (use "amarok --nofork").
> So
> that is the backtrace:
> 
> > 
> > 0x74a751c8 in __GI_raise (sig=sig@entry=6) at
> > ../sysdeps/unix/sysv/linux/raise.c:54
> > 54  ../sysdeps/unix/sysv/linux/raise.c: File o directory non
> > esistente.
> > (gdb) bt
> > #0  0x74a751c8 in __GI_raise (sig=sig@entry=6) at
> > ../sysdeps/unix/sysv/linux/raise.c:54
> > #1  0x74a7664a in __GI_abort () at abort.c:89
> > #2  0x71d7560b in init_context_defaults (s=s@entry=0x7ffe6c
> > 077ce0, codec=codec@entry=0x726bb900 )
> > at src/libavcodec/options.c:142
> > #3  0x71d756d6 in avcodec_alloc_context3
> > (codec=0x726bb900 ) at
> > src/libavcodec/options.c:163
> > #4  0x7fff04558540 in gst_ffmpeg_cfg_install_property
> > (klass=0x7ffe6c077550, base=8) at gstavcfg.c:732
> > #5  0x7fff0454ee53 in gst_ffmpegvidenc_class_init
> > (klass=0x7ffe6c077550) at gstavvidenc.c:225
> > #6  0x7fffecf2722d in g_type_class_ref (pclass=0x7ffe6c077220,
> > node=0x7ffe6c076f40) at /build/glib2.0-vjfO_h/glib2.0-
> > 2.48.1/./gobject/gtype.c:2241
> > #7  0x7fffecf2722d in g_type_class_ref (type=type@entry=1407307
> > 10847296) at /build/glib2.0-vjfO_h/glib2.0-
> > 2.48.1/./gobject/gtype.c:2956
> > #8  0x7fffdf246da4 in gst_element_register (plugin=plugin@entry
> > =0xbe1160 [GstPlugin], name=name@entry=0x7ffe6c06eeb0
> > "avenc_h264_vaapi", rank=rank@entry=128, type=type@entry=1407307108
> > 47296) at gstelementfactory.c:243
> > #9  0x7fff0454f5b3 in gst_ffmpegvidenc_register (plugin=plugin@
> > entry=0xbe1160 [GstPlugin]) at gstavvidenc.c:1009
> > #10 0x7fff04541e20 in plugin_init (plugin=0xbe1160 [GstPlugin])
> > at gstav.c:158
> > #11 0x7fffdf268537 in gst_plugin_register_func (plugin=0xbe1160
> > [GstPlugin], desc=0x7fff04770180 , user_data=0x0)
> > at gstplugin.c:523
> > #12 0x7fffdf26a425 in _priv_gst_plugin_load_file_for_registry
> > (filename=0xbe4d00 "/usr/lib/x86_64-linux-gnu/gstreamer-
> > 1.0/libgstlibav.so", registry=0x92b2b0 [GstRegistry], registry@entr
> > y=0x0, error=error@entry=0x7fff04f71800)
> > at gstplugin.c:826
> > #13 0x7fffdf26acea in gst_plugin_load_file (filename= > out>, error=error@entry=0x7fff04f71800) at gstplugin.c:680
> > #14 0x7fffdf26b12c in gst_plugin_load_by_name (name=0xbe378a
> > "libav") at gstplugin.c:1265
> > #15 0x7fffdf26ba8d in gst_plugin_feature_load (feature=feature@
> > entry=0xc0b360 [GstTypeFindFactory]) at gstpluginfeature.c:111
> > #16 0x7fffdf2917e3 in gst_type_find_factory_call_function
> > (factory=0xc0b360 [GstTypeFindFactory], find=0x7fff04f718e0) at
> > gsttypefindfactory.c:210
> > #17 0x7fffdf55e0c9 in gst_type_find_helper_get_range (obj=obj@e
> > ntry=0xd7eec0 [GstID3Demux], parent=parent@entry=0x0, func=func@ent
> > ry=0x7fffdad05600 , size=,
> > e
> > xtension=extension@entry=0x0, prob=prob@entry=0x7fff04f719ac) at
> > gsttypefindhelper.c:355
> > #18 0x7fffdad02cc8 in gst_tag_demux_element_find
> > (demux=0xd7eec0 [GstID3Demux]) at gsttagdemux.c:1364
> > #19 0x7fffdad03d8d in gst_tag_demux_element_loop
> > (demux=0xd7eec0 [GstID3Demux]) at gsttagdemux.c:1437
> > #20 0x7fffdf28ce71 in gst_task_func (task=0x92d950 [GstTask])
> > at gsttask.c:332
> > #21 0x7fffed8b855e in g_thread_pool_thread_proxy
> > (data=) at /build/glib2.0-vjfO_h/glib2.0-
> > 2.48.1/./glib/gthreadpool.c:307
> > #22 0x7fffed8b7bc5 in g_thread_proxy (data=0x7ffe740fcde0) at
> > /build/glib2.0-vjfO_h/glib2.0-2.48.1/./glib/gthread.c:780
> > #23 0x736d0464 in start_thread (arg=0x7fff04f72700) at
> > pthread_create.c:333
> > #24 0x74b2930d in clone () at
> > ../sysdeps/unix/sysv/linux/x86_64/clone.S:109
> 
> Which seems to indicate that the bug is in gstreamer1.0-libav. And
> actually upgrading that package to the experimental version (1.9.1-1)
> fixes the bug. So I leave it to the GStreamer maintainers to decide
> what
> to do with the bug (if 1.9.1-1 is planned to migrate to unstable and
> testing soon, there is no need to fix 1.8.2-1; if not, probably it is
> a
> good idea to do that).
> 
> Thanks, Giovanni.
> ___
> pkg-gstreamer-maintainers mailing list
> pkg-gstreamer-maintain...@lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-gstreamer
> -maintainers

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


Bug#803456: Digikam 5.0.0 uploaded

2016-08-03 Thread Simon Frei

Hi,

First a big thanks at Steve for packaging digikam!
I proposed an information on the welcome page about the configuration 
transition. I hope this is included before 5.1.0: 
https://bugs.kde.org/show_bug.cgi?id=364258#c18
I will keep you posted. I would really like to see digikam5 in 
non-experimental debian repo soon!


On a side note: Is bug triaging on this package welcomed?

Cheers,
Simon



Bug#833360: Kmidimon - French translation

2016-08-03 Thread James Cowgill
Hi,

On 03/08/16 19:46, Pedro Lopez-Cabanillas wrote:
> On Wednesday 03 August 2016 14:52:02 James Cowgill wrote:
>> While this could be patched into the Debian version, it would be
>> preferable to have a new upstream release.
>>
>> Pedro, if you do make a new release, could you include this patch as well?
>>
>> https://sources.debian.net/src/kmidimon/0.7.5-2/debian/patches/01-remove-uni
>> nstall-target.patch/
> 
> I can't promise a deadline for the next kmidimon release, because I have  
> another pending release much more mature right now: drumstick-1.1, and this 
> library shall be required by a new kmidimon, along with Qt5. This is a 
> similar 
> situation to what happened with drumstick-1.0, kmetronome-1.0 and vmpk-0.6  
> releases that have not been available for Debian and Ubuntu users since then.
> 
> So I guess that the same may be true for drumstick-1.1/kmidimon and Debian 
> users wanting  the latest versions will need to build from sources, requiring 
> both install and uninstall targets. 

Hopefully the same situation won't happen this time. I think the normal
maintainers for those Debian packages haven't been very active.

> I don't want to take your patch removing uninstall for everyone, but I don't 
> mind to wrap the uninstall chuck with "if (NOT TARGET uninstall)", though.   
> Below is an alternate patch. But before applying any patch, I would like to 
> know why is it necessary. Is Debian breaking the build system of every 
> project 
> that offers a custom uninstall target?

The FindKDE4 module has installed an "uninstall" target into all
downstream projects for ages (>= 10 years). Until recently kdelibs also
added a 'cmake_policy(SET CMP0002 OLD)' line to the top of the KDE4
module. This suppresses the error about duplicate targets. Now that the
policy line has been removed, cmake will error out on duplicate targets.

Commit which caused this error (introduced in kdelibs 4.14.22):
https://github.com/KDE/kdelibs/commit/dda2199d601491c6ceb07b5f11c8696216558623

Since KDE4 also ships an uninstall target, I see no reason to keep the
one in kmidimon.

Thanks,
James



signature.asc
Description: OpenPGP digital signature


Bug#833401: debian-policy: virtual packages: dbus-session-bus, dbus-default-session-bus

2016-08-03 Thread Simon McVittie
Package: debian-policy
Severity: wishlist
X-Debbugs-Cc: debian-de...@lists.debian.org

I propose two new virtual packages:

dbus-session-bus: anything providing the D-Bus well-known session bus
for user login sessions

dbus-default-session-bus: Debian's preferred implementation of
dbus-session-bus

Currently, many packages that require a D-Bus session bus express that
dependency by depending on dbus-x11. Many more packages rely on a session
bus without an explicit dependency. I would like to deprecate dbus-x11
(which provides a D-Bus session bus per X11 session to that X11 session)
in favour of dbus-user-session (which provides a D-Bus session bus per
uid, shared by all concurrent PAM sessions), while keeping dbus-x11
supported as a non-preferred implementation.

>From discussion in the related MBF plan
, I am led
to believe that the preferred way to do this is with two virtual packages,
analogous to mail-transport-agent and default-mta.

dbus-session bus would be provided by dbus-x11, dbus-user-session, and
possibly something kdbus-related in future. The intended semantics are:
programs in at least graphical login sessions can rely on seeing the
$DBUS_SESSION_BUS_ADDRESS environment variable, the $XDG_RUNTIME_DIR/bus
Unix socket, or some other way to discover a session bus that is supported
by all the major D-Bus client libraries.

dbus-default-session-bus would be provided by exactly one package per suite
that is the preferred implementation, currently dbus-user-session.

Programs and desktop environments that require a D-Bus session bus and cannot
work without one should generally declare:

Depends: dbus-default-session-bus | dbus-session-bus

Programs with weaker dependencies can use a Recommends or a Suggests.

Other options
=

If this is not a best-practice use of virtual packages, the other options that
I am aware of are:

* Add a real (non-virtual) empty package dbus-session-bus built by src:dbus,
  with Depends: dbus-user-session | dbus-x11 (initially). Other packages
  depend on dbus-session-bus.
  (Pro: simpler dependency graph. Con: requires NEW queue.)

* Add a virtual package dbus-session-bus, and a real (non-virtual) package
  dbus-default-session-bus built by src:dbus.
  (Pro: avoids ambiguity if apt is configured to see more than one suite.
  Con: requires NEW queue.)

* Give packages a direct Depends: dbus-user-session | dbus-x11, and do
  another MBF if we decide post-stretch that we should actually be
  preferring a third implementation, kdbus-session-bus or something.
  (Pro: no proliferation of package names. Con: possible MBF in future.)

* MBF asking applications to stop depending on dbus-x11, and just
  assume that any reasonable desktop environment will pull in
  dbus-user-session | dbus-x11 anyway, in the same way that applications
  are not expected to depend on an X11 server.
  (Pro: simplest possible dependency graph. Con: undeclared dependency.)

Regards,
S



Bug#833328: [Pkg-openssl-devel] Bug#833328: Bug#833328: openssl does not start on x86_64: version `OPENSSL_1.0.1s' not found

2016-08-03 Thread Sebastian Andrzej Siewior
On 2016-08-03 17:06:22 [+0200], Kurt Roeckx wrote:
> You're using openssl from stable but libssl1.0.0 from backports.
> 
> It's rather annoying, but I wasn't sure how to deal with it.  I
> guess I should add a Breaks in the backports version.

I think the linker version script is wrong. In stable we have:

OPENSSL_1.0.1s {
global:
SRP_VBASE_get1_by_user;
SRP_user_pwd_free;
}

and bpo we have

OPENSSL_1.0.2g {
global:
SRP_VBASE_get1_by_user;
SRP_user_pwd_free;
}

I think we have to use 1.0.1s unless there was a ABI change. If there
was a change we would need to update the symbols files.
nginx (bpo) picked up the correct dependency due to the ALPN symbols so
that worked as planned :)

If I read codesearch.d.n right then openssl is the only use of those two
symbols so nothing else should be affected.

> Kurt

Sebastian



Bug#832713: systemd: after "systemd (231-1) unstable" update systemd-jurnald.service fails to start

2016-08-03 Thread Rick Thomas

On Aug 3, 2016, at 9:06 AM, Felipe Sateler  wrote:

> On 1 August 2016 at 18:32, Rick Thomas  wrote:
>> 
>> Thanks, Filipe!
>> 
>> What do we have to do at this point to test this and then translate it into 
>> a patch?
> 
> OK, so I have a proof-of-concept patch. Rick, could you test it in your 
> machine?

I’m afraid I don’t have the facilities or the expertise to turn this into a 
loadable kernel .deb .

If someone can provide an installable kernel .deb file for a Cuboxi4-Pro 
machine, I’ll he happy to test it.

Thanks!
Rick


Bug#833400: google-android-m2repository-installer: [INTL:pt] Portuguese translation - debconf messages

2016-08-03 Thread Américo Monteiro
Package: google-android-m2repository-installer
Version: 35
Tags: l10n, patch
Severity: wishlist

Updated Portuguese translation for google-android-m2repository-installer's 
debconf messages
Translator: Américo Monteiro 
Feel free to use it.

For translation updates please contact 'Last Translator' or the
Portuguese Translation Team .

-- 
Melhores cumprimentos/Best regards,

Américo Monteiro# Trandlation of google-android-m2repository's debconf messages to European Portuguese
# Copyright (C) 2016 THE google-android-m2repository'S COPYRIGHT HOLDER
# This file is distributed under the same license as the google-android-m2repository-installer package.
#
# Américo Monteiro , 2016.
msgid ""
msgstr ""
"Project-Id-Version: google-android-m2repository-installer\n"
"Report-Msgid-Bugs-To: google-android-m2repository-installer@packages.debian."
"org\n"
"POT-Creation-Date: 2016-07-18 13:32+\n"
"PO-Revision-Date: 2016-08-03 21:41+0100\n"
"Last-Translator: Américo Monteiro \n"
"Language-Team: Portuguese \n"
"Language: pt\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
"Plural-Forms: nplurals=2; plural=(n != 1);\n"
"X-Generator: Lokalize 1.5\n"

#. Type: select
#. Description
#: ../templates:1001
msgid "Mirror to download packages ?"
msgstr "Mirror para descarga de pacotes ?"

#. Type: select
#. Description
#: ../templates:1001
msgid ""
"Please select your prefered mirror to download Google's Android packages "
"from."
msgstr ""
"Por favor seleccione o seu mirror preferido de onde descarregar os "
"pacotes Android da Google."



Bug#833399: wims: please make the build reproducible

2016-08-03 Thread Chris Lamb
Source: wims
Version: 1:4.11c~dfsg1-1
Severity: wishlist
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: timestamps
X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org

Hi,

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

Patch attached.

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


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-
--- a/debian/patches/90reproducible-build.patch 1969-12-31 19:00:00.0 
-0500
--- b/debian/patches/90reproducible-build.patch 2016-08-03 16:20:00.459487438 
-0400
@@ -0,0 +1,20 @@
+Description: Make the build reproducible
+Author: Chris Lamb 
+Last-Update: 2016-08-03
+
+--- wims-4.11c~dfsg1.orig/wims/src/configure.ac
 wims-4.11c~dfsg1/wims/src/configure.ac
+@@ -215,7 +215,12 @@ if test "$with_wimsd" = "yes"; then
+   BUILD_WIMSD=wimsd
+ fi
+ 
+-date=`date +%Y-%m-%d`
++if test -n "$SOURCE_DATE_EPOCH"; then
++  date=`date --utc --date="@$SOURCE_DATE_EPOCH" +%Y-%m-%d`
++else
++  date=`date +%Y-%m-%d`
++fi
++
+ DEFINES="-DGNU_SOURCE -DVERSION_DATE=\\\"$date\\\""
+ AC_SUBST(D_CASE_INSENSITIVE_FS)
+ AC_SUBST(STATIC_LIB)
--- a/debian/patches/series 2016-08-03 16:10:18.278271329 -0400
--- b/debian/patches/series 2016-08-03 16:19:58.631468101 -0400
@@ -6,3 +6,4 @@
 60flydraw.patch
 70fix-find-syntax-for-perm.patch
 80makefile-for-jmEvers-scripts.patch
+90reproducible-build.patch


Bug#832336: jessie-pu: package systemd/215-17+deb8u5

2016-08-03 Thread Julien Cristau
On Wed, Aug  3, 2016 at 22:32:16 +0200, Michael Biebl wrote:

> Am 29.07.2016 um 23:00 schrieb Michael Biebl:
> > Am 29.07.2016 um 14:00 schrieb Julien Cristau:
> >> This looks fine in general, I'm just wondering if the effect of bumping
> >> the util-linux dependency on upgrades from wheezy was considered/tested?
> > 
> > It was not specifically tested since I didn't expect any breakage
> > because of it. But I did it now for a basic wheezy system the upgrade to
> > jessie (with the updated systemd packages) worked fine. The tightened
> > dep on u-l seems to not cause any issues.
> > 
> > I've attached the typescript from the wheezy → jessie dist-upgrade.
> 
> Is that sufficient or do you still have concerns?
> 
I'm definitely concerned about changing dependencies in the base system
in stable, yes.  Is the parallel fsck bug that bad?

Cheers,
Julien



Bug#829330: Please update hyperref from version v6.83p to v6.83q

2016-08-03 Thread Norbert Preining
I'm traveling till Monday on conferences. After this I'll prepare packages.

On August 3, 2016 2:17:13 PM EDT, James Murphy  
wrote:
>On Sun, 3 Jul 2016 07:12:21 +0900 Norbert Preining 
>wrote:
>> > Please update hyperref from version v6.83p to v6.83q.
>> 
>> Will be in the next checkout from upstream TeX Live which
>> already contains the q version.
>> 
>> Norbert
>
>Just wanted to bump this. Sorry for my impatience as well, but any idea
>when the next checkout will be? I've been eagerly awaiting this bug's
>demise. Thanks for your support.
>
>James

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



Bug#832336: jessie-pu: package systemd/215-17+deb8u5

2016-08-03 Thread Michael Biebl
Am 29.07.2016 um 23:00 schrieb Michael Biebl:
> Am 29.07.2016 um 14:00 schrieb Julien Cristau:
>> This looks fine in general, I'm just wondering if the effect of bumping
>> the util-linux dependency on upgrades from wheezy was considered/tested?
> 
> It was not specifically tested since I didn't expect any breakage
> because of it. But I did it now for a basic wheezy system the upgrade to
> jessie (with the updated systemd packages) worked fine. The tightened
> dep on u-l seems to not cause any issues.
> 
> I've attached the typescript from the wheezy → jessie dist-upgrade.

Is that sufficient or do you still have concerns?

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#833398: vmdebootstrap: correcting broken after custom packages fails to pass yes

2016-08-03 Thread Sam Hartman
Package: vmdebootstrap
Version: 1.5-1
Severity: normal


ERROR: command failed: ['chroot', '/tmp/tmpuio60u', 'apt-get', '-f', '--no-remov
e', 'install']
Reading package lists...  
Building dependency tree...   
Correcting dependencies... Done
The following additional packages will be installed:
  dh-python libmpdec2 libpython3-stdlib libpython3.5-minimal
  libpython3.5-stdlib python3 python3-minimal python3-netifaces python3-parted
  python3-sh python3.5 python3.5-minimal
Suggested packages:
  libdpkg-perl python3-doc python3-tk python3-venv python3.5-venv
  python3.5-doc binutils binfmt-support
The following NEW packages will be installed:
  dh-python libmpdec2 libpython3-stdlib libpython3.5-minimal
  libpython3.5-stdlib python3 python3-minimal python3-netifaces python3-parted
  python3-sh python3.5 python3.5-minimal
0 upgraded, 12 newly installed, 0 to remove and 0 not upgraded.
1 not fully installed or removed.
Need to get 4898 kB of archives.
After this operation, 24.6 MB of additional disk space will be used.
Do you want to continue? [Y/n] Abort.


I think you want a -y on that command line as well.
The current behavior is clearly wrong.  The issue here is that the
custom package depends on packages not in the image.


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

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

Versions of packages vmdebootstrap depends on:
ii  debootstrap 1.0.81
ii  extlinux3:6.03+dfsg-14
ii  kpartx  0.6.1-3
ii  libjs-sphinxdoc 1.4.4-2
ii  mbr 1.1.11-5+b1
ii  parted  3.2-15
ii  python-cliapp   1.20160316-1
ii  python-distro-info  0.14
ii  python2.7   2.7.12~rc1-2
pn  python:any  
ii  qemu-utils  1:2.6+dfsg-3

Versions of packages vmdebootstrap recommends:
ii  grub2-common  2.02~beta2-36
ii  python-guestfs1:1.32.4-2
ii  qemu-system   1:2.6+dfsg-3
ii  qemu-user-static  1:2.6+dfsg-3
ii  squashfs-tools1:4.3-3

Versions of packages vmdebootstrap suggests:
pn  cmdtest   
pn  pandoc
pn  u-boot:armhf  

-- no debconf information



Bug#696332: lsb-release: release/codename depend on a successful apt-get

2016-08-03 Thread Axel Beckert
Control: found -1 9.20160629

Hi Didier,

Didier 'OdyX' Raboud wrote:
> > If an apt-get update fails (i.e. no internet connection), the lsb
> > codename will change to "n/a", which shouldn't happen. Release changes
> > to "testing/unstable".

I just ran into this on a uptodate Debian Sid system, but the reason
seems a different one than varacanero has. The issue only happens for me
if I run "lsb_release -a" as non-privileged user.

It's also easier to reproduce for me:

As normal user:

→ lsb_release -a
No LSB modules are available.
Distributor ID: Debian
Description:Debian GNU/Linux unstable (sid)
Release:unstable
Codename:   sid

So far everything looks fine.

Then use dpkg (not apt/apt-get/aptitude) to install a debian package
which is either not yet installed or already installed with a
different version:

# dpkg -i some.deb

(Reinstalling a package at the same version does not seem to trigger
this issue.)

Now the output looks like this for any unprivileged user:

→ lsb_release -a
No LSB modules are available.
Distributor ID: Debian
Description:Debian GNU/Linux testing/unstable
Release:testing/unstable
Codename:   n/a

> How does your /etc/debian_version look like ? And what is the output
> of `apt-cache policy` ?

→ cat /etc/debian_version
stretch/sid
→ apt-cache policy
E: Problem renaming the file /var/cache/apt/pkgcache.bin.JkcuIW to
/var/cache/apt/pkgcache.bin - rename (1: Operation not permitted)
W: You may want to run apt-get update to correct these problems
E: The package cache file is corrupted

The latter output is very likely the reason for this issue.

To "fix" this, run _any_ command which causes a regeneration of apt's
package list cache as root. E.g. running "lsb_release -a" as root
already suffices and then it also works again for any unprivileged
user again. But of course "apt update" (without network issues) also
fixes this.

Hope this helps and contains enough information to allow the removal
of the "moreinfo" tag.

Regards, Axel
-- 
 ,''`.  |  Axel Beckert , http://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE



Bug#833396: audiotools: please make the build reproducible

2016-08-03 Thread Chris Lamb
Source: audiotools
Version: 3.1.1-1
Severity: wishlist
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: timestamps
X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org

Hi,

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

Patch attached.

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


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-
--- a/debian/patches/reproducible-build.patch   1969-12-31 19:00:00.0 
-0500
--- b/debian/patches/reproducible-build.patch   2016-08-03 16:00:41.954116812 
-0400
@@ -0,0 +1,30 @@
+Description: Make the build reproducible
+Author: Chris Lamb 
+Last-Update: 2016-08-03
+
+--- audiotools-3.1.1.orig/docs/manpagexml.py
 audiotools-3.1.1/docs/manpagexml.py
+@@ -17,6 +17,7 @@
+ # along with this program; if not, write to the Free Software
+ # Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA  02110-1301  
USA
+ 
++import os
+ import re
+ import time
+ from sys import version_info
+@@ -181,12 +182,14 @@ class Manpage:
+examples=examples)
+ 
+ def to_man(self, stream):
++curdate = time.gmtime(int(os.environ.get('SOURCE_DATE_EPOCH',
++ time.time(
+ write_u(stream,
+ (u".TH \"%(utility)s\" %(section)d " +
+  u"\"%(date)s\" \"\" \"%(title)s\"\n") %
+ {"utility": self.utility.upper(),
+  "section": self.section,
+- "date": time.strftime("%B %Y", time.localtime()),
++ "date": time.strftime("%F", curdate),
+  "title": self.title})
+ write_u(stream, u".SH NAME\n")
+ write_u(stream, u"%(utility)s \\- %(name)s\n" %
--- a/debian/patches/series 1969-12-31 19:00:00.0 -0500
--- b/debian/patches/series 2016-08-03 15:44:10.233516989 -0400
@@ -0,0 +1 @@
+reproducible-build.patch


Bug#833395: emacspeak: please make the build reproducible

2016-08-03 Thread Chris Lamb
Source: emacspeak
Version: 44.0+dfsg-1
Severity: wishlist
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: timestamps
X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org

Hi,

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

Patch attached.

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


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-
--- a/debian/patches/reproducible_build.patch   1969-12-31 19:00:00.0 
-0500
--- b/debian/patches/reproducible_build.patch   2016-08-03 16:01:53.454741128 
-0400
@@ -0,0 +1,35 @@
+Description: Make the build reproducible
+Author: Chris Lamb 
+Last-Update: 2016-08-03
+
+--- emacspeak-44.0+dfsg.orig/sounds/3d/src/scroll.csd
 emacspeak-44.0+dfsg/sounds/3d/src/scroll.csd
+@@ -13,8 +13,8 @@ kaz1 linseg -90, p3, 90
+ kaz2  linseg 45, p3, 225
+ kenv linseg 0.5, p3, 0.1
+ ; generate pink noise
+-an1  pinkish 1
+-an2  pinkish  0.25
++an1  pinkish 1 20 1
++an2  pinkish  0.25 20 1
+ al1, ar1 hrtfmove2 an1, kaz1, -40, 
"hrtf-44100-left.dat","hrtf-44100-right.dat"   
+ al2, ar2 hrtfmove2 an2, kaz2, 40, 
"hrtf-44100-left.dat","hrtf-44100-right.dat"
+ ; write audio out
+--- emacspeak-44.0+dfsg.orig/sounds/3d/src/window-resize.csd
 emacspeak-44.0+dfsg/sounds/3d/src/window-resize.csd
+@@ -9,12 +9,13 @@ nchnls = 2
+ 0dbfs = 1
+ 
+ instr 1 
++seed 10
+ kaz1  linseg -360, p3, 0
+ kaz2  linseg 0, p3, 360
+ kenv linseg 0.5, p3, 0.1
+ ; generate pink noise
+-an1  pinkish 1
+-an2  pinkish  0.15
++an1  pinkish 1 20 1
++an2  pinkish  0.15 20 1
+ al1, ar1 hrtfmove2 an1, kaz1, -40, 
"hrtf-44100-left.dat","hrtf-44100-right.dat"   
+ al2, ar2 hrtfmove2 an2, kaz2, 40, 
"hrtf-44100-left.dat","hrtf-44100-right.dat"
+ ; write audio out
--- a/debian/patches/series 2016-08-03 15:59:31.457501122 -0400
--- b/debian/patches/series 2016-08-03 16:01:48.642699115 -0400
@@ -5,3 +5,4 @@
 fix_lintian_privacy-breach-logo_error.patch
 add_DESTDIR_to_makefile.patch
 dont_install_OUTLOUD_for_now.patch
+reproducible_build.patch


Bug#833394: wmweather: URL of data source has changed

2016-08-03 Thread Matthieu Weber
Package: wmweather
Version: 2.4.5-2
Severity: grave
Tags: upstream patch
Justification: renders package unusable

Dear Maintainer,

The URL of the source of the data used by wmweather has changed, causing
the software to exit immediately upon start.

The fix is trivial, and a patch is included.

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

Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.ISO-8859-15, LC_CTYPE=en_US.ISO-8859-15 (charmap=ISO-8859-1) 
(ignored: LC_ALL set to en_US.iso88591)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages wmweather depends on:
ii  libc62.19-18+deb8u4
ii  libcurl3-gnutls  7.38.0-4+deb8u4
ii  libx11-6 2:1.6.2-3
ii  libxext6 2:1.3.3-1
ii  libxpm4  1:3.5.11-1+b1

Versions of packages wmweather recommends:
ii  x11-utils  7.7+2

Versions of packages wmweather suggests:
ii  wmaker  0.95.5-2+b2

-- no debconf information
diff -Nru wmweather-2.4.5/debian/changelog wmweather-2.4.5/debian/changelog
--- wmweather-2.4.5/debian/changelog	2013-12-30 17:28:13.0 +0200
+++ wmweather-2.4.5/debian/changelog	2016-08-03 21:52:36.0 +0300
@@ -1,3 +1,10 @@
+wmweather (2.4.5-2.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Updated NOAA URL
+
+ -- Matthieu Weber   Wed, 03 Aug 2016 21:52:24 +0300
+
 wmweather (2.4.5-2) unstable; urgency=low
 
   * Updated build system.
diff -Nru wmweather-2.4.5/debian/patches/series wmweather-2.4.5/debian/patches/series
--- wmweather-2.4.5/debian/patches/series	1970-01-01 02:00:00.0 +0200
+++ wmweather-2.4.5/debian/patches/series	2016-08-03 21:52:50.0 +0300
@@ -0,0 +1 @@
+update-url.patch
diff -Nru wmweather-2.4.5/debian/patches/update-url.patch wmweather-2.4.5/debian/patches/update-url.patch
--- wmweather-2.4.5/debian/patches/update-url.patch	1970-01-01 02:00:00.0 +0200
+++ wmweather-2.4.5/debian/patches/update-url.patch	2016-08-03 21:53:29.0 +0300
@@ -0,0 +1,11 @@
+--- a/src/wmweather.c
 b/src/wmweather.c
+@@ -62,7 +62,7 @@
+ static struct memory
+ 	header = {NULL, 0};
+ char
+-	url[]   = "http://weather.noaa.gov/pub/data/observations/metar/decoded/\0\0\0\0.TXT;,
++	url[]   = "http://tgftp.nws.noaa.gov/data/observations/metar/decoded/\0\0\0\0.TXT;,
+ 	xtitle[]= "weather report for \0\0\0\0\0",
+ 	*station= NULL,
+ 	*report = NULL,


Bug#832456: elfutils: improve handling of DEB_BUILD_OPTIONS=nocheck

2016-08-03 Thread Kurt Roeckx
On Wed, Aug 03, 2016 at 06:56:59PM +0200, Mark Wielaard wrote:
> Hi,
> 
> On Wed, 2016-07-27 at 18:16 +0200, Helmut Grohne wrote:
> > > I'm wondering if I should just disable the biarch tests on all
> > > arches and remove the gcc-multilib Depends completly.
> > 
> > I won't disagree with that.
> > 
> > Personally, I'd like to see biarch/multilib to die as soon as possible.
> > Unfortunately, it looks like we'll have to support it for quite some
> > time yet. Still we don't have to add it for new architectures (like
> > ppc64el).
> 
> As upstream hacker I would like to see the native/biarch tests been run
> if at all possible. They do show if we do the right thing when a 64-bit
> process uses elfutils to inspect a 32-bit process running on the system.
> If we get that wrong I do like to know about it. But some of the
> native/biarch tests are a little fragile (failures can occur not just
> for the cross 32/64 word issue, but also because of ptrace/proc,
> eh_frame issues, symbol table completeness, etc.) So if there is
> anything we can do to make these tests easier/simpler/better please let
> us/upstream know.

I already changed my mind to keep it as it currently is.

But Maybe we should have an option to test x32 on x86_64.

And I guess there are some other things that could be tested too.


Kurt



Bug#816987: NMU + patch for: Bug#816987: plplot: FTBFS when built with dpkg-buildpackage -A (Error copying file)

2016-08-03 Thread Axel Beckert
Control: tag -1 + patch pending

Hi,

Santiago Vila wrote:
> I tried to build this package with "dpkg-buildpackage -A"
> (i.e. only architecture-independent packages), and it failed:

Reason is that the build-indep-stamp does not depend on the config or
config-stamp target and hence "dpkg-buildpackage -A" tries to build
more or at least different bindings than Debian intents.

> Sorry not to have a fix, as I am reporting many bugs similar to
> this one.

The patch was quite simple in the end:

-build-indep-stamp:
+build-indep-stamp: config-stamp

I've uploaded a fixed package as non-maintainer upload to DELAYED/5 to
avoid the removal of plplot's reverse dependencies from testing.
Feel free to tell me if I should delay it longer or fast forward it.

Here's the full debdiff:

diff -Nru plplot-5.10.0+dfsg2/debian/changelog 
plplot-5.10.0+dfsg2/debian/changelog
--- plplot-5.10.0+dfsg2/debian/changelog2016-02-16 22:32:31.0 
+0100
+++ plplot-5.10.0+dfsg2/debian/changelog2016-08-03 21:18:45.0 
+0200
@@ -1,3 +1,11 @@
+plplot (5.10.0+dfsg2-0.3) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTBFS with "dpkg-buildpackage -A" by letting build-indep-stamp
+depend on config-stamp in debian/rules. (Closes: #816987)
+
+ -- Axel Beckert   Wed, 03 Aug 2016 21:18:45 +0200
+
 plplot (5.10.0+dfsg2-0.2) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru plplot-5.10.0+dfsg2/debian/rules plplot-5.10.0+dfsg2/debian/rules
--- plplot-5.10.0+dfsg2/debian/rules2016-02-16 18:37:24.0 +0100
+++ plplot-5.10.0+dfsg2/debian/rules2016-08-03 21:14:06.0 +0200
@@ -128,7 +128,7 @@
touch build-arch-stamp
 
 build-indep: build-indep-stamp
-build-indep-stamp:
+build-indep-stamp: config-stamp
dh_testdir
( cd $(BUILD_DIR) ; $(CMAKE) $(SRC_DIR) $(CONFIGURE_OPTIONS) 
-DBUILD_DOC=ON ; \
cd doc ; $(MAKE)  )

P.S. to Ole: As requested. ;-)

Regards, Axel
-- 
 ,''`.  |  Axel Beckert , http://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE



Bug#833392: hilive: FTBFS: assumes uint64_t is unsigned long

2016-08-03 Thread Aaron M. Ucko
Source: hilive
Version: 0.0+20150926-1
Severity: important
Justification: fails to build from source

Hi, Andreas.

Builds of hilive for 32-bit architectures such as i386 have been failing:

  /«BUILDDIR»/hilive-0.0+20150926/lib/alnblock.cpp:202:19: error: prototype for 
'long unsigned int DatasetAlignment::deserialize_file(std::__cxx11::string)' 
does not match any in class 'DatasetAlignment'
   unsigned long int DatasetAlignment::deserialize_file(std::string f /* = "" 
*/) {
 ^
  In file included from /«BUILDDIR»/hilive-0.0+20150926/lib/alnblock.cpp:1:0:
  /«BUILDDIR»/hilive-0.0+20150926/lib/alnblock.h:62:12: error: candidate is: 
uint64_t DatasetAlignment::deserialize_file(std::__cxx11::string)
 uint64_t deserialize_file(std::string f = "");
  ^

Please consistently use one type or the other here, and anywhere else
that conflates these types.  (I haven't looked further.)

Thanks!



Bug#808421: proposed solution

2016-08-03 Thread Dieter Adriaenssens

owner !
thanks

Hi,

In attachment a commit that adds debian/upstream/metadata.
Running duck gave no warnings

Kind regards,
Dieter
>From 4d3ec6db03fe44d42d482634d3201d21f3f2b597 Mon Sep 17 00:00:00 2001
From: Dieter Adriaenssens 
Date: Wed, 3 Aug 2016 21:18:58 +0200
Subject: [PATCH] Bug #808421 : Add upstream/metadata (DEP12)

Add a file with metadata about the upstream MariaDB project, as proposed
in DEP12

See : https://bugs.debian.org/808421
---
 debian/upstream/metadata | 8 
 1 file changed, 8 insertions(+)
 create mode 100644 debian/upstream/metadata

diff --git a/debian/upstream/metadata b/debian/upstream/metadata
new file mode 100644
index 000..692c316
--- /dev/null
+++ b/debian/upstream/metadata
@@ -0,0 +1,8 @@
+Name: MariaDB
+Bug-Database: http://mariadb.org/jira
+Bug-Submit: http://mariadb.org/jira
+Contact: maria-develop...@lists.launchpad.net
+Donation: https://mariadb.org/donate/
+Repository: git://github.com/MariaDB/server.git
+Repository-Browse: https://github.com/MariaDB/server
+Security-Contact: secur...@mariadb.org
-- 
2.5.0



Bug#832713: systemd: after "systemd (231-1) unstable" update systemd-jurnald.service fails to start

2016-08-03 Thread Michael Biebl
Am 03.08.2016 um 17:26 schrieb Felipe Sateler:
> Control: forwarded -1 https://github.com/systemd/systemd/issues/3882
> Control: severity -1 serious

> Yes, I'd like upstream's opinion on this first. However, I think this
> bug should be bumped to RC to prevent migration to testing, as this
> makes arm systems basically unusable. I have marked the bug as serios.
> Feel free to downgrade if you disagree.

No, I agree with the severity bump.

Regards,
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#776193: unshield: directory traversal

2016-08-03 Thread Petter Reinholdtsen
This issue is still unsolved upstream.  Upstream asked for pull requests
with a fix, but according to the SuSe bug report,
https://bugzilla.novell.com/show_bug.cgi?id=CVE-2015-1386 >, it is
not straight forward to figure out how to fix it.

-- 
Happy hacking
Petter Reinholdtsen



Bug#819700: ITP: airflow -- Programmatically author, schedule and monitor data pipelines

2016-08-03 Thread Daniel Stender
Great pick.

https://www.youtube.com/watch?v=i3AL3OQGJ6A

DS

-- 
4096R/DF5182C8
http://www.danielstender.com/blog/



Bug#833390: sbuild: cannot set *_root_args so as to not try to run the command as root

2016-08-03 Thread Sean Whitton
Package: sbuild
Version: 0.70.0-1
Severity: normal

Dear maintainer,

It should be possible to instruct sbuild not to run autopkgtest or
piuparts as root.  If using a schroot backend for autopkgtest, root is
not required, and hopefully this will soon be true for piuparts too
(#708663).

At present, the only way to stop sbuild from prepending sudo to the
autopkgtest command is something like this:

$autopkgtest_root_args = ["env"];

That's because setting

$autopkgtest_root_args = [];

implies

$autopkgtest_root_args = ["sudo", "--"];

There should be a better, documented way to not run the commands as
root.

Thanks!

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

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

Versions of packages sbuild depends on:
ii  adduser 3.115
ii  apt-utils   1.3~pre2
ii  libsbuild-perl  0.70.0-1
pn  perl:any

Versions of packages sbuild recommends:
ii  debootstrap  1.0.81
ii  fakeroot 1.21-1

Versions of packages sbuild suggests:
pn  deborphan  
ii  wget   1.18-2

-- no debconf information

-- 
Sean Whitton


signature.asc
Description: PGP signature


Bug#833389: Finding offset should not require network connectivity

2016-08-03 Thread Ryan Kavanagh
Package: morituri
Version: 0.2.3-2
Severity: normal
Tags: upstream

Finding a drive's offset should *not* require network connectivity.

$ rip offset find
Checking device /dev/cdrom
Traceback (most recent call last):
  File "/usr/bin/rip", line 41, in 
sys.exit(main.main(sys.argv[1:]))
  File "/usr/lib/python2.7/dist-packages/morituri/rip/main.py", line 45, in main
ret = c.parse(argv)
  File "/usr/lib/python2.7/dist-packages/morituri/rip/main.py", line 123, in 
parse
logcommand.LogCommand.parse(self, argv)
  File "/usr/lib/python2.7/dist-packages/morituri/extern/command/command.py", 
line 401, in parse
return self.subCommands[command].parse(args[1:])
  File "/usr/lib/python2.7/dist-packages/morituri/extern/command/command.py", 
line 401, in parse
return self.subCommands[command].parse(args[1:])
  File "/usr/lib/python2.7/dist-packages/morituri/extern/command/command.py", 
line 363, in parse
ret = self.do(args)
  File "/usr/lib/python2.7/dist-packages/morituri/rip/offset.py", line 121, in 
do
handle = urllib2.urlopen(url)
  File "/usr/lib/python2.7/urllib2.py", line 154, in urlopen
return opener.open(url, data, timeout)
  File "/usr/lib/python2.7/urllib2.py", line 429, in open
response = self._open(req, data)
  File "/usr/lib/python2.7/urllib2.py", line 447, in _open
'_open', req)
  File "/usr/lib/python2.7/urllib2.py", line 407, in _call_chain
result = func(*args)
  File "/usr/lib/python2.7/urllib2.py", line 1228, in http_open
return self.do_open(httplib.HTTPConnection, req)
  File "/usr/lib/python2.7/urllib2.py", line 1198, in do_open
raise URLError(err)
urllib2.URLError: 

Best,
Ryan

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

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

Versions of packages morituri depends on:
ii  cdparanoia 3.10.2+debian-11
ii  cdrdao 1:1.2.3-3
ii  gstreamer1.0-plugins-good  1.8.2-1
ii  python 2.7.11-2
ii  python-cddb1.4-5.2
ii  python-gi  3.20.1-1
ii  python-gobject 3.20.1-1
ii  python-gst-1.0 1.8.2-1
ii  python-musicbrainzngs  0.5-2
ii  python-pkg-resources   20.10.1-1.1

Versions of packages morituri recommends:
ii  gstreamer1.0-libav  1.8.2-1
ii  gstreamer1.0-tools  1.8.2-1
ii  python-xdg  0.25-4

Versions of packages morituri suggests:
pn  gstreamer1.0-plugins-ugly  
ii  python-gtk22.24.0-5
pn  python-pycdio  

-- no debconf information

-- 
|_)|_/  Ryan Kavanagh  | GPG: 4E46 9519 ED67 7734 268F
| \| \  https://ryanak.ca/ |  BD95 8F7B F8FC 4A11 C97A


signature.asc
Description: PGP signature


Bug#833388: ITP: metaphlan2 -- Metagenomic Phylogenetic Analysis

2016-08-03 Thread Andreas Tille
Package: wnpp
Severity: wishlist
Owner: Andreas Tille 

* Package name: metaphlan2
  Version : 2.5.0
  Upstream Author : Nicola Segata 
* URL : https://bitbucket.org/nsegata/metaphlan2/wiki/Home
* License : MIT
  Programming Lang: Python
  Description : Metagenomic Phylogenetic Analysis
 MetaPhlAn is a computational tool for profiling the composition of
 microbial communities (Bacteria, Archaea, Eukaryotes and Viruses) from
 metagenomic shotgun sequencing data with species level resolution. From
 version 2.0, MetaPhlAn is also able to identify specific strains (in the
 not-so-frequent cases in which the sample contains a previously
 sequenced strains) and to track strains across samples for all species.
 .
 MetaPhlAn 2.0 relies on ~1M unique clade-specific marker genes (the
 marker information file can be found at src/utils/markers_info.txt.bz2
 or here) identified from ~17,000 reference genomes (~13,500 bacterial
 and archaeal, ~3,500 viral, and ~110 eukaryotic), allowing:
 .
  * unambiguous taxonomic assignments;
  * accurate estimation of organismal relative abundance;
  * species-level resolution for bacteria, archaea, eukaryotes and
viruses;
  * strain identification and tracking
  * orders of magnitude speedups compared to existing methods.
  * metagenomic strain-level population genomics


Remark: The package is a target for Debian Med in itself and will be
used by metaBIT.  It will be maintained by the Debian Med team and the
packaging is currently available at
   svn://anonscm.debian.org/debian-med/trunk/packages/metaphlan2/trunk/


*** I'd like to discuss the following issue on debian-devel list ***

While Debian Med is injecting several low popularity contest packages
this one has an extraordinary large set of data and thus I want to
discuss the following options:

  1) Original orig.tar.gz has 1GB and contains 1.2GB uncompressed
 binary data.  License-wise it should not be a problem since
 there is a recipe given how to translate these into text form
 back and forth[1].

 We would have: source package 1GB + binary package 1GB

  2) When unpackaging the orig.tar.gz translating binary data to
 text format and recompress using xz the tarball is "only" 265MB.
 The transformation process takes about 30min on my Laptop - not
 longer than any larger project might need to build but the
 resulting binary package would have again close to 1GB.

 This enables the options:

 2a) Source tarball 256MB + binary package 1GB

 2b) Do the conversion of the format in postinst at the expense
 of users time which is acceptable since the package usually
 unpacks on high performance machines and not so many
 installations which means bandwidth and disk space on Debian
 mirrors should be saved here instead of users machine

 Source tarball 256MB + binary package ~250MB (estimated)

  3) Strip all data from the source package and download data in
 postinst from upstream Git repository.  This makes the package
 of uncritical size from a Debian point of view but might be
 problematic in some user setups which might have problems with
 larger data downloads (possibly be upstream can be convinced
 to provide a *.bz2 tarball for maximum compression).

 3a) Use postinst

 3b) Inform user to call a download script manually to do not
 block apt for a longer time dealing with potential download
 problems.

What do you think what strategy should be choosen to be kind to Debian
(and mirror) resources?

Kind regards

Andreas.

[1] 
https://bitbucket.org/biobakery/metaphlan2#markdown-header-customizing-the-database



Bug#833360: Kmidimon - French translation

2016-08-03 Thread Pedro Lopez-Cabanillas
Hi,

On Wednesday 03 August 2016 14:52:02 James Cowgill wrote:
> While this could be patched into the Debian version, it would be
> preferable to have a new upstream release.
> 
> Pedro, if you do make a new release, could you include this patch as well?
> 
> https://sources.debian.net/src/kmidimon/0.7.5-2/debian/patches/01-remove-uni
> nstall-target.patch/

I can't promise a deadline for the next kmidimon release, because I have  
another pending release much more mature right now: drumstick-1.1, and this 
library shall be required by a new kmidimon, along with Qt5. This is a similar 
situation to what happened with drumstick-1.0, kmetronome-1.0 and vmpk-0.6  
releases that have not been available for Debian and Ubuntu users since then.

So I guess that the same may be true for drumstick-1.1/kmidimon and Debian 
users wanting  the latest versions will need to build from sources, requiring 
both install and uninstall targets. 

I don't want to take your patch removing uninstall for everyone, but I don't 
mind to wrap the uninstall chuck with "if (NOT TARGET uninstall)", though.   
Below is an alternate patch. But before applying any patch, I would like to 
know why is it necessary. Is Debian breaking the build system of every project 
that offers a custom uninstall target?

Regards,
Pedro

Index: CMakeLists.txt
===
--- CMakeLists.txt  (revision 200)
+++ CMakeLists.txt  (working copy)
@@ -128,12 +128,14 @@
 "${CMAKE_SOURCE_DIR}/kmidimon.spec"
 IMMEDIATE @ONLY)
 
-CONFIGURE_FILE(
-"${CMAKE_SOURCE_DIR}/cmake_admin/cmake_uninstall.cmake.in"
-"${CMAKE_CURRENT_BINARY_DIR}/cmake_uninstall.cmake"
-IMMEDIATE @ONLY)
-ADD_CUSTOM_TARGET(uninstall
-"${CMAKE_COMMAND}" -P 
"${CMAKE_CURRENT_BINARY_DIR}/cmake_uninstall.cmake")
+if (NOT TARGET uninstall)
+CONFIGURE_FILE(
+"${CMAKE_SOURCE_DIR}/cmake_admin/cmake_uninstall.cmake.in"
+"${CMAKE_CURRENT_BINARY_DIR}/cmake_uninstall.cmake"
+IMMEDIATE @ONLY)
+ADD_CUSTOM_TARGET(uninstall
+"${CMAKE_COMMAND}" -P 
"${CMAKE_CURRENT_BINARY_DIR}/cmake_uninstall.cmake")
+endif()
 
 ADD_CUSTOM_TARGET ( tarball
 COMMAND mkdir -p kmidimon-${VERSION}



Bug#833119: libdbd-oracle-perl: Oracle Instant Client installation instructions outdated

2016-08-03 Thread Christoph Biedl
Alex Muntada wrote...

> What about using the whole README contents in the Description
> field in debian/control and get rid of README? Would it be too
> much?

In my opinion this is too much in detail for Description:

And the huge advantage of adding an indirection, you can change the
instructions easily in case they need an update. For example if Oracle
re-organises the web page, breaking all links. I cannot speak for this
company, other do this on a regular base :(

Christoph


signature.asc
Description: Digital signature


Bug#827296: connman: Connman slow down the boot when no network available

2016-08-03 Thread Brian Potkin
On Tue 02 Aug 2016 at 17:08:28 +0100, Brian Potkin wrote:

> On Thu 16 Jun 2016 at 18:33:45 +0200, Kristian Klausen wrote:
> 
> > I just checked NetworkManager, and they only install it
> > (NetworkManager-wait-online.service) but does not enable it.
> > 
> > I think that is the correct behavior, next time someone update connman
> > they could fix this bug :)
> 
> Please see #812209, Message #25.
> 
>  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=812209
> 
>   While we still have a few stragglers left, the most important blockers
>   have been dealt with. So I enable NM-wait-online with the last upload.

Having said that, there is still the question of the issue reported by
Florian; I see behaviour which supports his observations.

'apt-get install connman' sees the install process get to creating
symlinks and then hanging for nearly 2.5 minutes. This is very, very
disconcerting. I have not experienced anything like this before.

Eventually, it completes with the message:

  connman-wait-online.service couldn't start.

Sure enough, systemctl shows the unit in a failed state.

I nearly forgot to mention: that was with no ethernet cable connected
and the package cached. Connecting the cable and installing connman
takes the usual few seconds and connman-wait-online.service is active
afterwards.

Regards,

Brian.



Bug#546507: stormbaancoureur: fails to start (alsa issue?)

2016-08-03 Thread Markus Koschany
Control: tags -1 unreproducible

On Sun, 13 Sep 2009 20:44:48 +0200 =?utf-8?q?Gon=C3=A9ri_Le_Bouder?=
 wrote:
> Package: stormbaancoureur
> Version: 2.1.5-5+b1
> Severity: important
> 
> /tmp$stormbaancoureur
> Version 2.1.5-generic
> Stormbaan Coureur is (c)2006-2008 by Bram Stolk
> plib is (c) by Steve Baker
> OpenDE is (c) by Russel L. Smith
> 640x480-16@72
> OpenGL is version 2.1 Mesa 7.5.1
> OpenGL renderer Mesa DRI Mobile Intel® GM45 Express Chipset GEM 20090712 
> 2009Q2 RC3 x86/MMX/SSE2
> This platform supports all required GL extensions to do hardware accelerated 
> shadowing.
> DEBUG: ssgLoadTGA: Loading 
> '/usr/share/games/stormbaancoureur/images/spot.tga', RGB 512x512-24 RLE.
> open() on joystick device failed: No such file or directory
> Cannot open /home/goneri/.stormbaancoureur.keys
> Using keyboard
> Asked for 44100Hz playback rate, but got 44099Hz
> soundenginealsa.cxx: period size SOLL-WERT 625, IST-WERT 940
> soundenginealsa.cxx: buffer size SOLL-WERT 5000, IST-WERT 4703
> soundenginealsa.cxx: WARNING - buffersz is not a multiple of periodsz
> Number of samples per pixel: 0
> Number of samples per pixel: 0
> stormbaancoureur: ../src-common/soundenginealsa.cxx:238: float 
> SoundEngineAlsa::Susta
> in(): Assertion `rc == -32 || rc >= 0' failed.
> Abandon

I could not reproduce this one on my system. Thus tagging it as
unreproducible.

Markus






signature.asc
Description: OpenPGP digital signature


Bug#833387: ITP: mapdamage -- tracking and quantifying damage patterns in ancient DNA sequences

2016-08-03 Thread Andreas Tille
Package: wnpp
Severity: wishlist
Owner: Andreas Tille 

* Package name: mapdamage
  Version : 2.0.6
  Upstream Author : Jónsson H, Ginolhac A, Schubert M, Johnson P, Orlando L.
* URL : https://github.com/ginolhac/mapDamage
* License : MIT
  Programming Lang: Python
  Description : tracking and quantifying damage patterns in ancient DNA 
sequences
 MapDamage is a computational framework written in Python and R, which
 tracks and quantifies DNA damage patterns among ancient DNA sequencing
 reads generated by Next-Generation Sequencing platforms.
 .
 MapDamage is developed at the Centre for GeoGenetics by the
 Orlando Group.


Remark: This package is useful in connection with metaBIT and will
be maintained by the Debian Med team at
   https://anonscm.debian.org/git/debian-med/mapdamage.git



Bug#533715:

2016-08-03 Thread Grace Bunyan
Greeting, Did you receive the fund letter i send you last? from Grace Bunyan



Bug#829135: jessie-pu: package python2.7/2.7.9-2+deb8u1

2016-08-03 Thread Moritz Mühlenhoff
On Tue, Jul 12, 2016 at 09:55:23PM +0100, Adam D. Barratt wrote:
> Control: tags -1 + confirmed
> 
> On Thu, 2016-06-30 at 22:17 +0200, Moritz Muehlenhoff wrote:
> > +python2.7 (2.7.9-2+deb8u1) jessie; urgency=medium
> > +
> > +  * Backport upstream commit b3ce713fb9beebfff9848cefa0acbd59acc68fe9
> > +to address StartTLS stripping attack in smtplib (CVE-2016-0772)
> > +  * Backport upstream commit 985fc64c60d6adffd1138b6cc46df388ca91ca5d
> > +to address integer overflow in zipimporter (CVE-2016-5636)
> > +  * Backport upstream commit 1c45047c51020d46246385949d5c02e026d47320
> > +to address HTTP header injection (CVE-2016-5699)
> 
> Please go ahead.

Uploaded.

Cheers,
Moritz



Bug#829330: Please update hyperref from version v6.83p to v6.83q

2016-08-03 Thread James Murphy
On Sun, 3 Jul 2016 07:12:21 +0900 Norbert Preining 
wrote:
> > Please update hyperref from version v6.83p to v6.83q.
> 
> Will be in the next checkout from upstream TeX Live which
> already contains the q version.
> 
> Norbert

Just wanted to bump this. Sorry for my impatience as well, but any idea
when the next checkout will be? I've been eagerly awaiting this bug's
demise. Thanks for your support.

James



Bug#833119: libdbd-oracle-perl: Oracle Instant Client installation instructions outdated

2016-08-03 Thread Alex Muntada
Christoph Biedl:

> Nice. You plan to leave the description in debian/control unchanged?
> Then I suspect people will still follow just the link there and might
> get stuck the way I did. It's so clickable in
> https://packages.debian.org/sid/libdbd-oracle-perl
> 
> Also README.Debian is not accessible before the package is installed,
> but it's not installable before the procedures described there to
> install the instant client have been followed %-)

Hmm, you're absolutely right. I didn't remember that detail and
I think it's really the key to improve the whole documentation.

> So I'd rather re-phrase the last sentence, use an URL to your README,
> and also mention the arch restriction.
> 
> | To install the Instant Client, available for the i386 and amd64 archs
> | only, download the RPM package from the Oracle web page and install it
> | using Alien. Detailled instructions for this are available at
> | 
> 

What about using the whole README contents in the Description
field in debian/control and get rid of README? Would it be too
much?

Thanks!
Alex



signature.asc
Description: Digital signature


Bug#833386: robustirc-bridge: init script can't stop daemon: unable to stat //robustirc-bridge (No such file or directory)

2016-08-03 Thread Axel Beckert
Package: robustirc-bridge
Version: 1.5-1
Tags: patch

Dear Michael,

trying to stop the robustirc-bridge daemon on a system with sysvinit as
init system fails for me as follows on multiple machines:

# service robustirc-bridge stop
start-stop-daemon: unable to stat //robustirc-bridge (No such file or directory)

The following patch fixes the issue for me:

diff --git a/debian/robustirc-bridge.init b/debian/robustirc-bridge.init
index bbddcc0..c07aaa6 100644
--- a/debian/robustirc-bridge.init
+++ b/debian/robustirc-bridge.init
@@ -78,7 +78,7 @@ do_stop()
#   1 if daemon was already stopped
#   2 if daemon could not be stopped
#   other if a failure occurred
-   start-stop-daemon --stop --quiet --retry=TERM/30/KILL/5 --pidfile 
$PIDFILE --exec $NAME
+   start-stop-daemon --stop --quiet --retry=TERM/30/KILL/5 --pidfile 
$PIDFILE --exec $DAEMON
RETVAL="$?"
[ "$RETVAL" = 2 ] && return 2
fi

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

Kernel: Linux 4.6.0-trunk-amd64 (SMP w/8 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 robustirc-bridge depends on:
ii  init-system-helpers  1.42
ii  libc62.23-4

robustirc-bridge recommends no packages.

robustirc-bridge suggests no packages.

-- no debconf information



Bug#833385: xfce4-terminal: newer upstream release (0.6.90)

2016-08-03 Thread Tianon Gravi
Package: src:xfce4-terminal
Version: 0.6.3-2
Severity: wishlist

It's been 3 years in the making, but Igor's released 0.6.90 recently
with a bunch of neat enhancements that it'd be really great to see in
Debian! :)

Full changelog is available [1], but some of the highlights IMO are:

- VTE3 (text reflow on window resize)
- option for unlimited scrollback
- ability to zoom in/out by pressing Ctrl +/-
- new "MiscMiddleClickOpensUri" for disabling middle click opening URIs

[1]: https://git.xfce.org/apps/xfce4-terminal/tree/NEWS?id=xfce4-terminal-0.6.90

♥,
- Tianon
  4096R / B42F 6819 007F 00F8 8E36  4FD4 036A 9C25 BF35 7DD4



Bug#833378: keyboard-configuration: config script fails (syntax error)

2016-08-03 Thread Dominik George
Package: keyboard-configuration
Version: 1.148
Followup-For: Bug #833378
Control: tag -1 + patch

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Find attached a patch that fixes this class of syntax errors.

- -nik

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQJOBAEBCAA4BQJXoit6MRpodHRwczovL3d3dy5kb21pbmlrLWdlb3JnZS5kZS9n
cGctcG9saWN5LnR4dC5hc2MACgkQt5o8FqDE8pZ9bRAA0lSh2Rosa3EVwNDACGi8
zJdtX3hxnEaxyl/iF9VFSH8jLFM+xgbvBw/dHsJFIgoZR3/SXJakkfWIoIRY9rpK
/nlC/ozFaz6zn12kOo5kU9syShSZI7z7lbNSxfUXGKkMod0exPnxbabI6g7794nP
H3IOiKy3St9Xc4afOJd1dXikjKpSsRYop+YbeoT+Ffx5QQ2Gx+t6nZbjLlpzPbxE
7lrrjJEO5z4jU2uI3LA+bzFgpDVhAA+RmdFFQdt1xYOXoIPQgi8N3BifJ8AqeECJ
c2us1jdJ38i9LpiyaFTA4YOy2OE3Kr405rKbX9aeWyin2NrCp9P1dtCLCzImVHY2
1BNsMcJig+J2Jfpr30GjIBr8bvSDb2VnhCZ2Q1XwddFukay+lNO7cOkOZDNNWwKT
SsOVvdot/Fq68iYYQwG+dxTnMAJ1PTxVB1GXIo4amT+Yo8uDysIvHuFKRCnoCUPC
h0o+UOf8YdUZ48J6fKCw0nF8P3Y1MWwVItcMoRpjNRzFskv0y++bhJaU9a/n5m4P
SpiCkOo/muf9icHNfNUjamTNvFXhqlctjlnL9IxD4TV+nyF/thTiEQ2uMfwNPwgP
ylb5rVZA6P9OAG+vRTYXPzHfZTL7pu15uAw2pkKdipORqaLqEeEGsJ0RAEohnfJB
ttBk8XKpeV2ZigvVSNIUxiA=
=Turl
-END PGP SIGNATURE-
--- keyboard-configuration.config	2016-08-03 18:56:12.748813432 +0200
+++ keyboard-configuration.config.new	2016-08-03 19:33:26.934585427 +0200
@@ -34615,10 +34615,10 @@
 # Get defaults from debconf, to allow preseeding in the udeb
 if db_get keyboard-configuration/xkb-keymap && [ "$RET" ]; then
 keymap="$RET"
-layout="${keymap%(*}"
+layout="${keymap%\(*}"
 variant="${keymap#$layout}"
-variant="${variant%)}"
-variant="${variant#(}"
+variant="${variant%\)}"
+variant="${variant#\(}"
 XKBLAYOUT="$layout"
 XKBVARIANT="$variant"
 fi
@@ -35114,10 +35114,10 @@
 		db_fset keyboard-configuration/variant seen true
 		db_get keyboard-configuration/xkb-keymap
 		keymap="$RET"
-		debconf_layout="${keymap%(*}"
+		debconf_layout="${keymap%\(*}"
 		debconf_variant="${keymap#$debconf_layout}"
-		debconf_variant="${debconf_variant%)}"
-		debconf_variant="${debconf_variant#(}"
+		debconf_variant="${debconf_variant%\)}"
+		debconf_variant="${debconf_variant#\(}"
 		STATE=$(($STATE + 1))
 		else
 		STATE=$(($STATE - 1))


Bug#833384: wordnet: multiple packages for the same database

2016-08-03 Thread Ritesh Raj Sarraf
Source: wordnet
Severity: normal

Hi,

Is there a good reason for having 3 separate packages for the same
wordnet lexical database?

Right now, we have:

wordnet
goldendict-wordnet
dict-wn
dico-module-wordnet


>From a dictionary server point of view, having just one pacakge would
have been nicer. But I can see the argument that may come the other way
around too.

Tools like GoldenDict are nicer that they are able to scan the installed
dictionaries in dict format. This way, it helps the user who could use
the client/server dict interface, as well as the very pretty and useful
goldendict interface.

Is there some way to have it common ? I can see some information loss of
the results from goldendict-wordnet vs dict-wn use case.

The other concerning thing is the multiple copies with different
versions/wordcounts.

dico-module-wordnet is at version 2.2-9. I'm not sure what the db
version is at.

On the rest of the wordnet packages in Debian, you are the maintainer
for all of them. All the packages are at the same version, but their
word counts are slightly different.

For example, as per goldendict dictionaries tab:
goldendict-wordnet  => Total Words: 148730
dict-wn => Total Words: 147311


Also, the results of dict-wn vs goldendict-wordnet are slightly
different.


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

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



Bug#833383: ros-std-msgs: split headers and message definitions

2016-08-03 Thread Daniele E. Domenichelli
Source: ros-std-msgs
Severity: wishlist

It would be very useful to be able to install the message definitions without
installing the whole libstd-msgs-dev package that depends on many other
packages.
The same applies to all the other ros messages packages.



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

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



Bug#833333: Amarok crash probably due to gstreamer

2016-08-03 Thread Giovanni Mascellani
Hi.

I reported bug #83 against the Amarok package, but it is probably
due to gstreamer. So gstreamer maintainers are in Cc.

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

I found how to intercept amarok's backtrace (use "amarok --nofork"). So
that is the backtrace:

> 0x74a751c8 in __GI_raise (sig=sig@entry=6) at 
> ../sysdeps/unix/sysv/linux/raise.c:54
> 54../sysdeps/unix/sysv/linux/raise.c: File o directory non esistente.
> (gdb) bt
> #0  0x74a751c8 in __GI_raise (sig=sig@entry=6) at 
> ../sysdeps/unix/sysv/linux/raise.c:54
> #1  0x74a7664a in __GI_abort () at abort.c:89
> #2  0x71d7560b in init_context_defaults (s=s@entry=0x7ffe6c077ce0, 
> codec=codec@entry=0x726bb900 ) at 
> src/libavcodec/options.c:142
> #3  0x71d756d6 in avcodec_alloc_context3 (codec=0x726bb900 
> ) at src/libavcodec/options.c:163
> #4  0x7fff04558540 in gst_ffmpeg_cfg_install_property 
> (klass=0x7ffe6c077550, base=8) at gstavcfg.c:732
> #5  0x7fff0454ee53 in gst_ffmpegvidenc_class_init (klass=0x7ffe6c077550) 
> at gstavvidenc.c:225
> #6  0x7fffecf2722d in g_type_class_ref (pclass=0x7ffe6c077220, 
> node=0x7ffe6c076f40) at 
> /build/glib2.0-vjfO_h/glib2.0-2.48.1/./gobject/gtype.c:2241
> #7  0x7fffecf2722d in g_type_class_ref (type=type@entry=140730710847296) 
> at /build/glib2.0-vjfO_h/glib2.0-2.48.1/./gobject/gtype.c:2956
> #8  0x7fffdf246da4 in gst_element_register (plugin=plugin@entry=0xbe1160 
> [GstPlugin], name=name@entry=0x7ffe6c06eeb0 "avenc_h264_vaapi", 
> rank=rank@entry=128, type=type@entry=140730710847296) at 
> gstelementfactory.c:243
> #9  0x7fff0454f5b3 in gst_ffmpegvidenc_register 
> (plugin=plugin@entry=0xbe1160 [GstPlugin]) at gstavvidenc.c:1009
> #10 0x7fff04541e20 in plugin_init (plugin=0xbe1160 [GstPlugin]) at 
> gstav.c:158
> #11 0x7fffdf268537 in gst_plugin_register_func (plugin=0xbe1160 
> [GstPlugin], desc=0x7fff04770180 , user_data=0x0) at 
> gstplugin.c:523
> #12 0x7fffdf26a425 in _priv_gst_plugin_load_file_for_registry 
> (filename=0xbe4d00 "/usr/lib/x86_64-linux-gnu/gstreamer-1.0/libgstlibav.so", 
> registry=0x92b2b0 [GstRegistry], registry@entry=0x0, 
> error=error@entry=0x7fff04f71800)
> at gstplugin.c:826
> #13 0x7fffdf26acea in gst_plugin_load_file (filename=, 
> error=error@entry=0x7fff04f71800) at gstplugin.c:680
> #14 0x7fffdf26b12c in gst_plugin_load_by_name (name=0xbe378a "libav") at 
> gstplugin.c:1265
> #15 0x7fffdf26ba8d in gst_plugin_feature_load 
> (feature=feature@entry=0xc0b360 [GstTypeFindFactory]) at 
> gstpluginfeature.c:111
> #16 0x7fffdf2917e3 in gst_type_find_factory_call_function 
> (factory=0xc0b360 [GstTypeFindFactory], find=0x7fff04f718e0) at 
> gsttypefindfactory.c:210
> #17 0x7fffdf55e0c9 in gst_type_find_helper_get_range 
> (obj=obj@entry=0xd7eec0 [GstID3Demux], parent=parent@entry=0x0, 
> func=func@entry=0x7fffdad05600 , size= out>, extension=extension@entry=0x0, prob=prob@entry=0x7fff04f719ac) at 
> gsttypefindhelper.c:355
> #18 0x7fffdad02cc8 in gst_tag_demux_element_find (demux=0xd7eec0 
> [GstID3Demux]) at gsttagdemux.c:1364
> #19 0x7fffdad03d8d in gst_tag_demux_element_loop (demux=0xd7eec0 
> [GstID3Demux]) at gsttagdemux.c:1437
> #20 0x7fffdf28ce71 in gst_task_func (task=0x92d950 [GstTask]) at 
> gsttask.c:332
> #21 0x7fffed8b855e in g_thread_pool_thread_proxy (data=) 
> at /build/glib2.0-vjfO_h/glib2.0-2.48.1/./glib/gthreadpool.c:307
> #22 0x7fffed8b7bc5 in g_thread_proxy (data=0x7ffe740fcde0) at 
> /build/glib2.0-vjfO_h/glib2.0-2.48.1/./glib/gthread.c:780
> #23 0x736d0464 in start_thread (arg=0x7fff04f72700) at 
> pthread_create.c:333
> #24 0x74b2930d in clone () at 
> ../sysdeps/unix/sysv/linux/x86_64/clone.S:109

Which seems to indicate that the bug is in gstreamer1.0-libav. And
actually upgrading that package to the experimental version (1.9.1-1)
fixes the bug. So I leave it to the GStreamer maintainers to decide what
to do with the bug (if 1.9.1-1 is planned to migrate to unstable and
testing soon, there is no need to fix 1.8.2-1; if not, probably it is a
good idea to do that).

Thanks, Giovanni.
-- 
Giovanni Mascellani 
PhD Student - Scuola Normale Superiore, Pisa, Italy

http://poisson.phc.unipi.it/~mascellani



signature.asc
Description: OpenPGP digital signature


Bug#833382: twistd does not properly daemonize

2016-08-03 Thread Evgeni Golov
Package: python3-twisted
Version: 16.3.0-1
Severity: normal
Tags: patch upstream

Running "twistd3 web" will block, not daemonize and not start the twistd 
webserver.
Running with -n works fine.

See https://twistedmatrix.com/trac/ticket/8155
Patch:
--- /usr/lib/python3/dist-packages/twisted/scripts/_twistd_unix.py  
2016-08-03 19:28:30.933976876 +0200
+++ /tmp/_twistd_unix.py2016-08-03 19:28:10.889758303 +0200
@@ -217,7 +217,7 @@
 else:
 statusPipe = self.config.get("statusPipe", None)
 if statusPipe is not None:
-untilConcludes(os.write, statusPipe, "0")
+untilConcludes(os.write, statusPipe, b"0")
 untilConcludes(os.close, statusPipe)
 self.startReactor(None, self.oldstdout, self.oldstderr)
 self.removePID(self.config['pidfile'])
@@ -341,7 +341,7 @@
 @rtype: C{int}
 """
 data = untilConcludes(os.read, readPipe, 100)
-if data != "0":
+if data != b"0":
 msg = ("An error has occurred: '%s'\nPlease look at log "
"file for more information.\n" % (data[2:],))
 untilConcludes(sys.__stderr__.write, msg)


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

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

Versions of packages python3-twisted depends on:
ii  python3-openssl   16.0.0-2
ii  python3-service-identity  16.0.0-2
ii  python3-zope.interface4.2.0-1
pn  python3:any   

Versions of packages python3-twisted recommends:
pn  python3-pam 
ii  python3-serial  3.1-2

Versions of packages python3-twisted suggests:
pn  python3-glade2
pn  python3-gtk2  
pn  python3-qt4   
ii  python3-tk3.5.1-1
pn  python3-wxgtk2.8  

-- no debconf information

-- debsums errors found:
debsums: changed file 
/usr/lib/python3/dist-packages/twisted/scripts/_twistd_unix.py (from 
python3-twisted package)



Bug#833319: adwaita-icon-theme: Please package debian-swirl icon

2016-08-03 Thread Dmitry Shachnev
Hi Jeremy,

On Tue, Aug 02, 2016 at 10:08:59PM -0400, Jeremy Bicha wrote:
> With the other issue I mentioned, how about a MBF to try to remove
> gnome-icon-theme-symbolic (only 6 rdepends) and gnome-icon-theme (over
> 50 rdepends)?

I would support that effort, but it is worth noting that adwaita-icon-theme
does not contain some icons which were present in gnome-icon-theme (mostly
non-standard aliases, like gtk-execute which is used by many packages).

-- 
Dmitry Shachnev


signature.asc
Description: PGP signature


Bug#833381: "'ProcessLookupError' object is not subscriptable" when trying to handle stale PID file

2016-08-03 Thread Evgeni Golov
Package: python3-twisted
Version: 16.3.0-1
Severity: normal
Tags: patch upstream

Stale pid files confuse twistd:

evgeni@nana ~ % echo 123 > twistd.pid  
evgeni@nana ~ % twistd web 
Removing stale pidfile /home/evgeni/twistd.pid

evgeni@nana ~ % echo 123 > twistd.pid  
evgeni@nana ~ % twistd3 web
Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/twisted/scripts/_twistd_unix.py", line 
90, in checkPID
os.kill(pid, 0)
ProcessLookupError: [Errno 3] No such process

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/usr/bin/twistd3", line 18, in 
run()
  File "/usr/lib/python3/dist-packages/twisted/scripts/twistd.py", line 29, in 
run
app.run(runApp, ServerOptions)
  File "/usr/lib/python3/dist-packages/twisted/application/app.py", line 643, 
in run
runApp(config)
  File "/usr/lib/python3/dist-packages/twisted/scripts/twistd.py", line 25, in 
runApp
_SomeApplicationRunner(config).run()
  File "/usr/lib/python3/dist-packages/twisted/application/app.py", line 373, 
in run
self.preApplication()
  File "/usr/lib/python3/dist-packages/twisted/scripts/_twistd_unix.py", line 
193, in preApplication
checkPID(self.config['pidfile'])
  File "/usr/lib/python3/dist-packages/twisted/scripts/_twistd_unix.py", line 
92, in checkPID
if why[0] == errno.ESRCH:
TypeError: 'ProcessLookupError' object is not subscriptable

(twistd is running python2, twistd3 python3)

As per https://twistedmatrix.com/trac/ticket/8155 this needs a trivial change 
in _twistd_unix.py:
- if why[0] == errno.ESRCH:
+ if why.args[0] = errno.ESRCH:

Greets
Evgeni

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

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

Versions of packages python3-twisted depends on:
ii  python3-openssl   16.0.0-2
ii  python3-service-identity  16.0.0-2
ii  python3-zope.interface4.2.0-1
pn  python3:any   

Versions of packages python3-twisted recommends:
pn  python3-pam 
ii  python3-serial  3.1-2

Versions of packages python3-twisted suggests:
pn  python3-glade2
pn  python3-gtk2  
pn  python3-qt4   
ii  python3-tk3.5.1-1
pn  python3-wxgtk2.8  

-- no debconf information



Bug#833378: Info received (Bug#833378: Acknowledgement (keyboard-configuration: config script fails (syntax error)))

2016-08-03 Thread Dominik George
Control: tag -1 - moreinfo
Control: severity -1 serious
Justification: Policy 10.4

Actually, the script is the culprit.

Line 34618is:

layout="${keymap%(*}"

The ( needs to be quoted or escaped, as dictated by http://pubs.opengroup.org/
onlinepubs/009604499/utilities/xcu_chap02.html#tag_02_13_01 . Thus, mksh is 
right with casting a syntax error, and bash and dash are just too lazy to do.

-nik

-- 
PGP-Fingerprint: 3C9D 54A4 7575 C026 FB17  FD26 B79A 3C16 A0C4 F296

Dominik George · Mobil: +49-1520-1981389

Teckids e.V. · FrOSCon e.V. · OpenRheinRuhr e.V.
Fellowship of the FSFE · Piratenpartei Deutschland
Opencaching Deutschland e.V. · Debian Contributor

LPIC-3 Linux Enterprise Professional (Security)



Bug#833308: libwebkitgtk-doc: Please bump breaks/replaces

2016-08-03 Thread Alberto Garcia
Control: tags -1 pending

On Tue, Aug 02, 2016 at 02:50:15PM -0400, Jeremy Bicha wrote:

> Patch attached.

Thanks, applied.

Berto



Bug#833377: release.debian.org: boost1.61 transition

2016-08-03 Thread Emilio Pozuelo Monfort
Control: forwarded -1 https://release.debian.org/transitions/html/boost1.61.html

Hi Dimitri,

On 03/08/16 18:02, Dimitri John Ledkov wrote:
> Package: release.debian.org
> Severity: normal
> 
> Hello,
> 
> pkg-boost team would like to transition to the next boost abi, based on
> 1.61 release.
> 
> boost1.61 is now in experimental.
> 
> The abi is complex and depends on multiple things. We do not wish to
> maintain same boost series (1.61) with multiple abi builds. Due to fixes
> to the c++11 inline namespace abi tags in gcc-6 (as compared to gcc-5)
> the ABI of boost-regexp changes when compiled with gcc-6.

Hmm, can you clarify this? I wasn't aware that rebuilding with g++-6 caused ABI
changes. Do you know if this affects other libraries? Surely we can workaround
it in boost by doing the 1.61 transition at the same time, but what about other
libraries?

> Therefore we
> would like to only support boost1.61 abi, when compiled with gcc-6. This
> makes transation to boost1.61 depend on on g++-6 being the default.

Understandable.

> There is icu 57.1 staged in experimental. This transtion is large as
> well, and we would like to lead transtion to icu 57.1 with
> boost1.61. Therefore boost1.61 build-depends on icu 57 or higher.

Is there a need to tangle these? Can't we do GCC 6 + boost1.61 first, then do
icu later? What is the benefit of doing them together, apart from saving a few
cycles in the buildds? Is icu also affected by the ABI break when rebuilt with
g++-6 ?

> Please let me know if you are happy to transition to
> boost1.61(gcc-6,icu57), and let me know when we can coordinate the lot.

Have you done any test rebuilds against boost1.61 (with GCC 6)?

Once all the above is clear, I think we are ready to start anytime now.

> A boost tracker similar to the past boost trackers would be useful, once
> the transtion starts.

See https://release.debian.org/transitions/html/boost1.61.html (will appear in
20 minutes).

Cheers,
Emilio



Bug#833380: roaraudio: please make the build reproducible

2016-08-03 Thread Chris Lamb
Source: roaraudio
Version: 1.0~beta11-7
Severity: wishlist
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: environment
X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org

Hi,

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

It also affects anything that uses libroar-dev, eg. roarplaylistd.

Patch attached.

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


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-
--- a/debian/patches/06-reproducible-build.diff 1969-12-31 19:00:00.0 
-0500
--- b/debian/patches/06-reproducible-build.diff 2016-08-03 12:59:22.903192842 
-0400
@@ -0,0 +1,56 @@
+Description: Make the build reproducible
+Author: Chris Lamb 
+Last-Update: 2016-08-03
+
+--- roaraudio-1.0~beta11.orig/build-system/configure.tests
 roaraudio-1.0~beta11/build-system/configure.tests
+@@ -52,7 +52,12 @@ test_pkgversion() {
+ 
+ test_buildstamp() {
+  echo -n "checking for build stamp of this package... "
+- BUILD_STAMP="`date -u +'%F %X'` (`id -un`@`uname -n`)"
++ if [ "$SOURCE_DATE_EPOCH" != '' ]
++ then
++  BUILD_STAMP="`LC_ALL=C date -u -d @$SOURCE_DATE_EPOCH +'%F %X'`"
++ else
++  BUILD_STAMP="`date -u +'%F %X'` (`id -un`@`uname -n`)"
++ fi
+  echo "$BUILD_STAMP"
+  return 0
+ }
+--- roaraudio-1.0~beta11.orig/build-system/configure.lib
 roaraudio-1.0~beta11/build-system/configure.lib
+@@ -549,8 +549,14 @@ write_header_configlog() {
+  */
+ 
+ EOF
+-  echo '/* uname: ' $(uname -a) '*/'
+-  echo '/* Date : ' $(date)  '*/'
++  if [ "$SOURCE_DATE_EPOCH" != '' ]
++  then
++echo '/* uname:  - */'
++echo '/* Date : ' $(LC_ALL=C date --utc --date="@$SOURCE_DATE_EPOCH")  
'*/'
++  else
++echo '/* Date : ' $(uname -a) '*/'
++echo '/* Date : ' $(date)  '*/'
++  fi
+   echo
+ 
+   echo
+@@ -588,8 +594,14 @@ write_header_configh() {
+   echo "#define $1"
+   echo
+   echo '#ifdef __RABS_COMMENT__'
+-  echo '/* uname: ' $(uname -a) '*/'
+-  echo '/* Date : ' $(date)  '*/'
++  if [ "$SOURCE_DATE_EPOCH" != '' ]
++  then
++echo '/* uname:  - */'
++echo '/* Date : ' $(LC_ALL=C date --utc --date="@$SOURCE_DATE_EPOCH")  
'*/'
++  else
++echo '/* uname: ' $(uname -a) '*/'
++echo '/* Date : ' $(date)  '*/'
++  fi
+   echo '#endif'
+   echo
+  } >&3
--- a/debian/patches/series 2016-08-03 12:16:18.832908598 -0400
--- b/debian/patches/series 2016-08-03 12:24:38.629266072 -0400
@@ -3,3 +3,4 @@
 03-manpage-spelling-errors.diff
 04-more-spelling-errors.diff
 05-more-more-spelling-errors.diff
+06-reproducible-build.diff


Bug#833379: hardinfo: please make the build reproducible

2016-08-03 Thread Chris Lamb
Source: hardinfo
Version: 0.5.1-1.5
Severity: wishlist
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: environment
X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org

Hi,

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

Patch attached.

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


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-
--- a/configure 2016-08-03 12:09:24.359183765 -0400
--- b/configure 2016-08-03 12:13:50.725579223 -0400
@@ -186,9 +186,15 @@
 echo "#define $ARCH" >> config.h
 echo "#define ARCH \"$ARCH\"" >> config.h
 
-echo "#define PLATFORM \"`uname`\"" >> config.h
-echo "#define KERNEL   \"`uname -r`\"" >> config.h
-echo "#define HOSTNAME \"`hostname`\"" >> config.h
+if [ "$SOURCE_DATE_EPOCH" = "" ]; then
+   echo "#define PLATFORM \"`uname`\"" >> config.h
+   echo "#define KERNEL   \"`uname -r`\"" >> config.h
+   echo "#define HOSTNAME \"`hostname`\"" >> config.h
+else
+   echo "#define PLATFORM \"-\"" >> config.h
+   echo "#define KERNEL   \"-\"" >> config.h
+   echo "#define HOSTNAME \"-\"" >> config.h
+fi
 
 echo "#define PREFIX \"/usr/share/hardinfo/\"" >> config.h
 echo "#define LIBPREFIX \"/usr/lib/hardinfo/\"" >> config.h


Bug#833378: Acknowledgement (keyboard-configuration: config script fails (syntax error))

2016-08-03 Thread Dominik George
Control: tag -1 + moreinfo
Control: severity -1 normal

Apparently, this only happens with mksh. While mksh states it is policy 10.4 
compliant, this does seem to be a bug in mksh.

Lowering severity to not block migration, will probably reassign later.



Bug#802380: epiphany-browser: System crashes when visiting reuters.com URL (GPU crash?)

2016-08-03 Thread Alberto Garcia
On Mon, Oct 19, 2015 at 12:45:30PM -0700, David Glover-Aoki wrote:

> When visiting the following URL in Epiphany/Web:
> http://www.reuters.com/article/2015/10/18/us-new-york-flightcenter-
> idUSKCN0SC14B20151018
> 
> The entire screen turns black, then red, then finally is covered in garbage
> random red pixels. It looks very much like a GPU crash. At this point the
> system is hung and must be rebooted.

We believe that this is fixed in WebKitGTK 2.13.4, currently available
in Debian experimental.

Can you try that version and confirm that it solves your problem?

Thanks!

Berto



Bug#832456: elfutils: improve handling of DEB_BUILD_OPTIONS=nocheck

2016-08-03 Thread Mark Wielaard
Hi,

On Wed, 2016-07-27 at 18:16 +0200, Helmut Grohne wrote:
> > I'm wondering if I should just disable the biarch tests on all
> > arches and remove the gcc-multilib Depends completly.
> 
> I won't disagree with that.
> 
> Personally, I'd like to see biarch/multilib to die as soon as possible.
> Unfortunately, it looks like we'll have to support it for quite some
> time yet. Still we don't have to add it for new architectures (like
> ppc64el).

As upstream hacker I would like to see the native/biarch tests been run
if at all possible. They do show if we do the right thing when a 64-bit
process uses elfutils to inspect a 32-bit process running on the system.
If we get that wrong I do like to know about it. But some of the
native/biarch tests are a little fragile (failures can occur not just
for the cross 32/64 word issue, but also because of ptrace/proc,
eh_frame issues, symbol table completeness, etc.) So if there is
anything we can do to make these tests easier/simpler/better please let
us/upstream know.

Cheers,

Mark



Bug#833320: RFS: nbconvert/4.2.0-1 (ITP -- to experimental!)

2016-08-03 Thread Gianfranco Costamagna
Hi,

>That's not surprising : the bot takes the ipython in unstable and not the one 
>in experimental! Notice that the dep on ipython is indirect, so 

>I don't know which package needs a versioned dep :-/



I would wild guess:
reverse-depends -r experimental -b ipython
Reverse-Build-Depends-Indep
===
* nova

Reverse-Build-Depends
=
* jupyter-client
* jupyter-core

locutus@Unimatrix04-Xenial:/tmp $ reverse-depends -r experimental  ipython
Reverse-Depends
===
* python-caffe-cpu [s390x]
* python-ipykernel

Packages without architectures listed are reverse-dependencies in: amd64, 
arm64, armel, armhf, hurd-i386, i386, kfreebsd-amd64, kfreebsd-i386, mips, 
mips64el, mipsel, powerpc, ppc64el, s390x


so, ipykernel seems a good candidate.

what do you think about? you might enforce a version in setup.py
"'ipython>=4.0.0',"
and let the magic do the other stuff.

what do you think about?

G.



Bug#833378: keyboard-configuration: config script fails (syntax error)

2016-08-03 Thread Dominik George
Package: keyboard-configuration
Version: 1.148
Severity: grave
Justification: renders package unusable

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

/var/lib/dpkg/info/keyboard-configuration.config[35572]: no closing quote

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

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

Versions of packages keyboard-configuration depends on:
ii  debconf 1.5.59
ii  liblocale-gettext-perl  1.07-3

keyboard-configuration recommends no packages.

keyboard-configuration suggests no packages.

Versions of packages console-setup depends on:
iu  console-setup-linux  1.148
ii  debconf  1.5.59
ii  xkb-data 2.17-1

Versions of packages console-setup suggests:
ii  locales2.23-4
ii  locales-all [locales]  2.23-4
ii  lsb-base   9.20160629

Versions of packages console-setup-linux depends on:
ii  init-system-helpers  1.42
ii  initscripts  2.88dsf-59.8
ii  kbd  2.0.3-2

Versions of packages console-setup-linux suggests:
iu  console-setup  1.148

Versions of packages keyboard-configuration is related to:
pn  console-common
pn  console-data  
pn  console-tools 
pn  gnome-control-center  
ii  kbd   2.0.3-2
ii  systemd   231-1

- -- debconf information:
* keyboard-configuration/layout: English (USA)
  console-setup/codeset47: # Latin1 and Latin5 - western Europe and Turkic 
languages
* keyboard-configuration/variantcode:
* keyboard-configuration/toggle: No toggling
  console-setup/guess_font:
  console-setup/fontsize-fb47: 8x16
* keyboard-configuration/compose: Right Alt (AltGr)
  console-setup/framebuffer_only:
  console-setup/fontsize: 8x16
* keyboard-configuration/xkb-keymap: us
* keyboard-configuration/altgr: The default for the keyboard layout
  keyboard-configuration/unsupported_config_layout: true
  console-setup/store_defaults_in_debconf_db: false
* keyboard-configuration/other:
  console-setup/use_system_font:
* keyboard-configuration/model: Generische PC-Tastatur mit 105 Tasten (Intl)
  console-setup/fontface47: Fixed
* keyboard-configuration/optionscode: compose:ralt,terminate:ctrl_alt_bksp
* keyboard-configuration/layoutcode: us
  keyboard-configuration/unsupported_layout: true
* keyboard-configuration/variant: English (USA)
* keyboard-configuration/store_defaults_in_debconf_db: true
  console-setup/codesetcode: Lat15
  keyboard-configuration/unsupported_config_options: true
* keyboard-configuration/modelcode: pc105
  console-setup/fontsize-text47: 8x16
* keyboard-configuration/switch: No temporary switch
  keyboard-configuration/unsupported_options: true
  console-setup/charmap47: UTF-8
  debian-installer/console-setup-udeb/title:
* keyboard-configuration/ctrl_alt_bksp: true

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQJOBAEBCAA4BQJXoiHdMRpodHRwczovL3d3dy5kb21pbmlrLWdlb3JnZS5kZS9n
cGctcG9saWN5LnR4dC5hc2MACgkQt5o8FqDE8pY/9RAA01qDdab9mjBlBHMlBO5w
Sq6PV5PqKlzzHtPFglXfUakWCQGiAqJGmtTUJCBhGMsVXYpeq6BsLCT9O0DZX/3t
dUh+t6jpDPirH35Es+kGUDdEkx+nFfkIY1Hi8y77VkON0iZ4fpO1bVqlPQ+65PDs
P4dpO9k50xHwQchgHz03VAM++z8CyYaBRvc50iLhxZWdMO/6Qllnq2R0h8FpUBIr
4q0HpE5/omkCuGcPUS8tRrWBuX0lXoYBa4ZwpGKINwd7w5qGU3zaZXCTvdnHABmm
aiTNM3PGyReZmQRcP1A2l5zPF7tSw2xOUrysYTGgfWkdWOxNT5ES9YzFIF1JuQvj
aFIa0BtZFjIIr76U4wuWpC9UlgSe7cVfNoSx7MX81DDiNpryAxbcG8J9bFUXNMka
HH1HYJGnyO7HBm+ok2azkB44iBp6L5VZONmT2oXPld01PKB63kU2CnQV7xrikSrp
v3uLG+OVbAKEdc58JkjVa0sOY8zYgnbwaBapL+QEYvV1MocvBEDlyFH4p2V8/5RV
Gz9di3SMeozmYMCFWM9hUE9TP5WHVYs+as7fjT+9q81JrW6JRveKZsHJGh2Jusk3
ushy7hNXm5TYl+KD82E2HneMimuU3CHm2l2FUewsm+ZxwT6QgzLHTTqptAXfncLn
Dum8G1gUxsWW3wU7iqDpzc0=
=V6UX
-END PGP SIGNATURE-



Bug#833189: redis-server: Update via apt or dpkg hangs

2016-08-03 Thread Chris Lamb
> Sounds like a systemd bug - systemctl should have some way of handling
> a potentially non-responsive server

We have no way of telling the difference between a "non-responsive
server" and a Redis instance that is writing its state to disk. This
is how Redis shuts down by design.

This also applies to sysvinit, it makes zero difference which init
system you are using from this point of view.

> Anyhow, the kill allowed the purge to complete

Well, sure, but now we don't know the real reason why it was hanging 
for you. I would have liked to have seen the strace of the redis-server
process as that would have actually told us what it was doing, but
now you have killed it we will never know. :(


Regards,

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



Bug#833189: redis-server: Update via apt or dpkg hangs

2016-08-03 Thread Chris Lamb
> Sounds like a systemd bug - systemctl should have some way of handling
> a potentially non-responsive server

We have no way of telling the difference between a "non-responsive
server" and a Redis instance that is writing its state to disk. This
is how Redis shuts down by design.

This also applies to sysvinit, it makes zero difference which init
system you are using from this point of view.

> Anyhow, the kill allowed the purge to complete

Well, sure, but now we don't know the real reason why it was hanging 
for you. I would have liked to have seen the strace of the redis-server
process as that would have actually told us what it was doing, but
now you have killed it we will never know. :(


Regards,

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



  1   2   3   >