Timestamps are in GMT/BST.
[5:34] * cknowles (uid98028@gateway/web/irccloud.com/x-kykccszefenqhint) has joined #duraspace
[6:33] -orwell.freenode.net- *** Looking up your hostname...
[6:33] -orwell.freenode.net- *** Checking Ident
[6:33] -orwell.freenode.net- *** Found your hostname
[6:34] -orwell.freenode.net- *** No Ident response
[6:34] * DuraLogBot (~PircBot@webster.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
[7:43] * cknowles (uid98028@gateway/web/irccloud.com/x-kykccszefenqhint) Quit (Quit: Connection closed for inactivity)
[8:33] * peterdietz (uid52203@gateway/web/irccloud.com/x-gmqkizuhyeynvcln) Quit (Quit: Connection closed for inactivity)
[12:47] * tdonohue (~tdonohue@c-98-226-113-104.hsd1.il.comcast.net) has joined #duraspace
[13:11] * mhwood (mwood@mhw.ulib.iupui.edu) has joined #duraspace
[13:23] * pbecker (~pbecker@ubwstmapc098.ub.tu-berlin.de) has joined #duraspace
[13:51] * cknowles (uid98028@gateway/web/irccloud.com/x-yexiwmoilnfzwrzl) has joined #duraspace
[14:18] * peterdietz (uid52203@gateway/web/irccloud.com/x-yljbogesjzbkgfgq) has joined #duraspace
[14:21] * cwilper (185d1269@gateway/web/freenode/ip.24.93.18.105) has joined #duraspace
[14:31] * hpottinger (~hpottinge@128.206.252.168) has joined #duraspace
[14:40] * dyelar (~dyelar@31.158.45.66.cm.sunflower.com) has joined #duraspace
[15:00] <tdonohue> Hi all, welcome to our weekly DSpace DevMtg. Today's agenda is at: https://wiki.duraspace.org/display/DSPACE/DevMtg+2015-10-07
[15:00] <kompewter> [ DevMtg 2015-10-07 - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/DevMtg+2015-10-07
[15:00] <peterdietz> hi all
[15:00] * tdonohue realized in the last 15mins that I never sent this agenda to dspace-devel. So, apologies. Some of you may have stumbled on it if you went looking yesterday or this morning
[15:01] <tdonohue> In any case...our main topics for today are a possible 5.4, and looking towards 6.0
[15:02] <tdonohue> Regarding a 5.4 release: It's sounding more and more like we still have some bugs that need resolution in the 5.x codebase. Especially with the new addition of DS-2788 (and also DS-2679, which was already fixed)
[15:02] <kompewter> [ https://jira.duraspace.org/browse/DS-2788 ] - [DS-2788] Performance degradation of SOLR Discovery indexing in DSpace 5 - DuraSpace JIRA
[15:02] <kompewter> [ https://jira.duraspace.org/browse/DS-2679 ] - [DS-2679] Google Scholar ordering of metadata tags with multiple values (like authors) broken - DuraSpace JIRA
[15:03] <hpottinger> I like the idea of a 5.4 for those fixes
[15:03] <tdonohue> So, as noted in the agenda, we now have a "5.4" version in JIRA, and I've already flagged a few possible tickets for that release. If there are additional issues you feel should be fixed in a 5.4, please add them to that release for consideration
[15:04] <peterdietz> Are there any other outstanding issues with SOLR / browse?
[15:04] <tdonohue> There also is a 5.4 milestone in GitHub (which hasn't yet been fully "synced" with JIRA, but should be): https://github.com/DSpace/DSpace/pulls?q=is%3Aopen+is%3Apr+milestone%3A5.4
[15:04] <kompewter> [ Pull Requests · DSpace/DSpace · GitHub ] - https://github.com/DSpace/DSpace/pulls?q=is%3Aopen+is%3Apr+milestone%3A5.4
[15:05] <hpottinger> DS-2790
[15:05] <kompewter> [ https://jira.duraspace.org/browse/DS-2790 ] - [DS-2790] duplicate log4j configuration for Solr - DuraSpace JIRA
[15:05] <tdonohue> peterdietz: I think there was another *search* issue that aschweer stumbled on. I'm trying to find that ticket number (as it should also be added to 5.4)
[15:05] <hpottinger> DS-2699
[15:05] <kompewter> [ https://jira.duraspace.org/browse/DS-2699 ] - [DS-2699] Search not working as expected - DuraSpace JIRA
[15:06] <tdonohue> that's the one! thanks, hpottinger
[15:06] <hpottinger> DSPR#1045 and DSPR#1095
[15:06] <kompewter> [ https://github.com/DSpace/DSpace/pull/1045 ] - Ds 2699 improve search by aschweer
[15:06] <kompewter> [ https://github.com/DSpace/DSpace/pull/1095 ] - [DS-2790] removed duplicate log4j config lines for Solr by hardyoyo
[15:07] <tdonohue> In any case, if you notice other things that should be added to 5.4, feel free
[15:07] <peterdietz> I can't believe the number of JIRA's we've gone through is approaching 3000
[15:07] <tdonohue> There's no exactly timeline for 5.4 *yet*. Mainly, we need to get these major issues *fixed*. Then we need to find one or more individuals who are willing to help with the release (if you are willing, get in touch please!)
[15:09] <tdonohue> Any other thoughts/questions on 5.4? Or shall we move on to 6.0 topics?
[15:09] * hpottinger wonders if cwilper might have an update from @mire re: DS-2788?
[15:09] <kompewter> [ https://jira.duraspace.org/browse/DS-2788 ] - [DS-2788] Performance degradation of SOLR Discovery indexing in DSpace 5 - DuraSpace JIRA
[15:11] <tdonohue> Sounds like we'll wait on that (no big deal)
[15:11] <tdonohue> moving along for now.... 6.0 topics
[15:13] <tdonohue> As noted in the agenda, OAI-PMH is still not working on "master": DS-2777 (This is mostly a note to see if anyone has time this week to help dig into it)
[15:13] <kompewter> [ https://jira.duraspace.org/browse/DS-2777 ] - [DS-2777] Three webapps fail to load with DSpace:master post-service API merger: OAI, Sword and SwordV2 - DuraSpace JIRA
[15:13] <tdonohue> All other webapps seem to be working (at least minimally)...though more testing is *highly* encouraged for any/all
[15:14] <hpottinger> I had a slightly unorthodox idea re: the OAI webapp for 6...
[15:14] <tdonohue> I did some digging on 2777, and hit a few walls along the way (notes in that ticket). I hope to get back to it at some point, but not sure if that'll happen this week (if it does it may be Fri)
[15:15] <hpottinger> if the xoai code won't easily work with with the Service API... we could move back to the DB-based OAI...
[15:15] * hpottinger ducks
[15:15] * peterdietz throws a shoe at hpottinger
[15:15] * pbecker throws something in hpottinger's direction
[15:15] <peterdietz> ;)
[15:16] <tdonohue> hpottinger: not sure that actually helps. The problem is that XOAI is trying to use/inject the *HandleService* and cannot find it. It's not really something a DB backend would solve
[15:16] <peterdietz> previous errors are not present. You need to change tomcat log to ... (looking)
[15:17] <peterdietz> http://stackoverflow.com/a/6081748/368581 logging.properties ContainerBase.Catalina.levels ...
[15:17] <kompewter> [ java - Tomcat startup logs - SEVERE: Error filterStart how to get a stack trace? - Stack Overflow ] - http://stackoverflow.com/a/6081748/368581
[15:17] <peterdietz> Often tomcat will just swallow the real error, and not show it in the logs. It might be something simple like, can't find dspace.cfg
[15:18] <tdonohue> In any case , if anyone ends up with ideas on 2777 regarding OAI, I'd appreciate brainstorms/help. I feel like I'm *missing* something...or we just need to STOP wrapping Spring in our ServiceMgr, and use Spring directly.
[15:18] <cwilper> re: DS-2788, no update, agree more measurement + specifics are needed. Two things we have done in our installs that have been fruitful with indexing performance are to 1) reduce the amount of time postgresql transactions are open, and 2) change solr committing behavior, both with code + config. Roeland mentioned #1 in the ticket. I'll add a little more detail about #2 to the ticket shortly.
[15:18] <kompewter> [ https://jira.duraspace.org/browse/DS-2788 ] - [DS-2788] Performance degradation of SOLR Discovery indexing in DSpace 5 - DuraSpace JIRA
[15:18] <tdonohue> peterdietz: huh, that is something to try
[15:18] <peterdietz> Might also need to watch tomcat/log/localhost-DAY-.log
[15:19] <tdonohue> cwilper: thanks for that update
[15:19] <hpottinger> yep, thanks, cwilper, sorry for putting you on the spot like that. :-)
[15:19] <cwilper> np, just didn't notice right away. mostly lurking today :)
[15:20] <tdonohue> Back to DSpace 6-related stuff. We have a TON of PRs currently flagged for possible inclusion in DSpace 6. So, in the coming weeks, I'd like to recommend we start reviewing those in these meetings (even if it's just 20mins or so). (That'd include *this* meeting, once we finish all other topics)
[15:21] <mhwood> 1 ton = 55 PRs. A number of them have merge conflicts. (Someone just a few minutes ago fixed one of those.)
[15:21] <mhwood> Oops, 57.
[15:21] <hpottinger> I mostly suggested moving from xoai to the old code base because xoai is a SpringMVC webapp... and getting SpringMVC to work with Services-API seems to be a blocker...
[15:21] <peterdietz> 1.03 tons of Pull Requests
[15:22] <tdonohue> mhwood: yep :) Right, we'd ignore the ones with merge conflicts for now..and go back to them later
[15:22] <mhwood> So how do we move forward?
[15:22] <tdonohue> So, regarding other topics today. Are there any other topics folks want to bring up around 6.0?
[15:23] <hpottinger> just when you merge a PR for 6, think about whether it can backport to 5.4
[15:23] <peterdietz> Not that I've dug too deep into other new features. But, I'd be quite happy if S3 assetstore, and dynamic configs got in
[15:24] <tdonohue> hpottinger: it's an idea..but honestly, I'm not 100% convinced that I'm not overlooking something yet around OAI-PMH / 2777. I don't know if it is that SpringMVC *won't work* with Services API. But, it's at least frustrating to get working ;)
[15:24] <peterdietz> Try that logging change I mentioned. As simple as editing tomcat/conf/logging.properties, and restarting tomcat
[15:25] <tdonohue> peterdietz: will do. Maybe I can find some time later today to do that, just to see if it brings the problem to light
[15:26] <peterdietz> I also wish that dspace servlets/webapps were less noisy to catalina.out. I don't entirely want to know on an INFO level all the stuff going on.
[15:26] <tdonohue> Ok, before we jump into 6.0 PR reviews, I did also want to mention this brainstorm/design ticket for Hierarchical Metadata Support: DS-2769
[15:26] <kompewter> [ https://jira.duraspace.org/browse/DS-2769 ] - [DS-2769] Hierarchical Metadata Support - DuraSpace JIRA
[15:26] <hpottinger> tdonohue: you're using Vagrant-DSpace to do your testing, correct? This is mostly a "smoke test" of the OAI webapp. Just turn it on and see if smoke comes out.
[15:26] <mhwood> When we have our logging right, nothing would ever get to catalina.out.
[15:27] <tdonohue> (I'm mostly mentioning this because we seem to have this team willing to volunteer *time* towards Hierarchical Metadata Support, if we give them feedback on their idea)
[15:27] <tdonohue> hpottinger: yes, I'm using vagrant-dspace with OAI testing
[15:28] <tdonohue> Regarding 2769, it'd be useful if we could give them some feedback on their ideas..which are given more details in this wiki page: https://wiki.duraspace.org/display/DSPACE/Hierarchical+Metadata+Support+-+LOM+and+MODS
[15:28] <kompewter> [ Hierarchical Metadata Support - LOM and MODS - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/Hierarchical+Metadata+Support+-+LOM+and+MODS
[15:29] <peterdietz> Hierarchical metadata would be another good problem to solve. I feel that that is something that is in high demand in our field. I had a brainstorm on some backus-naur-form for a model in my head. But haven't built any pretty visio diagrams of it
[15:29] <tdonohue> I'm not sure if we want to spend today's meeting talking in depth here, but it seems like we should all find time to review this, and discuss it's plausibility for Hierarchical Metadata
[15:29] <hpottinger> my worry is that if DS-2788 is indeed related to metadata4all, what happens when we make the metadata model more complex?
[15:29] <kompewter> [ https://jira.duraspace.org/browse/DS-2788 ] - [DS-2788] Performance degradation of SOLR Discovery indexing in DSpace 5 - DuraSpace JIRA
[15:29] <mhwood> We find the bottleneck and fix it?
[15:29] <tdonohue> hpottinger: one thing at a time :) If we fix 2788, then we should get a better idea of what causes the bottleneck, and avoid it later on
[15:30] <hpottinger> sorry, I'm a worrier. :-)
[15:31] <peterdietz> I don't think SOLR being poor performance should cause us to stop advancing DSpace. I was at this point 5 years ago (??) When I built the Elastic Search statistics, for performance reasons. But, uniformity and consistency is probably a bigger concern than raw performance
[15:31] <peterdietz> At this moment, I don't believe I'll be able to contribute much to Hierchical metadata for DSpace 6
[15:32] <tdonohue> hierarchical metadata *wouldn't* be for DSpace 6... this project is just in "brainstorms". I just wanted to give them feedback on their design.
[15:32] <peterdietz> Maybe to discussions, but not to development. I've prototypes adding serialized json as metadata values, it sort of gives you some room. https://trydspace.longsight.com/handle/123456789/178
[15:32] <kompewter> [ Getty Research Journal No. 4 ] - https://trydspace.longsight.com/handle/123456789/178
[15:32] <pbecker> We have deep interest in this feature. We are going to start a project next January where hierarchical metadata in DSpace will be one topic.
[15:32] <tdonohue> They are *volunteering* to build this for DSpace. So, it'd be useful if we can help them build it *correctly* (instead of building something that in the end won't work)
[15:33] <tdonohue> pbecker: it'd be useful to get your feedback on 2769 then, to see if their proposal would also work for your needs...or if you see flaws in it, or limitations
[15:33] <mhwood> tdonohue: I hear you. I just haven't anything to say yet.
[15:34] <pbecker> of course, I just won't have the time at least before Oct. 29. ;-)
[15:34] <peterdietz> The current "DSpace way" that one would support hierarchical metadata, is what @Mire did with ORCID. I would say build into DSpace the ability for DSpace to contain its own metadata authority control. And then when you store author = {{ DSPACE-AUTHORS, id=12345 --> first: Peter, last, Dietz, institution: Longsight }}
[15:34] <pbecker> There are good reasons why our project starts in January and not before. But I'll see what I can do.
[15:34] <tdonohue> Since it sounds like most folks haven't reviewed this yet, I wonder if we should all find time to look at it in more detail in the next few weeks, and we can revisit it later on? (I can keep it on the agenda as a reminder to us)
[15:35] <peterdietz> ...but, if one is willing to invest in touching the data model, I think a metadatavalue that can contain other metadata values is a better direction.. But requires DSpace wizards to think about it
[15:35] <tdonohue> pbecker: thanks. I don't think there's a rush here. Although it might also be useful to note your interest (in a comment) and let them know you'd be willing to review it in November sometime (or whenever)
[15:35] <hpottinger> still... it seems like a big layer of complexity to accomodate one use case
[15:36] <mhwood> Indeed, can't we parse this stuff *once* and store the semantic network in a usable form?
[15:36] <cwilper> I do suspect we can squeeze a *lot* better performance out of Solr/discovery indexing. I don't think the problem is inherent in solr, nor is it really a design issue with metadata4all, but is more likely exacerbated by it. What I'd really like to do is set up a proper reindexing performance test, tweaking some of the variables we've noticed as having a significant effect.
[15:36] <peterdietz> This metadata use case is everywhere. I see it all the time. Need a proper solution
[15:37] <tdonohue> Maybe I'll ping the Committers list on this as well (-commit) to see if others have seen this design. It looks *reasonable* to me, but it would need to get into Solr as well for best performance. The joins on these tables to grab out metadata values/attributes seem like they could get complex :)
[15:38] <hpottinger> I'll admit, my librarians are interested in hiearchical metatadata support, so, I'm all for it... I just don't know if the complexity needs to be in the DB
[15:39] <peterdietz> If DSpace had a graph DB (neo4j), I think this would be a piece of cake.
[15:39] * hpottinger wonders if Hibernate accomodates complex structures like, erm, graphs, as peterdietz suggests
[15:40] <tdonohue> hpottinger: right, understandable. In some ways we could just store JSON in the DB (if we were OK with that), and Solr indexing, rather than building a complex set of tables which can handle all hierarchical metadata schemas
[15:40] <mhwood> Ew!
[15:41] <tdonohue> There's lots of way this *could* be done...it's a matter of finding some "best practices" here (and I frankly don't know how other projects store such hierarchies in a relational db)
[15:41] <hpottinger> wait... why build a graph DB on top of a RDBMS?
[15:41] <hpottinger> why not just use a graph DB?
[15:42] <mhwood> Probably should not, if that's what we need.
[15:42] <pbecker> are we discussing now to store everything as linked data like fedora 4 (IIRC)? ;-)
[15:42] <hpottinger> flat metadata goes in the ORM, complex metadata goes into the graph DB
[15:42] * pbecker likes that idea *g*
[15:43] <cwilper> side note: orientdb is kinda neat, java-based, clusterable, and does hierarchical + graph type queries. i did some stuff with it while at sonatype.
[15:43] <mhwood> I was wondering when pbecker would speak up. :-)
[15:43] <tdonohue> I think part of the problem is keeping the number of "pieces" that is DSpace small/contained. We don't want to have to add more and more complexities here to make Dspace "work"
[15:44] <pbecker> to be serious: going to some kind of graph db would be a ton of work.
[15:44] <pbecker> I don't see that this is neccessary now or would help us even with the idea in mind of hierarchical metadata.
[15:44] <cwilper> it's not super mature (like a lot of graph dbs) but has some really nice capabilities. i would treat it as a secondary store -- mostly a cache of stuff stored elsewhere, much the same way people treat solr/elasticsearch, so it can be rebuilt
[15:45] <hpottinger> similar to how we do RDF
[15:45] <pbecker> it would deeply change DSpace and some basic concepts we are now using for years.
[15:46] <mhwood> It's about time for that change, I think. Our metadata manipulation is too close to the data. We need to abstract a bit.
[15:46] <pbecker> If we really want to use graph DB I would prefer to not use a specific db but to support protocolls like sparql 1.1
[15:46] <peterdietz> okay. sorry, maybe wrong direction on this subject, but general idea is that there is some support for the idea of hierarchical metadata, but would like to have people analyze how it might be possible
[15:46] <tdonohue> While these brainstorms are nice, it seems like we need to think more about *use cases* than looking for a "magic bullet". I'm not convinced we need to redo our entire storage layer for Hierarchical Metadata. But, I'm willing to listen to brainstorms :)
[15:47] <pbecker> .addpoint tdonohue
[15:47] <kompewter> tdonohue: +2/-0, 2
[15:47] <tdonohue> I would recommend though that our time today may be better spent elsewhere. It would be great for everyone to think more on Hierarchical Metadata, and review the proposal. but, let's table it for today, and revisit later
[15:47] <mhwood> The metadata service should sort out how it does matching and storage. We can have bounded-hierarchy (QDC) and general hierarchy done differently.
[15:48] <tdonohue> Are there any other pressing topics for today? (If not, I'd suggest we do some PR reviews for the remaining minutes)
[15:48] <pbecker> If there is space for a new topic I just want to let you know that the German DSpace User Group Meeting happend last Monday. We had a great get together with round about 35 people in Universität Tübingen.
[15:49] <mhwood> That's good to hear.
[15:49] <pbecker> There were several talks, g.e. about Migrating OPUS repositories to DSpace, OpenAire compliancy and the strategic plan for the development of DSpace.
[15:49] <tdonohue> great to hear, pbecker!
[15:50] <pbecker> Peter Rempis (the host this year) and I will put up the slides into the DSpace wiki within the next days.
[15:50] <mhwood> I was just going to ask. Thank you!
[15:50] <tdonohue> Any particular feedback or topics of note?
[15:50] <peterdietz> awesome!! I wish we could replicate that success in the US
[15:50] <pbecker> Of course all slides are written in German, but even non German Speakers should be able to see the topics.
[15:51] <pbecker> No particular Feedback. But a lot of great ides.
[15:51] <tdonohue> sounds good
[15:51] <pbecker> I will need some days to sort all of it.
[15:51] <pbecker> But I can recommend to just pick a date, write some mails and invite all interessted DSpace users in your country.
[15:53] <tdonohue> Regarding US-based meetings, I also think we just need one (or a few) institutions to decide to host a regional meeting, and send out invites to see who is interested. I know Fedora has started having regional user groups (mostly a grass-roots sort of thing)
[15:53] <tdonohue> (It's also the same way things like regional code4lib conferences occur)
[15:54] <cknowles> A UK DSpace user group is planned for 2nd Nov.
[15:54] <peterdietz> I feel like I'm on an Island. No DSpace user that I'm aware of for ~100 miles? But, in this room alone, are alot of people in the Midwest
[15:54] <pbecker> Ah I almost forgot we had again some suisse guests as well. ;-)
[15:54] <tdonohue> Any other topics to share for today? (I'm noting we are actually running low on time. Perhaps we look at PRs in the JIRA backlog)
[15:54] <pbecker> cknowles: great!
[15:54] <cknowles> There are going to be regional centres and then we all video conference in
[15:55] <tdonohue> cknowles: also excellent
[15:55] <pbecker> peterdietz: tübingen is more then 400 miles away from berlin
[15:55] <tdonohue> peterdietz: yea, by "regional", I actually do mean something like a "DSpace Midwest User Group" "DSpace West Coast User Group", "DSpace East Coast User Group", etc
[15:56] <hpottinger> +1 midwest DSpace UG
[15:56] <mhwood> Distance is the trouble here. The US is about 4700km across. Germany is about 700km? We have to think more in terms of a number of regional meetings.
[15:56] <pbecker> mhwood: I know. But I was thinking in the same direction as tdonohue.
[15:56] <tdonohue> But, the point is that an institution needs to be willing to host this sort of thing. It works better as a "grassroots event" (like regional code4lib) than a top-down sort of thing
[15:57] <pbecker> there is a reason it is "just" a german dspace user group meeting and not an european one.
[15:57] <tdonohue> .addpoint pbecker
[15:57] <kompewter> pbecker: +2/-0, 2
[15:58] <mhwood> A while back, IU, Purdue, Notre Dame, UIUC, and a few others did manage to send some of their repository people to a meeting. It's probably time to do so again.
[15:58] <peterdietz> Not sure which would be best. Just contact a big Uni, and see if they want to host it? I'm thinking OSU or UMich could host it in the opposite city as the big football game each year. Plus other dates / locations. (Keep in mind, I'm not in contact with these people about these things)
[15:59] <tdonohue> Ok, since we are near 1 hour, I'm not going to introduce any other topics today
[15:59] <pbecker> mhwood: perfect. And don't forget to send a mail to dspace-general to give anybody will the chance to attend as well. that's all what it needs.
[16:00] <pbecker> s/will/willing
[16:00] <kompewter> pbecker meant to say: mhwood: perfect. And don't forget to send a mail to dspace-general to give anybody willing the chance to attend as well. that's all what it needs.
[16:01] <mhwood> Use the Jira hour for PR review? At least part of it?
[16:01] <hpottinger> +1
[16:01] <tdonohue> mhwood: yep, sounds reasonable
[16:01] * pbecker is sorry but unable to attend.
[16:02] <tdonohue> We'll close up the meeting for today. Those who are able to attend the JIRA backlog review, we'll be reviewing PRs today over in #dspace
[16:02] <tdonohue> Thanks all!
[16:34] * pbecker (~pbecker@ubwstmapc098.ub.tu-berlin.de) Quit (Quit: Leaving)
[17:04] * terry-b (~chrome@71-212-24-25.tukw.qwest.net) Quit (Ping timeout: 272 seconds)
[17:50] * hpottinger (~hpottinge@128.206.252.168) Quit (Quit: Leaving, later taterz!)
[18:23] * cknowles (uid98028@gateway/web/irccloud.com/x-yexiwmoilnfzwrzl) Quit (Quit: Connection closed for inactivity)
[19:16] * cwilper (185d1269@gateway/web/freenode/ip.24.93.18.105) Quit (Quit: Page closed)
[19:16] * cwilper (~user@cpe-24-93-18-105.rochester.res.rr.com) has joined #duraspace
[20:53] * dyelar (~dyelar@31.158.45.66.cm.sunflower.com) Quit (Ping timeout: 264 seconds)
[20:56] * cwilper (~user@cpe-24-93-18-105.rochester.res.rr.com) Quit (Quit: cwilper)
[20:57] * dyelar (~dyelar@31.158.45.66.cm.sunflower.com) has joined #duraspace
[21:02] * mhwood (mwood@mhw.ulib.iupui.edu) has left #duraspace
[21:44] * tdonohue (~tdonohue@c-98-226-113-104.hsd1.il.comcast.net) has left #duraspace
[22:54] * dyelar (~dyelar@31.158.45.66.cm.sunflower.com) Quit (Quit: Leaving.)
[23:32] * cwilper (~user@50.48.252.106) has joined #duraspace
These logs were automatically created by DuraLogBot on irc.freenode.net using the Java IRC LogBot.