--- Log opened Tue Jun 28 00:00:08 2005
00:26 -!- shres [~shreyas@202.144.86.147] has joined #fink
00:32 < shres> hmmm... isnt xdarwin installed by default with mac os x 10.4. The cd with my power book does not seem to have it :-?
00:32  * shres aplogizes if this is a wrong place for such questions 
00:33 < htodd> it's not installed by default, usually
00:34 < htodd> lessee, which channel am I on? :)
00:34 < dmacks> alt.sex.binaries.fink
00:34 -!- lamer0 [~lamer0@c-24-30-126-12.hsd1.ca.comcast.net] has quit []
00:34 < htodd> heh
00:34 < htodd> also, you need to install the X11 SDK explicitly
00:35 < shres> isnt that in the xcode package ?
00:35 < htodd> by in, you mean on the disk?
00:37 < shres> well, when you install the xcode package. I have it on my G5 and it was installed when i installed xcode 
00:37 < dmacks> The SDK (IIRC yes, it's on XCode) is also optional and often not selected by default.
00:39 < shres> dmacks: submitting the gnomeprint2.2 v 2.8 info now. Please have a look
00:39 < dmacks> Will do when I get home in few hrs. Thanks!
00:47 < htodd> yeesh
00:47 < htodd> you get home at 4am or something?
00:48 < dmacks> Yeah, usually sometime 2-4 or so.
00:49 < htodd> the exciting life of a post-doc!
00:50  * dmacks doesn't function before noon, so /me doesn't arrive before noon:)
00:50  * dmacks also leaves early when happy-hours happen.
00:50 < htodd> :)
00:52 < shres> argh, All the sdk's packages are installed and i still cant see xdarwin. :(
00:53 < dmacks> Do you really mean "xdarwin", or "X11.app" ?
00:53 < shres> xdarwin not x11.app
00:53 -!- JesseW [~chatzilla@JesseW.student.supporter.pdpc] has quit ["Chatzilla 0.9.68a [Firefox 1.0.4/20050511]"]
00:54  * shres waits for happy hours too
00:54 < dmacks> What specifically are you looking for, and how are you looking?
00:54 -!- vasi [~vasi@modemcable214.145-70-69.mc.videotron.ca] has joined #fink
00:55 < shres> i just got this brand new machine and so i am trying to run full screen x and see if everything is ok. 
00:55 < shres> sorry, if i am acting daft but mac is pretty new for me as a development platform
00:57 < dmacks> If you installed Apple's X11 runtime code packge, you should have /Applications/Utilities/X11.app
00:59 < shres> thats not on the cd i suppose ?
00:59 < dmacks> I think it's on the Tiger disk, not the XCode one.
01:00 < shres> hmmm... interstingly i have just 2 disk. One has xcode and tiger and the other has just tiger. But the xcode package installs x11sdk
01:00 < shres> s/disk/disks
01:01 < dmacks> Right. Anything "sdk" is only compilers, C headers, other development and programming stuff. 
01:02 < dmacks> (most OS X users *don't* compile stuff, so all those files are a separate package from the shared libs and other runtime stuff)
01:04 < vasi> look at the Tiger disk, there should be X11User or something like that
01:06 < vasi> dmacks, were you looking for me at some point?
01:08 < shres> duh me, found it. sorry for being such pain. Just having a bad day. 
01:11 < dmacks> vasi: yeah, can't remember exactly why though:/ Was something about c++ ABI mess.
01:11 < vasi> miga's problems?
01:12 < dmacks> Naw, I didn't understand that one. I *think* she's making either a big deal out of nothing, or misunderstanding who's gotta be compatible with what (a la my -devel msg)
01:13 < dmacks> But I'm only starting to think seriously about this whole mess for first time in a while.
01:14 < vasi> i'm going to take a look at miga's thing anyhoo
01:14 < vasi> er, which part of our whole mess? :-)
01:14 < vasi> so many options!
01:16 < dmacks> Heh. Ah now I remember...adding a %{dist} key, so that a single .info could generate dist-specific pkgs. Goal: minimize the differences between trees to make it easier to support multiple trees.
01:16 < vasi> aha, yes that's an option
01:17 < vasi> as i've already noted, it would be nice to have a Trees: field or some such at the same time
01:17 < vasi> so that the same file could do both (main crypto) and (10.4-trans 10.4)
01:18 < vasi> major difficulty: dealing with different revisions in different trees
01:18 < dmacks> One could put it in the Revision (2.%{dist}) And teach the dep resolver to ignore any pkgs that have that token but for a different dist than the current one.
01:18 < vasi> er, the revision field is very very restricted
01:19 < vasi> ah, dot is allowed, cool
01:19 < dmacks> Ayup. Only restriction beyond Version is that hyphens are forbidden.
01:20 < vasi> er, rather than teaching the dep-resolver things, it would be best to just not include them in the PDB
01:20 < vasi> (i think)
01:20 < vasi> er, note that dist is not alpha-comparable in a good way
01:21 < vasi> (and contains hyphens)
01:21 < dmacks> Gotta make sure when dist is 10.4-real it doesn't compile against a 10.4-transitional C++ lib. So that lib would have the revision token.
01:21 < dmacks> (so we make up some derivative string instead of using the "actual" dist name)
01:21 < vasi> i thought we do the revision-bumpy-game for that?
01:22  * dmacks is proposing an alternative that avoids having to remember which rev# is where, and to do the +10 dance, and making sure not to overlap, etc.
01:22 < vasi> what do we do about situations where we need diff revisions in diff dists?
01:23 < dmacks> That's why the %dist token is in the Revision field:)
01:23 < vasi> ie: foo-1.0-1 is updated to foo-1.0-2 to fix a bug in 10.4-trans....
01:23 < vasi> but the non-trans folks shouldn't have to rebuild....s
01:23 < vasi> so what happens?
01:23 < dmacks> Does this bug also affect 10.3 folks?
01:24 < vasi> either way
01:24 < dmacks> Well if it does, then one would want to backport the fix and force the 10.3 folks to rebuild also, right?
01:25 < vasi> er, sure...what about the non-trans folks?
01:25 < vasi> we still want them to have foo-1.0-1, right?
01:25 < dmacks> Ah, 10.4-real?
01:25 < vasi> yeah
01:26 < vasi> let's call them 10.4-T and 10.4-R so we don't get confoozled :-)
01:26 < vasi> this particular case isn't important, it's the general idea...if the revisions have to be different for one of a multitude of possible reasons, what happens?
01:27 < vasi> (what if even the version or whole file has to be different, how do we deal with that?)
01:28 < dmacks> Could keep using the same old +10 (or +100) perhaps.
01:29 < vasi> just to make clear...are you proposing that the same directory-tree-of-.info-files represent multiple distribution-trees using a %dist flag?
01:29 < dmacks> No.
01:29 < vasi> or that we still have multiple dir-trees, but allow the same .info file to multiplex in a copy-it-over sort of way?
01:29 < dmacks> That's more like it.
01:30 < vasi> so the Revision munging you're talking about is related only to updating fink between dists, eh?
01:30 < dmacks> Right. I'm tired of seeing bug-fixes committed to only one or the other tree, so I'm occasionally running a diff between the trees.
01:30 -!- eno-away [~eno-away@adsl-68-123-123-227.dsl.snfc21.pacbell.net] has quit [Read error: 60 (Operation timed out)]
01:31 -!- eno-away_ [~eno-away@adsl-216-100-134-62.dsl.snfc21.pacbell.net] has joined #fink
01:31 < vasi> but right now the same .info file is supported in multiple trees
01:31 < vasi> adding a %dist field for the sake of conditionals is easy and doable
01:31 < dmacks> It sucks, because some differences are due to OS differences (poll support), while others are "I forgot to fix some Dep in the other tree"
01:32 < dmacks> So I want a way to conditionalize on "the tree I'm in"
01:32 < dmacks> (right:)
01:32 < vasi> that i have no objection to
01:32 < vasi> the Revision thing i need to think of more...hmm
01:33 < vasi> i think very recent apt support + and ~ as post- and pre- flags
01:34 < vasi> so that foo-1.0-1~foo2 << foo-1.0-1
01:34 < dmacks> I was generalizing this as a solution to the ABI "rev-up, then have to propagate that as minimum rev to everything that depends on me"
01:34 < vasi> (which is not exactly relevant, but still cool)
01:35 < dmacks> Essentially as a semi-automatic "whatever's in my tree".
01:35 < dmacks> (interesting!)
01:35 < dmacks> (solves all those damn "1.0beta12" versions)
01:36 < vasi> dmacks, i think the whole rev-bumping is kinda broken anyhow...
01:36  * dmacks agrees, but doesn't have a clean better idea:(
01:37 < vasi> i don't really agree with cirdan's idea of dummy packages, i think that's messing with fire
01:37  * dmacks agrees A LOT
01:38 < vasi> the main problem with any "solution" is that there's no such thing really as a consistent intermediate stage between all 10.4-T and all 10.4-R
01:38 < dmacks> Waht I just proposed would mean one would only have to upgrade when one tried to install something new, and only those things in the dep tree of that thing.
01:38 < vasi> at any point where you're half/half, things will almost certainly break
01:39 < vasi> so i DO like cirdan's idea of basically saying 'if you intend to do anything new now, i shall enforce that you up your whole tree'
01:40 < dmacks> Adding %dist to Revision would make it trivial to detect pkgs that are for "a different" tree.
01:40 < dmacks> ...and rebuild them in the correct order, since a wrong-dist pkg would not satisfy a dep.
01:42 -!- eno-away_ is now known as eno-away
01:43 < vasi> but the GCC field can already do that i think
01:43 < dmacks> It's not in the .deb, so there's no data in the pdb for one's "old" pkgs when one shifts to a "new" dist.
01:44 < vasi> er, why do we not put it in the deb?
01:44 < vasi> it's kinda important
01:44 < vasi> it definitely *should* be there
01:44 < dmacks> It only has an effect when one is compiling the pkg.
01:45 < vasi> yes, but we can choose to put things in the deb
01:45 < vasi> (ie: i recently added Section to HEAD)
01:45 < dmacks> Yes, but first we'd have to figure out what it shuold do:)
01:45 < vasi> and we put BDO in the deb
01:46 < dmacks> BDO has a meaning when one is using pkg as a dep, not just building it. .info not required.
01:46 < vasi> well GCC has a meaning too
01:46 < dmacks> It has never (yet) had a meaning when one is using a pkg as a dep.
01:47 < vasi> in that if you're building a GCC package, and one of it's deps as currently installed has GCC: somehting else, STOP
01:47 < vasi> my point is that it should :-)
01:47 < dmacks> :)
01:47 < vasi> rather than doing the whole revision-bumping (either +100 or N.%dist)
01:48 < vasi> if it's in the dpkg status, then we can do a reasonably simple algorithm to dist-up
01:48 < dmacks> I suggested adding GCC to .deb a while ago, everyone said "too soon to think about it". It *really* sucks to do it after many users have built of collections of .deb:(
01:49 < vasi> 1. @need_up = grep { $_->{gcc} != current_gcc } @install_packages
01:49 < vasi> 2. while there's still stuff in need_up, pop $pkg from it
01:50 < vasi> 3. if $pkg has any deps in @need_up, just unshift $pkg back onto the front of @need_up, and try the next one
01:50 < vasi> 4. otherwise, rebuild and reinstall $pkg
01:50 < dmacks> If the resolver knows to only consider pkgs whose gcc==current_gcc, step 3 is not needed.
01:51 < vasi> er that's just two different ways of checking the same thing
01:51 < vasi> whether it's done in dist-up or in the resolver is moot
01:52 < vasi> anyhow, it's NOT hard to do even with users having a collection of debs
01:52 < vasi> just START as of 10.4-R, if a package does not have GCC in the deb but has GCC in the info db, assume it's wrong
01:52 < vasi> (that means we have to be strict about GCC:, but that's what we're trying to do)
01:53 < dmacks> *if* the .info exists.
01:54 < dmacks> What happens if we have pkgs who need to retain the old GCC?
01:55 < vasi> hmm, ok i should rephrase 1 and 3
01:55 < vasi> 1 should grep { $deb->{gcc} != $info->{gcc} }
01:55 < dmacks> I'm not so sure that we really do need to force users to do a complete update of all old-abi pkgs at the time they change dists.
01:56 < vasi> 3 should check if deps have gcc != dependee's gcc
01:56 < vasi> dmacks, it's very hard to maintain a half-half situation
01:56 < dmacks> As per my -devel query, it's perfectly okay to have foo->bar->qux in 3.3 and wiff->woff->woof in 4.0
01:57 < vasi> ie: user has foo and zot which depend on bar (all need g++)....fink update foo correctly updates bar, but then what happens to zot?
01:57 < vasi> we don't do much reverse-dependency checking!
01:57 < vasi> (dmacks, i agree with that)
01:57 < vasi> (the question is, can we deal with it?)
01:58 < dmacks> "my zot isn't working" "did you update it to the pkg in the new dist?" (therefore putting %dist or a rev-up in Revision)
01:58 < vasi> dmacks, ok i nominate you to deal with all the whiny users :-)
01:58 < vasi> the idea of a package manager is that generally we shouldn't leave a system borked :-)
01:59 < vasi> i really don't like the idea of allowing updating piecemeal, and allowing it to silently break things
01:59 < dmacks> It's identical to the situation in any of the other dist changes. Folks who still had glib2 from 10.3 suddenly had broken irssi in 10.4-T
02:00 < vasi> yes, but frankly an OS change induces much less dependee-breakage than an ABI change
02:00 < dmacks> All those programs that are perl5.8.1 suddenly stop working.
02:01 < vasi> yes, which means we should have dealt with that better
02:01 < dmacks> And actually all those perl5.8.6 programs stopped working too!
02:01 < vasi> if we hadn't been scrambling to deal with Apple's borked ABI issues, we might have had time to fix those issues
02:02 < vasi> and anyhow, in most cases where 10.4 broke things, we had no way of knowing there would be breakage in advance (perl excepted)
02:03 < vasi> with the 10.4-T => 10.4-R ABI change, we *know* that things will break if we allow piecemeal updating
02:03 -!- broeken [~chatzilla@fswfirewall.fss.uu.nl] has joined #fink
02:03 < vasi> now maybe we should allow both a dist-up solution and a piecemeal approach, and tell users that "piecemeal is likely to break things but you're welcome to try"
02:04 < dmacks> Right. If we rely on the upgrade process to "uprgade everything", user is perpetually screwed if something gets missed. Or if %v++ suddenly starts using C++. Or user installs some .deb a friend of his gave him, not realizing it wasn't portable from a different dist.
02:05 < dmacks> That last issue would be an entirely new restriction I think.
02:05 < dmacks> "Ya can't cheat the resolver engine"
02:06 < vasi> "last issue"?
02:06 < vasi> most users don't realize when they're "cheating the resolver"
02:07 < dmacks> "yeah, John at work gave me his foo.deb so I installed it" but it was GCC:3.3 and I am on 4.0.
02:07 -!- beniamino [~benw@adsl-66-124-235-77.dsl.snfc21.pacbell.net] has joined #fink
02:07 < vasi> ie: if the user wants a new foo, they don't usually think "aha! but foo Dep bar, and also zot Dep bar, i guess that would be cheating the engine"
02:07 -!- beniamino [~benw@adsl-66-124-235-77.dsl.snfc21.pacbell.net] has quit [Client Quit]
02:07 < dmacks> If resolver doesn't detect that when I compile something against it, I'm now mixing ABIs.
02:08 < vasi> yeah, so we can use the GCC-in-deb to detect that on compiles, that's fine
02:08 < dmacks> I'm not opposed to a sweep-and-replace at the moment of dist-upgrade, but I don't think it's necessary or sufficient.
02:09 < vasi> in fact that's a pretty good argument for *some* kind of rev-bumping approach, since then dpkg would refuse to install something that would screw things up (at least in one direction)
02:09 < vasi> dmacks, no it's not sufficient for all cases, i think it handles *most*....we have time now, so we can test and try out several approaches
02:10 < dmacks> Simple rev-bumping is a giant nightmare, we already know...both at the start and as an ongoing issue.
02:10 < vasi> i know :-)
02:10 < vasi> it's still not worth it, but it's allowed to have upsides anyhow
02:11 < vasi> you have yet to explain to me how a piecemeal approach would deal with the pretty common situation of multiple things depending on one library
02:11 < dmacks> "it doesn't work" "update it"
02:11 < dmacks> Same as we say every time a user says that.
02:12 < vasi> *sigh*
02:12 < dmacks> Again, I'm not opposed to dist-up.
02:12 < vasi> so we'll try to give users both options?
02:13 < dmacks> Putting dist (or gcc or whatever token) in Revision majorly simplifies the job of fixing deps vs. +10 approaches.
02:13 -!- xhrl [~ThomasW@24.80.39.250] has quit [Read error: 110 (Connection timed out)]
02:14 < dmacks> I'm not entirely opposed to forcing a dist-up (I'm being swayed here:).
02:14 < vasi> (i'm actually not sure whether I want to support upgrades of any kind, *at all*...i kinda think it would be best to have an "upgrade" uninstall fink entirely, but keeping the debs that are still ok, and then allow the user to do 'fink reinstall-everything-i-used-to-have')
02:15 < vasi> er, if we DO put %dist in Revision, shouldn't it be %dist-%r instead of the other way around like you said?
02:15 < vasi> er, maybe it should even be before version?
02:17 < dmacks> Why? foo-1.0-1 was C++, then they went to pure C in 2.0. Now we gotta epoch to get correct ordering.
02:18 < dmacks> %dist-%r could be more correct than %r-%dist
02:18 < dmacks> (a "fink-epoch on the fink-revision" kind of thing)
02:20 < dmacks> We'd need to use "very large" %dist (compared to %r) then, so that %v-%dist-%r sort correctly.
02:20 < dmacks> (gotta not break if there are residual %v-%r pkgs)
02:25 < vasi> hmm, the problem is that %dist is really orthogonal to %r and %v
02:25 < vasi> ie: if something depends on foo (%dist = 4.0), it doesn't matter how high %v or %r get, they should never be enough
02:26 < vasi> but if something depends on foo (%v >= N), it doesn't matter what %dist is if %v or %r is too low
02:26 < dmacks> Right.
02:27 < vasi> (just as a wild-ass-idea, what if we had foo with GCC: 4.0 implicitly Provide foo-gcc40...and then had bar Depends: foo GCC: 4.0 implicitly also Depends: foo-gcc40?)
02:28 < vasi> that way, presumably, even dpkg and apt couldn't fuck things up
02:28 < dmacks> Interesting!
02:28 < vasi> (we'd have to munge with our dep engine a bit, but since we know the problem domain we can special-case it appropriately)
02:29 < vasi> i'm sure there's some reason this won't work...Murphy's Law dictates it....any idea what reason? :-)
02:29 < dmacks> Wait, that would require starting from scratch during dist-upgrade.
02:29 < vasi> uh, it would? couldn't we just start it with 4.0?
02:29 < dmacks> (wipe and redo, not use "fink update" or a dpkg/apt analog)
02:30 < dmacks> You're assuming ABI will never change again? Talk about tempting Murphy!
02:30 < vasi> heh, i am? you've gotta explain your reasoning
02:31 < dmacks> Okay, we got your foo abd bar installed with the implicit foo-gcc40 pkg.
02:31 < dmacks> Now I move to GCC:4.1, so I build a new foo:Provides:foo-gcc4.1
02:31 < vasi> and then bar is no good, so it needs to be rebuilt too
02:32 < dmacks> Can't install it, because it breaks bar's deps. That's good (avoids our having to walk back up the dep tree)
02:32 < vasi> er, except it has to be uninstalled first
02:32 < vasi> ugh
02:32 < dmacks> But that really sucks, by the same way users switching between -ssl/!-ssl get snagged.
02:33 < dmacks> ...and can't update bar either, because it'd first update foo, which will fail.
02:33 < vasi> but the situation is such that the whole tree from foo on up has to be rebuilt ANYWAY
02:33 < vasi> so could we just uninstall it and rebuild the whole thing?
02:34 < dmacks> Sure. start from scratch rather than using normal pkg upgrade mechanisms.
02:35 < vasi> i mean, if someone does 'fink update bar', should fink maybe notice that "crap the whole tree-rooted-at-foo has to go", tell the user and get his ok to uninstall and rebuild that tree?
02:35 < dmacks> The implicit foo-%dist pkg is clever, but would still require rev-bumping both in foo and bar, no?
02:36 < vasi> i mean, that's kinda what we WANT to have happen, right? the alternative is allowing the user to break the whole tree-rooted-at-foo (except bar)
02:36 < dmacks> Right.
02:37 < vasi> question is "how easy is it to notice this?"
02:37 < vasi> hmm, only needs the Status DB, not the PDB, that's not so bad actually
02:38 < dmacks> Right. It only matters for installed stuff, since [one or all of these proposals] already prevents future install of a wrong-dist pkg.
02:39 < vasi> ok, so is this a problem with the implicit-provides scheme, or a benefit of it? :-)
02:39 < dmacks> Both.
02:40 < vasi> ....oh
02:43 < dmacks> Why not have abi-$dist pkgs (that always exist, for all known dists). GCC:3.3 gets translated into Depends:abi-3.3, so it's easy to find all pkgs using a given ABI and try to rebuild them.
02:45 < dmacks> Ok, *fine* we'll force a complete old-ABI-pkgs upgrade during dist-upgrade:)
02:45 < vasi> hehe
02:47 < vasi> if you do want to allow a piecemeal approach using a robust solution like implicit provides on %n-gcc40, that's ok with me
02:47 < dmacks> Aw crap...we have to deal with packages that really do use the old abi.
02:47 < vasi> eh? whatcha mean?
02:47  * dmacks just grepped for "GCC: 3.1" in 10.3 trees.
02:47  * dmacks found >0 cases.
02:47 < vasi> how many?
02:48 < dmacks> 5-ish.
02:48 < vasi> 5-ish? new number i'm not acquainted with ;-)
02:49 < dmacks> Also have to figure out what to do if some self-consistent set of pkgs does not exist in the new dist. Do we nuke them entirely? Or offer piece-wise.
02:49 < dmacks> heh
02:50 < vasi> well in the 3.1 packages, i think i only see one that depends on another...and with just 5 pkgs i bet we could get them working
02:50 < dmacks> "5-ish" is an integer between 2 and 8, whose exact value is only known, if at all,  in the bit of RAM that used to contain that terminal window before I closed it:)
02:52 < vasi> er, you mean what if foo, zot Dep bar....they're all installed in 10.4T, but zot doesn't exist in 10.4R...and then the user does 'fink update foo' which would require removing zot?
02:53 < dmacks> Yes (I think you would think yes:) Or also if none of those three did (I think all could stay)? 
02:53 < vasi> i guess normally with a partial-dist-up we'd tell the user "If you update foo, the following # packages will need to be rebuilt to be compatible: <list of packages>. Pick one of: 1) Install foo and rebuild them  2) Install foo and remove them  3) Give up"
02:54 < dmacks> That's sounding awefully piecewise...:)
02:54 < vasi> if there's no good state, then i guess we either remove option 1, or try and bomb
02:54 < vasi> partial-dist-up == piecewise
02:54 < vasi> i thought that's what you were asking about?
02:55 < dmacks> No, I'm asking for a full update, the goal of which (I assume) is to return the user to the same set of installed packages.
02:56 < vasi> ah ok
02:57 < vasi> it sounds difficult to check that a future state will not be consistent, except for the easy case of "package doesn't exist anymore"
02:58 < vasi> in that easy case, we just tell the user "you won't get this one back, selfupdate some other time" (or subscribe to an rss feed or whatever)
02:58 < dmacks> Good thought.
02:59 < vasi> in the more difficult case (ie: there's a new conflict or depend, or the PDB is inconsistent) i guess we just let it fail...it seems way too hard to detect, and work around
03:00 < dmacks> Yeah. All of the save-state games we're trying to play with BuildConflicts suck that way anyway.
03:02  * dmacks wonders if we could use dist-upgrade to force other 10.{x->y}-specifc changes. Like building a real perl581 and nuking a real perl586 when going 10.3->10.4.
03:05 < vasi> yeah, that's part of cirdan's Great New Plan
03:06 -!- uncon [uncon@corp.efnet.net] has quit [Read error: 60 (Operation timed out)]
03:07 < dmacks> Maybe we should prohibit wrong-ABI stuff in a given tree? Then we could have GCC:3.3 generate an implicit Provides:gcc-abi-3.3, and each time fink runs it bitches loudly about all providers of the "wrong" one?
03:07 < vasi> i think it's ok to allow a very few old-ABI packages
03:07 < dmacks> Oh.
03:08 < vasi> as long as there are no crazy dep trees rooted at them
03:08 < vasi> but if there are one or two packages not yet ported to 4.0, with no C++ dependencies, let them stay
03:09 < vasi> stuff two generations old should maybe be prohibited
03:11 < vasi> hmm, so if we DO have a dist-up to upgrade all old-ABI stuff....how should it work?
03:12 < dmacks> That's a very good question. I didn't think about wanting to keep old-abi stuff until a few hrs ago.
03:12 < vasi> uninstall all the bad stuff? keep them all, but update them? install cirdan's silly dummy packages?
03:14 < dmacks> ...assuming we even *could* update them, since they may not appear in the new dist instantly either.
03:16 < vasi> well presumably we don't release 10.4R to non-developers until most things ARE in it
03:16 < dmacks> Aw crap, and what happens if user's build of [some pkg] fails?
03:16 < vasi> we keep the old debs and just revert
03:16 < vasi> (i guess?)
03:17 < dmacks> foo:dep:bar, we upgrade bar successfully, foo's build fails. Now we've got crossed ABIs.
03:18 -!- shres [~shreyas@202.144.86.147] has quit [Read error: 54 (Connection reset by peer)]
03:18 < dmacks> Or we just remove all old (or install dummies) first.
03:19 -!- shres [~shreyas@202.144.86.147] has joined #fink
03:19 -!- shres [~shreyas@202.144.86.147] has quit [Read error: 54 (Connection reset by peer)]
03:19 < dmacks> ("my pkg foo is missing" and "my pkg foo says its a dummy") "rebuild it"
03:19 -!- shres [~shreyas@202.144.86.147] has joined #fink
03:19 < dmacks> Sounds a lot like "my pkg foo is broken" "rebuild it"
03:20 < vasi> i don't like the dummies
03:20 < vasi> if foo fails, then we just say "sorry, this ain't working" and reinstall the old bar
03:20 < dmacks> Me neither, just figured I'd mention it since it's the same issue)
03:20 < vasi> ie: we leave the user in the old dist
03:21 < dmacks> What about qux:dep:bar, where we have upgraded if (successfully) just before starting to do foo?
03:22 -!- beniamino [~benw@209.233.196.71] has joined #fink
03:22 < dmacks> Gotta go back up the tree. Assuming we have the old .deb, which are likely unretrievable anyway since thosed.
03:22 < dmacks> s|thosed|the dists/ link is changed|
03:25 < vasi> if ANY ONE THING fails during dist-up, we revert the whole dist-up
03:25 < vasi> that's what i'm trying to say
03:25 < dmacks> Ah.
03:26 < dmacks> If the .deb are present.
03:26 < vasi> the next dist-up will still have all the .debs we built successfully, so it's not like starting from scratch next time the user tries to dist-up
03:26 < vasi> er yeah, most users should have all the necessary debs
03:26 < vasi> if they don't we warn them before
03:27 < dmacks> That's a pretty big hole that's pretty easy to dig for oneself.
03:27 < vasi> er, the vast majority of users would have debs
03:27 < vasi> since fink keeps them by default
03:28 < vasi> unless i'm misunderstanding the big hole of which speak you
03:28 < dmacks> 'fink selfupdate && fink cleanup && update OS X && fink dist-update'
03:29 < vasi> cleanup keeps current debs
03:29 < vasi> it only removes old debs
03:30 < dmacks> Ah, /me didn't realize it kept current (!= .info) ones.
03:31 < dmacks> Hold on here. We can use 'apt-cache unmet' to walk up the tree for installed pkgs.
03:32 < vasi> uh, what is 'current != info'?
03:32 < dmacks> (installed pkgs whose .info is gone)
03:33 < dmacks> (stuff from status db)
03:34 < dmacks> Piecemeal could work as a general solution if fink scanned the "unmet" output periodically.
03:34 < vasi> oh, it may very well remove those, that's true
03:34 < dmacks> (at the beginning of every 'fink update'? during indexing? at end of selfupdate?)
03:35 < vasi> just after doing an install?
03:35 < vasi> we, we'd still need a way to indicate that something is unmet :-)
03:35 < dmacks> Yeah (at the end of 'fink install', not "after installing each pkg)
03:35 < vasi> ie, rev-bumping of some sort
03:36 < dmacks> Right. Which brings us back to shoe-horning GCC (or %dist) into Revision.
03:37 < vasi> which is icky :-)
03:37 < dmacks> Better than current situation, no?
03:39 < dmacks> It doesn't help apt and dpkg folks, but then again they've *always* had a silent bug involving installing mismatched deps.
03:39 < dmacks> (So either gotta hack dpkg/apt or else use something like your implicit Provides:foo-gcc3.3)
03:41 < vasi> er, dpkg will refuse to install an update that causes a dependency to become unmet
03:41 < vasi> so how do you propose we arrange that?
03:41 < dmacks> That statement is not strictly true.
03:41 < vasi> examples?
03:42 < dmacks> Given foo:dep:bar(=1.1), install foo and bar-1.1; now install bar-1.0
03:43 < dmacks> What if we use Suggests:foo-gcc3.3 (instead of Depends)? That way user can upgrade foo, but then unmet will detect that what-depends-on-foo needs to be updated.
03:44 < vasi> eww, that's almost as bad as dummy packages
03:45 < dmacks> Yeah, but not quite:)
03:45 < vasi> if we're gonna do piecemeal, and detect problems, let's at least look at the installed packages ourselves
03:45 < vasi> rather than tricking dpkg to do it for us using some unholy combination of weirdness
03:46 < dmacks> Okay. What's wrong with our current rev-up approach?
03:47 < dmacks> It's a huge pain, but it works.
03:47 < dmacks> Except that it allows a dependent to be upgraded without the depends-on-it to be upgraded.
03:48 < vasi> yes, so a user can silently break packages
03:48 < vasi> or rather fink will do it for them
03:48 < dmacks> Right.
03:48 < vasi> Good: no initial work for us
03:48 < vasi> Bad: lots of users will whine
03:49 < dmacks> So we use unmet to tell users (heck, offer and default to "yes, unbreak my stuff") at the end of 'fink install'
03:49 < vasi> Also bad: we still need to put in work bumping revs
03:50 < dmacks> Right. Putting %dist or GCC into rev handles that though.
03:51 < vasi> ok, two problems...first it means we have to figure out how to deal with putting GCC in %r such that it doesn't interact badly with the orthogonal normal function of %r
03:51 < vasi> second, and more seriously, we have to find a way to make rev-bumping cause unmet deps
03:52 < vasi> ie: the packages already installed, how does dpkg know they're no good?
03:54 < vasi> (oops...uh, where 'dpkg' = 'apt')
03:55 < dmacks> Hrm, I guess we'd have to teach dpkg that foo-1.0-1dist104t doesn't satisfy bar:Depends:foo if bar's rev is not also *dist104t
03:55 -!- Feanor [~astrange@feanor.developer.opendarwin] has quit []
03:57 < dmacks> (that solves the orthogonality issue: no foo-%v-%r from the wrong dist could ever satisfyt, no matter how high the %v-%r; that's actually a major step up from what we do now)
03:59 < dmacks> ("dist" would be our special-meaning delimiter within the full %r field)
04:02 -!- beniamino [~benw@209.233.196.71] has quit ["The computer fell asleep"]
04:03 < dmacks> Okay, my brane is full, I go bed now. Thanks for contemplating along with me here.
04:04 -!- dmacks [~dmacks@dmacks.active.supporter.pdpc] has quit ["leaving"]
04:04 < vasi> toodles
04:38 -!- vasi [~vasi@modemcable214.145-70-69.mc.videotron.ca] has quit []
06:08 -!- hennker [flullup@dsl-082-082-234-042.arcor-ip.net] has joined #fink
06:28 -!- vasi [~vasi@modemcable214.145-70-69.mc.videotron.ca] has joined #fink
06:31 -!- Netsplit kornbluth.freenode.net <-> irc.freenode.net quits: bender|
06:33 -!- Netsplit over, joins: bender|
07:12 -!- Netsplit kornbluth.freenode.net <-> irc.freenode.net quits: bender|
07:15 -!- Netsplit over, joins: bender|
07:15 -!- Netsplit kornbluth.freenode.net <-> irc.freenode.net quits: bender|
07:15 -!- Netsplit over, joins: bender|
08:06 -!- lstryder [~lstryder@84.92.238.159.broadband.plus.dyn.plus.net] has joined #fink
08:07 -!- lstryder [~lstryder@84.92.238.159.broadband.plus.dyn.plus.net] has quit [Client Quit]
08:29 -!- theid [~theid@12-218-61-181.client.mchsi.com] has quit []
08:40 -!- ralfWORK [jwalker@flynn.smearcampaign.org] has quit [Read error: 104 (Connection reset by peer)]
08:41 -!- ralfWORK [jwalker@flynn.smearcampaign.org] has joined #fink
08:42 -!- qiqo [~qiqo@210.213.233.190] has joined #fink
08:47 -!- lstryder [~lstryder@84.92.238.159.broadband.plus.dyn.plus.net] has joined #fink
08:47 < lstryder> i'm getting consistent bounces from the mailing lists upon subscription request
08:48 -!- qiqo [~qiqo@210.213.233.190] has left #fink []
08:53 -!- dk0r [~dk0r@cpe-24-194-167-76.nycap.res.rr.com] has joined #fink
08:55 -!- ringerc [~craig@dsl-202-72-144-62.wa.westnet.com.au] has joined #fink
09:02 -!- newmanbe [~newmanbe@madinina.de] has joined #fink
09:07 < newmanbe> Hehehe. /me just installed a package from Debian.
09:08 < newmanbe> No non-free free packages on my computer, rms would be proud.
09:08 < newmanbe> Not.
09:08 -!- You're now known as RangerRick
09:08 < pogma> lstryder: use the web interface
09:09 < lstryder> pogma: i do. when i confirm my request, the confirmation is bounced; or am i missing something?
09:09 < pogma> morning RangerRick 
09:09  * robilad grumbles about panther printing fudged fonts
09:09 < pogma> lstryder: hmm, what address to you send the confirmation to?
09:10 < lstryder> pogma: fink-users-request@lists.sourceforge.net
09:10 < RangerRick> mornin'
09:10 < pogma> strange, can you lisppaste the bounce message?
09:10 < RangerRick> lisppaste: url
09:10 < lisppaste> To use the lisppaste bot, visit http://paste.lisp.org/new/fink and enter your paste.
09:12 < lisppaste> lstryder pasted "Fink users mailing list bounce" at http://paste.lisp.org/display/9462
09:13 < pogma> is formofthought.com your host?
09:13 < RangerRick> lstryder: looks like your ISP is rejecting it
09:14 < RangerRick> hrm, wait, no
09:14 < pogma> can you enable a postmaster account on that box?
09:14 < RangerRick> looks like they're rejecting your postmaster  :)
09:14 < pogma> it is checking for spam by looking to email postmaster on the sending host
09:15 < pogma> I had to enable postmaster@pogma.com for the same reason :)
09:15 < RangerRick> tsk, didn't have it?  :)
09:15  * RangerRick installs itunes 4.9
09:15  * newmanbe doesn't.
09:16 < newmanbe> I suppose Software Update will want me to install it even if the new features only working on Mac OS X 10.4.
09:16 < pogma> RangerRick: I had had it, but removed it in an attempt to reduce spam, but that just broke sf's attempt to reduce spam...
09:16 < RangerRick> why would the new features only work on 10.4?
09:16 < pogma> so I had to put it back :)
09:16 < newmanbe> RangerRick: I don't know, but that's what the last update for iTunes said.
09:16  * newmanbe doesn't use iTunes anyways.
09:16 < RangerRick> ah
09:17  * RangerRick loves itunes
09:17  * lstryder does too
09:17 < newmanbe> JuK!
09:17 < RangerRick> maybe if I could get a native version compiled  :)
09:17 < lstryder> 4.9 is supposed to have podcast subscription built into it, doesnt it?
09:17 < RangerRick> yeah
09:18 < lstryder> pogma: so do you use the postmaster@pogma.com address for mailing lists?
09:19 < lstryder> pogma: as in subscribing to lists, not administering them
09:19 < RangerRick> lstryder: no, it's just that spammers' mailers tend to not have postmaster@ addresses, so sourceforge won't accept any mail to mail servers that don't have one
09:19 < RangerRick> you don't have to *use* it for anything, just accept it
09:20 < lstryder> ah, i see (total noob when it comes to server-side email admin)
09:29 < lstryder> RangerRick: have you tried the podcast directory in 4.9 yet?
09:29 < RangerRick> nope
09:29 < RangerRick> just finished installing
09:30 < RangerRick> doing my ipod update first
09:30 < lstryder> ok
09:34  * RangerRick wonders idly if 10.4.2 is coming soon
09:34 < RangerRick> no reason, just wondering
09:34 < RangerRick> *cough*
09:34 < RangerRick> ;)
09:35 < pogma> beats me
09:35 -!- uncon [uncon@corp.efnet.net] has joined #fink
09:35  * RangerRick looks at a huge list of reversioners
09:35 < pogma> been "coming soon" for quite a while now
09:36 < RangerRick> and the last few have had actual descriptions in the installer  ;)
09:37 < RangerRick> reminds me, I've gotta tell apple that I fixed my wireless problem by moving the old prefs file out of the way  :)
09:37  * RangerRick goes to bugreporter
09:47 -!- akh [~akhansen@jove.psfc.mit.edu] has joined #fink
09:48 -!- pogma [~peter@pogma.developer.opendarwin] has quit [Remote closed the connection]
09:49 -!- dreamind [~dreamind@C2107.campino.wh.tu-darmstadt.de] has joined #fink
09:50 -!- dreamind [~dreamind@C2107.campino.wh.tu-darmstadt.de] has quit [Client Quit]
09:52 -!- jtyler [~jtyler@iphost-64-56-130-194.edm.wiband.net] has joined #fink
09:53 -!- dreamind [~dreamind@C2107.campino.wh.tu-darmstadt.de] has joined #fink
09:54 -!- pogma [~peter@p1174-ipad212kobeminato.hyogo.ocn.ne.jp] has joined #fink
09:54 < pogma> summer is coming, router's getting hot
09:55 -!- broeken [~chatzilla@fswfirewall.fss.uu.nl] has quit ["Chatzilla 0.9.68a [Firefox 1.0.4/20050511]"]
09:55 < newmanbe> Summer is here here.
10:05 < akh> newmanbe: I present you with this Certificate of Redundancy Certificate.  ;-)
10:06 < newmanbe> I thank you with all the thankfulness in the world.
10:06 -!- mode/#fink [+o pogma] by ChanServ
10:07 < akh> heh
10:07 <@pogma> bye newmanbe
10:07 -!- newmanbe was kicked from #fink by pogma ["see ya"]
10:07 -!- newmanbe [~newmanbe@6d6aca167cb98485.session.tor] has joined #fink
10:07 < newmanbe> Hmm, auto-rejoin.
10:07 <@pogma> heh, auto-rejoin
10:08 -!- mode/#fink [-o pogma] by pogma
10:28 -!- baba [~baba@YahooBB220041001026.bbtec.net] has joined #fink
10:48 < vasi> grrr, why can't Software Update understand that i *don't want* iPod updates?
10:49 < vasi> they all have different names, so ignoring it doesn't seem to work...grrr
10:49  * vasi has more fun growling
10:49 < pogma> just grin and bear it
10:49 < vasi> but it's hard to growl while grinning....
10:49 < pogma> lol
10:49 < vasi> :-)
10:50 < pogma> it really is easier to just accept all software updates
10:51 < pogma> they have zero clue how to deal with software packages @apple, imo
10:51 < vasi> hey pogma, what are your thoughts on whether/how we should allow upgrades from  10.4-transitional (henceforth 10.4-T) to 10.4-gcc4.0 (or whatever, henceforth 10.4-R for "real") ?
10:51 < vasi> (speaking of having zero clue how to deal with software packages.... ;-)
10:51 < pogma> we need to allow people to update, this means rev up random number for c++ packages
10:52 < pogma> and versioned deps, unfortunately
10:52 -!- zizban [~chris@24-52-0-219.sbtnvt.adelphia.net] has joined #fink
10:53 < vasi> a problem dmacks and i have been discussing is if packages foo and zot both depend on libbar....assume all are C++ and all are installed under 10.4-T
10:53 < vasi> if the user upgrades to 10.4-R, and then does 'fink update foo' it will also update bar (from the versioned dep)....but then zot will silently break
10:53 < cirdan> hey
10:53 < vasi> hiya cirdan :-)
10:54 < cirdan> vasi yeah, i've been saying that for a long while now
10:54  * cirdan hears echos
10:54 < cirdan> ;-)
10:54 < pogma> vasi: his zot is out-of-date
10:54 < vasi> pogma, yes
10:54 < pogma> vasi: not our fault
10:54 < vasi> no, not our fault, but we'll get blamed anyhow
10:54 < vasi> so we might wish to avert disaster :-)
10:55 < akh> fink broke my zot
10:55 < akh> ;-)
10:55 < pogma> vasi: I see where you are coming from, but what are your suggestions for aversion of disaster
10:55 < cirdan> that was why i was gonna try to make empty dummy packages so zot isn't available until it's rebuilt
10:55 < vasi> watch it akh, or i'll break your %$#%^ zot!
10:55 < pogma> vasi: 10.4 tree will not be made available without zot
10:55 < vasi> pogma, there are various ideas
10:56 < vasi> we could force update-all when the user moves to 10.4-R
10:56 < vasi> or, we could detect when a library is being updated to a new ABI and has something depending on it, and warn the user (or do something about it, eg: uninstall/rebuild)
10:56 < cirdan> vasi: that's fine, but update-alls fail
10:57 < vasi> cirdan, i said they're ideas, i didn't say they're perfect
10:57 < pogma> vasi: thing is, we've had this problem with every tree move
10:57 < cirdan> i know :-)
10:57 < vasi> clearly each possibility has it's ups and downs
10:57 < pogma> vasi: and we've just said F' it.
10:57 < vasi> pogma, well at least with upgradeable moves
10:57 < RangerRick> yeah
10:58 < RangerRick> if we up the version on anything c++ or anythign depending on it, and up the req for that new version, an "update-all" should be solution enough  :)
10:58 < cirdan> also: we need to discuess the policy of debs needing to be identical....
10:59 < vasi> yes, update-all solves things, we just have to make sure users actually do it i guess
10:59 < vasi> cirdan, do you mean the shlibs issue? or something else?
10:59 < cirdan> we have many cases of debs with the same version-rev and they are different
11:00 < pogma> differences in description fields etc. have always been mildly OK
11:00 < cirdan> like foo-1.0-1 in the 10.3 tree might get to foo-1.0-10...but the 10.4 tree starts with foo-1.0-10
11:00 < cirdan> overlap creates different packages w/different deps
11:00 < vasi> (one other thing, does anybody mind if we put the GCC: field in debs? so it will be in the dpkg status DB, and we can actually tell if a user has old-API stuff)
11:00 < pogma> heh, thought drm was on vacation n Turkey
11:01 < pogma> what's he doing committing stuff?
11:01 < vasi> cirdan, so start at 100 in 10.4 :-)
11:01 < RangerRick> vasi: that's a good idea
11:01 < cirdan> vasi: not a bad idea, suggested sokething like that before
11:01 < vasi> dmacks is ok with it too, so i'll add that to HEAD soonish
11:01 < cirdan> vasi: rev bumps are random
11:02 < cirdan> we have no real policy
11:02 < vasi> cirdan, that's true
11:02 < cirdan> that's why I wanted 10.x-rev to be the rev
11:02 < pogma> cirdan: policy is "bump rev enough so that there can be no overlap"
11:02 < cirdan> or even just 10.x.rev
11:02 < vasi> cirdan, the problem with that is that %dist is orthogonal to %r
11:02 < vasi> they mean different things
11:03 < vasi> so it can get awkward if you try to do fancy things with it
11:03 < cirdan> but %dist is directly related to deps
11:03 < cirdan> and different deps means different %r
11:03 < vasi> if you just want it as a prefix, that's ok (but only use allowed symbols in %r)
11:04 -!- beniamino [~benw@209.233.196.71] has joined #fink
11:04 < cirdan> well, the main argument against using %dist in %r was that maintainers just copy .info files blindly between trees and they build exactly the same
11:05 < cirdan> if we enforce %r to have no overlaps somehow, both arguments are then false
11:05 < vasi> i'm just being anal about it because dmacks was talking earlier about putting %dist in %r so that we could detect older packages
11:05 < vasi> and so we could set depends on >= %v-%dist-%r and such
11:05 < pogma> seems easy enough, darwin8 revs are 8XXX, darwin9 9XXX etc
11:06 < cirdan> vasi: it helps, but not really, because we have different abi's for 10.4
11:06 < pogma> but that is just pointless compiling for packages that work on update
11:06 < vasi> cirdan, yeah so if you don't want to do anything facny (such as ABI detection) then sure, use %dist in %r
11:06 < cirdan> pogma: not pointless, just extra, to make sure everything is updated to a supported version
11:06 < vasi> i don't care what scheme you use
11:07 < cirdan> vasi: well, 10.4t and 10.4 could be used in the diff trees
11:07 < cirdan> vasi: and i'm talking about general policy, not just for my packages
11:07 < vasi> cirdan, in that case no
11:08 < vasi> many packages should NOT need a rebuild, this forces it
11:08 < cirdan> pogma: yes, but 8xxx makes less sense to the user than 10.x.xxx
11:08 < cirdan> vasi: it doesnt force it unless you update all
11:08 < cirdan> and the deps will not be the same for the same deb-%v-%r, which is my entire point
11:09 < cirdan> vasi: only versioned deps force it
11:09 < vasi> cirdan, for pure-C packages the deps WILL be the same
11:09 < cirdan> vasi: no, they will not
11:09 < vasi> why not?
11:09 < cirdan> we make them different, leaving aside the libsystem and support libs issues we had long ago
11:10 < cirdan> every package has a darwin version depends
11:10 < vasi> the darwin dep doesn't change for an ABI update...
11:10 < cirdan> >= than the system that was used to build
11:11 < cirdan> people sometimes get conused when they try to install 10.4 packages on 10.3
11:11 -!- beniamino [~benw@209.233.196.71] has quit ["The computer fell asleep"]
11:11 < cirdan> everything looks good, it just refuses to install, and if it's forced, it'll break
11:11 < vasi> but we're talking about an API upgrade
11:11 < vasi> er, ABI
11:11 < vasi> the version of darwin doesn't change
11:12 < cirdan> i'm talking about the osx version in the %r, not so much the actual tree
11:12 < vasi> well you gave 10.4t and 10.4 as examples :-P
11:12 < cirdan> although the tree would ease some deps, where they are needded
11:13 < cirdan> cause dmacks's idea
11:13 -!- kikov [~kikov@190.Red-83-39-208.pooles.rima-tde.net] has joined #fink
11:13 < kikov> who was the KDE-Mac man?
11:14 < zizban> That'd be RangerRick 
11:14 < vasi> RangerRick, primarily
11:14 < cirdan> RangerRick: :-p
11:14 < kikov> ok, thx... 
11:14 < vasi> cirdan, we just need an unstable bindist...so users can apt-get dist-upgrade and it will do all the work
11:14 < kikov> today has been complete a milestone.. Qt4 :)
11:14 < vasi> that will solve all our problems :-)
11:14 < zizban> don't pester him about an update ''cuse he gets really angry :P
11:15 < zizban> just ask nicely pray he doesn't rip your head off
11:15 < cirdan> vasi: yes, then the rebuilds between trees don't matter so much :-p
11:17 < kikov> zizban, this message is to me?
11:19 < zizban> relax, it was a joke :)
11:20 < vasi> zizban, it was? :-)
11:20 -!- baba [~baba@YahooBB220041001026.bbtec.net] has left #fink ["Leaving"]
11:20 < zizban> :)
11:20 < kikov> zizban, I have been talking to him several times about that...
11:20 < zizban> cool
11:21 < kikov> indeed, I want to help him with KDE packages... I'm quite interesting, besides that, I have experience in packaging for Debian and Gentoo
11:21 -!- baba [~baba@YahooBB220041001026.bbtec.net] has joined #fink
11:21 < kikov> and as I have seen in the fink Development manual, fink it's a mixure of both... :)
11:21 < zizban> that's awesome. Any help is greatly appreciated
11:22 < kikov> RangerRick, ? hello?
11:23 < pogma> kikov: he may be @work and busy
11:23 < pogma> email, as usual will find and eventual reply
11:25 < kikov> email?
11:25 < kikov> what's email?
11:26 < zizban> heh
11:26 < zizban> or just hang out here, he'll show up eventually
11:29 < kikov> Ok.. Benjamin Reed is KDE fink kde maintainer...
11:29 -!- dk0r [~dk0r@cpe-24-194-167-76.nycap.res.rr.com] has quit []
11:30 < zizban> aka RangerRick
11:33 < kikov> zizban, yes.. I was looking his email... I have got it... 
11:34 < zizban> cool
11:34 < kikov> he has a different email by each package [PACKAGE]@fink. BLAHBLAHBLAH
11:34 < zizban> ya :)
11:36 -!- megahal [~astrange@100-241.35-65.tampabay.res.rr.com] has quit [Remote closed the connection]
11:37 < kikov> sent
11:38 < zizban> cool
11:39 -!- linuxmaniac [~maniac@84-120-48-49.onocable.ono.com] has joined #fink
11:43 -!- megahal [~astrange@100-241.35-65.tampabay.res.rr.com] has joined #fink
11:46 < kikov> well.. compiling qt4 opensource mac native version here :)
11:47 < zizban> wow. cool
11:47 < kikov> I'm wondering if Qt4 will be backwards compatible... or at least if kdelibs3 could compile with this... we could have amarok running natively on macosx :) without X :)
11:49 < zizban> I would think so
11:49 -!- Stereo [~stereo@hertz.stereo.lu] has quit ["rebooting"]
11:49 < kikov> umm. but not. it's not possible.. KDElibs has a lot of X11 hacks.. :/
11:49 < zizban> I'm no expert but it would suck if qt4 apps didn't work with qt3 apps
11:49 < cirdan> zizban: they wont, i bet
11:49 < cirdan> qt2 apps dont work with qt3
11:49 < kikov> yes.. it's a major version
11:50 < zizban> oh
11:50 < zizban> true
11:50 < kikov> help is provided to port... ( deprecated functions and so.. )
11:50 < kikov> and now, there is a porting apps that change a bit your code to adapt to qt4... 
11:50 < vasi> yeesh, parsing C++ isn't easy
11:51 < kikov> and Qt4 is a revolution compared to Qt3... a lot of things have been changed... a lot of structures have been removed... 
11:52 < kikov> it's not adding new functionality, but purging old parts, and optimizing, and redesigning...
11:52 < kikov> ( as far I have heard, Qt4 is up to 30% faster when drawing )...
11:54 -!- lstryder [~lstryder@84.92.238.159.broadband.plus.dyn.plus.net] has quit []
11:56 -!- lstryder [~lstryder@84.92.238.159.broadband.plus.dyn.plus.net] has joined #fink
12:02 < vasi> ooh speed is good
12:03 < zizban> what command does one use to untar a .tar (no .gz) file?
12:04 < vasi> tar -xf foo.tar
12:04 < zizban> ah thanks
12:04 < vasi> zizban, i have a general expansion script that i can send you if you want
12:04 < vasi> it lets you just do 'var <any archive>' and will usually do the right thing
12:05 < zizban> hmmm
12:05 < zizban> cool send
12:06 < vasi> tell me if you find any bugs :-)
12:06 < zizban> ok
12:07 < vasi> hmm, DCC not working?
12:07 < zizban> I see the window here
12:07 < zizban> hold on
12:08 < zizban> weird
12:09 < zizban> can you email it to me? zizban@gmail.com?
12:09 < newmanbe> vasi: Make a Fink package for it!
12:09 < vasi> i just put it in experimental/vasi/scripts
12:09 < vasi> newmanbe, it's not THAT impressive
12:10 -!- dk0r [~dk0r@cpe-24-194-167-76.nycap.res.rr.com] has joined #fink
12:10 < newmanbe> Fine, make a DariwnPorts port file.
12:10 < vasi> *sigh*
12:10 < zizban> heh
12:12 < cirdan> hehe
12:12 < zizban> heh
12:12 < dk0r> hoho
12:12 -!- f4ng [~Fang@2002:53cd:a70b:1:0:0:0:1] has joined #fink
12:12 < newmanbe> IPv6
12:14 -!- f4ng is now known as Fang
12:17 < dk0r> mac can write to fat32's hd correct?
12:17 < newmanbe> Yes, for a long time.
12:17 < dk0r> are you being a dick? or.. 
12:17 < dk0r> thhey can?
12:17 < newmanbe> It has been able to do that pre-Mac OS X.
12:17 < dk0r> why not ntfs?
12:18 < dk0r> just because?
12:18 < newmanbe> I know there is read only support.
12:18 < dk0r> yep
12:18 < dk0r> ok
12:18 < dk0r> ty!
12:18 < newmanbe> I thought there was write support too.
12:18 < dk0r> not for ntfs
12:18 < dk0r> where did u read that?
12:18 < newmanbe> Somewhere on apple.com...
12:19  * newmanbe finds vasi's script in experimental.
12:19 < dk0r> tiger has 'better' ntfs support
12:19 < dk0r> but that does not include writting
12:20 < newmanbe> !google
12:20 -!- vasi [~vasi@modemcable214.145-70-69.mc.videotron.ca] has quit [Read error: 104 (Connection reset by peer)]
12:23 < zizban> what's a Shape extension?
12:26 < zizban> never mind, figured it out
12:26 < zizban> cursed makefile
12:26 -!- vasi [~vasi@modemcable214.145-70-69.mc.videotron.ca] has joined #fink
12:26 < zizban> brb
12:26 -!- zizban [~chris@24-52-0-219.sbtnvt.adelphia.net] has quit ["Leaving"]
12:31 -!- baba [~baba@YahooBB220041001026.bbtec.net] has quit ["Leaving"]
12:35 -!- lstryder [~lstryder@84.92.238.159.broadband.plus.dyn.plus.net] has quit [Read error: 110 (Connection timed out)]
12:36 < akh> heh--package request on -devel where there isn't even a *nix port of any sort.
12:37 < cirdan> ?
12:37 < newmanbe> The NASA one?
12:37 < akh> yup
12:37 < cirdan> heh
12:38 < akh> Sounds like a job for Windows on an x86 Mac.  ;-)
12:39 < dk0r> heh
12:40 < newmanbe> Isn't C# a Microsoft Windows-only programming language?
12:41 < newmanbe> Hmm, most of you probably wouldn't know that.
12:41 < newmanbe> If it indeed is.
12:41 < akh> I think so.
12:42 < akh> Maybe it could be ported to use gtk-sharp...
12:43 < akh> (/me is extrapolating from the single data point of mono)
12:45 < newmanbe> http://lynx.browser.org is never up-to-date.
12:46 < cirdan> newmanbe: mono coes C#, iirc
12:52 -!- kikov [~kikov@190.Red-83-39-208.pooles.rima-tde.net] has quit ["This computer has gone to sleep"]
12:55 -!- zizban [~chris@24-52-0-219.sbtnvt.adelphia.net] has joined #fink
12:57 -!- mdmonk_a1ay is now known as mdmonk_nothere
13:03 < akh> hmmm...xfree86 refers to a now nonexistent xfree86-upgrade package.
13:03 < zizban> gott love it
13:04 < zizban> fink is a monster now...it's uncontrollable
13:04 < zizban> or something
13:05 -!- dk0r [~dk0r@cpe-24-194-167-76.nycap.res.rr.com] has quit []
13:09 < zizban> bbl
13:10 < runelind> anyone using gaim?
13:10 < runelind> it takes _forever_ for it to launch for me
13:23 < RangerRick> runelind: probably fixed in 10.4.2, might be able to update-all with unstable and get a fix (not sure which glib2 gaim is using)
13:24 < runelind> RangerRick: I have been using unstable
13:24 < runelind> and it gave me v 1.3.1
13:25 < runelind> it is not a huge deal, just annoying to wait for like a minute for it to launch
13:25 < akh> That's an OS issue.
13:25 < akh> (as RR said)
13:26 < RangerRick> dlsym is broken on 10.4.x lower than 10.4.2
13:26 < RangerRick> which is what everyone has at the moment, except for seed key holders  :)
13:26 < runelind> hopefully 10.4.2 will be out real soon now (tm)
13:26 < RangerRick> a few packages have workarounds
13:26 < RangerRick> but some don't
13:26  * akh hasn't tried out my 10.4.2 setup yet.
13:26 -!- Murr [~neeri@A17-202-20-71.apple.com] has joined #fink
13:27 < akh> D'oh!  Just a new iTunes and iPod updater....
13:27 < runelind> akh: but we get podcasting now :D
13:27  * runelind cheers
13:27 < cirdan> yay
13:27 < Murr> is there any non-system xfree86 package that is binary compatible with system-xfree86
13:27 < runelind> now I just have to start lobbying NPR to podcast cartalk for free :D
13:28 < cirdan> runelind: hehe
13:28 < RangerRick> Murr: they're all supposed to be
13:28 < RangerRick> although it looks like on tiger there might be issues with some gl stuff
13:28 < RangerRick> because it uses c++
13:28 -!- linuxmaniac [~maniac@84-120-48-49.onocable.ono.com] has left #fink ["Me voy de este canal!!"]
13:28 < cirdan> Murr: the one with the lowest version. isn't x11.app based on xfreee 4.4? if so, maybe xfree 4.3 is :-)
13:28 < Murr> RR I'm on Panther, and I'm getting this scary warning from a 4.3.99 package
13:28 < Murr> ah, so that's resolved with 4.4?
13:28 < RangerRick> oh, *forwards*-compatible?
13:29 < cirdan> right, because of other support libs and such
13:29 < cirdan> you can go forward murr, you can't go back
13:29 < RangerRick> no, on panther, apple's x11 is based on xfree86 4.3
13:29 < RangerRick> so no, there are no packages less than xfree86 4.4 in fink (I believe)
13:29 < cirdan> RangerRick: yes, not sure about his os when i said it though :-)
13:29 < RangerRick> so there are no fink packages you can build against and still be compatible with panther's x11 except panther's x11
13:29 < Murr> ah
13:30 < Murr> but the packages would be compatible with Tiger X11?
13:30 < RangerRick> yes, tiger x11 is xfree86 4.4
13:30 < cirdan> should be
13:30 < Murr> ic
13:30 < Murr> our server/binary dist machine doesn't have X11 preinstalled
13:30 < cirdan> i just use xorg :-)
13:31 < akh> And never look back. ;-)
13:31 < cirdan> i like it better, and it seems less buggy
13:31 < RangerRick> yeah
13:31 < RangerRick> x.org is good
13:31 < cirdan> plus i can config my virtual 3 button mouse :-)
13:31 < akh> Yup.
13:33 < cirdan> !lart single button trackpads
13:33  * Melian --purges single button trackpads
13:33 < RangerRick> http://ktown.kde.org/~binner/qt4dance_medium.mov
13:33 < cirdan> heh
13:33 < RangerRick> that's just wrong
13:33 < cirdan> RangerRick: you know a good linux x86 hardware diag. cd?
13:33 < runelind> for ppc?
13:34 < RangerRick> cirdan: nope
13:34 < cirdan> memtest, bacblocks, something to max cpu and vid card?
13:34 < cirdan> darn
13:34 < Murr> I don't USE the X11 thereon, I just need it to build packages
13:34 < runelind> shouldn't knoppix ppc work?
13:34 < cirdan> i can't d/.l knoppix on my cell phone :-)
13:35 < RangerRick> Murr: if you really want to becompatible with everything, you pretty much need apple's x11 installed to build against
13:35 < akh> mmmm....lowest common denominator
13:35 < RangerRick> yeah
13:35 < htodd> ok, so now I have to purge qt from my system :)
13:36 < akh> fink purge --recursive qt3-shlibs
13:37 < akh> ;-)
13:44 < akh> Now I'm going to see that every time I start KDE...
13:44 < akh> *shudder*
13:45 < cirdan> haha
13:45  * cirdan didn't look
13:46 < akh> Wise move.
13:46  * akh only saw part and it was too much.
13:47 -!- Albie [~ambs@bl5-163-63.dsl.telepac.pt] has joined #fink
13:56 -!- emp [~emp@67-42-224-94.blng.qwest.net] has quit ["Leaving"]
14:06 -!- Albie [~ambs@bl5-163-63.dsl.telepac.pt] has quit ["This computer has gone to sleep"]
14:07 -!- Albie [~ambs@bl5-163-63.dsl.telepac.pt] has joined #fink
14:08 -!- vasi [~vasi@modemcable214.145-70-69.mc.videotron.ca] has quit []
14:09 < cirdan> !seen msachs
14:09 < Melian> cirdan: i haven't seen 'msachs'
14:10 < newmanbe> Melian: I haven't seen 'mscahs', not i haven't seen 'msachs'
14:10 < Melian> newmanbe: I wish you would RTFM.
14:10 < newmanbe> Melian: No, that's what cirdan needs to do.
14:10 < Melian> newmanbe: wish i knew
14:10 < newmanbe> To enable searching.
14:10 < newmanbe> I think either akh or dmacks told me to yell at you for that.
14:11 < akh> must be dmacks
14:16 -!- f4ng [~Fang@AToulon-151-1-50-248.w86-193.abo.wanadoo.fr] has joined #fink
14:25 -!- Fang [~Fang@2002:53cd:a70b:1:0:0:0:1] has quit [Read error: 110 (Connection timed out)]
14:26 -!- Albie [~ambs@bl5-163-63.dsl.telepac.pt] has quit ["This computer has gone to sleep"]
14:26 -!- Albie [~ambs@bl5-163-63.dsl.telepac.pt] has joined #fink
14:26 < geordie> i'm trying to run fink selfupdate after installing tiger and it keeps demanding i select gcc 4.0.  gcc_select won't allow this even though gcc-4.0 is installed from xcode
14:28 < cirdan> something seems to be wrong with the xcode install then
14:28 < cirdan> did you do a clean install?
14:28 < cirdan> or just upgrade
14:31 < geordie> not an upgrade exactly, but not a clean install either.  i'll try uninstalling and then reinstall
14:31 < Albie> wow, apache is answering
14:32 < Albie> not I just need to bug someone to build a fink package for mod_perl2 :)
14:37 -!- f4ng [~Fang@AToulon-151-1-50-248.w86-193.abo.wanadoo.fr] has quit ["Black holes are where God divided by zero."]
14:58 < geordie> now when i do fink selfupdate it says: "The package dpkg-1.10.21-217 must be compiled with gcc 4.0.0, however, you currently have gcc (unknown version) selected. [...] run the command: sudo gcc_select 4.0"  gcc-4.0 is the only gcc in /usr/bin, and gcc_select is no longer there at all
14:58 < akh> After a clean uninstall?  ick.
15:00 < akh> and 'gcc -v' gives what?
15:00 < akh> (oh, you only have /usr/bin/gcc-4.0?)
15:00 < akh> Never mind
15:03  * akh wonders if the guy on -users who was updating from 10.2->10.4 should restart from scratch.
15:03 < akh> (having told him to do a binary update)
15:06 < akh> geordie: It seems like you need to reinstall DeveloperTools.pkg
15:09 < akh> As that's what provides  both /usr/bin/gcc and /usr/sbin/gcc_select
15:09 < geordie> doing it now
15:16 < geordie> hmmm, sudo gcc_select 4.0 returns Error trying to determine current cc version (got )
15:18 < akh> Check for /usr/bin/cc
15:18 < akh> !lart Apple's lazy installer
15:18  * Melian whacks Apple's lazy installer with a giant beaver's tail
15:24 < geordie>  usr/bin/cc points to fcc-3.3 which is gone
15:25 < geordie> fixed that, now gcc_select works
15:26 < geordie> (apple should take some quality control pointers from debian)
15:28 < geordie> fink selfupdate goes further now, but is complaining "Can't exec 'gcc'" and stopping
15:29 -!- vasi [~vasi@modemcable214.145-70-69.mc.videotron.ca] has joined #fink
15:29 < akh> I guess check the existence and executability of /usr/bin/gcc
15:29 -!- vasi [~vasi@modemcable214.145-70-69.mc.videotron.ca] has quit [Client Quit]
15:32 < geordie> yeah it was pointing to gcc-3.3, thanks
15:35 < akh> ah
15:44 -!- albo [~albo@pcp03531647pcs.sntafe01.nm.comcast.net] has joined #fink
15:44 < albo> what is the equivelant of apt-cache search
15:46 < akh> apt-cache search will work if you install apt-cache.
15:46 -!- Albie [~ambs@bl5-163-63.dsl.telepac.pt] has quit ["This computer has gone to sleep"]
15:47 < albo> web002:~ hperess$ fink install apt-cache
15:47 < albo> /usr/libexec/gcc/darwin/ppc/3.3/cc1plus is not executable!
15:47 < albo> Information about 1744 packages read in 0 seconds.
15:47 < albo> Failed: no matching version found for apt
15:47 < albo> akh: ewww.
15:47 < akh> apt-cacher, sorry.
15:48 < albo> akh: also no
15:48 < albo> same failure
15:48 < akh> It exists, it's just in stable.
15:48 < akh> unstable
15:48 < akh> oops
15:48 < albo> wheres my sources.conf
15:49 < akh> You mean /sw/etc/apt/sources.list?
15:49 -!- xjerky [~xjerky@jerky.advance.net] has joined #fink
15:50 < albo> do i change this to unstable deb file:/sw/fink stable main crypto 
15:50 -!- Albie [~ambs@bl5-163-63.dsl.telepac.pt] has joined #fink
15:52 < akh> Wait, you're trying to access the unstable tree?  No apt-get for you.
15:52 < geordie> fink selfupdate stops while trying to configure libgettext3shlibs, claiming "C compiler cannot create executables"
15:52 < akh> !unstable
15:52 < akh> geordie: You may be missing some headers.
15:52 < albo> akh: can i go to testing by changing that line
15:53 < akh> albo: http://fink.sourceforge.net/faq/usage-fink.php?phpLang=en#unstable
15:53 < akh> There is no 'testing' in fink.
15:53 < akh> Fink != Debian
15:53 < albo> ok, sorry
15:53 < albo> web002:~ hperess$ fink install ghostscript
15:53 < albo> /usr/libexec/gcc/darwin/ppc/3.3/cc1plus is not executable!
15:53 < albo> Information about 1744 packages read in 0 seconds.
15:53 < albo> Failed: Can't resolve dependency "x11" for package "ghostscript-8.00-3" (no matching packages/versions found)
15:54 < akh> a)  Change the permissions on /usr/libexec/gcc/darwin/ppc/3.3/cc1plus to make it executable.
15:54 < akh> b) You must not have Apple's X11 installed (and I'm surprised that Fink hasn't wanted you to install XFree86)
15:55 < akh> respectively
15:55 < albo> is there x11 for tiger ?
15:57 < xjerky> I wonder if OSX will start using X.org
15:57 < akh> albo: yes
15:57 < akh> xjerky: dunno--it's available in any case.
15:58 < albo> akh: do you know where to get it
15:58 < xjerky> yes and no - so far transparency doesnt work as far as I know.
15:59 < akh> albo: On your Tiger DVD.
15:59 < akh> xjerky: Well, I didn't say it was "fully featured", just "available"
15:59 < akh> ;-)
15:59 < xjerky> heh
16:00 < xjerky> oddly I found that fonts looked _much_ better with Xorg, but it was so much slower I decided it wasnt worth it
16:00 -!- Murr [~neeri@A17-202-20-71.apple.com] has quit [Connection timed out]
16:01 < xjerky> does anyone have the default proftpd.conf file? I nuked mine by accident and reinstalling proftpd via fink does not put it back. I copied the basic.conf and modified it, but it's not liking my passowrd. I think it's a PAM issue
16:04 < akh> xjerky: Slower?  You must not have used 'quartz-wm --only proxy'
16:05 < newmanbe> quartz-wm always hung for /me.
16:06 < xjerky> akh: slower as in - window movements had noticable lag
16:06 < xjerky> and scrolling
16:06 < albo> akh: i installed x11 from tiger dvd but i still get Failed: Can't resolve dependency "x11" for package "ghostscript-8.00-3" (no matching packages/versions found)
16:07 < xjerky> and I did use that quartz-wm line
16:07 < akh> albo: What do you get from "fink list -i system-xfree86"
16:07 < albo> akh: nothing 
16:07 < xjerky> but no biggie, I backed out anyway - I didnt like that future program compiles would force me to keep using Xorg anyway
16:07 -!- geordie [~geordie@mail.resist.ca] has left #fink ["rcirc.el 0.8 $Revision: 1.213 $"]
16:08 -!- Murr [~neeri@A17-202-20-71.apple.com] has joined #fink
16:08 < akh> albo: Did you install X11User ?
16:08 < akh> (and if you did, check via 'fink-virtual-pkgs --debug' what might be missing)
16:09 -!- emes [~emes@emes.student.supporter.pdpc] has joined #fink
16:10 < xjerky> damn proftpd is really getting on my nerves
16:10 -!- dk0r [~dk0r@pool-70-18-105-2.alb.east.verizon.net] has joined #fink
16:17 -!- dmacks [~dmacks@203-137.dialup.cloud9.net] has joined #fink
16:17 < dmacks> vasi: Well waddayaknow? I just screwed up a 10.3->10.4 pkg update:(
16:18 < dmacks> (oops, I guess Ididn'tknow he ain't here)
16:18 -!- Hentai [~justin@24-182-218-164.dhcp.sprn.tx.charter.com] has joined #fink
16:18 -!- Hentai [~justin@24-182-218-164.dhcp.sprn.tx.charter.com] has left #fink []
16:19 -!- geordie [~geordie@mail.resist.ca] has joined #fink
16:21 < akh> dmacks: oops
16:22 < akh> Unlink somebody's /var ?
16:22 < cirdan> hehe
16:23 < dmacks> Naw, lost a flag that's required in 10.4 and forbidden in 10.3
16:23 < akh> Ah
16:24 -!- dk0r [~dk0r@pool-70-18-105-2.alb.east.verizon.net] has quit []
16:24 < cirdan> -fno-work? :-)
16:25 < akh> -fmess-up-your-abi ?
16:25 < cirdan> -fyou-up
16:25 < cirdan> :-)
16:25 < dmacks> ha!
16:26 -!- dk0r [~dk0r@pool-70-18-105-2.alb.east.verizon.net] has joined #fink
16:26  * cirdan wonders why someone has a nick which means Japanese Animated Pr0n. (Hentai)
16:27 < cirdan> ok, hitting the gym, bbl
16:27  * dmacks wonders why cirdan is just starting to wonder about that:)
16:27 < cirdan> no, just the first time i said it out loud
16:27 < cirdan> :-)
16:27 < dmacks> Ah.
16:27  * akh wondered but didn't want to reveal my own knowledge of the subject.  ;-)
16:27 -!- RLD_osx [~rldempse@24-178-204-108.dhcp.ftwo.tx.charter.com] has quit [Read error: 104 (Connection reset by peer)]
16:27 < cirdan> akh: hah!
16:27 < dmacks> xjerky: Still unable to get a clean proftpd.conf ?
16:27 < cirdan> we knew, don't worry :-)
16:27 < geordie> cirdan: perhaps it his or her given name
16:28 < cirdan> perhaps...
16:28 < xjerky> yeah no luck yet
16:28 -!- dk0r [~dk0r@pool-70-18-105-2.alb.east.verizon.net] has quit [Client Quit]
16:28 < xjerky> i think i have a PAM issue, but it isnt logging very well
16:28 < cirdan> PAM?
16:28 < cirdan> xjerky: no workie?
16:28 < cirdan> :-)
16:28 < xjerky> its not accepting my password
16:29 < xjerky> but not giving a good reason as to why in the log
16:29 < xjerky> i blew away the base conf when i tried to use an old one of mine
16:29 < xjerky> and for some reason uninstalling and recomiling did not put a new base conf back in
16:30 < dmacks> If you 'fink purge' (not remove) all your proftpd* pkgs then 'fink install' them (as opposed to just 'reinstall') you should get the default .conf back.
16:30 < xjerky> hmm I could try that i guess
16:30 < xjerky> there's probably some sort of PAM default that fink is assuming that Im missing
16:30 < xjerky> the defualt install uses PAM apparently
16:31 < dmacks> ('remove' and 'reinstall' don't touch ConfFiles usually, but 'purge' does remove them and 'install' does install them if they are not present)
16:31 < xjerky> ill try it
16:31  * dmacks knows nothing about proftpd or pam-specific stuff, just pkg-manager games:)
16:33 -!- xaru [xar@magiczny.net] has quit [Remote closed the connection]
16:33 < dmacks> akh: See my flurry of glib2 commits for more information.
16:33 < akh> dmacks: Ah
16:35 < dmacks> Okay, laundry done; /me back to office.
16:35 -!- dmacks [~dmacks@dmacks.active.supporter.pdpc] has quit ["leaving"]
16:36 -!- RLD_osx [~rldempse@24-178-204-108.dhcp.ftwo.tx.charter.com] has joined #fink
16:37 -!- dk0r [~dk0r@pool-70-18-105-2.alb.east.verizon.net] has joined #fink
16:38 < albo> where can i make fink install use -j2 for make
16:45 -!- ringerc [~craig@dsl-202-72-144-62.wa.westnet.com.au] has left #fink ["Yanked sudenly from my seat by a large monster"]
16:45 < akh> You can't without hacking fink itself.
16:45 < albo> akh: so theres no way to take advantage of my dual procs ?
16:45 < akh> Like I said, only if you hack fink.
16:45 < albo> i could write a shell script to make -j2 $@ 
16:47 < akh> Maybe.
16:47 < akh> Fink's probably not clever enough to overwrite that.
16:48 -!- akh [~akhansen@jove.psfc.mit.edu] has quit []
17:01 -!- linuxmaniac [~maniac@151.Red-81-39-193.pooles.rima-tde.net] has joined #fink
17:08 < Murr> I think the issue is that not all makefiles are really parallel save
17:09 < Murr> so people whining about wanting automatic -j are then the people who whine that their stuff won't build anymore
17:16 -!- Albie [~ambs@bl5-163-63.dsl.telepac.pt] has quit ["Leaving"]
17:18 -!- xjerky [~xjerky@jerky.advance.net] has quit ["Leaving"]
17:19 -!- dmacks [~dmacks@netspace.org] has joined #fink
17:26 < dmacks> Murr: Wait, people whine about problems they cause for themselves?
17:29 < Murr> shocking, isn't it?
17:31 < zizban> the nerve!
17:42 -!- You're now known as RangerAway
18:00 -!- akh [~akhansen@jove.psfc.mit.edu] has joined #fink
18:02 < akh> !lart me
18:02  * Melian whips out a sword and chops akh in half
18:02 < zizban> heh
18:02 < dk0r> off topic: anyone know a 3rd part avi joiner for mac>? QT wont work
18:03  * akh was trying to remove residual Tiger seed files from my iPod and I added some unfortunate leading slashes.
18:03 < dk0r> party*
18:03 < zizban> ouch
18:04 < akh> Yeah--luckily the Tiger DVD allowed me to Archive and Install
18:04 < zizban> yeah
18:05 < akh> Otherwise I have a full-drive backup from this weekend, but it's at home.
18:05 < akh> So it wasn't too bad.
18:05 < dk0r> thanks guys :)
18:06 -!- dk0r [~dk0r@pool-70-18-105-2.alb.east.verizon.net] has quit []
18:07 < zizban> cool
18:08 < akh> Guess I'll have to download some podcasts, since I went through the trauma of clearing space on the thing.
18:08 -!- linuxmaniac [~maniac@151.Red-81-39-193.pooles.rima-tde.net] has quit [Remote closed the connection]
18:09 < zizban> heh
18:12 < akh> D'oh!  Have to reinstall xorg.
18:13 < akh> Good thing it wasn't my apt server that I stupidly broke.
18:13 < zizban> oooops
18:13 < zizban> I finally tried out x.org on FreeBSD...it was niiice
18:14  * akh is considering switching OSes on my P4, again.
18:15 < zizban> from what to what?
18:15 < newmanbe> From good to bad.
18:15 < akh> I'll probably have to stick with some flavor of Linux, but maybe from Debian to something with a newer X11.
18:15 -!- jtyler [~jtyler@iphost-64-56-130-194.edm.wiband.net] has quit ["Leaving"]
18:16 < zizban> I used Debian for a while but I just return to solaris
18:16 -!- RLD_osx [~rldempse@24-178-204-108.dhcp.ftwo.tx.charter.com] has quit [Read error: 54 (Connection reset by peer)]
18:17 -!- RLD_osx [~rldempse@24-178-204-108.dhcp.ftwo.tx.charter.com] has joined #fink
18:19 < newmanbe> akh: You are condemning yourself for not compiling xorg yourself on Debian.
18:19 < dmacks> Oh good, now they say Viagra does not cause blindness.
18:19 < akh> newmanbe: Just lazy.
18:19 < zizban> whew
18:20 < akh> So what's causing....nevermind.
18:20 < akh> ;-)
18:21 < dmacks> heh
18:21 -!- baba [~baba@YahooBB220041001026.bbtec.net] has joined #fink
18:22  * akh needs a fink reinstall --recursive
18:22 < newmanbe> cron is so stupid.
18:22 < newmanbe> It is executing the command one second after it was supposed to!
18:22 < zizban> oooops
18:23 < zizban> I just reinstalled fink the other day
18:23 < akh> *ominous music*
18:24 < akh> (or was everything OK?)
18:24 < dmacks> cron has sub-minute granularity?
18:24 < zizban> oh it was fine, just a clean out after some experimental "let's see if this works"
18:25 < newmanbe> dmacks: I have  it set to do it on the minute, but it is executed on the minute + one second.
18:25 < akh> zizban: ah
18:25 < akh> newmanbe: so we're talking an error of 1 part in 60?
18:26 < newmanbe> akh: Except that it does it everytime!
18:26 < akh> Can't you set it to be on the :59?
18:26 < dmacks> Maybe cron kicks its commands at the "end" of a minute, so they don't finish until "sometime during the next one"?
18:27 < htodd> cron isn't guaranteed to run at any particular time
18:27 < htodd> just after that time sometime
18:27 < newmanbe> That's stupid.
18:27 < akh> As you said.  ;-)
18:28 < dmacks> Right. cron claims it'll check all the crontab files each minute; that is all.
18:28  * newmanbe wonders the value of Darwin having a quantum time-splicing of 1000 um.
18:28 < newmanbe> us
18:29 < akh> So that you know how long it takes for Installer.app to "Optimize system performance" ;-)
18:30 < dmacks> I suspect system performance would kinda suck if cron ran itself every ms, no?
18:31 < dmacks> akh: Right. It needs to pull a very precise value out of its ass.
18:31 < akh> And most of the stuff you run with cron is heavy duty overnight stuff, anyway.
18:31 < newmanbe> megahal: Fix cron.
18:31 < megahal> newmanbe: Cron is a colloquy developer and open-source contributor and taking his family died.
18:31 < akh> (e.g. updating the locate database)
18:32  * dmacks wonders why apple doesn't ship anacron.
18:32  * newmanbe will just have to do it another way.
18:32 < akh> dmacks: because we provide it.
18:32 < dmacks> :)
18:32 < akh> Wait, that would mean that they acknowledge our existence...
18:33 < akh> Must be some other reason then.
18:34 < dmacks> If they didn't acknowledge our existence, they wouldn't spend so much effort refusing to ackowledge that the dyld FALLBACK bug is a bug.
18:34 -!- vasi [~vasi@modemcable214.145-70-69.mc.videotron.ca] has joined #fink
18:34 < akh> Ah, yes.  :-)
18:35 < akh> Must, restart, but xorg..not..installed...
18:35  * akh evokes Jim Kirk
18:37 < akh> It takes almost as long to install the .deb as it did to build the thing.
18:37 < dmacks> You could always rebuild KDE to keep things in perspective.
18:39 < vasi> or install Gentoo :-)
18:39 -!- baba [~baba@YahooBB220041001026.bbtec.net] has quit ["This computer has gone to sleep"]
18:39 < akh> Pass.  ;-)
18:40 < akh> I'd have to reinstall xorg for the former anyway, because /usr/X11R6 got hosed in my *cough* incident.
18:40 < akh> (or by the OS install)
18:41 < zizban> use apple's X11 you heretic
18:41 < akh> NEVER!
18:41 < akh> I use X11.app and quartz-wm; isn't that enough?!
18:41 < zizban> heh
18:41 < dmacks> cirdan: Melian's brain is broken.
18:42  * akh would have to rebuild everything.
18:43  * dmacks would start with a window-manager...will help get you in the groove.
18:43 < akh> pass
18:43  * dmacks sings %% rebuilt metacity for rock and rolllll %%
18:44 < akh> lol
18:44 < akh> shutdown -rf now
18:45 -!- akh [~akhansen@jove.psfc.mit.edu] has quit []
18:49 < dmacks> megahal: What's wrong with Melian?
18:49 < megahal> dmacks: Swedish has different symbols with the wrong time to worry about it, melian is a movie as "uncompressed 10-bit.
18:49 < dmacks> megahal: Is her encoding wrong?
18:49 < megahal> dmacks: Candread was just what is wrong with filing patents, what's wrong is the encoding to read my crappy thread.
18:49 < dmacks> True 'nuf.
18:50 < vasi> wtf?   Warning: Too old version of gnome-vfs-2.0     Need 22.0.0, but 2.6.1.1 is installed
18:51 < dmacks> _22_.0.0???
18:51 < vasi> from gnome-python2-py23
18:52 < vasi> i wanted to test out meld :-)
18:52 < vasi> and i get this ridiculous error
18:52 < vasi> er actually, that's just a warning
18:52 < dmacks> gnome-python2 needs to be updated in a major way I think. Not sure where it's getting that value though.
18:52 < vasi> real error is: AttributeError: add_template_option
18:53  * vasi gets out my vengeful google of doom
18:53 < dmacks> Go file a bug at gnome. I dare you!
18:54 -!- akh [~akhansen@jove.psfc.mit.edu] has joined #fink
18:56 < vasi> heh
18:57 < vasi> aw crap, gnome cvsweb is down?
18:57 < akh> Maybe they're getting ready for a new release so that Fink is even further behind the times...
18:58 < vasi> wow, gnome-python is at 2.0.0 in fink
18:58 < vasi> and 2.11.2 in gnome
18:58 < akh> w00t
18:58 < vasi> not that we're behind or anything
18:59 < vasi> is Jeremy Higgs an alive or dead maintainer?
18:59 -!- RLD_osx [~rldempse@24-178-204-108.dhcp.ftwo.tx.charter.com] has quit [Read error: 104 (Connection reset by peer)]
18:59 < dmacks> IIRC, he's alive but kinda overworked ATM. /me thinks he posted to -devel recently about his situation.
18:59 < akh> At least he said something.
19:00 < vasi> well it appears the version 22 thing is his fault :-)
19:00 -!- dk0r [~dk0r@pool-70-18-105-2.alb.east.verizon.net] has joined #fink
19:00 < akh> Ah
19:00 < vasi> otherwise, i guess we need to update gnome-python
19:01 < akh> grrr...have to rebuild applex11tools
19:01 < dmacks> vasi: That's a weird .patch alright.
19:02 < dmacks> At least everything is explained well in the Desc* :/
19:03 -!- RLD_osx [~rldempse@24-178-204-108.dhcp.ftwo.tx.charter.com] has joined #fink
19:04 < vasi> why does Safari insist on turning foo.tar.bz2 into foo.tar.bz2.tar ?
19:04 < akh> file a radar
19:04 < akh> ;-)
19:05 < akh> Hadn't noticed that one...
19:05 < dmacks> Yeah...go to apple.radar.com
19:06 < vasi> er, other way around?
19:06 -!- hennker [flullup@dsl-082-082-234-042.arcor-ip.net] has quit ["leaving"]
19:06 -!- dk0r [~dk0r@pool-70-18-105-2.alb.east.verizon.net] has quit [Read error: 104 (Connection reset by peer)]
19:06 < akh> Yup.
19:07 -!- zizban [~chris@24-52-0-219.sbtnvt.adelphia.net] has quit [Read error: 110 (Connection timed out)]
19:08 < vasi> bah, just used the Safari bug report feature
19:08 < vasi> easier on my brain
19:08 < akh> Probably goes to the same place, anyway. ;-)
19:08 < dmacks> gnome-core?
19:08 < akh> Or one of its numerous aliases
19:14 -!- xhrl [~ThomasW@24.80.39.250] has joined #fink
19:16 < vasi> grrr we need inherited builddepends
19:16 < akh> Sounds like a plan.
19:16 < vasi> yes, it's my plan #34 for fink
19:17 < vasi> i should get to it by fall 2018
19:17 < akh> Hopefully it's better than Plan 9 From Outer Space.
19:17 -!- Murr [~neeri@A17-202-20-71.apple.com] has quit [Read error: 110 (Connection timed out)]
19:17 < akh> By that time Apple will have WIndows on its x86 boxes or be out of business.
19:17 < vasi> actually, the plan consists of bugging TheSin, since he's the only one brave enough to touch the dep engine
19:17 < dmacks> Take it comp.os.plan9, gentlemen.
19:18 < akh> heh
19:18 < dmacks> vasi: drm hsa toyed with it too.
19:18 < dmacks> *has
19:18 < vasi> ooh, more people to bug, yay
19:18 < akh> !seen drm
19:18 < Melian> akh: i haven't seen 'drm'
19:18 < dmacks> Melian's brain is busted.
19:18 < vasi> oh crikey, i have to move new dpkg to stable sometime soon
19:18 < dmacks> Yeah, so we can get a bootstrap that works.
19:18 < akh> yah.  Any drm-sign recently?
19:18 < dmacks> he committed today.
19:19 < akh> Ah
19:19 < vasi> strangely enough
19:19 < akh> Or maybe he committed weeks ago and it took until today for the message to go through.
19:19 < vasi> ok, i'm off before my RSI kills me
19:19  * dmacks occasionally contemplates allowing BDO:true packages to Depend on each other.
19:19 < vasi> (heh)
19:19 < vasi> toodles y'all
19:19 < akh> later
19:19 -!- vasi [~vasi@modemcable214.145-70-69.mc.videotron.ca] has quit []
19:20 < akh> dmacks: that's scary
19:20 < dmacks> Indeed.
19:20 < akh> That'd make for an unhappy validator.
19:21 < dmacks> Not truee.
19:21 < akh> Really?
19:21 < akh> Fun.
19:21 < dmacks> Validator only cares whether a pkg requires a BDO flag or not.
19:21 < akh> ah
19:22 < dmacks> Dep engine only whines if a Depends is being satisfied by a BDO:true pkg.
19:22 < dmacks> So corrupt^Wtweak the latter to only do that if BDO!:true in the pkg whos Depends one is checking.
19:23 < akh> hmmm
19:23 < dmacks> And have phase_remove of a pkg that is BDO:true implicitly mean --recursive.
19:24 < akh> ooooh
19:25 < dmacks> So 'fink build foo' where foo:BDep:gtk+3-dev and gtk+3-dev:Dep:glib3-dev, we install gtk+3-dev which installs glib3-dev which removes glib2-dev which removes gtk+2-dev.
19:25 < dmacks> ...which causes the collective heads of fink-devel to asplode.
19:26 < akh> Indeed!
19:27 < dmacks> (BildDependsInherited is only useful for fink builds. End-user who wants to compile-myself still has to chase down the -dev interactions manually)
19:28 < akh> Yah
19:28 < dmacks> Pretty silly that "fink install gtk+2-dev" doesn't give a functional pkg.
19:28 < dmacks> vasi noted that Debian does allow -dev to be dependents.
19:29 < akh> hmm...I hadn't noticed, but wasn't really looking.
19:29  * akh just installed -dev stuff as needed for builds.
19:36 -!- z|bandito [~z@cpe-66-8-245-189.hawaii.res.rr.com] has joined #fink
19:43 -!- __jt__ [~james@69-162-30-40.stcgpa.adelphia.net] has joined #fink
19:44 -!- dmacks is now known as dmacks_awa
19:44 -!- dmacks_awa is now known as dmacks_away
19:45 < dmacks_away> ident epothilone
19:45 < dmacks_away> ident epothilonea
19:45 < dmacks_away> the hell?
19:46 -!- dmacks_away is now known as dmacks
19:46 -!- dmacks is now known as dmacks_away
19:46 -!- comforteagle [~comfortea@CPE000f6636edec-CM0011ae9117a2.cpe.net.cable.rogers.com] has joined #fink
19:47 < comforteagle> how do I set the MACOSX_DEPLOYMENT_TARGET>
19:47 < comforteagle> ?
19:48 -!- dmacks_away is now known as dmacks_
19:49 -!- dmacks_ is now known as dmacks_away
19:50 < akh> comforteagle: Why? 
19:50 -!- philips [philipsb@shell.onid.oregonstate.edu] has joined #fink
19:50 < comforteagle> akh: I was trying to compile something that said that with it set to 10.1 it wouldn't work
19:51 < comforteagle> got it though
19:51 < akh> OK.
19:51 < akh> (I encountered a runtime problem at one point involving it, so that's why I asked)
19:52 -!- zizban [~zizban@24-52-0-219.sbtnvt.adelphia.net] has joined #fink
20:12 -!- dk0r [~dk0r@pool-70-18-105-2.alb.east.verizon.net] has joined #fink
20:12 -!- akh [~akhansen@jove.psfc.mit.edu] has quit [Read error: 104 (Connection reset by peer)]
20:15 -!- akh [~akhansen@jove.psfc.mit.edu] has joined #fink
20:29 -!- The_Tick [headliner3@the-tick.growl] has joined #fink
20:30 < The_Tick> fink work pretty well on 10.4?
20:31 < akh> Sure.
20:32 < The_Tick> been using dports for a bit, figure i might try fink again
20:33 < akh> I don't know of any major show-stopping issues with the current incarnation.
20:33 < akh> (just the grubby annoyances that keep the developers on their toes.  ;-) )
20:33 < The_Tick> ya, worst case i rm /sw
20:33 < akh> yup
20:37 -!- driftkop [~driftkop@user-0c8hrip.cable.mindspring.com] has joined #fink
20:43 -!- dk0r [~dk0r@pool-70-18-105-2.alb.east.verizon.net] has quit [Read error: 110 (Connection timed out)]
20:43 < akh> Grr...why is Mail.app being so flaky?
20:44 < The_Tick> woah
20:44 < zizban> operator error?
20:44 < The_Tick> the installer for fink is writing ~/.profile with root.group privelages
20:44 < The_Tick> from the looks of it
20:44 < The_Tick> that known?
20:45 < akh> The_Tick: I've mentioned it to people...
20:45 < akh> zizban: Ummm...no
20:46 < The_Tick> akh: alright, i'll bother sin or ranger then
20:46 < akh> Sounds good.
20:46 < The_Tick> hehe
20:46 < The_Tick> setting up new ibook still
20:47  * The_Tick hearts it
20:48 < The_Tick> oh bah
20:48 < The_Tick> i always forget to move to unstable
20:49 < akh> That cuts down on the fun.
20:50 < The_Tick> ya
20:50 < The_Tick> do i need to run fink selfupdate with sudo?
20:50 < akh> nope
20:50 < newmanbe> But you still need to do it as an administrator.
20:51 < The_Tick> ya
20:51 < The_Tick> hey tor boy
20:51 < newmanbe> Tor hater boy.
20:51 < The_Tick> heh
20:52 < akh> Ah, figured out my Mail.app issue.
20:52 < akh> Spotlight...
20:52 < akh> The initial index...
20:59 < zizban> ah
20:59 < zizban> I remember that
20:59 < zizban> made my itunes stutter at the time
21:00 < zizban> I haven't found a use for Spotlight yet, but then again, I just got tiger two weeks ago
21:07 -!- __jt___ [~james@69-162-30-40.stcgpa.adelphia.net] has joined #fink
21:07 -!- __jt__ [~james@69-162-30-40.stcgpa.adelphia.net] has quit [Read error: 104 (Connection reset by peer)]
21:07 -!- akh [~akhansen@jove.psfc.mit.edu] has quit [Read error: 148 (No route to host)]
21:10 -!- msachs [~msachs@17.255.96.116] has joined #fink
21:10 < msachs> 'lo
21:11 < zizban> howdy
21:12 < msachs> Does anyone know why fink might suddenly forget about package descriptions?  This is on Intel, btw.
21:12 < msachs> !lisppaste
21:13 < zizban> your using darwin x86?
21:13 < lisppaste> msachs pasted "fink is forgetful" at http://paste.lisp.org/display/9489
21:13 < msachs> Nope, Developer Transition System.
21:14 < zizban> ah
21:14 < zizban> that's a weird error
21:15 < zizban> stupid question: did you selfupdate?
21:16 < msachs> Yeah.  I'm doing the same procedure as -- this is from my first attempt at an x86 buildfink run, and just to keep things kosher, I wiped my powerpc /sw and recreated it from scratch following my instructions and doing the same thing on the x86 side.
21:16 < zizban> okay
21:16 < zizban> I dunno what to say, I don't know how osx/intel works
21:16 < msachs> If I do . /sw/bin/init.sh ; fink info fink-prebinding, it does find the package.  It's just forgetting about it in my run.
21:17 < zizban> that's weird
21:17 < msachs> Yeah, I'll mail fink-core.
21:17 < zizban> maybe someone else here knows
21:21 < msachs> Ah, I had patched Bootstrap.pm to recognize intel and that change got blown away when I rebuilt Fink.
21:22 < zizban> ah, very clever
21:23 < msachs> So dist got changed to 10.2
21:24 < zizban> oooohhh
21:24 < zizban> I'll make a mental note just in case someone else has this problem and comes on here :)
21:25 < msachs> The fix I had to make is already in HEAD, but bootstrap in HEAD was broken when I was doing my build, so I used the latest release, alas...
21:25 < zizban> oooops
21:28 -!- theid [~theid@12-218-61-181.client.mchsi.com] has joined #fink
21:30 -!- dreamind [~dreamind@C2107.campino.wh.tu-darmstadt.de] has quit []
21:30 -!- You're now known as RangerRick
21:32 < msachs> Okay, an inject later and away we go again.
21:32 < msachs> Hey Ben.
21:34 < zizban> hey RangerRick 
21:39 < RangerRick> hey
21:39 < msachs> How's it going?
21:43 < RangerRick> not bad
21:44 < zizban> how's pinpoint?
21:45 < RangerRick> not pinpoint  :)
21:45 < RangerRick> post-merger it's Motricity  ;)
21:45 < zizban> Motricity...interesting name ;)
21:47 < RangerRick> yeah
21:49 < zizban> so hows life treating you?
21:50 < RangerRick> pretty good, busy as always  :)
21:52 < zizban> cool
21:52 < pogma> hello
21:52 < zizban> het pogma
21:52 < zizban> hey even
21:54 < msachs> 'lo pogma
21:58 < pogma> libkern/OSByteOrder.h changed in xcode-2.1?
21:59 < msachs> Let me see...
22:01 < pogma> Oh, never mind.
22:01 < pogma> xephem has a struct "temp"
22:01 -!- newmanbe [~newmanbe@6d6aca167cb98485.session.tor] has quit ["This computer has gone to sleep"]
22:01 < msachs> Gotcha.
22:01 < pogma> or a #define, whatever, it is coming out wrong
22:02 < pogma> uint16_t np->n_temp = data;
22:02 < pogma> should be uint16_t temp = data :-p
22:03 < msachs> Lovely.
22:04 -!- newmanbe [~newmanbe@ce68e8912e12da02.session.tor] has joined #fink
22:04 < pogma> easy fixed
22:06 -!- msachs [~msachs@17.255.96.116] has quit []
22:07 < pogma> love the way he just quits, no goodbye, just gone :)
22:08  * newmanbe doesn't like it much when he does say goodbye.
22:08 < RangerRick> hehe
22:10 < zizban> heh
22:17 < The_Tick> RangerRick: !
22:17 < The_Tick> omg i'm using fink
22:19 < newmanbe> Congratulations Tor hater boy!
22:19 < RangerRick> er?  :)
22:19  * RangerRick is going to bed  :)
22:19 -!- You're now known as RangerAway
22:21 -!- dmacks_away is now known as dmacks
22:22 < dmacks> Holy crap, someone used FC to send a non-null msg...and it was positive feedback!
22:22 < newmanbe> !party
22:22 < newmanbe> !celebrate
22:22 < newmanbe> megahal: You get the fixings for a party.
22:22 < megahal> newmanbe: "In this guide i will get you a party.
22:24 < dmacks> newmanbe: Melian's brain is broken.
22:24 < newmanbe> !seen dmacks
22:24 < Melian> newmanbe: i haven't seen 'dmacks'
22:25  * newmanbe guesses the MySQL connection is messed up again
22:25 < dmacks> !lart cirdan for having a busted bot
22:25  * Melian beats cirdan severely about the head and shoulders with a rubber chicken for having a busted bot
22:26 -!- zizban [~zizban@24-52-0-219.sbtnvt.adelphia.net] has quit [Remote closed the connection]
22:26 < dmacks> *phew* At least the essentials still work:)
22:35 -!- newmanbe [~newmanbe@ce68e8912e12da02.session.tor] has quit ["Leaving"]
22:36 -!- dk0r [~dk0r@cpe-24-194-167-76.nycap.res.rr.com] has joined #fink
22:39 -!- driftkop [~driftkop@user-0c8hrip.cable.mindspring.com] has quit ["Client exiting"]
22:45 -!- dk0r [~dk0r@cpe-24-194-167-76.nycap.res.rr.com] has quit []
22:52 < dmacks> Is there a way to have certain apps not appear in the cmd-tab cycle?
23:04 -!- bmaret [~smaret@visitor14.iram.es] has joined #fink
23:04 < bmaret> hi folks
23:04 < bmaret> I'd like to downgrade g95 to an older verion
23:04 < bmaret> I have the .deb file in /sw/fink/debs, but cannot install it
23:05 < bmaret> fink install g95-xxx says it can not find matching version
23:05 < bmaret> and dpkg -i /sw/deb/g95-xxx complains that it cannot access archive
23:05 < bmaret> how do i do that ?
23:25 < dmacks> bmaret: /sw/fink/debs usually just contains symlinks. Is yours a pointer to nowhere?
23:33 -!- bmaret [~smaret@visitor14.iram.es] has quit [Read error: 145 (Connection timed out)]
23:36 -!- gopp [party@ool-44c13de2.dyn.optonline.net] has joined #fink
23:36 < gopp> hey has any one here upgraded their itunes
23:36 < gopp> if I do so, will it delete my libary
23:37 < dmacks> gopp: That has not been the case with any previous upgrade.
23:37 < gopp> on the osx version
23:37 < gopp> how about the windows verison
23:38 < dmacks> I don't know...no windows+itunes machines here.
23:39 < dmacks> But again, that's not something that iTunes updates usually do.
23:42 -!- bmaret [~smaret@visitor14.iram.es] has joined #fink
23:43 < bmaret> bye
23:43 -!- bmaret [~smaret@visitor14.iram.es] has quit [Client Quit]
23:46 -!- dk0r [~dk0r@cpe-24-194-167-76.nycap.res.rr.com] has joined #fink
--- Log closed Wed Jun 29 00:00:00 2005