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