Log of the #fcrepo channel on chat.freenode.net

Using timezone: Eastern Standard Time
* lsitu leaves00:27
* dwilcox joins02:42
* dwilcox leaves02:47
* dwilcox joins02:55
* dwilcox leaves02:58
* dwilcox joins06:20
* dwilcox leaves06:23
* dwilcox joins08:02
* dhlamb joins08:12
* dwilcox leaves08:46
* dhlamb leaves08:47
* benpennell joins08:54
* dwilcox joins08:59
* dhlamb joins09:00
* peichman joins09:03
* awoods joins09:06
* dwilcox leaves09:07
* dwilcox joins09:08
* yamil joins09:10
* dwilcox leaves
* bseeger joins09:14
<dhlamb>[API Alignment Standup]09:18
Finished yesterday:
Working on today:
Using 'acl:agentClass foaf:Agent' to denote public access
To some degree, WebAC needs to be enabled: https://jira.duraspace.org/browse/FCREPO-263109:19
but it's not _really_ a blocker to begin work.
<benpennell>awoods: sorry won't be able to make tech meeting today, i'm going to be out of the office at that time09:22
* mohideen joins09:28
<peichman>[API Alignment Standup]09:32
Finished yesterday:
minor cleanup of AuthNZ wiki docs https://wiki.duraspace.org/display/FEDORA4x/Authentication+and+Authorization
Working on today:
I can work on switching to acl:agentGroup/vcard:Group implementation for group lists: https://jira.duraspace.org/browse/FCREPO-2633
same as dhlamb, getting WebAC enabled in the build would be helpful, but not a complete blocker: https://jira.duraspace.org/browse/FCREPO-2631
* apb18 joins09:36
<awoods>[API Alignment Standup]09:56
Finished yesterday:
Created 5.0.0 wiki documentation space: https://wiki.duraspace.org/display/FEDORA5x
Working on today:
Creating tickets and reviewing work
* rotated8 joins09:57
[API Alignment Standup]09:58
Finished yesterday:09:59
Environment set up
Working on today:
API Delta Document CRUD verification10:00
<awoods>peichman: working on fcrepo-2633 sounds great10:01
rotated8: Since we ultimately are targeting alignment with the spec, it may make sense to walk through the Delta doc and spec together in your verification process.10:02
<rotated8>awoods: OK, can do!10:07
<awoods>rotated8++ Would it be helpful to create a new wiki page that outlines the sections of the spec?10:12
<rotated8>awoods: Yeah, that sounds like a good idea10:17
* lsitu joins10:18
<awoods>rotated8: can you create a child page under: https://wiki.duraspace.org/display/FEDORAAPI/Fedora+API+Delta+Document10:22
<lsitu>[API Alignment Standup]10:27
Finished yesterday:
Read the Versioning - Authorization Design documentation and walked through the version related tickets
Discover the current version implementation in Fedora and the version suport in ModeShape
Working on today:
Versioning - Authorization Design and implementation discussions
Look for tickets to work on
<rotated8>awoods: like this? https://wiki.duraspace.org/display/FEDORAAPI/Fedora+API+Spec+and+Delta+Document+Verification10:29
<awoods>rotated8: looks good. Then within each section, maybe add the spec section numbers as you go and indicate if they pass or not.10:30
<rotated8>awoods: Sounds good
<awoods>rotated8: It would also be helpful to include the build and version numbers of the fedora that you are verifying10:32
lsitu: do you not have any work remaining from sprint-1?10:33
dhlamb: is there a good ticket for lsitu to take now?10:34
* bhauer joins10:35
<dhlamb>awoods, i have not made a jira issue for number 5 in the AuthZ section of the Delta Doc, and I think 4 has an existing ticket10:36
awoods, I _believe_ this covers number 4 from the delta doc: https://jira.duraspace.org/browse/FCREPO-2628
<awoods>thanks dhlamb. Yes, fcrepo-2628 should cover #4 in the AuthZ delta10:38
dhlamb: Would you mind creating a ticket for #5?10:39
<mohideen>[API Alignment Standup]
Finished yesterday:
Read the versioning docs and looked into codebase for making implementation decisions.
Working on today:
I will meet with Jared and Longshou at noon today to get started with the versioning implementation.
<dhlamb>awoods, np
<dhlamb>awoods, btw, I don't appear to have perms to assign jira issues to the sprint10:40
awoods, I can add them to the epic, but not the sprint
<awoods>dhlamb: I will do that, sorry for the trouble
<rotated8>awoods: Where do I get the build and version numbers? I was thinking of using the commit sha.10:43
<awoods>rotated8: For example, see the bottom-right of the splash page: http://demo.fcrepo.org:8080/fcrepo/10:44
rotated8: Are you using the one-click? or mvn jetty:run?
<rotated8>awoods:mvn jetty:run10:45
<awoods>rotated8: the values are blank with 'mvn jetty:run' :(10:46
rotated8: can you try the following...10:47
rotated8: mvn clean install -pl fcrepo-webapp -Pone-click
followed by:
java -jar fcrepo-webapp/target/fcrepo-webapp-5.0.0-SNAPSHOT-jetty-console.jar --headless10:49
rotated8: if you do that, the values will be on the splash page
<rotated8>awoods: ok. The first command is running. I'll let you know if I have problems10:50
<awoods>rotated8: please let me know either way ;)
rotated8: basically, the first command does a build that creates the one-click fedora
rotated8: the second command simply runs the one-click10:51
<rotated8>awoods: Release: 5.0.0-SNAPSHOT | Build #30b6e16f (2017-09-28)10:53
Ah! The build is the SHA!
<awoods>rotated8: awesome. I am glad that went smoothly.
<lsitu>awoods: I have a PR need review https://github.com/fcrepo4/fcrepo4/pull/1238.10:54
And I am working on ticket https://jira.duraspace.org/browse/FCREPO-2628 Change userAgent references in FedoraSession to userURI now.
<awoods>lsitu++ sounds like you are good for now.
<lsitu>Yes. Just for now.10:55
<f4jenkins>Project fcrepo-import-export build #1: SUCCESS in 3 min 24 sec: http://jenkins.fcrepo.org/job/fcrepo-import-export/1/10:56
* whikloj joins10:58
* benpennell leaves
* whikloj prepares for mastering of the star11:01
* escowles joins11:02
* escowles is here
* apb18 is here
* dhlamb is here
<whikloj>double dhlamb11:03
* tolloid joins11:08
<dbernstein>[API Alignment Standup]
Finished yesterday: ----
Working on today:
wrapping up https://jira.duraspace.org/browse/FCREPO-2631
Enable WebAC by default
Create deploy-time on/off switch for webac.
The above is almost done: I’m having difficulty getting the one click to recognize the jetty.xml config.
<whikloj>bseeger++ benpennell++11:10
<bseeger>that's my understanding, too11:13
that's where the orig. design was going, but I don't think I've mapped it out well and I'm sure all you sprint 2 sprinters will do a great job with it. :)11:14
(regarding the ACL stuff ^^)
<dhlamb>dbernstein, I'm still getting oriented with the codebase, so you've still got time before really blocking me11:17
<dbernstein>dhlamb++ good to know.11:18
<peichman>likewise for me
* westgard joins11:22
<dhlamb>peichman, awoods that's my understanding as well
<escowles>yes, that's my understanding — replacing with agentGroup11:23
<peichman>sounds good to me11:28
<apb18>My own gut feeling is narrowing the scope. It sounds useful for organizing resources in bags, or other scenarios that specifically use a file/hierarchy as a mechanism of transferring or reasoning about content11:34
<dhlamb>AFAIC, this is at too low of a level for me to care about. I really don't want/need to know how it's arranged on disk, but how I can get it from the API. Building apps to work together at this level would be akin to integrating at the db level instead of using the api.11:36
<escowles>apb18++ i think this makes sense in the import/export context (and synchronous export sounds interesting)11:37
<dhlamb>apb18, yeah... use at your own risk. i can see why people want this, but I wouldn't use it unless I felt it was absolutely neccessary11:38
<bseeger>yes, I agree with everything apb18 just said11:41
<whikloj>Fedora as files on disk, everything else is gravy11:48
<dhlamb>that does feel in line with what people loved about fedora 3
<bseeger>we do offer that if you use the camel toolbox. bonus that you're not mucking with potentially 'live' data when you look at the data on the disk.
<dhlamb>awoods++ bseeger++
folks would definitely like that11:50
<escowles>i think it would be possible to make a fedora spec impl. that stored everything as files on disk11:52
<whikloj>escowles++ # You do you11:54
<escowles>it seems like this could be a good sidecar spec, if there are enough people interested in implementing and using this with different implementations11:58
<whikloj>escowles++ awoods ^^12:00
* tolloid leaves12:03
* rotated8 leaves12:07
* bhauer leaves12:08
* rotated8 joins12:21
* westgard leaves
* westgard1 joins
* bseeger leaves12:28
* tolloid joins12:29
<awoods>whikloj: https://github.com/fcrepo/fcrepo-specification/issues/23812:39
<dbernstein>awoods: I’m basically there onf https://jira.duraspace.org/browse/FCREPO-2631. I’m having trouble getting the jetty console jar to work without passing in a —jettyXml param. Thus the “one click” no longer works: a command line call is required: “java -jar fcrepo-jetty-console.jar —jettyXml src/test/resources/jetty-one-click.xml12:48
Just wanted to get a read from you on how imporant the “click” aspect is.
<awoods>dbernstein: on a call. Let's see the PR... I can give it a look.12:54
<dbernstein>okay - I’ll push it up.
* lsitu leaves
* lsitu joins
* ddavis joins12:56
* bseeger joins13:00
<mohideen>awoods: I will create a jira ticket to create the new branch and to remove the existing versioning code. I guess there is no ticket for it yet.13:05
oooh, always find something with SSL13:22
<dbernstein>awoods: ran into a little snag with the PR. I need to step out for a 1/2 hour. will push it when I return.13:26
<awoods>dbernstein: ok13:27
<dhlamb>way more rational++13:32
apb18, sounds good, i'll see what I can do on the CLAW end of things13:39
<mohideen>awoods: I created "memento-versioning" branch from master, but I am not able to push the new branch to fcrepo4 github. I guess I don't have the permissions.13:41
<awoods>mohideen: can you create a PR?
<mohideen>awoods: I don't have any changes in it yet. I just wanted to have the branch in place to issue PRs to. If you can create the branch "memento-versioning", I will issue the PR against that new branch when I am done cleaning the code.13:47
* github-ff joins13:48
[fcrepo4] awoods created memento-versioning from master (+0 new commits): https://git.io/vdOSB
* github-ff leaves
<f4jenkins>Project fcrepo4 build #3727: FAILURE in 10 min: http://jenkins.fcrepo.org/job/fcrepo4/3727/13:58
<dhlamb>apb18, i'm firing up a claw-playbook with karaf 4.1.2 right now. i'll let you know how it goes.14:00
<apb18>fantastic! fingers crossed
* bryjbrown joins14:01
* ddavis leaves14:03
* mohideen leaves14:05
* travis-ci joins14:08
fcrepo4/fcrepo4#5172 (memento-versioning - 30b6e16 : dbernstein): The build passed.
Change view : https://github.com/fcrepo4/fcrepo4/compare/memento-versioning
Build details : https://travis-ci.org/fcrepo4/fcrepo4/builds/280977452
* travis-ci leaves
<f4jenkins>Yippee, build fixed!14:10
Project fcrepo4 build #3728: FIXED in 10 min: http://jenkins.fcrepo.org/job/fcrepo4/3728/
* mohideen joins14:15
* benpennell joins14:22
<whikloj>awoods: Sorry missed the standup before the call. here it is14:31
[API Alignment Standup]
Finished yesterday:
- Lots of reading and chatting around versioning design and how it might work in Modeshape Impl14:32
Working on today:
- Lots of reading, chatting and starting to document possible paths of implementation
- None
* github-ff joins14:33
[fcrepo-import-export] awoods pushed 1 new commit to master: https://git.io/vdOd9
fcrepo-import-export/master 777f564 Mike Durbin: Updated bag generation to conform to APTrust specifications.
* github-ff leaves
<lsitu>awoods: Any ideas in customize Fedora CND with the example from Modeshape for sigle resource(ignored child nodes) versioning https://github.com/ModeShape/modeshape/blob/master/modeshape-jcr/src/test/resources/cnd/versioning.cnd?14:34
<awoods>lsitu: we have found in the past that making updates to the CND file often results in legacy installation breakage... but that said, I suspect we will need to change the type applied here: https://github.com/fcrepo4/fcrepo4/blob/master/fcrepo-kernel-modeshape/src/main/java/org/fcrepo/kernel/modeshape/services/VersionServiceImpl.java#L16414:39
* tolloid leaves
<awoods>lsitu: have you ready through section 15 of: https://docs.adobe.com/content/docs/en/spec/pdf/jcr-spec.pdf14:40
<lsitu>awoods: Not read it through yet. But I will.14:41
* tolloid joins14:43
* dhlamb leaves14:51
* bryjbrown leaves14:52
* dhlamb joins14:54
* westgard1 leaves15:00
* westgard1 joins15:01
<peichman>when running the integration tests for WebAC at the master branch, I am getting 14 test failures (all 409 or 403 responses where it was expecting 2xx responses)15:02
does anyone else see this, or is it something peculiar to my setup?
I run mvn test verify in fcrepo-auth-webac, and get:15:03
Failed tests:
WebACRecipesIT.scenario1:164->ingestObj:119 expected:<201> but was:<409>
WebACRecipesIT.scenario2:198->ingestObj:119 expected:<201> but was:<409>
WebACRecipesIT.scenario3:232->ingestObj:119 expected:<201> but was:<409>
WebACRecipesIT.scenario4:262->ingestObj:119 expected:<201> but was:<409>
WebACRecipesIT.scenario5:342->ingestObj:119 expected:<201> but was:<409>
WebACRecipesIT.scenario9:382->ingestObj:119 expected:<201> but was:<409>
WebACRecipesIT.testAccessByUriToVersionedResources:594->ingestObj:119 expected:<201> but was:<409>
WebACRecipesIT.testAccessToBinary:464->ingestObj:119 expected:<201> but was:<409>
WebACRecipesIT.testAccessToRoot:428 expected:<403> but was:<200>
WebACRecipesIT.testAccessToVersionedResources:508->ingestObj:119 expected:<201> but was:<409>
WebACRecipesIT.testDelegatedUserAccess:541->ingestObj:119 expected:<201> but was:<409>
WebACRecipesIT.testDeletePropertyAsUser:732->ingestObj:119 expected:<201> but was:<409>
WebACRecipesIT.testRegisterNamespace:696->ingestObj:119 expected:<201> but was:<409>
* peichman leaves
* peichman joins
<whikloj>peichman: I haven't tried but as WebAC is not enabled yet, that probably makes sense...I think15:05
* bseeger leaves
<peichman>whikloj: even though it is happening when running the WebAC modules own integration tests? I'd expect those to spin up a repo with WebAC enabled15:07
<whikloj>peichman: I think it still relies on the webapp-plus, but I'd have to look at it. Let me try and run it now
in the meantime, I have code and updated unit tests (that are all passing) for the switch from acl:agentClass to acl:agentGroup15:09
if we determine the failing integration tests are unrelated, i can go ahead and package it up in a PR
* manez leaves15:11
* manez joins15:13
* mohideen leaves15:21
<awoods>peichman: I am able to reproduce the error you seen when running "mvn test verify" from within the fcrepo-auth-webac directory; however...15:22
when running "mvn clean install", all is well.
<peichman>awoods: cool, I will go ahead on the assumption that I didn't break anything in my changes for the ACL groups, and issue that PR :-)15:23
(the unit tests pass fine)
<awoods>peichman: also, "mvn clean test verify" seems to work.
<whikloj>peichman: The first 409 seems to be because when running that test I already have a resource at that URI before I ingest it
* bseeger joins15:24
* bseeger leaves
* bseeger joins
<whikloj>awoods++ # It was leaving stuff in the fcrepo4-data directory I think
<peichman>awoods, whikloj: "mvn clean test verify" is succeeding for me too15:25
* mohideen joins15:33
* github-ff joins15:36
[fcrepo4] peichman-umd opened pull request #1245: Change groups from acl:agentClass to acl:agentGroup (master...FCREPO-2633) https://git.io/vdOjc
* github-ff leaves
* westgard1 leaves15:41
* tolloid leaves15:44
* tolloid joins15:45
* tolloid leaves15:46
* yamil leaves15:48
* tolloid joins15:50
* tolloid leaves
* westgard1 joins15:54
* github-ff joins15:57
[fcrepo4] dbernstein opened pull request #1246: Enables WebAC by default. (master...fcrepo-2631) https://git.io/vd3fn
* github-ff leaves
<awoods>dbernstein: please add a link to your PR in: https://jira.duraspace.org/browse/FCREPO-263115:59
<dbernstein>yup - on it.
* bseeger leaves16:01
* bseeger joins16:07
<whikloj>benpennell: Regarding https://jira.duraspace.org/browse/FCREPO-2614 I still don't see where in the spec it says that a GET/HEAD request to a URI-M must return a Content-Location header pointing at itself. Or am I misunderstanding part of that ticket?16:42
<benpennell>whikloj: i'm not really sure i can add much else other than the comments on the ticket and my interpretation could be wrong (it was many times while going through all the specs). I interpret receiving a memento either by uri-m or uri-g with datetime negotiation as returning the memento in 4.1.2. The example linked to and text at the beginning of the section describes returning a content-location. there is no distinction made about16:50
ther the memento's headers should vary depending on how its retrieved. But i recognize that the header seems redundant on a uri-m request, and that that section is describing datetime negotiation.
so if you would prefer to drop it for uri-m requests that is probably reasonable. that is why i was suggesting asking the memento people16:51
<whikloj>benpennell: yeah I can't believe I'm saying this, but I wish there was more normative text in that instead of a bunch of example patterns
<benpennell>whikloj: yes, it leaves a lot to the imagination :)16:52
<whikloj>benpennell: ok, I just wanted to make sure I wasn't just missing an obvious statement. Lets leave that for Tuesday16:53
<benpennell>i find it kind of weird that 4.1.2 doesn't mention the Content-Location header in the list of MUSTs, its just in the opening paragraph of the section as a thing which is going to show up in the example16:54
<whikloj>benpennell: I think that is because if you do a 200 response you return a Content-Location, if you do a 302 response you return Location16:55
not sure why the difference
actually the difference is if you do a 302 then you never provide the URI-M body while negotiating the URI-R. Maybe we should do that?16:57
> In a subsequent request, shown in Figure 6, the user agent can obtain the selected Memento by issuing an HTTP GET request against the URI-M that was provided in the "Location" header.16:58
<benpennell>whikloj: i don't have a strong opinion on whether to use 4.1.1 or 4.1.2, I think any of the 4.1 approaches would work with fcrepo's specification. 4.1.1 seems slightly inconvenient since it requires to API calls to get a memento, but if there are compelling reasons to go that route than it should be proposed.17:01
<whikloj>benpennell: I'm just wondering about the API's use of Content-Location for external content
This could alleviate that overlap17:02
* bseeger leaves
* mohideen leaves17:04
<benpennell>whikloj: yes that's true. I think it is another good topic to bring up on tuesday if that's not hampering your ability to make progress
<whikloj>benpennell: no problem, once the information is retrievable how we retrieve it should be easier to manipulate.17:05
and we best get it right now :)17:06
* peichman leaves17:15
* westgard1 leaves17:24
* rotated8 leaves17:30
* dwilcox joins17:32
* dwilcox leaves17:36
* github-ff joins17:39
[fcrepo4] lsitu opened pull request #1247: Renamed signature UserAgent to UserURI and use constant for user base uri environment variable setting. (master...feature/useruri) https://git.io/vd33y
* github-ff leaves
* benpennell leaves17:45
* whikloj leaves17:53
* dwilcox joins17:55
* dhlamb leaves18:00
* dwilcox leaves18:08
* apb18 leaves19:34
* escowles_ joins21:27
* escowles leaves21:30
* awoods leaves23:58

Generated by Sualtam