16:01:19 <roshi> #startmeeting F26-blocker-review
16:01:19 <zodbot> Meeting started Mon Apr 10 16:01:19 2017 UTC.  The chair is roshi. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:01:19 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:01:19 <zodbot> The meeting name has been set to 'f26-blocker-review'
16:01:19 <roshi> #meetingname F26-blocker-review
16:01:19 <zodbot> The meeting name has been set to 'f26-blocker-review'
16:01:20 <roshi> #topic Roll Call
16:01:35 * coremodule is here and ready for secretary duties!
16:01:37 <roshi> who's around for some fun?
16:01:42 <roshi> thanks coremodule :)
16:01:47 * garretraziel is here
16:01:51 <coremodule> No problem. :P
16:02:42 * pwhalen is here
16:03:16 * adamw is here and primed for FUN
16:03:32 <roshi> let's get started then :)
16:03:35 <roshi> #topic Introduction
16:03:35 <roshi> Why are we here?
16:03:35 <roshi> #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:03:39 <roshi> #info We'll be following the process outlined at:
16:03:41 <roshi> #link https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting
16:03:44 <roshi> #info The bugs up for review today are available at:
16:03:46 <roshi> #link http://qa.fedoraproject.org/blockerbugs/current
16:03:49 <roshi> #info The criteria for release blocking bugs can be found at:
16:03:51 <roshi> #link https://fedoraproject.org/wiki/Fedora_26_Alpha_Release_Criteria
16:03:54 <roshi> #link https://fedoraproject.org/wiki/Fedora_26_Beta_Release_Criteria
16:03:57 <roshi> #link https://fedoraproject.org/wiki/Fedora_26_Final_Release_Criteria
16:04:00 <roshi> looks like we've got 3 proposals each for Beta/Final
16:04:35 <roshi> #topic (1439388) Kickstart installs sometimes die with traceback ending in gdbus error
16:04:38 <roshi> #link https://bugzilla.redhat.com/show_bug.cgi?id=1439388
16:04:41 <roshi> #info Proposed Blocker, anaconda, NEW
16:05:33 <adamw> I'm +1 blocker on this, as it seems that in at least some cases it can happen every time or almost every time
16:05:35 <cmurf> +1 on the basis of c8
16:05:54 <roshi> seems right to me
16:06:02 * roshi hasn't done a ks install to confirm though
16:06:04 <roshi> +1
16:06:05 <garretraziel> +1 blocker
16:06:13 <adamw> it prevented rebuild of the openQA base images for f26 on the openQA server until I hacked up the creation script to apply an updates.img with the fix; seemed like every attempt to create one of the images ran into this
16:06:20 <pwhalen> +1
16:06:45 <adamw> roshi: also, you should do some backup #chairs and get a secretarary
16:07:06 <roshi> proposed #agreed - AcceptedBlocker - RHBZ#1439388 - This bug is a violation of the following Alpha criterion: "The scripted installation mechanism must provide a working function for creating local user accounts, including the ability to specify a hashed password, and for specifying a hashed password for the root account."
16:07:17 <roshi> but if I have all the chairs, I can build mega-chair
16:07:27 <roshi> and coremodule volunteered already
16:07:40 <roshi> #chair adamw garretraziel cmurf coremodule pwhalen
16:07:40 <zodbot> Current chairs: adamw cmurf coremodule garretraziel pwhalen roshi
16:07:40 <pwhalen> ack
16:07:58 <adamw> MEGACHAIR
16:08:02 * roshi mourns the loss of megachair
16:08:04 <adamw> oh, so he did.
16:08:21 <adamw> roshi: maybe note it's a *conditional* violation, but ack.
16:08:46 <roshi> proposed #agreed - AcceptedBlocker - RHBZ#1439388 - This bug is considered a conditional violation of the following Alpha criterion: "The scripted installation mechanism must provide a working function for creating local user accounts, including the ability to specify a hashed password, and for specifying a hashed password for the root account."
16:09:22 <roshi> acks?
16:09:31 <cmurf> ackbar
16:09:40 <cmurf> let's just get that one out of the gate
16:09:50 <pwhalen> ack
16:09:58 <roshi> #agreed - AcceptedBlocker - RHBZ#1439388 - This bug is considered a conditional violation of the following Alpha criterion: "The scripted installation mechanism must provide a working function for creating local user accounts, including the ability to specify a hashed password, and for specifying a hashed password for the root account."
16:10:16 <roshi> #topic (1438046) initial-setup.service: Failed to set up stdin: Inappropriate ioctl for device
16:10:19 <roshi> #link https://bugzilla.redhat.com/show_bug.cgi?id=1438046
16:10:22 <roshi> #info Proposed Blocker, initial-setup, NEW
16:10:56 <mkolman_> IMHO this is yet again some ARM specific weirdness
16:11:08 <pwhalen> sadly I missed this for Alpha, not all sbc's are affected but allwinner is
16:11:40 <adamw> seems pretty +1-y to me...
16:11:44 * kparal will be back in 10
16:11:47 <cmurf> +1 blocker
16:12:02 <mkolman_> still, I have a rough plan how to handle stuff like this, by basically starting the IS TUI on all suitable consoles
16:12:07 <roshi> +1
16:12:17 <pwhalen> +1
16:12:31 <mkolman_> at once
16:12:37 <adamw> mkolman_: hum...would that mean if it failed to start properly you wouldn't be able to bypass it at all?
16:13:00 <mkolman_> adamw: it would mean one console not starting up should not be an issue
16:13:10 <adamw> yes, i see the upside
16:13:16 <adamw> i'm just trying to think of downsides...
16:13:33 <mkolman_> adamw: but the main motivation is - which console is valid ?
16:13:38 <roshi> proposed #agreed - AcceptedBlocker - RHBZ#1438046 - This bug is a violation of the following criterion: "Release-blocking ARM disk images must boot to the initial-setup utility."
16:13:44 <mkolman_> adamw: the graphical one or say a ttys0 ?
16:13:51 <mkolman_> there is really not way to tell
16:13:58 <adamw> true
16:14:00 <mkolman_> *no way to tell
16:14:14 <adamw> ack
16:14:15 <cmurf> ACKnowledged
16:14:30 <pwhalen> ack
16:14:55 <mkolman_> so hopefully all this would also work in practice :)
16:15:27 <pwhalen> thanks mkolman_, happy to test once you have something
16:15:35 <roshi> #agreed - AcceptedBlocker - RHBZ#1438046 - This bug is a violation of the following criterion: "Release-blocking ARM disk images must boot to the initial-setup utility."
16:15:36 <mkolman_> BTW, any suggestions how to list all consoles users might be using in a robust manner ? ;-)
16:15:44 <mkolman_> pwhalen: thanks! :)
16:15:47 <roshi> last one for Beta
16:15:59 <adamw> mkolman_: ls /dev/*ty* , i'm sure that'd work with no problems ;)
16:16:17 <roshi> #topic (1227736) Minimal grub after a kernel update with gnome-software
16:16:20 <roshi> #link https://bugzilla.redhat.com/show_bug.cgi?id=1227736
16:16:22 <roshi> #info Proposed Blocker, plymouth, NEW
16:16:23 * mkolman_ points to PPC & hvc0
16:16:34 <cmurf> Per ususal, I've used the bugzilla as my lab journal, with running commentary, just in case I die midstream, someone can pick up this very important work. However, I'll summarize.
16:16:59 <cmurf> All pk-offline updates reboot with remount-ro failure of root fs, resulting in XFS and ext4 being dirty at next boot; this can result in boot failure if grub.cfg is on an XFS rootfs.
16:17:27 <cmurf> And the reason why is Plymouth is exempting itself from being killed by systemd, so rootfs can't be remount-ro.
16:18:06 <cmurf> Systemd folks basically ask to please not do that. https://lists.freedesktop.org/archives/systemd-devel/2017-March/038533.html
16:18:19 <cmurf> Unless Plymouth is moved to the initramfs.
16:18:50 <adamw> so basically this is only really bad when you have xfs / and no separate /boot ?
16:19:04 <adamw> and it's been around for a while, right?
16:19:19 <cmurf> adamw the dirty fs is always true, how it manifests depends on configuration
16:19:38 <cmurf> but yes in this particular case of the system being unbootable, it's XFS / and /boot is a directory
16:20:38 <cmurf> I started threads on XFS and systemd lists, those are listed in the bug if anyone wants bedtime reading. The term "bag of dicks" does come up...
16:20:56 <adamw> ah, i always enjoy a good solid technical discussion.
16:21:23 <cmurf> Yes well, systemd blames XFS and XFS blames systemd, what do you expect?
16:21:26 <adamw> this feels like one of those where it sucks if you get caught in it, but that's not gonna be many people.
16:21:46 <cmurf> Nope.
16:22:09 <cmurf> But you don't have to worry about that. It's really clear that plymouth shouldn't exempt itself from being killed unless it's baked into the initramfs.
16:22:36 <cmurf> The further debate that does not concern us is "what if someone else this?" who should prevent bad things from happening, XFS vs systemd
16:23:21 <cmurf> I suggest punting until we hear from plymouth folks.
16:23:31 <cmurf> The bug contains the offending committ.
16:23:54 <cmurf> And yes it's really obscure.
16:24:00 <adamw> i'm quite inclined to -1 on the basis of very limited impact and pre-existence.
16:25:20 <roshi> I'm fine with punting on this one
16:25:46 <roshi> but leaning -1 for the same reasons adam said
16:26:38 <adamw> anyone else?
16:28:06 <cmurf> I still say punt. But baring that I'm +1 because this is a supported layout and offline updates never work in that layout.
16:28:49 <cmurf> I think it's a bad idea to leave the file system dirty.
16:29:00 <kparal> I'd lean to +1 unless heavily argumented against by the devs
16:29:08 <cmurf> Doesn't matter if it's not manifesting with boot failure.
16:29:10 <roshi> so that's 2 punt
16:30:32 <kparal> punt is fine by me
16:31:32 <roshi> proposed #agreed - Punt - RHBZ#1227736 - We're going to defer deciding blocker status on this until we can gather more information.
16:31:34 <pwhalen> +1 punt
16:32:05 <roshi> acks?
16:32:06 <adamw> sure, fine
16:32:08 <cmurf> maybe needinfo plymouth folks?
16:32:10 <cmurf> ackackack
16:32:54 <roshi> #agreed - Punt - RHBZ#1227736 - We're going to defer deciding blocker status on this until we can gather more information.
16:33:10 <roshi> onto the Final proposals
16:33:11 <roshi> #topic (1439282) Tabs crash on loading large sites.
16:33:12 <roshi> #link https://bugzilla.redhat.com/show_bug.cgi?id=1439282
16:33:12 <roshi> #info Proposed Blocker, firefox, NEW
16:34:28 <kparal> seems +1
16:34:29 <cmurf> I haven't hit this bug.
16:34:30 <adamw> eh
16:34:30 <roshi> yeah
16:34:38 <coremodule> What is the criteria it violates?
16:34:43 <adamw> i've seen it crash once or twice lately, i guess, but not enough that i felt like 'whoah, block the release!'
16:34:45 <cmurf> basic functionality test
16:34:46 <coremodule> Ah, I see it.
16:34:59 <roshi> Default application functionality
16:35:15 <coremodule> Yeah +1.
16:35:27 <roshi> I haven't seen it on my F25 machines...
16:35:34 <roshi> but I don't do the facebag and all that
16:35:36 <adamw> though i use ublock and umatrix, which might make giant piles of shitty third-party javascript less likely to cause trouble.
16:35:41 <roshi> so, I guess I wouldn't see it?
16:35:45 <adamw> i just opened twitter.com and it didn't crash.
16:35:46 <cmurf> I haven't seen it on either F25 or F26. I've been using F26 exclusively for two weeks.
16:35:52 <roshi> or it could be my noscript keeping it sane
16:36:01 <adamw> i'd be inclined to punt and ask people on lists how they're findingi t
16:36:08 <cmurf> adamw: good point, i'm using ublock and privacy badger
16:36:08 <adamw> roshi: pshaw, noscript is *so* 2013
16:36:15 <adamw> roshi: get umatrix, man
16:36:27 * roshi is a grumpy old man that doesn't like change
16:36:51 <cmurf> shitty javascript is change; revert to sanity by blocking
16:37:10 <coremodule> I'm okay with a punt to acquire more data.
16:37:10 <roshi> I'm fine with punt to see if more people see it
16:37:49 <cmurf> But hey it's a good tip off this bug might be javascript related...or admalware
16:38:08 <roshi> proposed #agreed - Punt - RHBZ#1439282 - We're going to defer making a blocker decision on this for further testing, because no one in the blocker review meeting has seen this behaviour.
16:38:18 <kparal> ack
16:38:29 <cmurf> acksing
16:38:39 <roshi> #agreed - Punt - RHBZ#1439282 - We're going to defer making a blocker decision on this for further testing, because no one in the blocker review meeting has seen this behaviour.
16:38:47 <roshi> #topic (1438026) GNOME crashes several times a day due to bug in driver
16:38:50 <roshi> #link https://bugzilla.redhat.com/show_bug.cgi?id=1438026
16:38:53 <roshi> #info Proposed Blocker, kernel, NEW
16:39:45 <cmurf> -1 or punt and see if more people run into it still
16:40:01 <coremodule> Agreed, -1 or punt for more info.
16:40:05 <cmurf> I think this is similar to a bug I was hitting on the mac, with i915 enabled, the gpu would hang and then gnome-shell would crash
16:40:23 <cmurf> But that hasn't happened since post alpha updates.
16:40:26 <roshi> -1
16:40:37 <kparal> seems fixed
16:40:41 <cmurf> i think so
16:40:47 <kparal> -1
16:40:56 <cmurf> yeah -1, clear it off the board and renominate if it comes back
16:41:02 <adamw> sure
16:41:12 <adamw> we'd need a much clearer indication of affected hardware to really consider it
16:41:15 <adamw> but if it got fixed anyhow...
16:42:02 <roshi> proposed #agreed - RejectedBlocker - RHBZ#1438026 - This bug seems to already be fixed and it was unclear who all this might affect. Please repropose if it resurfaces.
16:42:29 <adamw> ack
16:42:33 <cmurf> ack
16:42:40 <coremodule> ack
16:42:43 <kparal> ack
16:42:46 <roshi> #agreed - RejectedBlocker - RHBZ#1438026 - This bug seems to already be fixed and it was unclear who all this might affect. Please repropose if it resurfaces.
16:42:55 <roshi> #topic (1436873) KDE live environment notifies of available updates
16:42:58 <roshi> #link https://bugzilla.redhat.com/show_bug.cgi?id=1436873
16:43:00 <roshi> #info Proposed Blocker, plasma-desktop, NEW
16:43:03 <roshi> last one :)
16:43:23 <roshi> +1
16:43:27 <roshi> seems clear to me
16:43:44 <kparal> +1
16:43:50 <cmurf> super clear +1 blocker
16:44:07 <adamw> +1
16:44:12 <roshi> proposed #agreed - AcceptedBlocker - RHBZ#1436873 - This bug is a clear violation of the following criterion: "Release-blocking desktops must notify the user of available updates, but must not do so when running as a live image."
16:44:16 <cmurf> ack
16:44:17 * roshi loves the clear ones
16:45:20 <adamw> ack
16:45:31 <coremodule> ack
16:45:35 <adamw> one naive day back when we wrote the criteria, we thought *all* blocker discussions would be like this
16:45:38 <adamw> oh, what fools we were
16:46:07 <kparal> ack
16:46:15 <cmurf> uss ship it
16:46:17 <roshi> #agreed - AcceptedBlocker - RHBZ#1436873 - This bug is a clear violation of the following criterion: "Release-blocking desktops must notify the user of available updates, but must not do so when running as a live image."
16:46:27 <roshi> #topic Open Floor
16:46:33 <roshi> anyone have anything for open floor?
16:46:41 <adamw> look out for the big hole in the floor!
16:46:51 <cmurf> wat?
16:46:52 <adamw> i really don't know why we don't fix that
16:47:04 * adamw hopes cmurf lands somewhere soft
16:47:16 * cmurf is confuzzled
16:47:17 <coremodule> "Hey Marv, I'
16:47:22 <coremodule> m coming up!!!"
16:47:42 <roshi> lol
16:48:38 * roshi sets fuse
16:49:03 <adamw> maybe it's that big bomb we set off at the end of every meeting that's blowing the hole in the floor
16:49:10 <adamw> we really need to rethink this whole process
16:49:13 <adamw> :P
16:49:53 <coremodule> That... is a good point!
16:51:14 <roshi> lol
16:51:16 <roshi> 3...
16:51:27 <roshi> what's a meeting without some pyrotechnix at the end?
16:51:29 <roshi> 2...
16:51:32 <roshi> 1...
16:51:36 <roshi> thanks for coming folks!
16:51:39 <roshi> #endmeeting