1873 2011-12-29 02:45:05 +0000 [Build Appliance] Track Dave's comments on build appliance 2012-03-14 20:42:21 +0000 1 1 7 Build System, Metadata & Runtime Meta-yocto meta-yocto 1.2 x86 Multiple RESOLVED FIXED (QA testing completed) (Done) Low enhancement 1.2 M3 1 shane.wang edwin.zhai dexuan.cui jiajun.xu poky.bs.watcher poky.watcher song.liu --- --- --- oldest_to_newest 17879 0 shane.wang 2011-12-29 02:45:05 +0000 I thought I would give you a few comments for finishing this up: * I see that you are booting straight into Hob, which is what was requested. I guess I didn’t think that you would have no window manager running at all, but it makes sense. This implies that there will be a number of things which need to be built into the hob to make it useful. I have noted a few below… * As you already know, there needs to be a deployment option. Have you thought about how this will look? * For QEMU* images, should there be an option to start QEMU with the resulting image? * You will need to add the ability to set up a proxy. I realize that this is not needed for the no-net version, but if you are loading off the network, there will need to be some option for setting these. * Should there be a dialog for storage management? Something for example which allows you to remove previously built images? Let’s say you have used the appliance for a while and have created 20 or 30 images, you would need to remove some of them to recover space. * Should there be an option to remove all of tmp to force a complete rebuild of everything from sources? * Without a WM, I am wondering if you will need the ability to adjust the running display resolution. Even when running this in VMWare, I think the bare metal hardware display will vary in its dimensions, and the default chosen might not be the best. * Should we give the option to allow someone to escape the Hob jail and enter a window manager? * Let’s think about the usage model for a minute and see if this works. If there is no WM, then the only thing you can do is chose which packages to include in the image and some of the parameters for the build. You can’t edit any of your sources (unless you add an editor), and I’m not sure you can adjust any kernel parameters. I suppose we could say that these are all advanced features and require you to run Yocto the way God and Richard Purdie designed it (ie, installed on a regular desktop Linux) so we avoid feature bloat. * Final comment is about the VMWare image size… it sounded like the full one with all SSTATE populated is about 20GB… which seems like a lot. 17880 1 shane.wang 2011-12-29 02:46:35 +0000 Saul's comments: --------------------- > * I see that you are booting straight into Hob, which is what was requested. I guess I didn't think that you would have no window manager running at all, but it makes sense. This implies that there will be a number of things which need to be built into the hob to make it useful. I have noted a few below... > We are considering a window mananger to be able to hand dropping to a shell, running a qemu session, or starting the deployment gui. > * As you already know, there needs to be a deployment option. Have you thought about how this will look? > It's being worked now, Dexuan is looking at a script that Darren had and is going to work on a PyGTK gui that could be launch from HOB > * For QEMU* images, should there be an option to start QEMU with the resulting image? > Agreed, also something we have started talking about, this gets more interesting with a client/server setup, as the images need to be loaded locally and what host are we on, ... > * You will need to add the ability to set up a proxy. I realize that this is not needed for the no-net version, but if you are loading off the network, there will need to be some option for setting these. > Maybe another dialog box, this is probably as much a HOB issue as it is for the self-hosted target, it's a matter of when hob starts (it needs to build pseudo first, and therefor needs to the proxies very early). This again could be a GUI of somekind that does sanity tests after the proxies are set (test connection button). > * Should there be a dialog for storage management? Something for example which allows you to remove previously built images? Let's say you have used the appliance for a while and have created 20 or 30 images, you would need to remove some of them to recover space. > > * Should there be an option to remove all of tmp to force a complete rebuild of everything from sources? > > * Without a WM, I am wondering if you will need the ability to adjust the running display resolution. Even when running this in VMWare, I think the bare metal hardware display will vary in its dimensions, and the default chosen might not be the best. > These three might be getting scope creep, I know we need to make this usable, the display resolution and storage starts to smack of a Full OS and we need to be careful about that. If we have to boot on any device and handle any display we are not going to make it. I thought the idea was to build on a mac, pc, or linux box using VMware, with a fixed configuration that would be delivered. If I am wrong about this we need to really revisit. For the time being if we get a shell window with a WM, then cleaning can be done from there. > * Should we give the option to allow someone to escape the Hob jail and enter a window manager? > See above about adding a WM > * Let's think about the usage model for a minute and see if this works. If there is no WM, then the only thing you can do is chose which packages to include in the image and some of the parameters for the build. You can't edit any of your sources (unless you add an editor), and I'm not sure you can adjust any kernel parameters. I suppose we could say that these are all advanced features and require you to run Yocto the way God and Richard Purdie designed it (ie, installed on a regular desktop Linux) so we avoid feature bloat. > Pretty much to do anything other than create images from the default packages you are correct, you can't do it with HOB and now shell window. > * Final comment is about the VMWare image size... it sounded like the full one with all SSTATE populated is about 20GB... which seems like a lot. We can use SSTATE_MIRRORS, but we would still need to ship a VMDK that could grow to that size or larger for builds, images and local SSTATE. 17881 2 shane.wang 2011-12-29 02:49:01 +0000 Shane just filed a bug to track those, and assigned to Edwin. When Edwin and Dexuan are doing "build appliance", please consider them. 17894 3 edwin.zhai 2011-12-29 22:40:10 +0000 I have added matchbox-wm into mini-X. Test showed it can meet our requirements: window close and switch. Then most of the features can be achieved by switching to another terminal. 18039 4 edwin.zhai 2012-01-10 00:15:52 +0000 With WM enabled, we achieve most of the features, excepting following: * deployment option * setup proxy via HOB * image size 18513 5 edwin.zhai 2012-02-06 17:14:31 +0000 I'd like to close this one, as remaining items like * deployment option * image size are already tracked by other bugs. Thanks, Edwin 18993 6 jiajun.xu 2012-03-13 14:52:15 +0000 QA has tested build appliance against both qemu and vmdk image, it could work as expected.