16:07:12 <spot> #startmeeting Fedora Packaging Committee
16:07:13 <zodbot> Meeting started Wed Feb 24 16:07:12 2010 UTC.  The chair is spot. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:07:14 <spot> ok, no bot. i guess we'll log this old-school. :)
16:07:15 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:07:16 <spot> Roll Call:
16:08:26 <spot> aha, there goes the bot
16:08:28 <spot> maybe i'm just lagged
16:09:00 <spot> racor, rdieter, tibbs|h: ping
16:09:09 <rdieter> hiya
16:09:13 <tibbs|h> Yep.
16:09:14 <racor> here
16:09:42 <spot> i don't see limb, abadger1999, Rathann, hans, or SmootherFrOgZ
16:10:36 <spot> but... we do have abadger1999's votes via email
16:11:00 <spot> so, we might be able to get some things done, assuming we count that as quorum on those issues
16:11:22 <tibbs|h> Don't see why we can't at least discuss things.
16:11:37 <spot> okay, lets start with item 1
16:11:41 <spot> #topic https://fedoraproject.org/wiki/Fix_Complex_Font_Template%28draft%29
16:12:32 <tibbs|h> The whole font thing still warps my brain.  So much complexity.
16:13:34 <rdieter> tibbs|h: indeed
16:13:43 <tibbs|h> But I don't see how just putting the macro at the same place in the two templates could be a bad thing.
16:14:04 <spot> tibbs|h: yeah, i'm inclined to agree with you
16:14:30 <tibbs|h> I suppose we can assume that this has actually been tested.
16:14:46 <spot> i'm pretty sure it has been tested.
16:15:26 <tibbs|h> Was there input from the font people (besides all of the flaming)?
16:15:29 <rdieter> just move it then
16:15:55 <spot> the only real input was that it would require package changes to be compliant with the template change
16:16:34 <spot> nim-nim seemed to prefer that we added a dummy %_font_pkg macro to redhat-rpm-config instead
16:16:49 <spot> which would evaluate to %{nil} if not already defined by fontpackages-devel
16:17:03 <tibbs|h> Any particular reason that's not in the draft?
16:17:19 <rdieter> it is, per
16:17:20 <spot> not sure, i just saw it in bz 564613
16:17:25 <rdieter> as suggested by Panu
16:17:36 <rdieter> but not mentioned explicitly
16:17:55 * spot is not opposed to that solution either
16:17:55 <tibbs|h> Don't see how that relates to "Fix the tools".
16:18:23 <tibbs|h> It seems like less of a patch job to just tweak the packages, but then we're used to papering over all sorts of things.
16:19:36 <rdieter> nim seemed not happy to have to do any work changing stuff, and the fake %_font_pkg macro in redhat-rpm-config is one way to achieve that
16:20:11 <spot> well, i'm inclined to go with the macro fix for now, especially given that the longer term fix of section end markers is being worked on at some point in the distant future
16:20:35 <tibbs|h> Well, with a system as complex as all of the font templates, assuming that we'd never find any problem with it after approval is incredibly optimistic.
16:21:05 <tibbs|h> But sure, if one tweak to redhat-rpm-config solves the problem then I don't see why we wouldn't just do that.
16:21:10 <rdieter> I'm ok with any of the proposed fixes too
16:21:32 <rdieter> though mod'ing redhat-rpm-config feels the most hackish
16:21:35 <spot> racor: any thoughts here?
16:21:53 <spot> we could also do both, fix the template and add the macro failsafe
16:22:07 <spot> that way, new packages get cleaner, existant packages get grandfathered
16:22:28 <rdieter> I think I like that better, yes
16:22:38 <tibbs|h> Sure.
16:23:03 <spot> Okay, so lets vote on "Move the Macro and Add the Macro failsafe to redhat-rpm-config"
16:23:36 <spot> +1 from me
16:23:37 <tibbs|h> +1
16:23:54 <racor> +1
16:23:59 <tibbs|h> I just hope there's not some hidden breakage we'll find next month from this change.
16:24:04 <rdieter> +1
16:24:39 <spot> Toshio had no preference of choice, so I think it is safe to assume he +1s here as well
16:24:57 <spot> but i'll follow up with him as soon as he gets back from pycon to be sure
16:25:08 <spot> #action +4 for proposal
16:25:43 <spot> #topic https://fedoraproject.org/wiki/PackagingDrafts/RPMMacros_sharedstatedir_optflags_and_admonitions
16:26:33 <spot> this looks like a general cleanup of an older page
16:27:22 <spot> seems straightforward to me, +1
16:27:33 <tibbs|h> Shouldn't those EPEL issues be on the EPEL page?
16:27:33 <rdieter> old/crufty bad, clean good: +1
16:27:57 <spot> tibbs|h: yeah, but that's an implementation note, i'll do the writeup and make sure it ends up there
16:28:41 * spot has a big note in his todo list to make sure that all EPEL specific items at least get repeated on an EPEL specific page
16:29:55 <spot> any other concerns? if not, please toss out votes.
16:30:21 <tibbs|h> I'm doing a visual diff.
16:30:27 <spot> mmkay
16:31:31 <tibbs|h> Kind of wish we'd just not use $RPM_BUILD_ROOT and $RPM_OPT_FLAGS, but I guess that's just personal preference.
16:32:26 <tibbs|h> Some of these are weird enough that I wonder if there's a point in having them in the guidelines.
16:32:51 <tibbs|h> I mean, it's true that %{_oldincludedir} is defined by RPM.  But why do we need to put that in the guidelines?
16:33:16 <spot> yeah, we probably don't need to reference that one
16:33:31 <spot> i wouldn't consider it "common"
16:33:40 <tibbs|h> He didn't add it; it was there from the beginning.  But I've always wondered why it's even mentioned.
16:33:49 <spot> easy enough to remove if we're cleaning it now
16:34:10 <tibbs|h> The guidelines should be "this is what you should use", not "here's a list of everything you could find with rpm --showrc".
16:34:39 <tibbs|h> But, yes, a general +1 to these changes.
16:34:55 <racor> I don't understand what this "draft" is trying to achieve.
16:35:20 <spot> racor: its a cleanup for the existing RPMMacros page
16:35:39 <tibbs|h> Some of it is stuff we should just be doing anyway.
16:35:58 <tibbs|h> Not mentioning "Fedora Core" and such.
16:36:52 <racor> OK, but my feel is there are way too many critical details inside which all would require  to be checked for, before voting.
16:37:03 <spot> such as?
16:37:22 <racor> eg. the /var vs. localstatedir section.
16:37:28 <spot> i mean, confirming the validity of these macros is as straightforward as --showrc
16:37:53 <tibbs|h> It's true that %{_var} and %{_localstatedir} evaluate to the same thing.
16:38:05 <racor> They serve different purposes, similar to %_lib and %_libdir
16:38:30 <spot> racor: that may be so, but they've evaluated like this since... well, at least FC3
16:38:52 <tibbs|h> If you wish to write a draft explaining which should be used when, please feel free.
16:39:16 <tibbs|h> It's not as if the original document didn't mention both in exactly the same way that the draft does.
16:39:50 <racor> Well, I actually feel this proposal should be split, because I feel it's too radical
16:40:04 <tibbs|h> You must have some odd definition of radical.
16:40:21 * spot notes that the part you have highlighted for concern is present in the existing guidelines page
16:40:47 <tibbs|h> All he did is change "Other macros" to "Other macros and variables for paths".
16:41:06 <racor> Taking too many steps at once, with a high probabilty of replacing existing bugs with new ones.
16:41:12 <tibbs|h> And add PM_BUILD_ROOT to the bottom of the section.
16:41:27 <tibbs|h> That... turned out weird.
16:41:34 <tibbs|h> And add $RPM_BUILD_ROOT to the bottom of the section.
16:41:43 <spot> racor: i really can't say i see where you're coming from on this one.
16:42:09 <spot> but, if you're opposed, go ahead and vote so we can move on.
16:42:28 <tibbs|h> But, sure, I couldn't object to actually going through all the stuff on this page to make sure we actually want people to use it.
16:42:36 <tibbs|h> racor: Are you willing to do that?
16:43:24 <tibbs|h> ...
16:44:24 * spot yawns
16:44:41 <racor> spot: This proposal is trying to change many _critical_ _core_ details of the configuration machinery.
16:44:51 <spot> racor: it doesn't change _anything_
16:45:01 <spot> racor: this is how the macros are defined. right now.
16:45:09 <racor> I feel each sentence of this proposal needs to be explicitly reviewed
16:45:23 <tibbs|h> So I ask again: are you willing to do that?
16:45:24 <racor> not doing so would be grossly negligant
16:46:03 <racor> spot: This doesn't exclude the current state is broken.
16:46:11 <tibbs|h> That's true.
16:46:35 <spot> racor: this draft doesn't request that we change the current macro definitions, merely that we reflect what they are.
16:46:36 <racor> sorry, ... might/could be broken ... I don't know
16:46:38 <tibbs|h> I actually think that there's stuff in there which we probably don't want in there.
16:46:57 <tibbs|h> But there are nuances I'm sure I don't understand.
16:47:07 <spot> if you think that macros should be changed, then i think that is a separate issue
16:47:28 <tibbs|h> Still, if racor isn't even willing to given an answer to questions about whether he's willing to contribute to fixing the document, then I'm not sure we have much more to discuss.
16:47:29 <spot> (i'm not sure if that issue is within our scope or not.)
16:47:57 <spot> racor: would you like to vote on this draft, for the record? otherwise, i'll assume a vote of 0 and move on.
16:48:09 <racor> tibbs: Your provocations are beyond limits, get a grip on yourselv
16:48:32 <tibbs|h> I only asked if you were willing to assist in correcting the document.
16:48:50 <racor> spot: I don't want to be co-responsible for writing broken stuff into concrete: My vote -1
16:48:58 <spot> okay.
16:49:23 <spot> #action Voting on RPMMacros improvements: +3, -1 (racor)
16:49:37 <spot> #topic http://fedoraproject.org/wiki/Packaging/No_py_removal%28draft%29
16:51:07 <tibbs|h> My network just dropped for about 90 seconds.
16:51:10 <spot> fun.
16:51:18 <spot> well, you didn't miss anything
16:51:24 <spot> aside from me moving to the next topic
16:51:45 <spot> this draft seems to be common sense to me.
16:51:45 <tibbs|h> That link gets me to a "no such page" page.
16:51:52 <spot> https://fedoraproject.org/wiki/No_py_removal%28draft%29
16:51:54 <spot> ?
16:52:09 * spot just opened it
16:52:10 <rdieter> ok, better
16:52:15 <rdieter> wierd
16:52:28 <tibbs|h> No "Packaging/"
16:53:17 <rdieter> looks like a no-brainer
16:53:24 <spot> #topic https://fedoraproject.org/wiki/No_py_removal%28draft%29
16:53:27 <tibbs|h> I guess it's not a bad idea to make this explicit.
16:53:56 <spot> tibbs|h: agreed, especially since the question explicitly came up which inspired this draft
16:54:05 <spot> +1 from me
16:54:36 <racor> +1
16:54:40 <tibbs|h> +1
16:55:06 <spot> rdieter ?
16:55:15 <rdieter> +1
16:55:43 <spot> #action Voting on No_py_removal: +4 present, +1 from abadger1999 via email, it passes.
16:56:02 * abadger1999 shows up late
16:56:08 <spot> #topic http://fedoraproject.org/wiki/User:Ajax/Static_Library_PICness_Guidelines
16:56:54 <spot> abadger1999: we voted to both move the font macro in the template and to create a dummy macro in redhat-rpm-config as described in the bugzilla ticket
16:57:13 <spot> abadger1999: if you'd like to vote on that, it would decide whether that issue passes or not.
16:58:18 <spot> on the current topic, i think this draft is incomplete.
16:58:27 <abadger1999> For Library PICness I'm not opposed to it but I don't think it's complete yet.
16:58:30 <ajax> i agree.  what needs doin'?
16:58:43 <spot> ajax: there are some open issues listed on that page
16:59:16 <ajax> tsk.  you mean if i hadn't written them down, you wouldn't have noticed? ;)
16:59:29 <spot> no, i would have caught at least two of them. ;)
17:00:08 <tibbs|h> So what happens when you build a static library without -fPIC on x86_64?
17:00:09 <spot> fwiw, i think this is the first time we've required .pc creation
17:00:23 <spot> (or rather, the first time that a draft has required it)
17:00:36 <ajax> tibbs|h: nothing.  amd64 doesn't allow non-pic DSOs; ld won't create them and ld.so won't load them.
17:00:43 <ajax> i386 is the only arch that's this stupid.
17:00:50 <ajax> (that we ship on)
17:01:05 <tibbs|h> But does it build it PIC anyway or does it fail?
17:01:26 <ajax> oh, static lib.  sorry, misread.
17:01:44 <ajax> you can create ar archives containing non-PIC objects
17:02:03 <ajax> if you try to link that lib into a DSO or a PIE executable, ld will fail
17:02:17 <ajax> if you try to link that lib into a normal executable, it'll succeed
17:02:21 * spot had to patch the shit out of chromium to fix that issue
17:02:56 <spot> lots of fun. :)
17:03:54 <ajax> spot: on the pc file issue: yes, but it seems like the correct mechanism.  it means the non-PIC ar archive is something you have to explicitly ask for.
17:04:06 <spot> ajax: i don't disagree with that, just noting it.
17:04:14 <tibbs|h> I have to wonder if this is something we actually run into.
17:04:18 <spot> we should be discouraging static libs in most cases anyways
17:04:29 <spot> tibbs|h: i have one package that needs to do this (and actually does it)
17:04:36 <spot> except for the .pc part
17:04:42 <tibbs|h> Current guidelines permit static libs if the maintainer wants them.
17:04:59 <tibbs|h> Actually using those in other packages is what's restricted.
17:05:16 <spot> tibbs|h: fair enough.
17:05:36 <spot> it does however, say: "Static libraries should only be included in exceptional circumstances."
17:05:46 <spot> and "In general, packagers are strongly encouraged not to ship static libs unless a compelling reason exists. "
17:05:58 <tibbs|h> I think we're actually kind of contradictory about that.
17:06:04 <spot> really?
17:06:58 <ajax> it's definitely a corner case.
17:07:20 <ajax> i don't think we see it often.  but we should still get it right.
17:07:28 <spot> anyways, that issue aside, i think we can push this one out two weeks for the draft to be finished up
17:07:48 <tibbs|h> I don't feel up on the technical issues here, but currently there's not enough there for reviewers to be able to use.
17:07:51 <ajax> any issues besides the ones in the draft?
17:08:13 <halfline> do we really want to be in the business of shipping fedora specific .pc files?
17:08:30 <ajax> the "simple definition" bit in Open Issues should probably include a way of testing for picness; i'll include that.
17:08:37 <abadger1999> ajax: The basics of my questions were: How does the reviewer determine that a package is doing it wrong and how doesthe packager fix the issue.
17:09:25 <abadger1999> ajax: If answering the questions are sufficient for that then it's good, if a reviewer would still be lost then we'd need to add some more.
17:09:35 <ajax> halfline: not in general?  but this level of build configuration detail is a distro policy question, so it kinda makes sense to ask a per-distro mechanism.
17:10:08 <ajax> i don't think anyone is actually going to bother to build their static libs both ways, so.
17:10:11 <halfline> thing is, having disto-specific .pc files implies having distro-specific patches to configure.ac ...
17:10:37 <halfline> seems like a road we souldn't want to go down...
17:10:45 <ajax> it does indeed.  i think that's the point; that's a diversion we generally don't want to carry, so you should have to justify it pretty hard.
17:11:58 <ajax> which is why Exceptions says "non-PIC static libs need explicit approval from FESCO"
17:12:29 <ajax> anyway.  i'll work this more.  thanks for the feedback!
17:12:29 <spot> ajax: but the .pc file is required even for the PIC static lib
17:12:36 <abadger1999> spot: (What do you need me to vote on to either pass or fail?)
17:12:55 <ajax> spot: that may be how it reads, but that is not the intent.
17:12:57 <spot> abadger1999:  we voted to both move the font macro in the template and to create a dummy macro in redhat-rpm-config as described in the bugzilla ticket
17:13:07 <spot> ajax: okay, please fix then. ;)
17:13:44 <ajax> spot: the pc file is only there for the "build both" case, is the intent.
17:14:14 <spot> ajax: okay, when you're polishing this up, please make that explicitly clear.
17:14:19 <ajax> will do.
17:14:23 * ajax afk, lunch
17:15:01 <spot> okay, i'm going to go to the last issue for today
17:15:29 <spot> #topic Clarify line between bundled libraries and copied snippets of code https://fedorahosted.org/fesco/ticket/314
17:15:35 <spot> man, this is a fun one.
17:16:44 <spot> i dunno if we still need to do anything here, it was on the agenda, but i thought it was discussed last meeting 02/03
17:16:52 <tibbs|h> I don't think it's possible to write a reasonable guideline for this that answers more questions than it raises.
17:17:17 <abadger1999> Yeah -- So this is a discussion and maybe be able to draft some guidelines topic.
17:17:46 <tibbs|h> All this over wordpress.
17:17:47 <abadger1999> At when point does modified bundled libraries stop being bundled libraries and become forked code that happens to live in another package?
17:17:52 <spot> i don't know that we will be able to do this in a reasonable guideline that isn't contentious
17:17:56 <abadger1999> s/when/what/
17:18:20 <tibbs|h> abadger1999: The answer to that question depends on the disposition of both upstreams.
17:18:32 <spot> in the specific case of WP, are these three PHP files really "libraries" ?
17:18:55 <tibbs|h> That, as well, depends on the disposition of both upstreams.
17:18:59 <abadger1999> spot: The one I looked at was really a library upstream.
17:19:08 <tibbs|h> I think it's all about intent.
17:19:14 <abadger1999> But wordpress didn't treat it as a library.
17:19:24 <tibbs|h> We fork/patch/whatever code in Fedora all the time.
17:19:42 <tibbs|h> But our intent is not to diverge permanently or significantly in most cases.
17:19:47 <abadger1999> It made changes to the code instead of calling the api... to my unaided eye, it seemed a bit gratuitous.
17:19:56 <tibbs|h> The wordpress folks just don't seem to care.
17:20:00 <abadger1999> <nod>
17:20:13 <spot> these seem to be forks with wordpress changes.
17:20:14 <tibbs|h> But that's a view through a long lens.
17:20:21 <abadger1999> Some cases deserve to be divergent though -- for instance rsync's bundled library needs to be pulled out.
17:20:43 <abadger1999> Because there's other libraries that want to be wire-sompatible with rsync.
17:20:49 <abadger1999> s/libraries/applications/
17:21:23 <spot> i'm not sure where the line of acceptability truly is here. is it a % of fork? is it upstream's intent?
17:21:36 <spot> is it affected by type of code in use (PHP vs traditional DSO)
17:21:45 <tibbs|h> The bottom line with wordpress is that we seem to be trying to make the decision between accepting what wordpress upstream does, basically forking wordpress ourself to "do the right thing", or kicking it out of the distro in protest.
17:22:00 <tibbs|h> ourselves.  Jeez.
17:22:34 <spot> in the case of WP, if the code is forked with changes, we either accept that they are maintaining that code as part of WP or we don't permit the package.
17:22:48 <spot> i'm inclined to accept it in this situation.
17:23:10 <tibbs|h> I'm inclined to be more cautious.
17:24:03 <tibbs|h> Not that it's my decision anyway.
17:24:14 <spot> i think cases where libs or dynamically loaded files are simply copied for convenience or laziness are clearly unacceptable
17:24:40 <spot> but a forked work could easily be considered an improved (or simply derived) work
17:24:47 <tibbs|h> It starts as convenience or laziness, and then they change a couple of lines instead of bothering to send a patch upstream and all of a sudden it's a fork.
17:25:37 <tibbs|h> Sometimes when they are called on it, the fork can be made to go away.
17:26:05 <abadger1999> spot: but what about when the forking causes compatibility problems?  (for instance rysnc's zlib)?
17:26:31 <spot> well, i'm not sure that we can do much more on this issue. I think it is good for us to be pushing upstream, but at the end of the day, it is up to FESCo to decide whether the merits of keeping the code are enough to ignore upstream's bad behavior.
17:26:52 <tibbs|h> So what is actually before FPC at this point?
17:27:00 <spot> as far as i can tell, nothing
17:27:03 <spot> but i might be wrong
17:27:14 <tibbs|h> So...
17:27:24 <abadger1999> <nod>  So -- our final analysis is that FESCo will need to do the analysis -- FPC has no more input on the proper criteria to give?
17:28:04 <spot> abadger1999: i could write pages and pages on this topic, but i'm not sure it would do anything other than make a gray area even more gray
17:28:04 <tibbs|h> It's completely situational.
17:28:23 <spot> i'm happy for FESCo to ask for FPC advice on each situation
17:28:36 <tibbs|h> We can write "maintainer _should_ contact both upstreams regarding resolving forks" or something.
17:28:39 * abadger1999 is fine with that just wants an accurate summary.
17:28:52 <abadger1999> spot: Hmmm... so what's FPC's advice i nthis situation?
17:29:18 <spot> well, if it were my package, this is what I would do
17:29:45 <spot> 1. Package up the verbatim copied bits as proper upstream components, and make WP dep on them (with symlinks if needed).
17:30:16 <spot> 2. Generate diffs of the changes made to forked components and submit them to the upstreams for consideration
17:30:59 <spot> If those upstreams rejected the diffs, I'd try to at least open a dialog with WP on the topic
17:31:15 <spot> If they accepted them, I would remove the forked code (as it wouldn't be forked anymore)
17:31:15 <tibbs|h> We could provide guidelines for naming forked libraries, I guess.
17:31:36 <spot> Based on a maintainer taking those actions, I would recommend that we permit WP.
17:32:38 <abadger1999> Where dialog == more than the bug report that was already opened?  Or that bug report was sufficient?
17:33:03 <tibbs|h> Well, "bug report" if awfully one way.
17:33:09 <tibbs|h> But if there's no response....
17:33:18 <spot> Well, in this case, i was thinking of the upstreams of the forked bits
17:33:36 <spot> opening bugs there
17:33:39 * abadger1999 wants to avoid bug reports of the form: "My distro requires me to open this bug report to try to get you to unbundle these libraries but I really don't understand why it's helpful so feel free to close it if it's too hard" type things.
17:33:54 <abadger1999> Ah.
17:34:02 <spot> heh. i think in such cases, i'd advise against including them.
17:34:16 <abadger1999> Note that the one library I looked at (the one that seemed gratuitous) was all WP specific changes.
17:34:24 <abadger1999> Rename classes to have WP in the names
17:34:33 <abadger1999> Change error messages to be WP specific.
17:34:43 <tibbs|h> Unsurprising fail.
17:35:01 <abadger1999> You know -- very little in the way of changes to the functioning of the code... but very specific to WP rather than upstreamable.
17:35:03 <spot> yep, its fail, but WP is taking responsibility for it at some level.
17:35:15 <spot> i mean, if it could be sanely patched out in our copy, maybe.
17:35:25 <spot> i patched out quite a bit of that from chromium
17:35:42 <spot> and to be fair, i think mozilla does some of that too
17:35:58 <tibbs|h> Doesn't make it remotely a good idea.
17:36:15 <tibbs|h> It's just that we weren't paying as much attention to this kind of thing way back when.
17:36:34 <spot> my feeling is that we should push maintainers to do the best that they can to inform the upstreams of the issue, try to get it resolved, and if all avenues fail, ask FESCo to decide if it is acceptable to keep.
17:36:54 <spot> i know that i'm not doing a very good job of defining what is acceptable at that point. :/
17:37:00 <tibbs|h> Yes.
17:37:39 <spot> however, i suspect most packages with such issues will not have such diligent maintainers and will not get that far
17:37:43 <tibbs|h> The tough issue is to decide if and how much the popularity or importance of the application factors into the decision.
17:37:59 <spot> and those that do, well, that maintainer knows what they're in for and is making a level of committment.
17:38:26 <spot> i think those factors do weigh on the decision
17:38:48 <spot> i mean, if we were to pull rsync over this issue, it would be perceived as extremely negative and damaging to Fedora
17:39:14 <tibbs|h> Well, what's in is already in, and our focus has to be on fixing those mistakes as best we can.
17:39:17 <abadger1999> spot: In ththe vien of the Fedora package maintainer making a level of commitment: "If it has to be modified I would ask that someone who knows PHP would take it [...]" <=  wrong or right attitude?
17:39:50 <spot> abadger1999: well, at least he's admitting he's not the qualified person for the job. :/
17:40:18 <spot> i hate to jump out at this point, but we're pushing on 1 hr 40 minutes now.
17:40:19 <abadger1999> <nod>
17:40:30 <spot> i'm going to open the floor for other topics, and hopefully, wrap this up
17:40:34 <spot> #topic Open Floor
17:40:39 <abadger1999> Okay -- I'll update the fesco ticket to say we punt to them.
17:40:43 <abadger1999> Re: fonts.
17:40:55 <abadger1999> I readthe logs, why are we doing both?
17:41:08 <spot> abadger1999: so that existing packages can be effectively grandfathered
17:41:21 <abadger1999> Doing just one will fix the base problem, though.
17:41:30 <spot> yes, but it is cleaner to do it right.
17:41:35 <abadger1999> Okay.
17:41:42 <abadger1999> +1 then.
17:41:46 <tibbs|h> And less work for those involved to do it simply.
17:42:02 <spot> #action Font macro changes as earlier voted are passed with abadger1999's late +1 vote.
17:42:30 <spot> Are there any other topics for today?
17:42:32 <tibbs|h> I have nothing.
17:42:41 <abadger1999> none from me.
17:42:57 <spot> mdomsch: you submitted a draft for CMPI Plugins
17:43:15 <spot> mdomsch: there are some outstanding questions on the page that should be addressed
17:43:43 <spot> we'll look at it next meeting, hopefully it will be clearer at that point.
17:44:03 <spot> Okay, with that, I'm closing out the meeting. Thanks everyone.
17:44:06 <spot> #endmeeting