Unable to build sparc toolset
chrisj at rtems.org
Wed Dec 9 22:19:36 UTC 2015
On 12/09/15 23:43, Gedare Bloom wrote:
> On Wed, Dec 9, 2015 at 6:38 AM, Sambeet Panigrahi
> <sambeet161616 at gmail.com <mailto:sambeet161616 at gmail.com>> wrote:
> I also tried to clone the contents into a .git directory using git
> init because of the following line
> git: clone: git://git.rtems.org/rtems-tools.git
> <http://git.rtems.org/rtems-tools.git> -> sources/git/rtems-tools.git
> but the process still tries to clone it, giving back the same error.
> How do we get around this?
> RSB always assumes it should restart fresh. Ithink there may be an
> option not to restart/download, and it will look for the sources in the
> current directory, but I could be mistaken.
The downloaded files are cached in local directories 'sources' and
'patches'. The MD5 hashes make sure we have valid files in those
directories. Downloading will continue from the last failed or missing
download. Access to repositories is different because they are
interactive so you need access to pass that point. There is nothing I
can do about that.
I am working on tickets to release the RSB and RTEMS Tools and have
pushed some changes with more to come. The outcome of this will go a
long way to help here. The ftp area on ftp.rtems.org has a
releases/4.11/4.11.0-rc1 staging area I am using for testing (if you
take a look please read the README.txt). I will be adding a 'sources'
directory there which is the result of the RSB command below for
'4.11/rtems-all'. It will contain all sources and patches. A released
RSB will look here for a download before heading to the home site of a
package. As a result of this I need to conditionally support any repo
accesses based on the RSB being released in the configuration files. I
will have to create equivalent tar files. This means there is now a
requirement on the RSB that repo access is only for development and
releases need to have tar file support.
Sambeet's thread on this topic is timely because it confirms my
suspicion we need file level access. It also brings back to the
foreground the issue of a ChangeLog or dump of the git log being placed
in a release. Do we need this? I have seen schools block
> Another more complicated
> option would be to copy and modify the .cfg files in RSB to either point
> them to downloadable files or to an internal git clone url.
You can download with:
$ ../source-builder/sb-set-builder --dry-run --with-download \
(Note --without-error-report is coming)
then copy the 'sources' and 'patches' directories.
You will still need access to git repo's because the commands often do a
clean and pull because the RSB has to assume the repo needs updating
More information about the users