17:01:36 <tflink> #startmeeting f16-blocker-bug-5-and-a-half
17:01:36 <zodbot> Meeting started Tue Nov  1 17:01:36 2011 UTC.  The chair is tflink. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:01:36 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
17:01:59 <tflink> #meetingname f16-blocker-bug-5-and-a-half
17:01:59 <zodbot> The meeting name has been set to 'f16-blocker-bug-5-and-a-half'
17:02:00 <tflink> #topic roll call
17:02:15 <fenrus02> bug 5.5 ?  hows that work?
17:02:19 <tflink> Who's ready for some rather impromptu blocker review?
17:02:34 * cwickert is, although he is not a bugzapper officially
17:02:40 * red_alert 
17:02:45 * adamw raises a bottle
17:02:57 <tflink> fenrus02: it's a secret bug naming system
17:03:11 <fenrus02> heh
17:03:11 <tflink> #meetingname f16-blocker-bug-review-meeting-5-and-a-half
17:03:11 <zodbot> The meeting name has been set to 'f16-blocker-bug-review-meeting-5-and-a-half'
17:03:36 <tflink> cwickert, red_alert: welcome to the party!
17:03:48 <tflink> #chair adamw
17:03:48 <zodbot> Current chairs: adamw tflink
17:04:12 <dgilmore> hola compadres
17:04:29 <tflink> hrm, the wiki page doesn't show all the blocker bugs
17:04:46 <tflink> nvm, it just got updated
17:04:47 * nirik is lurkin
17:04:50 <jwb> we're only talking about one, right?
17:04:54 <tflink> I think the updating script runs on the hour
17:05:04 <tflink> 5 proposed blockers, 2 approved
17:05:15 <adamw> we'll go with the kernel one first
17:05:21 <tflink> k
17:05:41 <cwickert> how about we use https://bugzilla.redhat.com/showdependencytree.cgi?id=713568&hide_resolved=1 then
17:05:42 * tflink skips the usual formalities
17:05:54 <tflink> #link https://fedoraproject.org/wiki/Current_Release_Blockers
17:06:31 <tflink> starting w/ proposed blockers, kernel first
17:06:33 <tflink> #topic (748516) kernel does not boot with patch to fix invalid EFI remap calls from 2011-10-18
17:06:36 <tflink> #link http://bugzilla.redhat.com/show_bug.cgi?id=748516
17:06:39 <tflink> #info Proposed Blocker, ASSIGNED
17:06:56 * dgilmore thinks that using bios mode is an acceptable workaround
17:07:06 <adamw> so i think we can summarize the impact of this as: EFI boot will fail on an as-yet-unknown number of EFI-supporting systems
17:07:07 <dgilmore> i may be alone there
17:07:12 <drago01> is the "we don't support efi on macs" documented somewhere?
17:07:28 <tflink> drago01: https://fedoraproject.org/wiki/Fedora_16_Beta_Release_Criteria
17:07:36 <tflink> criterion 4
17:07:57 <adamw> it's a bit messy with the way we have the criteria written at present, but our intent is that we don't really support EFI booting on macs.
17:08:03 <adamw> however, we don't believe this bug would be limited to macs.
17:08:06 <tflink> it's not so much "we don't support efi on macs" as "we won't block release for EFI issues only on macs"
17:08:09 <fenrus02> is there some other popular efi hardware other than mac?
17:08:18 <drago01> yes
17:08:25 <jwb> it's becoming increasingly available
17:08:27 <notting> do we have verification that it blocks some non-macs?
17:08:39 <adamw> notting: no, but we have little efi info in general.
17:08:41 <notting> and have we always shipped with some EFI hardware not working?
17:08:47 <adamw> yes.
17:09:04 <fenrus02> notting, well, "always" is not the same.  efi was not really used anywhere other than mac before.
17:09:17 <adamw> mjg59 says "it'll happen on anything that has runtime services above the top of RAM"
17:09:31 <dgilmore> all the new thinkpads it seems have efi
17:09:35 <tflink> it's been on servers for a while now but I'm not sure how many people are runnning fedora on baremetal servers
17:09:36 <adamw> <airlied> mjg59: is that a common case outside of macs?
17:09:40 <dgilmore> as does a bunch of other boards
17:09:50 <drago01> pretty much all new boards have efi
17:09:56 <adamw> <mjg59> airlied: It's a completely valid configuration
17:09:57 <adamw> No clue how common. People still rarely do EFI installs with Fedora.
17:09:57 <adamw> <adamw> it doesn't affect my system, so hey, data point.
17:10:02 <fenrus02> so we need to start caring more about efi than ever before.
17:10:13 <dgilmore> fenrus02: yes
17:10:14 <adamw> do we need an EFI primer?
17:10:17 <jwb> we already are to a large degree
17:10:26 <jwb> but that is somewhat off topic...
17:10:28 * spot is here
17:10:30 <spot> EFI booting has never quite worked right on macs
17:10:32 <dgilmore> and considering windows 8 will only support efi, there will be a flood of efi enabled hardware
17:10:32 <spot> at least, not all macs
17:11:08 <adamw> let's do the quick one: EFI is a new system firmware format, essentially a replacement for BIOS. Just about all systems that ship with an EFI firmware implement a 'BIOS compatibility mode' which effectively looks like a regular BIOS to the operating system.
17:11:21 <adamw> you pick EFI or BIOS when you install, you can't install via EFI then boot via BIOS later - at least, AIUI.
17:12:30 <adamw> EFI is getting increasingly more traction but it's still quite a minority pursuit at this time. we're generally agreed we want to ensure it works but the _practical_ impact of it not working on some systems isn't likely to be huge at this point.
17:12:36 <fenrus02> common bugs post then?
17:12:42 <adamw> i'm just trying to give background...
17:12:57 <notting> for the new arrivals: https://bugzilla.redhat.com/show_bug.cgi?id=748516
17:13:18 <drago01> adamw: what about dual boot? lets say you have windows installed on efi ... can you just switch to bios mode without breaking windows?
17:13:19 <fenrus02> adamw, nod.  i've seen a lot of mac-hw users trying to install fedora and not having a good time of it.
17:13:56 <fenrus02> some random laptoys too, but i do not have the hw specs on any of them handy.
17:13:59 <adamw> drago01: i think it gets complex at that point.
17:14:11 <adamw> mjg59 would probably be able to answer the q better. =)
17:14:15 <notting> so, this broke in 3.1-rc10?
17:14:18 <adamw> yes
17:14:24 <cra> efi implies gpt from a standards point-of-view, and the hack to boot gpt via bios doesn't always work
17:14:25 <adamw> it's an upstream commit
17:14:29 <jwb> no
17:14:29 <fenrus02> is there a known fix for rc10?
17:14:33 <jwb> wait, no
17:14:41 <adamw> srry
17:14:42 <mjg59> There is a simple fix
17:14:44 <jwb> this was a patch added from an upstream EFI developer
17:14:48 <drago01> cra: windows ignores that and uses mbr anyway
17:14:51 <jwb> it's not in 3.1 at all
17:14:53 <mjg59> And we have no idea how large the impact of the bug is
17:15:04 <cra> i've read that windows requires gpt to boot from efi
17:15:06 <fenrus02> mjg59, simple enough for an end-user to implement ?
17:15:10 <mjg59> fenrus02: No
17:15:19 <jwb> fenrus02, how are they going to install it if it doesn't boot?
17:15:21 <mjg59> The fix is that we rebuild the kernel without the patch
17:15:27 <jwb> mjg59, which i've done
17:15:34 <mjg59> And then respin the install media
17:15:44 <notting> mjg59: what is the difference between w/o patch and w/new-posted-in-bz patch?
17:15:54 <adamw> if the bug is accepted as a blocker, then we do that.
17:15:57 <mjg59> notting: 32-bit EFI systems (which we don't support) work better
17:15:59 <adamw> if it isn't, then we don't do that.
17:16:01 <mjg59> adamw: That's the fix
17:16:01 <jwb> notting, 32-bit EFI might work with the patch
17:16:14 <mjg59> If you don't want to fix it, that's fine. But an unknown number of EFI systems, which we claim to support, won't work.
17:16:17 <notting> the patch is for 32-bit efi? ok, fine with dropping it
17:16:23 <adamw> mjg59: yes, indeed.
17:16:27 <dgilmore> jwb: we dont make the 32 bit media efi supported afaik
17:16:31 * drago01 has a hard time caring about 32bit efi
17:16:37 <adamw> wait
17:16:42 <adamw> signals getting crossed hre
17:16:42 <pjones> drago01: well, as Fedora, we don't care at all.
17:16:44 <jwb> yes.  all of which is why i already dropped the patch and rebuilt
17:16:44 <mjg59> We don't support 32 bit EFI
17:16:49 <drago01> pjones: good
17:16:51 <notting> mjg59: ASSumption: there are no 32-bit only EFI machiens?
17:16:51 <mjg59> Ignore 32 bit EFI
17:16:55 <adamw> the bug is not that 32-bit EFI is broken
17:16:57 <mjg59> notting: There are. We don't support them
17:17:04 <mjg59> The bug the patch *fixed* is that 32-bit EFI was broken
17:17:06 <adamw> the *broken patch* was for 32-bit EFI
17:17:19 <adamw> so if we revert it, theoretically, 32-bit EFI support gets worse. but fedora does not care about 32-bit EFI.
17:17:20 <pjones> notting: gateway and apple both produced some.  we've never seen the former, we support the latter in BIOS (bootcamp) only.
17:17:31 <drago01> adamw: yeah we get that ... just talking about the impact of dropping it
17:17:34 <adamw> k.
17:17:45 <spot> i don't suppose we can detect 32bit EFI systems and toss a happy note?
17:17:48 <mjg59> The impact in dropping it is that some machines we don't support break, and some machines we do support start working
17:17:49 <fenrus02> all the hw i've seen that has efi, also has 64bit.  just document that.
17:17:55 <adamw> let's forget about 32-bit EFI.
17:17:57 <mjg59> spot: We don't produce 32-bit EFI install media
17:18:09 <mjg59> That's a pretty significant indication that it's not supported
17:18:20 <spot> mjg59: understood, however, does the avg owner of a 32bit EFI box know that?
17:18:27 <mjg59> spot: They could never have installed
17:18:38 <spot> mjg59: could they have booted the installer?
17:18:40 <mjg59> No
17:18:44 <pjones> spot: no - but their system will quietly install as a BIOS machine.
17:18:45 <spot> okay then. dont care.
17:18:50 <adamw> spot: the 32-bit install images just don't have the EFI stuff on them.
17:18:55 <pjones> which is fine, and how it has been and should be.
17:19:21 <notting> so, yeah, i'd be +1 blocker, +1 to drop the patch and respin
17:19:23 <mjg59> The only significant issue here is whether we're fine with breaking an unknown number of 64-bit EFI systems
17:19:28 <adamw> so, again: fundamentally this bug is simply a judgment call: is breaking EFI boot on a certain unknown amount of machines a blocker bug?
17:19:35 <drago01> notting: +1
17:19:46 <mjg59> And sorry about this, I should have caught it upstream
17:19:50 * pjones would also be +1 blocker and +1 to drop and respin
17:19:52 <fenrus02> mjg59, but reverting the patch fixes the known quantity?
17:20:01 <red_alert> does smolt say something on the number of 64bit EFI systems?
17:20:13 <mjg59> fenrus02: The failure precisely matches the expected behaviour of the patch
17:20:15 <adamw> smolt data doesn't indicate EFI support, i don't believe.
17:20:20 <pjones> red_alert: smolt is, as usual, fairly useless in this regard.
17:20:25 <adamw> fenrus02: there's a confirmation in the bug that the fix works.
17:20:40 <mjg59> red_alert: It's not all 64 bit EFI systems. It's 64 bit EFI systems that have EFI services code above the top of RAM.
17:20:53 <mjg59> The failure is well understood. Dropping the patch will avoid it.
17:21:05 <adamw> we're going to have to live with the fact that we don't have any certain data on the amount of systems it affects.
17:21:09 <jwb> adamw, no
17:21:13 <adamw> what we have is about 8 data points.
17:21:22 <jwb> adamw, oh, well yes i suppose
17:21:24 <fenrus02> mjg59, when stated like that, it seems the risk of dropping the patch is nearly nil.
17:21:28 <mjg59> fenrus02: Yes
17:21:28 <adamw> cos that's how many systems we have EFI install tests on that aren't affected by other bugs.
17:21:45 <adamw> fenrus02: strictly, we should not consider such issues when deciding if a bug's a blocker
17:21:58 <adamw> if it's a blocker then *it's a blocker*: no matter how hard it is to fix, we just keep working until we fix it.
17:22:00 <drago01> adamw: this bug can even affect hardware that is yet to be produced
17:22:12 <fenrus02> adamw, we have no means of measuring the end-user impact, but we have a known working fix.
17:22:21 <adamw> drago01: yes, it can. it's more likely to than not, in fact. do bear in mind fedora releases' limited shelf lives, though.
17:22:23 <adamw> fenrus02: yes.
17:22:49 <fenrus02> adamw, what's the downside of rolling out the corrected version?  i'm not seeing one.
17:23:00 <notting> AIUI, the downside is "we slip"
17:23:11 <adamw> fenrus02: the downside is that we have to respin and re-test the entire release in the next 24 hours, and there is always a significant chance of something going wrong if we do that.
17:23:17 <adamw> notting: not for certain, but it's possible.
17:23:48 <adamw> fenrus02: In Theory reverting the patch itself is a perfectly safe operation, but it does entail a rebuild of our release images, which is a much bigger operation.
17:24:08 <fenrus02> adamw, *nod*  but seems highly beneficial in the long term.
17:24:16 <fenrus02> adamw, even if that means we slip
17:24:31 <adamw> okay
17:24:34 <fenrus02> perhaps i'm missing something critical.
17:24:40 <adamw> not at all
17:24:54 <adamw> just trying to make sure all the info is here, i'm not trying to influence you toward one vote or the other
17:24:57 <mjg59> Well, we can declare EFI unsupported, which means we have a severe functional regression compared to F15
17:25:05 <mjg59> Or we can block
17:25:09 <fenrus02> adamw, *nod*  much appreciated
17:25:22 <red_alert> so, any more _new_ arguments or can we vote and get on? :)
17:25:23 <dgilmore> i dont think anyone wants to say efi is unsupported
17:25:26 <mjg59> Now so far everyone who's expressed an opinion has said we should block
17:25:29 <adamw> mjg59: in practice, if we didn't fix this, we'd probably document it and put up a special boot image with a fixed kernel for affected people to use, i expect
17:25:31 <drago01> mjg59: no (yes we can) but that's not really worth it
17:25:46 <dgilmore> mjg59: i dont want to block on this.
17:25:52 <adamw> but yes, that would be worse than f15. (though it's not as if f15 worked on all efi systems.)
17:25:55 <dgilmore> i agree its not ideal
17:26:01 <dgilmore> and that it needs a fix
17:26:01 <adamw> i think we have all the info, anyway
17:26:16 <adamw> so we can probably just vote and see if we have enough of a consensus
17:26:18 <pjones> dgilmore: how's that not a +1 to block on it?
17:26:36 <dgilmore> pjones: im ok with saying if efi doesnt work for you sorry use bios mode
17:26:39 <drago01> dgilmore: you mean s/block/slip/ ?
17:26:45 <mjg59> dgilmore: No, that is really not acceptable
17:26:47 <gtirloni> adamw: how long could it take to have a special boot image for these guys?
17:26:55 <mjg59> dgilmore: We have explicitly said that EFI is supported
17:26:56 <rbergeron> cripes
17:27:20 <notting> gtirloni: if we're going to that effort, i'd prefer to do it right and just fix it in the main image
17:27:26 <adamw> gtirloni: bout an hour
17:27:26 <drago01> dgilmore: no, and having people messing with efi vs bios mode just makes usability worse for the worst case of a one week slip
17:27:31 <dgilmore> drago01: yeah
17:27:35 <mjg59> dgilmore: It's also impossible to migrate from EFI to BIOS boot
17:27:55 <mjg59> dgilmore: So anyone who upgrades from DVD will be left utterly screwed
17:28:36 <adamw> yeah, that is a point, if you installed f15 EFI then upgraded you'd be in stew.
17:29:04 <adamw> okay
17:29:07 <adamw> can we please get votes?
17:29:12 <drago01> adamw: that and the dual boot thing
17:29:16 <pjones> dgilmore: also there is some (albeit small) chance that some hardware vendor will ship a non-BIOS-booting machine in the F16 timeframe.
17:29:23 <adamw> anyone who's here is allowed to vote, the votes are tabulated by the highly scientific method of 'hey, looks like we have a consensus'
17:29:28 <adamw> please vote +1 blocker or -1 blocker
17:29:35 <red_alert> +1 blocker
17:29:36 <mjg59> +1 blocker
17:29:37 <gtirloni> +1 blocker
17:29:40 <fenrus02> +1 blocker
17:29:41 <cwickert> +1 blocker
17:29:41 <drago01> + blocker
17:29:42 <nirik> +1blocker ;(
17:29:44 <drago01> 1
17:29:48 <tflink> sounds like consensus to me
17:29:48 <nokia3510> +1 blocker
17:29:50 <notting> +1 blocker
17:29:51 <pjones> +1 blocker
17:29:53 <spot> +1
17:30:05 * rbergeron is +1 as well
17:30:33 <adamw> dgilmore is -1, i believe
17:30:34 <red_alert> now that's a lot of votes and very clear :)
17:30:36 <tflink> proposed #agreed - 748516 - AcceptedBlocker - Violates the beta release criterion "The installer must boot and run on systems using EFI other than Apple Macs"
17:30:42 <adamw> so, yeah, that seems clear enough.
17:30:50 <tflink> ack/nak/patch?
17:30:50 <adamw> ack
17:30:58 <rbergeron> ack
17:31:04 <red_alert> ack
17:31:05 <tflink> #agreed - 748516 - AcceptedBlocker - Violates the beta release criterion "The installer must boot and run on systems using EFI other than Apple Macs"
17:31:29 <adamw> alright
17:31:33 <adamw> we have a few other proposed blockers too i think?
17:31:38 <tflink> yep, 4 more
17:31:41 <tflink> #topic (748272) The UEFI installation fails to install bootloader
17:31:41 <tflink> #link http://bugzilla.redhat.com/show_bug.cgi?id=748272
17:31:41 <tflink> #info Proposed Blocker, NEW
17:31:51 <adamw> this one's been around for a bit
17:31:56 <adamw> i've been trying to shepherd it
17:31:59 <adamw> frankly the reporter is a bit of a pita
17:32:47 <pjones> I'm not completely convinced there's an actual bug here.
17:32:57 <pjones> and if there is, I'm not convinced it's not in his firmware, tbh.
17:33:12 <adamw> yeah, me either. it's very difficult to get a handle on what the hell he's actually trying to tell us, in between all his attempts to use different images in different ways and stuff.
17:33:45 <adamw> so i'm fine just rejecting this one atm for unclear impact and inability of anyone else to reproduce exactly what he's complaining about; i'm pretty sure none of the other efi bugs we've seen have exactly been whatever the hell he's doing wrong.
17:33:54 <pjones> anyway, this appears to work for other people and on my test machines, so...
17:34:00 <cwickert> +1
17:34:10 * pjones wonders what cwickert is +1'ing.
17:34:20 <adamw> us?
17:34:23 <cwickert> +1 for adamw's suggestion to reject it
17:34:26 <pjones> okay
17:34:28 <tflink> yeah, I'm thinking the same
17:34:31 <adamw> so, -1 blocker
17:34:31 <pjones> I can totally get behind that.
17:34:32 <fenrus02> i would have said -1 blocker
17:34:40 <rbergeron> -1 blocker
17:34:45 <nokia3510> -1
17:34:51 <cwickert> -1 blocker (to make it more clear)
17:34:55 <drago01> -1
17:34:58 <red_alert> -1 blocker
17:35:25 <tflink> proposed #agreed - 748272 - RejectedBlocker - It isn't clear that there is a bug here and nobody other than the reporter has been able to reproduce the issue
17:35:30 <tflink> ack/nak/patch?
17:35:44 <dgilmore> -1 blocker
17:35:55 <rbergeron> ack
17:36:10 <adamw> ack
17:36:12 <red_alert> ack
17:36:19 <tflink> #agreed - 748272 - RejectedBlocker - It isn't clear that there is a bug here and nobody other than the reporter has been able to reproduce the issue
17:36:24 <tflink> #topic (750469) Fedora missing in Grub Legacy after F15->F16 DVD upgrade with Grub 2 option
17:36:28 <tflink> #link http://bugzilla.redhat.com/show_bug.cgi?id=750469
17:36:30 <tflink> #info Proposed Blocker, NEW
17:36:51 * red_alert is the culprit here :/
17:37:10 <adamw> yeah, we really can't evaluate this yet
17:37:16 <adamw> i can try to reproduce though, i guess
17:37:27 <drago01> what is the "grub2 option" ?
17:37:35 <red_alert> I reproduced it twice so far on the same hardware
17:38:02 <drago01> red_alert: does not look like anything hardware specific
17:38:02 <red_alert> drago01: when you upgrade, you can choose to stay with your existing boot loader or install a new one...I thought of the latter as "grub 2 option"
17:38:09 <tflink> red_alert: do you know if you were booting the f16 kernel or not?
17:38:16 <drago01> red_alert: ah ok
17:38:31 <pjones> tflink: I can't imagine that would make any difference
17:38:33 <adamw> what it _does_ is just try to re-do the bootloader config from scratch, much like would happen on a fresh install
17:38:54 <adamw> anyway, i'm cloning my windows-with-some-free-space vm right now, will test this.
17:38:59 <red_alert> tflink: sorry? there's no boot options for Fedora available
17:39:02 <adamw> i think we can punt on it till we have a bit more data
17:39:06 <tflink> pjones: I'm just remembering the preupgrade issues where the system ended up using the F15 grub installation and F15 kernel
17:39:24 <tflink> nvm, I'm misreading
17:39:53 <adamw> note, however, that the upgrade criterion is quite narrow
17:40:08 <adamw> "The installer must be able to successfully complete an upgrade installation from a clean, fully updated default installation (from any official install medium) of the previous stable Fedora release, either via preupgrade or by booting to the installer manually. The upgraded system must meet all release criteria "
17:40:26 <adamw> intentionally so, as we acknowledge that, well, upgrading is hard. and usually _is_ going to break in some cases.
17:40:32 <drago01> adamw: which is clear enough
17:40:43 <j_dulaney> This really doesn't fit, then
17:40:53 <drago01> adamw: no it shouldn't break
17:40:53 <adamw> an upgrade performed strictly by the book does work, we have multiple tests of that
17:40:56 <red_alert> adamw: I didn't have the latest updates, so I can't say we block this right now
17:41:32 <drago01> red_alert: don't see how this matters
17:41:32 <tflink> so it sounds like punt or reject
17:41:47 <adamw> drago01: it's a classic too-many-variables problem. upgrades can be broken by just about anything in the source system or the target system, and there's what, 10,000 packages in fedora?
17:42:03 <red_alert> only ~900 in a live isntall ;)
17:42:08 <dgilmore> adamw: ~18000 binaries
17:42:16 <drago01> adamw: well the result should not be an unbootable system
17:42:20 <adamw> i'm probably punt on this for now
17:42:23 <drago01> adamw: that's just not acceptable
17:42:25 <adamw> drago01: yeah, that does suck.
17:42:26 <cwickert> but only two boot managers and one package that touches it's config
17:42:53 <adamw> cwickert: and yet this bug happened to red_alert, yet doesn't happen if you just build a vm, install f15 into it, update f15, then upgrade
17:42:53 <red_alert> if we punt, I'll try to make a couple of additional tests (including whatever adamw calls 'by the book') tomorrow (CEST)
17:42:58 <drago01> I'd say retest and just drop the "grub 2 option"
17:43:02 <adamw> cwickert: i can tell you that for damn sure cos i've done it about 10 times
17:43:06 <drago01> so upgrades stick to grub for now
17:43:10 <adamw> drago01: no.
17:43:11 <drago01> until we fix it (f17)
17:43:17 <tflink> proposed #agreed - 750469 - We need more information and re-testing with a fully updated install before making a decision on blocker status
17:43:18 <cwickert> adamw: and you did upgrade to grub2?
17:43:21 <adamw> cwickert: yes.
17:43:22 <tflink> ack/nak/patch?
17:43:24 <cwickert> alright
17:43:26 <adamw> cwickert: that's the supported and default option
17:43:45 <red_alert> to clarify: I hit the exact same with both options, grub1 and grub2
17:43:46 <adamw> cwickert: 'skip bootloader configuration' is not a good choice, really. it's meant to be used if you have a third party bootloader and want anaconda not to touch anything.
17:43:58 <adamw> it's not actually expected to result in a bootable system if you're _not_ using some kind of other bootloader.
17:44:10 <drago01> adamw: isn't the bug about that option breaking?
17:44:28 <adamw> drago01: yes. but dropping the grub2 migration is not a viable fix.
17:44:49 <drago01> adamw: ah ok
17:44:50 <cwickert> adamw: agreed.
17:44:53 <pjones> drago01: oh good lord, no, we're not supporting grub1 on bios installs in f16.
17:45:00 <rbergeron> tflink: ack
17:45:06 <adamw> tflink: ack
17:45:15 <tflink> #agreed - 750469 - We need more information and re-testing with a fully updated install before making a decision on blocker status
17:45:22 <drago01> pjones: the whole grub1 and grub2 at the same time is a mess really
17:45:22 <tflink> #topic (746693) Can't login via gdm when `metacity` pkg is not installed
17:45:26 <tflink> #link http://bugzilla.redhat.com/show_bug.cgi?id=746693
17:45:28 <tflink> #info Proposed Blocker, NEW
17:45:34 <cwickert> adamw: have you tested both installing the boot loaded to mbr and to the first sectors of the /boot partition?
17:45:37 <pjones> drago01: then why are you suggesting we do it?
17:45:44 <adamw> cwickert: not on upgrade, no
17:45:52 <drago01> pjones: because we have it anyway
17:45:57 <pjones> o_O
17:46:14 <drago01> pjones: I'd suggest dropping grub1 at all but we are one week before release
17:46:14 <adamw> man, this is an annoying bug.
17:46:15 <cwickert> adamw: I think both locations should be supported, I will test it later
17:46:22 <adamw> i should just have stuck the damn dependency in myself last week.
17:46:47 <adamw> cwickert: breakage in first sector wouldn't result in an unbootable system, though, of course.
17:47:17 <adamw> i'm -1 blocker +1 nth on this, we should fix it since we're doing an rc4 anyway
17:47:23 <adamw> impact is that xfce is broken, basically.
17:47:36 <rbergeron> do we have a fix?
17:47:43 <cwickert> adamw: well, I fixed it in the kickstart
17:47:48 <tflink> yeah, I'm the same. I was just looking through the criteria to see if I was missing something
17:47:54 <cwickert> but the proper fix would be in gdm
17:47:55 <tflink> -1 blocker, +1 NTH
17:48:15 <nirik> the ks fix only will help the live media...
17:48:15 * fenrus02 still thinks we should just fix the Requires: in gdm
17:48:15 <cwickert> people using the DVD and doing a yum groupinstall will hit that bug
17:48:20 <nirik> not yum groupinstall or dvd...
17:48:29 <cwickert> we could change comps if we respin anyway
17:48:47 <cwickert> but I would rather prefer a fix in gdm
17:49:08 <tflink> proposed #agreed - 746693 - RejectedBlocker AcceptedNTH - hits the alpha release criterion "Following on from the previous criterion, after firstboot is completed and on subsequent boots, a system installed according to any of the above criteria (or the appropriate Beta or Final criteria, when applying this criterion to those releases) must boot to a working graphical environment without unintended user intervention. This includes correctly accessin
17:49:10 <cwickert> long story short: -1 blocker, +1 NTH
17:49:16 <adamw> we can decide on the best fix lately
17:49:16 <tflink> ack/nak/patch?
17:49:31 <adamw> at this late point i am highly predisposed to changes which only affect comps/ks rather than rebuilding packages, but meh
17:49:32 <adamw> ack
17:49:35 <dgilmore> cwickert: changing comps makes for alot of extra work for me. so id rather not change comps unless we really have to
17:49:47 <cwickert> alright dgilmore
17:49:57 <fenrus02> adamw, change gdm requires in -updates then?
17:49:59 <nirik> changing gdm means retesting, but then we should anyhow?
17:50:12 <red_alert> did that proposal only got cut off at the end for me? :)
17:50:21 <adamw> it's a long criterion...
17:50:23 <fenrus02> red_alert, not just you
17:50:24 <adamw> i know how it ends, though. =)
17:50:29 <cwickert> :)
17:50:33 <rbergeron> tflink: can you hit the end of that for those of us playing along at home
17:50:40 <rbergeron> :)
17:50:43 <tflink> where did it get cut off?
17:50:46 <adamw> rbergeron: teh end of the criterion is irrelevant to the bug
17:50:54 <adamw> it ends with 'accessing encrypted partitions'
17:51:05 <red_alert> -1 blocker, +1 NTH, ack (if the proposal ends with the full criterion)
17:51:15 <tflink> when the correct passphrase is supplied" for the XFCE spin
17:51:22 <tflink> is the last part
17:51:42 <red_alert> tflink: so far ends with "correctly accessin" ;)
17:52:00 <tflink> sigh
17:52:46 <tflink> proposed #agreed - 746693 - RejectedBlocker AcceptedNTH - hits the alpha release criterion "Following on from the previous criterion, after firstboot is completed and on subsequent boots, a system installed according to any of the above criteria (or the appropriate Beta or Final criteria
17:53:01 <tflink> when applying this criterion to those releases) must boot to a working graphical environment without unintended user intervention. This includes correctly accessing any encrypted partitions when the correct passphrase is supplied" for the XFCE spin
17:54:04 <tflink> #agreed - 746693 - RejectedBlocker AcceptedNTH - hits the alpha release criterion "Following on from the previous criterion, after firstboot is completed and on subsequent boots, a system installed according to any of the above criteria (or the appropriate Beta or Final criteria, when applying this criterion to those releases) must boot to a working graphical environment without unintended user intervention. This includes correctly accessing any enc
17:54:17 <tflink> #topic (702659) xcb_io.c:221: poll_for_event: Assertion `(((long) (event_sequence) - (long) (dpy->request)) <= 0) failed
17:54:20 <tflink> #link http://bugzilla.redhat.com/show_bug.cgi?id=702659
17:54:22 <tflink> #info Proposed Blocker, ASSIGNED
17:54:55 <tflink> I'm not so sure about blocker on this one
17:55:27 <red_alert> workaround: don't press cancel on that dialog
17:55:37 <red_alert> that's an easy one everyone can do ;)
17:55:51 <tflink> true, but it's really easy to hit
17:55:59 <fenrus02> sounds like an easy workaround
17:56:09 <fenrus02> change vc's create your user, restart gdm
17:56:13 <tflink> does firstboot run again if it does crash?
17:56:21 <gtirloni> does it block forever if it can't find the ntp servers?
17:56:35 <red_alert> tflink: should run on next reboot IIRC
17:56:36 <gtirloni> (meaning the user *has* to press cancel)
17:57:01 <fenrus02> gtirloni, should timout in ~90s or thereabouts.  have you tried it?
17:57:12 <tflink> if firstboot runs again on next boot, I think I'd be OK with NTH
17:57:16 <adamw> not sure anyone would wait for the timeout vs. just hitting cancel, though
17:57:18 <adamw> tflink: +1
17:57:37 <adamw> well, let me revise that
17:57:42 <gtirloni> fenrus02: not yet, i'll start a vm here.
17:57:43 <adamw> i am not keen to take a gtk2 change that's not a blocker fix
17:57:44 <tflink> but the other remaining question is whether or not we see the same behavior on 64 and 32 bit systems
17:57:52 <rbergeron> yeah, a lot of people are impatient
17:57:53 <notting> i would be -1 blocker, just because it's an error path, not a normal path, and no fix in hand
17:58:34 <adamw> if you definitely get firstboot again when you restart that makes me rather less worried
17:58:35 <tflink> ok, so this would be worst on 32 bit systems
17:58:45 <red_alert> servers that don't exist will be detected even before you get to activate NTP, won't they? I think there's a nslookup first
17:58:49 <tflink> on 64 bit, you end up at gdm
17:59:09 <tflink> its only on 32 bit that you end up @ gdm with no non-root user
17:59:19 <adamw> and then you can just reboot and you should get to try again.
17:59:30 <dgilmore> document it then
17:59:32 <dgilmore> and move on
17:59:44 <adamw> hey, and we wonder why we get called unpolished...
17:59:52 <tflink> votes? it sounds like -1 blocker for the most part
18:00:07 <fenrus02> -1 blocker
18:00:15 <tflink> and +1 nth for non-gtk fixes
18:00:16 <dgilmore> adamw: i guess its just where we put the line in the polishing sand
18:00:16 <cwickert> -1 blocker, +1 NTH
18:00:33 <adamw> -1 nth
18:00:36 <red_alert> -1 blocker, -1 NTH
18:00:37 <adamw> if the fix is in gtk
18:01:15 <cwickert> yes, if it's really GTK, then -1 NTH, too
18:01:40 <tflink> proposed #agreed - 702659 - RejectedBlocker AcceptedNTH - This is a polish issue that isn't difficult to hit. Note that the NTH status ONLY applies to fixes that DO NOT involve new gtk builds.
18:02:02 <tflink> ack/nak/patch?
18:02:22 <adamw> nak
18:02:26 <dgilmore> ack
18:02:30 <adamw> i'd want to go the safe way
18:02:38 <adamw> rejectednth, re-propose if someoen comes up with a non-gtk2 fix
18:02:44 <tflink> works for me
18:02:44 <red_alert> if it's not gtk, is it likely to be firstboot?
18:03:09 <adamw> red_alert: which is also pretty key, so yeah, i'm feeling rejecty.
18:03:19 * adamw gets out the Big Pink NO stamp[
18:03:23 <dgilmore> adamw: if its nth im free to not include it
18:03:26 <tflink> proposed #agreed - 702659 - RejectedBlocker - This is a polish issue that isn't difficult to hit but isn't a blocker. If there is a non-gtk fix for this, please re-propose as NTH.
18:03:32 <red_alert> right, I stick with -1 / -1 without any "if"s ;)
18:04:05 <adamw> dgilmore: just tryin' to avoid any unfortunate accidents
18:04:11 <adamw> ack
18:04:28 <dgilmore> adamw: sure
18:04:29 <red_alert> ack
18:04:52 <tflink> #agreed - 702659 - RejectedBlocker - This is a polish issue that isn't difficult to hit but isn't a blocker. If there is a non-gtk fix for this, please re-propose as NTH.
18:05:08 * rbergeron nods
18:05:35 <tflink> crap, it sounds like we're going ot have a new proposed blocker in a few minutes
18:05:39 <rbergeron> NOOOOOOO
18:05:57 <tflink> but that's it for the proposed blockers at the moment
18:06:05 <tflink> lets hit the accepted blockers
18:06:06 <adamw> tflink: your dracut one?
18:06:13 <tflink> yep
18:06:19 * adamw prepares the stamp
18:06:30 <fenrus02> what's the bugid for reference?
18:06:33 * rbergeron provides the blood-red ink
18:06:36 <rbergeron> from my /wrists
18:06:42 <tflink> I'm also skipping 743135 for the moment since that'll be related
18:06:46 <tflink> fenrus02: not filed yet
18:06:52 <fenrus02> tflink, ah, ok
18:06:57 <tflink> #topic (750228) F16 RC2 efidisk.img doesn't boot on ThinkPad T520, older one works
18:07:01 <tflink> #link http://bugzilla.redhat.com/show_bug.cgi?id=750228
18:07:03 <tflink> #info Accepted Blocker, NEW
18:07:34 <adamw> ahh, the lottery bug
18:07:38 <cra> rc3 efidisk.img works, but do we know that it won't break when rc4 is built?
18:07:39 <adamw> this is a fun one!
18:07:43 <adamw> cra: hell, no.
18:07:48 <rbergeron> red or black?
18:07:52 <adamw> based on the pattern so far, rc4 should break and rc5 should work. ;)
18:07:59 <adamw> rbergeron: yeah.
18:08:04 <dgilmore> cra: so i think i can reprodcue good ones
18:08:08 <adamw> efidisk.img generation sometimes fails and results in an image full of zeroes.
18:08:08 <notting> our build process is no consistent?
18:08:10 <adamw> sometimes it works.
18:08:14 <adamw> notting: hahahahaahaha.
18:08:16 <adamw> ahahahaa.
18:08:16 <cra> copy from rc3 to later compose?
18:08:17 <adamw> ahahahahahahaha.
18:08:28 <dgilmore> notting: it seems to only show up when i compose x86_64 by itself
18:08:34 <adamw> cra: that's not going to be ideal, given that the point of rc4 is to fix an efi blocker
18:08:46 <dgilmore> notting: when i compose i686 and x86_64 at the same time on the box  they are ok
18:08:49 <adamw> so we presumably want efidisk.img to have the fix
18:09:00 <pjones> yes.
18:09:05 <adamw> notting: this is fedora. _nothing_ is consistent. i'm only moderately sure what day of the week it is.
18:09:22 <cra> reproducibility is an illusion
18:09:25 <red_alert> adamw: that's a clear sign you've been sleeping too much lately ;)
18:09:28 <adamw> =)
18:09:32 <dgilmore> im fairly confident i can make a good one
18:09:35 <adamw> okay
18:09:42 <adamw> so, we leave this one to dgilmore's good offices
18:09:43 <tflink> either way, nothing to do from our end
18:10:04 <red_alert> we'll just make dgilmore roll new RCs until we have a valid one and only then start to test again?
18:10:19 <tflink> #agreed - 750228 - Progress is being made, future issues with efidisk.img will be dealt with if they happen
18:10:29 * rbergeron nods
18:10:40 <adamw> red_alert: we can do all the other images and then keep trying efidisk.imgs until one works, if worst comes to worst, i guess.
18:10:58 <red_alert> adamw: ah, if it;s done seperately, of course
18:11:12 <adamw> not usually, but it _can_ be.
18:11:32 <red_alert> okay
18:11:33 <tflink> still waiting on the dracut bug but I think that we can get part of this out of the way with the existing lorax bug
18:11:44 <tflink> #topic (743135) The installer no longer has access to files in the initrd
18:11:47 <tflink> #link http://bugzilla.redhat.com/show_bug.cgi?id=743135
18:11:50 <tflink> #info Accepted Blocker, ASSIGNED
18:12:06 <red_alert> anyone eager to point out quickly what lorax is?
18:12:11 <adamw> it builds installer images.
18:12:18 <adamw> not super important to understanding the bug
18:12:18 <red_alert> okay, thanks
18:12:19 <tflink> lorax builds the initramfs used in the installer
18:12:36 <cra> and efidisk.img
18:13:00 <tflink> adamw's description is probably more accurate
18:13:00 <adamw> so basically the bug means you can't deliver a kickstart or updates.img to the installer by stuffing it into the installer initramfs
18:13:09 <adamw> oh hell no, i'm just guessing.
18:13:18 <adamw> Description :
18:13:19 <adamw> Lorax is a tool for creating the anaconda install images.
18:13:23 <adamw> hey, i win the coconut.
18:13:37 <tflink> it does most of the images, anyways
18:13:47 <pjones> so anyway, it's something of a fringe feature, but one we've supported for a long time.
18:13:59 <tflink> I think that it's used by virt-installer too
18:14:25 <tflink> ah, an option of virt-install
18:14:48 <adamw> currently, we have a criterion requiring all possible kickstart deployment methods to work.
18:14:51 <adamw> so strictly it's a blocker.
18:15:04 <adamw> i do find it really hard to care about this, but hey, someone probably has a reason to deploy their kickstarts this way.
18:15:20 <tflink> but I think this will come down to a discussion of whether or not we want to block on this issue
18:15:34 <adamw> yeah, it's certainly an arguable position that we shouldn't block on all ks delivery methods.
18:15:36 <tflink> the actual bug is in dracut, a bug is currently being filed but no bzid yet
18:15:57 <red_alert> it already seems to be an AcceptedBlocker so we should only change this if something changed in the meanwhile...did it?
18:16:01 <adamw> if we know what the fix is we should probably just damn fix it, it's freaking impossible to get hold of harald on anything approaching reasonable notice
18:16:14 <adamw> red_alert: we could decide to change the criterion
18:16:44 <adamw> bearing in mind that we need a fix for this within, like, the next few hours if we're not going to slip the release
18:16:50 <adamw> at least for the other accepted blockers so far _we have fixes_
18:17:04 <tflink> according to bcl, the bug was introduced by fedpkg commit cfb1dbbaea0ce6fc47f7904db0dad84a40bbc1c2
18:17:19 <red_alert> making blockers go away just for the sake of it sorta sucks :/
18:17:40 <adamw> red_alert: not really just for the sake of it, i've been leery about the criterion since beta
18:17:51 <adamw> red_alert: note the comment on the bug that it's an accepted blocker 'for now' but we might change the criterion
18:18:32 <adamw> i do worry that there's some kind of actually-sensible use case for this that i didn't think of, though. did someone mention cloud deployments or some such thing?
18:18:50 <tflink> related bug: https://bugzilla.redhat.com/show_bug.cgi?id=750603
18:19:11 <tflink> there is an inject option to virt-install
18:19:37 <rbergeron> bcl :)
18:19:45 * bcl waves hello
18:19:59 <adamw> the commit which broke this was to fix a more important issue
18:20:01 <adamw> (failure to boot)
18:20:03 <tflink> bcl: I assume that you know more about the virt-install use case that's affected by the dracut issue?
18:20:06 <adamw> so i'm not sure we could just revert i
18:20:07 <adamw> t
18:20:42 <red_alert> I certainly don't see all the use cases for this but looks like the criterion matches very well and should stay. Depending on the impact I'd either vote +1 blocker or +1 NTH
18:20:46 <bcl> tflink: yeah, virt-install uses the 'append to initrd' in order to inject kickstarts
18:21:11 <tflink> is that the default or do you have to specify special options?
18:21:31 <bcl> And I depend on that for my new livemedia project. Otherwise I'll have to fire up a local web server to get kickstarts into the install
18:21:55 <adamw> bcl: do you reckon you can fix the dracut bug?
18:22:16 <bcl> well, virt-install has tons of options :) if you want to use a kickstart you can: inject it into initrd, serve it from http or make a new iso with it
18:22:42 * adamw votes for #2!
18:23:00 <bcl> adamw: I'm not sure if I can fix it or not.
18:23:06 <adamw> sigh. we can take this, i guess. but then my slip estimation goes up to about 90% if we're waiting for harald to fix it, cos it's similar to waiting for godot.
18:23:20 <bcl> I *do* have a good reproducer, running it on a f16 virt and looking at the generated initramfs
18:23:32 <rbergeron> adamw: what was the cloud bit you mentioned?
18:23:40 <adamw> rbergeron: i don't really remember
18:23:50 * rbergeron is jsut curious if it might be something that would break ec2 somehow, just poking around
18:23:53 <adamw> was just trying to think of cases where you can't serve a kickstart off a web/nfs server like any normal damn person would
18:23:55 <tflink> I think that he was referring to the virt-install part
18:24:01 <dgilmore> rbergeron: id say not ec2
18:24:07 <adamw> tflink: i think it was something else, but i can't recall details
18:24:32 <bcl> adamw: in my specific case, I automate things for individual .iso builds so firing up a web server is a big deal.
18:24:36 <dgilmore> rbergeron: but youcould use it to do automated installs into a cloud rather than have prebuilt images
18:24:58 <bcl> It would also hit PXE users who have an initramfs with kickstart added.
18:25:25 <tflink> wouldn't it be easier to use something like boxgrinder or oz for the cloud use cases?
18:25:46 <red_alert> I'm rather sure most PXE users can serve the ks by other means and normally also do so
18:25:46 <adamw> oh, pxe, i think that's the case i was trying to remember.
18:25:59 <tflink> bcl: true but I imagine that most PXE users would have access to some http server
18:26:19 <bcl> red_alert: probably so. but this is something that *has* worked and it is broken for no good reason.
18:26:28 <tflink> the first use case that comes to mind with PXE is pxeboot + http mirror
18:26:39 <tflink> if you're installing on boot, anyways
18:26:41 <bcl> I'm also not sure what other use cases dracut --include hit, which is really the core issue.
18:27:14 <adamw> spot: rbergeron: so is there any vague chance of persuading harald to deign to bless us with an appearance?
18:29:05 <tflink> I'm assuming not so much
18:29:47 <rbergeron> ughhh.
18:30:07 <tflink> I think that the big issue is time. Do we want to modify the release criteria to exclude this ks delivery method or do we risk slipping?
18:30:46 <adamw> i've been more or less in favour of dropping the exotic ks methods for a bit, but just afraid that i'm missing real-world use cases of the kind that people don't tell you about until you take them away
18:31:08 <rbergeron> I doubt he's available right this second. We might be able to tag him tonight, possibly
18:31:21 <rbergeron> I can send one of "those mails" though
18:31:58 <adamw> yeah, tonight is slip.
18:32:47 <red_alert> modifying release criteria to get the release out is really defying the purpose, though :/ even if it's a sane change, it feels like a very wrong move
18:33:03 <rbergeron> spot: ping
18:33:13 <adamw> red_alert: well, it's not just to get the release out. i'm more or less of the opinion this just isn't important enough to block for and the criteria are wrong.
18:33:26 <adamw> red_alert: i've stuck my neck out for releases often enough in the past, but this just really does not feel like a major issue to me
18:33:28 <red_alert> well, it's 7:30 PM in harald's place...so he might well be out for the next 12h or so
18:33:53 <rbergeron> red_alert: yeah
18:34:11 <adamw> yeah, god forbid anyone else should have to freaking check their mail occasionally in an evening when it's release time or anything.
18:34:13 <rbergeron> adamw: I can probably get spot to go talk to his boss's boss's boss
18:34:18 <rbergeron> adamw: or while they're at linuxcon!
18:34:31 <spot> uhoh
18:34:59 <spot> who is harald's boss?
18:35:00 <rbergeron> spot: are you within buttering distance of denise? :)
18:35:02 <rbergeron> phil knirsch
18:35:13 <spot> rbergeron: indeed i am
18:35:19 * nokia3510 thinks an email could be dispatched, and hopefully he (HH) might check his mobile once in a while
18:35:24 <rbergeron> oh
18:35:26 <rbergeron> wait.
18:35:30 <rbergeron> we have harald's gmail address, don't we
18:35:47 <red_alert> gmail, G!, twitter, facebook, ... ;)
18:35:53 <adamw> really, we just need someone who can fix it. doesn't have to be harald.
18:35:57 <adamw> but seems like he'd be the best shot.
18:36:02 <spot> bz?
18:36:14 <tflink> spot: https://bugzilla.redhat.com/show_bug.cgi?id=750603
18:36:52 <spot> if no one fixes this, do we slip?
18:36:54 <adamw> spot: if we declare it a blocker, yes.
18:36:57 <adamw> we still didn't decide that.
18:37:11 <adamw> i'm a weak -1, red_alert seems and bcl seem to be weak +1s, i dunno.
18:37:24 <tflink> either way, I'm thinking that 743135 can be closed
18:37:36 <tflink> which is the lorax related bug
18:37:39 <dgilmore> adamw: im kinda a 0
18:37:49 <rbergeron> spot or adamw: can you think of anyone stateside who might be an option
18:37:50 <red_alert> -1 blocker, +1 NTH - I think the criterion is valid and should stay as-is but it's enough of a corner case not to risk a slip
18:38:41 <bcl> I'm a strong +1
18:39:03 <bcl> my livemedia project (via virt-install) depends on this working. That's why I fixed it in the first place.
18:39:36 <adamw> rbergeron: well, bcl.
18:39:42 <adamw> tflink: okay, go ahead and close it.
18:40:03 <adamw> and anyone else who cares to look at http://fpaste.org/p8Xw/ and figure out what he broke.
18:40:29 <tflink> #agreed - 743135 - This can be closed again because it is not the root cause. The issue fixed in this bug is still fixed
18:40:52 <tflink> I'm pretty much on the fence on the dracut issue, though
18:41:14 <tflink> #topic (750603) dracut --install isn't copying script to the target
18:41:16 <adamw> bcl: well, i'm not that concerned about your personal issue, frankly; you're smart enough to work around it. question is, how many other people might be doing something like that? hard one to answer, i guess.
18:41:21 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=750603
18:41:26 <bcl> adamw: understood.
18:41:33 <tflink> #info Proposed Blocker, NEW
18:42:06 <bcl> I'm just a bit peeved at things that *worked* then getting *broken*
18:42:08 <adamw> and, as you pointed out, does the dracut breakage break anything else we didn't think of.
18:42:14 <adamw> bcl: oh, sure.
18:42:30 <bcl> granted, the dracut issue can be fixed post-release. but that doesn't help the installer.
18:42:55 <adamw> would fixing it with an update fix the virt-install case or no?
18:43:11 <tflink> not without building a new image, I don't think
18:43:51 <tflink> since it's the initial boot of the installer's initrd that's the problem
18:43:54 <fenrus02> virt-install items can be resolved in -updates though, no?
18:44:08 <tflink> but the problem isn't with virt-install iteslf
18:44:14 <tflink> virt-install does things properly
18:44:36 <tflink> but dracut isn't constructing the initrd correctly and the appended ks doesn't make it into the installers fs post-boot
18:44:38 <bcl> adamw: no, although maybe it could be fixed with another overlay, but I'm unsure.
18:44:44 <fenrus02> tflink, right, just saying that anything revolving around virt-install can be non-blocking and fixed in -updates.  unless it also affects discrete installs
18:45:07 <tflink> fenrus02: it can if you install with ks files appended to the initramfs
18:45:07 <adamw> apparently not...
18:45:30 <tflink> this can't really be fixed with updates in the usual way
18:45:46 <tflink> unless you spin up new installer images to use after the update is released
18:46:14 <tflink> virt-installer usually uses released initrds for installation
18:47:03 <tflink> so you could fix this with updates in the same way that you could fix an EFI issue by spinning up a new installer image post-release
18:47:13 <adamw> i guess we should stop wasting time talking about it and start wasting time trying to fix it
18:47:21 <tflink> yeah,
18:47:21 <adamw> we have the -15 to -16 diff, we have a reproducer...
18:47:29 <tflink> thoughts on blocker or not?
18:47:40 <tflink> or do we wait for an hour or two and see what happens
18:47:43 <adamw> if we fix it, +1 ;)
18:47:52 <red_alert> still: -1 blocker, +1 NTH
18:48:22 <tflink> how about this: we accept as blocker and continue the ks conversation on test@
18:48:34 <tflink> or just continue the conversation
18:48:41 <adamw> in all honesty i don't feel like i can make a great call on this because i'm so damn sick of this release i'd ship hello_world.sh with a shiny Fedora 16 sticker on it at this point.
18:48:48 <adamw> ack. whatever.
18:48:59 <spot> i can
18:49:05 <spot> i cannot find anyone awake to work this
18:49:10 <spot> best hope is wwoods
18:49:12 <spot> but he's MIA
18:50:06 <tflink> either way, it sounds like we're pretty much even on this
18:50:12 <tflink> maybe slightly +1
18:50:20 * spot is taking a look personally
18:50:28 <spot> although i am entirely novice in dracut
18:50:36 <adamw> hey, it's just shell scripts, how hard can it be.
18:50:59 <adamw> bcl: it might help to have a log of it *succeeding* as well as one of it failing, perhaps? and you could bisect the 15-16 changes, since there's a lot of them
18:51:24 <bcl> I do. I'm stepping through both right now.
18:51:31 <adamw> cool
18:51:34 <bcl> I'll add my working log to the bug
18:51:34 <tflink> ok, I'm going to +1 adamw's "let's be done talking about it for now"
18:51:52 <tflink> leave as proposed and vote async in the bug
18:51:53 <spot> bcl: does your shell script start with a shebang?
18:52:28 <red_alert> tflink: you can't _leave_ it as proposed as it's currently AcceptedBlocker ;)
18:52:43 <tflink> red_alert: not it's not. I'm closing that one
18:52:51 <tflink> we're talking about the dracut bug
18:53:16 <red_alert> ah, my bad....brain's hibernated, needs dinner :)
18:53:18 <bcl> spot: yes
18:53:22 <bcl> it is also executable
18:53:54 <tflink> proposed #agreed - 750603 - We're still undecided on whether or not this should block release. Will make decision over the next couple of hours - please vote in bug.
18:53:58 <tflink> ack/nak/patch?
18:54:10 <adamw> ack
18:54:18 <tflink> #agreed - 750603 - We're still undecided on whether or not this should block release. Will make decision over the next couple of hours - please vote in bug.
18:55:24 <tflink> gah, we have one ... interesting NTH bug
18:55:44 <tflink> oh, it starts making more sense as it goes on
18:55:51 <tflink> #topic (749985) F16 RC1 Live-CD test - some errors to look at
18:55:51 <tflink> #link http://bugzilla.redhat.com/show_bug.cgi?id=749985
18:55:51 <tflink> #info Proposed NTH, MODIFIED
18:56:36 <tflink> which has been closed since I generated my list
18:56:54 <tflink> I assume that we still need to ack it as NTH since it made it into RC3?
18:57:07 <adamw> yeah, retrospective justification ftw
18:57:12 <adamw> +1 nth
18:57:21 <red_alert> what happens if we don't? ;D
18:57:44 * red_alert has his -1 NTH ready for the lulz ;)
18:57:51 <tflink> proposed #agreed - 749985 - AcceptedNTH - Broken power management is a blocker issue for LXDE and therefore NTH
18:58:09 <adamw> red_alert: world ends, i get to relax!
18:58:20 <red_alert> +1 NTH then :D
18:58:21 * tflink ignores red_alert, wants to be done with this
18:58:28 <adamw> ack
18:58:30 <tflink> the timing on that was awesome
18:58:37 <tflink> #agreed - 749985 - AcceptedNTH - Broken power management is a blocker issue for LXDE and therefore NTH
18:58:40 <spot> bcl: your line numbers from the bug don't match the checkout i'm lookin at
18:58:49 <tflink> unless more blockers have come in since we started, I think we're done
18:59:07 <tflink> nope, I'm not showing anything new
18:59:11 <tflink> #topic open floor
18:59:12 <spot> bcl: 013-17 is what i did fedpkg prep on.
18:59:23 <tflink> adamw: are you playing secretary or should I?
18:59:28 <bcl> well that's dumb
18:59:46 <bcl> it exits inst_binary if the target directory exists.
19:00:11 <spot> bcl: ignore me, i'm being dumb
19:00:13 <tflink> anything else?
19:00:31 * tflink sets fuse for 0 < x < 5 minutes
19:00:40 <bcl> spot: the broken ones are from -16 which is what the TC3 DVD install installed
19:00:59 <cwickert> tflink: there is no need to act on 749985, this is fixed in rc3
19:01:04 <cwickert> LXDE spin is ready
19:01:22 <tflink> cwickert: yeah but technically, we were supposed to take it as NTH before it made it into RC3 :)
19:01:29 <cwickert> ah, I see
19:01:39 <spot> +-    [[ -e $initdir$_target ]] && return 0
19:01:39 <spot> ++    [[ -e $initdir/$_target ]] && return 0
19:01:50 <tflink> but it was a clear cut NTH, so just dotting is and crossing ts
19:01:50 <spot> thats why it started failing. before it was never true.
19:02:09 * cwickert is afk
19:02:14 <spot> 0096-dracut-functions-do-not-install-files-from-current-d.patch
19:02:25 <bcl> spot: the key change seems to be calling inst_binary from inst_script instead of inst_simple
19:02:44 <spot> well, inst_binary shouldn't fail if the $target dir exists
19:02:47 <tflink> ok, then. Thanks for coming everyone!
19:03:00 * tflink will probably send out minutes shortly
19:03:04 <tflink> #endmeeting