Re: [yocto] How to temporarily disable a package rebuild during an image build?

[Alex J Lennon]

On 31/01/2014 01:22, Adam Lee wrote: I see. Why not just build the kernel image (uImage) and copy the file over to your /boot partition? That way you don't have to build and as well as write an entire image to ur card, saving you some time.  I'm  sure you're right Adam. Historically I've run into trouble with building kernel images without the associated modules in the f/s but I may be over-thinking the problem there. Perhaps it's a non issue, or at least would be something I could work around. I also mistakenly assumed that the build system was doing something with the Freescale secret sauce to add bootstream headers to image files before dd'ing into magic offsets in the flash, but I see that with the wonders of u-boot it's a simple matter of loading the uImage from the FAT partition. I do like to do a complete rebuild as things do break on and off and I like to keep an eye on that, but I think I will follow your advice and just build the kernel image for now :) Cheers, Alex On Thu, Jan 30, 2014 at 4:00 PM, Alex J Lennon <ajlen...@dynamicdevices.co.uk> wrote: On 30/01/2014 23:54, Adam Lee wrote: Hi Alex, so are you bitbaking the entire image every time you make a change to the kernel (The .bb file you linked is the image recipe)? If you only build the kernel (ie bitbake virtual/kernel), your system shouldn't build the entire image. Let me know! That's exactly right Adam. I'm bitbaking an SD card image, writing that to a uSD card and booting it up :) In theory that should result in the kernel rebuild and a nice image for me to use. In actuality numbers of other things seem to decide they need to be rebuilt, which doesn't appear to be too much of a time-sink, excepting for QT4 Adam On Thu, Jan 30, 2014 at 3:11 PM, Alex J Lennon <ajlen...@dynamicdevices.co.uk> wrote: Hi Adam, On 30/01/2014 18:40, Adam Lee wrote: I am not sure if that's the correct behaviour at all. If you are building the kernel, it should only build the kernel (and its deps). How are you building it? I suppose you are doing 'bitbake virtual/kernel', but just checking! I'm building an image for test, based on fsl-image-gui out of meta-fsl-arm. It looks like that fsl image pulls in qt4 - https://github.com/Freescale/meta-fsl-demos/blob/master/recipes-fsl/images/fsl-image-gui.bb I don't quite understand why qt4 is rebuilding but if I had to guess perhaps it's got a dependency on framebuffer support or something. I could probably go in and change the image recipes if I really had to, but I'd rather leave them as is, assuming correctness of dependencies, I'd rather change an environment variable during my debug cycle to temporarily contrain rebuilding of packages that I know don't need to be rebuilt, so things revert to "correct" when I'm finished porting the kernel Cheers, Alex Adam On Wed, Jan 29, 2014 at 12:09 PM, Alex J Lennon <ajlen...@dynamicdevices.co.uk> wrote: Hi, I was wondering if there's a per-package environment variable I could use to contrain the rebuilding of packages? i.e. I am modifying a linux-imx kernel, rebuilding that kernel package and then generating an output filesystem image to boot from an SD card for testing. Each time I modify linux-imx I am finding that qt4 does a rebuild. So whilst I'm making changes to linux-imx for test I'd rather that q4 didn't rebuild when I build the image, and was wondering if there's a way to prevent that? (I could, I suppose, move to a testing model that didn't use a completely rebuilt SD card image but I like this approach as if it works, well, it works, and I can distribute. Perhaps there's a better way?) Thanks, Alex _______________________________________________ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto -- Alex J Lennon / Director 1 Queensway, Liverpool L22 4RA mobile: +44 (0)7956 668178 This e-mail message may contain confidential or legally privileged information and is intended only for the use of the intended recipient(s). Any unauthorized disclosure, dissemination, distribution, copying or the taking of any action in reliance on the information herein is prohibited. E-mails are not secure and cannot be guaranteed to be error free as they can be intercepted, amended, or contain viruses. Anyone who communicates with us by e-mail is deemed to have accepted these risks. Company Name is not responsible for errors or omissions in this message and denies any responsibility for any damage arising from the use of e-mail. Any opinion and other statement contained in this message and any attachment are solely those of the author and do not necessarily represent those of the company. -- Alex J Lennon / Director 1 Queensway, Liverpool L22 4RA mobile: +44 (0)7956 668178 This e-mail message may contain confidential or legally privileged information and is intended only for the use of the intended recipient(s). Any unauthorized disclosure, dissemination, distribution, copying or the taking of any action in reliance on the information herein is prohibited. E-mails are not secure and cannot be guaranteed to be error free as they can be intercepted, amended, or contain viruses. Anyone who communicates with us by e-mail is deemed to have accepted these risks. Company Name is not responsible for errors or omissions in this message and denies any responsibility for any damage arising from the use of e-mail. Any opinion and other statement contained in this message and any attachment are solely those of the author and do not necessarily represent those of the company. -- Alex J Lennon / Director 1 Queensway, Liverpool L22 4RA mobile: +44 (0)7956 668178 This e-mail message may contain confidential or legally privileged information and is intended only for the use of the intended recipient(s). Any unauthorized disclosure, dissemination, distribution, copying or the taking of any action in reliance on the information herein is prohibited. E-mails are not secure and cannot be guaranteed to be error free as they can be intercepted, amended, or contain viruses. Anyone who communicates with us by e-mail is deemed to have accepted these risks. Company Name is not responsible for errors or omissions in this message and denies any responsibility for any damage arising from the use of e-mail. Any opinion and other statement contained in this message and any attachment are solely those of the author and do not necessarily represent those of the company.

_______________________________________________
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto