15:02:27 <spot> #startmeeting Fedora Packaging Committee
15:02:27 <zodbot> Meeting started Wed Oct 19 15:02:27 2011 UTC.  The chair is spot. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:02:27 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
15:02:30 <spot> #meetingname fpc
15:02:30 <zodbot> The meeting name has been set to 'fpc'
15:02:33 * Smoother1rOgZ here\
15:02:33 <rdieter> yo
15:02:49 <spot> gimme one sec to get my act together and minimize these webpages
15:04:23 <abadger1999> spot: That's why lawyers get paid so much.   Every 100 words reduces their life by 1 minute.
15:04:39 <spot> abadger1999: i believe it!
15:04:47 <spot> okay, lets start with 108
15:05:02 <spot> #topic Devel Packages Clarification - https://fedorahosted.org/fpc/ticket/108
15:05:32 <spot> i wrote a slightly longer draft last week
15:05:44 <spot> https://fedoraproject.org/wiki/TomCallaway/Devel_Packages_Draft
15:06:59 <abadger1999> Looks good to me. +1
15:07:09 * spot is +1 on his own draft
15:07:22 <Smoother1rOgZ> +1 from me.
15:07:48 <tibbs|h> Seems OK to me, though it does seem odd to say "There are some notable exceptions" and then list exactly one.
15:08:11 <spot> tibbs|h: thats just me future proofing. I tried to come up with another one, but couldn't.
15:08:26 <abadger1999> The shared library names section of this might be helpful; but it might just be more information. http://tldp.org/HOWTO/Program-Library-HOWTO/shared-libraries.html
15:08:35 <racor> +1, but i don't like the section referring to gcc.
15:08:37 <abadger1999> I'll link it to the ticket in case this ever comes up again
15:09:13 * spot sees +4 on the table
15:09:54 <tibbs|h> Maybe just mention compiler systems in general?
15:09:56 <abadger1999> Maybe change that sentence to * compilers often include development files in the main package because compilers are themselves only used for development purposes.
15:10:08 <abadger1999> , thus, a split package model does not make any sense.
15:10:30 <spot> abadger1999: yeah, i like that
15:11:20 * spot makes that edit
15:11:20 <rdieter> sorry, +1
15:11:34 <rdieter> distracted for a few minutes there
15:11:40 <spot> rdieter: no worries
15:12:04 <spot> we're at +5, if limburgher or tibbs|h want to vote for the record
15:12:30 <tibbs|h> +1
15:13:03 <spot> #action Draft approved (+1:6, 0:0, -1:0)
15:13:17 <spot> There is a corresponding change to also reflect this in the Review Guidelines
15:13:44 <spot> see the last two comments in ticket 108
15:14:11 <spot> if anyone is opposed to that change, speak now. :)
15:14:20 <abadger1999> <nod> that lookes good to me.
15:15:03 <tibbs|h> Sure, looks OK.
15:15:32 <limburgher> +1, I like it.
15:15:39 <spot> okay, moving on
15:15:53 <racor> abadger1999: the purpose of *-devel packages is to provide a split between "run-time" and "devel". This kind of split doesn't make much sense in case a package is "development" only.
15:16:05 <abadger1999> racor: Right.
15:16:26 <spot> #topic Permit essential packages which are useful only on Secondary Architectures to be included in Fedora - https://fedorahosted.org/fpc/ticket/110
15:17:00 <spot> IMHO, this proposed change is obviously correct, and reflects the reality we have today.
15:17:08 <racor> abadger1999: ... i don't see much use in emphasizing gcc
15:17:33 <abadger1999> racor: Correct again.
15:18:09 <tibbs|h> Yes, banning secondary-only arch packages doesn't seem to be intentional.
15:18:16 <spot> So, +1 from me.
15:18:20 <tibbs|h> +1
15:18:35 <abadger1999> I'd s/only compile and are useful/only are useful/
15:18:42 <abadger1999> +1 with that change.
15:18:54 <Smoother1rOgZ> +1. I see no blocker here
15:19:22 <limburgher> +1
15:19:35 <spot> abadger1999: thats not in the guideline, thats just descriptive text around the proposal
15:19:53 <abadger1999> Ah my bad.
15:19:56 * abadger1999 learns to read
15:19:58 <abadger1999> :-)
15:20:05 <abadger1999> unconditioned +1
15:20:35 <spot> okay, we're at +5. racor, rdieter, if you want to vote for the record...
15:20:43 <rdieter> +1
15:21:35 <spot> #action Draft approved (+1:6, 0:0, -1:0)
15:22:16 <spot> #topic Precompiled windows programs exception - https://fedorahosted.org/fpc/ticket/111
15:22:36 <spot> https://fedoraproject.org/wiki/Windows_loaders_packaging_draft
15:23:07 <racor> Sorry, was distracted: +1 to #110
15:24:03 <abadger1999> This one came up wrt python shipping some pre-compiled code to unzip and byte compile python byte code when it builds windows installers for third-party modules
15:24:10 <spot> so, even though this whole arrangement makes me a bit queasy
15:24:52 <abadger1999> We thought we found similar stuff in a python-setuptools installer as well but determined that that one was invoking python via a subprocess so wasn't affected.
15:25:33 <abadger1999> I wrote this since its the only way I found to make it work but... if someone wantsto discuss and try to find another solution, that's fine with me too.
15:26:56 <spot> If a package provides Windows executables (with corresponding source code), but those executables link to multiple Windows DLLs that we do not ship and thus cannot be rebuilt from source, you may be allowed to ship the pre-compiled Windows binary from upstream. See Precompiled Windows Programs for details.
15:27:07 <spot> ^^^ I prefer this short version
15:27:17 <tibbs|h> Do we really want to go down this road?
15:27:38 <spot> I just wonder whether there is really a benefit to having these things.
15:28:12 <rdieter> this MinGW stuff seems to be turning into a deep rats nest (though that's largely a policy issue...), otherwise, +1 to spot's short version
15:28:17 <tibbs|h> I mean, how does this not open us to just shipping precompiled windows programs intended to be run under wine?
15:28:24 * abadger1999 makes spot's change
15:28:39 <abadger1999> The benefit is to users.
15:29:07 <racor> I will vote against this proposal.
15:29:11 <abadger1999> Specifically, users who are developers trying to ship python modules for their users who are on Windows.
15:29:46 <abadger1999> mingw is kinda orthogonal to this -- without mingw, we'd have no choice but to ship the files.
15:29:48 <spot> abadger1999: i'm just not sure what the end-user on Fedora gets out of a windows binary
15:30:07 <spot> (built from source or otherwise)
15:30:27 <abadger1999> spot: the user of Fedora is a developer of pyhton modules who wants to ship their module to Windows users.
15:30:28 <tibbs|h> I can understand why windows binaries can be useful.
15:30:40 <abadger1999> they run python setup.py bdist_wininst
15:30:44 <racor> abadger1999: You want to allow prebuild Windows binaries, but disallow prebuild Linux? To me this is absurd
15:30:45 <abadger1999> and it works.
15:30:50 <tibbs|h> But I'm not sure that somehow that gets us away from the whole building from source thing.
15:30:55 <spot> abadger1999: well, they're not really a "user" in the traditional sense. they're developing for Windows on Fedora.
15:31:10 <tibbs|h> I mean, there are linux things that are useful and for which we have the source, but we cannot build them because the compiler is non-free.
15:31:17 <tibbs|h> Are those OK too because they benefit users?
15:32:11 <abadger1999> spot: Since python is cross-platform... they're developing for Linux and Windows both.
15:32:25 <racor> tibbs|h: If this goes in, we must allow java, python etc. binaries, too.
15:32:31 <spot> i think we would need to narrow this exception down quite a bit
15:32:38 <limburgher> at least.
15:32:56 <abadger1999> tibbs|h: All good points.
15:33:12 <abadger1999> geppetto: hey, we're discussing https://fedorahosted.org/fpc/ticket/111
15:33:19 <spot> in the specific python case that you hit, why exactly couldn't it be built from the source?
15:33:24 * geppetto trys to catch up
15:33:49 <abadger1999> spot: Because of the C library and dynamic loader stupidity on windows.
15:34:18 <spot> abadger1999: be specific, it was linked to the Windows C library, and rebuilding it would cause it to be linked to the MinGW C lib?
15:34:43 <abadger1999> itOkay -- Let's say you get python and libpython from ActiveState.com
15:35:21 <abadger1999> they've linked libpython against the windows CRT.dll (windows equiv of libc) at version 09.
15:35:43 <abadger1999> The latest version of the CRT.dll on your windows version is version 10.
15:36:09 <abadger1999> You go to install the python-foo module from a wininst that the devloper created on Fedora.
15:36:53 <abadger1999> if these files were recompiled using mingw, the wininst will simply ask for the CRT.
15:37:05 <abadger1999> So the windows loader will load the latest version of the CRT.
15:37:35 <abadger1999> When the wininst gets to the place where it calls out to libpython, the windows loader will load the version 09 of the CRT.
15:37:42 <abadger1999> Now hilarity starts to ensue.
15:37:46 <spot> okay
15:37:57 <abadger1999> libpython tries to do things like write to stdout
15:38:15 <spot> so the issue here is that in situations where there is a windows executable which is launched by a native-windows runtime
15:38:24 <spot> the CRTs might conflict
15:38:39 <kalev> abadger1999: any chance you could bring this up on the fedora-mingw mailing list first before voting on the exception?
15:38:45 <abadger1999> due to stdout already having been defined in the CRT version that was loaded for the wininst, the CRT in libpython doesn't get to write to stdout.
15:38:46 <spot> but isn't it possible that the prebuilt might conflict with the selected runtime _anyways_ ?
15:39:08 <spot> or is that just not as likely?
15:39:24 <abadger1999> kalev: Absolutely.  In which case, this would be fact finding for what questions we need answered.
15:39:39 <geppetto> abadger1999: Also doesn't that mean we can't ever build any mingw binaries?
15:39:48 <abadger1999> spot: So the prebuilt is statically linked to a specific CRT
15:40:13 <spot> abadger1999: what if it is linked to 10? and the libpython is at 09?
15:40:25 <abadger1999> the way the windows dynamic loader works, the static stuff will not conflict with the dynamically loaded CRT.
15:40:35 <abadger1999> why they built this thing this way, I don't know.
15:40:45 <abadger1999> but apparently, that's how it works.
15:40:55 * spot wipes up the puddle of blood dripping from his brain
15:41:10 <spot> okay, but this is only a concern when there is a runtime in play to conflict with it
15:41:11 <limburgher> spot: I think some of that might be mine. . .
15:41:21 <abadger1999> geppetto: I didn't want to open more doors than I had to but... there are wider ramifications, yes.
15:41:23 <spot> a normal binary built by mingw doesn't hit this case
15:41:24 <spot> right?
15:41:36 <abadger1999> geppetto: If we control all the libraries that the program links to, we should be okay.
15:42:01 <geppetto> Ok … so why do we not control python?
15:42:31 <spot> abadger1999: okay, so binaries that are built on Fedora are assumed to be 100% linked to Fedora bits (or doing dynamic requests of windows libraries)
15:43:01 <abadger1999> spot: yep.
15:43:21 <spot> in cases where those binaries are loaded by a runtime that we cannot control (such as ActiveState python), then we grant this exception
15:43:36 <kalev> I'd like to point out that Fedora MinGW toolchain ships a lot of stubs, which are needed to use the Microsoft CRT
15:43:39 <spot> this would rule out 99% of pre-built windows binaries
15:44:07 <kalev> it's possible to link against the stubs, but not ship the full CRT.
15:44:49 <geppetto> I'm somewhat confused … are we shipping things that require ActiveState python?
15:45:03 <spot> geppetto: no, but they require some sort of windows python runtime
15:45:05 <abadger1999> geppetto: I think we might be able to get the complete python stack packaged for Fedora MinGW and then we'd be able to recompile the wininst binaries statically.  That would inflate their size dramatically, though... not sure if it's feasible or not.
15:45:32 <geppetto> abadger1999: Why not dynamically?
15:46:11 <geppetto> It seems like we are shipping stuff which requires python without having python … so I'd be tempted to say, stop doing that
15:46:14 <kalev> should certainly discuss it on the mingw list, I don't think anyone involved is even aware of the Python packaging efforts
15:46:17 <abadger1999> geppetto: because if they're linked dynamically, Windows gets to choose which library is loaded on the end user's  system.  And that's why we're in this mess.
15:46:53 <geppetto> abadger1999: And there's no rPath like thing … where we can tell Windows to prefer our libpython for our apps?
15:46:53 <abadger1999> One library may request a version of the CRT that is not the same as another library (or our wrapper's) requested version of the CRT.
15:47:20 <abadger1999> geppetto: If it's not linked statically, then our libpython probably isn't installed on Windows.
15:48:00 * spot thinks at this point, abadger1999 should take this to the mingw folks, and I would personally recommend that when it comes back for review again, that the exception be as narrow as possible, perhaps even moving to a whitelist of approved exceptions.
15:48:21 <abadger1999> spot: Sure.  But what questions do we want to ask?
15:48:33 <abadger1999> I can fact check the exception with the MinGW folks.
15:48:48 <spot> abadger1999: i don't think there are specific questions for the mingw folks
15:48:53 <abadger1999> But it sounds like we want more than just verification that the facts are correct.
15:48:55 <spot> just fact checking and informational stuff
15:49:01 <abadger1999> like
15:49:19 <abadger1999> MinGW folks, can you wave your wand and make Windows not be so brain-numbingly icky?
15:49:23 <spot> hehehe
15:49:25 <abadger1999> :-)
15:49:29 <spot> for me, it is more like this:
15:49:40 <spot> the python situation you've described is far more specific than the draft
15:49:57 <spot> the draft just says ":What this means for us is when the software we're packaging is intended to run on Windows end user's systems and the software links against multiple libraries then recompiling it locally will lead to code which may have errors when it finally gets to the Windows user's system simply because the code uses common functions from the C library."
15:50:10 <spot> I could fly a space shuttle through that hole.
15:50:30 <spot> When really, it could be narrowed to something like:
15:50:32 <limburgher> While Hagrid wing-walked on it.
15:51:15 <spot> If, and only if the software requires a runtime on Windows to execute and it is likely that that runtime will load a conflicting CRT, then and only then may a pre-built executable be used.
15:52:00 <spot> Exceptions that meet this criteria are:
15:52:03 <spot> * python-foo
15:52:06 <spot> * python-bar
15:52:26 <spot> If you feel your package contains software that meets this exception, open a FPC ticket here.
15:52:42 <spot> abadger1999: do you understand?
15:52:50 <geppetto> And that still feels like a pretty big hole
15:52:50 <kalev> I am still catching up on all this, but I'm pretty sure the current MinGW toolchain we have is capable of linking against different versions of the CRT, if needed
15:53:02 <abadger1999> kalev: That's not the issue really.
15:53:22 <abadger1999> kalev: the issue is what the windows dynamic loader does when the software is installed on a Windows system.
15:53:50 <kalev> sure, but how does Windows dynamic loader behaviour mean that we can't build it from source?
15:53:56 <spot> geppetto: i think it really only affects arch-specific (and thus, compiled) code for interpreted languages like python or perl.
15:54:42 <kalev> there are means to link against the same C runtime that the upstream binary python distribution uses, AFAIK
15:54:50 <kalev> e.g. we currently have:
15:54:51 <abadger1999> spot: I do. I could limit the scope to things that create software installers which link to other libraries somehow.
15:54:53 <spot> kalev: which one? all of them? :)
15:55:00 <kalev> /usr/i686-pc-mingw32/sys-root/mingw/lib/libmsvcr70.a
15:55:00 <kalev> /usr/i686-pc-mingw32/sys-root/mingw/lib/libmsvcr70d.a
15:55:00 <kalev> /usr/i686-pc-mingw32/sys-root/mingw/lib/libmsvcr71.a
15:55:00 <kalev> /usr/i686-pc-mingw32/sys-root/mingw/lib/libmsvcr71d.a
15:55:00 <kalev> /usr/i686-pc-mingw32/sys-root/mingw/lib/libmsvcr80.a
15:55:02 <kalev> /usr/i686-pc-mingw32/sys-root/mingw/lib/libmsvcr80d.a
15:55:05 <kalev> /usr/i686-pc-mingw32/sys-root/mingw/lib/libmsvcr90.a
15:55:07 <kalev> /usr/i686-pc-mingw32/sys-root/mingw/lib/libmsvcr90d.a
15:55:10 <kalev> /usr/i686-pc-mingw32/sys-root/mingw/lib/libmsvcrt.a
15:55:12 <spot> kalev: at once? :)
15:55:13 <kalev> /usr/i686-pc-mingw32/sys-root/mingw/lib/libmsvcrtd.a
15:55:16 <abadger1999> spot: for political rather than technical reasons.  I'm totally fine with that.
15:55:26 <kalev> no, only one at a time
15:55:29 <abadger1999> Is that what other people would like me to pursue?
15:55:49 <spot> kalev: but, if i understand this right, we don't know which python runtime people will be using, thus, we don't know which CRT
15:56:13 <kalev> could be, I am not really up to speed here
15:56:14 <abadger1999> spot: correct.
15:56:35 <spot> abadger1999: i think we're on the same page. the narrower the exception, the more likely i am to vote for it. :)
15:56:55 <geppetto> abadger1999: Also … ask them about compiling the python stack statically
15:56:55 <abadger1999> so then libpython on the windows system is linked against a different CRT than what we've linked our wininst to.  and that's when problems arise.
15:57:13 * spot notes that we're almost out of time
15:57:35 <abadger1999> geppetto: okay -- but that is also a feasibility question for python maintainer/developers of modules for python.
15:57:39 <spot> i'm tabling this one to give the mingw folks some time to understand it and chew on it with abadger1999, and for abadger1999 to narrow the exception
15:57:44 <abadger1999> because of the inflation of the wininst size.
15:57:56 <abadger1999> Sounds good.
15:58:00 <limburgher> Agreed.
15:58:06 * abadger1999 will update ticket with our goals
15:58:14 <spot> any burning issues for the next, oh, 75 seconds?
15:58:33 * spot knows we didn't get to binutils, we'll lead off with it next week
15:58:59 <limburgher> spot: That's OK, the binutils merge review isn't going anywhere. :)
15:59:07 <spot> limburgher: thats for sure.
15:59:20 <spot> okay, thanks everyone.
15:59:24 <spot> #endmeeting