[DISCUSS][VOTE] Release apache-openoffice-4.1.2-patch1 Source

["Dennis E. Hamilton" <de...@acm.org>]

> -----Original Message-----
> From: Andrea Pescetti [mailto:pescetti@apache.org]
> Sent: Wednesday, August 3, 2016 12:15
> To: dev@openoffice.apache.org
> Subject: Re: [VOTE] Release apache-openoffice-4.1.2-patch1 Source
> 
[ ... ]
> $ svn co
> https://dist.apache.org/repos/dist/dev/openoffice/4.1.2-patch1/source
> 
> $ dos2unix apache-openoffice-4.1.2-patch1.zip.md5
> 
> (this is needed as apparently md5sum will get confused by newlines in
> the checksum file).
> 
> $ md5sum -c apache-openoffice-4.1.2-patch1.zip.md5
> apache-openoffice-4.1.2-patch1.zip: OK
> 
> $ dos2unix apache-openoffice-4.1.2-patch1.zip.sha256
> $ sha256sum -c apache-openoffice-4.1.2-patch1.zip.sha256
> apache-openoffice-4.1.2-patch1.zip: OK
[ ... ]
[orcmid] 

I believe PGP protocol is clever about line-ending differences, canonicalizing text streams as part of verifying signatures (and reading the signature block).  Windows developer tools tend to be forgiving in that manner as well although it might not help if the results are given back to folks using *nix systems.

It's possible that using the Unix-compatible versions of the .md5 and .sha256 text formatting will work better, since the Windows-native versions of md5sum and sha256sum may be more forgiving.

Oh, and the SVN config should be changed to recognize .md5 and .sha256 files as text and to be handled with respect to native.  I suspect that the default *in* the SVN should be Unix-style.

Time to run some experiments.

 - Dennis

PS: I just added 

*.asc = svn:eol-style=native;;charset=UTF-8
*.md5 = svn:eol-style=native
*.sha256 = svn:eol-style=native

To my SVN config file.

Once we have the files in default SVN line-ending texts on the SVN, we can check how well that works when the files are checked-out and also when the files are accessed directly from the repository via http.

Note, the charset=UTF-8 should also be used for KEYS files also, which need to work without character-set translation and not have code-page/single-byte interchange problems.  We have conflicts between UTF-8 and Western European (ISO 8859-1) in our KEYS file right now.  That's a separate problem that needs to be handled by configuring PGP tools to use UTF-8 instead of what is the default on a given machine and operating system and which breaks across the international reach of the ASF and Apache OpenOffice.




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

Re: [DISCUSS][VOTE] Release apache-openoffice-4.1.2-patch1 Source

[Andrea Pescetti <pe...@apache.org>]

Dennis E. Hamilton wrote:
> It's possible that using the Unix-compatible versions of the .md5 and .sha256 text formatting will work better

This worked better for my usual workflow. But there are many ways and 
tools to check an MD5 hash. It is fine to keep the current files as they 
are, no need to worry about this. I specified the detail just in case 
someone is confused by md5sum complaining that the target file cannot be 
found.

Regards,
   Andrea.

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