Chris.. an RSB feature submission question at the bottom. Rest inlined.
On Tue, Jan 9, 2024 at 9:30 AM Michael G. South <mso...@msouth.org> wrote: > > > On Jan 8, 2024, at 10:53 , Joel Sherrill <j...@rtems.org> wrote: > > > > > > > > On Mon, Jan 8, 2024 at 10:13 AM Frank Kühndel < > 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 --mail-from=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 > > 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/ > > _______________________________________________ > > devel mailing list > > devel@rtems.org > > 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/ ) 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. 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. > > 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. 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 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 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. --joel > > Mike > > -- > > Michael South > mso...@msouth.org > LinkedIn: www.linkedin.com/in/msouth > > > >
_______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
