fpc
LOGS
17:00:25 <geppetto> #startmeeting fpc
17:00:25 <zodbot> Meeting started Thu Dec  9 17:00:25 2021 UTC.
17:00:25 <zodbot> This meeting is logged and archived in a public location.
17:00:25 <zodbot> The chair is geppetto. Information about MeetBot at https://fedoraproject.org/wiki/Zodbot#Meeting_Functions.
17:00:25 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
17:00:25 <zodbot> The meeting name has been set to 'fpc'
17:00:25 <geppetto> #meetingname fpc
17:00:25 <zodbot> The meeting name has been set to 'fpc'
17:00:25 <geppetto> #topic Roll Call
17:00:32 * GwynCieslasheher here
17:00:34 <tibbs> Hey.
17:00:51 <geppetto> #chair tibbs
17:00:51 <zodbot> Current chairs: geppetto tibbs
17:00:56 <geppetto> #chair GwynCieslasheher
17:00:56 <zodbot> Current chairs: GwynCieslasheher geppetto tibbs
17:01:11 <geppetto> hey
17:02:42 <decathorpe> hello! o/
17:02:56 <decathorpe> (hope the matrix bridge is more stable this time)
17:03:06 <geppetto> #chair decathorpe
17:03:06 <zodbot> Current chairs: GwynCieslasheher decathorpe geppetto tibbs
17:03:28 <geppetto> decathorpe: very likely, but maybe still not enough ;)
17:03:36 <carlwgeorge> .hi
17:03:36 <zodbot> carlwgeorge: carlwgeorge 'Carl George' <carl@redhat.com>
17:03:41 <GwynCieslasheher> We need to recruit someone who's handle is eames
17:03:43 <geppetto> #chair carlwgeorge
17:03:43 <zodbot> Current chairs: GwynCieslasheher carlwgeorge decathorpe geppetto tibbs
17:04:07 <geppetto> GwynCieslasheher: why?
17:04:39 <GwynCieslasheher> It's a kind of chair.
17:04:48 <geppetto> TIL
17:04:58 * geppetto assumed something to do with typos ;)
17:05:15 <GwynCieslasheher> We could go with something better known, like salon or electric
17:05:27 <GwynCieslasheher> geppetto: as so many of the best things do.
17:06:19 <geppetto> electric … I like that
17:06:41 <geppetto> #topic Schedule
17:06:44 <geppetto> #info https://lists.fedoraproject.org/archives/list/packaging@lists.fedoraproject.org/message/T4UW3AJG54LJKSOKQADWC7TL72BHBWBL/
17:07:30 <geppetto> #topic #1132 Mark comments as scriplets for Sources, for automation
17:07:30 <geppetto> .fpc 1132
17:07:31 <geppetto> https://pagure.io/packaging-committee/issue/1132
17:07:32 <zodbot> geppetto: Issue #1132: Mark comments as scriplets for Sources to be used in automation - packaging-committee - Pagure.io - https://pagure.io/packaging-committee/issue/1132
17:07:48 <tibbs> So it seems they are already using comments for automation.
17:08:40 <geppetto> yeh
17:08:46 <tibbs> But I'm not sure what else we can do here.
17:09:02 <GwynCieslasheher> I was confused by the last stanza but I got there in the end.
17:09:58 <GwynCieslasheher> I feel like unless we want to denote a script pattern format, our answer is No.
17:10:01 <geppetto> I think it's 50/50 … they wanted our opinion on the best way to do what they want and also if we could enshine something in policy so they can more easily point people to what to do.
17:10:34 <tibbs> But saying "insert magic comments" doesn't seem like the smart way to do this.
17:10:48 <geppetto> I agree
17:10:51 <tibbs> If they provided a script and a way to configure it, we could suggest that people use it.
17:11:01 <tibbs> If they built something into fedpkg then we could suggest that people use that.
17:11:22 <geppetto> I also don't see the reason to go indirectly through a macro … just have a well known script name.
17:11:41 <GwynCieslasheher> Right?
17:12:25 <tibbs> The script doesn't need to be in the package, so it doesn't really need to be reflected in the spec other than with an explanatory comment above the source: line.
17:13:51 <carlwgeorge> i thought this sort of thing was already covered by the docs but now i can't find it
17:14:28 <tibbs> https://docs.fedoraproject.org/en-US/packaging-guidelines/SourceURL/#when-upstream-uses-prohibited-code is what we have
17:14:59 <tibbs> They are asking for something that automation can use instead of something that's merely an explanation for packagers.
17:15:03 <carlwgeorge> ah i think that is what i remember
17:15:22 <carlwgeorge> i also agree that magic comments are a bad idea
17:16:47 <tibbs> So my proposal was that we simply evolve what we have to specify more precisely how it should be done, so that automation can rely on such things like the name of the script and the arguments it takes.  But there are still details that doesn't cover.
17:17:05 <tibbs> Like how you actually get the upstream tarball.
17:18:27 <geppetto> I assume the script would have arguments … like "./script.sh download" … "./script.sh generate"
17:19:07 <tibbs> I guess that would be up to whoever writes it.
17:19:14 <GwynCieslasheher> Right. It can't be fedpkg/koji. Not net access.
17:19:18 <GwynCieslasheher> s/Not/No/
17:19:23 <GwynCieslasheher> fedpkg local, but that's it.
17:19:36 <GwynCieslasheher> Or mock either obvs
17:19:47 <geppetto> Yeh, I have opinions … but not strong enough that I want to own it and/or be the one that is writing it
17:20:04 <tibbs> This would all happen at the same time as when you normally fetch upstream tarballs.
17:20:42 <geppetto> As long as it's not insane I'm mostly happy to put what they want into policy …
17:20:47 <GwynCieslasheher> Right, pre fedpkg new-sources
17:20:59 <decathorpe> I've written similar scripts in the past, and it's actually pretty easy to make them "self-contained" and not need any CLI arguments
17:21:18 <GwynCieslasheher> Or even just version.
17:21:50 <geppetto> decathorpe: I would suggest it's worth it even if there's only a single argument of "generate" to start with
17:22:03 <decathorpe> (i.e. make upstream download URL a template, and get %version from the .spec file, like here: https://src.fedoraproject.org/rpms/rust-opml/blob/rawhide/f/gen_clean_tarball.sh )
17:22:17 <geppetto> Then if anyone wants to add "verify" or "tests" or "cleanup" or whatever we don't need two scripts
17:24:39 <decathorpe> I'd argue that writing any CLI argument parsing in bash is a crime against humanity and should be avoided, but what do I know
17:26:06 <geppetto> Doing a case "x$1" … should be enough for what I meant
17:26:31 <carlwgeorge> instead of everyone duplicating code in bash scripts, it would be nice if we had a standard non-bash tool to do this, and each packager could just add a small config file to dist-git with instructions on where the upstream tarball was and which files needed to be removed.
17:26:35 <geppetto> but as I said, I'm not writing it … people can mostly do what they want.
17:26:50 <carlwgeorge> that's a free idea for anyone that wants it, i'm not particularly interested in writing it :P
17:27:13 <geppetto> carlwgeorge: I mean I agree in theory … but who are you volunteering to write the generic version?
17:27:56 <tibbs> I figure the person who wanted this would write it or get patches into fedpkg or whatever.
17:28:01 <carlwgeorge> not volunteering anyone of course, just an idea.  maybe one day i'll get motivated to do it myself, or maybe i can talk someone into it.
17:28:29 <carlwgeorge> hmm, i like the idea of integrating it into fedpkg as a subcommand, rather than a separate tool
17:29:58 <geppetto> The problem there is it then needs to get ported to centpkg etc. … but, eh
17:30:41 <geppetto> Anyone want to volunteer to comment again … tibbs?
17:31:31 <tibbs> Honestly I'm not sure what else there is to say.
17:31:35 <geppetto> On the upside I think we all pretty much agree on any of the ways forward
17:31:37 * decathorpe grumbles about having wanted to write automation like this for years but never finding the time to put together all the pieces
17:31:59 <tibbs> "If you give us a script then we'll recommend its use"?
17:32:40 <tibbs> That's pretty much what we said last week.
17:33:15 <geppetto> Yeh, I guess the comment could just be "We dicussed it again, and had a few generic opinions but if you do all the work you are mostly free to do what you want. Feel free to read it"
17:33:23 <geppetto> Except there is no way to read the logs atm.
17:34:17 <carlwgeorge> aren't these logs on https://meetbot.fedoraproject.org/sresults/?group_id=fpc&type=team
17:34:45 <geppetto> They do appear to bo there
17:35:28 <tibbs> I can include a reference.
17:35:34 <geppetto> https://meetbot-raw.fedoraproject.org/fedora-meeting-1/2021-12-02/
17:35:39 <geppetto> Raw also works  again
17:35:45 <geppetto> so that's cool
17:35:57 <geppetto> I'll comment and point to this and last weeks meetings
17:36:06 <geppetto> #topic Open Floor
17:36:37 <carlwgeorge> for general awareness in case anyone missed it, epel9 is now available
17:37:35 <geppetto> 👍
17:38:06 <tibbs> So there is a proposal to pull the C compiler stuff out of redhat-rpm-config.
17:38:38 <tstellar> That was my proposal and I am happy to discuss.
17:38:40 <tibbs> Personally I agree with it but haven't had the time to comment.
17:39:05 <tibbs> It's not really a packaging guidelines thing since in the end I don't believe anything would change.
17:39:20 <tibbs> from a packager perspective, that is.
17:39:30 <tstellar> tibbs: I think the main question is what stuff to move out into this new package.
17:40:06 <tstellar> tibbs: I tried to limit it to just C / C++, but Florian was suggesting moving a few more ELF related things.
17:40:11 <tibbs> Since FPC folks are all technically maintainers of redhat-rpm-config....
17:41:14 <tibbs> Things can move over time, but of course any move requires coordination so it might be a case of just getting it all done at once for simplicity.
17:41:53 <tibbs> I'm not sure I have an opinion other than doing what makes sense to the maintainers of the new package.
17:42:09 <GwynCieslasheher> Same.
17:43:18 <tibbs> All of the macros in question are the kind of things that often require full distro coordination to change anyway.  So what package carries them has less overall importance.
17:44:07 <GwynCieslasheher> Just that it...exists.
17:44:46 <tibbs> And I have no problem with this kind of thing being in the hands of the people who understand it most.  Because I know I'm not qualified to review many of the changes in that area.
17:46:13 <geppetto> Yeh, not sure it's worth a real package but if they'd prefer it … whatever
17:46:31 <geppetto> I'm certainly not touching those macros :)
17:46:56 <tibbs> I wonder if this would subsume that odd case of that one annobin configuration file.
17:47:58 <tstellar> One advantage of a separate package is that if you structure the dependencies right, it could reduce the buildroot size for non-C/C++ builds.
17:48:00 <tibbs> It does of course introduce another package where one error breaks the entire distribution and so does merit some consideration but again, I'd rather that be in the hands of the people who understand it most.
17:49:24 <tibbs> tstellar: I don't see how that's much different than what you could do already; in the end it's going to have a net result of one additional tiny package in the buildroot.
17:50:13 <tstellar> tibbs: e.g. Some of the brp scripts are only necessary for C/C++ code so any dependencies they have aren't needed for other language.
17:51:32 <tibbs> Sure, but limiting those dependencies isn't something that requires splitting the package.
17:52:19 <tibbs> In any case, it is still work that could be done outside of redhat-rpm-config.  History has shown that avoiding the need to mess with that package is usually good.
17:54:23 * geppetto nods
17:54:40 <geppetto> Ok, I'm going to close and give you 5 mins back
17:54:56 <geppetto> Will everyone be around next week?
17:55:03 <geppetto> #endmeeting