Re: Download Junit and Hamcrest in ./bootstrap?

[Damjan Jovanovic]

Sadly it's not that simple: Junit builds with Maven, and Hamcrest with
Gradle.

Is it ok to download the binaries, or is only source code allowed under
ext_sources?

On Thu, Aug 11, 2016 at 10:42 AM, Damjan Jovanovic 
wrote:

> Hi
>
> If you've been checking the buildbots you'll see that all who don't use
> --without-junit are currently broken in ./configure due to junit being too
> old. This is unlikely to change, as the buildslaves are running Ubuntu
> 10.04 which doesn't have newer versions of Junit available in apt.
>
> This is part of a bigger problem, which is that Junit's dependencies
> changed multiple times in the 4.x releases, which is why I changed
> configure.ac to need at least 4.11 (the maximum being 4.12).
>
> Instead of needing a correct system Junit version to run tests during the
> build, and having to worry about having correct system versions of Hamcrest
> on the classpath, should we not rather treat them like external
> dependencies and download specific versions during ./bootstrap? It's under
> 300 kB for both, and the bvt/fvt/pvt tests already download their own copy.
>
> Damjan
>
>

RE: [TESTING] Applying openoffice-4.1.2-patch1 for Windows

[Dennis E. Hamilton]

BETA 0.1.0 WITH AUTOMATED SCRIPTS IS NOW AVAILABLE

The scripts make life much easier, since users don't have to go hunting for 
anything and digging around in operating-system locations.

You should be able to go through the procedure that uses the automated steps 
pretty easily.

It is very important to know the difficulties that arise or whether there were 
none.

The material is available at 
.

 - Dennis



> -Original Message-
> From: Dennis E. Hamilton [mailto:dennis.hamil...@acm.org]
> Sent: Wednesday, August 10, 2016 18:01
> To: dev@openoffice.apache.org
> Cc: q...@openoffice.apache.org
> Subject: RE: [TESTING] Applying openoffice-4.1.2-patch1 for Windows
> 
> Beta version 0.1.0 is now nearing completion.
> 
> It will include two scripts, one for applying the patch, the other for
> reverting the patch.
> 
> The .zip will also have a copy of the original 4.1.2 tl.dll as well as
> the new one.  These are used in the procedures to verify the files that
> are present in the OpenOffice configuration in order to apply the patch
> and also to remove it.
> 
> Next steps:
>  * Additional path testing of the two scripts and verification that
> operation on Windows XP and on Windows 10 work as expected.
[orcmid] 

Done
 
It is also much easier to work through the patch checks using the scripts.
> 
>  * Updating of the README to reflect the availability of the batch-file
> scripts as well as the manual procedure if ever needed.
[orcmid] 

Done

> 
>  * Although the Zips already carry executable code (i.e., DLLs) there
> may be some Antivirus push-back where the policy is to not allow .zip
> files with scripts in them.  The README will also have to address that
> possibility.
[orcmid] 

I forgot that at the last minute.  I will put that into the next version.  
Meanwhile, those who check these procedures should report any AV objections 
they ran into.


> 
>  - Dennis
> 
> > -Original Message-
> > From: Dennis E. Hamilton [mailto:dennis.hamil...@acm.org]
> > Sent: Monday, August 8, 2016 09:58
> > To: dev@openoffice.apache.org
> > Cc: q...@openoffice.apache.org
> > Subject: RE: [TESTING] Applying openoffice-4.1.2-patch1 for Windows
> >
> > Alpha version 0.0.1 of README-4.1.2-patch1-apply-Windows.txt has been
> > introduced into the files (and the .zip) at
> >  > patch1/binaries/Windows>.
> >
> > This version reflects suggestions by Marcus Lange, Pedro Lino, and
> Keith
> > McKenna.  Suggestions that are not (yet) implemented will be discussed
> > in replies to their messages and on the bugzilla issue at
> > .
> >
> >
> > By its nature, this material is intended for users operating on
> Windows.
> > In some cases, incompatible forms are used on the Subversion server
> > where the above files are situated.  Version 0.0.1 attempts to
> > accommodate for this incompatibility.  In continuing to verify the
> > procedure, please indicate whether there are (now) difficulties using
> > the text files, especially on Windows.
> >
> > Users of Linux systems may have difficulties with some utilities for
> > which the Windows versions of the same tool (e.g., md5sum) do not
> > produce Linux-acceptable line endings.  It is useful to know if that
> is
> > still the case.  The files have been confirmed to be usable using the
> > utilities built for use on Windows.
> >
> > For future versions, the use of HTML instead of text will be
> considered.
> > HTML does not have white-space incompatibility problems across
> different
> > platforms. The HTML will also be digitally-signed as a means of
> > verifying its authenticity.
> >
> > In addition to possibly using HTML as a better form for cross-platform
> > use of text, attention will now move toward introducing scripts that
> > automatically apply the change, replacing all of steps 9-18.
> >
> > Meanwhile, it is valuable to continue testing that the replacement
> file
> > produces no regression or introduction of any defects not seen using
> an
> > unmodified Apache OpenOffice 4.1.2.
> >
> >  - Dennis
> >
> >
> > > -Original Message-
> > > From: Dennis E. Hamilton [mailto:dennis.hamil...@acm.org]
> > > Sent: Tuesday, August 2, 2016 20:31
> > > To: dev@openoffice.apache.org
> > > Cc: q...@openoffice.apache.org
> > > Subject: [TESTING] Applying openoffice-4.1.2-patch1 for Windows
> > >
> > > Testing of an Apache OpenOffice 4.1.2-patch1 procedure is requested.
> > >
> > > The files to be used in testing are at
> > >  > patch1/binaries/Windows>.
> > >
> > > The files to be tested and reviewed are
> > >
> > >  * README-4.1.2-patch1-apply-Windows.txt
> > >The description of the procedure for applying a corrected
> > >library file to installed copies of Apache OpenOffice 4.1.2
> > >on Windows.  Read this first

Re: [PACKAGING 4.1.2-patch1 Binaries] (was RE: [TESTING] Applying openoffice-4.1.2-patch1 for Windows)

[Marcus]

Am 08/11/2016 09:50 PM, schrieb Kay sch...@apache.org:


On 08/09/2016 02:12 PM, Kay Schenk wrote:

[top posting]
I'm in the process of trying to "sync" instructions for Linux32,
Linux64, and MacOSX at the moment. As far as instructions on the actual
HOTFIX page, we need to have just a "general" instruction for ALL zips
that simply says -- "Unzip this package to some folder of your choosing
and read the README that's included." Everything else should be in the
various READMEs for each platform.

I should be done with all edits by this evening for a final review
before zipping and signing.


Ok, I've now moved on to creating zip files, etc for Linux32, Linux64
and Mac.

My openssl version on does NOT supply digest sha256. Is it OK to use
sha1? MD5 already computed for each of these.


I like to have it consistent for all platforms. Therefore I'll check the 
ZIPs and deliver the sha256 hash files.


Marcus




On 08/05/2016 09:28 AM, Dennis E. Hamilton wrote:

Branching off the part that is not about the Windows 4.1.2-patch1 [TESTING].


-Original Message-
From: Marcus [mailto:marcus.m...@wtnet.de]
Sent: Thursday, August 4, 2016 15:52
To: dev@openoffice.apache.org
Subject: Re: [TESTING] Applying openoffice-4.1.2-patch1 for Windows

Am 08/05/2016 12:26 AM, schrieb Kay Schenk:

[ ... ]


hmmm...well no zips for Mac, Linux32, or Linux 64 -- yet.

Should we get started on these?


it depends what we want that they should contain. The ZIP file for
Windows contains a LICENSE and NOTICE file as well as an ASC file for
the DLL. As it is only a patch IMHO we don't need to provide another
LICENSE and NOTICE file which is already available in the OpenOffice
installation. Also the ASC is not necessary as we provide it already
(together with MD5 and SHA256) for the whole ZIP file.

[orcmid]

I think there is a misunderstanding.  Two matters:

  1. The use of LICENSE is required by the ALv2 itself, and the ASF practice is 
to include NOTICE as well on binary distributions.  The patch qualifies, 
especially when it is moved to general distribution.  It is also easy and 
harmless to provide.

  2. The reason for preserving the .asc on the shared-library binary is because 
it authenticates with respect to who produced it and establishes that it has 
not been modified as supplied in the package (or as the result of some glitch 
in creation of the Zip).  It provides a level of accountability and, also, 
auditability.

Even though few people will check all of these, they remain possible to be 
checked.  Since this is a matter of security vulnerabilities and involves 
elevation of privilege to perform, I believe it is important to demonstrate 
diligence and care, so that users have confidence in this procedure to the 
extent they are comfortable.  Also, if it becomes necessary to troubleshoot a 
problem with these patch applications, we have the means to authenticate what 
they are using to ensure there are no counterfeits being offered to users.


That means that only the README and library file remains.

When the README for Windows keep its length then I don't want to copy
this on the dowload webpage. ;-)

So, when we put the README for all platforms in their ZIP files then we
can just put a pointer to it on the download webpage and thats it.

[orcmid]

Yes, that seems like a fine idea.  The README can be linked the same way the 
.md5, .sha256, and .asc are linked.

Also, the README may become simpler if we can link to some of the information 
and not have so much detail in the README text itself.  It might even be useful 
to have an .html README for that matter.  But that is all extra.  Right now I 
think we want to get into the testing and see how to smooth what we have.

PS: A friend of mine is looking into the MacOSX situation.  He points out that 
one can use the Finder to do the job without users having to use Terminal 
sessions.  I don't have further information at this time.

PPS: The inclusion of scripts that do the job is also worthy of consideration, 
perhaps making it unnecessary to build executables.  I will be looking at 
finding a .bat file that works safely for the Windows case.  That can make the 
instructions much shorter :).



To cut a long story short:
I would say yes for a ZIP file for every platform.

[ ... ]


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

Re: [PACKAGING 4.1.2-patch1 Binaries] (was RE: [TESTING] Applying openoffice-4.1.2-patch1 for Windows)

[Don Lewis]

On 11 Aug, Kay sch...@apache.org wrote:
> 
> 
> On 08/11/2016 12:50 PM, Kay sch...@apache.org wrote:
>> 
>> 
>> On 08/09/2016 02:12 PM, Kay Schenk wrote:
>>> [top posting]
>>> I'm in the process of trying to "sync" instructions for Linux32,
>>> Linux64, and MacOSX at the moment. As far as instructions on the
>>> actual HOTFIX page, we need to have just a "general" instruction for
>>> ALL zips that simply says -- "Unzip this package to some folder of
>>> your choosing and read the README that's included." Everything else
>>> should be in the various READMEs for each platform.
>>>
>>> I should be done with all edits by this evening for a final review
>>> before zipping and signing.
>> 
>> Ok, I've now moved on to creating zip files, etc for Linux32, Linux64
>> and Mac.
>> 
>> My openssl version on does NOT supply digest sha256. Is it OK to use
>> sha1? MD5 already computed for each of these.
> 
> sha1 is referenced on the ASF code signing page so I decided it was OK. :)

I'm really surprised that ASF requires MD5 since it was broken long ago.
Even SHA1 is now regarded as a weak hash.


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

Re: [PACKAGING 4.1.2-patch1 Binaries] (was RE: [TESTING] Applying openoffice-4.1.2-patch1 for Windows)

[Andrea Pescetti]

Kay Schenk wrote:

My openssl version on does NOT supply digest sha256. Is it OK to use
sha1? MD5 already computed for each of these.


Guidelines recommend SHA256. But it should not be difficult for you to 
get a sha256sum binary or a generic shasum binary to run as "shasum 
-a256 FILENAME".


Regards,
  Andrea.

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

Re: Download Junit and Hamcrest in ./bootstrap?

[Don Lewis]

On 11 Aug, Kay Schenk wrote:
> 
> 
> On 08/11/2016 01:05 PM, Kay Schenk wrote:
>> 
>> On 08/11/2016 09:53 AM, Don Lewis wrote:
>>> On 11 Aug, Kay sch...@apache.org wrote:

 On 08/11/2016 01:42 AM, Damjan Jovanovic wrote:
> Hi
>
> If you've been checking the buildbots you'll see that all who don't use
> --without-junit are currently broken in ./configure due to junit being too
> old. This is unlikely to change, as the buildslaves are running Ubuntu
> 10.04 which doesn't have newer versions of Junit available in apt.
>
> This is part of a bigger problem, which is that Junit's dependencies
> changed multiple times in the 4.x releases, which is why I changed
> configure.ac to need at least 4.11 (the maximum being 4.12).
>
> Instead of needing a correct system Junit version to run tests during the
> build, and having to worry about having correct system versions of 
> Hamcrest
> on the classpath, should we not rather treat them like external
> dependencies and download specific versions during ./bootstrap? It's under
> 300 kB for both, and the bvt/fvt/pvt tests already download their own 
> copy.
>
> Damjan
>

 This would be OK with me. What version of the jre does Junit 4.11
 require? I can't find information about this on the junit site
 --http://junit.org/junit4/

 Right now, we're still spec'd at jdk 1.6 for everything except Windows,
 but IMO we should advance to 1.7 .
>>>
>>> That sounds good to me as well, but are there any issues with installing
>>> a newer jdk on older Linux distributions that we still support?
>> 
>> Andrea put out a notice for setting up a production farm of machines --
>> see:
>>  
>> http://mail-archives.apache.org/mod_mbox/openoffice-dev/201608.mbox/%3C57AA12CA.1090207%40apache.org%3E
>> 
>> We'd have to use CentOS 5.11 since this is the only 5 version that is
>> NOT deprecated. It looks like java 1.7 SDK is available for that
>> distribution.
>> 
>> http://mirror.centos.org/centos/5.11/os/i386/CentOS/
>> 
>> We also know that the older branch 4.1.2 will not work with java 1.7,
> 
> [sorry I misspoke here. 4.1.2 will NOT work with java 1.8. 4.2 works
> with either java 1.7 or java 1.8]

The FreeBSD port of OpenOffice 4.1.2 works with java 1.8.  The only
problem that I know if related to using 1.8 to build is that that after
installation it will only work with 1.8.  If you build with 1.7, then
you can use either 1.7 or 1.8 on the machine where OpenOffice is
installed.


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

Re: [PACKAGING 4.1.2-patch1 Binaries] (was RE: [TESTING] Applying openoffice-4.1.2-patch1 for Windows)

[Kay sch...@apache.org]

On 08/11/2016 12:50 PM, Kay sch...@apache.org wrote:
> 
> 
> On 08/09/2016 02:12 PM, Kay Schenk wrote:
>> [top posting]
>> I'm in the process of trying to "sync" instructions for Linux32,
>> Linux64, and MacOSX at the moment. As far as instructions on the actual
>> HOTFIX page, we need to have just a "general" instruction for ALL zips
>> that simply says -- "Unzip this package to some folder of your choosing
>> and read the README that's included." Everything else should be in the
>> various READMEs for each platform.
>>
>> I should be done with all edits by this evening for a final review
>> before zipping and signing.
> 
> Ok, I've now moved on to creating zip files, etc for Linux32, Linux64
> and Mac.
> 
> My openssl version on does NOT supply digest sha256. Is it OK to use
> sha1? MD5 already computed for each of these.

sha1 is referenced on the ASF code signing page so I decided it was OK. :)

So I think I'm done with the Linux32, Linux64, and MacOSX zip artifacts.
Please check at:

https://dist.apache.org/repos/dist/dev/openoffice/4.1.2-patch1/binaries/

If anything's amiss, it's likely I can't get back to this until Sunday.
Or feel free to fix.

> 
>>
>> On 08/05/2016 09:28 AM, Dennis E. Hamilton wrote:
>>> Branching off the part that is not about the Windows 4.1.2-patch1 [TESTING].
>>>
 -Original Message-
 From: Marcus [mailto:marcus.m...@wtnet.de]
 Sent: Thursday, August 4, 2016 15:52
 To: dev@openoffice.apache.org
 Subject: Re: [TESTING] Applying openoffice-4.1.2-patch1 for Windows

 Am 08/05/2016 12:26 AM, schrieb Kay Schenk:
>>> [ ... ]
>
> hmmm...well no zips for Mac, Linux32, or Linux 64 -- yet.
>
> Should we get started on these?

 it depends what we want that they should contain. The ZIP file for
 Windows contains a LICENSE and NOTICE file as well as an ASC file for
 the DLL. As it is only a patch IMHO we don't need to provide another
 LICENSE and NOTICE file which is already available in the OpenOffice
 installation. Also the ASC is not necessary as we provide it already
 (together with MD5 and SHA256) for the whole ZIP file.
>>> [orcmid] 
>>>
>>> I think there is a misunderstanding.  Two matters:
>>>
>>>  1. The use of LICENSE is required by the ALv2 itself, and the ASF practice 
>>> is to include NOTICE as well on binary distributions.  The patch qualifies, 
>>> especially when it is moved to general distribution.  It is also easy and 
>>> harmless to provide.
>>>
>>>  2. The reason for preserving the .asc on the shared-library binary is 
>>> because it authenticates with respect to who produced it and establishes 
>>> that it has not been modified as supplied in the package (or as the result 
>>> of some glitch in creation of the Zip).  It provides a level of 
>>> accountability and, also, auditability.
>>>
>>> Even though few people will check all of these, they remain possible to be 
>>> checked.  Since this is a matter of security vulnerabilities and involves 
>>> elevation of privilege to perform, I believe it is important to demonstrate 
>>> diligence and care, so that users have confidence in this procedure to the 
>>> extent they are comfortable.  Also, if it becomes necessary to troubleshoot 
>>> a problem with these patch applications, we have the means to authenticate 
>>> what they are using to ensure there are no counterfeits being offered to 
>>> users.

 That means that only the README and library file remains.

 When the README for Windows keep its length then I don't want to copy
 this on the dowload webpage. ;-)

 So, when we put the README for all platforms in their ZIP files then we
 can just put a pointer to it on the download webpage and thats it.
>>> [orcmid] 
>>>
>>> Yes, that seems like a fine idea.  The README can be linked the same way 
>>> the .md5, .sha256, and .asc are linked.
>>>
>>> Also, the README may become simpler if we can link to some of the 
>>> information and not have so much detail in the README text itself.  It 
>>> might even be useful to have an .html README for that matter.  But that is 
>>> all extra.  Right now I think we want to get into the testing and see how 
>>> to smooth what we have.
>>>
>>> PS: A friend of mine is looking into the MacOSX situation.  He points out 
>>> that one can use the Finder to do the job without users having to use 
>>> Terminal sessions.  I don't have further information at this time.
>>>
>>> PPS: The inclusion of scripts that do the job is also worthy of 
>>> consideration, perhaps making it unnecessary to build executables.  I will 
>>> be looking at finding a .bat file that works safely for the Windows case.  
>>> That can make the instructions much shorter :).
>>>

 To cut a long story short:
 I would say yes for a ZIP file for every platform.
>>> [ ... ]
>>>
>>>
>>> -
>>> To unsubscribe, e-mail: dev-unsubscr...@op

Re: Download Junit and Hamcrest in ./bootstrap?

[Kay Schenk]

On 08/11/2016 01:05 PM, Kay Schenk wrote:
> 
> On 08/11/2016 09:53 AM, Don Lewis wrote:
>> On 11 Aug, Kay sch...@apache.org wrote:
>>>
>>> On 08/11/2016 01:42 AM, Damjan Jovanovic wrote:
 Hi

 If you've been checking the buildbots you'll see that all who don't use
 --without-junit are currently broken in ./configure due to junit being too
 old. This is unlikely to change, as the buildslaves are running Ubuntu
 10.04 which doesn't have newer versions of Junit available in apt.

 This is part of a bigger problem, which is that Junit's dependencies
 changed multiple times in the 4.x releases, which is why I changed
 configure.ac to need at least 4.11 (the maximum being 4.12).

 Instead of needing a correct system Junit version to run tests during the
 build, and having to worry about having correct system versions of Hamcrest
 on the classpath, should we not rather treat them like external
 dependencies and download specific versions during ./bootstrap? It's under
 300 kB for both, and the bvt/fvt/pvt tests already download their own copy.

 Damjan

>>>
>>> This would be OK with me. What version of the jre does Junit 4.11
>>> require? I can't find information about this on the junit site
>>> --http://junit.org/junit4/
>>>
>>> Right now, we're still spec'd at jdk 1.6 for everything except Windows,
>>> but IMO we should advance to 1.7 .
>>
>> That sounds good to me as well, but are there any issues with installing
>> a newer jdk on older Linux distributions that we still support?
> 
> Andrea put out a notice for setting up a production farm of machines --
> see:
>  
> http://mail-archives.apache.org/mod_mbox/openoffice-dev/201608.mbox/%3C57AA12CA.1090207%40apache.org%3E
> 
> We'd have to use CentOS 5.11 since this is the only 5 version that is
> NOT deprecated. It looks like java 1.7 SDK is available for that
> distribution.
> 
> http://mirror.centos.org/centos/5.11/os/i386/CentOS/
> 
> We also know that the older branch 4.1.2 will not work with java 1.7,

[sorry I misspoke here. 4.1.2 will NOT work with java 1.8. 4.2 works
with either java 1.7 or java 1.8]

> but I have had no problems with my older CentOS 6.8 setup with either
> java 1.7 or java 1.8.
> 
> In any case, once the initial VMs in the production farm are setup,
> we'll need additional help with setup and testing. Hopefully, once we're
> out of the 4.x versions, we can move on to a later CentOS version.
> 
> 

-- 

MzK

"Time spent with cats is never wasted."
   -- Sigmund Freud

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

Re: [PACKAGING 4.1.2-patch1 Binaries] (was RE: [TESTING] Applying openoffice-4.1.2-patch1 for Windows)

[Kay sch...@apache.org]

On 08/09/2016 02:12 PM, Kay Schenk wrote:
> [top posting]
> I'm in the process of trying to "sync" instructions for Linux32,
> Linux64, and MacOSX at the moment. As far as instructions on the actual
> HOTFIX page, we need to have just a "general" instruction for ALL zips
> that simply says -- "Unzip this package to some folder of your choosing
> and read the README that's included." Everything else should be in the
> various READMEs for each platform.
> 
> I should be done with all edits by this evening for a final review
> before zipping and signing.

Ok, I've now moved on to creating zip files, etc for Linux32, Linux64
and Mac.

My openssl version on does NOT supply digest sha256. Is it OK to use
sha1? MD5 already computed for each of these.

> 
> On 08/05/2016 09:28 AM, Dennis E. Hamilton wrote:
>> Branching off the part that is not about the Windows 4.1.2-patch1 [TESTING].
>>
>>> -Original Message-
>>> From: Marcus [mailto:marcus.m...@wtnet.de]
>>> Sent: Thursday, August 4, 2016 15:52
>>> To: dev@openoffice.apache.org
>>> Subject: Re: [TESTING] Applying openoffice-4.1.2-patch1 for Windows
>>>
>>> Am 08/05/2016 12:26 AM, schrieb Kay Schenk:
>> [ ... ]

 hmmm...well no zips for Mac, Linux32, or Linux 64 -- yet.

 Should we get started on these?
>>>
>>> it depends what we want that they should contain. The ZIP file for
>>> Windows contains a LICENSE and NOTICE file as well as an ASC file for
>>> the DLL. As it is only a patch IMHO we don't need to provide another
>>> LICENSE and NOTICE file which is already available in the OpenOffice
>>> installation. Also the ASC is not necessary as we provide it already
>>> (together with MD5 and SHA256) for the whole ZIP file.
>> [orcmid] 
>>
>> I think there is a misunderstanding.  Two matters:
>>
>>  1. The use of LICENSE is required by the ALv2 itself, and the ASF practice 
>> is to include NOTICE as well on binary distributions.  The patch qualifies, 
>> especially when it is moved to general distribution.  It is also easy and 
>> harmless to provide.
>>
>>  2. The reason for preserving the .asc on the shared-library binary is 
>> because it authenticates with respect to who produced it and establishes 
>> that it has not been modified as supplied in the package (or as the result 
>> of some glitch in creation of the Zip).  It provides a level of 
>> accountability and, also, auditability.
>>
>> Even though few people will check all of these, they remain possible to be 
>> checked.  Since this is a matter of security vulnerabilities and involves 
>> elevation of privilege to perform, I believe it is important to demonstrate 
>> diligence and care, so that users have confidence in this procedure to the 
>> extent they are comfortable.  Also, if it becomes necessary to troubleshoot 
>> a problem with these patch applications, we have the means to authenticate 
>> what they are using to ensure there are no counterfeits being offered to 
>> users.
>>>
>>> That means that only the README and library file remains.
>>>
>>> When the README for Windows keep its length then I don't want to copy
>>> this on the dowload webpage. ;-)
>>>
>>> So, when we put the README for all platforms in their ZIP files then we
>>> can just put a pointer to it on the download webpage and thats it.
>> [orcmid] 
>>
>> Yes, that seems like a fine idea.  The README can be linked the same way the 
>> .md5, .sha256, and .asc are linked.
>>
>> Also, the README may become simpler if we can link to some of the 
>> information and not have so much detail in the README text itself.  It might 
>> even be useful to have an .html README for that matter.  But that is all 
>> extra.  Right now I think we want to get into the testing and see how to 
>> smooth what we have.
>>
>> PS: A friend of mine is looking into the MacOSX situation.  He points out 
>> that one can use the Finder to do the job without users having to use 
>> Terminal sessions.  I don't have further information at this time.
>>
>> PPS: The inclusion of scripts that do the job is also worthy of 
>> consideration, perhaps making it unnecessary to build executables.  I will 
>> be looking at finding a .bat file that works safely for the Windows case.  
>> That can make the instructions much shorter :).
>>
>>>
>>> To cut a long story short:
>>> I would say yes for a ZIP file for every platform.
>> [ ... ]
>>
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
>> For additional commands, e-mail: dev-h...@openoffice.apache.org
>>
> 

-- 
Kay Schenk
Apache OpenOffice


"Things work out best for those who make
 the best of the way things work out."
 -- John Wooden

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

Re: Planning for emergency releases

[Patricia Shanahan]

On 8/11/2016 10:45 AM, Marcus wrote:

Am 08/10/2016 12:25 AM, schrieb Patricia Shanahan:

On 8/9/2016 3:12 PM, Marcus wrote:
...

we have a documented release process here [1]. Of course it's for a full
release. But for a bugfix (or emergency) release it can be derived and
then shortend.

[1]
https://cwiki.apache.org/confluence/display/OOOUSERS/Release+Planning+Template




That is the documentation I found before. Looking only at the steps
labeled "Release Manager", I do know how to make announcements on
mailing lists, even if I do sometimes get into autocomplete tangles and
pick the wrong list, and how to run votes.

That leaves

[...]


OK, then it's not what you have searched for. As I don't know the
details that are missing I cannot really help more than this.

Sorry


Don't be. It's a starting point. My next step is going to be to try to
fill in the details, doing step-by-step searches.

Meanwhile, it is interesting for contemplating a ready-to-release
strategy. We would need to pick a step at which to hold a release that
minimizes the time to put in one critical fix and ship it.

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

Re: [PACKAGING 4.1.2-patch1 Binaries] (was RE: [TESTING] Applying openoffice-4.1.2-patch1 for Windows)

[Marcus]

Am 08/10/2016 05:03 AM, schrieb Dennis E. Hamilton:



-Original Message-
From: Marcus [mailto:marcus.m...@wtnet.de]
Sent: Tuesday, August 9, 2016 15:26
To: dev@openoffice.apache.org
Subject: Re: [PACKAGING 4.1.2-patch1 Binaries] (was RE: [TESTING]
Applying openoffice-4.1.2-patch1 for Windows)

Am 08/09/2016 11:12 PM, schrieb Kay Schenk:

[top posting]
I'm in the process of trying to "sync" instructions for Linux32,
Linux64, and MacOSX at the moment. As far as instructions on the

actual

HOTFIX page, we need to have just a "general" instruction for ALL zips
that simply says -- "Unzip this package to some folder of your

choosing

and read the README that's included." Everything else should be in the
various READMEs for each platform.


yes, this shortens the webpage a lot.


I should be done with all edits by this evening for a final review
before zipping and signing.


When the ZIP files are ready, I can do the checks for Linux and Windows.

Marcus

[orcmid]

I have a working Windows batch-file script for installing the patch, but I have 
not updated the documentation yet and I need to do tests on Windows XP to make 
certain that the script works there too.

The next update for Windows will be version 0.1.0 and be beta level.

There might be an 0.2.0 if the README is changed from .txt to .html to get 
around line-ending incompatibilities depending on what platform is used for 
what.

Once those clear, we can look at adjustments for 1.0.0 and general release 
after a little regression checking.

I suspect the general will happen on Thursday or Friday.


that fits perfectly for my weekend. I can do tests on Windows 10 and 
also update the documentation - or at least make some suggestions.


Marcus




On 08/05/2016 09:28 AM, Dennis E. Hamilton wrote:

Branching off the part that is not about the Windows 4.1.2-patch1

[TESTING].



-Original Message-
From: Marcus [mailto:marcus.m...@wtnet.de]
Sent: Thursday, August 4, 2016 15:52
To: dev@openoffice.apache.org
Subject: Re: [TESTING] Applying openoffice-4.1.2-patch1 for Windows

Am 08/05/2016 12:26 AM, schrieb Kay Schenk:

[ ... ]


hmmm...well no zips for Mac, Linux32, or Linux 64 -- yet.

Should we get started on these?


it depends what we want that they should contain. The ZIP file for
Windows contains a LICENSE and NOTICE file as well as an ASC file

for

the DLL. As it is only a patch IMHO we don't need to provide another
LICENSE and NOTICE file which is already available in the OpenOffice
installation. Also the ASC is not necessary as we provide it already
(together with MD5 and SHA256) for the whole ZIP file.

[orcmid]

I think there is a misunderstanding.  Two matters:

   1. The use of LICENSE is required by the ALv2 itself, and the ASF

practice is to include NOTICE as well on binary distributions.  The
patch qualifies, especially when it is moved to general distribution.
It is also easy and harmless to provide.


   2. The reason for preserving the .asc on the shared-library binary

is because it authenticates with respect to who produced it and
establishes that it has not been modified as supplied in the package (or
as the result of some glitch in creation of the Zip).  It provides a
level of accountability and, also, auditability.


Even though few people will check all of these, they remain possible

to be checked.  Since this is a matter of security vulnerabilities and
involves elevation of privilege to perform, I believe it is important to
demonstrate diligence and care, so that users have confidence in this
procedure to the extent they are comfortable.  Also, if it becomes
necessary to troubleshoot a problem with these patch applications, we
have the means to authenticate what they are using to ensure there are
no counterfeits being offered to users.


That means that only the README and library file remains.

When the README for Windows keep its length then I don't want to

copy

this on the dowload webpage. ;-)

So, when we put the README for all platforms in their ZIP files then

we

can just put a pointer to it on the download webpage and thats it.

[orcmid]

Yes, that seems like a fine idea.  The README can be linked the same

way the .md5, .sha256, and .asc are linked.


Also, the README may become simpler if we can link to some of the

information and not have so much detail in the README text itself.  It
might even be useful to have an .html README for that matter.  But that
is all extra.  Right now I think we want to get into the testing and see
how to smooth what we have.


PS: A friend of mine is looking into the MacOSX situation.  He points

out that one can use the Finder to do the job without users having to
use Terminal sessions.  I don't have further information at this time.


PPS: The inclusion of scripts that do the job is also worthy of

consideration, perhaps making it unnecessary to build executables.  I
will be looking at finding a .bat file that works safely for the Windows
case.  That can make the ins

Re: Planning for emergency releases

[Marcus]

Am 08/10/2016 12:25 AM, schrieb Patricia Shanahan:

On 8/9/2016 3:12 PM, Marcus wrote:
...

we have a documented release process here [1]. Of course it's for a full
release. But for a bugfix (or emergency) release it can be derived and
then shortend.

[1]
https://cwiki.apache.org/confluence/display/OOOUSERS/Release+Planning+Template



That is the documentation I found before. Looking only at the steps
labeled "Release Manager", I do know how to make announcements on
mailing lists, even if I do sometimes get into autocomplete tangles and
pick the wrong list, and how to run votes.

That leaves

[...]


OK, then it's not what you have searched for. As I don't know the 
details that are missing I cannot really help more than this.


Sorry

Marcus


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

Re: Download Junit and Hamcrest in ./bootstrap?

[Don Lewis]

On 11 Aug, Kay sch...@apache.org wrote:
> 
> On 08/11/2016 01:42 AM, Damjan Jovanovic wrote:
>> Hi
>> 
>> If you've been checking the buildbots you'll see that all who don't use
>> --without-junit are currently broken in ./configure due to junit being too
>> old. This is unlikely to change, as the buildslaves are running Ubuntu
>> 10.04 which doesn't have newer versions of Junit available in apt.
>> 
>> This is part of a bigger problem, which is that Junit's dependencies
>> changed multiple times in the 4.x releases, which is why I changed
>> configure.ac to need at least 4.11 (the maximum being 4.12).
>> 
>> Instead of needing a correct system Junit version to run tests during the
>> build, and having to worry about having correct system versions of Hamcrest
>> on the classpath, should we not rather treat them like external
>> dependencies and download specific versions during ./bootstrap? It's under
>> 300 kB for both, and the bvt/fvt/pvt tests already download their own copy.
>> 
>> Damjan
>> 
> 
> This would be OK with me. What version of the jre does Junit 4.11
> require? I can't find information about this on the junit site
> --http://junit.org/junit4/
> 
> Right now, we're still spec'd at jdk 1.6 for everything except Windows,
> but IMO we should advance to 1.7 .

That sounds good to me as well, but are there any issues with installing
a newer jdk on older Linux distributions that we still support?


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

Re: Download Junit and Hamcrest in ./bootstrap?

[Don Lewis]

On 11 Aug, Damjan Jovanovic wrote:
> Hi
> 
> If you've been checking the buildbots you'll see that all who don't use
> --without-junit are currently broken in ./configure due to junit being too
> old. This is unlikely to change, as the buildslaves are running Ubuntu
> 10.04 which doesn't have newer versions of Junit available in apt.
> 
> This is part of a bigger problem, which is that Junit's dependencies
> changed multiple times in the 4.x releases, which is why I changed
> configure.ac to need at least 4.11 (the maximum being 4.12).
> 
> Instead of needing a correct system Junit version to run tests during the
> build, and having to worry about having correct system versions of Hamcrest
> on the classpath, should we not rather treat them like external
> dependencies and download specific versions during ./bootstrap? It's under
> 300 kB for both, and the bvt/fvt/pvt tests already download their own copy.

That's fine with me as long as it is still an option to use the system
version as long as it is recent enough.


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

Re: Download Junit and Hamcrest in ./bootstrap?

[Damjan Jovanovic]

On Thu, Aug 11, 2016 at 6:03 PM, Kay sch...@apache.org 
wrote:

>
> On 08/11/2016 01:42 AM, Damjan Jovanovic wrote:
> > Hi
> >
> > If you've been checking the buildbots you'll see that all who don't use
> > --without-junit are currently broken in ./configure due to junit being
> too
> > old. This is unlikely to change, as the buildslaves are running Ubuntu
> > 10.04 which doesn't have newer versions of Junit available in apt.
> >
> > This is part of a bigger problem, which is that Junit's dependencies
> > changed multiple times in the 4.x releases, which is why I changed
> > configure.ac to need at least 4.11 (the maximum being 4.12).
> >
> > Instead of needing a correct system Junit version to run tests during the
> > build, and having to worry about having correct system versions of
> Hamcrest
> > on the classpath, should we not rather treat them like external
> > dependencies and download specific versions during ./bootstrap? It's
> under
> > 300 kB for both, and the bvt/fvt/pvt tests already download their own
> copy.
> >
> > Damjan
> >
>
> This would be OK with me. What version of the jre does Junit 4.11
> require? I can't find information about this on the junit site
> --http://junit.org/junit4/
>
>
Unzipping 4.11's JAR and running "file *" on some class files gives this:

ResultPrinter.class: compiled Java class data, version 49.0 (Java 1.5)
TestRunner.class:compiled Java class data, version 49.0 (Java 1.5)
package-info.class:  compiled Java class data, version 49.0 (Java 1.5)



> Right now, we're still spec'd at jdk 1.6 for everything except Windows,
> but IMO we should advance to 1.7 .
>
>
+1. It would also be a major improvement to use 1.7's AutoCloseable and
try-with-resources to control UNO object lifetimes instead of relying on
garbage collection or explicit calls to dispose().

Re: Download Junit and Hamcrest in ./bootstrap?

[Kay sch...@apache.org]

On 08/11/2016 01:42 AM, Damjan Jovanovic wrote:
> Hi
> 
> If you've been checking the buildbots you'll see that all who don't use
> --without-junit are currently broken in ./configure due to junit being too
> old. This is unlikely to change, as the buildslaves are running Ubuntu
> 10.04 which doesn't have newer versions of Junit available in apt.
> 
> This is part of a bigger problem, which is that Junit's dependencies
> changed multiple times in the 4.x releases, which is why I changed
> configure.ac to need at least 4.11 (the maximum being 4.12).
> 
> Instead of needing a correct system Junit version to run tests during the
> build, and having to worry about having correct system versions of Hamcrest
> on the classpath, should we not rather treat them like external
> dependencies and download specific versions during ./bootstrap? It's under
> 300 kB for both, and the bvt/fvt/pvt tests already download their own copy.
> 
> Damjan
> 

This would be OK with me. What version of the jre does Junit 4.11
require? I can't find information about this on the junit site
--http://junit.org/junit4/

Right now, we're still spec'd at jdk 1.6 for everything except Windows,
but IMO we should advance to 1.7 .

-- 
Kay Schenk
Apache OpenOffice


"Things work out best for those who make
 the best of the way things work out."
 -- John Wooden

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

Download Junit and Hamcrest in ./bootstrap?

[Damjan Jovanovic]

Hi

If you've been checking the buildbots you'll see that all who don't use
--without-junit are currently broken in ./configure due to junit being too
old. This is unlikely to change, as the buildslaves are running Ubuntu
10.04 which doesn't have newer versions of Junit available in apt.

This is part of a bigger problem, which is that Junit's dependencies
changed multiple times in the 4.x releases, which is why I changed
configure.ac to need at least 4.11 (the maximum being 4.12).

Instead of needing a correct system Junit version to run tests during the
build, and having to worry about having correct system versions of Hamcrest
on the classpath, should we not rather treat them like external
dependencies and download specific versions during ./bootstrap? It's under
300 kB for both, and the bvt/fvt/pvt tests already download their own copy.

Damjan