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