f17-beta-blocker-review-2
LOGS
17:02:02 <adamw> #startmeeting F17-beta-blocker-review-2
17:02:02 <zodbot> Meeting started Fri Mar  9 17:02:02 2012 UTC.  The chair is adamw. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:02:02 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
17:02:07 <adamw> #meetingname F17-beta-blocker-review-2
17:02:07 <zodbot> The meeting name has been set to 'f17-beta-blocker-review-2'
17:02:19 <adamw> #topic roll call
17:02:21 * nirik is lurking.
17:02:27 * pschindl is here
17:02:32 * brunowolff is here, but might need to leave a bit before noon.
17:02:34 <adamw> who's here for some super exciting, nay, thrilling, blocker review
17:02:45 <brunowolff> (CST -0600)
17:03:32 * bcl wiggles his fingers
17:03:35 <adamw> also, does anyone want to secretaryize?
17:03:36 * kparal here
17:04:12 <adamw> hey millionaire
17:04:14 * maxamillion is here-ish
17:04:27 <maxamillion> I'm in a meeting at work in person and attempting to attend here ... we'll see how this goes :)
17:05:31 <bcl> don't cross the streams
17:05:33 <adamw> oh, about as well as it normally does!
17:05:42 * adamw pounds coffee and makes crap up as he goes along
17:05:50 <maxamillion> adamw: LIKE A BOSS
17:05:52 <maxamillion> >.>
17:06:19 * adamw is far from a hip-hop authority, but isn't that kind of old?
17:06:39 <maxamillion> adamw: I think its alive and well in internet meme land
17:06:48 <adamw> oh, my. that scary territory.
17:07:03 <maxamillion> yeah .... #rhel likes to post randomness from that black hole of the internet
17:07:20 <maxamillion> and I spend *far* too much time in #rhel
17:07:32 <adamw> #chair kparal
17:07:32 <zodbot> Current chairs: adamw kparal
17:07:42 <adamw> okay, excuse me while i laboriously copy/paste tflink's intro stuff
17:07:47 <adamw> #topic Introduction
17:07:54 <maxamillion> I'm the #1 poster in #rhel ... :( ... I'm part proud, part really sad for myself --> http://www.delhage.se/rhelstats/
17:07:57 <adamw> #info Our purpose in this meeting is to review proposed blocker and nice-to-have bugs and decide whether to accept them, and to monitor the progress of fixing existing accepted blocker and nice-to-have bugs.
17:08:04 <adamw> #link https://fedoraproject.org/wiki/Current_Release_Blockers
17:08:07 <adamw> #link https://fedoraproject.org/wiki/Fedora_17_Beta_Release_Criteria
17:08:11 <adamw> #link https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting
17:08:16 <adamw> Up for review today are:
17:08:30 <adamw> #info 9 Proposed Blockers
17:08:43 <maxamillion> oooo, the current release blockers page is awesome
17:08:44 <maxamillion> kudo
17:08:47 <maxamillion> +s
17:08:48 <adamw> #info 7 Accepted Blockers
17:09:00 <adamw> so let's start with the proposed blockers
17:09:24 <adamw> maxamillion: yeah, it's nifty, right? I think jlaska hacked it up.
17:09:35 <maxamillion> adamw: it is quite nifty
17:09:36 <adamw> christ alone knows where the script runs.
17:09:42 <maxamillion> heh
17:09:48 <adamw> #topic http://bugzilla.redhat.com/show_bug.cgi?id=801782
17:09:49 <buggbot> Bug 801782: unspecified, unspecified, ---, debarshi.ray, NEW, Updates notification doesn't show up
17:09:49 * maxamillion bets nirik knows where the script is :D
17:10:15 <nirik> hum?
17:10:27 <nirik> no idea. jlaska set that up somewhere.
17:10:46 <adamw> man, we're so professional it *hurts*
17:10:53 <pschindl> in this one, I'm not sure if it is problem of PackageKit. It might be a problem of notification system or something like this
17:10:56 <maxamillion> nirik: oh, lol :P
17:11:03 <adamw> pschindl: packagekit is usually a good guess
17:11:10 <maxamillion> nirik: I just assume you know all ... because so far in my history in Fedora land, its proven true ;)
17:11:20 <adamw> it seems pretty straightforward to me, the only concern i have is that two hours _may_ not be long enough. blocker notification can be...weird.
17:11:22 <nirik> I'm sure I can find it if it's important.
17:11:27 <maxamillion> adamw: yes, we are professional grade
17:11:31 <pschindl> anyway it is blocker
17:11:33 <adamw> but that said, i don't recall ever getting any on my desktop, so i wouldn't be surprised if it was broken.
17:11:40 <adamw> so yeah, +1 on this.
17:11:45 <maxamillion> +1 as well
17:12:08 <pschindl> +1
17:12:19 <adamw> any objections?
17:12:43 <kparal> +1
17:13:20 <adamw> propose #agreed 801782 is a blocker per beta criterion "The default update manager in release-blocking desktops must not periodically check for updates when the system is booted live, but must periodically check for updates when running on an installed system"
17:13:34 <kparal> ack
17:13:36 <pschindl> ack
17:13:39 <brunowolff> ack
17:14:06 <maxamillion> ack
17:14:28 <adamw> #agreed 801782 is a blocker per beta criterion "The default update manager in release-blocking desktops must not periodically check for updates when the system is booted live, but must periodically check for updates when running on an installed system"
17:14:34 * adamw vows to stop reading news in the background
17:14:47 <adamw> so if no-one's going to secretaryize i'll just go round and do it after the meeting
17:15:33 <kparal> you mean provide info into the bug reports?
17:15:44 <adamw> yeah - update the bug reports
17:15:54 <adamw> set the fields correct and post a comment explaining what happened, like i usually do
17:15:55 <kparal> do we have some template?
17:16:03 * kparal will read SOP
17:16:06 <adamw> nah, it's freeform more or less.
17:16:22 <adamw> I usually start the comment with 'As discussed at the blocker bug review of (DATE)' and then just explain the decision.
17:16:31 <adamw> #topic http://bugzilla.redhat.com/show_bug.cgi?id=787744
17:16:32 <buggbot> Bug 787744: unspecified, unspecified, ---, wwoods, ASSIGNED, "rd.luks=0 rd.md=0 rd.dm=0" required for kernel boot, otherwise anaconda crashes
17:17:04 <kparal> let me give you quick summary
17:17:23 <adamw> by all means
17:17:29 <kparal> if you boot from kernel+initrd and have encrypted disk and don't provide these boot options manually, anaconda crashes
17:17:46 <kparal> it was already approved for alpha, then closed as wontfix, then reopened
17:17:55 <kparal> because wwoods said he can make those options as default
17:18:13 <kparal> so you don't have to specify them
17:18:20 <kparal> and virt-install doesn't have to be patch etc
17:18:23 <kparal> *patched
17:19:09 <adamw> so...this seems like something we should fix, sure, but it doesn't necessarily feel like a beta blocker.
17:19:18 <adamw> i dunno, though. i'm kind of on the fence.
17:19:24 <adamw> bcl, any thoughts from anaconda side?
17:19:38 * kparal searches for criterion "installer must not crash"
17:19:39 <bcl> uhh...
17:19:43 <kparal> is it Final?
17:20:04 <bcl> oh, I think noloader will fix this.
17:20:26 <adamw> kparal: that's not exactly a criterion in itself.
17:20:31 <bcl> it isn't a blocker. you just need have the right kernel params.
17:20:34 <kparal> true, I didn't find it
17:20:44 <adamw> so let's delimit this
17:20:57 <kparal> I'm fine with Final
17:21:03 <adamw> i don't think we really need to care about virt-install etc because in general, it's the responsibility of tools like that to work with what they're given
17:21:22 <adamw> we can't really consider 'breaks some random downstream tool' to be a release blocker when it's not like anaconda publishes an API or something...
17:21:43 <kparal> that seems as a valid point
17:22:01 <adamw> so far as stuff that's actually in the criteria and which we really care about goes...what's affected by this are cases where you're somehow manually booting the installer, right?
17:22:10 <adamw> i.e. not actually writing an image to something and booting it
17:22:11 <kparal> otoh people are used to boot kernel+initrd, same as adminitrators when creating pxe setups
17:22:19 <adamw> but configuring some kind of bootloader
17:22:24 <adamw> right
17:22:25 <pschindl> If some easy workaround exist, I'm -1 blocker, +1 NTH
17:22:34 <adamw> so the actual specific cases we have of that are...what? PXE boot is one
17:22:38 <kparal> workaround exists, just add those options
17:23:01 <brunowolff> What about updates of systems with encrypted disks?
17:23:14 <brunowolff> I couldn't tell for sure if those were broken.
17:23:30 <kparal> my point is that anaconda should not crash, there's not reason. it should spit out "sorry, can't work with unlocked devices" or something
17:23:59 <adamw> brunowolff: it's only a problem if you're in some way directly booting the installer's kernel/initrd, not writing an image and booting it. in those cases, systems with encrypted and/or RAID devices will be affected.
17:24:05 <kparal> but this will be fixed eventually according to wwoods
17:24:11 <maxamillion> yeah, I actually agree with that ... a crash is not good
17:24:30 <adamw> well, sure, but there's not a huge deal of functional difference between those cases.
17:24:32 <kparal> I just want to make sure we don't allow Final to go gold without having this fixed
17:24:35 <adamw> ultimately the experience is 'install fails'.
17:25:00 <adamw> kparal: well...that's really the question we're asking :) do we actually have to ensure that?
17:25:13 <adamw> so, I think PXE counts as Final, right?
17:25:27 <adamw> hum, no. we have it marked as Alpha.
17:25:30 <bcl> pxe works too. you just need the right parameters.
17:25:46 * kparal is really bad at searching criteria pages
17:26:09 <kparal> it just needs the right parameters otherwise it crashes and doesn't offer you any advice
17:26:33 <adamw> bcl: yeah, but that's the only case we have that's really materially affected and in the criteria, which is why i'm focusing on it.
17:26:42 <fenrus02> adamw, pxe really should work by beta.  not sure about alpha.
17:27:22 <adamw> still, i think if we want this to be a blocker it should be beta blocker. final blocker doesn't really seem justified by the process. either beta blocker or no blocker, for me. i'm leaning towards 'no blocker'.
17:27:24 <kparal> I can't find "pxe" anywhere in those pages
17:27:41 <adamw> kparal: yeah, i think we consider it covered by some more generally-worded criterion, but i'm having trouble remembering the details
17:27:56 <adamw> pschindl: do you remember what we decided about pxe and the criteria in ticket 151?
17:28:00 <bcl> I'm good with fixing it to 'just work', but I also think it is reasonable to expect people to check for new boot arguments and update their setups accordingly.
17:28:18 <adamw> yeah, i think it would be best to fix it, but it doesn't smell of blocker to me.
17:28:19 <fenrus02> bcl, whare are 'the right params' to make pxe work?
17:28:20 <kparal> 'just work' is definitely prefered
17:28:31 <adamw> fenrus02: as it says in the bug title
17:28:32 <pschindl> adamw: I'don't. I think, that we didn't talk about PXE at all
17:28:39 <adamw> rd.luks=0 rd.md=0 rd.dm=0
17:28:47 <bcl> the ones in the title of the bug, or more generally, the ones we write to the bootloader for the boot.iso
17:28:52 <adamw> pschindl: hum, maybe we should circle back around to it then. and i'll have to dredge my memory.
17:28:55 <fenrus02> adamw, that hardly seems like "working as designed" when you cannot use crypto or raid
17:29:01 <adamw> fenrus02: you can.
17:29:13 <adamw> fenrus02: the point of the kernel parameters is to stop dracut activating the devices and let anaconda do it.
17:29:21 <fenrus02> ah, i see
17:29:37 <maxamillion> I feel like rd.luks=0 for a luks device seems ... odd, unless I'm missing something
17:29:39 <adamw> fenrus02: without the parameters, dracut will try to activate any raid or luks devices it finds on any hard disk on the system, and anaconda gets confused when it does its storage scan.
17:29:45 <adamw> maxamillion: ^^^
17:29:52 <kparal> one possible scenario: system admin adds F17 to company PXE (not RH). some people boot. some people don't, it crashes. "damn Fedora". only later sysadmin finds out there must be new options specified
17:30:00 <kparal> which were not necessary by the way
17:30:09 <kparal> could have been fixed
17:30:18 <fenrus02> they were not required in f16 nor prior
17:30:24 <kparal> poor experience in my eyes
17:30:35 <maxamillion> adamw: ahhhhh ok
17:30:53 <bcl> so? progress means change. Part of their job is making sure they understand the changes.
17:30:55 <adamw> kparal: sure. is it a release blocker? mehhhh.
17:31:06 <adamw> just because we don't make it a blocker, doesn't mean it won't get fixed.
17:31:07 <kparal> anaconda should either fix it or not crash and provide helpful information
17:31:11 <maxamillion> adamw: is there a listing of all possible parameters for the kernel boot line in kernel-docs or something? .... I feel like there was but I'm failing to locate it
17:31:25 <adamw> maxamillion: there's a listing of all actual true kernel parameters in there somewhere, yeah
17:31:34 <adamw> maxamillion: but most 'kernel parameters' are not really *kernel* parameters at all
17:31:38 <adamw> they get passed along to some other bit
17:31:40 <bcl> maxamillion: not a complete one -- various programs use the cmdline for their own purposes.
17:31:45 <adamw> any rd.* parameter is handled by dracut, not kernel
17:31:49 <maxamillion> adamw: right
17:31:52 <maxamillion> bcl: yeah, rgr
17:31:55 <maxamillion> .... bugger
17:31:56 <bcl> anaconda is moving to using inst.*
17:32:01 <adamw> okay, so i think we kicked this one to death
17:32:03 <adamw> votes?
17:32:03 <maxamillion> adamw: so ... those would be dracut-doc maybe?
17:32:06 <adamw> i'm -1 blocker
17:32:06 <maxamillion> errr
17:32:10 <maxamillion> sorry to derail
17:32:20 <bcl> but in general, read the bootloader config from boot.iso, that will be the minimum needed.
17:32:26 <pschindl> still -1 blocker, +1 NTH
17:32:27 <adamw> maxamillion: 'man dracut.kernel'. clearly!
17:32:38 <maxamillion> adamw: ahhh, rocking
17:32:41 <kparal> I'm +1 blocker to either fixing it or not crashing
17:32:45 <adamw> this is certainyl something we 'd want in the release notes if not fixed.
17:33:13 <maxamillion> I'm +1 blocker, I think that's really unfortunate behavior
17:33:23 <fenrus02> this is sounding like "not expected to be fixed because anaconda is too messy"
17:33:25 <pschindl> yep, and we can start discussion on test list about PXE
17:33:44 <adamw> fenrus02: aiui it can be fixed and probably will
17:34:00 <adamw> but just because we're likely to get a fix doesn't mean we make it a blocker and pat ourselves on the back when the fix lands. =)
17:34:16 <fenrus02> then +1 NTH now, and +1 blocker for final.
17:35:14 <brunowolff> I'm +1 NTH, -1 blocker.
17:35:17 <maxamillion> the installer crashes, yes?
17:35:21 <kparal> yes
17:35:24 <adamw> oh goody, lack of consensus.
17:35:26 <bcl> not always
17:35:30 <kparal> :D
17:35:31 <brunowolff> (for beta, not sure about final)
17:35:31 <maxamillion> and this is acceptable and considered NTH because?
17:35:32 <fenrus02> yeppers.  anaconda crashes without any explaination
17:35:48 <adamw> maxamillion: why not? we don't consider every possible thing that makes the installer crash a blocker. why would that be the case?
17:35:51 <bcl> only if it has luks, md or dm raid for dracut to activate.
17:35:52 <maxamillion> (not trying to be snooty, just honestly don't entirely understand)
17:36:01 <maxamillion> adamw: ahhhh, ok
17:36:11 <fenrus02> "explanation" rather. (speling is hrd)
17:36:22 <adamw> things are blockers if they infringe the criteria. and of course we can write new criteria where it seems appropriate. but we've never, ever said 'any installer crash is a blocker'.
17:36:31 <brunowolff> I was thinking +1 NTH because it would be hard to fix with updates if you can install.
17:36:38 <brunowolff> s/can/can't/
17:36:39 <maxamillion> fenrus02: your keyboard is defective, I suggest you demand a full refund ;)
17:36:45 <adamw> i'm sure you can crash anaconda *somehow* in any fedora release.
17:36:49 <maxamillion> adamw: that's fair
17:36:54 * fenrus02 ^5s maxamillion
17:36:55 <adamw> brunowolff: it's easy to workaround if you read the docs.
17:37:02 <maxamillion> yeah, I crashed the F16 installer a few days ago
17:37:06 <bcl> brunowolff: it is easy to fix. it only hits non-media installs. they have control over their commandline.
17:37:19 <maxamillion> alright ... I'd like to change mine
17:37:24 <bcl> the iso's have this set as the defauly FYI.
17:37:24 <maxamillion> -1 blocker, +1 NTH
17:37:38 <adamw> so let me count
17:37:44 <fenrus02> bcl, including live?
17:37:49 <bcl> yes
17:37:51 * maxamillion didn't entirely understand
17:38:22 <adamw> we have 4 -1 blocker
17:38:24 <adamw> 1 +1 beta blocker
17:38:27 <adamw> 1 +1 final blocker
17:38:28 <kparal> I just hope wwoods finishes this in time
17:39:00 <adamw> it's always nice to have consensus...but that seems 'not a blocker-y' enough for me, sorry fenrus/kparal
17:39:09 <adamw> feel free to store this up for your 'i told you so' files :)
17:39:21 <fenrus02> adamw, heh
17:39:29 <adamw> 'they didn't listen to me...they NEVER listen to me...but who's laughing now, huh? WHO'S LAUGHING NOW?!'
17:39:40 <kparal> actually I am
17:39:51 <kparal> but, I'll have my revenge sooner or later
17:40:28 <fenrus02> bcl, does adding those same options break f16's pxe ?
17:40:29 <kparal> we seem to have different approach in 'not defined in the criteria'
17:40:31 <adamw> propose #agreed 787744 is rejected as a blocker: it doesn't really prevent direct kernel boot of the installer from working, you just need to specify some parameters for it. i.e. it's 'easily workaroundable'. accepted as NTH, if the fix is not too invasive.
17:40:51 <brunowolff> +1
17:40:53 <adamw> fenrus02: no. in f16 and earlier, those options got added 'for you' even when doing a pxe-style boot. so it'd just be redundant to add them again.
17:41:08 * kparal abstains
17:41:26 <fenrus02> adamw, ok.  +1 NTH then.  (redundant should not break anaconda)
17:41:28 <pschindl> hmm, what about NTH
17:41:50 <adamw> kparal: i think we consider pxe to be 'in the criteria' somewhere, but my position is that this doesn't really break the criteria, because it's not like pxe install is impossible. it just requires some parameters in some specific case, which we could certainly document.
17:42:04 <bcl> fenrus02: It shouldn't
17:42:06 <adamw> pschindl: the NTH votes seemed pretty clear, no-one voted -1 on nth.
17:42:26 <kparal> let's hope anaconda won't introduce 'standing on one leg' requirement next time
17:42:30 <fenrus02> bcl, anaconda is fragile enough, i hate having to add special cases to it every single release
17:42:59 <adamw> bcl: obviously, we'd still much appreciate it if you guys can fix this one.
17:43:40 <brunowolff> I need to leave. Hopefully you guys will be done before I get back.
17:43:55 <bcl> adamw: obviously
17:44:18 <adamw> brunowolff: ahahahaha.
17:44:22 <adamw> can i get me some ax?
17:44:24 <adamw> (acks)
17:44:30 <adamw> or nacks. or whatever.
17:44:34 <pschindl> ack
17:44:35 <bcl> ackack
17:44:49 <adamw> okay, let's escape this hell hole.
17:44:58 <adamw> #agreed 787744 is rejected as a blocker: it doesn't really prevent direct kernel boot of the installer from working, you just need to specify some parameters for it. i.e. it's 'easily workaroundable'. accepted as NTH, if the fix is not too invasive.
17:45:03 <maxamillion> ack
17:45:08 <maxamillion> oh ... heh, little late
17:45:15 <kparal> :)
17:45:27 <adamw> YOUR ACK IS USELESS TO ME NOW
17:45:29 <adamw> #topic http://bugzilla.redhat.com/show_bug.cgi?id=800316
17:45:30 <buggbot> Bug 800316: high, unspecified, ---, anaconda-maint-list, ASSIGNED, Bootloader upgrade options description is misleading
17:45:42 <kparal> I tagged this one as well. but from a bit different reason
17:45:58 <kparal> I don't consider the bug per say as  a blocker, but the lack of information what to test
17:46:10 <kparal> currently our bootloader upgrade test cases fail
17:46:23 <kparal> and we're not sure what is the correct behavior
17:46:39 <kparal> we need this information to update the test cases and then we can discuss the bug itself
17:46:50 <pschindl> not only bootloader upgrade, but skip ones fail too
17:46:53 <adamw> i think i'm -1 on this: the specific issue described here isn't a blocker, and there are other bugs for the more significant issues with bootloader behaviour on upgrade
17:47:17 <adamw> pschindl: afaict skip bootloader actually does what it's meant to, so far as anaconda is concerned. anaconda can't really do anything about what kernel %Post does.
17:47:30 <adamw> i think it would be a good idea to clarify the description of 'skip bootloader', but it doesn't seem like a blocker.
17:47:36 <kparal> our test case says: "The previous bootloader configuration should be left completely untouched, even if it is now invalid (unbootable)"
17:47:39 <fenrus02> -1 blocker unless i misunderstand the point.  just reword and call it a nth
17:47:46 <adamw> kparal: we'll have to update the test case, now.
17:47:53 <maxamillion> -1 blocker
17:47:59 <kparal> if we can right away say this description is not correct, then we can remove the blocker then
17:48:05 <maxamillion> pretty much what fenrus02 said
17:48:07 <kparal> but I wasn't sure of that
17:48:14 <fenrus02> reworded to say "install on mbr / gpt" would be accurate
17:49:38 <adamw> kparal: the test case was accurate for a grub-legacy world
17:49:47 <kparal> alright, so pester anaconda team to provide description of what to expect from those two options, update test cases, and remove blockerness
17:49:59 <adamw> yeah, that sounds like the ticket here.
17:50:14 <adamw> but we should make sure the more significant bugs about bootloader behaviour on upgrade are blockerish. /me goes to look
17:50:18 <kparal> I intended to do it and marked it as blocker, but didn't realize the meeting is the very day, otherwise I probably wouldn't
17:51:30 <adamw> so i think we should probably have 800376 and 742207 as blockers
17:51:35 <kparal> I still think this could go as Final NTH, since some people can suppose it really doesn't touch their config
17:51:37 <adamw> i'll propose them and we can do 'em later
17:51:37 <kparal> when it does
17:52:06 <kparal> and I'm not sure why 'Update bootloader' option is missing
17:52:36 <kparal> oh, that's the one you reference
17:52:37 <kparal> d
17:52:55 <kparal> alright
17:53:05 <adamw> okay
17:53:35 <adamw> propose #agreed 800316 is not a blocker as the impact is fairly small (it affects only the rarely used 'skip bootloader' option). we have other bugs for more serious problems with bootloader handling on upgrade
17:53:37 <adamw> ack/nack/patch?
17:53:50 <pschindl> ack
17:53:52 <kparal> ack
17:53:53 <fenrus02> ack
17:53:54 <maxamillion> ack
17:54:07 <adamw> #agreed 800316 is not a blocker as the impact is fairly small (it affects only the rarely used 'skip bootloader' option). we have other bugs for more serious problems with bootloader handling on upgrade
17:54:20 <adamw> #topic http://bugzilla.redhat.com/show_bug.cgi?id=797507
17:54:21 <buggbot> Bug 797507: high, unspecified, ---, dracut-maint, NEW, Failure install PXE UEFI dracut: FATAL: No or empty root= argument
17:55:04 <kparal> this is just a dupe of the famous empty root= bug, isn't it?
17:55:06 <adamw> oh, isn't this the same old https://bugzilla.redhat.com/show_bug.cgi?id=785815 ?
17:55:07 <buggbot> Bug 785815: unspecified, unspecified, ---, wwoods, ASSIGNED, anaconda requires root= kernel argument
17:55:10 <adamw> seems like it
17:55:15 <adamw> bcl: are we wrong?
17:55:36 <bcl> sounds like it on the surface...
17:55:51 <kparal> read comment #4
17:56:13 <kparal> but it's a dupe
17:57:00 <bcl> yeah, not limited to EFI.
17:57:31 <adamw> the preupgrade consequence of this makes me think maybe we should have 785815 as a beta blocker.
17:57:33 <fenrus02> close one, and mark the other as blocker?
17:57:36 <kparal> but if it breaks preupgrade, we should have a special bug for it, or mark blocker the original one
17:57:53 <bcl> similar to the other one, you have to pass the right args -- although I think wwoods has a fix for this one as well.
17:57:54 * kparal has slow fingers
17:58:08 <bcl> if preupgrade isn't setting it up right then that's a preupgrade bug.
17:58:20 <kparal> bcl: anaconda is rather picky these days, isn't it?
17:58:38 <bcl> not really.
17:58:57 <adamw> kparal: it's all consequences of this 'noloader' change aiui
17:59:11 <kparal> I'm just teasing
17:59:18 <fenrus02> this seems to have no workaround for pxe, and a outright bug for preupgrade.
17:59:21 <kparal> but preupgrade is beta
17:59:26 <kparal> we should have a blocker bug for it
17:59:28 <bcl> not realy, it is more related to the live environment we use to save memory usage.
17:59:33 <pschindl> https://bugzilla.redhat.com/show_bug.cgi?id=800205
17:59:35 <buggbot> Bug 800205: urgent, urgent, ---, hughsient, NEW, kernel panic after running preupgrade
17:59:35 <adamw> oh, right, sorry. wrong change
17:59:42 <pschindl> this is the bug for preupgrade
17:59:46 <adamw> cool, thanks.
17:59:47 <pschindl> it's on the list
18:00:17 <kparal> ok, then we can mark this one as a dupe
18:00:28 <adamw> propose #agreed 797507 is a dupe of 785815, we also have 800205 for the preupgrade case (which could be fixed on preupgrade side if it is not fixed on anaconda side)
18:00:43 <pschindl> ack
18:00:47 <fenrus02> is 785815 already accepted as blocker?
18:00:52 <kparal> ack
18:00:53 <kparal> not yet
18:01:00 <adamw> fenrus02: no, because in itself it isn't one (it's similar to the pxe case we discussed at length earlier)
18:01:01 <kparal> it is not even proposed
18:01:13 <adamw> but the preupgrade special case of this i think *would* be a blocker
18:01:28 <fenrus02> adamw, i know you dont care for pxe, but i use it extensively.  beta should be able to pxe
18:01:32 <adamw> it's important to differentiate them, though - we do need a separate bug for the preupgrade case, because even if this isn't fixed anaconda side, it could be fixed preupgrade side
18:01:36 <adamw> fenrus02: and it can
18:01:44 <adamw> fenrus02: you just have to specify the parameter.
18:01:56 <adamw> fenrus02: that's not really an odd thing to expect to have to do when you're _manually specifying how to boot a kernel_.
18:02:04 <fenrus02> adamw, what would root= for pxe installs then?
18:02:42 <kparal> fenrus02: see 785815
18:03:20 <fenrus02> yeah, looking for it
18:04:17 <fenrus02> c15 looks more like a hack, not a proper working fix
18:05:15 <kparal> it's all hacks
18:05:21 <kparal> proper fix is 'to come'
18:05:37 <fenrus02> then mark 785815 as blocker until the fix arrives
18:05:53 <adamw> we can kick 785815 around again if someone wants to propose it, sure.
18:06:10 <kparal> I already depleted my energy voting for broken anaconda issues
18:06:21 <kparal> this is basically the same as the pxe issue
18:06:24 <kparal> no difference
18:06:44 <kparal> it breaks tools, it breaks custom installation scenarios, it breaks guides all over the net
18:06:51 <kparal> but there's a workaround
18:07:12 <adamw> well, it's a bit different for me, in that the workaround is somewhat hacky as fenrus02 says
18:07:19 <adamw> 'point it to this random file on teh intarwebz'
18:07:33 <adamw> or, i guess, 'extract the random file and put it on your network somewhere and point installs to that'
18:07:36 <adamw> anyhow
18:07:41 <adamw> let's not get ahead of the discussion...
18:08:15 <kparal> I think we're still voting on #agreed dupe
18:08:17 <fenrus02> these two bugid's look like dups. one can be common faulted to the other.  the remaining one should be a blocker on beta.
18:08:51 <adamw> fenrus02: as i see it, 797507 is a dupe of 785815, and 800205 is a 'special case' for preupgrade. everyone okay on that?
18:09:06 <kparal> I am
18:09:21 <kparal> everyone else sleeps
18:09:34 <adamw> success!
18:09:35 <fenrus02> do they have the same fix?
18:09:41 <adamw> it's not a *real* blocker review until everyone's asleep.
18:09:43 * fenrus02 reads slowly
18:09:50 <adamw> fenrus02: 797507 and 785815, yes. they're precise dupes.
18:10:10 <fenrus02> adamw, sorry meant 800205 have the same fix as 785815
18:10:22 <fenrus02> is it really one problem, or two?
18:10:28 <adamw> fenrus02: it's quantum. =)
18:10:37 * fenrus02 chuckles
18:10:38 <adamw> fenrus02: if it gets fixed on anaconda side, aiui, that ought to fix it for preupgrade too.
18:10:55 <kparal> or preupgrade can work around
18:10:59 <adamw> but it's also theoretically possible we don't get a fix for anaconda, but we *could* fix it in preupgrade.
18:10:59 <adamw> yeah
18:11:08 <adamw> i.e. have preupgrade specify root= somehow.
18:11:13 <fenrus02> kparal, if preupgrade simply works-around, then that still leaves pxe broken
18:11:28 <bcl> preupgrade needs to pass root, since it is setting up the environment.
18:11:29 <kparal> yes
18:11:30 <adamw> yeah. it's obviously a sub-optimal solution. but it's still worth tracking them separately because of that factor, i think.
18:11:34 <fenrus02> otoh, if anaconda reverts to expecting the same that f16 did, it works for all cases
18:11:59 <kparal> fenrus02: again correct
18:12:27 <bcl> fenrus02: we can't 'revert'. this is a change that won't change :)
18:12:39 <adamw> bcl: um. wwoods seems confident he's going to 'fix' this somehow.
18:12:46 <adamw> are we on different pages as to exactly what that means?
18:12:49 <kparal> not revert code, just revert behavior to the old one
18:12:50 <fenrus02> bcl, "expecting the same params" is not the same as rolling back the feature that mandated this
18:13:16 <kparal> anyway, can we finally agree $TOPIC is a dupe?
18:13:24 <maxamillion> I have to duck out ... laters all
18:13:25 <fenrus02> yep, certainly looks like a dup
18:13:40 <kparal> 3x ack I count
18:13:44 <adamw> bcl: i think we're all expecting that anaconda will 'fix' this in the sense of 'no user should have to worry about manually passing root= parameters'
18:13:46 <adamw> kparal: yup
18:13:59 <adamw> #agreed 797507 is a dupe of 785815, we also have 800205 for the preupgrade case (which could be fixed on preupgrade side if it is not fixed on anaconda side)
18:14:01 <bcl> adamw: for most cases, yes.
18:14:01 <bcl> but for, eg. PXE, you have to tell it where to find squashfs.img, it can't know where you want to serve it from.
18:14:22 <bcl> adamw: s/no/most/ and I'd agree.
18:14:22 <fenrus02> bcl, how did f16 do it?
18:14:33 <bcl> f16 was different. it was all in the same initrd.
18:14:41 <bcl> f17 is more like f15 with stage2.
18:14:48 <adamw> how did f15 do it?
18:14:49 <adamw> :P
18:14:50 <bcl> or was that 14?
18:14:50 <kparal> actually it can search the directory provided as method=
18:14:58 <fenrus02> fair enough, but i didnt have to specify root= for f15 either
18:15:14 <adamw> okay, so in the interests of time...
18:15:20 <bcl> maybe it was 14. either way, you're complaining about change, not real bugs.
18:15:21 <adamw> i think we should definitely discuss the pxe case further in the bug
18:15:36 <bcl> you have to expect to deal with differences.
18:15:49 <adamw> bcl: i dunno, it sure looks like a functional regression to the regular PXE user. suddenly, they have to serve this apparently random file to the installer and tell it where to find it. they never had to before.
18:15:52 <kparal> bcl: just make it easier, not more difficult, and noone will complain
18:16:04 <bcl> what did the do when we had stage2?
18:16:04 <adamw> but yeah: we should discuss that in the bug and see if we can come up with a better fix, but for now let's move on...
18:16:22 <fenrus02> bcl, i've never needed root= for pxe before.  not on any release.
18:16:23 * kparal moves on
18:16:31 <adamw> #topic http://bugzilla.redhat.com/show_bug.cgi?id=736993
18:16:33 <buggbot> Bug 736993: medium, unspecified, ---, pjones, ASSIGNED, error install bootloader with serial interface install
18:16:42 <adamw> so, this is the ol' serial install one
18:16:50 <kparal> ah, again, old friend bug
18:17:06 <adamw> last week we agreed to kick off a discussion on test@ about whether serial console should be beta or final
18:17:13 <adamw> that hasn't totally concluded yet, but it seems to be skewing towards beta
18:17:20 <adamw> so do we want to punt this another week or just take it as a beta blocker?
18:17:24 <kparal> I think noone else responded except me and adamw?
18:17:27 <fenrus02> do we have any req's on serial installs for beta?
18:17:32 <adamw> dan did (vicodan2)
18:17:39 * kparal reads
18:17:53 <adamw> fenrus02: it's still at the 'proposal' stage, as we never definitely decided whether we want it to be beta or final
18:18:06 <adamw> fenrus02: the list thread is "Installation interfaces criterion proposal" by pschindl
18:18:07 <fenrus02> adamw, ime, this is a "final" item, not a "beta" item.
18:18:07 <bcl> FYI I have the fix for this.
18:18:15 <kparal> ok, dan votes for beta
18:18:35 <adamw> fenrus02: it's worth reading kparal's post in the thread, it has a good argument for beta.
18:18:44 * fenrus02 still looking for thread
18:19:03 <adamw> fenrus02: https://lists.fedoraproject.org/pipermail/test/2012-March/106028.html
18:19:14 <fenrus02> ta
18:20:00 <adamw> bcl: yay. so it's not a big problem if we decide to make it a beta blocker?
18:20:43 <bcl> fine with me.
18:20:54 <fenrus02> hm.  good point.
18:21:31 <adamw> so our choices are basically to punt for another week and let the discussion roll, or just make the call that we're going beta for serial now.
18:21:50 <pschindl> +1 beta blocker
18:22:20 <kparal> pschindl: welcome back :)
18:22:26 <kparal> +1 beta blocker
18:22:47 <fenrus02> i think i have to agree with kparal's reasoning.
18:22:54 <adamw> yeah, +1 beta here too, let's just call it: serial console is beta
18:23:11 <kparal> WHO'S LAUGHING NOW???
18:23:16 * fenrus02 ^5s kparal
18:23:18 <kparal> sorry, I had to
18:23:23 <kparal> couldn't resist
18:23:42 <adamw> propose #agreed 736993 is a beta blocker: general consensus that serial console should be beta blocking, we will tidy up the criteria to reflect this
18:23:50 <kparal> I think it's a good decision
18:23:52 <kparal> ack
18:23:52 <fenrus02> ack
18:23:53 <pschindl> ack
18:25:02 <adamw> #agreed 736993 is a beta blocker: general consensus that serial console should be beta blocking, we will tidy up the criteria to reflect this
18:25:32 <adamw> #topic http://bugzilla.redhat.com/show_bug.cgi?id=748964
18:25:33 <buggbot> Bug 748964: unspecified, unspecified, ---, pjones, NEW, grub2-mkconfig does not work with an unpopulated GRUB_PREFIX (i.e. before grub2-install) if using a serial console
18:25:46 <adamw> hum, this is another vintage one, right?
18:25:57 <adamw> ahh, it's the 'clone' i filed for a better fix.
18:26:02 <adamw> i see bcl just updated it
18:26:33 <adamw> does this strictly need to be a blocker, bcl? I mean, presumably if we don't put your 'good fix' in, we still have the 'ugly hack' from f16./
18:26:55 <kparal> maybe nth then?
18:27:28 <fenrus02> adamw, doesnt this relate to the last bug?  as in, if it's not fixed - serial console installs still fail?
18:27:33 <kparal> if the dirty hack works well, there's no need to make this a blocker
18:28:05 <adamw> fenrus02: afaict no, because like i say, we put a fix in for f16; it just wasn't considered a very 'clean' fix. but it worked.
18:28:20 <fenrus02> got it.  nth then imho.
18:28:21 <adamw> bcl: or did the unclean fix never get applied to the 17 branch?
18:28:29 <bcl> really this is just a dupe I think.
18:29:03 <bcl> the fix may have been lost in some rewrite of the bootloader code, the fix I'm adding will fix both of these :)
18:29:23 <fenrus02> thanks bcl =)
18:29:39 <adamw> i guess i'll just go look if the old fix is in f17 or not.
18:29:45 * adamw plays intermission music
18:30:04 * kparal switches to youtube
18:30:16 <adamw> nyan cat for everyone!
18:30:59 <bcl> adamw: I didn't see it (double call to grub2-install IIRC).
18:31:59 <fenrus02> adamw, that clearly falls into cruel and unusual punishment
18:32:30 <adamw> ah - seems like it did regress in f17
18:32:34 <adamw> the original bug was actually re-opened
18:32:47 <adamw> so we have https://bugzilla.redhat.com/show_bug.cgi?id=736993 and http://bugzilla.redhat.com/show_bug.cgi?id=748964 open currently.
18:32:49 <buggbot> Bug 736993: medium, unspecified, ---, pjones, ASSIGNED, error install bootloader with serial interface install
18:32:49 <buggbot> Bug 748964: unspecified, unspecified, ---, pjones, NEW, grub2-mkconfig does not work with an unpopulated GRUB_PREFIX (i.e. before grub2-install) if using a serial console
18:33:05 <adamw> so yeah, i guess we can just close this as a dupe and update 736993, and take it as a blocker.
18:33:19 <kparal> ack
18:33:22 <fenrus02> ack
18:33:39 <adamw> propose #agreed 748964 can now be considered a dupe of 736993 as that's been re-opened for F17 Beta. 736993 is accepted as a beta blocker as it breaks serial install.
18:34:00 <fenrus02> wfm
18:34:06 <kparal> ack
18:34:39 <adamw> #agreed 748964 can now be considered a dupe of 736993 as that's been re-opened for F17 Beta. 736993 is accepted as a beta blocker as it breaks serial install.
18:35:32 <adamw> #topic http://bugzilla.redhat.com/show_bug.cgi?id=799174
18:35:33 <buggbot> Bug 799174: high, high, ---, otte, NEW, update-testing repo for Fedora 17 has depenency problems.
18:35:40 * fenrus02 is running out of time and has to bail
18:35:53 <fenrus02> err, when has -testing been blocker for anything?
18:36:11 <adamw> these are just ongoing dependency issues
18:36:17 <adamw> not usually worth tracking as blockers
18:36:17 <adamw> yup
18:36:19 <adamw> -1
18:36:38 <adamw> if they get out of -testing and cause problems with composes that's another issue, but i don't see anything like that currently.
18:36:42 <adamw> i've mentioned to vicodan that it
18:36:44 <kparal> -1, updates-testing is not blocker, but some important package we want to push to stable might be
18:36:57 <adamw> it's not usually worth filing blockers for these as automatic notifications get sent to maintainers
18:37:23 <kparal> automatic notifications from where?
18:37:36 <adamw> propose #agreed 799174 is not a blocker: dependency issues in updates-testing are pretty common place and don't affect releases unless the problems get pushed to stable, which we would catch later
18:37:47 <adamw> kparal: those mails that get sent to -devel
18:37:55 <pschindl> ack
18:37:56 <nirik> not for updates-testing... but if it gets into stable/base
18:37:58 <kparal> ack
18:38:19 <adamw> #agreed 799174 is not a blocker: dependency issues in updates-testing are pretty common place and don't affect releases unless the problems get pushed to stable, which we would catch later
18:38:31 <adamw> #topic http://bugzilla.redhat.com/show_bug.cgi?id=800205
18:38:32 <buggbot> Bug 800205: urgent, urgent, ---, hughsient, NEW, kernel panic after running preupgrade
18:38:38 <adamw> so this is the preupgrade 'special case' of the root= bug
18:38:45 <kparal> those "F17 reports"? ok, but that's not really "sent to maintainers" . but thanks for clarification
18:38:49 <adamw> i'd say this one is definitely +1 blocker, even if the other isn't
18:38:52 <adamw> kparal: yeah, sorry
18:39:04 <adamw> preupgrade's supposed to work, it doesn't, pretty clear cut.
18:39:05 <nirik> kparal: the composes do spam maintainers for any broken deps.
18:39:23 <pschindl> +1 blocker
18:39:31 <kparal> +1 blocker
18:39:54 <kparal> nirik: that's great
18:40:09 <nirik> yep. :)
18:40:21 <kparal> nirik: daily?
18:40:28 <adamw> propose #agreed 800205 is a blocker per criterion "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"
18:40:32 <nirik> every compose run, yes.
18:40:33 <kparal> ack
18:40:35 <pschindl> ack
18:41:14 <adamw> #agreed 800205 is a blocker per criterion "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"
18:41:25 <adamw> #topic http://bugzilla.redhat.com/show_bug.cgi?id=591630
18:41:26 <buggbot> Bug 591630: high, urgent, ---, twoerner, ASSIGNED, DHCPv6 responses are not allowed by default ip6tables ruleset
18:41:28 <adamw> wow, old school!
18:42:33 * nirik thinks this one really needs fixed.
18:42:42 <adamw> charles has some pretty strong reasoning.
18:42:47 <adamw> https://bugzilla.redhat.com/show_bug.cgi?id=591630#c19
18:42:48 <buggbot> Bug 591630: high, urgent, ---, twoerner, ASSIGNED, DHCPv6 responses are not allowed by default ip6tables ruleset
18:43:01 <nirik> there's some discussion on the devel list about it as well.
18:43:14 <adamw> of course, this comes under the "There may be times where a requirement is unmet only in a particular configuration" section of the criteria too
18:43:33 <adamw> it's a conditional criterion breakage. it clearly breaks the 'network must work' stuff (criteria cited by charles) *in the case of an IPv6-only network*
18:43:42 <adamw> question is, are we yet at the point where we want to commit to that working OOTB.
18:44:03 <nirik> may be a fesco item... personally I think we should.
18:44:32 <adamw> yeah, it's a bit of a pay grade question.
18:44:35 <kparal> is that just a misconfiguration issue? easily solved?
18:44:37 * adamw grabs the magic 8-ball
18:44:45 <kparal> no technical obstacles?
18:44:52 <adamw> it looks fairly easily solved, yeah. but 'easily solved' or not shouldn't really factor strongly into blocker discussion.
18:45:11 <adamw> but yeah, i don't think there's any utterly insuperable obstacle to having IPv6-only work ootb given the components we have in f17.
18:45:47 <nirik> this may become more common and we should be supporting it before it does, IMHO.
18:45:48 <kparal> I think it should be blocker unless it's highly difficult to fix
18:46:35 <adamw> so how about we go with the 'better to ask forgiveness than permission' approach
18:46:47 <adamw> we take it as a blocker, and we notify devel list + fesco that we decided to make the call that ipv6 damn well ought to work by now
18:46:54 <adamw> if they think we shouldn't have done, they can let us know
18:47:07 <adamw> sound good
18:47:08 <adamw> ?
18:47:15 * kparal likes this approach
18:47:34 <kparal> python zen actually
18:47:50 <nirik> +1, fine with me.
18:48:51 <adamw> propose #agreed 591630 is a blocker: the bug infringes criteria cited in the report in the specific case of 'IPv6-only network'. we are making the determination that this is a significant enough case at this point in time to make the bug a blocker. we will report this decision to devel list and FESCo for their review
18:49:06 <kparal> ack
18:49:24 <pschindl> ack
18:50:11 <adamw> #agreed 591630 is a blocker: the bug infringes criteria cited in the report in the specific case of 'IPv6-only network'. we are making the determination that this is a significant enough case at this point in time to make the bug a blocker. we will report this decision to devel list and FESCo for their review
18:51:24 <adamw> #topic https://bugzilla.redhat.com/show_bug.cgi?id=800376
18:51:25 <buggbot> Bug 800376: unspecified, unspecified, ---, anaconda-maint-list, NEW, 'Update boot loader configuration' option is missing
18:51:52 <adamw> so, this is upgrade again
18:52:07 <adamw> pschindl: so when doing an upgrade from f16 the default was 'install a new bootloader'?
18:52:16 <pschindl> yep
18:52:22 <adamw> did it work?
18:52:26 <pschindl> and there was no option to update
18:52:35 <pschindl> install new works well
18:52:39 <adamw> okay
18:52:48 <kparal> as with the previous bug, we need anaconda input here
18:52:54 <kparal> it might be intentional
18:52:57 <adamw> so...i'm not sure it quite counts as blocker, though it's probably unintended behaviour, and 'update bootloader' is safer (less likely to cause problems)
18:53:16 <adamw> i'm probably -1 blocker +1 nth unless there's factors not yet considered
18:53:25 <pschindl> I would like to see this option in the future
18:53:25 <adamw> bcl: where are we with the whole bootloader-on-upgrade question atm?
18:53:31 <pschindl> so I'm +1 NTH too
18:53:33 <bcl> I'm not totally clear on what the upgrade options should be :/
18:53:38 <kparal> I'd delay this for next week and ask anaconda in the mean time
18:54:02 <bcl> It *does* work if you just accept the defaults.
18:54:03 <pschindl> it's not a blocker as you can save your grub settings somewhere and after upgrade make changes
18:54:16 <adamw> bcl: so prior to the Great Grub2 Migration the default option was 'update bootloader'
18:54:27 <adamw> bcl: which just tried to update grub.conf; it didn't touch any MBRs
18:54:47 <adamw> bcl: for f16 we made the default 'install new bootloader' and disabled 'update bootloader configuration', to force migration to grub2 on upgrade
18:55:29 <adamw> bcl: now we have a tricky situation with f17, because if you upgrade from f15 we still probably want to force you to replace grub with grub2 (i.e. 'install new bootloader'), but if you upgrade from f16, it's probably not ideal behaviour for us to go poking your mbr; don't we want to go back to just 'update bootloader configuration' for f16 -> f17 upgrades?
18:56:34 <pschindl> It would be nice if there was 'update bootloader' as default
18:56:58 <adamw> aside from the discussion of what would be best, let's still vote for blocker-or-not
18:57:06 <bcl> yeah, I'm just not sure what the expected behavior is for all the various ways to get there.
18:57:12 <adamw> i wanted to put it on the list...but as long as the default choice does seem to work in a basic test, it's probably -1 blocker
18:57:15 <pschindl> -1 blocker, +1 NTH
18:57:21 <kparal> postpone?
18:58:37 <adamw> not sure how much use that would be...i think we know the current situation reasonably well. 'install new bootloader' has some known complications (install it *where*?) but it broadly works, as f16 testing showed. we released f16 with it as the default option.
18:59:11 <kparal> we don't know whether anaconda wants 'update' present or not
18:59:30 <adamw> kparal: sure, but does that affect whether it's a blocker? blocker's based on functionality, not design choices...
19:00:10 <kparal> this can be an interesting discussion and I think I could use that argument against you in certain cases I proposed a blocker :)
19:00:12 <adamw> i guess it might matter if we were voting *+1* and then anaconda said 'hold on, but we don't want that'
19:00:20 <adamw> kparal: ooh! them's fighting words ;)
19:01:03 <kparal> exactly, if anaconda doesn't want that, it's much harder to say 'blocker'. if they say 'gosh, it should be there', then it's easy
19:01:10 <adamw> but since we seem to be voting -1 anyway...i don't see how anything anaconda team says about what design they want would change that vote
19:01:31 <kparal> alright
19:02:05 <adamw> am i making sense, or are you just agreeing so we can get out of here? :)
19:02:20 <kparal> am I so transparent?
19:02:48 <adamw> like a bottle of evian
19:02:54 <kparal> I am -1 blocker anyway
19:02:57 <adamw> okey dokey
19:03:25 <kparal> it's true we still have some time untill sunrise and then there's the weekend
19:03:28 <adamw> propose #agreed 800376 is not a blocker: it's likely not the desired design, but in practice, upgrade *does* work with the default option. if anaconda team want to improve the design that's great, but it's not a blocker
19:03:31 <adamw> hehe
19:03:34 <kparal> so we can academically discuss further
19:03:41 <adamw> you didn't want to see your family anyway, right?
19:03:42 <kparal> ack
19:03:43 <pschindl> ack
19:03:51 <adamw> #agreed 800376 is not a blocker: it's likely not the desired design, but in practice, upgrade *does* work with the default option. if anaconda team want to improve the design that's great, but it's not a blocker
19:03:54 <kparal> I'm already home
19:04:04 <adamw> ahh, where the liquor is
19:04:13 <pschindl> I'm the only one who stays in the work :(
19:04:26 <adamw> okay, let's just have a quick run through the accepted blockers
19:04:27 <kparal> pschindl: you'll know better next time!
19:04:29 <adamw> that's all the proposed
19:04:47 <pschindl> hoooray :)
19:04:49 <adamw> #topic bugzilla.redhat.com/show_bug.cgi?id=742207
19:04:59 <adamw> this is the matching bug for text mode - bootloader options are somewhat more screwed up there
19:05:13 <adamw> looks like bcl has a patch in, and an updates image for testing - so we need to give some feedback on that
19:05:30 <adamw> #info an updates.img is available for 742207, so it's on QA to check that out and give feedback to bcl
19:05:53 <adamw> not sure there's much else to say there?
19:05:55 <bcl> yeah, I changed text to match GUI
19:06:18 <adamw> apart from, of course, we still have the same consideration as for GUI - should we have 'update bootloader' active again, and default for f16-f17 upgrades
19:06:19 <bcl> so going forward we can make changes to both, once we figure out what right is.
19:06:23 <adamw> yup.
19:06:46 <adamw> okay, moving on...
19:06:55 <adamw> #topic http://bugzilla.redhat.com/show_bug.cgi?id=753421
19:06:56 <buggbot> Bug 753421: unspecified, unspecified, ---, dlehman, ASSIGNED, FSError: failed to get block size for ext4 filesystem on /dev/md127
19:07:09 <kparal> pschindl: your happiness was premature:)
19:07:23 <adamw> kparal: this bit should be pretty fast, i don't see any huge discussions pending
19:07:33 <adamw> this is another one with an updates.img that needs testing
19:08:00 <adamw> seems reasonably straightforward to test - try an upgrade on a system with md raid
19:08:08 <adamw> i have hardware to test that
19:08:16 <kparal> then it should be modified or on_qa?
19:08:24 <adamw> #info 753421 has an updates.img available for testing, so again, needs us to test
19:08:34 <adamw> kparal: i think not because the patch isn't committed to the anaconda tree yet
19:08:49 <adamw> kparal: anaconda team usually try to get testing and/or a review of the patch before actually committing it, and then set MODIFIED once it's committed
19:08:52 <kparal> alright, I sometimes recognize this way which bugs need testing
19:08:58 <brunowolff> Dang! You guys are still at it.
19:09:02 <adamw> brunowolff: nearly done
19:09:03 <kparal> we love it
19:09:18 <adamw> #topic bugzilla.redhat.com/show_bug.cgi?id=787461
19:09:33 <kparal> don't strip http:// please
19:09:42 <adamw> oop, sorry, didn't mean too
19:09:47 <adamw> to*
19:09:53 <adamw> #topic http://bugzilla.redhat.com/show_bug.cgi?id=787461
19:09:54 <buggbot> Bug 787461: unspecified, unspecified, ---, anaconda-maint-list, MODIFIED, system halts at first reboot after install
19:10:02 <adamw> so this got closed then reopened by hoyang
19:10:15 <adamw> seems like hoyang's remaining issue is to do with the completeness or otherwise of a kickstart...doesn't look terribly blockerish
19:10:24 <adamw> should we drop this from blocker status as the main issue got fixed?
19:10:36 <kparal> I think we should re-test quickly
19:10:38 <kparal> should be easy
19:10:44 <kparal> I can do it
19:10:52 <bcl> his ks isn't a reliable test.
19:11:06 <adamw> well, if you look at the comments, seems like bcl and hoyang can reproduce the specific issue hoyang is seeing, but it requires a kickstart bcl considers incomplete
19:11:19 <bcl> I'm not sure what's missing from it, but it needs something else.
19:11:20 <adamw> i think we can leave them to kick it back and forwards but it doesn't really look like a big blocker any more
19:11:35 <kparal> if it has 'reboot' it should reboot, right?
19:11:49 <adamw> probably...is that a blocker though?
19:11:53 <bcl> yep, and it does. the problem I had with it was the boot didn't finish.
19:12:15 <adamw> the issue now is clearly different from the bug as initially filed, anyhow
19:12:32 <adamw> it's now 'this specific kickstart which worked with f16 doesn't complete post-install boot with f17'
19:12:53 <kparal> ok, makes sense. but advice to file a new bug if he sees one
19:13:01 <adamw> yeah, it might be better to split this off
19:13:06 <adamw> bcl: do you agree?
19:13:57 <bcl> yep.
19:14:01 <adamw> okay
19:14:06 <adamw> brb, i have to pick up a parcel from downstairs
19:14:07 <adamw> back to nyan cat
19:18:45 <adamw> #agreed 787461 has morphed into a much less serious bug than initially reported, let's re-close it and ask hongqing to report his bug as a new one
19:19:01 <adamw> #topic http://bugzilla.redhat.com/show_bug.cgi?id=787893
19:19:01 <buggbot> Bug 787893: urgent, unspecified, ---, bcl, ON_QA, Anaconda needs to handle /usr move preparation on upgrade for F17
19:19:11 <kparal> needs testing
19:19:25 <bcl> yep. should be working.
19:19:28 <adamw> yeah, 17.12 went into beta tc1 so we should be able to test
19:19:44 * adamw has a new hat
19:19:55 <bcl> I'd done f15 and f16 with /usr upgrade w/o problems.
19:20:04 <kparal> which color?
19:21:30 <adamw> black.
19:21:50 <adamw> #info fix for 787893 is in Beta TC1 and needs testing - simple f16 to f17 upgrade test should be enough
19:22:02 <adamw> #topic http://bugzilla.redhat.com/show_bug.cgi?id=796155
19:22:03 <buggbot> Bug 796155: unspecified, unspecified, ---, rvykydal, NEW, iface_ip2str returned NULL
19:22:13 * kparal expected red
19:22:16 <adamw> kparal: http://www.johnhelmer.com/prod.itml/icOid/161
19:23:14 <adamw> so, i think this one's back on anaconda team, as we've reproduced with beta tc1
19:23:19 <adamw> bcl: are you tracking this one?
19:23:52 <bcl> I'd have sworn I saw a fix for this on the list, but couldn't find it yesterday.
19:24:01 <bcl> This will go away with the noloader change.
19:24:05 <adamw> i am confident!
19:24:07 <adamw> noloader still isn't landed?
19:24:13 <adamw> we'd probably like to have it in asap
19:24:14 <bcl> not quite yet.
19:25:04 * kparal is watching TED
19:25:05 <adamw> #info bcl says this bug should go away with the landing of noloader, which will happen Real Soon Now: ball is in anaconda team's court on this one
19:25:13 <adamw> kparal: stop that and watch nyan cat immediately
19:25:21 <adamw> okay, two more to go
19:25:24 <adamw> #topic http://bugzilla.redhat.com/show_bug.cgi?id=798373
19:25:25 <buggbot> Bug 798373: unspecified, unspecified, ---, mgracik, ON_QA, live image failed to boot in 3 runlevel
19:25:50 <kparal> hey, I verified that one
19:25:50 <adamw> so we have a a fix for this but it needs pushing stable, probably didn't make tc1
19:25:57 <adamw> i should have asked for it to be pulled into tc1 compose, my bad
19:26:02 <kparal> only me as it seems
19:26:16 <adamw> #info 798373 fix is in and tested by kparal but needs to be pushed stable and added to beta tc2 compose
19:27:25 <adamw> #topic bugzilla.redhat.com/show_bug.cgi?id=754568
19:27:27 <adamw> last one!
19:27:41 <adamw> not much news here, we probably need to ping ajax to work on it
19:27:46 <adamw> anyone have any fresh info?
19:28:03 * pschindl has to go, and wish to everyone a nice weekend
19:28:12 <kparal> pschindl: see you
19:28:22 <kparal> I don't have any news
19:28:29 <kparal> I reverted to VNC
19:29:59 <adamw> okay
19:30:08 <adamw> #action adamw to bug ajax about 754568
19:31:01 <adamw> and i think that's all she wrote
19:31:05 <adamw> everyone asleep yet?
19:31:13 * nirik snores.
19:31:17 <adamw> #info 754568 no movement from developer
19:31:23 * adamw empties nirik's pockets
19:31:27 * adamw freaks out and calls the cops
19:31:31 <nirik> :)
19:31:46 <kparal> what a short meeting today
19:31:54 <kparal> let's repeat
19:31:54 <adamw> a mere stripling of a 2.5hr meeting
19:31:58 <adamw> yeah!
19:32:04 <adamw> #topic roll call
19:32:06 <adamw> :P
19:32:22 <adamw> #agreed meeting was unacceptably short. let's not make that mistake again.
19:32:45 <brunowolff> I'm here now, but missed over an hour in the middle.
19:32:47 <adamw> #topic open floor
19:33:02 <adamw> anyone have any issues to bring up that haven't come up yet?
19:33:07 <adamw> you have 10 seconds to speak. ;)
19:33:30 <kparal> damn, missed it. next time
19:34:07 <adamw> thanks for coming everyone
19:34:08 * kparal raises his hand and flies away
19:34:23 <adamw> same time, same place, next week
19:34:32 <brunowolff> Overall F17 is working pretty well for me. I switch my home server over to F17 this week. Some glitches, but nothing I'd call a blocker.
19:34:39 <adamw> you're insane!
19:34:54 <adamw> #endmeeting