[04:36] <hyperair> could a core-dev please sponsor Bug #976120
[04:55] <umang> Hi, on the beta 2 release notes, it says "Both of these reduces power consumption and thus battery lifetime." It sounds as though they should say "Both of these reduce power consumption and thus increase battery lifetime." (or just life).
[04:55] <umang> https://wiki.ubuntu.com/PrecisePangolin/TechnicalOverview/Beta2
[04:56] <umang> I can't make changes, but I hope someone in this room can.
[05:05] <pitti> Good morning
[05:06] <ajmitch> hi pitti
[06:35] <dholbach> good morning
[06:43] <dholbach> can somebody of the kernel team have a look at bug 975392?
[08:06] <jibel> slangasek, there's a regression with msttcorefonts and the package downloader introduced in update-notifier bug 977812
[08:40] <soren> win 37
[08:40] <soren> doh
[09:11] <dholbach> tumbleweed, heya - I just read the log of the DMB meeting - are you going to process the applications by mail now?
[09:12] <tumbleweed> we have always been able to. Although we haven't done any since I joined. Apparently it never worked very well
[09:12] <tumbleweed> people don't reply with votes, or something like that
[09:12] <henrix> pitti: hi! not sure if you're the right person to contact about this... just received an email w/ subject "linux-lts-backport-natty_2.6.38-0~12~oneiric1_source.changes rejected"
[09:13] <henrix> pitti: it states that File linux-lts-backport-natty_2.6.38-14.58~lucid1.tar.gz already exists in PPA for Cycklon, but uploaded version has different contents.
[09:13] <pitti> "Cycklon"?
[09:13] <pitti> henrix: sounds like a LP regression then; different PPAs ought to be able to have different origs
[09:13] <henrix> well, that's what it says
[09:14] <henrix> so, shall i just send an email to launchpad-users@lists.launchpad.net?
[09:14] <dholbach> tumbleweed, hum, it just wasn't quite clear to me what's going to happen with the applications of yesterday
[09:15] <Laney> we should email them to do it next time
[09:20] <tumbleweed> dholbach: the applicant wasn't present, and there wasn't quorum. But yes, we should probably mail the applicant and mention that we rescheduled him
[09:22] <dholbach> ivoks, you might want to add your application as well :-)
[09:22] <dholbach> tumbleweed, alrightie
[09:22] <dholbach> thanks a bunch
[09:22] <sabdfl> pitti, rickspencer3 sent me scrollback on your upgrade testing
[09:22] <sabdfl> superb!
[09:22] <pitti> sabdfl: thanks!
[09:23] <pitti> sabdfl: that's the first release ever where we got that right
[09:23]  * pitti bounces
[09:24] <ivoks> dholbach: :)
[09:25] <rickspencer3> jibel, ^ very nice contribution from the QA team :)
[09:27] <jibel> rickspencer3, thanks  \o/
[09:29]  * pitti hugs jibel
[09:29] <pitti> we could never have come that far without you and all that jenkins work
[09:31]  * jibel hugs back pitti 
[09:35] <seb128> http://pastebin.ubuntu.com/923047/ (retracers bugs with >=3 dups sorted by count of duplicates since the start of april)
[09:35] <seb128> (just for info if some are interested)
[09:40] <pitti> ah, thanks; I see an udisks bug there whic is already fixed
[09:45] <seb128> pitti, yeah, I don't filter out closed bugs, most of the top bugs have been fixed already
[09:46] <pitti> no, I mean it was an unclosed duplicate, I duped it now
[09:48] <infinity> seb128: Interesting report.  I can't speak for most upstreams, but I wonder if there might be value in snagging all the telepathy-*/mission-control bugs and bundling up the list for an email to the telepathy list.
[09:48] <infinity> seb128: (Not that I checked bug statuses, maybe they're all fixed already)
[09:49] <seb128> infinity, yeah, I will mention it to kenvandine ;-)
[09:49] <infinity> pitti: And congrats on the upgrade testing success!  Does this mean I have nothing to do this month? ;)
[09:50] <pitti> infinity: there are still some conffile questions, and http://people.canonical.com/~ubuntu-archive/nbs.html :)
[09:50] <infinity> pitti: (I know :P)
[09:50] <infinity> pitti: I'm pretty sure I'll keep myself more than busy from now until release.
[09:51] <infinity> And then drown myself in gin the night after...
[09:51] <pitti> heh, sounds like a plan! although I'd prefer Vodka
[09:53] <infinity> seb128: Oh, speaking of desktop things, do we have someone working on libical?
[09:53] <infinity> It's making outdate.txt a sad Panda.
[09:53] <seb128> doh
[09:54] <seb128> infinity, it's supposed to be me, I keep hopping that Debian would fix the bug since they have it too but no dime :p
[09:54] <infinity> A man can dream.
[09:54] <infinity> As long as it doesn't fall off your radar, I'll pester occasionally. ;)
[09:56] <seb128> infinity, thanks for the reminder
[12:29] <smoser> just going to rhtrow htis out htere and ask if anyone knows.
[12:30] <smoser> i have an ext4 filesystem in a file image (mkfs.ext4 -F foo.img).  It has some files in it.  is there a way to essentially "trim" the image ?
[12:30] <smoser> i've done mount -o loop, dd if=/dev/zero of=/mnt/file.img, rm /mnt/file.img, umount /mnt
[12:30] <smoser> and that largely works.
[12:30] <smoser> but reading 'e2image' i got the impression it could do it, but i think i'm wrong.
[12:31] <smoser> (a copy rather than in-place update would be acceptable here)
[12:31] <soren> smoser: Yeah, there is.
[12:31] <soren> smoser: Let me see if I can remember where it is..
[12:32] <soren> smoser: http://bazaar.launchpad.net/~ubuntu-core-dev/livecd-rootfs/trunk/view/head:/e2fs-zero.py
[12:34] <smoser> soren, thanks.
[12:34] <soren> smoser: It always gave me the heeby jeebies.
[12:35] <smoser> well, yeah.
[12:35] <smoser> dd if=/dev/zero seems less prone to error :)
[12:35] <soren> smoser: Which is why I never integrated it into vmbuilder.
[12:35] <smoser> but in my case, and yours, data loss is not really a big deal.
[12:35] <soren> ..and instead built the fs outside the image and then copied everything into the image.
[12:36] <soren> smoser: WEll...
[12:36] <soren> smoser: The problem is that any data loss isn't obvious.
[12:36] <soren> It might not reveal itself until much later and will be extremely hard to debug.
[12:36] <smoser> true.
[12:37] <smoser> i would think that e2fs upstream would probably take an e2image patch that also copied data.
[12:37] <soren> ...and back when vmbuilder has the new hawtness, the state of the art was still to use VM's much like real machines: Long-lived, persistent resources.
[12:40] <smoser> http://patchwork.ozlabs.org/patch/142316/
[12:45] <smoser> well, fun...
[12:46] <smoser>  http://e2fsprogs.sourceforge.net/e2fsprogs-release.html#1.42.2 seems to imply that we should probably sync e2fsprogs from debian.
[12:59] <smoser> anyone want to look at bug 978012 ?
[13:27] <cjwatson> mvo: can you think of any reason why bug 922949 might not be an apt bug?  all ubiquity is doing here is running 'apt-get -d -y --force-yes -q -o Dir::Cache=/target/var/cache/apt upgrade'
[13:28] <cjwatson> mvo: I suppose I could explicitly go through and check all the checksums, but it seems as though apt ought to have done that already
[13:46] <smoser> slangasek, you're last touched on e2fsprogs, do you have thoughts on bug 978012 ? basically, i'm weary of doing a merge that this point, but the debian maintainer seems like he knows a thing or two about ext filesystems.
[13:50] <mvo> cjwatson: let me check that one
[13:51] <mvo> cjwatson: right, apt should do this - its doing this when getting the data from the network into memory, but after it has written the file it does not do another verification of the resulting deb, maybe this is what should be done too
[13:52] <cjwatson> mvo: you mean checking that it's been written to disk correctly?
[13:52] <mvo> cjwatson: yes, exactly
[13:52] <cjwatson> it's just odd that we're seeing this disproportionately (I think?) during installation
[13:52] <cjwatson> it seems to be doing something more or less plausible when I just run locally with a test proxy that corrupts stuff on the way through
[13:53] <mvo> cjwatson: not sure, there are a bunch of bugs for apt itself that have similar symptoms - or is this sometihng that started recently in the installer?
[13:53] <cjwatson> I don't think it's particularly recent
[13:53] <mvo> cjwatson: the way its currently working is that there the  hashsum is updated for each bit of data that comes in, but its not checking the final written file
[13:56] <cjwatson> wait, it *might* be something else, this isn't actually the "download updates during install" bit now that I look at it more closely
[13:56] <cjwatson> it's langpack installation
[13:57] <cjwatson> ubiquity installs its own acquireprogress/installprogress implementations there, so it's possible this is ubiquity's fault for omitting some crucial piece of error handling
[13:59] <cjwatson> or that python-apt is missing something
[13:59] <mvo> cjwatson: ohhh, thats interessting!
[14:00] <barry> ScottK: need any help on LP: #879405 ?
[14:00] <barry> bug 879405
[14:01] <barry> or maybe pitti ^^
[14:06] <mvo> cjwatson: keep me updated if you find out more please
[14:07] <cjwatson> mvo: will do, still investigating
[14:09] <pitti> barry: no, I already uploaded it to Debian
[14:10] <pitti> barry: I just need a review/ack from a fellow release team member
[14:10] <barry> pitti: cool.  that'll help my list for q :)
[14:10] <msvb> Hello Chris aka Mr. cjohnston, you wrote me today that you can't find me on Launchpad.
[14:11] <msvb> …but it seems you're not here either. Maybe out to lunch.
[14:11] <msvb> Depending on the timezone. No idea.
[14:11]  * ogra_ seriously wonders about all these locale warnings inside chroots recently 
[14:11] <cjohnston> msvb: Michael?
[14:11] <msvb> Aha, you are there. Yes, Michael.
[14:11] <cjohnston> :-)
[14:12] <msvb> Hope you liked my wild guess of writing ideas in the whiteboard. No idea if I committed a giant faux pas with that.
[14:12] <ogra_> something weems to have changed that always gets me warnings for LANGUAGE, LC_CTYPE, LC_COLLATE and LC_MESSAGES being set to en_US.UTF-8 ... even though LANG=C was used
[14:12] <cjohnston> Ok.. So I spoke with Jono... I don't believe that that blueprint/meeting is the correct place to discuss those topics as that blueprint is more on the actual code and development on Summit.. We do both agree though that there should possibly be a meeting to discuss your points, and others.
[14:13] <msvb> Should I start a new general topic on the issue of welcome strategy or something like that?
[14:13] <msvb> Is there already a existing topic about these things that you know of?
[14:13] <cjohnston> That would work..
[14:14] <cjohnston> Not that I know of.. its still quite early in the planning process
[14:14] <msvb> I think there's only 15 so far, so as long as I'm not looking in the wrong place then I'll go to it.
[14:14] <msvb> I must say that I've proposed four track meetings already and this will be the fifth.
[14:14] <cjohnston> I don't see any in Summit either
[14:14] <cjohnston> msvb: This one should be against community.
[14:15] <msvb> Yes, I agree.
[14:15] <cjwatson> mvo: can't seem to reproduce it here, though - I get FetchFailedException when I run the relevant bits of code manually against a broken proxy
[14:16] <msvb> Can you tell me if I should use the 'propose meeting' link on the summit.ubuntu.com website or create a new blueprint with sprint or not with sprint and with an attached schedule, or should I do both a blueprint and a meeting proposal?
[14:16] <cjwatson> ogra_: LANG is overridden by other LC_*/LANGUAGE environment variables
[14:16] <ogra_> is that new ?
[14:16] <cjwatson> no, it's been that way for as long as I can remember
[14:16] <cjwatson> set LC_ALL=C if you want a big-hammer override
[14:16] <ogra_> i definitely didnt have these errors in the past for LANG=C chroot foo-chroot
[14:17] <cjohnston> One or the other.. The Propose a Meeting in summit is brand new.. to give the option of moving away from creating a blueprint just to create a meeting
[14:17] <ogra_> now i get them everywhere
[14:17] <cjwatson> something may have changed, but it wasn't the environment variable precedence order :)
[14:17] <doko> pitti: could you approve icedtea-web as well?
[14:19] <RainCT> didrocks: Hey. Just uploaded Zeitgeist 0.9 to Debian unstable :)
[14:19] <didrocks> RainCT: awesome, thanks \o/
[14:20] <mvo> cjwatson: that is consistent with what I saw a while ago when looking at this, I was using a fault-injection proxy and got the expected hashsum errors
[15:01] <cjwatson> mvo: the only thing I can think of so far is an error somewhere in the complicated circular buffer code in the http method
[15:01] <cjwatson> but I don't actually have anything definite to show
[15:02] <cjwatson> if it has something to do with slow writes to disk, though, that might explain why we're seeing this during installation when there's lots of stuff going on
[15:03] <cjwatson> mvo: does anything check errors from close()?
[15:03] <cjwatson> mvo: (I'm getting increasingly tempted to work around this by an explicit check in ubiquity, despite what I just said in the bug)
[15:09] <mvo> cjwatson: close is checked, but it looks like there might be a explicit close missing, let me look at the code some more
[15:11] <mvo> cjwatson: no, thats not it, its there via explicit destruction
[15:11] <cjwatson> mm, but what happens if it fails?
[15:12] <cjwatson> I don't have much evidence that this is actually the problem, though, I'm just guessing
[15:16] <mvo> it will set the internal _error->Error() state and return, this should be transported back to the parent of the http class, but it might be that this is not working, http://paste.ubuntu.com/923431/ may be worthwhile, let me dig some more
[15:17] <cjwatson> mm, possibly
[15:36] <mvo> @pilot in
[15:52]  * dholbach hugs mvo
[15:56]  * mvo hugs dholbach
[15:56] <dholbach> :)
[16:00] <cjwatson> mvo: there doesn't seem to be much in python-apt that would make it sane for ubiquity to do its own validation, even :(
[16:00] <cjwatson> for instance, it doesn't look like there's a way to ask whether a package has already been downloaded to .../archives/ and if so what its filename is
[16:14] <RainCT> didrocks: Why does bug #962265 have a Zeitgeist task?
[16:15] <didrocks> RainCT: just to track it, the -datahub change is dependeing on the new zg from what mhr3 told dme
[16:15] <RainCT> didrocks: I don't even see anything file related in the bug description/comments
[16:16] <didrocks> RainCT: ping him, but he ensured me that if I uploaded -datahub with our incoming distro patch without the new zg, there will be no more event logged
[17:09] <jkakar> Hi!  Updates from yesterday totally hosed my mouse and wireless on my Thinkpad T61... I ended up reinstalling Beta 2 from scratch (was previously running an upgrade from 11.10).
[17:09] <jkakar> I poked about Launchpad, but didn't find any related bugs... does anyone know if these issues were reported/have been fixed?
[17:37] <rbasak> cyphermox: around? Could you please look at bug 956843? I've attached a debdiff. I think it's a candidate for precise, since evolution calendar is fundamentally broken without this workaround, and will cause evolution to randomly crash when using the calendar.
[17:38] <cyphermox> rbasak: oh, I thought we had just fixed that
[17:38] <rbasak> cyphermox: I'm not aware of anything. Is there another bug?
[17:39] <cyphermox> I once dreamed of seeing a workaround for this in evo which I would have cherry-picked
[17:39] <cyphermox> I'll take a look :)
[17:39] <rbasak> Upstream didn't seem to be aware of this issue when I asked. There is another workaround that is present, but it doesn't work for an edge case which I am hitting.
[17:39] <cyphermox> fwiw, evo calendar doesn't really crash for me though
[17:39] <cyphermox> ok
[17:39] <rbasak> It depends on what timezones you're using in your calendar
[17:39] <cyphermox> well, it's definitely worth patching the issue anyway
[17:39] <rbasak> It crashes for me every time without my workaround
[17:40] <rbasak> It's a fundamental issue with memory management in the libical API. My patch is just (yet another) workaround to make an array big enough to start with that it doesn't need to be extended (because if it does get extended then it starts corrupting the heap).
[17:40] <rbasak> Thanks for looking!
[17:43] <cyphermox> ah, I see. we seem to have the workaround for evo but maybe it doesn't catch all the cases
[17:44] <cyphermox> rbasak: patch looks reasonable to me too and it's acked by upstream, I'll sponsor it in a minute
[17:44] <rbasak> cyphermox: great, thanks!
[18:07] <cjwatson> james_w,maxb,vila: I have a UDD branch (openssl) affected by bug 714622, but where I'm actively making use of the ability to merge from the Debian branch.  Just how much does requeue_package.py --full delete?  Would it rewrite history in either the Debian or the Ubuntu branch?
[18:07]  * maxb tries to remember
[18:09] <maxb> --full means to delete the importer's memorization of where the tags should point in the various branches
[18:09] <maxb> I don't recall exactly how it behaves, though, for existing branches when it has no memos
[18:10]  * maxb tries a --zap-revids=precise instead
[18:11] <maxb> or would, if the importer wasn't holding a lock on the db
[18:11] <maxb> james_w: The timeout thing hasn't completely fixed matters - I think the storm refactor is leading to the importer holding open a transaction for far too long at some point
[18:13] <maxb>  And I think that thing must be the driver (at least in part, since it's still locked up, and only the driver is currently running
[18:13] <maxb> SIGTERMing the driver
[18:14] <cyphermox> rbasak: what do you do to make evo crash in ical the most?
[18:15] <rbasak> cyphermox: I just start evolution. I think it's the contents of my calendar. Something to do with events that use timezones I think. Possibly timezones that don't exist in libical's builtin_timezones array by default. Not sure what timezone that might be.
[18:16] <cyphermox> d'oh
[18:17] <rbasak> cyphermox: the problem is heap corruption. The crash may or may not happen. My crashes tend to happen in GUI rendering, so people might just not notice when it corrupts rendering but doesn't actually crash for them. Actually I'd been seeing rendering problems for a while - perhaps that had the same root cause too
[18:17] <cyphermox> rbasak: I was just curious if there was an easy way to reproduce it so I could test it here
[18:18] <rbasak> cyphermox: I understand. Sorry, I'm not aware of one. You might try running it under valgrind - that will detect the problem even if it doesn't cause the crash. The valgrind warning I've got in the bug report should go away when the problem is fixed (or worked around)
[18:18] <cyphermox> rbasak: all good -- sponsored.
[18:18] <rbasak> cyphermox: thanks!
[18:19] <rbasak> (OTOH, you might not see the valgrind warning because that only happens when evolution steps on the heap that libical freed, which might not happen in your case!)
[18:19] <rbasak> This is one of _those_ bugs :-)
[18:26] <james_w> maxb, that's pretty much the same conclusion that I have come to
[18:26] <james_w> I don't have any ideas about where that transaction may be yet though
[18:26] <maxb> james_w: When it is in the process of breaking, you can see a meta.db-journal file present on disk
[18:27] <maxb> though, so much is in meta.db, that that does not narrow it down much
[18:31] <cjwatson> maxb: not to rush you or anything, but roughly how long should I expect to wait for lp:debian/sid/openssl to come up to date now that you've stabbed it (i.e. when should I check again)?
[18:32] <maxb> ugh, it's died again
[18:32] <maxb> TypeError: tuple indices must be integers, not str !
[18:32]  * maxb looks into that
[18:32] <maxb> I will ping you here with a conclusion
[18:36] <maxb> hmm. looks like --zap-revids=precise... didn't
[18:40] <maxb> james_w: Hmm, how plausible does it sound that requeue-package is missing a commit after the storm refactor, so that the effects of --full or --zap-revids get rolled back, not applied?
[18:42] <maxb> Also does anyone know why jubany doesn't let me forward a ssh key to it?
[18:43] <james_w> maxb, canonical DC machines disallow that globally I believe
[18:43] <james_w> maxb, commit> possible, but my first suspicion would be a unicode issue that means that it is acting on 0 rows instead
[18:43] <maxb> That is unhelpful when you want to push local changes to a bzr branch
[18:44] <james_w> maxb, I bet I missed a unicode() for the argument of --zap-revids
[18:44] <james_w> but if --full doesn't work either then it may be something different
[18:44] <maxb> I admit I didn't test --full
[18:44] <maxb> that was just inference
[18:45] <maxb> cjwatson: The problem has been overcome and an import is now running
[18:47] <cjwatson> maxb: cool
[19:39] <gotwig> hey
[19:42] <maxb> cjwatson: openssl import complete
[19:44] <cjwatson> maxb: brilliant, thanks
[20:34] <ScottK> barry: Looks to me like tumbleweed took care of you.
[20:34] <barry> ScottK: yep
[20:36]  * tumbleweed likes easy FFes
[20:47]  * highvoltage is glad that tumbleweed is on the release team
[20:47] <highvoltage> (not that I've had any FFes this cycle)
[20:47]  * highvoltage is tempted to add a "(yet)"
[20:48] <ajmitch> highvoltage: there's still time
[20:49] <tumbleweed> :)
[20:51] <ajmitch> highvoltage: also time to upload fixes, especially for universe :)
[20:52] <rbasak> cyphermox: hmm, libical FTBFS on amd64, although I had tested it with sbuild. I'll compare the build logs
[20:53] <cyphermox> ugh
[20:53] <cyphermox> I also ran it here on amd64 successfully
[20:55] <highvoltage> ajmitch: *nod*
[20:55] <cyphermox> rbasak: if you can figure out what is going on there, I'll keep diving into the armel failure.
[20:55] <rbasak> It used -j8
[20:56] <rbasak> I wonder if the build system breaks with that and it'll work with -j1
[20:57] <cyphermox> arf
[20:57] <rbasak> cyphermox: it's 2200 here, I'll look at it in the morning. I can look at armel too seeing as I have arm boards for this kind of purpose anyway - do you want to pass on how far you got for me to pick up in the morning, or would you prefer to look at it yourself?
[20:57] <cyphermox> rbasak: I'll give it a shot, then email you with how far I got.
[20:58] <rbasak> cyphermox: ok great - I'll sync with you tomorrow
[20:58] <cyphermox> alright
[21:13] <bdmurray> slangasek: do you have any thoughts on the update-manager task in bug 863509?
[21:19] <slangasek> bdmurray: not something we should commit to
[21:20] <bdmurray> slangasek: okay
[21:23] <bdmurray> slangasek: I also found bug 978124 which seems similar to bug 923220
[21:36] <slangasek> bdmurray: that's caused by glib2.0 being out of sync across architectures today
[21:36] <slangasek> ("Rompe on" - ugh, why is half of apt.log translated)
[21:39] <cjwatson> slangasek: bah, and I thought there was no arch skew problem with glib2.0
[21:39] <cjwatson> had forgotten about multiarch agan
[21:39] <cjwatson> *again
[21:40] <slangasek> yeah... I think we're going to want to start shoving lots of libraries through -proposed anymore after betas
[21:41] <cjwatson> or fix apt to do a better job of selecting workable library combinations out of what's available to it in the archive
[21:43] <cjwatson> (NP-complete in general, I imagine, but surely that little detail ought not to bother a resolver :-P)
[21:46] <slangasek> :)
[21:47] <cjwatson> oh, mind you, not sure we keep the old non-arch-all binaries
[21:51] <bdmurray> cjwatson: do you think bug 921889 should be a duplicate of bug 500175?
[21:55] <cjwatson> bdmurray: Hard to be sure.  Probably.
[21:56] <bdmurray> cjwatson: because it might be bug 442941 or something else entirely?
[21:57] <cjwatson> bdmurray: I left a comment.
[21:59] <bdmurray> cjwatson: It seems to me like these package install failures are missing some bit of information and are not useful in their current state is that correct?
[22:01] <cjwatson> Kind of.  I wrote up my thoughts on this failure type in bug 500175 a while back.
[22:01] <cjwatson> Specifically comment 10.
[22:45] <doko> now I think I did fix all build failures for an openjdk-7 update, and then ...
[22:46] <doko> cp: writing `/home/packages/openjdk/7/openjdk-7-7~u3-2.1.1~pre1/build/openjdk.build/j2sdk-image/jre/lib/amd64/zero/libjvm.so': No space left on device
[22:46] <doko> cp: failed to extend `/home/packages/openjdk/7/openjdk-7-7~u3-2.1.1~pre1/build/openjdk.build/j2sdk-image/jre/lib/amd64/zero/libjvm.so': No space left on device
[22:46] <doko> make[1]: *** [stamps/add-zero.stamp] Error 1
[22:46] <doko> :-/
[22:46]  * doko removes a few gcc builds
[22:57] <slangasek> maxb, james_w: plymouth's UDD branch suddenly got a merge from the package importer today, resetting it back to the state of the last upload; do you know why that would be?
[22:57] <slangasek> james_w: oh, I see plymouth was one of the ones I asked you about on bug #714622
[22:57] <slangasek> james_w: so the result seems to have been the exact opposite of what I was looking for ;
[22:57] <slangasek> ;)
[23:01] <maxb> hm, this surprises me
[23:12] <maxb> Ugh, the importer has really made a mess of plymouth
[23:21] <slangasek> maxb: well, it seems to be easy enough for me to revert by just dropping the latest commit ;)
[23:25] <maxb> slangasek: yeah, I've done that on the precise branch. Now working on the oneiric branch
[23:26] <slangasek> maxb: cheers
[23:30] <maxb> urgh, except I can't uncommit from the oneiric branch, due to what I assume is a bug with branch stacking
[23:34] <maxb> and it's trampled the natty branch too
[23:37] <bdmurray> are the apt tasks in bug 659438 still necessary?