16:01:05 <adamw> #startmeeting F31-blocker-review
16:01:05 <zodbot> Meeting started Mon Oct 14 16:01:05 2019 UTC.
16:01:05 <zodbot> This meeting is logged and archived in a public location.
16:01:05 <zodbot> The chair is adamw. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:01:05 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:01:05 <zodbot> The meeting name has been set to 'f31-blocker-review'
16:01:06 <adamw> #meetingname F31-blocker-review
16:01:06 <zodbot> The meeting name has been set to 'f31-blocker-review'
16:01:06 <adamw> #topic Roll Call
16:01:15 <adamw> morning folks, who's here for blocker review fun?
16:01:24 <lruzicka2> .hello lruzicka
16:01:26 <zodbot> lruzicka2: lruzicka 'Lukáš Růžička' <lruzicka@redhat.com>
16:01:33 <kparal> .hello2
16:01:34 <zodbot> kparal: kparal 'Kamil Páral' <kparal@redhat.com>
16:01:44 <coremodule> .hello2
16:01:46 <zodbot> coremodule: coremodule 'Geoffrey Marr' <gmarr@redhat.com>
16:01:55 <coremodule> love me some monday morning fun
16:02:07 * coremodule will secretarialize.
16:03:12 <cmurf> .hello chrismurphy
16:03:13 <zodbot> cmurf: chrismurphy 'Chris Murphy' <bugzilla@colorremedies.com>
16:03:14 * cmurf is lurking
16:03:35 <frantisekz> .hello2
16:03:36 <zodbot> frantisekz: frantisekz 'František Zatloukal' <fzatlouk@redhat.com>
16:04:13 <kalev> .hello2
16:04:13 <zodbot> kalev: kalev 'Kalev Lember' <klember@redhat.com>
16:04:25 <adamw> hi everyone
16:04:31 <frantisekz> hi
16:05:14 <adamw> alrighty then, impending boilerplate alert
16:05:21 <adamw> #chair cmurf kparal
16:05:21 <zodbot> Current chairs: adamw cmurf kparal
16:05:27 <adamw> #topic Introduction
16:05:28 <adamw> Why are we here?
16:05:28 <adamw> #info Our purpose in this meeting is to review proposed blocker and nice-to-have bugs and decide whether to accept them, and to monitor the progress of fixing existing accepted blocker and nice-to-have bugs.
16:05:28 <adamw> #info We'll be following the process outlined at:
16:05:30 <adamw> #link https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting
16:05:31 <adamw> #info The bugs up for review today are available at:
16:05:33 <adamw> #link http://qa.fedoraproject.org/blockerbugs/current
16:05:34 <cmurf> let's play DONKEY KONG
16:05:35 <adamw> #info The criteria for release blocking bugs can be found at:
16:05:37 <adamw> #link https://fedoraproject.org/wiki/Basic_Release_Criteria
16:05:39 <adamw> #link https://fedoraproject.org/wiki/Fedora_31_Beta_Release_Criteria
16:05:41 <adamw> #link https://fedoraproject.org/wiki/Fedora_31_Final_Release_Criteria
16:05:43 <adamw> #info for F31 Final, we have:
16:05:48 <adamw> #info 4 Proposed Blockers
16:05:48 <adamw> #info 4 Accepted Blockers
16:05:52 <adamw> #info 2 Proposed Freeze Exceptions
16:05:52 <adamw> #info 3 Accepted Freeze Exceptions
16:06:04 * adamw starts rolling barrels
16:06:17 <adamw> #info coremodule will secretarialize
16:06:36 <adamw> so since it's a holiday and i'm not even supposed to BE here today, without further ado, let's start with proposed blockers
16:06:36 <coremodule> is that slang for something nefarious?
16:06:50 <adamw> coremodule: i was following the donkey kong idea
16:06:56 <adamw> so i mean...i guess yes, it is nefarious?
16:07:02 <coremodule> ah, so yes, very nefarious!
16:07:07 <adamw> #info let's start with proposed Final blockers
16:07:13 <adamw> #topic (1761484) Update appstream-data after final freeze
16:07:13 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1761484
16:07:13 <adamw> #info Proposed Blocker, appstream-data, ON_QA
16:08:08 <adamw> so, this is kinda established by now
16:08:17 <adamw> viz https://pagure.io/fesco/issue/1858#comment-506261
16:08:34 <adamw> we should just accept this and move on. actually we should probably add it to the automatic blockers.
16:08:39 <adamw> anyway, +1.
16:08:50 <coremodule> sounds good, +1
16:09:00 <frantisekz> +1
16:09:21 <lruzicka2> +1 when Fesco says
16:11:29 <adamw> proposed #agreed 1761484 - AcceptedBlocker (Final) - this is accepted per precedent from the last few releases and the FESCo ticket. We will look at treating it as an automatic blocker for future releases
16:11:38 <kparal> ack
16:11:45 <lruzicka2> ack
16:11:48 <frantisekz> ack
16:11:48 <coremodule> ack
16:11:49 <kalev> ack
16:13:02 <adamw> #agreed 1761484 - AcceptedBlocker (Final) - this is accepted per precedent from the last few releases and the FESCo ticket. We will look at treating it as an automatic blocker for future releases
16:13:08 <adamw> #topic (1760937) dnf-yum in F30 is now higher versioned than F31+ yum's "Obsoletes" (affects upgrades)
16:13:08 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1760937
16:13:08 <adamw> #info Proposed Blocker, dnf, NEW
16:13:35 <coremodule> +1 blocker
16:14:18 <kalev> not sure this should be a GA blocker, a post-GA update would suffice I think
16:14:29 <kalev> but +1 FE, definitely, to ease testing
16:14:38 <kparal> "In the past we've blocked on upgrade issues that can only be bypasses by using --allowerasing" -- I'd just like to note that while that might be true, we've also rejected many upgraded that required --allowerasing. That option was always considered necessary in certain cases and not inherently a blocker.
16:15:00 <frantisekz> +1 FE , -1 Blocker
16:15:03 <kparal> *many upgrades
16:15:21 <cmurf> what's the solution?
16:15:29 <kparal> normally I'd be -1 blocker unless something breaks, but I'm very wary about doing it for dnf
16:15:36 <lruzicka2> +1 FE, can be easily workarounded
16:15:54 <frantisekz> dnf writes you to use --allowerasing
16:16:03 <frantisekz> gnome software just does that if it's needed
16:16:17 * kalev nods.
16:16:18 <frantisekz> (I am not sure about other upgrade tools, especially on KDE/XFCE)
16:16:31 <kalev> I don't think there are any KDE/XFCE upgrade tools
16:16:36 <frantisekz> oh... :D
16:16:45 <adamw> kparal: when did we reject a case like this?
16:16:52 <lruzicka2> kalev, dnfdragora?
16:17:06 <frantisekz> lruzicka2: I don't think that supports upgrade
16:17:06 <kalev> lruzicka2: can it do F30 to F31 upgrades?
16:17:12 <adamw> i don't like saying 'oh just use --allowerasing' because if there are *other* issues in the upgrade it can very easily destroy your system
16:17:26 <kparal> adamw: I don't have an example handy. but I remember very clearly that --allowerasing was considered to be a standard way forward, especially before we had a meta package to obsolete old packages
16:17:37 <lruzicka2> adamw, true, if you do not look into the messages
16:17:46 <adamw> the recommended upgrade tool for all fedora upgrades is dnf except for Workstation, where gnome-software is recommended.
16:18:10 <frantisekz> also, this can be fixed post release pretty easily
16:18:21 <lruzicka2> adamw, but if you do look into the messages, then you should be all right
16:18:29 <adamw> lruzicka: if you understand them, sure
16:18:38 <kparal> we could say that allowerasing must not be necessary of default installation packages or something like that. but it's a moving target, changing with every repo push
16:19:26 <lruzicka2> most conservativelly, it should be able to upgrade without allowerasing and we should strive for that, but I dont think this idea finds much support.
16:19:37 <lruzicka2> kparal, ^
16:19:47 <adamw> kparal: default install packages is obviously already required as that's what the criterion says.
16:19:49 <kparal> I guess I'd be +1 for requiring dnf to follow upgrade path, because it's the damn upgrade tool and we want to avoid all risks. But I don't think we have a precedence for this
16:20:02 <adamw> dnf-yum appears to be included in all the blocking package sets for f30, afaict.
16:20:13 <frantisekz> (or... adamw, you can get on your proven packager hat and just update dnf in dist-git/f31 and fix it right away :) )
16:20:30 <adamw> i'm not sure i'm actually allowed to build dnf, it may be on the Super Restricted list. but i don't recall
16:20:31 <kparal> adamw: the criterion doesn't speak about allowerasing at all
16:20:48 <kalev> I'm happy to do the proven packager fix if required, I don't think it's on the super restricted list
16:20:57 <adamw> kparal: no, that part is just about our interpretation and precedent
16:21:09 <adamw> kalev: i can do it easily enough, i just wanted dnf team to have a look at it first.
16:21:12 * kalev nods.
16:21:32 <kparal> adamw: ok. I'm just saying I quite remember a different interpretation in the past. I'm happy to talk about adjusting it
16:21:34 <frantisekz> but, I was talking with dnf guys last week and it seems it might be intentional to have older dnf in f31... so, just changing obsoletes/provides version in spec would do the trick
16:21:38 <kalev> yeah; probably best if the dnf team fixes it so they realize they need to bump the obsoletes next time F30 dnf gets an update
16:21:56 <adamw> hmm
16:21:58 <adamw> note this footnote
16:21:58 <adamw> "The upgraded system must include all packages that would be present on the system after a default installation from install media, plus any packages the user previously had (minus any obsolete content)."
16:22:04 <adamw> arguably that is not met if you use --allowerasing
16:22:10 <adamw> because you lose dnf-yum and do not get yum
16:22:23 <frantisekz> hmm
16:22:38 <coremodule> I think that criterion does it for me
16:22:57 <adamw> hah
16:22:58 <coremodule> *footnote
16:23:03 <frantisekz> but under that criterion, anything that gets intentionally retired/removed/obsoleted would mean we block on that
16:23:07 <lruzicka2> in the light of this criterion, +1 Blocker
16:23:15 <frantisekz> don't if that ever happened though
16:23:15 <adamw> this has also just caused me to notice that f31 comps has package 'dnf-yum' as 'mandatory' in the @core group...
16:23:27 <kparal> frantisekz: no, "minus the obsolete content"
16:23:31 <adamw> frantisekz: no it wouldn't, note "minus any obsolete content"
16:23:34 <frantisekz> oh, thanks
16:23:40 <adamw> but this is more a rename than an obsolete
16:23:57 <kparal> adamw: ok, I guess we can use this explanation, even though it's bit on the edge
16:24:38 <kparal> I would also rather block on this, but that's just because I don't like the idea of possibly downgrading dnf in the upgraded system
16:25:09 <kparal> if it was gnome-calculator, I wouldn't care at all, as long as it works
16:25:11 <frantisekz> kparal, you would get dnf downgrade anyway
16:25:32 <kparal> frantisekz: even after we fix this?
16:25:49 <frantisekz> yeah, jmracek said it was probably intentional to have older dnf in f31
16:26:03 <frantisekz> so I am assuming fix is going to be only obsoletes/provides change
16:26:18 <kparal> hmm
16:26:35 <kparal> ok, so this is only about losing dnf-yum
16:26:36 <frantisekz> don't ask me why... :D
16:26:50 <kparal> which is just a /usr/bin/yum symlinked to /usr/bin/dnf, right?
16:26:57 <frantisekz> it isn't in f30
16:27:01 <frantisekz> it is in f31
16:27:15 <kparal> it is a symlink in F30
16:27:19 <frantisekz> or... I am not sure about the binary itself
16:27:23 <kparal> I'm looking at it :)
16:27:23 <adamw> you know, now i'm wondering if we actually meant to have dnf-yum included in all installs for every release since f22 in the first place
16:27:27 <adamw> this is a whole can o' fun!
16:27:28 <lruzicka2> I think when your system is already upgraded, you will not have to downgrade dnf ... why?
16:27:39 <frantisekz> but yum libraries were actually yum in f30 when I used it
16:27:47 <adamw> yum contains /usr/bin/yum which is a symlink to /usr/bin/dnf-3
16:28:09 <adamw> which is not the same as /usr/bin/dnf  , i believe it has a more old-dnf / yum-y syntax
16:28:27 <adamw> /usr/bin/dnf-3 is part of package python3-dnf
16:28:41 <kparal> $ rpm -ql dnf-yum
16:28:45 <adamw> lruzicka: upgrades are distro-sync operations by default
16:28:45 <frantisekz> (or, I might be mixing that up with something I got installed while working on file_conflicts script and I used --releasever=29 a few times)
16:28:58 <adamw> lruzicka: which means they will prefer f31 packages over f30 even if the f30 package is newer
16:29:12 <kparal> sigh, my paste failed. never mind
16:29:21 <adamw> can everyone just revote and we'll move on?
16:29:24 <lruzicka2> adamw, I just realized I do not have dnf-yum nor yum on my F31 installation
16:29:31 <adamw> we've talked it out enough i think
16:29:34 <adamw> lruzicka: yes, this is because of the comps thing
16:29:41 <adamw> comps wants to pull in dnf-yum, which doesn't exist any more
16:29:48 <adamw> when the package was renamed someone should have updated comps, but no-one does
16:29:50 <adamw> did*
16:29:55 <adamw> i'll send a PR for that
16:29:56 <lruzicka2> adamw, and dnf seems to be working normally
16:30:06 <adamw> yes
16:30:13 <kparal> I don't know how to vote now. someone tell me :)
16:30:16 <adamw> you don't need the yum compat bits for dnf to work
16:30:17 <frantisekz> anyhow, I still feel like -1 Blocker, +1 FE
16:30:27 <adamw> but we clearly intended to have the yum compat bits installed by default
16:30:39 <adamw> at least, back in f22 we intended that and no-one changed it afterwards, and then it broke
16:30:55 <adamw> kparal: toss a coin!
16:31:00 <lruzicka2> well, if there is the intention, I am +1 Blocker, although I seem to be incompatible and I do not mind it. Some folks might.
16:31:08 <lruzicka2> +1B
16:31:23 <coremodule> I am +1 blocker based on the stated footnote
16:31:23 * kparal grabs a two-face coin
16:31:39 <lruzicka2> kparal, pick a coin with both sides same
16:32:55 <kparal> I'm rather +1 with adamw's criterion breakdown explanation
16:34:15 <kalev> +1 blocker from me as well then
16:34:26 <adamw> proposed #agreed 1760937 - AcceptedBlocker (Final) - this is a close call, but we accept it as a blocker as a violation of the Beta upgrade criterion, referencing the footnote "The upgraded system must include all packages that would be present on the system after a default installation from install media, plus any packages the user previously had (minus any obsolete content)"
16:34:38 <frantisekz> sad ack :/ :D
16:34:42 <kparal> ack
16:35:38 <lruzicka2> ack
16:35:38 <coremodule> ack
16:36:44 <adamw> #agreed 1760937 - AcceptedBlocker (Final) - this is a close call, but we accept it as a blocker as a violation of the Beta upgrade criterion, referencing the footnote "The upgraded system must include all packages that would be present on the system after a default installation from install media, plus any packages the user previously had (minus any obsolete content)"
16:36:46 <kalev> ack
16:36:54 <adamw> #topic (1758588) dnf system-upgrade reboot fails due to depresolv difference with download
16:36:54 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1758588
16:36:54 <adamw> #info Proposed Blocker, dnf-plugins-extras, MODIFIED
16:37:03 * kalev afks for dinner. Back in 15 minutes.
16:37:12 <frantisekz> +1 Blocker
16:37:25 <adamw> i'm actually -1 on this as i'm not aware of any case of it affecting a default package set
16:37:32 <frantisekz> (not sure about what basis though)
16:37:35 <adamw> note FE makes no sense for this bug as the fix goes to f29 and f30, not f31
16:37:50 <adamw> so if accepted it would be an AcceptedPreviousReleaseBlocker
16:38:02 <frantisekz> hmm, I think I can live with FE too
16:38:13 <frantisekz> I'll make sure fix gets into stable in time
16:38:41 <lruzicka2> Seems that BZ discutees are also -1
16:39:23 <kparal> so is it now necessary to add --releasever=31 to system-upgrade reboot, or not?
16:40:01 <lruzicka2> however we need to have the fix, too, for future upgrades of 31
16:40:13 <lruzicka2> so it not only will go into 29 and 30
16:40:25 <lruzicka2> but 31, too
16:40:30 <adamw> yes, but going into 31 is not urgent at all
16:40:34 <adamw> so no justification for an FE
16:40:53 <adamw> kparal: i don't think that relates to this bug, but it shouldn't be necessary afaik.
16:41:13 <lruzicka2> adamw, how do we make sure, the fix arrive there ... we will forget about it and it bites us later
16:41:30 <frantisekz> kparal: also, I've heard adding that flag to reboot won't help as it's not saved anyway, but I didn't test it
16:41:36 <adamw> i mean, by remembering to do it with our brains? that's how i usually do it :)
16:41:46 <coremodule> If it doesn't affect the default package set, I'm -1 blocker
16:42:03 <coremodule> FWIW I've always set that flag, thinking it was required to run a system upgrade..
16:42:07 <lruzicka2> adamw, well ... I know how we did with those obvious blockers
16:42:21 <lruzicka2> coremodule, allowerasing?
16:42:28 <adamw> coremodule: you have to set it at the download step. but setting it when running the reboot command doesn't do anything, i don't think.
16:42:40 <lruzicka2> oh, the releasever
16:42:40 <kparal> adamw: in that case I agree we probably have no criterion to cover this. Which is something I'm deeply uncomfortable with, and I'll try to push myself to propose a revised criterion in the future. So I guess it's -1 right now.
16:42:46 <adamw> all the 'reboot' command actually *does* is poke a magic file and then reboot the system.
16:42:53 <coremodule> lruzicka2, not --allowerasing, --releasever=xx
16:43:03 <frantisekz> -1 from me then
16:43:19 <coremodule> adamw, ahh, gotcha. Ive never set it on the reboot step, only the download step anyway
16:43:19 <lruzicka2> coremodule, yeah you need to download the packages, you do not need it for installing them
16:43:30 <coremodule> gotcha, I was confuzzled
16:43:38 <adamw> btw, i suppose it would also be worth noting that doing the upgrade the way that broke in this bug isn't the right thing to do anyway
16:43:56 <lruzicka2> coremodule, hehe, so this was a wasted time discussion after all :D
16:43:59 <adamw> at least for the case i used as a reproducer
16:44:10 <coremodule> lruzicka2, yes, yes it was :P
16:44:12 <adamw> the bug is ultimately caused by the libgit2 module problem
16:44:36 <adamw> so the 'right' fix is to reset the module streams before upgrading, at which point this bug won't actually be triggered and you won't need to use --allowerasing at all
16:44:39 <adamw> anyoho.
16:45:13 <adamw> proposed #agreed 1758588 - RejectedBlocker (Final) - this is rejected as we are not aware of any case where this problem affects one of the release-blocking F30 package sets, so it does not violate the criterion
16:45:14 <lruzicka2> -1 then and move the wagon
16:45:17 <coremodule> ack
16:45:20 <lruzicka2> ack
16:45:21 <frantisekz> ack
16:45:44 <adamw> #agreed 1758588 - RejectedBlocker (Final) - this is rejected as we are not aware of any case where this problem affects one of the release-blocking F30 package sets, so it does not violate the criterion
16:45:52 <adamw> #topic (1750575) dnfdragora complains that dnf is locked by another process after updates
16:45:53 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1750575
16:45:53 <adamw> #info Proposed Blocker, libdnf, NEW
16:45:59 <adamw> so i was -1 on this, until some new info showed up recently
16:46:21 <adamw> https://bugzilla.redhat.com/show_bug.cgi?id=1750575#c18
16:46:28 <adamw> "The GUI does crash after closing the error window or clicking ok."
16:46:30 <adamw> can anyone else confirm that?
16:46:59 <frantisekz> from what I remember, I've seen dnfdragora closing after closing error window
16:47:10 <frantisekz> if it was crash... I am not 100_ sure
16:47:19 <kparal> adamw: I tried it and it doesn't crash, it quits
16:47:26 <adamw> hmm
16:47:29 <kparal> but I understand how the user can see it that way
16:47:50 <frantisekz> I am still (weak) -1 Blocker
16:47:51 <adamw> yeah, i mean, technically the app *itself* does not crash, but it unexpectedly and unavoidably exits
16:47:52 <kparal> I'm +1 here under the basic functionality criterion
16:48:06 <adamw> which makes me more amenable to the 'basic functionality' argument, yeah
16:48:17 <adamw> 'install some updates and don't fall over' seems like fairly basic functionality
16:48:33 <kparal> if your text editor saved your file but told you it didn't, you wouldn't consider it working. this is similar, just more confusing
16:48:53 <frantisekz> dnfdragora doesn't tell you it didn't install updates
16:49:06 <frantisekz> you see installation progressing
16:49:07 <kparal> no, it tells you weird error and exits
16:49:11 <frantisekz> yeah
16:49:17 <kparal> as I say, more confusing
16:49:32 <kparal> I would be nervous as hell whether my system is working or broken
16:49:43 <kparal> and a general user can't check dnf history and see whether it worked
16:50:08 <kparal> I can check my text file, but I can't check my system status, as a general user
16:50:27 <frantisekz> you can reboot/launch dnfdragora gain and see there are no more updates available
16:50:31 <frantisekz> *again
16:50:33 <adamw> i mean, you can just 'rpm -q' something that was in the list of updates. but yeah, i keep coming back to 'what would we think if GNOME Software was behaving this way'
16:50:35 <lruzicka2> I would expect a confirmation of a finished operation on files, otherwise I'd be terribly nervous.
16:50:39 <kparal> sure, that doesn't mean it's not broken
16:50:49 <adamw> so i think i'm coming around to +1 on this one
16:50:59 <lruzicka2> #metoo
16:51:38 <adamw> #reallydontthinkthatswhatthathashtagisfor
16:51:46 <kparal> #metoo
16:51:50 <frantisekz> #metoo
16:51:53 <lruzicka2> :D
16:52:15 <kparal> I guess that should have been #meneither
16:52:43 <lruzicka2> kparal, #neitherdoI
16:52:45 <lruzicka2> ?
16:52:52 <kparal> aha
16:53:08 <lruzicka2> kparal, i think both work
16:53:21 <kparal> package managers must work well, that's my opinion, and an error dialog at the end is not acceptable from my pov
16:53:40 <lruzicka2> +1
16:53:41 <kparal> it's like an error at the end of copying a file in nautilus
16:53:55 <kparal> then you wonder - is it really copied intact, or broken somewhere in the middle?
16:54:07 <lruzicka2> yes, which makes me nervous and I tend to believe it has not been copied
16:54:14 <adamw> so um
16:54:16 <adamw> counting votes
16:54:19 <lruzicka2> +1B
16:54:20 <adamw> i have +1 from kparal and +1 from me
16:54:27 <adamw> frantisekz, was your me too a +1?
16:54:35 <frantisekz> no, I am still -1... alone
16:54:45 <frantisekz> :D
16:54:59 <adamw> okay, so we have +3 / -1 atm
16:55:00 <lruzicka2> frantisekz, silvester stALONE
16:55:03 <adamw> which is a bit weak
16:55:11 <lruzicka2> coremodule,  ?
16:55:16 <coremodule> ugh...
16:55:19 <adamw> coremodule?
16:55:26 <adamw> kalev, finished dinner yet? :)
16:55:30 <frantisekz> wait a while, I am creating more freenode accounts to vote for -1...
16:55:36 <coremodule> I am +1, I can see the justification for it
16:56:35 <adamw> .fire frantisekz you are only allowed to clone yourself in order to work harder
16:56:35 <zodbot> adamw fires frantisekz you are only allowed to clone yourself in order to work harder
16:56:41 <adamw> ok, +4/-1
16:56:59 <adamw> that's enough for accepted, i think, frantisekz wins the Sacred Right To Say I Told You So
16:57:05 <frantisekz> :)
16:57:50 <adamw> proposed #agreed 1750575 - AcceptedBlocker (Final) - this is accepted as a violation of "All applications that can be launched using the standard graphical mechanism of a release-blocking desktop after a default installation of that desktop must start successfully and withstand a basic functionality test" for dnfdragora, we hold that 'install some updates without printing a confusing error and quitting' is 'basic' functionality for an updater
16:58:05 <coremodule> ack
16:58:08 <frantisekz> ack
16:58:33 <lruzicka2> ack
16:58:49 <kparal> my frantisekwithmoustache nick got trimmed his name and also can't post to the channel :/
16:58:52 <kparal> ack
16:59:04 <adamw> #agreed 1750575 - AcceptedBlocker (Final) - this is accepted as a violation of "All applications that can be launched using the standard graphical mechanism of a release-blocking desktop after a default installation of that desktop must start successfully and withstand a basic functionality test" for dnfdragora, we hold that 'install some updates without printing a confusing error and quitting' is 'basic' functionality for an updater
16:59:14 <adamw> haha, victory for the anti-cloning forces
17:00:00 <adamw> #topic Proposed Final freeze exceptions
17:00:06 <adamw> #info let's review proposed Final FEs!
17:00:12 <adamw> #topic (1761327) "Object St.Button (0x5621e3249b90), has been already deallocated — impossible to get any property from it." spam in system logs
17:00:13 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1761327
17:00:13 <adamw> #info Proposed Freeze Exceptions, gnome-shell, NEW
17:00:20 <adamw> this one is a bit marginal...
17:00:37 <adamw> fixing log spam is great, and does affect lives, but it's also not the biggest problem in the world, soo.
17:01:49 <lruzicka2> are there any guarantees that it will not break the gnome-shell?
17:01:52 <frantisekz> looking at your comment in bz... I think we should either reject or ask gnome devs about safety?
17:02:00 <adamw> well, that's sort of what the comment was about.
17:02:06 <adamw> i'm assuming they'll reply.
17:02:47 <frantisekz> so, punt for now?
17:04:13 <adamw> i'd be either -1 or punt, yeah.
17:04:34 <kparal> the same here
17:04:52 <coremodule> I'm up for punt for info
17:04:58 <lruzicka2> do we have time for punt?
17:05:09 <lruzicka2> go/no go is on thursday
17:05:23 <lruzicka2> ?
17:05:58 <coremodule> is true
17:06:03 <kparal> lruzicka2: if we don't approve it, it won't go in, that's it
17:06:25 <lruzicka2> so, there is not difference in punt or -1
17:06:29 <lruzicka2> let's -1
17:06:33 <kparal> there is a difference
17:06:40 <kparal> -1 rejects it, punt delays it
17:06:45 <adamw> we can punt for vote in-bug
17:06:45 <kparal> obviously :)
17:07:02 <lruzicka2> hmm, how does this decision affect go/nogo?
17:07:02 <kparal> lruzicka2: moreover, nobody says it will be Go this week
17:07:03 <adamw> and in case the release slips
17:07:10 <adamw> lruzicka: it doesn't, really.
17:07:16 <frantisekz> +1 punt
17:07:22 <lruzicka2> if we punt, it will be nogo, right?
17:07:37 <frantisekz> it's proposed FE
17:07:37 <kparal> lruzicka2: go/nogo doesn't care about FEs, just blockers
17:07:51 <adamw> right.
17:08:08 <lruzicka2> but, as I understand it, if it is go, the freeze will be waived and updates will stream in, right?
17:08:18 <frantisekz> after the release
17:08:27 <frantisekz> so it won't get on installation media for example
17:08:31 <lruzicka2> so no preventing this one into flowing into
17:08:52 <kparal> lruzicka2: the freeze exception is only important if you want to have it on the release media
17:08:53 <lruzicka2> but if we punt, and we will be GO, it won't go either
17:09:09 <lruzicka2> kparal, which if we want it there should be +1
17:09:17 <adamw> yes.
17:09:22 <kparal> lruzicka2: sure, if we want
17:09:25 <lruzicka2> because I do not understand how a punt could achieve it
17:09:43 <kparal> lruzicka2: we're not sure we want to have it there
17:09:44 <lruzicka2> and if we do not want it there, its -1. again, punt will not save us
17:09:45 <frantisekz> punt would make sense if we're no go
17:09:53 <frantisekz> we can decide on +1 next week
17:10:04 * kalev is back.
17:10:15 <adamw> lruzicka: if we punt we could vote in bug tomorrow. or in two hours. or whatever. when new info appears.
17:10:16 <kparal> lruzicka2: situation can change any day and we can vote +1 in bug tomorrow, if we want
17:10:27 <adamw> if we -1...well, i mean, we can still repropose it, but a rejection kind carries weight.
17:10:29 <lruzicka2> frantisekz, but do we want to be nogo? my concern is, if people want to be go, they will push for that
17:10:34 <adamw> anyway can we pick something and move on? this is taking a lot of time
17:10:46 <frantisekz> lruzicka2: this deos not affect go/no go in any way
17:10:49 <frantisekz> does*
17:10:54 <adamw> lruzicka: nothing we decide for this bug affects go/nogo at all.
17:10:55 <kparal> lruzicka2: let's not overthink this. we can talk tomorrow in person
17:11:08 <lruzicka2> I am +1 to make the release compose better
17:11:26 <frantisekz> ... this doesn't mean compose is going to be better
17:11:33 <frantisekz> it can be worse
17:11:38 <lruzicka2> it is, because the fix will be there
17:11:39 <kparal> lruzicka2: the reason why I'm reluctant to this in is that is presents a risk
17:11:45 <kparal> *take this in
17:11:48 <lruzicka2> in that case, we will not be go
17:11:56 <lruzicka2> which is fine with me
17:12:07 <kparal> I'm completely lost in your way of thinking
17:12:16 <lruzicka2> I am lost in yours, too
17:12:24 <kparal> so, let's vote. +1 punt
17:12:27 <frantisekz> punt
17:12:28 <lruzicka2> +1 FE
17:12:35 <adamw> punt for more info
17:12:37 <coremodule> +1 punt
17:12:43 <kparal> +1 punt can be confusing, let's say just "punt" :)
17:12:45 <cmurf> +1 punt
17:13:02 <cmurf> +44 punt hike hike hike!
17:13:31 <adamw> proposed #agreed 1761327 - punt (delay decision) - the bug here is relatively minor, and there are two different proposed fixes whose safety is not clear. we will punt to give the GNOME devs a chance to provide more info and clarity on the proposed fix here
17:13:35 <cmurf> ack
17:13:41 <kparal> ack
17:13:41 <frantisekz> ack
17:13:42 <kalev> ack
17:13:46 <lruzicka2> ack
17:13:47 <coremodule> ack
17:13:51 <Southern_Gentlem> ack
17:14:10 <adamw> #agreed 1761327 - punt (delay decision) - the bug here is relatively minor, and there are two different proposed fixes whose safety is not clear. we will punt to give the GNOME devs a chance to provide more info and clarity on the proposed fix here
17:14:18 <adamw> #topic (1759490) Fedora 31: Wayland: qtwebengine-based applications cannot be full screened
17:14:18 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1759490
17:14:18 <adamw> #info Proposed Freeze Exceptions, qt5-qtwayland, NEW
17:14:25 <adamw> i'm not really sure of the value of an FE here
17:14:39 <adamw> what's it helping? people installing qtwebengine-based apps in a Workstation live session?
17:15:17 <Southern_Gentlem> what about in kde
17:15:22 <kparal> or playing with not-updated system
17:16:15 <kparal> -1 FE
17:16:17 <lruzicka2> Southern_Gentlem, KDE does not run natively on wayland, does it?
17:16:22 <adamw> KDE live doesn't run on wayland
17:16:30 <adamw> and i'm not sure you can make it run on wayland without a lot of effort
17:16:41 <kparal> there's not even an update ready yet, we don't know what it affects
17:16:57 <lruzicka2> and there is no time, -1 FE
17:17:07 <kparal> Southern_Gentlem: this has been demonstrated just with gnome, afaik
17:17:11 <adamw> yeah, -1 here also
17:17:13 <frantisekz> -1 FE
17:17:28 <coremodule> -1
17:17:44 <kalev> agreed, -1 FE (as we don't have an update fixing it ready)
17:18:02 <adamw> proposed #agreed 1759490 - RejectedFreezeException (Final) - we don't see any convincing benefit to granting an FE here, the only case it would really help is someone installing a qtwebengine-based app in a Workstation live session, which seems like a pretty unusual scenario. We think it's fine for this to go as a regular update.
17:18:28 <kalev> ack
17:18:34 <coremodule> ack
17:18:35 <frantisekz> ack
17:18:43 <lruzicka2> ack
17:18:52 <adamw> #agreed 1759490 - RejectedFreezeException (Final) - we don't see any convincing benefit to granting an FE here, the only case it would really help is someone installing a qtwebengine-based app in a Workstation live session, which seems like a pretty unusual scenario. We think it's fine for this to go as a regular update.
17:20:14 <adamw> #topic Accepted Final blockers
17:20:21 <adamw> #info let's go over the accepted Final blockers
17:20:27 <adamw> as we're close to release, we'll do it properly, one by one
17:20:56 <adamw> #info we will consider all accepted blockers except those that are VERIFIED
17:21:02 <adamw> #topic (1747408) Cannot upgrade to Fedora 31: package exa-0.9.0-2.module_f31+5365+04413d87.x86_64 requires libgit2.so.28()(64bit), but none of the providers can be installed
17:21:03 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1747408
17:21:03 <adamw> #info Accepted Blocker, fedora-release, NEW
17:21:10 <adamw> so, this is the really awkward one
17:21:41 <adamw> sgallagh: nirik: either of you around for a fesco perspective here?
17:21:54 <kalev> fesco talked about this in their meeting today and wanted to vote somewhere if this is an acceptable soultion or not
17:22:00 <adamw> #info this is accepted as a blocker per FESCo decision, but debate continues as to what would constitute an acceptable solution
17:22:09 <adamw> kalev: aha, thanks, let me pull up those minutes
17:23:46 <Southern_Gentlem> what DE was that ?
17:23:54 * mboddu is here just for this ticket ;)
17:24:06 <lruzicka2> Today, I was approached by jmracek and he told me that they would only do the proposed fix or someone gives them the proper requirements how to fix it
17:24:10 <adamw> #info fesco decided today to vote in https://pagure.io/fesco/issue/2230 on whether the currently proposed solution - some text pointing to an 'upgrade guide' document to be shown at the time of running 'system-upgrade download' - is sufficient
17:25:57 <adamw> i guess there's not much more we can do here
17:26:10 <adamw> but if you have a strong opinion on whether or not the proposed fix is sufficient, you can add your voice to the bug report
17:26:11 <kparal> it looks we'll punt the whole F31 release by 6 months or so :-)
17:26:20 <adamw> cheers to that!
17:26:27 <mkolman> we can always add the "I'm feeling lucky!" option :)
17:26:28 <lruzicka2> who is the "someone" to give them the requirements?
17:26:49 <frantisekz> FESCO?
17:26:56 * kalev nods.
17:27:02 <Southern_Gentlem> i am sorry i dont think a modularity issue should be a blocker
17:27:20 <lruzicka2> So, it seems FESCO will be against the proposed fix, so we cannot do much here.
17:27:23 <lruzicka2> indeed
17:27:39 <frantisekz> it does not seem so
17:27:50 <adamw> yeah, we can't really do much besides follow along here
17:28:00 <lruzicka2> the vote started with -1 and -1, frantisekz
17:28:06 <adamw> #info this is more or less in the hands of FESCo and dnf devs at this point, we will continue to monitor
17:28:18 <adamw> #topic (1749433) enabled zoom stops sending mouse button events
17:28:18 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1749433
17:28:19 <adamw> #info Accepted Blocker, mutter, MODIFIED
17:28:30 <lruzicka2> Southern_Gentlem, until Modularity enters your system by default, we must block on it, I believe
17:28:41 <adamw> I just sent the hopefully-real fix for this to testing this morning, it just needs verifying
17:29:01 <kalev> thanks for picking all the fixes and sending all the builds, adamw
17:29:21 <adamw> no problem, thanks for making sure stuff got fixed
17:29:39 <frantisekz> yeah, I've tested this with mutter I've built myself, seemed to work
17:29:40 <kparal> adamw: verified already
17:29:49 <kparal> refresh your bugzillas
17:29:53 <adamw> heh
17:30:05 <adamw> #info the fix for this was very recently VERIFIED, so it should be good now
17:30:12 <adamw> #topic (1728240) Cannot start Fedora-KDE-Live (F31) in basic graphics mode on BIOS machine
17:30:12 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1728240
17:30:12 <adamw> #info Accepted Blocker, sddm, NEW
17:30:16 <mkolman> IIRC jkonecny never explicitly installed any modules yet had his upgrade broken by a broken module
17:30:33 <adamw> so, this one is still just sort of sitting around, i think.
17:30:40 <adamw> we got a bit of movement, but not exactly a flood.
17:30:45 <mkolman> I think that's the issue - submarine modules getting brought in as dependencies & then causing issues later on
17:31:02 <mkolman> </offtopic>
17:31:20 <lruzicka2> mkolman, but yeah, that is the problem indeed.
17:31:45 <adamw> #info we are still waiting on the KDE team for a fix here
17:31:58 <adamw> #action adamw to poke KDE folks again and try to get some kind of fix ASAP
17:32:28 <frantisekz> for this one... I am willing to propose waiving on go/no-go if we don't see any fix in time
17:33:19 <kparal> frantisekz: under "hard to fix" clause?
17:33:24 <frantisekz> yeah
17:33:33 <kparal> we actually don't know that yet
17:33:48 <frantisekz> anyhow... we might end up blocking fedora forever on this
17:33:56 <frantisekz> I didn't see any upstream replies here
17:34:05 <lruzicka2> Adam's last proposed Ubuntu-like fix does not look too complicated.
17:34:09 <kparal> I think it will get resolved sooner than basic use cases for modularity :)
17:34:17 <frantisekz> :D
17:34:24 <lruzicka2> kparal, beware of forbiden statements
17:34:55 <adamw> i just sort of looked into this very briefly and it seems...a bit odd...because there's no directly 'new' usage of CanGraphical stuff recently in sddm afaics
17:35:01 <adamw> did anyone test whether this works on f30?
17:35:29 <frantisekz> I am not sure/don't remember (#me_runs_away if it was myself who tested that)
17:35:45 <lruzicka2> adamw, it did not when we tested f30 and it somehow slipped our attention, therefore I checked for that again on 31, but not on 30 again.
17:36:00 <frantisekz> I can test 30 tomorrow though
17:36:19 <adamw> would be useful to know last release where it worked
17:36:25 <adamw> would help bisect sddm changes...
17:36:34 <lruzicka2> ok, so, we can try 29, too
17:36:36 <frantisekz> I can do that
17:36:44 <frantisekz> if it worked at some point adamw
17:36:48 <kparal> frantisekz: might be difficult tomorrow, we're at the university
17:36:50 <adamw> heh
17:37:01 <adamw> anyhow, i'll try and focus on this one this week
17:37:13 <lruzicka2> we can test several releases on wednesday
17:37:35 <adamw> wed is kinda too late for the release :/ we really need to fix this by tomorrow...
17:37:37 <adamw> anyhoo!
17:37:42 <adamw> we know where we're at at least
17:38:09 <adamw> #topic (1761484) Update appstream-data after final freeze
17:38:09 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1761484
17:38:09 <adamw> #info Proposed Blocker, appstream-data, ON_QA
17:38:21 <adamw> #info this is straightforward, we just need to test the updated data and karma it
17:38:28 <adamw> #topic (1760937) dnf-yum in F30 is now higher versioned than F31+ yum's "Obsoletes" (affects upgrades)
17:38:28 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1760937
17:38:28 <adamw> #info Proposed Blocker, dnf, NEW
17:38:43 <adamw> #info this is also fairly simple, we just need a dnf maintainer or provenpackager to bump the version on the obsoletes and submit an update for testing
17:39:18 <adamw> #topic (1750575) dnfdragora complains that dnf is locked by another process after updates
17:39:18 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1750575
17:39:18 <adamw> #info Proposed Blocker, libdnf, NEW
17:39:39 <adamw> this one we'll need to get dnfdragora and dnf devs to work on urgently i guess :/
17:39:54 <adamw> nirik, cmurf, you guys have any ideas about it? or outside your range?
17:40:35 <lruzicka2> kparal, frantisekz: Shall I stay at the office and test those bugs tomorrow when you are at FIT?
17:40:58 <frantisekz> lruzicka2: it's up to you, I guess we can make it without one person
17:41:36 <lruzicka2> frantisekz, kparal: So I will run those tests in the morning and join you later.
17:42:08 <lruzicka2> adamw, I will run the Base Driver tests tomorrow for 30, 29, and earlier if need be.
17:42:35 <frantisekz> lruzicka2: just make sure you run them in BIOS mode, it seems to work fine in UEFI
17:42:58 <adamw> right.
17:43:05 <adamw> (which makes sense if it's the CanGraphical thing, actually.)
17:43:10 <adamw> i may check it later today
17:43:14 <adamw> but it depends a bit as it's a holiday
17:43:18 <adamw> (in canada nayway)
17:43:36 <Southern_Gentlem> in the usa as well
17:43:39 <adamw> #info we need dnfdragora and dnf developers to come up with a fix for this one
17:43:53 <adamw> huh, really? it's correct thanksgiving today
17:43:59 <adamw> you guys have your entirely incorrect thansgiving later i thought
17:44:25 <Southern_Gentlem> columbus day so banks, postal and government closed (i get holiday for it)
17:44:49 <lruzicka2> frantisekz, BIOS, sure :D
17:44:52 <kparal> columbusthanksgiving day!
17:45:57 <cmurf> It's outside of my range, I don't know any of the dnfdragora developers.
17:46:08 <adamw> #action adamw to ping dnfdragora and dnf developers to work on this urgently
17:46:10 <cmurf> Or maybe, ngompa is?
17:46:20 <adamw> he is involved i believe, but i don't see him here.
17:46:24 <adamw> (under any of his many aliases)
17:46:43 <frantisekz> adamw, I can poke dnf devs in person too, might help to kidnap them and force them to work on Fedora blockers instead of that RHEL stuff...
17:46:51 <cmurf> this blocks because of KDE right?
17:46:56 <frantisekz> and xfce arm
17:47:28 <adamw> frantisekz: i fully endorse this plan
17:47:32 <frantisekz> :)
17:48:13 <cmurf> so i mean, it's a blocker then right?
17:48:37 <adamw> #action frantisekz to kidnap dnf developers and force them to fix all the bugs or else they have to read the modularity threads over and over again forever
17:48:43 <adamw> cmurf: we're not deciding blocker status here
17:48:47 <cmurf> oh t his one
17:48:49 <adamw> we're reviewing current action on accepted blockers
17:48:58 <frantisekz> adamw++ :D
17:48:58 <zodbot> frantisekz: Karma for adamwill changed to 12 (for the current release cycle):  https://badges.fedoraproject.org/tags/cookie/any
17:49:08 <cmurf> it's proposed
17:49:21 <cmurf> i don't see it listed as a blocker - i thought we punted on this because it's ugly, not clearly blocking
17:49:47 <adamw> we accepted it earlier in this meeting.
17:49:51 <cmurf> ohhh
17:50:01 <mkolman> I think most of the issues do not stem from the implementation of modularity ion DNF
17:50:23 <mkolman> rather on the insufficient/conflicting/missing specification of how modularity should work
17:50:24 <adamw> #topic Open floor
17:50:30 <adamw> so, that's everything on the list
17:50:35 <mkolman> and that's not coming from the DNF team
17:50:36 <adamw> anyone have other f31-release-related business
17:50:37 <adamw> ?
17:52:22 <lruzicka2> mkolman, unfortunately that seems not to be fixed any time soon
17:52:35 <mkolman> yep
17:52:56 <mkolman> just saying throwing the blame on the DNF team is not really correct
17:54:15 <adamw> welp, if no-one has anything, i guess we can all go enjoy the possibly-a-holi-day
17:54:21 <adamw> thanks for coming, folks
17:54:28 <frantisekz> thanks adamw and everybody else
17:54:42 <coremodule> thanks for hosting adamw, as always
17:54:56 <kparal> thanks
17:55:41 <adamw> #endmeeting