16:00:18 <geppetto> #startmeeting fpc
16:00:18 <zodbot> Meeting started Thu Nov  3 16:00:18 2016 UTC.  The chair is geppetto. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:00:18 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:00:18 <zodbot> The meeting name has been set to 'fpc'
16:00:19 <geppetto> #meetingname fpc
16:00:19 <zodbot> The meeting name has been set to 'fpc'
16:00:19 <geppetto> #topic Roll Call
16:01:23 <tibbs> OK, so, FPC meeting?
16:01:32 <geppetto> #chair tibbs
16:01:32 <zodbot> Current chairs: geppetto tibbs
16:01:35 <geppetto> yep
16:01:42 <geppetto> Well, maybe
16:01:48 <tibbs> It's DST confusion time again.
16:01:59 <geppetto> Ahh, yeh, could be
16:02:21 <tibbs> My calendar entry says now, and I get that feed from fedocal.
16:02:26 <geppetto> On the upside, there's no new tickets
16:02:28 <orionp> hello
16:02:30 <mbooth> Hi
16:02:34 <geppetto> #chair orionp
16:02:34 <zodbot> Current chairs: geppetto orionp tibbs
16:02:35 <tibbs> geppetto: Sadly I'm filing one.
16:02:37 <geppetto> #chair mboddu
16:02:37 <zodbot> Current chairs: geppetto mboddu orionp tibbs
16:02:40 <geppetto> #chair mbooth
16:02:40 <zodbot> Current chairs: geppetto mboddu mbooth orionp tibbs
16:02:44 <tibbs> Just for open floor time.
16:02:45 <geppetto> #unchair mboddu
16:02:45 <zodbot> Current chairs: geppetto mbooth orionp tibbs
16:03:13 * geppetto really needs a #chair TAB complete plugin for xchat
16:03:14 * limburgher is here
16:03:21 <geppetto> #chair limburgher
16:03:21 <zodbot> Current chairs: geppetto limburgher mbooth orionp tibbs
16:03:26 <geppetto> We made 5 :)
16:04:04 <geppetto> racor Rathann might be screwed due to DST changes.
16:04:16 <limburgher> Yeah.
16:04:34 <tibbs> And tomspur would now be an extra hour later.
16:04:40 * geppetto nods
16:05:59 <geppetto> #topic Schedule
16:06:01 <geppetto> https://lists.fedoraproject.org/archives/list/packaging@lists.fedoraproject.org/message/AN2CB4KC25BIUHZ2SVHKK34GVQXU3JJE/
16:06:29 * handsome_pirate wanders in
16:08:38 <geppetto> tibbs: You want to do 657 first?
16:09:19 <orionp> Start with 650 as that had some action?
16:09:28 <geppetto> #topic #650     Alternate Python Interpreters
16:09:33 <geppetto> .fpc 650
16:09:35 <geppetto> yeh
16:09:35 <zodbot> geppetto: #650 (Suggested Change for Python Guidelines about Alternate Python Interpreters) – fpc - https://fedorahosted.org/fpc/ticket/650
16:09:47 <geppetto> 656 too, but nothing for us
16:10:15 <tibbs> Yeah, it looks like we're basically back to where we were before the detour to FESCo.
16:10:56 <tibbs> I tossed in a proposal.  Not formalized of course as I only had a few minutes.
16:11:14 <orionp> So, we're going to allow packages that nothing can require, so we need to track that - seems reasonable
16:11:32 <tibbs> I'm here all day so order doesn't really matter.
16:11:56 <geppetto> unrequired? leaf-only? standalone?
16:11:57 <tibbs> We always track these things with a Provides:; I don't see why we wouldn't do that here.
16:12:16 <geppetto> user-only?
16:12:16 <tibbs> Flip a coin at this point, I think.
16:12:17 <limburgher> geppetto: I was just thinking leaf-only
16:12:18 <orionp> agreed
16:12:29 <tibbs> leaf-only makes sense to me.
16:12:42 <geppetto> Ok, that's 3 people who think it's sane :)
16:12:48 <orionp> works for me
16:13:03 <tibbs> Sadly we sort of pollute our one namespace for packages when we do this; I wish RPM gave us another tag we could use.
16:13:04 <geppetto> mbooth: work for you?
16:13:27 <mbooth> Sure
16:13:28 <geppetto> tibbs: In what way?
16:13:29 <orionp> do we need (name) or %version added, or is "leaf-only" sufficient
16:13:41 <geppetto> tibbs: Oh, you mean that we pollute the provides namespace?
16:13:45 <tibbs> Right.
16:14:06 <tibbs> But... we do this rarely, and maybe one day RPM will give us something else to use.
16:14:14 <geppetto> We could have them be in a special rpm group … ha
16:14:18 <tibbs> And this is easy to repoquery.
16:14:29 * geppetto nods
16:14:42 <orionp> repoquery --whatrequires leaf-only
16:14:46 <tibbs> So: these packages _must_ add Provides: leaf-only(%name) = %version
16:14:56 <orionp> do we need (name) or %version added, or is "leaf-only" sufficient
16:15:14 <tibbs> Right, I figured that to avoid any type of conflict, we'd want to add the stuff.
16:15:19 <limburgher> Yeah.
16:15:25 <tibbs> But we don't need it for bookkeeping, certainly.
16:15:25 <orionp> what conflict?
16:15:28 <geppetto> #action Packages to add leaf-only(%name) = %version to not be required by other packages (+1:5, 0:0, -1:0)
16:15:31 <tibbs> I don't know;
16:15:46 <tibbs> It's basically what we do for other things where we use Provides: to track.
16:15:51 <orionp> multiple things can provide the same thing, done all the time
16:15:57 * geppetto nods … it can't hurt to add the extra stuff
16:16:14 <orionp> right but with bundled we care about what is bundled - this is just a flag
16:16:24 <tibbs> It's one line either way; I guess perhaps it could be useful but I don't care either way.
16:16:25 * geppetto nods
16:16:32 <tibbs> We just have to tell them what line to paste.
16:16:48 <orionp> but I guess "repoquery --whatrequries 'leaf-only*'" works too.
16:16:57 <tibbs> It does simplify any queries to not have anything to match.
16:17:04 <geppetto> Yeh, the tools should be fine either way
16:17:12 <tibbs> Also, does that repoquery call actually work?
16:17:25 <tibbs> I mean, nothing is actually going to BuildRequires: leaf-only.
16:17:29 <geppetto> So it's just aesthetics … if orionp thinks it should be just a flag though I'm not set on the extra data.
16:17:36 <tibbs> Or Requires: leaf-only.
16:18:00 <orionp> hmm, good question
16:18:03 <geppetto> If you do --resolve, it should work
16:18:14 <geppetto> And I think that's the default for repoquery
16:18:20 <tibbs> Well, there's repoquery and dnf repoquery.
16:18:32 <tibbs> Anyway, as long as its possible, I don't care.
16:18:33 <orionp> and dnf repoquery dropped a lot of defaults
16:18:35 <geppetto> Yeh, repoquery --whatrequires MTA
16:18:48 <tibbs> You can do --whatprovides and then loop over each of those, too.
16:19:03 <geppetto> dnf has a mandate to fix broken compat. … so that should go away
16:19:17 <orionp> we should probably start tracking what we need to start tracking...
16:19:28 <tibbs> Only two things require MTA.
16:19:31 <handsome_pirate> meta tracking
16:19:39 <tibbs> Which obviously isn't right.
16:19:56 <geppetto> yeh, I was wrong … saw results and assumed nobody would actually require just MTA
16:20:03 * geppetto sighs
16:20:26 <tibbs> Anyway, we know it's doable.  If repoquery doesn't make it trivial it doesn't matter because we know there's a way to make it work.
16:20:52 <tibbs> Another question, then: do we want to separate runtime dependencies from build-time dependencies?
16:21:12 <geppetto> I assume not
16:21:31 <tibbs> In other words, is there ever a reason to say that you can depend on something at runtime but not at build time, or the other way around?
16:21:40 <orionp> yeah, nothing should be building with this either, right?
16:21:55 <tibbs> I assume so.
16:21:57 <geppetto> Never runtime only, IMNSHO … but I guess it's possible that someone wouldn't mind build-time only
16:22:01 <limburgher> I won't speak to ever, but in this case it shouldn't be build-time or run-time.
16:22:08 <orionp> although, there is testing perhaps
16:22:17 <geppetto> But I'm happy to jump off the bridge only when we come to it
16:22:30 <tibbs> Note that we already have this type of prohibition with foo-static packages.
16:22:38 <tibbs> You can never depend on foo-static at build time.
16:22:50 <geppetto> But you can at runtime??
16:22:55 <orionp> umm....
16:22:59 <tibbs> I don't know why you'd ever depend on a static package at runtime, of course.
16:23:16 <geppetto> Yeh, and if you found a way I think people would object
16:23:25 <limburgher> tibbs: for great justice?
16:23:37 <geppetto> If anything I'd say that static should be leaf-only too :)
16:23:58 <tibbs> Of course, never say never; we do have an exception policy for that.  But then we have an exception policy for anything.
16:24:01 <geppetto> Andone want to vote on adding a line for that?
16:24:04 <orionp> So "No package can Require or BuildRequire any package that provides "leaf-only"."
16:24:20 <geppetto> yeh
16:24:36 <limburgher> Yes.
16:24:52 <geppetto> #info "No package can Require or BuildRequire any package that provides "leaf-only"
16:25:01 <tibbs> I guess we _could_ just go with "Provides: leaf-only" and then rreserve Provides: leaf-only(XXX) for communicating that if we really needed to.
16:25:30 * geppetto ¯\_(ツ)_/¯
16:26:10 <tibbs> OK, so what do I write up here?  Just Provides: leaf-only" and complicate later if there's a reason to do so?
16:26:34 <limburgher> Prolly.
16:26:35 <Rathann> hi guys
16:26:36 <orionp> Well, rpmlint will probably complain about un-versioned provides, but...
16:26:36 <Rathann> sorry
16:26:40 <geppetto> #chair Rathann
16:26:40 <zodbot> Current chairs: Rathann geppetto limburgher mbooth orionp tibbs
16:26:48 <tibbs> Ah, doh.
16:26:49 <Rathann> my calendar doesn't seem to understand UTC
16:26:52 <tibbs> Yeah, what rpmlint is a whole separate thing.
16:26:57 <limburgher> All these packages are yours, except leaf-only; attempt no Requires there.
16:26:59 * geppetto nods
16:27:45 <tibbs> OK, so I'll do Provides: leaf-only(%name) = %version and we can forget about it until someone complains that we did it wrong.
16:28:12 <tibbs> And +1 to that if we're actually voting.
16:28:29 <tibbs> Yeah, there was an action earlier.  Goodie.
16:28:43 <racor> seems to me, as if zodbot doesn't want to count me ;)
16:29:34 <tibbs> #chair racor
16:29:34 <zodbot> Current chairs: Rathann geppetto limburgher mbooth orionp racor tibbs
16:29:45 <tibbs> ....
16:30:01 <racor> tibbs: thanks
16:30:02 <geppetto> Yeh, sorry … didn't see you racor
16:30:08 <geppetto> my fault.
16:30:47 <geppetto> Ok, anything else to say … we want to vote on adding that text for static packages?
16:31:14 <Rathann> leaf-only sounds good to me
16:31:24 <tibbs> We can probably just leave static packages out of it for now.  What we have has worked pretty well for the past decade, after all.
16:31:41 <orionp> yeah
16:31:59 <orionp> +1 to be official
16:32:17 <racor> geppetto: As far as I could follow this discussion, this seems wrong for *-static packages, IMHO.
16:32:49 <geppetto> racor: ok
16:33:03 <tibbs> Exactly why I'd like to keep static packages out of it.
16:33:27 <geppetto> I didn't think they should be in requires for buildtime or runtime … but it's fine to keep them out of it atm. … just thought it'd be good to merge if they were the same
16:33:32 <racor> static packages are "devel" packages, runtime packages should not pull in.
16:33:53 <orionp> yeah, static is its own beast
16:34:02 <tibbs> Plus the static libs are often actually in the devel package.
16:34:02 <racor> but there is nothing wrong in br-ing them.
16:34:50 <racor> (except that such cases should be "very special" and "very exceptional"
16:35:17 <geppetto> ok, no problem
16:35:26 <geppetto> So we good to move on?
16:36:05 <tibbs> Yep.
16:36:07 <geppetto> #topic #657 	Keeping packager tooling in sync with our guidelines
16:36:12 <geppetto> .fpc 657
16:36:13 <zodbot> geppetto: #657 (Keeping packager tooling in sync with our guidelines) – fpc - https://fedorahosted.org/fpc/ticket/657
16:36:30 <tibbs> I just filed this.
16:36:45 <tibbs> I really just wanted to make sure we talked about it at some point.
16:37:06 <Rathann> right
16:37:21 <orionp> yeah, good stuff
16:37:32 <geppetto> Yeh, those tools should probably take flags for which distro. they are operating against.
16:37:37 <tibbs> There are a number of interrelated issues which I didn't get to mention when I typed that up.
16:37:46 <geppetto> But default to the latest is the next best thing
16:38:01 <orionp> fedora-review has some of that capability
16:38:16 <tibbs> We're facing the issue that we have cross-distro tools which we expect to be useful in checking Fedora specs.
16:38:28 * geppetto nods
16:38:34 <geppetto> and rmlint is it's own beast
16:38:38 <orionp> but that has been an issue with rpmdev-newspec and debate over what to support
16:39:03 <geppetto> people have complained for a long time that it should default to whatever policy is … and I think some have attempted changes to do that
16:39:06 <tibbs> The thing is, if rpmdev-newspec creates somethng that violates even a SHOULD NOT then... it's not useful for new packagers.
16:40:15 <tibbs> We really need to accept that at some point it's going to be close to impossible to have one spec that meets all Fedora guidelines and still works on vanilla RHEL5.
16:40:22 <tibbs> I'm lagging, BTW.
16:41:01 <Rathann> yup, it already is becoming kludgy to support EL6 and newer in one spec
16:41:07 <tibbs> But RHEL5 is EOL soon, so....
16:42:06 <tibbs> The thing is, if we have this hypothetical spec generation tool and the maintainer refuses to update things to comply with Fedora guidelines, then I think we should mention loudly somewhere that people should not make use of this tool.
16:42:47 <tibbs> But I think we're in a worse situation where things have diverged enough and basically nobody's paying attention.
16:42:58 * geppetto nods
16:43:16 <geppetto> rpmdev-newspec should be easy to fix, I think.
16:43:16 <tibbs> I think fixing rpmlint and fedora-review to do the right thing and complain when necessary will at least save people time.
16:43:55 <tibbs> I found an old ticket against cpanspec and it's probably going to move forward at some point in the not too distant future.
16:44:08 <tibbs> Well, I found and updated an old tic.et
16:44:31 <tibbs> But rpmlint, well, we kind of rely on it.
16:44:58 <tibbs> We really should be adding checks to it for everything we can.  It's just that there isn't enough time.
16:45:17 <tibbs> It's been a long time since I tried to get something changed in rpmlint so I guess I should try again.
16:45:29 <Rathann> it'd be nice rpmlint had a --dist fedora|suse|whatever option
16:45:34 <tibbs> I thought it did.
16:45:45 <tibbs> Well, it has different configurations.
16:46:02 <Rathann> ah it does
16:46:15 <tibbs> And honestly, I don't care what it does, but when you run rpmlint on Fedora you should have it checking against Fedora guidelines.
16:47:34 <tibbs> So, the thing is, this basically needs us as individuals to do some work to contribute patches.
16:48:45 <tibbs> I've never really looked within rpmlint to see how it works or whether Fedora can add its own checks without stomping on whatever cross-distro support it has.
16:49:05 <geppetto> yeh, me either
16:49:55 <tibbs> I will try to at least make a basic test and see if there's a hole in the documentation I can fill.
16:50:17 <tibbs> I just don't know if anyone else has any time to work on it.
16:50:25 <geppetto> Not in the near term
16:50:46 <tibbs> I think it's that way all around.
16:51:08 <tibbs> It might turn out to be really easy to add tests.  Getting them actually in the distro, I'm not sure.
16:51:43 <tibbs> Another thing to consider is that, perhaps, FPC should basically be helping to maintain these packages.
16:51:52 <limburgher> If you can spell out a simple workflow, like, where to add a test, things to look at to make sure it doesn't break for other distros, I could take a stab at some.
16:52:12 <tibbs> Yeah, that's what probably needs a quick writeup.
16:52:58 <tibbs> Hmm, so rpmlint  is maintained by kevin, spot, tmz and twoerner.
16:53:21 <tibbs> Spot is POC.  I have a feeling spot wouldn't have a problem at all with having FPC folks involved.
16:53:38 * limburgher nods
16:53:58 <tibbs> Sadly it has 15 open bugs and could use some love.
16:55:12 <tibbs> Wow, /usr/bin/el4-rpmlint.
16:56:40 <tibbs> I think with rpmlint, the best thing to do would be to for us to just work in the Fedora package and then offer those tests to upstream.
16:57:01 <limburgher> Agreed.
16:57:03 <tibbs> Having things flow from upstream down to Fedora at some arbitrary rate doesn't really serve our packagrs well.
16:57:24 <tibbs> But of course everything we do should be maximally upstreamable.
16:58:55 * geppetto nods
16:58:55 <tibbs> Also, rpmlint appears to be in RHEL proper (6 and 7, at least).
16:59:07 <tibbs> I wonder if Red Hat has any custom magic in their package.
17:00:29 <tibbs> Anyway, it looks like rpmlint itself is really, really simple to work with.  So I'll see what I can do.
17:01:00 <geppetto> I'm pretty sure that rpmlint is unchanged in rhel
17:01:04 <tibbs> Anyway, I guess that's about all I had to say about that.
17:01:08 <geppetto> whatever is in fedora is shipped as is
17:01:14 * geppetto nods
17:01:19 <geppetto> #topic Open Floor
17:01:53 <tibbs> I went ahead and requested commit access to rpmlint.
17:02:03 <geppetto> So, I won't be near a computer next week … I might be able to do the schedule and run the meeting the week after, but I'm not sure
17:02:09 <geppetto> tibbs: cool
17:02:26 <tibbs> I don't _think_ I'll have anything going on.
17:02:41 <tibbs> So I can try, assuming that DST doesn't embarrass me.
17:02:59 <geppetto> Well it's kind of back to normal next week :)
17:03:15 <tibbs> Depends on whether we stay at 16:00....
17:03:31 <geppetto> it should be on New_York time
17:03:39 <limburgher> Not really.  The Cubs went all the way.  Normal has died. ;)
17:04:05 <tibbs> I didn't realize it was superbowl time already.
17:04:06 <geppetto> limburgher: ha
17:04:19 <geppetto> limburgher: They were the favourites at various points
17:04:26 <limburgher> They got like 8 touchdowns, and make some good spikes.
17:04:32 <geppetto> haha
17:04:45 <geppetto> Good spotsballing
17:04:52 <geppetto> ¯\_(ツ)_/¯
17:05:00 <limburgher> geppetto:  I believe you.  I don't follow baseball but I'm thrilled for my parents. :)
17:05:41 <tibbs> So the fedocal entry has this meeting at the same time next week in my local time zone.
17:05:58 <geppetto> what's that?
17:06:12 <geppetto> Are they on a UTC calendar entry?
17:06:20 <geppetto> Where do they meet?
17:06:38 * geppetto has all the questions and no answers
17:06:49 <tibbs> Yeah, in UTC it's set to change to 17:00.
17:06:55 * geppetto nods
17:06:56 <racor> tibbs: DST has ended last weekend in EU, so we're one hour earlier local time now than we were.
17:07:06 <geppetto> yeh
17:07:09 <tibbs> Sorry, I guess I lagged again.
17:07:17 <geppetto> but we end in 4 days
17:10:08 <tibbs> OK, now someone was at the door.
17:11:19 <tibbs> OK, so yeah, I know the US ended up being stupid with DST, which is why personally I'm always happy to just change the meeting time when the part of the world that playes real football does.
17:11:44 <limburgher> Works for me.
17:11:45 <tibbs> That way Eurpoean folks don't notice any difference and Americans get confused.
17:12:04 <limburgher> What's 1700UTC in Fahrenheit?
17:12:07 <tibbs> But fedocal is se5t to change to 1700 for next meeting, so we should all be back on track.
17:12:12 <geppetto> I'm mostly fine with that, if you want to change the calendar
17:13:05 <mbooth> limburgher: About 4.3 furlongs
17:13:11 <tibbs> The only other thing I wanted to mention is that I'm continuing to work on https://fedoraproject.org/wiki/User:Tibbs/VersioningCleanup
17:13:19 <limburgher> mbooth: Thank you.
17:13:53 <tibbs> But I think maybe I'm too verbose, and so it ends up being longer.  Maybe longer isn't strictly worse, though, and I'm not yet done anyway.
17:14:13 * geppetto nods
17:15:15 <geppetto> The more I've thought about it the more I've thought it just needs a "this is the simple case" and "this is the more complicated case" … and a set of reasons/whatever to choose/not-choose the simple case.
17:15:39 <tibbs> That's exactly what's there currently.
17:15:57 * geppetto stops trying to fix his time machine
17:16:12 <tibbs> I've used the term "simple" to describe a versioning scheme that's basically what most people would expect.
17:16:18 * geppetto nods
17:16:30 <tibbs> You read the intro, the definitions, the "Simple versioning" section and you can stop.
17:16:41 <geppetto> yeh
17:17:02 <tibbs> Then there's a list of five conditions (more than one of which may apply) and a section for how to handle each.
17:17:14 <tibbs> The idea is for everything to include links to the examples page.
17:17:34 <tibbs> And for all of the original examples to be there, along with new ones.
17:18:32 <geppetto> sounds awesome
17:18:43 <tibbs> What's in there now also includes the "Version: 0" thing we did last week, and it also includes the suggestion of using YYYYMMDD.shorthash in Release: which we didn't actually vote on last time.
17:18:53 <tibbs> But it's easy to remove that when the time comes if necessary.
17:19:28 <tibbs> In doing this, I actually realized that the existing guidelines really did leave several things unspecified.
17:20:17 <tibbs> Anyway, if I can stop losing changes I'll actually have this done soon.
17:21:11 <tibbs> Anyone ever seen an upstream that uses a versioning scheme which includes negative components?
17:21:17 <tibbs> 0.1.-2.3 ?
17:21:21 <geppetto> god no
17:21:34 <tibbs> I swear I saw something that did that at one time.
17:22:06 <tibbs> See, nothing in our document tells you what to do when upstream uses prohibited characters in their _version_.
17:22:41 <geppetto> cry?
17:22:50 <geppetto> complain to upstream?
17:22:56 <tibbs> It's actually easy to handle, but our document doesn't say how.
17:23:30 <tibbs> To me that's not a big deal, except that for the tilde thing we wanted them to account for every possibility, when the current document didn't even do that.
17:23:43 * geppetto nods
17:23:52 <geppetto> I assume that doesn't come up ever
17:24:09 <tibbs> I sure as hell hope not.
17:24:21 <tibbs> But the idea is to just drop in an example whenever someone has a question.
17:24:24 <geppetto> part of me wants to make a package with a utf8 version now … but that will pass :)
17:24:28 <tibbs> And to hope that I've covered all of the cases.
17:24:36 * geppetto nods
17:25:31 <tibbs> Anyway, still so much to do.
17:26:07 <geppetto> Yeh
17:26:29 <geppetto> Anyway, we can probably end this meeting now, and do other stuff
17:26:43 <geppetto> Unless anyone has anything?
17:27:48 <tibbs> I think I'm out.
17:28:44 <geppetto> #endmeeting