17:00:17 #startmeeting F19 Alpha Go/No-Go meeting 17:00:17 Meeting started Thu Apr 11 17:00:17 2013 UTC. The chair is jreznik. Information about MeetBot at http://wiki.debian.org/MeetBot. 17:00:17 Useful Commands: #action #agreed #halp #info #idea #link #topic. 17:00:32 #meetingname F19 Alpha Go/No-Go meeting 17:00:33 The meeting name has been set to 'f19_alpha_go/no-go_meeting' 17:00:50 #topic Roll Call 17:00:54 * nirik is here. 17:01:01 hey all! 17:01:17 * satellit listening but afk 17:01:45 * jreznik hopes his connection will stand through the meeting, having difficulties... 17:02:19 let's wait a moment for people to come 17:02:20 Heyo. 17:02:52 #info just a reminder - Readiness meeting follows in this channel two hours later, even we say No-Go here 17:03:05 (also for guys who thought Readiness is now ;-) 17:03:36 * tflink 17:03:40 * tflink is here 17:03:52 sigh, always miss this channel 17:04:22 it's better to use -1 to avoid conflicts... 17:04:49 seems like people are popping in - let's start with secretary stuff 17:05:03 #chair nirik rbergeron tflink adamw 17:05:03 Current chairs: adamw jreznik nirik rbergeron tflink 17:05:08 I swear, yesterday things looked like magic :) 17:05:31 ;-) 17:05:32 #topic Purpose of this meeting 17:05:41 #info Purpose of this meeting is to see whether or not F19 Alpha is ready for shipment, according to the release criteria. 17:05:48 #info This is determined in a few ways: 17:05:53 #info No remaining blocker bugs 17:05:57 #info Test matrices for Alpha are fully completed 17:06:16 #link http://qa.fedoraproject.org/blockerbugs/milestone/19/alpha/buglist 17:06:35 #link https://fedoraproject.org/wiki/Test_Results:Fedora_19_Alpha_RC2_Install 17:06:50 #link https://fedoraproject.org/wiki/Test_Results:Fedora_19_Alpha_RC2_Base 17:07:04 #link https://fedoraproject.org/wiki/Test_Results:Fedora_19_Alpha_RC2_Desktop 17:09:05 I think the best idea now is start with mini blocker review - we have 3 bugs as accepted blockers, all verified and 4 more proposed bugs we should go through 17:09:26 tflink, adamw: may I ask you to lead it? 17:09:42 tflink, you prepared? 17:09:56 yeah 17:10:19 #info The criteria for release blocking bugs can be found at: 17:10:19 #link https://fedoraproject.org/wiki/Fedora_19_Alpha_Release_Criteria 17:10:36 tflink: thanks for addition 17:10:52 * tflink assumes that we want to go through all of the currently proposed blockers 17:11:03 #info Up for review today, we have: 17:11:19 #info 4 Proposed Blockers 17:11:35 note that there are 3 accepted blockers, all VERIFIED and not in need of review at this time 17:12:05 #topic (950700) NameError: global name 'encryption_changed' is not defined 17:12:08 #link https://bugzilla.redhat.com/show_bug.cgi?id=950700 17:12:10 #info Proposed Blocker, anaconda, ASSIGNED 17:12:47 i think encryption works if you don't go through custom partitioning, so i'd probably be -1 to this; we don't require anything from custom partitioning at alpha./ 17:12:50 probably +1 fe though 17:13:01 I'm not really sure why this is a blocker but yeah, easy to hit 17:13:13 encryption is for beta, sure 17:13:22 * tflink didn't realize that this got reported - hit bz errors in libreport when it happened 17:13:26 encryption is for alpha 17:13:28 but custom is for beta 17:13:30 -1 blocker, +1 FE if the fix is non intrusive. 17:14:09 adamw: I see Creating encrypted partitions in Beta criteria - it's about creation 17:14:16 oh, okay 17:14:18 i thought it was in alpha 17:14:24 * rbergeron is -1 blocker as well 17:14:40 well, double -1 then :) 17:14:49 -1 blocker 17:15:07 proposed #agreed 950700 - RejectedBlocker, AcceptedFreezeException - Custom partitioning is not part of the alpha release requirements and thus, this does not qualify for release blocking status for F19 alpha. However, it is really easy to hit and would be good to fix - a tested fix would be considered past freeze if it isn't too intrusive or risky. 17:15:37 adamw: for alpha it's "In all of the above cases, if any system partitions were encrypted as part of the installation, the boot process must prompt for the passphrase(s) and correctly unlock the partition(s) when provided with the correct passphrase(s). " 17:15:39 adamw: IIRC, you can hit this without marking partitions as encrypted 17:15:48 it happens either way 17:16:24 ack 17:16:30 jreznik: that doesn't actually require that encryption works, so it's fine 17:16:33 ack 17:16:37 ack 17:16:39 ack 17:16:47 #agreed 950700 - RejectedBlocker, AcceptedFreezeException - Custom partitioning is not part of the alpha release requirements and thus, this does not qualify for release blocking status for F19 alpha. However, it is really easy to hit and would be good to fix - a tested fix would be considered past freeze if it isn't too intrusive or risky. 17:16:58 #topic (950709) Clean pstore at install time 17:16:58 #link https://bugzilla.redhat.com/show_bug.cgi?id=950709 17:16:58 #info Proposed Blocker, anaconda, NEW 17:17:38 IIRC, this is a workaround/response to #947142 17:18:04 not really 17:18:24 it's more that, if you're affected by 950709, then you'll be stuffed even if we fix 947142 17:18:25 yep, for most people #947142 is this bug 17:18:34 jreznik: i don't think that's been demonstrated. 17:18:42 you can't just assume it. 17:19:46 * nirik really should get a efi machine here to test with someday. 17:19:50 at least for kamil it worked but he used efibootmgr 17:19:51 so, this one will only affect people who have existing f17 or f18 UEFI native installs and have hit some kernel crashes. 17:20:19 it's pretty tricky to recover from if you _do_ get hit by it, though. 17:20:21 adamw: does that mean upgrade ? or just a machine that ran f18/f17? 17:20:26 Pardon my ignorance on the issue, but is that just clearing out Fedora's storage, or the entire storage? 17:20:30 nirik: just a machine that has been running f17 or f18. 17:20:31 nirik: just machine 17:20:55 jsmith: it'd be anything that writes crashes there. i think the patch is in upstream kernel so other distros could be putting tracebacks there, I guess. 17:21:05 jwb would be the best person to ask for sure though, it hink 17:21:21 doing this @ install time seems like an odd place to be clearing out the nvram to me 17:21:28 jsmith: it's not like this is hugely valuable data, though, I don't think anyone would cry if we wiped a kernel crash from another distro 17:21:45 tflink: how else could we do it? 17:21:50 btw. other idea is to add support to Abrt - Abrt takes a look, reports it and wipes it, /me talked to abrt guys today about it 17:21:57 adamw: No, there may be other situations where they'll hit it 17:22:02 adamw: True that, I was just curious if anybody else would complain about us tampering with "their" data 17:22:05 jreznik: it's not 'other idea' exactly, they want to do both 17:22:19 mjg59: sorry, 'no' to what? 17:22:23 adamw: it just seems kind of unlikely that this would prevent too many issues - what about upgrades? 17:22:26 18:19 < adamw> so, this one will only affect people who have existing f17 or f18 UEFI native installs and have hit some kernel crashes. 17:22:30 adamw: sorry, wasn't clear - that's another piece of puzzle 17:22:40 tflink: upgrades should be fine as they don't involve poking efibootmgr. 17:22:51 mjg59: ah, okay. what other scenarios can it hit? 17:23:03 if the nvram is already full, aren't people pretty much screwed already? 17:23:09 adamw: Other Linuxes, any other situation in which EFI variables have been created and deleted 17:23:23 tflink: screwed in what way? it's only a problem if you need to write something to it, which doesn't happen _that_ often 17:23:27 or would this clear the crashes from nvram before doing modifications? 17:24:27 mjg59: well, this bug is specifically about kernel traces in the pstore, isn't it? or do other things get written there? 17:24:28 if it's clearing cruft from nvram to avoid problems, I think I just misunderstood what was being proposed 17:24:31 tflink: that is the intent 17:24:43 tflink: anaconda should clean out pstore before running efibootmgr. aiui. 17:25:12 What about people who have more than one OS. Maybe the don't want test installs of Fedora to be clearing recent kernel crash data? 17:25:14 adamw: at various points pstore was configured to write on reboot, not just on crash 17:25:29 ah 17:25:51 brunowolff: like i said, i can't see that anyone would get really hopping mad about it. it's not like its their tax documents. 17:26:18 so anyhow, i'm definitely +1 FE to this at a minimum 17:26:19 brunowolff: we should at least wipe only our logs, so not wipe * 17:26:21 blocker is rather difficult to call 17:26:38 +1 FE sure 17:26:53 maybe we should discuss the both related bugs as one I'd say in this point 17:26:54 yeah, it seems rather unlikely that people would get mad about this - if they wanted the data, I think they would have retrieved it before doing another install 17:27:02 is there a workaround/manual way to move it forward? 17:27:03 Do you get asked whether or not to do this during the install process? 17:27:10 nirik: it is 17:27:25 brunowolff: i don't know. i'd think doing that would be very bad UI, as you can hardly assume people know what the hell a pstore is. but eh 17:27:27 nirik: http://mjg59.dreamwidth.org/23554.html 17:27:37 adamw: :) 17:28:11 * jreznik now knows what pstore is (barely) 17:29:03 but at least - for FE - we have to clearly document it in case we would go with it - release notes/common bugs 17:29:13 Is this consistent with how pstore cleanup happens while you are running Fedora? You can't keep adding kernel crash data forever, so something must be limiting pstore use now. 17:29:15 I guess I'm slight -1 to blocker if we can document a workaround and aren't sure that this is all that widespread. 17:29:37 it's pretty impossible to be sure either way 17:29:38 (mean FE we do not fix and ship) 17:29:49 I thought it was only certain kinds of kernel crashes that wrote to pstore 17:29:56 brunowolff: we have nothing cleaning it up at present, which is kind of the probelm 17:30:01 brunowolff: they just get written until it's full. 17:30:22 brunowolff: the 'other bug' jreznik mentioned is a feature request for abrt to clean it up on running systems 17:31:33 so it sounds like we're mostly +1 FE? 17:31:37 -1 blocker 17:31:47 er, mostly -1/+1 17:31:53 brunowolff: https://bugzilla.redhat.com/show_bug.cgi?id=949721 17:32:05 i am. 17:32:16 * nirik nods 17:32:30 It doesn't feel like an alpha blocker. I wouldn't expect it to hit that may people. 17:32:48 brunowolff: that's the question... 17:33:12 well documented in case we would not have a fix for release, I'm -1/+1 17:33:44 it's very hard to say, but yeah... 17:33:44 i'm really not that confident in -1, i think we're just guessing. but i'm not entirely against it. 17:33:46 proposed #agreed 950709 - RejectedBlocker, AcceptedFreezeException - This doesn't seem critical enough to justify blocking the release of F19 alpha but it is an issue that will need to be dealt with at some point. A tested fix would be considered past freeze for inclusion in F19 Alpha. 17:33:55 ack 17:33:59 ack 17:34:19 ACK 17:34:29 #agreed 950709 - RejectedBlocker, AcceptedFreezeException - This doesn't seem critical enough to justify blocking the release of F19 alpha but it is an issue that will need to be dealt with at some point. A tested fix would be considered past freeze for inclusion in F19 Alpha. 17:34:41 #topic (949761) EFI installed system fails to boot (Fedora-19-Alpha-TC5) 17:34:44 #link https://bugzilla.redhat.com/show_bug.cgi?id=949761 17:34:47 #info Proposed Blocker, grub2, NEW 17:34:55 ooh, the fun one! 17:35:10 basically, this seems to break all HW uefi installs 17:35:32 there is a workaround to alter the grub configuration to use a console, though 17:36:08 ugh. 17:36:13 Looks ugly 17:36:20 it is 17:36:42 not sure we can justify releasing with this bug 17:36:49 uefi isn't as rare as it used to be 17:37:04 and it's a pretty clear criteria violation 17:37:05 yeah. Sadly looks like a blocker. 17:37:41 might be we could do some hacky workaround quickly for alpha and fix it properly as time permits? (ie, make it default to console for alpha?) 17:38:18 possibly, but I'm not sure that's a good idea 17:38:26 The ticket lists a particular way to do the install using livecd-iso-to-disk, does this really apply to all install methods? 17:38:30 yeah, this is pretty hard to handwave away 17:38:36 nirik: that's actually the fix pjones is proposing. 17:38:37 It's going to be fixed by defaulting to console 17:38:45 it seems like the kind of hack that is really risky and would require more testing than we have time for 17:38:49 ok 17:38:57 brunowolff: so far I'm pretty sure it does. every UEFI install I've heard of that gets past bootloader installation has hit his bug. 17:39:53 it's really late for any kind of hackish workaround - it's release with nasty workaround or slip 17:40:08 * jreznik is going to ask pjones to join us 17:40:15 Then I think this should be considered a blocker. All EFI is probably too many systems these days. 17:40:21 I'm +1 blocker 17:40:51 I'm a little confused here. The maintainer is going to avoid the bug by defaulting to console. 17:40:52 * nirik is +1 blocker too sadly. 17:41:01 +1 blocker 17:41:05 mjg59: yes. 17:41:14 So I don't understand why there's discussion of whether or not that's an acceptable hack or not 17:41:32 I don't either, really, but hey. just let it flow. 17:41:42 * nirik either. 17:41:44 proposed #agreed 949761 - AcceptedBlocker - Violates the following F19 alpha release criterion for all known UEFI systems which complete an install: "A system installed with a graphical package set must boot to the 'firstboot' utility on the first boot after installation. The firstboot utility must be able to create a working user account." 17:41:52 yes, we know the verbage is out of date 17:42:06 I ack 17:42:07 ack 17:42:11 ha. loophole! :) 17:42:13 ack 17:42:37 ack 17:42:50 #agreed 949761 - AcceptedBlocker - Violates the following F19 alpha release criterion for all known UEFI systems which complete an install: "A system installed with a graphical package set must boot to the 'firstboot' utility on the first boot after installation. The firstboot utility must be able to create a working user account." 17:43:41 mjg59: I wasn't trying to criticize the fix, just that it would need more testing than we currently have time for without slipping 17:44:06 #topic (947142) write to /sys/firmware/efi/vars/new_var results in ENOSPC 17:44:08 * jreznik understood it as tflink is trying to explain 17:44:09 #link https://bugzilla.redhat.com/show_bug.cgi?id=947142 17:44:11 #info Proposed Blocker, kernel, NEW 17:44:32 with this one we're pretty much guessing still 17:44:56 several people did hit either this or the pstore one (it's pretty hard to tell which they hit) after the call for testing 17:45:13 we can punt on it since we're already no-go 17:45:25 sure, but it'd be good to have a clear plan going forward 17:45:29 true 17:45:34 and seems firmware makes some difference too 17:45:35 if we're slipping i'd really like to get all three addressed if that's at all possible 17:45:48 for one system at least, yeah 17:47:04 given my experiences with asus uefi firmware, that doesn't surprise me a whole lot :-/ 17:47:04 Yes, firmware behaviour is important here 17:47:19 The behaviour in question is unspecified, so all behaviours are acceptable 17:48:01 yay standards! 17:48:29 mjg59: do you have a feel on whether this and/or the pstore issue ought to be blockers? i appreciate it's a pretty tough thing to pick. 17:48:57 adamw: Well, it prevents installation on a significant proportion of computers 17:49:15 Which sounds like the kind of thing that would usually be classed as a blocker 17:49:15 Given this one seems to leave people in a bad place in some cases, I'd be inclined to say blcoked even if not that many people are affected. 17:49:16 yeah, the problem is guessing what the percentage is, I guess :/ 17:49:23 mjg59: that question is how significant and how many are affected by only this one and the other one 17:49:30 Oh, yeah, and it fails at the end of installation after it's already wiped your drive 17:49:33 and yeah, the fact that you can have your old boot entry wiped but no new one created kinda sucks 17:49:46 jreznik: Somewhere between 0% and 100%. I have no mechanism for determining. 17:49:58 sounds pretty blockery to me 17:50:04 although you can't really do two fedora UEFI installs alongside each other anyway, so that may be a bit of a moot point 17:50:09 * nirik thinks it sounds blockery too 17:50:23 we need that evidence that more bugs are caused by pstore one than this one 17:50:31 adamw: not without some manual boot entry hackery, anyways 17:50:36 try guys to reproduce with wiped pstore 17:50:49 (who experienced this one) 17:51:01 at least kamil reports it made a difference 17:51:42 i hit this one on a machine with empty pstore. 17:52:02 well, i'll double check, but i'm pretty sure it's empty. 17:52:08 yeah, that can happen. 17:53:10 mjg59: is it plausible we can get a fix for this by next tuesday? wednesday at the latest? 17:53:26 adamw: Plausible, but not guaranteed 17:53:32 Still working on this with upstream 17:54:22 okay 17:54:31 welp, I'm +1 FE at minimum 17:54:33 probably +1 blocker 17:54:44 +1 blocker 17:55:14 +1 FE, for blocker I'd really like to see more data - seems quite fuzzy 17:55:36 but really would like to see it solved even it means slipping (the whole UEFI mess) 17:56:32 jreznik: is that a -1 blocker? 17:56:37 If we burn even a small number of testers by making there machines unbootable (which is what it appears can happen) that's going to hurt our reputation a lot. 17:56:50 proposed #agreed 947142 - AcceptedBlocker - While this does not affect 100% of uefi machines, it leaves the system in a bad, difficult to recover place. Thus, accepted as a blocker for F19 alpha due to violation of the following criterion for a non-trivial number of uefi systems: "When using the dedicated installer images, the installer must be able to complete an installation using the text, graphical and VNC installation interfaces." 17:56:59 ack 17:57:23 ack/nak-patch? 17:57:31 brunowolff: that completely broken system is what scares me most 17:58:19 ack 17:59:01 * jreznik would like to see this one coupled with FE we accepted above - at least make sure we have that FE fix 17:59:21 ack 17:59:23 ack 17:59:38 #agreed 947142 - AcceptedBlocker - While this does not affect 100% of uefi machines, it leaves the system in a bad, difficult to recover place. Thus, accepted as a blocker for F19 alpha due to violation of the following criterion for a non-trivial number of uefi systems: "When using the dedicated installer images, the installer must be able to complete an installation using the text, graphical and VNC installation interfaces." 17:59:51 OK, that's all of the blockers on my list 18:00:21 tflink: thanks! 18:00:27 jreznik: np 18:00:32 Guys: I'm going to point everyone towards #fedora-meeting-2 it looks like, for the Board Meeting 18:00:44 #fedora-meeting-pi 18:01:00 heh 18:01:05 rbergeron: it wasn't updated in the channels table and I completely forget it, sorry 18:01:06 adamw: now you're just getting irrational. 18:01:17 ten points 18:01:22 jreznik: it's right between them 18:01:42 it's no biggie 18:02:07 nirik: get real 18:02:07 rbergeron: still wed 18:02:19 so test coverage isn't bad, but we don't really need to go through that i guess, since we now have open blockers 18:02:25 we can just jump straight to go/no-go? 18:02:29 adamw: yes 18:02:36 #topic Go/No-Go 18:03:31 well, we have just accepted two new blocker bugs we want to solve for Alpha 18:03:46 so if nobody objects, it's No-Go now 18:03:54 ack 18:04:04 yeah, i don't see any kinda hero effort here 18:04:13 i thought we might actually be able to ship on time for a change, but hey. 18:04:44 Plus it sounds like it isn't worth trying to do a short slip. 18:05:08 adamw: we would loose our reputation... 18:05:18 Heh 18:05:18 rackerhacker, inode0, nb, gholms -- we're in #fedora-meeting-2, fyi 18:05:30 ah 18:05:33 brunowolff: let's hope for a short one 18:05:42 jreznik: i think he means <1 week 18:05:50 i think ideal here is 1 week slip and fix all three big UEFI issues, if we can swing that 18:05:54 ah, ok 18:06:04 pjon: mjg59: you guys know where we stand now, right? 18:06:08 doh 18:06:10 adamw: yep, one week makes sense, especiall for mjg59's one 18:06:43 mjg59: any chance to get a fix even it would not be accepted for 100% by upstream? otherwise we are screwed 18:07:54 jreznik: No, this needs to be upstream acceptable 18:09:52 #agreed due to severe UEFI related bugs, it was agreed to slip Fedora 19 Alpha for one week 18:10:03 * pbrobinson is here 18:10:14 pbrobinson: -> #fedora-meeting-2, sorry 18:10:22 (my scheduling...) 18:11:01 anything else? 18:11:10 jreznik: tut tut 18:11:48 #action jreznik to announce slip 18:12:57 if not, I'll end the meeting in a few minutes 18:12:59 * nirik nods. sad. 18:13:03 #topic Open floor 18:13:33 think that's all, really, looks like the uefi stuff is the only stumbling block 18:14:30 well, at least we should have a plan B in case we won't have the kernel fix in time - so spread the call for testing - ask people to update firmware, to wipe out pstore and test, test... 18:15:14 * jreznik is sad we slipped but inside he thinks it safer and better to have a "solid" uefi for alpha, not hitting this issues later in the release cycle 18:15:46 #info reminder - the Readiness meeting follows in this channel, 19:00 UTC 18:15:48 jreznik, better slip now than later IMHO 18:15:59 Southern_Gentlem: yep, that's my thought 18:16:14 If we can figure out triggers for 947142, maybe we could put in a hack to block installs if we don't have a fix in time. 18:16:15 the more gets fixed now no slips later 18:17:14 brunowolff: kamil has an idea - do the efi entry in opposite way - try to add new one and if succeed remove the old one 18:17:31 in the worst case you would end up with dupes, not unbootable system... 18:17:55 not sure how crazy it is... 18:18:38 setting fuse now... 3... 18:18:49 thank you for coming! 18:20:13 2... 18:21:21 1... 18:23:17 #endmeeting