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

Using timezone: Eastern Standard Time
* whikloj joins04:04
* whikloj leaves04:08
* whikloj joins05:05
* whikloj leaves05:09
* dchandekstark joins05:16
* dchandekstark leaves05:21
* whikloj joins06:06
* whikloj leaves06:10
* whikloj joins07:06
* whikloj leaves07:11
* dwilcox joins07:23
* manez joins08:00
* manez leaves08:05
* coblej joins08:07
<ruebot>[Import/Export Standup]08:14
* Completed yesterday:
- A significant amount of meetings
* Planning on completing today:
- https://github.com/fcrepo4-labs/fcrepo-import-export/pull/6 -- testing08:15
- contribute to https://jira.duraspace.org/browse/FCREPO-213408:16
* Blockers / Need help with:
- nada
* manez joins08:40
* westgard joins08:46
* dchandekstark joins08:54
* whikloj joins
* coblej leaves08:59
* coblej joins09:00
* acoburn joins09:02
* coblej leaves09:05
* coblej joins09:07
<escowles>[import/export standup]09:10
* yesterday: PR for export skeleton: https://github.com/fcrepo4-labs/fcrepo-import-export/pull/609:11
* today: respond to ruebot's comment and then work on export tickets (2141/2142)09:12
* blockers: none09:13
escowles: did i jump the gun with my comment? i thought about that after i commented.
<escowles>ruebot: not at all — i think the problem is just the path to the jar file, can you try with fcrepo-export/target/fcrepo-export-0.0.1-SNAPSHOT.jar ?09:15
<awoods>[Import/Export Standup]09:16
* Completed yesterday:
- Review of: (Create a test plan) https://jira.duraspace.org/browse/FCREPO-2132
* Planning on completing today:
- Review and testing of anything that is "In Review"
* Blockers / Need help with:
- Please let me know if you need help, should we schedule a call for Thu? Fri?
<escowles>a call on friday to take stock is probably a good idea09:17
<awoods>ruebot: shall we schedule it?
* ajs6f joins09:18
* dchandekstark leaves
<ruebot>escowles: updated. facepalm by me :-)09:21
* barmintor_ joins
<ruebot>awoods: yeah. i could do afternoon on thursday or friday.
<escowles>i was thinking of updating the example to explicitly mention the path to the jar file anyway, so i'll do that
<awoods>ruebot: either is good with me09:22
<barmintor_>* yesterday: split the i/e project up into a multimodule so that we could work on more than one component at once
* today: working on FCREPO-2130
<ajs6f>acoburn: Can you say anything about this: https://github.com/fcrepo4-exts/fcrepo4-vagrant/pull/55#issuecomment-243757367
<barmintor_>* blockers: none that I know of
<ajs6f>acoburn: I.e. is it likely due to the changes in -camel config?
<ruebot>awoods: i'll toss together a doodle poll.
<barmintor_>ruebot: on trains, ttyl09:23
* barmintor_ leaves
<acoburn>ajs6f: likely
ajs6f: I don't use vagrant, but once my time frees up a bit, I'll take a look
<ajs6f>acoburn: I don't understand how -camel was or is configured enough to do much. Thanks!09:24
* dhlamb joins09:26
* youn joins
* github-ff joins
[fcrepo-import-export] escowles force-pushed export-skeleton from 0cb5ba6 to 46c54e5: https://git.io/viT27
fcrepo-import-export/export-skeleton 46c54e5 Esmé Cowles: Adding basic export implementation.
* github-ff leaves
<youn>[Import/Export Standup]
* Completed yesterday: test resources - binaries09:27
* Planning on completing today: containers with RDF and binaries
* Blockers / Need help with: none
* youn leaves
<awoods>ajs6f/acoburn: As a note, 5 people engaged in fcrepo4-vagrant release testing with the prior camel-toolbox, then on the day of the release the version of the camel-toolbox within fcrepo4-vagrant was changed... and it is not working quite yet. I would suggest we rely on the release testing process that took place: https://wiki.duraspace.org/display/FF/Release+Testing+-+4.6.0#ReleaseTesting-4.6.0-VagrantTests09:29
<ajs6f>awoods: No. You can't test the correct versions of components in the vagrant setup without releasing the other components, or at least, that procdedure gives no guidance as to how to so do.09:30
awoods: The tests those 5 people did were only with 4.5.1
awoods: The vagrant code itself had not been updated to use 4.6.0 gear.
awoods: For my money, vagrant should be on a completely independent release cycle. Too much stuff is being released together now.09:31
awoods: and people (like me) who are not, who have particularly disclaimed, responsibility for components in -exts are still being made responsible for their release.09:32
* dchandekstark joins
* mikeAtUVa joins09:33
<acoburn>awoods: the issue is that the camel release cycle is decoupled from the F4 release cycle (this is a good thing)09:34
awoods: the reason this was difficult was:
1: the message serialization format changed
(so fcrepo-camel-toolbox was no longer compatible with the new F4)09:35
2: the toolbox architecture changed (re: configuration)
<awoods>acoburn: although the messaging change only affects delete operations on solr and the triplestore.
* mikeAtUVa leaves
<acoburn>awoods: true, but the architecture changes to the -toolbox meant that it was a major release09:36
<awoods>acoburn: of course
<westgard>[Import/Export Standup]
<acoburn>awoods: I COMPLETELY agree with ajs6f that the vagrant gear should be released independently of F4
<awoods>acoburn: I think it would be great if we can get the latest camel-toolbox working in the 4.6.0 vagrant... I am just noting that the release process was testing (and validated) a different target.09:37
<acoburn>awoods: I also think that -exts projects should, in no way, affect the release cycle of F4 core
<awoods>acoburn: I disagree about having vagrant on a different release cycle from the core code. Vagrant is how many people use each release.09:38
<acoburn>awoods: yes, the toolbox code (for very good reasons) is based on _actual releases_ of F4
awoods: now that F4 4.6.0 has been released, I can update the test code to be based on that artifact
awoods: but _not_ before
* bseeger joins
<ajs6f>awoods: That means it shouldn't be in -exts, and you are demanding that the committers take joint responsiblity for it.
<ruebot>"For my money, vagrant should be on a completely independent release cycle. Too much stuff is being released together now."09:39
^^ that++
<acoburn>awoods: and if -vagrant is in core and it depends on the camel machinery, then ipso facto the camel machinery goes in core, too09:40
awoods: and I am -1 on that
<awoods>acoburn: you make a good point about the toolbox's dependency on an already-released version of fcrepo.
<ajs6f>The answer to coupling problems is usually looser coupling. Not tighter coupling.
<ajs6f>There is another approach: stop having volunteer release managers.09:41
awoods: If you want to do all the work (you are doing much of it now) you can release everything in Github all together every cycle, as far as I'm concerned.09:42
* peichman joins
<awoods>My concern is two-fold: 1) people rely on vagrant to use fcrepo releases. 2) for better or worse, we did release testing and validated a vagrant environment, then are trying to release a different vagrant environment.09:43
<ajs6f>awoods: We did the _wrong_ testing and validation. The change at the last minute is not the problem. The fact that it didn't occur earlier is the problem.
<awoods>ajs6f: that fact that what did not occur earlier?09:44
<acoburn>awoods: in hindsight, I should have waited until well _after_ the F4 release to release the camel-toolbox
awoods: but it would have resulted in a broken vagrant anyway
<ajs6f>awoods: 1) realizing that the vagrant setup was not using (could not be using) 4.6.0, and 2) having some kind of procedure to fix that or work around it.09:45
<acoburn>awoods: esp if vagrant depends on -toolbox
<ajs6f>awoods: what acoburn says
* justinsimpson joins09:46
<awoods>We have three choices right now: 1) make the latest toolbox work in the 4.6.0 vagrant. 2) roll back the release tag on vagrant to the commit that was tested during RC. 3) don't release vagrant with the 4.6.0 fcrepo release.09:48
<ajs6f>awoods: You object to #3, but I have no problem with it.09:49
<acoburn>awoods: I'm in favor of #3
<ajs6f>awoods: #1 would require work from acoburn, I suspect.
<acoburn>which won't happen immediately
<ajs6f>awoods: I'm not sure what #2 accomplishes?
<awoods>I'm am open to a committer vote.
<ajs6f>awoods: Here is a release that is exactly like the last one?
<acoburn>except that it only _sort of_ works09:50
<whikloj>awoods/ajs6f/acoburn: Has anyone tried the karaf-service restart I added?
<ajs6f>If we're voting, I am +1 to #3— no vagrant release until this main release is entirely done.
<acoburn>I'm also +1 on #3
* mikeAtUVa joins
<justinsimpson>[Import/Export Standup] (Justin Simpson)09:51
* Completed yesterday:
<acoburn>whikloj: I don't use vagrant, so no
<ajs6f>whikloj: I have not. I'm not even sure how to do that. Should I take the code and do 'vagrant up' and just watching for errors in the log?
<justinsimpson>set up a local test environment
* Planning on completing today:
try an initial test of https://github.com/fcrepo4-labs/fcrepo-import-export/pull/6
* Blockers / Need help with:
<whikloj>acoburn/ajs6f: It's fine, you guys have a plan09:52
<ajs6f>Our plan, so far, is to punt. Which is sometimes the smart thing to do.
We can release vagrant separately later this week, or next week, can we not?
<escowles>ajs6f: given the dependencies, it seems like a f4 core release is a precondition for a toolbox release, which is a precondition for a vagrant release09:53
<whikloj>I would say you can release it whenever, I'm not certain whom uses it
<ruebot>i'm fine with holding on the vagrant release. sound sounds like the smart play.09:54
<escowles>so — doing each in turn (with some inevitable delays) seems like the only reasonable thing to do
<acoburn>and typically, the -toolbox code doesn't change from F4 release to F4 release — the wrinkle here is that the message format changed
<ajs6f>At least for this time. We can discuss it further later, although I am in favor of permanently decoupling these things.09:55
At least for this time meaning do stagerred releases this time.
<awoods>I believe we have 8 of the 11 committers here on IRC. In addition to acoburn, ajs6f, escowles, whikloj, can we get two more up-votes for punting on vagrant for the moment?
* diegopino joins09:56
* Fedo_Raadmin joins
<ruebot>+1 punting
<Fedo_Raadmin>I'm in favor of punting.
<ajs6f>+1 to punting.
* dchandekstark leaves09:57
<westgard>trying this again09:58
[Import/Export Standup]
* Completed yesterday:
Finished loading of plant patents dataset that can be used for testing.
* Planning on completing today:
A few refinements, then export XML and make available by some means agreeable to all (size is around 60 MB).
* Blockers / Need help with:
Just need to know how we want to share this dataset.
* diegopino_ joins
<ajs6f>awoods: I think 4 committers with +1 are enough, sans any -1s.
<ruebot>westgard: i think the plan was to initially include it in the fcrepo-import-export repo09:59
<bseeger>[Import/Export Standup]
* completed yesterday: looked at test plan, added comments
* planning on completing today: setup test env
<awoods>barmintor? mikeAtUVa? thoughts?10:00
<bseeger>* blockers / need help with: just not quite sure what to do yet, but helping here and there.
<ruebot>barmintor: is on a train
<westgard>ruebot: what's the best way to do that? Export the XML & binaries, tar it up and make a pull request?10:01
* diegopino leaves10:02
<ruebot>^^ awoods, escowles: what do you think? put in in fcrepo-import-export or a sep repo?
<justinsimpson>ruebot westgard I think having a sampledata repo on its own is useful, the data is good for not just for import-export testing, presumably, but potentially other testing?
<awoods>+1 sep repo10:03
<escowles>i agree with justinsimpson: putting the data in its own repo is a good idea (keep import-export smaller too)
<bseeger>same here, fwiw
about separate repo
this exists: https://github.com/fcrepo4-labs/fcrepo-sample-dataset10:04
<westgard>OK, agree sep repo makes sense. As a general test dataset, this may prove to be a bit too homogenous, but we can always add more diverse objects later10:05
<ajs6f>awoods: We need to resolve this question of vagrant. I am going on vacation tomorrow (I bizarrely supposed that three full days of work would be enough to release Fedora) so I will not be travailing further with this.10:06
<bseeger>Hmm… that repo I sent is a bit lower level - jcr/xml, not quite the right thing.10:07
<awoods>ajs6f: I agree. Let's resolve this today. I will be tied up until 1pm ET, but will then have some time to see if whikloj's PR (or modifications thereof) fix things, otherwise, unless mikeAtUVa or barmintor have objections, we punt.10:08
<ajs6f>awoods: +1
* mikeAtUVa has no objections.10:09
<ajs6f>awoods: And I will be circling back on this to try to get a fuller, more satisfying resolution. We need strong procedures.
<mikeAtUVa>[Import/Export Standup]10:10
* Completed yesterday:
- Wiki documentation stub: https://jira.duraspace.org/browse/FCREPO-2136
- Explored camel serializer
* Planning on completing today:
- https://jira.duraspace.org/browse/FCREPO-2127 or something more useful
* Blockers / Need help with:
- not sure whether FCREPO-2127 is still relevant or where to put the documentation
- distracted by https://jira.duraspace.org/browse/FCREPO-2086
- not sure what to work on next
* coblej leaves
<awoods>ruebot: ping10:15
<ruebot>awoods: on a call :-(10:16
* coblej joins
<escowles>mikeAtUVa: i'd say 2127 is still relevant, and you can put the docs on the import/export design page (or child page) for now: https://wiki.duraspace.org/display/FF/Design+-+Import+-+Export10:17
<mikeAtUVa>escowles: thanks! I'll do that.10:18
* diegopino leaves
<westgard>bseeger: I think we do want jcr/xml (or that was my understanding) since that's the quickest/easiest to load10:19
* coblej leaves10:21
<westgard>bseeger: but in order to get the data set up I did make the loader that operates over the REST api so someone could in theory use that too
<ruebot>awoods: pong
<mikeAtUVa>westgard: per your earlier question, weren't we going to share an "fcr:backup"?10:22
<awoods>ruebot: just noting mikeAtUVa's request for tasking
<bseeger>westgard: Okay, I see - so that repo might be applicable. I was thinking about the import part - where we will want to use the RESTAPI stuff, I believe. ?
* dhlamb leaves10:23
* ruebot reads up
* dhlamb joins10:24
<ruebot>escowles: for mikeAtUVa - "not sure whether FCREPO-2127 is still relevant or where to put the documentation"10:25
<escowles>ruebot: i said "yes" and "attached to https://wiki.duraspace.org/display/FF/Design+-+Import+-+Export"
<westgard>mikeAtUVa: bseeger: I will gladly take guidance here... I used to be indecisive but now I'm not so sure
* ruebot facepalm
escowles: sorry, just read that.
* ruebot should read more
<escowles>ruebot: n/p there's a couple different convos going on here and it's easy to miss stuff10:26
<ajs6f>awoods: Trying to work through release notes, but I can't make much of the issue macros you have used: are they based on saved filters in Jira?
mikeAtUVa: https://jira.duraspace.org/issues/?jql=project%20%3D%20FCREPO%20AND%20status%20in%20(Open%2C%20%22In%20Progress%22)%20AND%20component%20%3D%20f4-import-export -- that's what we have open and/or in progress
<awoods>ajs6f: yes, jira queries based on "release version" and labels10:27
<bseeger>westgard: :) not sure myself. Might make sense to store what you have (but where?). Soon we'll have export and then can test import from that exported data; so jcr/xml makes sense to me in that scenario10:28
<ajs6f>awoods: But saved there? So I need to make the queries, save them, then use that macro in the notes?
<awoods>ajs6f: exactly
<ajs6f>awoods: Okay, cool.
<awoods>ajs6f: and you need to make those saved queries public, naturally.
<ajs6f>awoods: Right, right. Hm. We should find a a way to automate this. Not today, tho.10:29
* coblej joins10:31
<ajs6f>awoods: Hm. I can't see how to make this public. I've got a filter, and under "Details" it just says10:33
This filter is only visible to you.
with no button or anything to change that.
awoods: Might I need some additional permissions for my account?10:34
<awoods>ajs6f: sounds that way... I see: "Permissions10:35
This filter is only visible to you.
Edit permissions"
<ajs6f>awoods: Okay, should I ping someone at DS? Bill or someone?
<awoods>ajs6f: I will give it a quick look
* dchandekstark joins10:37
<bseeger>awoods, whikloj, westgard, mikeAtUva: can we use use https://github.com/fcrepo4-labs/fcrepo-sample-dataset for this data set or should something new be used (or did I miss a decision somewhere)?10:41
mikeAtUVa, westgard: I think we did talk about fcr:backup. I don't have a preference - what ever is most condensed makes the most sense, so if that's the fcr:backup, that sounds good.10:42
<awoods>bseeger: fcrepo-sample-dataset seems appropriate
<ajs6f>mikeAtUVa: "Ah, silly me... the documentation is on our own Wiki." Nothing silly about that. This is our wiki: http://www.panoramio.com/photo/1070215010:43
* github-ff joins
[fcrepo-import-export] escowles created binaries-iff-configured (+1 new commit): https://git.io/viTHc
fcrepo-import-export/binaries-iff-configured 7d220fe Esmé Cowles: Don't export binaries if binDir not configured
* github-ff leaves
* github-ff joins10:44
[fcrepo-import-export] escowles opened pull request #7: Binaries iff configured (master...binaries-iff-configured) https://git.io/viTH2
* github-ff leaves
<awoods>ajs6f: refresh your jira10:45
<ajs6f>awoods: Looks good10:46
awoods: Can you just look at this and verify that you can see it?
<awoods>ajs6f: I see it... but it may be a better test if a non-admin tries.10:47
<ajs6f>awoods: good point.
ajs6f: I see it in incognito10:48
<ajs6f>awoods: Oh, cool. That "private" or "incognito" function turned out to be more useful to devs than I imagine web browser project ever imagined.
<awoods>whikloj: the latest PR to vagrant is showing promise... resources show up in: fuseki, solr and serialized to disk... and delete deletes them.10:57
<whikloj>awoods: it still has those baseUrl errors in the karaf.log though10:58
<awoods>whikloj: yes... nasty stack traces
<whikloj>awoods: I think that is somehow related to what acoburn said about the message format changing, but I can see why10:59
* awoods into calls11:00
<ajs6f>Is there no more "baseUrl" being pushed into the message headers?11:01
<acoburn>that header should be there
<whikloj>2016-08-31 13:03:21,798 | ERROR | Consumer[fedora] | DefaultErrorHandler | 57 - org.apache.camel.camel-core - 2.17.1 | Failed delivery for (MessageId: ID:fedora4-53047-1472648402925-3:1:1:1:12 on ExchangeId: ID-fedora4-37662-1472648489660-2-10). Exhausted after delivery attempt: 11 caught: java.io.IOException: No baseURL header available!. Processed by failure processor: FatalFallbackErrorHandler[Channel[Log(FcrepoTriple11:03
storeUpdater)[Index Routing Error: ${routeId}]]]
maybe its in the logging part of the route?!
<acoburn>ajs6f: curious thing about tombstones in 4.6.0: if you provide an RDF-based accept header, it reports the content type as that, even though it's always just text/plain11:05
<ajs6f>acoburn: Is not the word "stinky" the bon mot?
<acoburn>ajs6f: very much so11:06
<ajs6f>acoburn: But did you see barmintor's excellent point ystday re tombstones vs versioing?
<acoburn>ajs6f: yes, I did
<ruebot>escowles: should i be getting exported rdf with #6, or just the directory structure?
<acoburn>ajs6f: it was an excellent point
<escowles>ruebot: you should be getting rdf files11:07
* justinsimpson leaves
<ajs6f>acoburn: I think we need to understand that idea before we know quite what to do with the tombstone stiinkiness.
<ruebot>escowles: oh, if i change it to the root of the repo, i get rdf
<escowles>ruebot: but not if you point it at a random container?11:08
* dwilcox leaves11:09
<ruebot>escowles: that is correct. ...just verified again.
http://localhost:8080/rest +1
http://localhost:8080/rest/15/e5/8f/f0/15e58ff0-0e64-47d5-af4f-e32c0e819574 no rdf
<escowles>ruebot: and curl returns RDF for that URL, right?11:10
<bseeger>ruebot: I just noticed I get rdf, but with a .ttl extension
<escowles>bseeger: ruebot: the default is to retrieve turtle and use .ttl as the extension
(which can be configured)
* dwilcox joins11:11
<bseeger>escowles: yes, I used —rdfLang application/rdf+xml but didn't configure an extension
escowles: so I missed that part...
<ruebot>escowles: yeah, curl -s http://localhost:8080/rest/15/e5/8f/f0/15e58ff0-0e64-47d5-af4f-e32c0e819574 returns rdf for me11:12
<ajs6f>all: I'm working at finishing release notes for 4.6.0 : https://wiki.duraspace.org/display/FF/Fedora+4.6.0+Release+Notes11:18
all: Anyone who ha a moment, please do glance over them and tell me what I am missing / what I am claiming that isn't true / what is just daft or insane. I'm sure there's a healthy sprinkling of all these things.11:19
<acoburn>ajs6f: I'd need access to view that page11:20
<ajs6f>acoburn: And there's the first thing I forgot.
awoods: I think you'll have to remove the restriction. It's the same story— I can see it, but I can't edit it.11:21
<barmintor>ruebot: who is reviewing pr #611:27
<ruebot>barmintor: i've been testing it along with bseeger11:39
barmintor: if you want to do code review, go for it
* bseeger leaves11:40
* coblej leaves11:42
* github-ff joins11:43
[fcrepo-camel] acoburn opened pull request #117: Update testing apparatus to use F4 v4.6.0 (master...fcrepo-2147) https://git.io/vikeL
* github-ff leaves
* dhlamb leaves
* dwilcox leaves11:45
* thomz leaves11:46
<ajs6f>awoods: if you have a chance, please remove the restrictions on the release notes page.11:48
* coblej joins11:49
<awoods>ajs6f: done
acoburn: ^^^ take a look at the release notes, if you have a chance thnx11:52
* dwilcox joins
<acoburn>ajs6f: ok, I'll try this afternoon
* coblej leaves11:53
* dhlamb joins12:02
* dchandekstark leaves12:10
<ruebot>barmintor, mikeAtUVa: when you have a moment http://doodle.com/poll/6y4gs8wdmk2bgzau12:13
<barmintor>ruebot: done. I blocked off the morning for I/E this week, and the afternoon is filled up12:23
<barmintor>(next week will be spottier)
or at least less consistent
* dchandek_ joins12:26
* coblej joins12:27
<ruebot>escowles: we don't have a check to see if fcrepo is actually there do we? i just ran it on a non-existant fcrepo instance, and it said "Exporting!"12:28
escowles: if not, i can create a ticket.
* coblej leaves
<escowles>ruebot: yes, we should have a ticket for error handling and reporting total failures like that12:29
escowles: creating one now.
* coblej joins12:30
<ruebot>awoods: do we have a sprint setup in JIRA?12:31
<awoods>no, just the f4-import-export module
<ruebot>awoods: do we want one setup? not sure how you normally roll during sprints w/r/t this.12:32
<awoods>tracking by the jira component seems to work12:33
in this case
<ruebot>awoods: cool. just wanted to make sure.12:34
* dchandek_ leaves12:37
* Fedo_Raadmin leaves12:41
<escowles>ruebot: PR #7 also adds logback and config, so the logging statements actually work, which will help somewhat12:44
* dchandekstark joins12:58
* peichman leaves12:59
* bseeger joins13:02
* peichman joins13:04
<ajs6f>afk bbl13:24
* ajs6f leaves
* dwilcox leaves13:27
* dchandek_ joins13:39
* dchandek_ leaves13:40
* dchandek_ joins
* dchandek_ leaves13:41
* dchandekstark leaves13:42
* dchandekstark joins
* dwilcox joins
* coblej leaves13:46
* peichman leaves
* dchandekstark leaves
* coblej joins13:47
* peichman joins13:48
* coblej leaves13:49
* coblej joins13:53
* github-ff joins
[fcrepo-camel-toolbox] acoburn opened pull request #108: Update dependencies (master...fcrepo-2147) https://git.io/vik8m
* github-ff leaves
* dchandekstark joins13:57
* github-ff joins14:01
[fcrepo-camel-tests] acoburn opened pull request #11: Update testing apparatus to use Fedora 4.6.0 (master...fcrepo-2147) https://git.io/vik4E
* github-ff leaves
* dchandekstark leaves14:12
* dchandekstark joins14:16
* travis-ci joins14:21
fcrepo4-exts/fcrepo-mint#32 (4.6.0-maintenance - 4d82f50 : ajs6f): The build has errored.
Change view : https://github.com/fcrepo4-exts/fcrepo-mint/compare/4.6.0-maintenance
Build details : https://travis-ci.org/fcrepo4-exts/fcrepo-mint/builds/156328008
* travis-ci leaves
* ajs6f joins
* travis-ci joins
fcrepo4/fcrepo-module-auth-rbacl#82 (4.6.0-maintenance - 50a9ab2 : ajs6f): The build has errored.
Change view : https://github.com/fcrepo4/fcrepo-module-auth-rbacl/compare/80a59895e128...50a9ab281af0
Build details : https://travis-ci.org/fcrepo4/fcrepo-module-auth-rbacl/builds/156326347
* travis-ci leaves
<ajs6f>[ERROR] Non-resolvable parent POM: Could not transfer artifact org.fcrepo:fcrepo:pom:4.6.1-SNAPSHOT from/to codehaus-snapshots (https://nexus.codehaus.org/snapshots/): nexus.codehaus.org and 'parent.relativePath' points at wrong local POM @ line 3, column 11: Unknown host nexus.codehaus.org -> [Help 2]14:22
Not sure what's going on there.
<acoburn>ajs6f: looks like jenkins hasn't pushed those artifacts to sonatype14:23
<ajs6f>I think we get some Maven plugins from Codehaus, that's all.
<awoods>ajs6f/whikloj: I think the following PR works: https://github.com/fcrepo4-exts/fcrepo4-vagrant/pull/55
<ajs6f>acoburn: Ok, not going to freak out about it.
<whikloj>awoods: what about that baseUrl stack traces?
* travis-ci joins
fcrepo4-exts/fcrepo-audit#121 (4.6.0-maintenance - e35b7b4 : ajs6f): The build has errored.
Change view : https://github.com/fcrepo4-exts/fcrepo-audit/compare/4.6.0-maintenance
Build details : https://travis-ci.org/fcrepo4-exts/fcrepo-audit/builds/156328186
* travis-ci leaves
<ajs6f>awoods: Is that PR correcting for the change in auth config?
* travis-ci joins14:24
fcrepo4-exts/fcrepo-transform#109 (4.6.0-maintenance - b979523 : ajs6f): The build has errored.
Change view : https://github.com/fcrepo4-exts/fcrepo-transform/compare/4.6.0-maintenance
Build details : https://travis-ci.org/fcrepo4-exts/fcrepo-transform/builds/156328153
* travis-ci leaves
* bseeger leaves
<whikloj>ajs6f: yes
<ajs6f>acoburn: Can you glance at that ^^^ PR?14:25
<acoburn>ajs6f: is this the pr? https://github.com/fcrepo4-exts/fcrepo4-vagrant/pull/55
ah yes it is
ajs6f:awoods: it looks right to me, but I am not in a good position to actually test it14:26
<awoods>acoburn: there are some unpleasant stacktraces in the karaf.log, but the functionality seems correct.14:27
<acoburn>awoods: that's great
awoods: stack traces related to baseURL?14:28
<ajs6f>awoods:acoburn:whikloj: Do we have a sense that the stacktraces are unrelated? They seem to have to do with JMS connections, which I would think would be something else.
<acoburn>awoods: I just updated all the camel machinery to be tested against F4 4.6.0, and other than some minor changes to a few tests, the runtime code all worked correctly (which is what I've seen in manual tests, too)14:29
ajs6f: the release notes look good14:31
<whikloj>ajs6f: it seems related to the triplestore indexer. But I'm not sure what is happening as items do end up in the triplestore and get deleted.
<acoburn>ajs6f: there are a few items that are listed in the JIRA tickets which might be good to highlight (e.g. the change to using weak ETags)14:33
<ajs6f>acoburn: +1 # i'll put in something about that.
<acoburn>ajs6f: I also wonder if it would make sense to mention that infinispan will not be part of 4.7.0
ajs6f: that gets into more of a "roadmap" document, which really should be separate14:34
ajs6f: but the last time I saw a "roadmap" document in the F4 wiki, it was really out of date
ajs6f: maybe not "out of date", but lacking much in specificity
<ajs6f>acoburn: I do have something labout that in there, already… ?14:36
<acoburn>ajs6f: I clearly needed to read more closely :-)
* westgard leaves
<whikloj>I think those stack traces are due to HEAD requests for fcr:transform/default, which Fedora responds with "Prefix fcr has not been registered".14:39
<acoburn>whikloj: you mean when running the reindexer?
<whikloj>acoburn: no, when I created a new container in Fedora14:40
I see a bunch (like 9) of
INFO 18:35:57.406 (FedoraLdp) HEAD for: fcr:transform/default
<acoburn>oh, aren't you using webapp-plus?
right, the solr indexer uses that14:41
<whikloj>acoburn: yes, and if I go to test:jared/fcr:transform/default it works fine
but this seems to be trying to get the transform of the root resource
<acoburn>whikloj: it's probably trying to index the root resource
whikloj: in previous versions of fedora, messages for the root were never published
<whikloj>acoburn: right and http://localhost:8080/fcrepo/rest/fcr:transform/default doesn't work anyways14:42
<acoburn>whikloj: exactly
<ajs6f>acoburn: dare i ask why it would be trying index the root? is this some kind of recursion up the tree?
<whikloj>Because the I made my container as a child of root probably14:43
<acoburn>ajs6f: when you add a new container to the root, the lastModified property changes, so an event is fired
ajs6f: camel is just reacting to events
<acoburn>whikloj: w/r/t this error, I'd much rather spend time replacing the usage of fcrepo-transform with fcrepo-ldpath14:44
whikloj: which is to say that I'm not planning to do anything about it (i.e. w/r/t fcrepo-transform)
<ajs6f>acoburn:whikloj: Ok, so we can ignore it for now? It doesn't actually represent a fault condition?
<whikloj>acoburn: np, I'm just trying to see if that was the remaining issue in the vagrant setup.14:45
<acoburn>ajs6f: one could interpret it as a fault in the fcrepo-transform module, but I'm not touching that: https://github.com/fcrepo4-exts/fcrepo-transform/pull/27
ajs6f: in principle, it is an error, but in practice, I'd ignore it14:46
<ajs6f>acoburn: I am happy to accept that interpretation.14:47
<whikloj>acoburn/ajs6f: the errors between catalina.out and karaf.log do line up. I'm actually not seeing that baseUrl error now, just a 400 Bad Request which would be Fedora's response
<acoburn>whikloj: in which case the karaf error is correct and expected14:48
<whikloj>acoburn: agreed
<ajs6f>Fedora 4: The error is correct.
<whikloj>acoburn: and adding a child not to the root node (ie. /rest/test:one/test:two), throws no errors in the karaf log14:49
<acoburn>whikloj: right, b/c it triggers events only for /rest/test:one and /rest/test:one/test:two14:50
<whikloj>acoburn: cool, okay. I am fine with those errors for now. The plan is to remove fcrepo-transform, so no point expending extra effort on it.14:51
<acoburn>whikloj: unless you make /rest/test:one a direct/indirect container and set the target for membership triples at the root (which seems like a bad idea somehow)
<whikloj>acoburn: haha agreed14:52
<ajs6f>acoburn:whikloj: That was a really good LDP joke.15:00
<whikloj>ajs6f: just missing an alligator15:01
<ajs6f>whikloj: https://media.giphy.com/media/l0NwPZ027mabR6Tg4/giphy.gif15:02
<whikloj>ajs6f: you know, we look a lot alike15:03
<ajs6f>whikloj: We're both well-proportioned, that's for sure.
<acoburn>ajs6f: awoods: is it now time to "protect" the various 4.6.0-maintenance branches?15:08
i.e. to prevent force-push operations
<ajs6f>acoburn: That's seems appropriate to me, but I honestly do not know how to do that. Is it a Github function?
<ruebot>ajs6f: yep! it's on the settings page
<acoburn>ajs6f: yes: in the repo: settings -> branches
<ajs6f>awoods: Seem okay to you?
<awoods>acoburn: sounds reasonable, thanks for suggesting it.
<ajs6f>acoburn:awoods: I'll wrangle it.
* github-ff joins15:11
[fcrepo-import-export] barmintor opened pull request #8: Import skeleton (master...import-skeleton) https://git.io/vikoO
* github-ff leaves
<barmintor>awoods ruebot escowles I got burned by the copycode
<awoods>barmintor: are you ok?15:12
<barmintor>I have to run to another office, but that is starting to pull out common code into a common module and a driver into a separate module
<barmintor>so there's a total of: parent, common, import, export, driver15:13
<barmintor>driver uses import and export
<ruebot>are we good to merge 6 then?
<barmintor>import and export use common
<ruebot>then barmintor can rebase?
<awoods>unless driver fits into common
<ruebot>...and are we good to merge 7?
<barmintor>awoods: circular dependencies
<awoods>we don't want that
* awoods one last meeting {sigh}15:14
<barmintor>I also renamed o.f.export to o.f.exporter, so that I could call the import module importer instead of importexport
which was confusing me
<ajs6f>awoods: The last meeting ever?! My goodness, man, you've got nothing to complain about. I have a whole lifetime of meetings still in fron tof me.
<barmintor>in PR 7 importexport is for shared classes15:15
<ruebot>barmintor++ #importer exporter
<barmintor>anyway, I'm late. feel free to fork that branch, I'll check before I leave campus.
* github-ff joins15:20
[fcrepo-import-export] ruebot closed pull request #6: Adding basic export implementation. (master...export-skeleton) https://git.io/viJVk
* github-ff leaves
<ruebot>escowles: #6 merged -- do you need to do an update on #7?
<escowles>ruebot: yep, i'll rebase it (and i think there was a comment from ajs6f i wanted to address too)
<ruebot>escowles: excellent15:21
* coblej leaves15:23
<escowles>ruebot: #7 is updated: https://github.com/fcrepo4-labs/fcrepo-import-export/pull/715:24
* github-ff joins
[fcrepo-import-export] escowles force-pushed binaries-iff-configured from 7d220fe to e3bafab: https://git.io/vikKN
fcrepo-import-export/binaries-iff-configured e3bafab Esmé Cowles: Don't export binaries if binDir not configured
* github-ff leaves
* github-ff joins15:27
[fcrepo-camel] acoburn opened pull request #118: update readme to include the latest updates from Fedora v4.6.0 (master...update_documentation) https://git.io/vik6B
* github-ff leaves
escowles: i'll check it out and verify as soon as i'm this call. if all looks good, i shall merge.15:33
<ajs6f>acoburn: Do you use this: http://hawt.io/?15:38
<acoburn>ajs6f: yes15:39
ajs6f: I like it a lot15:40
<ajs6f>acoburn: Worth packing into the camel gear?
<acoburn>ajs6f: I think we recommend it in the documentation
ajs6f: what do you mean by "packing into the camel gear"?
<ajs6f>acoburn: They offer an OSGi service. I was thinking we might include that by default.15:42
acoburn: For the Jolokia part, that is.
<acoburn>ajs6f: you mean in the vagrant stuff?
ajs6f: I always just install it separately so as not to introduce unnecessary dependencies15:43
ajs6f: maybe someone wants to use some other JMX thing
<ajs6f>acoburn: Well, that's true. No matter how helpfu it might be, it isn't needed.
acoburn: Better leave it alone.
<acoburn>ajs6f: they have pretty frequent releases, so it would be a chore simply keeping up with that15:44
<ajs6f>acoburn: nm, then. The more I think about it, the less I think it a good idea.
* dhlamb leaves15:48
<ruebot>ajs6f: we install it in CLAW vagrant iirc, happy to do the same in fcrepo vagrant if it is useful15:51
<ajs6f>acoburn:ruebot: Putting in vagrant would make more sense. But wouldn't the "fast-moving-dependency" problem stilll be there?15:52
<ruebot>weird. i thought we did. not see it with grep.15:53
* github-ff joins
[fcrepo4-vagrant] ajs6f pushed 5 new commits to 4.6.0-maintenance: https://git.io/vik1t
fcrepo4-vagrant/4.6.0-maintenance 5625981 Andrew Woods: Enable karaf features to install with fcrepo-camel-toolbox:4.6.0
fcrepo4-vagrant/4.6.0-maintenance ff3d09c Jared Whiklo: Setup user/pass in correct config.
fcrepo4-vagrant/4.6.0-maintenance 207252b Andrew Woods: Merge pull request #1 from whikloj/4.6.0-maintenance...
* github-ff leaves
<acoburn>ajs6f: not really — vagrant is more of a test env, and no one would be needing a more recent version
<ajs6f>ruebot: Pull up you hawt.io console to check where the health of your hawt.io .
<acoburn>ajs6f: as long as it gets updated periodically, that would be sufficient
ajs6f: just like any dependency
<ajs6f>ruebot:acoburn: Let's file a ticket now, since there's a lot of things flying around vagrant. Let's get it released for 4.6.0 and then maybe this?15:54
acoburn:awoods:whikloj: I have merged awoods' pr against vagrant. Are we now assured that we are in good enough shape for a release?15:55
<acoburn>ajs6f: I defer to awoods and whikloj on that
<ajs6f>acoburn:ruebot: https://jira.duraspace.org/browse/FCREPO-215015:56
* westgard joins16:01
<ruebot>westgard: http://doodle.com/poll/6y4gs8wdmk2bgzau -- looks like the best time misses you :-(16:07
* github-ff joins16:08
[fcrepo-camel] ajs6f pushed 2 new commits to master: https://git.io/vikDK
fcrepo-camel/master 09deb23 Aaron Coburn: update readme to include the latest updates from v4.6.0
fcrepo-camel/master af82931 A. Soroka: Merge pull request #118 from acoburn/update_documentation...
* github-ff leaves
* travis-ci joins16:12
fcrepo4-exts/fcrepo-camel#277 (master - af82931 : A. Soroka): The build passed.
Change view : https://github.com/fcrepo4-exts/fcrepo-camel/compare/0170b7939be1...af82931d9f1c
Build details : https://travis-ci.org/fcrepo4-exts/fcrepo-camel/builds/156625700
* travis-ci leaves
<westgard>ruebot: that's OK -- I'll catch up on the reports later
* ruebot phew16:13
<ajs6f>wihikloj: Do I understand correctly that you have verified that awoods' fix for vagrant is enough o support a release?
* github-ff joins16:17
[fcrepo4] mikedurbin opened pull request #1096: Added path-based locking in LDP PATH, POST, PUT and DELETE methods. (master...FCREPO-2086) https://git.io/vikSm
* github-ff leaves
* dchandekstark leaves16:22
<ruebot>escowles: was #7 supposed to clean up the SLF4J: Failed to load class "org.slf4j.impl.StaticLoggerBinder". error too?16:33
<escowles>ruebot: it was supposed to — do you see logging output now?16:43
<ajs6f>mikeAtUVa: I'm not saying that there isn't any kind of concurrency control needed. But what you have there seems awfully strict. I'd like to look at some lower cost alternatives like simple locking and returning a 409 for anyone trying to get the lock when it is in use. Then we just need a simple set of paths. Clients who fail with 409 are welcome to try again.16:46
<mikeAtUVa>ajs6f: what I went with roughly translates to "only one request can modify a resource at a given path at once" I'd love to have just locked between "checking if an object exists and creating it", but because the way JCR sessions work, we can't really do that.16:50
ajs6f: returning conflicts seems meaner than making the client wait the split second for the previous request to finish.16:51
* dwilcox leaves
<ajs6f>mikeAtUVa: No, 1) your impl includes things like "get a lock on this static object before even trying to get a single lock" 2) I don't want to lock on a granularity finer than a single request 3) it is simpler and easier to reason about. Whether it is "meaner"? I don't know. I don't know how setting "retry limit" on your client is "mean". I have very little empathy for HTTP clients. {grin}16:53
<mikeAtUVa>ajs6f: that lock is for *extremely* fast operations like comparing an int and then removing something from a map.16:54
<ajs6f>mikeAtUVa: As I just wrote, I'm not at all convinced we need _any_ of that locking.
mikeAtUVa: But I am very mean-spirited.16:55
<mikeAtUVa>ajs6f: then how would you propose to fix the problem?
ajs6f: I don't believe there's a way to detect the conflict without adding at least *some* synchronization... this approach makes things work as I'd expect. If two PUT request come in at the same time, one of them fails.16:57
<ajs6f>mikeAtUVa: ^^^ a reentrant lock on the resource itself. If you try to get it, try using tryLock(), not lock. If you fail, you get a 409.
mikeAtUVa: Done.
mikeAtUVa: No blocking.
<mikeAtUVa>ajs6f: but if the resource doesn't exist (ie, PUT) how do you lock on the resource?16:58
<ajs6f>mikeAtUVa: If you desperately want to block, you could use lock() instead. Still, no global map of paths to locks.
* dchandekstark joins16:59
<ajs6f>mikeAtUVa: You check whether it exists first. If it does, get its lock.
<mikeAtUVa>ajs6f: but without synchronizing those two calls, between checking whether it exists and creating it, it could have been created (and indeed has been)17:00
<ajs6f>mikeAtUVa: And again, I would throw a 409.
* dchandekstark leaves
<ajs6f>mikeAtUVa: If you really want to synch, like I wrote above, you could use a set of paths (paths in use).17:01
<mikeAtUVa>ajs6f: how is a set of paths substantively better than a map of paths?17:02
* whikloj leaves
* acoburn leaves17:03
<ajs6f>mikeAtUVa: Even better would be back the resource lock by JCR locking. In fact, now that I think about it, that's what I would do if I was going to do this. But as I've said several times now, I'm not really sure we should do this.
mikeATUVa: I would rather just throw a 409. It's okay to do that.
<mikeAtUVa>ajs6f: my solution DOES throw a 409.17:04
<ruebot>escowles: yeah, all good on #7 :-)
* github-ff joins
[fcrepo-import-export] awoods deleted export-skeleton at 46c54e5: https://git.io/vikbJ
* github-ff leaves
<ajs6f>mikeAtUVa: Sorry, I meant in the situation in which requests "overlap".
<escowles>ruebot: good!
<mikeAtUVa>ajs6f: they only overlap because of the way we've architected our application, not because of anything wrong (or predictable) with the request.17:05
<ajs6f>mikeAtUVa: The situation you offered as a reason not to use per-resource locking. I would say that you still use per-resource locking, and back it by the JCR's locks.
mikeAtUVa: Fine with me.
<mikeAtUVa>ajs6f: backing it with JCR's locks will make transactions in their current form unusable.
<ajs6f>mikeAtUVa: You have two clients firing mutating requests at the same resource at the same moment. I have no problem returning a 409 to that.17:06
mikeAtUVa: Why?
<mikeAtUVa>ajs6f: because you'd lock those resources for the duration of the transaction... abandonded transactions would prevent other operations.
<ajs6f>mikeAtUVa: Abandoned transactions are hardly a problem that can be managed by Fedora.17:07
mikeAtUVa: It's past 5. I've got to run. Can you put this on the tech call for tomorrow?
<mikeAtUVa>ajs6f: agreed, let's not talk about transactions... they don't really work anyway.
ajs6f: sure thing.
<ajs6f>mikeAtUVa: Thanks. And thanks for tackling this.17:08
* ajs6f leaves17:10
<awoods>ruebot: you are merging #7?17:13
<escowles>i'm heading out - talk to y'all tomorrow
<awoods>escowles: I notice you have been doing some force pushes.
* dchandekstark joins
* mikeAtUVa leaves
<awoods>escowles: talk to you tomorrow
<escowles>awoods: i rebased and squashed...17:14
awoods: yep, we can talk tomorrow if we'd rather not have squashed PRs
* dchandekstark leaves17:17
<ruebot>awoods: not yet17:19
<awoods>ruebot: I see you have a binary issue
<ruebot>awoods: yep
awoods: not sure if it is me or not.17:20
* awoods taking a look
* peichman leaves17:29
* manez leaves17:30
* dwilcox joins17:37
<awoods>ruebot: no, it's not you. Binary export does not seem to be doing anything.17:45
* ajs6f joins17:46
<awoods>ruebot: the issue is not about binaries... but rather that it does not support recursive export.17:47
* dwilcox leaves
<ajs6f>awoods: I am longer clear on whether we are going to release vagrant. I have no received any confirmation that the various fixes have fixed everything that we wanted to see fixed.
<awoods>ajs6f: I believe vagrant is cleared to release17:48
ajs6f: although verification would have been nice from more than one person.
<ajs6f>awoods: Yes, it would. Yes, it certainly would. Well, I am going to cut it and send the message to the lists.17:49
* dwilcox joins
* dchandekstark joins
* ruebot phew
<ruebot>ajs6f: RELEASE MANAGER!!!17:50
<ajs6f>ajs6f: Tired. Very tired.
one day, we can have a release manager get together in a wonderful bar somewhere.17:51
<ajs6f>ruebot: https://s-media-cache-ak0.pinimg.com/736x/29/e3/12/29e31223942728ee959e7cfbd60d26e6.jpg
* github-ff joins17:54
[fcrepo4-vagrant] ajs6f force-pushed fcrepo4-vagrant-4.6.0 from 5033911 to 4411c87: https://git.io/viJ9e
* github-ff leaves
awoods: do we want do create a new ticket for that, or resolve in #7 PR?
<awoods>ruebot: https://github.com/fcrepo4-labs/fcrepo-import-export/pull/7#issuecomment-24391468917:55
<ruebot>awoods: ...and just noticed you're comment.
* github-ff joins
[fcrepo-import-export] ruebot pushed 1 new commit to master: https://git.io/viIvm
fcrepo-import-export/master 5a3620f Esmé Cowles: Don't export binaries if binDir not configured (#7)
* github-ff leaves
<ruebot>awoods: so, we just need to rebase #8, and that resolves another one.
awoods: things seem to be moving along very well from my perspective.
<awoods>ruebot: yes, we just need to make sure that folks know what to work each morning.17:57
ruebot: I don't see a ticket associated with #817:58
ruebot: is it ready for review?
<ruebot>awoods: yeah. i suppose i should be better at that.
awoods: i don't think ben created a ticket for that. he just did it because it was bothering him.
<awoods>ruebot: is that PR ready?17:59
<ruebot>awoods: https://github.com/fcrepo4-labs/fcrepo-import-export/pull/8#issuecomment-243915455
awoods: added a note about a ticket too18:00
<awoods>ruebot: did barmintor say #8 is ready for review/merge?
<ruebot>awoods: not explicitly, he had to run to something.18:01
awoods: "anyway, I'm late. feel free to fork that branch, I'll check before I leave campus."18:02
* westgard leaves18:06
<ajs6f>awoods: Just sent the message. Should I send something particular to Carol?18:12
<awoods>ajs6f: that is great. maybe a message to Carol and dwilcox and myself would be good.
<dwilcox>ajs6f++ Thanks!18:14
<ajs6f>ruebot: Big ups back to you, and all who tested, tweaked and (especially whikloj) flat-out cut parts of this release.
<ajs6f>I am going on vacation. Expect nothing from me until next week.18:16
out like a light
* ajs6f leaves
* ruebot ruebot_away18:23
* dchandekstark leaves18:30
* manez joins18:31
* manez leaves18:35
* dwilcox leaves19:03
* manez joins19:25
* manez leaves19:29
* manez joins
* manez leaves19:36
* dchandekstark joins20:00
* dchandekstark leaves20:05
* dchandekstark joins20:11
* dchandekstark leaves20:22
* dchandekstark joins20:23
* manez joins20:37
* manez leaves20:43
* dhlamb joins21:03
* dchandekstark leaves21:19
* ajwagner leaves21:57
* ajwagner joins21:59
* dchandekstark joins22:42
* dchandekstark leaves22:49
* dchandekstark joins23:04
* dchandekstark leaves23:09
* dhlamb leaves
* manez joins23:50
* manez leaves23:54
* dchandekstark joins00:06
* dchandekstark leaves00:11

Generated by Sualtam