Re: [Fink-devel] finlayd-cache merges into HEAD

2002-03-31 Thread Finlay Dobbie
On Sunday, March 31, 2002, at 07:09 PM, Benjamin Reed wrote: Max Horn [[EMAIL PROTECTED]] wrote: I just merged Finlay's cacheing code into HEAD CVS. For me it causea quite a speed boost, from 10-80 secs down to 2-8 secs. Please give it a try, we need some testing before we can put it into a

Re: [Fink-devel] finlayd-cache merges into HEAD

2002-03-31 Thread Max Horn
At 19:28 Uhr +0100 31.03.2002, Finlay Dobbie wrote: On Sunday, March 31, 2002, at 07:19 PM, Max Horn wrote: Thanks, I somehow thought that somebody had tested this *cough* :-) I'll look into fixing this. I did too :-/ I *swear* I fixed this. Oh, well. No worries. Fixed in CVS (I hope :-)

Re: [Fink-devel] dirent.h

2002-03-31 Thread Martin Costabel
Yves de Champlain wrote: Hi I'm getting these errors and I can't figure out what the problem is /usr/include/sys/dirent.h:73: parse error before `u_int32_t' /usr/include/sys/dirent.h:73: warning: no semicolon at end of struct or union Usually a missing #include sys/types.h --

Re: [Fink-devel] dirent.h

2002-03-31 Thread Max Horn
At 22:58 Uhr +0200 31.03.2002, Martin Costabel wrote: Yves de Champlain wrote: Hi I'm getting these errors and I can't figure out what the problem is /usr/include/sys/dirent.h:73: parse error before `u_int32_t' /usr/include/sys/dirent.h:73: warning: no semicolon at end of struct or

Re: [Fink-devel] finlayd-cache merges into HEAD

2002-03-31 Thread Finlay Dobbie
On Sunday, March 31, 2002, at 07:19 PM, Max Horn wrote: Thanks, I somehow thought that somebody had tested this *cough* :-) I'll look into fixing this. I did too :-/ I *swear* I fixed this. Oh, well. -- Finlay ___ Fink-devel mailing list

Re: [Fink-devel] dirent.h

2002-03-31 Thread Dan Winship
Usually a missing #include sys/types.h Martin is right, just to clarify this: it's a bug in OS X's version of dirent.h, rather in the software with that problem. We have to fix it in a quite a lot of pacakges. Couldn't we create /sw/include/dirent.h that just did #include sys/types.h

[Fink-devel] implicit declaration of function `int localtime_r(...)'

2002-03-31 Thread Chris Zubrzycki
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 hmm...I dont understand this error very well (for licq): /sw/include -c `test -f countrycodes.c || echo './'`countrycodes.c source='log.cpp' object='log.o' libtool=no \ depfile='.deps/log.Po' tmpdepfile='.deps/log.TPo' \ depmode=gcc /bin/sh

Re: [Fink-devel] Fwd: [Licq-devel] Porting licq problems

2002-03-31 Thread Max Horn
Did you try this with the sed package installed? If that helps, you could BuildDepend on sed. I think I saw this before, but I forgot the resolution :-/ Max -- --- Max Horn Software Developer email: mailto:[EMAIL PROTECTED] phone: (+49)

Re: [Fink-devel] implicit declaration of function `intlocaltime_r(...)'

2002-03-31 Thread Max Horn
There is no localtime_r in Mac OS X / Darwin. You will have to provide your own implementation. For an example look at gal19-0.19-1.patch Cheers, Max -- --- Max Horn Software Developer email: mailto:[EMAIL PROTECTED] phone: (+49) 6151-494890

Re: [Fink-devel] Fwd: [Licq-devel] Porting licq problems

2002-03-31 Thread Ben Hines
At 2:44 AM +0200 4/1/02, Max Horn wrote: Did you try this with the sed package installed? If that helps, you could BuildDepend on sed. I think I saw this before, but I forgot the resolution :-/ Yep. I had this problem with normalize just yesterday - It is apparently a side effect of the fact

[Fink-devel] directories in Docs

2002-03-31 Thread Chris Zubrzycki
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Why does fink complain if I want to include a whole folder, say upgrading in the DocFiles? Co we allow this, and Maybe have the default not allow dirs, but include a boolean AllowDocDirs: true in the info file? licq has docs in ./, docs, and

[Fink-devel] the stable tree and a new release

2002-03-31 Thread David R. Morrison
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)