17:00:48 #startmeeting F17-beta-blocker-review-1 17:00:48 Meeting started Fri Mar 2 17:00:48 2012 UTC. The chair is tflink. Information about MeetBot at http://wiki.debian.org/MeetBot. 17:00:48 Useful Commands: #action #agreed #halp #info #idea #link #topic. 17:00:52 #meetingname F17-beta-blocker-review-1 17:00:52 The meeting name has been set to 'f17-beta-blocker-review-1' 17:01:06 who's ready for some blocker bug review party time? 17:01:13 * pschindl is present 17:01:19 * nirik is lurking 17:01:19 #topic roll call 17:01:26 morning 17:01:46 pschindl, adamw: welcome to the party! 17:02:00 hi all 17:02:08 is this partypoker.net? 17:02:17 * brunowolff is here 17:02:31 adamw: if by poker you mean blocker review, sure :) 17:02:48 poker sounds better :) 17:03:15 jpoker is ftbfs. I looked at it, but it didn't look simple to fix. 17:03:33 that's an interesting thought, I wonder if we'd get more people if we started calling these meetings poker parties 17:03:33 we use pokerth in the secret fedora poker sig. 17:03:55 tflink: someone i think partyblockerreview.net would not be as successful a business 17:03:58 s/someone/somehow/ 17:04:23 adamw: I don't know, blockerreviewparty.net sounds pretty tempting 17:06:03 ok, I think we have enough people. let's get started 17:06:12 any volunteers for secretary? 17:06:23 #chair adamw 17:06:23 Current chairs: adamw tflink 17:06:41 #topic Introduction 17:06:56 in case this wasn't clear ... 17:07:02 #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:07:10 #link https://fedoraproject.org/wiki/Current_Release_Blockers 17:07:11 #link https://fedoraproject.org/wiki/Fedora_17_Beta_Release_Criteria 17:07:11 #link https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting 17:07:27 Up for review today are: 17:07:29 #info 8 Proposed Blockers 17:07:29 #info 1 Proposed NTH 17:07:29 #info 1 Accepted Blocker 17:07:47 unless there are objections, I'm going to start with the proposed blockers 17:08:34 #topic (753421) FSError: failed to get block size for ext4 filesystem on /dev/md127 17:08:37 #link http://bugzilla.redhat.com/show_bug.cgi?id=753421 17:08:38 Bug 753421: unspecified, unspecified, ---, dlehman, ASSIGNED, FSError: failed to get block size for ext4 filesystem on /dev/md127 17:08:39 #info Proposed Blocker, ASSIGNED 17:09:18 looks like a pretty clear blocker to me according to c#4 17:09:48 proposed #agreed - 753421 - AcceptedBlocker - The installer must be able to successfully complete an upgrade installation from a clean, fully updated default installation (from any official install medium) of the previous stable Fedora release, either via preupgrade or by booting to the installer manually. The upgraded system must meet all release criteria. 17:10:27 ack 17:11:04 sorry, reading 17:11:27 ack 17:11:33 sucks that it's in f16, too. le sigh 17:11:41 there are no constraint on hardware in the criterion 17:12:21 sucks that we missed this for f16 17:12:37 #agreed - 753421 - AcceptedBlocker - The installer must be able to successfully complete an upgrade installation from a clean, fully updated default installation (from any official install medium) of the previous stable Fedora release, either via preupgrade or by booting to the installer manually. The upgraded system must meet all release criteria. 17:12:45 #topic (787893) Anaconda needs to handle /usr move preparation on upgrade for F17 17:12:49 #link http://bugzilla.redhat.com/show_bug.cgi?id=787893 17:12:50 Bug 787893: urgent, unspecified, ---, bcl, MODIFIED, Anaconda needs to handle /usr move preparation on upgrade for F17 17:12:51 #info Proposed Blocker, MODIFIED 17:13:04 pschindl: it comes under the 'configuration specific issues require judgment call' thing, but i'd say it's pretty obvious that this one's significant enough to take 17:13:29 this is an obvious blocker 17:13:39 adamw: it was just note, I'm not against ack :) 17:13:42 and worries me that it's kind of been left sitting on a couple of hard to understand comments from harald 17:13:51 pschindl: sure, i was just explaining for the record 17:13:53 proposed #agreed - 787893 - AcceptedBlocker - #topic (787893) Anaconda needs to handle /usr move preparation on upgrade for F17 17:13:57 #link http://bugzilla.redhat.com/show_bug.cgi?id=787893 17:13:57 whoops 17:13:58 Bug 787893: urgent, unspecified, ---, bcl, MODIFIED, Anaconda needs to handle /usr move preparation on upgrade for F17 17:13:59 #undo 17:13:59 Removing item from minutes: 17:14:01 #undo 17:14:01 Removing item from minutes: 17:14:04 #info Proposed Blocker, MODIFIED 17:14:06 #undo 17:14:06 Removing item from minutes: 17:14:44 proposed #agreed - 787893 - AcceptedBlocker - The installer must be able to successfully complete an upgrade installation from a clean, fully updated default installation (from any official install medium) of the previous stable Fedora release, either via preupgrade or by booting to the installer manually. The upgraded system must meet all release criteria 17:14:57 * adamw trying to get bcl to join 17:14:58 ack 17:15:05 ack 17:15:14 crap, I think I screwed up the minutes 17:15:23 #info Proposed Blocker, MODIFIED 17:15:27 there we go 17:16:32 definitely a blocker, plus we should probably ping it to try and get anaconda team to let us know where it's at 17:16:34 #agreed - 787893 - AcceptedBlocker - The installer must be able to successfully complete an upgrade installation from a clean, fully updated default installation (from any official install medium) of the previous stable Fedora release, either via preupgrade or by booting to the installer manually. The upgraded system must meet all release criteria 17:17:11 adamw: you OK with taking the action item on that? 17:17:39 sure 17:17:41 #action adamw to ping anaconda team to make sure that 787893 gets fixed 17:17:46 i'm going to do it now, so no need...ah well 17:18:26 adamw: you can't stop the bureaucracy! 17:18:35 #topic (796155) iface_ip2str returned NULL 17:18:35 #link http://bugzilla.redhat.com/show_bug.cgi?id=796155 17:18:35 #info Proposed Blocker, NEW 17:18:36 Bug 796155: unspecified, unspecified, ---, rvykydal, NEW, iface_ip2str returned NULL 17:18:50 criterion: The installer must be able to use all kickstart delivery methods 17:19:51 yep, I imagine that this one is waiting for the noloader patch 17:19:52 +1 blocker as things stand 17:20:07 +1 blocker 17:20:09 especially since it can also affect http 17:20:12 +1 17:20:21 proposed #agreed - 796155 - AcceptedBlocker - The installer must be able to use all kickstart delivery methods 17:20:24 adamw: the last comment says it doesn't 17:20:26 ack/nak/patch? 17:20:30 ack 17:20:35 oh, okay. but still ack. 17:20:37 ack 17:20:46 #agreed - 796155 - AcceptedBlocker - The installer must be able to use all kickstart delivery methods 17:20:55 #topic (799312) @base and @base-x comp results in a broken system 17:20:55 #link http://bugzilla.redhat.com/show_bug.cgi?id=799312 17:20:55 #info Proposed Blocker, NEW 17:20:56 Bug 799312: unspecified, unspecified, ---, notting, CLOSED DUPLICATE, @base and @base-x comp results in a broken system 17:21:23 ah, my bug 17:21:44 is that supposed to work? 17:21:57 ie is @base and @base-x enough? 17:22:10 well it should at least give me a prompt, shouldn't it? 17:22:18 if I use just @base, it gives me console prompt 17:22:24 if I add @base-x, it doesn't 17:22:40 what do you get? 17:22:44 I wonder how firstboot-text got started, I thought that we disabled it 17:22:51 adamw: nothing, see screenshot 17:23:00 just ctrl+alt+del works 17:23:40 huh. firstboot-text seems to have risen from the grave. 17:23:57 * tflink wonders if the firstboot logic was triggered by the presence of X but didn't have everything needed to actually start 17:24:45 ah, i see a new firstboot 17 build which kills it again. 17:24:53 tflink: no, that's just firstboot-text.service firing. they're entirely separate services. 17:24:54 see also the dupe bug, yes 17:25:06 the 'weird tool' in question is /usr/bin/setup, fwiw. 17:25:12 i'm +1 blocker, anyhow. 17:25:25 should it be reopened and rephrased then? 17:25:33 oh, lemme see the dupe 17:25:34 A few packages went backwards in the mass rebuild since they had changes in F16 that hadn't been pushed to rawhide. 17:25:58 I noted a few on the devel list, but I don't know if anyone did anything about those. 17:26:10 the dupe is fine 17:26:16 we should re-open the dupe and mark it as a blocker 17:26:18 proposed #agreed - 799312 - AcceptedBlocker - When booting a system installed without a graphical environment, or when using a correct configuration setting to cause an installed system to boot in non-graphical mode, the system should provide a working login prompt without any unintended user intervention when boot is complete, and all virtual consoles intended to provide a working login prompt should do so 17:26:25 it's been 'closed nextrelease' but the update isn't actually pushed yet 17:26:26 nack 17:26:34 798373 should be the blocker (the bug it's a dupe of) 17:26:34 adamw: patch? 17:26:52 oh, I generated this list before the dupe went through 17:27:10 proposed #agreed - 798373 - AcceptedBlocker - When booting a system installed without a graphical environment, or when using a correct configuration setting to cause an installed system to boot in non-graphical mode, the system should provide a working login prompt without any unintended user intervention when boot is complete, and all virtual consoles intended to provide a working login prompt should do so 17:27:17 ack 17:27:19 #info 799312 is a dupe of 798373 17:27:22 ack 17:27:25 am i chair? 17:27:27 ack 17:27:30 ack 17:27:30 adamw: yep 17:27:34 okay, so that should go in. 17:27:41 #agreed - 798373 - AcceptedBlocker - When booting a system installed without a graphical environment, or when using a correct configuration setting to cause an installed system to boot in non-graphical mode, the system should provide a working login prompt without any unintended user intervention when boot is complete, and all virtual consoles intended to provide a working login prompt should do so 17:27:57 #topic (795412) No poweroff option in greeter in VM 17:27:57 #link http://bugzilla.redhat.com/show_bug.cgi?id=795412 17:27:57 #info Proposed Blocker, NEW 17:28:00 Bug 795412: unspecified, unspecified, ---, rstrode, NEW, No poweroff option in greeter in VM 17:28:14 and me again, yay 17:28:17 I'm famous 17:28:53 for me, the key question is - is poweroff/restart a supported mechanism? 17:29:07 from GDM/KDM anyways 17:29:20 darn well ought to be. 17:29:22 should be, it's in criteria :) 17:29:40 it was a bug in F16. I believe it's again bug in F17. I don't think upstream removed that intentionally 17:29:44 bcl: no arguments from me there 17:29:48 pschindl: it is? 17:30:12 tflink: All release-blocking desktops' offered mechanisms (if any) for shutting down, 17:30:14 logging out and rebooting must work 17:30:22 I think this one could fit 17:30:35 pschindl: yeah but that wasn't my question. is doing that from GDM a supported mechanism? 17:30:37 it's mentioned in the bug report. but it is not "offered" 17:31:05 I can find the same bug for F16, we discussed the same problem 17:31:15 I think it meets the criteria as documented, but I seem to remember discussing a similar issue a release or two ago. 17:31:19 the bug isn't that you _can't_ shutdown/reboot. just that you can't do so from GDM 17:31:31 what if you can't log in? 17:31:40 I thought we had discussed loosening up the requirement. 17:32:11 kparal: VT + 3 finger salute 17:32:48 let's ping someone from gdm upstream whether it's intentional 17:32:51 I doubt that 17:32:52 it doesn't meet the criteria as documented 17:33:02 the criteria specifically says "offered mechanisms (if any)" 17:33:11 * kparal searches for F16 bug 17:33:18 that means that whatever power management options are actually *shown* in the DM must work 17:33:22 yeah, I'm pretty much -1 blocker on this 17:33:26 it doesn't require any particular options to be present or not present 17:33:43 i think it's a bug and gnome team will want to fix it, but it's not clearly a blocker 17:33:59 adamw: you are right. So it looks like -1 blocker 17:34:04 of course, there's the problem that 'do it from GDM' is the gnome team's 'official' answer to the question 'how do i power off / reboot' 17:34:13 can we discuss FinalBlocker afterwards? 17:34:32 so if it's broken in gdm, there's really no way to shut down / reboot from GNOME except the 'sekrit' alt key workaround 17:34:44 I was thinking offered meant intended to be offered rather than visible. If visible is meant, than it's not a blocker. 17:35:47 kparal: which final criterion were you thinking of? 17:36:05 tflink: I don't think I have one 17:36:14 I've got -3 explicit and I'm guessing +1 implicit for blocker? 17:36:35 if upstream says it's a bug, I would be +1 for Final blocker 17:36:35 brunowolff: if its not visable its not offered 17:36:47 -1 for Beta if you think so 17:36:49 -1 blocker 17:37:33 * kparal can't find F16 dupe 17:37:46 -1 for beta anyhow 17:37:59 yep, it can be re-proposed for final 17:38:06 kparal: in F16 i complained loudly about the lack of poweroff when logged in, but I don't remember a problem with GDM 17:38:24 maybe it was F15 17:38:27 but I do 17:38:31 I'm -1 beta but +1 final on this 17:38:42 proposed #agreed - 795412 - RejectedBlocker - Does not hit any of the beta release criteria since all of the visible methods work 17:38:53 ack 17:39:34 ack 17:39:38 ack 17:39:41 ack, but I'll re-propose it for Final. ask bug rstrode about it 17:39:44 *and 17:39:57 #agreed - 795412 - RejectedBlocker - Does not hit any of the beta release criteria since all of the visible methods work 17:40:22 I'm just not sure that the blocker process is right for this but we can re-visit if it isn't fixed by final 17:40:35 #topic (736993) error install bootloader with serial interface install 17:40:38 #link http://bugzilla.redhat.com/show_bug.cgi?id=736993 17:40:39 Bug 736993: medium, unspecified, ---, pjones, ASSIGNED, error install bootloader with serial interface install 17:40:40 #info Proposed Blocker, ASSIGNED 17:41:07 this one should be final blocker 17:41:26 did we ever get around to dealing with console install issues? 17:41:42 or does that fall under the "all supported interfaces" criterion for final? 17:41:46 * kparal points out comment 46 17:42:20 if it is a final blocker, we can't test any automation 17:42:25 kparal: yeah, I think that's been the other side of the serial console argument 17:42:44 and I don't mean just AutoQA, no one can 17:42:54 automation can catch quite some problems 17:43:15 But does that make it a blocker, rather than just important? 17:43:39 with the criteria as they are, I think our options are: defer to final or defer to next week and propose criteria change 17:44:19 so we're back to the 'when should serial console block release' question 17:44:22 when I proposed this criterion as final nobody had objection. 17:44:38 i think we're generally agreed it should be beta or final - it shouldn't be alpha, and it shouldn't be 'not a blocker' 17:44:56 i think i'm probably okay with final 17:45:11 as bruno suggests, the question of 'importance to autoqa' is kind of orthogonal to the question of 'importance to the release' 17:45:25 and I was not talking about autoqa 17:45:48 sorry, so what do you mean? 17:45:50 I guess there are people out there who run tests on development releases 17:45:58 it's not *just autoqa* 17:46:02 what *is* it? 17:46:20 beaker would also be impacted if anyone was using it w/ fedora pre-releases 17:46:51 wait, that's not quite right. I was mixing up some other issues from F16 17:46:53 mmm 17:47:10 either way, this isn't a beta blocker as is 17:47:23 no, but don't cut off the discussion 17:47:34 i mostly proposed it so we could discuss the serial question, as we need to settle it 17:48:02 what is our general approach to automation/kickstart/virt stuff? 17:48:06 it is all beta? 17:48:16 or all final? 17:48:17 i don't see those three as being the same thing at all... 17:48:35 well, automation tends to rely on virt and kickstart 17:48:40 what is it about them that makes you lump them together? 17:49:00 I'm just trying to find some pattern 17:49:05 but it's not the *only* thing that uses virt and kickstart 17:49:07 that could guide us in the decision process 17:49:18 so it doesn't follow that 'virt and kickstart are beta in the criteria because we want automation to work at beta' 17:49:21 What outside groups need this for testing? For internal testing, we are locked into using the beta release, as opposed to daily builds. 17:49:36 That should be aren't, not are. 17:49:40 I think that a sub-question is whether we consider testability via automation blocker issues 17:53:01 * adamw watches dustballs blow by 17:53:20 i don't really have a position on this, i just want there to be a decent justification for whatever decision we come up with 17:53:54 how much work would it be to fix serial console install? 17:53:56 i'm fine if we decide enough valid beta usage requires serial console install, hence we should make it work 17:54:05 that should not be a consideration at all for defining the criteria 17:54:14 Unless someone outside is doing testing that is blocked by this, I am not sure why this needs to block the beta directly. 17:54:27 the criteria are *general*, so how much work it takes to fix *one specific breach* is irrelevant to defining them 17:54:34 adamw: I was curious, mostly 17:54:44 since this isn't so much of a new issue 17:54:47 I could see there being problems with not being able to do internal testing that results in problems that result in slipage. 17:54:53 i'd actually prefer we didn't get an answer to avoiding improperly influencing the decision... 17:54:55 brunowolff: I don't think it really matters whether you are inside or outside. it won't work either way 17:55:13 adamw: fair enough, that makes sense 17:55:32 bcl: does anaconda team have a strong position on whether this should be beta or final functionality? 17:55:37 It matters, because inside we can use daily builds for testing. Outside people are going to be looking at the beta release images. 17:55:58 hell if I know. 17:56:13 Ask pjones :) 17:56:16 IIRC, the discusion about serial console install on anaconda-devel was pretty quiet 17:58:03 okay, we're not really getting any further here i don't think... 17:58:19 how about this: pschindl, can you resurrect your proposal and specifically say that we could do it for beta or final and we need to pick which 17:58:23 we'll punt this issue for a week 17:58:30 and bcl, please fix it so the problem goes away ;) 17:58:38 haha. we'll see. 17:59:21 proposed #agreed - 736993 - Does not hit beta release criteria as currently written, will propose changge to critera and re-visit next week 17:59:31 ack 17:59:32 s/changge/change 18:00:00 adamw: I will ask anaconda team again and send a new proposal 18:00:10 ack 18:00:18 ack 18:00:21 #agreed - 736993 - Does not hit beta release criteria as currently written, will propose change to critera and re-visit next week 18:00:31 #topic (754568) [abrt] gnome-shell-3.2.1-6.fc17: _int_free: Process /usr/bin/gnome-shell was killed by signal 11 (SIGSEGV) 18:00:35 #link http://bugzilla.redhat.com/show_bug.cgi?id=754568 18:00:36 Bug 754568: unspecified, unspecified, ---, ajax, NEW, [abrt] gnome-shell-3.2.1-6.fc17: _int_free: Process /usr/bin/gnome-shell was killed by signal 11 (SIGSEGV) 18:00:37 #info Proposed Blocker, NEW 18:01:17 so yeah, my justification for this is it pretty much makes a default VM unusable as shell will crash before you can do anything substantial. 18:01:20 does this also happen w/ VNC connection? 18:01:30 i haven't really tested but i think not 18:01:41 it's qxl/spice specific 18:01:47 qxl/spice is the default for f16 and f17 VMs, though, i believe. 18:01:57 I also have the notion that it happens just with spice/qxl 18:02:07 adamw: yes, it is the default 18:02:32 that would explain why I haven't hit it - I usually force VNC 18:03:45 any votes on blockery-ness? 18:04:55 +1. obviously. 18:05:03 Sorry I'm late 18:05:12 definitely +1 blocker, but I'm not completely sure whether Beta or Final 18:05:24 anyone else? I'm a little on the fence about beta since VNC works 18:05:36 Given the explanation that qxl/spice is the default vm environement, I think this fits the criteria for a beta blocker. 18:06:29 also, gnome-shell just restarts and you don't lose any data, right? 18:06:37 that happens in my case 18:06:39 * j_dulaney is looking at bug 18:06:44 kparal: not in mine 18:06:54 adamw: did it crash hard for you? 18:06:55 thanks to GNOME's 'clever' crash catcher, i always get the fail whale when it happens 18:07:03 i think shell crashes, respawns, crashes again, and that triggers the fail whake 18:07:07 so i'm dumped back out to gdm 18:07:22 if it was just shell restarting every so often it'd be less of a pain. 18:07:38 ok, that didn't happen to me 18:07:44 yeah, that sounds like beta blocker material 18:07:46 for me it just killed and restarted shell 18:08:05 kparal: how often have you hit it? 18:08:11 just want to see what the sample size is like 18:08:36 adamw: with spice/qxl I think you can hit it during 5 minutes 18:08:39 my estimate 18:08:42 or 10 minutes 18:09:08 * j_dulaney is leaning beta blocker 18:09:17 but I tried that just several times, I switched to VNC because I needed to report other bugs 18:09:46 kparal: but each time you saw it you just got a shell respawn and could carry on, no fail whale? 18:10:24 adamw: I don't remember any reset to gdm, just gdm respawn and you could go on. I *think* 18:10:31 I'm not totally sure on that 18:10:47 just gnome-shell respawns 18:10:50 typo 18:10:56 * j_dulaney doesn't recall hitting this in Alpha tests 18:11:23 j_dulaney: it's specific to testing in a KVM with spice/qxl 18:12:32 * kparal boots to F17, he thinks he has a reproducer 18:12:46 it sounds like we're mostly beta blocker 18:12:47 adamw: Explains why I didn't hit it 18:13:07 * j_dulaney doesn't use spice 18:13:18 kparal: my reproducer is just 'run shell in a VM for about two minutes' 18:13:23 it's not exactly a hard bug to trigger :) 18:14:13 ok I wanted to reproduce that but my display just exploded into a mess of colors 18:14:27 Explosions in the Sky? 18:14:47 http://imgur.com/56zZx 18:14:51 I don't want to download/install spice just try this. 18:14:56 proposed #agreed - 754568 - AcceptedBlocker - Since spice/qxl is the default interface for F16+ KVM, this was considered a common enough configuration to hit the beta VM criterion and the usability criterion from alpha 18:15:14 +1 18:15:37 ack 18:15:38 adamw: reproduced. sad face "Oh no!" 18:15:42 ack 18:15:46 kparal: right, that's the one. 18:15:54 adamw: that's the "fail whale"? 18:15:56 ack 18:15:57 #agreed - 754568 - AcceptedBlocker - Since spice/qxl is the default interface for F16+ KVM, this was considered a common enough configuration to hit the beta VM criterion (#15) and the usability criterion from alpha (#16) 18:15:59 kparal: sometimes you can alt-f4 that and get back to work, but doesn't appear to fly in this case. 18:16:05 kparal: yeah - the only button you have is 'log out', right? 18:16:09 yes 18:16:10 #topic (794690) PulseAudio fails to run if ConsoleKit is not present, and CK is not included currently in F17 desktop live image 18:16:14 #link http://bugzilla.redhat.com/show_bug.cgi?id=794690 18:16:15 Bug 794690: unspecified, unspecified, ---, lpoetter, ON_QA, PulseAudio fails to run if ConsoleKit is not present, and CK is not included currently in F17 desktop live image 18:16:16 #info Proposed Blocker, ON_QA 18:16:25 adamw: system settings -> display causes that 100% 18:17:07 If I don't get any more karma on this build, do you want me to push it to stable at three days (which will happen sometime today)? 18:17:14 unlike the last two, this seems like a pretty clear blocker 18:17:57 yeah, obvious +1. 18:18:12 brunowolff: i'll +1 it today most likely, just didn't get around to it yet 18:18:24 proposed #agreed - 794690 - AcceptedBlocker - In most cases, the installed system must be able to play back sound with gstreamer-based applications 18:18:30 ack 18:18:31 +1 18:18:36 ack 18:18:40 #agreed - 794690 - AcceptedBlocker - In most cases, the installed system must be able to play back sound with gstreamer-based applications 18:18:54 OK, that's all of the proposed blockers I had 18:19:30 on to the proposed NTH 18:19:42 #topic (794478) [abrt] kernel: BUG: soft lockup - CPU#0 stuck for 185s! [lxdm-binary:744] 18:19:44 Which is mine 18:19:45 #link http://bugzilla.redhat.com/show_bug.cgi?id=794478 18:19:46 Bug 794478: unspecified, unspecified, ---, cwickert, ASSIGNED, [abrt] kernel: BUG: soft lockup - CPU#0 stuck for 185s! [lxdm-binary:744] 18:19:48 #info Proposed NTH, ASSIGNED 18:19:53 I could use another +1 besides Adam's, since it is currently at just 1. (Without the default of 3 needed for auto push.) 18:20:09 brunowolff: I'll test post-meeting 18:20:20 Thanks! 18:20:47 so...this is 100% CPU use in lxdm? 18:20:53 j_dulaney: any consequences beyond that? 18:20:53 adamw: Indeed 18:21:03 No 18:21:05 does the usage persist once you've logged in? 18:21:11 Indeed 18:21:21 It makes it very difficult to get things done 18:21:23 ah, so if you have lxdm as your DM, you'll be pegged at 100% CPU all the time? 18:21:28 okay, i'm +1 nth on that for the lxde spin 18:21:29 Indeed 18:21:57 same here 18:22:01 +1 18:22:07 +1 NTH 18:22:07 * j_dulaney started hitting this way early in testing, and originally thought it was something else 18:22:26 thanks for the report 18:22:36 The fix is supposedly upstream 18:22:59 any suggestions on criterion? 18:23:19 Well, it makes the DE almost unusable 18:23:41 tflink: we don't need one for NTH. 18:23:45 proposed #agreed - 794478 - AcceptedNTH - hits the alpha criterion for usability on a non-blocking DE 18:23:49 ack 18:23:53 ack 18:23:57 ack 18:24:05 adamw: yeah, I was thinking of it as a blocker for LXDE, not an NTH 18:24:11 #agreed - 794478 - AcceptedNTH - hits the alpha criterion for usability on a non-blocking DE 18:24:29 and that's the only proposed NTH 18:24:35 #topic (742207) No usable bootloader option during a text mode f15->f16 upgrade 18:24:39 #link http://bugzilla.redhat.com/show_bug.cgi?id=742207 18:24:40 Bug 742207: high, unspecified, ---, anaconda-maint-list, NEW, No usable bootloader option during a text mode f15->f16 upgrade 18:24:41 #info Accepted Blocker, NEW 18:25:51 well, we kinda need anaconda team to work on this one 18:25:51 bcl! 18:26:28 LOL 18:27:35 there doesn't appear to have been any movement on this in the last month 18:27:46 hmm 18:29:56 oh, I see, I think. it isn't setting the default in the dialog. 18:30:19 bcl: do note the issues in comment #4 as well 18:31:05 for f16 the fix should just have been to do the same as done in graphical install - make the default 'install new bootloader' and grey out everything else but 'skip bootloader' 18:31:06 yeah. 18:31:15 I guess I'll take a look at this then. 18:31:17 for f17...it gets more complicated. ditto for the graphical path, of course. 18:31:23 and the other thing is you shouldn't be able to cancel the dialog 18:31:39 or cancelling it should pick the default option, not result in anaconda doing nothing at all about the bootloader 18:32:09 er, sorry, not 'cancel the dialog', but proceed without selecting an option 18:32:20 right, that may be similar to a bug I fixed for rhel 18:33:52