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
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
Re: Help request for potentially new host dependencies
On 9/10/19 10:02 am, Chris Johns wrote: > On 9/10/19 3:31 am, Sebastian Huber wrote: >> - Am 8. Okt 2019 um 4:04 schrieb Jonathan Brandmeyer >> jbrandme...@planetiq.com: >> >>> On Mon, Oct 7, 2019 at 12:32 AM Sebastian Huber >>> wrote: Hello, I need your help to figure out if some host tools which I would like to use for the RTEMS BSP build and development are widely supported on the host platforms of all RTEMS users. The current build system is based on Autoconf and Automake. I would like to replace it with a Python based build system (waf) which is aimed to be faster and easier to maintain. >>> >>> Do you need to do anything special to get waf to use all of the build >>> machine's resources? Waf was only capable of keeping about ~30% of a >>> 16-core/32-thread workstation's resources busy during the rtems-libbsd >>> build at any time, even during the embarrassingly parallel stages of >>> the build. >> >> Yes, I noticed this too in the libbsd build. I had no time to figure out why >> it is not able to keep all processors fully loaded. > > I checked and saw the same thing. I used the -j option to double the number of > parallel processes and the load was still not 100% so I am not sure where the > issue is. One of the python processes or threads runs at 100% which does not > seem right to me. Thanks to some help from Jonathan and Thomas I think I have a fix. I will need to package it up and I will post it on devel when I have something. FYI the issue was the time to scan dependences in Python. Using gcc drops the build time from 1m25s to 1m14s and top shows 0% idle. Chris ___ users mailing list users@rtems.org http://lists.rtems.org/mailman/listinfo/users
