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

Tue Oct 8 14:31:44 UTC 2019

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 <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.
> > 
> > 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20191008/41bfcfc2/attachment.sig>