[rtems-source-builder commit] 5: Update Newlib

[Chris Johns]

On 6/6/19 5:01 pm, Sebastian Huber wrote:
> On 06/06/2019 08:05, Chris Johns wrote:
>> On 6/6/19 3:04 pm, Sebastian Huber wrote:
>>> On 06/06/2019 02:23, Chris Johns wrote:
>>>> On 5/6/19 10:16 pm, Sebastian Huber wrote:
>>>>> +tools/rtems-gcc-fb371a33fa6-newlib-5c2a3661c
>>>> Is there a timetable for gcc 7 branch releases? I see the built gcc executable
>>>> clearly shows the version of gcc is 7.4.1 which is great so I am wondering if
>>>> this file name would be clearer if the branch was included, ie
>>>> `tools/rtems-gcc-7.4-fb371a33fa6-newlib-5c2a3661c`. I am not concerned with
>>>> newlib as much because there are no branches like we have with gcc.
>>>>
>>>> I raise this because I saw `rtems-gcc-fb371a33fa6-newlib-1d35a003f` being built
>>>> by the RSB and I did not know if this was master, a branch or which branch.
>>>> Also
>>>> the package name is the name of the source tarball and so the name used in a
>>>> release on our ftp servers.
>>> We could use the branch number and atimestamp for the files, e.g.
>>>
>>> rtems-gcc-fb371a33fa6-newlib-5c2a3661c ->
>>> rtems-gcc-7-2019-06-05-newlib-2019-06-05
>>>
>> I am not sure what "for the files" means?
> 
> The file name of the *.cfg file?
> 

Sure but it does not help a tarball name in a release if one is made. Should we
add the branch to the file name? For example ..

%define gcc_branch 7
%define gcc_version fb371a33fa6
%define gcc_external 1
%define gcc_expand_name gnu-mirror-gcc-%{gcc_branch}-%{gcc_version}

>>
>> I am fine with the git hash being present. It does make it easy find the history
>> given a tarball.
> 
> You asked for a timeline. Even with
> 
> rtems-gcc-7-fb371a33fa6-newlib-5c2a3661c
> rtems-gcc-7-32fc1a32aa6-newlib-5c2a3661c
> 
> you don't know which GCC 7 branch commit was before or after.
> 

Oh sorry I was meaning, if there are no more branch release or anything soon'ish
we should handle this or do we wait for a branch release to be made?

Chris