17:13:54 <adamw> #startmeeting F32-blocker-review
17:13:54 <zodbot> Meeting started Mon Feb  3 17:13:54 2020 UTC.
17:13:54 <zodbot> This meeting is logged and archived in a public location.
17:13:54 <zodbot> The chair is adamw. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:13:54 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
17:13:54 <zodbot> The meeting name has been set to 'f32-blocker-review'
17:13:54 <adamw> #meetingname F32-blocker-review
17:13:54 <adamw> #topic Roll Call
17:13:54 <zodbot> The meeting name has been set to 'f32-blocker-review'
17:14:03 <adamw> #chair lruzicka cmurf
17:14:03 <zodbot> Current chairs: adamw cmurf lruzicka
17:14:11 <adamw> impending boilerplate alert!
17:14:11 <adamw> #topic Introduction
17:14:12 <adamw> Why are we here?
17:14:12 <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.
17:14:13 <adamw> #info We'll be following the process outlined at:
17:14:13 <adamw> #link https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting
17:14:16 <adamw> #info The bugs up for review today are available at:
17:14:17 <adamw> #link http://qa.fedoraproject.org/blockerbugs/current
17:14:19 <adamw> #info The criteria for release blocking bugs can be found at:
17:14:20 <lruzicka> .hello2
17:14:21 <adamw> #link https://fedoraproject.org/wiki/Basic_Release_Criteria
17:14:21 <zodbot> lruzicka: lruzicka 'Lukáš Růžička' <lruzicka@redhat.com>
17:14:25 <tablepc> .hello 2
17:14:25 <adamw> #link https://fedoraproject.org/wiki/Fedora_32_Beta_Release_Criteria
17:14:26 <zodbot> tablepc: Sorry, but you don't exist
17:14:27 <adamw> #link https://fedoraproject.org/wiki/Fedora_32_Final_Release_Criteria
17:14:38 <adamw> #info 6 Proposed Blockers (Beta)
17:14:38 <adamw> #info 1 Accepted Blockers (Beta)
17:14:47 <adamw> #info 1 Proposed Blockers (Final)
17:14:58 <adamw> who wants to secretarialize?
17:15:07 <adamw> coremodule: ahoy hoy?
17:15:09 <kparal> .hello2
17:15:10 <zodbot> kparal: kparal 'Kamil Páral' <kparal@redhat.com>
17:15:13 <kparal> adamw: he's on PTO
17:16:33 <tablepc> I don't exist
17:16:43 <adamw> oh right
17:16:50 <adamw> tablepc: don't worry, it's not so bad
17:16:53 <adamw> i guess i'll secretarialize!
17:17:01 <adamw> #info adamw will secretarialize after the meeting
17:17:04 <kparal> I was about to give up and volunteer
17:17:08 <kparal> but too late, not a problem
17:17:10 <adamw> i'll keep my hand in
17:17:16 <adamw> #topic Proposed Beta blockers
17:17:30 <adamw> #topic (1797274) AttributeError: can't set attribute
17:17:30 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1797274
17:17:30 <adamw> #info Proposed Blocker, anaconda, POST
17:17:37 * pwhalen is here
17:18:06 <adamw> openQA is hitting this one too, I believe
17:18:42 <adamw> yup
17:18:45 <adamw> +1 blocker, pretty obvious
17:18:55 <adamw> it breaks just about everything in custom/blivet part
17:19:15 <pwhalen> +1
17:19:33 <kparal> +1
17:20:21 <lruzicka> +
17:20:23 <lruzicka> 1
17:21:06 <adamw> proposed #agreed 1797274 - AcceptedBlocker (Beta) - accepted as a violation of just about every bullet under "When using both the installer-native and the blivet-gui-based custom partitioning flow, the installer must be able to: "
17:21:47 <kparal> ack
17:22:54 <lruzicka> ack
17:23:55 <cmurf> ack
17:23:58 <pwhalen> ack
17:24:43 <adamw> #agreed 1797274 - AcceptedBlocker (Beta) - accepted as a violation of just about every bullet under "When using both the installer-native and the blivet-gui-based custom partitioning flow, the installer must be able to: "
17:24:51 <adamw> #topic (1795000) gnome-session is crashing, desktop intermittently is never reached
17:24:51 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1795000
17:24:51 <adamw> #info Proposed Blocker, gnome-shell, NEW
17:25:01 <adamw> we think this is probably a dupe of the glib bug?
17:25:33 <cmurf> i'm not certain but i think so
17:26:01 <cmurf> the other two selinux bugs I filed along with this were marked as dups of the bug I cited
17:26:06 <cmurf> but not this one
17:26:21 <cmurf> soooidunno
17:26:51 <kparal> accept all the things
17:27:46 <adamw> cmurf: do these crashes happen with enforcing=0?
17:27:53 <cmurf> no
17:29:03 <adamw> i think i'd kinda like to get all the selinux denials fixed and then see if all these other bugs go away...
17:30:31 <lruzicka> testing just now ..... enforcing 0, blinking, no desktop. VM 20200132.n.1
17:30:36 <lruzicka> workstation
17:30:52 <pwhalen> 20200132.n.1?
17:31:00 <lruzicka> typos
17:31:08 <lruzicka> 31.n.0
17:31:11 <adamw> why is 1795524 not a proposed blocker...
17:31:31 <adamw> ah, the 32nd of january, my favourite day of the year
17:31:37 <adamw> hum.
17:31:59 <cmurf> this is a good question
17:32:01 <pwhalen> 1795524 should be
17:32:43 <cmurf> I'm gonna guess 1795524 should be blocking, and 1795000 and 1797414 are dups
17:33:00 <adamw> so, if lruzicka is seeing the behaviour described in 1795000 even with enforcing=0, i guess i'm +1 to keep it separate and accept it as a blocker for now
17:33:09 <cmurf> BUT 1795000 could be a gnome-session crasher independent of the glib2+selinux issue, hard to separate them
17:33:09 <adamw> brb, call of nature
17:33:25 <lruzicka> cmurf, but the 1795524 says it works with enf0, mine does not, will retry once more to be sure
17:33:28 <cmurf> i think that's a good idea
17:35:06 <lruzicka> adamw, cmurf: grrr, worked this time. Will retry once more.
17:36:22 <lruzicka> but I still got a lot of unusual blinking, and when GIS finished, I am getting the blinking again and ..... no screen now.
17:36:45 <cmurf> lruzicka: it's not your fault, it's non-deterministic
17:36:56 <cmurf> sometimes the login window doesn't even appear fo rme
17:37:13 <cmurf> sometimes i get 4-5 crashes and something gives up trying (?)
17:37:23 <lruzicka> cmurf, yeah ... I see the same way.
17:37:32 <lruzicka> see it
17:37:57 <lruzicka> I would still be +1 for this one and the other one, too
17:38:17 <lruzicka> btw, no screen again
17:38:34 <cmurf> probably keep them separate for now
17:38:37 <cmurf> both blocking
17:38:40 <adamw> yeah, that's my feeling
17:38:47 <adamw> so i count that +3
17:38:49 <adamw> any other votes?
17:39:11 <pwhalen> +1 here too
17:40:03 <Southern_Gentlem> +1
17:40:47 <adamw> proposed #agreed 1795000 - accepted as a violation of "A system installed with a release-blocking desktop must boot to a log in screen where it is possible to log in to a working desktop using a user account created during installation or a 'first boot' utility"
17:41:04 <Southern_Gentlem> ack
17:41:08 <pwhalen> ack
17:41:20 <lruzicka> ack
17:41:34 <kparal> ack
17:42:24 <adamw> #agreed 1795000 - accepted as a violation of "A system installed with a release-blocking desktop must boot to a log in screen where it is possible to log in to a working desktop using a user account created during installation or a 'first boot' utility"
17:42:30 <adamw> #topic (1782778) virt-install unable to find any master var store for loader
17:42:30 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1782778
17:42:30 <adamw> #info Proposed Blocker, libvirt, POST
17:42:42 <cmurf> looks fixed
17:42:51 <cmurf> i've been using uefi vms for a while now
17:42:54 <cmurf> couple weeks i guess
17:43:51 <pwhalen> yes, fixed on aarch64 with libvirt 6.0 as Cole mentioned
17:44:11 <adamw> ok, let's close it then
17:44:23 <adamw> #info this was expected fixed in libvirt 6.0 and multiple reports say it is, so we'll close it and move on
17:44:45 <lruzicka> ack
17:44:47 <pwhalen> ack
17:44:56 <Southern_Gentlem> ack
17:45:00 <adamw> #topic (1786876) ERROR: 'python-nftables' failed: prevents libvirt from activating NAT, results in failure to start VMs
17:45:00 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1786876
17:45:00 <adamw> #info Proposed Blocker, selinux-policy, POST
17:45:06 <adamw> that was an info, not a proposal :P
17:45:23 <lruzicka> adamw, cant we ack the info?
17:46:41 <adamw> lruzicka: you can only ack proposals
17:46:50 <adamw> .fire lruzicka for superfluous acks
17:46:50 <zodbot> adamw fires lruzicka for superfluous acks
17:46:58 <adamw> looks like this ought to be fixed too
17:47:04 * lruzicka bleeds all over adamw
17:47:06 <adamw> cmurf, have you checked?
17:47:41 <cmurf> oh this
17:47:51 <cmurf> the problem here is I can't boot with enforcing=0
17:48:00 <cmurf> s/with/without
17:48:13 <cmurf> and enforcing=0 prevents this problem from happening
17:48:18 <cmurf> so i don't actually know if it's fixed
17:48:23 <adamw> you can setenforce after booting, no?
17:48:24 <cmurf> probably?
17:48:27 <adamw> or does stuff blow up then?
17:48:37 <cmurf> dunno haven't tried that
17:49:18 <cmurf> checking...
17:49:45 <cmurf> what's the exact command? "sudo setenforce ??"
17:50:12 <adamw> Enforcing
17:50:16 <cmurf> got it
17:51:28 <cmurf> works
17:52:44 <cmurf> yes so boot with enforcing=0, then setenforce, confirm its enforcing with sestatus, the VM startsup without complaint
17:54:34 <adamw> okay
17:54:37 <adamw> let's close this one too then
17:54:52 <adamw> #info looks like this is fixed too according to cmurf, will close it and move on
17:56:52 <lruzicka> adamw, I am not acking to be sure.
17:58:09 <adamw> =)
17:58:16 <adamw> #topic (1797414) can't login due to AVC denied  { sys_nice } for  pid=964 comm="accounts-daemon"
17:58:16 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1797414
17:58:16 <adamw> #info Proposed Blocker, selinux-policy, NEW
18:01:16 <cmurf> that's likely a dup
18:01:35 <cmurf> also does not happen with enforcing=0
18:01:41 <cmurf> part of the glib2+selinux madness
18:02:02 <adamw> so, i'd propose we punt on it to see if it goes away when the main glib2+selinux bug is fixed?
18:02:08 <cmurf> fair
18:02:09 <pwhalen> +1 punt
18:02:40 <kparal> +3 punt
18:03:51 <adamw> kparal is many
18:04:54 <adamw> proposed #agreed 1797414 - punt (delay decision) - we suspect this is a dupe of https://bugzilla.redhat.com/show_bug.cgi?id=1795524 , which we'll consider later. we're not sure, so we don't want to close it, but we'll delay considering it as a blocker on its own until that bug is resolved
18:05:18 <lruzicka> ack
18:05:32 <Southern_Gentlem> ack
18:06:00 <kparal> ack
18:06:20 <adamw> #agreed 1797414 - punt (delay decision) - we suspect this is a dupe of https://bugzilla.redhat.com/show_bug.cgi?id=1795524 , which we'll consider later. we're not sure, so we don't want to close it, but we'll delay considering it as a blocker on its own until that bug is resolved
18:06:27 <adamw> #topic (1554010) No env. group installed after Fedora installation
18:06:27 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1554010
18:06:27 <adamw> #info Proposed Blocker, spin-kickstarts, NEW
18:07:33 <adamw> as discussed in the bug, this doesn't seem like a blocker to me.
18:07:45 <adamw> it's just a kind of historical quirk in how we build lives.
18:09:30 <pwhalen> -1
18:11:09 <adamw> .hire lruzicka because we need the votes
18:11:09 <zodbot> adamw hires lruzicka because we need the votes
18:11:45 <lruzicka> -1
18:11:53 <kparal> hmm
18:12:08 <lruzicka> +1fe
18:12:12 <cmurf> what's the basis for it being a blocker
18:12:17 <kparal> I guess the best argument is we had been shipping for a long time in this state
18:12:24 <cmurf> is there a remotely applicable criterion?
18:12:28 <kparal> even though I see the point of how it breaks dnf
18:12:32 <adamw> "The presence of environmental group is critical part to keep integrity of the system. When user on fresh systems (workstation distribution) installs additional env. group (KDE) and then removes it it also removes most of the part of Workstation (also it tries to remove dnf). Official distributions must always mark one env. group as installed."
18:12:42 <kparal> cmurf: the dnf criterion I guess
18:12:43 <adamw> but that's an opinion, it's not actually something that's written in the release criteria or anywhere else.
18:12:56 <adamw> i guess it's an opinion from an important perspective, but still.
18:13:02 <cmurf> i'd say punt and ask DNF folks if it should be a blocker
18:13:17 <adamw> installing additional environments then removing them is not really something we block on.
18:13:23 <kparal> cmurf: jmracek is one of the main dnf developers
18:13:31 <cmurf> ahh
18:13:49 <cmurf> welll, that's interesting
18:14:28 <kparal> I guess adamw is correct
18:14:31 <lruzicka> yeah, the thing is, this has been a problem since Fedora 26/27, nobody seemed to have complained
18:14:41 <kparal> but we could fudge the criterion a bit...
18:15:02 <kparal> I have been annoyed by it, I just didn't know it's a bug and not a feature :)
18:15:15 <cmurf> i think it's a gray area
18:15:47 <cmurf> there it's a criterion, maybe there should be
18:15:53 <cmurf> s/it's/isn't
18:16:19 <cmurf> what does making it a blocker bug do? who would have to fix this and why can't that just be fixed anyway without making it a blocker?
18:17:01 <kparal> looks like livecd building tools need to do the right thing, whatever that is
18:17:30 <adamw> just use the env groups in the kickstarts
18:17:42 <adamw> if it works it's a straightforward change, and a clearly beneficial one
18:17:47 <adamw> but i still don't think it's a release blocker :)
18:17:55 <cmurf> right
18:18:02 <cmurf> i'm -1
18:18:09 <Southern_Gentlem> -1 +fe
18:18:16 * kparal shrugs
18:18:50 <cmurf> i support someone filing a fesco issue on it though, if they feel strongly about it
18:19:18 <kparal> might be a good idea
18:19:20 <adamw> any other fe votes? i'm not sure it's really a great candidate for an FE myself
18:19:25 <adamw> seems better to change it outside of freeze
18:19:34 <kparal> +1 FE
18:19:56 <tablepc> I'm old school, but doing things like the bug describes is probably Bad Dog. If I did something like that I'd figure on doing a clean install of Workstation to get back to where I was before doing the KDE install.
18:19:57 <cmurf> we're a ways from freeze aren't wee
18:20:04 <cmurf> weeee
18:20:24 <lruzicka> +1fe (just repeating)
18:24:16 <adamw> proposed #agreed 1554010 - RejectedBlocker (Beta) AcceptedFreezeException (Beta) - we agree that fixing this would be a significant improvement, but it does not violate any release criteria that we can see (and we've been releasing this way for years). accepted as an FE as it would be beneficial to change this, and it can't be fixed with an update
18:24:46 <lruzicka> ack
18:24:51 <pwhalen> ack
18:25:18 <adamw> #agreed 1554010 - RejectedBlocker (Beta) AcceptedFreezeException (Beta) - we agree that fixing this would be a significant improvement, but it does not violate any release criteria that we can see (and we've been releasing this way for years). accepted as an FE as it would be beneficial to change this, and it can't be fixed with an update
18:25:38 <adamw> #topic (1795524) Fedora 32 Rawhide won't boot until set to "permissive"
18:25:42 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1795524
18:25:53 <adamw> #info Proposed Blocker, glib2, ASSIGNED
18:26:00 <adamw> so this is the main selinux/glib2 bug, i believe
18:26:05 <kparal> +1
18:26:11 <adamw> to me it makes sense to take this as a blocker and see where the others land after it's fixed
18:26:14 <cmurf> +1
18:26:25 <pwhalen> +1
18:26:30 <lruzicka> +1
18:28:28 <adamw> proposed #agreed 1795524 - AcceptedBlocker (Beta) - this is accepted as a violation of all the 'installed system must boot' criteria. Note that we believe various other significant bugs may well be dupes of this as well.
18:28:32 <Southern_Gentlem> +1
18:28:38 <Southern_Gentlem> ack
18:28:40 <lruzicka> ack
18:29:27 <kparal> ack
18:29:36 <adamw> #agreed 1795524 - AcceptedBlocker (Beta) - this is accepted as a violation of all the 'installed system must boot' criteria. Note that we believe various other significant bugs may well be dupes of this as well.
18:31:20 <adamw> #topic Proposed Final blockers
18:31:25 <adamw> that was all of the proposed Beta blockers
18:31:32 <adamw> there's one proposed Final
18:31:32 <adamw> #topic (1774746) iscsi login fails during install with "buf[20] !sufficient to decode string[66]" since Fedora-Rawhide-20191119.n.2
18:31:33 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1774746
18:31:33 <adamw> #info Proposed Blocker, iscsi-initiator-utils, NEW
18:31:41 <adamw> this has been broken forever and I'm not getting any movement on the bug, but it clearly is a blocker
18:31:46 <adamw> we may need to poke someone to get it escalated
18:31:56 <adamw> clear +1, though
18:33:56 <pwhalen> +1
18:34:18 <lruzicka> +1, let's push for fix
18:34:19 <Southern_Gentlem> +1
18:35:43 * pwhalen just proposed a new blocker for beta- sorry
18:37:19 <adamw> grrrr :P
18:38:04 <adamw> proposed #agreed 1774746 - AcceptedBlocker (Final) - accepted as a violation of "The installer must be able to detect (if possible) and install to supported network-attached storage devices."
18:38:17 <lruzicka> ack
18:38:27 <pwhalen> ack
18:38:54 <adamw> #agreed 1774746 - AcceptedBlocker (Final) - accepted as a violation of "The installer must be able to detect (if possible) and install to supported network-attached storage devices."
18:39:00 <adamw> pwhalen: what did you propose?
18:39:11 <adamw> i can't refresh the app because of the whole 'plugging in a yubikey crashes GNOME' bug :P
18:39:25 <pwhalen> this one - https://bugzilla.redhat.com/show_bug.cgi?id=1796267
18:39:30 <adamw> ah, https://bugzilla.redhat.com/show_bug.cgi?id=1796267
18:40:04 <adamw> #topic (1796267) login to ssh on arm fails with seccomp denial on clock_gettime64
18:40:07 <adamw> grrr
18:40:08 <adamw> #undo
18:40:08 <zodbot> Removing item from minutes: <MeetBot.items.Topic object at 0x7fdff20f89d0>
18:40:13 <adamw> #topic New proposed Beta blocker
18:40:21 <adamw> we have a new ch ch challenger!
18:40:25 <adamw> #topic (1796267) login to ssh on arm fails with seccomp denial on clock_gettime64
18:40:32 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1796267
18:40:34 <Southern_Gentlem> +1
18:41:04 <adamw> #info Proposed Blocker, openssh, NEW
18:41:23 <adamw> i feel like we should have a criterion that covers this better, but i can't find it
18:41:24 <adamw> anyone?
18:41:24 <pwhalen> +1, most arm users rely on ssh
18:41:32 <adamw> anyway, i'm +1 even with using the rarely-used criteria wiggle
18:41:37 <pwhalen> I couldnt find it either
18:41:38 <lruzicka> +1
18:42:32 <adamw> does sshd appear to start up successfully then only fail when someone logs in?
18:42:50 <adamw> the 'system services' criterion might be applicable, but it does say "All system services present after installation with one of the release-blocking package sets must start properly"
18:42:53 <pwhalen> adamw, yes, starts fine
18:42:54 <adamw> so if it *starts*...
18:42:56 <adamw> sigh.
18:43:05 <adamw> ok, we need a criterion for this :P
18:43:16 <adamw> +1
18:44:16 <adamw> proposed #agreed 1796267 - AcceptedBlocker (Beta) - not accepting ssh connections is clearly a critical issue and will render many installs of remote-only-access systems useless, we think there should be a criterion for this, but will accept it immediately under the "Bug hinders execution of required Beta test plans or dramatically reduces test coverage" provision
18:44:31 <pwhalen> ack
18:44:50 <cmurf> ack
18:45:03 <cmurf> what about the post install criterion?
18:45:04 <lruzicka> ack
18:45:09 <adamw> #agreed 1796267 - AcceptedBlocker (Beta) - not accepting ssh connections is clearly a critical issue and will render many installs of remote-only-access systems useless, we think there should be a criterion for this, but will accept it immediately under the "Bug hinders execution of required Beta test plans or dramatically reduces test coverage" provision
18:45:12 <adamw> cmurf: doesn't seem to cover this
18:45:15 <adamw> it explicitly talks about VTs
18:45:24 <adamw> we could probably expand it, for beta or final, to require ssh worsk
18:45:33 <adamw> if someone wants to draft that :)
18:45:41 <adamw> ok, that's all proposals
18:45:43 <adamw> #topic Open floor
18:45:49 <adamw> any other business, before I go unload some more boxes? :)
18:46:41 <tablepc> Good luck with boxes
18:49:01 <lruzicka> ack
18:49:25 <kparal> adamw: do you perhaps have a cat in one of those?
18:50:05 <kparal> that might be a surprise of the day
18:50:09 <tablepc> Cat in a box... Sounds like a product
18:52:49 <tablepc> Have a Great Day Everyone!
18:52:56 <lruzicka> you too
18:53:24 <lruzicka> take care
18:56:20 <adamw> kparal: no, they're mostly in the closets...
18:56:23 <adamw> thanks for coming folks!
18:56:24 <adamw> #endmeeting