17:13:39 <adamw> #startmeeting F30-blocker-review 17:13:39 <zodbot> Meeting started Mon Feb 11 17:13:39 2019 UTC. 17:13:39 <zodbot> This meeting is logged and archived in a public location. 17:13:39 <zodbot> The chair is adamw. Information about MeetBot at http://wiki.debian.org/MeetBot. 17:13:39 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic. 17:13:39 <zodbot> The meeting name has been set to 'f30-blocker-review' 17:13:39 <adamw> #meetingname F30-blocker-review 17:13:39 <adamw> #topic Roll Call 17:13:39 <zodbot> The meeting name has been set to 'f30-blocker-review' 17:13:53 * coremodule is present and ready to act as secretary! Also, I was present for the entirety of the QA meeting, but was using an unregistered nick so none of my messages went through... whoops! -.- 17:14:00 <adamw> .fire coremodule 17:14:00 <zodbot> adamw fires coremodule 17:14:07 <adamw> it's okay, i'm sure you didn't have anything of interest to say ;) 17:14:11 * cmurf is somewhere 17:14:11 <coremodule> lol 17:14:22 <coremodule> just about the cron blocker, but oh well 17:14:30 <adamw> morning folks, who's around for some super fun blocker review? 17:14:42 <frantisekz> Me! :D 17:14:45 <cmurf> crank it out, I'm hungry 17:14:52 <coremodule> and just about paychecks for the rest of forever, but its okay 17:14:55 <coremodule> ;P 17:16:55 <sgallagh> .hello2 17:16:56 <zodbot> sgallagh: sgallagh 'Stephen Gallagher' <sgallagh@redhat.com> 17:17:10 <frantisekz> .hello2 17:17:11 <zodbot> frantisekz: frantisekz 'František Zatloukal' <fzatlouk@redhat.com> 17:17:44 <adamw> unfortunately we are all out of stock on super fun blocker review 17:17:51 <adamw> so you'll be getting dull, boring blocker review instead 17:17:56 <frantisekz> :'( 17:17:57 <adamw> refunds are absolutely not available 17:18:23 <sgallagh> Ah, blocker meetings are done in the Kickstarter style, now? 17:18:39 <coremodule> i would like to speak to a manager 17:18:48 <adamw> REQUEST DENIED 17:18:50 <adamw> .fire coremodule 17:18:50 <zodbot> adamw fires coremodule 17:18:54 <adamw> ...but you can't leave. 17:19:04 <adamw> sgallagh: =) 17:19:10 <coremodule> indebted servitude? 17:19:11 <bcotton> this is going to be a Very Productive and Serious Meeting™, isn't it? 17:19:26 <adamw> #info coremodule will secretarialize 17:19:32 <adamw> #chair bcotton sgallagh 17:19:32 <zodbot> Current chairs: adamw bcotton sgallagh 17:19:42 * sgallagh hands bcotton a party hat 17:19:45 <adamw> boilerplate incoming 17:19:45 <adamw> #topic Introduction 17:19:45 <adamw> Why are we here? 17:19:45 <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:19:46 <adamw> #info We'll be following the process outlined at: 17:19:46 <adamw> #link https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting 17:19:48 <adamw> #info The bugs up for review today are available at: 17:19:50 <adamw> #link http://qa.fedoraproject.org/blockerbugs/current 17:19:50 <cmurf> HEY! you can't fire someone twice! 17:19:52 <adamw> #info The criteria for release blocking bugs can be found at: 17:19:54 <adamw> #link https://fedoraproject.org/wiki/Basic_Release_Criteria 17:19:56 <adamw> #link https://fedoraproject.org/wiki/Fedora_30_Beta_Release_Criteria 17:19:58 <adamw> #link https://fedoraproject.org/wiki/Fedora_30_Final_Release_Criteria 17:20:00 <adamw> .fire cmurf can, will 17:20:00 <zodbot> adamw fires cmurf can, will 17:20:08 <adamw> we have: 17:20:10 <adamw> #info 4 Proposed Blockers (Beta) 17:20:19 <adamw> #info 4 Proposed Blockers 17:20:24 <adamw> #undo 17:20:24 <zodbot> Removing item from minutes: INFO by adamw at 17:20:19 : 4 Proposed Blockers 17:20:28 <adamw> #info 4 Proposed Blockers (Final) 17:22:02 <adamw> #topic Proposed Beta blockers 17:22:09 <adamw> #topic (1672761) segfault during boot of netinstall image 17:22:09 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1672761 17:22:09 <adamw> #info Proposed Blocker, device-mapper-multipath, MODIFIED 17:22:25 <cmurf> bug is fixed so blocker aspect is perhaps moot 17:22:47 <cmurf> comment 4 is most central, whether this would be a blocker to have it entirely non-functional for beta GA 17:23:16 <sgallagh> cmurf: If the fix is not complete, it may still be useful 17:23:19 <cmurf> i'm gonna say +1 until there's a better argument than what I came up with 17:24:17 <adamw> i don't think openqa hit this, oddly 17:24:33 <adamw> don't know why it'd crash for you but not in openqa... 17:24:40 <cmurf> also the rest of the bug questions where this wrong /etc/multipath.conf is coming from; there's an anaconda and test list thread about that on-going 17:24:44 <adamw> https://openqa.fedoraproject.org/tests/overview?distri=fedora&version=Rawhide&build=Fedora-Rawhide-20190205.n.0&groupid=1 17:24:48 <adamw> note the *-boot-iso tests pass 17:24:59 <cmurf> *shrug* dunno 17:25:11 <adamw> iirc there may be some udev magic involved but i'd have to go dig all that out again 17:25:34 <cmurf> well the wrong multipath.conf is on the actual netinstall media, I'm just not sure how it gets there 17:25:42 <adamw> still, i'd probably be +1 on this if it's relatively easy to run into without actually wanting to do any multipath stuff or anything 17:25:58 <sgallagh> I'm inclined to say +1 17:26:08 <bcotton> yeah, seems like a +1 is in order here 17:26:23 <cmurf> otherwise with crashing we have no idea what other bugs might be lurking 17:27:05 <cmurf> anyway the multipath.conf generation is a separate issue i'll keep following up on 17:27:21 <frantisekz> +1 from me 17:29:00 <adamw> proposed #agreed 1672761 - AcceptedBlocker (Beta) - we believe this crash will occur commonly enough to accept it as a Beta blocker per "All release-blocking images must boot in their supported configurations". It is believed fixed, but not yet fully confirmed, so we will accept it in case any issues remain 17:29:06 <cmurf> ack 17:29:08 <bcotton> ack 17:29:12 <frantisekz> ack 17:29:16 <adamw> #agreed 1672761 - AcceptedBlocker (Beta) - we believe this crash will occur commonly enough to accept it as a Beta blocker per "All release-blocking images must boot in their supported configurations". It is believed fixed, but not yet fully confirmed, so we will accept it in case any issues remain 17:29:27 <adamw> #topic (1616167) dnf doesn't record modular metadata in a local database 17:29:28 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1616167 17:29:28 <adamw> #info Proposed Blocker, dnf, NEW 17:29:34 <adamw> so, this is a "special" one 17:29:56 <adamw> this is the one where a sorta safety feature it would be good for DNF to have in regards to modularity is missing 17:30:02 <sgallagh> This apparently started magically passing in openqa, so we forgot to keep an eye on it. 17:30:20 <adamw> it didn't start passing, we just disabled the test. :) 17:30:27 <sgallagh> Whoops, sorry. 17:30:29 <adamw> but don't worry, i've been keeping an eye on it 17:30:35 <sgallagh> I was thinking of a different BZ 17:30:41 <adamw> for f29 we kicked it upstairs to fesco, they decided it should be there, then dnf team said they couldn't do it in time so fesco decided it wasn't so important after all 17:30:56 <adamw> it was definitely going to be ready for f30 though, except that it's...not. 17:31:12 <adamw> so i'm gonna propose we kick it back up to fesco, with a copy of Yakkety Sax. 17:31:22 <frantisekz> dnf guys are no longer in the office, so I can ask them tomorrow what's the situation and expected delivery ... :) 17:31:31 <adamw> then we can triple that? 17:31:39 <sgallagh> I need to double-check, but I think we may still have this for F30 Final. Beta might be tough though 17:32:07 <frantisekz> yeah... I think having this as a final blocker should be okay 17:32:26 <sgallagh> But I think kicking it to FESCo makes sense 17:32:51 <frantisekz> shouldn't I ask the devs first? so we won't bother FESCO too much :D 17:33:15 <adamw> i'm expecting fesco is gonna want to talk to the devs anyway. 17:33:25 * sgallagh nods 17:33:31 <frantisekz> okay then :) 17:33:38 <sgallagh> Possibly with bamboo stalks 17:34:06 <adamw> proposed #agreed as we did for Fedora 29, due to the issues with delivery time on this bug, we will pass this to FESCo to decide what the requirements should be for F30 Beta and Final 17:34:13 <adamw> "talk" to the devs 17:34:13 <adamw> :D 17:34:27 <frantisekz> :D 17:34:28 <frantisekz> ack 17:34:32 <bcotton> ack 17:34:42 <sgallagh> quack 17:36:01 <adamw> #agreed as we did for Fedora 29, due to the issues with delivery time on this bug, we will pass this to FESCo to decide what the requirements should be for F30 Beta and Final 17:36:05 <adamw> #unfo 17:36:06 <adamw> #undo 17:36:06 <zodbot> Removing item from minutes: AGREED by adamw at 17:36:01 : as we did for Fedora 29, due to the issues with delivery time on this bug, we will pass this to FESCo to decide what the requirements should be for F30 Beta and Final 17:36:40 <adamw> #agreed 1616167 - punt to FESCo - as we did for Fedora 29, due to the issues with delivery time on this bug, we will pass this to FESCo to decide what the requirements should be for F30 Beta and Final 17:36:53 <adamw> #topic (1672683) [ebtables] build option breaks service firewalld 17:36:54 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1672683 17:36:54 <adamw> #info Proposed Blocker, ebtables, ASSIGNED 17:37:22 <sgallagh> I think we have "firewalld works" as a Server criterion somewhere 17:37:26 <sgallagh> So I'm +1 17:37:28 <adamw> yeah, it's a clear blocker 17:37:35 <adamw> it's claimed fixed now, openqa didn't confirm yet due to needle fun 17:37:40 <frantisekz> +1 .. seems fixed, so just in case 17:37:43 <adamw> (i'm fixing that as we speak) 17:37:48 <adamw> +1 for me obs 17:37:52 <bcotton> +1 17:38:36 <sgallagh> Actually... what's the behavior here. 17:38:45 <sgallagh> If it's blocking all traffic, it's not technically a blocker 17:39:26 <sgallagh> I see a lot of errors, but the actual behavior isn't documented. 17:39:53 <adamw> i'm pretty sure it's a blocker anyway. 17:39:59 <sgallagh> If it's failing "safe", I'd lower my vote to an exception+ 17:40:06 <adamw> i don't actually know exactly what it *does*, as openqa fails on the command errors 17:40:24 <adamw> "Supported install-time firewall configuration options must work correctly" 17:40:29 <adamw> i'm gonna say it's a blocker on that basis. 17:40:33 <sgallagh> OK, good enough for me 17:40:35 <adamw> (from Basic criteria) 17:43:11 <adamw> proposed #agreed 1672683 - AcceptedBlocker (Beta) - accepted as a blocker per Basic criterion "...Supported install-time firewall configuration options must work correctly." 17:43:23 <bcotton> ack 17:43:33 <frantisekz> ack 17:44:24 <cmurf> Ackbar 17:45:33 <adamw> #agreed 1672683 - AcceptedBlocker (Beta) - accepted as a blocker per Basic criterion "...Supported install-time firewall configuration options must work correctly." 17:45:36 <adamw> IT'S A TRAP! 17:45:39 <adamw> ahem. sorry. mandatory 17:45:49 <adamw> #topic (1666868) NFS install fails with kernel "invalid creds" traceback 17:45:49 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1666868 17:45:49 <adamw> #info Proposed Blocker, kernel, NEW 17:46:06 * cmurf understood that reference! 17:46:26 <cmurf> OK so I updated the bug 17:46:37 <cmurf> I think I found the upstream bug report, and there's been a fix already 17:46:42 <cmurf> but yeah otherwise it would have been a blocker 17:46:50 <cmurf> so +1 17:47:06 <bcotton> +1 17:47:11 <sgallagh> If this indeed prevents installation from NFS mounts, then it's a clear +1 17:47:17 <sgallagh> (so that was my +1) 17:47:28 <frantisekz> +1 17:48:49 <adamw> proposed #agreed 1666868 - AcceptedBlocker (Beta) - accepted as a clear violation of "When using the dedicated installer images, the installer must be able to use HTTP, FTP and NFS repositories as package sources" 17:49:21 <cmurf> acknowledged 17:49:24 <bcotton> ack 17:49:27 <frantisekz> ack 17:50:27 <sgallagh> ack 17:50:47 <adamw> #agreed 1666868 - AcceptedBlocker (Beta) - accepted as a clear violation of "When using the dedicated installer images, the installer must be able to use HTTP, FTP and NFS repositories as package sources" 17:51:19 <adamw> #topic Proposed Final blockers 17:51:28 <adamw> #info that was all proposed Beta blockers, moving onto proposed Final blockers 17:51:37 <adamw> #topic (1648268) Drag and Drop from file-roller Does not work on Wayland 17:51:37 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1648268 17:51:37 <adamw> #info Proposed Blocker, file-roller, NEW 17:52:04 <frantisekz> this is broken also on F29 17:52:07 <cmurf> well I'd want to know what the wayland developers think, however, seems to me drag and drop works on X so it should work on wayland 17:52:32 <cmurf> And also, drag and drop appeared in the middle to late jurassic period of computing so, yeah +1 17:53:14 <cmurf> but also actually needinfo 17:53:32 <frantisekz> if it's accepted, I'll create bug report in upstream too, so GNOME guys know about that and have some time to fix it 17:53:36 <adamw> note we had a disagreement on this one for f29 17:53:44 <adamw> sorry, at the last f30 meeting 17:53:56 <frantisekz> what's the need ? I'll tell you everything... :) 17:53:58 <adamw> vote was +2/-2 17:54:12 <adamw> just a disagreement on whether drag-and-drop really constituted 'basic functionality' 17:54:16 * cmurf is happy to be present to break the tie 17:54:21 <adamw> it's pretty fuzzy 17:54:29 * bcotton doesn't remember what he voted 17:54:30 <frantisekz> for archive manager... I'd say it's basic 17:54:46 <cmurf> unequivocally on a GUI it's basic 17:54:59 <sgallagh> I'd probably come down on the side of "would fail the 'last blocker at Go/No-Go' test" 17:55:38 <cmurf> hence the needinfo, what's actually going on 17:57:25 <adamw> so for the record, votes last time were: 17:57:37 <adamw> +1: lruzicka, bcotton 17:57:41 <adamw> -1: adamw, lailah 17:57:56 <adamw> punt: coremodule 17:58:07 <frantisekz> so... obviously, I am +1 17:58:13 <coremodule> roger 17:58:17 <frantisekz> lruzicka is not here, lailah neither 17:58:18 <sgallagh> I'm -1 today 17:58:28 <bcotton> i think i'm going to stick with +1, even though it kind of makes me sad 17:58:29 <adamw> so now we're at +3 / -3? excellent. :D 17:58:30 <cmurf> I'm +1 and needinfo desktop@ people 17:58:43 <cmurf> adamw no you didn't count mine :D 17:58:58 <adamw> cmurf: i don't think drag/drop is generally broken, it's probably just file-roller not updating for some GTK+ protocol change or some such thing 17:59:08 <adamw> cmurf: i typed that before i saw you vote :D 17:59:11 <coremodule> i would be okay with punting for info from wayland folks 17:59:23 <adamw> #info vote tally (including votes from previous meeting) currently at +4 / -3 17:59:41 <adamw> i usually look for a decent consensus at these meetings, not a bare majority 18:00:11 <coremodule> ...but im inclined to fall in the "drag and drop isn't basic functionality" wagon... 18:00:28 <coremodule> because there are workarounds. 18:00:44 <frantisekz> okay... so, I'd write on desktop ml and get the definition of basic functionality 18:00:51 <frantisekz> for file-roler 18:01:36 <coremodule> ^^what frantisekz said, if we haven't defined that already 18:02:28 <adamw> this is why i wish we'd never written this criterion :P 18:02:32 <adamw> oh well 18:02:58 <cmurf> ok I just sent an email on desktop@ list 18:03:05 <adamw> proposed #agreed 1648268 - punt (delay decision) - there still isn't a clear consensus on this (current vote total at +4 / -3) so we will delay once again, and try to ping desktop team for more info and hopefully a fix 18:03:07 <adamw> thanks cmurf 18:03:12 <frantisekz> thanks cmurf, ack 18:03:16 <cmurf> ack 18:03:43 <sgallagh> adamw: I think it was +4/-4 based on coremodule's last bit 18:03:50 <sgallagh> "but im inclined to fall in the "drag and drop isn't basic functionality" wagon..." 18:04:00 <adamw> oh yes, you're right. 18:04:03 <coremodule> patch for what sgallagh said 18:04:04 <adamw> will amend 18:04:08 <adamw> patch accepted! 18:04:18 <adamw> proposed #agreed 1648268 - punt (delay decision) - there still isn't a clear consensus on this (current vote total at +4 / -4) so we will delay once again, and try to ping desktop team for more info and hopefully a fix 18:04:30 <frantisekz> ack 18:04:55 <coremodule> ack 18:05:50 <sgallagh> ack 18:06:25 <bcotton> ack 18:09:40 <adamw> #agreed 1648268 - punt (delay decision) - there still isn't a clear consensus on this (current vote total at +4 / -4) so we will delay once again, and try to ping desktop team for more info and hopefully a fix 18:09:42 <adamw> whoops, sorry 18:09:49 <adamw> #topic (1674167) __libc_free: gnome-control-center killed by SIGSEGV 18:09:49 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1674167 18:09:49 <adamw> #info Proposed Blocker, gnome-control-center, NEW 18:11:10 <bcotton> seems like a clear +1 to me 18:11:15 <cmurf> +1 18:11:19 <frantisekz> +1 18:11:28 <coremodule> +1 18:12:10 <sgallagh> +1 18:14:16 <adamw> proposed #agreed 1648268 - AcceptedBlocker (Final) - 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" 18:14:31 <bcotton> ack 18:14:38 <frantisekz> ack 18:14:42 <coremodule> ack 18:15:41 <sgallagh> ack 18:16:01 <adamw> #agreed 1648268 - AcceptedBlocker (Final) - 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" 18:16:08 <adamw> #topic (1666920) iSCSI installs fail to boot since systemd-240 (Fedora-Rawhide-20181222.n.1) 18:16:08 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1666920 18:16:08 <adamw> #info Proposed Blocker, systemd, NEW 18:16:16 <cmurf> +1 blocker 18:16:35 <cmurf> however looking at the log, I'm unable to locate the problem 18:17:03 <cmurf> I think systemd uses dbus to setup iscsi, in which case maybe this is dbus-broker related? 18:17:22 <cmurf> but that doesn't explain why it was working before, unless dbus-broker landed about this same time 18:18:12 <adamw> i couldn't see anything obvious either, but hey, this isn't a debugging meeting 18:19:39 <bcotton> +1 blocker 18:19:54 <frantisekz> +1 18:20:24 <adamw> proposed #agreed 1666920 - AcceptedBlocker (Final) - accepted as a violation of "The installer must be able to detect (if possible) and install to supported network-attached storage devices...Supported network-attached storage types include iSCSI, Fibre Channel and Fibre Channel over Ethernet (FCoE)." 18:20:54 <bcotton> ack 18:20:55 <frantisekz> ack 18:22:14 <adamw> any more acks? 18:22:16 <cmurf> ack 18:22:16 <adamw> any any any more acks 18:22:20 <adamw> #agreed 1666920 - AcceptedBlocker (Final) - accepted as a violation of "The installer must be able to detect (if possible) and install to supported network-attached storage devices...Supported network-attached storage types include iSCSI, Fibre Channel and Fibre Channel over Ethernet (FCoE)." 18:22:29 <adamw> alrighty, last one 18:22:29 <adamw> #topic (1674045) Upgrade from F29 to Rawhide (F30) hangs at end, showing "Upgrade complete! Cleaning up and rebooting..." 18:22:29 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1674045 18:22:29 <adamw> #info Proposed Blocker, systemd, NEW 18:22:41 <cmurf> hmm well I think that's a bug 18:22:47 <cmurf> :D 18:23:14 <cmurf> +1 blocker 18:23:27 <frantisekz> could be final IMO ... but +1 anyway 18:23:34 <frantisekz> *beta blocker 18:23:53 <adamw> frantisekz: i put my reasoning in the bug 18:24:04 <adamw> i think saying 'just hit reset' is ok for beta, but probably not final 18:24:04 <frantisekz> I mean... people can't always hit reset button on a server , I've read it 18:24:13 <frantisekz> but I am not going to fight for it :D 18:24:18 <adamw> well, true. though there's usually *some* way they can force a reboot remotely 18:24:26 <adamw> and if not you probably shouldn't be installing betas on it. :P 18:24:27 <bcotton> +1 final blocker 18:24:32 <frantisekz> yeah.... :D 18:26:03 <adamw> proposed #agreed 1675045 - AcceptedBlocker (Final) - accepted as violation of "For each one of the release-blocking package sets, it must be possible to successfully complete a direct upgrade from a fully updated, clean default installation of each of the last two stable Fedora releases with that package set installed", reasoning per comment #2 18:26:08 <frantisekz> ack 18:26:17 <cmurf> ack! ack! ack! ack! 18:26:23 <bcotton> ack 18:26:54 <adamw> #agreed 1675045 - AcceptedBlocker (Final) - accepted as violation of "For each one of the release-blocking package sets, it must be possible to successfully complete a direct upgrade from a fully updated, clean default installation of each of the last two stable Fedora releases with that package set installed", reasoning per comment #2 18:27:03 <adamw> #topic End of proposed blockers 18:27:18 <adamw> #info there's only one accepted Beta blocker and it doesn't really need checking, so onto open floor! 18:27:20 <adamw> #topic Open floor 18:27:27 <adamw> any other business, new proposals, etc? 18:27:33 <cmurf> branch next week, beta due in three weeks :D 18:27:38 <adamw> this is true! 18:27:49 <adamw> i would also like to officially note that Celeste is an awesome game and everyone should go play it 18:27:58 <adamw> :P 18:28:22 <cmurf> cool 18:28:38 <cmurf> prototyped in four days for a game jam, nifty origin 18:29:56 <coremodule> question! what was the proposed milestone for the potential cron blocker case from the QA meeting? 18:30:27 <cmurf> should install media, in particular netinstalls, now be doing installs from post mass rebuild packages? 18:30:35 <cmurf> or is it a mix? 18:31:20 <frantisekz> okay... I need to leave, thanks adamw for leading the meeting! 18:31:30 <adamw> coremodule: i do not recall 18:31:32 <adamw> let me see 18:31:50 <adamw> cmurf: as long as you hit an updated mirror, it should use post-rebuild packages 18:31:56 <adamw> since we have a compose with the post-rebuild packages 18:33:10 <adamw> coremodule: looks like the proposal did not specifiy 18:33:13 * adamw brb 18:33:25 <cmurf> ok super 18:33:27 <cmurf> bye 18:37:52 <adamw> ok, thanks everyone! 18:37:54 <adamw> i guess we're done 18:38:10 <adamw> #endmeeting