15:00:17 #startmeeting F-12Beta Blocker Bug Review meeting 15:00:17 Meeting started Fri Oct 9 15:00:17 2009 UTC. The chair is jlaska. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:00:17 Useful Commands: #action #agreed #halp #info #idea #link #topic. 15:00:53 #topic gathering minds ... 15:01:20 oh no! my mind! 15:01:32 that's right ... we've got it now 15:01:33 duuuhhhwwee? 15:01:37 * jlaska tightens lid on jar 15:01:58 lemme see if we can stir up a notting 15:02:31 not on irc ... thought I heard him earleir 15:02:33 earlier 15:03:00 might be too early for Oxf13 and poelcat? 15:03:08 I believe denise is present 15:03:19 yes, lurking .. 15:03:43 denise: howdy 15:03:50 hiya! 15:04:19 anyone else want to loan their mind or say hello to zodbot? 15:05:40 well, let's get started and we can pull in folks as needed 15:05:56 The usual procedure here ... I'm going to walk through https://bugzilla.redhat.com/showdependencytree.cgi?id=F12Beta&hide_resolved=1 15:06:06 the list has 5 bugs on it presently 15:06:16 starting with ... 15:06:19 #topic https://bugzilla.redhat.com/show_bug.cgi?id=517260 15:06:21 Bug 517260: medium, low, ---, dlehman, ASSIGNED, liveinst fails at partitioning screen 15:06:48 dlehman posted a patch to anaconda-devel-list to address this issue https://www.redhat.com/archives/anaconda-devel-list/2009-October/msg00163.html 15:07:08 I was trying to test it for him, but have unfortunately not been able to reproduce the underlying issue (since the storage test day last week) 15:07:23 he's just posted a new comment explaining how to reproduce 15:07:33 #23 15:08:00 yeah, we spoke about it before the meeting ... 15:08:09 that proceedure is not reproducing the issue 15:08:24 ah :/ 15:08:25 dlehman noted that some other changes in the UI might have worked around the underlying problem 15:08:39 so .. I'm inclined to push this off until post-beta 15:08:39 are there any other known sufferers at this point? 15:08:50 I spoke to harald who also hit this issue ... and we tried his reproducer 15:08:53 no luck 15:09:01 but we were running into another bug that I added for review (down the list) 15:09:56 denise, dunno if you have any thoughts here ... the choice would be to take that patch post-beta or now 15:10:03 (or not at all I guess 15:10:05 ) 15:10:17 but kind of disconcerting that we weren't able to reproduce the bug anymore 15:10:27 good from a user standpoint though :) 15:10:43 jlaska, as long as you take it! 15:11:05 #info jlaska unable to reproduce 517260 using the procedure posted to the bugzilla 15:11:16 brb, call of nature 15:11:35 then I'd vote for post-beta (under the less change banner) 15:11:39 any objections? 15:12:07 +1 15:12:24 alrighty ... I'll go ahead and change the bug to block F12Blocker 15:13:27 #agreed 517260 will be moved to F12Blocker and accepted post-beta 15:13:36 #topic https://bugzilla.redhat.com/show_bug.cgi?id=526208 15:13:38 Bug 526208: low, low, ---, mclasen, ASSIGNED, preupgrade failed from old release(f10, f11) 15:14:11 erf 15:14:22 i'm not a huge fan of post-beta anaconda patches 15:14:22 who has the latest on this one? 15:14:22 especially for things we are not sure are broken 15:14:29 it's not an anaconda bug. 15:14:38 wwoods: i'm talking about 517260 sorry 15:14:40 it's a bug in gtk2/preupgrade in F11. 15:14:43 since i was away when the vote happened :) 15:14:53 gotcha, sorry! 15:15:06 beta is going to be the last point at which we get really wide-based installer testing 15:15:16 any patch we throw into the installer after that is something of a wildcard 15:15:24 anyway there are gross workarounds (preupgrade-cli, downgrade gtk2) 15:15:52 adamw: I'll just back to that bug in a sec then ... 15:15:55 * poelcat lurking, but at another meeting 15:15:58 let's just finish out the preupgrade bz 15:16:08 s/just/jump/ 15:16:22 k, sorry 15:16:27 np np 15:16:40 wwoods: so we have some ugly workarounds? 15:16:57 and as discussed previously, preupgrade can be fixed in an F11 updates push after Beta 15:17:08 so it's probably not worth delaying the release over 15:17:11 err, delaying Beta 15:17:27 how close does that one feel to having a real fix 15:17:35 is that days or weeks away 15:18:03 yeah, the workarounds are not good - downgrading gtk2 is nasty, preupgrade-cli is a totally different user experience.. or you just just wait patently and only watch the progrss via the status icon 15:18:09 I have no idea 15:18:16 #info "as discussed previously, preupgrade can be fixed in an F11 updates push after Beta" -wwoods 15:18:30 the only comment I've got is "rewrite to use a mainloop" which is a fairly major refactoring effort 15:18:45 and no actual assertion that "this will definitely fix the problem because ..." 15:19:15 I'm gonna take some time today to actually try to trace the problem 15:19:45 wwoods: okay 15:19:48 I feel like it's probably a pretty simple fix - just need to find someone who knows what the fix is 15:19:51 wwoods: i think that looked like a red herring from the bug discussion 15:20:06 mclasen's last comment suggests he didn't think your code had a mainloop at all 15:20:44 would it help to have mclasen here? 15:21:50 i don't think so - like i said he kinda took himself out of being a useful analyst of the problem :) it looks to me like we need a different expert, heh 15:22:08 is skvidal plugged in on this one still 15:22:22 yeah, but neither of us are pygtk experts 15:22:33 ? 15:22:41 what's up? 15:22:42 it's kind of taken a turn since it was discovered to be a gtk/pygtk bug - it looks like it needs the input of someone who's knowledgeable in that area 15:22:46 rjune: ? 15:22:48 I'm no expert, but I'm familiar with pygtk 15:23:03 rjune: https://bugzilla.redhat.com/show_bug.cgi?id=526208 15:23:04 Bug 526208: low, low, ---, mclasen, ASSIGNED, preupgrade failed from old release(f10, f11) 15:24:05 this is going from f10/f11 to f12? 15:24:10 yes. 15:24:37 is it a bug in the *old* preupgrade? 15:24:53 that would be the next question. is it fixed already? 15:25:06 no. it's a bug in gtk or pygtk. 15:25:14 adamw: but the old version 15:25:19 that is in no way clear to me... 15:25:26 old version of *what*? 15:25:35 it's an error running preupgrade on f10/f11, right? 15:25:38 preupgrade runs on the (unupgraded) host system 15:25:41 notting: the bug is in the f10/f11 package base, yes, as far as we know. 15:25:47 it doesn't run on the target at all 15:25:50 so, there is nothing we can possibly change in the beta to fix it. ergo, it's not a beta blocker. 15:25:56 mclasen: if the bug is in the version of gtk / pygtk installed in f10 and f11, *BUT* there is a newer version in f12, the bug may be fixed and it's a simple backport 15:26:07 notting: we went through that at the last meeting. 15:26:33 notting: it is possible for us to refuse to release the beta unless a bug which is not technically in the beta but relates to it is fixed. 15:26:48 rjune_wrk: there is no simple backporting between gtk 2.18 and 2.16 15:27:09 notting: we can do that either by setting it as a beta blocker and remember it doesn't block us building the beta, just releasing it; or not set it as a blocker and remember that we shouldn't release until it's fixed. either depends on us being people with brains. it didn't seem that important which we picked. 15:27:37 rjune: we can't tell if the problem happens when preupgrading from f12 as there's nothing to preupgrade *to*, yet. 15:27:39 mclasen: ok so it's not simple. it's still a backport and the bug is likely documented 15:27:53 adamw: so this is from f10 to f11 ? 15:27:56 rjune_wrk: I don't know where you take that knowledge from 15:27:56 no. from f11 to f12. 15:28:00 not from f10 or f11 to f12 15:28:14 or possibly f10 to f12, i think, but we're focussing on the f11 case afaik. 15:28:32 ok. 15:28:34 the point is we don't know if the code in f12 also has this problem because you can't do a preupgrade from f12 to anything else, yet. there's nowhere to go. 15:28:39 I think the first step toward identifying the problem would be to narrow 'between 2.16.0 and 2.16.6 to a single version step 15:28:44 we've got a reliable reproducer with F11; haven't tried to confirm it with F10 yet 15:28:50 ok. 15:29:06 if there's any known changes in behavior between those gtk versions I'd really like to know about it 15:29:07 #info "I think the first step toward identifying the problem would be to narrow 'between 2.16.0 and 2.16.6 to a single version step" -mclasen 15:29:10 changelog the best place to look for that? 15:29:33 i think the idea would be just to test with each intermediate step and see which breaks 15:29:44 assuming we can pull packages from koji, or just rebuild them 15:29:46 I don't think we packaged every intermediate step 15:29:48 wwoods: not sure what you are after; of course there are changes, otherwise we wouldn't release a new version... 15:30:19 mclasen: right, but specifically I'm looking for changes that involve the way gtk.events_pending() and gtk.main_iteration() would work 15:30:23 since AFAICT that's what's failing 15:31:03 wwoods: there's no changes in that area 15:31:04 it has a Very Long Running Callback where we just manually run the event queue rather than returning to the mainloop 15:31:04 http://git.gnome.org/cgit/gtk+/log/?h=gtk-2-16 15:31:23 is there a smaller simpler test script as a reproducer? 15:31:26 to avoid reinstalls etc... 15:31:26 not yet 15:31:42 but I've got a couple F11 VMs that I've been cloning and messing with 15:31:49 ah good call 15:32:29 okay, to summarize ... 15:32:55 we still need to isolate root cause, to do that mclasen recommended testing against certain versions 15:33:15 and I'm hearing from adamw, that this should stay on the list for now 15:33:26 disagree 15:33:28 objections/misreads? 15:33:34 jlaska: no, that's not my position 15:33:52 jlaska: was just explaining to notting that _in theory_ blocker bugs don't have to be in the f12 package base 15:33:55 I agree with the point that technically something can be a release blocker despite it not being part of the release 15:34:00 whether this is one of those cases isn't the same point 15:34:05 adamw: sure 15:34:17 And we also made the point that this bug is a *release* blocker which is, technically, distinct from a *compose* blocker 15:34:29 but that's kind of just academic 15:34:37 it feels kinda on the bubble to me as to whether we consider it a beta release blocker or not 15:34:43 I vote we move the bug to F12Blocker 15:34:56 i'm abstaining :) 15:34:58 document the workarounds and push a fix ASAP 15:35:07 the fix can be pushed post-Beta 15:35:20 depends on if you want to test upgrades with the beta 15:35:29 and if you can live with a documented workaround for now 15:35:48 mclasen: as noted, since the fix would go into f11 not f12, once it's fixed people would still be able to test with the beta 15:36:03 sure 15:36:06 we definitely want to test upgrades with the beta, but I don't think we need that *to the exclusion of everything else* 15:36:06 but of course mostly people are likely to test around release time... 15:36:09 you can still upgrade with media / boot.iso 15:36:42 plus - it still *WORKS* is the thing 15:36:49 let's push out a fix that pops up a window ... "this will take a while and won't be responsive" :) 15:36:53 you can just minimize the window and walk away and it'll work exactly as expected 15:36:59 and the status icon even provides correct status 15:37:18 if we knew how to update the UI to pop up a window, we wouldn't have this problem 15:37:24 =) 15:37:30 wwoods: heh 15:38:14 alrighty ... so I agree, this shouldn't block compose, but I think we've got ~3-4 work days where we can still chase this issue down and have a fix in time for beta 15:38:31 I'll put other things aside for this - at least for a day or two 15:38:39 would more people help solve this ... or wwoods are you comfortable going to town on those package versions? 15:39:09 adamw: common_bugs still alive and well? 15:39:19 one thing that _might_ be related is e.g. this: http://git.gnome.org/cgit/gtk+/commit/?h=gtk-2-16&id=52325ccd669ebd24de873bb0949d68d6dad17fb0 15:39:41 if preupgrade previously relied on getting random events to pump the event loop... 15:40:00 jlaska: i'll be updating it soon, want to get an accurate snapshot of what will/won't be broken in the beta :) 15:40:08 adamw: agreed :) 15:40:12 this'll definitely go in there if it's still broken at release time 15:41:03 I think I'd prefer to keep this on the list until beta goes public 15:41:22 and see about trying to line up help to isolate the problem 15:42:00 which bug this blocks seems like semantics at this point ... we are trying to work the issue for beta 15:42:08 but it doesn't block beta compose 15:42:27 while we are at least working it for beta, let's just keep it on the list? 15:42:40 sure, as we said last week, just relies on us having brains to remember the situation :) 15:42:45 right on 15:43:24 mclasen: hrm, maybe it was! so maybe events_pending() is always returning false/[] 15:43:33 okay ... folks ready to move on (or back)? 15:43:38 sure 15:43:41 we aren't actually firing off any events.. 15:43:46 yeah please do, sorry 15:44:17 #agreed wwoods and mclasen will continue to identify root cause on 526208 with the goal of a new F-11 update in time for F-12-Beta 15:44:22 wwoods: normally, you would expect some queue_draw calls, or such, or just setting progress values will cause the progressbar to do that 15:44:26 adamw: ready to jump back to first bz? 15:44:34 #topic https://bugzilla.redhat.com/show_bug.cgi?id=517260 15:44:35 Bug 517260: medium, low, ---, dlehman, ASSIGNED, liveinst fails at partitioning screen 15:44:51 yeah...i just wanted to note that i'm leery about adding patches post-beta to 'fix' things that we can't reproduce as being broken any more 15:45:03 Spoke to dlehman ... who suggested that if we take this fix for Beta ... we have to get a specific set of test results to confirm this isn't introducing regressions 15:45:15 adamw: you're point is valid 15:45:18 your point 15:45:45 regression testing is good but by the nature of the beast we can't test in as wide a range of scenarios as the beta will be tested 15:46:08 if the anaconda guys really think it's ok to put this in then i guess i'll live with it. really i just want my leeriness noted so i can say 'i told you so' if it all goes south =) 15:46:42 hey, we're all in this together :) 15:47:07 so ... any changes to the plan here? ... we can take it for beta ... but will need to scramble on validating the patch 15:47:07 * mclasen points out that it is somewhat disingenuous to be very adamant about not taking patches between beta and final when we are just opening the floodgates again after final 15:47:37 mclasen: eh? why? 15:47:58 you can break stuff in rawhide after we release f12. that's fine. breaking stuff is what rawhide's there for... 15:48:36 adamw: wanna help test this patch with me? 15:48:44 adamw: I'm talking about opening the f12 updates floodgates... 15:48:54 or if we can get help from others ... we can get confidence in the fix and take it for beta 15:49:04 mclasen: oh. this is an anaconda issue. anaconda doesn't get updated after release. 15:49:11 right 15:49:12 jlaska: i can do what i can do, but all i can do at present is virtual installs 15:49:17 anaconda is different, ignore me 15:49:21 jlaska: i have no spare hardware for to-the-metal installs :/ 15:49:29 adamw: hey, I offered :) 15:49:39 alright ... so I'll take an action to work this w/ dlehman 15:49:41 yeah, maybe i should expense a couple of spare hard disks 15:50:07 if we can get confidence that this won't invalidate all of the beta testing so far ... we'll take it 15:50:15 jlaska: anyway, my personal preference would be to have it in the beta so it gets wider testing, but do override me if you think i'm wrong. =) 15:50:27 nope, I agree with that 15:50:35 but want to test it *before* it lands in the beta 15:51:00 #action jlaska will work w/ dlehman to verify the bug#517260 patch before it hits next anaconda 15:51:00 sure. i can definitely do a couple of virt installs with it to help test. i'll cc myself on the bug to stay in the loop. 15:51:01 Bug https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=517260 medium, low, ---, dlehman, ASSIGNED, liveinst fails at partitioning screen 15:51:15 okay moving on ... 15:51:17 #topic https://bugzilla.redhat.com/show_bug.cgi?id=526320 15:51:18 Bug 526320: medium, low, ---, jkeating, MODIFIED, ppc64.img and ppc32.img missing from tree 15:51:32 I moved this from CLOSED -> MODIFIED today since the issue doesn't seem fixed from what I can tell 15:51:36 is Oxf13 around? 15:52:09 sure enough, it might have just needed the newer anaconda build in the compose 15:52:20 'cause it seems to be here for todays recently finished compose 15:52:23 http://kojipkgs.fedoraproject.org/mash/rawhide-20091009/development/ppc/os/images/netboot/ 15:52:26 nice, that was easy 15:53:00 I just closed that bug so it's now off the list 15:53:06 next up ... 15:53:15 #topic https://bugzilla.redhat.com/show_bug.cgi?id=526899 15:53:16 Bug 526899: medium, low, ---, anaconda-maint-list, NEW, Encrypted partitions has "Unknown" type in table and ext4 in editor 15:53:31 this out of greenlion1's testing from the anaconda storage test day 15:53:40 I added this for review during this meeting 15:53:47 yep 15:53:50 it's on livecd 15:54:13 the use case seems to be that using the live image, encrypted partitions don't get a mount point anymore 15:54:24 so the only encrypted isntalls you can do are autopart+encrypted ... it seems no manual encrypted partitioning 15:54:51 see screenshot posted by greenlion1 - https://bugzilla.redhat.com/attachment.cgi?id=363477 15:55:20 this is a regression from the Beta test compose ... which is why I bumped this into the meeting requesting blocker 15:55:40 denise: what's your take? 15:56:11 dlehman is on it, but not a lot to report 15:56:39 jlaska: I'm somewhat around now 15:56:43 jlaska: still trying to do the breakfast thing 15:56:51 Oxf13: mornin' :) 15:56:52 could document around it for beta if we had to i guess, but this feels like one we should fix to get the testing 15:57:37 what's the bug here? 15:58:08 Oxf13: we already got past the one jlaska pinged you for :) 15:58:08 Oxf13: seems like we can no longer create encrypted partitions in the manual disk partition screen 15:58:08 Oxf13: now we're on https://bugzilla.redhat.com/show_bug.cgi?id=526899 15:58:08 Bug 526899: medium, low, ---, anaconda-maint-list, NEW, Encrypted partitions has "Unknown" type in table and ext4 in editor 15:59:19 any other opinions/concerns on this issue? 16:00:02 hrm. 16:00:07 let me preface something here. 16:00:13 We have a high chance of getting into RC phase today 16:00:13 uh oh :) 16:00:26 I think the last of the blockers were "fixed" by the anaconda build I tagged last night 16:00:37 so lets be really sure something is a blocker before we cause a slip 16:00:48 right on, that's why we're here 16:02:03 but I don't think today's rawhide has landed yet, so there may be surprises :/ 16:02:14 Oxf13: I built a live image this morning from rawhide-static 16:02:21 k 16:02:23 that's where I'm seeing this issue 16:02:27 k 16:02:43 I can deal with a new anaconda build on the side to enter RC phase 16:02:50 that's easy to manage. 16:02:54 anything more gets less so 16:04:03 are you in agreement on this bug staying on the list and dlehman continues to investigate? 16:04:47 * jlaska reconfirms ... there is something unpleasant going on with the partition detail screen 16:05:16 yeah 16:05:25 I think it would be crappy to go out like this 16:05:31 unfortunate I know ... but I ... yeah exactly 16:06:05 #agreed 526899 will stay on beta blocker awaiting review from dlehman 16:06:10 okay ... next up ... 16:06:15 #topic https://bugzilla.redhat.com/show_bug.cgi?id=528077 16:06:16 Bug 528077: high, low, ---, rstrode, NEW, No graphical boot (verbose text boot only) on ix86 live images 20091007+ 16:06:27 adamw: you want to take this? 16:07:00 well, it's pretty straightforward 16:07:09 you think it may be fixed with today's builds so i'll check it out 16:07:25 confirming on _real_ hardware now 16:08:15 the bug is just as the subject says - 20091007 and 20091008 i686 live images gave verbose text boot, on all systems tested (by me and jlaska) 16:08:21 having a non-functioning plymouth seems like a no brainer 16:08:25 but the matching x86-64 images gave nice working graphical boot 16:08:42 * mclasen welcomes halfline 16:08:56 i'll test with 20091009 images when there are some 16:09:03 jlaska's using a homebrew image 16:09:22 adamw: using the test day instructions (https://fedoraproject.org/wiki/QA/Test_Days/Live_Image) 16:10:03 any objections to not keeping this on the list? 16:10:17 rather ... anyone suggesting we remove this from the F12Beta list 16:10:54 ugh... 16:10:57 i chimed on the bug report 16:11:03 that would be tougher to slip in if it wasn't already fixed 16:11:33 it's pretty hard for me to imagine a plausible explanation for this bug 16:11:47 halfline: thanks, will update you later 16:11:54 I seem to remember getting text plugin booting live image I made yesterday in kvm, i686 16:12:17 note you don't just get the text progress bar - you actually get a full verbose text boot 16:12:27 adamw: w/modeset, though, right? 16:12:27 as if you removed 'rhgb quiet' from the parameters 16:12:29 yes 16:12:36 modeset kicks in 16:13:00 * adamw didn't actually check what the default kernel parameters were...wonder if it was as simple as they got screwed somehow... 16:13:12 that could be 16:13:22 anyway, will provide updated results from 20091009 later today 16:13:22 hrm. 16:13:25 the thing is...the fallback splash by default is "text" not "details" 16:13:33 actually I think I see this on yesterday's image I built in kvm 16:13:36 so if there was some failure, i'd expect to see animated bars 16:13:42 right, that's what made it seem odd to me. 16:13:50 but if jlaska doesn't see it today, maybe it fixed itself. 16:14:32 so, let's leave this on the list and follow-up with more testing this afternoon? 16:14:38 k 16:14:59 yeah 16:15:10 i have a gdm fix i'd like to get in for the beta if possible 16:15:12 rawhide is still doing the rsync, should be done soon 16:15:17 fixes the "other" item 16:15:18 halfline: erm... 16:15:19 #agreed retest 528077 on live images built today and provide feedback in bz 16:15:47 okay, lemme reload the F12Beta page ... 16:16:16 * greenlion1 has added one bug there at start of meeting... 16:16:17 we've got a new bug added to the list 16:16:43 halfline: we'll talk to greenlion1's bug, then come to yours 16:16:48 #topic https://bugzilla.redhat.com/show_bug.cgi?id=498026 16:16:50 Bug 498026: medium, low, ---, anaconda-maint-list, NEW, RuntimeError: Returning partitions to state prior to edit failed 16:17:19 I've hit in this many times during latest test day 16:17:44 looks like so is IBM 16:17:50 while this is bad, I don't necessarily think it's a beta blocker. 16:17:51 * jlaska reading https://bugzilla.redhat.com/show_bug.cgi?id=498026#c17 16:17:52 Bug 498026: medium, low, ---, anaconda-maint-list, NEW, RuntimeError: Returning partitions to state prior to edit failed 16:18:01 basically, if all disk is filled with partitions, most operations will result in crash 16:18:14 greenlion: any work arounds? 16:18:22 it is hard to create any complex partition layout 16:18:34 greenlion: so you're getting it without trying to revert any previous edits? 16:18:52 jlaska, only if you don't fill up fully disk 16:19:14 greenlion: comment#17 has a reproducer that seems to be intentionally validating an error case 16:19:32 Oxf13, not only revert, but when trying to edit partitions too 16:19:42 4. Increase the size of the partition and press OK. 16:19:42 * This should give an error of saying " not enough free space on disk". Which 16:19:43 5. Now click on 'OK' for the error. This will crash the anaconda. 16:19:45 is expected. 16:19:48 16:20:00 crash is expected? 16:20:14 no, the dialog was expected 16:20:16 afterwards, it crashed 16:20:20 the is expected line got out of sync 16:20:29 so basically there is a crash in the 'out of space' handler routine 16:20:34 that might be easier to find/fix 16:20:47 it's even worse than bug with encryption on liveinst - there it doesn't crash 16:21:30 just reproduced using that procedure 16:21:53 but that procedure doesn't seem like a common use case ... is this encountered some other way 16:22:16 it's not common in that normally you'd reduce the size of something before increasing the size of something else 16:22:20 * greenlion will try to write more common use case 16:22:22 but I can see this being hit 16:22:42 there is no need to resize partitions to crash it in this way 16:22:52 something disruptive was introduced into anaconda partitioning recently 16:24:14 I'd agree with keeping this if the failure case didn't involve negative testing -- a failure while testing whether anaconda let's you create a partition that's larger than your free space 16:24:22 Oxf13: your take? 16:24:24 dlehman says that he is pulling together an F12 tree to test a fix for this one 16:24:50 denise: geez, that was fast 16:24:55 he's good ;-) 16:25:02 jlaska: from looking at it, I think the error can be isolated pretty easily, since it appears to be in the routine for when you have not enough free space 16:25:08 denise: sounds like we have a few folks reproducing this as well if he needs help 16:25:17 if it crashed from finding out you had not enough, that might be worse, but this is a crash in handling the fact 16:25:18 ok will let him know 16:25:52 okay, I'm hearing this stays on the list from Oxf13 and greenlion 16:25:59 is that right? 16:26:13 i haven't experienced this bug 16:26:19 jlaska, dlehman will be in touch 16:26:24 denise: thx 16:26:35 but my only question would be, are we sure the bug greenlion is talking about, and the crash with the specific procedure outlined above, are both the _same_ bug? 16:26:39 adamw: I haven't either ... until I just tested the steps in comment#17 16:26:49 jlaska: that was just a preface to my next remark =) 16:27:04 ;) 16:27:15 adamw, good question. I guess I need to reproduce and compare traceback? 16:27:23 i think so, yeah 16:27:31 greenlion: did anaconda automatically cc you to that? 16:27:58 jlaska, I think, I've found it in bugzilla and cc'ed to in myself 16:28:37 adamw: given that every reproducer seems to involve hitting the "you don't have enough space for this action" routine, I'd imagine they're the same bug 16:29:33 Oxf13: ok 16:29:43 greenlion: if you can confirm, that would help too 16:30:26 ok 16:30:42 alright, so this is staying on the list then 16:31:08 any objections? 16:32:08 alrighty ... it stays 16:32:16 #agreed 498026 will remain on list - dlehman will have a patch available soon for verification 16:32:26 that's it for my list 16:32:33 halfline: you had a bug to review? 16:32:46 jlaska: yea bug 527920 16:32:47 Bug https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=527920 high, low, ---, jmccann, MODIFIED, gdm doesn't show user list and crashes - unable to login 16:32:52 #topic https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=527920 16:32:55 Bug 527920: high, low, ---, jmccann, MODIFIED, gdm doesn't show user list and crashes - unable to login 16:32:58 that's for folks with LDAP right? 16:33:06 well it's for everyone 16:33:09 it just affects them worse 16:33:17 the "Other" item is absent right now 16:33:25 which means you can only log into users that show up in the list 16:33:27 I see. 16:33:46 fix is already built 16:33:48 lots of gdm packages :/ 16:33:59 what's the use case for logging in as a user that isn't in the list? 16:34:06