date:20140809

Bug#757360: Confusing version, please follow upstream version tags

2014-08-09 Thread Volker Schroer


Hi,

one should differ
the version of gnuradio gr-fcdproplus is suitable for
and the version of gr-fcdproplus.

At the moment the master branch is suitable for gnuradio 3.7.x and there 
exits an older  3.6 branch suitable for 3.6 .


There are tags for the 3.6 and the 3.7 releases but they don't reflect 
updates.

So what about using branches (3.6 , 3.7) to make the dependency clearer.
though it's already fixed in the CMakeList.txt
 ( find_package(Gnuradio 3.7)

In addition I could try to add the version of gnuradio the lib is build 
against to the library name.


Would this help ?


-- Volker


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

Bug#757548: Please switch to libvirt-daemon-system

2014-08-09 Thread Guido Günther

Source: nova
Version: 2014.1.1-8
Severity: wishlist
Tags: patch

Hi,
The libvirt package has been split to allow installation without 
the libvirtd daemon running as root. The package that ensures
that libvird is running as root (providing qemu:///system and lxc:///)
is now called libvirt-daemon-system. The attached patch changes
the dependencies accordingly. It'd be great if this could be applied.

To be on the safe side you could also depend on libvirt-daemon-system
| libvirt-bin and use Should-Start: libvirtd libvirt-bin but since a
version in backports will be available too this isn't necessary.

Cheers,
 -- Guido
From 966cb1f28acce048984540e31104edefa7592adf Mon Sep 17 00:00:00 2001
Message-Id: 966cb1f28acce048984540e31104edefa7592adf.1407534200.git@sigxcpu.org
From: =?UTF-8?q?Guido=20G=C3=BCnther?= a...@sigxcpu.org
Date: Fri, 8 Aug 2014 23:37:28 +0200
Subject: [PATCH] Switch to libvirt-daemon-system instead of libvirt-bin

libvirt-bin is now a transitional package, use libvirt-daemon-system
instead.
---
 debian/control   | 10 +-
 debian/nova-compute.init |  4 ++--
 2 files changed, 7 insertions(+), 7 deletions(-)

diff --git a/debian/control b/debian/control
index ea569c8..8aaff30 100644
--- a/debian/control
+++ b/debian/control
@@ -17,7 +17,7 @@ Build-Depends: debhelper (= 9),
 Build-Depends-Indep: bpython,
  euca2ools,
  ipython,
- libvirt-bin,
+ libvirt-daemon-system,
  openssh-client,
  procps,
  pylint,
@@ -227,7 +227,7 @@ Architecture: all
 Pre-Depends: dpkg (= 1.15.6~)
 Depends: adduser,
  dpkg-dev,
- libvirt-bin,
+ libvirt-daemon-system,
  nova-common,
  nova-compute,
  python-libvirt,
@@ -257,7 +257,7 @@ Architecture: all
 Pre-Depends: dpkg (= 1.15.6~)
 Depends: adduser,
  dpkg-dev,
- libvirt-bin,
+ libvirt-daemon-system,
  nova-common,
  nova-compute,
  python-libvirt,
@@ -313,7 +313,7 @@ Architecture: all
 Pre-Depends: dpkg (= 1.15.6~)
 Depends: adduser,
  dpkg-dev,
- libvirt-bin,
+ libvirt-daemon-system,
  nova-common,
  nova-compute,
  python-libvirt,
@@ -345,7 +345,7 @@ Pre-Depends: dpkg (= 1.15.6~)
 Depends: adduser,
  dpkg-dev,
  qemu-kvm | kvm,
- libvirt-bin,
+ libvirt-daemon-system,
  nova-common,
  nova-compute,
  python-libvirt,
diff --git a/debian/nova-compute.init b/debian/nova-compute.init
index 7876c18..b4b65f1 100644
--- a/debian/nova-compute.init
+++ b/debian/nova-compute.init
@@ -3,8 +3,8 @@
 # Provides:  nova-compute
 # Required-Start:$network $local_fs $remote_fs $syslog
 # Required-Stop: $remote_fs
-# Should-Start:  libvirtd libvirt-bin postgresql mysql keystone rabbitmq-server ntp
-# Should-Stop:   libvirtd libvirt-bin postgresql mysql keystone rabbitmq-server ntp
+# Should-Start:  libvirtd postgresql mysql keystone rabbitmq-server ntp
+# Should-Stop:   libvirtd postgresql mysql keystone rabbitmq-server ntp
 # Default-Start: 2 3 4 5
 # Default-Stop:  0 1 6
 # Short-Description: Nova Compute server
-- 
2.0.1

Bug#757549: owncloud: DB-Errors on Migration 6.0.3 to 7.0.0

2014-08-09 Thread Tom Fernandes

Package: owncloud
Version: 7.0.0+dfsg-2~bpo70+2
Severity: normal

Dear Maintainer,

I upgraded OC from 6.0.3+dfsg-2~bpo70+1 to 7.0.0+dfsg-2~bpo70+2 and then
went to my OC-website. I was prompted for clicking to run the update,
which I did. Then it said there was an error and that I should report
this to the community.

The postgres-log says:
ERROR:  relation oc_share_external already exists
STATEMENT:  CREATE TABLE oc_share_external (id SERIAL NOT NULL,
remote VARCHAR(512) NOT NULL, share_token VARCHAR(64) NOT NULL,
password VARCHAR(64) NOT NULL, name VARCHAR(64) NOT NULL, owner
VARCHAR(64) NOT NULL, user VARCHAR(64) NOT NULL, mountpoint
VARCHAR(4000) NOT NULL, mountpoint_hash VARCHAR(32) NOT NULL, PRIMARY
KEY(id))

The OC-log reports:
ailed to update database structure (exception 'PDOException' with
message 'SQLSTATE[42P07]: Duplicate table: 7 ERROR: relation
oc_share_external already exists' in
/usr/share/php/Doctrine/DBAL/Connection.php:801 Stack trace: #0
/usr/share/php/Doctrine/DBAL/Connection.php(801): PDO-query('CREATE
TABLE o...') #1 /usr/share/owncloud/lib/private/db/migrator.php(179):
Doctrine\DBAL\Connection-query('CREATE TABLE o...') #2
/usr/share/owncloud/lib/private/db/migrator.php(35):
OC\DB\Migrator-applySchema(Object(Doctrine\DBAL\Schema\Schema)) #3
/usr/share/owncloud/lib/private/db/mdb2schemamanager.php(98):
OC\DB\Migrator-migrate(Object(Doctrine\DBAL\Schema\Schema)) #4
/usr/share/owncloud/lib/private/db.php(320):
OC\DB\MDB2SchemaManager-updateDbFromStructure('/usr/share/ownc...') #5
/usr/share/owncloud/lib/private/app.php(1172):
OC_DB::updateDbFromStructure('/usr/share/ownc...') #6
/usr/share/owncloud/lib/private/app.php(980):
OC_App::updateApp('files_sharing') #7
/usr/share/owncloud/lib/private/app.php(87):
OC_App::checkUpgrade('files_sharing') #8
/usr/share/owncloud/lib/private/app.php(72):
OC_App::loadApp('files_sharing') #9
/usr/share/owncloud/lib/private/updater.php(222): OC_App::loadApps() #10
/usr/share/owncloud/lib/private/updater.php(137):
OC\Updater-doUpgrade('7.0.0.8', '6.0.3.1') #11
/usr/share/owncloud/core/ajax/update.php(35): OC\Updater-upgrade() #12
{main} Next exception 'Doctrine\DBAL\DBALException' with message 'An
exception occurred while executing 'CREATE TABLE oc_share_external
(id SERIAL NOT NULL, remote VARCHAR(512) NOT NULL, share_token
VARCHAR(64) NOT NULL, password VARCHAR(64) NOT NULL, name
VARCHAR(64) NOT NULL, owner VARCHAR(64) NOT NULL, user VARCHAR(64)
NOT NULL, mountpoint VARCHAR(4000) NOT NULL, mountpoint_hash
VARCHAR(32) NOT NULL, PRIMARY KEY(id))': SQLSTATE[42P07]: Duplicate
table: 7 ERROR: relation oc_share_external already exists' in
/usr/share/php/Doctrine/DBAL/DBALException.php:91 Stack trace: #0
/usr/share/php/Doctrine/DBAL/Connection.php(811):
Doctrine\DBAL\DBALException::driverExceptionDuringQuery(Object(PDOException),
'CREATE TABLE o...') #1
/usr/share/owncloud/lib/private/db/migrator.php(179):
Doctrine\DBAL\Connection-query('CREATE TABLE o...') #2
/usr/share/owncloud/lib/private/db/migrator.php(35):
OC\DB\Migrator-applySchema(Object(Doctrine\DBAL\Schema\Schema)) #3
/usr/share/owncloud/lib/private/db/mdb2schemamanager.php(98):
OC\DB\Migrator-migrate(Object(Doctrine\DBAL\Schema\Schema)) #4
/usr/share/owncloud/lib/private/db.php(320):
OC\DB\MDB2SchemaManager-updateDbFromStructure('/usr/share/ownc...') #5
/usr/share/owncloud/lib/private/app.php(1172):
OC_DB::updateDbFromStructure('/usr/share/ownc...') #6
/usr/share/owncloud/lib/private/app.php(980):
OC_App::updateApp('files_sharing') #7
/usr/share/owncloud/lib/private/app.php(87):
OC_App::checkUpgrade('files_sharing') #8
/usr/share/owncloud/lib/private/app.php(72):
OC_App::loadApp('files_sharing') #9
/usr/share/owncloud/lib/private/updater.php(222): OC_App::loadApps() #10
/usr/share/owncloud/lib/private/updater.php(137):
OC\Updater-doUpgrade('7.0.0.8', '6.0.3.1') #11
/usr/share/owncloud/core/ajax/update.php(35): OC\Updater-upgrade() #12
{main}) 


My OC-instance seems to work fine, but I feel uneasy if the DB-migration
executed fine in the end.
I did not find a way to re-run the upgrade or to verify the status of
the system.

Is there a way to check if the upgrade/migration worked correctly?

Warm regards and thanks for the good work,


Tom

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

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

Versions of packages owncloud depends on:
ii  fonts-font-awesome   3.2.1~dfsg-2~bpo7+1
ii  fonts-liberation 1.07.2-6
ii  fonts-linuxlibertine 5.1.3-1
ii  fonts-lohit-deva 2.5.1-1
ii  fonts-sil-gentium-basic  1.1-5
ii  fonts-wqy-microhei   0.2.0-beta-2~bpo70+1
ii  libjs-chosen 0.9.11-1~bpo7+1
ii  libjs-dojo-dojox 1.7.2+dfsg-1
ii  libjs-jcrop  0.9.12+dfsg-1~bpo70+1
ii  libjs-jquery-minicolors

Bug#755947: I switched to youtube-dl

2014-08-09 Thread 積丹尼 Dan Jacobson

OK I switched to youtube-dl. That works in this case.


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

Bug#750022: slapd: offer mdb backend in configuration

2014-08-09 Thread Ryan Tandy


On 31/05/14 12:34 PM, Ryan Tandy wrote:

The LMDB backend is now considered stable, and in 2.4.40 upstream will
start to recommend it over hdb as the default backend. For jessie I'd
like for it to at least be included as an option in the debconf menus.


Trivial example of how that might look (modulo a debconf-updatepo) attached.


The default maxsize for back-mdb is 10 MiB, only enough (IMO) for a toy
database. I think we should configure it higher, but I'm not sure how
high. On 32-bit systems there is only so much address space available.


How about a default of 1 GiB? That should fit in the 32-bit address 
space but is still significantly larger than any casual user is likely 
to have. We should document the size restriction, though, and if 
possible provide an example of a cron job to monitor it.



I predict, though, that offering mdb as a configuration choice is going
to result in a lot of people asking for dpkg-reconfigure to be able to
change the backend of an existing database (ie. #599585)...


Actually, AFAICT dpkg-reconfigure is happy to create a new database with 
a different backend. Will follow that bug up separately.



I don't know what the format stability of mdb is like (ie. whether, or
when, a dump/reload is required). I will look into that.


IIRC, in 2.4.40 there is a forward-incompatible change: upgrades to 
2.4.40 are fine but going back requires a reload. Can't find an ITS 
reference right now: might have been an IRC discussion (wishing I kept 
better logs) or maybe my brain is starting to invent things...


The disk format will not change backward-incompatibly in 2.4, but it 
sounds like it will at the transition to 2.5. ([ITS#7713] is an example 
of a format-breaking change.)


[ITS#7713] http://www.openldap.org/its/?findid=7713

Out of time for tonight and probably for the weekend, looking forward to 
Debconf where I might have some bigger blocks of time for this...


cheers,
Ryan
From 9e87486c2934c6321fcc76266833904525ace500 Mon Sep 17 00:00:00 2001
From: Ryan Tandy r...@nardis.ca
Date: Fri, 8 Aug 2014 21:29:57 -0700
Subject: [PATCH 1/2] re-introduce @BACKENDOPTIONS@ for mdb

---
 debian/slapd.init.ldif  |  5 +
 debian/slapd.scripts-common | 15 +++
 2 files changed, 12 insertions(+), 8 deletions(-)

diff --git a/debian/slapd.init.ldif b/debian/slapd.init.ldif
index 6a237e0..6fefcae 100644
--- a/debian/slapd.init.ldif
+++ b/debian/slapd.init.ldif
@@ -62,10 +62,7 @@ objectClass: olcDatabaseConfig
 objectClass: @BACKENDOBJECTCLASS@
 olcDatabase: @BACKEND@
 olcDbCheckpoint: 512 30
-olcDbConfig: set_cachesize 0 2097152 0
-olcDbConfig: set_lk_max_objects 1500
-olcDbConfig: set_lk_max_locks 1500
-olcDbConfig: set_lk_max_lockers 1500
+@BACKENDOPTIONS@
 olcLastMod: TRUE
 olcSuffix: @SUFFIX@
 olcDbDirectory: /var/lib/ldap
diff --git a/debian/slapd.scripts-common b/debian/slapd.scripts-common
index 5427204..5d671b5 100644
--- a/debian/slapd.scripts-common
+++ b/debian/slapd.scripts-common
@@ -460,15 +460,21 @@ create_new_slapd_conf() {		# {{{
 # Create the new slapd.d directory (configuration)
 # Usage: create_new_slapd_conf basedn backend
 
-	local initldif failed basedn backend backendobjectclass adminpass
+	local initldif failed basedn backend backendobjectclass backendoptions adminpass
 
 	# Fetch configuration
 	basedn=$1
 	backend=$2
-	if [ $backend = hdb ]; then
-		backendobjectclass=olcHdbConfig
+	if [ $backend = mdb ]; then
+		backendoptions=olcDbMaxSize: 1073741824
+		backendobjectclass=olcMdbConfig
 	else
-		backendobjectclass=olcBdbConfig
+		backendoptions=olcDbConfig: set_cachesize 0 2097152 0\nolcDbConfig: set_lk_max_objects 1500\nolcDbConfig: set_lk_max_locks 1500\nolcDbConfig: set_lk_max_lockers 1500
+		if [ $backend = hdb ]; then
+			backendobjectclass=olcHdbConfig
+		else
+			backendobjectclass=olcBdbConfig
+		fi
 	fi
 	db_get slapd/internal/adminpw
 	adminpass=$RET
@@ -484,6 +490,7 @@ create_new_slapd_conf() {		# {{{
 	# Change some defaults
 	sed -i -e s|@BACKEND@|$backend|g ${initldif}
 	sed -i -e s|@BACKENDOBJECTCLASS@|$backendobjectclass|g ${initldif}
+	sed -i -e s|@BACKENDOPTIONS@|$backendoptions|g ${initldif}
 	sed -i -e s|@SUFFIX@|$basedn|g ${initldif}
 	sed -i -e s|@PASSWORD@|$adminpass|g ${initldif}
 
-- 
2.1.0.rc1

From 4de312cd174bc4aad91a92f3d1a186a8515392b9 Mon Sep 17 00:00:00 2001
From: Ryan Tandy r...@nardis.ca
Date: Fri, 8 Aug 2014 21:30:15 -0700
Subject: [PATCH 2/2] add MDB backend in debconf choices

---
 debian/slapd.templates | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/debian/slapd.templates b/debian/slapd.templates
index 551e881..0a1c5d5 100644
--- a/debian/slapd.templates
+++ b/debian/slapd.templates
@@ -131,13 +131,17 @@ _Description: slapcat failure during upgrade
 
 Template: slapd/backend
 Type: select
-Choices: BDB, HDB
+Choices: BDB, HDB, MDB
 Default: HDB
 _Description: Database backend to use:
  The HDB backend is recommended. HDB and BDB use similar storage formats,
  but HDB adds

Bug#754384: php5-fpm: Apache2 + php5-fpm using fastcgi breaks after upgrading to 5.6.0~rc2+dfsg-1

2014-08-09 Thread David Zuelke

New PR for PHP to fix the breakage: https://github.com/php/php-src/pull/765

On 12 Jul 2014, at 22:46, Lars Veldscholte l...@tuxplace.nl wrote:

 OK, so mod_fastcgi is deprecated.
 
 If I switch to mod_proxy_fcgi with mod_proxy_handler like this:
 
 FilesMatch \.php$
SetHandler proxy:fcgi://127.0.0.1:9000/
 /FilesMatch
 
 I won't have the problems I encountered when I used mod_proxy_fcgi with
 mod_proxy, right? (Like this:)
 
 ProxyPassMatch ^/(.*\.php(/.*)?)$
 fcgi://127.0.0.1:9000/path/to/your/documentroot/$1
 
 If so, I guess I'm gonna try that.
 


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

Bug#735884: Review of debian/copyright for ocp-indent

2014-08-09 Thread Johannes Schauer

Hi Andreas,

Quoting Andreas Cadhalpun (2014-08-09 00:48:05)
You introduced a default copyright for INRIA, Jun Furuse and OCamlPro
where I tried to name files individually to match the different copyrights.
For example the only files that are copyright INRIA seem to be
src/approx_tokens.ml, src/approx_lexer.mll and src/approx_common.mli so I
don't see how INRIA can be in the default block.

There had been no general 'Files: *' stanza and some files (like
Makefile etc.) had not been mentioned explicitly. Therefore I created
the default stanza with the license mentioned in the LICENSE file.

correct, this indeed makes a 'Files: *' stanza necessary or some files will not
be matched.

To shorten debian/copyright I merged all the files under this license
into this stanza, which thus mentions all copyright holders.
But if you prefer to list some of them, e.g. those with copyright INRIA,
separately, that is also fine.

[...]

Merging all the copyright holders and dates into the default stanza doesn't
mean that all the files are copyrighted by all the listed copyright holders
with the same dates, but rather that at least one of them is copyrighted by
at least one of these copyright holders with one of the dates.

The copyright format specification makes it clear that whether to merge
or not is just a matter of taste:
Since the license of the manual pages is the same as the other files in
the package, the last paragraph above could instead be combined with the
first paragraph, listing both copyright statements in one Copyright
field. Whether to combine paragraphs with the same license is left to
the discretion of the author of the debian/copyright file. [a]

Okay, I see. Then I agree that merging those stanzas makes things much more
maintainable and readable.

You're welcome. By the way, I just notice that 'BSD-3-clause' should have
been 'BSD-3-Clause' (with capital C) as recommended by the copyright format
specification.

Indeed. Thanks, I changed that too.

As these have rather permissive licenses, it wouldn't hurt to leave them and
just document there existence in debian/copyright. But if you prefer, it's
also fine to remove them via Files-Excluded.

I'll cater for that in a later release.

I noticed something else: when you added tests/passing/traverse.mli as being
licensed under AGPL-3, is it not necessary to paste the full text of the AGPL-3
because the AGPL cannot be found in /usr/share/common-licenses? I added the
text of the AGPL-3 to debian/copyright to fulfill policy § 12.5.

You can find the full diff of the changes in:
http://anonscm.debian.org/cgit/pkg-ocaml-maint/packages/ocp-indent.git/commit/?id=3316070c3164a14926abd9fcba46b88b8419640c

1 2 3 >

1 - 100 of 273 matches

Mail list logo