16:00:54 <abadger1999> #startmeeting fpc
16:00:54 <zodbot> Meeting started Wed Nov 14 16:00:54 2012 UTC.  The chair is abadger1999. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:00:54 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:01:01 <abadger1999> #topic Roll call
16:01:04 <abadger1999> Who's here?
16:01:05 * limburgher here
16:01:49 <abadger1999> racor, tibbs: You guys here for FPC meeting?
16:02:13 * SmootherFrOgZ here
16:02:14 <abadger1999> SmootherFrOgZ and geppetto said they were present just before I started the meeting.
16:02:37 <abadger1999> spot is busy but may be able to attend the last portion of the meeting.
16:03:16 * geppetto is here … for the record ;)
16:03:34 <abadger1999> rdieter: You here for FPC?
16:03:58 <rdieter> abadger1999: oh, I can pretend (a bit busy/distracted @ work tho)
16:04:06 <abadger1999> Okay.
16:04:17 * racor here
16:04:35 <abadger1999> That's six, so we have quorum :-)
16:05:15 <abadger1999> #topic https://fedorahosted.org/fpc/ticket/231  -- Requesting exception for libuv to bundle libev
16:05:46 <tibbs> Howdy.
16:06:08 <tibbs> libev seems to be a constant source of issues.
16:06:15 <abadger1999> sgallagh has been working on unbundling libraries from node.js.  libuv is one of those.  It in turn bundles libev.
16:07:57 <geppetto> so we can -1 this and it'll fix itself?
16:08:10 <abadger1999> that's the eventual idea.
16:08:24 <abadger1999> I'd also be okay with an exception with a limited time
16:08:34 <tibbs> Wait, how would it fix itself?
16:08:36 * rdieter too, +1 time-limited exception
16:08:39 <abadger1999> Say, okay to bundle through F19. Must unbundle by F20.
16:08:55 <abadger1999> tibbs: sgallagh would eventually get it unbundled upstream.
16:08:57 <limburgher> +1 if out by 20
16:08:59 <SmootherFrOgZ> yeah, +! with time-limited.
16:09:08 <geppetto> fair enough … +1
16:09:09 * rdieter would prefer to give longer, say ~1 year, approx ~2 fedora releases
16:09:11 * SmootherFrOgZ hopes it get renamed
16:09:16 <racor> +1 with time-limit
16:09:25 <abadger1999> +1 time limit.
16:09:32 <misc> what happen if the exception is not met ?
16:09:33 <tibbs> Will time limited work?  The request has no schedule for this splitting.
16:09:45 <misc> ie, the package is dropped from fedora ?
16:09:48 <rdieter> tibbs: we'll revisit it i guess
16:09:52 <abadger1999> rdieter: I'll ask in the bug if more time would be valuable.
16:10:17 <abadger1999> tibbs: we'd revisit.  there is the estimate of "likely to take months to accomplish"
16:10:22 <SmootherFrOgZ> misc: what rdieter said
16:10:45 <geppetto> I'm with SmootherFrOgZ too … just tell them an easy out is to just rename their libev library.
16:11:51 <abadger1999> although renaming is an out... if they're willing to change code so they can use system libev, that seems like it is a better solution.
16:12:07 <limburgher> Reduce, reuse, recycle!
16:12:09 <abadger1999> less code to maintain.
16:12:14 <abadger1999> limburgher: :-)
16:12:57 <abadger1999> Currently at +6
16:13:34 <abadger1999> tibbs, you can vote for the record if you lke.
16:14:11 <tibbs> I'm not sure unbundling by F20 is doable.
16:14:30 <tibbs> I'm not exactly sure which proposal has six votes.
16:14:46 <tibbs> Since rdieter said he supported unbundling but not on that schedule.
16:14:54 <abadger1999> okay.
16:15:22 <rdieter> consider me +1 either way, i'd just prefer extending the exception to f21 too
16:15:23 <tibbs> I support an exception, though.
16:15:43 <geppetto> rdieter: yeh
16:15:44 <abadger1999> tibbs: If you also feel better with F21, we can revote
16:16:03 <tibbs> I just don't want to be back here in, what, four months telling someone that they have to do work or we try to kick the package out.
16:16:05 <geppetto> Sure, I'll give a +1 to F21
16:16:07 <abadger1999> Proposal: Okay to bundle through F20.  Must unbundle by F21.
16:16:10 <abadger1999> +1
16:16:15 <tibbs> +1.
16:16:17 <limburgher> I'd be willing to switch to 21, just to there's a limit 21.
16:16:20 <limburgher> +1
16:16:24 <racor> -1 to F21, +1 for F20
16:16:32 <limburgher> not sure what the end of my sentence meant, exactly.
16:16:32 <rdieter> +1
16:16:38 <SmootherFrOgZ> +! to F21
16:16:42 <SmootherFrOgZ> +1
16:17:09 <tibbs> The other question is that when we say "must unbundle by release N", exactly what does that mean?
16:17:20 <tibbs> Before branching?  Or the day before release we block the package, or what?
16:18:14 <geppetto> I assume as it branches we'd have rel-eng hold it back.
16:18:18 <rdieter> tibbs: i'd hope that fpc would "revisit" the issue by then, but that assumes someone is policing and does followup
16:18:34 <abadger1999> I usually take it to mean must be in the final.  But yeah, checking at branching makes more sense.
16:19:16 <abadger1999> I've clarified the wording to: FPC voted that it would be Okay to bundle through F20. Must unbundle when F21 branches (so that F21 release has the unbundled copy).
16:20:18 <misc> rdieter: just create a cronjob that send a email at the right time :)
16:20:35 <limburgher> to rdieter. :)
16:21:08 <abadger1999> #topic https://fedorahosted.org/fpc/ticket/226  -- bundling request for byteman
16:21:20 <abadger1999> We discussed this last week and spot has been following up in the ticket.
16:21:51 <abadger1999> spot made a new proposal in https://fedorahosted.org/fpc/ticket/226#comment:6
16:22:43 <limburgher> Sounds like they would not then need an exception, no?
16:22:59 <tibbs> It's still bundling.
16:23:03 <abadger1999> mgoldmann added an implementation note: https://fedorahosted.org/fpc/ticket/226#comment:8   but it doesn't change the strategy.
16:23:34 <abadger1999> Well -- kinda a hybrid between bundling and static linking.
16:23:43 <limburgher> abadger1999:  That's exactly how I read it.
16:23:45 <abadger1999> but java doesn't have a notion of static linking.
16:23:50 <tibbs> Right.
16:24:11 <abadger1999> so it seems fair to treat it as bundling if everyone is agreeable to it.
16:24:29 <tibbs> Anyway, I'm +1 to the proposal.  I thought it would be too annoyingly restrictive for them, but they seem to think it's OK.
16:24:36 <abadger1999> +1
16:25:03 <SmootherFrOgZ> +1 from me
16:25:05 <limburgher> Wha+1
16:25:09 <limburgher> Damn.
16:25:17 <rdieter> ditto as tibbs , +1
16:25:22 <limburgher> Sorry, cannot type, or apparently, backspace today.
16:25:32 <geppetto> yeh, this seems much less like bundling and more like forking to me.
16:25:33 <geppetto> +1
16:25:43 <geppetto> real forking that is … with new names.
16:26:14 <racor> +1
16:26:26 <tibbs> I wouldn't call it forking at all.
16:26:49 <rdieter> a contrived fork
16:26:52 <tibbs> They run an automatic thing over another source tree to transform it in a predictable way and then link it statically.
16:27:15 <geppetto> well, that's spot's workaround.
16:27:28 <geppetto> But their first idea was just to manually rename, which is more like a fork.
16:27:30 <tibbs> No, that's actually how they originally implemented it, as I read things.
16:27:38 <abadger1999> +7 so this passes
16:29:05 <tibbs> I wonder how common this kind of thing is with Java.
16:29:44 * rdieter doesn't want to know
16:29:58 <rdieter> scared of the answer
16:30:15 <tibbs> re-namespacing libraries so they don't conflict seems like it might be not-uncommon.
16:30:54 <abadger1999> #topic https://fedorahosted.org/fpc/ticket/201  Changes to D guidelines
16:31:19 <tibbs> I had no idea this was back.
16:31:56 <limburgher> rdieter: :)
16:32:16 <abadger1999> This has been sitting there for a while -- I think that it actually needs some work to be a draft.
16:32:26 <tibbs> I thought spot took care of this four months ago; what remains to be done?
16:32:40 <abadger1999> There was linking it to the main page.  that's done.
16:33:04 <tibbs> And dropping one section that's not relevant.  What needs a draft?
16:33:05 <abadger1999> Then there was removing the static library portion since ldc (the d compiler) now supports shared libraries
16:33:24 <abadger1999> But... the current guidelines don't seem to say anything about shared libraries.
16:33:52 <abadger1999> "At this time, Linux does not support shared libraries for D code (only OSX does). As a result, D packages are explicitly excluded from the restrictions against packaging static libraries."
16:34:03 <tibbs> Right, that whole libraries section needs to go.
16:34:31 <tibbs> I guess someone would eventually need to write something to replace it, but that certainly isn't going to be me as I know less than zero about whatever language system this is.
16:34:39 <abadger1999> Do we still need the: "If your D package contains static libraries, you must disable debuginfo generation, by adding this line to the top of your spec file:"  s/static//  ?
16:35:00 <rdieter> I think we need someone with more knowledge about D to help make a draft
16:35:25 <tibbs> I think there's pretty much exactly one person who cares at all about D.
16:35:36 <abadger1999> And update the template => remove the Provides:[..] -static
16:35:59 <abadger1999> Change %files to include %{_libdir}*.so*  instead of %{_libdir}/*.a
16:36:14 <rdieter> abadger1999: that would be my naive guess too
16:36:17 <abadger1999> I can update the bug with these as questions.
16:36:25 <abadger1999> Anyone see anything else that should be asked?
16:36:57 <tibbs> I'm not sure I know enough to even spot something that's missing.
16:37:14 <abadger1999> <nod>
16:37:24 <geppetto> Which applications do we have that use D?
16:37:50 <tibbs> I'm not sure we have anything at all.
16:37:57 <misc> derelict
16:38:12 <tibbs> That's not an application, though.
16:38:20 <misc> mhh indeed, tought this was a ide
16:38:52 <SmootherFrOgZ> geppetto: right. b/c that would imply to rebuild them with shared libs
16:39:15 <geppetto> SmootherFrOgZ: I was thinking more … wtf are we wasting time on this for when nothing uses it ;)
16:39:25 <tibbs> Erm, derelict has exactly zero dependencies?
16:39:51 <limburgher> Better to get it right now before it grows many that don't comply.
16:40:11 <SmootherFrOgZ> huh, yeah :)
16:40:24 <tibbs> Yep, the derelict package is pretty broken.
16:40:46 <misc> dustmite , a d application
16:41:32 <tibbs> Maybe tango as well.
16:41:48 <tibbs> I guess that's a library, though.
16:42:00 <abadger1999> ldc-phobos-geany-tags, ldc-phobos-devhelp, ldc-phobos-devel, ldc-phobos, ldc-druntime, ldc-druntime-devel
16:42:01 <misc> ( well, half of biofornatics rpm are D related )
16:42:14 <tibbs> In any case, there are a few things, and a few packaging problems, which doesn't surprise me.
16:42:22 <abadger1999> those all Req/BReq ldc
16:43:11 <tibbs> So, anyway, we can't really do anything else here unless we get some kind of draft, I guess.
16:43:19 <abadger1999> Okay, I'll update the ticket with the current questions.
16:43:28 <abadger1999> Last thing I see today...
16:43:35 <abadger1999> #topic https://fedorahosted.org/fpc/ticket/222  Java guidelines update
16:43:58 <tibbs> And did we get an answer on that fesco ticket?
16:44:19 <tibbs> https://fedorahosted.org/fesco/ticket/961
16:44:26 <abadger1999> FESCo replied that java does not need to be multilib
16:44:29 <abadger1999> yep.
16:45:11 <tibbs> I'm getting confused by process here.
16:45:41 <tibbs> If I recall correctly, the fundamental issue was whether not using /usr/lib64 on 64-bit was OK because multilib will never be a consideration.
16:46:29 <abadger1999> Well -- using %{libdir} vs using /usr/lib was the question.
16:46:53 <abadger1999> multilib tied into it because it seems the only make-or-break reason to mandate %{_libdir}
16:47:31 <abadger1999> I'd still prefer %{_libdir} because i think it's also used to organize the types of files on the filesystem.
16:47:41 <geppetto> Right … the real question was can/should packages be able to ignore %{_libdir} if they don't plan on having multilib.
16:47:48 <rdieter> ok, /usr/lib/java it is
16:47:58 <tibbs> And that question is bigger than Java.
16:48:06 <abadger1999> right.
16:48:14 <rdieter> geppetto: seems the tentative answer is yes, but we don't need to go there (yet)
16:49:31 <tibbs> I'm OK with it, honestly.  Having to move things on 64-bit for no reason is just pointless overhead.
16:50:06 <geppetto> I hate it from a packaging tools POV … but, w.e.
16:50:32 <rdieter> java is special too
16:50:43 <geppetto> ruby is special.
16:50:46 <geppetto> D is special.
16:50:54 * geppetto could go on for a while.
16:50:57 <tibbs> If only we could have done /usr/lib and /usr/lib32 in the beginning, none of this would be a consideration.  But obviously that wouldn't have worked.
16:51:00 <abadger1999> I'd vote -1 to allowing ignore %{_libdir}, but if it gets approved, I'd be willing to revist the other things that this touches
16:51:11 <abadger1999> geppetto:  systemd is special.
16:51:13 <sochotni> fyi I am around
16:51:24 <geppetto> abadger1999: oh, for sure.
16:51:34 <sochotni> just forgot so reading backlog
16:51:34 <limburgher> Why not /usr/lib, /usr/lib64, and /usr/lib32?  Need to be ready for 128. . .
16:52:08 <geppetto> abadger1999: I thought the idea was that we'd ask FESCO and if they said it was ok we'd allow java/eclipse to ignore it.
16:52:09 <rdieter> as notting noted in the ticket, jvm's have always been explicitly blacklisted from multilib'ing anyway
16:52:18 <sochotni> geppetto: it's not just eclipse
16:52:25 <sochotni> Java stack is quite huge currently
16:52:44 <geppetto> abadger1999: I don't really mind being mean and saying no anyway … but it seems pointless to have asked FESCO.
16:53:05 <abadger1999> geppetto: Well.. I disputed that multilib was the only reason to use %{_libdir} and that we should address that as a broader issue last time.
16:53:27 <abadger1999> spot wanted to have the multilib question resolved so we knew more facts.
16:53:47 <racor> limburgher: gcc+glibc history. Multilib/arch subdirs actually can be arbitrarily chosen as subdir underneath of /usr/lib. They had started with /usr/lib/. on i386 20 years ago, and later had added /usr/lib/../lib64 many years later.
16:53:54 <sochotni> there never *was* multilib support in Java libraries officially so we partially tried to sort-of support it
16:54:12 <sochotni> there are multiple issues with noarch packages needing to access libdir during buildf
16:54:27 <sochotni> and then runtime figuring out what type of JVM you are running inside
16:54:33 <abadger1999> Do we want to vote on: "can packages ignore %{_libdir} if they don't plan on having multilib."  ?  If that passe, I don't really see anyhting to block the java guideline update.  If it doesn't pass, we can debate the merits of %{_libdir} some more.
16:55:06 <abadger1999> sochotni: we're talking a little more meta right now.
16:55:18 <sochotni> abadger1999: yeah, noticed this is not just Java guidelines now
16:55:20 <sochotni> came a bit late
16:55:21 <rdieter> abadger1999: i'd rather simply vote on the draft as-is, then can consider broader implications...
16:55:26 <sochotni> so I just read scrollback
16:55:42 <tibbs> Pretty sure some folks are going to want to think on that some more.  It's enough of a huge change that it warrants public discussion/flamewars/whatever, I'd think.
16:55:50 <racor> abadger1999: these packages must be noarch packages => %_libdir must point to /usr/lib => these package "may not ignore %libdir", the MUST install to /usr/lib independently of %libdir
16:55:53 <rdieter> esp since the hour is almost up, and i have a hard stop
16:56:11 <abadger1999> rdieter: k... I definitely want to ave the broader question addressed first -- otherwise it isn't fair that we hold some things to the %{_libdir} rule while other things get a pass.
16:56:48 <rdieter> abadger1999: it gets a pass because fesco said it doesn't need to pretend about multilib anymore
16:57:01 <abadger1999> rdieter: not true.  It gets a pass about multilib.
16:57:16 <sochotni> https://fedoraproject.org/wiki/User:Akurtakov/JavaPackagingDraftUpdate#Notes_on_multiarch
16:57:24 <abadger1999> The question of whether multilib is the only reason we enforce libdir is up in the air.
16:57:30 <rdieter> and multilib is the only real reason it ever used %{_libdir}
16:57:41 <rdieter> ok, if you say so
16:57:45 <abadger1999> I'd like that decided so we can enforce that fairly in the guidelines.
16:58:00 <abadger1999> otherwise java gets a pass, but systemd files do not, etc.
16:58:14 <sochotni> unless someone fixes that...we'll have packages that build but will never work
16:58:16 <tibbs> systemd sort of already has its pass, doesn't it?
16:58:32 <tibbs> I mean, it's not using _libdir now and we haven't done anything other than grumble.
16:58:34 <sochotni> and I sure as hell ain't touching that can of worms again
16:58:41 <rdieter> tibbs: not really, the current status is systemd and everyone else pretty much agrees to disagree
16:58:54 <abadger1999> tibbs: I thought we said it's in the wrong place and we won't update the guidelines to allow it?
16:59:10 <abadger1999> tibbs: but hte systemd packagers refuse to change and we just write guidelines, don't enforce.
16:59:27 <tibbs> Which is... pretty much what I've wrote.
16:59:31 <tibbs> Ugh.
16:59:37 <abadger1999> so someone has opened a fesco ticket that I haven't looked at this week...
16:59:38 <geppetto> rdieter: aka. systemd did what they felt like and we are powerless
16:59:59 <rdieter> leave it to the executive branch
17:00:31 <abadger1999> racor: these packages are arch specific.
17:00:45 <abadger1999> racor: they contain JNI files which are compiled per-arch.
17:01:04 <abadger1999> Well, hour is up.
17:01:24 <abadger1999> Shall we discuss this overarching question on the packaging list?
17:01:26 <racor> abadger1999: How so?
17:01:45 <abadger1999> Rathann: Greetings.  Daylight savings catch you?  ;-)
17:01:56 <Rathann> hi abadger1999
17:02:03 <abadger1999> racor: How so what?  The java packages we're talking about are arch specific.
17:02:06 <Rathann> yes, a couple of weeks now
17:02:20 <Rathann> I'm not able to attend at 16:00 UTC
17:02:25 <abadger1999> ah.
17:02:39 <Rathann> as I leave the office then
17:03:19 <racor> abadger1999: I thought the files in question here are arch-independent?
17:03:38 <rdieter> racor: they are not (mostly)
17:03:38 <abadger1999> k.  Maybe we need to see if there's a time that works for everyone again. (although the members haven't changes since last time so this might be the best we can do).
17:03:47 <racor> ... were arch-independent.
17:04:33 <rdieter> (or at least partially)
17:04:42 <geppetto> abadger1999: In previous year's we have changed the time around DST
17:04:48 <sochotni> racor: arch-independent go into /usr/share/java
17:05:11 <racor> sochotni: Yes, this would be an alternative.
17:05:28 <sochotni> you mean placing stuff into /usr/share/java even if it's arch-specific?
17:05:55 <abadger1999> racor: this is the alternative location for arch-specific jars
17:06:01 <abadger1999> ones that contain JNI code
17:06:24 <geppetto> racor: The eclipse problem is roughly: foo.noarch => bar.$arch … where currently bar can be in lib or lib64 … but foo can't say "look in lib or lib64" for whatever weird java reason.
17:06:55 <abadger1999> although at build time, there are tools that make that possible.
17:07:06 <racor> sochotni: No. General rule of thumb: arch-dependent goes underneath of /usr/lib[64], arch independent can go to either /usr/lib or /usr/share.
17:07:21 <sochotni> abadger1999: not really
17:07:32 <sochotni> because some of those tools generate symlinks
17:07:47 <sochotni> and they would again fail during runtime if you symlinked to a jni-jar
17:08:27 <geppetto> racor: right, but imagine you had a bash script but instead of /bin/bash it was either /bin/bash or /bin64/bash depending on arch. … but everything else in the pacakge was truely noarch.
17:08:45 <geppetto> racor: That's the Java/eclipse case atm.
17:08:51 <Rathann> Handling proper requires in RPM is impossible. For example package Z-native.i686 and JDK.x86_64 are installed. As far as RPM is concerned this would be enough to provide Z.noarch with needed "Requires: Z-native", but it would not work during runtime.
17:08:59 <limburgher> Then the whole thing is arched.
17:09:13 <Rathann> this part isn't true
17:09:15 <sochotni> limburgher: we'd make whole java stack arch specific
17:09:35 <limburgher> sochotni:  Or noarch subpackages?
17:10:00 <racor> sochotni: In general, this should always be possible as the last resort
17:10:17 <limburgher> sochotni: If the arch matters, isn't that really what needs to happen?
17:10:27 <rdieter> or just... avoid the whole mess, acknowldget java/multilib isn't worth the pain to even pretend to support.  which is essentially what the draft does here
17:10:57 <racor> rdieter: Pardon?
17:11:14 <sochotni> we've been trying ti simplify packaging, any real fix would make Java packaging hell (more of a hell anyway)
17:11:26 <abadger1999> racor: rdieter is saying that we just use %{_prefix}/lib for arch-specific java libraries.
17:11:55 <rdieter> racor: the draft simplifies matters, so those arch-specific deps essentially don't matter anymore
17:11:58 <sochotni> Rathann: about that part you quoted...care to enlighten how you'd solve it?
17:12:14 <sochotni> i.e. you have a noarch package which requires arch-specific package
17:12:19 <racor> abadger1999: hardest imaginable -1 to the idea from me.
17:12:25 <sochotni> but *that* depends on JVM being run *not* the host arch
17:13:17 <abadger1999> racor: well -- that's what's in the current java draft.  so there'll be plenty of opportunity to vote against it in the next few meetings :-/
17:14:10 <sochotni> I'll reiterate: this doesn't actually change anything
17:14:16 <sochotni> we *never* had multiarch in Java
17:14:24 * rdieter has to go, consider me pragmattically in support of java-sig's draft, and in giving java essentially a free-pass exception to use /usr/lib for arch-specific stuff
17:14:30 <sochotni> up until F15 we installed everything in /usr/lib/java
17:14:37 <sochotni> then I *tried* to make it multiarch
17:15:05 <sochotni> if you want to see several Java guys *really trying* to solve it: https://bugzilla.redhat.com/show_bug.cgi?id=665576
17:15:08 <sochotni> and we failed
17:15:12 <sochotni> in ugly ways
17:15:18 <sochotni> which were not apparent right away
17:15:27 * abadger1999 proposes we take: "should packages be able to ignore %{_libdir} if they don't plan on having multilib." to the packaging list and then revist that and approving java update next week.
17:15:32 <Rathann> sochotni: hm, I thought the 32bit packages had distinct provides but it seems they don't, only 64bit ones do have Provides: name(x86-64)
17:15:40 <Rathann> so forget it
17:15:46 <limburgher> abadger1999: +1
17:16:03 <abadger1999> #topic open floor
17:16:15 <abadger1999> Anyone have anything they want to bring up?
17:16:36 <Rathann> nothing from me
17:16:38 <racor> sochotni: <sigh/> the same situation as with perl, it's a mess.
17:17:30 <limburgher> Not here.
17:17:38 * abadger1999 will close in 60s
17:18:59 <abadger1999> #endmeeting