fpc
LOGS
15:57:51 <spot> #startmeeting Fedora Packaging Committee
15:57:51 <zodbot> Meeting started Wed Mar 27 15:57:51 2013 UTC.  The chair is spot. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:57:51 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
15:57:55 <spot> #meetingname fpc
15:57:55 <zodbot> The meeting name has been set to 'fpc'
15:58:06 <spot> wow, its been so long since i've done that, i almost forgot the commands. :0
15:58:13 <spot> #topic Roll Call
15:59:04 <spot> abadger1999: did we change meeting rooms?
15:59:21 <abadger1999> Bleagh -- just me in the wrong room.
15:59:23 * abadger1999 here
16:00:09 <spot> geppetto, limburgher, rdieter, tibbs, Smoother1rOgZ: ping
16:00:35 * limburgher here.
16:01:31 <rdieter> hola
16:01:49 * geppetto is here
16:02:04 <spot> thats 5! quorum!
16:02:38 <spot> #topic Revision to Haskell Packaging Guidelines - https://fedorahosted.org/fpc/ticket/194
16:02:47 <spot> This ticket has been outstanding for a LONG time. :/
16:03:13 <spot> diff is here: https://fedoraproject.org/w/index.php?title=PackagingDrafts/Haskell&diff=321552&oldid=81838
16:03:13 <tibbs> Howdy.
16:05:03 <spot> I'm not personally the biggest fan of rpm macroizing like this, but since it seems to be identical for all Haskell packages of their type, and it is reasonably easy to override (just don't use the macro)
16:06:04 <tibbs> Personally I wish the templates were actually in the guidelines.
16:06:08 <limburgher> Right.  Beats defining a macro the same way in each spec and then only using it once.  Not. . .that. . .anyone. . .ever. . .sorry, what were we talking about?
16:06:46 <rdieter> that's quite a big diff
16:06:56 <spot> It is, which is why we bounced it the first time
16:06:58 <tibbs> It's basically "toss the old guidelines and start over".
16:07:06 <spot> but i think it actually simplified things quite a bit.
16:07:13 <abadger1999> Should the static libraries be separate from -devel?
16:07:22 <limburgher> From what I can see, no.
16:07:24 <rdieter> spot: true
16:07:28 <tibbs> Which isn't necessarily a bad thing; if you click through to the templates you'll see they're much cleaner as long as you don't mind the macros.
16:08:13 <spot> "Because GHC still assumes static versions of libraries are installed they need to be in the devel subpackage and it doesn't make sense to subpackage them yet. "
16:08:20 <spot> I'm inclined to let this go as is.
16:08:41 <spot> this is still an evolutionary step in the right direction
16:08:54 <limburgher> Perfect being the enemy of good, I'm with spot.
16:09:05 <spot> So, I'm +1 on this draft.
16:09:41 <limburgher> +!
16:09:47 <geppetto> A minor nit thing is that it might be easier if they didn't comma separate some of the macros. and just put them each on a different line/whatever.
16:09:47 <limburgher> Which is like +1
16:09:52 <geppetto> But, meh, I'm +1 anyway.
16:10:00 <tibbs> Yeah, I'm mostly fine with this except that I think we should at least decide in general if it's OK for the templates to live outside of the actual guidelines.
16:10:13 <spot> tibbs: we already have other guidelines doing that
16:11:02 <tibbs> Not really sure we should, though.  Pretty sure I objected to it then, though.
16:11:12 <tibbs> But, in any case, I guess that's an argument for another day.
16:11:19 * spot isn't that concerned about the disconnect, if someone wants to make templates that don't reflect the guidelines, we can escalate it to FESCo.
16:11:25 <tibbs> So I guess +1 for me.
16:11:52 <geppetto> Might be worth asking why they have the templates outside?
16:12:00 <spot> I see +4 on this, abadger1999 & rdieter have not yet voted.
16:12:09 * abadger1999 still reading
16:12:19 <tibbs> We can always paste them in later if we decide to do so.
16:12:26 <spot> abadger1999: thats fine, just noting the vote tally, mostly for my own sanity. :)
16:12:49 <rdieter> +1
16:14:52 <abadger1999> tibbs: You said there was a template somewhere?
16:15:21 <tibbs> The "spec file templates" section at the top has links to the templates.
16:15:27 <abadger1999> oh I see.
16:15:56 <abadger1999> +1 if we move the templates into the Packaging: namespace.
16:16:12 <tibbs> I think it bears mentioning that they've been using these guidelines for ages already anyway.
16:16:23 <spot> #action Haskell Draft Guidelines approved (+1:6, 0:0, -1:0)
16:16:36 <spot> we'll just move copies of the templates into the Packaging: namespace
16:16:42 <abadger1999> <nod>
16:17:17 <abadger1999> oh wait
16:17:20 <abadger1999> I see something wrong
16:17:29 <spot> ?
16:17:37 <abadger1999> %ghc_devel_post_postun => needs to be broken into two macros
16:18:00 <spot> ah. good point.
16:18:08 <abadger1999> Each scriptlet section should have its own "header" in the spec files and then you can use a macro within that section
16:18:09 <abadger1999> ie:
16:18:11 <abadger1999> %post
16:18:17 <limburgher> So people can customize post and postun without doing both.  good catch.
16:18:18 <abadger1999> %ghc_devel_post
16:18:31 <tibbs> Oh, hmm, I didn't see that through all of the macroization.
16:18:53 <tibbs> Yeah, a macro should never actually include the %build, %post, whatever headers.
16:20:27 <abadger1999> just a question since I don't know -- how do you make multiline macros in a spec file?
16:20:28 <tibbs> Looking again at the second and third templates, I do have to say it's way excessively macroized.  What to do?
16:20:45 <abadger1999> I'm wondering how %common_description needs to be written
16:20:47 <tibbs> You just backwhack the newlines.
16:21:09 <abadger1999> Okay -- and that properly adds newlines in the rpm -qi output?
16:21:23 <abadger1999> or does it make a one-line %description?
16:21:25 <tibbs> So maybe we were too quick.  I only really looked at the first template, which looks pretty much fine to me.
16:23:15 <abadger1999> yeah, at the least, I'd consider things like %package devel to be a "header" as well
16:24:09 * spot could go either way on that
16:24:16 <geppetto> I thought if you wanted the newlines you had to do: \n\
16:24:19 <abadger1999> it doesn't appear they have more than one header in those macros so it wouldn't affect customization but it does affect readability
16:24:21 <tibbs> But do note that if we're going to get into that, we probably have to take a hard look at some other guidelines like the font stuff.
16:24:47 <tibbs> Right, if you can't even tell where the sections start because of macros, something is being lost.
16:24:59 <abadger1999> tibbs: I was actually thinking of the times we told the font sig to change their guidelines as precedent for this.
16:25:05 <abadger1999> :-)
16:26:37 <abadger1999> The order in those templates is also funny, %build and %install are being done before the meta-data (%package) sections
16:27:03 <tibbs> Ugh, I should have checked the other two templates more closely.
16:27:10 <spot> order is semantic. it really doesn't matter.
16:27:26 <tibbs> Not really, but again we should try to be consistent.
16:27:35 <geppetto> Being different for no reason isn't a great idea though.
16:27:55 * geppetto also only checked the first template … :(
16:28:19 <abadger1999> %ghc_files is also including "%files devel" type stuff
16:28:28 <tibbs> I guess it's official vote changing time.  Currently I have to go to -1 on this until I look over it more closely.
16:28:48 <spot> does anyone else want to pull their vote?
16:28:51 <abadger1999> <nod> -1 -- I think the changes would be reasonably  easy to do
16:29:03 <abadger1999> but I do want those things fixed.
16:29:21 <abadger1999> and they have to be fixed in the macros as well as in the guidelines.
16:29:24 <tibbs> I kind of feel bad for the haskell folks now, because they really deserved to know this shortly after they submitted the guideline.
16:29:36 <tibbs> But that's as much my fault as it is anyone else's.
16:30:57 <spot> is anyone willing to propose what a fixed version might look like?
16:31:41 <geppetto> Not sure we should … esp. given how different the first template is to the other two.
16:31:49 * rdieter is confused.  is the guideline draft broke or the templates?  or both?
16:31:59 <spot> I think it is the macros, tbh.
16:32:05 <rdieter> k
16:32:10 <spot> If the macros didn't pull in the headers, would we approve it?
16:32:30 <abadger1999> spot: I could write up what I think we'd want to have changed in the ticket -- I won't rewrite the guidelines themselves (at this time) though.... I'm hoping the haskell sig/ghc maintainer will do the macro rewriting.
16:32:48 <spot> abadger1999: okay, then i'll note that you will be following up in the ticket.
16:32:55 <abadger1999> Cool.
16:34:28 <spot> #action Haskell Draft reset to review (due to changed votes)
16:34:43 <spot> #topic Packaging Cron Jobs - https://fedorahosted.org/fpc/ticket/261
16:34:57 <spot> Draft is here: https://fedoraproject.org/wiki/User:Johannbg/Packaging/CronFiles
16:35:15 <spot> I like 95% of this.
16:35:24 <spot> The 5% I don't care for is the required subpackaging.
16:35:27 <spot> Just seems silly.
16:36:08 <rdieter> agreed
16:36:09 <limburgher> Yeah, I don't see the gain.
16:36:21 <spot> I think we can keep the Requires: crontab and the %config files entry and lose the subpackage
16:36:54 <tibbs> What was the justification for the subpackaging?  I agree it seems kind of pointless.
16:37:08 <spot> I guess if you didn't want to run the cronjob by default?
16:37:11 * spot shrugs
16:37:13 <tibbs> Some programs might not be useful at all without their cron job.
16:37:17 <geppetto> spot: I believe that's there so you can "remove" the cron script easily
16:37:26 <spot> geppetto: rm works wonders. :)
16:37:35 <geppetto> spot: upgrade breaks that
16:37:56 <spot> geppetto: but in this case, it means users will have to know that a cron-foo package exists
16:37:57 <tibbs> config(noreplace), though.
16:38:10 <tibbs> What does that do with a file that's been removed?
16:38:25 <geppetto> puts it back, IIRC
16:38:28 <tibbs> Honestly, adding a '#' at the start still works great, though.
16:38:29 * spot has no idea, and I'm not really willing to go into RPM to find out
16:38:45 <limburgher> config(noreplace)?
16:38:53 <geppetto> You can alter it … to comment it out, but that's much more annoying than dealing with the packages, IMO.
16:39:09 <tibbs> To be honest, I personally think that the solution to easily-disableable cron jobs is to move them to systemd.
16:39:28 * spot is not even going to step on that landmine.
16:39:49 <abadger1999> anyone know the justification of the "and does not ship systemd unit file, " requirement?
16:39:58 <tibbs> Trying to hack around the fact that we have no disable mechanism besides "comment it out" by using subpackages isn't great.
16:40:12 <rdieter> is there some usecase for someone really not wanting crontab installed?
16:40:23 * rdieter can't think of any, but...
16:40:26 <tibbs> Well, a minimal system, I guess.
16:40:31 <geppetto> tibbs: At that point, why not just have the packaging guides just be "use systemd timers"?
16:40:32 <limburgher> Is it so they can avoid the massive bloat of a crond?
16:41:16 * abadger1999 adds justification for the Requires: crontabs
16:41:30 <tibbs> geppetto: Well, I think you can say "if you want to have a cron job that can be easily disabled by the admin using the usual mechanisms for disabling services, you can do A or B."
16:41:53 <tibbs> Where B is switch to systemd and A is the nasty thing where you have a service that sets a lock file which is checked by the cron job.
16:41:56 <geppetto> tibbs: I just don't see the advantage of shipping two types of system cron jobs.
16:42:11 <rdieter> hrm, according to repoquery, no package provides crontab
16:42:13 <tibbs> But that's getting way too complicated for a basic guideline, I think.
16:42:17 <rdieter> am I blind?
16:42:34 <rdieter> crontabs
16:42:35 <geppetto> rdieter: add the 's' :)
16:42:36 * abadger1999 also pluralizes crontab(s)
16:42:47 <rdieter> Size        : 3013  , heh
16:42:59 * spot whipped up a draft that drops the subpackage : https://fedoraproject.org/wiki/User:Spot/Packaging/CronFiles
16:43:31 <tibbs> geppetto: I don't see the advantage of shipping two types of service management scripts, either; we just haven't switched over entirely to the new hotness.
16:43:42 <tibbs> This is just another case of that, with the same attached politics.
16:43:43 <rdieter> spot: i link that, +1
16:44:00 <tibbs> So maybe the avoidance of politics is the advantage.
16:44:07 <rdieter> (though Requires: crontabs isn't enough to ensure they actually run... I think)
16:44:16 <spot> this doesn't say you _can't_ put it in a subpackage, just doesn't require it.
16:44:24 <geppetto> tibbs: I thought we'd got rid of sysvinit scripts now … but at least those were managed in the same way (and used by the same daemon).
16:44:26 <geppetto> meh.
16:44:41 <tibbs> spot: Makes sense; needs minor grammar cleanups.
16:45:16 <spot> okay, hit me with the grammar errors, or just fix them in my draft?
16:45:19 <rdieter> ah, crontabs pulls in /etc/cron.d/ owner (which happens to be cronie)
16:45:20 <tibbs> geppetto: meh indeed.  It's a morass but one we need to deal with at some point.
16:45:30 * abadger1999 adds justification for crontabs to spot's version
16:45:48 <geppetto> Is it worth having an example of a sub-package?
16:46:35 <tibbs> spot: Comma fault in first sentence, "an script" in second sentence, kind of stopped scanning there.  No problem for me to fix up but we can't all edit the thing at once.
16:46:35 * spot isn't sold on a subpackage being a good idea. I think anyone smart enough to have a case where it is will know how to do it.
16:46:50 <tibbs> spot: I definitely agree with that.
16:47:05 * abadger1999 done editing
16:47:29 <spot> tibbs: you're up!
16:47:29 <geppetto> Fair enough … +1 to spot's draft.
16:47:54 * spot is +1 as well, assuming tibbs is happy with the grammar. me speak good english sometimes.
16:48:01 <geppetto> :)
16:48:33 <abadger1999> Still wondering what the justification is for "does not ship systemd unit file"
16:48:59 <tibbs> abadger1999: I kind of agree.
16:49:15 <tibbs> I guess the point is that if you do ship a unit file, you just drop your scheduled task stuff in there.
16:49:28 <limburgher> +1
16:49:31 <tibbs> But, really, I don't think at this point we should be mandating anything like that.
16:49:38 <spot> It could be confusing to have two independent timing mechanisms going at once.
16:50:07 <tibbs> Maybe "does not ship a systemd unit file that runs periodic tasks" or whatever the proper terminology is.
16:50:13 <spot> We could really drop that sentence. It doesn't affect the guideline except to politicize things.
16:50:14 <abadger1999> tibbs: +1
16:50:39 <tibbs> Becuse admins really don't deserve to have to find two different scheduling mechanisms for the same package.
16:50:40 <abadger1999> <nod>  I could go for either dropping or specifying that we're only talkingabout systemd periodic tasks
16:50:51 <limburgher> Right.
16:51:20 <abadger1999> right now it reads like: legacy sysv-init + cron XOR systemd unit files + systemd timer
16:52:06 <tibbs> But spot's right; that sentence could just go.
16:52:15 <spot> "For the purposes of these guidelines, a cron job file is defined as an script (e.g., shell scripts or Perl scripts). These cron job files are scheduled to run on regular intervals by a cron daemon."
16:52:24 <spot> and just drop the extra sentence
16:52:50 <tibbs> If anyone's really nuts enough to use two different timer mechanisms at once in the same package, someone can just file bugs.
16:52:55 <abadger1999> +1 to spot's draft
16:53:15 <tibbs> Note hard stop for me in right minutes, but I can be back at fifteen after.  Performance evaulation time.
16:53:17 * spot makes that change to his draft
16:55:09 <spot> hmm
16:55:11 <spot> i just had a thought
16:55:16 <spot> (i know, it is rare)
16:55:29 <spot> it talks about making changes to /etc/crontab
16:56:02 <spot> i think we want new entries in /etc/cron.d instead
16:56:02 <limburgher> Maybe change that to /etc/cron.d/foo?
16:56:07 <limburgher> Jinx
16:56:17 <abadger1999> Yes.
16:57:10 <spot> that whole sentence in the draft is wrong.
16:57:20 <spot> /etc/cron.d/ just stores crontab entries, not scripts
16:57:38 <abadger1999> yeah -- I think there was a misunderstanding of how that directory works.
16:59:02 <spot> So... do we want to standardize where these scripts go?
16:59:45 <geppetto> Is that useful?
16:59:53 <abadger1999> I've dropped them into %{_sbindir} in the past.
16:59:56 <limburgher> Sort of.  I prefer cron.d, but there's no reason not to use daily, hourly, etc.
17:00:13 <limburgher> Oh, sorry, scripts, not entries.  Then no.
17:00:14 <abadger1999> I oculd see the %{_libexecdir} family of directories being okay as well.
17:01:03 <abadger1999> yeah, I don't think there's a need to standardize where the scripts go.
17:01:34 <spot> okay, i reworded the draft
17:01:44 <abadger1999> this is common sense/look at the other guidelines about helper scripts.... we can standardize if people start fighting about it on the mailing lists.
17:01:52 <limburgher> Can we change cron.daily in the example at the end to cron.d, so people don't dump everything in daily?
17:02:44 <abadger1999> spot: crob job file example for cron.d needs changing too.
17:02:45 * spot fixes the example
17:03:59 <spot> and i changed the spec example to monthly
17:04:42 <abadger1999> spot: there's one more s/daily/monthly/ in the example at the end  (the mkdir)
17:04:56 <spot> fixed
17:05:21 <abadger1999> +1
17:05:21 <limburgher> Why monthly?
17:05:35 <spot> because it is the least bad choice if someone blindly copies?
17:05:41 <spot> cron.d is not right
17:05:47 <limburgher> Why not?
17:05:51 <spot> cron.d is for crontab files
17:05:54 <spot> not cron scripts
17:05:57 <geppetto> +1
17:06:14 <spot> crontab file: 0 */2 * * * root /usr/sbin/example
17:06:29 <limburgher> Oh, right, I got scripts and crontabs mixed up again.  Sorry, doing too many things at once.
17:06:49 <spot> okay, i think the draft is finished as is.
17:07:03 <spot> shall we try to do another round of votes? my stomach is GROWLING.
17:07:08 <rdieter> +1 spot's draft
17:07:10 <Rathann> hi, sorry for being late
17:07:11 <geppetto> +1
17:07:19 <limburgher> +1 as well.
17:07:24 <spot> +1
17:07:42 <abadger1999> +1
17:07:48 <Rathann> could you paste the link to the draft?
17:07:52 <spot> https://fedoraproject.org/wiki/User:Spot/Packaging/CronFiles
17:08:43 * spot just realized he started the meeting at 1600, not 1700. :/
17:08:56 <spot> daylight savings time, i curse at thee!
17:09:08 <abadger1999> heh.  Go for another hour? ;-)
17:09:24 <spot> i think we'll just call it a day and start at the right time next week.
17:09:36 <spot> Rathann: apologies for the confusion.
17:09:53 <abadger1999> We're at +5 for cron guidelines atm which will pass.
17:09:54 <geppetto> So we are on 1pm-2pm EST now?
17:09:55 <Rathann> heh, no problem
17:09:58 <spot> geppetto: yes
17:10:12 <geppetto> bah.
17:10:16 <geppetto> +1 for hate on DST.
17:10:29 <spot> #action Spot's revised draft passes (+1:5, 0:0, -1:0)
17:11:10 <abadger1999> before we leave, I'm hoping for one more vote for filtering guidelines update: https://fedorahosted.org/fpc/ticket/189
17:12:23 <spot> abadger1999: +1
17:12:30 <abadger1999> Thanks :-)
17:12:37 <spot> sorry for not doing that sooner.
17:12:51 * spot puts it in the ticket for good measure.
17:13:16 <spot> okay, thanks everyone. Remember, we're meeting at 1700 UTC next week (our proper time), which is 1 PM Boston time. :)
17:13:23 <spot> #endmeeting