16:01:30 <adamw> #startmeeting F22-blocker-review
16:01:30 <zodbot> Meeting started Mon May 11 16:01:30 2015 UTC.  The chair is adamw. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:01:30 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:01:31 <adamw> #meetingname F22-blocker-review
16:01:31 <zodbot> The meeting name has been set to 'f22-blocker-review'
16:01:31 <adamw> #topic Roll Call
16:01:33 <adamw> morning folks
16:02:27 <jreznik_> hey adamw
16:02:44 <adamw> who's around for some blocker review?
16:02:53 * tflink can be
16:03:02 * jreznik_ is back after a few days offline - some kind of food poisoning/infection/or whatever and you know what does it mean...
16:03:34 * satellit_e listening but have to leave early
16:04:06 * adamw hopes jreznik didn't bring a slide deck
16:04:12 * danofsatx is heah
16:05:15 <danofsatx> morning folks
16:05:19 <adamw> hi dan
16:05:21 <adamw> anyone else?
16:05:24 <danofsatx> I spammed f-kde and f-server
16:05:33 <adamw> #chair jreznik_ danofsatx
16:05:33 <zodbot> Current chairs: adamw danofsatx jreznik_
16:05:34 <adamw> thanks
16:05:49 * danofsatx goes in search of cloud
16:06:43 <adamw> welp, let's get started, i guess
16:06:48 * pschindl is here
16:06:57 <adamw> #topic Introduction
16:06:57 <adamw> Why are we here?
16:06:57 <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:06:57 <adamw> #info We'll be following the process outlined at:
16:06:58 <adamw> #link https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting
16:06:58 <adamw> #info The bugs up for review today are available at:
16:07:01 <adamw> #link http://qa.fedoraproject.org/blockerbugs/current
16:07:02 <adamw> #info The criteria for release blocking bugs can be found at:
16:07:04 <adamw> #link https://fedoraproject.org/wiki/Fedora_22_Alpha_Release_Criteria
16:07:06 <adamw> #link https://fedoraproject.org/wiki/Fedora_22_Beta_Release_Criteria
16:07:08 <adamw> #link https://fedoraproject.org/wiki/Fedora_22_Final_Release_Criteria
16:07:10 <adamw> hi pschindl
16:07:12 <adamw> #info 11 Proposed Blockers
16:07:14 <adamw> #info 8 Accepted Blockers
16:07:16 <adamw> #info 9 Proposed Freeze Exceptions
16:07:18 <adamw> #info 5 Accepted Freeze Exceptions
16:07:34 <adamw> who wants to secretarialize?
16:08:08 <danofsatx> I'm prepped to do so...even with the "Blocks" bugs already ready to C&P
16:08:08 * tflink can
16:08:21 <tflink> but if dan wants to do it, I'm certainly not going to stop him :)
16:08:40 <danofsatx> the question is...does adam trust me? ;)
16:09:09 * adamw trusts no-one
16:09:15 <adamw> #info danofsatx will secretarialize
16:09:17 <adamw> thanks dan
16:09:23 <danofsatx> good policy
16:09:30 <adamw> #topic (1219264) Intel firmware RAID set does not appear in INSTALLATION DESTINATION in live installer
16:09:30 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1219264
16:09:30 <adamw> #info Proposed Blocker, anaconda, NEW
16:09:31 <danofsatx> trusting no-one, that is
16:09:55 <adamw> so i hit this one while testing something else last week, didn't get time to look into it very deep yet
16:10:05 <danofsatx> +1. I can confirm this one, too.
16:10:09 <adamw> ah, thanks dan
16:10:23 <tflink> +1
16:11:16 <jreznik> +1, it's sad we have found it so late - anyone can confirm if it's in Beta too?
16:11:21 <danofsatx> we thought it was our hardware, but now that I see the bug it makes sense
16:11:42 <adamw> jreznik: didn't check yet, for beta we had enough troubles getting non-live to work
16:12:41 <adamw> proposed #agreed 1219264 - AcceptedBlocker - violates "The installer must be able to detect and install to hardware or firmware RAID storage devices" for live installs
16:12:50 <tflink> ack
16:12:52 <jreznik> ack
16:12:55 <danofsatx> ack
16:14:07 <adamw> #agreed 1219264 - AcceptedBlocker - violates "The installer must be able to detect and install to hardware or firmware RAID storage devices" for live installs
16:14:19 <adamw> #topic (1219430) MDRaidError: No name found for the node 'md126p1'
16:14:20 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1219430
16:14:20 <adamw> #info Proposed Blocker, anaconda, NEW
16:14:28 <adamw> this is the one that shows up...sometimes, iirc
16:14:36 <adamw> oh, different one
16:15:25 <adamw> hum, actually looks like the same
16:15:25 <adamw> https://bugzilla.redhat.com/show_bug.cgi?id=1210057
16:15:33 <adamw> which has now been marked as a dupe of https://bugzilla.redhat.com/show_bug.cgi?id=1160424
16:16:00 <pschindl> It shows me everytime I try to run anaconda on Live with our firmware raid.
16:17:09 <adamw> pschindl: you can try recreating the fwraid array and see if it still happens (but then it might be hard to reproduce again of course)
16:17:47 <adamw> so...on the one hand this doesn't always happen and it was in F21 so it's not a regression from the last stable release, on the other hand people sure do seem to keep running into it. on the gripping hand, dlehman says it's not at all an easy fix
16:17:56 <adamw> (i.e. he doesn't actually know what's going wrong exactly yet)
16:17:58 <pschindl> adamw: I'm not at the office right now, so I can try it tomorrow.
16:18:10 <adamw> lemme see if anne/dlehman are around
16:20:57 <adamw> just waiting for a bit to hear from them in #anaconda
16:21:08 <jreznik> maybe skip this one for now?
16:22:01 <danofsatx> concur
16:22:29 <adamw> i'm a bit worried about declaring it a blocker without dev buy-in, could lead to problems
16:22:38 <adamw> but it sure does seem like people keep running into it :/
16:24:15 <jreznik> I agree not accepting it agains will of devels
16:24:28 <adamw> ok, let's leave it for now and circle back at the end of the list, see if we hear from devs by then
16:24:32 <adamw> #info will circle back to this later
16:24:48 <adamw> #topic (1206960) Various apps crash with an X BadMatch error when run on GNOME with llvmpipe
16:24:49 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1206960
16:24:49 <adamw> #info Proposed Blocker, clutter, VERIFIED
16:25:01 <adamw> this is actually one we accepted previously, but it turned out to be a bit different
16:25:20 <danofsatx> is it indeed fixed in TC3?
16:25:24 <adamw> we had a bug that was 'totem crashes on fresh install' - the reality turns out to be 'several apps crash in GNOME without hardware acceleration'
16:25:27 <adamw> yes, that's why it's VERIFIED.
16:25:34 <danofsatx> oh, duh....
16:25:53 <adamw> i'm +1 on the revised bug - OK it doesn't happen on all systems, but it affects more apps than we thought...
16:25:54 * danofsatx reaches his quota of "One thing learned per day"
16:26:19 <tflink> +1 as well - not good experience for live images on a system using llvmpipe
16:26:31 <jreznik> BZ is still loading...
16:26:54 <jreznik> on how many systems do we expect llvmpipe these days? but yeah, it could be many
16:26:57 * danofsatx loaded all the bugs an hour ago just in case
16:27:24 <jreznik> but +1
16:27:41 <danofsatx> +1
16:27:58 <pschindl> +1
16:28:46 <adamw> jreznik: VMs would be the main case
16:29:00 <adamw> then maybe some systems with very old or very new gfx cards i guess
16:29:49 <jreznik> adamw: ah, you're right, I completely forgot VMs
16:29:58 <adamw> proposed #accepted 1206960 - AcceptedBlocker - 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" if hardware acceleration isn't available
16:30:03 <adamw> er
16:30:08 <adamw> proposed #agreed 1206960 - AcceptedBlocker - 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" if hardware acceleration isn't available
16:30:26 <danofsatx> ack2
16:30:28 <jreznik> ack
16:30:29 <tflink> ack
16:30:43 <pschindl> ack
16:31:47 <adamw> #agreed 1206960 - AcceptedBlocker - 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" if hardware acceleration isn't available
16:31:58 <adamw> #topic (1200302) dnf reinstall breaks alternatives
16:31:59 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1200302
16:31:59 <adamw> #info Proposed Blocker, dnf, NEW
16:32:33 <tflink> this doesn't seem very blockery to me
16:32:49 <tflink> not fun but could be fixed with an update and unlikely to affect live images
16:32:57 <tflink> or the installer, for that matter
16:33:14 <jreznik> yep
16:33:52 <danofsatx> -1
16:34:04 <adamw> it does seem a bit specific
16:34:07 <danofsatx> +/-1 FE. undecided.
16:34:30 <tflink> -1/-1
16:34:39 <jreznik> -1 blocker, for FE it's dnf, so be carefull, more inclined -1
16:34:58 <danofsatx> -1 / -1. decided now.
16:36:03 <adamw> proposed #agreed 1200302 - RejectedBlocker - this bug obviously sucks if you run into it, but doesn't seem especially critical to the release media, doesn't violate any release criteria, and seems unlikely to be hit very often
16:36:21 <danofsatx> ackish
16:36:23 <jreznik> ack
16:36:25 <pschindl> ack
16:36:42 <tflink> ack
16:37:12 <adamw> #agreed 1200302 - RejectedBlocker - this bug obviously sucks if you run into it, but doesn't seem especially critical to the release media, doesn't violate any release criteria, and seems unlikely to be hit very often
16:37:24 <adamw> #topic (1218787) gdm-wayland-session fails to present login screen after successful installation
16:37:24 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1218787
16:37:24 <adamw> #info Proposed Blocker, gdm, NEW
16:37:41 <adamw> this is a bad bug, but seems fairly hardware-specific
16:38:04 <tflink> is wayland release blocking?
16:38:34 <danofsatx> well, if this bug blocks wayland from getting out of the way to present a login screen, then yes it is.
16:39:10 <jreznik> tflink: no but as it's dm...
16:39:35 <adamw> tflink: gdm-on-wayland is because it's the default.
16:39:58 <adamw> basically the bug is 'install Workstation on this hardware and you don't see GDM'.
16:40:46 <jreznik> any dual graphics or just these specific?
16:41:06 <tflink> do we have any idea how widespread the issue is outside of that collection of hw?
16:41:12 <adamw> i'd have expected we'd get more reports if it was all dual graphics systems
16:41:14 <adamw> tflink: no.
16:42:12 <jreznik> if it is in this specific case, I'm -1 - I can try Intel/NVidia combo tomorrow but last time I played with it, it worked (Beta times)
16:42:17 <jreznik> as far as I remember
16:42:27 <adamw> i don't see any other case reported against gdm
16:43:52 <adamw> i'm either -1 or punt, i guess
16:44:05 <tflink> put for a week to see if there are any other reports?
16:44:12 <tflink> s/put/punt
16:44:13 <danofsatx> Macs have other.....issues. I'm tempted to -1 on this one too.
16:44:16 <adamw> well i was more punting for info from debugging
16:44:27 <adamw> sometimes when you find out what the bug actually is you get an idea of how much hardware it'll affect
16:44:47 <jreznik> I can try Intel/NVidia tomorrow on T520
16:45:36 <adamw> sure, i strongly expect it'll work, though.
16:45:42 <adamw> usually when stuff is busted on thinkpads we hear about it
16:45:50 <adamw> can't hurt to check :)
16:46:33 <jreznik> adamw: well, there are not many thinkpads with dual graphics in the wild (and it was worst decision ever to get such one)
16:46:34 <adamw> proposed #agreed 1218787 - punt (delay decision) one week - this is a bad bug but so far known to affect only one system; we're inclined to reject it as too hardware-specific, but will wait to see if any info appears indicating it affects more than this particular laptop/graphics adapter combination
16:46:39 <adamw> jreznik: heh
16:46:43 <jreznik> but I expect it's going to work
16:46:45 <tflink> ack
16:46:51 <danofsatx> ack
16:46:55 <jreznik> ack
16:46:55 <pschindl> ack
16:47:53 <adamw> #agreed 1218787 - punt (delay decision) one week - this is a bad bug but so far known to affect only one system; we're inclined to reject it as too hardware-specific, but will wait to see if any info appears indicating it affects more than this particular laptop/graphics adapter combination
16:48:03 <adamw> #topic (1197940) kde-l10n conflicts
16:48:03 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1197940
16:48:03 <adamw> #info Proposed Blocker, kde-l10n, NEW
16:48:34 <adamw> I am sceptical about "This bug makes it not possible to install KDE-Desktop Environment from netinstall or live-image with german translation / localization"
16:48:34 <danofsatx> +1
16:48:38 <adamw> i don't see how it can affect live images
16:48:58 <danofsatx> hang on, let me grab Kevin for some clarifying info
16:49:57 <adamw> so far as network install is concerned, an update can mostly fix it, the only affected scenario after an update would be an install with updates repo disabled...
16:51:41 <adamw> i can be +1 FE for jam composing issues
16:53:22 <tflink> I don't completely understand why it wouldn't affect live images but I'll take your word for it
16:53:33 <tflink> at least +1 FE for spin compose issues
16:54:23 <pschindl> +1 FE
16:54:34 <danofsatx> if it's just the compose, +1 FE. If it prevents German (or other language) netinstall of Plasma, +1 blocker
16:54:59 <adamw> tflink: live images don't do anything with packages at install time.
16:55:09 <adamw> tflink: if a conflict affects a live image, it doesn't compose.
16:55:22 <adamw> the fact that KDE live images compose demonstrates quite strongly that this bug doesn't affect them. :)
16:55:42 <tflink> oh, I was just thinking i10n issues - not the root compose bug :-/
16:56:18 <adamw> danofsatx: i can believe it affects netinstall, but you can fix netinstall issues with updates for most people
16:56:23 <adamw> installing with the updates repo disabled is fairly unusual
16:56:45 <danofsatx> yeah, that's kind of one of the points of a netinstall
16:58:34 <adamw> no response from #fedora-kde folks apparently
16:58:43 <danofsatx> nope. they seem to be sleeping.
16:58:52 <adamw> so...
16:59:03 <adamw> i'm -1 blocker/+1 FE
16:59:31 <danofsatx> -1/+1
17:01:28 <adamw> proposed #agreed 1197940 - RejectedBlocker AcceptedFreezeException - we don't believe it's correct that this affects live installs. That means the only scenario that can't be fixed with an update is 'network install of KDE in German with the updates repository disabled', which seems too unusual to block the release for, but accepted as an FE
17:01:30 <jreznik> -1/+1 but dvratil should take care of it
17:01:37 <dvratil> alreadz working on it
17:01:38 <adamw> oh, alsooh, patch
17:02:03 <adamw> proposed #agreed 1197940 - RejectedBlocker AcceptedFreezeException - we don't believe it's correct that this affects live installs. That means the only scenarios that can't be fixed with an update are 'Jam live image compose' (not a blocking image) and 'network install of KDE in German with the updates repository disabled', which seems too unusual to block the release for, but accepted as an FE
17:02:27 <pschindl> ack
17:02:37 <danofsatx> ack
17:02:39 <tflink> ack
17:03:08 <adamw> #agreed 1197940 - RejectedBlocker AcceptedFreezeException - we don't believe it's correct that this affects live installs. That means the only scenarios that can't be fixed with an update are 'Jam live image compose' (not a blocking image) and 'network install of KDE in German with the updates repository disabled', which seems too unusual to block the release for, but accepted as an FE
17:03:19 <adamw> #topic (1219033) Utility detection broken with the cs_CZ (Czech) locale
17:03:20 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1219033
17:03:20 <adamw> #info Proposed Blocker, libblockdev, POST
17:05:12 <adamw> i'm probably -1/+1 on this, as i-s isn't *completely* critical - it's not use on Workstation, and on all the spins where it's used, you can log in graphically as root
17:05:24 <adamw> so you're not stuck if you didn't create a user during install. should still be fixed, though.
17:05:32 <danofsatx> agreed. -1/+1
17:06:09 <tflink> yeah, makes sense to me
17:06:15 <tflink> -1/+1
17:06:16 <pschindl> I would be more to +1. But +1 FE seems good to me as well
17:06:57 <jreznik> -1/+1
17:06:58 <adamw> let me re-check the criterion wording
17:07:41 <adamw> yeah, we made it 'and/or'
17:07:43 <adamw> " A working mechanism to create a user account must be clearly presented during installation and/or first boot of the installed system."
17:07:50 <adamw> so, i stick with my vote
17:08:15 <danofsatx> and/or - it's in the installation setup ;)
17:08:38 <pschindl> The same reasoning could be used for non-working g-i-s (you can switch to console).
17:09:17 <adamw> pschindl: that's not really the 'same' reasoning
17:09:24 <pschindl> But it's true that in graphic it will be easier for normal user (and who uses KDE anyway :) )
17:09:30 <adamw> anyhoo, it's getting fixed, so no reason to argue too hard i guess
17:09:46 <jreznik> pschindl: almost everyone :) come to visit our second floor :)))
17:09:50 <pschindl> +1 FE (with closed one eye)
17:10:28 <pschindl> jreznik: second floor is strange place. Full of managers and so.
17:12:09 <adamw> proposed #agreed 1219033 - RejectedBlocker AcceptedFreezeException - i-s isn't actually critical as you can log in as root on all spins where it's intended to appear, but obviously this should be fixed as we want it to appear
17:12:22 <danofsatx> ackish
17:12:29 <pschindl> ack
17:12:57 <jreznik> ack
17:12:58 <tflink> ack
17:13:17 <adamw> #agreed 1219033 - RejectedBlocker AcceptedFreezeException - i-s isn't actually critical as you can log in as root on all spins where it's intended to appear, but obviously this should be fixed as we want it to appear
17:13:18 * danofsatx has a special request to change the lineup
17:13:33 <adamw> #topic (1219871) don't require pre-created directory in /var
17:13:33 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1219871
17:13:33 <adamw> #info Proposed Blocker, nfs-utils, NEW
17:13:35 <adamw> danofsatx: hmm?
17:13:36 <danofsatx> I'd like to jump to https://bugzilla.redhat.com/show_bug.cgi?id=1217844 due to an upcoming meeting in the office
17:13:49 <adamw> it's the next one up anyway
17:14:03 <danofsatx> oh, ok. hurry up then. ;)
17:14:19 <adamw> -1. nope. atomic is still not a blocking image.
17:14:22 <adamw> +1 FE, though.
17:15:10 <tflink> yeah -1 blocker definitely
17:15:13 <jreznik> -1
17:15:19 <tflink> not sure how intrusive the fix is for FE, though
17:15:33 <tflink> oh, that's not too bad
17:15:36 <tflink> +1 FE
17:15:39 <danofsatx> -1
17:15:50 <adamw> seems pretty small (for FE)
17:15:51 <pschindl> +1 FE
17:15:56 <danofsatx> +1 FE
17:17:36 <adamw> proposed #agreed 1219871 - RejectedBlocker AcceptedFreezeException - Atomic is not a release-blocking image and this bug does not affect any blocking images we know about, but accepted as an FE as fixing Atomic is a good thing if possible
17:17:47 <pschindl> ack
17:18:07 <jreznik> ack
17:18:26 <tflink> ack
17:18:29 <danofsatx> ack
17:18:40 <adamw> #agreed 1219871 - RejectedBlocker AcceptedFreezeException - Atomic is not a release-blocking image and this bug does not affect any blocking images we know about, but accepted as an FE as fixing Atomic is a good thing if possible
17:18:46 <adamw> #topic (1217844) F22 - Plasma 5 Screen Freezes
17:18:46 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1217844
17:18:46 <adamw> #info Proposed Blocker, plasma-workspace, NEW
17:19:35 <danofsatx> ok. So, dgilmore just ran into this bug this morning with AMD graphics, so it is across all GPUs. This effectively makes Plasma unusable if you walk away from it.
17:20:02 <jreznik> it happened once for me (or similar) after daily use on several laptops
17:20:14 <adamw> this seems...mysteious
17:20:26 <danofsatx> rdieter has linked it to upstream bugs, but those are for mesa or neuvau drivers.
17:20:34 <jreznik> and half of our floor at rh runs plasma 5 and I didn't hear about freezes from them
17:20:43 * danofsatx can't spell neuvea
17:21:21 <adamw> jreznik: on F22?
17:21:31 <jreznik> so it can be annoying, but I don't see it happening so often to block release (and it can be hard to track it down)
17:21:32 <danofsatx> it is very mysterios, and very annoying. For instance, last friday I locked this system at 16:22 local time. Plasmashell locked up at 16:35 local time.
17:21:34 <jreznik> adamw: on f22
17:22:08 <rdieter> it happens semi often if screen is locked and a notifcation happens
17:22:10 <jreznik> (not everyone running f22 but a lot)
17:22:15 <danofsatx> the system itself still runs. all desktop apps are running in the background. The general consensus is that notifications are what is locking it up.
17:22:50 <adamw> i guess i'm somewhat inclined to punt, as it seems to be a developing situation
17:22:55 <jreznik> danofsatx: so my freeze was different - just plasma was frozen, everything worked well
17:22:57 <adamw> but...lemme check schedule
17:23:08 <jreznik> I'm -1 blocker on this one
17:23:35 <dgilmore> it has happened to me once
17:23:42 <adamw> go/no-go is 05-21
17:23:45 <danofsatx> plasmashell is what is freezing. If the system is locked, you can't unlock it or otherwise restart plasmashell. if it locks up while in operation, you can kill plasmashell and restart it and continue on.
17:23:46 <adamw> so we have one more scheduled blocker review
17:23:47 <dgilmore> and I have been using KDE on my dekstop for weeks
17:23:52 <rdieter> the issue as being tracked is what jreznik described, where only plasmashell is hung
17:24:00 <adamw> does it sound like this is happening to more people than others?
17:24:23 * adamw brb, call of nature
17:24:36 <dgilmore> danofsatx: in my case I could alt-tab between applications
17:24:39 <jreznik> and yes, there's workaround how to restart plasma (unless it's frozen behind lock screen)
17:24:42 * satellit_e I have not seen it on a VM or an install in tc-3
17:24:48 <dgilmore> it was just the panel that was frozen
17:24:56 <danofsatx> yes, I can do that too. I can open alt-f2, and alt-tab between applications.
17:25:02 <jreznik> dgilmore: yep, same here, just panel was frozen (and one preview window)
17:25:09 <rdieter> satellit_e: <nod>, it only happens with dri3-enabled mesa drivers
17:25:13 <rdieter> afaict
17:25:15 <danofsatx> but like I said, if the system is locked, you're effectively screwed.
17:25:43 <rdieter> danofsatx: maybe yours is different then, you mean ALT-TAB or ALT-F2 doesn't work?
17:25:54 <randomuser> I recall something like this issue from my early use of the plasma5 copr - it went away with compositing turned off
17:26:07 <jreznik> danofsatx: in this case, you are - but it's really not that frequent... I use Plasma 5 on top of F22 everyday on Intel and second installation is on intel/Nouveau (default) T520
17:26:08 <rdieter> if you can get to krunner, you can kill/restart plasmashell
17:26:21 <jreznik> so I'm still -1/+1
17:26:31 <rdieter> frequency is relative to how many notifications you get while screen is locked
17:26:48 <danofsatx> when plasmashell locks up while in use, plasmashell is the only thing locked up and is is recoverable. When plasmashell locks up when the screen is locked, the system is unusable.
17:26:53 <rdieter> I suppose Kevin (Kofler) would use this as an excuse to argue for disabling the default screen lock
17:27:06 <jreznik> rdieter: :)
17:27:20 <jreznik> it's definitely not going to survive last blocker test
17:27:43 <dgilmore> i would be +1 FE
17:27:45 <danofsatx> I run into this on both Intel HD4600 and Nvidia GTX650M
17:27:50 <dgilmore> not quite so sure on blocker
17:28:43 <jreznik> it's not blocker...
17:28:53 <jreznik> (for me)
17:29:00 <adamw> rdieter: what's your opinion on blocker status?
17:29:21 <danofsatx> It is blocker for me.
17:29:41 <rdieter> it's infrequent enough and can be worked around, and fixed in updates... so if asking me... -1 to blocker
17:30:20 <rdieter> it does definitely suck, don't get me wrong
17:30:35 <tflink> what are the odds of this affecting the liveimage enough to cause problems?
17:30:48 <tflink> that's the only thing that's keeping me not completely -1 blocker
17:30:48 <adamw> depends how you use the live image, i guess
17:31:05 <danofsatx> the screen doesn't lock on Live, and notifications are rare I would guess.
17:31:11 <rdieter> could lock screen in live image, and induce some notifications, and probably see it sooner or later
17:31:31 <jreznik> rdieter: but if you use it just for installation - almost no way to hit this one
17:31:43 <dgilmore> the trigger for me seemed to be the popup from all the windows kontact had open
17:31:52 <rdieter> jreznik: correct, that's my experience, never seen it get stuck when screen is not locked
17:31:57 <dgilmore> apparently I left it sitting up and walked away
17:32:07 <rdieter> dgilmore: your screen was not locked?
17:32:13 <dgilmore> rdieter: it was not
17:32:26 <rdieter> oh, :(  interesting, ok.
17:32:29 <tflink> I forget, does the liveimage lock itself?
17:32:36 <danofsatx> I have hit it while using the system. A notification pop up or a preview from the task bar locked plasmashell.
17:32:37 <rdieter> tflink: it should
17:32:56 <adamw> so i'm definitely +1 FE as a minimum
17:33:01 <jreznik> rdieter: actually it's that better option - it's not locked, you just restart it
17:33:06 <adamw> still making up mind on blocker...
17:33:07 <rdieter> maybe it's enough if plasmashll doesn't have focus then
17:33:30 <jreznik> as daily user of Plasma 5 I'm still -1 blocker on this one
17:34:14 <tflink> jreznik: even though the lives can't be fixed after release?
17:34:39 <danofsatx> I've got to run. I am +1 blocker.
17:34:49 <rdieter> in the upstream bugs, seems fedora users are the primary ones experiencing this on plasma5.  does anyone know if we seem to be the only distro using dri3 (or using dri3 before others)?
17:34:52 * satellit_e afk have to go
17:35:04 <jreznik> tflink: I really don't think it will be so frequent on lives, actually I don't think many people are using it as daily driver with many notifications and if so - with overlay and can be updated
17:35:08 <adamw> rdieter: sorry, wouldn't know off the top of my head
17:35:13 <adamw> best to ask airlied/ajax i guess
17:35:15 <danofsatx> I will complete the scretarialization when I return.
17:35:21 <rdieter> ok
17:36:27 <tflink> jreznik: yeah, I was just thinking about the "try out" use case where someone might hit this while not using kde daily and end up with a machine that can't be unlocked (assuming I'm understanding all this correctly)
17:36:35 <adamw> danofsatx: thanks
17:37:27 <jreznik> tflink: and this "try out" - you won't get many notifications and it seems to be related to notifications
17:37:47 <jreznik> believe me, I want Plasma Fedora the best OS ever but...
17:37:55 <rdieter> jreznik: wifi notifications would be the primary thing live users could see
17:38:28 <rdieter> if testers of live image were able to reproduce this semi-reliably, I could change my mind on it being blocker-worthy
17:38:51 <tflink> punt/+1?
17:39:13 <jreznik> well, it seems like punt and gather more data but I still stand behind mine -1 blocker
17:39:14 <rdieter> tflink: punt means, defer decision?
17:39:18 <tflink> rdieter: yeah
17:39:19 <adamw> rdieter: yeah
17:39:22 <rdieter> punt++
17:39:28 <adamw> in this case i guess for a bit more data on the trigger and maybe some more live testing
17:39:33 <adamw> i can vote punt/+1
17:39:38 <pschindl> punt
17:39:39 <adamw> (that is, punt on blocker, +1 FE)
17:40:09 * jreznik is sticking with -1/+1 but if punt, he can ask people using Plasma 5 on F22 if they hit it or not
17:40:12 * dgilmore is with adamw
17:40:31 <adamw> proposed #agreed 1217844 - punt (delay decision) on blocker, AcceptedFreezeException - this certainly seems bad enough to be worth fixing during freeze, we will wait for a bit more data on what is causing it and how frequently it is encountered (especially when booted live) to make a determination on blocker status
17:40:44 <jreznik> ack
17:40:57 <pschindl> ack
17:41:08 <tflink> ack
17:41:28 * pschindl has to leave today earlier
17:41:42 <adamw> #agreed 1217844 - punt (delay decision) on blocker, AcceptedFreezeException - this certainly seems bad enough to be worth fixing during freeze, we will wait for a bit more data on what is causing it and how frequently it is encountered (especially when booted live) to make a determination on blocker status
17:41:53 <adamw> last proposed blocker:
17:41:54 <adamw> #topic (1219986) [abrt] evolution: WebCore::FrameView::removeChild(): evolution killed by SIGSEGV
17:41:54 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1219986
17:41:54 <adamw> #info Proposed Blocker, webkitgtk3, NEW
17:42:18 <tflink> this only hits evolution, right?
17:42:35 <adamw> yeah, and so far i only hit it once - i was going to try and reproduce it on bare metal but got distracted
17:43:13 <tflink> definitely +1 FE, not sure this really needs to be a blocker since i can't see many folks running evolution on a liveimage but it does violate criteria if reproducable
17:43:33 <adamw> i think we could probably punt for a bit more testing
17:43:37 * oddshocks pops in late
17:43:38 <tflink> so I guess I'm +1/+1 conditional on reproducibility
17:45:02 <adamw> ahoy oddshocks
17:45:09 <jreznik> adamw: punt
17:45:22 <tflink> punt works for me
17:46:13 <adamw> proposed #agreed 1219986 - punt (delay decision) - so far we have only one data point here, need to see if it can be reproduced
17:46:21 <tflink> ack
17:46:24 <jreznik> ack
17:46:31 <pschindl> ack
17:46:40 <adamw> #agreed 1219986 - punt (delay decision) - so far we have only one data point here, need to see if it can be reproduced
17:47:15 <adamw> OK, that's all the blockers. suggest we review proposed FEs next as freeze is tomorrow and we need decisions on them
17:47:22 <adamw> we can review accepted blockers at the end if there's still time
17:47:41 <tflink> wfm
17:47:51 <jreznik> yep
17:48:07 <jreznik> maybe just FEs that are doable to get ready soon
17:48:35 <adamw> eh, that would involve work!
17:49:01 <adamw> seriously, doing that kinda requires figuring it out ahead of time, which i didn't do
17:49:01 <jreznik> ok, let's move on - we can sort it during review
17:49:13 <adamw> so may was well go through them all rather than you sitting there waiting for me to speed-read
17:49:13 <adamw> #topic (1218241) CVE-2015-3315 abrt: Various race-conditions and symlink issues found in abrt [fedora-all]
17:49:13 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1218241
17:49:14 <adamw> #info Proposed Freeze Exceptions, abrt, NEW
17:49:25 <adamw> very much +1 for me, this is the 'abrt is a giant security hole' bug
17:49:37 <adamw> well, local privesc, but still nasty.
17:50:29 <jreznik> +1
17:50:31 <tflink> eh, I'm not as +1 - not sure replacing abrt at the last second is wise and i don't see how this would affect lives much
17:50:54 <adamw> tflink: it doesn't, but i don't like shipping things with big security issues.
17:50:56 <jreznik> tflink: we are not yet that late
17:50:57 <tflink> nasty bug, sure - nasty enough to replace abrt after freeze ... depends on when the fix came in
17:51:41 <tflink> adamw: if it's a choice between a big security hole that can be patched post-release and making sure things are stable ... depends on how bad the security hole is for me
17:52:43 <tflink> but I think we've had this argument before - I'm taking +1 FE as being "will take build after freeze" and not "will consider build after freeze assuming it's sane at that point"
17:53:20 <tflink> +1 to considering it after freeze assuming that it's sane to do so at the time a fix becomes available
17:54:35 <adamw> proposed #agreed 1218241 - AcceptedFreezeException - this is a significant ('important') security issue, though not an issue on live images (as root is freely available when booted live). We will consider a fix during the freeze
17:54:45 <oddshocks> ack
17:54:57 <tflink> ack
17:55:12 <dgilmore> I am +1 to FE
17:55:16 <dgilmore> ack
17:55:32 <adamw> #agreed 1218241 - AcceptedFreezeException - this is a significant ('important') security issue, though not an issue on live images (as root is freely available when booted live). We will consider a fix during the freeze
17:55:40 <adamw> #topic (1220358) Fedora 20 doesn't contain F22 gpg keys, prevents fedup
17:55:40 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1220358
17:55:40 <adamw> #info Proposed Freeze Exceptions, fedora-release, NEW
17:55:49 <dgilmore> -1
17:55:55 <dgilmore> its not a change in f22
17:56:01 <adamw> yeah
17:56:14 <adamw> there's nothing to be gained by making an F20 bug an FE for F22./
17:56:17 <dgilmore> I will make an updated fedora-release for f20, I thought they keys had been added
17:56:37 <dgilmore> but I do not see how this is a blocker or FE
17:56:40 <adamw> proposed #agreed 1220358 - RejectedFreezeException - as the issue here is in F20, there'
17:56:42 <adamw> grr
17:56:47 <adamw> proposed #agreed 1220358 - RejectedFreezeException - as the issue here is in F20, there's no reason to mark it as an FE for F22.
17:56:53 <dgilmore> ack
17:56:54 <tflink> ack
17:57:01 <tflink> +1 FE and ack, rather
17:57:23 <adamw> i think you mean -1? :)
17:57:25 <adamw> #agreed 1220358 - RejectedFreezeException - as the issue here is in F20, there's no reason to mark it as an FE for F22.
17:57:32 <adamw> #topic (1220396) fillets-ng fails to start
17:57:32 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1220396
17:57:32 <adamw> #info Proposed Freeze Exceptions, fillets-ng, MODIFIED
17:57:51 <tflink> +1 FE as it impacts the games spin
17:57:55 <adamw> sure, seems fine
17:57:57 <adamw> +1 FE
17:58:00 <dgilmore> +1 FE
17:58:42 <adamw> proposed #agreed 1220358 - AcceptedFreezeException - it'd be good to make sure all games on the games spin work, and this has no apparent chance of breaking anything anywhere else
17:58:56 <tflink> ack
17:59:10 <dgilmore> ack
17:59:12 <oddshocks> ack
17:59:19 <adamw> #agreed 1220358 - AcceptedFreezeException - it'd be good to make sure all games on the games spin work, and this has no apparent chance of breaking anything anywhere else
17:59:25 <adamw> #topic (1185447) text not GUI initial-setup runs on Xfce install (Rawhide 2015-01-23)
17:59:26 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1185447
17:59:26 <adamw> #info Proposed Freeze Exceptions, initial-setup, NEW
17:59:34 * jreznik will be back in 10 minutes
17:59:40 <adamw> should probably update the summary a bit here, as it's been seen on all desktops now i think
17:59:48 <adamw> i'm +1, this is pretty jarring when it happens
17:59:52 <tflink> +1 FE assuming fix is sane to add at the time it's available
18:01:10 * tflink is going to have to direct attention elsewhere in about 20-30 minutes to prepare for the taskotron outage that he should have scheduled for an hour later than he did
18:01:14 <dgilmore> i am +1 to a FE
18:01:21 <adamw> tflink: heh, np
18:01:53 <adamw> proposed #agreed 1185447 - AcceptedFreezeException - while the text i-s works fine, seeing it on a graphical install is fairly jarring and it would be good to fix that if possible
18:02:06 <tflink> ack
18:02:08 <oddshocks> ack
18:02:10 <dgilmore> ack
18:03:47 <adamw> #agreed 1185447 - AcceptedFreezeException - while the text i-s works fine, seeing it on a graphical install is fairly jarring and it would be good to fix that if possible
18:03:52 <adamw> #topic (1217900) Failed to parse mdexamine metadata
18:03:52 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1217900
18:03:52 <adamw> #info Proposed Freeze Exceptions, libblockdev, MODIFIED
18:04:51 <adamw> +1, anaconda crashers are bad
18:05:00 <tflink> +1
18:06:52 <oddshocks> +1
18:07:16 <adamw> proposed #agreed 1217900 - AcceptedFreezeException - any reasonable fix to a crasher in sensible anaconda usage is a good thing to get in
18:07:29 <dgilmore> ack
18:07:31 <oddshocks> ack
18:07:49 <tflink> ack
18:09:12 <adamw> #agreed 1217900 - AcceptedFreezeException - any reasonable fix to a crasher in sensible anaconda usage is a good thing to get in
18:09:21 <adamw> #topic (1212180) Displays a blank window on F22+ (due to qt4 issue with Xshm when X not run as root)
18:09:21 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1212180
18:09:21 <adamw> #info Proposed Freeze Exceptions, liveusb-creator, ASSIGNED
18:09:40 <adamw> -1, i don't really see a need to break freeze for this
18:09:44 <adamw> regular update would be fine
18:10:06 <tflink> yeah, fixable with an update and doesn't seem to affect the kind of things that a live user would likely run
18:10:10 <tflink> -1 FE
18:10:13 <oddshocks> makes sense to me. -1
18:10:29 <dgilmore> -1 FE
18:12:57 <adamw> proposed #agreed 1212180 - RejectedFreezeException - there's no need for an FE here, a regular update will handle the problem fine
18:13:28 <tflink> ack
18:14:01 <oddshocks> ack
18:14:20 <adamw> #agreed 1212180 - RejectedFreezeException - there's no need for an FE here, a regular update will handle the problem fine
18:14:33 <adamw> note: we've already done 1219871, it was in the proposed blockers
18:14:37 <adamw> #topic (1218846) Atomic f22 installer fails to unmount filesystems during install
18:14:37 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1218846
18:14:37 <adamw> #info Proposed Freeze Exceptions, ostree, ASSIGNED
18:14:54 <tflink> is this a side effect of the update push issues that happened last week?
18:15:09 * tflink isn't sure if f22 was affected or not
18:15:15 <tflink> i think it was
18:15:39 <tflink> nvm, this was pushed to stable on 2015-05-01
18:15:52 <adamw> well, in theory I'm +1 FE to atomic installer issues, but really not sure exactly what this bug is about
18:15:56 <adamw> dgilmore: any idea?
18:16:18 <tflink> it looks like the bug is about some installer image not having the atomic fix
18:16:28 <tflink> would have been nice had the specific compose been listed
18:16:46 <tflink> er, the ostree fix for atomic
18:17:54 <adamw> well, the only reading i can come up with is that the 0505 nightly didn't have the fix that was supposedly in ostree-2015.5-5.fc22, but that seems odd.
18:18:42 <dgilmore> adamw: afaik it should be fixed with the last atomic update
18:18:59 <dgilmore> there was issues with the update because it got pushed stable while on its way to testing
18:19:17 <adamw> so you mean it should be fixed in the most recent atomic image?
18:19:20 <tflink> I guess +1 FE if it still isn't in the images
18:19:31 <dgilmore> bodhi said hey its stable. but it was only in updates-testing
18:19:40 <adamw> well, an FE is only relevant if there is an update to push to stable. that's all the FE process is for
18:19:43 <adamw> dgilmore: and you've fixed that now?
18:19:48 <dgilmore> it should have been fixed in teh nightlies
18:20:05 <dgilmore> adamw: it has been tagged into stable
18:20:13 <tflink> ok, I'll rephrase - +1 FE if it still isn't stable
18:20:17 <dgilmore> http://koji.fedoraproject.org/koji/taskinfo?taskID=9702766
18:20:23 <tflink> but it sounds like that is no longer an issue and the bug can be closed
18:20:26 <adamw> yeah
18:20:28 <dgilmore> last nighst nightly atomic image built
18:20:31 <adamw> that sounds like it to me
18:21:06 <adamw> propose #agreed 1218846 - per dgilmore, this issue has been resolved (the update had not been properly pushed stable), so close the bug
18:21:10 <tflink> ack
18:21:16 <jreznik> ack
18:21:24 <oddshocks> ack
18:21:45 <dgilmore> ack
18:21:47 <adamw> #agreed 1218846 - per dgilmore, this issue has been resolved (the update had not been properly pushed stable), so close the bug
18:22:47 <adamw> #topic (1217578) Atomic rawhide installer fails to unmount filesystems during install
18:22:47 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1217578
18:22:48 <adamw> #info Proposed Freeze Exceptions, python-blivet, NEW
18:22:58 <adamw> sounds familiar, but not the same bug
18:23:07 <adamw> afaics, -1 because this is now about something that's specific to rawhide, not an F22 issue
18:23:17 <adamw> the f22 issue seems to have been resolved
18:24:07 <dgilmore> -1 rawhide bugs are not f22 release blockers
18:24:15 <adamw> (or FEs)
18:24:33 <oddshocks> -1
18:24:34 <dgilmore> of FE's
18:24:49 <dgilmore> or
18:25:50 <adamw> proposed #agreed 1217578 - RejectedFreezeException - this bug now seems to be tracking a Rawhide-specific issue, and Rawhide issues are not F22 FEs.
18:26:47 <oddshocks> ack
18:27:01 <tflink> yeah, -1
18:27:02 <tflink> ack
18:27:37 <dgilmore> ack
18:27:51 <adamw> #agreed 1217578 - RejectedFreezeException - this bug now seems to be tracking a Rawhide-specific issue, and Rawhide issues are not F22 FEs.
18:27:55 <adamw> OK, that's all the proposed FEs
18:28:09 <adamw> does anyone have a burning desire to go through the acceptedblockers? personally i'm kinda tired
18:28:22 <adamw> we can all look through them async to make sure they're going somewhere of course
18:28:30 <adamw> or if there's any specific ones that need discussion...
18:28:37 <adamw> oh, i guess we have that one fwraid blocker to circle back to
18:28:54 * tflink is fine skipping them for today
18:28:59 <tflink> has there been an update?
18:29:04 <adamw> not much, but...
18:29:05 <adamw> #topic (1219430) MDRaidError: No name found for the node 'md126p1'
18:29:05 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1219430
18:29:05 <adamw> #info Proposed Blocker, anaconda, NEW
18:29:23 <adamw> #info circling back: this is the same as https://bugzilla.redhat.com/show_bug.cgi?id=1160424 and has been closed as a dupe
18:30:00 <adamw> anaconda team shares our concern about #1160424 but the situation remains that they do not currently have a clear path to fixing the bug and it is not a regression vs. F21, so it's hard to consider it a blocker
18:30:23 <adamw> kind of a sucky situation :/
18:30:29 <dgilmore> i would go +1 FE, blocker i am 0
18:30:38 <dgilmore> if it was a regression I would say +1
18:30:59 <tflink> yeah, i don't see much point in blocking on something that isn't likely to get fixed in time
18:31:00 <dgilmore> but as it is the same situation, it sucks, but if it was a huge issue we would have fixed f21
18:31:05 <tflink> +0
18:31:43 <adamw> yeah, good point, we should make it an FE at least i think
18:31:45 <adamw> +1 FE
18:31:53 * adamw checks if it already is one
18:31:59 <tflink> yeah +0/+1
18:32:51 <adamw> proposed #agreed 1160424 (as 1219430 is a dupe) - AcceptedFreezeException - this is definitely serious enough for a freeze exception; it remains RejectedBlocker for now but we will continue to monitor it
18:33:17 <tflink> ack
18:34:07 <oddshocks> ack
18:34:22 <adamw> #agreed 1160424 (as 1219430 is a dupe) - AcceptedFreezeException - this is definitely serious enough for a freeze exception; it remains RejectedBlocker for now but we will continue to monitor it
18:34:39 <adamw> ok
18:34:40 <adamw> anyone want to pick out any acceptedblocker for review or anything?
18:35:28 * dgilmore has nothing
18:36:58 <tflink> me neither
18:37:02 <adamw> kk
18:37:06 <adamw> #topic Open Floor
18:37:09 <adamw> any other business, anyone?
18:38:28 <tflink> nothing from me
18:39:43 * danofsatx has returned
18:40:12 <adamw> hi again dan
18:40:30 <adamw> i did a couple of bits of 'unusual' secretarialization, so if you come across some bits i touched, that's why
18:40:55 <danofsatx> roger, I'll refresh everything beofre I commence
18:40:56 <adamw> looks like we're about done, thanks for coming, folks
18:40:58 * adamw sets fuse
18:43:28 <adamw> oh, fwiw, i'll be on vacation next week - will ask for someone else to run the meeting on-list
18:43:31 <adamw> roshi may be back by then, or not
18:43:43 <adamw> thanks again folks
18:43:45 <adamw> #endmeeting