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

Using timezone: Eastern Standard Time
* github-ff joins00:34
[fcrepo-import-export] dbernstein opened pull request #53: Implements binary redirects export approach (master...fcrepo-2296) https://git.io/v1Vej
* github-ff leaves
<dbernstein>[Import/Export Standup]00:39
Finished yesterday:
https://jira.duraspace.org/browse/FCREPO-2296
Implement binary redirects export approach
Issued pull request
Working on today:
Other than any feedback on the pull request
I’m not sure: let’s talk about it.
Blockers:
None
* dbernstein leaves00:43
* apb18 joins07:13
* dwilcox joins07:25
* coblej joins07:55
* awead joins08:42
* acoburn joins08:46
* whikloj joins08:57
* escowles leaves09:00
* escowles joins09:01
* apb18 leaves09:04
* peichman joins09:06
* peichman1 joins09:08
* peichman leaves
* dhlamb joins09:09
* Informatician joins09:14
* coblej leaves09:19
<ruebot>[Import/Export Standup]09:21
Finished yesterday:
- Worked on updating import-export utility to use a standardized config https://jira.duraspace.org/browse/FCREPO-2340 - whikloj took the baton09:22
* coblej joins
<ruebot> - Worked with westgard to resolve -- verification tool should handle up-to-date config file -- https://jira.duraspace.org/browse/FCREPO-2332
Working on today:
- Outlining Import-Export Videos https://jira.duraspace.org/browse/FCREPO-2299
- Test, validate, merge -- verification tool cannot handle exports performed with no binaries (-b flag) -- https://jira.duraspace.org/projects/FCREPO/issues/FCREPO-2342
Blockers:
- A few conference calls today
<awead>[Import/Export Standup]09:26
Finished yesterday:
No tickets to review.
Working on today:
Reviewing https://jira.duraspace.org/browse/FCREPO-2225
Blockers:
none
<escowles>[import/export standup]09:29
* yesterday: added integration tests https://jira.duraspace.org/browse/FCREPO-2192
* today: debug error messages https://jira.duraspace.org/browse/FCREPO-2330
debug losing namespaces https://jira.duraspace.org/browse/FCREPO-2252
* blockers: none
(also, almost done with sending digest with binary uploads https://jira.duraspace.org/browse/FCREPO-2334)09:30
* bseeger joins
* apb18 joins09:32
<bseeger>whikloj: can you take a look at this PR this morning? https://github.com/fcrepo4-labs/fcrepo4-tests/pull/909:33
* Informatician leaves
<whikloj>bseeger: looking now09:34
<bseeger>whikloj: thanks!!
* informatician joins
<whikloj>bseeger: You are just cutting release branches now right?
<bseeger>whikloj: I did all that yesterday - just testing vagrant and prepping the email.
<whikloj>bseeger: Awesome, just want to test this09:35
<bseeger>whikloj: great - 4.7.1-RC-1 is under the release page if you want to test against that.
<whikloj>bseeger++09:36
* westgard joins09:38
* ajs6f joins09:40
* github-ff joins09:41
[fcrepo-import-export] escowles created upload-fixity (+1 new commit): https://git.io/v1V1H
fcrepo-import-export/upload-fixity 7ec73a8 Esmé Cowles: Setting digest header on uploaded binaries to detect corruption
* github-ff leaves
<ruebot>acoburn: looks like you and awoods are the only owners in fcrepo4-exts from what i can see https://github.com/orgs/fcrepo4-exts/teams/committers09:42
* github-ff joins
[fcrepo-import-export] escowles opened pull request #54: Setting digest header on uploaded binaries to detect corruption (master...upload-fixity) https://git.io/v1V1x
* github-ff leaves
<acoburn>apb18: I just sent you an invite to the fcrepo4-exts org09:46
apb18: you also have a pending invite to fcrepo4
<ruebot>acoburn++09:48
* coblej leaves
* coblej joins
<acoburn>ruebot: I made you owner for fcrepo4-exts09:57
<ruebot>acoburn++
<apb18>acoburn: Thanks - I'm still not used to some aspects of the github UI. It took a little bit of digging to find; didn't seem to be any apparent notifications (?)09:58
<ruebot>acoburn: thanks!
* peichman1 leaves
* github-ff joins
[fcrepo-camel-toolbox] birkland closed pull request #118: Remove dependency on JMS-based headers (master...fcrepo-2333) https://git.io/v1uwU
* github-ff leaves
<acoburn>apb18:whikloj:ajs6f:escowles: I made you all "owners" for the fcrepo4-exts organization10:01
<escowles>acoburn: thanks
<ajs6f>acoburn++ # The Ownership Society
<whikloj>With great power comes great responsibility
<ajs6f>https://en.wikipedia.org/wiki/Ownership_society
* awead leaves10:02
<informatician>[Import/Export Standup]
Finished Yesterday:
- Nothing (*sadface)
Working on Today:
- Re-attempt verification on completed export
- Set up Fedora 4.7 on production infrastructure
- Test fcr:restore (4.7) using fcr:backup (4.0)
- Test Import (4.7) using export (4.0)
Blockers:
- Receiving HTTP 401 errors on use of verify.py.
Confirmed that correct credentials are being used.
Could this be due to running against fcrepo 4.0?
<westgard>[Import/Export Standup]
Finished yesterday:
verification tool able to handle nobinaries option (FCREPO-2342)
Working on today:
ticket to handle missing resources and continue after reporting error (FCREPO-2329)
ticket to ignore external binaries (FCREPO-2327)
Blockers:
None
* peichman joins10:03
<acoburn>ruebot: you're an owner of the fcrepo4 org now, too
<apb18>ajs6f: Ha, I didn't know that had a name
<westgard>informatician: There is a PR to make the verify.py handle nobinaries option, so that might be something to try next
<acoburn>ruebot: if I missed anyone, feel free to adjust the roles
<westgard>informatician: https://github.com/fcrepo4-labs/fcrepo-import-export-verify/pull/11/10:04
<ajs6f>apb18: The first order of business in politics is always to name things.
<informatician>westgard: thanks! I'll give that a go and see if maybe that sorts me out.
<westgard>I don't think I've ever tested against a 4.0 export, so certainly that is also a possibility
but worth testing this first10:05
<ruebot>acoburn: cool! thank you again :-)
<informatician>Righto. I went through some of the python code, but I don't have a debugging environment setup for python at the moment so didn't follow it very far. I'll check things out with that new PR and see what I get.10:06
<westgard>informatician++
* travis-ci joins10:07
fcrepo4-exts/fcrepo-camel-toolbox#307 (master - fb9ac73 : birkland): The build was broken.
Change view : https://github.com/fcrepo4-exts/fcrepo-camel-toolbox/compare/b66bb5447546...fb9ac73f4f09
Build details : https://travis-ci.org/fcrepo4-exts/fcrepo-camel-toolbox/builds/182611428
* travis-ci leaves
<apb18>acoburn: huh, test failures. I don't recall seeing that particular failure locally or in Travis before...10:09
<acoburn>apb18: travis can be a little temperamental sometimes
<westgard>Question for the group regarding import/export desired behaviors10:10
Right now there's a -b flag that allows you to export binaries
If -b is not included, only RDF resources will be exported
But fcr:metadata is not included either10:11
So the question is, what would folks want/expect from a nobinaries option?
<f4jenkins>Project fcrepo-camel-tests build #93: UNSTABLE in 4 min 5 sec: http://jenkins.fcrepo.org/job/fcrepo-camel-tests/93/
* th5 joins10:12
<westgard>fcr:metadata resources are RDF, but they don't make much sense without the binaries themselves
<acoburn>apb18: forgot to mention — there is a related PR here: https://github.com/fcrepo4-exts/fcrepo-camel-tests/pull/16
apb18: I have the pax exam tests in a separate repo (for now)10:13
<westgard>Also, it is unclear how one would import fcr:metadata resources without the binaries being there too, so including fcr:metadata in the export would seem to have limited utility, but might still be desired for backup purposes10:14
Any feedback or thoughts on this would be welcome
<ruebot>westgard: i think that last point you made is the critical point; if you get the fcr:metadata without the binary10:15
* github-ff joins10:16
[fcrepo-import-export] escowles created parsing-error (+1 new commit): https://git.io/v1V9C
fcrepo-import-export/parsing-error 628d9ff Esmé Cowles: Don't try to parse binaries as RDF
* github-ff leaves
* github-ff joins
[fcrepo-import-export] escowles opened pull request #55: Don't try to parse binaries as RDF (master...parsing-error) https://git.io/v1V9u
* github-ff leaves
<ruebot>escowles++ #you're on fire this morning!10:17
<escowles>ruebot: it's easy when the bugs are simple!
(i also got a 4-month-old PR merged this morning, so today is my lucky day)10:18
<ruebot>escowles++ #party time!
<apb18>acoburn: OK, will take a look.10:20
<westgard>ruebot: I guess the other side of the question is this. If someone is doing a nobinaries export, presumably they are getting the binaries by some other, non-HTTP method. If they do that, how will they get their fcr:metadata?
<ajs6f>Weird. Running org.fcrepo.kernel.modeshape.utils.ProjectedCacheEntryTest
Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0 sec <<< FAILURE! - in org.fcrepo.kernel.modeshape.utils.ProjectedCacheEntryTest
testGetExternalIdentifier(org.fcrepo.kernel.modeshape.utils.ProjectedCacheEntryTest) Time elapsed: 0 sec <<< ERROR!
java.lang.NoClassDefFoundError: org/modeshape/connector/filesystem/FileSystemConnector
at org.fcrepo.kernel.modeshape.utils.ProjectedCacheEntryTest.testGetExternalIdentifier(ProjectedCacheEntryTest.java:60)
Caused by: java.lang.ClassNotFoundException: org.modeshape.connector.filesystem.FileSystemConnector
at org.fcrepo.kernel.modeshape.utils.ProjectedCacheEntryTest.testGetExternalIdentifier(ProjectedCacheEntryTest.java:60)
The main code base shouldn't be looking for filesystem projection stuff anymore, should it?10:21
<ruebot>westgard: counter to that; is that our concern when we give them the option to get binaries?10:22
<westgard>ruebot: fair point. I would like to hear what the nobinaries stakeholders desire, since it's not really a use case I have.10:23
I have to head to a meeting momentarily, but will look for feedback on this question in the IRC logs later :-)10:24
<acoburn>apb18: I restarted the travis build for fcrepo-camel-toolbox, and it passed fine this time
ajs6f: are you getting that from the master branch?
* westgard leaves10:25
<ajs6f>acoburn: Yup.
<acoburn>ajs6f: that's very strange
<ajs6f>acoburn: Well, almost. master plus some plugin version updates.
acoburn: But no changes to dependencies or code.
acoburn: May be my local repo is fouled.
acoburn: I'll start afresh.
<apb18>acoburn: OK, it looks like Jenkins was happy with the latest toolbox build. Would you be able to kick off another Travis build of the camel-tests PR; https://github.com/fcrepo4-exts/fcrepo-camel-tests/pull/16?10:26
<acoburn>ajs6f: I see the filesystem connector stuff in master
<ajs6f>acoburn: Erp? But I thought we excised that? And it builds for you?10:27
<acoburn>ajs6f: last time I tried it did
ajs6f: https://github.com/fcrepo4/fcrepo4/blob/master/fcrepo-kernel-modeshape/src/main/java/org/fcrepo/kernel/modeshape/utils/ProjectedCacheEntry.java#L22
ajs6f: that needs to be removed10:28
<ajs6f>acoburn: Wh-wha!? A fresh clone just failed to build for me with the same errors.
acoburn: But if I am the only person with this problem… well, we could remove that stuff anyway, right?
<bseeger>ajs6f — odd, it worked yesterday for the RC I made… hmm….
<acoburn>ajs6f: I'll try a build
<ajs6f>bseeger: I don't think this is a big problem. I think I just turned up something weird locally.10:29
bseeger: It seems to be working for everyone, so we're prolly fine.
<acoburn>bseeger: it shouldn't' affect the release
<ajs6f>bseeger:acoburn: But if we do have detritus from projection in there, we could get rid of it post-release, or pre-release on the master branch.10:30
We should get rid of that kind of thing, because it will only cause more confusion and pain and suffering and heartbreak later
<acoburn>ajs6f: we can get rid of it in master now
<ajs6f>acoburn++
Let me look at where it's occurring. I should be able to send a PR.
<acoburn>ajs6f: I just managed to corrupt my git repo ;-(10:31
<ajs6f>acoburn: IT'S CONTAGIOUS
<acoburn>ajs6f: I know I've fixed this sort of thing before, but do you know off hand how to deal with "fatal: unable to read d4e1b5c73a62cb2c46f4f6130a0c30e4686debbf
error: failed to run repack"
<ajs6f>acoburn: I do not. I only know enough about git to cause other people to corrupt their repos.10:32
Not fix them.
acoburn: If it makes you feel any better, my Eclipse setup just tanked with hundreds of errors.10:33
<acoburn>ajs6f: I think it's time to go back to PHP programming
<ajs6f>acoburn: I got a lot done back in the day between Applesoft Basic (with floating point arithmetic!) and the Apple ][ monitor.10:34
acoburn: The monitor was great because you could put together assembly programs almost line by line10:35
acoburn: Like rack-and-pinion steering for your CPU
<acoburn>ajs6f: that would be an adventure10:36
* awead joins10:37
<ajs6f>acoburn: It was good times. I had a real hopped up machine, with the optional lowercase extension for the keyboard and the 16kB expansion memory board. The MOSTEK 6502 couldn't address all 64kB that gave you at once, so you had to bank-switch the last 4kB yourself.
acoburn: You had to constantly keep track of which 4kB you had in scope through program execution.10:38
acoburn: Missing it wasn't like a page fault, it was a complete crackout.
acoburn: But barmintor has better stories.
<acoburn>ajs6f: ah, the good old days
* coblej leaves
* awead leaves10:44
<bseeger>whikloj: that fedorar4 test repo is quite nice. It made testing last night and this am much easier.10:46
whikloj++
<whikloj>bseeger: yeah it could use some work, changing to using jq and json-ld responses would mean alot more testing could be automated10:47
* ajs6f leaves10:48
* ajs6f joins10:52
* coblej joins10:53
<whikloj>bseeger: https://github.com/fcrepo4-labs/fcrepo4-tests/pull/10 if you can give that a test I'll see if I can wrangle a committer to help us out10:54
<bseeger>whikloj: I'll give it a go now10:55
<ajs6f>acoburn: Looks like weird corruptions in downloads of Mode 5.2 artifacts.10:56
acoburn: So nothing that should affect anyone else.
<acoburn>ajs6f: and my git repo is still corrupted…10:57
<ajs6f>acoburn: Well, introduce legislation for public campaign financing.
acoburn: Some people think that will work.10:58
<acoburn>ajs6f: oooh, I fixed it
<ajs6f>acoburn++ # power to the people!
<acoburn>ajs6f: it was my typical approach — play some Philip Glass and the errors run screaming in all directions10:59
<ajs6f>acoburn; I know how they feel. I keep a Terry Riley CD around for the worst stuff.
acoburn: But I feel bad having to use it.
* awead joins
<acoburn>ajs6f: I wonder how Java code reacts to the song: "In C"
<ajs6f>acoburn: Same way I do, I expect. It falls asleep.11:00
<acoburn>ajs6f: I assumed it dispatched the garbage collector11:01
<ajs6f>Oh, poop. Now I'm getting tons of
java.lang.RuntimeException: java.lang.ClassNotFoundException: Provider org.glassfish.jersey.internal.RuntimeDelegateImpl could not be instantiated: java.lang.IllegalStateException: No generator was provided and there is no default generator registered
in http-commons
Looks like a bunch of garbage to me.11:02
<whikloj>bseeger: grabbing a coffee, brb
<ajs6f>This is the kind of stuff that makes barmintor growl.
<bseeger>anyone: how do I check out a PR on a repo?11:03
<ajs6f>https://help.github.com/articles/checking-out-pull-requests-locally/11:04
<escowles>bseeger: there are also instructions at the bottom of the PR on how to create a local branch and merge the PR changes in
<acoburn>bseeger: for example: git checkout -b whikloj-fcrepo-1234511:05
bseeger: git pull https://github.com/whikloj/fcrepo4.git fcrepo-12345
<ajs6f>You know what? This isn't worth it. I guess I just can't build fcrepo4. And that's fine. I'm going to go work on something else.11:06
<acoburn>as escowled mentioned, there is a link at the bottom of the PR (view command line instructions)
bseeger: that's the easiest way11:07
* coblej leaves
<apb18>bseeger: I edit .git/config to add under the [remote "origin"] section the line: `fetch = +refs/pull/*/head:refs/remotes/origin/pr/*11:09
`
<acoburn>ajs6f: my build of fcrepo succeeded11:10
<ajs6f>acoburn: Bully for you, my boy.
Sorry, that should have been, b'hoy.
<apb18>bseeger: then I do a `git fetch`, and can checkout pull requests as `git checkout pr/12345`
<ajs6f>acoburn: I'm going to go work on that fcrepo3 shim.
<apb18>acoburn: OK, Travis failed building fcrepo-camel-tests for what could be a silly reason, and I cannot get it to build locally. Looks like it could be exam<->probe issues11:12
<bseeger>thanks everyone, for your help.11:15
<ajs6f>acoburn: I'm seeing dependencies on INSPN in -camel-toolkit. Is that coming in from the LDCache gear?11:19
acoburn: Wait, just answered my own question, yes it is.
<acoburn>ajs6f: yes, probably INSPN 6.0
<ajs6f>Gross.
acoburn: Yes.
<acoburn>ajs6f: I know
<ajs6f>acoburn: Any objection to a PR that just stick stuff in a map?11:20
Local caching?
<acoburn>ajs6f: you mean an impl of the LDCache interface?
<ajs6f>We could inject it and people could use Hazelcast or whatever.
acoburn: Yeah, that.
<acoburn>ajs6f: fine with me
<ajs6f>acoburn: k
acoburn: getting lots of warnings in -camel-toolkit:11:22
2016-12-09 11:21:31,440 | WARN | 1)-10.204.120.76 | AnnotationTypeConverterLoader | 41 - org.apache.camel.camel-core - 2.18.0 | Ignoring converter type: org.apache.activemq.camel.converter.ActiveMQMessageConverter as a dependent class could not be found: java.lang.NoClassDefFoundError: org/apache/camel/component/jms/JmsBinding
java.lang.NoClassDefFoundError: org/apache/camel/component/jms/JmsBinding
Cool?
<acoburn>ajs6f: yeah, I'm aware of that
<ajs6f>acoburn: k, cool
<acoburn>ajs6f: it's an issue with AMQ
<ajs6f>acoburn: NP
<acoburn>ajs6f: but the warning doesn't seem to affect anything
<ajs6f>acoburn: ignoring11:23
<acoburn>ajs6f: the word on the street is that this will be fixed in AMQ 5.15.x
<ajs6f>acoburn: What kind of weird-ass streets do you hang out on? In my city, the word on the street is stuff like, "Man, sure is chilly today." or "You see when the last bus came?" or "Got any change?" Not stuff about obscure computer software.11:24
<acoburn>ajs6f: yeah, Vermont is weird
* tolloid joins11:25
<ajs6f>acoburn: Bernie Sanders having burst onto the national stage, you don't have to tell the rest of the country that.
But it's a charming kind of weirdness.
<acoburn>apb18: the travis build for https://github.com/fcrepo4-exts/fcrepo-camel-tests/pull/16 succeeded11:26
<ajs6f>acoburn: -camel-toolkit built fine, but man, that is a lot of warnings.
<acoburn>ajs6f: it's really too much output
<ajs6f>acoburn: And it is mostly stacktrace.
acoburn: I'm fine with that, but it could be offputting to some folks11:27
<acoburn>ajs6f: a lot of it is that AMQ warning
ajs6f: I agree
<ajs6f>acoburn: Okay, as long as you have a plan.
Which could be just 'wait for AMQ to fix itself"
<acoburn>ajs6f: yes, that's a good summary of the plan
<ajs6f>acoburn: That's a good plan.
acoburn: So all the LDCache backend stuff gets injected via Blueprint?11:29
<acoburn>ajs6f: most of it, yes
<apb18>ajs6f: See https://github.com/fcrepo4-labs/fcrepo-api-x/issues/94 for a bit of conversation on AMQ, Camel 2.18 and errors
<ajs6f>acoburn: K, then I just go and impl org.apache.marmotta.ldcache.services.LDCache and mess with injection?11:30
<acoburn>ajs6f: the idea is that a different backend could be injected (something other than the file-based backend)
<ajs6f>apb18: Nope. Not going to do that. I _trust_ acoburn.
Implicitly.
acoburn: Or the INSPN stuff? Isn't that the only in-mem form now available?11:31
acoburn: So that gets used for tests and stuff?
<acoburn>ajs6f: yes, the ISPN stuff is the only in-memory piece
<ajs6f>acoburn: no, I impl LDCachingService
or no… hm.
<acoburn>ajs6f: I don't think I'm using the ISPN cache layer11:32
<ajs6f>acoburn: Then why are we pulling all that stuff?
<acoburn>ajs6f: it's that Marmotta has a really wonky understanding of dependencies
<ajs6f>acoburn: ohhhh.
<acoburn>ajs6f: and when it comes to OSGi, I have to do a bunch of dark magic with embedded dependencies because they can't get their house in order
<ruebot>bseeger: ping
<ajs6f>acoburn: Are they using some weird setup for assembling runtimes? Not Karaf or other modern thing.11:33
<bseeger>ruebot: here
<acoburn>ajs6f: definitely not
<ajs6f>acoburn: Like what Stanbol still does?
begins with an 's'
the bundlelist thing
<acoburn>ajs6f: they mostly expect users to use tomcat or jetty
ajs6f: and the java service registry11:34
<ajs6f>acoburn: That's quality OSGi.
<acoburn>ajs6f: so things really fall apart in OSGi
ajs6f: it doesn't help that they misspell the package names in the OSGi exports either
<ajs6f>acoburn: Right. Okay, so this doesn't seem as interesting now. If we're only being exposed to their problems and not making our own, we shouldn't juggle bowling balls to get around these problems.11:35
<acoburn>ajs6f: and they have imports for versions of software that they don't use or which are mismatches of what's actually imported
<ajs6f>acoburn: We should parry as long as needed and if needed, go upstream to fix them.
<ruebot>bseeger: you super busy?
<acoburn>ajs6f: I have a PR that's been sitting in the Marmotta repo for six months
<ajs6f>acoburn: It is worrisome in the long term. It's powerful, attractive functionality, and it sounds like it is accumulating technical debt like Calvin and Hobbes picking up snow on a downhill sled run.11:36
<acoburn>ajs6f: https://github.com/apache/marmotta/pull/22
<ajs6f>acoburn: We may need to think about a hostage extraction op at some point. Not today, but at some point.
<bseeger>ruebot: just trying to finish up some testing and get that release email out. What's up?
<ruebot>bseeger: https://github.com/fcrepo4-labs/fcrepo-import-export-verify/pull/8 -- just want to see if you're cool with whikloj merging that so we proceed on some other work.
<acoburn>ajs6f: yes, they've been talking about a 3.4.0 release since May, and there's been almost no movement in that time11:37
<ruebot>bseeger: ...but, don't want to overwhelm you since you're busy with release stuff :-)
<ajs6f>acoburn: I wish we could cut the arms off of Marmotta devs and the legs off of Stanbol devs and suture them together into a magnificent army of hecatoncheires.11:38
acoburn: Can you think of a piece of -camel-toolbox with good route test examples? I haven't done this stuff in five or seven years and everything looks different..11:40
<ruebot>bseeger++
<acoburn>ajs6f: https://github.com/fcrepo4-exts/fcrepo-camel-toolbox/blob/master/fcrepo-indexing-triplestore/src/test/java/org/fcrepo/camel/indexing/triplestore/RouteTest.java11:41
<ajs6f>acoburn++ # thnks
<acoburn>ajs6f: it makes heavy use of AdviceWith11:42
<ajs6f>acoburn: That's new to me, what is that, some kind AOP for routes?
<acoburn>ajs6f: it's a way to mock particular endpoints within a route11:43
<ajs6f>acoburn: Yeah, reading, I think I see. You knock out endpoints and stick mocks in the holes.11:44
<acoburn>ajs6f: yes exactly
ajs6f: it's great for testing the logical flow of a particular route
<ajs6f>acoburn: The whole mock endpoints things has changed a lot. Guess I'll go read about that. I'm sure Camel docs are full, rich, and up-to-date.
<acoburn>ajs6f: but you'll still need some sort of integration testing
http://camel.apache.org/advicewith.html11:45
<ajs6f>acoburn: That means bringing up a repo, ancillary servers, a Karaf instance, plugging a bunch of stuff into Karaf, and messing with the repo. What is that done with now… Pax Exam?
<ruebot>escowles: squash and merge, or merge commit for https://github.com/fcrepo4-labs/fcrepo-import-export/pull/55
<acoburn>ajs6f: yes, pax exam11:46
ajs6f: that's for full end-to-end integration testing, which can be a real beast
<ajs6f>acoburn: Urg. I hate when you have to bring up 4GB of server and then do two small things to one end to see that three small things happened on the other end;
acoburn: Using Cargo with one or two servers is bad enough11:47
<acoburn>ajs6f: that's why I mostly stick with the simple route tests and push the real integration tests into something separate
<ajs6f>acoburn: And for the shim, I'll need to bring up Fedora 3, as well.
<acoburn>ajs6f: right so maybe you'll need 6GB of server capacity
<ajs6f>acoburn: Something separate? Is there a separate i-test project for -camel-toolbox now?
<acoburn>ajs6f: pretty much: https://github.com/fcrepo4-exts/fcrepo-camel-tests11:48
<ajs6f>acoburn: Howling monkeys on motorbikes, 6GB? :sigh:
<acoburn>ajs6f: I'd like to move that back into fcrepo-camel-toolbox, but I'll need to convert the build machinery to gradle first
<escowles>ruebot: merge commit please!
<acoburn>ajs6f: the issue is that pax exam runs in the test phase, but it requires that the artifacts you're testing have already been installed into the local maven11:49
* github-ff joins
[fcrepo-import-export] ruebot closed pull request #55: Don't try to parse binaries as RDF (master...parsing-error) https://git.io/v1V9u
* github-ff leaves
<acoburn>ajs6f: but you can get around that w/ gradle
<ajs6f>acoburn: Okay, well, I'm am trying to learn as little as possible about the world around me, and anything for Fedora 3 has a clock ticking on it, so I will start with just route testing. That sounds difficult enough already.
<acoburn>ajs6f: yes, the simple route testing _is_ difficult enough already
<ruebot>escowles: same for https://github.com/fcrepo4-labs/fcrepo-import-export/pull/52 ?11:50
<escowles>ruebot: yep!
<ruebot>escowles: coooooooool
* github-ff joins11:53
[fcrepo-import-export] ruebot pushed 1 new commit to master: https://git.io/v1weN
fcrepo-import-export/master 46f3f82 Nick Ruest: Merge pull request #52 from fcrepo4-labs/custom-membership...
* github-ff leaves
* github-ff joins11:55
[fcrepo-camel-tests] birkland pushed 1 new commit to master: https://git.io/v1wvI
fcrepo-camel-tests/master 732ac9b Aaron Coburn: Remove JMS header dependencies...
* github-ff leaves
<apb18>acoburn: merged it, sorry. Have two sick kids at home now. Am relying on asynchronous messaging to interact with the outside world :)11:57
<ruebot>escowles: your questions is a blocker here right? https://github.com/fcrepo4-labs/fcrepo-import-export/pull/53 -- just waiting on dbernstein to respond there?11:58
<acoburn>apb18: I hope your kids feel better soon!
<escowles>ruebot: yes, i'd like confirmation from somebody that the tests aren't going to be run out of order and mess things up11:59
<ruebot>escowles: cool
<apb18>acoburn: Thanks. They train in virus fighting at daycare.12:00
<f4jenkins>Yippee, build fixed!
Project fcrepo-camel-tests build #94: FIXED in 4 min 37 sec: http://jenkins.fcrepo.org/job/fcrepo-camel-tests/94/
apb: Remove JMS header dependencies
<escowles>maybe somebody know if the junit tests are run in sequence or if they sometimes are run in random order? ajs6f acoburn apb18?
<ajs6f>acoburn: so mockEndpointsAndSkip("*"); is going to swap endpoint X:Y for new endpoint mock:X:Y?
escowles: That is intentionally undefined.12:01
<acoburn>ajs6f: exactly
<ajs6f>escowles: It turns out to have to do with the order that parts of the Reflection API use in a agiven JVM.
<escowles>ajs6f: acoburn: that's good to know — i'll update my comment in the ticket that was depending on sequential test execution then
<ajs6f>escowles: You can control it if you really want to by using custom Runners, but that is pretty dubious cheese.
* travis-ci joins12:02
fcrepo4-exts/fcrepo-camel-tests#36 (master - 732ac9b : Aaron Coburn): The build was broken.
Change view : https://github.com/fcrepo4-exts/fcrepo-camel-tests/compare/fda79835922c...732ac9b67a74
Build details : https://travis-ci.org/fcrepo4-exts/fcrepo-camel-tests/builds/182646915
* travis-ci leaves
<ajs6f>escowles: Yeah, I have ranted about this in this channel before. Tests that depend on order like that are not sound wood.
escowles: @BeforeClass, @AfterClass, @Before, @After, and most powerfully of all, JUnit Rules.
escowles: That's the high road.12:03
* dbernstein joins12:04
<ajs6f>afk bbl
* ajs6f leaves
<escowles>ajs6f: this particular case is using some config object in one test, then updating it in another test in a way that would make the first test fail: https://github.com/fcrepo4-labs/fcrepo-import-export/pull/53/files?diff=unified#diff-49a7c2991c488c3d94f1d85202877c56R179
* travis-ci joins12:07
fcrepo4-exts/fcrepo-camel-tests#36 (master - 732ac9b : Aaron Coburn): The build passed.
Change view : https://github.com/fcrepo4-exts/fcrepo-camel-tests/compare/fda79835922c...732ac9b67a74
Build details : https://travis-ci.org/fcrepo4-exts/fcrepo-camel-tests/builds/182646915
* travis-ci leaves
<acoburn>escowles: I've found that for tests w/ different config options, it's usually easier to create a separate test class12:08
escowles: I don't know if that's possible in this case, but that would be a safer way to go
<escowles>acoburn: i don't think we need to do that here — we have a config class that encapsulates the different config options passed to the import client12:09
<ruebot>whikoj: https://github.com/fcrepo4-labs/fcrepo-import-export-verify/pull/8 -- you're good to merge12:21
* bseeger leaves12:26
<dbernstein>@escowles: I made the change you suggested: now there’s a separate config for the skip binary import test.12:29
<escowles>dbernstein++12:30
* github-ff joins
[fcrepo-import-export] escowles pushed 3 new commits to master: https://git.io/v1wTn
fcrepo-import-export/master 2ba1aac Daniel Bernstein: Implements binary redirects export approach...
fcrepo-import-export/master 046c056 Daniel Bernstein: Adds separate config for testing the no binaries case in ImporterTest.
fcrepo-import-export/master 0094485 Esmé Cowles: Merge pull request #53 from dbernstein/fcrepo-2296...
* github-ff leaves
<ruebot>escowles: FCREPO-2252 -- that's an interesting find!
dbernstein++
whikloj++12:32
wow, this is amazing display of productivity sprint team!
<whikloj>oops I forgot my sprint update didn't I12:33
[Import/Export Standup]
Finished yesterday:
FCREPO-2169 and FCREPO-2170 : https://github.com/fcrepo4-labs/fcrepo-import-export/pull/4912:34
Above could use some eyes and testing.
<ruebot>whikloj++
<whikloj>Branch FCREPO-2340 - Added some stuff around using Yaml for the config file
Working on today:12:35
Continuing to work on FCREPO-2340
Blockers:
none
<ruebot>escowles: can you rebase https://github.com/fcrepo4-labs/fcrepo-import-export/pull/54 -- and i'll test12:36
whikloj: you gotta rebase too :-( https://github.com/fcrepo4-labs/fcrepo-import-export/pull/4912:37
<whikloj>ruebot: ok
<ruebot>whikloj: we're too productive! :-D
informatician, awead: how are y'all doing with the psu data?12:39
* github-ff joins12:49
[fcrepo-import-export] whikloj force-pushed fcrepo-2169 from 30e02a2 to e0fdec7: https://git.io/v10q6
fcrepo-import-export/fcrepo-2169 708b6b7 Jared Whiklo: First pass at an audit logger.
fcrepo-import-export/fcrepo-2169 c4afed8 Jared Whiklo: Set a default value
fcrepo-import-export/fcrepo-2169 6211b86 Jared Whiklo: Add .log to .gitignore
* github-ff leaves
<ruebot>westgard: fyi https://github.com/fcrepo4-labs/fcrepo-import-export-verify/pull/11#issuecomment-26607601612:51
whikloj++12:54
<whikloj>escowles: I am reverting to your way of thinking re: Config and ArgParser. There seems to be a lot of stuff that could be static, is there any benefit in an application like this?
ruebot: thanks
* peichman leaves
<awead>ruebot: Informatician is working on it, AFAIK12:55
<escowles>whikloj: i don't know if it makes any difference — but if it makes the code cleaner to have things be static, then that sounds good to me
* peichman joins12:56
<whikloj>escowles: yeah I don't know that it makes it any cleaner. I'll pick away and you can check it later.12:57
<escowles>whikloj++
* ajs6f joins12:58
<ruebot>awead: great!13:00
escowles++ whikloj++13:01
* bseeger joins13:03
* github-ff joins13:06
[fcrepo-import-export] escowles force-pushed upload-fixity from 7ec73a8 to 2977c18: https://git.io/v1wqi
fcrepo-import-export/upload-fixity 2977c18 Esmé Cowles: Setting digest header on uploaded binaries to detect corruption
* github-ff leaves
<informatician>ruebot: I've been working on getting PSU data exported, verified, and imported. There have been many layers of troubleshooting, but I'm making progress.13:09
<escowles>ruebot: https://github.com/fcrepo4-labs/fcrepo-import-export/pull/54 is rebased and green13:10
* dwilcox leaves13:18
* github-ff joins13:22
[fcrepo-import-export] ruebot pushed 1 new commit to master: https://git.io/v1wOY
fcrepo-import-export/master 22502cd Jared Whiklo: First pass at an audit logger. (#49)...
* github-ff leaves
<ruebot>informatician++13:24
informatician: let me know if you need a hand with anything
escowles: i think i just messed you up :-(
ruebot--
escowles: i merged whikloj's logging PR
* escowles rebases again...13:25
<ruebot>escowles++ #thanks!
awead: do you want to test/verify https://github.com/fcrepo4-labs/fcrepo-import-export/pull/54 ?13:27
<awead>ruebot: sure13:28
* github-ff joins
[fcrepo-import-export] escowles force-pushed upload-fixity from 2977c18 to 2759b0b: https://git.io/v1wqi
fcrepo-import-export/upload-fixity 2759b0b Esmé Cowles: Setting digest header on uploaded binaries to detect corruption
* github-ff leaves
<ruebot>whikloj: i just realized something... did we update the readme with the log option?
<escowles>ruebot: re-rebased: https://github.com/fcrepo4-labs/fcrepo-import-export/pull/54
<whikloj>ruebot: oops
<ruebot>whikloj: if not, i'll take care of that
<whikloj>ruebot++
<ruebot>whikloj++
awead: all yours!13:29
* escowles_ joins
<whikloj>ruebot: also that you can set the audit log directory with -Dfcrepo.log.importexport.logdir=/some/directory java option
ruebot: otherwise it is the current working directory13:30
* github-ff joins13:31
[fcrepo-import-export] whikloj pushed 1 new commit to FCREPO-2340: https://git.io/v1w3I
fcrepo-import-export/FCREPO-2340 a0fdbff Jared Whiklo: Additional cleanup/changes
* github-ff leaves
* escowles leaves13:33
* tolloid leaves
<ruebot>whikloj++
<whikloj>ruebot: it needs review, make sure I'm not going off on a tangent13:34
ruebot: Oooo and I should document the new config file format. ie. the valid parameters
<ruebot>whikloj++
<whikloj>bseeger: how is the fcrepo4-tests?13:36
ruebot: can you explain what the "source" option if for?13:41
s/if/is/
<escowles_>whikloj: when the files were exported from a different baseURL than you're importing into13:42
<ruebot>escowles_++
<whikloj>escowles_: ok so like moving hosts
<escowles>whikloj: exactly
<whikloj>escowles: Does that affect both export and import or just import?
<escowles>whikloj: just import
<whikloj>escowles++
* coblej joins13:43
<escowles>and right now, only the host and port can be mapped — there are tickets for baseURL and path within the repo
<whikloj>cool13:46
* github-ff joins13:47
[fcrepo-import-export] ruebot created log-follow-up (+1 new commit): https://git.io/v1wsA
fcrepo-import-export/log-follow-up 78275dc nruest: README updates
* github-ff leaves
<whikloj>and we no longer allow setting the RDF extension, right?
<escowles>whikloj: that's right — it gets set by the RDF type
<whikloj>escowles: thanks
* github-ff joins13:48
[fcrepo-import-export] ruebot opened pull request #56: README updates (master...log-follow-up) https://git.io/v1wGT
* github-ff leaves
<bseeger>whikloj: the look good and ran well against the 4.7.1 RC for me13:49
whikloj: /the/they
<whikloj>ruebot/escowles/acoburn/ajs6f: Can I get someone to merge this please. https://github.com/fcrepo4-labs/fcrepo4-tests/pull/1013:50
<ajs6f>I made ruebot do it.13:51
<ruebot>whikloj: done
ajs6f++
<whikloj>ajs6f++ ruebot++
* acoburn leaves
<ajs6f>whikloj++
<escowles>ruebot: two missing characters on https://github.com/fcrepo4-labs/fcrepo-import-export/pull/5613:53
(other than that, looks good)
<ruebot>escowles: cool13:54
whikloj: let me know if i captured your work right
...and then i'll commit and push
* github-ff joins13:57
[fcrepo-import-export] ruebot pushed 1 new commit to log-follow-up: https://git.io/v1wZz
fcrepo-import-export/log-follow-up 863020d nruest: review
* github-ff leaves
<escowles>ruebot: https://github.com/fcrepo4-labs/fcrepo-import-export/pull/56 looks good — shall i squash & merge?13:58
<ruebot>escowles: go for it!
* dwilcox joins
* github-ff joins13:59
[fcrepo-import-export] escowles pushed 1 new commit to master: https://git.io/v1wZP
fcrepo-import-export/master f99e29d Nick Ruest: README updates (#56)...
* github-ff leaves
* github-ff joins
[fcrepo-import-export] escowles deleted log-follow-up at 863020d: https://git.io/v1wZ1
* github-ff leaves
* dwilcox_ joins14:01
* dwilcox leaves14:03
<bseeger>ruebot: I realize I just missed a readme update for the i/e tool. I was thinking of adding a note about what the default RDF serialization is.14:06
ruebot: do I need to file a ticket for that, or can I just create a PR?14:07
<ruebot>bseeger: i just did a readme update. maybe i got it? if not, just do a PR.
* acoburn joins
<bseeger>ruebot: okay, thanks14:08
* peichman leaves14:14
* peichman joins14:15
* github-ff joins14:19
[fcrepo-import-export] bseeger opened pull request #57: Notes which serialization is the default (master...add_default) https://git.io/v1wW3
* github-ff leaves
* github-ff joins14:20
[fcrepo-import-export] escowles closed pull request #57: Notes which serialization is the default (master...add_default) https://git.io/v1wW3
* github-ff leaves
* github-ff joins14:23
[fcrepo-import-export] whikloj force-pushed FCREPO-2340 from a0fdbff to a3a196a: https://git.io/v1wWh
fcrepo-import-export/FCREPO-2340 eea62a2 nruest: framing out yaml config
fcrepo-import-export/FCREPO-2340 6742feb Jared Whiklo: Use Yaml
fcrepo-import-export/FCREPO-2340 e6817bc Jared Whiklo: Additional cleanup/changes
* github-ff leaves
* github-ff joins14:25
[fcrepo-import-export] whikloj opened pull request #58: Use Yaml for config file and put defaults in Config (master...FCREPO-2340) https://git.io/v1wlL
* github-ff leaves
<ruebot>whikloj++ #you're taking it across the finish line!14:26
whikloj: thank you!
<whikloj>ruebot: it's kinda big though, again my eclipse add "finals" and removed "this"s where they weren't before14:27
ruebot: but I wanted to get it in before the rebase got too crazy14:34
* github-ff joins14:35
[fcrepo-import-export] whikloj created fcrepo-2340 (+1 new commit): https://git.io/v1w4B
fcrepo-import-export/fcrepo-2340 fb7f144 Jared Whiklo: Return saveConfig() to its previous position.
* github-ff leaves
* github-ff joins
[fcrepo-import-export] whikloj deleted fcrepo-2340 at fb7f144: https://git.io/v1w4E
* github-ff leaves
* github-ff joins14:36
[fcrepo-import-export] whikloj pushed 1 new commit to FCREPO-2340: https://git.io/v1w42
fcrepo-import-export/FCREPO-2340 fb7f144 Jared Whiklo: Return saveConfig() to its previous position.
* github-ff leaves
* westgard joins14:37
* dbernstein leaves
<westgard>ruebot: I have updated the pull request with the latest master14:38
* dbernstein joins14:41
* bseeger leaves14:42
<ruebot>westgard++ #team killing it!14:48
<dbernstein>escowles: this is small thing, but when you merge if you could make sure that you amend the author so it reflects the person who originally made the commit.14:49
just looking at 00944854d208a45f0ea60163907534342471694a…14:50
<escowles>dbernstein: sorry — i used github's squash-and-merge feature — i didn't realize it made me the author of the commit instead of you14:51
<westgard>fearless #leadership! -- ruebot++14:52
<ruebot>dbernstein: that's the merge commit isn't it - this is dbernstein's work, right? https://github.com/fcrepo4-labs/fcrepo-import-export/commit/046c056cb9a1ac0421d2fb8fd5d372eb04b7eebe
...or did github do something really strange?14:53
<escowles>ruebot: no, that's a different commit
this if for https://github.com/fcrepo4-labs/fcrepo-import-export/pull/53
it had two commits, and using squash-and-merge created a new commit with me as the author
* dbernstein leaves14:54
<escowles>it links to the PR which still has the original commits in it...
<ruebot>dbernstein: that's really weird
it was the middle option that did that? https://www.dropbox.com/s/vh2mxb8roayjkx9/Screenshot%20from%202016-12-09%2014-54-08.png
<escowles>yep14:55
<ruebot>weird. normally get git the buddy avatar thing. with the person doing the work as the big avatar, and the person merging as the little avatar14:56
<whikloj>westgard/ruebot: https://github.com/fcrepo4-labs/fcrepo-import-export-verify/pull/1215:06
<ruebot>whikloj: damn dude! nice work :-D15:08
<whikloj>escowles: danny's commit is there, just further down the list
https://github.com/fcrepo4-labs/fcrepo-import-export/commit/2ba1aaceccc6713aef244035fa0492e5bad2e6cb
<ruebot>whikloj++15:09
<escowles>whikloj: thanks for finding that — i didn't look past the following commit that wasn't from that PR, and didn't think it would be there further down15:10
<whikloj>escowles: Yeah we get two commits, so we know who to blame for writing the code and who to blame for committing it :)15:11
* acoburn leaves15:14
<ruebot>anybody having jira issues?15:17
<escowles>ruebot: i've got tons of jira issues assigned to me...15:18
* ruebot chortles
escowles++
* coblej leaves15:19
* coblej joins
<escowles>ruebot: i can't remember where we wound up with bag serialization - did we decide that writing unarchived bags was good enough, and people could tar/zip them up if they wanted to?
<ruebot>escowles: yeah, that sounds right.15:20
* acoburn joins
* coblej leaves15:24
* coblej joins15:34
* dwilcox_ leaves15:35
* informatician leaves15:54
* dbernstein joins15:57
<ruebot>escowles: you still good for putting on the lead hat for monday & tuesday?16:11
<escowles>ruebot: yep! i'll crack the standup whip16:13
<ruebot>escowles++
escowles: i'll send out an email to everybody later on this evening.
escowles: thanks again!
<escowles>ruebot++16:15
btw, ruebot, you're coming to cni, right?
<ruebot>escowles: yep!
escowles: ...wait, are you there too?
<escowles>i was planning on heading down to churchkey on sunday night to hang out with people in town
i'm not going to cni, but i do live in teh dc burbs
<ruebot>escowles: oh! excellent. dwilcox and i will be there, and manez is going to meet us too.16:16
<escowles>awesome, stroop will be there too, and probably lots of people
<ruebot>escowles: awesome!!!!!!!!!!
* github-ff joins16:19
[fcrepo-import-export] whikloj pushed 1 new commit to FCREPO-2340: https://git.io/v1wPO
fcrepo-import-export/FCREPO-2340 80901df Jared Whiklo: Close YamlWriter
* github-ff leaves
* github-ff joins16:21
[fcrepo-camel-toolbox] acoburn opened pull request #119: Generalize the audit container filtering (master...fcrepo-2320) https://git.io/v1wPg
* github-ff leaves
<ruebot>escowles: you good with awead's feedback on https://github.com/fcrepo4-labs/fcrepo-import-export/pull/54 ?16:29
escowles: ...or I should say, are those blockers, or should we create a couple improvement tickets?
awead++ #thanks for reviewing that one!16:30
<awead>sure1
!
<escowles>i think the first one is something i should address — the client should be checking the status and at least logging it appropriately
i.e., if a file fails, it should report the file and the error message received16:31
<ruebot>escowles++
<escowles>dunno about the second point — i think that's a bigger design question, so maybe we should make a ticket for that — we talked about the same thing with the verification tool, right?
<ruebot>escowles: yeah, i think so. westgard, does that sound familar?16:32
<westgard>ruebot escowles: yes, the verification tool, when it encounters a binary that should have been imported or exported, but it cannot open the file, it will throw and error and stop. It should record the error and continue.16:34
<ruebot>westgard++16:35
<westgard>There is a ticket to fix this problem already. There could be other similar fatal errors that should be handled.
So for the verification tool some comprehensive once-over looking for and handling all such possible errors should probably be done.16:36
* peichman leaves16:53
<apb18>acoburn: shall I merge fcrepo-camel-toolbox #119, or is there anybody else that should give it a look?17:03
* github-ff joins
[fcrepo-camel-toolbox] acoburn opened pull request #120: Dial back test logging (master...fcrepo-2344) https://git.io/v1wSG
* github-ff leaves
<acoburn>apb18: go right ahead; I'd like to wrap things up next week and give some folks an opportunity to test it before I release the new versions17:04
* coblej leaves
<apb18>acoburn: OK. Since it's just one commit, should I just rebase it on, or would it be best to merge commit?17:07
* th5 leaves
<acoburn>apb18: when I remember, I like to add the merge commit, but either way is fine17:08
<apb18>No prob, merge committing!
* github-ff joins17:09
[fcrepo-camel-toolbox] birkland closed pull request #119: Generalize the audit container filtering (master...fcrepo-2320) https://git.io/v1wPg
* github-ff leaves
<whikloj>escowles: are you working FCREPO-2335 (changing baseURL) or can I?
<acoburn>apb18++
<ruebot>whikloj: that's a phase-3 ticket, and technically out of scope for this sprint :-(17:12
<whikloj>ruebot: oh sorry, never mind besides the fact it appears if you change the source to be like http://localhost:8080/fcrepo/rest it already will work
<ruebot>whikloj: yeah17:13
<escowles>whikloj: it would be good to document what works now and what doesn't, but i agree with ruebot that it's a phase-3 ticket
<whikloj>escowles: Is there a test of it? I looked but couldn't tell
<escowles>whikloj: no, i have a branch (linked to from another ticket) with some tests17:14
<whikloj>escowles++
<escowles>https://github.com/fcrepo4-labs/fcrepo-import-export/pull/48
but that's more ambitious — trying to allow you to move stuff around in the repository, not just change the base URL17:15
<ruebot>westgard: we can close https://jira.duraspace.org/browse/FCREPO-2190 now, right?
...if so, that leave only two tickets left in our list!17:16
we crushed it today :-)
<whikloj>escowles: Yeah, I'm going to try moving from jetty to Tomcat with the existing code and see what happens17:17
<westgard>ruebot: yes, that was met by the addition of the logger and the update of the config file handling
<escowles>whikloj: i think that's the most important thing — lots of people will want to do that
* travis-ci joins17:18
fcrepo4-exts/fcrepo-camel-toolbox#310 (master - cf9a5b0 : birkland): The build was broken.
Change view : https://github.com/fcrepo4-exts/fcrepo-camel-toolbox/compare/fb9ac73f4f09...cf9a5b0f8230
Build details : https://travis-ci.org/fcrepo4-exts/fcrepo-camel-toolbox/builds/182731756
* travis-ci leaves
<whikloj>escowles/westgard/ruebot/dbernstein: Now that we have an audit log (assuming its good) should we shift all the import/export INFO messages to DEBUG?17:19
<escowles>whikloj: i don't know — i'm not sure how chatty people want the output to be17:20
either way, it would be nice to easily switch between terse and verbose logging output, since i'm sure some people will want the other one17:21
<whikloj>escowles: By easily you mean easier than -Dfcrepo.log.importexport=DEBUG ?
* ajs6f leaves17:22
<escowles>whikloj: yes, ideally with -v or -q
<ruebot>escowles++ whikloj++
whikloj: yeah, shifting to DEBUG would make sense to me17:23
<whikloj>we can also leave the messages where they are and move from INFO up to WARN based on a flag17:24
* github-ff joins17:25
[fcrepo-camel-toolbox] birkland pushed 2 new commits to master: https://git.io/v1wQV
fcrepo-camel-toolbox/master 5fda9db Aaron Coburn: Dial back test logging...
fcrepo-camel-toolbox/master 09000ac birkland: Merge pull request #120 from acoburn/fcrepo-2344...
* github-ff leaves
* acoburn leaves17:27
* travis-ci joins
fcrepo4-exts/fcrepo-camel-toolbox#310 (master - cf9a5b0 : birkland): The build was broken.
Change view : https://github.com/fcrepo4-exts/fcrepo-camel-toolbox/compare/fb9ac73f4f09...cf9a5b0f8230
Build details : https://travis-ci.org/fcrepo4-exts/fcrepo-camel-toolbox/builds/182731756
* travis-ci leaves
<whikloj>Ok so which is source and which is resource? If I'm exporting from /rest and importing to /fcrepo/rest17:28
* github-ff joins17:29
[fcrepo-import-export] escowles pushed 1 new commit to upload-fixity: https://git.io/v1w7G
fcrepo-import-export/upload-fixity b28a87a Esmé Cowles: Improving logging of upload failures, keeps importing after failures
* github-ff leaves
<escowles>ok, i'm heading out — have a great weekend everybody17:30
* dbernstein leaves
<ruebot>escowles++ take care!17:32
<whikloj>ruebot: Soooo if we store the export using the source URL, then how do I import it to a new host?17:33
I think we might need a destination to go with source, because we need the resource to match the URL when it was exported.17:34
So if I export from http://localhost:8080/rest/testObject
ruebot: Forget it, now I see what it only works for host/port17:35
<ruebot>whikloj++17:36
* travis-ci joins17:38
fcrepo4-exts/fcrepo-camel-toolbox#311 (master - 09000ac : birkland): The build passed.
Change view : https://github.com/fcrepo4-exts/fcrepo-camel-toolbox/compare/cf9a5b0f8230...09000acc3407
Build details : https://travis-ci.org/fcrepo4-exts/fcrepo-camel-toolbox/builds/182735290
* travis-ci leaves
* dbernstein joins17:39
* dwilcox joins17:40
<westgard>did I see earlier in the chat that there will be a Fedora standup at a pub in DC on Sunday?
<ruebot>westgard: "standup" yes :-)17:46
westgard: churchkey
<westgard>as in standing by the bar17:50
or maybe sitting down17:51
* apb18 leaves
<westgard>whikloj, ruebot: I'm not seeing the changes from pull request #10 in https://github.com/fcrepo4-labs/fcrepo-import-export-verify/pull/12, is it possible that PR#12 is behind master?17:54
<whikloj>westgard: yes17:55
I'll rebase it
<westgard>actually it's PR#11 that is missing
whikloj++
<whikloj>westgard: updated17:56
<westgard>whikloj++ Thanks a bunch
<whikloj>westgard: have a good weekend
<westgard>same to you. Time to call it a week!17:57
* dwilcox leaves17:58
<ruebot>westgard++
whikloj++
<whikloj>ruebot++17:59
I'm out
* whikloj leaves
<westgard>ruebot: So is there a time for this thing at churchkey? I will not be at CNI but I am local :-)18:01
<ruebot>westgard: not sure actually. i'm guessing people will start showing up 5-6ish?18:21
<westgard>ruebot: Thanks. Maybe I'll swing by! Would be fun to see everyone!18:32
I'm going to create a ticket and PR and then head out!18:33
thanks for all the help today
<ruebot>no problem!18:35
i'll shoot you an email on sunday once we sort out a time
if i forgot, just harass me on email :-)
* dwilcox joins18:36
<ruebot>have a good weekend!
<westgard>Thanks, ruebot++ Hope to see you Sunday.18:52
* westgard leaves
* awead leaves20:04
* dbernstein leaves22:22
* f4jenkins joins23:12
* dwilcox leaves23:14
* dwilcox joins23:15
* dwilcox leaves
* dwilcox joins23:16
* dwilcox leaves
* dbernstein joins23:49

Generated by Sualtam