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