Consider hosting rtems toolchain build-dependencies on GitHub

[lwehmeier]

It appears that some patches the rtems toolchain build process depends on are hosted on an unreliable server. Maybe consider hosting them GitHub or removing them altogether as they appear to be irrelevant for the ARM toolchain build?

grisp-software/build/build.sh

[...]
config: tools/rtems-gdb-8.0.1-1.cfg
package: arm-rtems5-gdb-8.0.1-x86_64-linux-gnu-1
download: http://ftp.gnu.org/gnu/gdb/gdb-8.0.1.tar.xz -> sources/gdb-8.0.1.tar.xz
downloading: sources/gdb-8.0.1.tar.xz - 18.7MB of 18.7MB (100%)
download: https://gaisler.org/gdb/gdb-8.0.1-sis-leon2-leon3.diff -> patches/gdb-8.0.1-sis-leon2-leon3.diff
download: https://gaisler.org/gdb/gdb-8.0.1-sis-leon2-leon3.diff: error: <urlopen error [Errno 111] Connection refused>
error: downloading https://gaisler.org/gdb/gdb-8.0.1-sis-leon2-leon3.diff: all paths have failed, giving up
Build FAILED
  See error report: rsb-report-arm-rtems5-gdb-8.0.1-x86_64-linux-gnu-1.txt
error: downloading https://gaisler.org/gdb/gdb-8.0.1-sis-leon2-leon3.diff: all paths have failed, giving up

[peerst]

Well thats not up to us at the moment: We are using https://github.com/RTEMS/rtems-source-builder under the hood to build the toolchain and rtems. Unfortunately it depends on many sites of which some are to available. Having mirrors for these would be fortunate but I don’t know if these can be set up easily

[kiwichris]

I moved the patch to the RTEMS servers yesterday. The RSB has been updated. Is the problem still present?

[holzingk]

@lwehmeier you could try building with branch update-rtems-source-builder, see #45 .

[eproxus]

@kiwichris @nextl00p Just tried out the branch, it works fine and only rtems.org was contacted 👍

[kiwichris]

Thanks for the report. I suppose this can be closed. :)

[eproxus]

@kiwichris I've merged this to master, please try it out 🙂

[lwehmeier]

Works fine on my Ubuntu 17.04 and Fedora 27 machines. On Fedora I had to install the python2 development headers to successfully build the arm-rtems-gdb, maybe add that to the dependencies listed in the wiki?

Edit: Just noticed that a project using the current grisp-software master fails to build the erlang/otp platform with the updated rtems version due to a hardcoded rtems version in the build process. rebar.config

{grisp, [
    {otp, [{version, "20.2"}]},
    {build, [
        {toolchain, [
            {directory,"/home/leon/dev/grisp-software-Og/rtems-install/rtems/5/"}
        ]}
    ]},
    {deploy, [
        {destination, "/home/leon/dev/deploy"}
    ]}
]}.

rebar3 grisp build: checking for arm-rtems4.12-gcc... /home/leon/dev/grisp-software-Og/rtems-install/rtems/5//bin/arm-rtems4.12-gcc -pipe -B /home/leon/dev/grisp-software-Og/rtems-install/rtems/5//arm-rtems4.12/atsamv/lib -specs bsp_specs -qrtems

[holzingk]

Python headers are already in the wiki: https://github.com/grisp/grisp/wiki/Linux-Development-Environment#fedora-27

Do you run latest rebar plugin?

[lwehmeier]

Indeed, missed that one. I'm running the current GitHub master of the plugin:

{plugins, [
  {rebar3_grisp, {git, "https://github.com/grisp/rebar3_grisp.git", {branch, "master"}}}
]}.

EDIT: When using the rebar3_grisp plugin v1.1.4 via hex instead of git master, the OTP21.0 target can be build using the rtems5 toolchain

[eproxus]

@lwehmeier Are you saying that the master branch cannot build using the RTEMS 5 toolchain but the Hex release can? The Hex version is almost identical to the latest master in this respect...

[lwehmeier]

I'm saying that once I changed my project's rebar config from

{plugins, [
  {rebar3_grisp, {git, "https://github.com/grisp/rebar3_grisp.git", {branch, "master"}}}
]}.

to

{plugins, [
 rebar3_grisp
]}.

it became to build using the rtems5 toolchain. Maybe changing the plugin from git to hex triggered some updates/upgrades beyond what rebar3 update && rebar3 plugins upgrade rebar3_grisp does? I'll try changing back to git master and report if the build breaks again or keeps working.

[eproxus]

@lwehmeier Thanks for letting me know. I would expect using RTEMS 5 to be possible after upgrading the plug-in to the latest master version. rebar3 plugins upgrade should have upgraded to the latest master branch... Rebar's plug-in system is very adhoc so I'm not surprised there are potential problems here. A good sanity check is to completely remove _build and either verify or remove rebar.lock and then try again.

[lwehmeier]

Probably an upgrade issue, after deleting the global caches to fix this networking issue building grisp/erlang/otp with the rtems5 toolchain is possible using both, git master and the hex package.