git.rtems.org down: rtems-sourcebuilder sub-module reference points to nonexisting changeset

[peerst]

It seems that the changeset referenced for rtems-source-builder is gone.

Seems someone is editing history over there :-(

[peerst]

Seems just the git.rtems.org server is gone.

If the infrastructure of rtems.org keeps to be unrealiable we should move all deps to github

[c-mauderer]

I have no problems accessing it. The referenced commit is here: https://git.rtems.org/rtems-source-builder/tree/?id=1ceafe5f12744e4b4424e68c70e6a5379c481e7e

Of course it should be no problem to add a clone of the source builder here too or just reference the existing one (https://github.com/RTEMS/rtems-source-builder).

In that case it might would be necessary to have a detailed look at the downloads done by rtems source builder. I think most patches are not from rtems.org but I'm not 100% sure about that.

[peerst]

It seems to be caused by the local Wifi which lets us access github but not git.rtems.org

[bieniusa]

I can access that webpage though. Odd.

[peerst]

Probably some git protocol blockage, thats opened up to github

[kiwichris]

No one should be rewriting the history of the RTEMS git repos. I would be concerned if that happens and there would be a public discussion about it.

We are working to consolidate as much onto the rtems.org hosts but there are limits. The actual machines are reliable and the net service via the OSU OSL is very good. Lance and his team do an awesome job. We have a number of servers behind duplicated cisco firewalls. The equipment is purchased from the money we receive for being part of Goggle's Summer of Code and is maintained by Amar as a volunteer. We welcome any support, we need it.

The trac instance we are running can go down and requires a restart. It is not that frequent but it does happen. I suspect it gets hammered all the time. Using tickets for patches is a good idea but this pause in trac is a pain.

The development versions of the RSB, ie a git version, is dependent on the availability of the upstream source. The ability to successfully download can vary and can break if a site decides to reorganize itself. A released RSB uses the RTEMS servers and this more reliable.

A system deploying the RSB could consider providing a VERSIONS file to change the download path used. This however means that system needs to keep an eye on the upstream RSB changes to make sure the files available are current. If you need a hand sorting this approach out please feel free to ask me.

If you have any issues or suggestions please drop by the RTEMS user list and let us know.

[peerst]

@kiwichris regarding history rewriting: This was probably because our toplevel repo had RSB as a subrepo and was probably referencing something in a branch that got rebased or cleaned up. Not even sure that was on rtems.org or if it was on embedded brains server. A side effect of the work in progress nature this had back then.

The same goes for using a non released RSB, we needed some current fixes to make our stuff work. Well noted that if we stay on released versions we are only depending on rtems.org

Regarding VERSIONS file: sounds very interesting can I read up on what can be done with it somewhere? Can it be used for a local cache of downloads? Especially when working on toolchain things it would be nice not to re-download all the dependencies over and over

[kiwichris]

Thanks for the feedback, the mess up makes sense and yes when things are fluid it makes it harder. On the VERSION topic there is not a great deal, I wish I had the time to write it up. The only places anything exists is the release scripts (https://git.rtems.org/rtems-release/tree/rtems-release-rsb-version) and the code (https://git.rtems.org/rtems-source-builder/tree/source-builder/sb/version.py#n50). I am sorry there is nothing more user friendly.

[eproxus]

@kiwichris Perhaps there should be a stable Git mirror of the source repository? E.g. on GitHub or BitBucket or somewhere? See https://help.github.com/articles/about-github-mirrors/

[kiwichris]

The source the RSB pulls down? This is problematic for a number of reason. For example the RSB supports pulling code from git and this is what the RISC-V target does so how do you package that repo as a "something" to be able to archive in a stable way. Another issue is the RSB containing the home sites for the projects it pulls in, thiis a good reference. We pull patches from patchworks, github, mail archives, trac, etc. This has to scale across all archs and supported hosts. I think evolving the "deployment" side of the RSB to better support users like you is a natural progression. The VERSION file is a simple start. I am happy to look at adding deployment support.

[eproxus]

Ah, it's more complex than I first imagined 😄