16:00:43 <tflink> #startmeeting f19alpha-blocker-review-8
16:00:43 <zodbot> Meeting started Wed Apr 17 16:00:43 2013 UTC.  The chair is tflink. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:00:43 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:00:43 <tflink> #meetingname f19alpha-blocker-review-8
16:00:43 <zodbot> The meeting name has been set to 'f19alpha-blocker-review-8'
16:00:43 <tflink> #topic Roll Call
16:00:53 <tflink> Who's ready for some blocker review fun time?
16:00:54 * nirik is lurking around.
16:01:14 * kparal appears out of the thin air
16:01:16 <adamw> morning
16:02:44 * satellit_e listening and testing
16:02:54 * jreznik is here
16:03:45 <tflink> any volunteers for secretary duty?
16:05:11 <adamw> sure
16:05:19 <tflink> why is it always thin air? Never fat air, chubby air, mostly-fit-could-stand-to-lose-a-few-pounds air?
16:06:03 <tflink> adamw: thanks
16:06:16 <kparal> tflink: you tell me, it's your language
16:07:10 <tflink> kparal: actually, that's a quote
16:07:19 <adamw> sounds familiar
16:07:27 <tflink> babylon 5
16:07:50 * kparal should find out what babylon 5 is :)
16:08:20 <tflink> but I have no idea where the idiom comes from
16:08:40 <tflink> kparal: sci-fi TV show in the US from the 90s
16:08:51 <kparal> no wonder I don't know it
16:09:02 <jreznik> kparal: I know what Babylon 5, it's on my todo and from what I heard - you don't have a time for it :)
16:09:13 * jreznik neither
16:09:26 <kparal> nope, no time for any tv shows
16:10:34 <tflink> well, lets get this started
16:10:38 <tflink> #topic Introduction
16:10:59 <tflink> Why are we here?
16:10:59 <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.
16:11:06 <tflink> #info We'll be following the process outlined at:
16:11:06 <tflink> #link https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting
16:11:12 <tflink> #info The bugs up for review today are available at:
16:11:13 <tflink> #link http://qa.fedoraproject.org/blockerbugs/current
16:11:18 <tflink> #info The criteria for release blocking bugs can be found at:
16:11:18 <tflink> #link https://fedoraproject.org/wiki/Fedora_19_Alpha_Release_Criteria
16:11:24 <tflink> #info Up for review today, we have:
16:11:31 <tflink> #info 2 Proposed Blockers
16:11:31 <tflink> #info 3 Accepted Blockers
16:11:31 <tflink> #info 4 Proposed Freeze Exceptions
16:11:31 <tflink> #info 12 Accepted Freeze Exceptions
16:11:48 <tflink> if there are no objections, we'll start with the proposed blockers
16:12:06 <tflink> #topic (906031) installation failure: "Error accessing file for config"
16:12:09 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=906031
16:12:11 <tflink> #info Proposed Blocker, anaconda, NEW
16:13:02 <adamw> so we already discussed this
16:13:10 <adamw> but i wanted to throw it back on the list for re-consideration
16:13:34 <jreznik> bcl thinks it's not anaconda bug but does not have a clue to which component to reassign it
16:13:44 <tflink> yeah, more people are hitting this and we have more details now
16:13:55 <jreznik> also I talked nils, he wasn't able to reproduce it today at all
16:13:56 <tflink> would be nice if we had a consistent reproducing case, though
16:14:01 <adamw> right
16:14:12 <jreznik> even he followed his steps one by one :(
16:14:22 <adamw> dan408 is quite vocal on this one, but not here atm
16:14:40 <tflink> I had trouble following the steps he laid out when trying to reproduce
16:15:14 <tflink> the way I was reading them, I couldn't get a working disk layout
16:15:32 <jreznik> seems it works for many people who were able to install alpha, some people hit this bug sometimes and what's bad - a few people hit it all the time
16:16:19 <kparal> kickstarts are Beta, aren't they?
16:16:37 <tflink> kparal: most of the people hitting this aren't doing ks installs
16:16:40 <jreznik> kparal: it's probably not only kickstart related
16:16:49 <kparal> ah
16:17:07 <tflink> i wonder what would happen if i did a virt install on a slower machine
16:17:19 <adamw> looks like satellit also hit it at https://bugzilla.redhat.com/show_bug.cgi?id=948921 (first report)
16:17:20 <jreznik> but as bcl said - gremlin bug - there's no clear way how to reproduce it and even same people trying to reproduce same issue fails another day
16:17:24 <tflink> ie my older laptop with a 4200rpm disk
16:17:41 <adamw> i've been trying to narrow down who (if anyone) hits this bug 100% but can't quite
16:18:34 <jreznik> there's no pattern or I'm just blind
16:18:57 <satellit_e> RC4 64 bit netinstall worked today
16:19:03 <adamw> it may be something to do with repo contents
16:19:13 * satellit_e virtualbox
16:19:15 <adamw> i'm not seeing any report that states it used DVD
16:19:31 <tflink> I'd be interested to know what hypervisor the vm installs were using
16:19:36 <jreznik> and nils says it worked with DVD
16:20:00 <jreznik> but not neinst and today it worked for him, so it could be repo state dependent
16:20:34 <tflink> a potential workaround could be "use the DVD"
16:21:25 <jreznik> or retry the other day - in case it's really related to content of repo (and hope it will be magically solved)
16:22:30 <adamw> so let's see. joe orton can't reproduce any more - intermittent. dan doesn't say. nils can't reproduce today - intermittent. satellit can't reproduce today - intermittent. internal reporters on the closed RHEL bug don't say. twu doesn't say but he's filed a lot of PASSes, so I guess intermittent. jens doesn't say. stefano says 3/3, but it'd be interesting to ask him to try today
16:23:40 <adamw> so overall it does kinda look like it's intermittent and somehow based on repo contents / wind direction
16:23:57 <adamw> kind of a sucky bug, but i guess i'm still slightly leaning towards -1
16:24:36 <tflink> yeah, I can't see slipping another week if it was just this bug
16:25:24 <tflink> other votes?
16:26:11 <kparal> -1 for alpha
16:26:15 <jreznik> -1 for alpha
16:26:24 * jreznik is talking to adam right now
16:26:39 * adamw looks around wildly
16:27:00 <jreznik> adamw: the other one from the report :)
16:27:58 <jreznik> but we should follow this one closely
16:28:07 <adamw> yeah, and document it for sure
16:28:17 <adamw> hopefully if enough people hit it, we'll get the magic data about what's going wrong :/
16:28:29 <tflink> proposed #agreed 906031 - RejectedBlocker - While this is a nasty bug for the people who hit it, it seems intermittant and we have no clue on the root cause. Thus far, trying later or trying with the DVD seem to be acceptable workarounds and thus, this is rejected as a release blocking bug for F19 alpha.
16:28:31 <adamw> oh, stefano was online till 14 minutes ago, d'oh.
16:28:37 <adamw> patch: intermittEnt
16:28:47 <adamw> spelling nazi on the case!
16:28:58 <tflink> proposed #agreed 906031 - RejectedBlocker - While this is a nasty bug for the people who hit it, it seems intermittent and we have no clue on the root cause. Thus far, trying later or trying with the DVD seem to be acceptable workarounds and thus, this is rejected as a release blocking bug for F19 alpha.
16:29:02 <jreznik> adam does not have access to it, so he can't retry :(
16:29:06 <tflink> actually
16:29:20 <tflink> proposed #agreed 906031 - RejectedBlocker - While this is a nasty bug for the people who hit it, it seems intermittEnt and we have no clue on the root cause. Thus far, trying later or trying with the DVD seem to be acceptable workarounds and thus, this is rejected as a release blocking bug for F19 alpha.
16:29:23 <adamw> :P
16:29:26 <adamw> ha ha
16:29:28 <adamw> ack!
16:29:28 <tflink> there, now it matches the patch
16:29:44 <tflink> ack/nak/patch?
16:29:50 <kparal> are we playing 'spot the difference' game?
16:29:52 <kparal> ack
16:31:24 <tflink> kparal: it's me being a smartass and adding in an upper case letter where it doesn't need to be
16:31:42 <tflink> other ack/nak/patch?
16:32:02 <jreznik> rule #1 use such difficult words when you want to confuse your enemy
16:32:17 <jreznik> aCk.lowercase()
16:32:23 * kparal votes for ents
16:32:29 <kparal> ents are cool
16:32:41 <tflink> #agreed 906031 - RejectedBlocker - While this is a nasty bug for the people who hit it, it seems intermittEnt and we have no clue on the root cause. Thus far, trying later or trying with the DVD seem to be acceptable workarounds and thus, this is rejected as a release blocking bug for F19 alpha.
16:32:55 <tflink> ents? as in tolkein's ents?
16:33:05 <kparal> yep
16:33:10 <tflink> #topic (951761) hangs when loading initramfs on EFI
16:33:10 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=951761
16:33:10 <tflink> #info Proposed Blocker, grub2, NEW
16:34:07 <tflink> it doesn't sound like enough people are hitting this to block over
16:35:35 <satellit_e> I see this on my MacBookProi7 now
16:35:50 <satellit_e> but it is EFI not UEFI
16:36:17 <adamw> satellit: are you sure you're hitting *this*?
16:36:31 <adamw> "To clarify, I do get a boot menu, but selecting the default (or any) entry results in a hang when GRUB outputs the "loading initramfs" line."
16:37:06 <satellit_e> litd USB stops at secureboot not found (?) worked in TC6 anaconda
16:37:25 <satellit_e> so no not the same
16:37:34 <tflink> satellit_e: even with removing quiet and adding rd.debug?
16:37:59 <satellit_e> I have not tested enough but Mac is corner case anyway
16:38:43 <adamw> anyhow, yeah, it's a bit unclear but it doesn't sound like many/any others hit this bug precisely
16:39:04 <jreznik> yep, -1, follow it
16:39:06 <satellit_e> last testing page kaparal made it work
16:40:00 * satellit_e sorry spelling...:  (
16:40:04 <tflink> proposed #agreed 951761 - RejectedBlocker - While this is nasty, it doesn't appear to affect many systems and there is no indication of a root cause. Thus, this bug is rejected as a release blocker for F19 alpha
16:40:25 <adamw> ack
16:40:46 <pschindl> ack
16:41:08 <kparal> ack
16:41:33 <tflink> #agreed 951761 - RejectedBlocker - While this is nasty, it doesn't appear to affect many systems and there is no indication of a root cause. Thus, this bug is rejected as a release blocker for F19 alpha
16:41:42 <tflink> ok, I think that's all of the proposed blockers
16:41:55 <adamw> can I throw https://bugzilla.redhat.com/show_bug.cgi?id=949786 in there?
16:42:34 <adamw> there are three people hitting that with RC3/RC4
16:42:56 <jreznik> and again we can see - update BIOS...
16:43:14 <tflink> #topic (949786) BootLoaderError: failed to set new efi boot target
16:43:17 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=949786
16:43:19 <tflink> #info Proposed Blocker, anaconda, NEW
16:44:05 <kparal> I have added a lot of comments to 947142
16:44:40 <kparal> which is more or less duplicate of this one?
16:44:52 <adamw> we're in the same area, yeah
16:45:01 <jreznik> I'd say so... not 100% but looks like
16:45:09 <kparal> we should discuss it in one go
16:45:17 * satellit_e on MacBookPro USB seems to written to. will not work in regular PC afterwards...get SELINUX...and quits
16:46:34 <adamw> jreznik: kparal: have you bumped the firmware on that ASUS?
16:46:50 <kparal> adamw: bumped? flashed?
16:46:53 <adamw> i'm wondering if ASUS actually fixed anything in newer firmware versions, or if it's just that the process of doing a firmware update clears up the nvram...eh
16:46:56 <adamw> updated, yeah.
16:47:10 <kparal> we didn't, but we can try. we can also try to reset bios to defaults
16:47:11 <tflink> it does clear the nvram, AFAIK
16:47:15 <adamw> it would probably help to have mjg59/jwb/pjones input at this point
16:47:25 <kparal> I wanted to wait a bit if Josh advices us something interesting
16:47:43 * tflink always enjoys having his settings reset on FW upgrade
16:48:36 * jreznik thinks everything we can do for these poor people is to ask vendor to replace mobo with something that sucks less
16:49:04 * adamw pings the kernel channel
16:49:06 <jreznik> kparal: while googling I found several people reporting reflash cleans it up...
16:49:10 <jwb> i'm reading teh bug
16:49:15 <adamw> jreznik: i'd like to check with the devs that there's nothing else they can do
16:49:36 <adamw> jwb: thanks, just wanted to make sure we have all the info to make a decision
16:49:44 <jreznik> adamw: not saying not to try it, this is just my observation...
16:50:12 <adamw> jwb: our impression is that at this point the code isn't terrible and people hitting errors basically have sucky firmware, but we wanted to make sure we weren't missing anything
16:50:14 <jwb> we're talking about 949786?
16:50:22 <adamw> and 947142
16:50:31 <kparal> jwb: 947142 comment 42
16:50:34 <adamw> we're kind of assuming they're more or less the same at this point - 'firmware reports no space'
16:51:15 <adamw> it looks like four testers - john reiser, aj werkman, smooge, and kparal/jreznik - still hit errors with RC3/RC4
16:51:25 <adamw> smooge reported that doing a firmware update 'fixed' it for him
16:51:42 <adamw> we know that smooge, kparal/jreznik and john reiser are all on ASUS boards
16:51:46 <jreznik> not me :)
16:52:12 <kparal> we found out that there is a newer bios from asus
16:52:12 <jreznik> smooge with updated firmware does not (at least this one)
16:52:15 <kparal> so we can try to reflash it
16:52:39 <jreznik> see #25 - Updating the ASUS laptop (K52F) to BIOS 218 has fixed the problem with RC3 for me.
16:53:07 <kparal> jreznik: the question is whether it fixed for good, or just for a few installation attempts
16:53:48 <adamw> we don't know aj's hardware, I don't think
16:53:51 <jreznik> kparal: at least efi pstore is now disabled... if it was really the issue
16:54:06 <jwb> as we've said before, no that isn't _the_ issue
16:54:43 <jwb> so for all of you running into this, do you have something in dmesg with the RC3 kernel along the lines of:
16:54:50 <jwb> efi: Inconsistent initial sizes
16:54:51 <jwb> ?
16:54:55 <pjones> jreznik: it's not the issue.  It's a trigger that makes it more likely to see the real issue
16:55:10 <adamw> i think kparal is the only person-hitting-the-bug present - kparal, are you in a position to check that quickly?
16:55:19 <jreznik> pjones: I mean it this way, sorry for not being more precise
16:55:36 <jwb> fwiw, there are machines that ship from the factory that use more than 50% of the NVRAM space apparently
16:55:36 * kparal booting that machine
16:56:10 <adamw> jwb: it sounds like this whole thing is a giant pita
16:56:17 <pjones> adamw: oh yes.
16:56:20 <jwb> yes, firmware usually is
16:56:24 <adamw> =)
16:56:29 <jwb> i say that having actually written firmware
16:56:55 <jreznik> are we even able to say that we support uefi at all?
16:56:57 <adamw> i'm working on a theory that ownership of and extensive experience with a crack pipe is a prerequisite for all firmware engineering positions
16:57:08 <adamw> jreznik: it depends how good your poker face is?
16:57:20 <pjones> jreznik: no more than we support bios?
16:57:28 <kparal> jwb: http://paste.fedoraproject.org/7817/13662178/
16:57:32 <adamw> we do our best to avoid it!
16:57:52 <kparal> jwb: filtered: paste.fedoraproject.org/7818/62178641
16:57:58 <jreznik> pjones: not sure, this seems like even bigger mess (but you're the right person to say it is or not)
16:58:16 <pjones> adamw: http://www.craigslist.org/about/best/sfo/27499971.html
16:59:04 <jwb> kparal, so no.  my guess is that if you reboot a large number of times, things will magically start working
16:59:08 <pjones> jreznik: this is /our/ bug, not UEFI's.  It's a workaround for a terrible firmware bug, it's true, but fundamentally speaking most of the problems being hit are simply that the workaround was bad.
16:59:25 <adamw> pjones: heh.
16:59:31 <kparal> jwb: we will try the firmware update
17:00:25 <jreznik> pjones: I know this one is our bug but reading mjg's blog... but I'm OT now
17:00:34 <kparal> don't wait for us. I just wanted to know whether there is some magic bullet for boards like we have
17:00:45 <kparal> it seems there isn't, and we will have to document it the hard way
17:01:01 <adamw> so anyway, we kinda need to decide if we ship alpha like this or not
17:01:09 <adamw> jwb: pjones: what's your take on that?
17:01:27 <jwb> if this is an issue of "not enough used space to force GC" then it's a catch 22 afaik.  we don't have > 50% free so we can't create new variables, but the firmware needs more space used before GC is done
17:01:56 <kparal> jwb: why is the 50% limit also used for boot entries, and not just the kernel dumps?
17:02:29 <jwb> kparal, because it's an issue with space available in NVRAM.  it doesn't matter what's occupying it
17:02:54 <jwb> if your bucket has a hole 1/2 way up it, you can pour water or sand and it will leak either way
17:03:44 <jreznik> adamw: and another question is if we can do anything with it that sucks less
17:04:06 <adamw> well that's kinda part of the same question, because if the answer's 'no', then the question of whether to ship it this way becomes easier :)
17:04:11 <jwb> the only other alternative is to disable the 50% check (or move it higher), but that is known to let Linux brick machines
17:04:27 <jwb> brick as in "send it back for replacement"
17:04:29 <adamw> jwb: apply the 50% check only to samsung? or do other firmwares have the same problem?
17:04:42 <jwb> excellent question.  answer unknown
17:05:05 <jwb> there is another patch floating around to allow people to disable the check via a kernel parameter
17:05:12 <adamw> if we can't refine the workaround in any way - if we just have a choice between 'cap at 50% and make install fail on some machines' or 'no cap, brick some machines', the choice seems kinda obvious
17:05:38 <pjones> adamw: if jwb says they've got a patch, and it works better on most machines, it's good enough for me.  We may have to guide some people through manually getting their machines to do garbage collection, but... such is life.
17:05:59 <pjones> adamw: the kernel parameter change might be worth it, though, just because...
17:06:13 <jwb> i'll look at that one to see how hard it would be to add
17:06:15 <pjones> the downside there is, of course, that if somebody with a samsung device does that, we've enabled killing their hardware.
17:06:19 <adamw> right
17:06:31 <adamw> it's a Click Here To Shoot Yourself kinda deal
17:06:46 <jreznik> or if we recommend to use it on non samsung machines and it will apply also for non samsung one
17:06:54 <kparal> adamw: jwb: firmware update fixed the issue on ASUS machine
17:07:02 <jwb> well yay
17:07:04 <adamw> kparal: well, fixed or "fixed"
17:07:08 <adamw> :P
17:07:10 <kparal> but maybe we will hit it again after a few installations
17:07:12 <pjones> kparal: possibly only cleared them out temporarily :/
17:07:19 <jwb> pjones, them?
17:07:23 <pjones> right now pstore is disabled though, right?
17:07:26 <jwb> yes
17:07:27 <pjones> jwb: hrm hrm?
17:07:32 <adamw> i can't seem to find changelogs for the asus firmwares, so it's impossible to know whether they actually fixed a firmware bug or just doing the firmware update cleans out nvram
17:07:44 <pjones> okay, so just creating boot variables /most likely/ won't be enough to trigger out of space anywhere
17:08:00 <jwb> pjones, you said "possibly only cleared them out temporarily".  was wondering what "them" referred to
17:08:03 <jreznik> that's why I thought it above :)
17:08:05 <pjones> jwb: nvram
17:08:07 <kparal> adamw: there is now changelog other then "improved stability" http://support.asus.com/download.aspx?SLanguage=en&p=1&m=M5A97+PRO&hashedid=m2rLy0HGICmyYO5b
17:08:14 <kparal> *no changelog
17:08:38 <pjones> jwb: firmware updates on efi boxes have /often/ cleared out all of the nvram variables and reset some during the next boot
17:08:46 <jreznik> kparal: it's typical for fw updates :)
17:09:03 <pjones> jwb: (sadly including boot variables, which is one more reason we need fallback.efi changes in shim, but I haven't had time to get that in before alpha :/)
17:09:10 <jreznik> are there any tools available to do it without fw upgrade ?
17:09:19 <jwb> pjones, right.  just wanted to make sure you didn't mean "dump-*" files.
17:09:28 <pjones> jreznik: you can do it with the efi shell
17:09:37 <jwb> jreznik, you can reboot 30 times :\
17:09:41 <pjones> which doesn't come with most machines, but you can google for it on the internet
17:09:42 <jwb> well, on some machines
17:09:53 <pjones> note that that's removing variables, which doesn't /necessarily/ include actual GC
17:09:53 <adamw> why's 30 a magic number?
17:10:06 <pjones> adamw: it isn't, it's just absurdly large.
17:10:10 <adamw> ah.
17:10:16 <jwb> adamw, it isn't.  it's just a number that one tester found to work on his particular machine
17:10:51 <pjones> I do suspect that GC will happen when you delete variables /before exiting boot services/ on most machines, so removing them from the efi shell may alleviate some pain as well.
17:11:10 <pjones> but that's... difficult to test.
17:11:58 <adamw> most production firmwares don't even have an EFI shell, right? so first you'd have to install one, which isn't really a walk in the park
17:12:07 <pjones> no production firmware has the efi shell
17:12:28 <adamw> roger.
17:12:46 <tflink> pjones: sorry to be particular but was that a "no, they have it" or "none of them have it"?
17:12:48 <pjones> installing it isn't that hard - place it on /boot/efi/EFI/BOOT/BOOTX64.EFI, remove Boot####, disable uefi, reboot.
17:12:54 <jreznik> but in the worst case ever, there's possibility at least to get it... :(
17:13:02 <pjones> tflink: they do not have it
17:13:04 * satellit afk
17:13:11 <pjones> production machines don't have the UEFI shell
17:13:20 <adamw> so, okay. just to double check: jwb, is it now the case that all we can really do with this is twiddle around the edges? add a kernel parameter for the check, tweak what machines it's applied to, all that stuff.
17:13:26 <tflink> they don't? I'm pretty sure at least 2 of my machines do
17:13:36 <tflink> but I could be mis-remembering
17:13:49 <adamw> if that's the case, and fundamentally the code we have in there right now is sound, then I'm gonna stick my neck out and say -1, let's ship Alpha this way and see what happens; it's kinda the point of Alpha after all
17:13:51 <pjones> tflink: really?  well, they're not supposed to, and all vendors have said they're not going to, and MS has said that they'll fail certification if they do
17:13:57 <pjones> tflink: but, I mean, firmware vendors, you know?
17:14:06 <tflink> and I build my machines from parts
17:14:07 <pjones> tflink: any chance those aren't production machines?
17:14:07 <jwb> adamw, i think that's a correct assessment
17:14:10 <tflink> so that might explain it
17:14:11 <pjones> Ah, okay
17:14:14 <pjones> yeah
17:14:26 <adamw> I don't think it's appropriate to do the tweaking based on limited information before the *Alpha* release, it'd seem to make sense to collect data with Alpha and do any tweaking afterwards based on that data
17:14:40 <pjones> tflink: it's a subtle distinction between "production machine" and "production parts you've assembled", but in this case it may be important.
17:15:05 <pjones> adamw: yeah, I say roll with what we've got
17:15:09 <tflink> pjones: yeah, it makes sense though
17:15:14 <kparal> CommonBugs
17:15:14 <jreznik> adamw: getting crazy of it, but seems like the only possibility for us (and I'd avoid kernel parameter at all - could cause a lot of harm, or at least - do not market it)
17:15:14 <adamw> since bare motherboards in boxes have no particular reason to get MS certification.
17:15:26 <pjones> adamw: exactly.
17:16:37 <tflink> proposed #agreed 949786 - RejectedBlocker - While nasty, the code involved is sound and we don't want to be making changes here with the little data we have. Thus, this is rejected as a blocker for F19 alpha but it needs to be well documented with ways to work around it if users do end up hitting the bug.
17:16:45 <adamw> ack
17:17:07 <jreznik> tflink: don't we want to merge it with the previous one (so mark this one as duplicate?)
17:17:33 <tflink> jreznik: is it a dupe? I figured we would end up rejecting 947142 when we got to it
17:17:43 <jreznik> possible
17:17:43 <adamw> jwb: does it make sense to make 949786 a dupe of 947142? or vice versa?
17:17:59 <adamw> or should we leave 'em separate?
17:18:17 <jreznik> and kparal wanted to discuss in one round, I don't want to spend another hour with the same discussion for the another one :)
17:19:04 <jwb> i haven't really read 949786 in detail.  i think pjones or mjg59 can dup if appropriate
17:19:09 <adamw> ok
17:19:23 <tflink> yeah, dupe discussion can happen outside the meeting
17:20:14 <kparal> ack to proposed
17:20:34 <pschindl> ack
17:20:51 <tflink> #agreed 949786 - RejectedBlocker - While nasty, the code involved is sound and we don't want to be making changes here with the little data we have. Thus, this is rejected as a blocker for F19 alpha but it needs to be well documented with ways to work around it if users do end up hitting the bug.
17:21:04 <tflink> any others?
17:21:44 <pjones> tflink: yeah, I'm closing that dupe
17:23:12 <tflink> there are no proposed FE which are beyond NEW right now
17:23:29 <tflink> so I'm moving on to the accepted blockers if there are no objections
17:24:28 <jreznik> go on
17:24:36 <tflink> #topic (949912) ValueError: Cannot remove extended partition sda4.  Logical partitions present.
17:24:39 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=949912
17:24:39 <tflink> bah
17:24:41 <tflink> #undo
17:24:41 <zodbot> Removing item from minutes: <MeetBot.items.Link object at 0xb629790>
17:24:43 <tflink> #undo
17:24:43 <zodbot> Removing item from minutes: <MeetBot.items.Topic object at 0xb6297d0>
17:24:45 <tflink> #info Accepted Blocker, anaconda, VERIFIED
17:24:46 <tflink> #undo
17:24:46 <zodbot> Removing item from minutes: <MeetBot.items.Info object at 0xb6297d0>
17:24:53 <tflink> #topic (951761) hangs when loading initramfs on EFI
17:24:53 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=951761
17:24:54 <tflink> #info Proposed Blocker, grub2, NEW
17:25:33 <tflink> it sounds like we can remove blocker on this one now
17:25:52 <tflink> or are we still waiting for anaconda to go stable?
17:28:45 <adamw> er
17:29:15 <adamw> didn't we already discuss this earlier?
17:29:34 <tflink> crap, I grabbed the wrong one
17:29:38 <tflink> #undo
17:29:38 <zodbot> Removing item from minutes: <MeetBot.items.Info object at 0xb629190>
17:29:40 <tflink> #undo
17:29:40 <zodbot> Removing item from minutes: <MeetBot.items.Link object at 0x1a00df90>
17:29:42 <tflink> #undo
17:29:42 <zodbot> Removing item from minutes: <MeetBot.items.Topic object at 0xb629f90>
17:29:49 <tflink> #topic (949761) EFI installed system fails to boot (Fedora-19-Alpha-TC5)
17:29:52 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=949761
17:29:54 <tflink> #info Accepted Blocker, grub2, NEW
17:30:04 <tflink> ok, now my question might make a bit more sense
17:30:29 * tflink hadn't used #undo for a while and wanted the experience again ...
17:30:32 <adamw> yeah, still waiting for the update to go stable
17:30:40 <adamw> we need to get karma in on a bunch of updates actually, i should fire off a mail
17:30:54 <adamw> satellit's issue is weird, but i don't think really to do with this bug
17:30:59 <adamw> no idea what's going on there, though.
17:31:12 <tflink> #info this has been worked around well enough for alpha - as soon as the anaconda update goes stable, can remove blocker classification from this
17:31:48 <tflink> anything else on this bug?
17:32:31 * tflink assumes not and moves on
17:33:09 <tflink> #topic (947142) write to /sys/firmware/efi/vars/new_var results in ENOSPC
17:33:12 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=947142
17:33:15 <tflink> #info Accepted Blocker, kernel, ON_QA
17:33:26 <tflink> so, how do we want to handle this bug?
17:33:30 <tflink> reject as blocker?
17:34:16 <jreznik> I'd say so
17:34:37 * jreznik does not want to go again the same discussion today :)
17:34:40 <adamw> no
17:34:50 <adamw> it just gets closed when kernel-3.9.0-0.rc6.git2.3.fc19 goes stable. simple enough
17:35:02 <adamw> this bug is considered to be whatever got fixed in the kernel.
17:35:21 <adamw> that kernel build we kept waiting on upstream approval for and whatever. i never quite got a clear picture of exactly what it was that was being fixed, but hey.
17:35:31 <tflink> oh, ok
17:35:45 <adamw> "This has some known deficiencies if the firmware on the machine doesn't do garbage collection to free up space.  This is being worked on upstream." was about all the specifics we got.
17:36:17 <pjones> adamw: I can explain it to you in gruesome detail if you like?
17:36:21 <adamw> gee!
17:36:25 <adamw> nah, i think that's okay :)
17:36:32 <tflink> #info "This has some known deficiencies if the firmware on the machine doesn't do garbage collection to free up space.  This is being worked on upstream."
17:36:35 <adamw> basically, we just karma up the kernel update and push it stable then we close this.
17:36:42 <jreznik> ok
17:36:45 <adamw> tflink: I'd #undo that, it'll look confusing
17:36:49 <tflink> #undo
17:36:49 <zodbot> Removing item from minutes: <MeetBot.items.Info object at 0x13d51ed0>
17:36:51 <tflink> ok
17:36:59 <adamw> makes it sound like there's more to fix *right now*, which isn't ther case.
17:37:35 <tflink> #info this bug has an update that needs testing, on track to being closed once that update goes stable
17:38:40 <tflink> anything else?
17:39:02 <tflink> or any bugs that I missed?
17:39:09 <tflink> that's all for my list
17:39:13 <adamw> i think that's it
17:39:24 * jreznik thinks it's all done for today
17:39:25 <tflink> #topic Open Floor
17:39:31 <adamw> so right now we're looking good for alpha, we need to up-karma all the ON_QA updates and get them pushed stable
17:39:37 <adamw> and fill out the RC4 test matrix
17:39:40 <tflink> Anything else that should be brought up in the meeting?
17:39:40 <jreznik> and matrix
17:39:55 <tflink> #info still need testing and karma to get stuff pushed stable
17:40:06 <tflink> #info appear to be looking good for alpha
17:40:17 <adamw> for anyone who doesn't know, RC4 is very similar to RC3 - only differences are it's built with the newer lorax that RC3 was meant to be built with, and it has a couple of one-liner fixes for re-using devices in custom partitioning (952662)
17:40:21 * jreznik is going to remind go/no-go meeting for tomorrow, do we want the same time as the last time?
17:40:23 <tflink> jreznik: I forget, has the go/no-go announcement been sent out yet?
17:40:32 <tflink> timing :)
17:40:46 <tflink> jreznik: wasn't there a request for a slightly different time during the meeting?
17:40:50 <jreznik> tflink: not yet, I was waiting for this bug review - to see if we will need to move it to friday
17:41:21 * tflink is fine either way
17:41:21 <jreznik> tflink: not sure now, but yeah - there was conflict with board meeting - and I should be on both...
17:41:28 <kparal> sorry I missed the information, is there going to be RC5?
17:41:47 <adamw> i think normal time tomorrow's fine
17:41:52 <adamw> kparal: doesn't look like it, unless we find more bugs
17:41:56 <tflink> kparal: I don't think so - there are no outstanding unadreesed blockers
17:42:02 <tflink> unadressed
17:42:03 <adamw> kparal: something we missed?
17:42:04 <kparal> ok
17:42:19 <kparal> just making sure
17:42:24 <jreznik> adamw: ok, I multitask with board - and better to have some more time before go/no-go
17:42:57 <kparal> I'll bother our interns to fill the missing matrix results tomorrow
17:43:44 <adamw> yay interns
17:43:49 <adamw> throw some more interns into the boilers
17:44:17 <tflink> if there's nothing else, the fuse is set for [0,5] minutes
17:45:26 <Martix> adamw: ?
17:45:26 <pjones> adamw: so, I have an update on the grub2 problem
17:45:35 <adamw> pjones: oh yup?
17:45:47 <pjones> adamw: the good news is that I know where to look for the problem!  the bad news is that rebasing to upstream won't fix it.
17:45:59 <pjones> adamw: in short: it works if I build with F18's toolchain and fails with F19's.
17:46:23 <adamw> ah
17:46:39 <adamw> good news that you've narrowed it down a bit though
17:46:45 <pjones> So that's slow and painful, but it means I know what to look for.
17:46:51 <pjones> kind of, anyway.
17:46:52 <adamw> didn't we have something similar to this before? seems like bootloaders are very susceptible to changes in teh build toolchain
17:46:59 <pjones> yep
17:47:04 <adamw> oh, that was the core image getting bigger, wasn't it
17:47:06 <pjones> happens... well, let's call it "constantly".
17:47:09 <adamw> :P
17:47:21 <pjones> Welcome to my hell.
17:47:29 <adamw> okay, that's good news. we're still fine with the console workaround for alpha, though, right?
17:47:36 <pjones> oh yes.
17:47:42 <adamw> coolbeans.
17:49:08 <tflink> anything else?
17:49:22 * tflink resets fuse for [0,5] minutes
17:49:57 <adamw> we really ought to patent our fuse design, y'know
17:50:53 <jreznik> adamw & tflink are going to be f*ing rich!
17:51:03 <adamw> pardon me, when I say we, I mean "I"
17:51:11 <adamw> tflink gets a pair of concrete brogues
17:55:33 <tflink> sounds like I'm in for some fun times
17:55:53 <adamw> you like swimming, right?
17:56:40 * adamw taps on fuse
17:56:47 <adamw> i guess it still needs some refinements.
17:57:20 <tflink> thanks for coming, everyone!
17:57:27 * tflink will send out minutes shortly
17:57:31 <tflink> #endmeeting