17:14:28 <abadger1999> #startmeeting fpc
17:14:28 <zodbot> Meeting started Wed Feb 20 17:14:28 2013 UTC.  The chair is abadger1999. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:14:29 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
17:15:03 <abadger1999> spot, racor: You around for FPC meeting?
17:16:46 <abadger1999> Let's start with byteman since we got a ping on it last night
17:16:47 * racor is half around - I am a bit distracted
17:17:04 <abadger1999> #topic additional exceptions for bundling in byteman: https://fedorahosted.org/fpc/ticket/226
17:17:42 <abadger1999> So, we had already given an exception for this to bundle objectweb-asm
17:18:02 <tibbs> For some reason I thought we were done with this.
17:18:23 <abadger1999> For much the same reason, they also need java_cup.
17:18:57 <abadger1999> spot proposed in the ticket:  " I'd be willing to grant a blanket exception for byteman to handle any other necessary components in exactly the same way we approved the ASM exception."
17:19:46 <abadger1999> Are we willing to vote on that or do we want discussion?
17:20:11 <tibbs> I'm swapping this all back in.
17:20:50 <abadger1999> <nod>
17:22:21 <tibbs> OK, yes, as long as the other bundled code is handled the way ASM is handled, that seems OK.
17:22:36 <tibbs> Sp +1 to spot's proposal in comment 14.
17:22:39 <abadger1999> +1
17:23:01 <abadger1999> geppetto, rdieter, SmootherFrOgZ, racor: voting on ticket 226
17:23:22 <geppetto> +1
17:23:26 <racor> 0
17:23:28 <rdieter> +1
17:24:28 <SmootherFrOgZ> +1
17:25:38 <abadger1999> That's 5
17:26:02 <abadger1999> #info additional bundling for byteman passes (+1: 5,  0: 1, -1: 0)
17:26:57 <abadger1999> #topic Use gem_install macro in ruby guidelines: https://fedorahosted.org/fpc/ticket/256
17:27:38 <Rathann> sorry, my daughter kept me busy for a while
17:28:58 <abadger1999> Rathann: no problem -- we're looking at https://fedorahosted.org/fpc/ticket/256
17:29:23 <Rathann> yes, I see it in the topic
17:29:42 <tibbs> Seems like this is a net win.
17:29:49 <abadger1999> I don't know why the macro allows setting the --install-dir.
17:30:40 <tibbs> But I'm always wary of macros which hide too much of the process
17:30:56 <Rathann> like %configure? ;)
17:31:05 * rdieter is ok with ticket #256 additions, +1
17:31:14 <tibbs> The problem is that occasionally something doesn't follow convention and you have to do it manually, but we've lost all description of what things used to be like without the macro.
17:32:13 <sochotni> tibbs: you can always "less /etc/rpm/macros.ruby" :-)
17:32:13 <rdieter> yeah, a tradeoff that makes 90% stuff easier, and the other 10% a little harder
17:32:33 <geppetto> tibbs: Like %configure or %systemd_post or …
17:32:52 <geppetto> I'm +1
17:32:55 <abadger1999> I'm +1 if --install-dir wasn't there or was explained why we should have that in the macro
17:33:11 <Rathann> abadger1999: it was there before
17:33:14 <Rathann> just expanded
17:33:16 <SmootherFrOgZ> I'm +1 with available option
17:33:17 <abadger1999> Rathann: no, it wasn't
17:33:23 <geppetto> abadger1999: We approved it in the copy and paste gem_install line?
17:33:27 <Rathann> looking at the diff I see it was
17:33:31 <abadger1999> Rathann: Before we specified:         --install-dir ./%{gem_dir} \
17:33:47 <abadger1999> Rathann: The macor specifies:         --install-dir '%{-d*}%{!?-d:.%{gem_dir}}' \\\
17:33:55 <sochotni> abadger1999: I assume that's to support possible SCL use
17:34:06 <sochotni> a wild guess though
17:34:09 <abadger1999> ie: it was hardcoded.  Now it's a parameter
17:34:12 <abadger1999> sochotni: SCL?
17:34:18 <sochotni> software collections
17:34:27 <geppetto> abadger1999: Yeh, but before it was copy and paste … so you could just tweak it.
17:34:41 <abadger1999> sochotni: Shouldn't come into play here.... This is to install into the local directory.
17:34:51 <Rathann> abadger1999: it was in the spec template
17:34:57 <Rathann> I wouldn't call that hardcoded
17:35:14 <Rathann> anyway, I'm +1
17:35:25 <tibbs> Sorry, house is full of in-laws.
17:35:27 <tibbs> +1
17:35:43 <racor> 0
17:35:53 <abadger1999> the thing I am a little worried about is that this is the %build step.  I don't want this macro to get used to install instead of build
17:36:06 <abadger1999> Maybe we should name it %gem_build as well?
17:36:31 <abadger1999> kinda funky though since it's implemented via gem install...
17:37:59 <geppetto> yeh, naming it via. the section it goes into is probably better.
17:38:33 <geppetto> But %gem_install also maps well to %configure
17:38:36 <geppetto> So … meh.
17:38:51 <abadger1999> k.  How about I'll +1 and we just recommend that they name it %gem_build since the purpose of the macro-ized command is to build the software?
17:39:01 <abadger1999> s/name/rename/
17:39:01 <geppetto> sure
17:39:04 <abadger1999> +1
17:39:11 <Rathann> they say %gem_install compiles any C extensions and installs the gem into ./%gem_dir
17:39:18 <Rathann> in a comment
17:40:14 * rdieter is +1 either way, but would prefer not renaming since it is a wrapper to 'gem install' after all, calling it something else may well lead to more confusion
17:40:22 <tibbs> Either way is confusing to someone, but abadger1999's proposal is a little less confusing to me.
17:40:37 <SmootherFrOgZ> rdieter: +1
17:40:54 * abadger1999 is now confused why it says "C extension" but that was in there before so....
17:41:56 <tibbs> To be honest I'm happy to defer to the ruby folks as to the naming.  I don't know if they thought about this when they chose the current name.
17:42:05 <abadger1999> #info update to Ruby Guideline to use %gem_install passes with a note that renaming it to something that reflects that this is a build step, not install step would be desirable.
17:42:39 <abadger1999> #nfo (+1: 6, 0: 1, -1: 0)
17:44:07 <abadger1999> okay -- we have two more new ones that may be a bit controversial... bundling of lua in nmap (since the Fedora package is not current) and an issue with xmvn
17:44:28 <abadger1999> Let's do xmvn first since it affects the java feature.
17:44:36 <abadger1999> #topic Xmvn problems https://fedorahosted.org/fpc/ticket/257
17:45:17 <sochotni> FYI mizdebsk wrote a long explaining email to java-devel today http://lists.fedoraproject.org/pipermail/java-devel/2013-February/004649.html
17:46:15 <abadger1999> thanks
17:46:18 * abadger1999 reads
17:46:24 <sochotni> it's really long though
17:46:25 <sochotni> :-)
17:47:20 <rdieter> is there any cliff's notes java-sig consensus/recommendation in there?
17:47:54 <sochotni> rdieter: well I believe there were 2 issues at play and alex put them together
17:47:59 <sochotni> it might get confusing I guess
17:48:02 <tibbs> You know, I don't think anyone has ever actually communicated what on earth a POM is.
17:48:20 <sochotni> tibbs: for example http://repo1.maven.org/maven2/org/sonatype/plexus/plexus-cipher/1.7/plexus-cipher-1.7.pom
17:48:29 <sochotni> it's a build recipe for maven
17:48:32 <tibbs> So... it's not code?
17:48:36 <sochotni> what dependencies are to be used, what versions
17:48:49 <tibbs> All of this is an argument over the bundling of metadata?
17:48:54 <sochotni> no, though it affects code creation and in some cases behaviour of packages
17:49:02 <sochotni> partially
17:49:06 <sochotni> that's 1 part
17:49:33 <sochotni> second part was basically this: http://pkgs.fedoraproject.org/cgit/maven-surefire.git/commit/?id=10dbd6b582f09f4c510ff5171fb9dfd12fb73149
17:49:54 <sochotni> i.e. mizdebsk created that new way to package Maven stuff
17:50:31 <sochotni> we started testing it out and it got out of hand (we ended up converting ~100 packages)
17:50:46 <sochotni> I am to blame for that
17:51:04 <rdieter> that "new" way does seem ... a lot simpler
17:51:09 <sochotni> IMO the spec files don't conform to Java guidelines, but binary packages do
17:51:17 <sochotni> rdieter: yes, that was the whole point of it
17:51:30 <geppetto> rdieter: But according to Java SIG it means that A needs to be rebuilt when X is, right?
17:51:41 <geppetto> rdieter: So the line is still there, just invisible?
17:51:41 <sochotni> geppetto: that would be going back to issue 1
17:52:04 <sochotni> so the xml file I pointed to has "parent"
17:52:25 <sochotni> Maven deals with inheritance (similar to chaining of .h files I guess)
17:52:45 <sochotni> what XMvn does is that it takes all parent pom.xml files and puts them all together
17:53:01 <sochotni> if parent pom has a bug which affects some runtime parameters...
17:53:12 <sochotni> it means all children will embed that bug
17:53:31 <sochotni> and fixing the bug will require fixin parent and then rebuilding all children (possibly recursively)
17:53:48 <Rathann> ok, I read it and it seems reasonable
17:53:53 <sochotni> this is very rare situation IMO (alex would not agree here I guess)
17:53:56 <rdieter> sochotni: does anyone (particularly in java sig) object to using xmvn ?
17:54:38 <sochotni> rdieter: not in principle, I believe alex raised the XMvn usage due to effective poms (which come into play with XMvn)
17:55:03 <sochotni> mizdebsk and akurtakov *seem* to have found a workable solution based on last few emails in java-devel
17:55:14 <sochotni> but I don't want to speak for any of them
17:55:30 <geppetto> sochotni: Isn't his #4 saying that this is true now?
17:56:01 <sochotni> geppetto: which #4? talking about meeting log?
17:56:23 <geppetto> sochotni: So … for the set of bugs that would require rebuilding dependant packages due to the "effective POMs" … those would also require just as much work using his first #3 solution?
17:56:34 <geppetto> sochotni: #4 is the one at the bottom of the email.
17:56:40 <geppetto> sochotni: #3 is the one at the top.
17:57:12 <geppetto> sochotni: Labeled "case 3" … and I actually meant "case 2" … just to be more confusing … sorry :(
17:58:48 <Rathann> I would like to see some example POMs before and after this change
17:58:48 <sochotni> there are cases of bugs in parent poms which would get inherited by children and would need that "mass rebuild" only in case of using effective poms
17:58:55 <sochotni> Rathann: second
17:59:00 <abadger1999> sochotni: Are poms just a buildtime thing?  Could we split them out into their own -devel (like) package?
17:59:14 <abadger1999> or am I misunderstanding the issue that's trying to be addressed?
17:59:31 <Rathann> abadger1999: I understand they're something like gcc dependency metadata
17:59:32 <sochotni> abadger1999: They are build time only, except for maven plugins and the like which need parent poms to work
17:59:41 <geppetto> sochotni: Ok … so there are new cases where a rebuild would be required … do we have any data on how likely those cases are?
18:00:11 <sochotni> geppetto: I can only speculate, Alex is expecting this to affect Eclipse in coming weeks/months
18:00:28 <sochotni> http://kojipkgs.fedoraproject.org//packages/maven-dependency-analyzer/1.3/7.fc19/noarch/maven-dependency-analyzer-1.3-7.fc19.noarch.rpm
18:00:58 <sochotni> that rpm contains effective pom in /usr/share/maven-poms/
18:01:16 * rdieter would prefer to wait on this, until java-sig reaches some agreement/consensus (doesn't seem we're at that point yet)
18:01:29 <sochotni> http://search.maven.org/remotecontent?filepath=org/apache/maven/shared/maven-dependency-analyzer/1.3/maven-dependency-analyzer-1.3.pom
18:01:35 <sochotni> ^ that's "raw" pom
18:02:08 <sochotni> rdieter: I believe Alex was concerned with out-of-guidelines changes to spec files
18:02:22 <rdieter> rightly so.
18:02:42 <rdieter> mind  you, fpc isn't in the business of enforcing guidelines either
18:02:56 <rdieter> so I'm not sure what we're being asked to do here
18:03:02 <sochotni> as I said previously, I believe binary packages are following guidelines
18:03:46 <sochotni> rdieter: well, I guess Alex is mostly asking "is this fair game"
18:04:29 <rdieter> I guess I'd say deciding that is premature.  why not focus efforts finding agreement/consensus on this new way of doign things?
18:05:11 <rdieter> or is that not practical ?
18:05:12 <sochotni> no argument there, so keep status quo for now I guess until more info...
18:05:26 <abadger1999> If we're looking for alternatives to embedding POMs, it might be possible to do by splitting packages into buildtime and runtime deps similar to C libraries having runtime packages and buildtime (glib && glib-devel)
18:05:30 <geppetto> sochotni: The ticket from alex read more like "wtf is this guy doing, can you stop it" … but after reading a lot and understanding a little, my guess is that "is this fair game" is maybe … certainly if Java SIG wants to do it that would be a major positive.
18:05:47 <abadger1999> but I'm not sure I understand all the moving parts so I could be wrong.
18:06:35 * akurtakov is here now but missed whatever was discussed
18:06:48 <sochotni> abadger1999: yeah, except rpm can't really handle those deps appropriately (i.e in some cases a Require is necessary but package itself is perfectly usable without it in different contexts)
18:07:08 <abadger1999> IMHO it's nicer not to embed part of another package in the current one but... if poms are just dependency information it doesn't seem as problematic as the bundling of libraries rules.
18:07:25 <abadger1999> sochotni: well -- are the contexts buildtime vs runtime?
18:07:25 <akurtakov> abadger1999: they are not just dependency information
18:07:35 <abadger1999> akurtakov: I can pastebin logs too, just a moment.
18:07:47 <sochotni> abadger1999: 90+% build time only
18:08:01 <akurtakov> they may contain many other informations
18:08:01 <abadger1999> akurtakov: http://paste.fedoraproject.org/3467/
18:08:14 <abadger1999> akurtakov: What other information is contained in them?
18:08:16 <sochotni> abadger1999: though it can affect runtime of maven plugins and other uses in maven context
18:08:33 <akurtakov> abadger1999: supported archs, configurations for what is available on classpath
18:08:50 <akurtakov> plain everything
18:09:07 <akurtakov> as every maven plugin can be configured this way
18:09:21 <akurtakov> and it's up to the plugins configured in the parent pom
18:09:43 <akurtakov> I do agree that we speak about 100% build time issues as maven is build tool
18:10:00 <sochotni> for what it's worth I believe we will have a solution so maintainers who wish to maintain their runtime dependencies manually can set-up their pom files in such way
18:10:35 <akurtakov> but the question is packager-use-of-maven vs. developer-use-of-maven
18:10:53 <akurtakov> what was introduced serves packages just fine
18:11:08 <akurtakov> but neglect the needs for people using it for upstream development
18:11:11 <abadger1999> So it sounds like poms contain dependency and configuration information.  Not code but it can affect how the code that is invoked operates.
18:11:43 <abadger1999> ^ Is that correct on the limits of what poms do?
18:11:59 <sochotni> akurtakov: people should use "mvn" script for upstream development which will ignore our poms completely in either case
18:12:12 <sochotni> akurtakov: and I know you like mvn-local
18:12:30 <akurtakov> sochotni: by advertising this you plain say don't use packages you know ?
18:12:51 <akurtakov> as mvn will not use all the maven plugins you have installed on the system
18:13:01 <akurtakov> but download them from the internet
18:13:11 <sochotni> akurtakov: developer will just install "maven" package so no plugins will be pulled in
18:13:23 <sochotni> but that's for another time
18:13:26 <sochotni> abadger1999: yes, correct
18:14:01 <akurtakov> to point people to parent pom that configures way more  than dependencies http://git.eclipse.org/c/platform/eclipse.platform.releng.aggregator.git/tree/eclipse-parent/pom.xml
18:14:38 <akurtakov> abadger1999: yes, configuration and dependency(optional)
18:15:28 <akurtakov> sochotni: of developer will do yum install maven-*-plugin ?
18:15:29 <sochotni> yeah, so for example if "maven.build.timestamp.format" changes in parent pom, all child packages will produce timestamps based on the configuration from time when the plugins were built, not current setting
18:16:12 <akurtakov> why I bringed this to fpc is that the change happened in rawhide and it will happen with every next build that uses xmvn
18:16:30 <abadger1999> <nod>
18:16:34 <akurtakov> and what I asked for is this to be stopped until the details are cleared
18:17:02 <abadger1999> akurtakov: Maybe -- jump into the fesco meeting too -- fpc might change guidelines... but they aren't really in the business of stopping something.
18:17:05 <akurtakov> I found such behavior totally unacceptable in community
18:17:08 <abadger1999> how about this...
18:17:38 <akurtakov> abadger1999: I want fpc opinion whether it's acceptable to bundle configuration that way
18:18:26 <akurtakov> and have 3 packages have 3 different configs when it was supposed to be one single conf file
18:18:39 <abadger1999> fpc vote on asking fesco to suspend using xmvn for a week while FPC and Java SIG lok into whether it's really the way we want to go forward with packaging.
18:18:46 <abadger1999> akurtakov, sochotni: Does that work?
18:19:03 * abadger1999 will call an fpc vote and them bring it to fesco open floor now if so)
18:19:07 <sochotni> abadger1999: well can't really "stop" using it, but we already stopped converting more specs
18:19:10 <akurtakov> abadger1999: thank you
18:19:23 * akurtakov has to run now
18:19:39 <sochotni> but yeah, works for us I believe
18:19:45 <abadger1999> k
18:19:47 <abadger1999> FPC?
18:19:58 <geppetto> +1
18:19:58 <abadger1999> Proposal: ask fesco to suspend converting to xmvn
18:20:02 <abadger1999> +1
18:20:05 <SmootherFrOgZ> +1
18:20:13 <abadger1999> tibbs, rdieter, racor, Rathann:
18:20:23 <rdieter> +1
18:20:34 <Rathann> +1
18:20:37 <abadger1999> Thanks guys
18:20:48 <racor> no vote or 0, sorry I have not been able to follow this discussion
18:21:55 <tibbs> +1, I guess.
18:22:29 <tibbs> Not that I disagree with the changes (because I don't know) but because someone should at least try to update the guidelines before converting a bunch of packages.
18:22:36 <akurtakov> to be clear - in order to prevent further damage xmvn behaviour needs to be changed back to installing normal poms
18:22:53 <akurtakov> otherwise people can use xmvn without knowing for the issue
18:22:54 <sochotni> we still disagree on that one though...
18:23:15 <sochotni> or rather there's no final solution, though one is looking promising
18:23:26 <sochotni> anyway...gotta run or I'll die of hunger
18:23:29 <akurtakov> [20:22] <tibbs> Not that I disagree with the changes (because I don't know) but because someone should at least try to update the guidelines before converting a bunch of packages.
18:23:36 <akurtakov> nothing more
18:29:59 <abadger1999> Okay, thanks for coming everyone!
18:30:31 <abadger1999> We should try to read the java sig thread and add questions or discussion where appropriate this week.
18:30:38 <Rathann> I'm just reading it
18:30:45 <Rathann> one concern I found so far
18:30:52 <Rathann> http://lists.fedoraproject.org/pipermail/java-devel/2013-February/004661.html
18:31:03 <abadger1999> fesco approved the 1 week suspension of converting specs for us to look at the issues with the java sig.
18:31:04 <Rathann> but if this setting is explicitly set in reactor configuration
18:31:04 <Rathann> then it will take precedence over user configuration.
18:31:33 <Rathann> I'm not familiar with the specific case, but shouldn't it be the other way around in general?
18:32:32 <Rathann> also it seems that all akurtakov's concerns were answered in the thread
18:32:48 <Rathann> just that no action plan has been proposed and agreed upon yet
18:35:00 <abadger1999> k.
18:35:08 <abadger1999> So that's looking good.
18:35:22 <abadger1999> #topic Open Floor
18:35:35 <abadger1999> we're way over time but -- anyone have something for open floor?
18:35:53 <abadger1999> If not I'll close the meeting in 1 minute
18:36:39 <Rathann> nothing here
18:36:58 <abadger1999> #endmeeting