Timestamps are in GMT/BST.
[0:00] * Dylan__ (~Dylan@86.39.200.115.static.hosted.by.easyhost.be) has joined #duraspace
[0:37] * Dylan__ (~Dylan@86.39.200.115.static.hosted.by.easyhost.be) Quit (Remote host closed the connection)
[0:38] * Dylan__ (~Dylan@86.39.200.115.static.hosted.by.easyhost.be) has joined #duraspace
[3:04] * terry-b3 (~chrome@75-172-49-239.tukw.qwest.net) Quit (Read error: Connection reset by peer)
[3:05] * terry-b3 (~chrome@75-172-49-239.tukw.qwest.net) has joined #duraspace
[6:41] -hitchcock.freenode.net- *** Looking up your hostname...
[6:41] -hitchcock.freenode.net- *** Checking Ident
[6:41] -hitchcock.freenode.net- *** Found your hostname
[6:42] -hitchcock.freenode.net- *** No Ident response
[6:42] * DuraLogBot (~PircBot@webster.duraspace.org) has joined #duraspace
[6:42] * Topic is '[Welcome to DuraSpace - This channel is logged - http://irclogs.duraspace.org/]'
[6:42] * Set by cwilper!ad579d86@gateway/web/freenode/ip.173.87.157.134 on Fri Oct 22 01:19:41 UTC 2010
[7:31] * pbecker (~pbecker@ubwstmapc098.ub.tu-berlin.de) has joined #duraspace
[7:48] * Dylan__ (~Dylan@86.39.200.115.static.hosted.by.easyhost.be) Quit (Remote host closed the connection)
[7:48] * Dylan__ (~Dylan@86.39.200.115.static.hosted.by.easyhost.be) has joined #duraspace
[10:04] * tmmguimaraes (~tmg@193.137.88.100) has joined #duraspace
[12:23] * mhwood (mwood@mhw.ulib.iupui.edu) has joined #duraspace
[13:31] * hpottinger (~hpottinge@mu-161168.dhcp.missouri.edu) has joined #duraspace
[14:53] * dyelar (~dyelar@31.158.45.66.cm.sunflower.com) has joined #duraspace
[14:59] * pbecker (~pbecker@ubwstmapc098.ub.tu-berlin.de) Quit (Quit: Leaving)
[15:42] * tmmguimaraes (~tmg@193.137.88.100) Quit (Quit: Leaving)
[15:42] * Dylan__ (~Dylan@86.39.200.115.static.hosted.by.easyhost.be) Quit (Remote host closed the connection)
[15:43] * Dylan__ (~Dylan@86.39.200.115.static.hosted.by.easyhost.be) has joined #duraspace
[16:58] * luizsan (~luizsan@209.120.171.227) has joined #duraspace
[19:06] * luizsan (~luizsan@209.120.171.227) Quit (Quit: Leaving...)
[19:06] * luizsan (~luizsan@209.120.171.227) has joined #duraspace
[19:06] <luizsan> Hi
[19:56] * tdonohue (~tdonohue@c-98-220-55-31.hsd1.il.comcast.net) has joined #duraspace
[19:57] <tdonohue> Hi all, reminder that DSpace DevMtg starts here in a few minutes. Agenda: https://wiki.duraspace.org/display/DSPACE/DevMtg+2016-07-06
[19:57] <kompewter> [ DevMtg 2016-07-06 - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/DevMtg+2016-07-06
[20:00] <tdonohue> It's now the top of the hour...a gentle reminder to any Committers in the room (pinging helix84, hpottinger, mhwood, terry-b3)
[20:01] <mhwood> Pong
[20:01] <tdonohue> We seem to be a smaller group again today, which is a tad disappointing. But, still hoping we can make some headway on pushing towards 6.0 final
[20:02] <tdonohue> In the last week, as noted on the agenda, I've flagged all tickets I feel we need to resolve (or reschedule if we deem them less serious) *before* 6.0 final....
[20:03] <tdonohue> And those are all the tickets currently scheduled for 6.0 (fix for 6.0) and a priority of "Major" or above: https://jira.duraspace.org/secure/IssueNavigator.jspa?reset=true&jqlQuery=project+%3D+DS+AND+priority+in+%28Blocker%2C+Critical%2C+Major%29+AND+resolution+%3D+Unresolved+AND+fixVersion+%3D+6.0&src=confmacro
[20:03] <kompewter> [ Issue Navigator - DuraSpace JIRA ] - https://jira.duraspace.org/secure/IssueNavigator.jspa?reset=true&jqlQuery=project+%3D+DS+AND+priority+in+%28Blocker%2C+Critical%2C+Major%29+AND+resolution+%3D+Unresolved+AND+fixVersion+%3D+6.0&src=confmacro
[20:04] <tdonohue> While there are 37 tickets in that category, some of these simply need a "retest", some have a PR which needs testing, and some simply need docs. That said, there are still some needing a volunteer to help us resolve the ticket
[20:04] <tdonohue> Nonetheless, I feel we are getting close to a 6.0. I'd hope most of these tickets should be resolvable rather quickly.
[20:04] <mhwood> There are two unassigned awaiting documentation.
[20:06] <tdonohue> In any case, today was about touching base on this list, and looking to either find volunteers for tickets, or seeing if anything is miscategorized, etc
[20:06] <mhwood> 3154 is still massive. It may have to wait.
[20:07] <tdonohue> mhwood: yes, that's one we likely will need to just break up / reschedule. One option on DS-3154 is to simply "turn off doclint" for now, but leave ourselves a ticket for 7.0 to do further cleanup etc
[20:07] <kompewter> [ https://jira.duraspace.org/browse/DS-3154 ] - [DS-3154] Maven release process fails when using Java 8 because of Javadocs errors - DuraSpace JIRA
[20:09] <tdonohue> just added a comment to that affect
[20:09] <tdonohue> in any case, I'd like to start at the top of this list of tickets and do a quick review today...see if we can find a volunteer for each, or discuss what may be needed to resolve (or reschedule) as needed
[20:10] <mhwood> OK
[20:10] <tdonohue> So, at the very top we have DS-3259 (has a PR, needs a tester)
[20:10] <kompewter> [ https://jira.duraspace.org/browse/DS-3259 ] - [DS-3259] DSpace creates unnecessary resource policies containing many null values - DuraSpace JIRA
[20:11] <tdonohue> this seems like it should stay on the list, as it's a definite new bug. Just needs a tester to grab the PR and try it out
[20:12] <terry-b3> I can take this one, but it may be a few days until I can tackle it
[20:12] <tdonohue> thanks terry-b3! Feel free to claim (either the PR or ticket)
[20:12] <terry-b3> done
[20:12] <tdonohue> moving along, DS-3256 (has PR, needs testing)
[20:13] <kompewter> [ https://jira.duraspace.org/browse/DS-3256 ] - [DS-3256] Configuration of metadata fields to show in JSPUI itemdisplay is broken - DuraSpace JIRA
[20:13] <luizsan> tdonohue: https://jira.duraspace.org/browse/DS-3259 already have a pull request.
[20:13] <kompewter> [ https://jira.duraspace.org/browse/DS-3259 ] - [DS-3259] DSpace creates unnecessary resource policies containing many null values - DuraSpace JIRA
[20:13] <kompewter> [ [DS-3259] DSpace creates unnecessary resource policies containing many null values - DuraSpace JIRA ] - https://jira.duraspace.org/browse/DS-3259
[20:13] <tdonohue> luizsan: yes, I realize that, I was asking for a tester for the PR. We cannot merge the PR without some basic tests (unless it's a tiny obvious fix)
[20:14] <tdonohue> The PR for 3256 was already assigned to me by pbecker, and I can claim this (though I'm out the rest of this week, so it'll be next week)
[20:14] <luizsan> tdonohue: I got it.
[20:14] <tdonohue> next up, DS-3255
[20:14] <kompewter> [ https://jira.duraspace.org/browse/DS-3255 ] - [DS-3255] 'dspace structure-builder' silently fails, logging Hibernate errors - DuraSpace JIRA
[20:15] <mhwood> I was hoping that that one would catch the eye of someone who understands our Hibernate code better than I.
[20:15] <tdonohue> 3255 still needs a volunteer to investigate.
[20:15] <tdonohue> mhwood: Have you tried pinging / emailing KevinVdV directly? Maybe he or someone at Atmire can take a quick look at it?
[20:15] <mhwood> I have not.
[20:16] <tdonohue> Please do so then..and I'll update it to "needs volunteer" status.
[20:16] <tdonohue> moving along for now... DS-3243
[20:16] <kompewter> [ https://jira.duraspace.org/browse/DS-3243 ] - [DS-3243] Cannot resume authentication - DuraSpace JIRA
[20:18] <tdonohue> This needs investigation. Likely a smaller issue, but it seems like a new bug to me that we need to fix
[20:18] <mhwood> Argh, those bugs that are carried along through the session context are hard to find!
[20:18] <tdonohue> It also may simply need someone else to verify/validate...just to be sure this is happening for others as well
[20:19] <terry-b3> In resolving this, does it need to resume the session or just provide a friendly error.
[20:19] <terry-b3> (Suggesting that as a clarification in the ticket)
[20:19] <tdonohue> terry-b3: ideally resume the session, as that was the noted behavior of 5.x
[20:20] <mhwood> Otherwise treat this as an anonymous session.
[20:21] <terry-b3> ok. In my testing I have not necessarily relied on this behavior, but it could be due to my authn method
[20:21] <tdonohue> ok, well, I'll leave this as needs volunteer for now. At the very least it sounds like this needs more investigation of issue/options.
[20:21] <tdonohue> (this one might be possible to ignore for a 6.1 if we needed too, as it's less likely to occur much...but still would be nice to fix)
[20:22] <tdonohue> in any case, moving on to DS-3241
[20:22] <kompewter> [ https://jira.duraspace.org/browse/DS-3241 ] - [DS-3241] org.dspace.content.crosswalk.CrosswalkMetadataValidator needs apache commons-lang3 at least in version 3.2 but no version defined in pom.xml - DuraSpace JIRA
[20:22] <terry-b3> I feel like I resolved a similar issue... let me look for it
[20:22] <tdonohue> This one I stumbled on in our inbox, and I thought we did something with Commons-Lang3 recently, but couldn't remember the details myself
[20:23] <mhwood> If that's the whole stack trace, then apparently we *do* have a direct dependency on lang3.
[20:24] <terry-b3> See https://jira.duraspace.org/browse/DS-3237
[20:24] <kompewter> [ [DS-3237] Class not found error running AIP restore - DuraSpace JIRA ] - https://jira.duraspace.org/browse/DS-3237
[20:24] <kompewter> [ https://jira.duraspace.org/browse/DS-3237 ] - [DS-3237] Class not found error running AIP restore - DuraSpace JIRA
[20:24] <tdonohue> aha. Good find, terry-b3. IN that case, it sounds like 3241 is already fixed...it was logged *before* we merged/closed 3237 (which is the same error)
[20:25] <tdonohue> I'll close 3241 as a duplicate of 3237, as these are obviously the same (at least to me)
[20:26] <terry-b3> sounds good
[20:26] <tdonohue> done
[20:26] <tdonohue> next up, DS-3234
[20:26] <kompewter> [ https://jira.duraspace.org/browse/DS-3234 ] - [DS-3234] Database Migration Script fails when executed by ANT, issue is repairable - DuraSpace JIRA
[20:26] <terry-b3> I have not yet had a chance to re-test. I still have this on my plate
[20:27] <mhwood> If it's assigned, it no longer needs a volunteer.
[20:27] <tdonohue> Ok, thanks terry-b3. Yes, we should reverify this... if the upgrade isn't working as documented, then we need to fix that
[20:27] <tdonohue> mhwood: yep, I just updated to status "accepted"
[20:28] <tdonohue> next up, DS-3233
[20:28] <kompewter> [ https://jira.duraspace.org/browse/DS-3233 ] - [DS-3233] DSpace 6.0 Handle server not starting - DuraSpace JIRA
[20:28] <tdonohue> ugh, sounds like a possible other log4j init problem in the handle server startup script
[20:28] <mhwood> Didn't we fix that already?
[20:29] <tdonohue> mhwood: I don't recall whether we fixed it in the handle startup script. We did fix other log4j issues though (trying to find the ticket/pr)
[20:30] <tdonohue> related to DS-3104
[20:30] <kompewter> [ https://jira.duraspace.org/browse/DS-3104 ] - [DS-3104] DSpace's command line interface has problems finding the log directory - DuraSpace JIRA
[20:30] <tdonohue> Actually, 3233 might just need *retesting*...it's possible the PRs in 3104 did fix this
[20:32] <tdonohue> linked up with 3104 and noted that it needs retesting
[20:33] <tdonohue> moving along, DS-3229
[20:33] <kompewter> [ https://jira.duraspace.org/browse/DS-3229 ] - [DS-3229] JSPUI: Submission verify step ignores type binding - DuraSpace JIRA
[20:33] <tdonohue> This has a PR that just needs someone to test & verify. It's a regression bug (used to work fine in 5.x)
[20:34] <tdonohue> actually...hmmm.. wait, it *didn't work in 5.x*...the ticket said it worked in 3.x :) But, still would be nice to finally fix
[20:35] <tdonohue> I'll leave as 'code review needed' for now
[20:35] <tdonohue> next, DS-3224
[20:35] <kompewter> [ https://jira.duraspace.org/browse/DS-3224 ] - [DS-3224] Submitters don't have the authorization to view their own files under embargo - DuraSpace JIRA
[20:36] <terry-b3> Should the submitter have access or should the embargo rule be absolute?
[20:36] <tdonohue> For this one, I actually couldn't remember if this worked right in 5.x...or if this is a more "longstanding" known issue?
[20:36] <tdonohue> terry-b3: good question
[20:37] <mhwood> Where does it say that the submitter should be immune to embargo?
[20:37] <terry-b3> Most of our submissions are done by repository admins, so I do not know if this is a current issue.
[20:37] <tdonohue> anyone know if this is just how embargo works? If so, we should likely just leave this open and note that it's *also* a known issue in 4.x,5.x etc
[20:38] <tdonohue> Essentially, if this existed in 4.x, 5.x, then I'd recommend we simply deschedule this from 6.0 (and wait for a volunteer to fix it). But, if this is a newly broken issue, we probably should fix it
[20:39] <tdonohue> Anyone willing to volunteer to investigate whether this bug also occurs in 4.x or 5.x?
[20:39] <terry-b3> I will run a test while we are meeting...
[20:39] <tdonohue> thanks terry-b3
[20:39] <mhwood> I suspect that this is actually a feature request, in that I expect it never worked the way the poster expects it to.
[20:40] <tdonohue> mhwood: yea, I'm starting to wonder if that's the case myself. If so, we can take it off our list for 6.0
[20:40] <tdonohue> moving along, DS-3209
[20:40] <kompewter> [ https://jira.duraspace.org/browse/DS-3209 ] - [DS-3209] Runtime Exception (Can't Create Identifier) on Items During AIP Restore - Restore Fails - DuraSpace JIRA
[20:40] <tdonohue> Has a PR, needs testing
[20:41] <tdonohue> oh, wait..this is that one from Georgetown that's had a lot of discussion :)
[20:41] <terry-b3> It would be great to have a test from someone. This is Mike's first PR and I would love to see it merged.
[20:42] <tdonohue> agreed, it'd be good to have a tester or two. I'd be glad to do a code reveiw (again won't happen till next week though)
[20:43] <tdonohue> terry-b3: does testing this just involve doing an AIP import? Or is it a specialized import of some sort?
[20:44] <terry-b3> It is an AIP import.
[20:44] <hpottinger> I was about to ask the same thing
[20:44] <terry-b3> There may be some details about how authority policies are named
[20:44] <tdonohue> cause it sounds like you just need an AIP export from a 5.x instance...then import it into 6.x and see if it works?
[20:45] <terry-b3> This was a port of a 5x solution into 6x
[20:45] <hpottinger> pretty sure 6x AIP restore works, but I'll look into it
[20:45] <tdonohue> right, I understand. I was just trying to help out testers...let them know how to test this exactly :)
[20:46] <tdonohue> hpottinger: sounds good. I'll let you have this one then
[20:46] <terry-b3> Sorry... my comment applied to his other PR. This one was a 6x issue.
[20:47] <tdonohue> terry-b3: If you or he can add a comment on the steps to test the PR, it might be helpful. I *think* they are just: (1) Export AIP from 5.x, (2) Try to import it to 6.x.
[20:47] <mhwood> Is there anything special about the handles that trigger the problem?
[20:47] <hpottinger> does it *have* to be exported from 5.x?
[20:48] <tdonohue> hpottinger: not sure...but it sounds like that's what he did when he encountered this (according to the ticket description & first comment)
[20:49] <terry-b3> Export from instance 1 that uses one handle pattern. Import into another instance using a different pattern.
[20:49] <tdonohue> so, that's why I was asking for more docs on how to replicate & test it. We need more details :)
[20:49] <mhwood> By "different pattern" you mean the two instances have different prefixes?
[20:49] <terry-b3> We pull prod handles into our test instance but need ot preserve the prod handles
[20:49] <terry-b3> They have different handle prefixes.
[20:50] <mhwood> And that's what triggers the problem?
[20:50] <terry-b3> The terminology on this may not be standard
[20:50] <terry-b3> I believe so. I will ask Mike to provide the definitive details
[20:50] <hpottinger> OK... so... totally different handles are OK? I can grab some AIPs from MOspace and try to load them into my dev instance, that'll be interesting
[20:51] <tdonohue> Thanks terry-b3. I think a step by step example that can replicate this scenario (from Mike) would help us out
[20:51] <tdonohue> moving along now... DS-3199
[20:51] <kompewter> [ https://jira.duraspace.org/browse/DS-3199 ] - [DS-3199] Editing bitstream generates error when saving - DuraSpace JIRA
[20:52] <tdonohue> This is one I investigated last week, but hadn't gotten back to. Bitstream editing from XMLUI doesn't work at all
[20:52] <tdonohue> It seems to be a UUID related issue (see my comment). I haven't had time to get back to this though (and won't until next week)
[20:53] <tdonohue> My suspicion is this is a tiny bug... as it seems to be trying to treat the Format ID (which is an Int) as a UUID somewhere in the XMLUI
[20:53] <tdonohue> If anyone wants it, feel free to claim it..otherwise, I'll try to get back to it sometime next week if I can
[20:54] <tdonohue> moving along for now... DS-3190
[20:54] <kompewter> [ https://jira.duraspace.org/browse/DS-3190 ] - [DS-3190] org.dspace.rdf.RDFConfiugartion throws IllegalAccessException - DuraSpace JIRA
[20:54] <tdonohue> this just needs docs from pbecker...skipping
[20:54] <tdonohue> next, DS-3157
[20:54] <kompewter> [ https://jira.duraspace.org/browse/DS-3157 ] - [DS-3157] browse by author displays authority key instead of value - JSPUI Test Plan Ref DISC6 - XMLUI DISC8 - DuraSpace JIRA
[20:55] <terry-b3> I am unable to test DS-3224. We do not allow a submitter to set an embargo.
[20:55] <kompewter> [ https://jira.duraspace.org/browse/DS-3224 ] - [DS-3224] Submitters don't have the authorization to view their own files under embargo - DuraSpace JIRA
[20:55] <tdonohue> This is a display issue with author authorities... it affects *both* JSPUI and XMLUI
[20:56] <terry-b3> Re 3157, I believe I saw this when I had authorities enabled. Does the issue resolve itself after re-indexing or after running the authority management command line tasks
[20:57] <tdonohue> terry-b3: unaware of this "resolving itself". It exists on demo.dspace.org right now though
[20:57] <mhwood> Is that the one that displays *some* names and *some* keys?
[20:57] <tdonohue> although it looks like demo.dspace.org is down
[20:58] <tdonohue> mhwood: yes... Some author names display right...it almost seems like names *later in the list* suddenly switch to keys
[20:58] <mhwood> So it may indeed be indexing.
[20:58] <hpottinger> terry-b3: maybe we can investigate the ORCID setup on demo?
[20:58] <terry-b3> Does demo run all of the nightly cron tasks?
[20:58] <tdonohue> but, as far as I'm aware 3157 has no resolution. But, if someone knows of one (if it is just an indexing issue), then that'd be good to document (and close the ticket)
[20:59] <hpottinger> I was just thinking that perhaps a cron job was missed
[20:59] <tdonohue> demo does run nightly tasks...not sure if it has *all* the cron jobs, but it should. It is possible we forgot one though
[20:59] <tdonohue> so, essentially 3157 needs a volunteer to investigate if this is demo specific, or if it really is a bug
[20:59] <terry-b3> I am just suggesting it as a possible solution. I no longer have it configured. I feel like I should include something in "quotes"
[21:00] <tdonohue> added a note to 3157 that it needs retesting
[21:02] <tdonohue> Ok, we've run out of time today. We didn't make it through all the tickets...and unfortunately, I cannot stick around much longer
[21:02] <mhwood> I'm going to have to leave.
[21:02] <tdonohue> So, we'll stop at 3157 today. I'd encourage everyone to please go through this list and claim a few tickets (to test, re-test, document or fix, based on status). The sooner we cut down this list, the sooner we can release 6.0
[21:02] <tdonohue> Here's that list again: https://jira.duraspace.org/secure/IssueNavigator.jspa?reset=true&jqlQuery=project+%3D+DS+AND+priority+in+%28Blocker%2C+Critical%2C+Major%29+AND+resolution+%3D+Unresolved+AND+fixVersion+%3D+6.0&src=confmacro
[21:02] <kompewter> [ Issue Navigator - DuraSpace JIRA ] - https://jira.duraspace.org/secure/IssueNavigator.jspa?reset=true&jqlQuery=project+%3D+DS+AND+priority+in+%28Blocker%2C+Critical%2C+Major%29+AND+resolution+%3D+Unresolved+AND+fixVersion+%3D+6.0&src=confmacro
[21:03] <tdonohue> Thanks all! FYI, I'll be out for the rest of this week, but will be returning to the office on Monday morning
[21:03] <terry-b3> I added a comment to DS-3224 recommending that someone test this on a 5x instance (that allows submitters to assign embargo)
[21:03] <kompewter> [ https://jira.duraspace.org/browse/DS-3224 ] - [DS-3224] Submitters don't have the authorization to view their own files under embargo - DuraSpace JIRA
[21:03] <mhwood> 'bye all.
[21:03] * mhwood (mwood@mhw.ulib.iupui.edu) has left #duraspace
[21:06] * tdonohue (~tdonohue@c-98-220-55-31.hsd1.il.comcast.net) has left #duraspace
[21:06] * hpottinger (~hpottinge@mu-161168.dhcp.missouri.edu) Quit (Quit: Leaving, later taterz!)
[22:00] * luizsan (~luizsan@209.120.171.227) Quit (Quit: Leaving...)
[23:59] * Dylan__ (~Dylan@86.39.200.115.static.hosted.by.easyhost.be) Quit (Remote host closed the connection)
These logs were automatically created by DuraLogBot on irc.freenode.net using the Java IRC LogBot.