I would suggest that if you have a functioning VM, we use it to run the builds that are currently on 'builds@a.o'. That is just too high maintenance (I spend about 2 hrs a week on the various issues there).
EdB On Tue, Dec 10, 2013 at 9:36 AM, OmPrakash Muppirala <bigosma...@gmail.com> wrote: > 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 >> -- Ix Multimedia Software Jan Luykenstraat 27 3521 VB Utrecht T. 06-51952295 I. www.ixsoftware.nl
