Timestamps are in GMT/BST.
[0:09] * mdiggory (~mdiggory@ip72-199-216-7.sd.sd.cox.net) Quit (Quit: mdiggory)
[0:23] * mdiggory (~mdiggory@ip72-199-216-7.sd.sd.cox.net) has joined #duraspace
[0:24] * mdiggory (~mdiggory@ip72-199-216-7.sd.sd.cox.net) Quit (Client Quit)
[0:31] * mdiggory (~mdiggory@ip72-199-216-7.sd.sd.cox.net) has joined #duraspace
[2:39] * mdiggory (~mdiggory@ip72-199-216-7.sd.sd.cox.net) Quit (Quit: mdiggory)
[3:44] * mdiggory (~mdiggory@ip72-199-216-7.sd.sd.cox.net) has joined #duraspace
[3:55] * mdiggory (~mdiggory@ip72-199-216-7.sd.sd.cox.net) Quit (Quit: mdiggory)
[3:56] * krnl_ (Andrius@193.219.34.106) Quit (Ping timeout: 260 seconds)
[4:02] * krnl_ (Andrius@193.219.34.106) has joined #duraspace
[5:15] * mdiggory (~mdiggory@72.199.216.7) has joined #duraspace
[6:34] -zelazny.freenode.net- *** Looking up your hostname...
[6:34] -zelazny.freenode.net- *** Checking Ident
[6:34] -zelazny.freenode.net- *** Found your hostname
[6:34] -zelazny.freenode.net- *** No Ident response
[6:34] * DuraLogBot (~PircBot@atlas.duraspace.org) has joined #duraspace
[6:34] * Topic is '[Welcome to DuraSpace - This channel is logged - http://irclogs.duraspace.org/]'
[6:34] * Set by cwilper!ad579d86@gateway/web/freenode/ip.173.87.157.134 on Fri Oct 22 01:19:41 UTC 2010
[8:35] * grahamtriggs (~grahamtri@62.189.56.2) has joined #duraspace
[12:22] * mhwood (~mhwood@2001:18e8:3:171:218:8bff:fe2a:56a4) has joined #duraspace
[13:42] * tdonohue (~tdonohue@c-98-228-50-45.hsd1.il.comcast.net) has joined #duraspace
[15:34] * mdiggory (~mdiggory@72.199.216.7) Quit (Quit: mdiggory)
[16:09] * mdiggory (~mdiggory@rrcs-74-87-47-114.west.biz.rr.com) has joined #duraspace
[19:04] * grahamtriggs_ (~Graham@cpc2-stev6-2-0-cust333.9-2.cable.virginmedia.com) has joined #duraspace
[19:07] * PeterDietz (~PeterDiet@sul272peter.lib.ohio-state.edu) has joined #duraspace
[19:20] * grahamtriggs_ (~Graham@cpc2-stev6-2-0-cust333.9-2.cable.virginmedia.com) Quit (Quit: Leaving)
[19:22] * grahamtriggs__ (~Graham@cpc2-stev6-2-0-cust333.9-2.cable.virginmedia.com) has joined #duraspace
[19:22] * grahamtriggs__ (~Graham@cpc2-stev6-2-0-cust333.9-2.cable.virginmedia.com) Quit (Client Quit)
[19:24] * grahamtriggs_ (~Graham@cpc2-stev6-2-0-cust333.9-2.cable.virginmedia.com) has joined #duraspace
[19:53] * aschweer (~schweer@schweer.its.waikato.ac.nz) has joined #duraspace
[19:55] <tdonohue> Hi all -- reminder, we have a DSpace Developers meeting here in ~5 minutes. Here's today's agenda: https://wiki.duraspace.org/display/DSPACE/DevMtg+2011-04-20
[20:00] * KevinVdV (~KevinVdV@d54C15567.access.telenet.be) has joined #duraspace
[20:00] * richardrodgers (~richardro@18.111.27.200) has joined #duraspace
[20:00] <tdonohue> Well it's that time again. DSpace Developers Mtg starts now. https://wiki.duraspace.org/display/DSPACE/DevMtg+2011-04-20
[20:01] <tdonohue> We'll kick off with our normal JIRA Quick Review. Here are the issues that still need our review: https://jira.duraspace.org/secure/IssueNavigator.jspa?reset=true&jqlQuery=project+%3D+DS+AND+resolution+%3D+Unresolved+AND+Key%3E%3DDS-781+ORDER+BY+key+ASC
[20:01] <tdonohue> Today, we'll start with DS-781
[20:01] * tdonohue hmm..no komputer today
[20:01] <tdonohue> Controlled vocabularies not shown when editing an item : https://jira.duraspace.org/browse/DS-781
[20:03] <mdiggory> wierd
[20:03] <tdonohue> any volunteers to look into this, to see if you can duplicate DS-781? seems odd to me too
[20:03] <mhwood> Two problems, really. It shouldn't throw an NPE if it can't open a file. And the probelm actually reported, to do with weird paths.
[20:03] * stuartlewis (~stuartlew@gendiglt02.lbr.auckland.ac.nz) has joined #duraspace
[20:03] <richardrodgers> I assume it's OK in later releases?
[20:04] <mdiggory> is this just jspui?
[20:04] <mdiggory> http://scm.dspace.org/svn/repo/dspace/trunk/dspace-jspui/dspace-jspui-webapp/src/main/webapp/controlledvocabulary/vocabulary2html.xsl
[20:04] <tdonohue> I think so. Component = JSPUI
[20:05] <tdonohue> volunteer for DS-781?
[20:05] <mhwood> I can look into it.
[20:05] <tdonohue> DS-781 : assign to mhwood for investigation (thanks Mark!)
[20:06] <tdonohue> Next up.. Add a resumption tokens support to ListIdentifiers verb in OAI-PMH : https://jira.duraspace.org/browse/DS-787
[20:07] <tdonohue> another OAI-PMH issue. any volunteers to test out?
[20:07] <aschweer> I should have some time today to test it
[20:08] <tdonohue> thanks aschweer. If you can report back via a comment, that'd be great. We can get kshepherd or stuartlewis to commit it, if you all are satisfied
[20:08] * grahamtriggs1 (~Graham@cpc2-stev6-2-0-cust333.9-2.cable.virginmedia.com) has joined #duraspace
[20:08] <aschweer> will do
[20:08] <tdonohue> DS-781 : aschweer will investigate and report back on patch
[20:08] <stuartlewis> Sure - no problem.
[20:09] <tdonohue> DSpace 1.7.0 only builds properly for Maven 2.2.0 or above : DS-788
[20:09] <stuartlewis> But not, IIRC, 3.0+ ?
[20:09] <stuartlewis> So currently only 2.2.x?
[20:09] <tdonohue> Right -- actually that is the case, I think there are some issues with Maven 3 as well
[20:10] <mhwood> 2.2 minimum is documented for the reported version.
[20:10] <tdonohue> so, currently we are supporting a very minimal range of 2.2.x only
[20:10] <stuartlewis> I think I updated the doco recently to mention not 3.
[20:10] <richardrodgers> I believe this was an issue for some one who wanted a stri ct Debian dist that hadn't got there
[20:10] <stuartlewis> Yep: https://wiki.duraspace.org/display/DSDOC/Installation#Installation-ApacheMaven2.2.x%28Javabuildtool%29
[20:10] <stuartlewis> Known issue with Maven 2.0.x and Maven 3.x and DSpace 1.7.0
[20:10] <stuartlewis> DSpace 1.7.0 does not build properly when using Maven 2.0.x or Maven 3.x. This is a known issue. The quick fix is to use Maven 2.2.x. More information on this issue can be found in the following JIRA issue: DS-788.
[20:11] <mdiggory> Yes, currently only 2.2.x
[20:11] <stuartlewis> Apple Mac's now default to 3.0 out the box, so support for 3 would be great
[20:11] <mdiggory> We need to clean up a few poms
[20:11] <tdonohue> Right. I guess my questions are: (1) Are we all OK with requiring 2.2.x or above. (2) Is someone working on fixes to Maven 3, so that it will work?
[20:12] <mdiggory> I expect we should do 3.0 for DSpace 1.8.0
[20:12] <mdiggory> grahamtriggs has captured the requirements already
[20:12] <tdonohue> Any volunteers for 3.0 support?
[20:12] <richardrodgers> I'm OK - with limited resources we should look at 3.0 over 2.0x issues
[20:12] <mdiggory> some "module" inclusion conventions changed
[20:13] <tdonohue> OK. I recommend we close DS-788, and then create a new issue around Maven 3.0 issues (and find a volunteer to tackle in time for 1.8.0)
[20:13] <mdiggory> we know what the issue is, but the solution is dependent on decisions we make about where and how we will manage dspace modules and the dspace-parent pom
[20:14] <mdiggory> the problem is that dspace-parent and dspace poms duplicate the includion of dspace-xxxx modules
[20:14] <mdiggory> and that doesn't work in 3.0
[20:15] <tdonohue> Ok. makes sense. don't want to dig into this too deeply now. mdiggory or grahamtriggs would one of you be willing to create a new ticket around 3.0 issues and schedule for 1.8.0?
[20:15] <grahamtriggs1> as we essentially know what needs to be done for 3.0 (and it does work with a few minor modifications to the poms), I would suggest assigning to Robin (as release co-ordinator), just as it needs someone to ensure that it's followed up for 1.8
[20:15] <mdiggory> an interim solution may be to disable the "all" profile when building dspace.pom
[20:15] <mdiggory> and visavi
[20:16] <tdonohue> I'm gonna move on, in essence of time. I'll create a ticket placeholder for 3.0 then (if no one else beats me to it) and close DS-788
[20:16] <stuartlewis> While we're JIRA-reviewing, do we need to look at DS-875? New issue affecting 1.7.1, which seems to affect the [dspace]/bin/dspace script quite badly.
[20:17] <tdonohue> SOLR - Spider detection to match on hostname or useragent : https://jira.duraspace.org/browse/DS-790
[20:17] <mdiggory> Its a warning more than an error
[20:17] <mdiggory> referring to DS-875
[20:17] <mhwood> 790: sounds reasonable, needs code.
[20:18] <tdonohue> stuartlewis -- let's wait till after this part of meeting. we're still playing "catchup" on our large backlog. We can skip to DS-875 during main discussion
[20:18] <stuartlewis> Sure - no problem.
[20:18] <stuartlewis> mhwood: +1
[20:18] <tdonohue> mhwood +1 on DS-790
[20:19] <mdiggory> DS-790 also why not add the known bingbots to a custom txt file for future releases?
[20:19] <mdiggory> bingbots = dingbats
[20:19] <mhwood> Probably should, but it's another entry in the Red Queen's Race.
[20:20] <tdonohue> mdiggory -- PeterDietz is suggesting that it's difficult to maintain listing of bots by IP addresses, and rather than filtering on IP, we should be filtering on user-agent. (or at least that's how I read it)
[20:20] <mdiggory> I think we avoided doing dns lookups for efficiency
[20:21] <mdiggory> Filtering on both was once an original requirement
[20:21] <mdiggory> # UA "msnbot/1.0 (+http://search.msn.com/msnbot.htm)"
[20:21] <mdiggory> and they are in the files
[20:21] <PeterDietz> hi all, sorry, got distracted
[20:21] <tdonohue> right, I know the user-agents are in the files, but does Solr actually filter based on user-agents? or just by IP?
[20:21] * mhwood wishes for a standard "I am a bot" header for well-behaved spiders to use. But, short of that, if they are giving us useful agent strings then we should use them.
[20:22] <stuartlewis> Just IP at present?
[20:23] <tdonohue> I think it's *just IP* at present. But, I'd agree with DS-790, that we should also allow filtering by user-agent string
[20:23] <mdiggory> Its mostly just enhancing http://scm.dspace.org/svn/repo/dspace/trunk//dspace-stats/src/main/java/org/dspace/statistics/util/SpiderDetector.java
[20:24] <tdonohue> OK. DS-790 summary: +3 vote. Needs code (enhance SpiderDetector) & volunteer
[20:24] <mdiggory> +1 for enhancing
[20:24] <richardrodgers> Does someone want to have a go at it, is the question
[20:25] <tdonohue> We'll stop the "official" JIRA review there for today.
[20:25] <mhwood> Put my name on 790.
[20:25] <tdonohue> But, stuartlewis wanted use to also take a quick look at DS-875. So, I'd like to glance at that together right now.
[20:25] <tdonohue> https://jira.duraspace.org/browse/DS-875
[20:25] <mdiggory> Do we have a field "needs volunteer" that we can put on issues?
[20:25] <tdonohue> DS-790 - assign to mhwood (thanks Mark!)
[20:26] <tdonohue> mdiggory -- no we do not. a lack of an "assignee" essentially is equal to "needs volunteer". When you volunteer for something, you should assign yourself to it
[20:27] <mdiggory> but "needs volunteer" != unassigned
[20:27] <tdonohue> why doesn't it? I feel "needs volunteer" = "unassigned". As once something has a volunteer, we assign it to that person
[20:29] <mdiggory> well, an unreviewed issue that is rejected does not need an assignee
[20:29] <tdonohue> right. but, if it's rejected, then we close or resolve it. It's no longer in our inbox
[20:30] <tdonohue> so, I guess to be more correct: "needs volunteer" = "unassigned" + "open"
[20:30] <mdiggory> someone hit me on the side of the head and say stop being so damn picky
[20:30] <tdonohue> :)
[20:31] <mdiggory> DS-875?
[20:31] <tdonohue> OK. back to DS-875, which stuartlewis wanted us to look at briefly: https://jira.duraspace.org/browse/DS-875
[20:31] * kompewter (~kompewter@sul272peter.lib.ohio-state.edu) has joined #duraspace
[20:31] <stuartlewis> I just wondered if we needed to do anything about it, as it is listed as a Mjor bug against 1.7.1.
[20:32] <stuartlewis> As Mark says, all it does it prints out stack traces - it still works.
[20:32] <stuartlewis> But at first glance you see stack traces and gulp.
[20:32] <mdiggory> so the analysis here is that your not supposed to place files ass classpath entires
[20:32] <stuartlewis> And our monitoring scripts get upset.
[20:32] <mdiggory> unless they are jars
[20:32] <mdiggory> and the shell scripts do
[20:32] <stuartlewis> What 'files
[20:32] <richardrodgers> no resrouces in classpath?
[20:33] <stuartlewis> What 'files' are you referring to?
[20:33] <mdiggory> directories, yes, non-jar files... no
[20:33] * kompewter (~kompewter@sul272peter.lib.ohio-state.edu) Quit (Remote host closed the connection)
[20:34] <mdiggory> directories of "non-jar files" yes
[20:34] <KevinVdV> Ps: just so everybody knows, the printing isn't a major problem the issue is that this way it will never load in config files from jar files when using the dspace script as oposed to the webapp where it will work
[20:35] <mdiggory> ok, so there is a deeper problem.
[20:36] <tdonohue> any volunteers to investigate this further? It sounds like there is an issue here...
[20:36] <KevinVdV> Well I looked into it and the thing it is quite easy to fix
[20:37] <KevinVdV> Only put jars in the classpath and everything will work properly
[20:37] <mdiggory> KevinVdV: do you know how the bin/dspace script gets into the CLASSPATH above?
[20:37] <tdonohue> KevinVdV would you be willing to post a patch or the fix then?
[20:37] <stuartlewis> Do we need to consider how this happened, and see if we can learn from that. A brief look at the commit logs suggest it was introduced from a change in dspace-services module, which presumably is in trunk development whilst we were in branch. Do we need to consider branching modules too?
[20:38] <KevinVdV> I am willing to post a patch
[20:38] <mdiggory> stuartlewis: we try to limit branching in favor of new version releases
[20:38] <KevinVdV> The thing is at the moment the classpaths given are the following:
[20:38] <KevinVdV> FULLPATH=$CLASSPATH:$JARS:$DSPACEDIR/config
[20:38] <KevinVdV> Leave out the $CLASSPATH (== {dspace.dir}/bin/dspace) and it will work
[20:39] <KevinVdV> & t.b.h. I don't think that this dspace script belongs in the classpath
[20:39] <stuartlewis> mdiggory: But would it be better to branch, so that we're all on branches and fixing bugs, rather than mixing 1.7.1 branch and services trunk with new features?
[20:40] <mdiggory> stuartlewis: I get what your saying... the strategy I recommned then is that dspace trunk be on dspace-services-SNAPSHOT
[20:40] <stuartlewis> Or can we do as some have suggested and bring services into main trunk, at least for a little while whilst we all get comfortable with it?
[20:40] <tdonohue> stuartlewis & mdiggory -- I suggest leaving discussions around 'branching' of dspace-services for larger discussion of *what belongs in Trunk* / Asynch release processes (as whatever you decide now may or may not be affected by that much larger discussion)
[20:40] <mdiggory> I hope that by the time we resolve the async / modularity issues... there will be less need to adjust branches.
[20:41] <richardrodgers> but the issue is the branch (presumably stable), not trunk, yes?
[20:41] <mdiggory> stuartlewis I am very very very against that
[20:42] <mdiggory> because the goal is currently the opposite, to work on eliminating the need to merge all code into one svn project
[20:42] <mdiggory> poicies about upgrading versioins of modules in branches would be more appropriate
[20:42] <tdonohue> Maybe we have a "special topics meeting" sometime in next 2 weeks on Asych Release Processes / What belongs in Trunk? This seems like something we need to come to an agreement on soon.
[20:43] <mhwood> tdonohue++
[20:43] <stuartlewis> Yeah - either way, but I guess my main thought is that does this issue need to make us consider how we manage the interplay of releases a bit more, so that a 1.x.y release is really only bug fixes, and no new untested features creep in from module trunks? But yes, can be discussed another week.
[20:43] <mdiggory> so the enhancements that happened in the branch / dspace-services were to provide backward compatable parity with the ConfigurationManager.
[20:44] <mdiggory> which was basically a bugfix
[20:44] <tdonohue> I'd prefer scheduling that Special Topics Mtg for May 4. Unfortunately, I may not be available for next weeks' mtg, and I really would want to be a part of that Special Topic Mtg
[20:45] <richardrodgers> but even bug fixes can destabilize..
[20:45] <mdiggory> TBH we should be using something like classworlds in the CLI
[20:45] <tdonohue> So, if others are OK with May 4, then I'll schedule this bigger discussion for then
[20:45] <stuartlewis> OK :)
[20:45] <mdiggory> richardrodgers: no-doubt it will occasionally happen
[20:45] <mdiggory> tdonohue: go for it
[20:46] <tdonohue> OK. May 4 = Special Topics Meeting on Async Releases + What belongs in Trunk
[20:46] <tdonohue> Anything else to say about DS-875?
[20:46] <mhwood> Patch would be appreciated.
[20:47] <mdiggory> So, for clarification
[20:47] <richardrodgers> I guess we probably think it does *not* warrant a 1.7.2, right?
[20:47] <KevinVdV> Just give a me a second & I will have a patch :)
[20:47] <mhwood> It sounds like the only problem is ugly stuff in the logs.
[20:47] <mdiggory> DS-875 does not cause a problem unless you are loading dspace modules cfg's out of the addon jars
[20:47] <stuartlewis> Nope - ugly stuff whenever you run [dspace]/bin/dspace foobar
[20:47] <tdonohue> it seems like it'd be fine to schedule for 1.8.0?
[20:48] <tdonohue> oh really?
[20:48] <tdonohue> (stuartlewis, are you saying we need a 1.7.2 then?)
[20:48] <mdiggory> tdonohue: I think that is fine, I would attach it to 1.7.x though I doubt we will be doing a 17.2 release
[20:48] * kshepherd predicts many dspace-tech emails
[20:48] <mdiggory> it would be good to get in there if there was a chance that it did happen
[20:48] <stuartlewis> Dunno - that was why I raised it. I wonder if we do? However, not seen many reports about it yet on dspace-tech, so maybe wait and see for a while?
[20:49] <mdiggory> the correction is to remove "$CLASSPATH:" from the bin/dspace script
[20:50] <tdonohue> OK, I suggest we tentatively schedule for 1.8.0 then. Push forward to a 1.7.2 only if we end up with a stream of complaints, etc.
[20:50] <KevinVdV> Attached a patch to the JIRA
[20:50] <mhwood> KevinVdV: thanks!
[20:51] <KevinVdV> Well about the complaints is just a display bug, it has no effect on the execution
[20:51] <mhwood> Yes, I don't think this alone warrants a point release. It's easy enough to just edit the wrapper if you have problems.
[20:51] <PeterDietz> patch is fine for now, you're always free to patch (or cherry-pick) your system. A release should have something more I think
[20:51] <tdonohue> DS-875 summary: KevinVdV posted a patch. Needs broader review. Schedule to fix tentatively for 1.8.0, but may require a 1.7.2 if we find many are significantly inconvenienced
[20:51] <mdiggory> More robust classloading would utilize the following
[20:51] <mdiggory> http://classworlds.codehaus.org/launchusage.html
[20:52] <stuartlewis> Yes for scripts that provide output, but for some (e.g. itemcounter) with no output, all we saw was a stacktrace, and assumed that it hadn't worked.
[20:52] <mdiggory> do we have anything else warranting a 1.7.2 release yet?
[20:53] <tdonohue> not as far as I know...this is the first thing that has come up
[20:53] <stuartlewis> KevinVdV: Thanks for the patch. Do we also need to patch dspace.bat in the same way?
[20:53] <PeterDietz> caching is annoying in 1.7.x (I've changed us to noncaching)
[20:54] <KevinVdV> T.b.h. haven't tested dspace.bat
[20:54] <KevinVdV> Can do that tomorrow don't have a windows pc operational at the moment
[20:54] <tdonohue> PeterDietz -- did you post a patch for that XMLUI caching / non-caching to JIRA? (If so, i must have missed it)
[20:54] <aschweer> https://jira.duraspace.org/browse/DS-866 is annoying for 'my' repositories
[20:54] <mdiggory> I'm running out of time today.
[20:55] <richardrodgers> quick GSOC update before we close?
[20:55] <PeterDietz> https://jira.duraspace.org/browse/DS-871 XMLUI caches community / collection page which doesn't show a recently submitted item immediately
[20:55] <mdiggory> we need to be careful, cannot comment about students in the public channel
[20:56] <stuartlewis> GSoC sounds like a great story - it had us all passionately involved, and ended happily ever after with the outcomes we wanted :)
[20:56] <tdonohue> sure. GSoC Update. We got that extra slot we wanted. So, we'll have 4 projects (cannot comment on them specifically right now, as they will only be public on Monday)
[20:56] <richardrodgers> agreed, just want to know where we are in the process
[20:56] <mdiggory> DS-871 I think we may take this one
[20:57] * stuartlewis gotta run - off to a meeting to discuss DSpace & Vivo + other fun stuff. Thanks, bye.
[20:57] <PeterDietz> mdiggory: I'm working on defaulting all to non-caching, then building browseArtifacts and browseArtifactsCached (ditto for viewArtifacts, searchArtifacts), where one does many things using the default non-caching, and the cached is for heavier things that can be cached
[20:57] <mdiggory> there are some general caching improvements that need to happen to the XMLUI including Larrys recent additions to the stiemap and general cocoon validity analysis
[20:57] <tdonohue> Feel free to claim DS-871 then, mdiggory. Unless PeterDietz wants to claim it and post his "fix" of switching to non-caching
[20:59] <tdonohue> Ok. Any other questions / comments on GSoC? As I mentioned via email, DuraSpace is open to feedback around the GSoC project selection process this year.
[20:59] <PeterDietz> I don't know how to have two pipelines in the same sitemap pipelines - (pipeline type-"caching" ....), (pipeline type="noncaching" .....) /pipelines, so that it accumulates both, so I'm splitting off to multiple aspects for each aspect, a cached and non-cached. mostly just barely working prototype thus far
[21:00] <tdonohue> This was the first time DuraSpace (as a whole, with all three technologies involved) took a lead on that, so I'm sure there's more we can "smooth out" in the future.
[21:00] <mdiggory> PeterDietz: all good ideas, need to run, lets convers in the task
[21:00] <PeterDietz> ok, later
[21:00] <richardrodgers> gotta run, bye all
[21:01] * richardrodgers (~richardro@18.111.27.200) Quit (Quit: richardrodgers)
[21:01] <mhwood> I must go too. Thanks all!
[21:01] <tdonohue> Ok. sounds like folks need to head out...discussion is waning :) We'll close the meeting then
[21:01] <tdonohue> Have a good rest of the week all!
[21:01] * mhwood (~mhwood@2001:18e8:3:171:218:8bff:fe2a:56a4) has left #duraspace
[21:08] * KevinVdV (~KevinVdV@d54C15567.access.telenet.be) Quit (Quit: KevinVdV)
[21:12] * aschweer (~schweer@schweer.its.waikato.ac.nz) Quit (Quit: heading to work)
[21:14] * grahamtriggs1 (~Graham@cpc2-stev6-2-0-cust333.9-2.cable.virginmedia.com) has left #duraspace
[21:14] * grahamtriggs_ (~Graham@cpc2-stev6-2-0-cust333.9-2.cable.virginmedia.com) Quit (Quit: Leaving)
[22:01] * tdonohue (~tdonohue@c-98-228-50-45.hsd1.il.comcast.net) Quit (Read error: Connection reset by peer)
[22:49] * mdiggory (~mdiggory@rrcs-74-87-47-114.west.biz.rr.com) Quit (Quit: mdiggory)
[23:58] * bradmc (~bradmc@207-172-69-79.c3-0.smr-ubr3.sbo-smr.ma.static.cable.rcn.com) has joined #duraspace
These logs were automatically created by DuraLogBot on irc.freenode.net using the Java IRC LogBot.