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

Using timezone: Eastern Standard Time
* escowles_ joins02:23
* escowles leaves02:26
* bryjbrown joins07:05
* bryjbrown leaves07:18
* escowles_ leaves07:58
* escowles joins
* dhlamb joins08:43
* dwilcox joins08:47
* escowles_ joins08:48
* escowles leaves08:51
* benpennell joins08:53
* awoods joins08:56
* peichman joins09:09
* peichman1 joins09:10
* peichman leaves09:13
* yamil joins09:16
* escowles_ leaves09:17
* escowles joins
* bryjbrown joins10:07
* bryjbrown leaves10:11
<peichman1>awoods: should I expect 4.7.5-RC-1 tags on the various fcrepo4 modules (auth-*, audit, mint) for sanity build testing? or should I be using the 4.7.5-RC branches?10:18
<awoods>peichman1: good question. I do not think those tags exist... so the 4.7.5-RC branch is good for now.10:19
* awoods we should make the tags
(finally got some time to do the testing I said I would)10:20
* jonathangee leaves10:22
* Jebediah leaves
* Jebediah joins10:23
* jonathangee joins
<awoods>+1 peichman110:24
* github-ff joins10:38
[fcrepo-module-auth-rbacl] awoods tagged fcrepo-module-auth-rbacl-4.7.5-RC-1 at 1ea9d34: https://git.io/vN0cL
* github-ff leaves
* github-ff joins
[fcrepo-module-auth-webac] awoods tagged fcrepo-module-auth-webac-4.7.5-RC-1 at 99b14de: https://git.io/vN0cm
* github-ff leaves
* github-ff joins10:39
[fcrepo-mint] awoods tagged fcrepo-mint-4.7.5-RC-1 at b9ef835: https://git.io/vN0c3
* github-ff leaves
<awoods>peichman1: all tags should now be in place.
* travis-ci joins10:41
fcrepo4-exts/fcrepo-mint#80 (fcrepo-mint-4.7.5-RC-1 - b8ccfc0 : Jared Whiklo): The build passed.
Change view : https://github.com/fcrepo4-exts/fcrepo-mint/compare/fcrepo-mint-4.7.5-RC-1
Build details : https://travis-ci.org/fcrepo4-exts/fcrepo-mint/builds/330411188
* travis-ci leaves
* travis-ci joins10:43
fcrepo4-exts/fcrepo-module-auth-rbacl#153 (fcrepo-module-auth-rbacl-4.7.5-RC-1 - abfae37 : Jared Whiklo): The build passed.
Change view : https://github.com/fcrepo4-exts/fcrepo-module-auth-rbacl/compare/fcrepo-module-auth-rbacl-4.7.5-RC-1
Build details : https://travis-ci.org/fcrepo4-exts/fcrepo-module-auth-rbacl/builds/330410888
* travis-ci leaves
* whikloj joins11:01
<peichman1>so not tequila
<whikloj>serves him right for getting a nice vacation11:05
* bseeger joins11:10
* dshalvi joins
<whikloj>bseeger: you going to OR?
<bseeger>whikloj: yes11:12
<whikloj>awoods: ^^
<escowles>i was just saying that it would be great to organize a dinner to talk about fedora stuff — not sure what the schedule is going to be like, esp. for evening events
<benpennell>sorry just joined, forgot about the call (its a snowday here!)
<whikloj>benpennell: are you going to OR?
<bseeger>escowles: that sounds like a good idea11:13
<benpennell>whikloj: yeah most likely
<benpennell>i'll be at code4lib as well, that sounds good
<bseeger>I will not be there this year
<escowles>same for #c4l — i saw an email go by recently about social activities — i haven't seen the newcomer dinner schedule or other evening events yet11:14
<bseeger>wow, that's surprising - it usually sells out so quickly
<escowles>i think a breakout session would be a good idea11:15
#c4l schedule has even activities: http://2018.code4lib.org/schedule/ (newcomer dinners are tueday)11:17
i generally avert my eyes when windows machines are around11:20
<bseeger>I have window in my office - it doesn't open though. :(
<peichman1>whikloj: now who's showing off? ;-)11:28
* apb18 joins11:34
<benpennell>since i'm home due to snow, i'll see if I can do some of the windows tests11:35
<bseeger>It's probably apb1811:36
* apb18 it's me
will hang up and re-dial..
<peichman1>apb18 is no longer a tiny robot11:37
<apb18>I am a human-sized robot
I will need to confer with Ben Wallberg about scheduling my time once he gets back from vacation next qweek11:40
<bseeger>Same here - I need to talk with Este first, but will do that soon.
<peichman1>I should have an answer by Tuesday, 1/2311:41
* bryjbrown joins11:43
<benpennell>apb18: since I happen to have access to a windows machine for a change today, I was going to try running some of the simpler windows tests if that's okay11:46
formal identifiers for sidecar/extra specs
I imagine something like IETF RFCs, or Python's PEPs11:49
<apb18>benpennell: sounds good!11:50
peichman1, Yes, exactly. Like IETF RFCs (some of them are speculative/experimental, for example. Some die, some grow into a standard)11:51
.. or PEPs, except without the dictator part11:52
<peichman1>my vote is also for 3, 1, 211:54
* yamil leaves12:03
<whikloj>awoods: minutes up12:04
* yamil joins12:08
* bryjbrown leaves12:10
<benpennell>hmm, on windows 10 there are a couple of integration tests that are failing for me in fcrepo-kernel-modeshape in 4.7.4 and 4.7.5. If I go back to 4.7.0 I get slightly fewer failures.12:16
apb18: which version of windows were you testing with?
<apb18>benpennell: 1012:17
<awoods>apb18: are you seeing build failures?
<benpennell>its failing for me here, among a few other failures https://github.com/fcrepo4/fcrepo4/blob/fcrepo-4.7.4/fcrepo-kernel-modeshape/src/test/java/org/fcrepo/integration/kernel/modeshape/FedoraBinaryImplIT.java?utf8=%E2%9C%93#L22412:18
<apb18>awoods, benpennell let me try. I do know that there was some wierdness that involved time
<benpennell>the build passes though
with tests turned off
<apb18>I never saw such errors, but I think it was yinlin who observed time-related exceptions. The key difference between our environments was that I'm running on top of hyper-V, and he wasn't12:19
let me run tests now just to confirm.. but I don't expect any problems12:20
<whikloj>peichman1: https://github.com/victims/victims-web/issues/155
<benpennell>apb18: hm, its a virtualized windows setup?
<apb18>It's magically virtualized. Enabling hyper-v on a system with windows directly installed places the existing OS install into a hyper-v machine that looks and feels native.12:24
<benpennell>wonder why that would affect the last modified date in fedora...12:25
<apb18>Nobody was ever able to figure that out.
<benpennell>unless its the date math stuff
<apb18>I'm really not sure. I'd think that the notion of time (and hardware counters, etc) would be more problematic in a VM than out of one.12:29
.. but the results seem to be the opposite.
<whikloj>I built the RC, but when I dropped the fcrepo-webapp-4.7.5.war into tomcat 8 I get a java.lang.NullPointerException am I forgetting something?12:36
<awoods>not sure... I can try after our 1pm call.12:37
<apb18>whikloj: What is it that happens to be null?12:38
<whikloj>Maybe its my building, I had this same problem when trying to setup Fedora on openstack to test clustering. I thought it was memory related12:39
apb18: https://gist.github.com/whikloj/8720b2f2259c830c2a21ea8a2fe10b9f
I just pulled 4.7.4 out of this tomcat, so I am guessing it is my build12:40
<apb18>let me open eclipse and see what com.arjuna.ats.arjuna.objectstore.StoreManager.java:159 is looking for12:41
<whikloj>apb18: oh wait I tried to use the war from inside fcrepo4/fcrepo-webapp I didn't build the webapp-plus.12:42
* whikloj facepalms12:43
oh wait, I am facepalm free as it still fails.12:46
maybe I can't build fedora anymore
<apb18>whikloj, Whatever this is, is returning null: store = ClassloadingUtility.loadAndInstantiateClass(ObjectStoreAPI.class, storeType, name);12:49
probably 'storeType' and 'name' are coming from configuration, somewhere.
<whikloj>apb18: I'll try git bisect and see if I can figure out what caused this
<apb18>In the meantime, I'm trying to find where the relevant configuration lives, so that you can check it.12:50
<whikloj>apb18: ugh hang on, I didn't back out far enough and it rebuild fcrepo4-webapp and not fcrepo-webapp-plus. I might need to crawl under my desk for a bit.12:53
apb18: alright now it is broken for sure. I couldn't think of what in fcrepo-webapp-plus would be necessary (as I disabled audit and webac) but I am still getting that error. Moving to git bisect13:09
apb18: oh maybe the upgrade to modeshape 5.4.0 has something
* dbernstein joins13:22
* dwilcox leaves13:26
* bryjbrown joins13:58
* travis-ci joins14:01
fcrepo4-labs/Fedora-API-Test-Suite#44 (LDPNR-Test - c2f11fb : Jorge Abrego): The build has errored.
Change view : https://github.com/fcrepo4-labs/Fedora-API-Test-Suite/commit/c2f11fb08739
Build details : https://travis-ci.org/fcrepo4-labs/Fedora-API-Test-Suite/builds/330499564
* travis-ci leaves
* dwilcox joins14:07
* travis-ci joins14:10
fcrepo4-labs/Fedora-API-Test-Suite#47 (LDPNR-Test - 9397bbb : Jorge Abrego): The build passed.
Change view : https://github.com/fcrepo4-labs/Fedora-API-Test-Suite/compare/c2f11fb08739...9397bbb86f63
Build details : https://travis-ci.org/fcrepo4-labs/Fedora-API-Test-Suite/builds/330503206
* travis-ci leaves
<whikloj>peichman1: Are you running Fedora on Tomcat? My ^^ above problem deploying seems to come from the change to Narayana14:19
<peichman1>whikloj: yes, we use Tomcat 714:20
<whikloj>peichman1: is it a custom build or just a straight compile of the Fedora4 repo and deploy the fcrepo4/fcrepo-webapp/targets/fcrepo-webapp-X.X.X.war?14:21
<peichman1>I haven't tested it recently, but when I first tried a local version running Narayana, I was able to deploy it without issue to our dev server on Tomcat 7.0.7014:22
whikloj: custom build: see https://github.com/umd-lib/umd-fcrepo-webapp/
whikloj: and we are using this as our custom build of fcrepo4: https://github.com/umd-lib/fcrepo4/tree/fcrepo-4.7.4-umd-1.014:32
* bryjbrown leaves14:35
* apb18 leaves
* bseeger1 joins14:36
* bseeger leaves14:38
<whikloj>peichman1: would you be able to try deploying Fedora to your tomcat 7 again. On tomcat 8 I get a NullPointer error. I'm trying the release branch but I'll try master too
<peichman1>whikloj: sure; the stock 4.7.5-RC-1 release?14:39
<whikloj>peichman1: yes please
<peichman1>whikloj: on it
<peichman1>whikloj: to get the Tomcat 7 env, I will be loading it in an instance of our local fcrepo-vagrant setup: https://github.com/umd-lib/fcrepo-vagrant14:42
<whikloj>peichman1: that's fine. I'm just trying to figure out if this is something I am doing or what
<peichman1>whikloj: fcrepo-webapp-4.7.5-SNAPSHOT.war started up just fine on my Tomcat 7 Vagrant14:47
<whikloj>peichman1: thanks
<peichman1>Tomcat 7 vs. 8 issue, maybe?14:48
I know the JTA has some connection to the servlet container, I'm just not sure what it is
<whikloj>peichman1: I backed up to just before the Narayana commit and it builds and deploys fine on Tomcat 8. I just can't figure why it works for you and not for me14:49
peichman1: I'm going to try going to older versions and see if it changes anything
<peichman1>whikloj: good luck14:50
<whikloj>Anyone else want to give deploying on Tomcat a try. Maybe its my vagrant setup14:53
<peichman1>whikloj: my spring config for fcrepo contains this "Transactions configurations" section at the end: https://gist.github.com/peichman-umd/913f2d61e6e705a92bd8f8922aad30eb15:07
<whikloj>peichman1: yeah I'm seeing that in the default fcrepo4 too15:08
I was trying in my CLAW box, I'll try in a fcrepo4-vagrant box15:10
or maybe I'll try the custom UMD enviroment15:11
<awoods>whikloj/peichman1: I will be deploying shortly, tomcat815:15
* travis-ci joins
fcrepo4-labs/Fedora-API-Test-Suite#48 (LDPNR-Test - fb3c459 : Jorge Abrego): The build passed.
Change view : https://github.com/fcrepo4-labs/Fedora-API-Test-Suite/compare/9397bbb86f63...fb3c45999b80
Build details : https://travis-ci.org/fcrepo4-labs/Fedora-API-Test-Suite/builds/330527543
* travis-ci leaves
* bseeger1 leaves15:29
* travis-ci joins15:30
fcrepo4-labs/Fedora-API-Test-Suite#50 (master - 19bb7d2 : ibr-jabrego): The build passed.
Change view : https://github.com/fcrepo4-labs/Fedora-API-Test-Suite/compare/69cc57f01269...19bb7d2c22ac
Build details : https://travis-ci.org/fcrepo4-labs/Fedora-API-Test-Suite/builds/330532856
* travis-ci leaves
* travis-ci joins15:36
fcrepo4-labs/Fedora-API-Test-Suite#51 (Http-Head-Test-Modifications - 19bb7d2 : ibr-jabrego): The build passed.
Change view : https://github.com/fcrepo4-labs/Fedora-API-Test-Suite/compare/Http-Head-Test-Modifications
Build details : https://travis-ci.org/fcrepo4-labs/Fedora-API-Test-Suite/builds/330535456
* travis-ci leaves
* dwilcox leaves
* dwilcox joins15:37
<awoods>whikloj/peichman1: null pointer here as well15:38
<whikloj>awoods/peichman1: I'm going to try a very old version of Narayana and see what happens15:40
<awoods>whikloj: yes, I am reverting that change
* dwilcox leaves
<whikloj>awoods: no I'm not switching back to jboss-jta, but just not jumping so far into Narayana15:41
like maybe 5.0.0-Final which was released in Jan-201415:42
the Jbossjta 4.16.6 was released Oct 2012
jump 2 years instead of 515:43
http://victi.ms is back too15:45
<awoods>whikloj: fyi, reverting the narayana commit seems to fix the issue.15:51
<whikloj>awoods: yes I got that, but not clear why it works for peichman1 and not for us. What dark magic do they wield?15:52
awoods: Works with narayana-5.0.0-Final15:53
<awoods>whikloj: that is good news
<whikloj>awoods: I'll try 5.4.0 next, this is like manual git bisect15:54
I'll also not that tomcat has set end-of-life for tomcat 8 at June 30th, 2018. So get your Tomcat 9s ready :D15:56
note not not
* apb18 joins16:05
whikloj: There's still Tomcat 8.5.x alive and well, I use that for Fedora in Docker images. It even has HTTP/2!16:07
<whikloj>apb18: Ohhh I read that wrong, its EOL for 8.0.x I read 8.x
<apb18>Yeah. I tried Fedora in 9.x once, and it didn't immediately work; but 8.5 is just as good.16:09
<whikloj>setting up a 9 right now for Fedora Mysql tests, we'll see how it goes16:11
awoods: I'm back testing Narayana 5.1.0-Final, 5.4.0-Final and 5.2.0-Final gave me NullPointers16:12
<awoods>whikloj: which is the most recent version that works?16:15
<whikloj>awoods: so far only 5.0.0-Final has worked, then I jumped to 5.4.0 which fails, 5.2.0-Final which fails, building with 5.1.0-Final now
<apb18>whikloj: I had some luck looking at what it was doing in a debugger, i.e. what values were used when Fedora was able to successfully start.16:16
haven't provoked a null pointer in order to compare the difference, though.16:17
<whikloj>apb18: cool, there is clearly some configuration we need to do that UMD is doing. Just not clear what it is
* bryjbrown joins16:21
* dshalvi leaves16:24
<apb18>hm. I just deployed into Tomcat 8.5 and it worked OK.16:27
<whikloj>argh, I quit. I'm going to be a pancake artist...Oh yes mark my words I'll make the best pancakes you've ever seen16:29
<awoods>I like pancakes16:38
<whikloj>nothing works, I'm going to try 5.0.0-Final in case I have lost touch with reality and it never worked either16:39
* bryjbrown leaves16:40
<awoods>abp18: would you mind adding links to the proper projects in the API-X table: https://wiki.duraspace.org/display/FF/Release+Testing+-+4.7.5#ReleaseTesting-4.7.5-API-X
<apb18>So do I. I also tried a more 'vanilla' Tomcat 8.5 install (in Docker), and it worked too.
awoods: sure16:41
<whikloj>so what is docker doing that we aren't. Is it vagrant? Except this is the same error I got when I tried to test that clustering PR. I thought it was a memory issue and those were Centos VMs without Vagrant
* bryjbrown joins16:43
<peichman1>whikloj: apb18: I've updated my gist with the full spring.xml config we use: https://gist.github.com/peichman-umd/913f2d61e6e705a92bd8f8922aad30eb16:45
<apb18>whikloj: I don't know. Is this "from scratch in an empty Vagrant," or replacing the Fedora deployed in an existing Vagrant image (and if so, what is it)??
<whikloj>peichman1: thanks
<apb18>For Docker, I'm essentially starting from scratch
<whikloj>apb18: replacing, I've tried our CLAW-playbook and fcrepo4-vagrant16:46
<apb18>OK. Well, that's still significant. Patch releases are supposed to be drop-in.16:47
<awoods>apb18: agreed16:48
<whikloj>yes but for peichman1 and apb18 they are...so this doesn't seem to be a code issue, its a config issue
<apb18>whikloj: .. but you've essentially proven that there exists some config that is a problem. ...which is a problem :)16:49
<whikloj>apb18: oh....well in that case your welcome. My flap jacks are burning16:50
<peichman1>fwiw, my test was also a drop-in; I spun up our vagrant and it built itself using our 4.7.4 build, then I stopped tomcat and replaced it with 4.7.5
<apb18>i.e. it'd be ideal that it Just Work in your vagrant.
<whikloj>peichman1: your vagrant was too complex for me. Once I could read through the tears I had to give it up16:51
<peichman1>whikloj: yeah, it's pretty close to a full-on simulation of our prod environment
<apb18>whikloj: I'm going to take a look at your vagrant. If necessary, I'll remind myself how vagrant works and try running it.16:53
<whikloj>ok so 5.0.0-Final does work for me
* bseeger joins
<apb18>I think I'd need to reboot in order to do that16:54
<whikloj>but 5.0.6 does not
<apb18>(i.e. hyper-v co-opts the CPU instructions needed by VirtualBox, so I need to drop down into non-hyper-v mode)
<awoods>apb18/whikloj/peichman1: where are we landing on this topic? revert to a consistent version of narayana? or working out the details of the config?17:01
<whikloj>awoods: I'm still trying to see if I can get to the change in narayana that is causing this. I think we need to figure it out, but I can be convinced to leave it17:02
<apb18>I'm still in orbit, so landing is "on earth somewhere, at some point". I'd like to at least get an understanding of what specifically is going on. If config is a problem, what aspect of it?17:03
<awoods>thanks apb18 & whikloj: figuring out is always a strong approach. I just wanting to clarify the planned approach for landing this blocker.
<whikloj>awoods/apb18/peichman1: 5.0.4-Final worked and 5.0.6-Final doesn't. Trying 5.0.5-Final17:05
<awoods>whikloj: you are very logical
<whikloj>awoods: you should see my batter recipes
<peichman1>"fcrepo: your flap jacks are burning!" ;-)
<apb18>huh. I wonder what jts-openjdk is all about.17:08
I test with openjdk
* yamil leaves
<apb18>(well, Docker testing)
(which is where I'm running Tomcat)17:09
<whikloj>there is not much in there, except maybe https://github.com/jbosstm/narayana/compare/5.0.4.Final...5.0.6.Final#diff-c0a605781e1131ecaef55317dc4a04e6R4
which could be a different rabbit hole
* bryjbrown leaves17:10
<whikloj>apb18: https://issues.jboss.org/browse/JBTM-133917:11
not really an open-jdk thing at all17:13
<apb18>so "probably not relevant"
* apb18 twitches involuntarily17:14
The little ones will be home soon, so will see what's going on tomorrow.17:16
<awoods>thanks apb1817:17
* apb18 leaves17:18
<whikloj>crap 5.0.6 did work, my logic is broken17:28
<dbernstein>Hey everyone - sorry about the fcrepo4-vagrant failure to increment to 4.7.5. I will fix that.17:36
<awoods>dbernstein: no worries. thanks for handling that... although based on the other issues discovered today, it is not clear that vagrant will work yet.17:37
<dbernstein>awoods: ++ good point. But correct me if I’m wrong, no other changes to fcrepo4-vagrant (other than incrementing) should be necessary.17:44
Do I have that right?
something like that
* github-ff joins
[fcrepo4-vagrant] dbernstein deleted fcrepo4-vagrant-4.7.5-RC-1 at efc5739: https://git.io/vNEZx
* github-ff leaves
<awoods>dbernstein: I would be happy to test your local branch if that would be helpful.17:46
* bseeger leaves
* bseeger joins17:48
<dbernstein>awoods: shouldn’t the version be 4.7.5-SNAPSHOT? the tagged version 4.7.5-RC-1 has a version number of 4.7.5-SNAPSHOT.17:49
ie the pom.xml says 4.7.5-SNAPSHOT.
I consulted the team on this and I thought we were all on the same page, but perhaps my question wasn’t clear.17:51
<awoods>The vagrant config ultimately maps to a URL to download an artifact
dbernstein: ...which will either go to the fcrepo4 release (not auth) or to the fcrepo-webapp-plus release17:52
dbernstein: it looks like fcrepo-webapp-plus artifacts need to be added to github:17:53
<dbernstein>are those added manually?17:54
<awoods>dbernstein: yes, and renamed as <artifact>-4.7.5-RC-1.war17:55
<dbernstein>okay - I’ll do that.17:56
<awoods>dbernstein: the previous github RC releases should serve as good examples.17:57
* github-ff joins18:00
[fcrepo4-vagrant] dbernstein created increment-to-4.7.5-RC-1 (+1 new commit): https://git.io/vNEcg
fcrepo4-vagrant/increment-to-4.7.5-RC-1 59f6b6a Daniel Bernstein: Updates version to 4.7.5-RC-1
* github-ff leaves
* dhlamb leaves18:01
* whikloj leaves18:02
* github-ff joins
[fcrepo4-vagrant] dbernstein opened pull request #83: Updates version to 4.7.5-RC-1 (4.7.5-RC...increment-to-4.7.5-RC-1) https://git.io/vNEc7
* github-ff leaves
<dbernstein>awoods: https://github.com/fcrepo4-exts/fcrepo4-vagrant/pull/83 - are we on the same page?
<awoods>dbernstein: that is what I would expect... but things rarely go as expected. We can only know for sure by testing the four scenarios: auth+audit, auth-audit, -auth+audit, -auth-audit18:04
dbernstein: and since the app does not currently deploy (see conversation from earlier), I am not sure we can test any of those scenarios.18:05
dbernstein: ...or maybe...
dbernstein: ...we could remove the fcrepo*war artifacts from the local vagrant directory, then run each of the four configurations and make sure that the war download is successful.18:06
<dbernstein>ah - okay - I’ll copy those first.18:07
* bseeger leaves18:10
* peichman1 leaves18:49
* bryjbrown joins19:08
* bryjbrown leaves19:32
* bryjbrown joins19:42
* github-ff joins19:57
[fcrepo4-vagrant] awoods pushed 1 new commit to 4.7.5-RC: https://git.io/vNEu7
fcrepo4-vagrant/4.7.5-RC fb5424b Daniel Bernstein: Updates version to 4.7.5-RC-1
* github-ff leaves
* github-ff joins
[fcrepo4-vagrant] awoods deleted increment-to-4.7.5-RC-1 at 59f6b6a: https://git.io/vNEu5
* github-ff leaves
* peichman joins
* bryjbrown leaves20:55
* escowles_ joins21:20
* escowles leaves21:24
* peichman leaves21:25
* peichman joins21:30
* dwilcox joins22:16
* dwilcox leaves22:30
* awoods leaves22:39
* peichman leaves22:47
* whikloj joins23:02
* whikloj leaves

Generated by Sualtam