=== jjohansen is now known as jj-afk === doko_ is now known as doko === yofel_ is now known as yofel === Quintasan is now known as Quintasan_ === Quintasan_ is now known as Quintasan === Quintasan is now known as Quintasan_ === Quintasan_ is now known as Quintasan === Quintasan is now known as Quintasan_ === Quintasan_ is now known as Quintasan === coalwater_ is now known as coalwater === czajkows1i is now known as czajkowski === Pendulum_ is now known as Pendulum [12:01] hi everyone. if i'm not mistaken, it's time once again for our bi-weekly udd stakeholders meeting [12:01] #startmeeting [12:01] Meeting started at 07:01. The chair is barry. [12:01] Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE] [12:01] hi barry! [12:01] jelmer: hi! [12:01] hi barry, jelmer [12:01] hi poolie [12:01] do you know if anyone else is joining us today? [12:02] well, anyway, let's get started [12:02] [TOPIC] agenda [12:02] New Topic: agenda [12:02] [LINK] https://wiki.ubuntu.com/DistributedDevelopment/20110713 [12:02] LINK received: https://wiki.ubuntu.com/DistributedDevelopment/20110713 [12:03] [TOPIC] action items [12:03] New Topic: action items [12:03] * jelmer to study the feasibility of merge helper ([[https://bugs.launchpad.net/bzr-builddeb/+bug/608675|bug 608675]]) as an intermediate step for quilt support [12:03] [12:03] Ubuntu bug 608675 in bzr-builddeb "merge-package should have support for manipulating quilt v3 patch stacks" [High,In progress] [12:04] I've been away for the last week so haven't spent any time on this since [12:04] at the last meeting (at the rally) we discussed it, and my conclusions there were that it seems feasible and I've started working on implementing it. [12:05] jelmer: awesome. we'll just keep it on for next time [12:05] that's great [12:05] * jelmer to look into [[https://bugs.launchpad.net/udd/+bug/609187|bug 609187]] (warn when package import is out of date) [12:05] Ubuntu bug 609187 in Ubuntu Distributed Development "users are not warned when branching ubuntu:foo (or lp:ubuntu/foo) and the package import of foo is out of date" [High,Triaged] [12:05] there was some discussion recently of this being useful even for non-quilt branches [12:05] hm [12:05] or, more generally, of being able to merge both the patched and unpatched forms [12:06] jam mentioned on IRC earlier that he's working on bug 609187 [12:06] barry, i think jam and others worked on that [12:06] oh, and maxb in london [12:06] very nice. so, in progress? [12:06] yep [12:06] should perhaps be owned by jam though? [12:07] hi [12:07] jam has taken my proof of concept "How to talk to LP without launchpadlib" and is pursuing it [12:07] sure, i can update that. [12:07] hi maxb [12:07] hi maxb [12:07] maxb: do you just make straight up http calls? [12:08] the point of avoiding lplib is that it's much faster to just make the single call we care about [12:08] yes [12:08] makes sense [12:08] Minimizing roundtrips and costly WADL downloads really matters if we're going to do this interactively [12:08] +1 [12:08] [12:09] * Riddell to file bug saying that packaging branch pages on code.lp.net should be better labeled [12:09] anybody know if the bug has been filed? [12:09] istr that he did [12:09] ... and fixed the bug :) [12:09] and, perhaps he worked on it at the rally [12:09] hooray [12:10] yay! [12:10] do you happen to have the bug #? [12:11] bug 797688 [12:11] Launchpad bug 797688 in Launchpad itself "Ubuntu Packaging Branches Should be Labeled Clearer" [Low,Fix released] https://launchpad.net/bugs/797688 [12:11] thanks (you're quicker at searching than me at this hour :) [12:11] i have kanban fu [12:11] http://people.canonical.com/~mbp/kanban/jr-kanban.html [12:11] LINK received: http://people.canonical.com/~mbp/kanban/jr-kanban.html [12:11] scan down the right hand column until you find it [12:11] ah, nice! [12:12] i like it [12:12] i didn't realize each person had their own kanban [12:13] [TOPIC] package importer progress [12:13] New Topic: package importer progress [12:13] yes, there's one aggregated per team and one per person [12:13] let's see [12:13] i think max said some new things started failing [12:13] There does seem to have been a small uptick in the count [12:13] hm, so it stepped down a bit, but now has drifted up [12:13] Besides the append-revisions-only stuff, which I'm taking account of [12:13] back from 400 to 425? [12:14] some of these are AppendRevisionsOnlyViolation which is a recent regression [12:14] so i'm proposing to make this rather more of a priority for the canonical bzr team [12:14] The append-revisions-only stuff accounts for ~25, but I've fixed about ~20 imports in the last 48 hours, which is why were are back at around 400 [12:14] putting it at the top of our quarterly planning commitments, and trying to get it below 200 by the start of october [12:15] which would be much faster than our current trend [12:15] thanks max [12:15] poolie: that would be amazing [12:15] I've made some progress on support for multiple upstream tarballs, which isn't finished yet but should help a bit too. [12:15] oh, that's great [12:15] One thing is that there seems to be a gradual uptick in the number of packages using multiple upstream tarballs. That's also the top single failure cause at the moment [12:16] Another thing to consider is that quite a number of the failures are failures during the generation of merge preview diffs - *not* the import itself [12:16] A subcategory of those are, I believe, being addressed by a bugfix of vila's [12:17] why does it generate merge preview diffs? [12:17] I'm guessing because james_w thought it would be useful? [12:17] I doubt many people know they exist. [12:17] http://package-import.ubuntu.com/merges/ [12:17] LINK received: http://package-import.ubuntu.com/merges/ [12:18] I started generating them as a test [12:18] hi james [12:18] but never followed it through to be the replacement for merges.ubuntu.com [12:18] hi [12:18] huh [12:18] james_w: hi. i didn't know that existed either [12:18] so, what shall we do [12:19] perhaps we should move it out of line so that it doesn't cause failure of the actual package import? [12:19] I estimate ~44 failures are in the merge generation. They are probably legitimate bzrlib bugs [12:20] I think we should be mindful of that possibility, but see how many of the failures are cleared up by vila's NoFinalPath bugfix before investing time [12:20] that seems to be a fair number of them [12:21] Merges are one of the goals of the UDD branches, so it seems useful to keep it in. [12:21] given no-one is using the output currently it wouldn't really cost anything to delete the code [12:21] or maybe comment it out for now? [12:22] ok, well, now i know it's there :) [12:22] :) [12:22] i agree with max, let's see how it goes with current in progress work landed, and then we can think about pruning it [12:22] or, alternatively, at least linking to ti [12:22] +1 [12:23] so, not really on the agenda, but i see lp and bzr got updated last night? how'd that go? [12:23] it was a bit bumpy [12:23] dang [12:23] but everything worked out? [12:23] since we went several revisions forward, and there were some bad interactions between changes in bzr and in bzr-svn when importing large branches [12:24] we are having a postmortem thread at the moment [12:24] to try to understand what happened [12:24] but i think it will be ok [12:24] cool. i'm on the mlist so i'll follow along [12:24] we will make it safer to deploy and roll back, and then deploy more often [12:24] similar to the approach being taken with other bits of lp [12:25] and speaking of which, can i just say how much i'm looking forward to their new shorter upgrade windows [12:25] (https://lists.launchpad.net/launchpad-dev/msg07623.html but it's a bit offtopic) [12:25] jelmer, can you tell us about what this is likely to change with imports? [12:26] poolie: Can you rephrase that, do you mean the vcs imports? [12:27] yes [12:27] also, what are the top-level user visible changes we'll see in bzr/udd/codehosting now? [12:27] we can hope to see more of them succeed after the lp upgrade? [12:28] poolie: What was the recent lp upgrade from last night barry was referring to exactly? [12:28] there should be a big new feature in lp which is showing diffs inline in the branch pages [12:28] lp had an upgrade outage today (australian time) [12:28] hm [12:28] perhaps we should get our story straight offline :) [12:28] that will be *awesome* [12:28] and then post something on the lp blog about user visible changes, if any [12:29] poolie: +1, can i give you that action? [12:29] actually could i put that on jelmer, since he landed the change iirc [12:30] the inline content feature is http://people.canonical.com/~andrew/Inline-diff-screenshot.png [12:30] not landed yet [12:30] [ACTION] jelmer to post summary of user visible changes with lp rollout [12:30] ACTION received: jelmer to post summary of user visible changes with lp rollout [12:30] I haven't caught up on all that email yet, but I'd be happy to take an action item about the post-morten analysis [12:30] poolie: that specific screenshot is for merge proposal pages [12:30] true [12:30] danilo's change was for Branch pages, which I certainly don't see, but I don't know whether or not his expander code has landed. [12:30] i think the code changes proposed now may only touch mp pages but we should be able to follow through and show stuff on the branch too [12:31] jelmer so i guess there's two things to follow on, one is the postmortem (what went wrong) and the other is the feature announcement, if any (what will go right) [12:31] i had the idea that the updated bzr-git etc are going to help a lot more branch imports complete [12:31] am i confused? [12:32] I haven't landed anything related to the expander code [12:32] I do have a fix for having bzr-svn deal with tags better (not use so much memory), but IIRC I haven't proposed that for landing on lp yet [12:33] didn't you land several updates into lp when we were at the rally? [12:35] perhaps we should move on; this isn't really udd specific [12:35] I have something I'd like people to have a think about: What are we going to do about developer-maintained package branches, which don't use upstream-* tags because they merge directly from upstream's bzr, and thus the UDD importer always fails on currently? I'm thinking of, e.g. apport [12:35] (sorry, looking through the revision log atm..) [12:35] poolie: okay [12:35] [TOPIC] * Get rid of `bzr mark-uploaded` ? [12:35] New Topic: * Get rid of `bzr mark-uploaded` ? [12:35] taking that offline (in the post-mortem thread perhaps?) might indeed be better [12:36] hi, sorry I'm late [12:36] so, if i'm not mistaken, mark-uploaded is more or less unnecessary now, right? [12:37] somewhat; debcommit -r will tag too and "bzr tag" without argument can also behave the same way as mark-uploaded [12:37] hmm, I was hoping to get away from using debcommit [12:37] jelmer: what does mark-uploaded do that bzr tag or debcommit doesn't? [12:38] i guess there are two things leading these questions: whether to change the udd documentation to just use bzr tag, and whether to actually deprecate or get rid of the command? [12:38] barry: I don't think there's anything it does that bzr tag doesn't, other than perhaps being a bit more clearly named [12:39] jelmer: cool. any objections to me changing the udd docs to use tag instead? [12:39] james_w ^? [12:39] Riddell: i'd like to get away from recommending debcommit too [12:39] not really [12:40] i wonder if bzr builddeb could instead hook into the tag command (through adding a hook, not in some gross way) to give people policy checks? [12:40] probably worth a note that if bzr says that they have to give a tag name they need a newer bzr/bzr-builddeb, or their bzr-builddeb is incorrectly installed [12:40] if those checks are seen as useful [12:41] james_w: good idea [12:41] [ACTION] barry to update udd docs to use `bzr tag` instead of `bzr mark-uploaded` [12:41] ACTION received: barry to update udd docs to use `bzr tag` instead of `bzr mark-uploaded` [12:41] barry i suggested Riddell might put his packaging background to use in working on the packaging guide with yourself and daniel [12:42] yes, I'm working my way through it fixing things and working out what's missing or not clear [12:42] great [12:42] Riddell: fantastic. you can add me as a reviewer for any mp [12:42] shall we talk about max's question? [12:42] Riddell: do you want to take the above action instead of me? [12:42] Riddell: Does that include non-UDD packaging? [12:42] barry: yes can do [12:43] hi scott [12:43] [ACTION] Riddell to update udd docs to use `bzr tag` instead of `bzr mark-uploaded` [12:43] ACTION received: Riddell to update udd docs to use `bzr tag` instead of `bzr mark-uploaded` [12:43] poolie: yes, let's take up maxb's question [12:43] I have something I'd like people to have a think about: What are we going to do about developer-maintained package branches, which don't use upstream-* tags because they merge directly from upstream's bzr, and thus the UDD importer always fails on currently? I'm thinking of, e.g. apport [12:43] ScottK: I'd like to discuss that with dholbach, it needs quite a lot of changes to include non-UDD bits and I don't know if he has thought about how to do that (but essentially i'm working on it from a bzr developer perspective so no) [12:44] That's one of the guide's biggest problems at the moment. [12:44] ScottK: but the guide should either be renamed or fixed for that [12:44] Agreed. [12:44] yep [12:44] ScottK: yep [12:44] maxb: It would seem reasonable to just directly tag the upstream versions with upstream-X if they have the same contents [12:46] by detecting there's a revision identical to the orig.tgz? [12:47] either by detecting or having some place where the upstream tag algorithm is specified [12:47] So perhaps the way forward is to discuss with the packagers of those packages how much they are willing to tweak their workflow for UDD compatibility [12:47] can we do something towards recognizing the actual tag in the upstream branch? [12:47] there very likely is one, istm [12:47] right [12:47] bzr-builddeb already has a config variable export-upstream-revision which can be set to the tag pattern for finding upstream versions [12:48] maxb, what kind of tweaks? [12:49] e.g. "export-upstream-revision = tag:bzr-svn-$UPSTREAM_VERSION" as bzr-svn's tagging algorithm uses the tag name "bzr-svn-1.0a" for version "1.0a" [12:50] The proper place to store that sort of information would be in Launchpad's release information I think [12:50] that would be useful in other places [12:50] for instance automatically presenting the releases in the ui and ws [12:50] As in, potentially making use of "bzr merge-upstream", or setting tags manually [12:52] it's getting late, so let's move on [12:52] [TOPIC] bugs of interest [12:52] New Topic: bugs of interest [12:52] [LINK] http://people.canonical.com/~mbp/kanban/canonical-bazaar-kanban.html [12:52] LINK received: http://people.canonical.com/~mbp/kanban/canonical-bazaar-kanban.html [12:52] good idea [12:52] anything in particular to point out? [12:53] i plan to stop the package importer pretending to be james tomorrow [12:53] nice :) [12:53] lots of bugs there [12:53] moving across [12:54] jelmer it looks like you should do a bzr-svn release [12:54] barry, james, maxb, is there anything especially biting you, or that you think especially needs attention? [12:54] barry: [LINK] lp:///~jameinel/bzr/2.2-is-up-to-date [12:54] poolie: I agree; the tags memory usage issue is the main thing that's blocking that at the moment. [12:54] [LINK] lp:///~jameinel/bzr/2.2-is-up-to-date [12:54] LINK received: lp:///~jameinel/bzr/2.2-is-up-to-date [12:55] jam, what is that? [12:55] I just added a "Branch.open" hook [12:55] so that doing "bzr info lp:ubuntu/bzr" tells you if the branch is up-to-date [12:55] oh i see [12:55] great [12:55] poolie: atm, nope. things are going well [12:55] we need to try again with a 2.3.4 sru into natty [12:55] ok [12:55] it's getting late here for sure [12:55] next? [12:56] http://paste.ubuntu.com/643225/ [12:56] LINK received: http://paste.ubuntu.com/643225/ [12:56] [TOPIC] aob [12:56] New Topic: aob [12:56] just one small note: poolie the meeting 2 weeks from now is at the wrong time i think [12:56] barry: I think that goes with the earlier action item (that I missed), for checking if import branches are up-to-date [12:56] yes, it does, that's nice [12:57] jam: thanks [12:57] ok [12:57] jam: that looks great [12:57] so we're going to keep it at the same time as today? [12:57] poolie: if that worked for you guys. it was much better for me ;) [12:58] wfm, poolie is the one most impacted by it [12:58] ok [12:58] thanks everyone for coming, especially maxb [12:58] okay, with that... [12:59] #endmeeting [12:59] Meeting finished at 07:59. [12:59] thanks everyone [12:59] thanks barry :) === Guest60391 is now known as Zic [15:03] hello [15:03] hiya [15:04] ...././.-../.-../--- [15:04] * slangasek waves [15:04] ..-. .. ... .... [15:04] heh [15:05] huzzah! [15:05] #startmeeting [15:05] Meeting started at 10:05. The chair is slangasek. [15:05] Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE] [15:05] [TOPIC] lightning round [15:05] New Topic: lightning round [15:05] $ echo $(shuf -e cjwatson barry doko csurbhi stgraber jhunt mvo ev vorlon bdmurray) [15:05] and... go [15:05] bdmurray ev jhunt barry csurbhi stgraber cjwatson vorlon doko mvo [15:05] bdmurray: [15:05] last again! [15:05] bug work [15:05] bug triage of ubiquity bug reports with SQUASHFS errors, fsys-tarfile-error apport package bug report cleanup, incompletion of ubiquity install failures due to oom, FTBFS bug report modifications, added bug reporting guidelines for ubuntu-meta, crichton function to deal with package-install-segfault bug reports, wrote a bug pattern for update-initramfs failures on Live Media and wrote a wiki page to point people at [15:06] community stuff/work [15:06] review and approval of 2 new Ubuntu Bug Control members, added in iso-testing bug reports to the package status pages, udw class prep and presentation regarding working with apport bugs [15:06] o/ [15:06] development work [15:06] update-manager apport hook SRU update and new merge proposal for oneiric, branch adding casper version to apport bug reports from live media, updated ubiquity apport package hook to ask permission before adding debug log and block SQUASHFS error bug reports, patch pilot day (fixed pm-utils failed to inhibit suspend bug, 665651 which revealed a bug in toshset which caused suspend to fail), bzr branch for unattended-upgrades and messag [15:06] * slangasek waves to psurbhi [15:06] \o/ for u-m [15:06] done [15:08] - More fighting over desk space. Now resolved! I'm officially a Millbank-based [15:08] employee from here on out. Yay. [15:08] - integrating Wubi builds into cdimage. Should be working just as soon as [15:08] LP: #807974 gets fixed. [15:08] - Further work on the IronPython Wubi test. I now have an executable bundle [15:08] that displays a WebKit view (of the people.ubuntu.com slideshow). [15:08] It's 8,751 KB, but I think I can further trim that down some. It's roughly: [15:08] 7-zip's SFX header, a small configuration file, and an LZMA archive [15:08] concatenated together. In the LZMA archive is the IronPython DLLs (3.32 [15:08] MB), the Chromium Embedded Framework DLLs (25.7 MB), CefSharp DLLs (293 KB), [15:08] and the application bytecode (.NET) and libraries (12.6 KB). I'm going to [15:08] stick an address bar on this and deliver it to The Team to use for Wubi [15:08] slideshow development. [15:08] - Looking into writing a small C++ wrapper around the front of our .NET [15:08] application to download and install the .NET 2.5 runtime when it's not [15:08] present on the system, rather than just letting Windows throw up an obtuse [15:08] error dialog. [15:08] - Trying to target an IronPython build for .NET 2/3.5. [15:08] - Developer Experience Community of Practice call. [15:08] - Stuck recovering my work from home laptop using the black magic of grub2's [15:08] loop mounting code (hooray for having a spare ISO lying around in /home). [15:08] Any thoughts on writing a copy of the installation ISO to the filesystem [15:08] during installation and wiring it into grub such that if everything goes to [15:08] hell, the user has something to boot into. Or should we do the ChromiumOS [15:08] A and B boot branch thing instead? [15:09] - Finished the PyGI port of SegmentedBar and nearly done with the timezone [15:09] map. Ran headfirst into GdkPixbuf.get_pixels() being hideously broken in [15:09] PyGI, blocking the finishing of the timezone port. Spent a lot of time [15:09] digging through the PyGI source looking for the best way to solve this in [15:09] this brave new world, proposed an approach to tomeu, and may have a solution [15:09] soon. [15:09] - Helped the web team again with the Launchpad API, further modifying the [15:09] script I wrote for them to generate reports of what bugs they fixed to work [15:09] with date ranges. [15:09] - Call with Steve on the plan for Wubi, and the hiring of a Windows developer. [15:09] - Chat with Francis on our plans for the crash database. He's going to circle [15:09] back with Rob and then presumably continue the discussion on the existing [15:09] mail thread. [15:09] - Started writing unit tests for gtkwidgets in ubiquity and a harness that [15:09] plays nice with the GTK main loop and the weird fact that PyGI raises [15:09] exceptions in a different thread of execution, thus they don't bubble up [15:09] around Gtk.main. I know, awesome, right? [15:09] - Had to do some running around and paperwork for signing up to Canonical's [15:09] implementation of the cycle to work scheme. [15:09] - More work on the wireless page for ubiquity. Implemented passphrase [15:09] handling. [15:09] bdmurray: I think your line truncated; "unattended-upgrades and messag[...]" [15:09] TODO: [15:09] - Objectives. Eep. [15:09] - Get hardware expensed for ubiquity testing in the datacenter. [15:09] (done) [15:09] ev: how much are charged for the desk? ;p [15:10] "bzr branch for unattended-upgrades and messages during shutdown, apt branch blocking of fsys tarfile error package install failures" [15:10] Raised MP to revert dokos gcc+armel change for libnih. Worked with [15:10] hallyn to find a resolution for bug 495394. Reviewed marrusl's [15:10] material for UDw. Some progress on Upstart disabling jobs feature. [15:10] Reviewed documentation changes for psurbhi's Upstart initramfs branch. [15:10] Worked through initramfs setup steps for Upstart and discussed with [15:10] Launchpad bug 495394 in libvirt (Ubuntu Natty) "autostart almost always fails on boot time host" [Undecided,Fix committed] https://launchpad.net/bugs/495394 [15:10] psurbhi. Started to look at bug 436936 (again). Made some good [15:10] Launchpad bug 436936 in gdm (Ubuntu Natty) "gdm upstart job checks /proc/cmdline for single user mode, won't start on post-boot runlevel change" [Medium,Triaged] https://launchpad.net/bugs/436936 [15:10] progress but then switched to bug 807293 which I am currently looking [15:10] Launchpad bug 807293 in upstart "user jobs cause kernel panic" [High,Confirmed] https://launchpad.net/bugs/807293 [15:10] at. [15:10] ./-./-.. [15:10] doko: I think you pay cvd in endless thank yous and one appears [15:10] rebuilding main dev machine (still need to restore pbuilder/sbuild/vms) - been filing bugs like mad; bug 806661 (python-imaging needs to be multiarch aware); bug 806744 (lazr.smtptest testing); looked at bug 212370 (coretemp kernel module) but need to come back to it; pep382 lively discussion on mlist and code reviews; patch pilot (see ubuntu-devel@); developer experience CoP; lead UDW session on dh_python2; UDD stakeholders meeting; [15:10] this week: work on lts ppa, continue on bug 788514; done. [15:10] [15:10] Launchpad bug 806661 in python-imaging (Ubuntu) "[oneiric] python-imaging needs to be multiarch-aware" [Medium,Fix released] https://launchpad.net/bugs/806661 [15:10] Launchpad bug 806744 in Launchpad itself "lazr.smtptest increases fragility of Launchpad appserver layer tests" [High,Fix released] https://launchpad.net/bugs/806744 [15:10] Launchpad bug 212370 in linux (Ubuntu) "Have to modprobe coretemp manually in order to get CPU temperatures on MacBook Pro" [Medium,Confirmed] https://launchpad.net/bugs/212370 [15:10] Launchpad bug 788514 in Ubuntu Oneiric "python packages on the CDs not using dh_python2" [Medium,Confirmed] https://launchpad.net/bugs/788514 [15:13] barry: sorry I missed the UDD stakeholders meeting yet again; it's creeping towards the time of day that I can make it, but I had an 11pm call last night so 5am was going to be a little rough :) [15:13] psurbhi: your turn [15:13] slangasek: no worries ;) [15:13] *) working on making a ppa of initramfs, upstart and mountall - testing the install scripts, updated mkinitramfs and update-initramfs. [15:13] *) done. [15:14] and learning about the evils of NSS in initramfses... [15:14] stgraber is on vacation this week [15:14] :) yeah ! [15:14] cjwatson: [15:15] * stgraber waves [15:15] and gets back to doing non Ubuntu stuff :) [15:15] hah, yeah, I remember discovering the fun of NSS in reduced systems when doing openssh-server-udeb a while back [15:15] Spent most of this week so far working on Launchpad, with mvo's help from the apt/python-apt side: [15:15] * My dpkg-xz-support branch from last year will be ready to go once apt and python-apt SRUs land in lucid-updates. [15:15] * My multiarch-translations branch probably still needs a bit more code review, but it's had a DB review and I believe the necessary apt change is due to go in as an SRU. Unfortunately, I think the Launchpad downtime schedule is such that this may not actually land in production until a day or two after feature freeze. Perhaps we should go ahead with the installer change to activate multiarch anyway, since the ... [15:15] ... Launchpad work is "only" a bandwidth reduction exercise? [15:15] * Good news: it only took about half a day to set up a Launchpad development VM, and most of that was waiting for downloads. It's not as hard as I remember it being. [15:16] Working on mountall for /run transition, with Steve. Will review Surbhi's stop-timer branch again once that transition is unstuck. [15:16] Kicked off preliminary CD building for 10.04.3. [15:16] Working on apt-setup error handling in the case of a non-downloadable local repository key (bug 728710). [15:16] Launchpad bug 728710 in apt-setup (Ubuntu) "d-i apt-setup/local0/repository not working" [Medium,Triaged] https://launchpad.net/bugs/728710 [15:16] Launchpad branch to add Lubuntu tasks has landed, so I'll be working on getting Lubuntu CDs going once we can debootstrap again. [15:16] Almost done with home plumbing problems saga of doom, at long last \o/ [15:16] -- [15:16] cjwatson, thanks ! [15:16] i am waiting for the mountall review ! [15:16] :) [15:16] sorry that's taken so long :-/ [15:16] activate multiarch anyway> that seems fair to do now and give a bandwidth hit since it only affects those using the dev release [15:16] np [15:16] as long as we're confident we'll have it really really fixed by beta :) [15:17] yeah, the branch is not that painful [15:17] although I don't actually have figures for how much it cuts [15:17] I should work on that [15:17] OK then, I'll pull the switch in the installer if I can say you told me to do it :-) [15:18] what could possible go wrong? [15:18] * slangasek gets the asbestos longjohns out of storage [15:18] you had them in storage? [15:18] global warming [15:18] you've been away from platform too long [15:18] heh [15:18] my turn [15:18] this week has pretty much been eaten up with bug #807974, development-wise [15:18] Launchpad bug 807974 in eglibc (Ubuntu Oneiric) "debootstrap fails to install libc6 installing oneiric from natty" [Critical,Triaged] https://launchpad.net/bugs/807974 [15:19] started my long heart-to-heart with the initscripts merge on Friday... been working on it since [15:19] should actually be in a position to upload initscripts+mountall later today [15:19] if someone were to have a look at debianutils and see whether we should merge it from unstable, that would knock one prereq off my list [15:20] I can do that [15:20]