On Tue, Oct 08, 2019 at 03:56:41PM +0200, Michal Simek wrote:
On 08. 10. 19 15:25, Tom Rini wrote:
On Tue, Oct 08, 2019 at 03:15:32PM +0200, Simon Goldschmidt wrote:
On Tue, Oct 8, 2019 at 2:54 PM Tom Rini trini@konsulko.com wrote:
On Tue, Oct 08, 2019 at 08:50:17AM -0400, Tom Rini wrote:
On Tue, Oct 08, 2019 at 08:42:58PM +0800, Bin Meng wrote:
On Tue, Oct 8, 2019 at 8:36 PM Tom Rini trini@konsulko.com wrote: > > On Tue, Oct 08, 2019 at 02:20:40PM +0200, Michal Simek wrote: >> On 07. 10. 19 23:15, Tom Rini wrote: >>> Hey all, >>> >>> It's release day and while we've once again had some last minute >>> regression fixes, I feel things are as stable as they are likely to get >>> so I've tagged and released v2019.07 and I would like to thank all of >>> our contributor for their efforts. >> >> I expect v2019.10 :-) > > Oops. I did get the tag right this time at least. > >>> To repeat something I posted about in the previous -rc release, I've >>> clarified on the http://www.denx.de/wiki/U-Boot/CustodianGitTrees page >>> that the "next" branch is expected to be rebased. Why? While I'm not >>> sure if I want to apply things directly to the next branch and then give >>> them some sort of automated testing, I do want to try and give changes >>> some sort of build testing and similar sooner than I have, and that was >>> at least a related problem. >>> >>> In terms of a changelog, >>> git log --merges v2019.10-rc4..v2019.10 >>> or >>> git log --merges v2019.07..v2019.10 >>> >>> For this next release, one big concern I have but that I am hopeful we >>> will be able to overcome is that we need to remove Python 2.7 support. >>> Python 2.7 itself is end of lifed on January 1st, 2020. There's been a >>> number of patches posted that get us a good part of the way there and I >>> believe we can get the rest done before the deadline. >>> >>> The merge window is once again open and I plan to tag -rc1 on October >>> 28th, bi-weekly -rcs thereafter and final release on January 6th, 2020. >> >> I am preparing pull request and I see that release has issue with >> sheevaplug board. >> >> 01: Prepare v2019.10 >> arm: + sheevaplug >> +u-boot.kwb exceeds file size limit: >> + limit: 524288 bytes >> + actual: 524632 bytes >> + excess: 344 bytes >> +make[1]: *** [u-boot.kwb] Error 1 >> +make[1]: *** Deleting file 'u-boot.kwb' >> +make: *** [sub-make] Error 2 >>
I saw this occasionally when I prepared the u-boot-x86 PR during past days, but I thought that was due to patches in my queue. However I remember I only saw excess 8 bytes or something, not 344 bytes ...
>> There are also warnings about conversions to DM. >> >> Is it OK to ignore these boards which should be likely removed? > > So, how / where are you making this fail? I know it's been noted > elsewhere that this happens, and also that the EFI PR will address this, > but my travis and gitlab pipelines passed. So that implies to me
My latest run of gitlab-ci passed as well. Again I was not sure if that was due to I dropped some SPL patches that were previously in the queue.
> there's some /full/path string(s) somewhere that we should find and > address. Thanks!
I see a few full path to source files in the resulting binary: $ strings /tmp/sheevaplug/current/sheevaplug/u-boot.bin | grep home /home/trini/work/u-boot/u-boot/drivers/mtd/mtdcore.c /home/trini/work/u-boot/u-boot/drivers/mtd/mtdpart.c /home/trini/work/u-boot/u-boot/drivers/mtd/ubi/attach.c /home/trini/work/u-boot/u-boot/net/eth_legacy.c /home/trini/work/u-boot/u-boot/drivers/mtd/nand/raw/nand_base.c /home/trini/work/u-boot/u-boot/drivers/mtd/ubi/vtbl.c /home/trini/work/u-boot/u-boot/drivers/mtd/nand/raw/nand_bbt.c
And we have -fmacro-prefix-map patches but our default toolchain doesn't support it (and these come from BUG/BUG_ON) and I still don't know of anyplace that provides a full set of new enough toolchains for use on all of the architectures we care about.
For BUG/BUG_ON in SPL/TPL, wouldn't the function name and line be enough info?
Note that for Sheevaplug it's the full U-Boot that's blowing up and not SPL/TPL.
Anyway back to the problem. If path matters for all these cases. Path depends on your github username because clone is done like that.
git clone --depth=50 --branch=mainline-v20191008 https://github.com/michalsimek/u-boot.git michalsimek/u-boot
And buildman is running without -o property. Shouldn't we setup -o property that it will behave the same for everybody? -o /tmp/ ?
Then all pathes should be the same for everybody without any dependency on github user name.
It's the source path not the binary path that's encoded in to the binary, is the problem. I don't know if we can easily / reliably do our builds somewhere else (gitlab for example is, or will be shortly, /builds/gitlab/u-boot in all cases) on Travis.