Timestamps are in GMT/BST.
[1:42] * peterdietz (uid52203@gateway/web/irccloud.com/x-tomapjvorkudpzzm) Quit (Quit: Connection closed for inactivity)
[7:02] -sendak.freenode.net- *** Looking up your hostname...
[7:02] -sendak.freenode.net- *** Checking Ident
[7:02] -sendak.freenode.net- *** Found your hostname
[7:02] -sendak.freenode.net- *** No Ident response
[7:03] * DuraLogBot (~PircBot@webster.duraspace.org) has joined #duraspace
[7:03] * Topic is '[Welcome to DuraSpace - This channel is logged - http://irclogs.duraspace.org/]'
[7:03] * Set by cwilper!ad579d86@gateway/web/freenode/ip.173.87.157.134 on Fri Oct 22 01:19:41 UTC 2010
[10:49] * pbecker (~pbecker@ubwstmapc098.ub.tu-berlin.de) has joined #duraspace
[13:18] * mhwood (mwood@mhw.ulib.iupui.edu) has joined #duraspace
[13:59] * tdonohue (~tdonohue@c-98-226-113-104.hsd1.il.comcast.net) has joined #duraspace
[14:34] * filatko (~filatko@dijkstra.ms.mff.cuni.cz) has joined #duraspace
[14:52] * KevinVdV (~kevin@85.234.195.109.static.edpnet.net) has joined #duraspace
[14:55] * KevinVdV_ (~kevin@195.176.9.225) has joined #duraspace
[14:58] * KevinVdV (~kevin@85.234.195.109.static.edpnet.net) Quit (Ping timeout: 250 seconds)
[14:58] * KevinVdV_ is now known as KevinVdV
[15:01] <tdonohue> Hello all. Welcome to our weekly DSpace Developers meeting. https://wiki.duraspace.org/display/DSPACE/DevMtg+2016-01-27
[15:01] <kompewter> [ DevMtg 2016-01-27 - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/DevMtg+2016-01-27
[15:02] <tdonohue> If you haven't seen the "news" this morning, http://duraspace.org/node/2775
[15:02] <kompewter> [ LYRASIS and DuraSpace Boards Approve “Intent to Merge” and Seek Your Input | DuraSpace ] - http://duraspace.org/node/2775
[15:03] <tdonohue> I'm not going to spend much time on this in today's meeting (as we really want to get 6.0 ready to go), but I'm glad to answer questions publicly or privately (tdonohue@duraspace.org).
[15:03] <tdonohue> I will say however, that I don't think this will change things for DSpace much. As far as I can tell, things should move along as normal, and if anything, we might get a few more resources to help us beef up DSpace training or promotion (both things Lyrasis is good at)
[15:04] <tdonohue> I don't think I'll say much more than that for now, but if we have time at the end of the meeting (or post-meeting), I'm glad to answer more questions, etc. I do think this merger could be of benefit though to DSpace and DuraSpace as a whole
[15:05] * hpottinger (~hpottinge@mu-162038.dhcp.missouri.edu) has joined #duraspace
[15:05] <tdonohue> One last note... as noted in the press release, we are looking for your institution's feedback. So, please do send along any feedback on the possible merger to synergy@duraspace.org
[15:06] <tdonohue> Ok. Now, on to 6.0 topics, which is what we are really here to discuss :)
[15:06] <tdonohue> Here's where we stand with our Feature PRs: https://github.com/DSpace/DSpace/pulls?q=is%3Aopen+is%3Apr+milestone%3A6.0
[15:07] <kompewter> [ Pull Requests · DSpace/DSpace · GitHub ] - https://github.com/DSpace/DSpace/pulls?q=is%3Aopen+is%3Apr+milestone%3A6.0
[15:07] <tdonohue> ack, wrong link
[15:07] <tdonohue> Here's the *feature* PR link: https://github.com/DSpace/DSpace/pulls?q=is%3Aopen+is%3Apr+milestone%3A6.0+label%3Afeature
[15:07] <kompewter> [ Pull Requests · DSpace/DSpace · GitHub ] - https://github.com/DSpace/DSpace/pulls?q=is%3Aopen+is%3Apr+milestone%3A6.0+label%3Afeature
[15:08] <tdonohue> We're down to just 5 left...which is good, but I'd rather we cull this down to 0 quickly :)
[15:08] <hpottinger> Let's do it!
[15:09] <helix84> um, those are only new features, what about improvements? https://github.com/DSpace/DSpace/pulls?utf8=%E2%9C%93&q=is%3Aopen+is%3Apr+milestone%3A6.0+label%3Aimprovement
[15:09] <kompewter> [ Pull Requests · DSpace/DSpace · GitHub ] - https://github.com/DSpace/DSpace/pulls?utf8=%E2%9C%93&q=is%3Aopen+is%3Apr+milestone%3A6.0+label%3Aimprovement
[15:09] <tdonohue> So, let's start with a "quick status" update. I think *I* know where everything currently stands, but let's make sure everyone is updated, and get volunteers where we need them
[15:09] <tdonohue> helix84: improvements will come next. We really need to get (closer) to a "Feature Freeze"
[15:09] <helix84> ok, thanks
[15:10] <tdonohue> Status on DSPR#1163?
[15:10] <kompewter> [ https://github.com/DSpace/DSpace/pull/1163 ] - DS-2880: Pubmed integration into XMLUI submission by rradillen
[15:10] <mhwood> +2 but there is a note about merging 1160 first, which may cause collisions.
[15:10] <tdonohue> This looks nearly 'ready to go'. It's at +2
[15:11] <tdonohue> Yes. So this is dependent on 1160: DSPR#1160
[15:11] <kompewter> [ https://github.com/DSpace/DSpace/pull/1160 ] - DS-2876 Framework for importing external metadata by jonas-atmire
[15:11] <hpottinger> sounds like we need to merge 1160 and 1163
[15:11] <mhwood> 1160 is, effectively, tested since 1163 is tested.
[15:11] <mhwood> And 1163 includes 1160.
[15:12] <KevinVdV> Indeed we recommend merging 1160 prior to 1163
[15:12] <hpottinger> then 1162 needs a final rebase and test
[15:12] <helix84> merging 1163 will mean that 1160 doesn't need to be merged (as it's commits are in 1163)
[15:12] <tdonohue> Thanks KevinVdV. Just as a warning to your staff... I notice the commit hashes in 1160 are *different* from those in 1163. Hopefully github will be smart about that, but merging 1160 may require a final rebase of 1163
[15:13] <helix84> merging 1160 would mean 1163 needs a rebase, but it shouldn't have any conflicts
[15:13] <tdonohue> true
[15:13] <hpottinger> (and 1162)
[15:13] <KevinVdV> I believe git(hub) compares files not commits
[15:13] <KevinVdV> So it shouldn’t be an issue
[15:13] <tdonohue> Sounds good then (I wasn't sure)
[15:14] <tdonohue> So, it sounds like we are in agreement? Merge 1160 today, and (if necessary) do a quick rebase of 1163 and merge it as well?
[15:14] <tdonohue> I'm +1 this approach (others?)
[15:14] <mhwood> Shall I just merge 1160 and see what happens?
[15:15] <tdonohue> mhwood: sure, go for it. It sounds like no one has objections. That'd let us know where we stand immediately
[15:16] <mhwood> Merged
[15:16] <helix84> just tested it, rebasing 1160 on 1163 is a NOOP
[15:16] <mhwood> 1163 now has conflicts.
[15:16] <hpottinger> I think git compares hashes first, then falls back to diffing if it has to
[15:16] <helix84> and vice versa it's without conflicts (but probably doesn't make sense)
[15:17] <helix84> yes, can't be merged, but should rebase without any conflicts
[15:17] <tdonohue> ok, so 1163 will need a rebase then. After that, it's ready to go
[15:17] <helix84> as the hashes differ, but the contents is the same
[15:17] <tdonohue> mhwood or KevinVdV, can one of you ping developers on 1163 for a quick rebase today?
[15:17] <KevinVdV> I will take care of it
[15:18] <tdonohue> thanks KevinVdV!
[15:18] <hpottinger> I will rebase 1162 and test using my own API key
[15:18] <tdonohue> Ok, so that covers 1163. Moving on to DSPR#1162 (which hpottinger just mentioned)
[15:18] <kompewter> [ https://github.com/DSpace/DSpace/pull/1162 ] - DS-2877 Import of ScienceDirect metadata including embargo and linking to or embedding of the final version by LetitiaMukherjee
[15:18] <helix84> I'll test it again now that the issues I found seem to be taken care of
[15:18] <tdonohue> Thanks hpottinger & helix84 for volunteering. Can you do testing of it today (or tomorrow)?
[15:19] <hpottinger> yes, today
[15:19] <mhwood> 1162 is also conflicted
[15:19] <helix84> yes
[15:19] <KevinVdV> I’ll see what I can do about it
[15:19] <hpottinger> thanks, KevinVdV!
[15:20] <tdonohue> Thanks KevinVdV again. Thanks hpottinger & helix84 for volunteering to test this. The code changes I requested for 1162 have been made, so it's looking ready once it is tested
[15:20] <KevinVdV> Put things in motion, rebase should happen sometime today
[15:20] <tdonohue> thanks
[15:20] <KevinVdV> 1163 rebased
[15:20] <tdonohue> Ok, so next up is DSPR#1104
[15:20] <KevinVdV> So pubmed is ready
[15:21] <kompewter> [ https://github.com/DSpace/DSpace/pull/1104 ] - DS-2654: Enhanced Configurations via Apache Commons Configuration by tdonohue
[15:21] <tdonohue> Latest status on 1104 is essentially, it's approved & ready to go, but I was holding off on breaking these other "feature" PRs. I think this should go in immediately *after* the remaining feature PRs (but BEFORE improvements/bug fixes)
[15:21] <mhwood> Not conflicted. Let's get it in.
[15:22] <tdonohue> 1104 is *highly likely* to cause conflicts with 1163 and 1162 (at least from my scanning the code). So, we may want to wait until those are both merged, and I'll do a final rebase & merge 1104
[15:22] <mhwood> 1163 is merged.
[15:23] <tdonohue> oh, ok. Well, then I guess it didn't cause conflicts there. 1162 adds new configs though, which may cause issues
[15:23] <hpottinger> OK, so, helix84 and I test 1162 and then ping tdonohue? either way one minght need a rebase, so... spin a bottle, who gets to rebase again?
[15:24] <tdonohue> If 1162 can be tested & verified ASAP, I'll wait on 1104, and do the rebase (as I know where the likely conflicts are).
[15:25] <filatko> fyi 2659 also adds a new config file
[15:25] <tdonohue> filatko: yep, I was just getting to that one. DSPR#994 is the last of the feature PRs... it also might have small conflicts with 1104
[15:25] <kompewter> [ https://github.com/DSpace/DSpace/pull/994 ] - DS-2659 new extensible platform health check reports with emailing by vidiecan
[15:27] <tdonohue> Anyone willing to give 994 a test run today as well?
[15:27] <mhwood> This one is +2 modulo some final tweaks
[15:28] * KevinVdV (~kevin@195.176.9.225) Quit (Ping timeout: 256 seconds)
[15:28] <tdonohue> yep. I notice it has votes...just might need some final tests to verify the recent commits are all working (they should be, but verification is a good thing)
[15:28] <filatko> fixed those reported by KevinVdV awhile ago
[15:29] <tdonohue> filatko: are you kosarko then? (sorry, didn't realize)
[15:29] <filatko> yeah, sorry...forgot how to change a nick :)
[15:30] <tdonohue> no problem. Thanks for being responsive though & working with us on the code filatko :)
[15:31] * KevinVdV (~kevin@85.234.195.109.static.edpnet.net) has joined #duraspace
[15:31] <tdonohue> As a reminder to folks, this PR 994 is essentially an improved, Java based replacement for our old "dspace-info.pl" script (which would be nice to finally get rid of!)
[15:31] <tdonohue> So, anyone here interested in helping us get 994 merged ASAP? Just needs a final test it seems
[15:33] <hpottinger> I'll give 994 a spin
[15:33] <helix84> I can test it again if that's all that's needed
[15:33] <helix84> already has +1 from me
[15:33] <tdonohue> filatko: One other comment.. at some point, we will need some basic Documentation on 994 (how to use it, configure it, etc). We don't necessarily need it prior to merging the code, but we need it for the official docs
[15:33] * dyelar (~dyelar@31.158.45.66.cm.sunflower.com) has joined #duraspace
[15:33] <tdonohue> Thanks hpottinger & helix84. I think it just deserves a last test...it has the votes, but I'm not certain it's been tested much since the code refactors
[15:34] <filatko> tdonohue: I think I've alredy started that docu somewhere
[15:34] <tdonohue> filatko: If so, great! If you can find them, please link them to the ticket in JIRA: DS-2659
[15:34] <kompewter> [ https://jira.duraspace.org/browse/DS-2659 ] - [DS-2659] Add configurable "healthcheck" system emailing internals of the repository on regular basis - DuraSpace JIRA
[15:34] <filatko> https://wiki.duraspace.org/display/DSPACE/Healthcheck+reports
[15:34] <kompewter> [ Healthcheck reports - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/Healthcheck+reports
[15:35] <filatko> it's in the PR at least
[15:35] <helix84> filatko: if you want edit access to official docs, just ask tdonohue and send him your Jira username
[15:35] <tdonohue> yep, I can give you edit access to official docs, if needed.
[15:36] <tdonohue> I added a link to those docs to the JIRA ticket too (as I overlooked them in the PR comments)
[15:37] <tdonohue> Ok. So, it sounds like the features are ALMOST ready. Ideally, we get 1162 and 994 tested quickly & merged. Then I'll do a final rebase of 1104 and merge immediately. After that, we're on to "improvements" and "bug fixes"
[15:37] <mhwood> Time to talk about improvements then?
[15:37] <tdonohue> Yep, improvements time: https://github.com/DSpace/DSpace/pulls?q=is%3Aopen+is%3Apr+milestone%3A6.0+label%3Aimprovement
[15:38] <kompewter> [ Pull Requests · DSpace/DSpace · GitHub ] - https://github.com/DSpace/DSpace/pulls?q=is%3Aopen+is%3Apr+milestone%3A6.0+label%3Aimprovement
[15:39] <tdonohue> There's a lot listed there, but I know that some of these have merge conflicts and would need more work to get ready to go. More may end up conflicted after 1104 gets in (and I plan to try and flag them all after 1104 is in)
[15:39] <tdonohue> Do we want to start again from the top (like last time)? Or start from bottom to switch up which we are talking about?
[15:40] <tdonohue> Actually, before we do that...are there any SPECIFIC ones folks here want to highlight to talk about?
[15:40] <tdonohue> (as this would be a good opportunity to get more eyes on specific important improvements)
[15:41] <helix84> tdonohue: yes, the RTL indexing for PDFs
[15:41] <tdonohue> which #?
[15:41] <helix84> DSPR#947
[15:42] <kompewter> [ https://github.com/DSpace/DSpace/pull/947 ] - DS-1187 Full-text indexing of right-to-left PDF files by saiful-semantic
[15:43] <tdonohue> This is a one-liner, and it looks like you found good performance? It seems like an obvious benefit/win to me
[15:43] <helix84> yep, just needs another +1 :)
[15:43] <tdonohue> I'd vote +1. If the performance is comparable, this is a backend process anyhow, so it seems like we just do it. I'll add my vote
[15:44] <helix84> thanks, I'll merge it shortly
[15:44] <tdonohue> merge it :)
[15:44] <mhwood> DSPR#1044 just had a positive report, and I'm going to have to ask around to get a second +1 as it's quite specialized.
[15:44] <kompewter> [ https://github.com/DSpace/DSpace/pull/1044 ] - [DS-1837] Create a separate Maven artifact for the MultiRemoteDSpaceRepositoryHandlePlugin by mwoodiupui
[15:46] * tdonohue needs to catch up on this discussion... is there a summary somewhere of why this should be a separate Maven project?
[15:47] <mhwood> DS-1637
[15:47] <kompewter> [ https://jira.duraspace.org/browse/DS-1637 ] - [DS-1637] Support running handle server and application container on separate machines - DuraSpace JIRA
[15:47] * peterdietz (uid52203@gateway/web/irccloud.com/x-qubocszdvejcuewb) has joined #duraspace
[15:47] <pbecker> tdonohue: we need to build a jar, that can be deployed to the handle server.
[15:48] <tdonohue> deployed to the server/system that is running the external handle server? (is that what you mean?...sorry there's two meanings of "server" here)
[15:49] <pbecker> yes, sorry.
[15:49] <mhwood> It's a plugin to the Handle resolver, so we need a way to deliver it there.
[15:49] <pbecker> the jar contains everything the handle server needs to contact dspace, to ask where to direct handles to. If the handle server runs on the same machine as DSpace, that is simple, if it runs on a remote one, you need this jar.
[15:50] <tdonohue> I understand now. So, my only comment on this PR is this... Is there a reason why we don't just pull this out into a separate GitHub project (which we release only as updates are needed)? I wonder if we are "cluttering" the main DSpace/DSpace with a ton of sub-projects
[15:51] <mhwood> Probably because I didn't think of doing that.
[15:51] <tdonohue> I.e. this seems like a very specific usage of the DSpace handle system...and I worry about making everyone build this new maven sub-project, when most don't need it? Can we just distribute it via Maven instead of within DSpace?
[15:51] <pbecker> the plugin in must correspondent with a servlet, but that is not a reason to have this in DSpace core. We probably could pull it out into a separate project.
[15:52] <helix84> Sorry, I didn't check, which handle server version does this work with? Is that documented?
[15:52] <tdonohue> I like the idea of distributing this as a separate GitHub project (and distribution via Maven dependencies), instead of within DSpace. Unless there's a good reason to keep it in the DSpace/DSpace GitHub, I'd prefer to see it separate
[15:52] <pbecker> helix84: IIRC we're using it with version 7.0
[15:53] <hpottinger> it's been a while since I tinkered with it, but I *am* running this plugin in production, I packaged it all up by hand, following peterdietz's docs
[15:54] <hpottinger> hsj-7.3.1 on our production box right now
[15:54] <mhwood> So hpottinger could test it too, if he has time. Cool.
[15:54] <pbecker> :-)
[15:54] <helix84> +1 to that :)
[15:54] <peterdietz> sorry, jumped in late. Hardy, your using the fat-jar HandleExternalAdapter thingy?
[15:54] <hpottinger> yup, peterdietz, I am
[15:54] <pbecker> peterdietz: do you use it in production?
[15:55] <tdonohue> Huh. Nice that this also fixes our issues with using Handle Server 7. That's actually something we should advertise it as doing (in the 6.0 release), as it's been an open issue: DS-1477
[15:55] <kompewter> [ https://jira.duraspace.org/browse/DS-1477 ] - [DS-1477] update the handle server (to get IPv6 support) - DuraSpace JIRA
[15:55] <peterdietz> Yeah, We have that in use for our client in Kuwait
[15:55] <pbecker> great!
[15:55] <peterdietz> I would like to harmonize the endpoints for JSPUI/XMLUI/REST
[15:55] <mhwood> I am scheming to remove the Handle resolver from DSpace in favor of running a stock one, someday.
[15:55] <pbecker> peterdietz: jspui and xmlui are harmonized.
[15:56] <hpottinger> after our upgrade to 5.4, our handle server situation "became dire" (I forgot to copy the configs over) easiest path out of that mess was to use the stock handle server
[15:56] <peterdietz> REST I don't think fully supports this. JSPUI and XMLUI have different endpoints... You can't just point to site.uni.edu/handle-resovler... You have to know if they use xmlui or jspui, because the endpoints are different
[15:56] <tdonohue> So, it seems like this DSPR#1044 could also be claimed as an early solution to DS-1477 and even DS-2153 (as it lets you run a "stock" handle server, right)?
[15:57] <pbecker> I thought you were thinking about giving back the same json structure.
[15:57] <kompewter> [ https://github.com/DSpace/DSpace/pull/1044 ] - [DS-1837] Create a separate Maven artifact for the MultiRemoteDSpaceRepositoryHandlePlugin by mwoodiupui
[15:57] <kompewter> [ https://jira.duraspace.org/browse/DS-1477 ] - [DS-1477] update the handle server (to get IPv6 support) - DuraSpace JIRA
[15:57] <kompewter> [ https://jira.duraspace.org/browse/DS-2153 ] - [DS-2153] Move to a more stock Handle service, implementing proper separation of concerns - DuraSpace JIRA
[15:57] <pbecker> tdonohue: yes and no. DS-2153 needs some more than that.
[15:57] <kompewter> [ https://jira.duraspace.org/browse/DS-2153 ] - [DS-2153] Move to a more stock Handle service, implementing proper separation of concerns - DuraSpace JIRA
[15:57] * tdonohue is trying to figure out which of these (many) tickets relating to updating the Handle Service could be somewhat "resolved" by this PR
[15:57] <peterdietz> I should get into the handle hosting business. Pascal, want that to be our first joint mission? But since handle registration is only $50/year, I don't think there is much money in it
[15:57] <tdonohue> pbecker: thanks for clarifying
[15:58] <pbecker> pr1044 solves ds1477
[15:58] * tdonohue is linking up ds1477 to ds1837 then
[15:58] <pbecker> peterdietz: working with you is reason enough to say: of course!
[15:59] <tdonohue> back to the PR here... mhwood: any objections to splitting this out into a separate GitHub project altogether? If not, I suggest we just do that. We can close the PR and just create a new Project for this
[16:00] <mhwood> No objection, and it decouples this from the 6.0 schedule.
[16:00] <mhwood> I.e. the new project can release anytime.
[16:00] <hpottinger> I'm not sure how we close those tickets if we make a new project?
[16:00] <pbecker> If we want to use this to resolve ds1477 it wouldn't decouple it...
[16:01] * tdonohue just wants to move to start to *simplify* our build process (not add more submodules). I hope to do more of that as we move to the new UI (in Dspace 7)
[16:01] <tdonohue> hpottinger: it's still a DSpace "feature" though...it'd just be distributed via *Maven* (or direct download of the JAR) instead of its source being packaged in the DSpace build & install
[16:02] <tdonohue> why not decouple it pbecker? I guess I don't see what the benefit of distributing it's source in DSpace brings us?
[16:02] <hpottinger> I remember bundling up a configuration into this jar, but maybe that's not necessary?
[16:03] <tdonohue> There's no config file in the PR itself
[16:04] <tdonohue> I guess my point here is that...if the goal is to "create a JAR that is divorced from the main API", why not just divorce it entirely from the DSpace source? Is there a purpose to keeping it in the DSpace source if it's supposed to be "separate"?
[16:04] <pbecker> tdonohue: it was related to mhwood, who noted that moving it to a separate project would decouples it from the 6.0 schedule.
[16:04] <KevinVdV> ==> needs to run, until next time
[16:04] * KevinVdV (~kevin@85.234.195.109.static.edpnet.net) Quit (Quit: KevinVdV)
[16:05] <tdonohue> If we move it into a separate project, I think we still need to keep it on the 6.0 schedule...that way we can advertise it as a "new feature" with 6.0 (even though it's distributed separate)
[16:05] <pbecker> hpottinger: the configuration file can be deployed in the configuration directory of the handle server.
[16:05] <pbecker> tdonohue: that was exactly what I meant to say.
[16:05] <pbecker> s/was/is
[16:05] <kompewter> pbecker meant to say: tdonohue: that is exactly what I meant to say.
[16:05] <tdonohue> So, it'd be "decoupled" in the source...but we still should aim to release it alongside (or prior to) 6.0
[16:05] <pbecker> ++1
[16:06] <mhwood> So I know what I'll be working on this afternoon, then. :-)
[16:06] <pbecker> mhwood: ping me if there is something I can help you with.
[16:06] <mhwood> Will do.
[16:06] <tdonohue> Thanks mhwood. Sorry I didn't catch this sooner. Let me know if you need anything from my end as well
[16:06] <mhwood> Will do.
[16:06] <hpottinger> likewise, ping me if you need a test... though I'm a bit worried about "testing in production" :-)
[16:07] <tdonohue> Ok. So, as we are now "over time", I suggest we close up today's meeting. If there are other improvements or bug fixes that require immediate attention, please do ping us via dspace-devel or IRC so we can work on getting them in as well
[16:08] <tdonohue> And, please let me know if any of you need anything with getting the Feature PRs merged ASAP. It'd be good to get that number to zero, so we can concentrate next week on improvements & bug fixes and stabilize for a "feature freeze"
[16:09] <tdonohue> Thanks all! We're getting closer to 6.0....just want to move this forward as rapidly as we can (and get back on a more "predictable" schedule)
[16:09] * tdonohue is moving over to #dspace now
[16:33] * filatko (~filatko@dijkstra.ms.mff.cuni.cz) Quit (Remote host closed the connection)
[16:46] * cknowles (uid98028@gateway/web/irccloud.com/x-emryqgmqzwzjvany) has joined #duraspace
[17:09] * dyelar (~dyelar@31.158.45.66.cm.sunflower.com) Quit (Quit: Leaving.)
[17:09] * dyelar (~dyelar@31.158.45.66.cm.sunflower.com) has joined #duraspace
[18:16] * pbecker (~pbecker@ubwstmapc098.ub.tu-berlin.de) Quit (Quit: Leaving)
[18:47] * awoods_away (~awoods@c-98-245-50-182.hsd1.co.comcast.net) Quit (Remote host closed the connection)
[19:51] * cknowles (uid98028@gateway/web/irccloud.com/x-emryqgmqzwzjvany) Quit (Quit: Connection closed for inactivity)
[21:06] * tdonohue is now known as tdonohue_away
[21:45] * mhwood (mwood@mhw.ulib.iupui.edu) has left #duraspace
[22:45] * hpottinger (~hpottinge@mu-162038.dhcp.missouri.edu) Quit (Quit: Leaving, later taterz!)
[23:52] * peterdietz (uid52203@gateway/web/irccloud.com/x-qubocszdvejcuewb) Quit (Quit: Connection closed for inactivity)
These logs were automatically created by DuraLogBot on irc.freenode.net using the Java IRC LogBot.