On Dec 9, 2013 11:31 PM, "Alex Harui" <aha...@adobe.com> wrote: > > > > 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.
Unfortunately I had to kill the VM and recreate a new one. I went through the whole setup and PB runs like a champ now. Good news is that I can start working on making this the second slave to Erik's VM. I am also planning on creating a public clonable image so that other committers can start creating their VMsand bring them online as well. This way, we could continue to reduce our dependence on builds@a.o. Thanks, Om > > 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 >
