This is a quick note to help people build, install and test apache2 and
php. This should also help others that are building DSO modules for
Apache2.
1) Build apache2
fink install apache2
2) Fix the build environment. The apache project is working to fix
these problems, if they have not alre
Um 22:18 Uhr -0600 am 11.1.2003, Chris Snell schrieb:
Has anybody worked on a gpsdrive package? If not, I'm interested in
making my port work under Fink.
It doesn't look like. I couldn't find any refernces in either the
mailing lists or the trackers. It would be great if you could make a
pack
At 20:14 Uhr -0500 11.01.2003, Bill Bumgarner wrote:
On Wednesday, Jan 8, 2003, at 14:33 US/Eastern,
[EMAIL PROTECTED] wrote:
We don't generally accept bundled .apps in fink, because they can be
moved by the user, and also to keep fink focused.
I know this has gone around before... but, to flog
On Sat, 11 Jan 2003, Benjamin Reed wrote:
> > 2) Apps can't be moved any more readily than, say, /sw/bin/python or
> > /sw/share/doc/apache. Same goes for frameworks.
>
> What do you mean?
>
> You can pick up any application in /Applications and stick it somewhere
> else and it works just as
On Sunday, January 12, 2003, at 09:53 AM, Bill Bumgarner wrote:
Read the post. I didn't say that Apps installed by Fink should be in
/Applications. They should be in /sw/Applications, to further follow
the Fink
guidelines. They work fine there.
Right, they work fine everywhere. What would
On Sunday, January 12, 2003, at 04:49 AM, Max Horn wrote:
At 20:14 Uhr -0500 11.01.2003, Bill Bumgarner wrote:
3) More and more Unix related tools have native Aqua ports available.
tk and wx immediately come to mind. Film-gimp on the applications
front. With PyObjC, CamelBones, and othe
On Sunday, January 12, 2003, at 07:38 AM, Ben Hines wrote:
Ok, i just had another idea... to fully support movable .apps in
/sw/Applications, we could create a carbon ALIAS file in /Applications
to our installed .app. The user could move that app alias wherever
they wanted. RangerRick think
Using aliases is not Mac-like. Giving users the illusion of moving
their apps isn't good enough. Besides, at this point, anyone using Fink
isn't going to be stopped by having the item in a hidden directory.
(Right-click > Show Original ends that search).
.apps just don't seem to go with what Fi
On Sunday, Jan 12, 2003, at 07:49 US/Eastern, Max Horn wrote:
At 20:14 Uhr -0500 11.01.2003, Bill Bumgarner wrote:
On Wednesday, Jan 8, 2003, at 14:33 US/Eastern,
[EMAIL PROTECTED] wrote:
We don't generally accept bundled .apps in fink, because they can be
moved by the user, and also to keep fin
On Sunday, Jan 12, 2003, at 10:12 US/Eastern, Benjamin Reed wrote:
On Sunday, January 12, 2003, at 09:53 AM, Bill Bumgarner wrote:
Read the post. I didn't say that Apps installed by Fink should be in
/Applications. They should be in /sw/Applications, to further
follow the Fink
guidelines. T
On Sunday, January 12, 2003, at 08:03 AM, Jared wrote:
Using aliases is not Mac-like. Giving users the illusion of moving
their apps isn't good enough. Besides, at this point, anyone using
Fink isn't going to be stopped by having the item in a hidden
directory. (Right-click > Show Original e
On Sunday, Jan 12, 2003, at 10:38 US/Eastern, Ben Hines wrote:
*IF* the user desires the flexibility to move these apps around, they
can install them without fink.
Or they can create a copy in their account or /Applications and do what
they want. But it'll be a copy no longer under Fink's contr
On Sunday, January 12, 2003, at 10:20 AM, Bill Bumgarner wrote:
He replied based on false assumptions and, unfortunately, I lost his
message.
Bottom line: If any application is installed in a proper, network
computing style, fashion, then no user should be able to move it or
rename it without
On Sunday, Jan 12, 2003, at 11:22 US/Eastern, Ben Hines wrote:
On Sunday, January 12, 2003, at 08:03 AM, Jared wrote:
Using aliases is not Mac-like. Giving users the illusion of moving
their apps isn't good enough. Besides, at this point, anyone using
Fink isn't going to be stopped by having t
On Sunday, January 12, 2003, at 11:21 AM, Bill Bumgarner wrote:
Right, they work fine everywhere. What would stop a user from moving
it out of /sw/Applications? In fact, I would expect users to go "I
want all of my apps in one place", and move them into /Applications,
first thing they do...
On Sunday, January 12, 2003, at 08:29 AM, Bill Bumgarner wrote:
On Sunday, Jan 12, 2003, at 11:22 US/Eastern, Ben Hines wrote:
On Sunday, January 12, 2003, at 08:03 AM, Jared wrote:
Using aliases is not Mac-like. Giving users the illusion of moving
their apps isn't good enough. Besides, at
On Sunday, January 12, 2003, at 10:29 AM, Bill Bumgarner wrote:
On Sunday, Jan 12, 2003, at 11:22 US/Eastern, Ben Hines wrote:
On Sunday, January 12, 2003, at 08:03 AM, Jared wrote:
Using aliases is not Mac-like. Giving users the illusion of moving
their apps isn't good enough. Besides, at
Sorry to join this discussion late...
On Friday, January 10, 2003, at 09:49 PM, Benjamin Reed wrote:
So the subject of perl 5.8 came up again on #fink, and I started
taking a look at what we had. Chris Dolan put together a great
package for perl 5.8, but it has one problem -- it still puts
Jared wrote:
On Sunday, January 12, 2003, at 10:29 AM, Bill Bumgarner wrote:
[]
Why is everyone hung up on MOVING the stupid apps Fink does *not*
need to support moving of the apps. If the user wants to 'move' the
apps, they can create copies or links. Done deal.
I agree fully with Bi
I don't think this has been discussed here before, so...
I wrote a fink package for "scsh", a Scheme Unix shell, which is now
in stable. I used this package myself to install scsh, and I had
reports from other people that it works fine. Then one day, a friend
of mine who needed "scsh", installed F
On Sunday, January 12, 2003, at 11:48 AM, Chris Dolan wrote:
No, that's not right at all. As I discussed with rangerrick on the
submission tracker, Perl already HAS a standard for dealing with
binary incompatible modules. Apple stupidly overrode that mechanism
and we've been dealing with it
On Sunday, January 12, 2003, at 09:06 AM, Michel Schinz wrote:
Now I'm preparing a new package for "scsh" for which I added
"dlcompat" in the dependencies. But this does not solve the problem in
general. The only way to solve it that I can think of, is that when
you build a package for the bina
(Sorry for the long post, but IMHO this is serious)
After fighting with some crashes becasue of undefined symbols and with
xemacs compiling problems under Apple's new X11, I have come to a rather
pessimistic conclusion about compatibility between different versions
of X11. This concerns not on
On Sunday, January 12, 2003, at 04:39 PM,
[EMAIL PROTECTED] wrote:
darwinports allows ports to create .apps, and trusts the user not to
move them. I'm starting to agree. We even have 2 apps in fink that
ALREADY use this principle, XDarwin and aquaterm. Aquaterm isn't even
open source!
Since wh
On Sunday, January 12, 2003, at 09:54 AM, Per Persson wrote:
On Sunday, January 12, 2003, at 04:39 PM,
[EMAIL PROTECTED] wrote:
darwinports allows ports to create .apps, and trusts the user not to
move them. I'm starting to agree. We even have 2 apps in fink that
ALREADY use this principle,
Ben Hines <[EMAIL PROTECTED]> writes:
[...]
> Well, the real problem is your fault, you missed a dependency when
> making the package, and we missed it when verifying. :)
Well, I do not view it that way, of course :-).
Scsh does *not* depend on dlcompat, it works perfectly well without
it. Howe
On Sunday, January 12, 2003, at 10:02 AM, Michel Schinz wrote:
Scsh does *not* depend on dlcompat, it works perfectly well without
it. However, if dlcompat is installed, and if it can be found by
configure when scsh is built, then it's used.
It does "depend" on dlcompat, because of our poli
The problem in this discussion is that there are very different basic
assumptions made by the various parties. I don't believe that we can
get to an agreement, ever. Bill and Ben consider some things for
important which I don't consider important at all, and vice versa. I
don't actually believe
No problem, will do that starting with next release. Nobody ever
pointed out that as a problem to me.
(I'm not a heavy fink-user, but I do scan the mailinglists for
questions related to project that I am, some way or another, involved
in: AQT, gnuplot, pgplot, plplot, octave and octave-forge)
On Sunday, January 12, 2003, at 10:17 AM, Ben Hines wrote:
On Sunday, January 12, 2003, at 10:02 AM, Michel Schinz wrote:
Scsh does *not* depend on dlcompat, it works perfectly well without
it. However, if dlcompat is installed, and if it can be found by
configure when scsh is built, then i
The bug is on your side, Michel. Two possible fixes, either add
dlcompat to the dependency list, or patch scsh such that it never
uses dlopen (i.e. patch the configure script).
Max
--
---
Max Horn
Software Developer
-
At 19:02 Uhr +0100 12.01.2003, Michel Schinz wrote:
Ben Hines <[EMAIL PROTECTED]> writes:
[...]
Well, the real problem is your fault, you missed a dependency when
making the package, and we missed it when verifying. :)
Well, I do not view it that way, of course :-).
Scsh does *not* depend
A couple of comments on this thread:
1) Fred Sanchez wrote a revised darwin.sh for perl in the fall, which was
accepted into the perl tree. I believe that it essentially implements
what Chris did. We should follow it. (Links to the document were in my
previous post.)
2) By convention, the use
Just to clarify the situation a bit more:
If the software you are packaging makes use of the Fink package foo
whenever foo is present, and if you have no way to disable it from making
use of foo, then you must list foo as a dependency.
This is the only way we have of guaranteeing that every Fink
Martin,
My understanding is that the following upgrade path:
XFree86-4.2 or Fink-4.2/ threaded-version / XFree86-4.3 or Fink-4.3
is expected to work just fine.
However, as has become apparent this week, the libraries shipped by Apple
are not binary compatible with other versions of the libr
Ben Hines <[EMAIL PROTECTED]> writes:
[...]
> And additionally, this isnt just an arbitrary goal, your package will
> break for source users too:
>
> 1. User installs dlcompat.
> 2. User installs (from source) your package, which finds and uses
> dlcompat
> 3. User removes dlcompat (this works be
I am creating rev. 2 of your package with the dependency on dlcompat.
-- Dave
---
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
__
On Sunday, January 12, 2003, at 10:59 AM, Michel Schinz wrote:
think I should correct and re-submit the current package, I will do
so. Or maybe someone with CVS access can add the dependency on
dlcompat for me and increment the revision.
I'll add it for you.
-Ben
-
"David R. Morrison" <[EMAIL PROTECTED]> writes:
> Just to clarify the situation a bit more:
>
> If the software you are packaging makes use of the Fink package foo
> whenever foo is present, and if you have no way to disable it from making
> use of foo, then you must list foo as a dependency.
Yes
Dave :
> We can probably include a short list of Fink binaries
> which are known not to work with Apple's libraries.
FWIW, I just installed nessus this afrenoon, with its dependancies
(mainly openssl, libxml2, gtk) It compiles and runs without any problem.
--
Xavier
http://www.freetibet.org
htt
At 1:59 PM -0500 1/12/03, David R. Morrison wrote:
Martin,
My understanding is that the following upgrade path:
XFree86-4.2 or Fink-4.2/ threaded-version / XFree86-4.3 or Fink-4.3
is expected to work just fine.
Yes. This kind of problem is why I got bent out of shape awhile ago
about Fink
At 20:14 Uhr +0100 12.01.2003, Michel Schinz wrote:
"David R. Morrison" <[EMAIL PROTECTED]> writes:
Just to clarify the situation a bit more:
If the software you are packaging makes use of the Fink package foo
whenever foo is present, and if you have no way to disable it from making
use of
David R. Morrison wrote:
Martin,
My understanding is that the following upgrade path:
XFree86-4.2 or Fink-4.2/ threaded-version / XFree86-4.3 or Fink-4.3
is expected to work just fine.
The upgrade from non-threaded 4.2 to threaded 4.3 is not completely
innocent. I am sure I have seen a fi
> "Max" == Max Horn <[EMAIL PROTECTED]> writes:
Max> The bug is on your side, Michel. Two possible fixes, either add
Max> dlcompat to the dependency list, or patch scsh such that it never uses
Max> dlopen (i.e. patch the configure script).
Or have two packages, like "emacs" vs "emacs-nox".
-
At the moment, there are very few .apps in Fink. I am not strongly
opinionated on either side of the issue of adding new applications to
Fink, but I have an idea for the existing, necessary, ones. In my
opinion, the .apps (Such as XDarwin and AquaTerm) that are already in
Fink should be put i
On Sunday, January 12, 2003, at 12:49 PM, David R. Morrison wrote:
A couple of comments on this thread:
1) Fred Sanchez wrote a revised darwin.sh for perl in the fall, which
was
accepted into the perl tree. I believe that it essentially implements
what Chris did. We should follow it. (Links
> "David" == David R Morrison <[EMAIL PROTECTED]> writes:
David> A couple of comments on this thread:
David> 1) Fred Sanchez wrote a revised darwin.sh for perl in the fall, which was
David> accepted into the perl tree. I believe that it essentially implements
David> what Chris did. We should
On 03/1/12 11:43 AM, "[EMAIL PROTECTED]"
<[EMAIL PROTECTED]> wrote:
> Message: 8
> Date: Sun, 12 Jan 2003 11:29:54 -0500
> Subject: Re: [Fink-devel] .apps in fink
> Cc: Jared <[EMAIL PROTECTED]>, Max Horn <[EMAIL PROTECTED]>,
> [EMAIL PROTECTED]
> To: Ben Hines <[EMAIL PROTECTED]>
> From: Bill Bu
On Sun, 12 Jan 2003, rand wrote:
> Actually moving the apps is a very valid argument. I don¹t do it all
> that much but the first thing two of my friends did when they got their
> new macs with osx was to completely screw the os:) renaming folders
> such as [Applications] [thisfolder] etc and mo
On 03/1/12 7:50 PM, "Hisashi T Fujinaka" <[EMAIL PROTECTED]> wrote:
> On Sun, 12 Jan 2003, rand wrote:
>
>> Actually moving the apps is a very valid argument. I don¹t do it all
>> that much but the first thing two of my friends did when they got their
>> new macs with osx was to completely screw
max, ben, bill and all,
let me add my thoughts as well. what is actually the gain of having
.apps in fink? for you it is none as you pointed out. the main reason
why i'd like, and i might here speak for others as well, to have .apps
in fink is the following:
software updates might bring great
On Sunday, Jan 12, 2003, at 11:42 US/Eastern, Jared wrote:
Frankly, because if you want a GUI solution, you should conform to the
way the GUI works. Creating something which is only "sorta like other
Mac apps" isn't good enough. You shouldn't expect others to work
around your decisions. Your de
On Sunday, January 12, 2003, at 05:01 PM, mathias meyer wrote:
situation: you have an app (hidden directory) and a visible symlink to
that.
We were discussing carbon aliases. Aliases are completely different
semantics than symlinks. Do not confuse the two or use the words
interchangably.
On Sun, 12 Jan 2003, rand wrote:
> Right/wrong? Not the point, the point is that a lot of users will
> attempt to move them, we need to realise this and build fink accordingly
> if it goes this route.
They'll learn soon enough that you can't do certain things. OSX is not
OS9. Just because you (t
I wanted to contact "Chris Zubrzycki <[EMAIL PROTECTED]>"
but the mail came back - so i post here:
Hello!
I have found that your package puts the man-pages in the wrong place:
i have found it in mplayer-0.90rc1-1.info.
drwxr-xr-x root/admin0 2003-01-13 01:08:17 ./
drwxr-xr-x root/admin
Hi All,
Aside from these directory name issues I have a start on some perl 5.8
info files based on a perl 5.8 info file from the submission tracker.
The modules I found so far which need to be recompiled simply have a
new info file identical to the old one but with a build/depends on the
new
On Sunday, January 12, 2003, at 04:02 PM, Randal L. Schwartz wrote:
David> 2) By convention, the user-modifiable portion of the Fink tree
David> is /sw/etc. So I think we should create /sw/etc/perl/5.6.0 and
David> /sw/etc/perl/5.8.0 and symlink them back into the /sw/lib/perl
David> trees that
First, This is a STUPID discussion. That said, I'm going to add my $0.02.
A normal user can write to /Applications b/c a normal mac user is the
*only* user on the machine and is therefore (by default) the
administrator as defined by apple's admin group. People here are
arguing about what *shou
On Sunday, January 12, 2003, at 05:50 PM, John Davidorff Pell wrote:
...
P.S. I have so many permissions problems in OSX that I've made cron jobs
to fix it all every night (over-kill, but it works) so making
/sw/Applications writable only by root probably won't work. hell, /
isn't even only
Let me jump back in one more time regarding multiple versions of perl module
packages.
There is a nifty system for emacs versions in Debian, which has been mostly
implemented in Fink (except that not every package follows it), in which
various files are registered as emacs source files and then if
A humble opinion from a list observer again
On Sunday, January 12, 2003, at 05:18 PM, Hisashi T Fujinaka wrote:
On Sun, 12 Jan 2003, rand wrote:
Right/wrong? Not the point, the point is that a lot of users will
attempt to move them, we need to realise this and build fink
accordingly
if it go
So, I'm pretty confident that my source package works properly and
conforms to fink standards. What steps do I need to take to get my
package into stable (or unstable for that matter, right now I'm the
only one who has it)? What I've done so far is getting my .info and
.patch files onto the pac
On Sun, 12 Jan 2003, Kow K wrote:
> As far as I can see, the reason that more and more people are attracted
> to Fink is *not* because it provides a purer Unix environment, but
> because it provides cool stuff like GIMP, well known as the Photoshop
> Killer for free. This is my personal observatio
Hi Jared. Thanks for your interest in making Fink packages; we definitely
need more people who want to do that!
The procedure is, once your submission to the package submission tracker
meets Fink's standards, one of the Fink developers will add it to the
unstable tree. (Sometimes this takes a wh
* Bill Bumgarner <[EMAIL PROTECTED]> [12 Jan 2003 08:21]:
> On Sunday, Jan 12, 2003, at 07:49 US/Eastern, Max Horn wrote:
> >At 20:14 Uhr -0500 11.01.2003, Bill Bumgarner wrote:
> >Benjamin already replied to this, so I won't do it again.
>
> He replied based on false assumptions and, unfortunatel
On Sunday, January 12, 2003, at 05:39 PM, rand wrote:
Ultimately, you have to factor in one thing, what is the goal of the
fink
project? Is it to manage everything that is ported in one way or
another
from any unix platform? Or is it to manage a certain type of porting
structure? If you thi
On Sunday, Jan 12, 2003, at 20:34 US/Eastern, Carsten Klapp wrote:
Hi All,
Aside from these directory name issues I have a start on some perl 5.8
info files based on a perl 5.8 info file from the submission tracker.
The modules I found so far which need to be recompiled simply have a
new inf
67 matches
Mail list logo
