16:59:40 #startmeeting F21-blocker-review 16:59:40 Meeting started Wed Jul 9 16:59:40 2014 UTC. The chair is roshi. Information about MeetBot at http://wiki.debian.org/MeetBot. 16:59:40 Useful Commands: #action #agreed #halp #info #idea #link #topic. 16:59:53 #meetingname F21-blocker-review 16:59:53 The meeting name has been set to 'f21-blocker-review' 16:59:58 #topic Roll Call 17:00:09 * pschindl1 is here 17:00:11 my hopes I will never have to join this channel no more are ruined now! 17:00:12 so who's here for some reviewing goodness? 17:00:34 blockers dash hopes and destroy dreams :) 17:00:40 * kparal is here 17:00:49 * roshi is obviously here 17:01:06 * nirik is lurking, but also in fesco meeting when it starts. 17:01:09 #chair kparal tflink pschindl1 jreznik 17:01:09 Current chairs: jreznik kparal pschindl1 roshi tflink 17:01:12 btw, why is it an hour later than usual? 17:01:22 DST? 17:01:26 I dunno 17:01:28 .hellomynameis jsmith 17:01:29 jsmith: jsmith 'Jared Smith' 17:01:52 * nanonyme is lurking but does not remember if he has any formal position anyway; probably not :) 17:01:57 I just copied the last review notice I sent out 17:02:18 do we have a volunteer for secretary duty? 17:03:33 ok, for the next time I proposed move it to 16 UTC, because we have summer time now :) 17:03:47 we usually stick with local time 17:03:58 works for me 17:04:26 I think there might be discussion on changing the time, since mattdm and some other fesco people might be interested in coming to these 17:04:51 ok, let's get started 17:04:55 * lsm5 is lurking 17:05:08 #topic Introduction 17:05:08 Why are we here? 17:05:08 #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. 17:05:12 #info We'll be following the process outlined at: 17:05:15 #link https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting 17:05:17 #info The bugs up for review today are available at: 17:05:20 #link http://qa.fedoraproject.org/blockerbugs/current 17:05:22 #info The criteria for release blocking bugs can be found at: 17:05:25 #link https://fedoraproject.org/wiki/Fedora_21_Alpha_Release_Criteria 17:05:28 #link https://fedoraproject.org/wiki/Fedora_21_Beta_Release_Criteria 17:05:46 onto the first bug 17:06:06 #topic (1111417) anaconda should depend on NetworkManager-wifi 17:06:06 #link https://bugzilla.redhat.com/show_bug.cgi?id=1111417 17:06:08 #info Proposed Blocker, anaconda, ASSIGNED 17:07:19 looks like this is well on it's way to being fixed 17:07:37 yep 17:07:38 +1 for blocker 17:08:14 as it's almost fixed already - I could go either way 17:08:15 reading the criterion, what exactly is "a dedicated installer image"? 17:08:19 is it netinst? 17:08:32 not sure that's 100% defined yet 17:08:39 I think it's everything but cloud, since that doesn't really *install* 17:09:10 anyway, +1 17:09:19 +1 from me too 17:09:23 but yeah - I don't think it's defined as granular as we'll need it 17:09:34 at least server I'd say 17:09:40 +1 17:09:45 Is it worth adding a criterion around "wireless and wired" interfaces for network installation? 17:10:36 depends whether we need that separation 17:10:52 at the moment we consider it equivalent, I think 17:11:28 proposed #agreed - 1111417 - AcceptedBlocker - Installation media should have access to wireless interfaces to satisfy Alpha Criterion "Remote Package Sources" 17:11:48 oh, and who is being secretary today? 17:11:49 ack 17:12:11 * kparal can't volunteer today, might leave early 17:12:14 ack 17:12:17 no worries 17:12:43 any more acks? 17:13:46 ack 17:13:59 ACK 17:14:35 #agreed - 1111417 - AcceptedBlocker - Installation media should have access to wireless interfaces to satisfy Alpha Criterion "Remote Package Sources" 17:14:50 moving on 17:14:52 #topic (1114774) bootloader.write failed: failed to set new efi boot target, system is not bootable 17:14:55 #link https://bugzilla.redhat.com/show_bug.cgi?id=1114774 17:14:57 #info Proposed Blocker, anaconda, NEW 17:15:44 it occurs to me that we might want to add the different products to bz sometime in the future 17:16:49 is this the famous nvram exhaustion bug? 17:16:59 I think it might be 17:18:49 * tflink is doing secretrialization, btw 17:18:52 nah - I think this is just related 17:18:56 thanks tflink :) 17:19:59 has anyone else run into this? 17:20:18 so, I'd really like to see this fixed - grub config files should be generated even if nvram write fails 17:20:24 for sure 17:20:25 but I don't think it's Alpha material 17:20:47 If it causes non-bootable installs it should be alpha blocker 17:20:53 it needs to be fixed, but it doesn't seem to be affecting all the installs or even the typical use cases 17:21:08 pschindl1: but only for selected systems, and the cause is in broken uefi firmware 17:21:39 right - but normally pschindl1 is spot on for blockeriness 17:21:41 we should do our best to work around it, but it affects only someone 17:21:42 IMO 17:21:48 at least that's my understanding 17:22:01 How wide is this expected to be, btw? 17:22:26 though cmurf does have a point at the end of comment 9 17:22:49 it seems anaconda has some nvram issues 17:23:23 I'd say punt to figure out how widespread this is 17:23:29 again? 17:24:13 I can't tell how many systems this effects 17:24:17 but that's just me 17:24:18 but for me, it doesn't sound like alpha, at least with info provided 17:25:07 I'd say reject and re-evaluate if it turns out to be affecting multiple systems 17:25:20 makes sense 17:25:35 we're early enough in the cycle for it to be re-evaluated :p 17:25:59 so, -1 with re-apply if there's more systems affected 17:26:01 for me 17:27:09 proposed #agreed - 1114774 - RejectedBlocker - This bug seems to only affect a small number of systems. If it's shown to affect more systems, we can re-evaluate it. 17:27:30 Sounds reasonable to me 17:27:40 -1 from me, kparal and jreznik is what I was counting 17:27:45 ack 17:27:49 ack. I will try to reproduce it on our efi machine. 17:28:04 #agreed - 1114774 - RejectedBlocker - This bug seems to only affect a small number of systems. If it's shown to affect more systems, we can re-evaluate it. 17:28:27 and on we go 17:28:29 #topic (1109603) dracut unable to boot 3.16 most of the time 17:28:29 #link https://bugzilla.redhat.com/show_bug.cgi?id=1109603 17:28:29 #info Proposed Blocker, cloud-initramfs-tools, NEW 17:28:48 pschindl1: isn't that one of the systems that has been affected by nvram exhaustion issues in the past? 17:30:14 tflink: what system do you refer to? 17:30:30 tflink: yes, it is 17:30:33 we have one in the office which was often affected before the kernel patch 17:31:32 kparal: the amd asus box 17:31:51 tflink: yes, that's the one 17:32:36 so, this bug seems to affect only ARM? 17:32:46 the system sometimes fails to boot 17:33:05 does this bug still show up with the latest kernels in rawhide (rc4 iirc) 17:33:11 ? 17:33:21 that's not there, but we can still decide 17:33:37 Sounded based on bug that it turned random after early 3.16's anyway 17:33:45 yeah 17:33:50 that's what I was reading 17:34:02 but yeah kparal, it looks like only arm 17:34:14 still, ARM is a primary architecture now 17:34:19 yup 17:34:20 so it seems to qualify 17:34:28 How critical is that dracut-module-growroot, btw? 17:34:30 do we block on "it randomly does foo?" 17:34:52 it depends on how often 17:35:05 I'm +1 (partially because I have a machine that randomly boots as well) 17:35:10 2 people confirming seems "often enough" 17:35:21 yeah - that's what I was thinking 17:35:21 Since sounded based on bug removing it made bug disappear completely. Looks like it's something that resizes root after first boot. I think I'm +1 regardless though 17:35:34 How reproducible: 17:35:34 Most of the time 17:36:07 +1 blocker 17:36:39 Well, according to comments reproducibility changed after initial report 17:38:09 proposed #agreed - 1109603 - AcceptedBlocker - Installed systems need to be able to boot according to the Alpha Criteria "Expected installed system boot behavior" 17:38:39 nanonyme: I understood it was caused by having nodebug kernel 17:38:39 true nanonyme - but if it stops manifesting itself, then the blocker can be closed as fixed 17:38:50 ack 17:38:57 kparal, oh, I misunderstand then. I understood it was caused by a newer kernel 17:38:59 ack 17:39:15 #agreed - 1109603 - AcceptedBlocker - Installed systems need to be able to boot according to the Alpha Criteria "Expected installed system boot behavior" 17:39:36 pull! 17:39:37 #topic (1116450) Can't login to fresh rawhide installation (2014-07-04) if SELinux is enforcing 17:39:41 #link https://bugzilla.redhat.com/show_bug.cgi?id=1116450 17:39:43 #info Proposed Blocker, filesystem, NEW 17:41:30 I haven't done an install with a recent rawhide image, but this seems like a clear blocker 17:41:36 +1 17:41:43 Well, I'm currently IRCing from an affected system. +1 17:41:48 +1 17:42:15 it actually violates two criterion, since the workaround forces you to break the SELinux Configuration criteria 17:42:19 This is not just for first-time installs but also upgrades 17:43:06 Just FWIW 17:43:31 (will be debugging further once I get back from cabin) 17:43:48 proposed #agreed - 1116450 - AcceptedBlocker - SELinux blocking login violates the Alpha Crierion "Expected installed system boot behavior" 17:43:52 good to know nanonyme 17:43:58 ack 17:44:01 ack 17:44:23 #agreed - 1116450 - AcceptedBlocker - SELinux blocking login violates the Alpha Crierion "Expected installed system boot behavior" 17:44:44 moving on... 17:44:45 #topic (1116478) [abrt] gnome-initial-setup: gdk_window_hide(): gnome-initial-setup killed by SIGSEGV 17:44:48 #link https://bugzilla.redhat.com/show_bug.cgi?id=1116478 17:44:51 #info Proposed Blocker, gnome-initial-setup, NEW 17:45:07 roshi, either that or I'm seeing a sister bug that's roughly the same. I'll be out of here tomorrow, will be able to go more thoroughly through these then 17:45:21 sounds good 17:45:28 you want an action item for it? 17:46:29 +1 for this bug 17:46:36 Not with this meeting, I think 17:46:50 It is more nice to have I thing, there is quite easy work around. 17:46:59 * roshi had never given an #action in a blocker meeting - wanted to see what it felt like :p 17:47:02 +1 17:47:14 pschindl1, yes, enforcing=0 does miracles 17:47:17 true pschindl1 - but the criteria is pretty clear 17:47:32 or are you talking about the last bug? 17:47:53 no, I was talking about g-i-s 17:47:58 Oh, sorry 17:48:07 * oddshocks pops in late, just got back from a roadtrip 17:48:17 roshi: thanks for the invite 17:48:30 not to mention having to reboot from a fresh install would lead to a bad first time user experience :) 17:48:37 np oddshocks glad to have you aboard 17:48:53 https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting for info on what's going on and whatnot 17:49:00 if you want it :) 17:49:20 so we've got two +1; anybody else? 17:49:22 But I'm ok with blocker, it really violates criteria 17:49:33 Sounds like a +1 to me 17:49:33 so +1 17:49:54 +1 from me 17:50:21 proposed #agreed - 1116478 - AcceptedBlocker - This is a clear violation of the "Expected installed system boot behavior" Alpha Criterion 17:51:01 * oddshocks clicks 17:51:05 ack 17:51:09 roshi: might be good to add a short excerpt of that particular criterion into #agreed 17:51:17 otherwise ack, of course 17:51:41 I can do that - was thinking having the criteria to reference was good enough 17:52:11 ACK 17:52:13 proposed #agreed - 1116478 - AcceptedBlocker - This is a clear violation of the "Expected installed system boot behavior" Alpha Criterion: "A system installed with a release-blocking desktop must boot to a log in screen where it is possible to log in to a working desktop using a user account created during installation or a 'first boot' utility." 17:52:32 ack 17:52:34 * roshi always did that during the secretarial work 17:53:03 * roshi takes nothing as continued acks 17:53:08 #agreed - 1116478 - AcceptedBlocker - This is a clear violation of the "Expected installed system boot behavior" Alpha Criterion: "A system installed with a release-blocking desktop must boot to a log in screen where it is possible to log in to a working desktop using a user account created during installation or a 'first boot' utility." 17:53:15 unfortunately there is a length limit in irc, so sometimes it needs to be shortened. but it's better to have it there 17:53:57 oddshocks, the basic workflow is: look at bug, compare to criteria, vote +1/-1 if it violates the criteria, then ack/nack on the proposed #agreed 17:54:06 and next bug is.... 17:54:22 #topic (1099581) 'pyanaconda.timezone.TimezoneConfigError' after completing initial-setup 17:54:25 #link https://bugzilla.redhat.com/show_bug.cgi?id=1099581 17:54:28 #info Proposed Blocker, initial-setup, VERIFIED 17:54:34 verified? 17:54:39 we can skip that 17:54:43 yup 17:54:53 didn't see that until I pasted it 17:55:06 moving on 17:55:07 #topic (1115120) cryptsetup-1.6.5-1.fc21 breaks booting when using luks partitions 17:55:10 #link https://bugzilla.redhat.com/show_bug.cgi?id=1115120 17:55:13 #info Proposed Blocker, kernel, ASSIGNED 17:55:31 +1 17:56:20 roshi: cool, thanks 17:56:26 I don't see anyting about luks in the alpha criteria 17:56:48 I quoted the passage I think applies in the ticket. 17:57:13 ah, sry I reacted on the wrong bug, my fault 17:57:48 brunowolff: is it specific to your system or does it affect most people with encrypted /home? 17:57:59 true brunowolff 17:58:02 If you set up encrypted partitions during install, the machine should boot. 17:58:12 yeah - clear +1 IMO 17:59:20 ok +1 - "In all of the above cases, if any system partitions were encrypted as part of the installation, the boot process must prompt for the passphrase(s) and correctly unlock the partition(s) when provided with the correct passphrase(s). " from Expected installed system boot behavior 17:59:27 brunowolff: ? 17:59:30 +1; is it just me of does this seem like a SELinux bug? 18:00:20 The encrypted partitions work OK in early boot, but mounting them in late boot fails. I am not sure if luks is resetup in a way that would not work in late boot for /. Things fail when it gets to /home. 18:01:20 All of the machines that were broken for me have /home as a separate partition. 18:01:25 I don't know that this would be related to selinux nanonyme - but then again, setenforce 0 fixes all kinds of things I wouldn't expect it to 18:01:31 IOW the discussion in the bug escalated to SELinux policies on certain cryptsetup files 18:02:01 However, for blocker purposes I think not having /home work when it is a separate encrypted partition is still a blocker. 18:02:03 I understand there are multiple broken machines, so +1 18:02:07 I'll just shut up, not related to blockerness 18:03:06 My understanding from the bug is that the real fault is a kernel bug in labelling a socket. The socket shows up as unlabelled when it should have a label. 18:03:57 proposed #agreed - 1115120 - AcceptedBlocker - This violates the encryption subsection of the "Expected installed system boot behavior": if any system partitions were encrypted as part of the installation, the boot process must prompt for the passphrase(s) and correctly unlock the partition(s)... 18:04:01 (ie re-iterating that yes, I think it's a blocker) 18:04:11 I see the probelm on 3 similarly set up machines (though the hardware is significantly different between them). 18:04:15 ACK 18:04:32 ack 18:04:35 ack 18:04:56 #agreed - 1115120 - AcceptedBlocker - This violates the encryption subsection of the "Expected installed system boot behavior": if any system partitions were encrypted as part of the installation, the boot process must prompt for the passphrase(s) and correctly unlock the partition(s)... 18:05:06 the next one is an arm bug 18:05:06 #topic (1115905) Segfaults on ARM 18:05:07 #link https://bugzilla.redhat.com/show_bug.cgi?id=1115905 18:05:07 #info Proposed Blocker, libgit2, NEW 18:06:46 I'm missing any substantial info on what crashes 18:06:55 the fact that the unit tests fail is not an alpha blocker 18:07:03 if git crashes, it's not an alpha blocker 18:07:37 yeah - disabling failing tests doesn't equate to blocker status 18:07:47 so it seems like -1 and ask for reason why it should be an alpha blocker 18:07:49 and it's not clear what's failing other than the tests 18:08:14 Ive asked Peter for clarification on this one 18:08:40 I've not run into it 18:09:00 Agreed -- not sure it's a blocker, but disabling unit tests is not the right answer 18:09:05 proposed #agreed - 1115905 - RejectedBlocker - It's not clear in the bug why this was nominated as a Alpha Blocker. Please provide reasoning and reapply. 18:09:06 (especially with ARM being a primary arch now) 18:09:17 ACK 18:09:20 ack 18:09:22 ack 18:09:22 ack 18:09:56 #agreed - 1115905 - RejectedBlocker - It's not clear in the bug why this was nominated as a Alpha Blocker. Please provide reasoning and reapply. 18:10:25 almost done folks, only 5 more blockers to go and one FE 18:10:26 #topic (1019454) fatal: RPC failed at server. There is no Hardware named 'armv7l' 18:10:29 #link https://bugzilla.redhat.com/show_bug.cgi?id=1019454 18:10:32 #info Proposed Blocker, libreport, NEW 18:10:38 this is closed, sorry for not updating the bz 18:10:58 that might have been one of the quickest blocker bug reviews ever :) 18:11:03 moving on then 18:11:15 #topic (1052317) selinux-policy preventing login through sddm and ssh 18:11:18 #link https://bugzilla.redhat.com/show_bug.cgi?id=1052317 18:11:21 #info Proposed Blocker, selinux-policy-targeted, NEW 18:12:29 is this the same as the gdm+selinux bug? 18:12:39 looks like it could be 18:13:08 they seem pretty similar - mislabeling things 18:13:14 the workaround is the same 18:13:56 it's not clear whether this affects fresh installs 18:14:17 it has to affect fresh installs in order to be alpha blocker 18:14:22 yeah 18:14:27 so, either punt or reject 18:14:29 danofsatx-work: you around? 18:14:45 I'd punt and ask for confirmation about fresh installs 18:15:00 I concur 18:15:08 without that detail there isn't a good way to know 18:15:16 I'd punt too. I can try it tomorrow. 18:16:27 proposed #agreed - 1052317 - Punt - It's not clear if this affects fresh installs (which would make it qualify for Alpha Blocker), please provide details on if this manifests on fresh installations. 18:16:36 fresh installs are affected, installed this morning and couldnt log in until a relabel 18:16:43 * pwhalen is distracted 18:16:55 you mean I wrote all that for nothing pwhalen ? 18:16:57 :p 18:17:04 :D 18:17:07 sorry 18:17:12 if it affects fresh installations then it's a +1 from me 18:17:20 but someone should update the bug to reflect that 18:17:24 yes, believe satellite also reported 18:17:31 +1 18:17:34 +! 18:17:34 +1 18:17:36 +1 18:17:42 +1 18:18:10 +1 18:19:13 proposed #agreed - 1052317 - AcceptedBlocker - This violates the Alpha Criterion "Expected installed system boot behavior": A system installed with a release-blocking desktop must boot to a log in screen where it is possible to log in to a working desktop using a user account created during installation... 18:19:22 ack 18:19:28 ack 18:19:29 ack 18:19:34 * roshi sees pwhalen trying to pad the votes there... 18:19:41 :) 18:19:49 #agreed - 1052317 - AcceptedBlocker - This violates the Alpha Criterion "Expected installed system boot behavior": A system installed with a release-blocking desktop must boot to a log in screen where it is possible to log in to a working desktop using a user account created during installation... 18:20:13 onward and upward! 18:20:14 #topic (1116651) systemd-215 breaks livecd-tools with /etc/resolv.conf handling 18:20:17 #link https://bugzilla.redhat.com/show_bug.cgi?id=1116651 18:20:20 #info Proposed Blocker, systemd, NEW 18:20:54 bah, I'm trying to do too many things @ the same time - thought the punt was accepted 18:21:27 it was, then pwhalen went and broke all the things with his accurate input 18:21:45 :) 18:23:26 trying to keep it exciting 18:23:34 haha 18:23:39 it's working 18:24:14 TNT's Summer New Drama "Fedora Blocker Review Meetings" 18:24:23 er, new summer drama, w/e 18:24:34 it's always fun to read discussions with lennart involved 18:25:01 lol 18:25:27 so, honestly, I don't know how to vote on this 18:25:36 I'm not sure whether it concerns systemd anaconda or livecdtools 18:25:50 yes, it's a blocker if TC1 can't be composed 18:25:52 ...yes? 18:26:06 it seems that has been patched and is building 18:26:07 i would agree 18:26:08 aiui 18:26:09 so if that's the correct bug to make a blocker of, let's make it a blocker 18:26:25 the live images all seemed to work looking at releng-dash this morning 18:26:25 and let them resolve their disputes until it works again 18:26:48 roshi: in that case we might not need to vote on this 18:27:09 workstation-armhfp(raw) was the only fail as of 5 hours ago 18:27:16 so I think we can just move on 18:27:29 er, 6 hours ago 18:27:35 * roshi can type, he promises 18:27:41 yep, all live cds seems to be built. So the problem was resolved. 18:27:48 moving on then 18:28:02 so let's suggest there to drop the blocker nomination 18:28:12 if the building process works now 18:28:50 https://apps.fedoraproject.org/releng-dash/#livecds here is the list of livecds and they looks quite built to me :) 18:28:58 proposed #agreed - 1116651 - RejectedBlocker - This seems to be resolved for now. If it comes up again please reapply for blocker status. 18:29:10 yeah - that's where I looked too pschindl1 18:29:14 ack 18:29:18 ack 18:29:40 ack 18:29:41 #agreed - 1116651 - RejectedBlocker - This seems to be resolved for now. If it comes up again please reapply for blocker status. 18:29:52 now moving on :) 18:29:55 #topic (1044778) wandboard uboot missing serial line speed in console environment variable 18:29:58 #link https://bugzilla.redhat.com/show_bug.cgi?id=1044778 18:30:00 #info Proposed Blocker, uboot-tools, NEW 18:30:35 looks like this is just the wandboard? 18:30:57 i may have been over zealous with blocker nomination, this affects one board and can be worked around. dgilmore is going to fix this before release 18:31:17 pwhalen: kernel messages are not shown, but you can log in? 18:31:37 if you're using a display, it should work.. serial.. not so much 18:32:09 so this is basically fixed already pwhalen? 18:32:14 " A system installed without a graphical package set must boot to a state where it is possible to log in through at least one of the default virtual consoles. " 18:32:22 so I think this would apply 18:32:34 is it all arm, or one board in the arm ecosystem? 18:32:41 * roshi isn't clear on that line 18:32:45 in the process, dgilmore is looking to have it fixed. for tracking it may be good to accept 18:32:48 one board 18:33:10 do you have some estimate how common the board is? 18:33:27 it is one piece of hw . no estimates. we'd love to know. 18:33:29 if it's not a complete outsider, I'm for +1 18:33:42 yeah - if it's a more common board, then +1 18:33:46 it is currently one of the best supported options 18:33:47 isn't it one of the supported arm platforms, though? 18:34:08 it is 18:34:19 +1 18:34:25 yeah - but if it's an odd board, then it's like blocking for a single odd mobos UEFI setup 18:34:34 right? or am I understanding it wrong? 18:35:20 roshi, pretty common 18:35:29 ok 18:35:31 +1 then 18:35:54 +1 18:36:17 roshi: it's a bit different for arm, I think. they only list a few boards as supported and this is one of them 18:36:34 proposed #agreed - 1044778 - AcceptedBlocker - This blocks the Alpha Criterion "Expected installed system boot behavior": A system installed without a graphical package set must boot to a state where it is possible to log in through at least one of the default virtual consoles. 18:36:39 right, and one of our 'stars' 18:36:54 gotcha 18:37:09 ack 18:38:07 any other acks? 18:38:10 * roshi acks 18:38:15 ack 18:38:19 ack 18:38:25 #agreed - 1044778 - AcceptedBlocker - This blocks the Alpha Criterion "Expected installed system boot behavior": A system installed without a graphical package set must boot to a state where it is possible to log in through at least one of the default virtual consoles. 18:38:36 and now for the last blocker bug 18:38:38 #topic (1044304) Segmentation fault in xorg-x11-drv-nouveau with kernel 3.13.0-0.rc3.git5.1.fc21.x86_64 18:38:41 #link https://bugzilla.redhat.com/show_bug.cgi?id=1044304 18:38:43 -1 it seems to be already resolved (last comment) 18:38:44 #info Proposed Blocker, xorg-x11-drv-nouveau, NEW 18:39:19 hola 18:39:25 I'm not sure why it's not closed then. 18:39:38 it's been a couple months and seems to be fixed 18:39:51 we were looking at other kde bugs that the desktop worked with later kernels 18:40:44 it's old, ask for newer info or drop 18:42:13 proposed #agreed - 1044304 - Punt - This bug seems to have gone stale. If it is still an issue, let us know or remove the blocker status. 18:42:31 ack 18:42:32 ack 18:42:36 ack 18:42:44 #agreed - 1044304 - Punt - This bug seems to have gone stale. If it is still an issue, let us know or remove the blocker status. 18:42:50 onto freeze exceptions 18:43:11 #topic (1116291) [en_US] imsettings-qt pulls in imsettings on Workstation Live causing: can't use any input method in gtk applications for en_US.utf8 locale 18:43:14 #link https://bugzilla.redhat.com/show_bug.cgi?id=1116291 18:43:16 #info Proposed Freeze Exceptions, spin-kickstarts, MODIFIED 18:44:01 I wonder if we need to vote on freezeexceptions now 18:44:05 it's not freeze yet 18:44:09 and it's already modified 18:44:25 do we need to do FEs? 18:44:28 * danofsatx-work was at class, here now (albeit too late to do any good) 18:44:31 probably not 18:44:45 just was on a roll doing the blocker meeting and whatnot :) 18:44:54