[U-Boot] python3 support for pylibfdt
Hi Simon,
With the EOL of python2 soon I've been looking at the Fedora U-Boot builds to see what it would take to move over to python3. There's a couple of issues building the bundled pylibfdt, the first is the Makefile hard codes python2, the second is that the generated libfdt_wrap.c doesn't seem to find the python3 version of Python.h (errors below).
It seems upstream now supports building pylibfdt with dtc 1.5.0 but I couldn't quite work out how this fits into the U-Boot bundled version. Is there plans to be able to support pylibfdt with python3?
Regards, Peter
gcc -O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -fexceptions -fstack-protector-strong -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -fasynchronous-unwind-tables -fstack-clash-protection -o scripts/dtc/dtc scripts/dtc/dtc.o scripts/dtc/flattree.o scripts/dtc/fstree.o scripts/dtc/data.o scripts/dtc/livetree.o scripts/dtc/treesource.o scripts/dtc/srcpos.o scripts/dtc/checks.o scripts/dtc/util.o scripts/dtc/dtc-lexer.lex.o scripts/dtc/dtc-parser.tab.o BUILDSTDERR: set -e; : ' CHK include/generated/generic-asm-offsets.h'; mkdir -p include/generated/; (set -e; echo "#ifndef __GENERIC_ASM_OFFSETS_H__"; echo "#define __GENERIC_ASM_OFFSETS_H__"; echo "/*"; echo " * DO NOT MODIFY."; echo " *"; echo " * This file was generated by Kbuild"; escripts/dtc/pylibfdt/libfdt_wrap.c:154:11: fatal error: Python.h: No such file or directory BUILDSTDERR: 154 | # include <Python.h> BUILDSTDERR: | ^~~~~~~~~~ BUILDSTDERR: compilation terminated. BUILDSTDERR: error: command 'gcc' failed with exit status 1 BUILDSTDERR: make[4]: *** [/builddir/build/BUILD/u-boot-2019.07-rc4/scripts/dtc/pylibfdt/Makefile:27: scripts/dtc/pylibfdt/_libfdt.so] Error 1 BUILDSTDERR: make[3]: *** [/builddir/build/BUILD/u-boot-2019.07-rc4/scripts/Makefile.build:432: scripts/dtc/pylibfdt] Error 2 BUILDSTDERR: make[2]: *** [/builddir/build/BUILD/u-boot-2019.07-rc4/scripts/Makefile.build:432: scripts/dtc] Error 2 BUILDSTDERR: make[1]: *** [/builddir/build/BUILD/u-boot-2019.07-rc4/Makefile:528: scripts] Error 2 BUILDSTDERR: make: *** [Makefile:148: sub-make] Error 2 BUILDSTDERR: error: Bad exit status from /var/tmp/rpm-tmp.Ca2SD2 (%build)
On Tue, Jun 18, 2019 at 10:39:54AM +0100, Peter Robinson wrote:
Hi Simon,
With the EOL of python2 soon I've been looking at the Fedora U-Boot builds to see what it would take to move over to python3. There's a couple of issues building the bundled pylibfdt, the first is the Makefile hard codes python2, the second is that the generated libfdt_wrap.c doesn't seem to find the python3 version of Python.h (errors below).
It seems upstream now supports building pylibfdt with dtc 1.5.0 but I couldn't quite work out how this fits into the U-Boot bundled version. Is there plans to be able to support pylibfdt with python3?
Sounds like we need to run the normal kernel script to re-sync with upstream? Thanks!
On Wed, Jun 19, 2019 at 7:22 PM Tom Rini trini@konsulko.com wrote:
On Tue, Jun 18, 2019 at 10:39:54AM +0100, Peter Robinson wrote:
Hi Simon,
With the EOL of python2 soon I've been looking at the Fedora U-Boot builds to see what it would take to move over to python3. There's a couple of issues building the bundled pylibfdt, the first is the Makefile hard codes python2, the second is that the generated libfdt_wrap.c doesn't seem to find the python3 version of Python.h (errors below).
It seems upstream now supports building pylibfdt with dtc 1.5.0 but I couldn't quite work out how this fits into the U-Boot bundled version. Is there plans to be able to support pylibfdt with python3?
Sounds like we need to run the normal kernel script to re-sync with upstream? Thanks!
Seems reasonable, I'll keep an eye out for a patch series to test, it's quite straight forward to test from my PoV.
Peter
On Thu, Jun 20, 2019 at 11:45:02AM +0100, Peter Robinson wrote:
On Wed, Jun 19, 2019 at 7:22 PM Tom Rini trini@konsulko.com wrote:
On Tue, Jun 18, 2019 at 10:39:54AM +0100, Peter Robinson wrote:
Hi Simon,
With the EOL of python2 soon I've been looking at the Fedora U-Boot builds to see what it would take to move over to python3. There's a couple of issues building the bundled pylibfdt, the first is the Makefile hard codes python2, the second is that the generated libfdt_wrap.c doesn't seem to find the python3 version of Python.h (errors below).
It seems upstream now supports building pylibfdt with dtc 1.5.0 but I couldn't quite work out how this fits into the U-Boot bundled version. Is there plans to be able to support pylibfdt with python3?
Sounds like we need to run the normal kernel script to re-sync with upstream? Thanks!
Seems reasonable, I'll keep an eye out for a patch series to test, it's quite straight forward to test from my PoV.
It won't be any time soon, sadly. Updating to the same dtc in the kernel (so just v1.4.7+) causes both massive amount of new device tree warnings as well as several fail to link due to size growth problems.
With the EOL of python2 soon I've been looking at the Fedora U-Boot builds to see what it would take to move over to python3. There's a couple of issues building the bundled pylibfdt, the first is the Makefile hard codes python2, the second is that the generated libfdt_wrap.c doesn't seem to find the python3 version of Python.h (errors below).
It seems upstream now supports building pylibfdt with dtc 1.5.0 but I couldn't quite work out how this fits into the U-Boot bundled version. Is there plans to be able to support pylibfdt with python3?
Sounds like we need to run the normal kernel script to re-sync with upstream? Thanks!
Seems reasonable, I'll keep an eye out for a patch series to test, it's quite straight forward to test from my PoV.
It won't be any time soon, sadly. Updating to the same dtc in the kernel (so just v1.4.7+) causes both massive amount of new device tree warnings as well as several fail to link due to size growth problems.
I'm guessing the size problem is due to an increase in size of where libfdt is linked in and not due to pylibfdt. Would it make sense to have a feature branch with the rebase to make it easier to test/fix the issues? And rebasing some DT to the current kernel versions should fix up a bunch of the DT problems?
Fedora, as are many other distros, is actively retiring python2 due to it's upcoming EOL ~ 6 months from now. I've had to already rescue a couple of python2 packages to keep U-Boot building, there's an intention to actively remove python2 in Fedora 32 (scheduled for May 2020) which means anything post U-Boot 2019.10 (the version we're aiming for in F-31) will start to cause me big problems.
Maybe we could add this to migration plans like any of the DM subsytems?
Peter
On Fri, Jun 28, 2019 at 01:38:01PM +0100, Peter Robinson wrote:
With the EOL of python2 soon I've been looking at the Fedora U-Boot builds to see what it would take to move over to python3. There's a couple of issues building the bundled pylibfdt, the first is the Makefile hard codes python2, the second is that the generated libfdt_wrap.c doesn't seem to find the python3 version of Python.h (errors below).
It seems upstream now supports building pylibfdt with dtc 1.5.0 but I couldn't quite work out how this fits into the U-Boot bundled version. Is there plans to be able to support pylibfdt with python3?
Sounds like we need to run the normal kernel script to re-sync with upstream? Thanks!
Seems reasonable, I'll keep an eye out for a patch series to test, it's quite straight forward to test from my PoV.
It won't be any time soon, sadly. Updating to the same dtc in the kernel (so just v1.4.7+) causes both massive amount of new device tree warnings as well as several fail to link due to size growth problems.
I'm guessing the size problem is due to an increase in size of where libfdt is linked in and not due to pylibfdt. Would it make sense to have a feature branch with the rebase to make it easier to test/fix the issues? And rebasing some DT to the current kernel versions should fix up a bunch of the DT problems?
The size growth is due to the C side growing, yes. Some of it is the safety checking I warned about back at the time and the rest of it is just general growth (U-Boot is guilty of that all the time, so I can't really complain about some other project growing slightly).
Rebasing to the current kernel version adds a bunch of DT problems, some of which I hope would be fixed by re-syncing the base DT at least.
Fedora, as are many other distros, is actively retiring python2 due to it's upcoming EOL ~ 6 months from now. I've had to already rescue a couple of python2 packages to keep U-Boot building, there's an intention to actively remove python2 in Fedora 32 (scheduled for May 2020) which means anything post U-Boot 2019.10 (the version we're aiming for in F-31) will start to cause me big problems.
Maybe we could add this to migration plans like any of the DM subsytems?
So, looking again, the problem is that upstream, pylibfdt/setup.py is still using python2. So while a resync with upstream dtc might be good, it won't solve this issue. I'm not even sure why it doesn't work with Python3, other than that in January we added a patch to ensure we used Python2 and not 3.
Simon, I don't see your series that updated a bunch of stuff to work with Python 3 in master, but it's listed as Accepted in patchwork, do you know what happened? Thanks!
Hi Tom,
On Fri, 28 Jun 2019 at 06:51, Tom Rini trini@konsulko.com wrote:
On Fri, Jun 28, 2019 at 01:38:01PM +0100, Peter Robinson wrote:
With the EOL of python2 soon I've been looking at the Fedora U-Boot builds to see what it would take to move over to python3. There's a couple of issues building the bundled pylibfdt, the first is the Makefile hard codes python2, the second is that the generated libfdt_wrap.c doesn't seem to find the python3 version of Python.h (errors below).
It seems upstream now supports building pylibfdt with dtc 1.5.0 but I couldn't quite work out how this fits into the U-Boot bundled version. Is there plans to be able to support pylibfdt with python3?
Sounds like we need to run the normal kernel script to re-sync with upstream? Thanks!
Seems reasonable, I'll keep an eye out for a patch series to test, it's quite straight forward to test from my PoV.
It won't be any time soon, sadly. Updating to the same dtc in the kernel (so just v1.4.7+) causes both massive amount of new device tree warnings as well as several fail to link due to size growth problems.
I'm guessing the size problem is due to an increase in size of where libfdt is linked in and not due to pylibfdt. Would it make sense to have a feature branch with the rebase to make it easier to test/fix the issues? And rebasing some DT to the current kernel versions should fix up a bunch of the DT problems?
The size growth is due to the C side growing, yes. Some of it is the safety checking I warned about back at the time and the rest of it is just general growth (U-Boot is guilty of that all the time, so I can't really complain about some other project growing slightly).
Rebasing to the current kernel version adds a bunch of DT problems, some of which I hope would be fixed by re-syncing the base DT at least.
Fedora, as are many other distros, is actively retiring python2 due to it's upcoming EOL ~ 6 months from now. I've had to already rescue a couple of python2 packages to keep U-Boot building, there's an intention to actively remove python2 in Fedora 32 (scheduled for May 2020) which means anything post U-Boot 2019.10 (the version we're aiming for in F-31) will start to cause me big problems.
Maybe we could add this to migration plans like any of the DM subsytems?
So, looking again, the problem is that upstream, pylibfdt/setup.py is still using python2. So while a resync with upstream dtc might be good, it won't solve this issue. I'm not even sure why it doesn't work with Python3, other than that in January we added a patch to ensure we used Python2 and not 3.
Simon, I don't see your series that updated a bunch of stuff to work with Python 3 in master, but it's listed as Accepted in patchwork, do you know what happened? Thanks!
There's a patchwork bug that breaks my script for accepting bundles. So when I applied these patches to u-boot-dm/next I just replied 'accepted' to the cover letter emails.
Unfortunately libfdt added various security checks which blow out the code side. I saw it at the time and tried to suggest that David could make them optional, as did Tom, but he was not willing to do that. So for now we have a libfdt which we cannot use in U-Boot. It needs some work, unfortunately.
Re Python, pylibfdt supports Python 3. At least with upstream dtc I can build for both.
I've converted patman, binman, etc. to Python 3 and should be able to pull these patches in when the release finally goes out.
If no one screams I'd like to apply a patch to make these tools use Python 3 instead, in time for the next release (October?!). Given that the release after that might not be until next year, I might try to do that change in the same release. There is good test coverage for most of it.
Re the other Python scripts in U-Boot, there are a few that are used by builds. The make_fit_atf.py should move to binman, I think. Not sure about the synopsys ones.
Regades, Simon
On Tue, Jun 18, 2019 at 10:39:54AM +0100, Peter Robinson wrote:
Hi Simon,
With the EOL of python2 soon I've been looking at the Fedora U-Boot builds to see what it would take to move over to python3. There's a couple of issues building the bundled pylibfdt, the first is the Makefile hard codes python2, the second is that the generated libfdt_wrap.c doesn't seem to find the python3 version of Python.h (errors below).
It seems upstream now supports building pylibfdt with dtc 1.5.0 but I couldn't quite work out how this fits into the U-Boot bundled version. Is there plans to be able to support pylibfdt with python3?
Sounds like we need to run the normal kernel script to re-sync with upstream? Thanks!
Seems reasonable, I'll keep an eye out for a patch series to test, it's quite straight forward to test from my PoV.
It won't be any time soon, sadly. Updating to the same dtc in the kernel (so just v1.4.7+) causes both massive amount of new device tree warnings as well as several fail to link due to size growth problems.
For reference the kernel moved to v1.5.0-30-g702c1b6c0e73 in the 5.3 merge window.
Peter
Hi Peter,
On Wed, 24 Jul 2019 at 02:23, Peter Robinson pbrobinson@gmail.com wrote:
On Tue, Jun 18, 2019 at 10:39:54AM +0100, Peter Robinson wrote:
Hi Simon,
With the EOL of python2 soon I've been looking at the Fedora U-Boot builds to see what it would take to move over to python3. There's a couple of issues building the bundled pylibfdt, the first is the Makefile hard codes python2, the second is that the generated libfdt_wrap.c doesn't seem to find the python3 version of Python.h (errors below).
It seems upstream now supports building pylibfdt with dtc 1.5.0 but I couldn't quite work out how this fits into the U-Boot bundled version. Is there plans to be able to support pylibfdt with python3?
Sounds like we need to run the normal kernel script to re-sync with upstream? Thanks!
Seems reasonable, I'll keep an eye out for a patch series to test, it's quite straight forward to test from my PoV.
It won't be any time soon, sadly. Updating to the same dtc in the kernel (so just v1.4.7+) causes both massive amount of new device tree warnings as well as several fail to link due to size growth problems.
For reference the kernel moved to v1.5.0-30-g702c1b6c0e73 in the 5.3 merge window.
Also I sent a series for libfdt to reduce the size, as a first step to syncing up U-Boot again. It needs work, but I expect to get back to it next week.
Regards, SImon
Hi Simon,
With the EOL of python2 soon I've been looking at the Fedora U-Boot builds to see what it would take to move over to python3. There's a couple of issues building the bundled pylibfdt, the first is the Makefile hard codes python2, the second is that the generated libfdt_wrap.c doesn't seem to find the python3 version of Python.h (errors below).
It seems upstream now supports building pylibfdt with dtc 1.5.0 but I couldn't quite work out how this fits into the U-Boot bundled version. Is there plans to be able to support pylibfdt with python3?
Sounds like we need to run the normal kernel script to re-sync with upstream? Thanks!
Seems reasonable, I'll keep an eye out for a patch series to test, it's quite straight forward to test from my PoV.
It won't be any time soon, sadly. Updating to the same dtc in the kernel (so just v1.4.7+) causes both massive amount of new device tree warnings as well as several fail to link due to size growth problems.
For reference the kernel moved to v1.5.0-30-g702c1b6c0e73 in the 5.3 merge window.
Also I sent a series for libfdt to reduce the size, as a first step to syncing up U-Boot again. It needs work, but I expect to get back to it next week.
What's the latest on this?
Peter
Hi Peter,
On Wed, 28 Aug 2019 at 05:46, Peter Robinson pbrobinson@gmail.com wrote:
Hi Simon,
> With the EOL of python2 soon I've been looking at the Fedora U-Boot > builds to see what it would take to move over to python3. There's a > couple of issues building the bundled pylibfdt, the first is the > Makefile hard codes python2, the second is that the generated > libfdt_wrap.c doesn't seem to find the python3 version of Python.h > (errors below). > > It seems upstream now supports building pylibfdt with dtc 1.5.0 but I > couldn't quite work out how this fits into the U-Boot bundled version. > Is there plans to be able to support pylibfdt with python3?
Sounds like we need to run the normal kernel script to re-sync with upstream? Thanks!
Seems reasonable, I'll keep an eye out for a patch series to test, it's quite straight forward to test from my PoV.
It won't be any time soon, sadly. Updating to the same dtc in the kernel (so just v1.4.7+) causes both massive amount of new device tree warnings as well as several fail to link due to size growth problems.
For reference the kernel moved to v1.5.0-30-g702c1b6c0e73 in the 5.3 merge window.
Also I sent a series for libfdt to reduce the size, as a first step to syncing up U-Boot again. It needs work, but I expect to get back to it next week.
What's the latest on this?
No new progress but I just emailed David again about my pending question.
Regards, Simon
On Wed, Aug 28, 2019 at 07:44:11AM -0600, Simon Glass wrote:
Hi Peter,
On Wed, 28 Aug 2019 at 05:46, Peter Robinson pbrobinson@gmail.com wrote:
Hi Simon,
> > With the EOL of python2 soon I've been looking at the Fedora U-Boot > > builds to see what it would take to move over to python3. There's a > > couple of issues building the bundled pylibfdt, the first is the > > Makefile hard codes python2, the second is that the generated > > libfdt_wrap.c doesn't seem to find the python3 version of Python.h > > (errors below). > > > > It seems upstream now supports building pylibfdt with dtc 1.5.0 but I > > couldn't quite work out how this fits into the U-Boot bundled version. > > Is there plans to be able to support pylibfdt with python3? > > Sounds like we need to run the normal kernel script to re-sync with > upstream? Thanks!
Seems reasonable, I'll keep an eye out for a patch series to test, it's quite straight forward to test from my PoV.
It won't be any time soon, sadly. Updating to the same dtc in the kernel (so just v1.4.7+) causes both massive amount of new device tree warnings as well as several fail to link due to size growth problems.
For reference the kernel moved to v1.5.0-30-g702c1b6c0e73 in the 5.3 merge window.
Also I sent a series for libfdt to reduce the size, as a first step to syncing up U-Boot again. It needs work, but I expect to get back to it next week.
What's the latest on this?
No new progress but I just emailed David again about my pending question.
Should we perhaps sync including your proposed changes for now and re-sync once it's in? There's more than just Fedora folks unhappy about us being one of the last requires python2 things they support.
Hi Tom,
On Wed, 28 Aug 2019 at 07:47, Tom Rini trini@konsulko.com wrote:
On Wed, Aug 28, 2019 at 07:44:11AM -0600, Simon Glass wrote:
Hi Peter,
On Wed, 28 Aug 2019 at 05:46, Peter Robinson pbrobinson@gmail.com wrote:
Hi Simon,
> > > With the EOL of python2 soon I've been looking at the Fedora U-Boot > > > builds to see what it would take to move over to python3. There's a > > > couple of issues building the bundled pylibfdt, the first is the > > > Makefile hard codes python2, the second is that the generated > > > libfdt_wrap.c doesn't seem to find the python3 version of Python.h > > > (errors below). > > > > > > It seems upstream now supports building pylibfdt with dtc 1.5.0 but I > > > couldn't quite work out how this fits into the U-Boot bundled version. > > > Is there plans to be able to support pylibfdt with python3? > > > > Sounds like we need to run the normal kernel script to re-sync with > > upstream? Thanks! > > Seems reasonable, I'll keep an eye out for a patch series to test, > it's quite straight forward to test from my PoV.
It won't be any time soon, sadly. Updating to the same dtc in the kernel (so just v1.4.7+) causes both massive amount of new device tree warnings as well as several fail to link due to size growth problems.
For reference the kernel moved to v1.5.0-30-g702c1b6c0e73 in the 5.3 merge window.
Also I sent a series for libfdt to reduce the size, as a first step to syncing up U-Boot again. It needs work, but I expect to get back to it next week.
What's the latest on this?
No new progress but I just emailed David again about my pending question.
Should we perhaps sync including your proposed changes for now and re-sync once it's in? There's more than just Fedora folks unhappy about us being one of the last requires python2 things they support.
OK I can try this, but there is a bit of work before we can move to Python 3. I asked a month or two ago whether we should move to default Python 3 for this release, but I don't think I got an answer so did not focus on it. Then again, maybe I imagined it or missed it.
Regards, Simon
On Wed, Aug 28, 2019 at 10:11:16AM -0600, Simon Glass wrote:
Hi Tom,
On Wed, 28 Aug 2019 at 07:47, Tom Rini trini@konsulko.com wrote:
On Wed, Aug 28, 2019 at 07:44:11AM -0600, Simon Glass wrote:
Hi Peter,
On Wed, 28 Aug 2019 at 05:46, Peter Robinson pbrobinson@gmail.com wrote:
Hi Simon,
> > > > With the EOL of python2 soon I've been looking at the Fedora U-Boot > > > > builds to see what it would take to move over to python3. There's a > > > > couple of issues building the bundled pylibfdt, the first is the > > > > Makefile hard codes python2, the second is that the generated > > > > libfdt_wrap.c doesn't seem to find the python3 version of Python.h > > > > (errors below). > > > > > > > > It seems upstream now supports building pylibfdt with dtc 1.5.0 but I > > > > couldn't quite work out how this fits into the U-Boot bundled version. > > > > Is there plans to be able to support pylibfdt with python3? > > > > > > Sounds like we need to run the normal kernel script to re-sync with > > > upstream? Thanks! > > > > Seems reasonable, I'll keep an eye out for a patch series to test, > > it's quite straight forward to test from my PoV. > > It won't be any time soon, sadly. Updating to the same dtc in the > kernel (so just v1.4.7+) causes both massive amount of new device tree > warnings as well as several fail to link due to size growth problems.
For reference the kernel moved to v1.5.0-30-g702c1b6c0e73 in the 5.3 merge window.
Also I sent a series for libfdt to reduce the size, as a first step to syncing up U-Boot again. It needs work, but I expect to get back to it next week.
What's the latest on this?
No new progress but I just emailed David again about my pending question.
Should we perhaps sync including your proposed changes for now and re-sync once it's in? There's more than just Fedora folks unhappy about us being one of the last requires python2 things they support.
OK I can try this, but there is a bit of work before we can move to Python 3. I asked a month or two ago whether we should move to default Python 3 for this release, but I don't think I got an answer so did not focus on it. Then again, maybe I imagined it or missed it.
Hmm, I think I had taken your statement at the time as more of a declaration of intent than a question, sorry!
Hi Tom,
Ah OK. I was worried about doing it in one step. It might be too late now but will take a look when I get time and we can see if it is safe.
Regards, Simon
On Wed, 28 Aug 2019 at 18:19, Tom Rini trini@konsulko.com wrote:
On Wed, Aug 28, 2019 at 10:11:16AM -0600, Simon Glass wrote:
Hi Tom,
On Wed, 28 Aug 2019 at 07:47, Tom Rini trini@konsulko.com wrote:
On Wed, Aug 28, 2019 at 07:44:11AM -0600, Simon Glass wrote:
Hi Peter,
On Wed, 28 Aug 2019 at 05:46, Peter Robinson pbrobinson@gmail.com wrote:
Hi Simon,
> > > > > With the EOL of python2 soon I've been looking at the Fedora U-Boot > > > > > builds to see what it would take to move over to python3. There's a > > > > > couple of issues building the bundled pylibfdt, the first is the > > > > > Makefile hard codes python2, the second is that the generated > > > > > libfdt_wrap.c doesn't seem to find the python3 version of Python.h > > > > > (errors below). > > > > > > > > > > It seems upstream now supports building pylibfdt with dtc 1.5.0 but I > > > > > couldn't quite work out how this fits into the U-Boot bundled version. > > > > > Is there plans to be able to support pylibfdt with python3? > > > > > > > > Sounds like we need to run the normal kernel script to re-sync with > > > > upstream? Thanks! > > > > > > Seems reasonable, I'll keep an eye out for a patch series to test, > > > it's quite straight forward to test from my PoV. > > > > It won't be any time soon, sadly. Updating to the same dtc in the > > kernel (so just v1.4.7+) causes both massive amount of new device tree > > warnings as well as several fail to link due to size growth problems. > > For reference the kernel moved to v1.5.0-30-g702c1b6c0e73 in the 5.3 > merge window.
Also I sent a series for libfdt to reduce the size, as a first step to syncing up U-Boot again. It needs work, but I expect to get back to it next week.
What's the latest on this?
No new progress but I just emailed David again about my pending question.
Should we perhaps sync including your proposed changes for now and re-sync once it's in? There's more than just Fedora folks unhappy about us being one of the last requires python2 things they support.
OK I can try this, but there is a bit of work before we can move to Python 3. I asked a month or two ago whether we should move to default Python 3 for this release, but I don't think I got an answer so did not focus on it. Then again, maybe I imagined it or missed it.
Hmm, I think I had taken your statement at the time as more of a declaration of intent than a question, sorry!
-- Tom
Hi,
On Wed, 4 Sep 2019 at 08:36, Simon Glass sjg@chromium.org wrote:
Hi Tom,
Ah OK. I was worried about doing it in one step. It might be too late now but will take a look when I get time and we can see if it is safe.
Just to close this thread, I have now sent a v2 series which I think covers this, as well as a patch upstream to libfdt.
Regards, Simon
Regards, Simon
On Wed, 28 Aug 2019 at 18:19, Tom Rini trini@konsulko.com wrote:
On Wed, Aug 28, 2019 at 10:11:16AM -0600, Simon Glass wrote:
Hi Tom,
On Wed, 28 Aug 2019 at 07:47, Tom Rini trini@konsulko.com wrote:
On Wed, Aug 28, 2019 at 07:44:11AM -0600, Simon Glass wrote:
Hi Peter,
On Wed, 28 Aug 2019 at 05:46, Peter Robinson pbrobinson@gmail.com wrote:
Hi Simon,
> > > > > > With the EOL of python2 soon I've been looking at the Fedora U-Boot > > > > > > builds to see what it would take to move over to python3. There's a > > > > > > couple of issues building the bundled pylibfdt, the first is the > > > > > > Makefile hard codes python2, the second is that the generated > > > > > > libfdt_wrap.c doesn't seem to find the python3 version of Python.h > > > > > > (errors below). > > > > > > > > > > > > It seems upstream now supports building pylibfdt with dtc 1.5.0 but I > > > > > > couldn't quite work out how this fits into the U-Boot bundled version. > > > > > > Is there plans to be able to support pylibfdt with python3? > > > > > > > > > > Sounds like we need to run the normal kernel script to re-sync with > > > > > upstream? Thanks! > > > > > > > > Seems reasonable, I'll keep an eye out for a patch series to test, > > > > it's quite straight forward to test from my PoV. > > > > > > It won't be any time soon, sadly. Updating to the same dtc in the > > > kernel (so just v1.4.7+) causes both massive amount of new device tree > > > warnings as well as several fail to link due to size growth problems. > > > > For reference the kernel moved to v1.5.0-30-g702c1b6c0e73 in the 5.3 > > merge window. > > Also I sent a series for libfdt to reduce the size, as a first step to > syncing up U-Boot again. It needs work, but I expect to get back to it > next week.
What's the latest on this?
No new progress but I just emailed David again about my pending question.
Should we perhaps sync including your proposed changes for now and re-sync once it's in? There's more than just Fedora folks unhappy about us being one of the last requires python2 things they support.
OK I can try this, but there is a bit of work before we can move to Python 3. I asked a month or two ago whether we should move to default Python 3 for this release, but I don't think I got an answer so did not focus on it. Then again, maybe I imagined it or missed it.
Hmm, I think I had taken your statement at the time as more of a declaration of intent than a question, sorry!
-- Tom
participants (3)
-
Peter Robinson -
Simon Glass -
Tom Rini