17:00:58 #startmeeting F32-blocker-review 17:00:58 #meetingname F32-blocker-review 17:00:58 #topic Roll Call 17:00:58 Meeting started Mon Mar 2 17:00:58 2020 UTC. 17:00:58 This meeting is logged and archived in a public location. 17:00:58 The chair is adamw. Information about MeetBot at http://wiki.debian.org/MeetBot. 17:00:58 Useful Commands: #action #agreed #halp #info #idea #link #topic. 17:00:58 The meeting name has been set to 'f32-blocker-review' 17:00:58 The meeting name has been set to 'f32-blocker-review' 17:01:04 who's around for blocker fun? 17:01:32 .hello2 17:01:33 frantisekz: frantisekz 'František Zatloukal' 17:01:56 .hello2 17:01:57 bcotton: bcotton 'Ben Cotton' 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 .hello2 17:04:38 lruzicka: lruzicka 'Lukáš Růžička' 17:05:45 #chair lruzicka kparal 17:05:45 Current chairs: adamw kparal lruzicka 17:05:59 boilerplate time! 17:06:00 #topic Introduction 17:06:00 Why are we here? 17:06:00 #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 #info We'll be following the process outlined at: 17:06:01 #link https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting 17:06:03 #info The bugs up for review today are available at: 17:06:05 #link http://qa.fedoraproject.org/blockerbugs/current 17:06:07 #info The criteria for release blocking bugs can be found at: 17:06:09 #link https://fedoraproject.org/wiki/Basic_Release_Criteria 17:06:11 #link https://fedoraproject.org/wiki/Fedora_32_Beta_Release_Criteria 17:06:13 #link https://fedoraproject.org/wiki/Fedora_32_Final_Release_Criteria 17:06:15 #action coremodule will secretarialize 17:07:04 #info for Beta, we have: 17:07:05 #info 2 Proposed Blockers 17:07:05 #info 7 Accepted Blockers 17:07:09 #info 5 Proposed Freeze Exceptions 17:07:09 #info 3 Accepted Freeze Exceptions 17:07:11 #info for Final, we have: 17:07:17 #info 2 Proposed Blockers 17:07:17 #info 3 Accepted Blockers 17:07:26 so, let's get started with: 17:07:30 #topic proposed Beta blockers 17:07:45 #topic (1807252) bootloader entry missing after installation on armhfp 17:07:45 #link https://bugzilla.redhat.com/show_bug.cgi?id=1807252 17:07:45 #info Proposed Blocker, anaconda, POST 17:08:06 seems like +1 to me 17:08:10 hmmm 17:08:10 well 17:08:23 per https://fedoraproject.org/wiki/Releases/32/ReleaseBlocking we do not actually have a release-blocking ARM installer image 17:08:31 how did I miss this 17:08:40 the only release-blocking ARM images are disk images, which don't run anaconda to install 17:08:41 I wasnt sure about the criteria. The system does boot, just uses the rescue entry 17:08:46 is this intentional? or are we missing something? 17:08:52 hmm 17:09:04 the bug says it's been fixed, so it does not look like intention 17:09:16 oh it's ew 17:09:18 adamw: see https://pagure.io/fedora-qa/issue/615 17:09:20 lruzicka, I think adamw is talking about wiki 17:09:24 haha, s/ew/new 17:09:50 this is either waiting on pbrobinson or bcotton 17:10:08 or pwhalen :) 17:10:26 frantisekz, oh well 17:10:56 I wonder if I linked the right ticket 17:10:56 right, i meant is it intentional that we have no release-blocking installer images on ARM 17:11:36 this *did* change at some point 17:11:52 it looks like it changed between 30 and 31 17:11:53 adamw, good question- minimally we need the installer working for installing builders 17:12:04 * pwhalen wasnt aware 17:12:12 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 for 31, when bcotton simplified the page, it got dropped 17:12:30 https://fedoraproject.org/wiki/Releases/31/ReleaseBlocking 17:12:34 d'oh 17:12:38 i don't know if that's intentional on someone's part, or an oversight 17:12:53 .hello2 ngompa 17:12:54 Eighth_Doctor: Sorry, but you don't exist 17:13:06 probably an oversight then. i don't recall an explicit call to drop it 17:13:13 Eighth_Doctor, with nickname just .hello 17:13:20 .hello ngompa 17:13:21 Eighth_Doctor: ngompa 'Neal Gompa' 17:14:26 the only change i remember is the recent one to drop Xfce and add Workstation on ARM 17:15:01 some arm-minimal stuff should remain blocking afaik 17:15:29 adamw: wait. the everything netinst was *not* blocking on the F30 page except for x86_64 17:15:47 oh yes, you're right 17:15:48 i misread it 17:15:53 hrrmff 17:16:19 the server dvd *was* blocking on aarch64...but not armhfp... 17:18:29 afaics we haven't had a release-blocking 32-bit ARM installer image for many releases 17:18:30 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 seems like a disconnect, then 17:19:05 builders can't be deployed via disk images? 17:19:51 adamw, I guess they could be.. would need tweaking for. Disk images dont use swap anymore 17:20:59 okay. hm. 17:21:02 thinking how best to proceed here. 17:21:57 minimal was arm blocker, is not that enough? 17:22:30 jlanda: where? 17:23:59 adamw, the matrices also list the arm install tests as basic(required). 17:23:59 release blocking deliverables just list the armhp raw image tho 17:25:43 pwhalen: true, but the criteria are 'more authoritative' than the matrices generally speaking 17:25:44 https://fedoraproject.org/wiki/Releases/32/ReleaseBlocking lists minimal raw armhp, but dunno if this is hittiing rhat 17:25:48 the matrices are meant to reflect the criteria 17:26:04 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 jlanda: no, that's the thing. that's a disk image 17:26:22 disk images are deployed, well, basically via dd 17:26:25 anaconda doesn't figure 17:26:33 Oh, ok, sorry for the noise then 17:26:39 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 ack 17:27:31 ack 17:27:45 ack 17:27:52 ack 17:27:56 ack 17:28:14 ack 17:28:28 ack 17:30:15 could we accept as a FE for now? 17:30:25 +1 17:30:56 sure 17:31:12 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 thanks 17:31:32 still ack 17:31:38 ack 17:31:40 ack 17:31:46 a happier ack from me 17:31:47 ack 17:33:17 ack 17:33:34 #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 ok, hopefully the others will be simpler :) 17:33:52 i'll file a ticket for this question or something and tag folks 17:33:56 #topic (1807768) dnsmasq user is not created during installation, breaking NAT 17:33:56 #link https://bugzilla.redhat.com/show_bug.cgi?id=1807768 17:33:56 #info Proposed Blocker, virt-manager, NEW 17:34:30 pretty sure this is -1 blocker because virtualization is working with GNOME Boxes 17:34:57 virt-manager doesn't work because the dnsmasq user doesn't exist 17:35:18 it is a regression, it was working before branch, no idea what broke this 17:35:53 we've always taken working virt-manager as a requirement 17:36:01 there needs to be some criterion around it 17:36:01 i see 17:36:16 then I'm right it's a gray area :D 17:36:24 gnome-boxes cannot fully replace virt-manager, I believe, we should block on this 17:36:46 Recommended virtualization technology 17:36:46 ...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 +1 blocker, we should have some criteria on it 17:37:04 and we do 17:37:06 https://fedoraproject.org/wiki/Fedora_32_Beta_Release_Criteria#Self_hosting_virtualization 17:37:19 thanks kparal 17:37:27 gnome-boxes must work because all apps must work. And virt-manager must work because we have a criterion for it :) 17:37:35 +1b then 17:37:36 kparal, cunning 17:37:40 +1 blocker 17:37:43 HMMM genius! 17:37:53 hm, +1 blocker then 17:37:54 I am not sure how long is virt-manager going to stay around though, deprecated in some RHEL 8.x 17:37:54 kparal++ 17:37:55 pwhalen: Karma for kparal changed to 4 (for the current release cycle): https://badges.fedoraproject.org/tags/cookie/any 17:37:56 i'm becoming convinced 17:37:58 +1 blocker 17:38:01 let's wait for adamw's blessing first, though 17:38:14 but so far this seems to be +1 blocker 17:38:17 +1 sure 17:38:20 sorry, i'm multitasking 17:38:20 frantisekz, are you kidding? what are they using then? 17:38:25 frantisekz, virsh? 17:38:34 and yes, this is according to precedent, we have historically considered both blocking 17:38:37 cockpit 17:38:45 fair enough, +1 blocker 17:38:53 frantisekz: good point! 17:39:14 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 ack 17:39:23 ack 17:39:23 ack 17:39:33 #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 ack 17:39:43 ack 17:39:51 ack 17:40:05 those late acks... 17:40:12 ack 17:40:12 haha 17:40:14 :D 17:40:29 ack 17:40:51 =) 17:41:21 i could go for a sn-ack 17:41:22 as we're in Beta freeze now, next let's do: 17:41:28 #topic proposed Beta freeze exceptions 17:41:30 btw, I've ninjaed AcceptedBetaFE for https://bugzilla.redhat.com/show_bug.cgi?id=1808651 , if somebody was against, just FYI 17:41:38 #topic (1806520) pyanaconda.modules.common.errors.storage.MountFilesystemError: Failed to mount sr0 at /tmp/tmphuna95st: mounting filesystem iso9660 is not supported 17:41:38 #link https://bugzilla.redhat.com/show_bug.cgi?id=1806520 17:41:39 #info Proposed Freeze Exceptions, anaconda, POST 17:42:46 +1 FE 17:42:53 +1 FE 17:42:57 are we voting for final blocker status now, too? 17:43:02 there's a PR to fix it already 17:43:11 since this was nominated for both beta fe & final blocker 17:43:20 good question 17:43:38 I am +1 FE now, +1 FB 17:44:07 +1 FE, +1 FB 17:44:07 +1 beta FE, and +1 final blocker 17:44:08 sure, we can do both 17:44:19 +1 Beta FE, +1 Final Blocker 17:44:45 +1 beta fe +1 final b 17:44:55 +1 beta fe, +1 final blocker 17:45:37 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 ack 17:45:51 ack 17:45:59 ack 17:46:13 ack 17:46:56 Ack 17:47:07 ack 17:47:19 #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 #topic (1807339) Second pass through INSTALLATION DESTINATION with empty disk complains there is not enough space 17:47:29 #link https://bugzilla.redhat.com/show_bug.cgi?id=1807339 17:47:29 #info Proposed Freeze Exceptions, anaconda, POST 17:47:39 +1 FE, however I think it might be a blocker 17:47:43 this fails release-blocking tests on openQA, but only because openQA happens to test in sort of a dumb way 17:47:49 i don't *think* it violates any beta criteria 17:47:52 "Bug hinders execution of required Beta test plans or dramatically reduces test coverage" 17:48:24 perhaps it's academic 17:48:28 there is a PR 17:48:37 it's gonna get fixed 17:48:47 +1 FE 17:48:56 +1 fe 17:48:59 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 +1 FE 17:49:01 +1 fe 17:49:11 +1 FE for sure, though 17:49:42 but I support bcotton for this to be a blocker 17:50:11 from the bug "this breaks all openQA encrypted install tests" 17:50:31 that sounds pretty blockerish 17:50:47 like i said, it 'breaks' them because of an implementation detail of how the openQA tests work 17:50:52 cmurf, that is not a criterion, but I believe that this must violate something like "must install on empty media." 17:50:56 i *could* make the tests avoid the bug, it'd just involve doing work 17:50:56 :P 17:51:11 because nobody tells you not to hit Done once and then retry. 17:51:25 nobody tells you not to, but the criteria don't really require it to work 17:51:34 adamw, you should be able to hit Done and retry anew 17:51:36 lruzicka: "A bug is considered a Beta blocker bug if any of the following criteria are met: " 17:51:47 and that includes what I quoted earlier 17:51:51 lruzicka: sure, you should, but does it need to block a beta release? 17:52:00 I'm on the fence 17:52:11 i think we don't need to waste too much time on it 17:52:13 but heck if adamw doesn't think it needs to be a beta blocker OK 17:52:15 there's a fix proposed 17:52:21 if we accept it as FE the fix should go in 17:52:23 right hence academic question 17:52:24 so let's just go with that for now 17:52:25 adamw, being an indecisive person I personally used this feature like 10 times already. 17:52:29 lruzicka: heh 17:52:31 agreed 17:52:36 haha 17:52:38 lruzicka: also, does it actually *break* things? 17:52:47 can't you just go through the 'not enough space' dialog and proceed? 17:52:52 i didn't bother reproducing manually to check, yet 17:52:59 adamw, I can, sure. 17:53:06 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 it's just making you do an extra step 17:53:20 what about making it a final blocker if the fix doesn't fix it? 17:53:28 cmurf: let's burn that bridge if we get to it? 17:53:31 ok 17:53:50 adamw, that is not wise ... let's burn it, when we pass it 17:54:12 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 ack 17:54:19 ack 17:54:21 ack 17:54:22 ack 17:54:24 ack 17:54:24 ack 17:54:29 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 #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 +1 adam's version 17:54:54 * adamw also fond of 'that train has sailed' 17:55:01 heh 17:55:16 oh i'm stealing that one 17:55:19 #topic (1807679) enable fedora-cisco-openh264 repo by default 17:55:19 #link https://bugzilla.redhat.com/show_bug.cgi?id=1807679 17:55:19 #info Proposed Freeze Exceptions, fedora-repos, NEW 17:55:32 adamw, I see 17:55:36 +1 FE 17:55:49 +1 FE 17:55:51 if this is a thing that's supposed to happen, sure, makes sense to do it in beta 17:55:54 assuming the repos are actually ready? 17:56:01 +1 fe 17:56:02 +1 fe 17:56:13 +1 fe 17:56:35 adamw, repos seem to be ready: https://codecs.fedoraproject.org/openh264/32/ 17:56:44 um 17:56:49 i am a little confused by the wording here 17:56:56 probably my fault 17:57:02 "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 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 if so, has that been sorted out with releng yet? 17:57:27 correct 17:57:30 yes 17:57:35 adamw: I filed the ticket: https://pagure.io/releng/issue/9246 17:57:49 no response from releng types, so I dunno 17:57:55 and i pinged mboddu about that last week 17:58:11 the idea is for the first update to install the contents of this repo 17:58:24 but that the install media should not have the contents of the repo 17:58:28 contents = packages 17:58:43 * mboddu looking 17:59:31 I was waiting on the PR to be rebased, its done. I can build it now, it should be fixed soon 17:59:48 um 17:59:49 um um um 18:00:10 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 that seems like it would be wrong 18:00:21 could be yes 18:00:37 otherwise we get nightlies with the software actually on it 18:01:01 adamw: They are not enabled in compose process 18:01:40 ok good 18:01:47 nirik and I checked it 18:02:18 but 18:02:21 if we merge this pr 18:02:24 would they be? 18:02:51 Nope, only the repo will be enabled 18:03:34 I checked kickstarts, comps and pungi configs, they are not enabled anywhere 18:03:45 can you please be specific about what you mean by "they" and "the repo" 18:04:46 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 that does not sound right 18:05:35 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 they = openh264 codecs packages, "the repo" = openh264 repo 18:05:50 lruzicka: yes, you are right 18:05:54 so he is saying the repo should not be enabled during composes in order to prevent this 18:06:10 just checking the packages are not explicitly listed in comps or kickstarts is not enough 18:06:25 adamw: Ahhh, I see your point 18:06:28 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 /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 correct, cmurf? 18:06:52 so 18:06:54 adamw: that's my understanding 18:06:57 Eighth_Doctor: ? 18:07:00 in theory i'm +1 to this 18:07:08 sounds fine with me 18:07:23 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 Then we might have to inject into something into compose process to disable the openh264 repo 18:07:29 I was mainly concerned with compose artifacts that are non-kickstart based: like the DVD ISO 18:07:49 ahhh 18:08:01 so there's no DVD ISO for Workstation 18:08:06 there is a Live ISO 18:08:22 but there is a DVD ISO for Server 18:08:40 but this change should only affect Workstation 18:09:13 it won't 18:09:28 it affects everybody 18:09:42 fedora-repos package affects everything 18:10:00 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 gotcha 18:10:30 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 ack 18:10:56 ack 18:11:03 ack 18:11:05 ack 18:11:09 ack 18:11:20 ack 18:11:32 ack 18:11:33 #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 #topic (1807692) fedora-repos-32-0.6 requires fedora-repos-rawhide 18:11:43 #link https://bugzilla.redhat.com/show_bug.cgi?id=1807692 18:11:43 #info Proposed Freeze Exceptions, fedora-repos, NEW 18:11:57 this might be blocker, if it means f32 installs get updates from rawhide by default 18:11:59 i didn't check that 18:12:10 I am fixing it right now 18:12:40 but it's definitely fe... 18:12:55 +1 FE 18:12:58 +1 fe 18:13:02 +1FE 18:13:07 ₊ FE 18:13:12 +1 FE 18:13:16 +1 FE... 18:13:24 +1 18:13:48 +1 FE 18:14:15 +1 fe 18:15:37 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 ack 18:15:47 ack 18:16:31 ack 18:17:08 ack 18:17:21 ack 18:17:30 #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 #topic (1799606) libx86emu: FTBFS in Fedora rawhide/f32 18:17:39 #link https://bugzilla.redhat.com/show_bug.cgi?id=1799606 18:17:39 #info Proposed Freeze Exceptions, libx86emu, MODIFIED 18:19:29 +1 FE 18:19:52 +1 FE 18:20:02 +1FE 18:20:05 i mean, it's not that important what's in the frozen beta tree, really 18:20:09 but can't hurt 18:20:14 (famous last words) 18:20:17 +0.5 FE 18:20:22 +1 FE 18:20:30 don't have it installed on my system, don't know what is it for... +1 FE though 18:20:41 it's not in comps so shouldn't affect any image composes 18:20:50 it's the library dependency for the hwinfo diagnostic tool 18:20:54 adamw, famous last words are "nothing is approaching from the right side." 18:21:05 "what's the worst that could possibly happ" 18:21:12 don't... just don't 18:21:28 that's a phrase that should never be uttered 😛 18:21:35 it's a good point 18:21:40 two of them even 18:22:00 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 patch 18:22:12 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 ack 18:22:25 ack 18:22:27 ack 18:22:29