From: Ash C. <as...@gu...> - 2010-08-17 19:34:44
|
Hi, I actually do regular builds against the Overo branch for testing. Recently, I've been playing around building different configurations using Buildbot (in the contrib. directory of the build tree there is already an example). However, I have not been able to get the build to automagically start using the git_poller method. I've not looked into adding a post-commit hook in gitorious but I can certainly do this if it is useful for anyone. Likewise, I've had a look at using Tinderbox as the oestats django package reports build data quite nicely. As a CI package though, Tinderbox seems to work well for CVS and not so much for git; I've not experimented much here so if other people have found different info, please let me know. My hit list for target builds looks like this: 'gcc-cross', 'virtual/bootloader', 'virtual/kernel', 'omap3-console-image', 'omap3-desktop-image'. What other important targets should be added? As for cleaning up old recipes...currently there is a (somewhat contentious) effort to do some clean up on the upstream OE tree. Perhaps it is better to see what changes this introduces before diving into spring cleaning mode. -Ash On Tue, Aug 17, 2010 at 11:12 AM, J. L. <vwy...@gm...> wrote: > I would be willing to setup at least one machine for this if others > like the idea. I think we should hit a few different OS's as well as > building maybe one image that is not the standard desktop or nand or > console image. Perhaps each person who sets up a machine for this can > make a very bloated image to test with the other 3 images as well. > > Also I think we need to clean up recipes, such as moving up the > default preferences on ones and or just getting rid of the old > versions. As well as making sure some of the recipes that are not > chosen by the default preference because of -1 should be made to > build. I notice a bunch of those do not build either. > > > On Tue, Aug 17, 2010 at 11:01 AM, AJ ONeal <coo...@gm...> wrote: >> How about a duct-tape jerry-rig solution using a "dev" and "unstable" >> branch, git-hooks, a small nodejs app with http requests, and a group of >> people will to let their machine burn their cpu whenever the overo branch >> gets updated? >> AJ ONeal >> >> On Tue, Aug 17, 2010 at 11:45 AM, J. L. <vwy...@gm...> wrote: >>> >>> I honestly think more testing needs to be done before pushing. I have >>> only built an image once successfully since purchasing an overo, and >>> never been able to build a gnome image! As you say Steve OE is complex >>> so I think you being the only tester is a bad practice. We need more >>> people testing and the build machine seems just as dependent as the >>> upstream changes not breaking anything. Also Steve if you read what >>> the guys on the OE list said about the same question posed there. We >>> are a random branch according to them. I also dont really see much >>> activity for fixes coming from you let alone anyone that gets put to >>> the OE dev branch. Also you just being able to build the basic image >>> is not enough testing in my book. You should have a test image that >>> builds as many different programs and configurations as possible >>> (hence why more testers and people helping you are needed). As some >>> programs build at certain times and others dont. There seems to be no >>> consistency at all and not very many having exactly the same issues >>> once a break occurs. You need help Steve you being a one man part time >>> person is not enough support or people working to better the overo >>> tree. Why does gumstix only have you doing this? Why are there not >>> more people from gumstix themselves helping you and making the overo >>> tree as great as it can and SHOULD be. I would gladly volunteer time >>> and efforts as I have a few different build machine configurations I >>> could do at home. >>> >>> On Tue, Aug 17, 2010 at 10:08 AM, Steve Sakoman <sa...@gm...> wrote: >>> > On Tue, Aug 17, 2010 at 8:51 AM, AJ ONeal <coo...@gm...> >>> > wrote: >>> > >>> >> How about something like this: >>> >> All updates are done in the "moving-target" (unstable) branch >>> > >>> > That is the org.openembedded.dev branch. >>> > >>> >> Any time the "moving-target" branch will build a clean >>> >> omap3-desktop-image >>> >> without errors it is merged with the "just-works" (stable) branch >>> > >>> > That is the overo branch. I merge with the upstream >>> > org.openembedded.dev branch approximately once a week. (this info is >>> > on the gumstix.net site IIRC) >>> > >>> > I then do builds of all of the "omap3" images and the >>> > sakoman-gnome-image on my dev machine (Ubuntu 10.04 quad core). I fix >>> > anything that might be broken and then do automated builds of the same >>> > images for both Beagle and Overeo on the www.sakoman.com machine >>> > (Ubuntu 9.04 64 bit server dual core). If successful then the result >>> > is pushed to overo branch. >>> > >>> > In theory that should yield a "just works" branch. >>> > >>> > In practice people still have problems. OE is a *very* complex build >>> > environment that still has dependencies on the package set installed >>> > on the build machine as well as lingering dependency issues that show >>> > up randomly depending on the number of cores on your machine and your >>> > settings for PARALLEL_MAKE and BB_NUMBER_THREADS. That is why -c >>> > clean and rebuilds of failing packages more often than not result in a >>> > good build the second time around. >>> > >>> > If you find fixes for the above, by all means submit the patches to >>> > the OE mailing list! You will have many grateful users :-) >>> > >>> >> The "just works" branch. >>> >> Then try to do a "bitbake world" on the "just-works" branches and tag >>> >> that >>> >> branch as special (or merge it with a "no-really-it-does-work" branch). >>> > >>> > Again, nice in theory. But I have *never* seen a 'bitbake world' >>> > succeed in real life :-) >>> > >>> >> Who is in charge anyway? Is that person interested in making things >>> >> more >>> >> reliable? Does that person want help? >>> > >>> > I guess I am the one currently "in charge" of the Overo branch. Of >>> > course I would like things to be more reliable! But this is a very >>> > big effort on a moving target, so the more folks that help the better. >>> > I'm one part-time consultant who is also doing board support for >>> > u-boot and the linux kernel so there is only so much that I can >>> > accomplish by myself. >>> > >>> > Again if you find fixes to OE issues, submitting them to the OE >>> > mailing list is the right thing to do. The Overo branch is 99.9% >>> > identical to org.openembedded.dev -- we use a custom linux and u-boot >>> > recipe so that we don't break every time someone upstream changes the >>> > "one size fits all" recipes upstream. We also have custom image >>> > recipes to control what goes in the NAND. If you find issues with >>> > those recipes, the gumstix list is the place to post your patches. >>> > But in my experience, the vast majority of build issues that people >>> > encounter are generic OE issues. Fixes for those should go to the OE >>> > list (and a cc to the gumstix list would be nice). >>> > >>> > Steve >>> > >>> > >>> > ------------------------------------------------------------------------------ >>> > This SF.net email is sponsored by >>> > >>> > Make an app they can't live without >>> > Enter the BlackBerry Developer Challenge >>> > http://p.sf.net/sfu/RIM-dev2dev >>> > _______________________________________________ >>> > gumstix-users mailing list >>> > gum...@li... >>> > https://lists.sourceforge.net/lists/listinfo/gumstix-users >>> > >>> >>> >>> ------------------------------------------------------------------------------ >>> This SF.net email is sponsored by >>> >>> Make an app they can't live without >>> Enter the BlackBerry Developer Challenge >>> http://p.sf.net/sfu/RIM-dev2dev >>> _______________________________________________ >>> gumstix-users mailing list >>> gum...@li... >>> https://lists.sourceforge.net/lists/listinfo/gumstix-users >> >> >> ------------------------------------------------------------------------------ >> This SF.net email is sponsored by >> >> Make an app they can't live without >> Enter the BlackBerry Developer Challenge >> http://p.sf.net/sfu/RIM-dev2dev >> _______________________________________________ >> gumstix-users mailing list >> gum...@li... >> https://lists.sourceforge.net/lists/listinfo/gumstix-users >> >> > > ------------------------------------------------------------------------------ > This SF.net email is sponsored by > > Make an app they can't live without > Enter the BlackBerry Developer Challenge > http://p.sf.net/sfu/RIM-dev2dev > _______________________________________________ > gumstix-users mailing list > gum...@li... > https://lists.sourceforge.net/lists/listinfo/gumstix-users > |