17:00:28 <tflink> #startmeeting f17-final-blocker-review-4
17:00:28 <zodbot> Meeting started Fri May  4 17:00:28 2012 UTC.  The chair is tflink. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:00:28 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
17:00:28 <tflink> #meetingname f17-final-blocker-review-4
17:00:28 <zodbot> The meeting name has been set to 'f17-final-blocker-review-4'
17:00:33 <tflink> #topic Roll Call
17:00:34 <adamw> yo
17:00:44 <tflink> Who's ready for some blocker meeting awesomeness?
17:00:48 <tflink> #chair adamw
17:00:48 <zodbot> Current chairs: adamw tflink
17:00:48 * nirik is lurking around, can help if needed.
17:00:52 * kparal is somewhat present
17:01:59 <cpuobsessed> topic should be: most awesomeness buggiest blockerest review of all time and then some
17:02:09 * adamw is around for about an hour before he has to go to the theatre
17:02:43 <adamw> cpuobsessed: why so understated?
17:02:44 <tflink> adamw: not acceptable.
17:02:51 <adamw> .fire adamw
17:02:51 <zodbot> adamw fires adamw
17:02:54 <adamw> i'm free!
17:03:15 <tflink> don't I wish it worked that way ... I would have been free a long time ago :)
17:03:20 <cpuobsessed> adamw, ran out of adjectives
17:03:40 * nirik notes to order more adjectives.
17:03:59 <cpuobsessed> nirik, and adverbs too
17:04:13 * cpuobsessed is always running out of adverbs
17:04:24 <nirik> I'll trade them for vowells and we can start meeting in welsh. ;)
17:05:04 <adamw> that'll make it all much clearer.
17:05:09 * akshayvyas is ready
17:05:35 <tflink> ok, let's get this party started
17:05:48 <tflink> ... with the always awesome boilerplate
17:05:55 <tflink> #topic Introduction
17:06:11 <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:06:22 <tflink> We'll be following the process outlined at:
17:06:23 <tflink> #link https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting
17:06:32 <tflink> The bugs up for review today is available at:
17:06:32 <tflink> #link https://fedoraproject.org/wiki/Current_Release_Blockers
17:06:52 <tflink> me speak english good : s/is/are
17:07:03 <tflink> The criteria for release blocking bugs can be found at:
17:07:03 <tflink> #link https://fedoraproject.org/wiki/Fedora_17_Final_Release_Criteria
17:07:03 <tflink> #link https://fedoraproject.org/wiki/Fedora_17_Beta_Release_Criteria
17:07:03 <tflink> #link https://fedoraproject.org/wiki/Fedora_17_Alpha_Release_Criteria
17:07:49 * tflink debates whether or not we need to re-visit any of the proposed blockers
17:09:25 <adamw> i think 816842 is one i just didn't update
17:09:30 <tflink> I don't see any big movement since yesterday, so I propose that we skip them for today
17:10:25 <tflink> I assume silence == no objections
17:10:27 <adamw> ack
17:10:34 <adamw> 816842 is acceptedblocker, fixed that now
17:10:37 <tflink> proposed NTH it is, then
17:10:58 <tflink> #topic (810141) KeyError: 'fstypeCombo'
17:10:58 <tflink> #link http://bugzilla.redhat.com/show_bug.cgi?id=810141
17:10:58 <tflink> #info Proposed NTH, NEW
17:12:27 <tflink> IIUC, any use of btrfs -> crashy
17:13:04 <adamw> it...doesn't entirely look like that, does it?
17:13:13 <adamw> ":I had f15, tried to install f17. Upon changing already existing logical volume
17:13:13 <adamw> to be mounted as /home, I recieved this traceback."
17:13:19 <adamw> that doesn't scream 'use btrfs and it crashes' to me.
17:13:30 * adamw goes to get some anacondians
17:14:00 <tflink> yeah, this does seem more like "can't use BTRFS in the anaconda GUI", which is a known issue for F17
17:14:19 <adamw> no, it doesn't look like that either. it's a later commenter who brings up the whole btrfs thing.
17:14:23 <adamw> the filer wasn't using btrfs at all afaics.
17:14:46 <adamw> well, he doesn't say he was
17:14:53 <adamw> bcl: what's going on in https://bugzilla.redhat.com/show_bug.cgi?id=810141 ?
17:15:19 <tflink> from the attached logs: templuks: existing 25022MB luks/dm-crypt luks-4ed68ca7-5df9-4675-b92b-2fb7e37d1d23 (86) with existing btrfs filesystem
17:15:25 <adamw> oh, i do see existing btrfs in the log...yeah.
17:15:41 <bcl> there is no btrfs gui
17:15:53 <bcl> it is kickstart only. So I'm not sure what's going on there.
17:15:57 <adamw> people seem to be hitting this by re-using existing partitions.
17:16:19 <adamw> so they have an f15 or f16 install with a btrfs partition, which they try to mount as part of the f17 system, and that seems to cause the crash.
17:16:25 <bcl> anaconda 17.18 is pretty old
17:16:32 <adamw> beta had 17.18, i believe.
17:16:45 <bcl> dlehman would know more.
17:17:06 <nirik> bug report is almost a month old. ;)
17:17:12 <tflink> the dupe is even older - 17.16
17:17:23 <akshayvyas> tflink:agree
17:17:47 <nirik> ask for people to repeat with current tc?
17:17:52 <adamw> i'd be +1 nth as far as we understand it. possibly even +1 blocker, really, it's a 'valid partition layout'.
17:18:14 * nirik nods.
17:18:58 <tflink> yeah, even though the gui doesn't support btrfs - crashing seems a bit harsh for existing systems
17:19:00 <akshayvyas> well comment 4 says something else
17:19:28 <cpuobsessed> if it is known that F17 won't support btrfs OOTB then anything dealing with btrfs should be NTH
17:19:29 <nirik> I think comment 4 was a bit confused as to the scope of the bug.
17:19:39 <tflink> I don't think that there have been any plans for btrfs to be the default fs for F17 for a while
17:19:49 <nirik> since this wasnt a new install with btrfs, it was an upgrade with an existing btrfs partition.
17:19:56 <adamw> well, i think he's just contrasting the two states. but yeah, it's hard to tell exactly what case vit hit.
17:20:06 <adamw> nirik: vit filed the bug that was closed as a dupe.
17:20:11 <nirik> ah, ok.
17:20:35 <adamw> he doesn't seem to have included any comment with his report, though, so it's hard to know what he was doing
17:20:41 <adamw> anyhow, we only have to vote on nth status
17:20:44 <cpuobsessed> then again what about systems that are upgraded through the DVD install that have btrfs?
17:20:52 <adamw> cpuobsessed: i've tested that, it works.
17:20:59 <adamw> upgrade is somewhat different from fresh install but re-use partitons.
17:21:01 <nirik> his looks like an upgrade too
17:21:12 <nirik> _origlv: existing 51200MB lvmlv vg_dhcp251-lv_home_f17 (139) with existing btrfs filesystem
17:21:33 <tflink> looks like he was using btrfs formatted LVs during install - not sure if it's an upgrade or just an externally prepped system
17:21:45 <cpuobsessed> i see, i remember now; when you just upgrade a system it bypasses partitioning all togeth
17:21:47 <cpuobsessed> er
17:22:06 <nirik> anyhow, +1 NTH, and ask folks to retest with latest anaconda?
17:22:07 <adamw> okay, so seems like we have a solid understanding
17:22:15 <adamw> re-using existing btrfs partitions caused explosions
17:22:32 <akshayvyas> yeah with f17 i think
17:22:59 <cpuobsessed> dern, i was going to reinstall using btrfs
17:23:06 <cpuobsessed> +1 NTH
17:23:15 <tflink> proposed #agreed - 810141 - AcceptedNTH - While btrfs isn't supported in the anaconda GUI, it shouldn't crash on discovery of pre-existing btrfs formatted partitions/disks/lvs
17:23:21 <adamw> ack
17:23:22 <nirik> ack
17:23:24 <tflink> cpuobsessed: you can use btrfs w/ kickstart, just not the GUI
17:23:26 <cpuobsessed> ack
17:23:33 <tflink> #agreed - 810141 - AcceptedNTH - While btrfs isn't supported in the anaconda GUI, it shouldn't crash on discovery of pre-existing btrfs formatted partitions/disks/lvs
17:23:42 <tflink> #topic (812528) creating LV partitions sometimes overwrites previous definitions
17:23:45 <tflink> #link http://bugzilla.redhat.com/show_bug.cgi?id=812528
17:23:47 <tflink> #info Proposed NTH, NEW
17:26:05 <tflink> the video helps
17:27:21 <tflink> AIUI - if you use 'lv' as the name for a LV created during partitioning and later create another LV with the name 'lv<anything>', the UI removes the first LV from the screen
17:27:49 <adamw> heh.
17:28:08 <tflink> which almost seems like blocker territory to me
17:28:12 <akshayvyas> well seemms like a ui
17:28:23 <tflink> definitely NTH
17:28:32 <cpuobsessed> simple, hard code partition name root swap  home usr
17:28:44 <adamw> hum. i was going to say, this might be one of those things we've been waving through as NTH that we might not want to any more, if we're being tighter after the beta experience...
17:29:05 <adamw> seems like the kind of thing where the fix might cause other problems.
17:29:16 <cpuobsessed> like what other names could throw anaconda into a tizzy
17:29:17 <akshayvyas> adamw: +1
17:29:17 <tflink> if we can get a fix soon, I'd be OK with it
17:29:29 <tflink> but I'm not as sure that I would want a fix at the 11th hour
17:29:57 * nirik is +1 NTH at this point. If the bug doesn't get fixed soon or the fix is intrusive, we should revisit...
17:30:21 <tflink> that sounds good to me
17:30:23 <adamw> it really doesn't seem as critical as all that to me
17:30:40 <adamw> i mean, i don't see how you wouldn't notice what was happening, you're not going to proceed with a bad layout or anything
17:30:43 <cpuobsessed> adamw: what about the poll of Fedora users, found out how they usually install Fedora?
17:31:13 <cpuobsessed> might help with determining what is critical/used more
17:31:17 <adamw> you have a whole other screen you go back to before you actually proceed with install, you have to actually assign mount points
17:31:22 <tflink> adamw: true, it's hard to miss and would end up being more of an annoyance than anything
17:31:27 <adamw> if an LV you meant to create doesn't seem to be there, you're probably going to notice
17:31:40 <tflink> looks bad, too
17:31:49 <akshayvyas> i dont know he is doing smething wrong there
17:32:10 * akshayvyas watching that video again
17:32:21 <adamw> i'd just feel a bit uncomfortable poking the LV creation code the day before doing an RC3, to fix this bug.
17:32:25 <cpuobsessed> anyone who custom partitions, whether using LVM or not, is not a typical user
17:32:32 <tflink> adamw: agreed
17:32:51 <adamw> the day after freeze, i guess maybe...so i can +1 on that basis i guess.
17:33:08 <tflink> we don't have to take NTH fixes
17:33:18 <adamw> yeah.
17:33:33 <tflink> but it would be good to make that clear to the devs so that they don't waste time fixing it if we're not going to take it
17:33:48 <cpuobsessed> save it for F18
17:34:42 <tflink> proposed #agreed - 812528 - AcceptedNTH - While not critical, this bug would be an annoyance and looks bad. We would take a tested fix soon but are less likely to allow a fix for this as we get closer to release.
17:34:46 <adamw> ack
17:35:04 <kparal> ack
17:35:17 <akshayvyas> ack
17:35:18 <tflink> cpuobsessed: the UI is going be completely rewritten for F18
17:35:24 <tflink> #agreed - 812528 - AcceptedNTH - While not critical, this bug would be an annoyance and looks bad. We would take a tested fix soon but are less likely to allow a fix for this as we get closer to release.
17:35:31 <tflink> #topic (818707) "network --device=link" in kickstart breaks boot
17:35:31 <tflink> #link http://bugzilla.redhat.com/show_bug.cgi?id=818707
17:35:31 <tflink> #info Proposed NTH, MODIFIED
17:36:30 <kparal> it seems that currently you can't use 'network --device' command inside kickstart
17:36:52 <tflink> kparal: I can build a test iso if you want to test the fix
17:37:05 <kparal> tflink: but I need kernel+initrd
17:37:11 <tflink> the initrd is built as part of the compose process
17:37:13 <kparal> or maybe not, hmm?
17:37:28 <tflink> initrd+vmlinuz
17:37:42 <adamw> what does --device do exactly?
17:38:13 <kparal> #link http://fedoraproject.org/wiki/Anaconda/Kickstart#network
17:38:30 <kparal> e.g. network --bootproto=dhcp --device=eth0
17:38:42 <tflink> #chair kparal
17:38:42 <zodbot> Current chairs: adamw kparal tflink
17:38:44 <adamw> oh, okay. +1, then. seems like important function.
17:38:53 <tflink> #link http://fedoraproject.org/wiki/Anaconda/Kickstart#network
17:38:59 <kparal> I can't say it breaks all kickstarts with 'network'
17:39:06 <kparal> but it definitely breaks this one
17:39:46 <tflink> proposed #agreed - 818707 - Breaks some kickstart network functionality - can't be fixed with a later update but isn't release critical.
17:39:55 <kparal> tflink: if you can build the kernel+vmlinuz for me, I'll be happy to test it
17:40:07 <tflink> #action tflink to build initrd+vmlinuz with  the dracut update for testing
17:40:18 <adamw> +1
17:40:19 <adamw> ack
17:40:20 <tflink> kparal: I'll get that started after the meeting
17:40:24 <kparal> post a link into that bz, thanks
17:40:25 <kparal> ack
17:40:50 <kparal> I'm not really sure whether it is release critical or not, in some setups they might need it
17:41:16 <tflink> proposed #agreed - 818707 - Breaks some kickstart network functionality - can't be fixed with a later update but may not be release critical.
17:41:19 <akshayvyas> i dont think its release critical
17:41:27 <akshayvyas> ack
17:41:52 <tflink> #agreed - 818707 - Breaks some kickstart network functionality - can't be fixed with a later update but may not be release critical.
17:41:57 <tflink> #topic (811389) EFI LiveUSB doesn't boot on UEFI system
17:41:57 <tflink> #link http://bugzilla.redhat.com/show_bug.cgi?id=811389
17:41:57 <tflink> #info Proposed NTH, MODIFIED
17:42:05 <kparal> sorry
17:42:13 <kparal> is that agreed NTH, or rejected NTH?
17:42:22 <tflink> damnation
17:42:25 <tflink> #undo
17:42:25 <zodbot> Removing item from minutes: <MeetBot.items.Info object at 0x259a0e90>
17:42:27 <tflink> #undo
17:42:27 <zodbot> Removing item from minutes: <MeetBot.items.Link object at 0x259a06d0>
17:42:29 <tflink> #undo
17:42:29 <zodbot> Removing item from minutes: <MeetBot.items.Topic object at 0x259a0d90>
17:42:31 <tflink> #undo
17:42:31 <zodbot> Removing item from minutes: <MeetBot.items.Agreed object at 0x259a0050>
17:42:40 <tflink> #agreed - 818707 - AcceptedNTH - Breaks some kickstart network functionality - can't be fixed with a later update but may not be release critical.
17:42:44 <kparal> ok
17:42:47 <tflink> #topic (811389) EFI LiveUSB doesn't boot on UEFI system
17:42:47 <tflink> #link http://bugzilla.redhat.com/show_bug.cgi?id=811389
17:42:47 <tflink> #info Proposed NTH, MODIFIED
17:43:01 <akshayvyas> oh uefi again
17:43:04 <tflink> I think this falls into the same bucket as the LV ui one
17:43:13 <tflink> +1 NTH but not at the 11th hour
17:43:31 <tflink> should be able to test this with the next compose, though
17:43:48 <bcl> already fixed.
17:43:59 * satellit_ f16 on bug
17:44:09 <adamw> this should be closed.
17:44:12 <adamw> again, bodhi didn't close it.
17:44:16 <adamw> been fixed for weeks.
17:44:25 <tflink> ah, even better
17:44:30 <akshayvyas> adamw: +1
17:44:58 <tflink> proposed #agreed - 811389 - This bug has been fixed for weeks but hasn't actually been closed yet. Close the bug as it has been resolved.
17:45:19 <nirik> ack
17:45:26 <akshayvyas> ack
17:45:46 <cpuobsessed> ack
17:45:56 <tflink> #agreed - 811389 - This bug has been fixed for weeks but hasn't actually been closed yet. Close the bug as it has been resolved.
17:46:04 <tflink> #topic (810083) dd'ed Fedora 17 Beta RC3 images are not EFI bootable
17:46:04 <tflink> #link http://bugzilla.redhat.com/show_bug.cgi?id=810083
17:46:04 <tflink> #info Proposed NTH, NEW
17:46:29 <tflink> was this fixed with the latest livecd-creator?
17:46:47 <tflink> nvm, this is pungi
17:46:55 <tflink> I misunderstood the last comment
17:47:07 <tflink> I think that dgilmore either has a patch for this or will have it soon
17:47:12 <akshayvyas> adamw: can you get one uefi'an
17:47:56 <tflink> this was accepted for beta NTH
17:48:12 <adamw> akshayvyas: i usually am one, i'm just away from my desktop
17:48:55 <adamw> so when this is fixed, chris and i will be able to test the fix
17:48:57 <akshayvyas> adamw: well this uefi is mysterious to me
17:48:59 <adamw> i'm +1 nth at least early
17:49:03 <tflink> proposed #agreed - 810083 - AcceptedNTH - EFI bootable DVD isos are desirable and a tested fix would be accepted soon but not at the last minute.
17:49:07 <adamw> akshayvyas: what's your hardware?
17:49:38 <akshayvyas> adamw: lenovo core i3 it came with dos
17:50:12 <akshayvyas> so i dont have any uefi issues
17:50:50 <tflink> ack/nak/patch?
17:51:05 <adamw> ack
17:52:21 <akshayvyas> ack
17:53:12 <tflink> #agreed - 810083 - AcceptedNTH - EFI bootable DVD isos are desirable and a tested fix would be accepted soon but not at the last minute.
17:53:21 <tflink> #topic (805017) Segmentation fault in anaconda when switching TTYs
17:53:21 <tflink> #link http://bugzilla.redhat.com/show_bug.cgi?id=805017
17:53:21 <tflink> #info Proposed NTH, ASSIGNED
17:53:46 <tflink> I've hit this a couple of times and it is an annoyance
17:54:16 <cpuobsessed> i haven't seen anything like this, and i have switched ttys during install
17:54:39 <adamw> cpuobsessed: it's specific to KVM VMs
17:54:50 <adamw> cpuobsessed: it happens quite often that if you switch to a VT in a VM, X will crash
17:54:54 <adamw> sometimes it doesn't, but often it does
17:55:03 <adamw> it's not at all specific to the installer.
17:55:25 <cpuobsessed> pfft, +1 NTH
17:55:42 <adamw> yeah, i'm still happy with NTH for this, it's unlikely a fix would have any terrible consequences, and it's an annoying bug
17:55:54 <tflink> doesn't this affect qxl more for the virt host, though?
17:55:55 <adamw> VM bugs that get 'locked in' for lives are really annoying when you're still hitting them months later...
17:56:09 <akshayvyas> adamw: +1
17:56:11 <adamw> tflink: it may be qxl specific, yeah. i always use qxl for guests.
17:56:23 <tflink> +1 NTH
17:56:52 <cpuobsessed> aren't there other bugs specific to qxl in a VM?
17:57:15 <tflink> proposed #agreed - 805017 - AcceptedNTH - This is an annoyance that affects livecds running as VMs and it would be nice to have this fixed prior to release.
17:57:24 <cpuobsessed> ack
17:57:26 <adamw> cpuobsessed: most of them are fixed in 17, happily.
17:57:28 <akshayvyas> ack
17:57:29 <tflink> cpuobsessed: I think that the others have been mostly taken care of
17:57:34 <adamw> this is the biggest remaining one.
17:57:38 <kparal> switching users is another one
17:57:47 <kparal> rejected as a blocker iirc
17:58:32 <tflink> #agreed - 805017 - AcceptedNTH - This is an annoyance that affects livecds running as VMs and it would be nice to have this fixed prior to release.
17:58:46 <tflink> #topic (725219) anaconda should run in clone not span mode
17:58:46 <tflink> #link http://bugzilla.redhat.com/show_bug.cgi?id=725219
17:58:46 <tflink> #info Proposed NTH, NEW
17:59:08 <tflink> has this been fixed?
17:59:26 <tflink> I thought that dual-head worked the last time I did an install
17:59:29 <tflink> but I could well be wrong
18:00:38 <adamw> i don't think it's fixed, but i did notice last time i left my second head plugged in on install that at least the buttons were visible...not sure what changed
18:00:45 <adamw> but afaik no-one did anything specific to fix this
18:01:51 <tflink> either way, same boat as most of the others - +1 NTH but not at the last minute
18:02:09 <bcl> oh, my fix for 800609 may solve this.
18:02:33 <bcl> we now pick the smallest size that will fit.
18:02:36 * tflink wonders if we should define the testing needed to take NTH fixes a bit better
18:02:40 <bcl> so it shouldn't span anything.
18:02:54 <adamw> honestly, in my new Tough On NTHs, Tough On The Causes Of NTHs regime, i might be -1 on this...
18:02:59 <adamw> bcl: oh neat.
18:03:07 <adamw> that'd explain it
18:03:27 <tflink> it'd depend on how big the fix was an when we got it
18:03:34 <tflink> for me, anyways
18:03:56 <adamw> i might say just close it and say 800609 fixed it. gordian knot solution. =)
18:04:32 <bcl> seems like I killed 2 bugs with that one.
18:04:54 <tflink> adamw: let's verify before closing it :-P
18:04:59 <adamw> sure...
18:05:07 <adamw> but punt on NTH status in the hope we don't have to care =)
18:05:56 <tflink> proposed #agreed - 725219 - This may have been fixed with another patch that is already in anaconda. Ask for retesting and close if this is the case - will revisit next week if this is still an issue.
18:06:14 <adamw> ack
18:06:16 <akshayvyas> ack
18:06:27 <adamw> i gotta run
18:06:29 <adamw> sorry :(
18:06:32 <adamw> leave you guys to finish up
18:06:34 <bcl> ack
18:06:37 <tflink> that's the last of the proposed NTH, anyways
18:06:45 <tflink> #agreed - 725219 - This may have been fixed with another patch that is already in anaconda. Ask for retesting and close if this is the case - will revisit next week if this is still an issue.
18:06:46 <adamw> if someone else wants to secretaryize then do, otherwise i'll finish it up later
18:07:00 <tflink> ok, we'll get it figured out :)
18:07:36 <tflink> alrighty, on to the accepted blockers
18:07:44 <tflink> #topic (755335) Shutting down while auto-updating breaks the system
18:07:44 <tflink> #link http://bugzilla.redhat.com/show_bug.cgi?id=755335
18:07:44 <tflink> #info Accepted Blocker, ASSIGNED
18:10:46 <tflink> it sounds like there has been some movement on this and while there is consensus that this is an issue - there doesn't seem to be a suggested fix for F17
18:11:28 <tflink> #info there is general agreement that this is an issue that needs to be fixed
18:11:47 <tflink> #info there are 3 proposed methods to fix this listed in c#10
18:12:03 <kparal> I doubt we can have option #2 or #3 in time
18:12:37 <kparal> it will be lightly tested at best
18:12:42 <tflink> even if we could, I'm not sure that taking fixes like those would be wise so late in the release process
18:12:43 <akshayvyas> well c#13 says that some warnings can be added
18:13:04 <akshayvyas> For F17, we can only make simple changes at this point. Even adding new warnings will run into problems with lack of translations. But we should do that anyway.
18:14:00 <tflink> #info adding a warning dialog was suggested in c#13, may be possible for F17 but difficult to translate in time
18:14:23 <tflink> either way, I don't think that there is much we can do from our end on this
18:14:28 <tflink> it looks like discussion is moving along
18:14:48 <tflink> maybe a poke to say "please figure it out soon so we're not taking fixes @ the last minute"
18:15:33 <tflink> proposed #agreed - 755335 - Progress is being made but there is no decided fix as of yet - this needs to happen soon so that we're not adding little-tested last minute changes
18:15:47 <akshayvyas> ack
18:15:50 <kparal> I have to confirm whether it concerns also KDE etc
18:16:03 <kparal> ack
18:16:23 <tflink> #action kparal to test whether or not KDE is affected by 755335
18:16:31 <tflink> #agreed - 755335 - Progress is being made but there is no decided fix as of yet - this needs to happen soon so that we're not adding little-tested last minute changes
18:16:39 <tflink> #topic (816509) 'Updates' notification not showing up in Gnome (F17 TC1)
18:16:42 <tflink> #link http://bugzilla.redhat.com/show_bug.cgi?id=816509
18:16:45 <tflink> #info Accepted Blocker, NEW
18:16:57 <tflink> looks like there has been progress here
18:17:18 <tflink> not sure which update changed things but the most recent comment says that it is working now
18:17:24 <tflink> #info progress is being made
18:17:39 <tflink> #info latest report says that the issue has been fixed with something from updates-testing
18:18:20 <cpuobsessed> wasn't the policy changed, updates are checked only daily/weekly so a user might not see it until later
18:18:39 <tflink> proposed #agreed - 816509 - It sounds like this issue may be fixed with something from updates-testing. Ask which update actually fixes this, get it into final TC3 and re-evaluate after testing.
18:19:02 <tflink> cpuobsessed: part of the test case involves changing the frequency of checking for updates
18:19:11 <tflink> well, it should at least. I remember it being a suggestion
18:19:36 <cpuobsessed> what happens if some packages are broke?
18:19:45 <akshayvyas> well c#7 and c#8 says it worked
18:19:58 <cpuobsessed> i have luxrender installed but other deps need to catch up
18:20:22 <tflink> cpuobsessed: it should still check for updates, I think
18:20:55 <akshayvyas> tflink: yeah agree
18:21:04 <tflink> akshayvyas: yeah but that's one report and it's not clear which build fixed it. I'd rather see the fixes in a TC/RC and run through the matrix before we call this fixed
18:21:31 <akshayvyas> tflink: yep i think thats best
18:21:52 <tflink> ack/nak/patch?
18:22:03 <akshayvyas> ack
18:23:01 <tflink> #agreed - 816509 - It sounds like this issue may be fixed with something from updates-testing. Ask which update actually fixes this, get it into final TC3 and re-evaluate after testing.
18:23:09 <tflink> #topic (790348) If specified repo= doesn't contain package repository, fall back to default online repos
18:23:12 <tflink> #link http://bugzilla.redhat.com/show_bug.cgi?id=790348
18:23:14 <tflink> #info Accepted Blocker, NEW
18:23:16 <tflink> I think that the fix for this is already in anaconda
18:23:49 <kparal> not really
18:24:01 <tflink> the patch was sent out and acked - not 100% sure if it was committed yet, though
18:24:13 <kparal> see comment 29
18:24:20 <tflink> keeping in mind that there is a newer anaconda build than what's in TC2
18:24:30 <kparal> they basically say that we should use stage2=
18:24:39 <kparal> instead of repo=
18:24:54 <kparal> but virt-install uses always repo=
18:25:13 <kparal> so yep, it will fix PXE installs, where you can specify it manually, which is great
18:25:19 <kparal> virt-install stays broken however
18:25:37 <kparal> but the criterion will be satisfied once the patch lands
18:26:34 <tflink> #info patch to fix stage2= has been sent out to anaconda-devel@, should land in next anaconda build if it isn't there already
18:26:44 <kparal> I'll spawn a new bug for virt-install probably, but that's not a blocker, so no action needed
18:26:55 <tflink> #info using stage2= will fix issues for PXE but doesn't help virt-install
18:27:28 <tflink> #info once the stage2= patch lands in anaconda, the release criteria should be satisfied
18:28:06 <bcl> patch will be in the next build
18:28:52 <tflink> proposed #agreed - 790348 - This appears to be on it's way to being fixed to the point where the release criteria are satisfied. It will need testing after the next compose and doesn't help virt-install. A new bug should be filed to get virt-install fixed so that it works with the new repo restrictions
18:28:57 <tflink> ack/nak/patch
18:29:08 <kparal> ack
18:29:12 <kparal> btw, off-topic, why don't we do proposed blockers first?
18:29:21 <akshayvyas> ack
18:29:22 <tflink> we usually do
18:29:59 <tflink> but since there have already been 2 blocker review meetings this week, there was no meaningful movement on the rest of the proposed blockers that warranted review again
18:30:14 <tflink> #agreed - 790348 - This appears to be on it's way to being fixed to the point where the release criteria are satisfied. It will need testing after the next compose and doesn't help virt-install. A new bug should be filed to get virt-install fixed so that it works with the new repo restrictions
18:30:24 <tflink> #topic (806166) Installation using DVD ISO dd'd to USB can't use USB as installation source
18:30:28 <tflink> #link http://bugzilla.redhat.com/show_bug.cgi?id=806166
18:30:30 <tflink> #info Accepted Blocker, ON_QA
18:31:10 <tflink> hrm, not sure how livecd-tools could affect this issue
18:31:36 <tflink> #info needs re-testing with TC2 which contains anaconda-17.23-1
18:32:09 <tflink> proposed #agreed - 806166 - This may be fixed with anaconda-17.23-1 but needs re-testing to verify that fix.
18:32:16 <tflink> ack/nak/patch?
18:32:52 <kparal> ack
18:32:56 <akshayvyas> ack
18:33:19 <tflink> #agreed - 806166 - This may be fixed with anaconda-17.23-1 but needs re-testing to verify that fix.
18:33:28 <tflink> #topic (807982) anaconda can not load an updates.img from removable media
18:33:30 <tflink> #link http://bugzilla.redhat.com/show_bug.cgi?id=807982
18:33:33 <tflink> #info Accepted Blocker, MODIFIED
18:34:32 <akshayvyas> comment c#4 says it will be fixed
18:34:57 <kparal> good
18:35:01 <tflink> yeah, just checked anaconda-devel@
18:35:31 <tflink> not sure if the fix is in 17.24-1 or if it will be in the upcoming 17.25-1, though
18:35:51 <tflink> #info patch has been sent out and reviewed
18:36:12 <tflink> #info this should be fixed, will need retesting for verification in the next compose
18:36:51 <tflink> proposed #agreed - 807982 - This should be fixed with the next build of anaconda - ask for re-testing once we have a new TC/RC and close if verified
18:36:58 <tflink> ack/nak/patch?
18:37:01 <kparal> ack
18:37:19 <akshayvyas> ack
18:37:28 <tflink> #agreed - 807982 - This should be fixed with the next build of anaconda - ask for re-testing once we have a new TC/RC and close if verified
18:37:31 <tflink> #topic (809647) sourcing updates.img from installation repository does not work
18:37:34 <tflink> #link http://bugzilla.redhat.com/show_bug.cgi?id=809647
18:37:37 <tflink> #info Accepted Blocker, MODIFIED
18:37:43 <tflink> this sounds like it is in the exact same boat - same patch, even
18:37:49 <tflink> #info patch has been sent out and reviewed
18:37:54 <tflink> #info this should be fixed, will need retesting for verification in the next compose
18:38:13 <tflink> proposed #agreed - 809647 - This should be fixed with the next build of anaconda - ask for re-testing once we have a new TC/RC and close if verified
18:38:17 <tflink> ack/nak/patch?
18:38:33 <akshayvyas> ack
18:39:35 <tflink> #agreed - 809647 - This should be fixed with the next build of anaconda - ask for re-testing once we have a new TC/RC and close if verified
18:39:46 <tflink> #topic (811242) PXE and repo=nfs or repo=nfsiso freezes installer
18:39:47 <tflink> #link http://bugzilla.redhat.com/show_bug.cgi?id=811242
18:39:47 <tflink> #info Accepted Blocker, ASSIGNED
18:40:31 <kparal> this is being solved
18:40:55 <tflink> #info there has been recent movement on this, sounds like a fix is closer
18:41:10 <tflink> kparal: any more information than what's already in the bug?
18:41:51 <kparal> no
18:42:39 <tflink> #info there is a request for more testing and logs from /var
18:43:31 <tflink> proposed #agreed - 811242 - There has been some movement on this bug but no fix has been proposed yet. There is a request for logs but the request is a little vague - ask for clarification before sending out a request for more testing
18:43:35 <tflink> ack/nak/patch?
18:43:54 <kparal> I don't think that request is intended for general public
18:43:59 <kparal> rather brainstorming
18:44:11 <kparal> but ack
18:44:16 <akshayvyas> ack
18:44:47 <tflink> proposed #agreed - 811242 - There has been some movement on this bug but no fix has been proposed yet. There is a request for logs but the request is a little vague - ask for clarification on exactly which logs are being requested
18:44:56 <tflink> kparal: better?
18:45:30 * kparal shrugs
18:45:42 <tflink> close enough :)
18:45:48 <tflink> #agreed - 811242 - There has been some movement on this bug but no fix has been proposed yet. There is a request for logs but the request is a little vague - ask for clarification on exactly which logs are being requested
18:45:56 <tflink> #topic (770197) Gnome Shell corrupted on nVidia cards with low VRAM
18:45:57 <tflink> #link http://bugzilla.redhat.com/show_bug.cgi?id=770197
18:45:57 <tflink> #info Accepted Blocker, NEW
18:46:05 <kparal> ah, this one
18:46:19 <kparal> I still don't understand whether my card should be covered by this bug report
18:46:46 <kparal> everyone seems to ignore me!
18:47:41 <tflink> are most of the issues that you've been reporting from the same machine?
18:48:00 <kparal> now you mean which issues?
18:48:13 <kparal> all the blocker bugs?
18:48:16 <tflink> kparal: I've been hoping for a fix so that I don't need a custom kernel for my laptop since before F16 was released
18:48:26 <tflink> kparal: this and the PA issue are the ones that come to mind
18:48:43 <kparal> those are from different machines
18:49:03 <akshayvyas> well no idea about nvidea i got ati
18:49:30 <tflink> #info There has been some progress on this issue but no definitive solution yet
18:49:57 <kparal> haha, anaconda just crashed on me in XFCE install
18:50:19 <tflink> #info some mutter patches from another bug are mentioned as potential fixes but it doesn't look like builds are available for testing
18:50:27 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=813648
18:51:44 <kparal> I hate abrt
18:52:10 <tflink> proposed #agreed - 770197 - Ask for ETA on the proposed fixes as we understand them. If there are available testers, ask for test mutter builds for the question posed in c#21.
18:52:15 <tflink> ack/nak/patch?
18:52:21 <kparal> ack
18:52:29 <akshayvyas> ack
18:52:43 <tflink> #agreed - 770197 - Ask for ETA on the proposed fixes as we understand them. If there are available testers, ask for test mutter builds for the question posed in c#21.
18:53:02 <tflink> #topic (809111) grub2-probe fails during install
18:53:02 <tflink> #link http://bugzilla.redhat.com/show_bug.cgi?id=809111
18:53:02 <tflink> #info Accepted Blocker, NEW
18:53:42 <tflink> #info There has been no movement on this since it was last reviewed (yesterday) - nothing to do on our end
18:53:58 <tflink> #topic (811412) F17 Beta RC4 desktop live fails to install successfully after being written with dd
18:54:01 <tflink> #link http://bugzilla.redhat.com/show_bug.cgi?id=811412
18:54:04 <tflink> #info Accepted Blocker, ASSIGNED
18:54:44 <tflink> #info not sure if this has been fixed yet or not, last report was from 2012-04-19
18:55:31 <tflink> proposed #agreed - 811412 - This may be fixed, needs re-testing. Update bug with request for specific answer on the retesting status and/or request more testing
18:55:34 <tflink> ack/nak/patch?
18:56:05 <kparal> ack
18:56:18 <akshayvyas> ack
18:56:34 <kparal> I propose to postpone rest of the meeting so that we have more attendants. I kind of need to go anyway
18:56:53 <tflink> aww, we only have 4 more
18:57:05 * tflink will look for other participants
18:57:09 <tflink> I really want this done
18:57:45 <tflink> #agreed - 811412 - This may be fixed, needs re-testing. Update bug with request for specific answer on the retesting status and/or request more testing
18:57:47 <kparal> ok, let's go on
18:57:51 <akshayvyas> kparal: +1
18:57:58 <tflink> #topic (815827) Connection to root iSCSI disk is disrupted during boot
18:58:01 <tflink> #link http://bugzilla.redhat.com/show_bug.cgi?id=815827
18:58:04 <tflink> #info Accepted Blocker, ON_QA
18:58:33 <tflink> #info this has been fixed, needs re-testing once dhcp-4.2.4-0.4.rc1 is pushed to stable and included in the next TC/RC
18:58:33 <akshayvyas> i think this one was set to needinfo
18:59:16 <tflink> proposed #agreed - 815827 - This appears to have been fixed and can be closed if verified with the next compose
18:59:21 <tflink> ack/nak/patch?
18:59:31 <kparal> ack
18:59:33 <tflink> akshayvyas: it was?
18:59:34 <akshayvyas> ack
18:59:49 <akshayvyas> as we discussed
18:59:57 <akshayvyas> in last meeting
19:00:08 <tflink> #agreed - 815827 - This appears to have been fixed and can be closed if verified with the next compose
19:00:35 * tflink will go back and check the minutes from last meeting later
19:00:58 <tflink> #action tflink to check previous minutes to make sure that we're not missing anything for 815827
19:01:06 <tflink> #topic (813905) livecd-iso-to-disk does not create USB correctly from a DVD image
19:01:09 <tflink> #link http://bugzilla.redhat.com/show_bug.cgi?id=813905
19:01:11 <tflink> #info Accepted Blocker, ON_QA
19:01:43 <tflink> it sounds like this is fixed, pending documentation updates
19:01:57 <tflink> #info it sounds like this has been fixed
19:02:15 <tflink> #info there is a proposal to do away with the wiki documentation in favor of the release notes
19:02:49 <tflink> proposed #agreed - 813905 - Ask for confirmation that this has indeed been fixed, close if it has
19:02:52 <tflink> ack/nak/patch?
19:03:30 <akshayvyas> ack
19:03:59 <kparal> ack
19:03:59 <tflink> #agreed - 813905 - Ask for confirmation that this has indeed been fixed, close if it has
19:04:03 <tflink> #topic (815413) Preugprade from F16 to F17 Beta does not regenerate pam.d/system-auth*, causing systemd-loginctl not to know about user sessions, breaking PulseAudio
19:04:06 <tflink> #link http://bugzilla.redhat.com/show_bug.cgi?id=815413
19:04:08 <tflink> #info Accepted Blocker, NEW
19:04:20 <tflink> #info no movement on this bug since it was reviewed yesterday - nothing to do from our end at this time
19:04:32 <tflink> and the last one!
19:04:34 <tflink> #topic (802552) wlan0: WPA: Failed to get master session key from EAPOL state machines - key handshake aborted
19:04:38 <tflink> #link http://bugzilla.redhat.com/show_bug.cgi?id=802552
19:04:40 <tflink> #info Accepted Blocker, NEW
19:05:08 <tflink> #info there are reports that this has been fixed - not clear whether the update is in stable yet or not
19:05:32 <akshayvyas> its fixed i think
19:05:57 <akshayvyas> c#12
19:06:23 <tflink> proposed #agreed - 802552 - This is reported to be fixed but its not clear what the status of any updates is. Ask for more information and close if the update is in stable - ask for required modifications otherwise
19:06:27 <tflink> ack/nak/patch?
19:06:31 <akshayvyas> ack
19:07:13 <kparal> ack
19:07:27 <tflink> #agreed - 802552 - This is reported to be fixed but its not clear what the status of any updates is. Ask for more information and close if the update is in stable - ask for required modifications otherwise
19:07:39 <tflink> and that was the last one
19:07:42 <tflink> #topic Open Floor
19:07:56 <tflink> Any other bugs or issues that people want to bring up?
19:08:03 <kparal> wheeee
19:08:15 <kparal> no
19:08:20 <akshayvyas> kparal: :)
19:08:43 <tflink> at least this meeting didn't go too far past the 3 hour mark :-/
19:09:06 <tflink> I think that we're all ready for this to be done, though
19:09:15 * tflink sets fuse for [0,5] minutes
19:09:41 <tflink> #info Next blocker review meeting will be 2012-05-11 @ 17:00 UTC
19:10:14 <tflink> eh, don't feel like waiting longer :)
19:10:37 <tflink> Thanks for coming everyone! There have been a lot of blocker review meetings this week but we're finally through the whole list!
19:10:46 * tflink will send out minutes shortly
19:10:49 <tflink> #endmeeting