<div dir="auto"><div><br><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Nov 25, 2019, 6:30 PM Chris Johns <<a href="mailto:chrisj@rtems.org">chrisj@rtems.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 26/11/19 10:46 am, Joel Sherrill wrote:<br>
> On Mon, Nov 25, 2019 at 5:28 PM Chris Johns <<a href="mailto:chrisj@rtems.org" target="_blank" rel="noreferrer">chrisj@rtems.org</a><br>
> <mailto:<a href="mailto:chrisj@rtems.org" target="_blank" rel="noreferrer">chrisj@rtems.org</a>>> wrote:<br>
>     On 26/11/19 9:57 am, Joel Sherrill wrote:<br>
>     > On Mon, Nov 25, 2019 at 3:19 PM Chris Johns <<a href="mailto:chrisj@rtems.org" target="_blank" rel="noreferrer">chrisj@rtems.org</a><br>
>     <mailto:<a href="mailto:chrisj@rtems.org" target="_blank" rel="noreferrer">chrisj@rtems.org</a>><br>
>     > <mailto:<a href="mailto:chrisj@rtems.org" target="_blank" rel="noreferrer">chrisj@rtems.org</a> <mailto:<a href="mailto:chrisj@rtems.org" target="_blank" rel="noreferrer">chrisj@rtems.org</a>>>> wrote:<br>
>     ><br>
>     >     On 26/11/19 8:05 am, Joel Sherrill wrote:<br>
>     >     > On Mon, Nov 25, 2019 at 2:12 AM Sebastian Huber<br>
>     >     > <<a href="mailto:sebastian.huber@embedded-brains.de" target="_blank" rel="noreferrer">sebastian.huber@embedded-brains.de</a><br>
>     <mailto:<a href="mailto:sebastian.huber@embedded-brains.de" target="_blank" rel="noreferrer">sebastian.huber@embedded-brains.de</a>><br>
>     >     <mailto:<a href="mailto:sebastian.huber@embedded-brains.de" target="_blank" rel="noreferrer">sebastian.huber@embedded-brains.de</a><br>
>     <mailto:<a href="mailto:sebastian.huber@embedded-brains.de" target="_blank" rel="noreferrer">sebastian.huber@embedded-brains.de</a>>><br>
>     >     <mailto:<a href="mailto:sebastian.huber@embedded-brains.de" target="_blank" rel="noreferrer">sebastian.huber@embedded-brains.de</a><br>
>     <mailto:<a href="mailto:sebastian.huber@embedded-brains.de" target="_blank" rel="noreferrer">sebastian.huber@embedded-brains.de</a>><br>
>     >     <mailto:<a href="mailto:sebastian.huber@embedded-brains.de" target="_blank" rel="noreferrer">sebastian.huber@embedded-brains.de</a><br>
>     <mailto:<a href="mailto:sebastian.huber@embedded-brains.de" target="_blank" rel="noreferrer">sebastian.huber@embedded-brains.de</a>>>>><br>
>     >     > wrote:<br>
>     >     ><br>
>     >     >     On 25/11/2019 08:55, Chris Johns wrote:<br>
>     >     >     ><br>
>     >     >     > On 25/11/19 5:28 pm, Sebastian Huber wrote:<br>
>     >     >     >><br>
>     >     >     >> On 24/11/2019 23:25, Chris Johns wrote:<br>
>     >     >     >>>>> Should there be a note or something about waf needing<br>
>     python and we<br>
>     >     >     recommend<br>
>     >     >     >>>>> python3? Plus waf needs a `python` installed and not just<br>
>     >     `python2` or<br>
>     >     >     >>>>> `python3`?<br>
>     >     >     >>>> I think this belongs to the Host Computer section. The quick<br>
>     >     start uses the<br>
>     >     >     >>>> RSB, so if you managed to build the tools, you must have a<br>
>     >     working Python.<br>
>     >     >     >>>> The RSB uses Python and the RTEMS Tools use waf.<br>
>     >     >     >>> The RSB can use python2 or python3 without a python. What<br>
>     about a note<br>
>     >     >     to say<br>
>     >     >     >>> ... "Waf uses python and you need to make this command available<br>
>     >     on your<br>
>     >     >     system".<br>
>     >     >     >> Now I am a bit confused. I thought every UNIX-like system<br>
>     provides a<br>
>     >     >     >><br>
>     >     >     >> #!/usr/bin/env python<br>
>     >     >     >><br>
>     >     >     >> which maps to Python 2 or 3?<br>
>     >     >     >><br>
>     >     >     > Apparently on some distros the python executable is not<br>
>     automatically<br>
>     >     >     installed<br>
>     >     >     > with a suitable python2 or python3. I am not aware of the<br>
>     specifics of<br>
>     >     >     this but<br>
>     >     >     > it was raised as an issue that I fixed in the RSB:<br>
>     >     >     ><br>
>     >     >     > <a href="https://devel.rtems.org/ticket/3537" rel="noreferrer noreferrer" target="_blank">https://devel.rtems.org/ticket/3537</a><br>
>     >     ><br>
>     >     >     I have never seen a system in which<br>
>     >     ><br>
>     >     >     #!/usr/bin/env python2<br>
>     >     ><br>
>     >     >     or<br>
>     >     ><br>
>     >     >     #!/usr/bin/env python3<br>
>     >     ><br>
>     >     >     works, but not<br>
>     >     ><br>
>     >     >     #!/usr/bin/env python<br>
>     ><br>
>     >     I agree however this is the post from Joel about a class he held ...<br>
>     ><br>
>     >     <a href="https://lists.rtems.org/pipermail/devel/2018-October/023150.html" rel="noreferrer noreferrer" target="_blank">https://lists.rtems.org/pipermail/devel/2018-October/023150.html</a><br>
>     ><br>
>     >     and I posted the change here ...<br>
>     ><br>
>     >     <a href="https://lists.rtems.org/pipermail/devel/2018-October/023296.html" rel="noreferrer noreferrer" target="_blank">https://lists.rtems.org/pipermail/devel/2018-October/023296.html</a><br>
>     ><br>
>     >     >     How many Python scripts would stop to work in this case?<br>
>     However, the<br>
>     >     >     availability of a python command is not mandatory according to:<br>
>     >     ><br>
>     >     >     <a href="https://www.python.org/dev/peps/pep-0394/" rel="noreferrer noreferrer" target="_blank">https://www.python.org/dev/peps/pep-0394/</a><br>
>     ><br>
>     >     I am aware of this and I support it however Linux distros seems to<br>
>     feel there<br>
>     >     are cases for exceptions, we have this one and there is also pax.<br>
>     ><br>
>     >     The pax and this python case are similar, do we say "We are correct,<br>
>     fix your<br>
>     >     host or raise a bug on your distro" or do we attempt to smooth over<br>
>     the cracks<br>
>     >     and attempt to just work?<br>
>     ><br>
>     >     In the case of ubuntu, maybe someone with some experience with it can<br>
>     see what<br>
>     >     is needed and update the documentation?<br>
>     ><br>
>     >     >     I think we should note in the "Host Computer" section that a<br>
>     "python"<br>
>     >     >     command is mandatory for RTEMS and remove the RSB extra stuff.<br>
>     ><br>
>     >     The argument was presented to me that the RSB should just work even in<br>
>     this case<br>
>     >     and so that is what I did. I am fine to remove that support, it is an<br>
>     >     average hack.<br>
>     ><br>
>     >     > Chris can answer to that.<br>
>     ><br>
>     >     Done.<br>
>     ><br>
>     >     > But on Centos 7, we have:<br>
>     >     ><br>
>     >     > $ type python<br>
>     >     > python is /usr/bin/python<br>
>     >     > $ python --version<br>
>     >     > Python 2.7.5<br>
>     >     > $ type python2<br>
>     >     > python2 is /usr/bin/python2<br>
>     >     > $ type python3<br>
>     >     > bash: type: python3: not found<br>
>     >     > $ env python<br>
>     >     > Python 2.7.5 (default, Aug  7 2019, 00:51:29)<br>
>     >     > [GCC 4.8.5 20150623 (Red Hat 4.8.5-39)] on linux2<br>
>     >     > Type "help", "copyright", "credits" or "license" for more information.<br>
>     >     >>>> <br>
>     >     ><br>
>     >     > and if I activate the SCL for Python 3:<br>
>     >     ><br>
>     >     > $ scl enable rh-python36 bash                                      <br>
>          <br>
>     >          <br>
>     >     >                                                                    <br>
>              <br>
>     >     > [joel@localhost rtems-work]$ type python                            <br>
>          <br>
>     >          <br>
>     >     >                                                                    <br>
>              <br>
>     >     > python is /opt/rh/rh-python36/root/usr/bin/python                  <br>
>          <br>
>     >          <br>
>     >     >                                                                    <br>
>              <br>
>     >     > [joel@localhost rtems-work]$ python --version                      <br>
>          <br>
>     >          <br>
>     >     >                                                                    <br>
>              <br>
>     >     > Python 3.6.3                                                <br>
>     ><br>
>     >     And on ubuntu? The original post was about that distro.<br>
>     ><br>
>     ><br>
>     >  Welcome to Ubuntu 18.04.3 LTS (GNU/Linux 4.15.0-66-generic x86_64)      <br>
>          <br>
>     >                                        <br>
>     > ....<br>
>     > $ type python<br>
>     > python is /usr/bin/python<br>
>     > $ python --version<br>
>     > Python 2.7.15+<br>
>     > $ env python<br>
>     > Python 2.7.15+ (default, Oct  7 2019, 17:39:04)<br>
>     > [GCC 7.4.0] on linux2<br>
>     > Type "help", "copyright", "credits" or "license" for more information.<br>
>     >>>> <br>
>     > $ python2<br>
>     > Python 2.7.15+ (default, Oct  7 2019, 17:39:04)<br>
>     > [GCC 7.4.0] on linux2<br>
>     > Type "help", "copyright", "credits" or "license" for more information.<br>
>     >>>><br>
>     > $ python3<br>
>     > Python 3.6.8 (default, Oct  7 2019, 12:59:55)<br>
>     > [GCC 8.3.0] on linux<br>
>     > Type "help", "copyright", "credits" or "license" for more information.<br>
>     >>>><br>
> <br>
>     I am sorry but I am not sure how this helps the discussion? Your original post<br>
>     last year raised the issue of no python being installed on ubuntu and that lead<br>
>     to the change in the RSB.<br>
> <br>
> I wish I had included the Ubuntu version in the original post. msys2 and cygwin<br>
> always seem to reflect the day you install them to me. The best I could do is<br>
> report on the msys2 on my laptop and the Ubuntu we use for testing appear to be OK. <br>
> <br>
> I have no way to reproduce what happened in the class I sent an email about.<br>
> I assure you that it happened though.<br>
<br>
I am sure it did happen. I reported at the time the python symlink is part of<br>
the python-minimal package. I have no idea how this sits in that distro's<br>
packaging structure and how it can happen.<br>
<br>
What does you version show for ...<br>
<br>
 apt-file search /usr/bin/python | grep "/usr/bin/python$"<br>
<br>
... ?<br>
<br>
> On the master, I suppose assuming "python" exists is OK as an experiment as long<br>
> as it is assumed it may be Python2 or Python3. We should be prepared for someone<br>
> to have the situation where it doesn't work out though and need to revisit this.<br>
<br>
Are you saying it is OK to remove the support I added from the RSB and rtems-tools?<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">I am saying I have no system to prove it right now. I think it is still needed but can't reproduce it.</div><div dir="auto"><br></div><div dir="auto">I don't like removing it quietly without a replacement to detect and report something to a user that X occurred, please report so we know what hosts this happens on.</div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Chris<br>
</blockquote></div></div></div>