17:01:14 <tflink> #startmeeting f18final-blocker-review-2
17:01:14 <zodbot> Meeting started Wed Dec  5 17:01:14 2012 UTC.  The chair is tflink. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:01:14 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
17:01:14 <tflink> #meetingname f18final-blocker-review-2
17:01:14 <zodbot> The meeting name has been set to 'f18final-blocker-review-2'
17:01:14 <tflink> #topic Roll Call
17:01:25 <tflink> Who all's ready for some blocker review fun time?
17:01:31 * satellit listening
17:01:52 * jreznik is here to have a lot of fun!
17:02:01 * pschindl is here
17:02:05 * kparal here
17:02:31 * Viking-Ice still thinks this belongs in QA or someother channel...
17:03:16 * adamw is here, dealing with postie
17:03:46 <jreznik> Viking-Ice: /me proposed #fedora-meeting-X where X > 2 but... it's standard but less people available there
17:04:36 <kparal> it's being discussed on the list, let's keep it there or at open floor
17:04:41 <adamw> we can keep trying stuff
17:05:10 <Viking-Ice> bugzapper is dead process no need to keep this channel alive...
17:06:03 <jreznik> well, let's start now but I agree with Viking-Ice... -> discuss on-list
17:06:51 <tflink> yeah, I'm not set on this as a final solution. it was just easy
17:07:16 <tflink> ok, I think we have enough people to get started with the always exciting boilerplate
17:07:20 <tflink> #topic Introduction
17:07:32 <tflink> Why are we here?
17:07:33 <tflink> #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:42 <tflink> #info We'll be following the process outlined at:
17:07:42 <tflink> #link https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting
17:07:48 <tflink> #info The bugs up for review today are available at:
17:07:48 <tflink> #link http://qa.fedoraproject.org/blockerbugs/current
17:07:54 <tflink> #info The criteria for release blocking bugs can be found at:
17:07:54 <tflink> #link https://fedoraproject.org/wiki/Fedora_18_Alpha_Release_Criteria
17:07:54 <tflink> #link https://fedoraproject.org/wiki/Fedora_18_Beta_Release_Criteria
17:07:54 <tflink> #link https://fedoraproject.org/wiki/Fedora_18_Final_Release_Criteria
17:08:08 <tflink> #info The current count of blocker and NTH bugs is:
17:08:17 <tflink> #info 25 Proposed Blockers
17:08:18 <tflink> #info 15 Accepted Blockers
17:08:18 <tflink> #info 23 Proposed NTH
17:08:18 <tflink> #info 5 Accepted NTH
17:08:31 <adamw> you cleaned up all the ones that got on-list votes, right?
17:08:34 <adamw> er, on-bug
17:08:40 <tflink> yeah, I did that this morning
17:09:10 <tflink> I've highlighted bugs that are ready for discussion, so I'm planning to start with that list
17:09:31 <tflink> #link#link http://tflink.fedorapeople.org/blockerbugs/sorted/sortedBlockers.html
17:09:34 <tflink> ha
17:09:38 <tflink> #undo
17:09:38 <zodbot> Removing item from minutes: <MeetBot.items.Link object at 0x233459d0>
17:09:47 <tflink> #link http://tflink.fedorapeople.org/blockerbugs/sorted/sortedBlockers.html
17:09:52 <jreznik> proposed blockers list now fits to my screen :)
17:09:58 <tflink> #info 12 proposed blockers highlighted for discussion
17:10:17 <tflink> if there are no objections, I'm planning to start with those
17:10:37 * adamw opening his presents
17:10:40 <tflink> #topic (851265) booting a wrong arch results in a black screen
17:10:40 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=851265
17:10:40 <tflink> #info Proposed Blocker, grub2, NEW
17:10:42 <buggbot> Bug 851265: unspecified, unspecified, ---, pjones, NEW , booting a wrong arch results in a black screen
17:11:38 <tflink> bz is slow today
17:11:43 <kparal> very slow
17:12:22 <tflink> the issue here, as I understand it, is that there is no warning if you try to boot an x86_64 image on an i686 only system
17:12:27 <jreznik> yep, it took ages to load bug
17:12:33 <jreznik> tflink: yep
17:12:55 <adamw> bz's been slow for a while...
17:12:56 <kparal> it just presents black screen and does nothing
17:13:10 <jreznik> btw. for multi dvds - this is not a problem - these are dual-arch
17:13:14 <adamw> seems a bit doctor-it-hurts-y
17:13:22 <Viking-Ice> +1 nth
17:13:30 <tflink> yeah but it would be nice to have some sort of warning
17:13:36 <kparal> adamw: sorry, don't know what that means
17:13:47 <adamw> oh, i thought it had been explained on the list
17:13:47 <Viking-Ice> it should check arch and error out asap
17:13:51 <tflink> I suspect this might be related to our use of smoke images as of late and the fact that I'm only building x86_64
17:14:06 <jreznik> nth and make sure there's warning as I don't think booting something on unsupported arch should be a blocker
17:14:06 <adamw> the joke goes "Doctor! It hurts when I jump up and down ten times!"
17:14:10 <kparal> I'm not +1 here for sure, but I wanted to have it discussed in case someone has other opinions
17:14:12 <adamw> "Well, don't do that then."
17:14:13 <Viking-Ice> arm is the new i386 :)
17:14:22 <kparal> I'm +0/+1 more or less
17:14:31 <pschindl> +1 nth
17:14:32 <adamw> Viking-Ice: there is a check, but it's getting hidden, apparently
17:14:37 <adamw> +1 nth if the fix is simple
17:14:50 <tflink> sounds like we're mostly -1/+1
17:14:53 <jreznik> -1/+1 (in case of simple check)
17:15:00 <adamw> -1 blocker
17:15:15 <jreznik> as do we want to block on arm image not booting on i386? (yeah, extreme case but)
17:15:39 <akshayvyas> -1 blocker
17:16:02 <tflink> proposed #agreed 851265 - RejectedBlocker, AcceptedNTH - While this is inconvenient, it is easily workaround-able (don't boot an image that your arch can't support) it is rejected as a blocker for F18 final. However, some warning message would be nice and a tested fix would be considered past freeze.
17:16:05 <kparal> jreznik: the issue is not in "not booting", that's not a good comparison
17:16:13 <kparal> ack
17:16:16 <pschindl> ack
17:16:20 <akshayvyas> ack
17:16:34 <jreznik> ack
17:16:37 <tflink> #agreed 851265 - RejectedBlocker, AcceptedNTH - While this is inconvenient, it is easily workaround-able (don't boot an image that your arch can't support) it is rejected as a blocker for F18 final. However, some warning message would be nice and a tested fix would be considered past freeze.
17:16:42 <jreznik> kparal: as I said - extreme comparison
17:16:42 <tflink> #topic (873220) dracut ignores /etc/modprobe.d blacklist
17:16:45 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=873220
17:16:47 <buggbot> Bug 873220: unspecified, unspecified, ---, dracut-maint, NEW , dracut ignores /etc/modprobe.d blacklist
17:16:47 <tflink> #info Proposed Blocker, dracut, NEW
17:17:39 <tflink> the reported issue is that dracut is ignoring kernel module blacklists
17:18:06 <tflink> one of the more obvious symptoms of this is if you blacklist nouveau or radeon so that you can use nvidia or fglrx
17:18:07 <Viking-Ice> +1 nth
17:18:15 <tflink> this is already accepted nth
17:18:27 <tflink> but the blocker votes in bug were pretty inconclusive
17:18:28 <Viking-Ice> does not count I did not vote ;)
17:18:59 <kparal> so nouveau/radeon can't be blacklisted at this time?
17:19:06 <kparal> -> nvidia/fglrx can't be used?
17:19:09 <tflink> not through the rd.blacklist
17:19:11 * jreznik is more -1 blocker - as how far nvidia/fglrx is something we support... and as far as I understand it should be fixable by update
17:19:11 <Viking-Ice> btw why are we voting on something that does not have input from the maintainer ( harald ) ;)
17:19:16 <jreznik> or manually
17:19:40 <tflink> Viking-Ice: I believe he proposed it
17:20:10 <jreznik> tflink: yep but seems he does not understand the process
17:20:16 <Viking-Ice> tflink, not seeing harald anywhere in that bug report
17:20:16 <akshayvyas> i am +1 nth
17:20:24 <jreznik> as he proposed bugs "I'd like to work on for F18"
17:20:37 <tflink> Viking-Ice: he's in the history as marking this as blocking F18 final
17:20:54 <jreznik> Viking-Ice: harald@redhat.com 	2012-11-29 10:33:47 EST        Blocks 		752661
17:21:01 <adamw> yeah, that's a crappy reason.
17:21:22 <kparal> I think this doesn't really have to be a blocker, can be fixed afterwards. and opensource drivers should work, so at least basic usage (if not gaming) is possible
17:21:25 <jreznik> and I really think he just misunderstood the process - to be wishlist
17:21:25 <tflink> he proposed 5 or so blockers (last week, I think)
17:21:36 <Viking-Ice> great!
17:21:52 <jreznik> kparal: +1
17:21:55 <tflink> IIRC, none of which had justifications or criteria violations
17:21:57 <Viking-Ice> I think we all agreed that the aggreed nth is accepted hence let's move on to next
17:22:01 <jreznik> so I'm defintely -1/+1
17:22:23 <jreznik> tflink: indeed - he used it as wishlist/todo-list for f18
17:22:24 <adamw> i'm with viking - we've gone with nth, it seems impossible to determine blocker
17:22:38 <tflink> it is?
17:22:53 <adamw> i guess we could do -1.
17:23:00 <jreznik> adamw: yep
17:23:04 <adamw> though i only see one -1 vote.
17:23:06 <tflink> we could punt, I suppose
17:23:14 <Viking-Ice> this can be fixed via update why punt
17:23:16 <jreznik> tflink: what would "punt" help here?
17:23:35 <jreznik> Viking-Ice: could you just -1 blocker to move on :)
17:23:40 <tflink> if it's impossible to make a decision due to votes, what other choice do we have?
17:23:50 <kparal> tflink: everyone voted -1 blocker
17:23:51 <tflink> ignore it and hope it goes away?
17:24:25 <Viking-Ice> jreznik, - blocker + nth
17:24:28 <tflink> I see -2/+1 blocker including in-bug votes
17:24:39 <tflink> unless I'm missing something
17:24:39 <kparal> -1 from me
17:24:44 <adamw> jreznik: the info i requested may show up
17:24:49 <akshayvyas> -1 from me too
17:24:53 <adamw> on anything specific that it breaks
17:24:55 <kparal> tflink: I don't see any +1
17:25:05 <adamw> i'm okay with -1 at this point, we could re-propose if info arrives, i guess.
17:25:05 <tflink> c#8
17:25:19 <jreznik> adamw: ok
17:26:18 <tflink> proposed #agreed 873220 - RejectedBlocker - Given our understanding at this time, this mostly affects the third-party graphics drivers which does not violate any F18 release criteria and could be fixed with an update. Therefore rejected as a blocker for F18 final (already accepted as NTH, a tested fix would be considered past freeze)
17:26:24 <akshayvyas> ack
17:26:31 <Viking-Ice> ack
17:26:33 <kparal> Sergio doesn't attend the meetings, I think we can't accept anybody's votes, but just votes from people we know they understand the process and they are around for some time. is that a heretic thought?
17:26:34 <jreznik> ack
17:26:36 <kparal> ack
17:26:42 <adamw> ack
17:26:49 <jreznik> kparal: yep
17:26:49 <tflink> #agreed 873220 - RejectedBlocker - Given our understanding at this time, this mostly affects the third-party graphics drivers which does not violate any F18 release criteria and could be fixed with an update. Therefore rejected as a blocker for F18 final (already accepted as NTH, a tested fix would be considered past freeze)
17:27:07 <adamw> kparal: when i was doing the voting i took them into account using a highly sophisticated weighting process which i made up in my head as we went along :P
17:27:08 <kparal> definitely from in-bug voting, because you can't talk to that person and ask for details
17:27:10 <tflink> kparal: I don't think that blocker votes should be exclusive
17:27:12 <adamw> er, counting the voting
17:27:36 <Viking-Ice> in bug voting cant be approved until here on the meeting
17:27:44 <tflink> #topic (881670) Provide fedup hook to add x-systemd.device-timeout=0 to mount options for encrypted file systems that need a passphrase from the user
17:27:47 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=881670
17:27:49 <buggbot> Bug 881670: unspecified, unspecified, ---, systemd-maint, NEW , Provide fedup hook to add x-systemd.device-timeout=0 to mount options for encrypted file systems that need a passphrase from the user
17:27:50 <tflink> #info Proposed Blocker, systemd, NEW
17:27:53 <kparal> I'd like us to skip this one
17:28:01 <Viking-Ice> punt it is
17:28:05 <kparal> we still don't have enough information to decide here
17:28:10 <adamw> there still seems a lot of confusion about it too.
17:28:10 <kparal> we discussed it on monday
17:28:24 <kparal> I'm getting more information, but it takes time
17:28:31 <jreznik> again? this one... punt today, we can back later to this one
17:28:41 <tflink> #info there is still a lot of confusion around this issue and there is currently not enough information to make a decision on blocker status. will re-visit when there is more info
17:28:48 <Viking-Ice> ack
17:28:49 * tflink moves it to his "needs info" list
17:28:50 <jreznik> kparal: any help needed with nagging people? /me got skilled during f18 release cycle...
17:29:09 <Viking-Ice> jreznik, club not good enough ;)
17:29:10 <kparal> jreznik: I'll contact you tomorrow if I can't get hold of somebody
17:29:51 <jreznik> kparal: ok
17:30:08 <tflink> #topic (870753) [abrt] gnome-font-viewer-3.6.0-1.fc18: load_font_infos: Process /usr/bin/gnome-font-viewer was killed by signal 11 (SIGSEGV)
17:30:11 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=870753
17:30:14 <buggbot> Bug 870753: unspecified, unspecified, ---, tiagomatos, MODIFIED , [abrt] gnome-font-viewer-3.6.0-1.fc18: load_font_infos: Process /usr/bin/gnome-font-viewer was killed by signal 11 (SIGSEGV)
17:30:14 <tflink> #info Proposed Blocker, gnome-font-viewer, MODIFIED
17:31:03 <tflink> so I'm not so clear on the status of this one but it sounds like it might have been somewhat fixed
17:31:13 <tflink> but in retrospect, this probably isn't so ready for discussion
17:31:20 <Viking-Ice> I'm fine with the trible U distro's font not working
17:31:27 <Viking-Ice> ;)
17:31:29 <tflink> there are conflicting reports of crashing vs. error message
17:31:31 <jreznik> 'Install Failed' - it still fails critaria...
17:31:41 <kparal> c#16
17:31:48 <Viking-Ice> "There is no segfault any more (gnome-font-viewer-3.6.1-1.fc18), the font is installed but the dialog says 'Install Failed'"
17:31:58 <kparal> if we ask Cosimo he will push a patch
17:32:04 <tflink> but c#17 is a crash with the same version
17:32:28 <akshayvyas> c#18 says its installed
17:32:32 <kparal> I think it crashes just once, then it behaves like in c#18
17:32:34 <Viking-Ice> fixable via update right
17:32:38 <tflink> assuming that it is still crashing, thoughts on blockery-ness?
17:32:56 <adamw> yeah, though for this particular criterion, anything that breaks it is 'fixable with an update'
17:33:05 <tflink> it's arguably part of the system menus, though
17:33:12 <adamw> the criterion is a) for polish (it's the kind of thing lots of casual testers/reviewers hit) and b) for live images
17:33:43 <adamw> we used to have embarrassing reviews where there'd be something like 'how could they possibly release this when (commonly-used-application X) just crashes?!'
17:33:46 <jreznik> could anyone try to rebuild it with the patch referenced by cosimo?
17:34:04 <adamw> i'd be +1 blocker if it's still crashing, -1 if it just behaves as described in #18
17:34:27 <tflink> sounds like punt to me
17:34:37 <Viking-Ice> punter indeed
17:34:51 <jreznik> punt, ask for the patch to be built, retest
17:34:54 <akshayvyas> i will go with punt as c# 18 is kinda confusing
17:35:33 <adamw> sounds good
17:35:57 * kparal is installing gnome-font-viewer
17:36:16 <tflink> proposed #agreed 870753 - It's still unclear on whether this is still crashing or just failing. We need more info on current behavior before deciding on blocker status. Request that a new gnome-font-viewer be built with the in-bug patch and testing with the new version to determine current behavior.
17:36:23 <adamw> patch
17:36:30 <adamw> s/just failing/just displaying a bogus error/
17:36:36 <adamw> comment #18 says "the font is installed"
17:36:58 <tflink> proposed #agreed 870753 - It's still unclear on whether this is still crashing or just displaying a bogus error message. We need more info on current behavior before deciding on blocker status. Request that a new gnome-font-viewer be built with the in-bug patch and testing with the new version to determine current behavior.
17:37:04 <tflink> thanks, missed that part
17:37:06 <adamw> ack
17:37:08 <akshayvyas> ack
17:37:24 * kparal just tested that
17:37:24 <Viking-Ice> ack
17:37:39 <kparal> first click on Install did nothing, second click said "installation failed"
17:37:51 <kparal> no crash
17:38:03 <adamw> hum, change to -1? :)
17:38:06 <pschindl> ack
17:38:12 <kparal> wait
17:38:29 <kparal> hmm, now it completely disappeared, but abrt says nothing
17:38:48 <kparal> segfault in console
17:38:50 <kparal> abrt silent
17:38:54 <kparal> so it crashes
17:39:10 <kparal> but it seems just in some cases, in other cases it says 'installation failed'
17:39:19 <Viking-Ice> still does not change my ack to the proposal
17:39:25 * jreznik just pinged cosimo...
17:39:30 <adamw> yeah, that sounds more questionable, so back to ack.
17:39:57 <tflink> any changes to nak?
17:40:26 <kparal> hmm, +1 blocker? crashes
17:40:27 <jreznik> ack for me
17:40:37 <kparal> but punt it fine as well
17:40:42 <tflink> #agreed 870753 - It's still unclear on whether this is still crashing or just displaying a bogus error message. We need more info on current behavior before deciding on blocker status. Request that a new gnome-font-viewer be built with the in-bug patch and testing with the new version to determine current behavior.
17:40:51 <tflink> #topic (862828) cancelling network time service kills firstboot
17:40:51 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=862828
17:40:52 <tflink> #info Proposed Blocker, system-config-date, ASSIGNED
17:40:54 <buggbot> Bug 862828: unspecified, unspecified, ---, nphilipp, ASSIGNED , cancelling network time service kills firstboot
17:41:32 <Viking-Ice> +1 blocker
17:41:34 <tflink> this feels a little self-induced to me
17:41:39 <tflink> workaround: '
17:41:49 <tflink> workaround: don't click on cancel
17:42:12 <Viking-Ice> users click cancell all the time
17:42:13 * jreznik is re-reading... the long one
17:42:42 <tflink> does it prevent you from logging in afterwards or after a reboot?
17:43:02 <kparal> tflink: no, you just have to create a second user
17:43:09 <akshayvyas> +1 blocker
17:43:16 <tflink> ah, that sucks a bit more than I was thinking
17:43:18 <adamw> i can see a case where it has trouble contacting the server for whatever reason
17:43:36 <kparal> firstboot forces you to create a new user every time it runs
17:43:38 <adamw> i'd kinda like to know if this was in previous releases - i suspect it was - but still sucks
17:43:51 <tflink> I'm definitely +1 NTH and probably not -1 blocker
17:43:53 <kparal> adamw: it's a re-occurring bug. I think it was fixed in previous releases
17:43:57 <adamw> ah
17:44:00 <Viking-Ice> and "first impression" not vote of confident if our system crashes at firstboot now is it ;)
17:44:17 <adamw> what's our criterion here?
17:44:19 <adamw> Viking-Ice: true
17:44:23 <Viking-Ice> Welcome to Feodra < crash>
17:44:26 <adamw> hehe
17:44:36 <adamw> view it as 'realistic setting of expectations' :P
17:44:37 <kparal> c#1 no criterion
17:44:58 <adamw> there's a criterion about firstboot, isn't there?
17:45:05 <tflink> "In most cases, a system installed according to any of the above criteria must boot to the 'firstboot' utility on the first boot after installation, without unintended user intervention ... The firstboot utility must be able to create a working user account"?
17:45:17 <tflink> which isn't quite right
17:45:29 <adamw> yeah, though it's obviously trying
17:45:29 <kparal> well it created the user :)
17:45:39 <tflink> but it could be argued that creating a second user account is unintended user intervention
17:45:54 <Viking-Ice> I would put this under application sanity
17:45:56 <adamw> maybe it needs a 'and complete successfully' or something
17:46:04 <adamw> Viking-Ice: trouble is firstboot isn't 'on the system menus'
17:46:09 <kparal> I think we don't need to do criteria juggling here. just decide what's best
17:46:11 <tflink> it does complete successfully, though
17:46:12 <adamw> this one seems to be falling between a few criteria stools
17:46:28 <adamw> tflink: no it doesn't, it completes unsuccessfully, which is why it runs again at the next boot
17:46:30 <tflink> you just have to create a second account or know how to disable firstboot
17:46:47 <adamw> it's supposed to write out /etc/sysconfig/firstboot and disable the service when it finishes, to stop it running again
17:46:47 <tflink> the user account creation is completed successfully, if I'm understanding correctly
17:46:49 <Viking-Ice> adamw, yeah but it kinda is part of "All elements of the default panel (or equivalent) configuration in all release-blocking desktops must function correctly in common use "
17:46:56 <kparal> tflink: yes
17:46:58 <adamw> tflink: right, but the firstboot process doesn't finish successfully
17:47:07 <tflink> true
17:47:08 <Viking-Ice> firstboot is present everywhere ( hence default )
17:47:15 <adamw> anyway, i think viking is right, we can agree on principle that this ought to be covered and i can draft up a criteria tweak afterwards
17:47:21 <tflink> it sounds like we are generally +1 blocker
17:47:27 * kparal is +0
17:47:30 <adamw> my inclination is that way
17:47:32 <adamw> call me a weak +1
17:47:33 <tflink> yay, longer criteria
17:47:40 <pschindl> +1 blocker
17:47:41 * jreznik is +0 more or less
17:47:44 <adamw> i can see this getting waved through a go/no-go meeting is my only cause for hesitation
17:47:49 <Viking-Ice> tflink, or shorter
17:47:50 <adamw> but it is a pretty crappy bug.
17:48:00 <adamw> Viking-Ice: tflink: yeah, my revision may involve splitting up that criterion.
17:48:14 * kparal finds crappy bugs all the time
17:48:31 <adamw> kparal: well i mean stop breaking things, god
17:48:31 <adamw> :P
17:48:52 <jreznik> crash in firstboot is not good, as it forces users to create second users - on the other hand this seems to be corner case, so if blocker, then really weak...
17:49:05 <kparal> that's what I'm hired for. do I hear something about a paid vacation?
17:49:18 <tflink> proposed #agreed 862828 - AcceptedBlocker - This provides a pretty bad first impression but doesn't completely violate any F18 release criterion. Accepted (pending criterion revision proposal) as it violates the following F18 alpha release criterion in spirit: "In most cases, a system installed according to any of the above criteria must boot to the 'firstboot' utility on the first boot after installation, without unintended user intervention ..."
17:49:47 <kparal> ack
17:49:49 <Viking-Ice> ack
17:49:51 <akshayvyas> ack
17:49:51 <pschindl> ack
17:49:59 <jreznik> ack
17:50:04 <tflink> kparal: that's one method that can be used to decrease bug counts: "send all testers out to the movies so they can't file more bugs"
17:50:12 <tflink> #agreed 862828 - AcceptedBlocker - This provides a pretty bad first impression but doesn't completely violate any F18 release criterion. Accepted (pending criterion revision proposal) as it violates the following F18 alpha release criterion in spirit: "In most cases, a system installed according to any of the above criteria must boot to the 'firstboot' utility on the first boot after installation, without unintended user intervention ..."
17:50:27 <tflink> adamw: want an #action for the criteria revision proposal?
17:50:31 <jreznik> tflink, kparal: what movie would you like to see? :)
17:50:32 <adamw> sure, thanks
17:50:36 <tflink> and while I'm thinking about it ...
17:50:43 <kparal> jreznik: a very long one, right? :)
17:50:45 <tflink> #chair adamw kparal
17:50:45 <zodbot> Current chairs: adamw kparal tflink
17:50:59 <adamw> War and Peace: Director's Cut
17:51:02 <tflink> all three extended versions of LotR back to back?
17:51:04 <jreznik> kparal: cloud atlas is 3 hours long :)
17:51:21 <adamw> #action adamw to revise firstboot criterion to cover successful exit / next boot run suppression
17:51:34 <tflink> you beat me to it
17:51:40 <adamw> booyah
17:51:53 <kparal> jreznik: "Days of our Lives" series?
17:52:18 <tflink> kparal: that might provoke a resignation letter from me ...
17:52:33 <tflink> #topic (873831) Make /tmp bigger, or use target image for yum downloads
17:52:36 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=873831
17:52:38 <buggbot> Bug 873831: medium, unspecified, ---, wwoods, NEW , Make /tmp bigger, or use target image for yum downloads
17:52:38 <tflink> #info Proposed Blocker, anaconda, NEW
17:53:01 <tflink> this seems ugly but a bit of a corner case to me
17:53:28 <jreznik> and it should probably not use tmp
17:53:30 <tflink> my understanding is that install fails for systems without a ton of ram but use a bunch of extra repos during installation
17:53:33 <Viking-Ice> is this not just a case of /var/tmp ?
17:53:39 <tflink> probably
17:53:43 <tflink> but does it block release?
17:53:54 <Viking-Ice> nope
17:53:59 <Viking-Ice> -1 blocker -1 nth
17:53:59 <jreznik> no
17:54:01 <kparal> "On anaconda install system" -- does he mean LiveCD or installed system?
17:54:06 <adamw> yeah, this seems pretty corner casey.
17:54:11 <jreznik> and it's fairly simple - /var/tmp as Viking-Ice said
17:54:13 <Viking-Ice> installed system
17:54:26 <adamw> it's filed against anaconda
17:54:35 <adamw> and says "(I enable a lot of repos via cobber during install)."
17:54:59 <kparal> that's cobbler?
17:55:00 <tflink> if it's using cobbler, I sincerely doubt that its a livecd
17:55:06 <tflink> more likely pxe
17:55:12 <adamw> if it's happening during install then i don't think using /var/tmp is going to change anything, is it? it's still not disk-backed.
17:55:17 <Viking-Ice> still an case of /var/tm
17:55:24 <Viking-Ice> P
17:55:26 <adamw> but i'm -1 if you need low RAM / lots-o-repos to hit it
17:55:38 <tflink> orion has talked about cobbler issues before, I assume that's what it's supposed to be
17:55:59 * kparal starts to understand
17:56:13 <adamw> is this writing yum repodata for these extra repos into the *installed* system?
17:56:17 <adamw> as a %post step or something?
17:56:24 <kparal> it's about installation, everything in RAM. too many repositories -> RAM can't cope with yum metadata
17:56:32 <tflink> I think yum does that by default
17:56:43 <tflink> downloads the filelists, dbs etc. before moving on
17:57:02 <kparal> yes, everything is in /tmp, on Live and DVD
17:57:14 <kparal> but that doesn't really matter, because everything is in RAM, not just /tmp
17:57:23 <jreznik> on live yep
17:57:24 * adamw would kinda like more information about whether we're talking about repos-to-be-used-as-package-source-during-install or repos-to-be-configured-on-the-installed-system here.
17:57:30 <kparal> even though /tmp might have some tighter limit
17:57:41 <Viking-Ice> it's not an issue with the offical repos
17:57:41 <tflink> if it was in /var/tmp, wouldn't it be possible to use swap?
17:57:44 <kparal> adamw: I think the first
17:57:51 <tflink> whereas using /tmp hits tmpfs issues?
17:57:51 <adamw> though either way, i'm tending -1
17:57:59 <tflink> assuming that the installer is using tmpfs
17:58:12 <Viking-Ice> what is "a lot of repos"
17:58:21 * kparal proposes punt and ask Orion for more info and _exact_ reproducer
17:58:35 <tflink> I'd be OK with that
17:58:36 <Viking-Ice> and do we accept blockers outside our own repo's
17:58:38 <tflink> other thoughts?
17:58:51 <tflink> Viking-Ice: if the issue was the contents of said repos, no
17:59:09 <tflink> if it's with the ability to use other repos, maybe. depends on the exact bug
17:59:22 <Viking-Ice> you can always add those afterwards
17:59:25 <adamw> i'd be happy with -1 or punt here
17:59:26 * tflink is waiting for more votes on punt/-1
17:59:33 <Viking-Ice> I'm still -1
17:59:46 <pschindl> -1
18:00:14 <jreznik> -1
18:00:34 <tflink> proposed #agreed 873831 - We would like to see an exact reproducer and information on what quantifies "too many repos" here before making a final decision on blocker status. Will re-visit after that information is available
18:00:45 <tflink> I can re-write for reject, though
18:00:46 <kparal> patch
18:00:53 <kparal> aha
18:01:01 <tflink> ?
18:01:01 <kparal> I thought you're missing "RejectedBlocker"
18:01:05 <Viking-Ice> we are 4 with -1
18:01:14 <tflink> ok, works for me
18:01:41 <Viking-Ice> 4 atleast
18:02:39 * Viking-Ice still would like to know how many repo's he's using
18:02:39 <tflink> proposed #agreed 873831 - RejectedBlocker - While unfortunate, this seems to be a little too much of a corner case to take as a blocker for F18 final (little memory, many extra repos) and is rejected as a blocker. Please re-propose if it turns out to be a more general problem than we're understanding.
18:02:48 <Viking-Ice> ack
18:02:51 <jreznik> ack
18:02:55 <pschindl> ack
18:03:27 <tflink> #agreed 873831 - RejectedBlocker - While unfortunate, this seems to be a little too much of a corner case to take as a blocker for F18 final (little memory, many extra repos) and is rejected as a blocker. Please re-propose if it turns out to be a more general problem than we're understanding.
18:03:27 <kparal> if would be nice to ask for more info anyway
18:03:33 <tflink> #topic (874486) progress indicator for mediacheck isn't displayed, so users may think the installer is hung
18:03:36 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=874486
18:03:38 <buggbot> Bug 874486: unspecified, unspecified, ---, bcl, NEW , progress indicator for mediacheck isn't displayed, so users may think the installer is hung
18:03:39 <tflink> #info Proposed Blocker, anaconda, NEW
18:04:32 <Viking-Ice> +1 nth
18:05:04 <kparal> nth is easy call. blocker is harder call
18:05:31 <tflink> if mediacheck is the default, I think it's somewhat +1 blocker
18:05:43 <Viking-Ice> mediacheck to me is not blocker worthy
18:05:44 <tflink> definitely +1 NTH
18:05:50 <Viking-Ice> users can always create new media
18:05:56 <akshayvyas> +1 NTH
18:06:04 <pschindl> +1 nth
18:06:06 <kparal> I believe we should either show the progress or make it non-default option
18:06:24 <kparal> that would be +1 blocker, any resolution of the two is ok
18:06:26 <tflink> by itself, no. but the issue in my mind is that mediacheck is the default when booting optical media - if it just hangs there with no progress indication for ~ 20 minutes, that's not OK
18:06:27 <Viking-Ice> both actually from me ;)
18:06:31 <tflink> kparal: +1
18:06:39 <tflink> as is, I think this is a blocker
18:06:52 <tflink> but I also think that making mediacheck non-default would make it not-a-blocker
18:06:56 <jreznik> it should not be default option...
18:07:15 <kparal> jreznik: actually I think it should be, but not without the progress and ability to skip it
18:07:15 <robatino> no one complained about it with the old mediacheck
18:07:16 <jreznik> as it's really confusing too
18:07:36 <robatino> the only reason it's a problem now is this bug
18:07:44 <kparal> robatino: agreed
18:07:45 <adamw> i'm +1 blocker on the basis of just not giving out any information at all
18:07:49 <tflink> it sounds like we're +1 nth
18:08:12 <adamw> i'd consider either 'don't do media check by default' or 'display some kind of indicator of what's going on' both to be perfectly good fixes
18:08:14 * tflink doesn't use optical media very often and usually skips mediacheck when he does
18:08:16 <jreznik> it's definitely +1 nth, blocker?
18:08:18 <kparal> I see +3 blocker
18:08:23 <jreznik> tflink: same here
18:08:33 <Viking-Ice> adamw, both
18:08:35 <jreznik> so I really think it's useless to be default
18:08:55 <Viking-Ice> adamw, it should not be the default and it should display somekind of information
18:09:00 <Viking-Ice> ;)
18:09:11 <jreznik> Viking-Ice: +1 ;-)
18:10:06 <kparal> that's not really part of this discussion
18:10:08 <tflink> proposed #agreed 874486 - AcceptedBlocker, AcceptedNTH - Violates the following F18 final release criterion: "If there is an embedded checksum in the image, it must match. If there is a related UI element displayed after booting the image, it must work and display the correct result". However, removing mediacheck as the default boot option would be enough to remove release blocking status. A tested complete fix would be considered past freeze.
18:11:02 <kparal> does it make sense to have it as a blocker _and_ nth?
18:11:08 <kparal> ack of course
18:11:53 <kparal> I'm not sure the criterion is fully correct, maybe custom explanation would be better. but doesn't really matter
18:11:58 <Viking-Ice> ack
18:12:00 <robatino> if the default is changed, is it easier to have it accepted already?
18:12:20 <tflink> I was more going with the "UI must work" part of the criterion
18:12:21 <robatino> accepted NTH
18:12:44 <adamw> ack
18:12:53 <robatino> ack
18:12:56 <tflink> robatino: not sure I'm following you - is there a problem with the proposal?
18:13:07 <tflink> oh, that was a correction. nvm
18:13:09 <robatino> i was responding to kparal's question
18:13:16 <tflink> #agreed 874486 - AcceptedBlocker, AcceptedNTH - Violates the following F18 final release criterion: "If there is an embedded checksum in the image, it must match. If there is a related UI element displayed after booting the image, it must work and display the correct result". However, removing mediacheck as the default boot option would be enough to remove release blocking status. A tested complete fix would be considered past freeze.
18:13:31 <tflink> #topic (876716) anaconda crashes after setting root password
18:13:31 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=876716
18:13:31 <tflink> #info Proposed Blocker, anaconda, ASSIGNED
18:13:33 <buggbot> Bug 876716: unspecified, unspecified, ---, msivak, ASSIGNED , anaconda crashes after setting root password
18:13:37 * kparal doesn't really see it, but that doesn't matter
18:13:57 <kparal> this is a clear +1 blocker for me
18:14:15 <kparal> we can now reproduce it reliably
18:14:18 <kparal> it's just about timing
18:14:42 <kparal> msivak says they are much bigger problems lurking and this is just one of the symptoms
18:14:56 <kparal> because anaconda lost access to the filesystem completely, for some reason
18:14:56 <Viking-Ice> +1 blocker
18:15:01 <adamw> with the reliable reproducer, +1 blocker
18:15:06 <kparal> it's just very lucky python modules are cached
18:15:07 <adamw> even if it's a bit artificial, it clearly shows something is wrong here.
18:15:19 <akshayvyas> +1 blocker
18:15:27 <pschindl> +1 blocker
18:17:02 <tflink> proposed #agreed 876716 - AcceptedBlocker - While this doesn't happen every time, it seems to be happening enough to justify release-blocking status. Violates the following F18 final release criterion as a not-uncommon timing issue: "The installer must be able to complete an installation using all supported interfaces"
18:17:14 <pschindl> ack
18:17:37 <Viking-Ice> ack
18:18:01 <kparal> ack
18:18:08 <tflink> #agreed 876716 - AcceptedBlocker - While this doesn't happen every time, it seems to be happening enough to justify release-blocking status. Violates the following F18 final release criterion as a not-uncommon timing issue: "The installer must be able to complete an installation using all supported interfaces"
18:18:21 <tflink> #topic (882722) 'KeyError: None' while trying to install F18 beta
18:18:21 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=882722
18:18:21 <tflink> #info Proposed Blocker, anaconda, NEW
18:18:23 <buggbot> Bug 882722: unspecified, unspecified, ---, anaconda-maint-list, NEW , 'KeyError: None' while trying to install F18 beta
18:19:46 <kparal> sounds like blocker
18:20:02 <Viking-Ice> yup
18:20:10 <kparal> it's pretty recent
18:20:11 <tflink> it's not completely clear what's causing this or which situations it manifests in but yeah, sounds rather blockery to me
18:20:42 <pschindl> +1
18:21:21 <tflink> do we really want to accept it before knowing what situations this occurs in?
18:21:53 <adamw> i'd kinda like more info but leaning +1
18:22:04 <kparal> re-using LVs
18:22:08 <adamw> but ideally, yeah, i'd like to know the trigger condition
18:22:10 <kparal> tflink: you mean an exact reproducer?
18:22:19 <Viking-Ice> does not comment one say what needs to be said?
18:22:20 <adamw> are we sure? we know that the initial reporter was re-using LVs, but how do we know that's exactly what triggers it?
18:22:33 <kparal> two reports, both same
18:22:39 <Viking-Ice> "ile reusing an LVM partition from a LUKS-encrypted volume group."
18:22:43 <kparal> c#16
18:22:45 <Viking-Ice> encrypted
18:22:59 <adamw> so does it matter if they're encrypted or not? jared doesn't say whether his were.
18:23:10 <tflink> I see two reports, one states encryption was used, the other doesn't
18:23:25 <Viking-Ice> both are blockers to me thou ;)
18:24:01 <adamw> i wouldn't hate +1, i just like to know precisely what triggers a bug first if possible
18:24:13 <adamw> count me +/-0 at this point
18:24:18 <tflink> which is pretty much where I'm at, as well
18:25:36 <kparal> let's write there we're leaning towards a blocker, but we would like to see more information what triggers the crash. ping anaconda folks to look at it
18:25:46 <kparal> and punt till next time
18:25:46 <tflink> I see 1 explicit +1, 1 implied +1 and I'm not quite sure where kparal is at
18:25:56 <tflink> unless he explains while I'm typing
18:26:06 <kparal> I'm at +1, but I'm OK with punt for more info
18:26:14 <Viking-Ice> me too
18:26:34 <adamw> kparal: that'd work fine for me
18:27:06 <tflink> proposed #agreed 882722 - This seems like it would qualify as a blocker for F18 final but we would like to get more information on what install configurations cause this before making a final decision. Will re-visit when there is more information.
18:27:36 <kparal> ack
18:27:42 <pschindl> ack
18:28:37 <adamw> ack
18:28:43 <Viking-Ice> ack
18:28:52 <tflink> #agreed 882722 - This seems like it would qualify as a blocker for F18 final but we would like to get more information on what install configurations cause this before making a final decision. Will re-visit when there is more information.
18:28:56 <tflink> #topic (873144) pressing Esc kills plymouth screen
18:28:56 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=873144
18:28:57 <tflink> #info Proposed Blocker, plymouth, NEW
18:29:00 <buggbot> Bug 873144: unspecified, unspecified, ---, rstrode, NEW , pressing Esc kills plymouth screen
18:29:36 * tflink hasn't gotten around to re-arranging things yet
18:29:45 <tflink> do we want to punt again until I do so?
18:29:49 <kparal> what is supposed to be shown behind the plymouth screen?
18:29:54 <tflink> some log output
18:30:17 <tflink> equivalent to what is is journald
18:30:26 <kparal> can user track progress from it?
18:30:47 <tflink> assuming I understand the log output that's supposed to be show, yes
18:30:48 <kparal> because I would rather block on missing progress bar than on displaying some logs on screen
18:30:53 <Viking-Ice> punt
18:30:58 <tflink> and I'm the exact opposite
18:31:01 <adamw> if the idea was that we punt till tflink cleans up teh bugs, and he hasn't, then punt.
18:31:09 <kparal> ok, punt
18:31:23 <tflink> yeah, this didn't get moved off the discussion list. my bad
18:31:51 <tflink> #info still waiting for tflink to re-organize as a clear issue, will re-visit when that happens
18:33:04 <tflink> I think this one has enough information for discussion now
18:33:12 <tflink> #topic (872088) fedup giving grubby backtrace
18:33:12 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=872088
18:33:12 <tflink> #info Proposed Blocker, fedup, ASSIGNED
18:33:14 <buggbot> Bug 872088: unspecified, unspecified, ---, wwoods, ASSIGNED , fedup giving grubby backtrace
18:33:53 <tflink> I'm not 100% sure it has enough information, but figured that it was worth a try
18:34:45 <adamw> well, clearly people are still hitting grubby-related backtraces.
18:34:46 <tflink> the cause of the issue doesn't seem 100% clear but it's related to grubby options
18:34:52 <adamw> i'm wondering if this needs to be split out as a separate bug.
18:35:12 <adamw> if several people are hitting it i lean towards blocker, as it clearly breaks upgrades, but it's kinda important to know how weird your grub config has to be...
18:35:14 <tflink> yeah, I think there have been more but I haven't gone through the fedup/fedup-dracut bug list in detail for a couple days
18:35:20 <tflink> I'd be OK with punt for now
18:35:25 <Viking-Ice> punt
18:35:51 <Viking-Ice> grubby gives headaches ;)
18:35:53 <tflink> I hit this 1/2 tries on the same system. one F17 install w/ livecd and the other with netinstall
18:36:34 <kparal> is this related to some specific environment, like UEFI?
18:36:38 <tflink> proposed #agreed 872088 - While it seems clear that people are still hitting grubby issues, the exact cause of this isn't clear and might be better to split off into a new report. will revisit later
18:36:41 <kparal> I wasn't able to digest all the comments
18:37:00 <adamw> ack
18:37:00 <tflink> kparal: kind of. like I said, I hit it on 1 of 2 tries on the same UEFI box
18:37:11 <eblake> hello - joining late, just noticed that you left notes on bug 882722; since I'm the OP on that bug, anything you need me to do for it?
18:37:13 <buggbot> Bug https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=882722 unspecified, unspecified, ---, anaconda-maint-list, NEW , 'KeyError: None' while trying to install F18 beta
18:37:48 <kparal> ack
18:37:53 <adamw> hi eblake, really we just wanted to be confident of precisely what the reproducer is
18:38:01 <Viking-Ice> ack
18:38:04 <tflink> #agreed 872088 - While it seems clear that people are still hitting grubby issues, the exact cause of this isn't clear and might be better to split off into a new report. will revisit later
18:38:17 <adamw> eblake: is it any re-use of existing LV, some particular existing LV config, does the encryption state matter
18:38:21 <tflink> eblake: and if it happens every time etc.
18:39:57 <tflink> #topic (860789) Multihead displays shows artifacts
18:39:57 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=860789
18:39:57 <tflink> #info Proposed Blocker, xorg-x11-drv-ati, NEW
18:39:59 <eblake> I don't know if the encryption state matters, but in my case, my pre-existing volume group was encrypted; I had previously created the LV within the VG, and the crash occurred after trying to see the updated view of which mount points belonged to the new install
18:39:59 <buggbot> Bug 860789: unspecified, unspecified, ---, xgl-maint, NEW , Multihead displays shows artifacts
18:40:23 <eblake> I tried multiple times, getting the same crash each time, so I think my steps were fairly reproducible
18:40:38 <tflink> note that we're already at -3 blocker in the bug
18:40:54 <tflink> the issue is that there is corruption on certain gfx hw when multiple monitors are used
18:41:14 <adamw> still -1 here.
18:41:17 <Viking-Ice> and back to the popular question how many have the HW
18:41:29 <adamw> well not just have the HW, but are using multiple monitors.
18:41:29 <tflink> X600 is rather old, IIRC
18:41:34 * kparal pinging Martix, he really haven't responded to c#6
18:41:41 <adamw> i'm pretty happily -1 to anything that's hardware *and* multi-monitor specific.
18:41:48 <Viking-Ice> tflink, which means it should work better not worse
18:41:50 <tflink> and I suspect that unplugging a montor might make it work well enough
18:42:07 <Viking-Ice> -1 blocker should work on single monitor and can be fixed via update
18:42:16 <tflink> Viking-Ice: you would think so, wouldn't you but doesn't it seem to be the opposite for gfx hw?
18:42:31 <kparal> I'm -1 blocker as well, probably even with a single monitor, unless we find out it covers more hardware than just a single card
18:42:33 <rbergeron> tflink: yes
18:42:33 * rbergeron assumes it's x600 and not x600 mobility but even that is still oldish
18:42:48 <Viking-Ice> dual monitors in GNU/linux sucks in general
18:43:07 <Viking-Ice> and I'm on T420 which should be recent enough to judge that
18:43:30 <tflink> proposed #agreed 860789 - RejectedBlocker - This is too hardware and setup specific to block the release of F18 final.
18:44:01 <tflink> ack/nak/patch?
18:44:09 <Viking-Ice> ack
18:44:14 <kparal> ack
18:44:20 <adamw> ack
18:44:21 <Viking-Ice> well you could mention fixable via update as well
18:44:27 <tflink> good point
18:44:41 <adamw> there's always lives, but yeah.
18:45:23 <tflink> proposed #agreed 860789 - RejectedBlocker - This could be fixed with an update in most situations and is too hardware/setup specific to block the release of F18 final.
18:45:40 <tflink> any changes to nak?
18:45:50 <adamw> still ack
18:45:50 <tflink> BTW, that's it for my list of bugs that need discussion right now
18:46:01 <adamw> *emerges blinking into light*
18:46:05 <tflink> the rest either need information or testing (in my view)
18:46:10 <Viking-Ice> ack
18:46:24 <tflink> #agreed 860789 - RejectedBlocker - This could be fixed with an update in most situations and is too hardware/setup specific to block the release of F18 final.
18:46:28 <Viking-Ice> ok call it quits for today?
18:46:41 <tflink> So we could either keep going with bugs that _I_ think aren't ready for a meeting or call it quits for today
18:47:01 <tflink> unless there is a bug that gets proposed during open floor
18:47:11 <kparal> tflink: all the rest of the bugs are "not ready"?
18:47:16 <Viking-Ice> +1 quits I need to go home from work and start cooking ;(
18:47:23 <tflink> or we could do nth, I suppose
18:47:25 <Viking-Ice> mean ;(
18:47:30 <Viking-Ice> mean ;)
18:47:46 <adamw> eh, maybe we should just get some work done after open floor
18:47:53 <tflink> kparal: I think so, yes
18:48:21 <kparal> tflink: we could do proposed nth which are >=modified
18:48:25 <tflink> some of them will be in the next meeting if there is no response from "hey, did this fix actually do anything?"
18:48:43 <tflink> kparal: wouldn't those not need NTH status?
18:48:59 <adamw> right. i'm generally of the opinion it's not worth doing NTH until close to freeze.
18:49:03 <adamw> since NTH status only matters post-freeze.
18:49:09 <kparal> hmm
18:49:18 <kparal> tflink: you might be right
18:49:46 <tflink> any objections to ending the meeting for today (assuming that kparal is ok with it?)
18:49:58 <tflink> #topic Open Floor
18:50:07 * kparal feels like a big troll now
18:50:14 <kparal> sure I'm OK with it
18:50:27 <tflink> anything else to discuss before we end the meeting?
18:50:38 <tflink> I have a question.
18:51:08 <tflink> other than the in-bug voting part - what do people think about me filtering bugs that are more-or-less ready for discussion before the meetings?
18:51:34 <kparal> tflink: that's a great idea, if you are willing to do that
18:51:51 <Viking-Ice> I think we still need approve votes here on the meeting
18:51:52 <kparal> certainly helps a lot to speed up the process
18:52:12 <kparal> (talking about the pre-meeting filtering)
18:52:23 <Viking-Ice> ah like that
18:52:31 <tflink> Viking-Ice: like I said, I'm not talking about inbug voting. just the filtering of stuff that needs more info and testing etc.
18:52:44 <tflink> I don't think we're going to have much more in-bug voting anyways
18:52:49 <Viking-Ice> tflink, if you or anyone else is willing to do the work
18:53:03 <tflink> I am, for now. assuming that I don't go crazy
18:53:13 <tflink> but some help working through the "needs testing" list would be much appreciated
18:58:50 * tflink notes that delay is due to conversation in fesco meeting
19:01:15 <Viking-Ice> I gotta run anyway
19:01:45 <Viking-Ice> my take is we should not release until we have a working gui for fedup...
19:08:29 <kparal> shouldn't we just #endmeeting?
19:11:45 <akshayvyas> oh i got one question
19:12:24 <akshayvyas> on using the weak root password anaconda does not prompt a warning
19:12:55 <akshayvyas> is this feature removed from new anaconda ??
20:11:58 <tflink> oh yeah, I suppose I should end the meeting
20:12:28 <tflink> anyone have an issue with not having another blocker review meeting this week?
20:14:24 <tflink> #info if no need is seen before then, the next blocker review meeting will be on 2012-12-05 @ 17:00 UTC
20:14:37 * tflink sets fuse for some small amount of time
20:14:46 * tflink will send out minutes shortly
20:14:51 <tflink> Thanks for coming, everyone
20:14:54 <tflink> #endmeeting