17:09:50 <abadger1999> #startmeeting fpc
17:09:50 <zodbot> Meeting started Wed Feb 27 17:09:50 2013 UTC.  The chair is abadger1999. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:09:50 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
17:09:54 <abadger1999> Rathann, geppetto, tibbs, spot, racor, SmootherFrOgZ, limburgher, rdieter: FPC meeting ping
17:10:00 <tibbs> I'm around.
17:10:07 * geppetto is here
17:10:08 <tibbs> Just finished reading all of that scrollback.
17:10:25 <geppetto> I read bits of it … was confused about if the meeting had started
17:10:47 * rdieter here, but may need to leave on short notice
17:10:47 * limburgher here, sort of.  Getting over being sick, working from home.
17:11:25 <abadger1999> Okay, that's just enough for quorum.
17:11:44 <geppetto> yeh, pretty sure spot is traveling
17:11:50 <abadger1999> #topic new Java Guidelines https://fedorahosted.org/fpc/ticket/260
17:12:26 * racor is here
17:13:07 * Rathann here, too
17:13:25 <tibbs> For me, this is another of those situations where it appears Java has chosen the most hilariously complicated way to do something, and I don't feel as if I have the capacity to understand it.
17:13:37 <abadger1999> This is both a continuation of https://fedorahosted.org/fpc/ticket/257 and changes to the existing guidelines.
17:13:57 <abadger1999> Java SIG worked out their differences of opinion for 257.
17:14:16 <abadger1999> The changes they made affected the xmvn package but not the guidelines per se.
17:14:39 <tibbs> I mean, it seems as if it's all well-considered, but I just don't have enough background to make a useful decision and haven't had the time to acquire it.
17:15:26 <abadger1999> As talked about last meeting, the strategy of xmvn is when the package is built, a file is constructed that holds the dependency information for all the jars that the package deps on.
17:16:31 <abadger1999> After talking to mizdebsk, it seems that even if this fle (an "effective pom") contains false deps, the results aren't likely to break an end user's system.
17:16:45 <abadger1999> so I don't think we need to anything there.
17:16:59 <abadger1999> anyone disagree?
17:18:06 <geppetto> Seems like we must be missing something … if they are "bundling" deps. it must break in some way, without mass rebuilds.
17:18:37 <limburgher> Right, why have 2 dep mechanisms?  What's the benefit?
17:18:41 <geppetto> Worst case they have deps. in some future builds that aren't there anymore … or even worse, don't have deps. that are there now.
17:19:44 <abadger1999> So the argument is -- the package will refuse to rebuild if that happens.
17:20:15 <geppetto> The later case, you'd assume so yeh.
17:20:28 <abadger1999> and also, applications will continue to run.
17:20:36 <abadger1999> but just building against the package will fail.
17:20:38 <tibbs> I guess this is a common problem whenever you have some domain-specific dependency system that's getting mapped to RPM dependencies.
17:20:49 <abadger1999> mizdebsk: Is my last statement accurate ? ^
17:20:51 <mizdebsk> we have 2 dep mechanisms (RPM and POM) so that Java build tools can read dependencies of installed packages without relying on RPM. these 2 dependency sets should always match each other as they are generated automatically
17:20:57 <tibbs> So the usual question is how do we automate the finding and fixing of errors in that mapping?
17:21:36 <mizdebsk> any bugs found in that mappoings would be there anyways, in form of broken RPM dependencies
17:21:40 <tibbs> Or is that not the issue here?
17:22:29 <mizdebsk> there could be some problems, but on very rare ocasion
17:23:09 <mizdebsk> and those problems would be mostly excessive dependency (as abadger1999 said)
17:24:26 <limburgher> So failure would err on the side of bloat, rather than breakage?
17:24:42 <limburgher> That's my preference, just clarifying.
17:25:14 <mizdebsk> limburgher: yes, i would say so
17:26:30 <mizdebsk> we are monitoring dependencies of major end-user applications on daily basis and fixing any dependency bloat, for example: https://binaryparadise.com/~w0rm/files/fedora/min_install/maven.svg
17:26:52 <abadger1999> I think it's slightly different emphasis ... there's actually going to be three dep sytems.  RPM, raw poms, and effective poms.  The raw poms are shipped by upstream to help upstream software build in maven.    The effective poms contain the information in the raw poms from the package and its parents.   This lets the rpm package get rid of a Requires: that is unneeded at runtime if the package would need the POM information from the parent
17:26:53 <abadger1999> for being built against.
17:27:21 <limburgher> Ahh.
17:27:43 <mizdebsk> yes, exactly
17:28:01 <geppetto> more is always better
17:28:37 <geppetto> meh. … anyway, I'm +1 on the Java SIG guildline change … it is what it is.
17:29:14 <limburgher> I'm +1 too.
17:29:35 <geppetto> Although they do say <"MUST" do XYZ> a couple of times now and then say <or you can do FOO>
17:29:38 <abadger1999> so Q: what does effective poms solve?  A: devel requires bloating an rpm's runtime deps.   Q: how does it do that?  A: by copying the pom information that may be needed to build into the dependent packages at build time.  Q: What possible breakage is there? A: extra packages are still possible if there's a bug in the pom and getting rid of those would now require a rebuild of dependent packages.
17:30:59 <abadger1999> +1 for java guideline changes
17:32:58 <abadger1999> tibbs, rdieter, Rathann, racor: care to vote on the changes in https://fedoraproject.org/w/index.php?title=User%3AMsrb%2FJavaPackagingDraft&diff=324747&oldid=323129
17:33:44 <tibbs> I'm torn between abstaining because I don't get it and voting for it because it seems like it's at least been well thought out.
17:34:33 <tibbs> Or is the effective pom discussion not enbodied in the guideline diff?
17:34:34 <rdieter> +1
17:34:47 <abadger1999> tibbs: The effective poms discussion isn't embodied in the guideline
17:34:53 <tibbs> Jeez.
17:34:57 <abadger1999> it's implemented by xmvn which is in the guideline
17:35:07 <abadger1999> so we're okaying it implicitly.
17:35:16 <tibbs> Now I've lost track of how many different issues are floating around here.
17:35:24 <mizdebsk> tibbs: there is nothing about effective POM in the guidelines, java SIG agreed it doesn't need to be included there
17:35:52 <racor> 0, I feel lost and therefore am abstaining
17:36:05 <tibbs> I'm just abstaining at this point.
17:36:15 <abadger1999> k
17:36:42 <tibbs> trying to not let all of this further damage my opinion of java.
17:36:44 <abadger1999> so at the moment, voting is +1: 4, 0: 2  with three votes not given.
17:37:08 <abadger1999> I'll record that in the ticket to let the other FPC members get a chance to vote.
17:37:15 <abadger1999> (Need +5 to pass)
17:37:41 <tibbs> But I have to say, having this huge discussion about the effective pom thing and then tossing in a guideline update that has nothing to do with that isn't the best way to keep people from being confused.
17:37:45 <abadger1999> #info New Java Guidelines Currently at (+1: 4, 0: 2, -1: 0); voting to continue in the ticket
17:40:00 <abadger1999> #topic Should rpm macros files be marked %config https://fedorahosted.org/fpc/ticket/259
17:40:17 <abadger1999> dmalcolm asks whether macro files should be marked %config.
17:40:23 <tibbs> I'd answer that question in the negative.
17:40:33 <rdieter> easyfix, yeah
17:40:33 * abadger1999 agrees
17:40:50 <tibbs> RPM has plenty of mechanisms for overriding macros; they should be used instead of hand-editing the installed macro files.
17:40:55 <abadger1999> Proposal: rpm macro files *must not* be marked as %config
17:40:59 <rdieter> +1
17:40:59 <abadger1999> +1
17:41:00 <tibbs> +1
17:41:18 <tibbs> Does rpmlint warn here?
17:41:36 <tibbs> If they aren't marked %config?  Because I would wager that's why so many packages do so.
17:41:49 <rdieter> yes, rpmlint fail
17:41:51 <abadger1999> tibbs: It might... I think that it hasa heuristic of files in /etc/
17:42:12 <tibbs> I believe there's a hardcoded list of places where it doesn't warn.
17:42:18 <tibbs> But it's been a while since I looked.
17:42:39 <abadger1999> I'll open a ticket against rpmlint to change that (assuming we get quorum of +1 votes)
17:42:43 <racor> +1, not mark them %config
17:43:04 <abadger1999> Need one more.  limburgher, geppetto?
17:43:43 <abadger1999> Rathann: ?
17:44:22 <abadger1999> #info Current vote on: RPM Macro files '''MUST NOT''' be marked as %config  (+1: 4, 0: 0, -1: 0)  voting to continue in ticket
17:44:31 <geppetto> +1
17:44:41 <abadger1999> #undo
17:44:41 <zodbot> Removing item from minutes: <MeetBot.items.Info object at 0x29cbf490>
17:44:55 <abadger1999> #info Approved: RPM Macro files '''MUST NOT''' be marked as %config  (+1: 5, 0: 0, -1: 0)
17:45:41 <tibbs> Yeah, rpmlint just warns about everything in /etc that's not buisted or marked %config.
17:45:59 <tibbs> "buisted"?  What did I even mean to type there?
17:46:07 <tibbs> "ghosted".
17:46:28 <tibbs> Either too many drugs or not enough.
17:46:35 <geppetto> :)
17:47:19 <abadger1999> #topic Bundling exception for nmap https://fedorahosted.org/fpc/ticket/255
17:47:36 <abadger1999> nmap would like to bundle a newer version of lua than we ship on the system
17:47:47 <abadger1999> On the one hand, I really don't like bundling languages.
17:47:58 <abadger1999> On the other hand, this is bundling of a non-forked newer version
17:48:14 <abadger1999> So the timeframe to expire would be when the system lua package is updated to the newer version.
17:48:21 <tibbs> I would agree to a temporary exception of we knew what the lua maintainer actually intended to do.
17:48:42 <tibbs> Because that newer version can easily turn into an older version in the span of a couple of weeks.
17:48:45 <abadger1999> I beleive panu is the owner of lua (because rpm needs it)
17:48:46 <geppetto> -1 … nmap maintainer can/should be co-maintainer of lua if he wants
17:48:57 <abadger1999> .whoowns lua
17:48:57 <zodbot> abadger1999: timn (rmyers in Fedora EPEL)
17:49:06 <abadger1999> guess I was wrong there.
17:49:35 <tibbs> lua is one of those things that's crept into various things but isn't maintained as if it's a core component.
17:50:28 <tibbs> It does at least have a comaintainer (salimma) but if I'm remembering correctly both of them occasionally go inactive.
17:50:37 <abadger1999> yeah.
17:51:15 <geppetto> having N > 2 more co-maintainers is fine though, right?
17:51:17 <abadger1999> and they may be able to watch over lua the package, but to do this upgrade it sounds like we might need a concerted porting effort.
17:51:19 <tibbs> So I think the solution here is more maintainers for lua, but since upgrading may have other side effects I'd be OK with an exception.
17:51:27 <rdieter> +1 (temporary) exception
17:51:38 <geppetto> still -1 on exception
17:52:23 <abadger1999> +0
17:52:36 <tibbs> I don't think this will pass here.
17:52:43 <abadger1999> I guess I agree with tibbs that I'd like to know what the maintainers would like to do.
17:53:30 <abadger1999> It may also be a case where we decide to have a lua5.1 package and a lua-5.2 package.
17:53:40 <tibbs> Sure, of someone wants to do that.
17:53:45 <abadger1999> but without maint input we don't know.
17:53:56 <tibbs> My fear is that they've asked the lua maintainers but haven't received a response.
17:54:01 <abadger1999> yeah.
17:54:17 <abadger1999> I'll write a request for more information.
17:54:18 <tibbs> And I'd hate to see a recalcitrant maintainer hold up other parts of the distro.
17:54:20 <racor> abadger1999: ACK, sounds like a case we need parallel packages.
17:54:46 <tibbs> Honestly I think we just need a lua update.
17:54:46 <geppetto> We have a NRM process
17:55:05 <geppetto> tibbs: yeh
17:55:20 <tibbs> OK, never mind; I did read https://bugzilla.redhat.com/show_bug.cgi?id=815263
17:55:45 <tibbs> and it seems that this is more of a case where we need parallel-installable packages if they want this in F18.
17:56:23 <tibbs> But for F19, I'm not sure why they don't move forward in current rawhide.
17:56:25 <geppetto> yeh, ok, I read the actual BZ too.
17:56:36 * rdieter (still) thinks requiring a parallel-instalable stack for one package is worse than bundling, imo
17:56:43 <geppetto> tibbs: Probably because nobody is stepping up to port rpm
17:56:48 <tibbs> rpm is ported already.
17:57:02 <tibbs> "FWIW, rpm >= 4.11 (currenly in rawhide) supports Lua 5.2 so from that POV starting..."
17:57:10 <abadger1999> for f18 definitely.  For f19, I don't know. f20, it could be just do it once rawhide is branched.
17:57:30 <geppetto> tibbs: Ahh, missed that … my bad.
17:58:01 <tibbs> Unfortunately "breaks a lot of things" doesn't really tell enough about how much effort is required.
17:58:11 * rdieter repoqueries, how many things BR: lua-devel these days
17:58:20 <rdieter> eep, 87
17:58:28 <tibbs> But, again, I'd support a temporary exception.
17:58:41 <tibbs> Through F19, but no further.
17:59:02 <abadger1999> okay...
17:59:23 * rdieter same as tibbs , except for s/though F19/until lua-5.2 lands/
17:59:33 <geppetto> I'd rather the nmap maintainer spend time making nmap compile on older releases, or helping lua do an official lua52 package.
17:59:34 <rdieter> which hopefully is the same thing
17:59:52 <geppetto> so still being annoying and saying -1
18:00:04 <abadger1999> Proposal: Temporary bundling exception for F19.  Work to either get main lua updated or parallel installable 5.1x and 5.2.x lua stacks for F20 and beyond.
18:00:09 <rdieter> geppetto: imo, we're meddling too much if we end up saying that (I guess we can agree to disagree)
18:00:17 <abadger1999> +1
18:00:18 <tibbs> +1
18:00:19 <geppetto> -1
18:00:22 <rdieter> +1
18:00:40 <tibbs> I mean, I don't feel super-strongly about this.
18:01:04 <tibbs> It just seems wrong to force security software to go backwards because the rest of the distro won't go forwards.
18:01:32 <abadger1999> racor, SmootherFrOgZ, Rathann: You can vote on the above proposal -- I'm going to have to take it to the ticket anyway, though (lack of quorum and we're out of time)
18:01:36 <racor> -1 to exception, recommend parallel lua52 package until lua is upgraded
18:01:57 <rdieter> forcing a compat lua52 for a single release is more than silly
18:02:14 <rdieter> ok, maybe just plain silly
18:02:22 <tibbs> I don't think it would be used just for nmap, though.
18:02:37 <tibbs> RPM would almost certainly use it.
18:02:49 <abadger1999> #info temporary exception for nmap to bundle newer version of lua in f19 only Current vote: (+1:3, 0:0, -1:2)  voting to continue in ticket
18:02:49 <racor> rdieter:  Can you exclude this is just the beginning of a general demand for a lua-upgrade?
18:02:55 <geppetto> yeh, it lets all the packages migrate easier … and should allow F20 to have a lua and lua51 packages, if there are any stragglers.
18:02:56 <tibbs> Though I think it should be compat-lua51 and letting the main lua package move forward.
18:02:59 <rdieter> I would... feel nervous if rpm changed lua interpreters mid-release
18:03:22 <rdieter> tibbs: +1
18:03:29 <abadger1999> #topic open floor
18:03:35 <abadger1999> Anything for open floor?
18:03:37 <geppetto> tibbs: I don't mind specifying it should go that way for F19
18:03:45 <abadger1999> If not I'll close the meeting in a minute
18:03:58 <tibbs> abadger1999: Your dependency filtering thing looked pretty good to me.
18:04:13 <tibbs> People are still using my old draft, which is unfortunate.
18:04:32 <abadger1999> tibbs: thanks. I had a package to experiment on so I took the plunge.
18:04:36 <tibbs> It was written back when we had to care for both methods, but it's been long enough that we should just forget about the old stuff.
18:04:49 <tibbs> Well, EPEL can't forget, but that's their albatross.
18:04:57 <abadger1999> yeah.
18:05:32 <abadger1999> if someone wants to work on he perl_defaultfilter, they're welcome too :-)  Otherwise I'll ping the perl-sig/old filtering guidelines people about changing that
18:05:43 <abadger1999> and hopefully we can vote on something next week.
18:05:52 <tibbs> I think the Perl default filters stuff was ported over ages ago.
18:06:50 <abadger1999> tibbs: ah cool.  I'll verify this week then.
18:07:00 <abadger1999> and then send email to panu.
18:07:17 <abadger1999> (and add that one section that was requested)
18:07:56 <abadger1999> Okay, thanks for coming everyone!
18:07:59 <abadger1999> #endmeeting