Please note:The SCons wiki is now restored from the attack in March 2013. All old passwords have been invalidated. Please reset your password if you have an account. If you note missing pages, please report them to webmaster@scons.org. Also, new account creation is currently disabled due to an ongoing spam flood (2013/08/27).
   1 16:50:31 *	Garyo (~chatzilla@209-6-36-50.c3-0.smr-ubr1.sbo-smr.ma.cable.rcn.com) has joined #SCONS
   2 16:55:03 *	jason_at_intel (~chatzilla@185.sub-75-205-7.myvzw.com) has joined #SCONS
   3 16:55:21 *	bdbaddog (~bdeegan@adsl-71-131-10-196.dsl.sntc01.pacbell.net) has joined #SCONS
   4 17:03:18 *	sgk (~sgk@nat/google/x-vdmoydnhvesvboyw) has joined #SCONS
   5 17:05:37 <GregNoel>	Are we ready to go?
   6 17:05:44 <Garyo>	i am
   7 17:05:47 <jason_at_intel>	Hi Steve, think we found the cause of the temp file issue
   8 17:05:53 <sgk>	ready when everyone else is
   9 17:05:54 <jason_at_intel>	I am ready
  10 17:05:57 <GregNoel>	1938 Gary took it
  11 17:05:57 <GregNoel>	1891
  12 17:06:06 <sgk>	i saw your mail, that sounds exactly like what's going on
  13 17:06:42 <Garyo>	1891?
  14 17:07:01 <GregNoel>	That's what's on the spreadsheet.
  15 17:06:56 <sgk>	sorry, that reply was to jason
  16 17:07:00 <jason_at_intel>	I think it just needs a fix to mslink
  17 17:07:08 <sgk>	jason, let's stick to the issue list and we can discuss the tempfile thing in turn
  18 17:07:21 <sgk>	or at the end if we haven't gotten to it
  19 17:07:17 <jason_at_intel>	yep
  20 17:07:27 <jason_at_intel>	so 1891
  21 17:07:34 <jason_at_intel>	I think we need to fix mslink.py
  22 17:07:41 <jason_at_intel>	and this will work
  23 17:08:12 <sgk>	that makes sense
  24 17:08:07 <Garyo>	Agree it can't be that hard.  Who has time?  Jason, would you like to take a crack at it?
  25 17:08:19 <jason_at_intel>	I would be happy to
  26 17:08:27 <Garyo>	2.1 p3 jason?
  27 17:08:33 <jason_at_intel>	I will try it out in the Parts mslink version
  28 17:08:53 <jason_at_intel>	that should be easy to map back to the SCons version
  29 17:09:10 <jason_at_intel>	since it just a new set of actions
  30 17:08:59 <sgk>	cool, thanks
  31 17:09:03 <sgk>	2.1 p3 jason sounds good to me
  32 17:09:06 <GregNoel>	done
  33 17:09:08 <GregNoel>	2153
  34 17:09:31 <sgk>	2153:  this is the email jason was referring to
  35 17:09:36 <jason_at_intel>	so I sent a mail on this to steve.. summarized here
  36 17:09:54 <sgk>	because long-line tempfiles get created as as a side effect of expanding ${TEMPFILE} in the command line
  37 17:10:12 <sgk>	the file gets created when we expand the line for display, too
  38 17:10:32 <sgk>	and since that display expansion doesn't actually get executed, the tempfile deletion never happens
  39 17:10:51 <Garyo>	hmm, makes sense.
  40 17:10:18 <jason_at_intel>	not sure on what is the best fix... thinking about MD5 the string to store the tempfile name in the env
  41 17:11:08 <sgk>	Jason, do you or your intern have cycles to work w/me on fixing this?
  42 17:11:16 <jason_at_intel>	Yep
  43 17:11:20 <sgk>	it might be a little involved, because it's not happening at the right time
  44 17:11:40 <sgk>	but i can provide direction, and if you two have time for the coding+testing, it'll go quicker than if it's on my plate
  45 17:11:43 <sgk>	okay, cool
  46 17:11:56 <jason_at_intel>	need to know if the env we pass to the action is unique or not
  47 17:12:02 <sgk>	2.1 p2 jason then
  48 17:12:10 <Garyo>	+1
  49 17:12:08 <GregNoel>	done
  50 17:12:14 <GregNoel>	2575 I can post the long comment, but I have commitments that will prevent me from taking much part in the discussion.
  51 17:12:44 <jason_at_intel>	honestly we have this fixed in Parts without a chdir
  52 17:13:02 <sgk>	for zip?  or a more general fix?
  53 17:13:07 <jason_at_intel>	it was so critical, we just made our own zipfile builder
  54 17:13:10 <Garyo>	I don't think it's too involved, but that's cause I'm pretty sure just passing a prefix or prefix to eliminate to the zipfile stuff is the way to go
  55 17:13:20 <jason_at_intel>	zipfile, tarfile bz2file
  56 17:13:31 <jason_at_intel>	it all the same basic code
  57 17:14:00 <jason_at_intel>	we can review it when i visit
  58 17:14:28 <sgk>	let's do that
  59 17:14:34 <Garyo>	I thought at least zipfile can already run w/o chdir
  60 17:14:32 <jason_at_intel>	I don't know if greg is in the CA area or not
  61 17:14:41 <jason_at_intel>	I take it he would want to have a say
  62 17:14:40 <sgk>	greg's in San Diego
  63 17:14:56 <jason_at_intel>	that pretty far south.. correct?
  64 17:15:08 <sgk>	yes, prohibitively so
  65 17:15:27 <jason_at_intel>	:-(.. want to meet the master himself :-)
  66 17:15:31 <sgk>	but we could at least start looking at it
  67 17:15:36 <jason_at_intel>	yep
  68 17:15:41 <Garyo>	How about Greg posting the long comment anyway so we can discuss the interface in the Zip builder, then use your code to implement?
  69 17:15:51 <sgk>	++
  70 17:15:59 <GregNoel>	Garyo, good idea
  71 17:16:08 <jason_at_intel>	sounds good
  72 17:16:23 <sgk>	leave it owned as issues@scons and revisit it after discussion?
  73 17:16:30 <Garyo>	I'm ok w/ that
  74 17:16:32 <GregNoel>	What to do with the issue in the meantime?
  75 17:16:46 <Garyo>	nothing?
  76 17:17:02 <GregNoel>	... with a meaning of review next time?
  77 17:16:59 <jason_at_intel>	is it research?
  78 17:17:22 <sgk>	yeah, either research or leave it as is, so we revisit it next time
  79 17:17:23 <Garyo>	I'm ok w/ research jason too -- that way we'll review it.
  80 17:17:47 <GregNoel>	research p1 then?
  81 17:18:02 <sgk>	done
  82 17:18:02 <GregNoel>	Who should own it?
  83 17:18:18 <sgk>	GregNoel until you post the comment, then re-assign to Jason?
  84 17:18:19 <Garyo>	Jason imho.  Jason, when's your meeting with sk?
  85 17:18:38 <jason_at_intel>	aug 18-19
  86 17:19:10 <jason_at_intel>	I get there aug 17.. . I forget what time.
  87 17:19:16 <jason_at_intel>	leave early on saturday
  88 17:19:27 <Garyo>	Anyway we have plenty of time to discuss on the ML
  89 17:18:53 <Garyo>	ok
  90 17:18:57 <sgk>	ok
  91 17:19:01 <GregNoel>	done
  92 17:19:04 <GregNoel>	1450
  93 17:19:22 <jason_at_intel>	ya so this bug
  94 17:19:54 <Garyo>	1450: Jason, do you have anything that would actually break?
  95 17:19:56 <jason_at_intel>	My concern is that the fix seems tied to a given version of mslink
  96 17:20:13 <jason_at_intel>	what about other tools?
  97 17:20:23 <Garyo>	Yeah, it's a fair point -- newlines in a command line makes me nervous too, even if it works now
  98 17:20:38 <jason_at_intel>	I might be missing something.
  99 17:20:46 <jason_at_intel>	but i think more testing is needed
 100 17:21:02 <Garyo>	Could have two versions TEMPFILE and TEMPFILESPACES or something (yuck)
 101 17:21:06 <jason_at_intel>	I am under the view that minus link
 102 17:21:11 <jason_at_intel>	most tools would take a file in a different way
 103 17:21:09 <sgk>	good lord, a command line that actually blows out the temp file limit?  131K characters?
 104 17:21:34 <Garyo>	sgk: I think it blows out the line length limit, hence the newlines.
 105 17:21:54 <Garyo>	and yes, that's a big cmd line! :-/
 106 17:22:02 <jason_at_intel>	per line
 107 17:22:03 <sgk>	the CMD line length limit is already exceeded, that's why it's getting put in the temp file
 108 17:22:12 <sgk>	i'm trying to figure out if there are two limits at work here
 109 17:22:43 <sgk>	or at least, our notion of the CMD line length is exceeded
 110 17:23:01 <sgk>	(bus coming in ~1-2 minutes, i'll have an interrupt)
 111 17:23:12 <Garyo>	The ticket says it generates LNK1170, a linker error (not cmd.exe)
 112 17:23:35 <sgk>	good point
 113 17:23:46 <sgk>	it's the linker that interprets the @tmpfile thing
 114 17:23:57 <sgk>	gotta run, biab
 115 17:23:59 *	sgk has quit (Quit: sgk)
 116 17:24:02 <jason_at_intel>	the fix was to make a new line before that link limit was hit
 117 17:25:28 <Garyo>	yes -- the fix in the post is to just join all the elements with newlines...
 118 17:25:57 <Garyo>	I just googled it and even vs2010 has this limit (128k chars on a line) and the suggested workaround is the same, use newlines
 119 17:26:17 <jason_at_intel>	I believe the icl, cl and link tools handle input files in this format
 120 17:27:05 *	sgk (~sgk@67.218.107.184) has joined #SCONS
 121 17:27:16 <sgk>	hello again
 122 17:27:18 <GregNoel>	So what to do with the issue?  We've pretty much reached the discussion limit.
 123 17:27:19 <Garyo>	right.  Your point is that TEMPFILE could be used for other tools which might barf on newlines, right?
 124 17:27:31 <jason_at_intel>	yep
 125 17:27:47 <Garyo>	I think either (a) an arg to TEMPFILE for what spacer to use, or (b) two versions of TEMPFILE
 126 17:28:05 <jason_at_intel>	... I think it would be easy to tweak tempfile to workaround this however.. I think
 127 17:28:20 <sgk>	yeah, we can make TEMPFILE configurable in some way
 128 17:28:31 <Garyo>	that'd be my 1st choice.
 129 17:28:58 <jason_at_intel>	if we can pass in a separator value to be used to the $Tempfile call.. i do stuff like this in Parts with the mappers objects
 130 17:29:07 <GregNoel>	So what to do with the issue?  We've pretty much reached the discussion limit.
 131 17:29:23 <sgk>	jason 2.1 p3 ?
 132 17:29:28 <jason_at_intel>	Since I seem to be fixing it.. I can take a stab at it
 133 17:29:40 <Garyo>	Jason, if you'll investigate it that'd be awesome.
 134 17:29:46 <GregNoel>	done
 135 17:29:52 <GregNoel>	2281 I'll go with research sk; what priority?
 136 17:30:11 <sgk>	i think it's a corner case, so I'd suggest p4
 137 17:30:19 <Garyo>	fine w/ me
 138 17:30:24 <GregNoel>	done
 139 17:30:34 <GregNoel>	2285
 140 17:30:53 <sgk>	2.1 p4 sk
 141 17:31:09 <GregNoel>	done
 142 17:31:11 <GregNoel>	2380
 143 17:31:11 <Garyo>	I think it has to be -- only you understand that stuff
 144 17:31:19 <sgk>	yeah
 145 17:31:21 <sgk>	:-(
 146 17:31:44 <jason_at_intel>	I woudl want to talk to you about this as well when i visit
 147 17:31:54 <Garyo>	2380?  Is it controversial?
 148 17:31:55 <sgk>	2380:  2.1 p4 ...  who?
 149 17:32:05 <jason_at_intel>	I want Scons to handle symlink and hardlinks on windows
 150 17:32:19 <jason_at_intel>	I Have it working.. but it really needs fixes in SCons
 151 17:33:04 <jason_at_intel>	then there is permission issues on windows.. so link might have to copy
 152 17:33:20 <Garyo>	I could do it but not for 2.1.  If it's me, it'd be 2.2 p3 garyo
 153 17:33:58 <Garyo>	(2380, not symlinks on windows of course)
 154 17:34:03 <sgk>	since it's low priority, 2.x p3 and punt on assigning someone for now?
 155 17:34:46 <GregNoel>	Hearing no objection, done
 156 17:34:50 <Garyo>	ok
 157 17:34:49 <GregNoel>	1745
 158 17:35:09 <Garyo>	see my comment
 159 17:35:16 <jason_at_intel>	ya.. but the issue is related to the File.<api> that needs to replace all os.<fileapi> calls
 160 17:35:38 <jason_at_intel>	:-)
 161 17:35:38 <sgk>	we've been loading up jason
 162 17:35:39 <Garyo>	jason, I think 1745 can be fixed w/o any of that.
 163 17:35:54 <sgk>	i see bdbaddog's signed in, is bill here?
 164 17:35:59 <bdbaddog>	yes
 165 17:36:48 <sgk>	bill, any of these look up your alley?
 166 17:36:20 <jason_at_intel>	why i think making all files precious is better than deleting them by default
 167 17:37:08 <Garyo>	ok, but the minimal change for 1745 is just to make the .ilk file a side effect.
 168 17:37:25 <sgk>	ah
 169 17:37:25 <jason_at_intel>	so is there anyway we can modify the object builder on windows?
 170 17:37:29 <Garyo>	Making incremental links work should maybe be a separate ticket.
 171 17:37:29 <bdbaddog>	so mslink emitter work then right?
 172 17:37:31 <jason_at_intel>	I am not sure where that is
 173 17:37:53 <Garyo>	bdbaddog: seems like it to me
 174 17:37:54 <sgk>	agree w/garyo re: a separate ticket for incremental links
 175 17:38:11 <jason_at_intel>	so this bug directly, is just a addition to .ilk files
 176 17:38:16 <jason_at_intel>	as a sideeffect
 177 17:38:24 <jason_at_intel>	given that the flags support it
 178 17:38:31 <bdbaddog>	are the .ilk's always generated?
 179 17:38:45 <bdbaddog>	or do some ms flags enable/disable them?
 180 17:38:46 <jason_at_intel>	there is some flag to force no incremental build
 181 17:38:47 <Garyo>	unless /noincremental or something like that
 182 17:39:08 <Garyo>	but I think it's ok to declare a side effect that doesn't get generated
 183 17:39:12 <Garyo>	(right?)
 184 17:39:28 <sgk>	i think so
 185 17:39:38 <GregNoel>	I think so, too
 186 17:39:18 <bdbaddog>	o.k. I can take it then.
 187 17:39:27 <Garyo>	thanks!
 188 17:39:38 <bdbaddog>	if the scope is .ilk's get deleted with --clean afterwards.
 189 17:39:54 <Garyo>	agreed, minimal scope
 190 17:39:59 <sgk>	yeah, if it turns into something bigger than that, we should re-review it
 191 17:40:04 <GregNoel>	milestone and priority?
 192 17:40:19 <Garyo>	2.1 p4, imho
 193 17:41:35 <sgk>	sounds good, bdbaddog++
 194 17:40:23 <sgk>	the only pitfall i can think of is if non-existent side-effect files trigger unnecessary rebuilds
 195 17:40:29 <sgk>	i don't think they do, but i don't remember
 196 17:40:47 <bdbaddog>	sgk: 99% sure you're right
 197 17:40:50 <Garyo>	sgk: I'm pretty sure not.
 198 17:41:06 <GregNoel>	sgk, I'm pretty sure they don't; that's why Russel uses them in the LaTeX builder.
 199 17:40:45 <sgk>	we should set a target date for 2.1
 200 17:40:23 <bdbaddog>	when are we thinking 2.1 will be?
 201 17:40:50 <sgk>	discuss after the issues?
 202 17:41:39 <GregNoel>	milestone and priority?
 203 17:41:41 <Garyo>	roadmap says 2.1 rc sept, 2.1 final oct.
 204 17:42:04 <sgk>	1745:  2.1 p4 bdbaddog
 205 17:42:13 <GregNoel>	done
 206 17:42:18 <jason_at_intel>	ahh the option is /INCREMENTAL
 207 17:42:51 <sgk>	why'd they pick an obscure option like that to control incremental linking?  :-)
 208 17:42:16 <GregNoel>	2355
 209 17:43:12 <Garyo>	2355 clearly needs research.
 210 17:43:34 <jason_at_intel>	I agree
 211 17:44:49 <jason_at_intel>	worse case the builder can add a cd <dir> && before the command is the subprocess thing does not work
 212 17:44:03 <Garyo>	Greg, would you like to look into the subprocess thing?
 213 17:45:00 <GregNoel>	Er, no.  I already know chdir= doesn't affect the main process on a Real Operating System; the question is about lesser operating systems.
 214 17:45:24 <bdbaddog>	You mean like MacOS right...;)
 215 17:45:57 <jason_at_intel>	should be simple to test
 216 17:46:24 <Garyo>	Simple to test, a bit scary to implement I think
 217 17:46:27 <sgk>	heh
 218 17:45:21 <Garyo>	In any case it doesn't seem practical to get into 2.1.  How about aiming for 2.2?
 219 17:46:58 <GregNoel>	Well, we've always had converting to subprocess() as a goal, but not in 2.1 I don't believe.
 220 17:47:32 <bdbaddog>	GN: I agree.. 2.2
 221 17:47:33 <Garyo>	So maybe this will just fall out of that conversion?
 222 17:47:38 <Garyo>	That'd be great.
 223 17:47:40 <jason_at_intel>	it seem doing subprocess in SCons first then chdir seem to be the best order
 224 17:47:50 <Garyo>	Agreed.
 225 17:47:51 <bdbaddog>	JAI: +1
 226 17:48:19 <sgk>	GregNoel:  looks like it's ok on windows, the cwd= argument is passed to CreateProcess()
 227 17:48:49 <sgk>	yeah, subprocess first
 228 17:48:55 <bdbaddog>	+1
 229 17:48:59 <bdbaddog>	should we file a bug for that?
 230 17:49:11 <sgk>	if there isn't one already open, yes
 231 17:50:09 <bdbaddog>	1955 might be part of that..
 232 17:50:24 <Garyo>	was just looking at that one
 233 17:50:53 <GregNoel>	What to do with this issue?  We're running short on time.
 234 17:51:10 <bdbaddog>	2.2
 235 17:51:14 <Garyo>	2.2 (but after subprocess), p2, whoever does subprocess.
 236 17:51:14 <sgk>	2.2 sounds right
 237 17:51:19 <jason_at_intel>	Say it depend on SCons Subprocess work
 238 17:51:43 <sgk>	1955 is dup with others that deal with long lines
 239 17:51:53 <sgk>	so I'll open an issue for the subprocess work
 240 17:52:04 <sgk>	and then we make 2355 depends on that one
 241 17:52:14 <Garyo>	sgk: +1
 242 17:52:35 <GregNoel>	sgk, yes, but what for this issue? 2.2 p2?  Who owns it?
 243 17:52:01 <jason_at_intel>	I might be able to help with that as well
 244 17:52:09 <jason_at_intel>	as Parts does this in SCons...
 245 17:52:26 <sgk>	jason_at_intel:  cool, thanks
 246 17:52:35 <jason_at_intel>	not sure what is scons defines the default "SPAWN" function however.. so i have not made a patch to SCons
 247 17:53:05 <Garyo>	Greg: I recommend assigning to sgk for now, he can reassign later if desired.
 248 17:53:11 <bdbaddog>	+1
 249 17:53:12 <bdbaddog>	:)
 250 17:53:13 <sgk>	sounds good
 251 17:53:18 <jason_at_intel>	+1
 252 17:53:16 <GregNoel>	done
 253 17:53:18 <GregNoel>	That covers the issues@scons issues; on to the new issues.
 254 17:53:18 <GregNoel>	2649 I'll go with research sk; what priority?
 255 17:53:40 <Garyo>	p3
 256 17:54:06 <GregNoel>	sgk?  What say you?
 257 17:54:33 <sgk>	yes
 258 17:54:38 <GregNoel>	done
 259 17:54:41 <GregNoel>	2650 consensus review next time
 260 17:54:41 <GregNoel>	2657
 261 17:55:14 <Garyo>	2.1 p2 sk
 262 17:55:19 <jason_at_intel>	Glad i have not seen this on our 64-bit boxes yet
 263 17:55:26 <sgk>	consensus 2.1 p2 sk done
 264 17:55:29 <GregNoel>	done
 265 17:55:31 <GregNoel>	2660 consensus research sk; what priority?
 266 17:55:40 <sgk>	p3
 267 17:56:08 <GregNoel>	done
 268 17:56:14 <GregNoel>	2661 consensus 2.1 p2 Bill
 269 17:56:14 <GregNoel>	2662 OK, I'll take it as 2.2 p4
 270 17:56:14 <GregNoel>	2663 consensus 2.1 p3 Bill
 271 17:56:14 <GregNoel>	That appears to be it for the day...  Anything else?
 272 17:56:28 <Garyo>	nice work all, just under an hour
 273 17:56:32 <sgk>	oh, heh:  my comment about 2661 was "try to keep SCons reasonably current with VC tools"
 274 17:56:34 <bdbaddog>	1.3.1.. push out from last checkpoint?
 275 17:57:04 <sgk>	yes
 276 17:56:56 <Garyo>	bdbaddog: absolutely.  No complaints whatsoever that I've heard.
 277 17:57:49 <bdbaddog>	what about last 2.0.1 checkpoint? release as 2.0.1? rebranch to remove extra changes? other?
 278 17:58:49 <Garyo>	I think we should try not to be pedantic -- push out as 2.0.1 as is, let's get going on 2.1 work.
 279 17:59:15 <Garyo>	(?)
 280 17:59:21 <bdbaddog>	+1 from me.
 281 18:00:06 <sgk>	+1
 282 18:00:31 <jason_at_intel>	+1 for me... I think the patches added here make the first drop we can use at work without breaking anything
 283 18:01:49 <jason_at_intel>	( since 1.2)
 284 18:01:36 <bdbaddog>	K. then I'll try and roll out 1.3.1 and 2.0.1 this weekend.
 285 18:01:46 <Garyo>	yay bdbaddog!
 286 18:01:29 <sgk>	so 2.1 release candidate in september--shall we pick a week to target?
 287 18:01:56 <bdbaddog>	I'm on vaca the whole first week thereof.
 288 18:02:09 <bdbaddog>	so later in ssept would be better.
 289 18:02:42 <sgk>	hmm, looking at the roadmap, i realize my real question is, when do we want to start releasing pre-2.1 checkpoints?
 290 18:03:00 <sgk>	the roadmap suggests one in july and one in august
 291 18:03:14 <sgk>	i'm trying to give myself a tangible near-term deadline to get going on some of these things
 292 18:03:51 <Garyo>	Don't think we have enough in yet for one now.  Maybe end of July?
 293 18:03:17 <bdbaddog>	has trunk diverged from 2.0.1 much?
 294 18:03:57 <sgk>	not much yet, but I'm about to start making some big doc changes
 295 18:04:01 <Garyo>	I'll try to get a few more things done soon.
 296 18:04:12 <Garyo>	This weekend e.g.
 297 18:04:26 <sgk>	okay, ditto
 298 18:04:52 <bdbaddog>	so checkpoint 7/31?
 299 18:05:01 <Garyo>	Let's aim for that.
 300 18:05:05 <sgk>	sounds like a good stake in the ground
 301 18:05:07 <bdbaddog>	k.
 302 18:05:30 <sgk>	any other issues to cover?
 303 18:06:09 <sgk>	going once...
 304 18:06:10 <jason_at_intel>	not from me... I will send some questions tomorrow to get tempfile working
 305 18:06:11 <Garyo>	none here
 306 18:06:11 <bdbaddog>	nope.
 307 18:06:13 <sgk>	going twice...
 308 18:06:18 <sgk>	okay, sold
 309 18:06:24 <sgk>	thanks for the good work, everyone
 310 18:06:39 <GregNoel>	G'night all...
 311 18:06:40 <Garyo>	bye 4 now
 312 18:06:43 <bdbaddog>	gnight
 313 18:06:44 <sgk>	bye
 314 18:06:46 *	sgk (~sgk@67.218.107.184) has left #SCONS
 315 18:06:47 <jason_at_intel>	night!
 316 18:06:58 *	You have been marked as being away
 317 18:07:22 *	jason_at_intel has quit (Quit: ChatZilla 0.9.86 [Firefox 3.6.6/20100625231939])
 318 21:23:49 *	Garyo has quit (Quit: ChatZilla 0.9.86 [Firefox 3.6.7/20100713130626])
 319 23:42:18 *	bdbaddog has quit (Quit: Leaving.)
 320 

BugParty/IrcLog2010-07-20 (last edited 2010-07-22 00:49:38 by ip68-7-79-188)