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 <mso...@msouth.org > <mailto:mso...@msouth.org>> wrote: > > > > On Jan 8, 2024, at 10:53 , Joel Sherrill <j...@rtems.org > <mailto:j...@rtems.org>> wrote: > > > > > > > > On Mon, Jan 8, 2024 at 10:13 AM Frank Kühndel > <frank.kuehn...@embedded-brains.de > <mailto:frank.kuehn...@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= > > > bu...@rtems.org <mailto:bu...@rtems.org> --mail-from=j...@rtems.org > <mailto:j...@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.kuehn...@embedded-brains.de > <mailto:frank.kuehn...@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@rtems.org <mailto:devel@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 _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
