Updates in fink's git master.

I've just put some updates into the fink master branch
(https://github.com/fink/fink)
The major changes are as follows:
1) bootstrap will work if users on Lion have just the Xcode Command Line
Tools, and not the full Xcode.
2) The gcc* virtual packages have been tightened up a bit. The only
versions that show as potentially installable on a given OS version are
those which can be installed via the Xcode installer for that OS
version, e.g. gcc4.2 is listed on 10.5, because Xcode 3.1 has it, 10.6,
because Xcode 3.2.x has it, and 10.7, because Xcode 4.1 has it.
3) There is now a clang virtual package, which shows up as a potential
option on 10.6 and later. Translated into a fink version and revision,
"Apple clang version 3.1 (tags/Apple/clang-318.0.58)" becomes
clang-3.1-3.18.0.58.
4) There is now an llvm-gcc virtual package, which shows up as a
potential option on 10.6 and later. Translated into a fink version and
revision, "i686-apple-darwin11-llvm-gcc-4.2 (GCC) 4.2.1 (Based on Apple
Inc. build 5658) (LLVM build 2336.9.00)" becomes llvm-gcc-4.2.1-2336.9.00.
If people try it, and I don't get any bad reports, I'll do a release in
a couple of days.
--
--
Alexander Hansen, Ph.D.
Fink User Liaison
http://finkakh.wordpress.com/2012/02/21/got-job/
------------------------------------------------------------------------------

Re: Changing fink-obsolete-packages dependencies to RuntimeDepends

Charles Lepple <clepple <at> gmail.com>
2012-04-04 01:23:00 GMT

On Mar 29, 2012, at 5:27 AM, Max Horn wrote:
> Dear all,
> a small clarification:
>
>
> Am 28.03.2012 um 17:46 schrieb Max Horn:
>
>> Dear package authors,
>>
>> I would like to suggest the following to all package authors using
>>
>> Depends: fink-obsolete-packages
>>
>> in an obsolete splitoff in one of their packages: Namely, please switch to using
>>
>> Depends: fink (>= 0.32)
>> RuntimeDepends: fink-obsolete-packages
>
> This should be
> BuildDepends: fink (>= 0.32)
> RuntimeDepends: fink-obsolete-packages
Max,
Does this apply for splitoffs only, or for standalone info files as well?
Example: Buildbot split into master and slave packages upstream. There is a buildbot-py.info that
depends on fink-obsolete-packages and the two new separate .info files.

Suggested packages

Remko Scharroo <remko <at> altimetrics.com>
2012-04-09 21:41:10 GMT

Dear Fink Developers,
I would like to contribute two science packages to Fink 10.7:
- sci/grib-api (ECMWF GRIB API)
- sci/cdo (Climate Data Operators)
The latter used to appear in Fink 10.6 but has no maintainer and was not ported to 10.7.
I'm running both packages for while with success. I'd be willing to become the maintainer of these packages
(tell me how), or someone can pick them up below.
Regards,
Remko

------------------------------------------------------------------------------
For Developers, A Lot Can Happen In A Second.
Boundary is the first to Know...and Tell You.
Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
http://p.sf.net/sfu/Boundary-d2dvs2

Re: Suggested packages

On 4/9/12 2:41 PM, Remko Scharroo wrote:
> Dear Fink Developers,
>
> I would like to contribute two science packages to Fink 10.7:
> - sci/grib-api (ECMWF GRIB API)
> - sci/cdo (Climate Data Operators)
> The latter used to appear in Fink 10.6 but has no maintainer and was not ported to 10.7.
>
> I'm running both packages for while with success. I'd be willing to become the maintainer of these
packages (tell me how), or someone can pick them up below.
>
> Regards,
> Remko
>
>
How to become the maintainer would be to put your name and preferred
email address in the Maintainer field, and send the files with those
changes. --
--
Alexander Hansen, Ph.D.
Fink User Liaison
http://finkakh.wordpress.com/2012/02/21/got-job/
------------------------------------------------------------------------------
For Developers, A Lot Can Happen In A Second.
Boundary is the first to Know...and Tell You.
Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
http://p.sf.net/sfu/Boundary-d2dvs2
_______________________________________________

switch to framework python builds?

Jack Howarth <howarth <at> bromo.med.uc.edu>
2012-04-11 14:43:46 GMT

Daniel and Daniel,
While creating test packaging for a wxcocoa923-py package for use
with relax-py, I discovered that the cocoa build of wxPython 9.2.3.1
issues an error message, when running its demos, that access to the
screen requires a framework build of python for the cocoa support.
Since MacPorts already builds their pythons as frameworks, I'll
continue testing there to make sure that the resulting wxPython
with cocoa support is fully functional. If it is, we really might
want to consider switching our python packages over to framework
builds as well in order to be able to use the upcoming cocoa support
in such packages as wxPython.
Jack
------------------------------------------------------------------------------
Better than sec? Nothing is better than sec when it comes to
monitoring Big Data applications. Try Boundary one-second
resolution app monitoring today. Free.
http://p.sf.net/sfu/Boundary-dev2dev
_______________________________________________
Fink-devel mailing list
Fink-devel <at> lists.sourceforge.net
List archive:
http://news.gmane.org/gmane.os.apple.fink.devel
Subscription management:
https://lists.sourceforge.net/lists/listinfo/fink-devel

Re: switch to framework python builds?

Daniel Macks <dmacks <at> netspace.org>
2012-04-11 15:04:05 GMT

Isn't the actual only difference between "framework" and "library" the
difference between using -F/-framework vs -L/-l flags when linking? And
the binary library inside .framework is really just a .dylib by a
different filenaming scheme. I can't envision any way that the linker
flags or filename/location could have any runtime effect at all, or
that any runtime-loading or configure-detection/makefile recipe
couldn't just have its flags changed to the normal-lib way.
dan
On Wed, 11 Apr 2012 10:43:46 -0400, Jack Howarth
<howarth <at> bromo.med.uc.edu> wrote:
Daniel and Daniel,
> While creating test packaging for a wxcocoa923-py package for use
> with relax-py, I discovered that the cocoa build of wxPython 9.2.3.1
> issues an error message, when running its demos, that access to the
> screen requires a framework build of python for the cocoa support.
> Since MacPorts already builds their pythons as frameworks, I'll
> continue testing there to make sure that the resulting wxPython
> with cocoa support is fully functional. If it is, we really might
> want to consider switching our python packages over to framework
> builds as well in order to be able to use the upcoming cocoa support
> in such packages as wxPython.
> Jack
>
>
--
Daniel Macks
dmacks <at> netspace.org

Re: switch to framework python builds?

Jack Howarth <howarth <at> bromo.med.uc.edu>
2012-04-11 15:40:49 GMT

On Wed, Apr 11, 2012 at 11:04:05AM -0400, Daniel Macks wrote:
> Isn't the actual only difference between "framework" and "library" the
> difference between using -F/-framework vs -L/-l flags when linking? And
> the binary library inside .framework is really just a .dylib by a
> different filenaming scheme. I can't envision any way that the linker
> flags or filename/location could have any runtime effect at all, or that
> any runtime-loading or configure-detection/makefile recipe couldn't just
> have its flags changed to the normal-lib way.
>
> dan
Dan,
It is unclear why wxPython is now demanding python frameworks. On their
web page http://www.wxpython.org/download-2.6.3.3.php, it says...
Mac OS X
wxPython needs a special Mac OS X-specific build of Python, called a Framework build, in order to work.
Panther and Tiger include a Framework build of Python 2.3, but on Jaguar you'll need to get the MacPython
installer from Jack's MacPython page.
Note to Fink users: Versions of Python installed by Fink cannot run wxPython (unless you install and run
X11...). You need to use Apple's Framework builds, or a third-party Framework build.
but it unclear if this really is only intended for users of prebuilt wxPython 2.9.x binaries.
However in http://www.wxpython.org/recentchanges.php, it mentions...
Added the ability to the build tools to make a Mac Framework for wxWidgets, and use it in the wxPython build.
(We're still ironing out some issues so it's not part of the release builds yet.)

Re: switch to framework python builds?

On Apr 11, 2012, at 11:04 AM, Daniel Macks <dmacks <at> netspace.org> wrote:
> Isn't the actual only difference between "framework" and "library" the difference between using
-F/-framework vs -L/-l flags when linking? And the binary library inside .framework is really just a
.dylib by a different filenaming scheme. I can't envision any way that the linker flags or
filename/location could have any runtime effect at all, or that any runtime-loading or
configure-detection/makefile recipe couldn't just have its flags changed to the normal-lib way.
> dan
Yes, it's just a matter of packaging. I'd bet though that wxcocoa
assumes that python is always a framework on OS X and only looks
there. It'll probably need patching.
Now there is another difference between fink's and system python; the
system's uses system tcltk which uses cocoa while fink's uses fink's
tcltk which uses x11. I don't know if that's an issue.
In any case, changing our python packages would require changing all
packages that link to them. That's a lot more work than fixing one
package. :)
Daniel
------------------------------------------------------------------------------
Better than sec? Nothing is better than sec when it comes to
monitoring Big Data applications. Try Boundary one-second
resolution app monitoring today. Free.
http://p.sf.net/sfu/Boundary-dev2dev
_______________________________________________
Fink-devel mailing list