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

Using timezone: Eastern Standard Time
* github-ff joins00:16
[fcrepo-camel-toolbox] birkland closed pull request #125: Update the ActiveMQ pooling defaults (master...fcrepo-2357) https://git.io/v1XCv
* github-ff leaves
* travis-ci joins00:28
fcrepo4-exts/fcrepo-camel-toolbox#320 (master - 06561b0 : birkland): The build passed.
Change view : https://github.com/fcrepo4-exts/fcrepo-camel-toolbox/compare/eeda117c3f6e...06561b0c1bf1
Build details : https://travis-ci.org/fcrepo4-exts/fcrepo-camel-toolbox/builds/183819948
* travis-ci leaves
* escowles leaves00:59
* escowles joins
* dbernstein leaves02:24
* thomz joins03:05
* github-ff joins07:10
[fcrepo-import-export] escowles deleted bag-profile at 067d7d2: https://git.io/v1M0d
* github-ff leaves
* github-ff joins07:11
[fcrepo-import-export] escowles deleted custom-membership at adb55f5: https://git.io/v1M0x
* github-ff leaves
* justinsimpson joins08:19
* coblej joins08:25
* dhlamb joins08:30
<justinsimpson>[Import/Export standup]
*yesterday: updated documentation in wiki for https://jira.duraspace.org/browse/FCREPO-2226
*today: very little, travelling today
*blockers: none
escowles: impressive two days!
* jjtuttle leaves08:41
* manez leaves08:42
* jjtuttle joins08:43
* dwilcox joins08:49
* bseeger joins09:01
* acoburn joins
<escowles>ruebot: thanks!09:07
ruebot: i wonder if you have any thoughts about user-supplied metadata — dbernstein & i thought starting out with a JSON file to provide it made sense (b/c a lot is boilerplate repeated across bags), but then some is unique to each bag, so maybe command-line params too?09:09
the other issue i see there is the aptrust fields (title and access) — i'm not sure how far we should go in modeling tag files vs. just having an e.g., aptrustTitle field09:10
<ruebot>escowles: yeah, i'll have to look in detail at what y'all have come up with. i naively thought i'd have time to keep up with stuff at CNI, but wow. NOPE.09:15
<escowles>ruebot: heh, i'm not surprised09:17
dbernstein is working on user-supplied metadata, and i expect the first pass to be just a JSON file09:18
<ruebot>escowles: also, hotel fire and 2hrs our sleep yesterday, and a 8:45am presentation :-(
<escowles>yeah, saw that on twitter — that's rough
<ruebot>escowles: ah cool. so this would be a bag profile on demand in a way?
<escowles>that's what i'm trying to reconcile — is the metadata part of the profile, or separate, or kind of overlapping09:19
e.g., do people want to take their profile and edit it to include their org/contact info/etc.? or does that live in a separate file?
<ruebot>escowles: oh! i see :-)09:20
escowles: yeah, that is a really good design question.
<escowles>i can't work on enforcing the profile requirements on user-supplied metadata until we have it figured out, so i think i'm going to start a wiki page and lay out all the fields09:21
so we can decide what goes in the profile, what goes in a sidecar metadata file, and what goes in command-line args
<bseeger>Is it typical to get a 304 Error + exception when clicking on the 'REST API' button on the index.html page? I see this with debug turned on. Perhaps it's a non-issue?09:25
or expected
<escowles>bseeger: that's not what i would expect — but i know there have been issues with the HTML UI and caching, so maybe this is a new wrinkle?09:27
<bseeger>escowles: okay - thanks. I'll file a ticket for it09:28
<acoburn>bseeger: are you seeing the error in the servlet log?09:29
<ruebot>escowles: i like the wiki idea
<bseeger>acoburn: yes
acoburn: v
acoburn: https://gist.github.com/bseeger/3fc49aa92f4fb8fed58eaf1d181c44be
<acoburn>bseeger: that seems strange that a 3xx response would generate an "error"
<bseeger>acoburn, escowles: note that I have debug turned on.09:30
<acoburn>bseeger: yes, but still…
bseeger: it looks like that would be expected, given how the code is written09:35
bseeger: if the Request::evaluatePrecondition has a match, the response is null, which causes a WebApplicationException to be thrown
bseeger: and in debug mode any WebApplicationException shows the whole stack trace09:36
it would be nice if the whole stack trace wasn't shown
<bseeger>acoburn: yeah, it makes it look as if there's a problem when there isn't.09:38
<dhlamb>acoburn, escowles et al. any idea where the paths for 'transaction.log' and 'velocity.log' gets set in config? i'm getting magical new errors when trying to deploy 4.7.0 in tomcat: https://gist.github.com/dannylamb/cea486a82d1467baf70d67bf40e8f9b909:43
<acoburn>dhlamb: I know I did something related to this some time ago, let me check...09:44
dhlamb: -Dfcrepo.velocity.runtime.log=file:/path/to/log09:46
<dhlamb>acoburn, where can i find a list of all those flags I can set?
* manez joins
<escowles>ruebot: the bag metadata page is https://wiki.duraspace.org/display/FF/Design+-+Bag+Metadata
<acoburn>dhlamb: https://wiki.duraspace.org/display/FEDORA4x/Application+Configuration09:47
<ruebot>escowles++ #this is great! thank you!
* manez leaves
* peichman joins
<ruebot>"Contact-Name":"Fedo Radmin"09:49
<acoburn>dhlamb: I recall something about the transaction.log location, but I'll need to dig further09:50
<dhlamb>acoburn, my suspicion is transaction.log should be inside the activemq directory we set in config
acoburn, which, by all accounts, should be fine
<ruebot>escowles: if i'm reading https://github.com/fcrepo4-labs/fcrepo-import-export/pull/63/files right, we aren't taking in the bag metadata values now, right?
<acoburn>dhlamb: I actually think transaction.log comes from the JTA transaction stuff, not AMQ
<escowles>ruebot: right i was hoping that the user-supplied metadata might land soon enough that i could just fold that in, but decided to go ahead with just the checksum algos since it didn't09:51
* westgard joins09:53
[Import/Export Standup]09:54
Finished yesterday:
None. Again, the day job...
Working on today:
Refactoring the resource class to make more maintainable and clearer code, and to accommodate external binaries.
We are closer to complete than the remaining tickets would suggest since many can be closed as soon as we have a v1.0 (they are the requirements).
* manez joins09:57
<dhlamb>acoburn, my issue may very well be because of vagran basebox gremlins10:00
<escowles>[Import/Export Standup]10:01
* yesterday: initial implementation of bag profiles
* today: importing into existing containers https://jira.duraspace.org/browse/FCREPO-2202
mapping to different path/baseURL: https://jira.duraspace.org/browse/FCREPO-2328 & https://jira.duraspace.org/browse/FCREPO-2335
* blockers: can't work on profile metadata support until we have user-supplied metadata (https://jira.duraspace.org/browse/FCREPO-2352)
<dhlamb>acoburn, and thx so much for the feedback on my PR. i'll get to that while i wait for my basebox to update.10:02
<acoburn>dhlamb: I _think_ the transaction.log gets written in the directory where the servlet (e.g. tomcat) is started from, but that is based on a vague memory
<dhlamb>acoburn, where you run the command? or where tomcat actually is?
<acoburn>dhlamb: I am looking on the server where we're running Fedora, and I don't see that file
* youn joins
<acoburn>dhlamb: I think it depends on the init.d script10:03
<dhlamb>acoburn, ah
<acoburn>dhlamb: we're using CentOS 6.x, and I think you're using Ubuntu or Debian, no?
<dhlamb>acoburn, ubuntu
<acoburn>dhlamb: of course, CentOS 7.x changes that whole thing10:04
<dhlamb>acoburn, i should be able to suss out where it goes from the service script
<acoburn>dhlamb: it is, at least, a place to start
<dhlamb>acoburn, it is. as always. many thanks.10:05
* youn leaves10:11
* youn joins10:12
* manez leaves10:14
<ruebot>escowles: so, our two main priorites for our noon call should be; 1) User supplied metadata 2) validation/verification status?10:15
<escowles>ruebot: that sounds good to me
<ruebot>westgard: that sound good to you too? any big things we need to talk out as a group with validation/verification?10:16
<escowles>ruebot: one place we need some more testing is https://jira.duraspace.org/browse/FCREPO-2350 — awead reported one error, but i think we need some more testing there to figure out what we need to do to import from bags10:17
<westgard>ruebot: I think the outstanding issues are this external/refactoring job that I'm working on, and a bug that informatician identified relating to auth credentials.10:18
<ruebot>escowles: cool. so, that test should be done on master, right? i can jump on that nowish.
<westgard>ruebot: And finally, rdf graph comparison for import.10:19
<ruebot>escowles: thanks for cleaning up the branches too, i was going to ask about that, but you went it and did it :-)
<escowles>ruebot: yep — i think you can export bags by adding "--bag default", and then import them with the same param
<ruebot>westgard: cool. did we get a ticket created for informatician's bug?
<westgard>ruebot: on import we need to filter out server managed triples and that bit is not fully working yet, though I think we have a pretty good idea how to do it.
<ruebot>escowles: cool. i'll put it through its paces10:20
<westgard>ruebot: I don't think so. I can do that quickly.
westgard: "on import we need to filter out server managed triples" -- that for import/export utility for validation/verification utility?10:21
<westgard>ruebot: for verification purposes -- that is, at least in the previous version of the exporter, when you export you get everything.10:22
So when you import that back, the server managed triples change.
So if you want to verify the import, you have to filter those out.10:23
Otherwise you'll get a false error report because those triples will be different
<ruebot>westgard: ah, i see!10:24
<westgard>ruebot: there is a ticket for this one: FCREPO-230310:25
* youn leaves10:26
* acoburn leaves10:34
<bseeger>ruebot, westgard: might be worth discussing: https://jira.duraspace.org/browse/FCREPO-2322
* whikloj joins10:35
<bseeger>ruebot, westgard, whikloj: and how, perhaps, the verification tool could use the audit log in verification.
ruebot, westgard, whikloj: if we want to even go down that road somewhere further on in time.10:36
* awead joins
<whikloj>bseeger: We need to decide if what we are interested in it a export of part of a repo, or a export that is a snapshot of the entire repo.
<awead>Tuesday, Dec. 14th10:39
[Import/Export Standup]
Finished yesterday:
Working on today:
Nothing. I’m available for reviewing.
Meetings. I’ll be in and out and will miss the noon call.
oops. I meant Wednesday.
* coblej leaves
<bseeger>whikloj: yeah, that too10:41
<westgard>bseeger ruebot whikloj: I would like to explore the use of the logs too, but I do think that's going to have to be for phase 3
<bseeger>westgard, ruebot, whikloj: in total agreement.10:45
* ruebot phase 3, nods in agreement10:47
* coblej joins10:52
<ruebot>escowles: i'm noticing some weirdness with lubm dataset exporting to bags. not sure if it is just export, or bags that is doing it. you want a me to write the output to stdout?10:55
<escowles>ruebot: sure — good to track down what's going on either way
<whikloj>escowles: Wondering about bag profiles is the idea that you can have multiple manifests with different algorithms, but each will have every file?10:56
<escowles>yes, every file should be in every manifest10:57
so you can use whichever algorithm you want
<whikloj>escowles: So when we are importing, do we care which one we use?
<escowles>whikloj: i'd just use sha1 for consistency
<whikloj>escowles: ok10:58
<escowles>(also because the exporter always creates sha1 manifests, whether the profile wants them or not)
<ruebot>i wonder of the manifest file is named wrong too11:00
$ bagit.py --validate plant
2016-12-14 10:38:36,662 - INFO - plant is invalid: Missing manifest file
i got that testing with bagit.py
<escowles>ruebot: what manifest-* files do you have?
* coblej leaves11:02
<escowles>i wonder if it's expecting manifest-sha1.txt11:04
* coblej joins
<ruebot>escowles: i bet it is!
* ruebot checks
$ mv manifest-SHA1.txt manifest-sha1.txt11:05
$ bagit.py --validate plant
2016-12-14 11:05:31,219 - INFO - plant is valid
<escowles>i don't know if we have control over that — think bagit-java handles the names of those...11:06
<ruebot>escowles: interesting11:07
escowles: that might be a bagit.py bug
* ruebot reads bagit spec
<whikloj>ruebot: manifest-SHA1.txt works on my mac
I'm less enthusiastic about bagit now11:08
<escowles>A payload manifest file MUST have a name of the form manifest-_algorithm_.txt, where _algorithm_ is a string specifying the bag checksum algorithm used in that manifest, such as:
<ruebot>whikloj: do you have a case-sensitive file system on your mac?
<escowles>i know i don't
yeah, we're creating manifests using the bagit-java constants StandardSupportedAlgorithms.SHA1, etc., so we don't even have a place we could lowercase the algorithm name11:09
<whikloj>ruebot: no apparently it is not
<ruebot>whikloj: i think that makes sense why it is validating for you11:10
* thomz leaves
<whikloj>escowles: It's their library that is creating them is it not?
<escowles>whikloj: yep
so the spec doesn't say anything about case-sensitivity of the digest algorithm part of the filename
<whikloj>escowles: So then this would be a bug on their end, or perhaps with bagit-python
[Import/Export Standup]11:11
Some reviews/merges, some working on BagIt import, too much time with BagVerifier
Finish BagIt importer and ITs, then something else
A couple calls to attend11:12
<escowles>whikloj: given the spec's ambiguity, i think bagit-python should check for upper or lower case versions
but either way, i would hope that bagit-python would validate bags produced with bagit-java...
<escowles>though i notice that all of the bags in https://github.com/loc-rdc/bagit-conformance-suite/ have lowercase algorithm names in their manifest files...11:14
* acoburn joins11:17
<escowles>afk # getting some lunch before our call at noon...11:18
<ruebot>escowles: when you get back https://gist.github.com/ruebot/511451f6b12af9493ddc605ac1e958fe11:27
* bseeger leaves11:28
<ruebot>escowles, whikloj: bugging chris https://twitter.com/ruebot/status/80907353405620633611:33
* bseeger joins11:37
* jgpawletko joins11:44
* dbernstein joins11:49
* coblej leaves11:50
* jgpawletko leaves11:52
* Informatician joins11:53
* Informatician leaves
* informatician joins11:54
<escowles>ruebot: thanks for bugging chris — it's good that it's not me all the time ;-)11:56
* justinsimpson leaves11:57
* justinsimpson joins11:59
<ruebot>dbernstein: you joining us?12:01
* dwilcox leaves
something like this: https://gist.github.com/ruebot/b7d4e8a592d304d9a9a47000355424a612:13
java -jar target/fcrepo-import-export-0.0.1-SNAPSHOT.jar --mode export --resource http://localhost:8080/rest --dir /tmp/bags/lubm --binaries --bag-profile default --bag-tags /path/to/tags.yml12:15
and maybe something like that
makes me what to have ox tail12:19
ox yum!
<escowles>i assume oxum = "octet sum" or something like that...12:20
<dhlamb>ruebot, ox tail, like chicken necks, are awesome for making soups12:21
* escowles leaves12:24
and https://jira.duraspace.org/browse/FCREPO-2356 (verifying it)
<whikloj>ruebot: Is this now what dbernstein is doing? https://jira.duraspace.org/browse/FCREPO-222812:36
<ruebot>whikloj: yeah. i think so, and i think i might have been playing fast and loose with my terminology in FCREPO-222812:39
"Name value config file that outlines everything that can be in a given bagit profile."
that should probably be:
"Name value config file that outlines everything that can be in a given bagit tag files."12:40
* awead leaves12:41
* coblej joins12:51
* coblej leaves12:55
* informatician leaves13:00
* dwilcox joins13:01
* coblej joins13:09
* kefo joins13:18
* justinsimpson leaves13:25
* github-ff joins13:33
[fcrepo-import-export] whikloj created fcrepo-2350 (+2 new commits): https://git.io/v1DCI
fcrepo-import-export/fcrepo-2350 08419f7 Jared Whiklo: Importer bagIt support and better tests of Bags
fcrepo-import-export/fcrepo-2350 6cc53f7 Jared Whiklo: Fix paths from manifest to match when importing
* github-ff leaves
* github-ff joins13:35
[fcrepo-import-export] whikloj opened pull request #64: Import Integration tests and using checksum (master...fcrepo-2350) https://git.io/v1DCu
* github-ff leaves
* westgard leaves13:43
* westgard joins13:51
<ruebot>escowles, whikloj: https://github.com/LibraryOfCongress/bagit-python/issues/83 -- after the exchange with chris on twitter14:12
<ruebot>whikloj: you think we should close this one? https://jira.duraspace.org/browse/FCREPO-2228
<whikloj>ruebot: I think its covered by fcrepo-2352, but its your ticket. Your call14:14
<ruebot>whikloj: cool. i guess we can say i resolved a ticket on the sprint call :-)14:15
<ruebot>whikloj: https://github.com/fcrepo4-labs/fcrepo-import-export/pull/64 -- we just really need code review there, right?14:18
<whikloj>ruebot: not sure, I changed to using the bag checksums if available. So a test of data is probably good. In theory as escowles pointed out the checksums in the manifest should match ones generated on-the-fly14:19
<ruebot>"Initial BigIt..."14:20
* ruebot dies giggling
whikloj: so, i should do an import of an export bag?14:21
<whikloj>ruebot: sure, that's what I did14:22
<ruebot>whikloj: cool. i'll put it through its paces
<escowles>ruebot: whikloj: i'm going to go pick up my daughter in a minute — i'll review that when i get back14:23
* mikeAtUVa joins14:31
* mikeAtUVa leaves14:42
<ruebot>whikloj: 2350 is looking good from an import testing perspective on hydra, 10k, and plant patents datasets14:46
<whikloj>ruebot: cool
* dwilcox leaves14:54
* bseeger leaves14:55
<escowles>whikloj: PR 64 looks good to me — do you want to squash your commits, or should i have github do it?14:59
<whikloj>escowles: github is fine
escowles: thanks
* github-ff joins
[fcrepo-import-export] escowles pushed 1 new commit to master: https://git.io/v1DwI
fcrepo-import-export/master b9b0dda Jared Whiklo: Import Integration tests and using checksum (#64)...
* github-ff leaves
<ruebot>whikloj, escowles: https://github.com/LibraryOfCongress/bagit-python/issues/83#issuecomment-267139564 -- i'm happy to update our pom.xml if y'all'd like15:00
<escowles>ruebot: that would be good — i didn't see anything newer than 5.0.0-BETA in maven (http://mvnrepository.com/artifact/gov.loc/bagit), so i don't know if it'll work...15:02
* westgard leaves15:05
<ruebot>escowles: ah! so, update pom.xml so it uses git instead of maven central?15:07
<escowles>ruebot: i've never done that — but that sounds good to me
<ruebot>escowles: i _think_ it is possible, and acoburn probably showed me how to do it once15:08
<acoburn>ruebot: I'm not sure you can just point maven at github and fetch an artifact15:11
ruebot: but from some basic googling, it appears that there are external services that will do that and make it look like a maven repository
ruebot: https://jitpack.io/15:12
<acoburn>ruebot: I've never used this, but I think that's what you're trying to do
<ruebot>acoburn: taunting us with gradle :-)15:17
<acoburn>ruebot: maven works, too. It's just that gradle is the "default" build tool that is shown
<ruebot>acoburn: heh. just noticed that.15:18
<acoburn>ruebot: https://jira.duraspace.org/browse/FCREPO-2336
and https://jira.duraspace.org/browse/FCREPO-233815:19
* coblej leaves15:23
acoburn: oh, interesting. bagit-java uses gradle to build, so jitpack might not work.15:32
<acoburn>ruebot: jitpack requires maven?15:33
<ruebot>[ERROR] Failed to execute goal on project fcrepo-import-export: Could not resolve dependencies for project org.fcrepo.importexport:fcrepo-import-export:jar:0.0.1-SNAPSHOT: Failure to find com.github.LibraryOfCongress:bagit-java:jar:v5.0.0-RC10 in https://jitpack.io was cached in the local repository, resolution will not be reattempted until the update interval of jitpack.io has elapsed or updates are forced15:34
<dbernstein>ruebot and team: when an aptrust bag is generated would we expect there to be both a bag-info.txt and an aptrust-info.txt as well? or will all properties wind up in a bag-info.txt file?
<ruebot>dbernstein: yeah, there should be two tag files15:35
<dbernstein>okay cool.
<ruebot>dbernstein: iirc, talked about this on the call. escowles might have said that the aptrust profile will create the aptrust-info.txt tag file. but, i could be mistaken :-)15:36
<acoburn>ruebot: it looks like it fails on the :signArchives task, which makes sense, since jitpack probably isn't set up to sign artifacts
<ruebot>acoburn: ah, interesting
<escowles>ruebot: dbernstein: yes, the aptrust profile will require bag-info.txt and aptrust-info.txt
* westgard joins15:38
<acoburn>ruebot: they've commented out the line that would have made this work: https://git.io/v1DPv
<ruebot>acoburn: :-( -- i'll harass them more15:40
<acoburn>ruebot: if they publish SNAPSHOT artifacts somewhere, it would be really convenient15:41
* coblej joins15:43
<ruebot>acoburn, escowles, whikloj; i think we are at the mercy of LoC on that. i don't see a way to tell maven to just grab this https://github.com/LibraryOfCongress/bagit-java/releases/download/v5.0.0-RC10/bagit-5.0.0-RC10-SNAPSHOT.jar in the pom.xml16:11
<acoburn>ruebot: I think that is correct, barring some seriously complex maven acrobatics16:12
<escowles>ruebot: that's kind of lame — i hope the LoC folks will push out a new beta release for us
<acoburn>ruebot: stop the press! https://oss.sonatype.org/content/repositories/snapshots/gov/loc/bagit/5.0.0-RC10-SNAPSHOT/16:13
<acoburn>ruebot: LoC is publishing artifacts on sonatype, including 5.0.0-RC10
<acoburn>ruebot: so, as long as you include the sonatype repository in the maven "repositories" section, and point specifically to 5.0.0-RC10-SNAPSHOT, you should be OK
ruebot: like this: https://github.com/fcrepo4/fcrepo-module-auth-rbacl/blob/master/pom.xml#L19-L3016:16
* bseeger joins16:25
* github-ff joins16:27
[fcrepo-import-export] dbernstein opened pull request #65: Adds support for user-supplied metadata (master...fcrepo-2352) https://git.io/v1D9x
* github-ff leaves
<ruebot>escowles, whikloj: so, we have a problem with 5.0.0-RC10 -- it appears to require oracle java16:39
<escowles>ruebot: why?
<ruebot>escowles, whikloj: when i set it up to use 5.0.0-RC10, i got:16:43
[ERROR] Failed to execute goal org.apache.maven.plugins:maven-compiler-plugin:3.2:compile (default-compile) on project fcrepo-import-export: Fatal error compiling: class file for javafx.util.Pair not found -> [Help 1]
which i found: https://gist.github.com/androidfred/bc64da9e6a355b984d37439ed63ae16b
<whikloj>ruebot: oh16:44
<ruebot>escowles, whikloj: ...and i try to compile with oracle java, well, it fails with a bunch of different errors. so...16:46
<escowles>ruebot: i'd file a bug — javafx is a GUI library, and there is no reason for them to be using it
<escowles>ruebot: yeah, there are a bunch of api changes since they published that beta to mavencentral, so we'll have to change a bunch of stuff from File to Path and so on16:47
<whikloj>ruebot: Perhaps suggest -> https://github.com/pinterest/teletraan/pull/84/files
<escowles>whikloj: ruebot: better yet: http://docs.oracle.com/javase/1.5.0/docs/api/java/util/Map.Entry.html16:48
<whikloj>escowles: haha yes I never thought of that
<escowles>Key-Value pairs have been in the core java api forever — i have no idea why someone would use a brand new GUI library KV pair in this context16:49
<acoburn>also, commons.lang3 has a Pair class with those semantics
but escowles' suggestion is better16:50
<ruebot>escowles, whikloj: so, do we want to stick with 5.0.0-BETA? and maybe we do a lowercase fix on our end? or write a few tickets for bagit-java to fix upstream16:51
<whikloj>ruebot: make the tickets either way16:52
<ruebot>whikloj: yeah, you're right. that shouldn't have been an OR :-)
<escowles>ruebot: i guess that depends — i think i'm going to be busy with the profile metadata enforcement, but maybe whikloj or dbernstein can do the upgrade...16:53
(or vice versa, i suppose if one of you wants to do the enforcement)
<whikloj>escowles: this is making the manifest filename have manifest-sha1.txt instead of manifest-SHA1.txt?
<escowles>whikloj++ # file the tickets anyway
whikloj: yes — and making it easier for us to upgrade once other changes come out — like bagit 1.0 in a few months16:54
so i think it's worth doing, just a question if it's worth doing this week or punting until the next sprint
<whikloj>ruebot: If you want to make up a ticket with the stuff, I can take it or leave it as escowles says for next sprint. Maybe there will be a release by then16:55
<dbernstein>Re profile metadata enforcement: are you talking about https://jira.duraspace.org/browse/FCREPO-2356
<escowles>dbernstein: yes, that's the ticket i think we should get done by friday if at all possible16:56
dbernstein: i'm happy to work it or happy to let you have it if you want it
<dbernstein>If you have other things I would prefer to work that one since I was just there.16:57
<ruebot>escowles, whikloj: i'd say create the bagit-java library tickets, and punt on 5.0.0-BETA to 5.whatever upgrade since we need something for stakeholders to test
<escowles>dbernstein: ok, sounds good to me
<dbernstein>I’m planning to have that done by tomorrow morning.16:58
<escowles>dbernstein: awesome — it'd be great to have some time to test and make sure the docs are updated
dbernstein: i don't know if you found a way to add other tag files (like aptrust-info.txt) using bagit-java — i looked for a way to do it and couldn't see one16:59
it would really suck to use that library and have to write our own tag file impl anyway
<dbernstein>I haven’t looked into that bit yet. If you have a moment - take a look at my pull request: https://github.com/fcrepo4-labs/fcrepo-import-export/pull/65 - there were a couple of places where it wasn’t clear where to pass the aptrust info to the Bag.17:00
So I just put in a couple of todos.
But before I start on the enforcement I just want to make sure that fcrepo-2352 is more or less the right approach.17:02
<escowles>dbernstein: yes, i was just looking at it and it looks good — i've just got a couple of comments on the tests, but you can fold those into the enforcement
* coblej leaves17:03
<dbernstein>escowles: will do, brother esme.17:04
<escowles>alright, it's quitting time for me — talk to y'all tomorrow17:07
* bseeger leaves17:14
* acoburn leaves17:15
* willtp87 leaves17:28
<ruebot>whikloj, escowles: https://github.com/LibraryOfCongress/bagit-java/issues/72 -- that's a really weird issue template17:37
<whikloj>ruebot: yeah I had the same problem -- https://github.com/LibraryOfCongress/bagit-java/issues/6917:48
* peichman leaves17:50
* whikloj leaves18:00
* westgard leaves18:05
* kefo leaves18:15
<dbernstein>@escowles: so am I going to work https://jira.duraspace.org/browse/FCREPO-2356 - but fyi it is still in the received state. Can someone open it?18:27
* dhlamb leaves18:33
* dbernstein leaves18:55
* westgard joins20:02
* westgard leaves20:07
* github-ff joins20:50
[fcrepo-camel-toolbox] birkland pushed 2 new commits to master: https://git.io/v1yZc
fcrepo-camel-toolbox/master 64850ab Aaron Coburn: Separate blueprint from java code...
fcrepo-camel-toolbox/master 8edaaec birkland: Merge pull request #124 from acoburn/fcrepo-2339...
* github-ff leaves
* travis-ci joins21:02
fcrepo4-exts/fcrepo-camel-toolbox#321 (master - 8edaaec : birkland): The build passed.21:03
Change view : https://github.com/fcrepo4-exts/fcrepo-camel-toolbox/compare/06561b0c1bf1...8edaaec380dd
Build details : https://travis-ci.org/fcrepo4-exts/fcrepo-camel-toolbox/builds/184120317
* travis-ci leaves
* westgard joins
* manez joins21:14
* westgard leaves22:51
* westgard joins22:58
* manez leaves23:29
* manez joins23:30

Generated by Sualtam