When fink itself is being worked on, the way to test it is this:
1) checkout the fink module using cvs
2) within that fink module, run ./inject.pl
That will install the bleeding-edge fink package manager.
-- Dave
___
Fink-devel mailing list
Hi all. As the experiences from the last week have shown, it is a bit tricky
updating things in the stable tree, particularly with regard to getting
all of the dependencies right.
I think it's important that we make the 0.4 release quite soon. Here's my
suggested strategy for doing this:
1)
Hmmm... using a browser I went to
ftp://ftp.gnome.org/pub/GNOME/stable/latest/sources
and what I see there is a bunch of files %n-%v.tar.gz, and no directories
%n.
On the other hand (and I didn't try this before) if I directly request
%n/%n-%v.tar.gz using wget or curl, I do get the file.
Bill Bumgarner [EMAIL PROTECTED] wrote:
Rsync's version has been bumped frequently over the last few months; from
2.5.0 to 2.5.4 happened in just a few+ months w/a revision released every
few weeks.
While the current release is available via:
http://samba.anu.edu.au/ftp/rsync/
Max Horn [EMAIL PROTECTED] wrote:
I think we might want to define a plan as to when we will consider
Fink to be 1.0. Some ideas of my own:
* package caching. It's just not acceptable that one has to wait
10-60 seconds before the actual command is processed.
* full shlibs support
This is a sporadic problem which hasn't been debugged yet. Try doing
fink reinstall automake, just by itself, and then run your big command
again.
-- Dave
___
Fink-devel mailing list
[EMAIL PROTECTED]
Hi all.
I've noticed that several of our essential packages build shared
libraries (for example, bzip2 and ncurses). This presents a bit of a
quandry for the shared libraries policy.
If we impose the shared libraries policy on these packages, they'll be
split into main and -shlibs. Should
Oh wait, I can answer my own question by looking at the scripts in
/sw/are/lib/dpkg/info. They are indeed /bin/sh and it looks like it
was fink that make them thay way.
So for consistency, I agree.
By the way, there is an old comment of chrisp's in the docs which hints
that he was planning to
Folks, Max has released fink 0.9.9 which contains the code that knows about
splitoffs.
You can put your splitoff packages into the unstable tree, but I would
suggest adding
BuildDepends: fink (= 0.9.9)
to any such package. This will force the user to update fink first and
so the code will
Sending a message about it here was a good way. I have just added it to
stable.
Another possible way is to re-open the package submission tracker item
which you originally used to submit the package, and make the request
there.
-- Dave
___
I have now committed a second draft of revised documentation for fink to
CVS. Again, only the file web/xml/packaging/packaging.xml was committed,
which could be processed into php/html if you like.
Today's changes:
1) minor edits to yesterday's changes
2) divided the list of allowed fields
If I understand correctly what the dpkg shlibs stuff will eventually do
for us, at some point in the future each fink package which provides
shared libraries will need to give some data about those libraries to
be used by the dpkg-shlibs system.
Max, will we put this directly in the .info file,
Max Horn [EMAIL PROTECTED] wrote:
The reason for bringing this up now is it would be good to start encouraging
people to provide this information in their packages, pretty soon. To
avoid fink validate problems, we might want to add one more field (Shlibs)
to the list of known fields right
My point of view about the dependent packages is this: if a user tells us
that he/she is successfully using the latest version of package foo, then
we know that he/she is also successfully using at least some version of
everything that foo depends on (even if the user doesn't point that out
Jeremy Higgs [EMAIL PROTECTED] wrote:
Hi David,
Just to clarify things... A couple of minutes ago, I updated the download
URL for qcad (in unstable), due to a report from a user that the previous
URL no longer worked. I assume this is OK, as no recompilation of the
package is necessary?
Jeremy Higgs wrote:
Just out of interest, Max, what's the easiest way to use the split-off
packages when using 'fink selfupdate-cvs'? As far as I know, the split-offs
module is not checked out when using this, so should someone wishing to try
out the split-off packages check the module out
I'd like to remind all core fink developers of the most important rule when
committing things to CVS:
IF YOU HAVE MADE ANY CHANGE TO YOUR PACKAGE, YOU MUST INCREASE THE
REVISION NUMBER.
Like any good rule, there are exceptions to this: you can modify the
Description field, for example, or
I have another small proposal to make related to the long-term shared libraries
project: I suggest that we add a new boolean field BuildDependsOnly. If
it is true, the package it is in would not be allowed to be Depended on
by any other package, only BuildDepends would be allowed. Fink won't
Justin Hallett [EMAIL PROTECTED] wrote:
hmmm I can't see why not but instead of adding more to the build time run
add it to the fink check command, which I hope all fauthors are using
right?:P
Actually, we can worry about the implementation later. We won't want to
implement this until the
Benjamin Reed [EMAIL PROTECTED] wrote:
Another thing that occurred to me while packaging is, is there a way to
do multilines inside a splitoff? While making the kdelibs package, I have
a huge line of files in the Files: section of the bin and shlibs
sub-packages. Can those be continued
The thing to keep in mind is that the package which contains headers might
get removed by users, and nothing else can depend on it. So any binary
which will only be used at compile time by other packages is fine for the
main package; anything which might be used at runtime by other packages
(or
We've had a package called fvwm-common since last July or August, which
both fvwm and fvwm2 depend on. It works in exactly the same way -- all
of the overlapping files go there. I borrowed the naming from debian
at the time. I think we can stick with that naming convention.
-- Dave
I can verify that php-4.1.2-1 will not build if the old version of gd is
installed rather than the new version. I recommend updating it to say
BuildDepends: gd (= 1.8.4-6)
-- Dave
___
Fink-devel mailing list
[EMAIL PROTECTED]
Has anybody ever seen this behavior before? I have a file. I put it in
my checked out copy of the source. I say cvs add foo; cvs commit and
the file gets corrupted, both on my copy and at the CVS site.
I don't notice this until somebody points it out, then I'm not sure if
I'm the one who
Justin, if you do fink install fink-0.9.8 you should get back to
pre-splitoff.
-- Dave
___
Fink-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/fink-devel
From [EMAIL PROTECTED] Sat Mar 9 15:48:27 2002
At 19:31 Uhr +0100 09.03.2002, Max Horn wrote:
OK, so I am working on PHP 4.1.2. Problem is, it tries to use gd,
but gd is only available as a static library. Yeah, I read the
comment, it is compiled with -fno-common, but libtool still
I discovered in the last few weeks that for one of my packages (latex2html)
the upstream source changes from time to time without the name of the
sourcefile changing. I've discussed this with the upstream maintainers
but they won't be changing their operating methods. So here's what I've done
Hmmm... the latest darwin-dev has a relevant post:
Subject: apache_mod_php module in cvs
From: Marko Karppinen [EMAIL PROTECTED]
To: darwin-development [EMAIL PROTECTED]
PHP 4.2.0 is due to be released on March 22nd, ie. in two weeks. This will
be the first PHP version with official Mac
Jeff Whitaker [EMAIL PROTECTED] wrote:
And BTW: this comes from the hdf5 dependency. hdf5 depends on hdf, which
depends on f2c fortran. If people really don't like that, I can remove
the hdf5 dependency from imagemagick. Who really uses hdf to store images
anyway?
Maybe this is a good
Hi Masanori.
Before yesterday, I was using the October Developer Tools, and I was unable
to build a working mozilla.
Now I have installed the December 2001 Developer Tools, and I rebuilt mozilla.
Everything works! So I think you have found the solution to the problem.
I know that somebody
I have written a system-ghostscript package, but I am undecided about
whether it should be included in fink or not.
As some of you know, there is a widely-used teTeX distribution (which
accompanies the program TeXShop), and we support this as an alternative
with fink's system-tetex package. The
I think I can explain what is happening during the post-installation. One
of the binaries which was compiled during the building of the package is
executed, which is supposed to configure mozilla. However, it crashes,
so the post-install script fails (with a not very informative message).
If
Kyle, the big difference between my proposal and your proposal is that
my proposal puts the burden of keeping things straight on the maintainer
of the package providing the libraries, and your proposal puts the
burden of keeping things straight on the maintainers of other packages.
Under your
Under your system, let's say I introduce foo-3.0.0 which is not
backwards
compatible. Now all of the other developers need to revise their
packages
immediately, because their packages were saying
Depends: foo (= 2.0.0)
but now they need to say
Depends: foo (= 2.0.0 3.0.0)
I thought it might be worth sketching a possible roadmap to full shared
libraries support for fink.
Phase 1: Convert some of the shared libraries packages to the
foo/foo-shlibs system. Be sure to include all packages where the major
version number is likely to change soon, or has
I've just updated the system-tetex package, which I try to do very
infrequently. One of the new features is a much more robust
pre-install script.
I haven't been able to find a solution to the following problem: some
users will need to do a bit of disk housekeeping (removing obsolete
files by
I enclose a suggested addition to the shared libraries documentation.
I believe that it addresses the problems Martin has uncovered. Any
comments?
-- Dave
Packages containing both binary files and libraries
When an upstream package contains both binary files and libraries, some
care must
fink describe lyx and fink describe xdvi will reveal the email addresses
of the maintainers.
The download URL for xdvi was fixed quite some time ago. You need to update
using fink selfupdate-cvs and then the corrected xdvi-22.48-1.info file
will be used.
-- Dave
Kyle Moffett [EMAIL PROTECTED] wrote:
On Sunday, February 24, 2002, at 07:25 , Jeff Whitaker wrote:
the .so for A::R and A::C both statically link to libapreq, which
should internally bind the entry points between the A::R/A::C and
libapreq libs, and it does on every platform including
I have separate binaries for /bin/sh and /bin/zsh, although they are
identical in size (449616) and date (Dec 31). Presumably they were
installed by the 10.1.3 upgrade. I don't know how to check the version
number of sh or zsh, which Matthias said was 3.0.8 in his case.
-- Dave
A section on shared libraries has now been added to the fink packaging
documentation, under policy. It is based on the email I circulated
a few weeks ago, with some improvements as suggested by others. I will
be happy to incorporate any other suggestions for improvement.
-- Dave
Notice that the license files for package foo go in
/sw/share/doc/foo/
So if we have foo, foo-bin, and foo-shlibs, the license files will go in
/sw/share/doc/foo
/sw/share/doc/foo-bin
/sw/share/doc/foo-shlibs
The developer will have the option of using the DocFiles line for any of
the
I'm looking for a volunteer to check out the Nautilus package on the
package submission tracker.
I can't check this one myself, because it depends on mozilla and I am one
of the people for whom mozilla does not compile correctly.
Nevertheless, this package might be useful for people who have
Hi Peter. I agree that ultimately we need the ability to generate more
than two debs from the same package file. (This is actually a bit different
from the other issue that has been discussed from time to time, namely
several variants of a package (like x/no-x) which would each require
a
There is another aspect of this which has not yet been mentioned.
When fink is analyzing dependencies, it (apparently, since I can't read
perl) creates a list of existing .info files which it can suggest it
will build in order to meet unmet dependencies. These will have to be
generated in some
Two more comments for now:
1) InfoDocs also needs to be on the allowed list, since we can't control
where the .info files will be installed. Similarly, UpdatePod.
2) Although it would be great in principle to somehow have every package
with a %n-shlibs splitoff to have a default Depends:
Hi. The most minimal form of implementing shlibs just divides the package
in half, with pkg-shlibs containing libpkg.N.x.y.dylib, libpkg.N.dylib
and often nothing else. (In particular, libpkg.dylib belongs in pkg,
not pkk-shlibs.) It is OK to put /sw/share/pkg/N/* in there as well,
so long as
I agree that in many cases we should have three packages from pkg, and other
packages would say (using the current names):
Depends: pkg-shlibs, pkg-bin
BuildDepends: pkg
Also, pkg depends on pkg-shlibs (and maybe should also depend on pkg-bin
in some cases).
Right now, the other packages
A small footnote on this: There has been a proposed openldap-ssl package
sitting in the package submission tracker for a couple of weeks, if that
makes someone's work easier.
-- Dave
___
Fink-devel mailing list
[EMAIL PROTECTED]
El JoPe Magnifico [EMAIL PROTECTED] wrote:
Cool. My gtk+ was apparently already linked against the right version,
but my gnome-libs and gdk-pixbuf were not, so I updated just those
and gnumeric works a-okay for me now too. Thanks!
Any ideas on a clean way to automate this kind of
Max, along these lines, I noticed that freetype2 is included in xfree86-4.2.
Like in the case of zlib, there is a version mismatch between fink's
version and xfree86's version, so we can't simply drop the fink freetype2.
/usr/X11R6/lib/libfreetype.6.dylib (compatibility version 6.0.0,
Max Horn [EMAIL PROTECTED] wrote:
Gnumeric crashes for me upong launch. never has been different. But
now also gabber crashes for me when I try to login. Looking at my
stack trace, both crash inside some gtkmm/gnomemm function... I
wonder if there is something deeper going on there...
Great! I think I can finally put gnumeric back into stable, then.
-- Dave
___
Fink-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/fink-devel
One correction to the earlier proposal. In the section on upgrading, I
should have said:
If shared libraries (or any other files now present
in foo-shlibs) were installed previously, then these new packages should
say
Replaces: foo ( earliest. compliant.version)
so that
Hi Max. I'm testing your new zlib, and it works great. In both of the
packages I depended which depend on zlib, at the outset, otool -L gave
/sw/lib/libz.1.dylib (compat. 1.1.3, current 1.1.3)
Then I installed the new zlib and everything still ran.
Then I recompiled my packages; now otill
Hi again Max.
I was looking more closely at a shared library example in Debian, and it
appears that they use a similar trick to what you've just done with zlib:
they divide the files between the packages like this:
Package foo contains:
/sw/lib/foo.N.x.y.dylib
/sw/lib/foo.N.dylib -
Two more comments about the new zlib
1) I have only a vague recollection about the earlier discussion of this.
Was zlib originally absent from darwin/OS X, and added in a later revision?
If so, do you need some kind of darwin-version test for the new package?
2) Since Apple is providing libz.h,
Max Horn [EMAIL PROTECTED] wrote:
At 18:11 Uhr -0500 02.02.2002, David R. Morrison wrote:
[snip]
There is one other issue: sometimes, there are a bunch of auxiliary
files which belong to a particular version of the library, and which
could get stored in /sw/lib/foo/N/ or in /sw/share/foo
I've been studying the Debian policy about shared libraries, and I think
I understand their strategy much better now.
It has several components. First, the libraries themselves are separated
from the headers -- you have to have two packages per program. (Well,
actually three in many cases,
I have one more minor adjustment to suggest for the fink validate command:
when checking whether the package name is included in the Description,
the check should be case-insensitive. I've just encountered a package
in the tracker whose description begins with a capitalized version of
the
Thanks for the explanation, Max. It's something that I kinda knew, but
had forgotten.
I haven't ever used Debian/Linux, but what I am hoping will happen after
we get this going is this: if I install a new version of a library,
dpkg will automatically recompile all of the guys that depend on
I'll take over as the new libpng maintainer (from chrisp). I made a fink
package for the latest upstream version. However, I have not put it on
CVS, because the major version number has changed and if you install the
new one, you will break around a dozen other packages which depend on it
Alexander Strange has submitted a revised version of the gimp package to
the tracker, taking over as maintainer from chrisp. (Thanks!)
There is one issue with this package that I wanted to bring up. It has
a linker flag -lcrypto and so will either use /usr/lib/libcrypto.dylib
or
Hi. If you look on the package submssion tracker you will see that
someone was working on Amaya 5.2 a few months ago; you might be able to
take advantage of the previous efforts. That tracker is also the way
to submit a new package for consideration. It is linked from fink's home
page.
The
Martin Costabel [EMAIL PROTECTED] wrote:
A little problem with the new geomview: It didn't upgrade gracefully.
/sw/bin/geomview used to be a directory, and it remained so after the
upgrade. It should now be a symlink to the geomview executable script,
so there was no geomview executable. I
Thanks, Max, for doing all of this package validation stuff.
I have one question though. For packages of type nosource or bundle,
do we really want a license field? If so, what should the rules be
about that license field? Since we are not really redistributing anything
with those packages, I
Could I suggest adding fink check and/or fink validate to the list
of commands that one sees when running fink --help? (Or else to the
man page... or both!) That will help us remember where to find this
later.
Thanks,
Dave
Max Horn [EMAIL PROTECTED] wrote:
Sorry, should have mentioned
Max Horn [EMAIL PROTECTED] wrote:
OK, it now doesn't warn for bundle package. it still warns for
nosource packages, though - the difference between those essentially
is that bundle works as an umbrella for other packages, hence
doesn't need a license field. But nosource means a
If Martin's observation is correct, a concern arises: How was the binary
being distributed by xfree86.org compiled, and is it still equivalent
to fink's, for the purposes of installing other fink packages?
-- Dave
___
Fink-devel mailing list
[EMAIL
Max, con you explain this little item in your patchfile for the new
libxml2 from today? You've patched Makefile.in with
-LDFLAGS = @LDFLAGS@
+LDFLAGS = -L./.libs @LDFLAGS@
and I'm curious about what this does and why it's necessary. (And if
the same effect could be achieved with SetLDFLAGS .)
At the very least, you could create all 15 .info files, wrap them up into
a single .tar file, and put the .tar file onto the package submission
tracker. Don't make me download 15 separate things!
Thanks,
Dave
___
Fink-devel mailing list
[EMAIL
Mat Caughron [EMAIL PROTECTED] wrote:
[snip]
Quite frankly, I'm ready to give up on Apple's pkg stuff. The only thing
it has to offer at this point is a GUI installation method, which, from
reading the mailing lists, it looks like the fink will have at some point
in the not-too-distant
Bill Bumgarner [EMAIL PROTECTED] wrote:
I saw a conversation go by that mentioned the possibility of using an
alternative to dpkg for package management...
I have no particular preference but thought I would toss out that Apple is
moving more and more to using RPM internally and that the
Do the doc and bin packages need DocFiles?
Every package needs DocFiles (or a less-automated installation of something
into %p/share/doc/%n).
-- Dave
___
Fink-devel mailing list
[EMAIL PROTECTED]
1101 - 1174 of 1174 matches
Mail list logo