16:00:27 <spot> #startmeeting Fedora Packaging Committee
16:00:27 <zodbot> Meeting started Thu May 16 16:00:27 2013 UTC.  The chair is spot. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:00:27 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:00:31 <spot> #meetingname fpc
16:00:31 <zodbot> The meeting name has been set to 'fpc'
16:01:12 <spot> #chair abadger1999
16:01:12 <zodbot> Current chairs: abadger1999 spot
16:01:18 <spot> just in case.
16:01:24 <abadger1999> <nod>
16:01:25 <spot> #topic Roll Call
16:02:10 <tibbs|w> Actually here this week.
16:02:27 <RemiFedora> here
16:02:50 * racor is here
16:03:35 * spot is here (and supposed to be dialed into another call that hasn't started yet, so i will be multi-tasking)
16:05:03 <spot> i know abadger1999 is here, and limburgher said he was going to be late.
16:05:10 <abadger1999> <nod>
16:05:24 <abadger1999> So we're at five for now
16:05:37 <spot> Smoother1rOgZ: ping
16:06:07 <spot> alrighty then, lets get started
16:06:24 <spot> #topic Bundling exception for agg in mapnik - https://fedorahosted.org/fpc/ticket/279
16:07:16 <tibbs|w> Would be nice if limb were around for this one.
16:07:23 <tibbs|w> Since he is the agg maintainer....
16:07:38 <spot> tibbs|w: good point, lets skip it for now
16:07:53 <spot> #topic Permissions on Files and Directories - https://fedorahosted.org/fpc/ticket/286
16:08:36 <geppetto> gah, sorry I'm late
16:09:01 <tibbs|w> I don't disagree, but I'm not sure about the setuid stuff.
16:09:47 <tibbs|w> It seems very specific for something we were supposed to be trying to remove entirely.  Or at least I thought that was the goal at one point.
16:12:42 <tibbs|w> Did I lag out?
16:12:46 <spot> nope
16:13:20 * abadger1999 tends to agree with tibbs|w
16:13:39 * abadger1999 trying to figure out if there's a way to reconcile those in his mind
16:13:46 <spot> perhaps we should consider the first two sections independently?
16:13:53 <tibbs|w> +1
16:13:59 * limburgher is here now.
16:14:35 * Rathann here
16:14:37 <Rathann> sorry
16:15:23 <spot> do we have any actual guidelines around setuid/setgid?
16:15:46 <geppetto> The 2nd paragraph looks fine, to me.
16:16:08 <geppetto> spot: Don't do it :)
16:16:31 <limburgher> geppetto:  +Eleventy
16:16:59 <tibbs|w> By the way, I'm assuming that this would replace what's currently at http://fedoraproject.org/wiki/Packaging:Guidelines#File_Permissions
16:17:16 <limburgher> I think so.
16:17:41 <limburgher> Dunno, first para leaves no room for exceptions, and there are valid cases.
16:17:59 <abadger1999> <nod>
16:18:00 <tibbs|w> Like /tmp
16:18:17 <limburgher> et. al. idinfinitum
16:18:23 <geppetto> Yeh, it certainly needs to be lead with a "this is the defaults, you can deviate"
16:18:25 <abadger1999> Potential rewording: "In the majority of situations, files should be owned by root:root, writable only by [...]"
16:18:26 <limburgher> which is like ad infinitum
16:18:30 <RemiFedora> it's only a "should", so exception are possible
16:18:44 <geppetto> Eg. I assume a lot of packages want different owners than just root:root.
16:18:47 <tibbs|w> Of course; vague guidelines make great sense until people disagree about what is permissible.  This seems to be a case of that.
16:18:53 <limburgher> Yeah.
16:19:07 <geppetto> yeh, which is why I thought we'd generally not bothered with stuff like this.
16:19:19 <tibbs|w> That's exactly the case.
16:19:32 <tibbs|w> But some people want everything dictated and all cases considered.
16:19:56 <geppetto> I'm happy to -1, ETOOGENERAL
16:19:56 * spot is not a fan of "do this, except when you don't" except when we can very clearly nail down "when you don't"
16:20:07 <tibbs|w> I have to agree.
16:20:08 <spot> rpm provides sane defaults
16:20:08 <limburgher> spot: Bingo
16:20:21 <spot> i dont see why we need to reiterate them
16:20:33 <tibbs|w> But then we're back at the original case, of people making systemd files executable.
16:20:38 <limburgher> Plus, rpm trumps the FPG. ;)
16:20:47 <racor> The last paragraph "no point in making unreadable" seems wrong.
16:20:48 <tibbs|w> Or at least I think that discussion spawned this ticket.
16:21:10 <limburgher> Which, while a silly thing to do, I've not seen a spelled out case of resulting harm.
16:21:29 <geppetto> Yeh, I was really worried about the unreadable bit with regards to prelinking.
16:21:33 <racor> "-r"'ing e.g. disables running "strings"
16:21:53 <geppetto> Or other things like that, where you might be able to gain extra knowledge by reading the binary.
16:21:57 <tibbs|w> OK, so is there anything in here we want?
16:22:13 <tibbs|w> Is there anything we can do to the existing "File Permissions" guideline which would tighten things up?
16:22:29 <geppetto> Well I'm 100% -1 on the 2nd two until someone from the security team looks at it.
16:22:31 <tibbs|w> Like "things shouldn't be executable unless they are actually executables" or somesuch?
16:22:41 <tibbs|w> geppetto: +1.
16:22:52 <tibbs|w> I'm not even sure of those old debian rules reflect current reality.
16:23:00 <limburgher> geppetto:  With you there.
16:23:07 <geppetto> The 2nd paragraph seems like it's fine as a "default" … the 1st, meh. … but I'm more than happy to just NAK the entire thing.
16:24:12 <abadger1999> Hmm... does prelink operate independently of people being able to read an executable?  /me isn't very knowledgable on how prelink achieves its security benefits.
16:24:27 <geppetto> abadger1999: I thought prelink ran as root.
16:24:30 <tibbs|w> There are security benefits?
16:24:37 <geppetto> abadger1999: As it needs to rewrite the binaries.
16:24:56 <abadger1999> geppetto: I mean, once prelink has rewritten the binaries, is there any benefit to user's not being able to read those rewritten binaries?
16:25:28 <abadger1999> tibbs|w: I thought that prelink had some sort of static address randomization
16:25:29 <Rathann> racor: on a live system, yes, but one can download the same package from koji, unpack it and run strings on unpacked file
16:25:32 <geppetto> I _think_ that if you can read the binary you can tell which parts of memory bits of the exec. will be loaded into … which makes lots of attacks easier to do.
16:25:44 <Rathann> so there's really no benefit to making things unreadable by default
16:25:49 <tibbs|w> I think we could probably save a lot of time by agreeing that the last two paragraphs at minimum need review by the security folks.
16:26:19 <geppetto> yeh, or just all give the entire thing -1 and go do a more productive ticket :)
16:26:55 <Rathann> geppetto: +1 to that, I don't think we'll be able to cover all cases anyway
16:27:03 <limburgher> Agreed.
16:27:36 <tibbs|w> Let me see if I can come up with any ideas for clarifying what we already have in a way that would have prevented the original problem.
16:27:37 <racor> rathann: Yes, but you can always obtain copies of ro-files from alternative sources (but the live system) for "deep" inspection.
16:27:50 <abadger1999> I think this is something we could vote on if we chose: http://www.fpaste.org/12578/36872162/
16:28:23 * abadger1999 is also ambivalent as to whether we really need something like this.
16:28:46 <tibbs|w> If you s/if appropriate/only if appropriate/ then you should solve the original discussion.
16:28:49 <geppetto> Yeh, I'm much happier with abadger1999's wording … and would give it +1
16:28:59 <limburgher> abadger1999:  If we do need this, I like yours.  But, you're right, do we?
16:29:00 <geppetto> If we need to put something like this somewhere.
16:29:15 <racor> rathann: a case, where this makes a difference, is live-system specific files (e.g. ro-config files).
16:29:18 <Rathann> +1 with tibbs' fix for what it's worth
16:29:32 <geppetto> Although I doubt this wording word stop the original "problem" the systemd devs complained about.
16:29:42 <Rathann> racor: right, I was thinking about binaries
16:29:43 <abadger1999> tibbs|w: : <nod>Makes sense
16:29:43 <tibbs|w> Generally if people have a real disagreement about a guideline, it shows us some place that we should at least consider tightening up.
16:29:45 <geppetto> But I'm fine with that too
16:30:13 <limburgher> geppetto: Is there a link to their original complaint?  I really don't understand the big deal, and want to if it's truly legit.
16:30:37 <tibbs|w> It was in the ticket we voted down a while back.
16:30:40 * spot is fine with abadger1999's proposal, fwiw.
16:31:00 <spot> It seems a bit like "don't eat broken glass" to me, but eh.
16:31:01 <geppetto> Was a previous ticket … basically seemed to be "I want to ban people from making systemd.unit file +x … with no reasoning other than "I don't like it"
16:31:02 <racor> rathann: I was also considering self-modifying/system-modified binaries (prelink?), data-bases, caches etc.
16:31:02 <RemiFedora> should we say "files in /usr" as config and data files are really different (from perm pov)
16:31:52 <limburgher> geppetto:  Ok, that's all I can find, at least in 283.  Wanted to make sure I wasn't missing something reasonable.
16:32:13 <limburgher> spot:  Except that's actively harmful.  +x on a unit file is just. . .sloppy.
16:32:23 <geppetto> abadger1999: So … do you want us to vote on your wording?
16:33:45 <abadger1999> RemiFedora: How aout this: "In the majority of situations, non-config and non-state should be owned by root:root [..]"
16:34:00 * abadger1999 just trying to incorporate the feedback here then we could vote.
16:34:23 <RemiFedora> abadger1999, yes
16:34:54 <Rathann> racor: do you have any specific cases where this actually matters (for binaries)?
16:34:58 <abadger1999> Okay, Proposal to vote on: http://www.fpaste.org/12580/13687220/
16:35:24 <limburgher> +1
16:35:40 <spot> +1
16:35:43 <abadger1999> +1
16:35:43 <tibbs|w> +1
16:35:45 <Rathann> If _a_ directory needs...
16:35:49 <Rathann> +1
16:35:55 <RemiFedora> +1
16:35:58 * spot is fine with Rathann's grammar fix
16:36:05 <limburgher> Totes.
16:36:08 <abadger1999> Rathann: <nod>  /me will change that in the writeup
16:36:30 <spot> racor: you're the only missing vote here.
16:36:44 <abadger1999> and geppetto
16:36:59 <spot> abadger1999: thanks, i miscounted. :)
16:37:21 <geppetto> +1
16:37:38 * Smoother1rOgZ is here (sorry, i'm late)
16:37:58 <racor> +1, sorry, distracted.
16:38:06 <spot> #action abadger1999's simplified draft (http://www.fpaste.org/12580/13687220/) approved (+1:8, 0:0, -1:0)
16:38:29 <spot> lets go back to 279
16:38:29 <abadger1999> Do we want to do the followup (ask security people about readable) or have mether do that?
16:38:43 <spot> abadger1999: it would be nice if we could do that
16:38:47 <tibbs|w> How do we ask the security people about anything?
16:39:07 <spot> abadger1999: you can probably get a good response from josh bressers or mark cox
16:39:18 <abadger1999> spot: Roger that.  I'll send them an email.
16:39:49 <spot> #topic Bundling exception for agg in mapnik - https://fedorahosted.org/fpc/ticket/279
16:39:51 <tibbs|w> By the way, http://fedoraproject.org/wiki/Features/RemoveSETUID
16:40:16 * limburgher puts on agg maintainer hat
16:40:29 <limburgher> What do I need to do to make the most software work?
16:40:57 <limburgher> Simple question, I know. :)
16:41:37 <tibbs|w> I think you're in the better position to answer that.
16:42:24 <spot> since agg upstream is dead, you'd become a defacto fork if you carried the mapnik patches
16:42:24 <tibbs|w> Seems to me if there's a maintained fork, it would be best to use it, but that depends on whether anything actually needs 2.5.
16:43:21 <tibbs|w> desume, gnash, mapnik, python-gnash, python3?-matplotlib
16:43:30 <Rathann> limburgher: have you talked to the maintainers of other agg consumers?
16:43:33 <limburgher> I think what I'll do then is take the mapnik patches and see if they break any of ^^^
16:44:06 <limburgher> Rathann:  I have not.  I think I will if ^^^ indicates a conflict.  It may not.
16:46:04 <spot> limburgher: okay then, we'll leave this open for the time being.
16:46:17 <tibbs|w> Is the agg repository on sourceforge the fork?
16:47:29 <spot> #topic Bundling exception request for sigrok-firmware-fx2lafw - https://fedorahosted.org/fpc/ticket/287
16:47:40 * spot is finally off his other call, should be a little more awake. :)
16:48:51 <tibbs|w> This kind of thing seems pretty much OK to me.
16:49:03 <spot> Worth remembering that fx2lafw is not in fedora right now, so I'm completely fine with this.
16:49:29 <tibbs|w> Even if it were, I'm not sure there would be much point.
16:49:52 <Smoother1rOgZ> indeed
16:50:07 <Smoother1rOgZ> +1 from me
16:50:09 <geppetto> I don't see why they can't just package it as a library
16:50:18 <geppetto> Their bundled version, that is.
16:50:36 * spot wouldn't mind if they split the static lib out into an fx2lafw subpackage.
16:50:52 <abadger1999> <nod>
16:50:55 <tibbs|w> Personally I think this is off in the same weird exception-land where other firmware lives.
16:50:56 <spot> but since it is a static lib, i don't think they _have_ to.
16:51:28 <geppetto> spot: I just figure that this way if anything else ever decides it needs it we'll find out
16:51:44 <spot> geppetto: yes, but if they do and someone wants a newer version... we're right back here again.
16:51:48 <geppetto> Whereas if they don't package it out, someone would have to remember.
16:52:02 <geppetto> spot: Yeh, but that's what we want, right?
16:52:17 <geppetto> If upstream comes back alive, we don't want N bundled copies.
16:52:47 <spot> geppetto: except for the whole "firmware depends on this specific version's behavior"
16:53:18 <Rathann> let me get this straight, the fx2lib code's target is 8051, it doesn't run on anything else, right?
16:53:26 <tibbs|w> "We want a local fx2lib copy in fx2lafw for various reasons, e.g. to make life simpler for all distros (none of which ship any fx2lib packages, and neither would it make sense to do so really), and as we'll want/need local changes to fix build issues and possibly other stuff anyway."
16:53:27 <spot> Rathann: i believe that is correct.
16:53:44 <tibbs|w> I guess I can't help but be curious as to why it wouldn't make sense.
16:54:08 <tibbs|w> I think this is one of those things that is supposed to be obvious but isn't to me.
16:54:15 <abadger1999> "Library routines for creating firmware for the Cypress FX2 (CY7C68013 and variants) with SDCC"
16:54:23 <Rathann> looks like the correct solution is to package it as a separate package
16:54:54 <spot> tibbs|w: probably because nothing besides firmware on a linux distro could really ever use it.
16:55:31 <geppetto> Meh. … I'm willing to just give it +1, I guess.
16:55:42 * spot is +1 for an exception here.
16:55:54 <racor> IMO, sdcc hardly is a reason for bundling binaries.
16:56:08 <spot> the library doesn't work within linux (unless you're running linux on an sdcc compatible target)
16:56:38 <limburgher> Sigh.  +1 I suppose.
16:56:48 <abadger1999> A brief look at the documentation seem to say that the routines compiled into the library are just run on the target, not on the host CPU.
16:56:59 <abadger1999> so yeah, seems to fall under firmware to me.
16:57:01 <tibbs|w> I'm kind of leaning towards pretending this is some sort of content.
16:57:01 <abadger1999> +1
16:57:03 <racor> spot: fx2lib seems GPLed - Do they ship the sources?
16:57:58 <spot> racor: i at least see them in their git repo.
16:58:52 <spot> so i think the answer is yes
16:59:28 <tibbs|w> I can't come up with any real reason not to +1 this.  So +1, I guess.
16:59:38 <tibbs|w> Was kind of hoping to see a counter-argument.
16:59:41 <spot> we're at +4 on granting an exception here.
16:59:43 <Rathann> these are still sources which are built into a binary
17:00:00 <Rathann> I don't see a good reason to bundle, to be honest
17:00:06 <Rathann> convenience is not a good reason
17:00:08 <spot> Rathann: i think it is fine to require that the fx2lib code be built with sdcc
17:00:09 <racor> -1, SDCC is not hard to build. Lack of a tool is not a sufficient reason to allow bundling binaries.
17:00:20 <Rathann> -1 from me
17:01:00 <spot> sdcc is already in fedora, i think
17:01:05 * abadger1999 notes that it's bundling source, not binaries.
17:01:24 <Rathann> spot: it is
17:01:40 <Rathann> but looks like FTBFS since F18
17:01:48 <spot> so this is all moot, they're just wanting to not have to split out their older version of fx2lib.
17:02:54 <abadger1999> Hmm... I think we're actually at +5, -2.
17:03:09 <spot> abadger1999: you're right.
17:03:21 <spot> who are we missing here?
17:03:27 <RemiFedora> +1
17:04:31 <spot> #action Exception granted (+1:6, 0:0, -1:2)
17:05:08 <spot> I know we're at the hour mark (actually a bit past it)
17:05:16 <spot> but I think these last two are faster items
17:05:20 <tibbs|w> I'm not going anywhere.
17:05:23 <spot> so i'm going to skip to them
17:05:45 <spot> #topic Octave Provides Filtering - https://fedorahosted.org/fpc/ticket/290
17:06:11 <spot> This is a one line add to the Octave guidelines. Ideally, rpm would ignore these automatically, but it doesn't now.
17:06:41 <tibbs|w> I do like Panu's solution.
17:06:50 <Rathann> can anything require those to work? some kind of octave plugin perhaps?
17:06:53 <spot> I propose we add it to the https://fedoraproject.org/wiki/Packaging:Octave and ask panu to tell us when it isn't needed.
17:07:06 <limburgher> Seconded.
17:07:09 <tibbs|w> +1
17:07:13 <spot> Rathann: orion is the one who filed this ticket and he would know.
17:07:22 <abadger1999> spot: +1
17:07:23 <Smoother1rOgZ> +1
17:07:27 <Rathann> ok
17:07:27 <spot> +1
17:07:29 <tibbs|w> It doesn't hurt, and we can take it back out.  Though with luck it wouldn't take too long.
17:07:31 <Rathann> +1 then
17:07:37 <RemiFedora> +1
17:07:38 <limburgher> +1
17:07:38 <geppetto> +1
17:08:01 <spot> i think the only vote missing here is racor.
17:09:20 <spot> #action Draft Approved (+1:8, 0:0, -1:0)
17:09:38 <spot> #topic copylib: mt19937ar.c - https://fedorahosted.org/fpc/ticket/291
17:09:48 <geppetto> +1
17:09:50 <spot> FWIW, this code is almost md5 bad.
17:09:53 <spot> +1 to exception for it
17:09:55 <tibbs|w> This is all over the place.
17:10:02 <tibbs|w> +1
17:10:20 <geppetto> yeh, it'd be nice if someone volunteered to put these in a nice library … but, meh.
17:10:23 <Smoother1rOgZ> +1
17:10:26 <limburgher> +1
17:10:44 <Rathann> if that's the case then maybe we should add it to the general copylib exceptions list so that further exception requests are not needed
17:10:45 <abadger1999> Are we dealing with multiple implementations of it or just that one "source"?
17:11:12 <geppetto> AIUI everyone copy and pastes the exact same code.
17:11:15 <spot> abadger1999: i've seen a few places where people have added helper functions around it (libdb), but its all based on the same source.
17:11:23 <abadger1999> Cool.
17:11:37 <racor> spot: +1, +1
17:11:50 <RemiFedora> +1
17:12:23 <abadger1999> Yeah, +1 to a copylib exception -- similar to the exception for md5
17:13:14 <spot> #action Exception approved as a copylib (+1:8 0:0 -1:0)
17:13:54 <spot> #topic Request for permission for usage of autogenerated sources - https://fedorahosted.org/fpc/ticket/289
17:14:15 <tibbs|w> This one is much tougher.
17:14:39 <tibbs|w> But one interesting thing is that this only applies to EPEL.
17:14:54 <spot> Yeah, i think Fedora 18+ should do it the "long way".
17:14:59 * abadger1999 notes that the Yeah.... I'd definitely be against it in Fedora.
17:15:05 * RemiFedora agreed
17:15:20 <tibbs|w> I think all current Fedora could do it properly.
17:15:35 <limburgher> spot:  heck yes.
17:15:59 <spot> I'm inclined to give a case-specific exception for EPEL branches without a modern enough compiler to use the "generated source" tarball provided by upstream.
17:16:14 <abadger1999> I would lean towards saying, if can't be done the long way in EPEL then it's not appropriate in epel but I'm not gong to argue for that... just vote that way.
17:16:18 <tibbs|w> But EPEL, I'm not sure if things get a pass or if someone should just get an updated gcc package branched and reviewed, or what.
17:16:51 <limburgher> tibbs|w: Took the words out of my mouth.  Why not a gcc47 for those platforms?
17:17:13 <rdieter> rhel6 does have some sort of devtoolset-1.1-gcc
17:17:20 <rdieter> fwiw, iirc, yada yada
17:17:26 <spot> there is actually a developer toolkit addon for RHEL 5/6
17:17:30 <spot> that has gcc 4.7
17:17:56 <tibbs|w> I pretty much know nothing of RHEL.
17:17:56 <RemiFedora> is DTS packages available at buildtime ?
17:18:23 <spot> nirik: do you know if EPEL has the developer toolset addon? I don't think it does.
17:18:38 <nirik> nope. if it's another channel, it wouldn't.
17:18:46 <spot> i suppose we _could_ add it
17:18:47 <tibbs|w> I think I'd also like to see some input from the EPEL folks about this kind of thing.
17:19:04 <limburgher> I imagine some might like it for other reasons.
17:19:13 <spot> i'd have to ask Red Hat if they were okay with it, but I can't imagine why they wouldn't be
17:19:38 <nirik> it's server, server-optional, lb and ha
17:19:43 <nirik> (those 4 channels only)
17:20:06 * abadger1999 notes that "which channels should the epel buildroot include" is a point of contention at times.
17:20:19 <geppetto> spot: So as a comparison … if some newer python was needed for a /usr/bin package, you wouldn't allow shipping a binary in EPEL-6 right?
17:20:38 <spot> geppetto: not quite equivalent, but yeah, i wouldn't.
17:21:02 <geppetto> I'm not sure how it's that different … the generated sources are almost guaranteed to be unhumanly readable.
17:21:21 <abadger1999> geppetto: definitely correct on that... we have precedent of (1) getting a newer python interpreter in and (2) of porting to older versions.
17:21:24 <spot> i guess the main concern with adding DTS is that some RHEL consumers may not have it
17:21:36 <nirik> also, some channels have conflicting or differing versions of packages. I don't know if the DTS is one of those, but it could be.
17:21:50 <RemiFedora> spot, not if it only used ay buildtime
17:21:54 <spot> but it is a free child channel to RHEL
17:22:06 <tibbs|w> It sounds like there is more to consider here regardless.
17:22:08 <spot> RemiFedora: should be true for gcc, but maybe not for the other parts.
17:22:09 <limburgher> Will CentOS/SL users have it or access to it?
17:22:13 <geppetto> abadger1999: Yeh, and it seems like at worst we could have a special EPEL-build repo. and have a very recent g++ in it.
17:22:33 <rdieter> limburgher: centos has a separate repo, http://people.centos.org/tru/devtools-1.1/
17:22:56 <rdieter> (at least that's the one I found when I went looking)
17:23:30 <tibbs|w> This all gets deep in to EPEL policy which I think we should try to stay out of.
17:23:43 <limburgher> But if a n00b installed CO5.9, and this new thing was in EPEL, and they installed the EL-5 EPEL repo, and yum install <thisthing>, it would fail unless they added the devtools repo, right?
17:23:50 * spot is fine asking EPEL how they want to handle this
17:24:05 <spot> limburgher: i don't think it would cause a linking issue.
17:24:19 <geppetto> limburgher: No, AIUI, it's just building that needs it … to use the library you are fine.
17:24:20 <spot> but if there were a dep issue, yes.
17:24:40 * abadger1999 is willing to let EPEL handle the epel side if they wish as well.
17:25:26 <limburgher> It's certainly and EPEL issue, but the whole point of this is that you have the tools to rebuild your tools.
17:25:46 <spot> limburgher: centos and RHEL users will have them
17:26:02 <spot> (and the srpms for the devtoolset stuff are out there)
17:26:21 <limburgher> spot:  Then I'm less worried, if EPEL is OK with this.
17:27:07 <spot> Proposal: Open an EPEL ticket recommending that they consider adding the DTS to the buildroot package set to allow for packages that need newer compilers to build properly.
17:27:23 <racor> Sorry folks, I've got to quit, soon.
17:27:29 <limburgher> spot:  If we block this on that, +1.
17:27:30 * RemiFedora also
17:27:34 <geppetto> spot: +1
17:27:47 <abadger1999> Hmm.... We're also fine if they say that it's okay to build with the pre-generated sources?
17:28:00 <abadger1999> ie: they can come up with whateve soution they like?
17:28:12 * abadger1999 is fine with that for the record.
17:28:12 <spot> maybe it should be "Pass this to EPEL to resolve for EPEL." :)
17:28:15 <limburgher> abadger1999:  I thought all this was so that they could do it the long way.
17:28:16 <racor> +1 on bundling pregenerated sources in this case, because there are many precedences elsewhere (e.g. yacc, bison, lex/flex etc.)
17:28:16 <tibbs|w> I think we can ask them what they think, and then vote after we know that.
17:28:18 <spot> which we don't need to really vote on.
17:28:34 <abadger1999> <nod>
17:28:36 <spot> tibbs|w: i like that, lets just ask EPEL.
17:28:38 <Smoother1rOgZ> tibbs|w: agreed
17:28:52 <geppetto> sounds good
17:28:54 <Rathann> agreed as well
17:28:55 <spot> Okay, one more ticket for today
17:28:57 <abadger1999> +1 to let EPEL resolve the EPEL portion and -1 to going with pregenerated sources in Fedora
17:29:00 <spot> and we'll all run away
17:29:08 <tibbs|w> Though flex/yacc stuff is an interesting precedent.
17:29:14 <spot> #topic glassfish-jaxb-api and OpenJDK - https://fedorahosted.org/fpc/ticket/292
17:29:24 <Rathann> that one
17:29:41 <tibbs|w> I didn't even get as far as figuring out what glassfish was.
17:29:52 <Rathann> I think both should unbundle JAXP/JAX-WS
17:29:55 <spot> Summary: JAXP and JAX-WS are maintained by glassfish (Oracle). OpenJDK (Oracle) pulls these code bases into OpenJDK regularly.
17:30:07 <spot> The JDK depends on them being there.
17:30:18 <spot> glassfish ships them as part of their API
17:30:26 <spot> the whole thing is a headache.
17:30:31 <Smoother1rOgZ> wow
17:30:37 <tibbs|w> Where "whole thing" means Java?
17:30:42 <spot> tibbs|w: yes.
17:30:52 <spot> or "Oracle", take your pick.
17:31:02 <geppetto> my gut reaction is -1, get everyone to do better rel-eng or don't update in fedora.
17:31:35 <spot> Oracle has stated openly that they are aware of this behavior occasionally causing inconsistency between what glassfish uses (newer) and what openjdk uses (sometimes older)
17:31:36 <limburgher> So. . .we want to grant an exception because Oracle . . . (takes deep breath). . .oy.
17:31:46 <spot> but they will not do anything about it.
17:31:48 <limburgher> spot:  And they intend to do what to fix it?
17:32:01 <tibbs|w> Squat, I gather.
17:32:03 <spot> "There are many reasons for this current mechanism, and it is understood that this is not ideal for the open source community."
17:32:09 <spot> The reasons are not given.
17:32:28 <spot> Honestly, this whole thing makes me facepalm, but I don't want to look too hard at trying to untangle the JDK
17:32:28 <Rathann> "It is possible this process could change in the future."
17:32:37 <spot> thats some black magic evil right there
17:32:46 <tibbs|w> How often does this out of sync issue happen?
17:32:56 <Smoother1rOgZ> Rathann: I don't think regarding what they said.
17:32:58 <geppetto> And, more importantly, for how long?
17:33:02 <spot> hard to say. current state is pretty close.
17:33:04 <tibbs|w> And how long does it generally stay out of sync?
17:33:10 <tibbs|w> Ninja'd, ugh.
17:33:14 <spot> but pretty close != identical
17:33:47 <spot> glassfish doesn't want to have to rely on the openjdk bits because they're the upstream and they need to make fixes as they see fit
17:34:05 <spot> openjdk doesn't want to rely on glassfish because they assume the only behavior is in the build they code dropped.
17:34:10 <abadger1999> Our maintainers wouldn't pull the newer version of hte library in?
17:34:24 <limburgher> (takes another slow deep breath)
17:34:40 <spot> abadger1999: its embedded in the jdk and would possibly need us to patch the jdk, which would change the jdk behavior and api
17:34:51 <spot> the whole java stack teeters.
17:34:56 <geppetto> I'm still pretty much … -1, someone needs to get a clue and I don't really care who.
17:34:57 <abadger1999> <nod> but in a compatible or incompatible way?
17:35:04 <spot> i'm going to say incompatible.
17:35:10 <limburgher> abadger1999: Or only release synced releases?  Which would probably but one or both out of sync with security fixes.
17:35:20 <tibbs|w> So, I guess this is the usual question: JAXP/JAX-WS has an intependent upstream.  Sometimes glassfish and openjdk want different versions of JAXP/JAX-WS.  Why not package up different versions?
17:35:29 <spot> tibbs|w: glassfish is the upstream
17:35:49 <tibbs|w> I guess I got confused.
17:35:53 <Rathann> sigh
17:36:05 <tibbs|w> Because this hurts my brain: The repositories jaxp and jaxws actually do not contain the sources for JAXP or JAX-WS.
17:36:05 <spot> the glassfish-jaxb-api package has the newer revision
17:36:13 <spot> openjdk has the older revision
17:36:23 <abadger1999> So.... since glassfish is the upstream, I could see allowing bundling on similar grounds to what we approved for samba as a project and parts of the gnu toolchain as a project.
17:36:29 <spot> they go into different (compatible jars)
17:36:47 <spot> abadger1999: my thinking as well
17:36:57 <tibbs|w> By the way, how much code are we talking about here?
17:36:59 <abadger1999> otoh, I can't really see a reason that openjdk should get a pass if they're relying on a separate upstream to maintain that portion of their api.
17:37:05 <spot> tibbs|w: it is not a lot.
17:37:19 <abadger1999> which is more problematic since openjdk is more essential than glassfish.
17:37:29 <spot> abadger1999: remember, this is Oracle. I think this is two teams at the same company.
17:37:58 <spot> glassfish moves slightly faster than openjdk does.
17:38:04 <spot> (which isn't shocking)
17:38:42 <spot> this code isn't going into shared libraries, the api namespace for class naming is unique between the two, so there isn't collisions
17:39:12 <tibbs|w> Is there any point in doing a temporary exception and revisiting?  Or is that like waiting for a glacier to move a few miles?
17:39:18 <spot> tibbs|w: i think the latter.
17:39:21 <abadger1999> ah.  so if the api is separate...
17:39:38 <abadger1999> I don't think we even need an exception for glassfish...
17:39:42 <spot> abadger1999: yes, sun changes the class naming to be part of the org.sun jdk namespace.
17:39:55 <limburgher> Waiting for Oracle to do the right thing is sort of like . . . I have no sufficient metaphor.
17:40:07 <geppetto> Yeh, I kind of feel the opposite of abadger1999 … openJDK is basically a giant dump of code as a single unit, so it can include what it wants … glassfish has to work around that and not bundle random newer versions
17:40:07 * abadger1999 still sighs over the jdk portion of this mess
17:40:14 <spot> abadger1999: yeah, technically, the jdk needs the exception.
17:40:40 * spot just wants to except this whole nightmare as "java idiocy" and move on.
17:40:45 <geppetto> The fact they are the "upstream" for parts of it doesn't seem that relevant.
17:41:08 <tibbs|w> spot: I agree, but due diligence and everything....
17:41:13 <spot> geppetto: well, in as much as the same entity is making sure that things don't break.
17:41:30 * limburgher snickers
17:41:32 <spot> next time openjdk has a minor release, it will pull in the matching code.
17:41:37 <abadger1999> My feeling on relevancy of upstream is -- issue is discovered... where does fixing of the issue start?  What is the quickest path to getting that fix to everyone concerned?
17:41:47 <spot> and they'll be in sync until glassfish releases again.
17:41:51 <abadger1999> \To me, that starts with teh upstream which is glassfish.
17:42:18 <geppetto> spot: Yeh, I just meant that "glassfish" can't really say they are the upstream for JAXP so they can bundle it … it would be like random package bundling a newer glibc because the upstream was also an upstream of glibc.
17:42:42 <Rathann> ok, so no exception necessary for glassfish and file a bug against openjdk to ask for a bundling exception?
17:42:46 <spot> geppetto: well, as abadger1999 pointed out, we've granted bounded exclusions in that case for samba and gnu
17:42:52 <spot> err... gcc
17:43:54 * geppetto nods
17:44:17 <tibbs|w> Also, what does openjdk do when things are in sync?  Does it still bundle, or does it make use of the other package when possible?
17:44:34 <spot> i'd be inclined to support an exception for openjdk to bundle an older version of JAXP and JAXWS.
17:44:42 <spot> tibbs|w: no, it bundles, because they change the namespace
17:44:52 <tibbs|w> Oh, I see.
17:44:57 <spot> the JDK API says that JAXP and JAX-WS are part of the JDK
17:45:21 <tibbs|w> Didn't we recently address the issue of some java application needing to use the sources of another but changing the namespace?
17:45:42 <spot> tibbs|w: yes, but this is trickier, because the JDK API says that these bits are in this namespace.
17:45:53 <spot> we can't just point it to the glassfish namespace.
17:46:09 <spot> because all sorts of other things will just break.
17:46:55 <tibbs|w> Right, I just thought there was some automated way to change the namespace which would enable code sharing if the two code bases happen to be in sync.
17:47:05 <spot> Proposal: Grant a bundling exception to OpenJDK to bundle JAXP and JAX-WS.
17:47:15 <spot> tibbs|w: for anything higher in the stack than the JDK, maybe.
17:47:35 <geppetto> +1
17:47:39 <spot> +1
17:47:59 <tibbs|w> Doesn't seem to be any reasonable way around this.  +1, but I guess we could revisit in a few releases.
17:48:33 <tibbs|w> I'm guessing the jdk folks like this about as much as we do, and would probably prefer not to do this.
17:48:42 <RemiFedora> +1  (and so avoid wasting our time on fixing Oracle stuff)
17:48:43 <limburgher> +1 because E_ORACLE
17:48:43 <spot> tibbs|w: you guess correctly.
17:48:58 <spot> okay, i see +5 here.
17:48:59 <Smoother1rOgZ> +1
17:49:00 <abadger1999> +1
17:49:27 <spot> #action Exception for openjdk to bundle JAXP and JAX-WS is granted (glassfish does not need one) (+1:7, 0:0, -1:0)
17:49:46 <spot> we're _way_ over time
17:49:51 <spot> but thanks to everyone for sticking around
17:49:57 <limburgher> And I have a hard stop in 10
17:50:04 <limburgher> We got a lot done at least.
17:50:04 <spot> so i'm going to end it here.
17:50:10 <spot> thanks all
17:50:12 <spot> #endmeeting