20100120

Agenda

Minutes

Review ACTION points from previous meeting

  • smoser to look at getting Karmic images refreshed: bug verifiedfixed, image refresh coming up before end of week

Action: smoser to publish karmic cloud image refresh

  • mathiaz to send out AWS Client lib RFC: done
  • ttx to coordinate alpha ISO testing: done
  • ttx for papercuts: discuss acceptance criteria, project publicity plan: mail sent, more in this meeting

  • mathiaz to publish papercuts & apport efforts in our blog/community channels: done

  • mathiaz to publish request for iso testing in our regular blog/community channels: done

Spec quickreview

All alpha-3 targeted specs are on track.

To avoid useless noise, blueprint assignees are asked to refresh the status of their specs by using the "Status:" section of the blueprint whiteboard. It will then automagically show up in the report (http://people.canonical.com/~pitti/workitems/canonical-server-lucid-alpha-3.html).

Action: Everyone: update status for your specs before the meeting starts

Alpha3 subcycle planning

The final planning is still being discussed, and should be officialized this week. No change is expected in the Prio 1 specs ("High" priority), some priority changes might affect Prio2/3 specs, and some late specs might be introduced as Prio2/3 specs.

server-lucid-papercuts

We discussed the papercuts acceptance criteria, as described in a recent ubuntu-server ML post. This looks fine and was approved. Final criteria should make clear that any server-related package (in main, universe or multiverse) is relevant, and that the fix should not introduce a new feature (and therefore be OK to fix after FeatureFreeze). The criteria might be further refined when we start hitting difficult nominations.

About the project publicity plan, mathiaz already posted a blog entry about the project on the ubuntuserver blog. This should be complemented by an ubuntu-devel ML post, personal blog posts (ttx, zul) and brought to the attention of the Ubuntu Weekly News team. alexm will talk about it in his loco. The message is about nominating your favorite server papercuts, so that we gather as many candidates as possible now.

Action: ttx, zul to blog about papercuts, make sure UWN gets the word

Action: ttx to send email about criteria and nomination to ubuntu-devel, ubuntu-server

server-lucid-apport-hooks

Building on the UDS Dallas discussion about how having apport hooks in server packages can help the quality of the bug reports we receive, the server apport hooks effort aims at adding as many as we can before FeatureFreeze. zul created a page at https://wiki.ubuntu.com/ServerTeam/ApportHooks with likely candidates. Anyone interested, please sign up for your favorite package, or add your own !

Weekly Updates & Questions for the QA Team

soren has been extending the ISO testing features, and can now at the click of a button run ISO tests of the cartesian product of i386/amd64,lvm/non-lvm,basic/mail/bind9/lamp/postgresql installs. Documentation on the setup is under way, and the process should be ultimately integrated with Marc Tardif's checkbox work. soren will lead an UbuntuDeveloperWeek session about this next Tuesday at 2000 UTC.

Weekly Updates & Questions for the Kernel Team

Discussion concentrated on bug 494565, since a decision must be reached on the best option to follow. The -virtual kernel currently being a subflavour of -server and -generic-pae, building support for the block devices needed for EC2 and UEC would also affect those kernels. The options are CONFIG_SCSI_SYM53C8XX_2, CONFIG_VIRTIO_NET and CONFIG_VIRTIO_BLK. CONFIG_SCSI_SYM53C8XX_2=y, in particular, could have unexpected consequences on some rare hardware. Note that building in that SCSI support would not prevent it from being manually bypassed. Alternatives would be to make -virtual a flavour of its own (but this adds a lot of maintenance work for the kernel team), patch UEC so that it works without that SCSI support (potential performance issues, deviation from upstream), or abandon the idea of using no ramdisks for UEC. This should be further discussed on ubuntu-devel.

Action: smoser to raise thread about the no-ramdisk / -virtual config tradeoff

Assigned and to-be-assigned bugs

List at http://qa.ubuntu.com/reports/team-assigned/canonical-server-assigned-bug-tasks.html still needs to be cleaned up to be more useful.

Action: zul, kirkland to unassign themselves from "maybe working on one day" bugs

Agree on next meeting date and time

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

Log

[14:01] <ttx> #startmeeting
[14:01] <ttx> ...
[14:01] <ttx> No MootThing
[14:01] <ttx> I'll be today's scribe, lucky me
[14:02] <ttx> so we'll try to keep it short :P
[14:02] <soren> o/
[14:02] <ttx> [TOPIC] Review ACTION points from previous meeting (ttx)
[14:02] <ttx> * ScottMoser to look at getting Karmic images refreshed.
[14:02] <ttx> * Mathiaz to send out AWS Client lib RFC
[14:03] <mathiaz> ttx: done
[14:03] <ttx> * ttx to coordinate alpha ISO testing.
[14:03] <ttx> done
[14:03] <ttx> * ttx for papercuts: discuss acceptance criteria, project publicity plan
[14:03] <ttx> mail sent, no answer, more in this meeting
[14:03] <ttx> smoser: status on first action in list ?
[14:04] <ttx> * Mathiaz to publish papercuts & apport efforts in our blog/community channels
[14:04] <mathiaz> ttx: done
[14:04] <ttx> * mathiaz to publish request for iso testing in our regular blog/community channels
[14:04] <mathiaz> ttx: done
[14:04] <smoser> eric verified karimc-proposed for me.
[14:04]  * mathiaz feels repetitive
[14:04] <smoser> we hope to have that refresh end of week.  pitti said he will push to -updates.
[14:04] <ttx> smoser: we will, you mean :)
[14:05] <ttx> [ACTION] smoser to publish karmic cloud image refresh
[14:05] <smoser> sounds good.
[14:05] <ttx> ok, next subject
[14:05] <ttx> [TOPIC] Spec quickreview (ttx)
[14:06] <ttx> So, this is where we communicate a short oneliner about each spec
[14:06] <ttx> http://people.canonical.com/~pitti/workitems/canonical-server-lucid-alpha-3.html
[14:06] <ttx> server-lucid-cloud-krd
[14:06] <ttx> (smoser)
[14:07] <ttx> I want a short status, "on track" is OK
[14:07] <smoser> boothooks, krd and config on srack.
[14:07] <ttx> Note that in the future, you should update the "Status:" part of the blueprint before the meeting
[14:07] <ttx> so that status shows automagically on the report
[14:08] <ttx> so I don't want to see "(not updated)" there anymore :)
[14:08] <soren> Err...
[14:08] <ttx> server-lucid-vmbuilder-multiple-outputs (soren)
[14:08] <smoser> krd is giving me some fits right now, it *should* be fixed on ec2, and i've even verified in one case, can't figure out why my official builds pushed this morning are not working.
[14:08] <soren> What are the valid statuses we can put there?
[14:08] <ttx> "On track", "Doomed"...
[14:09] <ttx> "OMG"
[14:09] <ttx> Anything else than "On track" will be further discussed during the meeting.
[14:09] <soren> ttx: I thought it would be parsed and interpreted by some script or whatnot so it had to be some specific set of statuses. Ok, no worries.
[14:09] <ttx> soren: oh, no. It's just a freeform status
[14:10] <ttx> soren: what about server-lucid-vmbuilder-multiple-outputs ?
[14:10] <soren> on track
[14:10] <ttx> server-lucid-vmbuilder-multiple-outputs
[14:10] <ttx> arrh
[14:10] <ttx> server-lucid-mysql-5.0 (zul)
[14:10] <zul> on track
[14:10] <soren> on track!
[14:10] <ttx> server-lucid-eucalyptus-merging-and-packaging (kirkland)
[14:10] <soren> I keep telling you!
[14:10] <soren> dude!
[14:10] <soren> :D
[14:10] <ttx> on track
[14:10] <ttx> server-lucid-id-mgmt-login-testing (mathiaz)
[14:10] <mathiaz> ttx: started - on track
[14:10] <ttx> server-lucid-daily-vcs (zul)
[14:10] <zul> started
[14:10] <ttx> server-lucid-canonical-application-support (zul)
[14:11] <zul> on track
[14:11] <ttx> server-lucid-papercuts (ttx)
[14:11] <ttx> on track, more about it today
[14:11] <ttx> server-lucid-aws-client-libraries (mathiaz)
[14:11] <mathiaz> ttx: on track as well
[14:12] <ttx> This is getting old
[14:12] <ttx> Anyone has anything not on track ?
[14:12] <soren> I can stop working on things, just to spice things up?
[14:12] <soren> No charge.
[14:12] <soren> No?
[14:12] <soren> Oh, well.
[14:12] <ttx> Everyone: please update the status in your specs so that we can call it done
[14:12] <zul> heh
[14:12] <mathiaz> ttx: well - there are a couple of my specs that haven't started yet
[14:12] <ttx> and do so before every meeting at the very least
[14:12] <mathiaz> ttx: so I can't really say wether they're on track or not
[14:13] <ttx> mathiaz: right. And until the alpha3 plan is finalized that doesn't make so much sense anyway
[14:13] <mathiaz> ttx: the close we get to the deadline, the more accurate I can say wether they're on track or not
[14:13] <ttx> Which brings us to...
[14:13] <mathiaz> ttx: right - how about that?
[14:14] <ttx> [ACTION] everyone: update status for your specs before the meeting starts
[14:14] <ttx> (next week)
[14:14] <ttx> [TOPIC] Alpha3 subcycle planning (ttx)
[14:14] <ttx> So this is still work in progress, should be officialized this week
[14:15] <mathiaz> ttx: does it mean that spec will be added?
[14:15] <ttx> As a reminder High priority specs should be dealt with before the "Medium" ones, which are in turn more important than the "Low" ones
[14:15] <mathiaz> ttx: dropped?
[14:15] <mathiaz> ttx: WI revisited?
[14:15] <ttx> mathiaz: The targets are being reviewed
[14:15] <mathiaz> ttx: you mean the WI lists or the goals?
[14:15] <ttx> that could end up in specs being dropped
[14:15] <ttx> the goals
[14:16] <ttx> Prio 1 specs ("High") should not change, so work can safely start on them.
[14:16] <mathiaz> ttx: ok
[14:16] <ttx> as well as everything that spilled over from alpha2
[14:16] <ttx> (don't follow my look)
[14:16] <mathiaz> ttx: and there isn't any hidden spec (critical ones) that would show up on the radar?
[14:16] <ttx> mathiaz: no
[14:17] <ttx> There might be new Prio 2 ones, or things moving from prio 3 to prio 2...
[14:17] <ttx> but we don't expact anything
[14:17] <ttx> Any other questions ?
[14:18] <zul> nope
[14:18] <ttx> moving on, then
[14:18] <ttx> [TOPIC] server-lucid-papercuts (ttx)
[14:18] <ttx> So today I wanted to discuss with everyone the acceptance criteria and best way/timing to announce the project
[14:18] <ttx> I sent an email to the ubuntu-server ML about this
[14:19] <ttx> does the criteria announced there make sense, and is it sufficiently precise to allow us to deny/accept bugs ?
[14:19]  * ttx digs up link
[14:19] <soren> ttx: Was just about to ask that :)
[14:19] <ttx> https://lists.ubuntu.com/archives/ubuntu-server/2010-January/003648.html
[14:20] <ttx> The project was created, and a group to act as triagers was created
[14:21] <ttx> Comments ?
[14:21] <soren> At a glance, the criteria look fine.
[14:21] <alexm> any package can be triaged as a papercut or only those in main?
[14:21] <ttx> alexm: I'd say, any.
[14:22] <soren> Anything server related, IMO.
[14:22] <soren> Be it main or universe (or multiverse).
[14:22] <alexm> great
[14:22]  * zul likes the branding
[14:22] <ttx> ok, then, if those make sense, we'll try them out.
[14:23] <ttx> we can revisit them if they end up being a complete failure
[14:23] <ttx> About publicity plan now
[14:23] <ttx> We need bugs to be nominated now
=== swoody_ is now known as swoody
[14:23] <ttx> So I think we should communicate about that phase widely
[14:24] <ttx> I can do a (personal) blogpost about it
[14:24] <zul> as can i
[14:24] <soren> What's the plan? Collect and process papercuts until X milestone, and then go into fixing mode?
[14:24] <ttx> What else should we aim for ? UWN ?
[14:24] <alexm> i will too in my loco
[14:24] <ttx> soren: yes
[14:24] <mathiaz> I've already published a blog post on the ubuntuserver blog
[14:25] <ttx> Fixing should start after alpha3
[14:25] <zul> uwn obviously and a post to ubuntu-devel as well  i think
[14:25] <ttx> ... which probably means that those should all be bugs not affected by FeatureFreeze, methinks
[14:25] <ttx> mathiaz: Aw, I missed it
[14:26] <ttx> ok
[14:26] <ttx> Anything else on that area ?
[14:26] <ttx> [ACTION] ttx, zul to blog about papercuts, make sure UWN gets the word
[14:27] <ttx> [ACTION] tx to send email about criteria and nomination to ubuntu-devel, ubuntu-server
[14:27] <ttx> Moving on
[14:27] <ttx> [TOPIC] server-lucid-apport-hooks (zul)
[14:27] <zul> hi
[14:28] <zul> so at uds in dallas we talked about having apport hooks in server packages can help the quality of the bug reports we recieved
[14:28] <zul> the spec is at https://blueprints.edge.launchpad.net/ubuntu/+spec/server-lucid-apport-hooks
[14:28] <zul> and so we have come up with a list of packages based on number of bugs in launchpad and other factors
[14:29] <zul> the list can be found at https://wiki.ubuntu.com/ServerTeam/ApportHooks
[14:29] <zul> if you want to help out with this effort please sign up
[14:29] <zul> i think thats it from me
[14:30] <zul> oh yeah and i blogged about it last week as well so there is some publicity around this as well
[14:30] <zul> any comments?
[14:30] <ttx> anyone interested in helping Chuck ?
[14:31] <zul> dont all yell at once ;)
[14:31] <mathiaz> zul: I've posted a post about it on the ubuntuserver blog
[14:31] <zul> mathiaz: cool i must have missed it
[14:31] <ttx> ok, let's move on... zul will do a weekly update on the progress of the apport hooks effort during the meeting.
[14:32] <Daviey> zul: Having never written an apport hook, i would like to have a play with what is involved before offering :)
[14:32] <ttx> Daviey: it's easy, and fun !
[14:32] <zul> Daviey: yeah I was the same way its not that hard, there are plenty of examples though
[14:32]  * ttx wonders if there is an apport session during devWeek
[14:32] <Daviey> neat
[14:33] <zul> when is devweek again?
[14:33] <ttx> next week
[14:33] <ttx> [TOPIC] Weekly Updates & Questions for the QA Team (soren)
[14:33] <zul> oh i dont think so but in the past there has been sessions on how to write apport hooks
[14:33] <ttx> soren: how is quality going
[14:34] <mathiaz> soren: any one processing the mysql build failure?
[14:34] <soren> mathiaz: Not that I know of.
[14:34] <soren> ttx: It's improving!
[14:34] <mathiaz> soren: I've been receiving these messages in my Inbox for a few days
[14:34] <soren> mathiaz: So you should be super motivated to fix it :)
[14:34]  * ttx hesitates between fixing it and writing a filter rule for it
[14:35] <soren> ttx: Since last week I've extended the ISO testing stuff somewhat.
[14:35]  * nijaba thinks that ttx second option lasts longer ;)
[14:35] <mathiaz> soren: well - I think the next step should be to identify *why* it fails
[14:35] <mathiaz> soren: after that we can see *how* it should be fixed
[14:35] <zul> nijaba: yes but you will get warm and fuzzies if you fix it
[14:35] <ttx> soren: extending, how ?
[14:35] <soren> I can now at the click of a button run ISO tests of the cartesian product of i386/amd64,lvm/non-lvm,basic/mail/bind9/lamp/postgresql installs.
[14:35] <ttx> ah, ok
[14:36] <soren> I'll be adding the last few server ISO test cases either this week ornext.
[14:36] <mathiaz> soren: do you have a describition of your setup somewhere?
[14:36] <soren> ..and I'll add a live CD test as well so that the desktop people can see how über cool the stuff we're using is.
[14:36] <mathiaz> soren: could this be included as part of the checkbox automatic test runs from marc tardif ?
[14:37] <soren> mathiaz: I started documenting it, but I was changing it faster than I could describe it, so I put that on hold for a bit.
[14:37] <mathiaz> soren: fair enough
[14:37] <soren> It will move to be run along with Marc's other tests.
[14:37] <ttx> soren: anything else before we move on ?
[14:37] <soren> ...and part of that involves documenting the whole thing.
[14:37] <soren> Just one thing.
[14:37] <soren> UDW is next week, and I have a session on this stuff, so if you're interested, come join me.
[14:38] <soren> It's Tuesday at... er... 2000 UTC, I think.
[14:38] <zul> when?
[14:38] <soren> It's Tuesday at... er... 2000 UTC, I think.
[14:38] <soren> :)
[14:38] <soren> UDW = Ubuntu Developer Week, by the way.
[14:38] <soren> That's it from me.
[14:38] <ttx> Plenty of crazy stuff @ https://wiki.ubuntu.com/UbuntuDeveloperWeek/Sessions !!
[14:38] <ttx> [TOPIC] Weekly Updates & Questions for the Kernel Team (jjohansen)
[14:38] <soren> Unless anyone has questions, of course.
[14:38] <ttx> jjohansen: o/
[14:38] <jjohansen> \o
[14:39] <ttx> We have one specific bug to discuss
[14:39] <ttx> I'll let smoser do the talking
[14:39] <smoser> whoowhoo
[14:39] <smoser> ok.
[14:39] <jjohansen> okay, well I did some test kernel builds for said bug
[14:39] <jjohansen> Bug #494565
[14:39] <ubottu> Launchpad bug 494565 in linux "support ramdiskless boot for relevant kvm drive interfaces in -virtual" [High,Triaged] https://launchpad.net/bugs/494565
[14:40] <smoser> so, we have a blueprint that wishes to have UEC and EC2 images booting without a ramdisk (https://blueprints.launchpad.net/ubuntu/+spec/server-lucid-cloud-krd)
[14:40] <smoser> in order to do that, we need support for the block devices used by EC2 and UEC built in to the respective kernels.
[14:40] <jjohansen> right, EC2 is not a problem
[14:40] <ttx> jjohansen: how did those tests go ?
[14:40] <jjohansen> ttx: okay
[14:40] <smoser> the UEC images use '-virtual' which is a "sub-flavour" of '-server' for amd64 and -generic-pae for i386
[14:40] <ttx> jjohansen: eta for fix ?
[14:41] <jjohansen> ttx: not yet
[14:41] <jjohansen> there needs to be a decision made about how we are going to proceed
[14:41] <soren> Why is this a problem?
[14:41] <smoser> it is not possible for jjohansen to change the config of -virtual and keep it a "sub flavour"
[14:41] <jjohansen> -virtual is a subflavour and can not have its own confings
[14:41] <jjohansen> so either we start a new flavor
[14:42] <soren> I thought you guys were building a whole bunch of stuff into the kernel anyway to avoid the need for a ramdisk for the common case (for boot speed purposes)?
[14:42] <jjohansen> or change -server and -generic-pae
[14:42] <smoser> so we either need to build the support for the relavent block devices into -server/-generic-pae, or split -virtual off into a separate entity
[14:42] <jjohansen> configs
[14:42] <zul> jjohansen: shouldnt the xen block devices be already built in?
[14:42] <jjohansen> zul: for EC2 yes
[14:42] <smoser> ec2 yes, but thats really a non-issue as ec2 affects nothing else
[14:42] <ttx> jjohansen: I suppose it's a kernel team decision ?
[14:42] <jjohansen> ttx: well we need some server team input
[14:43] <smoser> our choice to bbuild in CONFIG_SCSI_SYM53C8XX_2=y could have negative affect
[14:43] <smoser> as in it would no longer be blacklistable.
[14:43] <jjohansen> basically how much of an impact would building them into -server have
[14:43] <soren> eh?
[14:43] <soren> UEC uses scsi disks?
[14:43] <smoser> we would also like to build in CONFIG_VIRTIO_NET=y and CONFIG_VIRTIO_BLK=y but I expect those would have less negative consequences.
[14:43] <jjohansen> smoser: it can be disabled
[14:43] <smoser> jjohansen, oh? via cmdline you can say "don't do anything" ?
[14:44] <jjohansen> yeah basically
[14:44]  * soren taps his microphone
[14:44] <smoser> soren, yes. UEC uses scsi disks.
[14:44] <soren> smoser: Oh, wow.
[14:44] <smoser> it runs kvm with -drive if=scsi
[14:44]  * soren wonders why
[14:44] <ttx> jjohansen: and the cost of splitting -virtual into a separate entity ? It's a maintenance cost for the kernel team, right ?
[14:44] <smoser> the only options are ide, scsi or virtio.
[14:44] <jjohansen> right
[14:44] <mathiaz> smoser: to support EC2 images?
[14:44] <smoser> mathiaz is right, thats the assumption/explanation we have is that they use if=scsi so 'root=/dev/sda1' will work
[14:45] <mathiaz> smoser: IIRC UEC needs scsi drives in order to be able to provide the scratch space from EC2 as /dev/sdb
[14:45] <smoser> it is obviously possible to change eucalyptus, to use if=virtio, but that really is somewhat more heavy handed.
[14:45] <smoser> the basic question here is:
[14:45] <mathiaz> smoser: and run EC2 images *without* any modification
[14:45] <smoser> Does anyone expect negative fallout of changing:
[14:45] <smoser> CONFIG_VIRTIO_NET=m
[14:45] <smoser> CONFIG_VIRTIO_BLK=m
[14:45] <smoser> CONFIG_SCSI_SYM53C8XX_2=m
[14:46] <smoser> to the '=y' values.  that would occur in -generic-pae (which affects people other than -server) and in '-server'
[14:46] <soren> No.
[14:46] <jjohansen> the only one that should cause any problems is ONFIG_SCSI_SYM53C8XX_2=y
[14:46] <soren> jjohansen: Why is that?
[14:47] <smoser> mathiaz, where "without any modification" needs "if you're willing to pretend that swapping out a kernel is not a modification"
[14:47] <jjohansen> I don't expect virtio to be used in general
[14:47] <jjohansen> but sYM53C8XX has caused scsi problems in the past
[14:47] <jjohansen> rare but possible
[14:47] <mathiaz> smoser: hm right.
[14:47] <soren> Do we know why UEC uses scsi disks?
[14:47] <smoser> soren, googling for 'blacklist sym53c8xx' does have some hits. but jjohansen indicates that you could still effectively blacklist that.
[14:47] <mathiaz> soren: I've just outlined the reason above
[14:47] <smoser> soren, you're not listening. mathiaz explained that.
[14:48] <mathiaz> soren: IIRC UEC needs scsi drives in order to be able to provide the scratch space from EC2 as /dev/sdb
[14:48] <ttx> ok, we'll have to have a discussion about that. The no-ramdisk feature might not be worth the risk
[14:48] <mathiaz> soren: and run EC2 images *without* any modification
[14:48] <smoser> soren, and i'm guessing you're suggesting 'virtio' rather than 'ide' as the replacement ? virtio would require guest drivers, which may not be present at all.
[14:48] <ttx> (or additional workload)
[14:48] <soren> smoser: No, not at all.
[14:48] <soren> smoser: I'd use ide.
[14:49] <smoser> which would be slow
[14:49] <smoser> er
[14:49] <soren> Not really.
[14:49] <mathiaz> smoser: the other thing is that we could add udev rules to create that symlink for virtio block devices (to emulate /dev/sdb from EC2)
[14:49] <soren> These are not actual scsi controller or ide controllers. This is all emulated.
[14:49] <smoser> with guest modification, yes, mathiaz . note, that not all OSes support virtio
[14:49] <mathiaz> smoser: but that means not *all* EC2 images would run unmodified
[14:49] <ttx> i'll raise a thread so that we can continue this interesting discussion
[14:50] <mathiaz> ttx: ++
[14:50] <smoser> soren, yes, but the scsi is emulated faster. this is what i've understood from some of the kvm folks.
[14:50] <ttx> moving on
[14:50] <ttx> [TOPIC] Assigned and to-be-assigned bugs: http://qa.ubuntu.com/reports/team-assigned/canonical-server-assigned-bug-tasks.html (ttx)
[14:50] <smoser> ttx, i'll raise the thread on -devel
[14:50] <ttx> [ACTION] ttx to raise thread about the no-ramdisk / -virtual config tradeoff
[14:51] <smoser> unless you object.
[14:51] <ttx> and I delegate that to smoser.
[14:51] <smoser> moving on.
[14:51] <ttx> :)
[14:51] <ttx> Same status as last week...
[14:51] <ttx> nothing assigned to team
[14:52] <ttx> [ACTION] zul, kirkland to unassign themselves from "maybe working on one day" bugs
[14:52] <zul> didnt have a chance to do that last week
[14:52] <zul> but ill do it now
[14:52] <ttx> anything else about the list ? In its current form it's not really exploitable, zul & kirkland please fix that
[14:52] <ttx> moving on
[14:53] <ttx> [TOPIC] Weekly SRU review: https://wiki.ubuntu.com/ServerTeam/KnowledgeBase#SRU%20weekly%20review (mathiaz)
[14:53] <mathiaz> two bugs nominated for karmic
[14:54] <mathiaz> bug 434701
[14:54] <ubottu> Launchpad bug 434701 in python-boto "Main Inclusion Request: python-boto" [High,Fix released] https://launchpad.net/bugs/434701
[14:54] <mathiaz> bug 379329
[14:54] <ubottu> Launchpad bug 379329 in openssh "CVE-2008-5161: OpenSSH CBC plaintext recovery" [Low,Fix released] https://launchpad.net/bugs/379329
[14:54] <mathiaz> first one is bogus
[14:54] <mathiaz> and the security team is probably taking care of the second one
[14:54] <ttx> second one is securityteam-land
[14:54] <mathiaz> jdstrand: kees: ^^?
[14:55] <mathiaz> http://qa.ubuntu.com/reports/ubuntu-server-team/fixedbugs.ubuntu-server.latest.html
[14:55] <mathiaz> anything worth on this list^^?
=== KatieKitty is now known as KatieOffline
[14:56] <zul> there is a whole bunch of samba bugs that I fixed yesterday
[14:56] <zul> which is not on the list
[14:56] <mathiaz> zul: right - the list is generated on monday nights  IIRC
[14:56] <mathiaz> zul: they will show up next week
[14:56] <ttx> will be on next week's
[14:57] <zul> ok
[14:57] <mathiaz> nothing SRU worth??
[14:57] <ttx> nothing from me
[14:57] <zul> the apxs one maybe
[14:57] <ttx> http://launchpad.net/bugs/503402
[14:57] <ubottu> Ubuntu bug 503402 in samba "winbind crashes on authentication (winbind_pam_auth)" [Medium,Fix released]
[14:57] <ttx> but already accepted
[14:58] <mathiaz> zul: well - it seems like it's a build failure from an upstream source
[14:58] <mathiaz> zul: not sure if it's SRU worth
[14:59] <mathiaz> zul: if the released version of php5 would fail, that would be more annoying
[14:59] <zul> fine with me
[14:59] <mathiaz> ok - last one: http://qa.ubuntu.com/reports/ubuntu-server-team/acceptedbugs.ubuntu-server.latest.html
[14:59] <mathiaz> there a bugs that have been accepted and have someone assigned
[15:00] <mathiaz> please move them forward and bring them to -proposed
[15:00]  * ttx cleans up the list a little
[15:00] <mathiaz> that's all for the SRU review
[15:01] <ttx> [TOPIC] Open Discussion
[15:01] <ttx> [TOPIC] Agree on next meeting date and time
[15:01] <ttx> Next week, same batplace...
[15:02] <ttx> Questions / remarks / Thoughts for the day ?
[15:02] <mathiaz> move the meeting time and day?
[15:02] <jiboumans> as a heads up; in 2 weeks (first week of feb) we have a sprint
[15:02] <alexm> i heard about lucid being delayed
[15:02] <alexm> is that true?
[15:02] <jiboumans> it's likely that the server meeting that week will be canceled
[15:03] <ttx> alexm: ah ? Interesting, I think I would know
[15:03] <alexm> that's what i thought too ;)
[15:03] <mathiaz> alexm: where?
[15:03] <ttx> alexm: At least, I hope they would tell me :)
[15:03] <alexm> people from my locoteam
[15:03]  * ttx could use a few more years before release.
[15:03] <alexm> maybe the rumours come from the forums
[15:04] <zul> pfft
[15:04] <ttx> pfft
[15:04] <jdstrand> mathiaz: I think I mentioned the ssh thing last week. it is on our radar, it is for our team to fix. if someone from the server team/community wants to develop a patch and do the testing, we will sponsor it
[15:04] <alexm> ttx: don't worry at all, just wanted to be sure, thanks
[15:04] <jdstrand> mathiaz: otherwise, perhaps it should be taken off your todo list, since it is on ours?
[15:04] <mathiaz> jdstrand: well - it's on the list of nominated bugs for karmic
[15:05] <mathiaz> jdstrand: that's why it shows up on the review
[15:05] <jdstrand> (that said, there are higher priority issues in front of this issue)
[15:05] <ttx> jdstrand: just accept the nomination :)
[15:05] <mathiaz> jdstrand: should the bug be accepted for karmic?
[15:05]  * ttx closes the bar
[15:05] <ttx> it's time to go home, mathiaz.
[15:05] <ttx> #endmeeting

MeetingLogs/Server/20100120 (last edited 2010-01-20 16:22:15 by lns-bzn-48f-81-56-218-246)