16:00:44 <geppetto> #startmeeting fpc
16:00:44 <zodbot> Meeting started Thu Jun 18 16:00:44 2015 UTC.  The chair is geppetto. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:00:44 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:00:44 <geppetto> #meetingname fpc
16:00:44 <geppetto> #topic Roll Call
16:00:44 <zodbot> The meeting name has been set to 'fpc'
16:01:01 <gbcox> Good morning, I'm here to discuss Ticket #541 - Package Naming Guidelines Clarification
16:02:01 <tomspur> Hi all
16:02:16 <mbooth> Hi all
16:02:34 <geppetto> #chair tomspur
16:02:34 <zodbot> Current chairs: geppetto tomspur
16:02:36 <geppetto> #chair mbooth
16:02:36 <zodbot> Current chairs: geppetto mbooth tomspur
16:02:45 <tibbs|w> Howdy.
16:05:31 <geppetto> #chair tibbs
16:05:31 <zodbot> Current chairs: geppetto mbooth tibbs tomspur
16:05:44 * racor is here (currently distracted on the phone)
16:05:52 <geppetto> #chair racor
16:05:52 <zodbot> Current chairs: geppetto mbooth racor tibbs tomspur
16:08:30 * Corey84 hangs out in back row
16:10:14 <geppetto> racor: sorry for the ping
16:10:38 <geppetto> Looks like nobody else is here, and we have 5 so …
16:10:43 <geppetto> #topic Schedule
16:10:49 <geppetto> https://lists.fedoraproject.org/pipermail/packaging/2015-June/010705.html
16:11:16 <geppetto> #topic #541 	Package Naming Guidelines - Clarification Required
16:11:16 <geppetto> .fpc 541
16:11:17 <geppetto> https://fedorahosted.org/fpc/ticket/541
16:11:19 <zodbot> geppetto: #541 (Package Naming Guidelines - Clarification Required) – fpc - https://fedorahosted.org/fpc/ticket/541
16:11:42 <geppetto> gbcox: you are up :)
16:12:07 <geppetto> Although I'm not sure we have to do anything here
16:12:13 <tibbs|w> I still don't see what clarification is required.
16:12:16 <gbcox> Thanks... I really don't have more to add than what I've already put into the ticket.  I think the guidelines are clear
16:12:26 <gbcox> racor was the one who had the issue...
16:12:46 <tibbs|w> Guidelines say lower case is preferred.
16:13:22 <gbcox> I do think it would be wise to tighten up the exceptions
16:14:02 <tibbs|w> I'd like to work on the NamingGuidelines page at some point anyway, to split out the Versioning stuff to a different page.
16:14:07 <gbcox> Here was my last comment in the ticket regarding that...
16:14:09 <gbcox> The Naming Guidelines are not changing the identity of the project, nor the method upstream chooses to name their project. It only relates to how that package is identified within Fedora for packaging purposes. If you go to the project website, you can view how upstream wants to represent their project - mixed case, special characters, etc. It's helpful to know though, if you want to install My-FavORIte_PacKage that in Fedora,
16:14:11 <gbcox> you can simply use: dnf install my-favorite-package from the command line. I believe there is major value to that. Allowing upstream to dictate the package naming convention is just confusing and chaotic. You then don't have one uniform standard, you have thousands.
16:15:34 <mbooth> agree, seems like a non-issue
16:15:47 <tibbs|w> Can we push this down a little bit and I'll write a quick proposal?
16:15:52 <geppetto> sure
16:15:55 <tibbs|w> If I can get the wiki to do anything.
16:16:16 <geppetto> #topic #542 	Forbid "python -OO" for Python < 3.5
16:16:16 <geppetto> .fpc 542
16:16:16 <geppetto> https://fedorahosted.org/fpc/ticket/542
16:16:17 <zodbot> geppetto: #542 (Forbid "python -OO" for Python < 3.5) – fpc - https://fedorahosted.org/fpc/ticket/542
16:16:34 <tibbs|w> I'm kind of lost as to what the deal is here.
16:17:00 <tibbs|w> "something the package does causes problems.  please fix."  "the guidelines don't say I have to fix it."
16:17:11 <tibbs|w> That's basically my understanding.
16:17:26 <tomspur> Same here
16:17:54 * geppetto shrugs
16:17:55 <tomspur> I think if the python folks say, "don't use -OO" you shouldn't use -OO, but I don't think this belongs into the guidelines
16:18:11 <tibbs|w> Nevertheless, if it confuses people, one sentence won't hurt.
16:18:18 <tomspur> Maybe on some kind of "bugs we don't backport" or whatever
16:18:43 <tomspur> tibbs|w: Did you see toshios diff? ;)
16:19:31 <geppetto> wow, that's big
16:19:48 <tibbs|w> Well, I did, but I think we should try to limit the length of the python guidelines to at most the length of your favorite Tolstoy novel.
16:20:14 <geppetto> ha
16:20:27 <tibbs|w> Plus, I believe that rationale never belongs directly on a guideline page.
16:20:50 <mbooth> Yeah, I don't think the character needs that much back story
16:20:52 <geppetto> Can we just remove the rationale section
16:21:20 <mbooth> Just "don't use -OO until python-3.5" ought to suffice
16:21:33 <geppetto> Yeh, I'd be happy to remove the version qualifier too
16:21:57 <geppetto> at least until someone has a better usecase than Ales decided it was fun a few months ago.
16:22:06 <tibbs|w> For my elucidation, what does -O0  actualy do?
16:22:24 <geppetto> Removes docstrings as well as asserts
16:23:36 <geppetto> In theory this could make the .pyo files quite a bit smaller, if you have lots of API docs.
16:23:55 <geppetto> In practice … I doubt it's measurable.
16:24:19 <tibbs|w> Does that really matter?  I guess for DNF it might be (since it's always on the system), but someone should be able to at least provide some stats.
16:24:20 <geppetto> Well, the disk space is probably measurable … but still stupidly small
16:24:30 <geppetto> But I doubt the difference in load time is measurable.
16:24:50 <tibbs|w> And how does py3.5 help here?
16:25:06 <tibbs|w> It seems that since it writes out separate files, it would actually increase the disk usage.
16:25:07 <geppetto> AIUI 3.5 it kind of works somehow?
16:25:36 <geppetto> before 3.5 python will get confused if there are different optimisation levels used within the same program … AIUI
16:25:39 <mbooth> py3.5 ostensibly generates two different bytecode outputs so you can have both -O and -OO on disk
16:26:00 <mbooth> Instead of .pyo files only
16:26:30 <mbooth> (AIUI from reading toshio's text)
16:28:38 <tibbs|w> So if I add "don't use -OO on python versions less than 3.5" to Packaging:Python, where would it go?
16:29:05 <geppetto> I think we should just have:
16:29:19 <geppetto> === Python Optimization Level ===
16:29:19 <geppetto> * Fedora packages running with Python '''MUST NOT''' use <code>python -OO</code> in shebang lines (<code>python -O</code> is fine) or set the environment variable <code>PYTHONOPTIMIZE</code> to 2 or greater.
16:29:19 <geppetto> * Similarly, any <code>.pyo</code> shipped in a Fedora package for python '''MUST NOT''' have been byte compiled using optimization level 2 or higher.
16:29:49 <geppetto> Where toshio put it … so around line 143 of the python docs.
16:30:05 <tibbs|w> +1
16:30:13 <tomspur> +1
16:30:19 <geppetto> +1
16:30:29 <mbooth> +1
16:31:37 <geppetto> racor: vote?
16:35:22 <racor> back from the phone ... what is the topic?
16:35:28 <tibbs|w> We really need to have a meeting where we get more than the minimum 5.
16:35:41 <geppetto> racor: Voting on the text just before the +1's
16:36:07 <racor> my vote: 0
16:37:21 <tibbs|w> Well OK then.  Maybe we can get more votes in the ticket or something.
16:37:40 <tibbs|w> I kind of figured this was a just do it thing since it's obvious that the behavior is broken.
16:38:16 <geppetto> indeed
16:38:28 <geppetto> #action Forbid "python -OO" for all versions of Python, no need for rationale in policy (+1:4, 0:1, -1:0)
16:38:37 <geppetto> #action Need more votes
16:39:18 <geppetto> Ok, so we have 539, 540 and 541 we can talk about.
16:39:59 <geppetto> 540 seems kind of trivial, and I'm not sure we really need to do anything … but maybe putting some small number of lines somewhere will make the GCC people happ
16:40:00 <geppetto> happy
16:40:03 <tomspur> and #281
16:40:10 <geppetto> has that changed?
16:40:26 <geppetto> ahh, yes, sorry
16:40:32 <geppetto> #topic #281 	New Python Macros for Easier Packaging
16:40:32 <geppetto> .fpc 281
16:40:32 <geppetto> https://fedorahosted.org/fpc/ticket/281
16:40:33 * tomspur tested the macros and posted a diff
16:40:34 <zodbot> geppetto: #281 (New Python Macros for Easier Packaging) – fpc - https://fedorahosted.org/fpc/ticket/281
16:41:19 <geppetto> those look awesome, to me
16:41:21 * tomspur talked with mstuchli and it is fine to add those to the python package and built it on all branches
16:41:31 <geppetto> +1
16:41:40 <tibbs|w> Please define "all branches".
16:41:55 <tomspur> I only talked about Fedora with him...
16:42:06 <tomspur> Can ask about rhel again...
16:42:26 <tibbs|w> I would assume no, but it may be possible for EPEL folks to just have a macros package.
16:42:48 <tibbs|w> I don't work with python < 3.3 any more so that cuts RHEL right out.
16:43:46 <mbooth> I am +1 to that latest diff
16:44:30 <tibbs|w> +1 to that diff, though some of that is already in the guidelines now.
16:44:37 <geppetto> racor: vote?
16:44:55 <tibbs|w> I can figure it out when I write this up, assuming it passes.
16:45:03 <tomspur> tibbs|w: where would you put those macros? redhat-rpm-macros?
16:45:03 <nirik> FYI, epel does have a macros package. :)
16:45:26 <tibbs|w> nirik: Ah, cool.  I have been agitating for that for years but I didn't realize it actually happened.
16:45:28 <nirik> epel-rpm-macros
16:45:49 <tibbs|w> tomspur: In the python package if that's possible.
16:45:53 <nirik> it has these python3 macros in it already. Not sure if it's in the srpmbuild root yet, but if not it will be soon
16:46:15 <tibbs|w> But either location is fine.  Just seems to make sense to me to keep them together somehow.
16:46:27 * tomspur nods
16:46:33 <tibbs|w> nirik: Does that package get sucked in automatically?
16:46:45 <nirik> yeah, we are planning to add it to the srpm buildroot.
16:46:48 <tibbs|w> Because we might be able to encapsulate other EPEL differences in there now.
16:46:49 <nirik> (for epel)
16:46:55 <nirik> sure, sounds good.
16:47:26 <nirik> happy to add co-maintainers of FPC folks too if you want to just add things as needed.
16:48:28 <tomspur> that would be great
16:48:43 <geppetto> #action New Python Macros for Easier Packaging, py2_build/py2_install/etc. (+1:4, 0:0, -1:0)
16:48:53 <racor> my vote on https://fedorahosted.org/fpc/ticket/281; 0
16:48:59 <geppetto> #undo
16:48:59 <zodbot> Removing item from minutes: ACTION by geppetto at 16:48:43 : New Python Macros for Easier Packaging, py2_build/py2_install/etc. (+1:4, 0:0, -1:0)
16:49:05 <geppetto> #action New Python Macros for Easier Packaging, py2_build/py2_install/etc. (+1:4, 0:1, -1:0)
16:49:12 <geppetto> #action Need more votes
16:49:41 <geppetto> Ok, so back to 539, 540 and 541.
16:49:57 <geppetto> tibbs: You done a draft for 541 yet?
16:50:10 <tibbs|w> Typing now.
16:50:53 <geppetto> Ok, we might as well wait on it … as 539/540 don't have much to actually do
16:50:59 <geppetto> #topic #541 	Package Naming Guidelines - Clarification Required
16:50:59 <geppetto> .fpc 541
16:50:59 <geppetto> https://fedorahosted.org/fpc/ticket/541
16:51:01 <zodbot> geppetto: #541 (Package Naming Guidelines - Clarification Required) – fpc - https://fedorahosted.org/fpc/ticket/541
16:51:05 <racor> FWIW: I will abstain from voting on any of these current python packaging issues, because I don't feel knowlegable to vote and feel these changes are not productive.
16:51:33 <racor> geppetto: I just commented on the ticket
16:52:08 <tibbs|w> https://fedoraproject.org/w/index.php?title=PackagingDrafts%2FLowerCase&diff=416012&oldid=416011
16:53:03 <tibbs|w> I just struck "generally", moved the statement about case/dashes to the beginning, and added a sentence about asking upstream.
16:53:34 <tibbs|w> But, ugh, my editor re-wrapped things.  Dang it.
16:53:53 <geppetto> Looks fine, to m
16:54:01 <geppetto> +1
16:54:41 <tibbs|w> +1
16:55:02 <mbooth> +1
16:55:53 <racor> -1 this proposal is totally converse to what had been rule in Fedora for 10 yes. This proposal is idiotic.
16:56:14 <racor> s/yes/years/
16:56:18 <tomspur> racor: Just blindly using the tarball name won't work on all occasions as some upstreams wildly use Coke or coke together. Do you have a concrete example why this proposal is idiotic?
16:56:31 <geppetto> racor: It was a rule to always use upstream naming even when it's stupid?
16:57:07 * tomspur would also prefer lowercase names, but it makes also sense to use upper ones sometimes. So the diff above seems fine
16:57:15 <racor> geppetto: I was rule to use the tarball name - period. This had avoided endless and unpleasant rules and package conflicts.
16:57:20 <tomspur> But maybe I'm missing some concrete reason for not using it
16:57:45 <tibbs|w> That was never the rule.
16:58:22 <tomspur> If there is a naming clash of two upstreams you have a problem. No matter if one is upper and the other is lower. That confuses people anyway.
16:58:35 <tomspur> +1
16:59:00 <geppetto> Yeh, it was never the rule that you had to follow the tarball name. And it was always encouraged to use lowercase, and add a provides for the capitalized version. Just that the encouragement has been more forceful with expereience of people not doing it and how that isn't good for anyone
16:59:20 <geppetto> But … shrugs.
16:59:26 <gbcox> The preference for using lowercase was already voted on and decided by FPC in Ticket #336
16:59:26 <geppetto> #action Package Naming Guidelines - Clarification (+1:4, 0:0, -1:1)
16:59:34 <geppetto> #action Need more votes
16:59:42 <tibbs|w> gbcox: Of course it was.
16:59:43 <geppetto> #topic Open Floor
17:00:08 <tibbs|w> This just cleans up the language to be a bit less confusing, but sometimes people don't want things to be less confusing.
17:00:34 <geppetto> So do we want to talk about 540?
17:00:34 <gbcox> yes, agreed... so is my package of all lowercase ready to go now?
17:00:42 <geppetto> I'm not sure we need to do anything
17:00:48 <gbcox> or is it still being blocked by FPC
17:00:51 <racor> tibbs|w: No it causes additional churn and bugs.
17:00:54 <tibbs|w> Not blocked by FPC.
17:00:59 <tibbs|w> Blocked by your reviewer.
17:01:07 <gbcox> my reviewer didn't block it
17:01:10 <gbcox> racor did
17:01:14 <tibbs|w> Uh?
17:01:18 <gbcox> my reviewer agrees with me
17:01:19 <racor> What are you going to BR: libx or libX11
17:01:25 <tibbs|w> Then have your reviewer just click the box and go on with life.
17:01:31 <gbcox> ok, will do
17:01:36 <gbcox> thanks
17:01:40 <geppetto> racor: whatever the package is called
17:01:55 <tibbs|w> racor: The guideline says should, not must.  This isn't rocket science, you know.
17:02:05 <racor> gbcox: tibbs just overruled ... I'm this FPC has derailed.
17:02:13 <tibbs|w> And our guidelines are not retroactive.
17:02:34 <geppetto> racor: There's nothing to overrule … the packager is complying with the poliucy, and the reviewer agrees
17:02:45 <tibbs|w> racor: Blame me or curse me if you like; I can take it.  If you don't like the existing rules, feel free to submit a draft to change them.
17:02:53 <tibbs|w> But this rule has been in effect for a long time.
17:03:13 <racor> tibbs|w: https://fedoraproject.org/w/index.php?title=Packaging:NamingGuidelines&oldid=66607
17:03:20 <geppetto> And we had nothing but problems with random case before that
17:03:40 <geppetto> Way way way too many "I tried yum install mysql" and nothing happened
17:03:50 <tibbs|w> gbcox: Sorry you had to see this.
17:04:19 <gbcox> no problems... I expected it
17:05:06 <tibbs|w> I would actually be super happy to force packages to always Provides: a lower-cased name if they choose to use mixed case.
17:05:07 <tomspur> racor: There is still a "should" in it. So if not matching the tarball, it is not a problem too
17:05:34 <geppetto> tibbs: yeh, I'd +1 that
17:05:52 <racor> https://fedoraproject.org/w/index.php?title=Packaging:NamingGuidelines&oldid=400814
17:05:56 <tibbs|w> I'll make a separate proposal.  Let me wrap that draft up in another ticket.
17:06:07 <geppetto> I'd even be happy to +1 a "you should provide an exact upstream capitalization, if possible"
17:06:20 * tomspur is unsure about the provides
17:06:31 <geppetto> tomspur: Why what could go wrong?
17:06:49 <racor> sorry folks, I am not in a mood to continue this discussion and therefore prefer to quit this meeting now.
17:06:52 <tomspur> I would encourage people to do so, but writing it into the guidelines seems to more or less force them
17:07:03 <tibbs|w> He took his ball and went home.
17:07:07 <tomspur> :)
17:07:09 <geppetto> tomspur: I'm happy with a SHOULD instead of a MUST
17:07:23 <geppetto> tomspur: Just that some of them might not think of it without a nudge
17:07:27 <abadger1999> tomspur: it might be desirable to... it gives end users a consistent way to find packages.
17:07:34 <tomspur> geppetto: If racor reviews it, the should turns into a must
17:07:57 <geppetto> That's a separate thing
17:08:02 <geppetto> One I've hit recently
17:08:09 <geppetto> And I'm not sure how to solve it
17:08:39 <gbcox> As an outside observer, I don't see any value add to Fedora for having mixed case in package names or doing what upstream desires
17:08:46 <geppetto> But when you are getting a package reviewed all common sense goes out the window, and you are kind of forced to just do whatever the reviewer wants
17:09:00 <tomspur> yeah
17:09:09 <gbcox> why give upstream the power of veto over fedora packaging guidelines
17:09:26 <tibbs|w> I don't think we ever have.
17:09:43 <tibbs|w> But working with upstream in a productive fashion is one of the tenets of Fedora.
17:09:46 <gbcox> there is clear value to standardize on lowercase... what is the value add for mixed?
17:09:47 <geppetto> In general we try to be nice to what upstream wants
17:09:53 <geppetto> So that they don't hate us
17:10:03 <geppetto> Like the apache-httpd rename
17:10:20 <tibbs|w> And just recently, mscore -> musescore.
17:10:28 <gbcox> LOL... true, but in 99.999% I think they could care less... they're just happy someone is taking the time to package their program
17:10:57 <geppetto> yeh, I would certainly expect almost all upstreams to understand using all lowercase
17:10:57 <tibbs|w> Of course.
17:11:08 <tibbs|w> Which is why this whole thing is so absurd.
17:11:11 <gbcox> and you're not changing their package identity, just how it is represented internally in fedora
17:11:27 <tibbs|w> To step in to someone else's review to complain about the case of one letter seems beyond the pale.
17:11:35 <geppetto> And only the most insane to disagree if we add the provides
17:12:01 <gbcox> I don't get the drama surrounding this
17:12:06 <geppetto> But I wouldn't guarantee there are no insane OSS people out there ;)
17:12:31 <tibbs|w> gbcox: It's just an interpersonal thing.  Every project acquires some people who are just harder to handle.
17:12:44 <tibbs|w> Unfortunately one of them happened to notice your review.
17:12:49 <gbcox> ROFL
17:13:18 <tibbs|w> It sucks because this kind of thing turns off so many potential contributors.
17:13:29 <tibbs|w> But it's not really our place to fix that.
17:13:36 <gbcox> Yeah, my concern is that is happening quite a bit, and people roll over when threatening with having to take an issue to FPC
17:13:53 <tibbs|w> I really, really want to do package reviews differently in any case.
17:13:55 <gbcox> That isn't right
17:14:03 <mbooth> We are at 1.25 hours, so my time is up for today
17:14:09 <tibbs|w> Like always having the spec in some collaborative editing platform.
17:14:12 <geppetto> mbooth: I think we are done anyway
17:14:16 <tibbs|w> And yeah, I think we're done.
17:14:21 <mbooth> Cool :-)
17:14:21 <gbcox> Thanks folks!
17:14:55 <geppetto> Yeh, the two big things I think are that reviews are way too strict when they happen, and they only happen once
17:14:57 <tomspur> tibbs|w: In which sense? Isn't git collaborative? ;)
17:15:33 <geppetto> tomspur: I guess he means more like proven packagers just editing minor stuff in specs
17:15:43 <tomspur> Ah ok
17:15:45 <geppetto> except on a much bigger scale
17:15:47 <tibbs|w> No, I mean pre-import.
17:15:57 <tibbs|w> People work on a spec together.
17:16:10 <tibbs|w> Whip it into shape.
17:16:23 <geppetto> yeh, but that requires us taking the spec into something we own before we've "approved it"
17:16:35 <tibbs|w> Just the spec; that's not a big deal.
17:16:46 <tibbs|w> And I don't mean git, I mean something like etherpad or gobby.
17:16:51 * geppetto nods
17:17:19 <geppetto> I'm certainly not against that as a best practice
17:17:29 <tibbs|w> Oh, sure, it wouldn't work for every case.
17:18:04 * tomspur always wanted to write some checks to see which packages comply with the guidelines and which ones don't. e.g. introducing the %py_install macros
17:18:16 * geppetto nods
17:18:48 <geppetto> The only way I've seen that done is someone having a lot of disk space, checking out all the packages and doing greps/etc.
17:19:11 <mbooth> tomspur: More rpmlint checks
17:19:19 <mbooth> Would be a good start
17:19:23 <tibbs|w> There are complete tarballs of the git repos you can get.
17:19:32 <tibbs|w> At least there used to be.
17:19:51 <nirik> there still is. :) or is again
17:19:55 <tomspur> mbooth: yes, maybe. I thought more about on some automatic fixes.
17:20:10 <tomspur> nirik: Is it possible to use/grep on fedorapeople? :)
17:20:58 <nirik> I don't understand the question... you can use grep there yes, but it doesn't have all git pkgs repos there at all.
17:22:08 <tomspur> nirik: yeah, that was the question. If it is mounted there read-only so one can grep or so
17:22:34 <mbooth> tomspur: We have a RPM spec file editor for eclipse: https://wiki.eclipse.org/Linux_Tools_Project/SpecfileEditor/User_Guide
17:22:35 <nirik> no easy way to do that. they are not in the same datacenters
17:23:05 <mbooth> tomspur: I want to add "quickfixes" and "save actions" to it that make files more guideline compliant
17:23:33 <mbooth> Long term TODO list item :-)
17:23:42 <tibbs|w> I just use vim.  It tells me a big pile of things that are wrong with specs.
17:23:49 <geppetto> :)
17:24:03 <tibbs|w> Well, vim with syntastic, which calls rpmlint.
17:24:08 <geppetto> Is that in beepy mode or non-beepy mode?
17:24:30 <tibbs|w> I have vim and emacs and kate open right now.
17:24:34 <geppetto> ha
17:24:37 <tomspur> mbooth: Sounds good for people who like using eclipse :)
17:24:44 <tibbs|w> Working on javascript and python and perl.
17:25:05 <mbooth> tomspur: It's hard work to get java people to package software ;-)
17:25:15 <tibbs|w> You said "java".
17:25:58 <mbooth> Does that mean I lose points?
17:26:01 <tomspur> :D
17:27:44 * tomspur didn't know about syntastic+rpmlint. Will try it out later on
17:28:22 <tibbs|w> Can give you my .vimrc stuff if you like.
17:28:44 <tibbs|w> Anyway, we should probably end the meeting as I have another (real-life) meeting soon.
17:28:59 <geppetto> Do you have to configure a lot of stuff?
17:29:08 <tibbs|w> Not really.
17:29:48 <tibbs|w> Install syntastic using whatever method you use to install vim things (I use Plug) and it kind of happens automatically.
17:29:59 <geppetto> Ahh, I know I have automatic highlighting with vim … but I don't get rpmlint messages
17:30:22 <geppetto> Ahh, I _love_ having to use non-native package managers ;)
17:30:36 <tomspur> Doesn't work right out of the box over here
17:30:43 <tomspur> tibbs|w: .vimrc would be great :)
17:31:06 <tibbs|w> there's actually nothing in vimrc about rpmlint; it just happened.
17:31:13 * geppetto nods
17:31:23 <tomspur> Maybe it is interfering with some other plugins of mine... :/
17:31:42 <tibbs|w> One annoying thing is that it actually checks the Source: urls by default, which slows startup.  But you can disable that.
17:31:44 <geppetto> Anyway … I shall end the meeting in a min., unless someone brings something up real soon
17:32:10 <geppetto> Might be worth having a page somewhere about tools you can use to help with specfile creation/maintenance
17:32:21 <tibbs|w> With a spec file open, :SyntasticCheckers says http://fpaste.org/233670/43464872/
17:33:10 <geppetto> interesting
17:33:31 <tibbs|w> vimrc is at http://paste.fedoraproject.org/233671/34648788 but I have local ftplugins as well.
17:33:42 <tibbs|w> Not one for spec files, though.
17:34:17 <tomspur> thanks!
17:35:30 <geppetto> #endmeeting