My host OS is Arch Linux and it recently updated python to 3.9. I am now unable to build OW. I am assuming the two are related. Does one need to do anything to trigger any update to toolchains or am I completely off base?
For example, trying to build 9aabd934a98ca894dc178d875f6ca6ea14ce427d from master for ath79/generic (buildbot config) gives this build.log.
EDIT: I deleted my toolchains and am rebuilding them thinking that might have an effect. Any thoughts?
Well naturally a "make dirclean" to clear both "tools" (host tool binaries) and "toolchain" (gcc,musl, gdb etc.) is appropriate.
Not suite sure whre the error comes from, as you have been compiled multi-threaded with "-j something " ??? (that makes log reading really difficult)
Searching for "***" reveal the earliest error, and that is not related to python at all.
make[3]: *** [Makefile:35: /scratch/union/build_dir/target-aarch64_cortex-a72_musl/wireless-regdb-2020.04.29/.built] Error 127
make[3]: Leaving directory '/scratch/union/package/firmware/wireless-regdb'
time: package/firmware/wireless-regdb/compile#0.18#0.06#0.36
ERROR: package/firmware/wireless-regdb failed to build.
make[2]: *** [package/Makefile:114: package/firmware/wireless-regdb/compile] Error 1
make[2]: *** Waiting for unfinished jobs....
I have a vague recollection that year ago there was a global problem with regdb python3 transition.
But you should run the compilation singlethreaded to find out more closely.
And maybe just with a minimal package set. (just firmware + regdb ???)
@hnyman - Thank you for the reply. Rebuilting my toolchains did the trick. I successfully build the buildbot config for both ath79/generic and bcm27xx/bcm2711. I am assuming that python 3.8.6 --> 3.9.0 update on my host OS is to blame.
This.. There is a reason the error code tells you to re-run the job with -j1 V=s or -j1 V=sc. When you run multi-threaded, where it shows you it dies is never where it actually failed. It has to fail, and then wait for the rest of the threads to finish what they are doing. Calling the -j1 means that it runs down the list - in order - and will show you where the "first" failure is at.
I always suggest removing ./tmp, in addition to ./build_dir and ./staging_dir when I'm needing to ensure a build after a fundimental change to the build system (tools, toolchain, etc). Some might also suggest removing the ~/.ccache directory, but I don't use ccache, so dunno.
@Grommish and @hnyman - Thanks for the advice regarding single threads to debug; I will do so in the future. Regarding the three directories... I did just that when I rebuilt things.
There is no special "buildbot config". It is just the device defaults for each device. 
Great that you got it working.
There is no special "buildbot config". It is just the device defaults for each device.
Well, you have lots of additional packages compiled and symbols selected (and get much bigger images due to that). This actually makes a huge difference for build-testing, both in coverage of possible issues and build time.
I typically just do default settings for testing device support, but for a kernel bump one should use buildbot configuration ...
Sorry, but I get lost here. The images produced by buildbot are just the defaults for each device, AFAIK.
Sure, buildbot(s) build all packages either in phase1 or phase2 buildbot.
But from private build perspective, there is nothing special gained from using buildbot config.seed file.
Buildbot set (among others) the following two config symbols:
CONFIG_ALL_KMODS=y
CONFIG_ALL_NONSHARED=y
This will build a lot of packages, though not include the packages in the images. But all kernel config symbols enabled in these packages with =y (not =m) will be enabled for the devices built. This is necessary so you can download packages depending on these symbols via opkg afterwards.
On the contrary, if you use default settings (i.e. rm .config and then just select the target/device), you won't be able to download and run any package via opkg or binary that requires additional kernel symbols that are boolean (and thus require =y) on the resulting image, as the kernel in the image lacks these symbols.
This is also the reason why buildbot image kernels typically are a few hundred kiB (!) bigger than those just built locally (and which is why you always have to try with all feeds installed and buildbot settings for kernel size issue patches). On the contrary, this is why custom downstream firmwares without need for downloading packages can still be so much smaller and even support 4M flash.
So, there is a difference for local private build. You don't have to care though if you just include everything you need in the first place.
Apart from that, my initial comment was about testing, and there obviously it's even more important to also have the packages built. And of course, having or not having feeds installed is another lever in this context.
This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.