| |
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 |
| 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 |
| 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 |
| 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 |
Copyright &© by the contributing authors. All material on this collaboration platform is the property of the contributing authors.