17:00:45 <spot> #startmeeting Fedora Packaging Committee
17:00:45 <zodbot> Meeting started Wed Feb 29 17:00:45 2012 UTC.  The chair is spot. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:00:45 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
17:00:49 <rdieter> after learning a bit more (and from onlist discussion), I don't mind dropping the unconditional gem repacking
17:00:50 <spot> #meetingname fpc
17:00:50 <zodbot> The meeting name has been set to 'fpc'
17:01:03 * abadger1999 was under the impression that when they rebuilt for ruby-1.9.x they just went ahead and changed to the unapproved guidelines.
17:01:28 <limburgher> Groan.
17:02:11 <spot> #topic Roll Call
17:02:15 <geppetto> ofc. … it's the Fedorfa way
17:02:18 * geppetto is here
17:02:23 <rdieter> hi ho
17:02:34 * limburgher here
17:02:37 * spot is propped upright for the moment
17:02:51 <abadger1999> rdieter: I've been thinking about it for a couple weeks -- I've decided unless they present me with packages where it doesn't work for a valid reason (not buggy upstream code) I won't vote yes without unconditional gem repacking.
17:03:10 <abadger1999> rdieter: but we can vote on that separately from the rest of the guideline update.
17:03:31 <limburgher> abadger1999:  I really don't see where it's extra work, except for the buildsystem.  Whoop de-do.
17:03:33 <spot> abadger1999: my thoughts are this: once you get something for us to vote on, we will. i'm not sure you're waiting on input from the Ruby SIG at this point
17:03:40 * abadger1999 sent a message to the packaging list about 5 minutes ago with rationale about htat.
17:03:47 <spot> if they really cannot stomach it, we'll let them appeal to FESCo
17:03:51 <abadger1999> spot: Just... time.
17:04:08 <spot> abadger1999: understood
17:04:27 <spot> just make it clear to them that we're not trying to delay them out as a bargaining position
17:04:52 <abadger1999> Gotta get some code finished by pycon and then attend pycon and probably sprint on that code -- so I'm severely time limited until March 16th or so.
17:05:01 <tibbs|h> Has the Ruby SIG given us what they consider to be the final guidelines they want us to vote on?
17:05:16 <spot> i also don't think there is any reason to advise FESCo to drop the 1.9.x feature from f17, even if we haven't got final guidelines
17:05:17 <tibbs|h> Was that mess with all of the exceptions the final submission?
17:05:22 <abadger1999> tibbs|h: What they gave us was riddled with problems.
17:05:45 <limburgher> I think the discussion was around trying to massage it into something we'd accept.
17:06:02 <tibbs|h> If they gave us a draft and we articulated the issues with it, they can't really blame us for any delay.
17:06:08 * spot notes that we have quite a few items on the agenda for today.
17:06:18 <abadger1999> tibbs|h: I've revised the draft to address some of those but they're not in consensus about all of those changes.
17:06:23 <limburgher> LEt's get the non-ruby stuff done.
17:06:28 <spot> Right now, I count geppetto, rdieter, tibbs|h, limburgher, abadger1999, spot
17:06:34 <spot> racor emailed me to say he would be absent
17:06:37 <abadger1999> tibbs|h: and some of the changes are linked together.
17:06:52 <spot> so we have quorum as is
17:07:08 <spot> if SmootherFrOgZ or Rathann arrive... they arrive.
17:07:14 <spot> #topic Ruby
17:07:33 <spot> We're going to revisit this when there is a draft ready for consideration, understanding this is not likely for the next 3 weeks or so.
17:07:37 <spot> Moving on.
17:07:56 <spot> #topic Logging (i think) - https://fedorahosted.org/fpc/ticket/142
17:08:16 <spot> johannbg opened it, then closed it, then reopened it
17:08:21 <spot> maybe it is a translation barrier
17:08:28 <spot> but i am not sure what he wants us to do here
17:08:47 <tibbs|h> I think that's wading into FESCo feature territory.
17:09:17 <geppetto> I think he wanted us to change packaging guidlines to say "do not use rsyslog" … but I'm not sure now.
17:09:20 <limburgher> I think, at this point, nothing.  He asked me about this on IRC, but it was about guidelines about supporting logging implementations, not defaults, migrations, etc.
17:09:33 <spot> Is anyone opposed to be closing that ticket out?
17:09:36 <limburgher> No.
17:09:49 <geppetto> No
17:09:54 <Viking-Ice> I open that ticket so logging could be fixed in the distribution
17:09:55 <limburgher> As long as we comment that he should re-open if we're misunderstanding.
17:09:58 <limburgher> Ah!
17:10:09 <spot> Viking-Ice: fixed, how exactly?
17:10:25 <Viking-Ice> which should have been done when rsyslog got introduced in F7 or in F8
17:10:51 <Viking-Ice> spot, by putting some guidelines around it proper rsyslog conf file if you are using rsyslog
17:10:53 <spot> Are we planning on supporting configurations with multiple simultaneous (but incompatible) syslog setups?
17:10:58 <Viking-Ice> dependency on rsyslog for example
17:11:10 <spot> Or permitting one spin to use rsyslog and another to use $SOMETHINGELSE ?
17:11:20 <rdieter> eep
17:11:48 <spot> I think unless the answer is no, it is safe to assume that packages are using the "default syslog mechanism", whatever FESCo decides that to be
17:12:00 <spot> (or rather, unless the answer is yes)
17:12:16 <spot> which is currently rsyslog
17:12:25 <Viking-Ice> regardless of that you still need guidelines
17:12:31 <spot> to say what exactly?
17:12:37 <spot> "use syslog"? :)
17:12:47 <limburgher> Is there a current package that doesn't do something it should?
17:12:50 <Viking-Ice> sub package and depend on rsyslog
17:12:59 <spot> Viking-Ice: why would a subpackage be necessary at all?
17:13:00 <Viking-Ice> limburgher, yours for example
17:13:13 <Viking-Ice> that provides rsyslog conf file but does not depend on rsyslog
17:13:20 <Viking-Ice> ???
17:13:22 <abadger1999> well..
17:13:29 <spot> Viking-Ice: i believe there is an assumption that rsyslog is present in every Fedora spin
17:13:35 <abadger1999> It would be nice if the feature went to fesco now.
17:13:43 <rdieter> so, is that what https://fedoraproject.org/wiki/User:Johannbg/Packaging/LogFiles is supposed to be then?
17:13:44 <Viking-Ice> it's ready for wrangler
17:13:47 <spot> much in the same fashion that we do not require "kernel"
17:13:49 <limburgher> Viking-Ice:  Which?
17:13:54 <abadger1999> and then we could start looking at what we'd need for guidelines now, well before f18.
17:14:17 <abadger1999> otherwise we get stuck where the guidelines aren't ready and people are trying to get other things done under the f18 deadlines.
17:14:47 <Viking-Ice> abadger1999, my journal proposal is just about disabling rsyslog by default not removing it
17:15:03 <spot> I agree with abadger1999, lets worry about guidelines once FESCo has approved changing the default syslog mechanism from rsyslog
17:15:38 <tibbs|h> Someone can always draft some guidelines, and we can look at them with the assumption that fesco will approve its stuff.
17:15:50 <geppetto> And I'm still not sure what general packages would need to know … they'd still just use /dev/log or glibc's APIs.
17:16:07 <geppetto> And not care at all if rsyslog or journald is on the other end.
17:16:07 <Viking-Ice> geppetto, log files creations etc
17:16:43 * spot notes that the draft as-is, states that "As of Fedora 18+? systemd journal has become the default syslog solution for Fedora."
17:16:56 <spot> since this is not yet true, it will be difficult to consider the draft.
17:17:11 <tibbs|h> Even then, that's not much of a draft.
17:17:12 <spot> i am rather uncomfortable spending time putting carts before horses. :/
17:17:43 <spot> But I will say that I don't see why rsyslog subpackages would be necessary today or in that hypothetical f18 timeline.
17:17:49 <Viking-Ice> ok put on ice review later if/when  journal becomes the default syslog
17:18:02 <spot> Viking-Ice: alright.
17:18:16 <limburgher> I could see considering guidelines around subpackages, but only with use cases/examples of existing issues, which I don't yet see.
17:18:22 <spot> #action #142 is tabled until change of default syslog
17:19:27 <spot> Alright
17:19:31 <spot> moving onward
17:19:35 <Viking-Ice> limburgher, minetest-server provides /etc/rsyslog.d/minetest.conf but does not depend on rsyslog
17:19:53 <spot> #topic https://fedorahosted.org/fpc/ticket/143 - Note on Software Collections for Packaging Guidelines
17:20:24 <spot> Please note: I worked with mmaslano to propose this language as an alternative to adopting Software Collections and they are okay with it
17:20:59 <limburgher> Viking-Ice:  Ah.  That's not mine.  But yes, it should, as rsyslog provides that directory.
17:21:03 <spot> Basically, what it says is this: There are these macros that some packagers may want to use in their spec files, much as some packagers use OpenSUSE macros in the Fedora spec files
17:21:16 <spot> we do not forbid this, because, well, they're not used in Fedora, so they're not really an issue
17:21:45 <spot> But in this case, given the somewhat intrusive nature of the changes, I thought it merited being mentioned in the guidelines so that these macros are not cargo-culted and accidentally turned on.
17:22:12 <geppetto> seems fine
17:22:14 <geppetto> +1
17:22:19 <spot> +1 from me as well
17:22:42 <limburgher> +1, would be neat if rpmlint could check for these and W about them.
17:22:49 <rdieter> +1
17:23:08 <tibbs|h> Are we just talking about the four macros from http://docs.fedoraproject.org/en-US/Fedora_Draft_Documentation/0.1/html/Packagers_Guide/sect-Packagers_Guide-Converting_a_Conventional_Spec_File.html
17:23:20 <spot> tibbs|h: pretty much, yes
17:23:41 <tibbs|h> If that's it, they doesn't look particularly intrusive.
17:23:46 <spot> tibbs|h: however, the net result of those changes if enabled is that the packages look and act very different
17:23:52 <spot> they're effectively relocated
17:24:25 <tibbs|h> My concern is that packages would be complicated by a tonne of excess crap.
17:24:28 <abadger1999> +0 atm
17:24:39 <spot> tibbs|h: yep, but the maintainers would be doing that voluntarily
17:24:42 * abadger1999 could be persuaded, though
17:24:56 <spot> and afaik, we have no real rules about "don't add macros that you don't turn on"
17:25:02 <tibbs|h> Of course, but my concern is that if one maintainer does it, nobody else would be able to understand the restructured package.
17:25:09 <tibbs|h> It doesn't look that bad, so my concern is assuaged.
17:25:12 <spot> tibbs|h: hence, the note and the provided docs
17:25:32 <geppetto> abadger1999: You want people to build packages in Fedora which live in /opt or whatever?
17:25:35 <spot> and it isn't terrible. more logical than deb file syntax. ;)
17:25:36 <abadger1999> complication for present maintainer, future maintainer, reviewers, bug reports from users asking that a package start using the scl macros,
17:25:41 <tibbs|h> Still not getting my point across.
17:25:49 <abadger1999> geppetto: That's a -1 without question :-)
17:25:51 <geppetto> abadger1999: Or you want to ban the macros in the specfiles, even if they aren't used?
17:26:24 <spot> I'll be straightforward. Red Hat wants to make some of these software collections for RHEL
17:26:28 <abadger1999> geppetto: yeah, I'm stuck between do we want to point out that these macros exist (and allowed but not required) or banning.
17:26:40 <tibbs|h> The concern is that with anything like this, adding excessively complicated macros that most packagers don't understand effectively drops the package out of the community.  Look at clamav.
17:26:42 <spot> and they'd like for these macros to be in Fedora's spec files in certain packages (probably less than 10)
17:26:57 <spot> and simply not enabled except when Red Hat wants to build these SCs for RHEL
17:26:57 <tibbs|h> But these macros don't seem all that bad, so if that's it then I'm OK with it.
17:27:23 <geppetto> abadger1999: My personal opinion is that we should allow any macros in the specfiles … to help with interop. between SuSE/RHEL/Magiea/whatever … as long as the packages come out as Fedora packages, from our build system.
17:27:34 <abadger1999> Do we still have in the guidelines that spec files written for other distros are discouraged or not allowed?
17:27:46 * spot notes that we are being clear that inclusion is okay and enablement is forbidden
17:27:56 <geppetto> Packaging is a boring task, with not many resources … so helping packagers share that task is good.
17:27:58 <abadger1999> this is kind of a similar foundation but we'd be specifically allowing it.
17:28:01 <tibbs|h> geppetto: I'm against that kind of thing for the reasons I just stated.
17:28:08 <spot> and each spec file using it will have a mandatory comment note at the top
17:28:28 <spot> where "using" means "adding macros, but disabling them"
17:28:34 <tibbs|h> Anyway, I don't particularly have a problem with this particular draft.
17:28:35 <tibbs|h> +1
17:28:55 <spot> #action Draft approved (+1:5, 0:1, -1:0)
17:29:15 <spot> #topic Require PIE - https://fedorahosted.org/fpc/ticket/144
17:30:05 <tibbs|h> It's this guideline being changed: http://fedoraproject.org/wiki/Packaging:Guidelines#PIE
17:30:05 <geppetto> +1
17:30:10 <spot> notting wants to require PIE in the cases we defined as SHOULD
17:30:26 <spot> i'm fine with that, noting that if there is an obvious exception, it still applies
17:30:32 <spot> +1
17:30:42 <limburgher> +1
17:30:44 <rdieter> +1
17:31:12 <tibbs|h> +1
17:31:25 <abadger1999> I thought that we made it a should for a reason but I can't recall.
17:32:18 <spot> abadger1999: we're at +5, but i'll wait for your vote
17:32:56 <tibbs|h> All of this assumes that _hardened_build actually turns on the right stuff for the package, and it's not always easy for a reviewer to tell.
17:33:02 <geppetto> IIRC there were some discussions about how it might affect perf. … but I don't think anyone ever provided any compelling numbers
17:33:35 <tibbs|h> At first we let FESCo maintain the list; now it appears that the listed criteria are sufficient.  Which seems OK to me.
17:35:00 <spot> #action Change to MUST approved (+1:5, 0:0, -1:0)
17:35:10 <abadger1999> So...
17:35:13 <abadger1999> With PIE
17:35:14 <abadger1999> and must
17:35:28 <abadger1999> Does that mean libreoffice would be PIE compiled?
17:35:32 <abadger1999> as an example.
17:35:45 <abadger1999> " Your package accepts/processes untrusted input. "
17:35:46 <geppetto> it doesn't meet any of those 4 points, does it?
17:35:49 <spot> does not suid, run as root, or count as long running
17:36:02 <abadger1999> firefox similarly
17:36:03 <tibbs|h> Depends on how you define "untrusted input".
17:36:05 <geppetto> I guess it "accepts untrusted input"
17:36:06 <abadger1999> yeah
17:36:10 <abadger1999> I think...
17:36:10 <tibbs|h> And I'd leave that to the packager.
17:36:18 <limburgher> All input == untrusted. :)
17:36:20 * spot would leave that to the packager and/or FESCo
17:36:34 <abadger1999> I think I would leave it as should if the definition of untrusted input is left to the packager.
17:36:45 <geppetto> Maybe just remove the last point … or move it to a should section?
17:36:51 <abadger1999> I  think I'd switch it to must if we actually do intend to include things like libreoffice.
17:36:58 <abadger1999> also, I think the fesco list should go away.
17:37:07 <geppetto> And, yeh, I'm trying pretty hard to think of any input that could be classified as trusted.
17:37:08 * spot notes we are at +5 on changing this to a MUST
17:37:14 <abadger1999> Instead a partial list should now go into the guidelines.
17:37:19 <tibbs|h> fesco may wish to maintain an additional list; I've no problem with that.
17:37:22 <abadger1999> as examples of those four points.
17:37:32 <spot> if people want to make other changes to this section, i would ask them to put forth a draft
17:37:44 * spot is trying not to be cranky, but well, i feel sick. :/
17:37:48 <abadger1999> I think cahnging from should to must changes the thrust of the guideline significantly...
17:37:54 <limburgher> geppetto:  If a program accepts any input at all, even it's own logs might not be *entirely* trustworthy.
17:38:02 <geppetto> limburgher: yeh
17:38:18 <abadger1999> I'm okay with voting yes under those circumstances...
17:38:23 <geppetto> spot: Ok, I'm -1 with the fourth point … let me comment with a new wording
17:38:51 <abadger1999> but i want it understood that it would be a big change :-)
17:39:37 <spot> geppetto: should we wait for the new wording or move on and revisit this next week?
17:40:10 <geppetto> I've almost got it
17:40:11 * abadger1999 wonders if firefox should also be considered "long running"
17:40:21 * spot waits
17:40:28 <abadger1999> Did I say that out loud? ;-)
17:40:28 <limburgher> abadger1999: Not if flash is installed. :)
17:40:32 <abadger1999> hehe
17:40:50 <spot> abadger1999: well, it will have to be shutdown to update to a newer version every 3 days or so
17:40:57 <abadger1999> limburgher: I have chromium installed for running flash ;-)
17:41:06 <limburgher> spot:  Was JUST thinking that. :)
17:41:08 <geppetto> comment submitted
17:41:26 <geppetto> I'm +1 on that.
17:41:30 * spot is +1 on that
17:41:48 <limburgher> Yeah, +1.
17:42:22 <tibbs|h> I can get behind that as well.
17:42:23 <limburgher> That takes the change from MUST for all to MUST for critical and REAAAAAALLLY should for everything else if you really stop and think about it.
17:42:24 <abadger1999> +1  -- also, move the FESCo list after the list of criteria when updating the guideline.
17:42:25 <limburgher> I like.
17:42:36 <spot> abadger1999: sure
17:42:43 <abadger1999> as it makes it clearer now that it's a must.
17:43:14 <spot> i see +4
17:43:19 <spot> tibbs|h, rdieter ?
17:44:15 <rdieter> ok, +1
17:44:33 <tibbs|h> +1
17:44:45 <spot> #action Draft in comment 1 approved (+1:6 ,0:0, -1:0) also, move the FESCo list after the list of criteria when updating the guideline.
17:45:11 <spot> #topic Cleanups - https://fedorahosted.org/fpc/ticket/145
17:45:23 <spot> IMHO, these are easy fixes, no guideline changes just improved flow and organization
17:45:34 <spot> so unless someone disagrees, i'll just do this
17:45:37 <geppetto> yeh, w/e … +1 :)
17:45:53 <limburgher> +1 go for it.
17:45:55 * spot waits a minute or so for dissent
17:45:58 <abadger1999> +1 clarification only
17:46:19 <spot> #action EASYFIX, just do it.
17:46:40 <tibbs|h> Yeah, looks OK.
17:46:55 <spot> #topic Renaming Django packages - https://fedorahosted.org/fpc/ticket/146
17:46:59 <tibbs|h> BTW, if you look deeply enough you'll find all sorts of stuff.
17:47:09 <spot> tibbs|h: thats why i try not to look too deeply. ;)
17:47:46 <spot> there is some irony here in this ticket, because it is asking us to approve a change to bring these packages into compliance with the python naming guidelines
17:48:11 <tibbs|h> I'm not really sure that Django is more appropriately named python-django.
17:48:29 <geppetto> Yeh, this seems weird.
17:48:31 <spot> So while I do not think our "approval" is strictly necessary, I'm fine with them coming into compliance if thats what the Django and python folks want.
17:48:33 <abadger1999> +1
17:48:42 <abadger1999> If they're willing to do the work, I'm for it.
17:48:43 <tibbs|h> We have TurboGears as well,
17:48:45 <limburgher> Does anything else use it?  I mean, we wouldn't make php-drupal.
17:48:52 <limburgher> CherryPy
17:49:00 <abadger1999> django is a library, not a standalone app.
17:49:03 <spot> limburgher: python has interesting naming rules.
17:49:14 * spot wrote them, so i am to blame, but still
17:49:21 <abadger1999> so it makes sense in that way.
17:49:29 <limburgher> spot: python *software* has interesting naming.
17:49:31 <tibbs|h> Python has the terrible "py in the name" exception, but this isn't one of those.
17:49:39 <abadger1999> otoh, few things that are not a django app will use the django library.
17:49:42 <limburgher> abadger1999: Ah.
17:49:54 <abadger1999> so I've been okay with it being grandfathered.
17:49:59 <geppetto> It still seems bad … I mean Django isn't just a random python lib. … and we don't want to enforce python-yum or python-TurboGears … do we?
17:50:13 <spot> I propose we respond with "This change is acceptable to the FPC. We also think that adding useful Provides as you propose will help users."
17:50:14 <abadger1999> but like I say if someone is willing to do the work, I'm +1 to letting/encouraging them to do it.
17:50:24 <abadger1999> yum is an application
17:50:31 <geppetto> Isn't Django?
17:50:34 <abadger1999> python-TurboGears, I would encourage as well.
17:50:41 <abadger1999> geppetto: No.
17:50:47 <tibbs|h> Note that this request isn't coming from a maintainer or comaintainer of Django.
17:50:47 <limburgher> All right.  +1.
17:50:48 <abadger1999> geppetto: It's a framework and a library.
17:50:52 * jsmith would argue that Django is a framework
17:51:11 <abadger1999> you can't just run a /usr/bin/django and have it do anything.
17:51:22 <geppetto> Doesn't it do something useful if you install it and run it?
17:51:41 <geppetto> I mean … we don't think of Apache-httpd as a non-application, right?
17:51:53 <spot> I propose we respond with "This change is acceptable to the FPC, but we are not mandating it at this time, and defer to the discretion of the Django maintainers. We also think that adding useful Provides as you propose will help users, should this change be made."
17:52:00 <limburgher> I think it's more akin to pygame.
17:52:04 <spot> how about that?
17:52:12 <geppetto> spot: Sure, I guess … I'm +1 to that.
17:52:19 <limburgher> Ok. +1
17:52:27 <spot> +1 from me
17:52:31 <abadger1999> +1
17:52:37 <tibbs|h> +1
17:53:05 <rdieter> +1
17:53:36 <spot> #action My proposal passes with a vote of: (+1:6, 0:0, -1:0)
17:54:14 <spot> #topic Add FAS line to Package Review template - https://fedorahosted.org/fpc/ticket/147
17:55:01 <spot> I don't see the harm in this to be honest.
17:55:16 <spot> I'd hate to see a trend of overloading the template, but i don't think this qualifies
17:55:24 <rdieter> beats always having to ask, +1
17:55:29 <tibbs|h> Sure, but I have been unsuccessful in getting that modified in the past.
17:55:33 * spot might also add Koji Rawhide Scratch Build
17:55:38 <limburgher> Nor to I.  If it makes things even a tiny bit easier to get new contributors in the door, go for it.
17:55:48 <spot> but i know that doesn't work well for first timers
17:55:49 <tibbs|h> spot: Yes, that's what I've been unsuccessful in getting added.
17:56:06 <limburgher> spot:  No.
17:56:12 <tibbs|h> If someone has the sekrit backdoor access to get that template changed, awesome.
17:56:20 * spot can do that
17:56:49 <spot> i think jkeating has the magic, or if not, i can just ask the Red Hat Bugzilla overlords
17:56:49 <abadger1999> whats a FAS?
17:57:08 <spot> abadger1999: how about "Fedora Account System Username:"
17:57:18 <abadger1999> Sounds better :-)
17:58:00 <spot> okay, so lets vote on adding "Fedora Account System Username:" to the default review template
17:58:02 <limburgher> Fabulous Abdominal Satchel?
17:58:05 <spot> +1
17:58:07 <tibbs|h> +1
17:58:09 <limburgher> +1
17:58:34 <tibbs|h> We do need to make sure that the Join document gets updated to match.  I've been meaning to reorder it a bit for some time now.
17:58:49 <spot> tibbs|h: probably need a new screenshot as well, the one i took is notably dated
17:58:54 <tibbs|h> Right now it asks you to get your account after you submit the review request.
17:59:07 <spot> tibbs|h: okay, i'll flip them
17:59:15 <abadger1999> +1
17:59:20 <geppetto> +1
17:59:27 <tibbs|h> I'm talking about https://fedoraproject.org/wiki/Join_the_package_collection_maintainers if it wasn't clear.
18:00:22 <spot> #action Adding "Fedora Account System Username:" to the default review template is approved
18:00:23 <spot> (+1:6, 0:0, -1:0)
18:00:23 <rdieter> +1
18:00:33 * spot counted rdieter's earlier +1... :)
18:00:43 <rdieter> +2
18:01:06 <spot> okay, we're at an hour. i'd really like to stop now.
18:01:23 <spot> 148, 149, and 150 are still pending, i propose they be tabled to next week
18:01:47 <tibbs|h> Fine with me.
18:01:56 <rdieter> table++
18:02:09 <limburgher> table.  Go sleep.
18:02:16 <abadger1999> spot: go home and rest :-)
18:02:16 <spot> Okay, great, thanks everyone, see you next week.
18:02:19 <spot> #endmeeting