16:03:53 <roshi> #startmeeting F21-blocker-review
16:03:53 <zodbot> Meeting started Wed Nov 12 16:03:53 2014 UTC.  The chair is roshi. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:03:53 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:03:53 <roshi> #meetingname F21-blocker-review
16:03:53 <zodbot> The meeting name has been set to 'f21-blocker-review'
16:03:53 <roshi> #topic Roll Call
16:03:58 * kparal is here
16:04:03 <roshi> who's around for some blocker review?
16:05:05 * jskladan is here
16:05:17 <kparal> jskladan: do you know whether pschindl should come?
16:05:27 <jskladan> *shrugs*
16:05:49 <roshi> danofsatx: you around?
16:06:01 <roshi> jreznik said he would be here later
16:06:06 <roshi> adam is on vacation
16:06:08 <danofsatx> maybe, who's askin' ;)
16:06:18 * kparal sent him a message
16:06:37 <roshi> tim could be here if we need another person
16:06:53 <roshi> #chair kparal jskladan danofsatx
16:06:54 <zodbot> Current chairs: danofsatx jskladan kparal roshi
16:07:06 <roshi> we've enough to get started though
16:07:17 <roshi> 11 to go through today
16:07:30 <roshi> #topic (1161779) System fails to boot with rootfs on iSCSI - missing kernel parameters
16:07:33 <roshi> #link https://bugzilla.redhat.com/show_bug.cgi?id=1161779
16:07:36 <roshi> #info Proposed Blocker, anaconda, NEW
16:07:44 * roshi skipped the boilerplate, hope no one minds
16:08:30 <kparal> should I invite anaconda folks over?
16:08:58 <roshi> probably
16:09:11 * satellit listening
16:09:12 <roshi> I don't have any iSCSI or any experience with it
16:09:18 <roshi> #chair satellit
16:09:18 <zodbot> Current chairs: danofsatx jskladan kparal roshi satellit
16:09:29 <roshi> seems a clear blocker though, per the criteria
16:09:51 <kparal> and it seems they know where the bug is
16:10:25 <roshi> if I wanted to get particular, it's might be a clearer violation of does it start after install
16:10:36 <roshi> installation finishes, just doesn't start after that
16:11:21 <kparal> no response in #anaconda
16:11:25 <kparal> +1 per criteria
16:11:34 <roshi> +1 as well
16:11:57 <jskladan> ^^
16:12:48 <roshi> proposed #agreed - 1161779 - AcceptedBlocker - This is a clear violation of the Final criteria: "The installer must be able to detect (if possible) and install to supported network-attached storage devices."
16:13:43 <kparal> ack
16:13:57 <jskladan> ack
16:14:04 <roshi> #agreed - 1161779 - AcceptedBlocker - This is a clear violation of the Final criteria: "The installer must be able to detect (if possible) and install to supported network-attached storage devices."
16:14:09 <roshi> #topic (1162215) LV resize does not check filesystem minimum size
16:14:09 <roshi> #link https://bugzilla.redhat.com/show_bug.cgi?id=1162215
16:14:10 <roshi> #info Proposed Blocker, anaconda, ASSIGNED
16:14:22 <kparal> I'll secretarialize
16:14:50 <roshi> thanks
16:15:31 <kparal> for this bug, jskladan found out if affects guided part as well
16:15:48 <kparal> and for plain ext4 partitions as well
16:16:13 <kparal> which should make it a blocker, imho
16:16:36 * kparal will find a better criterion
16:17:00 * roshi reads the comments
16:17:25 <kparal> Any installer mechanism for resizing storage volumes must correctly attempt the requested operation.
16:17:36 <kparal> in this case, it doesn't. it tries to shrink below minimum size
16:18:09 <roshi> attempt doesn't mean accomplish though - I could see it being argued that it does attempt it
16:18:17 <roshi> (in a theoretical sense, at least)
16:18:43 <kparal> it does attempt, but not correctly
16:19:01 <kparal> the important word is 'correctly' here
16:19:38 <kparal> anaconda will happily to shrink 10GB to 1MB partition at the moment
16:19:42 <kparal> *try
16:19:46 <jskladan> IMHO correctly attempt in a clearly incorrect way means throwing an error (or a warning at least)
16:19:54 <roshi> makes sense to me
16:20:05 * roshi was just off in theoretical land
16:20:29 <roshi> so anaconda has the wrong order of steps, or not enough steps to do it correctly
16:20:53 <kparal> resize2fs now requires e2fsck to be run first
16:21:00 <kparal> which anaconda doesn't take into account
16:21:01 <roshi> +1 blocker in any case
16:21:25 <kparal> and it ignores an error from resize2fs and considers it "0", as the minimum filesystem size
16:21:48 <kparal> which was not very defensively programmed in the first place
16:22:00 <kparal> the patch also fixes this
16:22:18 <roshi> votes?
16:22:23 <kparal> +1
16:22:27 <jskladan> +1
16:24:04 <roshi> proposed #agreed - 11662215 - AcceptedBlocker - This bug is a clear violation of the Final criterion: "Any installer mechanism for resizing storage volumes must correctly attempt the requested operation."
16:24:16 <jskladan> ack
16:24:43 <kparal> ack
16:25:02 <kparal> pschindl: welcome
16:25:08 <pschindl> Hi all
16:25:09 <roshi> #agreed - 11662215 - AcceptedBlocker - This bug is a clear violation of the Final criterion: "Any installer mechanism for resizing storage volumes must correctly attempt the requested operation."
16:25:14 <roshi> hey pschindl :)
16:25:19 <roshi> #chair pschindl
16:25:19 <zodbot> Current chairs: danofsatx jskladan kparal pschindl roshi satellit
16:25:59 <roshi> #topic (1158442) Gnome-initial-setup window doesn't fit to visible with small resolution
16:26:02 <roshi> #link https://bugzilla.redhat.com/show_bug.cgi?id=1158442
16:26:05 <roshi> #info Proposed Blocker, gnome-initial-setup, MODIFIED
16:26:11 <pschindl> How many blockers left? :)
16:26:19 <roshi> I'm trying to spin up a live image with the updated package for this one to confirm a fix
16:26:38 <roshi> 8 or 9 pschindl
16:27:39 <pschindl> I talked to Rui and he said that people with hidpi could have problems with this.
16:27:50 <pschindl> if they use scaling
16:28:15 <kparal> roshi: this is fixed for me, 650px screen height
16:28:16 * satellit_e mclasen on #fedora-desktop just discussed fix with scroolbars
16:28:48 <kparal> still, we need to vote, or at least punt
16:28:54 <kparal> it's not stable yet
16:28:55 <roshi> I can't find a criteria for it though
16:29:08 <kparal> I think this is related to creating a user account
16:29:12 <roshi> once we get enough votes to get it into stable it becomes a non-issue
16:30:22 <kparal> so, what do you propose?
16:30:42 <roshi> I say punt and give karma to the update
16:30:54 <roshi> then it just magically goes away :)
16:31:23 <roshi> votes for punt?
16:31:26 <kparal> for the purposes of new TCs, do we need to have it accepted to ask releng to include it in a new TC?
16:31:30 <pschindl> I'm +1 for punt
16:31:40 <pschindl> it could save as some time now :)
16:31:40 <roshi> I think so
16:31:59 <roshi> and I don't know if we have time to get it into TC2
16:32:00 <kparal> I considered asking this to be in TC2, but didn't know if it is ok or not, if it is not accepted
16:32:00 <pschindl> and we have enough time to deal with it later if it goes wrong
16:32:20 <kparal> it might be too late now, but I was thinking about this in the morning
16:32:43 <kparal> +1 punt is ok
16:32:52 <kparal> seems fixed anyway
16:32:59 <kparal> we just need to push it to stable
16:33:01 <roshi> it needs 2 karma to fix
16:33:13 <roshi> if it works for you and someone else it can get the stable karma it needs
16:34:11 <kparal> is has scrollbars, just tried again with 800x600
16:34:15 <kparal> *it
16:34:21 <kparal> ok, let's punt
16:35:22 <roshi> proposed #agreed - 1158442 - Punt - We're going to wait to decide on this pending discussion and testing of an existing fix.
16:35:30 <pschindl> ack
16:35:57 <kparal> pschindl: can you also test and add karma? just create a new account, switch to it, change resolution to 800x600, and relog
16:36:07 <kparal> ack
16:36:18 <pschindl> kparal: ok
16:37:26 <roshi> #agreed - 1158442 - Punt - We're going to wait to decide on this pending discussion and testing of an existing fix.
16:37:41 <roshi> #topic (986731) Dual boot of uefi Windows 7 and Fedora 19 fails to boot Windows
16:37:45 <roshi> #link https://bugzilla.redhat.com/show_bug.cgi?id=986731
16:37:47 <roshi> #info Proposed Blocker, grub2, NEW
16:39:09 <kparal> see last comment
16:39:13 <kparal> I tested this very carefully
16:39:17 <kparal> couldn't find any problem
16:39:49 <kparal> it seems no one tested this with F21, and everybody refers to older releases
16:40:30 <kparal> -1, until somebody can reproduce and attach logs
16:40:46 <kparal> personally I think it's simply fixed in F21
16:40:50 <roshi> makes sense to me
16:40:51 <roshi> -1
16:41:01 * roshi was looking for something referencing f21
16:41:26 <jskladan> accprding to the comment from kparal in bugzilla, -1 blocker from me
16:41:41 <roshi> proposed #agreed - 986731 - RejectedBlocker - This doesn't seem to be reproducible on F21. If it is, please update the bug and reproduce.
16:41:48 <kparal> ack
16:42:21 <jskladan> ack
16:42:24 <roshi> #agreed - 986731 - RejectedBlocker - This doesn't seem to be reproducible on F21. If it is, please update the bug and reproduce.
16:42:27 <roshi> #topic (1103496) Installer interface sometimes freezes for a while (but install continues, and screen eventually unfreezes)
16:42:30 <roshi> #link https://bugzilla.redhat.com/show_bug.cgi?id=1103496
16:42:33 <roshi> #info Proposed Blocker, gtk3, NEW
16:43:05 * satellit_e I have not seen thi lately with bare metal installs
16:43:14 <satellit_e> this*
16:44:19 <kparal> unless this disappears completely, I think this should be a blocker
16:44:29 <roshi> I haven't seen this in my last few installs
16:44:30 <kparal> we've found out that it's not KDE-specific
16:44:38 <roshi> Xfce install and KDE
16:44:41 <roshi> i686
16:44:42 <kparal> yes
16:45:03 <kparal> if we accept this but stop seeing it, we can always drop the status
16:45:14 * satellit_e bare metal? or VM
16:45:33 <kparal> this happens in both
16:45:34 <roshi> baremetal
16:45:38 <satellit_e> k
16:45:41 <roshi> when I installed last
16:45:49 <roshi> to a 2005 macbook pro, at that
16:46:47 * satellit_e I only test bios boot....
16:48:47 <kparal> +1, we need at least make it somehow not happen, if not fixing the root cause. if it is fixed by updating/removing the spinner, so be it
16:49:28 <kparal> if nobody sees it in some time, we'll drop the blocker status
16:49:31 <roshi> feels like an annoyance to me, but I would easily block on the polish criteria for this for final
16:49:37 <roshi> +1 blocker
16:49:58 <jskladan> +1
16:50:21 <kparal> annoyance if you know about it. if you don't... you can easily kill installer or restart pc in the middle of installation
16:50:52 * kparal is thinking we should have a criterion about 'sufficiently high risk of using user data'
16:50:56 <kparal> *losing
16:51:41 <roshi> where is the polish criteria?
16:52:30 <roshi> proposed #agreed - 1103496 - AcceptedBlocker - This bug conditionally violates the Final Objective to "     Provide a polished final release suitable for meeting the needs of our Target Audience"
16:52:34 <roshi> I guess?
16:52:50 * satellit_e is this same bug where the cursor turns to hand over root and user during install?
16:53:03 * kparal looks for something better
16:53:45 <roshi> I don't really see anything better than that (at least in final)
16:54:04 <roshi> I think a generic "polish" criteria might be a good idea to let us block on things like this
16:54:13 <kparal> I think it could be argued that this has a high possibility of causing a data corruption, which is in our criteria
16:54:37 <roshi> but the user would cause that, not the installer itself
16:54:38 <kparal> rather loss than corruption, but that's what we have
16:54:47 <kparal> yes, but due to an installer bug
16:55:00 <kparal> the installer would seem to be hung and not working
16:55:09 <kparal> so let's kill it and start over, right?
16:55:30 <roshi> I can see that
16:55:53 * satellit_e it does warn that nothing will be done to your disk until you hit install
16:56:05 <roshi> though from a long time ago I started giving things that seemed hung an hour or so before killing them - especially if the hdd activity light is blinking
16:56:31 <roshi> but that might just be me having broke a lot of things in the past by being impatient :p
16:56:51 <roshi> I'm fine with a conditional violation of data loss/corruption
16:56:53 <kparal> if it's not giving proper feedback, it's a software bug
16:57:07 <kparal> I don't see anything better
16:57:15 <roshi> me either
16:57:54 <kparal> let's use that
16:58:19 <roshi> that a beta criteria?
16:58:43 <kparal> https://fedoraproject.org/wiki/Fedora_21_Final_Release_Criteria#Data_corruption
17:00:00 <roshi> and documenting on commonbugs isn't enough for this one?
17:01:00 <kparal> If the issue is sufficiently serious, we may consider that documenting it is not sufficient and it must be fixed. This is a subjective determination that will be made at blocker review or Go/No-Go meetings.
17:01:24 <roshi> proposed #agreed - 1103496 - AcceptedBlocker - This is a conditional violation of the Final Data Corruption criterion since it creates the opportunity of data loss to the user (by making them think the install has hung and the user restarts the machine mid-install).
17:01:29 <kparal> I think this will depend on how much we see it in future composes
17:01:37 <roshi> yeah
17:01:57 <jskladan> ack
17:02:08 <kparal> I'll add a note about that
17:02:10 <kparal> ack
17:02:20 <satellit_e> ack
17:02:22 <roshi> #agreed - 1103496 - AcceptedBlocker - This is a conditional violation of the Final Data Corruption criterion since it creates the opportunity of data loss to the user (by making them think the install has hung and the user restarts the machine mid-install).
17:02:37 <roshi> #topic (1144613) [abrt] gnome-tweak-tool: gtk_tree_row_ref_deleted(): python2.7 killed by SIGSEGV
17:02:40 <roshi> #link https://bugzilla.redhat.com/show_bug.cgi?id=1144613
17:02:43 <roshi> #info Proposed Blocker, gtk3, NEW
17:03:26 <roshi> is the tweak tool a default app?
17:03:30 * roshi didn't think it was
17:05:19 <kparal> it's not
17:05:26 <roshi> -1 then
17:06:07 * kparal will check real quick
17:07:01 * satellit_e afk
17:07:12 <kparal> no it's not
17:07:12 <kparal> -1
17:07:33 <jsmith> -1 then
17:08:10 <roshi> proposed #agreed - 1144613 - RejectedBlocker - The GNOME tweak tool is not a default application for the Workstation product, so this is not considered a blocker.
17:08:21 <jskladan> ack
17:09:31 <pschindl_> -1
17:09:34 <pschindl_> ack
17:09:36 <kparal> ack
17:09:38 <pschindl_> sry :)
17:10:09 <roshi> #agreed - 1144613 - RejectedBlocker - The GNOME tweak tool is not a default application for the Workstation product, so this is not considered a blocker.
17:10:18 <roshi> #topic (1147670) keyboard layout chooser switches letters while typing
17:10:21 <roshi> #link https://bugzilla.redhat.com/show_bug.cgi?id=1147670
17:10:24 <roshi> #info Proposed Blocker, gtk3, NEW
17:12:08 <kparal> this is loads of fun. letters are swapped in anaconda
17:12:26 <kparal> quite interestingly, I've seen it only in anaconda, even though anaconda devs suspect gtk bug
17:12:46 <kparal> there were multiple people complaining about this on the test list
17:12:53 <roshi> when selecting language or what?
17:13:11 <kparal> it seems to be a race condition. some people were having difficulties writing the same password in the two boxes
17:13:18 <roshi> didn't happen for me when typing "deu" in the first available input in a VM
17:13:30 <kparal> roshi: I think it happens in every field while some demanding operation runs in the background
17:13:59 <kparal> roshi: try the language box, type something very quickly, delete it, and again. try several times
17:14:10 <kparal> it might depend on the number of CPUs assigned
17:14:27 <roshi> hrm, set fine for me
17:14:40 <kparal> roshi: Live or DVD?
17:14:47 <roshi> Live
17:15:30 <roshi> let me try with one CPU assigned
17:15:31 <kparal> I have to say I can't reproduce it with language selection right now either
17:15:52 <roshi> I'm also trying on the user creation screen
17:16:11 <kparal> I was able to reproduce with the password bug always, but I had to know my machine timing. on bare metal, I had to be really fast. with VM, I must not have been too fast
17:16:45 <kparal> but some people reported they basically can't get past the root password dialog
17:20:20 <kparal> the problem is that we don't know what types of machines are affected and how often
17:20:46 <roshi> yeah
17:20:54 <kparal> the impact is not that great, because all passwords require filling in twice, and there's a very low chance it would swap letters the same way in both fields
17:21:03 <roshi> I haven't had any issues with it
17:21:08 <kparal> and for other fields, you can easily correct it
17:21:27 <roshi> I guess I'm -1/punt for this with more info on what kinds of machines are impacted and whatnot
17:21:33 <jskladan> anybody successfully reproduced the issue? /me tries but no luck so far
17:21:41 <kparal> pschindl_ did
17:22:02 <kparal> but you need to get the timing right, and it's different for every machine :)
17:22:25 <kparal> also it's hard to verify the bug because there is not 'show password' checkbox in anaconda
17:22:34 <kparal> but there's an updates.img which adds it, for these purposes
17:22:39 <pschindl_> yes. I reproduced this few times.
17:23:01 <kparal> both bare metal and VM are affected
17:23:47 <roshi> if it's reproducable, I could be convinced +1 blocker
17:23:55 <jskladan> ^^
17:24:32 <roshi> but again, I'd like to put this under a polish criteria - because it doesn't *break* anything, it's just annoying
17:24:41 * jreznik_x1 is here, sorry for being late
17:24:48 <kparal> if you regularly sacrifice to the god of race conditions, then yes, it is
17:25:21 <kparal> I'm not myself convinced whether this should be a blocker
17:25:51 <kparal> is there any text input in anaconda which is really sensitive to get the right value, except for password fields?
17:25:53 <roshi> me either - though I'd take an FE for it early enough in the process
17:27:13 <kparal> again, some people claimed they are unable to provide two same password values, and they tried multiple times. but I couldn't reproduce that
17:27:23 <kparal> in that case it would be quite serious
17:27:44 <roshi> what if they just type real slow?
17:27:54 <roshi> I mean, I can't make it happen
17:27:57 <kparal> the password field failed for me only on my first attempt. next attempts were fine
17:28:29 <kparal> slow typing would not be a problem, because there is a low likelihood for swapping input events
17:28:58 <kparal> ah, you mean they should try typing slow. yes, that should work
17:29:13 <roshi> yeah, I meant them slowing down how fast they hit keys
17:29:32 <kparal> that can be a hilarious common bugs - type your passwords slow :-D
17:29:47 <roshi> honestly, if it didn't happen *every* time, I'd assume I'd made a typo when typing (which isn't uncommon)
17:30:09 <roshi> lol
17:30:11 <kparal> roshi: that's exactly what I thought, until it happened to me in 80% of installations
17:30:20 <roshi> that's really odd
17:30:22 <kparal> I'm used to fill the forms really fast
17:30:40 <roshi> it gets that way after a while :)
17:30:47 <roshi> so blocker or FE?
17:30:51 * roshi leans FE
17:30:56 <kparal> jskladan: pschindl_: what do you think?
17:31:10 <jskladan> I'm +1 on FE
17:31:19 <roshi> danofsatx: ^^
17:31:26 <roshi> jreznik: ^^
17:31:56 <pschindl_> I'm +1 FE
17:32:27 <pschindl_> I haven't seen serious case enough to block.
17:32:39 <kparal> jskladan: does that mean -1 blocker?
17:33:34 * jsmith is having a hard time deciding, so he'll give it a +0
17:33:37 <roshi> -1/+1 blocker/FE
17:33:44 <jreznik_x1> -1/+1
17:34:46 <kparal> we can re-evaluate if we find someone who's having real troubles to get past those dialogs
17:34:59 <kparal> so -1/+1 sounds fine
17:35:07 <roshi> proposed #agreed - 1147670 - RejectedBlocker AcceptedFreezeException - This bug doesn't seem to be reproducible and there isn't much information on what systems are effected. Accepting as an FE because if you do hit it, it would be pretty obnoxious. Repropose if more solid reproduction steps can be found.
17:35:32 <roshi> proposed #agreed - 1147670 - RejectedBlocker AcceptedFreezeException - This bug doesn't seem to be reproducible and there isn't much information on what systems are affected. Accepting as an FE because if you do hit it, it would be pretty obnoxious. Repropose if more solid reproduction steps can be found.
17:36:10 <kparal> patch
17:36:27 * jreznik_x1 is looking for obnoxious in dictionary
17:36:58 <pschindl_> ack
17:37:23 <roshi> I can change that to "annoying"
17:37:36 <roshi> go for it kparal
17:38:19 <kparal> This bug is difficult to reproduce and it seems to be very system-dependant.  Accepting as an FE because if you do hit it, it would be pretty obnoxious. Repropose if more solid reproduction steps can be found or there is a concrete system on which it is quite difficult to perform Fedora installation.
17:38:42 <kparal> feel free to fix my english :)
17:39:13 <roshi> ack
17:39:32 <kparal> I actually did not use 'proposed'
17:39:38 <kparal> but that's ok
17:39:54 <roshi> proposed #agreed - 1147670 - RejectedBlocker AcceptedFreezeException - This bug is difficult to reproduce and it seems to be very system-dependant.  Accepting as an FE because if you do hit it, it would be pretty obnoxious. Repropose if more solid reproduction steps can be found or there is a concrete system on which it is quite difficult to perform Fedora installation.
17:40:01 <roshi> there
17:40:02 <kparal> ack
17:40:07 <roshi> :)
17:40:23 <roshi> alright with obnoxious jreznik_x1 ?
17:41:06 <kparal> should we recommend anaconda to include 'show password' checkboxes in the installer? that's my pet peeve
17:41:16 <roshi> I dunno
17:41:23 <roshi> never bothered me until this bug
17:41:36 <jreznik_x1> roshi: I'm ok with that word, now I know meaning
17:41:47 <kparal> roshi: that's the happy live of a single keyboard layout
17:41:53 <jreznik_x1> show password is a nice feature very often
17:41:59 <jreznik_x1> kparal: exactly
17:42:00 <roshi> sounds good, just checking - had no problem changing it :)
17:42:15 <roshi> I'm not opposed to it
17:42:16 <kparal> *life
17:42:30 <roshi> but I don't know that the blocker review meeting is the best medium to request a UI change
17:42:36 <roshi> could be wrong though
17:42:42 <kparal> you're probably right
17:42:48 <roshi> i hadn't considered that use case, it's a good point
17:42:49 <kparal> but it's my pet peeve! as I said :)
17:43:04 <roshi> if I was switching langs I would want it, now that I think about it
17:43:07 <kparal> other votes?
17:43:13 <roshi> since I couldn't be sure what input I was using at the time...
17:43:19 <kparal> pschindl_: jskladan: votes?
17:43:23 <roshi> votes or acks?
17:43:31 <kparal> acks
17:43:37 <jreznik_x1> ack
17:43:43 <jskladan> ack
17:43:49 <roshi> #agreed - 1147670 - RejectedBlocker AcceptedFreezeException - This bug is difficult to reproduce and it seems to be very system-dependant.  Accepting as an FE because if you do hit it, it would be pretty obnoxious. Repropose if more solid reproduction steps can be found or there is a concrete system on which it is quite difficult to perform Fedora installation.
17:44:00 <roshi> #topic (1158968) AttributeError: 'DMRaidArrayDevice' object has no attribute 'formatClass'
17:44:03 <roshi> #link https://bugzilla.redhat.com/show_bug.cgi?id=1158968
17:44:05 <roshi> #info Proposed Blocker, python-blivet, MODIFIED
17:46:57 <jreznik_x1> +1 based on comment from dlehman
17:47:31 <pschindl_> +1
17:47:37 <roshi> has anyone been doing raid tests and seen this?
17:47:45 * roshi doesn't have disks for raid
17:47:45 <pschindl_> not me
17:48:40 <kparal> I have done raid tests with Beta
17:49:22 <kparal> +1
17:49:35 <kparal> I haven't seen it myself though
17:49:50 <kparal> but if dlehman proposed, it's probably serious enough
17:49:57 <kparal> *it
17:50:22 <jsmith> +1 from me, based on dlehman's comment
17:50:28 <roshi> works for me
17:51:25 <roshi> under the beta criteria: The installer must be able to detect and install to hardware or firmware RAID storage devices.
17:51:28 <roshi> ?
17:52:52 <roshi> proposed #agreed - 1158968 - AcceptedBlocker - This bug is a violation of the Beta Criterion: "The installer must be able to detect and install to hardware or firmware RAID storage devices."
17:53:40 <pschindl_> ack
17:53:49 <jskladan> ack
17:55:44 <kparal> ack
17:56:05 <jreznik_x1> ack
17:56:13 <roshi> #agreed - 1158968 - AcceptedBlocker - This bug is a violation of the Beta Criterion: "The installer must be able to detect and install to hardware or firmware RAID storage devices."
17:56:21 <roshi> #topic (1130794) Missing high contrast icon
17:56:21 <roshi> #link https://bugzilla.redhat.com/show_bug.cgi?id=1130794
17:56:22 <roshi> #info Proposed Blocker, setroubleshoot, NEW
17:57:28 <roshi> it's a pretty clear blocker of the stated criterion
17:57:31 <roshi> +1
17:57:47 <roshi> also easy to fix (/me tries not to use the S word with this one)
17:58:28 <kparal> technically it should be reported against F21
17:58:51 <jreznik_x1> it's different to anaconda high contrast icon - there's no high contrast icon for selinux
17:59:02 <jreznik_x1> (or maybe I'm blind)
17:59:25 <kparal> jreznik_x1: I'm not following you
17:59:29 <jreznik_x1> so not that easy, we would need to ask design team, but strictly based on criterion +1
17:59:42 <roshi> yeah, change the release to 21 while we're there
17:59:43 <kparal> ah, you mean it hasn't been drawn yet
17:59:53 <kparal> while anaconda has it, just not using it
17:59:57 <jreznik_x1> kparal: yep
18:00:05 <kparal> still, criteria says... +1
18:00:22 <kparal> so, we will need to re-evaluate criteria if this turns out to be a problem
18:00:27 <kparal> same approach as with anaconda
18:00:35 <kparal> +1 here
18:00:43 <roshi> proposed #agreed - 1130794 - AcceptedBlocker - This is a pretty clear violation of the criterion: "All applications installed by default in Fedora Workstation must comply with each MUST and MUST NOT guideline in the Applications and Launchers policy.."
18:00:47 <kparal> I'll switch the bug to F21
18:01:05 <pschindl_> ack
18:01:07 <kparal> ack
18:01:14 <roshi> #agreed - 1130794 - AcceptedBlocker - This is a pretty clear violation of the criterion: "All applications installed by default in Fedora Workstation must comply with each MUST and MUST NOT guideline in the Applications and Launchers policy.."
18:01:19 <roshi> #topic (1162537) No CJK fonts installed on MATE Live
18:01:21 <roshi> #link https://bugzilla.redhat.com/show_bug.cgi?id=1162537
18:01:24 <roshi> #info Proposed Blocker, spin-kickstarts, NEW
18:01:59 <roshi> this isn't a release blocking desktop
18:02:01 <roshi> -1
18:02:31 <pschindl_> -1
18:03:10 <jreznik_x1> -1
18:03:23 <kparal> we can also vote FE
18:03:44 <roshi> looks like they have it fixed already anyways
18:04:01 <roshi> FE would be fine, since it won't affect anything but the MATE spin
18:04:04 <jreznik_x1> would this be blocking desktop blocker -> automatic FE?
18:04:52 <jreznik_x1> probably not, but I'm +1 FE
18:04:59 <roshi> I dunno what languages are blockers
18:05:19 <roshi> another part of only having a single keyboard layout I imagine :p
18:05:40 <kparal> blissful ignorance!
18:05:55 * kparal would love to have it
18:06:06 <kparal> -1, let's go on
18:06:07 <roshi> lol
18:06:35 <roshi> proposed #agreed - 1162537 - RejectedBlocker - MATE is not a release blocking desktop environment.
18:06:43 <kparal> ack
18:06:45 <jreznik_x1> ack
18:06:53 <roshi> #agreed - 1162537 - RejectedBlocker - MATE is not a release blocking desktop environment.
18:06:56 <roshi> #topic (1162068) High Xorg cpu usage during F21 beta install prevents installation
18:06:59 <roshi> #link https://bugzilla.redhat.com/show_bug.cgi?id=1162068
18:07:01 <roshi> #info Proposed Blocker, xorg-x11, NEW
18:07:44 <kparal> oh, somebody actually reported this? cool
18:08:10 <kparal> meh, that's a different bug
18:08:26 <kparal> too bad
18:08:29 <roshi> I haven't seen this one
18:09:10 <kparal> me neither
18:09:25 <pschindl_> I haven't seen this too
18:09:38 <roshi> I think we need more information before we can vote on it, if *none* of us have seen it
18:09:54 <roshi> doesn't seem like he's doing anything out of the oridnary
18:10:00 <roshi> ordinary, even
18:10:15 <kparal> it seems as a graphics driver bug or something
18:10:29 <kparal> I'd say -1 unless more people are affected
18:10:40 <kparal> have you seen anyone else complaining about this?
18:10:42 <roshi> do we want to punt and ask for more info?
18:10:56 <kparal> roshi: from xorg devs?
18:11:08 <kparal> the reporter probably can't add any more info
18:11:11 <roshi> CPU, ram, gfx card, baremetal/vm
18:11:16 <kparal> ah
18:11:17 <pschindl_> I'm -1.
18:11:45 <roshi> that would help us try to find a reproducer
18:11:48 <roshi> was my thought
18:11:55 <kparal> roshi: that's a good idea
18:12:18 <pschindl_> if someone else appears then be it. But if only one person have seen such bad problem then I think it is due to some hw problem
18:12:32 <kparal> I don't mind if we punt this
18:13:01 <pschindl_> We can try to wait for more reproducers. :)
18:13:20 <roshi> proposed #agreed - 1162068 - Punt - We'd like to have more information before deciding on this bug. Could you provide the following information so we can try to reproduce? CPU, RAM, graphics stack, baremetal or VM? Thanks.
18:14:08 <kparal> ack
18:14:12 <pschindl_> ack
18:14:42 <roshi> #agreed - 1162068 - Punt - We'd like to have more information before deciding on this bug. Could you provide the following information so we can try to reproduce? CPU, RAM, graphics stack, baremetal or VM? Thanks.
18:14:56 <roshi> that's it for the proposed blockers
18:15:12 <roshi> two proposed FEs to address, but we're not in freeze
18:15:18 <roshi> I don't think we are anyway
18:15:29 <kparal> all blockers gone, wheeeee
18:17:15 <roshi> so do we want to call it quits or go over FEs?
18:17:42 <jreznik_x1> we're not in freeze, so I don't think it's neccessary
18:18:24 <roshi> me either
18:18:28 <roshi> #topic Open Floor
18:18:40 <roshi> anyone have anything?
18:18:52 <roshi> sgallagh_afk: you got any ninja blockers to propose?
18:18:58 <roshi> sometimes he does :)
18:19:58 * roshi sets the fuse...
18:20:00 * pschindl_ has to leave now. So good night
18:20:16 <roshi> night pschindl_ , thanks for coming! :D
18:21:58 <roshi> 3...
18:22:14 <roshi> 2...
18:24:20 <roshi> 1...
18:24:27 <roshi> thanks for coming everyone!
18:24:33 <roshi> #endmeeting