16:06:03 <adamw> #startmeeting F26-blocker-review
16:06:03 <zodbot> Meeting started Mon Mar 20 16:06:03 2017 UTC.  The chair is adamw. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:06:03 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:06:03 <zodbot> The meeting name has been set to 'f26-blocker-review'
16:06:04 <adamw> #meetingname F26-blocker-review
16:06:04 <adamw> #topic Roll Call
16:06:04 <zodbot> The meeting name has been set to 'f26-blocker-review'
16:06:07 * pschindl_wfh is here
16:06:12 <adamw> morning folks, who's here for blocker meeting fun?
16:06:16 <jkurik> .hello jkurik
16:06:17 <zodbot> jkurik: jkurik 'Jan Kurik' <jkurik@redhat.com>
16:06:27 * kparal is here
16:06:32 * coremodule is here.
16:06:38 <jkurik> adamw: for the blocker review or for the fun ?
16:07:01 <adamw> fun is not guaranteed
16:07:36 * roshi is here
16:07:39 <roshi> sorry
16:07:41 <adamw> roshi: you wanna take over?
16:07:43 <roshi> got the time wrong
16:07:51 <adamw> .fire roshi
16:07:52 <zodbot> adamw fires roshi
16:07:52 <roshi> :(
16:07:56 <roshi> sure thing
16:08:26 <adamw> #chair roshi
16:08:26 <zodbot> Current chairs: adamw roshi
16:08:30 <adamw> #chair jkurik
16:08:30 <zodbot> Current chairs: adamw jkurik roshi
16:09:10 <roshi> #topic Introduction
16:09:10 <roshi> Why are we here?
16:09:10 <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:09:14 <roshi> #info We'll be following the process outlined at:
16:09:16 <roshi> #link https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting
16:09:19 <roshi> #info The bugs up for review today are available at:
16:09:21 <roshi> #link http://qa.fedoraproject.org/blockerbugs/current
16:09:24 <roshi> #info The criteria for release blocking bugs can be found at:
16:09:26 <roshi> #link https://fedoraproject.org/wiki/Fedora_26_Alpha_Release_Criteria
16:09:29 <roshi> #link https://fedoraproject.org/wiki/Fedora_26_Beta_Release_Criteria
16:09:32 <roshi> #link https://fedoraproject.org/wiki/Fedora_26_Final_Release_Criteria
16:09:55 <roshi> looks like we have 2/1/5 proposed blockers for Alpha/Beta/Final
16:10:16 <roshi> first up
16:10:17 <roshi> #topic (1433560) After enrolling system to FreeIPA domain during install, cannot login as domain user
16:10:20 <roshi> #link https://bugzilla.redhat.com/show_bug.cgi?id=1433560
16:10:22 <roshi> #info Proposed Blocker, anaconda, NEW
16:10:32 <adamw> this one showed up on friday, i'm still looking into it
16:10:45 <adamw> my best guess so far is it has something to do with system time being off between client and server, but i'm really not sure
16:11:46 <roshi> seems a clear +1 to me
16:11:55 <jkurik> I do not what is going on there, however from the description this seems to be clear blocker
16:13:36 <adamw> well, if it's a time issue it'd be easily worked around by...fixing the time, and may not occur in different scenarios (depending on the timezones in kickstarts and stuff)
16:13:41 <adamw> but it's hard to be sure right now
16:13:49 <adamw> we can always accept it for now and change our vote later...
16:13:54 <roshi> yeah
16:14:12 <roshi> more votes?
16:14:15 <jkurik> lets change our vote on thursday :)
16:14:18 <roshi> lol
16:14:43 <adamw> i vote to vote again later!
16:14:49 <adamw> ok, +1 for now
16:14:55 <coremodule> I'm +1
16:14:57 <jkurik> I am +1 for now as well
16:14:59 <pschindl_wfh> +1
16:15:02 <kparal> +1
16:15:44 <roshi> proposed #agreed - AcceptedBlocker - RHBX#1433560 - This bug seems to be a clear violation of the following criterion: "It must be possible to join the system to a FreeIPA or Active Directory domain at install time and post-install, and the system must respect the identity, authentication and access control configuration provided by the domain."
16:16:02 <jkurik> ack
16:16:25 <roshi> who wants to secretarialize?
16:16:40 <pschindl_wfh> ack
16:16:40 <kparal> ack
16:16:48 <coremodule> roshi: I'll do it.
16:17:14 <roshi> thanks coremodule
16:17:21 <roshi> #agreed - AcceptedBlocker - RHBX#1433560 - This bug seems to be a clear violation of the following criterion: "It must be possible to join the system to a FreeIPA or Active Directory domain at install time and post-install, and the system must respect the identity, authentication and access control configuration provided by the domain."
16:17:28 <adamw> you got an X instead of a Z in there.
16:17:46 <roshi> so I do
16:17:49 <roshi> #undo
16:17:49 <zodbot> Removing item from minutes: AGREED by roshi at 16:17:21 : - AcceptedBlocker - RHBX#1433560 - This bug seems to be a clear violation of the following criterion: "It must be possible to join the system to a FreeIPA or Active Directory domain at install time and post-install, and the system must respect the identity, authentication and access control configuration provided by the domain."
16:17:59 <roshi> #agreed - AcceptedBlocker - RHBZ#1433560 - This bug seems to be a clear violation of the following criterion: "It must be possible to join the system to a FreeIPA or Active Directory domain at install time and post-install, and the system must respect the identity, authentication and access control configuration provided by the domain."
16:18:04 <roshi> thanks adamw
16:18:08 <roshi> #topic (1433899) Workstation Live panics when media test is attempted
16:18:11 <roshi> #link https://bugzilla.redhat.com/show_bug.cgi?id=1433899
16:18:13 <roshi> #info Proposed Blocker, kernel, NEW
16:18:31 <kparal> adamw: re last comment - I couldn't find that one criterion :)
16:18:47 <adamw> yeah, it doesn't have the word 'check' in it
16:18:47 <kparal> but it sounds reasonable
16:18:49 <adamw> just to keep you on your toes
16:18:50 <adamw> :P
16:19:12 <adamw> to be fair, completely failing to boot is worse than the check just not running or giving the wrong result or something
16:19:19 <adamw> but it's easy enough to just boot again without the check
16:19:28 <adamw> and i think people will naturally figure that out after a try or two
16:19:35 <adamw> so i'm ok with final blocker for this perosnally
16:19:53 * roshi just commented on the bug
16:20:02 <roshi> I didn't see this with my bare metal install
16:20:05 <jkurik> I would not accept this as a blocker for Alpha, and I am not more/less +1 to have it as a blocker for final
16:20:42 <kparal> I'm fine with -1 Alpha, +1 Final
16:20:45 <adamw> i think i did see it myself once
16:20:57 <adamw> but i was chasing three other things at the time so i didn't circle back and try it again
16:20:58 <kparal> has anyone seen it outside of media check menu?
16:22:49 <adamw> not this one, no
16:23:07 <roshi> +1 for the Final criterion
16:23:26 <pschindl_wfh> +1 for final too
16:23:44 <adamw> thorsten reported some intermittent crash issues with the latest kernel, though - https://bugzilla.kernel.org/show_bug.cgi?id=194911
16:23:50 <adamw> i may have seen that once or twice in a VM too
16:24:05 <roshi> proposed #agreed - AcceptedFinalBlocker - RHBZ#1433899 - This bug is a clear violation of the following Final criterion: "Validation of install media must work correctly for all release-blocking images."
16:24:12 <roshi> note that says FinalBlocker
16:24:34 <jkurik> adamw: is it in the latest compose ?
16:24:40 <roshi> coremodule: you'll have to update which tracking bug it references, just FYI
16:24:48 <kparal> ack
16:24:57 <jkurik> roshi: ack
16:25:04 <adamw> ack
16:25:06 <roshi> #agreed - AcceptedFinalBlocker - RHBZ#1433899 - This bug is a clear violation of the following Final criterion: "Validation of install media must work correctly for all release-blocking images."
16:25:21 <adamw> we usually say "AcceptedBlocker (Final)" but meh
16:25:46 <coremodule> roshi: Yep, got it.
16:26:02 <roshi> I think we've used a variety of formats adamw
16:26:16 <adamw> let's make up another!
16:26:16 <roshi> onto the Beta proposal
16:26:25 <roshi> #topic (1403352) FreeIPA server install fails (and existing servers probably fail to start) due to changes in 'dyndb' feature on merge to upstream BIND
16:26:28 <roshi> #link https://bugzilla.redhat.com/show_bug.cgi?id=1403352
16:26:30 <roshi> can do :p
16:26:32 <roshi> #info Proposed Blocker, freeipa, ON_QA
16:27:24 <jkurik> seems to be fixed
16:27:44 <jkurik> so I am fine to block Beta on this
16:28:13 <roshi> and this seems to already be accepted
16:28:39 <roshi> I'm +1 for this
16:28:42 <adamw> it was previously accepted as an alpha blocker in a different incarnation
16:28:50 <adamw> it's now proposed as a beta blocker for the upgrade impact
16:29:10 <roshi> the rationaly stands, I'd just add AcceptedBlocker to the whiteboard and move on
16:29:47 <jkurik> ack
16:30:59 <pschindl_wfh> ack
16:31:08 <adamw> there should be an explicit comment that it's accepted as a beta blocker,
16:31:41 <adamw> on the basis that it violates the same criterion after upgrade, maybe with a reference to the beta criterion that says upgraded systems have to meet the other criteria
16:32:28 * roshi gathers criteriea for #agreed
16:35:29 * adamw chews on a piece of straw, looks out over field
16:35:36 <roshi> proposed #agreed - AcceptedBetaBlocker - RHBZ#14003352 - The rational behind this blocking Alpha also stands for blocking Beta, as the bug exists after upgrade, and upgrade is covered under the following beta criterion: "For each one of the release-blocking package sets, it must be possible to successfully complete a direct upgrade from fully updated installations of the last two stable
16:35:42 <roshi> Fedora releases with that package set installed."
16:35:51 <roshi> bah, too long
16:36:25 <roshi> proposed #agreed - AcceptedBetaBlocker - RHBZ#14003352 - The rational behind this blocking Alpha also stands for blocking Beta, as the bug exists after upgrade. This violates the beta criterion: "For each one of the release-blocking package sets, it must be possible to successfully complete a direct upgrade from fully updated installations of the last two stable Fedora releases with that
16:36:31 <roshi> package set installed."
16:36:32 <roshi> proposed #agreed - AcceptedBetaBlocker - RHBZ#14003352 - The rational behind this blocking Alpha also stands for blocking Beta, as the bug exists after upgrade. This violates the beta criterion: "For each one of the release-blocking package sets, it must be possible to successfully complete a direct upgrade from fully updated installations of the last two stable Fedora releases with that..."
16:36:38 <roshi> sheesh
16:36:42 <adamw> ack
16:36:46 <adamw> *golf clap*
16:37:00 <roshi> luckily writing these things is at least a par 5
16:37:01 <roshi> so
16:37:27 <adamw> heheh
16:37:32 <adamw> anyone else still alive?
16:37:35 * adamw pokes people
16:37:36 <jkurik> ack
16:37:56 <roshi> #agreed - AcceptedBetaBlocker - RHBZ#14003352 - The rational behind this blocking Alpha also stands for blocking Beta, as the bug exists after upgrade. This violates the beta criterion: "For each one of the release-blocking package sets, it must be possible to successfully complete a direct upgrade from fully updated installations of the last two stable Fedora releases with that..."
16:38:34 * roshi imagines jkurik asleep IRL, someone wakes him and his first word is "ack! Wait, what?" :p
16:38:57 <adamw> he got a special keyboard with an 'ack' key
16:38:58 <roshi> we've got 5 proposed for Final
16:39:09 <roshi> if people are still around, we can go through those
16:39:10 * jkurik was carefully reading all the versions of proposed #agreed
16:40:13 * kparal is here, just having dinner
16:40:53 <adamw> let's go for it
16:40:58 <roshi> wfm
16:41:13 <Kohane> Hi! Sorry that I'm so late
16:41:18 <roshi> no worries
16:41:19 <Kohane> .fas lailah
16:41:20 <zodbot> Kohane: lailah 'Sylvia Sánchez' <BHKohane@gmail.com>
16:41:21 * roshi was late too
16:41:22 * jkurik is here, preparing for a bit of plum brandy before the proposed 5
16:41:41 * Kohane wants plum brandy as well
16:41:55 * roshi remembers he's QA and can drink at all hours of the day :p
16:41:58 <roshi> #topic (1413387) SELinux is preventing spice-vdagentd from 'getattr' accesses on the filesystem /sys/fs/cgroup/systemd.
16:42:01 <roshi> #link https://bugzilla.redhat.com/show_bug.cgi?id=1413387
16:42:04 <roshi> #info Proposed Blocker, selinux-policy, ON_QA
16:42:43 <adamw> roshi: s/can/is required to/
16:43:14 <roshi> \o/
16:43:18 <adamw> i guess this might only happen on vms, but still a lot of systems.
16:43:21 <adamw> +1, sure.
16:43:23 <roshi> +1
16:43:49 <Kohane> +1
16:43:51 <pschindl_wfh> +1
16:44:02 <jkurik> +1
16:44:04 <roshi> proposed #agreed - AcceptedBlockerFinal - RHBZ#1413387 - This bug is a clear violation of the following criterion: "There must be no SELinux denial notifications or crash notifications on boot of or during installation from a release-blocking live image, or at first login after a default install of a release-blocking desktop."
16:44:18 <jkurik> ack
16:44:25 <Kohane> ack
16:44:26 <pschindl_wfh> ack
16:44:42 <adamw> ack
16:44:52 <kparal> ack
16:44:55 <roshi> #agreed - AcceptedBlockerFinal - RHBZ#1413387 - This bug is a clear violation of the following criterion: "There must be no SELinux denial notifications or crash notifications on boot of or during installation from a release-blocking live image, or at first login after a default install of a release-blocking desktop."
16:45:10 <roshi> #topic (1414910) SELinux is preventing gnome-shell from 'execute' accesses on the file 2F7661722F6C69622F67646D2F23333932363239202864656C6574656429.
16:45:13 <roshi> #link https://bugzilla.redhat.com/show_bug.cgi?id=1414910
16:45:15 <roshi> #info Proposed Blocker, selinux-policy, ON_QA
16:45:44 <roshi> +1
16:45:47 <roshi> same as above
16:45:47 <kparal> that's a nice file
16:45:52 <kparal> where is it located?
16:45:56 <roshi> that's how I name all my files
16:46:12 <adamw> under /2/2F7/2F76661722 of course
16:46:14 <adamw> where else would it be
16:46:19 <kparal> that makes sense
16:46:27 <jkurik> +1 to block on the file name :)
16:46:39 <kparal> +1
16:46:48 <Kohane> +1
16:46:49 <adamw> +1
16:46:57 <roshi> it's using the rand(sqrt(2) * 3.141)[:5] file nameing convention
16:47:02 <jkurik> +1
16:47:36 <roshi> proposed #agreed - FinalAcceptedBlocker - RHBZ#1414910 - This bug is a clear violation of the following criterion: "There must be no SELinux denial notifications or crash notifications on boot of or during installation from a release-blocking live image, or at first login after a default install of a release-blocking desktop."
16:48:12 <adamw> roshi: ...in hex?
16:48:14 <adamw> ack
16:48:22 <jkurik> ack
16:48:24 <kparal> ack
16:48:25 <Kohane> ack
16:48:25 <pschindl_wfh> ack
16:48:33 <roshi> in hex and '5' is overloaded to be rand(0, 650000)
16:48:46 <adamw> haha
16:48:50 <roshi> #agreed - FinalAcceptedBlocker - RHBZ#1414910 - This bug is a clear violation of the following criterion: "There must be no SELinux denial notifications or crash notifications on boot of or during installation from a release-blocking live image, or at first login after a default install of a release-blocking desktop."
16:49:06 <roshi> it's in the python stdlib
16:49:14 <roshi> import wtfbruh
16:49:18 <roshi> :p
16:49:36 <roshi> which is a port of how javascript works in general
16:49:37 <adamw> first line of all my apps!
16:49:55 <roshi> import wtfbruh as wat
16:49:57 <roshi> :P
16:50:03 <roshi> #topic (1427312) SELinux is preventing /usr/lib/systemd/systemd from 'mounton' accesses on the directory /usr/lib/modules.
16:50:06 <roshi> #link https://bugzilla.redhat.com/show_bug.cgi?id=1427312
16:50:09 <roshi> #info Proposed Blocker, selinux-policy, ON_QA
16:51:00 * adamw engages autofire mode on his ack key
16:51:02 <roshi> seems like our bug playlist is stuck on repeat
16:51:06 <roshi> +1
16:51:09 <adamw> +1
16:51:30 <Kohane> roshi: I was thinking the same
16:51:31 <jkurik> +1
16:51:32 <Kohane> +1
16:52:09 <roshi> proposed #agreed - FinalBlockerAccepted - RHBZ#1427312 - This bug is a clear violation of the following criterion: "There must be no SELinux denial notifications or crash notifications on boot of or during installation from a release-blocking live image, or at first login after a default install of a release-blocking desktop."
16:52:46 <kparal> ack
16:52:55 <Kohane> ack
16:53:19 <roshi> #agreed - FinalBlockerAccepted - RHBZ#1427312 - This bug is a clear violation of the following criterion: "There must be no SELinux denial notifications or crash notifications on boot of or during installation from a release-blocking live image, or at first login after a default install of a release-blocking desktop."
16:53:27 <roshi> #topic (1429164) SELinux is preventing abrt-dump-journ from 'write' accesses on the sock_file nss.
16:53:30 <roshi> #link https://bugzilla.redhat.com/show_bug.cgi?id=1429164
16:53:32 <roshi> #info Proposed Blocker, selinux-policy, ON_QA
16:53:47 <roshi> +1 ack
16:54:03 <Kohane> Yet another SELinux?
16:54:07 <jkurik> +1
16:54:09 <adamw> +1 ack guilty fired
16:54:09 <Kohane> +1
16:54:22 <roshi> proposed #agreed - AcceptedBlocker - RHBZ#1429164 - This bug is a clear violation of the following criterion: "There must be no SELinux denial notifications or crash notifications on boot of or during installation from a release-blocking live image, or at first login after a default install of a release-blocking desktop."
16:54:27 <roshi> all of them are SELinux
16:54:37 <roshi> #agreed - AcceptedBlocker - RHBZ#1429164 - This bug is a clear violation of the following criterion: "There must be no SELinux denial notifications or crash notifications on boot of or during installation from a release-blocking live image, or at first login after a default install of a release-blocking desktop."
16:54:47 <jkurik> ack :)
16:54:55 * roshi just autofired that one
16:55:01 <roshi> since it's the same wording
16:55:02 <Kohane> ack
16:55:07 <roshi> #topic (1429341) SELinux is preventing (fwupd) from mounton access on the directory /var/lib/fwupd.
16:55:10 <roshi> #link https://bugzilla.redhat.com/show_bug.cgi?id=1429341
16:55:12 <roshi> #info Proposed Blocker, selinux-policy, NEW
16:55:31 <roshi> +1 FE/ +1 Final Blocker
16:56:03 <adamw> all the fixes are in the same update, btw, so we'll get them all for the price of one.
16:56:14 <jkurik> +1
16:56:16 <adamw> +1 ack guilty fired strike three
16:56:23 <roshi> proposed #agreed - AcceptedFinalBlocker AcceptedAlphaFreezeException- RHBZ#1429341 - This bug is a clear violation of the following criterion: "There must be no SELinux denial notifications or crash notifications on boot of or during installation from a release-blocking live image, or at first login after a default install of a release-blocking desktop."
16:56:33 <jkurik> ack
16:56:35 <Kohane> ack
16:56:42 <pschindl_wfh> ack
16:56:50 <roshi> proposed #agreed - AcceptedFinalBlocker AcceptedAlphaFreezeException- RHBZ#1429341 - This bug is a clear violation of the following criterion: "There must be no SELinux denial notifications or crash notifications on boot of or during installation from a release-blocking live image, or at first login after a default install of a release-blocking desktop." We'd gladly accept a fix for Alpha
16:56:56 <roshi> during freeze.
16:56:59 <roshi> proposed #agreed - AcceptedFinalBlocker AcceptedAlphaFreezeException- RHBZ#1429341 - This bug is a clear violation of the following criterion: "There must be no SELinux denial notifications or crash notifications on boot of or during installation from a release-blocking live image, or at first login after a default install of a release-blocking desktop." We'd gladly accept a fix for Alpha.
16:57:05 <roshi> there, and a note for the FE
16:57:34 <adamw> ack
16:57:38 <kparal> ack
16:57:41 <Kohane> ack
16:57:42 <jkurik> ack
16:57:47 <roshi> #agreed - AcceptedFinalBlocker AcceptedAlphaFreezeException- RHBZ#1429341 - This bug is a clear violation of the following criterion: "There must be no SELinux denial notifications or crash notifications on boot of or during installation from a release-blocking live image, or at first login after a default install of a release-blocking desktop." We'd gladly accept a fix for Alpha.
16:57:57 <roshi> #info Moving on to Accepted Review
16:58:17 <roshi> I figure we should move through the accepted Alpha blockers to check status and then break for more validation
16:59:37 <adamw> sure
16:59:55 <Kohane> yes
17:00:20 <roshi> #topic Accpted Review
17:00:21 <roshi> #topic (1430511) cloud init doesn't setup ssh keys for access
17:00:21 <roshi> #link https://bugzilla.redhat.com/show_bug.cgi?id=1430511
17:00:21 <roshi> #info Accepted Blocker, cloud-init, ON_QA
17:00:30 <roshi> fwiw, this one seems fixed in the latest RC
17:00:37 * roshi gave it karma this morning
17:01:09 <adamw> great
17:01:13 <adamw> i'll do a stable push today
17:01:41 <roshi> nirik has also tested it and left results in the test matrix
17:01:46 <roshi> seet
17:01:49 <roshi> sweet, even
17:01:50 <roshi> #topic (1420520) All ARM disk image composes fail in Rawhide
17:01:50 <roshi> #link https://bugzilla.redhat.com/show_bug.cgi?id=1420520
17:01:50 <roshi> #info Accepted Blocker, distribution, NEW
17:02:21 <adamw> so alpha 1 was missing arm images?
17:02:23 <adamw> that's...bad.
17:02:55 <adamw> nirik?
17:03:08 <nirik> huh?
17:03:28 * nirik has no idea on arm images.
17:04:02 <roshi> there's also no Atomic image in the RC1 compose, but I wasn't sure if that was desired or not with the 2week thing
17:04:18 * roshi noticed this morning and hadn't gotten around to asking about it yet
17:04:48 <nirik> I bet it's the compose box using an old koji.
17:05:24 <nirik> well, new.
17:05:28 <adamw> nirik: yeah, i pinged you as you explained the issue originally in the bug
17:05:33 <nirik> I can add a note to the bug
17:05:38 <adamw> so i figured you might know what had happened to make it happen againb
17:05:48 <adamw> roshi: no Atomic in candidate composes is intentional.
17:05:55 <adamw> (though we may change it.)
17:05:57 <roshi> that's what I kinda figured
17:07:03 <adamw> so, basically, we're definitely gonna need an RC2
17:07:14 <adamw> and we'll have to take care when building it that this doesn't happen
17:07:16 <adamw> sound about right?
17:07:29 <roshi> sounds right to me
17:07:38 <roshi> so another RC after the stable push?
17:07:39 <Kohane> sounds right to me too
17:07:48 <roshi> then fire off our test batteries at it
17:07:55 <roshi> and hope we're good to go for Thursday
17:08:00 <jkurik> I am a bit puzzled. There are ARM images in https://kojipkgs.fedoraproject.org/compose/branched/latest-Fedora-26/compose/Spins/armhfp/images/
17:08:10 <jkurik> so, what we are missing ?
17:08:18 <adamw> jkurik: that's the nightly.
17:08:18 <nirik> thats the nightly branched compose.
17:08:21 <nirik> not the rc1
17:08:29 <jkurik> ah, sure, sorry
17:08:31 <adamw> rc1 didn't have any.
17:10:48 <roshi> #info there were no ARM images for RC1 so we will need an RC2
17:11:06 <roshi> anything else for this one?
17:11:39 <jkurik> we need to ask releng during tomorrow for the RC2
17:11:56 <roshi> at the latest, tomorrow
17:12:04 <jkurik> right
17:12:18 <roshi> though I'd like to get one requested today if it's possible
17:12:40 <jkurik> roshi++
17:12:40 <zodbot> jkurik: Karma for roshi changed to 8 (for the f25 release cycle):  https://badges.fedoraproject.org/tags/cookie/any
17:12:46 <adamw> depends on figuring out the freeipa bug :/
17:12:48 <roshi> :D
17:12:53 <roshi> ah, right
17:12:54 <adamw> so that's what i get to do today...
17:13:05 <roshi> summon the internet faeries that do the work!
17:13:14 <roshi> ok, onto the next accepted blocker
17:13:19 <roshi> #topic (1431879) Pre-GDM gnome-initial-setup fails to run (when no user created during install), with log WARNING: Unable to find required component 'gnome-settings-daemon'
17:13:23 <roshi> #link https://bugzilla.redhat.com/show_bug.cgi?id=1431879
17:13:25 <roshi> #info Accepted Blocker, gnome-initial-setup, ON_QA
17:13:59 <adamw> this one i kinda need to re-test a few times
17:14:02 <adamw> the *original* bug is fixed
17:14:11 <roshi> ooh, fun
17:14:12 <adamw> it seems there is another problem behind it that is less...clear c ut
17:14:21 <Kohane> ?
17:14:23 <adamw> actually, if other people could test it with rc1 too, that would help
17:14:36 <adamw> just run an install of Workstation and *don't* create a user during install
17:14:46 <adamw> then see if gnome-initial-setup runs properly on boot of the installed system to create a user
17:15:19 <roshi> I just did this
17:15:26 <roshi> waiting for it to reboot right now
17:18:16 <adamw> basically there's a longstanding kinda race-y issue in gnome startup involving gnome-session and various subprocesses and stuff
17:18:21 <adamw> it's all tracked in a few upstream bugs
17:18:30 <adamw> and basically it sometimes prevents the gnome session starting properly
17:18:39 <adamw> it *seems* like some variant of that problem affected g-i-s startup the first time i tested
17:18:46 <adamw> (after the fix for the initial bug here)
17:21:40 <adamw> so i guess the action here is to figure out how common it still is for g-i-s to fail in the no-user-created-during-install case
17:21:52 <Kohane> roshi: any news?
17:22:44 <Kohane> I don't think that is very common to leave without user a fresh installation...
17:22:54 <roshi> this machine generally has issues
17:22:59 <Kohane> But I never actually researched. So maybe I'm wrong.
17:22:59 <roshi> it's frozen at boot
17:23:06 <roshi> so let's not wait on me
17:23:18 <Kohane> Okay
17:24:51 <adamw> well, 'frozen at boot' is what happens if g-i-s doesn't start up...
17:24:56 <adamw> or did it fail earlier?
17:25:22 <roshi> [ OK ] Started Hostname Service.emon. Dispatcher Service....
17:25:26 <roshi> is where it hung
17:25:32 <roshi> but I can get to another tty and log in
17:25:35 <roshi> as root
17:25:39 <roshi> starting x works
17:25:44 <roshi> no services failed
17:26:14 <jkurik> it looks like some other issue
17:26:51 <adamw> no, that actually looks a lot like g-i-s failing to me.
17:26:55 <adamw> can you post the journal somewhere?
17:27:08 <adamw> but we can probably continue this in #fedora-qa
17:27:14 <adamw> any more accepted to look at?
17:27:21 <roshi> I'll keep looking
17:27:37 <roshi> #info this bug still needs testing
17:27:43 <roshi> #topic (1432667) kernel 4.11.0-0.rc2.git0.1.fc26 oops on Allwinner SoCs
17:27:47 <roshi> #link https://bugzilla.redhat.com/show_bug.cgi?id=1432667
17:27:49 <roshi> #info Accepted Blocker, kernel, ON_QA
17:28:51 <adamw> pwhalen: how do things look in rc1?
17:28:57 <adamw> well, i guess if we had no arm images, it's a bit hard to test :)
17:29:38 <Kohane> Yes, I was thinking that adamw
17:29:50 <jkurik> proposed #info This bug needs to be re-tested once we have RC2 available
17:29:55 <roshi> ack
17:30:49 <Kohane> ack
17:31:07 <jkurik> #info This bug needs to be re-tested once we have RC2 available
17:32:16 <roshi> and that's all we have for accepted for Alpha
17:32:33 <roshi> I propose we go ahead and break here and get back to testing/fixing things
17:32:55 <kparal> breaking things, you mean?
17:33:00 <roshi> #info adamw will submit a stable push today and hopefully we can get an RC started
17:33:09 <roshi> sshh :p
17:33:16 <roshi> ack nack?
17:33:34 <jkurik> ack
17:33:46 <jkurik> looks like a plan
17:33:48 <adamw> ack
17:33:52 <roshi> #topic Open Floor
17:33:52 <Kohane> ack
17:34:01 <roshi> anyone have any last bits before we get back to it?
17:34:26 <Kohane> I don't remember any....
17:34:53 * roshi sets the fuse
17:34:55 <roshi> 3...
17:35:03 <roshi> thanks for coming folks!
17:35:11 <jkurik> roshi: thanks
17:35:17 <roshi> np np
17:35:19 <roshi> 2...
17:35:35 * roshi will endeavor to get the damn time right next time :/
17:35:38 <roshi> 1...
17:35:41 <roshi> #endmeeting