FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.

» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Ubuntu > Ubuntu Server Development

LinkBack Thread Tools
Old 01-08-2010, 06:17 AM
Dustin Kirkland
Default ubuntu-server meeting minutes from 2010-01-06


Here are the minutes of this week's meeting. They can also be found
online with the irc logs here:

## page was renamed from MeetingLogs/Server/20100107
== Agenda ==

* Review ACTION points from previous meeting
* Discuss some specs that were not targeted to alpha2:
* [[https://blueprints.launchpad.net/ubuntu/+spec/server-lucid-aws-client-libraries|server-lucid-aws-client-libraries]]
* [[https://blueprints.launchpad.net/ubuntu/+spec/server-lucid-asterisk-integration|server-lucid-asterisk-integration]]
(dyfet, Daviey)
* [[https://blueprints.launchpad.net/ubuntu/+spec/server-lucid-cluster-stack|server-lucid-cluster-stack]]
(RoakSoax, ivoks)
* [[https://blueprints.launchpad.net/ubuntu-docs/+spec/lucid-serverguide|lucid-serverguide]]
* [[https://blueprints.launchpad.net/ubuntu/+spec/server-lucid-contextualization|server-lucid-contextualization]]
* Check blueprint status and progress for the week
* Assigned and to-be-assigned bugs:
* Weekly Updates & Questions for the QA Team (soren)
* Weekly Updates & Questions for the Kernel Team (jjohansen)
* Weekly SRU review (mathiaz)
* [[https://wiki.ubuntu.com/ServerTeam/KnowledgeBase#SRU%20weekly%20review]]
* Open Discussion
* Agree on next meeting date and time

== Minutes ==

==== Previous actions points ====
* JosBoumans to talk to ColinWatson and HughBlemings about taking
over eCryptfs support/maintenance

==== Non-alpha2 targeted specs for lucid ====
* UbuntuSpec: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.'
* UbuntuSpec:server-lucid-cluster-stack
* ivoks has it packaged at
* 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
* UbuntuSpec:lucid-serverguide
* AdamSommer suggests a weekly meeting item, asking for server guide changes
* UbuntuSpec: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
* UbuntuSpec: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
* UbuntuSpec:server-lucid-papercuts
* 'ACTION': ThierryCarrez to send background mail on papercuts
project for next weeks discussion

==== blueprint status check ====
* UbuntuSpec:server-lucid-uec-testing - 12/0/13 52%
* MathiasGug says still on track
* UbuntuSpec:server-lucid-ec2-config - 8/0/2 20%
* ChuckShort, ScottMoser say still on track
* UbuntuSpec:server-lucid-ec2-boothooks - 10/0/3 23%
* ScottMoser is confident
* UbuntuSpec:server-lucid-eucalyptus-merging-and-packaging
* DustinKirkland says on track
* UbuntuSpec:server-lucid-euca2ools
* DustinKirkland says on track

==== assigned bugs:
* 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) ====
* Kernel still open for config changes
* ThierryCarrez asked about Bug:499785 and Bug:499491
* JohnJohansen says kernel will be uploaded Monday or Tuesday

==== weekly SRU review (MathiasGug) ====
* Jaunty, Bug:117736
* to decline
* Karmic, Bug: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],
[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>
[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
[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
[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
[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
[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,
[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
[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
[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
[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:
[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
[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
[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
[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
[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
[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]
[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:
[15:19] <MootBot> New Topic: assigned bugs:
[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:
[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
[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
[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]
[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]
[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]
[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]
[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]
[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]
[15:50] <ScottK> Speaking of SRU review, thanks to everyone who helped
out on the Spamassassin update over the weekend.
[15:50] <mathiaz>
[15:50] <MootBot> LINK received:
[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>
[15:52] <MootBot> LINK received:
[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
[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.


ubuntu-server mailing list
More info: https://wiki.ubuntu.com/ServerTeam

Thread Tools

All times are GMT. The time now is 06:07 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org