Hi Tom, On 26 May 2017 at 06:49, Tom Rini <tr...@konsulko.com> wrote: > > On Thu, May 25, 2017 at 09:15:33PM -0600, Simon Glass wrote: > > Hi Tom, > > > > On 25 May 2017 at 11:42, Tom Rini <tr...@konsulko.com> wrote: > > > On Thu, May 25, 2017 at 11:27:10AM -0600, Simon Glass wrote: > > >> Hi Tom, > > >> > > >> On 25 May 2017 at 05:19, Tom Rini <tr...@konsulko.com> wrote: > > >> > > > >> > On Wed, May 24, 2017 at 06:15:25PM -0600, Simon Glass wrote: > > >> > > > >> > > Hi Tom, > > >> > > > > >> > > This incorporates the v2 patch for 'fdt: Build the new python libfdt > > >> > > module' which should fix the problem with the original pull request. > > >> > > > > >> > > > > >> > > The following changes since commit > > >> > > be62fbf376261ab3a4ed5db3bf54d5df9e216d9f: > > >> > > > > >> > > Merge branch 'rmobile' of git://git.denx.de/u-boot-sh (2017-05-23 > > >> > > 16:22:03 -0400) > > >> > > > > >> > > are available in the git repository at: > > >> > > > > >> > > git://git.denx.de/u-boot-fdt.git > > >> > > > > >> > > for you to fetch changes up to > > >> > > da9c601049eb7c993c7f6e33ae10af7a847a483d: > > >> > > > > >> > > fdt: Drop fdt_select.py (2017-05-24 18:12:31 -0600) > > >> > > > >> > NAK. travis-ci blows up quite badly: > > >> > https://travis-ci.org/trini/u-boot/builds/235861889 > > >> > > >> I'm not sure how to repeat this problem. When I try this: > > > > > > Your best bet is likely: > > > https://docs.travis-ci.com/user/common-build-problems/#Troubleshooting-Locally-in-a-Docker-Image > > > > Sadly still no luck. I installed this one: > > > > travisci/ci-garnet:packer-1478744932 > > > > It includes python-dev but not swig, so should not be able to build > > the module. As expected I get this error: > > > > NO_SDL=1 ./tools/buildman/buildman -P sandbox_spl > > boards.cfg is up to date. Nothing to do. > > Building current source for 1 boards (1 thread, 8 jobs per thread) > > sandbox: + sandbox_spl > > +Traceback (most recent call last): > > + File "<stdin>", line 1, in <module> > > +ImportError: No module named libfdt > > +make[2]: *** [checkdtoc] Error 1 > > +make[1]: *** [spl/u-boot-spl] Error 2 > > +make: *** [sub-make] Error 2 > > > > > > If I install swig then all is well. I don't see the same error. > > > > I'm also unsure how you get it to pass with some boards but not others... > > > > There is obviously something odd going on. I also cannot understand > > why in this one: > > > > https://travis-ci.org/trini/u-boot/jobs/235861899#L769 > > > > I see it trying to compile libfdt_wrap.c. That should be handled by > > setup.py - I just cannot figure out why it would try to compile it > > itself: > > > > arm: + mx6sabresd_spl > > +mv: cannot stat lib/libfdt/pylibfdt/libfdt.py: No such file or directory > > +make[2]: *** [tools/_libfdt.so] Error 1 > > +make[1]: *** [tools] Error 2 > > +make: *** [sub-make] Error 2 > > arm: + ls1021aqds_nor_lpuart > > +x86_64-linux-gnu-gcc: error: lib/libfdt/pylibfdt/libfdt_wrap.c: No > > such file or directory > > +x86_64-linux-gnu-gcc: fatal error: no input files > > +compilation terminated. > > +error: command 'x86_64-linux-gnu-gcc' failed with exit status 4 > > +make[2]: *** [tools/_libfdt.so] Error 1 > > +make[1]: *** [tools] Error 2 > > +make: *** [sub-make] Error 2 > > arm: + mx6slevk > > +x86_64-linux-gnu-gcc: error: lib/libfdt/pylibfdt/libfdt_wrap.c: No > > such file or directory > > +x86_64-linux-gnu-gcc: fatal error: no input files > > +compilation terminated. > > +error: command 'x86_64-linux-gnu-gcc' failed with exit status 4 > > +make[2]: *** [tools/_libfdt.so] Error 1 > > +make[1]: *** [tools] Error 2 > > +make: *** [sub-make] Error 2 > > 55 0 3 /58 mx6qsabreauto > > boards.cfg is up to date. Nothing to do. > > Summary of current source for 58 boards (2 threads, 1 job per thread) > > arm: + mx6sabresd_spl ls1021aqds_nor_lpuart mx6slevk > > +mv: cannot stat lib/libfdt/pylibfdt/libfdt.py: No such file or directory > > > > > > Are you able to run with V=1 to get the full make output? That might > > help me narrow it down. Or, if you have a particular docket image, > > please point me to it. There seems to be some init going on though > > (e.g. /tmp/dtc). > > Anyone can use travis-ci :) In the past I've had some luck debugging > these issues (since I didn't want to mess with docker) by hacking up the > .travis.yml file to just have a single matrix entry for whatever I was > debugging and hack things as needed, including 'cat'ing files.
OK I found that with the prerequisites installed I can repeat this with something like: buildman -P sandbox (which only builds 3 boards) The problem is that setup.py is writing to the source directory. It seems to be hard to stop it doing that. I was aware of it but did not imagine the race condition it would create. I've updated the patches and sent v3. I have a passing run on travis-ci [1]. If all looks good I'll pull it in and try a take three early next week. Most of my testing is with buildman running on a branch. In that case each thread has its own source tree, so the race condition does not occur. Once again I'm really impressed with your test setup! Regards, Simon [1] https://travis-ci.org/sglass68/u-boot/builds/236586312 _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
