16:01:59 <adamw> #startmeeting F25-blocker-review
16:01:59 <zodbot> Meeting started Mon Sep 12 16:01:59 2016 UTC.  The chair is adamw. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:01:59 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:01:59 <zodbot> The meeting name has been set to 'f25-blocker-review'
16:01:59 <adamw> #meetingname F25-blocker-review
16:01:59 <zodbot> The meeting name has been set to 'f25-blocker-review'
16:01:59 <adamw> #topic Roll Call
16:02:12 <adamw> hi folks! we're just wrapping up the QA meeting, so i'll leave registration open for a few minutes
16:02:15 <adamw> say hi if you're here
16:02:25 * coremodule is here. And happy to act as secretary for today's meeting.
16:02:38 * cmurf here, making "tea" for blocker review hours
16:02:51 <adamw> #info coremodule to secretarialize
16:02:53 <adamw> thanks coremodule
16:03:02 <coremodule> No problem, glad to do it.
16:03:03 <adamw> cmurf: pour me a slug...er, cup
16:03:11 <cmurf> pay me
16:03:13 <cmurf> haha
16:03:39 <cmurf> j/k this is only coffee and milk, no Irish vvisky
16:04:04 <cmurf> but seriously at the 2nd  hour I'm opening the Grand Marnier
16:04:35 * kparal is here
16:04:41 * tenk is here
16:04:42 * kparal pokes pschindl
16:05:38 * pschindl is here
16:06:28 * satellit listening
16:06:29 * pwhalen is here
16:07:32 <adamw> alrighty, let's get rolling!
16:07:50 <adamw> #chair kparal pwhalen
16:07:50 <zodbot> Current chairs: adamw kparal pwhalen
16:07:59 <adamw> #topic Introduction
16:07:59 <adamw> Why are we here?
16:07:59 <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:07:59 <adamw> #info We'll be following the process outlined at:
16:08:00 <adamw> #link https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting
16:08:00 <adamw> #info The bugs up for review today are available at:
16:08:04 <adamw> #link http://qa.fedoraproject.org/blockerbugs/current
16:08:06 <adamw> #info The criteria for release blocking bugs can be found at:
16:08:08 <adamw> #link https://fedoraproject.org/wiki/Fedora_25_Alpha_Release_Criteria
16:08:10 <adamw> #link https://fedoraproject.org/wiki/Fedora_25_Beta_Release_Criteria
16:08:12 <adamw> #link https://fedoraproject.org/wiki/Fedora_25_Final_Release_Criteria
16:08:14 <adamw> we have - buckle up, folks::
16:08:22 <adamw> #info 9 Proposed Blockers (Beta)
16:08:30 <adamw> #info 8 Proposed Blockers (Final)
16:08:35 <adamw> #info 2 Accepted Blockers (Beta)
16:09:28 <cmurf> my god man
16:09:30 <kparal> let's give up immediately
16:09:49 <kparal> what's wrong on skipping a release, right?
16:09:52 <cmurf> that's the perfect phrase
16:10:12 <cmurf> i'm still giggling
16:10:46 <cmurf> this is still so much better than days of yore where it was something like 18 proposed blockers...
16:11:01 <adamw> right
16:11:18 <adamw> some of these should be pretty straightforward, too...
16:11:18 <adamw> #topic (1371338) pyanaconda.nm.SettingsNotFoundError: SettingsNotFoundError('ens3',)
16:11:18 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1371338
16:11:18 <adamw> #info Proposed Blocker, anaconda, VERIFIED
16:11:58 <adamw> this was a straight up failure of anaconda to run on UEFI, so pretty obvious +1 to me
16:12:00 <adamw> it also got fixed already, so yay
16:12:18 <pschindl> +1
16:12:19 <kparal> +1
16:12:31 <pwhalen> +1
16:12:38 <adamw> oh wait sorry, it was text install, not UEFI.
16:12:38 <tenk> +1
16:12:46 <adamw> still makes it a blocker, though.
16:12:51 <cmurf> yeah i was gonna say, works for me!
16:12:51 * adamw getting his showstoppers mixed up...
16:13:10 <cmurf> textui, uefi - all the same melt
16:13:25 <adamw> proposed #agreed 1371338 - AcceptedBlocker (Beta) - this violates Alpha criterion "When using a dedicated installer image, the installer must be able to complete an installation using the text, graphical and VNC installation interfaces."
16:13:34 <pwhalen> ack
16:13:36 <cmurf> ack
16:14:34 <kparal> ack
16:15:08 <adamw> #agreed 1371338 - AcceptedBlocker (Beta) - this violates Alpha criterion "When using a dedicated installer image, the installer must be able to complete an installation using the text, graphical and VNC installation interfaces."
16:15:36 <adamw> coremodule: note: you can't distinguish between accepting it as an F25 Beta blocker and an F26 Alpha blocker, it'll be considered 'accepted' as both. but that's fine, not really a problme.
16:15:46 <adamw> #topic (1372868) F25 Alpha-2 Installer Fails if  DVD-ROM is on Silicon Image 3114 SATA Controller
16:15:46 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1372868
16:15:46 <adamw> #info Proposed Blocker, anaconda, NEW
16:15:55 <cmurf> punt. a.) we need more info, no idea where it's even failing b.) it'd be a conditional blocker due to hardware specifics
16:16:08 <coremodule> adamw, Gotcha, I won't worry about it.
16:16:28 <adamw> cmurf: it's either punt or -1 for me, yeah. sad bug though
16:17:11 <cmurf> it's not even getting to the installer
16:17:43 <adamw> i guess if everyone can try burning a current nightly image to an actual optical disc and booting it on all the optical drives they have, that'd be helpful'
16:17:47 <adamw> we could send out a mailing list call
16:17:51 <cmurf> very good idea
16:18:05 <kparal> let's do that, we can try tomorrow in the office
16:18:13 <adamw> #action adamw to send out call for optical media testing
16:18:23 <adamw> #undo
16:18:23 <zodbot> Removing item from minutes: ACTION by adamw at 16:18:13 : adamw to send out call for optical media testing
16:18:23 <pwhalen> +1 punt, get more info
16:18:24 <cmurf> do i have optical media here???
16:18:28 <adamw> #action adamw to send out call for optical media testing in re 1372868
16:18:38 * adamw still has a spindle of honest-to-god CD-Rs
16:18:42 <pschindl> +1 punt
16:18:46 <cmurf> woohoo! dvd+rw
16:18:51 <adamw> since we had a fun bug a couple of releases back where it'd boot from a CD but not a DVD or vice versa...
16:19:15 <cmurf> that's obscure
16:22:25 <adamw> proposed #agreed 1372868 - punt (delay decision) - we're not yet sure exactly how this is failing or how much hardware may be affected; we have asked the reporter for more info and will also put out a call for optical media testing
16:22:41 <kparal> ack
16:22:49 <pschindl> ack
16:23:47 <pwhalen> ack
16:23:53 <tenk> ack
16:23:54 <adamw> #agreed 1372868 - punt (delay decision) - we're not yet sure exactly how this is failing or how much hardware may be affected; we have asked the reporter for more info and will also put out a call for optical media testing
16:24:06 <adamw> #topic (1366775) /usr/libexec/gnome-settings-daemon is hammering CPU after login tring to connect to local printing service
16:24:06 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1366775
16:24:06 <adamw> #info Proposed Blocker, cups, NEW
16:24:12 <adamw> ooh look, this one's not a slam dunk
16:24:16 <cmurf> comment 2: cups is disabled, appears to be an instigator? but then comment 10 has justification doesn't say whether cups was disabled first? I haven't run into this problem.
16:25:12 <cmurf> if CUPS is disabled by the user and that instigates the problem, I'd say not a blocker
16:25:18 <cmurf> bad bug, but not a blocker
16:27:22 <kparal> I see this in my VMs
16:27:30 <kparal> default installation, nothing changed
16:27:47 <adamw> hum, i recall seeing it before (at least the high CPU use) but it doesn't seem to be happening on this boot
16:28:14 <adamw> i'm not sure i saw all the other consequences Christian identified...
16:28:21 <kparal> what does this mean? "* Applications relying on g-s-d break, miss functionality or are rendered useless"
16:28:30 <adamw> yeah, not sure about that one
16:28:39 <adamw> i guess login did take a long time last time i logged in, now i think about it
16:29:06 <cmurf> hrmmm
16:29:10 <adamw> huh. now i have htop running, i just noticed that when i open the overview, three nautilus processes show up and start eating a ton of CPU time, and don't seem to go away again.
16:29:17 <cmurf> are this subsequent logins?
16:29:18 <kparal> I think it's not really a Beta blocker, but we could discuss Final one
16:29:30 <cmurf> adamw: eww
16:30:16 <adamw> kparal: yeah, it feels more final than beta for me for sure
16:30:33 <adamw> cmurf: i think the reporter considers this a 'steady state' bug, it happens on every boot, all the time
16:30:39 <adamw> it's not a thing that suddenly gets 'triggered' sometimes
16:31:21 <kparal> happens every time for my VMs, yeah
16:31:28 <kparal> doesn't happen on my bare metal, though
16:31:55 <cmurf> definitely did not happen baremetal with an installation over the weekend for me
16:32:22 <cmurf> but I don't recall it an issue in VM's either
16:32:35 <adamw> so it sounds like we're definitely not +1 beta on this
16:32:39 <cmurf> right
16:32:43 <adamw> and maybe like we should punt for final and get more data?
16:32:55 <cmurf> but mainly, we don't have all the facts, we're not sure what's going on or how common it is
16:33:02 <cmurf> so even if it's blocker worthy, what to block?
16:33:04 <kparal> yeah, -1 Beta, punt Final, ask for clarification about "renders apps useless"
16:33:17 <adamw> sounds good
16:33:22 <pwhalen> -1 beta, punt more info
16:33:25 <kparal> the login delay surely annoys me
16:33:28 <cmurf> yes
16:33:39 <cmurf> it would annoy me too if i could reproduce it :-P
16:34:07 <adamw> for that matter, i'm not sure we've actually proved the slow login is part of this bug, the report *states* that it is but i'm not sure it demonstrates it?
16:34:16 <cmurf> good point
16:34:21 <cmurf> may be orthogonal and a separate problem
16:34:31 <cmurf> a two in one
16:35:23 <adamw> proposed #agreed 1366775 - change to proposed Final blocker, punt (delay decision) on accepting it - we generally agreed this doesn't violate the criteria sufficiently to be considered a Beta blocker. we're more open to considering it a Final blocker, but there seem to be several unclear points we want to clarify before deciding
16:35:38 <adamw> coremodule: so don't mark RejectedBlocker, but change it to blocking FinalBlocker instead of BetaBlocker
16:35:39 <cmurf> ack
16:35:44 <coremodule> adamw, Gotcha.
16:36:46 <kparal> ack
16:36:47 <pwhalen> ack
16:38:06 <adamw> #agreed 1366775 - change to proposed Final blocker, punt (delay decision) on accepting it - we generally agreed this doesn't violate the criteria sufficiently to be considered a Beta blocker. we're more open to considering it a Final blocker, but there seem to be several unclear points we want to clarify before deciding
16:38:13 <adamw> #topic (1374852) /etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-25-x86_64 missing from Fedora 23
16:38:13 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1374852
16:38:13 <adamw> #info Proposed Blocker, fedora-repos, ON_QA
16:38:20 <cmurf> +1
16:38:30 <adamw> this one's kinda straightforward, it breaks all f23 to f25 upgrades (you can see them all failing in openqa, every day)
16:38:49 <cmurf> it's a thank you captain obvious blocker bug
16:38:50 <adamw> so, +1
16:39:05 <pwhalen> +1
16:39:07 <coremodule> +1
16:39:13 <pschindl> ₊
16:39:23 <pschindl> +1
16:39:25 <kparal> +1
16:39:26 <tenk> +1
16:40:20 <mboddu> +1
16:40:29 <tenk> hmm
16:40:53 <tenk> I have done a working upgrade from F23 to F25 ALpha 1.2 this afternoon
16:41:13 <adamw> how?
16:41:40 <tenk> like the testcase
16:41:43 <tenk> 2s
16:41:58 <adamw> do you have updates-testing enabled on your f23 install?
16:42:20 <tenk> https://fedoraproject.org/wiki/QA:Testcase_upgrade_dnf_previous_server
16:42:45 <tenk> ok get my miss
16:42:49 <tenk> probably
16:42:57 <adamw> the fix for this was already sent to u-t, so if you have it enabled, that'd explain why it worked
16:44:23 <tenk> ok i will remove my check on the F25 Alpha 1.2 Test
16:44:25 <tenk> sorry for that
16:44:57 <adamw> tenk: don't worry too much, this test doesn't fit great into the matrices, it's a bit awkward :)
16:45:30 <adamw> proposed #agreed 1374852 - AcceptedPreviousRelease - violates "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 package set installed."
16:45:39 <adamw> coremodule: you remember the 'special blocker' states?
16:45:39 <pwhalen> ack
16:45:44 <tenk> ack
16:45:53 <kparal> ack
16:45:55 <cmurf> akc
16:46:02 <coremodule> adamw, 'Special blocker' states... Not off the top of my head, no...
16:46:15 <adamw> coremodule: https://fedoraproject.org/wiki/QA:SOP_blocker_bug_process#Normal.2C_0-Day_and_Previous_Release_blockers
16:46:25 <adamw> basically just put 'AcceptedPreviousRelease' instead of 'AcceptedBlocker'.
16:46:46 <adamw> #agreed 1374852 - AcceptedPreviousRelease - violates "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 package set installed."
16:46:57 <coremodule> adamw, Roger that!
16:47:02 <adamw> #topic (1373169) Can't login again after logout.
16:47:02 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1373169
16:47:03 <adamw> #info Proposed Blocker, gnome-session, NEW
16:47:11 <adamw> this is the wayland bug kparal mentioned in the meeting, i think
16:47:58 <kparal> very annoying
16:48:12 <kparal> debugging takes eternity when you need to reboot all the time
16:48:53 <kparal> you can log in again with X11 session, but not with Wayland session
16:49:14 <cmurf> huh
16:49:25 <cmurf> this is definitely a regression from f24 wayland i do this all the time
16:49:35 <adamw> this doesn't *technically* violate the criterion, because logging out works.
16:49:44 <adamw> logging back in again actually isn't covered in the criterion...
16:49:59 * kparal looks very angrily at adamw
16:50:07 <adamw> ;)
16:50:11 <adamw> hmm, well: "Logging out must return the user to the environment from which they logged in, working as expected."
16:50:12 <pwhalen> heh
16:50:15 <kparal> I don't think logging out works
16:50:21 <kparal> some processes are hanging
16:50:27 <adamw> so i guess the 'environment from which they logged in' isn't 'working as expected'.
16:50:29 <kparal> in loginctl the sessions are still listed
16:50:32 <adamw> okay, i can say +1 then.
16:50:52 <kparal> +1 here
16:50:56 <pwhalen> +1
16:51:20 <cmurf> oh guess what?
16:51:28 <kparal> you reproduced the bug
16:51:46 <cmurf> no
16:52:06 <cmurf> but my /etc/systemd/logind.conf has KillUserProcesses=yes
16:52:17 <cmurf> that's very likely why I don't run into this on F24
16:52:24 <cmurf> which means it may NOT be a regression
16:53:58 <kparal> I thought it's the default now on F25?
16:54:15 <cmurf> it was supposed to be a feature, but it didn't get completed so it was withdrawn
16:54:38 <cmurf> let me check my f25 installation
16:55:15 <cmurf> it's commented out on Fedora 25
16:55:17 <cmurf> cleanly installed
16:55:18 <kparal> I know that if I kill all sessions with loginctl, I can log in again into wayland
16:55:21 <kparal> otherwise I can't
16:55:30 <cmurf> poop
16:55:46 <kparal> which makes me assume something is hanging and preventing re-login
16:56:48 <cmurf> yep
16:56:51 <cmurf> exactly
16:57:03 <cmurf> +1 blocker but for beta or final?
16:57:30 <adamw> kparal: are you definitely seeing the same problem as pavel? same log messages?
16:58:05 <cmurf> yeah because pavel has all kinds of spurious errors
16:58:16 <kparal> the same symptoms, didn't check log messages
16:58:34 <adamw> probably be worth checking, this feels like the kind of thing where we could wind up realizing there are ten different bugs all causing the same result
16:58:42 <kparal> I'll add my logs to the bug
16:59:01 <kparal> either way, I haven't seen a system where re-login would work
16:59:09 <kparal> should be trivially reproducible in a VM
16:59:47 <adamw> i'm a tad inclined to punt on this just purely so we can straighten out the report and make sure everyone's hitting the same case
17:00:17 <kparal> no problem
17:03:47 <adamw> anyone else?
17:04:05 <cmurf> is it better to just have kparal file a bug with his logs?
17:04:13 <cmurf> and then punt and get more info on this one?
17:04:22 <kparal> it's the same bug
17:04:34 <cmurf> i mean same cause
17:04:46 <cmurf> if you're sure it's the same cause, fine don't file a new bug
17:05:04 <cmurf> but your bug is convincing as a blocker straight away without even looking at logs, the way you're describing it
17:05:24 <cmurf> ^convincing *to me*
17:05:31 <kparal> let me work on that tomorrow
17:06:10 <adamw> cmurf: i'd just like us to have a couple other people confirm it happens
17:06:15 <adamw> i'm fully expecting we *will*
17:07:06 <adamw> proposed #agreed 1373169 - punt (delay decision) - we're pretty sure this will be accepted as a blocker, but we'd just like to have kparal check he's really running into the same case as pavel, and have a few other people confirm it happens for them too
17:07:20 <cmurf> ack
17:07:49 <pwhalen> ack
17:08:15 <kparal> ack
17:08:49 <adamw> #agreed 1373169 - punt (delay decision) - we're pretty sure this will be accepted as a blocker, but we'd just like to have kparal check he's really running into the same case as pavel, and have a few other people confirm it happens for them too
17:09:20 <adamw> #topic (1373134) initial-setup doesn't run on ARM with: "pyanaconda.nm.SettingsNotFoundError: SettingsNotFoundError('eth0',)"
17:09:21 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1373134
17:09:21 <adamw> #info Proposed Blocker, initial-setup, NEW
17:09:39 <cmurf> g-i-s needs to run at beta yes? if so +1 blocker
17:10:15 <cmurf> question is whether this is directly a g-i-s bug or networkmanager or something else
17:10:41 <pwhalen> +1, duplicate of the other, and fixed
17:10:59 <pschindl> +1
17:11:08 <cmurf> ahh ok
17:11:20 <cmurf> so just mark it as a dup of 1371338
17:11:42 <pwhalen> right
17:11:42 <adamw> the correct criterion here is "A working mechanism to create a user account must be clearly presented during installation and/or first boot of the installed system."
17:11:48 <adamw> from alpha
17:12:07 <adamw> i guess making it a dupe is easiest
17:12:37 <adamw> proposed #agreed 1373134 - close as duplicate of 1371338 - they had the same cause and are fixed by the same fix
17:13:26 <pwhalen> ack
17:14:18 <cmurf> ack
17:14:19 <pschindl> ack
17:14:26 <adamw> #agreed 1373134 - close as duplicate of 1371338 - they had the same cause and are fixed by the same fix
17:14:35 <adamw> #topic (1374810) initial-setup fails - TypeError: unhashable type: 'list'
17:14:35 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1374810
17:14:35 <adamw> #info Proposed Blocker, initial-setup, NEW
17:15:39 <adamw> oh jeez, my favourite python limitation
17:16:27 <pwhalen> +1
17:16:30 <adamw> (this means the value of 'server' is a list, and python won't use it as a dict key)
17:17:05 <cmurf> +1
17:17:06 <adamw> assuming this always happens, +1, violates "A working mechanism to create a user account must be clearly presented during installation and/or first boot of the installed system." , because i-s is the mechanism for ARM
17:17:27 <tenk> +1
17:18:19 <pwhalen> adamw, saw it first when testing the other fix, appears on todays images with the new anaconda build
17:19:25 <adamw> proposed #agreed 1374810 - AcceptedBlocker - violates Alpha criterion "A working mechanism to create a user account must be clearly presented during installation and/or first boot of the installed system." for the release-blocking ARM images, where i-s is the only user creation mechanism
17:19:53 <pwhalen> ack
17:19:57 <kparal> ack
17:20:52 <cmurf> ack
17:20:56 <adamw> #agreed 1374810 - AcceptedBlocker - violates Alpha criterion "A working mechanism to create a user account must be clearly presented during installation and/or first boot of the installed system." for the release-blocking ARM images, where i-s is the only user creation mechanism
17:21:03 <adamw> topic (1374864) initial-setup is not completable
17:21:03 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1374864
17:21:03 <adamw> #info Proposed Blocker, initial-setup, NEW
17:21:09 <adamw> wow, initial-setup sure works good huh
17:21:50 <cmurf> sounds like a repeat?
17:22:18 <cmurf> dup of 1371338 again?
17:22:53 <cmurf> oh never mind no
17:23:39 <cmurf> dgilmore is saying without any network at all he can't create a user on ARM with g-i-s?
17:24:46 <adamw> it's pwhalen, not dgilmore...
17:24:54 <cmurf> are we on the same bug?
17:24:55 <pwhalen> apparently you cant complete it with no network, which i think is a regression
17:24:55 <adamw> oh sorry, i'm in the wrong bug.
17:25:02 * adamw multitasking
17:25:17 <cmurf> .fire adamw
17:25:17 <zodbot> adamw fires adamw
17:26:00 <adamw> this could still be related to the other bugs somehow, i guess, but we haven't proved it
17:26:17 <cmurf> well it's not crashing
17:26:24 <adamw> this isn't just not having a network *connection*, note, but having absolutely no working network devices, i think
17:26:33 <cmurf> yeah that's where I'm at
17:26:47 <adamw> if so, i'd probably be -1 blocker unless such a system was on the list of 'officially supported' arm devices
17:27:09 <cmurf> we require network to install?
17:27:24 <cmurf> to complete an installation?
17:27:43 <cmurf> seems questionable
17:27:45 <pwhalen> this would be to boot, which i think should be possible without network/device
17:28:17 <cmurf> it's first boot though, as g-i-s only comes up on first boot
17:28:31 <adamw> this is i-s, not g-i-s.
17:28:37 <cmurf> oh
17:28:40 <cmurf> OOOHH
17:28:49 <adamw> and the reason i-s is blocking on ARM is that it's the only place you can create a user account and/or set the root password.
17:29:13 <pwhalen> if not completed, it comes up everytime, also need to complete it to log in
17:29:22 <adamw> pwhalen: i think it should be possible without a network *connection*
17:29:25 <cmurf> gotcha yeah so the work around is init=/bin/bash that's not  ok for final, maybe not even beta
17:29:44 <adamw> but i'm less sold on it having to be possible without a working network *device* unless a system with no kind of working network device ootb is one of our supported arm targets
17:30:00 <cmurf> ?
17:30:14 <pwhalen> dgilmore said "you can reproduce by booting the system without a network cable plugged in" so the device is there, but not connected
17:30:45 <adamw> hmm, if that's correct then i'd be +1
17:30:50 <adamw> as he explained it on irc it didn't sound that way
17:31:26 <cmurf> needinfo?
17:32:02 <cmurf> I guess I'm skeptical of any hard requirement on working network, regardless of x86 or ARM.
17:32:54 <adamw> i guess i can just vote +1 on the bug description...
17:33:08 <pwhalen> most dont have an rtc, so the clock will be way off if theres no network
17:33:25 <pwhalen> +1
17:33:30 <cmurf> +1
17:34:11 <cmurf> pwhalen: sure network makes sense eventually, but just to create a user and get past the initial setup?
17:34:27 <cmurf> I dunno, maybe it's up to the ARM folks if they really want to block on it, more than QA
17:34:53 <pwhalen> no, agree, you should be able to complete it with a connection.. or hw imo
17:35:06 <adamw> cmurf: um. if we *don't* want a hard requirement for network, we should accept this as a blocker.
17:35:06 <pwhalen> *without
17:35:12 <adamw> so, yeah, let's just take it
17:35:47 <adamw> proposed #agreed 1374810 - AcceptedBlocker (Beta) - this violates "A working mechanism to create a user account must be clearly presented during installation and/or first boot of the installed system" in the case of an ARM system with no network connection, which we agreed is severe enough to constitute a blocker
17:35:52 <cmurf> ack
17:35:53 <pwhalen> ack
17:36:02 <tenk> ack
17:36:05 <adamw> #agreed 1374810 - AcceptedBlocker (Beta) - this violates "A working mechanism to create a user account must be clearly presented during installation and/or first boot of the installed system" in the case of an ARM system with no network connection, which we agreed is severe enough to constitute a blocker
17:36:51 <adamw> oh crud
17:36:59 <adamw> i missed a hash back there a ways
17:37:00 <adamw> #undo
17:37:00 <zodbot> Removing item from minutes: AGREED by adamw at 17:36:05 : 1374810 - AcceptedBlocker (Beta) - this violates "A working mechanism to create a user account must be clearly presented during installation and/or first boot of the installed system" in the case of an ARM system with no network connection, which we agreed is severe enough to constitute a blocker
17:37:02 <adamw> #undo
17:37:02 <zodbot> Removing item from minutes: INFO by adamw at 17:21:03 : Proposed Blocker, initial-setup, NEW
17:37:05 <adamw> #undo
17:37:05 <zodbot> Removing item from minutes: <MeetBot.items.Link object at 0x2dfc88d0>
17:37:20 <adamw> #topic (1374864) initial-setup is not completable
17:37:20 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1374864
17:37:20 <adamw> #info Proposed Blocker, initial-setup, NEW
17:37:37 <adamw> #agreed 1374864 - AcceptedBlocker (Beta) - this violates "A working mechanism to create a user account must be clearly presented during installation and/or first boot of the installed system" in the case of an ARM system with no network connection, which we agreed is severe enough to constitute a blocker
17:37:43 <adamw> better.
17:37:56 <adamw> #topic (1374334) Error setting partition type after formatting
17:37:56 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1374334
17:37:56 <adamw> #info Proposed Blocker, storaged, NEW
17:37:56 <cmurf> ack
17:38:26 <cmurf> ok so, does using Disk Utility to format a stick constitute basic functionality?
17:39:04 <cmurf> I'd say yes, so if it can't properly create a partition map without failing it's a blocker, IMO. However, not against storaged, this is almost certainly the bug in comment 6
17:40:19 <adamw> erf, it's kinda borderline for me
17:40:29 <cmurf> Thing is, I can't tell if this bug fails because of the sfdisk bug (which is fixed and pushed, just not sure if it went to stable or u-t) or all the AVC denials
17:40:34 <kparal> so how do you format a usb stick in gnome?
17:40:35 <adamw> when i wrote 'basic functionality' it was kind of a codification of 'run the app in a vm and click around a bit' (which is what the test case covers)
17:40:42 <cmurf> he's getting a bunch of AVC denials on the mkfs command itself?
17:40:47 <adamw> kparal: from a console, with mkfs. :P
17:40:52 <kparal> I mean what is gnome-disks used to by an ordinary user?
17:41:01 <kparal> if not formatting sticks?
17:41:03 <adamw> looking at pretty graphs of disks, of course!
17:41:11 <kparal> I think those were removed
17:41:15 <cmurf> that's something else, that's the grapher app or whateverit's called
17:41:16 <kparal> if you mean performance testing
17:41:36 <cmurf> the usage map thingy (hand wave, read my mind)
17:41:37 <adamw> no, i mean the disk layout horizontal bar chart...things...that anaconda hates.
17:41:42 <kparal> gotcha
17:41:53 <adamw> oh hey, it doesn't run on my desktop at *all*. that's fun.
17:41:54 <kparal> that's probably less useful than formatting sticks
17:41:58 <cmurf> yes
17:42:02 <kparal> adamw: do you have a dvd drive?
17:42:08 <adamw> less useful, but so much easier to test!
17:42:09 <adamw> sure i do.
17:42:13 <kparal> currently it fails if you have a dvd drive because of selinux
17:42:16 <adamw> fun
17:42:20 <cmurf> haha shit
17:42:20 <kparal> try it with setenforce 0
17:42:45 <adamw> that seems like it should be a blocker
17:42:57 <kparal> it's proposed for Final
17:43:00 <cmurf> the fact it doesn't run at all?
17:43:23 <adamw> yeah, this should be final as well...
17:43:24 <kparal> thinking about this, this one bug should have been proposed for Final
17:43:29 <adamw> i think the proposer intended to
17:43:29 <kparal> Pavel made a mistake
17:43:38 <kparal> he quoted final criterion
17:44:10 <cmurf> well the sfdisk bug cited in comment 6 is probably a beta blocker for cloud because it breaks cloud-init (kindof a tangent)
17:44:37 <kparal> as I see this, formatting drives and creating partitions is a basic functionality of gnome-disks
17:44:47 <cmurf> yeah i think so
17:45:00 <kparal> it's not marketed as a read-only app
17:45:18 <cmurf> OK so the sfdisk problem is fixed in util-linux-2.28.2-1.fc25 which has been pushed stable
17:45:28 <kparal> we might need to retest it then
17:45:40 <adamw> kparal: as the developer sees it, it isn't
17:45:52 <cmurf> yes to see if it still fails due to AVCs
17:46:03 <cmurf> or something else
17:47:08 <kparal> adamw: well, one of them
17:48:20 <kparal> we can punt and retest tomorrow
17:48:26 <kparal> it's for Final anyway
17:48:31 <kparal> change swap the tags
17:48:34 <kparal> *just
17:48:39 <cmurf> kparal: about the wayland logout logbacking bug, did you launch any apps or just login and immediately logout then try to login again?
17:49:58 <kparal> cmurf: immediate logout triggers it
17:50:07 <kparal> but logout after some time as well
17:50:22 <adamw> proposed #agreed 1374334 - move to proposed Final blocker, punt (delay decision) - this should have been proposed for Final, not Beta, under the criterion cited. we believe it may have been fixed, so we will delay the decision to re-test and clarify the report
17:50:23 <cmurf> this is booted from live or as-installed?
17:50:28 <cmurf> ack
17:50:45 <tenk> ack
17:51:23 <kparal> ack
17:51:33 <kparal> cmurf: installed
17:51:43 <cmurf> kparal: ok testing it now
17:52:27 <cmurf> not hitting it
17:52:47 <kparal> cmurf: also happens with Live
17:52:53 <cmurf> not hitting it
17:52:59 <kparal> interesting
17:53:01 <cmurf> neither live nor as installed
17:53:08 <cmurf> i log out, i can log right back in
17:53:14 <kparal> Fedora-Workstation-Live-x86_64-25-20160911.n.0.iso
17:53:20 <adamw> can you discuss in #fedora-qa please?
17:53:20 <kparal> and installed with full updates-testing
17:53:22 <adamw> we're not on that bug right now.
17:53:25 <kparal> sorry
17:53:31 <adamw> #agreed 1374334 - move to proposed Final blocker, punt (delay decision) - this should have been proposed for Final, not Beta, under the criterion cited. we believe it may have been fixed, so we will delay the decision to re-test and clarify the report
17:53:53 <adamw> coremodule: can you move that from Beta to Final as well as noting the delay? thanks
17:54:03 <adamw> #info that's all proposed Beta blockers, moving onto proposed Final
17:54:41 <adamw> #topic (1374321) file-roller has all actions disabled under wayland
17:54:42 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1374321
17:54:42 <adamw> #info Proposed Blocker, file-roller, NEW
17:54:48 <adamw> seems pretty obvious as described, +1
17:54:52 <coremodule> adamw, I can do that!
17:55:18 <kparal> +1
17:55:45 <pwhalen> +1
17:57:13 <adamw> proposed #agreed 1374321 - AcceptedBlocker (Final) - violates "All applications that can be launched using the standard graphical mechanism of a release-blocking desktop after a default installation of that desktop must start successfully and withstand a basic functionality test"
17:57:44 <pschindl> ack
17:58:03 <kparal> ack
17:58:54 <adamw> #agreed 1374321 - AcceptedBlocker (Final) - violates "All applications that can be launched using the standard graphical mechanism of a release-blocking desktop after a default installation of that desktop must start successfully and withstand a basic functionality test"
17:58:59 <adamw> #topic (1373933) object selection and edit freezes libreoffice for several seconds
17:59:00 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1373933
17:59:00 <adamw> #info Proposed Blocker, libreoffice, NEW
17:59:50 <adamw> kparal: hum, doesn't seem to affect just regular text in writer?
17:59:52 * adamw tries impress
18:00:03 <adamw> oh, this is wayland, right?
18:00:04 <kparal> it does, if you insert graphics or objects into the text document
18:00:07 <kparal> yes
18:00:10 <adamw> oh no, you said x11.
18:00:13 <adamw> ah k
18:00:38 <kparal> yes, should happen as well on X11
18:00:51 <kparal> but this makes impress and draw basically unusable
18:01:09 <kparal> it's not such a big problem with writer, unless you have many inline pictures, I guess
18:01:59 <adamw> oh yeah, impress is completely unusable...i can't select a chunk of text at all even
18:02:23 <adamw> +1
18:02:28 <kparal> +1
18:02:45 <coremodule> +1
18:02:49 <cmurf> sad
18:03:01 <cmurf> I wonder if it's using wayland directly or xwayland
18:03:22 <adamw> proposed #agreed 1373933 - AcceptedBlocker (Final) - this constitutes a violation of "All applications that can be launched using the standard graphical mechanism of a release-blocking desktop after a default installation of that desktop must start successfully and withstand a basic functionality test", as it's impossible to do basic work in Impress or Draw
18:03:25 <adamw> cmurf: i'm on X11.
18:03:35 <cmurf> oh well that's bad
18:03:39 <adamw> and kparal says it affects x11 for him too.
18:03:41 <cmurf> ack
18:03:42 <coremodule> ack
18:03:44 <kparal> ack
18:03:55 <adamw> #agreed 1373933 - AcceptedBlocker (Final) - this constitutes a violation of "All applications that can be launched using the standard graphical mechanism of a release-blocking desktop after a default installation of that desktop must start successfully and withstand a basic functionality test", as it's impossible to do basic work in Impress or Draw
18:04:00 <cmurf> so it happens on X but not on wayland?
18:04:03 <cmurf> or both?
18:04:10 <adamw> both.
18:04:11 <adamw> #topic (1372300) GDM does not use the keyboard layout which is selected
18:04:11 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1372300
18:04:11 <adamw> #info Proposed Blocker, mutter, NEW
18:04:13 <cmurf> ok
18:05:01 <kparal> this original reporter said my workaround didn't work for him. but I wasn't able to understand what exactly he did differently
18:05:09 <kparal> either way, I found a bug :)
18:05:37 <kparal> it seems that the default keymap in GDM is different than what is displayed by default in the picker
18:06:03 <adamw> mmf
18:06:25 <adamw> kparal: well, not exactly 'default', right? you only see a bug after you start fiddling around in the settings
18:06:34 <adamw> out of the 'box' (i.e. after install) everything is consistent?
18:06:51 <adamw> i find it hard to decide where to draw lines here
18:06:55 <kparal> I'm not sure
18:07:00 <adamw> since there's so many damn problems in keyboard handling
18:07:25 <adamw> kparal: we do have an openqa test for it which should catch if things don't line up on a straight-through russian install
18:07:28 <kparal> but I see what you mean
18:07:34 <adamw> it uses a user password with both russian and ascii characters
18:07:45 <kparal> I can try again without changing locale in gnome
18:07:50 <kparal> just default install
18:07:53 * adamw checks it
18:08:01 <adamw> https://openqa.fedoraproject.org/tests/33863
18:08:15 <adamw> oh, hah. that's right...it doesn't do a graphical login after install
18:08:16 <adamw> only console
18:08:21 * adamw can't remember why it's set up that way
18:08:58 <adamw> oh right, it uses minimal software selection. hmm. guess i should tweak it
18:10:00 <kparal> let's punt and I'll provide more details
18:11:03 <tenk> Sorry 3 am Tuesday here, i fall asleep and can't follow anymore as good as i want. I will read the minutes tomorrow. Have a good end of meeting.
18:11:27 <adamw> tenk: thanks for sticking around!
18:11:35 <adamw> sorry for the meeting times :(
18:11:40 <adamw> it's hard to find times that work for everyone
18:12:19 <adamw> proposed #agreed 1372300 - punt (delay decision) - it's not entirely clear if this is a problem after a default Russian install or only after tweaking the keyboard layout order post-install; we will wait for kparal to test further and report
18:12:42 <kparal> ack
18:12:48 <coremodule> ack
18:12:56 <pschindl> ack
18:13:06 <adamw> #agreed 1372300 - punt (delay decision) - it's not entirely clear if this is a problem after a default Russian install or only after tweaking the keyboard layout order post-install; we will wait for kparal to test further and report
18:16:02 <adamw> https://phab.qadevel.cloud.fedoraproject.org/T842
18:16:02 <adamw> :P
18:16:20 <adamw> #topic (1374600) Can't change display's resolution on Gnome Wayland
18:16:20 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1374600
18:16:20 <adamw> #info Proposed Blocker, mutter, ASSIGNED
18:17:06 <cmurf> hmmm
18:17:27 <adamw> hum, not sure if this is general or a single-system issue
18:17:34 <adamw> kparal, can you check if this affects you?
18:17:40 <kparal> pushed today
18:17:51 <kparal> adamw: yes
18:18:00 <kparal> I see only a single resolution on laptop display
18:18:31 <cmurf> i have an external, but this host is F24 on Wayland and resolution switching works
18:19:09 <kparal> IIUIC, modern laptop displays only claim they support their native resolution, and there was a "hack" in X to add common modes to the picker
18:19:23 <kparal> so that's what's missing in wayland
18:19:31 <adamw> hmm, so i guess the question is whether that's 'basic functionality'
18:19:36 <cmurf> no
18:19:37 <adamw> seems a bit tricky
18:19:54 <adamw> i know a lot of people do use a non-native resolution because the native makes some things too small for them to use...
18:20:08 <adamw> it's kinda 'doing it wrong' but we shouldn't really be too prescriptive about things
18:20:09 <kparal> font scaling is quite good in gnome
18:20:14 <kparal> if you know where to find it
18:20:22 <cmurf> i suppose it could be an argument for accessibility
18:20:40 <kparal> I wouldn't probably block on this
18:20:49 <kparal> I'll add it to common bugs
18:21:03 <adamw> kparal: it doesn't help with non-text things though (like the eclipse UI which was cited in the last discussion i had about this...)
18:21:56 * kparal shrugs
18:22:13 <kparal> accessibility is broken in wayland anyway, no?
18:22:29 <fmuellner> that sounds like https://bugzilla.gnome.org/show_bug.cgi?id=744544 which just landed, so it'll be in today's 3.21.92 releas
18:23:06 <kparal> we won't block on games not working in wayland, seems to me we should not block on this. same recommendation - for special use cases please use X11
18:23:33 <adamw> yeah, seems reasonable
18:23:36 <adamw> i'm -1
18:23:52 <kparal> -1
18:24:03 <kparal> fmuellner: thanks for info
18:24:19 <coremodule> Font scaling *does* work well, better than lowering the resolution. I'm -1.
18:25:58 <cmurf> -1
18:26:30 <pschindl> -1
18:27:41 <adamw> proposed #agreed 1374600 - RejectedBlocker - the issue here is that there was an X11 workaround to make non-native resolutions available on laptop displays; this isn't really 'basic functionality' for the resolution switching applet, which is doing all it's supposed to do, and so this is rejected as a blocker.
18:27:59 <cmurf> ack
18:28:00 <kparal> ack
18:28:35 <coremodule> ack
18:28:37 <pschindl> ack
18:29:01 <adamw> #agreed 1374600 - RejectedBlocker - the issue here is that there was an X11 workaround to make non-native resolutions available on laptop displays; this isn't really 'basic functionality' for the resolution switching applet, which is doing all it's supposed to do, and so this is rejected as a blocker.
18:29:16 <adamw> #topic (1370459) SELinux is preventing udisksd from 'read' accesses on the blk_file sr0.
18:29:17 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1370459
18:29:17 <adamw> #info Proposed Blocker, selinux-policy, NEW
18:29:24 <adamw> this is the one you mentioned earlier, i guess, kparal?
18:29:28 <kparal> yes
18:29:36 <adamw> given that a lot of systems do still have optical drives, i'll go for +1.
18:29:38 <kparal> dvd drive blocking gnome-disks
18:29:47 <kparal> and also causing other issues
18:29:55 <adamw> maybe in about three years i'd buy the excuse that no-one has an optical drive any more, god. :P
18:30:19 <kparal> comment 12 says it breaks automount
18:30:34 <kparal> which is probably true, Pavel had issues with automount as well
18:31:02 <kparal> +1
18:31:50 <coremodule> +1
18:32:20 <cmurf> maybe it breaks dvd automount but it's not breaking e.g. usb stick automount, that i've tried
18:32:34 <kparal> cmurf: it prevented us from mounting sticks
18:32:40 <kparal> at least it seemed to
18:32:47 <kparal> will try again tomorrow
18:33:14 <cmurf> yeah need to see logs, what did udisksd try to mount and what was the avc
18:33:43 <adamw> cmurf: did the system you tested on have an optical drive?
18:33:54 <cmurf> yes but there's nothing in the drive
18:34:13 <kparal> I think we also didn't have anything in it
18:35:04 <cmurf> I tested 20160909.n.0 without any updates
18:35:38 <cmurf> anyway I'm +1 to this bug, selinux needs to allow udisksd to use sr0 obviously
18:35:46 <pschindl> +1
18:36:43 <adamw> proposed #agreed 1370459 - AcceptedBlocker (Final) - this violates "All applications that can be launched using the standard graphical mechanism of a release-blocking desktop after a default installation of that desktop must start successfully and withstand a basic functionality test" in the case of gnome-disks on a system with an optical drive; it may have other consequences too, but that's sufficient for blocker status
18:36:56 <cmurf> ack
18:37:42 <kparal> ack
18:38:02 <coremodule> ack
18:38:14 <adamw> #agreed 1370459 - AcceptedBlocker (Final) - this violates "All applications that can be launched using the standard graphical mechanism of a release-blocking desktop after a default installation of that desktop must start successfully and withstand a basic functionality test" in the case of gnome-disks on a system with an optical drive; it may have other consequences too, but that's sufficient for blocker status
18:38:23 <adamw> #topic (1370136) glibc update corrupts display of a running system
18:38:23 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1370136
18:38:24 <adamw> #info Proposed Blocker, systemd, POST
18:38:37 <adamw> oh hey, it's our old friend
18:38:58 <kparal> so, my colleague said he would comment on this and didn't
18:39:07 <kparal> because of this bug he had to reinstall his system
18:39:23 <kparal> screen went black, he waited a while and force-rebooted
18:39:33 <kparal> had the dnf operation unfinished, whole system broken
18:39:50 <adamw> kparal: in re #c24, various other packages will trigger a daemon re-exec in their scriptlets, i think. probably systemd itself in that case.
18:40:11 <adamw> kparal: pfah, you can fix that. it just takes like four hours with the dnf logs and a large bottle of whisky...
18:40:12 <adamw> :P
18:40:18 <kparal> hehe
18:40:21 * adamw has done it at least three times on this system...
18:40:32 <kparal> also, I've seen different artifacts even on intel graphics, seems to be random-ish
18:40:55 <adamw> http://koji.fedoraproject.org/koji/buildinfo?buildID=796090 claims to have fixed this
18:41:04 <kparal> great
18:41:08 <adamw> i guess that was the update you were installing at the time of #c26?
18:42:06 <kparal> hmm, I was upgrading and downgrading whole system, so I was probably going from the old systemd to the new one and back
18:42:12 <kparal> had to bisect a regression
18:42:27 <adamw> anyhow, i can probably go with +1 final blocker
18:42:37 <kparal> +1 from me
18:42:39 <cmurf> adamw: no it takes btrfs snapshots, 2 seconds, and 20 large bottles of whisky over the previous 2 months to grok btrfs
18:42:44 <cmurf> +1
18:43:17 <cmurf> maybe not all that much whisky or time to learn it though, they're really easy
18:44:53 <cmurf> as often as you guys blow up shit you don't care about anyway, i'm a little baffled you'd hassle with four hour fixes from unfinished dnf updates
18:44:53 <adamw> any other votes?
18:45:03 <adamw> cmurf: i don't blow up my desktop very often at all
18:45:22 <adamw> 03:43:11,047 INFO anaconda: /usr/sbin/anaconda 15.31
18:45:26 <cmurf> i don't blow it up ever, rollbacks
18:45:30 <adamw> so...not for four and a half years, at least.
18:45:33 <coremodule> That's a lot of whiskey.
18:45:39 <coremodule> +1 blocker.
18:46:06 <adamw> hum, what criteria are we going with?
18:46:10 * adamw plays criterion bingo
18:46:23 <kparal> update has to work
18:47:53 <cmurf> yeah i don't know how you have gui guarantees with updates that could yank out all sorts of things from a running system
18:48:08 <adamw> proposed #agreed 1370136 - AcceptedBlocker (Final) - this can be considered a conditional violation of Alpha criterion "The installed system must be able to download and install updates with the default console package manager" and also Final "All known bugs that can cause corruption of user data must be fixed or documented at Common F25 bugs", as it can cause the user to reboot before the update process completes, breaking the system and riskin
18:48:08 <adamw> g data loss
18:48:10 <adamw> grr
18:48:18 <adamw> proposed #agreed 1370136 - AcceptedBlocker (Final) - this can be considered a conditional violation of Alpha criterion "The installed system must be able to download and install updates with the default console package manager" and also Final "All known bugs that can cause corruption of user data must be fixed or documented at Common F25 bugs", as it can cause the user to reboot before the update completes, breaking the system and risking data l
18:48:18 <adamw> oss
18:48:27 <adamw> that'll work when we lose the 'proposed'
18:48:36 <cmurf> ack
18:48:46 <coremodule> ack
18:48:55 <kparal> ack
18:49:10 <adamw> #agreed 1370136 - AcceptedBlocker (Final) - this can be considered a conditional violation of Alpha criterion "The installed system must be able to download and install updates with the default console package manager" and also Final "All known bugs that can cause corruption of user data must be fixed or documented at Common F25 bugs", as it can cause the user to reboot before the update completes, breaking the system and risking data loss
18:49:27 <adamw> #topic (1374371) systemctl set-default doesn't work at all
18:49:27 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1374371
18:49:27 <adamw> #info Proposed Blocker, systemd, POST
18:49:40 <adamw> eh, i'm pretty -1 on this.
18:50:05 <adamw> it doesn't violate any existing criterion and really doesn't feel significant enough to merit a new one.
18:50:06 <kparal> isn't this an issue with cloud/server/etc?
18:50:13 <adamw> all 'set-default' does is update a symlink
18:50:23 <adamw> it's just a little convenience thing really
18:50:30 <adamw> and they all have appropriate defaults anyway
18:50:50 <adamw> the case you'd be most likely to use it, i guess, is if you do a minimal install then add a desktop
18:50:57 <adamw> but it's trivial to just update the symlink directly instead
18:51:26 <cmurf> it's getting fixed
18:51:41 <cmurf> might even make it into beta
18:51:47 <cmurf> i'd be +1 FE if it doesn't
18:52:11 <cmurf> if it doesn't ^by freeze
18:53:16 <adamw> eh, i dunno if a freeze exception makes much sense
18:53:21 <adamw> why would it need to be fixed on images?
18:53:32 <adamw> especially the calculus of taking a systemd update through a freeze just to fix this
18:53:42 * adamw is -1 alla round
18:53:53 <kparal> I might verify whether vnc installation sets the correct target
18:54:06 <kparal> it's supposed to set multi-user instead of graphical I believe
18:54:12 <kparal> not vnc, text installation
18:54:27 <kparal> anyway, probably also -1 at this moment
18:54:50 <kparal> even though it feels like critical system functionality :)
18:56:03 <coremodule> -1
18:56:25 <cmurf> -1
18:57:08 <adamw> proposed #agreed 1374371 - RejectedBlocker (Final) - this doesn't violate any existing criterion and we didn't see any need to add a new one; it's really just a small convenience tool that updates the target of a symlink, which you can easily do manually instead, and the functionality is not that commonly used in any case
18:57:16 <cmurf> ackministan
18:57:21 <pschindl> ack
18:57:26 <adamw> ooh, you've been saving that one up, haven't you
18:57:29 <coremodule> ack
18:57:29 <kparal> ack
18:57:56 <cmurf> adawm haha what?
18:59:03 <adamw> ackministan
18:59:06 <adamw> #agreed 1374371 - RejectedBlocker (Final) - this doesn't violate any existing criterion and we didn't see any need to add a new one; it's really just a small convenience tool that updates the target of a symlink, which you can easily do manually instead, and the functionality is not that commonly used in any case
18:59:19 <adamw> hold onto your pants, ladies and gentlemen, it's the LAST ONE
18:59:20 <adamw> #topic (1266484) spice + fedora wayland VM + spice-vdagent + resize-guest == flickering display
18:59:20 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1266484
18:59:20 <adamw> #info Proposed Blocker, xorg-x11-drv-qxl, NEW
18:59:35 <cmurf> OMFG the last one
19:00:29 <cmurf> another qxl bug huh
19:00:42 <cmurf> this is set to Fedora 23
19:00:47 <adamw> so...executive summary, if a VM created in Boxes uses Wayland it don't work good?
19:01:31 * adamw is kinda convinced by the arguments in #c39 and #c40
19:01:57 <adamw> especially given the cynical motivation of the criterion, which is basically "we know journalists review distros by clicking on apps at random and typing a bit, so we want to make sure that works"
19:02:11 <cmurf> +1
19:02:30 <adamw> if journos happen to run Boxes and play with it a bit they're going to hit this and be like 'haha wayland whut'
19:02:45 <cmurf> haha
19:03:31 <kparal> I guess I could try booting a Live image
19:04:13 <sgallagh> I'm not sure this would survive the "last blocker" test.
19:04:32 <adamw> hmm, it'd be close.
19:05:41 <kparal> why is it so common to see Gtk-Critical messages in console?
19:05:42 <kparal> sigh
19:05:48 <kparal> anyway, Live doesn't flicker for me
19:05:58 <kparal> I can try installed system tomorrow
19:06:08 <kparal> also, it resizes correctly
19:06:12 <cmurf> sounds like they'd use the virtio video for Boxes to work around it before it'd actual block though
19:07:27 <cmurf> oh no they wouldn't, that's the last comment
19:08:45 <kparal> we're over time
19:09:32 <cmurf> this is a wayland guest os on a wayland host os bug?
19:09:40 <cmurf> if either use X it doesn't happen?
19:09:43 <kparal> I'm running wayland on wayland on f25
19:09:49 <kparal> and don't see it with Live
19:09:55 <adamw> maybe we should punt a bit?
19:09:58 <cmurf> punt
19:10:01 <cmurf> +1
19:10:02 <kparal> I guess
19:10:45 <adamw> proposed #agreed 1266484 - punt (delay decision) - we're not entirely clear on the circumstances in which this bug happens or the difficulty of the workaround(s); kparal tested live in the meeting and did not see the bug in an F25-on-F25, Wayland-on-Wayland test. will ask for more info in bug
19:11:34 <cmurf> it's a messy bug report
19:11:50 <kparal> ack
19:12:34 <cmurf> ack
19:13:08 <adamw> #agreed 1266484 - punt (delay decision) - we're not entirely clear on the circumstances in which this bug happens or the difficulty of the workaround(s); kparal tested live in the meeting and did not see the bug in an F25-on-F25, Wayland-on-Wayland test. will ask for more info in bug
19:13:18 <adamw> alrighty, i think everyone's lost the will to live now, so our work here is done
19:13:26 <adamw> #info we're over time, so skipping the accepted blockers
19:13:30 <adamw> #topic Open floor
19:13:48 <adamw> any other business before we all go for a new bottle of whisky?
19:13:58 <cmurf> did we really just do 3 hours of blocker review?
19:14:14 <adamw> i dunno, i did about 30 minutes of blocker review and 2.5 hours of reading dumb websites
19:14:29 * kparal played with openstreetmap
19:15:34 <cmurf> question, when selinux troubleshooter produces a notification in gnome, but lists 3 items, how to figure out which one is a final blocker?
19:15:44 <cmurf> all three? i have no idea which one is producing the notification
19:15:53 * kparal has to go, thanks everyone, see you
19:16:05 <cmurf> bye kparal
19:16:08 <kparal> cmurf: I'd propose all of them
19:16:14 <cmurf> kthx
19:17:04 <adamw> cmurf: yeah, propose 'em all
19:17:11 <adamw> let god sort 'em out
19:17:41 <cmurf> ack
19:18:59 <coremodule> lol
19:19:20 <adamw> alrighty, thanks for coming everyone
19:19:27 * adamw sets fuse and prepares to get the hell out
19:19:41 <coremodule> Thanks for hosting adamw.
19:19:45 <dgilmore> adamw: see my updates to the initial-setup bug
19:22:20 <adamw> dgilmore: yeah, we accepted it already
19:22:22 <adamw> #endmeeting