ETICS Issues and Problems

Color Coding No Patch Resolved Patched in TCD only Patched in TCD, misconfiguration

etics-client-setup problems

  OS   Architecture   client version   Description of Errors   Resolution
SL3   x86   1.0.0-1   Platform name changed to sl3_ia32_gcc323 instead of rhel3_ia32_gcc323   Yes! Changed PlatformUtils.py to change sl to rhel in dist_map definition
SuSE   x86   1.0.0-1   Package manager problems introduced with upgrade in client   Changed $ETICS_HOME/etc/packageTypes.xml and set SuSE9 to SuSE instead to fix this issue
Darwin880/772   powerpc   1.0.0-1   psyco won't compile under Mac OS breaking the ETICS install   Yes, just compare os.uname()[] == "Darwin" to fix the bug
SL3   x86   0.8.0-1   None   None
CentOS   x86   0.8.0-1   None   None
SuSE x86   0.7.2-1   After compilation and removal of traceback.py from etics/lib/python2.4/site-packages we obtain the following error at etics-get-project:   Use 0.6.5-1 temporarily although gives periodic problems with wget failing to get files resulting in long waits. Alternatively installing python-2.3.6 will allow 0.7.2-1 version to work perfectly. Error: the following unexpected error was detected: 'list index out of range' Traceback (most recent call last):
      0.8.0-1   traceback.py is not included in lib/python2.4/site-packages if "python -V == 2.4"   Tested and working: 2007-02-27
SL3   x86_64   0.7.2-1   Not checked yet   Usiing 0.6.5-1
CentOS x86_64 0.6.5-1/0.7.2-1 pthread issue in Ft of 4Suite   ln -s /lib64/libc.so.6 /lib64/libc.so
          ln -s /lib64/libpthread.so.0 /lib64/libpthread.so
          seems to be exclusively a CentOS 4.4 problem, not an SLC 4.4 problem
Darwin772   powerpc   0.7.2-1   Not checked yet   Using 0.6.5-1
Darwin880   powerpc   0.7.2-1   0.6.5-1 gives problems with pthread   Removed psyco from the 0.6.5-1 version to get it to install and work
Solaris 10   x86   0.7.2-1   0.6.5-1 gives problems with a lot of things   So far rebuilding python-2.3.6 from source with a gcc compiler has got a little further
AIX 5.2   powerpc   0.7.2-1   Not investigated yet   Not investigated yet

Build Time Issues

Problem relates to: Description of the problem Informed ETICS on date   Resolution
Misconfigured dependencies Many dependencies such as zlib, MySQL, expat, httpd, boost should not be in the build system as external dependencies, but instead should be included as Build Requires dependencies. Mailing List: 2007-06-05 ETICS are not to blame for JRA1's mismanagement of its dependencies.
gLite Entanglement Many modules are still using org.glite/project/*.xml to perform the packaging part of their builds. This is the case with org.glite.security.java-util and trustmanager which are problematic under SuSE RGMA informed All modules should be upgraded to ETICS package management where the %build line is removed when blank. This is the main cause of RPM build failures from the glite packager.
Misconfigured dependencies misconfigured dynamic dependencies should be reported in XML and HTML, not just to stderr. The build should not return success when it has inadvertantly failed. Savannah: 2007-03-09 not a bug that is persistent but must be properly logged. At the moment it is only logged at stderr or stdout. The main issue here is that the build returned success which is wrong
SLC4 should be the default build not SLC3 Reported in Savannah bug, but was told that it should be an EGEE/SA3 issue Savannah: 2007-03-08 not an ETICS bug, SA3/JRA1 issue
build-status.xml contains missing info build-status.xml contents seems to be missing entries, in particular for etics-version 0.8.0 there is no dependency information for voms-api or voms-api-c as shown by a hypergraph that was generated to demonstrate the dependency information Savannah: 2007-03-05 not a critical bug but needs fixing if we are to have a correct build hierarchy
Status report Success when no build Modules with wrongly named configurations that generate no CHECKOUT or BUILD file should not be marked as success, but instead be marked with currentstatus: Unknown in the build-status.xml Savannah: 2007-03-02 no fix required in TCD, just better XML description in build-status.xml
BuildArch wrong under SuSE The Build architecture is set in PlatformUtils.py to be i386 which is wrong. It must be ascertained from the OS. Savannah: 2007-02-23 The best way to fix it quickly it to set arch = PlatformUtils.dist()[2] if using SuSE. This is not the correct fix thought, just a quick workaround. Strictly speaking /usr/lib/rpm/rpmrc should be interrogated to find the correct architecture usage.
gLite entanglement The build system is too entangled with the glite build system. org.glite/project still exists and is even more crytic that before Laurence: 20th and 2007-02-22 Remove usage of org.glite/project/*.xml entirely and replace with Python equivalent. Make sure nobody is allowed use common build environments.
torque-2.1.6 not writing to /var pbs_resources_all.so file is deleted during the checkin step, so not an ETICS problem. But not writing to /var is an ETICS problem. Its possible that we might need to write the spec file more carefully to fix the problem. Alberto: 2007-02-05 workaround is to avoid make install step and only do a make and make rpm step where rpm step requires a {{{make -i rpm}}}
globus-2.4.3-VDT-1.2.2 VDT-1.2.2 will not build because its own libtool is being overridden by the build system which is incorrect. It should use its own build system environment. The ETICS build system is incorrectly setting up its environment somehow. Alberto: 2007-01-12 Problem was introduced by setting CVSROOT="" in a python script, thus confusing the cvs checkouts of globus-2.4.3-VDT-1.2.2 defined in globus-2.4.3-VDT-1.2.2/bin/cvs
boost-1.32.0 boost-1.32.0-6 is used under SLC3 and boost-1.32.0-1.rhel4 is used under SLC4 because there are definitions for both under boosts configuration in the web client. This seems a little strange, but if I want something that builds for all platforms I must edit the build from source configuration boost-1.32.0-6 so that it will build on all platforms. We need to ensure that boost-1.32.0.tar.gz exists in the source tarball directory. At the moment there is boost.tar.gz in the src tarball directory which is not correct for the --fromsource build option. Fix this when LXPLUS account is reinstalled. Alberto: 2007-01-12 Nothing to fix in ETICS. Instead if we want a generic boost module use boost-1.32.0.port and add -p boost.DEFAULT="boost v. boost-1.32.0.port" so that there are no conflicts with the production system

List of Known ETICS problems

Problem relates to: Description of the problem Informed ETICS on date   Resolution
builds taking too long Thought it might be the threading for the dots that is causing the issue. Builds are not completing for WN in what should be 1-2 hour builds. More recently version 0.8.0-1 will fix the problem just using --noask. Alberto: 2007-02-15 Issue is subtle. The --force command when checking out using etics-checkout still requires user input of [y/n] which when running in an automated environment causes the checkouts to hang. The solution is to already start a build in a clean directory structure. Which isn't really ideal when debugging code problems. 0.8.0-1 will fix this problem.
etics-client-setup 0.7.1-1 changes etics-build etic-build will not build different versions of the same module unless you specify the --config option to build the correct tag, this is good because it puts an order on the building of multiple versions of the one piece of code Alberto: 2007-02-01 Added -c option to tcd-etics-build to fix this change (it isn't a bug). This is better functionality
etics-client-setup fails under x86_64 pyopenssl needs to be put in lib64 under pyopenssl or the code needs to be patched so that it installs in a directory lib. Alberto: 2007-01-16 Change lib to lib64 in CommandBase.py and etics-client-setup under rhel3_x86_64_gcc323 and centos4_x86_64_gcc346. However this is fixed with an if statement for etics-client-setup-0.8.0
Staging problem When building wms-utils.tls it can be seen that its build.xml file is copying files into the staging directory. In particular its copying into a 5th nested subdirectory. On my build machines I only have /stage/share and no lower subdirectory structure. This suggests a few things. (1) The builds are not cleaned each night in CERN. (2) the build system is to tied to the old gLite build system. (3) there is probably mkdir used when mkdir -p should be used instead. A patch should not be too difficult to make for this error. Alberto: 2007-01-16 Web Client fix: Configure: mkdir -p ${m4.macros.location} ; cp ${m4.macros.location}/glite.m4 ${m4.macros.location}/globus.m4 ${m4.macros.location}/cppunit.m4 ${m4.macros.location}/optimize.m4 ./project; ./bootstrap
SuSE RPMs fail to build no RPMs will build under SuSE within ETICS which was a problem that occurred with the gLite build system as well. Turns out that commenting out two lines of the ModulePackager.py module relating to wrongly inserted empty %build instructions in spec files will fix the problem Alberto: 2007-01-15 ModulePackager.py.rpmbuild.patch Patch was implemented in ETICS: 2007-02-27
Deep Copy the deepCopy functionality used by ETICS doesn't function correctly. So it needed patching of ModuleBuilder.py Alberto: 2006-12-15 ModuleBuilder.py.patch, deepCopy is not used anymore instead a shutil command is used. We need to remove this software anyway because it is causing a problem with staging.
SuSE9_ia32_gcc335 SuSE is defined as SuSe in ModulePackager.py. This issue was only introduced recently. Previously it worked fine. Alberto: 2006-12-15 ModulePackager.py.!SuSE.patch Patched added to ETICS: 2007-02-27
SuSE9_ia32_gcc335 SuSE9_ia32_gcc335 was previously defined for SuSE systems. In recent months the definition in the ETICS database was incorrectly changed to be SuSE_ia32_gcc335. To patch the build system to conform to this error means changing lines relating to SuSE in PlatformUtils.py Alberto: 2006-12-15 PlatformUtils.py.SuSE.patch Patch added to ETICS: 2007-02-27
Staging problem globus-VDT-1.2.2 could not build the 9 RPMs correctly. Now builds without any problems if we remove the 0644 mode problematic code from the etics/lib/python2.3/site-packages/*.py code. This was due to software changing permissions as it untarred it from inside ETICS Alberto: 2006-11-03 Patched in ETICS now

Work done on ETICS

Problem relates to: Description of the Implementation Informed ETICS on date   Outcome
Hyper Graph generator The xml.dom.minidom module is used to parse build-status.xml to obtain (using highly object oriented python modules) a set of modules of org.glite and each of their dependencies. The result is a reformated XML file that is then used by hypergraph (sourceforge) project to generate the graphs ETICS/SA3: 2007-07-01 python xml.dom.minidom and hypergraph.sourceforge.net used to generate these modules. See http://grid.ie/autobuild/hypergraph
WebReactor Replaced WebReactor with an XML to Python and then Python to HTML conversion using xml.minidom and HTMLgen to create the appropriate output showing nightly build results from ETICS Alberto & MEB: 2006-12-08 HTMLgen code sent with a few later revisions
Source Tarballs twiki page https://uimon.cern.ch/twiki/bin/view/EGEE/SourceTarballs Oliver Keeble: 2006-11-30 Now maintained by Oliver/myself
Source Tarballs External dependency software required integration from source to make the build system heterogeneous Alberto & MEB: 2006-10-23 Still needs MySQL
OS versions patch added to platform utility to determine the names of OSes, distribution, version number and compiler type. MEB: 2006-08-31 SuSE, Mac OS X and AIX included
cvs_proxy TCD also requires cvs_proxy support Alberto: 2006-08-09 Patch now incorporated into ConfigurationManager.py in ETICS
http_proxy TCD requires ZSI to include http_proxy support Alberto: 2006-06-29 Implemented patch: ZSI.http_proxy.patch

Color Coding No Patch Resolved Patched in TCD only Patched in TCD, misconfiguration

-- Main.ekenny - 22 Feb 2007

Edit | Attach | Watch | Print version | History: r8 < r7 < r6 < r5 < r4 | Backlinks | Raw View | WYSIWYG | More topic actions
Topic revision: r8 - 2007-06-07 - EamonnKenny
 
    • Cern Search Icon Cern Search
    • TWiki Search Icon TWiki Search
    • Google Search Icon Google Search

    EGEE All webs login

This site is powered by the TWiki collaboration platform Powered by Perl This site is powered by the TWiki collaboration platformCopyright & by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Ask a support question or Send feedback