Timestamps are in GMT/BST.
[0:03] -rajaniemi.freenode.net- *** Looking up your hostname...
[0:03] -rajaniemi.freenode.net- *** Checking Ident
[0:03] -rajaniemi.freenode.net- *** Found your hostname
[0:03] -rajaniemi.freenode.net- *** No Ident response
[0:03] * DuraLogBot (~PircBot@atlas.duraspace.org) has joined #duraspace
[0:03] * Topic is '[Welcome to DuraSpace - This channel is logged - http://irclogs.duraspace.org/]'
[0:03] * Set by cwilper!ad579d86@gateway/web/freenode/ip.173.87.157.134 on Fri Oct 22 01:19:41 UTC 2010
[0:15] -cameron.freenode.net- *** Looking up your hostname...
[0:15] -cameron.freenode.net- *** Checking Ident
[0:15] -cameron.freenode.net- *** Found your hostname
[0:15] -cameron.freenode.net- *** No Ident response
[0:16] * DuraLogBot (~PircBot@atlas.duraspace.org) has joined #duraspace
[0:16] * Topic is '[Welcome to DuraSpace - This channel is logged - http://irclogs.duraspace.org/]'
[0:16] * Set by cwilper!ad579d86@gateway/web/freenode/ip.173.87.157.134 on Fri Oct 22 01:19:41 UTC 2010
[6:39] -asimov.freenode.net- *** Looking up your hostname...
[6:39] -asimov.freenode.net- *** Checking Ident
[6:39] -asimov.freenode.net- *** Found your hostname
[6:39] -asimov.freenode.net- *** No Ident response
[6:39] * DuraLogBot (~PircBot@atlas.duraspace.org) has joined #duraspace
[6:39] * Topic is '[Welcome to DuraSpace - This channel is logged - http://irclogs.duraspace.org/]'
[6:39] * Set by cwilper!ad579d86@gateway/web/freenode/ip.173.87.157.134 on Fri Oct 22 01:19:41 UTC 2010
[14:02] -asimov.freenode.net- *** Looking up your hostname...
[14:02] -asimov.freenode.net- *** Checking Ident
[14:02] -asimov.freenode.net- *** Found your hostname
[14:02] -asimov.freenode.net- *** No Ident response
[14:02] * DuraLogBot (~PircBot@atlas.duraspace.org) has joined #duraspace
[14:02] * Topic is '[Welcome to DuraSpace - This channel is logged - http://irclogs.duraspace.org/]'
[14:02] * Set by cwilper!ad579d86@gateway/web/freenode/ip.173.87.157.134 on Fri Oct 22 01:19:41 UTC 2010
[15:39] * mhwood (mwood@mhw.ulib.iupui.edu) has joined #duraspace
[18:15] * edInCo (~smuxi@seta.coalliance.org) has joined #duraspace
[18:51] * hpottinger (~hpottinge@mu-161244.dhcp.missouri.edu) has joined #duraspace
[20:09] * hpottinger is kind of distracted, but is pretty sure there's supposed to be a meeting today
[20:10] * hpottinger is in no condition to lead it
[20:12] * mhwood1 (mwood@mhw.ulib.iupui.edu) has joined #duraspace
[20:18] * mhwood (mwood@mhw.ulib.iupui.edu) Quit (*.net *.split)
[20:19] <mhwood1> Oh, good: splits.
[20:20] <hpottinger> mhwood1: do we have a quorum here?
[20:20] <mhwood1> Did we? I haven't heard from anyone but you today.
[20:21] <hpottinger> we have an RT quorum at any rate
[20:21] <mhwood1> True.
[20:21] <hpottinger> I think we need one more committer to speak up in order to decide anything
[20:22] * hpottinger wanders around the room, poking lurkers, helix84, kshepherd, PeterDie_
[20:22] <mhwood1> There are still four tickets open on 4.1. One is still unassigned needs-volunteer. At this point I think it will have to move to 4.2.
[20:23] <hpottinger> good idea, let's look at those
[20:24] <mhwood1> DS-1718
[20:24] <mhwood1> No kompewter either.
[20:24] <mhwood1> https://jira.duraspace.org/browse/DS-1718
[20:25] <mhwood1> We'll do it the old-fashioned way.
[20:25] <mhwood1> 1718 looks stalled.
[20:26] * kompewter (~kompewter@ec2-50-17-201-82.compute-1.amazonaws.com) has joined #duraspace
[20:27] <hpottinger> there we go
[20:27] * hpottinger waves to kompewter!
[20:27] <mhwood1> Welcome back kompewter.
[20:28] <hpottinger> 1718 should bump to 4.2
[20:28] <mhwood1> I agree. Will do.
[20:28] <mhwood1> Done.
[20:28] <hpottinger> though, you know, *I* can put in missing configurations, I just am not sure what's missing
[20:29] <mhwood1> DS-1702
[20:29] <kompewter> [ https://jira.duraspace.org/browse/DS-1702 ] - [DS-1702] XSS injection possible on collection home page for JSPUI - DuraSpace JIRA
[20:31] <hpottinger> 1702 is not really a security concern, as admin are generally trusted
[20:32] <mhwood1> That's what I was thinking, based on discussion in the ticket which seems to be saying that.
[20:32] <hpottinger> bump to 4.2
[20:32] <mhwood1> Bump to 4.2 as well? If this comes back to life, we can do a 4.2 quickly if needed.
[20:32] <mhwood1> OK, I'll move it.
[20:33] <hpottinger> 4.2 is looking like Andrea B's call ;-)
[20:33] <mhwood1> Done. Backlog reduced by 50%.
[20:33] <hpottinger> woot!
[20:33] <hpottinger> we are ON FIRE
[20:33] <PeterDie_> hi all,
[20:33] <mhwood1> Hi yourself.
[20:34] <hpottinger> woah, who woke up PeterDie_
[20:34] <mhwood1> DS-1536
[20:34] <kompewter> [ https://jira.duraspace.org/browse/DS-1536 ] - [DS-1536] having a DOT in handle prefix causes identifier.uri to be cut off when being created - DuraSpace JIRA
[20:35] <hpottinger> 1536 is only open for the missing documentation, which is on me to do
[20:36] <mhwood1> Yes, it's all merged but needs DB fixup doco.
[20:37] <hpottinger> I got tricked into documenting it because I happen to "speak oracle"
[20:37] * hpottinger thought for sure that would wake up helix84...
[20:38] <mhwood1> It's 21:38 where he is, I believe. Not the best time to catch his attention, perhaps.
[20:38] <hpottinger> true, true
[20:39] <hpottinger> OK, post meeting I will see if I can untangle 1536 enough to say something sensible in the docs
[20:40] <mhwood1> So, 4.1 can ship as is w.r.t. 1536, and we have sort-of documentation in the ticket, to be tidied up for the release notes.
[20:40] <mhwood1> Thank you!
[20:40] <mhwood1> DS-1781
[20:40] <kompewter> [ https://jira.duraspace.org/browse/DS-1781 ] - [DS-1781] LDAP never uses the specified email_field - DuraSpace JIRA
[20:41] <hpottinger> https://wiki.duraspace.org/display/DSDOC4x/Upgrading+From+4.0+to+4.x
[20:41] <kompewter> [ Upgrading From 4.0 to 4.x - DSpace 4.x Documentation - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSDOC4x/Upgrading+From+4.0+to+4.x
[20:41] <hpottinger> just need to move those to 5.0 docs
[20:42] <mhwood1> Well, copy.
[20:42] <mhwood1> Woohoo, already written. Good show.
[20:43] <helix84> hello
[20:43] <mhwood1> Good evening.
[20:46] <hpottinger> helix84 deserves all the credit for that writing, I think I just copy/pasted some Oraclese in there
[20:46] <helix84> all woken up. 1781 needs just a teeny tiny thing. the person who decided to move release docs around namespaces (in 4.0) didn't say where to put 4.1 docs. They're all written up, though.
[20:48] <hpottinger> ok, where is the page you wrote, where would you expect to put it, and why can't you put it there?
[20:48] <helix84> ad LDAP - feel free to push them to 5.0 if you don't want to tackle them. I lost hope that any small changes will do more good than harm. the netid vs email discussion needs to be figured out first.
[20:48] <mhwood1> One other tweak: I'm changing "query above" to "query below".
[20:49] <mhwood1> Yes, it sounds like 1781 should move, and 4.2 may be too soon. We can always move it again.
[20:49] <hpottinger> 4.x docs seem to be here: https://wiki.duraspace.org/display/DSDOC4x/DSpace+4.x+Documentation
[20:49] <kompewter> [ DSpace 4.x Documentation - DSpace 4.x Documentation - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSDOC4x/DSpace+4.x+Documentation
[20:50] <helix84> hunting down the URLs. wiki is slow.
[20:51] <helix84> sloooooow
[20:52] <hpottinger> so, I was thinking I needed to copy the instructions re: 1536 to the 5.0 docs, but it appears that most of the upgrade from prior versions documentation points off towards older docs
[20:52] <hpottinger> which seems reasonable to me (and less chance for information to fall out of sync)
[20:52] <helix84> hpottinger: I put the actual instrictions into upgrading notes and I just linked to them from release notes
[20:53] <helix84> the wiki is extremely slow...
[20:53] <hpottinger> I think 1536 is as documented as we get, but I could be wrong...
[20:54] <mhwood1> So we need to know where to tuck the release notes into the DSDOC4x space?
[20:54] <mhwood1> hpottinger: I think you are right. Want to close it?
[20:54] <helix84> mhwood1: yes, basically. but they were split up and now look different.
[20:55] <hpottinger> 1536: closed
[20:56] <mhwood1> Hooray! No open issues for 4.1.
[20:56] <mhwood1> Just getting the documentation assembled properly.
[20:56] <helix84> I give up on waiting. Here are the links if someone wants to make sense of this later:
[20:56] <helix84> https://wiki.duraspace.org/display/DSPACE/DSpace+Release+4.0+Notes
[20:56] <helix84> https://wiki.duraspace.org/display/DSPACE/DSpace+Release+4.1+Notes
[20:56] <helix84> https://wiki.duraspace.org/display/DSDOC4x/Release+Notes
[20:56] <kompewter> [ DSpace Release 4.1 Notes - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/DSpace+Release+4.1+Notes
[20:56] <kompewter> [ Release Notes - DSpace 4.x Documentation - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSDOC4x/Release+Notes
[20:57] <helix84> so who will do the honors on Friday?
[20:58] <helix84> I may still have one late translation coming into dspace-xmlui-lang
[20:59] <mhwood1> I can do the release again, if no one else wants it.
[20:59] * edInCo (~smuxi@seta.coalliance.org) Quit (Remote host closed the connection)
[21:00] <hpottinger> it's all yours, mhwood1, though I'm tempted to try it from Vagrant-DSpace
[21:01] * edInCo (~smuxi@seta.coalliance.org) has joined #duraspace
[21:01] <mhwood1> My recollection is that we decided to no longer stuff the PDF into the source kit; instead it will be released with the tar/zipballs on SourceForge. Correct?
[21:01] <hpottinger> correct: big binaries make git slow
[21:02] <mhwood1> I guess that means we need to 'git rm' the 4.0 PDF before tagging.
[21:02] <hpottinger> well... I think we can save the clean-up for another day
[21:03] <hpottinger> though, yeah, maybe we should delete it from master
[21:03] <mhwood1> It isn't a big job, we just need it done. Shipping 4.1 with 4.0 doco. might be confusing.
[21:04] <hpottinger> is there a JIRA issue for that work?
[21:04] <hpottinger> DS-1750
[21:04] <kompewter> [ https://jira.duraspace.org/browse/DS-1750 ] - [DS-1750] Git clone is becoming slow - DuraSpace JIRA
[21:05] <mhwood1> Ah, I was just looking for it.
[21:05] <hpottinger> we should probably schedule that
[21:07] <mhwood1> 1750 seems to cover more than just this, but dropping the PDF from the kit can be attributed to it and the ticket left open for further consideration and (maybe) work.
[21:07] <hpottinger> "maybe work", snicker
[21:09] <mhwood1> Seriously. We may decide that rewriting history is too disruptive, and just carry along the versions already stuck in the history. But right now we can stop this getting any worse, just by 'git rm'ing one file.
[21:09] <helix84> Can we just decide whether the ticket means to stop increasing the repo size or going through all the hassle of actually reducing the repo size? These eternally open issues are starting to multiply.
[21:09] <hpottinger> added a comment to 1750
[21:09] <mhwood1> Bring it up next week? Call for a decision then. There are a lot of people in the channel but only three are talking right now.
[21:10] <helix84> sure
[21:10] <hpottinger> next week, though it only takes 3 to make decisions {evil grin}
[21:10] <mhwood1> Hmmm.
[21:11] <hpottinger> rewriting history does seem a bit drastic
[21:13] <helix84> The church got away with it. But Looney Tunes didn't.
[21:13] <mhwood1> I agree. I lean toward just stopping the rot.
[21:13] <hpottinger> I don't mean philosophically, just that's a lot of broken work
[21:15] * helix84 becomes a ghost again
[21:15] <hpottinger> oh, if we are going to stuff the PDF into the distribution files, we will probably need to change the distribution assembly code
[21:16] <hpottinger> you can do it by hand for now, of course, but zip files are yucky
[21:18] <mhwood1> We can live with the dead weight of the old documentation for a while, and if it's found to be intolerable then we can do more then.
[21:18] <mhwood1> BTW we are about 15 minutes past the official announced ending time for the meeting. But I'm willing to go on, if it's useful.
[21:19] * hpottinger bangs the gavel, dismissed!
[21:19] * hpottinger hands the gavel back to mhwood1
[21:20] <mhwood1> DSPR#491 removes the PDF from the 4_x kit.
[21:20] <kompewter> [ https://github.com/DSpace/DSpace/pull/491 ] - [DS-1750] Remove DSpace manual PDF from the source kit. by mwoodiupui
[21:21] <hpottinger> oh, if this is to be a manual procedure, we should note the procedure in the release instructions
[21:21] <hpottinger> looks good to me +1 merge
[21:22] <mhwood1> Woops, the manual is mentioned in /README.
[21:23] * hpottinger_ (~hpottinge@mu-161244.dhcp.missouri.edu) has joined #duraspace
[21:23] <hpottinger_> wheeee
[21:23] <mhwood1> I will track down any other references. Don't pull just yet.
[21:25] * hpottinger_ wonders how to reclaim that stalled nick
[21:26] * hpottinger (~hpottinge@mu-161244.dhcp.missouri.edu) Quit (Disconnected by services)
[21:26] * hpottinger_ is now known as hpottinger
[21:35] <mhwood1> Good catch: assembly.xml needs tweaking to not refer to a nonexistent directory.
[21:36] <mhwood1> Assembly adjusted, testing....
[21:40] <kshepherd> anyone around with knowlege of the OAI issues in 3.x/4.x like https://jira.duraspace.org/browse/DS-1855 ?
[21:40] <kompewter> [ [DS-1855] OAI-PMH indexing throws AuthorizationException when License is not available anonymously - DuraSpace JIRA ] - https://jira.duraspace.org/browse/DS-1855
[21:40] <kompewter> [ https://jira.duraspace.org/browse/DS-1855 ] - [DS-1855] OAI-PMH indexing throws AuthorizationException when License is not available anonymously - DuraSpace JIRA
[21:40] <kshepherd> just wondering if the PRs for this got merged back into 3_x and 4_x... there seem to be enough changes between them and master that it might not have been trivial
[21:44] <mhwood1> 1855 refers to DS-1856, which is commented that some of this is addressed in OAI 2.1.
[21:44] <kompewter> [ https://jira.duraspace.org/browse/DS-1856 ] - [DS-1856] OAI-PMH indexes metadata of non-public Items - DuraSpace JIRA
[21:44] <kshepherd> yeh
[21:44] <mhwood1> I don't know what parts that might be.
[21:44] <kshepherd> and covered by pulls 441 (replaced by 466)
[21:46] <kshepherd> just figuring out how to actually get a 3.x compatible patch/branch out of all that work..
[21:48] <kshepherd> hrm, actually, looks like that wasn't included in the list of bugfixes, i just assumed it was
[21:59] <hpottinger> can I help with testing?
[21:59] <kshepherd> sure, looks like i have to write hte fix first htough ;P
[21:59] <kshepherd> s/htough/though/
[21:59] <kompewter> kshepherd meant to say: sure, looks like i have to write hte fix first though ;P
[21:59] <kshepherd> kompewter: THANKS
[22:00] <kshepherd> we're a bit behind with our own IR, upgrading to 3.2 finally :P but this is a showstopper for us
[22:01] <hpottinger> I think Vagrant-DSpace would give you a quick way to test against a working version of the master branch
[22:03] * hpottinger is trying to follow the thread of the conversation re: OAI stuff
[22:03] <kshepherd> master branch no good i don't think, too many dspace-oai changes since 3_x
[22:04] <mhwood1> I have to leave. Goodbye all.
[22:04] * mhwood1 (mwood@mhw.ulib.iupui.edu) has left #duraspace
[22:05] <hpottinger> Oh, I see, well... it's a problem with the 3x and 4x/master branches, looks like, so we'd probably want to change on master first?
[22:07] <hpottinger> I think the behavior described int 1856 is the way OAI has always worked for DSpace
[22:08] <hpottinger> I don't think OAI has ever respected metadata access rights
[22:09] <hpottinger> s/OAI/OAI as coded in DSpace/g
[22:09] <kompewter> hpottinger meant to say: I don't think OAI as coded in DSpace has ever respected metadata access rights
[22:09] * aschweer (~schweer@schweer.its.waikato.ac.nz) has joined #duraspace
[22:09] <hpottinger> two kiwis in the room!
[22:09] <aschweer> hpottinger: are you sure? I don't remember what's standard DSpace and what's our customisation, but there is an 'includerestricted' config setting isn't there?
[22:10] <aschweer> and I'm not sure I qualify as a kiwi really ;)
[22:10] <hpottinger> I'm working from memory, but I do remember OAI being rather chatty about the contents of our repository
[22:10] <aschweer> https://github.com/DSpace/DSpace/blob/master/dspace/config/dspace.cfg#L415
[22:10] <kompewter> [ DSpace/dspace/config/dspace.cfg at master · DSpace/DSpace · GitHub ] - https://github.com/DSpace/DSpace/blob/master/dspace/config/dspace.cfg#L415
[22:11] <hpottinger> aschweer: that line is for the OAI client, I think?
[22:11] <aschweer> no I don't think so
[22:11] <aschweer> "If you wish to only expose items through these channels where the ANONYMOUS
[22:11] <aschweer> # user is granted READ permission, then set the following options to false"
[22:11] <aschweer> https://github.com/DSpace/DSpace/blob/master/dspace/config/dspace.cfg#L406
[22:11] <kompewter> [ DSpace/dspace/config/dspace.cfg at master · DSpace/DSpace · GitHub ] - https://github.com/DSpace/DSpace/blob/master/dspace/config/dspace.cfg#L406
[22:11] <aschweer> still says that actually :)
[22:12] <aschweer> the setting is just ignored by xoai afaik
[22:13] <hpottinger> well, interesting, when did those configurations get in there?
[22:13] <kshepherd> what issue is this?
[22:14] <hpottinger> Blame says december of 2008, Stuart Lewis
[22:14] <kshepherd> i do remembe the includerestricted config...
[22:14] <kshepherd> it works
[22:14] <hpottinger> https://github.com/DSpace/DSpace/commit/09dcb5219bcc8811a55c8b304b75c262d98accab
[22:14] <kompewter> [ Fix for SF bug [1730606] Restricted Items metadata exposed via OAI · 09dcb52 · DSpace/DSpace · GitHub ] - https://github.com/DSpace/DSpace/commit/09dcb5219bcc8811a55c8b304b75c262d98accab
[22:14] <kshepherd> but DS-1855 refers to any item (restricted or not) with a restricted licence bundle/file
[22:14] <kompewter> [ https://jira.duraspace.org/browse/DS-1855 ] - [DS-1855] OAI-PMH indexing throws AuthorizationException when License is not available anonymously - DuraSpace JIRA
[22:15] <kshepherd> however, i'm not actually completely sure whether it's breaking anything or just filling up our locks with stacktraces and failing on those particular items
[22:15] <kshepherd> i'll comment on teh DS issue when i know more
[22:20] <kshepherd> *something* is broken on my test OAI anyway (blank page and no errors for any normal requests), and not dev.. will keep digging
[22:23] <hpottinger> it's interesting that we have this policy in the config, and then assume the policy is set one way with REST-API, and another app ignores the policy
[22:24] * hpottinger dreams of a world where that kind of thing isn't possible
[22:31] <aschweer> sorry, I had to be elsewhere
[22:31] <aschweer> I remember I customised something in DSpace 4 OAI just a few weeks ago around bitstream/bundle permissions but I've already forgotten what it was...
[22:38] <aschweer> right it looks like it's just complaining excessively. However it also only tries to index the first bitstream in the license bundle, which may or may not be what people expect
[22:38] <aschweer> https://github.com/DSpace/DSpace/blob/master/dspace-oai/src/main/java/org/dspace/xoai/util/ItemUtils.java#L280
[22:38] <kompewter> [ DSpace/dspace-oai/src/main/java/org/dspace/xoai/util/ItemUtils.java at master · DSpace/DSpace · GitHub ] - https://github.com/DSpace/DSpace/blob/master/dspace-oai/src/main/java/org/dspace/xoai/util/ItemUtils.java#L280
[22:38] <kshepherd> yeh
[22:41] <kshepherd> so our "OAI returns blank page for everything" might be someting else, but xoai is working fine in our dev instance, which configured the same, but doesn't contain those restricted licence bitstreams
[22:41] <kshepherd> the solr index itself looks ok
[22:41] <aschweer> hum
[22:41] * kshepherd resumes headscratching
[22:41] <aschweer> and the oai solr queries look fine on your test instance too? (in the tomcat log)
[22:43] <aschweer> oh, also: https://github.com/DSpace/DSpace/blob/master/dspace-oai/src/main/java/org/dspace/xoai/app/XOAI.java#L293 suggests that items with even one non-public bundle won't be indexed
[22:43] <kompewter> [ DSpace/dspace-oai/src/main/java/org/dspace/xoai/app/XOAI.java at master · DSpace/DSpace · GitHub ] - https://github.com/DSpace/DSpace/blob/master/dspace-oai/src/main/java/org/dspace/xoai/app/XOAI.java#L293
[22:43] <kshepherd> i'll check again, not sure if i've seen the queries be logged
[22:47] <kshepherd> i can see lots of successful POSTSs.. and i can see GETs for my working dev oai but not test, so i guess something's going wrong further up the chain. will keep looking.
[22:47] <kshepherd> oh no wait, that was my earlier testing
[22:48] <kshepherd> i don't think i can actually see teh dspace->localhost:8080/solr GETs in either instance.. maybe my logging is bad
[22:49] <aschweer> that sounds odd
[22:50] <kshepherd> and i can see the responses appearing in the oai cache
[22:50] <kshepherd> but tomcat just never gives them to me! :P
[22:50] <aschweer> my dspace 4 dev instance currently doesn't have oai deployed -- will do that then check logs for reference
[22:50] <kshepherd> yes, this is getting a bit twilight zone
[22:53] <kshepherd> HAHA found it
[22:53] <kshepherd> *facepalm*
[22:53] <aschweer> oh?
[22:55] <kshepherd> my previous clever apache rewrite rules to block requests taht weren't for (a) valid sets, (b) identify or listsets, etc. (so nobody could explicitly request our 'closed' collections or do a ListRecords without specifying sets) has been happily working in test and production
[22:55] <kshepherd> but
[22:56] <kshepherd> now it's blocking the requests for /static/style.xsl l)
[22:56] <aschweer> haha
[22:56] <kshepherd> no stylesheet, no display ;)
[22:56] <aschweer> yeah I guess you can't complain about that :)
[22:59] <aschweer> anyway, lunchtime. catch you later :)
[22:59] * aschweer (~schweer@schweer.its.waikato.ac.nz) Quit (Quit: leaving)
[23:19] * edInCo (~smuxi@seta.coalliance.org) Quit (Read error: Connection reset by peer)
[23:27] * hpottinger (~hpottinge@mu-161244.dhcp.missouri.edu) has left #duraspace
[23:46] * kshepherd2 (~kim@203.160.115.131) has joined #duraspace
These logs were automatically created by DuraLogBot on irc.freenode.net using the Java IRC LogBot.