commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Phil Steitz <p...@steitz.com>
Subject Re: [doc] First attempt at update to release.html
Date Wed, 15 Dec 2004 11:06:15 GMT
Rory Winston wrote:
> Hmm,
> 
> Or even (given that 1.3.0 is the version number):
> 
> $ for f in $(ls -d *1.3.0*); do if [[ -f $f ]]; then md5sum $f > $f.md5; 
> fi;done

I think if you use md5sum you need to strip off the file name appended 
after the hash (per the release.html instructions).  The script below 
uses openssl, which does not include the file name in the hash.

-Phil
> 
> To create the md5sums.
> 
> I think we could be able to automate most of the process with some 
> judicious scripting.
> 
> Cheers,
> Rory
> 
> Rory Winston wrote:
> 
>> Martin,
>>
>> You're right - sorry about that - the following line will fix that
>>
>> $ for f in $(ls commons*); do  mv $f ${f/1.3.0/current}; done
>>
>> i.e. this will turn all commons-xxx-1.3.0.foo into 
>> commons-xxx-current.foo
>>
>> Probably should tidy this up into a script and encapsulate the version 
>> number as a variable....
>>
>> Cheers,
>> Rory
>>
>> Martin Cooper wrote:
>>
>>> This is cool, but it doesn't look quite right. The links are supposed
>>> to use "current" in the name instead of the actual version number.
>>> (The real files have the version number, obviously.)
>>>
>>> -- 
>>> Martin Cooper
>>>
>>>
>>> On Tue, 14 Dec 2004 15:56:43 +0000, Rory Winston 
>>> <rwinston@eircom.net> wrote:
>>>  
>>>
>>>> I just created a two-liner to create my symlinks (doing my first
>>>> release, so fingers crossed ;-))
>>>>
>>>> Here it is (assuming your binaries and source dirs are named likewise):
>>>>
>>>> $ for f in $(ls source/*1.3.0*);do ln -s $f ${f##source/}; done
>>>> $ for f in $(ls binaries/*1.3.0*);do ln -s $f ${f##binaries/}; done
>>>>
>>>> The "1.3.0" part is just a part of the filename that you can use to
>>>> identify the latest release, so it doesnt go off
>>>> creating symlinks to everything in there.
>>>>
>>>> Cheers,
>>>> Rory
>>>>
>>>> Martin Cooper wrote:
>>>>
>>>>  
>>>>
>>>>> On Mon, 13 Dec 2004 07:24:15 -0500, Phil Steitz <phil@steitz.com>

>>>>> wrote:
>>>>>
>>>>>
>>>>>   
>>>>>
>>>>>> One more general comment that I did not know what to do with.  
>>>>>> Steps 6
>>>>>> and 7 (checksums and sigs) and 11 (upload) involve quite a bit of

>>>>>> manual
>>>>>> typing that is time consuming and can lead to errors.
>>>>>>
>>>>>>
>>>>>>       
>>>>>
>>>>>
>>>>>
>>>>> Maven does the MD5 for you, and I use GUI tools for signing and 
>>>>> uploading.
>>>>>
>>>>>
>>>>>
>>>>>   
>>>>>
>>>>>> For 6 and 7, I
>>>>>> used the script below (please do not make fun of my limited bash

>>>>>> skills
>>>>>> ;-) .  I have another one that does verification separately 
>>>>>> (presumably
>>>>>>       from a different user ID). It would be nice to also have a

>>>>>> script to
>>>>>
>>>>>
>>>>>
>>>>>   
>>>>>
>>>>>> create the symlinks in 11 automatically.  Does anyone have this?
>>>>>>
>>>>>>
>>>>>>       
>>>>>
>>>>>
>>>>>
>>>>> I have a "script", if you can call it that, to create the links for
>>>>> Struts releases, but it's way more lame than your script below. ;-) It
>>>>> isn't eve generic - I just edit it for each release. If someone has a
>>>>> generic script, I'd be happy to use it instead.
>>>>>
>>>>>
>>>>>
>>>>>   
>>>>>
>>>>>> Should
>>>>>> these scripts a) go in committers/tools  b) be housed somewhere in

>>>>>> j-c
>>>>>> c) be summarized / embedded / linked in the instructions or d) 
>>>>>> none of
>>>>>> the above?
>>>>>>
>>>>>>
>>>>>>       
>>>>>
>>>>>
>>>>>
>>>>> If they're not Commons specific, 'committers' seems like the right
>>>>> place for the tools, with a reference to them from our Commons release
>>>>> docs.
>>>>>
>>>>> -- 
>>>>> Martin Cooper
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>   
>>>>>
>>>>>> #!/bin/sh
>>>>>> #---------------------------------------------------------------
>>>>>> # Creates detached ascii signatures and md5 hashes for each
>>>>>> # of the files in the current directory.
>>>>>> #
>>>>>> # Also verifies the signatures.
>>>>>> #
>>>>>> # For each file in the current directory, two new files
>>>>>> # are created:
>>>>>> #
>>>>>> #   <name>.asc -- ascii-armored detached PGP digital signature
>>>>>> #   <name>.md5 -- md5 hash (checksum)
>>>>>> #
>>>>>> # where <name> is the name of the file, not including file
>>>>>> # path.
>>>>>> #
>>>>>> # For example, foo-1.0-src.tar.gz in the current
>>>>>> # directory will result in foo-1.0-src.tar.gz.asc and
>>>>>> # foo-1.0-src.tar.gz.md5 added to the current directory.
>>>>>> #
>>>>>> # Deletes any .asc or .md5 files in the current directory
>>>>>> # before processing and does NOT recurse subdirectories.
>>>>>> #
>>>>>> # usage:
>>>>>> #     signAndHash
>>>>>> #
>>>>>> # requires:
>>>>>> #    gpg
>>>>>> #    openssl
>>>>>> #---------------------------------------------------------------
>>>>>> `rm *.asc`
>>>>>> `rm *.md5`
>>>>>> for file in *; do
>>>>>>   if [ -f "$file" ]; then
>>>>>>       openssl md5 < $file > ${file}.md5
>>>>>>           gpg --armor --output ${file}.asc --detach-sig $file
>>>>>>           gpg --verify ${file}.asc $file
>>>>>>   fi
>>>>>> done
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
>>>>>> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>       
>>>>>
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
>>>>> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>     
>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
>>>> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>>>>
>>>>
>>>>   
>>>
>>>
>>>
>>>
>>>
>>>  
>>>
>>
>>
>>
>>
>>
>> Martin Cooper wrote:
>>
>>> This is cool, but it doesn't look quite right. The links are supposed
>>> to use "current" in the name instead of the actual version number.
>>> (The real files have the version number, obviously.)
>>>
>>> -- 
>>> Martin Cooper
>>>
>>>
>>> On Tue, 14 Dec 2004 15:56:43 +0000, Rory Winston 
>>> <rwinston@eircom.net> wrote:
>>>  
>>>
>>>> I just created a two-liner to create my symlinks (doing my first
>>>> release, so fingers crossed ;-))
>>>>
>>>> Here it is (assuming your binaries and source dirs are named likewise):
>>>>
>>>> $ for f in $(ls source/*1.3.0*);do ln -s $f ${f##source/}; done
>>>> $ for f in $(ls binaries/*1.3.0*);do ln -s $f ${f##binaries/}; done
>>>>
>>>> The "1.3.0" part is just a part of the filename that you can use to
>>>> identify the latest release, so it doesnt go off
>>>> creating symlinks to everything in there.
>>>>
>>>> Cheers,
>>>> Rory
>>>>
>>>> Martin Cooper wrote:
>>>>
>>>>  
>>>>
>>>>> On Mon, 13 Dec 2004 07:24:15 -0500, Phil Steitz <phil@steitz.com>

>>>>> wrote:
>>>>>
>>>>>
>>>>>    
>>>>>
>>>>>> One more general comment that I did not know what to do with.  
>>>>>> Steps 6
>>>>>> and 7 (checksums and sigs) and 11 (upload) involve quite a bit of

>>>>>> manual
>>>>>> typing that is time consuming and can lead to errors.
>>>>>>
>>>>>>
>>>>>>       
>>>>>
>>>>>
>>>>> Maven does the MD5 for you, and I use GUI tools for signing and 
>>>>> uploading.
>>>>>
>>>>>
>>>>>
>>>>>    
>>>>>
>>>>>> For 6 and 7, I
>>>>>> used the script below (please do not make fun of my limited bash

>>>>>> skills
>>>>>> ;-).  I have another one that does verification separately 
>>>>>> (presumably
>>>>>>       from a different user ID). It would be nice to also have a

>>>>>> script to
>>>>>
>>>>>
>>>>>    
>>>>>
>>>>>> create the symlinks in 11 automatically.  Does anyone have this?
>>>>>>
>>>>>>
>>>>>>       
>>>>>
>>>>>
>>>>> I have a "script", if you can call it that, to create the links for
>>>>> Struts releases, but it's way more lame than your script below. ;-) It
>>>>> isn't eve generic - I just edit it for each release. If someone has a
>>>>> generic script, I'd be happy to use it instead.
>>>>>
>>>>>
>>>>>
>>>>>    
>>>>>
>>>>>> Should
>>>>>> these scripts a) go in committers/tools  b) be housed somewhere in

>>>>>> j-c
>>>>>> c) be summarized / embedded / linked in the instructions or d) 
>>>>>> none of
>>>>>> the above?
>>>>>>
>>>>>>
>>>>>>       
>>>>>
>>>>>
>>>>> If they're not Commons specific, 'committers' seems like the right
>>>>> place for the tools, with a reference to them from our Commons release
>>>>> docs.
>>>>>
>>>>> -- 
>>>>> Martin Cooper
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>    
>>>>>
>>>>>> #!/bin/sh
>>>>>> #---------------------------------------------------------------
>>>>>> # Creates detached ascii signatures and md5 hashes for each
>>>>>> # of the files in the current directory.
>>>>>> #
>>>>>> # Also verifies the signatures.
>>>>>> #
>>>>>> # For each file in the current directory, two new files
>>>>>> # are created:
>>>>>> #
>>>>>> #   <name>.asc -- ascii-armored detached PGP digital signature
>>>>>> #   <name>.md5 -- md5 hash (checksum)
>>>>>> #
>>>>>> # where <name> is the name of the file, not including file
>>>>>> # path.
>>>>>> #
>>>>>> # For example, foo-1.0-src.tar.gz in the current
>>>>>> # directory will result in foo-1.0-src.tar.gz.asc and
>>>>>> # foo-1.0-src.tar.gz.md5 added to the current directory.
>>>>>> #
>>>>>> # Deletes any .asc or .md5 files in the current directory
>>>>>> # before processing and does NOT recurse subdirectories.
>>>>>> #
>>>>>> # usage:
>>>>>> #     signAndHash
>>>>>> #
>>>>>> # requires:
>>>>>> #    gpg
>>>>>> #    openssl
>>>>>> #---------------------------------------------------------------
>>>>>> `rm *.asc`
>>>>>> `rm *.md5`
>>>>>> for file in *; do
>>>>>>   if [ -f "$file" ]; then
>>>>>>       openssl md5 < $file > ${file}.md5
>>>>>>           gpg --armor --output ${file}.asc --detach-sig $file
>>>>>>           gpg --verify ${file}.asc $file
>>>>>>   fi
>>>>>> done
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
>>>>>> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>       
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
>>>>> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>     
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
>>>> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>>>>
>>>>
>>>>   
>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
>>> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>>>
>>>
>>>
>>>  
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>>
>>
>>
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message