Clone wiki

SCons / BugParty / IrcLog2010-03-09

The SCons wiki has moved to

16:50:54  *      Jason_at_Intel (~[chatzilla@](mailto:chatzilla@ has joined #SCONS 
16:52:29  *      [GregNoel](GregNoel) is no longer marked as being away 
16:53:51  <Jason_at_Intel>       hello 
16:53:59  *      Garyo (~[]( has joined #SCONS 
16:54:12  <Jason_at_Intel>       Hi Gary 
16:54:21  <Garyo>        Hi Jason. 
17:02:17  <Garyo>        Hi Greg -- feel free.  I'm starting to get some SCons time in the next few months (I hope!) 
17:05:34  *      bdbaddog (~[]( has joined #SCONS 
17:06:03  <Garyo>        Hi Bill! 
17:06:19  <bdbaddog>     hey 
17:06:39  <Garyo>        Thanks (again) for pushing out the checkpoint; this one is looking good. 
17:06:45  <[GregNoel](GregNoel)>     We're short Steven, but he commented in the spreadsheet; should we begin? 
17:06:52  <bdbaddog>     sure. 
17:06:57  <Garyo>        I think so too. 
17:07:14  <[GregNoel](GregNoel)>     2517 
17:07:36  <[GregNoel](GregNoel)>     Steven says give it to him, but I don't like it as research. 
17:08:02  <Garyo>        I think it's his choice, is that OK? 
17:08:36  <[GregNoel](GregNoel)>     Yeah, but I don't think he should work on it until post-2.0. 
17:09:06  <Garyo>        Ah, I see.  Spend his cycles getting the python 2.4 stuff in now instead? 
17:09:16  <[GregNoel](GregNoel)>     Yes. 
17:09:43  <Garyo>        That makes a lot of sense.  I'm worried the 1.3 -> 2.0 transition will take a long time. 
17:10:23  <[GregNoel](GregNoel)>     It better not; I'll be flat on my back if it does... 
17:09:42  <[GregNoel](GregNoel)>     What's the priority on 2550?  I didn't look. 
17:10:02  <Garyo>        2550=p3 
17:10:29  <[GregNoel](GregNoel)>     What's the milestone? 
17:10:45  <Garyo>        research 
17:11:03  <[GregNoel](GregNoel)>     Ouch.  OK, make them the same: research p3. 
17:11:27  <Garyo>        OK, or move both to 2.1 p3 if you like. 
17:11:45  <[GregNoel](GregNoel)>     I'll put in a note that this "research" is less priority than 2.0. 
17:11:53  <Garyo>        +1 
17:11:58  <[GregNoel](GregNoel)>     done 
17:12:02  <[GregNoel](GregNoel)>     1549 
17:12:09  <[GregNoel](GregNoel)>     oops, 2549 
17:12:48  <Garyo>        Here's where I say I am really happy Russel is taking the lead in putting tools in a DVCS. 
17:13:24  <[GregNoel](GregNoel)>     I agree.  I'm not sure I agree with his choice of DVCS, but any choice is better than none. 
17:13:34  <bdbaddog>     he's certainly bringing the email volume up.. 
17:14:09  <Garyo>        So... can we make a new category of issues for external tools, and this can be one? 
17:14:27  <Garyo>        (I know it's half here & half there, so it's confusing.) 
17:14:28  <[GregNoel](GregNoel)>     Hmmm...  Possible.  Needs discussion. 
17:14:47  <[GregNoel](GregNoel)>     Not something to settle today, surely. 
17:14:59  <Jason_at_Intel>       +1 
17:15:01  <Garyo>        Agreed.  Just let Russel work on it for now. 
17:15:31  <[GregNoel](GregNoel)>     so 2549, 3.x, what priority? 
17:15:42  <Garyo>        So 3.x p4? 
17:15:53  <[GregNoel](GregNoel)>     Hmmm... 
17:16:15  <[GregNoel](GregNoel)>     I think I'd like it to resurface sooner than that. 
17:16:44  <Garyo>        I'm hoping we'll decide some day to take the D tool out of SCons entirely instead. 
17:16:53  <[GregNoel](GregNoel)>     Yeah, along with Java. 
17:17:02  <Garyo>        ... and latex, and ... 
17:17:03  <Jason_at_Intel>       why? 
17:17:16  <[GregNoel](GregNoel)>     Make them all user-supported. 
17:17:16  <Garyo>        Because they can be developed and released asynchronously. 
17:17:17  <Jason_at_Intel>       oh make them add on 
17:17:47  <Jason_at_Intel>       in that case most of the tools can go that route 
17:18:19  <Garyo>        Jason: agreed.  But we have to balance that with the python "batteries included" philosophy. 
17:17:55  <Garyo>        (We could do a linux distro thing and include the latest blessed version... or not even that.  All up for discussion.) 
17:18:08  <[GregNoel](GregNoel)>     Yeah, 2549 3.x p4; reassign it when we have a separate user-supported flow. 
17:18:27  <Garyo>        Greg: +1 
17:18:32  <[GregNoel](GregNoel)>     done 
17:18:39  <[GregNoel](GregNoel)>     2566 
17:18:42  <Garyo>        2566 is already closed. 
17:18:52  <Garyo>        can't repro. 
17:19:03  <[GregNoel](GregNoel)>     WORKSFORME? 
17:19:34  <Garyo>        I said INVALID because he couldn't repro it either :-) 
17:19:58  <[GregNoel](GregNoel)>     worksforme, then. {;-} 
17:19:27  <[GregNoel](GregNoel)>     In any event, 2571 
17:20:13  <Jason_at_Intel>       2571? is this calling Scons under the covers still? 
17:20:29  <Garyo>        Jason: sure. 
17:20:15  <Garyo>        2571: tell OP good job, give some direction on compat, then integrate for 2.1? 
17:20:28  <[GregNoel](GregNoel)>     I'll go along. 
17:20:38  <[GregNoel](GregNoel)>     Who?  Gary? 
17:20:47  <Garyo>        I'll take it. 
17:21:17  <[GregNoel](GregNoel)>     Obviously needs  some test cases, but I like the scheduling. 
17:21:04  <Garyo>        (Not that I care about MSVS, but I do care about new contributors.) 
17:21:27  <Jason_at_Intel>       it start small then grows 
17:21:41  <[GregNoel](GregNoel)>     2.1 p3 Garyo, done 
17:22:09  <[GregNoel](GregNoel)>     2572, defer? 
17:22:29  <Garyo>        sure 
17:22:33  <Jason_at_Intel>       +1 
17:22:37  <bdbaddog>     +1 
17:22:47  <[GregNoel](GregNoel)>     done 
17:22:56  <[GregNoel](GregNoel)>     2573 
17:22:59  <Garyo>        2573: what is ".sx"? 
17:23:10  <Jason_at_Intel>       :-) was just going to ask that 
17:23:15  <bdbaddog>     some .net file? 
17:23:22  <[GregNoel](GregNoel)>     Man page says "preprocessed assembler" 
17:23:33  <[GregNoel](GregNoel)>     (It's in the spreadsheet comments.) 
17:23:36  <Garyo>        for what OS? 
17:23:44  <[GregNoel](GregNoel)>     Any? 
17:23:56  <Garyo>        what man page did you find it in? 
17:24:24  <[GregNoel](GregNoel)>     SCons man page. 
17:24:48  <[GregNoel](GregNoel)>     We currently preprocess those files, but apparently don't scan them for dependencies. 
17:24:56  <Garyo>        Oh?!  Wow, that's a surprise! 
17:25:05  <[GregNoel](GregNoel)>     It was to me, too. 
17:25:09  <Garyo>        OK, I guess you guys are right, add it to the list. 
17:25:37  <Garyo>        I'll do that too.  The work part is trivial. 
17:25:49  <Garyo>        2.1 p4 garyo +easy 
17:25:51  <[GregNoel](GregNoel)>     OK, done, but watch for side-effects: it may try to compile the file. 
17:26:07  <Garyo>        ok, put a note in if you don't mind... 
17:26:17  <[GregNoel](GregNoel)>     Wilco 
17:26:33  <[GregNoel](GregNoel)>     2574 
17:27:02  <[GregNoel](GregNoel)>     Another trivial change, but would work better post-2.0. 
17:27:16  <Garyo>        Agreed.  Post 2.0. 
17:27:33  <Garyo>        2.1 p2, who? 
17:28:08  <[GregNoel](GregNoel)>     Not seeing any volunteers... 
17:28:19  <[GregNoel](GregNoel)>     I can't take it; I'll be recovering. 
17:28:36  <Garyo>        Understood.  Assign it to me then, I'll delegate if needed. 
17:28:41  <[GregNoel](GregNoel)>     done 
17:28:48  <[GregNoel](GregNoel)>     2575 
17:28:59  <Jason_at_Intel>       2575 ... it would be better if we had a src_dir which could be used as a root, to allow -j based builds to work 
17:29:22  <Garyo>        That's an excellent idea. 
17:29:39  <Garyo>        Jason, can you propose that to the OP and ask for a new patch? 
17:29:50  <Jason_at_Intel>       (zipfile in Parts :-) .. not as good as raw zip however in some cases) 
17:30:09  <Jason_at_Intel>       sure.. main problem is the call more than once issue 
17:30:29  <Jason_at_Intel>       the builders think the output is more than one environment 
17:30:16  <[GregNoel](GregNoel)>     Um, it would have to work for all builders, not just this one. 
17:30:32  <Garyo>        Would it, Greg?  Couldn't it just be an env override? 
17:31:07  <[GregNoel](GregNoel)>     No, I don't think so.  Think of LaTeX, for example, which wants to run in the build directory. 
17:31:10  <Garyo>        And Jason, if it's an env var, shouldn't it be constant for all calls anyway?  (I think I see your point though, still causes a warning) 
17:31:24  <Jason_at_Intel>       that is why i made a zipfile() and not override zip() as this changes behavior of calling more than once 
17:31:46  <Garyo>        Greg: I don't think tar/zip need to *run* in any particular dir, they just need a reference point. 
17:32:39  <Garyo>        OK, maybe this is more complicated than it seems at first. 
17:32:40  <Jason_at_Intel>       however for 2575 his patch will work.. it will just break -j builds 
17:33:00  <Garyo>        Jason: that worries me. 
17:33:07  <[GregNoel](GregNoel)>     Actually, tar/zip can have multiple changes of directory in them; that's why I like the solution in 1890. 
17:33:31  *      Garyo looks at 1890 
17:34:15  <Jason_at_Intel>       ie use the tarfile module? 
17:34:23  <Garyo>        I see, use tarfile instead of calling tar.  I totally agree. 
17:34:34  <[GregNoel](GregNoel)>     Garyo, basically, each entry is a duple of (name-in-archive, File-node). 
17:34:48  <Jason_at_Intel>       I have an impl in Parts for this 
17:34:59  <Jason_at_Intel>       but again i don't have it support more than one call 
17:35:15  <Garyo>        It's a call-once-with-all-sources builder? 
17:35:28  <Jason_at_Intel>       yep 
17:35:44  <Jason_at_Intel>       again the src_dir overide upsets teh builders 
17:35:54  <Jason_at_Intel>       spits out warnings or errors 
17:35:58  <Garyo>        Not ideal, of course, but probably best we can do given builder limitations 
17:36:08  <[GregNoel](GregNoel)>     I have a functional prototype for 1890, but I've been waiting for post-2.0 to implement it. 
17:36:29  <Garyo>        And calling with a single src dir is probably 90% of all use cases anyway. 
17:37:11  <Jason_at_Intel>       can you look at [*checkout*/parts/trunk/parts/parts/pieces/](*checkout*/parts/trunk/parts/parts/pieces/ 
17:37:13  <[GregNoel](GregNoel)>     Then why not base it off of chdir=?  It's the effect that counts, not the actual functioning. 
17:37:51  <Garyo>        because of breaking -j, right? 
17:38:10  <Jason_at_Intel>       I think the chdir in SCons means current dir change 
17:38:26  <Jason_at_Intel>       Scons needs a new idea to support the "root" area to use 
17:38:38  <Garyo>        OK, so for 2575: 2.1, p2, Jason and Greg to investigate Jason and Greg's work, and come up with a nice solution. 
17:38:40  <Jason_at_Intel>       src_dir is what i would propose 
17:39:04  <[GregNoel](GregNoel)>     I don't agree. 
17:39:26  <Garyo>        don't agree w/ src_dir, or don't agree w/ my assignment? 
17:39:27  <Jason_at_Intel>       to me .. not gary .. correct? 
17:39:58  <[GregNoel](GregNoel)>     don't agree with src_dir; again, the effect is the requirement, not the actuality. 
17:40:15  <Jason_at_Intel>       ?? 
17:40:38  <Garyo>        I think you're saying it should get chdir before SCons actually changes the dir, and just use that dir itself. 
17:40:52  <[GregNoel](GregNoel)>     Yes 
17:41:01  <Garyo>        Might require a little core patching but not impossible of course. 
17:41:15  <Jason_at_Intel>       that is fine.. then does this mean we will fix command to do the same 
17:41:21  <Garyo>        (like a "builder_wants_chdir" flag or something) 
17:41:35  <Jason_at_Intel>       will it out add a cd <dir> && to the command? 
17:42:15  <Garyo>        Jason: at least the infrastructure would be there to handle it that way if we wanted to. 
17:42:22  <[GregNoel](GregNoel)>     I'm not going to design on the fly; my suggestion was to reject this issue as invalid, since it's the same problem with all builders where you use chdir=. 
17:43:07  <[GregNoel](GregNoel)>     If we change that paradigm, we need to make it consistent. 
17:42:57  <Jason_at_Intel>       so back to the issue 
17:43:02  <Jason_at_Intel>       this is a patch 
17:43:11  <Jason_at_Intel>       that is invalid? 
17:43:13  <Garyo>        Let's not say it's invalid then, but we think there's a better method. 
17:43:24  <[GregNoel](GregNoel)>     Garyo, yes. 
17:43:51  <Jason_at_Intel>       i see... not sure what the better method you have in mind is 
17:44:08  <Garyo>        Leave the issue open for this particular builder, but note that it requires a little infrastructure work to expose chdir to the builder, then we can do it better. 
17:44:29  <Jason_at_Intel>       agree 
17:44:48  <Garyo>        Jason: a builder flag that would tell scons not to chdir, but pass the chdir arg as a kwd arg to the builder.  Or something like that. 
17:45:11  <[GregNoel](GregNoel)>     And you could have chdir= on each builder call. 
17:45:13  <Jason_at_Intel>       I guess... but you woudl always want it on.. never off 
17:45:20  <Garyo>        (Greg, is that basically your idea?) 
17:45:42  <[GregNoel](GregNoel)>     Still designing on the fly, but yes, I think so. 
17:45:44  <Garyo>        Jason: we can't turn it on for all builders because most of them don't understand it. 
17:45:59  <loonycyborg>  chdir is clearly hack in this case. 
17:46:26  <[GregNoel](GregNoel)>     Hi, Sergey; glad you could join us.  Do you think users would understand a distinction there? 
17:46:29  <loonycyborg>  There should be more flexible ways to specify paths that'll be stored in the archive, 
17:46:32  <Garyo>        loonycyborg: yes, we'd be "repurposing it" a bit. 
17:46:51  <Jason_at_Intel>       Sure.. I will wait to see what greg proposes.. however from a generic pragma.. chdir is designed in SCons to mean something, changing its logic seem bad, better to add a new "verb" to say what we want clearly 
17:47:34  <Garyo>        OK, so given that let's not design it here but just say in the ticket that it needs thought and some internal changes before we can do it right. 
17:47:45  <Jason_at_Intel>       agree 
17:48:02  <[GregNoel](GregNoel)>     OK, then what should we do with the ticket? 
17:48:37  <[GregNoel](GregNoel)>     I'll suggest deferring to the mailing list. 
17:48:43  <Garyo>        How about this: mark it 2.1 p2, but with a note to say revisit at that time and discuss. 
17:48:58  <Jason_at_Intel>       +1 
17:49:00  <[GregNoel](GregNoel)>     Yes 
17:49:08  <bdbaddog>     +1 
17:49:08  <Garyo>        (rather than have a complete implementation by that time) 
17:49:16  <[GregNoel](GregNoel)>     done 
17:49:18  <Garyo>        good, consensus! 
17:53:13  <loonycyborg>  Zip builder should store paths relative to shortest common path of sources by default IMO.. 
17:53:35  <[GregNoel](GregNoel)>     And that's what I'd like to do with 1890. 
17:54:24  <[GregNoel](GregNoel)>     Always put in a duple with relative path and File node. 
17:53:49  <Garyo>        loonycyborg: put a note in those 2 tickets if you want. 
17:54:54  <Garyo>        I like explicit rather than implicit in general though, even if it's a little more typing. 
17:55:19  <[GregNoel](GregNoel)>     Garyo, yes. 
17:55:02  <Jason_at_Intel>       lonnycyborg.. I agree.. that is what I have in Parts as well 
17:55:04  <[GregNoel](GregNoel)>     Remember, relative path is expensive to calculate; should try to avoid it when possible. 
17:55:06  <Garyo>        ...but we're trying to design it here. 
17:55:15  <Garyo>        let's not. 
17:49:37  <[GregNoel](GregNoel)>     2576 
17:50:00  <Garyo>        2576 looks like good potential for Russel to feed Steven things. 
17:50:28  <[GregNoel](GregNoel)>     Yes. 
17:51:13  <[GregNoel](GregNoel)>     I wonder if "anytime" would work for this, as they work out the interaction details. 
17:51:19  <Garyo>        2.x p3, Steven to own, and work w/ Russel? 
17:51:57  <Garyo>        (Or vice versa, Russel to own, delegate work to Steven?) 
17:52:08  <[GregNoel](GregNoel)>     I could buy 2.x p3, but I'd like to see a procedure worked out first. 
17:52:37  <[GregNoel](GregNoel)>     Russel to own during design, Steven to own during implementation? 
17:52:57  <Garyo>        OK then, let's ask Steven to work something like that out & revisit next meeting. OK? 
17:53:12  <[GregNoel](GregNoel)>     yes, I like that. 
17:53:18  <bdbaddog>     +1 
17:53:25  <Jason_at_Intel>       +1 
17:55:40  <[GregNoel](GregNoel)>     We seem to have covered the issues; I have one thing on schedule. 
17:56:21  <[GregNoel](GregNoel)>     I can't make the next meeting; should we think about one week or three weeks for the next party? 
17:55:21  <Jason_at_Intel>       so 1.3 
17:55:37  <Garyo>        Yes, 1.3.  I'm in favor of moving aggressively to release. 
17:56:13  <Garyo>        I have 2 issues to test and one which won't get into 1.3. 
17:56:45  *      loonycyborg really hopes that 2443 will be fixed in 1.3 
17:57:30  <Garyo>        :-( that's my one I thought wouldn't make it.  I'll make an effort for it. 
17:57:32  <[GregNoel](GregNoel)>     loonycyborg, if the current checkpoint is the final candidate, that won't happen.  Sorry. 
17:57:34  <bdbaddog>     seems unlikely. we're on the runway to 1.3 launch.. 
17:58:01  <Garyo>        They're right, things I've looked at would destabilize. 
17:59:00  <Jason_at_Intel>       hmm  2443 works for me. 
17:58:23  <Garyo>        Let's get 1.3 and 2.0 out asap. 
17:58:39  <Garyo>        Then we can get back on a shorter & less constricted release cycle. 
17:58:57  <bdbaddog>     yaha 
17:59:11  <bdbaddog>     so 1.3 this weekend then? 
17:59:14  <[GregNoel](GregNoel)>     Can you get back to all the people who've had problems with vs_revamp and get them to try the checkpoint? 
17:59:33  <[GregNoel](GregNoel)>     If so, this weekend sounds fine to me. 
17:59:35  <Garyo>        Greg: yes, those are the 2 issues on my test list. 
17:59:57  <Garyo>        Bill: I'll try to review the release docs soon.  I'm happy to help wordsmith. 
18:00:56  <Garyo>        Is the release process pretty much as documented on the wiki now? 
18:02:09  <Garyo>        I'll be skiing this wkend, but around this week and next. 
18:02:12  <bdbaddog>     yes. though I might move a few steps around to streamline 
18:02:36  <Garyo>        OK, let me help; you've done a lot. 
18:03:00  <Garyo>        Do you think this wkend is possible? 
18:03:36  <bdbaddog>     to get feedback on the couple of issues msvs/vc/sdk which have been reported? 
18:04:13  <Garyo>        I think that should be possible. 
18:04:21  <[GregNoel](GregNoel)>     If you can get it done this weekend, I can start on 2.0 on Tuesday after I get back from Cabo. 
18:05:14  <Garyo>        Bill: I have the "missing VCs on empty SConstruct" one and "wrong bat file for VS2005" and I think both are now fixed. 
18:05:31  <bdbaddog>     there's two more. 
18:05:55  <bdbaddog>     this one: []( 
18:06:23  <Garyo>        Oh right, missing gdi32.lib. 
18:06:50  <bdbaddog>     and one with vc2010rc + a bunch of other isntalled vc's and it not picking  up the requested one. 
18:08:00  <bdbaddog>     I had a win7 license from when they gave out the free trials, but it's expired. 
18:07:51  <Garyo>        I think we have to draw the line somewhere or we'll never get it out. 
18:08:08  <bdbaddog>     yeah. I think so too. 
18:08:11  <bdbaddog>     back in a minute.. 
18:08:12  <Garyo>        I have a win7 machine now. 
18:08:57  <Garyo>        The missing gdi32.lib might be simple, or we might be able to give him a simple workaround (he hardcoded a bunch of stuff in his old version, as most people did.) 
18:09:22  <Jason_at_Intel>       what is win7 needed for? 
18:09:54  <Garyo>        I think bdbaddog's 2nd issue, from the ML. 
18:09:58  <bdbaddog>     I just needed a 64 bit some flavor of windows to build up a vm to try and reproduce some of the reported issues. 
18:10:24  <Jason_at_Intel>       ahh 
18:10:49  <Jason_at_Intel>       was masm tool fixed to use ml64? 
18:11:04  <Garyo>        I don't remember. 
18:11:10  <bdbaddog>     donno. 
18:11:13  <Garyo>        Try it :-) 
18:11:22  <bdbaddog>     or check the bug to see if it's marked fixed. 
18:11:40  <Jason_at_Intel>       I think it still uses ml 
18:13:15  <Jason_at_Intel>       yep.. still broken 
18:11:51  <Garyo>        So I say let's look at the missing gdi32 one, but with the vc2010 one let's say we are too close to 1.3 to change things now. 
18:12:27  <bdbaddog>     the gdi32 I think it's setting up right the first time,and the second time it's not. maybe default env and his initial Environmnet() 
18:12:49  <Garyo>        That's usually what that means. 
18:14:04  <bdbaddog>     I'm guessing somehow the sdk/vc logic combo is not quite right, but only in some corner cases. 
18:13:51  <Garyo>        I really want to get the site_scons dirs in too, so the sooner we can get moving on 2.0 the better. 
18:13:26  <Garyo>        Sorry.  2.1. 
18:14:14  <bdbaddog>     I hear u. I want 1.3 done. 
18:14:19  <bdbaddog>     I'm tired of py 1.5.2 
18:14:19  <Jason_at_Intel>       on that i have mirrored this in Parts (with part-site) 
18:15:32  <Garyo>        So let's forge ahead, hoping to get 1.3 out early next week? (Sounds like not all the test results will be in til then.) 
18:15:34  <Jason_at_Intel>       so go with what we have with vs_revamp and patch in 2.0? 
18:15:57  <Garyo>        Jason: yes, or 2.1 actually.  2.0 = 1.3 with python floor update. 
18:15:58  <bdbaddog>     what's in vs_revamp? it's all on trunk 
18:16:11  <Garyo>        yes, trunk. 
18:16:25  <Jason_at_Intel>       sorry mean the "feature" not branch 
18:16:51  <Jason_at_Intel>       so this mean 2.0 will be soon after 1.3? 
18:17:06  <[GregNoel](GregNoel)>     I'll have three weeks, 
18:17:42  <[GregNoel](GregNoel)>     which won't be enough, but I'm hoping I'll be far enough that someone else can finish getting out the checkpoints and release itself. 
18:17:06  <Garyo>        hopefully! 
18:17:07  <bdbaddog>     yes. that's the plan. 
18:17:19  <Jason_at_Intel>       great! 
18:17:22  <bdbaddog>     no features in 2.0, just remove 1.5.2->2.3 code. 
18:17:24  <bdbaddog>     right? 
18:17:32  <Jason_at_Intel>       2.4? 
18:17:34  <Garyo>        agreed. 
18:17:49  <Jason_at_Intel>       thought 2.3 was broken on some platforms 
18:18:00  <bdbaddog>     we're dropping 2.3 
18:18:04  <bdbaddog>     and below. 
18:18:09  <Garyo>        2.4 is the new floor. 
18:18:13  <bdbaddog>     yes. 
18:18:17  <Jason_at_Intel>       :-) 
18:19:04  <Garyo>        ok, let's do it! 
18:19:13  <bdbaddog>     k. 
18:19:24  <[GregNoel](GregNoel)>     OK, is that it for 1.3?  When should the next party be?  One week, two weeks, or three weeks?  I can't be there if it's two weeks. 
18:19:48  <bdbaddog>     should we make the call next tues on 1.3? 
18:20:00  <Garyo>        +1 
18:20:00  <Jason_at_Intel>       +1 
18:20:07  <bdbaddog>     or we can handle on release mailing list if things are resolved sooner. 
18:20:23  <Garyo>        fine. 
18:21:01  <[GregNoel](GregNoel)>     One week, then? 
18:21:16  <Garyo>        good with me. 
18:21:34  <bdbaddog>     k. virtually c u all then. 
18:21:44  <Jason_at_Intel>       same! 
18:21:49  <[GregNoel](GregNoel)>     OK, see you all in one week. 
18:21:54  <Garyo>        bye 4 now. 
18:22:00  <Jason_at_Intel>       bye 
18:22:04  <[GregNoel](GregNoel)>     Got to go, dinner is calling. 
18:22:12  <bdbaddog>     l8r 
18:22:22  <[GregNoel](GregNoel)>     G'day all. 
18:22:29  *      [GregNoel](GregNoel) has been marked as being away 
18:23:38  *      bdbaddog (~[]( has left #SCONS 
18:32:20  *      Jason_at_Intel has quit (Quit: [ChatZilla](ChatZilla) 0.9.86 [Firefox 3.5.3/20090824101458]) 
18:38:08  *      loonycyborg has quit (Quit: Zzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz) 
18:45:54  *      Garyo has quit (Quit: [ChatZilla](ChatZilla) 0.9.86 [Firefox 3.5.8/20100202165920])