[00:01:42] *** Tashtego has quit IRC
[00:09:14] *** maeste_afk has quit IRC
[00:09:47] *** maeste_afk has joined #jbosstesting
[00:11:21] *** maeste_afk has quit IRC
[00:11:47] *** maeste_afk has joined #jbosstesting
[00:28:17] *** maeste_afk has quit IRC
[00:31:02] *** michaelschuetz has quit IRC
[00:55:40] *** lightguard_jp has quit IRC
[01:24:13] *** bleathem has quit IRC
[01:49:12] *** aslak has quit IRC
[02:41:21] <jbossbot> git [shrinkwrap] push SHRINKWRAP-140 6ab117d.. Andrew Lee Rubinger [SHRINKWRAP-140] Remove notion of ArtifactSBuilder; handled by ArtifactBuilder just fine
[02:41:22] <jbossbot> jira [SHRINKWRAP-140] Support loading artifacts from a Maven repository [Open (Unresolved) Feature Request, Major, Karel Piwko] https://issues.jboss.org/browse/SHRINKWRAP-140
[02:41:22] <jbossbot> git [shrinkwrap] push SHRINKWRAP-140 0827209.. Andrew Lee Rubinger [SHRINKWRAP-140] Unified entry point for DependencyResolver creation; refactoring to simplify and separate the API.  All tests passing.
[02:41:23] <jbossbot> git [shrinkwrap] push SHRINKWRAP-140 URL: http://github.com/shrinkwrap/shrinkwrap/compare/be9cd03...0827209
[02:46:52] *** ldimaggi has joined #jbosstesting
[02:48:32] <jbossbot> git [arquillian] push ARQ-370 54d35ff.. Andrew Lee Rubinger [ARQ-370] Update to reflect latest SHRINKWRAP-140 refactorings
[02:48:33] <jbossbot> jira [ARQ-370] Merge remote aslakknutsen/the_bigger_picture back into upstream/master [Open (Unresolved) Task, Major, Andrew Rubinger] https://issues.jboss.org/browse/ARQ-370
[02:48:34] <jbossbot> jira [SHRINKWRAP-140] Support loading artifacts from a Maven repository [Open (Unresolved) Feature Request, Major, Karel Piwko] https://issues.jboss.org/browse/SHRINKWRAP-140
[02:48:34] <jbossbot> git [arquillian] push ARQ-370 URL: http://github.com/arquillian/arquillian/compare/4209e3a...54d35ff
[03:14:04] <jbossbot> git [shrinkwrap] push master e29ebae.. Andrew Lee Rubinger Merge branch 'master' into SHRINKWRAP-140
[03:14:05] <jbossbot> jira [SHRINKWRAP-140] Support loading artifacts from a Maven repository [Open (Unresolved) Feature Request, Major, Karel Piwko] https://issues.jboss.org/browse/SHRINKWRAP-140
[03:14:05] <jbossbot> git [shrinkwrap] push master 52f3366.. Andrew Lee Rubinger [SHRINKWRAP-140] Create an API allowing creation of any DependencyBuilder from a unified entry point
[03:14:06] <jbossbot> git [shrinkwrap] push master 3f516b2.. Karel Piwko SHRINKWRAP-140 Split of API
[03:14:06] <jbossbot> git [shrinkwrap] push master 30f23f4.. Karel Piwko SHRINKWRAP-255 Split API and removed DependencyFilter...
[03:14:06] <jbossbot> jira [SHRINKWRAP-255] Clean up dependencies API  - remove DependencyFilter [Resolved (Done) Feature Request, Major, Karel Piwko] https://issues.jboss.org/browse/SHRINKWRAP-255
[03:14:06] <jbossbot> git [shrinkwrap] push master 79e7be0.. Karel Piwko SHRINKWRAP-255 Wrappers removed, fixed StrictFilter...
[03:14:07] <jbossbot> git [shrinkwrap] push master f9cec32.. Karel Piwko SHRINKWRAP-255 Logging levels shifter to be less verbose
[03:14:07] <jbossbot> git [shrinkwrap] push master 60494cc.. Karel Piwko SHRINKWRAP-255 Changed Filter package
[03:14:07] <jbossbot> git [shrinkwrap] push master 1a3c0d8.. Karel Piwko SHRINKWRAP-255 Renamed converter methods
[03:14:08] <jbossbot> git [shrinkwrap] push master 2113330.. Andrew Lee Rubinger [SHRINKWRAP-140] Renaming and API refactoring atop kpiwko experimental branch
[03:14:08] <jbossbot> git [shrinkwrap] push master 27bcaf5.. Andrew Lee Rubinger [SHRINKWRAP-140] Package renaming in impl-maven
[03:14:09] <jbossbot> git [shrinkwrap] push master 1bdb248.. Andrew Lee Rubinger [SHRINKWRAP-140] Package renaming in impl-maven test sources
[03:14:09] <jbossbot> git [shrinkwrap] push master 020ad24.. Andrew Lee Rubinger [SHRINKWRAP-140] Correct the POM parents for extension-resolver modules
[03:38:35] <jbossbot> git [shrinkwrap] push SHRINKWRAP-140 URL: http://github.com/shrinkwrap/shrinkwrap/compare/0827209...0000000
[04:04:17] *** ALR has quit IRC
[04:13:35] *** ALR has joined #jbosstesting
[05:50:18] *** echelog-2 has joined #jbosstesting
[06:01:13] *** echelog-2 has joined #jbosstesting
[07:12:51] *** michaelschuetz has joined #jbosstesting
[07:30:33] *** michaelschuetz has quit IRC
[07:48:32] <hatchetman82> ..
[07:54:50] *** mgoldmann has joined #jbosstesting
[08:01:02] *** michaelschuetz has joined #jbosstesting
[08:05:41] *** vtunka has joined #jbosstesting
[08:08:55] *** jharting has joined #jbosstesting
[08:12:25] *** michaelschuetz has quit IRC
[08:19:30] *** Jaikiran has joined #jbosstesting
[08:27:24] <nickarls> .
[08:29:31] *** vtunka has quit IRC
[08:31:59] *** hatchetman82 has quit IRC
[08:43:18] *** vtunka has joined #jbosstesting
[08:47:22] *** ge0ffrey has joined #jbosstesting
[08:55:53] *** jeand has joined #jbosstesting
[09:01:46] *** lfryc has joined #jbosstesting
[09:14:28] *** michaelschuetz has joined #jbosstesting
[09:15:25] <nickarls> goddamit, how can Oracle all of a sudden swich from 0-based counting to 1-based in the latest drivers?
[09:15:58] <nickarls> setBinaryStream(0L) suddently throws "Illegal argument" and you have to use 1L to get the start at a blob
[09:16:24] *** oskutka has joined #jbosstesting
[09:23:22] *** wolfc has joined #jbosstesting
[09:28:33] *** rruss has quit IRC
[09:32:07] *** michaelschuetz has quit IRC
[09:40:31] *** Jaikiran has quit IRC
[09:45:05] *** Jaikiran has joined #jbosstesting
[09:49:53] *** kpiwko has joined #jbosstesting
[10:21:26] *** alesj has joined #jbosstesting
[10:21:27] *** aslak has joined #jbosstesting
[10:21:50] *** aslak has quit IRC
[10:21:50] *** aslak has joined #jbosstesting
[10:36:09] *** Jaikiran has quit IRC
[10:40:27] *** maeste has joined #jbosstesting
[11:16:20] *** michaelschuetz has joined #jbosstesting
[11:34:14] *** oskutka has quit IRC
[11:55:00] *** Jaikiran has joined #jbosstesting
[12:06:30] *** jharting has quit IRC
[13:28:42] *** kpiwko has quit IRC
[13:29:23] *** kpiwko has joined #jbosstesting
[13:32:11] *** ldimaggi has joined #jbosstesting
[13:32:16] *** ldimaggi is now known as ldimaggi_wfh
[13:48:23] *** Jaikiran has quit IRC
[13:49:12] *** Jaikiran has joined #jbosstesting
[14:36:41] *** bobmcw has joined #jbosstesting
[14:50:40] *** lightguard_jp has joined #jbosstesting
[15:25:02] *** rruss has joined #jbosstesting
[15:25:47] *** rruss has quit IRC
[15:31:19] *** michaelschuetz has quit IRC
[15:32:06] *** michaelschuetz has joined #jbosstesting
[16:29:45] *** mgoldmann has quit IRC
[16:31:38] *** rruss has joined #jbosstesting
[16:58:10] *** bleathem has joined #jbosstesting
[17:52:59] *** ge0ffrey has quit IRC
[17:57:24] <jbossbot> git [arquillian] push ARQ-370 fc20764.. Karel Piwko ARQ-329 Introduced WebTestConfiguration interface
[17:57:25] <jbossbot> jira [ARQ-329] Support Ajocado in Selenium extension [Open (Unresolved) Feature Request, Major, Karel Piwko] https://issues.jboss.org/browse/ARQ-329
[17:57:26] <jbossbot> git [arquillian] push ARQ-370 725777d.. Karel Piwko ARQ-329 Updated ShrinkWrap packaging w.r.t. new API semantics
[17:57:26] <jbossbot> git [arquillian] push ARQ-370 042c9ea.. Karel Piwko ARQ-329 ARQAJO-2 Updated Ajocado dependency to 1.0.0.Alpha1
[17:57:26] <jbossbot> jira [ARQAJO-2] Integration with Arquillian Selenium Extension [Resolved (Done) Task, Critical, Karel Piwko] https://issues.jboss.org/browse/ARQAJO-2
[17:57:27] <jbossbot> git [arquillian] push ARQ-370 23babeb.. Karel Piwko ARQ-371 ARQ-373 Support for multiple configuration...
[17:57:27] <jbossbot> jira [ARQ-371] Split Arquillian Selenium configuration according to framework [Open (Unresolved) Task, Major, Karel Piwko] https://issues.jboss.org/browse/ARQ-371
[17:57:28] <jbossbot> jira [ARQ-373] Support multiple Web Test objects in one test [Open (Unresolved) Task, Major, Karel Piwko] https://issues.jboss.org/browse/ARQ-373
[17:57:28] <jbossbot> git [arquillian] push ARQ-370 640b5a1.. Karel Piwko ARQ-329 Improved API and updated JavaDoc
[17:57:29] <jbossbot> git [arquillian] push ARQ-370 URL: http://github.com/arquillian/arquillian/compare/8f6dae1...640b5a1
[18:07:46] *** lightguard_jp has quit IRC
[18:15:46] *** lfryc has quit IRC
[18:19:13] *** alesj has left #jbosstesting
[18:26:00] *** thohawk has joined #jbosstesting
[18:26:50] <thohawk> hi, is it possible to add an external jar file to an enterprisearchive in arquillian?
[18:27:59] *** michaelschuetz has quit IRC
[18:29:25] <thohawk> seems that arquillian creates its own ear file without my external jar afterwards...
[18:34:53] <thohawk> anyone?
[18:36:38] *** thohawk has quit IRC
[18:39:35] <kpiwko> thohawk: yes, it is, but you already left
[18:50:35] *** rruss has quit IRC
[18:55:16] *** vtunka has quit IRC
[18:55:36] *** lightguard_jp has joined #jbosstesting
[19:04:39] *** rruss has joined #jbosstesting
[19:12:58] <aslak> :)
[19:25:13] *** rruss has quit IRC
[19:25:55] *** kpiwko has quit IRC
[19:26:03] *** ALR has joined #jbosstesting
[19:39:45] <ALR> aslak: Didja see?
[19:40:21] <aslak> ALR, release? yea
[19:40:38] <ALR> Man, what a weight off.
[19:40:43] <aslak> :)
[19:40:49] <ALR> Can't wait to get back into regular cycles.
[19:41:04] <aslak> I haven't looked into hte new 140 much yet, but it seemed you had renamed Dependencies to MavenResolver ?
[19:44:48] <ALR> DependencyResolvers.use(MavenDependencyResolver.class)
[19:45:02] <ALR> So the entry point is "DependencyResolvers"
[19:45:11] <ALR> MavenDependencyResolver is the Maven API we support now.
[20:01:13] *** mgoldmann has joined #jbosstesting
[20:01:13] <aslak> ALR, ok, i'll have a closer look after dinner.. :)
[20:01:42] <ALR> aslak: Again, no rush.
[20:01:46] <ALR> ARQ is updated to use it
[20:01:54] <ALR> And we can still change the SW-140 APIs
[20:02:22] <ALR> But I wanted to get a chance to separate out things more, and unify some of Karel's stuff a bit.  I'm interested to see what he thinks.
[20:08:06] *** Jaikiran has quit IRC
[20:13:58] *** kpiwko has joined #jbosstesting
[20:15:43] <ALR> kpiwko: There he is.
[20:16:03] <kpiwko> ALR: hi
[20:16:19] <ALR> kpiwko: You might wanna review the changes I made to your stuff and see if you like how I maybe ruined it. :)
[20:16:20] <kpiwko> ALR: congratulations to alpha-12 release
[20:16:31] <ALR> kpiwko: But I got it "right enough" I think for release.
[20:16:37] <ALR> At least in terms of separation.
[20:16:39] <ALR> Thanks :)
[20:16:47] <ALR> kpiwko: Some highlights of my changes:
[20:17:07] <ALR> DependencyResolvers.use(MavenDependencyResolver.class) < Entry point
[20:17:21] <ALR> Also I merged the idea of a "resolver" and a "dependency builder" into the same user view.
[20:17:51] <ALR> So "MavenDependencyResolver" is pretty much what the user sees and interacts with.
[20:18:25] <kpiwko> ALR: seams reasonable
[20:18:31] <ALR> It's entirely possible that I've broken something in there; I haven't yet looked at Code Coverage
[20:18:38] <ALR> But I was able to keep all your tests green
[20:18:43] <kpiwko> great
[20:18:47] <ALR> So I pulled the trigger.
[20:19:01] <ALR> kpiwko: But don't think I unilaterally changed your stuff and that's that.
[20:19:10] <ALR> Have a look and let's discuss anything you don't like.
[20:19:41] <kpiwko> actually the main reason why I split DependencyResolver from DependencyBuilder was not to allow user to be able to call resolve() with no artifacts defined
[20:20:11] <ALR> Hm.
[20:20:20] <ALR> Well now the main impl class is...big.
[20:20:28] <ALR> Because of ArtifactBuilder and ArtifactsBuilders
[20:20:34] <ALR> Which are inner classes of the Maven impl
[20:20:42] <ALR> And they're wrapping a delegate.
[20:20:53] <ALR> To override some methods
[20:21:07] <ALR> But preserve the same backing repository system and dependency info.
[20:25:37] <kpiwko> actually, I don't get why DependencyBuilder is a part of API...you think artifact concept is general enough to be shared between all implementations?
[20:29:12] <kpiwko> ALR:^
[20:29:35] <kpiwko> is there a reason why StrictFilter was kept with implementation?
[20:33:54] <kpiwko> if its because of MavenConverter in internals, this could be solved by providing a compare method into MavenDependency iface
[20:36:52] <kpiwko> the problem is, StrictFilter is maybe the most important one, because it allows user to avoid transitive deps
[20:40:10] <ALR> kpiwko: Yeah, just the internals part.  I meant to ask you about that.
[20:40:19] <ALR> (For StrictFilter)
[20:40:47] <ALR> DepBuilder in the API: I figure everything will be able to have some notion of resolution based upon a String input
[20:40:59] <ALR> In Maven's case it's groupId:artifactId:version:scope
[20:41:10] *** jc3 has joined #jbosstesting
[20:41:13] <ALR> But I think other backends will also resolve on some String
[20:42:18] *** michaelschuetz has joined #jbosstesting
[20:42:54] <jc3> aslak: howdy! remember that time back at band camp when you said in-container ruby testing would be easy?  i just somehow needed to pass the code via some internal web server or something like that?
[20:45:29] <aslak> jc3, you need to impl a AuxiliaryArchiveAppender to package up the rspec to have it deployed, and a impl of TestRunner that runs RSpec tests based on Class and Method
[20:46:44] <kpiwko> ALR: at least there will be resolvers JIRA for alpha-13, to move StrictFilter :)
[20:46:45] <jc3> aslak: is this still relevant?  https://gist.github.com/864777
[20:47:51] <aslak> jc3, yes, with the added AuxiliaryArchiveAppender i forgot to mention the last time..
[20:47:58] <kpiwko> I meant at least one JIRA will be there, the rest of the code is bug-free, out course :)
[20:48:03] <ALR> kpiwko: Super
[20:48:06] <kpiwko> out -> of
[20:48:21] <ALR> kpiwko: Of course.  I'll make a JIRA to check out the coverage in clover to see how well-tested we are
[20:48:29] <jc3> aslak: k, i'll start there, thanks!
[20:48:32] <aslak> jc3, not to familliary with the ruby world, but if it can be deployed as a war, with the libs and rails app in it, then it should be good to go
[20:48:48] <kpiwko> ALR: great
[20:50:27] <kpiwko> aslak: welcome back from vacations :)
[20:50:36] *** mgoldmann has quit IRC
[20:51:23] <jc3> aslak: cool.  we're quickly outgrowing our external-container testing ways.  bobmcw tests too friggin much, and firing up an app server between each one takes FOREVER!
[20:52:15] <bobmcw> we only fire up the AS twice!
[20:52:18] <bobmcw> once for junits, once for specs
[20:52:24] <bobmcw> jeez
[20:52:27] <kpiwko> ALR: have you discussed GIT Work Flow with Dan?
[20:52:32] <ALR> kpiwko: Yep.
[20:52:49] <jc3> bobmcw: well, then deployment takes too long.  *SOMETHING* takes too long between each spec.
[20:53:07] <kpiwko> ALR: Did you convince you it is a must-have feature?
[20:53:21] <kpiwko> *Did him
[20:53:40] <ALR> kpiwko: Oh, I'm on board with it.
[20:54:00] <ALR> But he explained that closing a pull request doesn't resolve the issue
[20:54:08] <ALR> Either way I say let's give it a spin.
[20:54:17] <ALR> And make some corrections along the way if need be.
[20:54:34] <ALR> Good idea guys.
[20:59:55] <aslak> jc3, not sure incontainer mode will change how you start the appserver but
[21:00:45] <aslak> jc3, and if you start a AppServer outside of Arq and use the jboss-remote-container, you can reuse the same server over and over.. and maybe over, until it runs out of permgen.. :)
[21:01:04] <aslak> kpiwko, thank you.. :)
[21:02:28] <bobmcw> I wonder... is it possible for N testcases to share a single deployment cycle?
[21:02:49] <bobmcw> in the context of app1.war, run this large bag of distinct test-cases
[21:02:53] <ALR> That's the kind of thing I've been meaning to bring up again w/ aslak
[21:03:12] <ALR> Allowing the user to determine which container event is bound to which test lifecycle event
[21:03:15] <bobmcw> we have FormHandlingTest, SessionHandlingTest, organized as separate tests
[21:03:24] <bobmcw> but all run against our basic-app.knob archive, roughly speaking
[21:03:49] <bobmcw> the app is sorta like a fixture for us, I guess
[21:03:55] <bobmcw> for N testcases
[21:03:58] <kpiwko> actually, I have an use case where user might want to skip deployment at all...e.g. app is already deployed
[21:04:10] <ALR> kpiwko: That's part of it.
[21:04:32] <ALR> kpiwko: And also there's the issue that Laird Nelson raised, wanting to skip explicit @Deployment
[21:04:42] <aslak> bobmcw, working on that. a Arq Suite if you may, where you define Deployments on Suite level and a Suite can contain multiple test classes
[21:04:52] <ALR> IMO we need to let the user configure the events.
[21:05:03] <bobmcw> aslak: yes
[21:05:05] <bobmcw> aslak: thank yoU!
[21:05:10] <ALR> aslak: I think we can decouple more than just by providing an Arq Quite.
[21:05:12] <ALR> *Suite
[21:05:21] <bobmcw> suite would be sweet
[21:05:31] <bobmcw> especially if you get away from static methods and annotations :)
[21:05:32] <ALR> Embassy Sweet.
[21:06:44] <ALR> bobmcw: Related: http://community.jboss.org/message/592104
[21:06:52] <ALR> I need to reply to that post, actually.
[21:07:02] <jc3> bobmcw: so in-container doesn't really make us faster cuz the deployment time takes just as long?  all we save is the time for GETs rather than method calls?
[21:07:04] <ALR> And detail what I'm thinking here a bit more
[21:07:06] <aslak> bobmcw, well, the use of static is because they don't belong to a instance, there is no instance of the test class a deploy time. it's just to 'bundle' the deployment and testcase as one unit
[21:07:45] <aslak> bobmcw, annotations is the java way :) but Arq will have / has SPIs you can use to get load/parse the metadata as you need it
[21:08:00] <bobmcw> jc3: I think we could replace some of stuff with in-container tests
[21:08:06] <bobmcw> but some needs to be a rails app deployed, etc
[21:09:17] <jc3> i guess i was thinking ARQ had some way of simulating the container so that we wouldn't "really" be deploying anything to a running jboss.
[21:09:27] <aslak> bobmcw, @Deployment and static deploy methods are really just the default implementation of the DeploymentScenarioGenerator SPI. you could load all of that metadata from a file or a database if you wantex to
[21:10:07] <bobmcw> for reals?
[21:10:11] <bobmcw> jc3: ^
[21:10:30] <aslak> bobmcw, still a few Annotations deps in there, but working on extracting them out and have a 'Metadata' layer that it all goes through
[21:10:41] <bobmcw> coolbeans
[21:12:51] <aslak> kpiwko, yea, no defined Deployment is another scenario in workings
[21:15:17] <aslak> kpiwko, a tiny issue there tho is that without a deployment we have minimal info about the container, like ip / ports etc, since that is all relevant/extracted based on a deployment (thing domain server deployment etc)
[21:16:41] <aslak> jc3, the benefit of having in-container tests is that you don't have to write 'servlets' to access what you want to test, but rather move that to the test method. e.g. lookup transactions messaging etc
[21:16:49] <kpiwko> aslak, I see
[21:17:32] <kpiwko> aslak, but if user wants no deployment, he should now how to access app which he'd deployed manually
[21:17:44] <kpiwko> or which is deployed within AS
[21:18:34] <aslak> kpiwko, true
[21:19:55] <aslak> ALR, which container events are you refering to? start / stop / deploy / undeploy?
[21:26:16] <ALR> aslak: Yeah.
[21:26:35] <ALR> Basically just letting the user map 'em to whatever test lifecycle event they want
[21:27:00] * ALR be back.
[21:28:15] <aslak> ALR, yea, opened up for that in the ContainerEventController, a Handler that is between the Test events and a Contianer event set.
[21:28:42] <ALR> Who-ahh. :)
[21:28:55] <ALR> aslak: In the coming weeks I should be getting familiar again w/ ARQ internals.
[21:29:33] <aslak> ALR, not exposed a way to set it yet, but the separation layer is there. Start/Stop/Deploy/Undeploy no longer 'depend' on Test LifeCycle events, but rather SetupContainers|StartContainers etc.. ContainerEventController is the mapping layer between teh two event models if you like.
[21:41:40] *** ldimaggi_wfh has quit IRC
[21:46:07] *** michaelschuetz has quit IRC
[21:49:25] *** ldimaggi has joined #jbosstesting
[21:50:57] *** rruss has joined #jbosstesting
[21:54:07] *** mgoldmann has joined #jbosstesting
[22:02:27] <aslak> and ta da.. we have Event interceptors as well
[22:18:52] *** ldimaggi has quit IRC
[22:24:31] *** rruss has quit IRC
[22:28:25] *** mgoldmann has quit IRC
[22:34:37] *** kpiwko has quit IRC
[22:35:13] *** jharting has joined #jbosstesting
[22:39:59] <nickarls> aslak: just filed https://issues.jboss.org/browse/JBIDE-8553 ,that would be a killer feature
[22:40:01] <jbossbot> jira [JBIDE-8553] Generation of Arquillian @Deployment method [Open (Unresolved) Feature Request, Major, Unassigned] https://issues.jboss.org/browse/JBIDE-8553
[22:41:05] *** Tashtego has joined #jbosstesting
[22:41:18] *** michaelschuetz has joined #jbosstesting
[22:41:23] <aslak> nickarls, hmm yea..
[22:42:07] <Tashtego> hi guys ;)
[22:42:24] <aslak> nickarls, working as a static generation, with a option of update or similar
[22:42:59] <nickarls> aslak: yep
[22:50:53] <aslak> nickarls, this one should help a bit as well: JBIDE-8548
[22:50:55] <jbossbot> jira [JBIDE-8548] Support auto discovery of remote processes for debugging [Open (Unresolved) Feature Request, Major, Unassigned] https://issues.jboss.org/browse/JBIDE-8548
[22:52:34] <aslak> no more manually adding of Remote process debug launchers, that eventually get acosiated with the wrong project and non of the source can be found..
[23:04:54] *** wolfc has quit IRC
[23:14:29] *** jharting has quit IRC
[23:29:09] *** jeand has quit IRC
[23:51:28] *** Tashtego has quit IRC





top