Hi,
I maintain the packages fetchmail and fetchmail-ssl, which have been
in 'unstable' for quiet some time now. I'm not sure what the exact
policy on 'when to move xy to stable' is, but I received many positive
comments on fetchmail. It works very fine on my OS X boxes too. So, if
it's appropria
At 22:12 Uhr -0700 30.05.2002, Torrey T. Lyons wrote:
>I noticed at SourceForge that Fink has announced the availability of
>KDE for Mac OS X. First I should congratulate all the hard working
>KDE-Darwin and Fink developers!
>
>My concern is that I noticed that Fink has started to distribute
>l
Max Horn [[EMAIL PROTECTED]] wrote:
> I am fully with you on this. I stated similar concerns about this in
> the past but was overruled. In any case now it's not to late to undo
> this, if we can agree on it, even with relatively little pain.
>
> However, first we need to evaluate in how far sh
At 9:55 Uhr +0200 31.05.2002, Eric Knauel wrote:
>Hi,
>
>I maintain the packages fetchmail and fetchmail-ssl, which have been
>in 'unstable' for quiet some time now. I'm not sure what the exact
>policy on 'when to move xy to stable' is, but I received many positive
>comments on fetchmail. It works
Xinerama and Xv, in the shared lib format are *NOT* needed. They are only
used if present. Since Xinerama and Xv are built statics in the Xfree
build by default, and we turned them on, since I needed them for an other
port, and Ben build the KDE binaries from fink and the fink verion of
Xfree, t
these are the libs affected so far:
/sw/lib/libIDL-0.6.0.dylib (compatibility version 0.0.0, current version
0.0.0)
/sw/lib/libIIOP.0.dylib (compatibility version 0.0.0, current version 0.0.0)
/sw/lib/libORBit.0.dylib (compatibility version 0.0.0, current version 0.0.0
At 8:38 Uhr -0600 31.05.2002, Justin Hallett wrote:
>Xinerama and Xv, in the shared lib format are *NOT* needed. They are only
>used if present. Since Xinerama and Xv are built statics in the Xfree
>build by default, and we turned them on, since I needed them for an other
>port, and Ben build th
no there isn't. Plus why would you want to revert the change? It doesn't
hurt anything unless you try and mix to systems. hmmm...I think this
might end up being a problem with other pkgs for the bin dist as well.
shared libs and system pkgs are not gonna mix well in the bin dist.
[EMAIL PROTE
At 11:43 AM -0600 5/31/02, Justin Hallett wrote:
>no there isn't. Plus why would you want to revert the change? It doesn't
>hurt anything unless you try and mix to systems. hmmm...I think this
>might end up being a problem with other pkgs for the bin dist as well.
>shared libs and system pkgs a
This is true, how ever the system-xfree86 pkg is flawed in other ways as
well. Since some pkgs may depend on a certain version of xfree, and since
there is no way of knowing which is install with system-xfree86. The make
a pkg management system as fink all pkgs almost need to be controlled by
fi
Firstly i asked about the shared libs to the Xfree team, and there was no
good reason for them being disabled, according to my replies from the list.
Secondly this would be a concern if we were making .pkg OS X style
installed that aren't managed. (i.e. kinda like rpm thought I'll give
rpms quaz
of course i can't remember which pkg it was now, though it might be
mplayer, and it's cause Xinerama and Xv statics are flawed on darwin that
this happens mostly, and there are instructions on how to get xfree to
make the shared versions in the install notes (accutally I think it was
xine now that
hey developer,
i red your news about the kde on mac os x.
i'am a german mechanical engineering student from berlin and pls believe
me...a lot of users which never want touch windows anymore, which toke a
look on linux with a smile due too the missing graphic and video
apps...they wated for thi
yes and no. precompiled version may or may not work, and compiling these
programs for source if available might need some patches. Since IIRC most
of these are commercial programs and will never be in fink and are
probably distributed via binaries only form. You can try them but since
they are
Here's my opinion about this:
1) We are offering users the option of system-xfree86 or system-xtools. So
it only makes sense that we need to make sure that the Fink package works
exactly like the system-xfree86 package.
2) There are only a few other system-foo packages, and in each case we need
this is a correct statement and I agree 100% with it, my argument is
supporting the system pkgs. The problem is this statement will limit the
software we are able to port, like xine which IHMO is major port, or in
demd software. And we would not be able to provide it. I think that to
satisfy bo
Just to followup one more time: Torrey, we've had a bit more discussion
among fink developers on IRC, and it turns out that the problem which
Justin is having with xine is related to the lack of x-shm support on
Darwin. Somehow with the shared libs he can get around this (I wasn't
too clear about
just a short (and little late on top, i know) answer:
what fails to compile is actually not python but readline
> ### mv failed, exit code 1
> Failed: installing readline-shlibs-4.2a-5 failed
> [localhost:~] hester% "
i'm sorry if my mail confused you. all i said was that python itself
would c
At 4:17 PM -0400 5/31/02, David R. Morrison wrote:
>Just to followup one more time: Torrey, we've had a bit more discussion
>among fink developers on IRC, and it turns out that the problem which
>Justin is having with xine is related to the lack of x-shm support on
>Darwin. Somehow with the share
I'm slowly making progress on dx-2.4.0-- sorry to get everyone's hopes
up be prematurely submitting a compiled package...
I installed autoconf-2.5, and automake 1.5 to test for compatibility--
most bug reports concerned this.
The quick fix seems to be
SetCPP: cc -E -traditional-cpp
although th
cc -DHAVE_CONFIG_H -I. -I. -I../.. -DGNOMEDATADIR=\""/sw/share"\"
-DGNOMELOCALEDIR=\""/sw/share/locale"\"
-I../../src -I.
-I.
-I/sw/include/gnome-1.0
-DN
At 7:58 PM -0400 5/31/02, Jeremy Erwin wrote:
>
>Is there a way to get fink to properly expand $(CC) ? i.e
>SetCPP: $(CC) -E -traditional-cpp
>does not seem to work; it's flagged as "not sane" by configure-- the
>shell variable does not correctly expand.
CC is really just supposed to be the nam
On Friday, May 31, 2002, at 10:15 PM, Ben Hines wrote:
> At 7:58 PM -0400 5/31/02, Jeremy Erwin wrote:
>>
>> Is there a way to get fink to properly expand $(CC) ? i.e
>> SetCPP: $(CC) -E -traditional-cpp
>> does not seem to work; it's flagged as "not sane" by configure-- the
>> shell variable
23 matches
Mail list logo
