Re: [Fink-devel] gnuplot history -- doesn't detect readline

2004-01-26 Thread Martin Costabel
Joe Corneli wrote:

gnuplot history
 warning: history command requires some form of readline support
fink list readline
Information about 2434 packages read in 2 seconds.
 i   readline   4.3-25   Comfortable terminal input library
 i   readline-shlibs4.3-25   Comfortable terminal input library
 term-readline-pm   1.0203-10Placeholder for versioned 
Term::ReadLine::Perl packages
 term-readline-pm5811.0203-10Minimal interface to Readline
I have readline, and I just rebuilt gnuplot.  Seems like readline
must not be being linked in properly.
It is, but looking at the sources of gnuplot-3.8j.0, I get the 
impression that they have their head screwed on backwards. They put the 
whole history command processing between

 #if defined(READLINE)  !defined(HAVE_LIBREADLINE)
 #endif
which is the exact opposite of what they want. If I replace this by
 #if 1
I get a gnuplot executable that executes its history command correctly.
--
Martin


---
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
___
Fink-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/fink-devel


[Fink-devel] apr 0.9.5 and apache 2.0.48 and bdb4.2 (another try)

2004-01-26 Thread Christian Schaffner
Hi Dustin, hi TheSin

I am sorry to bother you again on this topic. I heard that you, Dustin, 
are working on upgrading apache2 and php to work with bdb4.2. Still, i 
haven't seen as sign on that yet since December.

Subversion yesterday released a new version, 0.37, which is probably 
the last beta before 1.0. I need to release this version as soon as 
possible to let people test it. Like this we can move svn 1.0 to stable 
soon after it is released.

Now, as you know, svn now depends on bdb4.2 and therefore i need apr 
and apache2 to be upgraded with bdb4.2. Could you please tell me, what 
is holding up the release of newer revisions of these packages?

I tested apache2 and apr with db4.2 and they seem to work fine. What 
else needs to be done? Can i help you test?

Do you have anything against it if i release a new revision of apache2 
and apr?

I really want to release this week! So, could we make that happen?

Thanks,
Chris.
PS:
The updated files are in my experimental directory in cvs fink:
/sw/fink/experimental/chris01/finkinfo/



---
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
___
Fink-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/fink-devel


Re: [Fink-devel] Packaging issue - ruby extensions

2004-01-26 Thread Michal 'hramrach' Suchanek
On Fri, Jan 23, 2004 at 07:39:14PM -0500, Daniel Macks wrote:
 On Wed, Jan 21, 2004 at 09:10:24AM +0100, Michal 'hramrach' Suchanek wrote:
  On Tue, Jan 20, 2004 at 04:39:27AM -0500, Daniel Macks wrote:
   On Tue, Jan 20, 2004 at 10:22:04AM +0100, Michal 'hramrach' Suchanek wrote:
On Mon, Jan 19, 2004 at 10:28:33PM -0500, Daniel Macks wrote:
 On Mon, Jan 19, 2004 at 01:35:31PM +0100, Michal Suchanek wrote:
 
  So I made ripper-ruby16 0.0.5-2 that has a splitoff ripper
  0.0.5-2-16, ripper-ruby18 with splitoff ripper 0.0.5-2-18, etc.
 
 What exactly is the purpose of these splitoffs and what do they
 contain? [...]
 are you trying to arrange so that other fink packages can use yours
 by simply Depends: ripper and be assured of a fully functional
 module *somewhere*?
Yes, that's what I intended to do.
   
   Okay then, I have to ask: why?
  It was the first soulotion that came to my mind and I like it.
 
 Valid, so long as it works.
 
 Given that they won't know where, though, what's the point? I'm
 thinking back to your example of an invalid configuration:
 
ruby16 + ruby18 + ruby 1.8.0 + ripper-ruby16 + fxruby-ruby18 + freeride
 
 that could result from freeride saying 'Depends: ripper, fxruby'.
 
 Experience has shown that when we have foo-pmXX provides:foo-pm (or a
 foo-pm bundle depends:foo-pmXX|foo-pmYY) other package maintainers are
 likely to Depends:foo-pm without considering that it's the same as
 your broken example.
That is why I made the splitoffs, not Provides:ripper
 
 Based on the freeride example you give, you're in the same
 versioned-perl-module handbasket. If it's the freeride package (which
 is not ruby-versioned) that needs a certain suite of modules all in
 the same ruby-version, it's up to that package to request them. Why
 can't it just pick a ruby and use it?

As you put it it should be possible to make
freeride + freeride-ruby18 + freeride-ruby16 where freeride-rubyXX contains a
script for running freeride with the correct interpreter.
 
 If that's the case for this example:
 
  I had another thing in mind:
  
  Package: freeride
  Depends: freeride-ruby-runtime
  (contains the freeride sources)
  
  Package: freeride-ruby16
  Depends: ruby16, ripper-ruby16, fxruby-ruby16
  Provides: freeride-ruby-runtime
  (contains a startup script)
 
 Which I would assume looks like:
   freeride: %p/bin/freeride-bin (some script)
   freeride-ruby16: %p/bin/freeride ('%p/bin/ruby1.6 %p/bin/freeride-bin')
 
 So you'd need freeride-ruby16 Depends:freeride-ruby16, which causes a
 dependency loop. I have no idea whether freeride-ruby16 also has
 things that other programs might want (i.e., would someone ever want
 to install freeride-ruby16 and -ruby18 at the same time?), but if so
 then there are file conflicts.
Installing freeride-ruby-16 and freeride-ruby18 at the same time is not useful.
But freeride-ruby16 and freeride-ruby18 could install different files and
an alternative.
To avoid the cyclic dependency one more package could be created.
Like freeride-bin (the freeride stuff), freeride-rubyXX that contain startup
scripts and provide freeride.

Thanks

-- 
Michal Suchanek
[EMAIL PROTECTED]


---
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
___
Fink-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/fink-devel


Re: .app's in Fink (was Re: [Fink-devel] CFD: Installing Frameworks from fink packages)

2004-01-26 Thread Martin Costabel
David R. Morrison wrote:
[]
My proposal is that we place .app's in /sw/Applications, and then in a
postinstall script, set up a symlink from /Applications to the actual .app.
It would be better to make an Alias instead of a symlink. And put it on 
the Desktop instead of /Applications. This would be less intrusive. 
During package installation, people are used to things appearing on the 
desktop.

--
Martin


---
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
___
Fink-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/fink-devel


[Fink-devel] Re: .app's in Fink

2004-01-26 Thread Chris Zubrzycki
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Jan 26, 2004, at 1:42 AM, D. Höhn wrote:
|I think we will have to restart the old discussion of 
/sw/Applications,
|too. And I mean a real discussion, not the hasty erection of 
religious
|taboos as we had in the past. I would really love to see things like
|Tcl/Tk-aqua and rangerrick's KDE/Qt-mac stuff in Fink.

I do not quite understand why. Please do not misunderstand me, I am not
completely opposed, I just do not get why. We are good at something,
which is packaging Unix based applications. There are enough
applications out there which have not been packaged yet and we are
having trouble already keeping up. I just fear that introducing .app
into the whole system complicates matters to the worse.
Well, there are many nice wrappers for opensource programs that could 
be a welcome addition to fink, also some projects have os x code in 
them itself. What is the difference in an opensource Cocoa app or an 
x11 one? just a different windowserver. Also it would be possible for 
the apps to use fink's libs, and not have to duplicate everything in 
each app bundle, which is the point of shared libs in the first place. 
I'd love to see more stuff, but I do feel we should be pretty selective 
about it, at least at first. As for duplicating everyting that kde apps 
need to run, well, i'd much rather not :)

- -chris zubrzycki
- - --
PGP public key: http://homepage.mac.com/beren/publickey.txt
ID: 0xA2ABC070
Fingerprint: 26B0 BA6B A409 FA83 42B3  1688 FBF9 8232 A2AB C070
_
This message is encoded using the Rot-26 encoding method.  Unauthorized 
decoding of this message may result in extreme penalties under the 
DMCA.  These penalties include, but are not limited to: US$100,000 
fine, life imprisonment, castration, death, limp hair, terminal 
halitosis, and amputation of the extremities.

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.3 (Darwin)
iD8DBQFAFZaZ+/mCMqKrwHARAlQJAKCCcyN6g3RTxDOZXykFHuCMfq41EgCeMsqZ
SYRSC4+DcjcMmlHmx1G4DxI=
=K1wC
-END PGP SIGNATURE-


---
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
___
Fink-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/fink-devel


[Fink-devel] Re: .app's in Fink

2004-01-26 Thread Chris Zubrzycki
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Jan 26, 2004, at 5:32 PM, Martin Costabel wrote:

David R. Morrison wrote:

My proposal is that we place .app's in /sw/Applications, and then in a
postinstall script, set up a symlink from /Applications to the actual  
.app.
It would be better to make an Alias instead of a symlink. And put it  
on the Desktop instead of /Applications. This would be less intrusive.  
During package installation, people are used to things appearing on  
the desktop.
Well, whose desktop do you put it on? I vote for /Applications, most  
apps people install end up there. Also, in this case, since the  
original will not be moving, i think an alias is fine; it's also much  
easier to create via the command line.  ;-)

 
==
A cat spends her life conflicted between a deep, passionate and  
profound
desire for fish and an equally deep, passionate and profound desire to
avoid getting wet.  This is the defining metaphor of my life right now.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.3 (Darwin)

iD8DBQFAFZdm+/mCMqKrwHARAjVAAJsFPvfLbioCNDHGLw+wm3CAK0sC1wCg0JjL
CxfXwIKuZk/4s+dJBPoJObk=
=Olh+
-END PGP SIGNATURE-


---
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
___
Fink-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/fink-devel


Re: .app's in Fink (was Re: [Fink-devel] CFD: Installing Frameworks from fink packages)

2004-01-26 Thread Benjamin Reed
Martin Costabel wrote:

It would be better to make an Alias instead of a symlink. And put it on 
the Desktop instead of /Applications. This would be less intrusive. 
During package installation, people are used to things appearing on the 
desktop.
I can imagine installing KDE and having 150 apps on my desktop.  =)

I think we're better off making an alias in /Applications/Fink or something.

---
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
___
Fink-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/fink-devel


Re: .app's in Fink (was Re: [Fink-devel] CFD: Installing Frameworks from fink packages)

2004-01-26 Thread Martin Costabel
D. Höhn wrote:
[]
I do not quite understand why. Please do not misunderstand me, I am not
completely opposed, I just do not get why. We are good at something,
which is packaging Unix based applications. There are enough
This is a false opposition. There are more and more Unix based 
applications (whatever that means on an operating system that is itself 
based on Unix) that try to use OSX's native graphics and are then in a 
natural way packed as app bundles. I don't see why qt-x11 should be 
considered more Unix based than qt-mac, for example.

applications out there which have not been packaged yet and we are
having trouble already keeping up. I just fear that introducing .app
into the whole system complicates matters to the worse.
It would be interesting to have statistics about the main activities of 
Fink developers these last months. I bet that only a rather small part 
of their time went into actually packaging new packages. People are not 
creating Fink packages because there are so many applications out 
there, but because they either want some package for their own purposes 
or because it is fun to spend time with a particular piece of software. 
In both categories there will be more and more app bundles.

There is a saying in german Schuster bleib bei deinen Leisten which
means as much as Stick to what you are good at. I would suggest, that
we leave the .app handling to others and concentrate on improving fink
To others like Ben Reed or what? Nobody is forced to make app bundles 
out of their fink packages. But there are app bundles that would greatly 
enrich fink if they were available as fink packages.

itself as well as its packages. I really do not mind downloading
KDE/QTMac from somewhere else. Rather than having calssic KDE/QT plus
KDE/QTMac in Fink.
But I do mind. Why should I start reading web pages with long lists of 
instructions on what to download from where and to install first in /opt 
and /usr/local and then download something else and start compiling with 
autoconf and glibtoolize and whatever and then install in /Applications 
when I could just say fink install koffice-aqua and let fink do its 
magic? Not to mention subsequent update-all or remove commands that 
you don't get from somewhere else.

--
Martin




---
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
___
Fink-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/fink-devel


Re: .app's in Fink (was Re: [Fink-devel] CFD: Installing Frameworks from fink packages)

2004-01-26 Thread Keith Conger
This sounds like a nice solution.

Keith
On Jan 26, 2004, at 5:52 PM, Benjamin Reed wrote:
Martin Costabel wrote:

It would be better to make an Alias instead of a symlink. And put it 
on the Desktop instead of /Applications. This would be less 
intrusive. During package installation, people are used to things 
appearing on the desktop.
I can imagine installing KDE and having 150 apps on my desktop.  =)

I think we're better off making an alias in /Applications/Fink or 
something.

---
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
___
Fink-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/fink-devel


---
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
___
Fink-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/fink-devel


Re: .app's in Fink (was Re: [Fink-devel] CFD: Installing Frameworks from fink packages)

2004-01-26 Thread Martin Costabel
Ben Hines wrote:

Fine by me, as long as we stick to open source applications ONLY.  The 
No one ever suggested anything else.

objection about 'moving apps around' never did make sense to me, i think 
a more important objection is fink losing focus.

I believe we have one or two command line apps in fink which are binary.
One of them is aquaterm that installs an app into /sw/Applications. I 
never liked the fact that this is a binary installation, even when you 
do fink install. But I think the main reason for this is precisely 
that the building of apps with Fink packages was frowned upon. A binary 
installation was considered the lesser evil, which I always found 
perverse. BTW, I don't think anyone ever reported problems with 
AquaTerm.app living in /sw/Applications. Nobody complained about the 
restriction of their freedom to move apps around at will.

--
Martin


---
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
___
Fink-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/fink-devel


Re: .app's in Fink (was Re: [Fink-devel] CFD: Installing Frameworks from fink packages)

2004-01-26 Thread Chris Zubrzycki
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Jan 26, 2004, at 5:52 PM, Benjamin Reed wrote:

Martin Costabel wrote:

It would be better to make an Alias instead of a symlink. And put it 
on the Desktop instead of /Applications. This would be less 
intrusive. During package installation, people are used to things 
appearing on the desktop.
I can imagine installing KDE and having 150 apps on my desktop.  =)

I think we're better off making an alias in /Applications/Fink or 
something.
What about refining the current structure we have for our info files? 
We can use /Applications/Fink/foo/app, and when we remove the package, 
we can check everywhere under /Applications/Fink for the link to the 
app to remove it. This also brings up another point, what about having 
subcategories in our structure? kde/net kde/devel, graphics/multimedia 
etc? We could again borrow from debian the subcategories we like :)

Everyone who comes in here wants three things:
(1) They want it quick.
(2) They want it good.
(3) They want it cheap.
I tell 'em to pick two and call me back.
-- sign on the back wall of a small printing company
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.3 (Darwin)
iD8DBQFAFZ2d+/mCMqKrwHARAnRGAKCqB1XZUBC1s1HPN69jhgEhpwt1NQCfdk9Q
8+PXtyj3BsubBEIJYOvhdO4=
=MSf2
-END PGP SIGNATURE-


---
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
___
Fink-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/fink-devel


Re: .app's in Fink (was Re: [Fink-devel] CFD: Installing Frameworks from fink packages)

2004-01-26 Thread Darian Lanx
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
Martin Costabel wrote:

D. Höhn wrote:
[]
I do not quite understand why. Please do not misunderstand me, I am not
completely opposed, I just do not get why. We are good at something,
which is packaging Unix based applications. There are enough


This is a false opposition. There are more and more Unix based 
applications (whatever that means on an operating system that is itself 
based on Unix) that try to use OSX's native graphics and are then in a 
natural way packed as app bundles. I don't see why qt-x11 should be 
considered more Unix based than qt-mac, for example.

I guess that is a matter of definition. I think that those applications 
which utilise native Cocoa Objects, display directly under Aqua and so 
on have been considered native, yet I am no expert on this field and I 
will gladly agree that my own definition is made out of a personal , 
construed feeling. There are no hard facts I have based this opinion on.
snip
It would be interesting to have statistics about the main activities of 
Fink developers these last months. I bet that only a rather small part 
of their time went into actually packaging new packages. People are not 
creating Fink packages because there are so many applications out 
there, but because they either want some package for their own purposes 
or because it is fun to spend time with a particular piece of software. 
In both categories there will be more and more app bundles.

Says who? There are enough applications which do not need to be ported 
to a native app bundle, where some built in framework is used or the 
actual screen rendering is then done on the Aqua Desktop. There will be 
tons of new applications released initially meant for other UNIX based 
systems which happen to run fine on Mac os X as well. Therefore I do not 
quite follow your prediction of a shift toward app bundles.

There is a saying in german Schuster bleib bei deinen Leisten which
means as much as Stick to what you are good at. I would suggest, that
we leave the .app handling to others and concentrate on improving fink


To others like Ben Reed or what? Nobody is forced to make app bundles 
out of their fink packages. But there are app bundles that would greatly 
enrich fink if they were available as fink packages.

Why? Why would that enrich Fink? In what way? What are my exact 
benefits? That is the tenor of my original message and I fail to see it 
answered here. I honestly am not seing it, that is why I am requesting a 
second point of view.

itself as well as its packages. I really do not mind downloading
KDE/QTMac from somewhere else. Rather than having calssic KDE/QT plus
KDE/QTMac in Fink.


But I do mind. 
Why should I start reading web pages with long lists of 
instructions on what to download from where and to install first in /opt 
and /usr/local and then download something else and start compiling with 
autoconf and glibtoolize and whatever and then install in /Applications 
Would it not be the main purpose of an app to be bundled with a neat 
Installer? Or am I missing the point here?

when I could just say fink install koffice-aqua and let fink do its 
magic? Not to mention subsequent update-all or remove commands that 
you don't get from somewhere else.
What happens to the maitainer precedence then? Will the native app 
always be preffered? Why would anyone want to use KDE/X11 when they can 
have native KDE? Those are all questions I would like to see addressed 
prior to allowing any kind of app bundle into Fink's structure.

Again, personal opinion.

- -d


-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.3 (Darwin)
iD8DBQFAFaGxPMoaMn4kKR4RA5yaAJ9GZF1N0CHz7Ura/fduJYJ6QLL01QCeNxFO
/PliYPDdWNKIiHHx5BpreRE=
=IcCS
-END PGP SIGNATURE-
---
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
___
Fink-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/fink-devel


Re: [Fink-devel] Questions about .info file

2004-01-26 Thread James Gibbs
On Jan 25, 2004, at 8:44 PM, James Gibbs wrote:

On Jan 25, 2004, at 10:33 AM, Pierre Mazoyer wrote:

## Dependencies
Depends: tcltk (= 8.0), tcltk-dev (= 8.0), tcltk-shlibs (= 8.0)

Forgot to mention that versioned deps have to have a revision, like:

Depends: tcltk (= 8.0.0-1), etc.

James



---
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
___
Fink-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/fink-devel


Re: .app's in Fink (was Re: [Fink-devel] CFD: Installing Frameworks from fink packages)

2004-01-26 Thread David R. Morrison
In my view, the main reason for doing this is that there already exists
software out there which on the one hand depends on UNIX libraries which
are (or should be) part of Fink, but on the other hand is packaged in
OS X form, as an .app bundle which uses a Cocoa interface.

Either all of the Unix libs have to be stuck inside the bundle, requiring
much duplication, or this .app bundle needs to have a way to link to
(and be sure of the existence of) some underlying UNIX libs.  I think
that allowing that second possibility would be very worthwhile, and
would be a good way to use the Fink infrastructure which already exists.

  -- Dave


---
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
___
Fink-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/fink-devel


[Fink-devel] gnome on macos x

2004-01-26 Thread Niccolò Battezzati
Hello,

I have MacOS X 10.2.8 running on my iMac. I've installed Fink (last 
release) and I'm trying to use Gnome as window manager for unix 
applications. I installed the bundle-gnome package but I can't run it. 
If I call the startx command (with -fullscreen or -rootless) it runs 
XFree86.
Can you help me? What can I do to run Gnome?

Thank you very much!

Niccolò



---
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
___
Fink-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/fink-devel


Re: .app's in Fink (was Re: [Fink-devel] CFD: Installing Frameworks from fink packages)

2004-01-26 Thread Peter O'Gorman
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Chris Zubrzycki wrote:

|
| On Jan 26, 2004, at 5:52 PM, Benjamin Reed wrote:
|
| Martin Costabel wrote:
|
| It would be better to make an Alias instead of a symlink. And put it
| on the Desktop instead of /Applications. This would be less
| intrusive. During package installation, people are used to things
| appearing on the desktop.
|
|
| I can imagine installing KDE and having 150 apps on my desktop.  =)
|
| I think we're better off making an alias in /Applications/Fink or
| something.
|
|
| What about refining the current structure we have for our info files? We
| can use /Applications/Fink/foo/app, and when we remove the package, we
| can check everywhere under /Applications/Fink for the link to the app to
| remove it. This also brings up another point, what about having
| subcategories in our structure? kde/net kde/devel, graphics/multimedia
| etc? We could again borrow from debian the subcategories we like :)
Why not just do:
ln -s /sw/Applications /Applications/Fink
??
It is just one symlink, easier to add to our how do I delete fink? docs.
We could have subdirs in /sw/Applications as Chris suggests, I think it may
be necessary in the future.
Peter
- --
Peter O'Gorman - http://www.pogma.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.4 (Darwin)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iQCVAwUBQBWzW7iDAg3OZTLPAQLWewP/VOYheu/NCvMTjQqUTJM+bzIIbgDXg8T4
Pw7gZmP2qH/fvf8v6zCLUfk2AGU36InwNHhe1itdiF6hVBCTPW+lE6kQtEdWdhtF
Bbwc4xZzLQR47LwZl1gdIjQDP4cEj27eY5LTmk79xg+WqKtAApij8s2Pend2YDfe
EzUPIoI5yLE=
=t0/E
-END PGP SIGNATURE-
---
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
___
Fink-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/fink-devel


Re: [Fink-devel] gnome on macos x

2004-01-26 Thread Alexander Hansen
You run gnome-session
--
Alexander K. Hansen
Levitated Dipole Experiment
http://www.psfc.mit.edu/LDX
On Jan 26, 2004, at 7:19 AM, Niccolò Battezzati wrote:

Hello,

I have MacOS X 10.2.8 running on my iMac. I've installed Fink (last 
release) and I'm trying to use Gnome as window manager for unix 
applications. I installed the bundle-gnome package but I can't run it. 
If I call the startx command (with -fullscreen or -rootless) it runs 
XFree86.
Can you help me? What can I do to run Gnome?

Thank you very much!

Niccolò


---
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
___
Fink-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/fink-devel


Re: [Fink-devel] Incompatible .info files

2004-01-26 Thread Daniel Macks
On Mon, Jan 26, 2004 at 02:14:00PM +0900, Peter O'Gorman wrote:
 Daniel Macks wrote:
 |
 | In implementing variants, I'm doing some percent expansions on Package
 | using %things that may not be known to previous fink. That means (I
 | think) that if a user selfupdates while running an older fink and
 | there are variant-ish .info files, his fink is gonna croak when it
 | tries to index (he's still under old-fink, since it's not yet known
 | that there is a new fink package).
 
 Well, don't commit anything to unstable until a fink which understands the
 new % expansions has been released. Then when the user selfupdates fink will
 install the latest fink and reexecute fink before creating the index.

I was wondering about that approach. I wasn't sure if I could assume a
user will never be upgrading from more than one fink version old.

So how do you feel about the .vinfo solution?

dan

-- 
Daniel Macks
[EMAIL PROTECTED]
http://www.netspace.org/~dmacks



---
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
___
Fink-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/fink-devel


Re: [Fink-devel] Incompatible .info files

2004-01-26 Thread Peter O'Gorman
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
David R. Morrison wrote:

|So how do you feel about the .vinfo solution?
|
|
| Could you explain that a bit more?  I didn't quite follow...
Yes lets.

dmacks has added some new % expansions to fink. I assumed fink selfupdate
did the following:
1. grab .info files
2. delete index
3. check for new fink version
4. install new fink
5. exec new fink
6. generate index
which if true would be wonderful! It isn't true though :( fink tries to
generate an index before running the new fink, so when it sees unknown %
expansions it will just die and selfupdate will fail.
Peter
- --
Peter O'Gorman - http://www.pogma.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.4 (Darwin)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iQCVAwUBQBXGwLiDAg3OZTLPAQKAYwP9H3UeOggXO9UnZ7KPvr6hIN0oY3B0G8RU
1ObKm18b8QXcVgR7IlxLtdQVljURRoeY6UAqB6MAJmu16QAB5x9jTtBe1ktgIDHn
ltGMkTdXLvYF9Mn5slXgzcQUTcBOA9JtLhll0mXaRfCfvIe2qXclNjrEIsG4agf7
tCgiZzI2h4Y=
=XMAH
-END PGP SIGNATURE-
---
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
___
Fink-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/fink-devel


Re: [Fink-devel] Incompatible .info files

2004-01-26 Thread David R. Morrison
So you would migrate from .info files to .vinfo files, over time?  That's
quite a hack!

Seriously, if this were going to be done, then goal #1 of the hack would be
to set up a new, extensible, % system so that this would never need to be done
again in the future.  I don't know what form that would take, but we would
certainly need it.

Also, I would vote for .finkinfo as the new extension.

 -- Dave


---
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
___
Fink-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/fink-devel


Re: [Fink-devel] gnome on macos x

2004-01-26 Thread BABA Yoshihiko
From: Alexander Hansen [EMAIL PROTECTED]
Subject: Re: [Fink-devel] gnome on macos x
Date: Mon, 26 Jan 2004 20:25:23 -0500

 You run gnome-session

Here's how:
http://fink.sourceforge.net/doc/x11/run-xfree86.php

--
+ - - - - - - - - - - - - - - - - - - - - - - - -
+ BABA Yoshihiko
+ - - - - - - - - - - - - - - - - - - - - - - - -
+ Towards the Better Environment
+ - - - - - - - - - - - - - - - - - - - - - - - -


---
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
___
Fink-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/fink-devel


Re: [Fink-devel] Incompatible .info files

2004-01-26 Thread Daniel Macks
On Mon, Jan 26, 2004 at 09:38:34PM -0500, Benjamin Reed wrote:
 David R. Morrison wrote:
 
 So you would migrate from .info files to .vinfo files, over time?  That's
 quite a hack!
 
 Seriously, if this were going to be done, then goal #1 of the hack would be
 to set up a new, extensible, % system so that this would never need to be 
 done
 again in the future.  I don't know what form that would take, but we would
 certainly need it.
 
 Also, I would vote for .finkinfo as the new extension.
 
 And, if we have to do this, we need to make sure that anything else we 
 want to do that changes the info file format happens at the same time, 
 we won't have many other opportunities to do so.

That's why I also mentioned adding some sort of magic number and have
the indexer ignore any file that is newer than the level it supports.
Maybe a MinFinkVersion:  field as the first line?

dan

-- 
Daniel Macks
[EMAIL PROTECTED]
http://www.netspace.org/~dmacks



---
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
___
Fink-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/fink-devel


[Fink-devel] Re: .app's in Fink

2004-01-26 Thread Matthias Neeracher
From: Darian Lanx [EMAIL PROTECTED]

Martin Costabel wrote:

D. H=F6hn wrote:

I do not quite understand why. Please do not misunderstand me, I am 
not
completely opposed, I just do not get why. We are good at something,
which is packaging Unix based applications.
The underlying technology is suitable for packaging pretty much 
anything that is built from source code. Obviously, we should restrict 
ourselves to only (publicly) packaging packages that build from 
REDISTRIBUTABLE source code, but it's not clear to me that it makes 
sense to restrict ourselves to packages that display their graphics 
through X11 rather than Aqua. Note that we don't have similar taboos 
against using any other frameworks  cdrtools uses the DiscRecording 
framework, which is about as MacOS X specific as it gets, and many 
packages are using CoreFoundation or even Cocoa/Carbon.

There is a saying in german Schuster bleib bei deinen Leisten which
means as much as Stick to what you are good at. I would suggest, 
tha=
t
we leave the .app handling to others and concentrate on improving 
fink


To others like Ben Reed or what? Nobody is forced to make app 
bundles=
out of their fink packages. But there are app bundles that would 
greatly
enrich fink if they were available as fink packages

Why? Why would that enrich Fink? In what way?
Aqua based OpenOffice apps, for instance, or .app bundles for SDL based 
apps. Could you explain in what way NOT allowing .app bundle packages 
enriches fink currently?

itself as well as its packages. I really do not mind downloading 
KDE/QTMac from somewhere else. Rather than having calssic KDE/QT 
plus KDE/QTMac in Fink.
My primary reason for starting to use fink was that I did not want to 
figure out how to install (pre-Apple) xfree86 and TeX/Metafont. Each 
package we add (as long as it does not corrupt our core vision, which 
is what we're discussing here) will attract further users.

But I do mind. Why should I start reading web pages with long lists 
of instructions on what to download from where and to install first 
in /opt and /usr/local and then download something else and start 
compiling with
autoconf and glibtoolize and whatever and then install in 
/Applications
Precisely! This is what fink is all about.

Would it not be the main purpose of an app to be bundled with a neat 
Installer? Or am I missing the point here?
What if the user wants to build from source?

when I could just say fink install koffice-aqua and let fink do its
magic? Not to mention subsequent update-all or remove commands 
that
you don't get from somewhere else.

What happens to the maitainer precedence then? Will the native app
always be preffered?
That's really up to the maintainer (and nobody says that the X11 and 
the .app packages need to be maintained by the same maintainer).

Speaking for myself, I could imagine Trackballs migrating to an .app 
package and the X11 version disappearing, while nethack almost 
certainly would stay X11 based :-)

Why would anyone want to use KDE/X11 when they can have native KDE?
I don't think we need to pick favorites among Open Source packages 
(that kind of thing is best left to GNU-Darwin :-)
If native KDE runs everything that KDE/X11 does and looks good, then I 
see no inherent value in KDE/X11, but as long as people are interested 
in the latter, the KDE/X11 package will find maintainers.

Matthias



---
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
___
Fink-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/fink-devel


Re: [Fink-devel] Incompatible .info files

2004-01-26 Thread Peter O'Gorman
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Daniel Macks wrote:
|
| That's why I also mentioned adding some sort of magic number and have
| the indexer ignore any file that is newer than the level it supports.
| Maybe a MinFinkVersion:  field as the first line?
After discussion on #fink which I'll try to summarize:

The problem is a couple of bugs in fink. The parser dies when it meets
unknown percent expansions and selfupdate should not be doing an index until
it has checked for and installed a new fink. Both these bugs need to be fixed.
To work around these, because we can't magically change code in released
fink packages, a number of possible solutions were discussed;
1. make yet another Distribution:
2. change the extension from .info to something else for packages using
these new % expansions.
3. make the first line in packages using these new % expansions 'Info2: '
and update fink to not treat this field specially in future releases.
previously released fink versions will grumble a little but about
unterminated here-docs, but won't die.
I like solution 3 since I proposed it :), any other answers?

Peter
- --
Peter O'Gorman - http://www.pogma.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.4 (Darwin)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iQCVAwUBQBXoGLiDAg3OZTLPAQIVZwP8CoSqDo//j3TAJlco5JFqG1JGpGmZ4byQ
ZMwZL+UBTcsQ+ypDhNyb7piw6YYztYH58N8hdZv1EhBPueAsj3kJXRs98s4Uuqgk
JoNXguB95hg8rOzEP+G5qovu7DB7NxdE6AqLWDIlCRk7jOnpaZxDkmFdy1KWRcy1
97YkMQ7oHlc=
=9pJj
-END PGP SIGNATURE-
---
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
___
Fink-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/fink-devel