Bug#888656: flowcanvas: should this package be removed? (superseded by ganv)

2018-01-28 Thread Simon McVittie 
Source: flowcanvas
Severity: important
User: debian...@lists.debian.org
Usertags: proposed-removal
Control: clone -1 -2
Control: reassign -2 ladish
Control: retitle -2 ladish: should this package be removed?

flowcanvas depends on numerous obsolete GNOME 2-era libraries
(e.g. #885095) and hasn't had a maintainer upload since 2009. Its upstream
website says:

**Note**: FlowCanvas is dead, long live Ganv!

ganv is also in Debian as src:ganv; it's orphaned in Debian, but appears
to have commit activity upstream.

flowcanvas has one reverse-dependency in Debian, gladish (src:ladish),
whose most recent maintainer upload was in 2014. web.archive.org says
the ladish.org website has been down since mid 2014.

These packages both seem like candidates for removal from unstable.
If you agree, please reassign this bug to the ftp team with
cont...@bugs.debian.org commands similar to these:

severity xx normal
reassign xx ftp.debian.org
retitle xx RM: flowcanvas -- RoQA; depends on obsolete libraries, 
superseded by ganv

severity yy normal
reassign yy ftp.debian.org
retitle yy RM: ladish -- RoQA; depends on obsolete libraries, appears 
unmaintained upstream

(replacing RoQA with RoM if you are a maintainer of the appropriate package).

Thanks,
smcv

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

Bug#868612: mixxx: diff for NMU version 2.0.0~dfsg-7.1

2017-07-24 Thread Simon McVittie 
On Mon, 24 Jul 2017 at 14:04:03 +0200, Mattia Rizzolo wrote:
> I've merged your changes and added a tag to the git repository; please
> feel free to reschedule it to delayed/0.

Thanks, done (assuming I got my dcut syntax right).

S

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

Bug#868612: mixxx: diff for NMU version 2.0.0~dfsg-7.1

2017-07-24 Thread Simon McVittie 
Control: tags 868612 + patch pending

I've prepared an NMU for mixxx (versioned as 2.0.0~dfsg-7.1)
incorporating the patch from James Cowgill for #868612 and the pending
change from pkg-multimedia git, and uploaded it to DELAYED/2. Please
feel free to tell me if I should delay it longer.

The changes can also be fetched from the 'nmu' branch in this git
repository: https://anonscm.debian.org/git/users/smcv/mixxx.git

Regards,
S
diffstat for mixxx-2.0.0~dfsg mixxx-2.0.0~dfsg

 changelog   |   13 +
 control |1 
 patches/0009-Include-sqlite3.h-instead-of-forward-declaring-typed.patch |   26 ++
 patches/series  |1 
 patches/ubuntu.series   |1 
 5 files changed, 41 insertions(+), 1 deletion(-)

diff -Nru mixxx-2.0.0~dfsg/debian/changelog mixxx-2.0.0~dfsg/debian/changelog
--- mixxx-2.0.0~dfsg/debian/changelog	2017-01-11 20:04:24.0 +
+++ mixxx-2.0.0~dfsg/debian/changelog	2017-07-24 11:08:10.0 +0100
@@ -1,3 +1,16 @@
+mixxx (2.0.0~dfsg-7.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+
+  [ Sebastian Ramacher ]
+  * Remove used B-D on libaudiofile-dev
+
+  [ Simon McVittie ]
+  * Add patch from James Cowgill to fix FTBFS with newer sqlite3
+(Closes: #868612)
+
+ -- Simon McVittie <s...@debian.org>  Mon, 24 Jul 2017 11:08:10 +0100
+
 mixxx (2.0.0~dfsg-7) unstable; urgency=medium
 
   * Team upload.
diff -Nru mixxx-2.0.0~dfsg/debian/control mixxx-2.0.0~dfsg/debian/control
--- mixxx-2.0.0~dfsg/debian/control	2017-01-11 19:47:04.0 +
+++ mixxx-2.0.0~dfsg/debian/control	2017-07-24 11:08:10.0 +0100
@@ -11,7 +11,6 @@
  chrpath,
  debhelper (>= 9),
  docbook-to-man,
- libaudiofile-dev,
  libchromaprint-dev,
  libexpat-dev,
  libfftw3-dev,
diff -Nru mixxx-2.0.0~dfsg/debian/patches/0009-Include-sqlite3.h-instead-of-forward-declaring-typed.patch mixxx-2.0.0~dfsg/debian/patches/0009-Include-sqlite3.h-instead-of-forward-declaring-typed.patch
--- mixxx-2.0.0~dfsg/debian/patches/0009-Include-sqlite3.h-instead-of-forward-declaring-typed.patch	1970-01-01 01:00:00.0 +0100
+++ mixxx-2.0.0~dfsg/debian/patches/0009-Include-sqlite3.h-instead-of-forward-declaring-typed.patch	2017-07-24 11:08:10.0 +0100
@@ -0,0 +1,26 @@
+From: James Cowgill <jcowg...@debian.org>
+Date: Mon, 17 Jul 2017 14:01:04 +0100
+Subject: Include sqlite3.h instead of forward-declaring typedefs
+
+This fixes FTBFS with libsqlite3-dev 3.19.3-3.
+
+Bug-Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=868612
+Forwarded: no, upstream appears to have rewritten the sqlite3 code
+---
+ src/library/trackcollection.h | 3 +--
+ 1 file changed, 1 insertion(+), 2 deletions(-)
+
+diff --git a/src/library/trackcollection.h b/src/library/trackcollection.h
+index 0ce9a23..fb66ce6 100644
+--- a/src/library/trackcollection.h
 b/src/library/trackcollection.h
+@@ -34,8 +34,7 @@
+ #include "library/dao/libraryhashdao.h"
+ 
+ #ifdef __SQLITE3__
+-typedef struct sqlite3_context sqlite3_context;
+-typedef struct Mem sqlite3_value;
++#include 
+ #endif
+ 
+ class TrackInfoObject;
diff -Nru mixxx-2.0.0~dfsg/debian/patches/series mixxx-2.0.0~dfsg/debian/patches/series
--- mixxx-2.0.0~dfsg/debian/patches/series	2017-01-11 19:55:53.0 +
+++ mixxx-2.0.0~dfsg/debian/patches/series	2017-07-24 11:08:10.0 +0100
@@ -6,3 +6,4 @@
 0006-opengles.patch
 0007-fix_gcc6_issue.patch
 0008-chromaprint-1.4.patch
+0009-Include-sqlite3.h-instead-of-forward-declaring-typed.patch
diff -Nru mixxx-2.0.0~dfsg/debian/patches/ubuntu.series mixxx-2.0.0~dfsg/debian/patches/ubuntu.series
--- mixxx-2.0.0~dfsg/debian/patches/ubuntu.series	2017-01-11 19:56:01.0 +
+++ mixxx-2.0.0~dfsg/debian/patches/ubuntu.series	2017-07-24 11:08:10.0 +0100
@@ -5,3 +5,4 @@
 0006-opengles.patch
 0007-fix_gcc6_issue.patch
 0008-chromaprint-1.4.patch
+0009-Include-sqlite3.h-instead-of-forward-declaring-typed.patch
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Bug#865264: unicap: please build-depend on automake, not obsolete automake1.11

2017-06-20 Thread Simon McVittie 
Source: unicap
Version: 0.9.12-2
Severity: normal
User: debian...@lists.debian.org
Usertags: automake1.11 automake1.11-only

This package Build-Depends on the obsolete automake1.11 package.

Please check whether this package can be built correctly with the
recommended automake version, as provided by the automake package
(currently version 1.15). If it can, please build-depend on automake
instead, with no automake1.11 alternative. automake (>= 1:1.11)
has been available since at least Debian 7 'wheezy' (oldoldstable).

If this package has an old build system, it is possible that it
will need build system changes for it to be able to autoreconf with
a current version of automake. If so, those changes should be
forwarded upstream. See `info automake Upgrading` or
https://www.gnu.org/software/automake/manual/html_node/Upgrading.html
for details. automake 1.15 was released in 2014 and is now widespread,
so most upstreams will probably not object to a dependency on
versions >= 1.15 at this point.

If automake1.11 is removed from Debian, this bug will become serious
(release-critical), since the Debian buildd infrastructure would be
unable to satisfy this package's build-dependencies. As far as I am
aware, there are no immediate plans to remove automake1.11.

Thanks,
S

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

Bug#865168: jack-audio-connection-kit: please build-depend on automake, not obsolete automake1.11

2017-06-19 Thread Simon McVittie 
Source: jack-audio-connection-kit
Version: 1:0.125.0-2
Severity: normal
User: debian...@lists.debian.org
Usertags: automake1.11 automake1.11-only

This package Build-Depends on the obsolete automake1.11 package.

Please check whether this package can be built correctly with the
recommended automake version, as provided by the automake package
(currently version 1.15). If it can, please build-depend on automake
instead, with no automake1.11 alternative. automake (>= 1:1.11)
has been available since at least Debian 7 'wheezy' (oldoldstable).

If this package has an old build system, it is possible that it
will need build system changes for it to be able to autoreconf with
a current version of automake. If so, those changes should be
forwarded upstream. See `info automake Upgrading` or
https://www.gnu.org/software/automake/manual/html_node/Upgrading.html
for details. automake 1.15 was released in 2014 and is now widespread,
so most upstreams will probably not object to a dependency on
versions >= 1.15 at this point.

If automake1.11 is removed from Debian, this bug will become serious
(release-critical), since the Debian buildd infrastructure would be
unable to satisfy this package's build-dependencies. As far as I am
aware, there are no immediate plans to remove automake1.11.

Thanks,
S

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

Bug#865166: icecast2: please build-depend on automake, not obsolete automake1.11

2017-06-19 Thread Simon McVittie 
Source: icecast2
Version: 2.4.2-1
Severity: normal
User: debian...@lists.debian.org
Usertags: automake1.11 automake1.11-only

This package Build-Depends on the obsolete automake1.11 package.

Please check whether this package can be built correctly with the
recommended automake version, as provided by the automake package
(currently version 1.15). If it can, please build-depend on automake
instead, with no automake1.11 alternative. automake (>= 1:1.11)
has been available since at least Debian 7 'wheezy' (oldoldstable).

If this package has an old build system, it is possible that it
will need build system changes for it to be able to autoreconf with
a current version of automake. If so, those changes should be
forwarded upstream. See `info automake Upgrading` or
https://www.gnu.org/software/automake/manual/html_node/Upgrading.html
for details. automake 1.15 was released in 2014 and is now widespread,
so most upstreams will probably not object to a dependency on
versions >= 1.15 at this point.

If automake1.11 is removed from Debian, this bug will become serious
(release-critical), since the Debian buildd infrastructure would be
unable to satisfy this package's build-dependencies. As far as I am
aware, there are no immediate plans to remove automake1.11.

Thanks,
S

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

Bug#852985: gsequencer: please do not build-depend on oss4-dev on Linux

2017-01-31 Thread Simon McVittie 
On Tue, 31 Jan 2017 at 02:56:37 +0100, Joël Krähemann wrote:
> The patch looks fine. There should be no problem as passing this
> configure flag.  I even used gsequencer on linuxfromscratch.org based
> system without having OSS4 at all.

I'd be happy to sponsor a maintainer upload with this or a similar change
if you prepare one - I'd prefer to upload something that someone who knows
the software has tested! Or please let me know if you'd like me to prepare
a non-maintainer upload and send it to you for testing.

> Note you can disable it for GNU/Hurd, as well. So JACK is the only
> output sink.

Hurd isn't a release architecture (and never has been, unlike kFreeBSD)
so I don't mind whether it has an OSS4 dependency there - it isn't going
to disrupt the release either way. Do you have any preference for
whether it's [!linux-any] or [kfreebsd-any]?

In NMUs for other packages I've been using [!linux-any] so it's only
a change to previous behaviour on the kernel I know about.

S

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

Bug#852984: audacious-plugins: please do not build-depend on oss4-dev on Linux

2017-01-29 Thread Simon McVittie 
On Sun, 29 Jan 2017 at 18:30:09 +0100, Sebastian Ramacher wrote:
> > On Sat, 28 Jan 2017 at 17:54:43 +, Simon McVittie wrote:
> > I have done a non-maintainer upload to DELAYED/7
> 
> Thank you. Feel free to reschedule it to DELAYED/0.

Rescheduled. I'll open an unblock bug when it's been accepted.

S

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

Bug#852985: gsequencer: please do not build-depend on oss4-dev on Linux

2017-01-29 Thread Simon McVittie 
Control: tags 852985 + patch

On Sat, 28 Jan 2017 at 17:55:43 +, Simon McVittie wrote:
> This package build-depends on oss4-dev, which is built by RC-buggy source
> package oss4.

I attach a possible patch.

I don't know how to test gsequencer, so I am not intending to do a
NMU for this bug.

Regards,
S
>From a7fc446f2b269f054c371f32816d35747771f2b6 Mon Sep 17 00:00:00 2001
From: Simon McVittie <s...@debian.org>
Date: Sun, 29 Jan 2017 12:12:19 +
Subject: [PATCH] Build-depend on ALSA on Linux, and on OSS4 on non-Linux

Disable the other kernel's API in each case (Closes: #852985)
---
 debian/changelog | 8 
 debian/control   | 5 +++--
 debian/rules | 3 ++-
 3 files changed, 13 insertions(+), 3 deletions(-)

diff --git a/debian/changelog b/debian/changelog
index a9b2ad4..550ff35 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,11 @@
+gsequencer (0.7.122-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Build-depend on ALSA on Linux, and on OSS4 on non-Linux, disabling
+the other kernel's API in each case (Closes: #852985)
+
+ -- Simon McVittie <s...@debian.org>  Sun, 29 Jan 2017 12:11:56 +
+
 gsequencer (0.7.122-1) unstable; urgency=medium
 
   * New upstream version 0.7.122
diff --git a/debian/control b/debian/control
index b13e923..27f2c9e 100644
--- a/debian/control
+++ b/debian/control
@@ -20,8 +20,9 @@ Build-Depends: debhelper (>= 9),
  dssi-dev,
  lv2-dev,
  libgmp-dev,
- libasound2-dev|liboss4-salsa-dev,
- oss4-dev,
+ libasound2-dev [linux-any],
+ liboss4-salsa-dev [!linux-any],
+ oss4-dev [!linux-any],
  libjack-dev,
  uuid-dev,
  docbook-xsl,
diff --git a/debian/rules b/debian/rules
index fc2ae40..7575519 100755
--- a/debian/rules
+++ b/debian/rules
@@ -8,10 +8,11 @@ archconfflags :=
 
 ifeq ($(DEB_HOST_ARCH_OS),linux)
   archconfflags += --enable-alsa
+  archconfflags += --disable-oss
 else
   archconfflags += --disable-alsa
+  archconfflags += --enable-oss
 endif
-archconfflags += --enable-oss
 
 archconfflags += --enable-gtk-doc --enable-gtk-doc-html
 
-- 
2.11.0

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

Bug#852984: audacious-plugins: please do not build-depend on oss4-dev on Linux

2017-01-29 Thread Simon McVittie 
Control: tags 852984 + patch pending

On Sat, 28 Jan 2017 at 17:54:43 +, Simon McVittie wrote:
> This package build-depends on oss4-dev, which is built by RC-buggy source
> package oss4.

I have done a non-maintainer upload to DELAYED/7 to make sure this doesn't
result in audacious getting removed from stretch; a (trivial) patch against
debian/3.7.2-2-1 in pkg-multimedia git is attached. Please let me know
if you would like me to cancel or reschedule it.

If you would prefer to do a maintainer upload (which would pre-empt my
NMU), please do.

Regards,
S
>From b7a3e1dcf98703f2f15c4cf3c12e1a24c7a5a30e Mon Sep 17 00:00:00 2001
From: Simon McVittie <s...@debian.org>
Date: Sun, 29 Jan 2017 11:54:47 +
Subject: [PATCH] Drop build-dependency on oss4-dev for Linux kernel (Closes:
 #852984)

---
 debian/changelog | 7 +++
 debian/control   | 2 +-
 2 files changed, 8 insertions(+), 1 deletion(-)

diff --git a/debian/changelog b/debian/changelog
index b98217b..f889020 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+audacious-plugins (3.7.2-2.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Drop build-dependency on oss4-dev for Linux kernel (Closes: #852984)
+
+ -- Simon McVittie <s...@debian.org>  Sun, 29 Jan 2017 11:54:36 +
+
 audacious-plugins (3.7.2-2) unstable; urgency=medium
 
   * Team upload.
diff --git a/debian/control b/debian/control
index 62c771d..700cd18 100644
--- a/debian/control
+++ b/debian/control
@@ -47,7 +47,7 @@ Build-Depends:
  libwavpack-dev (>= 4.31),
  libxcomposite-dev,
  libxml2-dev,
- oss4-dev,
+ oss4-dev [!linux-any],
  qtbase5-dev,
  qtmultimedia5-dev,
  libqt5opengl5-dev
-- 
2.11.0

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

Bug#852985: gsequencer: please do not build-depend on oss4-dev on Linux

2017-01-28 Thread Simon McVittie 
Source: gsequencer
Version: 0.7.122-1
Severity: serious
Justification: release team consensus

This package build-depends on oss4-dev, which is built by RC-buggy source
package oss4.

I discussed this with some release team members and their opinion is that
oss4 should only be used on non-Linux architectures: on Linux, we should be
using ALSA, either directly or via intermediaries like PulseAudio.
Please restrict the build-dependency to oss4-dev [kfreebsd-any] or possibly
oss4-dev [kfreebsd-any hurd-any], and set the configure options so OSS is
only requested on those architectures, similar to what is done in
vlc (>= 2.2.0~pre3-1).

Regards,
smcv
helping the Cambridge BSP

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

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

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

Bug#852984: audacious-plugins: please do not build-depend on oss4-dev on Linux

2017-01-28 Thread Simon McVittie 
Source: audacious-plugins
Version: 3.7.2-2
Severity: serious
Justification: release team consensus

This package build-depends on oss4-dev, which is built by RC-buggy source
package oss4.

I discussed this with some release team members and their opinion is that
oss4 should only be used on non-Linux architectures: on Linux, we should be
using ALSA, either directly or via intermediaries like PulseAudio.
Please restrict the build-dependency to oss4-dev [kfreebsd-any] or possibly
oss4-dev [kfreebsd-any hurd-any], and if necessary set the configure options
so OSS is only requested on those architectures, similar to what is done in
vlc (>= 2.2.0~pre3-1).

Regards,
smcv
helping the Cambridge BSP

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

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

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

Bug#836396: sonic-pi: please replace dbus-launch with something else

2016-09-02 Thread Simon McVittie 
Source: sonic-pi
Version: 2.10.0~repack-2
Severity: normal
Tags: upstream
User: d...@packages.debian.org
Usertags: dbus-launch dbus-launch-for-infra

As described in 
I'm trying to reduce how much dbus-launch is used in Debian.
sonic-pi currently starts a new D-Bus session bus in the sonic-pi and
rp-app-bin scripts: I'm not sure whether these are used in Debian or not.
That dbus-daemon process is not terminated with sonic-pi (it is "leaked"),
which is a bug in its own right.

There are two possibilities here: either sonic-pi is meant to use an
existing D-Bus session bus if there is one, or it is not.

--- 1. Existing session bus

I suspect that what is actually intended here is to use an existing
D-Bus session bus if one exists, like every GNOME, KDE, etc. app would do.

The simplest way to use an existing session bus is to not run dbus-launch
explicitly at all, and have the Debian package depend on
default-dbus-session-bus | dbus-session-bus. This will either use an
existing D-Bus session bus provided by the dbus-user-session or dbus-x11
package, or if there is no existing session bus but dbus-x11 is installed
and an X11 DISPLAY is available, start a new bus via "X11 autolaunch".

Alternatively, if Sonic Pi really needs to support being run with
neither a D-Bus session bus nor X11 already available and start
a new D-Bus session bus, it could probe for one with dbus-send:

command_prefix=

if ! dbus-send --session --dest=org.freedesktop.DBus --type=method_call \
/org/freedesktop/DBus org.freedesktop.DBus.GetId \
>/dev/null 2>/dev/null; then
command_prefix="dbus-run-session --"
fi

$command_prefix $DIR/../app/gui/qt/sonic-pi

This avoids second-guessing how D-Bus implementations would connect to the
session bus, so it is better than probing based on $DBUS_SESSION_BUS_ADDRESS.

--- 2. New session bus

If the intention is that sonic-pi always behaves like a new login session
(but this is really unconventional, and normal applications don't do this),
then it could do this more simply and with fewer dependencies via something
like this:

* remove "eval $(dbus-launch --auto-syntax)"
* instead of "$DIR/../app/gui/qt/sonic-pi" run
  "dbus-run-session -- $DIR/../app/gui/qt/sonic-pi"

If you forward this upstream, please quote the whole text so the upstream
developer can decide.

Thanks,
S

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

Bug#836078: audacious: please switch from dbus-x11 to default-dbus-session-bus | dbus-session-bus

2016-08-31 Thread Simon McVittie 
On Tue, 30 Aug 2016 at 20:59:07 -0400, Nicholas D Steeves wrote:
> I maintain the Jessie backport for audacious.  As far as I can tell,
> neither default-dbus-session-bus nor dbus-session-bus are provided for
> Jessie, even as a virtual package.

Correct. If you want to allow for no-change backports, I think the best
way is probably:

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

(or Recommends, whichever one this package uses). dbus-x11 is the
closest equivalent of default-dbus-session-bus in jessie.

S

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

Bug#836078: audacious: please switch from dbus-x11 to default-dbus-session-bus | dbus-session-bus

2016-08-30 Thread Simon McVittie 
Source: audacious
Version: 3.7.2-1
Severity: normal
User: d...@packages.debian.org
Usertags: dbus-launch default-dbus-session-bus

As described in 
I'm trying to reduce how much dbus-launch is used in Debian.
This package currently Depends on dbus-x11 as a way to get a session bus.

This package falls into the "other software that relies on D-Bus"
category: please replace

Depends: dbus-x11

with

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

so that either dbus-user-session or dbus-x11 can be used.

My short-term goal with this is that major desktop environments in Debian
stretch should be able to run with either dbus-user-session or dbus-x11,
with the other one uninstalled.

Thanks,
S

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

Bug#799649: stk: ABI transition needed for libstdc++ v5

2015-09-21 Thread Simon McVittie 
Source: stk
Version: 4.4.4-5
Severity: serious
Justification: ABI break since stable when rebuilt
Tags: sid stretch
User: debian-...@lists.debian.org
Usertags: libstdc++-cxx11

Background[1]: libstdc++6 introduces a new ABI to conform to the
C++11 standard, but keeps the old ABI to not break existing binaries.
Packages which are built with g++-5 from experimental (not the one
from testing/unstable) are using the new ABI.  Libraries built from
this source package export some of the new __cxx11 or B5cxx11 symbols,
dropping other symbols.  If these symbols are part of the API of
the library, then this rebuild with g++-5 will trigger a transition
for the library.

In the case of stk, there's a lot of std::string use in include/,
so a transition does appear to be needed. The transition normally
consists of renaming the affected library packages, replacing the
c2a suffix from a similar previous transition with a v5 suffix
(libstk0v5). The SONAME should not be changed when doing this.

If an upgrade to a new upstream SONAME is already planned, and that
SONAME has never been available in Debian compiled with g++-4, then an
alternative way to carry out the transition would be to bump the
SONAME. However, the libstdc++ transition has been going on for nearly
2 months already, and anything that makes it take longer is bad for Debian,
so introducing new upstream code is not recommended at this stage.

These follow-up transitions for libstdc++ are not going through exactly
the normal transition procedure, because many entangled transitions are
going on at the same time, and the usual ordered transition procedure
does not scale that far. When all the C++ libraries on which this library
depends have started their transitions in unstable if required, this
library should do the same, closing this bug; the release team will deal
with binNMUs as needed.

Looking at the build-dependencies of stk, rtaudio and rtmidi have
already had their renames, so I believe stk is now ready to be renamed.

The package might be NMU'd if there is no maintainer response. The
release team have declared a 2 day NMU delay[2] for packages involved
in the libstdc++ transition, in order to get unstable back to a usable
state in a finite time.

Regards,
S

[1] https://wiki.debian.org/GCC5#libstdc.2B-.2B-_ABI_transition
[2] https://lists.debian.org/debian-devel-announce/2015/08/msg0.html

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

Bug#797994: synfig: ABI transition needed for libstdc++ v5

2015-09-04 Thread Simon McVittie 
Source: synfig
Version: 1.0-1
Severity: serious
Justification: breaks ABI without a package rename
Tags: sid stretch
User: debian-...@lists.debian.org
Usertags: libstdc++-cxx11

Background[1]: libstdc++6 introduces a new ABI to conform to the
C++11 standard, but keeps the old ABI to not break existing binaries.
Packages which are built with g++-5 from experimental (not the one
from testing/unstable) are using the new ABI.  Libraries built from
this source package export some of the new __cxx11 or B5cxx11 symbols,
dropping other symbols.  If these symbols are part of the API of
the library, then this rebuild with g++-5 will trigger a transition
for the library.

In the case of synfig, std::string appears in functions in public
headers, so it seems very likely that a transition is needed.
The transition normally consists of renaming the
affected library packages, adding a v5 suffix (libsynfig0v5).
The actual SONAME should not be changed when doing this.

If an upgrade to a new upstream SONAME is already planned, and that
SONAME has never been available in Debian compiled with g++-4, then an
alternative way to carry out the transition would be to bump the
SONAME. However, please avoid doing this unless the new upstream version
is very low-risk: the libstdc++ transition has stalled development in
unstable for long enough already.

These follow-up transitions for libstdc++ are not going through exactly
the normal transition procedure, because many entangled transitions are
going on at the same time, and the usual ordered transition procedure
does not scale that far. When all the C++ libraries on which this library
depends have started their transitions in unstable if required, this
library should do the same, closing this bug; the release team will deal
with binNMUs as needed.

Looking at the build-dependencies of synfig:

* boost has already been renamed
* etl seems to be header-only so does not need a transition
* libmagick++ has already been renamed
* libmlt++ is not believed to need a transition (but please check)

so I think this sub-transition may be ready.

The package might be NMU'd if there is no maintainer response. The
release team have declared a 2 day NMU delay[2] for packages involved
in the libstdc++ transition, in order to get unstable back to a usable
state in a finite time.

Regards,
S

[1] https://wiki.debian.org/GCC5#libstdc.2B-.2B-_ABI_transition
[2] https://lists.debian.org/debian-devel-announce/2015/08/msg0.html

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

Re: Bug#791290: sndobj: library transition may be needed when GCC 5 is the default

2015-08-25 Thread Simon McVittie 
On Fri, 07 Aug 2015 at 13:22:49 -0300, Felipe Sateler wrote:
 Sndobj requires a transition. Renamed package has been uploaded to
 experimental and is in NEW.

Since sndobj does not appear to build-depend on any libraries that need a
transition, I believe it can be uploaded to unstable any time.

S

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

Bug#795813: kodi: FTBFS with g++-5: multiple definitions of argument-parsing stuff

2015-08-17 Thread Simon McVittie 
Source: kodi
Version: 14.2+dfsg1-2
Severity: serious
Justification: fails to build from source (but built successfully in the past)
Tags: patch

kodi fails to build from source when binNMU'd for the libstdc++ transitions:
https://buildd.debian.org/status/package.php?p=kodi

There are lots of errors like this:

../../lib/libmisc.a(argp-parse.o): In function `argp_usage':
/«BUILDDIR»/kodi-14.2+dfsg1/xbmc/screensavers/rsxs-0.9/lib/argp.h:568: multiple 
definition of `argp_usage'
../../lib/libmisc.a(argp-help.o):/«BUILDDIR»/kodi-14.2+dfsg1/xbmc/screensavers/rsxs-0.9/lib/argp.h:568:
 first defined here
../../lib/libmisc.a(argp-parse.o): In function `_option_is_short':
/«BUILDDIR»/kodi-14.2+dfsg1/xbmc/screensavers/rsxs-0.9/lib/argp.h:574: multiple 
definition of `_option_is_short'
../../lib/libmisc.a(argp-help.o):/«BUILDDIR»/kodi-14.2+dfsg1/xbmc/screensavers/rsxs-0.9/lib/argp.h:574:
 first defined here

I believe this is because g++-5 changed the default interpretation of
inline T foo() { ... } from historical GNU behaviour to Standard C++.
https://gcc.gnu.org/gcc-5/changes.html

In Ubuntu, Matthias Klose patched kodi to use historical GNU inline
semantics http://patches.ubuntu.com/k/kodi/kodi_14.2+dfsg1-2ubuntu1.patch:

diff -pruN 14.2+dfsg1-2/debian/rules 14.2+dfsg1-2ubuntu1/debian/rules
--- 14.2+dfsg1-2/debian/rules   2015-06-04 08:33:30.0 +
+++ 14.2+dfsg1-2ubuntu1/debian/rules2015-08-10 19:42:58.0 +
@@ -37,6 +37,7 @@ DEB_CFLAGS ?=  $(shell dpkg-buildflags -
 DEB_CXXFLAGS ?= $(shell dpkg-buildflags --get CPPFLAGS) \
   $(filter-out -g -O2, $(shell dpkg-buildflags --get CXXFLAGS))
 DEB_LDFLAGS ?= $(shell dpkg-buildflags --get LDFLAGS) $(shell pkg-config 
--libs ftgl)
+DEB_CFLAGS += -fgnu89-inline
 ENV_OPTIONS = CFLAGS=$(DEB_CFLAGS) CXXFLAGS=$(DEB_CXXFLAGS) \
   LDFLAGS=$(DEB_LDFLAGS)
 

This is probably an appropriate change for kodi in Debian too.

Regards,
S

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

Bug#791197: lv2-c++-tools: library transition may be needed when GCC 5 is the default

2015-08-10 Thread Simon McVittie 
On Fri, 07 Aug 2015 at 12:49:43 -0300, Felipe Sateler wrote:
 I don't think a transition is required, but maybe there are libpaq
 users outside debian? Does someone know?

If there isn't a reason to suspect there are library users outside Debian,
it seems less disruptive to assume there are not. If it's absolutely
necessary, there can be a follow-up transition afterwards.

jcristau said on IRC that the release team would prefer to have packages
with no known reason for a transition taken off their radar; there are too
many library renames going on at once as it is. So I'd suggest closing
this bug.

S

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

Bug#794975: mixxx: will FTBFS with unsatisfiable dependencies due to libstdc++ transition

2015-08-08 Thread Simon McVittie 
Package: mixxx
Version: 1.11.0~dfsg-4
Severity: serious
Justification: fails to build from source (but built successfully in the past)
User: debian-...@lists.debian.org
Usertags: libstdc++-cxx11
Tags: patch

A binNMU of mixxx failed to build from source prior to the transition
from libvamp-hostsdk3 to libvamp-hostsdk3v5. It has not yet been retried,
but when it is, it will likely stop at BD-Uninstallable or continue
to fail, because it specifically build-depends on the old libvamp-hostsdk3.

It is unusual to build-depend on library packages, because the
corresponding -dev usually pulls them in, but I assume there is some
special reason in this case.

The attached patch appears to resolve this. I'm happy to NMU this
(with the addition of this bug number) if necessary.

Regards,
S
From a0156952b92336f21642a9cd31c317f933510919 Mon Sep 17 00:00:00 2001
From: Simon McVittie s...@debian.org
Date: Sat, 8 Aug 2015 16:51:35 +0100
Subject: [PATCH] debian/control: change build-dependency on libvamp-hostsdk3
 to libvamp-hostsdk3v5 for stdc++ transition

---
 debian/changelog | 8 
 debian/control   | 2 +-
 2 files changed, 9 insertions(+), 1 deletion(-)

diff --git a/debian/changelog b/debian/changelog
index f923767..d108522 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,11 @@
+mixxx (1.11.0~dfsg-4.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * debian/control: change build-dependency on libvamp-hostsdk3 to
+libvamp-hostsdk3v5 for stdc++ transition
+
+ -- Simon McVittie s...@debian.org  Sat, 08 Aug 2015 16:51:14 +0100
+
 mixxx (1.11.0~dfsg-4) unstable; urgency=medium
 
   * Team upload.
diff --git a/debian/control b/debian/control
index 6b63635..ae0e57f 100644
--- a/debian/control
+++ b/debian/control
@@ -30,7 +30,7 @@ Build-Depends:
  libsoundtouch-dev (= 1.5.0),
  libtag1-dev,
  libusb-1.0-0-dev,
- libvamp-hostsdk3,
+ libvamp-hostsdk3v5,
  libvorbis-dev,
  pkg-config,
  portaudio19-dev,
-- 
2.5.0

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

Bug#791307: vamp-plugin-sdk: library transition may be needed when GCC 5 is the default

2015-08-06 Thread Simon McVittie 
Control: severity 791307 serious
Control: retitle 791307 vamp-plugin-sdk: library transition needed for GCC 5 ABI

On Fri, 03 Jul 2015 at 13:14:47 +, Matthias Klose wrote:
  - Decide if the symbols matching __cxx11 or B5cxx11 are part of the
library API, and are used by the reverse dependencies of the
library.

Yes they are, mixxx uses them:
https://buildd.debian.org/status/fetch.php?pkg=mixxxarch=amd64ver=1.11.0~dfsg-4%2Bb1stamp=1438764427

for example:

lin32_build/vamp/vamppluginloader.o: In function 
`VampPluginLoader::loadPlugin(std::__cxx11::basic_stringchar, 
std::char_traitschar, std::allocatorchar , float, int)':
/«PKGBUILDDIR»/src/vamp/vamppluginloader.cpp:58: undefined reference to 
`_VampHost::Vamp::HostExt::PluginLoader::loadPlugin(std::__cxx11::basic_stringchar,
 std::char_traitschar, std::allocatorchar , float, int)'

Regards,
S

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

Bug#697026: swami: please re-upload built against GLib 2.32

2012-12-30 Thread Simon McVittie 
Source: swami
Version: 2.0.0+svn389-1
Severity: serious
Justification: Bug #694525
Control: block 694525 by -1

src:swami was last built against GLib 2.30, and contains public
structs (SwamiLock and derived structs) which embed a GStaticMutex,
GStaticRecMutex or GStaticRWLock.

On most 32-bit platforms (notably armel, armhf, mips, mipsel, powerpc, s390
and sparc), the size of GStaticMutex etc. changed between GLib 2.30 and 2.32;
this resulted in bugs like #683012. Because that was a while ago, upstream
recommend rebuilding everything that's affected against the new GLib and
carrying on with the new ABI.

Because swami has Multi-Arch: same packages, a binNMU is undesirable,
so it would be better to make a sourceful upload as a pseudo-binNMU.

See #694525 for further discussion.

Regards,
Simon

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

Bug#697026: swami: please re-upload built against GLib 2.32

2012-12-30 Thread Simon McVittie 
A simple rebuild (no source changes) on amd64 results in a swami GUI
executable that runs, but I have no idea how to test it, or indeed make
it do anything at all.

It appears to default to trying to exec jackd (which is only suggested,
and that only indirectly) and output via that; with the output backend
set to either alsa, jack, pulseaudio or oss (using pasuspender in the
case of oss), clicking on keys on the piano keyboard doesn't produce any
sound. I suspect my sound card (Intel HDA on Lenovo X220) doesn't
actually have any MIDI support; if that's the case, and hardware MIDI
support is required, then I won't be able to NMU this package.

S

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

Bug#697031: swami: default output mechanism is jackd, which is not depended on

2012-12-30 Thread Simon McVittie 
Package: swami
Version: 2.0.0+svn389-1
Severity: normal

swami appears to default to output via jackd:

libswami-Message: Loading plugins from /usr/lib/swami
libswami-Message: Loaded 4 plugins
Cannot connect to server socket err = No such file or directory
Cannot connect to server request channel
exec of JACK server (command = /usr/bin/jackd) failed: No such file or 
directory

but it does not depend on, or even recommend, jackd. The closest it gets
is this chain:

swami Depends libfluidsynth1 Depends libjack-jackd2-0 Suggests jackd2

or if you take the non-default branch of an alternative dependency,

swami Depends libfluidsynth1 Depends libjack0 Suggests jackd1

Either way, it's only suggested, and only indirectly; that doesn't seem
ideal. (If you think this is more of a libfluidsynth1 or libjack* bug,
feel free to reassign it - I encountered it when testing swami for #697026.)

Regards,
S

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

Bug#666401: libavutil51: conflict with libavutil-extra-51 is counter-productive

2012-03-30 Thread Simon McVittie 
Package: libavutil51
Version: 5:0.8.1-3
Severity: important

Judging by its description, libavutil-extra-51 is meant to be a transitional
package.

However, transitional packages should be installable simultaneously
with the package to which you're transitioning, otherwise there's no point:
if the transitional package isn't co-installable with the new package that
it depends on, then it's not installable.

The two ways I can see to do this transition are:

* remove libavutil-extra-51 entirely, have libavutil51 conflict/replace it

* keep libavutil-extra-51 as a transitional package, have
  libavutil51 conflict/replace versions less than the one in which the
  transition was made

I'm sure the release team would also have something to say about this.

Regards,
S




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

Bug#587110: mixxx: FTBFS: dlgprefmidibindings.cpp:75: undefined reference to `MidiOptionDelegate::MidiOptionDelegate(QObject*)'

2010-10-08 Thread Simon McVittie 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Fri, 25 Jun 2010 at 12:14:04 +0200, Lucas Nussbaum wrote:
 Source: mixxx
 Version: 1.7.2-1
 Severity: serious
 Tags: squeeze sid
 User: debian...@lists.debian.org
 Usertags: qa-ftbfs-20100624 qa-ftbfs
 Justification: FTBFS on amd64

Hi,
How do you intend to deal with this bug for squeeze? The changes in
experimental seem unlikely to be suitable for a frozen distribution (unless
mixxx 1.8.0.1 is very similar to 1.7.2), so backporting a minimal fix is
likely to be the way forward.

S
-BEGIN PGP SIGNATURE-

iQIVAwUBTK8xD03o/ypjx8yQAQhWcg//b5tLKUUCkC7q95PXdOr4p9OoDDoF0ZDs
3niWbqyeXMsf2/09gDQ1wpIsSb+EgXYje8YmyysRGhGt6KsJGeEJxAAAPwkexK/3
e1WGv2YZ+iPBmJpsDRc+xYGY4yhA5bUJmRA/olreB3/8i0jbldrOQpKCY7MjpFjx
v5l83R7mPBX77Wp7wrgU9rLq4vLo7r1cxLbNnIcB3f6d6e0sBe4uHMxvgrozsTAu
wYoDjVMmbJKmlxOnjmBjVapASiRFeJsh47VyVF4dYGwpCj/M7F5Y/bMkRmHcef4o
SKrrLY1jNKeU3LHsR4TeAgHZfD4+uoA1itnxg1g1WoHqMGCVjTAM3QGKl8Zh2Yfa
ohlQDGxM4Sfoy7xdMwvKexiyfqiOH/8hdMZYf+3tPTZvYjOzkztD6oygqQdpZp1O
ww1rgJQ19xgznuKvgf5GiSl5N0YQu5hjNf3eZ4exT+tqCm/jAhQ2Uc5eG3gJYxTm
i5auq/WTb1Zws5GhX1qSNj+rKUKH4hkhzVFOrjTQ24HUAHrJOWaQUdb2owJdNBpK
f8rXMIgCbidp5Og/ITCosH6xb4LLxtRPmhIb2l1TO6KYHm0rCCNXH0npnDHepf6P
kZ//lGFQ0XgzYrd3DV9zWcbOrPFO32krg2/+1Cr2fDU9bNwu0xtKZ2artQGWHk5e
ltNjRmuTpTo=
=cdbT
-END PGP SIGNATURE-



___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers

Bug#580088: jack-audio-connection-kit: FTBFS on armel (cannot convert 'int' to 'va_list')

2010-05-03 Thread Simon McVittie 
On Mon, 03 May 2010 at 18:13:00 +0200, Adrian Knoth wrote:
 Obviously, arg4 is NULL, so the message means the compiler cannot
 convert 0 to a va_list, which should be (more or less) a pointer.

Or a struct, or a platform-specific-object that exists nowhere else in C, or a
piece of cheese, depending. (C makes no guarantees about what va_list means; I
doubt C++ does either.)

Googling for armel va_list turns up
https://bugs.launchpad.net/ubuntu/+source/gnome-keyring/+bug/527179 which
suggests that va_list is indeed a struct on armel.

 The code in question:

jack_client_open_aux(client_name, (jack_options_t)options, NULL, NULL);

Instead of trying to fake up an empty va_list, why not call the varargs
version, with only the argument terminator in its varargs?

jack_client_open(client_name, (jack_options_t)options, NULL, NULL);

I'm assuming here that jack_client_open_aux is to jack_client_open as
vprintf is to printf, i.e. jack_client_open just calls jack_client_open_aux.

Regards,
S
(who knows very little about armel or JACK)



___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers