In fact 
ardour 2.8.12 needs to be built with the old version of lv2-core and slv2 as provided by Mageia

Ardour may be updated to the last new version 2.8.14 
this version needs 
lv2 bug 7639 
lilv bug 7838
suil bug 7841

slv2 is deprecated and lv2-core is obsolete for the new version of ardour

Depends on: (none) => 7841
Summary: a new version of lv2 exists : ardour may be built with it (see bug 7639) => a new version of lv2 exists : the new ardour (2.8.14) must be built with it (see bug 7639)
Source RPM: ardour-1.2.8 => ardour-2.8.12

I attach a spec file for new ardour (2.8.14) successfully built and installed on Mageia2 
I first
1) built  and installed lv2 (which obsoletes lv2-core and lv2-ui)
2) built and installed lilv
3) rebuilt and installed suil
4) created dmalloc rpm (bug 8178)

then built Ardour 2.8.14

Depends on: (none) => 8178

Created attachment 3138 [details]
spec file for ardour 2.8.14

cleaned and adapted spec file to update ardour to 2.4.18 version

2 patches are useless since 2.8.12 version

added BR lv2 lilv suil
suppressed BR lv2-core (obsoleted by lv2)
suppressed BR slv2 (deprecated)
suppressed soundtouch-devel no more needed

PS 
A version of ardour with the vst option may be provided

But the author asks to provide it with the name "ardourvst" instead of simply "ardour"

I will send a spec file for this special build

Created attachment 3143 [details]
spec file for ardourvst 2.8.14

spec file to build ardour with VST (bundled headers from VeSTige)

NB this version of ardour named ardourvst can't be installed beside ardour2

We may add some conflicts perhaps but I don't know how

Created attachment 3144 [details]
ardour-2.8.2-disable-fdo-actions.patch

ardour-2.8.2-disable-fdo-actions.patch is the only needed patch for both versions ardour and ardourvst

Created attachment 3146 [details]
corrected spec file for ardourvst 2.8.14

This spec file asks for a patch which allows the desktop file to launch ardourvst

Attachment 3143 is obsolete: 0 => 1

Created attachment 3147 [details]
ardour-2.8.14-desktop.in.patch

patch to modify desktop.in so that the exec is ardourvst instead of ardour2

NB :
Ardourvst needs wine-devel to be build and wine to work !
It's easy to build and use on a 32 bits Mageia
It's maybe a little more tricky on a 64 bits Mageia

Created attachment 3155 [details]
build log

Hi Philippe,
Ardour build fails at the moment using essentially your spec. Looks like some boost headers are not being found, but not yet figured out why.
Ping me on IRC if you have an answer.

Spec as it stands now is here http://paste.kde.org/614114/
I made a few changes but nothing that should affect this.
I moved that warning to a README.urpmi and quietened rpmlint with a few libname changes which I left #-ed out.

Have fun ;)

Hi Barry !

I saw that you updated qtractor and linuxsampler after having pushed the whole lv2 basis...
\o/

For the problem you encounter with ardour :
I downloaded you build log to compare it with mine
I modified my spec file to have the same as yours

I rebuilt ardour
no problem for me...

but I looked again to your build log and I discovered a possible reason :
I have a 32bits system and you have a 64bits one...

You may perhaps find the culprit here :
lines 89 to 92 of your spec file 
%ifarch x86_64
TARGETCPU="x86_64"
ARCHFLAGS="-DARCH_X86 -DBUILD_SSE_OPTIMIZATIONS -DUSE_X86_64_ASM"
%endif

is there a typo in line 91 : might it be :
ARCHFLAGS="-DARCH_X86_64 -DBUILD_SSE_OPTIMIZATIONS -DUSE_X86_64_ASM"

Perhaps you may try to correct this if this is a typo !!! and try it again...

If this doesn't work there's perhaps something else to modify in line 91
Frank Kobber added a comment just upon this :
line 84
#(tpg) disable strange optimisations, like SSE

I try to investigate ...

Thanks for the time you spent to import this whole stuff !

Regards 
Philippe

No it's not a typo I had a look on the spec file from fedora ...

lines 89 to 92 of your spec file 
%ifarch x86_64
TARGETCPU="x86_64"
ARCHFLAGS="-DARCH_X86 -DBUILD_SSE_OPTIMIZATIONS -DUSE_X86_64_ASM"
%endif

Looking at your build log we may think about a problem of coherency between the  versions of
gtk+-2-devel
gtkmm-devel
sigc++
gnomecanvas
gnomecanvasmm
and boost

It's maybe not an ardour problem but a cauldron problem 

You may perhaps ask Funda Wang ... 

try to build on a 32bits cauldron system (to see if it's only a 64bits problem)

try to build on a Mageia2 64bits system (that means backport first the lv2 stuff)

I already tried 32 bit build last night (same problem):
http://mtf.no-ip.co.uk/pub/linux/barjac/distrib/cauldron/i586/log/ardour-2.8.14-1.mga3.src.rpm/build.0.20121125000840.log
You may be able to compare it with yours.
I have yet to manage to get iurt to see my local test repo at the same time as my mirror, so I can't try building on 2 yet, but if I find time I will look again at this.
I'm wondering if we are just missing a BR due to some package splitting somewhere. It does not help that it uses scons.

Hi Barry !

I attentively read your 32bits log :

The problem begins on line 428
when working on gtk2_ardour/editor.cc
several lines (130) like this one :
gtk2_ardour/editor_xpms:9:51: warning: narrowing conversion of '224' from 'int' to 'const gchar {aka const char}' inside { } is ill-formed in C++11 [-Wnarrowing]


and continues from line 720 to 1100
add_route_dialog.cc:(.text.startup+0x2c): undefined reference to `boost::system::generic_category()'


I have not those warnings at the same moment of the making process... 


It seems to be a problem of compatibility with the version of sigc++ and boost inside cauldron...

I'm stuck !

I won't be surprised that if you attempt to rebuild ardour-2.8.12 from its srpm inside cauldron you would have the same problem !!!

I asked on #dev and was pointed to the boost version in Cauldron vs 2
<Luigi12> :v -s boost
<Sophie> Luigi12: 1.50.0-6.mga3 // core-release-src (Mga, cauldron, x86_64), core-release-src (Mga, cauldron, i586)
<Luigi12> :v -s boost -r 2
<Sophie> Luigi12: 1.48.0-9.1.mga2 // core-updates-src (Mga, 2, x86_64), core-updates-src (Mga, 2, i586)
<Sophie> Luigi12: 1.48.0-9.mga2 // core-release-src (Mga, 2, x86_64), core-release-src (Mga, 2, i586)

So maybe this needs reporting upstream unless it's already fixed in revision of ardour.

There is no change in svn for the first "culprits" :

add_route_dialog.cc last modification is 17 months old
editor.cc last modification is 8 months old

I saw that fedora failed to rebuild ardour-2.8.14 on new boost updated to 1.50 for Fedora18 in july
they keep the version built on boost 1.48 !!!

Why such tools don't have retro-compatibility !!! and force developers to work to comply with new features breaking the old ones !

Why there's no possibility to have coexisting versions of boost !

We can provide all the lv2 stuff and packages built on it as updates for Mageia2 (unless somebody wants to update boost stuff inside Mageia2)
but we can't do it in Cauldron for ardour !

If someone wanted to do a mass rebuild for the new boost how many packages will fail to build ? and how many devs will have to work to adapt their program to the new boost diktat ! 
I am a bit disppointed :(

Yes - I had a chat with Ardour dev on IRC and here are his comments.

<barjac> Hi build of 2.8.14 fails on system with boost-1.5, but is OK with boost-1.48.0 should I file a bug or is this known?
<barjac> undefined reference to `boost::system::generic_category() - Many instances
<barjac> build log here: http:XXXXXXXXXXX

<las> barjac: that is a known issue with boost 1.5
<las> barjac: they *fundamentally* altered boost. 
<las> barjac: it used to be possible to use boost without linking - just using header files
<las> barjac: this has now changed, for extremely undefensible reasons
<las> barjac: we have modified ardour 3.X to cope with this, but at present i do not plan to modify 2.X to accomodate this (what i consider) crazy change in boost
<barjac> las: OK thanks - we will delay attempting to package this until 3.x then.
<las> barjac: 2.X is likely to get "stranded" in time
<las> barjac: i plan to "maintain" it in terms of being willing to apply important patches and occasionally (if we discover them) backport important fixes, but personally i'm not planning to try to keep it "current" with anything other than the library versiosn we use for binary bundles
<las> barjac: and right now, i have no plans to upgrade to a version of boost that breaks one of the original, fundamental promises of the boost "libraries"

:(

Yeah !
There something wrong and anti-democratic (or autistic)  when some people apply and impose changes that imply lot of work to others who had not been consulted before !

May we boycott an update of such an important library until they are rewritten to be retrocompatible !
Or must we accept the implicit :
"Libboost is better indeed and doesn't break anything : you only have to write again all your stuff: that's your problem ... not ours !"


I choosed Linux for the cooperation spirit... but sometimes, I wonder !

What a waste of time indeed ...
How many packagers and dev in how many distributions will have to face the same problem...
try to understand 
and then
chat mail complain  with ardour or foo devs 
and ask them to be compliant with libboost

It's a shame !
:-(

A bit of news for you.
I got Ardour-3.0.beta5 (very rough) package working in Cauldron \o/
http://imgur.com/FVn47
Lots more work to do - let me know if you want to continue the project and I'll pass over to you what I have. :)

I'm OK to try :-)

Just gonna be a little busy until next monday...

I just had a glance on ardour svn and to the tags : the last one seems to be Ardour-3.0.beta3 .

nevertheless, I downloaded the last revision 13552

Wow !
Lots of changes : he uses waf now and no more scons ...  :-(

I just discovered waf with the lv2 project

Yet something else to learn !
and a lot of work to create a new spec file and perhaps patches...

If that's the only way to have ardour in cauldron let's go .

but I'm gonna try it on my good stable Mageia2 (hoping he decided not to use boost) ;-)

Regards
Philippe

Hi !

There's an optional BuildRequire that seems to be useful for ardour3:
libltc
http://x42.github.com/libltc/

there's no rpm for it 
it replaces ltcsmpte (that existed only in debian and ubuntu, not in )

it's a library handling time code to synchronize audio and midi tracks

it is linked to ltc-tools and libtimecode
https://github.com/x42/ltc-tools
https://github.com/x42/libtimecode


Nevertheless that's not the reason why I couldn't build.
I try to explore

Created attachment 3177 [details]
a bad draft of spec file for ardour3

It's really a draft :

the %files part is useless because it couldn't install anything in BUILDROOT

Created attachment 3178 [details]
extract of the build log when it fails

13552 is buggy, fix is in 13554.

I will probably commit ardour3 package to svn using 13546 (which is working) so we can collaborate on it.

There is mk_svn_tar in the SOURCES which is modified to detect ardour3 and create a needed file and add it to the tarball - or it won't build.

Probably best to stick with 13546 for now, which is in the sources.

Outstanding:
The main issue is configs install path - which I have not had time / expertise to fix yet. There are some notes in the spec.

Probably some extra BRs in there from 2.x.x

libs need some wildcards eventually

Not sure about group


Check it out with:
mgarepo co ardour3 
so that you can send me svn diff output for any changes.

Just a little comment :
I'm on it but short in time.

I found yesterday night that it was the install part of svn 13552 that was wrong !

I could indeed build without trying to install  with ./waf (not doing ./waf install)
got some warnings 

but when I tried to launch directly from the blabla/BUILD/ardour-3.0 with ./ardev command I got a segfault ...
even when jackctl launched first

there's no valid bug option in waf !?

Gonna try tonight with your spec

OK, I just packaged ltc so I will update ardour3 spec with that added when it's pushed.
IIANM this (ardour3) will need to be split into a heap of small lib/dev packages as I don't think we can leave shared libs in the main package. Unless my understanding after reading (many many times) of the library policy is wrong. I will ask.

Yes they bundle ardour3 for a local build -it's not set up for a system install - hence the issues with the config etc.

There is also a massive over-linking problem as the package stands, and I have no idea how to fix it - yet. (I'll let you figure that one :)

Created attachment 3180 [details]
some modif to your spec file

Hi Barry

Mgarepo + svn diff

Very nice tools indeed

So :
I downloaded your job and played a little with your spec file

It's easier to work on a sane basis !!!

I found a way to install the /etc/stuff in the good directory
I added or modified some BR
I added some options and comments about other options

I build a rpm and installed it ... (no problem on Mageia2)

Wonderful evolution ... Ardour3 it's quite perfect ! no problem to use it
When you have launch qjackctl first, the connections are automagically done inside it when you launche Ardour3

I think you really may push it ! 

NB there are only some warnings when building 
I will attach a file with all these warnings

Attachment 3177 is obsolete: 0 => 1

Created attachment 3181 [details]
extract of the build log when it fails with your spec

Quite no difference with the build log of the build with svn13546
(the warnings don't appear in the same order)

It is maybe useful for the ardour3 dev... but not for us

Well done - excellent. \o/
It's getting there now.

I made a few changes to svn today, and I think you diffed against an earlier revision than I was at. 
Before making a final diff it's best to rename the spec file you are working on by e.g. adding an X to the end and running 'svn up' which will replace the missing spec with the current version in svn.
Immediately delete it and rename yours back (remove the X) and run 'svn diff > svndiff' to get a diff against the most recent commit.

I cherry picked your changes - there is no need to add lv2-devel and those others as they are automatic requires of lilv and get pulled in - if you look at the change log you will see where I removed them.

I asked a few people about those libs and it's OK to leave them in the main package.

There is no need for --lv2 etc in the waf configure as it is found without it.

I also asked upstream about the docs and .desktop and he says they have probably never been built under waf, so we need to add something in the spec.

The minimum versions on BRs should not be needed (I had removed them) since we are currently above all those in Cauldron, however for now I have put them back just for you :)

Not sure why you think ./waf clean may be needed. Builds all start in a clean chroot on the BS, so it's not needed, however for testing locally I leave an empty %clean section, which stops BUILDROOT being cleaned automatically after a successful build, so I can study the contents.

Last build with the spec which I will commit in a moment is here http://mtf.no-ip.co.uk/pub/linux/barjac/distrib/cauldron/x86_64/log/ardour3-3.0-0.13546.mga3.src.rpm/build.0.20121129005241.log
Note that sratom, serd, sord lv2 are all found despite not being specifically added a BRs.

The next one to solve is the overlinking...

Created attachment 3183 [details]
less modif to your last spec file

some suggestions about your last spec fiel

Attachment 3180 is obsolete: 0 => 1

Just a question about overlinking and about the way to know there is overlinking :
is it what is shown near the end of the build log ? like this kind of lines

.../...
Warning: unused libraries in /usr/lib64/ardour3/libvampplugin.so.0.0.0: libfftw3f.so.3
 libm.so.6

Warning: unused libraries in /usr/lib64/ardour3/libpbd.so.4.1.0: libgio-2.0.so.0

Warning: unused libraries in /usr/lib64/ardour3/libmidipp.so.4.1.0: 	libpbd.so.4
 	libsmf.so
 	libtimecode.so.0
 libgobject-2.0.so.0
 libsigc-2.0.so.0
 libglib-2.0.so.0
 libxml2.so.2
 libuuid.so.1
 libsndfile.so.1
 libgiomm-2.4.so.1
 libgio-2.0.so.0
 libgthread-2.0.so.0
 librt.so.1
 libm.so.6
.../...

Yes, but I admit to not fully understanding it despite much reading - maybe your more agile brain can figure it. 

I patched with all your changes (and then removed your comments - the libart one was actually OK as it was pulling in lib64art_lgpl-devel, however pkgconfig(libart-2.0) as you point out is more correct.

Glad you noticed that the BRs are in alphabetical order ;)

Your patch also introduced an extra space in the configure line.

Regarding freedesktop - I don't think it's worth worrying about. Upstream are not really interested in distributions since they ask for donations on the website when people download the 'bundle', however they don't actively discourage distribution either - I had a good chat and suggested they add a donate button to the 'about' dialog to compensate somewhat and that seemed to be accepted as a good idea.
Any upstream .desktop would probably need editing in the spec, so ours is perfectly acceptable.

Regarding documentation - if you can figure out how to build it - let me know. I looked briefly, but short on time and the Makefile mutters about scons. :\

OK thanks for your work - I think I should really become your official mentor as I don't think you will be apprentice for long ;)

Regarding my last comment.
What is your Mageia account name here http://identity.mageia.org/

ardour3 is now in Cauldron, it may be installed alongside ardour.

Please test and report any issues here.

Many thanks to Philippe Didier for his persistence in getting this project off the ground :)

Closing bug as fixed, not quite true but a good alternative I hope.

Status: NEW => RESOLVED
Resolution: (none) => FIXED

Created attachment 3187 [details]
a little modification to allow national languages support

Hi Barry :
I finally found a way to have locale support...
not really well documented !!!
The Gui is now in french for me ;-)

Besides that :
I'm digging about a way to prevent from overlinking...
and to build a manual

unsuccessfuly

You may (temporarily) close the bug again

Regards
Philippe

Attachment 3183 is obsolete: 0 => 1

(In reply to comment #34)
> Regarding my last comment.
> What is your Mageia account name here http://identity.mageia.org/

Hi Barry !

Forgot to give my account name...
it's simply philippedidier

It would be nice to cooperate with you, even if I have not the skill, nor the tools (a dedicated computer and soundcard to use cauldron) to become a real packager...

I have still some other music packages to propose ;-)

And a pending package request for a sail navigation software (bug 7932) :
Its spec file is more canonical (respecting the Mageia policy), but may miss some BuildRequires.


Regards
Philippe

(In reply to comment #28)
> When you have launch qjackctl first, the connections are automagically done
Now ardour don't work without package qjackctl. I think qjackctl must be in Requires.

CC: (none) => loginov_alex

This new version of Ardour3 needs indeed jackd running .
jackit is already required

The Ardour3 GUI allows itself to create connections (qjackctl is not needed for this purpose)

Requiring qjackctl is not explicitely needed ... and the fact of having this rpm installed can't, by itself, automatically launch qjackctl (and so jackd) before Ardour3.


Nevertheless the problem remains : what is the good way to have jackd running first ?

 1)
If qjackctl is launched first before Ardour3, it's OK jackd runs... but we need a way to say to the user he needs to launch qjackctl first (only to have jackd running).

 2)
We may provide a script that asks for jackd before launching Ardour3

But if qjackctl was already used, for a Computer Assisted Music session (using a sampler, a keyboard or a sequencer for instance, connected through qjackctl)
  launching Ardour3, then, through this script, might bring problems with jackd already running ! (twice jackd side by side ... It may be a mess !)

I tested it on Mageia2 (for which I built a rpm with Ardour3 srpm from mga3)

I don't see any problem indeed :
If qjackctl is launched first and Ardour3 secondly it's OK

If qjackctl is not running, Ardour starts jackd automatically... and the connexions can be created through the new Ardour GUI... no need of qjackctl


You just have to create a new track and connect what you want to the audio input

(through menu Window)

Many changes in the GUI since Ardour2....

Status: REOPENED => RESOLVED
Resolution: (none) => WORKSFORME

(In reply to comment #38)
> (In reply to comment #28)
> > When you have launch qjackctl first, the connections are automagically done
> Now ardour don't work without package qjackctl. I think qjackctl must be in
> Requires.

Sorry for the misunderstanding that was induced by my comment #28 :

Indeed what I mean is:
1) Ardour3 can launch jackd if it was not already running, and you can create connections inside the Ardour GUI => so no need for qjackctl, and no need for any script

2) But, more than this, if qjackctl is already running before Ardour3 is launched, Ardour3 will appear inside the connection window of qjackctl... and connected to your audio system (it doesn't launch twice jackd ...)
and you will be able to add connections for Ardour3 with which ever jack-connectable audio and MIDI plugin or software you launch ...

So qjackctl is not needed for basical use... but if you launch it you will have more connections possibilities . and no problem induced.

Regards 
Philippe