CentOS 8 - no python

Wed Jan 10 01:47:56 UTC 2024

On 10/1/2024 3:38 am, Joel Sherrill wrote:
> Chris.. an RSB feature submission question at the bottom.

If virtual env is possible then I recommend that. Anything the RSB does breaks
when `waf` runs as it wants `python`.

> Rest inlined.

Same

> 
> On Tue, Jan 9, 2024 at 9:30 AM Michael G. South <msouth at msouth.org
> <mailto:msouth at msouth.org>> wrote:
> 
> 
>     > On Jan 8, 2024, at 10:53 , Joel Sherrill <joel at rtems.org
>     <mailto:joel at rtems.org>> wrote:
>     >
>     >
>     >
>     > On Mon, Jan 8, 2024 at 10:13 AM Frank Kühndel
>     <frank.kuehndel at embedded-brains.de
>     <mailto:frank.kuehndel at embedded-brains.de>> wrote:
>     > Hi Joel,
>     >
>     > have a great 2024!
>     >
>     > On 12/24/23 22:16, Joel Sherrill wrote:
>     >  > Hi
>     >  >
>     >  > Trying to bring up Coverity builds on a Centos 8 machine, I ran into
>     > this:
>     >  >
>     >  > + ../source-builder/sb-set-builder --log=l-sparc.txt
>     >  > --prefix=/home/joel/rtems-cron-coverity/tools/6 --mail --mail-to=
>     >  > build at rtems.org <mailto:build at rtems.org>  --mail-from=joel at rtems.org
>     <mailto:joel at rtems.org> 6/rtems-sparc
>     >  >
>     >  > /usr/bin/env: ‘python’: No such file or directory
>     >  >
>     >  > There is, in fact, no python executable -- there is python2 and python3.
>     >  >
>     >  > Suggestions other than adding a symlink?
>     >
>     > In RHEL 9.3 there exists the package python-unversioned-command which
>     > creates a "python" command for "python3". I do not know whether it
>     > exists in CentOS 8.
> 
> 
> It appears to exist via Google but this was also suggested:
> 
> $ alternatives --set python /usr/bin/python3
> 
> Or select Python 2. 
> 
> FWIW I think CentOS 8 is the last RHEL version to include Python 2.
>  
> 
>     >
>     > Thanks. It looks like CentOS 8 has that package but the computer is down
>     right now.
>     >
>     > It is on a UPS that needs a new battery. So not much use. :(
>     >
>     > --joel
>     >
>     > Greetings,
>     > Frank
>     >
>     > --
>     > embedded brains GmbH & Co. KG
>     > Herr Frank KÜHNDEL
>     > Dornierstr. 4
>     > 82178 Puchheim
>     > Germany
>     > email: frank.kuehndel at embedded-brains.de
>     <mailto:frank.kuehndel at embedded-brains.de>
>     > phone:  +49-89-18 94 741 - 23
>     > mobile: +49-176-15 22 06 - 11
>     >
>     > Registergericht: Amtsgericht München
>     > Registernummer: HRA 117265
>     > Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
>     > Unsere Datenschutzerklärung finden Sie hier:
>     > https://embedded-brains.de/datenschutzerklaerung/
>     <https://embedded-brains.de/datenschutzerklaerung/>
>     > _______________________________________________
>     > devel mailing list
>     > devel at rtems.org <mailto:devel at rtems.org>
>     > http://lists.rtems.org/mailman/listinfo/devel
>     <http://lists.rtems.org/mailman/listinfo/devel>
> 
>     This might become an ongoing problem. As distros drop Python 2 support they
>     have a tendency to also just drop “python” -> “pythonX” links. The Official
>     Word ( https://peps.python.org/pep-0394/ <https://peps.python.org/pep-0394/>
>     ) is kind of weak-kneed about how “Python script publishers” should approach
>     the issue, but basically says to either use a virtual environment, or figure
>     out whether “python” or “python3” works and then use that.
> 
> 
> Yep. I think the Python folks really made a mess with this transition. And there
> are bumps in the 3.x series where things change. It is just messy.

Maybe put there are multiple parties doing things.

> 
> In my standards work, I remind folks that if we need to fix/change something
> that we should find a way to fix the issue so the fewest set of users are
> impacted. The Python authors are a much smaller subset than Python users. This
> is just whining I suppose. 

Please use venv.

>     Does source builder still work with Python 2? I seem to recall the answer is
>     “no,” that the gcc (or maybe lib?) build breaks with p2. If it does still
>     work, is that an explicit goal for SB, and are there regression tests to
>     avoid bit rot?
> 
> 
> User facing tools like the RSBand waf  are supposed to work with Python 2 or 3.
> OAR actively tests on CentOS 7 which is Python 2.

There is requirement to have 3 to build GDB so in effect python2 support has
been dropped. I think you updated to GDB to cause this.

> But.. developer facing tools can require Python 3.  The documentation uses
> Sphinx which requires Python 3. I had a virtual environment on CentOS 7 to build
> this. CentOS/RHEL have a concept of software collections to let you get newer
> tools like gcc or Python.
> 
> At some point, I assume Python 2 will become rare enough in the user community
> that we won't care to support it any longer. Guessing, I would suspect RTEMS 6
> could be the last major release to worry about Python 2.
> 
> 
>     As an aside, SB isn’t building on macOS Catalina for a similarish reason;
>     there’s a path issue with the default Apple Python install, same issue with
>     the official python.org <http://python.org>  macOS bundles, and Homebrew
>     patched it but no longer supports an old-enough python3 version that doesn’t
>     break the GCC builds for other reasons.
> 
>     I think “the right way” would be to have sb/linux.py figure out the correct
>     path for Python and pass that to the rest of the build. Though a lot more
>     work in this particular case.
> 
>     Would you be interested in a patch to linux.py/rest <http://linux.py/rest>
>     of SB that implemented such a thing?
> 
> 
> I cc'ed Chris about this. I expect it would be appreciated. If he doesn't reply
> to this email thread,  please just email the patch to devel@ and let's see the
> reaction.

Please use venv and may the Linux doco needs to be updated like I did for MacOS
to detail using venv.

Chris