Re: [Fink-devel] compatibility version problem

2010-09-29 Thread Peter O'Gorman 
On 09/29/2010 05:53 PM, David R. Morrison wrote:
>
> On Sep 30, 2010, at 7:45 AM, Alexander Hansen wrote:
>
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA1
>>
>> On 9/29/10 5:08 PM, Ebrahim Mayat wrote:
>>> Hello list
>>>
>>> With reference to my submission (#3074237) for fluidsynth-1.1.2, I have
>>> come across a compatibility version issue.
>>>
>>> As similarly outlined in my earlier message:
>>>
>>> 
>>>
>>> using autotools for the previous version of fluidsynth-1.1.1, the
>>> compatibility version for the shared library libfluidsynth.1.dylib is
>>>
 /sw/lib/libfluidsynth.1.dylib (compatibility version 5.0.0, current
 version 5.0.0)
>>>
>>> while building with cmake for fluidsynth-1.1.2 gives
>>>
 /sw/lib/libfluidsynth.1.dylib (compatibility version 1.0.0, current
 version 1.4.0)
>>>

Ew!

You'll have to relink the library "by hand" in the .info file, giving it 
a compatibility version >= 5.0.0, or figure out how to tell cmake to use 
a different compatibility version.

Please report this to the upstream developers, since it means that any 
binary that used fluidsynth-1.1.1 will need to be rebuilt to use 1.1.2 
(and it seems likely that is not their intention).

Peter

--
Start uncovering the many advantages of virtual appliances
and start using them to simplify application deployment and
accelerate your shift to cloud computing.
http://p.sf.net/sfu/novell-sfdev2dev
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
http://news.gmane.org/gmane.os.apple.fink.devel
Subscription management:
https://lists.sourceforge.net/lists/listinfo/fink-devel

Re: [Fink-devel] compatibility version problem

2010-09-29 Thread Hanspeter Niederstrasser 
On 9/29/10 6:53 PM, David R. Morrison wrote:
>
> On Sep 30, 2010, at 7:45 AM, Alexander Hansen wrote:
>
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA1
>>
>> On 9/29/10 5:08 PM, Ebrahim Mayat wrote:
>>> Hello list
>>>
>>> With reference to my submission (#3074237) for fluidsynth-1.1.2, I have
>>> come across a compatibility version issue.
>>>
>>> As similarly outlined in my earlier message:
>>>
>>> 
>>>
>>> using autotools for the previous version of fluidsynth-1.1.1, the
>>> compatibility version for the shared library libfluidsynth.1.dylib is
>>>
 /sw/lib/libfluidsynth.1.dylib (compatibility version 5.0.0, current
 version 5.0.0)
>>>
>>> while building with cmake for fluidsynth-1.1.2 gives
>>>
 /sw/lib/libfluidsynth.1.dylib (compatibility version 1.0.0, current
 version 1.4.0)
>>>
>>> So, this leads to a problem since the compatibility version is being
>>> downgraded. The reviewer has suggested that this problem can be
>>> circumvented by simply renaming the package.
>>> For example, instead of "fluidsynth" the new package can be called
>>> "fluidsynth1".  This would seem simple enough but perhaps some of you
>>> may have alternative ideas that should be considered.
>>>
>>> I would appreciate any suggestions on how I could effectively deal with
>>> this compatibility version problem.
>>>
>>> Sincerely,
>>> Ebrahim
>>>
>>>
>>>
>>>
>>
>> That's probably the most straightforward way to handle the situation.
>> You'd want to have fluidsynth1-dev and fluidsynth-dev Conflict and
>> Replace each other, of course.
>>
>
> I'm afraid this case is trickier than that, because the major version of the 
> library has not changed and therefore the primary filename of the shared 
> library has not changed.  So the files in the two -shlibs splitoffs will 
> conflict, and you can't use one to replace the other or the compatibility 
> version will break.
>
> Would it be possible to go back to using autotools to compile the package?  
> If not, you are going to have to modify the cmake procedures so that they 
> produce compatibility versions in the same way as the old autotools build 
> method did.  Since I know very little about cmake, I can't give advice about 
> how to do this.

Speex had a similar issue recently (offloaded public but unstable 
symbols to another dylib) but kept the install name the same.  The new 
speex version was put into a new package name (speex3 -> libspeex1) 
*AND* the libraries were put into a 'hidden' directory 
/sw/lib/libspeex1/lib (that is, not directly into /sw/lib) to avoid 
filename collisions while maintaining Shlibs policy.

Hanspeter

--
Start uncovering the many advantages of virtual appliances
and start using them to simplify application deployment and
accelerate your shift to cloud computing.
http://p.sf.net/sfu/novell-sfdev2dev
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
http://news.gmane.org/gmane.os.apple.fink.devel
Subscription management:
https://lists.sourceforge.net/lists/listinfo/fink-devel

Re: [Fink-devel] compatibility version problem

2010-09-29 Thread David R. Morrison 

On Sep 30, 2010, at 7:45 AM, Alexander Hansen wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> On 9/29/10 5:08 PM, Ebrahim Mayat wrote:
>> Hello list
>> 
>> With reference to my submission (#3074237) for fluidsynth-1.1.2, I have
>> come across a compatibility version issue.
>> 
>> As similarly outlined in my earlier message:
>> 
>> 
>> 
>> using autotools for the previous version of fluidsynth-1.1.1, the
>> compatibility version for the shared library libfluidsynth.1.dylib is
>> 
>>> /sw/lib/libfluidsynth.1.dylib (compatibility version 5.0.0, current
>>> version 5.0.0)
>> 
>> while building with cmake for fluidsynth-1.1.2 gives
>> 
>>> /sw/lib/libfluidsynth.1.dylib (compatibility version 1.0.0, current
>>> version 1.4.0)
>> 
>> So, this leads to a problem since the compatibility version is being
>> downgraded. The reviewer has suggested that this problem can be
>> circumvented by simply renaming the package.
>> For example, instead of "fluidsynth" the new package can be called
>> "fluidsynth1".  This would seem simple enough but perhaps some of you
>> may have alternative ideas that should be considered.
>> 
>> I would appreciate any suggestions on how I could effectively deal with
>> this compatibility version problem.
>> 
>> Sincerely,
>> Ebrahim
>> 
>> 
>> 
>> 
> 
> That's probably the most straightforward way to handle the situation.
> You'd want to have fluidsynth1-dev and fluidsynth-dev Conflict and
> Replace each other, of course.
> 

I'm afraid this case is trickier than that, because the major version of the 
library has not changed and therefore the primary filename of the shared 
library has not changed.  So the files in the two -shlibs splitoffs will 
conflict, and you can't use one to replace the other or the compatibility 
version will break.

Would it be possible to go back to using autotools to compile the package?  If 
not, you are going to have to modify the cmake procedures so that they produce 
compatibility versions in the same way as the old autotools build method did.  
Since I know very little about cmake, I can't give advice about how to do this.

  -- Dave



--
Start uncovering the many advantages of virtual appliances
and start using them to simplify application deployment and
accelerate your shift to cloud computing.
http://p.sf.net/sfu/novell-sfdev2dev
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
http://news.gmane.org/gmane.os.apple.fink.devel
Subscription management:
https://lists.sourceforge.net/lists/listinfo/fink-devel

Re: [Fink-devel] compatibility version problem

2010-09-29 Thread Alexander Hansen 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 9/29/10 5:08 PM, Ebrahim Mayat wrote:
> Hello list
> 
> With reference to my submission (#3074237) for fluidsynth-1.1.2, I have
> come across a compatibility version issue.
> 
> As similarly outlined in my earlier message:
> 
> 
> 
> using autotools for the previous version of fluidsynth-1.1.1, the
> compatibility version for the shared library libfluidsynth.1.dylib is
> 
>> /sw/lib/libfluidsynth.1.dylib (compatibility version 5.0.0, current
>> version 5.0.0)
> 
> while building with cmake for fluidsynth-1.1.2 gives
> 
>> /sw/lib/libfluidsynth.1.dylib (compatibility version 1.0.0, current
>> version 1.4.0)
> 
> So, this leads to a problem since the compatibility version is being
> downgraded. The reviewer has suggested that this problem can be
> circumvented by simply renaming the package.
> For example, instead of "fluidsynth" the new package can be called
> "fluidsynth1".  This would seem simple enough but perhaps some of you
> may have alternative ideas that should be considered.
> 
> I would appreciate any suggestions on how I could effectively deal with
> this compatibility version problem.
> 
> Sincerely,
> Ebrahim
> 
> 
> 
> 

That's probably the most straightforward way to handle the situation.
You'd want to have fluidsynth1-dev and fluidsynth-dev Conflict and
Replace each other, of course.

You may also find it convenient to have the package which contains the
executable (currently the main package) continue to be called
'fluidsynth'.  This strategy requires some tricks, but is convenient for
upgrades when people have the executable package installed.

The easiest way to handle it would be either to have the filename for
the new package be fluidsynth-1.1.2.info, or (as is more commonly done)
to make the prior version fluidsynth-1.1.1.info.  Changing the filename
disrupts the CVS history, but that's not insurmountable.
- -- 
Alexander Hansen
Fink User Liaison
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkyjwXcACgkQB8UpO3rKjQ8NsQCglr35fFb2QxGsWjeC7jZ0QxDK
mUQAoKeypQLaC8t42dniS5Qq4FDtRmIW
=wdHF
-END PGP SIGNATURE-

--
Start uncovering the many advantages of virtual appliances
and start using them to simplify application deployment and
accelerate your shift to cloud computing.
http://p.sf.net/sfu/novell-sfdev2dev
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
http://news.gmane.org/gmane.os.apple.fink.devel
Subscription management:
https://lists.sourceforge.net/lists/listinfo/fink-devel

[Fink-devel] compatibility version problem

2010-09-29 Thread Ebrahim Mayat 

Hello list

With reference to my submission (#3074237) for fluidsynth-1.1.2, I  
have come across a compatibility version issue.


As similarly outlined in my earlier message:



using autotools for the previous version of fluidsynth-1.1.1, the  
compatibility version for the shared library libfluidsynth.1.dylib is


/sw/lib/libfluidsynth.1.dylib (compatibility version 5.0.0, current  
version 5.0.0)


while building with cmake for fluidsynth-1.1.2 gives

/sw/lib/libfluidsynth.1.dylib (compatibility version 1.0.0, current  
version 1.4.0)


So, this leads to a problem since the compatibility version is being  
downgraded. The reviewer has suggested that this problem can be  
circumvented by simply renaming the package.
For example, instead of "fluidsynth" the new package can be called  
"fluidsynth1".  This would seem simple enough but perhaps some of you  
may have alternative ideas that should be considered.


I would appreciate any suggestions on how I could effectively deal  
with this compatibility version problem.


Sincerely,
Ebrahim


--
Start uncovering the many advantages of virtual appliances
and start using them to simplify application deployment and
accelerate your shift to cloud computing.
http://p.sf.net/sfu/novell-sfdev2dev___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
http://news.gmane.org/gmane.os.apple.fink.devel
Subscription management:
https://lists.sourceforge.net/lists/listinfo/fink-devel

Re: [Fink-devel] [cvs] dists/10.4/unstable/main/finkinfo/sound fluidsynth.info, 1.7, 1.8

2010-09-29 Thread Ebrahim Mayat 

On Sep 29, 2010, at 10:22 AM, Alexander Hansen wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Hi.  There was an extra comma in an enum field in fluidsynth/synth.h
> which caused scummvm (and likely other packages) not to build.
>
> Since this was an obvious and quick fix, I went ahead and  
> implemented it
> after testing that the scummvm build issue was indeed fixed.   
> Hopefully
> this is OK for all concerned.
>
> -  Original Message 
> Subject: [cvs] dists/10.4/unstable/main/finkinfo/sound
> fluidsynth.info, 1.7, 1.8
> Date: Wed, 29 Sep 2010 14:18:35 +
> From: Alexander Hansen 
> Reply-To: fink-devel@lists.sourceforge.net
> To: fink-comm...@lists.sourceforge.net
> Newsgroups: gmane.os.apple.fink.cvs
> Followup-To: gmane.os.apple.fink.devel
>
> Update of /cvsroot/fink/dists/10.4/unstable/main/finkinfo/sound
> In directory sfp-cvsdas-3.v30.ch3.sourceforge.com:/tmp/cvs-serv16693
>
> Modified Files:
>   fluidsynth.info
> Log Message:
> Fix malformed header file
>
> Index: fluidsynth.info
> ===
> RCS file:
> /cvsroot/fink/dists/10.4/unstable/main/finkinfo/sound/ 
> fluidsynth.info,v
> retrieving revision 1.7
> retrieving revision 1.8
> diff -u -d -r1.7 -r1.8
> - --- fluidsynth.info 5 Jul 2010 10:20:18 -   1.7
> +++ fluidsynth.info   29 Sep 2010 14:18:33 -  1.8
> @@ -1,6 +1,6 @@
> Package: fluidsynth
> Version: 1.1.1
> - -Revision: 280
> +Revision: 281
> #Distribution: 10.5, 10.6
> ###
> Depends: <<
> @@ -17,6 +17,9 @@
> Source: http://download.savannah.gnu.org/releases/fluid/%n-%v.tar.gz
> Source-md5: 0db3da78028d255026230809c6e21b44
> ###
> +PatchScript: <<
> + perl -pi -e 's/R = 7,/R = 7/' include/%n/synth.h
> +<<
> SetLDFLAGS:
> ConfigureParams:
> ###
> @@ -59,4 +62,7 @@
> for audio synthesis.
> <<
> ###
> +DescPort: <<
> +AKH:  typo in fluidsynth/synth.h fixed at Revision 281
> +<<
> Maintainer: Ebrahim Mayat 
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.4.10 (Darwin)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iEYEARECAAYFAkyjS44ACgkQB8UpO3rKjQ/R+ACcDx8NYW+rFPGPDcJ4fUK8ofyp
> QJIAn11/+loJbQm+NWqndfETRkRWEjSI
> =uXKT
> -END PGP SIGNATURE-

Alexander

I have put this question to the fluid-devs. (Personally I am okay with  
it.) I don't think that there should be any objection from the fluid- 
devs to your suggestion.

Many thanks,
Ebrahim 

--
Start uncovering the many advantages of virtual appliances
and start using them to simplify application deployment and
accelerate your shift to cloud computing.
http://p.sf.net/sfu/novell-sfdev2dev
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
http://news.gmane.org/gmane.os.apple.fink.devel
Subscription management:
https://lists.sourceforge.net/lists/listinfo/fink-devel

[Fink-devel] Fwd: [cvs] dists/10.4/unstable/main/finkinfo/sound fluidsynth.info, 1.7, 1.8

2010-09-29 Thread Alexander Hansen 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi.  There was an extra comma in an enum field in fluidsynth/synth.h
which caused scummvm (and likely other packages) not to build.

Since this was an obvious and quick fix, I went ahead and implemented it
after testing that the scummvm build issue was indeed fixed.  Hopefully
this is OK for all concerned.

-  Original Message 
Subject: [cvs] dists/10.4/unstable/main/finkinfo/sound
fluidsynth.info, 1.7,   1.8
Date: Wed, 29 Sep 2010 14:18:35 +
From: Alexander Hansen 
Reply-To: fink-devel@lists.sourceforge.net
To: fink-comm...@lists.sourceforge.net
Newsgroups: gmane.os.apple.fink.cvs
Followup-To: gmane.os.apple.fink.devel

Update of /cvsroot/fink/dists/10.4/unstable/main/finkinfo/sound
In directory sfp-cvsdas-3.v30.ch3.sourceforge.com:/tmp/cvs-serv16693

Modified Files:
fluidsynth.info
Log Message:
Fix malformed header file

Index: fluidsynth.info
===
RCS file:
/cvsroot/fink/dists/10.4/unstable/main/finkinfo/sound/fluidsynth.info,v
retrieving revision 1.7
retrieving revision 1.8
diff -u -d -r1.7 -r1.8
- --- fluidsynth.info   5 Jul 2010 10:20:18 -   1.7
+++ fluidsynth.info 29 Sep 2010 14:18:33 -  1.8
@@ -1,6 +1,6 @@
 Package: fluidsynth
 Version: 1.1.1
- -Revision: 280
+Revision: 281
 #Distribution: 10.5, 10.6
 ###
 Depends: <<
@@ -17,6 +17,9 @@
 Source: http://download.savannah.gnu.org/releases/fluid/%n-%v.tar.gz
 Source-md5: 0db3da78028d255026230809c6e21b44
 ###
+PatchScript: <<
+   perl -pi -e 's/R = 7,/R = 7/' include/%n/synth.h
+<<
 SetLDFLAGS:
 ConfigureParams:
 ###
@@ -59,4 +62,7 @@
 for audio synthesis.
 <<
 ###
+DescPort: <<
+AKH:  typo in fluidsynth/synth.h fixed at Revision 281
+<<
 Maintainer: Ebrahim Mayat 
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkyjS44ACgkQB8UpO3rKjQ/R+ACcDx8NYW+rFPGPDcJ4fUK8ofyp
QJIAn11/+loJbQm+NWqndfETRkRWEjSI
=uXKT
-END PGP SIGNATURE-

--
Start uncovering the many advantages of virtual appliances
and start using them to simplify application deployment and
accelerate your shift to cloud computing.
http://p.sf.net/sfu/novell-sfdev2dev
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
http://news.gmane.org/gmane.os.apple.fink.devel
Subscription management:
https://lists.sourceforge.net/lists/listinfo/fink-devel

Re: [Fink-devel] wine stable/unstable

2010-09-29 Thread Damian Dimmich 
  Hi Alexander,

That's cool - in that case what I've done is created a second package 
called wine-stable which will track the stable releases of wine, and 
left the 'normal' wine package to be the development one:

The stable can be found here:
https://sourceforge.net/tracker/?func=detail&aid=3077940&group_id=17203&atid=414256

and devel, updated to conflict and replace the stable
https://sourceforge.net/tracker/?func=detail&aid=3075933&group_id=17203&atid=414256

I've also gotten both packages to work with opengl accelleration, which 
didn't work before for me.

Damian
On 24/09/10 22:07, Alexander Hansen wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Our stable tree version need have nothing to do with what upstream
> considers stable or unstable.  "stable" for our purposes entails that
> the package works, and builds on a clean system, against only
> dependencies that are in the stable tree.  It's often easiest just to
> put the current upstream stable version into Fink's unstable.
>
> You can certainly come up with a wine-1.2 package description, but there
> is no way that it can go straight into stable without testing.  There's
> no problem with having both 1.2 and 1.3.3 in unstable while this occurs,
> as you can have e.g. wine-1.2.info referring to wine-1.2, and people can
> use e.g. "fink install wine-1.2-1" to install that version for testing.
>
> On 9/24/10 2:01 PM, Damian Dimmich wrote:
>> Hi All,
>>
>> I've been asked by, presumably, one of the wine dev's to put wine 1.2
>> into the 'stable' tree of fink.
>>
>> I'm happy to do this, although I'm not sure what this would entail
>> (well, I can create the .info file in any case and test it).
>>
>> Currently 1.3.3 is in unstable fink.
>>
>> Thoughts?
>>
>> Cheers,
>>
>> Damian
>>
> - -- 
> Alexander Hansen
> Fink User Liaison
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.4.10 (Darwin)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iEYEARECAAYFAkydExQACgkQB8UpO3rKjQ8yWgCeLYCZIwy6Y/ZNNCtTa0qnqPFv
> /N4AnAxjAw/0OIk6KxlYZ+4EpSn41X4e
> =s6Lu
> -END PGP SIGNATURE-


--
Start uncovering the many advantages of virtual appliances
and start using them to simplify application deployment and
accelerate your shift to cloud computing.
http://p.sf.net/sfu/novell-sfdev2dev
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
http://news.gmane.org/gmane.os.apple.fink.devel
Subscription management:
https://lists.sourceforge.net/lists/listinfo/fink-devel