The problem with perl is similar, but not identical.
Many perl modules work just fine with all versions of perl, and those
don't necessarily need to be segregated from each other.
Once I get the bindist out the door, I plan to work on getting multiple
versions of perl coexisting with fink. For
Max Horn [EMAIL PROTECTED] wrote:
Am Mittwoch, 02.04.03 um 12:43 Uhr schrieb Christian Schaffner:
Dear Jeff, dear Fink developers
Since I got quite a bit positive feedback on apr and svn-client I
would like to move the current packages to the stable tree before the
next binary
tetex-nox depends on tetex-shlibs and tetex-dev, and the latter two require
the X11-enabled versions of ghostscript in order to *build*, but not in
order to run.
To build tetex-nox without installing those versions, you'll need to do
binary installs of the little -shlibs and -dev parts, via:
Dear fink developers,
There has been a small change to the bootstrap, related to my recent project
to make Fink compatibile with newer versions of perl. There are two
additional packages present in the bootstrap now: storable-pm560 and
system-perl580. Only one of these will actually be built
Dear fink developers,
We've suffered for some time with an inability to update some of our
essential packages, due to not having made splitoffs of them. There
have been discussions about ways to do this a few times in that past,
which concluded that there is no truly elegant solution to this
At Ben Hines' suggestion, I've moved libtool14-1.5-1 to stable.
Is there any need to keep libtool 1.4 around? If so, can anybody think
of a sensible package name for it? (libtool143-1.4.3-1, perhaps?) I won't
do this unless there is demand for it, though...
-- Dave
What is the point of LibTool in Fink, Mac OS X include version 1.4.2
from glibtool --version:
ltmain.sh (GNU libtool) 1.4.2 (1.4 2001/11/19 00:06:02)
Sure, and now libtool is up to 1.5 . The newer versions have a lot of
Darwin/Mac OS X-specific improvements, in fact (many of which were
- python modules: must comply with fink python policy
Is anybody willing to write a brief statement of what this policy is? I
would then add it to the documentation. I'll also add the emacs policy,
which Rohan pointed out.
-- Dave
---
Many of you will remember the discussions in March and April about somehow
automating the setting of paths for new users.
Martin Costabel has written a nice little app for this purpose (really
a shell script executed by the Terminal). It needs testing (and possibly
critiquing). Let me encourage
More details about my proposed change to the essential packages. I've now
made some packages, in my experimental tree, which can serve as placeholders
for the new splitoffs of essential packages during the transition.
Here's how it would work: First, I'll put these new packages (for things
like
And finally, let me explain the motivation for this change a bit more.
We are unable to update essential packages which have shared libraries,
if those libraries get a change in their major version number, without
the splitoff mechanism. This has already happened for gettext, the
latest versions
Hi Max. I agree that caution is necessary in executing this change.
There are really two things being changed here: (1) we now insist that
dependencies on essential packages should be stated, and (2) in addition
to that, we're going to change the setup of the essential packages.
It's hard to
Max,
I can almost fix the bootstrap with the following sort of modification: We
ask the user Do you still have the apple-supplied perl or has it been
replaced with perl 5.8.0? Then we remove either storable-pm560 or
system-perl580 from the set of files in the 10.2 directory, and the
correct one
Here's the point: there is a new version of gettext with a new major version
number for the library. In an ideal world, we would have gettext-shlibs,
gettext-dev, gettext2-shlibs, and gettext2-dev all available. (This is
what I am trying to achieve, in fact.)
Now, which of these are essential?
Hi Max. I think it is tolerable for now. Can we encourage SF to hurry
up a bit with the spam filters? It would be better to wait for them,
if we can...
-- Dave
---
This SF.net email is sponsored by: Etnus, makers of TotalView, The best
When a library gets a non-backward-compatible upgrade, fink's shared libraries
policy (which was borrowed from Debian), insists that the package which
contains the shared library should get a new name. The library itself
will get a new name too: for example, the gettext package currently
installs
Hi Carsten.
Please wait until the next release of the fink package manager before using
%n.info in the unstable tree, and wait until that version of fink has
moved to the stable tree before using %n.info in the stable tree.
-- Dave
---
This
Folks, there are lots of packages in the unstable tree which don't pass the
tests in fink validate. Everything is required to pass these tests (except
for the package lenght being 45 characters) in order to be allowed into a
binary distribution, so when there is a lot of last-minute moving from
Yes, I know that not everybody has waited. But I'm still asking people please
to wait.
-- Dave
---
This SF.NET email is sponsored by: eBay
Great deals on office technology -- on eBay now! Click here:
I've released fink 0.13.2. This is a very minor update, which adds Martin
Costabel's pathsetup.command script to fink. I hope to push it to the
stable tree quite quickly.
This is NOT the promised release which will allow folks to start using the
name.info style. Please continue to wait
This is just a reminder to check your dependencies before moving things to
the stable tree.
Two of the packages which were added to the stable tree just prior to the
code freeze have been removed by me today, due to missing dependencies.
In one case, seven other fink packages were required which
Koen van der Drift [EMAIL PROTECTED] wrote:
I've released fink 0.13.2. This is a very minor update, which adds Martin
Costabel's pathsetup.command script to fink. I hope to push it to the
stable tree quite quickly.
Where is it? It doesn't show up in unstable - I'm still at 0.13.0-1, and
The code freeze for the stable tree is now lifted. Thanks for your cooperation.
-- Dave
---
This SF.Net email is sponsored by: INetU
Attention Web Developers Consultants: Become An INetU Hosting Partner.
Refer Dedicated Servers. We Manage
Thanks for the offer. You might have noticed on that web page that
system-libgl is only a 10.1-package in fink? This is because it is
no longer needed in 10.2... So there is probably not much point in
getting a new maintainer for it.
Generally, being a package maintainer means keeping up with
As most of you have heard, there is a new cooperative venture between Fink,
Gentoo, and DarwinPorts, intended to share patches and porting information
among the three projects.
You are all invited to subscribe to the mailing list which has just been
set up for that purpose:
Dear fink-devel,
We need to do some further work on our system-xfree86 package.
Imagine a user who is interested in doing binary-only installs of Fink
packages. We already know that such a user won't need the Developer tools,
because no compiling will be done. Similarly, such a user does not
There are binary compatibility issues between code compiled with gcc 3.1
and gcc 3.3. We are still investigating these, to determine what the
impact will be on Fink. For now, I advise everyone to stick with gcc 3.1
for their compiles.
-- Dave
I like this idea of making a deb out of what was on the users system, so that
it could be restored later.
-- Dave
---
This SF.Net email is sponsored by: INetU
Attention Web Developers Consultants: Become An INetU Hosting Partner.
Refer
James Gibbs [EMAIL PROTECTED] wrote:
On Tuesday, June 24, 2003, at 06:32 PM, Randal L. Schwartz wrote:
And so it's been broken for a week for everyone, and there's no
end to the breakage in sight? How is anyone getting anything done?
There is new hardware scheduled for installation at
It's the NDA you agree to when you join the Apple Developer Connection,
either as an online member or as some other kind of member. I'm sure
there must be a copy somewhere at connect.apple.com .
-- Dave
---
This SF.Net email sponsored by:
Dear fink developers,
As some of you know, we have a pretty slick system for generating our
web pages, using xml source which is processed into php files.
The same xml source can be processed into more monolithic html files,
which are distributed these days with the binary installer. Also, some
OK, the ncurses issue is another complicated one.
Both with fixing ncurses, and with the gcc 3.3 ABI change, we're going
to need to so what we did last time and be careful to do two things:
1) give a new version number to pkgs with C++ code when they are moved
to the 10.3 tree
2) make every
As I discussed on the list last night, I've rearranged the way we work with
the documentation and the website.
You should get rid of your CVS checkout of web, and instead do a CVS
checkout of xml. If you don't do this, you'll find that make install
no longer has the expected behavior, because I
Alexander K. Hansen [EMAIL PROTECTED] wrote:
OK. Is this the correct operational sequence:
1) Make changes to the XML files
2) Commit the XML (cvs commit xml)
3) Generate the PHP, HTML, etc. (make ; make install)
4) Commit the other stuff (cvs commit xml again)
?
Yes, that
Dear fink-devel,
As discussed on the list a while back, I'm planning to convert four of
our essential packages (bzip2, gettext, libiconv, and ncurses) to splitoff
packages. When this is done, the -dev parts of the packages will no
longer be essential, and you'll need to declare dependencies on
Ah, I get it now. I guess for me, a certain workaround has become such
a habit that I forgot about why I do it. Namely, when I want to build a
package foo which has a shlibs splitoff, I just do fink build foo-shlibs
to avoid the extra installation.
-- Dave
Hi Max.
If you do fink build foo then indeed foo-shlibs gets installed.
My understanding of the logic is this: both Depends and BuildDepends
are checked for whether they are installed or not, when fink build foo
is processed. Since foo-shlibs is not yet installed, the command
fink install
There are two ways to resolve the versioning issue. One is to rename
the package. The other is to use the relatively new Epoch field in
fink. All versions with epoch = 1 are regarded as newer than all
versions with epoch = 0 (the default).
Epochs should only be used in special cases, but this
Just to follow up on my own message:
As the referenced document (made publically available, with permission of
the company, by an Apple employee) indicates, Apple will be shipping
a slightly non-standard version of Perl 5.8.1, with two-level namespace
enabled and thread support turned on. For
The stable tree contains imlib-1.9.14-3, libjpeg-6b-6, and libpng3-1.2.5-4.
The -shlibs packages are splitoffs of the main packages, so they are
there as well.
These are precisely the same versions as are available in the unstable
tree.
-- Dave
From: Christian Schaffner [EMAIL PROTECTED]
Hi all. JF Mertens has contributed a number of -pm580 packages to go
along side the -pm560 packages, as well as some fixes for the latter.
You can find these in /experimental/jfmertens if you would like to
help test.
Also, he has provided workarounds for the assembler problem in the
gcc 3.3
Hi Dean.
I think this is a very interesting project. I've had thoughts along similar
lines, that someday all of the basic libraries which fink is providing
might be packaged into frameworks for a more OS X-like version of fink.
-- Dave
---
John,
You'll defintely find some rough edges if you try to use fink with the
WWDC Panther preview. A number of fink developers will have access to
Panther seeds as software seed key holders, and we're working to get
fink up and running.
I found lots of problems with various 0.5.3 binary
Thanks for pointing this out. Fixed now.
-- Dave
Hi,
there is a problem on the Fink's site. Under Documentation section
the link Print Version seems to be broken for all documents. Could
you fix it?
Thanks,
Andrea.
---
not only a wait to combine them, but the seperate them too for when
maintainers are making the next release.
Sure. That's what I meant about needing tools. If we had a little tool
for developers to use to bundle the .info and .patch file into a text archive
(maybe with the shar format), and
Well, it still doesn't solve the problem of how to retrieve an old patch file
that correctly matches the fink version number.
Peter O'Gorman jokingly suggested on IRC using ar to combine them. Or maybe
it wasn't a joke? In fact, some way of combining them would be get.
(The ar idea is not so
I'd like to weigh in on this again. I played around for a while today with
making shar archives out of a combination of info and patch files, using
/usr/bin/shar (which is BSD shar). The resulting file is quite similar
to the original proposal of tacking the patch file on to the info file,
but
Hi Max. Well, actually I was thinking that fink could parse the shar
archive directly, and only unpack it if it was building a package
(in order to extract the patch file). The algorithm:
1) ignore all lines at the beginning not starting with X
2) while the line begins with an X, drop the X
An apple employee posted the Developer Release Notes for Perl on Panther over
on the macosx-talk mailing list. They are well worth reading.
http://www.omnigroup.com/mailman/archive/macosx-talk/2003-June/013541.html
-- Dave
---
This
I don't think that -beginners is restricted either. I don't subscribe to
it, yet I am able to post to it.
-- Dave
---
This SF.Net email sponsored by: Parasoft
Error proof Web apps, automate testing more.
Download eval WebKing and get a
Finlay Dobbie [EMAIL PROTECTED] wrote:
I'm not maintaining this any more.
Begin forwarded message:
From: Dameron Midgette [EMAIL PROTECTED]
Date: Mon Jul 14, 2003 12:03:22 am Europe/London
To: [EMAIL PROTECTED]
Subject: ion-20011109-1
OK, I've removed your name as maintainer of
On Jul 14,2003 12:08:33 -0700, William Scott [EMAIL PROTECTED] wrote :
If gcc 3.3 is again responsible for this, I think fink either needs to
fix this now or tell people not to install the patch. Merely switching
back to 3.1 doesn't solve these problems.
Bill,
There have been warnings at
Dear fink developers,
Over the past few weeks, I added BuildDepends on bzip2-dev, gettext-dev,
libiconv-dev and/or ncurses-dev to many many packages. The corresponding
splitoff versions of these essential packages have now been added to
the unstable tree, and will move to stable after a testing
There is one public source of information about 10.3: the Darwin 7 Preview
http://www.opensource.apple.com/darwinsource/7.0b1/index.html
This includes some of the open source projects for Mac OS X, the WWDC
Panther seed.
Unless lipipx is part of a larger project, it does not seem to be on
Hello Mark. There are several things to do:
1) Read the installation instructions for the package: they often mention
some of the requirements.
2) Watch the output of configure as it runs: in many cases it will
mention things it is checking for and there might be a corresponding
fink
To make sure that the old issues with Storable don't get in the way,
people need to be updated to at least fink-0.13.0 , which changed the way
that fink handles perl modules. If people do that before trying to
upgrade Perl, they shouldn't have any problem with Storable.
Someone who upgrades Perl
Hi. This is indeed a tricky problem. Ideally, people might want to have
several different versions of the perl-core packages installed, and might
want the ability to easily switch back and forth among them. So I am a
bit concerned that the perl-core-not packages you propose would interfere
with
I'm not sure if you got a response to your initial message or not.
Apple has added a number of new open source pacakges with each major
release of OS X. So far, fink's philosophy has been to keep providing
a fink version of the package, even after Apple is providing their own.
(The only
When we need to host the tarball for a package at fink's site, it has to
be placed there by one of the fink project leaders.
If the package in question is ready to go, otherwise, please let me know
the details and I can get the tarball to the fink site.
By the way, this assumes that the source
I'd like to get some feedback on the splitoff versions of the essential
packages bzip2, gettext, libiconv, and ncurses, which were introduced to
the unstable tree around 10 days ago.
Did the update go smoothly for people? Is anyone aware of any problems?
(There was one user with a problem on
Either way is fine. If you add your new version to the old tracker item,
be sure to change closed to open. Or if you prefer to start a new
tracker item, that is fine too.
-- Dave
From: Nathan Hackett [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: [Fink-devel] new version
Date: Mon,
Well, to respond to my own message, a problem just showed up on the fink-users
list! As a result, there is yet another new gettext package, with the
InfoDocs command moved to the correct splitoff. I'll need to wait a while
for feedback on this one before I can move all of these things to stable.
Well, Justin just found a problem when trying to install the gettext-0.10.40-6
package: its a problem of circular dependencies. This is the same problem
which a user had reported in IRC 10 days ago.
I have removed gettext-0.10.40-6 from unstable, and put it into my
experimental tree instead. I
I also had no problem with it, or I wouldn't have put it there, of course.
But since Justin has had the mysterious circular dependencies problem,
I think it's important to track that down before this gets out into
userland.
-- Dave
---
This
The circular dependencies problem seems to have been unique to Justin's
setup, so I have returned gettext-0.10.40-6 to the unstable tree and hope
that the upgrade will go smoothly for folks.
-- Dave
---
This SF.Net email sponsored by: Free
Martin,
Ben Reed (rangerrick) is on vacation this week, so you won't be able to tap
into his experience with qt right at the moment.
-- Dave
---
This SF.Net email sponsored by: Free pre-built ASP.NET sites including
Data Reports,
Hi Max.
1) You are quite right, the man pages belong in -dev. I'll move them.
2) Yes, gettext-runtime and gettext-tools can be compiled completely
separately, although they use the same source (and gettext-runtime has
to be done first because gettext-tools links to the libs in the other
I doubt that we can use update-alternatives in gettext. The problem is,
the update-alternatives binary is provided by dpkg, but dpkg depends
on gettext and so gettext gets built earlier in the bootstrap...
-- Dave
---
This SF.Net email
John,
I'm aware of this issue, and have reported it to Apple. Hopefully it will
get fixed before Panther is released.
In the meantime, adding the following two lines after xmkmf in your
CompileScript should fix the problem:
mv Makefile Makefile.old
sed s|-arch i386||g Makefile.old Makefile
Dear Yarden,
A number of us are working on getting things ready for Panther, but due to
the NDA we don't discuss the details on the mailing list. However, you
can find a number of Panther-ready packages in various parts of the
experimental CVS tree.
Of course, one of the issues is simply that,
Hi Max. I need your help in figuring out the correct strategy for upgrading
gettext.
There are two issues, which I will keep separate so as not to confuse things.
As I've mentioned before, the major version number in libintl.dylib has
changed in recent versions of gettext, so we need a new
What happens if two packages specify the same user? Even if this is OK,
what happens if they give different info about that user?
-- Dave
---
This SF.Net email sponsored by: Free pre-built ASP.NET sites including
Data Reports, E-commerce,
Dear fink-devel,
For those of you who are helping to get Fink ready for 10.3, I've moved the
10.3-enabling code into a CVS branch of the Fink project, called
test_10_3.
Best,
Dave
---
This SF.Net email sponsored by: Free pre-built
Ben Hines [EMAIL PROTECTED] wrote:
Why? Xcode (and 3.3) is shipping for jaguar. No need to depend on OS.
-Ben
On Thursday, August 14, 2003, at 08:58 AM, David R. Morrison wrote:
Modified Files:
ChangeLog PkgVersion.pm
Log Message:
disable prebinding code unless distribution
After a discussion on IRC last night, I have a completely different proposal
to make about the gcc 3.3 upgrade.
In the new proposal we make a new distribution, perhaps called 10.2a, which
is for packages running under 10.2 but compiled with gcc 3.3. Peter O'Gorman
and others believe that version
It's possible that the problem here is the SourceForge delay in CVS: it
can take up to 24 hours for a file to propagate from the live CVS tree
to the backup CVS which is accessible to anonymous users (and through the
web interface).
-- Dave
One thing I forgot to say. Even with my new strategy, we need to have fink
verify that the correct version of gcc has been selected when compiling is
being done.
The overwhelming opinion on IRC last night was that fink should NOT reset
your gcc selection. Instead, fink should query the gcc
John Davidorff Pell [EMAIL PROTECTED] wrote:
I'm actually a little confused as to why each *package* needs the gcc:
3.1 | 3.3 flags. Its only important to which version of gcc3 we compile
with, not which code we compile.
Shouldn't fink just keep track of which gcc3 a given package was
Hi. After the discussion last week, I agree with you, and don't plan to have
fink invoke gcc_select. In fact, I've put code into fink on CVS which
checks that version of gcc you are running (when it matters, as indicated
by the GCC directive), and if the version is incorrect, advises you to
run
Dear Fink developers,
As some of you know, the pkgconfig system is being used extensively with
GNOME2 packages and possibly with other systems as well. The pkgconfig
system aims to solve the problem of multiple versions of a shared library
by (1) carefully giving different names to different
Peter O'Gorman [EMAIL PROTECTED] wrote:
Hi David,
On Thursday, August 28, 2003, at 09:41 PM, David R. Morrison wrote:
SHORT TERM SOLUTION:
Although we should not allow a -dev splitoff to Depend on another -dev
splitoff, we can use the Recommends field to specify the other -dev
What about fixing the fink dep engine, so that BuildDependsOnly
packages may depend on other BuildDependsOnly, and then a kde packahe
could BuildDepend on kdelibs3-dev and a few other -dev packages it
needs, and fink will make sure everything needed is there; fink would
need to
Hi Peter. This one should be structured as a warning to developers, not
to users (similar to the duplicate fields warning). In fact, there is
already a warning if you do fink fetch foo and foo has no MD5-sum.
Just like with duplicate fields, and other critical errors, we shouldn't
be allowing
On Aug 29,2003 23:57:27 +0900, Peter O'Gorman [EMAIL PROTECTED] wrote :
On Friday, August 29, 2003, at 11:41 PM, David R. Morrison wrote:
Hi Peter. This one should be structured as a warning to developers,
not
to users (similar to the duplicate fields warning). In fact
On Aug 29,2003 11:09:56 -0400, David R. Morrison [EMAIL PROTECTED] wrote :
On Aug 29,2003 23:57:27 +0900, Peter O'Gorman [EMAIL PROTECTED] wrote :
On Friday, August 29, 2003, at 11:41 PM, David R. Morrison wrote:
Hi Peter. This one should be structured as a warning to developers
On Sep 5,2003 09:41:36 -0400, Cunningham, Chad [EMAIL PROTECTED] wrote :
Hi,
I've been making a binary of webalizer available on their site for some
time and I'm thinking I'd rather just add it to fink and have people grab
it from there. I've noticed that webalizer (as well as zlib, which it
Dear fink-devel,
I've begun to implement the gcc 3.3 update, as I described in a few messages
in mid-August.
If you are interested in testing or assisting, here's what you need to do.
First, you can bootstrap fink running 10.2 and gcc3.3 if you check out the
CVS branch tagged test_10_3 and
One more thing, if you'd like to help out...
To keep things straight, when I move a package to HEAD, in the 10.2-gcc3.3
tree, I *remove* that same package from the not_ready branch... that
way, the only things left in the not_ready branch are the things still
being worked on...
(And in case you
This sounds like the libtool-1.4.x relinking bug. Try disabling relinking
and see if that cures it.
perl -pi.bak -e s/need_relink=yes/need_relink=no/ ltmain.sh
is one way to do it.
Or, if it is finding an old copy of the library during linking instead
of the one it just build, you can try
Well, it's still relinking.
Why does it list as libtool
SH_LIBTOOL='/sw/share/apr-0/build/libtool'
That sounds like something already installed, perhaps by the previous build?
If it wants to be using a customized one, it should be looking in the
build directory, no?
-- Dave
Greg Novak [EMAIL PROTECTED] wrote:
On Tue, 9 Sep 2003 Jerry Talkington wrote:
Unfortunately there doesn't seem to any desire among the maintainers to
make fink a more user mode environment, which is a big mistake, IMHO.
An application shouldn't request root privileges until absolutely
I suppose you are using the updated Developer Tools? There is a problem
with fort77 and the new tools. As it says on Fink's homepage, users
are advised not to update their developer tools, or if they do, to be
sure and run sudo gcc_select 3 before using fink to compile packages.
The problem
Dear fink-devel,
The code freeze for the 10.2/stable tree is hereby lifted. However, I would
like to ask all fink developers to try and keep 10.2-gcc3.3/stable in sync
with (or ahead of) 10.2/stable. I hope that the conversion to the new
trees will be complete within a few weeks.
All fink
Here's a list of what's currently missing from 10.2-gcc3.3/stable, and a
discussion of some of the reasons.
First, KDE has not yet been moved to 10.2-gcc3.3, but no problems are
anticipated.
Second, fort77 does not compile under gcc 3.3, probably due to problems
with f2c (which probably needs
We're still in the process of upgrading packages to be ready for gcc 3.3.
The enforcement of the fink declaration GCC: 3.1 was not done in the
past, but is now being done with the recent upgrade.
Your best strategy if you are using panther is to make sure that the
dists symlink points to
clisp-2.29 is also available from fink in binary form. The binary was
compiled with gcc 3.1.
-- Dave
---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
Koen, did you recompile xfree86 after the update?
-- Dave
---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
Fink-devel mailing list
[EMAIL
Dear fink-devel,
With the recent release of fink-0.14.0 and fink-0.14.1-beta, I slightly
switched strategies with respect to the various branches in CVS. I
merged the old test_10_3 branch back into HEAD at that time. Please
don't make any new commits to that branch.
Instead, what I intend to
Does anybody have any feedback on fink 0.14.0? I'd like to move it to stable
soon, so that we can announce the rsync update method as the preferred method
for all users. (Anonymous CVS at sourceforge has become unresponsive AGAIN...)
Thanks,
Dave
Do you have unstable/crypto and unstable/main in the Trees line in
/sw/etc/fink.conf ? The new rsync method only updates the trees which are
mentioned in your conf file.
-- Dave
---
This SF.net email is sponsored by: SF.net Giveback
401 - 500 of 1174 matches
Mail list logo
