15:59:58 <spot> #startmeeting Fedora Packaging Committee
15:59:58 <zodbot> Meeting started Wed Apr 13 15:59:58 2011 UTC.  The chair is spot. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:59:58 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:00:02 <spot> #meetingname fpc
16:00:02 <zodbot> The meeting name has been set to 'fpc'
16:00:08 <spot> #topic Roll Call
16:00:16 <tibbs|h> Howdy.
16:00:25 <epienbro> hi all
16:00:48 <SmootherFrOgZ> salut les loulous
16:00:57 * limburgher oh captain, my captian!
16:01:42 * geppetto is here
16:02:54 <spot> well, thats just barely quorum
16:03:07 <spot> racor told me he would not be here
16:03:32 * spot seems to recall that abadger1999 might not be here either
16:03:46 <jsmith> abadger1999 is on vacation
16:03:57 <spot> rdieter: ping?
16:03:59 <abadger1999> Hey, here now.
16:04:07 <abadger1999> Will be gone by tonight
16:04:12 <spot> abadger1999: aha!
16:04:15 <rdieter> oh hi, here.
16:04:28 <jsmith> abadger1999: Ah, sorry to lie about you then :-/
16:04:32 <spot> okay, i think we have everyone we're expecting. Rathann might drop in.
16:04:39 <abadger1999> jsmith: No problem :-)
16:05:14 <spot> #topic Systemd Migration Guidelines - https://fedoraproject.org/wiki/User:Toshio/Systemd_scriptlet_options
16:05:25 <spot> abadger1999: did you have a chance to test them at all? (i did not)
16:05:34 <abadger1999> I didn't have a chance either.
16:05:47 <abadger1999> So probably can't discuss this at all this time.
16:06:04 <spot> okay. i'll make a solid effort to test it this week
16:06:15 <spot> anyone else with spare cycles, please feel free to help here.
16:07:33 <spot> #topic Updated MinGW guidelines - https://fedorahosted.org/fpc/ticket/71
16:07:34 * SmootherFrOgZ will test this weekend
16:07:50 <spot> epienbro: thanks for coming, and for answering questions in the ticket
16:08:05 <epienbro> sure, no problem
16:08:13 <epienbro> luckily I could make it in time for the meeting
16:08:20 <abadger1999> spot: Oh, you could also try contacting bochecha (re: systemd testing) -- he had some package that needed to be converted and he said he'd be willing to test and give feedback.
16:08:29 <spot> abadger1999: okay, cool
16:08:43 <spot> going down the list of items from the ticket
16:08:50 <spot> 1) There is now a template spec, thanks
16:09:13 <spot> 2) Separated Source RPMS
16:09:43 <spot> With regards to #2, you said that the intent was that the SRPM would be mingw-foo and that the binary packages would reflect the bitsize targets
16:09:53 <epienbro> that's correct
16:10:04 <spot> The way Source package naming is worded makes that a bit unclear
16:10:15 <abadger1999> template, can we put it into the guideline page to match the other guidelines (and make sure that they stay in sync)?
16:11:02 <spot> we could simplify that section quite a bit by changing it to just say: MinGW source packages should be named by prefixing the upstream package name with mingw- (even if it only builds binary packages for mingw32 or mingw64).
16:11:35 <rwmjones> isn't it "prefixing the Fedora native package name"?
16:11:37 <spot> And possibly add a section for "Binary Package Naming" that covers the mingw32- vs mingw64- output
16:11:51 <spot> rwmjones: yep, thats probably better wording.
16:12:16 <epienbro> spot, sounds good enough to me
16:12:23 <spot> epienbro: okay, i'll make that change real quickly
16:12:25 <epienbro> I'll update the draft after the meeting
16:12:48 <epienbro> oh if you want to do it that's also fine by me
16:13:41 <abadger1999> https://fedoraproject.org/wiki/PackagingDrafts/MinGWCrossCompiler#Package_naming
16:13:50 <spot> abadger1999: you're too fast. :)
16:13:52 <abadger1999> spot: ^
16:13:55 <abadger1999> :-)
16:14:14 <spot> 3) There are no known situations for common files.
16:14:29 <spot> 4) Macro renaming
16:14:55 <spot> there were four macros identified for renaming from _foo to foo
16:15:06 <spot> (err. five)
16:15:11 <abadger1999> epienbro rwmjones: Should we say, there should be no mingw-foo binary packages? (All should be mingw32-foo or mingw64-foo)?
16:15:28 <rwmjones> epienbro?
16:15:35 <epienbro> abadger1999, sure
16:15:49 * abadger1999 makes that change
16:15:51 <spot> %{_mingw_find_lang} %{_mingw_configure} %{_mingw_cmake}, %{_mingw_make} and %{_mingw_make_install} should be renamed because their non-mingw counterparts are not _ prefixed
16:16:15 <spot> I believe the rest of the macros are fine as is.
16:16:16 <epienbro> well, rpm will always produce a 'mingw-foo' binary package, but it will be empty
16:16:23 <spot> epienbro: it shouldn't.
16:16:40 <spot> epienbro: if you don't have a %files, rpm is smart enough not to make an empty package
16:17:15 <epienbro> hm okay..but on the other hand..it makes the BuildRequires harder
16:17:33 <epienbro> as each package will now have to BuildRequires: mingw32-foo and BuildRequires: mingw64-foo
16:17:40 <epienbro> instead of just 'BuildRequires: mingw-foo'
16:17:54 <spot> epienbro: do they really need both or just the correct bitsized one?
16:18:13 <rwmjones> depends if the package can build both 32 bit and 64 bit variants
16:18:22 * spot could see situations where both would be necessary, but others where only one is needed
16:18:27 <spot> so that seems reasonable
16:18:38 <epienbro> for building srpm, you need both  (if you want to have binary packages for both w32 and w64 targets)
16:19:04 <abadger1999> hmmm .. good point
16:19:05 <spot> so, yeah, i think thats more correct than hiding it behind a meta-package
16:19:17 <spot> if it was 10+ packages, maybe, but two?
16:20:26 <epienbro> I'm okay with any of the 2 methods, I'll leave the decision to you :)
16:20:56 * spot prefers the more accurate set of BuildRequires. anyone else wanna chime in?
16:21:14 * abadger1999 is okay with either one.
16:21:29 <rwmjones> empty RPMs doesn't sound good to me
16:21:41 <abadger1999> explicit BR's do make for one less special case.
16:23:06 <abadger1999> the metapackage would mean documenting: BuildRequire: mingw-foo unless your package only builds on a subset of the supported mingw architectures.  Then BuildRequire the platform specific binary rpm instead.
16:23:18 <tibbs|h> I have no preference, but I don't think that being explicit is going to hurt anyone.
16:23:18 <spot> i don't hear anyone strenuously advocating for the meta-package, so lets go with the explicit BuildRequires.
16:23:35 <abadger1999> <nod>
16:23:53 <spot> i think the only obvious change that needs to be made is to the example spec
16:24:06 <epienbro> okay, perhaps it would be good to add something to the draft which mentions that there should be no %files section for the main package
16:24:19 <epienbro> I'll update the example spec right now
16:24:57 <spot> abadger1999: since you're fast with the wiki, can you add that "No %files for the mingw-foo package, just for mingw32-foo and/or mingw64-foo" ?
16:25:20 <abadger1999> Yep.
16:25:41 <epienbro> now that we've made this decision, the macro %{_mingw_default_requires} can be dropped from the draft
16:26:28 <tibbs|h> I note it's a bit contradictory for the sample spec to include -static subpackages with no comment while the guidelines say that static libs should not be built.
16:27:59 <spot> okay, so on macro naming
16:28:01 <epienbro> the example spec has just been updated
16:28:12 <epienbro> tibbs|h, it does? let me verify..
16:28:18 <abadger1999> guideline page updated.
16:28:58 <spot> the five we've highlighted should not need the _, as their "normal" version doesn't have it. The rest of the macros are pathing or command macros, where the normal version does have a _ prefix
16:28:59 <epienbro> tibbs|h, did you mean that the native fedora guidelines state that static libs shouldn't be built?
16:29:12 <tibbs|h> I mean the proposed mingw guideline also says that.
16:29:16 <spot> https://fedoraproject.org/wiki/PackagingDrafts/MinGWCrossCompiler#Static_libraries
16:29:23 <tibbs|h> In accordance with ordinary Fedora policy, static libraries should not be built, and if they are then they should be placed in a -static subpackage.
16:29:32 <epienbro> ah yes I see
16:29:42 <tibbs|h> Yet the example spec passes --enable-static and includes the subpackages.
16:30:07 <epienbro> well, the case is that several mingw32 packages already have -static subpackages
16:30:34 * spot won't lose much sleep over mingw static packages, since the Windows use case often requires them
16:30:35 <epienbro> so basically it's up to the package maintainer to decide if they want to bundle static libs
16:30:50 <tibbs|h> All I'm saying is that things are currently contradictory.
16:31:21 <spot> tibbs|h: perhaps a comment in the template spec reminding maintainers that in most cases, static libs are not necessary
16:31:38 <tibbs|h> Sure, or simply strike the sentence from the guidelines.
16:31:45 <epienbro> yeah that sentence is kinda contradictory
16:31:59 * spot is fine with dropping that static section
16:31:59 <epienbro> but I'll also add a comment to the example spec about this
16:32:22 * spot nukes it
16:33:05 <epienbro> don't you wish to keep something which says that it's up to the package maintainer to decide for itself whether they want to bundle static libs?
16:33:26 <spot> epienbro: well, we could just point to the static libs section in the general guidelines
16:33:49 <spot> epienbro: but in general, it is assumed that unless the type specific guidelines overrule a normal guideline, it is still applicable
16:33:58 <abadger1999> ehh.. that would continue to disagree with the example spec.
16:34:16 <abadger1999> the example spec has the static libraries in the same subpackage as the dynamic libraries.
16:34:27 <epienbro> no it hasn't
16:34:45 <epienbro> the .dll.a files are import libraries, not static libraries
16:34:47 <abadger1999> or maybe not
16:34:54 <abadger1999> Ah yeah, that's what confused me.
16:35:00 <epienbro> the .a files really are static libs
16:36:10 <rwmjones> they contain automatically generated stubs that get linked to the application; the stubs deal with the business of locating the DLL and loading it (which is not automatic like in Linux)
16:36:36 <spot> So, on macro naming: there are three situations in play: macros that are mingw versions of command macros (e.g. %{_mingw_configure}), macros that are mingw versions of path macros (e.g. %{_mingw32_bindir}), and mingw custom macros (e.g. %{_mingw32_sysroot})
16:36:54 <geppetto> epienbro: Do you need to name them .dll.a ?
16:37:14 <epienbro> geppetto, it's what libtool does automatically
16:37:23 <spot> i can see the benefit of a consistent naming scheme here, i'm just not sure the _ prefix is beneficial.
16:37:45 <epienbro> spot, mingw32_sysroot is also a path macro
16:38:04 <spot> epienbro: yes, but there is no "normal" equivalent
16:38:19 <epienbro> '/' :)
16:38:26 <spot> yeah, but there is no %{sysroot}
16:38:44 <spot> so, my proposal is to just drop the _ prefixing everywhere
16:38:52 <tibbs|h> Sure, if at all possible, less typing.
16:39:07 <spot> and not lose sleep over the fact that a strictly correct version of the path macros would have redundant underscores
16:39:24 <epienbro> fine by me
16:39:44 <spot> anyone disagree?
16:39:48 <tibbs|h> Not me.
16:40:24 <SmootherFrOgZ> nope
16:40:27 <spot> okay. then i think the last issue was do with the %{mingw_configure} parsing
16:40:42 <spot> abadger1999 thought that %mingw_configure --disable-xlib --enable-win32 would work fine
16:40:44 <abadger1999> epienbro, rwmjonesDoes the paragraph here look good: https://fedoraproject.org/wiki/PackagingDrafts/MinGWCrossCompiler#Libraries_.28DLLs.29
16:40:46 <epienbro> I just updated the spec file to make it more clear that static subpackages are optional
16:41:58 <rwmjones> epienbro: do we need the *.la file?
16:42:02 <epienbro> abadger1999, looks good, there's just a </code> there which doesn't belong there
16:42:08 * abadger1999 fixes
16:42:23 <epienbro> rwmjones, yeah you need them, especially when you're working with static libs
16:42:33 <rwmjones> ok, I'm fine with it in that case
16:42:34 <epienbro> and if they're missing libtool will complain
16:42:42 <rwmjones> libtool--  bane of my life
16:43:25 <abadger1999> So with %mingw_configure args  -- epienbro did you get a chance to test?
16:43:36 <epienbro> spot, %mingw_configure without braces: didn't have time to test that yet..
16:44:42 <epienbro> but I'm afraid it won't work well
16:44:49 <spot> okay, then i propose that we edit the draft to use %mingw_configure --disable-xlib --enable-win32 for now
16:45:01 <spot> and if it is discovered to not work, we can always make a quick ninja edit
16:45:12 <epienbro> good
16:45:17 <abadger1999> Sounds good to me.
16:45:37 <tibbs|h> Sure.
16:46:45 <abadger1999> So the three changes: 1) Include spec template inline (at the end of the page) 2) Switch _mingw* macros to mngw* 3) Change %{mingw_configure "arg1" "arg2"} to %mingw_configure arg1 arg2
16:47:01 <spot> i just made the configure change
16:47:29 <spot> the other two changes i can make before we move it to its new home
16:47:45 <spot> along with preserving the old guidelines and adding a link to them for older targets
16:48:06 <epienbro> do you want to drop the curly braces from the mingw_make macro as well?
16:48:22 <epienbro> (and mingw_make_install)
16:48:26 * abadger1999 sees another %{mingw_configure arg} and changes
16:48:50 <kalev> rwmjones, regarding the .la files: afaik they were originally designed for linking back in the time when there were no shared libraries
16:48:52 <spot> epienbro: yes, good catch
16:49:05 <kalev> rwmjones: .a files are just archives, with no metadata about other dependant libraries
16:49:22 <spot> abadger1999: since you're editing there, can you get those two items as well?
16:49:31 <kalev> rwmjones: fortunately, elf .so files have DT_NEEDED sections for loading other needed libraries so .la files are really not useful any more
16:49:48 <rwmjones> kalev: I know .. unfortunately they nowadays cause *over*-linking.  See the workaround we use in libguestfs: http://git.annexia.org/?p=libguestfs.git;a=blob;f=libtool-kill-dependency_libs.sh;hb=HEAD
16:49:57 <kalev> rwmjones:  I believe the situation is the same on windows: .la files are not needed for linking dynamic libraries, but are pretty useful for static libs
16:50:31 <epienbro> about the _mingw* to mingw* change..this will break backwards compatibility with all current mingw32-* packages..is this really what we want to do?
16:50:47 <epienbro> or should I add backwards compatibility macros for those?
16:51:52 <spot> hmm
16:52:05 * abadger1999 fixes mingw_make and mingw_make_install
16:52:39 * spot likes clean macros, i'm fine with backwards compat macros as long as they're not documented in the guideline
16:52:42 <abadger1999> I'm fine with just changing the five that were mentioned -- do those macros break backwards compat?
16:53:07 * abadger1999 also fine with spot's backwards compat but undocumented.
16:53:27 <epienbro> which five exactly?
16:53:42 <epienbro> mingw_configure, mingw_make and mingw_make_install are new macros
16:53:51 <epienbro> so they won't break backwards compatibility
16:54:16 <spot> i think just keeping backwards compat macros that are basically just aliases to the new, proper names are fine
16:54:45 <abadger1999> _mingw_find_lang should be renamed to mingw_find_lang for consistency. The same change applies to %{_mingw_configure} %{_mingw_cmake}, %{_mingw_make} and %{_mingw_make_install}
16:54:54 <abadger1999> Those are the five.
16:55:00 <epienbro> ah yes, those are all new
16:55:04 <epienbro> so can be renamed safely
16:55:40 <spot> and the others can have alias macros with the old names
16:55:54 <epienbro> okay
16:56:46 <spot> so, with the two changes: 1) Include spec template inline (at the end of the page) 2) Switch _mingw* macros in draft and template spec to mingw*
16:56:50 <spot> Lets take a vote
16:56:52 <epienbro> example has been updated again, for the macro renaming and explicit BR's
16:56:52 <spot> +1
16:57:35 <limburgher> +1
16:57:37 <SmootherFrOgZ> +1 from me
16:57:45 <tibbs|h> Sorry, on the phone.
16:57:57 <tibbs|h> +1
16:58:07 <abadger1999> +1
16:58:27 <spot> okay, thats our +5. rdieter, if you want to jump in, go for it.
16:58:35 <rdieter> +1
16:58:41 <geppetto> +1
16:59:01 <spot> #action Approved with two changes: 1) Include spec template inline (at the end of the page) 2) Switch _mingw* macros in draft and template spec to mingw* (+1:7, 0:0, -1:0)
16:59:14 <spot> epienbro & rwmjones: thanks for your help!
16:59:24 <epienbro> no problem :)
16:59:41 <spot> okay, next item
16:59:47 <kalev> what about the naming of the base packages, mingw-filesystem, mingw-gcc, mingw-binutils? Now that all other packages don't build mingw- binary packages, should these be changed too?
17:00:25 <epienbro> they can also be named in line with the guidelines
17:00:38 <epienbro> so the srpms will be the names you just mentioned
17:00:51 <epienbro> and only mingw32-foo and mingw64-foo binary packages will be built
17:00:57 <kalev> okay, sounds good.
17:01:08 <spot> epienbro: please update the draft to reflect that
17:01:13 <spot> and lemme know when you're done
17:01:21 <epienbro> right away
17:01:34 <spot> #topic Perl paths @INC change - https://fedorahosted.org/fpc/ticket/73
17:01:59 <tibbs|h> Did we actually get an answer to the question you raised?
17:02:08 <spot> For the record, we still have not received any feedback from mmaslano.
17:02:23 <spot> i will send her an email hoping to get clarification
17:02:25 <tibbs|h> "I'd like to have vendor reserved as empty directory for users Perl rpms. Otherwise there is no need to have vendor at all."
17:02:40 <spot> oh, my bad
17:02:46 * spot wonders how he missed that
17:02:50 <tibbs|h> I'm still not sure I get it, though.
17:03:15 <tibbs|h> Plus, "vendor" for "user" packages seems quite backwards.
17:03:27 <spot> yeah. i agree. i really do not see the benefit of this change.
17:03:45 <tibbs|h> Maybe the idea is to let users install their own packages to override the distro ones.
17:03:59 <tibbs|h> And vendor happens to be earlier in the search sequence.
17:04:03 <spot> yes, but that works with the existing @INC pathing, i thought
17:04:21 <tibbs|h> I can't really call myself a perl expert these days.
17:04:31 <spot> well, the CPAN path is still identical
17:04:40 <spot> and most users doing local installs use CPAN
17:04:49 <tibbs|h> This is also something that Ralf will have a strong opinion on.
17:05:03 <tibbs|h> Whether we can get him to state it is another matter.
17:05:56 <spot> lemme see if i can get feedback from upstream perl before we move on this
17:06:07 <spot> they have had rather... strong opinions on our @INC paths in the past
17:06:17 <spot> we'll revisit it next week
17:06:24 <tibbs|h> But I thought we actually took care of their concerns.
17:06:37 <spot> tibbs|h: we did, but that is with the current macros, not the proposed changes
17:06:40 <tibbs|h> I guess I'd hate to get back to a state where they think we're screwing up.
17:06:59 <spot> iirc, they interpreted the "vendor" target as "the place Fedora puts things"
17:07:01 <tibbs|h> I still think there's some RHEL issue underlying this.
17:07:15 <spot> and the private target as "the place perl puts things"
17:07:25 <spot> and the user target as "the place everyone else puts things"
17:07:42 <geppetto> A quick google brings up: http://use.perl.org/~schwern/journal/39246
17:07:55 <geppetto> Which seems to imply "vendor == rpm packages go here"
17:08:17 <spot> yep. which means mmaslano's proposal is not in sync with upstream
17:08:32 <spot> i'll double check, but we should revisit this next week
17:08:36 <tibbs|h> That's from a macos perspective where "OS" and "package manager" aren't the same thing, though.
17:09:06 <tibbs|h> Not that the observation isn't valid.
17:09:19 <tibbs|h> I do think that's where a lot of the confusion comes from, though.
17:09:28 * spot is running into a hard stop here today
17:09:33 <spot> but two quick items
17:09:37 <spot> #topic https://fedorahosted.org/fpc/ticket/76
17:09:50 <spot> I would like to see a draft there before we discuss it in a meeting
17:09:53 <tibbs|h> Sure.
17:10:01 <tibbs|h> The question is whether it's worth me writing a draft.
17:10:14 <spot> tibbs|h: seems like it to me. i know upstream rpm would prefer it
17:10:20 <tibbs|h> Or should we wait until the new stuff is supported in an actual release.
17:10:31 <spot> tibbs|h: we could wait for F15 to drop.
17:10:45 <spot> #topic meeting time
17:10:49 <tibbs|h> Unfortunately upstream hasn't actually documented this stuff, but I think I know enough about it to do stuff.
17:11:02 <spot> most of you did not email me wrt to moving to 1500 UTC on Wednesday
17:11:10 <spot> so now is your chance to speak up
17:11:16 <tibbs|h> I already indicated that time was fine for me.
17:11:27 <limburgher> +1
17:11:30 <abadger1999> I don't know how it works, but I'd love to have it documented.
17:11:42 <tibbs|h> abadger1999: I think this will end up being the documentation.
17:11:47 <tibbs|h> It's terribly simple.
17:12:08 <abadger1999> 15:00 UTC Wed works for me.
17:12:21 <geppetto> 15:00 is fine here, too
17:12:28 <abadger1999> tibbs|h: Make a draft and I'll vote for it then :-)
17:12:36 <SmootherFrOgZ> +1 for the record
17:12:36 <spot> #action Our next meeting will be at 1500 UTC on April 20. Future meetings will be at 1500 UTC on Wednesdays.
17:12:44 <rdieter> ok with me
17:13:07 <spot> If there are any super urgent open floor items, throw them at me now, otherwise, i'm closing this meeting out in a minute.
17:13:16 <spot> #topic Brief Open Floor
17:13:18 <abadger1999> One thing that I'm going to ticket (but then leave :-) is that %defattr seems to only be necessary on EL-4
17:13:37 <tibbs|h> Really?
17:13:46 <abadger1999> scop tested and rpm seems to put a default %defattr in if it's not present.
17:13:52 <spot> abadger1999: yeah, i think they finally made "default attributes" the default. ;)
17:13:54 <tibbs|h> It would be nice to dump another pointless bit of line noise from specs.
17:14:44 <spot> okay, thanks everyone
17:14:51 <tibbs|h> Thanks.
17:14:52 <spot> dont forget to test selinux migration if you have time
17:14:54 <spot> #endmeeting