16:00:33 <geppetto> #startmeeting fpc
16:00:33 <zodbot> Meeting started Thu May 28 16:00:33 2020 UTC.
16:00:33 <zodbot> This meeting is logged and archived in a public location.
16:00:33 <zodbot> The chair is geppetto. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:00:33 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:00:33 <zodbot> The meeting name has been set to 'fpc'
16:00:33 <geppetto> #meetingname fpc
16:00:33 <geppetto> #topic Roll Call
16:00:33 <zodbot> The meeting name has been set to 'fpc'
16:00:41 * limburgher here
16:00:45 <tibbs> Hey, folks.
16:00:49 <ignatenkobrain> .hello2
16:00:50 <zodbot> ignatenkobrain: ignatenkobrain 'Igor Raits' <igor.raits@gmail.com>
16:02:28 <geppetto> #chair tibbs
16:02:29 <zodbot> Current chairs: geppetto tibbs
16:02:31 <geppetto> #chair ignatenkobrain
16:02:31 <zodbot> Current chairs: geppetto ignatenkobrain tibbs
16:02:35 <geppetto> #chair limburgher
16:02:35 <zodbot> Current chairs: geppetto ignatenkobrain limburgher tibbs
16:03:01 <geppetto> mhroncok said he can't make it
16:03:17 <decathorpe> hello o/
16:03:26 <geppetto> #chair decathorpe
16:03:26 <zodbot> Current chairs: decathorpe geppetto ignatenkobrain limburgher tibbs
16:03:31 <mhroncok> I am around in case you miss one vote or something, but thaat's it... sorry
16:03:40 <geppetto> mhroncok: No problem
16:03:45 <geppetto> No new tickets
16:05:22 <geppetto> #topic Schedule
16:05:24 <geppetto> https://lists.fedoraproject.org/archives/list/packaging@lists.fedoraproject.org/message/4XPZQR3K6MRP2SENELXHEASNCBBIPPSO/
16:05:46 <geppetto> Saying that I would like to talk a little bit about https://pagure.io/packaging-committee/issue/982#comment-653814
16:06:15 <geppetto> #topic 982 Fonts packaging stopped working etc.
16:06:22 <geppetto> .fpc 982
16:06:24 <zodbot> geppetto: Issue #982: Font packaging stopped working in rawhide/F33 - packaging-committee - Pagure.io - https://pagure.io/packaging-committee/issue/982
16:07:22 <geppetto> So AIUI nim did the reproducer, with an srpm that was affected by the recent rpm change … but then what happened?
16:07:38 <tibbs> This is all such a mess.  And to be fair, it was bound to happen eventually.
16:08:38 <tibbs> I don't think anything can move forward until the PR for redhat-rpm-config is merged.  (Or definitively closed without being merged, so that the process can start over).
16:08:42 <decathorpe> as far as I can tell, the whole problem was a bit self-inflicted on his part. just not using %{name} macro in Patch tags should resolve the whole thing
16:09:01 <tibbs> decathorpe: Well, I'm of two minds about that.
16:09:11 <geppetto> decathorpe: But those are auto generated for 100s of packages, no?
16:09:21 <geppetto> Or 1,000s even.
16:09:49 <geppetto> And it worked for a long time
16:09:53 <tibbs> Given how RPM isn't really "specified" cleanly, all you can do is use what works and hope it keeps working.  In this case, it got a bit into a grey area and some internal RPM rework broke things.
16:10:08 <decathorpe> the Patch lines? I don't think so many font packages need patches, and the ones that do have them were touched manually anyway
16:11:22 <ignatenkobrain> geppetto: did you see my comment there?
16:11:46 <geppetto> tibbs: I mean, again, that feels like a fine answer if one or two packages are using some obscure feature .. but if thousands of font packages break when you "rework" something you can't just shrug.
16:12:21 <geppetto> ignatenkobrain: Which one ?:). I tried to read al the comments since last week, but I haven't directly tested anything
16:12:24 <decathorpe> geppetto: https://koschei.fedoraproject.org/search?q=fonts shows zero broken fonts packages right now
16:12:26 <tibbs> Right, hence the situation you're in.
16:12:30 <ignatenkobrain> it breaks only if you use %{name} in %{_sourcedir} combined together with using Sources / Patches before the Name definition.
16:12:35 <ignatenkobrain> this is rare and basically unsupported case
16:12:43 <geppetto> decathorpe: Right, but AIUI you can't patch most of them.
16:12:51 <ignatenkobrain> geppetto: this one: https://pagure.io/packaging-committee/issue/982#comment-653941
16:13:05 <decathorpe> you can patch all of them, except if you insist on using %{name} macro in the file name.
16:13:32 <ignatenkobrain> I have PR in upstream to improve this situation a bit here: https://github.com/rpm-software-management/rpm/pull/1235
16:13:46 <geppetto> ignatenkobrain: Does that fix it to work as it did before?
16:14:19 <geppetto> ignatenkobrain: So in your comment you say: this does not qualify as "breaking 1750 packages".
16:14:52 <geppetto> But AIUI they all can't be updated using the "normal" patch process that's worked for years, right?
16:15:49 <geppetto> I understand Panu didn't realize he broke something … and it's maybe hard to fix? … but what is the resolution? Is someone going to merge nim's patch for redhat-rpm-macros which works around this?
16:15:51 <ignatenkobrain> geppetto: as I said, it only breaks if you have %{name} in the %{_sourcedir}. that is not used in Fedora infra anywhere. neither is default anywhere.
16:16:12 <tibbs> I did look at the redhat-rpm-macros PR.
16:16:21 <ignatenkobrain> and only if you specify Sources/Patches before the actual Name definition.
16:16:27 <geppetto> ignatenkobrain: nim seemed pretty convinced that fonts used it
16:16:48 <ignatenkobrain> geppetto: on his laptop yes, but nowhere else.
16:17:02 <ignatenkobrain> as you can see in koschei, no fonts are broken
16:17:26 <geppetto> ignatenkobrain: But he didn't do anything different to a normal font patch/update … that was just to prove the problem, right? Like we asked him too last week?
16:18:06 <ignatenkobrain> geppetto: to reproduce you need to have a %{name} in %{_sourcedir} with his src.rpm
16:18:11 <geppetto> We know current packages are ok, that's what we wanted to get to last week … and we said we'd look a tthe updating problem if we got there, right?
16:18:20 <ignatenkobrain> so you are intentionally moidifying internal RPM macro
16:18:29 <geppetto> ignatenkobrain: But that's the std. way of patching fonts, right?
16:18:54 <ignatenkobrain> no, that's not related to fonts at all
16:19:03 <ignatenkobrain> this is macro that specifies where sources that are used for rpm are stored
16:19:08 <ignatenkobrain> defaulting to ~/rpmbuild/SOURCES/
16:20:18 <tibbs> In other words, you won't see the existing problem in our build system.
16:20:36 <tibbs> But certain types of local builds will break.
16:20:45 <geppetto> I understand that the macro is generic in some way … but AIUI the std. way fonts get patched is to do the thing that rpm broke?
16:21:21 <geppetto> tibbs: Ok, so the fonts updating process has a local build part that is broken?
16:21:35 <decathorpe> no, and no
16:22:11 <tibbs> I think it's more "the standard way of doing fonts in Fedora now doesn't work with one way of local building which has worked since the beginning of time".
16:23:02 <decathorpe> adding "Patch0: this-is-my.patch" did work and still works. it only breaks *locally* if you use nonstandard _sourcedir definition (including %{name}) or if you use %{name} macro in file name
16:23:29 <geppetto> Ok … so who is doing that local building? ... Is it just nim?
16:23:36 <decathorpe> I guess so.
16:23:49 <tibbs> It's anyone who wanted to just take a Fedora SRPM and build it.
16:24:13 <geppetto> Ok … so it builds in koji but not in mock?
16:24:21 <decathorpe> tibbs: built it outside mock.
16:24:36 <tibbs> Not mock, just bare rpmbuild.
16:24:38 <geppetto> Like if anyone downloads a font srpm and runs mock on it it'll just fail in a weird way?
16:24:46 <geppetto> Ahh
16:24:52 <decathorpe> geppetto: no that still works obviously
16:25:06 <tibbs> I have had %name in %_sourcedir in my local .rpmmacros file for well over a decade.
16:25:07 <decathorpe> only if you have custom ~/.rpmmacros file and run bare rpmbuild things can break
16:25:26 <geppetto> Ok, I see
16:25:29 <tibbs> It's not uncommon to do that, then these days I never use bare rpmbuild anyway.
16:25:30 <geppetto> I think :)
16:25:40 <geppetto> Yeh, dito. both of those things.
16:26:02 <decathorpe> IMO if you have custom nonstandard .rpmmacros all bets are off
16:26:12 <tibbs> So the breakage is if you did a very particular thing which used to be relatively common, but just doesn't get used by many these days.
16:26:16 <geppetto> I guess sometimes I hack something for a one off with rpmbuild … as long as I know it's not going anywhere
16:26:27 <ignatenkobrain> you also need to have Patches / Sources defined BEFORE the Name :)
16:26:34 <ignatenkobrain> otherwise you won't spot this
16:26:43 <geppetto> decathorpe: If that's true then rpmbuild itself shouldn't run outside of mock because almost everyone does it.
16:26:45 <tibbs> And this comes down to a fundamental point: whether or not we care that Fedora packages will build outside of our build infrastructure.
16:27:00 <tibbs> I think we still do.
16:27:15 <ignatenkobrain> tibbs: I think we care that it builds with default RPM configuration
16:27:41 <decathorpe> tibbs: but they do still build unless you do weird things in both the custom configuration and .spec files
16:28:15 <tibbs> Like I said, it used to be a common recommendation that you alter your personal .rpmmacros file to have %_sourcedir and friends containing %name.
16:28:18 <geppetto> Yeh, but significantly less so if it's outside of mock
16:28:44 <geppetto> This would have been much better handled if rpm maintainers just fixed their regression … sigh.
16:29:02 <decathorpe> tibbs: that must've been before I started packaging for fedora, means more than 6 years ago
16:29:04 <geppetto> Yeh, what tibbs said.
16:29:12 <geppetto> decathorpe: We old :)
16:29:19 <tibbs> For me this .rpmmacros file predates the existence of Fedora.
16:29:58 <decathorpe> I only created one a few months ago, and only to make "rpmbuild -bs" behave the same way as "fedpkg srpm" ...
16:30:06 <geppetto> To be fair I don't have one on this machine (see: mostly use only mock now) .. but I definitely did that in the past.
16:30:34 <tibbs> I only have one because I'm using the same homedir that I had started using in 1989.
16:30:58 <tibbs> Man, there's some crap in there.
16:31:06 <geppetto> tibbs: Ok, so what do you think about the PR?
16:31:07 <decathorpe> tibbs: your $HOME is older than both Igor and me :)
16:31:31 <tibbs> The PR actually seems fine to me.
16:32:02 <decathorpe> I'm just not sure that we need even more lua code just to solve this edge case for one packager ...
16:32:12 <geppetto> Are any of the other maintainers unhappy with it?
16:32:26 <tibbs> I mean, you could argue over naming endlessly and I just don't see much point in that, but otherwise, just looking at the change in isolation, it seems like a functional thing.
16:32:47 <geppetto> decathorpe: Given the number of packages, and the fact it's working around an rpm regression I think we should be pretty lenient here.
16:32:53 <ignatenkobrain> geppetto: tibbs I just would like pmatilai to say  "yes, I don't care" or "merge it"
16:32:55 <tibbs> The difficult discussion comes in when you start asking just why it's needed.
16:33:30 <geppetto> I mean … workaround rpm regression edge case when doing local builds with rpmbuild ?
16:33:35 <tibbs> ignatenkobrain: I basically feel the same.  I mean, I could merge it and see if anyone yells; sometimes that's a reasonable way to work.
16:34:19 <geppetto> #action tibbs will merge redhat-rpm-config PR and see if anyone complains
16:34:32 * geppetto whistles innocently
16:34:35 <ignatenkobrain> :D
16:34:37 <decathorpe> I just worry that if we merge it, the fonts macros will use it, and at some point nobody will understand them anymore
16:34:52 <tibbs> But basically all the macro (and underlying lua code) does is spit out the specfile preamble if necessary.
16:34:56 <ignatenkobrain> the worst thing that can happen is that pmatilai can revert it
16:35:00 <geppetto> decathorpe: I think we may have already crossed the bridge where only a few people do
16:35:03 <ignatenkobrain> and then we will break fonts for real
16:35:17 <tibbs> decathorpe: That is one of my concerns, yes.  But I agree that we might be down that hole already.
16:35:33 * decathorpe is sad and grumpy and has a headache
16:35:40 <tibbs> Thing is, there are plenty of things down in RPM that have the same issue.  It's just that they come from RPM upstream.
16:35:58 * geppetto nods
16:36:26 <tibbs> That gets down into the question of whether we have to reserve the deep magic to RPM developers, or if distro folks get to play as well.
16:37:20 <tibbs> And that comes back around full circle: if RPM maintainers break something that's in RPM, then they'll fix it.  Otherwise, the downstream maintainers get to deal with the breakage.
16:37:25 <decathorpe> I'm fine with merging the macros PR ... still I worry about plastering over a one-person edge case with more abstractions
16:37:37 <tibbs> And we've now seen that RPM upstream won't always be sympathetic.
16:37:38 <geppetto> I would probably be against it if it was all new, but given "it worked" a couple of months ago and rpm maintainers aren't going to fix the regression, then I'm heavily on the side of packagers who want it to work again
16:38:10 <ignatenkobrain> geppetto: the problem is that it is not a regression :/
16:38:19 <ignatenkobrain> it is the "feature" that used to work by accident
16:38:21 <tibbs> It's difficult to be told "you shouldn't have been doing that" about something that worked for years.
16:38:26 <ignatenkobrain> it is like UB
16:38:45 <decathorpe> geppetto: also, "it worked" last on fedora 30
16:38:48 <geppetto> ignatenkobrain: I mean you can call it what you want, but when something goes from working to working then the blame lies first with the thing that changed.
16:39:10 <ignatenkobrain> F30 is EOL now
16:39:52 <decathorpe> I checked, the RPM change that "broke" this undefined behaviour landed in fedora 30 pre-alpha.
16:40:05 <decathorpe> *fedora 31 pre-alpha
16:40:17 <tibbs> Yes, the breakage is sufficiently rare that nobody noticed.
16:40:54 <geppetto> decathorpe: Ok, so that's going to be post el8?
16:41:22 <tibbs> It doesn't mean it's not broken, but it does mean that the comments about how bad this was seem a bit over the top.
16:41:26 <geppetto> It's like a year ago, roughly?
16:42:10 <tibbs> I think the poor communication about just what the breakage was just made the whole mess worse.
16:42:16 * geppetto nods … I understand nim was very emotional over it, but I think that was dread from thinking he'd have to change 1,000s of packages.
16:42:23 * geppetto nods
16:42:48 <tibbs> Note that even if the redhat-rpm-config PR is merged, those packages will still have to change.
16:43:04 <geppetto> Anyway, I added an action item for tibbs … nobody seemed to object, and decathorpe kind of agreed … but if panu goes insane feel free to blame me.
16:43:28 <geppetto> tibbs: Yeh, but AIUI it's a change nim is mentally prepared for.
16:43:30 <ignatenkobrain> #action ignatenkobrain to blame geppetto if redhat-rpm-config maintainers will not be happy with tibbs merge
16:43:40 <geppetto> ignatenkobrain: 👍
16:43:42 <tibbs> In general I don't have problems adding something which is isolated and has a potential for helping out this situation.
16:44:15 <decathorpe> well right now it has the potential to break hundreds of packages that use fonts macros :)
16:44:55 <geppetto> ¯\_(ツ)_/¯
16:44:57 <decathorpe> anyhoo, I enabled koschei for all fonts packages, so at least we should see pretty quickly what happens
16:45:01 <tibbs> I get what you're saying, but it would only have the potential to break something if something else starts using it.
16:45:06 <geppetto> decathorpe: cool
16:45:27 <geppetto> decathorpe++
16:45:59 <tibbs> In this case, the fonts macros package would start using %new_package, and then we'll see.  But then the breakage would still be limited to breaking things that use the font macros.  It's not as if glibc or the kernel would start failing because of this.
16:46:19 * geppetto nods
16:46:39 <geppetto> Ok, we'll see what the fallout from this is next week.
16:46:45 <geppetto> #topic #977 Get new members?
16:46:48 <geppetto> .fpc 977
16:46:49 <zodbot> geppetto: Issue #977: Get new members? - packaging-committee - Pagure.io - https://pagure.io/packaging-committee/issue/977
16:47:18 <decathorpe> were there any volunteers?
16:47:29 <geppetto> So as I updated … the email got sent out, as the world is insane atm. I put a long time limit on it
16:48:15 <geppetto> We've got one response so far
16:48:33 <tibbs> Yes, we shouldn't be in a hurry here.
16:48:56 <ignatenkobrain> geppetto: from nim I hope? :)
16:49:13 <geppetto> No, let me try to find it
16:49:21 <ignatenkobrain> geppetto: the limit is -2 years so it is infinite? :)
16:50:17 <geppetto> It's from Yann COLLETTE: https://copr.fedorainfracloud.org/coprs/ycollet/linuxmao/
16:50:38 <geppetto> Note that we've not talked about people applying in public before
16:51:23 <geppetto> So might want to start an email thread, but I was going to do that more towards the end
16:51:43 <decathorpe> geppetto: good idea
16:51:48 <geppetto> Anyway … it's moving along, hopefully more people apply … if only because we need more than one person :)
16:52:22 <ignatenkobrain> I think I've never interacted with Yann before 🙂 but let's see
16:52:41 * geppetto nods
16:52:46 <geppetto> #topic Open Floor
16:53:01 <geppetto> Anything else in the last few minutes?
16:53:31 <tibbs> I thought we would have several takers, honestly.  But these times are weird and so probably we just need to wait a bit.
16:54:03 <geppetto> Yeh
16:55:57 <geppetto> #endmeeting