16:03:05 <adamw> #startmeeting Fedora 13 Alpha blocker bug review #3
16:03:06 <zodbot> Meeting started Fri Feb 19 16:03:05 2010 UTC.  The chair is adamw. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:03:07 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:03:31 <Oxf13> I'm here, on another call too
16:03:37 * maxamillion is here ... sorry I'm late
16:04:35 <adamw> alright, let's get going, with the dulcet tones of Tiger in the background
16:04:55 <jeff_hann> :P
16:05:24 <adamw> #topic https://bugzilla.redhat.com/show_bug.cgi?id=557386
16:05:41 <adamw> alright, this is abrt/kernel again
16:06:12 <adamw> chatter i've noticed this week seems to indicate it's fixed
16:06:24 <jlaska> it's in MODIFIED now, so that's a good sign
16:06:57 <adamw> from the looks of comments 8/9 we should re-assign to abrt
16:07:19 <jlaska> is that captured in another bug already on the list ...
16:08:15 <jlaska> 566460
16:08:16 <adamw> i don't believe so
16:08:45 <adamw> that looks like something new/different
16:09:03 <jlaska> yeah
16:09:21 <adamw> so i think perhaps the first bug should be assigned to abrt, but depending on this bug?
16:09:21 * jlaska looks in https://admin.fedoraproject.org/pkgdb/packages/bugs/abrt?_csrf_token=9f092d288101fe29f222eb7df98274ab5ee97a6f
16:09:56 <jlaska> nothing jumps out as being already filed to track that change
16:10:29 <jlaska> okay ... so there is some more work needed
16:10:46 <jlaska> do we have a sense if that should be on the F13Alpha list?
16:11:10 <jlaska> I don't see Jiri around, perhaps we can pull in nhorman
16:11:45 <adamw> go for it
16:12:24 <maxamillion> jlaska: *random* side note on that, I got "scolded" recently for posting a link that included the csrf token .... just a though for future reference :)
16:13:02 <jlaska> maxamillion: oh boy, thanks for the heads up
16:13:02 <adamw> jlaska: i think the second bug is essentially the same in character as the first - a breakage in the kernel which stops abrt from being able to work
16:13:20 <maxamillion> jlaska: anytime
16:13:33 <jlaska> my understanding of the second is that it impacts only c/c++ apps
16:13:46 <jlaska> which ... is most of the desktop
16:13:54 <maxamillion> is abrt not being functional considered an alpha blocker? (just curious)
16:14:00 <jlaska> okay, nhorman said he'd join shortly
16:14:17 <adamw> maxamillion: we decided it was for 557386
16:14:44 <adamw> maxamillion: the main issue is that if abrt is broken due to the kernel, people testing the live images can't possibly file abrt reports
16:14:57 <maxamillion> adamw: ah, makes sense
16:15:01 <jeff_hann> adamw: regarding the 2nd bug, do you see it as a bug in the kernel?
16:15:09 <jeff_hann> or in abrt?
16:15:26 <adamw> jeff_hann: it's clearly a kernel bug
16:15:36 <adamw> look at the reproduction steps, it doesn't involve abrt at all
16:16:05 <jeff_hann> hmmm
16:17:34 <jeff_hann> wait a moment
16:18:19 <adamw> #agreed 557386 is back with abrt team but probably depends on 566460
16:18:22 <jeff_hann> yes, adamw, you were right
16:18:30 <adamw> #topic https://bugzilla.redhat.com/show_bug.cgi?id=566460
16:18:35 <jeff_hann> my mind was wondering
16:18:36 <adamw> (since we're talkin about it anyway)
16:19:07 <jlaska> so this is the second bug, right?
16:19:28 <jlaska> I added this to the list for discussion since it seems to match the criteria used for the previous bug
16:19:30 <jeff_hann> yea
16:19:39 <adamw> yeah
16:19:49 <jlaska> but definitely wanted additional input
16:19:58 <adamw> shall we quickly discuss another one while we wait for nhorman?
16:20:08 <jlaska> adamw: sure, no objections
16:20:31 <adamw> #agreed suspending discussion on 566460 while we wait for nhorman
16:20:33 <adamw> #topic https://bugzilla.redhat.com/show_bug.cgi?id=560477
16:21:21 <jlaska> I propsed this since it touches point#10 of the Alpha criteria
16:21:32 <jeff_hann> was this tested with a more recent anaconda?
16:21:35 <jlaska> it's in MODIFIED, and I've confirmed the fix with an updates.img, just waiting for an official build
16:21:39 <adamw> sure, we discussed it last week
16:21:41 <maxamillion> it appears to have a patch mentioned in the bug
16:21:53 <jeff_hann> 04.02, right?
16:22:13 <adamw> jlaska: could you add a comment to say you've tested with updates.img btw? your last comment doesn't say that
16:22:14 <jeff_hann> if it's still not fixed, we'll see
16:22:35 <jlaska> adamw: I can do that ... just fyi ... I'm not posting feedback in any of my MODIFIED bugs until the build is available for test
16:22:42 <jlaska> but I'll note that now in the bz
16:22:55 <adamw> ah k
16:23:11 <adamw> it would be useful to know that the updates.img had worked, though, just so we know where we're up to
16:23:28 <jlaska> good point
16:23:31 <jlaska> okay, posted
16:23:34 <adamw> ok
16:23:45 <adamw> so basically we're happy with the situation of this one as we're just waiting for the next build point, right?
16:23:51 <jlaska> yeah
16:24:22 <adamw> #agreed 560477 is probably fixed, waiting for next anaconda build to confirm fix
16:24:33 <adamw> #topic https://bugzilla.redhat.com/show_bug.cgi?id=562209
16:25:02 <jlaska> puff of smoke ... and nhorman appears
16:25:04 <nhorman> jlaska, sorry, was in a mtg w/ lwang
16:25:11 * nhorman choughs
16:25:13 <nhorman> :)
16:25:14 <jlaska> nhorman: no worries, thanks for joining
16:25:15 <adamw> aha, okay, re-topicing
16:25:25 <nhorman> jlaska, what are we trying to solve here?
16:25:27 <adamw> #agreed resuming 566460 discussion
16:25:33 <adamw> #topic https://bugzilla.redhat.com/show_bug.cgi?id=566460
16:25:56 <jlaska> nhorman: we are discussing F13 Alpha blocker potential for /topic bug
16:25:58 <nhorman> ah, this jem
16:26:13 <adamw> nhorman: we just want an update basically
16:26:17 <jeff_hann> downloading the iso to test a bit in KVM
16:26:24 <adamw> as we understand it this is another kernel problem which makes it impossible for abrt to work, right?
16:26:28 <adamw> (can't do much without a core dump)
16:26:51 <nhorman> adamw, yeah.....sort of....
16:27:02 <adamw> do elaborate :D
16:27:03 <nhorman> I can give the medium sized story w/ backround if you like
16:27:05 <nhorman> :)
16:27:06 <adamw> sure
16:27:47 <nhorman> so....setting asside the snit that jmoscovk and I got into over it, basically 6 months ago I changed how kernel coredump to pipe worked to fix a race/bug/oops
16:28:05 <adamw> um, remember this is 566460 not 557386
16:28:15 <nhorman> adamw, I know, they're related
16:28:21 <adamw> ah k
16:28:27 * adamw shuts up again
16:28:34 <nhorman> to continue, that change hit rawhide and abrt broke
16:29:15 <nhorman> we have two solutions, the one which I recommended, and jmoscovk implemented in user space, and the one which I promised to try and push through upstream in the kernel
16:29:38 <nhorman> I was figuring no one would want the kernel solution, since its a bit wierd....and that the user space solution would stick
16:29:41 <nhorman> I was wrong :)
16:30:01 <nhorman> the kernel solution was successful, and I pulled it back to rawhide....and there was moderate rejoicing
16:30:12 <adamw> hehe
16:30:41 <nhorman> unfortunately, to do the backport I had to suck in some other work from andi kleen in the same area that seems to have busticated core_pipe_limit somehow
16:30:47 <nhorman> hence bz 566460
16:31:19 <adamw> ah, okay.
16:31:23 <nhorman> I'm confident I can fix it given enough time (I just don't know how much time I have)
16:31:27 <adamw> so it's a kernel bug but you broke it =)
16:31:27 <nhorman> when is f13 deadline?
16:31:38 <adamw> https://fedoraproject.org/wiki/Releases/13
16:32:16 <adamw> alpha is 'frozen' now but blocker fixes can go in up until...probably the go/no-go
16:32:21 <adamw> which is on 2010-02-24
16:32:45 <adamw> if this doesn't get fixed, abrt is effectively broken, right?
16:33:04 <Oxf13> 13 is essentially frozen until we hit GA
16:33:29 <nhorman> adamw, well, I think thats a question for the abrt guys.  you can still get cores, you just can't access the /proc/pid of a crashing process when you get it
16:33:39 <nhorman> don't know how much they depend on that
16:33:42 <jlaska> no capture of c/c++ apps
16:34:04 <adamw> euf, so a question for jmoskovc after all...do we have any other abrt contacts?
16:34:27 <nhorman> how can they be that reliant on gathering information out of /proc/pid?  Its almost all completely available in the core itself
16:34:31 <nhorman> *sigh*
16:34:39 <adamw> i don't know if they are, that's what we'll ask them
16:34:54 <nhorman> ok, so reading this schedule 3/2 is the alpha freeze?
16:35:17 <adamw> no, that's when the alpha is released.
16:35:40 <nhorman> ah, alpha freeze was....2 days ago
16:35:41 <nhorman> great
16:35:41 <adamw> alpha is already frozen, as I said, since 16th. but fixes for critical issues get in.
16:35:58 <nhorman> ok, so exactly how long do I have to fix this jem?
16:36:09 * Oxf13 notes that the wiki pages and schedules and freeze pages are slightly outdated due to no frozen rawhide
16:36:26 <Oxf13> nhorman: you do a build in F-13, you push it into bodhi for updates-testing, and if it solves the issue we can push it stable
16:36:50 <jlaska> adamw: Can't find Jiri, but asking kklic
16:36:55 <adamw> Oxf13: jlaska: would you agree with 'up until the go/no-go'?
16:36:55 <nhorman> so basically, just fix it asap?
16:37:01 <nhorman> jlaska, he's in bed by now
16:37:18 <jlaska> nhorman: in bed by 6pm, early sleeper :)
16:37:36 <jlaska> adamw: that doesn't resolve the live image scenario?
16:37:38 <nhorman> jlaska, well, home at least, brno office is getting a 3rd floor added to it
16:37:44 <jlaska> nhorman: right
16:37:47 <nhorman> no one can work through the noise after they start construction :)
16:37:54 <adamw> jlaska: i mean *alpha* go/no-go
16:38:28 <Oxf13> adamw: what is the question again?
16:38:28 <jlaska> adamw: right ... so that's too late for testing
16:39:09 <adamw> Oxf13: how long does nhorman have to fix this to get it in alpha
16:39:33 <Oxf13> it should be tested in updates-testing and then tagges table by go-nogo
16:39:38 <adamw> ok
16:39:50 <nhorman> so when is the go/nogo descision made?
16:39:52 <adamw> of course, if we consider it a blocker, we ought to delay the alpha if it's not fixed. that depends on what abrt tell us
16:40:02 <adamw> nhorman: 24th.
16:40:02 <jlaska> kklic: thanks for joining!
16:40:45 <nhorman> adamw, ok, that works.  I'll start hammering on it this afternoon. with any luck, I can have it fixed by wed. of next week or so
16:41:01 <nhorman> I'd like to get the fix upstream first, but it sounds like we're going to have to do this in parallel to make the schedule
16:41:02 <adamw> nhorman: 24th *is* wednesday
16:41:14 <adamw> nhorman: we'd need to have it available for testing on 23rd probably to test it
16:41:16 <Oxf13> it'd need to get into updates-testing a day or 3 before that
16:41:25 <adamw> but, we need to ask kklic...
16:41:32 <adamw> kklic: does https://bugzilla.redhat.com/show_bug.cgi?id=566460 stop abrt from working?
16:41:36 <adamw> or can abrt work around it?
16:43:15 <kklic> adamw: I need a minute or two to check the source code
16:44:04 <adamw> ok
16:44:06 <adamw> we'll wait
16:45:04 <jlaska> adamw: I have to step out in 16 minutes ... but you can put me down to update all the installer MODIFIED bugs as you suggested with the previous installer issue
16:45:36 <adamw> jlaska: ok, so basically all your installer bugs in modified are in the same state? probably fixed, waiting for next anaconda drop to confirm
16:46:11 <jlaska> yeah, I've been maintaining a mega-updates.img that has all the fixes planned for the next build of anaconda
16:46:44 <jlaska> there's only 1 unresolved issue that concerns me from our TC2 testing for the alpha
16:47:33 <jlaska> ^---> 562209
16:47:43 <adamw> let's talk about that one then, while kklic is looking...
16:47:56 <adamw> #agreed kklic is checking out 566460, going to discuss another bug for now
16:47:59 <adamw> #topic 562209
16:48:02 <kklic> That #566460 basically prevents ABRT from catching C/C++ cratches
16:48:12 <adamw> gah!
16:48:16 <jlaska> doh!, sorry Adam :(
16:48:21 <adamw> #topic https://bugzilla.redhat.com/show_bug.cgi?id=566460
16:48:23 <adamw> :P
16:48:28 <kklic> :)
16:48:46 <adamw> kklic: nhorman says:
16:48:47 <adamw> <nhorman> adamw, well, I think thats a question for the abrt guys.  you can still get cores, you just can't access the /proc/pid of a crashing process when you get it
16:48:53 <adamw> <nhorman> how can they be that reliant on gathering information out of /proc/pid?  Its almost all completely available in the core itself
16:48:53 <adamw> *sigh*
16:49:03 <adamw> so abrt does need the /proc/pid ?
16:50:28 <kklic> yes, we read data from /proc/pid, it cannot be changed easily afaik
16:50:52 <adamw> okay...so we need the kernel side fix
16:51:04 <adamw> given the tight timelines it'd be great if you could do anything to help nhorman with the kernel side
16:51:10 <nhorman> ok, so I need to get that fixed, I'll try focus on it this afternoon.  With any luck, it won't be too convoluted to figure out
16:51:17 <kklic> we read cwd, stat, cmdline, exe, limits(?)...not sure how much work would it be to find all that stuff in the coredump
16:51:22 <adamw> nhorman: would it help to have more eyes on it?
16:51:30 <adamw> nhorman: if we could ask for any other kernel devs to help out?
16:52:01 <nhorman> adamw, I really can't say right now to be honest
16:52:05 <adamw> ok
16:52:18 <adamw> well do let us know if you feel like you're running into a wall as we'll have to try and do something about it :)
16:52:19 <nhorman> I have a feeling its just going to be dumping a few printks into the kernel to figure it out
16:52:34 <nhorman> kklic, unless you are intimately familiar with how the coredump path works in the kernel?
16:52:38 * nhorman asks hopefully :)
16:53:23 <adamw> #agreed 566460 should be a blocker, must be fixed kernel side, nhorman will try and fix it in time to be tested before go/no-go
16:53:25 <kklic> nhorman: no experience with kernel, sorry
16:53:47 * nhorman makes a note to himself to _never_ touch the coredump path again
16:54:05 <adamw> hehe
16:54:08 <maxamillion> lol
16:54:18 <adamw> okay, i think we've covered that one...nhorman please do keep us up to date ;)
16:54:36 <adamw> #topic https://bugzilla.redhat.com/show_bug.cgi?id=562209
16:54:39 <adamw> jlaska: still around?
16:54:41 <nhorman> adamw, ok
16:54:42 <jlaska> you bet
16:54:51 <adamw> thanks a lot nhorman / kklic
16:54:59 <nhorman> np
16:55:09 <adamw> so what's the story on 562209 jlaska
16:55:33 <jlaska> well .. it affects any ISO boot scenarios (boot.iso, CD and DVD)
16:55:33 <jeff_hann> adamw: the latest boot.iso has anaconda 13.25
16:55:50 <jlaska> the bug prevents access to any network package repositories
16:55:53 <jeff_hann> but the latest in repos is 13.27
16:55:55 <jlaska> which is the default case for boot.iso
16:56:27 <jlaska> so I think this fits well into the Alpha release criteria
16:56:38 <adamw> yeah, it does, boot.iso is supposed to work
16:56:42 <jlaska> there is a workaround ... add the boot argument "updates="
16:56:52 <jlaska> but that's messy and no one will use it for this common case
16:56:57 <jlaska> clumens updated the bug with several options this morning
16:57:21 <jlaska> I think the devs need to choose an option forward
16:57:32 <jlaska> I can ask clumens + skvidal to join if that would help move things forward
16:57:37 <adamw> "This means no connection sharing, though." - don't quite understand that
16:57:41 <adamw> yeah it would be good
16:57:56 <jlaska> adamw: that's just internals of how they are passing around the libcurl network object
16:58:04 <jlaska> vs having to reinstantiate the connection every time
16:58:23 <adamw> so it's inelegant but not fundamentally going to break anything?
16:58:29 <adamw> it reads like 1) is the best option, certainly for alpha
16:58:40 <jlaska> yeah, this issue might need a short-term, then a long-term fix
16:58:52 <skvidal> what's up?
16:59:06 <jlaska> hey skvidal, thanks for joining
16:59:18 <jlaska> looking over clumens feedback in bug#562209
16:59:40 <jlaska> clumens: welcome to the party
17:00:20 <skvidal> woo hoo
17:00:43 <jlaska> so ... just trying to get an understanding of how to move forward on this bug
17:00:53 * adamw passes around the weak lemon punch
17:01:33 <adamw> clumens: skvidal: we're coming down to the wire on alpha so we need to decide and approach and test a fix fairly quick
17:02:25 <skvidal> clumens: I'll work on whatever you prefer, here. - though a 'drop and reinit' option to urlgrabber is probably easiest
17:02:44 <clumens> skvidal: i am okay with that
17:02:55 <skvidal> clumens: and given curl's tendency toward 'odd' behavior it'll probably be needed elsewhere
17:03:18 <clumens> yeah, joy
17:03:22 <skvidal> before I d
17:03:23 <skvidal> o
17:03:26 <skvidal> and just b/c I want to be sure
17:03:37 <skvidal> we can reliably repeat this, right?
17:03:50 <clumens> i can do it in anaconda every time
17:03:56 <jlaska> skvidal: yeah
17:04:19 <skvidal> clumens: and when curl is not built with c-ares the problem still exists, right?
17:04:32 * jlaska has to run to conflict ... will catch up after
17:04:42 <skvidal> b/c it looks like in comment 24 on the bug
17:04:47 <skvidal> that w/o c-ares it works
17:05:04 <skvidal> so if we can just rebuild curl and have it all work - well, yay
17:05:08 <Oxf13> I think that depends on what other thing it uses, and whether or not someting calls glibc res_init() after resolv.conf changes
17:05:26 <Oxf13> there may very well be something triggering a res_ini(), but since curl doesn't currently use glibc, that does nothing for it
17:06:04 <clumens> skvidal: looks like if we rebuilt curl to use the same linker as the rest of the universe, we'd still have to call res_init in anaconda.
17:06:15 <skvidal> ok
17:06:16 <clumens> but that's not such a big deal.
17:06:49 <Oxf13> it's something we should probably do anyway
17:07:52 <adamw> ao again, whatever's being done, we'd want it available for testing by tuesday at latest
17:08:06 <skvidal> so is this the plan:
17:08:13 <skvidal> 1. rebuild curl w/o c-ares
17:08:20 <skvidal> 2. call re_init() in anaconda?
17:08:22 <skvidal> or
17:08:26 <skvidal> is it:
17:08:41 <skvidal> 1. write a 'restart_curl_obj' method to urlgrabber
17:08:47 <skvidal> 2. call that from anaconda
17:09:03 <adamw> 5. profit
17:09:45 <skvidal> either way we require modifying one pkg + anaconda
17:09:49 <clumens> seems to me that the rebuild curl plan is likely to turn up additional weirdness.
17:10:16 <skvidal> okay, then I'll shelve the other things I was doing and work on a patch to urlgrabber
17:10:40 <clumens> and i'll be standing by to test
17:10:45 <adamw> as will jlaska
17:10:53 <adamw> and i agree, i was hoping someone else would say that :)
17:11:01 <adamw> rebuilding curl this close to alpha wouldn't make me warm and fuzzy
17:11:32 <skvidal> oh but adding code to urlgrabber
17:11:34 <clumens> (though that really is the right fix.  what the hell, use the same resolver as everyone else.)
17:11:35 <skvidal> that's okay
17:11:37 * skvidal boggles
17:12:21 <Oxf13> so, there is probably planA for alpha, and planB for after alpha
17:12:30 <jeff_hann> +1
17:12:37 <Oxf13> planB should be the 'make curl use the same damn resolver as everything else'
17:12:38 <wwoods> switching curl's resolver library is something you probably want a little more lead time on
17:13:13 <adamw> #agreed 562209 for now will be handled by having urlgrabber be able to reinit connections, skvidal will work on this, clumens and jlaska will test
17:13:30 <wwoods> but the urlgrabber thing is a temporary band-aid until then, right?
17:13:38 <adamw> #agreed post-alpha a more 'correct' fix may be put in place
17:13:43 <wwoods> big fat "REMOVE THIS AFTER CURL STOPS BEING CRAZY" comments and all?
17:14:45 <adamw> thanks folks...
17:14:54 <adamw> anyone have anything else on this bug, or next bug?
17:16:45 <adamw> okay, next bug then
17:16:52 <adamw> #topic https://bugzilla.redhat.com/show_bug.cgi?id=563212
17:17:53 <adamw> this is the intel bug. we can probably close it now. uh, if -4 is definitely in the f13 repos after the big exciting switchover
17:19:12 * adamw goes to check. manually, since his yum config appears to be totally useless at present.
17:20:16 * Oxf13 is still working on getting the 13 directory published
17:20:37 <adamw> yup, -4 is in the 13 tree. so I think we can close this, since there's multiple confirmations in the bug that -4 is okay
17:20:38 <jeff_hann> it's 4, alright, adamw
17:20:45 <adamw> and we were pretty confident about what caused it and how to fix it anyway
17:20:55 <adamw> any objections?
17:21:23 <adamw> ok!
17:21:28 <adamw> #agreed 563212 is fixed, closing
17:21:58 <adamw> #topic https://bugzilla.redhat.com/show_bug.cgi?id=565306
17:22:21 <adamw> damn, we lost clumens
17:22:33 <adamw> given that jlaska was able to create an updates.img i assume this should be fixed in next anaconda drop
17:22:36 <adamw> anyone know?
17:24:46 <adamw> well, let's figure it is. :)
17:25:08 <adamw> #agreed 565306 should be fixed in next anaconda drop, jlaska will test
17:25:10 <adamw> #topic https://bugzilla.redhat.com/show_bug.cgi?id=565497
17:25:42 <adamw> this is fixed by the updated pl-parser, I believe
17:25:49 <adamw> obviously jlaska didn't get around to retesting
17:26:57 <adamw> i have a totem-pl-parser installed with the correct gmime dependency. so this is fixed. closing.
17:26:58 <wwoods> what a lazy bum!
17:27:20 <adamw> yeah, he sucks :)
17:27:28 <adamw> #agreed 565306 is fixed by updated totem-pl-parser, closing
17:27:45 <adamw> okay, so now we have a chunk of MODIFIED anaconda bugs:
17:28:05 <adamw> 565592, 565599, 565611, 565639, 565840, 565873
17:28:34 <adamw> jlaska says all of these should be fixed in next anaconda drop
17:28:42 <adamw> and he's just waiting on that to confirm and close them
17:28:51 <adamw> does anyone want to go through them individually or should we just take that as OK?
17:30:03 <adamw> *crickets*
17:30:11 <jeff_hann> :P
17:30:32 <adamw> okay, we'll just leave 'em
17:30:38 <adamw> #topic 565592, 565599, 565611, 565639, 565840, 565873
17:30:53 <adamw> #agreed these are all anaconda bugs which have been patched but no new anaconda build has been made to test them yet
17:31:13 <adamw> #agreed we will re-test and confirm the fixes after the next anaconda drop
17:31:19 <adamw> #topic open floor
17:31:24 <adamw> anyone have any other bugs to bring to the party?
17:32:05 <jeff_hann> adamw: was the bug regarding installing a minimal system pulls unwanted deps fixed?
17:32:23 <adamw> jeff_hann: don't know off the top of my head
17:32:28 <adamw> ...heh.
17:33:44 <jeff_hann> sorry, timed out
17:35:06 <adamw> jeff_hann: i don't know that bug off the top of my head
17:35:09 <adamw> do you have the number?
17:35:21 <jeff_hann> nope :(
17:35:51 <jeff_hann> but it's exactly what I'm doing now with boot.iso (rawhide) in KVM
17:35:59 <adamw> uf.
17:36:12 <adamw> i don't believe minimal install is in the alpha criteria...
17:36:24 <jeff_hann> I'm sure it isn't
17:36:30 <jeff_hann> just a quirk of mine
17:36:41 <adamw> it is something it'd be nice to have working, though, yeah
17:37:00 <jeff_hann> well, working on it and will file a bug or smth.
17:37:04 <jeff_hann> if need be
17:38:42 <adamw> ok, thanks
17:38:52 <adamw> any other business?
17:39:29 <adamw> okey dokey, thanks everyone
17:39:37 <adamw> #endmeeting