<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Sun, Apr 26, 2015 at 2:28 PM, Ash Charles <span dir="ltr"><<a href="mailto:ashcharles@gmail.com" target="_blank">ashcharles@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Alexander,<br>
<br>
Great to hear from you---long time no talk indeed :).<br>
<br>
I submitted the snap here:<br>
<a href="https://myapps.developer.ubuntu.com/dev/click-apps/2476/" target="_blank">https://myapps.developer.ubuntu.com/dev/click-apps/2476/</a><br>
(FWIW, when I build the package, click-review gets angry and says<br>
"(MANUAL REVIEW) type 'oem' not allowed").<br></blockquote><div><br></div><div>This just means that we require manual review on the store for oem packages because they are not confined by default.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class=""><br>
On Sun, Apr 26, 2015 at 9:40 AM, Alexander Sack <<a href="mailto:asac@canonical.com">asac@canonical.com</a>> wrote:<br>
> oh i forgot in my other mail to explain that signing happens through<br>
> uploading to store! Is pretty trivial for you as you reuse our<br>
> official enablement/kernel and just have a custom dtb and bootloader.<br>
</span>Is 'flashtool-assets' totally superseded by oem packages?  I got hung<br>
up on this when I first started playing around.<br></blockquote><div><br></div><div>oem packages are what you want, we have killed flashtool-assets with this generic way of enabling oems to wok with the ubuntu kernels in a way that enables them to focus on what matters to them, feel free to log bug reports (or reply here) with anything you think will make or would have made the oem enablement part a better experience for you.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Being able to use a stock kernel made it really easy. I actually<br>
tested out a custom kernel too as some patches for our latest wireless<br>
chip (Wilink8) aren't yet mainlined but packing/unpacking the ramdisk<br>
got to be a pain.<br>
What is the best source for the ramdisk? The snappy-device-builder<br>
grabs [1], adds the custom kernel, and then re-packs for use as<br>
"--device-part"<br>
<br>
[1] <a href="http://cdimage.ubuntu.com/ubuntu-core/daily-preinstalled/current/vivid-preinstalled-core-armhf.device.tar.gz" target="_blank">http://cdimage.ubuntu.com/ubuntu-core/daily-preinstalled/current/vivid-preinstalled-core-armhf.device.tar.gz</a><br>
<br>
<snip><br>
<span class="">> this is a cool showcase how to 'freeride' our officially supported<br>
> enablement by just providing your board specifics in oem snap. Thanks<br>
> for this! Should be similarly trivial for plenty other boards like<br>
> panda beagleboard etc...<br>
</span>And DuoVero (OMAP4 like panda) and Pepper (AM335x like beaglebone) hehehe...<br>
<snip><br>
<span class="">> We don't have an overo in our teams. 20 seconds sounds a bit too long,<br>
> but not sure how the IO is on overo. If you want to debug you find us<br>
> on #snappy on freenode as well!<br>
</span>Cool--thanks. I've found that SD cards vary widely in performance so I<br>
may try loading the initrd from NAND just to test.<br></blockquote><div><br></div><div>True, the biggest boot slowness I think I've seen was networking not being available, if you can confirm that it would be great.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="HOEnZb"><div class="h5"><br>
--Ash<br>
<br>
--<br>
snappy-devel mailing list<br>
<a href="mailto:snappy-devel@lists.ubuntu.com">snappy-devel@lists.ubuntu.com</a><br>
Modify settings or unsubscribe at: <a href="https://lists.ubuntu.com/mailman/listinfo/snappy-devel" target="_blank">https://lists.ubuntu.com/mailman/listinfo/snappy-devel</a><br>
</div></div></blockquote></div><br></div></div>