On 20/08/2021 18:24, Gedare Bloom wrote:
On Fri, Aug 20, 2021 at 2:02 AM Chris Johns <chr...@rtems.org> wrote:
On 20/8/21 5:42 pm, Christian MAUDERER wrote:
Am 20.08.21 um 09:02 schrieb Chris Johns:
On 20/8/21 4:48 pm, Christian MAUDERER wrote:
Hello,
Am 20.08.21 um 03:49 schrieb Chris Johns:
On 20/8/21 3:16 am, Joel Sherrill wrote:
On Thu, Aug 19, 2021 at 11:51 AM Gedare Bloom <ged...@rtems.org> wrote:
I have no problem with this. I think it is sensible to look for
python3 before python2. At some point we'll have to stop looking for
python2 :)
That is further in the future than I would have thought based on the
CentOS project changes. I still see user organizations with no plans
to move off CentOS 7. It will receive maintenance updates through
2024-06-30.
But on CentOS 7, I can load a Python 3.6, newer GCC, etc. so it isn't
that bad. I had to test something on a true 32-bit distribution this week
and even CentOS 7 (i386) wasn't as painful as I expected to setup.
There will come a time when a change made cannot be easily tested by us on
python2 and that will in effect end our support. We are not there yet.
STOP.
Please do not do this again.
That discussion took a wrong direction. We discussed deprecating python2 a
few times and I know that we will not do it before the big long living
distributions drop it. I can live with that and I don't want to re-start this
discussion with this patch.
If Joel feels the need to make this statement he can and he has more than earned
the right to do so. His work and those he supports is important.
Sorry, I didn't want to offend you, Joel or Gedare.
I had that with discussions before that the original idea (here: giving priority
to python3 over python2 when building gdb) started to be buried by a similar but
slightly different one which has been already discussed multiple times (here:
deprecating python2). I wanted to avoid that.
I should have worded that different. I'm sorry if I have offended you, Joel or
Gedare or anyone else.
Thanks and none taken. I am clear on the focus of your posts so it is ok. :)
It would be fine without the STOP. Totally acceptable to express your
opinion and request that we not bikeshed your patch, we just want to
keep the tone of the list in the right direction which we all know can
be challenging in virtual, international communications. We understand
the intent here, but we just want to make sure to keep the list
friendly to all (who may lack some of our context). Thanks!
Yes, again: sorry. "Let's deprecate python2" is a dangerous topic that
has the tendency to start really long discussions. I pannicked a bit
there that it would hide the topic that I had in mind. I used the wrong
tone to express that. I'll try to be more careful in the future.
On Thu, Aug 19, 2021 at 3:24 AM Christian MAUDERER
<christian.maude...@embedded-brains.de> wrote:
PS: I had the problem on the 5 branch of RTEMS source builder. I think
we should apply a patch to both: master and the 5 branch.
Am 19.08.21 um 10:34 schrieb Christian Mauderer:
More and more systems stop shipping python2. So we should start to
prefer python3 over python2. For building gdb it is not only necessary
to have a python binary installed, but also the matching python-devel
packet. On a lot of hosts that will now be more often python3-devel
and not python2-devel.
---
Note: Please see that patch more as an suggestion / base for
discussion. I'm open to better solutions.
My problem that triggered this patch was a build of a toolchain on a
github CI/CD system that has been originally set up by one of our
users (see [1] for the log). It seems that on the "macos-latest"
machines a python2 is installed but no python2 headers are found.
I have just built the latest RSB master GDB on a fully updated MacOS (Big Sur):
config: tools/rtems-gdb-10.cfg
package: arm-rtems6-gdb-7ab567f-x86_64-apple-darwin20.1.0-1
building: arm-rtems6-gdb-7ab567f-x86_64-apple-darwin20.1.0-1
sizes: arm-rtems6-gdb-7ab567f-x86_64-apple-darwin20.1.0-1: 629.086MB
(installed:
19.586MB)
cleaning: arm-rtems6-gdb-7ab567f-x86_64-apple-darwin20.1.0-1
reporting: tools/rtems-gdb-10.cfg ->
arm-rtems6-gdb-7ab567f-x86_64-apple-darwin20.1.0-1.txt
reporting: tools/rtems-gdb-10.cfg ->
arm-rtems6-gdb-7ab567f-x86_64-apple-darwin20.1.0-1.xml
I support the latest MacOS with Xcode and have a dedicated Mac machine that
tracks the current RSB. It had wedged itself and I have cleared that so it is
now building the latest.
So do I understand that correct: This is a "clean" Mac with no additional python
installs or similar and it worked? What python versions are available on this
this machine?
It is working for me and I have not looked into it any more.
If I did understand you correctly, it seems that github has made some odd
choices about their default config for the macos-latest machines. They seem to
have python2 but no devel headers.
You will need to raise that with them.
Yes, of course. I didn't want to raise it as a problem here. It was more a
statement than a question or a complain.
Yeap, I understand.
Homebrew - which could be used earlier on MacOS to install the
necessary headers - dropped the python@2 packet.
Homebrew and MacPorts are a personal choice and I am fine with users heading
down this path however it is beyond this project's scope to support those
frameworks. I have posted the reasons in the past and the MacPorts maintainers
are aware of those reasons.
No problem. I'm not a Mac user so I don't really have an opinion or experience
what is the right way to install the requirements on a MacOS system. I'm really
happy that it just works most of the time (a lot of it most likely thanks to
you).
Actually, all I do is politely raise issues with those that do the real work. I
think Homebrew and Macports are awesome projects but they bring in packages and
with that issues and when our users have a mix of package versions the level of
complexity exploded. I have no capacity to cover this.
So it seems that on a
modern MacOS there is no possibility to get python2 headers.
As I have just built GDB this does not appear to be true. I would prefer we do
not overreach until we all agree there is a problem. If there is an issue I
would raise the problem in Apple'd developer bug system. I have raised a number
of issues over the years and to Apple's credit they have dealt with them all.
Maybe I haven't made it enough clear: I had to do some guess work here. I have
put it here as a basis for discussion. I'm completely OK if you can tell me that
my conclusion has been wrong.
I think the switch is a good idea. It may break something things but that is
also OK because we can then fix them well before a release.
It seems that it really is just an odd choice of defaults on github then.
Sorry, again I am not sure.
Found the documentation on github. If someone is interested:
https://github.com/actions/virtual-environments/blob/main/images/macos/macos-10.15-Readme.md
https://github.com/actions/virtual-environments/blob/main/images/macos/macos-11-Readme.md
So all github macOS runners have some Python 2.7 installed.
Big Sur still ships Python2.
FYI the MacOS build reports have started to appear on the build list.
If
python2 is still installed on the machine (for whatever reason), it is
not possible to successfully use RTEMS source builder to build a gdb.
If python3 is preferred instead, that should solve the problem.
The change seems sensible.
I think even if a clean MacOS doesn't have a problem (like I assumed), I still
think it would be a good idea to prefer python3 if it is available. We are not
talking about preferring it in our python-scripts but only to build gdb.
I agree, lets switch.
Thanks.
Do I have a "go" to:
- create tickets for 5 and 6
("RSB: Prefer python3 to build gdb if it is there" with some explanation in
the description)
The 6 patch is OK to push when you are ready.
Agreed for 6.
I will do some tests on 5 like Chris suggested. If something comes up
there, it is nearly sure that it is a problem for 6 too. So I'll wait
for the results of these tests.
- push that patch to 5 and 6 and close the tickets with it
The 5 needs to be check on Windows before we switch. I think it will be fine but
it is a release hurdle if it does not as it makes a dot release a major piece of
work.
Do you need a hand with Windows? If so please ask.
What would you see as the more difficult Windows build environment that should
be tested? We have MSYS2 and Cygwin in our documentation. Do you test both on
releases?
I only test MSYS2 and on real hardware with Windows 10. Cygwin is important to
Joel and DEOS and so I leave this task to him.
+1 @Joel
Also given our relationship with cygwin via newlib, I think it is a
good platform for us to be supporting to some extent. But as always,
time is the enemy.
Started to test both (MSYS2 and Cygwin) and I start to suspect that our
manual needs some minor updates. I'm taking notes ...
Best regards
Christian
Note that at the moment I only tried it on my OpenSUSE-Linux machine.
For that I made sure that I have python2 and python3 installed but no
python-devel (which is python2 on OpenSUSE). Earlier I know that I
needed python-devel to build gdb. With this patch, I can build with
only python3-devel.
I'll try to add that patch to the CI too to see whether it works on
MacOS. But I'm a bit unsure what other problems this patch could
trigger and therefore I want to start a discussion early.
Best regards
Christian
[1] https://github.com/grisp/grisp2-rtems-toolchain/runs/3362717606
I am looking forward to their hardware being shipped.
I think there will be an official update soon. You most likely noted that the
CI-run belongs to a pull request that updates the toolchain to work with the
first final board that had been on my desk this week.
Great and no I had not looked. Sorry, deep in libbsd (again and eval_path grr).
Good luck with the libbsd problems.
Thanks.
Chris
_______________________________________________
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
_______________________________________________
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
