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

Using timezone: Eastern Standard Time
* thomz joins02:52
* dhlamb joins07:52
* dwilcox joins08:20
* coblej joins08:28
* dwilcox leaves08:34
* acoburn joins08:57
* github-ff joins09:00
[fcrepo-camel] acoburn opened pull request #133: Remove unmaintained example projects (master...fcrepo-2291) https://git.io/vXRk7
* github-ff leaves
<acoburn>awoods: the PRs in fcrepo-camel are starting to pile up: https://github.com/fcrepo4-exts/fcrepo-camel/pulls09:01
* dwilcox joins09:02
<awoods>acoburn: good morning09:07
<acoburn>awoods: and a good morning to you09:08
<awoods>acoburn: it looks like two of the three came in today or yesterday
<acoburn>awoods: yes, it would be nice to get those merged this week
awoods: there will be corresponding updates to fcrepo-camel-toolbox, but that can't happen until after we get a 4.5.0 release of fcrepo-camel out09:09
* jonathangee joins09:10
<awoods>acoburn: ok, I will get to them shortly.
<acoburn>awoods++
* dwilcox leaves09:12
* dwilcox joins09:13
* bseeger joins09:15
* dwilcox leaves09:16
* acoburn1 joins
* acoburn leaves09:19
* ajs6f joins09:28
* acoburn1 leaves09:36
* acoburn joins
<ajs6f>awoods: The two biggest issues left in the spec game, to my mind, are: in the CRUD spec chapter and the atomic op spec chapter.09:37
awoods: Create-on-PUT, against which barmintor has some objections about which I hope to hear specifics quite soon.09:38
awoods: And in the atomic op spec, whether we are talking about headers or URIs.
awoods: We are getting close.
<awoods>ajs6f: Nice work.09:39
<acoburn>ajs6f++
<awoods>ajs6f: It seems that you have a preference for headers over URIs re:atomic-ops
<ajs6f>awoods: I do. But to be clear, I don't think there's a strong answer here. As we've discussed in this forum before (and as professed by St. Roy Fielding) there isn't a natural way to do transactions in REST.09:40
awoods: I would like to hear from folks, but that is not easy to accomplish.09:41
<acoburn>ajs6f: I am in favor of using headers for batch ops
ajs6f: should this be a topic for a tech call?09:42
<ajs6f>acoburn: It was. We didn't get to it.
<awoods>ajs6f: One aspect of the question is: are the batch-op resources different resources than their non-batch-op counterparts?
<ajs6f>acoburn: 4.7.0 shenanigans got in the way.09:43
<acoburn>ajs6f: oh right
<ajs6f>awoods: Yes and no, of course. IF there is a common resource, they might be. But there will be resources that aren't in common, and resources that have been changed so subtantially that on some measures, you are dealing with two different things that are using the same URI.09:44
<awoods>ajs6f: I also wonder about passing the batch-op header around when linking from one resource to the next.09:45
<ajs6f>awoods: Why would that be especially difficult? Or are you talking about the fact that it's stateful?
* mohamedar joins09:46
* mohamedar leaves
<ajs6f>I tend to think of atomicity as a characteristic, a mode. To use it in a REST context, either we reify it and identify it (URIs, what we do now) or we expand the protocol. The first is gross because they aren't really resources in the same sense as every other thing we call a resource. The second is gross— it's flat out unRESTful.09:48
<awoods>ajs6f: There are probably several scenarios, but one is the simple browser navigation. Would you be able to view some resources in-the-transaction and others out-of-the transaction if there is a live transaction?
<ajs6f>We choose the flavor of nausea we like the most.
awoods: I'm not sure you would be able to work with a transaction easily or at all with a browser. That's not idea, I admit.09:49
awoods: You would have to control headers, not something for which a browser is wonderful. Now, we could put some Javascript on top, and that would do it.09:50
<awoods>ajs6f: What is the appeal of headers if they are not RESTful and they do not work intuitively in the browser?09:52
<ajs6f>awoods: The appeal is that they aren't URIs and don't present all the problems thereof. They don't pretend to identify a real resource.09:53
awoods: They don't repsent the problems of translating links.
awoods: They don't force us to create magic URIs like fcr:tx. They don't force implementors to figure out where to put those magic URIs and how to link to them, a problem exacerbated by create-on-pUT09:54
awoods: They let us inflect messages instead of the repository structure.
awoods: If we're going to see that anything changes between "I'm just working with a repo" and "I'm working with a repo inside an atomic op" I would prefer that it _not_ be the repo.09:55
awoods: It ought to be the meaning of the work "working".
* coblej leaves09:56
* coblej joins09:57
<ruebot>https://wiki.duraspace.org/display/FF/2016-11-07+-+Import-Export+Planning+Meeting09:58
smooooooooooooooooth jazz
<bseeger>jazz destoryer here09:59
* github-ff joins10:01
[fcrepo-camel] dannylamb closed pull request #133: Remove unmaintained example projects (master...fcrepo-2291) https://git.io/vXRk7
* github-ff leaves
* kestlund joins
<ajs6f>https://www.youtube.com/watch?v=Sc6V8BQS2BM&list=RDSc6V8BQS2BM#t=0
* coblej leaves
<ajs6f>Not my favorite, but some people liked it.
* escowles joins
<awoods>escowles: https://wiki.duraspace.org/display/FF/2016-11-07+-+Import-Export+Planning+Meeting10:02
<escowles>i'm getting "incorrect access code" — it's still 479307#, right?
<awoods>right10:03
<ruebot>escowles: yes
<ajs6f>https://www.youtube.com/watch?v=U2_h-EFlztY
He knows the access codes, for sure.10:04
<escowles>i'm here
* coblej joins10:06
<ruebot>kestlund++10:11
* peichman joins10:13
* mikeAtUVa joins
* amccarty joins10:15
Morning folks - I'm working with fcrepo 4.7.0 RC2 and for the life of me can't get the logging out of DEBUG mode - ADD_JAVA_OPTS looks like "-Dfcrepo.log=ERROR"10:16
<acoburn>amccarty: do you have a snippet of the logging output?10:17
<amccarty>acoburn: one sec
* osmandin joins10:18
<ruebot>https://jira.duraspace.org/browse/FCREPO-2284
<acoburn>amccarty: and I'm not familiar with ADD_JAVA_OPTS, where is that being set?
<ruebot>https://github.com/bseeger/fcrepo-sample-dataset-tests
https://github.com/fcrepo4-labs/fcrepo-import-export-verify
Those are the two tools
<amccarty>acoburn: sorry, doing that via puppet
<acoburn>amccarty: ok, I've never used puppet10:19
<amccarty>acoburn: here you go: https://gist.github.com/amccarty/17d0517e70745abca1d8a51451f4cfc610:20
not exactly a snippet, sorry :)
<bseeger>new repo: https://github.com/fcrepo4-labs/fcrepo-import-export-verify
<acoburn>amccarty: it seems that your root logger is configured at the DEBUG level — did you change the logback.xml file?10:23
<amccarty>acoburn: no - it looks like this: https://gist.github.com/amccarty/b89c4d2f6d7dcaee13c1ad015ddde05d10:24
<acoburn>what servlet container are you using?10:25
<amccarty>tomcat 7.0.4210:27
<acoburn>amccarty: are you overriding the logback config: -Dlogback.configurationFile=/path/to/logback.xml10:28
amccarty: i.e. in JAVA_OPTS?
<amccarty>acoburn: https://gist.github.com/amccarty/dc39f4278792ba47bdbf12973516594d10:30
<bseeger>snippet of current CSV output file: https://gist.github.com/bseeger/0c6f19a1e38c997670b02ed90b70139e10:31
<acoburn>amccarty: are you running this in a particularly small container?10:38
amccarty: i.e. < 2GB of RAM?
amccarty: nevermind — I was looking at the wrong value
<amccarty>acoburn: no - should i change my mem setting?
ok cool :)10:39
<acoburn>amccarty: actually, you set -Xmx twice, once as a very low value (256M) and once much higher — you should remove the first declaration10:40
amccarty: also, all the PermGen switches can be removed — they are no longer supported in Java8
amccarty: also, I would *highly* recommend setting the default encoding as UTF-810:41
<amccarty>acoburn: ok - where are you seeing that I'm not using UTF-810:42
* coblej leaves
* anarchivist leaves10:43
<acoburn>amccarty: there's no "-Dfile.encoding=UTF-8" in your JAVA_OPTS, which means the JVM will use the system default
<amccarty>ah, gotcha
<acoburn>amccarty: admittedly, that's typically UTF-8 on linux, but it's good practice to set this explicitly
<awoods>kestlund: https://github.com/fcrepo4-labs/fcrepo-import-export-verify
<acoburn>amccarty: I don't know why MODE is producing debug output, but what I would recommend is adding this to your JAVA_OPTS: -Dlogback.configurationFile=/path/to/logback.xml10:44
<kestlund>I'm happy to test in the off hours
<amccarty>acoburn: ok let me test that10:45
<acoburn>amccarty: and then directing logging output to a separate file: e.g. /var/log/fcrepo/fcrepo.log
amccarty: there's an example here: https://wiki.duraspace.org/display/FEDORA4x/Best+Practices+-+Fedora+Configuration
* anarchivist joins
<amccarty>acoburn: thx - been looking for some good examples like that10:46
<acoburn>amccarty: it may be just me, but I like to keep catalina.out pretty trim — just really serious errors go there; everything Fedora-related goes into a rolling logfile that's separate
<amccarty>acoburn: i like that idea - esp. when debugging (intentionally or not) :)10:47
<acoburn>amccarty: great, I hope this leads you down a good path10:48
<amccarty>acoburn: it will, thx10:49
* coblej joins
* whikloj joins10:52
<kestlund>Apologies, I need to leave the import/export call. Catch you next time.10:54
* kestlund leaves10:58
<awoods>All: it looks like ModeShape has pushed a patch release: https://github.com/ModeShape/modeshape/pull/1604#issuecomment-25887147311:03
So now we can move forward with Fedora 4.6.1
<acoburn>awoods: are we waiting on that before announcing 4.7.0?
<awoods>acoburn: yes... because we need to also provide an upgrade pathway.11:04
* thomz leaves
* ajs6f1 joins
<whikloj>Pretend 4.7.0 never happened11:05
<acoburn>awoods: so it's probably too early to start talking about a 4.7.1 release?
whikloj: too late, we've already deployed it
whikloj: plus, I've already written software that pulls 4.7.0 in from maven
<whikloj>acoburn: I didn't hear that
<awoods>whikloj: 4.7.0 looks good... it is just the 4.6.x that is the problem.
<acoburn>whikloj: blah, blah, blah
<whikloj>lalalala
* ajs6f leaves11:08
<awoods>escowles/mikeAtUVa: I am going to be creating a PR for reverting fcrepo-upgrade-utils-4.7.0 (backupfixer)... unless you think we should handle getting rid of it in another way.11:13
<mikeAtUVa>awoods: seems reasonable11:15
awoods: do we know what subset of backup
's are screwed up?
awoods: is there a feature or usage pattern that dictates whether yours will suffer the strange behavior Kevin Ford described after the restore?11:16
<awoods>mikeAtUVa: I am not sure I follow. From what I have seen, using the backupfixer corrupts the repository in a few different ways.
mikeAtUVa: I think the point is, don't use backupfixer, but instead upgrade to 4.6.1 (that includes the Mode4 patch) and do /fcr:backup from there.11:17
<mikeAtUVa>awoods: will do... was just curious why it seemed to work for Esme and myself.11:18
<awoods>mikeAtUVa: did you validate your restored repo?11:19
mikeAtUVa: for example, by iterating over all of the resources?
<mikeAtUVa>awoods: not every time. You're suggesting if I did, I'd find the problem.11:21
<awoods>mikeAtUVa: yes... I have seen the restore "work fine" in the sense that I can start up the restored repo... but some of the resources puke a 500 when I make a GET request on them.11:22
mikeAtUVa: basically, the backupfixer removes some screws from the repository, the impact of which is not always known until you start driving.11:23
<mikeAtUVa>awoods: in cases where the backup fixer only removed exactly one duplicate line? That seems really non-intuitive to me... but it's not important, I'll expend effort testing the new backup version.11:24
<awoods>mikeAtUVa: thanks.
* mikeAtUVa remembers why he's more comfortable writing software from scratch than relying on immense third party libraries.11:25
* github-ff joins11:35
[fcrepo4-upgrade-utils] awoods opened pull request #15: Revert "BackupFixer" associated with upgrading to Fedora 4.7 (master...fcrepo-2292) https://git.io/vXR2h
* github-ff leaves
<awoods>escowles/mikeAtUVa: https://github.com/fcrepo4-exts/fcrepo4-upgrade-utils/pull/1511:36
<ajs6f1>"the backupfixer removes some screws from the repository, the impact of which is not always known until you start driving"
That's the most Fedora thing I've heard in quite a while.
Sometimes there's a Mr. Bean-ish quality to our work.
<awoods>coblej: do you have Aisha's email address?11:38
jjtuttle: do you have Aisha's email address?11:39
* bseeger leaves11:40
<coblej>awoods: ayse.durmaz@duke.edu11:41
<awoods>coblej++
* ayd leaves11:44
<escowles>awoods: hypothetically, if someone had a backup from before the Modeshape patch, people would still be able to download the snapshot release to fix the backup, right?
(that's my only qualm about merging https://github.com/fcrepo4-exts/fcrepo4-upgrade-utils/pull/15)11:45
<awoods>escowles: what snapshot release?
<escowles>https://github.com/fcrepo4-exts/fcrepo4-upgrade-utils/releases/tag/fcrepo4-upgrade-utils-4.7.0-SNAPSHOT
<awoods>escowles: I would suggest we delete that tag as well11:46
escowles: do you have objections?11:47
<escowles>and if someone had an existing backup they wanted to restore...?
<awoods>escowles: any backup that has been touched by the backupfixer should be considered corrupt.
<escowles>if their repository is still working, they could upgrade and create a new backup
* github-ff joins11:48
[fcrepo4-upgrade-utils] mikedurbin closed pull request #15: Revert "BackupFixer" associated with upgrading to Fedora 4.7 (master...fcrepo-2292) https://git.io/vXR2h
* github-ff leaves
<escowles>awoods: sure — but sometimes a corrupt-but-restorable backup is better than a backup that can't be restored at all
oh, well — looks like we're overcome by events here11:49
<awoods>escowles: If they have a working 4.6 or less repo, then they should upgrade to 4.6.1, perform a /fcr:backup from 4.6.1, then restore into 4.7.0. I am not sure what scenario you are considering.
<escowles>the scenario i imagine is where they have a working 4.6 repo and are making backups, and then the repository fails and they want to restore the backup11:50
of course it would be good if they upgraded promptly, but we know people don't always do that
<awoods>escowles: got it. Something I did not mention was that 4.6 or less /fcr:backup works just fine if you are restoring into a 4.6 or less Fedora.11:51
<mikeAtUVa>escowles... sorry I didn't read this conversation until after I merged.
<awoods>escowles: it only has an issue if you want to restore into a 4.7 repo
<escowles>mikeAtUVa: don't worry about it — it's a pretty minor point i'm raising
<awoods>escowles: however, if the backupfixer has been used on the output of a 4.6 or less /fcr:backup, all bets are off.11:52
<escowles>and since awoods just said that we can restore the old backups into a =< 4.6.0 repo, then there's a path for anyone with an existing backup
<awoods>as long as they have not employed the backupfixer11:53
escowles/mikeAtUVa: shall we remove the tag: fcrepo4-upgrade-utils-4.7.0-SNAPSHOT ?
<escowles>awoods: sure
<mikeAtUVa>awoods: no objection here.
* travis-ci joins11:54
fcrepo4-exts/fcrepo4-upgrade-utils#15 (master - 9bfc094 : Michael Durbin): The build passed.
Change view : https://github.com/fcrepo4-exts/fcrepo4-upgrade-utils/compare/3002a9a29130...9bfc09416ec6
Build details : https://travis-ci.org/fcrepo4-exts/fcrepo4-upgrade-utils/builds/173954216
* travis-ci leaves
* github-ff joins11:55
[fcrepo4-upgrade-utils] awoods deleted fcrepo4-upgrade-utils-4.7.0-SNAPSHOT at ff42ba3: https://git.io/vXRrP
* github-ff leaves
* peichman leaves12:00
* peichman joins12:03
* coblej leaves12:07
* osmandin leaves12:10
* ajs6f1 leaves12:22
* dbernstein joins12:35
* acoburn1 joins12:45
* acoburn leaves12:47
* coblej joins
* escowles leaves12:57
* kestlund joins
* escowles joins
<kestlund>@ruebot: where is the sign-up for the next import/export sprint?13:06
<awoods>kestlund: I believe it is here: https://wiki.duraspace.org/display/FF/Design+-+Import+-+Export#Design-Import-Export-Sprinters13:17
kestlund: although that is a little misleading... as phase and sprints are not a one-to-one mapping
<kestlund>Thanks @awoods! That will do.13:18
<ruebot>kestlund: oh, you can just ping me, and i'll get them added. ...or if folks have questions email me and awoods.13:23
<kestlund>@ruebot Great Dan C. or I will confirm with you and awoods.13:25
<ruebot>kestlund: awesome!!13:28
* kefo joins13:30
* tolloid joins13:32
* dbernstein leaves13:38
* dbernstein joins13:39
* bseeger joins13:40
* osmandin joins13:57
* kestlund leaves14:07
* kestlund joins14:08
* osmandin leaves14:18
* coblej leaves14:21
* tolloid leaves14:24
<whikloj>awoods: modeshape 5.2.0.Final appears to be in maven central14:25
awoods: oh you need the 4.x branch for your patch14:26
<awoods>whikloj: indeed
<whikloj>awoods: mea culpa
<awoods>whikloj: master is at 5.2.0 right now: https://github.com/fcrepo4/fcrepo4/blob/master/pom.xml#L4914:27
* coblej joins14:28
* tolloid joins14:29
<whikloj>awoods: Is this not the Jboss repository? https://repository.jboss.org/org/modeshape/modeshape/
awoods: 'cause I don't see 4.6.2
awoods: augh
<awoods>whikloj: I am waiting on: http://search.maven.org/#artifactdetails%7Corg.modeshape%7Cmodeshape%7C4.6.2.Final%7Cpom14:30
<whikloj>awoods: Yeah I just wondered when it went into JBoss, I now see it as of 2 minutes ago.
* th5 joins14:32
* coblej leaves14:33
* escowles_ joins14:38
* escowles leaves14:42
* github-ff joins14:44
[fcrepo-camel] awoods closed pull request #131: Update to fcrepo-java-client 0.2.x (master...fcrepo-2287) https://git.io/vXcoB
* github-ff leaves
* travis-ci joins14:50
fcrepo4-exts/fcrepo-camel#318 (master - 1f9b3c0 : Aaron Coburn): The build passed.
Change view : https://github.com/fcrepo4-exts/fcrepo-camel/compare/27684fc4f388...1f9b3c06cb4a
Build details : https://travis-ci.org/fcrepo4-exts/fcrepo-camel/builds/174003726
* travis-ci leaves
* kestlund leaves14:57
* peichman1 joins
* peichman leaves14:59
* kestlund joins15:03
* ajs6f joins15:11
Interesting stuff from Michael Nelson's (he's one of the Memento people) group: https://ws-dl.blogspot.com/2016/11/2016-11-07-linking-to-persistent.html15:12
* coblej joins15:14
* escowles_ leaves15:18
* github-ff joins15:42
[fcrepo-camel] awoods closed pull request #132: Add a processor to handle Fedora's message serialization (master...fcrepo-2071) https://git.io/vX4Nk
* github-ff leaves
<acoburn1>awoods++ #thanks!
<awoods>np
thank you
* travis-ci joins15:49
fcrepo4-exts/fcrepo-camel#319 (master - e8c9ffc : Aaron Coburn): The build passed.
Change view : https://github.com/fcrepo4-exts/fcrepo-camel/compare/1f9b3c06cb4a...e8c9ffc9f9af
Build details : https://travis-ci.org/fcrepo4-exts/fcrepo-camel/builds/174020393
* travis-ci leaves
<acoburn1>awoods: dbernstein: just fyi, I'm making progress on the IdentifierConverter conversion, but it's slow going16:07
<dbernstein>that’s good to hear - ie that progress is being made. thanks for the update.
<acoburn1>dbernstein: I probably won't have anything to show until next week sometime16:08
* kestlund leaves16:16
<dbernstein>acoburn1: that sounds good. I have lots of other things to work on in the meantime.16:17
<acoburn1>dbernstein: me too :-)
<bseeger>awoods: do you know if the proposal for code4lib was submitted?16:22
<awoods>bseeger: no... could you ping esme?16:23
<bseeger>awoods: sure
* ajs6f leaves16:25
<bseeger>awoods: sending an email. It's unclear if the deadline is tonight at midnight or tomorrow at 5. The websites say two different things.16:26
awoods: or rather the main site says tonight and the proposal form says tomorrow at 5pm.
* peichman1 leaves16:27
* peichman joins
<tolloid>bseeger: hi bethany it’s tonight midnight PST16:28
bseeger: preconferences is tomorrow though at 8pm PST so lots of time for that16:29
<bseeger>tolloid: great - it's a workshop we want to propose
tolloid: thanks!
<tolloid>excellent
* peichman leaves
* peichman joins16:32
* peichman leaves
* bseeger leaves16:33
* peichman joins16:34
* osmandin joins16:38
* osmandin leaves16:40
* dwilcox joins17:01
* kefo leaves
* tolloid leaves17:15
* th5 leaves17:17
* coblej leaves17:25
* acoburn1 leaves17:34
* peichman leaves17:40
* github-ff joins17:46
[fcrepo4] acoburn opened pull request #1136: Replace deprecated methods with better versions (master...fcrepo-2294) https://git.io/vX02i
* github-ff leaves
* dwilcox leaves17:48
* whikloj leaves17:52
* dbernstein leaves18:09
* dbernstein joins18:10
* github-ff joins18:48
[fcrepo4] awoods pushed 1 new commit to master: https://git.io/vX0PI
fcrepo4/master 2ee05ca Aaron Coburn: Replace deprecated methods with better versions (#1136)...
* github-ff leaves
* travis-ci joins19:03
fcrepo4/fcrepo4#4834 (master - 2ee05ca : Aaron Coburn): The build was broken.
Change view : https://github.com/fcrepo4/fcrepo4/compare/4d76448841fa...2ee05ca81700
Build details : https://travis-ci.org/fcrepo4/fcrepo4/builds/174071115
* travis-ci leaves
* travis-ci joins19:44
fcrepo4/fcrepo4#4834 (master - 2ee05ca : Aaron Coburn): The build was broken.
Change view : https://github.com/fcrepo4/fcrepo4/compare/4d76448841fa...2ee05ca81700
Build details : https://travis-ci.org/fcrepo4/fcrepo4/builds/174071115
* travis-ci leaves
* awoods leaves20:02
* ajs6f joins20:07
* ajs6f leaves
* awoods joins20:12
* travis-ci joins20:53
fcrepo4/fcrepo4#4834 (master - 2ee05ca : Aaron Coburn): The build was broken.
Change view : https://github.com/fcrepo4/fcrepo4/compare/4d76448841fa...2ee05ca81700
Build details : https://travis-ci.org/fcrepo4/fcrepo4/builds/174071115
* travis-ci leaves
* dwilcox joins23:17
* dwilcox leaves23:25

Generated by Sualtam