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

[Tom Rini]

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

-- 
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/fc8c67ef/attachment.sig>