Simple yet radical proposition: The pbk shaders didn't evolve much, and the compiled pbj are already committed to the repo (although git history says they have been removed). So couldn't we simply comment/strip "pixelbender-compile" from the build ? If it ever happens to change, we could then recompile the pbj and recommit.
What do you think ? Maurice -----Message d'origine----- De : Erik de Bruin [mailto:e...@ixsoftware.nl] Envoyé : mardi 10 décembre 2013 08:12 À : dev@flex.apache.org Objet : Re: [Builds/Jenkins] Help and advise needed 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
