On 17/04/2018 21:18, Sebastian Huber wrote:
> On 17/04/18 12:12, Chris Johns wrote:
>> On 17/4/18 6:49 pm, Sebastian Huber wrote:
>>> On 17/04/18 10:30, Chris Johns wrote:
>>>> On 17/04/2018 18:21, Sebastian Huber wrote:
>>>>> Download via HTTPS RTEMS file server.
>>>>>
>>>>> Close 3241.
>>>> Can you please explain why this solves the issue in the ticket? I do not
>>>> see
>>>> how
>>>> they relate.
>>> This solves the ticket since git is no longer involved.
>>>
>>>> There can be issues with a sequence of git commands if you are switching
>>>> branches. This can be resolved by improving the sequence used.
>>>>
>>>>> ---
>>>>> rtems/config/tools/rtems-tools-5-1.cfg | 28
>>>>> ++++++++++++++++++++++++++--
>>>>> 1 file changed, 26 insertions(+), 2 deletions(-)
>>>>>
>>>>> diff --git a/rtems/config/tools/rtems-tools-5-1.cfg
>>>>> b/rtems/config/tools/rtems-tools-5-1.cfg
>>>>> index 6efc4e3..e0178f0 100644
>>>>> --- a/rtems/config/tools/rtems-tools-5-1.cfg
>>>>> +++ b/rtems/config/tools/rtems-tools-5-1.cfg
>>>>> @@ -7,9 +7,33 @@
>>>>> #
>>>>> %if %{rsb_released}
>>>>> %define rtems_tools_version %{rsb_version}
>>>>> +%else
>>>>> + %define rtems_tools_version ec419a05ee52869a7d5b8712ea8e7a7d74fde096
>>>>> %endif
>>>> Sorry, this is not the right place for this sort of detail. Version details
>>>> need
>>>> to be in the release defaults or overridden in a an arch specific file.
>>> Sorry, I didn't understand the logic for the rtems_tools_version definition
>>> at
>>> all. Why is it dependent on rsb_released?
>> If the RSB is released the RTEMS ftp server is used for downloads and the
>> version is the RTEMS release verson. The RTEMS tools do not have a separate
>> release cycle from RTEMS and use the same version numbers.
>>
>>>> Why this version?
>>> It is the latest commit. So, just the thing that would have been picked by
>>> the
>>> current RSB.
>>>
>>> The use of a random HEAD is a major problem from my point of view. It makes
>>> the
>>> RSB outcome build time dependent and irreproducible.
>> Releases are matched. I do not follow how this resolves any dependence issue
>> that may appear such as the dl06 and rtems-ld.
>
> For the latest test suite you need an up to date rtems-ld. If you built the
> tools with RSB 703532cb04c6990fb21e97cb7347a16e9df11108 two months ago, then
> it
> will not work. If you build with RSB 703532cb04c6990fb21e97cb7347a16e9df11108
> today, then everything is fine. This is a serious defect from my point of
> view.
How is this any different from all the newlib changes you made? To me it is the
same.
Lets not get to too tangled up here it is development. I clearly stated in the
cover email a tools update was needed and in future I will send a single
specific email to the list to say an update is needed.
>>
>>>> I do not follow or understand the purpose of the change and with a lack of
>>>> specific detail it appears to solve a local problem. It may appear to
>>>> solve the
>>>> problem because it side steps an issue related to switching branches.
>>> There are some reports on the mailing list related to the rtems-tools
>>> download
>>> via git. It has at least two problems:
>>>
>>> 1. It fails sporadically.
>> The real issue in the way git is being sequenced should be fix.
>>
>>> 2. You need internet access during the build.
>> If you updated RTEMS and have disconnected and not updated the RSB with a new
>> hash version downloaded from your home ftp area you have stuffed anyway.
>>
>
> You should be able to
>
> ../source-builder/sb-set-builder --dry-run --with-download ...
>
> and then disconnect from the internet to build the tools.
>
The ability to create an archive directory is something I would welcome. I side
step around it in the release scripts at the moment but this functionality
should be moved into the RBS. It will happen when I find the time.
Chris
_______________________________________________
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
