Log of the #duraspace-ff channel on chat.freenode.net

Using timezone: Eastern Standard Time
* ksclarke leaves01:42
* jgpawletko joins07:28
* ajs6f joins07:57
* dhlamb joins08:46
* awead joins08:57
* ksclarke joins09:05
* acoburn joins09:21
* osmandin joins09:24
* mikeAtUVa joins09:28
* MohamedAR joins09:37
* github-ff joins09:39
[fcrepo4] osmandin opened pull request #761: Remove symbolic link image reference to fix maven jettyconsole jar windo... (master...1414) http://git.io/vevwe
* github-ff leaves
* awead leaves09:41
* awead joins09:43
<osmandin>[sprint] Yesterday: Worked on FCREPO-1414, created PR-761 for it. Today: It's a wrap.09:47
afk (meetings)09:58
<dhlamb>are awoods and dwilcox mia?09:59
lost in conference land somewhere?
<acoburn>dhlamb: I think awoods was at the DCFUG meeting10:00
<ajs6f>dhlamb: They're probably traveling or recovering.
<ruebot>Maybe they're doing M.I.A. karaoke somewhere.
<ajs6f>acoburn: Yes.
<ruebot>ah, that makes sense.
<ajs6f>They had a lot farther to go to get home than did I.
<ruebot>do we have a tech call today?
<ajs6f>Given that the only dev on sprint is osman, and there is no agenda...10:01
<acoburn>either way, I can't make it (I have another meeting)
<ruebot>Welp. I suppose not.
<ajs6f>ruebot: Do you have something that warrants discussion?
<ruebot>ajs6f: wanted to discuss the work that danny and jared had been doing, and how we should be much better at coordinating with mikeAtUVa.10:03
<ajs6f>mikeAtUVa: Can you make a call for that?
<ruebot>ajs6f: also so 3.8.1-SNAPSHOT updates. ben and I have been working working through stuff.
<ajs6f>ruebot: Can you set up an agenda page before 11? If not, perhaps we should make some "special topics" calls in Hangout.10:04
<ruebot>I vote for special topics hangout10:05
<ajs6f>ruebot: I think that does seem to make more sense, given the lateness and the "orthogonality" of the themes.
<ruebot>(if folks are willing and able)
<escowles>ruebot ajs6f: i'm trying to find someone to start the readytalk line - awoods and dwilcox are traveling today10:38
but a special topics hangout sounds fine too
<ajs6f>escowles: I don't know how to do that— sorry....10:39
<escowles>also, i setup a stub agenda: https://wiki.duraspace.org/display/FF/2015-04-02+-+Fedora+Tech+Meeting
<ruebot>escowles: i'm in skype chat with dwilcox
i could just tell him to do it :-)
<escowles>ajs6f: yep, i think it's only duraspace people who know the passcode...
<ruebot>"David Wilcox: Yeah I posted in the DuraSpace Skype chat about it - trying to find someone to start the call now"10:40
* dwilcox joins10:42
* acoburn leaves
<dwilcox>Ok, someone from DuraSpace will start the Fedora Tech call at 11am ET, so we can proceed as normal (though awoods and I will not be able to attend as we are on the road)10:43
<escowles>dwilcox: thanks!
<dwilcox>escowles: No problem - glad we caught that in time!10:44
<f4jenkins>Project fcrepo4-T2 build #193: UNSTABLE in 4 min 14 sec: http://jenkins.fcrepo.org/job/fcrepo4-T2/193/10:52
* escowles: Adding userID and userAgent to events
* escowles: Renaming setUpJMSBaseURIs to setUpJMSInfo, narrowing exception handling, and using Gson instead of building JSON as a string
<barmintor>something weird and buzzy on the line10:58
<barmintor>afk just a sec11:11
<mikeAtUVa>ajs6f: ruebot: yeah, I can call to talk about stuff... when?11:12
<ruebot>mikeAtUVa: https://wiki.duraspace.org/display/FF/2015-04-02+-+Fedora+Tech+Meeting
<barmintor>ok sorry11:13
<mikeAtUVa>ruebot; oh, didn't htink there'd be one today...
<dhlamb>i know a fair bit
you can always bug me
<ruebot>mikeAtUVa: yeah, none of did until about 15 minutes before the call :-)11:14
<barmintor>the call went silent11:17
did I drop?
<ruebot>you dropped
* barmintor redials11:18
<ruebot>mikeAtUVa: I realized this week that we should probably check-in more often on the migration-utils work.
<mikeAtUVa>ruebot: alright... I'm on the call... we could bring it up now on that channel, or schedule something using whatever, whenever works for you.
<ruebot>mikeAtUVa: cool
<barmintor>(I am back)11:20
<ruebot>Here is the XACML setup I was referring to: https://gist.github.com/ruebot/f01123e4725ca0f452ee11:23
<barmintor>thanks escowles11:24
a+ moderation
* dwilcox leaves11:28
<barmintor>Université Laval11:43
ruebot: do you know that shop? ^^11:44
<ruebot>Université Laval - I know some of the labour folks from the CAUT side of things, but not the repository side of things.11:45
* ajs6f leaves12:21
* osmandin leaves
* acoburn joins13:23
* github-ff joins13:27
[fcrepo4] escowles created event-IT (+1 new commit): http://git.io/veJEB
fcrepo4/event-IT 257994a Esmé Cowles: Expanding IT to cover all audit event types except fixity
* github-ff leaves
* github-ff joins13:29
[fcrepo4] escowles opened pull request #762: Expanding IT to cover all audit event types except fixity (master...event-IT) http://git.io/veJu4
* github-ff leaves
* travis-ci joins13:43
fcrepo4/fcrepo4#3520 (event-IT - 257994a : Esmé Cowles): The build passed.
Change view : https://github.com/fcrepo4/fcrepo4/commit/257994a97931
Build details : http://travis-ci.org/fcrepo4/fcrepo4/builds/56917802
* travis-ci leaves
<ruebot>mikeAtUVa: I have the TravisCI stuff almost ready for a pull request. We'll just need somebody with fcrepo4-labs GitHub Organization authority to click the switch in TravisCI.13:46
<mikeAtUVa>ruebot: I should be able to do that... where do I go?13:47
<ruebot>mikeAtUVa: I also have a Fedora iCLA
Click on the Organization
Then click "Sync" up at the top
Then click on the little switch thing (Green check or Grey X) for the repo to turn it on13:49
<mikeAtUVa>ruebot: there's already a green check beside fcrepo4-labs...
Do I need to add the Travis CI service in the fcrepo4-labs/migration-utils project in github?13:50
<ruebot>Ah, if it is already green, then we just need to merge the PR that has the .travis.yml in it, and then it'll start triggering builds after that.13:51
I just cribbed from the fcrepo4 travis config file. If we need to tweak those settings, we can do that after we merge, so then I'll trigger a build if I do another pull request.13:53
<dhlamb>any way to get more detailed information from fedora when issuing a sparql query? all i'm getting is "bad request"13:57
what i've got runs fine in the update properties text area on the page, but fails when running programatically and i'm wondering if i can try and pin down what the issue is
<mikeAtUVa>dhlamb: I would have suggested you enter the query in the web-ui to see the error... perhaps your URL or method or headers are wrong...14:01
<escowles>dhlamb: i'm doing bad sparql updates on the command line and getting error messages like "Lexical error at line 1, column 61. Encountered: " " ..."14:02
<dhlamb>ok, all i've got is the actual delete and insert blocks, not the full message, so there could be differences
<escowles>but the error handling might depend on how it's failing -- can you give me a sample update command?14:03
<mikeAtUVa>dhlamb: BasicObjectVersion handler has example code to build a sparql update query and send it off to fedora are you using a similar pattern?
<mikeAtUVa>dhlamb: you can output the String ((sparqlUpdate.toString("UTF-8")) to a log or something so you can see the command it generates and test it in the UI or run it by us.14:04
<dhlamb>ok, cool
was just outputting the toString, but not adding the utf-8 when debugging
let me see if that changes things14:05
{ ?s <http://purl.org/dc/terms/identifier> ?o . ?s <http://purl.org/dc/terms/title> ?o . ?s <http://fedora.info/definitions/1/0/access/objState> ?o . ?s <http://www.loc.gov/premis/rdf/v1#hasDateCreatedByApplication> ?o . ?s <http://www.loc.gov/premis/rdf/v1#formatDesignation> ?o .
} ;
INSERT DATA { <> <http://purl.org/dc/terms/identifier> "AUDIT" . <> <http://purl.org/dc/terms/title> "Audit Trail for this object" . <> <http://fedora.info/definitions/1/0/access/objState> "A" . <> <http://www.loc.gov/premis/rdf/v1#hasDateCreatedByApplication> "2015-01-27T19:07:33.120Z"^^<http://www.w3.org/2001/XMLSchema#dateTime> .
<> <http://www.lo.gov/premis/rdf/v1#formatDesignation> "info:fedora/afedora-system:format/xml.fedora.audit" .
mikeAtUVa escowles: I tried deleting properties that don't exist yet and dropping the subject variables in DELETE for <>, but no dice
how are you running on the command line? just using curl?14:10
<mikeAtUVa>dhlamb: that command works fine for me on a freshly created object in fedora 4... what's the java line you use to execute it?14:15
* dwilcox joins14:16
<mikeAtUVa>dhlamb: ooh... maybe fcrepo4-client doesn't work to update properties on a datastream, I know there were some gyrations relating to the semantics of that operation... escowles, do you use fcrepo4-client to update properties on a nonRdf resource?
<escowles>mikeAtUVa: no, i don't think so (in fact i'm not using fcrepo4-client for my main ingest work now)14:22
<mikeAtUVa>dhlamb: yeah:( it looks like that might be the issue... to update properties of a non-rdf-resource (datastream) one must PATCH to "path/to/datastream/fcr:metadata)
<escowles>mikeAtUVa: should be easy to implement that, right?
<mikeAtUVa>escowles: in your opinion is it worth trying to fix and use fcrepo4-client or should we throw it away?
escowles: there's a little chunk of work to make integration tests, then more work to add missing features. What are you using instead? Just writing the HTTP code yourself?14:23
<escowles>mikeAtUVa: i'm conflicted: i think it would be great to fix it, but i wasn't willing to do it all by myself
mikeAtUVa: yes, just plain httpclient14:24
the basic problem is that fcrepo4-client does a bunch of extra stuff to maintain state (like getting the RDF of an object after each update) that really slow it down for batch ingest
<mikeAtUVa>escowles: we should fix it then... we're close enough to complete for the migration-utils project, I can submit fixes for the stuff that doesn't work and eventually add the integration tests.
<dhlamb>escowles, mikeAtUVa: i can pitch in, too14:25
<escowles>mikeAtUVa++ that sounds great
<mikeAtUVa>escowles: hmm... that would likely be a big downside in our use of it in the migration-utils as well.
<escowles>mikeAtUVa: right -- i thought about adding some config to turn that off or make it lazy-loaded
<mikeAtUVa>escowles: it wouldn't be to hard to make some void-returning update methods, would it?
<escowles>mikeAtUVa: it might make sense to make it more stateless -- separate methods for updating and getting the status14:26
so if you want to update your local status after an update, you'd need to do that explicitly
<dhlamb>our tuque library ends up being super chatty because of the same scenario14:27
part of why we're moving to being almost completely functional using the camel component14:28
<mikeAtUVa>escowles: I think i can make the necessary changes and make it performant... it's not super complex, but I don't want to hold up dhlamb.
dhlamb: I can give you a block of code that will perform that update and you can just stuff it in a method for now if you want (with a TODO message indicating that we need to move the fix into fcrepo4-client, something I'll do ASAP)..14:29
<dhlamb>mikeAtUVa: sounds fine
mikeAtUVa: plug the hole and keep moving :D
<mikeAtUVa>dhlamb: or you could leave the code as is, assume it'll work when we fix the client and know it doesn't work yet.14:30
That would be unsatisfying for your testing...
<dhlamb>mikeAtUVa: how long do you think it will take to make the PATCH?14:31
mikeAtUVa: i can wait a bit, but if it won't happen til later in the week, i'll just manually hit the url and move on until you get enough time14:32
*later next week
<mikeAtUVa>I can get a PR in to fix fcrepo4-client this week.14:33
<dhlamb>mikeAtUVa: that's cool. you working friday?
* dwilcox leaves
<dhlamb>figured most everyone would have that off14:34
<mikeAtUVa>dhlamb: yeah, mostly on other stuff though, but it's important to maintain momentum on this, and give awodos time to review the PR...
<dhlamb>mikeAtUVa: that's cool. i'm almost done for hte day and won't be back til monday, so it'll be fine for now14:35
<mikeAtUVa>dhlamb: good good. Thanks again for working on this! We'll bring both these projects up to snuff in no time.14:36
<dhlamb>mikeAtUVa: no worries. sorry for blowing a week going down the camel rabbit hole14:37
and don't worry about performance just yet, we'll probably eek more out of it going concurrent
<mikeAtUVa>dhlamb: it's all good...:)14:38
<acoburn>dhlamb, mikeAtUVa, escowles: if you are working on fcrepo4-client feel free to steal any code from here: https://github.com/fcrepo4/fcrepo-camel/blob/master/src/main/java/org/fcrepo/camel/FcrepoClient.java14:43
it's an entirely stateless client for fcrepo14:44
<mikeAtUVa>acoburn: good to know... typically I pilfer my code from the integration tests in the main fcrepo4 project, but this may be more concise and too the point.14:49
<acoburn>mikeAtUVa: ideally, I'd use fcrepo4-client in the camel code, but I couldn't get it to work just right. It would be nice to revisit that, though14:50
it was mostly an issue with semantics — I needed a stateless client14:51
<mikeAtUVa>acoburn: I agree... maybe I'll have time to bring it all together... the higher level APIs in fcrepo4 client could be built on your stateless core and then we'll have only one place to update next time the fedora API changes.14:52
<acoburn>mikeAtUVa: that would be great14:54
<mikeAtUVa>acoburn: sadly I won't have time to really consider that effort until nearly May.
<acoburn>mikeAtUVa: well it's good to keep this in mind14:55
<mikeAtUVa>acoburn: indeed...
* acoburn leaves14:56
<barmintor>hey does anyone know how awoods cuts the RC distros on github (for fcr 3.x)?15:17
<ruebot>mikeAtUVa: got another PR, and looks like we've successfully triggered a TravisCI build :-)15:18
mikeAtUVa: https://github.com/fcrepo4-labs/migration-utils/pull/3
<mikeAtUVa>ruebot: awesome, success! Thanks for your contribution and hand-holding. (as you can tell, I screwed it up the first time when I pulled your original PR)15:19
<ruebot>mikeAtUVa: no worries! (what'd you screw up? I didn't notice anything)15:20
<mikeAtUVa>ruebot: well, it didn't build because I merged the PR before finishing the travis set up. And apparently there's no way to trigger one manually.
<ruebot>mikeAtUVa: oh, it worked right. It need the .travis.yml before it could trigger the build. so my first pull request was a chicken and egg thing.15:21
mikeAtUVa: https://travis-ci.org/fcrepo4-labs/migration-utils/builds and we should get our fancy little green badge soon once it builds your merge commit.15:24
* travis-ci joins15:25
fcrepo4-labs/migration-utils#2 (master - 47261df : Michael Durbin): The build passed.
Change view : https://github.com/fcrepo4-labs/migration-utils/compare/a7e99cce456b...47261df78f35
Build details : http://travis-ci.org/fcrepo4-labs/migration-utils/builds/56934943
* travis-ci leaves
<dhlamb>made a ticket for the duplicate published messages for NonRDFSourceDescriptions15:28
looks like it's only for NODE_ADDED and NODE_REMOVED events
* barmintor leaves15:29
* dhlamb leaves15:44
* escowles leaves16:08
* acoburn joins16:23
* travis-ci joins16:47
fcrepo4/fcrepo-camel#153 (master - 0334c53 : Mike Durbin): The build passed.
Change view : https://github.com/fcrepo4/fcrepo-camel/compare/e039ef04d77a...0334c5329aa6
Build details : http://travis-ci.org/fcrepo4/fcrepo-camel/builds/55987328
* travis-ci leaves
* ksclarke leaves
* ksclarke joins16:48
* mikeAtUVa leaves16:59
* mikeAtUVa joins17:16
* acoburn leaves17:30
* terrellt leaves
* jgpawletko leaves17:32
* pivotal-bot_ leaves17:35
* pivotal-bot_ joins17:36
* terrellt joins17:39
* MohamedAR leaves17:53
* jgpawletko joins17:58
* jgpawletko leaves
* MohamedAR joins18:04
* jgpawletko joins18:42
* jgpawletko leaves18:45
* MohamedAR leaves19:00
* MohamedAR joins19:13
* jgpawletko joins19:15
* MohamedAR leaves19:28
* ksclarke leaves19:48
* awead leaves19:58
* MohamedAR joins20:00
* ksclarke joins20:03
* ksclarke leaves20:13
* MohamedAR leaves20:25
* ksclarke joins20:38
* jgpawletko leaves20:56
* jgpawletko joins
* MohamedAR joins21:11
* jgpawletko leaves21:14
* MohamedAR leaves21:27
* jgpawletko joins21:48
* fcrepo-bot joins22:59
* jgpawletko leaves23:15
* fcrepo-bot leaves00:04

Generated by Sualtam