Ardour still not present in testing

[Brandon Simmons]

Hello,
Writing to inquire why Ardour has not yet made it to into Lenny. I
couldn't glean the reason from the Debian developer page. If there are
issues with the package, are they being resolved? I would think this
package would be in high demand, but apparently not.

Thank you,
Brandon


--
To UNSUBSCRIBE, email to debian-multimedia-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Tshepang Lekhonkhobe]

On Wed, Apr 30, 2008 at 9:18 PM, Brandon Simmons
<brandon.m.simmons@...> wrote:
> Hello,
>  Writing to inquire why Ardour has not yet made it to into Lenny. I
>  couldn't glean the reason from the Debian developer page. If there are
>  issues with the package, are they being resolved? I would think this
>  package would be in high demand, but apparently not.

It's failing to build on a few archs, so by default can't transition into Lenny:
* http://bjorn.haxx.se/debian/testing.pl?package=ardour


--
my place on the web:
floss-and-misc.blogspot.com


--
To UNSUBSCRIBE, email to debian-multimedia-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Felipe Sateler]

On Wednesday 30 April 2008 15:41:32 Tshepang Lekhonkhobe wrote:

> On Wed, Apr 30, 2008 at 9:18 PM, Brandon Simmons
>
> <brandon.m.simmons@...> wrote:
> > Hello,
> >  Writing to inquire why Ardour has not yet made it to into Lenny. I
> >  couldn't glean the reason from the Debian developer page. If there are
> >  issues with the package, are they being resolved? I would think this
> >  package would be in high demand, but apparently not.
>
> It's failing to build on a few archs, so by default can't transition into
> Lenny: * http://bjorn.haxx.se/debian/testing.pl?package=ardour

Actually, when/if it builds it won't go either, since it has 4 RC bugs and
there is no version in testing.

--
Felipe Sateler

[Daniel James-2]

Hi Felipe,

> Actually, when/if it builds it won't go either, since it has 4 RC bugs and
> there is no version in testing.

Is there any way we can resolve this? Can we just get security support
removed so that the embedding of libraries is no longer an issue?

I seriously doubt that Ardour is installed on any security-critical servers.

Cheers!

Daniel


--
To UNSUBSCRIBE, email to debian-multimedia-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Felipe Sateler]

On Thursday 01 May 2008 12:13:38 Daniel James wrote:

> Hi Felipe,
>
> > Actually, when/if it builds it won't go either, since it has 4 RC bugs
> > and there is no version in testing.
>
> Is there any way we can resolve this? Can we just get security support
> removed so that the embedding of libraries is no longer an issue?
>
> I seriously doubt that Ardour is installed on any security-critical
> servers.

I think this should be taken to the release and security teams.
Note though that there are non-security related RC bugs, these would need to
be fixed first.


--
Felipe Sateler

[Paul Wise-3]

On Fri, May 2, 2008 at 12:13 AM, Daniel James <daniel@...> wrote:

>  Is there any way we can resolve this? Can we just get security support
> removed so that the embedding of libraries is no longer an issue?

Security isn't the only reason embedded libraries are bad.

>  I seriously doubt that Ardour is installed on any security-critical
> servers.

Don't you care about the security of users desktops or audio workstations?

--
bye,
pabs

http://wiki.debian.org/PaulWise


--
To UNSUBSCRIBE, email to debian-multimedia-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Paul Wise-3]

I'm going to have a go at killing all these libraries right now, but
someone needs to get in contact with upstream and educate them about
the evilness of embedded code copies.

--
bye,
pabs

http://wiki.debian.org/PaulWise


--
To UNSUBSCRIBE, email to debian-multimedia-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Paul Wise-3]

On Fri, May 2, 2008 at 12:21 PM, Paul Wise <pabs@...> wrote:

> I'm going to have a go at killing all these libraries right now, but
>  someone needs to get in contact with upstream and educate them about
>  the evilness of embedded code copies.

I thought this would be as simple as turning on the SYSLIBS option to
the SConstruct, but...

I began by fighting with scons because it decided boost doesn't exist
and doesn't want to run the compiler to find out. Worked around this
by ignoring the error. Getting help in #scons though.

There are a bunch of libraries, but it is hard to tell which are
internal ardour libs and which are code copies.

After turning on SYSLIBS (USE AT YOUR OWN RISK: CANCELS ALL SUPPORT
FROM ARDOUR AUTHORS) I see the below stuff that might be problematic.

Does anyone know if the below stuff are external libraries?

I know that clearlooks is a gtk theme and libsndfile is an external
library, but I'm not sure about the rest.

It builds fine without the embedded copy of libsndfile, didn't test it
though because I've never used it.

libraries['ardour'] = LibraryInfo (LIBS='ardour',
LIBPATH='#libs/ardour', CPPPATH='#libs/ardour')
libraries['midi++2'] = LibraryInfo (LIBS='midi++',
LIBPATH='#libs/midi++2', CPPPATH='#libs/midi++2')
libraries['pbd']    = LibraryInfo (LIBS='pbd', LIBPATH='#libs/pbd',
CPPPATH='#libs/pbd')
libraries['gtkmm2ext'] = LibraryInfo (LIBS='gtkmm2ext',
LIBPATH='#libs/gtkmm2ext', CPPPATH='#libs/gtkmm2ext')

...

#
# these are part of the Ardour source tree because they are C++
#

libraries['vamp'] = LibraryInfo (LIBS='vampsdk',
                                 LIBPATH='#libs/vamp-sdk',
                                 CPPPATH='#libs/vamp-sdk')
libraries['vamphost'] = LibraryInfo (LIBS='vamphostsdk',
                                 LIBPATH='#libs/vamp-sdk',
                                 CPPPATH='#libs/vamp-sdk')

...

    libraries['rubberband'] = LibraryInfo (LIBS='rubberband',
                                           LIBPATH='#libs/rubberband',
                                           CPPPATH='#libs/rubberband',
                                           CCFLAGS='-DUSE_RUBBERBAND')

...

    libraries['sndfile-ardour'] = LibraryInfo(LIBS='libsndfile-ardour',
                                    LIBPATH='#libs/libsndfile',
                                    CPPPATH=['#libs/libsndfile/src'])

...

    libraries['appleutility'] = LibraryInfo(LIBS='libappleutility',
                                            LIBPATH='#libs/appleutility',
                                            CPPPATH='#libs/appleutility')

...

    subdirs = [
        'libs/libsndfile',
        'libs/pbd',
        'libs/midi++2',
        'libs/ardour',
        'libs/vamp-sdk',
        'libs/vamp-plugins/',
    # these are unconditionally included but have
    # tests internally to avoid compilation etc
    # if VST is not set
        'libs/fst',
        'vst',
    # this is unconditionally included but has
    # tests internally to avoid compilation etc
    # if COREAUDIO is not set
        'libs/appleutility'
        ]

...

    gtk_subdirs = [
        'libs/gtkmm2ext',
        'gtk2_ardour',
        'libs/clearlooks'
        ]

...

surface_subdirs = [ 'libs/surfaces/control_protocol',
                    'libs/surfaces/generic_midi',
                    'libs/surfaces/tranzport',
                    'libs/surfaces/mackie',
                    'libs/surfaces/powermate'
                    ]

...

        surface_subdirs += [ 'libs/surfaces/sony9pin' ]

...

timefx_subdirs = ['libs/soundtouch']
if env['RUBBERBAND']:
    timefx_subdirs += ['libs/rubberband']

--
bye,
pabs

http://wiki.debian.org/PaulWise


--
To UNSUBSCRIBE, email to debian-multimedia-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Daniel James-2]

Hi Paul,

> Security isn't the only reason embedded libraries are bad.

On the other hand, what about the right of an upstream development team
to specify the versions of libraries which they require, patching them
as necessary?

Even with libraries built in, the Ardour package is still smaller than
iceweasel, and a great deal smaller than openoffice.org.

>>  I seriously doubt that Ardour is installed on any security-critical
>> servers.
>
> Don't you care about the security of users desktops or audio workstations?

Of course, but as a regular Ardour user I'll take a stable version with
a theoretical security exploit over a buggy version any day. Also, it's
not required for Ardour machines to be connected to the internet at all,
let alone be online 24/7. So there's a great deal of difference between
  a DAW and a web server.

Cheers!

Daniel


--
To UNSUBSCRIBE, email to debian-multimedia-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Daniel James-2]

Hi Paul W,

> someone needs to get in contact with upstream and educate them about
> the evilness of embedded code copies.

I don't think that's a very helpful approach. The Ardour team are
already aware of Debian's reservations about the embedded libraries.

Consider that the Ardour team do not want to be receiving bug reports
for years into the future from Debian, Ubuntu and other Debian
derivative distro users about problems which are not present in their
own copies of the libraries.

It would be more productive to get the changes that the Ardour team
requires into the various libraries that Ardour needs, before the Lenny
release, in order to avoid creating a binary which is unsupported upstream.

If Lenny doesn't contain Ardour, then the Debian-based multimedia
distros will be forced to build their own Ardour packages, which will be
based on upstream's tarball. So there's no practical benefit to keeping
Ardour out of Lenny over this issue, but it could turn people away from
using official Debian.

Cheers!

Daniel


--
To UNSUBSCRIBE, email to debian-multimedia-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Daniel James-2]

Hi Paul W,

> Does anyone know if the below stuff are external libraries?
>
> I know that clearlooks is a gtk theme and libsndfile is an external
> library, but I'm not sure about the rest.

> libraries['vamp'] = LibraryInfo (LIBS='vampsdk',
>                                  LIBPATH='#libs/vamp-sdk',
>                                  CPPPATH='#libs/vamp-sdk')
> libraries['vamphost'] = LibraryInfo (LIBS='vamphostsdk',
>                                  LIBPATH='#libs/vamp-sdk',
>                                  CPPPATH='#libs/vamp-sdk')

These relate to the VAMP analysis plugins.

>     libraries['rubberband'] = LibraryInfo (LIBS='rubberband',
>                                            LIBPATH='#libs/rubberband',
>                                            CPPPATH='#libs/rubberband',
>                                            CCFLAGS='-DUSE_RUBBERBAND')

Timestretching library, replaces soundtouch since Ardour 2.2.

>     libraries['sndfile-ardour'] = LibraryInfo(LIBS='libsndfile-ardour',
>                                     LIBPATH='#libs/libsndfile',
>                                     CPPPATH=['#libs/libsndfile/src'])

I'd guess that's Ardour's internal copy of libsndfile.

>     libraries['appleutility'] = LibraryInfo(LIBS='libappleutility',
>                                             LIBPATH='#libs/appleutility',
>                                             CPPPATH='#libs/appleutility')

I don't know this one, my guess is that it relates to the OS X port.

>         'libs/gtkmm2ext',

C++ interface for GTK+, Ardour specific version I think.

> surface_subdirs = [ 'libs/surfaces/control_protocol',
>                     'libs/surfaces/generic_midi',
>                     'libs/surfaces/tranzport',
>                     'libs/surfaces/mackie',
>                     'libs/surfaces/powermate'

>         surface_subdirs += [ 'libs/surfaces/sony9pin' ]

I think all these control surface libraries are specific to Ardour; at
least I don't recall seeing them in an external library.

Cheers!

Daniel


--
To UNSUBSCRIBE, email to debian-multimedia-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Paul Davis]

On Fri, 2008-05-02 at 10:22 +0100, Daniel James wrote:
> Hi Paul W,
>
> > someone needs to get in contact with upstream and educate them about
> > the evilness of embedded code copies.
>
> I don't think that's a very helpful approach. The Ardour team are
> already aware of Debian's reservations about the embedded libraries.

You can say that again. Yes, we'd love to avoid the security issues,
increased memory overhead, extra maintainance costs and overall
redundancy of embedded libraries, but we're not going to.

> Consider that the Ardour team do not want to be receiving bug reports
> for years into the future from Debian, Ubuntu and other Debian
> derivative distro users about problems which are not present in their
> own copies of the libraries.

There is really one library to which this specific issue applies, and
that is libsndfile. The reason that this is included in the Ardour code
tree and installed with the executables is that its author has still not
released a version containing the fixes that we need, approximately 18
months after he said he would do so. Calling them "fixes" may be
misleading. They are small changes in semantics. As soon as Erik does
release this, we will remove libsndfile from our tree. Until that time,
the libsndfile that comes with Ardour cannot be considered equivalent to
the one built from "upstream" sources.

However, the historical reasons are more pressing for us. Whatever
debian (or any other distribution) maintainers may tell us, we know one
thing for sure: there are plenty of users who will end up building
Ardour with a different C++ compiler or even just sufficiently different
compiler flags than were used to build the C++ libraries that Ardour
depends on. The abject failure of the gcc project to maintain a stable
ABI for C++ caused us to spend hundreds of hours of wasted time tracking
down issues caused by these compiler mismatches. Our solution was to get
rid of them for once and for all, by putting all the C++ libraries that
Ardour uses (and that do not come with the compiler) into the source
tree.

As a nod toward distributions like Debian, we added the SYSLIBS compile
time option, but using it means that we will not provide any support to
the user. Yes, we've heard for years that "there will never be a
compiler mismatch, the user will always have the same g++ as was used to
build libfoobar". Problem is, not a month goes by when this is
disproved. We are *not* going to waste our time figuring out why the
system build of libfoobar is breaking ardour when we already know that
the build done as part of ardour's own build process works just fine
(and I am not talking about code changes to the library, just the build
processes). And its not just debian. Gentoo has had this problem
recently, where their maintainer messed up their ebuild (using SYSLIBS)
to produce a crash-on-startup version of ardour. Who do you think got to
clean that up, us or the "packager" ?

--p




--
To UNSUBSCRIBE, email to debian-multimedia-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Paul Wise-3]

On Fri, May 2, 2008 at 8:41 PM, Paul Davis <paul@...> wrote:

>  > Consider that the Ardour team do not want to be receiving bug reports
>  > for years into the future from Debian, Ubuntu and other Debian
>  > derivative distro users about problems which are not present in their
>  > own copies of the libraries.
>
>  There is really one library to which this specific issue applies, and
>  that is libsndfile.

About libsndfile, how about the Debian libsndfile source package is
modified so that it produces a normal libsndfile library and a
libsndfile-ardour for ardour to build against. The ardour SConstruct
could then test that the changes are available at build time. If
libsndfile was using sourceforge, I'd suggest you hijack the project,
but that doesn't look to be the case.

Also, what about the clearlooks theme?

>  However, the historical reasons are more pressing for us. Whatever
>  debian (or any other distribution) maintainers may tell us, we know one
>  thing for sure: there are plenty of users who will end up building
>  Ardour with a different C++ compiler or even just sufficiently different
>  compiler flags than were used to build the C++ libraries that Ardour
>  depends on. The abject failure of the gcc project to maintain a stable
>  ABI for C++ caused us to spend hundreds of hours of wasted time tracking
>  down issues caused by these compiler mismatches. Our solution was to get
>  rid of them for once and for all, by putting all the C++ libraries that
>  Ardour uses (and that do not come with the compiler) into the source
>  tree.

Only way I can think to deal with this would be some kind of
build-time test that checks the that the C++ ABI matches. Reading the
docs, there is -fabi-version=n, which might help here. The latest ABI
version mentioned there is version 2, which appeared in GCC 3.4 (4
years ago). The ABI change before that was in 2002.  For some reason I
get the impression that ABI changes will be minimal from now on.

http://gcc.gnu.org/onlinedocs/gcc-3.4.3/gcc/C_002b_002b-Dialect-Options.html#index-fabi_002dversion-120

>  As a nod toward distributions like Debian, we added the SYSLIBS compile
>  time option, but using it means that we will not provide any support to
>  the user. Yes, we've heard for years that "there will never be a
>  compiler mismatch, the user will always have the same g++ as was used to
>  build libfoobar". Problem is, not a month goes by when this is
>  disproved. We are *not* going to waste our time figuring out why the
>  system build of libfoobar is breaking ardour when we already know that
>  the build done as part of ardour's own build process works just fine
>  (and I am not talking about code changes to the library, just the build
>  processes). And its not just debian. Gentoo has had this problem
>  recently, where their maintainer messed up their ebuild (using SYSLIBS)
>  to produce a crash-on-startup version of ardour. Who do you think got to
>  clean that up, us or the "packager" ?

Normally I would assume the packager did, but I guess from your tone
that you had to deal with it.

Not really any way to fix people not testing their changes, except
maybe forwarding all the bugs that get filed or asking for their
Gentoo commmit privileges to be revoked.

--
bye,
pabs

http://wiki.debian.org/PaulWise


--
To UNSUBSCRIBE, email to debian-multimedia-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Daniel James-2]

Hi Paul,

> About libsndfile, how about the Debian libsndfile source package is
> modified so that it produces a normal libsndfile library and a
> libsndfile-ardour for ardour to build against.

Or how about the libsndfile1 Debian package maintainer, Anand Kumria, is
asked to apply the Ardour team's patches so that the new, improved
version of libsndfile gets some testing before the Lenny freeze? (I'm
cc'ing Anand on this mail).

There hasn't been an upstream release of libsndfile since 2006, and the
last major release was in 2002.

>>  Gentoo has had this problem
>>  recently, where their maintainer messed up their ebuild (using SYSLIBS)
>>  to produce a crash-on-startup version of ardour. Who do you think got to
>>  clean that up, us or the "packager" ?
>
> Normally I would assume the packager did, but I guess from your tone
> that you had to deal with it.

I believe the problem is that Debian packages of Ardour end up in
Debian-derived distributions, most of which are used by people who
aren't DD's and don't use bugs.debian.org. These users are likely to
assume any problems they encounter are in the Ardour source, rather than
a result of the build or packaging process. Therefore they take their
bug reports upstream to the Ardour or distro forums, if they bother to
report the problem at all.

Cheers!

Daniel


--
To UNSUBSCRIBE, email to debian-multimedia-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Paul Davis]

On Thu, 2008-05-08 at 14:12 +0100, Daniel James wrote:

> Hi Paul,
>
> > About libsndfile, how about the Debian libsndfile source package is
> > modified so that it produces a normal libsndfile library and a
> > libsndfile-ardour for ardour to build against.
>
> Or how about the libsndfile1 Debian package maintainer, Anand Kumria, is
> asked to apply the Ardour team's patches so that the new, improved
> version of libsndfile gets some testing before the Lenny freeze? (I'm
> cc'ing Anand on this mail).

The one issue with that is rather important is that the patches slightly
change the semantics of libsndfile. I won't bore you with the details,
unless someone asks, but suffice it to say that it allows a program
using libsndfile to do something that used to return an error code.

> I believe the problem is that Debian packages of Ardour end up in
> Debian-derived distributions, most of which are used by people who
> aren't DD's and don't use bugs.debian.org. These users are likely to
> assume any problems they encounter are in the Ardour source, rather than
> a result of the build or packaging process. Therefore they take their
> bug reports upstream to the Ardour or distro forums, if they bother to
> report the problem at all.

This is precisely correct.
--p



--
To UNSUBSCRIBE, email to debian-multimedia-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Anand Kumria-2]

Hi guys,

[ apologies, progsoc has been having some "issues" so this went to the
wrong folder ]

On Thu, May 8, 2008 at 2:12 PM, Daniel James <daniel@...> wrote:

> Hi Paul,
>
>> About libsndfile, how about the Debian libsndfile source package is
>> modified so that it produces a normal libsndfile library and a
>> libsndfile-ardour for ardour to build against.
>
> Or how about the libsndfile1 Debian package maintainer, Anand Kumria, is
> asked to apply the Ardour team's patches so that the new, improved version
> of libsndfile gets some testing before the Lenny freeze? (I'm cc'ing Anand
> on this mail).

That is certainly possible. Where are the patches? Any reason that
Erik can not incorporate them back upstream?

> There hasn't been an upstream release of libsndfile since 2006, and the last
> major release was in 2002.

Well we can always throw in the pre-release version.

It compiles and, therefore, should be good to go. ;-)

Erik do you want Debian to push out 1.0.18pre5 and see what breaks?

Cheers,
Anand


--
To UNSUBSCRIBE, email to debian-multimedia-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Erik de Castro Lopo-8]

Anand Kumria wrote:

> That is certainly possible. Where are the patches? Any reason that
> Erik can not incorporate them back upstream?

I recently had a look at what was in ardour SVN and distilled a patch
which is currently in my development tree.

There is a pre-release available here:

    http://www.mega-nerd.com/tmp/libsndfile-1.0.18pre22.tar.gz
 
> > There hasn't been an upstream release of libsndfile since 2006, and the last
> > major release was in 2002.
>
> Well we can always throw in the pre-release version.
>
> It compiles and, therefore, should be good to go. ;-)
>
> Erik do you want Debian to push out 1.0.18pre5 and see what breaks?

That one is really ancient. I'd prefer not to have that debian.

I'm getting really close to a proper 1.0.18 release. The only major
thing still required is to remove the Ogg, Vorbis and FLAC sources
from the tree and link against external versions.

How long do I have to get the proper release sorted out for inclusion
in Lenny?

Erik
--
-----------------------------------------------------------------
Erik de Castro Lopo
-----------------------------------------------------------------
"Powershell is slow. Exceedingly slow. I didn't think speed would be
a factor in a shell until I used Powershell. The Unix shell tools are
literally hundreds, if not thousands of times faster than the equivalent
Powershell commands."
-- http://reddit.com/r/programming/info/6cgne/comments/c03h3h7


--
To UNSUBSCRIBE, email to debian-multimedia-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...