On 12/9/13 11:12 PM, "Erik de Bruin" <e...@ixsoftware.nl> wrote:
>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? Yeah, it is a pretty simple compiler. All we do is give it a command that is effectively pbutil <input> <output> as in: "$PIXELBENDER_HOME\pbutil.exe" $FLEX_HOME\frameworks\projects\framework\src\mx\graphics\shaderClasses\Colo r.pbk $FLEX_HOME\frameworks\projects\framework\src\mx\graphics\shaderClasses\Colo r.pbj If you have a windows machine please verify that I didn't type that wrong, I'm on my mac right now. I know everyone claims "nothing changed". But I'm wondering if we can compare Om's VM setup against yours and fix Om's setup before we go back and bug Gavin. Meanwhile, I'm trying to find the source to the compiler. I have a wild guess that the aif dlls have some silly check for graphic cards or some other Photoshop or After Effects dependency. Or maybe some OpenGL library that comes with newer versions of Windows. If it is a graphics card thing then some hardware change or configuration outside the slave itself could have caused things to fail. Then everyone would technically be right that the nothing changed in the Slave or our code. -Alex > >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
