big_data_sig
LOGS
15:00:45 <tstclair> #startmeeting
15:00:45 <zodbot> 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 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
15:01:00 <tstclair> #meetingname big_data_sig
15:01:00 <zodbot> The meeting name has been set to 'big_data_sig'
15:01:28 <tstclair> #meetingtopic status
15:01:42 <tstclair> #topic current_issues
15:02:14 <tstclair> Morning folks!
15:02:21 <number80> afternoon :)
15:02:41 <rsquared> issue: colt
15:02:44 <willb> howdy all
15:03:01 <tstclair> rsquared, What seems to be the problem?
15:04:19 <rsquared> 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 <tstclair> Is the bundle a fork?
15:05:09 <rsquared> 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 <rsquared> 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 <tstclair> is it possible to have colt depend on upstream aida versus "re-bundling"
15:07:05 <tstclair> Then in generate-tarball or %pre you can remove the rebundled elements.
15:07:31 <rsquared> 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 <willb> rsquared, this is a pretty standard technique, see the scala spec for an involved example
15:07:56 <rsquared> willb: What's a standard technique?  Bundling bits of other sw?
15:08:16 <tstclair> ripping out the rebundled bits, to depend on upstream
15:08:19 <willb> rsquared, no, patching project X to depend on a system copy of project Y (instead of a bundled version)
15:08:56 <rsquared> 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 <willb> rsquared, alas, bundling is also a "standard" technique  ;-)
15:09:07 <willb> rsquared, you cannot modify the license file
15:09:16 <willb> that is one of the things you can't patch
15:09:29 <mizdebsk> if bundled libs are non-free (like aida) then it's necessary to remove them from source tarball, not in %prep
15:09:40 <mizdebsk> we can't ship non-free stuff even as part of srpm
15:10:04 <tstclair> generate-tarball.sh
15:10:06 <rsquared> 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 <pmackinn> colt tarball -> 2 licenses
15:10:48 <pmackinn> bundled src, not libs
15:10:49 <willb> mizdebsk, I thought aida was lgpl?
15:10:52 <willb> wrong aida?
15:10:58 * willb prefers Falstaff in any case
15:11:04 <rsquared> http://acs.lbl.gov/software/colt/license.html
15:11:12 <rsquared> http://aida.freehep.org/license.thtml
15:11:28 <rsquared> colt license for aida is lgpl with military restriction, upstream aida is just lgpl
15:11:31 <mizdebsk> willb: it says "military applications is expressly forbidden"
15:11:50 <rsquared> However, the source for colt has a license file that includes license for colt AND aida (with military restriction)
15:11:58 <willb> hm, sounds pretty incoherent
15:12:15 <number80> they refer to FreeHEP for the licensing terms of these bits
15:12:55 <willb> "LGPL with usage restrictions" --> "not even close to the LGPL"
15:13:53 <number80> the safest would be asking fedora-legal, but unbundling aida (and a re-archiving) should be ok
15:14:13 <tstclair> +1
15:14:23 <rsquared> number80: What about the license file in colt?  1 file includes the colt license and the restricted aida license
15:14:35 <rsquared> If we can't modify the license file, what is there to be done?
15:15:13 <number80> rsquared: the license only covers the bits shipped with the tarball
15:15:34 <willb> rsquared, I agree with number80 that consulting legal makes sense
15:15:35 <number80> if fedora-legal is ok, you should just file a ticket upstream to update the license file
15:16:03 <willb> 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 <rsquared> 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 <tstclair> If B is unbundled (not in the srpm), then my understanding is yes.
15:16:54 <number80> rsquared: depends, if it covers only the bundled bits or whatever version you use
15:17:36 <tstclair> Are there any other open-issues?
15:17:49 <willb> yes
15:18:00 <tstclair> fire away willb
15:18:18 <willb> good news and bad news; I'll start with the former
15:18:52 <willb> 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 <willb> 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 <willb> 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 <mizdebsk> gradle used to be in fedora but was removed
15:21:11 <mizdebsk> i can give you detailed info
15:21:32 <willb> mizdebsk, yeah, I've followed the history there; will ping you elsewhere on IRC to give you details.  thanks!
15:21:59 <tstclair> #topic current_status
15:22:44 <mattf> 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 <tstclair> 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 <tstclair> mattf, I can look next week.
15:24:58 <pmackinn> 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 <mattf> tstclair, no need
15:27:12 <mattf> what about the qa love. anyone know of a good group to engage?
15:27:56 <willb> 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 <tstclair> mizdebsk, number80 re: mattf's comment ^, have either of you worked with https://fedoraproject.org/wiki/QA?
15:31:19 <tstclair> k, I guess I'll follow up and report back.
15:31:37 <tstclair> #topic news
15:32:08 <tstclair> Are there any new developments, packages to watch, etc?
15:32:20 <tstclair> https://fedoraproject.org/wiki/SIGs/bigdata/packaging - accurate?
15:33:13 <willb> I've made some updates to the Spark and Scala pages since we last met
15:35:42 <tstclair> pmackinn, mattf - Are there links to hadoop.images somewhere that we should cross ref?
15:36:31 <mattf> scollier is working on some docker images, o ref yet
15:36:46 <pmackinn> tstclair, i can add my docker dev images if you like
15:37:47 <number80> tstclair: engaging QA people ain't easy, they're understaffed and it requires some time to test specialized stuff
15:38:09 <tstclair> pmackinn, if it's useful to the broader SIG during development, then that would be awesome.
15:38:21 <pmackinn> tstclair, ack
15:38:21 <tstclair> number80, thanks for the info!
15:38:24 <number80> 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 <tstclair> number80, that would be my hope ;-)
15:39:00 <number80> i'd be happy to come testing :)
15:40:40 <tstclair> mizdebsk, rsquared, pmackinn, willb, mattf, number80 - Is there anything else?
15:41:02 <mizdebsk> about QA
15:41:26 <mizdebsk> i think there should be manual test cases on the wiki
15:41:39 <mizdebsk> like install this, connect there etc.
15:41:58 <mizdebsk> this way people that don't know all the details can help with testing
15:42:03 <mizdebsk> my 2c
15:42:08 <tstclair> +1.
15:42:25 <number80> +1
15:43:16 <number80> (sorry for the lag, it's office hours here)
15:43:29 <tstclair> np.
15:43:48 <mizdebsk> example: https://fedoraproject.org/wiki/QA:Testcase_thermostat_logging
15:44:28 <tstclair> ack.
15:45:36 <number80> good
15:45:37 <tstclair> mizdebsk, rsquared, pmackinn, willb, mattf, number80 - last call for topics, or adjourn.
15:45:42 <rsquared> Nothing from me
15:45:47 <number80> the same
15:45:50 <mizdebsk> nothing here
15:45:52 <willb> nothing here
15:47:57 <tstclair> Thanks everyone!
15:48:04 <tstclair> #endmeeting