date:20140818

Package: presage
Version: 0.8.9-1
Severity: important
Tags: patch sid jessie
User: freewx-ma...@lists.alioth.debian.org
Usertags: wxpy3.0
Control: block 755757 by -1

We're aiming to migrate the archive to using wxpython3.0 instead of
wxwidgets2.8, and hope to drop wxwidgets2.8 before jessie is released.

I've rebuilt presage with the attached patch.  The required change
suppresses WXDEBUG assertions, which happened by default with wx2.8.
I've also updated a couple of constant names - wxPython 3.0 still
provides the old names, but they're gone in the C++ API, so they're
likely to disappear from wxPython in the next release.

Both changes should be compatible with wxPython 2.8.

I've tested the pyprompter app with these changes, and it seems to
work correctly.

I'm happy to NMU these changes.

Cheers,
Olly
diff -Nru presage-0.8.9/debian/changelog presage-0.8.9/debian/changelog
--- presage-0.8.9/debian/changelog	2013-10-03 10:28:47.0 +1300
+++ presage-0.8.9/debian/changelog	2014-08-18 19:09:09.0 +1200
@@ -1,3 +1,10 @@
+presage (0.8.9-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Update to depend on python-wxgtk3.0.
+
+ -- Olly Betts o...@survex.com  Mon, 18 Aug 2014 18:54:57 +1200
+
 presage (0.8.9-1) unstable; urgency=low
 
   * New upstream release.
diff -Nru presage-0.8.9/debian/control presage-0.8.9/debian/control
--- presage-0.8.9/debian/control	2013-10-03 10:28:47.0 +1300
+++ presage-0.8.9/debian/control	2014-08-18 18:54:41.0 +1200
@@ -14,7 +14,7 @@
  swig2.0 (= 2.0.4),
  libgtk2.0-dev (= 2.12),
  python-dbus,
- python-wxgtk2.8
+ python-wxgtk3.0
 Build-Depends-Indep: doxygen, graphviz
 Standards-Version: 3.9.4
 Homepage: http://presage.sourceforge.net/
@@ -178,7 +178,7 @@
 Depends: ${python:Depends},
  ${misc:Depends},
  python-presage (= ${source:Version}),
- python-wxgtk2.8 (= 2.8.7)
+ python-wxgtk3.0
 Description: intelligent predictive wxPython text editor
  This package contains the wxPython predictive text editor pyprompter.
  .

Bug#758481: collectd: FTBFS with clang-ftbfs.diff

2014-08-18 Thread Florian Forster

FYI, this patch was merged upstream:
https://github.com/collectd/collectd/commit/0afea60611f115a28b8ec331aba610e3038c1ef2

Thanks Arthur!
—octo
-- 
collectd – The system statistics collection daemon
Website: http://collectd.org
Google+: http://collectd.org/+
GitHub:  https://github.com/collectd
Twitter: http://twitter.com/collectd


signature.asc
Description: Digital signature

Bug#751277: python-biopython: FTBFS on mips* powerpc s390x

2014-08-18 Thread Andreas Tille

Hi porters,

could you please be so kind to check this issue?  It would be great to
find out why the test suite of biopython fails on these architectures.

Thanks a lot

   Andreas.

On Mon, Aug 18, 2014 at 12:35:53AM -0700, Michiel de Hoon wrote:
 Hi Andreas,
 
 Without access to powerpc, I have no way to test the code.
 Can you try recompiling Biopython and checking what exactly happens inside 
 the distance_converter function in Bio/Cluster/clustermodule.c ?
 For example, I am really wondering what strlen(data) inside this function 
 returns on powerpc.
 
 Best,
 -Michiel.
 
 
 On Sat, 8/16/14, Andreas Tille andr...@an3as.eu wrote:
 
  Subject: Re: Bug#751277: python-biopython: FTBFS on mips* powerpc s390x
  To: Peter Cock p.j.a.c...@googlemail.com
  Cc: Dejan Latinovic dejan.latino...@imgtec.com, Michiel de Hoon 
 mjldeh...@yahoo.com, Biopython discussion list 
 biopyt...@lists.open-bio.org, 751...@bugs.debian.org 
 751...@bugs.debian.org, biopython-...@biopython.org 
 biopython-...@biopython.org
  Date: Saturday, August 16, 2014, 5:37 AM
  
  Hi Peter,
  
  On Thu, Aug 14, 2014 at
  09:52:40AM +0100, Peter Cock wrote:
  
  
      1. waiting for
  your confirmation / patch
  
     2. deactivating the specific test
      3. exclude mips for
  biopython
      4. ? any
  better idea ?
   
  
   In the current state all the work we spent in biopython
  over the last
monthes will not
  migrate to testing for the simple reason that the
current package in testing just does
  not run the test suite at build
   
  time and moreover python3 is not supported.
   
Kind
  regards
   
  
        Andreas.
   
   I would suggest (2), deactivate this test
  (at least for for mips) as
   the most
  practical short term solution for the Debian packages.
   Or if you prefer (3), don't target
  mips for the Biopython package
  
  (yet).
   
   Medium
  term, I hope we can fix the C code to handle either
   Endian platform - option (1).
  
  It seems after having fixed
  the issue caused by wise we have one
  remaining problem:
  
    On powerpc[1] and s390x[2] test_Cluster
  fails even with Python 2.7 with:
  
  ==
  ERROR: test_clusterdistance
  (test_Cluster.TestCluster)
  --
  Traceback (most recent call last):
    File
  
 /«BUILDDIR»/python-biopython-1.64+dfsg/.pybuild/pythonX.Y_3.4/build/Tests/test_Cluster.py,
  line 212, in test_clusterdistance
     
  method='a', transpose=0)
  ValueError:
  method should be a single character
  
  ==
  ERROR: test_kcluster
  (test_Cluster.TestCluster)
  --
  Traceback (most recent call last):
    File
  
 /«BUILDDIR»/python-biopython-1.64+dfsg/.pybuild/pythonX.Y_3.4/build/Tests/test_Cluster.py,
  line 141, in test_kcluster
     
  method='a', dist='e')
  ValueError: method should be a single
  character
  
  ==
  ERROR: test_somcluster
  (test_Cluster.TestCluster)
  --
  Traceback (most recent call last):
    File
  
 /«BUILDDIR»/python-biopython-1.64+dfsg/.pybuild/pythonX.Y_3.4/build/Tests/test_Cluster.py,
  line 557, in test_somcluster
     
  inittau=0.02, niter=100, dist='e')
  ValueError: distance should be a single
  character
  
  ==
  ERROR: test_treecluster
  (test_Cluster.TestCluster)
  --
  Traceback (most recent call last):
    File
  
 /«BUILDDIR»/python-biopython-1.64+dfsg/.pybuild/pythonX.Y_3.4/build/Tests/test_Cluster.py,
  line 290, in test_treecluster
     
  transpose=0, method='a', dist='e')
  ValueError: method should be a single
  character
  
  --
  Ran 210 tests in 293.712 seconds
  
  FAILED (failures = 1)
  
  
  On sparc[3]
  there is a problem with dialign but sparc is no release
  architecture and wie might ignore this.  It
  might be a helpful hint
  anyway.
  
  Any hint for the test_Cluster
  problem?  If not I would also consider to
  hide it cowardly under the carpet for the
  moment.  The new package is so
  much better
  tested than the one in the testing distribution which
  does
  not even dare about any unit tests and
  only for this reason reached the
  testing
  distribution.
  
  What do you
  think?
  
  Kind regards
  
     
     Andreas.
  
  scrool these links to the end to see the
  problem:
  
  [1] 
 https://buildd.debian.org/status/fetch.php?pkg=python-biopythonarch=powerpcver=1.64%2Bdfsg-3stamp=1408116532
  [2]

Bug#757243: RFS: qmapshack/0.2.0+ds1-1

2014-08-18 Thread Tobias Frost

On Sun, 2014-08-17 at 21:11 +0200, Jaromír Mikeš wrote:

Ok, review complete.
When below things are fixed, I will upload it.

-- 
tobi

d/copyright: 
 (beside the already discussed things)
 - Files-Excluded not needed
 - Whats the copyright of the gpx examples?
 - src/cursors not documented
 
d/dirs 
  not needed, you can remove it. 

wrap-and-sort 
(please over the complete directory. Just run it from the root package
directory.) e.g d/control will look much better afterwards)

d/rules:
- please remove the last line (the commented line gunzuip ... )
- the mv is not required: You can use the -O option of wget; also
  not that get-orig-source should get the tarball and 
  leaves it in the current directory. (Policy 4.9), so the ../  
  in the mv is not right. 

d/clean + d/rules
- please clean the generated icons in e.g d/clean and rebuild them  
 during build. (there is such a nice script for doing this in the   
  src :))
  General rule: If there is a source, use it during build. 
  E.g also compass.png should be regenerated. 



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

Bug#758495: src:wxwidgets3.0: Please use mingw-w64 when cross-compiling the Windows binaries

On Mon, Aug 18, 2014 at 08:28:28AM +0200, Stephen Kitt wrote:
 I noticed you provide everything necessary to cross-compile wxwidgets
 for Windows, which is great!
 
 The instructions currently refer to mingw32, but that is now a
 transitional package since we're dropping mingw32 in favour of
 mingw-w64 for Jessie. Everything still works fine as is, but I'd
 appreciate it if you could update the instructions and debian/rules,
 replacing mingw32 with mingw-w64 and i586-mingw32msvc with
 i686-w64-mingw32.
 
 I haven't checked the consequences of enabling threads with
 mingw-w64 (as mentioned in debian/rules for mingw32). There is no
 mingwm10.dll with mingw-w64, but depending on which compiler variant
 is used (-win32 or -posix) it's likely the resulting binaries will
 have a dependency on libgcc and libwinpthread.

This support was added by Ron Lee, who's no longer active in Debian wx
maintenance.  I used to use it myself, but I no longer do.  I've not
seen any feedback for years, and had recently concluded it was probably
unused and was actually contemplating removing it.

If you're wanting to get it updated for changes in the cross toolchains,
you're probably going to need to step up and make the required changes.
I'm happy to add you to the wx team on alioth, or just send me patches
to apply.

I'm also not aware of anyone having tested it since the update from 2.8
to 3.0, so it may well not quite work currently.  I tried to make the
relevant updates to it, but my focus in wx maintenance has been in
trying to migrate packages to use wx3.0.

Cheers,
Olly


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#758172: isync: Adds . to Maildir directory names

2014-08-18 Thread Oswald Buddenhagen

https://sourceforge.net/p/isync/mailman/message/30694372/
https://sourceforge.net/p/isync/feature-requests/5/


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#731111: Bug#731132: augeas: CVE-2012-0786, CVE-2012-0787

2014-08-18 Thread Florian Ernst

Hello there,

On Mon, Dec 02, 2013 at 12:05:30PM +0100, Raphael Geissert wrote:
 [...]
 Could you please prepare the packages and coordinate with the release
 team?

On Wed, Jan 15, 2014 at 05:26:54PM +0100, Raphael Geissert wrote:
 [...]
 Could you please coordinate with the release team to fix these issues
 via O/SPU?

Both #731132 (augeas: CVE-2012-0786, CVE-2012-0787) and #73 (augeas:
CVE-2013-6412) don't show any maintainer action. These security bugs
remained untouched for several months.

Furthermore, the last maintainer upload of augeas seems to have been
over 1.5y ago, and two new upstream releases are now available (cf.
#751232).

Thus, I wonder whether augeas is still maintained ...?

Best regards,
Flo


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#708931: Disconnects ifupdown-managed eth0 during start and stop

2014-08-18 Thread Antti-Juhani Kaijanaho

Package: network-manager
Followup-For: Bug #708931

I can no longer reproduce this bug.  This is a recent change (within a month or
two).  I suspect the bug has been fixed in a recent version.


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

Kernel: Linux 3.14-2-amd64 (SMP w/2 CPU cores)
Locale: LANG=fi_FI.UTF-8, LC_CTYPE=fi_FI.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages network-manager depends on:
ii  adduser3.113+nmu3
ii  dbus   1.8.6-1
ii  init-system-helpers1.20
ii  isc-dhcp-client4.3.1-1
ii  libc6  2.19-9
ii  libdbus-1-31.8.6-1
ii  libdbus-glib-1-2   0.102-1
ii  libgcrypt111.5.4-2
ii  libglib2.0-0   2.40.0-4
ii  libgnutls-deb0-28  3.2.16-1
ii  libgudev-1.0-0 208-7
ii  libmm-glib01.2.0-1
ii  libndp01.4-1
ii  libnewt0.520.52.17-1
ii  libnl-3-2003.2.24-2
ii  libnl-genl-3-200   3.2.24-2
ii  libnl-route-3-200  3.2.24-2
ii  libnm-glib40.9.10.0-1.1
ii  libnm-util20.9.10.0-1.1
ii  libpam-systemd 208-7
ii  libpolkit-gobject-1-0  0.105-6.1
ii  libreadline6   6.3-8
ii  libsoup2.4-1   2.46.0-2
ii  libsystemd-daemon0 208-7
ii  libsystemd-login0  208-7
ii  libuuid1   2.20.1-5.8
ii  lsb-base   4.1+Debian13
ii  policykit-10.105-6.1
ii  udev   208-7
ii  wpasupplicant  1.1-1

Versions of packages network-manager recommends:
ii  crda  1.1.2-1
ii  dnsmasq-base  2.71-1
ii  iptables  1.4.21-2
ii  modemmanager  1.2.0-1
ii  ppp   2.4.6-2

Versions of packages network-manager suggests:
ii  avahi-autoipd  0.6.31-4

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

-- no debconf information


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#708931: Disconnects ifupdown-managed eth0 during start and stop

2014-08-18 Thread Antti-Juhani Kaijanaho

On Mon, Aug 18, 2014 at 11:08:01AM +0300, Antti-Juhani Kaijanaho wrote:
 Package: network-manager
 Followup-For: Bug #708931
 
 I can no longer reproduce this bug.  This is a recent change (within a month 
 or
 two).  I suspect the bug has been fixed in a recent version.

Hm, the current version was not included in this, I see.

ii  network-manager 0.9.10.0-1.1 amd64
network management framework (daemon and userspace tools)

-- 
Antti-Juhani Kaijanaho


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#738590: new upstream (2.4.1)

2014-08-18 Thread Florian Ernst

Hello there,

On Tue, Feb 11, 2014 at 12:14:58AM +0100, Daniel Baumann wrote:
 Package: mcollective
 Seerity: wishlist
 
 it would be nice if you could upgrade to the current stable release (2.4.1).

In the meantime, mcollective has progressed further, the 2.6.0 release
is pending (28/Aug/14). Any news on this? Or is there anything blocking
further updates? E.g. license problems, program restructuring, lack of
spare time ... just wondering ...

Cheers,
Flo


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#758093: [Pkg-ltsp-devel] Bug#758093: ltspfsd: quietly fails with systemd as init system

2014-08-18 Thread Petter Reinholdtsen


[Vagrant Cascadian]
 --- a/scripts/ltspfs_entry
 +++ b/scripts/ltspfs_entry
 @@ -101,14 +101,13 @@ remove_device()
  
  start_ltspfsd()
  {
 -if [ ! -e /var/run/ltspfsd.pid ]  [ -z $(pgrep ltspfsd) ]; then
 +if [ -z $(pgrep ltspfsd) ]; then
  # Make this sessions secret auth cookie for ltspfs
  if [ ! -f /var/run/ltspfs_token ]; then
  mcookie  /var/run/ltspfs_token
  fi
  # start up the ltspfsd daemon
 -/usr/bin/ltspfsd
 -echo $! /var/run/ltspfsd.pid
 +systemctl start ltspfsd || /usr/bin/ltspfsd
  fi
  }

Perhaps better to use a test like [ -d /run/systemd/system ] around the
call to systemctl to detect a running systemd, and keep using the pid
file for non-systemd environments?

-- 
Happy hacking
Petter Reinholdtsen


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#500778: NFS server on Wheezy, clients on Jessie, happens quite often

2014-08-18 Thread Di Domizio Daniele

This is happening quite often to me, also with the proposed workaround of 
Cache-Timeout = 10 (both on server and clients).
I don't have problems at boot time, but I get random user/gid 4294967294, 
especially on file creation, and they disappear without no intervention usually 
in some minutes.
The NFS server is on Debian Wheezy and clients on Debian Testing. I also have a 
Debian Wheezy NFS client that doesn't have this problem at all, so I tried 
downgrading

nslcd (to 0.8.10-4)
libnss-ldapd (to 0.8.10-4)
libpam-ldapd (to 0.8.10-4)
nfs-common (to 1.2.6-4)
libnfsidmap2 (to 0.25-4)
libnss3 (to 2:3.14.5-1)

to match the versions on Wheezy but it's not helping. I also tried the 
reconnect_invalidate nfsidmap on the latest versions of nslcd (on Debian 
Testing) and it's also not helping. I already have sec=sys enabled in the NFS 
mount options.

Thanks,
Daniele

Bug#758500: ltsp-client-builder: Unable to install LTSP from CD using udeb (Debian Edu Jessie)

2014-08-18 Thread Petter Reinholdtsen

Package: ltsp-client-builder
Version: 5.5.2-1
User: debian-...@lists.debian.org
Usertags: debian-edu

Hi.  I just tested Debian Edu based on Jessie, and selected the Thin
Client Server profile, which set up LTSP on a server.  But the
installation failed.  I used our netinst CD, and the installation
failed with these syslog messages:

  Aug 17 22:21:53 main-menu[175]: INFO: Menu item 'ltsp-client-builder' selected
  Aug 17 22:21:53 ltsp-client-builder: ltsp-build-client options: --mirror 
file:///media/cdrom --security-mirror none --updates-mirror none 
--accept-unsigned-packages
  Aug 17 22:21:53 ltsp-client-builder: Installing package 
ltsp-server-standalone in target
  Aug 17 22:21:54 in-target: Leser pakkelister...
  Aug 17 22:21:54 in-target: 
  Aug 17 22:21:54 in-target: Skaper oversikt over avhengighetsforhold...
  Aug 17 22:21:54 in-target: 
  Aug 17 22:21:54 in-target: Leser tilstandsinformasjon...
  Aug 17 22:21:54 in-target: 
  Aug 17 22:21:55 in-target: ltsp-server-standalone er allerede nyeste versjon.
  Aug 17 22:21:55 in-target: 0 oppgraderte, 0 nylig installerte, 0 å fjerne og 
0 ikke oppgradert.
  Aug 17 22:21:55 kernel: [48880.496511] ISO 9660 Extensions: Microsoft Joliet 
Level 3
  Aug 17 22:21:55 kernel: [48880.496971] ISO 9660 Extensions: RRIP_1991A
  Aug 17 22:21:55 kernel: [48880.551581] ISO 9660 Extensions: Microsoft Joliet 
Level 3
  Aug 17 22:21:55 kernel: [48880.552151] ISO 9660 Extensions: RRIP_1991A
  Aug 17 22:22:00 in-target: Detected CD install, disabling APT repository 
checking.
  Aug 17 22:22:02 in-target: I: Retrieving Release 
  Aug 17 22:22:02 in-target: E: Failed getting release file 
file:///media/cdrom/dists/jessie/Release
  Aug 17 22:22:02 in-target: error: LTSP client installation ended abnormally
  Aug 17 22:22:03 ltsp-client-builder: ERROR: ltsp-build-client failed to run
  Aug 17 22:22:03 main-menu[175]: WARNING **: Configuring 'ltsp-client-builder' 
failed with error code 1
  Aug 17 22:22:03 main-menu[175]: WARNING **: Menu item 'ltsp-client-builder' 
failed.

Perhaps this is related to the issue reported in
URL:https://bugs.debian.org/606313 ?

Any clues how to get LTSP installing from d-i in Jessie?

-- 
Happy hacking
Petter Reinholdtsen


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#750480: Fixed upstream

2014-08-18 Thread Svante Signell

tags 750480 + fixed upstream
thanks

See
https://github.com/shadow-maint/shadow/commit/4911773b7746ee86229f6a552a806b8e756b74c9


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#758501: gsmlib: FTBFS in unstable with gettext 0.19

2014-08-18 Thread Riku Voipio

Package: gsmlib
Version: 1.10+20120414.gita5e5ae9a-0.1
Severity: serious
Justification: FTBFS
User: debian-...@lists.debian.org
Usertag: arm64 

gsmlib will FTBFS due to gettext upgrade in unstable. Blocks arm64 since 
gettext 0.18
was never built on arm64, but happens also on all other architectures:

local reproduced build on i386:

make[3]: Entering directory
'/tmp/buildd/gsmlib-1.10+20120414.gita5e5ae9a/po'
*** error: gettext infrastructure mismatch: using a Makefile.in.in from
gettext version 0.18 but the autoconf macros are from gettext version
0.19

arm64 build:

https://buildd.debian.org/status/fetch.php?pkg=gsmlibarch=arm64ver=1.10%2B20120414.gita5e5ae9a-0.1stamp=1408319184


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#758482: [Pkg-postgresql-public] Bug#758482: pg-reorg: builds packages not listed in source package's debian/control

Re: Ansgar Burchardt 2014-08-18 87a972oi2m@deep-thought.43-1.org
 Source: pg-reorg
 Version: 1.1.9-2
 Severity: serious
 
 pg-reorg regenerates d/control during build and creates packages not
 listed in the source package:
 
   Source: pg-reorg (1.1.9-2)
   Binary: postgresql-9.4-reorg
 
 but postgresql-9.4-reorg is not in the .dsc's Binary field.

The problem is that the package needs porting to postgresql-9.4, but
upstream hasn't done that yet.

Until then, pg-reorg should be removed from testing.

Thanks,
Christoph
-- 
c...@df7cb.de | http://www.df7cb.de/


signature.asc
Description: Digital signature

Bug#750480: Fixed upstream

2014-08-18 Thread Svante Signell

tags 750480 + fixed-upstream
tags 750480 - fixed upstream
thanks

See
https://github.com/shadow-maint/shadow/commit/4911773b7746ee86229f6a552a806b8e756b74c9


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#758488: python3: float conversion broken on s390x

2014-08-18 Thread Matthias Klose

Control: tags -1 + help moreinfo

Am 18.08.2014 um 04:23 schrieb Philipp Kern:
 Package: python3-minimal
 Version: 3.4.1-1
 Severity: serious
 X-Debbugs-Cc: debian-s...@lists.debian.org
 
 The datetime module fails its initialization assertions on s390x with python3
 upon import:
 
 import datetime
 Traceback (most recent call last):
   File stdin, line 1, in module
   File /usr/lib/python3.4/datetime.py, line 619, in module
 microseconds=99)
   File /usr/lib/python3.4/datetime.py, line 395, in __new__
 assert abs(microseconds)  3.1e6
 AssertionError
 
 (Disregard slight shifts in the line numbers.)
 
 The actual problem is this:
 
 float(99)
 1073740750258176.0
 
 Sadly python3-minimal fails to configure because of this, which in turn lets
 other packages being upgraded fail to fully install.
 
 int to float casts are working with python2, but are completely broken with
 python3:
 
 float(1)
 1073741824.0
 float(-1)
 -1073741824.0

- does this work with python3-dbg?

- if yes, please find out which optimization, or which
  wrong code causes this, and send a patch or workaround.

the python3.4 testsuite looks good, except for some failing test_dbm tests and a
failing test_signal test.

I won't have time to handle this until late September.

  Matthias


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#597166: #597166 - gnome-user-share: please support symlinks in the ~/Public folder

2014-08-18 Thread Fabian Greffrath

Control: found -1 3.10.2-1

Am Freitag, den 08.08.2014, 22:22 +0100 schrieb Pedro Beja: 
 Could you please confirm the status of this one with newer version of
 gnome-user-share like 3.10.2-1 ?

The issue persists with recent releases, see 
https://bugzilla.gnome.org/show_bug.cgi?id=733583

- Fabian


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#758502: tracker.debian.org: Add data from duck.debian.net to action needed panel

2014-08-18 Thread Simon Kainz

Package: tracker.debian.org
Severity: wishlist
Tags: patch

Hello,

this adds support for data from duck.debian.net.

Please see the attached patch.



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

Kernel: Linux 3.2.0-4-amd64 (SMP w/8 CPU cores)
Locale: LANG=de_AT.UTF-8, LC_CTYPE=de_AT.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
From a0a3810608a306ab77eee214a9be0854e39e3367 Mon Sep 17 00:00:00 2001
From: Simon Kainz si...@familiekainz.at
Date: Mon, 18 Aug 2014 10:42:28 +0200
Subject: [PATCH 1/2]  add new template for duck extra info.

---
 .../vendor/debian/templates/debian/duck-action-item.html  | 8 
 1 file changed, 8 insertions(+)
 create mode 100644 distro_tracker/vendor/debian/templates/debian/duck-action-item.html

diff --git a/distro_tracker/vendor/debian/templates/debian/duck-action-item.html b/distro_tracker/vendor/debian/templates/debian/duck-action-item.html
new file mode 100644
index 000..851310c
--- /dev/null
+++ b/distro_tracker/vendor/debian/templates/debian/duck-action-item.html
@@ -0,0 +1,8 @@
+{% with duck = item.extra_data.duck_link %}
+{% with issues = item.extra_data.issues_link %}
+a href={{ duck }}DUCK/a reports some a href={{ issues }}issues/a concerning upstream URLs defined for this package.
+{% endwith %}
+{% endwith %}
+
+
+
-- 
2.0.1

From a0a3810608a306ab77eee214a9be0854e39e3367 Mon Sep 17 00:00:00 2001
From: Simon Kainz si...@familiekainz.at
Date: Mon, 18 Aug 2014 10:42:28 +0200
Subject: [PATCH 1/2]  add new template for duck extra info.

---
 .../vendor/debian/templates/debian/duck-action-item.html  | 8 
 1 file changed, 8 insertions(+)
 create mode 100644 distro_tracker/vendor/debian/templates/debian/duck-action-item.html

diff --git a/distro_tracker/vendor/debian/templates/debian/duck-action-item.html b/distro_tracker/vendor/debian/templates/debian/duck-action-item.html
new file mode 100644
index 000..851310c
--- /dev/null
+++ b/distro_tracker/vendor/debian/templates/debian/duck-action-item.html
@@ -0,0 +1,8 @@
+{% with duck = item.extra_data.duck_link %}
+{% with issues = item.extra_data.issues_link %}
+a href={{ duck }}DUCK/a reports some a href={{ issues }}issues/a concerning upstream URLs defined for this package.
+{% endwith %}
+{% endwith %}
+
+
+
-- 
2.0.1



duck_patches.tgz
Description: GNU Zip compressed data

Bug#758503: tinyows: Transition to postgresql-9.4

Package: tinyows
Version: 1.1.0-4
Severity: important
User: pkg-postgresql-pub...@lists.alioth.debian.org
Usertags: migration-94

Jessie will be shipping with postgresql-9.4; postgresql-9.3 will
eventually be removed.

tinyows recommends postgresql-9.3-postgis-2.1,
please upgrade this dependency.

The best fix would probably be to just Recommends: postgis. postgis
itself recommends the server module. That would avoid tracking the
PostgreSQL version in tinyows.

Christoph
-- 
c...@df7cb.de | http://www.df7cb.de/


signature.asc
Description: Digital signature

Bug#754407: nginx: error installing on 64bit jessie

2014-08-18 Thread Mattia Migliorini

Package: nginx
Version: 1.6.1-1
Followup-For: Bug #754407

nginx will not install on Debian Jessie amd64.

-- Output of apt-get install nginx:

Setting up nginx-full (1.6.1-1) ...
Job for nginx.service failed. See 'systemctl status nginx.service' and
'journalctl -xn' for details.
invoke-rc.d: initscript nginx, action start failed.
dpkg: error processing package nginx-full (--configure):
 subprocess installed post-installation script returned error exit status 1
dpkg: dependency problems prevent configuration of nginx:
 nginx depends on nginx-full (= 1.6.1-1) | nginx-light (= 1.6.1-1) |
nginx-extras (= 1.6.1-1) | nginx-naxsi (= 1.6.1-1); however:
  Package nginx-full is not configured yet.
  Package nginx-light is not installed.
  Package nginx-extras is not installed.
  Package nginx-naxsi is not installed.
 nginx depends on nginx-full ( 1.6.1-1.1~) | nginx-light ( 1.6.1-1.1~)
| nginx-extras ( 1.6.1-1.1~) | nginx-naxsi ( 1.6.1-1.1~); however:
  Package nginx-full is not configured yet.
  Package nginx-light is not installed.
  Package nginx-extras is not installed.
  Package nginx-naxsi is not installed.

dpkg: error processing package nginx (--configure):
 dependency problems - leaving unconfigured
Errors were encountered while processing:
 nginx-full
 nginx
E: Sub-process /usr/bin/dpkg returned an error code (1)

-- Output of systemctl status nginx.service:

nginx.service - A high performance web server and a reverse proxy server
   Loaded: loaded (/lib/systemd/system/nginx.service; enabled)
   Active: failed (Result: exit-code) since lun 2014-08-18 10:32:06 CEST;
1min 13s ago
  Process: 15870 ExecStart=/usr/sbin/nginx -g daemon on; master_process on;
(code=exited, status=1/FAILURE)
  Process: 15866 ExecStartPre=/usr/sbin/nginx -t -q -g daemon on;
master_process on; (code=exited, status=0/SUCCESS)

ago 18 10:32:05 kira nginx[15870]: nginx: [emerg] bind() to 0.0.0.0:80
failed (98: Address already in use)
ago 18 10:32:05 kira nginx[15870]: nginx: [emerg] bind() to [::]:80 failed
(98: Address already in use)
ago 18 10:32:05 kira nginx[15870]: nginx: [emerg] bind() to 0.0.0.0:80
failed (98: Address already in use)
ago 18 10:32:05 kira nginx[15870]: nginx: [emerg] bind() to [::]:80 failed
(98: Address already in use)
ago 18 10:32:06 kira nginx[15870]: nginx: [emerg] bind() to 0.0.0.0:80
failed (98: Address already in use)
ago 18 10:32:06 kira nginx[15870]: nginx: [emerg] bind() to [::]:80 failed
(98: Address already in use)
ago 18 10:32:06 kira nginx[15870]: nginx: [emerg] still could not bind()
ago 18 10:32:06 kira systemd[1]: nginx.service: control process exited,
code=exited status=1
ago 18 10:32:06 kira systemd[1]: Failed to start A high performance web
server and a reverse proxy server.
ago 18 10:32:06 kira systemd[1]: Unit nginx.service entered failed state.


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

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

Versions of packages nginx depends on:
ih  nginx-full  1.6.1-1

nginx recommends no packages.

nginx suggests no packages.

-- no debconf information

-- 
Mattia Migliorini

Web Designer
Website: www.deshack.net
OpenPGP key: AA3B90BC
Fingerprint: 5F30 BEB3 224E A831 1DCE  F554 7E64 2AFF AA3B 90BC

Bug#758319: bird: Please ship birdcl in package

2014-08-18 Thread Ondřej Surý

Hi Micah,

why would we need to ship birdcl together with birdc in one package?
That makes no sense since birdcl is just no-readline version of birdc.

Cheers,
Ondřej

On Sat, Aug 16, 2014, at 21:50, Micah Anderson wrote:
 Package: bird
 Version: 1.4.4-1
 Severity: wishlist
 Tags: patch
 
 Hello,
 
 It seems that you are not shipping the birdcl binary in the package. The
 attached patch would add that to the package.
 
 I'm happy to upload this as a NMU to help you.
 
 micah
 
 -- System Information:
 Debian Release: jessie/sid
   APT prefers unstable
   APT policy: (500, 'unstable')
 Architecture: amd64 (x86_64)
 Foreign Architectures: i386
 
 Kernel: Linux 3.14-2-amd64 (SMP w/4 CPU cores)
 Locale: LANG=en_US.utf8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
 Shell: /bin/sh linked to /bin/dash
 
 Versions of packages bird depends on:
 ii  adduser   3.113+nmu3
 ii  libc6 2.19-7
 ii  libreadline6  6.3-8
 ii  libtinfo5 5.9+20140712-2
 
 bird recommends no packages.
 
 Versions of packages bird suggests:
 ii  bird-doc  1.4.4-1
 Email had 1 attachment:
 + bird2.diff
   1k (text/x-diff)


-- 
Ondřej Surý ond...@sury.org
Knot DNS (https://www.knot-dns.cz/) – a high-performance DNS server


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#758498: syslog

2014-08-18 Thread Helmut Schreiber

Excerpt from the syslog-file :
Aug 18 08:39:52 Luke kernel: [   31.140927] usb 1-1: new high-speed USB device 
number 5 using xhci_hcd
Aug 18 08:39:52 Luke kernel: [   31.269919] usb 1-1: New USB device found, 
idVendor=1004, idProduct=61fc
Aug 18 08:39:52 Luke kernel: [   31.269924] usb 1-1: New USB device strings: 
Mfr=2, Product=3, SerialNumber=4
Aug 18 08:39:52 Luke kernel: [   31.269926] usb 1-1: Product: LGE P2 USB Device
Aug 18 08:39:52 Luke kernel: [   31.269928] usb 1-1: Manufacturer: LGE
Aug 18 08:39:52 Luke kernel: [   31.269930] usb 1-1: SerialNumber: 
328C000600010A3C263A0601A00E
Aug 18 08:39:52 Luke mtp-probe: checking bus 1, device 5: 
/sys/devices/pci:00/:00:14.0/usb1/1-1
Aug 18 08:39:52 Luke mtp-probe: bus: 1, device: 5 was not an MTP device
Aug 18 08:39:52 Luke kernel: [   31.299596] cdc_acm 1-1:1.0: This device cannot 
do calls on its own. It is not a modem.
Aug 18 08:39:52 Luke kernel: [   31.299647] cdc_acm 1-1:1.0: ttyACM0: USB ACM 
device
Aug 18 08:39:52 Luke kernel: [   31.300031] usbcore: registered new interface 
driver cdc_acm
Aug 18 08:39:52 Luke kernel: [   31.300034] cdc_acm: USB Abstract Control Model 
driver for USB modems and ISDN adapters
Aug 18 08:39:52 Luke kernel: [   31.300663] usb-storage 1-1:1.5: USB Mass 
Storage device detected
Aug 18 08:39:52 Luke kernel: [   31.302501] scsi5 : usb-storage 1-1:1.5
Aug 18 08:39:52 Luke kernel: [   31.302609] usbcore: registered new interface 
driver usb-storage
Aug 18 08:39:52 Luke kernel: [   31.309380] cdc_ether 1-1:1.3 usb0: register 
'cdc_ether' at usb-:00:14.0-1, CDC Ethernet Device, da:cb:e3:68:55:7b
Aug 18 08:39:52 Luke kernel: [   31.309808] usbcore: registered new interface 
driver cdc_ether
Aug 18 08:39:52 Luke NetworkManager[753]: info (usb0): carrier is OFF
Aug 18 08:39:52 Luke NetworkManager[753]: info (usb0): new Ethernet device 
(driver: 'cdc_ether' ifindex: 4)
Aug 18 08:39:52 Luke NetworkManager[753]: info (usb0): exported as 
/org/freedesktop/NetworkManager/Devices/3
Aug 18 08:39:52 Luke NetworkManager[753]: info (usb0): device state change: 
unmanaged - unavailable (reason 'managed') [10 20 2]
Aug 18 08:39:52 Luke NetworkManager[753]: info (usb0): link connected
Aug 18 08:39:52 Luke NetworkManager[753]: info (usb0): preparing device
Aug 18 08:39:52 Luke NetworkManager[753]: info devices added (path: 
/sys/devices/pci:00/:00:14.0/usb1/1-1/1-1:1.3/net/usb0, iface: usb0)
Aug 18 08:39:52 Luke NetworkManager[753]: info device added (path: 
/sys/devices/pci:00/:00:14.0/usb1/1-1/1-1:1.3/net/usb0, iface: usb0): 
no ifupdown configuration found.
Aug 18 08:39:52 Luke NetworkManager[753]: info (usb0): device state change: 
unavailable - disconnected (reason 'none') [20 30 0]
Aug 18 08:39:52 Luke NetworkManager[753]: info Auto-activating connection 
'USB Network'.
Aug 18 08:39:52 Luke NetworkManager[753]: info Activation (usb0) starting 
connection 'USB Network'
Aug 18 08:39:52 Luke NetworkManager[753]: info Activation (usb0) Stage 1 of 5 
(Device Prepare) scheduled...
Aug 18 08:39:52 Luke NetworkManager[753]: info Activation (usb0) Stage 1 of 5 
(Device Prepare) started...
Aug 18 08:39:52 Luke NetworkManager[753]: info (usb0): device state change: 
disconnected - prepare (reason 'none') [30 40 0]
Aug 18 08:39:52 Luke NetworkManager[753]: info NetworkManager state is now 
CONNECTING
Aug 18 08:39:52 Luke NetworkManager[753]: info Activation (usb0) Stage 2 of 5 
(Device Configure) scheduled...
Aug 18 08:39:52 Luke NetworkManager[753]: info Activation (usb0) Stage 1 of 5 
(Device Prepare) complete.
Aug 18 08:39:52 Luke NetworkManager[753]: info Activation (usb0) Stage 2 of 5 
(Device Configure) starting...
Aug 18 08:39:52 Luke NetworkManager[753]: info (usb0): device state change: 
prepare - config (reason 'none') [40 50 0]
Aug 18 08:39:52 Luke NetworkManager[753]: info Activation (usb0) Stage 2 of 5 
(Device Configure) successful.
Aug 18 08:39:52 Luke NetworkManager[753]: info Activation (usb0) Stage 3 of 5 
(IP Configure Start) scheduled.
Aug 18 08:39:52 Luke NetworkManager[753]: info Activation (usb0) Stage 2 of 5 
(Device Configure) complete.
Aug 18 08:39:52 Luke NetworkManager[753]: info Activation (usb0) Stage 3 of 5 
(IP Configure Start) started...
Aug 18 08:39:52 Luke NetworkManager[753]: info (usb0): device state change: 
config - ip-config (reason 'none') [50 70 0]
Aug 18 08:39:52 Luke NetworkManager[753]: info Activation (usb0) Beginning 
DHCPv4 transaction (timeout in 45 seconds)
Aug 18 08:39:52 Luke NetworkManager[753]: info dhclient started with pid 2287
Aug 18 08:39:52 Luke NetworkManager[753]: info Activation (usb0) Stage 3 of 5 
(IP Configure Start) complete.
Aug 18 08:39:52 Luke dhclient: Internet Systems Consortium DHCP Client 4.3.1
Aug 18 08:39:52 Luke dhclient: Copyright 2004-2014 Internet Systems Consortium.
Aug 18 08:39:52 Luke dhclient: All rights reserved.
Aug 18 08:39:52 Luke dhclient: For info, please visit 
https://www.isc.org/software/dhcp/
Aug 18 08:39:52 Luke

Bug#758464: [DSE-Dev] Bug#758464: selinux-policy-default: Impossible to use libvirt(d) if enforcing

2014-08-18 Thread Andreas Florath

Hello Mika,

there is also a boolean 'virt_use_execmem' which does
a similar thing (allow execmem and execstack) but in a different
domain: setting this to on does also not change the things.

The attached patched solves the problem for me.
I'm not sure why the 'execstack' was not included in the appropriate rule
- execmem is already.
And also I'm not sure if this can be a general way to fix this:
I have not enough knowledge about libvirtd.

Nevertheless:
when applying the patch to the selinux-policy-default and installing
the new version, two more errors pop up:

Aug 18 10:31:22 nestor libvirtd[866]: An SELinux policy prevents this sender 
from sending this message to this recipient, 0 matched rules; 
type=method_call, sender=:1.4 (uid=0 pid=866 comm=/usr/sbin/libvirtd ) 
interface=org.freedesktop.login1.Manager member=CanSuspend error 
name=(unset) requested_reply=0 destination=org.freedesktop.login1 (uid=0 
pid=672 comm=/lib/systemd/systemd-logind )
Aug 18 10:31:22 nestor libvirtd[866]: Failed to get host power management 
capabilities
Aug 18 10:31:22 nestor libvirtd[866]: Unable to open /dev/net/tun, is tun 
module loaded?: No such file or directory

The first one is IMHO a minor problem (it's not nice, but it should run without 
this info).
The second one prevents VMs to be started (therefore it's IMHO an important 
one).

Should I create two new bug reports for these things? (This would IMHO be
better than discussing some problems in the same thread.)

Kind regards

Andre

===


diff --git a/policy/modules/contrib/virt.te b/policy/modules/contrib/virt.te
index cb868d5..e1a36fb 100644
--- a/policy/modules/contrib/virt.te
+++ b/policy/modules/contrib/virt.te
@@ -412,7 +412,7 @@ corenet_tcp_connect_all_ports(svirt_t)
 #

 allow virtd_t self:capability { chown dac_override fowner ipc_lock kill mknod 
net_admin net_raw setpcap setuid setgid sys_admin sys_nice };
-allow virtd_t self:process { getcap getsched setcap sigkill signal signull 
execmem setexec setfscreate setsockcreate setsched };
+allow virtd_t self:process { getcap getsched setcap sigkill signal signull 
execmem execstack setexec setfscreate setsockcreate setsched };
 allow virtd_t self:fifo_file { manage_fifo_file_perms relabelfrom relabelto };
 allow virtd_t self:unix_stream_socket { accept connectto listen relabelfrom 
relabelto };
 allow virtd_t self:tcp_socket { accept listen };


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#757645: Rationale for the change

2014-08-18 Thread Yuri D'Elia

On 08/18/2014 08:22 AM, Gianfranco Costamagna wrote:
 Since also my first sponsor got some troubles in running them (if you
 choose pyside without having it installed you will likely have a
 import error and in some cases a segfault, IIRC), and since I'm a
 person that _really_ likes to install and run things, rather than
 install, run/fail/run/fail/check_faults/change_library, I choose to
 go for having them both required.

IMHO it's perfectly reasonable that if you can select the binding
engine, and the selected one is missing, the example fails.

The idea of the example is not to let people swap engines at runtime,
but to make the example run at all.

You could detect at runtime which binding is available and gray out
the selection if you really wanted to. This would fix the issue
permanently.

 In my opinion A is the best solution (didn't come in my mind when I
 firstly thought about this problem), but I really would like to hear
 some feedbacks ;)

I would go for a

Depends: pyside|pyqt

recommending pyside as the favorable option, since pyqt with python 2.7
has still the old SIP api enabled by default (and changing it is a
PITA). I would recommend newcomers to use pyside if possible, even just
for the API. Most developers already have a clear idea of which binding
to use.

I would agree with upstream here to ship with the documentation. I'm
working often offline, and I've reported many bug reports trying to ship
docs along with the packages and to always Suggest: the -doc package if
it exists.

I personally wouldn't put examples into a different package, but ship
them with the documentation. Unless the examples come with extra
unreasonable dependencies. In this case, the -doc can recommend *both*
pyqt and pyside (that is, with 2 recommends), without affecting the main
package and without requiring an extra one.

I feel that a reccomends would be too strong anyway, as one of the goals
of pyqtgraph is really to be interchangeable between the two. As far as
an example is concerned, if it runs with the installed engine, what's
the point really?

 BTW I'm a quite old DM, but I'm not in the dm.txt list for this
 package, so would be nice to have a sponsor for the change ;).

Cannot help you here, I also need sponsors ;)


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#758482: [Pkg-postgresql-public] Bug#758482: pg-reorg: builds packages not listed in source package's debian/control

On 08/18/2014 10:36, Christoph Berg wrote:
 Re: Ansgar Burchardt 2014-08-18 87a972oi2m@deep-thought.43-1.org
 Source: pg-reorg
 Version: 1.1.9-2
 Severity: serious

 pg-reorg regenerates d/control during build and creates packages not
 listed in the source package:

   Source: pg-reorg (1.1.9-2)
   Binary: postgresql-9.4-reorg

 but postgresql-9.4-reorg is not in the .dsc's Binary field.
 
 The problem is that the package needs porting to postgresql-9.4, but
 upstream hasn't done that yet.

Thats another problem. Regenerating d/control (and actually changing it)
is a RC bug on its own. I guess pg-reorg is not the only package doing
that, but didn't look into it.

Ansgar


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#650175: perl test dist/threads/t/stack now succeeds on GNU/Hurd

2014-08-18 Thread Svante Signell

found 650175 5.18.2-7
found 650175 5.20.0-4
thanks

Hi,

The patch hurd_test_skip_stack.diff is no longer needed since Hurd now
supports varying stack length sizes. Please remove it and close this bug
in the next version update of perl.

Thanks 


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#757645: Rationale for the change

2014-08-18 Thread Gianfranco Costamagna

Hi Yuri



 Il Lunedì 18 Agosto 2014 11:12, Yuri D'Elia wav...@thregr.org ha scritto:
  On 08/18/2014 08:22 AM, Gianfranco Costamagna wrote:
  Since also my first sponsor got some troubles in running them (if you
  choose pyside without having it installed you will likely have a
  import error and in some cases a segfault, IIRC), and since I'm a
  person that _really_ likes to install and run things, rather than
  install, run/fail/run/fail/check_faults/change_library, I choose to
  go for having them both required.
 
 IMHO it's perfectly reasonable that if you can select the binding
 engine, and the selected one is missing, the example fails.
 
 The idea of the example is not to let people swap engines at runtime,
 but to make the example run at all.
 
 You could detect at runtime which binding is available and gray out
 the selection if you really wanted to. This would fix the issue
 permanently.

this needs code, and would be nice to have a patch, or to report upstream :)

 
  In my opinion A is the best solution (didn't come in my mind when I
  firstly thought about this problem), but I really would like to hear
  some feedbacks ;)
 
 I would go for a
 
 Depends: pyside|pyqt
 
 recommending pyside as the favorable option, since pyqt with python 2.7
 has still the old SIP api enabled by default (and changing it is a
 PITA). I would recommend newcomers to use pyside if possible, even just
 for the API. Most developers already have a clear idea of which binding
 to use.
 

changed in git :)

 I would agree with upstream here to ship with the documentation. I'm
 working often offline, and I've reported many bug reports trying to ship
 docs along with the packages and to always Suggest: the -doc package if
 it exists.
 
 I personally wouldn't put examples into a different package, but ship
 them with the documentation. Unless the examples come with extra
 unreasonable dependencies. In this case, the -doc can recommend *both*
 pyqt and pyside (that is, with 2 recommends), without affecting the main
 package and without requiring an extra one.
 

but my approach will avoid the extra documentation if not needed, someone 
talked about small systems ;)

I mean, python is used in both development and deploy systems, so maybe a split 
is also good

 I feel that a reccomends would be too strong anyway, as one of the goals
 of pyqtgraph is really to be interchangeable between the two. As far as
 an example is concerned, if it runs with the installed engine, what's
 the point really?

the point is that people like me wants to have stuff working without reading 
the READMEs, trying to search for the right dependencies, look at 
recommends/depends/suggests fields...

my solution should be easily apt-get install friendly, with a nice difference 
between deploy and devel, and without requiring any kind of reading of the 
README.Debian documentation.

anyway I don't think I would like to add some code for detecting the available 
engine on the system (just an import with an exception catch?) for the *only* 
benefit of debian distros.

Upstream is so responsive about patches, so if you want to code and send 
upstream I'll be happy to cherry-pick and go for your solution :D

cheers,

Gianfranco

 
 
  BTW I'm a quite old DM, but I'm not in the dm.txt list for this
  package, so would be nice to have a sponsor for the change ;).
 
 Cannot help you here, I also need sponsors ;)



--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#649603: RFS: splash -- visualisation tool astrophysics stuff [ITP]

2014-08-18 Thread Ole Streicher

Hi Andreas,

Am 15.08.2014 um 13:53 schrieb Andreas Tille:
 So *if* your time permits and splash might come on top of your todo list
 I would encourage you to package it and hope it works in a similar way
 as my experience tells me.

I finished packaging and put everything in 

ssh://anonscm.debian.org/git/debian-astro/packages/splash.git
http://anonscm.debian.org/cgit/debian-astro/packages/splash.git

Could I ask you (or Steffen) to upload? I will, however, issue an RFA
for this package as soon as it is in Debian and I hope that someone takes
over. However, until then I will maintain this package.

Best regards

Ole


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#758504: tox: new upstream release, 1.7.2

2014-08-18 Thread Sandro Tosi

Source: tox
Severity: wishlist

Hello,
a new version has been released: https://pypi.python.org/pypi/tox/1.7.2

It would be cool if you can update the Debian package.

Thanks,
Sandro

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

Kernel: Linux 3.14-2-amd64 (SMP w/16 CPU cores)
Locale: LANG=en_IE.UTF-8, LC_CTYPE=en_IE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#721418: libdata-streamdeserializer-perl: diff for NMU version 0.06-1.1

2014-08-18 Thread Damyan Ivanov

Control: tags 721418 + patch

Dear maintainer,

Attached is the NMU diff for libdata-streamdeserializer-perl 0.06-1.1 
that I have just uploaded fixing this bug.

Regards,
dam
diff -Nru libdata-streamdeserializer-perl-0.06/debian/changelog libdata-streamdeserializer-perl-0.06/debian/changelog
--- libdata-streamdeserializer-perl-0.06/debian/changelog	2011-03-02 21:22:49.0 +0200
+++ libdata-streamdeserializer-perl-0.06/debian/changelog	2014-08-18 12:30:47.0 +0300
@@ -1,3 +1,13 @@
+libdata-streamdeserializer-perl (0.06-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * patch t/10_memoryleak.t to skip all tests if AUTOMATED_TESTING is in the
+environment. Fixes an intermittent failure during package build.
+(Closes: #721418)
+  * High urgency to help the perl 5.20 transition
+
+ -- Damyan Ivanov d...@debian.org  Mon, 18 Aug 2014 09:22:36 +
+
 libdata-streamdeserializer-perl (0.06-1) unstable; urgency=low
 
   * Initial release (Closes: #616138);
diff -Nru libdata-streamdeserializer-perl-0.06/debian/patches/skip-t_10_memoryleak.t.patch libdata-streamdeserializer-perl-0.06/debian/patches/skip-t_10_memoryleak.t.patch
--- libdata-streamdeserializer-perl-0.06/debian/patches/skip-t_10_memoryleak.t.patch	2014-08-18 12:19:48.0 +0300
+++ libdata-streamdeserializer-perl-0.06/debian/patches/skip-t_10_memoryleak.t.patch	2014-08-18 12:29:46.0 +0300
@@ -1,3 +1,11 @@
+Description: skip t/10_memoryleak.t in AUTOMATED_TESTING environment
+ This test fails from time to time, which is probably caused by the complex
+ nature of the perl memory allocator.
+ This patch skips the test in automated environment.
+Author: Damyan Ivanov d...@debian.org
+Bug-Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=721418
+Bug: https://rt.cpan.org/Ticket/Display.html?id=78969
+
 --- a/t/10_memoryleak.t
 +++ b/t/10_memoryleak.t
 @@ -7,14 +7,20 @@ use open qw(:std :utf8);

Bug#758505: tox: outdated Homepage field

2014-08-18 Thread Sandro Tosi

Source: tox
Severity: minor

Hello,
upstream homepage is now at http://tox.testrun.org/ but Homepage field is
pointing to the old website. Can you please update it?

Thanks,
Sandro


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

Kernel: Linux 3.14-2-amd64 (SMP w/16 CPU cores)
Locale: LANG=en_IE.UTF-8, LC_CTYPE=en_IE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#758330: blender: Use pkg-config to determine FFmpeg linker flags

2014-08-18 Thread Matteo F. Vescovi

Hi!

On 2014-08-16 at 23:39 (CEST), Andreas Cadhalpun wrote:
 Attached patch achieves that for this package. Please apply it to
 facilitate building your package with FFmpeg in Debian.

I'll consider this patch once the package in NEW will be accepted in the
official archives, surely not before.

Cheers.

-- 
Matteo F. Vescovi | Debian Maintainer
GnuPG KeyID: 4096R/0x8062398983B2CF7A


signature.asc
Description: Digital signature

Bug#758482: [Pkg-postgresql-public] Bug#758482: Bug#758482: pg-reorg: builds packages not listed in source package's debian/control

Re: Ansgar Burchardt 2014-08-18 53f1c2b7.9070...@debian.org
 Thats another problem. Regenerating d/control (and actually changing it)
 is a RC bug on its own. I guess pg-reorg is not the only package doing
 that, but didn't look into it.

That only happens in coordination with postgresql-common. The
coordination is tracked there:

https://release.debian.org/transitions/html/postgresql-9.4.html
https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=migration-94;tag=migration-93;users=pkg-postgresql-pub...@lists.alioth.debian.org
https://wiki.debian.org/pkg-postgresql/migration94

Christoph
-- 
c...@df7cb.de | http://www.df7cb.de/


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#758506: Fix for TLS read/handshake error

2014-08-18 Thread Lars-Dominik Braun

Package: pianobar
Version: 2012.05.06

Hi,

version 2012.05.06 (stable) currently fails with a TLS error message.
Please apply commit ea4324bbb6d3388c39f80906c85501feee3cb541, which
fixes the error message “TLS read error” and commit
72a461d31b6587a8dcc555af774913bf92b40f93 which replaces the default
certificate fingerprint.

Thanks,
Lars


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#745342: ITP: twine -- Collection of utilities for interacting with PyPI

2014-08-18 Thread Julian Gilbey

On Mon, Aug 18, 2014 at 08:49:46AM +0200, Zygmunt Krynicki wrote:
 Hi
 
 I've packaged twine and its dependency 'requests' but they are stuck
 in review. Requests was recently rejected and twine cannot be uploaded
 without that first.

Oh rubbish :-(

Thanks for working on this, though!

   Julian


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#756357: squid-deb-proxy: refresh_pattern for .tar.xz and .tar.bz2

2014-08-18 Thread Michael Vogt

On Tue, Jul 29, 2014 at 12:34:00AM -0700, Vagrant Cascadian wrote:
 Package: squid-deb-proxy
 Version: 0.8.8
 Severity: wishlist
 Tags: patch

Thanks for your bugreport and your patch.

I added this to the bzr tree and it will be part of the next upload.

Thanks,
 Michael
 
 squid-deb-proxy.conf sets a refresh_pattern on .tar.gz files, and it seems
 like it should also do so with .tar.xz and .tar.bz2 files as well, as these
 are now used by many source packages both upstream and within Debian.
 
 --- squid-deb-proxy.conf.dpkg-dist2014-07-18 04:25:52.0 -0700
 +++ squid-deb-proxy.conf  2014-07-29 00:10:59.114247495 -0700
 @@ -54,6 +54,8 @@
  refresh_pattern deb$   129600 100% 129600
  refresh_pattern udeb$   129600 100% 129600
  refresh_pattern tar.gz$  129600 100% 129600
 +refresh_pattern tar.xz$  129600 100% 129600
 +refresh_pattern tar.bz2$  129600 100% 129600
  
  # always refresh Packages and Release files
  refresh_pattern \/(Packages|Sources)(|\.bz2|\.gz|\.xz)$ 0 0% 0 refresh-ims
 
 
 live well,
   vagrant
 
 -- System Information:
 Debian Release: jessie/sid
   APT prefers testing
   APT policy: (500, 'testing'), (120, 'unstable')
 Architecture: amd64 (x86_64)
 Foreign Architectures: i386
 armhf
 
 Kernel: Linux 3.14-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
 
 Versions of packages squid-deb-proxy depends on:
 ii  debconf [debconf-2.0]  1.5.53
 ii  squid3 3.3.8-1.1+b1
 
 Versions of packages squid-deb-proxy recommends:
 ii  avahi-utils  0.6.31-4
 
 squid-deb-proxy suggests no packages.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#758482: [Pkg-postgresql-public] Bug#758482: Bug#758482: pg-reorg: builds packages not listed in source package's debian/control

Hi,

On 08/18/2014 11:38, Christoph Berg wrote:
 Re: Ansgar Burchardt 2014-08-18 53f1c2b7.9070...@debian.org
 Thats another problem. Regenerating d/control (and actually changing it)
 is a RC bug on its own. I guess pg-reorg is not the only package doing
 that, but didn't look into it.
 
 That only happens in coordination with postgresql-common. The
 coordination is tracked there:
 
 https://release.debian.org/transitions/html/postgresql-9.4.html
 https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=migration-94;tag=migration-93;users=pkg-postgresql-pub...@lists.alioth.debian.org
 https://wiki.debian.org/pkg-postgresql/migration94

So it's a case of should never break in theory, but does in practice? :)

Please don't silently regenerate d/control. It could generate a new one
and *fail* the build if it differs; the maintainer should use a special
target in d/rules or mv d/control.new d/control and restart the build.

See also debian/control breakage #2 in the REJECT-FAQ[1].

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

Ansgar


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#757645: Rationale for the change

2014-08-18 Thread Yuri D'Elia

On 08/18/2014 11:32 AM, Gianfranco Costamagna wrote:
 You could detect at runtime which binding is available and gray 
 out the selection if you really wanted to. This would fix the 
 issue permanently.
 
 this needs code, and would be nice to have a patch, or to report 
 upstream :)

Yes, this is why it's probably like this anyway. Not worth the effort.

 but my approach will avoid the extra documentation if not needed, 
 someone talked about small systems ;)

No problem with that. It's always good to have more granularity.

Though generally speaking, you'd need examples for doing development.

 I feel that a reccomends would be too strong anyway, as one of the 
 goals of pyqtgraph is really to be interchangeable between the
 two. As far as an example is concerned, if it runs with the
 installed engine, what's the point really?
 
 the point is that people like me wants to have stuff working without 
 reading the READMEs, trying to search for the right dependencies, 
 look at recommends/depends/suggests fields...

I think this discussion is a bit overkill.

I mean, you need pyqtgraph for development.
pyqtgraph needs at least *one* qt binding to work at all.
As a developer, I don't need strict dependencies to understand that.
In fact, I'm forced to use pyqt in some projects, and pyside in others.

When pyqtgraph is pulled as a dependency, you need to make sure to pull
the least amount of dependencies for user's sake. This is why an OR
dependency is the way to go. I would revert dependencies just to fix this.

I'm being pragmatic here. I'd expect developers to know what pyqt or
pyside mean. Maybe they don't know which one to choose, but this doesn't
make an intrinsic difference.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#758319: bird: Please ship birdcl in package

2014-08-18 Thread Ondrej Zajicek

On Mon, Aug 18, 2014 at 10:58:13AM +0200, Ondřej Surý wrote:
 Hi Micah,
 
 why would we need to ship birdcl together with birdc in one package?
 That makes no sense since birdcl is just no-readline version of birdc.

I think it makes sense. Generally birdc is more suited to interactive
usage, while birdcl is more suited to non-interactive usage (although
both could be used in the other way).

If you use birdc non-interactively using pipes, it cannot be ruled out
that readline would somehow interfere undesirably with it in some
unexpected way.

Another possible reason is that some third-party scripts (like looking
glass or scripting language bindings) use birdcl by default, so they
would have to be modified to use birdc in case that birdcl is not
available.

-- 
Elen sila lumenn' omentielvo

Ondrej 'Santiago' Zajicek (email: santi...@crfreenet.org)
OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net)
To err is human -- to blame it on a computer is even more so.


signature.asc
Description: Digital signature

Bug#731744: rancid: Use rancid-git fork

2014-08-18 Thread Vincent Bernat

 ❦  9 décembre 2013 18:18 +0100, Vincent Bernat v...@deezer.com :

 I am opening this bug report just to run the idea with you. Would it
 be possible to switch to the rancid-git fork [0] which adds git
 support. It also covers CVS and SVN support as the regular rancid.

 I don't know why git support has not been integrated upstream.

  [0]: http://dotwaffle.github.io/rancid-git/

 Attached is a patch to add git support to the current Debian package. I
 have just extracted what was related to git (and HTML emails) from
 dotwaffle repository. Feel free to use it (correct the version number
 in debian/changelog in this case).

As an update, it seems that git support is currently being discussed by
the original rancid maintainers. A patch exists and is being
reviewed. See for example:
 http://www.shrubbery.net/pipermail/rancid-discuss/2014-July/007753.html
-- 
prom_printf(Detected PenguinPages, getting out of here.\n);
2.0.38 /usr/src/linux/arch/sparc/mm/srmmu.c


signature.asc
Description: PGP signature

Bug#758507: p9m4: Please update to use wxpython3.0

Package: p9m4
Version: 0.5.dfsg-2.1
Severity: important
Tags: patch sid jessie
User: freewx-ma...@lists.alioth.debian.org
Usertags: wxpy3.0
Control: block 755757 by -1

We're aiming to migrate the archive to using wxpython3.0 instead of
wxwidgets2.8, and hope to drop wxwidgets2.8 before jessie is released.

I've rebuilt p9m4 with the attached patch to just update its
dependencies and it seems to work fine.

I'm happy to NMU these changes.

Cheers,
Olly
diff -u p9m4-0.5.dfsg/debian/control p9m4-0.5.dfsg/debian/control
--- p9m4-0.5.dfsg/debian/control
+++ p9m4-0.5.dfsg/debian/control
@@ -13,7 +13,7 @@
 
 Package: prover9-mace4
 Architecture: all
-Depends: ${python:Depends}, ${misc:Depends}, python-wxgtk2.8, prover9 (= 0.0.200712-1)
+Depends: ${python:Depends}, ${misc:Depends}, python-wxgtk3.0, prover9 (= 0.0.200712-1)
 Description: GUI for Prover9 and Mace4
  This package provides a graphical user interface for easily running
  the Prover9 theorem prover and the Mace4 countermodel generator
diff -u p9m4-0.5.dfsg/debian/changelog p9m4-0.5.dfsg/debian/changelog
--- p9m4-0.5.dfsg/debian/changelog
+++ p9m4-0.5.dfsg/debian/changelog
@@ -1,3 +1,10 @@
+p9m4 (0.5.dfsg-2.2) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Update to depend on python-wxgtk3.0 rather than python-wxgtk2.8.
+
+ -- Olly Betts o...@survex.com  Mon, 18 Aug 2014 21:53:23 +1200
+
 p9m4 (0.5.dfsg-2.1) unstable; urgency=low
 
   * Non-maintainer upload.

Bug#758508: /etc/apparmor.d/abstractions/perl incompatible with Perl 5.20

2014-08-18 Thread Jakub Wilk


Package: apparmor
Version: 2.8.0-5.1+b1
Severity: normal
User: debian-p...@lists.debian.org
Usertags: perl-5.20-transition

/etc/apparmor.d/abstractions/perl includes these:

 /usr/lib{,32,64}/perl5/** r,
 /usr/lib{,32,64}/perl{,5}/**.so*  mr,

But in Perl 5.20, the path changed from /usr/lib/perl to 
/usr/lib/${DEB_HOST_MULTIARCH}/perl.


--
Jakub Wilk


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#758509: ITP: ryu -- A component-based software defined networking framework

2014-08-18 Thread Dariusz Dwornikowski

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Package: wnpp
Severity: wishlist

* Package name: ryu
  Version : 3.12
  Upstream Author : Ryu Project Team ryu-de...@lists.sourceforge.net
* URL : http://osrg.github.io/ryu/
* License : Apache 2.0
  Programming Lang: Python
  Description : Component-based SDN framework.

Ryu is a component-based software defined networking framework. Ryu
provides software components with well defined API that make it easy
for developers to create new network management and control
applications. Ryu supports various protocols for managing network
devices, such as OpenFlow, Netconf, OF-config, etc. About OpenFlow,
Ryu supports fully 1.0, 1.2, 1.3, 1.4 and Nicira Extensions.




- -- 
Dariusz Dwornikowski,
  Institute of Computing Science, Poznań University of Technology
  www.cs.put.poznan.pl/ddwornikowski/
  room 2.7.2 BTiCW | tel. +48 61 665 29 41
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBCAAGBQJT8dFRAAoJECEac8aaew/HPIoP/i+I//f2TPbzTlEyyTSdqc/t
xB3tOZBVBWJHdu5TMl4S3czdxsnfcNTeWN4O7LsuKjEqcorrIJ/udh2G6tkhRSwF
ucPa8gDIx9cIVeNSlUoE8n+xTHQKzVtb40ouZZ5+fEtm8nsMNm2eYfvKxdB/wC6r
/QUqkMBUS5v5K70Zz/efj8CH1/Nlxlibdxc5YTbtLaXBBhtDPjkPvNZRrf1+87Fe
He1va68lyozBjhUki3o7w+AfLflgkLkLR5H7pghAWjrFH5QX8yuOtn65ckOOzj7A
N9j/QOfHcr6ClpLwbzI3UTjHp2/TOTgJPez25PfzRS9vLNr+OYytZdm+TDOcjv8o
8iHpXvfz1Iym7rV5h15sYzcPG0Iq2umSJgDh5hsneXUZXrtU/xnrDhVbgXagtQXm
tGg1KHW71JDhzDR5thiYh9aBozCRPZXfZJ851RDF0GcAYKMsvR7pewB8hFG8feZK
Sm5q5ux6IqlU/EDgzMxB6Wiq1+vay+05VcSQBRev/ZDtfh8RcN5ws4S2agGyLmey
pfOn9Fos0ks4invkq9JGKHH8K7EjeGL4qTLSOeBM36duiISfoTLcSHO8PSllxgy4
UaYd79lSnCtiLT1hZG4oIa4bgqeG27hW+BSSOiIQSHSCC1dgLRsIBaumjmjXf4/b
SPSiO81tkyL62lkpC0+d
=VUEM
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#758319: bird: Please ship birdcl in package

2014-08-18 Thread Ondřej Surý

On Mon, Aug 18, 2014, at 11:31, Ondrej Zajicek wrote:
 On Mon, Aug 18, 2014 at 10:58:13AM +0200, Ondřej Surý wrote:
  Hi Micah,
  
  why would we need to ship birdcl together with birdc in one package?
  That makes no sense since birdcl is just no-readline version of birdc.
 
 I think it makes sense. Generally birdc is more suited to interactive
 usage, while birdcl is more suited to non-interactive usage (although
 both could be used in the other way).
 
 If you use birdc non-interactively using pipes, it cannot be ruled out
 that readline would somehow interfere undesirably with it in some
 unexpected way.

We have many other examples when the CLI is compiled with readline
and it doesn't interfere (there was a problem in libedit in the past
when
using CLI in non-interactive way, but it's gone...).

 Another possible reason is that some third-party scripts (like looking
 glass or scripting language bindings) use birdcl by default, so they
 would have to be modified to use birdc in case that birdcl is not
 available.

This could be solved by a symlink reducing the binary with duplicate
functionality.

Ondrej
-- 
Ondřej Surý ond...@sury.org
Knot DNS (https://www.knot-dns.cz/) – a high-performance DNS server


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#751917: ghostscript: add ppc64el to symbols file (patch available)

2014-08-18 Thread Mauricio Faria de Oliveira


Hi Andreas and Jonas,

On 08/17/2014 08:10 AM, Jonas Smedegaard wrote:

Quoting Andreas Barth (2014-08-17 11:32:51)

* Mauricio Faria de Oliveira (mauri...@linux.vnet.ibm.com) [140817 09:31]:

May you please consider this trivial patch (attached) for an upload?

I'm willing to upload the fix, is it ok if I NMU this package?

Thanks, that'd be nice!


Thank you very much for the quick upload.  The package builds fine now!

Best regards,

--
Mauricio Faria de Oliveira
IBM Linux Technology Center


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#757645: Rationale for the change

2014-08-18 Thread Gianfranco Costamagna



 Il Lunedì 18 Agosto 2014 11:54, Yuri D'Elia wav...@thregr.org ha scritto:

  On 08/18/2014 11:32 AM, Gianfranco Costamagna wrote:
  You could detect at runtime which binding is available and gray 
  out the selection if you really wanted to. This would fix the 
  issue permanently.
 
  this needs code, and would be nice to have a patch, or to report 
  upstream :)
 
 Yes, this is why it's probably like this anyway. Not worth the effort.
 
  but my approach will avoid the extra documentation if not needed, 
  someone talked about small systems ;)
 
 No problem with that. It's always good to have more granularity.
 
 Though generally speaking, you'd need examples for doing development.
 
 
  I feel that a reccomends would be too strong anyway, as one of the 
  goals of pyqtgraph is really to be interchangeable between the
  two. As far as an example is concerned, if it runs with the
  installed engine, what's the point really?
 
  the point is that people like me wants to have stuff working without 
  reading the READMEs, trying to search for the right dependencies, 
  look at recommends/depends/suggests fields...
 
 I think this discussion is a bit overkill.
 
 I mean, you need pyqtgraph for development.
 pyqtgraph needs at least *one* qt binding to work at all.
 As a developer, I don't need strict dependencies to understand that.
 In fact, I'm forced to use pyqt in some projects, and pyside in others.
 
 When pyqtgraph is pulled as a dependency, you need to make sure to pull
 the least amount of dependencies for user's sake. This is why an OR
 dependency is the way to go. I would revert dependencies just to fix this.
 
 I'm being pragmatic here. I'd expect developers to know what pyqt or
 pyside mean. Maybe they don't know which one to choose, but this doesn't
 make an intrinsic difference.

I completely agree, this is what I committed on git so far
http://anonscm.debian.org/cgit/debian-science/packages/python-pyqtgraph.git

the fixed package is already on mentors
https://mentors.debian.net/package/python-pyqtgraph

and if somebody will ever fix the examples I'll be really happy to make them 
come back to the original place :D
(since because of the -doc package this will require a NEW step)

Now I'm trying to get everything work with python3
cheers,

G.




--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#754411: udev: loop mounts fail after 204-14 update

2014-08-18 Thread Michael Biebl

Am 11.07.2014 13:42, schrieb Marco d'Itri:
 On Jul 11, Michael Biebl bi...@debian.org wrote:
 
 This seems to be setup correctly afaics:
 It is, I can reproduce this on my system as well.
 
 Is our mount version too old or should it work irregardless of the mount
 It is:

Peter, this particular issue is solved when you upgrade to
util-linux/mount from experimental (if you are running sysvinit, you
also need udev 208-7).

I'm inclined to *not* add a workaround to udev to create /dev/loop0 and
simply wait until this util-linux version enters unstable.

In the case this doesn't happen for jessie, we can still revisit this
decision.

-- 
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#758510: mediawiki: 1.19.18 fixes security vulnerabilities (CVE-2014-5241 CVE-2014-5242 CVE-2014-5243)

2014-08-18 Thread Salvatore Bonaccorso

Source: mediawiki
Version: 1:1.19.17+dfsg-1
Severity: important
Tags: security upstream fixed-upstream
Control: found -1 1:1.19.16+dfsg-0+deb7u1

Hi

See

https://marc.info/?l=oss-securitym=140800398132695w=2

and 

https://www.mediawiki.org/wiki/Release_notes/1.19#Changes_since_1.19.17
https://lists.wikimedia.org/pipermail/mediawiki-announce/2014-July/000157.html

Regards,
Salvatore


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#758511: ITP: ibus-zhuyin -- IBus Zhuyin Input Method

2014-08-18 Thread Shih-Yuan Lee (FourDollars)

Package: wnpp
Severity: wishlist
Owner: Shih-Yuan Lee (FourDollars) fourdoll...@gmail.com

* Package name: ibus-zhuyin
  Version : 0.1.0
  Upstream Author : Shih-Yuan Lee (FourDollars) fourdoll...@gmail.com
* URL : https://github.com/fourdollars/ibus-zhuyin
* License : GPLv3
  Programming Lang: C
  Description : IBus Traditional ZhuYin Input Method

This traditional Chinese zhuyin input method is designed for old school
users. There is no intelligent phonetic matching mechanism, so you have
to select every word you type.

This program is similar to the plain mode of ibus-chewing. However
ibus-chewing uses intelligent phonetic matching mechanism by default.
ibus-zhuyin tends not to use any intelligent phonetic matching
mechanism, and keeps the program less dependencies and fast response.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#758482: [Pkg-postgresql-public] Bug#758482: Bug#758482: Bug#758482: pg-reorg: builds packages not listed in source package's debian/control

Re: Ansgar Burchardt 2014-08-18 53f1cbb6.8080...@debian.org
 So it's a case of should never break in theory, but does in practice? :)

Not quite. You just found the single package which wasn't updated for
9.4 yet, because it's broken upstream. There was no RC bug about it
yet because I had it on my radar.

 Please don't silently regenerate d/control. It could generate a new one
 and *fail* the build if it differs; the maintainer should use a special
 target in d/rules or mv d/control.new d/control and restart the build.

We rely on that mechanism to make backports and builds for
apt.postgresql.org to automatically create the right set of binaries.

Note that the regeneration of debian/control should only happen on
clean which I believe the buildds do not invoke. The only time when
debian/control really changes is when postgresql-common changes the
set of supported PostgreSQL versions. There will be no surprises aka
FTBFSes unless when a transition is ongoing. The current transition
has been started weeks ago, and this is the first problem report, so
we can probably say the mechanism is working.

I am aware the situation isn't optimal. We have been thinking about
alternative approaches (like putting modules for all PostgreSQL
versions in a single binary package), but all of them involve
different disadvantages as well. Suggestions welcome :) (Note that
with the current system, having to manually confirm the control update
would just have traded one kind of FTBFS for another kind, which I
wouldn't see as a change in the right direction.)

Christoph
-- 
c...@df7cb.de | http://www.df7cb.de/


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#751624: [systemd]: emergency shell takes several minutes to start

2014-08-18 Thread Michael Biebl

Am 21.06.2014 20:13, schrieb Michael Gold:
 On Tue, Jun 17, 2014 at 13:11:09 +0200, Michael Biebl wrote:
 Am 15.06.2014 00:50, schrieb Michael Gold:
 But why does it print the welcome message 3 times, with a delay each
 time?  And why does it give me an unusable root password prompt minutes
 before giving me a working one?

 Ok, this indeed doesn't sound like the 90s timeout after which systemd
 drops into the rescue shell.
 Not sure if the dying rescue shell is related to [1].

 If you systemctl enable debug-shell.service it starts a debug shell
 very early on during boot. You can switch to it on tty9.
 This might help you inspecting the system while that happens.

 What is the journal logging in such a case?
 
 The log is attached.  The debug shell was restarted while I was using
 it, and there were some messages logged about this.

If you add
Conflicts=syslog.socket
to /lib/systemd/system/emergency.service, is the problem gone?


-- 
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#758511: ITP: ibus-zhuyin -- IBus Zhuyin Input Method

2014-08-18 Thread Aron Xu

Hi,

It's nice to see the work on input method, do you mind to maintain the
package under the pkg-ime team's umbrella?

Regards,
Aron

On Mon, Aug 18, 2014 at 6:32 PM, Shih-Yuan Lee (FourDollars)
fourdoll...@gmail.com wrote:
 Package: wnpp
 Severity: wishlist
 Owner: Shih-Yuan Lee (FourDollars) fourdoll...@gmail.com

 * Package name: ibus-zhuyin
   Version : 0.1.0
   Upstream Author : Shih-Yuan Lee (FourDollars) fourdoll...@gmail.com
 * URL : https://github.com/fourdollars/ibus-zhuyin
 * License : GPLv3
   Programming Lang: C
   Description : IBus Traditional ZhuYin Input Method

 This traditional Chinese zhuyin input method is designed for old school
 users. There is no intelligent phonetic matching mechanism, so you have
 to select every word you type.

 This program is similar to the plain mode of ibus-chewing. However
 ibus-chewing uses intelligent phonetic matching mechanism by default.
 ibus-zhuyin tends not to use any intelligent phonetic matching
 mechanism, and keeps the program less dependencies and fast response.


 --
 To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
 with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
 Archive: https://lists.debian.org/20140818103225.8059.42035.reportbug@9020M




-- 
Regards,
Aron Xu


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#758504: Acknowledgement (tox: new upstream release, 1.7.2)

2014-08-18 Thread Sandro Tosi

control: severity -1 important

I'm raising the severity as 1.7.2 fixes the bug
https://bitbucket.org/hpk42/tox/issue/150/posargs-configerror which is
causing several issues in running OpenStack tests.

Regards,
Sandro

On Mon, Aug 18, 2014 at 10:36 AM, Debian Bug Tracking System
ow...@bugs.debian.org wrote:
 Thank you for filing a new Bug report with Debian.

 This is an automatically generated reply to let you know your message
 has been received.

 Your message is being forwarded to the package maintainers and other
 interested parties for their attention; they will reply in due course.

 Your message has been sent to the package maintainer(s):
  Barry Warsaw ba...@debian.org

 If you wish to submit further information on this problem, please
 send it to 758...@bugs.debian.org.

 Please do not send mail to ow...@bugs.debian.org unless you wish
 to report a problem with the Bug-tracking system.

 --
 758504: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=758504
 Debian Bug Tracking System
 Contact ow...@bugs.debian.org with problems



-- 
Sandro Tosi (aka morph, morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#758482: [Pkg-postgresql-public] Bug#758482: Bug#758482: Bug#758482: pg-reorg: builds packages not listed in source package's debian/control

On 08/18/2014 12:34, Christoph Berg wrote:
Re: Ansgar Burchardt 2014-08-18 53f1cbb6.8080...@debian.org
So it's a case of should never break in theory, but does in practice? :)

Not quite. You just found the single package which wasn't updated for
9.4 yet, because it's broken upstream. There was no RC bug about it
yet because I had it on my radar.

i.e. it breaks.

Please don't silently regenerate d/control. It could generate a new one
and *fail* the build if it differs; the maintainer should use a special
target in d/rules or mv d/control.new d/control and restart the build.

We rely on that mechanism to make backports and builds for
apt.postgresql.org to automatically create the right set of binaries.

Note that the regeneration of debian/control should only happen on
clean which I believe the buildds do not invoke.

Except that pg-reorg started to build packages not listed in d/control
on buildds... Which lead me to write a bug report.

https://buildd.debian.org/status/fetch.php?pkg=pg-reorgarch=s390xver=1.1.9-2%2Bb1stamp=1408310111

The current transition
has been started weeks ago, and this is the first problem report, so
we can probably say the mechanism is working.

It works unless packages are built at a different time than you expect,
like binNMUs for other reasons. That's what I mean by works in theory,
but breaks in practice.

(Note that
with the current system, having to manually confirm the control update
would just have traded one kind of FTBFS for another kind, which I
wouldn't see as a change in the right direction.)

It would at least FTBFS on the buildd and not upload broken things to
the archive.

Ansgar

--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#758402: ITP: python-xstatic-jquery.quicksearch -- jQuery.quicksearch XStatic support

2014-08-18 Thread Thomas Goirand

On 08/17/2014 10:29 PM, Justin B Rye wrote:
 Thomas Goirand wrote:
 Thanks for this message. I would welcome indeed any change to this long
 description, reviewed by the d-l-english team!
 
 Well, I'd like to, but so far I don't really understand it.  I don't
 even know what it means by static files.  As opposed to what?

As opposed to dynamic content. For example:
- javascript
- .css
- .png

are all static files, and not scripts. This is what XStatic provides.

 I do believe this is relevant. The point of the XStatic packages is that
 they are available using pip install, which make them universal. This
 is a very good selling point for Python developers, and will push them
 to use XStatic rather than embedding static files directly in their
 python module/app.
 
 I'm sure it's an interesting fact about XStatic, and therefore may
 belong in the package description for python-xstatic.  But how is it
 useful information for people trying to decide whether to install
 python-xstatic-jquery.quicksearch?  It seems to amount to this
 software is also available as something that isn't a Debian package,
 and that's true of pretty much anything in the archives.

The point is that they will have an API to find out what is the location
of the jquery.quicksearch in the system. And this API will work on every
operating system using packages (if they are available), or by
downloading the XStatic package using pip install
xstatic-jquery.quicksearch within the Python virtualenv.

 Meanwhile there's literally no description whatsoever of the
 functionality of jQuery.quicksearch!

The package depends on libjs-quicksearch. This is where you have the
correct description, and that's where I expect users will read. Do you
think the description of jquery.quicksearch should be copied there too?

By the way, python-xstatic-* packages aren't directly useful for the
final users, they will only be dependencies of Python applications, and
in my case, the OpenStack dashboard (eg: the Horizon web GUI).

On 08/18/2014 06:26 AM, Justin B Rye wrote:
 Some further googling reveals that by static files, Python web
 developers mean the kind of data files you might expect to find under
 $DOCROOT/resources/ or somewhere.

From Debian's perspective, the files would be in /usr/share/somewhere.

 Static files as opposed to... I'm not sure what.  Dynamically
 generated pages?

Yes. Often Django based web interface (as we're in Python). FYI Django
is *the* Python web GUI framework everyone is using, though I don't
think XStatic is specific to Django itself.

 But I definitely don't yet understand how XStatic renders a collection
 of files easily usable on all operating systems with any package
 management system.  Sure, bundling files into a Python egg might make
 them accessible via a Python egg installer, but that's not the same
 thing as making it possible to install them with APT.

The point of XStatic is to avoid developers to embed static files of
libraries (often: javascript libraries) directly in their Python
application, which is a security disaster from a distribution stand
point. A Python developer will simply make his application require
(which is the Python language to say depends) the XStatic python
module. If the developer works with pip, then it will automatically pip
install xstatic-jquery.quicksearch for example, which will go in the
virtualenv (which is a kind of chroot-like stuff specific to Python, if
you like).

When in a distribution like Debian, the
python-xstatic-jquery.quicksearch does *not* embed the library. It only
Depends: on the libjs-jquery.quicksearch (which I packaged separately),
and points to it (eg: in the package, I have patched upstream code
BASE_DIR configuration variable, which is what upstream recommends).

So XStatic stuff are really made for better integration within
distributions.

 So the thing to do is arrange for the package that contains your
 Python software to depend on the package that contains that JavaScript
 library.  Right?  Oh, no, of course, you can't do that because you're
 not on Debian, so your packaged Python doesn't have any way of
 depending on JavaScript - other than directly including the files,
 which is nasty.  Or... putting them in a *fake* Python package?  Aaah!
 Maybe this is beginning to make sense now...

I think you got it! Except that it's not really a fake python package,
it's a real one which is available from PyPi... :)

So, these Python packages really include the javascript, though the
Debian resulting python .deb will not.

  By having static files in packages, it is also easier to build
 virtual envs,

 Borderline ungrammatical.  And isn't it virtualenvs?  (Or virtual
 environments, but that's bad because it sounds as if it means what it
 says.)

virtual envs, or virtualenvs, are in the common Python dictionary. This
should stay as-is. Anyone who knows a bit about Python knows (or heard
about) virtualenvs.

  support linux/bsd/... distribution package maintainers and

Bug#755757: transition: wxpython3.0

On Wed, Jul 23, 2014 at 03:33:03PM +0200, Matthias Klose wrote:
Asking what will happen with packages depending on wxPython 2.8 and
which cannot be converted to 3.0.

There aren't many incompatible changes between wxPython 2.8 and 3.0.
With the C++ API, the Unicode changes have been quite painful, but
that's simply not relevant to wxPython.

My hope is that we will get all packages converted, though I know from
the wxwidgets2.8 transition that there are a few rdeps which are dead
upstream and effectively unmaintained in Debian. If such a package
isn't actually working currently and nobody has reported it, removal
might be the best option.

I've had a go at updating 20 of the rdeps of python-wxgtk2.8, so I've
now got some concrete information. I've done all the orphaned ones
(since it seemed unlikely anyone else would), the two which also depend
libwxgtk2.8-dev, and a selection of others biased towards those with
the highest popcon scores.

Several packages work without any changes (including p9m4, the last
upload of which was an NMU by me in 2011 for the wxwidgets2.8
transition!) For most of the others the updates needed are
mechanical (e.g. wx.Color is no longer supported as an alias for
wx.Colour). I've produced a script which automates most of these
(link below).

The 5 orphaned packages I just QA uploaded, and of the other 15, 5 have
either been uploaded by the maintainer or NMUed by me.

Of the other 10, 8 are ready to upload (so 18 are uploaded or ready to
upload).

The other two are:

grass: grass 7.0.0 is close to release, but would require a transition
for dependencies. For grass 6.4.3 I have a patch which makes the wizard
work, but the main gui needs more work.

playonlinux: The maintainer reports problems with layout. I've not yet
tried it myself (the description warns PlayOnLinux downloads and
execute unchecked third-party scripts), so I'm not sure what the cause
is.

Extrapolating to the ~80 rdeps, that suggests something like 8 that
won't be trivial to update, is a realistic number to have to address
before the freeze.

Here are the user tagged bugs:

https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=wxpy3.0;users=freewx-ma...@lists.alioth.debian.org

And the transition tracker:

https://release.debian.org/transitions/html/wxpython3.0.html

And finally, the repo with the script in, and a README about using it
and updating packages for wxPython 3.0 in general:

http://anonscm.debian.org/cgit/collab-maint/wx-migration-tools.git

I'd like to encourage maintainers of affected packages to try this
script out. In many cases, it should be enough to get your packages
working (if they don't already) - if it does, please upload them.

If the script doesn't do the job, let me know (or improve the script if
you can figure out what it needs to do to get your package working).

Cheers,
Olly

--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#757256: [Debian] thrift packaging

2014-08-18 Thread Stephan Sürken

Hi László

On Mon, 2014-08-18 at 08:24 +0200, László Böszörményi (GCS) wrote:
(..)
  I previously talked to Evan and he eventually RFAd them; the intention
  was, in a nutshell, that I take them over, make it mono-source package,
  and add the C++ library package (that's what I need).
  This is my plan as well.

Great!

  So, what are your intentions here? Are you also going to package the C++
  library? Will you also convert this to a monolithic source package?
  I'd like to make it monolithic. I don't see the reason for the split.
 More work to split them, when the language bindings should be the same
 version anyway.

Hmm, exactly my reasoning.

  I would still be willing to take it all over if you are fine with that;
  alternatively I would be honored to be able to help with/provide the C++
  library packaging. I do have some headaches though with the current
  extra setup, deliberately splitting upstream.
  I hope I can do most of the work today. Then I can give it to you for
 testing / review if you are interested.

Sure; if you have anything ready before uploading it to
experimental/unstable, I could have a look.

Again, thanks for packaging it!

Stephan


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#758216: libmusicbrainz-discid-perl: FTBFS: * stack smashing detected * during tests

2014-08-18 Thread Damyan Ivanov

-=| Damyan Ivanov, 15.08.2014 16:06:45 +0300 |=-
 Package: libmusicbrainz-discid-perl
 Version: 0.03-4
 Severity: serious
 
 libmusicbrainz-discid-perl failed to build with today's round of binNMUs for 
 perl 5.20:
 
 Module::Build will be removed from the Perl core distribution in the next 
 major release. Please install the separate libmodule-build-perl package. It 
 is being used at Build, line 40.
 t/00use.t . ok
 t/05pod.t . ok
 *** stack smashing detected ***: /usr/bin/perl terminated
 === Backtrace: =
 /lib/s390x-linux-gnu/libc.so.6(+0x8787c)[0x3fffd31287c]
 /lib/s390x-linux-gnu/libc.so.6(__fortify_fail+0x38)[0x3fffd399d70]
 /lib/s390x-linux-gnu/libc.so.6(+0x10ed36)[0x3fffd399d36]
 /«PKGBUILDDIR»/blib/arch/auto/MusicBrainz/DiscID/DiscID.so(+0x1946)[0x3fffd248946]
 /usr/lib/s390x-linux-gnu/libperl.so.5.20(Perl_pp_entersub+0x5d4)[0x3fffd5e359c]

Here's a stack trace on i386:

#0  0xf75d31ac in raise () from /lib/i386-linux-gnu/libc.so.6
#1  0xf75d4833 in abort () from /lib/i386-linux-gnu/libc.so.6
#2  0xf7611f58 in ?? () from /lib/i386-linux-gnu/libc.so.6
#3  0xf768b230 in __fortify_fail () from /lib/i386-linux-gnu/libc.so.6
#4  0xf768b1ea in __stack_chk_fail () from /lib/i386-linux-gnu/libc.so.6
#5  0xf756f8f4 in __stack_chk_fail_local ()
   from 
/libmusicbrainz-discid-perl-0.03/blib/arch/auto/MusicBrainz/DiscID/DiscID.so
#6  0xf756f3e7 in XS_MusicBrainz__DiscID_discid_put (my_perl=0x968e008, 
cv=0x9840278)
at lib/MusicBrainz/DiscID.c:584
#7  0x0813d839 in Perl_pp_entersub (my_perl=0x968e008) at pp_hot.c:2795
#8  0x0810a6df in Perl_runops_debug (my_perl=0x968e008) at dump.c:2428
#9  0x0808af96 in S_run_body (oldscope=optimized out, my_perl=optimized 
out) at perl.c:2456
#10 perl_run (my_perl=0x968e008) at perl.c:2372
#11 0x0805fe4a in main (argc=2, argv=0xfff59204, env=0xfff59210) at 
perlmain.c:114

Building with DEB_BUILD_MAINT_OPTIONS=hardening=-stackprotectorstrong 
results in passing tests.

Here's the assembler code for the XS_MusicBrainz__DiscID_discid_put 
function (with default build flags, including stackprotectorstrong):

Dump of assembler code for function XS_MusicBrainz__DiscID_discid_put:
546 {
   0xf756ecf6 +0: push   %ebp
   0xf756ecf7 +1: mov%esp,%ebp
   0xf756ecf9 +3: push   %edi
   0xf756ecfa +4: push   %esi
   0xf756ecfb +5: push   %ebx
   0xf756ecfc +6: sub$0x1fc,%esp
   0xf756ed02 +12:call   0xf756bbe0 __x86.get_pc_thunk.bx
   0xf756ed07 +17:add$0x32f9,%ebx
   0xf756ed0d +23:mov0x8(%ebp),%eax
   0xf756ed10 +26:mov%eax,-0x1fc(%ebp)
   0xf756ed16 +32:mov0xc(%ebp),%eax
   0xf756ed19 +35:mov%eax,-0x200(%ebp)
   0xf756ed1f +41:mov%gs:0x14,%eax
   0xf756ed25 +47:mov%eax,-0x1c(%ebp)
   0xf756ed28 +50:xor%eax,%eax

547 dVAR; dXSARGS;
   0xf756ed2a +52:mov-0x18(%ebx),%eax
   0xf756ed30 +58:mov(%eax),%eax
   0xf756ed32 +60:sub$0xc,%esp
   0xf756ed35 +63:push   %eax
   0xf756ed36 +64:call   0xf756ba60 pthread_getspecific@plt
   0xf756ed3b +69:add$0x10,%esp
   0xf756ed3e +72:mov(%eax),%eax
   0xf756ed40 +74:mov%eax,-0x1e8(%ebp)
   0xf756ed46 +80:mov-0x18(%ebx),%eax
   0xf756ed4c +86:mov(%eax),%eax
   0xf756ed4e +88:sub$0xc,%esp
   0xf756ed51 +91:push   %eax
   0xf756ed52 +92:call   0xf756ba60 pthread_getspecific@plt
   0xf756ed57 +97:add$0x10,%esp
   0xf756ed5a +100:   mov%eax,%edx
   0xf756ed5c +102:   mov0x44(%edx),%eax
   0xf756ed5f +105:   lea-0x4(%eax),%ecx
   0xf756ed62 +108:   mov%ecx,0x44(%edx)
   0xf756ed65 +111:   mov(%eax),%eax
   0xf756ed67 +113:   mov%eax,-0x1e4(%ebp)
   0xf756ed6d +119:   mov-0x18(%ebx),%eax
   0xf756ed73 +125:   mov(%eax),%eax
   0xf756ed75 +127:   sub$0xc,%esp
   0xf756ed78 +130:   push   %eax
   0xf756ed79 +131:   call   0xf756ba60 pthread_getspecific@plt
   0xf756ed7e +136:   add$0x10,%esp
   0xf756ed81 +139:   mov0xc(%eax),%ecx
   0xf756ed84 +142:   mov-0x1e4(%ebp),%eax
   0xf756ed8a +148:   lea0x1(%eax),%edx
   0xf756ed8d +151:   mov%edx,-0x1e4(%ebp)
   0xf756ed93 +157:   shl$0x2,%eax
   0xf756ed96 +160:   add%ecx,%eax
   0xf756ed98 +162:   mov%eax,-0x1e0(%ebp)
   0xf756ed9e +168:   mov-0x1e8(%ebp),%edx
   0xf756eda4 +174:   mov-0x1e0(%ebp),%eax
   0xf756edaa +180:   sub%eax,%edx
   0xf756edac +182:   mov%edx,%eax
   0xf756edae +184:   sar$0x2,%eax
   0xf756edb1 +187:   mov%eax,-0x1dc(%ebp)

548 if (items  4)
   0xf756edb7 +193:   cmpl   $0x3,-0x1dc(%ebp)
   0xf756edbe +200:   jg 0xf756edd5 
XS_MusicBrainz__DiscID_discid_put+223

549croak_xs_usage(cv,  disc, first_track, sectors, offsets );
   0xf756edc0 +202:   sub$0x8,%esp
   0xf756edc3 +205:   lea-0x24a4(%ebx),%eax
   0xf756edc9 +211:   push   %eax
   0xf756edca +212:   pushl  -0x200(%ebp)
   0xf756edd0 +218:   call   0xf756bae0

Bug#758485: dkms: sed: -e expression #1, char 6: unknown command: `m' when installing nvidia

2014-08-18 Thread Olivier Berger

On Mon, Aug 18, 2014 at 02:09:39AM +0100, Julian Gilbey wrote:
 
 When updating nvidia-kernel-dkms, I observed the following:
 

SNIP

 sed: -e expression #1, char 6: unknown command: `m'
 
 I have not been able to identify the source of this sed error, sorry.
 
FWIW, I've just experienced a similar error in rebuilding virtualbox guest 
modules :

# LANG=C dpkg-reconfigure virtualbox-guest-dkms

 Uninstall Beginning 
Module:  virtualbox-guest
Version: 4.3.14
Kernel:  3.14-2-686-pae (i686)
-

Status: Before uninstall, this module version was ACTIVE on this kernel.

vboxguest.ko:
 - Uninstallation
   - Deleting from: /lib/modules/3.14-2-686-pae/updates/
 - Original module
   - No original module was found for this module on this kernel.
   - Use the dkms install command to reinstall any previous module version.


vboxsf.ko:
 - Uninstallation
   - Deleting from: /lib/modules/3.14-2-686-pae/updates/
 - Original module
   - No original module was found for this module on this kernel.
   - Use the dkms install command to reinstall any previous module version.


vboxvideo.ko:
 - Uninstallation
   - Deleting from: /lib/modules/3.14-2-686-pae/updates/
 - Original module
   - No original module was found for this module on this kernel.
   - Use the dkms install command to reinstall any previous module version.

depmod

DKMS: uninstall completed.

--
Deleting module version: 4.3.14
completely from the DKMS tree.
--
Done.
Loading new virtualbox-guest-4.3.14 DKMS files...
Building only for 3.14-2-686-pae
Building initial module for 3.14-2-686-pae
Done.

vboxguest:
Running module version sanity check.
 - Original module
   - No original module exists within this kernel
 - Installation
   - Installing to /lib/modules/3.14-2-686-pae/updates/

vboxsf.ko:
Running module version sanity check.
 - Original module
   - No original module exists within this kernel
 - Installation
   - Installing to /lib/modules/3.14-2-686-pae/updates/

vboxvideo.ko:
Running module version sanity check.
 - Original module
   - No original module exists within this kernel
 - Installation
   - Installing to /lib/modules/3.14-2-686-pae/updates/

sed: -e expression #1, char 6: unknown command: `m'
depmod

DKMS: install completed.



Hope this helps.

Best regards,
-- 
Olivier BERGER 
http://www-public.telecom-sudparis.eu/~berger_o/ - OpenPGP-Id: 2048R/5819D7E8
Ingenieur Recherche - Dept INF
Institut Mines-Telecom, Telecom SudParis, Evry (France)


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#568836: choose profiles after installation

2014-08-18 Thread Holger Levsen

Hi,

On Sonntag, 17. August 2014, Petter Reinholdtsen wrote:
 It allow one to take basic / simple Debian system and transform it into
 a Debian Edu system.  It is expected to work if the packages configured
 by Debian Edu during installation are not installed before the
 debian-edu-bless script is executed.

if this is expected, the script should check this and fail+complain if this 
requirement is not met.

 There is no way to roll back (aka
 de-activate) this transformation, thought.

warn the user appropriatly, ask and default to no. Either via debconf (which 
then is translatable) or via a --really-run-this option (probably better 
named though :)


cheers,
Holger




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

Bug#758512: debian-cd: Wrong word splitting reg-exp for $ENV{ARCHES}

2014-08-18 Thread Philipp Hahn

Package: debian-cd
Version: 3.1.13
Severity: normal

Dear Maintainer,

the environment variable ARCHES is set to amd64, but
tools/generate_di_lists still complains about a missing i386 Packages
file:
 Missing package file for i386/local.

I think the regular expressions are wrong, since [^\s] is any character
other then a white-space while (^|\s) would match beginning of
string or white space. Same for [\s\$] to match the end of the work.

--- tools/generate_di_list.orig 2014-07-30 09:23:32.464452565 +0200
+++ tools/generate_di_list  2014-07-30 09:23:40.576662354 +0200
@@ -12,8 +12,8 @@
  my @ARCHES;
 if ( $ENV{ARCHES} ) {
-push @ARCHES, 'i386' if $ENV{ARCHES} =~ /[^\s]i386[\s\$]/;
-push @ARCHES, 'amd64' if $ENV{ARCHES} =~ /[^\s]amd64[\s\$]/;
+push @ARCHES, 'i386' if $ENV{ARCHES} =~ /(^|\s)i386(\s|$)/;
+push @ARCHES, 'amd64' if $ENV{ARCHES} =~ /(^|\s)amd64(\s|$)/;
 push @ARCHES, grep { !/^(source|i386|amd64)$/ } split /\s+/,
$ENV{ARCHES};
 }
 @ARCHES = qw{i386 amd64} unless @ARCHES;

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

Kernel: Linux 3.2.0-4-amd64 (SMP w/2 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#758177: [Pkg-bluetooth-maintainers] Bug#758177: blue: hcitool dev yields no device although the Laptop has 2 bluetooth apadpters.

2014-08-18 Thread Nobuhiro Iwamatsu

severity 758177 important
thanks

Hi,

Please run the hcicinfig.
If you are not able to obtain an output such as the following, is not able to
recognize the bluetooth host device on your machine.

$ hciconfig
hci0: Type: BR/EDR  Bus: USB
BD Address: xx:xx:xx:xx:xx:EF  ACL MTU: 1021:8  SCO MTU: 64:1
UP RUNNING PSCAN ISCAN
RX bytes:14637 acl:0 sco:0 events:1517 errors:0
TX bytes:13791 acl:0 sco:0 commands:782 errors:0

Best regards,
  Nobuhiro

2014-08-15 12:39 GMT+09:00 Kumar Abhishek kumar.os.tes...@gmail.com:
 Package: bluetooth
 Version: 4.101-4.1
 Severity: grave
 File: blue
 Justification: renders package unusable

 Dear Maintainer,

* What led up to the situation?
 == Wanted to use the bluetooth to pair my laptop to my phone and a portable 
 bluetooth speaker.
* What exactly did you do (or not do) that was effective (or
  ineffective)?
 == I had restarted bluetooth service from init.d.
* What was the outcome of this action?
 == The service restarted successfully without any error, but the adapters 
 still could not be detected.
* What outcome did you expect instead?
 == Expected that the service restart could start the bluetooth adapter

 -
 root@debiantesting:/var/log# /etc/init.d/bluetooth restart
 [ ok ] Stopping bluetooth: rfcomm /usr/sbin/bluetoothd.
 [ ok ] Starting bluetooth: bluetoothd rfcomm.

 root@debiantesting:/var/log# dmesg | grep -i blue
 [6.562242] usb 8-4: Product: Bluetooth USB Host Controller
 [   10.738355] Bluetooth: Core ver 2.17
 [   10.738389] Bluetooth: HCI device and connection manager initialized
 [   10.738402] Bluetooth: HCI socket layer initialized
 [   10.738407] Bluetooth: L2CAP socket layer initialized
 [   10.738415] Bluetooth: SCO socket layer initialized
 [   12.000574] Bluetooth: Loading patch file failed
 [   24.963833] Bluetooth: RFCOMM TTY layer initialized
 [   24.963850] Bluetooth: RFCOMM socket layer initialized
 [   24.963863] Bluetooth: RFCOMM ver 1.11
 [   25.043101] Bluetooth: BNEP (Ethernet Emulation) ver 1.3
 [   25.043107] Bluetooth: BNEP filters: protocol multicast
 [   25.043121] Bluetooth: BNEP socket layer initialized
 root@debiantesting:/var/log#
 
 hp-pavillion g6 2010ax : AMD APU A8(4500m) Dual Graphic Card
 

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

 Kernel: Linux 3.13-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

 Versions of packages bluetooth depends on:
 ii  bluez  4.101-4.1

 Versions of packages bluetooth recommends:
 ii  bluez-alsa   4.101-4.1
 ii  bluez-gstreamer  4.101-4.1

 Versions of packages bluetooth suggests:
 pn  bluez-cups  none

 -- no debconf information

 ___
 Pkg-bluetooth-maintainers mailing list
 pkg-bluetooth-maintain...@lists.alioth.debian.org
 http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-bluetooth-maintainers



-- 
Nobuhiro Iwamatsu
   iwamatsu at {nigauri.org / debian.org}
   GPG ID: 40AD1FA6


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#757037: liblzo2-2: Upgrading liblzo2-2 to 2.08 crashes openvpn

2014-08-18 Thread Thomas Herrmann

On 08/18/2014 04:57 AM, Peter Eisentraut wrote:
 Do you have a reproducible test case for that?

Yes, just created one:

root@qnap:/etc/openvpn# cat test.conf
local 192.168.242.215
port 1194
proto udp
dev tun
ca ca.crt
cert qnap.crt
key qnap.key
dh dh1024.pem
server 192.168.54.0 255.255.255.0
ifconfig-pool-persist ipp.txt
push route 192.168.242.0 255.255.255.0
keepalive 10 120
comp-lzo
user nobody
group nogroup
persist-key
persist-tun
status openvpn-status.log
verb 3

root@qnap:/etc/openvpn# openvpn --cd /etc/openvpn --config 
/etc/openvpn/test.conf  Mon Aug 18 13:15:35 2014 OpenVPN 2.3.2 
arm-unknown-linux-gnueabi [SSL (OpenSSL)] [LZO] [EPOLL] [PKCS11] [eurephia] 
[MH] [IPv6] built on Mar 18 2014
Mon Aug 18 13:15:35 2014 Diffie-Hellman initialized with 1024 bit key
Mon Aug 18 13:15:35 2014 Socket Buffers: R=[163840-131072] S=[163840-131072]
Mon Aug 18 13:15:35 2014 ROUTE_GATEWAY 192.168.242.1/255.255.255.0 IFACE=eth0 
HWADDR=00:08:9b:c6:12:56
Mon Aug 18 13:15:35 2014 TUN/TAP device tun0 opened
Mon Aug 18 13:15:35 2014 TUN/TAP TX queue length set to 100
Mon Aug 18 13:15:35 2014 do_ifconfig, tt-ipv6=0, tt-did_ifconfig_ipv6_setup=0
Mon Aug 18 13:15:35 2014 /sbin/ip link set dev tun0 up mtu 1500
Mon Aug 18 13:15:35 2014 /sbin/ip addr add dev tun0 local 192.168.54.1 peer 
192.168.54.2
Mon Aug 18 13:15:35 2014 /sbin/ip route add 192.168.54.0/24 via 192.168.54.2
Mon Aug 18 13:15:35 2014 GID set to nogroup
Mon Aug 18 13:15:35 2014 UID set to nobody
Mon Aug 18 13:15:35 2014 UDPv4 link local (bound): [AF_INET]192.168.242.215:1194
Mon Aug 18 13:15:35 2014 UDPv4 link remote: [undef]
Mon Aug 18 13:15:35 2014 MULTI: multi_init called, r=256 v=256
Mon Aug 18 13:15:35 2014 IFCONFIG POOL: base=192.168.54.4 size=62, ipv6=0
Mon Aug 18 13:15:35 2014 IFCONFIG POOL LIST
Mon Aug 18 13:15:35 2014 Initialization Sequence Completed
Mon Aug 18 13:15:35 2014 109.91.169.175:38150 Cannot initialize LZO compression 
library
Mon Aug 18 13:15:35 2014 109.91.169.175:38150 Exiting due to fatal error


Downgrade to 2.06:

root@qnap:/etc/openvpn# dpkg -i ~/liblzo2-2_2.06-1+deb7u1_armel.deb dpkg: 
warning: downgrading liblzo2-2:armel from 2.08-1 to 2.06-1+deb7u1
(Reading database ... 99277 files and directories currently installed.)
Preparing to unpack .../liblzo2-2_2.06-1+deb7u1_armel.deb ...
Unpacking liblzo2-2:armel (2.06-1+deb7u1) over (2.08-1) ...
Setting up liblzo2-2:armel (2.06-1+deb7u1) ...
Processing triggers for libc-bin (2.19-7) ...


root@qnap:/etc/openvpn# openvpn --cd /etc/openvpn --config 
/etc/openvpn/test.conf
Mon Aug 18 13:16:26 2014 OpenVPN 2.3.2 arm-unknown-linux-gnueabi [SSL 
(OpenSSL)] [LZO] [EPOLL] [PKCS11] [eurephia] [MH] [IPv6] built on Mar 18 2014
Mon Aug 18 13:16:26 2014 Diffie-Hellman initialized with 1024 bit key
Mon Aug 18 13:16:26 2014 Socket Buffers: R=[163840-131072] S=[163840-131072]
Mon Aug 18 13:16:26 2014 ROUTE_GATEWAY 192.168.242.1/255.255.255.0 IFACE=eth0 
HWADDR=00:08:9b:c6:12:56
Mon Aug 18 13:16:26 2014 TUN/TAP device tun0 opened
Mon Aug 18 13:16:26 2014 TUN/TAP TX queue length set to 100
Mon Aug 18 13:16:26 2014 do_ifconfig, tt-ipv6=0, tt-did_ifconfig_ipv6_setup=0
Mon Aug 18 13:16:26 2014 /sbin/ip link set dev tun0 up mtu 1500
Mon Aug 18 13:16:26 2014 /sbin/ip addr add dev tun0 local 192.168.54.1 peer 
192.168.54.2
Mon Aug 18 13:16:26 2014 /sbin/ip route add 192.168.54.0/24 via 192.168.54.2
Mon Aug 18 13:16:26 2014 GID set to nogroup
Mon Aug 18 13:16:26 2014 UID set to nobody
Mon Aug 18 13:16:26 2014 UDPv4 link local (bound): [AF_INET]192.168.242.215:1194
Mon Aug 18 13:16:26 2014 UDPv4 link remote: [undef]
Mon Aug 18 13:16:26 2014 MULTI: multi_init called, r=256 v=256
Mon Aug 18 13:16:26 2014 IFCONFIG POOL: base=192.168.54.4 size=62, ipv6=0
Mon Aug 18 13:16:26 2014 IFCONFIG POOL LIST
Mon Aug 18 13:16:26 2014 Initialization Sequence Completed
Mon Aug 18 13:16:31 2014 109.91.169.175:59973 TLS: Initial packet from 
[AF_INET]109.91.169.175:59973, sid=265834d9 280eeafc
Mon Aug 18 13:16:31 2014 109.91.169.175:59973 VERIFY OK: depth=1, C=DE, ST=XX, 
L=XX, O=Home, OU=None, CN=Home CA, emailAddress=XX
Mon Aug 18 13:16:31 2014 109.91.169.175:59973 VERIFY OK: depth=0, C=DE, ST=XX, 
L=XX, O=Home, OU=None, CN=XX, emailAddress=XX


I have just realized that the problem only occurrs, when a client connects. So 
to reproduce the problem a fully working openvpn setup (including keys an 
certificates) is necessary, including a client.

Regards
Thomas


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#758513: fails to authenticate if multiple LDAP results match, misleading error message

2014-08-18 Thread Daniel Pocock

Package: nagios3

Not sure if this log message comes from Apache or from Nagios, if it is
an Apache error then please re-assign to the Apache package.

Basically, my Nagios was working fine with Apache LDAP

In httpd.conf:

AuthType bsic
AuthBasicProvider ldap
AuthName test server
AuthLDAPURL ldap://some-server/dc=example,dc=org;

One day, I found I could not log in to the web interface, the password
popup would keep appearing

Looking at the Apache error log file, I could see lines like this:

 user daniel not found: /nagios3/cgi-bin/status.cgi

Looking in Google, not found brings up all kinds of unrelated pages,
but I found a few other people with similar messages such as:

 user nagiosadmin not found: /nagios3/cgi-bin/status.cgi
 user root not found: /nagios/cgi-bin/status.cgi

In my case it turns out that somebody had changed the LDAP configuration
and created two users called daniel, each in different sub-trees, e.g.

uid=daniel,dc=test,dc=example,dc=org
uid=daniel,dc=production,dc=example,dc=org

So the not found message is actually quite confusing, in my case, it
seems to indicate that two users were found and it didn't know which is
correct.  By refining my AuthLDAPURL to use
dc=production,dc=example,dc=org I got it working again.

Other people commented that disabling SELinux or fixing permissions on
the htpasswd file made this error go away in other situations.  In my
case, none of that feedback was relevant.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#740678: Abiword maintainer

2014-08-18 Thread Dmitry Smirnov

Dear Carlo, Per and Jose,

Thank you for your interest to Abiword.

On Sat, 16 Aug 2014 15:35:20 Carlo Giordano wrote:
 I want maintainer Abiword.

Your help is very welcome. 


 Do you help me?

I might be occasionally available for sponsorship and review of your changes. 
However my primary reasons for searching for (co-)maintainer(s) are lack of 
time and interest to Abiword...

Here are some links that (I hope) you might find useful:

http://www.debian.org/doc/manuals/maint-guide/index.en.html
http://wiki.debian.org/IntroDebianPackaging
http://wiki.debian.org/PackagingTutorial
http://wiki.debian.org/Packaging
https://mentors.debian.net/


 On Sat, Aug 16, 2014 at 5:35 PM, Carlo Giordano
 I would suggest that you maintain it in the Debian Junior Team.

I don't know why Debian Junior Team might be interested to take care of 
Abiword. At the moment Abiword repository is at collab-maint where all DDs can 
contribute. For now let's keep repository where it is although I do not mind 
if Junior team will be listed as Maintainer and take over the packaging.

Also please take care of wv dependency package.

Thank you.

-- 
Regards,
 Dmitry Smirnov.

---

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


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

Bug#758511: ITP: ibus-zhuyin -- IBus Zhuyin Input Method

2014-08-18 Thread Shih-Yuan Lee (FourDollars)

Hi Aron,

Sure.
Please provide the relative information to me.

Regards,
$4


On Mon, Aug 18, 2014 at 6:37 PM, Aron Xu happyaron...@gmail.com wrote:

 Hi,

 It's nice to see the work on input method, do you mind to maintain the
 package under the pkg-ime team's umbrella?

 Regards,
 Aron

 On Mon, Aug 18, 2014 at 6:32 PM, Shih-Yuan Lee (FourDollars)
 fourdoll...@gmail.com wrote:
  Package: wnpp
  Severity: wishlist
  Owner: Shih-Yuan Lee (FourDollars) fourdoll...@gmail.com
 
  * Package name: ibus-zhuyin
Version : 0.1.0
Upstream Author : Shih-Yuan Lee (FourDollars) fourdoll...@gmail.com
  * URL : https://github.com/fourdollars/ibus-zhuyin
  * License : GPLv3
Programming Lang: C
Description : IBus Traditional ZhuYin Input Method
 
  This traditional Chinese zhuyin input method is designed for old school
  users. There is no intelligent phonetic matching mechanism, so you have
  to select every word you type.
 
  This program is similar to the plain mode of ibus-chewing. However
  ibus-chewing uses intelligent phonetic matching mechanism by default.
  ibus-zhuyin tends not to use any intelligent phonetic matching
  mechanism, and keeps the program less dependencies and fast response.
 
 
  --
  To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
  with a subject of unsubscribe. Trouble? Contact
 listmas...@lists.debian.org
  Archive:
 https://lists.debian.org/20140818103225.8059.42035.reportbug@9020M
 



 --
 Regards,
 Aron Xu

Bug#757917: transition: libav11

2014-08-18 Thread Reinhard Tartler

On Sat, Aug 16, 2014 at 11:24 AM, Reinhard Tartler siret...@gmail.com wrote:

 vlc FAIL (silly configure check fail, will sort out with upstream)

 Turns out to be sligtly more complicated as thought. After
 consultation with j-b (videolan upstream), we decided that we really
 should go with vlc 2.2 for jessie. This, however, requires new
 upstream releases of libdvdread and libdvdnav (j-b blogged on this:
 http://www.jbkempf.com/blog/post/2014/dvdread-dvdnav-and-dvdcss)

 I've uploaded both packages, the next step would be to update vlc to 2.2.

VLC 2.2 pre2 is now uploaded to unstable. Because of a SONAME bump of
libvlccore, it requires going through, but I expect that to be really
trivial.

Now with all packages fixed, are we good to proceed with libav11 in
unstable now?

-- 
regards,
Reinhard


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#758511: ITP: ibus-zhuyin -- IBus Zhuyin Input Method

2014-08-18 Thread Aron Xu

On Mon, Aug 18, 2014 at 7:41 PM, Shih-Yuan Lee (FourDollars)
fourdoll...@gmail.com wrote:
 Hi Aron,

 Sure.
 Please provide the relative information to me.

 Regards,
 $4


Please join https://alioth.debian.org/projects/pkg-ime/

And create git repository on it, for example the ibus one:
http://anonscm.debian.org/cgit/pkg-ime/ibus.git

It would be appreciate to put pkg-ime as Maintainer, and yourself as Uploaders.

Thanks,
Aron Xu


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#751277: python-biopython: FTBFS on mips* powerpc s390x

2014-08-18 Thread David Gosselin

I can provide SSH access to a PowerMac G5 running 7.6 if you'd like to test 
this. 

 On Aug 18, 2014, at 4:01, Andreas Tille andr...@an3as.eu wrote:
 
 Hi porters,
 
 could you please be so kind to check this issue?  It would be great to
 find out why the test suite of biopython fails on these architectures.
 
 Thanks a lot
 
   Andreas.
 
 On Mon, Aug 18, 2014 at 12:35:53AM -0700, Michiel de Hoon wrote:
 Hi Andreas,
 
 Without access to powerpc, I have no way to test the code.
 Can you try recompiling Biopython and checking what exactly happens inside 
 the distance_converter function in Bio/Cluster/clustermodule.c ?
 For example, I am really wondering what strlen(data) inside this function 
 returns on powerpc.
 
 Best,
 -Michiel.
 
 
 On Sat, 8/16/14, Andreas Tille andr...@an3as.eu wrote:
 
 Subject: Re: Bug#751277: python-biopython: FTBFS on mips* powerpc s390x
 To: Peter Cock p.j.a.c...@googlemail.com
 Cc: Dejan Latinovic dejan.latino...@imgtec.com, Michiel de Hoon 
 mjldeh...@yahoo.com, Biopython discussion list 
 biopyt...@lists.open-bio.org, 751...@bugs.debian.org 
 751...@bugs.debian.org, biopython-...@biopython.org 
 biopython-...@biopython.org
 Date: Saturday, August 16, 2014, 5:37 AM
 
 Hi Peter,
 
 On Thu, Aug 14, 2014 at
 09:52:40AM +0100, Peter Cock wrote:
 
 
1. waiting for
 your confirmation / patch
 
2. deactivating the specific test
3. exclude mips for
 biopython
4. ? any
 better idea ?
 
 In the current state all the work we spent in biopython
 over the last
 monthes will not
 migrate to testing for the simple reason that the
 current package in testing just does
 not run the test suite at build
 time and moreover python3 is not supported.
 
 Kind
 regards
 
   Andreas.
 
 I would suggest (2), deactivate this test
 (at least for for mips) as
 the most
 practical short term solution for the Debian packages.
 Or if you prefer (3), don't target
 mips for the Biopython package
 (yet).
 
 Medium
 term, I hope we can fix the C code to handle either
 Endian platform - option (1).
 
 It seems after having fixed
 the issue caused by wise we have one
 remaining problem:
 
   On powerpc[1] and s390x[2] test_Cluster
 fails even with Python 2.7 with:
 
 ==
 ERROR: test_clusterdistance
 (test_Cluster.TestCluster)
 --
 Traceback (most recent call last):
   File
 /«BUILDDIR»/python-biopython-1.64+dfsg/.pybuild/pythonX.Y_3.4/build/Tests/test_Cluster.py,
 line 212, in test_clusterdistance

 method='a', transpose=0)
 ValueError:
 method should be a single character
 
 ==
 ERROR: test_kcluster
 (test_Cluster.TestCluster)
 --
 Traceback (most recent call last):
   File
 /«BUILDDIR»/python-biopython-1.64+dfsg/.pybuild/pythonX.Y_3.4/build/Tests/test_Cluster.py,
 line 141, in test_kcluster

 method='a', dist='e')
 ValueError: method should be a single
 character
 
 ==
 ERROR: test_somcluster
 (test_Cluster.TestCluster)
 --
 Traceback (most recent call last):
   File
 /«BUILDDIR»/python-biopython-1.64+dfsg/.pybuild/pythonX.Y_3.4/build/Tests/test_Cluster.py,
 line 557, in test_somcluster

 inittau=0.02, niter=100, dist='e')
 ValueError: distance should be a single
 character
 
 ==
 ERROR: test_treecluster
 (test_Cluster.TestCluster)
 --
 Traceback (most recent call last):
   File
 /«BUILDDIR»/python-biopython-1.64+dfsg/.pybuild/pythonX.Y_3.4/build/Tests/test_Cluster.py,
 line 290, in test_treecluster

 transpose=0, method='a', dist='e')
 ValueError: method should be a single
 character
 
 --
 Ran 210 tests in 293.712 seconds
 
 FAILED (failures = 1)
 
 
 On sparc[3]
 there is a problem with dialign but sparc is no release
 architecture and wie might ignore this.  It
 might be a helpful hint
 anyway.
 
 Any hint for the test_Cluster
 problem?  If not I would also consider to
 hide it cowardly under the carpet for the
 moment.  The new package is so
 much better
 tested than the one in the testing distribution which
 does
 not even dare about any unit tests and
 only for this reason reached the
 testing
 distribution.
 
 What do you
 think?
 
 Kind regards
 

Andreas.
 
 scrool these links to the end to see the
 problem:
 
 [1] 
 https://buildd.debian.org/status/fetch.php?pkg=python-biopythonarch=powerpcver=1.64%2Bdfsg-3stamp=1408116532
 [2]

Bug#753893: RFS: rapid-photo-downloader/0.4.10-2 [ITA]

2014-08-18 Thread Eriberto

2014-08-18 2:14 GMT-03:00 Jörg Frings-Fürst deb...@jff-webhosting.net:
 Hola Eriberto,

Hi!

 Please, check all files, years, licenses and authors.
 Done.
  - Change years
  - Remove file entrys of non-existing files
  - Reorder sections

A very good work. However, the rapid/ValidatedEntry.py is using a MIT
license. As tip, when you see a unknown license, put some lines in
Google.

I am witing this last fix to upload.

Cheers,

Eriberto


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#758496: [Debian-astro-maintainers] Bug#758496: stellarium: Fails to start

2014-08-18 Thread Martin Ziegler


My computer is a Lenovo T510.  Stellarium's stderr gives


  OpenGL versions supported: 1.1, 1.2, 1.3, 1.4, 1.5, 2.0,
  2.1
  Driver version string: 2.1 Mesa 10.2.5
  GL vendor is Intel Open Source Technology Center
  GL renderer is Mesa DRI Intel(R) Ironlake Mobile 

as graphics driver and card. lshw describes the card as

  description: VGA compatible controller
  product: Core Processor Integrated Graphics Controller
  vendor: Intel Corporation

The graphics kernel driver is i915, with boot-options

  i915.i915_enable_fbc=1 i915.i915_enable_rc6=1
  i915.semaphores=1 i915.lvds_downclock=1

I attach stderr-Output and config.ini. According
to config.ini no plugins were used during startup.

Regards

Martin
 ---
[ This is Stellarium 0.13.0 - http://www.stellarium.org ]
[ Copyright (C) 2000-2014 Fabien Chereau et al  ]
 ---
Writing log file to: /home/ziegler/.stellarium/log.txt
File search paths:
  0 .  /home/ziegler/.stellarium
  1 .  /usr/share/stellarium
Config file is:  /home/ziegler/.stellarium/config.ini
OpenGL versions supported: 1.1, 1.2, 1.3, 1.4, 1.5, 2.0, 2.1
Driver version string: 2.1 Mesa 10.2.5
GL vendor is Intel Open Source Technology Center
GL renderer is Mesa DRI Intel(R) Ironlake Mobile 
Cache directory is:  /home/ziegler/.cache/stellarium/stellarium
Sky language is  de_DE
Application language is  de_DE
Loading Solar System data ...
Loading star data ...
Loading /usr/share/stellarium/stars/default/stars_0_0v0_5.cat: 0_0v0_2; 4963
Loading /usr/share/stellarium/stars/default/stars_1_0v0_5.cat: 1_0v0_2; 
21598
Loading /usr/share/stellarium/stars/default/stars_2_0v0_5.cat: 2_0v0_2; 
150090
Loading /usr/share/stellarium/stars/default/stars_3_1v0_3.cat: 3_1v0_3; 
428466
Finished loading star catalogue data, max_geodesic_level:  3
navigation/preset_sky_time is a double - treating as jday: 2.45154e+06
Loaded 10051 NGC records
Loading NGC name data ...
Loaded 416 / 416 NGC name records successfully
Loading star names from 
/usr/share/stellarium/skycultures/western/star_names.fab
Loaded 237 / 237 common star names
Loading star names from /usr/share/stellarium/stars/default/name.fab
Loaded 4359 / 4359 scientific star names
Loading variable stars from 
/usr/share/stellarium/stars/default/gcvs_hip_part.dat
Loaded 6886 / 6886 variable stars
Loaded 88 / 88 constellation records successfully for culture western
Loaded 85 / 85 constellation art records successfully for culture western
Loaded 89 / 89 constellation names
Loading constellation boundary data ... 
Loaded 782 constellation boundary segments
Intializing basic GL shaders... 
Creating GUI ...

[astro]
flag_bright_nebulae = false
flag_light_travel_time  = false
flag_milky_way  = true
flag_nebula = true
flag_nebula_display_no_texture  = false
flag_nebula_long_name   = false
flag_nebula_name= false
flag_nebula_ngc = false
flag_object_trails  = false
flag_planets= true
flag_planets_hints  = true
flag_planets_orbits = false
flag_star_name  = true
flag_stars  = true
flag_telescope_name = false
flag_telescopes = false
labels_amount   = 3.0
max_mag_nebula_name = 8
meteor_rate = 10
milky_way_intensity = 1
nebula_hints_amount = 3.0
nebula_scale= 1

[color]
azimuthal_color = 0.3,0.2,0.1
cardinal_color  = 0.77,0.22,0.1
const_boundary_color= 0.3,0.1,0.1
const_lines_color   = 0.13,0.19,0.24
const_names_color   = 0.31,0.38,0.46
default_color   = 0.458,0.509,0.671
ecliptic_color  = 0.6,0.2,0.2
equator_color   = 0.2,0.2,0.6
equatorial_J2000_color  = 0.1,0.3,0.4
equatorial_color= 0.1,0.2,0.3
gui_base_color  = 0.458,0.509,0.671
gui_text_color  = 0.8,0.87,0.87
meridian_color  = 0.2,0.6,0.2
nebula_circle_color = 1.0,0.68,0.20
nebula_label_color  = 0.15,0.65,0.65
object_trails_color = 1,0.7,0
planet_names_color  = 0.46,0.51,0.67
planet_orbits_color = 0.69,0.2,0.2
star_label_color= 0.4,0.3,0.5
telescope_circle_color  = 0.6,0.4,0
telescope_label_color   = 0.6,0.4,0

[gui]
auto_hide_horizontal_toolbar= true
auto_hide_vertical_toolbar  = true
base_font_name  = DejaVuSans.ttf
base_font_size  = 14
day_key_mode= calendar

Bug#757243: RFS: qmapshack/0.2.0+ds1-1

2014-08-18 Thread Sebastiaan Couwenberg

On 08/18/2014 08:52 AM, Tobias Frost wrote:
 Hi Sebastiaan, 
 
 On Sun, 2014-08-17 at 23:57 +0200, Sebastiaan Couwenberg wrote:
 On 08/17/2014 10:55 PM, Tobias Frost wrote:
 Regarding the patch: I'm not near a PC right now, so can't check: Are you 
 sure the license of those files with the exception had a or later on 
 their GPL option?

 I'm pretty sure about that. The QT project licensing page links to the
 licenses as published by the FSF which contain the or later part.
 Furthermore the LICENSE.LGPL and LICENSE.GPL files contained in QT
 projects contain or (at your option) any later version.
 
 No I disagee. You cannot refer to the published complete license text
 here;
 LICENSE.GPL begins with 
 Everyone is permitted to copy and distribute verbatim copies
  of this license document, but changing it is not allowed.
 so one can be sure that it is not modified for the purpose to have the
 or later option. As there is no no-later veision of the license file,
 we have to read on.
 
 Later in the license the or-later-option is introduced:
 Each version is given a distinguishing version number.  If the Program
 specifies a version number of this License which applies to it and any
 later version, you have the option of following the terms and
 conditions either of that version or of any later version published by
 the Free Software Foundation.
 
 The files in question do *NOT* have the any later version specified,
 so the AND evaluated to false and it does not apply. That means you have
 only GPL-3 as option. 
 
 As licenses are bound to the specific artifact, it is very dangerous to
 say other packages using QT do it this way.  
 
 Looking at
 http://qt-project.org/doc/qt-5/qtwidgets-richtext-textedit-textedit-cpp.html
 (looks like the source of the file), and on 
 http://qt-project.org/doc/qt-5/licensing.html I don't see any or later
 option too. (However, this would be only an addtional, non-authoritive
 datapoint anyway, as the only thing that counts is the text in the
 artifact)

The license header in the artifact doesn't state the or later, but
refers to the license as published by the FSF which does include it:


 ** GNU Lesser General Public License Usage
 ** Alternatively, this file may be used under the terms of the GNU Lesser
 ** General Public License version 2.1 as published by the Free Software
 ** Foundation and appearing in the file LICENSE.LGPL included in the
 ** packaging of this file.  Please review the following information to
 ** ensure the GNU Lesser General Public License version 2.1 requirements
 ** will be met: http://www.gnu.org/licenses/old-licenses/lgpl-2.1.html.
 **
 ** In addition, as a special exception, Digia gives you certain additional
 ** rights.  These rights are described in the Digia Qt LGPL Exception
 ** version 1.1, included in the file LGPL_EXCEPTION.txt in this package.
 **
 ** GNU General Public License Usage
 ** Alternatively, this file may be used under the terms of the GNU
 ** General Public License version 3.0 as published by the Free Software
 ** Foundation and appearing in the file LICENSE.GPL included in the
 ** packaging of this file.  Please review the following information to
 ** ensure the GNU General Public License version 3.0 requirements will be
 ** met: http://www.gnu.org/copyleft/gpl.html.


The full license text is not included in the header, but is deferred to
the license as published by the FSF. Since the licenses as published by
the FSF include or (at your option) any later version GPL-3+ applies.

QT projects include the LICENSE.GPL and LICENSE.LGPL files as referred
to in the header, but these are not included in qmapshack as they are in
QT projects. The LICENSE.GPL and LICENSE.LGPL files included in QT
projects are verbatim copies of the licenses as published by the FSF
which includes or (at your option) any later version.

The QT code included in qmapshack is taken from the QT examples, and the
license applied to that include or (at your option) any later version:

https://qt-project.org/doc/qt-4.7/demos-textedit-textedit-cpp.html
https://qt-project.org/doc/qt-4.7/licensing.html
https://qt-project.org/doc/qt-4.7/gpl.html
https://qt-project.org/doc/qt-4.7/lgpl.html

 Regarding  the commercial option: I wouldn't leave it out, as IMHO 
 d/copyright should be a exact representation on the license, even if a 
 option is not really applicable. 

 I agree in general, but we're not able to document the text of the
 commercial license.
 
 Thats not the point. The message is There is a third license option
 available which are individually negotiated. See the URL for details or
 contact us Details on the license are not necessary and the don't
 impact the use under the other license options.

Leaving out the commercial licensing option is not ideal indeed. I
suggest to include the license header in the d/copyright as a comment
and keep the individual license specifications as they are now:

Files: src/helpers/CTextEditWidget.cpp

Bug#575395: [debdiff] Option to compare only packaging files when comparing .dscs

2014-08-18 Thread Eriberto Mota

Hi!

I found this message in Google. There is a definitive solution?

Regards,

Eriberto


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#758513: [Pkg-nagios-devel] Bug#758513: fails to authenticate if multiple LDAP results match, misleading error message

2014-08-18 Thread Alexander Wirt

On Mon, 18 Aug 2014, Daniel Pocock wrote:

 Package: nagios3
 
 Not sure if this log message comes from Apache or from Nagios, if it is
 an Apache error then please re-assign to the Apache package.
 
 Basically, my Nagios was working fine with Apache LDAP
During the authentication phase, mod_auth_ldap searches for an entry in the
directory that matches the username that the HTTP client passes. If a single
unique match is found, then mod_auth_ldap attempts to bind to the directory
server using the DN of the entry plus the password provided by the HTTP
client. Because it does a search, then a bind, it is often referred to as the
search/bind phase. Here are the steps taken during the search/bind phase.

single unique match is the point here. So the problem is on your side,
not on apache nor on icingas side. 

So I fail to see a bug here.

Feel free to close the bug or reassign it somewhere else, but I am not able
to find something to ressign it to.

Alex


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#741303: libfeel++1: libfeelpp.so.1.0.0 links with both GPL-licensed and GPL-incompatible libraries

2014-08-18 Thread Christophe Prud'homme

severity 741303 important
thanks

Feel++ links with petsc which has the same bug [1] and I feel quite the
same as Anton about the situation
1. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=741196

Waiting for ftpmaster to take a decision.

Best regards
C.

On Wed, Mar 26, 2014 at 10:19 PM, Francesco Poli invernom...@paranoici.org
wrote:

On Wed, 26 Mar 2014 15:52:34 +0100 Christophe Prud'homme wrote:

Dear Francesco Poli

Hello Christophe,
thanks for commenting my bug report.

What is the state of this bug ? any progress with respect to scotch
licensing ?

I am not aware of any progress: I am the bug report submitter and, as I
said in the original bug report, I need help from other people who
volunteer to get in touch with the upstream developer of SCOTCH and
persuade him to re-license SCOTCH under the LGPL.
I have already tried to do so in the past, but I failed to convince him
that there is an issue.

Please (re-)read https://bugs.debian.org/740463#5 for the full story.

Are you willing to help?

If so, please contact the main author of SCOTCH and explain the
licensing headaches he is causing to several other projects.
If you manage to persuade him (to get the necessary paperwork) to
re-license SCOTCH under the LGPL v2.1 or, at least, to dual-license it
under the GNU LGPL v2.1 or the CeCILL-C v1.0 (at the recipient's
choice), all the GPL-incompatibility issues will instantly vanish!

this is a really painful situation !

Indeed.

are petsc and all libraries (based on umfpack) related to this bug issues
marked for removal from testing ?

By looking at http://udd.debian.org/cgi-bin/autoremovals.cgi
it seems to me that feel++ and getdp are marked for auto-removal from
Debian testing, while other packages affected by SCOTCH licensing
issues are not (yet?) on the list.
I am not sure why (maybe because they are not leaf packages?).

The complete list of SCOTCH licensing bug reports is

https://bugs.debian.org/cgi-bin/pkgreport.cgi?archive=both;tag=scotch-license-issues;users=debian-science-maintain...@lists.alioth.debian.org

have you marked also octave with an RC bug ? it uses suitesparse/umfpack
and scotch [1]

Could you please elaborate?
I cannot spot the dependency of octave on scotch...

Basically all libraries/programs using suitesparse/umfpack should have
this
bug, no ?

Only when they contain a file which (directly or indirectly) links with
both SCOTCH and some GPL-licensed library (such as UMFPACK)...

I think Libreoffice/Openoffice are using suitesparse(and scotch) and
glpk
so it should also have the RC bug.

libreoffice? glpk?
Could you please help me to find the dependency on scotch? I fail to
see it...

I guess that the technical solution would be to get rid of umfpack but
then
that would disrupt a lot of software !

I think I clearly illustrated the solutions that I consider as
acceptable: see my original bug report(s).
Solution (A) is the most desirable, that's why I called for help to
push in that direction...

I hope this clarifies.

--
http://www.inventati.org/frx/frx-gpg-key-transition-2010.txt
New GnuPG key, see the transition document!
. Francesco Poli .
GnuPG key fpr == CA01 1147 9CD2 EFDF FB82 3925 3E1C 27E1 1F69 BFFE

Bug#758514: chromium pepperflash doesn't exit

2014-08-18 Thread Harald Dunkel

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Package: chromium
Version: 35.0.1916.153-2

If I close the last tab, then chromium doesn't exit, but keeps 8 jobs running:

% ps -ef | grep chromiu[m]
harri25759  4721  7 14:19 pts/200:00:00 /usr/lib/chromium/chromium 
--password-store=detect 
--ppapi-flash-path=/usr/lib/pepperflashplugin-nonfree/libpepflashplayer.so 
--ppapi-flash-version=14.0.0.125
harri25769 25759  0 14:19 pts/200:00:00 /usr/lib/chromium/chromium 
--password-store=detect 
--ppapi-flash-path=/usr/lib/pepperflashplugin-nonfree/libpepflashplayer.so 
--ppapi-flash-version=14.0.0.125 --type=sandbox-ipc
harri25770 25759  0 14:19 pts/200:00:00 
/usr/lib/chromium/chrome-sandbox /usr/lib/chromium/chromium --type=zygote 
--ppapi-flash-path=/usr/lib/pepperflashplugin-nonfree/libpepflashplayer.so 
--ppapi-flash-version=14.0.0.125
harri25771 25770  0 14:19 pts/200:00:00 /usr/lib/chromium/chromium 
--type=zygote 
--ppapi-flash-path=/usr/lib/pepperflashplugin-nonfree/libpepflashplayer.so 
--ppapi-flash-version=14.0.0.125
harri25775 25771  0 14:19 pts/200:00:00 /usr/lib/chromium/chromium 
--type=zygote 
--ppapi-flash-path=/usr/lib/pepperflashplugin-nonfree/libpepflashplayer.so 
--ppapi-flash-version=14.0.0.125
harri25801 25759  8 14:19 pts/200:00:01 /usr/lib/chromium/chromium 
--type=gpu-process --channel=25759.0.162146789 --supports-dual-gpus=false 
--gpu-driver-bug-workarounds=1,13,19,22,39 --disable-accelerated-video-decode 
--gpu-vendor-id=0x10de --gpu-device-id=0x0de1
- --gpu-driver-vendor=NVIDIA --gpu-driver-version=340.24
harri25810 25801  0 14:19 pts/200:00:00 /usr/lib/chromium/chromium 
--type=gpubroker

harri25823 25775  0 14:19 pts/200:00:00 /usr/lib/chromium/chromium 
--type=renderer --lang=en-US
-
--force-fieldtrials=Prerender/PrerenderEnabled/UMA-Session-Randomized-Uniformity-Trial-5-Percent/group_08/UMA-Uniformity-Trial-1-Percent/group_25/UMA-Uniformity-Trial-10-Percent/default/UMA-Uniformity-Trial-100-Percent/group_01/UMA-Uniformity-Trial-20-Percent/default/UMA-Uniformity-Trial-5-Percent/group_16/UMA-Uniformity-Trial-50-Percent/group_01/
- --extension-process 
--ppapi-flash-path=/usr/lib/pepperflashplugin-nonfree/libpepflashplayer.so 
--ppapi-flash-version=14.0.0.125 --enable-threaded-compositing 
--enable-delegated-renderer --disable-accelerated-video-decode 
--enable-software-compositing --channel=25759.2.170909645


All extensions are disabled.

Would it be possible to get a version without pepperflash in a
chromium-non-flash package?


Regards
Harri
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAEBCAAGBQJT8fG2AAoJEAqeKp5m04HLKlUH/1AcLqw+pk3lLvz5P0Pan2yB
0UjklWPQ/WD8QYSDeo0BHuCaEJ9L1blw8U3VefmXMjL2ePHvEN8X4AfwJVpqFDMJ
cNop1EWrJgi+swRMbMwvNCJel1W5phjepYCWhQVeNU+330+PNz3KGgiI09PET9VF
I2BkfkLt6hE6du/bKY1nwPObcg1HxfrmyYoHQV22fBtkWAOwtAPjlbZ8/w3ywOdF
MnvipHljrLuSgpvraDQDBKvwmuvOZRIrW7yL/2PW9tEjyWvK1AXN/rCb2pNtBxzD
bdhGMC/BpXMQfyFL7pWtVAuaALhkz5lpnDOt2PtEddVGowQL7RupJAUhl9XNow4=
=fZ6o
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#757243: RFS: qmapshack/0.2.0+ds1-1