--- Log opened Tue Sep 20 00:00:05 2005
00:06:00-!- shreyas_ [n=sshreyas@59.92.150.54] has joined #fink
00:07:23< dmacks> Anyone know anything about braille devices under OS X?
00:08:53-!- og [i=oyving@saminga.uninett.no] has quit [Remote closed the connection]
00:09:05-!- og [i=oyving@saminga.uninett.no] has joined #fink
00:09:18< pogma> not a clue
00:18:12-!- shreyas [n=sshreyas@59.92.136.154] has quit [Read error: 110 (Connection timed out)]
00:33:48-!- kane_ [n=kane@perl.xs4all.nl] has joined #fink
00:40:25-!- asari [n=asari@p1062-ipbf21marunouchi.tokyo.ocn.ne.jp] has joined #Fink
00:54:08-!- dmacks [n=dmacks@pdpc/supporter/active/dmacks] has quit ["leaving"]
01:03:37-!- eno-away [n=eno-away@adsl-216-100-132-251.dsl.snfc21.pacbell.net] has quit [Read error: 110 (Connection timed out)]
01:08:01-!- shreyas_ [n=sshreyas@59.92.150.54] has quit [Read error: 104 (Connection reset by peer)]
01:21:49-!- sugoi [n=Asian@71-178.69-92-cpe.cableone.net] has joined #fink
01:24:14< sugoi> can i set in my .initrc (such as bashrc for example) mappings to keys like home, end, and delete(remove proceding char)"
01:24:21< sugoi> isnt there some command like stty
01:29:39-!- RLD_osx_ [n=rldempse@66-190-76-181.dhcp.dntn.tx.charter.com] has joined #fink
01:29:51-!- RLD_osx [n=rldempse@66-190-76-181.dhcp.dntn.tx.charter.com] has quit [Nick collision from services.]
01:30:10-!- RLD_osx_ is now known as RLD_osx
01:30:11-!- lisppaste [n=lisppast@common-lisp.net] has quit ["Common Lisp IRC library - http://common-lisp.net/project/cl-irc"]
01:30:19-!- lisppaste [n=lisppast@common-lisp.net] has joined #fink
01:31:52-!- asari [n=asari@p1062-ipbf21marunouchi.tokyo.ocn.ne.jp] has quit ["Quitting!"]
01:34:47< brendan> man bash, /READLINE
01:35:48-!- RLD_osx [n=rldempse@66-190-76-181.dhcp.dntn.tx.charter.com] has quit []
01:38:35-!- robval [n=Robert@nat.packetfront.com] has joined #fink
01:41:35-!- nkuttler [n=nkuttler@dsl-084-058-197-058.arcor-ip.net] has joined #fink
01:42:13< sugoi> brendan: cool
01:42:18< sugoi> thanks=)
01:42:22< brendan> :)
01:43:35-!- RLD_osx_ [n=rldempse@66-190-76-181.dhcp.dntn.tx.charter.com] has joined #fink
01:44:30-!- RLD_osx_ is now known as RLD_osx
01:48:14-!- zecke [n=ich@rosine173.inf.fu-berlin.de] has joined #fink
01:52:24-!- shres [n=sshreyas@202.144.95.244] has joined #fink
01:54:26< sugoi> ha!
01:54:26< sugoi> it worked
01:54:30< sugoi> ...for del at lesat
01:54:34< sugoi> now for home and end
01:54:34< sugoi> =)
01:55:36< sugoi> HA
01:55:38< sugoi> it worked
01:55:45< sugoi> brendan: thanx a million =D
01:56:26< brendan> wow, usually people hate it when you say RTFM :)
01:57:11< sugoi> no no
01:57:20< sugoi> i ask when i have no idea where to look
01:57:25< sugoi> i have nothing against reading
01:57:29-!- robval [n=Robert@nat.packetfront.com] has left #fink []
01:58:04< sugoi> though, when using pico for example, these nice bindings i just added to my .inputrc aren't used =(
01:58:09< sugoi> just bash uses them
01:58:18< brendan> stty does work for some of that stuff (like delete)
01:58:47< sugoi> ok, man stty seems to have that information
01:58:54< brendan> don't think it does home though
01:59:03< sugoi> hmm
01:59:12< brendan> pico probably uses standard emacs keys (^A, ^E)
01:59:27< brendan> or maybe not. I can't remember the last time I touched pico
02:00:10< sugoi> it does
02:05:03-!- chris01 [n=chris01@212.126.165.246] has joined #fink
02:07:09-!- beniamino__ [n=ben@adsl-64-164-10-189.dsl.snfc21.pacbell.net] has quit ["This computer has gone to sleep"]
02:27:33-!- zecke [n=ich@rosine173.inf.fu-berlin.de] has quit [Read error: 110 (Connection timed out)]
02:43:51-!- eno-away [n=eno-away@adsl-67-127-69-49.dsl.snfc21.pacbell.net] has joined #fink
03:17:29-!- BleedAway [i=whocares@saus04.usc.es] has quit ["changing servers"]
03:18:05-!- BleedAway [i=whocares@saus04.usc.es] has joined #fink
03:49:29-!- og [i=oyving@saminga.uninett.no] has left #fink []
04:03:28-!- zecke [n=ich@rosine87.inf.fu-berlin.de] has joined #fink
04:09:07-!- asari [n=asari@newsodan.sodan.ecc.u-tokyo.ac.jp] has joined #Fink
04:09:22-!- asari [n=asari@newsodan.sodan.ecc.u-tokyo.ac.jp] has quit ["Quitting!"]
04:09:54-!- sid77 [n=sid77@host-84-222-62-128.cust-adsl.tiscali.it] has joined #fink
04:14:05-!- asari [n=ASARI@gw08.ecc.u-tokyo.ac.jp] has joined #Fink
04:15:56-!- RLD_osx [n=rldempse@66-190-76-181.dhcp.dntn.tx.charter.com] has quit [Read error: 104 (Connection reset by peer)]
04:35:14-!- zecke [n=ich@rosine87.inf.fu-berlin.de] has quit [Read error: 110 (Connection timed out)]
05:30:05-!- lisppaste [n=lisppast@common-lisp.net] has quit ["Common Lisp IRC library - http://common-lisp.net/project/cl-irc"]
05:30:12-!- lisppaste [n=lisppast@common-lisp.net] has joined #fink
05:32:02-!- sid77 [n=sid77@host-84-222-62-128.cust-adsl.tiscali.it] has quit ["http://slackintosh.workaround.ch/"]
05:56:04-!- chris01 [n=chris01@212.126.165.246] has quit ["bye"]
05:59:17-!- sid77 [n=sid77@host-84-222-62-128.cust-adsl.tiscali.it] has joined #fink
06:24:42< shres> hey, are there any problems with binaries built on 10.4.2 not running on 10.3.9. When i run them it spews undefined symbol statvfs. Isnt that in libc all the while ?
06:25:15< newmanbe> I'd imagine there would be problems trying to do that.
06:25:26< shres> hmmm.. why ?
06:26:15< shres> its c code, built using gcc-4
06:26:32< newmanbe> Mac OS X 10.4.2 uses gcc4 as opposed to Mac OS X 10.3 using gcc3.
06:26:47< shres> i would understand if it was c++ but should not matter for c code
06:27:23 * newmanbe shrugs/
06:27:35< shres> and it shouldnt crib about non presence of statvfs anyway. why cant it resolve that symbol
06:27:36< newmanbe> s/\///
06:34:48< shres> unbelievable, my libc.dylib does not have statvfs on 10.3.9. Is this normal ?
06:35:41< newmanbe> No idea.
07:04:01-!- taf2_ [n=chatzill@pcp0011023265pcs.arlngt01.va.comcast.net] has quit [Read error: 110 (Connection timed out)]
07:05:41-!- akh [n=akhansen@ldx3.psfc.mit.edu] has joined #fink
07:17:48-!- sid77 [n=sid77@host-84-222-62-128.cust-adsl.tiscali.it] has quit ["http://slackintosh.workaround.ch/"]
07:18:24-!- sid77 [n=sid77@host-84-222-62-128.cust-adsl.tiscali.it] has joined #fink
07:35:30-!- rajesh [n=rajesh@38.112.8.74] has joined #fink
07:43:48-!- taf2_ [n=chatzill@65.207.103.51] has joined #fink
08:07:16< shres> ok kinda, stupid question but here goes anyway, can i run panther on a g5 ?
08:07:57< akh> I believe so.
08:08:27< akh> (though since I don't have one, I can't say definitively)
08:11:58< pogma> was the g5 released before or after tiger?
08:12:40< akh> I believe before.
08:12:52< akh> (as a concept; not the particular one in question, as I don't know that)
08:13:30< shres> hmm.. ok. You guys maintain two binary trees for 10.3 and 10.4 ?
08:13:34< akh> Yes.
08:14:41< shres> isnt what's buillt on 10.3 executable on 10.4 ?
08:15:08< pogma> hehe
08:15:08< pogma> try it
08:15:20< akh> _Some_ things work.
08:15:21< pogma> it will mostly work, 'tis true
08:16:30< pogma> we keep hoping, one of these releases, that there will be no need to have a new tree
08:17:01< shres> i am in a terrible fix, i was getting ready to release evo-2.4 packages only to dicover the libc on 10.3 doesnt have statvfs. Oh its such a lovely surprise 
08:18:00< akh> Ouch.
08:18:36< shres> and i dont have a 10.3 cd, hehe i need a drink
08:21:10-!- chris01 [n=chris01@84-73-56-45.dclient.hispeed.ch] has joined #fink
08:21:12< pogma> what does it use statvbs for?
08:21:35 * akh gets depressed because people in other timezones can have a drink, while I'm just starting my work day.
08:21:47< akh> ;-)
08:22:05< shres> akh: heh, the fridge is right next to me and the drapes are closed and the watch can be fixed :-)
08:22:13< akh> Ah.
08:22:19< shres> pogma: some glib code uses it i suppose
08:22:43< pogma> manpage says -> The statvfs() and fstatvfs() functions are implemented as wrappers around
08:22:43< pogma>      the statfs() and fstatfs() functions
08:23:11< pogma> so, it shouldn't be too hard to find the implementation in darwinsource and copy it into a patch
08:23:47< pogma> 'cause 10.3 has statfs
08:27:39< shres> pogma: thats true, except for the fact that 10.4 libc has statvfs so the same binary would then show multiple symbol definition. So i have to make two binary releases anyway
08:28:21< shres> u meant patching evolution with the statvfs definition right ?
08:29:09< pogma> heh, you are making a binary that you want to use on both? I misunderstood
08:30:09< shres> yeah, actually abi word guys also do the same thing. One binary for both 10.3 and 10.4
08:30:28< pogma> you'll want to rebuild everything with the 10.3 sdk
08:30:46-!- asari [n=ASARI@gw08.ecc.u-tokyo.ac.jp] has quit ["Quitting!"]
08:30:57< pogma> or use weak linking
08:31:16< akh> This is exactly why we have separate trees.
08:31:35< shres> akh: i comprehend that, a bit late but i so do now 
08:32:09< akh> OTOH, to use anything via Fink, you have to install the whole infrastructure, which some people don't like to do.
08:32:24< shres> actually, i am planning to move all future evo releases to fink. This is an one off thing
08:32:47< shres> making binaries and releasing some mb's of tar balls is just painful
08:32:58< akh> I can imagine.
08:33:51< akh> IIRC, we aren't even going to try to use "Universal" binaries for the PPC -> Intel transition.
08:34:43< akh> (unlike a lot of people)
08:37:41< shres> interesting
08:38:30< shres> so, these library guys are damn efficient i got a 10.3 cd in half an hour. Wow i am impressed
08:38:34< akh> Nice.
08:38:43< pogma> plain old 10.3.0 ?
08:38:43< shres> now to see if it will install on my g5 
08:38:53< shres> yeah, which means tons of update downloading :(
08:38:53< pogma> that was before the g5 release, wasn't it?
08:39:11 * pogma crosses fingers for shres 
08:39:27 * shres prays for shres
08:39:32< akh> right--I thought the G5 came out somewhere in the middle of the 10.3 series.
08:39:35< akh> Maybe even at 10.3.5
08:39:47< pogma> yeah, so a 10.3.9 cd has a much better chance of working than a 10.3.0 one (is there a 10.3.9 cd?)
08:47:28< shres> *phew so it just hangs. Doesnt even go to the installation page :(
08:47:57< akh> I guess that saves time.
08:55:30-!- drm [n=drm@ip68-108-245-119.sb.sd.cox.net] has joined #fink
08:55:54< drm> RangerRick, you around?
08:59:18< RangerRick> drm: yeah, what's up?
09:00:37< drm> i'm wondering when/if qt3 is gonna stabalize...in my 10.4 experiments, i have to modify the package (building it with g++-4 instaed of g++-3) and i guess i'll want to freeze at some point
09:00:41< RangerRick> I believe it's solid now
09:00:52< drm> actually, i guess we could try building it with g++4 even in the 10.4T tree
09:01:16< RangerRick> it should, 3.3.5 had some gcc4 fixes I believe
09:01:17< drm> so far, my experiments say that you can build it with g++-4.0 but then use it with g++-3.3 with no apparent ill effects
09:01:22< RangerRick> wha??
09:01:28< RangerRick> how in the world would that work?
09:01:43< drm> i mean, compile kde with g++3.3 after compiling qt3 itself with g++-4.0
09:02:07< RangerRick> how did you compile qt3 with g++-4.0?  did you change the patch?
09:02:11< drm> yes
09:03:14< drm> if this doesn't work, then we're gonna either have to have two qt3's, or else hold all qt3-using pkgs at gcc 3.3 until they can be upgraded at once
09:03:29< RangerRick> wow, that just seems so unpossible  :)
09:04:04< drm> well, it compiled ok when i tried it (like a month ago)
09:04:24< RangerRick> I just have a hard time believing qt doesn't use anything that didn't change between gcc 3.1 ABI and gcc 4
09:04:27< drm> as you know, compiling kde is a long process, so i've been waiting a while to try again
09:05:09< drm> well, the symbols only get mangled differently if templates are involved, i believe
09:05:25< RangerRick> well, I was under the impression Qt had stuff for going from std::string to QString and such
09:05:47< drm> ok, i am rather ignorant about it
09:06:09< drm> i will try again, and keep some logs for people (like you) to look at if it works
09:06:13< RangerRick> well, maybe they don't use templates, that's something different
09:06:34< RangerRick> and we're not using exceptions in our Qt
09:06:42< RangerRick> so maybe it works
09:06:45< RangerRick> holy crap  :)
09:07:23< drm> actually, there have been several places where i've been able to successfully compile something with an old g++ that links to a lib compiled under g++-4.0... and a few other cases where that didn't work, due to symbol mangling
09:07:55< drm> when this works out, it sure makes the upgrade process easier
09:08:32< RangerRick> yeah
09:08:48< RangerRick> I'll send an e-mail to the qt list to see if anyone knows of any cases where this could blow up
09:08:54< drm> cool
09:09:01< chris01> hi drm
09:09:35< drm> (so far, i've managed to collect the stuff that won't be upgraded into small groups of related packages, at most a half dozen or so... but if this doesn't work with qt3, there will be a nightmare)
09:09:42< drm> hi chris01
09:09:45-!- beniamino__ [n=ben@adsl-64-164-10-189.dsl.snfc21.pacbell.net] has joined #fink
09:09:56< RangerRick> right
09:10:10< chris01> drm: i would like to move apr, apache2 and svn to stable, but need gettext3 in stable too. Could it be moved?
09:13:09< drm> chris01: we've been getting the occasional error report about gettext3 on fink-core...i'd like to track those down first
09:13:15< drm> but, pretty soon, i would think
09:13:33< chris01> ok. will wait patiently then. Thanks for the report.
09:14:14< drm> RangerRick: so will kde be ready for gcc 4.0 any time soon?
09:15:44< pogma> they blacklisted gcc-4.0
09:16:06< pogma> when apple's gcc is 4.0.1 then all will be well, maybe?
09:16:09< pogma> hi drm 
09:16:36< drm> hi pogma
09:17:14< drm> i've heard rumors that a new XCode release is being tested... perhaps that has 4.0.1
09:17:30< pogma> heh, I've heard rumors that it does :-p
09:17:47 * drm no longer has a ssed key, so is truly relying on rumors at this point :)
09:18:30< RangerRick> xcode 2.2 preview has 4.0.1
09:18:33< pogma> hmm, mine expires in march, don't recall who has them
09:18:42 * drm is happy to not have one
09:18:53< RangerRick> drm: hah, I was just going to offer you a seed key  :)
09:19:03< RangerRick> with xcode 2.2 kde should be gcc4 compilable
09:19:09< RangerRick> once I get it to stable I'll look into gcc4 stuff
09:19:20< RangerRick> (first I need gettext3 and some other stuff in stable, though...)
09:19:40< drm> geez, everybody wants gettext3! :)
09:20:19< RangerRick> hehe, yeah
09:20:26< RangerRick> anything that depends on it can't be moved to stable right now  :)
09:22:16< drm> well, in one sense i am tempted to say this is good... maybe the 10.4 tree should be created before all this stuff goes to stable
09:23:04< drm> it is very close to happening, but i don't have as much time for this as i did over the summer, so the last stages are a bit slow
09:26:00< drm> bbl
09:26:06-!- drm [n=drm@ip68-108-245-119.sb.sd.cox.net] has quit ["Leaving"]
09:30:13-!- lisppaste [n=lisppast@common-lisp.net] has quit ["Common Lisp IRC library - http://common-lisp.net/project/cl-irc"]
09:30:18-!- lisppaste [n=lisppast@common-lisp.net] has joined #fink
09:49:57-!- regeya [n=shane@adsl-sp3-cdale176.micgi.com] has joined #fink
10:04:27-!- beniamino__ [n=ben@adsl-64-164-10-189.dsl.snfc21.pacbell.net] has quit [Read error: 110 (Connection timed out)]
10:09:15-!- cianhughes [n=cian@cian.ws] has joined #fink
10:10:38-!- asari [n=asari@p4039-ipbf606marunouchi.tokyo.ocn.ne.jp] has joined #Fink
10:15:05-!- cianhughes [n=cian@cian.ws] has quit [Read error: 104 (Connection reset by peer)]
10:20:42-!- cianhughes [n=cian@cian.ws] has joined #fink
10:24:09 * akh works on a new wget package.
10:32:14< akh> Silly fink-installed openssl097-shlibs...
10:52:00< akh> w00t! Seems to work.
10:54:14< akh> Now to try the new upstream version
10:55:07< akh> Didn't even have to use much trickery.
10:55:44-!- dmacks [n=dmacks@pool-70-22-31-132.balt.east.verizon.net] has joined #fink
11:03:47< dmacks> chris01: Wait, you mean a user can't just set a tracker "Group: Added to Fink" and have the thing magically get added?
11:04:40< akh> dmacks:  hehe
11:05:07< akh> Could you imagine the crap packages we'd get?
11:05:13 * pogma files a feature request for that functionality :)
11:05:55 * dmacks redirects all -beginners to pogma
11:06:26< pogma> haha, you think I read my email, don't you? :-)
11:06:57< dmacks> Nice try, but /dev/null is already full to overflowing from gnome-core
11:07:08< akh> We'll text you.
11:08:58< akh> grr:  /me wants a firm policy against a variant of a package Provide: ing another variant.
11:09:36< dmacks> It's so rare that Provides is useful or used correctly at all in Fink.
11:09:40< akh> Yah.
11:10:22< akh> e.g. I'm trying to unify wget, and wget-ssl Provides: wget.
11:10:50< akh> Thus, wget-ssl doesn't get automagically updated to the unified wget (which will be a new upstream, too)
11:11:16< dmacks> ugh
11:11:31< akh> I used RangerRick's trick from the wiki.
11:11:41< akh> (dummy wget-ssl splitoff)
11:12:13< chris01> dmacks: right
11:12:13< dmacks> debian is right: Provides is *not* for the same namespace as actual package names.
11:12:21< akh> And, as a bonus, the gettext-dev dependency will go away.
11:13:29< akh> dmacks;  I totally agree with Debian's logic on this--having a Provide overlap with a real package suppresses the real package information in "fink list", for example.
11:14:26< dmacks> Yeah...they should both Provides some common third name.
11:15:00< akh> Exactly.  This will get better as we deprecate the separate -ssl variants, I guess.
11:15:55< dmacks> yp
11:16:45< dmacks> ...until someone gives us openssl098 and/or apple lags at patching their openssl097.
11:17:05< akh> We'll have to cross that bridge when we get to it.
11:17:16< dmacks> Maybe we could just burn it beforehand?
11:17:27< akh> Yup.
11:22:51< akh> At least for right now the binary redistributability issue is probably paramount.
11:22:58< dmacks> ya
11:23:14< akh> Stop people about grousing about the non-availablility of KDE from binaries.  ;-)
11:23:41< akh> Unless RangerRick wants to de-unify it, of course.
11:24:14< lisppaste> dmacks pasted "OSI-Approved? BSD?" at http://paste.lisp.org/display/11831
11:25:20< akh> It's not exactly the BSD license.
11:26:05< akh> I'd call it OSI-approved
11:26:23< akh> s/a/A/
11:26:53< akh> mmm...more poppler stuff.
11:28:06 * akh wonders if the developers of that package watched Futurama.
11:28:37< dmacks> hehe
11:28:48 * dmacks just started season3 dvds last weekend.
11:29:29< akh> My wife watched a good chunk of mine while she was laid up with back problems.
11:31:55< akh> I don't know if she got all the way through the set or not.
11:32:08< dmacks> Boo back problems. Yay futuramafication!
11:32:23< akh> Yup--comes out about even.
11:47:15< dmacks> Anyone ever played with Festival or other speech drivers on OS X?
11:48:28-!- shres [n=sshreyas@202.144.95.244] has quit [Read error: 110 (Connection timed out)]
11:58:15< dmacks> Does gpdf-2.10.0-3 compile on Tiger?
12:00:53< dmacks> Ne'ermind.
12:23:51< dmacks> Okay, does gpdf-2.10.0-3 compile on Tiger if you remove the second PatchScript line (the perl command changing uint->guint)?
12:28:01< cirdan> yoyo
12:29:25< dmacks> What up, cirdanski?
12:30:19< cirdan> not much, McDmacs
12:31:10-!- RLD_osx [n=rldempse@66-190-76-181.dhcp.dntn.tx.charter.com] has joined #fink
12:34:33-!- HenkPoley [n=henk@poley.xs4all.nl] has joined #fink
12:38:36< akh> McDmacs sounds redundant.
12:38:53< akh> Like a "Big McMac"
12:40:16< akh> grr...forgot to touch the kluge file
12:41:35-!- RLD_osx_ [n=rldempse@66-190-76-181.dhcp.dntn.tx.charter.com] has joined #fink
12:41:47-!- RLD_osx [n=rldempse@66-190-76-181.dhcp.dntn.tx.charter.com] has quit [Nick collision from services.]
12:42:12-!- RLD_osx_ is now known as RLD_osx
12:48:56-!- sid77_ [n=sid77@host-84-222-60-247.cust-adsl.tiscali.it] has joined #fink
12:49:44-!- _BleedAway [i=whocares@saus04.usc.es] has joined #fink
12:51:04-!- RLD_osx [n=rldempse@66-190-76-181.dhcp.dntn.tx.charter.com] has quit ["Mac OS X  - - a better alternative to winblow$"]
12:53:02-!- RLD_osx [n=rldempse@66-190-76-181.dhcp.dntn.tx.charter.com] has joined #fink
12:55:37-!- BleedAway [i=whocares@saus04.usc.es] has quit [Read error: 110 (Connection timed out)]
12:55:43-!- _BleedAway is now known as BleedAway
12:57:17-!- sid77 [n=sid77@host-84-222-62-128.cust-adsl.tiscali.it] has quit [Read error: 110 (Connection timed out)]
13:14:27-!- sugoi [n=Asian@71-178.69-92-cpe.cableone.net] has quit ["Qt ROCKS"]
13:15:18-!- sid77_ is now known as sid77
13:28:45-!- taf2_ [n=chatzill@65.207.103.51] has quit [Remote closed the connection]
13:30:09-!- lisppaste [n=lisppast@common-lisp.net] has quit ["Common Lisp IRC library - http://common-lisp.net/project/cl-irc"]
13:30:18-!- lisppaste [n=lisppast@common-lisp.net] has joined #fink
13:45:30-!- zecke_ [n=ich@83-169-171-130-dynip.superkabel.de] has joined #fink
14:04:25-!- HenkPoley [n=henk@poley.xs4all.nl] has quit [Read error: 104 (Connection reset by peer)]
14:22:47-!- zecke_ [n=ich@83-169-171-130-dynip.superkabel.de] has quit ["leaving"]
14:22:56-!- shres [n=sshreyas@59.92.129.191] has joined #fink
14:24:09-!- regeya [n=shane@adsl-sp3-cdale176.micgi.com] has left #fink ["Leaving"]
14:25:12-!- Albie [n=ambs@bl5-166-208.dsl.telepac.pt] has joined #fink
14:25:28-!- Albie [n=ambs@bl5-166-208.dsl.telepac.pt] has quit [Client Quit]
14:25:34-!- hennker [i=flullup@dsl-082-083-230-204.arcor-ip.net] has joined #fink
14:28:14-!- Albie [n=ambs@bl5-166-208.dsl.telepac.pt] has joined #fink
14:52:15-!- RLD_osx [n=rldempse@66-190-76-181.dhcp.dntn.tx.charter.com] has quit [Read error: 104 (Connection reset by peer)]
15:10:15-!- shres [n=sshreyas@59.92.129.191] has quit [Read error: 110 (Connection timed out)]
15:18:31-!- akh [n=akhansen@ldx3.psfc.mit.edu] has quit []
15:18:44-!- hennker [i=flullup@dsl-082-083-230-204.arcor-ip.net] has quit ["brb"]
15:21:18-!- Albie [n=ambs@bl5-166-208.dsl.telepac.pt] has quit ["Leaving"]
15:25:53-!- hennker [i=flullup@dsl-082-083-230-204.arcor-ip.net] has joined #fink
15:33:37-!- sid77 [n=sid77@host-84-222-60-247.cust-adsl.tiscali.it] has quit ["http://slackintosh.workaround.ch/"]
15:35:02-!- sid77 [n=sid77@host-84-222-60-247.cust-adsl.tiscali.it] has joined #fink
15:45:19-!- nkuttler_ [n=nkuttler@dsl-084-058-196-178.arcor-ip.net] has joined #fink
15:45:26-!- nkuttler [n=nkuttler@dsl-084-058-197-058.arcor-ip.net] has quit [Nick collision from services.]
15:45:28-!- nkuttler_ is now known as nkuttler
15:45:37-!- sid77 [n=sid77@host-84-222-60-247.cust-adsl.tiscali.it] has quit ["http://slackintosh.workaround.ch/"]
15:57:39-!- kane_ [n=kane@perl.xs4all.nl] has quit []
15:57:45-!- chris01 [n=chris01@84-73-56-45.dclient.hispeed.ch] has quit []
16:05:49-!- RLD_osx [n=rldempse@66-190-76-181.dhcp.dntn.tx.charter.com] has joined #fink
16:08:13-!- cianhughes [n=cian@cian.ws] has quit [Client Quit]
16:12:57-!- megahal [n=astrange@ip-246-036.oberlin.net] has quit [Read error: 104 (Connection reset by peer)]
16:44:11-!- atheken [n=atheken@cpe-65-24-92-24.columbus.res.rr.com] has joined #fink
16:44:14-!- eno-away [n=eno-away@adsl-67-127-69-49.dsl.snfc21.pacbell.net] has quit [Connection timed out]
16:44:37-!- atheken [n=atheken@cpe-65-24-92-24.columbus.res.rr.com] has left #fink []
16:44:42-!- RangerRick is now known as RangerAway
16:45:02-!- nkuttler [n=nkuttler@dsl-084-058-196-178.arcor-ip.net] has quit ["leaving"]
16:49:07-!- msachs [n=msachs@c-24-34-72-223.hsd1.ma.comcast.net] has joined #fink
16:51:32-!- vasi [n=vasi@modemcable133.147-70-69.mc.videotron.ca] has joined #fink
16:55:18-!- brainsik [n=brainsik@dsl092-001-132.sfo1.dsl.speakeasy.net] has joined #fink
17:02:38< msachs> Note to self: Refrigerators are hard, and rather unpleasant things to charge into.
17:02:59< newmanbe> Note to self: List to msachs notes.
17:03:00< newmanbe> :)
17:03:09< newmanbe> s/List/Listen/
17:03:47< dmacks> Better that than just standing there wondering "is that teetering vending machine gonna fall towards me or away?" though.
17:04:09< msachs> Well I was doing my impression of a bull in a bullfight.
17:04:28< msachs> And linoleum is more slippery than dirt.
17:04:36< dmacks> matador==frigerator?
17:04:37< dmacks> ah.
17:04:45< msachs> Nope, my housemate who was standing in front of said appliance.
17:05:25< vasi> owwww
17:05:56< dmacks> ouchie!
17:05:59-!- __jt__ [n=james@69-162-30-40.stcgpa.adelphia.net] has joined #fink
17:06:11< msachs> Eh, it wasn't so bad, and if it was I would've deserved it.
17:06:35< dmacks> Not you.../me concerned that all the beer is now too shaken to drink right when you need it!
17:06:41< vasi> heh
17:06:47< vasi> just don't win a darwin award, k?
17:07:24< msachs> dmacks: Only one way to find out!
17:07:32< msachs> I promise not to repeat this experiment with a JATO unit.
17:07:54< dmacks> Good thought (both beer and !JATO)
17:07:58< newmanbe> vasi: So if he would have died, would we have less people to run into refrigerators. :-p
17:08:20< newmanbe> (Speaking of Darwin)
17:08:49< msachs> If there had been more refrigerators on -- where was it, Galapgos? -- I'm sure he would've written about that.
17:08:55< dmacks> Maybe it's like sickle-cell anemia, where we have reached a steady state: we are programmed to run into fridges, but not hard enough to kill ourselves.
17:09:51< dmacks> Speaking of things that should just go kill themselves...Exhibit A: gettext
17:10:07< msachs> Which one?
17:10:32< dmacks> gettext itself, and especially programs that misuse it.
17:12:01< msachs> How do they manage to do that?
17:12:31< dmacks> 1. Close eyes 2. start typing 3. ship it when it compiles in a limited test environment:)
17:13:12< msachs> That'll do it.
17:13:25< msachs> I'm surprised they manage to use gettext instead of liba;lsdfhjkf,, though.
17:21:24< dmacks> vasi: Do you remember how someone (tonyarnold?) fixed a pkg to add library versioning to the msg catalogs?
17:21:39< vasi> dmacks, it was popt
17:21:40< vasi> (the pkg)
17:22:18< vasi> and the solution involved changing the GETTEXT_NAME or some variable like that
17:22:29< dmacks> *gah*...all my reading about gettext and grepping wouldn'ta found the fix he used:/
17:22:50< vasi> more like the solution i found for him :-P
17:23:01< dmacks> Ahh:)
17:23:03< vasi> don't remember where i got it from...probably just reading through the makefiles
17:23:35 * dmacks struggling to get gnome-menus somewhat compiled.
17:30:13-!- lisppaste [n=lisppast@common-lisp.net] has quit ["Common Lisp IRC library - http://common-lisp.net/project/cl-irc"]
17:30:18-!- lisppaste [n=lisppast@common-lisp.net] has joined #fink
17:33:06< vasi> good luck!
17:34:07 * dmacks wishes miga would reappear and explain the freedesktop standard. 
17:35:05< dmacks> Waddaya think of an enhanced DocFiles syntax, where an item like foo/bar/biff: would become biff.foo.bar ?
17:36:06< vasi> er, but foo/bar/biff already has the meaning 'install foo/bar/biff to %p/share/doc/%n/biff'
17:36:18< dmacks> Note trailing colon.
17:36:29< vasi> ah...hmm, interesting
17:36:47< vasi> if you want to work on DocFiles, how about making it copy complete directories too?
17:37:10< dmacks> Useful as a macro for our standard renaming where there are many of the same-named file in different locations (for example ChangeLog and po/ChangeLog, where the latter would be copied as ChangeLog.po)
17:38:47< dmacks> Not that gnome-games has an ugly-ass PatchScript...
17:39:56-!- muesli [n=muesli@mail.muehlhaeuser.de] has joined #fink
17:40:10< muesli> hey guys
17:40:23< muesli> trying a fink selfupdate i get this error on package libiconv-1.10-6
17:40:30< dmacks> If one passes a directory, what should it do? Flatten it? Do "cp -r"? 
17:40:34< muesli> checking how to run the C++ preprocessor... /lib/cpp
17:40:36< muesli> configure: error: C++ preprocessor "/lib/cpp" fails sanity check
17:40:47< dmacks> whoa muesli, that's weird.
17:40:59< muesli> indeed
17:41:35< dmacks> config.log in the build directory would have more details, but I think the general solution is gonna be "reinstall xcode"
17:42:37< muesli> checking whether we are using the GNU C++ compiler... no
17:42:47< muesli> thats pretty funny as well, and prolly the actual reason for it failing
17:42:48< muesli> how come
17:43:53< dmacks> Yeah, sounds like your xcode installation is broken. Because Apple's installer sucks (and is even worse when upgrading 10.3->10.4 for example)
17:44:02< muesli> hm
17:44:06< muesli> but it used to work before
17:44:15< muesli> and i can still compile programs manuallz
17:44:19< muesli> i did a sudo gcc_select 3.3, though
17:44:31< vasi> make sure you don't actually have a /lib directory
17:44:45< vasi> dmacks, i'd say it should 'cp -r', yeah
17:44:58< muesli> vasi: i dont have one
17:45:23< dmacks> You on Tiger? Have you ever installed any other compilers than xcode?
17:45:45< muesli> yes, tiger. no always used gcc
17:45:54< muesli> and i got a complete kde and stuff compiled with it
17:46:10< muesli> it just started after the last selfupdate
17:46:24< dmacks> Maybe gcc_select 4.0 (that's the Tiger default, yes?)
17:46:32-!- rajesh [n=rajesh@nylug/member/rajesh] has quit ["leaving"]
17:46:40< muesli> teyes
17:46:43< muesli> yes
17:46:45< vasi> quite a few packages have a custom InstallScript just to do 'mkdir %p/share/doc/%n && mv examples %p/share/doc/%n/'
17:46:46< muesli> trying that atm
17:46:50< vasi> which is silly
17:47:04< dmacks> Have you done Repair Permissions lately?
17:47:28< muesli> uhm dont think so
17:47:28< dmacks> vasi: Good point.
17:47:34< dmacks> muesli: Also try gcc_select -force
17:47:35< muesli> ok, gccselect 4.0 didnt help either
17:48:53< muesli> ok, trying that now
17:50:54< muesli> where is this config.log exactly?
17:51:11< dmacks> `fink dumpinfo -pb libiconv`
17:52:10< muesli> veggie:/ muesli$ fink dumpinfo -pb libiconv
17:52:11< muesli> Information about 4902 packages read in 17 seconds.
17:52:13< muesli> %b: .
17:52:23< dmacks> D'oh...looks like the patch to that didn't get released yet:(
17:53:11< muesli> i see
17:53:34< dmacks> Look in the directory libiconv-10.whatever/libiconv-10.whatever in the directory specified by Buildpath in your /sw/etc/fink.conf
17:54:20< dmacks> (or libiconv-1.10.whatever, or something like that:)
17:54:24 * dmacks -> dinner
17:54:30-!- dmacks is now known as dmacks_away
17:55:55< vasi> muesi, so that probably means /sw/src/fink.build/libiconv<something>/libiconv<something>
17:59:59-!- __jt__ [n=james@69-162-30-40.stcgpa.adelphia.net] has quit []
18:11:22-!- msachs [n=msachs@c-24-34-72-223.hsd1.ma.comcast.net] has quit []
18:30:52-!- zizban [n=zizban@24-52-0-219.sbtnvt.adelphia.net] has joined #fink
18:41:27< zizban> Ah, the glory that is a working keyboard
18:41:32-!- Feanor [n=astrange@mp1-248-19.dialup.emory.edu] has joined #fink
18:41:36< vasi> heh
18:42:20< zizban> even if springfield has no apple store and I had to go (gag) Compusa in Holyoke
18:42:33-!- vasi [n=vasi@modemcable133.147-70-69.mc.videotron.ca] has quit ["Client exiting"]
18:43:12-!- vasi [n=vasi@modemcable133.147-70-69.mc.videotron.ca] has joined #fink
18:55:54 * newmanbe woots!
18:56:58< newmanbe> I have spread my Gopher-ness and convinced someone to let me manage their Gopher server.
18:57:58< zizban> they still gopher servers?
18:58:12< Feanor> that sentence verb
18:58:21< zizban> have
18:58:50< zizban> new keyboard is smaller than the old one...still getting used to it
18:58:58< zizban> !lart CompUSA
18:59:09< zizban> sigh
19:01:49< newmanbe> Heh, CompUSA.
19:03:10< zizban> No Apple Store on my way to Springfield
19:03:57< newmanbe> Heh, Apple Retail Store.
19:04:01 * newmanbe thinks about which one is worse.
19:04:27< zizban> CompUSA, by far
19:05:59< newmanbe> The Apple Retail Store still gives it a run for its money. ;)
19:07:14-!- __jt__ [n=james@69-162-30-40.stcgpa.adelphia.net] has joined #fink
19:07:27< zizban> heh
19:16:41-!- holo [n=carlos@a81-84-126-89.cpe.netcabo.pt] has joined #fink
19:16:48< holo> hi
19:19:17< holo> fink can't find the package tightvnc and it is ported: http://pastebin.com/369525
19:20:16< newmanbe> 8Hello.
19:20:22< newmanbe> Did you enable unstable?
19:20:38< Feanor> Melian: unstable
19:20:55< holo> newmanbe, no sorry didn't check if the package was in unstable
19:21:22< cirdan> !unstable
19:22:14-!- Melian [n=blootbot@pcp04356153pcs.glstrt01.nj.comcast.net] has quit [Connection reset by peer]
19:23:20-!- Melian [n=blootbot@pcp04356153pcs.glstrt01.nj.comcast.net] has joined #fink
19:25:02< holo> funny: fink selfupdate; fink index; fink scanpackages
19:25:21< holo> when i used debian, i could do no more than apt-get
19:25:27< holo> *apt-get update
19:26:48< newmanbe> !debian
19:26:48< Melian> methinks debian is not Fink. Debian is not Fink. Debian is not Fink. Please repeat that.
19:27:02< newmanbe> Or if you prefer:
19:27:04< newmanbe> !fink
19:27:05< Melian> somebody said fink was not Debian. Fink is not Debian. Fink is not Debian. Repeat ;-)
19:27:07< newmanbe> :-p
19:27:28< zizban> heh
19:27:40< asari> F.. fink is not Debian
19:27:54< asari> morning all
19:28:01< newmanbe> Goodmorning.
19:29:19< holo> yeah yeah its not debian and im too diferent from all the people but i am still human as well
19:30:10< holo> and i didn't said it was debian (debian is a complete operating system) apt or fink are just package managers
19:30:58< holo> !package_manager
19:32:45< holo> wow.. it is downloading a bunch of stuff from a cvs.. i must really read finks features
19:34:29< zizban> if you haven't updated to .24.9 you do
19:35:45< holo> sorry for asking this without reading first but its urgent: if i install from unstable, its going to fetch unstable dependences.. how do i avoid this if possible? is there any form of apt-pinning here?
19:36:53< holo> an apt preferences or something
19:37:07< vasi> holo, um not really any good way :-(
19:37:11< newmanbe> No.
19:37:14< vasi> you can NOT enable unstable, and try copying a .info file from unstable to local
19:37:16< Feanor> fink does not yet support hold
19:37:32< Feanor> but package in the unstable tree generally aren't themselves unstable
19:37:34< Feanor> the tree itself is unstable
19:37:51< vasi> yeah, fink 'unstable' is probably more stable than debian 'testing'
19:37:53< holo> Feanor, i know.. thats not the reason.. broken packages are
19:38:01< holo> they are rare, but they are a bitch
19:38:15< vasi> yeah, but currently the 'unstable' tree probably has less broken packages than stable
19:38:18< holo> becouse of stable/ustable mixes
19:38:49< holo> vasi, ?
19:39:05< holo> stable is decaying? :D
19:39:46< Feanor> the policy for moving things to stable is pretty restrictive
19:39:52< Feanor> enough so that generally things don't get moved
19:40:02< holo> so i dont have to worry about broken dependences between stable/unstable?
19:40:13< zizban> no
19:40:23< holo> nice
19:40:25< zizban> if you use one, it doesn't affect the other
19:40:36< holo> zizban, i am using both
19:41:04< zizban> unstable will take priority
19:41:16< holo> i used stable/testing/unstable.. the system went screwed for life.. until i apt-pinned
19:43:26< holo> can i use a regular /etc/apt/prefrences from debian here?
19:43:37< holo> *preferences
19:45:26< holo> zizban, i just wanted it to install from unstable if i required it like `apt-get -t unstable install bla` and if not it would fetch stable versions whenever possible
19:45:48< zizban> I dont know if that's possible
19:45:48< vasi> holo, fink doesn't really support that
19:45:52< vasi> sorry :-(
19:46:21< holo> or apt-get install bla/unstable wich tries so fetch unstable package except its dependences
19:46:25< holo> vasi, ok :\
19:46:56< holo> but its great to use the wonderfull softwore i used before :D
19:47:08< vasi> hmmm, i have a PEF application, but double-clicking on it opens it in ScriptEditor (!?) instead of running the app
19:47:08< holo> *bla\unstable
19:47:17< vasi> weeeeeird
19:47:51< vasi> holo, i'm not aware of any build-from-source package manager that's really figured out a good way to pin
19:48:29< vasi> you might have some luck using a combination of fink and apt (see 'fink scanpackages')
19:48:34< holo> vasi, this one is not build from source model
19:48:34< holo> AFAIK
19:48:57< vasi> holo, apt is all binaries....fink is a build-from-source thing
19:49:03< holo> lol
19:49:12< holo> i didn't noticed
19:49:36< holo> lol.. so thats why it downloaded a lot of patch thingys
19:49:50 * holo feels dumb
19:50:39< holo> ok so apt here can use pinning priorities?
19:51:28< vasi> well you can use fink to build everything you need
19:51:42< vasi> then tell apt about the packages that fink just built, using 'fink scanpackages; apt-get update'
19:51:51 * holo suspects vasi is a gentoo user in part-time
19:51:58< vasi> and then perhaps you can convince apt to follow its pinning rule
19:51:59< vasi> s
19:52:13 * vasi actually strongly dislikes gentoo :-P
19:52:36< holo> vasi, thanks for the tip
19:52:55< vasi> i once fixed a bug in qpkg (gentoo's tool to list packages), and then some random dude overwrote my bugfix
19:53:09-!- dmacks_away is now known as dmacks
19:53:13< vasi> and i couldn't get anybody at gentoo to re-apply my fix
19:53:16 * zizban dislikes gentoo as well
19:53:23< vasi> so i got kinda pissed at them, and switched to ubuntu :-)
19:53:59< zizban> I took a break from Linux
19:54:20< holo> good switch
19:54:36< holo> installed it once and just loved it
19:55:29< holo> i liked the idea from those guys of system-7
19:56:19< holo> it would really be a f*ck-all_binary_distribution :D
19:56:33< dmacks> Yeah, thank goodness they deprecated Font/DA Mover!
19:59:23< vasi> oh my, those were the days
20:06:57< dmacks> Wow, DocFiles internals is messy!
20:08:24< asari> vasi: I installed ubuntu yesterday
20:08:36< vasi> dmacks, all internals are messy
20:08:43< vasi> at least in PV
20:08:44< asari> update-manager looks cool
20:09:10< vasi> i was just looking at one field....maybe Files? and for some reason we do '@list = grep { $_ } @list;'
20:09:11< vasi> WTF!?
20:09:16< dmacks> ha!
20:09:36< vasi> hmm, i guess if it can be a null value
20:09:36< vasi> really weird screwy code though
20:09:36< dmacks> Yeah.
20:09:55< vasi> asari, Breezy Badger (the next ubuntu) will have a really nice installer-program
20:09:57< dmacks> Must be an idiot coder, unless it was you or I or someone else we know:)
20:10:07< vasi> (they fixed up gnome-app-install so it has much nicer features)
20:10:47< asari> vasi: I have Preview Release of it
20:10:55< vasi> asari, oh ok
20:10:59< asari> maybe ..5.10?
20:11:11< vasi> yeah, that's Breezy
20:11:42< vasi> ah, it's infodocs
20:12:42< dmacks> We oughta have a single conditionals-and-multiline-rejoining accessor for all the ConfigureParams and *Files fields.
20:12:56< vasi> i don't even know why that's a field...why can't fink just detect that there are info docs to install?
20:13:33< dmacks> Please don't get me started ranting about infodocs.
20:13:45< vasi> hehe
20:14:08< dmacks> (I think with multiparters, one "should" only list the primary file, but dunno really)
20:14:23< vasi> the obvious way to split PV is actually to distinguish between source and non-source packages
20:14:37< vasi> but that could be a lot of work, and it's hard to see how it could be done incrementally
20:16:06< dmacks> So PV::SplitOff ISA=PV? That way we don't need all those 'if $self->has_parent {$self->parent->foo;return}' 
20:16:38< dmacks> And don't need the splitoff initializer spaghetti.
20:17:04< vasi> er, i didn't mean source-vs-splitoff
20:17:13< dmacks> Oh.
20:17:18< vasi> i mean 'fink buildable' vs 'other'
20:17:22< vasi> eg: status and virtpkg
20:17:46< dmacks> ahh
20:17:53< vasi> but yeah, it would make sense to further separate splitoffs and parents
20:18:05< dmacks> Yeah, that could work, but yeah, seems like a lot of work.
20:18:23< vasi> fink currently doesn't really understand the difference between buildable and dummy packages
20:18:42< vasi> random parts of the code use is_type("dummy") to check
20:18:50< dmacks> Sure it does...with a shitload of if is_type(dummy) :)
20:18:59< vasi> but the package-finding code (in match_package for example) doesn't seem to give a damn
20:19:21< dmacks> !lart install and install-sh
20:19:22 * Melian explains, ever so gently, that if install and install-sh doesn't give the channel more information, they can't help
20:19:31< vasi> lol
20:19:54< dmacks> !strap on a pair and !lart them harder!
20:20:12< vasi> probably the way to do things is to 1) separate out the source stuff into PV::Source
20:20:30< vasi> but make *every* PV a Source one for now
20:20:57< vasi> and then slowly move things to understand the difference between Source and Dummy, until they all work
20:21:10< vasi> at which point the Dummies can stop being Sources
20:21:19< dmacks> So when Package calls the PV initializer, it just decides whehter to use PV::Dummy or PV::Souce based on {dummy}?
20:21:38< vasi> well presumably it would call the correct initializer
20:21:58< vasi> so there will be a PkgVersion::new_from_properties, and PkgVersion::Source::new_from_properties
20:22:38< vasi> the only cases that DON'T use Source are the special VirtPackage and Status thingies
20:23:16< dmacks> is_dummy ? PV::new_from_properties : PV::Source::new_from_properties
20:24:28< dmacks> (need to document that DocFiles results in chmod -x for all files...that's bad for the examples/ situation)
20:24:38< vasi> er, but what object will it call is_dummy on? :-P
20:25:08< vasi> why chmod -x ?
20:26:40< dmacks> Okay, so always call PV::new_from_prop, which can then rebless itself into ::Source:: if it figures out it's not a dummy.
20:27:00< vasi> dmacks, nah better to call the right method for the right thing
20:27:16< vasi> it's not like there exists any code which could call either
20:27:29< vasi> hmm, the 'grep {$_}' thing is yours!!
20:27:59< dmacks> Where we lookin'?
20:28:06< vasi> apparently we used to to 'next unless $infodoc;' for some reason....so you just maintained that by turning it into a grep
20:28:31< vasi> line 3682, just after splitting the InfoDocs field
20:28:48< dmacks> Ahhh yeah. I went on a "convert function loops into pre-processing the data" binge a while back.
20:29:18< dmacks> Dude...read the comment there!
20:30:20< dmacks> (and feel my infodoc rage rising:)
20:31:12-!- akh [n=akhansen@68-118-244-23.dhcp.oxfr.ma.charter.com] has joined #fink
20:31:12-!- RangerAway is now known as RangerRick
20:31:21< dmacks> Well at *some* point *something* in the PV initializer has to decide "this is a dummy", so at that point either rebless, or put off blessing until that result it know.
20:31:22< dmacks> *known.
20:31:39< dmacks> *is
20:31:49< vasi> no no no
20:32:14< vasi> the code that wants to create a PV decides what kind of PV to create
20:32:27< dmacks> Ok, that's a more substantial change.
20:32:36< vasi> and then PV::initialize does its thing...and if it's a source PV, then PV::Source::initialize does its thing as well
20:32:58< vasi> dmacks, there are only three or four places that actually create a PV
20:33:17< vasi> i had to change them all already, when doing the "Great Package to PV move" :-)
20:33:42< dmacks> But it's a change in the whole "here's the data, go create yourself" philosophy.
20:34:27< dmacks> It shouldn't matter to the caller the details of the object creation.
20:34:39< vasi> but it's not a 'detail'
20:34:55< vasi> it's that right now, two *very different things* are created in the same way
20:35:14< vasi> it's like if we decide to initialize *everything* by calling Fink::Base::new
20:35:26< vasi> and Fink::Base would decide what object this should become :-)
20:36:00< vasi> that's what we're doing now with PV, where both 'kinds' of PV are created the same way
20:36:08< dmacks> PV and PV::Source are functionally the same (black box) from the caller yes?
20:36:28< vasi> no...PV::Source can do a lot of things that PV can't
20:36:42< dmacks> Does the caller need to know that?
20:36:51< vasi> sometimes yes, sometimes no
20:37:05< vasi> for 'list me such-and-such a package', no
20:37:10< vasi> for 'install me such-and-such a package', yes
20:37:40< vasi> so there would be some method, is_source() or is_dummy() that can distinguish easily
20:37:40< dmacks> Sorry..."caller" means during object creation, not an arbitrary *user* of the object.
20:37:52< vasi> for the creator, yes again
20:38:07< akh> mmm...object oriented IRC
20:38:50< dmacks> Okay, so the creation-caller, at several points in the code, will decide whether the thing is a dummy or not, then call the appropriate new_from_props?
20:39:05< vasi> what is 'the thing'?
20:39:29< dmacks> "the object to be created from the $properties hashref"
20:39:47-!- TheSin [n=TheSin@iphost-64-56-130-194.edm.wiband.net] has joined #fink
20:40:18< vasi> well if you look at the code now...the 'produce me a PkgVersion from a .info file' and 'produce me a PkgVersion from Status/VirtPkg' are quite different
20:40:33< vasi> there is no point in that code in which we don't know what kind of thing we're dealing with
20:41:07< dmacks> Ahhhh.
20:41:45< vasi> so we never have a $properties which may or may not be a source
20:42:38< dmacks> light gradually coming on...
20:43:20-!- holo [n=carlos@a81-84-126-89.cpe.netcabo.pt] has quit ["Leaving"]
20:43:31< vasi> :-)
20:43:44< TheSin> hey dmacks
20:43:54< dmacks> Hiya TheSin!
20:44:53< zizban> is TheSin back from vacation?
20:45:02< TheSin> yes I am
20:45:55< dmacks> vasi: This is making more sense now.
20:45:55< zizban> welcome back
20:46:02< vasi> sense is good!
20:46:20< TheSin> thanks zizban 
20:48:16< vasi> your idea with Parent vs. SplitOff separation makes sense too
20:48:31< dmacks> If foo ISA(foo_super) and a foo object method calls &func, will &func be searched for in foo then foo_super, or only in foo?
20:48:50< vasi> foo then foo_super
20:48:59< vasi> and of course one can override the other
20:49:17 * dmacks thinking about frozen APIs that might interfere with subclassing.
20:49:23-!- cirdan [n=chris@pcp04356153pcs.glstrt01.nj.comcast.net] has quit [Read error: 110 (Connection timed out)]
20:49:39< vasi> 'frozen' meaning FinkCommander?
20:49:47-!- Melian [n=blootbot@pcp04356153pcs.glstrt01.nj.comcast.net] has quit [Read error: 110 (Connection timed out)]
20:49:59< dmacks> Ayup
20:50:24< vasi> well the 'solution' to that is twofold
20:50:29< vasi> 1) Fix FinkCommander, eventually
20:50:39< akh> haha
20:50:47< vasi> 2) Make dummy methods in the new PV that simply 'return something by default'
20:50:58< vasi> kinda like what we already do, but explicit rather than hidden :-)
20:51:26-!- regeya [n=shane@adsl-sp3-cdale176.micgi.com] has joined #fink
20:51:50< vasi> so currently we have a big if-else in initialize, to deal with Source/Dummy packages
20:51:54-!- regeya [n=shane@adsl-sp3-cdale176.micgi.com] has quit [Remote closed the connection]
20:51:58< vasi> that will just become an overridden method
20:52:26< dmacks> &func function calls do not appear to search up the inheritance chain.
20:54:08< dmacks> No biggie, can just have an actual 'sub func {&foo_super::func}' in foo
20:54:34< vasi> oh, you mean with explicit &?
20:54:46< vasi> ooooh
20:54:53< dmacks> Yeah, that's why I called it "func" and not "another object method"
20:54:54< vasi> you mean non -> calls?
20:55:25< dmacks> Yup.
20:55:39< vasi> i don't think we have many of those...
20:55:44< vasi> since most subs need access to $self
20:57:03< dmacks> 110 subs in PV; 4 class methods, 84 instance methods.
20:57:36< dmacks> Not unfixable, just a gotcha we gotta avoid.
20:58:20< vasi> what subs does that count?
20:58:28< vasi> (ie: does it include anonymous subs?)
20:58:52< dmacks> 'grep "^sub " PkgVersion.pm'
20:59:06< vasi> better do ^\s*sub
20:59:15-!- brainsik [n=brainsik@dsl092-001-132.sfo1.dsl.speakeasy.net] has quit []
20:59:16< vasi> because we have some { } blocks at the top level
20:59:20< vasi> for private my vars
21:00:37< dmacks> Eh, it's a rough counting of class and instance cases too.:)
21:01:22< vasi> anyway, i think this method of moving things is something that we can easily do method-by-method
21:01:31< dmacks> Yeah.
21:01:41< vasi> and the 'big steps' can wait until we're ready for them
21:02:22< vasi> so, just after we release 0.25, i'll put the basic infrastructure in place...and then we can just move each method whenever it's convenient
21:02:34< dmacks> Sounds reasonable.
21:03:27< dmacks> Okay, onward to DocFiles?
21:04:12< zizban> onward, ho!
21:04:37< dmacks> Need to assign absolute perms *somehow*, right now we "install -m644". Would be better to add a+x iff the source file has u+x ?
21:04:56< dmacks> (and dirs 755 obviously)
21:05:35< vasi> hmmm...why not just remove the umask?
21:05:41< vasi> (is there an easy way to do that?)
21:06:46< vasi> i mean....that is the whole reason we're changing the perms, right?
21:07:55< dmacks> Sources could be 666 or 600; don't want them to be world-writable (probably) and want them to be world-readable.
21:09:45< dmacks> umask doesn't seem to cause cp to add perms beyond those present in the source perms.
21:10:48-!- msachs [n=msachs@c-24-34-72-223.hsd1.ma.comcast.net] has joined #fink
21:10:56< vasi> so why don't we just chmod a+r  and  chmod go-w ?
21:11:09< vasi> if that's what we're actually trying to do
21:11:40< dmacks> Because you objected when I said "all DocFiles will be 644"?
21:11:57< dmacks> ...leading to concerns about executable files in examples/
21:12:05-!- msachs [n=msachs@c-24-34-72-223.hsd1.ma.comcast.net] has quit [Client Quit]
21:12:55< vasi> why are we touching x at all though?
21:13:44< dmacks> Say examples/demo is 700; I assume we want the installed file to be 755 no?
21:14:12 * akh really needs to stop breaking support packages.  :-(
21:14:45< vasi> hmm, i guess
21:14:54< vasi> alright, you win :-)
21:15:12< vasi> -x ? 755 : 644
21:15:37< dmacks> Somethin' like that yeah.
21:18:56-!- shres [n=sshreyas@59.92.128.28] has joined #fink
21:19:08< dmacks> umask 077;cp;chmod go+r,a+X I guess
21:20:21< vasi> um, why set the umask?
21:21:24< dmacks> blocks a race if I cp;chmod go-w . Okay, I'm anal:)
21:22:02< vasi> um, i totally don't understand that, but i'll take your word for it :-)
21:23:45< dmacks> It's closer to the original 'install -m644' functionality..."never set some flags, then add them" rather than "perhaps set, then later clear certain flags"
21:26:09-!- shres [n=sshreyas@59.92.128.28] has quit ["I am sleepy"]
21:28:29-!- RangerRick [n=ranger@cpe-065-190-205-196.nc.res.rr.com] has quit [Connection timed out]
21:28:38-!- zizban [n=zizban@24-52-0-219.sbtnvt.adelphia.net] has quit []
21:29:48< akh> !lart upstream API changes
21:30:03< akh> (and stupid trivial ones that break shit)
21:30:07-!- lisppaste [n=lisppast@common-lisp.net] has quit ["Common Lisp IRC library - http://common-lisp.net/project/cl-irc"]
21:30:14-!- lisppaste [n=lisppast@common-lisp.net] has joined #fink
21:32:54< dmacks> Could someone check whether the 10.3 gpdf (revision 4) compiles on 10.4T? 
21:33:12< vasi> i'll give it a shot after i update-all
21:33:21< dmacks> thx
21:51:34-!- holo [n=carlos@a81-84-126-89.cpe.netcabo.pt] has joined #fink
21:51:34< holo> hi
21:52:39< akh> hi
21:52:53-!- RLD_osx [n=rldempse@66-190-76-181.dhcp.dntn.tx.charter.com] has quit [Read error: 104 (Connection reset by peer)]
21:53:13< holo> isn't it `setenv' supposed to be a shell directive?
21:53:24< holo> ha no
21:53:29< holo> its gnulib
21:53:44< holo> how do i install gnulib?
21:54:16< vasi> sorry, what's gnulib?
21:54:17< vasi> and why do you want it?
21:54:33< brendan> setenv is a csh thing. you probably just want export
21:54:34< holo> vasi, http://packages.debian.org/cgi-bin/search_contents.pl?word=setenv&searchmode=searchfiles&case=insensitive&version=stable&arch=i386
21:55:00< holo> ha export yes sorry i didn't analyse the command content
21:55:23-!- megahal [n=astrange@ip-246-036.oberlin.net] has joined #fink
21:55:29-!- megahal [n=astrange@ip-246-036.oberlin.net] has quit [Remote closed the connection]
21:56:48-!- megahal [n=astrange@ip-246-036.oberlin.net] has joined #fink
21:59:31-!- holo [n=carlos@a81-84-126-89.cpe.netcabo.pt] has quit ["This computer has gone to sleep"]
22:00:40-!- shres [n=sshreyas@59.92.143.89] has joined #fink
22:01:18-!- akh [n=akhansen@68-118-244-23.dhcp.oxfr.ma.charter.com] has quit []
22:11:47-!- TheSin [n=TheSin@iphost-64-56-130-194.edm.wiband.net] has quit ["Client exiting"]
22:18:30-!- beniamino__ [n=ben@adsl-64-164-10-189.dsl.snfc21.pacbell.net] has joined #fink
22:18:43< vasi> howdy ben
22:27:00< beniamino__> vasi: hey there
22:27:13 * beniamino__ has been lost in the real world
22:27:32< vasi> your user page on the wiki says 'dpkg -c `list_nonessential`'....it should be dpkg -r
22:27:35< vasi> just pointing it out
22:27:55< vasi> (the rest of us at fink also take breaks when real-life intervenes, no worries :-)
22:30:59< beniamino__> fixed :-)
22:32:57< dmacks> When we find someone whose doesn't, I vote to stick 'im with gnome-*
22:39:17-!- regeya [n=shane@adsl-sp3-cdale176.micgi.com] has joined #fink
22:40:31-!- dmacks [n=dmacks@pdpc/supporter/active/dmacks] has quit ["leaving"]
22:49:30< beniamino__> vasi: does your flocate script work? the commit comment is 'usable now?'
22:49:46< vasi> i use it all the time
22:49:56< vasi> you may have to adjust some of the paths in the script
22:50:09< beniamino__> sounds good - that '?' made me doubtful
22:50:20< vasi> uh yeah, don't trust my commit messages :-)
22:50:40< vasi> some of the scripts are a bit dated, no idea if flocate is one of them
22:50:57< vasi> (i rarely sync my local scripts with the scripts dir :-(  )
22:54:33< beniamino__> hm.. hardcoded paths are bad.. i was making a helper script that fills out .info fields based on the contents of a .deb. dpkg -s is sloow.
22:58:41< vasi> i think flocate mainly supports env vars and options now....
22:59:12< vasi> well dlocate finds stuff that's currently installed
22:59:20< vasi> no idea if it caches contents like flocate does
23:01:34< vasi> i have a fink-dep-check-flocate script somewhere, that uses flocate and otool to find shared library deps
23:02:04< vasi> but of course there's no good way to find other deps (ie: if a program calls some binary)
23:02:30-!- regeya [n=shane@adsl-sp3-cdale176.micgi.com] has quit ["Leaving"]
23:03:02< vasi> (fink 0.25 should be able to automagically find shared library deps, but there are some wrinkles that need ironing out...TheSin wrote the code, and nobody else really understands all of it, so hopefully that'll fix itself soon)
23:03:51< vasi> (and fink 0.26 should have InheritedBuildDepends, so that you don't have to depend explicitly on BuildDepends of your BuildDepends...we haven't yet decided the details of how it should work)
23:13:48-!- shreyas [n=sshreyas@59.92.147.48] has joined #fink
23:18:52 * vasi is off, toodles
23:19:16-!- vasi [n=vasi@modemcable133.147-70-69.mc.videotron.ca] has quit ["Client exiting"]
23:23:33-!- shres [n=sshreyas@59.92.143.89] has quit [Read error: 110 (Connection timed out)]
23:26:22-!- eno [n=eno@64.163.148.111] has joined #fink
--- Log closed Wed Sep 21 00:00:05 2005

.