15:58:17 <spot> #startmeeting Fedora Packaging Committee
15:58:17 <zodbot> Meeting started Wed Jan 26 15:58:17 2011 UTC.  The chair is spot. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:58:17 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
15:58:20 <spot> #meetingname fpc
15:58:20 <zodbot> The meeting name has been set to 'fpc'
15:58:24 <spot> #topic Roll Call
15:58:54 <tibbs|h> I'm here.
15:59:08 <tibbs|h> Early, even.
15:59:16 * limburgher is here
16:00:24 <Rathann> I'm here
16:01:11 * spot is here
16:01:39 <spot> abadger1999, Smoother1rOgZ: ping?
16:01:51 <abadger1999> spot: here
16:03:52 <spot> i will give racor another minute or two
16:03:56 <spot> and then we'll get started
16:04:00 * geppetto nods
16:06:40 <spot> okay.
16:06:54 <spot> #topic Services which may autostart
16:07:07 <spot> Did we hear clarification from FESCo on this topic?
16:07:22 <limburgher> Oh sweet chili con queso. . .
16:07:24 <spot> nirik: ?
16:07:27 <tibbs|h> I'm not sure fesco even talked about it last week.
16:07:40 <spot> okay. then we'll let it slip by for now.
16:07:41 <nirik> we didn't get to it last week. ;)
16:07:41 <abadger1999> I don't think they did
16:07:49 <nirik> well, a bit in open floor, but thats it.
16:08:02 <abadger1999> spot: fesco ticket is now open for it
16:08:17 <spot> #topic Systemd - https://fedorahosted.org/fpc/ticket/31 - https://fedoraproject.org/wiki/TomCallaway/Systemd_Revised_Draft
16:08:18 <geppetto> spot: nirik said they already had a rule about us "owning" it
16:08:32 <abadger1999> maru-nage
16:08:35 <abadger1999> https://fedorahosted.org/fesco/ticket/544
16:08:45 * abadger1999 gets the correct clipboard paste action
16:09:10 <spot> so, i spoke to lennart about the remaining issues in the draft
16:09:16 <spot> and he helped resolve most of them
16:09:45 <spot> there were two outstanding "TODOs" in the draft
16:09:56 <spot> 1) Clarify language in the Bus Activation section
16:10:34 <spot> lennart did add another chunk of text there to describe the non-disableable case
16:11:21 <spot> 2) The comments about daemon-reload
16:11:45 <spot> Lennart did point out that he is not very interested in supporting going from a unit file back to a sysvinit script
16:12:24 <geppetto> That's seems fine
16:12:41 <spot> Also, the trigger is back. I hate triggers with the passion of a thousand suns, but i can't think of a better way to do it.
16:13:16 <racor> spot: As I tried to tell you on PM, my primary issue with all this is F14 having 79 service on by default, while you are listing only 5.
16:13:30 <racor> This longs for an explanation.
16:13:46 <geppetto> Why does it need to be triggerun, and not just postun?
16:14:13 <spot> geppetto: because it only needs to be run once.
16:14:21 <tibbs|h> The postun that runs is from the old package, isn't it?
16:15:16 <spot> racor: we'll definitely discuss that if/when FESCo hands it over to us.
16:15:19 <abadger1999> spot: For runs once... why not have it check if a sysv init script ispresent?
16:15:38 <racor> spot: Inacceptable to me.
16:16:11 <spot> racor: well, as of this very moment, the issue of what is enabled by default is a FESCo responsibility, so i would recommend you take it up with them.
16:16:33 <abadger1999> racor: I think spot is saying that you voted to hand the decision to fesco last week -- if you want to influence the list, you now need to talk to fesco.
16:16:34 <racor> we need to understand what we are discussing here (e.g. which runlevel equivalent are we talking about)
16:16:46 <spot> racor: right now, we're talking about systemd
16:16:54 <limburgher> As I recall, we were going to develop the policy around the list, and ignore what the list actually was (mostly).
16:16:54 <geppetto> spot: according to nirik FESCO thinks it's us: "<nirik> we had: "Default is off, exceptions exist to allow proper functioning of the os. FPC to document exceptions and process exception requests." fwiw.
16:16:55 <racor> otherwise this all is a waste of time
16:17:31 <tibbs|h> And... derailed.
16:18:19 <spot> abadger1999: so, what the trigger does is this: if upgrading from a sysvinit only version of a package, use chkconfig to see if it is enabled, and if so, enable the unit file.
16:19:50 <spot> i couldn't come up with a way to do that without the trigger, and I'm not sure we want to always loop through the rest of the logic
16:20:19 <spot> (e.g. is it enabled with chkconfig (yes), enable the unit file, next update, is it enabled with chkconfig (yes), enable the unit file)
16:21:01 <geppetto> It just seems like it'd be better to disable it in chkconfig … or create another file somewhere, or something
16:21:41 <spot> geppetto: chkconfig was retooled to work with systemd, remember
16:21:48 <abadger1999> I think %post will do it:  %post of new package: check if a syvinit script is present, if so use chkconfig to see if it is enabled, if so enable the unit file
16:22:05 <tibbs|h> I think %post is cleaner even if it does run every time.
16:22:09 * geppetto nods
16:22:16 <spot> okay, i can see that
16:22:21 <tibbs|h> Though we should document how long that stuff needs to stick around.
16:22:44 <limburgher> Will upgraded systems switch from sysvinit to systemd?
16:22:57 <limburgher> Automagically I mean?
16:22:57 <tibbs|h> That's the point, I thought.
16:22:59 <spot> limburgher: i believe that is the plan.
16:23:04 <geppetto> The other way would be to create a new sub-package for the unit file … and have that do it's thing on %post (but only when installed) … and then use obsoletes/requires
16:23:08 <tibbs|h> I mean, my rawhide VM did when the switch happened.
16:23:12 <limburgher> Ok, then only 1-2 releases, then.
16:23:26 * geppetto nods
16:23:45 <abadger1999> The base init system in F15 will be systemd.  Then individual packages will switch init systems when they start installing a systemd unit instead of sysv script.
16:24:20 <abadger1999> Welll......
16:24:22 <abadger1999> So actually.
16:24:32 <tibbs|h> Just to ask, is it not appropriate to say "you may need to re-enable some services after upgrade"?
16:24:32 <abadger1999> I think this is something we'd want to coordinate more
16:24:53 <spot> if [ -f %{_initddir}/httpd ] ; then
16:25:03 <spot> if /sbin/chkconfig httpd ; then
16:25:07 <abadger1999> b/c every instance of dropping the %post/%trigger will mean that a yum update from F-ancient will encounter that as an issue.
16:25:10 <spot> /bin/systemctl enable httpd.service >/dev/null 2>&1 || :
16:25:10 <spot> fi
16:25:13 <spot> fi
16:25:52 <abadger1999> So maybe we'd want to wait until all services are shipping unit files, then remove the extra scriptlet for the next release (all at one time).
16:25:53 <tibbs|h> yum update from F-ancient isn't supported though.
16:26:05 <tibbs|h> And the worst that happens if you have to reenable something.
16:26:09 <tibbs|h> is
16:26:12 <spot> we can open a ticket to revisit the removal of this particular scriptlet in F17
16:26:25 <abadger1999> yeah -- but it makes documenting it harder than it needs to be.
16:27:16 * rdieter_work pops in, sorry I'm tardy
16:27:28 <abadger1999> whoever maintains the page on what versions can safely be skipped will have to note when each particular service switched to systemd unit files and when they removed the scriptlets.
16:27:33 <limburgher> No, we only support yum update from ancient to ancient+1 to ancient+2....current.
16:27:38 <tibbs|h> My concern is that {_initddir}/httpd won't exist when the new package's %post runs.
16:28:05 <abadger1999> If I was right when I wrote this up: https://fedoraproject.org/wiki/Packaging:ScriptletSnippets#Scriptlet_Ordering
16:28:10 <abadger1999> Then it should.
16:28:30 <abadger1999> The package removal step happens after the %post of the new package is run
16:28:54 <tibbs|h> Hopefully so. I just haven't tested it personally.
16:28:56 <tibbs|h> BTW, comcast is dropping out again.
16:28:58 <abadger1999> <nod>
16:29:16 <geppetto> abadger1999: that seems right
16:29:39 * spot has added the new %post scriptlet and dropped the triggerun
16:29:52 <spot> please make sure i didn't do it wrong
16:31:02 <spot> also, i think we do need to run daemon-reload unconditionally in %post
16:31:32 <rdieter_work> likes right to me
16:32:14 * spot makes that change too
16:32:52 <rdieter_work> spot: that could go in %posttrans too
16:33:17 <rdieter_work> %post is safer though, nvm
16:33:28 <abadger1999> Looks good to me -- do we want to take as homework testing the scriptlets and then vote next week?
16:33:38 <geppetto> spot: So what does the daemon-reload do on removal?
16:33:44 <tibbs|h> So for a regular update of a systemd-supporting package, does daemon-reload happen twice?
16:33:50 <tibbs|h> And if so, is that a problem?
16:34:01 <spot> tibbs|h: yes, and it should not be a problem
16:34:23 <tibbs|h> Hopefully restarting the daemon doesn't take too long.
16:34:30 <spot> geppetto: the unit file is gone, but systemd doesn't know until the daemon-reload happens
16:34:35 <geppetto> spot: ok
16:34:43 <geppetto> tibbs|h: daemon-reload != try-restart
16:34:53 <geppetto> tibbs|h: The daemon-reload is just the systemd part
16:34:57 <geppetto> AIUI
16:35:00 <tibbs|h> Ah, of course.
16:35:04 <spot> i think it is roughly equiv to a SIGHUP
16:35:13 <tibbs|h> New random terminology unrelated to existing terminology FTW.
16:35:20 <geppetto> yeh
16:35:52 <geppetto> I am confused about why we are doign it in %post … but, it's probably harmless
16:36:15 <tibbs|h> Because you may have just installed a unit, and want systemd to see it.
16:36:29 <spot> geppetto: if it ends up being a problem, we can work out much more complicated scriptlets
16:36:51 <geppetto> Also … given that 99% of packages using this are going to have identical scriplets as the example, with s/httpd/%{name}/ … what does everyone think of creating some "default" scriptlets … and shipping them in systemd or a fedora package?
16:36:53 <tibbs|h> Aside from the odd indentation, that looks good to me though I'll have to try it out.
16:37:16 <tibbs|h> I would seriously love to see some simple default scriptlets accessible with a macro.
16:37:28 <spot> geppetto: sounds like you're volunteering to test that
16:37:42 <abadger1999> ehh... I've gotten less enthused about function-macros of late.
16:37:58 <geppetto> haha :) … sure, I was thinking more of something like: %post\n/usr/share/systemd/default-post httpd … or something
16:38:15 <tibbs|h> I'm far less enthused about package maintainers having to care about the innermost details of this kind of thing.
16:38:21 <abadger1999> but maybe that's something we decide as a whole which direction we want to move in and then do it consistently.
16:38:27 <geppetto> I can create the three scriptlets, and update the wiki … but I'm not sure where they should go … any ideas?
16:38:28 <abadger1999> <nod>
16:38:44 <spot> geppetto: redhat-rpm-config is the normal place
16:39:02 <geppetto> spot: Ok, just means every service would have to require that
16:39:14 <spot> geppetto: well, we could put them in systemd-units
16:39:30 <spot> but we need to define %{_unitdir} somewhere anyways
16:39:33 * geppetto nods … if they don't mind, that's probably the best place
16:39:56 <spot> and that is probably more correct in redhat-rpm-conig
16:39:59 <spot> config, rather
16:40:06 <geppetto> Putting that in redhat-rpm-config is different though, it only needs to be installed for builds
16:40:20 <spot> geppetto: okay.
16:40:33 <spot> that makes sense to me
16:40:46 <spot> so, lets do this: geppetto will test macro'izing the scriptlets
16:40:57 <geppetto> Ok, I guess I'll speak to lennart about adding some scripts
16:41:04 <spot> the rest of us (as available) will test the rest of the document in real world packaging
16:41:13 <spot> we'll revisit it next week
16:42:11 <spot> #topic Declare md5.c a copylib - https://fedorahosted.org/fpc/ticket/47
16:42:22 <tibbs|h> I honestly don't know what to do about this.
16:42:37 <geppetto> the security guys never replied
16:42:56 <geppetto> I'm still inclined to -1 it
16:43:02 <tibbs|h> The maintainer of the package in question offered to split "his" md5.c out into another package.
16:43:20 <geppetto> It would be nice if "someone" would write a nice API everyone could use instead of bundling
16:43:20 <spot> fwiw, as much as i dislike copylibs, this behavior is incredibly common.
16:43:36 <tibbs|h> I'm not sure if -1 means address these as they come up or just ban these packages altogether.
16:43:37 <racor> geppetto: I have to ask again: What do you want to use packages instead?
16:43:38 <spot> if anything meets the criteria of a copylib, md5 is it.
16:44:05 <geppetto> tibbs|h: -1 for explicitly saying that bundling md5.c is fine
16:44:36 <geppetto> spot: there is that … but at the same time, if anything meets the criteria of common code that everything should be sharing, md5 is it
16:44:41 <tibbs|h> Then the question is that since every use is essentially the same, why do we want to have the same questions answered each time?
16:45:10 <spot> geppetto: to be fair, openssl has an MD5 API
16:45:13 <Rathann> I'd be ok with copylibs in build environment code, but not packaged code
16:45:22 <spot> and i'd wager that multiple other crypto libs do too
16:46:12 <geppetto> Rathann: yeh, I'd be fine with a blanket exception for packages to bundle md5.c for their builds, or for platforms where there is nothing native … but for Fedora I'd want them to use openssl, or something
16:46:13 * rdieter_work agrees with spot, believes copylib criteria met in this case, for better or worse
16:46:33 <tibbs|h> Asking people to use openssl is not practical.
16:46:40 <tibbs|h> I mean, it doesn't even have a stable API.
16:46:45 <racor> geppetto: right, but again: What is the alternative? Probably you will want to launch a new project or to persuade the glibc folk?
16:47:05 <abadger1999> libmd seems to exist for POSIX systems in general: http://martin.hinner.info/libmd/
16:47:06 <geppetto> racor: yeh, that's the sucky part … telling people to use openssl is not nice, I agree
16:47:44 <geppetto> racor: but we don't want people bundling, just because the API options aren't appealing
16:48:05 <tibbs|h> Of course it probably won't have the same API as the various md5.c bits that people are bundling.
16:48:23 * spot notes that libmd does not appear to be packaged in Fedora
16:48:25 <racor> IIRC, libmd originates from the BSDs. They have it for ages (decades, IIRC)
16:48:25 <tibbs|h> But if libmd were actually in the distro it would be reasonable to point folks there.
16:48:39 <spot> which implies that it may not be widely used...
16:49:36 <abadger1999> <nod> or code has #ifdef BSD libmdapicall #else mybundledapi
16:49:50 <geppetto> what I hoped for was something like: http://opensource.apple.com/source/text_cmds/text_cmds-18/md5/libmd.c … which probably isn't usable due to licensing
16:50:03 <Rathann> a list of known implementations: http://userpages.umbc.edu/~mabzug1/cs/md5/md5.html
16:50:11 <geppetto> even though any other implmentation is probably going to be identical
16:51:30 <spot> so, i think the answer here is "Whenever reasonable, try to leverage existing md5 provider libraries (openssl, libmd), but md5 implementations are otherwise considered a copylib, and packages that include them should have Provides: bundled(md5)."
16:52:15 <geppetto> spot: It sure feels like nobody is going to try very hard on the first point
16:52:29 <spot> geppetto: yes, but we know that already.
16:52:43 <spot> (which is why i am less than thrilled about being in charge of this stuff, but i digress)
16:52:59 <tibbs|h> I mean, we could conceivably break out the various mc5.c things into their own libraries.
16:53:12 <spot> tibbs|h: if you're volunteering to do that, then hey, but i'm not.
16:53:30 <Rathann> in most occasions, it should even be trivial to port the apps to use libmd
16:53:37 <tibbs|h> Well, it was offered in the ticket I was reviewing.
16:53:56 <Rathann> so I'd add a note to contact upstream about it
16:54:07 <tibbs|h> Of course we don't have libmd.
16:54:11 <spot> we can mandate that everything be ported to libmd or openssl (or other crypto library with md5 API).
16:54:14 <tibbs|h> So step one is to package it.
16:54:15 <racor> From what I could gather from a hasty glimpse in to freebsd's CVS libmd's origins date back to 1994
16:54:20 <spot> but i can hear the screaming from here.
16:54:55 <Rathann> also, libmd is ancient
16:55:12 <tibbs|h> Not that the md5 implementations it would replace are any newer.
16:55:38 <tibbs|h> I think it's probably a wash.
16:56:04 <Rathann> it'd be nice to have a single, optimized implementation and have everyone use it
16:56:33 <spot> Rathann: we must balance our desire for utopia with the coldness of reality. :)
16:56:35 <tibbs|h> Sure, but that boat sailed ages ago when the glibc folks refused.
16:56:37 <geppetto> yeh, idealy we'd have a wrapper API that called openssl (or NSS) … and have it export a stable/usable API everyone could call
16:56:38 <abadger1999> I think that this is a copylib.  We wrote the copylib information because we were more concerned about convenience than security.  I think if we want people to switch over to non-copylib versions of md5, then that needs to be a concerted effort by someone to choose a replacement and make patches.
16:56:53 <geppetto> I'm almost willing to volunteer to write it
16:56:59 <spot> i'm willing to package up libmd
16:57:12 <abadger1999> Like the people pushing for nss everywhere doing that.
16:57:12 <geppetto> spot: the FreeBSD one?
16:57:19 <tibbs|h> A review should be trivial.
16:57:20 <spot> geppetto: thats the only one i know of.
16:57:38 <spot> http://martin.hinner.info/libmd/
16:57:47 <geppetto> spot: Ok, just making sure yoou didn't mean: http://martin.hinner.info/libmd/
16:57:58 <tibbs|h> ...
16:58:06 <geppetto> spot: Ok, you do mean that one :)
16:58:17 <spot> geppetto: yeah, i'm not going to report the FBSD code
16:58:31 <spot> re-port, rather.
16:58:42 <geppetto> Anyway, yeh, it's fine by me … import that, and tell everyone they can use it or openssl
16:58:47 <abadger1999> If we have programs that bundle it use Provides: bundled(md5)  [maybe we should spell out what the name is?] then the security team/a porting team can find the instances of this at a later time.
16:58:48 <geppetto> +1
16:58:51 <spot> in fact, i seem to recall having packaged it once myself then abandoning it later
16:58:57 <geppetto> And I'll happily ignore the screaming :)
16:59:23 <tibbs|h> Yes, bundled(md5-deutsch) or bundled(md5-plumb).
16:59:36 <Rathann> this one seems newer: http://256.com/sources/md5/
16:59:37 <tibbs|h> For the two cases I found in a couple of minutes of looking at packages already in the distro.
17:00:13 <geppetto> Rathann: that's just md5 though
17:00:20 <Rathann> yeah
17:00:57 <spot> so... it feels like we have two proposals, one to require use of a common, available md5 lib
17:00:59 <tibbs|h> It's not as if we didn't know we were going to run into something like this when we decided to ban bundled libraries.
17:01:14 <spot> and one to encourage the use of a common available md5 lib, but permit the copylib bundling
17:01:22 <limburgher> tibbs|h: It was still the right move.
17:01:24 <racor> I am sure you will enforce these to use your new lib rpm -qf /usr/bin/sha256sum /usr/bin/md5sum
17:01:27 * racor ducks
17:01:50 <spot> racor: a valid point.
17:01:51 <Rathann> looks like libmd has made it into solaris
17:01:57 <Rathann> http://hub.opensolaris.org/bin/view/Project+crypto/libmd
17:01:57 <geppetto> spot: THE BEER-WARE LICENSE
17:03:25 <spot> https://fedoraproject.org/wiki/Licensing/Beerware
17:03:30 <abadger1999> +1 on copylib, document Provides name, okay to have a note (but not a requirement) that b/c this is security sensitive code we encourage people to port to a widely used library instead.
17:04:20 <geppetto> -1 on copylib
17:04:26 <abadger1999> Also, give a heads up to whoever is the "security team" that we've done this and where they can find the virtual provides... what they do with that from there is up to them.
17:04:29 <spot> abadger1999: the amount of that makes me really want to see a draft before i vote
17:04:38 <tibbs|h> +1, and noting that once we at least have these annotated, someone who is interested can work to port these apps to some common library.
17:06:46 <rdieter_work> +1 copylib
17:06:49 <racor> +1 to allow as copylib
17:07:08 <spot> +1 copylib
17:07:13 * rdieter_work thinks documenting efforts to use a common library, while noble, falls outside our scope
17:07:14 <limburgher> Reluctant +1
17:07:44 <spot> i remember now why i didn't finish libmd
17:07:52 <spot> it has an MD2 implementation that is non-free
17:07:58 <racor> tibbs|h: to me it would be consequent, if coreutils or gilibc would export some kind of libmd
17:08:41 <racor> s/gilibc/glibc/
17:08:55 <Rathann> +1 to allow as copylib, someone can go through the virtual provides and unbundle it later
17:09:32 <spot> #action md5 is a copylib, needs to be indicated with specific provides (+1:7, 0:0, -1:1)
17:09:39 <tibbs|h> Personally I don't care where the libmd comes from as long as it exists.
17:10:09 <geppetto> Well doesn't matter too much now :)
17:10:14 <racor> tibbs|h: API, portability, license .. all issues with FreeBSD's libmd
17:10:30 <geppetto> spot: How is the apple public license?
17:10:39 <spot> geppetto: depends on the version
17:11:00 <spot> lets move on, try to get through one more ticket before FESCo bounces us out
17:11:05 * geppetto nods
17:11:14 <spot> #topic Naming guideline for non-top-level python modules - https://fedorahosted.org/fpc/ticket/49
17:11:28 <spot> "The implicit rule followed by all existing packages is substituting the dots('.') with minuses('-') and prefixing 'python-'. For example, the rpm for zope.interface is named 'python-zope-interface'. I hope this can be written out if proper. "
17:12:03 <geppetto> yeh, this seems like a no-brainer … are any packages doing anything different?
17:12:04 <spot> part of this is already documented: https://fedoraproject.org/wiki/Packaging/NamingGuidelines#Separators
17:12:11 <Rathann> s/minus/dash/ ?
17:12:15 <spot> which says that you can't use a period as a separator
17:12:44 <Rathann> indeed
17:13:09 <spot> also: https://fedoraproject.org/wiki/Packaging/NamingGuidelines#Addon_Packages_.28python_modules.29
17:13:30 <spot> so, i honestly think we have this covered
17:14:15 <spot> i think what the reporter thinks is an implicit rule is actually the documented guidelines
17:14:26 <abadger1999> <nod>
17:14:44 <abadger1999> related to this -- I was asked whether compat libs using "." are proper earlier this week
17:14:48 <tibbs|h> He asked because I asked in a review ticket, FWIW.
17:14:49 <geppetto> spot: it might be worth having an example showing a $NAME that has a minus/dash/hyphen/whatever in it … but, yeh
17:14:54 <abadger1999> ie: python-turbojson13 vs python-turbojson1.3
17:15:00 <geppetto> spot: I certainly wouldn't expect anyone to do anything other than that
17:15:15 <spot> abadger1999: i think the answer is no, but we could probably argue about it
17:15:52 <abadger1999> I couldn't think of a reason it wouldn't be proper but it seemed like the guidelines said it wasn't.
17:15:54 <spot> i can see that there is a possibility for confusion
17:15:59 <geppetto> without the dot it gets messy when you have 12.4 etc.
17:16:05 <spot> geppetto: exactly
17:16:16 <spot> so, technically, the . is not being used as a separator
17:16:21 <abadger1999> <nod>
17:16:36 <spot> so the compat lib use doesn't fall into it
17:16:49 <geppetto> that works for me :)
17:17:28 <limburgher> Seems rational.
17:18:52 <spot> i'm going to open the floor now
17:18:57 <abadger1999> Okay, so proposal, two clarifications: 1) In python guidelines: "When a module has a dot in its name, the usual rule about changing "." to "-" applies [LINK]"
17:18:59 <spot> we only have about 10 minutes though, so keep that in mind
17:19:23 * spot waits for abadger1999's proposals
17:19:43 <abadger1999> and 2) In the dot-dash section, "Version numbers used in compat libraries do not need to omit the dot or  change it into a dash"
17:19:49 <spot> +1 to both from me
17:19:52 <abadger1999> +1
17:20:06 <tibbs|h> +1
17:20:10 <Rathann> +1 to both
17:20:10 <racor> +1
17:20:13 <limburgher> +1
17:20:41 <abadger1999> Cool.  I'll write it up.
17:20:41 <geppetto> +1
17:21:09 <abadger1999> err... make the changes (just to be cleear :-)
17:21:27 <spot> #action abadger1999's clarifications approved (+1:7, 0:0, -1:0)
17:21:49 <spot> abadger1999: i put them in ticket 49
17:21:55 <spot> #topic Open Floor
17:22:05 <spot> any real quick items of business?
17:22:14 <Rathann> nothing from me
17:22:17 <limburgher> Not I, said the duck.
17:22:21 <tibbs|h> Nope.
17:22:31 <abadger1999> none here
17:23:02 <spot> okay, thanks everyone
17:23:08 <spot> dont forget to test systemd draft out
17:23:14 <spot> #endmeeting