[U-Boot] [ANN] U-Boot v2019.10 released
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.
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
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!
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
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
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
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
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.
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
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.
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
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.
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
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!
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 ;)
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.
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
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.
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
participants (8)
-
Bin Meng -
Daniel Schwierzeck -
Heiko Schocher -
Michal Simek -
Peter Robinson -
Simon Goldschmidt -
Tom Rini -
Wolfgang Denk