17:00:17 <jreznik> #startmeeting F19 Alpha Go/No-Go meeting
17:00:17 <zodbot> 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 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
17:00:32 <jreznik> #meetingname F19 Alpha Go/No-Go meeting
17:00:33 <zodbot> The meeting name has been set to 'f19_alpha_go/no-go_meeting'
17:00:50 <jreznik> #topic Roll Call
17:00:54 * nirik is here.
17:01:01 <jreznik> 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 <jreznik> let's wait a moment for people to come
17:02:20 <rbergeron> Heyo.
17:02:52 <jreznik> #info just a reminder - Readiness meeting follows in this channel two hours later, even we say No-Go here
17:03:05 <jreznik> (also for guys who thought Readiness is now ;-)
17:03:36 * tflink 
17:03:40 * tflink is here
17:03:52 <adamw> sigh, always miss this channel
17:04:22 <jreznik> it's better to use -1 to avoid conflicts...
17:04:49 <jreznik> seems like people are popping in - let's start with secretary stuff
17:05:03 <jreznik> #chair nirik rbergeron tflink adamw
17:05:03 <zodbot> Current chairs: adamw jreznik nirik rbergeron tflink
17:05:08 <rbergeron> I swear, yesterday things looked like magic :)
17:05:31 <jreznik> ;-)
17:05:32 <jreznik> #topic Purpose of this meeting
17:05:41 <jreznik> #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 <jreznik> #info This is determined in a few ways:
17:05:53 <jreznik> #info No remaining blocker bugs
17:05:57 <jreznik> #info Test matrices for Alpha are fully completed
17:06:16 <jreznik> #link http://qa.fedoraproject.org/blockerbugs/milestone/19/alpha/buglist
17:06:35 <jreznik> #link https://fedoraproject.org/wiki/Test_Results:Fedora_19_Alpha_RC2_Install
17:06:50 <jreznik> #link https://fedoraproject.org/wiki/Test_Results:Fedora_19_Alpha_RC2_Base
17:07:04 <jreznik> #link https://fedoraproject.org/wiki/Test_Results:Fedora_19_Alpha_RC2_Desktop
17:09:05 <jreznik> 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 <jreznik> tflink, adamw: may I ask you to lead it?
17:09:42 <adamw> tflink, you prepared?
17:09:56 <tflink> yeah
17:10:19 <tflink> #info The criteria for release blocking bugs can be found at:
17:10:19 <tflink> #link https://fedoraproject.org/wiki/Fedora_19_Alpha_Release_Criteria
17:10:36 <jreznik> tflink: thanks for addition
17:10:52 * tflink assumes that we want to go through all of the currently proposed blockers
17:11:03 <tflink> #info Up for review today, we have:
17:11:19 <tflink> #info 4 Proposed Blockers
17:11:35 <tflink> note that there are 3 accepted blockers, all VERIFIED and not in need of review at this time
17:12:05 <tflink> #topic (950700) NameError: global name 'encryption_changed' is not defined
17:12:08 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=950700
17:12:10 <tflink> #info Proposed Blocker, anaconda, ASSIGNED
17:12:47 <adamw> 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 <adamw> probably +1 fe though
17:13:01 <tflink> I'm not really sure why this is a blocker but yeah, easy to hit
17:13:13 <jreznik> 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 <adamw> encryption is for alpha
17:13:28 <adamw> but custom is for beta
17:13:30 <nirik> -1 blocker, +1 FE if the fix is non intrusive.
17:14:09 <jreznik> adamw: I see Creating encrypted partitions in Beta criteria - it's about creation
17:14:16 <adamw> oh, okay
17:14:18 <adamw> i thought it was in alpha
17:14:24 * rbergeron is -1 blocker as well
17:14:40 <adamw> well, double -1 then :)
17:14:49 <jreznik> -1 blocker
17:15:07 <tflink> 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 <jreznik> 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 <tflink> adamw: IIRC, you can hit this without marking partitions as encrypted
17:15:48 <tflink> it happens either way
17:16:24 <nirik> ack
17:16:30 <adamw> jreznik: that doesn't actually require that encryption works, so it's fine
17:16:33 <brunowolff> ack
17:16:37 <adamw> ack
17:16:39 <jreznik> ack
17:16:47 <tflink> #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 <tflink> #topic (950709) Clean pstore at install time
17:16:58 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=950709
17:16:58 <tflink> #info Proposed Blocker, anaconda, NEW
17:17:38 <tflink> IIRC, this is a workaround/response to #947142
17:18:04 <adamw> not really
17:18:24 <adamw> it's more that, if you're affected by 950709, then you'll be stuffed even if we fix 947142
17:18:25 <jreznik> yep, for most people #947142 is this bug
17:18:34 <adamw> jreznik: i don't think that's been demonstrated.
17:18:42 <adamw> you can't just assume it.
17:19:46 * nirik really should get a efi machine here to test with someday.
17:19:50 <jreznik> at least for kamil it worked but he used efibootmgr
17:19:51 <adamw> 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 <adamw> it's pretty tricky to recover from if you _do_ get hit by it, though.
17:20:21 <nirik> adamw: does that mean upgrade ? or just a machine that ran f18/f17?
17:20:26 <jsmith> Pardon my ignorance on the issue, but is that just clearing out Fedora's storage, or the entire storage?
17:20:30 <adamw> nirik: just a machine that has been running f17 or f18.
17:20:31 <jreznik> nirik: just machine
17:20:55 <adamw> 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 <adamw> jwb would be the best person to ask for sure though, it hink
17:21:21 <tflink> doing this @ install time seems like an odd place to be clearing out the nvram to me
17:21:28 <adamw> 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 <adamw> tflink: how else could we do it?
17:21:50 <jreznik> 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 <mjg59> adamw: No, there may be other situations where they'll hit it
17:22:02 <jsmith> adamw: True that, I was just curious if anybody else would complain about us tampering with "their" data
17:22:05 <adamw> jreznik: it's not 'other idea' exactly, they want to do both
17:22:19 <adamw> mjg59: sorry, 'no' to what?
17:22:23 <tflink> adamw: it just seems kind of unlikely that this would prevent too many issues - what about upgrades?
17:22:26 <mjg59> 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 <jreznik> adamw: sorry, wasn't clear - that's another piece of puzzle
17:22:40 <adamw> tflink: upgrades should be fine as they don't involve poking efibootmgr.
17:22:51 <adamw> mjg59: ah, okay. what other scenarios can it hit?
17:23:03 <tflink> if the nvram is already full, aren't people pretty much screwed already?
17:23:09 <mjg59> adamw: Other Linuxes, any other situation in which EFI variables have been created and deleted
17:23:23 <adamw> 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 <tflink> or would this clear the crashes from nvram before doing modifications?
17:24:27 <adamw> 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 <tflink> if it's clearing cruft from nvram to avoid problems, I think I just misunderstood what was being proposed
17:24:31 <adamw> tflink: that is the intent
17:24:43 <adamw> tflink: anaconda should clean out pstore before running efibootmgr. aiui.
17:25:12 <brunowolff> 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 <mjg59> adamw: at various points pstore was configured to write on reboot, not just on crash
17:25:29 <adamw> ah
17:25:51 <adamw> 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 <adamw> so anyhow, i'm definitely +1 FE to this at a minimum
17:26:19 <jreznik> brunowolff: we should at least wipe only our logs, so not wipe *
17:26:21 <adamw> blocker is rather difficult to call
17:26:38 <jreznik> +1 FE sure
17:26:53 <jreznik> maybe we should discuss the both related bugs as one I'd say in this point
17:26:54 <tflink> 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 <nirik> is there a workaround/manual way to move it forward?
17:27:03 <brunowolff> Do you get asked whether or not to do this during the install process?
17:27:10 <jreznik> nirik: it is
17:27:25 <adamw> 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 <jreznik> nirik: http://mjg59.dreamwidth.org/23554.html
17:27:37 <rbergeron> adamw: :)
17:28:11 * jreznik now knows what pstore is (barely)
17:29:03 <jreznik> 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 <brunowolff> 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 <nirik> 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 <adamw> it's pretty impossible to be sure either way
17:29:38 <jreznik> (mean FE we do not fix and ship)
17:29:49 <tflink> I thought it was only certain kinds of kernel crashes that wrote to pstore
17:29:56 <adamw> brunowolff: we have nothing cleaning it up at present, which is kind of the probelm
17:30:01 <adamw> brunowolff: they just get written until it's full.
17:30:22 <adamw> brunowolff: the 'other bug' jreznik mentioned is a feature request for abrt to clean it up on running systems
17:31:33 <tflink> so it sounds like we're mostly +1 FE?
17:31:37 <tflink> -1 blocker
17:31:47 <tflink> er, mostly -1/+1
17:31:53 <jreznik> brunowolff: https://bugzilla.redhat.com/show_bug.cgi?id=949721
17:32:05 <rbergeron> i am.
17:32:16 * nirik nods
17:32:30 <brunowolff> It doesn't feel like an alpha blocker. I wouldn't expect it to hit that may people.
17:32:48 <jreznik> brunowolff: that's the question...
17:33:12 <jreznik> well documented in case we would not have a fix for release, I'm -1/+1
17:33:44 <nirik> it's very hard to say, but yeah...
17:33:44 <adamw> i'm really not that confident in -1, i think we're just guessing. but i'm not entirely against it.
17:33:46 <tflink> 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 <nirik> ack
17:33:59 <adamw> ack
17:34:19 <jsmith> ACK
17:34:29 <tflink> #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 <tflink> #topic (949761) EFI installed system fails to boot (Fedora-19-Alpha-TC5)
17:34:44 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=949761
17:34:47 <tflink> #info Proposed Blocker, grub2, NEW
17:34:55 <tflink> ooh, the fun one!
17:35:10 <tflink> basically, this seems to break all HW uefi installs
17:35:32 <tflink> there is a workaround to alter the grub configuration to use a console, though
17:36:08 <nirik> ugh.
17:36:13 <jsmith> Looks ugly
17:36:20 <tflink> it is
17:36:42 <tflink> not sure we can justify releasing with this bug
17:36:49 <tflink> uefi isn't as rare as it used to be
17:37:04 <tflink> and it's a pretty clear criteria violation
17:37:05 <nirik> yeah. Sadly looks like a blocker.
17:37:41 <nirik> 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 <tflink> possibly, but I'm not sure that's a good idea
17:38:26 <brunowolff> 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 <adamw> yeah, this is pretty hard to handwave away
17:38:36 <adamw> nirik: that's actually the fix pjones is proposing.
17:38:37 <mjg59> It's going to be fixed by defaulting to console
17:38:45 <tflink> it seems like the kind of hack that is really risky and would require more testing than we have time for
17:38:49 <nirik> ok
17:38:57 <adamw> 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 <jreznik> 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 <brunowolff> Then I think this should be considered a blocker. All EFI is probably too many systems these days.
17:40:21 <tflink> I'm +1 blocker
17:40:51 <mjg59> 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 <adamw> +1 blocker
17:41:05 <adamw> mjg59: yes.
17:41:14 <mjg59> So I don't understand why there's discussion of whether or not that's an acceptable hack or not
17:41:32 <adamw> I don't either, really, but hey. just let it flow.
17:41:42 * nirik either.
17:41:44 <tflink> 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 <tflink> yes, we know the verbage is out of date
17:42:06 <brunowolff> I ack
17:42:07 <adamw> ack
17:42:11 <nirik> ha. loophole! :)
17:42:13 <nirik> ack
17:42:37 <jreznik> ack
17:42:50 <tflink> #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 <tflink> 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 <tflink> #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 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=947142
17:44:11 <tflink> #info Proposed Blocker, kernel, NEW
17:44:32 <adamw> with this one we're pretty much guessing still
17:44:56 <adamw> 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 <tflink> we can punt on it since we're already no-go
17:45:25 <adamw> sure, but it'd be good to have a clear plan going forward
17:45:29 <tflink> true
17:45:34 <jreznik> and seems firmware makes some difference too
17:45:35 <adamw> if we're slipping i'd really like to get all three addressed if that's at all possible
17:45:48 <adamw> for one system at least, yeah
17:47:04 <tflink> given my experiences with asus uefi firmware, that doesn't surprise me a whole lot :-/
17:47:04 <mjg59> Yes, firmware behaviour is important here
17:47:19 <mjg59> The behaviour in question is unspecified, so all behaviours are acceptable
17:48:01 <adamw> yay standards!
17:48:29 <adamw> 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 <mjg59> adamw: Well, it prevents installation on a significant proportion of computers
17:49:15 <mjg59> Which sounds like the kind of thing that would usually be classed as a blocker
17:49:15 <brunowolff> 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 <adamw> yeah, the problem is guessing what the percentage is, I guess :/
17:49:23 <jreznik> mjg59: that question is how significant and how many are affected by only this one and the other one
17:49:30 <mjg59> Oh, yeah, and it fails at the end of installation after it's already wiped your drive
17:49:33 <adamw> and yeah, the fact that you can have your old boot entry wiped but no new one created kinda sucks
17:49:46 <mjg59> jreznik: Somewhere between 0% and 100%. I have no mechanism for determining.
17:49:58 <tflink> sounds pretty blockery to me
17:50:04 <adamw> 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 <jreznik> we need that evidence that more bugs are caused by pstore one than this one
17:50:31 <tflink> adamw: not without some manual boot entry hackery, anyways
17:50:36 <jreznik> try guys to reproduce with wiped pstore
17:50:49 <jreznik> (who experienced this one)
17:51:01 <jreznik> at least kamil reports it made a difference
17:51:42 <adamw> i hit this one on a machine with empty pstore.
17:52:02 <adamw> well, i'll double check, but i'm pretty sure it's empty.
17:52:08 <pjones> yeah, that can happen.
17:53:10 <adamw> mjg59: is it plausible we can get a fix for this by next tuesday? wednesday at the latest?
17:53:26 <mjg59> adamw: Plausible, but not guaranteed
17:53:32 <mjg59> Still working on this with upstream
17:54:22 <adamw> okay
17:54:31 <adamw> welp, I'm +1 FE at minimum
17:54:33 <adamw> probably +1 blocker
17:54:44 <brunowolff> +1 blocker
17:55:14 <jreznik> +1 FE, for blocker I'd really like to see more data - seems quite fuzzy
17:55:36 <jreznik> but really would like to see it solved even it means slipping (the whole UEFI mess)
17:56:32 <tflink> jreznik: is that a -1 blocker?
17:56:37 <brunowolff> 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 <tflink> 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 <brunowolff> ack
17:57:23 <tflink> ack/nak-patch?
17:57:31 <jreznik> brunowolff: that completely broken system is what scares me most
17:58:19 <adamw> 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 <jreznik> ack
17:59:23 <nirik> ack
17:59:38 <tflink> #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 <tflink> OK, that's all of the blockers on my list
18:00:21 <jreznik> tflink: thanks!
18:00:27 <tflink> jreznik: np
18:00:32 <rbergeron> Guys: I'm going to point everyone towards #fedora-meeting-2 it looks like, for the Board Meeting
18:00:44 <adamw> #fedora-meeting-pi
18:01:00 <Sparks> heh
18:01:05 <jreznik> rbergeron: it wasn't updated in the channels table and I completely forget it, sorry
18:01:06 <nirik> adamw: now you're just getting irrational.
18:01:17 <adamw> ten points
18:01:22 <rbergeron> jreznik: it's right between them
18:01:42 <rbergeron> it's no biggie
18:02:07 <rdieter> nirik: get real
18:02:07 <jreznik> rbergeron: still wed
18:02:19 <adamw> 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 <adamw> we can just jump straight to go/no-go?
18:02:29 <jreznik> adamw: yes
18:02:36 <jreznik> #topic Go/No-Go
18:03:31 <jreznik> well, we have just accepted two new blocker bugs we want to solve for Alpha
18:03:46 <jreznik> so if nobody objects, it's No-Go now
18:03:54 <brunowolff> ack
18:04:04 <adamw> yeah, i don't see any kinda hero effort here
18:04:13 <adamw> i thought we might actually be able to ship on time for a change, but hey.
18:04:44 <brunowolff> Plus it sounds like it isn't worth trying to do a short slip.
18:05:08 <jreznik> adamw: we would loose our reputation...
18:05:18 <gholms> Heh
18:05:18 <rbergeron> rackerhacker, inode0, nb, gholms -- we're in #fedora-meeting-2, fyi
18:05:30 <rackerhacker> ah
18:05:33 <jreznik> brunowolff: let's hope for a short one
18:05:42 <adamw> jreznik: i think he means <1 week
18:05:50 <adamw> i think ideal here is 1 week slip and fix all three big UEFI issues, if we can swing that
18:05:54 <jreznik> ah, ok
18:06:04 <adamw> pjon: mjg59: you guys know where we stand now, right?
18:06:08 <adamw> doh
18:06:10 <jreznik> adamw: yep, one week makes sense, especiall for mjg59's one
18:06:43 <jreznik> mjg59: any chance to get a fix even it would not be accepted for 100% by upstream? otherwise we are screwed
18:07:54 <mjg59> jreznik: No, this needs to be upstream acceptable
18:09:52 <jreznik> #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 <jreznik> pbrobinson: -> #fedora-meeting-2, sorry
18:10:22 <jreznik> (my scheduling...)
18:11:01 <jreznik> anything else?
18:11:10 <pbrobinson> jreznik: tut tut
18:11:48 <jreznik> #action jreznik to announce slip
18:12:57 <jreznik> if not, I'll end the meeting in a few minutes
18:12:59 * nirik nods. sad.
18:13:03 <jreznik> #topic Open floor
18:13:33 <adamw> think that's all, really, looks like the uefi stuff is the only stumbling block
18:14:30 <jreznik> 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 <jreznik> #info reminder - the Readiness meeting follows in this channel, 19:00 UTC
18:15:48 <Southern_Gentlem> jreznik, better slip now than later IMHO
18:15:59 <jreznik> Southern_Gentlem: yep, that's my thought
18:16:14 <brunowolff> 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 <Southern_Gentlem> the more gets fixed now no slips later
18:17:14 <jreznik> 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 <jreznik> in the worst case you would end up with dupes, not unbootable system...
18:17:55 <jreznik> not sure how crazy it is...
18:18:38 <jreznik> setting fuse now... 3...
18:18:49 <jreznik> thank you for coming!
18:20:13 <jreznik> 2...
18:21:21 <jreznik> 1...
18:23:17 <jreznik> #endmeeting