17:02:05 <tflink> #startmeeting F16-final-blocker-review
17:02:05 <zodbot> Meeting started Fri Oct  7 17:02:05 2011 UTC.  The chair is tflink. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:02:05 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
17:02:22 <tflink> #meetingname F16-final-blocker-review-2
17:02:22 <zodbot> The meeting name has been set to 'f16-final-blocker-review-2'
17:02:27 <tflink> #topic roll call
17:02:33 <tflink> so, who's ready for happy fun time?
17:02:49 * nirik is lurking, feel free to ping if i can help with anything.
17:02:51 <adamw> here sir
17:03:17 * adamw will secretaryize
17:03:35 <tflink> adamw: much appreciated
17:04:00 * brunowolff is here
17:04:11 <tflink> brunowolff: welcome to the party!
17:04:57 <adamw> hey andre
17:05:08 * tflink waits another minute or so before starting
17:05:18 <brunowolff> As a side note, I am hoping my machine crashes soon so I can get a traceback. If so, I'll disappear for a bit.
17:07:03 <tflink> #topic Why Are We Here?
17:07:26 <tflink> this could be a more existential question, but ...
17:07:30 <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:43 <tflink> up for review today are:
17:08:02 <adamw> i thought we were here to rock?
17:08:06 <tflink> #info 20 proposed blockers, 10 accepted blockers, 7  proposed NTH
17:08:37 <tflink> adamw: rock, review blocker bugs ... same thing :)
17:08:49 <tflink> if there are no objections, I was going to start with the proposed blockers
17:09:46 <tflink> #topic (742042) anaconda should ensure the correct bootloader #topic (grub-efi or grub2) is installed on upgrade from F15, and remove grub
17:09:49 <tflink> #link http://bugzilla.redhat.com/show_bug.cgi?id=742042
17:09:52 <tflink> #info Proposed Blocker, NEW
17:10:21 <tflink> woah, template fail
17:10:28 <tflink> #undo
17:10:28 <zodbot> Removing item from minutes: <MeetBot.items.Info object at 0x18fabd6c>
17:10:30 <tflink> #undo
17:10:30 <zodbot> Removing item from minutes: <MeetBot.items.Link object at 0x1ac3208c>
17:10:32 <tflink> #undo
17:10:32 <zodbot> Removing item from minutes: <MeetBot.items.Topic object at 0x1435d70c>
17:10:50 <tflink> #topic (742042) anaconda should ensure the correct bootloader (grub-efi or grub2) is installed on upgrade from F15, and remove grub
17:10:53 <tflink> #link http://bugzilla.redhat.com/show_bug.cgi?id=742042
17:10:55 <tflink> #info Proposed Blocker, NEW
17:10:56 <tflink> better
17:11:16 <adamw> we have a little thicket of grub bugs that pjones is working on
17:11:54 <nirik> is grub-efi a subpackage? or a new package on its own? or ?
17:11:55 <adamw> to shore up the handling of both efi and bios cases on install and upgrade (hopefully) so we never wind up with the wrong bootloader installed or conflicting packages or anything
17:12:10 <adamw> it's a new sub-package of the grub .src.rpm, but it's 'independent' - it doesn't require grub
17:12:29 <adamw> the end goal is that if you're running f16 from bios you have grub2 and if you're running it from efi you have grub-efi, no-one should really have grub any more
17:12:45 * nirik thinks it's a bit confusing, but ok.
17:12:55 <tflink> do we want to say that this is EFI related or general installer related?
17:13:03 <tflink> "The installer must boot and run on systems using EFI other than Apple Macs"
17:13:13 <adamw> the actual issue in beta is not efi related
17:13:32 <adamw> if you do an f15->f16 upgrade with beta you wind up with both grub and grub2 installed, and your first post-upgrade yum operation will complain about it
17:13:50 <tflink> ah
17:14:05 <adamw> this bug is now pretty much a catch-all for 'anaconda's got to do the right thing with grub when you upgrade'
17:14:16 <tflink> "The installer must be able to successfully complete an upgrade installation from a clean, fully updated default installation (from any official install medium) of the previous stable Fedora release, either via preupgrade or by booting to the installer manually. The upgraded system must meet all release criteria"
17:14:18 <adamw> once all the grub changes are in place i'll test both upgrade paths and close the bug if they're okay
17:14:47 <adamw> yeah - the upgraded system doesn't precisely meet all release criteria as you can't install updates. easy workaround - remove grub - so it wasn't too critical for beta, but it does need fixing.
17:15:13 <brunowolff> When grub2 replaces grub does it pick up custom kernel parameters?
17:15:30 <dgilmore> dont think so
17:16:20 <adamw> no.
17:16:43 <brunowolff> Will that be noted in the release notes?
17:16:44 <adamw> anyway, votes on the bug? i'm +1 due to the impact described above.
17:16:51 <brunowolff> +1 blocker
17:16:54 <adamw> brunowolff: if we get around to it. release notes have been frozen for a while, technically.
17:16:55 <nirik> if folks can, updating http://fedoraproject.org/wiki/Grub2 would be welcome too. ;)
17:17:26 <dgilmore> adamw: +1 from me
17:17:41 <tflink> I'm +1 too
17:17:45 <nirik> +1 too
17:18:24 <tflink> proposed #agreed - 742042 - AcceptedBlocker - The installer must be able to successfully complete an upgrade installation from a clean, fully updated default installation (from any official install medium) of the previous stable Fedora release, either via preupgrade or by booting to the installer manually. The upgraded system must meet all release criteria
17:18:31 <tflink> ack/nak/patch?
17:18:35 <brunowolff> My video card doesn't work right without disabling agp, so its something I need to watch for when grub2 obsoletes grub.
17:19:05 <nirik> aCK
17:19:20 <brunowolff> ack
17:19:49 <adamw> ack
17:19:51 <tflink> #agreed - 742042 - AcceptedBlocker - The installer must be able to successfully complete an upgrade installation from a clean, fully updated default installation (from any official install medium) of the previous stable Fedora release, either via preupgrade or by booting to the installer manually. The upgraded system must meet all release criteria
17:20:00 <tflink> #topic (742888) F16Beta Anaconda crashes when trying to rescue install on BIOS RAID
17:20:03 <tflink> #link http://bugzilla.redhat.com/show_bug.cgi?id=742888
17:20:05 <tflink> #info Proposed Blocker, ASSIGNED
17:20:50 <tflink> hrm, it sounds like the reporter is having trouble reproducing the issue
17:22:16 <tflink> I'm thinking punt for a week, see if can be reproduced and reject next week if not
17:22:30 <tflink> since dlehman couldn't repro it either
17:22:45 <dgilmore> works for me
17:22:45 <adamw> i'd rather kick it off now and re-propose if anyone can reproduce
17:22:52 <dgilmore> that works also
17:22:54 <adamw> it does look to be pretty likely an unreproducible to do with dirty raid state
17:23:02 <tflink> works for me
17:23:42 <adamw> so i'm -1
17:24:12 <tflink> proposed #agreed - 742888 - RejectedBlocker - This looks like a one-time issue as neither the reporter nor the developer can reproduce it. Re-propose if it is eventually reproduced.
17:24:20 <tflink> ack/nak/patch?
17:24:56 <brunowolff> ack
17:25:16 <adamw> ack
17:25:19 <tflink> #agreed - 742888 - RejectedBlocker - This looks like a one-time issue as neither the reporter nor the developer can reproduce it. Re-propose if it is eventually reproduced.
17:25:26 <tflink> #topic (743281) Disk encryption with national keymap doesn't work
17:25:26 <tflink> #link http://bugzilla.redhat.com/show_bug.cgi?id=743281
17:25:26 <tflink> #info Proposed Blocker, NEW
17:25:41 <adamw> this is a 'grey area' bug but it's a bit icky
17:26:16 * tflink wonders if this is related to the keyboard issues with unlocking gnome
17:27:04 <adamw> possibly, though more likely some anaconda thin
17:27:20 <clumens> i don't see how it's an anaconda thing.
17:28:25 <clumens> unless the keyboard variant just isn't getting set at all, which should be easy to check elsewhere too
17:28:29 <adamw> hum
17:28:35 <adamw> s-s-k?
17:28:52 <dgilmore> that should be testable by setting the keyboard to us and hitting tah same keys
17:29:12 <adamw> i guess we can look at what's different between the keymaps listed as working and those listed as not working
17:29:22 <dgilmore> if it unlocks keyboard is not set right when the encryption is setup
17:29:48 <dgilmore> adamw: i think this looks like a blocker. but we really need some more data
17:30:02 <tflink> yeah, I'm also +1 blocker on this
17:30:06 <adamw> drago01 is usually useful on these bugs
17:30:10 <adamw> guess he's not around atm though
17:30:51 <adamw> +1 blocker from me anyway
17:30:51 <tflink> proposed #agreed - 743281 - AcceptedBlocker - Following on from the previous criterion, after firstboot is completed and on subsequent boots, a system installed according to any of the above criteria (or the appropriate Beta or Final criteria, when applying this criterion to those releases) must boot to a working graphical environment without unintended user intervention. This includes correctly accessing any encrypted partitions when the correct pa
17:30:54 <adamw> ack
17:30:57 <adamw> er
17:31:06 <dgilmore> ack
17:31:11 <brunowolff> ack
17:31:12 <tflink> adamw: patch, then?
17:31:16 <adamw> nope, ack
17:31:18 <nirik> Ack
17:31:25 <tflink> #agreed - 743281 - AcceptedBlocker - Following on from the previous criterion, after firstboot is completed and on subsequent boots, a system installed according to any of the above criteria (or the appropriate Beta or Final criteria, when applying this criterion to those releases) must boot to a working graphical environment without unintended user intervention. This includes correctly accessing any encrypted partitions when the correct passphrase
17:31:33 <adamw> i've cced whot and drago, hopefully they'll have some idas
17:31:33 <tflink> nice and long :-/
17:31:42 <tflink> #topic (743381) anaconda should install grub-efi when doing an EFI install
17:31:45 <tflink> #link http://bugzilla.redhat.com/show_bug.cgi?id=743381
17:31:48 <tflink> #info Proposed Blocker, MODIFIED
17:32:05 <dgilmore> +1
17:32:29 <tflink> proposed #agreed - 743381 - AcceptedBlocker - The installer must boot and run on systems using EFI other than Apple Macs
17:32:42 <nirik> akc
17:32:52 <nirik> ack even.
17:32:58 <brunowolff> ack
17:33:12 <tflink> #agreed - 743381 - AcceptedBlocker - The installer must boot and run on systems using EFI other than Apple Macs
17:33:22 <tflink> #topic (743240) F15->F16 yum update fails to boot new kernel
17:33:22 <tflink> #link http://bugzilla.redhat.com/show_bug.cgi?id=743240
17:33:22 <tflink> #info Proposed Blocker, ON_QA
17:34:03 <tflink> it sounds like this only happens via yum upgrade
17:34:11 <tflink> so I'm -1 blocker -1 NTH on this
17:34:40 <dgilmore> tflink: i did a yum upgrade yesterday on my laptop
17:34:47 <dgilmore> and did not experience that
17:35:00 <adamw> yeah, i'd like to know what exactly the bug was here
17:35:10 <tflink> proposed #agreed - 743240 - RejectedBlocker - yum is not a supported upgrade method
17:35:16 <adamw> i suspect it's not something that hits *all* yum upgrades, so yum may not actually be the issue
17:35:19 <brunowolff> ack
17:35:58 <adamw> the update says "fixed mdraid container handling"
17:35:58 * tflink wonders if the reporter had multiple hds
17:36:43 <adamw> http://pkgs.fedoraproject.org/gitweb/?p=dracut.git;a=commitdiff;h=cfb1dbbaea0ce6fc47f7904db0dad84a40bbc1c2 is the change
17:36:55 <dgilmore> tflink: since it was /dev/sdc i would say yes
17:36:57 <adamw> doesn't look particularly yum-y to me, i think this is more a configuration-specific issue
17:37:22 <dgilmore> adamw: yeah
17:37:35 <dgilmore> i bet any upgrade in that configuration would hit that issue
17:37:39 <adamw> yeah
17:38:48 <tflink> any other votes for ack/nak/patch?
17:39:24 <dgilmore> looks like its fixed in a dracut update
17:39:33 <adamw> dgilmore: the fix is the commit i linked above
17:39:34 <dgilmore> im kinda inclined to ack it as a blocker
17:39:39 <adamw> that's what change in that dracut update
17:39:52 <adamw> theoretically i would vote to punt and ask harald for info on what exactly the conditions to trigger the bug are
17:40:03 <dgilmore> adamw: right. really doesnt matter much what we say it should be fixed in final regardless
17:40:05 <adamw> but since it's fixed anyway i vote we do the above and expect it to be closed next week so we don't have to worry =)
17:40:32 <dgilmore> im good with that
17:40:42 <tflink> proposed #agreed - 743240 - We need more information on this bug in order to make a decision on blocker status
17:41:08 <adamw> ack
17:41:12 <dgilmore> ack
17:41:18 <tflink> #agreed - 743240 - We need more information on this bug in order to make a decision on blocker status
17:41:22 <tflink> #topic (706756) No translation on Login-Page of the reboot-menu
17:41:24 <tflink> #link http://bugzilla.redhat.com/show_bug.cgi?id=706756
17:41:27 <tflink> #info Proposed Blocker, NEW
17:41:33 <tflink> we forgot to propose the release criteria for i18n
17:42:15 <adamw> s/forgot/didn't get around to/
17:42:21 <adamw> it's on my todo list, i just didn't get down there yet :(
17:42:32 <tflink> either way
17:42:44 <tflink> I'd say skip it for now, nothing new yet
17:43:04 <tflink> #action adamw propose i18n release criteria
17:43:22 <tflink> since he was planning to do it anyways
17:43:32 <adamw> okay. if we don't get the criteria done by next week let's just make them up during the meeting
17:43:40 <dgilmore> adamw: ok
17:43:56 <dgilmore> incomplete translations make for a weird experience
17:44:07 <dgilmore> but i think they are always incomplete
17:44:17 <tflink> #agreed - 706756 - Still don't have i18n release criteria. If none have been proposed by next week, will make them in the next meeting.
17:44:35 <tflink> #topic (743376) Split grub-efi out from grub and have it not conflict with grub2
17:44:38 <tflink> #link http://bugzilla.redhat.com/show_bug.cgi?id=743376
17:44:41 <tflink> #info Proposed Blocker, MODIFIED
17:44:50 <dgilmore> +1
17:45:12 <tflink> proposed #agreed - 743376 - AcceptedBlocker - #topic (743376) Split grub-efi out from grub and have it not conflict with grub2
17:45:13 <adamw> this is kind of a prerequisite to sorting out the bootloader mess; we need grub for efi installs which doesn't conflict with grub2 or else we'll inevitably wind up with conflict issues somewhere
17:45:15 <tflink> #link http://bugzilla.redhat.com/show_bug.cgi?id=743376
17:45:16 <tflink> woah
17:45:18 <tflink> #undo
17:45:18 <zodbot> Removing item from minutes: <MeetBot.items.Link object at 0xf1a314c>
17:45:20 <tflink> #undo
17:45:20 <zodbot> Removing item from minutes: <MeetBot.items.Info object at 0xb90020c>
17:45:23 <tflink> #info Proposed Blocker, MODIFIED
17:45:25 <tflink> #undo
17:45:25 <zodbot> Removing item from minutes: <MeetBot.items.Info object at 0x1a01218c>
17:45:34 <brunowolff> Maybe we should have that blocker depend on this one?
17:45:35 <adamw> okay, now i'm confused.
17:45:39 <tflink> same here
17:45:40 <adamw> brunowolff: it does.
17:45:50 <adamw> tflink: remember the proposed #agreed doesn't count as an action
17:45:57 <brunowolff> Then do we need to make it a blocker in its own right?
17:45:58 <tflink> #info Proposed Blocker, MODIFIED
17:46:12 <tflink> yeah, I was thinking that the #topic went through
17:46:13 <adamw> brunowolff: it doesn't make much difference as it shows up in the list and needs an AcceptedBlocker tag either way
17:46:37 <tflink> proposed #agreed - 743376 - AcceptedBlocker - The installer must boot and run on systems using EFI other than Apple Macs
17:46:45 <tflink> much better
17:46:53 <tflink> copy/paste fail
17:47:12 <brunowolff> OK. The phrasing of this bug was weird for a blocker since it didn't directly hit criteria and is more describing a particular solution.
17:47:21 <brunowolff> ack
17:47:37 <adamw> ack - the criterion is kinda arbitrary for this one
17:48:08 <tflink> #agreed - 743376 - AcceptedBlocker - The installer must boot and run on systems using EFI other than Apple Macs
17:48:16 <tflink> adamw: yeah, but EFI needs it
17:48:24 * tflink figured that was the best one
17:48:30 <tflink> #topic (735273) Command <grub2-mkconfig -o /boot/grub2/grub.cfg> finds Windows partition, adds to grub menu, but menu entry will not boot
17:48:34 <tflink> #link http://bugzilla.redhat.com/show_bug.cgi?id=735273
17:48:36 <tflink> #info Proposed Blocker, NEW
17:50:12 <tflink> I'm thinking -1 blocker ATM
17:51:06 <adamw> so we asked for more info, and it seems to be related to running an f16 vm atop an f14 host next to windows?
17:51:12 <adamw> craziness. but yeah, that makes it a bit niche for me.
17:51:44 <brunowolff> Especially since the last comment suggests the bug is in F14.
17:51:44 <tflink> yeah, couldn't repro with F15 as the host
17:52:24 <adamw> brunowolff: well, it may be some kinda combination - be interesting to try an f15 install atop f14.
17:52:40 <tflink> proposed #agreed - 735273 - RejectedBlocker - This bug seems to manifest only when F14 is used as the virtualization host and is a little too specific to be a blocker
17:52:53 <adamw> but anyway, whatever, it looks too restricted to make it a blocker, to me. (we have some wiggle room on this criterion; it doesn't require _all_ f16-alongside-windows configs to work)
17:52:54 <brunowolff> ack
17:52:56 <adamw> ack
17:53:07 <tflink> #agreed - 735273 - RejectedBlocker - This bug seems to manifest only when F14 is used as the virtualization host and is a little too specific to be a blocker
17:53:14 <tflink> #topic (737339) Grub menu is shown even for single OS installations
17:53:14 <tflink> #link http://bugzilla.redhat.com/show_bug.cgi?id=737339
17:53:14 <tflink> #info Proposed Blocker, ASSIGNED
17:54:22 <tflink> I'm thinking that this isn't a blocker
17:54:28 <dgilmore> -1 blocker
17:54:36 <tflink> NTH ... maybe
17:54:59 <brunowolff> I find it hard to call this a blocker based on there being divided opinion on whether the grub menu should be displayed for a bit during boot.
17:55:40 <tflink> now that I'm thinking about it more, I'm -1 NTH, too
17:55:51 <tflink> I wouldn't want to take a fix for this past freeze
17:56:44 * adamw checks criteria
17:56:49 <tflink> proposed #agreed - 737339 - RejectedBlocker - This bug doesn't hit any release criteria and opinions on whether the grub menu should be displayed or not are divided
17:56:55 <adamw> i thought we had a silly one about 'seamless boot' which is violated all over the damn place in f16, but i can't find it
17:56:59 <adamw> anyone know what i'm talking about?
17:57:44 <tflink> I don't remember a criterion for that from F15
17:58:00 <tflink> but I do remember people talking about that
17:58:06 <dgilmore> adamw: i dont remeber that
17:58:10 * dgilmore needs to run
17:58:16 * dgilmore has a meeting
17:58:22 <adamw> i just checked through and can't find it, which is good anyway, as it shouldn't be blocking
17:58:25 <tflink> I believe that seamless boot was the motiviation behind the syslinux and grub splash changes
17:58:26 <adamw> so, -1 -1 for me
17:58:46 <tflink> proposed #agreed - 737339 - RejectedBlocker RejectedNTH - This bug doesn't hit any release criteria and opinions on whether the grub menu should be displayed or not are divided
17:59:00 <adamw> tflink: we had it as a feature a while back - we did get one release to the point where you stay in one video mode, with no flashes to console and some kind of 'fedora' background consistently showing, all the way from grub to desktop
17:59:10 <adamw> but it's never been particularly reliable, and f16 is nowhere near that, heh
17:59:12 <adamw> ack
17:59:18 <tflink> #agreed - 737339 - RejectedBlocker RejectedNTH - This bug doesn't hit any release criteria and opinions on whether the grub menu should be displayed or not are divided
17:59:26 <tflink> #topic (742226) /sbin/grub2-probe: error: cannot find a GRUB drive for /dev/mapper/nvidia_cjfffajep2
17:59:29 <tflink> #link http://bugzilla.redhat.com/show_bug.cgi?id=742226
17:59:32 <tflink> #info Proposed Blocker, NEW
18:00:09 <tflink> on a side note, it turns out that I have a machine with nvidia bios raid
18:00:16 <adamw> funsies
18:00:40 <adamw> we asked for more info last week and didn't get any from pjones, but we did get one person who claims to reproduce and said he'd send logs, but hasn't yet.
18:00:56 <tflink> I can try today, I didn't realize that we needed logs on this
18:01:54 <tflink> do we want to punt on this again?
18:01:56 <adamw> not necessarily, james provided some
18:02:00 <adamw> but more are always good, heh
18:02:06 <adamw> i think so, yeah, we still need pjones to evaluate it
18:02:12 <tflink> I'm not sure its blocker if it's just nvraid, though
18:02:28 <adamw> nvidia mobos are very popular at a certain vintage
18:02:44 <adamw> but intel more popular these days
18:03:42 <brunowolff> But if your pci bus isn't overloaded and you don't need another OS to see the raid device, your probably better off with md raid instead.
18:04:01 <tflink> proposed #agreed - 742226 - We still need more information on what exactly is going wrong here
18:04:27 <adamw> ack
18:04:33 <brunowolff> ack
18:04:35 <adamw> brunowolff: the 'other OS' thing is the sticking point
18:04:37 <tflink> #agreed - 742226 - We still need more information on what exactly is going wrong here
18:04:48 <adamw> brunowolff: i just switched to software RAID on my laptop but that wouldn't have been an option if i wanted to keep it windows-capable
18:04:53 <tflink> #topic (743273) grub2 fails to install on IMSM raid device
18:04:53 <tflink> #link http://bugzilla.redhat.com/show_bug.cgi?id=743273
18:04:53 <tflink> #info Proposed Blocker, NEW
18:05:17 <tflink> wait, is this a repro of the last bug?
18:05:41 <dlehman> imsm uses mdraid while nvidia uses dmraid. wee!
18:06:10 <tflink> dlehman: its just two swapped chars, is it that big of a deal?
18:06:23 <dlehman> heh
18:06:33 <adamw> different bug, kinda similar
18:06:38 <adamw> we have a few in this general area
18:06:41 <dlehman> a whole different world of problems
18:06:42 <tflink> yeah
18:06:48 <brunowolff> If grub2-install is like grub-install you give a mount point / directory name, not a device name.
18:06:54 <adamw> i have another different bug trying to install to the intel bios raid on my laptop...
18:07:11 <adamw> a) it's not and b) i don't think that's right.
18:07:33 <dlehman> I just installed an intel fwraid system the other day w/ no trouble
18:07:38 <adamw> "INSTALL_DEVICE can be a GRUB device name or a system device filename"
18:08:28 <brunowolff> I had to play with grub-install recently, and I definitely used a file system path to the directory where the files were supposed to be copied and not /dev/something.
18:08:56 <dlehman> grub2-install is totally different
18:09:26 <adamw> i don't think he's right for grub-install anyway
18:09:36 <dlehman> brunowolff: the only directory you pass to grub-install is optionally --root-directory=
18:09:42 <adamw> i only have grub2 installed now, so i can't reference the --help, but http://orgs.man.ac.uk/documentation/grub/grub_3.html#SEC10 disagrees
18:11:11 <adamw> anyway
18:11:12 <brunowolff> dlehman: I might have been using that option and forgot that part.
18:11:25 <adamw> this whole area is a bit thorny, because we have lots of different bugs with different raid configs
18:11:40 <adamw> it's sort of like the total amount of breakage is worrying, but no individual bug looks bad enough to be a blocker on its own
18:11:53 <adamw> and we do have *some* tests where it worked (like dlehman's and my desktop)
18:12:31 <tflink> hm, several of these proposed blockers come from the same person
18:12:31 <dlehman> he manually upgraded from grub to grub2 and who knows what is grub config looks like after that
18:12:48 <adamw> dlehman: the package upgrade doesn't do anything to grub config
18:12:52 <tflink> https://bugzilla.redhat.com/show_bug.cgi?id=742888
18:13:01 <adamw> you have to do grub2-mkconfig after the upgrade, and that's all we do on a fresh install anyway - we trust grub2 to write a config
18:13:02 <tflink> I think that is related
18:13:04 <dlehman> right, so he could have an empty /boot/grub/device.map for one thing
18:13:30 <dlehman> does mkconfig auto-generate a device map?
18:13:37 <adamw> i think either mkconfig or grub2-install does
18:13:51 <adamw> at least, doing a manual upgrade on this system the same way he did it worked right for me
18:14:05 <adamw> all i did was install grub2, do grub2-mkconfig then grub2-install, rebooted and it worked, and i have a device.map
18:14:07 <dlehman> hmm, okay
18:14:47 <adamw> tflink: i don't think they're related...
18:15:02 <adamw> but now he can't reproduce 742888 i guess we could ask again about the clean install case...
18:15:09 <dlehman> on a similar note, I need to open a bug about not being able to boot after a fresh install to an md /boot
18:16:05 <tflink> 742888 is about the rescue mode, though not the installer
18:16:09 <adamw> i'm probably in favour of punting on this one until we know what's broken
18:16:29 <tflink> I don't understand how 742888 could be blocking him from installing grub
18:16:35 <tflink> but +1 to what adam said
18:16:38 <adamw> yeah, i just asked him to re-try with a clean install
18:17:23 <tflink> proposed #agreed - 743273 - It's really unclear what is broken here - ask the reporter to try a clean install and will revisit next week
18:17:23 <dlehman> he said he got a _similar_ error when try an install in addition to the rescue failure
18:17:39 <adamw> ack
18:17:48 <tflink> dlehman: ah, I missed that part
18:18:09 <tflink> #agreed - 743273 - It's really unclear what is broken here - ask the reporter to try a clean install and will revisit next week
18:18:09 <adamw> i think we need to ship pjones a ton of motherboards and tell him to spend the next two weeks installing to bios raid configs, heh
18:18:15 <dlehman> initial report is pretty sloppy
18:18:24 <tflink> #topic (744054) Cannot install to MBR of an Intel BIOS RAID-0 array (Sony Vaio Z stock layout)
18:18:28 <tflink> #link http://bugzilla.redhat.com/show_bug.cgi?id=744054
18:18:30 <tflink> #info Proposed Blocker, NEW
18:19:06 <dlehman> now this is highly similar
18:19:23 <adamw> this one's mine
18:19:35 <adamw> of course, now i can't test any fixes as i had to get the system working so i reinstalled to software raid :(
18:20:00 <adamw> and you're right, now i look at it, it does look similar to jes'
18:20:05 <adamw> hopefully you're happier with the info i provided =)
18:20:21 <adamw> i think i didn't include the device.map file though, sorry.
18:20:44 <dlehman> the console session -- is that from somewhere in anaconda or what?
18:21:09 <dlehman> because it looks kind of like your biosraid set just isn't up at the time
18:21:36 <adamw> it's from a running f15 system booted from the biosraid set.
18:21:39 <adamw> so yes, it was set up =)
18:22:01 <adamw> as per the bug description, i tried to do a 'live' switch from grub to grub2 on f15 to make sure grub2 would work before i upgraded to 16
18:22:18 <adamw> so i rebuilt grub2 for f15 and tried to install it. pjones said that procedure should work.
18:23:07 <dlehman> seems like a reasonable thing to try
18:23:42 <adamw> dlehman: grub2-mkconfig is just a script now i look at it
18:23:45 <adamw> and it calls grub_mkdevicemap
18:23:51 <adamw> so yeah, when you do mkconfig, it creates the devicemap
18:24:10 <adamw> (if one doesn't already exist)
18:24:40 <dlehman> and presumably puts everything necessary in it, so that should be fine
18:24:56 <adamw> that's obviously the intent, yeah: you're not supposed to hand-write or pre-generate a devicemap afaict.
18:25:14 <dlehman> oh? anaconda does just that.
18:25:19 <adamw> hum.
18:25:42 <dlehman> (that doesn't mean I've read every possible doc that might discourage such a thing)
18:25:57 <adamw> er...does it? grep -R mkdevice in the anaconda tree gives nothing for me.
18:26:25 <dlehman> it's just that "step back and allow the magician to work his magic" is not very conducive to a situation where anaconda needs to be able to control how some things are set up
18:26:57 <dlehman> adamw: grep write_device_map will give a result
18:27:09 <adamw> yeah just saw that
18:27:14 <adamw> are you sure it does that for grub2 though?
18:27:17 <adamw> or just grub and efigrub?
18:27:27 <dlehman> yes sir. I wrote that.
18:27:30 <adamw> okay =)
18:27:53 <adamw> anyhoo
18:28:01 <dlehman> the reason we do that is the old and crufty thing that allows people to specify a different bios order from what we detect
18:28:04 <adamw> when i say 'not supposed' i mean more 'not required'
18:28:31 <dlehman> I'm fine with either. anaconda is certainly not any developer's target audience
18:28:31 <adamw> i.e. it's not a problem that i/jes didn't write a device.map before doing mkconfig and intsall
18:28:36 <dlehman> agreed
18:28:43 <adamw> erf. we're wasting time
18:28:51 <tflink> votes?
18:28:57 <tflink> punt on this one too?
18:28:57 <adamw> proposal: let's punt on all grub2/raid issues for now and let pjones evaluate them
18:29:11 <adamw> where by 'let' i mean 'nag incessantly until he does it'
18:29:14 <tflink> works for me
18:29:20 <tflink> poke with sharper stick?
18:30:08 <tflink> #agreed 744054 - Not enough information about what's going wrong here, needs more analysis before we decide on blocker status
18:30:40 <tflink> #topic (676488) update showing Error message ??? instead of actual error message
18:30:42 <adamw> sharper and more tetanus-laden, yes
18:30:43 <tflink> #link http://bugzilla.redhat.com/show_bug.cgi?id=676488
18:30:46 <tflink> #info Proposed Blocker, NEW
18:30:50 <tflink> this is another i18n issue
18:31:07 <adamw> so ditto with previous one: punt for one more week
18:31:41 <tflink> proposed #agreed - 676488 - We still don't have a release criterion for i18n, will revisit next week once a criterion has been proposed/accepted
18:32:01 <tflink> #agreed - 676488 - We still don't have a release criterion for i18n, will revisit next week once a criterion has been proposed/accepted
18:32:02 <adamw> ack
18:32:04 <tflink> #topic (741950) F16: Can't use keyboard when installing F16-Alpha under Xen (regression) as guest
18:32:07 <tflink> #link http://bugzilla.redhat.com/show_bug.cgi?id=741950
18:32:10 <tflink> #info Proposed Blocker, MODIFIED
18:32:34 <tflink> do we want to take this on now or wait until there is more consesus on the proposed Xen criterion?
18:33:00 <adamw> uf. i'm still hugely on the fence, but the ec2 case is a pretty compelling one...
18:33:07 <adamw> it's just, blocker is such a big word =)
18:33:21 <tflink> yeah, I'm not sold on blocker yet
18:33:26 <tflink> NTH, yes
18:33:37 <adamw> maybe we should take the discussion to devel
18:34:17 <tflink> the thing that gets me is that we can't fix xen domU install issues post-release
18:34:29 <tflink> dom0, yes
18:34:36 <tflink> domU, no
18:34:52 <tflink> well, not easily in any sense anyways
18:35:08 <adamw> wait, which is which again?
18:35:14 <adamw> this is why i hate xen.
18:35:18 <tflink> dom0 -> host
18:35:21 <tflink> domU -> guest
18:35:58 <tflink> eh, I think their terminology is just as clear just different
18:36:37 <adamw> they could call it domH and domG, for one thing =)
18:36:56 <adamw> so yeah, maybe domU could be blocker and dom0 not? we could propose that
18:37:01 <adamw> and take it to devel
18:37:04 <adamw> and punt on the bug for a week
18:37:15 <tflink> true, but that doesn't fit Xen -> they're all domains on top of the hypervisor but Dom0 has super powers
18:37:30 <adamw> I DON'T WANT TO UNDERSTAN
18:37:31 <adamw> D
18:37:35 <tflink> I see
18:38:14 <adamw> =)
18:38:26 <tflink> proposed #agreed - 741950 - It's still not clear on whether the Xen related release criterion will be accepted, will ask devel@ and decide by next week
18:38:30 <adamw> ack
18:38:42 * tflink thinks it would be a shame if we released w/o DomU support
18:38:49 <tflink> #agreed - 741950 - It's still not clear on whether the Xen related release criterion will be accepted, will ask devel@ and decide by next week
18:38:58 <tflink> #topic (743135) The installer no longer has access to files in the initrd
18:39:01 <tflink> #link http://bugzilla.redhat.com/show_bug.cgi?id=743135
18:39:03 <tflink> #info Proposed Blocker, MODIFIED
18:39:53 <tflink> this is the source of the problems I was having with the ks/initrd turducken test case
18:40:06 <adamw> right
18:40:08 <adamw> heh
18:40:22 <adamw> so this is currently a blocker per the beta kickstart method criterion
18:40:30 <tflink> yep
18:40:40 <adamw> i have a todo item to propose tweaking that criterion, but...we can take it for now i guess.
18:40:45 <tflink> we still need a lorax build, though
18:40:48 <adamw> so per current criteria, +1
18:40:53 <tflink> same here
18:41:36 <tflink> proposed #agreed - 743135 - This bug blocks the beta test case "Kickstart File Path Ks" and is therefore a blocker
18:41:57 * tflink likes the name "Kickstart Turducken Test Case" better
18:42:06 <adamw> rename it!
18:42:11 <adamw> ack
18:42:20 <tflink> #agreed - 743135 - This bug blocks the beta test case "Kickstart File Path Ks" and is therefore a blocker
18:42:32 <tflink> #topic (726979) kwrite crashes in "Configure editor" (under some conditions)
18:42:35 <tflink> #link http://bugzilla.redhat.com/show_bug.cgi?id=726979
18:42:38 <tflink> #info Proposed Blocker, ASSIGNED
18:42:58 <tflink> I thought we accepted this already
18:43:11 <tflink> did I miss it from last week
18:43:29 <tflink> yes, I did
18:43:31 <tflink> already a blocker
18:43:36 <adamw> ah k
18:43:38 <adamw> i'll do it
18:43:56 <tflink> k, thanks
18:44:13 <tflink> #topic (742658) Buttons in Qt applications (both KDE Platform and Qt-only) not clickable when run under GNOME 3
18:44:17 <tflink> #link http://bugzilla.redhat.com/show_bug.cgi?id=742658
18:44:19 <tflink> #info Proposed Blocker, NEW
18:45:08 <tflink> not sure this is a blocker
18:45:25 <tflink> are any of the default apps on desktop qt based?
18:45:45 <adamw> i don't think so, no
18:45:49 <adamw> so i'd say not a blocker
18:46:02 <tflink> I'm not even sure NTH
18:46:06 <adamw> might mean kde team has to rearrange their blockers a bit, but...we can leave that up to them
18:46:06 <adamw> yeah
18:46:11 <tflink> since this can easily fixed with a 0day update
18:46:13 <adamw> post-release update would be okay i think
18:46:14 <adamw> yup
18:46:16 <adamw> -1
18:46:22 <tflink> and I'd rather not take new qt post-freeze
18:47:09 <tflink> proposed #agreed - 742658 - RejectedBlocker RejectedNTH - This doesn't hit any of the release criteria and could easily be fixed as a 0day update on release.
18:47:31 <adamw> ack
18:47:33 <tflink> #agreed - 742658 - RejectedBlocker RejectedNTH - This doesn't hit any of the release criteria and could easily be fixed as a 0day update on release.
18:47:36 <tflink> #topic (743386) Ensure grub2 and grub-efi are both on the install media without making them 'default' in comps
18:47:39 <tflink> #link http://bugzilla.redhat.com/show_bug.cgi?id=743386
18:47:42 <tflink> #info Proposed Blocker, NEW
18:47:55 <tflink> another grub/EFI bug
18:48:27 <tflink> proposed #agreed - 743386 - AcceptedBlocker - The installer must boot and run on systems using EFI other than Apple Macs
18:48:37 <tflink> well, not quite EFI but related
18:49:28 <brunowolff> ack
18:49:36 <tflink> #agreed - 743386 - AcceptedBlocker - The installer must boot and run on systems using EFI other than Apple Macs
18:49:55 <tflink> #topic (743022) F15->F16 yum update fails with IMSM (BIOS) raid
18:49:55 <tflink> #link http://bugzilla.redhat.com/show_bug.cgi?id=743022
18:49:55 <tflink> #info Proposed Blocker, NEW
18:50:00 <tflink> aww, this again?
18:50:13 <adamw> sorry back
18:50:39 <tflink> #agreed - 743022 - There isn't enough information to determine what exactly is going wrong here. Will revisit once the bug has been triaged.
18:51:00 <adamw> ack
18:51:08 <tflink> #topic (742768) tracker-miner-fs consumes 100% cpu and never finishes
18:51:09 <tflink> #link http://bugzilla.redhat.com/show_bug.cgi?id=742768
18:51:09 <tflink> #info Proposed Blocker, NEW
18:51:28 <tflink> what's tracker-miner-fs?
18:52:01 <tflink> oh, part of shell that mines the fs for search info
18:53:21 <tflink> not sure about blocker on this one
18:53:37 <tflink> does tracker run on a livecd?
18:54:08 <adamw> er, i think we disable it, but not 100% sure
18:54:27 <tflink> if we disable it on lives, I'm -1, -1
18:54:33 <adamw> i do have a special place of hate in my heart for desktop search indexers, but we'd usually need more people to be affected to take this kind of thing as a blocker
18:55:03 * adamw tries to check
18:57:26 <adamw> no reply from desktop folks
18:57:36 <adamw> let's make it provisional not-a-blocker and check whether it runs live
18:57:38 <adamw> ?
18:58:38 <tflink> proposed #agreed - 742768 - RejectedBlocker RejectedNTH - This doesn't hit any of the blocker criteria and could be fixed with a post-release update. It it turns out that tracker runs on live images, please note that and re-propose as either blocker or NTH
18:59:53 <adamw> ack
19:00:03 <tflink> #agreed - 742768 - RejectedBlocker RejectedNTH - This doesn't hit any of the blocker criteria and could be fixed with a post-release update. It it turns out that tracker runs on live images, please note that and re-propose as either blocker or NTH
19:00:12 <tflink> ok, done with the proposed blockers
19:00:17 <tflink> only took us 2 hours
19:00:29 * tflink doesn't even want to think what it would have been like if we didn't meet last week
19:00:37 <adamw> =)
19:00:37 <tflink> on to the NTH!
19:00:47 <tflink> #topic (731356) Error: unsupported locale setting
19:00:48 <tflink> #link http://bugzilla.redhat.com/show_bug.cgi?id=731356
19:00:48 <tflink> #info Proposed NTH, POST
19:03:04 <adamw> def +1
19:03:09 <adamw> might even be +1 blocker now we know what's going on
19:03:24 * tflink is still reading
19:04:21 <adamw> it's fairly simple - if you write the traditional installer to a usb stick it writes a lang= kernel parameter with the host system's LANG env var
19:04:32 <adamw> it turns out that var is actually wrong on fedora live installs, for some reason
19:04:50 <adamw> and anaconda chokes on the wrong value
19:04:58 <adamw> anyways, definitely +1 nth
19:05:10 <tflink> so if you create a liveusb on a system installed from a live install, anaconda blows up?
19:06:10 <adamw> not sure about live usb
19:06:18 <adamw> the tested case is writing the dvd/netinst to a usb stick
19:06:21 <tflink> yeah, typo
19:06:22 <adamw> which is supported
19:06:26 <adamw> sonar_logger1: yes.
19:06:28 <tflink> thinking one thing, typing another
19:06:30 <adamw> heh
19:06:33 <adamw> so: yes
19:06:48 <tflink> definitely +1 NTH
19:06:54 <tflink> not sure about blocker but NTH
19:07:03 <brunowolff> +1 nth
19:07:55 <tflink> proposed #agreed - 731356 - AcceptedNTH - This causes problems with creating installers on USB disks, fix is available
19:08:04 <tflink> proposed #agreed - 731356 - AcceptedNTH - This causes problems with creating installers on USB disks, fix is available for review
19:08:23 <adamw> ack
19:08:31 <tflink> #agreed - 731356 - AcceptedNTH - This causes problems with creating installers on USB disks, fix is available for review
19:08:39 <tflink> #topic (741199) BOOTPROTO missing in ifcfg-eth0 in minimal install
19:08:39 <tflink> #link http://bugzilla.redhat.com/show_bug.cgi?id=741199
19:08:39 <tflink> #info Proposed NTH, MODIFIED
19:10:43 <tflink> I'm not sure that I'm quite -1 NTH on this
19:10:46 <adamw> reading
19:10:46 <tflink> closer to 0
19:10:55 <tflink> wait, nvm
19:11:05 <tflink> yeah, I'm +1 NTH on this - it can't be fixed post-release
19:12:01 <adamw> yeah, sure.
19:12:17 <adamw> +1
19:12:38 <tflink> proposed #agreed - 741199 - AcceptedNTH - This is a bit of an annoyance and can't be fixed post-release
19:12:45 <adamw> ack
19:12:46 <tflink> #agreed - 741199 - AcceptedNTH - This is a bit of an annoyance and can't be fixed post-release
19:12:58 <tflink> #topic (743596) netinstall f16 Beta of LDXE and sugar (no gnome) fails to start gdm after firstboot
19:13:01 <tflink> #link http://bugzilla.redhat.com/show_bug.cgi?id=743596
19:13:03 <tflink> #info Proposed NTH, ON_QA
19:14:17 <tflink> looks to be fixed already
19:14:39 <adamw> +1 for this, it breaks sugar ootv
19:14:40 <adamw> ootb
19:14:44 <tflink> yeah
19:14:44 <brunowolff> +1 NTH as it would block gnome if the same thing were happening.
19:14:53 <adamw> and probably Xfce
19:15:31 <tflink> proposed #agreed - 743596 - AcceptedNTH - This is a release blocker for sugar, therefore NTH
19:15:44 <tflink> adamw: I didn't think xfce used gdm
19:15:56 <nirik> it does
19:16:12 <adamw> anyway, ack
19:16:20 <tflink> #agreed - 743596 - AcceptedNTH - This is a release blocker for sugar, therefore NTH
19:16:31 <tflink> #topic (743376) Split grub-efi out from grub and have it not conflict with grub2
19:16:35 <tflink> #link http://bugzilla.redhat.com/show_bug.cgi?id=743376
19:16:37 <tflink> #info Proposed NTH, MODIFIED
19:16:41 <tflink> huh, why is this proposed NTH
19:16:49 <tflink> #undo
19:16:49 <zodbot> Removing item from minutes: <MeetBot.items.Info object at 0x194448ac>
19:16:51 <tflink> #undo
19:16:51 <zodbot> Removing item from minutes: <MeetBot.items.Link object at 0x16cf6d4c>
19:16:55 <tflink> #undo
19:16:55 <zodbot> Removing item from minutes: <MeetBot.items.Topic object at 0x1835bd8c>
19:17:12 <tflink> #topic (741538) preupgrade f15->f16 fails to find any volumes with encrypted device (prompts for passphrase twice, tries to double mount)
19:17:15 <tflink> #link http://bugzilla.redhat.com/show_bug.cgi?id=741538
19:17:17 <tflink> #info Proposed NTH, NEW
19:17:31 <adamw> https://bugzilla.redhat.com/show_bug.cgi?id=735023 is proposed NTH, that's why.
19:18:00 <tflink> oh
19:18:08 <tflink> OK
19:19:18 <adamw> this looks more like anaconda than preupgrade, and needs some info
19:19:32 <tflink> and a real name
19:19:47 <adamw> heh
19:19:52 <adamw> i recognize the email address somehow
19:20:20 <tflink> the bug sounds familiar, too
19:20:33 <tflink> wasn't there something similar that kamil filed for alpha or beta?
19:20:46 <adamw> yeah
19:20:47 <adamw> different though
19:21:36 <adamw> anyway, re-assign to anaconda, ask for info, i think
19:22:30 <tflink> propsed #agreed - 74538 - Not enough info to make a decision on, re-assign to anaconda and ask for more info
19:22:48 <adamw> ack
19:22:51 <tflink> #agreed - 741538 - Not enough info to make a decision on, re-assign to anaconda and ask for more info
19:23:04 <tflink> #topic (735023) Fedora 16 live images are not EFI-capable: should use grub-efi package when available
19:23:08 <tflink> #link http://bugzilla.redhat.com/show_bug.cgi?id=735023
19:23:10 <tflink> #info Proposed NTH, NEW
19:23:34 <tflink> I'm +1 NTH on this
19:23:50 <tflink> well, maybe not
19:24:14 <tflink> with the fun we've been having with EFI as of late, I'm not sure taking fixes for EFI live after freeze would be so wise
19:25:15 <tflink> would it be nice to have? yes. would it be worth changing the tool that creates the livecds after final freeze ...
19:25:46 <adamw> well, i think it's not a huge change to the tool
19:26:01 <adamw> all the stuff is there already, we had EFI lives before
19:26:03 <tflink> then it can be done before freeze
19:26:09 <adamw> max it'll take is s/grub/grub-efi/ in a few places
19:26:20 <adamw> sure, but if we don't get around to it, it'd kinda suck not to take it post-freeze, i guess...
19:27:23 <adamw> i'm +1 i think
19:27:29 <adamw> as long as the fix isn't worse than i though
19:27:30 <adamw> t
19:27:42 <tflink> I think that I'm +0, maybe -.5
19:28:16 <tflink> is the new grub-efi build done?
19:28:50 <adamw> grub-efi is built
19:29:00 <adamw> after that we need to figure out what to change on the live setup
19:29:23 * tflink wonders how long that'll take
19:29:48 <tflink> I'd really rather see this pre-freeze if we're going to do it
19:29:57 <nirik> we need to get grub-efi in stable...
19:30:00 <adamw> sure. me too
19:30:08 <adamw> for _any_ bug it's better to fix it pre-freeze
19:31:03 <tflink> it looks like we're at +.5 ATM
19:31:06 <tflink> thoughts?
19:32:41 <tflink> nirik: do you have an opinion on NTH or not?
19:32:56 * nirik reads back up
19:33:23 <brunowolff> I'm on the fence. I'd want to be pretty sure it didn't break non-efi before taking this after freeze.
19:33:31 <nirik> so, basically we just need to add grub-efi onto the live images?
19:34:03 <tflink> that's what it sounds like
19:34:18 <nirik> that sounds like a reasonable change to me... I guess it could be NTH if we want EFI support for live
19:34:24 <adamw> there may be some other change
19:34:33 <adamw> i dunno exactly how the 'make live images efi bootable' stuff owrks
19:34:40 <adamw> but i think probably all it'd be is the package change
19:34:46 <tflink> because you'd need grub-efi or grub2 depending on what you're booting on, right?
19:35:00 <tflink> so there's a conditional where there previously wasn't one?
19:36:18 <tflink> I guess if we're talking about the ability to generate efi only livecds, I have less of an issue. If we're talking about having both grub-efi and grub2 on all the live images, I'm a bit more worried
19:36:19 <adamw> no
19:36:27 <adamw> two different issues
19:36:36 <adamw> well...
19:36:37 <adamw> okay.
19:36:48 <adamw> yes, we will need both grub2 and grub-efi on all the lives to make them EFI bootable.
19:37:03 <adamw> the two don't conflict in any way, though. it shouldn't cause any problems.
19:37:12 <nirik> I thought this bug was simply asking for livecd-iso-to-disk --efi to work?
19:37:22 <adamw> grub-efi does nothing at all unless you're booting from EFI. it doesn't install any files in any places that anything but EFI can do anything with.
19:37:23 <adamw> nirik: no.
19:37:26 <adamw> nirik: that already works.
19:37:31 <tflink> nirik: that's where it started
19:37:36 <adamw> the problem is that live images themselves are not EFI bootable because the files aren't present on them.
19:37:43 <adamw> no it didn't.
19:37:54 <adamw> livecd-iso-to-disk works and has worked all along.
19:37:56 <nirik> so, will take take changes to livecd-creator?
19:37:57 <adamw> the problem is *the image itself*.
19:37:59 <adamw> no.
19:38:09 <adamw> well, possibly, but most likely just the package list.
19:38:10 <tflink> adamw: how so? Yes, the problem wasn't with the creator but that's how this all got started
19:38:17 <tflink> eh, we're arguing about symantics
19:38:21 * nirik re-reads. skimming on a friday isn't working for my comprehension. ;)
19:39:02 <adamw> tflink: the tool works. it can write efi-bootable usb sticks. we know that because it works with the dvd and netinst. the problem isn't 'i can't write an efi bootable usb stick', it's 'the live images cannot possibly boot via EFI, no matter what they're written to'
19:39:15 <adamw> if you ignored livecd-iso-to-disk entirely and just burned the beta live image to a CD, that CD still would not boot via efi
19:39:16 <tflink> adamw: like I said, we're arguing about symatics
19:39:26 <tflink> and saying the same thing
19:39:34 <adamw> not really, because clearly, from the preceding discussion, it's possible to completely misunderstand what the bug is =)
19:39:36 <adamw> i don't call that semantics
19:39:38 <nirik> so, what exact changes are needed to fix this?
19:40:02 <adamw> that's not completely known, but at present, i believe all that's needed is for the grub-efi package to be included in the live image package set.
19:40:08 <nirik> grub-efi needs to be in the buildroot for the live media?
19:40:43 <adamw> i don't know about buildroot. i haven't looked at precisely what happens at image creation stage.
19:40:44 <nirik> ok, so I would say: punt, find out more where changes need to happen...
19:41:07 <tflink> works for me
19:41:10 <adamw> okay.
19:41:18 <tflink> if it is indeed that simple, I'd be OK with NTH
19:41:50 <nirik> yeah, if it's just ks changes, great.
19:42:01 <nirik> if it's buildroot and/or livecd-creator changes, less great
19:42:08 <adamw> it'd be easy enough to just test a compose. i'll put that on my todo.
19:42:19 <tflink> proposed #agreed - 735023 - Need more info about the proposed fix before deciding on NTH
19:42:52 <adamw> ack
19:43:13 <brunowolff> ack
19:43:14 <tflink> wow, I wasn't expecting that much discussion over that bug :)
19:43:22 <tflink> #agreed - 735023 - Need more info about the proposed fix before deciding on NTH
19:43:29 <tflink> #topic (742636) gnome3 - conflict with sugar-desktop installed telepathy
19:43:32 <tflink> #link http://bugzilla.redhat.com/show_bug.cgi?id=742636
19:43:35 <tflink> #info Proposed NTH, NEW
19:44:17 <adamw> seems to be a problem if you install both sugar and gnome shell
19:44:32 <adamw> so that wouldn't affect the sugar live, and could probably be fixed with an update...
19:44:37 <adamw> so, -1 for me
19:45:10 <tflink> I'm not sure I understand this whole thing
19:45:28 <tflink> but yeah, it sounds like a problem with installing sugar-desktop on top of shell
19:45:35 <tflink> so -1 from me, too
19:46:31 <tflink> proposed #agreed - 742636 - RejectedNTH - This isn't a problem with SoaS and could be fixed with a post-release update
19:46:50 <adamw> ack
19:47:00 <tflink> #agreed - 742636 - RejectedNTH - This isn't a problem with SoaS and could be fixed with a post-release update
19:47:20 <tflink> OK, that's all the proposed NTH
19:47:55 <tflink> shall we keep going on to the accepted blockers?
19:49:25 <adamw> let's not
19:49:38 <adamw> taken so long already...we can work them offline and we don't have devs around today anyhow
19:49:43 <adamw> er, async*
19:49:50 <tflink> works for me
19:50:05 <tflink> it looks like there are several that are waiting for an anaconda build
19:50:09 <tflink> so ...
19:50:11 <tflink> #open floor
19:50:15 <tflink> sigh
19:50:16 <clumens> i can do that right now.
19:50:26 <tflink> #topic open floor
19:50:41 <tflink> clumens: does it make sense to do that now if we're going to do a TC next week?
19:52:40 <tflink> I assume that the silence means no other topics
19:52:51 * tflink sets fuse for 3 minutes
19:53:16 <adamw> yeah, for anaconda, it's probably best to keep working on fixes then do a build next tue or wed
19:53:32 <clumens> whatever works best
19:53:34 <tflink> #info The next final blocker bug review meeting will be 2011-10-14 @17:00 UTC
19:53:42 <adamw> then we'll pull it into TC1 and we can re-review and close all fixed blockers at that point
19:54:07 <tflink> that sounds like a plan to me
19:54:30 <tflink> that also means I don't have to build another test ISO :-D
19:54:35 <robatino> isn't TC1 supposed to be on the 13th?
19:54:40 <tflink> wait, I was going to do that anyways
19:54:51 <adamw> robatino: yes. next thursday.
19:55:09 <adamw> so we need the anaconda build for it one or two days in advance.
19:55:57 <tflink> and probably poke mgracik about a new lorax build, too
19:56:06 * tflink hopes that he spelled that right
19:56:42 * tflink re-sets fuse for 1 minute
19:57:51 <tflink> OK, Thanks for coming everyone!
19:57:57 * tflink will send out minutes shortly
19:57:59 <tflink> #endmeeting