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

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

[Tom Rini]

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.

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.

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

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

[Michal Simek]

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 :-)

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

There are also warnings about conversions to DM.

Is it OK to ignore these boards which should be likely removed?

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

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

[Tom Rini]

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
> 
> 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
there's some /full/path string(s) somewhere that we should find and
address.  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/67cbcb5b/attachment.sig>

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

[Michal Simek]

On 08. 10. 19 14:35, Tom Rini 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
>>
>> 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
> there's some /full/path string(s) somewhere that we should find and
> address.  Thanks!

It was catched by Travis on my branch.
https://travis-ci.org/michalsimek/u-boot/jobs/594990410

But I was retesting it on my PC on tag too(log above).

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

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

[Bin Meng]

On Tue, Oct 8, 2019 at 8:36 PM Tom Rini <trini@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!

Regards,
Bin

[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@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>

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

[Tom Rini]

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

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

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

[Simon Goldschmidt]

On Tue, Oct 8, 2019 at 2:54 PM Tom Rini <trini@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@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] [ANN] U-Boot v2019.10 released

[Tom Rini]

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

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

[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@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@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

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

[Tom Rini]

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

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

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

[Michal Simek]

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@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@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?

M


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

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

[Tom Rini]

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@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@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>

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

[Peter Robinson]

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

I think the big missing piece was to rebase libfdt to the upstream
1.5.x series that now supports python3, the issue there from memory
was that it bloats some things, Simon was investigating and going to
post a patch set for upstream dtc/libfdt to resolve some of the issues
but I'm not sure if he'd reported back on the latest status of that
work.

Peter

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

[Tom Rini]

On Tue, Oct 08, 2019 at 04:36:08PM +0100, Peter Robinson wrote:
> > 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.
> >
> > 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.
> 
> I think the big missing piece was to rebase libfdt to the upstream
> 1.5.x series that now supports python3, the issue there from memory
> was that it bloats some things, Simon was investigating and going to
> post a patch set for upstream dtc/libfdt to resolve some of the issues
> but I'm not sure if he'd reported back on the latest status of that
> work.

The libfdt part, by itself, turns out to be easy (just the normal
convert to python3 setup.py or whatever).  But binman/buildman/test.py
all need updating and are real work.

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

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

[Heiko Schocher]

Hello Michal,

Am 08.10.2019 um 14:38 schrieb Michal Simek:
> On 08. 10. 19 14:35, Tom Rini 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
>>>
>>> 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
>> there's some /full/path string(s) somewhere that we should find and
>> address.  Thanks!
> 
> It was catched by Travis on my branch.
> https://travis-ci.org/michalsimek/u-boot/jobs/594990410
> 
> But I was retesting it on my PC on tag too(log above).

Sorry missed this thread yesterday ...

Yes I detected this issue also here, as I wanted to send a pull request
for ubi:

https://lists.denx.de/pipermail/u-boot/2019-October/385848.html

I asked Prafulla (listed as Board Maintainer) if there are plans to
convert this board to DM or if it can be removed.

bye,
Heiko
-- 
DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-52   Fax: +49-8142-66989-80   Email: hs at denx.de

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

[Wolfgang Denk]

Dear Tom,

In message <20191007211543.GQ6716@bill-the-cat> you wrote:
> 
> 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.

Thanks.  The release statistics is available as usual at [1].

[1] https://www.denx.de/wiki/U-Boot/UbootStat_2019_10

Here is the short summary:

Changes since v2019.07:

 * Processed 2007 csets from 190 developers
 * 31 employers found
 * A total of 111008 lines added, 38325 removed (delta 72683)

Developers with the most changesets
Simon Glass                252 (12.6%)
Kever Yang                 142 (7.1%)
Heinrich Schuchardt        115 (5.7%)
Patrick Delaunay           112 (5.6%)
Jagan Teki                  89 (4.4%)
Bin Meng                    70 (3.5%)
Hou Zhiqiang                66 (3.3%)
Adam Ford                   55 (2.7%)
Lukasz Majewski             46 (2.3%)
Peng Fan                    45 (2.2%)
...

Developers with the most changed lines
Simon Glass               15674 (12.4%)
Jagan Teki                7394 (5.8%)
Kever Yang                7177 (5.7%)
Marek Vasut               6504 (5.1%)
Bin Meng                  5608 (4.4%)
Heinrich Schuchardt       5109 (4.0%)
Lukasz Majewski           4813 (3.8%)
Patrick Delaunay          3764 (3.0%)
Manivannan Sadhasivam     3703 (2.9%)
Neil Armstrong            3599 (2.8%)
...

Developers with the most lines removed
Uwe Kleine-König         2338 (6.1%)
Heinrich Schuchardt       1027 (2.7%)
Horatiu Vultur             455 (1.2%)
Holger Brunck              431 (1.1%)
Tom Rini                   418 (1.1%)
Patrice Chotard            211 (0.6%)
Bartosz Golaszewski        193 (0.5%)
Ilko Iliev                 192 (0.5%)
Bernhard Messerklinger      77 (0.2%)
Ryan Harkin                 67 (0.2%)
...

Developers with the most signoffs (total 335)
YouMin Chen                 55 (16.4%)
Stefan Roese                36 (10.7%)
Patrice Chotard             23 (6.9%)
Michal Simek                20 (6.0%)
Tom Warren                  16 (4.8%)
Tom Rini                    14 (4.2%)
Holger Brunck               13 (3.9%)
Igor Opaniuk                12 (3.6%)
Matthias Brugger            10 (3.0%)
Bin Meng                     8 (2.4%)
...

Developers with the most reviews (total 897)
Bin Meng                   185 (20.6%)
Kever Yang                 119 (13.3%)
Prabhakar Kushwaha         108 (12.0%)
Simon Glass                 53 (5.9%)
Peng Fan                    40 (4.5%)
Jagan Teki                  35 (3.9%)
Lokesh Vutla                32 (3.6%)
Oleksandr Suvorov           31 (3.5%)
Stefan Roese                26 (2.9%)
Anup Patel                  21 (2.3%)
...

Developers with the most test credits (total 121)
Bin Meng                    43 (35.5%)
Anup Patel                   7 (5.8%)
Heiko Schocher               6 (5.0%)
Jernej Skrabec               5 (4.1%)
Corentin Labbe               5 (4.1%)
Steffen Dirkwinkel           5 (4.1%)
Adam Ford                    5 (4.1%)
Mark Kettenis                4 (3.3%)
Heinrich Schuchardt          3 (2.5%)
Joris Offouga                3 (2.5%)
...

Developers who gave the most tested-by credits (total 121)
Park, Aiden                 12 (9.9%)
Lukas Auer                  11 (9.1%)
Andre Przywara              10 (8.3%)
Simon Glass                  8 (6.6%)
Ramon Fried                  7 (5.8%)
Pierre-Jean Texier           6 (5.0%)
Yangbo Lu                    5 (4.1%)
Anup Patel                   4 (3.3%)
Marek Vasut                  4 (3.3%)
Neil Armstrong               4 (3.3%)
...

Developers with the most report credits (total 28)
Fermín Serna                5 (17.9%)
Ramon Fried                  4 (14.3%)
Simon Glass                  2 (7.1%)
Heinrich Schuchardt          2 (7.1%)
Jagan Teki                   2 (7.1%)
Sam Protsenko                2 (7.1%)
Fabio Estevam                2 (7.1%)
Marek Vasut                  1 (3.6%)
Kever Yang                   1 (3.6%)
Michal Simek                 1 (3.6%)
...

Developers who gave the most report credits (total 28)
Heinrich Schuchardt          7 (25.0%)
liucheng (G)                 5 (17.9%)
Jagan Teki                   3 (10.7%)
Eugeniu Rosca                3 (10.7%)
Anatolij Gustschin           2 (7.1%)
Bin Meng                     2 (7.1%)
Tom Rini                     1 (3.6%)
Simon Goldschmidt            1 (3.6%)
Suniel Mahesh                1 (3.6%)
Thierry Reding               1 (3.6%)
...

Top changeset contributors by employer
(Unknown)                  617 (30.7%)
Google, Inc.               253 (12.6%)
NXP                        216 (10.8%)
Rockchip                   144 (7.2%)
ST Microelectronics        140 (7.0%)
Texas Instruments          133 (6.6%)
DENX Software Engineering   98 (4.9%)
Amarula Solutions           96 (4.8%)
Linaro                      53 (2.6%)
BayLibre SAS                37 (1.8%)
...

Top lines changed by employer
(Unknown)                 41704 (32.9%)
Google, Inc.              15764 (12.4%)
NXP                       13113 (10.3%)
Amarula Solutions         7993 (6.3%)
DENX Software Engineering 7616 (6.0%)
Texas Instruments         7484 (5.9%)
Rockchip                  7183 (5.7%)
ST Microelectronics       5440 (4.3%)
Linaro                    4849 (3.8%)
BayLibre SAS              4685 (3.7%)
...

Employers with the most signoffs (total 335)
Rockchip                    62 (18.5%)
(Unknown)                   53 (15.8%)
ST Microelectronics         43 (12.8%)
DENX Software Engineering   38 (11.3%)
Texas Instruments           27 (8.1%)
NXP                         20 (6.0%)
Xilinx                      20 (6.0%)
NVidia                      16 (4.8%)
Konsulko Group              14 (4.2%)
Toradex                     11 (3.3%)
...

Employers with the most hackers (total 195)
(Unknown)                   97 (49.7%)
NXP                         20 (10.3%)
Texas Instruments           11 (5.6%)
Linaro                       7 (3.6%)
DENX Software Engineering    6 (3.1%)
ST Microelectronics          5 (2.6%)
Toradex                      4 (2.1%)
Novell                       4 (2.1%)
BayLibre SAS                 4 (2.1%)
Intel                        4 (2.1%)
...


Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
An age is called Dark not because  the  light  fails  to  shine,  but
because people refuse to see it.           -- James Michener, "Space"

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

[Daniel Schwierzeck]

Hi Tom,

On Tue, Oct 8, 2019 at 2:53 PM Tom Rini <trini@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@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.
>

this could also be fixed by replacing all usages of __FILE__ with
KBUILD_BASENAME which would work with all toolchain versions ;)

-- 
- Daniel

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

[Tom Rini]

On Mon, Oct 14, 2019 at 01:04:00PM +0200, Daniel Schwierzeck wrote:
> Hi Tom,
> 
> On Tue, Oct 8, 2019 at 2:53 PM Tom Rini <trini@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@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.
> 
> this could also be fixed by replacing all usages of __FILE__ with
> KBUILD_BASENAME which would work with all toolchain versions ;)

Yes, but I also loathe getting these files further out of sync with
Linux.  There's already a pretty big backlog of stuff to re-sync but I'm
telling myself to not do that now as the python2 problem is more
immediate.

-- 
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/20191014/69486b98/attachment.sig>