15:00:04 <contyk> #startmeeting FESCO (2020-02-24)
15:00:04 <zodbot> Meeting started Mon Feb 24 15:00:04 2020 UTC.
15:00:04 <zodbot> This meeting is logged and archived in a public location.
15:00:04 <zodbot> The chair is contyk. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:00:04 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
15:00:04 <zodbot> The meeting name has been set to 'fesco_(2020-02-24)'
15:00:06 <contyk> #meetingname fesco
15:00:06 <zodbot> The meeting name has been set to 'fesco'
15:00:08 <contyk> #chair nirik, ignatenkobrain, decathorpe, zbyszek, bookwar, sgallagh, contyk, mhroncok, dcantrell
15:00:08 <zodbot> Current chairs: bookwar contyk dcantrell decathorpe ignatenkobrain mhroncok nirik sgallagh zbyszek
15:00:10 <contyk> #topic init process
15:00:17 <contyk> .hello psabata
15:00:18 <zodbot> contyk: psabata 'Petr Šabata' <psabata@redhat.com>
15:00:19 <decathorpe> .hello2
15:00:21 <zodbot> decathorpe: decathorpe 'Fabio Valentini' <decathorpe@gmail.com>
15:00:22 <mhroncok> o/
15:00:25 <dcantrell> .hello dcantrel
15:00:25 <nirik> morning
15:00:25 <zodbot> dcantrell: dcantrel 'David Cantrell' <dcantrell@redhat.com>
15:00:33 <sgallagh> .hello2
15:00:38 <zodbot> sgallagh: sgallagh 'Stephen Gallagher' <sgallagh@redhat.com>
15:01:13 <contyk> Yay, quorum.
15:01:29 <contyk> So let's begin with the followups.
15:01:53 <contyk> #topic #2341 maven and ant: sfl4j-jdk14 filtered (ticket includes proposal to ban default modular streams)
15:01:58 <contyk> .fesco 2341
15:02:02 <zodbot> contyk: Issue #2341: maven and ant: sfl4j-jdk14 filtered (ticket includes proposal to ban default modular streams) - fesco - Pagure.io - https://pagure.io/fesco/issue/2341
15:03:32 <nirik> so, I guess there's a proposal here to drop default modules...
15:03:42 <nirik> https://pagure.io/fesco/issue/2341#comment-627466
15:03:44 <dcantrell> I believe that's what we've narrowed it down to
15:03:45 * sgallagh is internalizing the arguments. Please hold.
15:04:31 <contyk> So it's pretty similar to status quo, where it's all banned unless you get an exception.
15:04:32 <decathorpe> cipherboy would also be available to talk about this for about the next 20 minutes or so.
15:05:05 <mhroncok> contyk: except it also include exisitng defaults
15:05:09 <decathorpe> contyk: did maven and ant ever go through that process, or do those modules predate this policy?
15:05:22 <nirik> they predate the policy
15:05:42 <decathorpe> that explains a lot.
15:05:52 <mhroncok> contyk: and even with fesco exception, the default eclipse stream broke things horribly
15:06:24 <sgallagh> mhroncok: That was mostly because we didn't know where all the sharp edges were yet, but I agree it was a disaster
15:06:30 <mhroncok> this leaves no imlicit room for exceptions (of course, fesco can do exceptions for anything, but in this case, it would not be "the process")
15:06:54 <mhroncok> it also narrows down the conflict we had with sgallagh IMHO...
15:07:12 <sgallagh> Which conflict are you referring to?
15:07:19 <mhroncok> ...sgallagh wanted to "ban temporarily" I wanted to "ban forever"
15:07:28 <sgallagh> (Sorry if I'm slow today; just getting back from being blissfully on vacation)
15:07:43 <mhroncok> now this is by definition temporary, but does not build it on "when things are technically matured" but on exisiting policy
15:08:28 <mhroncok> I mean, on having the policy
15:08:39 <sgallagh> mhroncok: So, I think your proposal is the right one if we are considering Fedora exclusively (which, as FESCo, is our primary duty). However...
15:09:01 <mhroncok> there is always a however :(
15:09:24 <sgallagh> I also need to point out that default module streams are a committed feature for RHEL 8, and eliminating them for Fedora means that RHEL loses the ability to try and fix them in this space.
15:09:38 <sgallagh> I'm not saying "no", I just want to make sure we understand the unintended consequences too
15:09:56 <mhroncok> RHEL 8 is done. anything that is borken now will need to be fixed very carefully from within RHEL context
15:10:16 <mhroncok> In Fedora, we should look into future (9, 10), not in the past (8)
15:10:17 <dcantrell> I understand that, but we have an opportunity to fix things for fedora now or leave things broken for fedora because RHEL might something something
15:10:25 <decathorpe> sgallagh: while I understand this argument, this is 1) not affecting fedora and 2) just because this was shipped in RHEL prematurely doesn't mean that it has to be fixed in fedora.
15:10:49 <sgallagh> Again, I'm not saying "no". I'm resigned to the fact that this is probably the sane course forward.
15:10:50 <mhroncok> also, once we have a policy, we might have default modular streams
15:11:07 <sgallagh> But I want it on the record what the downsides are too
15:11:14 <decathorpe> mhroncok: right, but I doubt that this will happen before f34
15:11:35 <contyk> So this "forever" ban would be until 1) we have a mechanism that prevents default streams from shipping packages that override non-modular ones, and b) we have a reliable upgrade mechanism + stream/context migration implemented in software management tooling
15:11:37 <contyk> Correct?
15:11:39 <mhroncok> decathorpe: that's up to the people who want this. they can have it for 33 if they dedicate time and resources
15:11:57 <mhroncok> contyk: not in my vision
15:12:06 <sgallagh> contyk: Presumably also we would have a mechanism for backing out of modules as well, which we are lacking.
15:12:15 <sgallagh> There's a fair bit of work that needs to be done here still.
15:12:29 <decathorpe> right. because right now, there's issues in f31 that can never be fixed by updates.
15:12:39 <mhroncok> we would **also** have a "in Fedora, we modularize this kind of things" document
15:12:58 <sgallagh> I think mhroncok is right that we can't realistically list the minimal state for turning it back on at this timr.
15:13:06 <mhroncok> looping back to https://pagure.io/fesco/issue/2114
15:13:26 <mhroncok> so the proposal dos not list a TODO list for enablement
15:13:33 * sgallagh nods.
15:13:42 <mhroncok> it merely says: a policy must be made that fesco approves
15:13:50 <mhroncok> all the thing we are saying need to be part of that policy
15:13:54 <mhroncok> *things
15:14:10 <mhroncok> or "technically done" and hence the policy can count on them as facts
15:14:46 <sgallagh> This does not preclude the Modularity Team from proposing a set of those requirements for FESCo to consider in the future.
15:14:49 <sgallagh> Right?
15:15:04 <sgallagh> (I don't want to get into a state where the goalposts are constantly moving either)
15:15:13 <mhroncok> right
15:15:18 <bookwar> "we modularize this kind of things" - i don't believe that it is a reasonable goal, but i would agree that we need to resolve the issue with modules which were created before we enabled stricter requirements, and i thing removing current default modules which were made before and start over is a right thing to do
15:15:45 <sgallagh> I've said my piece and I'm prepared to vote +1 on mhroncok's proposal
15:15:52 <mhroncok> bookwar: "we can modularize anything" is also possible... if we agree on that
15:15:57 <mhroncok> sgallagh: thanks
15:16:01 <dcantrell> sgallagh: piece or peace?
15:16:29 <mhroncok> bookwar: the point is, that this will be a long and heated discussion. hence the details are intentionally left out.
15:16:55 <sgallagh> dcantrell: https://www.merriam-webster.com/words-at-play/say-your-piece-versus-peace-usage
15:17:05 <bookwar> mhroncok: i don't think we should, we need people to experiment with the technology, we need to ensure level of reliability, but we shouldn't limit the possibilities, but i agree we can leave it out
15:17:28 <ignatenkobrain> .hello2
15:17:29 <zodbot> ignatenkobrain: ignatenkobrain 'Igor Gnatenko' <i.gnatenko.brain@gmail.com>
15:17:37 <contyk> None of this forbids people from making modules, it's just about the defaults
15:17:54 <contyk> (which is significant, still, of course)
15:18:04 <dcantrell> sgallagh: I assumed former, but that's entirely too much text abouit piece vs. peace  :)
15:18:14 <nirik> so does just dropping defaults resolve our current blockers? (ie, the upgrades one and any others?)
15:18:24 <sgallagh> nirik: It does not
15:18:48 <mhroncok> nirik: combined with the propsoed solution to do `dnf module reset *` on default upgrade mechsnism, it should
15:18:53 <decathorpe> I think existing modules need to be "reset" at upgrade. but FTI issues should be resolved.
15:19:00 <mhroncok> nirik: standalone, it does not
15:19:02 <sgallagh> mhroncok: That's one option, but I think we can do better
15:19:17 <mhroncok> sgallagh: alos, intentionally left out here
15:19:23 <mhroncok> *also
15:19:27 <nirik> ok, fair
15:19:28 <sgallagh> If we're banning default streams outright, we can have fedora-repos include the `module_hotfixes` option on the non-modular repos
15:19:35 <decathorpe> that's a technical problem, not a policy problem.
15:19:43 <sgallagh> So as long as they have higher NVRs than the packages in the module streams, they'll "win"
15:19:57 <contyk> sgallagh: That feels very wrong to me.
15:20:00 <sgallagh> Hold on. That won't work
15:20:11 <sgallagh> Sorry, didn't think that through completely.
15:20:35 <sgallagh> The reset option is still probably best
15:20:42 <contyk> Yes.
15:20:49 <sgallagh> Sorry for the noise
15:21:07 <contyk> Even though that also means people who intentionally chose a stream will be "upgraded" to something else.
15:21:15 <contyk> But that's a price we probably have to pay.
15:21:49 <sgallagh> Release notes and careful messaging about that should be Good Enough (TM)
15:21:57 <decathorpe> do we want to vote on mhroncok's proposal?
15:22:05 <nirik> and at least upgrade time is when people are expecting to deal with that.
15:22:26 <sgallagh> nirik: Yeah, true
15:22:32 <contyk> So the proposal is to completely ban default streams starting with the next release?
15:22:34 <ignatenkobrain> +1 to mhroncok proposal
15:22:35 <mhroncok> contyk: also, there is an alternate upgrade way that should preserve the streams, as noted in th BZ
15:22:43 <mhroncok> contyk: with F32, yes
15:22:44 <ignatenkobrain> (FTR since I voted in the ticket)
15:23:02 <mhroncok> For Fedora 32 and onward, all default modular streams are banned. Existing defaults are removed. Once a comprehensive modular policy for Fedora is created and approved by FESCo, this ban can be lifted. The future policy should allow modularizing, but the primary objective is to make sure that the user experience and nonmodular packaging experience is not significantly worse than before modularity.
15:23:06 <mhroncok> ^ the proposal FTR
15:23:08 <contyk> Okay, +1 all things considered, hoping we can change that in the future.
15:23:10 <sgallagh> +1
15:23:15 <dcantrell> +1
15:23:18 <decathorpe> +1
15:23:20 <nirik> +1
15:23:58 <contyk> bookwar: ?
15:24:07 <bookwar> mhroncok: too much text to vote on )
15:24:09 <mhroncok> zbyszek told me on telegram to vote +1. but he can back that up in the ticket later if needed
15:24:22 <bookwar> +1 for "For Fedora 32 and onward, all default modular streams are banned. Existing defaults are removed."
15:24:36 * contyk nods
15:24:36 <mhroncok> zbyszek is stuck afk
15:25:04 <contyk> I didn't even see zbyszek so I wasn't waiting for him.
15:25:12 <mhroncok> sure, just forwarding the message
15:25:24 <contyk> #agreed For Fedora 32 and onward, all default modular streams are banned. Existing defaults are removed. (+8, 0, -0)
15:25:28 <sgallagh> bookwar: Can we make that "For Fedora 32 and onward, all default modular streams are banned until FESCo decides otherwise. Existing defaults are removed."
15:25:47 <contyk> I think "until FESCo decides otherwise" is always implied :)
15:25:53 <sgallagh> OK, fair
15:25:57 <bookwar> sgallagh: fesco overriding its own decisions is always an option
15:26:14 <contyk> #topic #2339 Proposal to change ARM Release Blocking Criteria - Drop XFCE (32bit), Add Workstation(64bit)
15:26:19 <contyk> .fesco 2339
15:26:21 <zodbot> contyk: Issue #2339: Proposal to change ARM Release Blocking Criteria - Drop XFCE (32bit), Add Workstation(64bit) - fesco - Pagure.io - https://pagure.io/fesco/issue/2339
15:26:28 <sgallagh> I thought this was approved last week?
15:26:30 <contyk> So I think we said there was nothing to do for us.
15:26:46 <contyk> But I saw the ticket was still open and there was some activity so I wanted to check.
15:27:06 <decathorpe> I think the comments don't change our decision, do they?
15:27:09 <nirik> just needs implementing now I think?
15:27:32 <contyk> Agreed.
15:27:45 <bookwar> i am uncomfortable with members of workstation wg calling aarch spin as having "branding" of a workstation, but we already discussed this last time
15:27:52 <contyk> #info No change in last week's FESCo decision, the ticket can be closed.
15:28:11 <contyk> #topic #2328 F32 Self-Contained Change: Additional buildroot to test x86-64 micro-architecture update
15:28:16 <contyk> .fesco 2328
15:28:17 <zodbot> contyk: Issue #2328: F32 Self-Contained Change: Additional buildroot to test x86-64 micro-architecture update - fesco - Pagure.io - https://pagure.io/fesco/issue/2328
15:28:53 <contyk> The proposal sounds sane to me.
15:29:04 <mhroncok> contyk: the change proposal?
15:29:20 <contyk> The proposal to leave it to releng.
15:29:23 <nirik> I think it's an idea worth trying... need to work out all the details.
15:29:42 <nirik> it also doesn't really need to be tied to a release...
15:29:44 <contyk> But also the change proposal, even though I'm worried about two things, mainly.
15:29:59 <sgallagh> mhroncok: releng saying "nope, we are sorry" also means that 9154 is never resolved.
15:30:09 <sgallagh> So I still think my proposal works
15:30:16 <contyk> First, what impact it will have on our resources, and second, how to deal with build failures in this second buildroot.
15:30:38 <sgallagh> Will this be a return to koji-shadow?
15:30:55 <mhroncok> sgallagh: sure. your proposal is fine with me. I juts didn't want it to sound: fesco tells releng to work things out
15:30:57 <bookwar> there is another part of the change which is not a releng: the disttag
15:31:26 * mhroncok is confused about the distatg
15:31:38 <nirik> It will use some more resources sure... failures would be on the 'owners' to fix and I sure hope it wouldn't be like koji shadow. ;)
15:31:40 <contyk> bookwar: Also the %rhel macros, right?
15:31:52 <mhroncok> bookwar: https://pagure.io/packaging-committee/issue/941#comment-619837 no answer
15:32:14 <bookwar> yes, the idea is that some packages can diverge from the main ones, but we don't want to branch them
15:32:21 <contyk> nirik: I was thinking -- if every 'fedpkg build' spawns to x86_64 builds and one of them fails, is the other still valid and be submitted as an update?
15:32:59 <bookwar> mhroncok: i was not sure if we should talk there or at fesco first, i'll comment there later today
15:33:10 <nirik> I think any alternative buildroots would be non blocking... but a lot of this depends on how it's implemented.
15:33:42 <nirik> it could be the owner of the buildroot does all the builds (based on fedmesgs or whatever)
15:33:45 <decathorpe> I think many maintainers will grumble if this breaks their builds and blocks other work.
15:34:12 * mhroncok would
15:34:17 <bookwar> decathorpe: there is no saying about blocking, only providing feedback
15:34:22 <contyk> Yes, that's my worry.
15:34:23 <sgallagh> decathorpe: That's the same argument against any new architecture though
15:34:34 <sgallagh> I don't think it's fair to apply it selectively to this case
15:34:37 <contyk> But if they don't block, there's no motivation for the maintainer to fix it.
15:34:56 <mhroncok> OOH I think it' much more likely our aarch64 or s390x builds break than this x86_64ish thing
15:35:07 <contyk> The architecture probably wouldn't trigger anyone, the disttag and %rhel macros could.
15:35:19 <bookwar> contyk: there is a group motivation to contact maintainers and figure out the fix
15:36:27 <bookwar> same for minimization, there is no"blocking" motivation for the package owner to minimize the package, but there is an effort, which the group can work on
15:37:09 * nirik nods
15:37:43 <nirik> there's lots of ways we could do it...
15:38:15 * mhroncok still has the sma eopinion. if releng wants to do this and has resources, they can
15:38:24 <mhroncok> *same opinion
15:38:26 <contyk> Should /etc/os-release be updated in this buildroot as well?
15:38:36 <contyk> What about modular builds?
15:39:05 <nirik> I would think the dist tag would be enough, but open to question I suppose...
15:39:09 <bookwar> contyk: mbs is out of scope for now, maybe later
15:39:20 <mhroncok> (OTOH given the state of my releng tickets, I doubt releng has free cycles for this)
15:39:45 <nirik> well, after setup it pretty much falls on the owners.
15:40:18 <contyk> nirik: If "the dist tag" includes the %fedora and %rhel macros, then you're probably right. But chances are some things check the file contents, in which case we might have some trademark problems (just guessing).
15:40:37 <bookwar> for /etc/os-release i wouldn't change it, we are not going to ship a user-facing image with this builds, and i think keeping os-release allows us to test packages from alt-buildroot on top of existing system if we'd like
15:41:43 <nirik> contyk: I'm not sure I follow there... Are you saying if there's an image and its called 'fedora' it would be a problem? or ?
15:42:15 <nirik> I think any images distributed are for testing/internal use only, not for end users... which we could enforce I guess if there's a legal thing
15:42:31 <contyk> nirik: I think there could be a problem if we distribute something (even just a koji buildroot) that calls itself "Enterprise Linux", it could be an issue, but IANAL.
15:42:58 <nirik> ah, well, I wasn't aware we were going to do that. ;)
15:43:15 <contyk> If it's in koji, we are.
15:43:59 <nirik> well, no, I meant calling it enterprise anything... 'alternative fedora xyz' or something was my thought
15:44:11 <decathorpe> so I guess we're saying: if releng can do it technically, and there's no legal issues, feel free to try this?
15:44:28 <contyk> Yeah, I think so.
15:45:32 <dcantrell> I'm not sure naming is an engineering issue here.  I agree it's a concern
15:45:40 <sgallagh> decathorpe: +1
15:46:38 <contyk> So since releng approval is implied, let's just vote on the change?
15:47:19 <mhroncok> what did I miss?
15:47:34 <mhroncok> releng approval is implied?
15:47:48 <contyk> Oh wait, it's self contained.
15:47:51 <contyk> Never mind.
15:48:27 <nirik> yeah, it shouldn't really affect things... or even be tied to releases much since it's going to base off rawhide.
15:48:44 <contyk> Proposal: Provided releng agrees, the change proposal is approved.
15:49:12 <decathorpe> +1
15:49:17 <dcantrell> +1
15:49:36 <nirik> sure, +1. Hopefully we can work out all the technical / legal issues in releng/legal space.
15:49:43 <mhroncok> +1
15:50:06 <sgallagh> +1
15:50:14 <mhroncok> as a side note, can we have our own alternate buildroot as well. do we just create cimilar change proposal?
15:50:21 <mhroncok> we = python miant
15:50:57 <contyk> I don't see why not.
15:50:59 <contyk> bookwar: ?
15:51:16 <nirik> sure, but... we might try and figure out how one works before adding more to the mix
15:51:45 <mhroncok> sure, will wait and than just collect the goodies :D
15:51:51 <bookwar> mhroncok: can we share? maybe you can describe the purpose? and we just starting, so as nirik said, might need to wait a bit before we get all the obstacles on the way )
15:52:12 <contyk> #agreed Provided releng agrees, the change proposal is approved. (+7, 0, -0)
15:52:17 <nirik> mhroncok: for python you just want a newer python to build against?
15:52:23 <mhroncok> bookwar: build everything with updated python. we use copr and it is really slow and not always reliable
15:52:27 <nirik> (but we could take this out of the meeting)
15:52:35 <mhroncok> sure, let's move on
15:52:40 <contyk> #topic #2342 F32 incomplete Changes
15:52:46 <contyk> .fedora 2342
15:52:52 <contyk> .fesco 2342
15:52:53 <zodbot> contyk: Issue #2342: F32 incomplete Changes - fesco - Pagure.io - https://pagure.io/fesco/issue/2342
15:54:07 <decathorpe> I think LLVM 10 is in f32+?
15:54:26 <sgallagh> Since Feb 15
15:55:01 <decathorpe> so the change is done but just wasn't marked as done?
15:55:10 <sgallagh> Looks like it
15:55:58 <mhroncok> decathorpe: was the side tag merged?
15:56:47 <sgallagh> mhroncok: For which?
15:57:02 <sgallagh> llvm-10.0.0-0.1.rc2.fc32 is tagged F32, not a special tag...
15:57:23 <mhroncok> ok then, I remember koschei saying something about side tags
15:57:59 <mhroncok> never mind me
15:58:05 <contyk> Should we go through the list one by one then?
15:58:37 <contyk> DNF better counting seems to be merged but I have no idea what release it's in.
15:58:55 <sgallagh> contyk: They client-side is, but the server-side is not, according to the comments
15:59:05 <sgallagh> So probably not appropriate to call it complete
15:59:59 <nirik> The server side was waiting on the client side. ;) but if thats in itcould be done
16:00:11 <contyk> The deadline's tomorrow.
16:00:26 <nirik> true.
16:00:37 * nirik has no idea what work is needed there. is it just reporting?
16:00:57 <sgallagh> If the client-side part is done, the server-side won't be blocking the release
16:01:11 <sgallagh> So I'm good with granting an exception to see if they finish by GA
16:01:22 <contyk> +1
16:01:43 <nirik> https://pagure.io/fedora-infrastructure/issue/7677
16:02:59 <contyk> #info DNF Better Counting: Non-blocking, client-side done, let's give the server-side part more time.
16:03:07 <contyk> Free Pascal Compiler 3.2.0
16:03:24 <decathorpe> I think this was built as well, and aarch64 issues were resolved?
16:04:14 <mhroncok> "Contingency deadline: Before release"
16:04:15 <nirik> fpc-3.2.0-0.20200222svn44232.1.fc32 is latest in f32
16:04:26 <nirik> and also built on aarch64
16:04:42 <contyk> Okay, seems fine.
16:04:51 <decathorpe> mhroncok: "Before release" is a tight deadline :)
16:04:51 <nirik> so, I think yes, it's done/in
16:05:02 <mhroncok> https://koji.fedoraproject.org/koji/buildinfo?buildID=1469799
16:05:03 <contyk> #info Free Pascal Compiler 3.20: Appears to be done, bug status should be updated.
16:05:33 <contyk> LLVM 10... so I think that's done as well.
16:05:49 <nirik> llvm-10.0.0-0.1.rc2.fc32 is latest in f32.
16:05:57 <sgallagh> Insofar as it is a release candidate
16:06:02 <contyk> #info LLVM 10: Appears to be done, bug status should be updated.
16:06:08 <decathorpe> I'm not sure about the "merged libs" LLVM change. is that already part of the latest llvm build as well?
16:06:22 <decathorpe> at least I think that was the plan.
16:06:33 <mhroncok> that was the plan
16:07:31 <smooge> sorry on the DNF better counting. The server side can go through old logs at any time to back count stuff
16:07:45 <mhroncok> https://src.fedoraproject.org/rpms/clang/blob/master/f/clang.spec has -DBUILD_SHARED_LIBS=OFF, not yet sure if built or just committed
16:07:47 <smooge> so as long as the client side is done, I would consider it done
16:08:05 <smooge> otherwise current time for it to get implemented will be F34
16:08:06 <nirik> mhroncok: the clang one is another change...
16:08:07 <contyk> smooge: Thanks.
16:08:32 <contyk> Yes, that's next on the list.
16:08:44 <contyk> So for restarting services at the end of RPM transactions...
16:08:55 <nirik> no idea on that one. ;(
16:09:00 <mhroncok> clang individual libs: "serge_sans_paille: yeah, it's in the clang-10.0.0rc2 package, if I recall correctly"
16:11:42 <contyk> I have no info whatsoever on this.
16:11:59 <contyk> Considering how little time is left, should we consider reverting?
16:12:01 <nirik> yeah, lets wait for info from change owner?
16:12:14 * nirik isn't even clear on what needs reverting if anything.
16:12:18 <sgallagh> contyk: Has some portion been implemented?
16:12:24 <contyk> No idea.
16:12:41 <sgallagh> mhroncok: This was dependent on an FPC PR; did one show up?
16:13:07 <mhroncok> sgallagh: what's "this"
16:13:26 <sgallagh> The systemd RPM service restart change
16:14:19 <mhroncok> I don't recall
16:14:38 <mhroncok> there was just https://pagure.io/packaging-committee/pull-request/949 but that's different
16:15:14 <mhroncok> telegramed zbyszek
16:15:15 <sgallagh> So it sounds like this one should be punted to F33
16:15:20 <contyk> Let's ping zbyszek in the ticket and ask him to either complete it or begin reverting.
16:15:30 <contyk> He still has a couple of hours.
16:15:56 <mhroncok> the alternatives thing is ignored by gcc maintainers: https://src.fedoraproject.org/rpms/gcc/pull-request/6
16:16:40 <contyk> #info Restart services at end of rpm transaction: Status unclear; if no action is taken before the deadline, let's move this to F33.
16:16:41 <sgallagh> mhroncok: How so?
16:16:47 <sgallagh> They rebased that PR 2 hours ago...
16:16:57 <contyk> Stop shipping individual component libraries in clang-libs package
16:17:01 <contyk> So we've touched this already.
16:17:17 <mhroncok> sgallagh: yes, they always rebase it on top of other gcc changes
16:17:51 <mhroncok> (sorry for jumping ahead)
16:18:02 <mhroncok> Stop shipping individual component libraries in clang-libs package seems done
16:18:28 <contyk> #info Stop shipping individual component libraries in clang-libs package: Appears to be done, bug status should be updated.
16:18:53 <contyk> And yes, the alternatives... should be postpoed to F33, if I understand it correctly.
16:19:55 * sgallagh agrees
16:20:06 * nirik nods.
16:20:28 <contyk> #info Use update-alternatives for /usr/bin/cc and /usr/bin/c++: Moved to F33, any changes should be reverted.
16:20:31 <contyk> Alright.
16:20:46 <contyk> Two more topics.
16:20:54 <contyk> #topic #2343 Proposal: Block (stable release) bodhi updates when they fail dist.rpmdeplint
16:20:58 <contyk> .fesco 2343
16:20:59 <zodbot> contyk: Issue #2343: Proposal: Block (stable release) bodhi updates when they fail dist.rpmdeplint - fesco - Pagure.io - https://pagure.io/fesco/issue/2343
16:21:00 <nirik> well, there's some self-contained ones...
16:21:08 <contyk> Right.
16:21:10 <contyk> #undo
16:21:10 <zodbot> Removing item from minutes: <MeetBot.items.Topic object at 0x7fdfe9392e10>
16:21:25 <contyk> Update Haskell package to Stackage LTS 14
16:21:54 <contyk> ON_QA
16:22:00 <nirik> done...
16:22:08 <nirik> https://bodhi.fedoraproject.org/updates/FEDORA-2020-b0652e4f4b (2 hours ago ;)
16:22:12 <contyk> #info Haskell package to Stackage LTS 14: Done.
16:22:22 <contyk> Ship BerkeleyDB backend as a module
16:22:43 <contyk> The owner proposes to move this to F33.
16:22:48 <dcantrell> do it
16:23:03 <contyk> #info Ship BerkeleyDB backend as a module: Moved to F33.
16:23:06 <nirik> yeah...
16:23:15 <contyk> Limit scriptlet usage of core packages
16:23:37 <nirik> no idea the status here. ;(
16:23:46 <contyk> I feel like this one keeps coming back.
16:23:50 <contyk> Move to F33?
16:24:00 <nirik> or ping maintainer on it?
16:24:18 <mhroncok> looking a release back
16:24:22 <dcantrell> that one feels basically ongoing.  there's a plan in place and it's just progressing.  I don't think there's any action for us
16:24:54 * contyk nods
16:25:14 <nirik> would be good to know the status, but yeah...
16:25:18 <contyk> #info Limit scriptlet usage of core packages: An ongoing change, status unknown. No action needed.
16:25:26 <mhroncok> ack
16:25:36 <contyk> #topic #2343 Proposal: Block (stable release) bodhi updates when they fail dist.rpmdeplint
16:25:48 <decathorpe> this is mine
16:25:52 <contyk> .fesco 2343
16:25:53 <zodbot> contyk: Issue #2343: Proposal: Block (stable release) bodhi updates when they fail dist.rpmdeplint - fesco - Pagure.io - https://pagure.io/fesco/issue/2343
16:26:07 <dcantrell> I am in favor of this change
16:26:15 <decathorpe> but I guess taskotron won't relocate to the new datacenter, so it's basically moot
16:26:28 <nirik> well, I think we don't want to depend on something that is going away.
16:26:55 <dcantrell> ah, yes
16:27:05 <decathorpe> I feel a bit stupid to have opened this proposal ticket. but I don't think taskotron shutdown was announced anywhere?
16:27:09 <nirik> but yes, I definitely would be in favor of some blocking tests. :)
16:27:19 <ignatenkobrain> I'd like to block packages going stable if they have broken dependencies... unless waived
16:27:32 <decathorpe> I'm opening almost one bug per day for broken deps.
16:27:38 <ignatenkobrain> but before we can do that, we need easy way to waive results
16:27:38 <dcantrell> I've got dep checking on my to do list for rpminspect and that runs for fedora builds now
16:28:07 <decathorpe> bodhi CLI and bodhi-cli both support waiving tests
16:28:41 <nirik> dcantrell: would it be worth looking at making that default blocking/
16:28:41 <nirik> ?
16:28:43 <tflink> the plan is to have something in place to run rpmdeplint before taskotron goes away
16:28:48 * nirik hasn't looked at rpminspect output
16:28:56 <dcantrell> nirik: yes, in fact that's a thing I am currently working on.
16:29:04 <dcantrell> there's a short list of things I deem very important before it can be blocking
16:29:15 <decathorpe> tflink: that would be great.
16:29:15 <dcantrell> but right now it runs for all koji builds and reports in an informational mode
16:29:58 <dcantrell> it is possible to run rpminspect locally as well
16:30:06 <dcantrell> just give it koji build NVRs and away it goes
16:30:11 <decathorpe> I'm just worried that the current situation isn't maintainable long-term. a lot of broken updates would have been pushed to stable if I hadn't intervened
16:30:29 <decathorpe> (stats are in the ticket)
16:31:17 <nirik> I think we all want something better, it's just a matter of driving that forward until it's in place
16:31:26 <contyk> Feels like everyone wants this. So the only problem is the status of taskotron and its rpminspect-based replacement.
16:31:37 <contyk> :)
16:32:22 <tflink> contyk: the plan is to run rpmdeplint in a non-taskotron system in the mean time
16:34:35 * nirik isn't sure of any timelines here...
16:34:41 <nirik> or what we can do here now.
16:34:48 <contyk> Proposal: Approved for an rpminspect-based solution once available.
16:35:03 <contyk> Not sure we need a timeline for it.
16:35:25 <decathorpe> contyk: either that, or rpmdeplint on taskotron replacement.
16:36:28 <contyk> Votes or a counterproposal?
16:36:37 * nirik is confused whats running now. I don't actually see in bodhi a rpmdeplint.
16:37:54 <decathorpe> nirik: dist.rpmdeplint should run. at least, it did, until a few days ago. but I guess it's not for every update.
16:38:19 <tflink> it should still be running for every update
16:38:21 <nirik> proposal: close for now, as soon as something is ready to enable ask us again about that specific thing
16:38:31 * tflink feels like he is just adding noise at this point, though
16:38:33 * nirik looked at https://bodhi.fedoraproject.org/updates/FEDORA-2020-9f0f051950
16:38:48 <decathorpe> tflink: I think it should, but it doesn't.
16:38:56 <decathorpe> +1 for nirik's proposal.
16:38:57 <contyk> nirik: +1
16:39:07 <dcantrell> +1
16:39:48 <nirik> and decathorpe++ for all your work blocking broken stuff manually
16:39:49 <zodbot> nirik: Karma for decathorpe changed to 6 (for the current release cycle):  https://badges.fedoraproject.org/tags/cookie/any
16:39:49 <contyk> bookwar, ignatenkobrain, mhroncok, sgallagh: ^ ?
16:40:05 <sgallagh> nirik: +1
16:40:59 <decathorpe> nirik: thanks! I just hope it's worth it. this should be a case for automation eventually :)
16:41:11 <contyk> #agreed Close for now; as soon as something is ready to enable, ask us again about that specific thing (+5, 0, -0)
16:41:12 * mhroncok haD a phone call, sorry, reading back
16:41:21 <nirik> yeah. I really really want gating.
16:41:39 <nirik> The number of times I have to fix things for rawhide composes is silly. ;(
16:41:41 * contyk waits for mhroncok
16:42:18 <mhroncok> contyk: acks the proposal, thanks. move on
16:42:25 <contyk> #undo
16:42:25 <zodbot> Removing item from minutes: AGREED by contyk at 16:41:11 : Close for now; as soon as something is ready to enable, ask us again about that specific thing (+5, 0, -0)
16:42:31 <contyk> #agreed Close for now; as soon as something is ready to enable, ask us again about that specific thing (+6, 0, -0)
16:42:44 <contyk> #topic #2340 Get a process established to remove branches
16:42:48 <contyk> .fesco 2340
16:42:49 <zodbot> contyk: Issue #2340: Get a process established to remove branches - fesco - Pagure.io - https://pagure.io/fesco/issue/2340
16:43:46 <nirik> I'm fine with the proposal... as long as it's easy and clear
16:44:37 <dcantrell> same
16:44:45 <mhroncok> if we agree on the rules, I can work with releng on how to automate this. I am willing to be the "automation" for the time being and later we can even run the check on git server side
16:45:07 <nirik> this also won't handle all cases, but thats fine
16:45:22 <mhroncok> that's known
16:45:37 <contyk> As long as we don't accidentally remove stream branches, cool.
16:45:48 <mhroncok> for example if you fedpkg retire that bracnh it's no longer part of enything or if you push a bad commit without building it
16:46:38 <nirik> there's a related idea to archive old/unused branches too...
16:47:40 <nirik> https://pagure.io/fedora-infrastructure/issue/8390
16:48:01 <contyk> Proposal: Branches reachable from any other branch that are not used for building anything can be removed.
16:48:20 <dcantrell> also related, I'd like it if we just stopped using branches altogether and let package maintainers make whatever branches they wanted to.  releng would include builds based on tag and we could have a file in the master branch called ".releng" or something that lists f32=TAG
16:48:38 <decathorpe> dcantrell that sounds horrible :)
16:48:45 <dcantrell> explain how
16:49:09 <dcantrell> we don't have to get in to this now
16:49:17 <contyk> Note our git tags are currently immutable.
16:49:32 <nirik> that would mean a bunch of tooling changes. If part of a entire revamp of how we do things it could work... but would also be a lot of work
16:49:53 <dcantrell> correct, it would not be a trivial change
16:49:58 * contyk suggests dcantrell files a change proposal.
16:50:03 <dcantrell> I can do that
16:50:18 <contyk> Votes on the last proposal?
16:50:34 <dcantrell> +1 from me on 2340
16:50:36 <mhroncok> contyk: +1
16:50:42 <decathorpe> +1
16:50:44 <sgallagh> contyk: +1
16:50:50 <nirik> +1
16:51:29 <contyk> I'll assume others have already left us.
16:51:39 <dcantrell> probably
16:51:46 <dcantrell> I have to run and meet my lunch delivery, don't wait for me
16:51:52 <contyk> #agreed Branches reachable from any other branch that are not used for building anything can be removed (+6, 0, -0)
16:52:11 <contyk> nim asked me if we can also discuss 2344
16:52:19 <contyk> #topic #2344 Enable new fonts packaging guidelines in F31
16:52:21 <contyk> .fesco 2344
16:52:22 <zodbot> contyk: Issue #2344: Enable new fonts packaging guidelines in F31 - fesco - Pagure.io - https://pagure.io/fesco/issue/2344
16:52:35 <nim-nim> contyk: thanks
16:53:02 <mhroncok> if this is not a breaking change, it is by defintion backwards compatible and hence requires no fesco aproval
16:53:25 <contyk> That's a change I like.
16:53:33 <mhroncok> OTOH if this is breaking change, and backwards incomaptible, I think fesco should not approve it
16:53:34 <decathorpe> I agree. no backwards incompatible stuff is being pushed to f31, so I'm in favor
16:54:00 <mhroncok> either way, I don't think a fesco ticket is needed, unles we are willing to dive in and actaully check
16:54:08 <nirik> mhroncok: +1
16:54:14 <contyk> I agree.
16:54:23 <mhroncok> Proposal: ...
16:54:25 <contyk> #info FPC approval is sufficient in this case.
16:54:29 <contyk> Like that? :)
16:54:37 <mhroncok> no FPC approval needed aither
16:54:40 <mhroncok> *either
16:54:53 <contyk> It's already happened, though.
16:54:54 <nim-nim> mhroncok: pwalters asked for FESCO arbitration ,not me :(
16:55:14 <decathorpe> FPC already approved the new guidelines, without limitations on where they are applicable.
16:55:18 <mhroncok> Proposal: No explicit approval needed for backwards compatible changes Close the ticket.
16:55:34 <decathorpe> mhroncok: +1
16:55:44 <mhroncok> mhroncok: Let them know that we deem it not necessary.
16:55:51 <nirik> +1
16:55:55 <contyk> +1
16:56:53 <nim-nim> so practically, is that sufficient to unblock https://bodhi.fedoraproject.org/updates/FEDORA-2020-296917559c ?
16:57:16 <mhroncok> nim-nim: yes, assuming the update is indeed backwards compatible
16:57:35 <mhroncok> which I have **not verified** for the record
16:57:46 <contyk> sgallagh, dcantrell: ?
16:58:11 <nim-nim> mhroncok: a few months ago I rebuilt all the (then existing) Fedora packages with fonts in them using the new macros, and no build failed in cpr
16:58:17 <nim-nim> in copr
16:58:31 <mhroncok> nim-nim++
16:58:38 <mhroncok> thanks for being careful
16:58:42 <nim-nim> that means all the existing specs found the grandfathered macros in the new macro package
16:58:55 <mhroncok> nim++
16:58:56 <zodbot> mhroncok: Karma for nim changed to 4 (for the current release cycle):  https://badges.fedoraproject.org/tags/cookie/any
16:59:25 <contyk> Seems we no longer have quorum but strictly speaking, I don't even think this needs a vote.
16:59:35 <mhroncok> right
16:59:45 <contyk> I'll just info it.
16:59:56 <contyk> #info No explicit approval needed for backwards compatible changes Close the ticket.
17:00:07 <nim-nim> so it should be solid, even if 100% solid does not exist in real life
17:00:08 <contyk> #topic Next week's chair
17:00:23 <nim-nim> thanks all
17:00:49 <contyk> We're out of time. Any volunteers?
17:01:13 <mhroncok> contyk: I can do it
17:01:21 <contyk> Thanks, mhroncok.
17:01:29 <contyk> #action mhroncok will chair the next meeting.
17:01:33 <contyk> #topic Open Floor
17:01:44 <contyk> Any last comments today? Closing in a bit.
17:01:46 <nirik> I had one item...
17:01:51 <contyk> Go ahead.
17:02:21 <nirik> just a info: beta freeze/bodhi enablement is at 14UTC on tuesday (2020-02-25). We moved it from 00:00, so 14 extra hours...
17:02:42 <contyk> #info beta freeze/bodhi enablement is at 14UTC on tuesday (2020-02-25). We moved it from 00:00, so 14 extra hours...
17:02:48 <contyk> Thanks.
17:03:10 <contyk> Alright. Thanks, everyone.
17:03:13 <contyk> #endmeeting