On Tue, Oct 08, 2019 at 04:17:08PM +0200, Michal Simek wrote: > On 08. 10. 19 16:02, Tom Rini wrote: > > 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 <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? > >>> > >>> 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. > > Is there something blocking us to move it to /tmp?
I don't know if in travis /tmp is a tmpfs or not, to start with. If we can preface things to move our checkout to /builds/u-boot/u-boot (which is what I see it as in GitLab, once we move to non-root builds at least) it will be a match. I'm currently kicking moving Travis to bionic, to match what we'll need in GitLab, to be able to move off of python2, can you kick a few ideas around in your travis please? But it's all a bandaid until we can move to I guess gcc-9 (as there's no one gcc-8 that works for everyone) and get the prefix map thing. Thanks! -- Tom
signature.asc
Description: PGP signature
_______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
