17:00:34 <tflink> #startmeeting F17-beta-blocker-review-3
17:00:34 <zodbot> Meeting started Fri Mar 16 17:00:34 2012 UTC.  The chair is tflink. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:00:34 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
17:00:34 <tflink> #meetingname F17-beta-blocker-review-3
17:00:34 <zodbot> The meeting name has been set to 'f17-beta-blocker-review-3'
17:00:40 <tflink> #topic roll call
17:00:45 <tflink> who's ready for some blocker review?
17:01:32 <tflink> #chair adamw
17:01:32 <zodbot> Current chairs: adamw tflink
17:01:40 <adamw> yo
17:01:48 <adamw> SUPER BLOCKER REVIEW POWER GO GO GO!
17:02:11 * tflink gets an image of the planeteers from captain planet
17:02:25 <tflink> with our blocker review powers combined ...
17:03:30 * brunowolff is here
17:03:44 <tflink> brunowolff: welcome!
17:04:59 * tflink waits a couple more minutes to see if we get anyone else
17:05:30 <adamw> i have the anaconda team's proxy. their response to everything is 'noloader fixes that'.
17:05:43 * nirik is lurking
17:05:49 <tflink> adamw: any idea when we're going to get a build for testing?
17:05:56 <tflink> it sounded like we might get something today
17:06:10 <adamw> yeah, that's what they're hoping for.
17:07:42 <tflink> ok, lets see if we can get this working with the people present
17:07:55 <tflink> #topic introduction
17:08:15 <tflink> just in case anyone's not familiar with the process ...
17:08:23 <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:08:38 <tflink> #link https://fedoraproject.org/wiki/Fedora_17_Beta_Release_Criteria
17:08:38 <tflink> #link https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting
17:08:53 <tflink> We'll be working off of the following list of blocker/NTH bugs
17:09:02 <tflink> #link https://fedoraproject.org/wiki/Current_Release_Blockers
17:09:15 <tflink> #info 8 proposed blockers
17:09:15 <tflink> #info 9 accepted blockers
17:09:15 <tflink> #info 0 proposed NTH
17:09:35 <tflink> if there are no objections, I'm going to start with the proposed blockers
17:10:14 <tflink> #topic (538499) IPv6-only network attachment fails, due to IPv4 addressing being considered mandatory
17:10:17 <tflink> #link http://bugzilla.redhat.com/show_bug.cgi?id=538499
17:10:19 <bugbot_> Bug 538499: medium, low, ---, dcbw, ASSIGNED, IPv6-only network attachment fails, due to IPv4 addressing being considered mandatory
17:10:20 <tflink> #info Proposed Blocker, ASSIGNED
17:11:30 <adamw> so this is more IPv6 stuff
17:11:30 * tflink looks for last week's minutes to figure out what the conclusion was on ipv6 bugs
17:11:40 <adamw> we're making them blockers.
17:12:05 <tflink> so this one would be a blocker?
17:12:08 <adamw> +1 on this one, it does genuinely prevent an IPv6-only connection happening
17:12:08 <adamw> yeah
17:12:32 <tflink> are we just using the network criteria?
17:12:42 <adamw> dan says (via email) "I just pushed your patch for this one to git master and it'll show up in the next F17 snapshot."
17:12:43 <adamw> yeah
17:13:31 <tflink> proposed #agreed 538499 - AcceptedBlocker - The installed system must be able to download and install updates with yum and the default graphical package manager in all release-blocking desktops
17:13:38 <brunowolff> +1
17:13:45 <tflink> ack/nak/patch?
17:15:06 <adamw> ack
17:15:17 <tflink> #agreed 538499 - AcceptedBlocker - The installed system must be able to download and install updates with yum and the default graphical package manager in all release-blocking desktops
17:15:26 <tflink> #topic (798697) The default IPv6 mode is "Ignore" for implicit/ifcfg-less connection profiles (e.g. wired ethernet)
17:15:30 <tflink> #link http://bugzilla.redhat.com/show_bug.cgi?id=798697
17:15:31 <bugbot_> Bug 798697: unspecified, unspecified, ---, dcbw, NEW, The default IPv6 mode is "Ignore" for implicit/ifcfg-less connection profiles (e.g. wired ethernet)
17:15:32 <tflink> #info Proposed Blocker, NEW
17:15:48 * tflink isn't as sure this one's a blocker
17:16:06 <adamw> i'd say it is.
17:16:14 <tflink> it sounds like network is functioning but only ipv4 on a network that has both v4 and v6
17:16:31 <adamw> no
17:16:38 <adamw> it affects all networks.
17:16:45 <adamw> doesn't have to be a mixed network.
17:16:55 <adamw> read comment #3.
17:17:07 <adamw> basically, NM doesn't do anything with IPv6 by default, on any connection.
17:17:32 <brunowolff> What if ip4 is used for the local network, but ip6 for getting to the outside world?
17:17:59 <brunowolff> That seems like it would be an issue for doing updates.
17:18:10 <adamw> as things stand, NM just isn't going to set up an IPv6 connection at all (do DHCP and consider it connected), unless you manually go in and change from 'Ignore' to 'Automatic'.
17:18:49 <tflink> proposed #agreed - 798697 - AcceptedBlocker - The installed system must be able to download and install updates with yum and the default graphical package manager in all release-blocking desktops
17:19:39 <adamw> ack
17:19:45 <brunowolff> +1
17:19:49 <tflink> #agreed - 798697 - AcceptedBlocker - The installed system must be able to download and install updates with yum and the default graphical package manager in all release-blocking desktops
17:19:59 <tflink> #topic (753421) FSError: failed to get block size for ext4 filesystem on /dev/md127
17:20:02 <tflink> #link http://bugzilla.redhat.com/show_bug.cgi?id=753421
17:20:04 <bugbot_> Bug 753421: unspecified, unspecified, ---, dlehman, ASSIGNED, FSError: failed to get block size for ext4 filesystem on /dev/md127
17:20:04 <tflink> #info Proposed Blocker, ASSIGNED
17:20:46 <adamw> so we previously approved this, but i dropped it back to proposed as it seems to be different from what we thought
17:21:20 <tflink> yeah, this sounds quite a bit more isolated than we previously thought
17:22:10 <tflink> I'm thinking -1 blocker -1 NTH
17:22:37 <adamw> as currently described, yeah.
17:22:56 <adamw> it'd be nice to verify that doing an f16 install with soft RAID and upgrading to F17 succeeds, but right now, it looks like -1.
17:24:02 <tflink> proposed #agreed - 753421 - RejectedBlocker - Our current understanding of the bug is that it is more isolated than previously thought but verification with 16 to 17 upgrade using sw RAID would be good
17:24:36 <brunowolff> ack
17:24:38 <adamw> ack
17:24:55 <tflink> #agreed - 753421 - RejectedBlocker - Our current understanding of the bug is that it is more isolated than previously thought but verification with 16 to 17 upgrade using sw RAID would be good
17:25:04 <tflink> #topic (802241) system halts at first reboot after installation with specific kickstart file
17:25:07 <tflink> #link http://bugzilla.redhat.com/show_bug.cgi?id=802241
17:25:09 <bugbot_> Bug 802241: unspecified, unspecified, ---, anaconda-maint-list, NEW, system halts at first reboot after installation with specific kickstart file
17:25:10 <tflink> #info Proposed Blocker, NEW
17:25:46 <brunowolff> -1 blocker -1 nth
17:25:47 <tflink> I'm not sure that we have enough information on this one
17:26:45 <tflink> that's a really simple KS - if it's failing, there could be other problems
17:26:56 <adamw> yeah, i think punting on this may be best
17:26:58 <tflink> but the bug really doesn't have a whole lot of data
17:27:19 <bcl> his minimal ks used to boot fine. in f17 it doesn't.
17:27:29 <adamw> i guess it'd be easy enough for us to reproduce.
17:27:42 <adamw> bcl: right, but we need to figure out _why not_. what's actually going wrong.
17:27:51 <adamw> it might point to a package missing from the base group or something, i guess.
17:27:52 <bcl> I reproduced it. but I don't think it is a blocker, probably needs something added to the ks.
17:27:55 <tflink> proposed #agreed - 802241 - This bug could be a blocker-worthy issue but more information on what exactly is failing before deciding on the bug's status
17:28:20 <bcl> I'm not sure what's expected from minimal packages.
17:28:35 <bcl> using it with 'minimal' from anaconda boots fine.
17:28:44 <bcl> (eg. remove package section)
17:28:57 <brunowolff> I don't think minimal package set working is something we block on though.
17:28:57 <adamw> so it seems we are looking at a comps issue?
17:29:22 <adamw> hum. base-x is the difference, i think. i guess it suggests that group is broken.
17:29:29 <adamw> if that's the case i'd probably be -1 blocker.
17:29:38 <tflink> wasn't there something else about issues with base-x?
17:30:19 <tflink> it sounds like we're pretty much -1 blocker on this, though
17:30:55 <adamw> if it's just a bug with the base-x group then yeah, that doesn't hit any criteria i can think of.
17:31:15 <adamw> i guess base-x doesn't actually include everything needed to get a default graphical.target to start successfully.
17:31:42 <brunowolff> I don't think it is a blocker unless the issue really turns out to be more widespread. It might be NTH depending on what the underlying problem is.
17:32:09 <tflink> proposed #agreed - 802241 - RejectedBlocker - This is an issue with either comps or the kickstart file as written and not with the kickstart system itself. Therefore this bug does not violate any criteria for beta.
17:32:31 <brunowolff> ack
17:32:32 <adamw> ack
17:32:43 <tflink> #agreed - 802241 - RejectedBlocker - This is an issue with either comps or the kickstart file as written and not with the kickstart system itself. Therefore this bug does not violate any criteria for beta.
17:32:50 <tflink> #topic (770197) Shell runs on GeForce2 MX, but it is too buggy to be usable
17:32:54 <tflink> #link http://bugzilla.redhat.com/show_bug.cgi?id=770197
17:32:55 <bugbot_> Bug 770197: unspecified, unspecified, ---, rstrode, NEW, Shell runs on GeForce2 MX, but it is too buggy to be usable
17:32:56 <tflink> #info Proposed Blocker, NEW
17:35:03 <drago01> ugh ... we shouldn't try to start gs on nv < 20 or radeon < 300 neither on intel < 915
17:35:21 <adamw> fuck. my system just exploded. and the phone is ringing.
17:35:35 <brunowolff> I suspect the number of users affected by this is low enough that we don't want to call this a blocker. But adding to a whitelist is pretty safe, so NTH seams reasonable.
17:35:38 <tflink> it sounds like one of the proposed fixes is to update the blacklist
17:36:44 <drago01> which makes sense
17:36:47 <brunowolff> Gnome shell doesn't work on nv28s either. I tried turning off forced fallback and ended up having to disable it again remotely.
17:36:48 <drago01> that's all we can do here
17:37:05 <adamw> i've been talking to the gnome and x teams about this
17:37:08 <drago01> brunowolff: it should though ... if it doesn't the driver is broken
17:37:34 <adamw> seems to be general agreement to update the blacklist, but we need to determine if we blacklist all vieux cards (everything GeForce 4 and earlier) or something narrower
17:37:35 <tflink> drago01: assuming that the upstream work mentioned in c6 doesn't make F17?
17:38:11 <tflink> nvm, I seem to be slow today
17:38:25 <drago01> tflink: it might get it to work but not sure about what performance will be
17:38:33 <drago01> the hardware is just not good enough
17:38:40 * adamw has to restart X, brb
17:39:04 <tflink> the question remains whether this is blocker material or just NTH since the cards in question are so old
17:39:23 <tflink> I'd definitely be +1 NTH. not as sure about blocker
17:40:31 <tflink> any other thoughts?
17:40:42 <adamw> it's...pretty icky. maybe final blocker not beta, though.
17:40:44 <adamw> it's probably okay to document something like this for beta at least.
17:40:57 <drago01> yeah for final I'd say blocker +1
17:40:58 <drago01> for beta +0
17:41:15 <brunowolff> For Beta I am -1 blocker, +1 NTH unless there is evidence that a lot of people are using this hardware.
17:41:19 <tflink> final blocker, beta NTH?
17:41:32 <drago01> (not -1 because it shoud be easy to fix but that doesn't count hence 0)
17:42:35 <adamw> i'm ack to final blocker, beta nth on the basis of breadth of impact
17:42:46 <adamw> i think there are probably _enough_ old nvidia cards out there that we shouldn't ship with this busted
17:42:51 <tflink> proposed #agreed 770197 - RejectedBlocker (Beta) AcceptedBlocker (Final) AcceptedNTH (Beta) - While this does prevent affected systems from using gnome-shell, those systems are assumed to be few enough in number that this doesn't need to be a beta blocker
17:43:09 <adamw> especially combined with the bug which breaks NV3x and possibly NV4x - between those two bugs, virtually the entire first half of NVIDIA's history is broken with Shell.
17:43:11 <brunowolff> ack
17:43:17 <adamw> ack
17:43:24 <tflink> #agreed 770197 - RejectedBlocker (Beta) AcceptedBlocker (Final) AcceptedNTH (Beta) - While this does prevent affected systems from using gnome-shell, those systems are assumed to be few enough in number that this doesn't need to be a beta blocker
17:43:33 <tflink> #topic (802106) ipw2200 bg doesn't work in f17
17:43:33 <tflink> #link http://bugzilla.redhat.com/show_bug.cgi?id=802106
17:43:33 <tflink> #info Proposed Blocker, NEW
17:43:34 <bugbot_> Bug 802106: unspecified, unspecified, ---, sgruszka, NEW, ipw2200 bg doesn't work in f17
17:46:25 <tflink> do we have any idea how common this wireless chipset is?
17:46:27 <brunowolff> I don't have a good feel for how many people this will affect.
17:46:49 <drago01> it used to be very common in older centrio generations
17:46:56 <drago01> shouldn't be on new hardware
17:47:14 <drago01> but there should still a number of such systems aroudn
17:47:18 <drago01> *around
17:47:28 <adamw> it's the same kind of deal
17:47:32 <adamw> (as the nvidia bug)
17:47:34 <drago01> it was the most commonly used wireless chip in the days it shipped
17:47:36 <adamw> it was *very* popular several years ago
17:47:38 <adamw> yup
17:48:04 * drago01 has to go
17:48:14 <tflink> which makes it sounds more blockery
17:48:14 <adamw> it was the first generation of laptops where everyone basically went with intel's combined platform - cpu, sound, wireless etc
17:48:40 <adamw> i think we're talking, what, 4 generations back?
17:48:53 <adamw> 2200, 3945, 4something, now we're on 5
17:49:03 <drago01> we have 6xxx now
17:49:27 <adamw> oh yeah
17:49:34 <adamw> 2xxx, 3xxx, 4xxx, 5xxx, 6xxx
17:49:52 <tflink> well, we could take it as a NTH and wait on a response from the person who seemed interested in updating the code
17:50:27 <adamw> i think again nth is okay for beta
17:50:33 <tflink> on the other hand, I think I'd rather wait until we knew what the fix was
17:50:34 <adamw> might be a more marginal call for final
17:51:36 <adamw> god, smolt is useless.
17:51:39 * adamw trying to get numbers from smolt
17:52:04 <tflink> I could look at the smolt db dump I have for F15 and F16
17:52:15 <tflink> but that would take more than a couple minutes
17:52:51 <adamw> yeah, for now should we just make it beta nth and move on?
17:52:55 <adamw> nth doesn't mean we *have* to take the fix
17:53:00 <tflink> true
17:53:02 <adamw> so if it turns out to be too invasive we just ...don't take it
17:53:41 <tflink> proposed #agreed - 802106 - AcceptedNTH - While this is an older wireless chipset, it was very common and a well tested fix would be accepted
17:53:51 <brunowolff> ack
17:54:07 <tflink> #action tflink to search smolt for numbers on ipw2200
17:54:26 <adamw> ack
17:54:42 <tflink> #agreed - 802106 - AcceptedNTH - While this is an older wireless chipset, it was very common and a well tested fix would be accepted
17:54:55 <tflink> #topic (803086) libosinfo depends on perl
17:54:56 <tflink> #link http://bugzilla.redhat.com/show_bug.cgi?id=803086
17:54:56 <tflink> #info Proposed Blocker, ON_QA
17:54:57 <bugbot_> Bug 803086: unspecified, unspecified, ---, berrange, ON_QA, libosinfo depends on perl
17:55:19 <brunowolff> -1 blocker, -1 nth
17:55:39 <tflink> same here
17:56:20 <tflink> proposed #agreed 803086 - RejectedBlocker - Unless the extra packages cause the live images to go over 700M, this doesn't hit any release criteria
17:56:42 <brunowolff> I might feel differently if one of the spins were currently oversize.
17:57:16 <brunowolff> (Games was, but I'd have had to drop FlightGear anyway, since it got a lot bigger in its latest release.)
17:57:21 <adamw> ack
17:57:26 <brunowolff> ack
17:57:29 <tflink> it's been fixed, anyways. as long as the build gets karma it'll get into beta
17:57:36 <tflink> #agreed 803086 - RejectedBlocker - Unless the extra packages cause the live images to go over 700M, this doesn't hit any release criteria
17:57:43 <tflink> #topic (745202) gnome-shell does not display correctly with many NV3x and NV4x adapters
17:57:46 <tflink> #link http://bugzilla.redhat.com/show_bug.cgi?id=745202
17:57:48 <bugbot_> Bug 745202: high, unspecified, ---, bskeggs, NEW, gnome-shell does not display correctly with many NV3x and NV4x adapters
17:57:48 <tflink> #info Proposed Blocker, NEW
17:59:31 <adamw> the hell? my entire desktop just crashed, launching totem.
17:59:35 <adamw> and abrt got nothing.
17:59:39 <adamw> oh, X crash. fun times.
18:00:20 <tflink> what is the proposed fix here?
18:00:22 <brunowolff> This seems to affect enough people, that we want to block on it.
18:01:25 <brunowolff> If we take it as a blocker, this is a scary bug though.
18:02:17 <tflink> yeah, it is
18:02:33 <tflink> does this affect enough people to justify slipping beta?
18:02:39 <adamw> the proposed 'fix' is to blacklist the cards until the driver's fixed.
18:02:52 <adamw> it sure affects a lot of people. get reports of it frequently.
18:02:53 <tflink> ok, that's far less scary
18:03:05 <adamw> yeah, blacklisting should be reasonably easy to do.
18:03:12 <tflink> are we looking at a major nouveau update for F17?
18:03:23 <adamw> i'm discussing this one also and again there seems to be general agreement to blacklist until the nvfx rewrite is done. and works.
18:03:25 <brunowolff> Yeah, if a simple blacklisting gets us some more time that seems a lot less scary.
18:03:43 <adamw> tflink: aiui we're looking at a significant update of the code _specifically for these cards_
18:03:55 <adamw> not for newer ones which are working
18:04:30 <tflink> proposed #agreed - 745202 - AcceptedBlocker - after firstboot is completed and on subsequent boots, a system installed according to any of the above criteria must boot to a working graphical environment without unintended user intervention. This includes correctly accessing any encrypted partitions when the correct passphrase is supplied
18:04:37 <brunowolff> ack
18:04:49 <tflink> adamw: darn, I was hoping to ditch the binary blob on my desktop since nouveau crashes on F16 with it
18:05:10 <adamw> have you filed that?
18:05:17 <adamw> ack
18:05:24 <tflink> adamw: I'm pretty sure it was filed for F16
18:05:35 <tflink> I haven't even tried F17 yet
18:05:48 <adamw> k
18:05:50 <tflink> #agreed - 745202 - AcceptedBlocker - after firstboot is completed and on subsequent boots, a system installed according to any of the above criteria must boot to a working graphical environment without unintended user intervention. This includes correctly accessing any encrypted partitions when the correct passphrase is supplied
18:06:05 <tflink> I should, though since it's a new nvidia card
18:06:29 <tflink> OK, that's it for the proposed blockers
18:06:43 <tflink> since there are no proposed NTH, I'm going to dive into the accepted blockers
18:06:52 <tflink> #topic (801782) Updates notification doesn't show up
18:06:53 <tflink> #link http://bugzilla.redhat.com/show_bug.cgi?id=801782
18:06:53 <tflink> #info Accepted Blocker, ASSIGNED
18:06:54 <bugbot_> Bug 801782: unspecified, unspecified, ---, debarshi.ray, ASSIGNED, Updates notification doesn't show up
18:08:03 <tflink> sounds like this is still waiting for testing
18:09:03 <tflink> I don't think there's much to say other than to request re-testing with the modification from comment 7
18:09:26 <adamw> yeah, we sucked at re-testing this week :(
18:09:40 <adamw> though we did get useful info for forcing the check to happen faster
18:09:42 <tflink> proposed #agreed - 801782 - This needs to be re-tested in order to verify whether or not this is a bug or not
18:09:45 <adamw> ack
18:09:52 <tflink> #agreed - 801782 - This needs to be re-tested in order to verify whether or not this is a bug or not
18:09:52 <adamw> we don't really need #agreeds for all accepted blockers
18:09:58 <adamw> you can just unilaterally do #infos, really
18:10:02 <adamw> makes things move faster
18:10:08 <tflink> either way
18:10:10 <tflink> #topic (742207) No usable bootloader option during a text mode f15->f16 upgrade
18:10:14 <tflink> #link http://bugzilla.redhat.com/show_bug.cgi?id=742207
18:10:15 <bugbot_> Bug 742207: high, unspecified, ---, bcl, MODIFIED, No usable bootloader option during a text mode f15->f16 upgrade
18:10:16 <tflink> #info Accepted Blocker, MODIFIED
18:10:41 <tflink> sounds like we're just waiting for a new offical image for retesting before closing it
18:11:03 <tflink> #info bug has been reported to be fixed, waiting for re-test with official builds/images before closing
18:11:15 <tflink> #topic (787893) Anaconda needs to handle /usr move preparation on upgrade for F17
18:11:19 <tflink> #link http://bugzilla.redhat.com/show_bug.cgi?id=787893
18:11:20 <bugbot_> Bug 787893: urgent, unspecified, ---, bcl, ON_QA, Anaconda needs to handle /usr move preparation on upgrade for F17
18:11:21 <tflink> #info Accepted Blocker, ON_QA
18:11:34 <tflink> sounds like this is in the exact same boat
18:11:59 <tflink> #info fix has made it into anaconda, needs to be retested
18:12:10 <adamw> yup. we really should do some of that 'testing' stuff i hear so much about.
18:12:15 <tflink> wait, what anaconda build is in tc1?
18:12:44 <adamw> i asked for 17.12 in the ticket
18:12:48 <adamw> so i'm assuming 17.12
18:12:55 <tflink> #undo
18:12:55 <zodbot> Removing item from minutes: <MeetBot.items.Info object at 0x1aa1a610>
18:13:25 <tflink> #info fix is in anaconda-17.12 which should be in F17 beta TC1, this needs to be retested in order to verify the fix
18:13:49 <tflink> #topic (796155) iface_ip2str returned NULL
18:13:49 <tflink> #link http://bugzilla.redhat.com/show_bug.cgi?id=796155
18:13:49 <tflink> #info Accepted Blocker, NEW
18:13:51 <bugbot_> Bug 796155: unspecified, unspecified, ---, rvykydal, NEW, iface_ip2str returned NULL
18:14:19 <tflink> this sounds like the default anaconda-bot answer for now - try it with noloader
18:14:37 <adamw> also looks like anaconda team is waiting for info from dan
18:14:50 <adamw> but yeah, we should check with noloader
18:15:09 <tflink> #info this bug is hopefully fixed with the noloader functionaltiy that should land soon, this needs to be retested with new anaconda builds
18:15:22 <tflink> looks like I'm going to be building some test images after the meeting
18:15:33 <tflink> #topic (798373) live image failed to boot in 3 runlevel
18:15:33 <tflink> #link http://bugzilla.redhat.com/show_bug.cgi?id=798373
18:15:33 <tflink> #info Accepted Blocker, ON_QA
18:15:35 <bugbot_> Bug 798373: unspecified, unspecified, ---, mgracik, ON_QA, live image failed to boot in 3 runlevel
18:16:06 <tflink> is this one in TC1, too?
18:17:13 <adamw> um, probably not
18:17:20 <adamw> since it didn't go stable and i didn't request it
18:17:38 <tflink> ok, I'll include it in the test image
18:17:45 <adamw> it has sufficient karma to be pushed stable now, we could ask mgracik to push it
18:18:03 <tflink> #info new build has been created, waiting for re-testing before confirming fix
18:18:10 <adamw> but might be good just to test it and make it hit +3.
18:18:56 <tflink> let's give that a try - if there are no major explosions in the noloader anaconda, it would be nice to do it that way
18:19:07 <tflink> #topic (736993) error install bootloader with serial interface install
18:19:10 <tflink> #link http://bugzilla.redhat.com/show_bug.cgi?id=736993
18:19:12 <bugbot_> Bug 736993: medium, unspecified, ---, pjones, MODIFIED, error install bootloader with serial interface install
18:19:13 <tflink> #info Accepted Blocker, MODIFIED
18:19:32 <tflink> adamw: didn't you submit an update with the new grub to fix this?
18:19:52 <adamw> pjones did.
18:20:14 <tflink> either way, needs confirmation
18:20:32 <adamw> yeah
18:20:39 <adamw> i guess an install with updates-testing should pull it in.
18:20:40 <tflink> #info update containing the fix for this has been submitted, needs testing in order to verify fix
18:21:12 <tflink> #topic (800205) kernel panic after running preupgrade
18:21:12 <tflink> #link http://bugzilla.redhat.com/show_bug.cgi?id=800205
18:21:12 <tflink> #info Accepted Blocker, ASSIGNED
18:21:13 <bugbot_> Bug 800205: urgent, urgent, ---, hughsient, ASSIGNED, kernel panic after running preupgrade
18:21:56 <tflink> looks like we don't 100% have a fix for this yet
18:22:14 <adamw> is noloader meant to fix the 'parent' bug?
18:22:16 <tflink> who might have an answer for the question in comment 9?
18:22:26 <tflink> I didn't think that preupgrade used anaconda
18:22:42 <tflink> or does noloader hit dracut, too?
18:23:32 <adamw> preupgrade does use anaconda.
18:23:47 <tflink> anaconda-bot answer, then :)
18:23:49 <adamw> all it does is download all the packages needed for the upgrade, then reboot into anaconda to do the upgrade.
18:24:02 <adamw> this is the firstboot-special-case version of the infamous root= bug
18:24:12 <adamw> i just realized that's not actually written in the bug anywhere, so i've added a comment to that effect
18:24:26 <tflink> #info hopefully, this will be fixed with the noloader anaconda build and needs re-testing once that lands
18:24:37 <tflink> #topic (591630) DHCPv6 responses are not allowed by default ip6tables ruleset
18:24:41 <tflink> #link http://bugzilla.redhat.com/show_bug.cgi?id=591630
18:24:43 <bugbot_> Bug 591630: high, urgent, ---, twoerner, ASSIGNED, DHCPv6 responses are not allowed by default ip6tables ruleset
18:24:43 <tflink> #info Accepted Blocker, ASSIGNED
18:25:15 <tflink> sounds like no movement since last week
18:25:29 <tflink> unless I just missed a proposed fix
18:26:22 <tflink> yep, the patch is right there
18:26:46 <tflink> #info patch has yet to be applied, nothing to test yet
18:27:12 <tflink> who do we poke about s-c-firewall?
18:27:28 <adamw> twoerner
18:27:33 <adamw> he has commented to some extent on the -devel thread
18:27:46 <adamw> "There will be a dhcpv6 service entry for firewalld soon and later on
18:27:46 <adamw> also for system-config-firewall.
18:27:46 <adamw> Where how and when it will and could be enabled will be evaluated."
18:28:09 <adamw> spot also proposed an alternative patch
18:28:39 <spot> adamw: twoerner emailed me and asked me not to commit it, said he was working on something else.
18:28:48 <adamw> okay
18:29:03 <adamw> could you ask him to update the bug? we really need blocker bugs to be updated with info on what's happening. it's hard to work blind.
18:29:17 <tflink> ok, it sounds like there has been movement on this outside bz and we're still waiting for a patch
18:29:33 <tflink> #undo
18:29:33 <zodbot> Removing item from minutes: <MeetBot.items.Info object at 0x28d35c50>
18:29:53 <tflink> #info a fix is being worked on, will need to re-test once a new build is available
18:30:31 <tflink> #info request update in BZ so that we can better track progress of this bug
18:30:42 <tflink> #topic (754568) [abrt] gnome-shell-3.2.1-6.fc17: _int_free: Process /usr/bin/gnome-shell was killed by signal 11 (SIGSEGV)
18:30:45 <tflink> #link http://bugzilla.redhat.com/show_bug.cgi?id=754568
18:30:47 <bugbot_> Bug 754568: urgent, unspecified, ---, airlied, ON_QA, [abrt] gnome-shell-3.2.1-6.fc17: _int_free: Process /usr/bin/gnome-shell was killed by signal 11 (SIGSEGV)
18:30:48 <tflink> #info Accepted Blocker, ON_QA
18:31:14 <tflink> fix is available, needs testing
18:31:34 <tflink> #info a fix for this is available, re-testing is needed
18:32:09 <adamw> yeah, that's exciting
18:32:15 <adamw> i'll try and work on re-testing this, should be easy enough
18:32:22 <tflink> cool, sounds good
18:32:55 <tflink> well, that's all of the accepted blockers
18:33:01 <tflink> #topic open floor
18:33:14 <tflink> is there anything else to cover or bugs that I missed?
18:33:32 <adamw> can't think of a lot, we really need to get going on the re-testing it sounds like
18:33:33 <brunowolff> Will f18 move on to 3.4 right after the merge window closes?
18:33:49 <brunowolff> Sorry wrong window.
18:34:28 <tflink> yeah, I'll get started on a test image after the meeting - assuming that the new anaconda build works well enough
18:35:56 <tflink> Other than the need to re-test a bunch of stuff, I don't think that there's much else to say
18:36:29 <tflink> #info F17 Beta Blocker Bug Review #4 will be on 2012-03-23 @ 17:00 UTC
18:36:40 * tflink sets fuse for ~ 5 minutes
18:43:48 <tflink> Thanks for coming, everyone!
18:43:52 <tflink> #endmeeting