[U-Boot] [ANN] U-Boot v2019.10 released

[Michal Simek]

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 at 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 at 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.

Thanks,
Michal

-- 
Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel - Xilinx Microblaze
Maintainer of Linux kernel - Xilinx Zynq ARM and ZynqMP ARM64 SoCs
U-Boot custodian - Xilinx Microblaze/Zynq/ZynqMP/Versal SoCs