[asterisk-dev] Additional release checksums?

[Ben Langfeld]

Patch submitted for review: https://reviewboard.asterisk.org/r/3091/


On 22 December 2013 11:31, Ben Langfeld <ben at langfeld.me> wrote:

> If everything went in one checksum file, how would one (or shasum) tell
> each of the checksums apart?
>
> I'll submit a patch to mkrelease for the extra files.
>
>
> On 21 December 2013 22:57, Matthew Jordan <mjordan at digium.com> wrote:
>
>>
>> On Sat, Dec 21, 2013 at 4:26 PM, Paul Belanger <
>> paul.belanger at polybeacon.com> wrote:
>>
>>> On 13-12-21 11:04 AM, Ben Langfeld wrote:
>>>
>>>> Congrats to all on the 12 release yesterday. There's some excellent work
>>>> that's gone into that release and we're all very grateful and excited
>>>> about
>>>> using it.
>>>>
>>>> Unfortunately, Chef only currently supports SHA-256 checksums of
>>>> downloaded
>>>> files. This means that in order to properly release new builds of
>>>> Asterisk
>>>> to my machines, I need to manually download the release, verify the
>>>> SHA1,
>>>> generate a SHA-256, feed this to Chef and converge.
>>>>
>>>> There's work underway on Chef to support other checksum types, but it
>>>> might
>>>> be helpful regardless for Asterisk to include other checksum types.
>>>> Would
>>>> it be a lot of work to add at least SHA-256, if not MD5 as well, to the
>>>> release process?
>>>>
>>>>  The build script for asterisk releases are located in repotools[1], so
>>> adding support should be a matter of just submitting a patch to the tracker.
>>>
>>> [1] http://svnview.digium.com/svn/repotools/
>>>
>>
>> It's pretty trivial to update mkrelease and releaser to create a new
>> checksum file using sha256sum/md5sum.
>>
>> The question is: if we're going to generate three checksums, is it
>> worthwhile to put them all into a single checksum file? Or do we want three
>> separate files?
>>
>> Going the separate file approach would end up generating 6 files per
>> release (3 for the release, 3 for the patch), times 3 supported release
>> branches. Not that it would take up a lot of disk space, but it would be
>> more stuff to browse through.
>>
>> Matt
>>
>> --
>> Matthew Jordan
>> Digium, Inc. | Engineering Manager
>> 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
>> Check us out at: http://digium.com & http://asterisk.org
>>
>> --
>> _____________________________________________________________________
>> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
>>
>> asterisk-dev mailing list
>> To UNSUBSCRIBE or update options visit:
>>    http://lists.digium.com/mailman/listinfo/asterisk-dev
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20131222/894e17ba/attachment.html>