On 12/9/13 11:40 PM, "Maurice Amsellem" <maurice.amsel...@systar.com> wrote:
>So we could make the compilation conditional on a env parameter, and set >that in the Jenkins job accordingly? Yes, but keep in mind that there is always a chance that someone who does use the pbj's will grab the nightly and complain. > > >Note: the current build has already a condition "unless=isLinux". Does >this mean Pixel Bender will not compile on Linux machines ? That's correct, we don't have a way to build the pbj files on Linux. > ><target name="pixelbender-compile" unless="isLinux"> > >Maurice > >-----Message d'origine----- >De : Alex Harui [mailto:aha...@adobe.com] >Envoyé : mardi 10 décembre 2013 08:33 >À : dev@flex.apache.org >Objet : Re: [Builds/Jenkins] Help and advise needed > >We could take the pixel bender compilation out of the jenkins builds, but >not our release package. It must contain the source and instructions for >building it, and the binary package must contain that compiled source so >folks don't have to compile it. > >The compiled pbj's should not be in the repo. Hopefully they were >removed. > >-Alex > >On 12/9/13 11:26 PM, "Maurice Amsellem" <maurice.amsel...@systar.com> >wrote: > >>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 >
