15:00:45 #startmeeting 15:00:45 Meeting started Thu Feb 13 15:00:45 2014 UTC. The chair is tstclair. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:00:45 Useful Commands: #action #agreed #halp #info #idea #link #topic. 15:01:00 #meetingname big_data_sig 15:01:00 The meeting name has been set to 'big_data_sig' 15:01:28 #meetingtopic status 15:01:42 #topic current_issues 15:02:14 Morning folks! 15:02:21 afternoon :) 15:02:41 issue: colt 15:02:44 howdy all 15:03:01 rsquared, What seems to be the problem? 15:04:19 colt bundles aida, which I'm been working on packaging separately. However, the license information for aida on the colt page and the aida page are different. Colt states there's a military restriction on the aida bits it bundles, but aida upstream mentions no such restriction. 15:04:51 Is the bundle a fork? 15:05:09 And the colt license file has license information for colt and aida bits. I'm unsure if the license file can be modified to remove the licensing info for aida if a separate aida can be packaged 15:05:33 Unclear. They only include the bits of aida colt needs. They don't provide info about where it comes from, version, or if they've changed it at all. 15:06:13 is it possible to have colt depend on upstream aida versus "re-bundling" 15:07:05 Then in generate-tarball or %pre you can remove the rebundled elements. 15:07:31 I'm attempting to bundle aida, but it involves reworking their build system to avoid pulling in freehep, which looks to be worthless for this effort as colt only uses ant extensions from freehep to get around very old ant versions. 15:07:33 rsquared, this is a pretty standard technique, see the scala spec for an involved example 15:07:56 willb: What's a standard technique? Bundling bits of other sw? 15:08:16 ripping out the rebundled bits, to depend on upstream 15:08:19 rsquared, no, patching project X to depend on a system copy of project Y (instead of a bundled version) 15:08:56 Right, working on that now. However, it's unclear if the upstream aida will work with colt. Also unclear if I can modify the colt license file 15:09:02 rsquared, alas, bundling is also a "standard" technique ;-) 15:09:07 rsquared, you cannot modify the license file 15:09:16 that is one of the things you can't patch 15:09:29 if bundled libs are non-free (like aida) then it's necessary to remove them from source tarball, not in %prep 15:09:40 we can't ship non-free stuff even as part of srpm 15:10:04 generate-tarball.sh 15:10:06 So if I rip out aida, what happens to the bits of the license file that cover the ripped out aida? That's where the restriction is. 15:10:12 colt tarball -> 2 licenses 15:10:48 bundled src, not libs 15:10:49 mizdebsk, I thought aida was lgpl? 15:10:52 wrong aida? 15:10:58 * willb prefers Falstaff in any case 15:11:04 http://acs.lbl.gov/software/colt/license.html 15:11:12 http://aida.freehep.org/license.thtml 15:11:28 colt license for aida is lgpl with military restriction, upstream aida is just lgpl 15:11:31 willb: it says "military applications is expressly forbidden" 15:11:50 However, the source for colt has a license file that includes license for colt AND aida (with military restriction) 15:11:58 hm, sounds pretty incoherent 15:12:15 they refer to FreeHEP for the licensing terms of these bits 15:12:55 "LGPL with usage restrictions" --> "not even close to the LGPL" 15:13:53 the safest would be asking fedora-legal, but unbundling aida (and a re-archiving) should be ok 15:14:13 +1 15:14:23 number80: What about the license file in colt? 1 file includes the colt license and the restricted aida license 15:14:35 If we can't modify the license file, what is there to be done? 15:15:13 rsquared: the license only covers the bits shipped with the tarball 15:15:34 rsquared, I agree with number80 that consulting legal makes sense 15:15:35 if fedora-legal is ok, you should just file a ticket upstream to update the license file 15:16:03 rsquared, probably also ask on -devel if you haven't already and see if people have dealt with a similar situation for practical guidance 15:16:18 number80: So if I ship package A, and a license file that covers A and B, the wording for B is irrelevant? 15:16:54 If B is unbundled (not in the srpm), then my understanding is yes. 15:16:54 rsquared: depends, if it covers only the bundled bits or whatever version you use 15:17:36 Are there any other open-issues? 15:17:49 yes 15:18:00 fire away willb 15:18:18 good news and bad news; I'll start with the former 15:18:52 I've written up some preliminary guidelines for packaging things with sbt on F20 (i.e. pre-xmvn 2.0): https://fedoraproject.org/wiki/SIGs/bigdata/packaging/Sbt 15:19:15 also, sbt should be in Fedora by the end of the week if enough people are at the FPC meeting to approve my bootstrap bundling exception 15:19:54 on a less-happy note, curious if anyone has gradle experience and would be willing to talk off-line about it with me 15:21:06 gradle used to be in fedora but was removed 15:21:11 i can give you detailed info 15:21:32 mizdebsk, yeah, I've followed the history there; will ping you elsewhere on IRC to give you details. thanks! 15:21:59 #topic current_status 15:22:44 i think the gluster-hadoop package is quite out of date. i may update it or have someone who maintains the project have a look. 15:23:56 So I've been chasing a permissions issue in tachyon through to hadoop's yarn user. It's led me to think we could use some testing/plugfest/hackathon love around the SIG. 15:24:11 mattf, I can look next week. 15:24:58 status: pig (jar) in rawhide, waiting for it to get to updates for an initial hive pkg for review; working on bin files for both 15:25:13 tstclair, no need 15:27:12 what about the qa love. anyone know of a good group to engage? 15:27:56 status: did some process documentation (as above), some reviewing (pig; others in flight), and have been looking at gil's Akka build 15:29:20 mizdebsk, number80 re: mattf's comment ^, have either of you worked with https://fedoraproject.org/wiki/QA? 15:31:19 k, I guess I'll follow up and report back. 15:31:37 #topic news 15:32:08 Are there any new developments, packages to watch, etc? 15:32:20 https://fedoraproject.org/wiki/SIGs/bigdata/packaging - accurate? 15:33:13 I've made some updates to the Spark and Scala pages since we last met 15:35:42 pmackinn, mattf - Are there links to hadoop.images somewhere that we should cross ref? 15:36:31 scollier is working on some docker images, o ref yet 15:36:46 tstclair, i can add my docker dev images if you like 15:37:47 tstclair: engaging QA people ain't easy, they're understaffed and it requires some time to test specialized stuff 15:38:09 pmackinn, if it's useful to the broader SIG during development, then that would be awesome. 15:38:21 tstclair, ack 15:38:21 number80, thanks for the info! 15:38:24 tstclair: but i'd see with adamw, if it's possible to set up a big data testing day in the release cycle 15:38:46 number80, that would be my hope ;-) 15:39:00 i'd be happy to come testing :) 15:40:40 mizdebsk, rsquared, pmackinn, willb, mattf, number80 - Is there anything else? 15:41:02 about QA 15:41:26 i think there should be manual test cases on the wiki 15:41:39 like install this, connect there etc. 15:41:58 this way people that don't know all the details can help with testing 15:42:03 my 2c 15:42:08 +1. 15:42:25 +1 15:43:16 (sorry for the lag, it's office hours here) 15:43:29 np. 15:43:48 example: https://fedoraproject.org/wiki/QA:Testcase_thermostat_logging 15:44:28 ack. 15:45:36 good 15:45:37 mizdebsk, rsquared, pmackinn, willb, mattf, number80 - last call for topics, or adjourn. 15:45:42 Nothing from me 15:45:47 the same 15:45:50 nothing here 15:45:52 nothing here 15:47:57 Thanks everyone! 15:48:04 #endmeeting