15:00:05 <ignatenkobrain> #startmeeting FESCO (2019-07-12)
15:00:05 <zodbot> Meeting started Fri Jul 12 15:00:05 2019 UTC.
15:00:05 <zodbot> This meeting is logged and archived in a public location.
15:00:05 <zodbot> The chair is ignatenkobrain. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:00:05 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
15:00:05 <zodbot> The meeting name has been set to 'fesco_(2019-07-12)'
15:00:11 <ignatenkobrain> #meetingname fesco
15:00:11 <zodbot> The meeting name has been set to 'fesco'
15:00:17 <zbyszek> .hello2
15:00:18 <ignatenkobrain> #chair nirik, ignatenkobrain, jforbes, zbyszek, bookwar, sgallagh, contyk, mhroncok, otaylor
15:00:18 <zodbot> Current chairs: bookwar contyk ignatenkobrain jforbes mhroncok nirik otaylor sgallagh zbyszek
15:00:18 <zodbot> zbyszek: zbyszek 'Zbigniew Jędrzejewski-Szmek' <zbyszek@in.waw.pl>
15:00:18 <ignatenkobrain> #topic init process
15:00:21 <contyk> .hello psabata
15:00:23 <jforbes> .hello2
15:00:24 <zodbot> contyk: psabata 'Petr Šabata' <psabata@redhat.com>
15:00:26 <nirik> .hello kevin
15:00:27 <zodbot> jforbes: jforbes 'Justin M. Forbes' <jforbes@redhat.com>
15:00:30 <zodbot> nirik: kevin 'Kevin Fenzi' <kevin@scrye.com>
15:00:38 <bookwar> .hello2
15:00:40 <zodbot> bookwar: bookwar 'Aleksandra Fedorova' <alpha@bookwar.info>
15:01:00 <sgallagh> .hello2
15:01:01 <zodbot> sgallagh: sgallagh 'Stephen Gallagher' <sgallagh@redhat.com>
15:01:26 <bcotton> .hello2
15:01:27 <zodbot> bcotton: bcotton 'Ben Cotton' <bcotton@redhat.com>
15:01:36 <mhroncok> hi
15:02:24 <ignatenkobrain> let's give otaylor few more minutes
15:02:40 * otaylor is here now
15:02:42 <otaylor> .hello2
15:02:43 <zodbot> otaylor: otaylor 'Owen Taylor' <otaylor@redhat.com>
15:03:08 <ignatenkobrain> cool, let's start
15:03:11 <ignatenkobrain> #topic #2166 F31 System-Wide Change: Python means Python 3
15:03:11 <ignatenkobrain> .fesco 2166
15:03:12 <zodbot> ignatenkobrain: Issue #2166: F31 System-Wide Change: Python means Python 3 - fesco - Pagure.io - https://pagure.io/fesco/issue/2166
15:03:13 <ignatenkobrain> https://pagure.io/fesco/issue/2166
15:03:44 <contyk> +1
15:03:55 <bookwar> i find fedora-devel discussion convincing enough, voted on the issue
15:03:56 <jforbes> Do, sorry. Thought I voted in ticket.
15:04:01 <jforbes> +1
15:04:03 <zbyszek> mhroncok, me, and bookwar votes in the ticket
15:04:09 <ignatenkobrain> I'm +1 on this, too
15:04:32 <sgallagh> I am +1 here also
15:04:38 <nirik> +1 as well
15:05:13 * nirik also was not for it before, but the discussion swayed me
15:05:24 <ignatenkobrain> otaylor: vote?
15:05:27 <otaylor> +1
15:05:35 <ignatenkobrain> cool
15:05:40 <mhroncok> thanks
15:05:53 <ignatenkobrain> #agree APPROVED (+8, 0, -0)
15:06:00 <ignatenkobrain> #topic #2165 F31 System-Wide Change: Golang 1.13
15:06:02 <ignatenkobrain> .fesco 2165
15:06:04 <zodbot> ignatenkobrain: Issue #2165: F31 System-Wide Change: Golang 1.13 - fesco - Pagure.io - https://pagure.io/fesco/issue/2165
15:06:15 <ignatenkobrain> https://pagure.io/fesco/issue/2165
15:07:12 <nirik> bookwar had some good questions here.
15:07:18 <sgallagh> I'm going to abstain here as I don't think I have a good grasp of the situation.
15:07:18 <zbyszek> 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 <mhroncok> here I don't understand the internal dispute between the go maintainers :(
15:07:46 <bookwar> mhroncok: me too
15:07:51 <ignatenkobrain> 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 <contyk> I'm +1 to the update in general but I'd be happier with a better plan and those questions addressed
15:09:09 <nirik> so, wait a week and ask for more info?
15:09:15 <nirik> (well, wait for answers)
15:09:23 <zbyszek> wfm.
15:09:33 <contyk> wfm as well
15:09:38 <mhroncok> ack
15:09:48 <ignatenkobrain> works for me
15:10:20 <ignatenkobrain> proposal: #agree Wait a week and get answers for questions in a ticket.
15:10:28 <zbyszek> ack
15:10:31 <contyk> ack
15:10:33 <jforbes> ack
15:10:34 <nirik> ack
15:10:36 <zbyszek> s/a ticket/the ticket/
15:10:40 <mhroncok> ack
15:11:00 <ignatenkobrain> #agree Wait a week and get answers for questions in the ticket
15:11:04 <ignatenkobrain> #topic #2155 Non-responsive maintainer "bdpepple" for package "farstream02"
15:11:06 <ignatenkobrain> .fesco 2155
15:11:07 <zodbot> ignatenkobrain: Issue #2155: Non-responsive maintainer "bdpepple" for package "farstream02" - fesco - Pagure.io - https://pagure.io/fesco/issue/2155
15:11:09 <ignatenkobrain> https://pagure.io/fesco/issue/2155
15:11:15 <jforbes> I do find it a bit odd that the ticket is such a mess, but the devel list discussion was crickets
15:11:39 <zbyszek> mhroncok, me, sgallagh were +1 in the ticket
15:11:45 <jforbes> +1
15:11:57 <contyk> +1
15:12:10 <nirik> +1
15:12:15 <otaylor> +1
15:12:17 <ignatenkobrain> +1
15:12:25 <sgallagh> 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 <bookwar> +1
15:12:49 <sgallagh> Oh wait, mhroncok voted on it.
15:12:56 <sgallagh> So this should have been approved at the 4-day mark
15:12:57 <sgallagh> 14
15:13:14 <ignatenkobrain> #agree APPROVED (+9, 0, -0)
15:13:23 <ignatenkobrain> sgallagh: yeah, let's try to do it better next time
15:13:30 <sgallagh> ack
15:13:30 <ignatenkobrain> #topic #2162 F31 System-Wide Change: No more i686 kernels or bootable images
15:13:31 <mhroncok> sorry for tagging it into meeting, will try to do better next time
15:13:33 <ignatenkobrain> .fesco 2162
15:13:35 <zodbot> 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 <ignatenkobrain> https://pagure.io/fesco/issue/2162
15:13:56 <ignatenkobrain> so we approved it, but there is question
15:13:58 <sgallagh> So, it seems like we agree to stop producing those images, but we're unclear on whether to compose the trees?
15:13:58 <jforbes> So the change was approved, but the discussion here is for the i686 repo
15:14:01 <ignatenkobrain> do we want to drop i686 compose or keep it
15:14:10 <nirik> I would really like to drop it. ;)
15:14:16 <ignatenkobrain> yup
15:14:31 <nirik> I am worried if we keep shipping it people will upgrade to it... and have then a old insecure kernel.
15:14:54 <nirik> plus it seems a waste of our resources if there's no way to install it
15:15:01 <mhroncok> what is our user story for i686 users? get a newer hardware?
15:15:11 <jforbes> 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 <bookwar> do we have possibility to build i686 packages in copr?
15:15:24 <sgallagh> Do we care about producing 32-bit-only containers?
15:15:29 <nirik> yeah buy something made in the last 10 years.
15:15:34 <jforbes> So I am good for dropping it
15:15:36 <contyk> sgallagh: +1
15:15:47 <jforbes> sgallagh: I don't think so
15:15:47 <ignatenkobrain> bookwar: if we drop it, then not
15:15:51 <sgallagh> contyk: That wasn't a proposal, it was a question :)
15:15:56 <nirik> bookwar: if we drop our trees copr will probibly not work anymore for i686
15:16:00 <contyk> sgallagh: I was just typing the same thing :)
15:16:05 <sgallagh> heh
15:16:19 <nirik> and yes, we can't make containers without a kernel I am pretty sure
15:16:28 <nirik> (well, at least not without changing the way we make them)
15:16:35 <contyk> I also wonder if there are use cases for i686 packages on 64bit systems, stuff that is not provided by multilib
15:16:47 <contyk> in which case people might want to use the i686 repo
15:17:19 <jforbes> 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 <sgallagh> Proposal: Do not ship composed public repositories for i*86 in Fedora 31+
15:17:36 <jforbes> +1
15:17:38 <nirik> +1
15:17:39 <mhroncok> 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 <sgallagh> I'm +1
15:17:42 <contyk> I abstain
15:17:47 <bookwar> 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 <nirik> mhroncok: yep.
15:18:01 <ignatenkobrain> +1
15:18:22 <mhroncok> I'd rather get the mock maintainers on board before we decide this
15:18:31 <nirik> bookwar: does copr support multilib at all now? I am not sure how...
15:18:42 <otaylor> 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 <bookwar> nirik: i don't know, sorry, i was assuming
15:18:50 <zbyszek> Yeah, me too. I feel like I don't have enough understanding of the impact to decide yet.
15:19:00 <nirik> otaylor: they still would be
15:19:08 <otaylor> 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 <zbyszek> ... and we said that containers will not be available any more, so that only leaves mock.
15:19:49 <otaylor> So dropping repos seems like a big hassle if we still want to support the use case
15:19:50 <bookwar> 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 <nirik> well, containers I am pretty sure go away with kernel dropping
15:20:01 <contyk> otaylor: I think the proposal was to drop the public repos and composes, not the koji arch
15:20:23 <otaylor> can someone explain to me how you build in mock without having the public repos / composes?
15:20:25 <nirik> right, koji would still have a buildroot and build things for it.
15:20:29 * mhroncok is back
15:20:30 <zbyszek> contyk: but people use the public composes for mock builds
15:20:37 <nirik> mock could in theory point to the koji buildroot.
15:20:39 <contyk> well, yeah, that would be just for our builds
15:20:44 <contyk> not solving the mock or copr problems
15:21:00 <mhroncok> is there a source repo for the koji buildroot?
15:21:24 <ignatenkobrain> not yet =(
15:21:30 <nirik> not currently, but we have been asked to enable it.
15:21:37 <nirik> and in fact we could/should.
15:21:49 <mhroncok> I wonder what the mock experience for i686 is
15:22:02 <mhroncok> without knowing that, I'm -1
15:22:31 <nirik> well, it would stop working or need to point to koji...
15:23:11 <nirik> 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 <jforbes> nirik: is there anything that would need to be done past changing the /etc/mock/fedora-31-i386.cfg
15:24:18 <contyk> the koji repos are a bit different from the compose repos, though
15:24:24 <contyk> that might not have a huge impact
15:24:27 <nirik> 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 <contyk> but it's worth noting
15:24:50 <nirik> yeah, no multilib in koji buildroot repos, but... that doesn't matter here. ;)
15:25:41 <contyk> and no filters; also probably no impact here
15:25:51 <jforbes> 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 <ignatenkobrain> also no modules... and such things
15:27:27 <ignatenkobrain> I think if we want people to build i686 packages locally , we need to provide composes (without ISOs and such)
15:27:31 <nirik> jforbes: sure, it already has the repo defined.
15:28:00 <zbyszek> Going back a bit, what is the motiviation for dropping the composes?
15:28:00 <nirik> do we want that?
15:28:02 <otaylor> ignatenkobrain: oy, good point - so how do you debug 32-bit build failures with things with modular buildrequires
15:28:15 <zbyszek> nirik mentioned that we are afraid of people upgrading with the old kernel
15:28:17 <mhroncok> and as long as we are not actually removing i686 as a whole, we need to support local mock builds
15:28:17 <jforbes> ignatenkobrain: I just don't think there is that much demand
15:28:30 <zbyszek> Do we care about saving space on mirrors?
15:28:39 <mhroncok> compose time?
15:28:40 <smooge> zbyszek, we don't run them so we always care
15:28:42 <zbyszek> Are there other reasons, like making the compose slimmer?
15:28:45 <mhroncok> or is that parallel anyway?
15:28:45 <nirik> zbyszek: upgrades, improve compose time/resources for things we care about more
15:29:08 <nirik> it will help time/space/cpu cycles
15:29:23 <zbyszek> Makes sense, thanks.
15:29:29 <nirik> pungi gathers every i686 package from koji and makes repos and runs createrepo on them, etc...
15:29:39 <sgallagh> 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 <ignatenkobrain> 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 <ignatenkobrain> sgallagh: My answer is "no"
15:30:10 <otaylor> sgallagh: well, also "do we care if packagers can easily reproduce i686 build failures"
15:30:22 <zbyszek> For the kernel issue, maybe we should add 'Obsoletes: kernel < ...' in the i686 fedora-obsoletes package?
15:30:28 <nirik> packages can point to koji or use scratch builds no?
15:30:39 <nirik> packagers
15:30:41 <jforbes> zbyszek: I don't see much point
15:30:41 <mhroncok> 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 <ignatenkobrain> 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 <otaylor> nirik: it seems like pointing to koji does not work for the modular case
15:31:12 <nirik> whats the modular case again?
15:31:31 <sgallagh> nirik: I think he means "if I need content from a default stream to build against"
15:31:44 <ignatenkobrain> sgallagh: and also building 32bit modules locally as well
15:31:50 <sgallagh> 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 <otaylor> sgallagh: that, but also, things in modules that hvae other modules as requirements
15:32:53 <zbyszek> 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 <sgallagh> otaylor: That would already require MBS, yes?
15:33:06 <zbyszek> I.e. better to wait a bit, and wait for the dust to settle.
15:33:11 <contyk> not just ursa prime
15:33:22 <contyk> if we support local i686 builds, we need to support local module i686 builds
15:33:31 <contyk> which means we need module composes for that arch at least
15:33:48 <ignatenkobrain> 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 <mhroncok> ignatenkobrain: +1
15:34:05 <otaylor> sgallagh: I was thjinking about "hacking" by creating a local i386 environment with the right module streams enabled, then trying rebuilds
15:34:05 <zbyszek> +1
15:34:06 <sgallagh> But I've been beating that horse since around 2010, so...
15:34:10 <mhroncok> sgallagh: I'm on that team, but there should be a strategy, really
15:34:14 <nirik> well, I think we could do i686 modules and still not publish a i686 everything tree
15:34:17 <mhroncok> sgallagh: we cannot kill it half way
15:34:42 <mhroncok> IMHO Killing the i686 compose is a separate issue
15:34:54 <mhroncok> separate change proposal is needed, separate announce on devel
15:34:56 <otaylor> 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 <mhroncok> we are leaving the community out right now
15:35:13 <bcotton> mhroncok: +1
15:35:17 <ignatenkobrain> 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 <nirik> well, I discussed it in the kernel thread
15:35:39 <sgallagh> OK, so let's take it back to the original problem.
15:35:42 <nirik> well, we cannot kill everything i686 until the multilib holdouts go away
15:35:42 <otaylor> nirik: Anything 20-30 messages down a long thread is pretty much private :-)
15:35:49 <mhroncok> if they don't care about the kernel, they haven't participated
15:35:56 <jforbes> 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 <sgallagh> nirik rightly notes that if we stop shipping the kernel, we realistically should not allow new installs/upgrades of i686
15:36:19 <nirik> sure, I can be ok with making this seperate for f32 or whatever... makes me sad, but oh well. ;)
15:36:22 <mhroncok> jforbes: yes, but we can plan and handle multilib case soemhow. this is nto it
15:36:33 <sgallagh> 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 <nirik> sgallagh: we can't prevent it I don't think
15:36:43 <mhroncok> nirik: I'd gladly consider this change for f31 as "late but wanted"
15:36:46 <sgallagh> nirik: Sure we can.
15:37:08 <mhroncok> it's not like we haven't approved changes post deadline earlier
15:37:11 <sgallagh> Someone earlier suggested adding "Obsoletes: kernel" to the i686 version of fedora-obsolete-packages.
15:37:20 <nirik> sgallagh: I bet you any weird conflicts/obsoletes/whatever you put in place, people will work around
15:37:20 <ignatenkobrain> 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 <sgallagh> Which would have the effect of preventing upgrades, since DNF would refuse the transaction
15:37:46 <nirik> except fedora-obsolete-packages isn't installed by default and they could just exclude it.
15:37:53 <nirik> but anyhow... we are driving off...
15:38:06 <nirik> I can try and put together a proposal...
15:38:25 <sgallagh> ignatenkobrain: Then they're upgrading but stuck with a vulnerable kernel for who knows how long
15:38:37 <nirik> ...forever. ;)
15:38:50 <ignatenkobrain> proposal #action nirik to put together a proposal how we can drop i686 composes
15:39:00 <mhroncok> sgallagh: or tey will be on fedora 30 forever with vulnerable kernel and everything else as well
15:39:24 <sgallagh> mhroncok: One of these things is more likely to get noticed by them and resolved manually
15:39:30 <nirik> note that the kernel drop already drops some composes... ;)
15:39:32 <jforbes> I think we should consider nirik's proposal as a late exception and make it for F31 though
15:40:16 <nirik> I'll try and do something on it this weekend, time permitting...
15:40:26 <mhroncok> sgallagh: however "should we actively block i686 upgrades to F31 and further" is a valid question
15:40:36 <bookwar> jforbes: +1, it should be more like communicating the way forward for multilib packages
15:41:27 <mhroncok> sgallagh: however if we indeed have another proposal from nirik, and we drop the composes, it get's autoresolved
15:41:29 <sgallagh> 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 <zbyszek> So... since nirik agrees, I think we shoud accept ignatenkobrain's action proposal and move on.
15:41:41 <sgallagh> ack
15:41:43 <nirik> right. ack
15:41:45 <mhroncok> ack
15:41:56 <contyk> ack
15:42:02 <ignatenkobrain> #action nirik to put together a proposal how we can drop i686
15:42:15 <jforbes> 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 <mhroncok> sgallagh: ask the dnf people?
15:42:36 <sgallagh> jforbes: Let's take that offline
15:42:53 <ignatenkobrain> #agree Once proposal in place, we can consider it as a late exception for F31
15:42:55 <ignatenkobrain> let's move next
15:43:01 <ignatenkobrain> #topic #2149 Proposal to change non-responsive maintainer policy
15:43:04 <ignatenkobrain> .fesco 2149
15:43:06 <zodbot> ignatenkobrain: Issue #2149: Proposal to change non-responsive maintainer policy - fesco - Pagure.io - https://pagure.io/fesco/issue/2149
15:43:07 <ignatenkobrain> https://pagure.io/fesco/issue/2149
15:43:28 <sgallagh> I'm good with the latest version (and three days)
15:43:48 <zbyszek> I'm +1 FTR too.
15:43:50 <nirik> 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 <mhroncok> nirik: we asked on devel
15:44:24 <jforbes> I am also good with the latest including 3 days
15:44:26 <mhroncok> zbyszek IIRC
15:44:37 <ignatenkobrain> +1 to the latest version including 3 days
15:44:38 * mhroncok looks
15:44:38 <nirik> did we? ok, I misremembered. ;)
15:44:57 <nirik> There is still a danger of abuse, but I think we can nip that in the bud if we see it.
15:45:03 <mhroncok> tps://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/4RW4ZCKE6JJNAYO252ZP2WTY5LVZVAVZ/
15:45:10 <mhroncok> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/4RW4ZCKE6JJNAYO252ZP2WTY5LVZVAVZ/
15:45:22 <bookwar> +1 for three days
15:45:30 <sgallagh> nirik: I think the obvious solution in the case of abuse is the revocation of privileges
15:45:36 <nirik> yep.
15:45:45 <mhroncok> 2 weeks have passed, no reply to the thread
15:46:23 <jforbes> mhroncok: that's because nonresponsive maintainers don't read devel :)
15:46:29 <sgallagh> hahaha
15:46:32 <mhroncok> :D
15:46:38 <nirik> heh
15:46:51 <bcotton> jforbes++
15:46:51 <sgallagh> So shall we go ahead and approve this, then?
15:47:17 <zbyszek> yes, please, it's been going on for too long already
15:47:28 <sgallagh> Getting packages back into active maintenance faster is a Good Thing
15:47:41 <sgallagh> Anyone in opposition?
15:47:42 * nirik nods
15:47:44 <jforbes> Yes, let's approve it before it changes again :)
15:48:12 <ignatenkobrain> so let's vote then
15:48:18 <mhroncok> just to be clear
15:48:37 <mhroncok> we vote on the proposal with 3 days period
15:48:40 <sgallagh> yes
15:48:42 <jforbes> +1
15:48:42 <mhroncok> +1
15:48:44 <zbyszek> +1
15:48:46 <sgallagh> +1
15:48:51 <nirik> +1
15:48:55 <contyk> +1
15:48:56 <otaylor> +1
15:48:57 <ignatenkobrain> +1
15:49:04 <bookwar> +1
15:49:11 <mhroncok> \o/
15:49:14 <sgallagh> Vote is unanimous \o/
15:49:18 <ignatenkobrain> #agree APPROVED (+9, 0, -0)
15:49:27 <zbyszek> #action zbyszek to prepare a PR
15:49:29 <ignatenkobrain> so we are getting to the last ticket :)
15:49:36 <mhroncok> the easy one?
15:49:44 <ignatenkobrain> #topic #2146 Temporarily revert breaking module changes
15:49:44 <sgallagh> (Quick, someone file more!)
15:49:45 <ignatenkobrain> .fesco 2146
15:49:46 <ignatenkobrain> https://pagure.io/fesco/issue/2146
15:49:47 <zodbot> ignatenkobrain: Issue #2146: Temporarily revert breaking module changes - fesco - Pagure.io - https://pagure.io/fesco/issue/2146
15:49:57 <sgallagh> ... oh, right. This one.
15:50:05 <ignatenkobrain> mhroncok: the "easy" one :)
15:50:12 <bookwar> The One
15:50:41 <mhroncok> 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 <mhroncok> 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 <contyk> so right now we're not ready for modules changing deps and the long term answer is still being figured out
15:51:41 <contyk> we won't do that here
15:52:28 <sgallagh> Right, so our short term answer has to be "don't expect that to work"
15:52:50 <ignatenkobrain> what do we do with existing systems?
15:52:56 <mhroncok> 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 <sgallagh> mhroncok: Where is that solution?
15:53:41 <sgallagh> Oh right, the compat packages
15:53:41 <ignatenkobrain> contyk: we are also not ready for changing defaults between releases.
15:53:48 <sgallagh> ignatenkobrain: Correct
15:54:58 <zbyszek> #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 <zbyszek> Is anyone against the "compat package" proposal as a temporary solutiNO?
15:55:52 <zbyszek> solution?
15:55:55 <sgallagh> no
15:56:19 <jforbes> no
15:56:20 <mhroncok> zbyszek: will that solution correctly fix exisiting systems affected by this?
15:56:20 <ignatenkobrain> 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 <mhroncok> (I'm honestly no longer sure)
15:57:06 <zbyszek> Can we push an update to the stream which nukes all packages from it?
15:57:16 <sgallagh> ignatenkobrain: What's wrong with the current systems?
15:57:16 <ignatenkobrain> mhroncok: it won't
15:57:28 <zbyszek> I.e. it would continue to be enabled, but just wouldn't carry anything.
15:57:31 <mhroncok> sgallagh: they have libgit installed from the module
15:57:33 <sgallagh> Let's drop the word "correctly" from that question, please.
15:57:42 <mhroncok> sgallagh: sure, sorry, consider it dropped
15:57:44 <sgallagh> It'll unnecessarily complicate the conversation
15:57:47 <contyk> I don't think it would fix the problem
15:57:49 <ignatenkobrain> 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 <contyk> DNF considers all available versions of the module
15:58:24 <sgallagh> 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 <contyk> would it?
15:58:54 <contyk> 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 <sgallagh> As long as the modular RPM packages and the non-modular RPM packages have different names, sure.
15:58:56 <ignatenkobrain> sgallagh: DNF locks you to one stream, so it won't use non-modular libgit2
15:58:59 <contyk> even though they're not in the latest version
15:59:18 <contyk> it does so to allow for cherry-picking RPMs from within the stream
15:59:27 <mhroncok> can the nonmodular libgit123 obsolete the modular libgit?
15:59:31 <sgallagh> 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 <sgallagh> mhroncok: Yes, in theory.
15:59:55 <zbyszek> sgallagh: no, the non-modular packages have no suffix.
15:59:57 <sgallagh> 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 <zbyszek> I.e. the latest version of libgit2 is just called libgit2.
16:00:25 <contyk> they would need to have a different name for that to work, yeah
16:00:35 <zbyszek> jcajka: there is various questions asked in the ticket. We decided to continue the conversation there.
16:00:55 <ignatenkobrain> 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 <ignatenkobrain> which would disable module
16:01:02 <ignatenkobrain> and then run dnf distro-sync
16:01:18 <mhroncok> ignatenkobrain: is that upgrade to newer fedora, or usual dnf upgrade?
16:01:44 <jcajka> zbyszek: ack, thanks
16:01:47 * nirik had to step away for a min. reading back up.
16:02:03 <ignatenkobrain> mhroncok: upgrade to newer fedora. I think within one release, we should be more or less safe.
16:02:44 <zbyszek> I'm is pretty sure I saw this issue during normal upgrades... but ignatenkobrain's solution would work there too.
16:03:56 <zbyszek> OK. Proposal: accept the proposal to use compat packages for libgit2 and put 'dnf module reset ...' work-around in Common Bugs.
16:04:14 <nirik> Isn't the issue only in rawhide?
16:04:51 <ignatenkobrain> 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 <ignatenkobrain> zbyszek: +1
16:05:28 <sgallagh> zbyszek: +1
16:05:58 <otaylor> zbyszek: +1
16:06:09 <sgallagh> 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 <jforbes> zbyszek: +1
16:06:51 <nirik> +1 I suppose...
16:07:13 <contyk> +1
16:07:15 <mhroncok> +1
16:07:30 <ignatenkobrain> bookwar: vote?
16:08:16 <mhroncok> sgallagh, contyk: and as a followup, should we "temporarily" ban changing the dependency streams?
16:08:30 <mhroncok> (or do we already do that?)
16:08:57 <zbyszek> > Changing module dependencies within a stream is banned.
16:09:01 <zbyszek> https://pagure.io/fesco/issue/2146#comment-580437
16:09:02 <sgallagh> mhroncok: I don't know of a way to enforce it, which is how we got into this mess
16:09:24 <mhroncok> zbyszek: thanks
16:09:56 <ignatenkobrain> #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 <mhroncok> sgallagh: I see
16:10:18 <ignatenkobrain> #topic Next week's chair
16:10:24 <ignatenkobrain> I can do next week (which is technically in more than a week)
16:10:41 <zbyszek> sgallagh: is this rule documented somewhere btw?
16:10:52 <ignatenkobrain> sgallagh: it is 22nd of Jul 15:00 UTC, right?
16:11:09 <zbyszek> ignatenkobrain: yes
16:11:33 <mhroncok> I can chair
16:12:12 <ignatenkobrain> mhroncok: you can or you would like to? :)
16:12:52 <bcotton> FYI: I'll be on PTO next week, so no change processing will happen. but you're not meeting next week, so you won't miss it :-)
16:13:09 <sgallagh> zbyszek: I think asamalik added it to the docs a couple weeks ago. Let me check
16:13:40 <jforbes> bcotton: me too
16:14:04 <mhroncok> bcotton: if nirik proposes the i686 change, can we process it instead of you to speed things up?
16:14:15 <bcotton> mhroncok: yep
16:14:46 <nirik> I guess we can move ahead with the kernel part? or wait?
16:14:55 <sgallagh> zbyszek: OK, I'm having trouble finding it, which means it's insufficiently documented.
16:14:57 <mhroncok> nirik: we can move ahead
16:15:00 <sgallagh> I'll work with asamalik to resolve that
16:15:13 <jforbes> No reason to wait on that point, it is a separate change and approved.
16:15:21 <ignatenkobrain> #action ignatenkobrain will chair next meeting
16:15:24 <ignatenkobrain> #topic Open Floor
16:15:25 <nirik> jforbes: do coordinate with releng when you do the kernel side of things. :)
16:15:45 <mhroncok> ignatenkobrain: BTW please close announced tickets after you post the fesco agenda
16:15:58 <jforbes> nirik: I already updated the ticket and told them it was approved, we will disable the build once they verify the scripts have been changed
16:16:03 <ignatenkobrain> mhroncok: ack
16:16:12 <nirik> right. I saw, just noting...
16:16:55 <mhroncok> zbyszek: I saw you updated the meeting wiki - let's change the day as well?
16:17:09 <zbyszek> Oh, right. I'll do that now.
16:17:32 <ignatenkobrain> yup, now we will have Monday's FESCo meeting :)
16:17:38 <ignatenkobrain> so, anyone has anything else to discuss?
16:17:54 <sgallagh> Nothing from me.
16:18:02 <sgallagh> Oh, wait. Actually one small note.
16:18:29 <sgallagh> I'm probably going to try to kick off a new Fedora Server PRD rewrite around Flock.
16:18:41 <sgallagh> The one we have is entirely out of date and basically worthless
16:19:33 <sgallagh> (Nothing to discuss here, just mentioning it to make people aware)
16:20:09 <ignatenkobrain> cool
16:20:10 <ignatenkobrain> sgallagh++
16:20:28 <zbyszek> ignatenkobrain: note that the date in "post meeting" on the wiki is now incorrect
16:21:09 <ignatenkobrain> zbyszek: yeah
16:21:19 <ignatenkobrain> I'll close this in 10 seconds then if nobody speaks up
16:21:52 <ignatenkobrain> #endmeeting