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