15:00:00 <tradej> #startmeeting Java SIG -- https://fedoraproject.org/wiki/SIGs/Java
15:00:00 <zodbot> Meeting started Tue Oct  2 15:00:00 2012 UTC.  The chair is tradej. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:00:00 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
15:00:27 <tradej> #meetingname Java SIG
15:00:27 <zodbot> The meeting name has been set to 'java_sig'
15:00:38 <tradej> #chair sochotni
15:00:38 <zodbot> Current chairs: sochotni tradej
15:00:49 <tradej> #topic roll-call
15:00:56 <sochotni> .fasinfo sochotni
15:00:57 <zodbot> sochotni: User: sochotni, Name: Stanislav Ochotnicky, email: sochotni@redhat.com, Creation: 2010-04-06, IRC Nick: , Timezone: Europe/Prague, Locale: en, GPG key ID:  71A1677C, Status: active
15:01:00 <zodbot> sochotni: Approved Groups: +gitfedorareview fedorabugs cla_redhat cla_fedora cla_done +packager provenpackager @git-javapackages
15:01:11 <tradej> .fasinfo tradej
15:01:12 <zodbot> tradej: User: tradej, Name: Tomas Radej, email: tradej@redhat.com, Creation: 2011-08-03, IRC Nick: tradej, Timezone: UTC, Locale: en, GPG key ID: , Status: active
15:01:15 <zodbot> tradej: Approved Groups: cla_fpca cla_done packager fedorabugs
15:01:46 <sochotni> let's see how many people are actually here for the Java meeting :-)
15:02:20 <mspaulding> hi, I'm here :)
15:02:22 * vanaltj is.  maybe more to observe :)
15:02:29 <mspaulding> .fasinfo madsa
15:02:30 <zodbot> mspaulding: User: madsa, Name: Matt Spaulding, email: mspaulding06@gmail.com, Creation: 2012-03-09, IRC Nick: mspaulding, Timezone: US/Pacific, Locale: en, GPG key ID: 0x1EE0A3B7, Status: active
15:02:32 * mojavelinux is lurking :) hi all!
15:02:34 <zodbot> mspaulding: Approved Groups: packager fedorabugs cla_fpca cla_done
15:02:58 * pingou around
15:03:08 <sochotni> I guess we'll wait ~5 minutes for everyone to get in here
15:03:19 * graphite6 here
15:03:40 <sochotni> and then we can go step by step 1 change at a time
15:04:00 <nkinder> .fasinfo nkinder
15:04:01 * akurtakov is here
15:04:01 <zodbot> nkinder: User: nkinder, Name: Nathan Kinder, email: nkinder@redhat.com, Creation: 2005-04-20, IRC Nick: , Timezone: US/Pacific, Locale: en, GPG key ID: 4D69E5AA, Status: active
15:04:03 <zodbot> nkinder: Approved Groups: fedorabugs @svnpki @gitosutil @gitpki @svntomcatjss svnesc cla_done @cvsdirsec packager cla_fedora @git389 cla_fpca
15:04:18 <mbooth> hello
15:04:20 <sochotni> since I believe the most important (one and only?) we have on agenda is ... new guidelines
15:04:25 <akurtakov> .fasinfo akurtakov
15:04:26 <zodbot> akurtakov: User: akurtakov, Name: Alexander Kurtakov, email: akurtako@redhat.com, Creation: 2008-10-01, IRC Nick: akurtakov, Timezone: Europe/Sofia, Locale: en, GPG key ID: , Status: active
15:04:28 <sochotni> mbooth: hey, nice to see you around
15:04:29 <zodbot> akurtakov: Approved Groups: @giteclipse-packagekit cla_fedora cla_done cla_redhat fedorabugs +packager provenpackager @git-javapackages @giteclipse-fedorapackager
15:04:51 <sochotni> since when does fasinfo include groups?
15:05:00 <sochotni> I remember the output being just the first line
15:05:03 <wolfc> .fasinfo wolfc1
15:05:04 <zodbot> wolfc: User: wolfc1, Name: Carlo de Wolf, email: cdewolf@redhat.com, Creation: 2011-12-20, IRC Nick: , Timezone: Europe/Amsterdam, Locale: en, GPG key ID: , Status: active
15:05:06 <mharmsen> .fasinfo mharmsen
15:05:07 <zodbot> wolfc: Approved Groups: cla_fpca cla_done
15:05:10 <zodbot> mharmsen: User: mharmsen, Name: None, email: mharmsen@redhat.com, Creation: 2005-04-27, IRC Nick: None, Timezone: None, Locale: None, GPG key ID: None, Status: active
15:05:11 <mefoster> .fasinfo mef
15:05:13 <zodbot> mharmsen: Approved Groups: svnesc svncoolkey gitcertmonger @gitpki cla_done cvsdirsec cla_fedora svnnuxwdog @svnpki gitmod_nss gitmod_revocator packager fedorabugs @git389 @svntomcatjss @gitosutil cla_fpca
15:05:16 <zodbot> mefoster: User: mef, Name: None, email: mefoster@gmail.com, Creation: 2007-08-29, IRC Nick: None, Timezone: None, Locale: None, GPG key ID: None, Status: active
15:05:19 <zodbot> mefoster: Approved Groups: fedorabugs cla_fedora cla_done packager provenpackager cla_fpca
15:05:39 <alee> .fasinfo alee
15:05:41 <zodbot> alee: User "alee" doesn't exist
15:05:46 <graphite6> .fasinfo graphitefriction
15:05:47 <zodbot> graphite6: User: graphitefriction, Name: Sarah White, email: graphitefriction@gmail.com, Creation: 2012-01-13, IRC Nick: , Timezone: US/Eastern, Locale: en, GPG key ID: , Status: active
15:05:50 <zodbot> graphite6: Approved Groups: cla_fpca cla_done ambassadors
15:05:53 <sochotni> alee: no fedora account? :-)
15:06:05 <alee> .fasinfo vakwetu
15:06:06 <zodbot> alee: User: vakwetu, Name: Ade Lee, email: alee@redhat.com, Creation: 2008-09-26, IRC Nick: , Timezone: UTC, Locale: en, GPG key ID: , Status: active
15:06:08 <mojavelinux> .fasinfo mojavelinux
15:06:09 <zodbot> alee: Approved Groups: gitpki cla_fedora cla_done svntomcatjss cla_redhat svnpki @svnnuxwdog gitosutil packager fedorabugs
15:06:11 <zodbot> mojavelinux: User: mojavelinux, Name: Dan Allen, email: dan.j.allen@gmail.com, Creation: 2012-01-13, IRC Nick: mojavelinux, Timezone: US/Eastern, Locale: en, GPG key ID: F30CC1C1, Status: active
15:06:14 <zodbot> mojavelinux: Approved Groups: cla_fpca cla_done
15:06:15 <sochotni> heh, would not guess that one :-)
15:06:28 <rgrunber> .fasinfo rgrunber
15:06:29 <zodbot> rgrunber: User: rgrunber, Name: Roland Grunberg, email: rgrunber@redhat.com, Creation: 2009-07-23, IRC Nick: rgrunber, Timezone: America/Toronto, Locale: en, GPG key ID: , Status: active
15:06:32 <zodbot> rgrunber: Approved Groups: cla_fedora cla_done cla_redhat packager fedorabugs @giteclipse-fedorapackager
15:06:43 <mbooth> .fasinfo mbooth
15:06:44 <zodbot> mbooth: User: mbooth, Name: None, email: fedora@matbooth.co.uk, Creation: 2008-04-03, IRC Nick: None, Timezone: None, Locale: None, GPG key ID: None, Status: active
15:06:46 <vanaltj> .fasinfo jvanalte
15:06:47 <zodbot> mbooth: Approved Groups: cla_fedora cla_done +packager fedorabugs provenpackager cla_fpca
15:06:50 <zodbot> vanaltj: User: jvanalte, Name: Jon VanAlten, email: jon.vanalten@redhat.com, Creation: 2011-05-19, IRC Nick: vanaltj, Timezone: UTC, Locale: en, GPG key ID: , Status: active
15:06:53 <zodbot> vanaltj: Approved Groups: packager fedorabugs cla_fpca cla_done
15:07:07 <sochotni> wow...I can't remember such a number of people...Seems this meeting is long overdue :-)
15:07:19 <davidcl> .fasinfo davidcl
15:07:21 <zodbot> davidcl: User: davidcl, Name: Clément David, email: c.david86@gmail.com, Creation: 2011-06-07, IRC Nick: davidcl, Timezone: Europe/Paris, Locale: en, GPG key ID: Clement David <c.david86@gmail.com>, Status: active
15:07:24 <zodbot> davidcl: Approved Groups: cla_fpca cla_done packager fedorabugs
15:07:39 <tradej> #info tradej sochotni mspaulding vanaltj mojavelinux pingou graphite6 nkinder akurtakov mbooth wolfc mharmsen mefoster alee rgrunber davidcl present
15:07:51 <sochotni> I'd go ahead...I believe most people are already here, rest will
15:07:56 <tradej> okay, let's roll
15:08:13 <tradej> #topic New Guidelines
15:08:20 <sochotni> #link https://fedoraproject.org/wiki/User:Akurtakov/JavaPackagingDraftUpdate
15:09:01 <akurtakov> tradej: sochotni: do you have a diff so we can look at changes ?
15:09:06 <tradej> akurtakov: coming
15:09:09 <sochotni> akurtakov: on it already
15:09:35 <sochotni> http://goo.gl/enTnE
15:09:46 <sochotni> #link http://goo.gl/enTnE
15:10:00 <sochotni> ^^ that's the diff against current guidelines
15:10:52 <wolfc> personally I would rather see the locally installed maven artifacts in a 'Maven' repo layout.
15:11:32 <sochotni> wolfc: me as well, but there are small issues we haven't solved wrt that approach
15:11:34 <akurtakov> wolfc: guidelines change only after underlying tools are there
15:11:49 <akurtakov> we can't change guidelines if we don't have the tooling to make it real yet
15:12:04 * fnasser was in the wrong meeting channel :-(
15:12:23 <sochotni> fnasser: sorry, tried to be more explicit...you didn't miss much, just started
15:12:45 <jerboaa> .fasinfo jerboaa
15:12:46 <zodbot> jerboaa: User: jerboaa, Name: None, email: jerboaa@gmail.com, Creation: 2010-06-17, IRC Nick: None, Timezone: None, Locale: None, GPG key ID: None, Status: active
15:12:49 <zodbot> jerboaa: Approved Groups: cla_fedora cla_done cla_redhat packager fedorabugs @giteclipse-fedorapackager
15:13:47 <tradej> fnasser: sorry, my bad. i checked that at 3:00, there are no meetings at #fedora-meeting. unfortunately, that was 3:00 AM :)
15:14:11 <sochotni> there are multiple small changes which I believe are not going to cause any issues: rewording, addition of pom_ macros, removal of maven2 mentions which are obsolete
15:14:22 <fnasser> tradej it is OK, I went back to the last msg and saw the note at the bottom
15:14:27 <sochotni> change from mvn-rpmbnuild install to package is also OK
15:14:37 <sochotni> or I'd say non-controversial
15:14:52 <sochotni> though I believe we should add %check mvn-rpmbuild verify as SHOULD
15:15:02 <sochotni> so we'll do the integration tests if there are any
15:15:11 <fnasser> I am not sure it is relevant, but if you dig the list archives you'll find my old proposal to change the layout of the RPM installation to resemble a Maven repo.  It was approved in principle at the time
15:15:54 <wolfc> fnasser: please read the backlog I send you ;-)
15:15:54 <fnasser> A guy from JPackage did a ProffOfConcept with it and it worked fine, except for some inconvenience of settings.xml that we could think together on a way to simplify that
15:16:07 <fnasser> wolfc Yes, I read, that is why I am mentioning it
15:16:10 <sochotni> fnasser: ok, theoretically we could add a symlinking step for %add_maven_depmap
15:16:33 <fnasser> sochotni, The POC was backwards compatible, so we could go converting over time
15:16:48 <sochotni> that symlinking could create _javadir/maven-repo/gid/aid/version/aid-version.jar symlink
15:16:53 <fnasser> But once we are in the new layout, pointing httpd to that dir would give us a maven repo
15:17:48 <sochotni> in principle I am for this change, but we can't do anything about it *now*
15:18:01 <akurtakov> can we go through current (tool backed) guideline changes first, vote them and discuss maven repo installation after that
15:18:13 <fnasser> sochotni, I am not discussing timing, I agree it has to be planned
15:18:13 <sochotni> what we can do: is everyone OK if I add that symlinking to add_maven_depmap?
15:18:29 <akurtakov> fine by me
15:18:40 <tradej> second that
15:18:49 <sochotni> that would be + from me
15:18:53 <fnasser> I'd like to play with it, so +1
15:19:26 <akurtakov> though make it _datadir/maven-repo
15:19:35 <sochotni> #action sochotni will update add_maven_depmap to symlink a true-ish maven repo
15:19:40 <akurtakov> to not make jpackage-utils traverse things twice
15:19:51 <akurtakov> build-classpath and etc. I mean
15:19:59 <sochotni> akurtakov: yup, sure thing
15:20:07 <sochotni> ok...so...let's move to other issues
15:20:29 <fnasser> Yes, my proposal included making a smarter build-classpath and friends.  I have somewhere the proposed additional flags for it
15:20:50 <fnasser> They's allow you to ask for a specific version, allow falling back to the default one etc.
15:21:12 <mojavelinux> one thing to consider is not pinning the repo name to the name "maven", just call it artifact-repository or something, since there are other tools that can use that layout (not critical, just something to consider)
15:21:16 <fnasser> and of course if not found in the maven repo it uses the regular one
15:21:22 <fnasser> I mean, pre-mavenization one
15:21:47 <sochotni> ok, while as Maven maintainer I'd like to discuss this more...it's out of scope for this meeting right now
15:21:49 <fnasser> mojavelinux, Not sure, maybe we should claim the name while we can :-)
15:21:54 <akurtakov> fnasser: current layout can not disappear :)
15:22:06 <fnasser> akurtakov, agreed
15:22:36 <sochotni> one thing which I wanted input on was JNI changes, I believe they will solve our current issues
15:22:47 <fnasser> akurtakov, But I bet when we have everything in a maven repo and people start using that it will gradually fade
15:22:52 <sochotni> i.e. noarch packages which BR arch-specific packages and then problems with _libdir
15:23:14 <nkinder> sochotni: yes, we're hitting those problems in rawhide currently.
15:23:27 <fnasser> 32 vs. 64 bits?
15:23:34 <sochotni> fnasser: yes
15:23:35 <nkinder> sochotni: as I understand the proposal, %_jnidir will no longer use %_libdir, right?
15:23:49 <sochotni> nkinder: correct
15:24:16 <sochotni> it will mean we will no longer be able to install 32 AND 64 bit JNI libs on the same system
15:24:23 <sochotni> in other words ... no multiarch
15:24:50 <sochotni> but there is a section in new guidelines explaining why multiarch is close to impossible to do right and simple at the same time
15:24:54 <nkinder> sochotni: we are fine with that on the Dogtag side of things
15:25:05 <nkinder> yes, mutiarch JNI is a bit of a pipe-dream
15:25:37 <sochotni> if we *did* do it, the guidelines would be too complicated to follow anyway IMO
15:26:07 <sochotni> nkinder: as you are one of primary users of JNI I trust your judgement here :-)
15:26:15 <akurtakov> it never worked so fine by me
15:26:28 <nkinder> sochotni: it's really mharmsen who is familiar with it on our side, but I know he is all for no multiarch JNI
15:26:35 <akurtakov> eclipse is doing the so file embeding in jar
15:26:39 <mharmsen> yes
15:26:50 <sochotni> akurtakov: my favourite approach
15:27:05 <mefoster> This also affects packages that aren't strictly Java packages -- e.g., I need to link against some libs from OpenOffice
15:27:25 <mefoster> So we also need to coordinate with people packaging things that happen to have jars in them ...
15:27:44 <akurtakov> mefoster: can you ellaborate please ?
15:27:46 <sochotni> mefoster: once I change _jnidir in rawhide a simple rebuild will fix things
15:28:11 <mefoster> akurtakov, sochotni: libreoffice jars aren't in _jnidir ...
15:28:24 <sochotni> if possible I'd like to do these changes in F18, though that would need a bit of coordination :-)
15:28:28 <mefoster> e.g., I need to link against /usr/lib64/libreoffice/program/classes/unoil.jar
15:28:36 <mefoster> and the lib64 gives a problem
15:28:59 <sochotni> mefoster: ah, right...so just make them follow our guidelines :-)
15:29:03 <fnasser> DO you guys mind if I consult some people about the multarch issue?  But unfortunately I cannot get a response for this mtg
15:29:26 <akurtakov> fnasser: any input is welcome , at anytime :)
15:29:32 <mefoster> If all the libreoffice jars were linked to /usr/share/java or somewhere it would be useful
15:29:54 <sochotni> fnasser: I was kinda hoping people noticed my warnings already, but indeed...if we can have issues with that I'll wait
15:30:03 <sochotni> with proposal to FPC I mean
15:30:06 <akurtakov> mefoster: I doubt libreoffice guys will gave up on multiarch
15:30:19 <fnasser> soI will write an e-mail right after the mtg
15:30:30 <sochotni> fnasser: ok, thanks
15:30:31 <fnasser> sochotni, and get back to you as soon as possible
15:31:26 <tradej> #action fnasser will get input on JNI from libreoffice
15:31:33 <mefoster> akurtakov: Yes, I know -- just if some solution were found for that issue, it would clean up one of my spec files
15:31:37 <sochotni> if noone is against, I'll add %check mvn-rpmbuild check part to templates and as a SHOULD item for maven packaging
15:32:21 <sochotni> mvn-rpmbuild verify that is
15:32:57 <tradej> np with that
15:33:13 <sochotni> done that already
15:33:30 <akurtakov> +1
15:34:01 <tradej> #info sochotni added mvn-rpmbuild verify as a SHOULD item for maven packaging
15:34:08 <sochotni> mefoster kindly provided nicer documentation for %add_maven_depmap and I believe that's not controversial at all so I'll skip that
15:35:03 <sochotni> one last item on my list: compat packages support
15:35:13 <sochotni> for maven mostly
15:35:52 <sochotni> which means following: if maven finds *exact* version as was requested in pom.xml, it will use that
15:36:05 <sochotni> otherwise it will fallback to default unversioned jar
15:36:57 <fnasser> makes sense
15:37:18 * mefoster has to leave now, sorry
15:37:44 <tradej> sochotni: +1
15:38:00 <sochotni> compat packages *must not* have unversioned jars
15:38:03 <fnasser> sochotni, I'd like to have more control though.  In a similar situation we had an env variable and maven would be strict if we had some value there
15:38:04 <sochotni> that's about it
15:38:40 <wolfc> is the unversioned always the latest version?
15:38:46 <sochotni> fnasser: i.e you'd like to be able to say "use default no matter what"?
15:38:50 <fnasser> sochotni, +1 to no unversioned jars in either legacy or progressive packages
15:38:53 <sochotni> wolfc: it should be
15:38:55 <wolfc> I encountered a situation where it would downgrade (with fmvn)
15:38:56 <fnasser> (your compat)
15:39:18 <fnasser> sochotni, Or fail if did not find the exact match
15:39:41 <tradej> yeah, i think the 'fail' option is useful
15:39:56 <fnasser> sochotni, We had this env variable set before running maven and it would behave accordingly to it  (we used it for signing but it is the same idea)
15:40:01 <sochotni> fnasser: I'll look into it, should be possible without too much trouble but that's implementation issue
15:40:17 <fnasser> sochotni, right.
15:40:36 <sochotni> I have some improvements planned in Maven wrt this compat stuff
15:40:41 <fnasser> the observation was simply "more control"
15:40:43 <wolfc> sochotni: it happens in case somebody installs a newer version as a compat
15:40:45 <sochotni> it's not used much but in some cases it's really usefull
15:40:59 <sochotni> wolfc: that would be...unwise to be diplomatic :-)
15:41:04 <wolfc> :-)
15:41:53 <tradej> anyone has anything more about the guidelines?
15:41:56 <wolfc> as for the fail option, it is useful to detect problems. But I fear the poms are not in a state that they specify the correct version always.
15:42:16 <sochotni> I've added few more things suggested earlier today (examples mostly)
15:42:37 <wolfc> In other words the installed maven poms do not form (nor are expected to form) a valid component matrix.
15:42:56 <fnasser> wolfc, good point
15:42:59 <sochotni> wolfc: true, it's unlikely it will be really useful but I can provide that option
15:43:34 <wolfc> I'm hoping at some point we'll have a build tool that actually builds up a valid repo from any given source.
15:43:46 <sochotni> btw there is a link to http://git.fedorahosted.org/git/?p=javapackages.git;a=blob_plain;f=macros.fjava in the guidelines
15:43:53 <sochotni> not sure if we want to keep there
15:44:02 <sochotni> it's just meant as "online docs"
15:44:41 <sochotni> it's possible that FPC will tell us to get rid of it in case we'll rig the system :-)
15:45:12 <sochotni> oh...completely forgot important part: J2EE APIs
15:46:03 <sochotni> I've prepared proposed default implementations that should have those "javax.XXX" provides
15:46:10 <wolfc> the JDK is likely to lag behind JavaEE again
15:46:19 <sochotni> I picked mostly based on Require chains being smaller
15:46:55 <sochotni> wolfc: possible, we still have option to use package names directly
15:47:01 <sochotni> until such time that JDK will catch up
15:47:13 <sochotni> or we change guidelines to accommodate that change :-)
15:47:39 <akurtakov> fwiw, very few packages require newer version than the on in the jdk
15:48:01 <sochotni> I can see JBoss being one that's likely to require new stuff
15:48:02 <akurtakov> and if they do it's even rarer for them to work with random implemenation at given version
15:48:07 <sochotni> but they provide it themselves so...
15:48:10 <akurtakov> they require their own usually
15:48:20 <sochotni> yup
15:49:15 <sochotni> I believe the package set is sane, and we'll work with owners of affected packages to add those directories into javadir
15:49:59 <sochotni> this can easily be done retroactively for F18 as well since it just adds options
15:50:05 <sochotni> we are not removing anything
15:51:15 <akurtakov> I even think that apis in the jdk should not have virtual provides
15:51:37 <akurtakov> and we keep the JavaEE apis as real EE (aka not in the JVM )
15:51:43 <sochotni> akurtakov: right, that is not actually mentioned in the text
15:52:29 <sochotni> intention is: if your package requires J2EE api already provided by JDK, remove that dependency from poms
15:53:29 <wolfc> I'm not in favor of that one
15:53:46 <sochotni> wolfc: I had a feeling you would not be :-)
15:53:56 <wolfc> Especially moving forward when the JDK really gets modular, hur hur
15:54:14 <sochotni> wolfc: that's years in the future TBT
15:54:21 <sochotni> JDK 9+ currently AFAIR
15:54:48 <vanaltj> and when it was orgininally supposed to be 7, and now 9, it is not too hard to believe ti could be further delayed.
15:55:10 <wolfc> :-)
15:55:16 <sochotni> indeed, JIGSAW is currently duke nukem forever of software development :-)
15:55:19 <wolfc> if the pom doesn't reflect such need, then we should not either
15:56:15 <wolfc> (but I'm still not in favor :-) )
15:56:18 <sochotni> generally we have 2 alternatives: jdk providing a bunch of empty directories + empty mappings (which will be hard to override if need arises)
15:56:36 <sochotni> or...removal of said dep from pom.xml
15:56:56 <sochotni> when I say empty mappings I am talking depmaps in maven2-common-poms
15:57:07 <wolfc> only those poms that require different versions have such dependencies
15:57:32 <sochotni> wolfc: they mostly have it because they support JDK 1.4/1.5
15:57:51 <akurtakov> wolfc: many packages still require javax.activation
15:57:58 <akurtakov> at version older than the one in jvm
15:58:04 <sochotni> akurtakov: I meant to use that example!
15:58:06 <sochotni> :-)
15:59:15 <wolfc> just note my concerns and we'll revisit once JDK does get modular :-)
15:59:31 <sochotni> wolfc: duly noted :-)
15:59:51 <sochotni> #note wolfc is unhappy about patching javax stuff out of pom, but content for now
16:00:07 <sochotni> I actually don't think there is a #note command but oh well...
16:00:17 <akurtakov> wolfc: I'll be the first one to propose a change once we have modular jvm :)
16:00:27 * akurtakov promises
16:00:48 <sochotni> now I don't want to drag this too much...
16:01:00 <sochotni> people have other meetings to enjoy as well I guess :-)
16:01:00 <mojavelinux> it may be interesting to note that Oracle announced yesterday that they are partially modularizing the JDK distro
16:01:14 <sochotni> mojavelinux: ah, missed that
16:01:18 <mojavelinux> just mentioning that as it might be something to track, people could ask about it as it pertains to the icedtea builds
16:01:28 <mojavelinux> check out the technical keynote reply when it comes online
16:01:30 <sochotni> mojavelinux: have link at hand?
16:01:34 <mojavelinux> it's worth listening to how they pitched it
16:01:37 <mojavelinux> pulling it up
16:02:00 <mojavelinux> http://www.oracle.com/javaone/live/on-demand/index.html
16:02:20 <sochotni> I guess we'll just go ahead with patching and if things don't work out we'll be out of sync with guidelines in reality for a bit
16:02:27 <mojavelinux> not available yet
16:02:31 <sochotni> I don't think it would be such a great issue
16:03:22 <sochotni> so...for people who have read and noticed those proposed changes...any major comments/worries we should discuss?
16:03:58 <sochotni> otherwise pending fnasser's investigation of multiarch and my small improvements to %add_maven_depmap...I'll be submitting current version for FPC
16:04:43 <sochotni> just realized...if I add new files (_datadir/maven-repo/X/) to add_maven_depmap stuff will stop rebuilding
16:04:51 <sochotni> because it will need new %files section
16:05:11 <sochotni> eh, new lines in %files section
16:05:27 <akurtakov> sochotni: unless you make it an option
16:05:37 <sochotni> akurtakov: unless! :-)
16:05:41 <akurtakov> fwiw such change is not acceptable for non-rawhide
16:06:15 <sochotni> akurtakov: most probably not
16:06:29 <sochotni> though it doesn't affect users really
16:06:56 <sochotni> just packagers would need to do some work when rebuilding
16:07:19 <sochotni> I can make it depend on a switch though
16:07:43 <sochotni> we need to touch those packages one way or the other
16:08:03 <sochotni> if we want maven-repo I mean
16:08:11 <sochotni> so...switch for add_maven_depmap it is
16:09:34 <sochotni> let's make it -m (or -r) :-)
16:09:49 <sochotni> I'll send email to java-devel once it's in rawhide
16:10:28 <tradej> Anyone has anything else?
16:10:36 <akurtakov> nothing from me :)
16:11:28 <sochotni> now what I'd like to do is revisit the change after we start using these new features
16:11:47 <sochotni> so...reconvene in a month or so after FPC approves the guidelines
16:12:30 <sochotni> as I see so many people here now I'll likely use this timeslot for further SIG meetings
16:12:56 <tradej> +1 on timeslot
16:13:00 <sochotni> it's likely lowest common denominator
16:13:09 <fnasser> +1
16:13:14 <graphite6> +1 on timeslot
16:13:41 <tradej> well then, give or take next month, same time.
16:13:55 <tradej> if nobody has anything, meeting is adjourned.
16:14:04 <fnasser> C U later
16:14:05 <sochotni> :-)
16:14:19 <sochotni> thanks everyone for participating/joining in
16:14:23 <tradej> #endmeeting