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 wrote:
> Hi Ben, hi fink-deve
i'll go ahead 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 i
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
I got this:
http://www.mail-archive.com/fink-beginners@lists.sourceforge.net/
msg16247.html
Looks like the bug is that pm581's wont compile if you have perl560-
core installed at the same time as perl581-core. Perl5.8.1 is using
perl560's makemaker.
The pm560 package isn't there anymore
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
se
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 (lengt
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 n
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 "
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 this
so I 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
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
br
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
perl5.8.4-core does not install /sw/bin/perl, but its Config.pm has:
startperl='#!/sw/bin/perl'. This messes up my help2man package. I tell
it PERL is /sw/bin/perl5.8.4 but then it asks for $Config{startperl}
and perl says /sw/bin/perl. So it no work. I want it to use fink perl
if its there.
S
es more sense to be, since 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-shlib
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 and
case,
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
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 n
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'
upd
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 li
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.
How can I check in my package the version of MacOSX before compiling ?
There is no such thing as libm on any OS X. libm is just a s
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 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
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
Index
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 s
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 successful
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?
phpLang=en#sharedl
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
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 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
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 this
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:
Sing
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:
http://fink.sourceforge.n
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 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",
espe
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 s
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
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
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 p
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
On Apr 17, 2004, at 6:14 PM, Remi Mommsen wrote:
Maintainer: Univ. of Tokyo Educational Computing System Tutors
<[EMAIL PROTECTED]>
I do not like this at all. If the package was made by Asari Takashi,
IMO he should be the maintainer. Group maintainers are bad. Research
shows that people are les
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
such...
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 11:57 PM, Ben Hines wrote:
Aha.. i can 'chgrp scribia' and 'chgrp finkcommander' but not 'fink'.
I am an admin on scribia and FC. Looks like only project admins can
chgrp now to their group.
https://sourceforge.net/tracker/index.php?
fun
On Feb 28, 2004, at 11:44 PM, Ben Hines wrote:
pdb/update.sh does not appear to work. It's not letting me chgrp
anything. Everything in 10.3.../gnome is now in the users group owned
by me. 'chown' is not working either, for that matter.
chgrp: changing group of
`./fink/10.
On Feb 28, 2004, at 10:16 AM, Max Horn wrote:
To that end, we have "update.sh" scripts in our main CVS checkout dirs:
/home/users/f/fi/fingolfin/fink/pdb/update.sh
/home/users/f/fi/fingolfin/fink/htdocs/update.sh
These scripts will automatically perform a CVS update, and then
afterwards corre
On Feb 28, 2004, at 10:23 AM, Remi Mommsen wrote:
Hi,
I would like to sync the root3 package in unstable with the stable
tree. It has some (minor) bug fixes which would be nice to have in the
upcoming binary release. However, the root3 package conflicts/replaces
the root4 package which will st
hope) versions. Who knows why I
didn't transfer them across..
Looking back in the CVS commits, gnome-python-1.4.2-1.info was removed
in late October last year (27/10, my time)... gnome-python-py23 was
also added on the 3rd November to the 10.3 tree by Ben Hines, and I've
edited it a c
On Feb 28, 2004, at 6:41 PM, Jeremy Higgs wrote:
On 29 Feb 2004, at 13:12, Ben Hines wrote:
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
n
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 means
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 gnome-pyt
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 g
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 now
On Feb 15, 2004, at 1:56 PM, David R. Morrison wrote:
So I tend to agree with Remi that, given the patches which already
exist,
something like 300K is probably a more reasonable cutoff than 30K.
Or maybe something in between, like 100K?
Why? You're being 'arbitrary' again. :) I based my number o
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 what
, and all patches should be necessary (no accidental patching of backup files, no patching of .am files uncessarily)
-Ben
Begin forwarded message:
From: Ben Hines <[EMAIL PROTECTED]>
Date: May 31, 2003 1:04:34 PM PDT
To: mathias meyer <[EMAIL PROTECTED]>
Cc: [EMAIL PROTECTED]
Sub
Uh, That is only two. apache and webmin. You counted webmin twice and 6
versions of apache2.
A 'few' generally means more than two.
There is no such guideline for info files since it generally is not
needed. patch files are much easier to balloon up in size. In any case
you should not put uneed
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 w
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 man
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 which
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 w
This is a very bad policy, since you may not be aware of possible
changes to fink which may break your packages or users' systems. They
should be filtered through a developer before being used by users IMO.
Anyway, it looks like pogma gave you cvs commit access, so please
commit your packages a
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 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 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.de
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 %i/share/intltool/X
On Feb 3, 2004, at 2:38 PM, Daniel Macks wrote:
On Tue, Feb 03, 2004 at 09:57:42PM +0100, Max Horn wrote:
Daniel E. Macks wrote:
Okay, what's the situation with indexing? In the past 10 minutes
it's gone from 270ish to 540ish.
As I stated in my reply, reindexing only takes 10-20 seconds (at
least
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' hav
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 i
On Jan 8, 2004, at 1:12 PM, Martin Costabel wrote:
If you take over a tracker item so that it is waiting for further
input, change its status from "Open" to "Pending". It is possible to
display only those packages that are "Pending", or those that are
"Open". The latter would then be those that
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 18, 2004, at 12:39 PM, David R. Morrison wrote:
The solution would be to still parse %n and generate a big fat warning
instead of fink dying.
I still disagree with this 'fix' by dmacks. There is no reason for fink
to die or warn at all. The old behavior was harmless, and was
explicitly co
On Jan 14, 2004, at 10:55 PM, D. Höhn wrote:
I doubt that this kind of rather unprofessional and almost personal
course of action will "spur some action". While I commend you for
pointing out, that fink is not near "perfect" yet, I hope that it is
It absolutely worked. And most of the dev team app
On Jan 15, 2004, at 3:51 AM, Max Horn wrote:
And I would like to add that I never saw a discussion, or at least a
formal announcement for this new CVS dir on fink-devel. . I am
sick of having to request this over and over again. Please please
folks, when you do major changes in CVS (and that in
On Jan 14, 2004, at 2:01 AM, Martin Costabel wrote:
If you get so excited about this workaround instead of a real fix, you
might want to go over the Fink FAQ. I would say that at least half of
its entries are due to behavior that could be classified as bugs, like
fink always wanting to install
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 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 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 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 remov
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 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 litt
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 SF
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.
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.
# L
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 freetyp
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 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 (u
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
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,
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
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:
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
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
re is obviously a middle ground, not all people are so easily
offended and set off as I am, 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 Hin
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 is
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 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 linkin
On Dec 25, 2003, at 2:18 PM, Koen van der Drift wrote:
But usally you'd want to be linking with "g++" instead of "gcc" to
fix the c++ link problem.
Actually, I only need SetLDFLAGS: -lstdc++.
Again the proper fix is to use "g++" as your linker. Adding the
-lstdc++ is the incorrect fix.
-Ben
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.cv
1 - 100 of 619 matches
Mail list logo
