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

Using timezone: Eastern Standard Time
* github-ff joins07:29
[fcrepo-camel-toolbox] ruebot opened pull request #50: Updates for migrating from standalone Fuseki to fuseki.war. Address F… (master...FCREPO-1467) http://git.io/vs9aP
* github-ff leaves
* dwilcox joins07:54
* esm_ joins08:30
* dhlamb joins08:32
* whikloj joins08:58
<ruebot>awoods: should we list the PCDM committers on the PCDM wiki?09:07
awoods: i ask, because i think the only place that it is specified is in the email you sent out in may... and i think that was just to fedora-tech.09:08
* ksclarke joins09:10
* acoburn joins09:13
* ksclarke leaves09:15
* MohamedAR joins09:18
<awoods>ruebot: good idea09:27
* ksclarke joins09:29
* ksclarke leaves09:33
<ajs6f>acoburn:ruebot: Do you get what I'm saying? Integration tests a) show that X is true and b) show how to do X. That means we need to lead by example.
<ruebot>ajs6f: i get what both you and acoburn are saying.09:34
<acoburn>ajs6f: I completely get that. The test is just showing point a, but not point b
<whikloj>ajs6f: I'm lost in a sea of misinformation
<ajs6f>acoburn: Yeah. If ruebot put it in another ticket, fine with me, as long as we get it done.09:35
whikloj: Just don't drink the water. It will only make you thirstier.
<whikloj>ajs6f: really? or is this a trick too?
<ruebot>awoods: done. https://github.com/duraspace/pcdm/wiki/PCDM-Committers09:36
<ajs6f>whikloj: No, these are tricks: https://www.youtube.com/watch?v=AliNpkkBvas
<ruebot>ajs6f: https://jira.duraspace.org/browse/FCREPO-170809:37
* osmandin joins
<awoods>ruebot++ on the PCDM
* jgpawletko joins09:41
* ksclarke joins09:49
* awead leaves10:31
* peichman joins10:33
* awead joins10:34
<acoburn>awoods: peichman: MohamedAR: whikloj posted this in the islandora channel. I'm copying it here10:38
(stand-up) edited design doc yesterday. Proposed req irc://chat.freenode.net:6667/#5 is open (I think) for discussion. Also found a Hydra WebAC doc with a bunch of suggested examples linked from https://wiki.duraspace.org/display/FF/Design+-+Authorization+-+Authentication. I'll be back (hopefully) by noon ET. Assign me something if you need.
<awoods>acoburn? no Google-Hangout?
<acoburn>awoods: on the contrary. whikloj had a dr appt and won't make it10:39
awoods: so I asked him to post a standup report before 1110:40
<awoods>acoburn: I saw that... but did not know until now that the hangout was cancelled.
<acoburn>awoods: who cancelled the hangout?
awoods: my understanding is that the hangout is still happening10:41
<awoods>acoburn: ok, I misunderstood your comment above
acoburn: is pull/1 building for you?
acoburn: fcrepo-module-auth-webac10:42
<acoburn>awoods: I haven't tried it yet
awoods: it builds for me10:44
<awoods>acoburn: not if you remove your local .m2 repo10:45
* pgwillia joins
<awoods>acoburn... which can be resolved with: https://jira.duraspace.org/browse/FCREPO-168410:47
<acoburn>awoods: looks like that repositories section is needed10:48
awoods: yes, I'm working on that
<awoods>acoburn: actually, I would rather that be provided by the parent
<acoburn>awoods: I agree. shall we wait on merging this until fcrepo-1684 is finished? I'm almost done10:49
awoods: meaning that I'll finish after our standup meeting
<awoods>acoburn: we can merge... and 1684 will just make it better.
acoburn: like you said, this PR builds now, if you have a populated local .m210:50
<acoburn>awoods: right, but travis won't succeed10:51
<awoods>acoburn: true
acoburn: but the sprint is waiting on this initial structure
<acoburn>awoods: yes, I'm inclined to just merge this and move on10:52
awoods: I need it in order to add the integration tests
<awoods>acoburn: yes. Do you have time to squash/merge?
<acoburn>awoods: I can do that
<awoods>acoburn: great
* pgwillia leaves11:20
* ksclarke leaves11:25
* ksclarke joins
* awead leaves11:29
* awead joins11:43
* dwilcox leaves11:51
* ajs6f leaves12:12
* esm_ leaves12:21
* dwilcox joins12:22
* awead leaves12:28
<whikloj>acoburn: sorry for posting in the wrong channel12:46
<acoburn>whikloj: no problem!12:47
* dwilcox leaves
* dwilcox joins12:48
<whikloj>acoburn: you asked for accessors for a "set of RDF classes", was there a vision for this? You want RDF file in and Model out or set of Models/RDFNodes/etc in12:50
<acoburn>whikloj: you get to implement this, so I'll defer to you on the initial design.12:52
whikloj: Basically, the ACL class would model the kinds of data that would be useful in that context
whikloj: but there definitely should be a static method that accepts a FedoraResource and returns one of these ACL classes12:53
* awead joins
<acoburn>whikloj: just be sure only to use the org.fcrepo.kernel.api classes
whikloj: if you find yourself reaching for anything that has modeshape or jcr in it, you're going in the wrong direction12:54
<whikloj>acoburn: how about jena?
<acoburn>whikloj: I don't think you should need that12:55
<whikloj>acoburn: hmm yeah, I got a path to follow. I'll see where I end up.12:56
<acoburn>whikloj: I take that back about jcr, you may need to use javax.jcr.Property
whikloj: although it's probably better to use the getTriples method on FedoraResource and then use the o.f.k.i.utils.iterators.RdfStream class12:58
whikloj: that is: org.fcrepo.kernel.api.utils.iterators.RdfStream12:59
<whikloj>acoburn: yeah, so you want to pass in the ACL FedoraResource and get able to alter the groups, users and permissions. And the static method13:00
<acoburn>whikloj: yes, and you will definitely need some jena code for handling Triples in the RdfStream13:01
<whikloj>acoburn: are we build a Constants class for namespace stuff, like https://github.com/fcrepo4/fcrepo-module-auth-xacml/blob/master/src/main/java/org/fcrepo/auth/xacml/URIConstants.java13:03
<acoburn>whikloj: I assume, at the very least, we will want a constant value for the WebAC namespace13:04
* esm_ joins13:08
hey all, quick question (from someone who doesn't have full understanding of LDP or Fedora 4): our experimentation leads us to believe that we cannot insert PREMIS hasFixity or hasFormat statements into LDP RDF containers. Is this expected behavior, and is it by design?
<awoods>esm_: can you provide an example sparql-update that is failing?13:09
* ksclarke leaves13:10
* ksclarke joins
<esm_>awoods: sec... getting a colleague to pass it over to me13:12
<peichman>@acoburn, @whikloj I had almost the same question, for what I'm working on it would be good to have constants for the WebAC-defined modes (Read, Write)
<acoburn>peichman: whikloj: if one of you wants to submit an initial PR with a constants class, that would be great. Then we can add to it as needed13:13
<whikloj>peichman: you or me?13:14
<peichman>@whikloj I can take
<esm_>awoods: https://s3.amazonaws.com/uploads.hipchat.com/267943/1716525/5cfgR9Zs70FjXrY/sparql2 (note that the urls won't be retrievable from outside hopkins)
<whikloj>all: what about Update and Delete as they are not part of the WebAC spec?13:15
<esm_>awoods: curl -v -# -X PATCH -H "Content-Type: application/sparql-update" --data-binary "@-"  http://fedora4.mse.jhu.edu:8080/fcrepo/rest/levypremis/100.049/binarymetadata/100.049.pdf < sparql2
awoods: fails with Could not persist triple containing predicate http://www.loc.gov/premis/rdf/v1#hasSize to node /.well-known/genid/16/1c/dc/c9/161cdcc9-29c7-4e94-a738-5203c77c27d7
awoods: and if you take out the hasFixity and hasFormats predicates the update succeeds
<acoburn>whikloj: the ACL class should just return what's part of the spec. For Update/Delete, an upstream class will map that to the ACL categories13:21
<awoods>esm_: Internally, F4 uses certain premis predicates to record F4 fixity results: https://github.com/fcrepo4/fcrepo4/blob/master/fcrepo-kernel-api/src/main/java/org/fcrepo/kernel/api/RdfLexicon.java#L137
<whikloj>acoburn: ok13:22
<awoods>esm_: Those predicates are currently not available for user modification/creation.
<esm_>awoods: Ok, thanks for figuring that out! So is that an intentional design decision, then?13:23
awoods: or are we experience an unintended consequence?
<awoods>esm_: yes, that is intentional... although your scenario is certainly an argument for reassessment.13:24
<acoburn>esm_: some folks are using ebucore:fileSize for user-supplied file size data13:25
<awoods>acoburn: https://s3.amazonaws.com/uploads.hipchat.com/267943/1716525/5cfgR9Zs70FjXrY/sparql2
<acoburn>awoods: thanks13:26
awoods: are all of the premis properties considered "server managed"?13:27
<esm_>awoods: ok no worries. it seems reasonable that premis Fixity and Format objects could be deposited to the repo. I just wanted to get a read on this from the developers, thanks!
<awoods>acoburn: no
acoburn: the "fixityProperties" are considered server-managed13:28
acoburn: https://github.com/fcrepo4/fcrepo4/blob/master/fcrepo-kernel-api/src/main/java/org/fcrepo/kernel/api/RdfLexicon.java#L137
esm_: I'll add it to the Thurs tech agenda.13:29
<esm_>awoods: many thanks
<whikloj>acoburn: am I correct to say that to use the FedoraResource.getTriples I have to create my own Context to populate the triples for acl:mode, acl:agent and acl:agentClass?13:38
<awoods>whikloj: has your interface been agreed upon?13:39
whikloj: sounds like you are "implementing"13:40
<acoburn>whikloj: at this point we just want to see an interface. awoods is correct — there shouldn't be any real impl yet
<whikloj>awoods/acoburn: so you don't want a static method in the interface, cause that seems to require me to actually implement something. But INAJP13:42
<acoburn>whikloj: I'm not a java programmer
<acoburn>awoods: ^^^
whikloj: the static method is just something to keep in mind for the actual implementation
whikloj: but it's not needed yet13:44
<peichman>@acoburn: should we be creating actual Java interfaces, or just interface designs?
<acoburn>peichman: I really like having actual java interfaces, because then we can export those via OSGi and keep the implementation hidden13:46
awoods: do you have an opinion ^^^
<peichman>@acoburn: will do13:47
<awoods>acoburn: do you then like having the interfaces in org.fcrepo.some.package, and the impls in org.fcrepo.some.package.impl?
<acoburn>whikloj: and you realize of course, that inajp either?
awoods: yes
awoods: then the OSGi packager will automatically exclude the impl packages
<awoods>acoburn: right13:48
<whikloj>acoburn: yes, technically but your general brilliance makes that fact marginally irrelevant. I try to get by on looks and wit.
<peichman>another inajp here, but I am learning :-)13:49
URI constants class created, see https://github.com/fcrepo4-labs/fcrepo-module-auth-webac/pull/2
<esm_>awoods: a process/community question: what is your (or this groups) reaction to a Slack channel for the Fedora 4 API Extensions work?13:53
<awoods>esm_: It seems like IRC provides more transparency, no?13:54
<acoburn>awoods: so long as the logger is alive; otherwise I'd say the same for slack13:55
<esm_>awoods: the discussions here are often low-level and not relevant to everyone who may be participating and/or they may find it intimidating to communicate with developers or cumbersome to communicate
awoods: slack logs; i don't think it is any less transparent
<acoburn>esm_ awoods: slack is definitely _not_ cumbersome
<esm_>awoods: the deal is, irc is ok but slack is awesome.13:56
<esm_>awoods: and their interface is much easier to use for the level of user who is putting together use cases for API-X
<awoods>esm_/acoburn: My experience with slack is that the channels are not public. Is that not the case?
<esm_>awoods: but that being said, I understand the desire to keep it all on irc. I think you can make them public. I'm happy to research and let you know.13:57
awoods: in a way, slack fits your chat model too. because you can have 'rooms' for core development, one for webac development, api-x discussion, etc.
<acoburn>awoods: I've never used a _public_ slack channel (if such a thing exists), but it's also really easy to add people
awoods: it would just need to be made clear that anyone can join13:58
<awoods>acoburn: the fact is, conversation would get lost.
<esm_>awoods: not trying to rock the boat ;) I'll look into the options slack offers and get back to you and discuss from there.
<awoods>acoburn/esm_: is the main argument against IRC the intimidation factor?13:59
<acoburn>awoods: esm_: https://github.com/ekmartin/slack-irc
you can have your cake and eat it, too
<esm_>awoods: intimidation of the interface, and intimidation of the poplation.
(yes there are bots that can put messages in both)14:00
and, the fact is, slack's history searching is much better than irc
<awoods>esm_: re: history, true
<esm_>I would say that they will start to charge you for managing your history if it gets large enough.
sharing of text snippets, images, etc.14:01
much nicer
starring messages is nice (e.g. you can star messages to keep track of a todo list, or to keep a link to a document handy)
jira bot integration14:02
anyway :)
i know that bifurcating any communications within the community isn't something to be taken lightly14:03
<ruebot>fwiw, folks have been asking about having an #islandora slack instance.14:05
dare i say clamouring for?
<esm_>how dare you!14:06
* esm_ mock indignation
* ajs6f joins14:20
acoburn:awoods: That was the wrong answer about that helper class. See my comment to the branch, if you cn see it after the branch has been deleted.14:21
<whikloj>awoods/acoburn: are we using the mixin type to define our accessToClass?
* ajs6f1 joins
<acoburn>ajs6f: I agree with you here, and I expect that peichman will submit another PR in a few minutes changing this to a normal class with a private constructor14:22
<acoburn>whikloj: aren't we using rdf:type?
<ajs6f1>whikloj: PLEASE be using rdf:type.14:23
* ajs6f leaves
<whikloj>acoburn: oh maybe that was it
<whikloj>ajs6f1: yes yes it definitely was rdf:type. Don't worry
<peichman>@acoburn: new PR for private constructor14:28
<acoburn>ajs6f1: do you hold the opinion that private constructors should follow class (static) variables?14:31
<ajs6f1>acoburn: No, I don't much care about that. I use an IDE that outlines things in whatever order I want, anyway.14:38
acoburn: But in this case, where the constructor carries almost no meaning, I can see why you'd rather have it away.14:39
<acoburn>ajs6f1: I don't have a strong opinion on that either, but it looks like peichman has already updated his PR14:40
<ajs6f1>acoburn: Then it's cool, eh?
<acoburn>ajs6f1: yep, all set14:41
<ajs6f1>aoburn: I wonder if that can be packed into code formatters.
<peichman>@ajs6f1 that would be very helpful
<ajs6f1>peichman: Open an issue, eh?
<acoburn>ajs6f1: peichman: I think sonar reports something related to that, but it would be nice if it was part of the checkstyle rules14:42
<peichman>@acoburn: to be clear here, are we talking about the private vs. public constructor, or the location of the constructor code in the source?14:44
<acoburn>peichman: we're nit picking about the location of the constructor in the class decl14:45
peichman: as far as I'm concerned, it's a very minor point
<peichman>@acoburn: got it
all: do you see any reason to separate out users and groups as separate arguments of an AccessToProvider.getModes() method, or just pass in a single javax.jcr.Session (probably handed off from the delegates rolesHavePermissions method)?14:56
* awead leaves14:57
* acoburn leaves14:58
<whikloj>peichman: if you can get it from the session, then you can just return all the modes applicable from any ACLs. I like that.
* awead joins14:59
* acoburn1 joins15:00
<peichman>@whikloj: the signature I am envisioning is Set<URI> getModes(ACL, javax.jcr.Session), where ACL is the interface you are working on
@whikloj: which would return the set of all modes that the user in Session holds, according to the ACL15:01
* awoods wary of passing jcr.Session around15:02
<peichman>as I am saying that, I am still wondering how that list is going to be narrowed to just the resource in question
given that an ACL could have a bunch of authorizations for different resources
* acoburn1 leaves15:03
<whikloj>peichman: That could be in the ACL implementation, pass it the ACL FedoraResource and target FedoraResource and get an ACL with permissions scoped to just that target?15:04
peichman: or maybe do that in your provider, filter out the extra target objects from the ACL
<peichman>@whikloj: it feels more natural in my provider, I think15:05
<whikloj>peichman: agreed
<peichman>@whikloj: (resource + ACL + user/group info) => (modes)
* acoburn joins
<peichman>@awoods: would a set of java.security.Principals be better?15:06
<whikloj>peichman: the question is do you go out and retrieve the group info?15:07
<peichman>@awoods: or two arguments: Principal userPrincipal, Set<Principal> allPrincipals?
<ajs6f1>peichman: anything is better than leaking JCR stuff.
<whikloj>peichman/awoods: I think Principle is what is used in the XACML
^^ actually they do, but they also pass in the javax.jcr.Session to build the Principle15:09
^^ https://github.com/fcrepo4/fcrepo-module-auth-xacml/blob/master/src/main/java/org/fcrepo/auth/xacml/XACMLAuthorizationDelegate.java#L136
acoburn: do you any issues with https://github.com/fcrepo4-labs/fcrepo-module-auth-webac/pull/3, cause I have some more constants to add :)15:10
<peichman>maybe the best strategy is to use Principals in the supporting classes (like the AccessTo/AccessToClass providers), which we can pull out of the session at the AuthzDelegate level?15:11
<awoods>whikloj/peichman: Is it safe to assume we will be using ServletContainerAutheniticationProvider? If so, it looks like principals become Strings: https://github.com/fcrepo4/fcrepo4/blob/master/fcrepo-auth-common/src/main/java/org/fcrepo/auth/common/ServletContainerAuthenticationProvider.java#L156
<whikloj>awoods/peichman: I think we defined servlet user-principle, headers and container provider as the agents we would collect.15:12
<acoburn>whikloj: I am going to merge PR #3 in just a sec. Once that's done, feel free to add additional constants
<acoburn>awoods: I just rebased and updated fcrepo-1684. It's ready for your review
<awoods>whikloj: yes, PrincipalProviders return java.security.Principal. https://github.com/fcrepo4/fcrepo4/blob/master/fcrepo-auth-common/src/main/java/org/fcrepo/auth/common/PrincipalProvider.java15:14
acoburn: thanks
<peichman>@awoods: wouldn't this imply that the Principal objects are available in the JCR Session (which is available to the Delegate)? https://github.com/fcrepo4/fcrepo-module-auth-xacml/blob/master/src/main/java/org/fcrepo/auth/xacml/XACMLAuthorizationDelegate.java#L16915:15
<acoburn>whikloj: I just merged PR #3, so feel free to add to that class15:18
<awoods>peichman: yes. Implementations of FedoraAuthorizationDelegate are tied directly into Modeshape. It would be nice if the jcr.Session did not leak beyond that. https://github.com/fcrepo4/fcrepo4/blob/master/fcrepo-auth-common/src/main/java/org/fcrepo/auth/common/FedoraAuthorizationDelegate.java15:21
<peichman>@awoods: then I will have the AccessToProvider take Principals as its arguments
* osmandin leaves15:31
* dwilcox leaves15:34
<ajs6f1>awoods: It would nice if we could refactor authz-commons to get away from JCR entirely.15:37
<awoods>ajs6f1: yes... although we get our authz tie-in with Modeshape via implementing org.modeshape.jcr.security.AuthenticationProvider15:39
<ajs6f1>awoods: I get that. We could build an SPI in kernel and a MODEshape specific subtype in kernel-modeshape.15:40
<awoods>ajs6f1: that is a good point.
ajs6f1: drop a ticket in15:41
<ajs6f1>awoods: This is a good point: https://uofa.ualberta.ca/news-and-events/newsarticles/2011/03/sharpestmicroscopetiplandsresearcheraworldrecord
* awoods leaves15:42
* awoods joins
* dhlamb leaves15:55
* awead leaves
* dhlamb joins
* github-ff joins
[fcrepo4-vagrant] whikloj pushed 2 new commits to master: http://git.io/vs5Pi
fcrepo4-vagrant/master 9c5839b Andrew Woods: Update for 4.3.1-SNAPSHOT...
fcrepo4-vagrant/master 3d715e1 Jared Whiklo: Merge pull request #19 from awoods/fcrepo-1658...
* github-ff leaves
<whikloj>awoods: do I need to add a "roadmap theme" when closing a Jira ticket?15:57
* dhlamb leaves16:00
* awead joins16:01
<ajs6f1>awoods: https://jira.duraspace.org/browse/FCREPO-170916:02
* esm_ leaves
* ajs6f1 leaves16:14
* ajs6f joins
* pgwillia joins16:16
<awoods>whikloj: nope16:21
whikloj: however, please "close" tickets you merge and if it was a button-click-merge, you can leave a comment in the ticket that says "PR-xx was merged", or if it is a manual squash/merge, you can leave a comment in the ticket like "Resolved with commit:xxx"16:24
* ajs6f1 joins
* ajs6f leaves
<ajs6f1>awoods:whikloj: Can I emphasize how good it is to actually note the _commit_ with which you merged whatever it was that closed the ticket? Actually put a Github _link_ to the commit in there.16:25
* acoburn leaves16:26
<awoods>ajs6f1: yes you can. and thanks.
* acoburn joins
<awoods>acoburn: it seems like your internet is on and off today.
<ajs6f1>awoods: Okay, I'll do that now: It's really good to actually note the _commit_ with which you merged whatever it was that closed the ticket. Put a Github _link_ to the commit in there.16:27
<acoburn>awoods: it's really inconvenient
* ajs6f1 leaves16:35
<whikloj>awoods/ajs6f1: how's this: https://jira.duraspace.org/browse/FCREPO-165816:37
<awoods>whikloj: that is pretty deluxe.16:38
<whikloj>awoods: that's how I roll16:39
<whikloj>to quote ruebot "dolla dolla bill yall"16:40
<awoods>acoburn: The last commit I see on this PR is from 14 days ago: https://github.com/fcrepo4/fcrepo4/pull/874/commits16:43
<acoburn>awoods: that's probably because any additional changes got pulled into the rebasing effort over the last two days16:44
awoods: I can assure you that the changes I made today are in there16:45
<awoods>acoburn: ok, one comment.16:46
whikloj: I changed to status from "done" to "fixed": https://jira.duraspace.org/browse/FCREPO-165816:47
<acoburn>awoods: is that your reading of the "Usage in multi-module projects" section?
<awoods>acoburn: yes. Do you read it differently?16:49
* ajs6f joins
* ajs6f leaves16:50
<acoburn>awoods: I think we have the same reading of that, though honestly, I thought I had tried that and it resulted in the integration tests simply not running. I'll try again16:51
awoods: I must have been imagining things. I'll update the PR in just a sec16:57
* awead leaves
<acoburn>awoods: all yours: https://github.com/fcrepo4/fcrepo4/pull/874/17:01
<awoods>acoburn: thanks
<whikloj>I'm out17:02
* whikloj leaves
* github-ff joins17:03
[fcrepo4] escowles created inbound-to-us (+1 new commit): http://git.io/vsdTH
fcrepo4/inbound-to-us dec0838 Esmé Cowles: Filtering references that aren't inbound to the node in question
* github-ff leaves
* github-ff joins17:04
[fcrepo4] escowles opened pull request #891: Filtering references that aren't inbound to the node in question (master...inbound-to-us) http://git.io/vsdTp
* github-ff leaves
* acoburn leaves17:08
* peichman leaves17:15
<ruebot>awoods: https://github.com/duraspace/pcdm/pull/24 -- ruthtillman mentioned on twitter she'd lend a hand. so, leaving it there if she'd like to expand upon it. but, what is there now should meet the bare minimum.17:16
<awoods>ruebot: see comment. I would be interested to hear your thoughts.17:18
* travis-ci joins17:19
fcrepo4/fcrepo4#3985 (inbound-to-us - dec0838 : Esmé Cowles): The build failed.
Change view : https://github.com/fcrepo4/fcrepo4/commit/dec0838f4a1f
Build details : https://travis-ci.org/fcrepo4/fcrepo4/builds/77225914
* travis-ci leaves
<ruebot>awoods: replied17:21
<awoods>ruebot: what "existing rdfs2html.xsl"?17:22
ruebot: was there an rdfs2html.xsl floating around somewhere?17:23
<ruebot>awoods: https://github.com/fcrepo4/ontology/blob/master/rdfs2html.xsl :-)
awoods: that's what i used for islandora ontology too
awoods: ...that's why i grabbed it so quick. figured it take me all of a weebit.17:24
<awoods>ruebot: thanks. That makes sense. Could you also add a <xml-stylesheet> statement in each of the RDF documents so that I can just drop your xsl next to the RDF documents on the webserver instead of pre-building the html?17:25
<ruebot>awoods: yep!
<awoods>ruebot: then we should be golden... and it is nice to have your pom.xml machinery in case we want to move toward a pre-built model.17:26
<ruebot>awoods: updated. use and rights are relative. hope that's ok.17:29
<awoods>ruebot: actually, relative is not ideal because of the 303 redirects17:30
<ruebot>awoods: shall i take out the ../ then?17:31
<awoods>ruebot: yes, please. See the result of: "curl -I -i pcdm.org/rights"
curl -I -i pcdm.org/rights | grep Location17:32
<ruebot>awoods: updated17:33
<ruebot>awoods: let me know if you want me to squash the commits again.
* ksclarke leaves18:02
* MohamedAR leaves18:14
* dwilcox joins18:32
* pgwillia leaves18:39
* dwilcox leaves18:54
* dwilcox joins19:09
* dwilcox leaves19:18
* dwilcox joins19:23
* the_mgt_ joins19:25
* the_mgt leaves19:29
* dwilcox leaves20:16
* ksclarke joins20:34
* github-ff joins20:37
[fcrepo-message-consumer] acoburn closed pull request #93: fix dependency convergence conflict (master...fcrepo-1684) http://git.io/v3JWC
* github-ff leaves
* github-ff joins20:40
[fcrepo-message-consumer] acoburn opened pull request #95: refactor to use fcrepo-parent maven configuration (master...fcrepo-1684) http://git.io/vsFmf
* github-ff leaves
* github-ff joins20:42
[fcrepo4-swordserver] acoburn opened pull request #10: clean up pom to correspond to upstream changes (master...fcrepo-1684) http://git.io/vsFmm
* github-ff leaves
* github-ff joins
[fcrepo-module-auth-xacml] acoburn opened pull request #43: update maven config based on upstream changes (master...fcrepo-1684) http://git.io/vsFmZ
* github-ff leaves
* dhlamb joins20:47
* awead joins20:51
* awead leaves20:52
* awead joins20:57
* awead leaves
* awead joins21:02
* awead leaves21:03
* awead joins21:28
* awead leaves22:17
* ksclarke leaves22:24
* awead joins22:25
* ksclarke joins22:40
* ksclarke leaves22:46
* ksclarke joins23:05
* dhlamb leaves23:44
* cmmills leaves00:01
* cmmills joins00:02

Generated by Sualtam