On Tue, Oct 8, 2019 at 2:54 PM Tom Rini <tr...@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 <tr...@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? Regards, Simon _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
