Community
Participate
Working Groups
Our build setup for Intel architecture native builds depends too heavily on the environment variables being set up for the builder via their login environments. All true dependencies need to move to the configure-environment.agntctrl.sf files in releng instead so that the build is independent of who is running it and from where they are running it.
Randy, is this bug yours?
Yes.
Setting P1 i3.
Can wait until next release to clean this up for the build.
I'm gradually making improvements in this area. Some changes just checked in against bugzilla_#150021 actually apply to this... in particular, the new creation of slave/windows-ia32/configure-environment.agntctrl.sf. But this won't REALLY be done until the usage of the "update" scripts in my home directories on the three Windows boxes and the ia32/em64t/ipf subdirectories of the builder home directory on the Linux boxes are merged into the build automation. Can we use execute-remote command capability? Put into the configure-environment scripts?? Maybe that is just the ticket! Need to try it.
Bring Windows-IA32 environment more into the right slave configuration files rather than depending on the local environment on that specific build machine (win-ia23-build).
As I've made fixes/improvements in our build, I've tried to gradually get these environment scripts to the point they can replace all the "private environment" stuff the build systems have that we depend on. But we're not there yet. We're closer. This isn't a P1... it's actually an enhancement to our build environment. We're getting better, but it won't be there for i2, and might not be COMPLETED for 4.3 at all.
Retarget to 4.4.
Kiryl, this one is mostly done. The main remaining portion is to get rid of the update/update2 steps that depend on remote scripts. This can probably be done as part of the repackaging of src-native[-new] into a single repository (getting rid of the separate RAC library builds), or worst case turned into a usage of the execute-remote script.
Kiryl, is the remaining work containable in 4.4?
No. I have no plans to do something special on this defect for 4.4.
I would like to get back to this defect on completion of bug 182085. It seems amount of related work may significantly reduced.
As of TPTP 4.6.0, TPTP is in maintenance mode and focusing on improving quality by resolving relevant defects and increasing test coverage through test creation, automation, Build Verification Tests (BVTs), and expanded run-time execution. Since this defect is more than 2 years old, it may be no longer relevant. As part of the TPTP Bugzilla housecleaning process (see http://wiki.eclipse.org/Bugzilla_Housecleaning_Processes), this defect is resolved as WONTFIX. If this defect is still relevant and reproducible in the latest TPTP release (http://www.eclipse.org/tptp/home/downloads/), please re-open.
As of TPTP 4.6.0, TPTP is in maintenance mode and focusing on improving quality by resolving relevant enhancements/defects and increasing test coverage through test creation, automation, Build Verification Tests (BVTs), and expanded run-time execution. As part of the TPTP Bugzilla housecleaning process (see http://wiki.eclipse.org/Bugzilla_Housecleaning_Processes), this enhancement/defect is verified/closed by the Project Lead since this enhancement/defect has been resolved and unverified for more than 1 year and considered to be fixed. If this enhancement/defect is still unresolved and reproducible in the latest TPTP release (http://www.eclipse.org/tptp/home/downloads/), please re-open.
