--- Log opened Fri Sep 16 00:00:34 2005 00:20:52< runelind> mmmm wpa2 00:23:50< vasi> brendan, i think that's the best way 00:24:01< vasi> er, NOT Conflicts 00:24:04< vasi> just Replaces 00:24:21< vasi> er....hmm 00:24:23< brendan> what's the difference exactly? 00:24:29< vasi> big difference 00:24:45< vasi> just Replaces means "files in this package can overwrite files in the other package, leaving both installed" 00:24:46< brendan> they can't be installed at the same time 00:25:09< vasi> Replaces/Conflicts means "installing this package will cause the other one to be removed" 00:25:19< brendan> what I want is for gsasl9-dev to go in first if they are both already there 00:25:30< vasi> go in first? 00:25:48< brendan> everything's fine if gsasl9-dev is upgraded first, since the shlibs disappears from it 00:26:15< brendan> Conflicts/Replaces just clobbers gsasl9-dev, then I have to manually reinstall it 00:26:29< vasi> hmm...i suspect that putting a C/R in -shlibs will work 00:26:34< vasi> i'm not entirely sure 00:26:50< brendan> I tried it. It's not too painful, but I have to remember to install gsasl9-dev afterwards 00:26:54< brendan> no errors at least 00:27:14< vasi> yeah, it will leave the user without the -dev, but that's minor since it's BDO 00:27:47< brendan> (unless the user is building non-fink stuff using the headers) 00:28:03< vasi> the problem is that the current fink has a bug 00:28:07< vasi> well it's really dpkg's bug 00:28:42< vasi> so that even though the old -dev depends on -shlibs (= %v-%r), dpkg doesn't notice that's being screwed up when -shlibs is updated 00:28:52< brendan> yeah, it seems like it ought to be able to figure that out 00:28:56< vasi> the next version of fink will notice that, and automatically update -dev 00:29:40< vasi> you can test it if you install fink from CVS HEAD 00:30:01< vasi> (just 'cvs co fink', 'cd fink', './inject.pl') 00:30:43< brendan> hmm, I hadn't expected to make the leap from selfupdate so soon :) 00:32:26< brendan> also, even if it works I guess it's better to leave C/R in the info file for the mainstream users... 00:32:49< beniamino> grr.. any idea how to get /sw/bin/python to point to /sw/bin/python2.4? other than the obvious 00:32:56< brendan> unless HEAD is going live soon 00:33:29< brendan> update-alternatives? 00:38:08< beniamino> ahhh... 'fink install python' ... update-alternatives would be better 00:51:21< vasi> brendan, 0.25 probably won't be released for at least another month 00:51:29< vasi> definitely go for a now-solution 00:51:58< vasi> beniamino, there's no consensus among devs about update-alternatives vs. symlink packages 00:52:17< vasi> most devs themselves prefer u-a 00:52:43< vasi> but many users have no idea about that, so a lot of devs just use symlink-packages for the benefit of the avg fink user 00:53:23< beniamino> but in auto mode, the average user need never know... 00:53:32< brendan> what he said :) 00:53:36< beniamino> just magically works 00:54:30< vasi> beniamino, the avg user has no idea how to *change* that though 00:54:55< vasi> the idea is that 'fink install python-2.3' is more obvious than u-a 00:55:02< vasi> nobody knows if that's really the case 00:55:10< vasi> can you tell we could use some usability testing? 00:55:13< vasi> :-) 00:55:52< vasi> ok, i go look at your tracker updates now...since the alternatives are going to sleep or coding, and i'm not in the mood for either 01:02:56< brendan> by the way, you've got a counterexample of two people who were confused by symlinks instead of update-alternatives right here :) 01:03:26< vasi> yeah, but you two are much more involved than the average user...who learns about 'fink install foo' and that's it 01:03:53< vasi> anyway, i usually use u-a for my packages, i'm just playing devil's advocate here 01:04:18< vasi> beniamino: any particular reason it's libjasper1 (rather than libjasper42 or some other number)? 01:04:24< vasi> nothing wrong with 1, just asking :-) 01:10:17< asari> vasi: I tried using your synaptic :) 01:10:28< vasi> tried? 01:10:35< vasi> does that imply it broke? 01:10:55< asari> s/tried using/used/ 01:10:56< asari> ? 01:11:09< asari> it worked well 01:11:29< vasi> oh good :-) 01:11:40< vasi> once RangerRick gets the new dpkg ready, it will be even nicer 01:13:20< asari> it was a little bit confusing for me that it requires root 01:13:56< beniamino> vasi: 1 is the first integer after 0 01:13:58< asari> I didn't know xhost + 01:14:21< vasi> asari, um i don't know "xhost +" either... 01:14:28< vasi> at least i don't think i do 01:14:43< vasi> er yeah, synaptic does need root since it installs things with dpkg 01:14:48< vasi> just like apt-get needs root 01:14:59< asari> yeah 01:15:24< vasi> beniamino: so it's just a reasonable choice for 'the first one i'm packaging'? ok! 01:15:29< beniamino> :-) 01:16:01< vasi> hasn't finished building yet...but from a cursory inspection the only thing that's wrong is you're inconsistent in Files 01:16:14< vasi> sometimes you say 'Files: lib/libjasper-1.701.1.0.0.dylib' 01:16:22< vasi> but later: 'Files: %p/bin/imgcmp' 01:16:23< beniamino> g'darn it. and sometimes %p/ 01:16:26< vasi> yeah 01:16:33< vasi> but it still works, it's just ugly :-) 01:17:40< beniamino> i think at some point, i thought 'oh no, missed the %p. how did it ever work?' and put some in. but not carefully, apparently. 01:20:30< beniamino> is either better? 01:20:32< vasi> yeah, fink is kinda inconsistent...some fields want %p, others don't 01:20:39< vasi> other can take both, Files is one of those 01:20:52< vasi> i usually prefer without, but it's up to you 01:21:39< vasi> i like that you specified the exact Files...some people depend on the SplitOffs being installed in-order, which works but is fragile 01:22:49< vasi> i gather that there's some issue about Apple including glut with OS X...i don't really know about it, but i think depending on glut rather than on macosx is probably safer...so that's a valid choice 01:23:13< beniamino> btw, your fink-tree script is cool. sw/src and sw/fink are shared nicely now, but you also mentioned ccache... 01:23:34< vasi> yeah, um i don't remember how i worked out that part, lemme check 01:23:43< beniamino> my ccache dir is ~/.ccache. so there's nothing to fix that i know of 01:24:02< vasi> ah ok...it's a bit of a story, i'll explain 01:24:20< vasi> by default, ccache uses ~/.ccache 01:24:34< vasi> that's a problem if you run fink as root, because then it stuffs root-owned stuff in your home dir 01:24:58< vasi> (assuming you have ccache-default installed, so fink uses ccache) 01:25:34< vasi> it's *bad* for root-owned stuff to be in your home dir, cuz then when you run ccache for non-fink things, it can't modify some of its files 01:25:52< beniamino> yeah, i hadn't thought about that. 01:26:00< vasi> sooo....fink now sets CCACHE_DIR to %p/var/ccache 01:26:14< vasi> but you can override that with a fink.conf parameter 01:26:34< vasi> CCacheDir: /some/dir 01:26:55< vasi> so i just have all my fink.conf's use that, set to the same dir 01:26:58< vasi> just like Buildpath 01:27:12< beniamino> ok. makes sense 01:27:31< vasi> um i forgot to mention earlier...try to make sure that all your fink trees use the same order in Trees: 01:27:48< vasi> otherwise they can get confused about where a .deb should go 01:28:12< vasi> (if you're using fink from HEAD and have UseBinaryDist on, then fink no longer gets confused this way, i think) 01:28:15-!- htodd [i=htodd@i8u.org] has joined #fink 01:28:37< beniamino> ok. so far my fink.confs are identical 01:28:45< vasi> ah, well no problem then :-) 01:29:28< vasi> i'll have to look for another reason to get you to use fink from HEAD....muhahaha, more vict--i mean, testers! 01:30:06-!- lisppaste [n=lisppast@common-lisp.net] has quit ["Common Lisp IRC library - http://common-lisp.net/project/cl-irc"] 01:30:13-!- lisppaste [n=lisppast@common-lisp.net] has joined #fink 01:30:38 * beniamino 's fingers are still horribly scarred from using darwinports HEAD 01:32:05< vasi> i heard something about them having some cool work going on in HEAD...wasn't paying too close attention tho 01:33:25< beniamino> yeah... one very cool thing is build tracing: 'port -t' gives you a list of every dep you forgot to declare 01:33:59< vasi> that sounds useful! 01:34:57< beniamino> it sure is. you'd better get coding... 01:37:47< vasi> ooh they use FORCE_FLAT_NAMESPACE though 01:37:58< vasi> we used to do that for some uses....tended to make things crash :-( 01:38:43< vasi> it's too bad, cuz they use it LD_INSERT_LIBRARIES for all kinds of things on Linux....but it's nearly impossible to get working without random crashes on OS X 01:44:14< vasi> (if you're curious, it has to do with two-level-namespace linking, and the possibility that multiple 'levels' have the same symbol...if that's true, and you force a flat namespace, boom) 01:45:51< beniamino> i'm reading up about it.. am yet to see the advantage of flat namespaces. it obviously tends towards clutter, so what's the advantage? 01:46:58< vasi> well the 'advantage' is that with a flat namespace, you can overwrite a symbol 01:47:46< vasi> with two-level linking, if two libs use the same symbol, it keeps track of which one should be used at each point...so you can't trick a program into using you custom function instead of the one it wants to use 01:48:08< beniamino> i see 01:48:42< vasi> while in a flat namespace, if you redefine a pre-existing symbol, everything has to use the new one....so you can do cool things like re-defining a system command to do something different 01:49:50-!- asari [n=asari@p4117-ipbf510marunouchi.tokyo.ocn.ne.jp] has quit ["Quitting!"] 01:50:06< vasi> there are some tricks you can use effectively for two-level stuff....like the Application Enhancer stuff that unsanity does...but it's much more complicated and invasive 01:50:55< beniamino> this starts out well: http://developer.apple.com/releasenotes/DeveloperTools/TwoLevelNamespaces.html 01:51:03< beniamino> 'The shared library implementation shipped with Mac OS X 10.0 is a robust, featureful implementation, with one small problem.' 01:53:10< beniamino> why did apple decide it was a bug, if everyone else calls it a feature? 01:54:28< vasi> they originally called it a feature 01:54:53< vasi> er, sorry 01:55:17< vasi> they originally had a lot of purists working on OS X....so something ugly like function overriding wasn't elegant enough :-) 01:55:41< beniamino> ah 01:55:51< vasi> it's true that on other Unices, it's sometimes a problem when it happens accidentally....but meh 01:56:36< vasi> hmmm, i wonder if we could use mach_override for overloading system functions? 01:56:40< vasi> that could be really neat 01:58:19< beniamino> what do you have in mind 01:58:19< beniamino> ? 02:00:43< beniamino> gotta sleep. early start. g'night 02:01:25-!- beniamino [n=ben@adsl-64-164-10-189.dsl.snfc21.pacbell.net] has quit ["Leaving"] 02:22:49-!- vasi [n=vasi@modemcable133.147-70-69.mc.videotron.ca] has quit ["Client exiting"] 02:27:33-!- ringerc [n=craig@dsl-202-72-144-62.wa.westnet.com.au] has joined #fink 02:28:22-!- broeken [n=broeken@5353014C.cable.casema.nl] has joined #fink 02:39:52-!- robval [n=Robert@nat.packetfront.com] has joined #fink --- Log opened Fri Sep 16 06:14:04 2005 06:14:53-!- gopherd [n=irclogge@tor/session/x-6176a1fdbe332449] has joined #fink 06:14:53-!- Topic for #fink: Have a question? Check the FAQ: http://fink.sf.net/faq || Latest Installers: 0.6.4 (10.2), 0.7.2 (10.3), 0.8.0 (10.4) || Fink 0.24.10: Cameloparadalis 06:14:53-!- Topic set by akh [] [Thu Aug 25 10:00:59 2005] 06:14:53[Users #fink] 06:14:53[ Airo ] [ cmeme ] [ gzl ] [ KraMer ] [ msachs ] [ ringerc ] 06:14:53[ asari ] [ das_ ] [ Henk_Poley ] [ lisppaste] [ muesli ] [ RLD_osx ] 06:14:53[ BleedAway] [ eno-away] [ htodd ] [ mcp ] [ newmanbe ] [ robval ] 06:14:53[ brendan ] [ Erik____] [ jack- ] [ mdmonk ] [ og ] [ runelind] 06:14:53[ cirdan ] [ Gavrila ] [ JosephSpiros] [ mee_bot ] [ pnorman ] [ swix_ ] 06:14:53[ Clef ] [ gecko2 ] [ jtyler__ ] [ megahal ] [ pogma ] [ usataway] 06:14:53[ cls ] [ gopherd ] [ kane_ ] [ Melian ] [ RangerAway] [ zorton ] 06:14:53-!- Irssi: #fink: Total of 42 nicks [0 ops, 0 halfops, 0 voices, 42 normal] 06:14:54-!- Channel #fink created Sun Aug 3 17:57:20 2003 06:14:55-!- Irssi: Join to #fink was synced in 2 secs 06:15:11-!- newmanbe_ [n=newmanbe@tor/session/x-48ec1d21db4b013f] has joined #fink 06:16:39< newmanbe_> !lart power outages 06:16:40 * Melian sends a legion of lawyers after power outages's head 06:17:46< gecko2> hmmm 06:18:01< gecko2> md5 /System/Library/Frameworks/Security.framework/Versions/A/Security <-- what do you get there? 06:18:26< newmanbe_> 7606eb4bedaa210fb3f5c7f79fd4fb47 06:18:47< gecko2> on 10.4.2? 06:21:08 * gecko2 got 08fb59c1815d2cfdf2f60d0f5ec26b5b and fafe6812c3342ee4c67e87a6d3e277f9 on 2 boxes with the same update level (10.4.2) 06:22:10< newmanbe_> No, Mac OS X 10.3.8. 06:22:27< gecko2> ohh 06:22:27< gecko2> ok 06:30:00< newmanbe_> Apple installed spyware in one of them. 06:38:10< gecko2> hehe 06:54:36-!- broeken [n=broeken@5353014C.cable.casema.nl] has joined #fink 06:56:11-!- _BleedAway [i=whocares@saus04.usc.es] has joined #fink 07:07:29-!- BleedAway [i=whocares@saus04.usc.es] has quit [Read error: 110 (Connection timed out)] 07:07:37-!- _BleedAway is now known as BleedAway 07:13:10-!- newmanbe [n=newmanbe@tor/session/x-33fd4df8314fcdd6] has quit [SendQ exceeded] 07:13:40-!- newmanbe_ is now known as newmanbe 07:43:50-!- broeken [n=broeken@5353014C.cable.casema.nl] has quit [] 07:53:41-!- baba [n=baba@YahooBB220041000080.bbtec.net] has joined #fink 07:53:41-!- baba [n=baba@YahooBB220041000080.bbtec.net] has quit [Client Quit] 08:05:49-!- RangerAway is now known as RangerRick 08:06:37-!- broeken [n=broeken@5353014C.cable.casema.nl] has joined #fink 08:06:59-!- xiv [n=none@62.58.106.42] has joined #fink 08:07:17< xiv> hi 08:07:55< xiv> I'm looking for a command line tool that sorts files to folders according to size 08:08:01< xiv> any ideas? 08:08:37-!- xiv is now known as x4ce 08:09:03-!- broeken [n=broeken@5353014C.cable.casema.nl] has quit [Client Quit] 08:09:03-!- shres [n=sshreyas@202.144.95.244] has joined #fink 08:11:41-!- akh [n=akhansen@ldx3.psfc.mit.edu] has joined #fink 08:18:31-!- Thiago-- [n=Thiago@200-158-228-80.dsl.telesp.net.br] has joined #Fink 08:30:38< akh> hi 08:31:01 * akh should have been mentored myself before I offered to mentor. :-( 08:31:28< akh> Either that or I just shouldn't commit packages late at night after a couple of beverages. ;-) 08:33:12< akh> Eh, could be worse--it's not like breaking cvs. 08:33:50-!- robval [n=Robert@nat.packetfront.com] has left #fink [] 08:33:51-!- geewz [n=gregreed@ppp122-142.static.internode.on.net] has joined #fink 08:35:01< shres> akh: the beverages you mentioned still active ? :-) 08:35:14< akh> shres: Not as such, no. :-) 08:35:48< akh> eww---got a call for proposals from the MIT-Microsoft alliance. 08:36:24< akh> So that answers my question about whether MIT will go to open standards like the state government is. 08:38:00< akh> oh--it's the last year of the grant. 08:38:05< cirdan> x4ce: ls can 08:38:06-!- Thiago-- [n=Thiago@200-158-228-80.dsl.telesp.net.br] has quit ["Exit... Stage Left [www.fullt.net]"] 08:42:31-!- ringerc [n=craig@dsl-202-72-144-62.wa.westnet.com.au] has quit ["zzzzz"] 08:52:51-!- geewz [n=gregreed@ppp122-142.static.internode.on.net] has quit ["Leaving"] 09:08:26-!- Gardner [n=mjg@pcp05047549pcs.ivylnd01.pa.comcast.net] has joined #fink 09:10:07-!- asari [n=asari@newsodan.sodan.ecc.u-tokyo.ac.jp] has quit ["Quitting!"] 09:11:00-!- Gardner [n=mjg@pcp05047549pcs.ivylnd01.pa.comcast.net] has quit [Client Quit] 09:25:27-!- kcp [n=kpaul@70.57.247.118] has joined #fink 09:27:14-!- shres [n=sshreyas@202.144.95.244] has quit [Read error: 110 (Connection timed out)] 09:30:05-!- lisppaste [n=lisppast@common-lisp.net] has quit ["Common Lisp IRC library - http://common-lisp.net/project/cl-irc"] 09:30:11-!- lisppaste [n=lisppast@common-lisp.net] has joined #fink 09:38:50< cirdan> akh: heh 09:53:45< akh> And I _did_ commit a fix for gnome-games to stop that thread. 10:00:48-!- x4ce [n=none@62.58.106.42] has quit [Read error: 110 (Connection timed out)] 10:02:03-!- regeya [n=shane@adsl-sp3-cdale176.micgi.com] has joined #fink 10:17:20< akh> !lilosmite gettext-dev 10:17:21 * Melian wallops gettext-dev with a main rotation server that needs rehubbing. It won't take long. 10:30:21-!- asari [n=asari@p1161-ipbf408marunouchi.tokyo.ocn.ne.jp] has joined #Fink 10:37:53< pogma> Hi asari 10:38:03< pogma> you should be in bed :) 10:38:03< asari> hi 10:39:28< asari> yes, I'm having some fruits on my bed :) 10:40:01< akh> (Which in US English could have alternate meanings...) 10:40:14< asari> oopssssss 10:40:29< akh> We know what you mean, though. :-) 11:01:13-!- asari [n=asari@p1161-ipbf408marunouchi.tokyo.ocn.ne.jp] has quit ["Quitting!"] 11:11:43-!- dmacks [n=dmacks@pool-70-22-62-248.balt.east.verizon.net] has joined #fink 11:23:12-!- hennker [i=flullup@dsl-082-083-234-072.arcor-ip.net] has joined #fink 11:26:11-!- regeya [n=shane@adsl-sp3-cdale176.micgi.com] has quit [Read error: 54 (Connection reset by peer)] 11:30:31-!- regeya [n=shane@adsl-sp3-cdale176.micgi.com] has joined #fink 11:51:11-!- mGiff [n=mGiff@ottawa-hs-209-217-84-67.d-ip.magma.ca] has joined #fink 11:53:05-!- mGiff [n=mGiff@ottawa-hs-209-217-84-67.d-ip.magma.ca] has left #fink ["Leaving"] 12:08:29< cirdan> dmacks 12:10:30< cirdan> ping 12:19:19-!- regeya [n=shane@adsl-sp3-cdale176.micgi.com] has left #fink ["Leaving"] 12:21:54-!- regeya [n=shane@adsl-sp3-cdale176.micgi.com] has joined #fink 12:35:54-!- cmeme [n=cmeme@boa.b9.com] has quit ["Client terminated by server"] 12:36:31-!- cmeme [n=cmeme@boa.b9.com] has joined #fink 12:43:49< dmacks> pong 12:44:07< cirdan> hey 12:44:17< cirdan> did you need to make any changes to cdrdao for 10.3? 12:44:23< cirdan> or was it libao that needed a change 12:44:37< cirdan> whichever it was, feel like committing the working files? :-) 12:44:50< cirdan> and/or checking cdrecord also 12:45:00< cirdan> or let me know and i'll check 12:45:55< dmacks> The files work as-is. I had a locally-created breakage (I forgot to make my libao2.patch readable so it compiled successfully but incorrectly) 12:47:00< dmacks> cdrdao.info/patch was just copied from 10.4T, no changes. 12:48:27< dmacks> I should commit it? 12:49:05-!- shres [n=sshreyas@59.92.141.161] has joined #fink 12:51:37< cirdan> ah 12:52:50< cirdan> you can commit it w/ -rev of 1 if you want 12:55:01< dmacks> Any reason not to use 10? 12:56:46< dmacks> More importantly, why the license change? 12:58:34-!- kane_ [n=kane@perl.xs4all.nl] has quit [] 13:00:34-!- regeya [n=shane@adsl-sp3-cdale176.micgi.com] has quit [Remote closed the connection] 13:02:14< cirdan> [chris@dale:~/development/cdrdao-1.2.0$]> head -n1 COPYING 13:02:14< cirdan> GNU GENERAL PUBLIC LICENSE 13:02:19< cirdan> :-) 13:02:27< cirdan> i dunno why the license changed 13:02:42< dmacks> It's explained in the .info containing the change:) 13:02:55< cirdan> dmacks: cause deps change when built on 10.3/10.4 13:03:07< cirdan> hmm, i just used an old .info.. 13:03:17< dmacks> If deps change then why aren't the (Build)Depends changed? 13:03:18< cirdan> anyway, back to work, bbiab 13:03:28< cirdan> dmacks: cuas ehte deps are auto added by fink 13:03:33< cirdan> darwin version 13:03:53< dmacks> We've never enforced that one as a reason to rev-up. 13:03:56< cirdan> stuff built on 10.4 can't be used on 10.3 13:04:11< cirdan> dmacks: still the corrrect thing to do, even if we don't enforce that policy yet 13:04:32< dmacks> Feel free to commit your package in whatever form you see fit. 13:04:32< cirdan> ok 13:04:42< cirdan> just wanted to make sure it didn't need a change 13:04:44< dmacks> ...*after* reading the license change of course:) 13:05:10< dmacks> Yeah, no changes needed from a compiling standpoint. 13:05:17-!- Murr [n=neeri@A17-202-20-71.apple.com] has joined #fink 13:10:07-!- shreyas [n=sshreyas@59.92.139.98] has joined #fink 13:19:59-!- shres [n=sshreyas@59.92.141.161] has quit [Read error: 110 (Connection timed out)] 13:23:06-!- Murr [n=neeri@A17-202-20-71.apple.com] has quit ["Quit"] 13:27:36-!- shreyas is now known as shres 13:30:09-!- lisppaste [n=lisppast@common-lisp.net] has quit ["Common Lisp IRC library - http://common-lisp.net/project/cl-irc"] 13:30:16-!- lisppaste [n=lisppast@common-lisp.net] has joined #fink 13:38:55< cirdan> dmacks: btw, cdrdao doesn't encode, so it's not restrictive at all 13:39:29< cirdan> and the lame license should be LGPL/Restrctive/can distrib 13:40:13< cirdan> it's more lgpl than restrictive...maybe a package that encodes with lame could be foo/restrictive, but the encoder by itself isn't 13:40:32< cirdan> we need fink-legal 13:40:33< cirdan> :-) 13:41:51< cirdan> the license is LGPL, but it just may need to be in a non-free section 13:42:01< cirdan> hmm, that's not a terrible idea 13:42:23< cirdan> paented stuff can go there instead of a (wrong) license change :-p 13:51:03-!- regeya [n=shane@65.171.234.176] has joined #fink 13:52:53< dmacks> The relevant issue here is whether lame can be distributed as binary. If not, then we can't have anything that depends on it be binary-available either (no holes in bindist!), and our only current mechanism for excluding stuff from bindist is via license:restricture 13:53:02< dmacks> s/ture/tive/ 13:53:16< cirdan> dmacks: there is nothing wrong with lame as a binary 13:53:23< cirdan> it's oother apps using the encoding engine 13:53:37< cirdan> only an encoder app may need a patent 13:54:05< dmacks> "license has been changed from LGPL to Restrictive, pending further clarification of the patent issue" 13:54:46< cirdan> still the patent is only for encoding 13:54:47< dmacks> Feel free to take it up with drm. 13:57:19< dmacks> htodd: Your extutils-depends-pm581 is broken (.deb doesn't validate). Please fix it. 13:59:49< dmacks> Also extutils-pkgconfig-pm581 (same problem) 14:03:06< dmacks> Also glib2-pm581 (same problem) 14:03:15< dmacks> (whoops, "glib-pm581") 14:12:17-!- shres [n=sshreyas@59.92.139.98] has quit [Read error: 110 (Connection timed out)] 14:27:58< akh> A day without updated packages is like a day without sunshine. 14:28:37-!- kcp [n=kpaul@70.57.247.118] has left #fink [] 14:29:03< akh> fscking "inconsistent dependencies" 14:29:54< akh> we hates them 14:31:09< cirdan> hatesses, my preciousses 14:32:25< dmacks> heh 14:32:38< akh> they burnss us 14:33:07< dmacks> It burns! It burns! The goggles--they do nothing! 14:33:23< akh> heh 14:33:46< dmacks> htodd: also gtk2-pm581...same deal. 14:42:51 * akh Rs TFM to figure out installed packages with no local debs. 14:43:23< cirdan> dpkg -l foo 14:43:41 * akh was looking for a "fink list" flag 14:43:52< cirdan> never heard of such a flag 14:44:07< akh> They're not in "fink list -i" anymore. 14:44:14< dmacks> ?? 14:44:23< akh> on HEAD 14:44:33< dmacks> Are they flagged *i* perhaps? 14:44:39< akh> Yup 14:44:51 * akh resorts to grep 14:45:09< dmacks> There's a list flag to show *i* pkgs. 14:45:29< cirdan> dmacks: you are a member of fink.inc? 14:45:32< dmacks> (not that this isn't broken behavior) 14:45:37< dmacks> cirdan: Maybe? 14:46:09< akh> dmacks: Did you give them their $50 and get the tote bag? ;-) 14:46:13 * dmacks has sent you $$ and helped edit the papers way-back-when, is all I know. 14:46:14< akh> Wait, that's PBS. 14:46:19< dmacks> heh 14:46:25< cirdan> yeah, no fink tote 14:46:28< cirdan> :-p 14:46:35< dmacks> Tickets to 3 Irish Tenors concert? 14:46:59< akh> ah! "fink -list -N" 14:47:35< dmacks> "-i" should list "all installed pkgs", same as it always has. 14:47:50< akh> The description didn't make it obvious that it applied in this case too. "version newer than fink knows about" 14:48:19< akh> And the buildlock packages go here now--interesting 14:48:21< dmacks> Yeah, that's a big confusing...how can it know it knows something, but then not know it? 14:52:29< akh> It's a conspiracy. :-) 14:53:15< dmacks> I bet kde/mac is flagged **i** 14:53:28< akh> heh 14:54:19< cirdan> heh 14:54:31-!- Albie [n=ambs@bl6-39-190.dsl.telepac.pt] has joined #fink 14:54:52< akh> )-: i :-( 14:55:55< cirdan> :-o i )-: 14:57:07< akh> Or :x i :x 14:57:37< cirdan> X-| 14:57:50< akh> XD 14:57:55< cirdan> DA 14:57:57< cirdan> DOA 14:58:20< dmacks> Gotta pass --NSA to see it. 14:58:28< akh> RangerRick said he may work on it once KDE4 is out. 14:58:50< akh> (or something of that effect) 14:59:00< dmacks> ...a flag that only exists when one is already in --NSA mode obviously. 14:59:15< dmacks> akh: Yeah...maybe was on the WackoBlog? 14:59:37< cirdan> Elitest News 14:59:39< cirdan> :-) 14:59:44< dmacks> Ah yeah that's it. 14:59:57< cirdan> .commie 15:00:21< RangerRick> I'm playing around with it a little right now 15:00:30< RangerRick> trying to work out what's missing int he scons build 15:00:33< RangerRick> it's a lot :) 15:00:37< akh> heh 15:00:37< cirdan> heh 15:00:39< cirdan> whee. 15:00:50< RangerRick> but it's at least flexible enough to do things right 15:07:38-!- regeya [n=shane@65.171.234.176] has quit ["Leaving"] 15:07:58< dmacks> jswhit is alive! 15:10:40< cirdan> heh 15:14:48< dmacks> akh: You could also suggest your mentee use freeglut instead of glut for x11. 'glut' development stopped ages ago, is not open-source, and has no fink pkg maintainer. 15:15:05-!- ambs_ [n=ambs@bl5-165-223.dsl.telepac.pt] has joined #fink 15:15:34-!- ambs_ is now known as ambs 15:16:14-!- vasi [n=vasi@modemcable133.147-70-69.mc.videotron.ca] has joined #fink 15:16:20< dmacks> Get him! 15:16:51< dmacks> vasi: Thanks for checking new gnome-python2 15:17:01< vasi> no prob :-) 15:17:22< vasi> what do you know about DYLD_INSERT_LIBRARIES? 15:17:28< vasi> is it safer now than it used to be? 15:17:48 * dmacks knows nothing. 15:17:54< vasi> hmm...i should bug pogma 15:17:59< dmacks> yeah 15:18:17< vasi> we use to use it for libxpg4, and it caused havoc with some two-level libs...bash and cvs would crash 15:18:40< vasi> but now dports is using it for finding missing deps, and that's useful and easily stealable 15:18:50< vasi> (it's all open source, stealing doesn't count :-) 15:18:53 * dmacks isn't surprised it's messy for 2-level. 15:19:19< vasi> i guess if it's just used at build-time, there's a low likelihood of trouble 15:19:38< dmacks> Are they really using it for non-flat stuff? 15:19:48< vasi> dmacks, only at build-time 15:19:57< vasi> but yeah, they're setting FORCE_FLAT 15:20:12< dmacks> That's a Good Thing? 15:20:42< vasi> well the Good Thing is all the crazy shit you can pull by overloading system functions 15:21:07< vasi> the Bad Thing is the possibility of crashes if there's a dup symbol....and the fact that dlsym doesn't work properly 15:21:41< vasi> i definitely wouldn't want it set during run-time like libxpg4 did...way too dangerous 15:22:01< vasi> but for building, only when a cmdline option is set, it could be worth it 15:22:23< vasi> just have a Trace: false for packages that break with tracing on 15:25:50-!- Albie [n=ambs@bl6-39-190.dsl.telepac.pt] has quit [Read error: 110 (Connection timed out)] 15:25:52< dmacks> Yeah...as long as it causes fink to die before the .deb is rolled so mis-defined stuff doesn't leak out. 15:26:05-!- ambs is now known as Albie 15:26:06< vasi> i think that's the worst case, yup 15:26:33< dmacks> Yeah. 15:26:39< vasi> we'd need to also have a way to get a list of the recursive deps...there ought to be a way to hack on Engine to that end 15:26:46< vasi> anyway, i'm adding it to the 0.26 goals 15:27:07< dmacks> Cool (I added some stuff to the existing one about build-env) 15:27:11< vasi> yeah i saw 15:27:20< vasi> i also lurk on the recently changed page :-) 15:27:38< vasi> um, for the Type: perl (or ruby, or perlModuleBuild) issue 15:27:51< RangerRick> yeah, I get the rss feed :) 15:28:19< vasi> my intention is to define those types, and others like them that want to control CompileScript and such, as "major types" 15:28:41< vasi> make it explicit that it's nonsense to have Type: perl, ruby :-) 15:29:46< vasi> then set up a class hierarchy for major types, like we do with Notify 15:30:23< vasi> so 1. it becomes easier to add a new type (python?), and 2. PkgVersion doesn't get even longer than it is 15:30:51< vasi> thoughts? 15:31:58 * dmacks has no clue what you're talking about in the explicit...nonsense here. 15:33:19< vasi> if there's a .info file with the line "Type: perl (5.8.6), ruby (1.6)" 15:33:25< vasi> what the heck is that supposed to mean? 15:33:31< vasi> it's technically legal now 15:33:35< dmacks> It means $Maintainer is an idiot? 15:33:49< vasi> :-) 15:34:53< dmacks> More politely, it is legal but can't be relied upon to do something useful. 15:34:53< vasi> yeah, there's a class of types that are mutually exclusive 15:35:12< vasi> so i just want to make explicit what those types are 15:35:31< vasi> hmm, maybe i'm going the wrong way with this...i should look into mixins 15:36:37< dmacks> The "Type" doc should be rewritten to state exactly what the magic types are. Type:ruby is not even documented anywhere. 15:37:16< vasi> ack 15:38:31< dmacks> It'd be simple to make the recursive type processor or the %type map creation function do sanity-checking. 15:40:02< vasi> i just think it's silly for the type-checking to be all if-else's inside PkgVersion 15:40:29< dmacks> Thinking of sanity, I wonder if instead of Type:PerlModuleBuildThingy being used *instead of* Type:perl to get Module::Build, it shuold be a separate Type flag? That way to convert between Makefile.PL and Module::Build, just have to change one Type flag, not all the %type_pkg[] names. 15:41:08< vasi> that's reasonable 15:43:33< vasi> what i'd like is for each magic type to have its own .pm file...which can override certain methods of PkgVersion 15:43:59 * vasi is just trying to think about the proper way to implement that 15:45:15< dmacks> That would be an interesting thing to do! 15:45:48< vasi> if there was only a way to change @ISA for a particular *object* rather than for a class? 15:46:07< dmacks> Nope...@ISA is a package-global variable. 15:46:13< vasi> yeah i know 15:46:56< dmacks> Have PkgVersion::Perl (etc) all be ISA(PkgVersion) and rebless various pkgs into the appropriate PkgVersion:: class. 15:47:20< dmacks> Then each can have a get_script() method that uses the appropriate template. 15:49:11< dmacks> (Reblessing into a child class based on some instance value or other runtime effect is pretty common in perl) 15:49:41< vasi> dmacks, but what about orthogonal magic? 15:50:27 * dmacks thinks.... 15:50:33< vasi> ie: if type 'perl' changes the CompileScript...and type, i dunno, 'rsrcfork' gets magic to preserve forks in the deb 15:50:39< vasi> there's no reason you can't have both 15:51:11< dmacks> Yeah yeah...I understand the situation, I just hadn't considered it:) 15:52:58< dmacks> Can one have anonymous classes? i.e., a class factory that generates the appropriate ISA(PV::perl,PV::rsrcfork) on-the-fly? 15:53:52< vasi> i was thinking of that...i think you could probably do it with evals 15:53:59< vasi> but it doesn't sound extremely efficient! 15:54:19< dmacks> Yeah...this is gonna be a real drain on the indexer. 15:55:12< dmacks> Hmm...Class::Factory might be a class factory. 15:55:16< vasi> maybe autoload stuff? 15:55:34< vasi> i thought it was a factory pattern? 15:56:05< dmacks> I mean the logic tree for choosing the right class(es) for each pkg. 15:56:17< vasi> yeah, that's a factory pattern :-) 15:56:48< dmacks> Ah:) 15:56:54< vasi> it doesn't really help with the orthogonality issue... 15:57:28< brendan> out of nowhere: package request 867658 (xmlto) can be closed I think, since it's in fink... 15:57:57< dmacks> Why not? Each PV::* provides methods that implement that type's magic. So PV::perl would override *Script, PV::rsrcfork would override InstallScript even further or whatever. 15:59:15< vasi> dmacks, what is PV::rsrcfork::ISA? 15:59:32< newmanbe> Hrmm. 15:59:37 * newmanbe doesn't much care for patch. 16:00:09< dmacks> brendan: Done. Thanks for noticing! 16:00:19< vasi> the idea is that something like rsrcfork can be used alone OR with another magic like perl 16:01:14< newmanbe> Or anything that gives me trouble when I try to use it. 16:02:14< newmanbe> patch just sits there, staring at me. 16:02:50< dmacks> vasi: With an anonymous class factory, each pkg becomes its own class, having ISA whatever it wants, including PV. Each PV::* Type class ISA nothing. 16:03:05< vasi> dmacks, yeah but that's not the same thing that Class::Factory does 16:03:09< vasi> it doesn't produce classes 16:03:13< vasi> it produces objects 16:03:22 * dmacks just readin' CPAN index, not specifics:) 16:03:56 * dmacks hauls out new podviewer to read about it... 16:04:34< dmacks> Yeah...it's not what I'm lookin' for. 16:05:04< dmacks> perl6 has it I think:) 16:07:59< dmacks> Sounds like I want something called an "inner class" 16:13:01< vasi> i'm working on a potential implementation...we'll see how silly it gets :-) 16:13:46< dmacks> My Config.pm that uses ref-weakening sets the bar pretty high dude. 16:16:06< akh> dmacks: OK 16:16:12< akh> (*glut) 16:16:48< akh> dammit! fink skipped removing a buildlock 16:17:31< akh> wait--sorry 16:17:41< akh> Timeout period elapsed 16:17:49< akh> My bad 16:18:49< dmacks> Class::Mix is what I want I think. 16:22:05< dmacks> Yup. 16:23:39< dmacks> (/me recalls that you said "mixins" a while ago:) 16:25:55< vasi> :-) 16:26:14< vasi> i've got a teeny-tiny generator working 16:26:23< brendan> hmm, what's the right way to install a python package that should be version independent (so I don't need type: python)? 16:26:24< vasi> but i'm not too sure how it will interact with SUPER 16:26:55< newmanbe> brendan: You mean python [python script here]? 16:27:20< newmanbe> Put #!/sw/bin/python as the first line and use the command chmod +x on it. 16:27:41< brendan> yes, but it includes a (pure) module 16:28:22< brendan> so where should the module be installed, and how should I get python to pick up the path... 16:28:49< brendan> (the package is tailor, the cross VCS synchronizing tool) 16:30:11< brendan> I could maybe create /sw/lib/python and add a PYTHON_MODULE_PATH snippet in profile.d... 16:36:18< dmacks> Better to use /usr/bin/python IMO (fewer dependencies, and fink's "python" package is confusing to users) 16:36:37< brendan> that's what I want, but I'm not sure where to put the module 16:37:02< brendan> (don't want to put it in /System of course...) 16:37:04< dmacks> Is the module private, only for use by this pkg, or are other pkgs going to want to use it? 16:37:25< brendan> Hmm, just for the package I think 16:37:32< dmacks> %p/lib/%n 16:38:41< brendan> ok. that doesn't seem like what happens when you make a type: python package though... 16:38:48< dmacks> (or %p/lib/%n/python, or whatever makes sense for internal organization there. %n in the pathname marks it as private to that %n) 16:39:04< dmacks> Right. Type:python doesn't actually *do* anything:) 16:39:36< dmacks> And most -py python pkgs contain *public* python modules so they go in the public places where python looks. 16:39:38< brendan> I mean usually the modules have their own subdirectory inside the standard module path 16:40:06< brendan> yeah, the public/private distinction is a little fuzzy 16:40:47< dmacks> That's why I asked specifically:) 16:41:24< brendan> I answered private because I don't know anything that would use the module, but nothing stops anyone :) 16:41:46< dmacks> To a first approximation, subdirectories within %p/lib/pythonX.X/site-modules are up to each module's author (not fink maintainer) to organize it that way 16:42:32< akh> Assuming a sphere. ;-) 16:42:47< dmacks> We have lots of pkgs whose whole reason for being is to provide modules for other pkgs. Those are clearly public:) 16:43:31< dmacks> Since the purpose of your package (sounds like) some executable scripts, which happen to need some modules that are supplied along with it, that sounds private. 16:43:31< brendan> yeah, leaf vs inner node is probably a better analogy for python packages than private vs public 16:44:03< dmacks> Could be. /me knows v. little python:) 16:44:09< brendan> I'll package it that way for now I guess 16:45:27< dmacks> Yeah. If you go into the common site-packages, you may have to do separate packages for each python version. 'cuz you know the minute you place it in python2.3 for public use, someone's gonna say "but I wanna use it from 2.4!" 16:45:59< dmacks> 'cuz users are like that. 16:46:32< akh> (joke) I want one for python 2.2 16:46:33< brendan> what I was thinking was creating /usr/lib/python or /usr/lib/python/site-packages and an /etc/profile.d/python that augments PYTHONPATH 16:46:34< akh> ! 16:46:43< brendan> but for this package it's probably not worth it 16:46:59< akh> I wouldn't recommend that. 16:47:30< akh> Going outside %p is only allowed in highly specific cases, when there's no other recourse. 16:47:33< brendan> no? 16:47:35-!- cianhughes [n=cian@cian.ws] has joined #fink 16:47:48< brendan> oh, meant /sw/lib, sorry 16:48:01< akh> That's OK, then. :-) 16:48:11< akh> (theoretically) 16:48:30< dmacks> Having a publicly used python-unversioned location leads to contention over which python-version's .py[co] are there. 16:49:15< brendan> well, not if there aren't any py[co] :) 16:49:16< newmanbe> Sounds like .ddl's or whatever that Microsoft thingy is. 16:50:13< dmacks> Many python packages automatically install them, so it becomes irresistable to say "this is just python, I'll go in the verisonless dir", not realizing .py[oc] get created 16:50:39< akh> newmanbe: dll's? 16:50:49< newmanbe> Yeah, that's it I think. 16:51:54< brendan> anyway don't different versions of python just give up on the compiled form if they're incompatible? 16:51:59< dmacks> .py[oc] are also created when the .py is loaded for the first time, hence python-version contension. 16:52:10< vasi> when is SUPER resolved? 16:52:24< brendan> (if you have write access to the dir, which you shouldn't) 16:52:39< dmacks> When one removes the pkg, the runtime-created stuff stays behind (because fink didn't install it, it doesn't remove it), which then confuses the hell out of fink users. 16:53:04 * dmacks has utility scripts that run as root. Doesn't everybody? 16:53:26< brendan> not me 16:53:45 * newmanbe does. 16:53:52< newmanbe> To change permissions. 16:54:52< dmacks> Point is, it's not an unlikely scenario. We could even have fink written in (or calling external) python some day. 16:55:09< akh> "Written in"? 16:55:21< brendan> that's true. I think it should be pretty harmless though 16:55:23< cirdan> dmacks: have the purge scripts rm the .py/.oc 16:55:46< dmacks> cirdan: Have the package not be written so shakily in the first place? 16:55:49< cirdan> or have them saved to ~ somewhere 16:56:50< akh> rm -rf %p 16:56:56< dmacks> brendan: We already get user complaints when there's an unexpected (runtime-created) file left alone in a directory that fink wants to remove. 16:57:02< akh> That fixes everything. :-) 16:57:23< brendan> yeah, I guess you'd need a postrm hook 16:57:30< brendan> or prerm rather 16:58:34< dmacks> It's also not uncommon to have python2.3 and python2.4 present at the same time. Seems needlessly inefficient to have them fight over whose pyc wins. And then one's prerm might remove the other's. 16:59:18< brendan> eh, that's pretty harmless, the prerm just removes compiled files if they're there 16:59:30< brendan> next time you run your root utility the python-du-jour will put them back 16:59:43< dmacks> ..."Seems needlessly inefficient" 17:00:18< brendan> so does multiple copies of modules IMHO 17:00:45< cirdan> touchee... 17:01:00< dmacks> Welcome to the world of fink supporting multiple versions concurrently:) 17:01:59< dmacks> Would we have to modify python's build script to check this new location? 17:02:23< cirdan> doubt it 17:02:32< brendan> uh, just add an environment variable i profile.d I think 17:02:37< cirdan> iirs it has an unversioned dir in it's search path 17:02:44< cirdan> iirc 17:03:05< brendan> well the apple paths are all in /System.... 17:03:14< dmacks> Apple's might. Finks' are all versioned. 17:03:40< dmacks> Nah, apple's are all versioned also. 17:03:50< brendan> PYTHONPATH should work though... 17:04:18< dmacks> Yeah, looks like it. 17:05:49-!- akh [n=akhansen@ldx3.psfc.mit.edu] has quit [] 17:05:58< dmacks> So every python-unversioned pkg needs to have a dependency on whatever pkg sets that profile.d. 17:06:16< brendan> yeah, suppose so 17:06:34< cirdan> or add it to the searchpath in python and vers.dep on that 17:06:52< dmacks> Either way, it's a non-obvious thing for a maintainer to have to do. 17:07:17< cirdan> doc it and tell 'em to RTFM when they mess it up ;-) 17:07:31< vasi> oooh: http://search.cpan.org/~chromatic/SUPER-1.10/lib/SUPER.pm 17:07:32< dmacks> And still some in-principle-unversioned pkgs would have to be versioned due to versioned dependencies (i.e., our -pm situation). 17:07:38< cirdan> seems easier than 3 diff varients 17:07:55< brendan> lots of stuff is non-obvious in the beginning 17:08:05< brendan> we just need some good demo packages :) 17:10:30< dmacks> Variants are trivial though, and early encountered in python pkgs anyway. 17:11:09< dmacks> neat vasi:) 17:11:31< brendan> alright, I don't have a module I'm dying to share right now anyway :) 17:11:34< dmacks> Class::Mix is stupid-simple to use. 17:11:51-!- Albie [n=ambs@bl5-165-223.dsl.telepac.pt] has quit ["Leaving"] 17:12:43< dmacks> I'll do a demo PV sometime...soon. 17:14:09< dmacks> dindin 17:14:10-!- dmacks [n=dmacks@pdpc/supporter/active/dmacks] has quit ["leaving"] 17:15:01< cirdan> heh 17:29:39< lisppaste> vasi pasted "mixins with NEXT.pm" at http://paste.lisp.org/display/11739 17:29:46< vasi> woops, dmacks left 17:29:50< vasi> i'll show him later 17:30:09-!- lisppaste [n=lisppast@common-lisp.net] has quit ["Common Lisp IRC library - http://common-lisp.net/project/cl-irc"] 17:30:15-!- lisppaste [n=lisppast@common-lisp.net] has joined #fink 17:33:24< brendan> vasi: saw your comment in pypar about not being able to fool lam into thinking you have two cpus. doesn't cpu=2 work? :) 17:38:43 * newmanbe wacks public radio show. 17:39:17 * newmanbe wacks basically ever general news organization for mis-reporting the same thing. 17:45:01< pogma> vasi: DYLD_INSERT_LIBRARIES is okay on 10.4 17:45:14< vasi> brendan, apparently not 17:45:17< vasi> pogma, always? 17:45:25< vasi> 'man dyld' claims not 17:45:36< brendan> (used to work for me when I was using lam a few months ago) 17:46:22< pogma> pretty sure I read in the code that it can insert into 2 level images 17:46:35< pogma> I'll check again later 17:46:58< vasi> please check....cuz it would make a much nicer liboss possible, as well as fakeroot! 17:47:11< vasi> when you have time, of course 17:47:17< vasi> thanks for being the expert, pogma :-) 17:49:18< vasi> oooh it looks like you're right! http://developer.apple.com/documentation/Performance/Conceptual/ManagingMemory/Articles/FindingPatterns.html 18:29:35-!- gopherd_ [n=irclogge@tor/session/x-bcedf3d3bfd8afd7] has joined #fink 18:29:35-!- Topic for #fink: Have a question? Check the FAQ: http://fink.sf.net/faq || Latest Installers: 0.6.4 (10.2), 0.7.2 (10.3), 0.8.0 (10.4) || Fink 0.24.10: Cameloparadalis 18:29:35-!- Topic set by akh [] [Thu Aug 25 10:00:59 2005] 18:29:35[Users #fink] 18:29:35[ Airo ] [ cmeme ] [ gopherd_ ] [ jtyler__ ] [ Melian ] [ RangerRick] 18:29:35[ BleedAway ] [ das_ ] [ gzl ] [ KraMer ] [ msachs ] [ RLD_osx ] 18:29:35[ brendan ] [ eno-away] [ Henk_Poley ] [ lisppaste] [ muesli ] [ runelind ] 18:29:35[ cianhughes] [ Erik____] [ hennker ] [ mcp ] [ newmanbe] [ swix_ ] 18:29:35[ cirdan ] [ Gavrila ] [ htodd ] [ mdmonk ] [ og ] [ usataway ] 18:29:35[ Clef ] [ gecko2 ] [ jack- ] [ mee_bot ] [ pnorman ] [ vasi ] 18:29:35[ cls ] [ gopherd ] [ JosephSpiros] [ megahal ] [ pogma ] [ zorton ] 18:29:35-!- Irssi: #fink: Total of 42 nicks [0 ops, 0 halfops, 0 voices, 42 normal] 18:29:35-!- Channel #fink created Sun Aug 3 17:57:20 2003 18:29:56-!- Irssi: Join to #fink was synced in 22 secs 18:29:58< pogma> gotta go work, dunno ... 18:30:08< vasi> alright, thanks anyhow 18:30:34< vasi> psst msachs, you around? :-) 18:31:40-!- newmanbe_ [n=newmanbe@tor/session/x-39d023aab0ed835a] has joined #fink 18:33:55-!- newmanbe [n=newmanbe@tor/session/x-48ec1d21db4b013f] has quit [Nick collision from services.] 18:34:00-!- newmanbe_ is now known as newmanbe 18:35:54-!- gopherd [n=irclogge@tor/session/x-6176a1fdbe332449] has quit [Nick collision from services.] 18:36:03-!- You're now known as gopherd 18:36:15-!- asari [n=asari@p1037-ipbf408marunouchi.tokyo.ocn.ne.jp] has joined #Fink 18:37:48-!- zizban [n=HP_Owner@24-52-0-219.sbtnvt.adelphia.net] has joined #fink 18:47:36-!- vasi is now known as vasiAway 19:06:52-!- brownjava [n=brownjav@pcp03711085pcs.westk01.tn.comcast.net] has joined #fink 19:07:28< brownjava> I have a fink question...is there any command I can type to install all of gnome in one fell swoop? I read somewhere that "fink install bundle-gnome" will work, but it doesn't for me 19:15:18< zizban> I thought so too 19:17:24< zizban> OH what version of fink? 19:17:39< brownjava> jeremy-browns-ibook-g4:~ jeremy$ fink install bundle-gnome 19:17:39< brownjava> Password: 19:17:39< brownjava> Information about 1914 packages read in 1 seconds. 19:17:39< brownjava> Failed: no package found for specification 'bundle-gnome'! 19:17:42< brownjava> the latest 19:18:01< zizban> thought so 19:18:21< zizban> gnome is still in unstable on 10.4 19:18:29< brownjava> ahh, ok 19:18:32< brownjava> should I add unstable then? 19:18:35< zizban> (gnome has no maintainer right now so work is slow) 19:18:41< zizban> if you want to use gnome, yes 19:18:45< brownjava> or just wait for it to be stable? 19:18:47< brownjava> k 19:20:34< cirdan> !tell brownjava about unstable 19:22:25 * zizban hears nothing but crickets 19:23:28-!- asari [n=asari@p1037-ipbf408marunouchi.tokyo.ocn.ne.jp] has quit ["Quitting!"] 19:28:05-!- brownjava [n=brownjav@pcp03711085pcs.westk01.tn.comcast.net] has quit [] 19:43:24-!- lisppaste [n=lisppast@common-lisp.net] has quit [Read error: 104 (Connection reset by peer)] 19:48:19-!- zizban [n=HP_Owner@24-52-0-219.sbtnvt.adelphia.net] has quit ["Leaving"] 20:08:15-!- Gavrila [n=Gavrila@213-140-16-182.fastres.net] has left #fink ["Leaving"] 20:14:11-!- beniamino [n=ben@adsl-64-164-10-189.dsl.snfc21.pacbell.net] has joined #fink 20:21:33-!- RLD_osx [n=rldempse@66-190-76-181.dhcp.dntn.tx.charter.com] has quit ["Mac OS X - - a better alternative to winblow$"] 20:22:16-!- RLD_osx [n=rldempse@66-190-76-181.dhcp.dntn.tx.charter.com] has joined #fink 20:40:45-!- baba [n=baba@YahooBB220041000080.bbtec.net] has joined #fink 20:53:11-!- Thiago-- [n=Thiago@200-158-228-104.dsl.telesp.net.br] has joined #Fink 21:13:38-!- newmanbe [n=newmanbe@tor/session/x-39d023aab0ed835a] has quit [K-lined] 21:19:16-!- gopherd [n=irclogge@tor/session/x-79aa700d2c6ea5e0] has joined #fink 21:19:16-!- Topic for #fink: Have a question? Check the FAQ: http://fink.sf.net/faq || Latest Installers: 0.6.4 (10.2), 0.7.2 (10.3), 0.8.0 (10.4) || Fink 0.24.10: Cameloparadalis 21:19:16-!- Topic set by akh [] [Thu Aug 25 10:00:59 2005] 21:19:16[Users #fink] 21:19:16[ Airo ] [ Clef ] [ gopherd ] [ jtyler__] [ msachs ] [ RLD_osx ] 21:19:16[ baba ] [ cls ] [ gzl ] [ KraMer ] [ muesli ] [ runelind] 21:19:16[ beniamino ] [ cmeme ] [ Henk_Poley ] [ mcp ] [ newmanbe ] [ swix_ ] 21:19:16[ BleedAway ] [ das_ ] [ hennker ] [ mdmonk ] [ og ] [ Thiago--] 21:19:16[ brendan ] [ eno-away] [ htodd ] [ mee_bot ] [ pnorman ] [ usataway] 21:19:16[ cianhughes] [ Erik____] [ jack- ] [ megahal ] [ pogma ] [ vasiAway] 21:19:16[ cirdan ] [ gecko2 ] [ JosephSpiros] [ Melian ] [ RangerRick] [ zorton ] 21:19:16-!- Irssi: #fink: Total of 42 nicks [0 ops, 0 halfops, 0 voices, 42 normal] 21:19:17-!- Channel #fink created Sun Aug 3 17:57:20 2003 21:19:41-!- Irssi: Join to #fink was synced in 26 secs 21:44:10-!- hennker [i=flullup@dsl-082-083-234-072.arcor-ip.net] has quit ["leaving"] 21:59:42< vasiAway> hey beniamino 21:59:44-!- vasiAway is now known as vasi 22:00:32< vasi> we looked into the tracing issue...unfortunately in 10.4.x, if Something Bad happens because of the technique use for tracing, it can happen silently 22:00:55< vasi> which makes it much less likely that we'll ever adopt that strategy 22:01:19< vasi> (depending on whether or not we get an auto-build system working any time soon) 22:02:32< beniamino> hmm.. this relates to two-level namespaces? 22:09:21-!- baba [n=baba@YahooBB220041000080.bbtec.net] has quit ["Leaving"] 22:23:16-!- _Zero_ [n=chatzill@206.188.129.109.ppp.northrock.bm] has joined #fink 22:23:25< _Zero_> Hey folks ;) 22:24:52< _Zero_> Anyone playing with Fink on x86? 22:26:40< _Zero_> I've got Darwin 8.0.1 going and I want to try and get fink working 22:29:00< vasi> Zero, we have reports of it working 22:29:16< vasi> some people at Apple are using it 22:30:06< vasi> beniamino: yeah...normally, if there's a function dup()...if libfoo has foo() which calls dup(), and libbar has bar() which calls dup()... 22:30:34< vasi> even though dup() is a duplicate, the two-level stuff keeps it all straight, so something which links to both libfoo and libbar works fine 22:30:53< _Zero_> Last install which I just wiped out it crapped on gzip when bootstrapping... if I try again figure I can get some help? 22:31:14< vasi> but to do the tracing stuff, you need to use flat namespaces....so only one of the dup() functions gets used, even though it's going to be the wrong one in some cases 22:31:22< vasi> Zero, paste the error 22:31:38< vasi> lisppaste: url 22:31:46< vasi> oh crikey, the pastebot is dead 22:31:56< _Zero_> Deal, mate! 22:32:14< _Zero_> Heh I'll throw it on a webspace no biggie 22:32:18< vasi> great 22:33:11< _Zero_> Bootstrapping through CVS is probably the way to go yes? 22:35:19< beniamino> vasi: but why the need to go flat in the 1st place? 22:35:27< vasi> Zero, yes 22:36:31< vasi> beniamino: for a flat namespace, as a side effect of the implementation (just a list of functions i believe) it's quite easy to replace a function 22:36:54< vasi> so apple can make that "just work" with no work on their part 22:37:20< vasi> but for two-level, it would be much harder to implement...cuz if you try to override dup(), which dup() should be overridden? 22:37:41< beniamino> oic 22:37:42< vasi> so it would take more work to implement, and nobody at apple has ever gone to the trouble 22:37:45 * beniamino finally catches on 22:38:31< vasi> ironically, the old behavior (from 10.2) would be better for us....then, if were are conflicting symbols in a flat namespace, you just got a crash 22:38:48< vasi> so at least that way, the worst that can happen is the build fails and you know to turn off tracing 22:39:19< vasi> but the new behavior, where one function just silently replaces another one, could introduce all kinds of bad stuff into .debs...and we'd never be sure what was causing it 22:39:38< vasi> :-( 22:48:27< vasi> beniamino: new pspp is missing InfoDocs 22:50:37< beniamino> oops... i think i got misled by DocFiles into thinking all those 'file type' fields didn't really do anything 22:55:16< vasi> but DocFiles does something 22:55:19< vasi> ? 22:55:56< vasi> also, any particular reason you're building with readline 4.3 rather than readline5? 22:57:22< beniamino> s/anything/anything cp doesn't do/ 22:58:04< beniamino> no reason for readline 4.3 -- i just hadn't twigged to the newer one 23:00:24< vasi> ah ok 23:00:35< vasi> probably want to move to the new one 23:13:07< _Zero_> Fink doesn't like bootstrapping as root does it? L) 23:13:32< _Zero_> I just found out what a PITA adding users is with netinfo lol 23:20:08< msachs> vasi: You rang? 23:20:30< vasi> msachs, yeah i was hoping you could resolve that issue pogma and i were discussing 23:20:38< msachs> Oh, I have to read stuff, eh? 23:20:46< vasi> i think we have it figured out now, but just to make sure 23:20:48< vasi> i'll tell you again 23:20:50< msachs> Gimme a minute... 23:20:55-!- drm [n=drm@ip68-108-245-119.sb.sd.cox.net] has joined #fink 23:20:57< msachs> k 23:21:02< vasi> basically, to do DYLD_INSERT_LIBRARIES 23:21:06< vasi> you still need FORCE_FLAT, right? 23:21:42< vasi> and on 10.3+, FORCE_FLAT no longer crashes if there are multiple definitions of a symbol, but instead just uses the first one it finds 23:21:53< vasi> ? 23:22:11< msachs> Mm I vaguely recall that we made some enhancements to interposing and twolevel namespaces in Tiger that means you might not need flat to do it. 23:22:31< msachs> And that sounds like the sort of thing we would've fixed, but I don't know offhand :) 23:22:34< vasi> msachs, hmm i put together a test, and it didn't seem to work without flat 23:22:38< msachs> Okay, then. 23:23:14< vasi> but both you and pogma had this vague recollection that it was fixed 23:23:40< drm> isn't there something that will be fixed in 10.4.3? 23:23:40< msachs> Well let me try my own testcase. 23:24:04< vasi> drm, i think it's the FALLBACK thing that's fixed in .3? 23:24:13< drm> oh , yeah, maybe that was it 23:30:10< msachs> Yeah, seems to not work for me w/o DYLD_FORCE_FLAT_NAMESPACE and work with it. 23:30:43< vasi> do you know if there's a way to make multiply-defined symbols cause a crash with FORCE_FLAT? 23:30:53< vasi> instead of just having one override the others 23:31:08< vasi> so at least that way we can be sure there's no data corruption going on 23:31:55< msachs> Ah, the dyld manpage says that DYLD_INSERT_LIBRARIES has no effect on two-level images unless DYLD_FORCE_FLAT_NAMESPACE is also used. 23:32:17< vasi> msachs, yes i read that...but manpages aren't known for being always up to date :-) 23:32:28< msachs> And the docs for FORCE_FLAT in the same manpage say it may cause programs to fail to execute with a multiply defied symbol error if two-level images blah blah... 23:32:35< vasi> yeah, that part seems wrong 23:32:43< vasi> at least so far as i can tell 23:32:47< vasi> but try it yourself too 23:34:28< msachs> I'm not sure how to build something that exercises that. 23:35:11< vasi> well if you search fink-devel for DYLD_FORCE_FLAT_NAMESPACE 23:35:41< vasi> you'll see that we used to get bash or cvs crashing from the same symbol occuring in ncurses and readline, i believe 23:35:44< drm> anybody have an opinion on the following issue: we have a package (stellarium) which absolutely needs g++-3.3, but depends on a library (sdl) which builds OK with g++-4.0 and in fact there are other things that depends on sdl which build ok with g++-4.0 23:36:07< drm> so I'm thinking of creating sdl-g++-3.3, just for use by the stellarium pkg 23:36:15< vasi> so i *tried* to make it happen now by putting the same symbol in two libraries, linking them together, and arranging for each library to try to call its version 23:36:29< vasi> drm, i have no objection, just give it a unique install_name 23:36:42< vasi> do we know why it absolutely needs 3.3? 23:36:46< drm> i was thinking of building it static 23:37:07< drm> sure, lots of compile-time errors with 4.0, even when the new version of stellarium is used 23:37:10< vasi> msachs, so when i tried that way, i got no crash....behavior was different from twolevel (since only one defn was actually used) 23:37:22< vasi> drm, got a log somewhere? 23:37:42< msachs> vasi: I don't really know this area of stuff too well, I have no reason to disbelieve your test cases. 23:37:55< vasi> msachs, i don't really either :-/ 23:38:04< msachs> Okay, then :) 23:38:05< vasi> got access to a 10.2.x system, maybe? 23:38:16< drm> vasi: nope... new version was posted by the maintainer in the last few days, and he even added a comment about needing g++-3.3 ot the .info file 23:38:32< msachs> vasi: I could dredge one up, but not conveniently. So what was the question, again? 23:38:55< vasi> drm, alright...just that sometimes a small issue can cause lots of errors, and there's an easy fix....or alternatively a linux distro may have a patch which they use 23:38:57< msachs> Well 3.3 isn't going to be around _forever_... 23:39:08< vasi> so it's best to move to 4.0, yeah 23:39:35< drm> msachs: let's thank our lucky stars that 2.95 has been resurrected for Tiger :) 23:39:44< vasi> msachs, the goal is to see whether the behavior that caused a crash under 10.2 also crashes under 10.3/4 23:39:48< vasi> or if it fails silently 23:40:17< msachs> Or "works silently" for some definition of works :) 23:40:23< vasi> uh yeah 23:40:25< vasi> :-) 23:40:52< vasi> you can probably repro the crash by building cvs or bash with fink on 10.2...and then run it with DYLD_FORCE_fLAT_namespace 23:40:54< msachs> If you send me an email I'll read it when I'm more awake. 23:41:03< vasi> msachs, ok 23:41:23 * drm has a coffee cup which reads "sleep is for the weak" 23:41:34< msachs> My body appears to agree with you, drm. 23:41:34< vasi> reason it matters is that darwinports uses DYLD_INSERT for some 'tracing' mechanism they have 23:41:50< msachs> Went to bed early on Sunday -- by which I mean 2:30 instead of 4:30. Of course that just meant that I woke up at 6:30... 23:41:54< vasi> the concept is cool, so if we can be sure there's no data loss we should copy it....but otherwise, prolly not 23:42:03< msachs> Gotcha, vasi. 23:42:07< drm> msachs: you back in boston? 23:42:13< msachs> drm: Yep. --- Log closed Sat Sep 17 00:00:03 2005 .