You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@openoffice.apache.org by Andrea Pescetti <pe...@apache.org> on 2016/08/09 17:28:42 UTC
Ready to setup release build machines?
Seeing the issue from a purely technical point of view (i.e., imagining
for a while that there is no cost associated and no Infra around), how
far are we from having an "Apache OpenOffice build farm" where we can
build releases?
Note: this is not a buildbot. Buildbots are meant to check that the
build is not broken. They do create install sets, but for example the
Linux builds wouldn't be as compatible as the ones we build on CentOS 5.
What I mean here is VMs able to build a release.
I think that within two-three weekends I could theoretically be able to
setup a Linux-based VM host and two KVM-based VMs running CentOS 5 (32
and 64 bit) that would be able to build releases and that could have
shared access (i.e., not only me but other active PMC members). But this
would only cover a small subset of users.
What about Windows? Would someone be able, under the same hypothesis, to
add a Windows VM to the stack? This would bring us much closer to full
coverage.
And what about Mac? If I recall correctly, one is tied with Apple
hardware for MacOS X. What would be a way to bring Mac builds under
"collective" control?
Regards,
Andrea.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: Ready to setup release build machines?
Posted by Kay Schenk <ka...@gmail.com>.
On Tue, Aug 9, 2016 at 10:28 AM, Andrea Pescetti <pe...@apache.org>
wrote:
> Seeing the issue from a purely technical point of view (i.e., imagining
> for a while that there is no cost associated and no Infra around), how far
> are we from having an "Apache OpenOffice build farm" where we can build
> releases?
>
> Note: this is not a buildbot. Buildbots are meant to check that the build
> is not broken. They do create install sets, but for example the Linux
> builds wouldn't be as compatible as the ones we build on CentOS 5. What I
> mean here is VMs able to build a release.
>
> I think that within two-three weekends I could theoretically be able to
> setup a Linux-based VM host and two KVM-based VMs running CentOS 5 (32 and
> 64 bit) that would be able to build releases and that could have shared
> access (i.e., not only me but other active PMC members). But this would
> only cover a small subset of users.
>
Fantastic! ... maybe. I MIGHT be able to do some things but I'm on CentOS
6.8.
In any case, if at all possible, we could set them up LIKE the buildbots in
terms of nightly scheduling etc. Yes, I know cron! :)
>
> What about Windows? Would someone be able, under the same hypothesis, to
> add a Windows VM to the stack? This would bring us much closer to full
> coverage.
>
> And what about Mac? If I recall correctly, one is tied with Apple hardware
> for MacOS X. What would be a way to bring Mac builds under "collective"
> control?
>
> Regards,
> Andrea.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
> For additional commands, e-mail: dev-help@openoffice.apache.org
>
>
--
----------------------------------------------------------------------
MzK
"Time spent with cats is never wasted."
-- Sigmund Freud
Re: Ready to setup release build machines?
Posted by Andrea Pescetti <pe...@apache.org>.
Ariel Constenla-Haile wrote:
> On Wed, Sep 21, 2016 at 12:10:29AM +0200, Andrea Pescetti wrote:
>> (the way it is now; I haven't checked
>> https://bz.apache.org/ooo/show_bug.cgi?id=127120 yet) it uses only packages
>> from CentOS and EPEL repositories, plus custom Ant and Perl as the versions
>> shipping with CentOS 5 are too old.
>
> With the commit for this bug, in AOO413 you can use Perl from CentOS
> repos
Thanks Ariel, I've now regenerated the VM using system Perl. Everything
worked correctly.
https://wiki.openoffice.org/wiki/Documentation/Building_Guide_AOO/Step_by_step#CentOS_5
is now updated to work with distribution-supplied packages only.
The only package we don't download from the distribution is Ant, but
that is unavoidable. So the recipe is now as simple and clean as it can be.
New Linux-64 binaries are uploaded to
http://home.apache.org/~pescetti/openoffice-4.1.3-dev-r1761683/
For Patricia's roadmap, this means that anyone can take the recipe at
https://wiki.openoffice.org/wiki/Documentation/Building_Guide_AOO/Step_by_step#CentOS_5
and produce a full set of Linux release builds from scratch, using
documented processes and tools, in less than 24 hours (perhaps a bit
more considering we are all volunteers, but still a matter of days and
not months).
Regards,
Andrea.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: Ready to setup release build machines?
Posted by Ariel Constenla-Haile <ar...@apache.org>.
On Wed, Sep 21, 2016 at 12:10:29AM +0200, Andrea Pescetti wrote:
> On 04/09/2016 Andrea Pescetti wrote:
> >https://wiki.openoffice.org/wiki/Documentation/Building_Guide_AOO/Step_by_step#CentOS_5
> >Ideally, this would become a semi-scriptable recipe for preparing a
> >"standard" CentOS 5 VM for building OpenOffice releases, at least for
> >the 4.1.x series
>
> The recipe has now been updated including some clarifications from Ariel at
>
> https://wiki.openoffice.org/wiki/Documentation/Building_Guide_AOO/Step_by_step#CentOS_5
>
> and (the way it is now; I haven't checked
> https://bz.apache.org/ooo/show_bug.cgi?id=127120 yet) it uses only packages
> from CentOS and EPEL repositories, plus custom Ant and Perl as the versions
> shipping with CentOS 5 are too old.
With the commit for this bug, in AOO413 you can use Perl from CentOS
repos, see
https://wiki.openoffice.org/wiki/Documentation/Building_Guide_AOO#General_Build_Requirements
yum install \
perl-libwww-perl \
perl-Archive-Zip \
perl-Digest-SHA \
perl-XML-Parser \
perl-Crypt-SSLeay \
Regards
--
Ariel Constenla-Haile
La Plata, Argentina
Re: Ready to setup release build machines?
Posted by Andrea Pescetti <pe...@apache.org>.
On 04/09/2016 Andrea Pescetti wrote:
> https://wiki.openoffice.org/wiki/Documentation/Building_Guide_AOO/Step_by_step#CentOS_5
> Ideally, this would become a semi-scriptable recipe for preparing a
> "standard" CentOS 5 VM for building OpenOffice releases, at least for
> the 4.1.x series
The recipe has now been updated including some clarifications from Ariel at
https://wiki.openoffice.org/wiki/Documentation/Building_Guide_AOO/Step_by_step#CentOS_5
and (the way it is now; I haven't checked
https://bz.apache.org/ooo/show_bug.cgi?id=127120 yet) it uses only
packages from CentOS and EPEL repositories, plus custom Ant and Perl as
the versions shipping with CentOS 5 are too old.
With these fixes, I was able to build on CentOS 5 with the release build
options.
A few resulting Linux-64 builds (English, German, Italian) are at
http://home.apache.org/~pescetti/openoffice-4.1.3-dev-r1761552/
and it would be good if someone can test that they work. They already
identify themselves as 4.1.3 since I used release options, but of course
they are dev builds as the directory name implies.
Regards,
Andrea.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: Ready to setup release build machines?
Posted by Andrea Pescetti <pe...@apache.org>.
On 29/08/2016 Kay Schenk wrote:
> \u200bThanks for all this work. I suggest trying builds on /trunk and I would
> bet the Perl problems go away. The new Java downloader is super!
Seeing the situation, I would still prefer to be able to build 4.1.2
correctly (which works now, but JUnit and Perl modules are not
contemplated in the standard system and are thus not so clean).
> P\u200blease let us know how we can further contribute to this effort.\u200b
I've added my notes to a new section of the "Building on different
environments" page:
https://wiki.openoffice.org/wiki/Documentation/Building_Guide_AOO/Step_by_step#CentOS_5
Ideally, this would become a semi-scriptable recipe for preparing a
"standard" CentOS 5 VM for building OpenOffice releases, at least for
the 4.1.x series (it may also work for trunk, obviously, but repeating
4.1.2 is the best exercise we can do).
Regards,
Andrea.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: Ready to setup release build machines?
Posted by Kay Schenk <ks...@apache.org>.
On Mon, Aug 29, 2016 at 12:02 AM, Andrea Pescetti <pe...@apache.org>
wrote:
> On 21/08/2016 Kay Schenk wrote:
>
>> We REALLY REALLY NEED the CentOS5 32-bit and 64-bit VMS regardless of
>> what we do for Windows.
>>
>
> I now have a repeatable process to create a CentOS 5 VM from scratch and
> building OpenOffice with it, meaning that I've successfully built 4.1.2 on
> it. I also have a ~200 MBytes snapshot (compressed disk image) that
> provides a minimal CentOS 5 where one can in principle install all needed
> dependencies through a script and build OpenOffice.
>
YAY!
>
> I am still unsatisfied about some dependencies, namely the Perl
> dependencies and JUnit. I'd like to have a clean way for installing them,
> but unfortunately the default versions of other packages on CentOS 5 are
> too old. Fore reference, http://markmail.org/message/mnqv3ncast7754zw
> does not work for me while the discussion in
> http://mail-archives.apache.org/mod_mbox/incubator-ooo-dev/
> 201206.mbox/%3CCALcb3vJd7t0CfgqCeCV7JmND43pECiwuovgjR8jVWdoF
> bDs5Dw@mail.gmail.com%3E is promising but incomplete. The idea is:
> install both the needed Perl modules and JUnit in the least obtrusive way.
>
Well we can work on this but the combination of CentOS5 and newer packs is
problematic I'm sure. I couldn't get some of the packs I needed for CenttOS
6.8 using standard repos.
> For the current, successful, build I disabled JUnit and used workarounds
> to get around Perl modules needed by ./bootstrap by mirroring packages on a
> local server. Things might be better by switching to the new Java-based
> downloader by Damjan, but I am now building 4.1.2 and not trunk (so I might
> want to "backport" the new downloader).
>
> Conceptually, we COULD use the Win7 buildbot to
>> spin out the binaries for each language, but, then there's that download
>> them ALL and do the signing on some other box I was talking about earlier.
>>
>
> I can assure you that uploading dozens GBytes to SVN is more painful...
> but you will have the occasion to try it out and compare. Fact is, whatever
> one wants to do, if Windows is missing then we have the n-th incomplete
> solution.
>
OK. We can discuss this later...soon.
>
> What do you need from us to get this going? Were you planning on doing
>> the CentOS5 installations and then get back to us?
>>
>
> A reference VM is the first step, and this is quite close. In an ideal
> world, we would then ask Infra to host a VM; but we already know this will
> be difficult due to the need for Infra to standardize on a few variants. So
> it might be that the outcome of my work is a nice wiki page that can be
> used to setup a release-capable build machine with minimal effort.
>
> It was time-limited and it expired. I'm not sure what Infra decided to
>>> do (they were examining options for code signing, with no big preference
>>> for the solution in use; this was about 6 months ago).
>>>
>> OK, we need to touch bases with them. And, find a committer that knows
>> how to do this.
>>
>
> We've never signed our Windows installers this way (we do sign; just, not
> in a way that bypasses Windows warnings). It must be said that we've
> received virtually no requests for this by Windows users. Maybe I need to
> clarify the answer above: yes, I did get -now expired- access to a
> web-based signing system but we have never used it.
>
More details in a separate thread would be helpful.
>
> Regards,
> Andrea.
Thanks for all this work. I suggest trying builds on /trunk and I would
bet the Perl problems go away. The new Java downloader is super!
P
lease let us know how we can further contribute to this effort.
--
--------------------------------------------------
Kay Schenk
Apache OpenOffice
"Things work out best for those who make
the best of the way things work out."
-- John Wooden
Re: Ready to setup release build machines?
Posted by Andrea Pescetti <pe...@apache.org>.
On 21/08/2016 Kay Schenk wrote:
> We REALLY REALLY NEED the CentOS5 32-bit and 64-bit VMS regardless of
> what we do for Windows.
I now have a repeatable process to create a CentOS 5 VM from scratch and
building OpenOffice with it, meaning that I've successfully built 4.1.2
on it. I also have a ~200 MBytes snapshot (compressed disk image) that
provides a minimal CentOS 5 where one can in principle install all
needed dependencies through a script and build OpenOffice.
I am still unsatisfied about some dependencies, namely the Perl
dependencies and JUnit. I'd like to have a clean way for installing
them, but unfortunately the default versions of other packages on CentOS
5 are too old. Fore reference,
http://markmail.org/message/mnqv3ncast7754zw does not work for me while
the discussion in
http://mail-archives.apache.org/mod_mbox/incubator-ooo-dev/201206.mbox/%3CCALcb3vJd7t0CfgqCeCV7JmND43pECiwuovgjR8jVWdoFbDs5Dw@mail.gmail.com%3E
is promising but incomplete. The idea is: install both the needed Perl
modules and JUnit in the least obtrusive way.
For the current, successful, build I disabled JUnit and used workarounds
to get around Perl modules needed by ./bootstrap by mirroring packages
on a local server. Things might be better by switching to the new
Java-based downloader by Damjan, but I am now building 4.1.2 and not
trunk (so I might want to "backport" the new downloader).
> Conceptually, we COULD use the Win7 buildbot to
> spin out the binaries for each language, but, then there's that download
> them ALL and do the signing on some other box I was talking about earlier.
I can assure you that uploading dozens GBytes to SVN is more painful...
but you will have the occasion to try it out and compare. Fact is,
whatever one wants to do, if Windows is missing then we have the n-th
incomplete solution.
> What do you need from us to get this going? Were you planning on doing
> the CentOS5 installations and then get back to us?
A reference VM is the first step, and this is quite close. In an ideal
world, we would then ask Infra to host a VM; but we already know this
will be difficult due to the need for Infra to standardize on a few
variants. So it might be that the outcome of my work is a nice wiki page
that can be used to setup a release-capable build machine with minimal
effort.
>> It was time-limited and it expired. I'm not sure what Infra decided to
>> do (they were examining options for code signing, with no big preference
>> for the solution in use; this was about 6 months ago).
> OK, we need to touch bases with them. And, find a committer that knows
> how to do this.
We've never signed our Windows installers this way (we do sign; just,
not in a way that bypasses Windows warnings). It must be said that we've
received virtually no requests for this by Windows users. Maybe I need
to clarify the answer above: yes, I did get -now expired- access to a
web-based signing system but we have never used it.
Regards,
Andrea.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: Ready to setup release build machines?
Posted by "Kay Schenk@apache.org" <ks...@apache.org>.
On 08/21/2016 10:46 AM, Andrea Pescetti wrote:
> On 19/08/2016 Dennis E. Hamilton wrote:
>> I thought that the basic requirement is that the release manager(s) do
>> any builds on a machine under their [exclusive] individual control.
>
> This way one would need to rely on individual volunteers to coordinate
> for a release. It is not impossible, of course. All our Apache
> OpenOffice releases have used this model so far. But a shared
> environment allows for knowledge sharing. And a developer can always
> clone the shared VM locally for total control on his builds (assuming
> trust between the PMC members having access). Or he can rebuild his
> environment from scratch, but always with a "reference" VM that he can
> inspect.
Well, this would depend on who wanted access I guess -- I mean given
your original proposal. You didn't' specify how login credentials would
be maintained.
>
> Anyway I'm not going to start the effort unless someone says that this
> could be useful for Windows builds too.
We REALLY REALLY NEED the CentOS5 32-bit and 64-bit VMS regardless of
what we do for Windows. Conceptually, we COULD use the Win7 buildbot to
spin out the binaries for each language, but, then there's that download
them ALL and do the signing on some other box I was talking about earlier.
I think we need this "production farm" soon! It would be great to set it
up and just run it weekly under cron with ALL langs as soon as possible.
What do you need from us to get this going? Were you planning on doing
the CentOS5 installations and then get back to us? Do you need a
commitment for the WindowsVM?
>
>> I believe that Andrea has the private key that was issued for that but
>> we have not managed to use it to sign the code.
>
> It was time-limited and it expired. I'm not sure what Infra decided to
> do (they were examining options for code signing, with no big preference
> for the solution in use; this was about 6 months ago).
OK, we need to touch bases with them. And, find a committer that knows
how to do this.
>
>> That private key is precious and is not to be shared.
>
> The understanding in this case is that it shouldn't be on shared
> infrastructure. But the other benefits of shared environments still hold.
>
> Regards,
> Andrea.
Thanks so much for this update!
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
> For additional commands, e-mail: dev-help@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-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: Ready to setup release build machines?
Posted by Andrea Pescetti <pe...@apache.org>.
On 19/08/2016 Dennis E. Hamilton wrote:
> I thought that the basic requirement is that the release manager(s) do
> any builds on a machine under their [exclusive] individual control.
This way one would need to rely on individual volunteers to coordinate
for a release. It is not impossible, of course. All our Apache
OpenOffice releases have used this model so far. But a shared
environment allows for knowledge sharing. And a developer can always
clone the shared VM locally for total control on his builds (assuming
trust between the PMC members having access). Or he can rebuild his
environment from scratch, but always with a "reference" VM that he can
inspect.
Anyway I'm not going to start the effort unless someone says that this
could be useful for Windows builds too.
> I believe that Andrea has the private key that was issued for that but we have not managed to use it to sign the code.
It was time-limited and it expired. I'm not sure what Infra decided to
do (they were examining options for code signing, with no big preference
for the solution in use; this was about 6 months ago).
> That private key is precious and is not to be shared.
The understanding in this case is that it shouldn't be on shared
infrastructure. But the other benefits of shared environments still hold.
Regards,
Andrea.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: Ready to setup release build machines?
Posted by "Kay Schenk@apache.org" <ks...@apache.org>.
On 08/19/2016 10:37 AM, Dennis E. Hamilton wrote:
>
>
>> -----Original Message-----
>> From: Kay Schenk [mailto:kay.schenk@gmail.com]
>> Sent: Friday, August 19, 2016 09:09
>> To: dev@openoffice.apache.org
>> Subject: Re: Ready to setup release build machines?
>>
>>
>>
>> On 08/12/2016 12:22 PM, Dennis E. Hamilton wrote:
>>> I thought that the basic requirement is that the release manager(s) do
>> any builds on a machine under their [exclusive] individual control.
>> That also means satisfying baseline requirements for release builds
>> though. That pretty much requires use of a VM if the main development
>> system of a release manager is aligned with different tools and
>> dependencies.
>>
>> I don't find any requirement like this vis a vis building by the release
>> manager per se. The release is voted on by the community. So, in a
>> sense, building/testing is the responsibility of all who vote on a
>> release.
>>
>> See: www.apache.org/dev/release-publishing.html
> [orcmid]
>
> That page is rather obsolete. For example, we have two branches on dist.apache.org, one of which is for dev (and where we put release candidates) and the other is release where we move any approved candidates. The dist ... release contents are automatically mirrored to archive.apache.org which seems to be the proper place to refer to these (although there is mirroring to consider, but not for 4.1.2-patch1).
>
> The release page does not address binaries. I saw the business about where official binaries are to be built somewhere and must find it.
The Release Publishing page does address binaries:
http://www.apache.org/dev/release-publishing.html
It also discusses the importance of "distribution" of ASF releases on
ASF servers but doesn't say anything about how that distribution, either
source or binaries, is created with respect equipment ownership, etc.
Publishing Releases is linked from the Release Policy page:
http://www.apache.org/dev/release
>
> Since we put binaries through a form of this process (usually concurrently) there does need to be some sort of provenance on those binaries.
>
>
>>
>>>
>>> I am not so certain about putting up shared release-build VMs on non-
>> ASF infrastructure though.
>>
>> Our "official", "required" release artifact is the source code for a
>> release.
>>
>>>
>>> One advantage to using ASF infrastructure is to bring code signing
>> into the fold. That seems rather important down the road.
>>
>> We have been signing ALL release artifacts -- including all the binaries
>> -- since AOO 3.4. So code signing of everything we release is already
>> part of this process.
> [orcmid]
>
> The use of PGP signatures on our release artifacts is a different matter than code signing that is recognized by the operating system and is part of the installer, not a detached signature that users must check manually. The signatures I meant are *embedded* in the artifacts, including .msi, .dll, and .exe files.
>
> I was thinking of this form of signed installs. That is a big deal for Windows, where the OS will check them automatically, and they are also reported in the Properties for the signed artifact. It also applies to all of the DLLs and such that are loaded with the install. I believe that Andrea has the private key that was issued for that but we have not managed to use it to sign the code. This is usually done as part of building distributable binaries.
>
> That private key is precious and is not to be shared. Ideally, it would belong to root@ but I don't think we have a process for that.
>
>
>>
>> We require a production environment accessible by the release manager
>> and helpers because producing distribution binaries in another location
>> (seperate developer machine), signing and then uploading ALL the
>> binaries to SourceForce by individuals is a horrendous undertaking.
>> Ariel Constenla-Haile provided binaries for the 3.4 release and I'm sure
>> he can attest to this. If we can set up a production environment under
>> ASF infrastructure, of course this would be ideal. But, I see no reason
>> why this environment couldn't have shell access by AOO developers who
>> are likely to do code signing.
>>
>>
> [ ... ]
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
> For additional commands, e-mail: dev-help@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-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
RE: Ready to setup release build machines?
Posted by "Dennis E. Hamilton" <de...@acm.org>.
> -----Original Message-----
> From: Kay Schenk [mailto:kay.schenk@gmail.com]
> Sent: Friday, August 19, 2016 09:09
> To: dev@openoffice.apache.org
> Subject: Re: Ready to setup release build machines?
>
>
>
> On 08/12/2016 12:22 PM, Dennis E. Hamilton wrote:
> > I thought that the basic requirement is that the release manager(s) do
> any builds on a machine under their [exclusive] individual control.
> That also means satisfying baseline requirements for release builds
> though. That pretty much requires use of a VM if the main development
> system of a release manager is aligned with different tools and
> dependencies.
>
> I don't find any requirement like this vis a vis building by the release
> manager per se. The release is voted on by the community. So, in a
> sense, building/testing is the responsibility of all who vote on a
> release.
>
> See: www.apache.org/dev/release-publishing.html
[orcmid]
That page is rather obsolete. For example, we have two branches on dist.apache.org, one of which is for dev (and where we put release candidates) and the other is release where we move any approved candidates. The dist ... release contents are automatically mirrored to archive.apache.org which seems to be the proper place to refer to these (although there is mirroring to consider, but not for 4.1.2-patch1).
The release page does not address binaries. I saw the business about where official binaries are to be built somewhere and must find it.
Since we put binaries through a form of this process (usually concurrently) there does need to be some sort of provenance on those binaries.
>
> >
> > I am not so certain about putting up shared release-build VMs on non-
> ASF infrastructure though.
>
> Our "official", "required" release artifact is the source code for a
> release.
>
> >
> > One advantage to using ASF infrastructure is to bring code signing
> into the fold. That seems rather important down the road.
>
> We have been signing ALL release artifacts -- including all the binaries
> -- since AOO 3.4. So code signing of everything we release is already
> part of this process.
[orcmid]
The use of PGP signatures on our release artifacts is a different matter than code signing that is recognized by the operating system and is part of the installer, not a detached signature that users must check manually. The signatures I meant are *embedded* in the artifacts, including .msi, .dll, and .exe files.
I was thinking of this form of signed installs. That is a big deal for Windows, where the OS will check them automatically, and they are also reported in the Properties for the signed artifact. It also applies to all of the DLLs and such that are loaded with the install. I believe that Andrea has the private key that was issued for that but we have not managed to use it to sign the code. This is usually done as part of building distributable binaries.
That private key is precious and is not to be shared. Ideally, it would belong to root@ but I don't think we have a process for that.
>
> We require a production environment accessible by the release manager
> and helpers because producing distribution binaries in another location
> (seperate developer machine), signing and then uploading ALL the
> binaries to SourceForce by individuals is a horrendous undertaking.
> Ariel Constenla-Haile provided binaries for the 3.4 release and I'm sure
> he can attest to this. If we can set up a production environment under
> ASF infrastructure, of course this would be ideal. But, I see no reason
> why this environment couldn't have shell access by AOO developers who
> are likely to do code signing.
>
>
[ ... ]
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: Ready to setup release build machines?
Posted by Kay Schenk <ka...@gmail.com>.
On 08/12/2016 12:22 PM, Dennis E. Hamilton wrote:
> I thought that the basic requirement is that the release manager(s) do any builds on a machine under their [exclusive] individual control. That also means satisfying baseline requirements for release builds though. That pretty much requires use of a VM if the main development system of a release manager is aligned with different tools and dependencies.
I don't find any requirement like this vis a vis building by the release
manager per se. The release is voted on by the community. So, in a
sense, building/testing is the responsibility of all who vote on a release.
See: www.apache.org/dev/release-publishing.html
>
> I am not so certain about putting up shared release-build VMs on non-ASF infrastructure though.
Our "official", "required" release artifact is the source code for a
release.
>
> One advantage to using ASF infrastructure is to bring code signing into the fold. That seems rather important down the road.
We have been signing ALL release artifacts -- including all the binaries
-- since AOO 3.4. So code signing of everything we release is already
part of this process.
We require a production environment accessible by the release manager
and helpers because producing distribution binaries in another location
(seperate developer machine), signing and then uploading ALL the
binaries to SourceForce by individuals is a horrendous undertaking.
Ariel Constenla-Haile provided binaries for the 3.4 release and I'm sure
he can attest to this. If we can set up a production environment under
ASF infrastructure, of course this would be ideal. But, I see no reason
why this environment couldn't have shell access by AOO developers who
are likely to do code signing.
>
> - Dennis
>
>> -----Original Message-----
>> From: Andrea Pescetti [mailto:pescetti@apache.org]
>> Sent: Tuesday, August 9, 2016 10:29
>> To: dev@openoffice.apache.org
>> Subject: Ready to setup release build machines?
>>
>> Seeing the issue from a purely technical point of view (i.e., imagining
>> for a while that there is no cost associated and no Infra around), how
>> far are we from having an "Apache OpenOffice build farm" where we can
>> build releases?
>>
>> Note: this is not a buildbot. Buildbots are meant to check that the
>> build is not broken. They do create install sets, but for example the
>> Linux builds wouldn't be as compatible as the ones we build on CentOS 5.
>> What I mean here is VMs able to build a release.
>>
>> I think that within two-three weekends I could theoretically be able to
>> setup a Linux-based VM host and two KVM-based VMs running CentOS 5 (32
>> and 64 bit) that would be able to build releases and that could have
>> shared access (i.e., not only me but other active PMC members). But this
>> would only cover a small subset of users.
>>
>> What about Windows? Would someone be able, under the same hypothesis, to
>> add a Windows VM to the stack? This would bring us much closer to full
>> coverage.
>>
>> And what about Mac? If I recall correctly, one is tied with Apple
>> hardware for MacOS X. What would be a way to bring Mac builds under
>> "collective" control?
>>
>> Regards,
>> Andrea.
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
>> For additional commands, e-mail: dev-help@openoffice.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
> For additional commands, e-mail: dev-help@openoffice.apache.org
>
--
--------------------------------------------
MzK
"Time spent with cats is never wasted."
-- Sigmund Freud
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
RE: Ready to setup release build machines?
Posted by "Dennis E. Hamilton" <de...@acm.org>.
I thought that the basic requirement is that the release manager(s) do any builds on a machine under their [exclusive] individual control. That also means satisfying baseline requirements for release builds though. That pretty much requires use of a VM if the main development system of a release manager is aligned with different tools and dependencies.
I am not so certain about putting up shared release-build VMs on non-ASF infrastructure though.
One advantage to using ASF infrastructure is to bring code signing into the fold. That seems rather important down the road.
- Dennis
> -----Original Message-----
> From: Andrea Pescetti [mailto:pescetti@apache.org]
> Sent: Tuesday, August 9, 2016 10:29
> To: dev@openoffice.apache.org
> Subject: Ready to setup release build machines?
>
> Seeing the issue from a purely technical point of view (i.e., imagining
> for a while that there is no cost associated and no Infra around), how
> far are we from having an "Apache OpenOffice build farm" where we can
> build releases?
>
> Note: this is not a buildbot. Buildbots are meant to check that the
> build is not broken. They do create install sets, but for example the
> Linux builds wouldn't be as compatible as the ones we build on CentOS 5.
> What I mean here is VMs able to build a release.
>
> I think that within two-three weekends I could theoretically be able to
> setup a Linux-based VM host and two KVM-based VMs running CentOS 5 (32
> and 64 bit) that would be able to build releases and that could have
> shared access (i.e., not only me but other active PMC members). But this
> would only cover a small subset of users.
>
> What about Windows? Would someone be able, under the same hypothesis, to
> add a Windows VM to the stack? This would bring us much closer to full
> coverage.
>
> And what about Mac? If I recall correctly, one is tied with Apple
> hardware for MacOS X. What would be a way to bring Mac builds under
> "collective" control?
>
> Regards,
> Andrea.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
> For additional commands, e-mail: dev-help@openoffice.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org