[11:54]  * persia prepares
[11:55] <amachu> persia: elkbuntu: TheMuso: lifeless: Hi every body!
[11:55] <TheMuso> Hey amachu.
[11:55] <TheMuso> It appears we have nobody on the agenda.
[11:56] <amachu> Hi TheMuso :-)
[11:56] <amachu> belutz had mailed that he might join!
[11:57] <persia> Nobody on the agenda might mean a short meeting.  Did we get more thoughts on timing/composition that I missed?
[11:57] <amachu> next week is the right time we take what we discussed last week on time and additional members on board to the CC!
[11:58] <persia> Indeed.
[12:00] <amachu> persia: not much to those what we discussed, may be TheMuso, lifeless can add their thoughts
[12:00] <amachu> for yourself, me and elkbuntu three were discussing on that much!
[12:00] <TheMuso> I have nothing to add. I can do earlier in the evening, but not later. However I know this affects others, so really don't know.
[12:00] <persia> Or belutz or zakame
[12:01] <TheMuso> All I can say is name a time, and I'll say yes or no as to whether I can do it.
[12:01] <persia> TheMuso, The proposal was for 9:00 and 15:00 UTC.  Would the former work for you (on Tuesdays)?
[12:02] <TheMuso> persia: 9:00UTC would suit me very nicely.
[12:03] <persia> TheMuso, That's what was thought, that it would be better for those in +10 or greater, whereas 15 would be better for those in +7 or less.  Those in +8 or +9 probably find the current time very convenient.
[12:03] <amachu> persia: 15.00 would suit Indian time, 9.00 might suit others better..
[12:03] <amachu> persia: yes.. We need to check with belutz and zakame
[12:04] <amachu> let me check for the participant for the day :-)
[12:04] <amachu> amireldor?
[12:04] <amachu> svaksha?
[12:04] <amachu> stefanlsd?
[12:04] <amachu> it appears none of them is here!
[12:05] <TheMuso> I thought we had stefanlsd? approach us already...
[12:05] <TheMuso> gah cut and paste
[12:06] <amachu> should I go ahead and take names of svaksha and amireldor from the agenda for they aren't turning up for a long time? they can add themselves again when they wish to take part..
[12:06] <TheMuso> amachu: I say yes.
[12:06] <persia> I'd agree with that.
[12:06] <amachu> fine, I will do that..
[12:06] <amachu> elkbuntu: silent today?
[12:07] <amachu> and lifeless: show some life ;-)
[12:08] <elkbuntu> amachu, nearly forgot
[12:08] <amachu> elkbuntu: hmm...
[12:08] <persia> lifeless was nearly 23 hours early to the meeting, so may have become distracted.
[12:08] <amachu> elkbuntu: any comments on discussions so far?
[12:09] <elkbuntu> not quite caught up yet
[12:10] <elkbuntu> svaksha is online
[12:10] <elkbuntu> just not in here
[12:11] <elkbuntu> amachu ^^
[12:12] <amachu> svaksha online where?
[12:13] <elkbuntu> in #ubuntu-women
[12:13] <amachu> got her
[12:14] <elkbuntu> amachu, you might need to be blunt
[12:16] <amachu> elkbuntu: asking her!
[12:17] <amachu> good! I need to mail the list asking for opinions..
[12:17] <amachu> from belutz, zakame and lifeless
[12:19] <amachu> if belutz and zakame can turn out to meetings regularly then we new members to the board can be re-considered..
[12:19] <amachu> but I will mail first..
[12:19] <elkbuntu> i'd still like to see more on the board
[12:20] <amachu> Ok!
[12:21] <persia> I'm happy with the current board number if we don't have two meetings.  If we have two meetings, I want 9 comprised of 3 from the east, 3 from the west, and 3 from the middle.
[12:21] <elkbuntu> because even if belutz and zakame can turn out more reguarly, we've still got a high chance of not having the quorum
[12:22] <elkbuntu> which i believe is the same as what persia believes
[12:22] <persia> Yes.
[12:23] <elkbuntu> hi svaksha_, good to see you active.
[12:24] <amachu> persia: that sounds good to me too...
[12:24] <svaksha_> elkbuntu: i was never inactive, silent yes
[12:24] <elkbuntu> svaksha_, the word 'see' is the key
[12:25] <svaksha_> amachu asked if i was applying so for the record, i am not applying for reactivating the expired membership
[12:26] <persia> svaksha_, You're applying for new membership, or not applying at all?
[12:28] <svaksha_> persia: my membership expired in Aug, and i was thinking of reapplying (or whatever you call it) but i think i can volunteer  without  it too right?
[12:29] <elkbuntu> of course. else nobody would even *get* to membership ;)
[12:29] <amachu> svaksha_: you can.
[12:30] <persia> svaksha_, Certainly.  You're welcome to help without membership.  As a member, you get an email address, the right to carry business cards, and other benefits.
[12:30] <amachu> svaksha_: as said, ﻿ we were discussing removing your entry and amireldor's from the agenda for they were present for quite some time! and if you wish you can add yourself later..
[12:31] <svaksha_> persia: :)
[12:31] <svaksha_> amachu: sure
[12:31] <amachu> and We would be glad to see you back, if you aren't taking it up today..
[12:31] <svaksha_> :)
[12:32] <amachu> are you or not?
[12:32] <svaksha_> amachu: 13:28 < svaksha_> persia: my membership expired in Aug, and i was thinking of reapplying (or whatever you call it) but i think i can volunteer  without  it  too right?
[12:33] <svaksha_> amachu: not today
[12:33] <persia> svaksha_, Indeed.  So, we're going to remove you from the agenda, and you can add it back if you want to reapply at a later time.
[12:33]  * svaksha_ nods
[12:33] <persia> amachu, Do we have any other agenda items?
[12:34] <amachu> svaksha_: Ok. Keep contributing :-)
[12:34] <amachu> persia: No
[12:35] <amachu> elkbuntu: TheMuso: any other thing which you would like to discuss?
[12:35] <TheMuso> Not from me.
[12:35] <TheMuso> I've actually gotta run I'm affraid.
[12:35] <elkbuntu> can i discuss sleep? :Þ
[12:36] <Hobbsee> elkbuntu: no.  Sleep is forbidden.
[12:36] <elkbuntu> :(
[12:36] <TheMuso> so till later folks, and thanks/
[12:36] <persia> discussing sleep is pointless.  Good night :)
[12:36] <elkbuntu> cyas
[12:42] <lifeless> erg
[12:42] <lifeless> hai
[12:42] <Hobbsee> lifeless: and you missed it again.  But you were closer this time!
[12:42] <lifeless> Hobbsee: :(
[12:44] <persia> lifeless, What's your opinion on splitting the meeting and adding more members?
[12:49] <lifeless> persia: do you mean committee members?
[12:49] <persia> Yes.
[12:49] <persia> 3/3/3 and 9:00/15:00
[12:50] <lifeless> I think its a bit hard to service france and argentina at the moment :P
[12:50] <persia> Yeah, well, there is that :)
[12:51] <lifeless> but we rarely have so many applicants that we have to defer some
[12:51] <lifeless> so, other than being nice times for me, I don't see much motivation to change
[12:51] <lifeless> perhaps west asia is a little under-available time slot wise though
[12:52] <persia> Well, being nice times for all the other people in places like India, East Australia, and New Zealand.
[12:52] <lifeless> yah
[12:53] <persia> Personally, I think picking nice times for us (within the prescription of "evening") is the best way to service the region.
[12:53] <lifeless> asia is so damn wide
[12:54] <lifeless> its a bad way to assess time zone availability IMNSHO.
[12:55] <persia> I suppose.  I don't think of "Asia" as wide, but I don't think of Australia as part of "Asia".
[12:55] <persia> That makes it similar in width to London <-> Petersberg or Sao Paulo <-> Mountain View
[12:55] <lifeless> anyhow +1 on better times for the committee; if that makes it unavilable reasonably to folk in the nominated zone, then a separate committee to cover that region is needed IMO
[12:55] <lifeless> what tz is turkey?
[12:56] <persia> +3 or +4 I think.
[12:56] <persia> +3
[12:56] <persia> (but DST may apply)
[12:57] <persia> I'd claim that we're only responsible for +5 to +13 or so, but that's my personal opinon.
[12:58] <persia> (hrm, does NZ have a +13:15 at certain times of year, or does it only go up to +12:45?)
[15:59]  * kirkland waves o/
[15:59]  * mathiaz waves o//
[16:00] <zul> hello
[16:00] <nealmcb> o/
[16:00] <Koon> o--
[16:01] <mathiaz> welcome to the 33919023th edition of the Ubuntu Server Team meeting !
[16:01] <nxvl> \o\ /o/ \o\ /o/
[16:01] <mathiaz> let's get the show started
[16:01] <mathiaz> #startmeeting
[16:01] <MootBot> Meeting started at 10:01. The chair is mathiaz.
[16:01] <MootBot> Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE]
[16:01] <persia> It's not that.  It's about the 40th.  I may have lost count along the way, but not by that much.
[16:02] <mathiaz> Today's agenda: https://wiki.ubuntu.com/ServerTeam/Meeting
[16:03] <mathiaz> Last week's minutes: https://wiki.ubuntu.com/MeetingLogs/Server/20081007
[16:03] <mathiaz> [TOPIC] Bacula SRU
[16:03] <MootBot> New Topic:  Bacula SRU
[16:03] <mathiaz> zul: ^?
[16:03] <nxvl> persia: don't make us lose the joy
[16:03] <mathiaz> zul: I think it has been published?
[16:04] <zul> mathiaz: uploaded not accepted afaik yet
[16:04] <zul> ill bug pitti about it
[16:05] <mathiaz> zul: ok.
[16:05] <mathiaz> [TOPIC] Review ServerGuide for Intrepid
[16:05] <MootBot> New Topic:  Review ServerGuide for Intrepid
[16:05] <mathiaz> sommer: anything new?
[16:07] <mathiaz> ok - noone is there - moving on
[16:07] <mathiaz> [TOPIC] KVM
[16:07] <MootBot> New Topic:  KVM
[16:07] <mathiaz> kirkland: what's the update on virtio bugs?
[16:07] <kirkland> mathiaz: i'm chasing down the virtio disk bug
[16:07] <mathiaz> kirkland: there were two bugs: one related to network and one related to block device
[16:07] <kirkland> mathiaz: looks to be grub geometry
[16:08] <mathiaz> kirkland: IIRC the network virtio bug is fixed
[16:08] <kirkland> mathiaz: the disk geometry for virtio disks is wrong in grub
[16:08] <kirkland> mathiaz: i'm checking if any of the other distros have solved that yet
[16:09] <mathiaz> kirkland: ok - that may point to an issue with kvm on the host
[16:09] <sommer> mathiaz: sorry, nothing new :)
[16:09] <mathiaz> kirkland: or an issue with the kernel guest
[16:09] <mathiaz> sommer: ok - I'll try to send an update to the support section
[16:09] <kirkland> mathiaz: i was concentrating on the guest
[16:10] <mathiaz> kirkland: if this is an issue with the guest kernel we may be hit by the kernel freeze
[16:10] <nealmcb> this one? https://bugs.launchpad.net/bugs/281492
[16:10] <mathiaz> kirkland: that is scheduled for this thursday
[16:10] <mathiaz> nealmcb: yes
[16:11] <kirkland> mathiaz: i may need to employ some additional expertise on this
[16:11] <mathiaz> kirkland: let's assume we are not able to fix grub in time
[16:11] <mathiaz> kirkland: what are the options?
[16:12] <mathiaz> kirkland: should we emit a warning? add some code to check if /boot is on a vd* device?
[16:12] <kirkland> mathiaz: tell people to install using a plain disk, and after installation is done, use a virtio disk
[16:13] <mathiaz> kirkland: that means some more work to be done in the installer
[16:13] <mathiaz> kirkland: or in grub-install?
[16:14] <kirkland> mathiaz: i'm trying to fix it in grub, as i said
[16:14] <kirkland> mathiaz: grub-install writes a borked bootloader to the disk
[16:14] <kirkland> mathiaz: if we get a good bootloader on the disk, it boots fine
[16:15] <mathiaz> kirkland: right - I think it's the right to try to solve the issue
[16:15] <kirkland> mathiaz: but when the grub writes the bootloader to a /dev/vd* disk, it hoses the disk for booting
[16:15] <kirkland> mathiaz: that's in the installer, and in runtime
[16:15] <mathiaz> kirkland: However I'm wondering about contigency plan if we don't fix it in time for intrepid
[16:16] <mathiaz> kirkland: right - so grub-install would be the correct place to emit a warning if it tries to write on a vd* device
[16:16] <nijaba> o/
[16:16] <mathiaz> kirkland: you said you'd ask for help
[16:16] <kirkland> mathiaz: sure
[16:16] <jdstrand> kirkland: I'm somewhat confused-- if the backup plan is to install to /dev/hda, then change to firtio *after* install, won't the next invocation of grub (eg through a kernel update), mess up the mbr (or whatever is borked)?
[16:16] <mathiaz> kirkland: what kind of expertise would you require?
[16:17] <mathiaz> jdstrand: I don't think so
[16:17] <mathiaz> jdstrand: the next invocation of grub will just update menu.lst
[16:17] <kirkland> mathiaz: i was going to ask cjwatson and aliguori, unless you can point me to someone else
[16:17] <jdstrand> mathiaz: good point
[16:17] <mathiaz> jdstrand: however it would break the boot loader if grub itself was updated
[16:18] <jdstrand> mathiaz: or if the user played with grub-install manually
[16:18] <mathiaz> kirkland: I don't think of anyone else - it seems to be kernel related somehow
[16:19] <mathiaz> jdstrand: correct.
[16:20] <mathiaz> kirkland: ok - it seems you've some ressource to get things moving
[16:20] <mathiaz> kirkland: however keep in mind the kernel freeze on thursday
[16:20] <kirkland> mathiaz: I'm trying
[16:21] <mathiaz> kirkland: on thursday we may need to see if we should try to keep fixing grub or go with a contigency plan since it will be hard to fix the kernel if necessary
[16:22] <mathiaz> kirkland: other than this bug, is there anything else on kvm?
[16:22] <kirkland> mathiaz: have you verified the virtio networking fix?
[16:22] <mathiaz> kirkland: yes - it's working from me in a hardy host
[16:23] <mathiaz> kirkland: and on your side?
[16:23] <kirkland> mathiaz: i would like to mirror your test
[16:23] <mathiaz> kirkland: on a intrepid host?
[16:23] <kirkland> mathiaz: i could not get it working on Friday, but i think my invocation or setup might have been wrong
[16:23] <mathiaz> kirkland: ok - I'll outline my test after the meeting
[16:23] <kirkland> mathiaz: thanks
[16:24] <mathiaz> [ACTION] mathiaz to explain his virtio network test to kirkland
[16:24] <MootBot> ACTION received:  mathiaz to explain his virtio network test to kirkland
[16:24] <mathiaz> kirkland: anything on the virt-manager front?
[16:25] <kirkland> mathiaz: no
[16:25] <mathiaz> kirkland: ok - thanks for the update on the virtualization front
[16:25] <kirkland> mathiaz: sure
[16:25] <mathiaz> [TOPIC] JeOS
[16:25] <MootBot> New Topic:  JeOS
[16:26] <mathiaz> nijaba: so I've got all things sorted out
[16:26] <nijaba> yes, that's great.  I guess we need some testing now..
[16:26] <mathiaz> nijaba: the -virtual kernels are on the -server cd and the F4 option to install a minimal virtual machine has been added to the installer
[16:27] <mathiaz> nijaba: I'm going to test today's -server isos as they're the first ones shipping with the -virtual kernels
[16:27] <nijaba> so we have a full intergartion of the jeos installer in the server cd, coolio
[16:27] <mathiaz> nijaba: yop - however JeOS is not mentionned anywhere
[16:27] <nijaba> yes, and the first time we have a 64bit kernel for -virtual
[16:28] <mathiaz> nijaba: technically -virtual is just a -server kernel with a lot of modules not included
[16:28] <nijaba> JeOS has never been mentionned elswhere than in the docs, so that's ok
[16:28] <mathiaz> nijaba: well - JeOS was part of the iso name
[16:28] <mathiaz> nijaba: and part of the product name too
[16:29] <nealmcb> nijaba: ahh - 64bit kernel - nice
[16:29] <nijaba> mathiaz: yes, but better safe than sorry, right ;)
[16:29] <mathiaz> nijaba: I was wondering if it should be added to the F4 option some how
[16:29] <nijaba> well, do not worry too much about this, I'll put plenty of explanation on the web, wiki, etc...
[16:30] <nijaba> mathiaz: I think the wording you proposed is more self explanatory
[16:30] <mathiaz> nijaba: "Install a minimal virtual machine"
[16:30] <nijaba> JeOS seems to be confusing for some, they were often trying to install it on real hw
[16:31] <nijaba> mathiaz: yes, that's really clear
[16:31]  * nealmcb nods
[16:31] <nijaba> mathiaz I have added a couple test cases on the server test for qa, how can I get the tests added to qa.u.c?
[16:32] <mathiaz> nijaba: great - so we've got JeOS fully integrated in intrepid -server iso
[16:32] <mathiaz> nijaba: they should be added by tomorrow
[16:32] <mathiaz> nijaba: do we have access to ESX somewhere?
[16:32] <nijaba> I tried to ping heno but did not get a reply
[16:32] <nijaba> mathiaz: IS has one up and running
[16:33] <nijaba> you can request access to it, I guess
[16:33] <mathiaz> nijaba: hm - I don't know how
[16:33] <mathiaz> nijaba: I'll ask heno or cr3 about it
[16:33] <nijaba> ok, I'll email heno tonight
[16:34] <mathiaz> nijaba: does JeOS support xen also?
[16:34] <nijaba> nope
[16:34] <mathiaz> nijaba: only ESX and kvm are supported?
[16:34] <nijaba> the -virtual kernel is not a paravirt kernel
[16:34] <nijaba> mathiaz: officially, yes, but it could work elsewhere
[16:34] <mathiaz> nijaba: well -virtual is the -server kernel
[16:35] <zul> nijaba: umm what?
[16:35] <nijaba> just need a full virtualization env, not paravirt
[16:35] <mathiaz> nijaba: the -virtual kernel is not a different kernel build AFAIUI
[16:36] <mathiaz> nijaba: is just a sub-selection of the -server build
[16:36] <nijaba> mathiaz: right, and this is the issue, AFAIK, to run it in a paravirt env, no?
[16:37] <nijaba> zul: do you agree that we need a -xen kernel to run ubuntu as a paravirtualizatin guest?
[16:37] <mathiaz> nijaba: I'm not sure - I'm running intrepid -server kernel as kvm guests.
[16:37] <nijaba> mathiaz: kvm == full virtualization, as vmware and virtualbox
[16:37] <zul> nijaba: no, you can run xen paravirt stuff with the server kernel
[16:37] <mathiaz> nijaba: hm - ok
[16:38] <nijaba> zul: ah, ok, so the paraviort extension made it in the plain kernel
[16:38] <zul> nijaba: yep
[16:38] <nijaba> coolio
[16:38] <nijaba> I did not know that
[16:38] <mathiaz> zul: do you have access to a xen host ?
[16:38] <mathiaz> zul: in order to test JeOS in xen?
[16:39] <zul> mathiaz: I can quickly
[16:39] <mathiaz> nijaba: or we don't need to test on xen?
[16:39] <zul> xen is in universe though
[16:39] <nijaba> that would be nice if we could support it as well with -virtual
[16:40] <zul> I dont think it will work with virtual though it hasnt been tested though
[16:40] <nijaba> zul: xen host is, but we decided to officially support xen as a guest option for ubuntu
[16:40] <zul> nijaba: interesting..
[16:40] <nijaba> zul: dom0 ->  community, domU -> full maintenance
[16:41] <mathiaz> nijaba: which version of xen host should we test on then?
[16:41] <zul> nijaba: ok then, I just want to add the -virutal kernel needs to add the xen modules then
[16:42] <nijaba> zul: I am lost, do you need extension to the kernel or not to run in a xen env as a DomU?
[16:43] <zul> the extensions to the kernel, the way that it works is that it takes a list of modules from the server kernel and repackages them, afaik right now the xen block devices and network devices are not packaged with the -virtual kernel
[16:43] <zul> Ill send a patch to the kernel team mailing list today to get this fixed
[16:43] <mathiaz> zul: ok - so keep in mind the kernel freeze on thursday
[16:43] <nijaba> zul: ah, ok, we do not have the *modules*
[16:44] <nijaba> zul: so let's think about it for Jaunty
[16:44] <zul> mathiaz: I can submit the patch after I go vote ;)
[16:44] <nijaba> zul: too late, too risky, IMHO
[16:44] <mathiaz> zul: nijaba: ok - so we don't try to support xen guest in intrepid?
[16:45] <nijaba> zul: not with the virtual kernel
[16:45] <mathiaz> nijaba: zul: ok - let's  move on
[16:45] <mathiaz> nijaba: we can discuss that later
[16:45] <nijaba> sure
[16:45] <mathiaz> [TOPIC] python-vm-builder
[16:45] <MootBot> New Topic:  python-vm-builder
[16:45] <mathiaz> nijaba: you - again?
[16:46] <nijaba> mathiaz, actually to ask you to take a look at the current trunk
[16:46] <nijaba> ask you to review it and upload it if you think it is fit
[16:46] <mathiaz> nijaba: I thought kees uploaded it yesterday
[16:46] <nijaba> once uploaded, i need for somemone to test it a bit on xen + libvirt
[16:47] <nijaba> mathiaz: nope, that was a fix kirkland did for ubuntu-virt-mgmt
[16:47] <mathiaz> nijaba: ah ok then
[16:47] <mathiaz> [ACTION] mathiaz to look at sponsoring python-vm-builder
[16:47] <MootBot> ACTION received:  mathiaz to look at sponsoring python-vm-builder
[16:48] <mathiaz> nijaba: what's the url?
[16:48]  * ivoks hi
[16:48] <zul> nijaba: we should get poppy's fix in there as well
[16:48] <nijaba> mathiaz: https://code.launchpad.net/~ubuntu-virt/vmbuilder/trunk
[16:48] <mathiaz> nijaba: thnks.
[16:48] <nijaba> nope, thank you
[16:48] <mathiaz> nijaba: anything else on vm-builder?
[16:49] <nijaba> nope, apart from testing required...
[16:49] <nijaba> I implemented some missing function to support xen, but do not have a xen host
[16:50] <nijaba> zul validated that the fstab was ok, but nobody tested with libvirt
[16:50] <mathiaz> ok - so it seems we'd need access to ESX and xen environment to test both JeOS and vm-builder
[16:50] <nijaba> would be nice
[16:51] <mathiaz> ok - let's move on
[16:51] <mathiaz> [TOPIC] Open Discussion
[16:51] <MootBot> New Topic:  Open Discussion
[16:51] <mathiaz> ivoks: so what's on your plate this week?
[16:51] <ivoks> mathiaz: i've finished testing of drbd and rhcs, all fine (except one minor bug in drbd)
[16:52] <ivoks> mathiaz: i plan testing bacula during this week
[16:52] <mathiaz> ivoks: bacula in intrepid?
[16:52] <ivoks> mathiaz: right
[16:52] <ivoks> mathiaz: and if there is anything anyone needs help with, i would be glad to help
[16:53] <mathiaz> ivoks: ebox testing is still on my TODO list
[16:53] <ivoks> i guess squashing bugs :D
[16:53] <ivoks> mathiaz: i could do that...
[16:53] <zul> ivoks: if you need anything from me just poke me with a stick just not in the eye :)
[16:53] <mathiaz> ivoks: and preparing a FFe request for the motu release team
[16:53] <ivoks> zul: i'll poke you with a drbd patch
[16:53] <nijaba> :D
[16:53] <zul> ivoks: im expecting it :)
[16:54] <ivoks> mathiaz: FFE for motu?
[16:54] <mathiaz> ivoks: yes
[16:54] <ivoks> mathiaz: for ebox?
[16:54] <mathiaz> ivoks: it's a new upstream revision
[16:54] <ivoks> ok
[16:54] <ivoks> put me in for ebox testing
[16:54] <mathiaz> ivoks: so a FFe needs to be written and motu-release subscribed
[16:54] <ivoks> or.. sign me in
[16:54] <ivoks> mathiaz: i know
[16:55] <ivoks> mathiaz: could i squeez ipmitool update into that? :)
[16:55] <mathiaz> ivoks: https://launchpad.net/~ebox/+archive <- that's what needs to be reviewd and sponsored
[16:55] <mathiaz> ivoks: of course :D
[16:55] <ivoks> ok
[16:56] <ivoks> all right... lots of packages :)
[16:56] <mathiaz> ivoks: but only the modules that are already in hardy need to be looked at
[16:56] <ivoks> k
[16:56] <mathiaz> ivoks: that's about 2/3 of the listed packages IIRC
[16:57] <zul> mathiaz: are they still using courier-imap for their mail module?
[16:57] <mathiaz> zul: I don't know
[16:57] <pgraner> \
[16:57] <mathiaz> pgraner: is the kernel team meeting now?
[16:57] <mathiaz> pgraner: or in one hour?
[16:58] <ivoks> in an hour, imho
[16:58] <ivoks> iirc
[16:58] <pgraner> mathiaz: one hour,
[16:58] <mathiaz> ok
[16:58] <mathiaz> anything else to add?
[16:58] <pgraner> mathiaz: I typed in the wrong window :-(
[16:58] <mathiaz> pgraner: I thought you were making signs... ;)
[16:59] <ivoks> oh...
[16:59] <ivoks> if anyone needs virtual machine for testing, let me know - i have one just for that
[16:59] <pgraner> mathiaz: nope just stupidity on my part...
[16:59]  * nijaba needs to part.... catching a flight...  thanks all
[16:59] <ivoks> nijaba: have a good trip
[17:00] <mathiaz> [TOPIC] Agree on next meeting date and time.
[17:00] <nijaba> thanks ivoks
[17:00] <MootBot> New Topic:  Agree on next meeting date and time.
[17:00] <mathiaz> same time, same place, next week?
[17:00] <sommer> sure
[17:01] <ivoks> ok
[17:01] <ivoks> (i might be late again :/)
[17:01] <mathiaz> excellent then. See you all next week, same place same time
[17:02] <mathiaz> thanks for attending and happy testing!
[17:02] <mathiaz> #endmeeting
[17:02] <MootBot> Meeting finished at 11:02.
[17:02] <mathiaz> ivoks: as long as you show up for the Open Discussion topic it's all good ;)
[17:02] <sommer> thanks mathiaz, later all
[17:03] <ivoks> mathiaz: :D
[17:03] <ivoks> mathiaz: sorry... you know, there's that nice girl and all... :)
[17:59] <rtg> BenC: vesafb looks good so far.
[18:00] <pgraner> Hello Everyone its about time for the Kernel Team Meeting....
[18:00] <pgraner> Looks like we have everyone from the Canonical side so I guess we can get started
[18:00] <pgraner> #startmeeting
[18:00] <MootBot> Meeting started at 12:00. The chair is pgraner.
[18:00] <MootBot> Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE]
[18:01] <pgraner> [TOPIC] Welcome Jim
[18:01] <pgraner> I'd like to Welcome Jim to the kernel team as the newest Canonical hire!
[18:01] <MootBot> New Topic:  Welcome Jim
[18:01] <lieb> hi all
[18:01] <smb_tp> Hi jim
[18:01] <rtg> lieb: dood
[18:01] <cking> Hi Jim, welcome!
[18:01] <amitk> welcome Jim
[18:01] <ogasawara> hi Jim :)
[18:02] <pgraner> lieb: Glad to have you onboard!
[18:02] <pgraner> [TOPIC] Intrepid Status
[18:02] <MootBot> New Topic:  Intrepid Status
[18:02] <pgraner> LP #254923 HPA
[18:02] <pgraner> [LINK] http://lwn.net/Articles/301862/
[18:02] <MootBot> LINK received:  http://lwn.net/Articles/301862/
[18:02] <pgraner> This bug is showing up and has folks concerned.
[18:02] <BenC> pgraner: Already fixed
[18:02] <pgraner> I've asked cjwatson to join and talk about what we need to do?
[18:03] <pgraner> BenC: What was the fix?
[18:03] <BenC> pgraner: I uploaded a new module-init-tools that sets ignore_hpa=1
[18:03] <BenC> which gives us the previous behavior
[18:03] <pgraner> BenC: How much grief are we going to get from upstream on that one?
[18:03] <BenC> cjwatson, Keybuk and I discussed this for some time
[18:03] <BenC> pgraner: no more than before, but I've agreed we need to discuss an upgrade path for ignore_hpa=0 for jaunty
[18:04] <pgraner> BenC: Make sure you add that to the UDS planning page pls.
[18:04] <cjwatson> so I definitely think we need to worry about it for jaunty
[18:04] <BenC> Basically upgrading systems, or multi-boot systems with a kernel that has ignore_hpa=1 need to be taken care of
[18:04] <cjwatson> but a lot of the work needs to be in userspace
[18:04] <pgraner> [ACTION] BenC to add HPA handling to UDS planning page
[18:04] <MootBot> ACTION received:  BenC to add HPA handling to UDS planning page
[18:04] <cjwatson> we can't fiddle about with the contents of disks in nearly the same way in the kernel
[18:04] <BenC> pgraner: ACK
[18:05] <pgraner> Anything else on this one?
[18:05] <pgraner> Ok, moving on then....
[18:05] <pgraner> LP #261318 toshiba acpi
[18:05] <pgraner> Are we doing the right thing in shipping tlsup instead of toshiba_acpi? If so, what do we need to do in order to get it working properly?
[18:05] <BenC> pgraner: I will note that Keybuk disagrees with my solution being in modprobe.d instead of changing the source code in libata-core.c, but that's not relevant, IMO
[18:06] <rtg> BenC: I got similar hassles from him this morning
[18:06] <pgraner> BenC: ack, noted just add to the planning page
[18:06] <pgraner> So whats up with this one?
[18:06] <BenC> pgraner: first I've heard of it
[18:06]  * BenC reads the bug quickly...
[18:07] <pgraner> BenC: Looks like users are seeing various levels of support with the new code
[18:08] <pgraner> BenC: I'll keep moving and give you the action to handle it
[18:08] <pgraner> [ACTION] BenC to look into  LP #261318 toshiba acpi
[18:08] <MootBot> ACTION received:  BenC to look into  LP #261318 toshiba acpi
[18:08] <BenC> pgraner: ACK
[18:08] <pgraner> LP #282700, 263782, 277795 Usplash Screen Corruuption
[18:09] <pgraner> I understand we are reverting to vesafb instead uvisafb, has anyone had a chance to test it yet?
[18:09] <pgraner> rtg: ???
[18:09] <BenC> pgraner: fix committed, rtg testing
[18:09] <rtg> pgraner: its looking OK on 2 x86-64 laptops
[18:09]  * Keybuk sniggers at the idea of visafb
[18:09] <Keybuk> drawing on money!
[18:09] <BenC> or immigration papers :)
[18:10] <pgraner> rtg: can you follow up in the bug with the testing results pls?
[18:10] <rtg> pgraner: can do
[18:10] <pgraner> [ACTION] rtg to follow up on  LP #282700, 263782, 277795 Usplash Screen Corruuption in the bug
[18:10] <MootBot> ACTION received:  rtg to follow up on  LP #282700, 263782, 277795 Usplash Screen Corruuption in the bug
[18:10] <pgraner> LP #267875 rf_kill switch
[18:11] <pgraner> rtg: how we doing on this one?
[18:11] <rtg> pgraner: no progress.
[18:11] <pgraner> rtg: will it make kernel freeze?
[18:11] <rtg> slangasek thiks its an app space issue
[18:11] <rtg> s/thiks/thinks/
[18:11] <pgraner> rtg: is he working it?
[18:12] <rtg> he uploaded something, though I can't recall what. pm-utils?
[18:12] <slangasek> well, that wasn't my /thought/, that's what I was told
[18:12] <slangasek> I uploaded the acpi-support part
[18:12] <pgraner> slangasek: you have doubts?
[18:12] <rtg> I'd go look at the bug but my POS fire-fox won't start.
[18:12] <slangasek> *if* /sys/class/rfkill/rfkill<n>/state is the right interface, then a hal fix is still needed
[18:13] <slangasek> pgraner: I always have doubts where anything under /sys is concerned :P
[18:13]  * pgraner nods
[18:13] <slangasek> if there were some documentation that I could beat upstream developers with later if it were changed, I'd be much happier :-)
[18:13] <pgraner> slangasek: so what do we need to do to close this one out?
[18:13] <rtg> I don't think rf-kill has settled down to being a stable feature yet.
[18:14] <slangasek> well, in the absence of that documentation, I was going to ask pitti to look into it
[18:14] <slangasek> or if he doesn't have time, tackle the hal patching myself
[18:14] <pgraner> slangasek: ok I'll give you that action then?
[18:14] <slangasek> sure
[18:14] <rtg> slangasek: so what is HAL gonna do? unload/reload driver modules?
[18:14] <slangasek> rtg: hal has to notify n-m when the rfkill has been switched
[18:15] <slangasek> it did this for the old iwl interface
[18:15] <pgraner> [ACTION] slangasek to look into rf_kill issue LP# 267875
[18:15] <MootBot> ACTION received:  slangasek to look into rf_kill issue LP# 267875
[18:15] <rtg> sends a D-BUS message?
[18:15] <slangasek> yes
[18:15] <pgraner> LP #220917 iwl4965 firmware
[18:15] <pgraner> Have we sorted this one out yet?
[18:15] <pgraner> BenC: ???
[18:15] <rtg> I think it should just unload the module 'cause most of the drivers aren't smart enough to power down.
[18:16] <BenC> pgraner: Fixed partially
[18:16] <BenC> pgraner: I need to split into a linux-firmware image to have a proper fix for upgrades
[18:16] <BenC> pgraner: which is in-progress
[18:16] <BenC> pgraner: will update bug
[18:16] <pgraner> BenC: ack
[18:17] <pgraner> [ACTION] BenC to update bug LP# 220917 with current status
[18:17] <MootBot> ACTION received:  BenC to update bug LP# 220917 with current status
[18:17] <pgraner> Moving on.... Status of wireless backport
[18:17] <pgraner> rtg: What say you?
[18:17] <rtg> pgraner: initial implementation is done, now I'm waiting for upstream bug fixes.
[18:18] <rtg> It doesn't play well with NM
[18:18] <slangasek> rtg: "just unload the module" - is that in reference to 267875?  I think that's pretty out-of-scope for this bug, which is about fixing the regression that n-m no longer knows the interface is down
[18:18] <pgraner> rtg: asking the obvious, will it make kernel freeze?
[18:18] <rtg> slangasek: when the modules gets unloaded, NM seems to notice.
[18:18] <rtg> pgraner: likely not. the empty package is in the archive
[18:19] <pgraner> rtg: thats gonna leave us with some pretty big bugs hanging
[18:19] <rtg> pgraner: besides, LBM is really subject to SRU policy.
[18:19] <pgraner> slangasek: you agree ^^^^^^^^^^^^^?
[18:20] <slangasek> rtg: that's fine, but I'm not writing code to figure out when to re-load the modules...
[18:20] <rtg> slangasek: it was just a suggestion :)
[18:20] <slangasek> pgraner: I think it's fair to say that SRUs are the primary reason for LBM's existence, sure
[18:21] <slangasek> and that anything that's fair to fix in LBM at all is fair to fix via SRU
[18:21] <rtg> slangasek: that doesn't make sense to me.
[18:21] <pgraner> rtg: when do think upstream will settle?
[18:21] <slangasek> rtg: sorry, why not?
[18:21]  * BenC thinks rtg and slangasek are intertwining two conversations :)
[18:22] <rtg> LBM is a vehicle for porting upstream versions, which do not necessarily address SRU issues.
[18:22] <slangasek> well, ok
[18:22] <rtg> pgraner: upstream wireless will not converge until someone imposes some discipline on the development process.
[18:22] <slangasek> let's put it this way, then: I'm not likely to feel the need to meddle with anything you tell me should go into LBM, as long as it doesn't collide with the final freeze :)
[18:23] <rtg> slangasek: agreed
[18:23] <pgraner> rtg: I was looking for for you gut feel, than a "state of upstream devel process".... jeeez
[18:23] <pgraner> s/for//
[18:23] <pgraner> s/you/your/
[18:24] <rtg> pgraner: I don't have a gut feel, 'cause I think things are out of control.
[18:24]  * pgraner needs to lay off the caffeine 
[18:24] <pgraner> rtg: then I'll keep this on the tracking list for now
[18:25] <pgraner> [ACTION] pgraner to follow up with rtg on state of wireless backport
[18:25] <MootBot> ACTION received:  pgraner to follow up with rtg on state of wireless backport
[18:25] <rtg> the out-of-box experience will mostly be ok if you're using a mainstream wireless adapter, and don't try to do anything funny.
[18:25] <pgraner> rtg: ack
[18:25] <pgraner> LP #262564 Wrong Copyright file in pkg
[18:25] <pgraner> BenC: you squash this one yet?
[18:25] <BenC> pgraner: fixed and uploaded
[18:25] <BenC> "Fix released"
[18:25] <pgraner> BenC: nice
[18:26] <pgraner> Anyone have any other pet bugs they would like to add here?
[18:26] <pgraner> Going once.....
[18:26] <pgraner> Going twice...
[18:27] <pgraner> Going three times.....
[18:27] <pgraner> Moving on....
[18:27] <pgraner> [TOPIC] QA Bugs
[18:27] <MootBot> New Topic:  QA Bugs
[18:27] <pgraner> [LINK] http://people.ubuntu.com/~ogasawara/intrepid-buglist.html
[18:27] <MootBot> LINK received:  http://people.ubuntu.com/~ogasawara/intrepid-buglist.html
[18:27] <ogasawara> I've frozen the buglist for now
[18:27] <ogasawara> all bugs which I feel need to be addressed I'll ping the team directly
[18:27] <ogasawara> or bring them up here in the meeting
[18:28] <pgraner> ogasawara: can you make sure all bugs are assigned to an individual rather than the kernel-team?
[18:28] <ogasawara> pgraner: sure
[18:28] <pgraner> [ACTION] ogasawara to make sure  all bugs are assigned to an individual
[18:28] <MootBot> ACTION received:  ogasawara to make sure  all bugs are assigned to an individual
[18:28] <pgraner> ogasawara: anything you want to say about individual bugs now? or can we move on?
[18:29] <ogasawara> I think we're good, move on
[18:29] <pgraner> ogasawara: ack
[18:29] <pgraner> [TOPIC] Open Discussion
[18:29] <MootBot> New Topic:  Open Discussion
[18:29] <pgraner> We got a question from mnuckfish on the Future of the linux-ports kernels
[18:29] <pgraner> Can we keep ports in sync with the official Ubuntu kernel in Jaunty? Like lpia does now?
[18:29] <pgraner> Is there anyone that cares about ia64 (currently FTBFS), sparc, hppa?
[18:29] <munckfish> Hi folks
[18:30] <munckfish> I just wanted to get an idea what the intention was for the future of the ports kernels
[18:30] <pgraner> BenC: thoughts?
[18:30] <BenC> pgraner: In jaunty I hope to be able to devote some time to those ports
[18:30] <munckfish> they use the 2.6.25 source right now
[18:30] <smb_tp> I looked at the ia64 FTBA and since it is only ABI stuff would care about that
[18:30] <BenC> pgraner: part of the reason for doing it this way in intrepid is that we knew we were going to be hard pressed to handle just x86 and x86-64
[18:31] <munckfish> BenC: how come things will be easier in Jaunty?
[18:31] <BenC> munckfish: we have more people on the canonical kernel team, and more experience, so I might have free time :)
[18:31] <amitk> pgraner: It is kinda hard to support these without necessary hardware to test with - who has a hppa, ia64 machine?
[18:31] <munckfish> BenC: sounds good
[18:31] <lieb> I do
[18:31] <pgraner> BenC: I wouldn't go that far
[18:32] <BenC> amitk: I do
[18:32] <BenC> I have one of everything
[18:32] <lieb> although the power bill has been half since the 'tanic has been off...
[18:32] <BenC> pgraner: well, there's a better chance in jaunty than there was in intrepid
[18:32] <pgraner> BenC: possibly, however we have assumed other workloads as well.
[18:32] <munckfish> well this is positive I really wasn't sure whether the general feeling towards ports was to let them die
[18:32] <BenC> lieb: sounds good, maybe we can both give it a little love
[18:33] <BenC> munckfish: as pgraner is pointing out, there's no guarantee though
[18:33] <pgraner> BenC: we can discuss at UDS when we are all together, I'm not opposed but we need to see what the cost is vs. everything else on the plate along with Jaunty features
[18:33] <munckfish> BenC: well that's ok, I'm happy to do any leg work I can - as I've done for Intrepid
[18:33] <amitk> so let me play devils advocated here: how many people use the ia64 and hppa ports?
[18:33] <BenC> amitk: probably 5-10 people
[18:34] <BenC> if that many
[18:34] <amitk> *advocate
[18:34] <munckfish> What about powerpc?
[18:34] <BenC> ppc is pretty well used by the community, just not very well supported by it
[18:34] <persia> ia64 is interesting to keep because it helps resolve a number of 64-bit code issues (it does 64-bit differently than amd64)
[18:34] <BenC> I would say ppc is lead only by x86/x86-64
[18:35] <BenC> persia: so does sparc
[18:35] <persia> BenC, Hrm.  Good point.  I should look there instead.
[18:35] <BenC> but then it isn't 64-bit userspace
[18:35] <BenC> except for a few bits
[18:35] <pgraner> BenC: IBM has been asking the server team for official support, we need to check with them to see if we can get IBM to help out for power
[18:35]  * amitk agrees with ppc, considering that PS3 will be available for the next 5-7 years
[18:36] <BenC> pgraner: IBM bought me a power5 box, so I feel somewhat obligated to help out
[18:36] <BenC> even if it is in my own time
[18:36] <munckfish> Wow, so there's a chance it may become official again?
[18:36] <pgraner> [ACTION] pgraner to set up talk with server team on PPC support
[18:36] <MootBot> ACTION received:  pgraner to set up talk with server team on PPC support
[18:36] <BenC> but an officially supported power (or even better CBE) port would be nice
[18:37] <munckfish> very nice
[18:37] <pgraner> munckfish: we need to see internally if its something thats worth while or not
[18:37] <pgraner> munckfish: are you did this answer your questons?
[18:37] <pgraner> s/questons/questions/
[18:38] <munckfish> Yes, second question was about staying in sync
[18:38] <BenC> munckfish: up for discussion at UDS
[18:38] <munckfish> amitk's LPIA tree
[18:38] <BenC> maybe we can look into putting some of the more stable ports back into the main kernel tree
[18:38] <munckfish> is that likely a good way to do things for ports/
[18:38] <munckfish> ?
[18:38] <munckfish> BenC: ok understood
[18:38] <BenC> IMO, ia64 and hppa should be left external to our tree
[18:39] <munckfish> btw folks Intrepid is running nicely on PS3 now bar one install bug - so thx for all the help, advice, and patience you've all offered in these last months
[18:39] <BenC> munckfish: excellent...guess it's time to upgrade mine :)
[18:39] <pgraner> Any other open topics ?????
[18:39] <rtg> slangasek: is there anything holding up the transition to -updates of the Hardy kernel in -proposed ?
[18:40] <slangasek> I haven't been tracking it, sorry; pitti would be better able to answer
[18:40] <smb_tp> I have to get back on him on that
[18:40] <slangasek> I know we had one purported regression, which I believe I saw was ironed out
[18:40] <rtg> slangasek: ok. kees is hot to publish CVEs
[18:41] <pgraner> [ACTION] smb_tp to get with pitti on Hardy -updates
[18:41] <MootBot> ACTION received:  smb_tp to get with pitti on Hardy -updates
[18:41] <smb_tp> In case hardy doesn't get into updates, there might be a split release but getting hardy as well would be preferred
[18:41] <smb_tp> pgraner, ack
[18:41] <pgraner> Anything else?
[18:42] <pgraner> Ok moving on then...
[18:42] <pgraner> [TOPIC] Lightening Round
[18:42] <MootBot> New Topic:  Lightening Round
[18:42] <pgraner> I'll go first...
[18:42] <pgraner> I'll be in London for release week.
[18:42] <pgraner> Working with the other teams on late breaking kernel issues. So if I ping you or ask status, please be kind. thats about it.
[18:43] <pgraner> timg: ???
[18:43] <rtg> heads down, boss.
[18:43] <pgraner> rtg: just what I like to hear :-)
[18:44] <pgraner> rtg: I think we covered most of your stuff above...
[18:44] <rtg> yep - I've no other topics
[18:44] <pgraner> BenC: how about you?
[18:44] <BenC> pretty much the same...finishing up the stuff we discussed on the bug list, and starting on some of the new action items from this meeting
[18:44] <pgraner> BenC: by my box score you walked away with most of the actions... anything else in the queue ?
[18:45] <pgraner> BenC: any concerns for kernel freeze?
[18:45] <BenC> pgraner: none of the moment
[18:45] <BenC> /sof/at/
[18:45] <pgraner> BenC: ack
[18:45] <pgraner> amitk: what say you?
[18:46] <amitk> Been busy keeping the lpia kernel up-to-date. Next week will be spent improving out-of-box support for some of the mobile devices we care about.
[18:46] <amitk> samsung q1 and jax10 being the main ones
[18:46] <pgraner> amitk: any concerns ?
[18:47] <amitk> no.. looking good.
[18:47] <pgraner> smb_tp: you're turn...
[18:47] <smb_tp> Work towards CVE release, fix ports ia64 FTBS, expect to get buried by Leann in bug reports...
[18:48] <pgraner> smb_tp: at least ogasawara is kind, she could really be mean about it
[18:48] <rtg> BenC: I think we should roll a kernel today and get the vesafb change propagated.
[18:48] <smb_tp> pgraner, I don't dare to say something else ;) She's too close
[18:48]  * ogasawara moves smb_tp to the top of her list :)
[18:48] <pgraner> smb_tp: I know!
[18:49] <pgraner> cking: how goes it?
[18:49] <cking> Supporting OEM team - plenty of BIOS and embedded controller issues to resolve
[18:49] <pgraner> cking: your getting pretty good what that DSDT stuff?
[18:50] <cking> well - I'm very comfortable at seeing bugs in DSTD / AML code now :-)
[18:50] <pgraner> cking: we can give you a bag of chicken bones and some magic dust if it would help?
[18:50] <cking> - yeah - I think voodoo + magic is required
[18:50] <pgraner> lieb: I would guess you don't have much other than new guy tasks... ?
[18:51] <smb_tp> Especially if it comes to interpret 4 letter variables...
[18:51] <lieb> yup
[18:51] <BenC> rtg: agreed
[18:51] <lieb> that too
[18:51] <pgraner> [ACTION] BenC to roll new kernel with vesafb changes
[18:51] <MootBot> ACTION received:  BenC to roll new kernel with vesafb changes
[18:51] <rtg> BenC: lemme redo a wireless patch for ipw220, then I can upload it (unless you have something?)
[18:51] <BenC> rtg: have at it
[18:52] <pgraner> [ACTION] rtg to roll new kernel with vesafb changes and other "stuff"
[18:52] <MootBot> ACTION received:  rtg to roll new kernel with vesafb changes and other "stuff"
[18:52] <rtg> on it...
[18:52] <pgraner> Ok folks our time is about up, anything else?
[18:52] <smb_tp> no
[18:53] <persia> I'm curious if anyone was able to review the -rt kernel, and if it needed work.
[18:53] <pgraner> Anyone?
[18:53] <rtg> persia: it now builds ok, but I haven't run it.
[18:53] <BenC> I tried a couple weeks ago to port the -rt patchset to 2.6.27 and gave up after manually merging > 100 patches of some 4-500
[18:53] <BenC> is it based on 2.6.27?
[18:54] <persia> BenC, abogani completed the porting.
[18:54] <persia> Yes.
[18:54] <BenC> more power to him then
[18:54] <rtg> it actually build depends on 2.6.27.
[18:54] <rtg> uses quilt to apply the patches
[18:54] <persia> I've been told that's what upstream for -rt is doing.
[18:55] <BenC> that's what I was working on when it was based on .26
[18:55] <BenC> easy to work with
[18:55] <rtg> yeah - I thought it was an elegant way to do it.
[18:55] <persia> abogani was wondering if there was a chance of a l-r-m-source package to do the same for l-r-m, or whether he'd have to copy the l-r-m source to do it as well.
[18:55] <pgraner> Anything else?
[18:56] <BenC> persia: > #ubuntu-kernel
[18:57] <pgraner> Ok, we are need to get outta here. I'll call it end of meeting.
[18:57] <pgraner> #endmeeting
[18:57] <MootBot> Meeting finished at 12:57.
[18:57] <pgraner> Thanks everyone
[18:57] <amitk> bye all
[18:57] <BenC> bye
[20:51] <ubunup> am i right in this chat when i use to talk ubuntu caus i just installed it 2 ohours ago
[20:53] <cjwatson> ubunup: this channel is for meetings (as in organised meetings) among Ubuntu teams; #ubuntu, please
[20:54] <ubunup> o sry thx