I would rather hand off maintaining these packages to someone else, if you'd
like to take them feel free! Unfortunately distracted with many things these
days so not much time/motivation to work on fink stuff.
thanks,
-Ben
On Fri, Mar 26, 2010 at 4:30 PM, Max Horn m...@quendi.de wrote:
Hi
Perhaps if it had a maintainer then it would be up to date.
This is silly that we are well over six months behind on such core
things.
-Ben
On Jun 2, 2005, at 9:45 PM, Daniel Macks wrote:
Our glib2 is too old for pygtk2-2.3.x :(
dan
On Thu, May 26, 2005 at 01:02:18PM -0700, Ben Hines
and do so.
thanks
-Ben
On Jun 3, 2005, at 3:14 PM, Ben Hines wrote:
Perhaps if it had a maintainer then it would be up to date.
This is silly that we are well over six months behind on such core
things.
-Ben
On Jun 2, 2005, at 9:45 PM, Daniel Macks wrote:
Our glib2 is too old for pygtk2
I disagree with making ALL of these desc checks only verb 3. Did you
mean to only change the 45 char desc warning? (due to bracketing, all
were lowered to verb 4, which means noone will ever see them.
-Ben
} elsif (Fink::Config::verbosity_level() 3) {
# Some pedantic checks
if
Sorry that was dmacks :)
Silly cvs.
-Ben
On Feb 12, 2005, at 7:15 PM, Ben Hines wrote:
I disagree with making ALL of these desc checks only verb 3. Did
you mean to only change the 45 char desc warning? (due to
bracketing, all were lowered to verb 4, which means noone will ever
see them
The deb contents database is pretty much ready for basic testing, see
the patch here:
experimental/benh57/fink/Reporting.pm
experimental/benh57/fink/reporting.patch
Folks are wondering why i don't make it live. I do want to put it into
CVS, HEAD actually, but since 24 is imminent it does make
Why not make 'fink build' ignore the depends line completely in all
cases?
-Ben
On Feb 5, 2005, at 7:30 AM, TheSin wrote:
Just to clarify this a little, only comment out the depends and use
'fink build' for testing, make sure you don't commit the pkg with the
depends commented, they are still
All of fink needs to be built with this patch before releasing this.
We've never audited this policy, my guess is a lot of stuff will break.
-Ben
On Feb 3, 2005, at 10:29 AM, TheSin wrote:
Also this needs to be docu'd and a policy for this needs to be made.
Lots of perlmods don't comply to
They lie. Perhaps they are there on tiger? They aren't on panther, even
with the dev tools installed.
-Ben
On Feb 4, 2005, at 8:54 PM, John T. Shaw wrote:
I asked a little while back about the cups headers in Mac OS.
Interestingly enough I got a response that said the headers are
included in a
never got around to packaging it,
although I had almost working packages in the tracker a year (or
more?) ago. Does it compile on a clean fink install? Thanx!
JP
On 30 Jan 2005, at 15:29, Ben Hines wrote:
I went ahead and switched libnids to libnet1.0 - and packaged dsniff,
which was not in fink
I went ahead and switched libnids to libnet1.0 - and packaged dsniff,
which was not in fink yet. I dont think a lot of folks have been using
libnids especially since dsniff wasn't in fink, and the libnids was
installing directly into /sw which is very bad. So i fixed that as
well.
Anyway, try
We should not put those instructions up unless we know that they work.
I don't think it will because 0.5.0a bindist doesn't contain that
version of fink.
The fix on the website was known to work for certain for that specific
upgrade problem, if there is some other version which also has the
But why shouldn't perl584-core specify /sw/bin/perl5.8.4 as the
startperl option? Specifying /sw/bin/perl seems inherently broken since
that file is not included in the -core package.
-Ben
On Nov 9, 2004, at 5:52 AM, David R. Morrison wrote:
On Nov 9, 2004, at 3:18 AM, Ben Hines wrote
On Jun 13, 2004, at 3:06 PM, Justin F. Hallett wrote:
Update of /cvsroot/fink/dists/10.3/unstable/main/finkinfo/libs
In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv28997
Added Files:
libdvdnav.info
Removed Files:
libdvdnav2.info
Log Message:
New upstream release, renaming
the Shlibs field deals
with compat.
---
TS
http://southofheaven.org
Chaos is the beginning and end, try dealing with the rest.
On 13-Jun-04, at 4:27 PM, Ben Hines wrote:
The old package should remain, and the new package should be called
'libdvdnav5-shlibs' to comply with the shlibs policy
,
the one provided by perl581-core might not be available, so you could
imagine needing a bunch of -pm584's to handle this.
-- Dave
From: Ben Hines [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: dists/10.3/unstable/main/finkinfo/libs/perlmods
locale-gettext-pm.info,1.1,1.2
Modified Files
On Jun 2, 2004, at 7:55 AM, Alexander K. Hansen wrote:
That's because nautilus-shlibs is only available in the unstable tree
(which is why a binary isn't available). By rights,
gnome-python2-py23 and therefore gramps should not be available in
stable either, because of this.
Anyway, you'll
On May 31, 2004, at 1:39 PM, Martin Langhoff (NZL) wrote:
Ben Hines wrote:
Works fine here, with those info files. (the patch fails, though)
Perhaps you have an old version of your info file there somewhere. If
all else fails try putting the revision on 2 and see if 'fink update'
updates
On May 29, 2004, at 11:43 PM, Martin Langhoff (NZL) wrote:
Building my 1st fink packages and I cannot for the life of me get
Patch or PatchScript entries to be observed. Is there any mechanism to
debug this situation? If I prevent the builddir from being removed, I
can apply the patch
On May 29, 2004, at 6:04 PM, Martin Langhoff (NZL) wrote:
And that was the last time /etc was seen alive.
After a moment of panic, I fixed it mounting the iBook as a FW device
-- connected to another mac. Recreated the symlink, easy enough.
However, I find distressing that I was able to do this
Revert this
-Ben
On May 27, 2004, at 6:33 PM, Benjamin Reed wrote:
Update of /cvsroot/fink/dists/10.3/unstable/main/finkinfo/utils
In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv2740
Modified Files:
rzip.info
Added Files:
rzip.patch
Log Message:
rzip compression program
On May 28, 2004, at 7:52 AM, David R. Morrison wrote:
but this principle has always been
more a pious wish than reality.
Could you explain in more detail what you mean?
I think it's a pretty accurate comment. It has been stated goal of
fink to
make sure that fink packages always compile the same
On May 28, 2004, at 5:23 AM, Charles Lepple wrote:
Sébastien Maret wrote:
I'm working on a package that compiles and runs only on MacOSX10.3.4,
because of a libm bug in previous versions.
How can I check in my package the version of MacOSX before compiling ?
actually, I guess you would need both
On May 30, 2004, at 2:08 AM, Sébastien Maret wrote:
Le 30 mai 04, à 10:56, Ben Hines a écrit :
On May 28, 2004, at 1:40 AM, Sébastien Maret wrote:
I'm working on a package that compiles and runs only on
MacOSX10.3.4, because of a libm bug in previous versions.
There is no such thing as libm
On May 15, 2004, at 11:12 AM, Spundun Bhatt wrote:
- Shlibs: %p/lib/libgsf-1.1.dylib 10.2.0 %n (= 1.8.2-1)
+ Shlibs: %p/lib/libgsf-1.1.dylib 10.2.0 %n (= 1.9.0-1)
To reiterate for everyone, this is wrong.
See
http://fink.sourceforge.net/doc/packaging/policy.php?
On May 8, 2004, at 9:21 AM, jfm wrote:
turned up only pari-gp (the executable)_ and that's no problem, since
otool shows gp links only with ncurses.
This must already cover a fair number of your 70 pkgs ...
So there is no problem then. We can update the 3 packages which have
the problem.
-Ben
We made variants to get rid of the multiple-info files messiness of
560* 580*, etc etc, shouldn't add new ones. You should use variant
packages for any new perl module setup. The old style is extremely
deprecated.
-Ben
On May 8, 2004, at 6:45 AM, David R. Morrison wrote:
Modified Files:
On May 8, 2004, at 3:05 PM, David H. wrote:
Ben Hines wrote:
The old style is extremely deprecated.
^^^
When did we decide on that? Since I was not reading the mailing lists
for a bit last wekk (was very busy), I might have overlooked the
discussion, but I am
On May 7, 2004, at 9:38 AM, jfm wrote:
Hi,
Today's update was motivated by :
Put an end to:
warning multiple definitions of symbol _BC
/sw/lib/libreadline.dylib(terminal.so)
definition of _BC
But since then I got with several programs :
# Singular
dyld: Singular Undefined symbols:
On May 7, 2004, at 4:42 PM, Ben Hines wrote:
That did not happen to me. Perhaps it will only occur with programs
which do not use ncurses, but which do use readline? Which programs ?
Also, at this point we might as well start adding versioned deps on the
latest readline on anything
Still a long-time bug in the packaging of db42, which needs to be fixed
at some point, if anyone feels like figuring out why it happens by
debugging the dependency resolver.
-Ben
On Apr 30, 2004, at 9:21 AM, Alexander K. Hansen wrote:
Did you try the suggestion from:
On Apr 19, 2004, at 6:45 PM, David R. Morrison wrote:
We need a mechanism to mark packages as should not be moved to 10.3,
especially if there is going to be a general call to action like this.
This is done. See http://fink.sourceforge.net/pdb/compare.php now.
Maintainers can change the status
On Apr 19, 2004, at 12:47 AM, D. Höhn wrote:
|
I suggested this. The University of Tokio will be supplying Fink with
numerous packages, mainly targeted toward the Japanese user. Asari
You should not have done that.
Takashi is only _one_ of the Tutors that take care of the submission
and
package
Still 500 pkgs show 'not moved' from 10.2-gcc3.3 to 10.3. A number of
these are obsolete, but many are not. Anyone with commit access feel
free to move over anything that works. (I usually start them out in the
10.3 tree with the new filename format, but be sure to fix any
references to the
On Apr 19, 2004, at 5:08 PM, Daniel Macks wrote:
On Mon, Apr 19, 2004 at 04:46:03PM -0700, Ben Hines wrote:
Still 500 pkgs show 'not moved' from 10.2-gcc3.3 to 10.3.
http://homepage.mac.com/bhines/finknotmoved.html
Something's wrong...you list gnome/pygtk2-py* and
libs/term-ansicolor-rb
On Apr 19, 2004, at 5:44 PM, Ben Hines wrote:
I think the #Package: term-ansicolor-rb16 commented out Package fields
broke my script. (these are old scripts from the 10.1 move, they don't
call fink and used a sketchy parser.. i updated the script to use some
of the read_properties_lines regex
On Apr 19, 2004, at 5:47 PM, Ben Hines wrote:
On Apr 19, 2004, at 5:44 PM, Ben Hines wrote:
I think the #Package: term-ansicolor-rb16 commented out Package
fields broke my script. (these are old scripts from the 10.1 move,
they don't call fink and used a sketchy parser.. i updated the script
On Apr 19, 2004, at 6:45 PM, David R. Morrison wrote:
All of the packages on that list which have me as the maintainer were
deliberately not moved, and should not be moved. I will be happy to
supply
reasons if required.
We need a mechanism to mark packages as should not be moved to 10.3,
On Mar 30, 2004, at 3:36 PM, David R. Morrison wrote:
Release candidates for the new installers are up at:
http://www.cgtp.duke.edu/~drm/Fink-0.6.3-Installer.dmg
http://www.cgtp.duke.edu/~drm/Fink-0.7.0-Installer.dmg
The PDB will need some code changes to handle the new release and
Why remove them?
-Ben
On Mar 5, 2004, at 6:02 AM, Mich?le Garoche wrote:
Update of /cvsroot/fink/web
In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv4123
Modified Files:
people.fr.php
Log Message:
revert to old version without Language team Leaders
Index: people.fr.php
On Feb 28, 2004, at 4:34 AM, Jeremy Higgs wrote:
OK... How come they aren't compliant? Sorry I haven't been keeping
up... I've started full-time work experience, and have uni starting
next week on top of that, so I've been very pre-occupied!
Since gramps seems to work fine, I can move
Yuck.. hmm Maybe if the purple were darker.
On Feb 28, 2004, at 10:25 AM, Max Horn wrote:
Update of /cvsroot/fink/web
In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv29389
Modified Files:
fink.css
Log Message:
new color scheme (looks IMO better, but taste will vary :-) this is by
no
gnome-python and hence, gramps need to be removed from stable since
they aren't compliant with the python policy. The versions in unstable;
gramps, gnome-python2, pytgtk2-py23, pygtk2-py22 need to be moved to
stable. I have good reports from gramps users which depends heavily on
the pygtk and
Why warn at runtime? It doesn't hurt users. It is no big deal, just
more SPAM. Put the warning in the validation.pm.
-Ben
On Feb 24, 2004, at 1:49 AM, Daniel Macks wrote:
I just converted all the .info files in the 10.2-gcc3.3 and 10.3 trees
and enabled a warning (during indexing) about the
On Feb 14, 2004, at 11:49 PM, Remi Mommsen wrote:
I don't know how you count, but I see 149 patch files in 10.2-gcc3.3
and 10.3 (both stable and unstable) which are above 30k.
Sounds pretty low to me... under 1 percent since you're counting most
packages 2 or even 3 times. (so you're counting
On Feb 15, 2004, at 1:06 PM, Remi Mommsen wrote:
How many *packages* is it? (stick to ONE tree)
Why? If these packages need to be changed, you have to fix/test 149 of
them. Some might be easy as they are identical in all 4 trees, others
have maybe 4 different versions. IMO it doesn't matter
Packages submitted to the tracker should be rejected if the .patch
files are not in unified diff format. That's our standard.
-Ben
On Feb 13, 2004, at 12:29 PM, Daniel Macks wrote:
That appears to be some hard-coded /sw. I don't think the validator
catches it, however...whoever wrote the check
On Feb 12, 2004, at 9:09 PM, Daniel Macks wrote:
The DescDetail is one giant line, so it looks like crap on plain-text
displays. A couple of weeks ago I added a validator warning for this a
couple of weeks ago, but I don't think it's gotten into a fink-release
yet.
All desc fields should be hard
I disagree. We should not accept patches this big in fink. As pogma
said, please make it a tar.gz and put it on a web site. If you don't
have one, we do.
I don't think we should commit patches over 30k. In fact fink should
reject such patch files.
Please submit a revision to this package
On Feb 14, 2004, at 5:20 PM, Remi Mommsen wrote:
That should read of course be a limit of 300k for patches. If you
really impose a limit on 30k the list would be too long to be sent
here (-:
No, it shouldnt be 300k. 30k is quite reasonable, even generous. Doing
some quick lists i don't see
On Feb 10, 2004, at 7:39 AM, Benjamin Reed wrote:
Peter ran into a problem where apt is installing perl 5.6 modules
because it doesn't think that perl581-core is there, even though
fink-virtual-provides says it is.
it appears that somehow fink is not showing the Provides: of virtuals
as being
On Feb 5, 2004, at 11:17 AM, David R. Morrison wrote:
Keith Conger [EMAIL PROTECTED] wrote:
+Source-MD5: 7285d5f792966b563519996ea3af58d5
ConfigureParams: --mandir='${prefix}/share/man'
-InstallScript:
- make install prefix=%i
- mkdir -p %i/lib/perl5/XML/Parser/Style
- cp
On Feb 6, 2004, at 7:27 PM, Ben Hines wrote:
LC_ALL=C ../intltool-merge ../po database-properties.desktop.in
database-properties.desktop -d -u -c ../po/.intltool-merge-cache
The OrigTree module doesn't seem to be properly installed
.../intltool-merge
make[1]: *** [database-properties.desktop
I added some 'groups' to the fink package submission tracker. Please
set the field when you modify a submission tracker item. It will let us
track the state of the tracker easier by allowing people to see which
items have not been touched.
All 'open' items with group 'Undergoing Validation'
On Jan 25, 2004, at 4:59 PM, David R. Morrison wrote:
OK, I suppose this is going to be controversial. Any discussion?
Fine by me, as long as we stick to open source applications ONLY. The
objection about 'moving apps around' never did make sense to me, i
think a more important objection
On Jan 21, 2004, at 11:49 PM, Alexander Strange wrote:
install -d -m 755 %d`%p/bin/xfontpath basedir`/freefont
install -c -m 644 * %d`%p/bin/xfontpath basedir`/freefont
I don't think this is legal.. it will make different .debs for
different people. It'll be luck of the draw to
On Jan 13, 2004, at 5:39 PM, Keith Conger wrote:
Hi,
This is unstable.
You are right, it is unstable tree. But you miss my point. People on
the list (Martin in this case) just tell users to remove things first,
and i see no evidence that anyone even considered this to be a problem.
It *IS*
On Jan 13, 2004, at 8:29 PM, Peter O'Gorman wrote:
perl -pi -e 's/hardcode_direct=yes/hardcode_direct=no/g' configure
Will also often fix this. You may need to do hardcode_direct_CXX too
if the
build uses c++.
Aha, you're right, that does fix it. I rememeber that now... Kieth
that is the
On Jan 13, 2004, at 8:18 AM, Finlay Dobbie wrote:
I am no longer maintaining passwd, and it looks like this is a problem
in the apt-get package depending on an old version anyway.
We fixed that (long ago) by removing the postfix user from the newest
passwd version. In stable, too I believe.
On Jan 13, 2004, at 4:32 PM, Ben Hines wrote:
On Jan 12, 2004, at 11:40 PM, Martin Costabel wrote:
Ben Hines wrote:
[]
ld: Undefined symbols:
_rsvg_set_default_dpi
This one has been answered many times (see also the post
fink-gnome-core black hole to fink-devel). You need to remove the
old
On Jan 12, 2004, at 6:23 PM, Koen van der Drift wrote:
Any ideas how to fix this?
Try adding -lcsirocsa -lcsironn to your libraries (LIBS or LDFLAGS if
LIBS fails) Make sure they come after the -L../../src/.libs -lplplotd
-Ben
---
This
On Jan 12, 2004, at 3:23 PM, Carsten Klapp wrote:
(For example, do we really need separate binaries for all those
perlmod versions? I thought we should only have two: 5.6.0+, or
earlier. Is there again ANOTHER perl binary incompatibility between
5.6.0 and 5.6.1? etc. Once again, I have had
On Jan 12, 2004, at 7:34 PM, Koen van der Drift wrote:
Try adding -lcsirocsa -lcsironn to your libraries (LIBS or LDFLAGS if
LIBS fails) Make sure they come after the -L../../src/.libs -lplplotd
How do I make sure they come after the -L../../src/.libs -lplplotd (if
that is what I did wrong)?
On Jan 9, 2004, at 10:16 AM, Martin Costabel wrote:
The install script for freetype2 moves lib/libfreetype.la into a
lib/freetype2/ directory, but that doesn't get installed from %i into
%p so there appears to be a problem with that package.
It gets installed into %p when you install the
This could be easily tested with a disk image, for example. Mount a
read/write disk image, get info, choose 'ignore permissions' (looks
like it is default) and try to install fink. It does indeed fail:
This first test is designed to die, so please ignore the error
message on the next line.
#
If there is anything we don't need it is to slow down indexing. I don't
care how much cleaner it makes the code, we need to index constantly.
It needs to be fast.
-Ben
On Jan 11, 2004, at 2:22 PM, Daniel Macks wrote:
Switch to an object-oriented and consistent way of handling source
tarballs.
Fink should be able to realize what this is:
WARNING: Unable to parse the line libbonobo2.info in
/sw/fink/dists/unstable/main/finkinfo/gnome/libbonobo2.info.
WARNING: Unable to parse the line === in
/sw/fink/dists/unstable/main/finkinfo/gnome/libbonobo2.info.
WARNING: Unable to parse the
On Jan 10, 2004, at 12:05 PM, Remi Mommsen wrote:
I need to explicitly pick the pm581 modules to make it work.
I'm not sure about the versioned perl modules business. I guess that
all versioned perl modules must depend explicitly on versioned perl
modules. But why do we need the placeholders
On Jan 8, 2004, at 7:24 PM, Max Horn wrote:
We can't get anything into 0.6.2 - that's a fixed release :-).
Not totally correct as you know, we do have an 'current' dir which we
can throw packages into which point release stable users can access.
For occasionally totally broken packages such as
On Dec 31, 2003, at 9:32 PM, Max Horn wrote:
What I find interesting about this is that we are apparently so close
in some regards, Ben... I am too lazy to search through the trackers,
but I think I could easily find similar examples quoting *you*... :-).
I certainly would admit it agree with
libgnugetopt dependencirs are never needed on 10.3... the missing
getopt functions were added to libsystem. Just remove all gnugetopt
deps completely! It will work fine.
-Ben
On Jan 1, 2004, at 3:21 AM, Matthias Neeracher wrote:
Update of /cvsroot/fink/dists/10.3/unstable/main/finkinfo/games
This is interesting.
I used a test package that was Type: nosource and fink rebuild baz
baz-shlibs 'compiles' baz twice no matter the order. Is your foo test
package Type nosource?
When i added a source tarball, it only builds once.
-Ben
On Jan 1, 2004, at 5:48 PM, Koen van der Drift wrote:
Ok, yeah, I can reproduce it with my test package after i remove.. it
appears it only happens if a package is NOT installed and is rebuilt.
Source line does not matter.
-Ben
On Jan 1, 2004, at 8:12 PM, Koen van der Drift wrote:
No, I don't use that field. I'll try to find an existing package
Still occurs with cvs. Note that the parent does not depend on the
-shlibs in my test package.
I think this might be a very old bug from max. (fix at bottom)
Here is the pkg, fink remove them all then do 'fink rebuild baz
baz-blammo
Package: baz
Version: 2.1
Revision: 11
#Depends: %N-blammo,
On Dec 31, 2003, at 12:32 PM, Max Horn wrote:
Am 31.12.2003 um 21:00 schrieb Martin Costabel:
Ben Hines wrote:
On Dec 22, 2003, at 4:50 AM, Martin Costabel wrote:
[]
I am dreaming of a mechanism that would remove a BuilDependsOnly
package immediately after it is used. This would not only solve
On Dec 31, 2003, at 1:21 PM, Ben Hines wrote:
I have been thinking about this some more, and I would now like to
propose this seriously as a solution for several problems that were
biting us recently. The more I think about it, the more it seems to
me that we will *have to* do this.
Here
, some wouldn't be bothered at all, and the
large center ground would simply read it and say 'that guy was a bit
harsh eh? He was just making a proposal'
Hm, in the light of what Ben Hines that (namely that for 'developers',
one can 'hold' packages), does that mean that we essential will start
On Dec 26, 2003, at 5:31 AM, Koen van der Drift wrote:
That's weird though, if I don't use the SetLDFLAGS: -lstdc++ line, I
get the c++ error during compilation
ld: Undefined symbols:
std::ios_base::Init::Init[in-charge]()
std::ios_base::Init::~Init[in-charge]()
std::cerr
.
Because its
Why not use the new info file name format?
it sure helps to track changes.
-Ben
On Dec 24, 2003, at 12:38 PM, David R. Morrison wrote:
Update of /cvsroot/fink/dists/10.2-gcc3.3/unstable/main/finkinfo/base
In directory sc8-pr-cvs1:/tmp/cvs-serv2951
Added Files:
fink-0.17.3-1.info
On Dec 22, 2003, at 4:50 AM, Martin Costabel wrote:
Solutions: Either one allows gettext-dev to Depend on libiconv-dev
(but this not only violates policy but may also break bootstrapping,
because gettext-dev might be needed before libiconv is built), or all
packages that are susceptible to be
On Dec 11, 2003, at 5:38 AM, David R. Morrison wrote:
The obvious solution to this problem would be to use versioned Provides
statements. That is, if you installed perl581 (or the virtual
system-perl581),
you would get
You seem to misunderstand my issue. We already have versioned provides.
Yes, it does check that on the deb file, but most folks probably don't
realize that deb files can be validated. Its also easy to miss changes
when updating packages.
btw:
main/finkinfo/libs 166 % fink validate libfinch0.info
Validating package file libfinch0.info...
Warning: Field files of
On Dec 24, 2003, at 9:37 PM, David R. Morrison wrote:
My belief is that the Provides line is not enough to satisfy dpkg.
Certainly that was true in the early days of fink. It's possible that
it has changed, and that I haven't kept up with dpkg's capabilities.
I'm not talking about adding
Looks like its not clearing out the index again.
% ./inject.pl
sudo ./inject.pl /sw
Password:
Creating fink tarball...
tar -cf /sw/src/fink-0.17.2.cvs.tar COPYING INSTALL INSTALL.html README
README.html USAGE USAGE.html Makefile ChangeLog VERSION fink.in
fink.8.in fink.conf.5.in install.sh
Ah, nevermind, looks like the fink VERSION file simply wasn't updated
to .3 in CVS.
-Ben
On Dec 24, 2003, at 10:38 PM, Ben Hines wrote:
Looks like its not clearing out the index again.
% ./inject.pl
sudo ./inject.pl /sw
Password:
Creating fink tarball...
tar -cf /sw/src/fink-0.17.2.cvs.tar
Thats it right there.
-Ben
On Dec 19, 2003, at 4:27 PM, Remi Mommsen wrote:
../10.3/stable/main/finkinfo/database/mysql.info
../10.3/stable/main/finkinfo/database/mysql.patch
../10.3/unstable/main/finkinfo/database/mysql.info
../10.3/unstable/main/finkinfo/database/mysql.patch
On Dec 15, 2003, at 6:24 AM, Peter O'Gorman wrote:
Things should not be depending on python, they ought to depend on the
specific version of python that they require, if the package is indeed
So what then is the 'python' splitoff for?
-Ben
On Dec 12, 2003, at 7:28 AM, Charles Lepple wrote:
Of course, this would require a little more advocacy of
popularity-contest, besides any changes to the inner workings of the
code..
I like popularity-contest, however it currently requires an MTA running
locally to submit results. If somone
On Dec 9, 2003, at 2:44 PM, Max Horn wrote:
Why was this done? Why not netpbm10-bin, which then Provides:
netpbm-bin ?
I agree, and was complaining about this the other day. Identically
named packages should be illegal.
'python' has a similar problem. If a user with python21 installs a
Feel free to submit a fink package to the submission tracker at:
http://sourceforge.net/tracker/?atid=414256group_id=17203
The .info file format is very easy. You can find examples in
/sw/fink/dists/unstable/main/finkinfo/
I know that Chris Z was working on one previously..
-Ben
On Dec 11,
I moved this to the 10.3/unstable tree today.
-Ben
On Nov 3, 2003, at 9:21 AM, Kirk R. Wythers wrote:
I have just moved from FreeBSD to OSX and want to get grass running.
Can anyone give me quick rundown on the status of grass on fink? Who
is the maintainer? Where did it go (seems like a
Since you've removed the system-perl packages, we're going to have to
add all the Provided: perl modules to fink's virtual packages system,
provided by those, hard coding the perl version into fink (or, maybe
just looking up the perl modules dynamically?... that'd be slick).
I had already
On Dec 10, 2003, at 8:10 AM, Benjamin Reed wrote:
'popt' contains i18n data, so it can't be BuildDependsOnly
I believe that lots of BuildDependsOnly (header) packages contain i18n
data. Do things actually fail at runtime due to this?
-Ben
On Dec 8, 2003, at 10:57 PM, D. Höhn wrote:
Geezes you people are picky ;)
I will remove the data contained in teh two mentioned flders so that
it
does not have to be checked anymore better? ;)
see yas
Yes i still use phpmyadmin. Leave them.
-Ben
On Dec 8, 2003, at 9:45 PM, Hisashi T Fujinaka wrote:
Actually, the maintainer removed them. I'll put them back.
No, he didn't remove them, they were added by someone else, and he
didn't notice.
-Ben
---
This SF.net email is sponsored by:
On Dec 8, 2003, at 11:11 PM, Ben Hines wrote:
On Dec 8, 2003, at 10:57 PM, D. Höhn wrote:
Geezes you people are picky ;)
I will remove the data contained in teh two mentioned flders so that
it
does not have to be checked anymore better? ;)
see yas
Yes i still use phpmyadmin. Leave them
On Dec 4, 2003, at 1:36 PM, TheSin wrote:
Already stated I will no longer work be working on fink's code base
unless it's to fix something that I created. Sorry to try and advance
fink instead of complaining yet again about something that has been
discuss a dozen times already.
Aw cmon don't
On Dec 2, 2003, at 3:29 PM, Dave Vasilevsky wrote:
3. Calls the utility program rmorphans2 to remove all the packages
that were only installed as a [Build]Depend, but that I don't want
kept.
This would be a really nice feature to have implemented directly in
fink.
-Ben
That sentence makes no sense
-Ben
On Dec 2, 2003, at 8:45 PM, TheSin wrote:
it's not dia isn't libunicode-gnome, I've already posted this to
fink-devel...
---
TS
http://southofheaven.org
Chaos is the beginning and end, try dealing with the rest.
On 2-Dec-03, at 9:17 PM, Ben Hines wrote
it is good to work in CVS. But for major dep engine changes you might
want to work in a 'branch' instead, not HEAD.
-Ben
On Dec 2, 2003, at 7:22 PM, TheSin wrote:
I'm just gonna do it steps, first I need BuildConflicts, which I just
added, now I'm gonna add the transparent check before every
1 - 100 of 472 matches
Mail list logo
