16:00:03 <spot> #startmeeting Fedora Packaging Committee
16:00:03 <zodbot> Meeting started Wed Mar  2 16:00:03 2011 UTC.  The chair is spot. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:00:03 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:00:07 <spot> #meetingname fpc
16:00:07 <zodbot> The meeting name has been set to 'fpc'
16:00:12 <spot> #topic Roll Call
16:00:30 * tibbs|h here
16:00:34 * gomix-fricky here
16:00:53 <limburgher> here, but may have to step out soon, to be determined.
16:01:27 <geppetto> here
16:01:53 <spot> abadger1999, rdieter, SmootherFrOgZ, racor: ping
16:02:07 * abadger1999 here
16:02:44 * spot will give the others a moment to wake up, but that's quorum
16:03:07 <tibbs|h> Not sure I know who "gomix-fricky" is.
16:05:43 <spot> okay, well, lets get started
16:06:04 <spot> #topic sonatype-tycho bundle exception for bootstrapping - https://fedorahosted.org/fpc/ticket/59
16:06:16 <limburgher> Me neither, actually.
16:06:23 <spot> I could have sworn we had guidelines covering bootstrapping, but I can't find them.
16:06:41 <racor> here.
16:06:55 <spot> the closest thing I can find is "Some software (usually related to compilers or cross-compiler environments) cannot be built without the use of a previous toolchain or development environment (open source). If you have a package which meets this criteria, contact the Fedora Packaging Committee for approval."
16:07:20 <tibbs|h> http://fedoraproject.org/wiki/Packaging:Treatment_Of_Bundled_Libraries#Bootstrapping
16:07:23 <tibbs|h> ?
16:07:42 <spot> aha, well, that is also useful
16:08:22 <limburgher> I'd like to avoid this if at all possible.  Painful != impossible, and how do we verify the prebuilt binary for legal, security, etc, issues?
16:08:28 <tibbs|h> I think the "treatment of bundled libraries" and the "no bundled libraries" pages might benefit from being combined.
16:08:44 <limburgher> tibbs|h: nods
16:08:49 <abadger1999> <nod.
16:08:53 <spot> My inclination is to approve this temporary exception, with the caveat that any such packages with "bootstrapping" libraries in use should not be tagged for a final release (or as an update to any release).
16:09:18 * abadger1999 agrees with spot.
16:09:20 <spot> s/should/must
16:09:32 <tibbs|h> I agree.
16:09:59 <tibbs|h> Although I'm not sure how we can tell after the fact.
16:10:25 <spot> tibbs|h: i'm willing to give the packager a bit of good faith here.
16:10:26 <geppetto> Maybe say anything with bootstrapping should provide "fpc-bootstrapping" or something?
16:10:35 <spot> geppetto: ooh, thats an idea.
16:10:48 <limburgher> Yes!
16:11:05 <limburgher> spot: any particular reason for the good faith, out of curiosity?
16:11:29 <tibbs|h> It's a pretty rare situation, I think.
16:11:32 <spot> limburgher: well, in general i like to think the best of Fedora packagers, but in this specific case, i've worked with the Java packagers before.
16:11:48 <spot> also, they asked permission rather than simply trying to slip it past us.
16:11:54 <tibbs|h> Anyone willing to go through all of the bureaucracy to get an exemption is probably going to follow the rules.
16:11:57 <spot> i don't think their intention is to be sloppy.
16:11:58 <abadger1999> We tend to give packagers good faith in general... we don't monitor 100% of commits so we kind of have to.
16:12:19 <limburgher> spot: That's compelling.
16:12:32 <limburgher> I still hate bootstrapping on principle, but. . .
16:12:42 <geppetto> Yeh, I agree … it's just probably useful to add the provides, to make sure something doesn't slip through
16:12:43 <limburgher> abadger1999: True.
16:13:02 <tibbs|h> So what's the plan?
16:13:15 <tibbs|h> Beef up the exception that's there and then say that this package falls under it?
16:13:18 <spot> So, I propose that we grant this temporary approval, with the caveat that any packages bootstrapped must add Provides: fpc-bootstrapping and that any bootstrapping enabled packages must not be tagged for a final release (or pushed as an update for any stable release).
16:13:41 <limburgher> How do we enforce the no release tagging bit?
16:14:01 <spot> limburgher: the cleanest answer would be an auto-qa test to check the provides
16:14:11 <tibbs|h> Ask releng to run repoquery --whatprovides before composing a release, I guess.
16:15:10 * spot is +1 on his own proposal
16:15:13 <geppetto> +1
16:15:15 <limburgher> +1
16:15:15 <tibbs|h> +1
16:15:32 <abadger1999> +1
16:16:06 <spot> that's +5. racor, would you like to vote?
16:17:10 <spot> #action Approved, with the caveat that any packages bootstrapped must add Provides: fpc-bootstrapping and that any bootstrapping enabled packages must not be tagged for a final release (or pushed as an update for any stable release). (+1:5, 0:0, -1:0)
16:17:46 <spot> Does anyone have an issue with permitting this addition to be added to Packaging:Treatment_Of_Bundled_Libraries#Bootstrapping
16:17:55 <spot> (as a more general case answer)
16:17:56 <racor> -1 packages which need precompiled stuff don't need this.
16:17:56 <abadger1999> +1 from me
16:18:19 <abadger1999> racor: Alternative?
16:18:39 <racor> You normally need such precompiled stuff once
16:18:57 <racor> later you have the "actual" binary
16:19:56 <racor> to achieve this you normally bundle the precompiiled stuff once into an src.rpm combine it with conditionals and remove all of this later
16:20:04 <abadger1999> right.... Is that not what this is doing?
16:20:17 * geppetto thought it was
16:20:35 <abadger1999> or are you saying... the Provides: fpc-bootstrap is superfluous because it'll only be in there for the initial build?
16:20:35 * spot thinks racor has done an excellent job explaining their situation. ;)
16:21:14 <racor> abadger1999: to some extend yes. Actually I don't see what it would be used for.
16:21:20 <abadger1999> <nod>
16:21:37 <spot> racor: it is intended so that we can detect if accidentally, a bootstrapping package gets into the updates stream
16:22:48 <racor> spot: OK, but how? How would you detect if a binary package contains files originating from precompiled files inside of the sources?
16:23:28 <spot> racor: well, its not magical or foolproof, but if a package has that provide, it at least throws up a red-flag.
16:23:51 <tibbs|h> The point is that you  can't really tell, so we ask that provides: fpc-bootstrap be added so that we can easily tell.
16:23:58 <abadger1999> In the past, instead of a virt provide, I think we've (not sure if that's an fpc of fesco we) just left the ticket open and pinged if the packager doesn't report that the bootstrapping is gone in a reasonable time.
16:24:11 <rdieter> here, belatedly.
16:24:22 <tibbs|h> I think, though, that it's more likely that the provides: is missed than the bundling is forgotten.
16:24:29 <spot> tibbs|h: sure.
16:24:35 <racor> abadger1999: yep.
16:25:04 <geppetto> abadger1999: I don't mind that either … but the provides thing could be generic advise, instead of having a ticket each time
16:25:17 <geppetto> But I'm fine with tickets forever too, if people prefer that
16:25:26 <abadger1999> geppetto: True... but right now we do require a ticket each time.
16:25:30 * geppetto nods
16:25:43 <spot> i don't see why we can't do both, tbh
16:26:05 <racor> do we need a ticket? Can't we make checking this the reviewer's job?
16:26:06 * abadger1999 would like to see less packager work so leans towards the ticket solution.
16:26:29 <spot> Do we want to drop the Provides requirement?
16:26:48 <abadger1999> racor: We but currently nothing requires the reviewer to look at the package post-review... this would be the first.
16:26:56 <abadger1999> *We could but
16:27:08 <abadger1999> spot: I do.
16:27:11 <racor> also consider that such bootstrapping normally is a few consecutive builts in very short time
16:27:33 <spot> Okay, I'm not locked into the Provides, tracking it via the ticket is fine by me.
16:27:48 <spot> So, i propose that we drop the Provides caveat.
16:27:49 <abadger1999> I think the ticket is less invasive, less likely to be forgotten, and doesn't add another task to releng.
16:28:17 <spot> +1 to dropping the Provides caveat
16:28:22 <abadger1999> =q to dropping provides
16:28:25 <abadger1999> +1
16:28:34 <racor> +1 to dropping
16:28:36 <tibbs|h> So if that's dropped, what's actually changing.
16:28:38 <tibbs|h> ?
16:28:56 <spot> The only caveat would be "Any packages actively using this bootstrapping must not be tagged for a final release (or pushed as an update for any stable release)"
16:29:07 <spot> and we'd track this via the ticket
16:29:32 <geppetto> +1
16:29:34 <abadger1999> Maybe add: "FPC will track this via the ticket requesting the bootstrap bundling exception."
16:29:47 <abadger1999> More to document for ourselves, then for the packager.
16:30:13 <spot> "FPC will track the progress of approved bootstrapping exceptions via the ticket requesting the bootstrap bundling exception."
16:30:37 <abadger1999> <nod>  Sounds good to me.
16:30:50 <tibbs|h> Sure.
16:30:52 <spot> So, there is +4 for dropping the provides caveat.
16:30:54 <limburgher> +1
16:31:12 <tibbs|h> +1
16:31:16 <spot> okay.
16:31:30 <spot> #action Dropping provides caveat (+1:6, 0:0, -1:0)
16:33:08 <spot> #topic Octave - https://fedorahosted.org/fpc/ticket/61
16:33:39 <spot> the macros are no longer dumped out, they now have descriptions
16:33:56 <spot> and buildroot is no longer used as pointed out before
16:34:32 <tibbs|h> The naming stuff should of course make it into the NamingGuidelines document.
16:35:03 <spot> tibbs|h: sure, thats easy to do.
16:35:25 <tibbs|h> I'm still finding it odd that this document doesn't have any actual rules to follow (besides the naming bit, I guess).
16:35:45 <abadger1999> spec templates should go last.
16:35:51 <limburgher> Yeah, it's more of a best practices/tools available thing.
16:35:51 <tibbs|h> abadger1999: Agreed.
16:36:56 <spot> okay, i moved templates to the end
16:37:39 <spot> any other concerns?
16:37:53 <limburgher> nothing jumps out.
16:38:01 <spot> +1 from me
16:38:29 <tibbs|h> What about the "NOTE: This may no longer be necessary" bit?
16:38:49 <racor> libexec ... I am not sufficiently familar with octave to be sure this is correct.
16:39:04 <limburgher> Should he maybe investigate and alter according, something like, "after release FXX not necessary"
16:39:07 <abadger1999> To follow the conventions of the rest of the guidelines, the macro explanations seem like they should be in the text, rather than comments about the macros.
16:39:15 <abadger1999> But I guess that's not a blocker in my mind.
16:40:08 * spot would be fine with changing that section to read: "Due to an issue with octave emitting an escape sequence (due to readline library) on startup, you may need to unset the TERM variable in the %build and %install sections."
16:40:20 <tibbs|h> racor: Currently octave puts loads of stuff in /usr/libexec/octave.
16:40:47 <racor> tibbs|h: May-be, but this doesn't mean it's "right"
16:40:50 <tibbs|h> It looks like most of what it puts there is actaully executable.
16:41:03 <tibbs|h> I didn't make any judgment as to whether it was right or not.
16:41:11 <racor> tibbs|h: Are these executables?
16:41:30 * spot is inclined to trust the octave packager here
16:42:06 <tibbs|h> Looks like they're shared libs.
16:42:11 <tibbs|h> amd.oct: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, stripped
16:42:36 <tibbs|h> I'm thinking that's not the best thing.
16:43:12 <tibbs|h> multilib conflicts seem to be avoided by using arch-specific directories underneath /usr/libexec/octave.
16:43:34 <racor> spot: I am inclined not to trust them, because it's easy to get used to non-standard-conforming "bad" packaging habits when frequently using a tool.
16:43:52 <tibbs|h> Octave has probably been this way forever.
16:44:07 <tibbs|h> Seems that _libdir makes much more sense for this stuff.
16:44:15 <tibbs|h> But I'm not 100% familiar with the FHS here.
16:44:28 <racor> tibbs|h: libexec is reserved for standalone executables (think of it as auxilliary bindir)
16:45:43 <rdieter> I think octave's content in libexec *used* to be executables, but seems they've optimized it a bit since last I looked closely, to use some sort of loadable modules now
16:46:01 <tibbs|h> The octave review predates the use of bugzilla for reviews anyway, so that's of no use.
16:47:17 <tibbs|h> So I think that before we ensconce this behavior in guidelines that will be used by countless modules, we try to get it right.
16:47:17 <rdieter> anyway, personally, I'd like to treat the submitted guidelines separately from any "is it FHS or not" discussion, the latter would require significant work to change it.
16:47:34 <rdieter> heh. :)
16:48:05 <spot> is someone willing to work with the author on this issue?
16:48:11 <tibbs|h> Fortunately this is hidden in macros so the packagers shouldn't have to care at all.
16:48:28 <spot> (author is orionp, he was helpful on the previously addressed concerns)
16:48:28 <abadger1999> Well... the paths might be compiled into stuff.
16:49:01 <spot> also, fwiw, libexecdir is not in the FHS
16:49:11 <spot> (this is a failing of the FHS, to be fair, but still)
16:49:26 <tibbs|h> Also, _libexecdir/octave/packages doesn't exist currently.
16:49:48 <racor> spot: libexecdir GNU Standards
16:49:57 <spot> racor: yes, i am aware of that.
16:50:28 <racor> the fundamental difference between libexecdir and libdir is multilibs
16:50:37 <tibbs|h> I think the point is that regardless of what libexec is for, _libdir is pretty obviously the right place for this stuff.
16:50:46 <abadger1999> <nod>
16:50:53 * abadger1999 agrees with tibbs|h
16:51:01 <spot> okay, so I will ask again, is anyone willing to talk to orionp about this?
16:51:26 <racor> libdir is always the last resort "if in doubt" (RH has a tradtion of not using libexec at all)
16:51:37 * spot is so buried in work I may never see the sun again, so i cannot volunteer here.
16:51:47 <tibbs|h> I can do so.
16:51:52 <spot> tibbs|h: thanks.
16:51:55 <abadger1999> thanks tibbs
16:52:05 <spot> we'll revisit this after tibbs|h has had a chance to discuss this with orionp
16:52:19 <tibbs|h> For the sake of progress, though, if the macro definitions weren't listed in the guideline, would anyone have any issues with it?
16:52:48 <spot> tibbs|h: i think given that the templates are highly macroized, i'd want definitions, at least for the ones used in the templates.
16:53:03 <tibbs|h> Let me ask another way, then.
16:53:07 <abadger1999> Meaning the relevant bits incorporatd into the text?  Or meaning would I approve the guideline if the macros with libexecdir were just not mentioned?
16:53:31 <tibbs|h> Outside of the libexec thing, are there any issues with the guideline that need to be addressed?
16:53:41 <spot> tibbs|h: none that i see.
16:53:42 <tibbs|h> I mean, since I'm going to discuss it with him.
16:54:27 <tibbs|h> Does anyone disagree with the use of _libdir/octave for this stuff?
16:54:34 <abadger1999> I'd like to see the explanation of the macros in text that explains how and why to use them rather than their current form... but I don't think I'd voe against if it remains that way.
16:54:39 <racor> AFAIC gather, there seems to be some sort of package registry below /usr/share/octave - Q: Is this arch-independed?
16:54:55 <tibbs|h> My understanding is that it is.
16:55:11 * abadger1999 agrees with the _libdir/octave unless orionp has other information that we didn't see here.
16:55:27 <spot> there are already some shared libs in _libdir/octave/
16:56:01 <tibbs|h> I do wonder if the modules will be multilib and if so what happens if you start mixing arches.
16:56:06 <spot> so, i suspect the answer is either more nuanced or more confused than it looks.
16:56:11 <tibbs|h> spot: Actually, _libdir/octave-%{version}
16:56:22 <spot> tibbs|h: yeah, sorry.
16:56:28 <tibbs|h> Anyway, I'll talk to Orion.
16:56:39 <racor> Ok, then let me ask more generally: Are the octave packages multilib-compliant? (I really don't know)
16:56:56 <tibbs|h> I think that's a question for Orion.
16:56:59 <abadger1999> One other clarification to get: %octave_cmd pkg rebuild <= is that the literal string "pkg" or is it the-octave-package-name ?
16:57:06 <tibbs|h> The base package certainly is multilib.
16:57:24 <tibbs|h> Probably because it has a -devel package.
16:57:47 <tibbs|h> abadger1999: Good question.
16:57:58 <spot> Okay, lets move on, we're at an hour and I'd like to try to get through two more items.
16:58:15 <spot> #topic Systemd - https://fedorahosted.org/fpc/ticket/31
16:58:30 <spot> abadger1999: have the blockers which prevented us from moving forward on this one been resolved?
16:59:06 <abadger1999> Previous blockers are in the process of being resolved new "ideas" have been raised that need us to make some decisions
16:59:37 <abadger1999> There's probably a huge conversation to be had here.  How about I outline issues here and then we talk o nthe list?
16:59:50 <spot> abadger1999: sounds like a good plan.
17:00:14 <spot> #topic Discourage use of macros for system execs - https://fedorahosted.org/fpc/ticket/64
17:00:16 <abadger1999> * Revisit triggers -- as notting says, they're conceptually more correct.  Also, some of the other ideas raised are least-messily  implemented using triggers.
17:00:31 <abadger1999> Ah okay we could move on and I can send the systemd summary to the list.
17:01:00 <spot> abadger1999: sorry, i misread your line. i thought that was your proposal.
17:01:07 <abadger1999> <nod>
17:01:09 <abadger1999> Fine with me.
17:01:20 <abadger1999> Probably makes more sense.
17:01:59 <spot> So, on this topic, I think the sanest thing is to go with the "simple guideline" as proposed in the ticket.
17:02:17 <spot> "Macro forms of system executables SHOULD NOT be used except when there is a need to allow the location of those executables to be configurable. For example, "rm" should be used in preference to "%{__rm}", but "%{__python}" is acceptable."
17:02:49 <tibbs|h> This is basically a straw man proposal.
17:02:55 * spot understands that
17:03:08 * abadger1999 likes the simple guideline.
17:03:15 <rdieter> works for me
17:03:17 <abadger1999> "discouraged" does seem better than SHOULD NOT.
17:03:35 <abadger1999> if the idea is to just stop people arguing about it.
17:03:35 <geppetto> Should allows people to still do it
17:03:39 <spot> s/SHOULD NOT/are strongly discouraged and SHOULD NOT/
17:04:02 <tibbs|h> Personally I'd like to approve the strongest version we can agree on.
17:04:09 <abadger1999> If the idea is to have people bring it up in reviews as "you should consider changing this but I won't require you to" then SHOULD NOT is appropriate.
17:04:26 <abadger1999> okay, then SHOULD NOT is fine is fine with me then.
17:04:30 <spot> abadger1999: yeah, i think thats where i sit.
17:04:33 <geppetto> Personally I think "SHOULD NOT" says, in the strongest possible way, that they shouldn't do it … but are allowed to if they want
17:04:42 <spot> geppetto: *nod*
17:05:10 <spot> So, I'm +1 to the "simple guideline".
17:05:14 <abadger1999> +1
17:05:19 <geppetto> +1
17:05:23 <tibbs|h> +1
17:05:24 <rdieter> +1
17:05:27 <racor> +1
17:05:43 <spot> #action Simple guideline approved (+1:6, 0:0, -1:0)
17:05:55 <tibbs|h> Someone must have hit the easy button.
17:06:17 <spot> okay, with the understanding that I want to give #67 more time to simmer, I'm opening the floor
17:06:17 <abadger1999> This is agree with tibbs day :-)
17:06:21 <spot> #topic Open Floor
17:06:50 <tibbs|h> 67 is about _bindir and such?
17:07:05 <abadger1999> Yeah
17:08:03 <tibbs|h> I don't think I have anything else.
17:08:25 <spot> the only thing i can think of is that it might be useful to have a meeting for just handling bundling tickets
17:08:46 <abadger1999> Do we want to close or talk about the systemd issues a little?
17:09:10 <tibbs|h> The whole bundling ticket thing seems to be having the (perhaps intended effect) of making people not ask for bundling very often.
17:09:14 <spot> which i suspect will be "have they provided info? No? Well, then, did we give them enough time to provide it? Yes? Well, then request denied."
17:10:15 * spot already has a headache, but i'd be willing to let others talk systemd.
17:10:28 <tibbs|h> How long should we keep bundling tickets open before giving up?
17:10:46 <geppetto> I don't mind giving them a couple of months
17:11:07 <spot> geppetto: you're more generous than i was about to be... i was halfway through typing "no more than a month"
17:11:17 <tibbs|h> It's not as if it hurts us, though trac doesn't make it easy to deal with lots of tickets.
17:11:29 <geppetto> But I suspect some of the problem is that it's obvious to the people opening tickets that we aren't just going to allow bundling if they keep asking, which may have been an impression with FESCO
17:11:40 <spot> i just don't want to let them go forever.
17:11:49 <abadger1999> Well, some of them would then switch to tracking tickets (ie: the package is already in the distro)
17:12:06 <abadger1999> Oh -- this bundling ticket is also ready: https://fedorahosted.org/fpc/ticket/52
17:13:23 <abadger1999> And this one has a reply from the package maintainer: https://fedorahosted.org/fpc/ticket/26
17:13:35 <abadger1999> So we could discuss what additional information we want or decide on it.
17:13:54 <abadger1999> The others -- I've pinged/asked for information and haven't gotten a response yet.
17:14:35 <tibbs|h> In re zorba/jsonxx, that seems to have all the answers we want.
17:14:40 <abadger1999> On the bundling front -- note that a new FES person has done a lot of good triage work on the C bundled libraries tracker which has resulted in quite a few being closed.
17:14:57 <geppetto> For #52 … they say it should be solved by April anyway … so do we want to just deny it and tell them to wait a month for the fix?
17:15:20 <tibbs|h> I don't think it's productive to deny things like that.
17:15:35 <abadger1999> tibbs|h: +1
17:15:39 <geppetto> Fair enough
17:15:50 <tibbs|h> They've done what we asked, and seem to meet the requirements, so we deny them because they won't have to wait long?
17:15:53 <spot> my instinct is to approve it, with the caveat that a move to the 2.0 release should be a priority to remove this issue.
17:16:05 <abadger1999> I'd be inclined to approve the exception and have the ticket track that the unbundling occurs.
17:16:28 <spot> abadger1999: i'm fine with that
17:16:35 <abadger1999> I can reping in April/May if the maintainer doesn't explicitly say that it's been unbndled.
17:16:58 <spot> Proposal: Approve temporary bundling exception in ticket #52
17:16:58 <geppetto> I guess my feeling is that it' probably be bad to do an upgrade to 2.0 in F15 … so if we approve it then f15 is going to have the bundled version
17:17:14 <geppetto> But if we don't then f15 can get the the "new" package as soon as it's ready
17:17:31 <tibbs|h> I think that in general it's OK for one release to end up with a bundled version.
17:18:00 <tibbs|h> The idea is to prevent bundling from proliferating endlessly and keep track of it.
17:18:04 <spot> fwiw, i'm +1 to my own proposal
17:18:04 <abadger1999> <nod>  I guess -- mention that in the ticket.  But -- when we unbundle libs in packages already approved, we only require the fixes go into rawhide, not the released fedoras so I'm still fine with it.
17:18:06 <abadger1999> +1
17:18:15 <tibbs|h> +1
17:18:36 <geppetto> Fair enough, +1
17:19:02 <spot> rdieter, racor?
17:20:29 <racor> are you voting on #52?
17:20:44 <spot> racor: we're voting to grant the exception on #52
17:21:23 <racor> -1 I still haven't seen a reply to my comment in this ticket ("why no parallel package")
17:22:21 <abadger1999> racor: The answer is -- the version of zorba to be released in April won't use that library at all.
17:22:24 <spot> rdieter: still around?
17:22:39 <abadger1999> in case it matters to your vote.
17:23:25 <abadger1999> limburgher: If you're still around as well, we're voting on one more item.
17:24:20 * spot will give it a few more minutes, but then we'll have to revisit it next week
17:24:40 <abadger1999> <nod>
17:26:35 <spot> okay, thanks everyone. we'll look at #52 next week.
17:26:37 <limburgher> SOrry, AFK for work emerg.  Cathing up. . .
17:26:41 * spot waits
17:27:06 <spot> limburgher: you've got about a minute to vote or we can look at this next week
17:27:17 <limburgher> +1
17:27:41 <spot> #action Bundling exception approved (+1:5, 0:0, -1:1)
17:27:46 <limburgher> Sorry for holding things up.
17:27:51 <spot> abadger1999: can you write up the approval in #52?
17:28:11 <abadger1999> spot: Yes, I'll do so.
17:28:16 <spot> abadger1999: thanks
17:28:21 <spot> and thanks to everyone
17:28:24 <spot> #endmeeting