16:00:04 <geppetto> #startmeeting fpc
16:00:04 <zodbot> Meeting started Thu Jul 25 16:00:04 2019 UTC.
16:00:04 <zodbot> This meeting is logged and archived in a public location.
16:00:04 <zodbot> The chair is geppetto. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:00:04 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:00:04 <zodbot> The meeting name has been set to 'fpc'
16:00:04 <geppetto> #meetingname fpc
16:00:04 <geppetto> #topic Roll Call
16:00:04 <zodbot> The meeting name has been set to 'fpc'
16:00:11 <tibbs> Hey, folks.
16:00:16 <mhroncok> hey there
16:00:16 <geppetto> #chair tibbs
16:00:16 <zodbot> Current chairs: geppetto tibbs
16:00:17 <decathorpe> hello
16:00:19 * limburgher here
16:00:20 <geppetto> #chair decathorpe
16:00:20 <zodbot> Current chairs: decathorpe geppetto tibbs
16:00:24 <geppetto> #chair limburgher
16:00:24 <zodbot> Current chairs: decathorpe geppetto limburgher tibbs
16:00:28 <geppetto> #chair mhroncok
16:00:28 <zodbot> Current chairs: decathorpe geppetto limburgher mhroncok tibbs
16:00:34 <geppetto> Hey everyone
16:00:52 <decathorpe> just as a heads-up, I'll have to leave a bit early today
16:01:05 <geppetto> ok
16:02:05 <ignatenkobrain> Hi. Do you need me today or I can be missing?
16:02:13 <geppetto> #chair ignatenkobrain
16:02:13 <zodbot> Current chairs: decathorpe geppetto ignatenkobrain limburgher mhroncok tibbs
16:02:24 <geppetto> You turned up, so volunteered yourself ;)
16:02:42 <geppetto> ignatenkobrain: We do have 6, so if you have to leave we'll still have quorum
16:02:48 <tibbs> At leat for a bit.
16:04:54 <geppetto> #topic Schedule
16:04:57 <geppetto> #link https://lists.fedoraproject.org/archives/list/packaging@lists.fedoraproject.org/message/FYPIOCSSQS7FSI6WB4TQOHAIMVRR2J5A/
16:05:06 <geppetto> #topic #907 Which %__foo macros for executables are acceptable?
16:05:09 <geppetto> .fpc 907
16:05:10 <zodbot> geppetto: Issue #907: Which %__foo macros for executables are acceptable? - packaging-committee - Pagure.io - https://pagure.io/packaging-committee/issue/907
16:06:13 <tibbs> So, Panu's answer is useful to us.
16:07:17 <decathorpe> if I understand this correctly, there's almost never a need to use the double-underscored macros for executables, except if you're doing weird thingsß
16:07:19 <decathorpe> ?
16:07:39 <tibbs> Basically, you probably shouldn't be using %__anything unless you're setting it to change some RPM behavior.
16:08:00 <geppetto> Yeh, I'm fine with tibbs cleanup comment
16:08:03 <tibbs> So basically only after %define or %global.
16:08:14 <tibbs> I still need to actually do the random cleanups I mentioned.
16:08:23 * geppetto nods
16:08:33 <limburgher> Same.
16:08:41 <decathorpe> sounds good :thumbsup:
16:08:47 <tibbs> Changes to Perl and Python guidelines would go via PR anyway.
16:08:47 <geppetto> 👍
16:09:14 <tibbs> But I guess in general we should just not have them used in examples and such.
16:09:36 <tibbs> One question I have is under what circumstances the caller's PATH leaks into an RPM build.
16:09:52 <mhroncok> the python case needs a deeper avaluation, as we actually now use ti to redefine python_sitelib etc. based on __python
16:10:18 <tibbs> mhroncok: But that would be a case where you set %__python, right?
16:10:22 <geppetto> tibbs: I know it doesn't in mock/etc. … but I'm not sure if it's been cleaned up in rpmbuild.
16:11:09 <decathorpe> gepetto: using plain rpmbuild does all kinds of weird things, I wouldn't be surprised if it took executables from the user-modified PATH
16:11:25 <mhroncok> tibbs: yes, but do we want to advice "only use %__python if you set it (already the case) + only use %__python3 if you set it (not the case now)?
16:11:26 <decathorpe> typo, sorry
16:12:01 <tibbs> mhroncok: I guess I'd have to know the specific case where it's useful.
16:13:01 <tibbs> And if it is, maybe we could provide something other than a double underscored super internal macro for people to use when they just want to call a python version that might vary between systems.
16:14:04 <mhroncok> probably
16:14:24 <tibbs> Anyway, I'm in the guidelines now so I can work on the trivial cleanups and then we can discuss the python things in the ticket.
16:14:34 <mhroncok> ack
16:14:47 <tibbs> I'm sure there will always be some valid reason to use these things but we really should try to cut down on some of the cargo culting.
16:15:15 <mhroncok> totally agreed
16:15:25 <tibbs> So we can have a general "don't do this" rule and then if a guideline really does intentionally tell someone to "do this" then it can include a line of explanation.
16:16:16 <geppetto> sure, I'm fine with that … where do you want to put it?
16:17:07 <tibbs> I'll think about it and send a PR.
16:17:11 <geppetto> ok
16:17:35 <tibbs> But somewhere under https://docs.fedoraproject.org/en-US/packaging-guidelines/#_macros
16:17:56 <tibbs> And probably reinforced in https://docs.fedoraproject.org/en-US/packaging-guidelines/RPMMacros/
16:18:24 * geppetto nods … sounds good to me
16:18:37 <geppetto> #topic #909 Suggest that linting/measuring-coverage is not for %check
16:18:41 <geppetto> .fpc 909
16:18:43 <zodbot> geppetto: Issue #909: Suggest that linting code and measuring coverage is not %check's business - packaging-committee - Pagure.io - https://pagure.io/packaging-committee/issue/909
16:20:07 <decathorpe> while I agree that Code Coverage and such things should be done upstream, I think if it's easier to let it enabled in the build than to patch things to enable it ... we can probably let it be
16:21:05 <tibbs> I think the issue is dependencies.
16:22:10 <decathorpe> right. for example, I don't think it necessary to create new packages for code coverage tools just to enable this stuff in other packages
16:22:32 <tibbs> My proposal was not to say "you SHOULD disable these things" but give a general set of conditions where you MAY disable checks, and then list linting and coverage checks as explicit examples.
16:22:33 <mhroncok> we seriously fight this over and over again when updating python
16:23:18 <tibbs> I guess my proposal in https://pagure.io/packaging-committee/issue/909#comment-580051 is on the table.
16:23:20 <geppetto> where the linter fails builds?
16:23:20 <mhroncok> I realize that carrying an enormous patch just t get rid of a dependnecy on a coverage tool that is available might be overkill
16:23:28 <geppetto> Ahh, I see
16:23:44 <geppetto> Can you not request upstream make it easier?
16:23:51 <mhroncok> you should
16:24:15 <mhroncok> that was my idea when I proposed this
16:24:20 * geppetto nods
16:24:34 <geppetto> I'm happy for people to ignore this if it's annoying/hard.
16:24:42 <mhroncok> what tibbs proposed is somewhat OK, but I'd still prefer if we explicitly say that %check is not for coverage/linting
16:25:22 <mhroncok> Could we say something like: SHOULD be disabled if possible with reasonable effort?
16:25:47 <geppetto> I'm fine with that
16:25:58 <tibbs> I think there are plenty of valid reasons for running those things in %check (as I wrote in the above-linked comment).
16:26:24 <tibbs> I just think there are also good reasons why you might want to do, and so I think it's reasonable to be permissive here.
16:26:45 <limburgher> mhroncok, I like it.
16:26:53 <tibbs> If running those tools is causing some kind of problem (dependency bloat, circular dependencies, long build times, etc) then sure, disable them.
16:27:20 <tibbs> But I don't see the benefit in telling everyone to do extra work to disable them.
16:27:52 <tibbs> Is there some conflict among the python developers which would be resolved by the packaging guidelines suggesting one way or the other?
16:28:03 <mhroncok> not a conflict
16:28:24 <mhroncok> particularly the motivation is that if there is no guideline, peeople keep adding those things forever
16:28:50 <mhroncok> and we need to go and ask packager by packager: could you please get this out? it causing trouble and brings no benefit
16:29:09 <mhroncok> while having it as a guideline might eventually (haha) make it an automatic thing
16:29:26 <mhroncok> however I can live with tibbs'es proposal for now
16:29:55 <tibbs> My point is that if it causes problems then that should be sufficient reason for someone to disable it, as long as the guidelines allow it to be disabled.
16:30:14 <mhroncok> ok
16:30:17 <tibbs> Right now you could read the guidelines as telling people that they should enable every single thing that the package will test.
16:30:21 <mhroncok> that makes sense
16:30:38 <mhroncok> I've added my +1 to that in the ticket
16:30:50 <mhroncok> do we want to vote on your proposal here?
16:31:07 <tibbs> Well you can assume my +1, and ignatenko was +1 in the ticket.
16:32:20 <tibbs> As an aside, is there a reasonable automated way to disable these types of tests for a python package?
16:32:43 <tibbs> There are so many different test suite packages, but even if we could catch the common ones....
16:33:29 <mhroncok> tibbs: unfortunately not, but we are working towards a common way of running the tests: https://github.com/fedora-python/tox-current-env
16:33:52 <limburgher> Voted in ticket.
16:34:02 <mhroncok> once we are there, maybe we can dig deeper, but it can still be buried under layers of configs
16:34:27 <mhroncok> it's usually a sed oneliner, but on a different file
16:34:33 <tibbs> I guess there is for Ruby.  And to be honest, I'd have no problems if a whole language ecosystem decided to disable these things by default.
16:34:48 <mhroncok> (some packages invoke linters explicitly: %check: make lint, or %check pylint */*.py
16:35:39 <tibbs> It would be nice to know if packagers are doing that because they believe there is benefit, or if they believe that they must.
16:37:04 <geppetto> maybe a bit of both
16:38:11 <tibbs> Well if we get one more +1 then I think we can help cut down on the latter.
16:39:03 <decathorpe> you can have my +1 as well, before I need to run
16:39:06 <decathorpe> sorry :)
16:42:14 <geppetto> no problem
16:42:21 <geppetto> Not sure if my +1 was counted either
16:42:39 <tibbs> I didn't see it, sorry.
16:42:47 <geppetto> tibbs: You want to do an #action?
16:43:10 <limburgher> And mine.
16:43:26 <tibbs> Whatever works; I don't usually stand on parliamentary procedure.
16:43:49 <tibbs> I'm more a fan of rough consensus and git revert.
16:44:00 <geppetto> It's fine … I mostly use it so the people in the ticket know what is happening.
16:44:15 <geppetto> #topic Open Floor
16:44:42 <geppetto> Not sure we can do another ticket, so anything to talk about before next week?
16:44:52 <tibbs> I'm working on the Users and Groups thing now.
16:45:03 <decathorpe> good timing for Open Floor. I need to leave, sorry :) see you next week, guys
16:45:38 <tibbs> Somehow the wiki conversion lost all of the admon/note and admon/warning things in that document.
16:45:56 <tibbs> I wonder how many of those were lost in other documents.
16:45:59 <geppetto> Oh, that's weird
16:46:13 <geppetto> Do we have it in the history on the old page?
16:46:28 <tibbs> Yeah, it's all there but was not in the initial conversion to git.
16:46:33 <mhroncok> :(
16:47:08 <tibbs> That document is... not great but I was hoping to avoid having to mess with it until we overhauled the whole user/group creation thing.
16:47:33 <tibbs> Looks like that is stalled out or is a big mess, sadly.
16:47:51 <tibbs> So anyway, I'll fix the document because some important info was lost.
16:48:26 <mhroncok> I have three PRs where I appreciate feedback: https://pagure.io/packaging-committee/pull-request/894 https://pagure.io/packaging-committee/pull-request/903 https://src.fedoraproject.org/rpms/redhat-rpm-config/pull-request/65
16:48:41 <mhroncok> I'd
16:50:15 <mhroncok> fort he Cython one, maybe a complete rewrite :D
16:50:31 <tibbs> I will try to look at them.  Am still so terribly busy.
16:51:54 <mhroncok> thanks
16:52:24 <mhroncok> the verify source new guidelines wasnt taken very well
16:52:35 <geppetto> how come?
16:52:56 <tibbs> The very old pre-dist-git system used to have a way to check tarballs before uploading them.
16:53:01 <mhroncok> my PR tries to make it a bit more usable. no code golf, but no extra long copypasta either
16:53:39 <geppetto> sounds good
16:53:41 <tibbs> Checking before uploading makes sense, but checking as part of the package build process also makes sense.
16:53:51 <mhroncok> I agree that ti makes sense
16:54:16 <tibbs> "belt and suspenders" is one phrase that comes to mind.
16:54:20 <mhroncok> but I also think that %{gpgverify} --keyring='%{SOURCE2}' --signature='%{SOURCE1}' --data='%{SOURCE0}' - is a bit too verbose
16:54:51 <tibbs> Yes, when I was trying to hack this originally I did a lot of work to make it simpler (like automatically determining the first two options).
16:55:33 <tibbs> But I kind of got lost in the process of making it too magical and never ended up producing something that anyone would want to use.
16:58:50 <geppetto> Fair enough
16:58:52 <mhroncok> time to end meeting?
16:58:58 <geppetto> Yeh, I think so
16:59:10 <geppetto> #endmeeting