Timestamps are in GMT/BST.
[0:52] * peterdietz (uid52203@gateway/web/irccloud.com/x-anexgmebjzedspqs) Quit (Quit: Connection closed for inactivity)
[7:15] -wolfe.freenode.net- *** Looking up your hostname...
[7:15] -wolfe.freenode.net- *** Checking Ident
[7:15] -wolfe.freenode.net- *** Found your hostname
[7:15] -wolfe.freenode.net- *** No Ident response
[7:15] * DuraLogBot (~PircBot@webster.duraspace.org) has joined #duraspace
[7:15] * Topic is '[Welcome to DuraSpace - This channel is logged - http://irclogs.duraspace.org/]'
[7:15] * Set by cwilper!ad579d86@gateway/web/freenode/ip.173.87.157.134 on Fri Oct 22 01:19:41 UTC 2010
[7:48] * pbecker (~pbecker@ubwstmapc098.ub.tu-berlin.de) has joined #duraspace
[13:06] * pbecker (~pbecker@ubwstmapc098.ub.tu-berlin.de) Quit (Quit: Leaving)
[13:20] * tdonohue (~tdonohue@c-98-226-113-104.hsd1.il.comcast.net) has joined #duraspace
[14:45] * KevinVdV (~kevin@85.234.195.109.static.edpnet.net) has joined #duraspace
[14:57] <tdonohue> Hi all, our DSpace Developers Mtg will start here shortly. Hi all, our DSpace Developers meeting starts shortly in #duraspace. https://wiki.duraspace.org/display/DSPACE/DevMtg+2016-03-09
[14:57] <kompewter> [ DevMtg 2016-03-09 - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/DevMtg+2016-03-09
[14:58] <tdonohue> whoops, copy & paste error in that last msg. You get the point though ;)
[15:00] <tdonohue> Ok, looks like we are at the top of the hour here. Our attendee list is really small today though. So, hopefully we'll end up with some others shortly.
[15:01] <tdonohue> Pinging Committers who are currently here... helix84, KevinVdV, terry-b
[15:01] <KevinVdV> Hello hello
[15:02] <tdonohue> So, at least two of us are actually here. :) Hi, KevinVdV
[15:02] <KevinVdV> Hi tdonohue
[15:03] <tdonohue> Well, the main topic for today was to try and go over 6.0 schedules and see what we can do to drive 6.0 forward (more quickly). It's gonna be hard to do that with just two of us, but I guess we could brainstorm
[15:04] <tdonohue> I also did want to note to everyone (reading this or here) that I'll be out much of next week to attend the DuraSpace Summit Mtg (on 16-17 in Washington DC). So, I'll miss this meeting next week, unfortunately.
[15:04] * roelandatmire (~roeland@85.234.195.109.static.edpnet.net) has joined #duraspace
[15:05] * hpottinger (~hpottinge@mu-161168.dhcp.missouri.edu) has joined #duraspace
[15:05] <tdonohue> Here's a few others joining up. Welcome hpottinger and roelandatmire. Until now it seems to have just been KevinVdV & I here today
[15:07] <tdonohue> So, as I was saying, we need to get a handle on 6.0. I feel like this is starting to turn into a release that has "no deadline" and could go on forever. While we are making strides (and thanks all for that), we still have a very large number of outstanding blockers, improvements, code tasks, and one feature PR
[15:07] <KevinVdV> @tdonohue: Shall we go over the list of blockers ? See if we can get some out of the way ?
[15:08] <tdonohue> KevinVdV. Sure, it seems like a good place to begin, just cause we really cannot even do an RC1 without clearing them out
[15:09] <tdonohue> So, here's that list of blockers: https://jira.duraspace.org/issues/?jql=project%20%3D%20DS%20AND%20status%20in%20(Received%2C%20%22More%20Details%20Needed%22%2C%20%22Volunteer%20Needed%22%2C%20%22Code%20Review%20Needed%22%2C%20Accepted)%20AND%20priority%20%3D%20Blocker
[15:09] <kompewter> [ Issue Navigator - DuraSpace JIRA ] - https://jira.duraspace.org/issues/?jql=project%20%3D%20DS%20AND%20status%20in%20(Received%2C%20%22More%20Details%20Needed%22%2C%20%22Volunteer%20Needed%22%2C%20%22Code%20Review%20Needed%22%2C%20Accepted)%20AND%20priority%20%3D%20Blocker
[15:09] <tdonohue> (Note, I'm skipping the first one that is only visible to Committers, just cause that's already actively in process on Committers list)
[15:09] <tdonohue> DS-3086
[15:09] <kompewter> [ https://jira.duraspace.org/browse/DS-3086 ] - [DS-3086] OAI Harvester is broken (NPEs around several classes) - DuraSpace JIRA
[15:10] <tdonohue> DSPR#1326 (looks to need a rebase)
[15:10] <kompewter> [ https://github.com/DSpace/DSpace/pull/1326 ] - DS-3086 OAI Harvester is broken (NPEs around several classes) by DylanMeeus
[15:10] <KevinVdV> I know this one to be still in progress (marked it as such)
[15:10] <KevinVdV> We fixed the nullpointers but are still unable to complete a full harvest.
[15:11] <KevinVdV> But I think this one shouldn’t hold us back from a RC-1, we just need to fix it prior to RC-2 ?
[15:11] <tdonohue> Ok. It might be worth trying a rebase here to see if some of those issues were being caused by some of the configuration issues (recently fixed on master)
[15:11] <tdonohue> correct, we probably could bypass this one for an RC1
[15:12] <hpottinger> should we change it from a blocker?
[15:12] <tdonohue> moving along for now, DS-3062 / DSPR#1313
[15:12] <kompewter> [ https://jira.duraspace.org/browse/DS-3062 ] - [DS-3062] Configurable (XML)Workflow cannot be enabled - DuraSpace JIRA
[15:12] <KevinVdV> Not sure, we don’t want to relase a DSpace without a fix for this one
[15:12] <kompewter> [ https://github.com/DSpace/DSpace/pull/1313 ] - [DS-3062] Fixing issues that prevented the xmlworkflow from being enabled by KevinVdV
[15:13] <tdonohue> hpottinger: I'd rather keep it as a "blocker" cause it *is* a blocker for the final 6.0. But, we can make (small) exceptions to 6.0RC1, and this seems like one
[15:13] <hpottinger> fine by me
[15:13] <tdonohue> 1313 looks correct to me (via code review). I've been too swamped to test it out, but it looks right
[15:13] <roelandatmire> can’t we capture that in the milestone field?
[15:14] <tdonohue> Has 1313 been tested on @mire's side?
[15:14] <KevinVdV> I tested it during my midday breaks
[15:15] <tdonohue> roelandatmire: yes, we could use the 'milestone' field in GitHub to specify 6.0RC1 vs 6.0RC2, etc. I haven't had a chance to do that yet, but I'd welcome it
[15:16] <tdonohue> 1313 to me looks like one that we merge soon/quickly. This obviously doesn't work now. The code looks like it should work. I'm not likely to get a chance to test it until *after* the DuraSpace Summit (late next week at the earliest). But, I don't think this needs to hang around if it works better than master
[15:16] <KevinVdV> It will work better then master & although I’m biased I would incline towards just merging it.
[15:17] <tdonohue> So, if there are no objections, I'm inclined to just merge it too
[15:17] <KevinVdV> If issues show up with the RC we can handle it then
[15:17] <tdonohue> exactly
[15:17] <hpottinger> I agree, do you need votes on the PR to move it?
[15:17] <tdonohue> hpottinger: yes, if you can add a +1 that helps
[15:17] <tdonohue> Then, I'll merge it
[15:17] <hpottinger> done
[15:18] <tdonohue> merged
[15:18] <tdonohue> ok, next up, DS-3004
[15:18] <kompewter> [ https://jira.duraspace.org/browse/DS-3004 ] - [DS-3004] extremely slow searching when logged in as admin - DuraSpace JIRA
[15:18] <tdonohue> DSPR#1322
[15:19] <hpottinger> I wish I'd managed to test this
[15:19] <kompewter> [ https://github.com/DSpace/DSpace/pull/1322 ] - Feature/DS-3004 isAdmin performance problems by tomdesair
[15:19] <tdonohue> hpottinger: do you have time to test it today?
[15:19] <hpottinger> too many other things keep cropping up
[15:19] <hpottinger> honestly, I can't say
[15:20] <hpottinger> I'm kinda running on empty right now, been two nights in a row patching things during maintenance windows
[15:21] <tdonohue> The concept behind this PR / change sounds reasonable to me (though it's a shame to have to unwind some of the metadata4all stuff, but I don't see a way around it). I can likely give it a code review today
[15:21] <KevinVdV> Groups still support metadata 4 all, but it might have been a mistake to place the name in there as well.
[15:22] <tdonohue> right, I understand
[15:22] <KevinVdV> It needs to be unique (like eperson emails)
[15:22] <hpottinger> it soulds like a good compromise
[15:22] <roelandatmire> The main concept is that the ‘required fields’ are in the table itself
[15:22] <hpottinger> before I vote for it I want to test it, just looking at the code it looks right, and I like the extensive writeup on the ticket
[15:23] <hpottinger> translation: I *want* to vote for this PR
[15:24] <tdonohue> I'll also do a code review of this (today/tomorrow) and add a +1 once I've done so. This seems like one that again, we should try and get in. but, I agree it'd be nice to get a tester here
[15:24] <tdonohue> "try and get in *quickly*" (i meant)
[15:24] <tdonohue> So, let's move along for now...This is one to keep close track of and help move forward though
[15:25] <tdonohue> DS-2981 (has no PR or volunteer yet)
[15:25] <kompewter> [ https://jira.duraspace.org/browse/DS-2981 ] - [DS-2981] Create indexes for UUID fields for Oracle migration script - DuraSpace JIRA
[15:25] <tdonohue> Oh wait, has hpottinger as a volunteer (I forgot)
[15:25] <tdonohue> We need to get this one in place by RC1...otherwise Oracle is gonna be slow/broken to test
[15:26] <tdonohue> hpottinger: any update here? Or do we need to find help?
[15:27] <hpottinger> these are all related (I can't test 1322 until I get 2981 fixed
[15:28] <hpottinger> My inclination is: the same index SQL for PostgreSQL is likely to "just work" for Oracle
[15:29] <tdonohue> That'd be my inclination as well..there may only be minor syntax changes (not sure if the Oracle & Postgres index syntax is identical or not)
[15:29] <hpottinger> the only time I've run into problems with Oracle creating indexes if it already infers their existence from other commands
[15:29] <hpottinger> then it gripes becuase you're trying to create an index that already exists... but you can ignore those because, whatevs, index, right?
[15:30] <tdonohue> Ok, hpottinger. So, I guess we're just depending on you to get to this for now (if there are any other Oracle users out there though, I'm sure we could use more help/testers!). Hopefully you can find time this week in your busy schedule.
[15:30] <hpottinger> I'll try
[15:31] <tdonohue> (I completely understand having a busy schedule...but, yes, if you can find even an extra hour or two, it'd be a huge help to 6.0)
[15:31] <tdonohue> moving along for now.. DS-2940
[15:31] <kompewter> [ https://jira.duraspace.org/browse/DS-2940 ] - [DS-2940] Metadata problems with the VersionedHandleIdentifierProvider - DuraSpace JIRA
[15:32] <tdonohue> which seems to be waiting on discussion/PR from DS-1348 (according to pbecker)
[15:32] <kompewter> [ https://jira.duraspace.org/browse/DS-1348 ] - [DS-1348] Item level versioning breaks persistence and lacks meta information - DuraSpace JIRA
[15:32] <tdonohue> DSPR#881
[15:32] <kompewter> [ https://github.com/DSpace/DSpace/pull/881 ] - DS-1348: Removes "canonical" handle for versioned Items. by pnbecker
[15:33] <tdonohue> Looks like there are a few minor comments/issues noted by Ben Bosman in 1348 still
[15:33] <KevinVdV> One is a bug, the other is IF we want to change the default config.
[15:33] <tdonohue> and pbecker implies he's working on a fix to the bug piece
[15:34] <tdonohue> which config is this (I'm trying to catch up here)
[15:35] <KevinVdV> The config revolves around how new handles are created when creating a new version
[15:35] <hpottinger> I think pbecker and mhwood were talking about this yesterday?
[15:35] <tdonohue> hpottinger: they may have been...neither of them are here today though
[15:36] <tdonohue> In any case, it *sounds* like this is still a work in progress. I need to scan the code myself to get a better understanding of the default config setting
[15:37] <hpottinger> looking back at my logs I can't see anything specific about 881 or 1348
[15:37] <KevinVdV> But we don’t much mind if the default changes, we can always alter it, but we should be aware that the default will change
[15:37] * tomdesair (~tom@85.234.195.109.static.edpnet.net) has joined #duraspace
[15:37] <tdonohue> We'd need details on *changing* this configuration then. I don't see anything that is obviously a config in the PR...but I need to look at it closer
[15:38] <tdonohue> (i.e. the PR doesn't actually add any new configs to a *.cfg or a Spring XML...which is why I'm confused by this discussion a tad)
[15:39] <KevinVdV> This is because he moves the current config in another class & then alters the original
[15:39] <tdonohue> Ok. I think it'd be good if someone adds an inline comment to this. I agree that a configuration change like this needs to be pointed out to ensure we are all OK with it
[15:40] <tdonohue> But, for now, I suggest we move along
[15:40] <tdonohue> DS-2898
[15:40] <kompewter> [ https://jira.duraspace.org/browse/DS-2898 ] - [DS-2898] REST API Should Support all DSpace Authentication Methods - DuraSpace JIRA
[15:40] <tdonohue> DSPR#1226
[15:40] <kompewter> [ https://github.com/DSpace/DSpace/pull/1226 ] - [DS-2898] Add support for all authentication methods in the rest api by KevinVdV
[15:41] <tdonohue> Huh, the PR seems to be showing Unit Test failures (from REST API unit tests) in Travis CI
[15:42] <tdonohue> This is a PR though that I think (once the Unit Test failures are resolved) we should work to merge...we can always just document issues with Shibboleth..but we shouldn't hold up RC1 just for full-Shibboleth integration
[15:43] <tdonohue> terry-b said something similar to this in the PR comments itself (his last comment)
[15:43] <KevinVdV> Appears to be a Mirage 2 issu, perhaps I should run it again ?
[15:43] <tdonohue> So, if we can get the Unit Tests to work right again (not sure why they are failing now), I think this is one that we should just merge. We can then create a new ticket about any outstanding Shib problems
[15:44] <tdonohue> KevinVdV: feel free to restart Travis to see if that helps
[15:44] <KevinVdV> If only I knew how ....
[15:45] <tdonohue> Oh, I can do it. You just need to be *logged in* to Travis (using your GitHub login)...then there's a little "Restart Build" icon (looks like an arrow in a circle) in the upper right
[15:45] <tdonohue> I'll restart it now
[15:45] <KevinVdV> Great thx
[15:46] <tdonohue> Ok, in any case, it *sounds like* 1226 has general approval (from mhwood, terry-b, etc). So, I think this is ready to go..and we then open up a new ticket(s) around any outstanding issues (especially with Shib)
[15:47] <KevinVdV> Might indeed be best to start a clean discussion on that one
[15:47] <tdonohue> Moving along for now though (time is running short here): DS-2846
[15:47] <kompewter> [ https://jira.duraspace.org/browse/DS-2846 ] - [DS-2846] DSpace 6 performance issue running index-discovery -b - DuraSpace JIRA
[15:48] <tdonohue> this one *seems* to have been addressed already by DSPR#1276 (as noted by terry-b). It's unclear whether we need to make any other changes here
[15:48] <kompewter> [ https://github.com/DSpace/DSpace/pull/1276 ] - DS-2965 - Allow cache clear during re-index (V2) by terrywbrady
[15:48] <KevinVdV> We could close, I assume if we release RC-1 & people have issues a new ticket will be reopned
[15:50] <tdonohue> Yes, obviously if it pops back up, we'd reopen the ticket. Are there any other *clear* (definitive) advantages to the extra changes in DSPR#1131? It sounds like they are somewhat "speculative" still. If that's the case, I'd recommend just closing both the PR (1131) and ticket (2846) for now...as it seems solved. If we rediscover this, we could reopen either again later
[15:50] <kompewter> [ https://github.com/DSpace/DSpace/pull/1131 ] - [DS-2846] Optimize memory usage when using iterators by KevinVdV
[15:51] <tdonohue> I guess the question in my mind is whether we are *sure* this new HibernateScrollableResultsIterator is beneficial...or not
[15:51] <KevinVdV> Well I honestly don’t know if it is beneficial
[15:52] <tdonohue> Ok. In that case, I recommend we close the PR & the ticket as "fixed". If we re-encounter this, we can go back to PR 1131 and reopen it to see if it helps.
[15:52] <KevinVdV> Ok
[15:52] <tdonohue> But, as of right now, it seems like the major issues are already fixed, so I see no reason to merge 1131 until we are certain it is beneficial
[15:55] * tomdesair (~tom@85.234.195.109.static.edpnet.net) has left #duraspace
[15:55] <tdonohue> Ok, I just closed both
[15:56] <tdonohue> Next up, DS-2687
[15:56] <kompewter> [ https://jira.duraspace.org/browse/DS-2687 ] - [DS-2687] When deleting a collection role, the administrator group (id 1) was deleted - DuraSpace JIRA
[15:56] * hpottinger twitches
[15:57] <tdonohue> This was "fixed" to some extent by DS-3024. But, it's not a perfect fix. We also need to fix FlowContainerUtils logic (see the final comment on this ticket)
[15:57] <kompewter> [ https://jira.duraspace.org/browse/DS-3024 ] - [DS-3024] "Administrator" and "Anonymous" groups can be renamed, which would cause them to no longer function in 6.x - DuraSpace JIRA
[15:57] <tdonohue> hpottinger was assigned to this, but is there anyone else willing to chip in here? It seems like hpottinger has a lot on his plate right now?
[15:58] <hpottinger> it looks like I accidentally made a PR for this :-) and closed it instantly
[15:58] <hpottinger> I dimly remember that day
[15:59] <tdonohue> My last two comments on this ticket describe the problem in FlowContainUtils. It shouldn't actually be hard to fix...it's just improving the logic of when a Community/Collection group is actually deleted
[15:59] <KevinVdV> Has anybody been able to reproduce locally on latest master ?
[15:59] <KevinVdV> Because I dimly remember trying but not getting the same result
[15:59] <hpottinger> All I did for my repository is remove the delete logic entirely
[16:00] <tdonohue> KevinVdV: Yes...though current master blocks the ability to delete "Administrator" or "Anonymous" groups...you still may autodelete a custom group (e.g. "Students", "Faculty") because of the flaw in the FlowContainerUtils logic
[16:00] <hpottinger> KevinVdV: if you modify the policy to use a group of your own creating, that logic will delete it if you change the role
[16:01] <tdonohue> So, the problem has morphed slightly...but it still exists... you may accidentally delete an entire group (without meaning to)
[16:01] <hpottinger> perhaps we need to change the issue description?
[16:01] <tdonohue> hpottinger: yes, that might be good
[16:03] <hpottinger> I may have gone too wordy with this revision: DS-2687
[16:03] <kompewter> [ https://jira.duraspace.org/browse/DS-2687 ] - [DS-2687] When deleting a collection role the group is also deleted, which is not appropriate for non-system-created groups - DuraSpace JIRA
[16:03] <tdonohue> Ok, for the time being, I'm going to move along... I think 2687 still requires attention, but it shouldn't be hard to fix...and it likely could wait for RC2 instead
[16:03] <tdonohue> next up, DS-2490
[16:03] <kompewter> [ https://jira.duraspace.org/browse/DS-2490 ] - [DS-2490] Add DOI support to Item Level Versioning - DuraSpace JIRA
[16:04] <tdonohue> This is an "improvement" which is a blocker as it also fixes bugs in the existing DOI support on master. (Unfortunately it is a bug fix & an improvement in one)
[16:04] <tdonohue> DSPR#879
[16:05] <kompewter> [ https://github.com/DSpace/DSpace/pull/879 ] - DS-2490: adds org.dspace.identifier.VersionedDOIIdentifierProvider by pnbecker
[16:06] <tdonohue> So, I can likely give this a code review as well... I see that KevinVdV already did the same
[16:06] <KevinVdV> We don’t use DOI’s, so hard to test for me…..
[16:06] <tdonohue> If anyone is willing to give this a quick test, it'd be appreciated...but it seems reasonable at a glance
[16:07] <tdonohue> Since we're overtime, I'm going to move along for now to the final one... DS-2437 / DSPR#1331
[16:07] <kompewter> [ https://jira.duraspace.org/browse/DS-2437 ] - [DS-2437] Stop relying on alphabetical loading of jars in WEB-INF/lib - DuraSpace JIRA
[16:07] <kompewter> [ https://github.com/DSpace/DSpace/pull/1331 ] - DS-2437: Ensure all webapps unpack "additions" into their WEB-INF/classes by tdonohue
[16:07] <tdonohue> I generated a PR for this which seems to work. mhwood gave it a test (and I have as well).
[16:08] <hpottinger> is that "good enough"?
[16:08] <roelandatmire> If you use the unpack goal
[16:08] <roelandatmire> you actually create a ‘virtual’ dependency
[16:08] <tdonohue> roelandatmire: not sure I understand you point?
[16:08] <roelandatmire> wich can lead to very hard to diagnose errors
[16:09] <tdonohue> roelandatmire: do you have an alternative suggestion that still obeys the Servlet Specification? Currently we are completely disobeying it by depending on this alphabetical loading of JARs
[16:10] <roelandatmire> just using a different goal of the maven dependency plugin to unpack the dependency
[16:10] <KevinVdV> <= Needs to run, until next time
[16:10] * KevinVdV (~kevin@85.234.195.109.static.edpnet.net) Quit (Quit: KevinVdV)
[16:10] <hpottinger> is the objection with the entire idea of the additions module, or just the phase we're using?
[16:11] <tdonohue> roelandatmire: what different goal? The goal is called "unpack" if you want to unpack an existing JAR
[16:11] <tdonohue> I'm not sure I understand your recommendation, roelandatmire
[16:11] <tdonohue> The name of the actual goal is "dependency:unpack" https://maven.apache.org/plugins/maven-dependency-plugin/unpack-mojo.html
[16:11] <kompewter> [ Apache Maven Dependency Plugin – dependency:unpack ] - https://maven.apache.org/plugins/maven-dependency-plugin/unpack-mojo.html
[16:12] <roelandatmire> I believe this is more approapriate
[16:12] <roelandatmire> https://maven.apache.org/plugins/maven-dependency-plugin/unpack-dependencies-mojo.html
[16:12] <kompewter> [ Apache Maven Dependency Plugin – dependency:unpack-dependencies ] - https://maven.apache.org/plugins/maven-dependency-plugin/unpack-dependencies-mojo.html
[16:12] <roelandatmire> unpack adds a dependency to your project and unpacks it
[16:13] <roelandatmire> unpack-dependencies unpacks a dependency that is already in the <dependency> block of your project
[16:14] <tdonohue> roelandatmire: but, we don't want "additions" to appear in the <dependency> block, or else it'll end up in the WEB-INF/lib/ (which would cause conflicts)
[16:14] <tdonohue> I guess we could exclude it out of the WEB-INF/lib/ using maven-war-plugin
[16:15] <roelandatmire> but you want to be able to compile against additions
[16:15] <tdonohue> honestly, an alternative PR here is welcome. I'll admit, as I've got to concentrate on the upcoming DuraSpace Summit (next week), I feel it's doubtful that I'll have much time to work on changing this PR until I return from the Summit
[16:16] <roelandatmire> Ok I’ll fire a pull request
[16:16] <tdonohue> But, roelandatmire, if you have time to spare, I think a new PR would be great. thanks!
[16:16] <tdonohue> your logic is making sense to me, roelandatmire...so as long as we can get it all working that way, it seems like a better direction
[16:17] <tdonohue> Ok. as we are now 15 minutes over time, I don't know that there's much else we can discuss today.
[16:18] * peterdietz (uid52203@gateway/web/irccloud.com/x-qvwulktngfivdliz) has joined #duraspace
[16:18] <tdonohue> Unfortunately, we didn't get to finalizing the 6.0 schedule. I'd *REALLY* like to get an RC1 ready by Thurs, March 24 if possible. But, that said, I'd need all of your help, as I will NOT be around next week
[16:18] <tdonohue> So, you all will be on your own for next week's meeting...but I'd encourage you to keep pushing hard on 6.0, with the goal of getting to an RC1 as soon as possible
[16:19] <tdonohue> With that, I'm going to close up today's meeting. I'll try and send a message to dspace-commit to this same effect. We need to get 6.0 out the door, and we need help getting these final PRs ready/tested.
[17:08] * dyelar (~dyelar@31.158.45.66.cm.sunflower.com) has joined #duraspace
[17:29] * misilot (~misilot@p-body.lib.fit.edu) Quit (Read error: Connection reset by peer)
[17:31] * misilot (~misilot@p-body.lib.fit.edu) has joined #duraspace
[19:29] * terry-b (~chrome@141.161.13.138) Quit (Ping timeout: 250 seconds)
[20:54] * kshepherd (~kim@lbdigs29.lbr.auckland.ac.nz) has joined #duraspace
[22:52] * tdonohue (~tdonohue@c-98-226-113-104.hsd1.il.comcast.net) has left #duraspace
[23:00] * kshepherd (~kim@lbdigs29.lbr.auckland.ac.nz) Quit (Ping timeout: 252 seconds)
[23:18] * kshepherd (~kim@lbdigs29.lbr.auckland.ac.nz) has joined #duraspace
[23:46] * hpottinger (~hpottinge@mu-161168.dhcp.missouri.edu) Quit (Quit: Leaving, later taterz!)
These logs were automatically created by DuraLogBot on irc.freenode.net using the Java IRC LogBot.