16:00:09 #startmeeting fpc 16:00:09 Meeting started Thu Jul 27 16:00:09 2023 UTC. 16:00:09 This meeting is logged and archived in a public location. 16:00:09 The chair is geppetto. Information about MeetBot at https://fedoraproject.org/wiki/Zodbot#Meeting_Functions. 16:00:09 Useful Commands: #action #agreed #halp #info #idea #link #topic. 16:00:09 The meeting name has been set to 'fpc' 16:00:09 #meetingname fpc 16:00:09 The meeting name has been set to 'fpc' 16:00:09 #topic Roll Call 16:00:22 .hi 16:00:23 decathorpe: Something blew up, please try again 16:00:26 decathorpe: An error has occurred and has been logged. Please contact this bot's administrator for more information. 16:00:27 .hello ngompa 16:00:33 Eighth_Doctor: Something blew up, please try again 16:00:36 Eighth_Doctor: An error has occurred and has been logged. Please contact this bot's administrator for more information. 16:00:43 lol 16:00:44 oh no 16:00:52 oh dear 16:00:54 Need to regenerate 16:00:59 #chair decathorpe 16:00:59 Current chairs: decathorpe geppetto 16:01:04 #chair Eighth_Doctor 16:01:04 Current chairs: Eighth_Doctor decathorpe geppetto 16:01:33 #chair Son_Goku 16:01:33 Current chairs: Eighth_Doctor Son_Goku decathorpe geppetto 16:01:40 I have a feeling we're in for a bad time 16:01:56 zodbot asleep at the wheel 16:03:22 or whatever the correct English idiom is for that 16:03:42 that's pretty much the the correct idiom 16:05:01 good to know 16:05:08 #unchair Eighth_Doctor 16:05:08 Current chairs: Son_Goku decathorpe geppetto 16:05:29 ehh, my other self is there, I just don't feel like dealing with the desync issues right now 16:05:42 and with zodbot slightly on fire, ehhh 16:05:56 probably doesn't matter much with only the three of us 16:06:01 I'm particularly cursed in this room 16:06:13 there are sync issues that only I experience in f-m-1 16:07:04 weird 16:07:22 Technology is too magic 16:08:01 .hi 16:08:02 decathorpe: decathorpe 'Fabio Valentini' 16:08:16 looks like nirik fixed it in fm3 16:10:11 * nirik nods 16:10:45 #topic Open Floor 16:11:16 Well, there's still only 3 of us (Son_Goku doesn't count twice ;) 16:11:23 Anyone have anything to talk about? 16:11:34 .hello ngompa 16:11:35 Son_Goku: ngompa 'Neal Gompa' 16:11:46 I think we can just close 1279 16:11:46 .hello ngompa 16:11:47 Eighth_Doctor: ngompa 'Neal Gompa' 16:11:50 nah, I got nothing 16:11:50 .fpc 1279 16:11:51 geppetto: Issue #1279: Packaging repo files to external repositories? - packaging-committee - Pagure.io - https://pagure.io/packaging-committee/issue/1279 16:12:06 oh this :/ 16:12:12 I really don't know if we want to do this 16:12:27 I'd rather have FESCo weigh in on this 16:12:32 than make guidelines yet 16:13:15 yeah, this also gets into uncomfortable territory about third party sources 16:13:33 it's not technically against the rules to package repo files, but ... I feel like it's against the spirit of the third party sources guidelines 16:13:42 Yeh, I didn't think it was allowed … but tibbs seemed to think it was fine as long as they are disabled. 16:14:00 yes, it would be good to clarify that 16:14:05 I thought distro policy allowed. 16:14:09 Sorry for being late. 16:14:13 #chair tibbs 16:14:13 Current chairs: Son_Goku decathorpe geppetto tibbs 16:14:39 technically, I think so. 16:14:39 but I think it's complicated 16:16:45 I don't know, the policy seems pretty clear. 16:16:49 https://docs.fedoraproject.org/en-US/fesco/Third_Party_Repository_Policy/ 16:17:55 The only fesco involvement is for repositories which are enabled by default. 16:18:18 I think the main concern I have is that the Intel repositories could break Fedora 16:18:30 Or am I misunderstanding? This all goes way beyond packaging committee stuff. 16:18:38 we've generally tried to avoid shipping repo files that contain content that could lead to system breakage 16:18:58 at least with Workstation that's been the case 16:19:17 It's really just so easy to add external repositories that I don't see all that much benefit from packaging them, but.... 16:20:02 tibbs: I think the big thing is the first key requirement 16:20:15 Workstation has generally had two requirements: 16:20:17 I think that our involvement shouldn't be much more than maybe adding a pointer to this policy. 16:20:19 1. AppStream repodata 16:20:29 2. Not obviously potentially break the distro 16:20:59 yes, the policy is pretty clear that you need FESCo approval to ship something as enabled - but shipping something as diabled doesn't really provide anything on top of copying the repo file into /etc/yum.repos.d manually 16:21:19 Right 16:21:32 some historical tickets for Workstation: 16:21:37 #link https://pagure.io/fedora-workstation/issue/291 16:21:46 #link https://pagure.io/fedora-workstation/issue/283 16:21:56 #link https://pagure.io/fedora-workstation/issue/356 16:22:00 But I honestly don't think we have much to say here. It's just that someone wants to package something, so the question is going to come to us. 16:22:05 Again, the first key requirement is that anything on the hosted repo (even if disabled) not break any of the legal requirements for Fedora packages. 16:22:14 right 16:22:24 We could maybe help with that by pointing to the policy somewhere, but none of the other questions seem to be ours to answer. 16:23:02 * geppetto nods 16:23:27 Heck, I would have added Slack's yum repo to fedora if it made sense and worked in a discoverable fashion 16:23:47 I think the distro policy is pretty clear here, and it's also clear that questions about that policy should go to FESCo. 16:23:50 https://docs.fedoraproject.org/en-US/fesco/Third_Party_Repository_Policy/#_key_requirements_for_third_party_repositories 16:24:14 these "key requirements" apply whether the repo is shipped enabled or not, so I really think FPC has not much to add here 16:24:25 So the remaining question, I guess, is whether we need to add something to the guidelines, and if so, what. 16:24:32 yeah, and it's probably worth asking FESCo to add some technical color 16:24:48 because it seems Workstation's rules are "unwritten", which is probably bad 16:25:11 "put files into the only place where they work" 16:25:17 but then ... I think that's usually implied 16:26:26 the "we need appdata for the repositories" seem to be https://docs.fedoraproject.org/en-US/fesco/Third_Party_Repository_Policy/#_software_labeling_and_metadata 16:26:33 (though the wording is unnecessarily obtuse IMO) 16:27:01 I think it's worth asking for it to be made clearer 16:28:15 I guess anyone is welcome to do that. 16:28:34 either way, shipping third party repositories already does require WG or FESCo approval, whether enabled by default or not 16:28:41 so I don't think we need to say anything as FPC here 16:28:56 👍 16:29:00 we can at least punt it to FESCo :) 16:29:13 some of the questions we've discussed in here belong there anyway 16:29:26 .fpc 1276 16:29:29 geppetto: Issue #1276: Should /sbin/ldconfig be /usr/sbin/ldconfig? - packaging-committee - Pagure.io - https://pagure.io/packaging-committee/issue/1276 16:29:30 This one annoys me 16:30:06 I have sort of lost track of just what the new dnf is going to break. 16:30:14 DNF5 annoys me to be honest, but that's a separate topic 16:30:31 But given the recent announcement that it's being put off until f40 or f41, there's certainly no urgency. 16:30:53 I don't understand what's going to break anymore 16:31:00 Really the question is whether we need to react to https://bugzilla.redhat.com/show_bug.cgi?id=2180842 in any way. 16:31:02 Makybe they'll fix it given the extra time 16:31:45 The fundamental issue was that they were going to stop downloading the whole file lists and break file dependencies outside of three directories. 16:32:14 Months ago I said that this kind of breakage really needs to go through the change process, but I was ignored. 16:32:24 Do the guidelines now say no package can make a file requirement? 16:32:47 nope 16:32:48 Well presumably a guidelines change would be part of the change process that they weren't going to do. 16:33:06 We discourage certain file dependencies but do not ban them. 16:33:12 And the list of directories seems to be different. 16:33:47 Oh, no, it's not. 16:33:51 https://docs.fedoraproject.org/en-US/packaging-guidelines/#_file_and_directory_dependencies 16:34:09 We say "SHOULD NOT They also MAY depend on paths listed in an explicit Provides:. They SHOULD NOT include dependencies on other paths as that requires additional repository metadata to be downloaded." 16:34:58 I pasted an extra two words at the beginning there, oops. 16:35:29 Anyway, we're fairly in sync except that we would have to change "SHOULD NOT" to "MUST" because otherwise the dependencies would simply not work. 16:36:02 Yeh, so not sure what to say "Please don't break the package installer to not follow the guidelines, or make a change request" is tempting, but will probably cause minor fires 16:36:28 I still think DNF5 should fix this - they originally planned to download file lists on demand, but that's apparently on the back burner 16:37:05 Given the delay, they will have more time to get to back burner things. 16:37:16 Yeh 16:37:21 I hope so 16:37:41 I think the only remaining question is whether there is an issue with using /bin/ldconfig in our examples. 16:38:10 there should not be 16:38:12 Someone says that it's confusing because it creates dependencies on /bin/ldconfig which contradicts this guideline. 16:38:27 do we even have a /bin/ldconfig? 16:38:32 I thought we only have /sbin/ldconfig 16:38:35 I'd vote no atm. … that's like /bin/sh … it should still be used even if it's not quite true. 16:38:44 Sorry, of course I mean /sbin/ldconfig. 16:39:09 I'm with geppetto on this one 16:39:11 I thought there was an explicit provides for it anyway. 16:39:20 Since glibc added an explicit Provides: /sbin/ldconfig, I think the issue went away and only the confusion remains. 16:39:33 * geppetto nods 16:39:40 It originally didn't have one and that's why so many packages were set to be broken. 16:39:47 I guess just close it and hope everything gets better 16:39:52 yeah 16:39:55 this is a non-issue 16:40:14 Only one of the packages that would be broken has yet to be fixed. 16:40:23 https://bugzilla.redhat.com/show_bug.cgi?id=1731700 if anyone cares. 16:40:39 Okay, I closed it. 16:40:46 +1 for closing 16:40:54 Yeah, I think we're good. 16:40:55 Anything else, or do you want 20ish minutes back 16:41:21 I was trying to clean some stuff up last night. 16:41:31 tibbs++ 16:41:31 geppetto: Karma for tibbs changed to 2 (for the release cycle f38): https://badges.fedoraproject.org/tags/cookie/any 16:41:39 tibbs++ 16:41:42 Son_Goku: Karma for tibbs changed to 3 (for the release cycle f38): https://badges.fedoraproject.org/tags/cookie/any 16:41:54 We really do have too many open issues. 16:42:13 Now pagure is being super slow.... 16:43:01 There's certainly nothing urgent. When pagure comes back I will just go through a few more tickets and PRs and see if I can clean anything up. 16:43:24 apparently there's intermittent network issues somewhere in the sphere (radius to be determined) around the pagure datacenter 16:44:16 Ah, well, not a big deal. Anything I was working on is by definition not urgent anyway. 16:44:26 * geppetto gives some karma to the network engineer that's trying to fix that. 16:44:50 Ok, enjoy the rest of your day 16:45:04 #endmeeting