14:59:45 <spot> #startmeeting Fedora Packaging Committee
14:59:45 <zodbot> Meeting started Wed Jul 27 14:59:45 2011 UTC.  The chair is spot. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:59:45 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
14:59:48 <spot> #meetingname fpc
14:59:48 <zodbot> The meeting name has been set to 'fpc'
14:59:53 <spot> #topic Roll Call
15:00:03 <Rathann> I'm here
15:00:09 <tibbs|h> Howdy.
15:00:13 <Rathann> although my connection is flaky and I may drop out
15:01:07 * spot is here
15:01:12 <spot> (obviously)
15:01:57 <spot> FPC ping: abadger1999, limburgher, rdieter, SmootherFrOgZ
15:02:24 <limburgher> Oh captain, my captain!
15:02:34 * abadger1999 here
15:02:55 <spot> abadger1999: is the board meeting still conflicting?
15:03:47 <abadger1999> spot: not at the moment
15:04:08 <spot> okay, well, we have quorum (just barely)
15:04:09 <abadger1999> spot: At beginning of September the Board will have to find a new meeting time again.
15:04:30 <spot> nirik: are you around?
15:04:34 <abadger1999> (but now they're aware of the FPC meeting at least)
15:04:43 <nirik> yeah, sorry...
15:04:58 <nirik> so, there's some progress on the PIE thing...
15:04:58 <spot> nirik: do you have a draft ready for the PIE issue?
15:05:11 <nirik> https://fedoraproject.org/wiki/User:Kevin/DRAFT_When_to_use_PIE_compiler_flags
15:05:20 <spot> #topic PIE
15:05:28 <nirik> we need to change the section about flags, ajax was going to make macros for it.
15:05:41 * nirik ediits really quickly.
15:07:14 * spot waits for the ninja edit
15:07:19 <nirik> basically we have a list where we would like to require it, but also leave open to maintainers to enable it if their package meets criteria for it being usefull
15:07:50 <nirik> so, the 'use something like this' section will change once we have macros.
15:08:11 <spot> as a point of legibility, i'd like to see this broken out on both sides
15:08:21 <spot> on the guidelines side, sectioned out by case
15:08:22 <limburgher> I see it's currently 'can'.  I'd like must (ain't gonna happen), and failing that I'm not sure if it should be 'can', 'should' or 'should consider'
15:08:25 <spot> where PIE is a case
15:08:26 <nirik> yeah, FPC side/ list side
15:08:36 <spot> and the same on the FESCo side
15:08:59 <spot> so we can be a bit more specific than "a list of packages that they require to have certain additional compilation flags enabled"
15:09:22 <nirik> yeah, makes sense.
15:09:30 <abadger1999> What's the rationale for preventing maintainers from adding these flags on their own?
15:10:11 <nirik> I guess that it could cause slowdowns... but I suppose if they don't feel thats a problem then not sure we should prevent them.
15:10:24 <spot> abadger1999: PIE will break some code, all PIE compiled code will now longer be prelink-able
15:10:26 <nirik> they can't use prelink then, and the startup costs will be higher
15:10:32 <Rathann> does the security SIG have a say in which packages get PIE'd?
15:11:02 <abadger1999> Okay.  I think "should consider" is likely a better choice than "can" in the section limburgher's pointing out.
15:11:33 <abadger1999> Probably mention the "PIE may break some code" case as well.
15:11:36 <spot> I'd almost want to reword it and switch the ordering.
15:11:45 <spot> 1) These packages must enable PIE
15:11:51 <limburgher> abadger1999: I agree.  Do we agree that 'should consider' is better than 'should'?  Due to breakage, performance, etc?
15:11:57 <nirik> Rathann: what security sig? ;)
15:12:10 <limburgher> First rule of security sig. . .
15:12:37 <spot> 2) Other packages are not required to enable PIE, but can consider enabling PIE, if <criteria>.
15:12:50 <limburgher> <killed by meme overuse patrol>
15:12:56 <abadger1999> spot: +1
15:13:29 <limburgher> spot: Shall we have a 'do not/cannot use PIE list' with reasons, like 'too slow', 'ate my baby', etc?
15:13:31 * nirik nods at spot's suggestion. makes sense.
15:13:39 <limburgher> spot:+1
15:13:49 <abadger1999> nirik: May I update for the reorder real quick?
15:14:13 <spot> limburgher: i think we should perhaps merge the disadvantages into the guideline as part of #2, explaining why you might not want to do it.
15:14:14 <nirik> abadger1999: sure. go for it.
15:14:36 <spot> i'd rather not have a blacklist and just let maintainers use their head
15:15:16 <limburgher> spot: Good.  That leaves the decision up to enterprising mainainer.  Besides, a blacklist would imply re-testing periodically, if later an item works well with PIE.
15:16:01 <tibbs|h> Where is this actually going to go in the guidelines? Replacing https://fedoraproject.org/wiki/Packaging:Guidelines#Compiler_flags or somewhere else?
15:16:58 <spot> I could see this replacing that section
15:17:07 <spot> that section is particularly crufty and old
15:17:15 <tibbs|h> "as of 2006..."
15:17:48 <spot> I would like to see "Adding to and overriding or filtering parts of these flags is permitted if there's a good reason to do so; the rationale for doing so should be reviewed and documented in the specfile especially in the override and filter cases." survive.
15:18:19 <spot> but the rest i think is covered in the draft
15:18:39 <spot> then tease out === PIE === as a subsection
15:18:54 <abadger1999> First reorder of page done.
15:19:27 * nirik reloads
15:21:18 * spot ninja edits in the disadvantages
15:22:19 <abadger1999> It would be nice if we had an example of how you might know PIE is breaking your code:  "If you compile with gcc and see that it gives an error BLEAGH then it could be the code doesn't work with PIE" or "When you run the app compiled with PIE, if it fails on startup but works when compiled without PIE then your code might not be compatibile with PIE" "If the app segfaults predictably when compiled with PIE [...]"
15:22:40 <abadger1999> Just something to point people in the right direction or away from wrong assumptions.
15:22:41 <tibbs|h> There are some grammar issues, I guess, and if this is going to replace the existing compiler flags guideline it needs to also mention everything that's in that guideline which we want to keep.  Particularly, I think it's important to explicitly limit the scope to C, C++ and such where the flags actually make sense.
15:22:51 * nirik isn't sure the cases of that off hand... I agree it would be nice to add.
15:23:24 * spot ninja edits some override language
15:24:33 <abadger1999> I think I'd add a sentence to the Compiler flags section that also points at this guideline.
15:24:37 * spot ninja edits for C, C++, and Fortran
15:24:58 <spot> abadger1999: i honestly think this can replace the existing section
15:25:00 <abadger1999> I think I'd add the guideline text to a new section on http://fedoraproject.org/wiki/Packaging/RPMMacros
15:25:08 * abadger1999 refreshes
15:26:10 <spot> the only remaining change that I would make would be to change "should" in the first sentence to "must".
15:26:49 * nirik reloads ago
15:26:50 <nirik> again
15:27:16 <abadger1999> I think I'd add some more of the generic stuff from the current guide.  /me does so
15:29:01 <tibbs|h> Not trying to be an ass, but the sentence starting with "Overriding these flags" approaches Bulwer-Lytton territory.
15:29:21 <spot> hee, yeah.
15:29:35 <spot> (this is the legal side of me bleeding over, feel free to improve it.)
15:29:43 <nirik> It was a dark and stormy night when I changed the optimization from -O2 to -O3...
15:31:53 * spot fills in the TODO explaining PIE
15:32:36 <limburgher> ROTLFMAOandspillingmycoffee
15:33:20 <tibbs|h> Naive edit: http://fpaste.org/fVXD/
15:33:34 <spot> "While it may seem like applying all the compiler flags found in Gentoo's wiki (or the gcc manpage) will make your code go OMGWTFBBQ, it is usually idiotic."
15:33:47 <tibbs|h> +99
15:33:59 <limburgher> :)
15:34:12 <limburgher> #laughingcantbreathe
15:34:36 <abadger1999> tibbs|h: +1 to your change
15:34:41 <spot> tibbs|h: looks good, i might drop the ", however, "
15:35:27 <spot> but i could leave it in too.
15:35:36 <tibbs|h> Either way.
15:35:50 * nirik thinks it reads better without that
15:36:03 <spot> i just worry that that parses weird with it, much less to someone who doesn't speak English as a first
15:36:19 <tibbs|h> Sure.  I was just rearranging words.
15:36:38 <spot> go ahead and ninja edit it in
15:36:54 <limburgher> tibbs|h: Never, ever say that to a legal person. ;)
15:37:25 <spot> limburgher: its right up there with "i fixed this existing license"
15:39:09 <spot> i think with tibbs's improved wording, I'm +1 on this, although we'd have to wait in on the macros and list before going live with it
15:40:34 <tibbs|h> OK, edited.
15:40:47 <tibbs|h> (no ",however, ".
15:41:11 <spot> any feedback on changing the first "should" to a "must" ?
15:41:11 <abadger1999> Yep, with the macros/how to add the macro to optflags section, this looks good.
15:41:34 <tibbs|h> spot: Hmm, yeah, "must" makes more sense to me.
15:41:36 <abadger1999> "; the rationale for doing so should be documented in the specfile" ?
15:41:44 * nirik thanks everyone for the ninja editing. Sorry its needed work. ;)
15:41:45 <abadger1999> yeah, s/should/must/
15:41:53 <spot> abadger1999: no, "Compilers used to build packages should"
15:42:04 <spot> although, i could see must there too
15:42:12 <abadger1999> yeah, +1 to change both to must.
15:42:38 <spot> +1
15:42:46 <tibbs|h> Generally, yeah, I think we should be using "must" in most of these places.
15:43:33 <tibbs|h> People tend to disagree over the strength of "should" when we use it.
15:43:50 <abadger1999> nirik: No problem, clarifying guidelines is not an onerous task.
15:44:23 <spot> i'm not hearing any opposition to the musts
15:44:27 <tibbs|h> Far better to get it right up front rather than later.
15:44:27 <spot> so i am editing them in
15:44:45 <pingou> as a non-english native, to me must -> mandatory -> optionnal, it is advised, not mandatory
15:44:57 <pingou> as a non-english native, to me must -> mandatory | should -> optionnal, it is advised, not mandatory*
15:45:08 <spot> pingou: that is generally how we consider it as well
15:45:28 <abadger1999> except when we use should instead of must :-)
15:45:37 <pingou> spot: not 100% if you are replacing should by must :)
15:45:37 <spot> abadger1999: yeah, except when we get it wrong. :)
15:46:04 <spot> okay, i changed the two shoulds to musts.
15:46:10 <spot> can we get votes on the draft?
15:46:20 <spot> +1
15:46:40 <abadger1999> +1 fwiw, still need the macros to finish it off.
15:47:02 <spot> yeah, we'll need to review the macros for sanity before it goes live
15:47:32 * spot notes that we just barely have quorum today, so i need votes from everyone to pass this
15:47:34 <tibbs|h> +1 (but, of course, it's incomplete)
15:48:06 <limburgher> +1
15:48:19 <spot> Rathann: still with us?
15:48:22 <Rathann> +1 so far
15:49:02 <spot> #action existing draft text (missing macros and FESCo list link) approved, waiting for missing pieces for final approval (+1:5, 0:0, -1:0)
15:49:15 <spot> nirik: please keep us updated on progress on the missing bits
15:49:20 <nirik> will do.
15:49:22 <nirik> thanks!
15:49:27 <spot> #topic Open Floor
15:50:16 <abadger1999> there's movement from ville to remove the trigger for (at least common cases) of the systemd guidelines.
15:50:21 * spot will note that he's hoping for a tested draft on any systemd scriptlet changes
15:50:38 <spot> i really am expecting that legwork to happen before it hits the consideration queue
15:50:53 <tibbs|h> Looking at an old ticket, how does this PIE stuff interact with that embryonic PIC guideline?
15:50:55 <abadger1999> yeah.  The legwork for that is horrendously awful.
15:51:01 <spot> i don't want those migraines again.
15:51:27 <spot> tibbs|h: PIE is for libs, PIC is for executables
15:51:28 <abadger1999> hmm... nirik, could you ask ajax tibbs|h's question?
15:51:40 <nirik> hum? which guideline?
15:51:42 <spot> but yeah, it would be nice to get that done at the same time
15:51:46 <tibbs|h> I mean, I know they're not the same thing.
15:51:51 <spot> https://fedorahosted.org/fpc/ticket/9
15:51:59 <spot> thats our oldest open ticket. :)
15:52:10 <spot> errrr.....
15:52:15 <spot> i got that backwards.
15:52:21 <spot> PIC is for libs, PIE for execs
15:52:25 <tibbs|h> ajax started that quite some time ago.
15:52:45 <tibbs|h> Honestly I think most of it could go away if rpmlint could just do the check when its appropriate.
15:52:59 <tibbs|h> But I've no real idea how reasonable that it.
15:53:26 <spot> i suspect ajax and someone like jakub would need to figure it out
15:53:33 * nirik isn't sure on that one... might be best to ask ajax.
15:54:33 <tibbs|h> And relating to the draft we just did, is is there any point to worrying about language-specific build systems (like Perl, Python, R, etc.) that will call the compiler themselves?
15:54:53 <abadger1999> tibbs|h: There is... we just don't know the answers atm.
15:55:18 <tibbs|h> I mean, you generally don't specify compiler flags anywhere when building an arch-specific R module; R takes care of that for you.
15:55:23 <abadger1999> in python, for things built using distutils or setuptools, the CFLAGS used to build the python interpreter are used.
15:55:28 <spot> tibbs|h: in the cases you call out, the compiler flags inherit from the runtime
15:55:41 <tibbs|h> But I guess the reviewer can still look at how the compiler is called.
15:55:45 <abadger1999> but if you have your own makefile to do it, you'd have to figure out the makefile.
15:55:50 <spot> e.g. building R with the proper optflags means that R modules all get built with them too
15:56:25 * spot has a hard stop at 12:00 to take people out to lunch
15:56:41 <spot> so... unless there is an item in the next minute or so, i'll close out the meeting
15:56:51 <tibbs|h> Nothing from me.
15:57:38 <abadger1999> nothing here either.
15:58:14 <spot> Okay, thanks everyone.
15:58:17 <spot> #endmeeting