17:00:52 #startmeeting fpc 17:00:52 Meeting started Thu Feb 14 17:00:52 2019 UTC. 17:00:52 This meeting is logged and archived in a public location. 17:00:52 The chair is geppetto. Information about MeetBot at http://wiki.debian.org/MeetBot. 17:00:52 Useful Commands: #action #agreed #halp #info #idea #link #topic. 17:00:52 The meeting name has been set to 'fpc' 17:00:52 #meetingname fpc 17:00:52 The meeting name has been set to 'fpc' 17:00:52 #topic Roll Call 17:00:57 yo 17:01:01 #chair redi 17:01:01 Current chairs: geppetto redi 17:01:04 Hey, folks. 17:01:09 #chair tibbs 17:01:09 Current chairs: geppetto redi tibbs 17:01:11 o/ hello 17:01:14 #chair decathorpe 17:01:14 Current chairs: decathorpe geppetto redi tibbs 17:01:52 * limburgher here 17:02:02 hey 17:02:17 #chair limburgher 17:02:17 Current chairs: decathorpe geppetto limburgher redi tibbs 17:02:19 #chair mhroncok 17:02:19 Current chairs: decathorpe geppetto limburgher mhroncok redi tibbs 17:04:52 #topic Schedule 17:04:55 #link https://lists.fedoraproject.org/archives/list/packaging@lists.fedoraproject.org/message/IAO6B2SKPGYUVYO2FWPGTJY2YJJ3DKLB/ 17:05:31 #topic #848 Clarify the use of path macros with respect to build dependencies 17:05:33 .fpc 848 17:05:34 geppetto: Issue #848: Clarify the use of path macros with respect to build dependencies - packaging-committee - Pagure.io - https://pagure.io/packaging-committee/issue/848 17:05:57 I haven't had time to even look over tickets this week. 17:06:02 IIRC this is kind of an ongoing thing we don't really need to discuss but keeping on the meeting list so we are all aware of it? 17:06:25 Well, something in the guidelines does need to change. 17:06:28 tibbs: Nothing new AFAIK 17:06:40 Ok, is there anything we can discuss today? 17:06:43 And there's a PR submitted. 17:06:47 * geppetto nods 17:07:55 my RPMMacros page update PR is also still open 17:08:02 should I just merge it? 17:08:03 I'm mostly happy with the proposal and solution 17:08:11 decathorpe: link? 17:08:14 I guess the wording has been tweaked but not since the last rebase a month ago, and there was discussion after that. 17:08:25 a bit OT, sorry: https://pagure.io/packaging-committee/pull-request/846 17:08:44 Yeah, let's do that one after this one. 17:10:01 the patch looks OK to me 17:10:36 It's a little over wordy, frankly. 17:10:53 it an improvement 17:11:28 perfect is the enemy of good 17:11:35 "You MUST not use macros for paths such as %_bindir when specifying BuildRequires:, as these may be changed when building certain types of packages." 17:11:40 let's have it merged and we can work on it later, but we don't have to 17:12:02 (we are dicsussing 2 things at once, right?) 17:12:15 Sometimes it's best to put up something imperfect; that draws corrections from the audience. :) 17:12:29 We are discussing ticket 848 and the associated pull request 847. 17:12:33 https://pagure.io/packaging-committee/pull-request/847#request_diff 17:12:58 (sorry for the confusion 🙉) 17:13:04 I like it. 17:14:07 otaylor: hey, we are talking about 848 17:14:08 Personally I like having one clear sentence rather than specifically a random set of potential problem domains and solutions. 17:14:52 geppetto: Hmm, which is that? 17:16:14 https://pagure.io/packaging-committee/issue/848 17:16:46 Ah, OK 17:17:24 I'm fine with the wording in the PR 17:17:32 * geppetto nods 17:17:32 me too 17:17:50 tibbs: You want to try to tweak it now? 17:18:22 No, if people are happy with it then lets merge it. I can capitalize MUST later. 17:18:28 the only thing that I can think to improve it is to add an example of badness, e.g. BuildRequires: %{_bindir}/sed 17:19:28 last time we discussed it, we seemed to get in a muddle whether this was only talking about paths in BuildRequires, or for actually running executables in the spec 17:19:33 an example would avoid that confusion 17:19:33 You MUST not use macros for paths such as %{_bindi}r when specifying BuildRequires:, as in `+BuildRequires: %{_bindir}/sed+`. These macros may be redefined when building certain types of packages." 17:19:38 but it's not essential 17:19:47 yeah I like that 17:20:00 Sure, +1 to that too 17:20:07 * mhroncok uses that all over the place, but +1 17:20:31 https://src.fedoraproject.org/rpms/redhat-rpm-config/blob/master/f/redhat-rpm-config.spec#_106 17:20:44 Yes, it's used pretty often. 17:20:59 I've never used it 😅 17:21:02 Though personally I've never agreed with the practice. 17:21:30 $ rg 'Requires:\s+%\{_bindir\}' -l | wc -l 17:21:30 We could try to narrow the scope of places where it can't be done, but I think madness lies down that road. 17:21:31 322 17:22:04 Yes, I had given a count when we discussed this a while ago. 17:22:15 Point is, it actually breaks things and is in no way necessary. 17:22:18 I think it's always wrong, but often doesn't matter much. :-) ... I don't think we'll even in the long term be rebuilding more than 10% of the distro for Flatpak inclusion 17:22:54 So then the question arises: If it doesn't matter often, why are we adding a prohibition to the guidelines? 17:23:04 hmm 17:23:11 Or why are we being asked to add one. 17:23:41 tibbs: I'm asking to add it, to make it clear if we request a change from a module maintainer, what is correct 17:23:57 My personal opinion is that this makes sense regardless of flatpaks or SCLs or whatever else might redefine %_bindir, but I can understand that others might disagree. 17:24:10 A number of these things entered the distro when we moved /bin to /usr/bin. 17:24:19 Also, the more people that people do it right, the more things just work 17:24:25 It allowed single specs across the usermove transition. 17:24:35 But now I see no valid reason for it. 17:24:46 (Inertia is not a valid reason....[) 17:24:49 tibbs: how? %{_bindir} was always /usr/bin 17:25:11 Not entirely sure of the history, but that was my recollection. 17:25:25 I could certainly be wrong; usrmove was a while ago. 17:25:39 Some maintainers might even have added it as a placebo. 17:25:58 People randomly add things thinking that they make sense, and often that gets copied randomly all over the place. 17:26:08 that is very true 17:26:15 I think it's mostly there because people fall into the habit of reflexively using the path macros instead of hardcoded paths without thinking about it a lot. 17:26:17 So bottom line is that I'll vote for a prohibition on it simply because I agree with it. 17:26:38 Personally I never use the path macros unless it actually makes things clearer or saves typing. 17:27:44 should we scoll back and count the votes, or revote? 17:28:15 let's make it explicit 17:28:43 +1 17:28:49 +1 17:28:57 +1 17:28:57 Hold on, what are we +1'ing? 17:29:13 the issue with it's PR 17:29:16 The concept, the PR or the sentence I posted? 17:29:26 hah :) 17:29:37 tibbs: the PR and your sentence 17:29:53 I assumed the same 17:30:13 I'm +1 to the concept; I prefer to be concise so prefer what I pasted but I can +1 the language in the PR as well. 17:31:09 redi: limburgher: vote? 17:31:24 let's vote for the concept, and iff it is approved, we can bikeshad about the wording? 17:31:32 +1 to the current PR, I like tibbs's concise statement too 17:31:56 mhroncok: Well we are already +5 on the wording, so meh 17:32:03 either way 17:32:10 mhroncok: if anyone wants to tweak it more they can do another PRs 17:32:19 works for me 17:33:59 =1 17:33:59 #action Clarify the use of path macros with respect to build dependencies PR and tibbs wording (+1:5, 0:0, -1:0) 17:34:00 +1 17:34:06 Sorry, was called away. 17:34:06 #undo 17:34:06 Removing item from minutes: ACTION by geppetto at 17:33:59 : Clarify the use of path macros with respect to build dependencies PR and tibbs wording (+1:5, 0:0, -1:0) 17:34:14 #action Clarify the use of path macros with respect to build dependencies PR and tibbs wording (+1:6, 0:0, -1:0) 17:34:16 no problem 17:34:33 #topic #845 Wiki deprecation status 17:34:38 .fpc 845 17:34:39 geppetto: Issue #845: Wiki deprecation status - packaging-committee - Pagure.io - https://pagure.io/packaging-committee/issue/845 17:35:23 Is there anything to do here? 17:35:30 help :) 17:35:31 This is just an ongoing thing, but if anyone has ten minutes to pick a page and check it over to make sure the formatting came out OK, that would be great. 17:35:39 Otherwise I will mark off pages as I find them. 17:35:40 I wanted to work on the SourceURL page a bit so we could officially move that one too 17:36:08 and I guess we can drop the RPMMacros wiki page as well after my PR is merged 17:36:53 * geppetto nods 17:36:58 yeah, your PR is much better 17:37:13 And we did agree that we should just redirect. 17:37:37 yes 17:37:47 So, for example, https://fedoraproject.org/wiki/Packaging:Scriptlets 17:38:00 Hit it and you don't get to see the wiki at all. 17:38:12 nice 17:38:35 https://fedoraproject.org/w/index.php?title=Packaging:Scriptlets&action=history 17:38:37 If we need to see the history, hit https://fedoraproject.org/wiki/Packaging:Scriptlets?action=history 17:38:45 ah that's what I was going to ask 17:38:47 thanks 17:38:57 history is in git too 17:38:59 But keep in mind that you can't even diff to the current page or it will redirect you. 17:39:09 Sadly history being in git isn't actually useful. 17:39:13 tibbs: the compare selected revisions redirects as well :D 17:39:18 feel free to assign me a few pages to check for formatting, can do it tomorrow. I have to leave now though 17:39:20 so I'm unable to see the change 17:39:33 Because what's in git is post-mangling. 17:39:35 ah, you've just said that 17:39:45 if we vote on 846 I'm +1 17:39:47 You can diff to any revision but the new one. 17:40:18 And you can of course click a date to see the page at that point in time, so it's still useful. 17:40:42 tibbs: do you keept he categoreies? 17:40:52 source shows that you don't 17:40:52 I wasn't planning on doing that. 17:41:14 shall we give it a thought? 17:41:21 Not sure if it's useful, really; I thought we wanted the stuff to basically drop out of the wiki entirely. 17:41:44 tibbs: ok 17:41:47 #topic #846 guidelines/RPMMacros: update for the 21st century 17:41:52 and when i redirecta page 17:41:54 We want to vote on this? 17:42:20 shall i put my name and date somewhere in the asciidoc source, or have we not yet figured that part out? 17:42:45 I think we haven't formalized this yet 17:43:41 I'm using the last-reviewed: 2019-01-01 17:43:54 I don't see a need to put the person who did the review since git blame will show it. 17:44:25 sure 17:44:41 see JavaScript or AppData 17:44:44 for an example 17:45:00 so should I add :last-reviewed: YYYY-MM-DD to my PR too? 17:45:11 So the only reason to include it in the document is if we want to actually substitute it into the document "last reviewed on (date) by (person)". But I don't see much point in that. 17:45:27 decathorpe: You can, or just merge the PR and commit a last-reviewed bit. 17:45:34 right 17:45:55 If you want to see how to do the redirect in the wiki, look at https://fedoraproject.org/wiki/Packaging:Scriptlets?action=edit 17:45:57 still, I think it's useful to have a tag that shows that someone has looked at the *whole* page, not only at the changes they made 17:46:15 Yes, that's what the tag would be intended to say. 17:46:36 Obviously you looked at the changes you are making. 17:46:46 (OK, we hope that you checked the formatting) 17:47:06 I find that Asciidoctor.js Live Preview browser extension to be super useful. 17:47:12 yeah, I did render it locally when I made the changes 17:48:21 I reworked the AppData page quite a bit to use some asciidoc features and I think it looks really nice now. 17:48:37 it does! 17:48:49 Too bad there's no highlighting engine for specfiles. Anyone know javascript and have an evening to spare? 17:50:36 And I've not had luck getting anyone to comment on adding some CSS to make the ToC look... like something. 17:50:43 I like the examplesdir 17:51:29 Yes, it makes the actual source document much more readable. 17:51:50 It's nice you you can just click the "Edit this Page" link to get to the source. 17:53:17 move on? 17:53:46 I added the last-reviewed tag to the PR 17:54:03 wasn't sure if we had anything to vote on here? 17:54:34 no idea, I just want to know if I can merge the PR :) 17:55:40 it doesn't add new policies, so i don't think we need to vote 17:55:45 ok 17:55:46 and geenrally people are happy about it 17:55:54 #topic Open Floor 17:56:04 Ok, we have 5 minutes … anything anyone wants to talk about? 17:56:15 interesting fesco issue: https://pagure.io/fesco/issue/2089 17:56:28 it is about retired packages and re-reviews 17:56:31 Yes, please merge that PR. I thought we accepted the document already. 17:56:40 done 17:56:48 does FPC want to be part of the decision? 17:57:26 seems fine … 2 weeks was a bit agressive 17:57:37 Nothing from me. 17:57:42 * decathorpe shrugs 17:57:45 Hmm, I think re-review is still important and wouldn't want to skip it because there's still a week before the last release that contained an unmaintained package goes EOL. 17:57:47 even 3 months seems kind of short 17:58:13 I guess I just don't see a re-review as that much of a burden. 17:58:25 If the package was in good shape then it should be easy. 17:58:39 If the package wasn't in good shape then.... a review is a good idea. 17:58:43 I just guess the when you accidentally retire a package that is needed 17:58:46 But I agree that two weeks is super short. 17:58:50 being able to put it back ASAP is good 17:59:02 If you accidentally retire a package then even the 2 week rule should have been fine. 17:59:05 and sometimes it takes almost 2 weekes to get a new compose and realize the problem 18:00:03 anyway, this was more of a pointer - we can discuss more in the ticket 18:00:20 * geppetto nods 18:00:34 Ok, going to close … see you next week 18:00:37 #endmeeting