16:02:44 <spot> #startmeeting Fedora Packaging Committee
16:02:44 <zodbot> Meeting started Wed Dec  1 16:02:44 2010 UTC.  The chair is spot. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:02:44 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:02:49 <spot> #meetingname fpc
16:02:49 <zodbot> The meeting name has been set to 'fpc'
16:03:28 <spot> #topic Roll Call
16:03:50 * spot is here (as much as I ever am, anyways)
16:04:05 <tibbs|h> Almost slept through it.  (Not feeling well today.)
16:04:11 <rdieter> here
16:04:12 * Rathann|work present
16:04:23 <Rathann|work> (but distracted)
16:05:07 <spot> geppetto, racor, SmootherFrOgZ?
16:06:09 <racor> here (somewhat distracted and likely having to leave early)
16:06:36 <abadger1999> Hi guys
16:06:50 <geppetto> yeh
16:07:04 <spot> okay, thats quorum (even if half of us are sick or distracted). :)
16:07:28 <spot> #topic Systemd https://fedorahosted.org/fpc/ticket/31
16:07:52 <spot> I updated the ticket and sent out an email to the packaging list with the new draft this morning
16:08:07 <spot> i think it would make sense to let it have a week to gather comments and review
16:08:34 <spot> Please try to find some time to look it over before next week: https://fedoraproject.org/wiki/TomCallaway/Systemd_Revised_Draft
16:08:51 <tibbs|h> Unfortunately I can't even get it to load.
16:09:08 <spot> tibbs|h: weird.
16:09:12 * abadger1999 still thinks we should have either unitfiles or sysvinit scripts but not both.
16:09:36 <tibbs|h> I thought the point was that it would use initscripts if it had them.
16:09:54 <tibbs|h> So you could override the unit behavior by dropping in a script.
16:10:02 <tibbs|h> Packaging both would seem to defeat that.
16:10:06 <spot> tibbs|h: i don't think it works like that
16:10:13 <abadger1999> tibbs|h: I think unitfiles are used if it has them, then it fallsback to the init script.
16:10:20 <abadger1999> if no unitfile is present.
16:10:23 <tibbs|h> Which if of course backwards.
16:10:32 <spot> tibbs|h: if you say "systemctl foo" and it can't find foo.service, it looks for /etc/rc.d/init/foo
16:11:08 <tibbs|h> Oh, well, another bump in the train wreck.
16:11:27 <abadger1999> But my problem with both is that sysadmin types in /etc/init.d/foo restart and that will do something even though a unitfile is present.
16:11:53 <Rathann|work> abadger1999 has a point
16:11:57 <geppetto> Yeh, I don't see the point of packaging both
16:12:07 <abadger1999> and a sysadmin edits /etc/init.d/foo and expects the changes to take effect but they don't since there's a unitfile.
16:12:09 <abadger1999> etc.
16:12:10 <tibbs|h> This revised draft is far, far better from an organizational point, at least.
16:12:14 <abadger1999> <nod>
16:12:19 <spot> the counter point there is that there will be some people who expect to be able to use upstart
16:12:48 <spot> and since it doesn't support the Unit .service files, it will simply not work.
16:12:50 <tibbs|h> I thought systemd was optional in F14, mandatory in F15.
16:12:54 <abadger1999> which won't work unless we mandate that you do provide a sysv init script.
16:13:07 <tibbs|h> This half-switching crap just isn't going to work out well.
16:13:09 <spot> tibbs|h: that wasn't my interpretation, just that it was "default".
16:13:24 <spot> nirik: around?
16:13:43 <geppetto> spot: When we switch to upstart, we didn't support moving back to sysvinit … did we?
16:14:04 <spot> geppetto: different situation, because we never switched to the upstart only format
16:14:14 <spot> geppetto: but it did work
16:14:59 * spot is not opposed to dropping the sysvinit files entirely, but I suspect there might be some pushback.
16:15:29 <spot> i think it might be best to have this discussion on the mailing list
16:15:40 <rdieter> agreed
16:15:50 <Rathann|work> seconded
16:15:59 <geppetto> Maybe … I mean systemd should support them … I just don't see the point in distributing both in our packages, it just can't end well
16:16:16 <geppetto> f-d-l super joyness?
16:16:19 <tibbs|h> One problem with _some_ packages providing initscripts is that people who want upstart still won't be happy unless all of the packages provide them.
16:16:24 <tibbs|h> And we're not making them mandatory.
16:16:46 <spot> tibbs|h: sure, but if we take them out, we'd also need to retire upstart entirely.
16:17:24 <tibbs|h> My point is that if you take just one out of one boot-necessary package, then upstart is screwed anyway.
16:17:34 <spot> tibbs|h: fair point.
16:17:39 <tibbs|h> But I'm happy to discuss this on list instead of here.
16:17:47 <abadger1999> Sounds good to me.
16:17:51 <spot> tibbs|h: okay, toss it on the list, and we'll discuss it
16:18:24 <spot> #topic hMandate NEVR(F N) >= NEVR(F N-1) - https://fedorahosted.org/fpc/ticket/40
16:18:30 <spot> #topic Mandate NEVR(F N) >= NEVR(F N-1) - https://fedorahosted.org/fpc/ticket/40
16:18:34 <tibbs|h> I thought this was already mandatory.
16:18:45 <abadger1999> There are some policies that at least imply this already
16:18:50 <abadger1999> both in fpc and fesco
16:18:52 <Rathann|work> me too
16:18:56 <spot> it would not hurt to be painfully clear here.
16:18:58 <Rathann|work> seems like a no-brainer to me
16:19:07 <spot> since we do have this problem creeping up often
16:19:13 <rdieter> nobrainer +1
16:19:16 <spot> +1
16:19:20 <Rathann|work> +1
16:19:21 <abadger1999> I think disttag has what I remember
16:19:56 <tibbs|h> It does mention it.
16:20:03 <geppetto> +1
16:20:06 <tibbs|h> As well as http://fedoraproject.org/wiki/Packaging:NamingGuidelines#Minor_release_bumps_for_old_branches
16:20:23 <tibbs|h> But I guess we can always state it a third time.
16:20:37 <abadger1999> +1
16:20:39 <tibbs|h> So +1, but where to put it?
16:21:08 <geppetto> also … wth happened with fife so it got an older version in updates?
16:21:32 <spot> https://fedoraproject.org/wiki/Packaging:NamingGuidelines#Package_Version seems the most logical place
16:22:20 <spot> #action Draft is approved (+1:6, 0:0, -1:0)
16:23:07 <abadger1999> Maybe a new section that encompasses package version, and package release
16:23:14 <spot> abadger1999: sure.
16:23:25 <abadger1999> I'll take the write up on that.
16:23:31 <spot> abadger1999: awesome. thanks.
16:23:43 <spot> #topic Version free changelogs - https://fedorahosted.org/fpc/ticket/38
16:25:10 <spot> my initial thought here was that we could require that all builds that go to koji must have a top level changelog entry with a version
16:25:24 <abadger1999> So I don't feel strongly but I'd rather see geppetto's suggestion or mine.
16:25:34 <spot> but i can see how that might be generally ignored and functionally impossible to police
16:25:55 <tibbs|h> Sorry, guys, my network connection dropped.
16:26:04 <rdieter> abadger1999: +1
16:26:20 <tibbs|h> I missed at least three minutes of discussion.
16:26:45 <rdieter> [10:24] <spot> #topic Version free changelogs - https://fedorahosted.org/fpc/ticket/38
16:26:46 <spot> tibbs|h: abadger1999 is going to make a new section encompasses package version, and package release and put the new sentence there
16:26:59 <tibbs|h> Sounds good.
16:27:01 <tibbs|h> +1
16:27:32 <geppetto> +1
16:27:35 <spot> Of the two options, I would prefer to document geppetto's solution
16:27:39 <abadger1999> <nod>
16:27:59 <abadger1999> That would be fine with me
16:28:04 <tibbs|h> BTW, is there need for any special consideration of rawhide?
16:28:30 <tibbs|h> Because we don't want broken rawhide preventing updates on release branches.
16:29:43 <spot> tibbs|h: perhaps a line noting that rawhide packages must at least be greater or equal than the corresponding package's EVR of the preceeding Fedora release in the spec file.
16:30:10 <tibbs|h> Not a bad idea, I guess.
16:30:25 <Rathann|work> so what are we voting for, exactly? because Toshio suggested that we keep the version for every change
16:30:27 <nirik> spot: I'm around now.
16:30:28 <spot> abadger1999: did you parse that logic? it came out a little uglier than i wanted.
16:30:31 <geppetto> spot: I think tibbs means when someone wants to do a simple update, but rawhide won't build their package … are they then allowed to have a newer version in release than rawhide?
16:30:54 <spot> geppetto: and my reply was "yes, as long as the spec in git is still >="
16:31:02 <tibbs|h> Sorry, I guess we're on to changelogs now; sorry.
16:31:06 <spot> s/git/rawhide git/
16:31:07 <abadger1999> spot: Yeah I did... figuring out how to phrase it.
16:31:07 * geppetto nods … ok
16:31:51 <tibbs|h> I just don't want someone saying "that security update couldn't go out because it won't build in rawhide and the guidelines said I couldn't update anything".
16:32:03 <tibbs|h> Because, you know....
16:32:11 <spot> nirik: wanted clarification on whether systemd would be mandatory in f15 or not (will upstart still be a supported option)
16:32:25 <spot> tibbs|h: sure.
16:32:28 <spot> tibbs|h: its a good point
16:32:37 <Rathann|work> spot: actually, I think we should be more lenient than that: you should be allowed to bump release branches higher than rawhide if necessary, temporarily of course
16:32:49 <nirik> spot: good question. Not sure. I can bring it up in the fesco meeting today.
16:33:14 <spot> nirik: the answer will affect whether we document packaging sysvinit scripts or not. :)
16:33:14 <mjg59> I'm pretty convinced it's insane to require support for multiple init tools
16:33:21 <Rathann|work> exactly for the reason tibbs mentioned
16:33:31 <tibbs|h> mjg59: Me as well, but....
16:33:48 <spot> Rathann|work: i'd still prefer that the spec in rawhide always be >=
16:34:01 <abadger1999> We already allow support for multiple init tools; but we don't require it.
16:34:06 <spot> even if they don't/can't build.
16:34:07 <nirik> spot: fair enough.
16:34:11 <nirik> mjg59: yep.
16:34:27 <Rathann|work> hm, ok, I guess a no-op bump can always be done
16:34:40 <abadger1999> And then, near release time, things get hairy with NEVR and not building again.
16:35:05 <spot> the autoqa folks have a pretty good test in the works to check against this
16:35:12 <abadger1999> But FESCo/FES has been doing a good job on that.
16:35:45 <spot> and i think they plan on running it prior to each target milestone (alpha/beta/rc/final) for f15 (and as part of the updates process in the future)
16:36:22 <spot> so, lets go back to ticket 38. :)
16:37:03 <abadger1999> +1 to geppetto's suggestion
16:37:11 <spot> I propose that we document that it is acceptable for multiple changelog entries to have the same V-R, even when the names and dates are different
16:37:27 <spot> (which is basically geppetto's suggestion summarized)
16:37:34 <geppetto> +1
16:38:10 <racor> spot: are the fedora tools able to handle this (rpmlint, rpmbuild, fedpkg clog)?
16:38:11 <geppetto> I'm happy to also +1 abadger1999 (which is that you shouldn't do serial entries which just change the date)
16:38:24 <spot> racor: yeah, they don't care about the V-R at all
16:38:37 <spot> except for maybe fedpkg clog, i would need to check it
16:38:45 <tibbs|h> I guess I can understand why you'd want multiple entries with different dates.
16:39:10 <tibbs|h> Although, honestly, shouldn't someone be considering how to link this all in with git these days?
16:39:32 <racor> spot: I think rpmbuild also occasionally complains (but I don't recall the precise circumstances, IIRC it's the date)
16:39:56 <spot> racor: it will complain about invalid dates
16:40:03 <spot> and out-of-order dates
16:40:19 <spot> fedpkg clog doesn't care either, it isn't terribly bright.
16:40:21 <racor> how about identical dates
16:40:41 * spot has done identical dates before
16:40:43 <spot> it doesn't mind that
16:40:53 <racor> OK
16:41:23 <spot> i would not be proposed to documenting both cases, as they are both permissable
16:41:29 <abadger1999> tibbs|h: Maybe -- although there's different audiences there.  git commit is aimed at the packagers.  %changelog is aimed at technical users bodhi... "end users" where people seem to be leaning more towards less technical end users sorta.
16:41:32 <spot> errr, opposed rather than proposed.
16:41:36 <spot> me speak good english.
16:41:46 <geppetto> :)
16:41:51 <abadger1999> <nod>
16:41:57 <abadger1999> I'd be okay with that as well.
16:41:58 <spot> in fact, that sounds good to me.
16:42:28 <spot> Lets vote on documenting both scenarios (multiple entries with the same V-R, appending additional items to existing V-R entry)
16:42:30 <racor> Another related question: What is the relation between "release" and VCS?
16:42:48 <racor> are they supposed to match, is VCS supposed to be buildable (at any time)?
16:43:01 <spot> racor: git doesn't care about it at all.
16:43:20 <spot> cvs cared from a tagging perspective
16:43:53 <racor> I am not talking about git vs. cvs, I am talking about "package state in VCS"
16:44:09 <spot> racor: koji cares, but only in the sense that it won't build something that it already has a successful N-V-R build for
16:44:34 <spot> racor: okay, then I'm not sure what you are asking here.
16:44:59 <racor> spot: Let me try to rephrase it:
16:45:35 <abadger1999> racor: I would say no.  vcs may be broken at any time.
16:45:51 <racor> if somebody checks out a package from git, it is this package's sources supposed to match what is in the corresponding *.src.rpm?
16:46:07 <spot> racor: unless they use the matching tag, the answer is no
16:46:16 <racor> another related case: Rebuilding Fedora from source.
16:46:26 <racor> ... FTBS
16:46:26 <Rathann|work> there are no tags, though
16:46:31 <Rathann|work> are there?
16:46:51 <tibbs|h> Only ones that you make yourself.
16:46:56 <Rathann|work> exactly
16:46:59 <abadger1999> racor: To me, that should use the srpm rather than VCS.
16:47:04 <racor> Rathann|work: yep, one reason for why I am not excited about fedpkg.
16:47:09 <tibbs|h> One day koji is supposed to tag after a successful build, but that's not implemented.
16:47:16 <Rathann|work> fedpkg should do git tag too
16:47:33 <spot> i think koji is doing something there
16:47:52 <spot> this is really a Jesse question though
16:48:00 <dgilmore> the plan is to have something external to koji do it
16:48:10 <dgilmore> once a build completes sucesfully
16:48:15 <Rathann|work> we're going off-topic now, aren't we?
16:48:31 <spot> i would agree
16:48:39 <spot> Lets vote on documenting both scenarios (multiple entries with the same V-R, appending additional items to existing V-R entry)
16:48:42 <spot> +1
16:48:45 <tibbs|h> +1
16:48:46 <Rathann|work> +1
16:48:53 <racor> -1
16:49:10 <rdieter> +1
16:49:11 <spot> racor: are you opposed to one of them, or both of them?
16:49:14 <geppetto> +1
16:49:25 <racor> both
16:49:36 <abadger1999> +1
16:49:39 <spot> racor: okay. duly noted.
16:50:05 <racor> you are adding reasons for confusion and inconstencies. this is not helpful
16:50:43 <spot> #action Documenting both scenarios (multiple entries with the same V-R, appending additional items to existing V-R entry) approved (as opposed to permitting version-less changelog entries, which was not) - (+1:6, 0:0, -1:1)
16:51:38 <spot> #topic Bundling Exception - shedskin - https://fedorahosted.org/fpc/ticket/39
16:51:52 * hicham wish we can add a number for automatic rebuilds like suse does
16:52:00 <tibbs|h> I came across this while doing a package review.
16:52:18 <tibbs|h> Basically, upstream is 50 lines of code you're supposed to paste in.
16:52:54 <tibbs|h> But it's structured like a real upstream; I figured it was worth considering properly.
16:53:51 <tibbs|h> Anyway, I'm +1 to listing this under the existing copylibs section.
16:55:01 <spot> the only concern I have here is that this is versioned
16:55:12 <spot> and it is theoretically possible that this code would have security issues
16:55:29 <spot> but given that it really isn't useful as a standalone library...
16:55:55 <Rathann|work> I think it should at least be mentioned in the spec which version was used
16:56:04 <Rathann|work> and it could be provided as a standalone library
16:56:27 <spot> Rathann|work: yeah, it could.
16:56:45 <Rathann|work> given that there actually are a couple of versions of this function provided on the upstream website
16:57:51 <spot> if it were my package, i would probably make murmurhash into a versioned shared lib
16:58:13 <spot> but i could see the other side here too.
16:58:16 <Rathann|work> +1 from me to the exception, with the stipulation that it's documented and machine-searchable
16:58:21 <Rathann|work> and I have to go now
16:58:31 <Rathann|work> I'll try to rejoin when I get home
16:58:37 <spot> Rathann|work: thanks
16:58:41 <Rathann|work> sorry
16:58:44 <tibbs|h> spot: Also, the license is a bit weird, but that's a separate question.
16:59:07 <Rathann|work> (later)
16:59:33 <spot> tibbs|h: weird how?
17:00:02 <abadger1999> heh, the code is even optional.
17:00:12 <tibbs|h> "All code is released to the public domain. For business purposes, Murmurhash is under the MIT license. "
17:00:12 <abadger1999> #ifdef __SS_FASTHASH
17:00:34 <spot> oh yeah, that. i chalk that up to "english not my first language"
17:00:54 <spot> we'll interpret it as "public domain, but if you need a license, MIT"
17:01:01 <spot> and use it under MIT.
17:01:09 <tibbs|h> OK, that's easy enough.
17:01:33 <spot> +1 to the exception here
17:01:48 <spot> with the caveat that if someone makes a murmurhash package, it should use it.
17:02:13 <racor> spot: +1, sound good
17:03:06 <spot> vote on granting exception (with caveats) is at +4
17:03:21 <tibbs|h> Does that include me?
17:03:25 <spot> tibbs|h: yes
17:03:47 <spot> tibbs|h: unless i misread your comment. :)
17:03:56 <abadger1999> Okay, looking at this a while, I think this can get a copylib exception.
17:04:21 <abadger1999> +1 to spot's caveat as well.
17:04:38 <tibbs|h> For all we know, there's other code in the distro that uses this thing.
17:04:49 <rdieter> +1
17:04:51 <tibbs|h> You have to be pretty thorough to find it, though.
17:05:10 <abadger1999> well.. the svn repo is very new
17:05:12 <spot> tibbs|h: if there is a security vuln in it, i'm pretty sure we'll find it. ;)
17:05:24 <abadger1999> http://code.google.com/p/smhasher/source/browse/#svn/trunk
17:05:27 <abadger1999> Nov
17:05:42 <spot> okay, that's +6
17:06:34 <dgilmore> win 4
17:06:48 <spot> #action Exception granted. Package must document the murmurhash bunding, have appropriate bundled Provide, and if murmurhash ever is packaged as a standalone library in Fedora, this package must then use it. (+1:6, 0:0, -1:0)
17:07:17 <racor> spot: I am sure we would have found the flaw they are referring to ... "MurmurHash3 ...  - it fixes a flaw that was found in MurmurHash2 ..." :)
17:08:22 <spot> #topic Explain why rpmlint warns about executable files in %doc - https://fedorahosted.org/fpc/ticket/36
17:09:13 <tibbs|h> I'd support a guideline that says "no executable documentation".
17:09:26 <spot> There isn't actually a proposed change that I can see in there, but I would agree with tibbs.
17:10:03 <tibbs|h> Well, he wanted us to answer a question: is executable documentation allowed?
17:10:40 <abadger1999> http://code.google.com/p/smhasher/wiki/MurmurHash2Flaw
17:10:49 <rdieter> personally, I'd allow it, as long as the packager understands the consequences of doing so (ie, added deps and such)
17:10:52 <tibbs|h> The more general question is what to do about things that rpmlint complains about but that isn't against the guidelines.
17:10:57 <spot> Although, I might make it a bit more specific to prevent confusion, something like: "Files with execute permissions may not be packaged as %doc files. Sample scripts can either be packaged as %doc (with chmod -x) or included in %{_bindir}/%{_sbindir}."
17:11:29 <abadger1999> The more general question: fix them unless fixing violates common sense.
17:12:26 <spot> Or maybe even just "Files with execute permissions may not be packaged as %doc files."
17:12:53 <racor> I'd also allow them, it the packager explicitly takes them into consideration
17:13:07 <spot> racor: what do you mean by that?
17:13:10 <geppetto> spot: So scripts must either be executable and in $PATH, or not executable?
17:13:23 <spot> geppetto: yeah, thats the logic i'm trying to spit out. :)
17:13:33 <tibbs|h> Well, module libexec.
17:13:57 <spot> But it boils down to "there is no good general case for executable docs"
17:14:17 <abadger1999> "sample scripts" probably don't belong in libexec either
17:14:42 <racor> spot: Example: adding executable example scripts, when they do not pull in additional deps.
17:15:11 <racor> this can be achieved by filtering, if the maintainer actively takes this into account.
17:15:30 <spot> racor: as long as they're marked chmod -x, i don't have an issue with it.
17:15:50 <rdieter> what's the aversion to +x exactly?
17:16:01 <racor> spot: yes, this is a radical, overly simplistic solution.
17:16:22 <spot> rdieter: files marked as +x get run through the auto-dependency scripts
17:16:22 <abadger1999> spot: racor is saying, if the maintainer has vetted the scripts and knows that they don't pull in additional deps it's technically fine so packaging guidelines could/should allow it.
17:16:45 <spot> abadger1999: yes, but it is very very easy to have one release be okay and the next not.
17:16:52 <rdieter> (yes, it can and does complicate things, but putting a blanket rule against it seems a bit overboard)
17:16:55 <racor> abadger1999: thanks, this is what I wanted to express.
17:16:59 <spot> i would prefer to simply require that all %doc files be -x
17:17:28 <spot> as that is much simpler than saying "if you go to the trouble of implementing complicated filtering, you can avoid running the chmod -x"
17:17:43 <racor> spot: yes, it's easy to make mistakes and to inadvertedly introduce bugs.
17:18:07 <spot> racor: whereas, by simply requiring that all %doc files be -x, we avoid the problem entirely.
17:18:12 <racor> spot: are we talkling about %doc or files below %docdir
17:18:29 <spot> racor: i think all files below %docdir are implicitly %doc
17:18:36 <spot> so, yes, and yes. :)
17:18:54 <racor> sport: excutable %doc files outside of %docdir may well make sense.
17:19:04 <spot> racor: as %doc?
17:19:24 <spot> either they're executable and useful, in which case, i would say they're no longer %doc
17:19:40 <spot> or, they're reference works and can be packaged as %doc -x
17:19:56 <racor> spot: %doc primarily means file is subject to rpm  --exclude-dir
17:19:56 <spot> if the user wants to +x them later, well, that's beyond our scope.
17:20:34 <spot> racor: sure, i understand that.
17:20:54 <spot> racor: the question is whether executable scripts count as %doc when they're +x
17:21:09 <spot> (and yes, i recognize that this is a major point of argument)
17:21:18 <racor> spot: ie. if a package ships scripts/tools to display some specialized documentation system, %doc'ing scripts and doc data is one applicable approach.
17:22:09 <racor> spot: the alternative is *-doc subpackages.
17:22:23 <spot> https://fedoraproject.org/wiki/Packaging/Guidelines#PackageDocumentation
17:22:30 <spot> "Also, if a package includes something as %doc, it must not affect the runtime of the application. To summarize: If it is in %doc, the program must run properly if it is not present. "
17:22:50 <spot> so, to your case, if the package depends on the scripts, they can't be %doc.
17:23:36 <rdieter> OK, silly question, if stuff marked %doc (which impliicitly happens to stuff under %_docdir) *does* affect runtime, the only option is to move it elsewhere?
17:24:00 <spot> rdieter: yeah
17:24:12 <racor> spot: OK less abstract: A package ships some ref-manuals in some package specific/proprietary formating. How to and where to package  "xxx-man.sh"?
17:24:12 <rdieter> ugh, icky poo
17:24:30 <spot> rdieter: otherwise, you get big boom when installing with --exclude-docs
17:25:00 <rdieter> spot: and if the software/pkg in question gracefully degrades without it (ie, no boom)?
17:25:04 <spot> racor: thats a heck of a corner case, but i would say that is an exception, rather than the rule.
17:25:15 <rdieter> I guess then it's not affecting runtime. nvm
17:25:18 <spot> rdieter: then it doesn't affect the runtime of the application. :)
17:25:20 <abadger1999> racor: Why not /usr/bin/xxx-man.sh ?
17:25:33 <rdieter> brane hurts, make it stop
17:25:37 * spot has never seen executable docs in a FOSS package
17:25:50 <spot> (i wish i could s/FOSS// there, but i can't. stupid adobe.)
17:25:51 <racor> rdieter,spot: http://lists.fedoraproject.org/pipermail/packaging/2010-November/007508.html
17:26:15 <racor> abadger1999: %doc /usr/bin/xxx-man.sh?
17:26:38 <spot> racor: ick!
17:26:59 <abadger1999> racor: not %doc
17:27:05 <rdieter> racor: needs fixing I'd say (the helper script(s) should arguably be in libexec too)
17:27:19 <spot> rdieter: +1
17:27:28 <abadger1999> racor: note, that thread ends with the files going in %{_datadir} which I thought was appropriate: http://lists.fedoraproject.org/pipermail/packaging/2010-November/007512.html
17:28:14 <rdieter> ok, I'm +1, haven't seen any compelling (enough) counter-examples (can re-evaluated if it does happen)
17:28:20 <racor> abadger1999: xxx-man.sh is useless without %doc /usr/share/xxx/foo/<weird docs>. I don't see much reason  not to %doc it.
17:28:50 <abadger1999> racor: man is useless without man pages as well.
17:28:59 <tibbs|h> I'm sure you can construct some bizarre corner case for pretty much every guideline we pass.  Which is why there's a generic "ask for an exception" procedure.
17:29:12 <spot> okay, can we consider "%doc files must be have executable permissions" ?
17:29:16 <spot> ugh.
17:29:16 <abadger1999> All man pages are marked %doc implicitly but /usr/bin/man is not.
17:29:20 <spot> i am failing at english today
17:29:20 <geppetto> spot: -1 :)
17:29:29 <spot> okay, can we consider "%doc files must not have executable permissions" ?
17:29:33 <geppetto> But +1 to what spot wanted to say
17:29:36 <tibbs|h> +1
17:29:44 <geppetto> +1
17:29:51 <rdieter> +1
17:29:55 <spot> +1
17:29:56 <abadger1999> geppetto: That'll be one pony plus shipping and feed for a year :-)
17:30:06 <abadger1999> +1
17:30:13 <racor> -1
17:30:40 <spot> #action "%doc files must not have executable permissions" passes (+1:5, 0:0, -1:1)
17:31:16 <spot> #topic Open Floor
17:33:07 <spot> if there are no additional items i will close this out at 1735 UTC
17:33:08 <abadger1999> I got nothin'
17:33:28 <tibbs|h> And my connection dropped again.
17:33:33 <rdieter> nuttin honey
17:33:57 <abadger1999> anyone want to send anything we passed today to fesco?
17:35:03 <spot> okay, thanks everyone
17:35:05 <spot> #endmeeting