16:00:34 <geppetto> #startmeeting fpc
16:00:34 <zodbot> Meeting started Thu Apr  9 16:00:34 2020 UTC.
16:00:34 <zodbot> This meeting is logged and archived in a public location.
16:00:34 <zodbot> The chair is geppetto. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:00:34 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:00:34 <zodbot> The meeting name has been set to 'fpc'
16:00:35 <geppetto> #meetingname fpc
16:00:35 <geppetto> #topic Roll Call
16:00:35 <zodbot> The meeting name has been set to 'fpc'
16:00:45 * limburgher here
16:00:56 <geppetto> #chair limburgher
16:00:56 <zodbot> Current chairs: geppetto limburgher
16:01:33 <decathorpe> .hello2
16:01:34 <zodbot> decathorpe: decathorpe 'Fabio Valentini' <decathorpe@gmail.com>
16:02:42 <geppetto> #chair decathorpe
16:02:42 <zodbot> Current chairs: decathorpe geppetto limburgher
16:03:00 <geppetto> mhroncok said he'd be a few minutes late
16:03:49 <tibbs> Hey, folks.
16:04:30 <geppetto> #chair tibbs
16:04:30 <zodbot> Current chairs: decathorpe geppetto limburgher tibbs
16:04:51 <tibbs> I'm happy I remembered what day it is.
16:06:01 <geppetto> You have a 1 in 7 chance ;)
16:06:01 <decathorpe> for some reason, this week I thought Tuesday was Thursday and yesterday was Friday, so ... yeah
16:06:50 * geppetto nods … I've worked from home for years, and it's just as bad here … not going out anywhere means there's nothing to sync by
16:07:10 <limburgher> Same, I'm always WFH but without the kids in school . . . yow.
16:07:34 <mhroncok> hey
16:07:37 <mhroncok> sorry
16:07:54 <geppetto> #chair mhroncok
16:07:54 <zodbot> Current chairs: decathorpe geppetto limburgher mhroncok tibbs
16:09:29 <geppetto> #topic Schedule
16:09:32 <geppetto> #link https://lists.fedoraproject.org/archives/list/packaging@lists.fedoraproject.org/message/UXFS7NJVASB2U652VBSEOEQJPCFFX7V3/
16:09:33 <tibbs> The thing that gets me the most is that I thought I'd have more time.
16:09:58 <limburgher> Me too. Sort of hilarious in retrospect.
16:10:05 <decathorpe> yeah ... more time != more energy
16:10:33 <geppetto> Let's try that again …
16:10:36 <geppetto> #link https://lists.fedoraproject.org/archives/list/packaging@lists.fedoraproject.org/message/FH72T5N2ZKVCZV3JPU4CVIXVKFKONQ5Z/
16:10:59 <geppetto> #topic #958 Update of the Haskell Packaging Guidelines
16:10:59 <geppetto> .fpc 958
16:11:00 <zodbot> geppetto: Issue #958: Update of the Haskell Packaging Guidelines - packaging-committee - Pagure.io - https://pagure.io/packaging-committee/issue/958
16:11:09 <decathorpe> geppetto: I wouldn't have noticed ;)
16:11:40 <geppetto> This is also: https://pagure.io/packaging-committee/pull-request/952
16:12:04 <tibbs> This all seems reasonable to me.
16:12:32 <decathorpe> I *think* I skimmed the changes and thought they look good, but I can't remember
16:13:28 <tibbs> Major changes are splitting out documentation into subpackages and the sample spec changes associated with that.
16:13:30 <limburgher> It seems sane to me.
16:14:47 * geppetto nods
16:15:00 <tibbs> +1 for merging this.
16:15:09 <geppetto> Sure, +1
16:15:31 <mhroncok> there is a question there
16:16:16 <decathorpe> I think using -devel to resolve ambiguity is fine
16:16:34 <tibbs> So the idea behind the build dependency on the static library is to make it easy to find packages which link statically.
16:16:43 <mhroncok> I say +1 to PR, yes to use -devel
16:16:57 <mhroncok> tibbs: so require both?
16:17:10 <limburgher> Agreed +1
16:18:10 <decathorpe> hrm. requiring both might do the wrong thing, i.e. ghc-yesod-static and ghc-yesod-static-devel and ghc-yesod-devel come from different packages
16:18:46 <tibbs> With the sad state of things today with regards to dynamic linking (many ecosystems not thinking it's a useful thing at all) I don't really know how useful it is to even try to find static linking and assume that it's everywhere all the time.
16:19:03 <decathorpe> tibbs: yeah that's true ...
16:19:23 <decathorpe> but I think saying "BuildRequire the thing that pulls in the correct dependency" is a sane approach
16:20:56 <tibbs> Yes, certainly, but we have a specific requirement in https://docs.fedoraproject.org/en-US/packaging-guidelines/#_statically_linking_executables
16:21:41 <tibbs> Question is whether that applies at all here.
16:22:36 <decathorpe> you mean, if it applies to haskell?
16:22:51 <tibbs> Yes.
16:23:23 <tibbs> The yesod thing is basically a weird side case that could apply basically anywhere.
16:24:21 <tibbs> When we say "make a subpackage (or provide) called %name-foo", there's always a chance that some other piece of software will actually have that name.
16:24:33 <decathorpe> sure .. it's a name clash
16:25:01 <decathorpe> but other than that, I just checked, and haskell static libs actually are *.a files, so the Guideline *should* apply
16:25:04 <tibbs> If I was a particularly annoying software developer, I could produce useful software named "glibc-devel" or something.
16:25:06 <nim> %name clashes a lot
16:25:08 <nim> when it works
16:25:29 <decathorpe> nim: I see what you did there ;)
16:25:50 <mhroncok> in this name clash, I suppose ghc-yesod-devel should not even provide -static to avoid the clash
16:25:56 <nim> decathorpe, yes that was just a friendly poke on my part :)
16:25:58 <mhroncok> and we treat it like a corner case
16:26:24 <decathorpe> mhroncok: I agree. corner case, just do the "right thing", and add a comment to the .spec file
16:27:03 <mhroncok> that's why we could provide/require static(%{name}) instead to avoid the clashes, but that would be a big chnage and aient nobody got time for that
16:27:07 <geppetto> I kind of feel like the ghc-yesod-devel should be ghc-yesod_devel or something
16:27:16 <tibbs> Yes, the point is the name clash; ignoring requirement to have a build dependency on the static subpackage is merely a workaround that works in just this one case and shouldn't be baked into the guidelines.
16:27:55 <decathorpe> or even make it -devel-static ...
16:27:58 <tibbs> geppetto: I assume you mean the ghc-yesod-devel source package.  I also think that ship sailed years ago.
16:28:17 <tibbs> So is there a ghc-yesod-devel-devel binary package there?
16:28:23 <geppetto> tibbs: yeh … but we could unsail it
16:28:36 <decathorpe> why not "^~^devel"
16:28:42 <geppetto> at least tell everyone it was a terrible idea and to just avoid name clashes
16:28:52 <mhroncok> :D
16:29:02 <tibbs> There's ghc-yesod-static-devel
16:29:05 <geppetto> decathorpe: sure, at this point in the pandemic I'll even +1 that
16:29:10 <mhroncok> ghc-yesod-devel is not a component
16:29:15 <mhroncok> ghc-yesod-static is
16:29:32 <mhroncok> so IMHO ghc-yesod-static-devel provides ghc-yesod-static-static
16:29:48 <tibbs> It does.
16:30:03 <decathorpe> well then that's not even a problem?
16:30:11 <mhroncok> decathorpe: it still is
16:30:17 <tibbs> It is if you buildrequire ghc-yesod-static.
16:30:22 <decathorpe> oh right
16:30:26 <mhroncok> you can get either of those
16:30:34 <decathorpe> at least it's not a problem both ways round ...
16:30:40 <tibbs> Because you wanted the -static subpackage of ghc-yesod, not the base package of ghc-yesod-static.
16:30:52 <mhroncok> BuildRequires: (ghc-yesod-static with ghc-yesod-devel)
16:31:05 <mhroncok> ta dah
16:31:14 <tibbs> Not even sure how or why that would work.
16:31:31 <decathorpe> this means: both dependencies have to be satisfied by the same package, right?
16:31:31 <mhroncok> buildrequire a single package that provide both
16:32:20 <mhroncok> not that it would make it any simper to query the depndency on -static if we attempted to do that, like ever
16:32:20 <decathorpe> that does seem to work
16:32:38 <mhroncok> decathorpe: even BRing both works
16:32:58 <decathorpe> >: D
16:32:59 <mhroncok> decathorpe: but is less explciit
16:33:01 <tibbs> Question is whether it works because it's intended to work that way, or if it just happens to work.
16:33:22 <mhroncok> tibbs: (a with b) is designed that way
16:33:58 <mhroncok> +1 to PR
16:35:21 <decathorpe> +1 from me too ...
16:35:22 <mhroncok> "name clashes like this should have been avoided in the first place, but use whatever works for you to workaround the problem, such as BRing ghc-yesod-devel or even (ghc-yesod-static with ghc-yesod-devel) -- but make sure to put a comment near that explaining itL
16:35:26 <mhroncok> it"
16:35:36 <geppetto> Are these new +1's for the change to use "with"?
16:35:48 <limburgher> +1 this one is.
16:35:50 <decathorpe> well only to resolve name clashes
16:36:24 <decathorpe> but I'm +1 to the PR as-is, and +1 to mhroncok's comment.
16:36:37 <tibbs> I don't think the answer to the buildrequires question matters to the PR in question.
16:36:48 <mhroncok> tibbs: it doesn't
16:37:08 <mhroncok> we can also approve the PR and offer personal comments in there
16:37:33 <mhroncok> I don't think we need a rubber stamped reply
16:39:56 <geppetto> #action Update of the Haskell Packaging Guidelines (+1:5, 0:0, -1:0)
16:40:12 <geppetto> If someone wants to click the button on the PR, that'd be cool.
16:40:34 <geppetto> #topic #959 Is it ok to have different version based on %{fedora}?
16:40:40 <geppetto> .fpc 959
16:40:41 <zodbot> geppetto: Issue #959: Clarification needed: It it allowed to have different version based on %{fedora}? - packaging-committee - Pagure.io - https://pagure.io/packaging-committee/issue/959
16:41:27 <geppetto> This seemed like a pretty clear no to me, but decathorpe thought it might be technically allowed
16:41:55 <limburgher> I feel like this is pointless if one uses git branches as intended. I'd say maybe not forbidden but frowned upon.
16:43:01 <mhroncok> honestly, it's very badly not working anyway, since the sources file onyl ocntain the one think in dist git
16:43:09 <mhroncok> *only contains
16:43:14 <mhroncok> *one thing
16:43:25 <limburgher> That too.
16:43:49 <mhroncok> the problem is if the SRPm is created on different version tahn we are building (copr does that for exmple)
16:44:03 <mhroncok> so I'd liek to see it killed with fire
16:44:10 <tibbs> This is one of those questions where if you actually need it badly enough that the broken behavior is OK, then you wouldn't be constrained by a guideline anyway.
16:44:12 <decathorpe> technically, as in "not explicitly forbidden by the text" ... though it should be explicitly forbidden imo
16:44:15 * limburgher hands mhroncok matches
16:45:05 <tibbs> So banning it or not really makes no difference.  It only helps someone who thinks they might want it save the time of figuring out how broken it is.
16:45:05 <mhroncok> %{fedora}, %{rhel}, %{rhl}, %{fc#}, %{el#} must never be used in the Name, Version, or Release fields, directly or indirectly.
16:45:24 <mhroncok> also, I think we should add %{epel}
16:45:38 <mhroncok> and we will soon be adding %{eln}
16:45:52 <mhroncok> so the entire page might get an overhaul?
16:46:05 <geppetto> yeh, on more than one occasion I've downloaded a fedora srpm and mock'd it on a different fedora.
16:47:08 <geppetto> So if it suddenly changed in a weird way that'd be pretty weird/bad.
16:47:17 <tibbs> Isn't there another guideline which says that the contents of the source package can't depend on the version of the distro where it was built?
16:47:40 <geppetto> tibbs: probably only arch?
16:47:41 <mhroncok> tibbs: that is IMHO the sentiment,  but not sure if it is explicitly written
16:47:54 <tibbs> Because that's a batter way to handle this, rather than having a big list of things that are not supposed to influence what goes into the source package.
16:48:04 <mhroncok> indeed
16:48:20 <geppetto> I'm fine with that
16:48:22 <tibbs> We have https://docs.fedoraproject.org/en-US/packaging-guidelines/#_no_arch_specific_sources_or_patches
16:48:56 <mhroncok> yes
16:49:01 <tibbs> But merely extending that to cover versions puts the section in the wrong place.
16:49:11 <geppetto> tibbs: Note that the NVR will change due to _dist … but apart from that, it shouldn't change.
16:49:15 <mhroncok> it's a trap
16:50:00 <geppetto> Again, I'm fine with saying it's all disallowed already and we can hit people with things that do this :)
16:50:16 <decathorpe> mhroncok: I'd extend "must never be used in the Name, Version, or Release fields, directly or indirectly" to "must never be used to *determine* Name, Version, or Release fields, directly or indirectly"
16:50:50 <tibbs> Yes, this is one of those things where you say "the guidelines don't aim to prevent every broken thing someone might do".
16:51:15 <tibbs> Is this a question which comes up more than once a decade?
16:51:32 <decathorpe> tibbs: I hope not :)
16:51:56 <decathorpe> I think it was a question related to ELN?
16:51:57 <mhroncok> I'Ve sen poeple addinch %if version patches
16:52:02 <mhroncok> *seen
16:52:06 <mhroncok> *adding
16:52:09 * mhroncok is tired
16:52:17 <decathorpe> ugh
16:52:34 <mhroncok> so a general rule to never %if Patches and Sources on conditions outside of fthe spec actually makes sense
16:52:44 <mhroncok> extending the arch rule
16:53:05 <decathorpe> yes ... otherwise stuff to build the RPM is either there or missing, depending on environment
16:53:06 <tibbs> Yes.
16:53:34 <tibbs> I actually don't think I have anything to do today, so maybe I can think of some reasonable way to say this.
16:53:35 <mhroncok> and even on in spec things, a general yes or no %if for a source is bad...
16:54:02 <decathorpe> IMO the same should apply to %{version}. it should not depend on things outside the .spec file
16:54:05 <mhroncok> this was clearly a bad idea as well: https://src.fedoraproject.org/rpms/python-pip/pull-request/56#request_diff
16:54:10 <mhroncok> (the state before that PR)
16:54:13 <tibbs> One reason people do conditional patches is because they want to use autosetup.
16:54:52 <tibbs> mhroncok: Well, lines 5 and 7 are bad.  The other conditionals are fine, I think.
16:55:06 <tibbs> Rather, were bad (before the patch).
16:55:16 <mhroncok> tibbs: 15 and 17 were actually bad as well
16:55:38 <mhroncok> tibbs: upstream patches could have not been applied i they amend tests
16:55:52 <mhroncok> that's what happened and why I've fixed it
16:56:00 <tibbs> I don't see why in general, though.  Maybe in that specific case.
16:56:00 <mhroncok> lines 26 and 29 are moot
16:56:18 <mhroncok> tibbs: right, talking about this one
16:56:46 <tibbs> I did have a hack macro which removed a patch from what autosetup.
16:56:54 <tibbs> what autosetup would apply.
16:56:57 <mhroncok> tibbs: do share please
16:57:09 <mhroncok> tibbs: I need it for python specfile
16:57:42 <tibbs> It was rather unpleasant (digging around in RPM internals with lua) and it's been years, but let me see if I can find it and run it by upstream.
16:58:34 <geppetto> That seems … very dark magic
16:59:13 <geppetto> Anyway … it's two minutes before the hour, so …
16:59:17 <tibbs> It's not that bad, really, but the RPM internals were reworked since I wrote it and I have ni idea if there's an easier way now.
17:00:08 <geppetto> #info Nobody likes it, and if it is allowed nobody wants it to be.
17:00:14 <geppetto> #topic Open Floor
17:00:37 <geppetto> Anything else to talk about in the -1 minutes we have left :)
17:00:45 <limburgher> No thank you.
17:00:48 <tachoknight> can  https://pagure.io/packaging-committee/issue/966 be discussed?
17:01:04 <tachoknight> it's super-brief :)
17:01:27 <decathorpe> I already commented, and your last scratch builds look good
17:01:33 <tachoknight> okay
17:01:42 <decathorpe> putting everything into libexec seems a sane solution
17:01:54 <limburgher> I agree.
17:01:55 <tachoknight> thanks; I've been testing and everything really "just works"
17:02:01 <mhroncok> /usr/libexec : Binaries run by other programs (optional)
17:02:07 <mhroncok> /usr/libexec includes internal binaries that are not intended to be executed directly by users or shell scripts. Applications may use a single subdirectory under /usr/libexec.
17:02:09 <tibbs> If it's the most reasonable solution, then great.
17:02:13 <nim> so I’d like FPC to investigate properly https://pagure.io/packaging-committee/issue/968, but since it’s new, probably not something that can be acted on today
17:02:30 <mhroncok> nim: I agree fully with what tibbs said there
17:02:38 <tibbs> At some point reliance on rules only goes so far and you have to be pragmatic.
17:02:46 <decathorpe> mhroncok: I think that applies here, since only swift and swiftc call those binaries.
17:02:59 <mhroncok> decathorpe: yes I think it does apply perfectly
17:03:13 <geppetto> That's a lot of text for something simple :)
17:03:24 <limburgher> Heh, how often does *that* happen?
17:03:26 <geppetto> But if decathorpe thinks it's fine, I'm fine with it at first glance
17:03:55 <decathorpe> I've already looked at this last week, so I had a head start
17:04:02 <nim> and https://pagure.io/packaging-committee/pull-request/951 is a two-line documentation patch which has been waiting for review for quite a long time
17:04:12 <geppetto> Yeh, I read your comment
17:04:13 <tachoknight> I appreciate it; thank you :)
17:04:53 <decathorpe> nim: when I'm not busy building almost 200 updates per week I'll look at your PRs ;)
17:05:12 <tibbs> I've basically been on vacation or in lockdown since the beginning of February.
17:05:18 <nim> decathorpe, thanks, i know everyone is busy
17:05:32 <tibbs> I'm just glad I got back from Puerto Rico before all hell broke loose.
17:05:37 <geppetto> #action 966 request to use /usr/libexec/swift seems fine to everyone
17:05:57 <mhroncok> tachoknight: I've +1ed your ticket
17:06:15 <tachoknight> thanks :)
17:06:17 <mhroncok> nim https://pagure.io/packaging-committee/pull-request/951 is a two-line documentation patch that received some unanswered comments
17:07:04 <nim> mhroncok, which one? I though jens had hanswered those fine ?
17:07:11 <geppetto> nim: Given: https://pagure.io/fork/nim/packaging-committee/c/aa5577c9721b6a496babf3cb5fd13247467f5afe … OI'm just going to merge it
17:07:24 <nim> answered
17:07:32 <geppetto> The text/discussion part made it seem like there was something to discuss
17:08:14 <geppetto> If I'd known it was that simple I'd have clicked earlier.
17:08:40 <nim> geppetto, sorry about this, my i18n friends are not used to answering FPC questions
17:09:06 <nim> geppetto, thanks for the merging, one problem gotten rid of
17:09:11 * geppetto nods
17:09:27 <geppetto> Ok … only 10 minutes late … so we good to end now?
17:09:37 <limburgher> I am.
17:09:41 <decathorpe> please do :)
17:10:04 <geppetto> #endmeeting