=== Amaranth_ is now known as Amaranth === oubiwann is now known as oubiwann_ === oubiwann is now known as oubiwann_ === oubiwann is now known as oubiwann_ === ogra_ is now known as ogra === ogra is now known as Guest94419 === Guest94419 is now known as ogra_ === rsalveti` is now known as rsalveti === Quintasan_ is now known as Quintasan === ogra_ is now known as ogra === ian_brasil__ is now known as ian_brasil === Ursinha is now known as Ursinha-lunch === oubiwann is now known as oubiwann_ === fader_ is now known as fader === dholbach_ is now known as dholbach === vanhoof[weekend] is now known as vanhoof === Ursinha-lunch is now known as Ursinha === Ursinha is now known as Ursinha-sick === jdstrand_ is now known as jdstrand [16:00] * ara waves [16:00] * skaet looks around [16:00] hi ara [16:01] #startmeeting [16:01] Meeting started at 10:01. The chair is skaet. [16:01] Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE] [16:01] o/ [16:01] hi Daviey [16:02] The priority for today's meeting is to figure out where we are with 10.04.2. [16:02] hi [16:02] hi cjwatson [16:02] cjwatson, pitti - where are we with the 10.04.2 images? [16:02] hello all [16:03] they build fine, and automatically [16:03] skaet - hi [16:03] I just gave an update wrt. proposed vs. updates this morning via email [16:03] hi pitti, victorp [16:03] right, that's the main thing we're waiting for at the moment [16:03] they currently build from -proposed, as we still need to verify some SRUs [16:03] one regression known to me, bug 709694 [16:03] Launchpad bug 709694 in linux-backports-modules-2.6.32 (Ubuntu Lucid) "Lucid package linux-backports-modules-wireless-lucid-generic broken" [Critical,Triaged] https://launchpad.net/bugs/709694 [16:03] in particular, d-i and installing with the maverick kernel [16:04] I believe pitti is handling that [16:04] cjwatson: was tested, copying to -updates nwo === wendar_ is now known as wendar [16:05] pitti, so when will there be an image for ara's team to use? [16:05] I still think we should use the current ones for certification (with -proposed) [16:05] I concur [16:05] ok [16:05] after a quick test from QA that they install at all (in VM should be fine) [16:05] install in normal lucid as well as "maverick backport kernel" modes [16:06] d-i and eglibc are the only potentailly hw specific packages [16:06] and we already cleaned up the questionable ones from -proposed [16:06] 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] -updates would cause every user to upgrade [16:06] ara: well, the point of that is testing, isn't it? [16:07] if we already knew that they don't break anything, then we wouldn't need a cert run [16:07] OTOH, if cert passes with those, we can move everything to -updates and are good to go [16:07] ara: we don't know of any breakage in the current proposed packages, but nobody tested them yet [16:07] jibel, pedro_ ^^ is a test of -proposed as outlined by pitti possible today? [16:08] the reason to be cautious about cert on -proposed would be if there were several things likely to be pulled out [16:08] pitti, the point in running a full cert is to "certify" that they keep working, more than testing if it breaks [16:08] as pitti said, he already removed the questionable proposals, so we're now looking at *unexpected* problems [16:08] ara: ok, then we need "normal" sru testing before [16:08] pitti, we tested it, last week [16:09] 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] ara: oh? didn't see that; was that with the current d-i already? [16:10] pitti, when was that uploaded to -proposed? [16:10] -- Colin Watson Tue, 25 Jan 2011 11:19:31 +0000 [16:10] but it would have needed explicit testing with the maverick boot option, not just "still works as normal" [16:10] cjwatson, we didn't test the maverick boot option, that's for sure [16:12] o/ [16:12] never mind [16:12] o/ [16:12] hi jibel, go ahead [16:13] hi, to answer your question, there are only 2 packages in -proposed that we can really test : base-files and unattended-upgrades [16:13] I don't understand why it isn't possible for QA to test d-i [16:14] jibel: i. e. QA can't do install smoketests? [16:14] yes I can, but at the moment I'm rather low on resources smoketesting A2 [16:14] 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] (i. e. same like for normal alphas, using the iso tracker) [16:14] (you plural) [16:15] perhaps we can also have some community testing on alpha2 [16:15] 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] and I can certainly help testing images as well [16:15] jibel: (^ that's fixed in -proposed, FYI) [16:15] actuall in -updates already, I think [16:16] wasn't that xubuntu-docs anyway? [16:16] no, ubuntu-docs [16:16] ok [16:17] hmm, so we appear to have run smack into the a2 testing crunch we were afraid of. [16:18] jibel, what's your current plan for today? [16:18] skaet, I'm nearly done with A2 smoketest, now syncing DVDs, I can do lucid d-i instead. [16:19] note that the lucid images that need testing in particular for this are DVDs, both amd64 and i386 [16:20] I can do lucid DVD i386 if people don't mind me doing it as the person who wrote the code [16:20] yes. I can sync that now and post the results tomorrow morning. [16:20] jibel, thanks. [16:20] awesome, thanks jibel [16:20] cjwatson, not worried. :) [16:20] skaet, but no smoketest of natty a2 dvd if you agree. [16:21] I think 10.04.2 CDs are more urgent wrt. that [16:21] 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] we'll get more community feedback on natty alphas than for lucid point releases [16:21] pitti, agreed [16:22] 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] o/ [16:23] 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] are the A2 images ready to go to the iso tracker? (so we can get community testing started on those) [16:24] if we get results for the DVD in both modes, d-i can go to -updates [16:24] pitti, ack [16:24] a2> no, I was expecting that to start with tomorrow's autobuilds [16:24] once hw cert passes, eglibc and basic stuff like consolekit can go, too [16:25] so that still means running cert against an image built from -proposed [16:25] I did some smoketesting on the natty dailies last week and yesterday, looks ok so far [16:25] which I'm happy with, but we seemed to be at an impasse on it earlier [16:25] if we don't run cert against -proposed, we can alternatively switch to -updates right after the d-i smoketest [16:25] and we are still running the server dailies on Hudson [16:25] (natty) [16:25] and test the other packages separately, as usual [16:25] I don't agree - that would mean dropping a bunch of stuff out [16:25] I think that would create substantial confusion CD-wise [16:26] the disadvantage is that we'll do a hw cert test against an older version of pacakges [16:26] and the actual 10.04.2 release will be different than what has been tested [16:26] also, the upstart patch is such that it should be on the CD [16:26] that's why I'd much prefer hw cert against the -proposed ones [16:26] but I think if that's a no-go, we could cope [16:26] pitti, anyway, we won't be finishing full cert until late next week [16:28] cjwatson, why building from -updates will mean that the rest will go out? [16:28] cjwatson, are we building only one daily from -updates [16:28] ? [16:29] 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] which would be unfortunate [16:29] if hw cert is testing the current images, then they would be in [16:29] for all intents and purposes, the current dailies are the final 10.04.2 release [16:29] ara: we only build one set of dailies, and they are from -proposed [16:29] unless testing/cert detects regressions [16:29] ara: the effect of switching to -updates is that anyone testing the CDs tests only -updates [16:30] 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] alpha images have nearly always gone to the ISO tracker on Tuesday, in practice. [16:31] skaet, if d-i and eglibc are in -updates, we are happy to test from -proposed [16:32] cjwatson, ack [16:32] o/ [16:32] it's also what https://wiki.ubuntu.com/MilestoneProcess says - "release minus 2 days" [16:34] jibel, go ahead [16:34] re a2, during smoketest I've identified 2 showstoppers on amd64 bug 710582 and bug 710612 . [16:34] Launchpad bug 710582 in ubiquity (Ubuntu Natty) "ubiquity crashes after step 'Who are you' : segfault in libwebkitgtk-1.0.so.0.5.2 on AMD64" [Critical,Confirmed] https://launchpad.net/bugs/710582 [16:34] Launchpad bug 710612 in ubiquity (Ubuntu Natty) "Kubuntu Desktop AMD64 - ubiquity kde_ui crash with File "/usr/lib/python2.7/dist-packages/debconf.py", line 70, in command self.write.flush() IOError: [Errno 32] Broken pipe" [Undecided,New] https://launchpad.net/bugs/710612 [16:35] It would be great if someone could confirm it's not just me. [16:35] (or better that it is just me) [16:36] the second was discussed this morning on #u-devel, I think that's not just you [16:36] (unfortunately I don't remember/have read the outcome) [16:36] it was discussed as a result of jibel mentioning it :-) [16:36] ah [16:36] and that was just me saying "not a debconf bug" [16:37] I couldn't confirm bug 710612 with today's ISO [16:37] Launchpad bug 710612 in ubiquity (Ubuntu Natty) "Kubuntu Desktop AMD64 - ubiquity kde_ui crash with File "/usr/lib/python2.7/dist-packages/debconf.py", line 70, in command self.write.flush() IOError: [Errno 32] Broken pipe" [Undecided,New] https://launchpad.net/bugs/710612 [16:38] jibel, thanks. will work with others then after this meeting to get someone else to confirm 710582 [16:38] I poked ev about jibel's latest reply to 710582 [16:38] skaet, thanks [16:38] cjwatson, thanks [16:38] I don't think it would strongly benefit from other people reproducing it [16:38] unless those other people are able to debug webkit directly [16:38] heh, fair 'nuf [16:39] 710612 is probably a race of some kind :-/ [16:39] :( [16:39] okie, back to 10.04.2 then... [16:39] I expect it depends on how long you take to respond to the parallelised questions [16:40] ? [16:41] * skaet is still jetlagged - parallelised questions isn't parsing [16:41] it's a detail of installer design [16:41] relevant to 710612 [16:41] cjwatson: ubiquity is copying files while the user still creates accounts, sets time zone, etc. [16:41] that happens in parallel since maverick [16:42] * cjwatson thinks pitti meant to direct that to skaet [16:42] oops, yes [16:42] 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] ah, right, sorry [16:43] o/ [16:43] go ara, I think your questions are the ones we need answered now.. [16:44] OK, so I think that if, as pitti says, QA tests d-i, d-i and eglibc can go to -updates [16:44] and we are happy to run cert from -proposed cds once those are in -updates [16:44] pitti, those are the packages that can affect hw, are they? [16:45] ara: right [16:45] but eglibc also needs extra verification [16:45] so a pure smoketest isn't enough for eglibc IMHO [16:45] hm, there is one quirk here [16:46] this only applies to live filesystems [16:46] but live filesystems that are built against -proposed contain -proposed in their sources.list [16:46] 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] I don't think we should release that way [16:47] agreed [16:47] 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] but that shouldn't matter for hw cert, just for final validation? [16:47] (i. e. after rebuilding the CD from -updates only at the end) [16:47] with the exception of server images, which could go ahead [16:47] hence my "if" [16:48] 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] so for hw cert a CD rebuild wouldn't hurt, but it mustn't happen for the latter? [16:49] are folks agreed that cert does not have to be on the very final set of images that we release? [16:49] cjwatson, hw cert is testing the functional equivalent, rather than the final. [16:49] in that case I withdraw my spanner [16:49] heh, that's what was discussed in dallas.. [16:49] cjwatson, yes, the images don't need to be final, but we need everything that affects hw in -updates [16:49] round and round we go. sorry. [16:50] ok, jibel, are you good with the d-i and eglibc testing today? [16:52] skaet, d-i ok, eglibc, I can only install, which doesn't verify anything. [16:53] jibel, thanks [16:53] hggdh should be able to verify https://bugs.launchpad.net/ubuntu/+source/eglibc/+bug/694772 [16:53] cjwatson, what's needed before the eglibc can be moved to updates? [16:53] Ubuntu bug 694772 in Ubuntu Studio "Sudden reboot during server ISO install" [Critical,Confirmed] [16:54] 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] Launchpad bug 702190 in eglibc (Ubuntu Lucid) "__strncmp_ssse3 can segfault when it over-reads its buffer" [Undecided,Fix committed] https://launchpad.net/bugs/702190 [16:54] 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] thanks cjwatson, pitti. ok [16:54] bug 694772 should be verified as part of validation testing, as it happened during iso tests [16:54] Launchpad bug 694772 in Ubuntu Studio "Sudden reboot during server ISO install" [Critical,Confirmed] https://launchpad.net/bugs/694772 [16:55] 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] bug 672177 is the third eglibc bug and should be testable during validation [16:55] Launchpad bug 672177 in upstart (Ubuntu Natty) "libc6 upgrade causes umount to fail on shutdown because init cannot be restarted" [Critical,In progress] https://launchpad.net/bugs/672177 [16:56] 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] hggdh, can you help out on 694772? [16:58] so on the whole I think install + upgrade smoketests should be sufficient for that [16:58] otherwise it could easily be a rabbithole that consumes QA forever [16:58] cjwatson, ok. [16:59] skaet, looking into it [16:59] thanks hggdh. [16:59] jibel: are you ok with cjwatson's proposal? [17:00] skaet, if everybody is ok, I'm fine with his proposal. [17:01] pitti, you ok? [17:01] ack [17:01] ok, that's the plan then. [17:02] we'll carry this conversation over to #u-release [17:02] we're running late now [17:02] any other critical issues to bring up? [17:02] pitti, for 694772 -- is it OK if I install the updates, then reboot into busybox and send in a telinit u? [17:03] as long as it's busybox init ... [17:03] (this may not be entirely trivial to arrange) [17:04] it might be easier to boot the server CD in rescue mode and then use 'telinit u' there [17:04] hggdh: I thought the fix in eglibc was to precisely not to that? [17:04] but none of that validates whether eglibc is doing the right thing in its postinst, of course! [17:04] so actually I don't think that's a valid test [17:04] hum [17:04] yeah, pitti's right too [17:05] darn, indeed :-( [17:05] I'd think the test case for this is "validate that the server iso installs"? [17:05] hggdh's proposal is a way to test upstart in isolation [17:05] but I agree with pitti, I don't think there's much point in lots of detailed messing about here [17:05] the problem is I would need to be in ISO install to test [17:06] note that upstart only adds a breaks to older eglibc versions [17:06] we haven't fixed the upstart part yet anyway [17:06] i. e. testing the the new upstart in isolation won't give us anything for this bug [17:06] any d-i install smoketest by anyone would be sufficient validation for 694772 [17:06] I agree [17:06] ok [17:07] cjwatson, then jibel's test should be enough? [17:07] 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] on that note, probably time to end the meeting. [17:08] thanks cjwatson, pitti, ara, jibel, hggdh, Riddell, ScottK [17:09] #endmeeting [17:09] Meeting finished at 11:09. [17:09] thanks skaet, all! [17:09] thanks everyone *phew* [17:10] 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] skaet, after 2000UTC, when everything is back to normal here, I need to deal with the kids now, see you later. [17:13] jibel, thanks! [18:01] \o [18:01] o/ [18:02] o/ [18:02] yellow [18:03] * sbeattie waves [18:03] shall I run the meeting? [18:04] * mdeslaur pushes jdstrand to front of room [18:04] ok then :) [18:04] #startmeeting [18:04] Meeting started at 12:04. The chair is jdstrand. [18:04] Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE] [18:05] [TOPIC] weekly standup report [18:05] New Topic: weekly standup report [18:05] I've got several things tugging at me at present [18:06] 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] I'm working on the dbus-glib update and the qrt script for dbus bindings [18:07] there is also a lot of various followup work I am trying to catchup on [18:08] that should be it for me [18:08] kees: you're up [18:08] okidoky [18:08] I've got OOo to publish, and kernel to do USNs for [18:09] I'm on triage, and I'm going to try to clean up some of the open security bugs [18:09] 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] that's it, mdeslaur you're up :) [18:09] I'm writing a subversion test script. I should get it published today [18:10] after that, I was to work on the new fuse stuff [18:10] and maybe take a look at exim4 if I have time [18:10] that's it. [18:10] sbeattie: you're next [18:11] I'm on community this week. [18:12] I've got another openjdk update planned this week; amazingly the arm hamsters managed to complete all the builds over the weekend. [18:12] so I'll be testing those today. [18:13] 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] I think that's it for me. [18:13] cool [18:14] [TOPIC] miscellaneous [18:14] New Topic: miscellaneous [18:14] so I have several random things to bring up that have been sitting in tomboy for far too long :) [18:15] first (and speaking of apparmor), we need to have an upstream apparmor meeting [18:15] is that something we can do this week? [18:15] yeah. [18:15] yep [18:15] (to discuss the rally stuff) [18:15] cool [18:15] we can schedule that in #apparmor [18:16] yep [18:16] 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] I'd like to provide summaries of our weekly security meetings somewhere === oubiwann_ is now known as oubiwann [18:17] 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] summary of the stand-up? [18:18] kees: stand-up and anything else. ie, this meeting :) [18:18] jdstrand: our activity reports are way more interesting than our meetings... [18:19] mdeslaur: yes, but other teams do log there meetings (eg, the server team) [18:19] unless we talk about something other than what we have planned for the week [18:19] 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] 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] 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] what do other people think? [18:20] yeah, I'm not against it, I just question the value. if people think there's value, then let's do it. [18:21] well, in a discussion I had it was implied that it should be done, and it isn't [18:21] 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] jjohansen: maybe, but it is an action item I can take [18:22] jdstrand: I wouldn't include the stand up report, but if we discuss anything else it could be worth it [18:22] I don't think it is much work. our meetings are short, the summary even more so [18:23] mdeslaur: well, what if we did this: [18:23] kees is on triage, sbeattie is on community. sbeattie also hopes to work on apparmor 2.5.2 [18:23] ie, don't mention the specific security updates/audits we are working on [18:24] that's fine [18:24] just that 'mdeslaur is working on foo in addition to various security updates) [18:24] s/)/'/ [18:24] I'll come up with some sort of summary, and we can discuss it outside of the meeting [18:25] [ACTION] jdstrand to write up meeting minutes and submit to team for review [18:25] ACTION received: jdstrand to write up meeting minutes and submit to team for review [18:25] perhaps we can table where the will reside based on what we decide should be in them [18:25] s/the will/they will/ [18:26] I also have various items from my rally notes that I think should either be assigned or documented somewhere for todo [18:27] please feel free to add any to this list [18:27] * respin ia32-libs (natty and earlier) [18:27] * add mvo's apt script to qrt [18:27] * kernel capabilities tests [18:27] * kernel keyring tests (LTP?) [18:28] * /etc/apparmor.d/mysqld.d for akonadi (currently assigned to me) [18:28] jdstrand: hm? [18:28] qrt? [18:28] * vm-iso changes to get rid of vm-new stuff [18:28] mvo: hi! not an action item for you [18:28] mvo: we discussed at the rally how we might want to snag your apt tests [18:28] mvo: and somehow incorporate them into qa-regression-testing [18:29] http://people.ubuntu.com/~mvo/apt/auth-test-suit/ [18:29] LINK received: http://people.ubuntu.com/~mvo/apt/auth-test-suit/ [18:29] mvo: and then conceivably run them on a release basis to be sure we are ok [18:29] aha, this one :) [18:29] ta! [18:29] * add ipc to kernel tests [18:30] 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] 't/can't do them right away [18:31] 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] I can put ia32-libs at the end of my to-do list [18:31] what were the details on the caps tests? [18:32] just for qrt? [18:32] kees: yeah-- something in qrt to verify that they work properly [18:32] * kees ponders [18:32] kees: positive and negative tests [18:32] I can take it, but it's not going to be very high priority for a while. [18:32] oh sure [18:32] what sort of tests for caps? [18:33] 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] [ACTION] mdeslaur to take ia32-libs when time allows [18:33] ACTION received: mdeslaur to take ia32-libs when time allows [18:33] 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] \o/ [18:34] hehe [18:34] actually, I should probably take a look at that one, to learn how its done. [18:34] (ia32-libs) [18:34] [ACTION] kees to take kernel capabilities tests when time allows [18:34] mdeslaur: you cool with sbeattie doing that? [18:34] aw, that only works for the chair, unlike urls [18:34] [ACTION] kees to take kernel capabilities tests when time allows [18:34] ACTION received: kees to take kernel capabilities tests when time allows [18:35] I think the apt and keyring ones are pretty big [18:35] (potentially) [18:35] I'll add TODO notes for them, and maybe Roadmap the apt one [18:36] yeah, kernel keyring's had lots of bugs. [18:36] [ACTION] jdstrand to add keyring and apt tests to TODO in the scripts [18:36] jdstrand: sure, I don't care [18:36] ACTION received: jdstrand to add keyring and apt tests to TODO in the scripts [18:36] jdstrand: either way, I won't be doing it :) [18:36] [ACTION] sbeattie to respin ia32-libds [18:36] *snicker* [18:36] ACTION received: sbeattie to respin ia32-libds [18:36] hehe [18:37] sbeattie: I'd focus on natty first, then maybe do earlier releases? [18:37] s'okay, we'll have multiarch before natty releases, and then we won't need ia32-libs! :) [18:37] \o/ [18:37] kees: lol [18:37] slangasek: right? ^^ :) [18:37] can't promise ia32-libs will go away this cycle [18:37] :) [18:37] especially as Yokozar has been adding more packages to it on the other end [18:38] which I'm unhappy about but am not going to meddle with [18:38] heh [18:38] sbeattie: oh, if Yokozar's been doing that, natty may not need the respin anyway [18:38] so no one took the akonadi one. I'll leave it on my todo liest then [18:38] list [18:38] that leaves vm-iso. how important is this? [18:39] jdstrand: I have it on my personal todo list as well, but not sure when I'll get the round tuits. [18:39] jdstrand: what is the vm-iso one? [18:39] (it == mysql-akonadi) [18:39] sbeattie: k. if one of us starts, let's let the other know [18:39] jdstrand: will do. [18:39] [ACTION] mysql/akonadi work coordinated between sbeattie and jdstrand [18:39] ACTION received: mysql/akonadi work coordinated between sbeattie and jdstrand [18:40] oh, I can take the kernel ipc tests for qrt [18:40] (fallout from dbus work) [18:40] [ACTION] jdstrand to add kernel ipc tests to qrt [18:40] ACTION received: jdstrand to add kernel ipc tests to qrt [18:41] 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] 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] (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] kees: fair enough [18:43] kees: I don't think it needs an action or assignment [18:43] right [18:43]