I don't think we actually know the cause of the problem.  I am going to
continue to spend cycles to try to find out though.

It would be nice to have an alternative to builds.a.o.  I'm not sure if it
will cost Om money to run a builds server.

-Alex

On 12/10/13 2:01 AM, "Maurice Amsellem" <maurice.amsel...@systar.com>
wrote:

>I understand that.
>
>Actually, my "understanding" on this issue was that pixel bender compiler
>required some sort of hardware configuration (OpenGL, etc...) that were
>not present on the b.a.o. new Windows Jenkins slave node, so that's why
>the build was failing,  and the Apache Infra was reluctant to let us
>modify anything, or even access the VM ourselves.
>So that's why I was proposing a "software only" solution.
>
>Now, it seems from what Om is saying that we can set up and use our own
>Jenkins slave node VM.
>
>That, of course, is much preferable...
>
>Maurice
>
>-----Message d'origine-----
>De : Erik de Bruin [mailto:e...@ixsoftware.nl]
>Envoyé : mardi 10 décembre 2013 10:44
>À : dev@flex.apache.org
>Objet : Re: [Builds/Jenkins] Help and advise needed
>
>Maurice,
>
>Your help is very much appreciated!
>
>I put "legal" in quotes, the issue is not really one of the law, more of
>the rules. An Apache release is supposed to be 'source only', and we if
>we can produce needed binaries from source, we keep only the source, not
>the artefacts themselves in the repo.
>
>
>EdB
>
>
>
>On Tue, Dec 10, 2013 at 10:34 AM, Maurice Amsellem
><maurice.amsel...@systar.com> wrote:
>>>In addition to the various "legal" issues with binaries in the repo.
>> I understand it's not a good idea to have binaries in the repo, so I
>>won't insist.
>> But please can you explain what are the legal issues of having binaries
>>in the repo?  Is this because of Adobe, or ASF rules ?
>>
>> On a side note, I was just trying to help, with my limited
>> understanding and knowledge, and because the email thread was titled
>> "help and advise needed" ;-)
>>
>> Regards,
>>
>> Maurice
>>
>> -----Message d'origine-----
>> De : Erik de Bruin [mailto:e...@ixsoftware.nl] Envoyé : mardi 10
>> décembre 2013 09:12 À : dev@flex.apache.org Objet : Re:
>> [Builds/Jenkins] Help and advise needed
>>
>> In addition to the various "legal" issues with binaries in the repo,
>>we'd be masking the cause of this failure. In order to prevent further
>>deterioration of the build process, we need to figure out what went
>>wrong and fix it.
>>
>> EdB
>>
>> PS. Thanks for leaving the keyboard on the Mustella VM set to FR...
>> Took me while to figure out that I hadn't gone insane or if my
>> keyboard was broken ;-)
>>
>>
>>
>> On Tue, Dec 10, 2013 at 9:04 AM, Maurice Amsellem
>><maurice.amsel...@systar.com> wrote:
>>>> someone who does use the pbj's will grab the nightly and complain.
>>>
>>> I don't understand.
>>> Why would someone complain if the pbj's are in the nightly?
>>>
>>> [From the other emai]
>>>>Apache repos aren't supposed to contain compiled code.  The pbj files
>>>>were removed during the initial release audit.
>>>>I don't think a workaround can involve checking in the pbj files.  But
>>>>we could borrow them from a prior release package temporarily.
>>>
>>>>So we could make the compilation conditional on a env parameter,  and
>>>>set that in the Jenkins job accordingly?
>>>>Yes but ...
>>>
>>> Alex, the conversation is getting out synch, so I am not sure that I
>>>have understood what you said.
>>>
>>> So can we include the pbj in the repo, and have a parameter to
>>>conditionally compile the pbj ?
>>> - This parameter would be set by default to do the compilation (so
>>> that folks can recompile)
>>> - and turned off on the b.a.o vm, with pre-compiled pbj's.
>>>
>>>
>>> Maurice
>>>
>>
>>
>>
>> --
>> Ix Multimedia Software
>>
>> Jan Luykenstraat 27
>> 3521 VB Utrecht
>>
>> T. 06-51952295
>> I. www.ixsoftware.nl
>
>
>
>--
>Ix Multimedia Software
>
>Jan Luykenstraat 27
>3521 VB Utrecht
>
>T. 06-51952295
>I. www.ixsoftware.nl

Reply via email to