16:01:58 <abadger1999> #startmeeting fpc
16:01:58 <zodbot> Meeting started Thu Aug 22 16:01:58 2013 UTC.  The chair is abadger1999. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:01:58 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:02:11 <abadger1999> #meetingname fpc
16:02:11 <zodbot> The meeting name has been set to 'fpc'
16:02:38 <tibbs|w> Howdy.
16:02:41 <abadger1999> #chair RemiFedora limburgher tibbs|w tibbs geppetto racor Smoother1rOgZ abadger1999
16:02:41 <zodbot> Current chairs: RemiFedora Smoother1rOgZ abadger1999 geppetto limburgher racor tibbs tibbs|w
16:03:21 * limburgher is here.
16:03:28 <abadger1999> #chair Rathann
16:03:28 <zodbot> Current chairs: Rathann RemiFedora Smoother1rOgZ abadger1999 geppetto limburgher racor tibbs tibbs|w
16:03:34 <limburgher> RemiFedora: No, you don't/
16:03:35 * RemiFedora here
16:03:44 <Rathann> hi, sorry about last week, but my connectivity was crap
16:03:58 <abadger1999> <nod>
16:03:59 <abadger1999> No problem
16:04:09 <limburgher> FYI, I have a hard stop in 30 min.  Sorry.
16:04:22 <abadger1999> #topic https://fedorahosted.org/fpc/ticket/327 Python shebangs should not point to /usr/bin/python
16:04:49 * abadger1999 checks what the state of this was
16:05:38 <limburgher> The can is open.  Not sure about the worms.
16:06:40 <abadger1999> Okay, I think there's a proposal lurking in there somewhere.  Let me try to state it.
16:07:37 <abadger1999> 1) change the guidelines and rpmdevtools-newspec to use explicit %{__python2} and %{__python3} instead of %{__python}.  Mention on the Python Guidelines page that %{__python} should be considered deprecated
16:08:03 <abadger1999> 2) Change the definition of the %{__python} to be /usr/bin/python2
16:08:23 <geppetto> What is the reasoning/advantage of #2?
16:08:34 <geppetto> #1 seems fine, to me.
16:08:35 * Smoother1rOgZ here
16:09:01 <abadger1999> 3) Add wording to the python guidelines that /usr/bin/python should not be invoked in files we're shipping  -- invoke /usr/bin/python2 or /usr/bin/python3 instead.
16:09:50 <abadger1999> I think those are all the things to change from that ticket.
16:10:04 <Rathann> geppetto: following upstream recommendatio not to break existing scripts
16:10:19 <Rathann> Avoiding breakage of such third party scripts is the key reason this PEP recommends that python continue to refer to python2 for the time being. Until the conventions described in this PEP are more widely adopted, having python invoke python2 will remain the recommended option.
16:10:29 <Rathann> http://www.python.org/dev/peps/pep-0394/#migration-notes
16:10:30 <abadger1999> For #2 -- that means that doing a rebuild of most packages will comply with #3.
16:11:06 <abadger1999> Because the packages' spec files are presently doing: %{__python} setup.py (build|install)
16:11:28 <geppetto> abadger1999: You don't read #3 as applying to "#!" lines?
16:11:50 <abadger1999> setup.py does a replacement of shebang lines on scripts it installs to whatever path invoked it (so whatever %{__python} maps to)
16:12:09 <abadger1999> geppetto: I do read it as applying to shebang lines.
16:12:17 <geppetto> Ok, didn't know that feature of setup.py
16:12:30 <abadger1999> geppetto: So #2 helps packages to comply without touching spec files.
16:12:59 <geppetto> Yeh
16:13:09 <abadger1999> <nod>  It's a feature of both distutils and setuptools which are the two ways that setup.py is almost always implemented.
16:13:17 <Rathann> I think we should put "and packaged scripts must be patched to use /usr/bin/python2 or ...3 as required." in 3)
16:13:38 <abadger1999> Rathann: <nod> being explicit about that makes sense.
16:13:40 <geppetto> I was leaning towards +1, -1, -1 … but with that feature of setup.py, I guess +1, 0, 0 … maybe be convinced to go all the way to +1 on the last two.
16:13:49 <Rathann> a link to pep-394 would also be nice
16:14:24 <Rathann> oh, there's one exception to the patching - scripts deliberately compatible with both 2.x and 3.x
16:14:36 <Rathann> it's all mentioned in the PEP
16:14:54 <abadger1999> Rathann: yeah -- that's a corner case.  I can put that in but I'm not sure if it will make a difference in practice or not.
16:15:38 <abadger1999> as dual compat would mean that the upstream needs to care and the packager needs to know that the upstream cares.
16:15:47 <limburgher> And packages calling setup.py without the macro are considered noncomplying anyway and will need to be fixd?
16:15:48 <abadger1999> which is more work than just assuming one or the other.
16:16:28 <abadger1999> limburgher: yeah -- they're considered noncomplying with #3 -- I wouldn't care if they switch from "/usr/bin/python setup.py" to "/usr/bin/python2 setup.py"
16:17:30 <limburgher> abadger1999:  Yeah, though, if they're updating anyway they really should.
16:17:57 <limburgher> That will make migration to /usr/bin/python4 that much easier in 2023.
16:18:03 <abadger1999> :-)
16:19:28 <abadger1999> Okay -- so we can vote to allow me to make these changes or you can tell me to write an actual draft with these changes first and then vote next meeting.
16:19:36 <limburgher> So as we sit I think I'm probably +1, +1, +1, as long as #3 remains SHOULD.
16:19:50 <abadger1999> ah..
16:20:32 <geppetto> abadger1999: So what's the rough timeline on changing /usr/bin/python to be py3k?
16:20:45 <geppetto> I know I've asked before, but… I've slept since then :)
16:20:46 <abadger1999> limburgher: Well, I think #3 is a must... the eventual smooth switching of /usr/bin/python to point at something other than /usr/bin/python2 depends on that having been a must at some time beforehand.
16:21:15 <abadger1999> geppetto: I'm going to say, no earlier than 2015.  (that's when upstream has said they'll reevaluate the recommendation in PEP394)
16:21:29 <limburgher> abadger1999: Good point, consider my condition revoked.
16:21:37 <geppetto> Still seems a bit too fast for #2 and #3 then, IMO
16:21:41 <abadger1999> geppetto: of course, everytime we get a new python maintainer we have this conversation again :-)
16:21:47 <geppetto> I'm +1 on #1.
16:21:57 <geppetto> abadger1999: Dave is doing something else now?
16:22:27 <abadger1999> geppetto: yeah -- IIRC he's working on gcc now but I've also slept since I last asked him.
16:22:37 <geppetto> :)
16:23:02 <abadger1999> geppetto: bkabrda is the new python maintainer.
16:23:47 <abadger1999> at first he wanted to switch /sur/bin/python to point to python3 in f22 but ncoghlan and I talked him into being a bit more conservative.
16:24:12 <geppetto> Change all the things! Do it now!
16:24:25 <geppetto> Anyway … +1, 0, 0
16:24:42 <abadger1999> So I'm +1 to all three.  My rasoning for #2 is that it won't break anything to do it now.
16:24:45 * Rathann is +1 on all three
16:24:50 <Smoother1rOgZ> +1 here
16:25:10 <geppetto> Go on then … I'll give #2 a +1 too.
16:25:10 <abadger1999> For #3, it's something we have to do -- this gives us plenty of time to start patching packages and working out the kinks.
16:25:25 <geppetto> That'll mostly fix #3 anyway, without having to add any wording. So meh.
16:25:37 <abadger1999> We wouldn't want to start on #3 the same release as /usr/bin/python3 gets switched.
16:25:58 <abadger1999> <nod>
16:26:07 <abadger1999> Alright, I'm +1 on all 3.
16:26:17 <geppetto> +1, +1, 0
16:27:05 <abadger1999> So far we have +3:0:-0, +3:0:-0, +2:1:-0
16:27:08 <geppetto> I'd +1 a slightly looser version of #3, saying something like "it'd be nice if you did this, but it's not required ... yet"
16:27:33 <RemiFedora> I don't really think that fixing a "deprecated" macro is a good idea... but
16:27:33 <geppetto> but, yeh, other people should vote too ;)
16:27:35 <RemiFedora> +1
16:27:48 <limburgher> Ok, I'll be AFK for a bit, I'll check back upon return to see if you're still in session.
16:27:53 <tibbs|w> It seems to me that we have to do all of this at some point.
16:27:54 <abadger1999> If 3 doesn't pass, I'd settle for that :-)  I'd like a nice must to get people to accept patches, though.
16:28:34 <abadger1999> <nod>  yeah it's inevitable.
16:28:40 <geppetto> abadger1999: Yeh, and I don't mind that wording … in a year or so. Just not excited to rush to that wording.
16:28:42 <abadger1999> limburgher: thanks.  See you later!
16:28:50 <racor> +1 for 2   -1 on 1 and 3
16:30:27 <geppetto> racor: why -1 on #1?
16:30:40 <tibbs|w> I'm basically +1 on all of it, but I do wonder about the timing of #3.
16:33:04 <abadger1999> Okay -- my count of votes is: +7:0:-1 (racor dissenting), +8:0:-0, +6:1:-1 (geppetto and racor dissenting)
16:33:30 <abadger1999> if that looks right to everyone else, then all three pass.
16:34:46 <racor> I am fan of "least effort" -  1 forces packagers to (IMO: avoidable) action.
16:36:41 <abadger1999> #info passed a 3 part update to shebang lines.  abadger1999 to modify the guidelines to implement the three changes.
16:36:59 <abadger1999> #topic #328     Soft-static uid/gid allocation for Performance Co-Pilot daemons
16:37:03 <abadger1999> .fpc 328
16:39:05 <abadger1999> https://fedorahosted.org/fpc/ticket/328
16:39:09 <geppetto> This looks like a "use dynamic uids" thing, right?
16:39:33 <RemiFedora> I don't see any explanation why a fix uid/gid will be required
16:39:37 <geppetto> it's not listed as common to use shared storage
16:39:40 <abadger1999> yeah -- I'm sorry -- I think last week we decided this looks like dynamic uids.
16:40:02 * geppetto nods
16:40:10 <abadger1999> I just need to write that into the ticket and allow the submitter to provide additional information if they think that's wrong.
16:40:23 <abadger1999> #topic #329     Packaging Guideline: libtool should be regenerated in SPEC
16:40:28 <abadger1999> https://fedorahosted.org/fpc/ticket/329
16:41:03 <tibbs|w> I wouldn't really object to "can be regenerated", but "should" doesn't seem really correct.
16:42:27 <geppetto> does upstream libtool recommend people regenerate everything all the time?
16:43:02 <geppetto> or autoconf, etc?
16:43:13 <geppetto> I know they explicitly did not recommend that in the past.
16:43:20 <racor> No it does not
16:43:45 <racor> they still do - People who are telling otherwise have no clue
16:44:26 <racor> besides this, a less known fact is not all versions of libtool being compatible
16:44:37 <geppetto> ok, then, seems like a pretty clear -1 to me.
16:44:55 <racor> Using newer versions require modifications in configure.in|a
16:45:08 * geppetto nods … same as it's always been then.
16:45:10 <racor> configure.in|ac
16:45:19 <racor> correct.
16:45:44 <tibbs|w> Is there any motivation for this other than "bundling"?
16:46:02 <tibbs|w> I mean, was this a huge deal when ARM got turned on or something?
16:46:17 <abadger1999> there was some fixing needed when arm was turned on
16:46:40 <abadger1999> was it the particular arm build target we needed wasn't there?
16:46:47 <racor> abadger1999: Which? I am not aware about any libtool related changes to the arm
16:46:57 <tibbs|w> Because this "bundling" doesn't result in anything that actually makes it into the binary packages, and if someone really wants to crusade against that kind of bundling, they'd be better off starting with bison/yacc output or somesuch.
16:47:01 <abadger1999> dgilmore: You around?
16:47:16 <Rathann> abadger1999: you're thinking about aarch64
16:47:22 <abadger1999> ah okay.
16:47:29 <racor> rathann: this was config.sub|guess
16:47:35 <Rathann> yes
16:47:47 <Rathann> I don't remember anything about arm and libtool
16:47:57 <geppetto> And even if it did hurt arm a bit, that we allow this … it's not like we'll have new arches every year.
16:48:55 <dgilmore> abadger1999: yeah
16:50:04 <abadger1999> dgilmore: I think we got it figured out -- we were discussing a request to require rebuilding libtool/automake/autoconf generated files every build and we were wondering if enabling arm needed anything like that.
16:50:25 <abadger1999> dgilmore: i thought there was but Rathann let me know that I was thinking about aarch64.
16:50:57 <Rathann> I'm fine with recommending that maintainers do try to run autoreconf -fi and if it doesn't work, report it upstream (or send a patch if they can), but requiring it might be a bit too much.
16:51:09 <sgallagh> abadger1999: I seem to recall that ARM did indeed need some fixes/patches for older versions of libtool, but I can't seem to find the details right now
16:51:11 <abadger1999> tibbs|w: The bugzilla linked in the ticket seems to be the motivation.
16:51:23 <dgilmore> abadger1999: arm no, aarch64 shows that there is some issues with autoconf etc, the supported triplets is hardcoded in the tarball, if things are generated with an older set of tools  some arches will fail to build
16:52:04 <Rathann> However, Debian requiring it is a strong argument in favour.
16:52:54 * limburgher is back, reading.
16:53:23 <sgallagh> I should also note that the Ubuntu guys discovered several packaging issues in some of my projects a while back, before we adopted this policy.
16:53:42 <sgallagh> Forcing the rebuild meant that they got caught.
16:54:58 <abadger1999> dgilmore: thanks
16:55:07 <dgilmore> sgallagh: personally i think if it fails to run its a bug in the package and needs fixed. there "should" be no harm in running autoreconf at any time
16:55:23 <limburgher> dgilmore: <nod>
16:55:30 <sgallagh> dgilmore: My point exactly
16:55:32 <dgilmore> i know some people think differently
16:56:18 <dgilmore> that you must use what upstram ships. but adding arches and some other cases fail.
16:56:47 <sgallagh> Sure, and my proposal doesn't prevent that, it just requires tracking it to (hopefully) encourage maintainers to work with upstream to fix that
16:56:48 <abadger1999> has libtool/automake/autoconf backwards compatibility improved?  the "past" (definitions of how long ago that is vary) problem has been that you get subtle problems running newer versions of the tools on older versions of the input.
16:57:15 <geppetto> abadger1999: I would guess no, if upstream are still saying not to regenerate anything.
16:57:52 <abadger1999> So if we were truly duplicating what we do for most shared libraries, we'd be telling maintainers to create autotools compat packages to run on their particular package.
16:57:56 <abadger1999> geppetto: <nod>
16:58:26 <abadger1999> I'm kinda leaning towards -- if this is covered by existing no bundling policy, it would be most akin to copylibs.
16:58:38 <racor> sgallagh: you are wrong autoreconf is harmful
16:58:57 <abadger1999> where upstream for the library wants people to import the copylib into their code and modify the copylib in their code if need be.
16:59:15 <racor> sgallagh: it's just the fact many packages are trivial, which makes them believe it works.
16:59:32 <racor> try that on complex packages and you're easily lost
17:00:17 <racor> try GCC, binutils, gdb, and you'll see
17:00:42 <geppetto> Basically without some kind of upstream message of "we strive to be backwards compatible", I'm -1 on this. Yes, I understand it sucks … but current policy sucks the least.
17:01:06 <abadger1999> added to that that the problems are said to be subtle (I'm guessing the problems are along the lines of "test doesn't work as it used to; causes a #define to have a different value; compiled code is not what the packager intended given the flags and packages they used")
17:01:14 <geppetto> And we are way more forgiving of any "bundling" when it's just build/test related.
17:01:31 <racor> the related lists currently are contact almost every day by debian/ubuntu folks who get trapped by their distros non-sensical policies
17:02:06 <racor> geppetto: rubbish, the actually are very few packages which cope with autoreconf
17:02:20 <Rathann> IMHO we need someone who can help fix any issues to do a mass rebuild with autoreconf before configure and see how much of a problem this would be
17:02:29 <racor> only those which actually are designed to be used this way.
17:02:56 <racor> and these only have been lucky by being actively maintained
17:03:22 <racor> once these packages age, they will inevitably fail
17:04:55 <racor> rathann: hardly possible ... an extreme case, showing the naivity of this idea are firefox/thunderbird
17:05:04 <Rathann> racor: (playing devil's advocate) I see as something a bit similar to FTBFS bugs
17:06:24 <geppetto> no … not even the bad/annoying FTBFS bugs. Don't change anything and it'll work forever.
17:06:33 <racor> rathann: Yes, e.g. I have been removing autoreconfs and replacing them with patches from several packages, because the caused FTBFSes, recently.
17:06:37 <geppetto> Change stuff randomly and it'll break randomly.
17:07:04 <racor> geppetto: correct - This is why running autoreconf is risky
17:07:18 <Rathann> but then we have bugs like this libtool case mentioned in the ticket
17:08:17 <racor> rathann: (Playing devils advocate) How about RH finally getting involved into libtool - I am having difficulties to remember RH ever having contributed anything to it.
17:09:23 <abadger1999> racor: to be fair, I do remember spot trying to get some things (multilib related, I think) into libtool.
17:09:53 <geppetto> Rathann: I don't see BZ#978949 as a reason to do this.
17:10:30 <racor> reference? I am subscribed to the libtool list for ca. a decade and do not recall him having shown up there. I'd be glad to be corrected, but ...
17:12:42 * Smoother1rOgZ brb
17:14:43 <abadger1999> bz 978949 is.... interesting in how it figures into the equation.  Since it's a non-upstream change, it won't be in the packages no matter how new their libtool is.  OTOH, it also means there's a higher likelihood that it will interact with what is in spec files in a bad way.
17:15:04 <abadger1999> anyhow...
17:15:13 <abadger1999> I think we should probably just vote on this.
17:16:11 * sgallagh notes that the original proposal is fairly weak: essentially: packages should run autoreconf *if they can*, and if not, should open a BZ to track it and try to work with upstream
17:16:25 <sgallagh> I didn't really expect it to be this controversial...
17:16:28 * Smoother1rOgZ back
17:17:45 <abadger1999> Proposal: autotools using packages must regenerate the autotools generated files in the spec file unless those regenerated files fail to build in which case they must file appropriate bugs
17:17:47 <abadger1999> -1
17:17:53 <limburgher> sgallagh: IOW treating it like any other upstream build problem.
17:18:23 <sgallagh> limburgher: Codifying it as a build problem, yess
17:18:32 <geppetto> -1
17:18:34 <tibbs|w> -1
17:18:38 <abadger1999> sgallagh: How long have you been in Fedora again? ;-)  This is a reoccuring flame war.
17:19:21 <tibbs|w> But like I said, I have no problem if some particular packager wants to do this for their packages.
17:19:56 <tibbs|w> A long time ago there was a push to ban autoreconf.
17:20:11 <Rathann> hm the way abadger1999 worded it, I'm +1 if you replace must with should, otherwise 0
17:20:23 <abadger1999> tibbs|w: <nod>  100% agree.
17:20:25 <Smoother1rOgZ> Rathann: +1
17:20:36 <Smoother1rOgZ> i'm not ok with "MUST"
17:20:37 <limburgher> 0: Because autoreconf should never really be necessary, and should really always work.  In a perfect world.
17:20:46 <Smoother1rOgZ> 0 forme
17:21:33 <tibbs|w> limburgher: Well, it's absolutely necessary if you're, say, packaging an SCM snapshot where the stuff wasn't actually generated.
17:22:28 <limburgher> tibbs|w:  Well, yes, of course, but then in a perfect world there are always current releases of the best working code. ;)  And I have a unicorn.
17:23:15 <abadger1999> Okay, this does not pass (looks like it doesn't pass even if it's a should instead of a must).
17:23:36 <abadger1999> Do people have time to look at one more?
17:23:52 <Smoother1rOgZ> sure
17:23:52 <abadger1999> #topic #331     ruby guidelines requiring ruby(release) causes depsolving headache https://fedorahosted.org/fpc/ticket/331
17:23:52 <tibbs|w> I'm not going anywhere.
17:23:52 * RemiFedora have to go soon
17:24:03 <abadger1999> If we lose quorum we can vote next meeting
17:24:48 <limburgher> Or in the ticket.
17:24:54 <tibbs|w> Doesn't this really, really need some input from the ruby folks?
17:25:11 <tibbs|w> That whole stack is complicated.
17:25:25 <limburgher> Yeah, it seems like if done wrong it could defeat the purpose of ruby(release)
17:27:15 <tibbs|w> Not only that, but I don't really think this is something that should be fixed in the guidelines.
17:27:22 <abadger1999> samkottler: Are you around?
17:27:46 <Rathann> from the ticket, it sounds like puppet should require ruby (instead of jruby) anyway
17:28:09 <limburgher> Rathann:  Yes.
17:28:13 <Rathann> so it makes sense to make it depend on a particular interpreter
17:32:15 <abadger1999> I wonder if https://fedorahosted.org/fpc/ticket/334  is the same issue.
17:33:32 <geppetto> 334 seems like a weird "this would have been a nice thing to do if we could go back in time, so we could use this macro everywhere"
17:33:55 <tibbs|w> That's more a "hey, the ruby stuff changes so fast that multi-release specs get ugly".
17:33:59 <Rathann> hm, I need to look back at ruby guidelines
17:34:12 <samkottler> abadger1999: hey, yeah
17:34:25 <abadger1999> samqDo you have any input on https://fedorahosted.org/fpc/ticket/331
17:34:39 <samkottler> so the issue is that the alternate ruby implementations are not complete and shouldn't get selected in the vast major of the cases
17:34:52 <abadger1999> samkottler: Or if this is a bad time; it's hte tail end of our meeting so we could pick this up next week if you'll be around.
17:34:56 <samkottler> so you should explicitly require jruby or mruby or whatever
17:35:13 <Rathann> For example, a package that uses fork should explicitly specify Requires: ruby.
17:35:24 <samkottler> Rathann: right
17:35:27 <Rathann> seems clear that puppet should require ruby and it does
17:35:44 <abadger1999> samkottler: heh. So you're saying that the assumptions the ruby sig made when they handed us the new ruby guidelines wer.... off base?
17:36:09 <samkottler> abadger1999: yep. none of the alternate implementations are complete
17:36:26 <samkottler> and even if jruby was complete, you wouldn't want to use it
17:36:31 <Rathann> so does the depsolving idiosyncracy affect the package install even with Requires: ruby in place?
17:36:33 <samkottler> it pulls in so many deps
17:36:53 <samkottler> Rathann: yes, then it installs jruby and MRI (ruby)
17:37:33 <abadger1999> hmm...
17:37:40 <abadger1999> Just how far from reality is: http://fedoraproject.org/wiki/Packaging:Ruby#Different_Interpreters_Compatibility ?
17:38:36 <samkottler> the information about jruby not working perfectly is true, but the Requires: ruby hack doesn't work
17:38:51 <abadger1999> okay.
17:38:59 <samkottler> IMO we should completely move away from the ruby(release) pattern because it breaks across versions
17:39:48 <Rathann> looks like RHEL7 adopted it already :(
17:40:51 <abadger1999> <nod>  Is that part of ticket 334?
17:41:25 <samkottler> abadger1999: no there's a whole other ticket I filed about that
17:41:33 <samkottler> but I'm on my phone right now so I don't have easy access to it
17:41:36 <abadger1999> <nod>  334 vs 331 :-)
17:41:38 <abadger1999> okay.
17:41:40 * abadger1999 posts title
17:41:52 <abadger1999> 334 is Create a macro for selecting the proper ruby-(abi|release) version
17:42:05 <Rathann> ok, I need to go away soon
17:42:08 <abadger1999> 331 is ruby guidelines requiring ruby(release) causes depsolving headache
17:42:13 <samkottler> abadger1999: that's the one
17:42:13 <limburgher> As do I.
17:42:18 <abadger1999> samkottler: cool.
17:42:30 <abadger1999> Okay.  I guess we should end the meeting and pick this up next week.
17:43:07 <geppetto> samkottler: We found a bug recently with the requires hack: https://bugzilla.redhat.com/show_bug.cgi?id=998707
17:43:30 <geppetto> samkottler: So if you want to go that way, it should work "soon".
17:43:59 <samkottler> geppetto: that's just diving deeper into the problem
17:44:01 <samkottler> it's a deeper hole
17:44:07 * geppetto nods
17:44:10 <Rathann> thanks guys
17:44:19 <Rathann> I'm on vacation for the next two weeks
17:44:28 <abadger1999> Rathann: ah, have fun!
17:44:33 <Rathann> but if anyone is going to FROsCon this weekend, I'll be there
17:44:49 <Rathann> bye
17:45:26 <RemiFedora> sorry must go also
17:45:28 <RemiFedora> bye
17:46:07 <abadger1999> samkottler: Okay... I guess we need to discuss these on the two tickets this week.  If you can be here for the meeting next week (~started about 1:45 ago) that would be helpful (although this time of year we might not get quorum so the ticket might be safer :-)
17:46:24 <samkottler> abadger1999: I should be able to make it
17:46:29 <abadger1999> samkottler: Cool.  Thanks!
17:46:40 <abadger1999> #endmeeting