csoundqt is marked for autoremoval from testing

[Debian testing autoremoval watch]

csoundqt 0.9.2.1-1 is marked for autoremoval from testing on 2016-06-16

It (build-)depends on packages with these RC bugs:
823316: stk: contains non-free Steinberg ASIO library


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

csound is marked for autoremoval from testing

[Debian testing autoremoval watch]

csound 1:6.05~dfsg1-7 is marked for autoremoval from testing on 2016-06-16

It (build-)depends on packages with these RC bugs:
823316: stk: contains non-free Steinberg ASIO library


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

stk is marked for autoremoval from testing

[Debian testing autoremoval watch]

stk 4.5.0-3 is marked for autoremoval from testing on 2016-06-16

It is affected by these RC bugs:
823316: stk: contains non-free Steinberg ASIO library


___
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: RFS: audacious/3.6.2-2~bpo8+1 and audacious-plugins/3.6.2-2~bpo8+1

[Mattia Rizzolo]

On Tue, May 10, 2016 at 06:03:18PM -0400, Nicholas D Steeves wrote:
> > Now, umh, with `push debian/%(bpo_tag)s would be what I usually do
> > without a branch.
> 
> Ohhh, I think I'm starting to understand now.  So what happens that
> the local master branch gets ahead of the remote without --detach, but
> that's ok.  It's ok because git pushes a snapshot of the local changed
> state to a remote state is only referenced by the tag.  If for some
> reason there was a bug in the debian/%(bpo_tag)s version, that's not
> in the debian/version-revision...well, that's where it feels strange
> to me.  So then one would make further changes to the local repo,
> local master would get further out of sync from remote master, but
> that wouldn't matter because the local state of master is only ever
> reflected as a tag on the remote?

Well, you are not supposed to have your local master out of sync with
the remote one.  doing `git checkout debian/version-revision` detaches
your head from a branch, and the stuff you do that are only referenced
by the tag, yep.  But if you do a `git checkout master` you ought to go
back to the very place the remote master is, and doing stuff that means
pushing to the remote master, and stuff pushed there is going to be on
the next unstable upload.

> Had I made my mistake at this
> point, it seems like it would have been a huge mess!

I see it's easy to do something wrong by accident here ;)

> > given that now a branch is used instead the workflow is:
> 
> This makes sense to me, but I'm still unclear why "git checkout
> jessie-backports && git merge debian/version-revision" is preferred
> over "git rebase debian/version-revision", when version-bumping the
> bpo.  I guess the question is: For a version bump of a bpo, should the
> changelog of a new-version bpo mention the previous bpo, or should it
> only contain a single "Rebuild for $stable-backports" entry?

The "jessie-backports branch workflow" I keep as a reference is the one
used by devscripts, that actually keeps the old backports entry in the
changelog during the merge.

> The
> semantics of checkout+merge seem to favour a bpo changelog that
> mentions prior versions (independent parallel branch with coherent
> history and imported updates), while the semantics of git rebase seem
> to favour a series of bpo forks (branch is a history of forks).

my idea of bpo is a series of separated forks, and here detached tags
work better than a branch.  But I think this is really a matter of how
you see it and how you work better, the actual thing doesn't really
change much.

> Mattia, thank you for taking the time to help me understand,
> I appreciate it a lot,
> Nicholas

Sorry for making this actually simple backport look like a huge
complicated deal :)

-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
more about me:  https://mapreri.org : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


signature.asc
Description: PGP signature
___
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#823953: inkscape: PDF+Latex export completely broken

[Mattia Rizzolo]

control: tag -1 upstream
control: notfound -1 0.91-5~bpo8+1
control: found -1 0.91-5
control: forwarded -1 https://qbugs.launchpad.net/inkscape/+bug/1417470

On Tue, May 10, 2016 at 11:05:43AM -0600, Daniel Blaschke wrote:
> Package: inkscape
> Version: 0.91-5~bpo8+1

bpo bugs are not to be sent to the Debian BTS.
But given that this issue actually affects also the regular release,
tweaking the version.

> see also the according launchbad bug report:
> https://bugs.launchpad.net/ubuntu/+bug/1417470

So this is an upstream bug.
Marking as so (but using the /inkscape/ part of the bug, instead of the
ubuntu one.  Also I added a Debian task to the LP bug, pointing to this
very bug.

-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
more about me:  https://mapreri.org : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


signature.asc
Description: PGP signature
___
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: RFS: audacious/3.6.2-2~bpo8+1 and audacious-plugins/3.6.2-2~bpo8+1

[Nicholas D Steeves]

On 10 May 2016 at 11:42, Mattia Rizzolo  wrote:
> On Tue, May 10, 2016 at 03:17:30PM +, Mattia Rizzolo wrote:
>> So, I'm going to use a local bpo of sndio instead (also because yours
>> would not be nice to upload due to the +2.  why 2 identical changelog
>> entries??), and try to build audacious again.  Tomorrow first thing in
>> the morning most probably.
>
> Actually, already did and uploading now.
>
> Enjoy ;)

Yay! :-)

___
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: RFS: audacious/3.6.2-2~bpo8+1 and audacious-plugins/3.6.2-2~bpo8+1

[Nicholas D Steeves]

On 10 May 2016 at 11:17, Mattia Rizzolo  wrote:
> Sorry for the delay, these days are crazy for me

That's life, right?!  :-)

> On Fri, May 06, 2016 at 02:05:17PM -0400, Nicholas D Steeves wrote:
>> I've just purged that repo and uploaded a bpo of libsndio to mentors.
>
> mh, no.
>
> There is already one in bpo-NEW from 2 days ago :)
> https://ftp-master.debian.org/new/sndio_1.1.0-2~bpo8%2B1.html
>
> So, I'm going to use a local bpo of sndio instead (also because yours
> would not be nice to upload due to the +2.  why 2 identical changelog
> entries??), and try to build audacious again.  Tomorrow first thing in
> the morning most probably.

;-) That's mine.  I contacted Peter Piwowarski asking if he'd like me
to maintain a backport as soon as I realised that an audacious bpo
depended on having a sndio bpo in the archive.  I'm not sure where two
identical changelog entries for bpo+1 and bpo+2 came from...that's
very strange.  Thankfully my sponsor caught it during the application
process!

>> Message-ID: 
>> 

Re: supercollider 3.7.0 in alioth to try

[Felipe Sateler]

On 10 May 2016 at 17:43, Dan S  wrote:
> 2016-05-10 21:33 GMT+01:00 Felipe Sateler :
>> On 10 May 2016 at 17:05, Dan S  wrote:
>>> 2016-05-10 18:23 GMT+01:00 Felipe Sateler :
 On 6 May 2016 at 13:32, Dan S  wrote:
> 2016-05-04 16:09 GMT+01:00 Felipe Sateler :
>> On 4 May 2016 at 11:57, Dan S  wrote:
>>> 2016-04-26 19:23 GMT+01:00 Felipe Sateler :
 On 25 April 2016 at 18:12, Felipe Sateler  wrote:
> On 20 March 2016 at 12:52, Dan S  wrote:
>>
>> Hi all,
>>
>> There's a new release of SuperCollider out (3.7) and I've imported 
>> and
>> updated the packaging at pkg-multimedia/supercollider.git . It builds
>> and works for me (on x64), and I'd like to ask others to have a look
>> at it and consider testing/uploading it.
>
> I reproduce the same failure as Hanno, also on x64:
>
> /usr/bin/ld: ../../external_libraries/libtlsf.a(tlsf.c.o): relocation
> R_X86_64_32S against `.rodata' can not be used when making a shared
> object; recompile with -fPIC
> ../../external_libraries/libtlsf.a: error adding symbols: Bad value
>
> adding said -fPIC flag to tlsf target continues until:
 
> /usr/bin/ld: cannot find -lQt5::OpenGL
>
>
> Could you have a look?

 This seems to be a missing build-dep on libqt5opengl5-dev. It builds
 fine after that.

 BTW, why do we disable the testsuite?
>>>
>>> (Sorry for the delay - didn't spot your second message)
>>>
>>> Regarding the testsuite: IIRC it doesn't succeed on all archs, and
>>> that's beyond our control. In 2013 you asked the same question, you
>>> asked "Why disable the testsuite? After all, if it is failing, its for
>>> a reason" and my answer was the following:
>>>
 That's what I thought too at first. However it's not intended to be
 packaged (it doesn't build anything), and after discussion with the
 developer who actually made and maintains that testsuite, he wanted it
 that way... (It's not really a testsuite of supercollider, btw, I
 think covers the 'supernova' component.)
>>
>> Heh, sorry for forgetting about that. I added a comment to that effect
>> to debian/rules.
>
> Thanks. Also thanks for the suggested build fixes. Now I've upgraded
> my OS I can finally confirm them, so I've pushed them (and proposed
> them upstream too).

 So now we have several build failures:

 https://buildd.debian.org/status/package.php?p=supercollider

 All of them in the embedded oscpack, but not all of them the same. I
 was going to suggest using the available library, but it is orphaned.
 Anyone up to take the maintainance of oscpack?
>>>
>>> One thing to note: it's only "supernova" that makes use of oscpack,
>>> and supernova is optional since it's a drop-in replacement for
>>> "scsynth".
>>> So, one cop-out alternative available to us (if oscpack isn't getting
>>> fixed) is that on some platforms we could disable building it
>>> (-DSUPERNOVA=0) and disable packaging it.
>>
>> We are already doing that[1], so that is a possible course of action.
>>
>> BTW, is it possible to use a system oscpack? It looks like the library
>> is barely ever updated, so maybe I could just bite the bullet and
>> upload it.
>
> Possible, yes, should be. However note that the pack did get a minor
> tweak in the supercollider local copy, see first commit here:
> https://github.com/supercollider/supercollider/commits/master/external_libraries/oscpack_1_1_0

Hmm. Should be possible to include in the debian version of oscpack.
I'm not sure if that breaks abi, though. Would the inlined method
still show up in the shared library?

> I guess by "upload" you mean upload the latest (1.1.0) oscpack to unstable?
> https://packages.debian.org/source/sid/oscpack
> I don't see much harm in uploading, though I've no idea of the
> present/future state of the lib - seems to be a little stale at
> present.

As long as there are users... Right now sc would be the only one.

But if the lib is dead, then probably sc (upstream) should not rely on it.

-- 

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

Re: supercollider 3.7.0 in alioth to try

[Dan S]

2016-05-10 21:33 GMT+01:00 Felipe Sateler :
> On 10 May 2016 at 17:05, Dan S  wrote:
>> 2016-05-10 18:23 GMT+01:00 Felipe Sateler :
>>> On 6 May 2016 at 13:32, Dan S  wrote:
 2016-05-04 16:09 GMT+01:00 Felipe Sateler :
> On 4 May 2016 at 11:57, Dan S  wrote:
>> 2016-04-26 19:23 GMT+01:00 Felipe Sateler :
>>> On 25 April 2016 at 18:12, Felipe Sateler  wrote:
 On 20 March 2016 at 12:52, Dan S  wrote:
>
> Hi all,
>
> There's a new release of SuperCollider out (3.7) and I've imported and
> updated the packaging at pkg-multimedia/supercollider.git . It builds
> and works for me (on x64), and I'd like to ask others to have a look
> at it and consider testing/uploading it.

 I reproduce the same failure as Hanno, also on x64:

 /usr/bin/ld: ../../external_libraries/libtlsf.a(tlsf.c.o): relocation
 R_X86_64_32S against `.rodata' can not be used when making a shared
 object; recompile with -fPIC
 ../../external_libraries/libtlsf.a: error adding symbols: Bad value

 adding said -fPIC flag to tlsf target continues until:
>>> 
 /usr/bin/ld: cannot find -lQt5::OpenGL


 Could you have a look?
>>>
>>> This seems to be a missing build-dep on libqt5opengl5-dev. It builds
>>> fine after that.
>>>
>>> BTW, why do we disable the testsuite?
>>
>> (Sorry for the delay - didn't spot your second message)
>>
>> Regarding the testsuite: IIRC it doesn't succeed on all archs, and
>> that's beyond our control. In 2013 you asked the same question, you
>> asked "Why disable the testsuite? After all, if it is failing, its for
>> a reason" and my answer was the following:
>>
>>> That's what I thought too at first. However it's not intended to be
>>> packaged (it doesn't build anything), and after discussion with the
>>> developer who actually made and maintains that testsuite, he wanted it
>>> that way... (It's not really a testsuite of supercollider, btw, I
>>> think covers the 'supernova' component.)
>
> Heh, sorry for forgetting about that. I added a comment to that effect
> to debian/rules.

 Thanks. Also thanks for the suggested build fixes. Now I've upgraded
 my OS I can finally confirm them, so I've pushed them (and proposed
 them upstream too).
>>>
>>> So now we have several build failures:
>>>
>>> https://buildd.debian.org/status/package.php?p=supercollider
>>>
>>> All of them in the embedded oscpack, but not all of them the same. I
>>> was going to suggest using the available library, but it is orphaned.
>>> Anyone up to take the maintainance of oscpack?
>>
>> One thing to note: it's only "supernova" that makes use of oscpack,
>> and supernova is optional since it's a drop-in replacement for
>> "scsynth".
>> So, one cop-out alternative available to us (if oscpack isn't getting
>> fixed) is that on some platforms we could disable building it
>> (-DSUPERNOVA=0) and disable packaging it.
>
> We are already doing that[1], so that is a possible course of action.
>
> BTW, is it possible to use a system oscpack? It looks like the library
> is barely ever updated, so maybe I could just bite the bullet and
> upload it.

Possible, yes, should be. However note that the pack did get a minor
tweak in the supercollider local copy, see first commit here:
https://github.com/supercollider/supercollider/commits/master/external_libraries/oscpack_1_1_0

I guess by "upload" you mean upload the latest (1.1.0) oscpack to unstable?
https://packages.debian.org/source/sid/oscpack
I don't see much harm in uploading, though I've no idea of the
present/future state of the lib - seems to be a little stale at
present.

Dan

___
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 3.7.0 in alioth to try

[Felipe Sateler]

On 10 May 2016 at 17:05, Dan S  wrote:
> 2016-05-10 18:23 GMT+01:00 Felipe Sateler :
>> On 6 May 2016 at 13:32, Dan S  wrote:
>>> 2016-05-04 16:09 GMT+01:00 Felipe Sateler :
 On 4 May 2016 at 11:57, Dan S  wrote:
> 2016-04-26 19:23 GMT+01:00 Felipe Sateler :
>> On 25 April 2016 at 18:12, Felipe Sateler  wrote:
>>> On 20 March 2016 at 12:52, Dan S  wrote:

 Hi all,

 There's a new release of SuperCollider out (3.7) and I've imported and
 updated the packaging at pkg-multimedia/supercollider.git . It builds
 and works for me (on x64), and I'd like to ask others to have a look
 at it and consider testing/uploading it.
>>>
>>> I reproduce the same failure as Hanno, also on x64:
>>>
>>> /usr/bin/ld: ../../external_libraries/libtlsf.a(tlsf.c.o): relocation
>>> R_X86_64_32S against `.rodata' can not be used when making a shared
>>> object; recompile with -fPIC
>>> ../../external_libraries/libtlsf.a: error adding symbols: Bad value
>>>
>>> adding said -fPIC flag to tlsf target continues until:
>> 
>>> /usr/bin/ld: cannot find -lQt5::OpenGL
>>>
>>>
>>> Could you have a look?
>>
>> This seems to be a missing build-dep on libqt5opengl5-dev. It builds
>> fine after that.
>>
>> BTW, why do we disable the testsuite?
>
> (Sorry for the delay - didn't spot your second message)
>
> Regarding the testsuite: IIRC it doesn't succeed on all archs, and
> that's beyond our control. In 2013 you asked the same question, you
> asked "Why disable the testsuite? After all, if it is failing, its for
> a reason" and my answer was the following:
>
>> That's what I thought too at first. However it's not intended to be
>> packaged (it doesn't build anything), and after discussion with the
>> developer who actually made and maintains that testsuite, he wanted it
>> that way... (It's not really a testsuite of supercollider, btw, I
>> think covers the 'supernova' component.)

 Heh, sorry for forgetting about that. I added a comment to that effect
 to debian/rules.
>>>
>>> Thanks. Also thanks for the suggested build fixes. Now I've upgraded
>>> my OS I can finally confirm them, so I've pushed them (and proposed
>>> them upstream too).
>>
>> So now we have several build failures:
>>
>> https://buildd.debian.org/status/package.php?p=supercollider
>>
>> All of them in the embedded oscpack, but not all of them the same. I
>> was going to suggest using the available library, but it is orphaned.
>> Anyone up to take the maintainance of oscpack?
>
> One thing to note: it's only "supernova" that makes use of oscpack,
> and supernova is optional since it's a drop-in replacement for
> "scsynth".
> So, one cop-out alternative available to us (if oscpack isn't getting
> fixed) is that on some platforms we could disable building it
> (-DSUPERNOVA=0) and disable packaging it.

We are already doing that[1], so that is a possible course of action.

BTW, is it possible to use a system oscpack? It looks like the library
is barely ever updated, so maybe I could just bite the bullet and
upload it.

[1] 
https://anonscm.debian.org/cgit/pkg-multimedia/supercollider.git/tree/debian/rules#n25

-- 

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

Re: supercollider 3.7.0 in alioth to try

[Dan S]

2016-05-10 18:23 GMT+01:00 Felipe Sateler :
> On 6 May 2016 at 13:32, Dan S  wrote:
>> 2016-05-04 16:09 GMT+01:00 Felipe Sateler :
>>> On 4 May 2016 at 11:57, Dan S  wrote:
 2016-04-26 19:23 GMT+01:00 Felipe Sateler :
> On 25 April 2016 at 18:12, Felipe Sateler  wrote:
>> On 20 March 2016 at 12:52, Dan S  wrote:
>>>
>>> Hi all,
>>>
>>> There's a new release of SuperCollider out (3.7) and I've imported and
>>> updated the packaging at pkg-multimedia/supercollider.git . It builds
>>> and works for me (on x64), and I'd like to ask others to have a look
>>> at it and consider testing/uploading it.
>>
>> I reproduce the same failure as Hanno, also on x64:
>>
>> /usr/bin/ld: ../../external_libraries/libtlsf.a(tlsf.c.o): relocation
>> R_X86_64_32S against `.rodata' can not be used when making a shared
>> object; recompile with -fPIC
>> ../../external_libraries/libtlsf.a: error adding symbols: Bad value
>>
>> adding said -fPIC flag to tlsf target continues until:
> 
>> /usr/bin/ld: cannot find -lQt5::OpenGL
>>
>>
>> Could you have a look?
>
> This seems to be a missing build-dep on libqt5opengl5-dev. It builds
> fine after that.
>
> BTW, why do we disable the testsuite?

 (Sorry for the delay - didn't spot your second message)

 Regarding the testsuite: IIRC it doesn't succeed on all archs, and
 that's beyond our control. In 2013 you asked the same question, you
 asked "Why disable the testsuite? After all, if it is failing, its for
 a reason" and my answer was the following:

> That's what I thought too at first. However it's not intended to be
> packaged (it doesn't build anything), and after discussion with the
> developer who actually made and maintains that testsuite, he wanted it
> that way... (It's not really a testsuite of supercollider, btw, I
> think covers the 'supernova' component.)
>>>
>>> Heh, sorry for forgetting about that. I added a comment to that effect
>>> to debian/rules.
>>
>> Thanks. Also thanks for the suggested build fixes. Now I've upgraded
>> my OS I can finally confirm them, so I've pushed them (and proposed
>> them upstream too).
>
> So now we have several build failures:
>
> https://buildd.debian.org/status/package.php?p=supercollider
>
> All of them in the embedded oscpack, but not all of them the same. I
> was going to suggest using the available library, but it is orphaned.
> Anyone up to take the maintainance of oscpack?

One thing to note: it's only "supernova" that makes use of oscpack,
and supernova is optional since it's a drop-in replacement for
"scsynth".
So, one cop-out alternative available to us (if oscpack isn't getting
fixed) is that on some platforms we could disable building it
(-DSUPERNOVA=0) and disable packaging it.

Dan

___
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#823963: ardour: Incorrect balance behaviour for stereo bus sends

[Nis Sandor]

Package: ardour
Version: 1:4.7~dfsg-1
Severity: normal

Dear Maintainer,

It is possible to set invalid balance values for stereo bus sends in ardour4.
How to reproduce: add a stereo bus and an audio track to your project. Add a 
"New aux send" to your audio track, open mixer window.
Click the 'Aux' button on you bus to show aux send's volume and balance 
parameters on the audio track. On the audio track grab
either the (L) or (R) signs to set stereo with or the center indicator and move 
it out of the channel strip.
You can set stereo width over 100% and L/R values below 0 and above 100  (eg: 
L: -70 R: 170 Width: 145%).
It will cause false stereo image rendering.

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

Kernel: Linux 4.5.0-2-686-pae (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 ardour depends on:
ii  ardour-data   1:4.7~dfsg-1
pn  jackd 
ii  libasound21.1.0-1
ii  libatk1.0-0   2.20.0-1
ii  libatkmm-1.6-1v5  2.24.2-1
ii  libaubio4 0.4.1-2.1+b1
ii  libbluetooth3 5.36-1
ii  libc6 2.22-7
ii  libcairo2 1.14.6-1+b1
ii  libcairomm-1.0-1v51.12.0-1+b1
ii  libcurl3-gnutls   7.47.0-1
ii  libcwiid1 0.6.00+svn201-3.2
ii  libfftw3-single3  3.3.4-2+b1
ii  libflac8  1.3.1-4
ii  libfontconfig12.11.0-6.4
ii  libfreetype6  2.6.3-3+b1
ii  libgcc1   1:6.1.1-1
ii  libgdk-pixbuf2.0-02.34.0-1
ii  libglib2.0-0  2.48.0-1
ii  libglibmm-2.4-1v5 2.48.1-1
ii  libgtk2.0-0   2.24.30-1.1
ii  libgtkmm-2.4-1v5  1:2.24.4-2+b1
ii  libjack-jackd2-0 [libjack-0.116]  1.9.10+20150825git1ed50c92~dfsg-1
ii  liblilv-0-0   0.22.0~dfsg0-1
ii  liblo70.28-5
ii  liblrdf0  0.4.0-7
ii  libltc11  1.2.0-1
ii  libogg0   1.3.2-1
ii  libpango-1.0-01.40.1-1
ii  libpangocairo-1.0-0   1.40.1-1
ii  libpangoft2-1.0-0 1.40.1-1
ii  libpangomm-1.4-1v52.40.0-1
ii  librubberband21.8.1-6+b1
ii  libsamplerate00.1.8-8
ii  libserd-0-0   0.22.0~dfsg0-2
ii  libsigc++-2.0-0v5 2.8.0-1
ii  libsndfile1   1.0.25-10
ii  libsord-0-0   0.14.0~dfsg0-1
ii  libsratom-0-0 0.4.6~dfsg0-1
ii  libstdc++66.1.1-1
ii  libsuil-0-0   1:0.8.2-dmo1
ii  libtag1v5 1.9.1-2.4
ii  libvamp-hostsdk3v51:2.6-dmo3
ii  libvamp-sdk2v51:2.6-dmo3
ii  libx11-6  2:1.6.3-1
ii  libxml2   2.9.3+dfsg1-1

Versions of packages ardour recommends:
ii  chromium [www-browser] 50.0.2661.94-1
ii  firefox-esr [www-browser]  45.1.0esr-1
ii  links [www-browser]2.12-1+b2
ii  lynx [www-browser] 2.8.9dev9-1
ii  opera [www-browser]12.16.1860

ardour 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

Bug#823589: mplayer: Please create dummy package for upgrades from jessie

[Adam Conrad]

Package: mplayer
Version: 2:1.3.0-1
Followup-For: Bug #823589
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu yakkety ubuntu-patch



In Ubuntu, the attached patch was applied to achieve the following:

  * Add mplayer2 transitional package to fix upgrades (LP: #1580268)

So, I noticed after fixing this in Ubuntu that you fixed it in Debian
git 48 hours ago.  Your fix is, however, incomplete (notice the extra
parts of my diff that aren't included in your commit, where I version
the Replaces, and change the Conflict to a versioned Breaks).

It would be lovely if you swapped in my fix for yours (at least the
missing bits).

... Adam

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

Kernel: Linux 4.4.0-21-lowlatency (SMP w/4 CPU cores; PREEMPT)
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)
diff -Nru mplayer-1.3.0/debian/control mplayer-1.3.0/debian/control
--- mplayer-1.3.0/debian/control	2016-04-17 13:14:24.0 -0600
+++ mplayer-1.3.0/debian/control	2016-05-10 11:57:44.0 -0600
@@ -147,6 +147,16 @@
  (1 or 2 passes), libavcodec, PCM/MP3/VBRMP3 audio. Also has stream
  copying and video resizing capabilities.
 
+# This can be dropped after yakkety/stretch release, whichever is later:
+Package: mplayer2
+Section: oldlibs
+Architecture: all
+Multi-Arch: foreign
+Depends: mplayer (>= 2:1.2)
+Description: transitional package from mplayer2 to mplayer
+ This package exists to upgrade mplayer2 users to mplayer; it can be safely
+ removed once the upgrade has been performed.
+
 Package: mplayer
 Architecture: any
 Multi-Arch: foreign
@@ -163,9 +173,9 @@
  mencoder (<< 2:1.0~rc3+svn20090426-2),
  mplayer-doc (<< 2:1.0~rc3+svn20090426-2),
  mplayer-nogui (<< 2:1.0~rc3+svn20090426-2),
- mplayer2
-Conflicts:
- mplayer2
+ mplayer2 (<< 2:1.2)
+Breaks:
+ mplayer2 (<< 2:1.2)
 Description: movie player for Unix-like systems
  MPlayer plays most MPEG, VOB, AVI, Ogg/OGM, VIVO,
  ASF/WMA/WMV, QT/MOV/MP4, FLI, RM, NuppelVideo, yuv4mpeg, FILM, RoQ, PVA files,
___
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 3.7.0 in alioth to try

[Felipe Sateler]

On 6 May 2016 at 13:32, Dan S  wrote:
> 2016-05-04 16:09 GMT+01:00 Felipe Sateler :
>> On 4 May 2016 at 11:57, Dan S  wrote:
>>> 2016-04-26 19:23 GMT+01:00 Felipe Sateler :
 On 25 April 2016 at 18:12, Felipe Sateler  wrote:
> On 20 March 2016 at 12:52, Dan S  wrote:
>>
>> Hi all,
>>
>> There's a new release of SuperCollider out (3.7) and I've imported and
>> updated the packaging at pkg-multimedia/supercollider.git . It builds
>> and works for me (on x64), and I'd like to ask others to have a look
>> at it and consider testing/uploading it.
>
> I reproduce the same failure as Hanno, also on x64:
>
> /usr/bin/ld: ../../external_libraries/libtlsf.a(tlsf.c.o): relocation
> R_X86_64_32S against `.rodata' can not be used when making a shared
> object; recompile with -fPIC
> ../../external_libraries/libtlsf.a: error adding symbols: Bad value
>
> adding said -fPIC flag to tlsf target continues until:
 
> /usr/bin/ld: cannot find -lQt5::OpenGL
>
>
> Could you have a look?

 This seems to be a missing build-dep on libqt5opengl5-dev. It builds
 fine after that.

 BTW, why do we disable the testsuite?
>>>
>>> (Sorry for the delay - didn't spot your second message)
>>>
>>> Regarding the testsuite: IIRC it doesn't succeed on all archs, and
>>> that's beyond our control. In 2013 you asked the same question, you
>>> asked "Why disable the testsuite? After all, if it is failing, its for
>>> a reason" and my answer was the following:
>>>
 That's what I thought too at first. However it's not intended to be
 packaged (it doesn't build anything), and after discussion with the
 developer who actually made and maintains that testsuite, he wanted it
 that way... (It's not really a testsuite of supercollider, btw, I
 think covers the 'supernova' component.)
>>
>> Heh, sorry for forgetting about that. I added a comment to that effect
>> to debian/rules.
>
> Thanks. Also thanks for the suggested build fixes. Now I've upgraded
> my OS I can finally confirm them, so I've pushed them (and proposed
> them upstream too).

So now we have several build failures:

https://buildd.debian.org/status/package.php?p=supercollider

All of them in the embedded oscpack, but not all of them the same. I
was going to suggest using the available library, but it is orphaned.
Anyone up to take the maintainance of oscpack?

-- 

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#823953: inkscape: PDF+Latex export completely broken

[Daniel Blaschke]

Package: inkscape
Version: 0.91-5~bpo8+1
Severity: normal

Dear Maintainer,

in inkscape 0.91, PDF+Latex export creates a  multipage pdf where every
element/line of the svg appears on a different pdf page, thus rendering this
functionality completely useless.
This used to work fine in version 0.48.

see also the according launchbad bug report:
https://bugs.launchpad.net/ubuntu/+bug/1417470

Cheers,
Daniel



-- System Information:
Debian Release: 8.4
  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/2 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages inkscape depends on:
ii  gconf-service  3.2.6-3
ii  libaspell150.60.7~20110707-1.3
ii  libatk1.0-02.14.0-1
ii  libatkmm-1.6-1 2.22.7-2.1
ii  libc6  2.19-18+deb8u4
ii  libcairo2  1.14.0-2.1+deb8u1
ii  libcairomm-1.0-1   1.10.0-1.1
ii  libexif12  0.6.21-2
ii  libfontconfig1 2.11.0-6.3
ii  libfreetype6   2.5.2-3+deb8u1
ii  libgc1c2   1:7.2d-6.4
ii  libgcc11:4.9.2-10
ii  libgconf-2-4   3.2.6-3
ii  libgdk-pixbuf2.0-0 2.31.1-2+deb8u4
ii  libglib2.0-0   2.42.1-1+b1
ii  libglibmm-2.4-1c2a 2.42.0-1
ii  libgnomevfs2-0 1:2.24.4-6+b1
ii  libgomp1   4.9.2-10
ii  libgsl0ldbl1.16+dfsg-2
ii  libgtk2.0-02.24.25-3+deb8u1
ii  libgtkmm-2.4-1c2a  1:2.24.4-1.1
ii  libgtkspell0   2.0.16-1.1
ii  libjpeg62-turbo1:1.3.1-12
ii  liblcms2-2 2.6-3+b3
ii  libmagick++-6.q16-58:6.8.9.9-5+deb8u1
ii  libmagickcore-6.q16-2  8:6.8.9.9-5+deb8u1
ii  libmagickwand-6.q16-2  8:6.8.9.9-5+deb8u1
ii  libpango-1.0-0 1.36.8-3
ii  libpangocairo-1.0-01.36.8-3
ii  libpangoft2-1.0-0  1.36.8-3
ii  libpangomm-1.4-1   2.34.0-1.1
ii  libpng12-0 1.2.50-2+deb8u2
ii  libpoppler-glib8   0.26.5-2+deb8u1
ii  libpoppler46   0.26.5-2+deb8u1
ii  libpopt0   1.16-10
ii  librevenge-0.0-0   0.0.1-3
ii  libsigc++-2.0-0c2a 2.4.0-1
ii  libstdc++6 4.9.2-10
ii  libwpg-0.3-3   0.3.0-3
ii  libx11-6   2:1.6.2-3
ii  libxml22.9.1+dfsg1-5+deb8u1
ii  libxslt1.1 1.1.28-2+b2
pn  python:any 
ii  zlib1g 1:1.2.8.dfsg-2+b1

Versions of packages inkscape recommends:
ii  aspell0.60.7~20110707-1.3
ii  imagemagick   8:6.8.9.9-5+deb8u1
ii  libgnomevfs2-extra1:2.24.4-6+b1
ii  libimage-magick-perl  8:6.8.9.9-5+deb8u1
ii  libwmf-bin0.2.8.4-10.3+deb8u1
ii  pstoedit  3.62-2+b1
ii  python-lxml   3.4.0-1
ii  python-numpy  1:1.8.2-2
ii  transfig  1:3.2.5.e-4

Versions of packages inkscape suggests:
pn  dia | dia-gnome  
pn  libsvg-perl  
pn  libxml-xql-perl  
pn  python-uniconvertor  
ii  ruby 1:2.1.5+deb8u2

-- 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

audacious-plugins_3.7.2-2~bpo8+1_amd64.changes is NEW

[Debian FTP Masters]

binary:audacious-plugins is NEW.
binary:audacious-plugins-data is NEW.
source:audacious-plugins is NEW.

Your package has been put into the NEW queue, which requires manual action
from the ftpteam to process. The upload was otherwise valid (it had a good
OpenPGP signature and file hashes are valid), so please be patient.

Packages are routinely processed through to the archive, and do feel
free to browse the NEW queue[1].

If there is an issue with the upload, you will receive an email from a
member of the ftpteam.

If you have any questions, you may reply to this email.

[1]: https://ftp-master.debian.org/new.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

audacious_3.7.2-1~bpo8+1_amd64.changes is NEW

[Debian FTP Masters]

binary:audacious is NEW.
binary:audacious-dev is NEW.
binary:libaudcore3 is NEW.
binary:libaudgui3 is NEW.
binary:libaudqt0 is NEW.
binary:libaudtag2 is NEW.
source:audacious is NEW.

Your package has been put into the NEW queue, which requires manual action
from the ftpteam to process. The upload was otherwise valid (it had a good
OpenPGP signature and file hashes are valid), so please be patient.

Packages are routinely processed through to the archive, and do feel
free to browse the NEW queue[1].

If there is an issue with the upload, you will receive an email from a
member of the ftpteam.

If you have any questions, you may reply to this email.

[1]: https://ftp-master.debian.org/new.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#823940: blender: please make the build reproducible (timestamps)

[Fabian Wolff]

Source: blender
Version: 2.77.a+dfsg0-3
Severity: wishlist
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: timestamps
X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org

Hi!

While working on the "reproducible builds" effort [1], we have noticed
that blender could not be built reproducibly.

Specifically, the current system time is used to define BUILD_DATE and
BUILD_TIME in build_files/cmake/buildinfo.cmake, obviously rendering
the build unreproducible.

The attached patch uses SOURCE_DATE_EPOCH [2] instead of the current
time. This should make the build reproducible.

Regards,
Fabian Wolff

[1] https://wiki.debian.org/ReproducibleBuilds
[2] https://reproducible-builds.org/specs/source-date-epoch/
--- a/build_files/cmake/buildinfo.cmake
+++ b/build_files/cmake/buildinfo.cmake
@@ -134,8 +134,13 @@
 # BUILD_PLATFORM and BUILD_PLATFORM are taken from CMake
 # but BUILD_DATE and BUILD_TIME are platform dependent
 if(UNIX)
-	execute_process(COMMAND date "+%Y-%m-%d" OUTPUT_VARIABLE BUILD_DATE OUTPUT_STRIP_TRAILING_WHITESPACE)
-	execute_process(COMMAND date "+%H:%M:%S" OUTPUT_VARIABLE BUILD_TIME OUTPUT_STRIP_TRAILING_WHITESPACE)
+	if(DEFINED ENV{SOURCE_DATE_EPOCH})
+		execute_process(COMMAND date "-u" "-d" "@$ENV{SOURCE_DATE_EPOCH}" "+%Y-%m-%d" OUTPUT_VARIABLE BUILD_DATE OUTPUT_STRIP_TRAILING_WHITESPACE)
+		execute_process(COMMAND date "-u" "-d" "@$ENV{SOURCE_DATE_EPOCH}" "+%H:%M:%S" OUTPUT_VARIABLE BUILD_TIME OUTPUT_STRIP_TRAILING_WHITESPACE)
+	else()
+		execute_process(COMMAND date "+%Y-%m-%d" OUTPUT_VARIABLE BUILD_DATE OUTPUT_STRIP_TRAILING_WHITESPACE)
+		execute_process(COMMAND date "+%H:%M:%S" OUTPUT_VARIABLE BUILD_TIME OUTPUT_STRIP_TRAILING_WHITESPACE)
+	endif()
 endif()
 if(WIN32)
 	execute_process(COMMAND cmd /c date /t OUTPUT_VARIABLE BUILD_DATE OUTPUT_STRIP_TRAILING_WHITESPACE)
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Processing of audacious_3.7.2-1~bpo8+1_amd64.changes

[Debian FTP Masters]

audacious_3.7.2-1~bpo8+1_amd64.changes uploaded successfully to localhost
along with the files:
  audacious_3.7.2-1~bpo8+1.dsc
  audacious_3.7.2-1~bpo8+1.debian.tar.xz
  audacious_3.7.2-1~bpo8+1_amd64.deb
  audacious-dev_3.7.2-1~bpo8+1_amd64.deb
  libaudcore3_3.7.2-1~bpo8+1_amd64.deb
  libaudgui3_3.7.2-1~bpo8+1_amd64.deb
  libaudtag2_3.7.2-1~bpo8+1_amd64.deb
  libaudqt0_3.7.2-1~bpo8+1_amd64.deb

Greetings,

Your Debian queue daemon (running on host franck.debian.org)

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

Processing of audacious-plugins_3.7.2-2~bpo8+1_amd64.changes

[Debian FTP Masters]

audacious-plugins_3.7.2-2~bpo8+1_amd64.changes uploaded successfully to 
localhost
along with the files:
  audacious-plugins_3.7.2-2~bpo8+1.dsc
  audacious-plugins_3.7.2-2~bpo8+1.debian.tar.xz
  audacious-plugins_3.7.2-2~bpo8+1_amd64.deb
  audacious-plugins-data_3.7.2-2~bpo8+1_all.deb

Greetings,

Your Debian queue daemon (running on host franck.debian.org)

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

Processing of audacious-plugins_3.7.2-2~bpo8+1_amd64.changes

[Debian FTP Masters]

audacious-plugins_3.7.2-2~bpo8+1_amd64.changes uploaded successfully to 
ftp-master.debian.org
along with the files:
  audacious-plugins_3.7.2-2~bpo8+1.dsc
  audacious-plugins_3.7.2-2~bpo8+1.debian.tar.xz
  audacious-plugins_3.7.2-2~bpo8+1_amd64.deb
  audacious-plugins-data_3.7.2-2~bpo8+1_all.deb

Greetings,

Your Debian queue daemon (running on host coccia.debian.org)

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

Processing of audacious_3.7.2-1~bpo8+1_amd64.changes

[Debian FTP Masters]

audacious_3.7.2-1~bpo8+1_amd64.changes uploaded successfully to 
ftp-master.debian.org
along with the files:
  audacious_3.7.2-1~bpo8+1.dsc
  audacious_3.7.2-1~bpo8+1.debian.tar.xz
  audacious_3.7.2-1~bpo8+1_amd64.deb
  audacious-dev_3.7.2-1~bpo8+1_amd64.deb
  libaudcore3_3.7.2-1~bpo8+1_amd64.deb
  libaudgui3_3.7.2-1~bpo8+1_amd64.deb
  libaudtag2_3.7.2-1~bpo8+1_amd64.deb
  libaudqt0_3.7.2-1~bpo8+1_amd64.deb

Greetings,

Your Debian queue daemon (running on host coccia.debian.org)

___
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: RFS: audacious/3.6.2-2~bpo8+1 and audacious-plugins/3.6.2-2~bpo8+1

[Mattia Rizzolo]

On Tue, May 10, 2016 at 03:17:30PM +, Mattia Rizzolo wrote:
> So, I'm going to use a local bpo of sndio instead (also because yours
> would not be nice to upload due to the +2.  why 2 identical changelog
> entries??), and try to build audacious again.  Tomorrow first thing in
> the morning most probably.

Actually, already did and uploading now.

Enjoy ;)

-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
more about me:  https://mapreri.org : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


signature.asc
Description: PGP signature
___
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: RFS: audacious/3.6.2-2~bpo8+1 and audacious-plugins/3.6.2-2~bpo8+1

[Mattia Rizzolo]

Sorry for the delay, these days are crazy for me

On Fri, May 06, 2016 at 02:05:17PM -0400, Nicholas D Steeves wrote:
> It seems I backported libsndio in a fugue state Feb 9th!  I found a
> libsndio-dev_1.0.1-2~bpo8+1_amd64.deb in my local repo.  I can't find
> an email notification from debian-mentors saying I uploaded it, so my
> conclusion is that this was leftover cruft from when I just starting
> out.  You have my sincerest apologies.

Nevermind, happens :)
FTR, I tend to clean up my local repository as soon as I'm done with
that build, as way too often happens to leave something there to me.

> I've just purged that repo and uploaded a bpo of libsndio to mentors.

mh, no.

There is already one in bpo-NEW from 2 days ago :)
https://ftp-master.debian.org/new/sndio_1.1.0-2~bpo8%2B1.html

So, I'm going to use a local bpo of sndio instead (also because yours
would not be nice to upload due to the +2.  why 2 identical changelog
entries??), and try to build audacious again.  Tomorrow first thing in
the morning most probably.


> Message-ID: 
> 

Hi Friend,The Work of God

[jskl]

Hi, I'm diagnosed with laryngeal Cancer,I want to give all my resources to you 
for Charity work. Let this be my last offering.

Respond with this ref. FresherHelp44. so i know you got this.God bless you 
abundantly.

Dennis Williams.


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