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

Using timezone: Eastern Standard Time
<fasseg>eddies: Did you mean for leenata to run the ingestion tests locally or on the SCC cluster? because there's not enough space on here HDD (390GB free) to make such a large ingest... And for running these test on the cluster she needs all kinds or permissions from admins at FIZ....10:15
<eddies>fasseg: what test are you referring to?10:16
<fasseg>I already have these permissions, but I guess it'll take two or three days for leenata to get the persmissions as well, since it involves a SSH-Gateway and the actual cluster account
ingesting a large amount of data ~1TB or sth10:17
<eddies>i assumed that was on one of the clusters you (FIZ) has available as part of the SCAPE work
<fasseg>yeah thought so...but I guess leenata will have to work on sth different until the permissions are sorted out...10:18
hopefully tomorrow, I wrote on Friday...10:19
<pivotal-bot_>Andrew Woods added comment: "I believe the sparql-update wiki page is a placeholder for documenting how users can currently update objec..." https://www.pivotaltracker.com/story/show/5156610310:20
* ajs6f joins10:29
<cbeer>ajs6f: is SMW over fcrepo4 a good hackfest candidate, maybe?10:39
<ajs6f>cbeer: I might do that myself. eddies, you'd give the $500, right? :)
cbeer: it would mean adding a pair of new endpoints (Sparql query and update, in the usual "style") and hooking 'er up.10:40
Could be a real good project,
awoods: Did you already send that list in?
<cbeer>and sparql-query is either.. translating sparql queries to jcr queries, or delegating to an external store?
<ajs6f>Hm.10:41
Forgot about that.
<awoods>ajs6f, yes, I did... but more topics can still be submitted.
<ajs6f>It would have to be the latter, right? No one is going to impl Sparql algebra over JCR in a day...
Or maybe I'm misunderestimating the OR crowd?
<awoods>seems like creating an external sparql query component would be more practical.10:42
<ajs6f>Much more practical.
I don't even know whether anyone would want a Sparql-over-JQL component in the long term. Seems like a lot of work for synch.10:43
<cbeer>well.. if there was sparql over jql...
you could put SMW over plain modeshape?
<ajs6f>You'd also need Update. Then yeah.10:44
Actually, this is all about the semantic data. I'm honestly not sure right now how SMW is treating uploads, etc.
But for a lot of people (for UVa) the sem data would be enough.10:45
<awoods>presumably the UVa use of SMW would like more of the sensibilities that Fedora offers, than a vanilla modeshape? or not?10:46
<ajs6f>awoods: yep. The idea that is starting to form in my head (remember, I am an R & D guy, not a line engineer) is this:
We need to begin the migration away from document/record-centric description (MARC) to assertion-centric description (RDA Vocabs).10:47
We also would like to kill our ILS.
Kill it dead.
* leenata leaves
<ajs6f>Which means dismemberment: moving services apart and recoupling loosely. E.g. metadata provision.
Why shouldn't we take the opportunity to unify our physical-items description (MARC-> RDA) and our digital items description/management (Fedora)?10:48
And at the same time, begin exploring the various workflows that could support assertion-centric description?
No cataloger/archivist/curator is going to write RDF triples.10:49
There has to be some medium in which that work can occur. And a semantic wiki might be just the ticket.
There's also the possibility (which interests me) of combining formal and informal description. "Literate programming" for metadata. :)10:50
<cbeer>grr. i've spent 45 minutes trying to figure out how to configure the leveldb cache loader10:52
it's nicely documented in the wiki
<ajs6f>cbeer: Well, you did succeed in introducing me to leveldb. Which I had not heard of.10:53
<cbeer>but it was added after the CR2 was published :/
ajs6f: yeah, it looks interesting. maybe a better candidate for object persistence
<ajs6f>cbeer: You mean the binary stuff?10:54
<cbeer>ajs6f: the binary json structures, yes.
not the datastream content
<ajs6f>well, the most important thing is that it has Node.js libraries: http://dailyjs.com/2013/04/19/leveldb-and-node-1/10:55
That _is_ where we're going to migrate fcrepo4, right?
<cbeer>excellent. a node.js - scala hybrid10:56
<eddies>ajs6f: you missed my innocent activemq upgrade in fcrepo3 last year which brought in the one million leveldb dependencies that bloated fedora.war and that i had to write all the maven exclusions for
<ajs6f>We start by rewriting Node in Scala, and then impl'ing Scala in JS.
eddies: Really? Is that because AMQ offers a leveldb backend?10:57
<eddies>pardon, *further* bloated fedora.war
yeah, it's their ostensibly higher-performance alternative to kahadb
<ajs6f>I don't think we should _any_ library that doesn't have a leveldb dep.10:58
use
In fact, I'm going to write a MARC store using leveldb to replace our ILS.
<eddies>but i reasoned if you're deploying amq in-jvm along w/ fedora you're not really out for performance anyway so i excluded it
<ajs6f>eddies: Yep. Integrators should be integrating, not bloating the repo app itself.10:59
(With a broker.)
* github-ff joins
[fcrepo4] cbeer pushed 1 new commit to master: http://git.io/EHul_Q
fcrepo4/master 34fef55 Chris Beer: bump to ISPN 5.3.0.CR2
* github-ff leaves
<eddies>incidentally, speaking of bloat. i nuked my ~/.m2/repository, built fcrepo4 and ended up with ~/.m2 repository weighing in at 1.6GB
<ajs6f>Yowza.
<fasseg>*boing*
<ajs6f>But that includes source and tests… eh?11:00
Still.
eddies: So you're volunteering for Maven gardening.
?
<cbeer>ajs6f: joining us?11:01
<eddies>lol. i spent two days maven gardening and pruned *all* the dependency conflicts from *every* project
<ajs6f>omw
<eddies>i think i've done my maven penance for the year
<ajs6f>PRUNE ALL THE CONFICTS!
Then add them back in.
<pivotal-bot_>A. "Torbulater" Soroka added "Add microdata RDF to HTML API responses" https://www.pivotaltracker.com/story/show/5222926711:12
Chris Beer delivered "alter FedoraTransactions so that it no longer maintains the state of the transaction store inside the endpoint itself" https://www.pivotaltracker.com/story/show/5160251311:18
<bljenkins>Project fcrepo-fixity-corrupter build #163: SUCCESS in 1 min 41 sec: http://ci.projectblacklight.org/jenkins/job/fcrepo-fixity-corrupter/163/11:22
Yippie, build fixed!11:27
Project fcrepo-kitchen-sink build #421: FIXED in 7 min 25 sec: http://ci.projectblacklight.org/jenkins/job/fcrepo-kitchen-sink/421/
Project fcrepo-fixity build #348: SUCCESS in 7 min 27 sec: http://ci.projectblacklight.org/jenkins/job/fcrepo-fixity/348/
* ajs6f leaves11:28
* awoods leaves11:29
<cbeer>eddies: can you look at the broken kitchen sink deploy? http://fcrepo4.fcrepo.org/fcrepo/rest/
<eddies>sure11:30
* jcoyne joins11:32
* ajs6f joins11:33
* awoods_ joins
* aawoods leaves11:37
<ajs6f>All--11:41
I'm getting bags of errors trying to build fcrepo
in kernal:
FedoraResourceTest.testGetPropertiesDataset:217 » NoClassDefFound org/w3c/dom/...
FedoraResourceTest.testGetPropertiesDatasetDefaultLimits:239 » NoClassDefFound
FedoraResourceTest.testGetPropertiesDatasetDefaults:261 » NoClassDefFound Coul...
FedoraResourceTest.testGetVersionDataset:283 » NoClassDefFound Could not initi...
FedoraResourceTest.testGetVersionDatasetDefaultSubject:299 » NoClassDefFound C...
e.g. java.lang.NoClassDefFoundError: Could not initialize class com.hp.hpl.jena.rdf.model.impl.ModelCom
Anybody else seeing this?
<cbeer>nope11:44
<ajs6f>{sigh}
* awoods joins11:50
* travis-ci joins11:53
[travis-ci] futures/fcrepo4#768 (master - 34fef55 : Chris Beer): The build passed.
[travis-ci] Change view : https://github.com/futures/fcrepo4/compare/ba9cebff911a...34fef55ee2cf
[travis-ci] Build details : http://travis-ci.org/futures/fcrepo4/builds/8390588
* travis-ci leaves
<ajs6f>How bizarre… it appears to have abeen a corrupted _xerces_ jar in my local Maven repo. Oh, well.12:11
cbeer: looks like you were right on target. The oauth stuff never got a bean scanning facelift.12:23
Can I look at http-api to copy the right kind of spring?
<cbeer>yes
<ajs6f>Rockin'.
Well, actually borin'. But much better than frustratin'.12:24
Is anyone (besides me) planning on going to DLF in Austin this year?12:31
<cbeer>ajs6f: now that we're doing this @InjectedSession stuff, we could also do some auto-logout stuff, right?
<ajs6f>cbeer: remember the dynamic proxy Autocloseable Session thing I did a month or two ago? This is exactly why I wanted to know if we could do it. We can. So there's our auto-logout.12:32
When I get free and can do that.
<cbeer>cool.
<ajs6f>We'll have to decide on a clean syntax. That's a great source of beer-debates for Charlottetown.12:33
If only we have Scala's type system..
but no.
<cbeer>https://wiki.duraspace.org/display/FF/2013-07-xx+Open+Repositories12:35
now we have a list :)
<ajs6f>+1 :)
<eddies>cbeer: did you do something to kitchen-sink on futures6?13:03
i just got off a call and was going to look at it, but futures6 isn't erroring out anymore
ah, wait. now it is
nm
weird
<cbeer>yeah. iirc, the multipart thing was a transitive dependency somewhere13:06
but i thought that was only an issue for testing
<eddies>no i think i see what it is. i made fcrepo-webapp into a "skinny war"13:07
because of the duplicated dependencies we were seeing kitchen-sink
but a consequence of that is kitchen-sink needs to explicitly declare the fcrepo-* dependencies we declare in fcrepo-webapp13:08
(e.g. fcrepo-http-api)
i thought our kitchen-sink sanity test was supposed to catch the webapp blowing up though13:09
nope. that wasn't it. kitchen-sink pom had explicitly declared jersey-multipart as test scoped so it wasn't making it into the war. and i was wrong about needing to explicitly declare fcrepo-* dependencies in kitchen-sink.13:20
i forgot i made fcrepo-webapp now generate a "classes" jar, too, specifically so we only need depend on that to get the transitive dependencies13:22
i'm thinking for the dev challenge we might need another local nexus repo set up.13:23
i'm at 1.8GB in my maven repo and i've only built fcrepo4 & kitchen-sink13:24
that's a *lot* to expect folks to bring down at a conference of ~500 saturating the wifi
<cbeer>fully saturate the PEI pipes :)13:26
<bljenkins>Project fcrepo-kitchen-sink build #422: SUCCESS in 6 min 7 sec: http://ci.projectblacklight.org/jenkins/job/fcrepo-kitchen-sink/422/13:29
* ksclarke makes a note to build before attending13:30
<cbeer>probably a good idea
<eddies>interestingly enough, the fedora 3.6.1 webapp weighs in at 57MB (i don't have 3.6.2 built at the moment). fcrepo(4)-webapp weighs in at 58MB13:33
maybe a repository app just needs to be that size :P
ooo. so pretty: http://fcrepo4.fcrepo.org/fcrepo/rest/13:34
cbeer++
<cbeer>just wait until a real designer gets their hands on it
<eddies>what is the difference between a folder and object?13:35
<cbeer>no idea.
<eddies>i might have thought (maybe) a folder was an nt:folder but not a fedora object13:36
ah. that is what it is. i thought i had tested that before and it was still giving me a fedora:object in both cases13:38
i don't think we actually want people creating nt:folders that are not fedora:objects
<cbeer>+1
<eddies>aside from nuking this from the form. how/where to enforce this? i had mentioned a similar flavor of thing when implementing the webdav support. if we were relying on sequencers to add the appropriate mixins, we wouldn't have to care if folks were creating nt:folders via whatever means, but since we don't want at least the fedora:object/fedora:datastream mixins to be added async, where's the right chokepoint for at least our own rest api?13:42
<cbeer>do we really want to enforce it?13:43
it'd be nice if downstream implementors could extend our fedora:objects and all that
to add their own properties or required children or whatever
<eddies>well, i fully expect people to *add* more mixins as that seems the closest path to validated cmodels13:44
but shouldn't we at least require everything be at least either a fedora:object or fedora:datastream?
<cbeer>it doesn't seem necessary to me.. it's not like those mixins are actually meaningful anyway13:45
oh - but, maybe we should do some rdf translation from e.g. nt:file => fedora:datastream?13:46
to preserve some notion of not being tied to jcr
<eddies>well that's just because we're not presently demanding much of those mixins.
yeah, that sounds right to me13:47
<cbeer>eddies/awoods: now that the kitchen sink is back, can you accept some tickets?
<eddies>oh, i came across this today, evidently from the same folks who did mongo is webscale. i think i'm going to reference this in my slides at OR: http://www.xtranormal.com/watch/13654333/every-discussion-about-rest-ever13:48
<awoods>cbeer: I would like to... stay tuned.
* github-ff joins13:53
[fcrepo4] eddies pushed 1 new commit to master: http://git.io/td-pyQ
fcrepo4/master 7df261c Edwin Shin: remove "folder" as a mixin option from the views
* github-ff leaves
<bljenkins>Project fcrepo-fixity-corrupter build #164: SUCCESS in 1 min 50 sec: http://ci.projectblacklight.org/jenkins/job/fcrepo-fixity-corrupter/164/14:11
<cbeer>wow. i think the filecachestore is.. absurdly slow.14:14
sorry, cache loader.14:15
<eddies>ooo. does portend some good news?
*does that
<cbeer>i'm just going to double check that my laptop didn't get much faster over the weekend14:16
<eddies>heh
<bljenkins>Project fcrepo-fixity build #349: SUCCESS in 6 min 43 sec: http://ci.projectblacklight.org/jenkins/job/fcrepo-fixity/349/
Project fcrepo-kitchen-sink build #423: SUCCESS in 7 min 15 sec: http://ci.projectblacklight.org/jenkins/job/fcrepo-kitchen-sink/423/
<cbeer>eddies: i swapped out the file cache loader for the object properties for the BDB one14:18
and created 1000 objects
with the file loader:
real 1m25.516s
user 0m5.000s
sys 0m2.971s
with bdb:
real 0m57.509s
user 0m5.009s
sys 0m2.891s
<eddies>well hot diggity14:19
<cbeer>and i've figured out how to do leveldb
if that pans out, i'm going to swap in leveldb by default
<eddies>what's weird is…i don't remember berkeley db being terribly fast14:20
(that is the bdb store, right?)14:21
<cbeer>yes
<ajs6f>Maybe there's something weird/bad in the filecache impl in ISPN?
<eddies>oh wait. sorry. i was thinking dbxml14:22
man. i've been getting all sorts of things backwards/confused today. i should avoid making any critical decisions today :P
<ajs6f>have another glass of cognac.14:23
<eddies>i had a very nice saison at dinner
it was 9.5%, so maybe that's partially to blame14:24
cbeer: leveldb looks even more promising by these numbers: http://highscalability.com/blog/2012/11/29/performance-data-for-leveldb-berkley-db-and-bangdb-for-rando.html14:25
never heard of bangdb before
on leveldb: "Write and Read are concurrent for the db, but write performs best with single thread whereas Read scales with number of cores"14:26
<cbeer>ok - so the thing in master is just the native java leveldb14:29
if i want to do it now, i have to do some JNI stuff14:30
i think i'm too lazy for that
according to JIRA, ISPN 5.3.0 is supposed to be released tomorrow
<ajs6f>Unless we're really confident about leveldb, we might not want to use JNI anyway. A bad fault in there could take down the JVM, and that's a mean surprise for sysops.14:31
<cbeer>s/i think i'm too lazy for that/ that ^ /
:)
<eddies>*tada!*
<ajs6f>Problem solved!
<cbeer>i'll give the native java impl a try whenever 5.3.0 gets released14:32
<eddies>what other store options are there?
<cbeer>lots of them:
https://docs.jboss.org/author/display/ISPN/Cache+Loaders+and+Stores
<eddies>(i'm sure there's a wiki page somewhere…ah that's what i was looking for)
<cbeer>i was looking at these because they're file-system based
but there's some jdbc and mongo options
<eddies>barmintor is texting me from paris. while he's downing a bordeaux. show-off ;-)14:37
<ajs6f>Says the guy who used to live in Paris.14:42
<eddies>actually, seems like we want to default to something like bdb anyway15:00
if we go to the trouble of implementing and using transactions, but then you store over a vanilla filesystem, it kinda all goes to hell anyway15:01
well, it could
and a 30% performance increase, well, that's just peachy15:02
<ajs6f>does the xactionality of the underlying store get promulgated all the way up to our API?
<cbeer>eddies: from that article, though, i think it makes sense to hold out for leveldb15:03
ajs6f: to the extent we expose sessions, i think.15:06
<ajs6f>Cool.
Yet another reason rhauch pushed us to use Sessions for xactions.
<cbeer>although workspace merges are scoped by a session too15:07
<ajs6f>But we were going to map xactions to wses, not ws merges, right?15:08
* github-ff joins15:12
[fcrepo4] ajs6f pushed 1 new commit to master: http://git.io/htA0Ew
fcrepo4/master b65044c ajs6f: Fixed small mistake in InjectableSession
* github-ff leaves
* github-ff joins15:14
[fcrepo-auth-oauth] ajs6f pushed 1 new commit to master: http://git.io/LPPQkw
fcrepo-auth-oauth/master bd1a9d4 ajs6f: Updating to use package-scanned *Service beans
* github-ff leaves
<ajs6f>eddies: Jenkins is giving me:15:17
Caused by: java.net.BindException: Address already in use
for fcrepo-oauth?
How could that be happening? Two build at once pick the same address for i-tests?
<eddies>hmm. are you using the build-helper maven plugin in the oauth project (see any of fcrepo4 modules that have ITs)15:18
<bljenkins>Project fcrepo-auth-oauth build #3: STILL UNSTABLE in 3 min 46 sec: http://ci.projectblacklight.org/jenkins/job/fcrepo-auth-oauth/3/
<ajs6f>No idea. I'll check
No— should it be using that?15:19
What is it, anywa?
<eddies>that's the plugin i added to reserve a random port
specifically so you don't deal w/ port conflcts15:20
<ajs6f>Oh, right on, brother.
<eddies>ah. and double check the jenkins job for oauth to make sure jenkins isn't reserving a static port. i think there were some old jobs that were passing in -Dtest.port=XXXX
i don't know who set up the jenkins job for the oauth project, but if was a copy of a job that was hard-coding that port assignment, that may have carried over15:21
hold on, i'll just check for you
hrm. if jenkins wasn't slow as a dog...15:22
ah yes, http://ci.fcrepo.org/jenkins/view/FF/job/fcrepo-auth-oauth/configure shows a build goal that includes "-Dtest.port=9876 clean install"15:23
* github-ff joins15:24
[fcrepo-auth-oauth] ajs6f pushed 1 new commit to master: http://git.io/C2KV7Q
fcrepo-auth-oauth/master 09fa6b5 ajs6f: Use the power of build-helper-maven-plugin!
* github-ff leaves
<eddies>ok. so i nuked that. if you add the build-helper plugin you should be good to go
<ajs6f>I just punched the build-helper-maven-plugin, let's see what happens...
Greuvy. That did it.15:26
I'll stick it in the kitchen-sink later this afternoon.
Thnx eddies
afk
<eddies>ajs6f: i was saying in my email that i think it should be wired into fcrepo-webapp, not kitchen-sink15:27
<bljenkins>Yippie, build fixed!15:28
Project fcrepo-auth-oauth build #4: FIXED in 4 min 21 sec: http://ci.projectblacklight.org/jenkins/job/fcrepo-auth-oauth/4/
<eddies>cbeer: one interesting note about leveldb (dunno about bdb) is that performance is poorer with larger values because it's essentially writing twice, once to the transaction log and then again to a sorted file15:30
http://leveldb.googlecode.com/svn/trunk/doc/benchmark.html
<cbeer>eddies: if teh object structure get that big...15:31
<eddies>on the other hand, for a larger numbers of key values, bdb evidently has a drop off that folks aren't observing w/ leveldb
well, that's true =)15:32
we can't really prevent people from hanging themselves with the rope we provide
but i can see getting to 100KB without too much difficulty as you start tacking on rdf statements15:34
well, actually, i don't know how those jcr:props translate into whatever gets persisted to the cache store15:35
(in terms of footprint)
i do remember folks posting about adding some tremendously lengthy tracts as string literals in their RELS-EXT datastreams15:37
<bljenkins>Project fcrepo-fixity-corrupter build #165: SUCCESS in 7 min 10 sec: http://ci.projectblacklight.org/jenkins/job/fcrepo-fixity-corrupter/165/
Project fcrepo-fixity build #350: SUCCESS in 10 min: http://ci.projectblacklight.org/jenkins/job/fcrepo-fixity/350/15:41
* travis-ci joins16:00
[travis-ci] futures/fcrepo4#769 (master - 7df261c : Edwin Shin): The build passed.
[travis-ci] Change view : https://github.com/futures/fcrepo4/compare/34fef55ee2cf...7df261ce484a
[travis-ci] Build details : http://travis-ci.org/futures/fcrepo4/builds/8396384
* travis-ci leaves
<cbeer>ok, got leveldb sorted out16:09
one of the transitive dependencies had a mac-only bug
real 0m48.271s
not appreciably faster than bdb
<ajs6f>eddies: webapp? You sure?16:14
<eddies>i think so. the webapp should have auth. we might change horses on the impl later. but oauth is what we have today16:15
PATCHES WELCOME ;-)16:16
<cbeer>should it? really?
(Fedo would be disappointed.)
<ajs6f>eddies: I have no intention of patching this cruft. I'll be busy working on fcrepo-auth-shibboleth.16:17
* github-ff joins16:19
[fcrepo4] cbeer pushed 4 new commits to master: http://git.io/_RjVaA
fcrepo4/master 6680bb2 Chris Beer: bdb-backed object store
fcrepo4/master bf8c368 Chris Beer: better placeholder for creating new objects
fcrepo4/master 52afe72 Chris Beer: Create an example leveldb-backed infinispan config
* github-ff leaves
<cbeer>i'm sure there was a ticket for the alt. cache loaders
oh well16:20
<ajs6f>afk16:21
* ajs6f leaves
* ajs6f joins16:24
cbeer: Was that a serious question about oauth-> webapp or were you just joking?16:26
<cbeer>ajs6f: serious. i'm not sure authn (and especially a particular form of authn) is actually a core concern
<ajs6f>good. 'cause I gree.
agree.
Especially not the half-assed crap I foisted on us as an impl.16:27
* travis-ci joins16:30
[travis-ci] futures/fcrepo4#770 (master - b65044c : ajs6f): The build passed.
[travis-ci] Change view : https://github.com/futures/fcrepo4/compare/7df261ce484a...b65044ca0a48
[travis-ci] Build details : http://travis-ci.org/futures/fcrepo4/builds/8398847
* travis-ci leaves
<bljenkins>Project fcrepo-fixity-corrupter build #166: SUCCESS in 3 min 1 sec: http://ci.projectblacklight.org/jenkins/job/fcrepo-fixity-corrupter/166/16:51
* ajs6f leaves16:55
* ajs6f joins16:57
<awoods>seems like we have some clustering details to work out...17:03
javax.jcr.InvalidItemStateException: This session tried to save changes to node with key 'Cannot locate child node: 87a0a8c317f1e70558d026-8035-45d5-8c88-032acd6e36d5 within parent: 87a0a8c317f1e7jcr:versionStorage', but it was removed by another session.
This is a common error in the jmeter tests.
Or it may just be that the tests are so fast that the round-robin load balancer services requests out of sequence.17:05
* ajs6f leaves17:18
* travis-ci joins17:24
[travis-ci] futures/fcrepo4#771 (master - 0f06b15 : Chris Beer): The build passed.
[travis-ci] Change view : https://github.com/futures/fcrepo4/compare/b65044ca0a48...0f06b1570125
[travis-ci] Build details : http://travis-ci.org/futures/fcrepo4/builds/8401110
* travis-ci leaves
* fasseg leaves17:29
<cbeer>awoods: i'm going to move some of our Features + FAQs pages to something like https://docs.jboss.org/author/display/ISPN/Contributing+to+Infinispan17:42
probably will subsume some of the misc tech team pages too17:43
<awoods>cbeer: you mean that you will be creating "an outline" of our pages?
with a logical flow?17:44
<cbeer>something like that.. probably copying their structure directly.
it seems pretty solid
<awoods>I do not see "features" on their page
<cbeer>awoods: sorry -- what i mean is, i really like their contributing to infinispan page17:45
and i'm going to make a fedora analogue.
<awoods>sure
<cbeer>by moving pages from our features and faqs section
into that (nearly blank) contributing page we have
<awoods>I am sure you will make it just right.17:46
<cbeer>k. i just wanted to warn you before pages go flying.
<awoods>I am braced
* jcoyne leaves18:18
* github-ff joins18:35
[fcrepo4] cbeer pushed 1 new commit to master: http://git.io/b7tZLw
fcrepo4/master 9beffae Chris Beer: reformatting to remove tab characters
* github-ff leaves
* ksclarke leaves18:50
<bljenkins>Project fcrepo-fixity-corrupter build #167: SUCCESS in 49 sec: http://ci.projectblacklight.org/jenkins/job/fcrepo-fixity-corrupter/167/
* travis-ci joins19:18
[travis-ci] futures/fcrepo4#772 (master - 9beffae : Chris Beer): The build passed.
[travis-ci] Change view : https://github.com/futures/fcrepo4/compare/0f06b1570125...9beffaeb38ce
[travis-ci] Build details : http://travis-ci.org/futures/fcrepo4/builds/8405270
* travis-ci leaves
<cbeer>ok, leveldb is a little bit faster than the file cache store..19:42
it tooks 40m to make 5000 objects before
with leveldb, its done the same in 10m.19:43
<awoods>that could be considered more than a little faster.19:57
<cbeer>just trying to not get eddies hopes up.20:09
looks like it still has some slow-down at volume though20:18
maybe that's unavoidable in the flat hierarchy20:19
* jcoyne joins21:00
* jcoyne leaves21:05
* ksclarke joins21:06
<bljenkins>Project fcrepo-fixity build #351: FAILURE in 5 hr 4 min: http://ci.projectblacklight.org/jenkins/job/fcrepo-fixity/351/21:52
Project fcrepo-kitchen-sink build #424: FAILURE in 6 hr 21 min: http://ci.projectblacklight.org/jenkins/job/fcrepo-kitchen-sink/424/
Yippie, build fixed!22:05
Project fcrepo-kitchen-sink build #425: FIXED in 12 min: http://ci.projectblacklight.org/jenkins/job/fcrepo-kitchen-sink/425/
Yippie, build fixed!22:09
Project fcrepo-fixity build #352: FIXED in 16 min: http://ci.projectblacklight.org/jenkins/job/fcrepo-fixity/352/