16:00:10 <adamw> #startmeeting F24-blocker-review
16:00:10 <zodbot> Meeting started Tue Mar 29 16:00:10 2016 UTC.  The chair is adamw. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:00:10 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:00:10 <zodbot> The meeting name has been set to 'f24-blocker-review'
16:00:10 <adamw> #meetingname F24-blocker-review
16:00:10 <zodbot> The meeting name has been set to 'f24-blocker-review'
16:00:10 <adamw> #topic Roll Call
16:00:18 <adamw> ahoyhoy folks, who's around for some fun blocker review
16:00:25 * garretraziel is here
16:00:27 * satellit_e listening
16:00:38 <lupinix> .hello lupinix
16:00:41 <zodbot> lupinix: lupinix 'Christian Dersch' <lupinix@mailbox.org>
16:00:53 <danofsatx> .hello dmossor
16:00:54 <zodbot> danofsatx: dmossor 'Dan Mossor' <danofsatx@gmail.com>
16:00:57 <adamw> #chair garretraziel danofsatx
16:00:57 <zodbot> Current chairs: adamw danofsatx garretraziel
16:01:04 * lbrabec is lurking
16:02:22 * kparal is here
16:03:09 <adamw> thanks for showing up, folks
16:03:10 <adamw> #topic Introduction
16:03:10 <adamw> Why are we here?
16:03:10 <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:03:11 <adamw> #info We'll be following the process outlined at:
16:03:11 <adamw> #link https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting
16:03:13 <adamw> #info The bugs up for review today are available at:
16:03:15 <adamw> #link http://qa.fedoraproject.org/blockerbugs/current
16:03:17 <adamw> #info The criteria for release blocking bugs can be found at:
16:03:21 <adamw> #link https://fedoraproject.org/wiki/Fedora_24_Alpha_Release_Criteria
16:03:23 <adamw> #link https://fedoraproject.org/wiki/Fedora_24_Beta_Release_Criteria
16:03:25 <adamw> #link https://fedoraproject.org/wiki/Fedora_24_Final_Release_Criteria
16:03:27 <adamw> who wants to be the secretary?
16:03:41 <adamw> this is like "who wants to be a millionaire" only there are no questions and no prize money
16:04:09 * danofsatx can't, leaving for school in 1 hour
16:04:30 <kparal> garretraziel: lbrabec: wanna try?
16:04:40 <kparal> don't be shy!
16:04:52 <adamw> it's so much fun!
16:04:54 <adamw> wait...no it isn't.
16:05:09 <garretraziel> I've never done it, I'm not sure what should I do as a secretary
16:05:21 <garretraziel> and now it definitely isn't the time to learn it :-)
16:05:33 <kparal> you would think
16:05:33 <lbrabec> i'll probably leave earlier... so nah, but thanks
16:05:57 * kparal will do it
16:06:23 <kparal> garretraziel: lbrabec: I'll give you a crash course next time before the meeting, "just in case" :)
16:06:39 <adamw> #info kparal to secretarialize, thanks kparal
16:06:48 <garretraziel> sound like fun
16:06:50 * pwhalen is here
16:06:55 <garretraziel> wait, no it doesn't
16:06:56 <adamw> so, starting with beta proposed blockers
16:06:58 <adamw> =)
16:07:07 <adamw> #topic (1315494) C.UTF-8 doesn't actually work as a default locale
16:07:07 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1315494
16:07:07 <adamw> #info Proposed Blocker, anaconda, MODIFIED
16:07:11 <adamw> this old friend's back!
16:07:33 <adamw> i think it's reasonable to accept it as a beta blocker on the basis we're unlikely to make it to beta without another anaconda build. rawhide testing indicates the fix is working.
16:07:38 <adamw> +1
16:08:44 <kparal> +1
16:09:00 <garretraziel> +1
16:09:13 <RaphGro> +1
16:09:20 <RaphGro> .hello raphgro
16:09:24 <zodbot> RaphGro: raphgro 'Raphael Groner' <projects.rg@smart.ms>
16:09:39 <danofsatx> +1
16:10:05 <pwhalen> +1
16:10:10 <adamw> proposed #agreed 1315494 - AcceptedBlocker (Beta) - this clearly violates the criteria (installer fails to run at all) and it's unlikely we can make the Beta release with the same anaconda build we used for Alpha (which did not suffer from the bug)
16:10:41 <pwhalen> ack
16:10:47 <RaphGro> ack
16:10:49 <danofsatx> ack
16:10:49 <kparal> ack
16:10:50 <lbrabec> ack
16:10:57 <garretraziel> ack
16:11:54 <adamw> #agreed 1315494 - AcceptedBlocker (Beta) - this clearly violates the criteria (installer fails to run at all) and it's unlikely we can make the Beta release with the same anaconda build we used for Alpha (which did not suffer from the bug)
16:12:01 <adamw> #topic (1318067) [anaconda] non-bootable system after fresh install of current F24 on bare metal
16:12:01 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1318067
16:12:01 <adamw> #info Proposed Blocker, grub2, NEW
16:12:11 <adamw> basically it seems like recent grub2 builds don't work on some systems
16:12:23 <adamw> we could probably do with some more info here but it certainly looks worrying, it's an obvious conditional blocker case
16:12:33 <adamw> i pinged pjones about it this morning but no reply yet
16:12:42 <RaphGro> what about the downgrade workaround?
16:13:38 <adamw> well, i mean, yeah, you can do that.
16:13:50 <danofsatx> +1 blocker
16:13:56 <adamw> it involves finding an f23 rescue image, booting that, and knowing how to do a grub2-install without nuking your hard disk. or some other hard disk.
16:14:18 <adamw> or knowing to switch to a console after install has completed and having some old grub2 bits handy on a USB stick or something and, again, knowing how to use them without blowing anything up.
16:14:20 <adamw> it's not a great workaround.
16:14:47 <adamw> i'd probably like to take a week to see if we can nail down any more details on this one, personally
16:14:47 <kparal> as long as the hardware affected is reasonably limited, I think Final blocker would be more appropriate
16:14:50 <RaphGro> with good documentation maybe
16:14:59 <RaphGro> hard to say
16:15:12 <RaphGro> +1 final
16:16:34 <garretraziel> it's +1 final for me - it looks like only limited set of HW is affected
16:16:48 <lbrabec> yep, +1 final
16:16:54 <adamw> well, we have two thinkpads already, thinkpads being affected is usually bad news'
16:17:19 <adamw> we can accept for blocker and punt for beta, i guess...
16:17:34 <pwhalen> +1 blocker for beta
16:17:42 <kparal> just punt would be ok now
16:17:58 <kparal> let's wait until pjones can look at it or we gather more feedback from users
16:18:45 <RaphGro> I'll get a thinkpad soonish, so I could test also on bare metal.
16:19:23 <adamw> proposed #agreed 1318067 - punt (delay decision) - we're generally inclined to take this as a Beta or Final blocker, but we'd like to try and gather some more precise data to be sure how wide the impact is first
16:19:36 <kparal> ack
16:19:38 <lbrabec> ack
16:19:41 <pwhalen> ack
16:19:42 <RaphGro> ack
16:19:42 <garretraziel> ack
16:20:10 <adamw> #agreed 1318067 - punt (delay decision) - we're generally inclined to take this as a Beta or Final blocker, but we'd like to try and gather some more precise data to be sure how wide the impact is first
16:20:15 <adamw> #topic (1321330) on i.mx6 systems the console does not start correctly
16:20:15 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1321330
16:20:16 <adamw> #info Proposed Blocker, kernel, NEW
16:20:25 <adamw> i'm +1 to this, it affects some of our supported ARM platforms.
16:20:28 <dgilmore> +1 blocker since I filed it
16:20:50 <RaphGro> what's i.mx6 system?
16:20:52 <pwhalen> +1
16:21:10 <dgilmore> RaphGro: one of teh most popular arm soc'ß
16:21:14 <dgilmore> soc's
16:21:23 <RaphGro> ok, I'm out of that
16:21:34 <RaphGro> +-0
16:21:54 <garretraziel> +1
16:22:05 <dgilmore> RaphGro: care to share why you voted that way?
16:22:18 <RaphGro> no idea about arm
16:22:19 <adamw> i think he just means he doesn't know about it
16:22:27 <RaphGro> yes
16:22:32 <lbrabec> +1
16:22:33 <kparal> does this affect just a single board or more?
16:22:40 <RaphGro> neutral vote from me for this bug
16:22:53 <dgilmore> kparal: everything with a i.MX6 I have tested
16:22:55 * kparal never heard of i.mx6
16:22:59 <adamw> RaphGro: you don't really need to, though: just read https://fedoraproject.org/wiki/Fedora_24_Alpha_Release_Criteria , click "Supported ARM platforms' under "Release-blocking images must boot"
16:23:04 <danofsatx> based on my analysis of the people who know WFT they're talking about said, I'm +1
16:23:08 <dgilmore> kparal: wandboard and cubox-i are what I tested
16:23:17 <adamw> it links to https://fedoraproject.org/wiki/Architectures/ARM/Supported_Platforms , and that lists systems affected by this bug
16:23:18 <kparal> those I heard of :)
16:23:38 <dgilmore> kparal: i.MX6 is teh soc they use
16:23:39 <adamw> (though that page could do with a bit of a refresh :>)
16:23:48 <kparal> ok, seems real world impact, +1. but in fact I think it's the same level of conditional blocker as the grub2 bug
16:23:57 <adamw> kparal: for ARM the situation is a bit different
16:24:09 <adamw> kparal: we can't realistically list *every x86 system we support*, but for ARM we actually can
16:24:39 <adamw> the ARM devices that we explicitly expect to have working are listed, and the rule is basically it's a blocker if one of those is broken. since the set of systems is quite small we don't really need to use the 'conditional blocker' evaluation process.
16:25:44 <adamw> proposed #agreed 1321330 - AcceptedBlocker (Beta) - violates Alpha criterion "All release-blocking images must boot in their supported configurations" on several supported ARM platforms (see "Supported ARM platforms" footnote)
16:25:45 <kparal> https://fedoraproject.org/wiki/Architectures/ARM/Supported_Platforms lists only Fedora 21 and older :)
16:25:52 <adamw> kparal: yeah, it's still pretty much valid though
16:26:02 <adamw> as i just wrote, "that page could do with a bit of a refresh"
16:26:19 <kparal> in that case the BananaPi bug should have been blocker as well. and was accepted just as a FE
16:26:27 <pwhalen> the list is pretty long for arm now
16:26:35 <adamw> which one was that?
16:26:36 <pwhalen> my understanding is that is was highbank+1 other
16:26:43 <pwhalen> list of supported hw
16:26:47 <kparal> adamw: nevermind, just thinking aloud. that was in Alpha
16:26:52 <kparal> ack
16:27:19 <adamw> welp, anyhow...we can revise later. but we really don't want to ship with i.MX6 broken.
16:27:53 <kparal> lbrabec: remember that URL and we can use it the next time our bananapi doesn't work
16:28:13 <lbrabec> well, we shouldn't block on one board
16:28:26 <lbrabec> but this seems to be affecting more boards
16:29:04 <kparal> lbrabec: adamw just said we would
16:29:24 <jkurik> hi blocker reviewers
16:29:26 <adamw> that's been the rule so far, anyhow
16:29:28 <adamw> hi jkurik
16:29:32 <kparal> vote, people, vote
16:29:38 <adamw> any other acks/nacks/patches?
16:29:53 <lbrabec> yea, i would expect that too, but "We don't block a release on individual devices" are words of pbrobinson
16:30:05 <dgilmore> ack
16:30:21 <jkurik> btw: who is proposing/approving what ARM boards&devices we are supporting ?
16:30:30 <garretraziel> ack
16:30:32 <pwhalen> ack
16:30:41 <lbrabec> ack
16:30:49 <danofsatx> ack
16:30:57 * danofsatx missed the proposal
16:31:02 <adamw> jkurik: it's pretty much up to the ARM team so far as I know.
16:31:07 <adamw> #agreed 1321330 - AcceptedBlocker (Beta) - violates Alpha criterion "All release-blocking images must boot in their supported configurations" on several supported ARM platforms (see "Supported ARM platforms" footnote)
16:31:13 <dgilmore> jkurik: as they work upstream we try to support them
16:31:15 <pwhalen> jkurik, we support everything upstream
16:32:03 <jkurik> ok, thanks for the answers
16:32:32 <adamw> so if people wanna take a closer look at the ARM 'supported platform' stuff we can do that on the mailing list or in a QA meeting maybe, but for now let's move along...this bug really ought to be a blocker anyhow, i.MX6 is one of the most important ARM platforms
16:32:34 <adamw> ok, next bug :)
16:32:34 <adamw> #topic (1262556) AttributeError: 'NoneType' object has no attribute 'get_data'
16:32:34 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1262556
16:32:35 <adamw> #info Proposed Blocker, NetworkManager, NEW
16:32:52 <adamw> this seems to be related to wifi discovery in anaconda
16:33:11 * satellit_e only in netinstall?
16:33:23 <adamw> i don't think so, no, but you
16:33:27 <adamw> you're more likely to see it there
16:33:32 <satellit_e> k
16:33:48 <adamw> i suspect it'd also happen on DVD if you went into network settings and tried to activate the wifi.
16:33:59 <adamw> it may not be present in lives because lives defer network configuration to the host desktop.
16:34:04 <danofsatx> I've seen it even in the respun F23 lives
16:34:23 <danofsatx> but yes, I see this often. annoyingly so.
16:34:29 <adamw> satellit and atodorov say they saw it after going to the network settings spoke, but when i tested i actually hit it right on the hub (after accepting the pre-release warning)
16:34:51 <adamw> so it was a complete install blocker for me, unless i plugged in ethernet somehow i guess (affected laptop has no inbuilt ethernet, though, so i'd need USB)
16:34:57 <satellit_e> I had wired connected and tried to do wireless spoke
16:35:48 <danofsatx> it's timing - it happens at a point in time. Doesn't matter which spoke you enter.
16:36:08 <danofsatx> at least, in my case....
16:36:22 <adamw> danofsatx: i suspect it depends whether you also have a wired connection, but that's just a guess.
16:36:44 <kparal> so it seems like a conditional blocker of basically starting the installer
16:37:05 <danofsatx> I was hitting it in VMs with no WiFi.
16:37:19 <kparal> +1 Beta
16:37:35 <adamw> yeah, i'm +1 based on my experience
16:37:42 <satellit_e> +1 Beta
16:37:47 <garretraziel> +1 beta
16:38:15 <pwhalen> +1 beta
16:38:19 <danofsatx> +1
16:40:19 <adamw> proposed #agreed 1262556 - AcceptedBlocker (Beta) - testing indicates that this bug violates "When using a dedicated installer image, the installer must be able to complete an installation using the text, graphical and VNC installation interfaces." (and other 'complete an install' criteria) for at least some affected systems, likely wifi-only installs from netinst / DVD
16:41:23 <garretraziel> ack
16:41:25 <jkurik> ack
16:41:31 <satellit_e> ack
16:41:48 <adamw> #agreed 1262556 - AcceptedBlocker (Beta) - testing indicates that this bug violates "When using a dedicated installer image, the installer must be able to complete an installation using the text, graphical and VNC installation interfaces." (and other 'complete an install' criteria) for at least some affected systems, likely wifi-only installs from netinst / DVD
16:41:59 <adamw> #topic (1320395) No 'favorites' in F24 KDE menu
16:41:59 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1320395
16:41:59 <adamw> #info Proposed Blocker, plasma-desktop, ON_QA
16:42:28 <adamw> could argue this for beta or final, really, depends which panel criterion we want to go with
16:42:39 * satellit_e but you can add them to it
16:43:29 <adamw> ah, interesting, i didn't try that
16:43:32 <adamw> so just the defaults are missing
16:45:31 <adamw> well, don't all rush to vote at once
16:45:34 <danofsatx> meh, I'm iffy on this one
16:46:10 <danofsatx> the claim of "not functioning" isn't entirely accurate, it's easy enough to fix by right clicking and selecting "add to favorites".
16:46:14 * satellit_e are they listed in .ks
16:46:28 <danofsatx> however, being blank is, unsettling.
16:46:32 <adamw> danofsatx: well, i'd say the defaults are part of the intended functionality.
16:46:42 <adamw> having to add your own link to launch a web browser is kind of silly.
16:47:40 <danofsatx> the question, though, is whether it was fixed with plasma-desktop-5.5.5-5.fc24
16:47:47 <adamw> danofsatx: no, that's not the question at all.
16:47:54 <adamw> we're here to decide if it's a blocker, not whether it's fixed...
16:48:15 <danofsatx> I know.
16:48:22 <danofsatx> I don't think it's a blocker. -1
16:48:24 <kparal> you can still launch the apps from the menu, right?
16:48:26 <adamw> if that update had gone stable we could say 'oh, close the bug so we don't need to decide', but the update is still in testing.
16:48:27 * satellit_e FE?
16:48:33 <adamw> kparal: yeah. if you can find them. this is KDE. ;)
16:48:56 <danofsatx> just start typing - apper will find it ;)
16:48:57 <kparal> I know, I met it already
16:49:11 * adamw nearly fell into the swamp and nearly got eaten by a grue on his way to the firefox launcher, but barely made it in the end
16:49:16 <kparal> -1 Beta, I think it's not "entirely non-functional"
16:49:51 <kparal> but maybe we can give it a final blocker with some polish criteria?
16:50:15 <kparal> or other nationality criteria, if you prefer
16:50:15 <adamw> final criterion we could use would be "All elements of the default panel (or equivalent) configuration in all release-blocking desktops must function correctly in typical use. " i guess
16:50:20 * satellit_e have to leave  ...afk
16:50:33 <adamw> beta criterion is "No part of any release-blocking desktop's panel (or equivalent) configuration may crash on startup or be entirely non-functional. "
16:50:37 <adamw> so yeah, i guess it fits better with final...
16:50:41 <danofsatx> final is better. it's functional, just not correctly.
16:51:32 <lbrabec> i'm for final
16:51:44 <garretraziel> -1 beta, +1 final
16:51:47 <kparal> I'm not fully convinced about Final either, can we just give it -1 blocker and leave it be a week?
16:51:47 <jkurik> I am for final as well, makes more sense for me
16:51:58 <kparal> * -1 beta blocker
16:52:03 <pwhalen> -1 beta, +1 final
16:52:04 <adamw> kparal: we can, sure.
16:52:11 * adamw tries to count votes
16:52:18 <danofsatx> -1 beta, +1 final
16:52:24 <kparal> well it seems final it is
16:52:32 <jkurik> -1 beta, +1 final
16:52:40 <kparal> it would be funny if KDE people wanted the bar empty by default :)
16:52:55 <kparal> but I guess that's not the case
16:53:12 * danofsatx thought it was s'posta be that way
16:53:14 <RaphGro> kparal, it's possible in/with xfce, by the way.
16:53:25 * kparal is ok with final
16:53:31 <adamw> proposed #agreed 1320395 - RejectedBlocker (Beta), AcceptedBlocker (Final) - we agreed this isn't really severe enough to constitute "entirely non-functional" (the Beta wording) but does violate the Final criterion "All elements of the default panel (or equivalent) configuration in all release-blocking desktops must function correctly in typical use."
16:53:40 <kparal> ack
16:53:44 <danofsatx> ack
16:53:47 <jkurik> ack
16:53:57 <RaphGro> ack
16:53:58 <garretraziel> ack
16:53:59 <lbrabec> ack
16:54:03 <adamw> #agreed 1320395 - RejectedBlocker (Beta), AcceptedBlocker (Final) - we agreed this isn't really severe enough to constitute "entirely non-functional" (the Beta wording) but does violate the Final criterion "All elements of the default panel (or equivalent) configuration in all release-blocking desktops must function correctly in typical use."
16:54:29 <adamw> OK, moving onto Final blockers
16:54:38 <adamw> #info that's all for Beta, moving onto Final
16:54:43 <adamw> #topic (1320396) [abrt] gnome-software: magazine_chain_pop_head(): gnome-software killed by SIGSEGV
16:54:43 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1320396
16:54:43 <adamw> #info Proposed Blocker, gnome-software, NEW
16:55:35 <adamw> i didn't investigate this one super thoroughly, but it certainly seems like you get a GNOME Software crash after install and first boot of F24 Alpha Workstation, and you don't get an update notification. seemed reasonable to guess they're connected.
16:55:44 <kparal> +1
16:56:08 <danofsatx> +1
16:56:09 <adamw> did others see the same crash in testing?
16:56:25 <danofsatx> I have a hard stop in 5 mins, I'm going to vote in tickets for blockers.
16:57:03 <garretraziel> +1
16:57:10 * kparal hasn't tested this yet
16:57:16 <adamw> danofsatx: thanks
16:57:26 <kparal> pschindl: welcome
16:57:51 <pschindl> hi all.
16:58:12 <pschindl> +1 (what we are talking about?)
16:58:14 <adamw> evening pschindl
16:58:21 <adamw> just figured out how to get on wifi at the bar?
16:58:23 <kparal> pschindl: see #topic
16:58:26 <pwhalen> +1
16:58:51 <jkurik> +1, this seems to be a clear violation of the criterion
16:58:53 <pschindl> still +1 :)
16:59:14 <adamw> proposed #agreed 1320396 - AcceptedBlocker (Final) - this appears to violate "Release-blocking desktops must notify the user of available updates, but must not do so when running as a live image."
16:59:30 <adamw> it'd be good if other folks can double-check this happens to them too, btw
16:59:35 <adamw> always good to have confirmation
16:59:36 <danofsatx> ack
16:59:53 <jkurik> adamw: to answer your question - I have not tested this
16:59:56 <RaphGro> +1
16:59:58 <pschindl> adamw: They gave me the password after fifth beer. I tried to drink fast. I should train more.
17:00:07 <RaphGro> argh, too late
17:00:11 <pschindl> ack
17:00:20 <RaphGro> ack
17:00:26 <pwhalen> ack
17:00:28 <adamw> pschindl: make sure you put that in your compass
17:00:33 <adamw> #agreed 1320396 - AcceptedBlocker (Final) - this appears to violate "Release-blocking desktops must notify the user of available updates, but must not do so when running as a live image."
17:00:42 <adamw> #topic (1320666) Show correct Fedora 24 background in KDE
17:00:43 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1320666
17:00:43 <adamw> #info Proposed Blocker, kde-settings, ASSIGNED
17:00:59 <RaphGro> I'm working on the review :)
17:01:04 <adamw> so for Alpha KDE got hacked to show some upstream background, which is fine per alpha/beta criteria, but for Final we require the *correct* background
17:01:05 <RaphGro> it looks quite trivial so far
17:01:05 <adamw> thus, +1
17:01:10 <RaphGro> +1
17:02:13 <garretraziel> clearly +1
17:02:20 <kparal> +1
17:02:26 <pwhalen> +1
17:02:30 <jkurik> +1
17:02:35 <pschindl> +1
17:03:14 <kparal> did we hire a prophet when creating those criteria? who would have thought...
17:07:13 <RaphGro> re adamw`
17:07:52 <adamw> darn IRC
17:07:56 <kparal> yay
17:08:10 <adamw> I missed all the votes after raphgro's +1
17:08:12 <RaphGro> power failure?
17:08:22 <adamw> no, just lost IRC connection for some mysterious reason./
17:08:27 <RaphGro> [19:01:10] <RaphGro> +1
17:08:28 <RaphGro> [19:02:13] <garretraziel> clearly +1
17:08:28 <RaphGro> [19:02:20] <kparal> +1
17:08:28 <RaphGro> [19:02:26] <pwhalen> +1
17:08:28 <RaphGro> [19:02:30] <jkurik> +1
17:08:28 <RaphGro> [19:02:35] <pschindl> +1
17:08:30 <RaphGro> [19:03:14] <kparal> did we hire a prophet when creating those criteria? who would have thought...
17:08:33 <RaphGro> [19:07:02] * adamw` (~adamw@happyassassin.net) has joined
17:08:34 <adamw> thanks
17:09:15 <adamw> proposed #agreed 1320666 - AcceptedBlocker (Final) - clear violation of "The proposed final Fedora artwork must be included and used as the background on release-blocking desktops."
17:09:24 <jkurik> ack
17:09:27 <pwhalen> ack
17:09:27 <RaphGro> ack
17:09:33 <adamw> #agreed 1320666 - AcceptedBlocker (Final) - clear violation of "The proposed final Fedora artwork must be included and used as the background on release-blocking desktops."
17:09:36 * RaphGro runs f-r tool on the blocking bug
17:09:43 <adamw> #topic (1314637) SELinux is preventing fwupd from 'write' accesses on the directory 0000:00:02.0.
17:09:43 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1314637
17:09:44 <adamw> #info Proposed Blocker, selinux-policy, MODIFIED
17:10:20 <adamw> this seems like it may be hardware dependent?
17:10:50 <adamw> pschindl: what's the affected system?
17:11:31 <kparal> his Thinkpad something
17:11:40 <adamw> hmm, https://bugzilla.redhat.com/show_bug.cgi?id=1300456 has more info
17:11:42 <adamw> and more affected people
17:11:56 <adamw> i'm fine with +1 for this based on 1300456, even if it's hardware dependent, obviously lots of people hit it
17:11:57 <pschindl> It happened on my working laptop
17:12:20 <pschindl> But I think that I haven't seen it for some time. So I'm not sure if it still occures.
17:12:22 <kparal> +1
17:13:01 <jkurik> why this should be hardware dependent?
17:13:10 <pschindl> I saw it during Alpha "RC" testing.
17:13:16 <adamw> jkurik: fwupd is the firmware update thing
17:13:26 <adamw> and "0000:00:02.0" looks like a hardware identifier
17:13:37 <adamw> so i'm figuring it may only happen if you have some particular type of hardware fwupd kicks in for
17:13:41 <jkurik> yes, but the write access is denied by selinux, not by a HW
17:13:56 <adamw> sure, but fwupd may only *try* and do the blocked thing if some supported HW is present
17:14:08 <jkurik> ah, ok
17:14:16 <pschindl> And I probably have seen it on virtual machine too (still on the same hardware).
17:14:20 <adamw> still, it seems enough people run into this that it doesn't really matter
17:14:33 <adamw> pschindl: i don't think i saw it in my VM testing, though some elements of VM config can be based on the host...
17:14:37 <adamw> anyhoo
17:14:39 * adamw counts votes
17:14:47 <jkurik> then I am +1 to block on this
17:14:57 <adamw> ok, that's 3/4
17:15:27 <pschindl> +1 too
17:15:27 <adamw> proposed #agreed 1314637 - AcceptedBlocker (Final) - violates "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." It's not clear whether this is at all hardware-dependent, but even if it is, it's clear many people are hitting it, enough to take it as a blocker
17:15:29 <garretraziel> +1
17:15:41 <jkurik> ack
17:15:42 <garretraziel> ack
17:15:44 <pschindl> ack
17:15:55 <adamw> #agreed 1314637 - AcceptedBlocker (Final) - violates "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." It's not clear whether this is at all hardware-dependent, but even if it is, it's clear many people are hitting it, enough to take it as a blocker
17:18:24 <adamw> oops, sorry, next bug
17:18:34 <adamw> #topic (1316514) SELinux is preventing colord from 'read' accesses on the file /etc/udev/hwdb.bin.
17:18:34 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1316514
17:18:34 <adamw> #info Proposed Blocker, selinux-policy, MODIFIED
17:19:34 <pschindl> +1
17:19:42 <jkurik> +1
17:19:43 <pwhalen> +1
17:20:03 <adamw> proposed #agreed 1316514 - AcceptedBlocker (Final) - clear violation of "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."
17:20:12 <pschindl> ack
17:20:46 <garretraziel> ack
17:21:10 <pwhalen> ack
17:21:42 <kparal> ack
17:22:39 <adamw> #agreed 1316514 - AcceptedBlocker (Final) - clear violation of "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."
17:23:03 <adamw> ok, last one:
17:23:03 <adamw> #topic (1318045) Incorrect keymap when decrypting encrypted partitions
17:23:04 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1318045
17:23:04 <adamw> #info Proposed Blocker, systemd, NEW
17:24:15 <RaphGro> +1
17:24:16 <pschindl> I think that this thing happens also for older releases
17:24:51 <RaphGro> bricks obviously user system
17:24:51 <adamw> we used to have a lot of trouble with this
17:24:55 <adamw> it's been pretty quiet lately
17:24:56 <pschindl> And I can't remember that we blocked due to this in past.
17:25:18 <RaphGro> FE?
17:25:40 <adamw> no, it is clearly a blocker if it's reproducible
17:25:49 <adamw> we explicitly block on this and explicitly have a test case to catch it
17:26:08 <adamw> i'm just surprised it came back, i thought we'd finally squished it for good :/
17:26:23 <adamw> i trust giulio so i'm +1 on this, of course it'd be good to reproduce and investigate more
17:26:44 <kparal2> haven't we waived some languages as "too difficult to fix"?
17:26:58 * kparal2 remembers some asian lang issues
17:27:38 <adamw> kparal: long story short, this is not that.
17:27:41 <pschindl> I'm +1 too. Because it really violates the criterion.
17:27:58 <kparal2> +1
17:28:01 <adamw> there is no technical reason we cannot use the same keymap when entering the encryption passphrase as we used when setting it.
17:28:13 <adamw> (I don't think.)
17:28:23 <pschindl> https://bugzilla.redhat.com/show_bug.cgi?id=681250
17:28:40 <pschindl> That's the bug I remember :)
17:28:47 <adamw> the case we wouldn't be able to 'fix' is if the 'it' console layout is a switchable one that's set to US by default
17:28:50 <adamw> but i don't believe it is
17:29:14 <kparal> right, that's the case with one of the czech layouts
17:29:34 <adamw> right
17:29:38 <adamw> so i don't think this case is that case
17:29:42 <adamw> lemme just have a quick look at the it layout
17:29:54 <adamw> we should probably note this case in the test case instructions i guess
17:30:50 <adamw> no, it doesn't look like the italian layout is a switched one, so i don't think this is a case of 681250. i'm still +1
17:31:29 <kparal> +1
17:31:51 <pwhalen> +1
17:32:02 <jkurik> +1
17:32:13 <garretraziel> +1
17:33:03 <jkurik> I am +1 even I am not sure it is a problem of systemd, however the criterion is broken
17:33:43 <pschindl> +1
17:35:17 <adamw> proposed #agreed 1318045 - AcceptedBlocker (Final) - as described, this is a clear violation of "If a particular keyboard layout has been configured for the system, that keyboard layout must be used: ... When unlocking encrypted storage volumes during boot"
17:35:29 <adamw> i'm adding a footnote about 681250 to the criteria right now, for the record.
17:35:50 <pschindl> ack
17:35:52 <pwhalen> ack
17:36:05 <jkurik> ack
17:36:47 <kparal> ack
17:37:21 <adamw> #agreed 1318045 - AcceptedBlocker (Final) - as described, this is a clear violation of "If a particular keyboard layout has been configured for the system, that keyboard layout must be used: ... When unlocking encrypted storage volumes during boot"
17:37:27 <adamw> OK, that's all the proposed blockers
17:37:49 <adamw> is anyone super keen to go through accepted beta blockers (I don't really see anything we urgently need to discuss) or proposed Beta FEs, or do you all wanna get out of here?
17:38:16 * kparal has quit
17:38:41 <jkurik> ack to get out of here :-)
17:38:52 <jkurik> I need to leave anyway ...
17:39:10 <RaphGro> thanks
17:40:24 <adamw> message received :)
17:40:26 <adamw> thanks for coming folks
17:40:30 <kparal> thanks
17:40:30 * adamw lights the fuse
17:40:40 * kparal goes afk
17:42:21 <adamw> #endmeeting