16:01:03 <spot> #startmeeting Fedora Packaging Committee
16:01:03 <zodbot> Meeting started Wed Apr 18 16:01:03 2012 UTC.  The chair is spot. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:01:03 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:01:07 <spot> #meetingname fpc
16:01:07 <zodbot> The meeting name has been set to 'fpc'
16:01:13 * geppetto nods … is here
16:01:17 <spot> #topic Roll Call
16:01:25 <geppetto> here
16:01:42 * abadger1999 here
16:03:23 * limburgher here
16:04:16 * racor here
16:04:26 <spot> and me makes 5
16:04:39 <spot> rdieter_work, tibbs|h, SmootherFrOgZ: ping?
16:05:28 <rdieter_work> have to count me out today, @work craziness
16:06:07 <spot> okay, well, we have quorum, so lets get to it
16:06:35 <spot> #topic (about mount --make-rprivate) : https://fedorahosted.org/fpc/ticket/162
16:07:34 <spot> so, i looked at this, and i think this is a request for us to add a guideline that says "Packages must not contain any code which executes 'mount --make-rprivate /'"
16:07:54 <spot> which seems really... odd. we might as well have guidelines that say "packages must not run 'rm -rf /'"
16:08:34 <limburgher> Or dd if=udrandom of=/dev/sda
16:09:51 <spot> i think my instinct here is to close this ticket as WONTFIX while encouraging the filer to reopen if they have a specific draft they want us to consider.
16:11:23 <spot> any other thoughts?
16:12:05 <limburgher> Sounds good.  I can't think this is terribly prevalent.  Like if someone's code flushed all iptables rules, it'd get found and a BZ filed.
16:12:34 <abadger1999> spot: +1
16:12:37 <geppetto> +1
16:13:01 <limburgher> +1
16:13:37 <spot> #action Marked as WONTFIX
16:13:59 <spot> #topic New (new) MinGW guidelines - https://fedorahosted.org/fpc/ticket/163
16:14:20 <spot> here's your diff between what we approved before and the newest draft: https://fedoraproject.org/w/index.php?title=PackagingDrafts%2FMinGWCrossCompiler&action=historysubmit&diff=284686&oldid=284536
16:14:50 <limburgher> The rename is done, right?
16:15:23 <spot> this draft assumes that it will be MinGW and the existing MinGW gets moved to MinGW_Old
16:15:34 <abadger1999> special naming to denounce the appropriate CPU  => s/denounce/denote/
16:15:57 <spot> abadger1999: good catch
16:16:00 <limburgher> abadger1999: That gave me an awesome mental picture
16:16:06 <spot> there are also some macros missing {}
16:17:38 * spot fixes both in a ninja edit
16:17:59 <spot> new diff: https://fedoraproject.org/w/index.php?title=PackagingDrafts%2FMinGWCrossCompiler&action=historysubmit&diff=284926&oldid=284536
16:19:44 <spot> the rest of it seems okay enough to me. the only reservation I have is that i am generally not a fan of "hiding" macros like they're doing with the %{mingw_package_header}, but eh.
16:20:21 <limburgher> Think there's probably a big enough maintainability gain there to let it go.
16:20:54 <spot> limburgher: yep.
16:21:20 <abadger1999> I wonder if the Line 355 removals are intentional
16:21:37 <abadger1999> (The part about %{mingw_configure} vs %mingw_configure
16:22:25 <spot> hm.
16:22:28 <spot> thats a good catch
16:23:28 <spot> they drop the " " in the example spec
16:23:34 <spot> so perhaps that macro is different?
16:24:25 <kalev> Yes, we managed to hack around the rpm macro optarg() parsing limitation we ran into earlier, so the quotes aren't necessary any more
16:24:50 <spot> kalev: so that section about mingw_configure was intentionally removed?
16:25:00 <kalev> regarding %{mingw_configure} vs %mingw_configure, I believe epienbro's intention was to make it similar to %configure macro, which is usually used without braces
16:25:06 <kalev> let me see.
16:25:43 <abadger1999> kalev: <nod>  But last time we added a note to explicitly say that %{mingw_configure} FOO  would not work correctly.
16:26:08 <abadger1999> this revision takes out that warning and we're wondering if that's on purpose (because with braces would work now)
16:26:11 <spot> kalev: i think the issue there is that the old MinGW32 used %{mingw32_configure}, and if you moved to %{mingw_configure} it wouldn't work properly in some/all cases.
16:26:14 <abadger1999> or on accident
16:26:55 <kalev> ah yes, it will work properly now with braces
16:27:19 <spot> okay then.
16:27:33 <abadger1999> Excellent
16:27:55 <abadger1999> The only other thing I see is that I'd like to have a section that explains what   %?mingw_package_header does
16:28:37 <kalev> for reference, %mingw_package_header is defined here: http://pkgs.fedoraproject.org/gitweb/?p=mingw-filesystem.git;a=blob;f=macros.mingw;h=d74130195d00280670715d8cbd1e56e44b0757dc;hb=HEAD#l28
16:28:46 <abadger1999> I'm assuming it's setting strip, find_deps, etc appropriately
16:29:06 <kalev> it's overriding __strip, __objdump, and __debug_install_post
16:29:29 <kalev> overriding the internal dep gen macros isn't necessary any more as we use RPM 4.9 fileattr based depgen
16:30:31 <abadger1999> ah so it's actually a lot simpler than all the sections its replacing
16:30:34 <abadger1999> Cool
16:30:37 <spot> i can't really imagine any of those three items being things a mingw packager would ever override either
16:30:52 <spot> so i'm actually okay without that definition being in the guidelines
16:31:13 * spot has no problem with it being added either, just don't think it is a blocker
16:31:51 * abadger1999 edits
16:32:23 <limburgher> <nods>
16:32:41 <racor> spot: packaging mingw -> <ELF-based OS> cross-compilers would likely be such a case. rpm's depgen usually fails miserably in such cases.
16:33:14 <spot> racor: eh, okay, although, i would hope if you're building a cross-compiler package, you know how to run rpm --eval "". ;)
16:35:33 <abadger1999> https://fedoraproject.org/wiki/PackagingDrafts/MinGWCrossCompiler#Stripping
16:35:54 <spot> looks good to me
16:36:33 <spot> so, I'm +1 on the draft
16:36:45 <limburgher> + also.
16:36:56 <limburgher> +1 that is.
16:37:19 <abadger1999> +1
16:37:21 <geppetto> +1
16:38:24 <racor> +1
16:38:38 <spot> #action Draft approved (+1:5, 0:0, -1:0)
16:38:44 <kalev> excellent, thanks
16:39:08 <spot> kalev: thanks for your help
16:39:33 <spot> #topic Add note about {release} into "Release Tag" chapter of Guidelines - https://fedorahosted.org/fpc/ticket/164
16:40:15 <spot> so, i don't agree with 164. I think double defining release as he proposes is a great way to confuse yourself and others.
16:40:47 <abadger1999> Amen, brother
16:40:56 <spot> there seems to be a bug in rpmdev-bumpspec where it can't find the canonical integer in a macro nightmare
16:41:17 <spot> but i happen to think that appending a subint (.1) is a perfectly valid way out of that case
16:41:39 <geppetto> yeh, I didn't see the big problem with putting it after dist.
16:42:10 <spot> so, i'm firmly WONTFIX on this one.
16:42:33 <geppetto> Yeh, maybe tell them they can open a BZ to fix rpmdev-bumpspec
16:42:49 <limburgher> Sounds reasonable.
16:42:56 <spot> okay, sounds like we're in agreement
16:43:12 <racor> I had not heard about this tool before and just gave it a try on some of my specs. -EFAIL this thing doesn't work reliable.
16:44:23 * abadger1999 votes -1 to the draft ; +1 to geppetto's suggestion to open a bug.
16:44:36 <limburgher> I hadn't either.  I'd love to use it, but if it's buggy it's more trouble than it's worth.
16:44:51 <geppetto> racor: My guess is that program is a hack that works in the very simple case only.
16:45:04 <geppetto> But I haven't looked.
16:45:21 <abadger1999> it might be what releng uses to do mass rebuilds.
16:45:49 <spot> #action Closed as WONTFIX, advised on why and recommended that they file a bug
16:46:02 <spot> #topic Open Floor
16:46:08 <racor> My private/non public  *.specs usually use Release: 0.<isodate>.<int>${?dist}, eg. 0.20120418.3
16:46:14 <limburgher> No, I think that's in their git repo.
16:46:25 <abadger1999> k
16:46:39 <limburgher> scripts/mass-rebuild.py, I think.
16:46:40 <racor> rpmdev-bumpspec increments the date instead of the <int> at the end ;)
16:49:10 <spot> if there are no other issues in the next, oh, two minutes, i'm ending the meeting
16:49:31 <limburgher> I think epienbro has a question.
16:50:03 <abadger1999> epienbro asked this in #fedora-meeting:
16:50:05 <abadger1999> [09:46:34] <epienbro> why did you add the curly braces to the mingw_package_header macro? I recall that in the previous fpc meeting (where the new mingw packaging guidelines were first approved) the recommendation was to remove the curly braces from all macros (where possible)
16:50:47 <spot> i thought we were only concerned about curly braces wrt configure
16:51:06 <VICODANAX> hiya
16:51:26 <abadger1999> yeah, afaik, macros that take parameters can't (or sometimes can't) have curly braces.
16:51:35 <abadger1999> all other macros are okay to have curly braces.
16:51:41 * spot thinks macros should have curly braces unless they can't because they have param issues
16:52:49 <spot> anything else?
16:53:06 <abadger1999> VICODANAX: did you have a question for FPC?
16:54:13 <VICODANAX> just sitting in the meeting, im a noob
16:54:17 <abadger1999> k
16:54:22 <abadger1999> nothing more from me
16:55:03 <limburgher> done here.
16:55:22 <spot> okay, thanks everyone
16:55:24 <spot> #endmeeting