17:00:58 <adamw> #startmeeting F32-blocker-review
17:00:58 <adamw> #meetingname F32-blocker-review
17:00:58 <adamw> #topic Roll Call
17:00:58 <zodbot> Meeting started Mon Mar  2 17:00:58 2020 UTC.
17:00:58 <zodbot> This meeting is logged and archived in a public location.
17:00:58 <zodbot> The chair is adamw. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:00:58 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
17:00:58 <zodbot> The meeting name has been set to 'f32-blocker-review'
17:00:58 <zodbot> The meeting name has been set to 'f32-blocker-review'
17:01:04 <adamw> who's around for blocker fun?
17:01:32 <frantisekz> .hello2
17:01:33 <zodbot> frantisekz: frantisekz 'František Zatloukal' <fzatlouk@redhat.com>
17:01:56 <bcotton> .hello2
17:01:57 <zodbot> bcotton: bcotton 'Ben Cotton' <bcotton@redhat.com>
17:02:20 * kparal is here
17:02:29 * pwhalen is here
17:02:59 * coremodule is here and willing to secretarialize.
17:04:37 <lruzicka> .hello2
17:04:38 <zodbot> lruzicka: lruzicka 'Lukáš Růžička' <lruzicka@redhat.com>
17:05:45 <adamw> #chair lruzicka kparal
17:05:45 <zodbot> Current chairs: adamw kparal lruzicka
17:05:59 <adamw> boilerplate time!
17:06:00 <adamw> #topic Introduction
17:06:00 <adamw> Why are we here?
17:06:00 <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:06:00 <adamw> #info We'll be following the process outlined at:
17:06:01 <adamw> #link https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting
17:06:03 <adamw> #info The bugs up for review today are available at:
17:06:05 <adamw> #link http://qa.fedoraproject.org/blockerbugs/current
17:06:07 <adamw> #info The criteria for release blocking bugs can be found at:
17:06:09 <adamw> #link https://fedoraproject.org/wiki/Basic_Release_Criteria
17:06:11 <adamw> #link https://fedoraproject.org/wiki/Fedora_32_Beta_Release_Criteria
17:06:13 <adamw> #link https://fedoraproject.org/wiki/Fedora_32_Final_Release_Criteria
17:06:15 <adamw> #action coremodule will secretarialize
17:07:04 <adamw> #info for Beta, we have:
17:07:05 <adamw> #info 2 Proposed Blockers
17:07:05 <adamw> #info 7 Accepted Blockers
17:07:09 <adamw> #info 5 Proposed Freeze Exceptions
17:07:09 <adamw> #info 3 Accepted Freeze Exceptions
17:07:11 <adamw> #info for Final, we have:
17:07:17 <adamw> #info 2 Proposed Blockers
17:07:17 <adamw> #info 3 Accepted Blockers
17:07:26 <adamw> so, let's get started with:
17:07:30 <adamw> #topic proposed Beta blockers
17:07:45 <adamw> #topic (1807252) bootloader entry missing after installation on armhfp
17:07:45 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1807252
17:07:45 <adamw> #info Proposed Blocker, anaconda, POST
17:08:06 <frantisekz> seems like +1 to me
17:08:10 <adamw> hmmm
17:08:10 <adamw> well
17:08:23 <adamw> per https://fedoraproject.org/wiki/Releases/32/ReleaseBlocking we do not actually have a release-blocking ARM installer image
17:08:31 <cmurf> how did I miss this
17:08:40 <adamw> the only release-blocking ARM images are disk images, which don't run anaconda to install
17:08:41 <pwhalen> I wasnt sure about the criteria. The system does boot, just uses the rescue entry
17:08:46 <adamw> is this intentional? or are we missing something?
17:08:52 <frantisekz> hmm
17:09:04 <lruzicka> the bug says it's been fixed, so it does not look like intention
17:09:16 <cmurf> oh it's ew
17:09:18 <kparal> adamw: see https://pagure.io/fedora-qa/issue/615
17:09:20 <frantisekz> lruzicka, I think adamw is talking about wiki
17:09:24 <cmurf> haha, s/ew/new
17:09:50 <kparal> this is either waiting on pbrobinson or bcotton
17:10:08 <kparal> or pwhalen :)
17:10:26 <lruzicka> frantisekz, oh well
17:10:56 <kparal> I wonder if I linked the right ticket
17:10:56 <adamw> right, i meant is it intentional that we have no release-blocking installer images on ARM
17:11:36 <adamw> this *did* change at some point
17:11:52 <adamw> it looks like it changed between 30 and 31
17:11:53 <pwhalen> adamw, good question- minimally we need the installer working for installing builders
17:12:04 * pwhalen wasnt aware
17:12:12 <adamw> for 30, the Everything netinst was release-blocking on 32-bit and 64-bit arm: https://fedoraproject.org/wiki/Releases/30/ReleaseBlocking
17:12:21 <adamw> for 31, when bcotton simplified the page, it got dropped
17:12:30 <adamw> https://fedoraproject.org/wiki/Releases/31/ReleaseBlocking
17:12:34 <bcotton> d'oh
17:12:38 <adamw> i don't know if that's intentional on someone's part, or an oversight
17:12:53 <Eighth_Doctor> .hello2 ngompa
17:12:54 <zodbot> Eighth_Doctor: Sorry, but you don't exist
17:13:06 <bcotton> probably an oversight then. i don't recall an explicit call to drop it
17:13:13 <lruzicka> Eighth_Doctor, with nickname just .hello
17:13:20 <Eighth_Doctor> .hello ngompa
17:13:21 <zodbot> Eighth_Doctor: ngompa 'Neal Gompa' <ngompa13@gmail.com>
17:14:26 <bcotton> the only change i remember is the recent one to drop Xfce and add Workstation on ARM
17:15:01 <frantisekz> some arm-minimal stuff should remain blocking afaik
17:15:29 <bcotton> adamw: wait. the everything netinst was *not* blocking on the F30 page except for x86_64
17:15:47 <adamw> oh yes, you're right
17:15:48 <adamw> i misread it
17:15:53 <adamw> hrrmff
17:16:19 <adamw> the server dvd *was* blocking on aarch64...but not armhfp...
17:18:29 <adamw> afaics we haven't had a release-blocking 32-bit ARM installer image for many releases
17:18:30 <pwhalen> Right, server for aarch64. For armhfp I have always tested and treated the installer as blocking. We need it for builders at minimum. I dont know how much its used outside of that.
17:18:51 <adamw> seems like a disconnect, then
17:19:05 <adamw> builders can't be deployed via disk images?
17:19:51 <pwhalen> adamw, I guess they could be.. would need tweaking for. Disk images dont use swap anymore
17:20:59 <adamw> okay. hm.
17:21:02 <adamw> thinking how best to proceed here.
17:21:57 <jlanda> minimal was arm blocker, is not that enough?
17:22:30 <adamw> jlanda: where?
17:23:59 <pwhalen> adamw, the matrices also list the arm install tests as basic(required).
17:23:59 <jlanda> release blocking deliverables just list the armhp raw image tho
17:25:43 <adamw> pwhalen: true, but the criteria are 'more authoritative' than the matrices generally speaking
17:25:44 <jlanda> https://fedoraproject.org/wiki/Releases/32/ReleaseBlocking lists minimal raw armhp, but dunno if this is hittiing rhat
17:25:48 <adamw> the matrices are meant to reflect the criteria
17:26:04 <adamw> in case of a discrepancy by default it's the matrices which should be fixed to reflect the criteria rather than vice versa
17:26:13 <adamw> jlanda: no, that's the thing. that's a disk image
17:26:22 <adamw> disk images are deployed, well, basically via dd
17:26:25 <adamw> anaconda doesn't figure
17:26:33 <jlanda> Oh, ok, sorry for the noise then
17:26:39 <adamw> proposed #agreed punt (delay decision), provisionally accepted as a blocker if any 32-bit ARM installer issues can be blockers - this is clearly a blocker *if 32-bit ARM installer issues can be blockers*, we are currently not entirely clear on that point. we will clear this up in discussion with ARM folks and FESCo and update bug as appropriate
17:27:28 <bcotton> ack
17:27:31 <jlanda> ack
17:27:45 <kparal> ack
17:27:52 <coremodule> ack
17:27:56 <pwhalen> ack
17:28:14 <frantisekz> ack
17:28:28 <lruzicka> ack
17:30:15 <pwhalen> could we accept as a FE for now?
17:30:25 <cmurf> +1
17:30:56 <adamw> sure
17:31:12 <adamw> proposed #agreed punt (delay decision) on blocker, AcceptedFreezeException (Beta), provisionally accepted as a blocker if any 32-bit ARM installer issues can be blockers - this is clearly a blocker *if 32-bit ARM installer issues can be blockers*, we are currently not entirely clear on that point. we will clear this up in discussion with ARM folks and FESCo and update bug as appropriate
17:31:28 <pwhalen> thanks
17:31:32 <bcotton> still ack
17:31:38 <lruzicka> ack
17:31:40 <jlanda> ack
17:31:46 <pwhalen> a happier ack from me
17:31:47 <frantisekz> ack
17:33:17 <coremodule> ack
17:33:34 <adamw> #agreed punt (delay decision) on blocker, AcceptedFreezeException (Beta), provisionally accepted as a blocker if any 32-bit ARM installer issues can be blockers - this is clearly a blocker *if 32-bit ARM installer issues can be blockers*, we are currently not entirely clear on that point. we will clear this up in discussion with ARM folks and FESCo and update bug as appropriate
17:33:44 <adamw> ok, hopefully the others will be simpler :)
17:33:52 <adamw> i'll file a ticket for this question or something and tag folks
17:33:56 <adamw> #topic (1807768) dnsmasq user is not created during installation, breaking NAT
17:33:56 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1807768
17:33:56 <adamw> #info Proposed Blocker, virt-manager, NEW
17:34:30 <cmurf> pretty sure this is -1 blocker because virtualization is working with GNOME Boxes
17:34:57 <cmurf> virt-manager doesn't work because the dnsmasq user doesn't exist
17:35:18 <cmurf> it is a regression, it was working before branch, no idea what broke this
17:35:53 <kparal> we've always taken working virt-manager as a requirement
17:36:01 <kparal> there needs to be some criterion around it
17:36:01 <cmurf> i see
17:36:16 <cmurf> then I'm right it's a gray area :D
17:36:24 <lruzicka> gnome-boxes cannot fully replace virt-manager, I believe, we should block on this
17:36:46 <kparal> Recommended virtualization technology
17:36:46 <kparal> ...when using Fedora's recommended virtualization technology, that is. This criterion applies only to the recommended Fedora virtualization tools - the qemu/kvm - libvirt - virt-manager stack.
17:36:56 <pwhalen> +1 blocker, we should have some criteria on it
17:37:04 <pwhalen> and we do
17:37:06 <kparal> https://fedoraproject.org/wiki/Fedora_32_Beta_Release_Criteria#Self_hosting_virtualization
17:37:19 <pwhalen> thanks kparal
17:37:27 <kparal> gnome-boxes must work because all apps must work. And virt-manager must work because we have a criterion for it :)
17:37:35 <jlanda> +1b then
17:37:36 <lruzicka> kparal, cunning
17:37:40 <lruzicka> +1 blocker
17:37:43 <cmurf> HMMM genius!
17:37:53 <bcotton> hm, +1 blocker then
17:37:54 <frantisekz> I am not sure how long is virt-manager going to stay around though, deprecated in some RHEL 8.x
17:37:54 <pwhalen> kparal++
17:37:55 <zodbot> pwhalen: Karma for kparal changed to 4 (for the current release cycle):  https://badges.fedoraproject.org/tags/cookie/any
17:37:56 <cmurf> i'm becoming convinced
17:37:58 <frantisekz> +1 blocker
17:38:01 <kparal> let's wait for adamw's blessing first, though
17:38:14 <kparal> but so far this seems to be +1 blocker
17:38:17 <adamw> +1 sure
17:38:20 <adamw> sorry, i'm multitasking
17:38:20 <lruzicka> frantisekz, are you kidding? what are they using then?
17:38:25 <lruzicka> frantisekz, virsh?
17:38:34 <adamw> and yes, this is according to precedent, we have historically considered both blocking
17:38:37 <frantisekz> cockpit
17:38:45 <cmurf> fair enough, +1 blocker
17:38:53 <cmurf> frantisekz: good point!
17:39:14 <adamw> proposed #agreed 1807768 - AcceptedBlocker (Beta) - accepted as a violation of "The release must be able host virtual guest instances of the same release...This criterion applies only to the recommended Fedora virtualization tools - the qemu/kvm - libvirt - virt-manager stack."
17:39:20 <bcotton> ack
17:39:23 <jlanda> ack
17:39:23 <frantisekz> ack
17:39:33 <adamw> #agreed 1807768 - AcceptedBlocker (Beta) - accepted as a violation of "The release must be able host virtual guest instances of the same release...This criterion applies only to the recommended Fedora virtualization tools - the qemu/kvm - libvirt - virt-manager stack."
17:39:33 <cmurf> ack
17:39:43 <pwhalen> ack
17:39:51 <kparal> ack
17:40:05 <frantisekz> those late acks...
17:40:12 <coremodule> ack
17:40:12 <cmurf> haha
17:40:14 <frantisekz> :D
17:40:29 <lruzicka> ack
17:40:51 <adamw> =)
17:41:21 <coremodule> i could go for a sn-ack
17:41:22 <adamw> as we're in Beta freeze now, next let's do:
17:41:28 <adamw> #topic proposed Beta freeze exceptions
17:41:30 <frantisekz> btw, I've ninjaed AcceptedBetaFE for https://bugzilla.redhat.com/show_bug.cgi?id=1808651 , if somebody was against, just FYI
17:41:38 <adamw> #topic (1806520) pyanaconda.modules.common.errors.storage.MountFilesystemError: Failed to mount sr0 at /tmp/tmphuna95st: mounting filesystem iso9660 is not supported
17:41:38 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1806520
17:41:39 <adamw> #info Proposed Freeze Exceptions, anaconda, POST
17:42:46 <cmurf> +1 FE
17:42:53 <frantisekz> +1 FE
17:42:57 <bcotton> are we voting for final blocker status now, too?
17:43:02 <cmurf> there's a PR to fix it already
17:43:11 <bcotton> since this was nominated for both beta fe & final blocker
17:43:20 <cmurf> good question
17:43:38 <lruzicka> I am +1 FE now, +1 FB
17:44:07 <pwhalen> +1 FE, +1 FB
17:44:07 <cmurf> +1 beta FE, and +1 final blocker
17:44:08 <adamw> sure, we can do both
17:44:19 <bcotton> +1 Beta FE, +1 Final Blocker
17:44:45 <jlanda> +1 beta fe +1 final b
17:44:55 <kparal> +1 beta fe, +1 final blocker
17:45:37 <adamw> proposed #agreed 1806520 - AcceptedFreezeException (Beta), AcceptedBlocker (Final) - accepted as a Final blocker as a violation of "The installer must be able to use an installer update image retrieved from removable media or a remote package source". accepted as a Beta FE as a significant issue which cannot be fixed by update (installer issue)
17:45:46 <bcotton> ack
17:45:51 <cmurf> ack
17:45:59 <frantisekz> ack
17:46:13 <coremodule> ack
17:46:56 <jlanda> Ack
17:47:07 <lruzicka> ack
17:47:19 <adamw> #agreed 1806520 - AcceptedFreezeException (Beta), AcceptedBlocker (Final) - accepted as a Final blocker as a violation of "The installer must be able to use an installer update image retrieved from removable media or a remote package source". accepted as a Beta FE as a significant issue which cannot be fixed by update (installer issue)
17:47:29 <adamw> #topic (1807339) Second pass through INSTALLATION DESTINATION with empty disk complains there is not enough space
17:47:29 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1807339
17:47:29 <adamw> #info Proposed Freeze Exceptions, anaconda, POST
17:47:39 <cmurf> +1 FE, however I think it might be a blocker
17:47:43 <adamw> this fails release-blocking tests on openQA, but only because openQA happens to test in sort of a dumb way
17:47:49 <adamw> i don't *think* it violates any beta criteria
17:47:52 <cmurf> "Bug hinders execution of required Beta test plans or dramatically reduces test coverage"
17:48:24 <cmurf> perhaps it's academic
17:48:28 <cmurf> there is a PR
17:48:37 <cmurf> it's gonna get fixed
17:48:47 <frantisekz> +1 FE
17:48:56 <lruzicka> +1 fe
17:48:59 <bcotton> yeah, i like the idea of calling this a blocker. if the fix in flight doesn't fully fix it, that could be a problem
17:49:00 <pwhalen> +1 FE
17:49:01 <kparal> +1 fe
17:49:11 <bcotton> +1 FE for sure, though
17:49:42 <lruzicka> but I support bcotton for this to be a blocker
17:50:11 <cmurf> from the bug "this breaks all openQA encrypted install tests"
17:50:31 <Eighth_Doctor> that sounds pretty blockerish
17:50:47 <adamw> like i said, it 'breaks' them because of an implementation detail of how the openQA tests work
17:50:52 <lruzicka> cmurf, that is not a criterion, but I believe that this must violate something like "must install on empty media."
17:50:56 <adamw> i *could* make the tests avoid the bug, it'd just involve doing work
17:50:56 <adamw> :P
17:51:11 <lruzicka> because nobody tells you not to hit Done once and then retry.
17:51:25 <adamw> nobody tells you not to, but the criteria don't really require it to work
17:51:34 <lruzicka> adamw, you should be able to hit Done and retry anew
17:51:36 <cmurf> lruzicka: "A bug is considered a Beta blocker bug if any of the following criteria are met: "
17:51:47 <cmurf> and that includes what I quoted earlier
17:51:51 <adamw> lruzicka: sure, you should, but does it need to block a beta release?
17:52:00 <cmurf> I'm on the fence
17:52:11 <adamw> i think we don't need to waste too much time on it
17:52:13 <cmurf> but heck if adamw doesn't think it needs to be a beta blocker OK
17:52:15 <adamw> there's a fix proposed
17:52:21 <adamw> if we accept it as FE the fix should go in
17:52:23 <cmurf> right hence academic question
17:52:24 <adamw> so let's just go with that for now
17:52:25 <lruzicka> adamw, being an indecisive person I personally used this feature like 10 times already.
17:52:29 <adamw> lruzicka: heh
17:52:31 <pwhalen> agreed
17:52:36 <cmurf> haha
17:52:38 <adamw> lruzicka: also, does it actually *break* things?
17:52:47 <adamw> can't you just go through the 'not enough space' dialog and proceed?
17:52:52 <adamw> i didn't bother reproducing manually to check, yet
17:52:59 <lruzicka> adamw, I can, sure.
17:53:06 <adamw> openQA dies at that point because it's not expecting the dialog, but it's not like the installer's crashed or something
17:53:17 <adamw> it's just making you do an extra step
17:53:20 <cmurf> what about making it a final blocker if the fix doesn't fix it?
17:53:28 <adamw> cmurf: let's burn that bridge if we get to it?
17:53:31 <cmurf> ok
17:53:50 <lruzicka> adamw, that is not wise ... let's burn it, when we pass it
17:54:12 <adamw> proposed #agreed 1807339 - AcceptedFreezeException (Beta) - this is accepted as a noticeable issue that cannot be fixed with an update (installer issue), and due to its impact on openQA tests. if the fix is delayed or doesn't work we may also consider it as a Beta or Final blocker
17:54:17 <bcotton> ack
17:54:19 <lruzicka> ack
17:54:21 <frantisekz> ack
17:54:22 <cmurf> ack
17:54:24 <kparal> ack
17:54:24 <pwhalen> ack
17:54:29 <adamw> lruzicka: the usual english idiom is "cross that bridge when we come to it", but i've always liked my version :P
17:54:37 <adamw> #agreed 1807339 - AcceptedFreezeException (Beta) - this is accepted as a noticeable issue that cannot be fixed with an update (installer issue), and due to its impact on openQA tests. if the fix is delayed or doesn't work we may also consider it as a Beta or Final blocker
17:54:40 <bcotton> +1 adam's version
17:54:54 * adamw also fond of 'that train has sailed'
17:55:01 <pwhalen> heh
17:55:16 <cmurf> oh i'm stealing that one
17:55:19 <adamw> #topic (1807679) enable fedora-cisco-openh264 repo by default
17:55:19 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1807679
17:55:19 <adamw> #info Proposed Freeze Exceptions, fedora-repos, NEW
17:55:32 <lruzicka> adamw, I see
17:55:36 <cmurf> +1 FE
17:55:49 <frantisekz> +1 FE
17:55:51 <adamw> if this is a thing that's supposed to happen, sure, makes sense to do it in beta
17:55:54 <adamw> assuming the repos are actually ready?
17:56:01 <kparal> +1 fe
17:56:02 <lruzicka> +1 fe
17:56:13 <pwhalen> +1 fe
17:56:35 <frantisekz> adamw, repos seem to be ready: https://codecs.fedoraproject.org/openh264/32/
17:56:44 <adamw> um
17:56:49 <adamw> i am a little confused by the wording here
17:56:56 <cmurf> probably my fault
17:57:02 <adamw> "In order to implement this in a way that complies with current policy, composes must have this repo *disabled* so that weak dependencies do not pull in software into the media and install trees distributed by Fedora."
17:57:17 <adamw> are you saying that the repo should be enabled by default in the package, but composes need to take special action to disable it at compose time?
17:57:24 <adamw> if so, has that been sorted out with releng yet?
17:57:27 <cmurf> correct
17:57:30 <cmurf> yes
17:57:35 <Eighth_Doctor> adamw: I filed the ticket: https://pagure.io/releng/issue/9246
17:57:49 <Eighth_Doctor> no response from releng types, so I dunno
17:57:55 <cmurf> and i pinged mboddu about that last week
17:58:11 <cmurf> the idea is for the first update to install the contents of this repo
17:58:24 <cmurf> but that the install media should not have the contents of the repo
17:58:28 <cmurf> contents = packages
17:58:43 * mboddu looking
17:59:31 <mboddu> I was waiting on the PR to be rebased, its done. I can build it now, it should be fixed soon
17:59:48 <adamw> um
17:59:49 <adamw> um um um
18:00:10 <adamw> we should not merge the fedora-repos PR before we merge whatever change is needed to make sure the repo gets disabled during the compose process, should we?
18:00:13 <adamw> that seems like it would be wrong
18:00:21 <cmurf> could be yes
18:00:37 <cmurf> otherwise we get nightlies with the software actually on it
18:01:01 <mboddu> adamw: They are not enabled in compose process
18:01:40 <cmurf> ok good
18:01:47 <mboddu> nirik and I checked it
18:02:18 <adamw> but
18:02:21 <adamw> if we merge this pr
18:02:24 <adamw> would they be?
18:02:51 <mboddu> Nope, only the repo will be enabled
18:03:34 <mboddu> I checked kickstarts, comps and pungi configs, they are not enabled anywhere
18:03:45 <adamw> can you please be specific about what you mean by "they" and "the repo"
18:04:46 <lruzicka> I think "they" means the actual packages and the "repo" means the codec repo that should be enabled by default, am I right, mboddu?
18:05:13 <adamw> that does not sound right
18:05:35 <adamw> the problem cmurf highlights is that there are existing weak dependencies in the package set which would cause the packages to be pulled in if the repo is enabled during composes
18:05:39 <mboddu> they = openh264 codecs packages, "the repo" = openh264 repo
18:05:50 <mboddu> lruzicka: yes, you are right
18:05:54 <adamw> so he is saying the repo should not be enabled during composes in order to prevent this
18:06:10 <adamw> just checking the packages are not explicitly listed in comps or kickstarts is not enough
18:06:25 <mboddu> adamw: Ahhh, I see your point
18:06:28 <lruzicka> adamw, as I picture it, it is not enabled for composes, but the composes end up with that repo enabled (no packages installed)
18:06:29 <cmurf> /etc/yum.repos.d/fedora-cisco-openh264.repo enabled=1 on the install media, but enabled=0 when creating the install media
18:06:30 <adamw> correct, cmurf?
18:06:52 <adamw> so
18:06:54 <cmurf> adamw: that's my understanding
18:06:57 <cmurf> Eighth_Doctor: ?
18:07:00 <adamw> in theory i'm +1 to this
18:07:08 <Eighth_Doctor> sounds fine with me
18:07:23 <adamw> but i think we need to be very sure that releng and workstation wg are on the same page about the consequences before we actually land it
18:07:24 <mboddu> Then we might have to inject into something into compose process to disable the openh264 repo
18:07:29 <Eighth_Doctor> I was mainly concerned with compose artifacts that are non-kickstart based: like the DVD ISO
18:07:49 <cmurf> ahhh
18:08:01 <cmurf> so there's no DVD ISO for Workstation
18:08:06 <cmurf> there is a Live ISO
18:08:22 <Eighth_Doctor> but there is a DVD ISO for Server
18:08:40 <cmurf> but this change should only affect Workstation
18:09:13 <Eighth_Doctor> it won't
18:09:28 <Eighth_Doctor> it affects everybody
18:09:42 <mboddu> fedora-repos package affects everything
18:10:00 <Eighth_Doctor> I'm reasonably confident on the kickstart based stuff, since they specify repos already, and OSTree based stuff has its own filtering mechanism, so that leaves the stuff purely built through pungi, which are install media
18:10:22 <cmurf> gotcha
18:10:30 <adamw> proposed #agreed 1807679 - AcceptedFreezeException (Beta) - this is accepted as a freeze exception as it makes sense to change this in Beta if we intend to have it changed for Final, but we will not actually push the update stable until we're sure workstation WG and releng are on the same page about the consequences and any necessary changes to ensure the result is as intended
18:10:55 <cmurf> ack
18:10:56 <frantisekz> ack
18:11:03 <lruzicka> ack
18:11:05 <Eighth_Doctor> ack
18:11:09 <pwhalen> ack
18:11:20 <bcotton> ack
18:11:32 <coremodule> ack
18:11:33 <adamw> #agreed 1807679 - AcceptedFreezeException (Beta) - this is accepted as a freeze exception as it makes sense to change this in Beta if we intend to have it changed for Final, but we will not actually push the update stable until we're sure workstation WG and releng are on the same page about the consequences and any necessary changes to ensure the result is as intended
18:11:43 <adamw> #topic (1807692) fedora-repos-32-0.6 requires fedora-repos-rawhide
18:11:43 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1807692
18:11:43 <adamw> #info Proposed Freeze Exceptions, fedora-repos, NEW
18:11:57 <adamw> this might be blocker, if it means f32 installs get updates from rawhide by default
18:11:59 <adamw> i didn't check that
18:12:10 <mboddu> I am fixing it right now
18:12:40 <adamw> but it's definitely fe...
18:12:55 <mboddu> +1 FE
18:12:58 <bcotton> +1 fe
18:13:02 <pwhalen> +1FE
18:13:07 <frantisekz> ₊ FE
18:13:12 <Eighth_Doctor> +1 FE
18:13:16 <frantisekz> +1 FE...
18:13:24 <lruzicka> +1
18:13:48 <cmurf> +1 FE
18:14:15 <jlanda> +1 fe
18:15:37 <adamw> proposed #agreed 1807692 - AcceptedFreezeException (Beta) - accepted as a prominent issue that will affect all installs and cannot be entirely fixed with an update
18:15:47 <jlanda> ack
18:15:47 <coremodule> ack
18:16:31 <pwhalen> ack
18:17:08 <cmurf> ack
18:17:21 <bcotton> ack
18:17:30 <adamw> #agreed 1807692 - AcceptedFreezeException (Beta) - accepted as a prominent issue that will affect all installs and cannot be entirely fixed with an update
18:17:39 <adamw> #topic (1799606) libx86emu: FTBFS in Fedora rawhide/f32
18:17:39 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1799606
18:17:39 <adamw> #info Proposed Freeze Exceptions, libx86emu, MODIFIED
18:19:29 <cmurf> +1 FE
18:19:52 <Southern_Gentlem> +1 FE
18:20:02 <pwhalen> +1FE
18:20:05 <adamw> i mean, it's not that important what's in the frozen beta tree, really
18:20:09 <adamw> but can't hurt
18:20:14 <adamw> (famous last words)
18:20:17 <bcotton> +0.5 FE
18:20:22 <lruzicka> +1 FE
18:20:30 <frantisekz> don't have it installed on my system, don't know what is it for... +1 FE though
18:20:41 <adamw> it's not in comps so shouldn't affect any image composes
18:20:50 <Eighth_Doctor> it's the library dependency for the hwinfo diagnostic tool
18:20:54 <lruzicka> adamw, famous last words are "nothing is approaching from the right side."
18:21:05 <adamw> "what's the worst that could possibly happ"
18:21:12 <Eighth_Doctor> don't... just don't
18:21:28 <Eighth_Doctor> that's a phrase that should never be uttered 😛
18:21:35 <cmurf> it's a good point
18:21:40 <cmurf> two of them even
18:22:00 <adamw> proposed #agreed 1799606 - AcceptedFreezeException (Beta) - accepted as we usually accept FTBFS fixes in order for the package to make the frozen trees, this isn't very important but should not affect composes in any way
18:22:05 <adamw> patch
18:22:12 <adamw> proposed #agreed 1799606 - AcceptedFreezeException (Beta) - accepted as we usually accept FTBFS fixes in order for the package to make the frozen trees, this isn't very important but should not affect release-blocking contents in any way
18:22:18 <frantisekz> ack
18:22:25 <Southern_Gentlem> ack
18:22:27 <lruzicka> ack
18:22:29 <cmurf> the s word
18:24:03 <adamw> #agreed 1799606 - AcceptedFreezeException (Beta) - accepted as we usually accept FTBFS fixes in order for the package to make the frozen trees, this isn't very important but should not affect release-blocking contents in any way
18:24:21 <adamw> mclasen: so, i don't see a gnome megaupdate proposed yet
18:24:25 <adamw> do you folks want to do one?
18:25:00 <mclasen> -> kalev
18:25:03 * mclasen is on vacation
18:25:27 <lruzicka> mclasen, nice bot
18:25:31 <frantisekz> :D
18:25:45 <frantisekz> .92 update should be ready in a few days it seems
18:25:47 <kalev> right. I think it could work out schedule wise to try to include 3.35.92 in beta, but only if QA is up for helping out with that
18:25:56 <kalev> I'm putting together the .92 update right now
18:26:10 <frantisekz> I'd vote for .92 to be included in beta
18:26:15 <lruzicka> mclasen: nice bot, second try
18:26:25 <kalev> I think it would be fine to leave it as a 0 day update as well, but if everybody is on board with including it as a FE, then sure, let's do that
18:26:46 <lruzicka> * thinks that it might not be a bot after all
18:26:54 <lruzicka> sorry, I had to try
18:26:57 <frantisekz> kalev, would you create fe ticket? I can do that too
18:27:04 <kalev> sure, let me do one
18:27:08 <kalev> give me a minute
18:27:08 <frantisekz> okay
18:28:22 <adamw> mclasen: oh, sorry, i saw you join so figured that was why
18:28:33 * adamw plays muzak
18:28:48 <mclasen> no worries, I'll leave
18:28:49 <adamw> your current wait time is: however fast kalev types
18:29:02 * Southern_Gentlem thinks sooner the better on stuff that may end up blocking down the road
18:31:37 <kalev> done: https://bugzilla.redhat.com/show_bug.cgi?id=1809270
18:32:27 <Southern_Gentlem> +1 FE
18:32:43 <cmurf> +1 FE
18:32:47 <adamw> hey, you can't vote yet!
18:32:51 <adamw> stoppit stoppit stoppit
18:33:24 <Southern_Gentlem> ack ack ack
18:33:31 <adamw> .fire southern_gentlem
18:33:31 <zodbot> adamw fires southern_gentlem
18:33:42 <cmurf> where is the kabooM? there is supposed to be an earth shattering kaboom!
18:33:58 <adamw> #topic (1809270) Include GNOME 3.35.92 in F32 Beta
18:34:01 <Southern_Gentlem> i am a contributor, so i am not an employee
18:34:05 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1809270
18:34:14 <cmurf> +1 FE
18:34:16 <frantisekz> +1 FE
18:34:18 <adamw> #info Proposed Freeze Exceptions, distribution, NEW
18:34:19 <Southern_Gentlem> +1 FE
18:34:22 <adamw> Southern_Gentlem: i can fire anyone
18:34:33 <cmurf> in fact, adamw can also hire them
18:34:35 <adamw> .fire jimw see?
18:34:38 <zodbot> adamw fires jimw see?
18:34:41 <cmurf> and them make them do things
18:34:51 <cmurf> like get fired
18:34:51 <adamw> muahahahaha
18:35:15 <bcotton> +1 FE (fire everyone)
18:35:25 <pwhalen> +1 FE
18:35:29 <lruzicka> + 1de
18:35:32 <lruzicka> fe
18:35:37 <kparal> +1 fe
18:36:22 <adamw> well that was fast!
18:37:01 <adamw> proposed #agreed 1809270 - AcceptedFreezeException (Beta) - this is a major change but we're still relatively far out from Beta and think we have sufficient time to land it if it tests out well, and it is a significant benefit to test closer to the final release
18:37:04 <Southern_Gentlem> ack
18:37:10 <kalev> ack
18:37:15 <frantisekz> ack
18:37:58 <kparal> ack
18:38:02 <cmurf> ack
18:38:31 <adamw> #agreed 1809270 - AcceptedFreezeException (Beta) - this is a major change but we're still relatively far out from Beta and think we have sufficient time to land it if it tests out well, and it is a significant benefit to test closer to the final release
18:39:43 <adamw> ok, moving on to:
18:40:02 <adamw> #topic Proposed Final blockers
18:40:28 <adamw> #info we already did #1806520
18:40:33 <adamw> #topic (1809107) Maximize doesn't work on GNOME Wayland, moves window partly off-screen
18:40:33 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1809107
18:40:33 <adamw> #info Proposed Blocker, firefox, NEW
18:40:52 <kalev> I'd like to point out that F32 doesn't have latest firefox
18:41:02 <adamw> this has been a problem for weeks, i just never got around to filing it
18:41:03 <kalev> would be nice to get that in first
18:41:09 <adamw> kinda assumed it was specific to my setup in some way
18:41:13 <kalev> (the builds have been failing)
18:41:40 <frantisekz> yeah... because armv7 was enabled in firefox... and it's broken the same way as in mozjs68 since gcc10
18:41:48 <kalev> ahh! :)
18:42:19 <adamw> frantisekz: is there some kind of plan there
18:42:19 <adamw> ?
18:42:30 <frantisekz> I'd ping mstransky about that... on one hand, I would be happy if somebody else solved mozjs problem :D , on the other hand, I'd be better to have latest firefox
18:42:53 <frantisekz> the plan is to let somebody that understands c/armv7 specifics better than me to fix it :D
18:43:12 <frantisekz> I'll try to ping firefox devs tomorrow about that :)
18:43:36 <bcotton> +1 blocker given the screencast. if it were off by a few px i would shrug it off, but that's pretty excessive
18:44:08 <bcotton> (i reserve the right to word-lawyer the words "basic functionality" if it's the last blocker remaining at go/no-go)
18:44:10 <adamw> the latest build looks like it failed on all arches...
18:45:39 <frantisekz> hmm, yeah, I didn't check the others, but it'll fail somewhere else on 100% than in armv7
18:46:51 <kparal> +1 blocker
18:46:55 <frantisekz> koji is slow as hell...
18:47:12 <lruzicka> +1 blocker
18:47:37 <cmurf> it's pretty wonky in my limited experience so far
18:47:46 <cmurf> +1 blocker
18:47:47 <frantisekz> +1 blocker
18:47:54 <pwhalen> +1 blocker
18:48:02 <frantisekz> cmurf, since gcc10, some armv7 structures changed their size
18:48:11 <frantisekz> and Firefox apparently needs to be adjusted for that
18:48:31 <frantisekz> if I nuked all asserts, the resulting binary was unusable (instant SIGSEGV)
18:49:00 <cmurf> pagure is hanging on me again
18:49:12 <frantisekz> yeah... adamw, compile fails much more further on all archs but armv7
18:50:18 <adamw> proposed #agreed 1809107 - AcceptedBlocker (Final) - we accept this as a blocker as a violation of "ll 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", this is held to be 'basic functionality' for a commonly-used app like Firefox
18:50:24 <adamw> patch:
18:50:30 <adamw> proposed #agreed 1809107 - AcceptedBlocker (Final) - we accept this as a blocker 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", this is held to be 'basic functionality' for a commonly-used app like Firefox
18:50:35 <adamw> (missed one character :>)
18:50:42 <kparal> ack
18:50:48 <Southern_Gentlem> ack
18:50:48 <frantisekz> ack
18:51:03 <lruzicka> ack
18:51:22 <pwhalen> ack
18:51:25 <kalev> ack
18:51:43 <adamw> #agreed 1809107 - AcceptedBlocker (Final) - we accept this as a blocker 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", this is held to be 'basic functionality' for a commonly-used app like Firefox
18:52:55 <adamw> ok, let's take a quick look at:
18:52:58 <adamw> #topic Accepted Beta blockers
18:53:30 <adamw> #info most blockers are under active development
18:53:39 <adamw> let's hit a couple that worry me a bit:
18:53:40 <adamw> #topic (1807342) Fedora 32 backgrounds not included
18:53:40 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1807342
18:53:40 <adamw> #info Accepted Blocker, distribution, NEW
18:53:48 <adamw> bcotton, are you in touch with relevant folks here?
18:53:54 <frantisekz> https://bugzilla.redhat.com/show_bug.cgi?id=1804564 , seems not to be
18:54:40 <adamw> frantisekz: yes, that's coming up
18:54:44 <adamw> .fire frantisekz no previews
18:54:44 <zodbot> adamw fires frantisekz no previews
18:55:11 <frantisekz> yeah, sorry, missed that you changed topic :O :D
18:57:45 <bcotton> adamw: design team has been discussing this, i'll give them another nudge
18:57:55 <adamw> okay, thanks
18:58:10 <adamw> #info bcotton is working with the design team on this, will continue to nudge it
18:59:15 <adamw> #topic (1804564) Cannot upgrade to Fedora 32: Modules blocking the upgrade path
18:59:15 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1804564
18:59:15 <adamw> #info Accepted Blocker, PackageKit, NEW
19:00:07 <frantisekz> seems like PackageKit devs don't care too much :(
19:01:06 <cmurf> that is concerning
19:01:18 <adamw> so, as frantisekz noted - we are sort of hanging here
19:01:56 <cmurf> this relates to the modularity heavy hammer approach that's been decided?
19:02:09 <adamw> for context, this is a redux/continuation of the issues we had with modules affecting upgrades in f31. for f31 we did a hack where a specific module was disabled prior to the upgrade running. for f32 the idea is now that we disable *all* modules prior to the upgrade running
19:02:32 <adamw> this is more or less done for dnf/libdnf: https://bugzilla.redhat.com/show_bug.cgi?id=1767351 is the bug tracking that
19:02:45 <adamw> but we also need to do the same thing in PackageKit, for upgrades run via gnome-software, and that's what this bug is for
19:03:01 <cmurf> why is it a final blocker and not beta?
19:03:12 <cmurf> i see the the criterion for upgrades is for beta
19:03:26 <cmurf> oh that's for upgrades from clean installs hmmmm
19:04:08 <adamw> they're both beta blockers
19:04:11 <adamw> we're on accepted beta blockers here
19:04:27 <cmurf> oh
19:04:30 <cmurf> ha
19:04:32 <cmurf> sorry
19:05:02 <bcotton> i'll email rhughes and see if I can get him to respond to the bug
19:05:26 <cmurf> kalev might respond faster
19:05:30 <bcotton> he got NEEDINFO'ed last monday, so if he's been on vacation or something he might not have seen it yet
19:07:20 <adamw> #action bcotton to follow up on this issue with hughesie and try to make sure it gets addressed
19:07:30 <adamw> #topic Open floor
19:07:33 <adamw> OK, that's all I got
19:07:44 <adamw> anything missed, any other f32-beta-related concerns, etc?
19:10:19 <adamw> i guess not!
19:10:45 <adamw> thanks for coming, everyone
19:11:30 <frantisekz> thanks
19:11:54 <adamw> #endmeeting