Remember, Gavin (builds@a.o) claim he changed nothing on the slave
that's now failing. I'm sure we didn't change anything on the Jenkins
job that is now failing. It isn't something in the SDK that's causing
this, lot's of people and the Mustella VM are building that regularly.

Anyway: I'm not familiar with Pixelbender at all, is there some way we
can ask Gavin to test it on the slave that doesn't involve Jenkins?
Like a command line that he can simply copy-paste into a shell and
give us the results from?

EdB



On Tue, Dec 10, 2013 at 8:06 AM, Alex Harui <aha...@adobe.com> wrote:
> I tried to reproduce the failure on my machine but couldn't.  I tried
> different path statements, removing the aif_* dlls, and changing execute
> rights on those dlls.  I did find that the string "Internal Exception" is
> in the aif_core.dll.
>
> Not sure what to do next, but now I'm thinking: maybe nobody has seen this
> on their local computers?  Only on the Jenkins Windows Slave and Windows
> VM?  What do they have in common?  What version of Windows are they
> running?  What kind of graphics cards do they have?
>
> -Alex
>
> On 12/9/13 11:38 AM, "OmPrakash Muppirala" <bigosma...@gmail.com> wrote:
>
>>On Dec 9, 2013 10:56 AM, "Alex Harui" <aha...@adobe.com> wrote:
>>>
>>> Ah, that thread looked like it was a year old.  Did you work around it
>>>or
>>> just stop working on it?
>>
>>I just stopped working on it because I hit a dead end.  I was clueless as
>>to how to fix it.
>>
>>>
>>> Other than checking the path, I don't have any ideas to try at the
>>>moment.
>>>
>>> On your Azure VM, if you manually launch the compiler from Windows
>>>command
>>> prompt you get this error, right?
>>>
>>
>>I will try it out tonight and let you know.
>>
>>Thanks,
>>Om
>>
>>> -Alex
>>>
>>> On 12/9/13 10:48 AM, "OmPrakash Muppirala" <bigosma...@gmail.com> wrote:
>>>
>>> >On Dec 9, 2013 10:35 AM, "Alex Harui" <aha...@adobe.com> wrote:
>>> >>
>>> >> We keep hitting this error, but the mail archives do not document how
>>we
>>> >> fix it.  This time, we should write down the answer.  Om's hit it,
>>> >>Justin
>>> >> hit it, I think I had it once.  The emails seem to indicate that it
>>> >>ispath
>>> >> related, but the build.xml does at least check if the pbutil.exe
>>>exists
>>> >> and is passing on that.
>>> >>
>>> >
>>> >In my case, I have not been able to fix it.  In fact, if we are trying
>>>to
>>> >reproduce the problem, we could use my Mustella VM on Azure and see if
>>>we
>>> >can figure out what is happening.
>>> >We can then apply that fix to the windows1 slave on builds.apache.org
>>> >
>>> >Thanks,
>>> >Om
>>> >
>>> >> I'll try to see if I can repro on my windows box tonight.
>>> >>
>>> >> -Alex
>>> >>
>>> >> On 12/9/13 12:16 AM, "Maurice Amsellem" <maurice.amsel...@systar.com>
>>> >> wrote:
>>> >>
>>> >> >Thanks Erik for the clarification.
>>> >> >
>>> >> >I confirm to you, I had to send the updated swc manually for testing
>>> >> >because the nightly build was down.
>>> >> >
>>> >> >Sorry, I didn't follow the thread from the beginning, so I checked
>>>the
>>> >> >archives, maybe have missed something.
>>> >> >
>>> >> >I can see from the build logs that pixel bender build failed and it
>>> >>seems
>>> >> >to be a path issue.
>>> >> >If that's correct, this is the path I am using on my local build in
>>>my
>>> >> >env.properties:
>>> >> >
>>> >> >env.PIXELBENDER_HOME=C:\\Program Files (x86)\\Adobe\\Adobe
>>>Utilities -
>>> >> >CS5\\Pixel Bender Toolkit 2
>>> >> >
>>> >> >I can see that in the build log, the path is:
>>> >> >
>>> >> >check-pixelbender-home:
>>> >> >     [echo] PIXELBENDER_HOME is C:/Program Files (x86)/Adobe/Adobe
>>> >> >Utilities - CS5/Pixel Bender Toolkit 2
>>> >> >
>>> >> >When I run it on my local env, it gives the following:
>>> >> >
>>> >> >[echo]
>>> >> >PIXELBENDER_HOME is C:\Program Files (x86)\Adobe\Adobe Utilities -
>>> >> >CS5\Pixel Bender Toolkit 2
>>> >> >
>>> >> >So maybe using "\" instead of "/" could fix the issue ?
>>> >> >
>>> >> >WDYT?
>>> >> >
>>> >> >Maurice
>>> >> >
>>> >> >-----Message d'origine-----
>>> >> >De : Erik de Bruin [mailto:e...@ixsoftware.nl]
>>> >> >Envoyé : lundi 9 décembre 2013 08:53
>>> >> >À : dev@flex.apache.org
>>> >> >Objet : [Builds/Jenkins] Help and advise needed
>>> >> >
>>> >> >Hi,
>>> >> >
>>> >> >I'm having some difficulty getting the 'regular' builds on
>>>'build@a.o'
>>> >> >working. For those not subscribed to the builds list, the situation
>>>is
>>> >>as
>>> >> >follows:
>>> >> >
>>> >> >- there are supposedly 9 admins for the windows1 slave, but only one
>>is
>>> >> >sporadically active. I've requested access to the machine, but got
>>>the
>>> >> >answer: "nine is enough." A suggestions there was actually only one,
>>> >>with
>>> >> >8 ghosts fell on deaf ears. Apparently, it makes no sense to remove
>>> >>old,
>>> >> >inactive admins and add new, active ones
>>> >> >
>>> >> >- since the windows1 slave is old, full and overworked, it regularly
>>> >>went
>>> >> >down for days on end. We are one of the few projects that uses the
>>> >> >windows slaves, so I ended up being the guy who always complains the
>>> >> >slave is down...
>>> >> >
>>> >> >- the one active admin is now working on a second slave (windows2).
>>>In
>>> >> >itself, that is a very good thing. However, in his own words, "he
>>feels
>>> >> >entitled to use our builds to experiment." I feel that is wrong,
>>>but I
>>> >> >know better than to further aggravate my relation with him by
>>objecting
>>> >> >too strongly.
>>> >> >
>>> >> >The point of this elaborate introduction is this: somewhere in his
>>> >> >experiments he broke the Windows slaves for our builds. We have not
>>> >>had a
>>> >> >successful build in a week. Normally, not that big a deal, but with
>>the
>>> >> >third party IDE people working on FlexJS and the very active mobile
>>> >> >development both relying on nightly builds, I feel this is not a
>>>time
>>> >>to
>>> >> >NOT have clean, daily builds of all our projects...
>>> >> >
>>> >> >Anything 'negative' I say on the builds list will certainly make
>>things
>>> >> >worse - my NL temperament and lack of finesse often does not sit
>>>well
>>> >> >with US recipients ;-) - so I would ask you to please chime in on
>>>the
>>> >> >builds list and that we together get our builds back to functioning.
>>> >> >
>>> >> >Thanks!
>>> >> >
>>> >> >EdB
>>> >> >
>>> >> >
>>> >> >
>>> >> >--
>>> >> >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