[16:00]  * ara waves
[16:00]  * skaet looks around
[16:00] <skaet> hi ara
[16:01] <skaet> #startmeeting
[16:01] <MootBot> Meeting started at 10:01. The chair is skaet.
[16:01] <MootBot> Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE]
[16:01] <Daviey> o/
[16:01] <skaet> hi Daviey
[16:02] <skaet> The priority for today's meeting is to figure out where we are with 10.04.2.
[16:02] <cjwatson> hi
[16:02] <skaet> hi cjwatson
[16:02] <skaet> cjwatson, pitti - where are we with the 10.04.2 images?
[16:02] <pitti> hello all
[16:03] <pitti> they build fine, and automatically
[16:03] <victorp> skaet - hi
[16:03] <pitti> I just gave an update wrt. proposed vs. updates this morning via email
[16:03] <skaet> hi pitti, victorp
[16:03] <cjwatson> right, that's the main thing we're waiting for at the moment
[16:03] <pitti> they currently build from -proposed, as we still need to verify some SRUs
[16:03] <cjwatson> one regression known to me, bug 709694
[16:03] <pitti> in particular, d-i and installing with the maverick kernel
[16:04] <cjwatson> I believe pitti is handling that
[16:04] <pitti> cjwatson: was tested, copying to -updates nwo
[16:05] <skaet> pitti,  so when will there be an image for ara's team to use?
[16:05] <pitti> I still think we should use the current ones for certification (with -proposed)
[16:05] <cjwatson> I concur
[16:05] <skaet> ok
[16:05] <pitti> after a quick test from QA that they install at all (in VM should be fine)
[16:05] <pitti> install in normal lucid as well as "maverick backport kernel" modes
[16:06] <pitti> d-i and eglibc are the only potentailly hw specific packages
[16:06] <pitti> and we already cleaned up the questionable ones from -proposed
[16:06] <ara> pitti, the thing is that I don't understand why you don't think those packages are safe enough to move to -updates, yet they are safe to use for certification
[16:06] <cjwatson> -updates would cause every user to upgrade
[16:06] <pitti> ara: well, the point of that is testing, isn't it?
[16:07] <pitti> if we already knew that they don't break anything, then we wouldn't need a cert run
[16:07] <pitti> OTOH, if cert passes with those, we can move everything to -updates and are good to go
[16:07] <pitti> ara: we don't know of any breakage in the current proposed packages, but nobody tested them yet
[16:07] <skaet> jibel, pedro_ ^^ is a test of -proposed as outlined by pitti possible today?
[16:08] <cjwatson> the reason to be cautious about cert on -proposed would be if there were several things likely to be pulled out
[16:08] <ara> pitti, the point in running a full cert is to "certify" that they keep working, more than testing if it breaks
[16:08] <cjwatson> as pitti said, he already removed the questionable proposals, so we're now looking at *unexpected* problems
[16:08] <pitti> ara: ok, then we need "normal" sru testing before
[16:08] <ara> pitti, we tested it, last week
[16:09] <cjwatson> I don't think we should waive the waiting period for cert, so if cert can't use -proposed, the only remaining option is to push through validation
[16:09] <pitti> ara: oh? didn't see that; was that with the current d-i already?
[16:10] <ara> pitti, when was that uploaded to -proposed?
[16:10] <cjwatson>  -- Colin Watson <cjwatson@ubuntu.com>  Tue, 25 Jan 2011 11:19:31 +0000
[16:10] <cjwatson> but it would have needed explicit testing with the maverick boot option, not just "still works as normal"
[16:10] <ara> cjwatson, we didn't test the maverick boot option, that's for sure
[16:12] <sconklin> o/
[16:12] <sconklin> never mind
[16:12] <jibel> o/
[16:12] <skaet> hi jibel,  go ahead
[16:13] <jibel> hi, to answer your question, there are only 2 packages in -proposed that we can really test : base-files and unattended-upgrades
[16:13] <cjwatson> I don't understand why it isn't possible for QA to test d-i
[16:14] <pitti> jibel: i. e. QA can't do install smoketests?
[16:14] <jibel> yes I can, but at the moment I'm rather low on resources smoketesting A2
[16:14] <cjwatson> you may not be able to confirm that it fixes a given piece of hardware, but you can confirm that it installs successfully and that it uses the proper kernel version both during installation and on the installed system
[16:14] <pitti> (i. e. same like for normal alphas, using the iso tracker)
[16:14] <cjwatson> (you plural)
[16:15] <pitti> perhaps we can also have some community testing on alpha2
[16:15] <jibel> The last package I've validated this way, 'check that it installs' was ubuntu-docs and now users of maverick think they are running natty :(
[16:15] <pitti> and I can certainly help testing images as well
[16:15] <pitti> jibel: (^ that's fixed in -proposed, FYI)
[16:15] <pitti> actuall in -updates already, I think
[16:16] <cjwatson> wasn't that xubuntu-docs anyway?
[16:16] <pitti> no, ubuntu-docs
[16:16] <cjwatson> ok
[16:17] <skaet> hmm, so we appear to have run smack into the a2 testing crunch we were afraid of.
[16:18] <skaet> jibel,  what's your current plan for today?
[16:18] <jibel> skaet, I'm nearly done with A2 smoketest, now syncing DVDs, I can do lucid d-i instead.
[16:19] <cjwatson> note that the lucid images that need testing in particular for this are DVDs, both amd64 and i386
[16:20] <cjwatson> I can do lucid DVD i386 if people don't mind me doing it as the person who wrote the code
[16:20] <jibel> yes. I can sync that now and post the results tomorrow morning.
[16:20] <skaet> jibel,  thanks.
[16:20] <ara> awesome, thanks jibel
[16:20] <skaet> cjwatson,  not worried.  :)
[16:20] <jibel> skaet, but no smoketest of natty a2 dvd if you agree.
[16:21] <pitti> I think 10.04.2 CDs are more urgent wrt. that
[16:21] <skaet> jibel,  ok,  don't think we have a choice at this point - if we want to get the 10.04.2 cert run done.
[16:21] <pitti> we'll get more community feedback on natty alphas than for lucid point releases
[16:21] <ara> pitti, agreed
[16:22] <ScottK> And undetected problems in an Alpha release are much less important than a problem in an LTS point release.
[16:22]  * skaet nods
[16:23] <charlie-tca> o/
[16:23] <skaet> ok,  so A2 smoke test of DVDs goes on the shelf, and we smoke test lucid, so hw cert can start tomorrow (if all goes well)
[16:24] <skaet> are the A2 images ready to go to the iso tracker?  (so we can get community testing started on those)
[16:24] <pitti> if we get results for the DVD in both modes, d-i can go to -updates
[16:24] <skaet> pitti,  ack
[16:24] <cjwatson> a2> no, I was expecting that to start with tomorrow's autobuilds
[16:24] <pitti> once hw cert passes, eglibc and basic stuff like consolekit can go, too
[16:25] <cjwatson> so that still means running cert against an image built from -proposed
[16:25] <pitti> I did some smoketesting on the natty dailies last week and yesterday, looks ok so far
[16:25] <cjwatson> which I'm happy with, but we seemed to be at an impasse on it earlier
[16:25] <pitti> if we don't run cert against -proposed, we can alternatively switch to -updates right after the d-i smoketest
[16:25] <hggdh> and we are still running the server dailies on Hudson
[16:25] <hggdh> (natty)
[16:25] <pitti> and test the other packages separately, as usual
[16:25] <cjwatson> I don't agree - that would mean dropping a bunch of stuff out
[16:25] <cjwatson> I think that would create substantial confusion CD-wise
[16:26] <pitti> the disadvantage is that we'll do a hw cert test against an older version of pacakges
[16:26] <pitti> and the actual 10.04.2 release will be different than what has been tested
[16:26] <cjwatson> also, the upstart patch is such that it should be on the CD
[16:26] <pitti> that's why I'd much prefer hw cert against the -proposed ones
[16:26] <pitti> but I think if that's a no-go, we could cope
[16:26] <ara> pitti, anyway, we won't be finishing full cert until late next week
[16:28] <ara> cjwatson, why building from -updates will mean that the rest will go out?
[16:28] <ara> cjwatson, are we building only one daily from -updates
[16:28] <ara> ?
[16:29] <pitti> if we require that "image that hw cert tests" == "released image", we'll need to postpone the remaingin proposed updates until after 10.04.2 and miss those fixes
[16:29] <pitti> which would be unfortunate
[16:29] <pitti> if hw cert is testing the current images, then they would be in
[16:29] <pitti> for all intents and purposes, the current dailies are the final 10.04.2 release
[16:29] <cjwatson> ara: we only build one set of dailies, and they are from -proposed
[16:29] <pitti> unless testing/cert detects regressions
[16:29] <cjwatson> ara: the effect of switching to -updates is that anyone testing the CDs tests only -updates
[16:30] <skaet> cjwatson,  pitti,   let me see if I've got it straight -  QA suspends rest of A2's smoke tests for today and A2 tomorrow images is for iso tracker (not ideal, but low risk);   10.04.2 - we get DVD runs from QA (and other volunteers) with current dailies (which will become 10.04.2), so we can move to updates,  then hw cert can start?
[16:31] <cjwatson> alpha images have nearly always gone to the ISO tracker on Tuesday, in practice.
[16:31] <ara> skaet, if d-i and eglibc are in -updates, we are happy to test from -proposed
[16:32] <skaet> cjwatson,  ack
[16:32] <jibel> o/
[16:32] <cjwatson> it's also what https://wiki.ubuntu.com/MilestoneProcess says - "release minus 2 days"
[16:34] <skaet> jibel, go ahead
[16:34] <jibel> re a2, during smoketest I've identified 2 showstoppers  on amd64 bug 710582 and bug 710612 .
[16:35] <jibel> It would be great if someone could confirm it's not just me.
[16:35] <jibel> (or better that it is just me)
[16:36] <pitti> the second was discussed this morning on #u-devel, I think that's not just you
[16:36] <pitti> (unfortunately I don't remember/have read the outcome)
[16:36] <cjwatson> it was discussed as a result of jibel mentioning it :-)
[16:36] <pitti> ah
[16:36] <cjwatson> and that was just me saying "not a debconf bug"
[16:37] <Riddell> I couldn't confirm bug 710612 with today's ISO
[16:38] <skaet> jibel, thanks.  will work with others then after this meeting to get someone else to confirm 710582
[16:38] <cjwatson> I poked ev about jibel's latest reply to 710582
[16:38] <jibel> skaet, thanks
[16:38] <skaet> cjwatson, thanks
[16:38] <cjwatson> I don't think it would strongly benefit from other people reproducing it
[16:38] <cjwatson> unless those other people are able to debug webkit directly
[16:38] <skaet> heh,  fair 'nuf
[16:39] <cjwatson> 710612 is probably a race of some kind :-/
[16:39] <skaet> :(
[16:39] <skaet> okie,  back to 10.04.2 then...
[16:39] <cjwatson> I expect it depends on how long you take to respond to the parallelised questions
[16:40] <skaet> ?
[16:41]  * skaet is still jetlagged - parallelised questions isn't parsing 
[16:41] <cjwatson> it's a detail of installer design
[16:41] <cjwatson> relevant to 710612
[16:41] <pitti> cjwatson: ubiquity is copying files while the user still creates accounts, sets time zone, etc.
[16:41] <pitti> that happens in parallel since maverick
[16:42]  * cjwatson thinks pitti meant to direct that to skaet
[16:42] <pitti> oops, yes
[16:42] <cjwatson> anyway, yes, 10.04.2
[16:43]  * skaet  light dawns.... thought "you" was in reference to something I needed to answer about 10.04.2, not 710582....  ok, clarity. 
[16:43] <cjwatson> ah, right, sorry
[16:43] <ara> o/
[16:43] <skaet> go ara,  I think your questions are the ones we need answered now..
[16:44] <ara> OK, so I think that if, as pitti says, QA tests d-i, d-i and eglibc can go to -updates
[16:44] <ara> and we are happy to run cert  from -proposed cds once those are in -updates
[16:44] <ara> pitti, those are the packages that can affect hw, are they?
[16:45] <pitti> ara: right
[16:45] <pitti> but eglibc also needs extra verification
[16:45] <pitti> so a pure smoketest isn't enough for eglibc IMHO
[16:45] <cjwatson> hm, there is one quirk here
[16:46] <cjwatson> this only applies to live filesystems
[16:46] <cjwatson> but live filesystems that are built against -proposed contain -proposed in their sources.list
[16:46] <cjwatson> I don't think that's preserved in the installed system, but it means that people e.g. upgrading live USB sticks get stuff from -proposed
[16:46] <cjwatson> I don't think we should release that way
[16:47] <pitti> agreed
[16:47] <cjwatson> so, sorry to put a spanner in the works, but if cert must check the final candidate images, then I think we may really need to finish verification before cert starts
[16:47] <pitti> but that shouldn't matter for hw cert, just for final validation?
[16:47] <pitti> (i. e. after rebuilding the CD from -updates only at the end)
[16:47] <cjwatson> with the exception of server images, which could go ahead
[16:47] <cjwatson> hence my "if"
[16:48] <pitti> I thought hw certification would be by and large "test default install on different hw" while validation would be "test all install modes on pretty much one kind of hw"
[16:49] <pitti> so for hw cert a CD rebuild wouldn't hurt, but it mustn't happen for the latter?
[16:49] <cjwatson> are folks agreed that cert does not have to be on the very final set of images that we release?
[16:49] <skaet> cjwatson, hw cert is testing the functional equivalent, rather than the final.
[16:49] <cjwatson> in that case I withdraw my spanner
[16:49] <skaet> heh,  that's what was discussed in dallas..
[16:49] <ara> cjwatson, yes, the images don't need to be final, but we need everything that affects hw in -updates
[16:49] <cjwatson> round and round we go.  sorry.
[16:50] <skaet> ok,  jibel,  are you good with the d-i and eglibc testing today?
[16:52] <jibel> skaet, d-i ok, eglibc, I can only install, which doesn't verify anything.
[16:53] <skaet> jibel,  thanks
[16:53] <ara> hggdh should be able to verify https://bugs.launchpad.net/ubuntu/+source/eglibc/+bug/694772
[16:53] <skaet> cjwatson,  what's needed before the eglibc can be moved to updates?
[16:54] <pitti> bug 702190  is a nuisance to verify, as it doesn't have a test case; if it passes an install check, I'd consider that enough regression testing, though
[16:54] <cjwatson> pitti may or may not agree, but TBH, it's had enough pre-release testing that I'd be happy with regression testing
[16:54] <skaet> thanks cjwatson, pitti.   ok
[16:54] <pitti> bug 694772 should be verified as part of validation testing, as it happened during iso tests
[16:55] <cjwatson> 702190 does have a test case, it's just rather opaque and involves compiling and running a program on the right kind of hardware (comment 1)
[16:55] <pitti> bug 672177  is the third eglibc bug and should be testable during validation
[16:56] <cjwatson> it's also a multi-part bug - I think the pre-release testing has covered much of that, although it's known not to be sufficient on its own
[16:57] <skaet> hggdh, can you help out on 694772?
[16:58] <cjwatson> so on the whole I think install + upgrade smoketests should be sufficient for that
[16:58] <cjwatson> otherwise it could easily be a rabbithole that consumes QA forever
[16:58] <skaet> cjwatson,   ok.
[16:59] <hggdh> skaet, looking into it
[16:59] <skaet> thanks hggdh.
[16:59] <skaet> jibel:  are you ok with cjwatson's proposal?
[17:00] <jibel> skaet, if everybody is ok, I'm fine with his proposal.
[17:01] <skaet> pitti, you ok?
[17:01] <pitti> ack
[17:01] <skaet> ok, that's the plan then.
[17:02] <skaet> we'll carry this conversation over to #u-release
[17:02] <skaet> we're running late now
[17:02] <skaet> any other critical issues to bring up?
[17:02] <hggdh> pitti, for 694772 -- is it OK if I install the updates, then reboot into busybox and send in a telinit u?
[17:03] <cjwatson> as long as it's busybox init ...
[17:03] <cjwatson> (this may not be entirely trivial to arrange)
[17:04] <cjwatson> it might be easier to boot the server CD in rescue mode and then use 'telinit u' there
[17:04] <pitti> hggdh: I thought the fix in eglibc was to precisely not to that?
[17:04] <cjwatson> but none of that validates whether eglibc is doing the right thing in its postinst, of course!
[17:04] <cjwatson> so actually I don't think that's a valid test
[17:04] <hggdh> hum
[17:04] <cjwatson> yeah, pitti's right too
[17:05] <hggdh> darn, indeed :-(
[17:05] <pitti> I'd think the test case for this is "validate that the server iso installs"?
[17:05] <cjwatson> hggdh's proposal is a way to test upstart in isolation
[17:05] <cjwatson> but I agree with pitti, I don't think there's much point in lots of detailed messing about here
[17:05] <hggdh> the problem is I would need to be in ISO install to test
[17:06] <pitti> note that upstart only adds a breaks to older eglibc versions
[17:06] <cjwatson> we haven't fixed the upstart part yet anyway
[17:06] <pitti> i. e. testing the the new upstart in isolation won't give us anything for this bug
[17:06] <cjwatson> any d-i install smoketest by anyone would be sufficient validation for 694772
[17:06] <pitti> I agree
[17:06] <skaet> ok
[17:07] <ara> cjwatson, then jibel's test should be enough?
[17:07] <cjwatson> it wouldn't be comprehensive proof, but the server team have been working on establishing that independently.  it would be regression-testing, which I think in this case will be enough
[17:08] <skaet> on that note, probably time to end the meeting.
[17:08] <skaet> thanks cjwatson, pitti, ara, jibel, hggdh, Riddell, ScottK
[17:09] <skaet> #endmeeting
[17:09] <MootBot> Meeting finished at 11:09.
[17:09] <ara> thanks skaet, all!
[17:09] <pitti> thanks everyone *phew*
[17:10] <skaet> jibel, can you hang out in #u-release today - so we can work through this.
[17:10]  * skaet agrees with pitti - *phew*....  need more 'spresso!
[17:13] <jibel> skaet, after 2000UTC, when everything is back to normal here, I need to deal with the kids now, see you later.
[17:13] <skaet> jibel,  thanks!
[18:01] <kees> \o
[18:01] <jjohansen> o/
[18:02] <jdstrand> o/
[18:02] <mdeslaur> yellow
[18:03]  * sbeattie waves
[18:03] <jdstrand> shall I run the meeting?
[18:04]  * mdeslaur pushes jdstrand to front of room
[18:04] <jdstrand> ok then :)
[18:04] <jdstrand> #startmeeting
[18:04] <MootBot> Meeting started at 12:04. The chair is jdstrand.
[18:04] <MootBot> Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE]
[18:05] <jdstrand> [TOPIC] weekly standup report
[18:05] <MootBot> New Topic:  weekly standup report
[18:05] <jdstrand> I've got several things tugging at me at present
[18:06] <jdstrand> I am helping the release team with my archive admin duties, and that has slowed me down a bit as I learn the processes
[18:07] <jdstrand> I'm working on the dbus-glib update and the qrt script for dbus bindings
[18:07] <jdstrand> there is also a lot of various followup work I am trying to catchup on
[18:08] <jdstrand> that should be it for me
[18:08] <jdstrand> kees: you're up
[18:08] <kees> okidoky
[18:08] <kees> I've got OOo to publish, and kernel to do USNs for
[18:09] <kees> I'm on triage, and I'm going to try to clean up some of the open security bugs
[18:09] <kees> I've also got a regression in the kernel I need to test a fix for. I'm kind of all over the place.
[18:09] <kees> that's it, mdeslaur you're up :)
[18:09] <mdeslaur> I'm writing a subversion test script. I should get it published today
[18:10] <mdeslaur> after that, I was to work on the new fuse stuff
[18:10] <mdeslaur> and maybe take a look at exim4 if I have time
[18:10] <mdeslaur> that's it.
[18:10] <mdeslaur> sbeattie: you're next
[18:11] <sbeattie> I'm on community this week.
[18:12] <sbeattie> I've got another openjdk update planned this week; amazingly the arm hamsters managed to complete all the builds over the weekend.
[18:12] <sbeattie> so I'll be testing those today.
[18:13] <sbeattie> I need to put together snapshots for apparmor 2.5.2 and 2.6.0 releases at some point, but that's been stalled on reviewing patches for 2.5.2.
[18:13] <sbeattie> I think that's it for me.
[18:13] <jdstrand> cool
[18:14] <jdstrand> [TOPIC] miscellaneous
[18:14] <MootBot> New Topic:  miscellaneous
[18:14] <jdstrand> so I have several random things to bring up that have been sitting in tomboy for far too long :)
[18:15] <jdstrand> first (and speaking of apparmor), we need to have an upstream apparmor meeting
[18:15] <jdstrand> is that something we can do this week?
[18:15] <sbeattie> yeah.
[18:15] <jjohansen> yep
[18:15] <jdstrand> (to discuss the rally stuff)
[18:15] <jdstrand> cool
[18:15] <jdstrand> we can schedule that in #apparmor
[18:16] <jjohansen> yep
[18:16] <jdstrand> one thing that has been asked of the security team in the past, and mentioned to be recently, is that we should strive to be as open as possible
[18:17] <jdstrand> I'd like to provide summaries of our weekly security meetings somewhere
[18:17] <jdstrand> I'm not sure where. I'm not convinced it is super interesting to devel@, so I thought maybe somewhere in the wiki?
[18:17] <kees> summary of the stand-up?
[18:18] <jdstrand> kees: stand-up and anything else. ie, this meeting :)
[18:18] <mdeslaur> jdstrand: our activity reports are way more interesting than our meetings...
[18:19] <jdstrand> mdeslaur: yes, but other teams do log there meetings (eg, the server team)
[18:19] <mdeslaur> unless we talk about something other than what we have planned for the week
[18:19] <kees> I'm not opposed to it, but it seems like summarizing our stand-ups isn't very useful. if it was a long meeting, it would make more sense?
[18:19] <jdstrand> now, there could be a concern about people saying "I'm going to work on this", get sidetracked and not do it, and then mentioning it the next week
[18:19]  * ScottK suspects it's interesting enough for ubuntu-devel.
[18:20] <jdstrand> I'm open to not doing anything with the stand-up report (ie "I'm working on foo this week"), but including the other bits as they come up
[18:20] <jdstrand> what do other people think?
[18:20] <kees> yeah, I'm not against it, I just question the value. if people think there's value, then let's do it.
[18:21] <jdstrand> well, in a discussion I had it was implied that it should be done, and it isn't
[18:21] <jdstrand> so I am trying to figure out the best way to do that
[18:21]  * jjohansen thinks its extra work for very little gain
[18:22] <jdstrand> jjohansen: maybe, but it is an action item I can take
[18:22] <mdeslaur> jdstrand: I wouldn't include the stand up report, but if we discuss anything else it could be worth it
[18:22] <jdstrand> I don't think it is much work. our meetings are short, the summary even more so
[18:23] <jdstrand> mdeslaur: well, what if we did this:
[18:23] <jdstrand> kees is on triage, sbeattie is on community. sbeattie also hopes to work on apparmor 2.5.2
[18:23] <jdstrand> ie, don't mention the specific security updates/audits we are working on
[18:24] <mdeslaur> that's fine
[18:24] <jdstrand> just that 'mdeslaur is working on foo in addition to various security updates)
[18:24] <jdstrand> s/)/'/
[18:24] <jdstrand> I'll come up with some sort of summary, and we can discuss it outside of the meeting
[18:25] <jdstrand> [ACTION] jdstrand to write up meeting minutes and submit to team for review
[18:25] <MootBot> ACTION received:  jdstrand to write up meeting minutes and submit to team for review
[18:25] <jdstrand> perhaps we can table where the will reside based on what we decide should be in them
[18:25] <jdstrand> s/the will/they will/
[18:26] <jdstrand> I also have various items from my rally notes that I think should either be assigned or documented somewhere for todo
[18:27] <jdstrand> please feel free to add any to this list
[18:27] <jdstrand> * respin ia32-libs (natty and earlier)
[18:27] <jdstrand> * add mvo's apt script to qrt
[18:27] <jdstrand> * kernel capabilities tests
[18:27] <jdstrand> * kernel keyring tests (LTP?)
[18:28] <jdstrand> * /etc/apparmor.d/mysqld.d for akonadi (currently assigned to me)
[18:28] <mvo> jdstrand: hm?
[18:28] <mvo> qrt?
[18:28] <jdstrand> * vm-iso changes to get rid of vm-new stuff
[18:28] <jdstrand> mvo: hi! not an action item for you
[18:28] <jdstrand> mvo: we discussed at the rally how we might want to snag your apt tests
[18:28] <jdstrand> mvo: and somehow incorporate them into qa-regression-testing
[18:29] <kees> http://people.ubuntu.com/~mvo/apt/auth-test-suit/
[18:29] <MootBot> LINK received:  http://people.ubuntu.com/~mvo/apt/auth-test-suit/
[18:29] <jdstrand> mvo: and then conceivably run them on a release basis to be sure we are ok
[18:29] <mvo> aha, this one :)
[18:29] <mvo> ta!
[18:29] <jdstrand> * add ipc to kernel tests
[18:30] <jdstrand> so, with the exception of ia32 and akonadi, it seems it is fine and appropriate to add these as TODO's to the various scripts if we don
[18:30] <jdstrand> 't/can't do them right away
[18:31] <jdstrand> does anyone want to claim any of these? the akonadi one is assigned to me currently, but it is likely I won't get to it anytime soon, so can consider that up for grabs
[18:31] <mdeslaur> I can put ia32-libs at the end of my to-do list
[18:31] <kees> what were the details on the caps tests?
[18:32] <kees> just for qrt?
[18:32] <jdstrand> kees: yeah-- something in qrt to verify that they work properly
[18:32]  * kees ponders
[18:32] <jdstrand> kees: positive and negative tests
[18:32] <kees> I can take it, but it's not going to be very high priority for a while.
[18:32] <jdstrand> oh sure
[18:32] <sbeattie> what sort of tests for caps?
[18:33] <jdstrand> this isn't about 'can we do it *now*' as much as if people want to do it, they can claim it, otherwise we can just pop it into the script as a todo
[18:33]  * sbeattie notes the apparmor regression tests test a few of the capabilities, but doesn't test the whole bounding set/inheritance stuff.
[18:33] <jdstrand> [ACTION] mdeslaur to take ia32-libs when time allows
[18:33] <MootBot> ACTION received:  mdeslaur to take ia32-libs when time allows
[18:33] <mdeslaur> so, I can put ia32-libs on my to-do list, just as long as you don't expect it to ever get done
[18:33] <mdeslaur> \o/
[18:34] <jdstrand> hehe
[18:34] <sbeattie> actually, I should probably take a look at that one, to learn how its done.
[18:34] <sbeattie> (ia32-libs)
[18:34] <kees> [ACTION] kees to take kernel capabilities tests when time allows
[18:34] <jdstrand> mdeslaur: you cool with sbeattie doing that?
[18:34] <kees> aw, that only works for the chair, unlike urls
[18:34] <jdstrand> [ACTION] kees to take kernel capabilities tests when time allows
[18:34] <MootBot> ACTION received:  kees to take kernel capabilities tests when time allows
[18:35] <jdstrand> I think the apt and keyring ones are pretty big
[18:35] <jdstrand> (potentially)
[18:35] <jdstrand> I'll add TODO notes for them, and maybe Roadmap the apt one
[18:36] <sbeattie> yeah, kernel keyring's had lots of bugs.
[18:36] <jdstrand> [ACTION] jdstrand to add keyring and apt tests to TODO in the scripts
[18:36] <mdeslaur> jdstrand: sure, I don't care
[18:36] <MootBot> ACTION received:  jdstrand to add keyring and apt tests to TODO in the scripts
[18:36] <mdeslaur> jdstrand: either way, I won't be doing it :)
[18:36] <jdstrand> [ACTION] sbeattie to respin ia32-libds
[18:36] <kees> *snicker*
[18:36] <MootBot> ACTION received:  sbeattie to respin ia32-libds
[18:36] <jdstrand> hehe
[18:37] <jdstrand> sbeattie: I'd focus on natty first, then maybe do earlier releases?
[18:37] <kees> s'okay, we'll have multiarch before natty releases, and then we won't need ia32-libs! :)
[18:37] <jdstrand> \o/
[18:37] <mdeslaur> kees: lol
[18:37] <kees> slangasek: right? ^^ :)
[18:37] <slangasek> can't promise ia32-libs will go away this cycle
[18:37] <kees> :)
[18:37] <slangasek> especially as Yokozar has been adding more packages to it on the other end
[18:38] <slangasek> which I'm unhappy about but am not going to meddle with
[18:38] <sbeattie> heh
[18:38] <jdstrand> sbeattie: oh, if Yokozar's been doing that, natty may not need the respin anyway
[18:38] <jdstrand> so no one took the akonadi one. I'll leave it on my todo liest then
[18:38] <jdstrand> list
[18:38] <jdstrand> that leaves vm-iso. how important is this?
[18:39] <sbeattie> jdstrand: I have it on my personal todo list as well, but not sure when I'll get the round tuits.
[18:39] <mdeslaur> jdstrand: what is the vm-iso one?
[18:39] <sbeattie> (it == mysql-akonadi)
[18:39] <jdstrand> sbeattie: k. if one of us starts, let's let the other know
[18:39] <sbeattie> jdstrand: will do.
[18:39] <jdstrand> [ACTION] mysql/akonadi work coordinated between sbeattie and jdstrand
[18:39] <MootBot> ACTION received:  mysql/akonadi work coordinated between sbeattie and jdstrand
[18:40] <jdstrand> oh, I can take the kernel ipc tests for qrt
[18:40] <jdstrand> (fallout from dbus work)
[18:40] <jdstrand> [ACTION] jdstrand to add kernel ipc tests to qrt
[18:40] <MootBot> ACTION received:  jdstrand to add kernel ipc tests to qrt
[18:41] <jdstrand> ok. back to vm-iso. how important is this? on the one hand, vmbuilder has been a handful, on the other hand it mostly works
[18:42] <kees> jdstrand: I think it's as important as the person wanting to use it makes it. i.e. I think I was the one complaining about vmbuilder, so if I'm going to use vm-iso, I should work on it.
[18:43] <jdstrand> (vm-iso is from ubuntu-qa-tools/vm-tools and it has been suggested we use that instead of vm-new for creating new VMs (see wiki.ubuntu.com/SecurityTeam/TestingEnvironment)
[18:43] <jdstrand> kees: fair enough
[18:43] <jdstrand> kees: I don't think it needs an action or assignment
[18:43] <kees> right
[18:43] <jdstrand> I just had it on my list to bring up
[18:44] <kees> cool by me
[18:44] <mdeslaur> jdstrand: put it here: https://wiki.ubuntu.com/SecurityTeam/Roadmap
[18:44] <jdstrand> does anyone have anything else from the rally that we should get out of our personal notes and assigned or put some where?
[18:45] <jdstrand> [ACTION] jdstrand to add vm-iso work to Roadmap
[18:45] <MootBot> ACTION received:  jdstrand to add vm-iso work to Roadmap
[18:45] <kees> I'll check my laptop, but I don't have that list handy at the moment.
[18:45] <jdstrand> (excepting apparmor stuff)
[18:45] <kees> (it was short, if not empty)
[18:45] <jdstrand> that's cool
[18:45] <jdstrand> I think that is everything on my list
[18:45] <jdstrand> oh, want to talk to skaet about dapper eol
[18:46] <jdstrand> skaet: you around? :)
[18:46]  * jdstrand takes that as a no
[18:47] <jdstrand> [ACTION] jdstrand to followup with skaet regarding dapper eol announcement
[18:47] <MootBot> ACTION received:  jdstrand to followup with skaet regarding dapper eol announcement
[18:47] <kees> btw, I'm going to replace u-maint with ubuntu-dev-tools's update-maintainer.
[18:47] <jdstrand> kees: oh? not the other way around?
[18:48] <kees> jdstrand: all the missing logic is included in udt's version now.
[18:48] <jdstrand> I thought you said u-maint had some advantages over update-maintainer
[18:48] <jdstrand> sweet :)
[18:48] <jdstrand> no more 2 year lag for us anymore! :P
[18:48] <kees> it did, but that's been fixed now, after I pointed it out. There's one feature left I'm going to forward.
[18:48] <mdeslaur> \o/
[18:48] <jdstrand> I'm sorry. 18 months
[18:49] <mdeslaur> hehe
[18:49] <jdstrand> [ACTION] kees to update umt to use update-maintainer
[18:49] <MootBot> ACTION received:  kees to update umt to use update-maintainer
[18:49] <jdstrand> [TOPIC] questions
[18:49] <MootBot> New Topic:  questions
[18:49] <jdstrand> does anyone have any other questions or items to discuss?
[18:51] <kees> nothing here
[18:52] <jdstrand> alrighty then
[18:52] <jdstrand> thanks everyone!
[18:52] <jdstrand> #endmeeting
[18:52] <MootBot> Meeting finished at 12:52.
[18:52] <kees> thanks jdstrand!
[18:52] <jdstrand> sure! :)
[18:52] <mdeslaur> thanks!
[19:01]  * persia looks for stgraber
[19:01] <cdbs> poolie, welcome!
[19:02] <poolie> hi cdbs
[19:03] <ari-tczew> persia: Are new DMB members know?
[19:04] <persia> ari-tczew, No.  See https://lists.ubuntu.com/archives/technical-board/2011-January/000653.html and followups
[19:06] <bdrung> stgraber: meeting or not meeting?
[19:06] <persia> I think we want a meeting, but it's a matter of chair.
[19:06] <ari-tczew> persia: so yours memberships were extended, when we get to know new members?
[19:06] <persia> ari-tczew, When they are decided.
[19:06] <ari-tczew> persia: I'd like to vote, but I guess is out of time.
[19:07] <persia> Rather the opposite: the nomination period just ended: a request for input from Ubuntu Developers will start soon.
[19:07] <cdbs> ari-tczew, Did you apply for nomination?
[19:08] <ari-tczew> cdbs: not me, I want to vote for someone else.
[19:08] <cdbs> I just tried my luck, though I am pretty much sure I won't get in
[19:08] <poolie> hi persia
[19:08] <persia> Hey poolie
[19:08] <ari-tczew> cdbs: your changes are more than me anyway :P
[19:09] <persia> bdrung, stgraber seems afk, would you mind taking over?
[19:09] <bdrung> k
[19:10] <bdrung> cody-somerville, cjwatson, soren, stgraber: DMB meeting now!
[19:10] <cody-somerville> I'm very sorry. I unfortunately won't be able to make today's meeting.
[19:10] <cjwatson> oh, seriously?  bah
[19:11] <bdrung> are we quorable?
[19:11] <cody-somerville> I'll send a write-up re: Marco via e-mail in lieu
[19:11] <persia> We are if cody-somerville can attend :)
[19:11] <bdrung> (if that's a word)
[19:11] <persia> quorate
[19:11]  * cody-somerville is just about to head out the door to Ottawa otherwise he'd be here.
[19:12] <cdbs> :(
[19:12] <persia> So we're waiting on one of geser, stgraber, soren to be quorate
[19:13] <poolie> perhaps the board should get bigger, or the quorum requirement should get smaller?
[19:13] <bdrung> i pinged geser on devel
[19:14] <persia> poolie, The two are tightly linked.  That said, if too much time passes, we could perhaps begin, and resolve outstanding votes via email (as poolie is here, by special arrangement)
[19:16] <bdrung> ok, let's start then
[19:16] <bdrung> #startmeeting
[19:16] <MootBot> Meeting started at 13:16. The chair is bdrung.
[19:16] <MootBot> Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE]
[19:16] <bdrung> [TOPIC] Review of previous action items
[19:16] <MootBot> New Topic:  Review of previous action items
[19:17] <bdrung> poolie is here, so the first point is processed
[19:17]  * cjwatson switches to his phone, sorry, had already booked family time without noticing this meeting so will have to get off the laptop
[19:18] <bdrung> persia started the selection process for DMB renewal and requested a term extension for current DMB members
[19:19] <persia> Does anyone have permission to flush the d-m-b@ moderation queue?  I think we have 10 nominees, but there's at least one I've had confirmed on IRC for whom I haven't seen the mail yet.
[19:21] <cjwatson> persia: I do
[19:21] <ari-tczew> persia: do you have informations who has been nominated?
[19:21] <persia> ari-tczew, Yes.
[19:21] <ari-tczew> persia: pm
[19:22] <cjwatson> but it's empty anyway
[19:22] <persia> Hmm..
[19:23] <persia> Ah, went to me personally.  I'll forward.
[19:23]  * persia needs to check headers more carefully
[19:23] <bdrung> [TOPIC] Review progress of probationary period of Marco Rodrigues
[19:23] <MootBot> New Topic:  Review progress of probationary period of Marco Rodrigues
[19:24] <persia> Let's skip this, as cody-somerville is on his way to Ottawa and sending email.  Maybe [ACTION] it?
[19:24] <bdrung> [ACTION] cody-somerville to write-up progress of probationary period of Marco Rodrigues
[19:24] <MootBot> ACTION received:  cody-somerville to write-up progress of probationary period of Marco Rodrigues
[19:25] <bdrung> [TOPIC] Confirm renewal of MOTU status for Bhavani Shankar
[19:25] <MootBot> New Topic:  Confirm renewal of MOTU status for Bhavani Shankar
[19:25] <persia> So, six months ago we granted bhavi probabtionary MOTU status.  We're supposed to review that.  Personally, I haven't seen any issues: has anyone else?
[19:25] <bdrung> i haven't
[19:26] <ari-tczew> Sorry for interrupt. I want to see bhavi still in MOTU.
[19:26] <cjwatson> I
[19:26] <cjwatson> er
[19:27] <cjwatson> I've seen some teething troubles, but generally things seem OK now from my POV
[19:27] <bdrung> do we need to vote?
[19:27] <persia> Let's do so formally, as we have to pass to email anyway.
[19:29] <bdrung> [VOTE] renewal of MOTU status for Bhavani Shankar
[19:29] <MootBot> Please vote on:  renewal of MOTU status for Bhavani Shankar.
[19:29] <MootBot> Public votes can be registered by saying +1/-1/+0 in the channel, private votes by messaging the channel followed by +1/-1/+0  to MootBot
[19:29] <MootBot> E.g. /msg MootBot +1 #ubuntu-meeting
[19:29] <bdrung> +1
[19:29] <MootBot> +1 received from bdrung. 1 for, 0 against. 0 have abstained. Count is now 1
[19:29] <cjwatson> +1
[19:29] <MootBot> +1 received from cjwatson. 2 for, 0 against. 0 have abstained. Count is now 2
[19:29] <persia> +1 : most of my concerns from the time of application have been addressed during the probationary period
[19:29] <MootBot> +1 received from persia. 3 for, 0 against. 0 have abstained. Count is now 3
[19:30] <bdrung> [ENDVOTE]
[19:30] <MootBot> Final result is 3 for, 0 against. 0 abstained. Total: 3
[19:31] <bdrung> [ACTION] collect vote from other DMB members via email
[19:31] <MootBot> ACTION received:  collect vote from other DMB members via email
[19:32] <geser> Hi
[19:32] <bdrung> [TOPIC] Martin Pool's application for per-package upload rights for bzr and related packages
[19:32] <MootBot> New Topic:  Martin Pool's application for per-package upload rights for bzr and related packages
[19:33] <bdrung> geser: hi. we reached the quorum.
[19:33] <bdrung> [TOPIC] Confirm renewal of MOTU status for Bhavani Shankar
[19:33] <MootBot> New Topic:  Confirm renewal of MOTU status for Bhavani Shankar
[19:35] <bdrung> geser: Six months ago we granted bhavi probabtionary MOTU status. We haven't seen any issue since then, did you? Are you ready to vote?
[19:35] <geser> I didn't heard about any complains and I'm ready to vote
[19:35] <bdrung> [VOTE] renewal of MOTU status for Bhavani Shankar
[19:35] <MootBot> Please vote on:  renewal of MOTU status for Bhavani Shankar.
[19:35] <MootBot> Public votes can be registered by saying +1/-1/+0 in the channel, private votes by messaging the channel followed by +1/-1/+0  to MootBot
[19:35] <MootBot> E.g. /msg MootBot +1 #ubuntu-meeting
[19:36] <poolie> hi, yes, i'm here
[19:37] <poolie> so,
[19:37] <poolie> i don't do a lot of packaging, but i think i know enough not to be dangerous
[19:37] <persia> geser, ?  The rest of us voted.  Vote is at +3.
[19:37] <geser> +1
[19:37] <MootBot> +1 received from geser. 1 for, 0 against. 0 have abstained. Count is now 1
[19:38] <poolie> i think having ppu would help me push proposed bzr SRUs into -proposed, where they can be reviewed, and this would save people some time
[19:38] <bdrung> [ENDVOTE]
[19:38] <MootBot> Final result is 1 for, 0 against. 0 abstained. Total: 1
[19:38] <bdrung> summa summarum that's four of us
[19:40] <bdrung> [TOPIC] Martin Pool's application for per-package upload rights for bzr and related packages
[19:40] <MootBot> New Topic:  Martin Pool's application for per-package upload rights for bzr and related packages
[19:40] <persia> poolie, When considering the differences between SRUs and security updates, what must one concern oneself about in terms of ensuring the user is not surprised by the output of bzr?
[19:40] <bdrung> [LINK] https://wiki.ubuntu.com/MartinPool/DeveloperApplication
[19:40] <MootBot> LINK received:  https://wiki.ubuntu.com/MartinPool/DeveloperApplication
[19:41] <poolie> persia, security updates are more conservative
[19:41] <poolie> and i wouldn't expect our MRE would apply there
[19:41] <bdrung> MRE?
[19:41] <poolie> so, there should not be any changes to the output of bzr, unless they are absolutely necessary to fix the security problem
[19:41] <poolie> bdrung, micro release exception
[19:42] <poolie> the TB agreed that for instance bzr should upload 2.2.x into Maverick that originally shipped with 2.2.0
[19:42] <poolie> this process is very halting at the moment and i'd like to see it flow more smoothly
[19:44] <poolie> persia, is that the answer you were you asking  looking for, or are you asking about some more specific aspect of bzr output?
[19:45] <persia> That's fine.  The only part of the differences between -security and -updates you didn't mention is about build-dependencies, which affect things, but aren't so important in the context of bzr.
[19:45] <poolie> ah
[19:45] <geser> poolie: so the most benefit of PPU for you would be SRU and normal uploads to natty still go through Debian and sync?
[19:45] <poolie> right, so we/i know to not change them in updates either
[19:46] <poolie> this is a little more conservative than is required but we can normally do that
[19:46] <poolie> geser, basically
[19:46] <poolie> we have a pretty good pipelines of maxb and jelmer uploading to debian, but it falls down a bit for ubuntu-specific uploads
[19:47] <poolie> i would like to do some more ubuntu work generally, but that's the specific thing
[19:48] <bdrung> poolie: are you involved in packaging bzr on the debian side?
[19:49] <poolie> bdrung, mostly by committing to our packaging branches, and then jelmer or max will upload from there
[19:49] <poolie> not quite so much of that at the moment as they've been taking more of the initiative
[19:50] <poolie> oh, i might also mention that i did a lot of work on packaging bzr into PPAs
[19:50] <persia> poolie, The latest version of bzr in maverick (representing the sort of SRU you're likely to be targeting) has an automatic patch in debian/patches : How do you think this might be better represented?
[19:53] <bdrung> 2.2.0-1 and 2.2.1-0ubuntu1 added automatic patches to debian/patches
[19:53] <poolie> good question, i'll look
[19:54] <bdrung> same for 2.3.0~beta5-1
[19:57] <poolie> i'm looking at debian-changes-2.2.3-0\~bazaar1\~maverick1
[19:58] <poolie> the commentary on it says that this contains upstream changes introduced in that version
[19:58] <cjwatson> the autocommentary can be a bit ... misleading :-)
[19:58] <poolie> mm
[19:59] <poolie> it looks like this is a change that should have been marked as a packaging patch, but this has got misclassified as coming in an upstream update
[19:59] <cjwatson> it means changes to the upstream source (i.e. not debian/)
[19:59] <cjwatson> it's just poor wording
[19:59] <poolie> i see
[20:00] <poolie> the point of this patch is that bzr ships a copy of a small xml library
[20:00] <poolie> which i think we preferentially import
[20:00] <poolie> and debian/ubuntu policy is to not do that, but rather to depend on it from a package
[20:00] <poolie> which makes sense of course
[20:01] <poolie> (this makes me wonder if we should in fact just cut it out of upstream now)
[20:01] <persia> That makes perfect sense.  So, when applying that clearly distro-specific patch, how might one represent it to be obvious when encountering the source?
[20:02] <poolie> persia, i think it would be better as an explicitly named patch, describing its purpose
[20:02] <poolie> and mentioned in the series file
[20:02] <persia> That's how I'd do it :)
[20:03] <poolie> actually we don't prefentially import it
[20:03] <poolie> as far as i can tell this patch has no effect, assuming that the external elementtree library is present, which it always should be
[20:03] <poolie> this patch only seems to touch the fallback case?
[20:04] <poolie> ah, there is a second part fixing what i guess is an api version skew with configobject
[20:04] <poolie> so, one other thing i would think of doing is splitting them into the conceptually separate patches
[20:05] <persia> That would be even better.
[20:05] <poolie> and perhaps pushing the second upstream
[20:08] <poolie> so?
[20:08]  * persia doesn't have any more questions
[20:08]  * geser neither
[20:09] <persia> cjwatson, ?  bdrung ?
[20:09] <bdrung> cjwatson: do you have questions?
[20:10] <cjwatson> nope
[20:11] <bdrung> poolie: oh, i have one: you wrote "In a small fraction of cases the emotional tone is unattractive and offputting"
[20:12] <poolie> ah, this is under 'things i'd like to improve in ubuntu'?
[20:12] <bdrung> yes
[20:12] <bdrung> poolie: isn't the CoC enough? how can we do better?
[20:13] <poolie> i think the CoC is a great document
[20:13] <poolie> just having the document isn't enough
[20:14] <poolie> those of you i know from this meeting, i consider to be forces in the right direction on this
[20:14] <poolie> so i don't want to cast this as "you're getting it all wrong and I'll make the project nicer"
[20:14] <poolie> but, it's a thing i care about
[20:15] <persia> What do you think you can do to help improve the tone?
[20:15] <poolie> one thing you can do is that if you see someone give a harsh reply on a bug or list, just also offer a not-harsh to-the-point reply too
[20:16] <bdrung> poolie: we do that on irc channels
[20:16] <poolie> i think generally speaking just setting an example of how things ought to be is good
[20:16] <poolie> right
[20:18] <poolie> do any of you think there's stuff i should do, or keep in mind, in this department?
[20:18] <bdrung> but it's harder to do for bugs and lists
[20:18] <poolie> oh, one other thing is
[20:18] <poolie> it's remarkable how much more forgiving people will be of criticism if they get it promptly and if there is a way forward
[20:19] <poolie> this is one reason i care a lot about patch piloting
[20:19] <poolie> if there's a substantive criticism, fair enough, but it feels much worse if the person gets it after a month of silence
[20:19] <poolie> or with no invitation to do something with it next
[20:20] <poolie> this is kind of hard to fix because it's a matter of time, but you can try
[20:20] <poolie> to put it ahead of other work
[20:21] <bdrung> the second thing you dislike is the profusion of stacked or alternative toolchains makes packaging very complicated. any ideas of making packaging easier?
[20:21] <poolie> heh
[20:21] <bdrung> 3.0 (quilt) helped with getting rid of the different patch systems.
[20:21] <poolie> i'd like to get source package branches to the point they are used for every package
[20:22] <poolie> which would avoid some profusion
[20:22] <poolie> using quilt there is definitely a good setp
[20:22] <poolie> *step
[20:23] <poolie> in other aspects of packaging, i do see it as a thing that erects a barrier to working in ubuntu, but
[20:23] <bdrung> with source package branches for every package do you mean that the binary packages should be build from bzr branches instead of source tarballs?
[20:23] <poolie> right, so the source package would be generated as part of building
[20:23] <poolie> rather than uploaded by the developer
[20:24] <poolie> obviously some work has to be done both to actually make this work at all, and to make it a compelling alternative
[20:24] <poolie> but i would like to do it
[20:25] <poolie> https://dev.launchpad.net/LEP/BuildFromBranchIntoMain
[20:26] <bdrung> more ideas how to make packaging simpler?
[20:26] <bdrung> would GUI tools help? should the amount of files in debian/ reduced?
[20:26] <poolie> i think the Quickly idea of seeing packaging as part of the development toolchain is promising
[20:27] <poolie> that's only going to cover a fraction of apps that were written that way
[20:27] <poolie> separately, i think it's very interesting how ppas and recipe builds have taken off
[20:27] <poolie> that gives people a useful spot between upstream and ubunut
[20:27] <poolie> *ubuntu
[20:28] <poolie> i think we can do a lot by building on that, to make it easier for people who care about a particular branch to get that packaged, perhaps cooperating with people who have more packaging expertise
[20:28] <bdrung> re recipe builds, i have a bunch of projects where the bzr import fails and therefore i am unable to create daily builds.
[20:28] <poolie> (and that connects too to making the main distribution more consistent with what's happening there)
[20:29] <poolie> ok, i'd like to fix that
[20:29] <poolie> do you have a bug, or can you tell me which branches they are?
[20:29] <poolie> bug #
[20:30] <bdrung> poolie: vlc, xmms2, audacious - let me search for the bug number
[20:30] <bdrung> poolie: bug #402814 is the biggest blocker
[20:31] <bdrung> poolie: http://overbenny.wordpress.com/2010/08/16/daily-builds-rock-but-bzr-imports-suck/
[20:31] <poolie> ok
[20:32] <poolie> i think the first of those bugs is fixed?
[20:32]  * jelmer wakes up
[20:32] <poolie> heh
[20:32] <poolie> hi jelmer
[20:33] <poolie> https://bugs.launchpad.net/launchpad/+bug/594294 is interesting; i haven't seen it before and it seems like it ought to be just a one line fix
[20:33] <poolie> but perhaps it's actually complicated
[20:33] <poolie> the submodules thing is on our list, though not at the top at the moment
[20:33] <poolie> bdrung, how should we stay in touch about these things in the future?
[20:34] <poolie> perhaps it's enough to just have bug reports, but i would like to hear other feedback about which ones really matter most
[20:34] <jelmer> by weird coincidence, bug #519709 happens to be one of the bugs I'm working on at the moment
[20:34] <bdrung> poolie: i am subscribed to the bugs that affect me and i am always available via irc
[20:35] <poolie> ok, likewise
[20:35] <bdrung> let's continue the discussion after the meeting. we should vote.
[20:35] <poolie> if you want to bump a bug up, just ask
[20:35] <bdrung> poolie: in which channel?
[20:36] <poolie> #bzr, #launchpad, #ubuntu-devel
[20:36] <poolie> (hm, the latter of which i used to lurk in but this client doesn't seem to auto-join it; fixed)
[20:37] <bdrung> [VOTE] Martin Pool to gain per-package upload rights for bzr and related packages
[20:37] <MootBot> Please vote on:  Martin Pool to gain per-package upload rights for bzr and related packages.
[20:37] <MootBot> Public votes can be registered by saying +1/-1/+0 in the channel, private votes by messaging the channel followed by +1/-1/+0  to MootBot
[20:37] <MootBot> E.g. /msg MootBot +1 #ubuntu-meeting
[20:37] <cjwatson> +1
[20:37] <MootBot> +1 received from cjwatson. 1 for, 0 against. 0 have abstained. Count is now 1
[20:37] <geser> +1
[20:37] <MootBot> +1 received from geser. 2 for, 0 against. 0 have abstained. Count is now 2
[20:38] <bdrung> +1
[20:38] <MootBot> +1 received from bdrung. 3 for, 0 against. 0 have abstained. Count is now 3
[20:38] <persia> +1
[20:38] <MootBot> +1 received from persia. 4 for, 0 against. 0 have abstained. Count is now 4
[20:38] <bdrung> [ENDVOTE]
[20:38] <MootBot> Final result is 4 for, 0 against. 0 abstained. Total: 4
[20:38] <persia> Just to make sure, we're voting on the extended list in the application, right?
[20:38] <bdrung> yes
[20:39] <bdrung> probably all bzr-* packages
[20:39] <bdrung> poolie: congrats
[20:40] <bdrung> [TOPIC] Select a chair for the next meeting
[20:40] <MootBot> New Topic:  Select a chair for the next meeting
[20:40] <bdrung> who want to be chair?
[20:41] <persia> I can chair.
[20:42] <bdrung> you won ;)
[20:42] <bdrung> [ACTION] persia to be chair in the next meeting
[20:42] <MootBot> ACTION received:  persia to be chair in the next meeting
[20:43] <bdrung> #endmeeting
[20:43] <MootBot> Meeting finished at 14:43.
[20:45] <bdrung> how do i give poolie PPU rights?
[20:45] <persia> bdrung, Add him to ~ubuntu-dev and ask cjwatson nicely
[20:47] <bdrung> cjwatson: can you please give poolie (~mbp) PPU rights?
[20:47] <poolie> thanks, guys
[20:48] <bdrung> poolie: btw, did you check the bzr upload with lintian?
[21:05] <cjwatson> bdrung,poolie: done
[21:06] <poolie> bdrung, do i in general? yes; i'll make a point of doing that