20100106

Agenda

Minutes

Previous actions points

Non-alpha2 targeted specs for lucid

  • server-lucid-aws-client-libraries

    • MathiasGug needs input from community on which libraries to package

    • MathiasGug to send an email to ubuntu-cloud@, ubuntu-ec2@ and blog about it

    • ACTION jib to complete Perl list for AWS client libs

    • ACTION nijaba to complete PHP list for AWS client libs

    • ACTION Mathiaz to send out AWS Client lib RFC

    • NOTE: Regarding the Perl API, EricHammand notes: There is a *different* Amazon::SimpleDB on CPAN which is not high quality, not maintained, and the author did not respond to my questions about its status. My ideal solution would be for Amazon's package to be renamed to Net::Amazon::SimpleDB and added to CPAN and then libnet-amazon-simpledb in Ubuntu.

  • server-lucid-cluster-stack

    • ivoks has it packaged at https://edge.launchpad.net/~ivoks/+archive/ppa/+packages

    • pacemaker might be a decent replacement for redhat-cluster-suite
    • ivoks to blog a call for testing
    • ivoks to add work items to his blueprint

    • ACTION ivoks to update server-lucid-cluster-stack with lucid (and alpha3) goals

  • lucid-serverguide

    • JosBoumans suggests a weekly meeting item, asking for server guide changes

    • AdamSommer doesn't think it's needed yet, but will ask for it if becomes needed

  • server-lucid-contextualization

    • not yet targeted, StefanGraber says updated userspace + tested libvirt could be targeted at Alpha3

    • SorenHansen mentioned some potential issues between LXC and upstart

    • lxc needs an MIR, should be straight-forward, StefanGraber to file the MIR

    • libvirt 0.7.5

      • JamieStrandboge mentions that it would be nice to get libvirt 0.7.5 into Lucid, StefanGraber agrees, as there are some LXC enhancements in 0.7.4

      • JamieStrandboge will do the merge

      • Long discussion ensued, see the full log

  • server-lucid-asterisk-integration

    • ACTION: jmdault to update server-lucid-asterisk-integration blueprint with alpha3 & post-alpha3 workitems and change syntax to match Pitti's workitems WorkItemsHowto

  • server-lucid-papercuts

    • ACTION: ThierryCarrez to send background mail on papercuts project for next weeks discussion

blueprint status check

assigned bugs: http://qa.ubuntu.com/reports/team-assigned/canonical-server-assigned-bug-tasks.html

  • Keep your bugs up to date

weekly Q&A with QA

  • SorenHansen has nightly builds of some server packages

    • libvirt, postgresql, mysql, openldap, php5

  • ACTION: SorenHansen to solicit packages that lend them selves well to nightly builds

  • ACTION: ScottMoser to investigate publishing new AMIs

Q&A with the kernel team (jjohansen)

weekly SRU review (MathiasGug)

  • Jaunty, 117736

    • to decline

  • Karmic, 379329

    • to be handled by Security Team

open discussion

  • Brief discussion about ubuntu-server bug contact for some packages

Agree on next meeting date and time

Next meeting will be on Wednesday, January 13th at 14:00 UTC in #ubuntu-meeting.

Log

[14:00] <jiboumans> #startmeeting
[14:00] <MootBot> Meeting started at 08:00. The chair is jiboumans.
[14:00] <MootBot> Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE]
[14:00] <jiboumans> [TOPIC] Previous actions points
[14:00] <MootBot> New Topic:  Previous actions points
[14:01] <zul> mathiaz: lay off the alcohol
[14:01] <jiboumans> only one outstanding, one me to check with the foundations team what to do with ecryptfs.
[14:01]  * ivoks o/
[14:01] <jiboumans> looks like we'll be moving maintenance to the foundations team, but it's pending an OK from colin & hugh. more next week probably
[14:02] <jiboumans> now, to the more interesting bits:
[14:02] <alexm> o/
[14:02] <kirkland_> jiboumans: thx
[14:02] <jiboumans> [TOPIC] Non-alpha2 targeted specs for lucid
[14:02] <MootBot> New Topic:  Non-alpha2 targeted specs for lucid
[14:02] <jiboumans> we have a list of 6'ish specs we'd like to dicuss here today. if all is well, ttx mailed the relevant drafters/assignees
[14:03] <jiboumans> i saw mathiaz here, so let's start there:
[14:03] <jiboumans> server-lucid-aws-client-libraries (mathiaz)
[14:04] <jiboumans> mathiaz: to get the ball rolling on this, what do you need from us and the community?
[14:04] <mathiaz> https://blueprints.launchpad.net/ubuntu/+spec/server-lucid-aws-client-libraries
[14:04] <mathiaz> jiboumans: decide which libraries are worth packaging
[14:04] <mathiaz> jiboumans: ie which ones are the most used
[14:04] <mathiaz> jiboumans: and if there is anything missing
[14:05] <mathiaz> jiboumans: next step: send an email to ubuntu-cloud@, ubuntu-ec2@ and blog about it
[14:05] <jiboumans> mathiaz: fair enough. Looks like we have the following languages we're looking to target: Python Perl Php Java Ruby Twisted
[14:05] <mathiaz> jiboumans: well - the first two WI
[14:05] <jiboumans> do we have any resident experts on any of those languages?
[14:05] <erichammond> Perl here
[14:05] <jiboumans> jiboumans: perl
[14:06] <jiboumans> erichammond: are you ok with us sharing the action to fill in that list?
[14:06] <mathiaz> both perl and python seems covered
[14:06] <mathiaz> only java is missing
[14:06] <jiboumans> mathiaz: php/ruby?
[14:06] <mathiaz> which is the other langage that has projects listed
[14:06]  * nijaba` can volunteer some php testing
[14:06] <erichammond> jiboumans: I'm ok with you doing it all :) but can help where needed.  I just added a link to Amazon's Amazon::SimpleDB
[14:07]  * zul thinks php is evil
[14:07] <zul> and ruby
[14:07] <jiboumans> erichammond: fair enough, won't take me long anyway
[14:07]  * nijaba` is evil anyway :P
[14:07] <mathiaz> jiboumans: I don't know if there any projects written in these langages
[14:07] <mathiaz> jiboumans: more invesitigation is needed
[14:07] <jiboumans> [ACTION] jib to complete Perl list for AWS client libs
[14:07] <MootBot> ACTION received:  jib to complete Perl list for AWS client libs
[14:07] <jiboumans> [ACTION] nijaba to complete PHP list for AWS client libs
[14:07] <MootBot> ACTION received:  nijaba to complete PHP list for AWS client libs
[14:07] <jiboumans> mathiaz: cool, then you get to mail people about that :)
[14:08] <jiboumans> [ACTION] Mathiaz to send out AWS Client lib RFC
[14:08] <MootBot> ACTION received:  Mathiaz to send out AWS Client lib RFC
[14:08] <jiboumans> mathiaz: think we can have that list complete by next meeting?
[14:08] <mathiaz> jiboumans: sure
[14:09] <jiboumans> cool. bonus points if we can get community packaging efforts going *hint hint* ;)
[14:09] <jiboumans> mathiaz: anything else for this spec?
[14:09] <ttx> jiboumans: let's harness our huge java packaging community :)
[14:09] <mathiaz> jiboumans: not for now
[14:09] <jiboumans> ttx: well volunteered!
[14:10] <jiboumans> ok, moving on
[14:10] <jiboumans> daviey, dufet: o/
[14:10] <ivoks> ]
[14:10] <ttx> dyfet ^
[14:10] <jiboumans> dyfet also
[14:10] <erichammond> jiboumans: There is a *different* Amazon::SimpleDB on CPAN which is not high quality, not maintained, and the author did not respond to my questions about its status.  My ideal solution would be for Amazon's package to be renamed to Net::Amazon::SimpleDB and added to CPAN and then libnet-amazon-simpledb in Ubuntu.
[14:10] <jiboumans> erichammond: ack
[14:10] <jiboumans> kirkland: don't miss that in the summary please ^
[14:11] <jiboumans> ok, both not around yet, trying again in am inute
[14:11] <kirkland_> jiboumans: got it!
[14:11] <jiboumans> ivoks, roaksoax: server-lucid-cluster-stack
[14:11] <ivoks> i'm here
[14:12] <ivoks> i've packaged most of the relveant stuff for pacemaker based cluster
[14:12] <ivoks> everything is on my PPA (https://edge.launchpad.net/~ivoks/+archive/ppa/+packages)
[14:12] <jiboumans> cool. are you targeting anything else for lucid as part of that spec?
[14:12] <ivoks> so, i'll be testing latest version of pacemaker during this week and give a proposal on which cluster stack to use in lucid, stay with rhcs or move to pacemaker
[14:13] <mathiaz> ivoks: what are the consequence for redhat-cluster-suite?
[14:13] <mathiaz> ivoks: It's related to the demotion of redhat-cluster-suite to universe
[14:13] <ivoks> mathiaz: if pacemaker ends up good, i'd agree with rhcs dmotion
[14:13] <mathiaz> ivoks: ok
[14:14] <ivoks> but if pacemaker isn't there yet, i don't think we should ship lts without cluster solution
[14:14] <mathiaz> ivoks: I'd suggest to do a call for testing via a blog post to get more feedback on pacemaker
[14:14] <mathiaz> ivoks: and your ppa packages
[14:14] <ivoks> that's the plan, right
[14:14] <ttx> ivoks: s/without/waithout a supported/ ?
[14:14] <ivoks> ttx: right
[14:15] <ivoks> sorry for not doing this sooner, i had very little time :(
[14:15] <jiboumans> ivoks: i'm keen to track this spec as we do with our other blueprints. could you list the TODOs for lucid in the blueprint as described here? https://wiki.ubuntu.com/WorkItemsHowto
[14:15] <ivoks> jiboumans: consider it done
[14:15] <jiboumans> ivoks++ thanks
[14:15] <ivoks> (i've seen your comment)
[14:16] <jiboumans> ivoks: i'm particularly interested in the items that need to be done for alpha3 obviously
[14:16] <jiboumans> ivoks, anyone else: anything more on this spec?
[14:16] <ivoks> when is alpha3?
[14:16] <jiboumans> ivoks: 25th of feb
[14:16] <soren> Feb 25th.
[14:16] <jiboumans> ivoks: https://wiki.ubuntu.com/LucidReleaseSchedule # for the full list
[14:16] <mathiaz> ivoks: https://wiki.ubuntu.com/LucidReleaseSchedule
[14:17] <ivoks> packages and testing should be done, and we should have clear vision what should be supported cluster
[14:17] <ivoks> (i'm on GPRS connection, so i might be lagged)
[14:17] <jiboumans> ivoks: awesome. anyone have somethign to add still?
[14:17] <nijaba`> ivoks: or http://people.ubuntu.com/~vorlon/UbuntuReleaseSchedule.ics
[14:18] <jiboumans> ok, moving on: lucid-serverguide (sommer)
[14:18] <jiboumans> sommer: i realise this is a docs project, but i'm sure we can make your life easier somehow
[14:18] <sommer> heh, that'd be great... I haven't had much time recently to work on the serverguide, but there have been some bug fixes committed
[14:19] <sommer> should have more time in the coming weeks as well
[14:19] <nijaba`> sommer: you did see that www.ubuntu.com/server/doc now works, right?
[14:19] <sommer> yep, good stuff :)
[14:19] <nijaba`> sommer: do you need with the wiki linking we talked about?
[14:20] <nijaba`> s/need/need help/
[14:20] <sommer> I think I should be able to handle that... it's at the top of my list, but if you'd like to setup some of the pages that'd be great too
[14:21] <jiboumans> [ACTION] ivoks to update server-lucid-cluster-stack with lucid (and alpha3) goals
[14:21] <MootBot> ACTION received:  ivoks to update server-lucid-cluster-stack with lucid (and alpha3) goals
[14:21] <jiboumans> (before i forget)
[14:21] <nijaba`> sommer: ok, let's talk about it off meeting
[14:21] <jiboumans> sommer: would it be helpful to have a weekly agenda point in this meeting for us to give updates on big changes and/or for you to ask questions?
[14:21] <sommer> nijaba`: sounds good
[14:22] <sommer> jiboumans: possibly, but the last couple of meetings I've had to duck out early
[14:22] <jiboumans> sommer: we can move the topic forward if that's useful to you
[14:22] <jiboumans> we're here all week^Whour
[14:23] <sommer> I think I can keep up... just need to ask more questions when I fall behind
[14:24] <jiboumans> sommer: ok. if you change yoru mind, i'm happy to give it a dedicated slot. we really appreciate the work that goes into this doc and want to make it as painless as possible
[14:24] <jiboumans> anything else for the docs blueprint?
[14:24] <sommer> jiboumans: sounds great much thanks
[14:24] <jiboumans> sommer: np
[14:24] <jiboumans> alright, moving on:
[14:25] <jiboumans> soren, jdstrand, stgraber: server-lucid-contextualization
[14:25] <jiboumans> stgraber: it's currently not milestoned; are you still dedicated to getting this in for lucid?
[14:25] <stgraber> yep
[14:26] <jiboumans> great. what is left for you to do when soren/jdstrand finish there bugs/items?
[14:26] <stgraber> I'm sorry, I'm on the phone at the same time
[14:26] <jiboumans> stgraber: no worries, should we do papercuts first?
[14:27] <stgraber> just finished my call
[14:27] <stgraber> so, I have on my todolist to check the state of current libvirt in Lucid + the lxc tool
[14:27] <stgraber> I contacted the Debian maintainer for the lxc userspace and he told me he was going to update it to current upstream
[14:27] <soren> I remember there were some issues with upstart and containers.
[14:28] <stgraber> once it's done, I'll get that synced in Lucid and will try to get a MIR on that
[14:28] <jiboumans> stgraber: does that sound realistic before alpha3?
[14:28] <jiboumans> (feb 25th)
[14:28] <stgraber> yes, upstart, especially umount can cause some issues with containers. Last time I tried Lucid containers worked correctly at least
[14:28] <stgraber> otherwise, I'm getting quite familiar with mountall due to LTSP bugs I'm helping debug from time to time, so it shouldn't be that hard to make it work properly
[14:29] <stgraber> jiboumans: updated userspace + tested libvirt by then sounds perfectly realisitc
[14:29] <stgraber> *realistic
[14:29] <soren> stgraber: I thought the problems were more fundamental than that.
[14:29] <soren> stgraber: Such as upstart not dealing very well at all with not properly being pid 1.
[14:29] <jiboumans> stgraber: we'd also need to have the package in main by then, if i'm getting alpha3's milestone right (ttx, correct me if i'm wrong)
[14:29] <stgraber> soren: at least on OpenVZ I can start a Lucid container including upstart
[14:30] <soren> (as in, it did not inherit orphan processes inside containers)
[14:30] <stgraber> soren: it's PID 1 (inside the container), it's not when seen from the host
[14:30] <soren> stgraber: Precisely.
[14:30] <ttx> jiboumans: before featurefreeze, to be precise.
[14:30] <stgraber> jiboumans: I can file a MIR for it
[14:30] <Daviey> \o
[14:30] <stgraber> jiboumans: only depends for it is libc6
[14:31] <Daviey> apologies for being late, for some reason i thought it started in 30 mins
[14:31] <jiboumans> Daviey: asterisk next, stay tuned :)
[14:31] <stgraber> upstream is active, it's maintained in Debian and there's no known security issues, so it's going to be an easy one
[14:31] <jmdault> hello Daviey
[14:31] <Daviey> \o jmdault
[14:31] <jiboumans> stgraber: if you feel you can get all that done for alpha3, that'll be great
[14:31] <jiboumans> stgraber, soren, jdstrand, ttx: anything else that may be a redflag?
[14:31] <jdstrand> the one task I had is completed
[14:32] <soren> jiboumans: Not at the moment.
[14:32] <stgraber> jiboumans: I'll get that to a point where we can focus on bugfix after alpha3. So that probably won't be bugfree but at least all pieces will be there.
=== robbiew_ is now known as robbiew
[14:32] <jiboumans> stgraber: that's perfect
[14:32] <jdstrand> I might mention, it would be nice to get libvirt 0.7.5 in for lucid
[14:32] <stgraber> jiboumans: +1
[14:32] <kirkland> jdstrand: are you planning to do that merge?
[14:32] <stgraber> jdstrand: +1 I mean ;)
[14:32] <jdstrand> there is an issue there cause Debian decided to run libvirt as non-root using upstream's new methods
[14:32] <jiboumans> stgraber: could i ask you to update the blueprint to reflect the work items we just discussed? (upstreams, tests, mir, etc)
[14:33] <stgraber> jiboumans: sure
[14:33] <jdstrand> how they implemented that is a) contentious and b) will likely require a *lot* of testing to make sure it doesn't break
[14:33] <ttx> jiboumans: looks good to me, pending the work items list
[14:33] <jiboumans> [ACTION] stgraber to update work item list for server-lucid-contextualization with alpha3 items
[14:33] <MootBot> ACTION received:  stgraber to update work item list for server-lucid-contextualization with alpha3 items
[14:34] <jdstrand> I was thinking I would do that merge, but disable that feature, since we have apparmor protections anyway, but it probably needs further discussion
[14:34] <jdstrand> I don't really have the resources to test it without disabling the feature
[14:34] <jiboumans> jdstrand: would that be part of this spec, or merely related?
[14:35] <jdstrand> jiboumans: I think related, unless stgraber really needs 0.7.5
[14:35] <jdstrand> and the non-root stuff is definitely non-lxc
[14:35] <jdstrand> it just complicates the merge and testing (eg what will happen to euca if libvirt is non-root?)
[14:36] <jdstrand> err... libvirt runs VMs as non-root
[14:36] <jdstrand> I don't have an answer to that question, or the resources to verify it all will work
[14:36] <stgraber> jdstrand: I had lxc to work with 0.7.2 though there was quite a lot of improvement in 0.7.4 (nothing in 0.7.5 itself though)
[14:36] <jiboumans> soren, ttx: opinions welcome here
[14:36] <kirkland> jdstrand: i like the idea of using your apparmor stuff, and running libvirt as root (as upstream upstream does)
[14:36] <kirkland> jdstrand: for Lucid, at least
[14:37] <soren> jdstrand: How does what Debian does differ from what Fedora does?
[14:37] <jdstrand> kirkland: that was my thought too-- we are protected, and I will be doing more work on the security driver anyway
[14:37] <kirkland> jdstrand: +1
[14:37] <jdstrand> soren: I don't know, but I imagine fedora will be moving to non-root
[14:37] <jdstrand> when, I can't say
[14:37] <soren> jdstrand: AFAIK, they've already done that.
[14:38] <kirkland> jdstrand: on a related note, i'm working on the qemu-kvm-0.12 merge, to be done shortly after Alpha2
[14:38] <ttx> I'd go for 0.7.5 with apparmor as well, lucid is no place to get experimental
[14:38] <jdstrand> soren: what are your thoughts on the non-root stuff?
[14:39] <soren> 19:08 < danpb> unit3: yeah, but in Fedora,  the qemu process itself runs  as 'qemu' these days
[14:39] <soren> From #virt yesterday.
[14:39] <jdstrand> I'd like to be clear-- the apparmor driver would be there regardless, it is whether or not to risk the non-root bits too
[14:39] <jiboumans> ttx: agreed. the question is 'keep the current version or 0.7.5+apparmor' -- no other configuration is safe enough i think
[14:39] <jdstrand> the apparmor driver is upstreamed and in 0.7.5, and works fine
[14:39] <soren> The problem is we might end up running libvirt in a way noone else is running it.
[14:39] <ttx> slightly more costly (debian delta) to go 0.7.5+apparmor, but I guess lots of bugfixes
[14:39] <soren> ...which is simply a /different/ kind of maintenance nightmare.
[14:40] <jiboumans> ok, then let me rephrase: what do we loes by staying with current version?
[14:40] <jdstrand> soren: well, we are already in that boat with enabling the apparmor driver
[14:40] <soren> jdstrand: True.
[14:40] <jdstrand> (I also field those bugs, btw)
[14:40] <ttx> jiboumans: stgraber might hate you
[14:40] <jdstrand> (as upstream and in ubuntu)
[14:40] <soren> jdstrand: The point of contention is the fiddling with device permissions and all that jazz, right?
[14:41] <ttx> jiboumans: + number? of high-impact bugs fixed between 0.7.2 and 0.7.5
[14:41] <jdstrand> soren: yes. it generally seems not the right thing to do, and most people I've talked to aren't keen on it
[14:41] <soren> jdstrand: Yeah, I absolutely hate it.
[14:41] <jdstrand> though, I've not talked to that terribly many people
[14:41] <ttx> jiboumans: bugs that you wouldn't want to ship an LTS with
[14:42] <soren> jdstrand: I don't predict it's going to be a lasting approach.
[14:42] <stgraber> ttx: +1 (except that I won't hate him, just will file a lot of bugs for you guys to fix ;))
[14:42] <soren> jdstrand: I'm cool with sticking with running kvm as root.
[14:42] <jiboumans> ttx: that makes 0.7.5+apparmor a desired target then
[14:42] <jdstrand> soren: well, it is easy enough to run it like it has always been run (ie as root), using the apparmor driver
[14:42] <soren> jdstrand: It's really much more sensible than the current alternative.
[14:42] <ttx> jiboumans: I don't know how much of our long libvirt list of bugs 0.7.5 fixed
[14:43] <jiboumans> ttx: ok fearless techlead, propose a plan :)
[14:43] <jdstrand> in that case, I will do the 0.7.5, and leave out the non-root bits. if someone else wants to flip that on later, they can do that
[14:43] <soren> jdstrand: Sounds good to me.
[14:43] <jdstrand> s/0.7.5/0.7.5 merge/
[14:43] <ttx> jiboumans: knowing that unknown would help choosing the right solution
[14:44] <ttx> jiboumans: my plan would be to follow the fearless jdstrand
[14:44] <soren> oh.
[14:44] <jdstrand> and I want it clear-- please don't disable the apparmor driver if testing non-root-- we still want it for guest isolation and host protection
[14:44] <soren> Er... I would not even consider sticking with 0.7.2.
[14:44] <jiboumans> ttx: fair enough
[14:44] <ttx> soren: thanks for your support
[14:44] <soren> I completely missed that suggestion.
[14:44] <jdstrand> it runs as non-root in Debian, but all as the same user (ie no guest isolation)
[14:45] <ttx> soren: <jiboumans> ok, then let me rephrase: what do we loes by staying with current version?
[14:45] <jdstrand> plus, I'd hate for a rogue guest to have even non-root privs on my host machine
[14:45] <jiboumans> jdstrand: where can we see the progress on this? i'm expecting this to impact UEC as well after all
[14:45] <soren> Sticking with old, unsupported versions of core virtualisation stuff is no fun at all (*cough* kvm-62 in hardy *cough*).
[14:45] <jdstrand> jiboumans: 0.7.5 is still in unstable and not migrated to testing
[14:46] <jdstrand> jiboumans: so sometime after that, plus there is a blueprint for the apparmor/libvirt dev work I am doing
[14:46] <soren> jdstrand: There's plenty of precendence for being ahead of Debian testing in Ubuntu for libvirt. Even ahead of Debian experimental at times.
[14:46]  * jdstrand goes to get it
[14:46] <soren> And precedence.
[14:46] <jdstrand> jiboumans: https://blueprints.launchpad.net/ubuntu/+spec/security-lucid-libvirt-apparmor-devel
[14:47] <jdstrand> I'll add a new item for 0.7.5
[14:47] <jiboumans> jdstrand: thanks. kirkland/ttx this will affect you for UEC. please keep an eye on it and stay in touch with jdstrand
[14:47] <kirkland> jiboumans: sure thing
[14:47] <ttx> ack
[14:47] <jiboumans> stgraber, soren, jdstrand: anything more on the containers spec?
[14:48] <soren> Not at the moment.
[14:48] <stgraber> not from me, I updated the blueprint with the new items for alpha-3
[14:48] <jiboumans> stgraber++ thanks
[14:48] <jiboumans> ok, next topic: server-lucid-asterisk-integration (dyfet, Daviey)
[14:48] <jmdault> and jmdault ...
[14:48] <jmdault> ;-)
[14:48] <dyfet> yes
[14:48] <jiboumans> jmdault: appologies :)
[14:48] <jiboumans> first order of business: who's the contact for this spec?
[14:48] <Daviey> \i
[14:49] <jiboumans> or drafter? or the person i'll be gently but firmly shaking in this meeting?
[14:49] <jmdault> jiboumans: you can shake me
[14:49] <dyfet> lol
[14:49] <jiboumans> jmdault: thanks for volunteering :)
[14:49] <dyfet> That works for me also!
[14:49] <jmdault> good
[14:49] <jiboumans> jmdault: this spec has been lingering a bit; are you still commited to this for lucid?
[14:50] <jmdault> jiboumans: yes, definitely
[14:50] <Daviey> I'm very keen to try and keep the packages from Debian as pristine as possible, and work with Debian's pkg-voip closer.
[14:50] <dyfet> I concur
[14:50] <jiboumans> excellent. You've all been doing this for a while, so you know what parts need to be done by alpha3
[14:50] <jmdault> me too
[14:51] <zul> are you guys looking to get asterisk in main?
[14:51] <jmdault> Asterisk 1.6.2 is officially released now
[14:51] <jiboumans> could i ask you to update the spec accordingly and prefix the people doing the tasks so pitti's magic tool picks it up?
[14:51] <jmdault> zul: not sure about main... we need to handle security updates, and that's gonna be a lot of work
[14:52] <jiboumans> mathiaz: wasn't asterisk on your promotion/demotion list?
[14:52] <Daviey> zul: not at present.
[14:52] <mathiaz> jiboumans: nope
[14:52] <mathiaz> jiboumans: I don't think so
[14:52] <jiboumans> mathiaz: ok, i probably misremembered then :)
[14:52] <zul> jiboumans: it was on my list but it got rejected
[14:52] <mathiaz> jiboumans: mainly for security reasons - jdstrand ^^?
[14:53] <zul> security reasons and lack of hardware for testing
[14:53] <Daviey> it did have a MIR
[14:54] <jiboumans> [ACTION] jmdault to update server-lucid-asterisk-integration blueprint with alpha3 & post-alpha3 workitems and change syntax to match Pitti's workitems howto (https://wiki.ubuntu.com/WorkItemsHowto)
[14:54] <MootBot> ACTION received:  jmdault to update server-lucid-asterisk-integration blueprint with alpha3 & post-alpha3 workitems and change syntax to match Pitti's workitems howto (https://wiki.ubuntu.com/WorkItemsHowto)
[14:54] <jmdault> Daviey: I don't see you're subscribed to ubuntu-voip mailing list?
[14:54] <jmdault> we need some communication
[14:54] <Daviey> jmdault: i should be!  I set it up
[14:55] <Daviey> jmdault: there is now #ubuntu-voip, and i somehow feel real time communication might help.
[14:55] <jiboumans> ok, i think we're aligned on the work that needs to be done. ttx: any concerns on this one?
[14:55] <zul> you should use asterisk to talk to each other :)
[14:56] <erichammond> Tangentially related: I built custom, private Karmic AMIs for a client who is running Asterisk on EC2.  He has timing problems with the 2.6.27 kernel and we are hoping that the 2.6.31 kernel will work better.  The kernel team has offered to build 250Hz and 1000Hz EC2 kernels for testing if the default 100Hz still doesn't work under Karmic with 2.6.31.
[14:56] <jiboumans> zul++ # +7 smartypants points
[14:56] <jdstrand> the security issues regarding asterisk are that there are many vulnerabilities
[14:56] <ttx> jiboumans: not at this point
[14:56] <Daviey> erichammond: erichammond Xen and asterisk have never played well.
[14:56] <jiboumans> alright, anything more on the asterisk spec?
[14:56] <jdstrand> there hasn't been a community around asterisk to fix what we have in Ubuntu now
[14:56] <Daviey> i built different kernels with different clock speeds and it did *help*, but not perfect.
[14:56] <smoser> erichammond, we've not heard back on that ?
[14:57] <erichammond> Davley: People are running Asterisk well under EC2 with an old 1000Hz kernel.
[14:57] <smoser> iirc that was some end of november-ish, right?
[14:57] <jdstrand> adding asterisk as a supported package is not recommended-- but this was all discussed at UDS, is this up for discussion again?
[14:57] <jiboumans> jdstrand: nope
[14:57] <erichammond> smoser: The Karmic AMIs just got built as it took me a while to sort out all the vmbuilder issues.
[14:57] <jiboumans> gents, i'm going to have to ask you to take this to #ubuntu-voip :)
[14:57] <jmdault> yes, come to #ubuntu-voip
[14:58] <smoser> oh. sorry. not meaning to call you out :)
[14:58] <jmdault> we need some traffic
[14:58] <dyfet> yep
[14:58] <jiboumans> our agenda is rather full and we have to move on i'm afraid
[14:58] <jiboumans> so, next topic: server-lucid-papercuts (ttx)
[14:58] <smoser> thought we were just waiting for someone else to test.
[14:58] <ttx> ok, so this is the spec following the UDS discussion we had on Server usability papercuts
[14:58] <ttx> To be successful, it needs to be a global effort shared between all Ubuntu Server team members
[14:58] <ttx> That's why I wanted to discuss the details of the project implementation before going forward
[14:58] <ttx> (not sure there is enough time in this meeting to do so, stop me if needed)
[14:58] <ttx> The blueprint whiteboards shows several subjects that we could discuss in January team meetings
[14:59] <ttx> Starting today with discussing the best way to nominate a bug as a papercut
[14:59] <ttx> jiboumans: want to move that to next week ?
[14:59] <jiboumans> ttx: given the time constraints and us being behind on some alpha2 work, yeah
[14:59] <jiboumans> ttx: i'd urge everyone to give this some thought though (perhaps you can send a mail to that extent) so we're prepared next week
[14:59] <ttx> ok. Let's discuss papercut nomination mechanism next week then
[15:00] <ttx> action me on that
[15:00] <jiboumans> [ACTION] ttx to send background mail on papercuts project for next weeks discussion
[15:00] <MootBot> ACTION received:  ttx to send background mail on papercuts project for next weeks discussion
[15:00] <jiboumans> see how fast i type? :)
[15:00] <ttx> we share a common brain
[15:00] <zul> thats scarey
[15:00] <jiboumans> 2 men 1 brain... sounds like a bad internet movie
[15:00] <jiboumans> ok, next:
[15:00] <jiboumans> [TOPIC] blueprint status check
[15:00] <MootBot> New Topic:  blueprint status check
[15:01] <jiboumans> most seem well on track, so slightly different format:
[15:01] <jiboumans> i'd liek to discuss 3 in particular, and then a quick round table
[15:01] <jiboumans> mathiaz: server-lucid-uec-testing   12/0/13 52%
[15:01] <jiboumans> are we still on track for alpha2? halfway complete dwith a few days development time left
[15:01] <mathiaz> jiboumans: on track IMO
[15:02] <mathiaz> jiboumans: three items are about alpha2 testing
[15:02] <mathiaz> jiboumans: two others are to talk with upstream
[15:02] <jiboumans> mathiaz: if you are confident, so am i.
[15:03] <mathiaz> jiboumans: and the last ones require a bit more hardware for testing
[15:03] <jiboumans> mathiaz: IS assured me we can get the hardware at alpha2. you & ttx need to look over the details though (see the rt mail that landed in yoru box today)
[15:03] <jiboumans> ttx: any opinions on taht yet? i saw cjwatson gave some tips
[15:04] <ttx> jiboumans: that sounds very promising
[15:04] <mathiaz> jiboumans: ok
[15:04] <ttx> jiboumans: I'm glued into an upstart issue, it's next on my totest list
[15:04] <mathiaz> jiboumans: I need to catch up on the RT thread (I don't receive all the emails of it apparently)
[15:04] <ttx> jiboumans: I'd revert my opinion now to "probably not needed anymore"
[15:05] <mathiaz> jiboumans: I know how to automate iso testing though
[15:05] <ttx> mathiaz: talk to you about it later today
[15:05] <mathiaz> ttx: ok
[15:05] <jiboumans> ttx, mathiaz: stick your heads together and make a call :)
[15:05] <jiboumans> next spec:there's also this spec: server-lucid-ec2-config 8/0/2 20%
[15:06] <jiboumans> zul, mathiaz: most of the work rests with you guys now and i know you've taken it over recently
[15:06] <mathiaz> jiboumans: you == zul^^ ?
[15:06] <zul> jiboumans: i showed smoser my first cut yesterday i think im on track https://code.launchpad.net/~zulcss/ec2-init/ec2-init-config
[15:06] <smoser> i think he's on track.
[15:07] <jiboumans> mathiaz: you have the parser writing on your plate: [mathiaz] write initial config parser : TODO
[15:07] <jiboumans> zul's doing the actual configs
[15:07] <mathiaz> jiboumans: hm - well - there isn't any parser to be written :)
[15:07] <mathiaz> jiboumans: the configuration file is in yaml
[15:07] <smoser> hopefully be tomorrow morning US/Eastern or end of day tomorrow we can have a combined branch with at least packaging
[15:08] <jiboumans> where's the code that grabs the file & DTRT?
[15:08] <mathiaz> jiboumans: boothooks
[15:08] <jiboumans> or is that *all* boothooks?
[15:08] <smoser> DTRT?
[15:08] <jiboumans> 'does the right thing'
[15:09]  * jiboumans hands smoser the interwebz
[15:09] <mathiaz> jiboumans: right - boothooks grabs the user-data, locally copies the yaml configuration and then fires an cloud-config upstart event
[15:09] <smoser> ah. that is boothooks
[15:09] <smoser> bah to you and your lmgtfy, jiboumans :)
[15:09] <jiboumans> ok, fair enough. mathiaz could you update the blueprint then please/ :)
[15:09] <mathiaz> jiboumans: relevant upstart jobs start on cloud-config and do whatever they want with the configuration file
[15:09] <smoser> so boot hooks gets user data, rips out user config, puts that in a file and emits an upstart job with CFG_FILE=path-to-that-file
[15:10] <jiboumans> is there no mileage in ever running this outside upstart?
[15:10] <smoser> well, it could. the upstart job just runs something else.
[15:10] <smoser> that something else coudl be run just as easily at other times.
[15:11] <smoser> but for now i think we're interested in at early-cloud-boot
[15:11] <jiboumans> smoser: i'll leave that for a design decision then while you're writing the code :)
[15:11] <smoser> yeah.
[15:11] <smoser> we ready to move to that blueprint then :)
[15:11] <jiboumans> server-lucid-ec2-boothooks  10/0/3  23%     High
[15:12] <jiboumans> smoser: are you still on the EC2 image issue, or moved to this spec now?
[15:12] <smoser> i am actually feeling much more confident of it now than i was before.
[15:12] <smoser> the ec2 image issue has been identified. bug 503212
[15:12] <ubottu> Launchpad bug 503212 in mountall "mountall crashed with SIGSEGV in main() without initramfs" [High,New] https://launchpad.net/bugs/503212
[15:13] <smoser> short summary, mountall doesn't work without a ramdisk, our ec2-images dont have ramdisks.
[15:13] <jiboumans> smoser: that sounds like cloud-krd is stalled pending that bug, correct?
[15:13] <smoser> well, yeah, but i have to assume that it will  be fixed. i sent mail to Keybuk, but i think he must  be out atm
[15:14] <jiboumans> fair enough. so, boothooks... on track now?
[15:14] <smoser> basically cloud-krd is done.  everything is functional (or at least *was* functional) in ec2
[15:14] <smoser> much closer to on track.  i do feel more confident now
[15:14] <jiboumans> smoser: please stay in touch wtih ttx about this
[15:15] <jiboumans> anything to add to this spec?
[15:15] <smoser> no. thanks to everyone who has helped and offered to help, though
[15:15] <jiboumans> excellent
[15:15] <jiboumans> everyone++ indeed
[15:15] <jiboumans> quick round table:
[15:16] <jiboumans> kirkland: any blockers or risks for your blueprints regarding alpha2?
[15:16] <kirkland> jiboumans: i don't think so
[15:16] <jiboumans> mathiaz: same question ^
[15:16] <mathiaz> jiboumans: I don't think so
[15:17] <jiboumans> smoser: i think we covered yours, right?
[15:17] <smoser> y
[15:17] <jiboumans> ttx: ^
[15:17] <ttx> jiboumans: I don't think so
[15:17] <smoser> y as in yes
[15:17] <jiboumans> zul: ^
[15:17] <zul> jiboumans: MIR team taking the time to review the MIR reports
[15:17] <jiboumans> zul: when do we need to have those back by?
[15:18] <zul> jiboumans: soon ill bug kees again today, i havent been able to talk to doko yet
[15:18] <jiboumans> zul: ok, flag it with me if you dont have an answer by thursday end of business
[15:18] <zul> ok
[15:19] <jiboumans> [TOPIC] assigned bugs: http://qa.ubuntu.com/reports/team-assigned/canonical-server-assigned-bug-tasks.html
[15:19] <MootBot> New Topic:  assigned bugs: http://qa.ubuntu.com/reports/team-assigned/canonical-server-assigned-bug-tasks.html
[15:19] <jiboumans> remind me who runs through this again usually :)
[15:19] <zul> ttx
[15:19] <ttx> zul: doh
[15:20]  * jiboumans watches the very slick push-infront-of-the-train action
[15:20] <ttx> Anyone has anything blocking to report ?
[15:20] <zul> nope
[15:20] <mathiaz> zope
[15:20] <ttx> Dustin, Chuck: all bugs assigned to you represent current or near-future work ?
[15:20] <kirkland> ttx: erg, yeah, near-ish future
[15:21] <zul> yeah near-ish future
[15:21] <kirkland> ttx: there's a few i'm on the *tip* of solving, uploading
[15:21] <ttx> ok
[15:21] <ttx> jiboumans: done
[15:21] <jiboumans> [TOPIC] weekly Q&A with QA
[15:21] <MootBot> New Topic:  weekly Q&A with QA
[15:21] <jiboumans> *badumtish*
[15:21] <jiboumans> soren?
[15:21] <soren> Hahah.
[15:21] <soren> Uh, yeah.
[15:22] <soren> Since last time, I've set up nightly rebuilds of a set of server packages.
[15:23] <soren> These are packages that already have test suites run at build time, but since stuff in their dependency tree might cause breakage, we need to run them periodically to detect regressions.
[15:23] <soren> ..so every night, I grab the current version of these packages and push them to a ppa.
[15:23] <soren> If they fail to build, I get an e-mail.
[15:23] <soren> Ideally, I would set something up to turn those e-mails into bug reports, but that's work to be done.
[15:24] <zul> is it possible to get a broader range of people to email?
[15:24] <soren> The current list of packages is:
[15:24] <soren> libvirt
[15:24] <soren> postgresql-8.3
[15:24] <soren> postgresql-8.4
[15:24] <soren> mysql-dfsg-5.0
[15:24] <soren> mysql-dfsg-5.1
[15:24] <soren> openldap
[15:24] <soren> php5
[15:24] <mathiaz> soren: using a team PPA so that others can get the emails as well if wanted?
[15:24] <soren> I'm sure I've missed some, so if you guys can think of anything server related that takes care to run its test suite at build time (and fails if the test suite fails), please let me know.
[15:25] <mathiaz> soren: there is dovecot
[15:25] <mathiaz> soren: it has a test suite, but not in the package
[15:25] <mathiaz> soren: it's in a different upstream hg repository
[15:25] <jiboumans> btw, this is the related spec: https://blueprints.launchpad.net/ubuntu/+spec/qa-lucid-automated-server-testing
[15:25] <zul> apache has an external testsuite but you have to fiddle with the package
[15:25] <soren> mathiaz: Right, so it doesn't really apply here.
[15:25] <mathiaz> soren: upstream dovecot wiki has an explanation
[15:25] <soren> Those are separate work items.
[15:25] <soren> mathiaz: Yes, I've seen it.
[15:26] <mathiaz> soren: right
[15:26] <jiboumans> alright, sounds like a good action point
[15:26] <soren> I intend to package it at some point and get it to run periodically.
[15:26] <soren> ...I just haven't gotten round to that yet.
[15:26] <kirkland> soren: i should have a qemu-kvm-0.12 merge ready soon ... any chance there will be a testing ringer i can put it through before unleashing it on people?
[15:26] <jiboumans> [ACTION] Soren to sollicit packages that lend them selves well to nightly builds
[15:26] <MootBot> ACTION received:  Soren to sollicit packages that lend them selves well to nightly builds
[15:27] <soren> kirkland: We could, but I don't think my current set of tests that use kvm will exercise it much more than what you get to do on a daily basis of just using it normally.
[15:28] <kirkland> soren: gotcha
[15:28] <jiboumans> soren: anything else to report from QA?
[15:28] <soren> I'm happy to test it in my daily work, though.
[15:28] <soren> jiboumans: Not at the moment, no. I expect to have a bunch of stuff for next week (a lot of my stuff is targeted for alpha-2).
[15:28] <jiboumans> soren: we look forward to next weeks update then
[15:28] <jiboumans> any questions for soren/QA?
[15:29] <mathiaz> soren: what's the status of the Server QA position?
[15:29] <soren> mathiaz: I don't know if I have the full picture, but as far as I know, there's no-one in the pipeline right now, so it'll probably be a while.
[15:30] <soren> But like in every other context, I somehow always manage to be the last person to know anything :)
[15:31] <zul> no that would be me ;)
[15:32] <soren> See? I didn't even know that.
[15:32] <jiboumans> cute :) any other questions?
[15:32] <erichammond> I don't use the new us-west-1 region in EC2 much yet, but bug 494185 makes the official Ubuntu AMIs broken there, and users have complained.  This seems like a pretty high priority to me.  It could either be fixed by publishing updated AMIs (bug 503649) or by having IT modify the firewall on the us-east-1 apt mirror to allow external access in the short term (very low cost).
[15:32] <ubottu> Launchpad bug 494185 in ec2-init "ec2-init selects us-east-1 mirror when running in us-west-1 region" [High,Fix committed] https://launchpad.net/bugs/494185
[15:32] <ubottu> Launchpad bug 503649 in ubuntu "Release updated official Ubuntu EC2 AMIs for Karmic, Hardy" [Undecided,New] https://launchpad.net/bugs/503649
[15:34] <smoser> i think we shoudl push new images there.
[15:34] <smoser> that will solve your other bvug, eric, for updated instances of karmic for speed.
[15:34] <kirkland> jiboumans: one from me ... i uploaded a new merge of euca2ools yesterday, the first sync with upstream since Oct
[15:34] <kirkland> jiboumans: i'd like to request some testing ;-)
[15:35] <smoser> i did open a ticket service ticket on ipening up the us-east mirror to outside, but nothing on that.
[15:35] <kirkland> just in general, from anyone doing UEC/EC2 ish stuff
[15:35] <jiboumans> this is particularly for the QA team :)
[15:35] <kirkland> jiboumans: yeah, them too :-)
[15:35] <jiboumans> soren: can you/QA help with either of those issues?
[15:36] <soren> Uh..
[15:36]  * soren seems to be missing something
[15:36] <jiboumans> 'no' is an acceptable answer :)
[15:36] <soren> Sorry, how did QA get wound up in this? :)
[15:37] <jiboumans> right, 'no' it is
[15:37] <soren> Works for me :)
[15:37] <jiboumans> [ACTION] smoser to investigate publishing new AMIs
[15:37] <MootBot> ACTION received:  smoser to investigate publishing new AMIs
[15:37] <jiboumans> [TOPIC] Q&A with the kernel team (jjohansen)
[15:37] <MootBot> New Topic:  Q&A with the kernel team (jjohansen)
[15:37] <jiboumans> jjohansen: so sorry to keep you waiting
[15:37] <jjohansen> np
[15:37] <smoser> erichammond, coudl you do me a favor and snif test a recent -testing build ?
[15:37] <mathiaz> kirkland: I'll test run the latest euca2ools today
[15:37] <jiboumans> jjohansen: i notice one open work item for you:     fix kernel configs such that uec requires no ramdisk (bug 494565)
[15:37] <ubottu> Launchpad bug 494565 in linux "support ramdiskless boot for relavant kvm drive interfaces in -virtual" [Low,Triaged] https://launchpad.net/bugs/494565
[15:37] <mathiaz> kirkland: while doing some more UEC testing
[15:38] <erichammond> smoser: sure thing.
[15:38] <erichammond> kirkland: Will euca2ools work with my EC2 account that starts with a zero now?
[15:38] <jjohansen> jiboumans: yeah, I am behind on that one, I am going to see what I can get done on that today and tomorrow
[15:38] <jiboumans> jjohansen: it's part of the alpha2 target; you see any risk of it not being done by then?
[15:39] <jjohansen> yeah it is in danger for alpha2 as kernel changes have deadline of friday
[15:39] <kirkland> erichammond: according to the changelog, yes
[15:39] <kirkland> erichammond: and commit history
[15:39] <jiboumans> smoser: what's the impact on cloud-krd if this doesn't happen?
[15:39] <kirkland> erichammond: it would be great if you could confirm, or reopen that bug if not
[15:39] <smoser> well, our uec images will just need to have a ramdisk
[15:39] <smoser> which they do now
[15:40] <jiboumans> right, so it would spill over to alpha3
[15:40] <jiboumans> jjohansen: we're still allowed to make changes like this for alpha3, yes?
[15:40] <smoser> if ever it were fixed i just have put back in a change that removes them (they didn't have a ramdisk for a while)
[15:41] <jjohansen> jiboumans: yes it should be good, its really just some config changes
[15:41] <ttx> Two bugs on my plate for the kernel team: bug 499785 and bug 499491. Both are fix committed, what's the ETA for archive ?
[15:41] <ubottu> Launchpad bug 499785 in linux "nic-usb-modules should include asix" [Medium,Fix committed] https://launchpad.net/bugs/499785
[15:41] <ubottu> Launchpad bug 499491 in linux "tun module no longer automatically available (was: Euca 1.6.2 fails to boot an instance)" [High,Fix committed] https://launchpad.net/bugs/499491
[15:41] <jiboumans> smoser: ok, keep an eye on this then and adjust the blueprint accordingly please
[15:42] <jjohansen> ttx: well my guess would be the kernel will be uploaded monday or tuesday
[15:42] <ttx> jjohansen: ack
[15:42] <jjohansen> just depending if something critical doesn't make friday
[15:43] <jiboumans> any other questions for the kernel team?
[15:43] <jiboumans> jjohansen: anything else we need to be aware of?
[15:43] <jjohansen> not that I can think of
[15:44] <jjohansen> wait
[15:44] <jjohansen> there is an EC2 kernel update coming
[15:44] <jjohansen> but that should break anything, I point smoser at the test kernels today
[15:44] <jiboumans> i so hope you meant 'should not' ;)
[15:45] <jjohansen> yeah :)
[15:45] <jiboumans> alright, thanks for letting us know ;)
[15:45] <jiboumans> [TOPIC] weekly SRU review (mathiaz)
[15:45] <MootBot> New Topic:  weekly SRU review (mathiaz)
[15:46] <mathiaz> one bug nominated for jaunty
[15:46] <mathiaz> bug 117736
[15:46] <ubottu> Launchpad bug 117736 in libpam-mount "pam_mount unable to unmount needs root priv" [Medium,Confirmed] https://launchpad.net/bugs/117736
[15:46]  * kirkland shudders at pam_mount
[15:46] <mathiaz> one bug nominated for karmic: bug 379329
[15:46] <ubottu> Launchpad bug 379329 in openssh "CVE-2008-5161: OpenSSH CBC plaintext recovery" [Low,Fix released] https://launchpad.net/bugs/379329
[15:46] <mathiaz> Are these two bus SRU worth?
[15:47] <ttx> the second one should be handled by security
[15:47] <ttx> if it's worth it, they will do it
[15:47] <kirkland> mathiaz: i spent about a week working with the pam_mount source code, when I was doing the Encrypted Private dir stuff way back
[15:47] <kirkland> mathiaz: it was really bad, and so I wrote pam_ecryptfs instead
[15:48] <kirkland> mathiaz: i don't know about that bug, but pam_mount is a mess
[15:48] <mathiaz> ttx: ok - I'll leave bug 379329 alone then
[15:48] <ubottu> Launchpad bug 379329 in openssh "CVE-2008-5161: OpenSSH CBC plaintext recovery" [Low,Fix released] https://launchpad.net/bugs/379329
[15:48] <mathiaz> jdstrand: ^^
[15:48] <jdstrand> we are aware of the bug
[15:48] <jdstrand> thanks
[15:49] <mathiaz> ok - I'll decline bug 117736
[15:49] <ubottu> Launchpad bug 117736 in libpam-mount "pam_mount unable to unmount needs root priv" [Medium,Confirmed] https://launchpad.net/bugs/117736
[15:50] <ScottK> Speaking of SRU review, thanks to everyone who helped out on the Spamassassin update over the weekend.
[15:50] <mathiaz> http://qa.ubuntu.com/reports/ubuntu-server-team/fixedbugs.ubuntu-server.latest.html
[15:50] <MootBot> LINK received:  http://qa.ubuntu.com/reports/ubuntu-server-team/fixedbugs.ubuntu-server.latest.html
[15:50] <mathiaz> two bugs fixed last week ?! ?
[15:50] <mathiaz> anything worth SRU?
[15:51] <zul> 478973 maybe...we need to find the patch for it though
[15:51] <mathiaz> zul: could you nominate/accept the bug then?
[15:52] <zul> mathiaz: sure
[15:52] <mathiaz> http://qa.ubuntu.com/reports/ubuntu-server-team/acceptedbugs.ubuntu-server.latest.html
[15:52] <MootBot> LINK received:  http://qa.ubuntu.com/reports/ubuntu-server-team/acceptedbugs.ubuntu-server.latest.html
[15:52] <mathiaz> zul: ^^ any progress on the bug there?
[15:52] <zul> no
[15:52] <ScottK> mathiaz: Why does the spamassassin bug not show up there?
[15:53] <mathiaz> ScottK: there == which list?
[15:53] <mathiaz> and that's all for the SRU review
[15:53] <ScottK> The bugs fixed list.
[15:54] <jiboumans> [TOPIC] open discussion
[15:54] <MootBot> New Topic:  open discussion
[15:54] <jiboumans> anythign left to be said afte 2 hours? :)
[15:54] <mathiaz> ScottK: because lp ~ubuntu-server is not a bug contact for spamassassin
[15:54]  * ttx wakes up
[15:54] <ScottK> mathiaz: I'd think it should be.
[15:54]  * kirkland looks forward to writing 2 hours of meeting minutes :-)
[15:54]  * zul cleans up his eyes
[15:54] <ttx> jiboumans: please, no
[15:54] <ScottK> Perl needs merged.
[15:54] <jiboumans> [TOPIC] next meeting
[15:54] <MootBot> New Topic:  next meeting
[15:55] <nijaba`> specially since it is in main now; right?
[15:55] <ScottK> Yep
[15:55] <ScottK> Probably clamav and amavisd-new too if they aren't
[15:55] <zul> they are
[15:55] <nijaba`> double yep
[15:55] <zul> amavisd-new is at least
[15:55] <ScottK> Does somebody get an action to fix that?
[15:55] <nijaba`> mathiaz: ?? ^
[15:56] <mathiaz> done
[15:56] <jiboumans> next week; same bat time, same bat channel. hopefully only 1 hour.
[15:56] <jiboumans> thanks for your patience people
[15:56] <jiboumans> #endmeeting
[15:56] <MootBot> Meeting finished at 09:56.
[15:57] <kirkland> ScottK: looks like it is already https://bugs.edge.launchpad.net/~ubuntu-server/+packagebugs
[15:58] <ScottK> kirkland: Then back to the original question, how come the bug wasn't on the list?
[15:58] <kirkland> ScottK: good q
[15:59] <ScottK> If I'm going to spend a Sunday getting Spamassassin fixed on 5 releases, I'd like it to at least show up as done
[16:00] <mathiaz> ScottK: I just added spamassassin and clamav
[16:00] <ScottK> Thanks.

MeetingLogs/Server/20100106 (last edited 2010-01-08 09:52:33 by c161-174)