Re: installing Doorstop on macOS (for RTEMS use)
Hello Chris, I know that you don't like homebrew based solutions on macOS. The reasons for this are understandable. This is why I suggested to use the installer from python.org: https://lists.rtems.org/pipermail/users/2019-October/067192.html There are Python 3 installers available for macOS from python.org: https://www.python.org/downloads/mac-osx/ According to the pip project site it is already installed for Python 2 >=2.7.9 or Python 3 >=3.4: https://pip.pypa.io/en/stable/installing/ For example to install Python 3.7.4 on macOS you can use: https://www.python.org/ftp/python/3.7.4/python-3.7.4-macosx10.9.pkg I don't have a Mac and cannot test this. The Python 2.7 end of life is in 2 months and 20 days (January 1, 2020). The first Python 3 release was in 2008. Are there plans from Apple to update their Python support in Xcode to a state of the art version? Using the doorstop tool is not absolutely necessary right now. The file format is so easy, you can do almost everything with a text editor by hand (and scripts). What you cannot easily do is the calculation of the fingerprint, however, this can be done by the one who commits a patch. So, in case a Python 3 support with pipenv is on the Apple roadmap for the next year, this would make this easier. -- Sebastian Huber, embedded brains GmbH Address : Dornierstr. 4, D-82178 Puchheim, Germany Phone : +49 89 189 47 41-16 Fax : +49 89 189 47 41-09 E-Mail : sebastian.hu...@embedded-brains.de PGP : Public key available on request. Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG. ___ users mailing list users@rtems.org http://lists.rtems.org/mailman/listinfo/users
Re: Help request for potentially new host dependencies
On 9/10/19 3:37 am, Sebastian Huber wrote: > > How do you build the documentation with this base installation? > I used easy_install and have ... % sphinx-build --version Sphinx (sphinx-build) 1.3.4 I only build HTML on MacOS and then check any patches on another machine that can generate PDF. Chris ___ users mailing list users@rtems.org http://lists.rtems.org/mailman/listinfo/users
Re: installing Doorstop on macOS (for RTEMS use)
On Thu, Oct 10, 2019 at 4:26 PM Chris Johns wrote: > On 11/10/19 1:15 am, Andrew Butterfield wrote: > > Dear RTEMS Users, > > > > Sebastian Huber asked me to check the availability of Doorstop ( > https://pypi.org/project/doorstop/) for macOS, and to report my > experience on this mailing list. > > > > It is planned to use this for RTEMS requirements in the RTEMS > qualification project. > > > > It turned out to install really easily on my machine, in few 10s of > seconds > > > > > > > The following is a record of my system setup w.r.t. python, > > and the installation process. > > > > > > Hardware/OS: MacBook Pro, 2.8Ghz i7, 16GB ram, 500GB flash, macOS 10.14.6 > > > > python state: > > > > ~> which python > > /usr/local/bin/python > ^^ > Hmmm ... > > ~> python --version > > Python 2.7.16 > > > > ~> which python3 > > /usr/local/bin/python3 > > ~> python3 --version > > Python 3.7.4 > > > > ~> which pip > > /usr/local/bin/pip > > ~> pip --version > > pip 19.0.3 from /usr/local/lib/python2.7/site-packages/pip (python 2.7) > > > > ~> which pip3 > > /usr/local/bin/pip3 > > ~> pip3 --version > > pip 19.1.1 from /usr/local/lib/python3.7/site-packages/pip (python 3.7) > > > > Both pythons are 'brew' versions. Chris Johns said we should only use > > the native installed versions. > > I am actually saying this is currently all we need to build our tool set. I > cannot afford to have homebrew or macport packages installed because what I > might have installed at any point in time may effect the building of the > tools > and I would never know and if I step on a bug where is the problem. > > I do not have the time or resources to maintain our tool sets when > building with > homebrew and macports packages installed. If an issue is found is the > problem in > the tools or an installed package. I would need to determine which part > and look > for a solution. I do not want to become a Mac package maintainer or a MacOS > expert in a wide number of open source packages. > > I have found the Xcode command line tools from Apple to be stable over a > number > of years and I have found Apple and GCC to be responsive to any issues I > raise. > I have raised a number of bugs with both parties and in each case I seem > to be > one of first to uncover them. > > > However other tools I may choose to used > > often need to be installed using 'brew' and you would be amazed how many > > of those have python as a (brew) dependency. > > This is one alternative and one that brings other often more complicated > issues. > > How do we managing building all the tools for all architectures making > sure they > build and work with any mix of installed packages at whatever versions they > have? Our mailing list has a number of posts about the RSB not building > tools on > MacOS and my first question is always "are any packages installed from > homebrew > or macports?" and it normally ends up being related. > > I have no idea how you would control and specify a set of suitable > packages for > homebrew or macports. I do know if you use a specific version of Xcode on a > specific version of MacOS you will end up with the same tool set I have > built > and tested. I think this is important and important for our users. > I'm a CentOS user and there is a parallel type of situation. I avoid using odd repositories and have resisted using the official "software collections" which include a newer Python. CentOS 7 ships by default with Python 2.7.5 and I will stay with that. Disclaimer: For Sphinx support, I use the Python 3 software collection. Sphinx's need for a newer Python is what drove me off CentOS 6. Sticking with base installs and official sources of packages keeps us as maintainers inline with what "real" users have. Large organization uses in the US are CentOS/RHEL users with strict security controls. Those are our corporate and scientific users. I try hard to suffer as much as they do. They can't just switch to Mint, FreeBSD, or install something from an odd repo. RTEMS isn't a hobby (or toy) project and most of its users are stuck in serious industrial settings. As core developers, we have to respect that and suffer along. --joel > > Chris > ___ > users mailing list > users@rtems.org > http://lists.rtems.org/mailman/listinfo/users > ___ users mailing list users@rtems.org http://lists.rtems.org/mailman/listinfo/users
Re: installing Doorstop on macOS (for RTEMS use)
On 11/10/19 1:15 am, Andrew Butterfield wrote: > Dear RTEMS Users, > > Sebastian Huber asked me to check the availability of Doorstop > (https://pypi.org/project/doorstop/) for macOS, and to report my experience > on this mailing list. > > It is planned to use this for RTEMS requirements in the RTEMS qualification > project. > > It turned out to install really easily on my machine, in few 10s of seconds > > The following is a record of my system setup w.r.t. python, > and the installation process. > > > Hardware/OS: MacBook Pro, 2.8Ghz i7, 16GB ram, 500GB flash, macOS 10.14.6 > > python state: > > ~> which python > /usr/local/bin/python ^^ Hmmm ... > ~> python --version > Python 2.7.16 > > ~> which python3 > /usr/local/bin/python3 > ~> python3 --version > Python 3.7.4 > > ~> which pip > /usr/local/bin/pip > ~> pip --version > pip 19.0.3 from /usr/local/lib/python2.7/site-packages/pip (python 2.7) > > ~> which pip3 > /usr/local/bin/pip3 > ~> pip3 --version > pip 19.1.1 from /usr/local/lib/python3.7/site-packages/pip (python 3.7) > > Both pythons are 'brew' versions. Chris Johns said we should only use > the native installed versions. I am actually saying this is currently all we need to build our tool set. I cannot afford to have homebrew or macport packages installed because what I might have installed at any point in time may effect the building of the tools and I would never know and if I step on a bug where is the problem. I do not have the time or resources to maintain our tool sets when building with homebrew and macports packages installed. If an issue is found is the problem in the tools or an installed package. I would need to determine which part and look for a solution. I do not want to become a Mac package maintainer or a MacOS expert in a wide number of open source packages. I have found the Xcode command line tools from Apple to be stable over a number of years and I have found Apple and GCC to be responsive to any issues I raise. I have raised a number of bugs with both parties and in each case I seem to be one of first to uncover them. > However other tools I may choose to used > often need to be installed using 'brew' and you would be amazed how many > of those have python as a (brew) dependency. This is one alternative and one that brings other often more complicated issues. How do we managing building all the tools for all architectures making sure they build and work with any mix of installed packages at whatever versions they have? Our mailing list has a number of posts about the RSB not building tools on MacOS and my first question is always "are any packages installed from homebrew or macports?" and it normally ends up being related. I have no idea how you would control and specify a set of suitable packages for homebrew or macports. I do know if you use a specific version of Xcode on a specific version of MacOS you will end up with the same tool set I have built and tested. I think this is important and important for our users. Chris ___ users mailing list users@rtems.org http://lists.rtems.org/mailman/listinfo/users
installing Doorstop on macOS (for RTEMS use)
Dear RTEMS Users, Sebastian Huber asked me to check the availability of Doorstop (https://pypi.org/project/doorstop/) for macOS, and to report my experience on this mailing list. It is planned to use this for RTEMS requirements in the RTEMS qualification project. It turned out to install really easily on my machine, in few 10s of seconds The following is a record of my system setup w.r.t. python, and the installation process. Hardware/OS: MacBook Pro, 2.8Ghz i7, 16GB ram, 500GB flash, macOS 10.14.6 python state: ~> which python /usr/local/bin/python ~> python --version Python 2.7.16 ~> which python3 /usr/local/bin/python3 ~> python3 --version Python 3.7.4 ~> which pip /usr/local/bin/pip ~> pip --version pip 19.0.3 from /usr/local/lib/python2.7/site-packages/pip (python 2.7) ~> which pip3 /usr/local/bin/pip3 ~> pip3 --version pip 19.1.1 from /usr/local/lib/python3.7/site-packages/pip (python 3.7) Both pythons are 'brew' versions. Chris Johns said we should only use the native installed versions. However other tools I may choose to used often need to be installed using 'brew' and you would be amazed how many of those have python as a (brew) dependency. Looking in /System/Library/Frameworks/Python.framework/Versions we find folders 2.3 2.5 2.6 2.7 Current Current contains 2.7.10 Attempt 1 - use the 'brew' versions >pip3 install doorstop --- log - Collecting doorstop Downloading https://files.pythonhosted.org/packages/d3/20/315248b287ee6b3055d23d02c00801a38f44a0baf4ebd225c63bf66c0812/doorstop-1.6-py3-none-any.whl (276kB) || 276kB 2.6MB/s Collecting Markdown<3,>=2 (from doorstop) Downloading https://files.pythonhosted.org/packages/6d/7d/488b90f470b96531a3f5788cf12a93332f543dbab13c423a5e7ce96a0493/Markdown-2.6.11-py2.py3-none-any.whl (78kB) || 81kB 20.2MB/s Collecting plantuml-markdown<4.0,>=3.0 (from doorstop) Downloading https://files.pythonhosted.org/packages/9a/62/f23ad5e2cf3b196d253cba258bc97862de3057d4861c52df485be11ca060/plantuml_markdown-3.1.3-py3-none-any.whl Requirement already satisfied: PyYAML<6.0,>=5.1 in /usr/local/lib/python3.7/site-packages (from doorstop) (5.1) Collecting openpyxl<3.0,>=2.6 (from doorstop) Downloading https://files.pythonhosted.org/packages/d6/26/eb28e975b7a37aad38d7ec4f7a0f652bdee6ecf36e6bd06f473c5af9b87b/openpyxl-2.6.4.tar.gz (173kB) || 174kB 33.4MB/s Collecting pyficache==0.3.1 (from doorstop) Downloading https://files.pythonhosted.org/packages/5a/97/859698b53eea27b92746105170417d881bfe99304626efc770d505323be4/pyficache-0.3.1.tar.gz Collecting mdx_outline<2.0.0,>=1.3.0 (from doorstop) Downloading https://files.pythonhosted.org/packages/01/88/2c978ced5a64a5fb6be8a788bac64e2cc5eaf603535ccec2b51cd98a388c/mdx_outline-1.3.0.tar.gz Collecting bottle==0.12.13 (from doorstop) Downloading https://files.pythonhosted.org/packages/bd/99/04dc59ced52a8261ee0f965a8968717a255ea84a36013e527944dbf3468c/bottle-0.12.13.tar.gz (70kB) || 71kB 20.0MB/s Collecting python-markdown-math==0.6 (from doorstop) Downloading https://files.pythonhosted.org/packages/7c/81/2c86570437821d77b90a6d939d54e11b507b71785850840a5e56d8febeca/python_markdown_math-0.6-py2.py3-none-any.whl Requirement already satisfied: requests<3,>=2 in /usr/local/lib/python3.7/site-packages (from doorstop) (2.22.0) Collecting plantuml (from plantuml-markdown<4.0,>=3.0->doorstop) Downloading https://files.pythonhosted.org/packages/1e/92/0754877e9f3752216717f53ef3c66b238ffaa4043402f4ecde1173c8d0d5/plantuml-0.2.1-py3-none-any.whl Collecting jdcal (from openpyxl<3.0,>=2.6->doorstop) Downloading https://files.pythonhosted.org/packages/f0/da/572cbc0bc582390480bbd7c4e93d14dc46079778ed915b505dc494b37c57/jdcal-1.4.1-py2.py3-none-any.whl Collecting et_xmlfile (from openpyxl<3.0,>=2.6->doorstop) Downloading https://files.pythonhosted.org/packages/22/28/a99c42aea746e18382ad9fb36f64c1c1f04216f41797f2f0fa567da11388/et_xmlfile-1.0.1.tar.gz Collecting coverage (from pyficache==0.3.1->doorstop) Downloading https://files.pythonhosted.org/packages/93/07/8302163cdbe2008441aa69f2119750110fde15ffd8a56a687311b143365a/coverage-4.5.4-cp37-cp37m-macosx_10_13_x86_64.whl (181kB) || 184kB 31.0MB/s Requirement already satisfied: pygments>=2.0 in /usr/local/lib/python3.7/site-packages (from pyficache==0.3.1->doorstop) (2.4.0) Requirement already satisfied: idna<2.9,>=2.5 in /usr/local/lib/python3.7/site-packages (from requests<3,>=2->doorstop) (2.8) Requirement already satisfied: certifi>=2017.4.17 in /usr/local/lib/python3.7/site-packages (from requests<3,>=2->doorstop) (2019.3.9) Requirement already satisfied: chardet<3.1.0,>=3.0.2 in /usr/local/lib/python3.7/site-packages (from requests<3,>=2->doorstop) (3.0.4) Requirement already satisfied: urllib3!=1.25.0,!=1.25.1,<1.26,>=1.21.1 in /usr/l
Re: File system deadlock troubleshooting
I’m fairly certain I’m running into this reported issue: https://devel.rtems.org/ticket/2792 Is there any status change on this? Is there a temporary workaround recovery procedure? I’m tempted to give the conditional wait a timeout. Sent from my iPhone > On Oct 9, 2019, at 23:05, Mathew Benson wrote: > > I enabled RTEMS_RAMDISK_TRACE. That appears to be dead code in my build. > Change didn't do anything. I checked the symbol table and none of those > functions are in my build. The actual ram disk driver is in a different > location and didn't have a trace equivalent. Is there another way to get a > trace from ramdisk? > >> On Wed, Oct 9, 2019 at 6:01 PM Chris Johns wrote: >> On 10/10/19 6:23 am, Mathew Benson wrote: >> > I added the tracerfs command to the shell. Not sure why that's not already >> > there. >> >> The command is not in the shell directory and I did not add it to the config >> for >> the shell. Maybe is should be. I am not sure. >> >> > I enabled all with "tracerfs set all". It took a while, but I did run >> > into the problem. The end of the log is below. Can you see what the >> > kernel is >> > trying to do and what its waiting on from this? It's going to be a while, >> > reading through kernel code, to understand exactly what this means. >> >> Thank you for this. I am travelling from tomorrow for a while. I will try and >> have a look while in transit if I can. >> >> Chris > > > -- > Mathew Benson > CEO | Chief Engineer > Windhover Labs, LLC > 832-640-4018 > > > www.windhoverlabs.com > ___ users mailing list users@rtems.org http://lists.rtems.org/mailman/listinfo/users