15:00:04 #startmeeting FESCO (2020-02-24) 15:00:04 Meeting started Mon Feb 24 15:00:04 2020 UTC. 15:00:04 This meeting is logged and archived in a public location. 15:00:04 The chair is contyk. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:00:04 Useful Commands: #action #agreed #halp #info #idea #link #topic. 15:00:04 The meeting name has been set to 'fesco_(2020-02-24)' 15:00:06 #meetingname fesco 15:00:06 The meeting name has been set to 'fesco' 15:00:08 #chair nirik, ignatenkobrain, decathorpe, zbyszek, bookwar, sgallagh, contyk, mhroncok, dcantrell 15:00:08 Current chairs: bookwar contyk dcantrell decathorpe ignatenkobrain mhroncok nirik sgallagh zbyszek 15:00:10 #topic init process 15:00:17 .hello psabata 15:00:18 contyk: psabata 'Petr Šabata' 15:00:19 .hello2 15:00:21 decathorpe: decathorpe 'Fabio Valentini' 15:00:22 o/ 15:00:25 .hello dcantrel 15:00:25 morning 15:00:25 dcantrell: dcantrel 'David Cantrell' 15:00:33 .hello2 15:00:38 sgallagh: sgallagh 'Stephen Gallagher' 15:01:13 Yay, quorum. 15:01:29 So let's begin with the followups. 15:01:53 #topic #2341 maven and ant: sfl4j-jdk14 filtered (ticket includes proposal to ban default modular streams) 15:01:58 .fesco 2341 15:02:02 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 so, I guess there's a proposal here to drop default modules... 15:03:42 https://pagure.io/fesco/issue/2341#comment-627466 15:03:44 I believe that's what we've narrowed it down to 15:03:45 * sgallagh is internalizing the arguments. Please hold. 15:04:31 So it's pretty similar to status quo, where it's all banned unless you get an exception. 15:04:32 cipherboy would also be available to talk about this for about the next 20 minutes or so. 15:05:05 contyk: except it also include exisitng defaults 15:05:09 contyk: did maven and ant ever go through that process, or do those modules predate this policy? 15:05:22 they predate the policy 15:05:42 that explains a lot. 15:05:52 contyk: and even with fesco exception, the default eclipse stream broke things horribly 15:06:24 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 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 it also narrows down the conflict we had with sgallagh IMHO... 15:07:12 Which conflict are you referring to? 15:07:19 ...sgallagh wanted to "ban temporarily" I wanted to "ban forever" 15:07:28 (Sorry if I'm slow today; just getting back from being blissfully on vacation) 15:07:43 now this is by definition temporary, but does not build it on "when things are technically matured" but on exisiting policy 15:08:28 I mean, on having the policy 15:08:39 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 there is always a however :( 15:09:24 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 I'm not saying "no", I just want to make sure we understand the unintended consequences too 15:09:56 RHEL 8 is done. anything that is borken now will need to be fixed very carefully from within RHEL context 15:10:16 In Fedora, we should look into future (9, 10), not in the past (8) 15:10:17 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 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 Again, I'm not saying "no". I'm resigned to the fact that this is probably the sane course forward. 15:10:50 also, once we have a policy, we might have default modular streams 15:11:07 But I want it on the record what the downsides are too 15:11:14 mhroncok: right, but I doubt that this will happen before f34 15:11:35 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 Correct? 15:11:39 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 contyk: not in my vision 15:12:06 contyk: Presumably also we would have a mechanism for backing out of modules as well, which we are lacking. 15:12:15 There's a fair bit of work that needs to be done here still. 15:12:29 right. because right now, there's issues in f31 that can never be fixed by updates. 15:12:39 we would **also** have a "in Fedora, we modularize this kind of things" document 15:12:58 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 looping back to https://pagure.io/fesco/issue/2114 15:13:26 so the proposal dos not list a TODO list for enablement 15:13:33 * sgallagh nods. 15:13:42 it merely says: a policy must be made that fesco approves 15:13:50 all the thing we are saying need to be part of that policy 15:13:54 *things 15:14:10 or "technically done" and hence the policy can count on them as facts 15:14:46 This does not preclude the Modularity Team from proposing a set of those requirements for FESCo to consider in the future. 15:14:49 Right? 15:15:04 (I don't want to get into a state where the goalposts are constantly moving either) 15:15:13 right 15:15:18 "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 I've said my piece and I'm prepared to vote +1 on mhroncok's proposal 15:15:52 bookwar: "we can modularize anything" is also possible... if we agree on that 15:15:57 sgallagh: thanks 15:16:01 sgallagh: piece or peace? 15:16:29 bookwar: the point is, that this will be a long and heated discussion. hence the details are intentionally left out. 15:16:55 dcantrell: https://www.merriam-webster.com/words-at-play/say-your-piece-versus-peace-usage 15:17:05 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 .hello2 15:17:29 ignatenkobrain: ignatenkobrain 'Igor Gnatenko' 15:17:37 None of this forbids people from making modules, it's just about the defaults 15:17:54 (which is significant, still, of course) 15:18:04 sgallagh: I assumed former, but that's entirely too much text abouit piece vs. peace :) 15:18:14 so does just dropping defaults resolve our current blockers? (ie, the upgrades one and any others?) 15:18:24 nirik: It does not 15:18:48 nirik: combined with the propsoed solution to do `dnf module reset *` on default upgrade mechsnism, it should 15:18:53 I think existing modules need to be "reset" at upgrade. but FTI issues should be resolved. 15:19:00 nirik: standalone, it does not 15:19:02 mhroncok: That's one option, but I think we can do better 15:19:17 sgallagh: alos, intentionally left out here 15:19:23 *also 15:19:27 ok, fair 15:19:28 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 that's a technical problem, not a policy problem. 15:19:43 So as long as they have higher NVRs than the packages in the module streams, they'll "win" 15:19:57 sgallagh: That feels very wrong to me. 15:20:00 Hold on. That won't work 15:20:11 Sorry, didn't think that through completely. 15:20:35 The reset option is still probably best 15:20:42 Yes. 15:20:49 Sorry for the noise 15:21:07 Even though that also means people who intentionally chose a stream will be "upgraded" to something else. 15:21:15 But that's a price we probably have to pay. 15:21:49 Release notes and careful messaging about that should be Good Enough (TM) 15:21:57 do we want to vote on mhroncok's proposal? 15:22:05 and at least upgrade time is when people are expecting to deal with that. 15:22:26 nirik: Yeah, true 15:22:32 So the proposal is to completely ban default streams starting with the next release? 15:22:34 +1 to mhroncok proposal 15:22:35 contyk: also, there is an alternate upgrade way that should preserve the streams, as noted in th BZ 15:22:43 contyk: with F32, yes 15:22:44 (FTR since I voted in the ticket) 15:23:02 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 ^ the proposal FTR 15:23:08 Okay, +1 all things considered, hoping we can change that in the future. 15:23:10 +1 15:23:15 +1 15:23:18 +1 15:23:20 +1 15:23:58 bookwar: ? 15:24:07 mhroncok: too much text to vote on ) 15:24:09 zbyszek told me on telegram to vote +1. but he can back that up in the ticket later if needed 15:24:22 +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 zbyszek is stuck afk 15:25:04 I didn't even see zbyszek so I wasn't waiting for him. 15:25:12 sure, just forwarding the message 15:25:24 #agreed For Fedora 32 and onward, all default modular streams are banned. Existing defaults are removed. (+8, 0, -0) 15:25:28 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 I think "until FESCo decides otherwise" is always implied :) 15:25:53 OK, fair 15:25:57 sgallagh: fesco overriding its own decisions is always an option 15:26:14 #topic #2339 Proposal to change ARM Release Blocking Criteria - Drop XFCE (32bit), Add Workstation(64bit) 15:26:19 .fesco 2339 15:26:21 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 I thought this was approved last week? 15:26:30 So I think we said there was nothing to do for us. 15:26:46 But I saw the ticket was still open and there was some activity so I wanted to check. 15:27:06 I think the comments don't change our decision, do they? 15:27:09 just needs implementing now I think? 15:27:32 Agreed. 15:27:45 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 #info No change in last week's FESCo decision, the ticket can be closed. 15:28:11 #topic #2328 F32 Self-Contained Change: Additional buildroot to test x86-64 micro-architecture update 15:28:16 .fesco 2328 15:28:17 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 The proposal sounds sane to me. 15:29:04 contyk: the change proposal? 15:29:20 The proposal to leave it to releng. 15:29:23 I think it's an idea worth trying... need to work out all the details. 15:29:42 it also doesn't really need to be tied to a release... 15:29:44 But also the change proposal, even though I'm worried about two things, mainly. 15:29:59 mhroncok: releng saying "nope, we are sorry" also means that 9154 is never resolved. 15:30:09 So I still think my proposal works 15:30:16 First, what impact it will have on our resources, and second, how to deal with build failures in this second buildroot. 15:30:38 Will this be a return to koji-shadow? 15:30:55 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 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 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 bookwar: Also the %rhel macros, right? 15:31:52 bookwar: https://pagure.io/packaging-committee/issue/941#comment-619837 no answer 15:32:14 yes, the idea is that some packages can diverge from the main ones, but we don't want to branch them 15:32:21 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 mhroncok: i was not sure if we should talk there or at fesco first, i'll comment there later today 15:33:10 I think any alternative buildroots would be non blocking... but a lot of this depends on how it's implemented. 15:33:42 it could be the owner of the buildroot does all the builds (based on fedmesgs or whatever) 15:33:45 I think many maintainers will grumble if this breaks their builds and blocks other work. 15:34:12 * mhroncok would 15:34:17 decathorpe: there is no saying about blocking, only providing feedback 15:34:22 Yes, that's my worry. 15:34:23 decathorpe: That's the same argument against any new architecture though 15:34:34 I don't think it's fair to apply it selectively to this case 15:34:37 But if they don't block, there's no motivation for the maintainer to fix it. 15:34:56 OOH I think it' much more likely our aarch64 or s390x builds break than this x86_64ish thing 15:35:07 The architecture probably wouldn't trigger anyone, the disttag and %rhel macros could. 15:35:19 contyk: there is a group motivation to contact maintainers and figure out the fix 15:36:27 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 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 *same opinion 15:38:26 Should /etc/os-release be updated in this buildroot as well? 15:38:36 What about modular builds? 15:39:05 I would think the dist tag would be enough, but open to question I suppose... 15:39:09 contyk: mbs is out of scope for now, maybe later 15:39:20 (OTOH given the state of my releng tickets, I doubt releng has free cycles for this) 15:39:45 well, after setup it pretty much falls on the owners. 15:40:18 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 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 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 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 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 ah, well, I wasn't aware we were going to do that. ;) 15:43:15 If it's in koji, we are. 15:43:59 well, no, I meant calling it enterprise anything... 'alternative fedora xyz' or something was my thought 15:44:11 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 Yeah, I think so. 15:45:32 I'm not sure naming is an engineering issue here. I agree it's a concern 15:45:40 decathorpe: +1 15:46:38 So since releng approval is implied, let's just vote on the change? 15:47:19 what did I miss? 15:47:34 releng approval is implied? 15:47:48 Oh wait, it's self contained. 15:47:51 Never mind. 15:48:27 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 Proposal: Provided releng agrees, the change proposal is approved. 15:49:12 +1 15:49:17 +1 15:49:36 sure, +1. Hopefully we can work out all the technical / legal issues in releng/legal space. 15:49:43 +1 15:50:06 +1 15:50:14 as a side note, can we have our own alternate buildroot as well. do we just create cimilar change proposal? 15:50:21 we = python miant 15:50:57 I don't see why not. 15:50:59 bookwar: ? 15:51:16 sure, but... we might try and figure out how one works before adding more to the mix 15:51:45 sure, will wait and than just collect the goodies :D 15:51:51 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 #agreed Provided releng agrees, the change proposal is approved. (+7, 0, -0) 15:52:17 mhroncok: for python you just want a newer python to build against? 15:52:23 bookwar: build everything with updated python. we use copr and it is really slow and not always reliable 15:52:27 (but we could take this out of the meeting) 15:52:35 sure, let's move on 15:52:40 #topic #2342 F32 incomplete Changes 15:52:46 .fedora 2342 15:52:52 .fesco 2342 15:52:53 contyk: Issue #2342: F32 incomplete Changes - fesco - Pagure.io - https://pagure.io/fesco/issue/2342 15:54:07 I think LLVM 10 is in f32+? 15:54:26 Since Feb 15 15:55:01 so the change is done but just wasn't marked as done? 15:55:10 Looks like it 15:55:58 decathorpe: was the side tag merged? 15:56:47 mhroncok: For which? 15:57:02 llvm-10.0.0-0.1.rc2.fc32 is tagged F32, not a special tag... 15:57:23 ok then, I remember koschei saying something about side tags 15:57:59 never mind me 15:58:05 Should we go through the list one by one then? 15:58:37 DNF better counting seems to be merged but I have no idea what release it's in. 15:58:55 contyk: They client-side is, but the server-side is not, according to the comments 15:59:05 So probably not appropriate to call it complete 15:59:59 The server side was waiting on the client side. ;) but if thats in itcould be done 16:00:11 The deadline's tomorrow. 16:00:26 true. 16:00:37 * nirik has no idea what work is needed there. is it just reporting? 16:00:57 If the client-side part is done, the server-side won't be blocking the release 16:01:11 So I'm good with granting an exception to see if they finish by GA 16:01:22 +1 16:01:43 https://pagure.io/fedora-infrastructure/issue/7677 16:02:59 #info DNF Better Counting: Non-blocking, client-side done, let's give the server-side part more time. 16:03:07 Free Pascal Compiler 3.2.0 16:03:24 I think this was built as well, and aarch64 issues were resolved? 16:04:14 "Contingency deadline: Before release" 16:04:15 fpc-3.2.0-0.20200222svn44232.1.fc32 is latest in f32 16:04:26 and also built on aarch64 16:04:42 Okay, seems fine. 16:04:51 mhroncok: "Before release" is a tight deadline :) 16:04:51 so, I think yes, it's done/in 16:05:02 https://koji.fedoraproject.org/koji/buildinfo?buildID=1469799 16:05:03 #info Free Pascal Compiler 3.20: Appears to be done, bug status should be updated. 16:05:33 LLVM 10... so I think that's done as well. 16:05:49 llvm-10.0.0-0.1.rc2.fc32 is latest in f32. 16:05:57 Insofar as it is a release candidate 16:06:02 #info LLVM 10: Appears to be done, bug status should be updated. 16:06:08 I'm not sure about the "merged libs" LLVM change. is that already part of the latest llvm build as well? 16:06:22 at least I think that was the plan. 16:06:33 that was the plan 16:07:31 sorry on the DNF better counting. The server side can go through old logs at any time to back count stuff 16:07:45 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 so as long as the client side is done, I would consider it done 16:08:05 otherwise current time for it to get implemented will be F34 16:08:06 mhroncok: the clang one is another change... 16:08:07 smooge: Thanks. 16:08:32 Yes, that's next on the list. 16:08:44 So for restarting services at the end of RPM transactions... 16:08:55 no idea on that one. ;( 16:09:00 clang individual libs: "serge_sans_paille: yeah, it's in the clang-10.0.0rc2 package, if I recall correctly" 16:11:42 I have no info whatsoever on this. 16:11:59 Considering how little time is left, should we consider reverting? 16:12:01 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 contyk: Has some portion been implemented? 16:12:24 No idea. 16:12:41 mhroncok: This was dependent on an FPC PR; did one show up? 16:13:07 sgallagh: what's "this" 16:13:26 The systemd RPM service restart change 16:14:19 I don't recall 16:14:38 there was just https://pagure.io/packaging-committee/pull-request/949 but that's different 16:15:14 telegramed zbyszek 16:15:15 So it sounds like this one should be punted to F33 16:15:20 Let's ping zbyszek in the ticket and ask him to either complete it or begin reverting. 16:15:30 He still has a couple of hours. 16:15:56 the alternatives thing is ignored by gcc maintainers: https://src.fedoraproject.org/rpms/gcc/pull-request/6 16:16:40 #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 mhroncok: How so? 16:16:47 They rebased that PR 2 hours ago... 16:16:57 Stop shipping individual component libraries in clang-libs package 16:17:01 So we've touched this already. 16:17:17 sgallagh: yes, they always rebase it on top of other gcc changes 16:17:51 (sorry for jumping ahead) 16:18:02 Stop shipping individual component libraries in clang-libs package seems done 16:18:28 #info Stop shipping individual component libraries in clang-libs package: Appears to be done, bug status should be updated. 16:18:53 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 #info Use update-alternatives for /usr/bin/cc and /usr/bin/c++: Moved to F33, any changes should be reverted. 16:20:31 Alright. 16:20:46 Two more topics. 16:20:54 #topic #2343 Proposal: Block (stable release) bodhi updates when they fail dist.rpmdeplint 16:20:58 .fesco 2343 16:20:59 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 well, there's some self-contained ones... 16:21:08 Right. 16:21:10 #undo 16:21:10 Removing item from minutes: 16:21:25 Update Haskell package to Stackage LTS 14 16:21:54 ON_QA 16:22:00 done... 16:22:08 https://bodhi.fedoraproject.org/updates/FEDORA-2020-b0652e4f4b (2 hours ago ;) 16:22:12 #info Haskell package to Stackage LTS 14: Done. 16:22:22 Ship BerkeleyDB backend as a module 16:22:43 The owner proposes to move this to F33. 16:22:48 do it 16:23:03 #info Ship BerkeleyDB backend as a module: Moved to F33. 16:23:06 yeah... 16:23:15 Limit scriptlet usage of core packages 16:23:37 no idea the status here. ;( 16:23:46 I feel like this one keeps coming back. 16:23:50 Move to F33? 16:24:00 or ping maintainer on it? 16:24:18 looking a release back 16:24:22 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 would be good to know the status, but yeah... 16:25:18 #info Limit scriptlet usage of core packages: An ongoing change, status unknown. No action needed. 16:25:26 ack 16:25:36 #topic #2343 Proposal: Block (stable release) bodhi updates when they fail dist.rpmdeplint 16:25:48 this is mine 16:25:52 .fesco 2343 16:25:53 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 I am in favor of this change 16:26:15 but I guess taskotron won't relocate to the new datacenter, so it's basically moot 16:26:28 well, I think we don't want to depend on something that is going away. 16:26:55 ah, yes 16:27:05 I feel a bit stupid to have opened this proposal ticket. but I don't think taskotron shutdown was announced anywhere? 16:27:09 but yes, I definitely would be in favor of some blocking tests. :) 16:27:19 I'd like to block packages going stable if they have broken dependencies... unless waived 16:27:32 I'm opening almost one bug per day for broken deps. 16:27:38 but before we can do that, we need easy way to waive results 16:27:38 I've got dep checking on my to do list for rpminspect and that runs for fedora builds now 16:28:07 bodhi CLI and bodhi-cli both support waiving tests 16:28:41 dcantrell: would it be worth looking at making that default blocking/ 16:28:41 ? 16:28:43 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 nirik: yes, in fact that's a thing I am currently working on. 16:29:04 there's a short list of things I deem very important before it can be blocking 16:29:15 tflink: that would be great. 16:29:15 but right now it runs for all koji builds and reports in an informational mode 16:29:58 it is possible to run rpminspect locally as well 16:30:06 just give it koji build NVRs and away it goes 16:30:11 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 (stats are in the ticket) 16:31:17 I think we all want something better, it's just a matter of driving that forward until it's in place 16:31:26 Feels like everyone wants this. So the only problem is the status of taskotron and its rpminspect-based replacement. 16:31:37 :) 16:32:22 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 or what we can do here now. 16:34:48 Proposal: Approved for an rpminspect-based solution once available. 16:35:03 Not sure we need a timeline for it. 16:35:25 contyk: either that, or rpmdeplint on taskotron replacement. 16:36:28 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 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 it should still be running for every update 16:38:21 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 tflink: I think it should, but it doesn't. 16:38:56 +1 for nirik's proposal. 16:38:57 nirik: +1 16:39:07 +1 16:39:48 and decathorpe++ for all your work blocking broken stuff manually 16:39:49 nirik: Karma for decathorpe changed to 6 (for the current release cycle): https://badges.fedoraproject.org/tags/cookie/any 16:39:49 bookwar, ignatenkobrain, mhroncok, sgallagh: ^ ? 16:40:05 nirik: +1 16:40:59 nirik: thanks! I just hope it's worth it. this should be a case for automation eventually :) 16:41:11 #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 yeah. I really really want gating. 16:41:39 The number of times I have to fix things for rawhide composes is silly. ;( 16:41:41 * contyk waits for mhroncok 16:42:18 contyk: acks the proposal, thanks. move on 16:42:25 #undo 16:42:25 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 #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 #topic #2340 Get a process established to remove branches 16:42:48 .fesco 2340 16:42:49 contyk: Issue #2340: Get a process established to remove branches - fesco - Pagure.io - https://pagure.io/fesco/issue/2340 16:43:46 I'm fine with the proposal... as long as it's easy and clear 16:44:37 same 16:44:45 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 this also won't handle all cases, but thats fine 16:45:22 that's known 16:45:37 As long as we don't accidentally remove stream branches, cool. 16:45:48