16:03:46 <abadger1999> #startmeeting fpc
16:03:46 <zodbot> Meeting started Wed Jul 25 16:03:46 2012 UTC.  The chair is abadger1999. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:03:46 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:04:02 <abadger1999> #chair geppetto limburgher
16:04:02 <zodbot> Current chairs: abadger1999 geppetto limburgher
16:04:24 <abadger1999> racor, rdieter, spot, tibbs, Smoother1rOgZ: FPC meeting time
16:04:37 <abadger1999> ya'll here?
16:05:02 * racor is here
16:05:34 * spot is here, sorry, launching a web app
16:05:58 <rdieter> yo
16:06:41 <abadger1999> Cool.  We have more than enough for quorum today
16:06:47 <abadger1999> #chair racor spot rdieter
16:06:47 <zodbot> Current chairs: abadger1999 geppetto limburgher racor rdieter spot
16:07:03 <spot> gimme a sec to whip up an agenda
16:08:42 <spot> okay.
16:09:02 <spot> #topic Revision to Haskell Guidelines - https://fedorahosted.org/fpc/ticket/194 - https://fedoraproject.org/wiki/PackagingDrafts/Haskell
16:11:21 * spot loves draft revisions without a diff
16:11:26 <limburgher> Can someone with more Haskell experience that I summarize the major changes?
16:11:30 <limburgher> spot: Jinx.
16:11:57 * abadger1999 doesn't like spec templates that aren't in the Packaging: namespace.
16:12:17 * abadger1999 likes the decrease in intro material
16:12:21 <spot> abadger1999: yeah, but the old ones weren't either
16:12:22 * abadger1999 continues reading
16:12:40 <rdieter> seeing rpm macros for pkg_name and stuff like  %ghc_devel_package, %ghc_devel_description %ghc_package, %ghc_description makes me cringe
16:14:04 <spot> rdieter: agreed
16:14:26 <abadger1999> rdieter: +1
16:15:48 <rdieter> imo, I know next to nothing about haskell particulars, but I'd propose postponing this one for now.  ask for:
16:16:08 <rdieter> 1.  a summary of changes/diffs from https://fedoraproject.org/wiki/Packaging/Haskell
16:16:18 <rdieter> 2. some justification for the additional rpm macros
16:16:47 <geppetto> I think this might be it: https://fedoraproject.org/w/index.php?title=PackagingDrafts%2FHaskell&action=historysubmit&diff=294977&oldid=233896
16:17:17 <spot> geppetto: no, because the intro section is also gone
16:18:11 <spot> current guidelines also say "Current releases of GHC do not yet support generating shared libraries"
16:19:12 <abadger1999> I guess %pkg_name is there so that things like ghc-pkg_name are easy.
16:19:21 <abadger1999> It's a common convention with python modules too.
16:19:41 <rdieter> abadger1999: is using ghc-pkg_name manually really that hard?
16:20:00 <abadger1999> Nope -- do they use pkg_name in other places though?
16:20:09 <abadger1999> Name: ghc-%{pkg_name}
16:20:29 <rdieter> I guess I could live with that one, but macro'izing _package, _description stuff feels like over-doing it
16:20:30 <abadger1999> Source: http://blah/%{pkg_name}/%{pkg_name}-%{version}.tar.gz
16:20:34 * limburgher Gazes into future, sees %{spec}
16:20:37 <spot> it does use them in their description macros
16:20:44 <abadger1999> %setup -n %{pkg_name}-%{version}
16:20:54 <spot> if the other helper macros common_summary and common_description aren't set
16:20:54 <abadger1999> rdieter: +1
16:20:57 <spot> i really do not like that.
16:21:05 <abadger1999> I don't like the macroizing of the others at all
16:21:37 <rdieter> I mean, pkg_name is just a convenience (but required for the other ones), so it's nice and all, but I'm not sure if it's worth (or a good idea) codifying in the guidelines
16:22:32 <rdieter> that's partly why I was curious for the justifcation behind adding these (if there's something more than I'm missing)
16:22:37 <spot> i think the %package, %description macros need to go
16:22:47 <abadger1999> <nod>
16:23:41 <limburgher> I think rdieter's 1. (w|c)ould help provide 2., and I think we all would like to see that.
16:23:55 <spot> okay, so lets toss it back with rdieter's questions
16:24:02 <racor> i don't like macroizing of rpm's "primary" %-tags (or whatever might be the correct nomenclature), I mean %files, %post*, %postun* etc.
16:24:31 <rdieter> racor: we seem to all agree on that part
16:24:52 <abadger1999> racor: yep I agree
16:25:38 <spot> #topic RPM macros guideline - https://fedorahosted.org/fpc/ticket/196
16:25:43 <geppetto> racor: yeh
16:26:47 <spot> The recommendation provided isn't correct, and the longer answer is a lot longer.
16:26:57 <spot> so the question is whether we want to document the longer answer
16:27:24 <rdieter> the recommendation is correct for the most common case(s), and uncommon cases are obviously exceptions to that
16:27:31 <spot> i can see how people may not understand where to package the macro files
16:28:21 <rdieter> folks packaging rpm macros, really need to educate themselves to get that understanding.  defining custom rpm macros shouldn't be taken lightly, imo.
16:28:56 <spot> Instead, how about "Additional RPM macros must be stored under /etc/rpm directory, and named using the syntax 'macro.$PACKAGE in files such as macros.perl, macros.ruby, etc are generally needed (only) at buildtime, so put them in your -devel pkg
16:29:04 <spot> sorry, accidental return there
16:29:06 <spot> i was not finished
16:29:10 <geppetto> Maybe just say "In short, don't do it" :)
16:29:23 <rdieter> now, to document that easy common case or not?  I kinda would rather our guidelines not try to serve as an educational tool, and provide every justification.  cause that's a deep rabbit hole
16:29:51 * Smoother1rOgZ here
16:30:32 <spot> Instead, how about "Additional RPM macros must be stored under /etc/rpm directory, and named using the syntax 'macros.$PACKAGE' (e.g. macros.perl). Normally, these files should be packaged in the -devel subpackage, since they are normally only needed for building other packages, however, this is not always ideal and packagers are encouraged to use their best judgement when determining the proper packaging home for these files."
16:31:13 <abadger1999> s/proper packaging home/proper subpackage/
16:31:25 <spot> abadger1999: might not be a subpackage
16:31:29 <abadger1999> True...
16:32:14 <abadger1999> but packaging home leaves me unclear about whether we're talking about the directories.  Or other packages altogether.
16:32:22 <rdieter> fine, +1.  I'd have hoped that in exceptional cases, packagers default to be encouraged to use their best judgement, but meh.
16:32:46 <abadger1999> "binary rpm"?
16:33:20 <spot> i could just say "proper package"
16:33:39 * abadger1999 fine with that
16:34:01 <Smoother1rOgZ> I'n fine with "proper packaging"
16:34:13 <abadger1999> Are we just talking about languages here?
16:35:22 <rdieter> abadger1999: anything that wants to provide supplemental macros.  languages are a prime example of that though
16:35:24 <abadger1999> I think that's the context this was brought up in but there's GConf macros, kde macros, cmake macros, font macros, etc.
16:35:34 <spot> "Additional RPM macros must be stored under /etc/rpm directory, and named using the syntax 'macros.$PACKAGE' (e.g. macros.perl). Normally, these files should be packaged in the -devel subpackage, since they are usually only needed for building other packages. However, in some situations, this is not always ideal and packagers are encouraged to use their best judgment when determining the proper package for these files."
16:35:46 <spot> reworded it a bit to have less repetition and run-on sentence
16:36:06 <abadger1999> I like the first sentence... I think I'm still with tibbs's view on the second part.
16:36:52 <abadger1999> Question -- how much does it hurt which package the macros end up in?
16:37:28 <rdieter> abadger1999: imo nothing, provided there are no conflicts of course
16:37:30 <abadger1999> It doesn't seem like it's that big a deal to me.
16:37:34 <abadger1999> yeah.
16:38:06 <rdieter> I suppose rpm invocations might slow down by a micro second or 2 parsing the additional macros
16:38:53 <spot> i just dont want some overzealous idiot to take just the first sentence and go out and file bugs
16:39:03 <spot> (first two sentences, rather)
16:39:08 <spot> and that has happened before
16:39:16 <spot> hence, the third sentence.
16:39:20 <abadger1999> Well... I guess I'm not seeing the reason for the second sentence on.
16:39:27 <rdieter> anyway, I'm +1 to spot's latest proposed wording.  I think having the guideline is better than not having one and relying on simple common sense
16:39:37 <abadger1999> Which I think is tibbs's reason for saying he'd vote against it i the ticket as well.
16:40:31 <abadger1999> If it does no harm and it's more corner cases than common cases, I don't know that the guidelines should specify it.
16:40:48 <spot> my proposal is for all three sentences, but if people want to propose just one of them, they can do so.
16:41:32 <spot> my thoughts are this: if someone was new to packaging, they wouldn't know necessarily where to put a macros.foo file.
16:41:46 <rdieter> abadger1999: the folks behind submitting the ticket wanted an answer to "how do I package rpm macros".  and you really want to give only a half an answer ?
16:41:46 <abadger1999> I'm totally fine with the first sentence but I know that that isn't what the person openning the ticket was looking for.
16:41:51 <spot> not just where on the filesystem
16:41:58 <geppetto> I'm +1 but I might do s/these files should be packaged/these files are packaged/
16:42:29 <geppetto> just so people don't read it as us saying "files SHOULD be packages in"
16:42:34 * spot is fine with geppetto's change
16:43:11 <abadger1999> I might not know whether a man page describing the API of a library goes in the main package or the -devel package... but that doesn't mean the Guidelines need to specify it.
16:43:29 <rdieter> great, now someone will ask for it. :)
16:43:38 <abadger1999> hehe :-)
16:43:53 * spot is pretty sure someone will ask for that now
16:44:13 <abadger1999> spot: Slippery slope!  j/k
16:44:14 <spot> I'm +1 to my proposal with geppeto's change.
16:44:23 <rdieter> +1 too
16:44:24 <abadger1999> +0
16:44:27 <Smoother1rOgZ> +1
16:44:49 <spot> so, we're at +4
16:45:15 * spot is assuming tibbs is -1 based on ticket data
16:45:24 <abadger1999> limburgher, racor: we're voting now.  So far, +4: 4, +0: 1, -1, 1
16:46:13 <limburgher> +1 with change.  SOrry, $_DAYJOB.
16:46:20 <Smoother1rOgZ> abadger1999: logically that should be -devel's. people should be smart enough to put doc files right packages according to their purpose.
16:46:29 <abadger1999> Smoother1rOgZ: Right.
16:46:41 <abadger1999> Smoother1rOgZ: Which is why I didn't vote +1 here as well.
16:46:47 <spot> #action Spot's draft with geppetto's change approved (+1:5, 0:1, -1:1)
16:47:09 <spot> #topic Add section to SysV initscripts about subsys locking - https://fedorahosted.org/fpc/ticket/198
16:47:20 * spot has to go afk for a few minutes, discuss and i'll be back. :)
16:47:27 <racor> +1, sorry was distracted
16:48:20 <rdieter> +1 to svsv subsys locking proposal
16:48:48 <abadger1999> +1
16:48:58 <Smoother1rOgZ> +1
16:49:24 <abadger1999> I suppose this whole page should go to the EPEL guidelines in the near future.
16:49:53 <limburgher> +1
16:49:56 <limburgher> Indeed.
16:50:20 <racor> +1
16:50:30 <geppetto> +1
16:52:38 <rdieter> that was easy
16:55:17 <abadger1999> #action SysV initscript locking approved (+1:5, 0:0, -1:0)
16:55:49 <abadger1999> #topic Ruby Guideliens inconsistency https://fedorahosted.org/fpc/ticket/197
16:56:13 <abadger1999> This is really just a clarification
16:56:20 <abadger1999> I have no feeling.
16:56:36 <abadger1999> Anyone have anything to say against keeping the ./ everywhere?
16:56:39 * rdieter has slight preference for ./%{... style here,
16:56:53 <spot> yeah, i prefer the /
16:56:56 <rdieter> even if you get a redundant /, it's easier to read, less error-prone
16:57:07 <abadger1999> <nod>
16:57:13 <abadger1999> Okay, I'll fix that today.
16:57:29 <abadger1999> #action toshio to make ./ consistent everywhere
16:57:30 <Smoother1rOgZ> rdieter: +1
16:58:14 <rdieter> of course, i'm hypocritical about not liking seeing stuff like %{buildroot}/%{_libdir} in .spec files either
16:58:24 <abadger1999> :-)
16:58:44 <abadger1999> spot: want to retake over now that you're back?
16:58:47 <spot> sure.
16:59:42 <spot> we're at an hour
16:59:48 <spot> we could go back over systemd tickets
16:59:55 <spot> but honestly, i'm happy to push that to next week
16:59:59 <abadger1999> There's also https://fedorahosted.org/fpc/ticket/185 which has been waiting a while
17:00:07 <abadger1999> (php-apache ticket)
17:00:11 <spot> ah, yes
17:00:13 <spot> lets do that one
17:00:27 <spot> #topic PHP library must not require apache - https://fedorahosted.org/fpc/ticket/185
17:01:20 <spot> new draft seems sensible to me
17:01:20 <limburgher> I like it, and I'd love to see EL-5's php53 fixed, as it's bitten me packaging at $_DAYJOB.
17:01:25 <rdieter> looks ok, +1
17:01:31 <spot> i might reword it a bit just for english grammar
17:01:34 <limburgher> +1
17:01:37 <spot> but +1 to the gist
17:01:38 <abadger1999> +1
17:01:56 <Smoother1rOgZ> +!
17:02:02 <Smoother1rOgZ> 1
17:02:39 <spot> #action draft approved (+1:5, 0:0, -1:0)
17:03:37 <racor> +1, .. you're too fast for me, I hardly can catch up reading ;)
17:03:56 <spot> racor: its that kind of day for me, too much to do and not enough time to do it in.
17:03:59 <spot> #topic Open Floor
17:05:06 * spot does a little dance
17:05:20 * limburgher makes a lit. . .or not.
17:05:32 <spot> hey, stop doing that to your laptop!
17:05:41 <spot> and with that, i think we're all done.
17:05:43 <spot> thanks everyone.
17:05:46 <spot> #endmeeting