Re: preparing new RtMidi release, question about SO version

2016-02-15 Thread Felipe Sateler 
On 15 February 2016 at 16:38, Stephen Sinclair  wrote:
> On Mon, Feb 15, 2016 at 12:05 PM, Felipe Sateler  wrote:
>> Hi Stephen
>>
>> On 10 February 2016 at 14:21, Stephen Sinclair  wrote:
>>>
>>> Hello,
>>>
>>> I am helping to update RtMidi, a C++ class for cross-platform MIDI
>>> support.  There is a Debian librtmidi package.  Although this is just
>>> a bug-fix release, and is planned to go from 2.1.0 to 2.1.1, we have
>>> added some automake/libtool infrastructure, and a last debate is
>>> whether to properly start supporting SO version according to libtool's
>>> rules.
>>
>> Cool. I would be careful, though, because for C++ seemingly innocent
>> changes can break the ABI. STK[1] was recently updated to use
>> libtool's -release style versioning to avoid problems, as some changes
>> broke ABI and were not noticed by upstream as such. This is
>> particularly important for libraries that are used as static libraries
>> (as this kind of breakage might go unnoticed for a  while).
>
> So that's sort of part of my question -- I'd like to integrate better
> ABI testing into the usual procedure, so as to avoid changes that
> "were not noticed by upstream."  If such problems are more likely
> noticed by packagers, would it be good practice to always request a
> pre-release review by packagers before doing an upstream release?  Or
> would that be too much noise?  (Not that releases are done very
> often.. but I'm asking in the general case, I'll likely apply this as
> a rule of thumb to other software I maintain.)

Well, I'm not sure packagers do anything special. We do have symbols
files that can help, but those are not currently in use by rtmidi (in
c++ in general they can be a bit of a pain). There are external tools
that can help (like the
abi-{compliance-checker,monitor,viewer,tracker} tools), but I think
the main way to keep this is to do it pre-emptively: be aware of
changes that can change ABI and do not merge those. For C++, this is
quite limiting, though[1]. ABI stability of C++ libraries is hard.


[1] 
https://techbase.kde.org/Policies/Binary_Compatibility_Issues_With_C%2B%2B#The_Do.27s_and_Don.27ts

>
>> [1] https://github.com/thestk/stk/pull/27
>>>
>>> Previous versions have made the error of treating SO version like the
>>> version number, and producing binaries e.g. librtmidi.so.2.1.0.
>>>
>>> I was recommending changing this to properly reflect ABI
>>> compatibility.  What would Debian maintainers prefer here?
>>
>> If (and only if) proper ABI versioning can be done, then I'd prefer
>> that, of course. But using a -release style versioning would also be
>> ok, and force rebuild of all reverse depedends on each upstream
>> version. This should be ok, as there aren't many (6 by my count). This
>> has the advantagae for upstream that they do not have to care about
>> abi.
>
> I don't think it's a huge overhead to check for ABI changes between
> releases, provided this can be done (largely) automatically.  Which
> should be possible, although I haven't explored the available tools
> yet.  I'm not 100% sure what you mean by -release style versioning.
> You mean append the library version as if it were the SO name?
> Doesn't that lead to complications when there's a bugfix release that
> happens to change the ABI? Or rather you seem to be suggesting a full
> SO bump on every release.  I'm not sure if I follow.

Yes, I suggest a full bump on every release. That, while not optimal
from a downstream perspective, is still manageable, and is much more
convenient for upstream and less error-prone.

Note that -release style versioning is setting SONAME as
libfoo-x.y.z.so instead of libfoo.x

>
>>> I proposed making the new SO version 3.0.0, to really emphasize that
>>> the ABI version is new, however since it's a bugfix release I don't
>>> know if that's the recommended strategy.
>>>
>>> https://github.com/thestk/rtmidi/pull/59
>>>
>>> In any case I notice that the interface has changed a bit, e.g. some
>>> functions have lost parameters, others have new parameters, since the
>>> last release.
>>
>> I see the pull request has already been merged. I hope this message
>> doesn't come too late.
>
> Yes, the release has been done.  However, I think bumping the SO name
> was the right call, seeing as the ABI signature of setErrorCallback()
> changed.  I just figured we may as well use it as an opportunity to
> make it significantly different from the release version while we're
> at it.

I agree a bump was required.

In summary:

1. C++ ABI compatibility is hard.
2. If you can (as upstream) commit to ABI stability and manage it,
this is the best for downstreams.
3. If you cannot, then I find -release style versioning acceptable as
well. While it is inconvenient to have to rebuild all reverse
dependencies, it beats having to figure out weird crashes when library
versions don't match.




-- 

Saludos,
Felipe Sateler

___
pkg-multimedia-maintainers mailing list
pkg-multim

Bug#796173: marked as done (reportbug: Sound goes away after seeking in VLC)

2016-02-15 Thread Debian Bug Tracking System 
Your message dated Tue, 16 Feb 2016 00:28:51 +0200
with message-id <3977947.ejt2fn9...@basile.remlab.net>
and subject line Re: reportbug: Sound goes away after seeking in VLC
has caused the Debian Bug report #796173,
regarding reportbug: Sound goes away after seeking in VLC
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
796173: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=796173
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: reportbug
Version: 6.6.3
Severity: normal

Dear Maintainer,

I try to seek in a video in vlc, but the sound goes away after seeking. If I 
keep seeking, I can randomly get the sound back sometimes.

This is with vlc version:
VLC media player 2.2.0-rc2 Weatherwax (revision 2.2.0-rc1-118-g22fda39)
VLC version 2.2.0-rc2 Weatherwax (2.2.0-rc1-118-g22fda39)
Compiled by buildd on brahms.debian.org (Jan 21 2015 22:35:58)
Compiler: gcc version 4.9.2 (Debian 4.9.2-9)

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

** /home/kerry/.reportbugrc:
reportbug_version "6.6.3"
mode standard
ui text
email "kerryh...@gmail.com"

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

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

Versions of packages reportbug depends on:
ii  apt   1.0.9.8
ii  python2.7.9-1
ii  python-reportbug  6.6.3
pn  python:any

reportbug recommends no packages.

Versions of packages reportbug suggests:
pn  claws-mail   
pn  debconf-utils
pn  debsums  
pn  dlocate  
pn  emacs23-bin-common | emacs24-bin-common  
ii  file 1:5.22+15-2
ii  gnupg1.4.18-7
ii  postfix [mail-transport-agent]   2.11.3-1
ii  python-gtk2  2.24.0-4
pn  python-gtkspell  
pn  python-urwid 
ii  python-vte   1:0.28.2-5
ii  xdg-utils1.1.0~rc1+git20111210-7.4

Versions of packages python-reportbug depends on:
ii  apt   1.0.9.8
ii  python-debian 0.1.27
ii  python-debianbts  1.12
pn  python:any

python-reportbug suggests no packages.

-- no debconf information
--- End Message ---
--- Begin Message ---
fixed 796173 2.2.2-1
thanks

On Sunday 25 October 2015 13:26:00 Rémi Denis-Courmont wrote:
> found 796173 2.2.0~rc2-1
> tags 796173 + moreinfo
> thanks
> 
> On Wed, 19 Aug 2015 15:03:28 -0700 Kerry Hall 
> 
> wrote:
> > Package: reportbug
> > Version: 6.6.3
> > Severity: normal
> > 
> > Dear Maintainer,
> > 
> > I try to seek in a video in vlc, but the sound goes away after seeking. If
> > I
> keep seeking, I can randomly get the sound back sometimes.
> 
> Are you using PulseAudio or ALSA or ... as output?
> Can you please post the logs?
> 
> If PulseAudio, this might already be fixed in VLC 2.2.2.

No answers to a rather trivial question. I am going to have to assume this is 
with PulseAudio and is fixed.

-- 
Rémi Denis-Courmont
http://www.remlab.net/--- End Message ---
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Processed: Re: vlc: segmentation fault with VDPAU

2016-02-15 Thread Debian Bug Tracking System 
Processing commands for cont...@bugs.debian.org:

> reassign 761165 mesa-vdpau-drivers
Bug #761165 [vlc] vlc: segmentation fault with VDPAU
Bug reassigned from package 'vlc' to 'mesa-vdpau-drivers'.
No longer marked as found in versions vlc/2.2.0~pre3-1, vlc/2.2.0~pre2-4, 
vlc/2.2.0~pre4-2, and vlc/2.2.0~pre4-1.
Ignoring request to alter fixed versions of bug #761165 to the same values 
previously set
> affects 761165 + vlc
Bug #761165 [mesa-vdpau-drivers] vlc: segmentation fault with VDPAU
Added indication that 761165 affects vlc
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
761165: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=761165
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

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

Processed: Re: reportbug: Sound goes away after seeking in VLC

2016-02-15 Thread Debian Bug Tracking System 
Processing commands for cont...@bugs.debian.org:

> fixed 796173 2.2.2-1
Bug #796173 [vlc] reportbug: Sound goes away after seeking in VLC
Marked as fixed in versions vlc/2.2.2-1.
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
796173: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=796173
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

___
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#814807: ffmpeg: FTBFS on mips

2016-02-15 Thread Carl Eugen Hoyos 
Hi!

I am looking at 
http://git.videolan.org/?p=ffmpeg.git;a=shortlog;h=refs/tags/n2.8.6 but I 
don't see a commit that may have affected roq audio encoding or muxing.
Are you able to test 2.8.5 with gcc-5_5.3.1-7 or 2.8.6 with gcc-5_5.3.1-6?

Carl Eugen

___
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#814646: vlc: unhandled symlink to directory conversion: /usr/share/doc/PACKAGE, /usr/share/bug/PACKAGE

2016-02-15 Thread Sebastian Ramacher 
On 2016-02-15 04:18:02, Andreas Beckmann wrote:
> On 2016-02-14 11:35, Sebastian Ramacher wrote:
> > On 2016-02-13 18:12:27, Andreas Beckmann wrote:
> >> 1m58.5s ERROR: FAIL: silently overwrites files via directory symlinks:
> >>   /usr/share/bug/libvlccore-dev/control (libvlccore-dev) != 
> >> /usr/share/bug/libvlccore8/control (libvlccore8)
> >> /usr/share/bug/libvlccore-dev -> libvlccore8
> >>   /usr/share/bug/libvlccore-dev/presubj (libvlccore-dev) != 
> >> /usr/share/bug/libvlccore8/presubj (libvlccore8)
> >> /usr/share/bug/libvlccore-dev -> libvlccore8
> >>   /usr/share/doc/libvlccore-dev/NEWS.Debian.gz (libvlccore-dev) != 
> >> /usr/share/doc/libvlccore8/NEWS.Debian.gz (libvlccore8)
> >> /usr/share/doc/libvlccore-dev -> libvlccore8
> >>   /usr/share/doc/libvlccore-dev/changelog.Debian.amd64.gz (libvlccore-dev) 
> >> != /usr/share/doc/libvlccore8/changelog.Debian.amd64.gz (libvlccore8)
> >> /usr/share/doc/libvlccore-dev -> libvlccore8
> >>   /usr/share/doc/libvlccore-dev/changelog.Debian.gz (libvlccore-dev) != 
> >> /usr/share/doc/libvlccore8/changelog.Debian.gz (libvlccore8)
> >> /usr/share/doc/libvlccore-dev -> libvlccore8
> >>   /usr/share/doc/libvlccore-dev/changelog.gz (libvlccore-dev) != 
> >> /usr/share/doc/libvlccore8/changelog.gz (libvlccore8)
> >> /usr/share/doc/libvlccore-dev -> libvlccore8
> >>   /usr/share/doc/libvlccore-dev/copyright (libvlccore-dev) != 
> >> /usr/share/doc/libvlccore8/copyright (libvlccore8)
> >> /usr/share/doc/libvlccore-dev -> libvlccore8
> > 
> > debian/libvlccore-dev.maintscript already has
> > 
> > symlink_to_dir /usr/share/doc/libvlccore-dev /usr/share/doc/libvlccore8 
> > 2.2.2-1~
> > 
> > So what went wrong here?
> > 
> > The /usr/share/bug/libvlccore-dev part is fixed in git.
> 
> 
> OK, let's rerun with some more debugging enabled (DPKG_DEBUG=1 and sed on 
> dpkg-maintscript-helper to have rm -v and mv -v)
> 
>   Preparing to unpack .../libvlccore-dev_2.2.2-3_amd64.deb ...
>   DEBUG: dpkg-maintscript-helper: Executing /usr/bin/dpkg-maintscript-helper 
> symlink_to_dir in preinst of libvlccore-dev
>   DEBUG: dpkg-maintscript-helper: SYMLINK=/usr/share/doc/libvlccore-dev -> 
> /usr/share/doc/libvlccore8 PACKAGE=libvlccore-dev:amd64 LASTVERSION=2.2.2-1~ 
> ACTION=upgrade PARAM=2.2.1-1~deb8u1
>   DEBUG: dpkg-maintscript-helper: Executing /usr/bin/dpkg-maintscript-helper 
> symlink_to_dir in preinst of libvlccore-dev
>   DEBUG: dpkg-maintscript-helper: SYMLINK=/usr/share/bug/libvlccore-dev -> 
> /usr/share/doc/libvlccore8 PACKAGE=libvlccore-dev:amd64 LASTVERSION=2.2.2-2~ 
> ACTION=upgrade PARAM=2.2.1-1~deb8u1
>   Unpacking libvlccore-dev (2.2.2-3) over (2.2.1-1~deb8u1) ...
>   Preparing to unpack .../libvlccore8_2.2.2-3_amd64.deb ...
>   DEBUG: dpkg-maintscript-helper: Executing /usr/bin/dpkg-maintscript-helper 
> symlink_to_dir in preinst of libvlccore8
>   DEBUG: dpkg-maintscript-helper: SYMLINK=/usr/share/doc/libvlccore8 -> 
> /usr/share/doc/vlc-data PACKAGE=libvlccore8:amd64 LASTVERSION=2.2.2-1~ 
> ACTION=upgrade PARAM=2.2.1-1~deb8u1
>   '/usr/share/doc/libvlccore8' -> '/usr/share/doc/libvlccore8.dpkg-backup'
>   Unpacking libvlccore8 (2.2.2-3) over (2.2.1-1~deb8u1) ...
> 
>   Setting up libvlccore8 (2.2.2-3) ...
>   DEBUG: dpkg-maintscript-helper: Executing /usr/bin/dpkg-maintscript-helper 
> symlink_to_dir in postinst of libvlccore8
>   DEBUG: dpkg-maintscript-helper: SYMLINK=/usr/share/doc/libvlccore8 -> 
> /usr/share/doc/vlc-data PACKAGE=libvlccore8:amd64 LASTVERSION=2.2.2-1~ 
> ACTION=configure PARAM=2.2.1-1~deb8u1
>   removed '/usr/share/doc/libvlccore8.dpkg-backup'
> 
>   Setting up libvlccore-dev (2.2.2-3) ...
>   DEBUG: dpkg-maintscript-helper: Executing /usr/bin/dpkg-maintscript-helper 
> symlink_to_dir in postinst of libvlccore-dev
>   DEBUG: dpkg-maintscript-helper: SYMLINK=/usr/share/doc/libvlccore-dev -> 
> /usr/share/doc/libvlccore8 PACKAGE=libvlccore-dev:amd64 LASTVERSION=2.2.2-1~ 
> ACTION=configure PARAM=2.2.1-1~deb8u1
>   DEBUG: dpkg-maintscript-helper: Executing /usr/bin/dpkg-maintscript-helper 
> symlink_to_dir in postinst of libvlccore-dev
>   DEBUG: dpkg-maintscript-helper: SYMLINK=/usr/share/bug/libvlccore-dev -> 
> /usr/share/doc/libvlccore8 PACKAGE=libvlccore-dev:amd64 LASTVERSION=2.2.2-2~ 
> ACTION=configure PARAM=2.2.1-1~deb8u1
> 
> 
> Looks like we have to deal with chained symlinks here:
>   /usr/share/doc/libvlccore-dev -> libvlccore8 -> vlc-data
> 
> This should work with dpkg-maintscript-helper if you use relative
> instead of absolute symlinks. "relative" means the output of
>   readlink $SYMLINK
> Absolute means the output from
>   readlink -f $SYMLINK
> must match, which cannot work while switching chained symlinks
> to directories.
> 
> Don't forget to bump the version.
> 
> So for libvlccore-dev.maintscript I'd suggest this (untested):
> 
> symlink_to_dir /usr/share/doc/libvlccore-dev libvlccore8 2.2.2-4~
> symlink_to_dir /usr/share/bug/libvlccore-dev libvlccore8 2.2.2-4~
> 
> Relative s

gratulacja

2016-02-15 Thread CHEVROLET COMPANY 
Gratulacje konta pocztowego wygrałeś $ 700.000,00 USD z Loterii 
Chevrolet Automobile Company, jesteś wysłać swoje dane osobowe do tego 
Urzędu teraz Gratulacje po raz kolejny.


___
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: preparing new RtMidi release, question about SO version

2016-02-15 Thread Stephen Sinclair 
On Mon, Feb 15, 2016 at 12:05 PM, Felipe Sateler  wrote:
> Hi Stephen
>
> On 10 February 2016 at 14:21, Stephen Sinclair  wrote:
>>
>> Hello,
>>
>> I am helping to update RtMidi, a C++ class for cross-platform MIDI
>> support.  There is a Debian librtmidi package.  Although this is just
>> a bug-fix release, and is planned to go from 2.1.0 to 2.1.1, we have
>> added some automake/libtool infrastructure, and a last debate is
>> whether to properly start supporting SO version according to libtool's
>> rules.
>
> Cool. I would be careful, though, because for C++ seemingly innocent
> changes can break the ABI. STK[1] was recently updated to use
> libtool's -release style versioning to avoid problems, as some changes
> broke ABI and were not noticed by upstream as such. This is
> particularly important for libraries that are used as static libraries
> (as this kind of breakage might go unnoticed for a  while).

So that's sort of part of my question -- I'd like to integrate better
ABI testing into the usual procedure, so as to avoid changes that
"were not noticed by upstream."  If such problems are more likely
noticed by packagers, would it be good practice to always request a
pre-release review by packagers before doing an upstream release?  Or
would that be too much noise?  (Not that releases are done very
often.. but I'm asking in the general case, I'll likely apply this as
a rule of thumb to other software I maintain.)

> [1] https://github.com/thestk/stk/pull/27
>>
>> Previous versions have made the error of treating SO version like the
>> version number, and producing binaries e.g. librtmidi.so.2.1.0.
>>
>> I was recommending changing this to properly reflect ABI
>> compatibility.  What would Debian maintainers prefer here?
>
> If (and only if) proper ABI versioning can be done, then I'd prefer
> that, of course. But using a -release style versioning would also be
> ok, and force rebuild of all reverse depedends on each upstream
> version. This should be ok, as there aren't many (6 by my count). This
> has the advantagae for upstream that they do not have to care about
> abi.

I don't think it's a huge overhead to check for ABI changes between
releases, provided this can be done (largely) automatically.  Which
should be possible, although I haven't explored the available tools
yet.  I'm not 100% sure what you mean by -release style versioning.
You mean append the library version as if it were the SO name?
Doesn't that lead to complications when there's a bugfix release that
happens to change the ABI? Or rather you seem to be suggesting a full
SO bump on every release.  I'm not sure if I follow.

>> I proposed making the new SO version 3.0.0, to really emphasize that
>> the ABI version is new, however since it's a bugfix release I don't
>> know if that's the recommended strategy.
>>
>> https://github.com/thestk/rtmidi/pull/59
>>
>> In any case I notice that the interface has changed a bit, e.g. some
>> functions have lost parameters, others have new parameters, since the
>> last release.
>
> I see the pull request has already been merged. I hope this message
> doesn't come too late.

Yes, the release has been done.  However, I think bumping the SO name
was the right call, seeing as the ABI signature of setErrorCallback()
changed.  I just figured we may as well use it as an opportunity to
make it significantly different from the release version while we're
at it.


Steve

___
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#814796: mpv: Missing libts shared library dependency.

2016-02-15 Thread James Cowgill 
On Mon, 2016-02-15 at 19:21 +0100, Tor Andersson wrote:
> Hi,
> 
> $ which mpv
> /usr/bin/mpv
> 
> $ ldd /usr/bin/mpv
[...]

From your ldd output, this file is likly to be the culprit:
 /usr/local/lib/libSDL2-2.0.so.0

Remove it and try running mpv again.

Thanks,
James

signature.asc
Description: This is a digitally signed message part
___
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#814796: mpv: Missing libts shared library dependency.

2016-02-15 Thread Tor Andersson 
Hi,

$ which mpv
/usr/bin/mpv

$ ldd /usr/bin/mpv
linux-vdso.so.1 (0x7ffe7d3c7000)
libva-glx.so.1 => /usr/lib/x86_64-linux-gnu/libva-glx.so.1
(0x7fd1e9b28000)
libva.so.1 => /usr/lib/x86_64-linux-gnu/libva.so.1 (0x7fd1e9912000)
libguess.so.1 => /usr/lib/x86_64-linux-gnu/libguess.so.1
(0x7fd1e970b000)
libdvdread.so.4 => /usr/lib/x86_64-linux-gnu/libdvdread.so.4
(0x7fd1e94ed000)
liblcms2.so.2 => /usr/lib/x86_64-linux-gnu/liblcms2.so.2
(0x7fd1e9293000)
libpulse.so.0 => /usr/lib/x86_64-linux-gnu/libpulse.so.0
(0x7fd1e9042000)
libbs2b.so.0 => /usr/lib/libbs2b.so.0 (0x7fd1e8e3d000)
libdvdnav.so.4 => /usr/lib/x86_64-linux-gnu/libdvdnav.so.4
(0x7fd1e8c28000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0
(0x7fd1e8a0b000)
libavutil.so.54 => /usr/lib/x86_64-linux-gnu/libavutil.so.54
(0x7fd1e87df000)
libavcodec.so.56 => /usr/lib/x86_64-linux-gnu/libavcodec.so.56
(0x7fd1e788b000)
libavformat.so.56 => /usr/lib/x86_64-linux-gnu/libavformat.so.56
(0x7fd1e754a000)
libswscale.so.3 => /usr/lib/x86_64-linux-gnu/libswscale.so.3
(0x7fd1e730)
libXv.so.1 => /usr/lib/x86_64-linux-gnu/libXv.so.1 (0x7fd1e70fb000)
libenca.so.0 => /usr/lib/x86_64-linux-gnu/libenca.so.0 (0x7fd1e6ec8000)
libXext.so.6 => /usr/lib/x86_64-linux-gnu/libXext.so.6 (0x7fd1e6cb6000)
libuuid.so.1 => /lib/x86_64-linux-gnu/libuuid.so.1 (0x7fd1e6ab1000)
librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x7fd1e68a9000)
libavfilter.so.5 => /usr/lib/x86_64-linux-gnu/libavfilter.so.5
(0x7fd1e6657000)
libcdio_paranoia.so.1 => /usr/lib/libcdio_paranoia.so.1 (0x7fd1e645)
libcdio_cdda.so.1 => /usr/lib/libcdio_cdda.so.1 (0x7fd1e6249000)
libcdio.so.13 => /usr/lib/libcdio.so.13 (0x7fd1e6025000)
libmpg123.so.0 => /usr/lib/x86_64-linux-gnu/libmpg123.so.0
(0x7fd1e5dca000)
libwayland-client.so.0 =>
/usr/lib/x86_64-linux-gnu/libwayland-client.so.0 (0x7fd1e5bbb000)
libwayland-cursor.so.0 =>
/usr/lib/x86_64-linux-gnu/libwayland-cursor.so.0 (0x7fd1e59b3000)
libxkbcommon.so.0 => /usr/lib/x86_64-linux-gnu/libxkbcommon.so.0
(0x7fd1e5777000)
libquvi.so.7 => /usr/lib/x86_64-linux-gnu/libquvi.so.7 (0x7fd1e556b000)
liblirc_client.so.0 => /usr/lib/liblirc_client.so.0 (0x7fd1e5365000)
libjpeg.so.62 => /usr/lib/x86_64-linux-gnu/libjpeg.so.62
(0x7fd1e510e000)
libavresample.so.2 => /usr/lib/x86_64-linux-gnu/libavresample.so.2
(0x7fd1e4eee000)
libavdevice.so.55 => /usr/lib/x86_64-linux-gnu/libavdevice.so.55
(0x7fd1e4cdd000)
liblua5.2.so.0 => /usr/lib/x86_64-linux-gnu/liblua5.2.so.0
(0x7fd1e4aaa000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x7fd1e47a9000)
libXinerama.so.1 => /usr/lib/x86_64-linux-gnu/libXinerama.so.1
(0x7fd1e45a6000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x7fd1e43a2000)
libbluray.so.1 => /usr/lib/x86_64-linux-gnu/libbluHi,

/usr/bin/mpv

ldd /usr/bin/mpv
linux-vdso.so.1 (0x7ffe7d3c7000)
libva-glx.so.1 => /usr/lib/x86_64-linux-gnu/libva-glx.so.1
(0x7fd1e9b28000)
libva.so.1 => /usr/lib/x86_64-linux-gnu/libva.so.1 (0x7fd1e9912000)
libguess.so.1 => /usr/lib/x86_64-linux-gnu/libguess.so.1
(0x7fd1e970b000)
libdvdread.so.4 => /usr/lib/x86_64-linux-gnu/libdvdread.so.4
(0x7fd1e94ed000)
liblcms2.so.2 => /usr/lib/x86_64-linux-gnu/liblcms2.so.2
(0x7fd1e9293000)
libpulse.so.0 => /usr/lib/x86_64-linux-gnu/libpulse.so.0
(0x7fd1e9042000)
libbs2b.so.0 => /usr/lib/libbs2b.so.0 (0x7fd1e8e3d000)
libdvdnav.so.4 => /usr/lib/x86_64-linux-gnu/libdvdnav.so.4
(0x7fd1e8c28000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0
(0x7fd1e8a0b000)
libavutil.so.54 => /usr/lib/x86_64-linux-gnu/libavutil.so.54
(0x7fd1e87df000)
libavcodec.so.56 => /usr/lib/x86_64-linux-gnu/libavcodec.so.56
(0x7fd1e788b000)
libavformat.so.56 => /usr/lib/x86_64-linux-gnu/libavformat.so.56
(0x7fd1e754a000)
libswscale.so.3 => /usr/lib/x86_64-linux-gnu/libswscale.so.3
(0x7fd1e730)
libXv.so.1 => /usr/lib/x86_64-linux-gnu/libXv.so.1 (0x7fd1e70fb000)
libenca.so.0 => /usr/lib/x86_64-linux-gnu/libenca.so.0 (0x7fd1e6ec8000)
libXext.so.6 => /usr/lib/x86_64-linux-gnu/libXext.so.6 (0x7fd1e6cb6000)
libuuid.so.1 => /lib/x86_64-linux-gnu/libuuid.so.1 (0x7fd1e6ab1000)
librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x7fd1e68a9000)
libavfilter.so.5 => /usr/lib/x86_64-linux-gnu/libavfilter.so.5
(0x7fd1e6657000)
libcdio_paranoia.so.1 => /usr/lib/libcdio_paranoia.so.1 (0x7fd1e645)
libcdio_cdda.so.1 => /usr/lib/libcdio_cdda.so.1 (0x7fd1e6249000)
libcdio.so.13 => /usr/lib/libcdio.so.13 (0x7fd1e6025000)
libmpg123.so.0 => /usr/lib/x86_64-linux-gnu/libmpg123.so.0
(0x7fd1e5dca000)
libwayland-client.so.0 =>
/usr/lib/x86_64-linux-gnu/libw

Processed: Re: Bug#814796: mpv: Missing libts shared library dependency.

2016-02-15 Thread Debian Bug Tracking System 
Processing control commands:

> tags -1 - d-i
Bug #814796 [mpv] mpv: Missing libts shared library dependency.
Removed tag(s) d-i.

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

___
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#814796: mpv: Missing libts shared library dependency.

2016-02-15 Thread James Cowgill 
Control: tags -1 - d-i

Hi,

On Mon, 2016-02-15 at 14:50 +0100, Tor wrote:
> Package: mpv
> Version: 0.6.2-2
> Severity: grave
> Tags: d-i
> Justification: renders package unusable
> 
> Dear Maintainer,
> 
> On Debian stable, the mpv command as installed doesn't run.
> 
> mpv: error while loading shared libraries: libts-0.0.so.0: cannot open shared 
> object file: No such file or directory

This is strange because libts isn't even a dependency of mpv.

Can you provide the output of these commands:
 which mpv
 ldd $(which mpv)

Thanks,
James

signature.asc
Description: This is a digitally signed message part
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

drumgizmo 0.9.8.1-3 MIGRATED to testing

2016-02-15 Thread Debian testing watch 
FYI: The status of the drumgizmo source package
in Debian's testing distribution has changed.

  Previous version: (not in testing)
  Current version:  0.9.8.1-3

-- 
This email is automatically generated once a day.  As the installation of
new packages into testing happens multiple times a day you will receive
later changes on the next day.
See https://release.debian.org/testing-watch/ for more information.

___
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: supercollider-sc3-plugins_3.7.0~beta+git20151221.f978dc2~repack-4_amd64.changes REJECTED

2016-02-15 Thread Hanno Zulla 
Hello Petter,

the main issue is fixed at



...but now that I learned a few new things to take care of while
packaging Sonic Pi, let me fix those lintian warnings before we try again.

Will report back when done.

Regards,

Hanno

___
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#814813: spurious output to stderr

2016-02-15 Thread Daniel Pocock 
Package: flactag
Severity: important

When starting up and also after pressing the 'W' key to write, flactag
is sending a whole lot of errors to stderr.  From comments in the
discussion forums it looks like they may be originating from libmusicbrainz

When the errors appear after displaying the UI, they corrupt the UI, it
is no longer possible to see the list of keystrokes at the bottom of the
screen.  Pressing 'Q' exits the application though.

- what is the impact of ignoring these elements?  Should flactag just
ignore them (or have a command line switch to ignore them) without
printing errors?

- could the errors be shown in the UI?  Maybe libmusicbrainz needs to
support some logging framework and the UI could then intercept log
messages to display them cleanly


Unrecognised disc element: 'offset-list'
Unrecognised release element: 'release-event-list'
Unrecognised release element: 'cover-art-archive'
Unrecognised disc element: 'offset-list'
Unrecognised disc element: 'offset-list'
Unrecognised disc element: 'offset-list'
Unrecognised disc element: 'offset-list'
Unrecognised release element: 'release-event-list'
Unrecognised release element: 'cover-art-archive'
Unrecognised disc element: 'offset-list'
Unrecognised disc element: 'offset-list'
Unrecognised disc element: 'offset-list'
Unrecognised disc element: 'offset-list'
Unrecognised release element: 'release-event-list'
Unrecognised release element: 'cover-art-archive'
Unrecognised disc element: 'offset-list'
Unrecognised disc element: 'offset-list'
Unrecognised disc element: 'offset-list'
Unrecognised disc element: 'offset-list'
Unrecognised release element: 'release-event-list'
Unrecognised release element: 'cover-art-archive'
Unrecognised disc element: 'offset-list'
Unrecognised disc element: 'offset-list'
Unrecognised disc element: 'offset-list'
Unrecognised disc element: 'offset-list'
Unrecognised track attribute: 'id'
Unrecognised track attribute: 'id'
Unrecognised track attribute: 'id'
Unrecognised track attribute: 'id'
Unrecognised track attribute: 'id'
Unrecognised track attribute: 'id'
Unrecognised track attribute: 'id'
Unrecognised track attribute: 'id'
Unrecognised track attribute: 'id'
Unrecognised track attribute: 'id'
Unrecognised track attribute: 'id'
Unrecognised track attribute: 'id'
Unrecognised track attribute: 'id'
Unrecognised track attribute: 'id'
Unrecognised relation attribute: 'type-id'
Unrecognised relation attribute: 'type-id'
Unrecognised release element: 'release-event-list'
Unrecognised release element: 'cover-art-archive'
Unrecognised disc element: 'offset-list'
Unrecognised disc element: 'offset-list'
Unrecognised disc element: 'offset-list'
Unrecognised disc element: 'offset-list'
Unrecognised track attribute: 'id'
Unrecognised track attribute: 'id'
Unrecognised track attribute: 'id'
Unrecognised track attribute: 'id'
Unrecognised track attribute: 'id'
Unrecognised track attribute: 'id'
Unrecognised track attribute: 'id'
Unrecognised track attribute: 'id'
Unrecognised track attribute: 'id'
Unrecognised track attribute: 'id'
Unrecognised track attribute: 'id'
Unrecognised track attribute: 'id'
Unrecognised track attribute: 'id'
Unrecognised track attribute: 'id'
Unrecognised relation attribute: 'type-id'
Unrecognised relation attribute: 'type-id'
Unrecognised release element: 'release-event-list'
Unrecognised release element: 'cover-art-archive'
Unrecognised disc element: 'offset-list'
Unrecognised track attribute: 'id'
Unrecognised track attribute: 'id'
Unrecognised track attribute: 'id'
Unrecognised track attribute: 'id'
Unrecognised track attribute: 'id'
Unrecognised track attribute: 'id'
Unrecognised track attribute: 'id'
Unrecognised track attribute: 'id'
Unrecognised track attribute: 'id'
Unrecognised track attribute: 'id'
Unrecognised track attribute: 'id'
Unrecognised track attribute: 'id'
Unrecognised track attribute: 'id'
Unrecognised track attribute: 'id'
Unrecognised track attribute: 'id'
Unrecognised disc element: 'offset-list'
Unrecognised track attribute: 'id'
Unrecognised track attribute: 'id'
Unrecognised track attribute: 'id'
Unrecognised track attribute: 'id'
Unrecognised track attribute: 'id'
Unrecognised track attribute: 'id'
Unrecognised track attribute: 'id'
Unrecognised track attribute: 'id'
Unrecognised track attribute: 'id'
Unrecognised track attribute: 'id'
Unrecognised track attribute: 'id'
Unrecognised track attribute: 'id'
Unrecognised track attribute: 'id'
Unrecognised track attribute: 'id'
Unrecognised disc element: 'offset-list'
Unrecognised track attribute: 'id'
Unrecognised track attribute: 'id'
Unrecognised track attribute: 'id'
Unrecognised track attribute: 'id'
Unrecognised track attribute: 'id'
Unrecognised track attribute: 'id'
Unrecognised track attribute: 'id'
Unrecognised track attribute: 'id'
Unrecognised track attribute: 'id'
Unrecognised track attribute: 'id'
Unrecognised track attribute: 'id'
Unrecognised track attribute: 'id'
Unrecognised track attribute: 'id'
Unrecognis

Bug#814807: ffmpeg: FTBFS on mips

2016-02-15 Thread Emilio Pozuelo Monfort 
Package: ffmpeg
Version: 7:2.8.5-1+b1
Severity: serious

Your package failed to build on mips:

[roq_dpcm @ 0xa345a0] packet is too small
Error while decoding stream #0:0: Invalid argument
/«PKGBUILDDIR»/debian/standard/tests/data/fate/acodec-roqaudio.roq: Invalid 
data found when processing input
size=   0kB time=00:00:00.00 bitrate=N/A
video:0kB audio:0kB subtitle:0kB other streams:0kB global headers:0kB muxing 
overhead: unknown
Output file is empty, nothing was encoded (check -ss / -t / -frames parameters 
if used)
Conversion failed!
/«PKGBUILDDIR»/tests/Makefile:203: recipe for target 'fate-acodec-roqaudio' 
failed
make[2]: *** [fate-acodec-roqaudio] Error 69

Full logs at:

https://buildd.debian.org/status/logs.php?pkg=ffmpeg&ver=7%3A2.8.6-1&arch=mips

___
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: supercollider-sc3-plugins_3.7.0~beta+git20151221.f978dc2~repack-4_amd64.changes REJECTED

2016-02-15 Thread Hanno Zulla 
Hello Thorsten,
hello Petter,

Thorsten:
> unfortunately you forgot the CC-BY-SA 3.0 license mentioned in
> supercollider-sc3-plugins/source/ATK/sc/README

Petter:
> As far as I can tell, the README refer to files that are not included
> in the source (at least not in git)

Indeed, they are not. I had asked upstream about this back in January:

https://github.com/supercollider/sc3-plugins/issues/61

The actual developers responsible for this code didn't respond, but as
far as my investigation goes, there is no CC-BY-SA 3.0 content found in
the repacked Debian source package.

Two different versions of the ATK library itself used to be shipped with
two plugins of the upstream release, but upstream has accepted a fix for
this here:

https://github.com/supercollider/sc3-plugins/pull/56

As of now, the upstream repo contains the ATK library only indirectly as
a git submodule and then compiles against it.

To assist us at Debian with packaging, upstream has added a configure
option to allow compiling against the system's ATK library instead here:

https://github.com/supercollider/sc3-plugins/pull/53

So in the end, there is no ATK library and no ATK filter kernels shipped
with the upstream sources

Thorsten:
> unfortunately you forgot the CC-BY-SA 3.0 license mentioned in
> supercollider-sc3-plugins/source/ATK/sc/README

Petter:
> As for ATKDocsLicensing.schelp, as far as I can tell it refer to the
> license of the CC logo or some documentation that is not in git:

This, unfortunately, is true. The file

source/ATK/sc/HelpSource/Guides/Intro-to-the-ATK.schelp

is CC-BY-SA 3.0 and I will fix that for the package.

Regards,

Hanno

P.S.: Also, there are a number of recordings mentioned in

source/ATK/sc/README_RECORDINGS
source/ATK/sc/HelpSource/Other/ATKLicensing.schelp

which, while mentioned, aren't actually part of upstream's source
distribution.


___
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: preparing new RtMidi release, question about SO version

2016-02-15 Thread Felipe Sateler 
Hi Stephen

On 10 February 2016 at 14:21, Stephen Sinclair  wrote:
>
> Hello,
>
> I am helping to update RtMidi, a C++ class for cross-platform MIDI
> support.  There is a Debian librtmidi package.  Although this is just
> a bug-fix release, and is planned to go from 2.1.0 to 2.1.1, we have
> added some automake/libtool infrastructure, and a last debate is
> whether to properly start supporting SO version according to libtool's
> rules.

Cool. I would be careful, though, because for C++ seemingly innocent
changes can break the ABI. STK[1] was recently updated to use
libtool's -release style versioning to avoid problems, as some changes
broke ABI and were not noticed by upstream as such. This is
particularly important for libraries that are used as static libraries
(as this kind of breakage might go unnoticed for a  while).


[1] https://github.com/thestk/stk/pull/27
>
> Previous versions have made the error of treating SO version like the
> version number, and producing binaries e.g. librtmidi.so.2.1.0.
>
> I was recommending changing this to properly reflect ABI
> compatibility.  What would Debian maintainers prefer here?

If (and only if) proper ABI versioning can be done, then I'd prefer
that, of course. But using a -release style versioning would also be
ok, and force rebuild of all reverse depedends on each upstream
version. This should be ok, as there aren't many (6 by my count). This
has the advantagae for upstream that they do not have to care about
abi.

>
> I proposed making the new SO version 3.0.0, to really emphasize that
> the ABI version is new, however since it's a bugfix release I don't
> know if that's the recommended strategy.
>
> https://github.com/thestk/rtmidi/pull/59
>
> In any case I notice that the interface has changed a bit, e.g. some
> functions have lost parameters, others have new parameters, since the
> last release.

I see the pull request has already been merged. I hope this message
doesn't come too late.

-- 

Saludos,
Felipe Sateler

___
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#814796: mpv: Missing libts shared library dependency.

2016-02-15 Thread Tor 
Package: mpv
Version: 0.6.2-2
Severity: grave
Tags: d-i
Justification: renders package unusable

Dear Maintainer,

On Debian stable, the mpv command as installed doesn't run.

mpv: error while loading shared libraries: libts-0.0.so.0: cannot open shared 
object file: No such file or directory

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

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

Versions of packages mpv depends on:
ii  libasound2  1.0.28-1
ii  libass5 0.10.2-3
ii  libavcodec566:11.4-1~deb8u1
ii  libavdevice55   6:11.4-1~deb8u1
ii  libavfilter56:11.4-1~deb8u1
ii  libavformat56   6:11.4-1~deb8u1
ii  libavresample2  6:11.4-1~deb8u1
ii  libavutil54 6:11.4-1~deb8u1
ii  libbluray1  1:0.6.2-1
ii  libbs2b03.1.0+dfsg-2.1
ii  libc6   2.19-18+deb8u2
ii  libcdio-cdda1   0.83-4.2
ii  libcdio-paranoia1   0.83-4.2
ii  libcdio13   0.83-4.2
ii  libdvdnav4  5.0.1-1
ii  libdvdread4 5.0.0-1
ii  libegl1-mesa [libegl1-x11]  10.3.2-1+deb8u1
ii  libenca01.16-1
ii  libgl1-mesa-glx [libgl1]10.3.2-1+deb8u1
ii  libguess1   1.2-1
ii  libjack-jackd2-0 [libjack-0.116]1.9.10+20140719git3eb0ae6a~dfsg-2
ii  libjpeg62-turbo 1:1.3.1-12
ii  liblcms2-2  2.6-3+b3
ii  liblircclient0  0.9.0~pre1-1.2
ii  liblua5.2-0 5.2.3-1.1
ii  libmpg123-0 1.20.1-2
ii  libpulse0   5.0-13
ii  libquvi70.4.1-3
ii  libsdl2-2.0-0   2.0.2+dfsg1-6
ii  libswscale3 6:11.4-1~deb8u1
ii  libuuid12.25.2-6
ii  libva-glx1  1.4.1-1
ii  libva-x11-1 1.4.1-1
ii  libva1  1.4.1-1
ii  libvdpau1   0.8-3+deb8u2
ii  libwayland-client0  1.6.0-2
ii  libwayland-cursor0  1.6.0-2
ii  libwayland-egl1-mesa [libwayland-egl1]  10.3.2-1+deb8u1
ii  libx11-62:1.6.2-3
ii  libxext62:1.3.3-1
ii  libxinerama12:1.1.3-1+b1
ii  libxkbcommon0   0.4.3-2
ii  libxrandr2  2:1.4.2-1+b1
ii  libxss1 1:1.2.2-1
ii  libxv1  2:1.0.10-1+b1
ii  zlib1g  1:1.2.8.dfsg-2+b1

mpv recommends no packages.

mpv suggests no packages.

-- no debconf information

___
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: supercollider-sc3-plugins_3.7.0~beta+git20151221.f978dc2~repack-4_amd64.changes REJECTED

2016-02-15 Thread Petter Reinholdtsen 

I'm dropping the ftpmasters from CC for now, as I do not really
understand the comment and hope Hanno or someone else understand what
need to be done.

[Thorsten Alteholz]
> Hi Petter,
>
> unfortunately you forgot the CC-BY-SA 3.0 license mentioned in 
>  supercollider-sc3-plugins/source/ATK/sc/README
>  
> supercollider-sc3-plugins/source/ATK/sc/HelpSource/Other/ATKDocsLicensing.schelp

Very good to have feedback.

As far as I can tell, the README refer to files that are not included in
the source (at least not in git):

  The filter kernels distributed with the Ambisonic Toolkit are licensed
  under a reative Commons Attribution-Share Alike 3.0 Unported License
  and are copyright the Ambisonic Toolkit Community and Joseph Anderson,
  2011.

  http://creativecommons.org/licenses/by-sa/3.0/

I am not sure, as I do not understand what "The filter kernels" refer
to, but could not find anything in the source that I would understand to
be "filter kernels".

As for ATKDocsLicensing.schelp, as far as I can tell it refer to the
license of the CC logo or some documentation that is not in git:

  title:: ATK Documentation License
  summary:: Ambisonic Toolkit Documentation License
  categories:: Libraries>Ambisonic Toolkit>Licensing
  related:: Other/ATKLicensing

  image::ccbysa3_88x31.png::

  link::Guides/Intro-to-the-ATK##Ambisonic Toolkit help documentation::
  for SuperCollider is licensed under a
  link::http://creativecommons.org/licenses/by-sa/3.0/##Creative Commons
  Attribution-Share Alike 3.0 Unported License::.

  Executable Ambisonic Toolkit code for SuperCollider remains under the
  GPL as stated in the Ambisonic Toolkit's and SuperCollider's main
  link::Other/ATKLicensing##license conditions::.

  To supply attribution for a help document (which may have multiple
  contributors), unless otherwise indicated you may credit "Ambisonic
  Toolkit for SuperCollider 3 documentation contributors".

How do you interpret this?

-- 
Happy hacking
Petter Reinholdtsen

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

Processed: Bug#814646 marked as pending

2016-02-15 Thread Debian Bug Tracking System 
Processing commands for cont...@bugs.debian.org:

> tag 814646 pending
Bug #814646 [src:vlc] vlc: unhandled symlink to directory conversion: 
/usr/share/doc/PACKAGE, /usr/share/bug/PACKAGE
Added tag(s) pending.
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
814646: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=814646
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

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