15:00:05 #startmeeting FESCO (2019-07-12) 15:00:05 Meeting started Fri Jul 12 15:00:05 2019 UTC. 15:00:05 This meeting is logged and archived in a public location. 15:00:05 The chair is ignatenkobrain. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:00:05 Useful Commands: #action #agreed #halp #info #idea #link #topic. 15:00:05 The meeting name has been set to 'fesco_(2019-07-12)' 15:00:11 #meetingname fesco 15:00:11 The meeting name has been set to 'fesco' 15:00:17 .hello2 15:00:18 #chair nirik, ignatenkobrain, jforbes, zbyszek, bookwar, sgallagh, contyk, mhroncok, otaylor 15:00:18 Current chairs: bookwar contyk ignatenkobrain jforbes mhroncok nirik otaylor sgallagh zbyszek 15:00:18 zbyszek: zbyszek 'Zbigniew Jędrzejewski-Szmek' 15:00:18 #topic init process 15:00:21 .hello psabata 15:00:23 .hello2 15:00:24 contyk: psabata 'Petr Šabata' 15:00:26 .hello kevin 15:00:27 jforbes: jforbes 'Justin M. Forbes' 15:00:30 nirik: kevin 'Kevin Fenzi' 15:00:38 .hello2 15:00:40 bookwar: bookwar 'Aleksandra Fedorova' 15:01:00 .hello2 15:01:01 sgallagh: sgallagh 'Stephen Gallagher' 15:01:26 .hello2 15:01:27 bcotton: bcotton 'Ben Cotton' 15:01:36 hi 15:02:24 let's give otaylor few more minutes 15:02:40 * otaylor is here now 15:02:42 .hello2 15:02:43 otaylor: otaylor 'Owen Taylor' 15:03:08 cool, let's start 15:03:11 #topic #2166 F31 System-Wide Change: Python means Python 3 15:03:11 .fesco 2166 15:03:12 ignatenkobrain: Issue #2166: F31 System-Wide Change: Python means Python 3 - fesco - Pagure.io - https://pagure.io/fesco/issue/2166 15:03:13 https://pagure.io/fesco/issue/2166 15:03:44 +1 15:03:55 i find fedora-devel discussion convincing enough, voted on the issue 15:03:56 Do, sorry. Thought I voted in ticket. 15:04:01 +1 15:04:03 mhroncok, me, and bookwar votes in the ticket 15:04:09 I'm +1 on this, too 15:04:32 I am +1 here also 15:04:38 +1 as well 15:05:13 * nirik also was not for it before, but the discussion swayed me 15:05:24 otaylor: vote? 15:05:27 +1 15:05:35 cool 15:05:40 thanks 15:05:53 #agree APPROVED (+8, 0, -0) 15:06:00 #topic #2165 F31 System-Wide Change: Golang 1.13 15:06:02 .fesco 2165 15:06:04 ignatenkobrain: Issue #2165: F31 System-Wide Change: Golang 1.13 - fesco - Pagure.io - https://pagure.io/fesco/issue/2165 15:06:15 https://pagure.io/fesco/issue/2165 15:07:12 bookwar had some good questions here. 15:07:18 I'm going to abstain here as I don't think I have a good grasp of the situation. 15:07:18 I'm not a go person, so somebody please explain: is there some doubt about how to proceed, or is all just business as usual with rebuilding a bunch of packages? 15:07:20 here I don't understand the internal dispute between the go maintainers :( 15:07:46 mhroncok: me too 15:07:51 bookwar: I don't think owners have clue how many things will break. I agree, it would be nice to have list of components which should cause change revert. 15:08:00 I'm +1 to the update in general but I'd be happier with a better plan and those questions addressed 15:09:09 so, wait a week and ask for more info? 15:09:15 (well, wait for answers) 15:09:23 wfm. 15:09:33 wfm as well 15:09:38 ack 15:09:48 works for me 15:10:20 proposal: #agree Wait a week and get answers for questions in a ticket. 15:10:28 ack 15:10:31 ack 15:10:33 ack 15:10:34 ack 15:10:36 s/a ticket/the ticket/ 15:10:40 ack 15:11:00 #agree Wait a week and get answers for questions in the ticket 15:11:04 #topic #2155 Non-responsive maintainer "bdpepple" for package "farstream02" 15:11:06 .fesco 2155 15:11:07 ignatenkobrain: Issue #2155: Non-responsive maintainer "bdpepple" for package "farstream02" - fesco - Pagure.io - https://pagure.io/fesco/issue/2155 15:11:09 https://pagure.io/fesco/issue/2155 15:11:15 I do find it a bit odd that the ticket is such a mess, but the devel list discussion was crickets 15:11:39 mhroncok, me, sgallagh were +1 in the ticket 15:11:45 +1 15:11:57 +1 15:12:10 +1 15:12:15 +1 15:12:17 +1 15:12:25 Somehow I missed this one originally. Technically our policy says this is rejected since it went two weeks without a +1... but obviously that was just a mistake 15:12:27 +1 15:12:49 Oh wait, mhroncok voted on it. 15:12:56 So this should have been approved at the 4-day mark 15:12:57 14 15:13:14 #agree APPROVED (+9, 0, -0) 15:13:23 sgallagh: yeah, let's try to do it better next time 15:13:30 ack 15:13:30 #topic #2162 F31 System-Wide Change: No more i686 kernels or bootable images 15:13:31 sorry for tagging it into meeting, will try to do better next time 15:13:33 .fesco 2162 15:13:35 ignatenkobrain: Issue #2162: F31 System-Wide Change: No more i686 kernels or bootable images - fesco - Pagure.io - https://pagure.io/fesco/issue/2162 15:13:37 https://pagure.io/fesco/issue/2162 15:13:56 so we approved it, but there is question 15:13:58 So, it seems like we agree to stop producing those images, but we're unclear on whether to compose the trees? 15:13:58 So the change was approved, but the discussion here is for the i686 repo 15:14:01 do we want to drop i686 compose or keep it 15:14:10 I would really like to drop it. ;) 15:14:16 yup 15:14:31 I am worried if we keep shipping it people will upgrade to it... and have then a old insecure kernel. 15:14:54 plus it seems a waste of our resources if there's no way to install it 15:15:01 what is our user story for i686 users? get a newer hardware? 15:15:11 My only concern was whether there were popular use cases where people could be installing packages from that repo on 64 bit systems. I spent some time looking and didn't see any 15:15:14 do we have possibility to build i686 packages in copr? 15:15:24 Do we care about producing 32-bit-only containers? 15:15:29 yeah buy something made in the last 10 years. 15:15:34 So I am good for dropping it 15:15:36 sgallagh: +1 15:15:47 sgallagh: I don't think so 15:15:47 bookwar: if we drop it, then not 15:15:51 contyk: That wasn't a proposal, it was a question :) 15:15:56 bookwar: if we drop our trees copr will probibly not work anymore for i686 15:16:00 sgallagh: I was just typing the same thing :) 15:16:05 heh 15:16:19 and yes, we can't make containers without a kernel I am pretty sure 15:16:28 (well, at least not without changing the way we make them) 15:16:35 I also wonder if there are use cases for i686 packages on 64bit systems, stuff that is not provided by multilib 15:16:47 in which case people might want to use the i686 repo 15:17:19 contyk: after looking, I didn't see much. And if there is a request to add something to multilib, that could be possible 15:17:26 Proposal: Do not ship composed public repositories for i*86 in Fedora 31+ 15:17:36 +1 15:17:38 +1 15:17:39 how does dropping the i686 compose impact building in i686 mock? does it mean we always need to enable the "local" repo? 15:17:41 I'm +1 15:17:42 I abstain 15:17:47 nirik: but multilib packages on copr will still be supported, does it mean someone could be able to rebuild i686package in copr as a "multilib one" in 64-bit buildroot? 15:17:49 mhroncok: yep. 15:18:01 +1 15:18:22 I'd rather get the mock maintainers on board before we decide this 15:18:31 bookwar: does copr support multilib at all now? I am not sure how... 15:18:42 I'm uncertain about this - I think that 32-bit builds should be "native" - not "cross builds" in a 64-bit system 15:18:49 nirik: i don't know, sorry, i was assuming 15:18:50 Yeah, me too. I feel like I don't have enough understanding of the impact to decide yet. 15:19:00 otaylor: they still would be 15:19:08 So if anyone wants to build a 32-bit package, they should have a 32-bit repository to build against with mock or a container 15:19:26 * mhroncok needs to reconnect internets, sorry 15:19:45 ... and we said that containers will not be available any more, so that only leaves mock. 15:19:49 So dropping repos seems like a big hassle if we still want to support the use case 15:19:50 so i feel like the use case we were looking for: i need to build custom 32-package for fedora, what do i do 15:19:52 well, containers I am pretty sure go away with kernel dropping 15:20:01 otaylor: I think the proposal was to drop the public repos and composes, not the koji arch 15:20:23 can someone explain to me how you build in mock without having the public repos / composes? 15:20:25 right, koji would still have a buildroot and build things for it. 15:20:29 * mhroncok is back 15:20:30 contyk: but people use the public composes for mock builds 15:20:37 mock could in theory point to the koji buildroot. 15:20:39 well, yeah, that would be just for our builds 15:20:44 not solving the mock or copr problems 15:21:00 is there a source repo for the koji buildroot? 15:21:24 not yet =( 15:21:30 not currently, but we have been asked to enable it. 15:21:37 and in fact we could/should. 15:21:49 I wonder what the mock experience for i686 is 15:22:02 without knowing that, I'm -1 15:22:31 well, it would stop working or need to point to koji... 15:23:11 I don't think it would be much burden on koji, as I suspect the number of people wanting to do that is... very very very very low 15:23:38 nirik: is there anything that would need to be done past changing the /etc/mock/fedora-31-i386.cfg 15:24:18 the koji repos are a bit different from the compose repos, though 15:24:24 that might not have a huge impact 15:24:27 I wouldn't think so...hum... ok, one thing... the koji repo doesn't have signed packages in it (although signed packages are available) 15:24:30 but it's worth noting 15:24:50 yeah, no multilib in koji buildroot repos, but... that doesn't matter here. ;) 15:25:41 and no filters; also probably no impact here 15:25:51 And I am assuming that copr could make a similar config change to point to the koji repos 15:25:59 * mhroncok has internet trouble, sorry about that 15:26:32 also no modules... and such things 15:27:27 I think if we want people to build i686 packages locally , we need to provide composes (without ISOs and such) 15:27:31 jforbes: sure, it already has the repo defined. 15:28:00 Going back a bit, what is the motiviation for dropping the composes? 15:28:00 do we want that? 15:28:02 ignatenkobrain: oy, good point - so how do you debug 32-bit build failures with things with modular buildrequires 15:28:15 nirik mentioned that we are afraid of people upgrading with the old kernel 15:28:17 and as long as we are not actually removing i686 as a whole, we need to support local mock builds 15:28:17 ignatenkobrain: I just don't think there is that much demand 15:28:30 Do we care about saving space on mirrors? 15:28:39 compose time? 15:28:40 zbyszek, we don't run them so we always care 15:28:42 Are there other reasons, like making the compose slimmer? 15:28:45 or is that parallel anyway? 15:28:45 zbyszek: upgrades, improve compose time/resources for things we care about more 15:29:08 it will help time/space/cpu cycles 15:29:23 Makes sense, thanks. 15:29:29 pungi gathers every i686 package from koji and makes repos and runs createrepo on them, etc... 15:29:39 I think the real question here is "Do we care if people can build i686 packages for any reason other than multilib"? 15:29:53 if we want people to keep building i686 packages locally, I think we need to keep compose around for some time until we get solution for things like building against modules 15:30:01 sgallagh: My answer is "no" 15:30:10 sgallagh: well, also "do we care if packagers can easily reproduce i686 build failures" 15:30:22 For the kernel issue, maybe we should add 'Obsoletes: kernel < ...' in the i686 fedora-obsoletes package? 15:30:28 packages can point to koji or use scratch builds no? 15:30:39 packagers 15:30:41 zbyszek: I don't see much point 15:30:41 we need a better multilib story, proobaly reducing the package set etc. - but I'm afraid that is mostly doable in F32 15:30:54 otaylor: actually this is not that bad because 32bit x86 is quite common. and if you run into 32bit issue, you can debug on armv7hl 15:31:02 nirik: it seems like pointing to koji does not work for the modular case 15:31:12 whats the modular case again? 15:31:31 nirik: I think he means "if I need content from a default stream to build against" 15:31:44 sgallagh: and also building 32bit modules locally as well 15:31:50 otaylor: But I *think* that stops being an issue with Ursa Prime, which contyk tells me will be in staging next week 15:31:53 sgallagh: that, but also, things in modules that hvae other modules as requirements 15:32:53 Dunno, I feel that if we drop the composes, it'd be hard to bring them back. So I'd prefer to be quite sure before taking that step. 15:32:57 otaylor: That would already require MBS, yes? 15:33:06 I.e. better to wait a bit, and wait for the dust to settle. 15:33:11 not just ursa prime 15:33:22 if we support local i686 builds, we need to support local module i686 builds 15:33:31 which means we need module composes for that arch at least 15:33:48 proposal: Keep i686 compose around for now and think how to handle this deprecation better 15:33:50 * sgallagh is still "Team kill-i686-with-fire" 15:33:59 ignatenkobrain: +1 15:34:05 sgallagh: I was thjinking about "hacking" by creating a local i386 environment with the right module streams enabled, then trying rebuilds 15:34:05 +1 15:34:06 But I've been beating that horse since around 2010, so... 15:34:10 sgallagh: I'm on that team, but there should be a strategy, really 15:34:14 well, I think we could do i686 modules and still not publish a i686 everything tree 15:34:17 sgallagh: we cannot kill it half way 15:34:42 IMHO Killing the i686 compose is a separate issue 15:34:54 separate change proposal is needed, separate announce on devel 15:34:56 then again, I may be overthinking this, it's not like i686 stuff breaks at build time very often, packagers will find a way, or ExcludeArch: i686 15:35:02 we are leaving the community out right now 15:35:13 mhroncok: +1 15:35:17 nirik: I know that we don't run repoclosure on modular content (though it would be nice). I would rather kill everything altogether, not by pieces 15:35:24 well, I discussed it in the kernel thread 15:35:39 OK, so let's take it back to the original problem. 15:35:42 well, we cannot kill everything i686 until the multilib holdouts go away 15:35:42 nirik: Anything 20-30 messages down a long thread is pretty much private :-) 15:35:49 if they don't care about the kernel, they haven't participated 15:35:56 mhroncok: actually, we kind of have to keep kill it half way. multilib will need to be a thing. Ubuntu tried to kill it completely and steam announced they were dropping support for them, ubuntu backtracked 15:36:05 nirik rightly notes that if we stop shipping the kernel, we realistically should not allow new installs/upgrades of i686 15:36:19 sure, I can be ok with making this seperate for f32 or whatever... makes me sad, but oh well. ;) 15:36:22 jforbes: yes, but we can plan and handle multilib case soemhow. this is nto it 15:36:33 Killing the compose has a variety of other benefits (particularly to compose time and mirrors), but it's not the sole way to solve that initial problem 15:36:34 sgallagh: we can't prevent it I don't think 15:36:43 nirik: I'd gladly consider this change for f31 as "late but wanted" 15:36:46 nirik: Sure we can. 15:37:08 it's not like we haven't approved changes post deadline earlier 15:37:11 Someone earlier suggested adding "Obsoletes: kernel" to the i686 version of fedora-obsolete-packages. 15:37:20 sgallagh: I bet you any weird conflicts/obsoletes/whatever you put in place, people will work around 15:37:20 sgallagh: I don't think we should not allow upgrades. installation is going away since there won't be a kernel anymore. 15:37:28 Which would have the effect of preventing upgrades, since DNF would refuse the transaction 15:37:46 except fedora-obsolete-packages isn't installed by default and they could just exclude it. 15:37:53 but anyhow... we are driving off... 15:38:06 I can try and put together a proposal... 15:38:25 ignatenkobrain: Then they're upgrading but stuck with a vulnerable kernel for who knows how long 15:38:37 ...forever. ;) 15:38:50 proposal #action nirik to put together a proposal how we can drop i686 composes 15:39:00 sgallagh: or tey will be on fedora 30 forever with vulnerable kernel and everything else as well 15:39:24 mhroncok: One of these things is more likely to get noticed by them and resolved manually 15:39:30 note that the kernel drop already drops some composes... ;) 15:39:32 I think we should consider nirik's proposal as a late exception and make it for F31 though 15:40:16 I'll try and do something on it this weekend, time permitting... 15:40:26 sgallagh: however "should we actively block i686 upgrades to F31 and further" is a valid question 15:40:36 jforbes: +1, it should be more like communicating the way forward for multilib packages 15:41:27 sgallagh: however if we indeed have another proposal from nirik, and we drop the composes, it get's autoresolved 15:41:29 mhroncok: I wonder if we could look into making cross-arch upgrades possible. Like, if they have compatible hardware, upgrade them to x86_64 15:41:29 So... since nirik agrees, I think we shoud accept ignatenkobrain's action proposal and move on. 15:41:41 ack 15:41:43 right. ack 15:41:45 ack 15:41:56 ack 15:42:02 #action nirik to put together a proposal how we can drop i686 15:42:15 sgallagh: I did a cross arch upgrade from FC1 32bit to FC1 64bit when I was porting it. It is a messy process 15:42:17 sgallagh: ask the dnf people? 15:42:36 jforbes: Let's take that offline 15:42:53 #agree Once proposal in place, we can consider it as a late exception for F31 15:42:55 let's move next 15:43:01 #topic #2149 Proposal to change non-responsive maintainer policy 15:43:04 .fesco 2149 15:43:06 ignatenkobrain: Issue #2149: Proposal to change non-responsive maintainer policy - fesco - Pagure.io - https://pagure.io/fesco/issue/2149 15:43:07 https://pagure.io/fesco/issue/2149 15:43:28 I'm good with the latest version (and three days) 15:43:48 I'm +1 FTR too. 15:43:50 I think the current proposal is good/better than what we have now. Do we want to get some community feedback before just changing it? 15:44:21 nirik: we asked on devel 15:44:24 I am also good with the latest including 3 days 15:44:26 zbyszek IIRC 15:44:37 +1 to the latest version including 3 days 15:44:38 * mhroncok looks 15:44:38 did we? ok, I misremembered. ;) 15:44:57 There is still a danger of abuse, but I think we can nip that in the bud if we see it. 15:45:03 tps://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/4RW4ZCKE6JJNAYO252ZP2WTY5LVZVAVZ/ 15:45:10 https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/4RW4ZCKE6JJNAYO252ZP2WTY5LVZVAVZ/ 15:45:22 +1 for three days 15:45:30 nirik: I think the obvious solution in the case of abuse is the revocation of privileges 15:45:36 yep. 15:45:45 2 weeks have passed, no reply to the thread 15:46:23 mhroncok: that's because nonresponsive maintainers don't read devel :) 15:46:29 hahaha 15:46:32 :D 15:46:38 heh 15:46:51 jforbes++ 15:46:51 So shall we go ahead and approve this, then? 15:47:17 yes, please, it's been going on for too long already 15:47:28 Getting packages back into active maintenance faster is a Good Thing 15:47:41 Anyone in opposition? 15:47:42 * nirik nods 15:47:44 Yes, let's approve it before it changes again :) 15:48:12 so let's vote then 15:48:18 just to be clear 15:48:37 we vote on the proposal with 3 days period 15:48:40 yes 15:48:42 +1 15:48:42 +1 15:48:44 +1 15:48:46 +1 15:48:51 +1 15:48:55 +1 15:48:56 +1 15:48:57 +1 15:49:04 +1 15:49:11 \o/ 15:49:14 Vote is unanimous \o/ 15:49:18 #agree APPROVED (+9, 0, -0) 15:49:27 #action zbyszek to prepare a PR 15:49:29 so we are getting to the last ticket :) 15:49:36 the easy one? 15:49:44 #topic #2146 Temporarily revert breaking module changes 15:49:44 (Quick, someone file more!) 15:49:45 .fesco 2146 15:49:46 https://pagure.io/fesco/issue/2146 15:49:47 ignatenkobrain: Issue #2146: Temporarily revert breaking module changes - fesco - Pagure.io - https://pagure.io/fesco/issue/2146 15:49:57 ... oh, right. This one. 15:50:05 mhroncok: the "easy" one :) 15:50:12 The One 15:50:41 I've tagged this with meeting, because while the discussion is long and emotional, we should really figure out what to do 1) right now and 2) long term 15:51:01 and I believe that the 2) is bikeshedding the 1) 15:51:02 * sgallagh thought he proposed a "right now" answer like two weeks ago 15:51:35 so right now we're not ready for modules changing deps and the long term answer is still being figured out 15:51:41 we won't do that here 15:52:28 Right, so our short term answer has to be "don't expect that to work" 15:52:50 what do we do with existing systems? 15:52:56 it seems that we have a solution/workaround ready, carlwgeorge waits to do it, but he was stopped "before the dicsussions finish" - however this will not finish soon 15:53:29 mhroncok: Where is that solution? 15:53:41 Oh right, the compat packages 15:53:41 contyk: we are also not ready for changing defaults between releases. 15:53:48 ignatenkobrain: Correct 15:54:58 #info compat packages proposal is in https://pagure.io/fesco/issue/2146#comment-576385, https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/P4XUEWEK33UQESIUJL3OLNGZLJYYXX7R/ 15:55:45 Is anyone against the "compat package" proposal as a temporary solutiNO? 15:55:52 solution? 15:55:55 no 15:56:19 no 15:56:20 zbyszek: will that solution correctly fix exisiting systems affected by this? 15:56:20 I'm +1 to the temporary solution. However, we need to figure out what to do with existing systems which have libgit2 module installed (since it is default one). 15:56:39 (I'm honestly no longer sure) 15:57:06 Can we push an update to the stream which nukes all packages from it? 15:57:16 ignatenkobrain: What's wrong with the current systems? 15:57:16 mhroncok: it won't 15:57:28 I.e. it would continue to be enabled, but just wouldn't carry anything. 15:57:31 sgallagh: they have libgit installed from the module 15:57:33 Let's drop the word "correctly" from that question, please. 15:57:42 sgallagh: sure, sorry, consider it dropped 15:57:44 It'll unnecessarily complicate the conversation 15:57:47 I don't think it would fix the problem 15:57:49 sgallagh: F30 has default libgit2:0.27, F31 has libgit2:0.28, upgrade is broken since packages now link against libgit2.so.28 15:57:56 DNF considers all available versions of the module 15:58:24 ignatenkobrain: I don't think that's a problem, since DNF would also see the non-modular RPMs that provide libgit2.so.2* 15:58:35 would it? 15:58:54 because it would get the RPM names from the non-latest module builds in the repo and mask the non-modular ones 15:58:54 As long as the modular RPM packages and the non-modular RPM packages have different names, sure. 15:58:56 sgallagh: DNF locks you to one stream, so it won't use non-modular libgit2 15:58:59 even though they're not in the latest version 15:59:18 it does so to allow for cherry-picking RPMs from within the stream 15:59:27 can the nonmodular libgit123 obsolete the modular libgit? 15:59:31 if the packages in the module are called "libgit2" and the non-modular ones are "libgit2_0.2*", they should still be in the transaction 15:59:38 mhroncok: Yes, in theory. 15:59:55 sgallagh: no, the non-modular packages have no suffix. 15:59:57 s/in/available to/ 16:00:00 * jcajka got unstuck from traffic, sorry if I have already missed it, I'm ready to answer any questions regarding Go 1.13, but will have to leave soonish again 16:00:08 I.e. the latest version of libgit2 is just called libgit2. 16:00:25 they would need to have a different name for that to work, yeah 16:00:35 jcajka: there is various questions asked in the ticket. We decided to continue the conversation there. 16:00:55 I have feeling that we need to just put in Upgrade Notes that users have to run `dnf module reset libgit2` or something like that 16:00:59 which would disable module 16:01:02 and then run dnf distro-sync 16:01:18 ignatenkobrain: is that upgrade to newer fedora, or usual dnf upgrade? 16:01:44 zbyszek: ack, thanks 16:01:47 * nirik had to step away for a min. reading back up. 16:02:03 mhroncok: upgrade to newer fedora. I think within one release, we should be more or less safe. 16:02:44 I'm is pretty sure I saw this issue during normal upgrades... but ignatenkobrain's solution would work there too. 16:03:56 OK. Proposal: accept the proposal to use compat packages for libgit2 and put 'dnf module reset ...' work-around in Common Bugs. 16:04:14 Isn't the issue only in rawhide? 16:04:51 I'll release tokei, bat and such module updates which will use non-modular libgit2, that will not break installations within one release and on release upgrade, you will need to do some extra work because we don't have support for changing defaults (/me sighs) 16:05:09 zbyszek: +1 16:05:28 zbyszek: +1 16:05:58 zbyszek: +1 16:06:09 ignatenkobrain: Sorry about this. We really are trying to figure out a better long-term solution, but there are a lot of moving parts involved. 16:06:30 zbyszek: +1 16:06:51 +1 I suppose... 16:07:13 +1 16:07:15 +1 16:07:30 bookwar: vote? 16:08:16 sgallagh, contyk: and as a followup, should we "temporarily" ban changing the dependency streams? 16:08:30 (or do we already do that?) 16:08:57 > Changing module dependencies within a stream is banned. 16:09:01 https://pagure.io/fesco/issue/2146#comment-580437 16:09:02 mhroncok: I don't know of a way to enforce it, which is how we got into this mess 16:09:24 zbyszek: thanks 16:09:56 #agree Accept the proposal to use compat packages for libgit2 and put 'dnf module reset …' work-around in Common Bugs. (+8, 0, -0) 16:10:03 sgallagh: I see 16:10:18 #topic Next week's chair 16:10:24