Created attachment 2881 [details]
spec file for the last svn 2367

NB 
You need to download the last svn revision
Use Make -f Makefile.cvs on the downloaded directory
Compress the modified directory in tar.bz format
Name it libgig-svn2367.tar.bz2

use the patch provided just above

NB
This svn revision allows to work with soundfonts files (.sf2 or .sfz)
If it is updated it allows to rebuild the packages depending on it :
gigedit
linuxsampler

Created attachment 2898 [details]
modified spec file for the last svn 2367 (Requires added)

Attachment 2881 is obsolete: 0 => 1

I don't think you should be including those scripts in the package as they all contain:-

# This wrapper script should never be moved out of the build directory.
# If it is, it will not operate correctly.

I have no real idea what they are for, but maybe you could do some research?

Also take a look here  https://wiki.mageia.org/en/Packaging_guidelines

You will see that you should:
1. remove the %clean section
2. remove Buildroot:
3. remove %defattr(-,root,root)
4. Use {} in variables e.g. %{libname} %{version} etc.
5. Don't mix tabs and spaces for indentation

Hint - install rpmlint and rpmlint-mageia-policy and run it on the srpm to check it.
e.g.
rpmlint foo.srpm

CC: (none) => zen25000

Thanks... 
and thanks for the link to the guidelines

I only imported and a little adapted the spec file from Mandriva (I neverminded if it was clean or not ... wanted only to build gig on Mageia, so I have it to build linuxsampler)

it's really non canonical but it worked for this purpose... and I know we can provide the whole linuxsampler group sofwares


some scripts had to be explicitely included in Mandriva spec (%clean, Buildroot definition, %defattr) didn't know they were no more needed in Mageia.



Sure it's a draft :  I'll try to improve and test it ...

But as it is a part of a group of interacting  softwares for computer music (see bug 7579 and bug 7639 and think about rosegarden jackit dssi qjackctl...) this needs a confirmed maintainer (cook) when I only know how to peel (badly) potatoes to prepare his work ;)

Created attachment 3045 [details]
cleaner spec file for gig svn2367

hope this is better !

NB I changed the source name to use a tar.gz file directly made from the downloaded svn version.
I created it this way in my svn folder :
tar -czf libgig-svn2367.tar.gz libgig/ --exclude-vcs

I also needed to add :
[ -f Makefile.cvs ] && make -f Makefile.cvs
 in the %prep part of the spec file
This line will have to be commented to be used with the next official tarbal.


( I did it  an other way before : to be more compliant with the official tarbal and to use the same spec file for svn or official tarbal
1) I first copied the libgig directory and then run
 [ -f Makefile.cvs ] && make -f Makefile.cvs
2) In a second time I created a tar.bz2 source from these expanded directory (containing configure and Makefile)

(In reply to comment #6)
> Created attachment 3045 [details]
> cleaner spec file for gig svn2367
> 
> hope this is better !
>

Yes :)
It's missing a BuildRequire: doxygen - it's also better to use 
BuildRequires: pkgconfig(sndfile) rather than libsndfile-devel


> NB I changed the source name to use a tar.gz file directly made from the
> downloaded svn version.
> I created it this way in my svn folder :
> tar -czf libgig-svn2367.tar.gz libgig/ --exclude-vcs
> 

Yes that's fine

> I also needed to add :
> [ -f Makefile.cvs ] && make -f Makefile.cvs
>  in the %prep part of the spec file
> This line will have to be commented to be used with the next official tarbal.
> 
> 
> ( I did it  an other way before : to be more compliant with the official tarbal
> and to use the same spec file for svn or official tarbal
> 1) I first copied the libgig directory and then run
>  [ -f Makefile.cvs ] && make -f Makefile.cvs
> 2) In a second time I created a tar.bz2 source from these expanded directory
> (containing configure and Makefile)

Yes that is probably better although it does create a much larger tarball
117k --> 582k

I've been playing with a more generic tarball script:-
http://paste.kde.org/597728/
Still a WIP but it works ;)

(In reply to comment #7)

> It's missing a BuildRequire: doxygen - it's also better to use 
> BuildRequires: pkgconfig(sndfile) rather than libsndfile-devel
> 
> 
The more I build packages, the more I have installed dev packages
and less I'm warned about needed BuildRequires as they are already installed...
and less my spec files are pertinent.
That's not a problem for my personal use ;)
That's a problem to provide working spec files on Mageia Buildsystem
That's the reason why it's difficult for me to propose something else than bad drafts

> > 
> > ( I did it  an other way before : to be more compliant with the official tarbal
> > and to use the same spec file for svn or official tarbal
> > 1) I first copied the libgig directory and then run
> >  [ -f Makefile.cvs ] && make -f Makefile.cvs
> > 2) In a second time I created a tar.bz2 source from these expanded directory
> > (containing configure and Makefile)
> 
> Yes that is probably better although it does create a much larger tarball
> 117k --> 582k
> 
> I've been playing with a more generic tarball script:-
> http://paste.kde.org/597728/
> Still a WIP but it works ;)


I thougt it's better to work on a copy of the downloaded svn directory to apply
 [ -f Makefile.cvs ] && make -f Makefile.cvs
I created a ~/Sources/foodirectory (a copy of my ~/svn/foodirectory) for this purpose.

I'm afraid that if I apply "[ -f Makefile.cvs ] && make -f Makefile.cvs " on the ~/svn/foodirectory this one becomes incoherent when updating from the source with a new revision  ...

Maybe I'm wrong, but being ignorant I prefer to be prudent and careful :) 

Anyway that's a little off topic ...

Of course, feel free to modify the spec file to add missing BuildRequires , Requires or anything else, so that it is ready and useable for any goodwilling potential maintainer

Regards
Philippe

(In reply to comment #8)

> The more I build packages, the more I have installed dev packages
> and less I'm warned about needed BuildRequires as they are already installed...

Exactly

> That's a problem to provide working spec files on Mageia Buildsystem
> That's the reason why it's difficult for me to propose something else than bad
> drafts

It's better to test builds in a clean chroot with only a base system, build tools and BuildRequires installed. This can be done locally using the same tool that is used by the BS - iurt. It helps to have a local mirror, but it can also be used with urpmi-proxy, which stores the regularly required rpms locally so they are available for the chroot re-builds.
Some packagers just throw the spec at the BS and use it to do the testing, which is a reasonable approach if you have lots to maintain. I prefer to test locally first, but I only have a few.
> 
> I'm afraid that if I apply "[ -f Makefile.cvs ] && make -f Makefile.cvs " on
> the ~/svn/foodirectory this one becomes incoherent when updating from the
> source with a new revision  ...
> 
> Maybe I'm wrong, but being ignorant I prefer to be prudent and careful :) 
>

No you are right - and that highlights a glaring error in my script - it should keep a pristine copy of the svn. I said it was a WIP ;)

> Of course, feel free to modify the spec file to add missing BuildRequires ,
> Requires or anything else, so that it is ready and useable for any goodwilling
> potential maintainer

Maybe you? Have you had any thoughts about becoming apprentice? ;)

Are you on IRC? If not it would be useful if you were, as I don't like cluttering bug reports with general discussion. Otherwise maybe we could use ML, but again it would create noise. xchat is a good client, and #mageia-mentoring is fairly quiet :)

(In reply to comment #9)

> 
> It's better to test builds in a clean chroot with only a base system, build
> tools and BuildRequires installed. This can be done locally using the same tool
> that is used by the BS - iurt. It helps to have a local mirror, but it can also
> be used with urpmi-proxy, which stores the regularly required rpms locally so
> they are available for the chroot re-builds.

Before becoming a maintainer, able to commit,  I need to learn this first... ;)

Thanks for your help

Philippe

gig-3.3.0-0.2379.mga3 is now in cauldron, please test.

Thanks Philippe for your help. 

Closing as fixed.

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

I thank you indeed to take care of it

I saw (on svnweb.mageia.org) your mk_svn_tar script to make a tarball from the svn
... it seems nice ;)


I'm gonna download your srpm when it's on distrib-coffee repos, and try to build on my computer 

NB
I can't really install Cauldron on my everyday's computer... I have lots of too much precious work on it ! (i'm trying to find and get a test computer for this)

I used your srpm on MGA2

Good job indeed :
the built packages bring documentation that mine didn't provide (I didn't ever mind about it : I only wanted to have the devel rpm to build linuxsampler ;) )


NB there's an optional BuildRequires that may eventually be added : liuuid-devel

It's not absolutely  needed (we can provide gig without this) :
there's only this warning during configure phasis :

>configure: WARNING: No UUID generate function found.
>*** libgig will not be able to create DLSIDs in DLS and gig files.
>*** Install libuuid from e2fsprogs to solve this. Package might be called
>*** uuid-dev,

It's fixed - there's no point providing a crippled package for the sake of BuildRequires:	pkgconfig(uuid).

checking uuid/uuid.h usability... yes
checking uuid/uuid.h presence... yes
checking for uuid/uuid.h... yes

http://svnweb.mageia.org/packages?view=revision&revision=317595

Thanks :)

(In reply to comment #10)
> 
> Before becoming a maintainer, able to commit,  I need to learn this first... ;)
> 
> Thanks for your help
> 
> Philippe

Philippe,

The whole point of becoming an apprentice is that you learn by your errors, with someone who is able to advise you and correct you, so that mistakes are rectified without doing any damage.
You may initially only be able to supply patches to your mentor (as I did), then later get access to commit to svn, (but not submit anything), so any mistakes can be easily reverted.

Please re-consider joining the mentoring process, it's quite painless and can be fun!

You have much more packaging knowledge now than I had when I became an apprentice :)

Cheers,
Barry

Well, Barry and I were replying to the same comment at the same time, but I'll add mine anyway:

(In reply to comment #10)

> 
> Before becoming a maintainer, able to commit,  I need to learn this first... ;)
> 


You are now trying to do too much of the learning on your own. I'm listed as apprentice, and I know *nothing* at all compared to you. So there is no need to learn more before getting a mentor.

You don't need to fear that you'll become a *maintainer* before you're ready to be one.

The order is as follows:

1. First you become an apprentice without commit rights. Your specs are checked by your mentor, who comments on them when they need improvement and commits them when they're OK
2. Then, when you've proven yourself to the satisfaction of your mentor, you get commit right. You can commit to SVN, but not submit, you cannot yet submit to the build system. Before someone submits any of your commits, he'll have a look at them.
3. If that goes well over a long enough period of time, your mentor will propose to give you submit rights, so that you become a full packager and can choose to maintain one or more packages. You'll *never* be obliged to maintain packages that you don't feel confident with, and you can then even choose to maintain difficult packages you're interested in with a group.

Please reconsider becoming an apprentice, again. We need you, Philip, and when you have a mentor you'll learn faster :-D

CC: (none) => marja11

s/Philip/Philippe/ (Sorry about that)

You might have written ΦίλιÏÏÎ¿Ï or Felipe or Filip I would have understood it anyway !  ;-) 
nevermind !

I'm really thinking about becoming an apprentice ... in spite of the fact I only can work and test on a stable version, and have irregularly free time and web access .

(In reply to comment #18)

> 
> I'm really thinking about becoming an apprentice ... in spite of the fact I
> only can work and test on a stable version, and have irregularly free time and
> web access .

That is great news, Philippe :-D

Tbh, I only have time to learn something about packaging during part of my holidays. 
Having irregular free time and web access won't be a problem, as long as your mentor knows before he starts mentoring you ;)

I know, that not even all our mentors use cauldron. I'm wondering how they do that, though, because new versions of packages go into cauldron first. Maybe use virtualbox to first test it in cauldron? Anyway, if someone can be a mentor without using cauldron, I don't see how you that could be a problem for you.