Ubuntu Wiki

Agenda

• Review ACTION points from previous meeting
  • sommer waiting on mdke re: refresh issue
• Maverick development (jib)
  • We are heavily loaded for the alpha-3 sub-cycle. low priority specs are at risk.

  • Alpha3 subcycle status (ttx)

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

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

  • Bug 597387: Maverick EC2 kernel issue

  • Bug 576066: ums-cypress.ko missing from server installer

  • atop kernel patch

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

• Weekly SRU review (zul)

  • Nominations review (see thread)

  • SRU Tracker status

• Rubygems in Ubuntu (SpamapS)
• Apport hooks call for participation (zulcss)
• Open Discussion
• Announce next meeting date and time
  • Tuesday 2010-07-20 at 1800 UTC - #ubuntu-meeting

Minutes

Review ACTION points from previous meeting

• sommer waiting on mdke re: refresh issue: DONE

Maverick development (jib)

• Alpha3 subcycle status (ttx)

  • Many specs are not showing as far along as we'd like. Please make sure you keep your specs up to date.

Weekly Updates & Questions for the QA Team (hggdh)

• server-maverick-qa-workflow is coming along well.

• ACTION: hggdh will discuss the outcome of this spec in ServerMeeting at some point in the future

Weekly Updates & Questions for the Kernel Team (jjohansen)

• Bug 597387: Maverick EC2 kernel issue: We received confirmation from Amazon contacts that pv-ops kernels work on EC2 and that they need xsave hypercall disabled

• Bug 576066: ums-cypress.ko missing from server installer: Tim is taking care of this.

• atop kernel patch

  • A thread (June, July) on the mailing list has been started, but there have been only a handful of responses. At the moment it looks unlikely that this is something the kernel team would pick up to support.

  • SpamapS has used atop and have had others use it difficult problems. He and jib will add to thread.

  • SpamapS brought up KSLM as 'probably "the right way" for atop to function'

• Bug 574910: "High load averages on Lucid while idling": load (per /proc/loadavg) is appearing higher than it should on ec2 lucid instances. This is causing some people to hesitate to move to lucid. jjohansen believes it to be an accounting issue more than an actual load issue. He expects to take a deeper look at this.

Weekly Updates & Questions for the Documentation Team (sommer)

• ACTION: sommer to check on getting some cloud-init / cloud-config doc. smoser should be available to help.

Weekly SRU review (zul)

• SRU Tracker status

• Discussed 3 bugs (579584, 598649, 603363), only one with actual discussion was 598649. That one appears like it would be difficult to backport, as it would require pulling back a lot.

Rubygems in Ubuntu (SpamapS)

• There was much discussion on Rubygems, and how to make users of ruby gems happy with Ubuntu's packaging. Mathiaz has worked on this in the past and not had much success.

• the main issue was that Rubygems executables are put into /var/lib/rubygems, which is not in PATH and uncommon. The ServerTeam expects to discuss this more at the Platform Rally next week.

• ACTION: SpamapS to send mail to -devel to get ruby community position on ruby gems in ubuntu.

Apport hooks call for participation (zulcss)

• There is an open call out for participation for more apport hooks for server packages. Jos mentioned this in a recent mail, and more should be coming from zulcss.

Open Discussion

• smoser mentioned new EC2 Cluster Compute, that uses HVM. Hardware assisted Virtualization Mode is new for EC2, and only available for the cluster compute instances. Right now there are no available EC2 images for these instance-types. It is unclear what would need to be done to get ubuntu images for this.

Agree on next meeting date and time

Next meeting will be on Tuesday, July 27 at 18:00 UTC in #ubuntu-meeting.

Log

[19:02] <smoser> #startmeeting
[19:02] <MootBot> Meeting started at 13:02. The chair is smoser.
[19:02] <MootBot> Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE]
[19:02] <smoser> https://wiki.ubuntu.com/ServerTeam/Meeting
[19:03]  * ttx bows to the Big Smoser
=== Ursinha is now known as Ursinha-afk
[19:03] <smoser> #topic Review ACTION points from previous meeting
[19:03] <ttx> [TOPIC] ...
[19:03] <smoser> [TOPIC] Review ACTION points from previous meeting
[19:03] <MootBot> New Topic:  Review ACTION points from previous meeting
[19:03] <smoser> sommer waiting on mdke re: refresh issue
[19:04] <smoser> (that is our only action point)
[19:04] <smoser> sommer, ?
[19:04] <smoser> hm... sommer was here 5 minutes ago.
[19:04] <sommer> I think it was fixed
[19:05] <ttx> yes
[19:05] <sommer> yep it's updated
[19:05] <smoser> ok.
[19:05] <ttx> sommer: thanks !
[19:05] <smoser> [TOPIC] Maverick development (jib)
[19:05] <MootBot> New Topic:  Maverick development (jib)
[19:05] <jiboumans> I sent out the Alpha3 update to the mailinglist the other day
[19:05] <jiboumans> we're mostly on track for the high priority blueprints: http://people.canonical.com/~pitti/workitems/maverick/canonical-server-maverick-alpha-3.html
[19:05] <jiboumans> but we're very heavily loaded this cycle
[19:06] <jiboumans> Low prio blueprints are at risk of being postponed
[19:06] <jiboumans> none-feature stuff can be moved to the Betas, but feature development may have to wait until Maverick+1 for those
[19:06] <jiboumans> Apport hooks are a special case here and we have an agenda item for that further down
[19:06] <jiboumans> ttx, can you take us through the specific blueprints here?
[19:07] <ttx> the specific blueprints that may have to wait, or those that are Low and might need to be postponed ?
[19:07] <jiboumans> sorry, i meant the next item on the agenda
[19:07] <jiboumans> the subcycle tracking :)
[19:07] <ttx> ah!
[19:07]  * jiboumans notices his segway was no where nearly as smooth as imagined
[19:08] <smoser> sorry
[19:08] <smoser> [TOPIC] Alpha3 subcycle status (ttx)
[19:08] <MootBot> New Topic:  Alpha3 subcycle status (ttx)
[19:08] <ttx> I don't have so much to add to your brilliant analysis
[19:08] <SpamapS> jiboumans: more hand waving
[19:08] <ttx> I'd like to have more work items burnt
[19:08] <ttx> since it looks like we didn't do any work, while I know it's not the case
[19:08]  * SpamapS has got a fever, and the only prescription, is more hand waving
[19:09] <jiboumans> seconding what ttx said; several people under 10% completion now is a red flag
[19:09] <SpamapS> ttx: I'm spinning on a few in parallel due to external factors (mostly debian sponsorship/bugs/etc), I'd expect 3 or 4 to go DONE all at once.
[19:09] <ttx> i'll have discussions with spec assignees soon to confirm expectations
[19:10] <ttx> SpamapS: ack, next time try to decorrelate work and sponsoring wait to avoid that
[19:10] <ccheney> my uec provisioning work is very interrelated and i think i can probably get them all done quickly once i get one blocker resolved
[19:10] <ttx> package FOO / package BAR / get sponsoring for FOO and BAR
[19:10] <ttx> that allows to keep the ball smoothly rolling
[19:10] <jiboumans> ccheney: what's your blocking factor?
[19:11] <SpamapS> ttx: we can discuss later to make sure I've done that properly (I think I may have.. and its just that they're all in the "get sponsoring for FOO and BAR" state now)
[19:11] <ttx> SpamapS: ah! that happens :)
[19:11] <ccheney> jiboumans, powerwake seems to need to write to the home directory but when running from apache2 has none, so it blows up
[19:11] <ccheney> jiboumans, i'm not sure how this worked in the past but it doesn't work for me while trying to set it up due to that
[19:12] <ccheney> i thought it was an issue with the machines i was using not waking up properly, which seemed to happen occasionally but the main issue was the home dir problem
[19:12] <jiboumans> ccheney: i assume worst case you can workaround manually and continue testing?
[19:13] <ccheney> jiboumans, well to get it working in a packaged and tested manner i need to get that part resolved asap
[19:13] <ccheney> i emailed kirkland but it appears he may be off atm?
[19:13] <SpamapS> ttx: as a side issue, I need to chat w/ Mathias a bit about some things that aare 90% done in the monitoring spec, so those should roll to DONE or even come off the list altogether after I talk to him.
[19:13] <hallyn> yeah he's at a conf
[19:13] <jiboumans> ccheney: he's at a conference
[19:13] <ccheney> jiboumans, oh ok
[19:14] <ttx> SpamapS: ok, you seem to be on top of it
[19:14] <ccheney> is there a better version of uec.py somewhere other than kirkland's bzr repo? i wasn't sure if it was the main branch
[19:14] <ttx> smoser: that's all from me
[19:15] <smoser> [TOPIC] Weekly Updates & Questions for the QA Team (hggdh)
[19:15] <MootBot> New Topic:  Weekly Updates & Questions for the QA Team (hggdh)
[19:15] <ttx> ccheney: I think kirkland has the most recent one
[19:15] <ttx> ccheney: it's a merge from several code bases, including mine
[19:15] <ccheney> ok
[19:15] <SpamapS> hggdh: Just a comment, I had no idea about the UEC rig, thanks for emailing that info!
[19:16] <jiboumans> hggdh: i see the blueprint for server-maverick-qa-workflow is progressing nicely
[19:16] <hggdh> jiboumans: yes... I had to stop for a while on the UEC testing to cater for the other tasks/blueprints
[19:16] <jiboumans> hggdh: is it worth a section in one of the coming meetings to introduce people to it (or some blog posts?)
[19:17] <hggdh> jiboumans: about the internal UEC rig ?
[19:17] <jiboumans> hggdh: server-maverick-qa-workflow
[19:17] <hggdh> ah. Sorry. Yes, it would be a good idea
[19:18] <jiboumans> hggdh: i trust you'll add it to the agenda when appropriate?
[19:18] <hggdh> jiboumans: albeit trusting me has been proved to be dangerous, yes, I will add it in
[19:18] <jiboumans> hggdh: already editing the blueprint with a WI ;)
[19:18] <hggdh> LOL
[19:19] <smoser> [ACTION] hggdh to discuss server-maverick-qa-workflow at future meeting
[19:19] <MootBot> ACTION received:  hggdh to discuss server-maverick-qa-workflow at future meeting
[19:19] <jiboumans> hggdh: at my age, i can hardly trust my brain to remember things
[19:19] <smoser> moving on ?
[19:19]  * hggdh wonders about self's age...
[19:19] <hggdh> I am done, smoser
[19:19] <smoser> [TOPIC] Weekly Updates & Questions for the Kernel Team (jjohansen)
[19:19] <MootBot> New Topic:  Weekly Updates & Questions for the Kernel Team (jjohansen)
[19:20] <jjohansen> sorry, can't seem to find my notes now
[19:21] <smoser> [TOPIC] Bug 597387: Maverick EC2 kernel issue
[19:21] <MootBot> New Topic:  Bug 597387: Maverick EC2 kernel issue
[19:21] <ubottu> Launchpad bug 597387 in Ubuntu Maverick "pv-ops kernel only works in 3 or 4 zones in EC2" [High,Confirmed] https://launchpad.net/bugs/597387
[19:21] <jiboumans> smoser: did you give me an update on that one yesterday? or was that unrelated?
[19:21] <jjohansen> so we received confirmation from Amazon contacts that pv-ops kernels work on EC2 and that they need xsave hypercall disabled
[19:22] <smoser> i dont think it was related. i dont recall anything yesterday.
[19:22] <smoser> jjohansen is on top of it.
[19:22] <jjohansen> I have built a pv-ops kernel but haven't tested it yet
[19:22] <smoser> so new kernel built and awating test in different regions ?
[19:22] <jjohansen> awaits any boot testing
[19:23] <jjohansen> I just haven't gotten that far yet
[19:23] <jjohansen> but that should happen this afternoon
[19:23] <smoser> great.
[19:23] <jjohansen> Bug #576066
[19:23] <smoser> [TOPIC] Bug 576066: ums-cypress.ko missing from server installer
[19:23] <MootBot> New Topic:  Bug 576066: ums-cypress.ko missing from server installer
[19:23] <ubottu> Launchpad bug 576066 in linux (Ubuntu Lucid) "ums_cypress missing from lucid server cd" [Low,In progress] https://launchpad.net/bugs/576066
[19:23] <jjohansen> Tim has prioritized, and is taking care of this
[19:24] <smoser> [TOPIC] atop kernel patch
[19:24] <MootBot> New Topic:  atop kernel patch
[19:24] <jiboumans> jjohansen: i only saw a handful of replies on the mailing-list
[19:24] <jjohansen> there hasn't been any more input on this yet
[19:25] <jjohansen> as it stands I don't see the kernel team picking up the patches
[19:25] <jiboumans> jjohansen: the use case highlighted of seeing what process is using bandwidth and the historical resource consumption are the two use cases i know
[19:25] <jjohansen> right
[19:25]  * ttx struggles a bit with his connection
[19:25] <jiboumans> if there are alternate tools, that would be good to know of. i dont know any though
[19:26] <jiboumans> jjohansen: do you know of any that could provide that functionality instead?
[19:26] <jjohansen> jiboumans: I am not aware of any either
[19:26] <SpamapS> Honestly, since discovering atop when I first heard about this, I've used it twice for my own issues, and a friend who I told about it used it to solve a pretty serious IO problem on his production servers.
[19:26] <jiboumans> jjohansen: ok, i'll chime in on the thread
[19:26] <SpamapS> atop is t3h awesome
[19:26] <jiboumans> it is
[19:26] <jjohansen> htop is better than top but I don't think it does
[19:26] <jjohansen> SpamapS, jiboumans: please chime in
[19:27] <SpamapS> nothing I've ever seen can tell me which process is doing which IO operations
[19:27] <jiboumans> doing so now
[19:27] <ttx> there is a EC2 performance issue filed against "Ubuntu on EC2", I'm trying (unsuccessfully) to get to its bug number
[19:27] <smoser> [ACTION] jiboumans to chime in on atop thread
[19:27] <MootBot> ACTION received:  jiboumans to chime in on atop thread
[19:27] <smoser> bug 574910: I've been pinged again on this, per erichammond, it is preventing pe
[19:27] <smoser> ople from moving to lucid as perceived performance drop.  It would be really nic
[19:27] <smoser> e to address it.  even if we can't fix it, to clearly state that performance is
[19:27] <smoser> the same as it was or better (maybe some benchmarks?)
[19:27] <ubottu> Launchpad bug 574910 in linux-ec2 (Ubuntu) "High load averages on Lucid while idling" [Undecided,In progress] https://launchpad.net/bugs/574910
[19:27] <jjohansen> jiboumans: also if this is really import let pete/tim know
[19:27] <smoser> (that is ttx's bug probably)
[19:27] <ttx> smoser: yes, thanks
[19:27] <SpamapS> We should also contact the KSLM author about this, which is probably "the right way" for atop to function
=== dharman_ is now known as dharman
[19:28] <jjohansen> smoser: right, in my limited testing it looked like accounting but we need to do some more testing
[19:28] <jjohansen> SpamapS: KSLM?
[19:28] <SpamapS> www.headinthecloud.net  and  http://launchpad.net/kslm
[19:28] <SpamapS> Cole Crawford
[19:29] <jjohansen> ah, thanks
[19:29] <SpamapS> I spoke with him at UDS about some unrelated monitoring stuff..
[19:29] <SpamapS> but I think kslm is an attempt to do what atop does, but in a less invasive way
[19:30] <jjohansen> okay, we need to look into it then
[19:30] <jiboumans> SpamapS: chime in on the thread? :)
[19:31] <smoser> ok. so, we really need to address the bug 574910 one way or another.  I hesitate to ask here for how, as I believe its going to result in work for me.
[19:31] <ubottu> Launchpad bug 574910 in linux-ec2 (Ubuntu) "High load averages on Lucid while idling" [Undecided,In progress] https://launchpad.net/bugs/574910
[19:31] <jiboumans> action smoser to just fix it? ;)
[19:32] <jjohansen> smoser: I will make some time to look at it again tomorrow
[19:32] <smoser> we really, really, really dont want people using our images to stay on karmic or hardy.
[19:32] <jjohansen> the kt is doing a bug day, and its on my list
[19:32] <smoser> jjohansen, ok. thank you. please get something there.  i realize its probably just a bad metric, but it appears at least to be a popular bad metric.
[19:32] <SpamapS> jiboumans: chiming. :)
[19:32] <smoser> anyone have anything else for jjohansen ?
[19:33] <jiboumans> jjohansen: smells of io
[19:33] <jiboumans> jjohansen++ # kernel hackery
[19:33]  * jjohansen needs a shower
[19:33] <smoser> [TOPIC] Weekly Updates & Questions for the Documentation Team (sommer)
[19:33] <MootBot> New Topic:  Weekly Updates & Questions for the Documentation Team (sommer)
[19:33] <sommer> don't have anything new this week, but should have some updates for next week
[19:34] <sommer> anyone else have questions comments for me?
[19:35] <jiboumans> sommer: maybe out of your scope, but i get questions about cloud-init / cloud-config regularly
[19:35] <jiboumans> are we covering this in our docs as well?
[19:35]  * smoser ducks
[19:35] <sommer> jiboumans: not too sure, but I can definitely check on that for next week
[19:35] <jiboumans> it's mostly 'how do i..' and then 'oh that is so easy with cloud-*'
[19:35] <smoser> [ACTION] sommer to check on getting some cloud-init / cloud-config doc
[19:35] <MootBot> ACTION received:  sommer to check on getting some cloud-init / cloud-config doc
[19:36] <jiboumans> sommer: that'd be great. they're amazing tools but not everyone's discoverd them yet
[19:36] <sommer> cool, I'll focus on updating that section
[19:36] <jiboumans> sommer++ thanks
[19:36] <smoser> [TOPIC] Weekly SRU review (zul)
[19:36] <MootBot> New Topic:  Weekly SRU review (zul)
[19:36] <jiboumans> ttx, can you take that?
[19:36] <jiboumans> zul's at a conference today and i dont think he managed to join in
=== Andre_Gondim is now known as Andre_Gondim-afk
[19:38] <zul> actually im here briefly
[19:38] <jiboumans> awesome
[19:38] <jiboumans> zul: then, if you don't mind
[19:38] <zul> we have recieved 2 requests this week
[19:39] <zul> the list went out on monday both are virt related i dnot have the bug numbers in front of me though
[19:39] <zul> so they will be looked at on friday and be added to the list for next week
[19:39] <hallyn> bug #579584
[19:39] <ubottu> Launchpad bug 579584 in libvirt (Ubuntu) "setgid, setuid needed by /etc/apparmor.d/abstractions/libvirt-qemu" [Medium,Fix released] https://launchpad.net/bugs/579584
[19:40] <zul> thats one of them ;)
[19:40] <smoser> i nominated bug 598649 .
[19:40] <ubottu> Launchpad bug 598649 in qemu-kvm (Ubuntu) "cannot boot grub multiboot image with kvm -kernel" [Medium,Fix released] https://launchpad.net/bugs/598649
[19:40] <smoser> it will require some hallyn work, but a working backport would allow us to run maverick guests with instance-servicable kernels in lucid hosts.
[19:40] <hallyn> smoser: hm, the problem with that one is we'd have to do pretty big updates for kvm+seabios for lucid
[19:41] <smoser> hallyn, yeah. i expected that as a possibility.
[19:41] <hallyn> i.e. we'd have to update to qemu 12.4
[19:41] <jiboumans> the other is bug #603363
[19:41] <ubottu> Launchpad bug 603363 in openssh (Ubuntu) "sshd never stops, prevents umount of /usr partition" [Medium,Fix released] https://launchpad.net/bugs/603363
[19:41] <zul> unfortunately the wireless here is sucking
[19:42] <zul> so thats it for me
[19:42] <smoser> [TOPIC] Rubygems in Ubuntu (SpamapS)
[19:42] <MootBot> New Topic:  Rubygems in Ubuntu (SpamapS)
[19:42] <SpamapS> Right
[19:43] <SpamapS> Its unfortunate that Mathiaz isn't here so he can comment on the past, but I'll share the current
[19:43] <SpamapS> everybody who uses ruby, uses rubygems.. and it is horribly broken for most people in Debian and ubuntu
[19:44] <SpamapS> the main gripe is that it stores binaries that would normally be placed in /usr/bin or (by configuration) /usr/local/bin, in /var/lib/rubygems
[19:44] <SpamapS> s/binaries/executables/
[19:44] <SpamapS> So at Velocity and DevOps days, after discussing with quite a few ruby developers who love ubuntu but hate ubuntu's rubygems, we need to come up with a strategy to make sure ruby developers can use rubygems the way they expect to.
[19:45] <SpamapS> mathiaz tried to "fix" this 2 years ago but had his upload reverted.
[19:46] <smoser> so do we want to add this to next weeks agenda with Mathiaz here and leave this as a teaser ?
[19:46] <SpamapS> Any thoughts on this issue? I feel strongly that it should place files in /usr/local/bin but the debian developer disagrees and says that FHS requires it go in /var/lib
[19:46] <zul> i dont think anything should be placed in /usr/local/bin
[19:46] <zul> sorry laggy
[19:46] <SpamapS> I'd like to make sure we all come to the sprint educated on the issue so we can leave Prague with an action plan.
[19:47] <SpamapS> zul: we allow CPAN to do that.
[19:47] <SpamapS> and every autoconf script out there puts things in /usr/local
[19:47] <smoser> SpamapS, by default cpan on ubuntu/debian puts things in /usr/local ?
[19:48] <SpamapS> smoser: as I type this, I'm not 100% sure that it does. I think my memory is based entirely on redhat's CPAN. :-/
[19:48] <SpamapS> which does /usr/bin
[19:49] <SpamapS> But it remains an important issue
[19:49] <smoser> usr/bin just seems dirty.
[19:49] <jiboumans> cpan on debian didn't used to be well behaved
[19:49] <jiboumans> let me check
[19:49] <SpamapS> users want these executables in their path
[19:49]  * ttx is kinda back
[19:49] <ttx> at ~40% packet loss
[19:49] <jiboumans> yeah, i think cpan is still naughty
[19:49] <SpamapS> it breaks things mightily for the executables to be in /var/lib (which some might argue, can be mounted noexec)
[19:50] <smoser> so what do we want to do here ?
[19:50] <jiboumans> $ perl -MConfig -le'print $Config{installbin}'
[19:50] <jiboumans>  /usr/bin
[19:50] <SpamapS> jiboumans: doh
[19:51] <SpamapS> smoser: we want to make sure users can use the software the way they want to.
[19:51] <jiboumans> spamaps: this is what local::lib and INSTALLDIRS=site is for, but it's not the default
[19:51] <SpamapS> smoser: without encouraging stupidity. ;)
[19:51] <SpamapS> right now, *everybody* reinstalls rubygems from source
[19:51] <smoser> well, i meant regarding this discussion.
[19:51] <SpamapS> the options we came up with were:
[19:52] <SpamapS> a) switch to using the embedded rubygems from ruby 1.9
[19:52] <ttx> SpamapS: if you haven't had this discussion with mathiaz, you should
[19:52] <ttx> SpamapS: he got burnt in those waters already
[19:52] <SpamapS> b) attempt to re-do the change mathiaz did, after discussion with motu council
[19:53] <SpamapS> c) attempt to wrest control of the debian package away from people by calling attention to  the fact that nobody likes the way it works now.
[19:53] <SpamapS> ttx: mathiaz and I discussed it at length with several ruby users and authors including the Chef guys.
[19:53] <ttx> SpamapS: ok, I was missing some context, I see
[19:54] <SpamapS> ttx: Jos also had some other discussions on the same vein.
[19:54] <zul> `maybe send an email to -devel and -serve to get more feedback
[19:54] <SpamapS> Either way, it was by far the most common complaint I got about Ubuntu Server at velocity.
[19:54] <jiboumans> agreed
[19:54] <jiboumans> it's a recurring theme for me
[19:55] <jiboumans> i'm open to any route forward, just not one that leaves an essential package in a state that the its users can't actually use
[19:55] <ttx> SpamapS: it's good for me to see it's no longer about how much our Tomcat sucks
[19:55] <SpamapS> ttx: :-D
[19:55] <jiboumans> ttx++ # fixing tomcat ;)
[19:55] <smoser> mdz blogged on related topic recently: http://mdzlog.alcor.net/2010/07/06/weve-packaged-all-of-the-free-software-what-now/
[19:56] <smoser> (not to just name drop, but i think it is generally larger than just ruby, and growing.
[19:56] <smoser> are we ready to move on ?
[19:56] <smoser> we're back to zul
[19:56] <smoser> [TOPIC] Apport hooks call for participation (zulcss)
[19:56] <MootBot> New Topic:  Apport hooks call for participation (zulcss)
[19:56] <jiboumans> hang on
[19:56] <SpamapS> Lets find the biggest ruby community(ies) and ask for their guidance. Maybe a huge community outpouring of need will be enough to enact change.
[19:56] <jiboumans> what action are we taking SpamapS?
[19:56] <smoser> sorry.
[19:56] <SpamapS> ^^
[19:57] <SpamapS> should I contact jcastro?
[19:57] <jiboumans> spamaps: adam and james will also be able to point you at relevant communities
[19:57] <jiboumans> and yes, contact jcastro
[19:57] <jiboumans> spamaps: is there anything that would be required to be resolved before feature freeze for it to make maverick?
[19:58] <jiboumans> or is maverick too optimistic?
[19:58] <SpamapS> jiboumans: not sure.
[19:58] <SpamapS> if you ask me, the package is 100% broken and this is SRU worthy given users complete abandonment of the package.
[19:59] <jiboumans> SpamapS: think about the options in that context too.. i'd love to see something workable already in maverick
[19:59] <smoser> well, nothing is SRU worthy unless fixed in development release.
[20:00] <jiboumans> SpamapS: can you get the discussion rolling and update us next week in prague?
[20:00] <jiboumans> we'll then revisit here in the next irc meeting
[20:00] <SpamapS> Yes I will email -devel and try to get the ruby community's position before next Tuesday.
[20:01] <smoser> [ACTION] SpamapS to send mail to -devel to get ruby community position on ruby gems in ubuntu
[20:01] <jiboumans> smoser, action spamaps please?
[20:01] <MootBot> ACTION received:  SpamapS to send mail to -devel to get ruby community position on ruby gems in ubuntu
[20:01] <jiboumans> thanks :)
[20:01] <smoser> now moving on ?
=== zyga is now known as zyga_
[20:01] <jiboumans> yes please
[20:01] <smoser> [TOPIC] Apport hooks call for participation (zulcss)
[20:01] <MootBot> New Topic:  Apport hooks call for participation (zulcss)
[20:01] <smoser> zul,
[20:02] <jiboumans> i'll take that one
[20:02] <jiboumans> zul's connection is flaky
[20:02] <jiboumans> so, as i mentioned above, our commitment for Alpha3 is quite high
[20:02] <jiboumans> and that means we're not likely to get many new apport hooks this cycle
[20:03] <jiboumans> and that'd be a real shame.
[20:03] <jiboumans> as this project is shaped very much like papercuts are, Zul wanted to issue a call for participation, both for apport hooks suggestions, but more importantly also for contributions
[20:03] <jiboumans> I highlighted this in the Alpha3 update here: https://lists.ubuntu.com/archives/ubuntu-server/2010-July/004411.html
[20:04] <jiboumans> and zul will be sending out something specific to apport hooks in the next day or two
[20:04] <jiboumans> if you have some spare cycles and have a package you care about with apport hooks, please consider contributing one!
[20:04] <jiboumans> I hope i represented zul's thoughts well there
[20:04] <jiboumans> smoser: that's it from me
[20:04] <smoser> [TOPIC] Open Discussion
[20:05] <MootBot> New Topic:  Open Discussion
[20:05] <smoser> i have one, just a re-announcement:
[20:05] <smoser> ec2 cluster compute : http://aws.typepad.com/aws/2010/07/the-new-amazon-ec2-instance-type-the-cluster-compute-instance.html .  for $1408/hour you can have a top 500 supercomputer.  Interesting things to note here is that cluster-compute nodes have to be HVM.  Right now, there are no ubuntu HVM nodes, and its very unclear how you would even create one other than running 'ec2-create-snapshot' from inside one.
[20:06] <ttx> smoser: what's HVM ?
[20:07] <smoser> (note, the $1408/hour is 880 * $1.6, which places 146 on Top 500)
[20:07] <ttx> Thanks everyone for assigning yourself to papercuts... don't forget to fix them before the end of the subcycle !
[20:07] <smoser> HVM is hardware assisted virtualization.  basically kvm but on xen.
[20:07] <smoser> its using the same infrastructure that windows instances previously used. (at least it seems to be)
[20:08] <smoser> ok. nothing else, then
[20:08] <smoser> [TOPIC] Announce next meeting date and time
[20:08] <MootBot> New Topic:  Announce next meeting date and time
[20:08] <SpamapS> smoser: so is it something that is already on our radar to support, or did this come out of left field?
[20:08] <smoser> well, most everything comes out of left field for ec2.
[20:08] <SpamapS> :)
[20:09] <smoser> our relationship is improving, and i hope that results in better previews of this sort of thing.
[20:09] <smoser> the hvm is something htat i always expected they'd do.
[20:10] <smoser> but it is currently only available on the cluster compute isntance types.
[20:10] <smoser> anyway.
[20:10] <smoser> The meeting next week will be
[20:10] <smoser> Tuesday 2010-07-20 at 1800 UTC - #ubuntu-meeting
[20:10] <jiboumans> team, please join me on a phone call
[20:10] <jiboumans> thanks all!
[20:10] <ttx> jiboumans: that would be 8pm for most of us, next week
[20:11] <smoser> yeah,
[20:11] <smoser> was going to mention that.
[20:11] <jiboumans> ah, good catch
[20:11] <jiboumans> usually we skip the irc meeting during a sprint week
[20:11] <jiboumans> and i think it's advisable to do so this sprint too
[20:11] <ttx> yes
[20:11] <smoser> unless someone objects, then we'll resume our regularly scheduled program on
=== MTeck is now known as MTecknology
[20:11] <smoser> Tuesday 2010-07-27 at 1800 UTC - #ubuntu-meeting
[20:11] <jiboumans> smoser++ # thanks for chairing
[20:12] <smoser> thank you, and good night.
[20:13] <smoser> #endmeeting
[20:13] <MootBot> Meeting finished at 14:13.