15:58:20 <spot> #startmeeting Fedora Packaging Committee
15:58:20 <zodbot> Meeting started Wed Mar 30 15:58:20 2011 UTC.  The chair is spot. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:58:20 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
15:58:32 <spot> #meetingname fpc
15:58:32 <zodbot> The meeting name has been set to 'fpc'
15:58:37 <spot> #topic Roll Call
16:00:27 <spot> ping: racor, abadger1999, rdieter, tibbs, geppetto, Rathann
16:00:31 * Rathann is here
16:00:36 * abadger1999 here
16:01:09 <racor> here, but will likely have to leave early due to DST in effect
16:01:18 <tibbs> Howdy.
16:01:19 <geppetto> here
16:04:21 <spot> okay, thats quorum
16:04:46 <spot> #topic Updated MinGW guidelines - https://fedorahosted.org/fpc/ticket/71 - https://fedoraproject.org/wiki/PackagingDrafts/MinGWCrossCompiler
16:05:16 <tibbs> Can we fix the FIXME at the top by just moving the template into the guideline?
16:05:17 <spot> Please note that I have cleaned up this draft to make it clear that these guidelines are only applicable to MinGW, and not as some sort of universal cross-compiler guidelines
16:05:59 <spot> tibbs: well, i think the problem is that the template has not been updated
16:06:05 <spot> tibbs: but yeah, we could.
16:06:13 <spot> (if it was updated)
16:07:17 <spot> rwmjones: around?
16:07:34 <tibbs> Are they still happy with this draft after you've cleaned it up?
16:07:45 <spot> tibbs: there was no feedback on the ticket
16:09:11 <racor> i still don't like it.
16:09:22 <abadger1999> Do the win64 and win32 binaries get placed into two different subpackages?
16:10:00 <tibbs> Tough to say without an updated example spec, I guess.
16:10:06 <tibbs> But I don't see why that would need to be the case.
16:10:09 <spot> Each cross compiled MinGW package which builds binaries for a specific target should put the binaries for that target in a separate subpackage. So if a package foo builds binaries for the Win32 and Win64 targets, then the source RPM should provide two subpackages named mingw32-foo and mingw64-foo.
16:10:17 <spot> So, yes.
16:10:41 <tibbs> What about common files and such?
16:10:58 <tibbs> Or does that not happen?
16:11:08 <spot> I'm sure it could happen.
16:11:14 <spot> I don't believe that is addressed here.
16:11:58 <tibbs> I guess it probably should be.
16:12:00 <Rathann> I think it's addressed by this:
16:12:01 <spot> But in general, i think the mingw packages only contain libraries/binaries
16:12:08 <tibbs> Or we should get a definitive answer that it's not necessary.
16:12:10 <Rathann> Cross compiled MinGW packages must follow Fedora policy, except where noted in this document.
16:13:11 <spot> The common files would be things like manpages and info files, which are omitted according to this draft.
16:13:32 <spot> So, the only cases I can think of would be configuration files or data files
16:13:37 <abadger1999> Not sure why we're separating mingw32, ming2, and mingw64 at the srpm level... seems more appropriate to name everything mingw- and separate at the binary package level.
16:14:02 <abadger1999> That last comment was about hte naming.
16:14:07 <spot> abadger1999: it does seem a bit odd, i think they're trying to document the case where a package only builds for one or the other
16:14:08 <tibbs> abadger1999: I kind of agree.  Just seems that we'll have renaming to do in the future.
16:14:23 <spot> i don't really see the merit of it though.
16:14:24 <abadger1999> tibbs: Right.  That was my thought
16:14:25 <tibbs> But I suppose that it's possible to need separate 32 and 64 bit srpms sor some library.
16:15:05 <spot> i don't see how, unless they were separate sources
16:15:15 <spot> (and even then, it should be possible to do in a single SRPM)
16:15:22 <geppetto> yeh
16:16:06 * spot wishes someone involved with mingw like rwmjones was around to discuss some of these points
16:16:09 <racor> they will not be able to avoid doing so, otherwise fixing a bug which only applies to one target requires a updating the other as well.
16:16:24 <tibbs> I don't really see that as a problem.
16:16:30 <Rathann> hm, on second thought, you are right, there should be no need for mingw32 and mingw64 srpms
16:16:34 <abadger1999> This means that a spec file must contains %package and %files sections for all the targets. We're still looking for methods to simplify this as it currently introduces quite an amount of duplication <= remove the second sentence there
16:16:50 <racor> I do mingw64 and mingw32 are entirely different beasts.
16:16:50 <tibbs> Fixing a 64-bit only bug in some native package right now involves updating every arch.
16:17:20 <Rathann> racor: you mean like i686 and x86_64? ;)
16:17:49 <abadger1999> Rename this macro: %_mingw_find_lang => %mingw_find_lang
16:17:51 <spot> abadger1999: nuked
16:18:02 <abadger1999> (Have to get it changecd in the package too)
16:18:32 <racor> I am not entirely sure. i686 and x86_64 linux are entirely separate paths within the cross-toolchains
16:18:53 <spot> abadger1999: why? (re: the macro rename)
16:19:02 <abadger1999> spot: To match %find_lang
16:19:04 <spot> abadger1999: all of their macros are in the syntax _mingw_FOO
16:19:11 <racor> i686-pc-mingw32 is a well estabilished target
16:19:25 * laxathom here
16:19:46 <racor> i686/x86_64-w64-mingw32 is very problematic and will not work without changes to many packages
16:20:53 <tibbs> Perhaps that's what they had in mind when they worded the original guideline.  It's tough to say.
16:21:04 <tibbs> Anyway, I don't think we can make progress here without some answers.
16:21:08 <spot> the old guideline used i686-pc-mingw32
16:22:11 <racor> spot: correct, ... because that's what mingw traditionally had been using.
16:22:19 <spot> it looks like the target naming is coming from the mingw-w64 fork
16:22:21 <spot> http://mingw-w64.sourceforge.net/
16:23:02 <racor> OK, I wasn't aware about it. When I am referring to mingw, I ususally refer to mingw.org
16:23:24 <spot> racor: yes, but in the ticket, they explicitly state that they're moving to the mingw-w64 codebase
16:23:43 <spot> so i think this target is correct.
16:24:58 <spot> So, it seems like there are three issues now
16:24:59 <abadger1999> "Packages which don't support out of source compilation may require a different approach like performing everything in the %install phase." <= I'd prefer copying of the source tree in %prep to what they seem to be saying here (do the configure and build steps in the %install section)
16:25:02 <spot> 1) No valid template
16:25:30 <spot> 2) No need for separated source RPMS (mingw-* is fine for everything, even if it only spits out mingw32-* or mingw64-* subpackages)
16:25:44 <racor> spot: Proposal table this issue, once more ... at least I would have to check what mingw-w64 is doing and who they are - I've never heard about them before.
16:25:47 <spot> 3) _mingw_find_lang should be renamed to mingw_find_lang for consistency
16:26:07 <abadger1999> %{_mingw_configure "--disable-xlib" "--enable-win32"} I think that and the following disclaimer can be changed to => %_mingw_configure --disable-xlib --enable-win32
16:26:41 <spot> abadger1999: well, i think that won't actually work.
16:26:56 <SmootherFrOgZ> abadger1999, +1
16:26:56 <spot> abadger1999: i don't know what that macro looks like, but i expect it loops through both targets
16:27:03 <abadger1999> I think this is the only form that doesn't work: %{_mingw_configure} --disable-xlib --enable-win32
16:27:14 <SmootherFrOgZ> spot, why, this can be added as an rpm_macros
16:27:15 <abadger1999> oh
16:27:20 <abadger1999> Let me look
16:27:51 <rdieter> here now (sorry)
16:29:24 <spot> 4) "Packages which don't support out of source compilation may require a different approach like performing everything in the %install phase." should be changed to "Packages which don't support out of source compilation may require a different approach like making multiple copies of the source tree in %prep."
16:29:44 <tibbs> That does seem preferable.
16:30:26 <abadger1999> +1 to rewording in #4
16:30:42 <spot> abadger1999: i think we're going to need to get feedback on this proposed changes
16:30:48 <spot> s/this/these/
16:30:55 <rwmjones> spot: sorry I don't know a lot about this, epienbro should be around to talk about this
16:31:38 <abadger1999> #3) => these macros might also be changed for similar reasons: %{_mingw_configure} %{_mingw_cmake}, %{_mingw_make} and %{_mingw_make_install}
16:31:39 <rwmjones> it might be better to kick this to a future meeting and I'll make sure he turns up?
16:31:54 <spot> rwmjones: sure. i'll document our concerns in the ticket.
16:31:59 <spot> we'll defer this to next week.
16:32:29 <abadger1999> rwmjones: Do you know which version of mingw-filesystem has the macros listed here?
16:32:38 <abadger1999> Are they in the current master?
16:32:41 <rwmjones> I know virtually nothing about this
16:32:45 <abadger1999> k
16:32:57 <tibbs> We're also going to have to figure out what to do on F13-F15.
16:33:05 <tibbs> Since this is an F16-only draft.
16:33:22 * abadger1999 just needs to check whether he's right about %{_mingw_configure "--disable-xlib" "--enable-win32"} vs %_mingw_configure --disable-xlib --enable-win32
16:34:09 <abadger1999> Normally we have both in one document with the changes between versions pointed out.
16:34:40 <spot> abadger1999: okay, can you update the ticket with any proposed changes once you confirm the macro?
16:34:43 <abadger1999> this may be an extensive reworking that we can just have two copies that point at each other, though.
16:35:12 <abadger1999> spot: Provided it's in the package... or we can have epienbro test.
16:35:46 <abadger1999> spot: The only gotcha I know about with macros and arguments is that %{macro} arg doesn't work -- have to use: %macro arg instead.
16:36:25 <abadger1999> I suspect  he tested %{macro} arg, found it didn't work, and then tried %{macro "arg"} without knowing about %macro arg
16:36:53 <spot> abadger1999: okay, add a summary of the concern to the ticket?
16:36:58 <abadger1999> Will do.
16:37:14 <abadger1999> I'll let you add your stuff first so trac doesn't eat our edits.
16:37:28 <spot> abadger1999: yeah, too late, rwjones already ate mine once. ;)
16:37:34 * spot LOOOVES trac
16:37:36 <abadger1999> heh
16:38:22 <gholms|work> You guys copy and paste your edits to gedit or something before updating tickets, right?
16:38:30 <gholms|work> Then you don't have to re-type everything.
16:38:59 <spot> okay, my update is on the ticket
16:39:08 <spot> lets move on
16:39:13 <spot> #topic Octave - https://fedorahosted.org/fpc/ticket/61
16:39:44 <spot> The only remaining item for this one was whether we wanted Orion to patch octave to not misuse %{_libexecdir}
16:40:06 <spot> After thinking about this, I think I would prefer that it not misuse _libexecdir, even if that means he has to carry a patch.
16:40:34 <spot> His patchset isn't very big.
16:41:11 <tibbs> I tend to agree.
16:41:14 <spot> Does anyone feel strongly in the other direction?
16:41:57 <Rathann> no, I agree too
16:42:05 <geppetto> no disagreement here
16:42:22 <spot> okay, so lets take a vote on the draft with the libexecdir changes applied
16:42:23 <racor> I tend to agree as well
16:42:38 <spot> +1
16:42:40 <Rathann> +1
16:42:53 <SmootherFrOgZ> +1
16:43:07 <racor> +1
16:43:18 <abadger1999> +1
16:43:24 <tibbs> +1
16:44:23 <spot> rdieter, geppetto, if you'd like to vote for the record, now is the time
16:44:42 <rdieter> +1
16:45:30 <spot> #action Octave draft passed (with changes to use %{_libdir} instead of %{_libexecdir}) (+1:7, 0:0, -1:0)
16:45:34 <geppetto> +1
16:45:47 <geppetto> blah … had it in the buffer, but hadn't pressed return :)
16:45:49 <spot> geppetto: i'll add your vote in the ticket change
16:45:57 <geppetto> no problem
16:47:18 <spot> okay, those are the big items on my todo list for today.
16:47:41 <spot> systemd is ... still waiting on lennart to get back to me about the bug i ran into while testing the scriptlets
16:48:18 <tibbs> Did we need to talk about the Perl thing?
16:48:26 <abadger1999> On systemd note, I talked to adamw about testing.
16:48:28 <spot> I'd like to hear back from mmaslano about why the perl @INC changes are useful before we discuss them further
16:48:53 <abadger1999> He asked if it would be a one-off (like a test day) or a recurring thing (like acceptance tests for a release/autoqa)
16:48:55 <tibbs> My impression is that they're trying to balance some RHEL requirements.
16:48:58 <spot> because i'm not sure what benefit they give us, and they will cause a massive change, especially for external packages.
16:49:15 <abadger1999> and he also showed me the templates they use for organizing test cases.
16:49:33 <spot> literally every single perl package in Fedora will need to be edited and rebuilt to accomodate this, when the end result is identical.
16:49:41 <tibbs> Yes.
16:49:42 <abadger1999> I'll try and get my test proceedure into that -- but a lot of the organizing of a table of tests will still fall on us.
16:49:55 <spot> I'm inclined to not make pointless changes with such high impact.
16:49:59 <tibbs> I'd really like to get some picture of what actually benefits from this change.
16:50:10 <tibbs> But I just can't think of anything.
16:50:11 <spot> But i'd like to know what the benefits would be before we jump to too many conclusions.
16:50:45 <spot> abadger1999: cool, hopefully my work can be converted at some point in the near future.
16:50:56 <spot> abadger1999: remind me if i don't remember to ask you directly about that.
16:51:17 <spot> so... it is Open Floor time
16:51:20 <spot> #topic Open Floor
16:51:27 <tibbs> As an aside, I'm glad the RH Perl folks have put this before the committee.
16:52:18 * spot reminds rdieter to look into ticket #48
16:52:27 <tibbs> I was just going to ask about thati.
16:53:25 * rdieter will be travelling this weekend, probably with some free time sitting around to finally do #48
16:53:39 <spot> from my perspective, updating the macros to their current values and removing the VERBOSE=1 item are both "minor change" items that do not require a vote
16:53:51 <tibbs> I agree.
16:54:01 <spot> anything more in depth than that, perhaps, but if thats all, just make those changes and close the ticket.
16:54:12 <rdieter> good, will do
16:54:38 <abadger1999> +1 for that sentiment
16:54:38 <spot> okay, if there are no other topics for the open floor, i will close out the meeting in 3 minutes.
16:54:48 <Rathann> nothing from me
16:54:51 <tibbs> Should we talk about changing the time?
16:55:18 <spot> tibbs: we can try to do a "whenisgood" for this meeting to see if there is a better time
16:55:19 * Rathann is fine with current time
16:55:28 <tibbs> I'm fine with either time.
16:55:46 <geppetto> I'm fine with it
16:55:46 <spot> i will set it up just to see what feedback we get.
16:55:47 <rdieter> fine either way too
16:55:53 <tibbs> FESCo was talking about moving, so one committee would get bumped if they do.
16:56:24 * abadger1999 fine with time
16:58:05 <tibbs> Personally I would prefer not changing anything but racor said that he has issues with it now that he's on DST.
17:00:23 <racor> with the DST shift the meeting has moved from 17:00 to 18:00 local time, making it more likely for me having to quit early or not being available.
17:01:06 <spot> okay guys
17:01:07 <spot> http://whenisgood.net/fpc
17:01:19 <spot> please take a moment and select all the times that will work for you
17:01:51 <spot> we'll see if any better fits reveal themselves. :)
17:02:03 <spot> and with that, i think we're done for today.
17:02:06 <spot> thanks everyone.
17:02:09 <spot> #endmeeting