[12:30] <ogra_> argh ... amd64 and i386 dont use the same live builder ?
[12:31]  * ogra_ curses 
[12:31] <ogra_> cjwatson_, do you know if the livefs builders are multiarch enabled by default ?
[12:32]  * ogra_ just noticed he needs an amd64 livefs builder but some i386 packages for the android builds ... 
[12:32] <ogra_> ... and indeed i filed a wrong RT assuming the i386 and amd64 builders are the same
[12:45] <cjwatson_> ogra_: No idea, but they typically do the actual live build in a chroot.  Which i386 packages do you need?
[12:46] <ogra_> a whole bunch ... https://wiki.ubuntu.com/Touch/Porting#Set_up_your_development_environment
[12:46] <ogra_> what i'm doing atm is just adding a script similar to livecd.sh to livecd-rootfs that does all the bits ... so i only need to adjust $COMMAND in BuildLiveCD
[12:47] <ogra_> http://paste.ubuntu.com/5649288/
[12:47] <cjwatson_> Urgh!  Please pretend livecd.sh doesn't exist
[12:47] <cjwatson> So the right answer for that is for there to be a separate chroot for building Android images
[12:47] <ogra_> i dont want to hack all this directly into BuildLiveCD
[12:48] <cjwatson> Sure, just don't use livecd.sh as an example of anything
[12:48] <ogra_> no, only the elif code in BuildLiveCD that switches $COMMAND
[12:49] <ogra_> i didnt plan to revive it :)
[12:49] <cjwatson> Yeah, that's probably inevitable
[12:49] <ogra_> similar switch to UBUNTU_DEFAULTS_LOCALE ... but then using "COMMAND="/usr/sbin/ubuntu-touch-android.sh ${SUBARCH}"" ... which is the above paste
[12:50] <ogra_> though assuming i'm in a chroot thats $current_dev_release multiarch should be fine ...
[12:53]  * ogra_ should probably add a "dpkg --add-architecture i386" to the script though ... 
[15:54] <vibhav> hmm
[15:54] <vibhav> We have an outdated topic
[15:55] <vibhav> cjwatson: Could you change Archive: Open to Archive: Closed?
[16:01] <cjwatson> vibhav: it's not closed
[16:21] <jodh> could someone take a look at my latest comments on ffe bug 1155205 as they may merit re-approval of that bug before upload.
[16:21] <ubot2> Launchpad bug 1155205 in upstart (Ubuntu) "FFE Request for Upstart in raring" [Undecided,Triaged] https://launchpad.net/bugs/1155205
[17:19] <vibhav> cjwatson: My fault, I was quite sleepy at the time
[17:19] <vibhav> yes, freeze
[19:02] <slangasek> bdmurray: what do you think about the last comment on bug #586462?
[19:02] <ubot2> Launchpad bug 586462 in pam (Ubuntu Lucid) "/sbin/pam_tally2 not included in package" [Medium,Triaged] https://launchpad.net/bugs/586462
[19:19] <bdmurray> slangasek: I'm fine with it being SRU'ed again I guess
[19:27] <slangasek> bdmurray: do you feel like doing expedited processing if I reupload it?  Otherwise I probably won't bother
[19:29] <bdmurray> slangasek: I could do that
[19:33] <slangasek> ok
[19:43] <stgraber> hey there, any archive admin around with a minute to bin-new upstart?
[19:44]  * stgraber wants to close bug 1155205 (wasn't listed in changelog, so needs manual monitoring)
[19:44] <ubot2> Launchpad bug 1155205 in upstart (Ubuntu) "FFE Request for Upstart in raring" [Undecided,Triaged] https://launchpad.net/bugs/1155205
[19:48] <slangasek> jodh: ^^ please close bugs in the debian/changelog when uploading :)
[19:48] <slangasek> stgraber: I'll have a look
[19:49] <stgraber> slangasek: thanks
[19:50] <slangasek> stgraber: done
[19:51] <stgraber> slangasek: thanks, I'll wait for it to publish and close the FFe bug
[19:51] <slangasek> stgraber: seems unnecessary to wait IMHO
[19:52] <stgraber> slangasek: ok, closing now then (won't complain about having one less thing to monitor ;))
[20:03] <jodh> slangasek: ack - noted for next time :)
[20:07] <slangasek> bdmurray: pam reuploaded to lucid-proposed
[20:08] <doko> xnox, hmm, how do I re-add the raring task for bzr in 1116079?
[20:09] <infinity> You can't readd a task if someone deleted it.  LP bug.
[20:10] <infinity> Not that it needs a raring task anyway, the parent task will be closed on an upload to raring.
[20:59] <bdmurray> slangasek: qdiff doesn't seem very useful for reviewing it
[22:01] <bdmurray> slangasek: a new version of apt was uploaded to P for bug 923876, is the same change necessary for Q?
[22:01] <ubot2> Launchpad bug 923876 in aptitude (Ubuntu Quantal) "FR: Limit and clean-up kernel images and headers automatically in LTS" [Undecided,Confirmed] https://launchpad.net/bugs/923876
[22:28] <infinity> bdmurray: The Q one was superseded by a security update, I'll rebase and reupload (with the subsequent fix that was in P) this week.
[22:30] <bdmurray> infinity: great, thanks
[23:30] <slangasek> bdmurray: the same change is applicable to Q; I've been lax in getting it uploaded
[23:30] <slangasek> bdmurray: qdiff> yeah, I imagine the diff just shows the changelog, which would be what we want?
[23:32] <bdmurray> slangasek: well, yes it confirms you didn't make any other changes other than the one from the last SRU