Ubuntu Wiki

Agenda

• Review ACTION points from previous meeting
  • mathiaz to send out a call for ideas on ubuntu to the puppet community
  • ALL to mark maverick assigned specs as "Implemented" or Deferred
  • jjohansen to look into bug 634487 and bug 658461
  • zul to check SRU tracker status
• Natty Development
• Maverick SRUs

  • Bug 661547 - Existing patch gssapi.diff makes guess_service_principal produce garbage

  • Bug 657149 - squid fails to upgrade (incomplete)

  • Bug 658227 - openldap fails to upgrade (in -proposed)

  • Bug 660227 - php5-pgsql crash on getting an error back from postgres (in -proposed)

  • Bug 600174 - axis2c fails to build from source on maverick/i386

• Weekly Updates & Questions for the QA Team (hggdh)

• Weekly Updates & Questions for the Kernel Team (jjohansen)

• Weekly Updates & Questions for the Documentation Team (sommer)

• Weekly Updates & Questions for the Ubuntu Community Team (kim0)

• Meeting time and scheduling (spamaps)
  • Possibility to move meeting earlier now that west coast is outnumbered (suggestion: 1600 UTC)

  • How do we add to the fridge calendar at http://fridge.ubuntu.com/calendar

• Open Discussion
• Announce next meeting date and time
  • Tuesday 2010-11-16 at 1600 UTC - #ubuntu-meeting ? -- Time tentative based on discussion

Minutes

Meeting Actions

• mathiaz: to verify SRU bug 666028
• ALL: please check the SRU tracker for verification-needed bugs and help out with verification
• SpamapS: change kernel team representative from jjohansen to smb in meeting agenda going forward
• robbiew: update the fridge calendar with new ubuntu server meeting time
• hggdh: contact Ubuntu Developers asking for packages which run test suites during build.

Review ACTION points from previous meeting

Because the previous meeting was pre-UDS, there were no ACTION points to review.

Natty Development

Specifications should be submitted for review, robbiew is reviewing/approving those that are ready.

Maverick SRUs

• JamesPage brought up bug #666028 as it would need verification.

• This brought up the bigger topic that there are no actual resources available to do verification of SRU's right now, so we should all allocate some time to watching for SRU's that are marked verification-needed and verify when possible. These are listed in Chuck's SRU tracker: http://people.canonical.com/~chucks/SRUTracker/sru-tracker-bugs.html#verified_bugs

• There was talk of a "daily verification" schedule similar to bug triage. Discussion of this further is deferred.

Weekly Updates & Questions for the QA Team (hggdh)

• The ISO images page was consolidated, causing some confusion. hggdh thought we were going to have to start doing ISO testing for MAC, armel, PPC, even possibly PS3.
  • robbiew put this to rest, i386/amd64 are the only ones requiring server ISO testing. This was just the result of consolidation.
• hggdh is expanding daily builds to include any packages that run extensive tests during their build process.
  • All are encouraged to send examples to hggdh. He will contact ubuntu developers for help in finding more.
  • mathiaz noted that rules files could be grepped for the 'nocheck' test that is suggested for any large test suites during build.

Weekly Updates & Questions for the Kernel Team (jjohansen)

• jjohansen has transitioned his role as server team kernel delegate to smb
• smb notes kernel bug #415353 which he will be looking into to help address issues with teh bnx2x drivers.
• jjohansen noted that there is an SRU pending for bug #651370 which causes ec2 to crash with an invalid opcode in maverick
• jjohansen noted that pv-on-hvm drivers are in the natty kernel and will undergo testing/experimentation in the short term.

Meeting time and scheduling

• The meeting is a bit late in the day for many of the european participants, so it was proposed, and accepted, to move the meeting back to 1600 UTC.
  • robbiew will add an entry to the official #ubuntu-meeting calendar on the fridge

Open Discussion

• RoAkSoaX would like people to review his split for cluster-stack library packages. SpamapS suggests adding a merge proposal and asking ubuntu-server for review.

Agree on next meeting date and time

Next meeting will be on Tuesday, November 16th at 16:00 UTC in #ubuntu-meeting.

Log

[19:01] <SpamapS> #startmeeting
[19:01] <MootBot> Meeting started at 13:01. The chair is SpamapS.
[19:01] <MootBot> Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE]
[19:01] <mathiaz> o/
[19:01] <JamesPage> o/
[19:01] <SpamapS> FYI, the meeting was sort of half scheduled for 18:00, half for 19:00, so we're doing it now
[19:02] <SpamapS> I will be the scribe since daviey is possibly unavailable
[19:02] <SpamapS> [TOPIC] Review ACTION points from previous meeting
[19:02] <MootBot> New Topic:  Review ACTION points from previous meeting
[19:02] <SpamapS> Unfortunately, I believe those ACTION points in the agenda are the same as last week's.
[19:03] <JamesPage> is that because we did not do them last week?
[19:03] <SpamapS> please standby I will grep them out of the meeting log from last week..
[19:04] <SpamapS> Ok there were none it seems
[19:04] <SpamapS> moving on
[19:04]  * mathiaz \o/
[19:04] <SpamapS> [TOPIC] Natty Development
[19:04] <MootBot> New Topic:  Natty Development
[19:04] <mathiaz> it's always like that at the begining of a release cycle
[19:04] <SpamapS> Indeed. :)
[19:05] <SpamapS> I added this topic, just wanted to make sure people had a forum for any questions or comments on the spec process.
[19:05] <mathiaz> so the focus is to get WI defined
[19:05] <robbiew> right
[19:05] <SpamapS> We should all be submitting specs for review by... is it next Thursday?
[19:05] <mathiaz> once the WI are defined and rough plan is outlined the spec status should be moved to Review
[19:05] <robbiew> and I've started reviewing/approving/deferring/asking :)
[19:06]  * robbiew gave https://wiki.ubuntu.com/ServerTeam/NattyBlueprints some loving
[19:06] <SpamapS> Feature Definition Freeze is 11/25, so specs must be approved before then right?
[19:06] <mathiaz> one thing to consider is that it's possible (and actually encouraged) to add WI after the spec has been approved
[19:06] <SpamapS> yes, its mostly about getting the design and intent clear
[19:06] <mathiaz> as it helps to keep track of what needs to be done
[19:07] <SpamapS> And a general idea of how much is needed to be done.
[19:07] <mathiaz> and if an important is taking more time we can know in advance what other things should be dropped
[19:07] <mathiaz> so WIs defined when a spec is approved are not set in stone
[19:08] <SpamapS> ok, anything else on Natty?
[19:08] <mathiaz> Natty is going to ROCK!
[19:09] <SpamapS> Its going to burst forth from the ocean like a unicorn with flippers and a blow hole.
[19:09] <robbiew> lol
[19:09] <SpamapS> Alright, moving on.
[19:09] <RoAkSoAx> is the meeting almost over or just started?
[19:09] <SpamapS> [TOPIC] Maverick SRUs
[19:09] <MootBot> New Topic:  Maverick SRUs
[19:10] <SpamapS> I think this list also wasn't updated in the agenda.. and zul was mostly in charge of these, but does anyone have new ones to bring up for discussion?
[19:10] <JamesPage> yes - bug 666028;
[19:10] <ubottu> Launchpad bug 666028 in openldap "apt-get install slapd => Can't locate object method "new" via package "Debconf::Element::Noninteractive::Booleam"" [Undecided,New] https://launchpad.net/bugs/666028
[19:10] <JamesPage> for awareness more than anything else; its a follow up to bug 658227
[19:11] <ubottu> Launchpad bug 658227 in openldap (Ubuntu Natty) "upgrade process does not upgrade underlying BDB format from 4.7 to 4.8 (so slapd aborts with "Program version 4.8 doesn't match environment version 4.7" error message)" [High,Fix released] https://launchpad.net/bugs/658227
[19:11] <mathiaz> JamesPage: the upload has been accepted in maverick-proposed
[19:11] <mathiaz> and should be ready in a couple of hours for testing
[19:11] <JamesPage> yep  - just went through
[19:11] <SpamapS> right looks like pitti accepted it into proposed just now
[19:11] <JamesPage> its holding up bug 661547
[19:11] <ubottu> Launchpad bug 661547 in openldap (Ubuntu) "Existing patch gssapi.diff makes guess_service_principal produce garbage" [High,Triaged] https://launchpad.net/bugs/661547
[19:12] <JamesPage> but that might be debatable for SRU (we'll see I guess)
[19:12] <SpamapS> Is anyone signed up to do the verification yet?
[19:12] <mathiaz> SpamapS: usually it's the SRU team in QA that does it
[19:12] <SpamapS> Ok.. I tend to verify my SRU's too.
[19:12] <mathiaz> SpamapS: however it's become a zero-man team recently
[19:12] <SpamapS> wha?
[19:13] <mathiaz> well - not really - volunteer are still trying to do verification
[19:13] <mathiaz> but it can take time
[19:13]  * SpamapS debates an action for robbiew: "FIX IT!"
[19:13] <mathiaz> so having someone within the server team taking care of sru-verification would be helpful
[19:13]  * robbiew is no longer release manager ;)
[19:13] <mathiaz> I'll do the sru-verification for openldap
[19:14] <robbiew> +1 on having Server team member on SRU team
[19:14] <robbiew> we are lucky to have pitti back from oem rotation this cycle for sure \o/...but help is definitely needed
[19:14] <mathiaz> it's also better to have the sru verification done by someone else than develop and sponsored the fix
[19:14] <SpamapS> [ACTION] mathiaz: to verify SRU bug 666028
[19:14] <MootBot> ACTION received:  mathiaz: to verify SRU bug 666028
[19:14] <ubottu> Launchpad bug 666028 in openldap "apt-get install slapd => Can't locate object method "new" via package "Debconf::Element::Noninteractive::Booleam"" [Undecided,New] https://launchpad.net/bugs/666028
[19:14] <JamesPage> mathiaz: I agree
[19:14] <SpamapS> s/better/vital/
[19:15] <mathiaz> which means that 3 people are required for getting an SRU through
[19:15] <mathiaz> (1 developer, 1 reviewer, 1 verifier)
[19:15] <SpamapS> Ok, so maybe another topic for discussion should be that we should raise the SRU manpower issue?
[19:15]  * hggdh pays attention now
[19:15] <mathiaz> yeah - that would be an interesting issue to solve
[19:16] <mathiaz> we had plans to improve the SRU process
[19:16] <SpamapS> maybe somebody could publicize that we are in need of some volunteer help for SRU's
[19:16] <mathiaz> (devised in the summer sprint in dublin more than 1 year ago)
[19:17]  * s3hh wonders what a reviewer task entails
[19:17] <Daviey> o/
[19:17] <robbiew> SpamapS: heh...if it were just advertising, it'd be a simple process to solve
[19:17] <robbiew> MIR team needs help too
[19:17] <SpamapS> yeah no kidding :p
[19:17] <mathiaz> the SRU tracker was designed as a tool to help in tracking what needs to be done
[19:17] <robbiew> and the Release Team could stand to grow a bit.../me gets off his soap box
[19:17] <robbiew> :)
[19:17] <mathiaz> it mainly is a ressource issue
[19:18] <mathiaz> s3hh: a review task is about reviewing the SRU prepared by another developer
[19:18] <mathiaz> s3hh: given that SRU is making there are no regression many eyes are important
[19:18] <SpamapS> Ok, so right now, we just make it clear that there is a resource issue, and tax other devs for verification?
[19:18] <ajmitch> robbiew: I didn't think the release team was necessarily involved in SRUs :)
[19:19] <mathiaz> SpamapS: yeah - I think that's the good way
[19:19] <mathiaz> SpamapS: with the sru tracker we should be able to generate a list of bugs that need to be verified
[19:19] <robbiew> ajmitch: you should check out the members of each then ;)
[19:19] <SpamapS> mathiaz: there's a tag for that ;)
[19:20] <mathiaz> SpamapS: and then the verification needs to be done by someone
[19:20] <ajmitch> SpamapS: is the problem mostly verification, or getting a package into -proposed in the first place?
[19:20] <mathiaz> SpamapS: yes - the SRU tracker also filters the list to make it relevant to server package
[19:20] <mathiaz> ajmitch: both ;)
[19:20] <SpamapS> So maybe we should add a "daily verification" schedule similar to daily triage.
[19:20] <mathiaz> SpamapS: make it smaller chunks
[19:20] <mathiaz> SpamapS: yop - that was the next step :)
[19:21] <SpamapS> zul_: think you could add a list of verification-needed bugs to the SRU tracker easily?
[19:21] <mathiaz> SpamapS: it already is IIRC
[19:21] <SpamapS> yes, why yes it is
=== bjf[afk] is now known as bjf
[19:21] <mathiaz> SpamapS: http://people.canonical.com/~chucks/SRUTracker/sru-tracker-bugs.html#verified_bugs
[19:22] <SpamapS> [ACTION] ALL: please check the SRU tracker for verification-needed bugs and help out with verification
[19:22] <MootBot> ACTION received:  ALL: please check the SRU tracker for verification-needed bugs and help out with verification
[19:22] <SpamapS> Ok, lets move on
[19:23] <SpamapS> ajmitch: getting things into proposed seems to happen at a fairly nice pace, we can thank pitti for that.
[19:23] <SpamapS> [TOPIC] Weekly Updates & Questions for the QA Team (hggdh)
[19:23] <MootBot> New Topic:  Weekly Updates & Questions for the QA Team (hggdh)
[19:23] <hggdh> k
[19:23] <hggdh> first question is from myself
[19:23] <hggdh> how are we going to test server images for MAC, armel, PPC?
[19:24] <hggdh> nice to have them, but...
[19:24] <ajmitch> SpamapS: oh I meant getting a package ready for -proposed, ie finding the fix
[19:24] <mathiaz> hggdh: are there any images published for these architecture?
[19:24] <hggdh> mathiaz: yes, just popped in in the server/daily
[19:25] <JamesPage> whats the status of libvirt/kvm on those architectures?
[19:25] <SpamapS> hggdh: I believe there were some build machines distributed for armel at UDS.. did we not get QA machines as well?
[19:25] <hggdh> SpamapS: none for server testing at least; I did not hear of any for QA at all
[19:26] <mathiaz> hggdh: well - I think these images should be tested
[19:26] <s3hh> JamesPage: well ppc kvm is supposed to work iirc
[19:26] <mathiaz> hggdh: in order to do that hardware needs to be available
[19:26] <hggdh> mathiaz: I agree, I  did not say they would not, I asked *how* ;-)
[19:26] <mathiaz> hggdh: which I don't have
[19:26] <mathiaz> hggdh: and I don't know who on the team has hardware
[19:27] <hggdh> robbiew: hello, sir :-)
[19:27] <SpamapS> I have an old PowerMac G5.. but what really troubles me is that this suggests maybe we're going to have even *more* iso tests to run?
[19:27] <hggdh> yes we will
[19:27] <SpamapS> JamesPage: time to fire up automated iso testing on PPC. :-D
[19:27] <robbiew> wait
[19:27] <hggdh> libvirt would help, but we need to also try bare metal
[19:27] <s3hh> doh
[19:27] <robbiew> why are we discussing this?
[19:28] <SpamapS> robbiew: no idea, hggdh brought it up
[19:28] <robbiew> Ubuntu Server testing on PPC32?
[19:28] <mathiaz> robbiew: http://cdimage.ubuntu.com/ubuntu-server/daily/current/
[19:28] <JamesPage> SpamapS; yes - but we need to cover the other two cases using physical hardware as well
[19:28] <mathiaz> robbiew: ^^ there are images for these architecture published there
[19:28] <hggdh> robbiew: we have the images now
[19:29] <SpamapS> Ooo I volunteer to host the PS3 test box...
[19:29] <robbiew> we don't spin official ISOs for Server on PPC32
[19:29] <robbiew> or PS3
[19:29] <SpamapS> darn
[19:29] <robbiew> these are ports, right?
[19:30] <mathiaz> robbiew: I don't know - it's the first time I see these images show up on cdimage
[19:30] <SpamapS> right, so we don't need to complete the iso tests.. that would be something the community would need to complete.
[19:30] <mathiaz> robbiew: under the ubuntu-server daily iso
[19:30] <robbiew> hmm
[19:30] <robbiew> let me dig into this
[19:30] <hggdh> thank you
[19:30] <highvoltage> there are PS3 images on cdimage!?
[19:30] <robbiew> I say for now...no testing of these flavors
[19:30] <mathiaz> robbiew: it may be an error on the iso build scripts
[19:30] <robbiew> intel and amd64 for now
[19:30] <hggdh> robbiew: the same for AMD64-mac?
[19:31]  * highvoltage sees there is and apologizes for his ignorance
[19:31] <robbiew> just focus on i386 and amd64 images
[19:31] <hggdh> k
[19:31] <SpamapS> sounds good to me. :)
[19:31] <hggdh> next item from QA
[19:31] <mathiaz> hggdh: so nothing changes compared to last release cycle
[19:31] <ajmitch> highvoltage: good luck getting a PS3 that you can still run it on :)
[19:31] <hggdh> mathiaz: ack
[19:32] <hggdh> I intend to expand daily build for packages with build-time checks
[19:32]  * robbiew suspects this has to do with the discussion at UDS around relocating the ports stuff
[19:32] <hggdh> so I would like you folks to give me these packages (so that I can add them in)
[19:33] <mathiaz> hggdh: you're looking for packages that have their test suite run during the build?
[19:33] <SpamapS> ahh so just add the natty package as a daily build, to test for toolchain regressions.
[19:33] <hggdh> mathiaz: yes, this would be immediately used (like mysql, coreutils, etc)
[19:33] <hggdh> which are already built daily, BTW
[19:33] <mathiaz> hggdh: ok - I'd suggest to send email to ubuntu-devel/ubuntu-server for a first round of feedback
[19:34] <SpamapS> hggdh: its not entirely clear how one would determine that easily, other than noticing it while looking at a package.
[19:34] <mathiaz> hggdh: you can also find good candidates by looking at packages that support the nocheck option at build time
[19:34] <hggdh> will look for them
[19:34] <SpamapS> mathiaz: how is that determined though? grep nocheck debian/rules ?
[19:34] <mathiaz> hggdh: as nocheck is the recommended way (may even be in the policy now) to disable tests at build time
[19:34] <mathiaz> SpamapS: yes - nocheck in debian/rules
[19:35] <mathiaz> SpamapS: write a script that looks for all debian/rules in the archive
[19:35] <mathiaz> SpamapS: I recommand a local mirror of the archive to do so
[19:35] <SpamapS> ok so that could be done in an automated fashion (albeit slow, since it would basically require grepping every diff and unpacking every .debian.tar.gz
[19:35] <mathiaz> SpamapS: I usually as kees to run these scripts ;)
[19:35] <SpamapS> hah good point
[19:35] <SpamapS> so, is somebody going to do that?
[19:36] <mathiaz> SpamapS: kirkland also has a local mirror and ran similar scripts before
[19:36] <hggdh> will look for easy ways. Meanwhile, if you know of any such packages now... I can add them
[19:36] <mathiaz> hggdh: mysql, openldap
[19:36] <JamesPage> hggdh: is it possible to see whats already covered somewhere?
[19:37] <hggdh> JamesPage: yes, just a sec
[19:38] <SpamapS> hggdh: how about you send a message to ubuntu-server and ubuntu-devel with the coverage and a request for more packages that do checks?
[19:38] <hggdh> deal.
[19:38] <SpamapS> we need to move on.
[19:38] <hggdh> I am done
[19:38] <robbiew> right...so the new look of the daily images has to do with https://blueprints.launchpad.net/ubuntu/+spec/ubuntutheproject-foundations-n-cdimage-ports-consolidation
[19:38] <robbiew> just an FYI
[19:38] <SpamapS> hggdh: thanks! :)
[19:38] <SpamapS> [TOPIC] Weekly Updates & Questions for the Kernel Team (jjohansen)
[19:38] <MootBot> New Topic:  Weekly Updates & Questions for the Kernel Team (jjohansen)
[19:39] <jjohansen> well first up lets add an action item to change that from jjohansen to smb :)
[19:39] <jjohansen> smb: did you have anything you wanted to bring up?
[19:39] <smb> Just one notification that I was made aware of a bug which looks server related by Montreal: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/415353
[19:39] <ubottu> Launchpad bug 415353 in linux (Ubuntu Lucid) "karmic/lucid installation slow on "detecting network hardware" with bnx2x" [Medium,Triaged]
[19:40] <smb> Have not looked at that deeply but plan to do tomorrow
[19:40] <SpamapS> jjohansen: will do when doing the minutes
[19:41]  * smb spent most of today from recovering / catching up from yesterday which he spent recovering from returning from Plumbers
[19:41] <jjohansen> The config patch for Bug #651370 has been submitted and accepted for SRU
[19:41] <ubottu> Launchpad bug 651370 in linux (Ubuntu Maverick) "ec2 kernel crash invalid opcode 0000 [#1]" [Medium,In progress] https://launchpad.net/bugs/651370
[19:42] <SpamapS> alright, anything else?
[19:42] <mathiaz> smb: how is the kernel release manager for natty?
[19:42] <mathiaz> smb: *who*
[19:42] <jjohansen> what else, the pv-on-hvm drivers are in the natty kernel and we will be experimenting with them this week
[19:43] <smb> apw
[19:43] <SpamapS> mathiaz: aw, and here I thought you were just concerned for apw's well being
[19:43] <mathiaz> :)
[19:43] <SpamapS> alright, we're running a bit short on time, so unless there is anything else?
[19:44] <jjohansen> I'm done
[19:44] <SpamapS> sommer seems to be absent so we will skip Doc team q&a for now
[19:44] <SpamapS> I've pinged kim0 .. but we can move on to the next topic till he replies
[19:44] <SpamapS> [TOPIC] Meeting time and scheduling (SpamapS)
[19:44] <MootBot> New Topic:  Meeting time and scheduling (SpamapS)
[19:45] <SpamapS> I think actually Daviey and ttx brought this up originally
[19:45] <SpamapS> two issues really
[19:45] <SpamapS> 1) today's was moved back to 1900 UTC accidentally I think.. or did we move it to 1900 so it stays at the same local time for everybody who is now on DST ?
[19:46] <mathiaz> SpamapS: 1) - yes for 2nd option
[19:46] <robbiew> any reason why it's so late in the day?
[19:46] <SpamapS> So given that do we have any strong thoughts about moving the meeting to 1600 UTC?
[19:46] <robbiew> could we do 1700 UTC?
[19:46] <mathiaz> robbiew: historical reason
[19:47] <robbiew> or even 1600UTC
[19:47] <JamesPage> 1600UTC would be better for me (and I now Daviey was keen as well)
[19:47]  * robbiew would love 1600UTC...but wasn't sure SpamapS would be awake ;)
[19:47] <mathiaz> 1600 UTC would mean we'd be back to back with the Tech Board
[19:47] <Daviey> \o/
[19:47] <mathiaz> every other week
[19:47] <SpamapS> 1600 UTC will be 8:00am for me, but I have a 1 year old so thats usually 3 - 4 hours after I wake up
[19:47] <Daviey> mathiaz: we used to be back to back
[19:47] <Daviey> it was *rarely* a problem
[19:47] <robbiew> eh...TB isn't that important anyway :P
[19:48] <mathiaz> Daviey: yes - the meeting was at 16:00 UTC for a long time
[19:48]  * robbiew says we move it back
[19:48]  * JamesPage seconds the motion
[19:48]  * s3hh is good w that
[19:48] <SpamapS> I am totally fine w/ 16:00 as long as its understood I may be surly and have messy hair.
[19:49] <robbiew> lol
[19:49] <s3hh> SpamapS: keep that webcam off
[19:49] <robbiew> yes..please!
[19:49] <SpamapS> Ok, 16:00 UTC it is
[19:49] <smb> This also means the meeting has to finish after one hour. :)
[19:49] <SpamapS> (I believe we also discussed this offline with some other team members last week so I feel comfortable saying that "the motion carries")
[19:49] <RoAkSoAx> jeez im gonna have to wake up early now :(
[19:49] <SpamapS> smb: ++
[19:50] <SpamapS> RoAkSoAx: I'll make an extra big pot of coffee so we can share
[19:50] <SpamapS> [TOPIC] Open Discussion
[19:50] <MootBot> New Topic:  Open Discussion
[19:50] <RoAkSoAx> I need a volunteer to review the library split for cluster-stack packages... anyone? :)
[19:51] <RoAkSoAx> before actually uploading to universe and requesting MIRs
[19:51] <ajmitch> RoAkSoAx: 16:00 UTC shouldn't be that bad for you? there aren't too many server community people in this part of the world though
[19:51] <SpamapS> RoAkSoAx: throw it up as a merge proposal and ask ubuntu-server for a review.
[19:52] <SpamapS> RoAkSoAx: I'll take a peek.
[19:52] <robbiew> wait folks...I think the desktop team meets at 16:30UTC...according to the Fridge
[19:52] <SpamapS> Anybody else have any other topics?
[19:52] <SpamapS> robbiew: doh
[19:52] <mathiaz> robbiew: nope - they meet in ubuntu-desktop
[19:52] <robbiew> sweet
[19:52] <mathiaz> robbiew: the fridge is probably wrong
[19:52] <robbiew> and odd...but who cares
[19:53] <SpamapS> oh thats the other thing
[19:53] <robbiew> \o/
[19:53] <SpamapS> should we update the fridge?
[19:53] <SpamapS> we aren't even listed there
[19:53] <robbiew> I can
[19:53] <SpamapS> [ACTION] robbiew: update the fridge calendar with new ubuntu server meeting time
[19:53] <MootBot> ACTION received:  robbiew: update the fridge calendar with new ubuntu server meeting time
[19:53] <RoAkSoAx> ajmitch: no it is actually not that bad... but it is early for me :P I wake up late sometimes :)
[19:53] <SpamapS> Alright
[19:53] <SpamapS> [TOPIC] Announce next meeting date and time
[19:53] <MootBot> New Topic:  Announce next meeting date and time
[19:53] <SpamapS> Tuesday 2010-11-16 at 1600 UTC - #ubuntu-meeting
[19:54] <SpamapS> Thanks everyone!
[19:54] <SpamapS> #endmeeting