15:59:56 <spot> #startmeeting Fedora Packaging Committee
15:59:56 <zodbot> Meeting started Wed Jul 11 15:59:56 2012 UTC.  The chair is spot. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:59:56 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
15:59:59 <spot> #meetingname fpc
15:59:59 <zodbot> The meeting name has been set to 'fpc'
16:00:04 <spot> #topic Roll Call
16:00:18 <tibbs> Howdy.
16:00:29 * geppetto is here
16:00:40 <tibbs> Need to step away for just a couple of minutes.
16:03:17 <tibbs> Back.
16:03:35 <spot> well, i see three of us.
16:03:39 <tibbs> Doesn't look like I missed much.
16:03:57 <geppetto> Meh. … having meetins is overrated anyway
16:04:16 <spot> abadger1999, racor, SmootherFrOgZ, Rathann: fpc ping
16:04:21 <Rathann> here
16:04:23 <abadger1999> pong
16:04:58 <racor> here
16:04:59 <abadger1999> 5 makes quorum
16:05:13 <spot> yep. i assumed racor was present as well, just waiting for him to chime in
16:05:19 <abadger1999> six is even better :-)
16:05:21 <abadger1999> Cool.
16:05:30 <spot> #topic Systemd scriptlet macros - https://fedorahosted.org/fpc/ticket/190
16:05:31 <racor> spot: yes, I just entered ;)
16:06:14 <spot> Basically, what lennart is asking is for us to use the upstream provided macros for the scriptlet cases
16:06:25 <spot> (although, i think they're only in rawhide at the moment)
16:07:11 <geppetto> Seems fine to me.
16:07:20 <spot> the only difference between the macros and the expansion we have now is the support for "packagepresets"
16:07:22 <spot> https://fedoraproject.org/wiki/Features/PackagePresets
16:07:44 <abadger1999> Hmm...
16:07:50 <abadger1999> PackagePresets hasn't gone to fesco yet.
16:07:56 <spot> no, i think it did
16:07:59 <spot> and it was rejected
16:08:01 <spot> NOT APPROVED, vote was +3, -5, 0:0
16:08:18 <spot> FESCo ticket #733: F17 Feature: Package Service Presets - https://fedoraproject.org/wiki/Features/PackagePresets
16:08:19 * abadger1999 must have read old fesco meeting notes.  doh
16:08:21 <nirik> that was for f17, IIRC... they haven't submitted it for f18
16:08:38 <spot> i'm not sure why they rejected it for f17 though
16:08:52 <spot> it seemed okay to me when lennart explained the concept to me roughly 4 months ago
16:09:08 <geppetto> The only weird thing was that everything defaulted to on.
16:09:48 <geppetto> Which seemed very crazy from a sysadmin point of view.
16:10:12 <geppetto> But then everything off isn't much better.
16:10:40 <nirik> http://meetbot.fedoraproject.org/meetbot/teams/fesco/fesco.2012-01-09-18.00.log.html#l-285
16:10:43 <geppetto> If anything though I'd prefer to +1 the macros. and tell him to remove the preset bits.
16:11:06 <spot> "Some core package needs to be updated to include the default fedora preset file which lists the very few services that may be enabled by default according to the current policy for "enable" and "disable *" to disable the rest. Probably should be fedora-release.rpm or a similar file. Basically, the data from https://fedoraproject.org/wiki/Starting_services_by_default needs to be turned into a compliant preset file. "
16:11:09 <nirik> the thought was that it should be supported by more stuff before announcing it.
16:11:14 <spot> doesn't sound like "everything default to on"
16:11:29 <spot> sounds more like "a preset file needs to be generated"
16:11:54 <spot> i don't want to put the cart before the horse here though
16:11:57 <abadger1999> I'm against the systemd_requires macro. The rest seem okay to me.
16:12:20 <spot> i propose we defer approval here pending FESCo feature approval
16:12:56 <geppetto> meh … looks like FESCO just didn't want to announce it, until it was widespread. So it seems bad for us to not allow using it.
16:13:01 <abadger1999> Maybe we should let fesco know whether we're okay with the changes?
16:13:03 <spot> abadger1999: yeah, that macro doesn't seem very useful, and we have avoided macro'izing Requires.
16:13:11 <geppetto> abadger1999: Why not the requires one?
16:13:47 <abadger1999> whenever there's a dependency between a fesco feature and fpc guidelines, there's a chicken-and-egg problem... if we're generally for it; i'd give fesco that information.
16:13:55 <abadger1999> geppetto: What spot said, basically.
16:14:48 <tibbs> I could go either way on that macro.
16:14:51 <spot> including the fact that the macro definition is for a set of Requires on "systemd", not "systemd-units" as present in the existing guidelines
16:14:51 <abadger1999> geppetto: To me, Requires and BuildRequires are things that the package maintainer should be able to easily see in the spec file while writing the package.
16:15:03 <geppetto> abadger1999: Fair enough.
16:15:26 <geppetto> abadger1999: I mean we already have auto. reqs. … but I'm not bothered
16:15:30 <abadger1999> <nod>
16:16:00 <tibbs> Yeah, it would be doubly awesome if rpm could just figure out those dependencies for itself.
16:16:19 <spot> aside from the Requires macro, i'm +1 to the rest of them, assuming that the proper presets are put in place.
16:16:27 <abadger1999> +1 here as well.
16:16:30 <geppetto> +1
16:16:35 <Rathann> +1 to what spot said
16:16:57 <tibbs> +1 spot
16:16:59 <abadger1999> (ie: same conditions as spot)
16:17:16 <racor> +1 spot
16:17:45 <tibbs> I note we're not macroizing the sysv->systemd conversion stuff.
16:17:47 <Rathann> tibbs: ideally, the %pre/post scripts would be parsed for calls to binaries and these would get added to autoreqs
16:18:00 <tibbs> Rathann: Yes, that's what I'm referring to.
16:18:02 <spot> #action All macros except for the Requires macro approved for inclusion in FPC guidelines, assuming that the proper presets are put in place (+1:6, 0:0, -1:0)
16:18:38 <spot> nirik: we'll hold on writing this one up for F18 Feature approval
16:18:58 <nirik> ok. (will try and remember to note that when the feature comes up to fesco)
16:21:04 <racor> How about fedora < 18. I'd like to see an API compatible  fc < 18 macro set, even if it should be a nop, because such "FC > FCX" macro sets usually are causing issues otherwise.
16:21:04 <spot> #topic Systemd Restart=always - https://fedorahosted.org/fpc/ticket/191
16:21:43 <abadger1999> I'd be fine with the macros being pushed back to older Fedoras
16:22:04 <geppetto> yeh, push macros back to all Fedoras that have systemd seems like the better plan.
16:22:08 * spot has no issue with the macros being pushed back as long as they actually work (the presets not being present in f17 or older)
16:22:11 <abadger1999> If it doesn't get pushed back, I'd be fine with the "Use macros on Fedora > X"
16:23:06 <geppetto> 191 annoys me … it seems like something that should just be fixed upstream.
16:23:19 <spot> So, reading through 191, it seems like Requires=on-abort should just be the default in the upstream systemd
16:23:22 <abadger1999> hmm... yeah -- without presets, it would be up to the individual package to know whether it needed enable or not.
16:23:28 <spot> as opposed to mandating it in each unit
16:23:29 <abadger1999> +1
16:23:32 <geppetto> It's not like we need more boilerplate that 99.999% of packages will have to copy and paste (correctly).
16:23:46 <abadger1999> If Lennart explains why not, that's fine too.
16:23:53 <abadger1999> but no explanation was given.
16:24:00 <geppetto> yeh
16:24:01 <tibbs> Right, why go through the whole macroization thing to remove boilerplate only to add more boilerplate elsewhere?
16:24:08 <spot> Proposal: Ask systemd upstream to set "Requires=on-abort" as the default, instead of boilerplating in each unit
16:24:09 <Rathann> agreed, go upstream with that or a Fedora-wide policy config file
16:24:15 <Rathann> not every unit file
16:24:22 <geppetto> spot: +1
16:24:28 <racor> abadger1999: I am sufficiently impressed by rpm's perl filters, to have a different opinion ;)
16:24:38 <tibbs> I suspect it's to not disrupt services which wouldn't work with the new default.
16:25:02 <spot> tibbs: eh, that seems like a lesser amount of trouble to fix than to edit all unit files.
16:25:04 <tibbs> You can add something to one package at a time; changing the default requires turning it off on all packages it breaks at the same time.
16:25:31 <tibbs> But I'm only guessing at the reasoning.
16:25:33 <spot> on-abort is reasonably non-intrusive (IMHO), especially as opposed to on-failure
16:26:09 * spot is +1 for his proposal
16:26:32 <tibbs> +1
16:26:52 <Rathann> which is to use restart=on-abort upstream, right?
16:27:04 <tibbs> [11:24] <spot> Proposal: Ask systemd upstream to set "Requires=on-abort" as the default, instead of boilerplating in each unit
16:27:10 <Rathann> +1
16:28:02 <spot> if they say no, we'll revisit documenting a boilerplate default
16:28:21 * spot notes we are at +4 on this proposal
16:28:50 <abadger1999> +1
16:29:06 <racor> 0, this proposal appears to be too uncooked to me
16:29:30 <spot> #action Ask systemd upstream to set "Requires=on-abort" as the default, instead of boilerplating in each unit. (+1:5, 0:1, -1:0)
16:29:36 <tibbs> To be honest, the systemd folks can change their defaults all they want without consulting us.
16:29:51 <tibbs> So this proposal is just to ask them as a committee to do what they can already do anyway.
16:30:27 <abadger1999> true -- though either we or fesco would get to react to a change that affected how packages install.
16:30:40 <abadger1999> or function on a global scale
16:30:43 <abadger1999> (which this does)
16:31:05 <spot> #topic Systemd Documentation= fields in unit files - https://fedorahosted.org/fpc/ticket/192
16:31:58 <Rathann> is there a draft to look at?
16:32:13 <tibbs> He doesn't like to give us drafts.
16:32:22 <spot> tibbs: an understatement
16:32:31 <spot> but basically, it boils down to something like this:
16:33:12 <tibbs> I mean, I'm +1 to recommending that people use existing features which help the end users.
16:33:15 * SmootherFrOgZ is here (with late -_-)
16:34:50 <spot> "Whenever possible, please include a Documentation= field in your unit file which points to available documentation describing the service being run. If a man page or info page is present in the package, refer to it using "man:/path/to/manpage" or "info:/path/to/infofile" respectively. If the documentation is in plaintext, use "file:/path/to/file". Lastly, if no local documentation exists in the package, but it exists at a url, use the URL (with http://)
16:34:50 <spot> in this field."
16:35:38 <Rathann> and an example would be nice to have too
16:35:41 <tibbs> The field does take multiple URLs.
16:35:53 <Rathann> tibbs: space-delimited?
16:35:59 <tibbs> Yes.
16:36:02 * abadger1999 thinks this seems like creeping featurism but that's really a fesco concern, not FPC.
16:36:16 <spot> "Multiple URIs can be added to the Documentation= field, as a space separated list."
16:36:33 <abadger1999> we should also document or point to documentation on the URI format (at least for man and info)
16:36:43 <tibbs> I think systemv stuff had something like this already, with less integration (like everything else it had).
16:36:49 <abadger1999> are they /path/to/infofile?  or info:page.info ?
16:37:00 <spot> man uri(7) has the details on URIs
16:37:25 <spot> (which i got wrong in my pseudo-draft).
16:37:34 <abadger1999> <nod>
16:39:15 <tibbs> Anyway, that draft seems fine to me (with info: fixed).
16:39:17 <spot> "Whenever possible, please include a Documentation= field in your unit file which points to available documentation describing the service being run. If a man page or info page is present in the package, refer to it using "man:manpage" or "info:infofile" respectively. If the documentation is in plaintext, use "file://path/to/file". Lastly, if no local documentation exists in the package, but it exists at a url, use the URL (with http://) in this field. M
16:39:18 <spot> ultiple URIs can be added to the Documentation= field, as a space separated list. For details on URI definitions and formatting, please refer to the uri(7) manpage (man uri)."
16:39:59 <spot> and i'll make a little example too
16:40:09 <tibbs> +1
16:40:11 <abadger1999> +1
16:40:14 <racor> How far backward compatible is this Doc:-feature, rsp. what will happen when this is used on FC < rawhide
16:40:18 <SmootherFrOgZ> +1
16:40:31 <tibbs> Pretty sure unknown stuff is just ignored.
16:40:39 <spot> racor: yeah, i bet it is just ignored
16:40:57 <spot> its not like it does anything besides print it out anyways
16:41:23 <spot> but, i will ask in the ticket to make sure it won't break older releases
16:41:30 <spot> +1 to my draft
16:41:49 <geppetto> +1, I guess … I don't really like it, but it's documentation … *sigh*
16:41:51 <racor> -1, draft has leaks and needs refinement
16:42:13 <spot> racor: okay, listening. what should we change?
16:42:46 <tibbs> It appears to be completely ignored on F16.
16:42:56 <spot> tibbs: thanks
16:43:11 <tibbs> I added it to one unit here and everything still works; systemctl staus just doesn't show a Docs: element.
16:43:47 <Rathann> +1
16:44:31 <Rathann> provided minimum Fedora version (or systemd version) where it actually works is given
16:44:56 <spot> Rathann: sure.
16:45:39 <Rathann> mentioning it is ignored in older systemd versions is nice, too - packagers can keep one systemd unit across all branches
16:46:04 <spot> okay, that seems appropriate
16:47:20 <racor> Rathann: exactly, this is the point. I want to have the systemd guys to test it and verify the "claim of Doc: being ignored"
16:48:09 <spot> "Fedora 18+ versions of systemd have support for defining documentation in unit files (it is ignored in older releases, so it is safe to keep one systemd unit file across all branches). Whenever possible, please include a Documentation= field in your unit file which points to available documentation describing the service being run. If a man page or info page is present in the package, refer to it using "man:manpage" or "info:infofile" respectively. If t
16:48:09 <spot> he documentation is in plaintext, use "file://path/to/file". Lastly, if no local documentation exists in the package, but it exists at a url, use the URL (with http://) in this field. Multiple URIs can be added to the Documentation= field, as a space separated list. For details on URI definitions and formatting, please refer to the uri(7) manpage (man uri)."
16:48:39 <spot> racor: tibbs just tested it and confirmed that F16 ignores it
16:49:05 * abadger1999 also +1 to the new wording
16:49:11 <spot> +1 to the new wording
16:49:21 <tibbs> Of course, the systemd guys should back that up, but it does appear to be completely ignored in my F16 system, which should be the oldest thing we need to be concerned with.
16:49:28 <Rathann> +1
16:49:29 <SmootherFrOgZ> +1
16:50:20 <geppetto> +1
16:51:10 * spot notes we are at +5 on the new wording, if racor or tibbs would like to go on the record here.
16:51:12 <racor> OK, I change my vote to 0.
16:52:17 <spot> #action Spot's new wording draft approved (+1:5, 0:1, -1:0)
16:52:26 <tibbs> +1 sorry.
16:52:37 <tibbs> Didn't realize I needed to keep voting.
16:53:59 <spot> i have a hard stop in 5 minutes
16:54:18 <spot> so, lets just hit the EASYFIX ticket before we adjourn
16:54:39 <spot> #topic Update hash to SHA256 in ReviewGuidelines - https://fedorahosted.org/fpc/ticket/195
16:54:57 <spot> Anyone opposed to marking this EASYFIX and just doing it, speak now.
16:55:17 <tibbs> I'm having trouble understanding why this even matters, but I've been using sha256 in my reviews for something like four years now.
16:56:02 <abadger1999> Yeah -- I could also have changed it to just say "Use a hashing program like sha256sum for this purpose"... but then I ran across racor's message.
16:56:13 <abadger1999> I'm fine with either wording.
16:57:26 <spot> okay, i'm not hearing any objections to this, marking it EASYFIX
16:58:37 <spot> well, i am out of time today
16:58:40 <spot> thanks everyone
16:58:54 <spot> i'll try to be here next week, but I'm at OSCON, so it may not happen.
16:58:55 <abadger1999> Thank for running the meeting!
16:59:15 <spot> #endmeeting