16:03:37 <adamw> #startmeeting F26-blocker-review
16:03:37 <zodbot> Meeting started Mon Jun 26 16:03:37 2017 UTC.  The chair is adamw. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:03:37 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:03:37 <zodbot> The meeting name has been set to 'f26-blocker-review'
16:03:37 <adamw> #meetingname F26-blocker-review
16:03:37 <adamw> #topic Roll Call
16:03:37 <zodbot> The meeting name has been set to 'f26-blocker-review'
16:03:46 <adamw> morning, folks, who's around for a blocker review meeting?
16:04:03 * kparal is here
16:04:07 <jkurik> .hello2
16:04:08 <zodbot> jkurik: jkurik 'Jan Kurik' <jkurik@redhat.com>
16:04:17 <kparal> I'd rather lurk but that is not going to work out I guess
16:04:27 <kparal> pschindl seems online, pinged him
16:04:33 * adamw covers kparal in anti-lurk paint
16:06:20 * adamw wonders if the zombie apocalypse broke out and no-one told us
16:06:27 * adamw checks window
16:07:39 <adamw> hmm, no, street seems *relatively* zombie free
16:07:50 * garretraziel is here
16:08:10 <jkurik> hmm... we are just 4 for the meeting ... (counting zodbot as well)
16:08:25 <adamw> five, now
16:08:41 <adamw> no, still four.
16:08:47 * adamw is good with the counting
16:10:46 * pwhalen is here
16:11:02 <adamw> well...i guess we can try with this many people
16:11:31 <adamw> #chair pwhalen jkurik kparal garretraziel roshi
16:11:31 <zodbot> Current chairs: adamw garretraziel jkurik kparal pwhalen roshi
16:11:34 <adamw> chairs for everyone!
16:11:40 <adamw> #topic Introduction
16:11:40 <adamw> Why are we here?
16:11:40 <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.
16:11:40 <adamw> #info We'll be following the process outlined at:
16:11:41 <adamw> #link https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting
16:11:41 <adamw> #info The bugs up for review today are available at:
16:11:43 <adamw> #link http://qa.fedoraproject.org/blockerbugs/current
16:11:47 <adamw> #info The criteria for release blocking bugs can be found at:
16:11:49 <adamw> #link https://fedoraproject.org/wiki/Fedora_26_Alpha_Release_Criteria
16:11:51 <adamw> #link https://fedoraproject.org/wiki/Fedora_26_Beta_Release_Criteria
16:11:53 <adamw> #link https://fedoraproject.org/wiki/Fedora_26_Final_Release_Criteria
16:11:58 <adamw> i'll handle secretary duty
16:12:06 <adamw> we have:
16:12:08 <adamw> #info 7 Proposed Blockers
16:12:08 <adamw> #info 4 Accepted Blockers
16:12:13 <adamw> #info 1 Proposed Freeze Exception
16:13:22 * roshi shows up
16:13:34 <roshi> family things happened and I just now got them finished
16:13:36 <roshi> apologies
16:15:03 <roshi> adamw: feel free to keep going if you like
16:15:27 <roshi> guess it depends on if you'd rather run or secretarialize :)
16:16:41 <adamw> you go ahead, roshi
16:16:44 <adamw> i'll secretarialize
16:16:46 <roshi> sgtm
16:16:48 <roshi> #topic (1443662) installation problems with repos accessed via NFS
16:16:51 <roshi> #link https://bugzilla.redhat.com/show_bug.cgi?id=1443662
16:16:52 <adamw> we were just about to go into the first proposed blocker
16:16:53 <roshi> #info Proposed Blocker, anaconda, NEW
16:17:00 <roshi> yep
16:20:35 <roshi> looks like a pretty generic kickstart to me...
16:21:11 <kparal> so there's a very exact set of configuration options that breaks it
16:22:06 <kparal> I'd say it's very specific and narrow to be a blocker
16:22:26 <adamw> so...we haven't got around to reproducing it yet (i'll try today)
16:22:26 * roshi doesn't use NFS for anything, so I'm not familiar
16:22:33 <roshi> punt, still?
16:22:54 <roshi> aiui, if the NFS server wasn't running v3, it'd work, right?
16:23:13 <jkurik> roshi: that is my understanding
16:23:16 <roshi> or is that the NFS API version?
16:23:17 <adamw> i don't think so
16:23:25 <adamw> the NFS version only seems to apply to the *second* issue
16:23:33 <adamw> note, https://bugzilla.redhat.com/show_bug.cgi?id=1443662#c5 is probably the best place to start, here
16:23:35 <roshi> "use this set of commands, not that one" kind of config
16:23:40 <adamw> i'd say the '2nd problem' is clearly not a blocker
16:23:47 <adamw> '1st problem' is closer
16:24:21 <roshi> makes sense
16:25:48 <jkurik> I am a bit confused with this, however I would agree with kparal that this has a very exact set of configuration options
16:26:12 <jkurik> as such I am more -1 to block and +1 FE
16:28:01 <adamw> well
16:28:05 <roshi> NFS gets a decent amount of use in automated deployments
16:28:09 <adamw> i wouldn't say it's as specific as all *that*
16:28:17 <adamw> I don't see "static IP plus NFS repo" as incredibly strange
16:28:23 <roshi> and those deployments might not be testing beta, so it'd be good to get it sussed out
16:28:47 <adamw> if we can reproduce that any attempt at a kickstarted install with a static IP and an NFS repo fails, that seems fairly significant...doesn't seem like a slam-dunk rejection at least
16:28:50 <roshi> I'd like more information, because I don't know how many people test this before release
16:28:59 <roshi> yeah
16:29:00 <adamw> i might still come down -1 in the end, but it's close
16:29:09 <roshi> I'm +1 to a punt for more testing at this point
16:29:39 <jkurik> yeah, probably more testing would be helpful to make a decision
16:30:26 <garretraziel> +1 punt also
16:30:47 <roshi> proposed #agreed - RHBZ#1443662 - Punt - We need some more information on how reproducible this is before we can make a decision on blocker status.
16:31:00 <roshi> adamw: you're going to test this today?
16:31:01 <kparal> ack
16:31:12 <jkurik> ack
16:31:23 <roshi> #agreed - RHBZ#1443662 - Punt - We need some more information on how reproducible this is before we can make a decision on blocker status.
16:31:36 <roshi> #topic (1443930) GLib.GError: nm-device-error-quark: This device is not active (4)
16:31:39 <roshi> #link https://bugzilla.redhat.com/show_bug.cgi?id=1443930
16:31:42 <roshi> #info Proposed Blocker, anaconda, NEW
16:32:37 <roshi> lol
16:33:08 <adamw> ack
16:33:09 <adamw> oops, sorry
16:33:16 <adamw> i will test that last one, yeah
16:34:49 <adamw> hmm
16:35:01 <adamw> if you have to toggle it at least twice, i'm probably -1 blocker on this
16:35:03 <kparal> +1
16:35:15 <kparal> if you can't enable the right interface, how can you install?
16:35:32 <adamw> both the reporters so far seem to have gone through all possible states at least twice
16:35:32 <roshi> and you have to have several
16:35:36 <adamw> which is never *necessary*
16:35:46 <adamw> if you could trigger it just with one 'disabled -> enabled' transition i'd be more +1
16:35:52 <adamw> but I don't see anyone claiming that, do you?
16:35:57 <roshi> I don't
16:36:03 <adamw> jiri said: "Enable and disable network interface again and again"
16:36:09 <roshi> and this is worth an FE, provided the fix just touches those bits
16:36:13 <adamw> Chris said: "Enable then disable then I think enable ethernet"
16:37:07 <kparal> I still don't think this is release-able for final, even for 2+ transitions
16:37:12 <jkurik> The issue should be fixed: https://bugzilla.redhat.com/show_bug.cgi?id=1443878#c9 . So, it seems to me like the fix is not somehow propagated to Anaconda
16:37:21 <pwhalen> +1, agree with kparal
16:37:46 <jkurik> Does Anaconda have its own NetworkManager built in ?
16:38:36 <adamw> no
16:38:39 <jkurik> but anyway, I am +1 to block; this should work
16:39:04 <adamw> welp, someone better cite a criterion
16:39:18 <roshi> I'm a light +1, but we need a criterion - and I don't know which to use
16:39:52 <roshi> I see it as a polish thing (and am confused as to why it would lose track of state like that)
16:40:10 <jkurik> The "The installer must be able to complete an installation using all supported interfaces. " one ?
16:40:23 <roshi> it is able to
16:40:43 <roshi> just not when you apply the turbo button to the interface toggle button
16:41:27 <kparal> jkurik: I think "interfaces" in that case mean GUI, TUI etc
16:41:31 <kparal> but we can use "The installer must be able to detect (if possible) and install to supported network-attached storage devices. "
16:41:38 <kparal> doh, that's "to"
16:41:43 <kparal> not "from"
16:42:05 <kparal> well then "When using the dedicated installer images, the installer must be able to use HTTP, FTP and NFS repositories as package sources. "
16:42:19 <kparal> for that, you need to enable the right network interface
16:42:53 <roshi> I don't know that this strictly violates it - because the installer is *able* to
16:43:00 <roshi> just not when a toggle is abused
16:43:25 <adamw> well, you could use the network storage one too, as you need network access to write to those as well. :P but i agree with roshi that this is fairly weak, since you certainly *can* do it if you just don't keep fat fingering the device activation UI
16:43:30 <roshi> could push this to the prioritized bug meeting and go from there
16:43:41 <roshi> let them fiat it
16:43:52 <roshi> (me is in on that meeting - I'll argue for it)
16:43:56 <adamw> i dunno, i just think we've waved through far worse things than this
16:44:05 <roshi> but it doesn't actually violate a criterion that I can see
16:44:14 <adamw> it honestly doesn't feel like something worth blocking the release for to me
16:44:19 <adamw> regardless of criteria
16:44:28 <adamw> just mho, though.,
16:44:31 <roshi> sure, and at Go/No-go, it'd be ignored
16:44:46 <roshi> so I say we offload this to the Prioritized Bugs thing and see where it goes
16:45:00 <roshi> since we're kinda 'meh" about it
16:45:18 <roshi> this is polish (which I think we should have)
16:45:23 <kparal> that fact that there exists a way to work around bugs doesn't mean it satisfies criteria
16:45:38 <adamw> it's barely a 'workaround;
16:45:42 <kparal> you just need to weigh the difficulty and impact
16:45:43 <adamw> you have to 'workaround' to *hit* the bug
16:45:46 <roshi> this is that there's a way to break it - not that you have to do a workaround
16:45:54 <roshi> workaround is after the bug, not before it
16:46:12 <adamw> 'just enable it once, don't enable it then disable it then enable it again' is barely worth calling a 'workaround', to me
16:46:12 <roshi> IMO at least
16:47:05 <kparal> if my wifi is disabled, so I enable it to connect, but it fails for some reason or I don't see my network, I switch if off and on again, and try again
16:47:09 <kparal> pretty standard
16:48:21 <adamw> aren't wifi adapters enabled by default anyway?
16:48:29 <adamw> i've never had to go into the settings to enable wifi on my laptop, i don't think..
16:48:33 <adamw> guess i should check again
16:48:42 <adamw> welp, we're at a bit of a standoff here
16:48:44 <roshi> I haven't
16:48:53 <kparal> what if you have it toggled off by a button and then toggle in on after it booted. is it automatically enabled?
16:48:55 <roshi> votes to set prioritized bug for review?
16:49:05 <roshi> in meatspace?
16:49:28 <adamw> kparal: i dunno.
16:49:47 <adamw> i'm okay with any form of kicking the can down the road ;)
16:50:13 <kparal> I won't fight this, that's just my preference. I'll ack even -1, it's not that important bug
16:50:21 <roshi> just means I get to talk about it tomorrow again :p
16:50:51 <jkurik> I would rather set -1 than move it to prioritized meeting
16:51:25 <roshi> proposed #agreed - RHBZ#1443930 - RejectedBlocker - This doesn't actually violate any of the Release Criteria so it's rejected as a blocker.
16:51:27 <jkurik> roshi: there is no prioritized meeting tomorrow; it is forthnightly meeting
16:51:32 <roshi> ah
16:51:42 <jkurik> ack
16:51:45 <roshi> that's why I get confused about when it is and when it isn't
16:52:06 <adamw> why don't they schedule a meeting every week and then cancel half of them, like *sensible* people do?
16:52:07 <roshi> jkurik: can you make sure we add this to our list?
16:52:09 <adamw> jeez
16:52:09 <adamw> ack
16:52:13 <roshi> lol
16:52:23 <roshi> #agreed - RHBZ#1443930 - RejectedBlocker - This doesn't actually violate any of the Release Criteria so it's rejected as a blocker.
16:52:49 <roshi> #topic (1462825) Aanconda bug reporting dialog is missing important log files & full treceback file
16:52:52 <roshi> #link https://bugzilla.redhat.com/show_bug.cgi?id=1462825
16:52:54 <roshi> #info Proposed Blocker, anaconda, NEW
16:53:45 <kparal> +1
16:54:02 <jkurik> roshi: (back to the RHBZ#1443930) - the prioritized meeting should cover bugs which have a "business impact", which IMO RHBZ#1443930 is not
16:54:20 <roshi> easy then :)
16:54:43 <adamw> +1 on the basis that it's not properly reporting, yeah
16:54:48 <pwhalen> +1
16:54:52 <adamw> ('appropriate information' is missing)(
16:55:35 <roshi> yeah
16:55:37 <kparal> since it's reported by an anaconda developer, I guess he's really missing something important :)
16:56:03 <kparal> I just don't know why he doesn't fix it and wastes his time reporting bugs! people...
16:56:17 <roshi> proposed #agreed - RHBZ#1462825 - AcceptedBlocker - This bug is a clear violation of the following Alpha criterion: "The installer must be able to report failures to Bugzilla, with appropriate information included."
16:56:24 <kparal> ack
16:56:59 <adamw> ack
16:56:59 <jkurik> as I understand it the anaconda developer think it should be fixed on libreport side ?
16:57:04 <pwhalen> ack
16:57:18 <roshi> #agreed - RHBZ#1462825 - AcceptedBlocker - This bug is a clear violation of the following Alpha criterion: "The installer must be able to report failures to Bugzilla, with appropriate information included."
16:57:19 <jkurik> roshi: ack
16:57:22 <roshi> #topic (1463297) Server install fails on armhfp - "/boot file system cannot be of type xfs"
16:57:26 <roshi> #link https://bugzilla.redhat.com/show_bug.cgi?id=1463297
16:57:28 <roshi> #info Proposed Blocker, anaconda, MODIFIED
16:57:34 <kparal> jkurik: you're right
16:58:07 <jkurik> kparal: then the bug has wrongly assigned the component
16:58:35 <pwhalen> +1
16:58:39 <kparal> jkurik: after reading it once again, he says "it is possible it's caused by libreport"
16:58:40 <adamw> um
16:58:46 <adamw> no server image is blocking for ARM, is it?
16:58:52 <adamw> the blocking images for ARM are minimal and Xfce
16:59:03 <roshi> don't think so - but is arm a blocking arch for sever?
16:59:06 <roshi> *server
16:59:18 <roshi> since WGs can pick their arches
16:59:49 <kparal> https://fedoraproject.org/wiki/Releases/26/ReleaseBlocking?rd=Fedora_Program_Management/ReleaseBlocking/Fedora26#Server
17:00:06 <kparal> arm doesn't block server
17:00:24 <roshi> kk
17:00:27 * roshi wasn't sure
17:00:52 <adamw> i'm -1 blocker on the basis that this doesn't affect any release-blocking media, but +1 FE
17:00:54 <pwhalen> sgallagher was +1
17:01:11 <roshi> it's only server that fails here?
17:01:15 <pwhalen> right
17:01:19 <roshi> huh
17:01:23 <kparal> -1/+1
17:01:55 <jkurik> +1 FE
17:02:24 <adamw> and not just server package set, it has to be an actual server image
17:02:28 <adamw> since it's to do with the product class
17:03:31 <roshi> huh
17:03:40 <roshi> -1/+1
17:04:32 <roshi> proposed #agreed - RHBZ#1463297 - RejectedBlocker AcceptedFreezeException - This bug doesn't affect any release blocking media for ARM, so is rejected as a blocker. However, it'd be great to get a fix in for this if we can, so granting FE status.
17:05:02 <adamw> ack
17:05:32 <jkurik> ack
17:05:39 <roshi> #agreed - RHBZ#1463297 - RejectedBlocker AcceptedFreezeException - This bug doesn't affect any release blocking media for ARM, so is rejected as a blocker. However, it'd be great to get a fix in for this if we can, so granting FE status.
17:05:53 <roshi> 3 more
17:05:54 <roshi> #topic (1464297) anaconda is disabling ipv6 even though not asked to
17:05:57 <roshi> #link https://bugzilla.redhat.com/show_bug.cgi?id=1464297
17:05:59 <roshi> #info Proposed Blocker, anaconda, MODIFIED
17:06:38 <adamw> +1, per reason in the bug
17:06:42 <kparal> +1
17:07:13 <jkurik> +1
17:07:27 <roshi> +1 per comments
17:08:44 * roshi proposed #agreed - RHBZ#1464297 - AcceptedBlocker - This bug conditionally violates a plethora of criteria when using ipv6, which is becoming more common.
17:09:04 * roshi isn't sur ehow he feels about the reasoning he wrote, but.. meh
17:09:50 <adamw> works for me!
17:09:50 <adamw> ack
17:10:00 <jkurik> ack :)
17:10:00 <adamw> roshi++ for use of 'plethora'
17:10:30 <kparal> ack
17:11:00 <roshi> #agreed - RHBZ#1464297 - AcceptedBlocker - This bug conditionally violates a plethora of criteria when using ipv6, which is becoming more common.
17:11:15 * roshi has a proclivity for using esoterich 'P' words
17:11:50 <adamw> there's no h in esoteric :P
17:12:02 <roshi> didn't ever say I could typ
17:12:02 <adamw> (he said, parenthetically)
17:12:20 <roshi> your error catching skills are prodigious
17:12:38 <roshi> #topic (1462444) [abrt] gnome-shell: std::_Rb_tree<_ConnectData*, _ConnectData*, std::_Identity<_ConnectData*>, std::less<_ConnectData*>, std::allocator<_ConnectData*> >::equal_range(): gnome-shell killed by signal 11
17:12:42 <roshi> #link https://bugzilla.redhat.com/show_bug.cgi?id=1462444
17:12:45 <roshi> #info Proposed Blocker, gjs, NEW
17:15:04 <adamw> https://bugzilla.redhat.com/show_bug.cgi?id=1462444#c23 is the note from last week's meeting on this
17:15:06 <adamw> let's see what happened since
17:15:15 <kparal> 31 crashes in faf
17:15:40 <kparal> I'd say punt until more people can reproduce
17:15:49 <kparal> or -1 until then
17:16:46 <adamw> and i'm not sure if each time tomas reproduces it, it counts again in faf, or not...
17:17:05 <roshi> probably...?
17:17:11 <kparal> they say "unique" in faf
17:17:26 <adamw> yeah, but i dunno what that means
17:17:30 <adamw> i guess we should ask :)
17:18:27 <adamw> still, we haven't had any kinda big outcry about this
17:18:32 <adamw> which makes me suspect it's quite limited
17:18:36 <adamw> i haven't hit it at all on my system
17:18:41 <roshi> yeah
17:18:58 <jkurik> I would vote for a punt till more people face it
17:19:11 * roshi is fine with that
17:19:17 <roshi> other votes?
17:19:59 <roshi> proposed #agreed - RHBZ#1462444 - Punt - It's still unclear how many people will hit this. We'll revisit next week when we have more information.
17:20:36 <jkurik> ack
17:20:47 <adamw> ack, i guess
17:21:00 <kparal> ack
17:21:17 <roshi> #agreed - RHBZ#1462444 - Punt - It's still unclear how many people will hit this. We'll revisit next week when we have more information.
17:21:26 <roshi> #topic (1448891) Boxes crashes on start
17:21:26 <roshi> #link https://bugzilla.redhat.com/show_bug.cgi?id=1448891
17:21:27 <roshi> #info Proposed Blocker, gnome-boxes, NEW
17:23:02 <roshi> doesn't look like everyone is hitting this
17:23:08 <adamw> yeah
17:23:18 <adamw> it sounds like perhaps the disk file for a VM went missing or something
17:23:26 <adamw> which obviously shouldn't cause boxes to crash, but doesn't seem like a release blocking issue
17:23:36 <roshi> if everyone ran into it when launching boxes, sure
17:23:40 <roshi> this looks local
17:23:59 * kparal agrees
17:24:15 <jkurik> right, so -1 to block
17:24:39 <adamw> yup, -1
17:24:48 <roshi> proposed #agreed - RHBZ#1448891 - RejectedBlocker - This bug doesn't seem to be a issue with boxes, but with something local. If more people run into this issue, please re-propose as this being widespread would be considered a blocker.
17:25:08 <jkurik> ack
17:26:25 <adamw> patch
17:26:27 <adamw> it *is* an issue with boxes
17:26:32 <adamw> it's just not an issue that'll affect everyone
17:26:38 <adamw> can you adjust to reflect that?
17:26:49 <roshi> sure
17:27:15 <roshi> proposed #agreed - RHBZ#1448891 - RejectedBlocker - This bug doesn't seem to be a generic crash Boxes has by default, but with something local. If more people run into this issue, please re-propose as this being widespread would be considered a blocker.
17:28:34 <adamw> ack
17:28:44 <jkurik> ack
17:28:55 <roshi> #agreed - RHBZ#1448891 - RejectedBlocker - This bug doesn't seem to be a generic crash Boxes has by default, but with something local. If more people run into this issue, please re-propose as this being widespread would be considered a blocker.
17:29:00 <roshi> that's it for blockers
17:29:04 <roshi> one FE
17:29:10 <roshi> #topic (1447708) cloud-init package module fails with python NameError exception
17:29:13 <roshi> #link https://bugzilla.redhat.com/show_bug.cgi?id=1447708
17:29:15 <roshi> #info Proposed Freeze Exceptions, cloud-init, ON_QA
17:30:23 <adamw> seems like a reasonable FE
17:30:24 <adamw> +1
17:30:26 <roshi> this is already fixed
17:30:39 <roshi> it's got 4 karma and has been tested
17:30:47 <adamw> the freeze is today, though
17:30:54 <adamw> so it'll still need an FE unless it gets pushed stable in the next few hours
17:31:01 <roshi> ah
17:31:05 <jkurik> +1 FE
17:31:09 <roshi> I thought it squeezed in
17:31:19 <roshi> it got pushed stable 5 hours ago
17:31:29 <roshi> according to bodhi
17:31:37 <roshi> https://bodhi.fedoraproject.org/updates/FEDORA-2017-1912218b0c
17:32:27 <adamw> no
17:32:30 <roshi> proposed #agreed - RHBZ#1447708 - AcceptedFreezeException - It'd be good to have this fixed at release. Thanks for the tested fix.
17:32:30 <adamw> that says 'submitted' for stable
17:32:33 <adamw> not 'pushed' to stable
17:32:39 <roshi> ah
17:32:41 <adamw> if there's one more push before freeze it should get in
17:32:45 <adamw> but no harm giving it an FE just in case
17:32:46 <adamw> ack
17:34:02 <jkurik> ack
17:34:04 <kparal> ack
17:34:11 <roshi> #agreed - RHBZ#1447708 - AcceptedFreezeException - It'd be good to have this fixed at release. Thanks for the tested fix.
17:34:15 <roshi> #topic Open Floor
17:34:21 <roshi> anyone have anything for the floor?
17:34:49 <roshi> if not, I'm setting the fuse!
17:35:02 * jkurik is fine not to have anything for the floor
17:36:02 <adamw> not from me
17:36:11 <adamw> i'll send out a blocker status mail this week
17:36:22 <roshi> thanks
17:36:35 <roshi> #info Blocker Status email to be sent sometime this week
17:36:37 <roshi> 3...
17:36:40 <roshi> thanks for coming folks!
17:36:46 <roshi> sorry I was a bit late!
17:36:52 <roshi> 2...
17:37:12 <roshi> 1...
17:37:15 <roshi> #endmeeting