17:02:54 <geppetto> #startmeeting fpc
17:02:54 <zodbot> Meeting started Thu Feb  5 17:02:54 2015 UTC.  The chair is geppetto. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:02:54 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
17:02:54 <geppetto> #meetingname fpc
17:02:54 <zodbot> The meeting name has been set to 'fpc'
17:02:54 <geppetto> #topic Roll Call
17:02:56 <mbooth> FPC meeting now?
17:03:06 <geppetto> #chair mbooth
17:03:06 <zodbot> Current chairs: geppetto mbooth
17:03:06 <orionp> hello
17:03:10 * tomspur is here
17:03:10 <geppetto> #chair orionp
17:03:10 <zodbot> Current chairs: geppetto mbooth orionp
17:03:14 <geppetto> #chair tomspur
17:03:14 <zodbot> Current chairs: geppetto mbooth orionp tomspur
17:03:17 * racor is here
17:03:22 <geppetto> #chair racor
17:03:22 <zodbot> Current chairs: geppetto mbooth orionp racor tomspur
17:04:28 <geppetto> limburgher Rathann SmootherFr0gZ spot tibbs|w: FPC ping
17:04:36 <tibbs|w> Howdy
17:04:45 <geppetto> #chair tibbs|w
17:04:45 <zodbot> Current chairs: geppetto mbooth orionp racor tibbs|w tomspur
17:05:12 <geppetto> Rathann is at devconf, yeh?
17:05:28 <tibbs|w> He said he wouldn't be here, yeah/.
17:05:35 * geppetto nods
17:05:48 <geppetto> Schedule: https://lists.fedoraproject.org/pipermail/packaging/2015-February/010454.html
17:06:03 <geppetto> #topic #494 	Python3 __pycache__ directory
17:06:09 <geppetto> https://fedorahosted.org/fpc/ticket/494
17:06:55 <geppetto> tomspur and tibbs|w seem to have looked at this already, either of you want to say anything?
17:07:10 <tibbs|w> There's a draft in the last comment.
17:07:15 <tibbs|w> https://fedoraproject.org/wiki/User:Tibbs/PycacheDraft#Byte_compiling
17:07:16 * geppetto nods
17:07:20 <tibbs|w> https://fedoraproject.org/w/index.php?title=User%3ATibbs%2FPycacheDraft&diff=402243&oldid=402019
17:08:05 * tomspur tries to find a new diff as I did a change to that page
17:09:35 * SmootherFrOgZ here
17:09:39 <geppetto> one thing I've wondered … if the packages have the .py and .pyo files … do they need the .pyc files?
17:09:54 <geppetto> #chair SmootherFrOgZ
17:09:54 <zodbot> Current chairs: SmootherFrOgZ geppetto mbooth orionp racor tibbs|w tomspur
17:10:08 <tomspur> https://fedoraproject.org/w/index.php?title=User%3ATibbs%2FPycacheDraft&diff=402245&oldid=402019
17:10:59 <geppetto> tomspur: That looks very similar to tibbs's version … what's the diff. between them?
17:11:09 <tibbs|w> I flubbed two macros in my version.
17:11:26 <geppetto> https://fedoraproject.org/w/index.php?title=User%3ATibbs%2FPycacheDraft&diff=402245&oldid=402243
17:11:36 <tomspur> geppetto: the "site-packages" is included in the macro, so I removed it after the macro
17:11:40 * geppetto nods
17:12:03 <geppetto> so … it looks fine to me
17:12:12 <tibbs|w> Anyway, I guess +1 to my draft, though I'm not the most expert python person.
17:12:18 <geppetto> tibbs: Why did you say it was a strawman draft?
17:12:28 <tibbs|w> Just semantics, I guess.
17:12:33 * geppetto nods
17:12:40 <tibbs|w> I just put it up there for people to pick apart.
17:12:54 <orionp> made a small wording change - https://fedoraproject.org/w/index.php?title=User%3ATibbs%2FPycacheDraft&diff=402764&oldid=402245
17:13:08 <mbooth> I'm happy with the guidelines (so +1) but I wonder why there could be possibly multiple __pycache__ dirs ... i.e. %{python3_sitearch}/__pycache__ and %{python3_sitearch}/some_extension/__pycache__
17:13:22 <tomspur> +1 here also
17:13:39 <tomspur> mbooth: the __pycache__ directory will be in the same folder where the *.py files are
17:13:47 <orionp> I'm +1
17:14:04 <tomspur> mbooth: %{python3_sitearch}/foo.py will be in the former and %{python3_sitearch}/some_extension/foo.py in the later directory
17:14:22 <geppetto> Ok, that's +5 … racor and SmootherFrOgZ you want to vote?
17:14:28 <tibbs|w> I guess the only thing I had a question about is whether it's really worth excluding the toplevel __pycache__ directory.
17:14:43 <SmootherFrOgZ> +1 from me
17:14:54 <geppetto> tibbs: I assume python will own that, right?
17:14:55 <mbooth> tomspur: Aha, I see so there's no name munging to get all bytecode in one place
17:15:00 <tibbs|w> geppetto: Yes, it does.
17:15:14 <tibbs|w> mbooth: Yeah, it just keeps a bunch of separate __pycache__ directories.
17:15:23 <geppetto> I guess nothing else should then … but I doubt it's a big problem if they do
17:15:36 <tibbs|w> Basically, everywhere you used to have a directory with *.py[oc] you now have a __pycache__ directory.
17:15:50 <tibbs|w> geppetto: There are a bunch of packages that do own them, but it's not really a big deal.
17:15:58 <geppetto> yeh
17:16:01 <tibbs|w> Anyway, it doesn't really complicate the guidelines to say that.
17:16:10 * geppetto nods
17:16:14 <tibbs|w> And I'm a big fan of just expecting complaints if I got something wrong.
17:16:21 <geppetto> :)
17:16:44 <tibbs|w> So I guess we're done?
17:16:47 <abadger1999> tibbs|w: I agree, not a really big deal (if python didn't own it it would fall under the every-package-that-uses-owns-it similar to /etc/bash.completion.d)
17:17:17 <tibbs|w> abadger1999: Thanks for that.  You're certainly one of the python experts I'd want to get input from.
17:17:49 <geppetto> #action Policy for py3k __pycache__ dir. by tibbs with edits by tomspur/orionp (+1:6, 0:0, -1:0)
17:18:04 <tibbs|w> Cool, I'll write it up.
17:18:20 <geppetto> abadger1999: one thing I've wondered … if the packages have the .py and .pyo files … do they need the .pyc files?
17:18:30 <geppetto> abadger1999: And/or does py3k fix that?
17:18:50 * geppetto figures he might as well ask you, while you're here
17:19:03 <tibbs|w> The nice thing is that if we just include whatever/__pycache__/ we don't have to care.
17:19:10 <abadger1999> geppetto: they're used in different casees.
17:19:20 <tibbs|w> Python can drop those or add others and the packaging wouldn't notice.
17:19:22 <abadger1999> .pyc is the default if it exists
17:19:40 <abadger1999> .pyo is only if you invoke python as python -O (or python -OO)
17:20:03 <tibbs|w> python needs -O9999 for fasterer performance.
17:20:05 <geppetto> abadger1999: that's for building, right? I thought .pyo was always used first if it exited
17:20:08 <abadger1999> .py is the fallback if those don't exist or those were built from an earlier version of the .py
17:20:16 * geppetto nods
17:20:22 <abadger1999> nope, .pyc's should be used first.
17:20:33 <abadger1999> they're designed to act like caches.
17:21:14 <geppetto> ok, weird
17:21:16 <abadger1999> python will create byte code from the .py source at runtime.  If the .pyc exists then it's taken to be hte pre-byte-compiled version.
17:21:25 * geppetto nods
17:21:37 <abadger1999> the byte code is different epending on whether you asked python to run in "optimization mode" or not.
17:22:03 <geppetto> interesting
17:22:17 <abadger1999> But optimization mode (-O) is not a very big optimization and -OO is also not a big optimization but changes the runtime behaviour in ways that could break code.
17:22:51 <abadger1999> so... .pyc and .pyo are not interchangable with each other.
17:22:59 <abadger1999> I guess that's the tldr; summary :-)
17:23:12 <geppetto> #topic #497 	Clean up BuildRequires section; don't try to define the minimal build env
17:23:14 <geppetto> https://fedorahosted.org/fpc/ticket/497
17:23:19 <tibbs|w> Ugh.
17:23:23 <geppetto> abadger1999: thanks, TIL :)
17:23:26 <tibbs|w> This really needs to be discussed on-list.
17:23:50 <geppetto> I'm happy to defer it for a bit, if you want to start a discussion on list
17:24:15 <tibbs|w> Perhaps we could talk about whether the rpm-rpmdevelrpms stuff is relevant any more.
17:24:28 <tibbs|w> I've never used it at all, and it's a pretty huge block of stuff that I don't think needs to be there.
17:25:00 <tibbs|w> It's unconnected with the hard issue there, but since they're both in the same section I just wrote the changes altogether.
17:25:48 <tibbs|w> But if nobody has an opinion, I need to take this to the list.  If anyone wants to express any opinion about what's there, I'm happy to listen.
17:26:17 <geppetto> rpmdev-rmdevelrpms this bit?
17:26:21 <tomspur> tibbs|w: you mean the removal of the rpmdev-rmdevelrpms section?
17:26:25 * geppetto has never heard of it, or used it
17:26:27 <mbooth> tibbs|w: Agree, I didn't know the existance of rpmdev-rmdevelrpms until reading this
17:26:28 <tibbs|w> tomspur: Yes.
17:26:42 <tibbs|w> I don't even know if the package is still in the distro.
17:27:11 <mbooth> I would not help for e.g. Java packages anyway
17:27:14 <abadger1999> it's part of rpmdev so it is in the distro
17:27:15 * gholms is pretty sure it's part of rpmdevtools
17:27:19 <tibbs|w> Everyone with fedpkg installed also has mock and koji.  We shouldn't be telling them to use anything else (my opinion, of course).
17:27:33 * orionp really thinks we should standardize on mock - as that is what we use in the builders
17:27:35 <tomspur> Yeah... the fedora-review tool builds it in mock where you need to have the correct dependencies or it fails
17:27:40 <geppetto> I'm happy to +1 removal of that … yeh, mock is the thing I'd recommend to use to find missing BR
17:27:42 * abadger1999 hasn't used rmdevelrpms since pre-FC6 days
17:28:10 <tomspur> Isn't a link to a scratch build mandatory? Should be enough to find the BRs
17:28:25 <tibbs|w> What I can do is present a draft for that while the difficult problem gets discussed on-list.
17:28:44 <geppetto> yeh, the packager should do a scratch build, and the reviewer too IIRC
17:29:00 <geppetto> tibbs|w: sounds fine
17:29:06 <tibbs|w> I'll do that.
17:29:34 <geppetto> want to do it quickly now (as it's just rm'ing lines) … or wait until next week for that?
17:29:59 <mbooth> I'm +1 to just removing that section :-)
17:30:42 <tibbs|w> I'm mildly distracted at the moment, so next week unless people just want to +1 a nuke.
17:30:52 <tibbs|w> And I'll +1 that.
17:30:54 <tomspur> +1 for the nuke :)
17:30:55 <geppetto> +1
17:31:01 <orionp> +1
17:31:01 <SmootherFrOgZ> +1
17:31:10 <geppetto> tibbs: Well that's +5 already :)
17:31:23 <tibbs|w> Cool.  I'll do that as part of the writeups.
17:31:32 <tibbs|w> And then regen my difficult draft.
17:31:43 <geppetto> #action Nuke rpmdev-rmdevelrpms section (+1:5, 0:0, -1:0)
17:32:04 <geppetto> #topic #498 	Seeking guidance: Apps using default Python in Fedora vs. EPEL
17:32:08 <geppetto> https://fedorahosted.org/fpc/ticket/498
17:32:50 <tomspur> The whole problem is: Fedora didn't switch to python3 yet, but encourages to use it for applications, but EPEL doesn't have python3
17:33:25 <tibbs|w> I am in general happy with letting EPEL and Fedora choose their own separate courses.
17:33:42 <tibbs|w> And EPEL could "easily" have python3, I guess.
17:33:52 <tomspur> -> I'd encourage people to build apps for Fedora if they like, but if they choose to switch to python3 whenever /usr/bin/python is switched to it, then they will be using python2 for apps still.
17:34:15 <geppetto> yeh, although the py2 is still default but please use py3 … is kind of crack smoking
17:34:20 <geppetto> but … *shrugs*
17:34:47 <geppetto> I think it'll be good to have __python point to py3 when it is the default
17:35:08 <geppetto> but doing so before then seems insane
17:35:43 <geppetto> And I don't see how anything introducing new macros will help, because they won't be there on EPEL anyway
17:35:44 <tibbs|w> tomspur had a simple proposal in there.
17:36:14 <geppetto> comment 5?
17:36:18 <tibbs|w> Yeah.
17:36:32 <tibbs|w> But really, I'm kind of unclear on the core issue.
17:36:32 <geppetto> yeh, that seems sane … but I don't see how it solves the problem
17:36:33 <abadger1999> geppetto: if someone talks to dgilmore, new macros could probably be added.  we've added packages to the minimal BR in the past for new macros.
17:36:53 <tibbs|w> Or really, I don't even know what the core issue is here.
17:37:25 <tibbs|w> If it's a question of introducing stuff that hides the spaghetti needed to support Fedora and EPEL in one spec, then I'd be all for it.
17:37:28 <geppetto> tibbs: AIUI the issue is that people want to build a py3 package on f21 and py2 package on el7 … but f21 is still default py2
17:37:52 <geppetto> dito. s/f21/f22/ because it got bumped
17:37:52 <tibbs|w> Uh, don't have a single spec in that case?
17:37:54 <abadger1999> I think the core issue is: How do we allow packagers to package for different distro-versions that ask packagers to choose different python interpreter dependencies.
17:38:14 <tibbs|w> I really don't think we should unless there's a very simple way to do it.
17:38:22 <geppetto> abadger1999: I think f23 and el7 should be easy, just use the default macros and it'll dtrt.
17:38:32 <abadger1999> where packagers want a single spec and bkabrda wants to figure out a way to do that.
17:38:59 <abadger1999> geppetto: default macros being __python, python_sitelib?
17:39:03 <geppetto> abadger1999: yeh
17:39:07 <abadger1999> geppetto: it won't.
17:39:16 <geppetto> abadger1999: why?
17:39:17 <abadger1999> __python and python_sitelib are not currently going to change.
17:39:24 <geppetto> abadger1999: see comment 5
17:39:29 <abadger1999> I think that's part of bkarbrda's proposal in this ticket.
17:39:47 <abadger1999> geppetto: comment:5 is not sufficient.
17:40:09 <abadger1999> So there's two things;  macros and the /usr/bin/python command.
17:40:24 <geppetto> Why do we need to change the python command?
17:41:09 <geppetto> I mean tomspur seemed to think that was a good idea anyway … so I might be convinced
17:41:14 <abadger1999> tomspur also wrote: Proposal for the meeting: Don't let /usr/bin/python and %__python diverge
17:41:21 <geppetto> But that seems like a giant back compat. nightmare
17:41:41 <abadger1999> Which means that if both proposals are taken together, we can't change the macro.
17:42:13 <tomspur> You can still overwrite them in our own spec file, wasn't this the case for EPEL and python2.6 a while ago?
17:42:15 <geppetto> I'm happy to +1 comment 5 … but I don't think we should change /usr/bin/python atm. … esp. given the PEP recommendation
17:42:28 <abadger1999> right.
17:42:46 <geppetto> tomspur tibbs: What's the rationale for wanting the command to change to py3?
17:42:53 <tomspur> Yet I'm not convinced to invent just another macro while the "apps should use python3" but "python3 is not the default /usr/bin/python implementation" time
17:43:01 <tibbs|w> That PEP recommendation seems overly cautious to me, honestly.
17:43:50 <geppetto> Well, personally I would think it's a good idea even if it wasn't in the PEP … just too much stuff people will have places with "#! /usr/bin/python" that doesn't expect a new language
17:43:51 <tomspur> When python3 is the default /usr/bin/python should be python3 and %{__python}
17:44:05 <abadger1999> tomspur: so if you want to overwrite it in the spec file, I don't think that's the wording in Comment:5 .... it's more like the various strategies that bkabrda outlines in the initial ticket comments.
17:44:48 <geppetto> tibbs: You don't think sysadmins will have random /usr/bin/python scripts and be super annoyed at having to make them /usr/bin/python2 ?
17:47:46 <tomspur> abadger1999: I'd not make the %make_default_python macro part of the guideline. If people want to use it in a spec, they should copy it around where needed. The wording of in commend:5 ensures that %{__python} is not deprecated but can be used for a general switch, when people think the %make_default copying is ugly and they wait for the big switch
17:47:47 <orionp> I don't think it's the FPC's place to decide where /usr/bin/python points
17:47:59 <tibbs|w> orionp: That's definitely the case.
17:48:10 <tibbs|w> geppetto: I do, but at some point we have to change.
17:48:25 <tibbs|w> That argument won't ever go away so it's going to have to happen eventually.
17:48:50 <orionp> I'd like to have some macro that reports what the "default" python should be
17:48:55 <geppetto> meh, personally I'm happy waiting a long long time … but maybe I'm biased
17:49:19 <tomspur> orionp: isn't that %{__python} ?
17:49:23 <geppetto> orionp: __python_version seems like a fine thing to have
17:49:35 <tibbs|w> I think the distro may get to a point where for most things there's simply no python2.  Then what?  /usr/bin/python isn't even there?
17:49:42 <geppetto> tomspur: not if it always points to /usr/bin/python ;)
17:49:50 <abadger1999> tomspur: So are you withdrawing the idea that __python should match with /usr/bin/python?
17:49:50 <tomspur> :/
17:49:55 <tibbs|w> But, really, this isn't our thing.
17:50:12 <tibbs|w> Or at least, what /usr/bin/python does is not our thing.
17:50:14 <geppetto> tibbs: I think comment 5 is fine for us to vote on
17:50:21 <abadger1999> because I think the timing of when we want to switch /usr/bin/pyhton does not match with when we would want to switch applications to use pyhton3 if they're able to.
17:50:28 <tomspur> abadger1999: Not really. Maybe we have a different definition of what "default" means
17:51:01 <tibbs|w> geppetto: Even if it doesn't resolve the issue, I think it's a good idea.
17:51:26 <tomspur> abadger1999: Exactly. If applications want to use %{__python3} so be it. But defining different defaults depending if you are packaging an application or not seems like a very complicated idea
17:52:10 <geppetto> Ok … ** Proposal: Just the wording change in comment 5, from tomspur.
17:52:12 <abadger1999> tomspur: always possible -- I think on the list and in the Change discussion we've agreed that "default" means that applications that can run with pyhton3 need to be built to run with python3 instead of python2.  And that various things important to the distro (package managers, anaconda, things on the livecd) need to be built to run under python3.
17:52:13 <geppetto> +1
17:52:19 <tibbs|w> +1
17:53:12 <abadger1999> I think comment5 lacks clarity on "defualt implementation" which will need to be addressed.
17:54:08 <geppetto> Given the last sentence, I assume it to mean what package managers/anaconda/etc. run under
17:54:23 <tibbs|w> abadger1999: I guess I kind of agree.
17:54:35 <abadger1999> tomspur: I think on the list we have left what /usr/bin/python points to as separate from the "default python" discussion.
17:55:08 <tibbs|w> "distribution's default python interpreter", maybe, and then rewrite the following sentence to avoid repetition.
17:55:19 <abadger1999> geppetto: okay.  So in the F23 timeframe you would see %{__python} pointing to /usr/bin/python3 while /usr/bin/python still points at python2?
17:55:25 <geppetto> abadger1999: yeh
17:55:27 <abadger1999> k
17:55:28 <tomspur> I'm leaning to a +1 too (obviously), yet based on the hot discussion above, I guess, I should reword it and provide a proper diff for the next time...
17:56:05 <geppetto> Ok, that seems fine
17:56:20 <tomspur> bkrabrda said that he could maybe join for the first few minutes next week
17:56:29 * geppetto nods
17:57:00 <tibbs|w> Hmm, tomspur's original idea wat that /usr/bin/python and %{__python} never diverge.
17:57:14 <tibbs|w> I'm kind of getting lost here, sorry.
17:57:29 <geppetto> tibbs: Yeh, abadger1999 said that a few mins. ago
17:57:30 <abadger1999> geppetto: I'm not in love with it but I think that's a reasonable strategy... will have to do some of the sed'ing of shebang lines as churchyard talks about.
17:58:16 <geppetto> abadger1999: What needs sed/ing of #! lines, and why?
17:58:52 <tibbs|w> I think the point is that we don't want anything in the distro using /usr/bin/python.
17:59:05 <geppetto> Uh, some apps. are expecting shipping with #! /usr/bin/python … sighs
17:59:35 <tibbs|w> You know, I wonder.  Why not get Fedora entirely out of the business of deciding what /usr/bin/python is?
17:59:38 <geppetto> Yeh, I guess I don't see a good fix for that without also changing the command … and that seems bad.
17:59:39 <tibbs|w> Run it through alternatives.
17:59:57 <abadger1999> I don't think that it's as drastic as ncoghlan thinks but there will be some problems:
18:00:06 <abadger1999> Comment:6: "Unfortunately, I just realised that the core problem with the idea of letting the two definitions of the "default Python" diverge is that you wouldn't be able to use unversioned shebang lines to go with the unversioned RPM macros."
18:00:06 <geppetto> tibbs: Worst of all worlds … nobody shipping software can then rely on it being anything
18:00:18 <geppetto> abadger1999: yeh
18:00:48 <geppetto> abadger1999: it's basically the opposite problem of sysadmins. with #! lines in their scripts
18:00:53 <tibbs|w> geppetto: And they can now?  I mean, if it's not the distro's choice then anyone can change the symlink if they want.
18:01:10 <tibbs|w> Applications that actually care should never call /usr/bin/python.
18:01:11 <abadger1999> I don't think it will affect the majority of packages (because if %{__python} expands to /usr/bin/python2 then distutils based installs should rewrite the shebangs correctly)
18:01:21 <geppetto> tibbs: Yeh, you can't ship something for Fedora dn Arch say
18:01:33 <abadger1999> But there will be some software where we'll have to rewite the shebangs because the build scripts don't do it right.
18:01:42 <tibbs|w> geppetto: But you can't anyway, because we won't all change at the same time.
18:02:09 <tibbs|w> And even if we do, in F27 or whatever, F26 will still be unchanged so you can't even ship for "Fedora".
18:02:22 <abadger1999> tibbs|w: The idea is that you can if we use /usr/bin/python3
18:02:28 <tibbs|w> Right.
18:02:53 <geppetto> Yeh, as I said I'd prefer to have python == python2 for a _long_ time
18:02:58 <tibbs|w> Which is why I think that nothing actually in the distro should ever be allowed to call /usr/bin/python.
18:03:16 <geppetto> tibbs: That's not an unreasonable idea
18:03:18 <abadger1999> (/usr/bin/python2 is problematic, though -- that wasn't part of upstream's build scripts so only some distros have it (fedora, RHEL do ; macOS X, older debian do not)
18:03:20 <tibbs|w> And then just leave it up to the end user to do whatever on earth they want.
18:03:54 <geppetto> abadger1999: ugh … I didn't know that … knowing that I'm much more against changing python binary.
18:03:56 <tibbs|w> We can leave it on /usr/bin/python2 or whatever and as a distro we don't really have to care.
18:05:19 * geppetto nods
18:05:27 <tomspur> How do you want to do the python3 transition then?
18:05:38 <abadger1999> tibbs|w: I think we approved guidelines to not use /usr/bin/python but someone needs to go through the packageset and perform cleanup.
18:05:41 <geppetto> tomspur: Just change the __python macros?
18:05:51 <tibbs|w> abadger1999: I don't remember doing that.
18:05:58 <geppetto> dito.
18:06:03 <abadger1999> I can see if I can find a ticket
18:06:13 <tomspur> geppetto: So the unversioned __python and /usr/bin/python eventually diverge?
18:06:23 <geppetto> tomspur: yeh
18:06:34 <tomspur> I think that's counter-intuitive...
18:06:54 <tibbs|w> It sort of makes sense if from a packaging standpoint you pretend /usr/bin/python doesn't exist.
18:07:01 <abadger1999> https://fedorahosted.org/fpc/ticket/327#comment:9
18:07:22 <tibbs|w> And my open question there....
18:07:29 <geppetto> tomspur: See abadger1999 point above … if you want to ship something on MacOSX and Fedora, "python" is the only binary name you can use.
18:08:17 <tibbs|w> Maybe I'll just go ahead and write 327 up.
18:08:19 <abadger1999> tibbs|w: Hmm... is there more guideline updating to do?  I thought I hit all the places in guidelines but left the tools undone.
18:08:34 <geppetto> abadger1999: Cool, thanks
18:08:53 <tibbs|w> abadger1999: I don't know; I was just trying to deal with the open ticket.
18:08:56 <abadger1999> tibbs|w: yeah, please do.  I guess i missed that bullet point in bkabrda's comemnt.
18:09:31 <tibbs|w> Do we need to vote on that?
18:09:56 <tibbs|w> Otherwise I'll write it up when I sweep the rest of the tickets.
18:10:04 <geppetto> F20 and F21 yum both still point to /usr/bin/python :( :(
18:10:06 <abadger1999> My impression was that would fall under the previous approval but up to you.
18:10:28 <abadger1999> FPC does have a lot of different members since it was approved :-)
18:10:28 <tibbs|w> Ah, yes, comment 9.
18:10:50 <tibbs|w> That's a "should" but bkarda request a "must".
18:11:02 <geppetto> ahh
18:11:12 <tibbs|w> kbabrda
18:11:17 <tibbs|w> I will never type that correctly.
18:11:25 <geppetto> :)
18:11:33 <tibbs|w> I would be +1 for must.
18:11:49 <tibbs|w> But will write it as a should for now if we don't get to +5 on that.
18:12:51 <geppetto> The weird thing is that comment #9 point 1 is kind of contradicting the __python macro change … *sigh*
18:13:07 <tibbs|w> Now you know why I'm confused.
18:13:43 <geppetto> Man, it's almost as if it would have been better if upstream python hadn't decided to screw up back compat. so much.
18:14:20 <geppetto> sighs
18:14:21 <tibbs|w> Even perl5 wasn't this bad.
18:14:32 <abadger1999> yeah, this new ticket is a request to change what was decided in 327#comment9 for the single-spec file use case.
18:14:57 <geppetto> #action tomspur Tweak wording of comment 5 for vote next week.
18:14:59 <geppetto> abadger1999: yeh
18:15:23 <geppetto> Do we have any other action items?
18:15:37 <tomspur> geppetto: I don't think tweaking the wording is necessary as I seem to contradict the old ticket?
18:15:45 <geppetto> tibbs: You want to propose something for the should => must change, or the binary name?
18:15:48 * tomspur is lost now too...
18:16:04 <tibbs|w> geppetto: I can write it up as "should" now.
18:16:13 <geppetto> tomspur: I think the wording tweak was just to clarify what "default" meant there
18:16:14 <tibbs|w> If people want it as a must, we can vote on that later.
18:16:19 * racor was lost long time ago ;)
18:16:29 <tibbs|w> There was a bunch of other stuff on the agenda, but some things were already closed.
18:16:36 <geppetto> Emergency … all FPC members are now lost.
18:17:18 <abadger1999> tomspur: it's okay to condradict the old ticket -- the new ticket is requesting a change to the existing guideliens (which the old ticket represents)
18:17:21 <tibbs|w> How about this: someone who understands this goes over all of the related tickets and stuff, summarizes and if necessary puts forward some kind of draft.
18:17:35 <geppetto> tibbs: Yeh, that's all the new tickets … we have older ones … but I've felt terrible all week, and would appreciate stopping
18:17:38 <tibbs|w> And that can't be me, due to the "understands" requirements.
18:17:54 <tibbs|w> geppetto: I wouldn't object to stopping.
18:18:03 * geppetto nods
18:18:16 <geppetto> #topic Open Floor
18:18:32 <tibbs|w> So can anyone find the time to summarize this python stuff?
18:19:30 <geppetto> I only see a few possibilities: 1) tibbs. 2) tomspur 3) geppetto 4) abadger1999 / python SIG.
18:19:39 <tibbs|w> Otherwise I'll try, but I can't promise to do the best job.
18:19:56 <tibbs|w> Because while I understand the general issues, I'm no python expert.
18:19:59 <abadger1999> bkabrda is probably the best but I hesitate to volunteer someone who isn't here :-)
18:20:08 <tomspur> I could find the time, but I am not convinced that I understood it now right anymore... :/
18:20:19 * geppetto nods … well you can point him at the meeting minutes :)
18:20:58 <geppetto> I could try to do a comment at least
18:21:29 <geppetto> maybe if we all did that, then at least bkabrda would have something to look at and could start from there next week.
18:21:43 <abadger1999> I can take a stab at an actual draft for ticket 327.
18:22:07 <tibbs|w> abadger1999: I'll write the "should" in for 327, if that's what you were talking about drafting.
18:22:11 <abadger1999> I'm not 100% behind the current ticket so bkabrda is probably better to write something up.
18:22:16 <abadger1999> tibbs|w: ah oky.
18:22:25 <abadger1999> no need for me to do something there then.
18:22:32 <tibbs|w> Yeah, I think I can do that one OK.
18:22:44 <tibbs|w> I'll try to collect related tickets and summarize.
18:22:50 <abadger1999> sound good.
18:22:55 <geppetto> ok, cool
18:23:04 <tibbs|w> And I'll take that buildroot thing to the packaging list.
18:23:19 <geppetto> ok
18:24:15 <geppetto> Anything else to talk about, or I'll close at 25 past
18:24:28 <tibbs|w> And I'll write up the other thing we voted on.  Are you OK to add the minutes links to the tickets or should I try to do that?
18:24:42 <geppetto> tibbs: No, I can still do that
18:24:49 <geppetto> was only 3 tickets anyway
18:25:06 <tibbs|w> OK, cool.
18:25:19 <geppetto> And I have a process doing it while doing the emailing of them :-o
18:25:28 <tibbs|w> I'll wonder off to do some work.
18:25:37 <geppetto> :)
18:25:55 <geppetto> #endmeeting