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