Re: [cross-project-issues-dev] [platform-releng-dev] [epp-dev] Issue with the macOS bundle signing, dmg packaging and signing

2017-09-14 Thread Markus Knauer 
Same here... I enabled signing and building DMG files today, and now I'm
running our Oxygen.1 build (still running...).
The first .dmg files are already available!

Many thanks!

Regards,
Markus



On 14 September 2017 at 18:03, Daniel Megert 
wrote:

> Hi Mikaël (and all other involved parties)
>
> I was one of those pushing hard on this and also ranting. Kudos that you
> guys were able to solve the problem. We were able to have several
> successful builds in a row.
>
> Thanks a lot - really appreciated!
> Dani
>
>
>
> From:Mikaël Barbero 
> To:Eclipse Packaging Project 
> Cc:Mike Milinkovich , Webmaster <
> webmas...@eclipse.org>, platform-releng-dev-boun...@eclipse.org, Cross
> project issues , "Eclipse platform
> release engineering list." 
> Date:14.09.2017 10:47
> Subject:Re: [platform-releng-dev] [epp-dev] Issue with the macOS
> bundle signing, dmg packaging and signing
>
> Sent by:platform-releng-dev-boun...@eclipse.org
> --
>
>
>
> Hi,
>
> I'm glad to announced that the macOS services (.app signing, .dmg
> packaging and .dmg signing) have been restored on a new machine hosted
> within the Foundation VLAN.
>
> If you've disabled their usages, you can now re-enable them as it was
> before. The authentication layer I was talking about in my initial mail
> will be released later to possibly let us use resources outside of the
> Foundation VLAN. We will keep you posted.
>
> Thanks for your patience while we were resolving this issue.
>
> Cheers,
> Mikael
>
> --
> *Mikaël Barbero - *Eclipse Foundation
> IT Services - Release Engineering
>  (+33) 642 028 039
>  *mikael.barb...@eclipse-foundation.org*
> 
>  @mikbarbero
>
> Le 11 sept. 2017 à 19:56, Denis Roy <*denis@eclipse-foundation.org*
> > a écrit :
>
> Hi Dani,
>
> Just a clarification -- the current (broken) Mac services are hosted on
> our hardware. We are working on two fronts --
>
> 1. Provision a temporary new Mac to re-establish the current service
>
> 2. Provision managed/hosted Mac services to avoid these problems in the
> future, as our in-house hardware is not redundant, and does not scale.
>
> In the immediate terms, you can disable the signing parts in your build
> scripts for basically no cost, as signing is likely not needed on I-builds,
> nor to validate test results.
>
> Mikael has offered to manually sign your the last release candidates so
> that release deadlines can be met.
>
> I apologize for the inconveniences this causes, and thank you for your
> continued patience while we resolve this issue and make it better.
>
> Denis
>
>
> On 11/09/17 08:14 AM, Daniel Megert wrote:
> Can you explain why this critical/blocking hardware is hosted outside the
> Eclipse Foundation, creating more/new issues and delays? Our automated
> builds don't play well with filing bugs (for signing and DMG creation) and
> wait for resolution ;-). Ah, and BTW, our latest Photon M2 candidate build
> just failed again:
> *http://download.eclipse.org/eclipse/downloads/drops4/I20170911-0405/*
> 
>
> Dani
>
>
>
> From:Mikaël Barbero **
> 
> To:"Eclipse platform release engineering list."
> ** ,
> Eclipse Packaging Project ** 
> Cc:Webmaster ** ,
> Cross project issues **
> 
> Date:07.09.2017 14:07
> Subject:[platform-releng-dev] Issue with the macOS bundle
> signing,dmg packaging and signing
> Sent by:*platform-releng-dev-boun...@eclipse.org*
> 
> --
>
>
>
> (cross-posting to platform-releng, epp-dev and cross-projects)
>
> Hi,
>
> Recently, we've been facing a lot of issues with the services we provide
> for macOS: UI testing, macOS .app bundles signing and DMG files creation
> and signing. It has been a combination of hardware, software and network
> failures and these issues have already impacted some projects, delaying
> their milestones/releases and consuming a lot of time from their teams.
>
> Since the beginning of the week, we've setup a new machine to run UI tests
> from the Hudson shared instance (*https://hudson.eclipse.org/shared/*
> ). This machine is not hosted on our
> infra, and thus not everything that was possible can be done on the new
> machine (most notably, it's not possible

Re: [cross-project-issues-dev] [epp-dev] [platform-releng-dev] Issue with the macOS bundle signing, dmg packaging and signing

2017-09-14 Thread Mikaël Barbero 
Hi,

I'm glad to announced that the macOS services (.app signing, .dmg packaging and 
.dmg signing) have been restored on a new machine hosted within the Foundation 
VLAN.

If you've disabled their usages, you can now re-enable them as it was before. 
The authentication layer I was talking about in my initial mail will be 
released later to possibly let us use resources outside of the Foundation VLAN. 
We will keep you posted.

Thanks for your patience while we were resolving this issue.

Cheers,
Mikael

--
Mikaël Barbero - Eclipse Foundation
IT Services - Release Engineering
 (+33) 642 028 039
 mikael.barb...@eclipse-foundation.org
 @mikbarbero

> Le 11 sept. 2017 à 19:56, Denis Roy  a 
> écrit :
> 
> Hi Dani,
> 
> Just a clarification -- the current (broken) Mac services are hosted on our 
> hardware. We are working on two fronts --
> 1. Provision a temporary new Mac to re-establish the current service
> 
> 2. Provision managed/hosted Mac services to avoid these problems in the 
> future, as our in-house hardware is not redundant, and does not scale.
> 
> 
> In the immediate terms, you can disable the signing parts in your build 
> scripts for basically no cost, as signing is likely not needed on I-builds, 
> nor to validate test results.
> Mikael has offered to manually sign your the last release candidates so that 
> release deadlines can be met.
> 
> 
> I apologize for the inconveniences this causes, and thank you for your 
> continued patience while we resolve this issue and make it better.
> 
> 
> Denis
> 
> 
> On 11/09/17 08:14 AM, Daniel Megert wrote:
>> Can you explain why this critical/blocking hardware is hosted outside the 
>> Eclipse Foundation, creating more/new issues and delays? Our automated 
>> builds don't play well with filing bugs (for signing and DMG creation) and 
>> wait for resolution ;-). Ah, and BTW, our latest Photon M2 candidate build 
>> just failed again: 
>> http://download.eclipse.org/eclipse/downloads/drops4/I20170911-0405/ 
>> 
>> 
>> Dani
>> 
>> 
>> 
>> From:Mikaël Barbero  
>> 
>> To:"Eclipse platform release engineering list." 
>>  , 
>> Eclipse Packaging Project  
>> Cc:Webmaster  , 
>> Cross project issues  
>> 
>> Date:07.09.2017 14:07
>> Subject:[platform-releng-dev] Issue with the macOS bundle signing,   
>>  dmg packaging and signing
>> Sent by:platform-releng-dev-boun...@eclipse.org 
>> 
>> 
>> 
>> 
>> (cross-posting to platform-releng, epp-dev and cross-projects)
>> 
>> Hi,
>> 
>> Recently, we've been facing a lot of issues with the services we provide for 
>> macOS: UI testing, macOS .app bundles signing and DMG files creation and 
>> signing. It has been a combination of hardware, software and network 
>> failures and these issues have already impacted some projects, delaying 
>> their milestones/releases and consuming a lot of time from their teams.
>> 
>> Since the beginning of the week, we've setup a new machine to run UI tests 
>> from the Hudson shared instance (https://hudson.eclipse.org/shared/ 
>> ). This machine is not hosted on our 
>> infra, and thus not everything that was possible can be done on the new 
>> machine (most notably, it's not possible to access machines inside the 
>> Eclipse VLAN). We still need to figure out if we want to make it possible, 
>> or if we want to set this fact as a restriction.
>> 
>> We've also successfully deployed and tested the signing and dmg packaging 
>> services on a similar machine. Unfortunately, we can't switch the current 
>> unreliable services to these new ones as they are also hosted outside of the 
>> Eclipse VLAN. As you may know, the services are insecure webapps (read plain 
>> HTTP) without any sort of authentication. We were using the fact that the 
>> services were running inside the VLAN to "protect" them. Only Eclipse 
>> projects and committers were both trusted to use the service by having 
>> access to the VLAN via their Hudson/Jenkins instance.
>> 
>> Opening the new services on a machine directly connected to the internet 
>> would let anyone sign a macOS application with the Eclipse certificate. This 
>> is something we want to avoid at all cost as it would ruin all the trust one 
>> can have in this certificate. So we are working hard to add a authentication 
>> layer and run the service on top of HTTPS to be able to provide these 
>> services reliably from the new machines. But it takes some time.
>> 
>> As we

[cross-project-issues-dev] Oxygen.1 RC4 staging repo is complete

2017-09-14 Thread Frederic Gurr 
Hi,

I declare the staging repo for Oxygen.1 RC4 to be complete.

As usual, it can be found here:

http://download.eclipse.org/staging/oxygen/

Please note, we will enter quiet week for Oxygen.1. If no blocking
issues are found, RC4 will become the official Oxygen.1 release on
September 27th.

Thanks for all your contributions.

Regards,

Fred


-- 
Frederic Gurr

Release Engineer
Eclipse Foundation
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

Re: [cross-project-issues-dev] Build Schedule for Oxygen.1 RC4?

2017-09-14 Thread Frederic Gurr 
Hi,

AFAICT, the CDT bits were built in build #596
(https://hudson.eclipse.org/simrel/job/simrel.oxygen.runaggregator.BUILD__CLEAN/596/
, please note: this link will expire eventually). So they should be in.

Regards,

Fred

On 13.09.2017 19:07, Doug Schaefer wrote:
> I was just wondering what the build schedule is for Oxygen.1 RC4. I have
> updated the CDT bits and I want to make sure they get in. They’re not in
> the build that’s currently running.
> 
>  
> 
> Thanks,
> 
> Doug.
> 
>


-- 
Frederic Gurr

Release Engineer
Eclipse Foundation
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev