16:00:01 #startmeeting fpc 16:00:01 Meeting started Thu Jul 19 16:00:01 2018 UTC. 16:00:01 This meeting is logged and archived in a public location. 16:00:01 The chair is geppetto. Information about MeetBot at http://wiki.debian.org/MeetBot. 16:00:01 Useful Commands: #action #agreed #halp #info #idea #link #topic. 16:00:01 The meeting name has been set to 'fpc' 16:00:02 #meetingname fpc 16:00:02 #topic Roll Call 16:00:02 The meeting name has been set to 'fpc' 16:00:10 Hey, folks. 16:00:11 hi 16:00:12 #chair redi 16:00:12 Current chairs: geppetto redi 16:00:15 #chair tibbs 16:00:15 Current chairs: geppetto redi tibbs 16:00:18 .hello2 16:00:19 Hey 16:00:19 ignatenkobrain: ignatenkobrain 'Igor Gnatenko' 16:00:22 #chair ignatenkobrain 16:00:22 Current chairs: geppetto ignatenkobrain redi tibbs 16:00:25 .hello2 16:00:26 decathorpe: decathorpe 'None' 16:00:30 #chair decathorpe 16:00:30 Current chairs: decathorpe geppetto ignatenkobrain redi tibbs 16:00:40 woo, 5 ftw :) 16:00:48 .hello2 16:00:51 orionp: Sorry, but you don't exist 16:00:54 #chair orionp 16:00:54 Current chairs: decathorpe geppetto ignatenkobrain orionp redi tibbs 16:00:58 hah! 16:01:00 :) 16:01:23 hi everybody! I'm really sorry for meeting the last few meetings, I've spent three weeks in hospital ... but I'm back now 16:01:33 hi 16:01:39 #chair mhroncok 16:01:39 Current chairs: decathorpe geppetto ignatenkobrain mhroncok orionp redi tibbs 16:01:49 decathorpe: You doing better?!? 16:02:06 gepetto: yeah, I am. thanks :) 16:02:20 oops, typo. 16:03:11 no problem :) 16:03:15 so many ppl today 16:03:33 * mhroncok would need to bail out in ~1 hour 16:03:47 mhroncok: we only have the meeting for 1 hour 16:03:59 geppetto: well, but it could go into 2 hours 16:04:29 Maybe, I think we've run into go/no-go meetings before … but that's probably not on atm. 16:04:51 #topic Schedule 16:04:53 https://lists.fedoraproject.org/archives/list/packaging@lists.fedoraproject.org/message/GSUKP4G7KFIJAH2DYHMI5H6VOJTEEVYJ/ 16:05:03 #topic #759 Don't require editing of Source0 in Python spec template 16:05:06 .fpc 759 16:05:08 geppetto: Issue #759: Don't require editing of Source0 in Python spec template - packaging-committee - Pagure - https://pagure.io/packaging-committee/issue/759 16:05:34 There were a couple of votes in the ticket here already 16:06:00 +1 (already on the ticket) 16:06:18 +1 from me 16:06:36 I was +1 in the ticket 16:06:51 +1 16:06:59 +1 from me too 16:07:39 redi: Ok, just you left to vote 16:08:06 +1 ! 16:08:08 #action Don't require editing of Source0 in Python spec template (+1:7, 0:0, -1:0) 16:08:12 (for the logs) geppetto was +1 on the ticket 16:08:19 I'll write that up now. 16:08:27 #topic #774 Reword "Addon Packages" a bit 16:08:31 .fpc 774 16:08:32 geppetto: Issue #774: Reword "Addon Packages" a bit - packaging-committee - Pagure - https://pagure.io/packaging-committee/issue/774 16:09:12 tibbs: we talked a little about this withou quorum … do you have anything to say for everyone? 16:09:56 Not really. I'm still not sure if removing the "new" was the only change requested. 16:10:04 If so, I think I would have just done it. 16:10:15 #topic #775 Allow to have %{?suse_version} condition in spec file 16:10:19 .fpc 775 16:10:20 geppetto: Issue #775: Allow to have %{?suse_version} condition in spec file - packaging-committee - Pagure - https://pagure.io/packaging-committee/issue/775 16:10:30 eurgh 16:11:51 I'm still -1 to any "official" acceptance of this kind of thing. 16:12:01 down with this sort of thing 16:12:09 I mostly agree with tibbs in the ticket … it's fine in small doses, but don't really want to encourage it. 16:12:21 Adding a few extra provides should be a lot easier, and cleaner. 16:13:07 I'd rather just say that "we can't stop you, but will try to avoid automatic cleanup which would interfere with that stuff" 16:13:31 yeah. If somebody wants to do it, I don't think we should go around ripping that stuff out of their spec, but also don't want to see it officially blessed or encouraged 16:14:07 Might be worth saying something about adding provides as a better/cleaner workaround 16:14:45 agree with tibbs 16:14:59 Adding dependencies won't be a complete workaround in any case. 16:15:05 But it would certainly help. 16:15:11 * geppetto nods 16:15:47 And if maintainers don't want to do that, we can always add stub packages like I do for python2-* in EPEL. 16:16:38 Hmm 16:16:49 Not sure we want to encourage that either :p 16:16:56 Of course you could balk at going through all that effort to avoid just having someone use some suse-specific macro, but I think saving packagers from having to care is better. 16:17:47 And, sure, no point in thinking about stub packages until after the relevant maintainers have nixed the idea of adding the Provides: to the relevant packages. 16:18:00 * geppetto nods 16:18:02 Anyway, it's just a PR away. 16:18:22 So, do we want to vote on anything here? 16:19:10 I don't really think anything would pass. 16:19:40 #topic #777 Improved text for default services page 16:19:42 .fpc 777 16:19:43 geppetto: Issue #777: Improved text for default services page - packaging-committee - Pagure - https://pagure.io/packaging-committee/issue/777 16:19:45 But there seems to be some agreement that we shouldn't blanket allow such things, so I don't think any guidelines change would happen. 16:20:02 OK, I put together a draft. 16:20:20 I think it says what was requested. 16:21:11 If anyone understands the "optionally failing" thing, feel free to tell me WTF it's supposed to be allowing. 16:22:28 Seems like we go to lengths to say that services can't fail if they're enabled by default, and then.... it's OK for them to fail if they have an opt-in mechanism. 16:22:47 "for example, when hardware which is expected to be present is removed or stops functioning" could do with clarification 16:22:49 But I thought the opt-in mechanism would be "systemctl enable" so I guess I just don't get it. 16:23:02 not much point in an example if it doesn't tell us what it's saying 16:23:06 redi: I don't disagree, but that is their text. 16:23:16 yeah, I'm not criticising your draft :) 16:23:28 And as I've said, I don't understand at all what is wanted, so I don't know how to make it better. 16:24:28 Maybe they have in mind some tool to control these things which somehow doesn't end up doing 'systemctl enable' when it wants to turn them on. 16:24:38 That seems utterly bizarre to me. 16:24:58 There must be some example someone had in mind; I just don't know what it is. 16:25:20 And I don't understand why saving state matters at all. 16:25:35 I wonder if rngd is compliant these days - it exits with an error on EL7 on hardware that doesn't support it - not sure about current Fedora.... 16:26:03 I think I get it 16:27:03 lets say you have a fancy fpga board installed. you enable a service that's meant to talk to it. if it melts, you don't want the service to just silently exit without error. you want it to be marked as "failed" 16:27:16 the current rule doesn't allow that 16:28:14 if it saves state in permanent storage it can record that it worked on the last boot, and therefore its failure now is unexpected, so mark as failed 16:28:23 if it never worked previously, it was probably never installed. 16:28:52 I'm not sure what the "An opt-in mechanism involving a userspace tool with proper documentation." means though. If you have to opt-in then the service isn't enabled by default anyway, and isn't covered by these rules 16:29:22 The current rule does allow that, though. 16:30:29 Hmm, OK, maybe that was true of one of the three versions of this that I lost because of the wiki being a wiki. 16:30:40 :) 16:31:04 At one point there was a phrase saying that things had to start without error under normal conditions. 16:31:49 redi: I think it's saying an opt in mechanism that makes the service fail when HW doesn't exist 16:31:49 They could still fail under exceptional conditions, like "you have the random number generator but... somehow we are erroring out when talking to it because your motherboard is fried". 16:32:39 geppetto: yeah, I was going to say something like that. so normally if it doesn't exist, it exits silently, but there's a way to say "be noisy if it stops working" 16:32:49 * geppetto nods 16:33:34 FWIW this is the diff. from current: https://fedoraproject.org/w/index.php?title=Tibbs%3ADefaultServices&type=revision&diff=522564&oldid=522327 16:33:38 I think I'm +1 16:33:52 tibbs: yeah, h/w that is expected to be present (because it's been configured to be expected) not being present is exceptional. 16:34:14 the bullet about saving state in permanent storage says "to aid in detecting the failure" which seems to suggest it only stores some info about the failure for debugging, rather than my guess of remembering if it worked last boot 16:34:28 I might be reading too much between the lines. 16:34:51 How about if I add a fourth condition "Must not fail under normal conditions". 16:35:02 works for me 16:35:04 In the text, define what "fail" means. 16:36:17 I still think a concrete example (from sgallagh or zbyszek) could clarify things 16:36:28 * sgallagh looks up 16:36:58 sgallagh: https://pagure.io/packaging-committee/issue/777 the "such as if hardware that is expected to be present disappears or stops functioning" case 16:37:01 Could someone summarize the question? there's a lot of scrollback 16:37:17 sgallagh: https://pagure.io/packaging-committee/issue/777#comment-522407 16:37:25 "And then that weird section about value in optionally failing comes along and contradicts all of the other rules and confuses things" 16:38:02 redi: I mean that there may be services for which we *want* to know if they stopped working when they previously worked fine. 16:38:37 For example, we installed a hardware RNG device to provide entropy to the system, but later it malfunctioned or someone knocked it out of the machine. 16:39:03 It should't fail in the pristine case where we assume that people don't have hardware RNG devices normally 16:39:17 But it probably SHOULD fail if one had been detected and used previously and suddenly isn't there anymore 16:39:36 but if it was working on last boot, or if the admin has somehow said "this machine expects this h/w" then it should be marked "failed" if absent 16:39:36 So we need to be able to store that information and make decisions from it 16:39:49 Right, that's why I'm adding this text as an additional prerequisite for something starting by default: The service must not under normal operating conditions exit with an error causing systemd to mark the unit as failed. A service which is started by default is permitted to fail under exceptional conditions. 16:40:11 redi: Yes 16:40:23 That is now in the current draft. 16:40:34 That clause is to allow for those decisions to be made automatically if sensible and not necessarily require the admin to say "we expect this" 16:41:13 If that is the whole point of that extra section, then simply saying "yes, you can fail when you see that something is broken" should cover it, I think. 16:41:26 yeah 16:41:26 tibbs: Works for me. 16:42:13 OK, I added that text and removed the more confusing text. 16:42:17 Thanks 16:42:24 So reload and have a look. 16:42:44 If folks need time to read, we can move on and collect votes in the ticket. But we should try to get this done soon. 16:43:03 tibbs: would "The service must not under normal operating conditions exit with an error causing systemd to mark the unit as failed" read better with commas around the "under normal operating conditions" clause? 16:43:27 i.e. The service must not, under normal operating conditions, exit with an error causing systemd to mark the unit as failed. 16:43:57 That's a tricky grammatical question. The sentence doesn't have dependent clauses so it wouldn't cause comma overload. 16:44:11 parens might be more clear 16:44:31 or "Under normal operating conditions, the service must not exit with an error causing systemd to mark the unit as failed." but I see the value in starting each requirement with "The service must not ..." 16:44:35 Should we perhaps provide a non-exhaustive example of "exceptional conditions" (such as "hardware present but malfunctioning")? 16:44:50 An example certainly wouldn't hurt. 16:44:53 yes, that's kind of what I was getting at with concrete examples. 16:45:21 Parentheses tend to be over-inserted in English text by programmers, I think. 16:45:32 I know I'm guilty (of that) 16:45:38 heh 16:45:49 Adding an example. 16:46:13 (•‿•) 16:47:02 .fire geppetto 16:47:03 adamw fires geppetto 16:48:00 ha 16:48:15 OK, two examples have been added. 16:48:55 +1 16:48:58 "Or a server could fail to start " s/server/service/ ? 16:49:31 or do you mean a service that runs a server? I guess either is right :) 16:49:56 I'd rather say service 16:49:59 I think "service" is more correct there. 16:49:59 "service" is what I intended. Fixed. 16:50:02 if server was intentional 16:50:05 Otherwise, that looks good to me 16:50:06 ok 16:50:07 when I first read it I thought "server" meant a machine 16:50:15 but it could be a web server, or NFS server etc 16:50:31 LGTM 16:50:33 redi: Which are actually just "machines running the web service" 16:50:49 :) 16:51:33 +1 in case it isn't obvious. 16:51:40 +1 16:51:41 +1 16:51:51 the latest draft clarifies all the bits that gave me pause 16:52:04 sgallagh: thanks for jumping in 16:52:43 Happy to help 16:53:03 if you need another vote, it's +1 from me since I think you fixed all the issues while I wasn't looking ;) 16:54:26 yeh, that's +5 now … but mhroncok or ignatenkobrain can still vote 16:54:38 geppetto: I voted 16:54:49 orionp can vote i guess 16:55:02 yeh, ignatenkobrain or orionp 16:55:20 +1 16:55:31 OK, so one more down. 16:55:39 Still have a couple of minutes. 16:55:43 yeah, +1 16:55:43 * geppetto nods 16:55:48 had to re-read 16:55:49 #action Improved text for default services page (+1:7, 0:0, -1:0) 16:55:59 #topic #781 Wiki:Packaging:Java Guidelines Update (one-liner) 16:56:01 .fpc 781 16:56:02 geppetto: Issue #781: Wiki:Packaging:Java Guidelines Update (one-liner) - packaging-committee - Pagure - https://pagure.io/packaging-committee/issue/781 16:56:06 looks like we should be able to do this 16:57:05 can we +1 it conditionally? 16:57:22 Well we can accept it but not write it up until it's ready. 16:57:35 mhroncok: I thought we hate conditionals ;) 16:57:40 yep, agreed 16:58:05 decathorpe: :D 16:58:08 ok, +1 16:58:37 I will have to go 16:58:38 I'm still +1 with the assumption that someone's actually going to fix what breaks. 16:58:45 +1 - seems to make sense 16:58:52 consider me +1 on the python_sitearch/lib one 16:58:55 bye 16:58:58 take care. 16:58:59 +1 16:59:03 +1 16:59:27 +1 16:59:55 I do still agree that this should be filed as a change, but if we approve this then that portion of the change process is complete. 17:01:01 We still do have quorum. 17:01:58 orionp: vote? 17:03:06 #action Wiki:Packaging:Java Guidelines Update (+1:6, 0:0, -1:0) 17:03:09 I'll just note that javapackages-filesystem is not (yet?) in EL7 17:03:18 #topic #782 Forbid %{pythonX_site(lib|arch)}/* in %files 17:03:25 .fpc 782 17:03:26 geppetto: Issue #782: Forbid %{pythonX_site(lib|arch)}/* in %files - packaging-committee - Pagure - https://pagure.io/packaging-committee/issue/782 17:03:58 So mhroncok already voted +1 17:04:35 So the guidelines already say what you should use in https://fedoraproject.org/wiki/Packaging:Python#Byte_compiling 17:04:49 And already say this: 17:04:55 You should not include the directories %{python3_sitearch}/__pycache__ or %{python3_sitelib}/__pycache__ because they are already owned by the python3-libs package. 17:05:09 So... this ticket is kind of redundant. 17:05:20 Will capitalize that should, though. 17:05:56 I made that change. 17:06:16 Is there anything else? 17:06:21 So... this ticket seems to come down to changing the SHOULD NOT to a MUST NOT. 17:07:01 looks that way 17:07:02 I'm personally OK with MUST but I'm still struggling to figure out what difference it really makes. 17:07:25 same here 17:07:33 tibbs: just directory ownership? 17:07:51 Yes, it just leads to multiple ownership of the __pycache__ directory. 17:07:58 it's like we could do /* 17:08:25 Right, though most would get it wrong and hit conflicts due to permissions on /usr being 555. 17:08:42 Sorry, not /usr, /usr/bin. 17:08:51 No idea why that's the case, but it is. 17:09:27 The ticket linked to a bugzilla ticket, but it turned out to be unrelated. 17:10:16 FWIW, we could automatically generate .python3-files.list and use %files -f 17:10:43 shouldn't it be better? ;0 17:10:52 but I would vote +1 for changing SHOULD NOT to MUST NOT 17:11:16 yeah, that change from SHOULD to MUST won't hurt, so +1 from me too 17:11:19 We could, technically, as part of %python3_install. 17:11:40 I can +1 it; it's really just a cleanliness issue. 17:12:39 +1 but I'm mostly just going along with peer pressure to look cool, because I don't really get it ;) 17:13:31 :) 17:13:33 It's OK to just leave the votes tallied in the ticket and let Miro comment on whether he thinks things still need to change. 17:13:39 if somebody has a good reason they want to do it we can change back to SHOULD NOT, but until then MUST NOT seems good 17:13:43 I mean, it doesn't have a real draft. 17:14:29 Unless my proposal of "s/SHOULD/MUST/ in one place" counts.... 17:15:34 I think we should move on, really. 17:15:59 Ok, that's way over an hour and al the new tickets 17:16:20 We have +3 for this … and I'm mostly happy to +1 it making it +4 17:16:33 Oh, ignatenkobrain was +1 too 17:16:39 So that's +5 17:17:46 orionp: or decathorpe want to vote? 17:18:14 He may still have changes in mind, but I may hoist that bit out of the "Byte compilation" section into some place where it's more obvious that we're indicating how your %files section should look. 17:18:23 * geppetto nods 17:18:24 I already voted +1 17:19:03 +1 17:19:18 #action Forbid %{pythonX_site(lib|arch)}/* in %files (+7, 0:0, -1:0) 17:19:24 #topic Open Floor 17:19:36 Ok, anything quick to talk about? 17:19:41 Might be worth taliking about 784 even though it's really new. 17:20:57 well, I finally got around to formalize my thoughts about this, we don't have to talk about it today 17:21:16 it just frustrates me that the number of "accidental soname bumps" seems to grow 17:22:08 You're right, but if this is really to help it would be good to have an idea of how to find packages which don't do the right thing. 17:22:24 even I understand the motivation, this will complicate CI systems for instance where you use one spec to build git versions of a package. also people will get annoyed for this 17:22:27 so I'm +0.1 17:22:28 ;) 17:22:48 even when doing CI it's useful information that the soname has changed 17:23:21 It may even be more important in the context of a CI system. 17:23:22 tibbs: well, we can always patch build/files.c to make an error if /usr/lib*/*.so* is included by such regex after all 17:24:00 (if it helps, I can hack up a script to check all specs and come back next week with more data) 17:24:06 Would rather find it by specfile inspection rather than another big bunch of FTBFS. 17:24:21 I'm just unclear on how you would handle it, though. 17:24:23 I'm mostly -1 … as I think it should be solved in a different way (like in bodhi or something) 17:24:42 Certainly bodhi doesn't help you for rawhide. 17:24:56 true, but does anyone care for rawhide? 17:25:00 well. gating + rawhide kinda didn't work out 17:25:13 even for rawhide soname bumps have to be announced one week in advance 17:25:21 which is hard if you do one accidentally 17:25:21 geppetto: well, I use it ;) 17:25:30 But you're right that this is a half-solution. 17:26:20 I mean, an unchanging so version does not really imply that a library update doesn't require rebuilds down the dependency tree. 17:26:30 sure, that too 17:26:39 geppetto: bodhi didn't help in the soundtouch case, where an accidental soname bump was pushed to stable (without rebuilding dependencies, of course) 17:27:17 decathorpe: yeh, I'm just saying that something should trigger a giant warning in bodhi that says "This is an SO bump change, are you really sure etc. etc." 17:27:33 Still, we can only control packaging guidelines. 17:27:56 Yeh, it just feels like the wrong way to workaround the problem 17:28:07 yes, that would help preventing pushed updates. we could still discourage usage of globs 17:28:34 Thing is, if we discourage it somehow then someone is justified in filing various reports about it. 17:29:05 decathorpe: Why do you want to discourage globs though? 17:29:30 decathorpe: apart from as a workaround for updates going out without testing 17:29:56 because packagers actually would notice soname bumps, because the build would fail 17:30:19 I think the fundamental issue is that there are a number of cases where it would have helped maintainers to notice changing SO versions. 17:30:28 tibbs: exactly 17:30:53 I thought there was some system which notified maintainers of ABI changes, but of course after you've done 'fedpkg build' it's too late. 17:31:13 The fact that we also don't have a broken deps report just exacerbates the problem. 17:31:25 But of course that's not FPC's issue to deal with. 17:32:10 As I said, I'll check how many packages this "glob issue" affects until next week, so we have more data to base our discussion on. 17:32:40 Ok 17:33:13 Alright, I'll close in a minute 17:33:17 only 35 minutes over :) 17:33:50 It's not time wasted if something got done. 17:33:56 * geppetto nods 17:34:19 Besides, 35 over isn't bad for having missed quorum for the previous several meetings. 17:34:43 True 17:35:22 #endmeeting