[11:27] <ogra_> cjwatson, hmm trying to merge rsalveti's goldfish support into cdimage ./run-tests produces http://paste.ubuntu.com/6508783/ even before i merge his code ...
[11:27] <ogra_> cjwatson, this is on precise (in case it matters) ...
[11:29] <ogra_> hmm, happens even if i remove the last few commits from the tree
[11:31]  * ogra_ does a cresh bzr checkout
[11:31] <ogra_> *fresh too
[11:32] <ogra_> hmm, no, doesnt change a thing
[12:05] <ogra_> aha, works fine in a trusty chroot
[12:15] <jamespage> could someone flush git through the NEW queue for trusty - its blocking openstack package builds in one of the server CI labs right now
[12:15] <jamespage> please (sorry - forgot my manners for a moment then)
[12:20] <rsalveti> ogra_: hey
[12:20] <ogra_> hey
[12:21] <ogra_> wrangling with your merge currently
[12:21] <rsalveti> ogra_: seems the test failures are not related with the code I changed
[12:21] <ogra_> no, they show on older commits too
[12:21] <ogra_> and dont show in a trusty cheroot
[12:21] <rsalveti> ogra_: right
[12:22] <ogra_> i'm on my xps now ... that hasa trusty setup ... if it works there i'll commit and push
[12:22] <ogra_> (and start a test image)
[12:25] <rsalveti> ogra_: cool, thanks
[15:19] <zul> can someone have a look at git please, it has some pending binaries https://launchpad.net/ubuntu/+source/git/1:1.8.5-1 thats blocking the openstack-ci lab
[15:55] <rsalveti> stgraber: hey, so we finally have the goldfish files in cdimage, can you enable it in system-image?
[16:07] <shadeslayer_> Could someone review kscreen in the unapproved queue plz ? bug 1254125
[16:07] <ubot2> Launchpad bug 1254125 in kscreen (Ubuntu Saucy) "Please update kscreen to 1.0.2.1" [Undecided,New] https://launchpad.net/bugs/1254125
[16:14] <stgraber> rsalveti: added
[16:15] <stgraber> rsalveti: note that I got some weird output when generating the device tarball, something about the system.img not being in the right format
[16:15] <rsalveti> stgraber: oh, right, I don't think they are the same format indeed
[16:15] <rsalveti> might need some other changes then
[16:16] <stgraber> rsalveti: right, the resulting device.tar.xz contains a 0 byte system.img, so you'll need to fix the format to match :)
[16:16] <rsalveti> stgraber: right, have a link to the branch that actually does this logic?
[16:16] <rsalveti> but I guess I need to change the android side of it
[16:17] <stgraber> yeah, it'd be easy to hack in system-image to have it not call simg2img but I'd rather not special case goldfish in there
[16:17] <rsalveti> sure
[16:17] <stgraber> so it'd probably be best if you could do a img2simg on the .img as part of the build
[16:18] <rsalveti> stgraber: so you basically just convert to the proper img format and use that instead, right?
[16:19] <stgraber> right, what I do is simg2img and resize2fs to shrink it down to the minimum non-sparsed size
[16:20] <rsalveti> right, cool
[16:22] <stgraber> I guess if there was an easy way to detect simg vs standard img, I could have the code skip that part of the code
[16:23] <rsalveti> right
[16:26] <xnox> stgraber: rsalveti: i can turn off sparse images for all of our builds of system.img in the android package.
[16:26] <xnox> (it's a board make variable)
[16:27] <rsalveti> xnox: sure, just not sure yet if this is kind of what we want
[16:27] <rsalveti> as we still want the fastboot-compatible images to be at cdimage
[16:27] <stgraber> xnox: that'd make 2GB large raw images by default, not sure we want that :)
[16:28] <stgraber> and indeed, be problematic for those using them with fastboot
[16:28] <xnox> rsalveti: i think we do. Both are fastboot compatible, and we want to be able to mount the system image. If it for some reason increases in size, we just need to make sure we don't "overspecify" large system.img.
[16:28] <xnox> but we actually don't use 2GB of it, hm. horum.
[16:28] <rsalveti> we would need to drop to a common size
[16:28] <rsalveti> which might also give us problems
[16:29] <xnox> rsalveti: alternative is to enable sparse system.img for goldfish, which will make current scripts not work (basically a call to sim2img would be needed)
[16:29] <rsalveti> never flashed a raw image with fastboot either
[16:29] <rsalveti> xnox: yup, that's what I'm currently checking
[16:30] <xnox> to be honest, i think i did disable sparse images for goldfish cause "it's all local, i'm porting it and want to mount it"
[16:30]  * xnox is on the laptop, testing installer on my server machine so can't look it up easily at the moment.
[16:30] <rsalveti> not so sure, I don't think aosp creates sparse image by default for it
[16:30] <ogra_> wasnt the final target to have an mmc like image with partition table etc
[16:30] <ogra_> for the emulator
[16:31] <rsalveti> but anyway, I'm checking if creating a sparse image for it is desirable
[16:31] <rsalveti> ogra_: later on, maybe
[16:31] <ogra_> so that it behaves identical to a real install
[16:37] <xnox> ogra_: i posted patches to boot of GPT partitioned mmc card =) but i'm yet to see responses to that.
[16:37] <xnox> ogra_: initramfs-ubuntu-touch patch is fairly generic, and other patch, is just tweaks to the build-emulator-sdcard.sh script to format it gpt.
[16:38] <ogra_> well, i think it should be our final target to get as close as possible to real HW
[16:38] <ogra_> especially for testing OTA upgrades etc
[16:38] <rsalveti> ogra_: right, I think we just need to discuss what would be our partitioning scheme
[16:39] <xnox> well, it still doesn't boot off the sdcard (but rather kernel/initramfs from command line)
[16:39] <ogra_> xnox, thats the next step then :)
[16:39] <rsalveti> but that's mostly because we don't have a bootloader
[16:39] <xnox> but i'm not keen on diving into qemu code to find/fix where/how it loads kernel off command line, instead of raw offset from the sdcard.
[16:39] <ogra_> right
[16:40] <xnox> yeah, no bootloader, so we could hack/hardcode qemu to read the raw kernels/initramfs from sdcard offset...... potentially.
[16:41] <xnox> i guess i should create the 3*8MB big bootloader partition as the first one. the rest can be flexible.