16:08:05 <geppetto> #startmeeting fpc
16:08:05 <zodbot> Meeting started Thu Sep  1 16:08:05 2022 UTC.
16:08:05 <zodbot> This meeting is logged and archived in a public location.
16:08:06 <zodbot> The chair is geppetto. Information about MeetBot at https://fedoraproject.org/wiki/Zodbot#Meeting_Functions.
16:08:06 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:08:06 <zodbot> The meeting name has been set to 'fpc'
16:08:06 <geppetto> #meetingname fpc
16:08:06 <geppetto> #topic Roll Call
16:08:06 <zodbot> The meeting name has been set to 'fpc'
16:08:16 <geppetto> davdunc[m: yeh
16:08:18 <geppetto> #chair GwynCieslasheher
16:08:18 <zodbot> Current chairs: GwynCieslasheher geppetto
16:08:20 <geppetto> #chair decathorpe
16:08:20 <zodbot> Current chairs: GwynCieslasheher decathorpe geppetto
16:08:24 <geppetto> #chair tibbs
16:08:24 <zodbot> Current chairs: GwynCieslasheher decathorpe geppetto tibbs
16:08:26 <geppetto> #chair carlwgeorge
16:08:26 <zodbot> Current chairs: GwynCieslasheher carlwgeorge decathorpe geppetto tibbs
16:08:27 <tibbs> We good here?
16:08:27 <gotmax> .hello gotmax23
16:08:28 <zodbot> gotmax: gotmax23 'Maxwell G' <gotmax@e.email>
16:08:29 <carlwgeorge> .hi
16:08:31 <zodbot> carlwgeorge: carlwgeorge 'Carl George' <carl@redhat.com>
16:08:50 <geppetto> Yeh, looks like
16:09:26 <gotmax> I have something
16:12:14 <geppetto> #topic Open Floor
16:12:18 <geppetto> gotmax: go for it
16:12:34 <gotmax> Okay, there's the issue I opened about shell completions, I have a new guidelines draft, and there's something about the forge macros.
16:12:48 <geppetto> issue number?
16:13:04 <gotmax> .fpc 1202
16:13:05 <zodbot> gotmax: Issue #1202: Add revised packaging guidelines for shell completions - packaging-committee - Pagure.io - https://pagure.io/packaging-committee/issue/1202
16:13:14 <gotmax> .fpc 1201
16:13:16 <zodbot> gotmax: An error has occurred and has been logged. Please contact this bot's administrator for more information.
16:13:22 <gotmax> Ah, doesn't work for PRs
16:13:27 <gotmax> #link https://pagure.io/packaging-committee/pull-request/1201
16:13:33 <gotmax> Draft guidelines
16:13:45 <gotmax> #link https://src.fedoraproject.org/rpms/redhat-rpm-config/pull-request/209
16:13:48 <gotmax> Forge macros
16:14:08 <gotmax> I probably shouldn't have done that all at once...
16:14:29 <gotmax> Not sure if anyone has anything to disucss about any of these
16:14:45 <geppetto> 1202 seems pretty simple +1
16:15:29 <carlwgeorge> we should definitely add those completion macros to epel-rpm-macros as well
16:15:36 <gotmax> Yeah, I'd like to do that
16:15:40 <GwynCieslasheher> Agreed.
16:15:46 <gotmax> Currently, we don't have an epel-filesystem, which we'd need
16:15:49 <decathorpe> should we just vote in ticket? I didn't have time to look at this stuff in detail yet.
16:15:50 <GwynCieslasheher> WFM
16:16:16 <gotmax> Or maybe it should be filesystem-epel. wdyt carlwgeorge?
16:17:15 <carlwgeorge> my preference would be adding those dirs to the rhel filesystem package.  seems like a straightforward contribution.
16:17:20 <GwynCieslasheher> def not file-epel-system
16:17:27 * gotmax laughs
16:17:40 <carlwgeorge> if for whatever weird reason it gets denied, we can figure out an epel one off package then
16:17:47 <gotmax> I'm not sure that'll happen anytime soon, and they probably won't take the fish part.
16:18:00 <gotmax> fish isn't part of RHEL, but it's in EPEL
16:18:17 <carlwgeorge> it's just adding a directory, i think they'd be ok with it
16:18:38 <gotmax> Alright, I'll try to get that into c9s first and then go from there.
16:18:43 <geppetto> I think the PR 1201 is good too … are there a lot of packagers of those things, or is it just gotmax and you are documenting your best practices?
16:18:44 <carlwgeorge> there is a push to have rhel maintainers be more supportive of epel things, such as adding -devel packages to crb
16:18:54 <GwynCieslasheher> You never no, even though it'd be a no-op they can be picky about what they want to support.
16:19:03 <GwynCieslasheher> s/no/know/
16:19:52 <carlwgeorge> my guess is they'll say yes for 9, no for 7, and 8 would be a toss up
16:20:02 <gotmax> geppetto: Including me, I think there's like 4 people who package ansible collections
16:20:35 <gotmax> I do most of the collections packaging, but I'd like to document the best practices for me and anyone else who wants to step up.
16:21:02 <gotmax> If you include inactive people who have packaged collections, there's 6
16:21:20 * geppetto nods
16:21:21 <gotmax> carlwgeorge: So how do we want to handle 7 and 8 if they say no
16:22:05 <carlwgeorge> if they say yes to 8/9 and only no on 7, i'm actually ok with just having 7 be different.  it's far from the only macro difference you have to account for if dealing with all three.
16:22:36 <gotmax> I guess
16:22:53 <gotmax> #action gotmax to contribute new shell completions macros to epel-rpm-macros
16:22:58 <carlwgeorge> if they say no to 8, and we think it's worth it to do something like epel-release-filesystem for 8, it would make sense to do it for 7 and 8 together
16:23:14 <gotmax> #action gotmax to contribute filesystem changes to cs8 and cs9
16:23:19 <carlwgeorge> couple of ways it could play out
16:23:21 <gotmax> Not sure if that'll work if I'm not chaired
16:23:38 <gotmax> carlwgeorge: Makes sense
16:23:55 <carlwgeorge> i'm guessing you've seen the gitlab workflow for c9s, but ping me later if you need help with the "workflow" for c8s
16:24:19 <gotmax> #action gotmax to complete the Ansible guidelines and move them out of "draft" state
16:24:42 <gotmax> carlwgeorge: I think it's just filing a BZ and attaching a patch for c8s, no?
16:25:51 <carlwgeorge> yeah that's it.  optionally also doing the pr on git.c.o to make the patch easier to read, but if you only did the git.c.o pr then it's likely the maintainer won't see it so the bz is mandatory.
16:26:42 <gotmax> Once I tried to file a PR for c8s on Gitlab and they said not to do that. Either way, they have to merge it manually, but it seems BZ is the best bet.
16:27:10 <carlwgeorge> the goal is to eventually migrate c8s over to the c9s workflow, but it's a work in progress
16:27:46 <gotmax> Isn't c8s on Gitlab still just a mirror that is synced as opposed to the repository where the maintainers actually work?
16:28:41 <carlwgeorge> not sure, geppetto is more in the loop there than i am
16:29:13 <gotmax> Re shell completions: For the people that said "+1 for MUST," do you think both things should be must or just the part about using the macros?
16:29:25 <geppetto> It's currently a mirror … but is supposed to change to work the same way as c9s "soon"
16:29:45 <gotmax> Ack thanks
16:30:12 <carlwgeorge> both for me
16:30:44 <carlwgeorge> to be clear, MUST use the macros, MUST NOT own the dirs themselves
16:30:44 <gotmax> Okay. In that case, this whole change is contingent on getting the filesystem changes into f35.
16:30:50 <gotmax> Yeah
16:30:56 <carlwgeorge> i really don't see the any scenario for an exception
16:31:37 <gotmax> Well, it doesn't work in EPEL yet
16:31:41 <carlwgeorge> obviously we'd be forgiving of people not migrating over yet, but making it MUST keeps people from saying no when it's brought up for a package
16:31:52 <gotmax> I guess
16:32:26 <carlwgeorge> i'm pretty sure epel guidelines say follow fedora guidelines when possible, this isn't the first time where fedora took on new guidelines that epel couldn't follow (yet)
16:32:34 <tibbs> Working in EPEL is not really a requirement, though new MUST things that won't work on EPEL aren't really nice to that subset of the packager base.
16:33:30 <gotmax> Yeah. I'll get the process started for EPEL, but I don't think that should be a prereq
16:33:30 <carlwgeorge> i can guarantee you that the most epel7 spec files are not anywhere close to complying with current fedora guidelines
16:33:51 <carlwgeorge> let me see if i can find the phrasing of the epel "when possible" provision
16:34:05 <gotmax> I wouldn't go that far. e.g. for python stuff, both the old and new guidelines are still valid
16:34:32 <gotmax> Side note: filesystem is not following the distgit is the cannonical source guideline
16:35:04 <carlwgeorge> https://docs.fedoraproject.org/en-US/epel/epel-packaging/
16:35:51 <carlwgeorge> we can add a note in there that the completion dir macros aren't in whichever rhel yet
16:36:12 <gotmax> #action gotmax to add note about shell completions to https://docs.fedoraproject.org/en-US/epel/epel-packaging/
16:37:38 <carlwgeorge> for now we could add a note that it doesn't apply to any epel branch, then update it based on how the situation changes
16:38:30 <gotmax> For the forge macros, there seems to be consensus to move that from redhat-rpm-config to somewhere else
16:39:05 <gotmax> The redhat-rpm-config maintainers don't want to maintain them, and PRs to them are not getting reviewed or merged
16:39:47 <gotmax> I know there's a bit of... history with them, but we can't completely remove them right now
16:40:16 <gotmax> I could help split them out, but I'm not sure I want to maintain them alone
16:40:25 <gotmax> #link https://src.fedoraproject.org/rpms/redhat-rpm-config/pull-request/209
16:41:17 <carlwgeorge> personally i avoid them because they don't follow the modern ~/^ snapshot guidelines (last i checked)
16:41:58 <tibbs> It's so funny.  Originally I created fedora-rpm-macros to hold those forge macros and things like it, and got so flamed for it that I gave up.
16:42:02 <gotmax> They don't. We can't really change them now, because it would likely cause NVR issues and break a bunch of things.
16:42:38 <gotmax> Also, the nice thing about them is no just define %commit once, and then it puts the information into %distprefix for you
16:42:46 <gotmax> With the new scheme, that wouldn't work
16:43:50 <decathorpe> well there could be new helper macros for the ^/+
16:43:57 <gotmax> s/no/you/
16:43:57 <carlwgeorge> yeah i get why it would be difficult to fix, but overloading the release with that info is bad anyways imo
16:44:03 <decathorpe> * ^/~ scheme
16:44:13 <tibbs> I think the forge macros were an interesting experiment, but now they need to be phased out and replaced with something better.
16:44:35 <gotmax> decathorpe: That would require significant changes which I am not prepared to make
16:44:49 <tibbs> The problem is that the "something better" doesn't exist, and I'm not sure there is any will to create it.
16:44:51 <carlwgeorge> tibbs: 100% agree
16:45:07 <gotmax> We'd need some way to tell it not to add stuff to %distprefix, and then we'd need to implement the new macros
16:45:10 <tibbs> I have no problem with adding the sourcehut stuff; I just have had no time to review the patches.
16:45:31 <gotmax> You could add %global distprefix %{nil} but that's ugly
16:45:49 <tibbs> Modern RPM makes some of the internals a good bit simpler.
16:46:07 <gotmax> tibbs: Would you like to help maintain the new packages ;)?
16:46:13 <gotmax> *package
16:46:34 <tibbs> "like to" and "have the time to" are sadly not the same thing.
16:46:48 <tibbs> As much as I try to bend reality to my will, there are still only 24 hours in a day.
16:46:56 <gotmax> Yeah, the eternal problem: time
16:47:31 <tibbs> I shouldn't even be in this meeting right now.  The beginning of the semester is a really bad time.
16:48:00 <tibbs> But maybe in a couple of weeks I might have thie time to at least brainstorm some things.
16:48:40 <gotmax> That would be good. In the meantime, I'd really like to get the Sourcehut changes merged.
16:49:53 <tibbs> I can't promise anything but I will try to do it maybe over the weekend.
16:50:53 <gotmax> Thank you! No rush.
16:51:31 <geppetto> Ok, anything else?
16:52:25 <gotmax> I'm working on a new RPM generator for bundled(golang(*)) Provides for vendored go packages, but that's not super relevant to the FPC
16:52:44 <gotmax> So, specfiles would no longer need 200 lines of boilerplate
16:52:58 <carlwgeorge> that would be amazing
16:52:59 <gotmax> #link https://pagure.io/go-rpm-macros/pull-request/49
16:53:02 <gotmax> if you're interested
16:53:22 <gotmax> You just mark the vendor/modules.txt file with %license and the generator takes care of the rest
16:53:40 <gotmax> I also plan to backport it to EPEL
16:53:59 <gotmax> You still should inspect the provides with `rpm -qp --provides`, but this should make things a lot easier
16:54:16 <gotmax> Okay, I think that's all from me :)
16:54:38 <geppetto> #endmeeting