TWiki> EGEE Web>SA3>EGEEPorting>PortingWithEtics (revision 1)EditAttachPDF

Porting with ETICS

The page serves as a way to get porting up and running at your site.

Repositories and Websites to Watch

  1. this is the web interface were you can see your OS configurations for the gLite Middleware. Also you will need to be become familar with the externals repository.
  2. This is the status page where you can see what is to be deployed for the reference platforms. The software to create a similar few and apt/yum repository can be obtained from:
  3. is where you should post your bug reports for ETICS related issues. However should be used for gLite middleware related issues and bugs.
  4. shows the results of certain builds under ETICS.
  5. references the grid deployment dashboard and the full monolithic builds of org.glite under SLC3 and SLC4.
  6. porting page where parallel builds and Unix builds will be reported.

Email Lists to Watch

List Name E-mail list to Subscribe to
Middleware Integration

Use Simba to subscribe to these lists:

Configuration of your Build Machine

There's little to do, just download the etics-client-setup and set up a few environment variables. However if you are using http and cvs proxies, then there are a few extra things to do. The total set of environment variables you will need to setup are:

      export CVS_RSH=ssh
      unset CVSROOT
      export ETICS_HOME=/home/<username>/<your-etics-installation-directory>
      export PATH=$ETICS_HOME/etics:$PATH

If you have cvs proxies and http proxies then set:

      export http_proxy=http://yoursiteproxy:8080/
      export https_proxy=http://yoursiteproxy:8443/
      export cvs_proxy=cvs-proxy.yourdomain

In the case of cvs_proxy this will modify: :pserver:anonymous@servername:/some/path to :pserver:anonymous%servername@cvs_proxy:/some/path.

Building Individual Modules

It is suggested that you take the following issues into account then porting:

  1. Building from source: If you don't build from source then you are attempting to build from binary. To build from binary assumes that you are going to look for the binary tarball in the AFS repository: or in the case of external dependencies in:
  2. Building with verbosity: Its a good idea in the being at least to get used to building with verbosity so that you have very detailed logging information. This will help in the initial stages of getting your builds into a good state.
  3. Continuing a build in the case of errors. This is always a good idea since you want to get as many modules to build as possible first go.
  4. Force the checkout. The checkout needs to be forced if you are writing over a previous build. However in ETICS they would suggest that build in a clean workspace environment. However if for some reason (maybe during testing) you want to use a workspace with a set directory structure already checked out then you will need to include the --noask flag or use the deprecated command --forcecheckout.

Building One Module

By way of example here is how you would build one module with a given configuration assuming you want to continue on error with verbosity and forcing of the checkout.

      cd some/directory
      etics-get-project org.glite
      etics-checkout --fromsource --forcecheckout --verbose --continueonerror --projectconfig glite_branch_3_1_0 --config moduleConfiguration1 moduleName1
      etics-build --verbose --continueonerror --config moduleConfiguration1 moduleName1

Building Multiple Modules together

      cd some/directory
      etics-get-project org.glite
      etics-checkout --fromsource --forcecheckout --verbose --continueonerror --projectconfig glite_branch_3_1_0 --config moduleConfiguration1 moduleName1
      etics-checkout --fromsource --forcecheckout --verbose --continueonerror --projectconfig glite_branch_3_1_0 --merge --config moduleConfiguration2 moduleName2
      etics-checkout --fromsource --forcecheckout --verbose --continueonerror --projectconfig glite_branch_3_1_0 --merge --config moduleConfigurationN moduleNameN
      etics-build --verbose --continueonerror --config moduleConfiguration1 moduleName1
      etics-build --verbose --continueonerror --config moduleConfiguration2 moduleName2
      etics-build --verbose --continueonerror --config moduleConfigurationN moduleNameN

Building an Entire Project

      etics-get-project org.glite
      etics-checkout --fromsource --forcecheckout --verbose --continueonerror --project-config glite_branch_3_1_0 org.glite
      etics-build --verbose --continueonerror org.glite

This is what is being described in CERN as the monolithic build. It requires that you glean the RPMs/tarballs or debs packages to build a node.

More Specialised OS Specific Builds

Sometimes, well quite often in fact you need to get your OS in line with the monolithic build coming out of CERN. To do this you can set properties that ensure you get the correct versions of modules to be built. For instance you might want to use the boost v. 1.32.0-1.rhel4 instead of boost v. 1.32.0-6 for newer OSes. Or you might want to build the source version of boost using the configuration boost v. 1.32.0-src. The point is, your OS may not have these definitions defined in CERN. So what do you do?


  1. Contact and say that you want your OS to have a particular configuration added to a particular module. For instance: SLC4 has boost-1.32.0-1.rhel4 attached to its structure by default, while SLC3 has boost-1.32.0-6 attached by default.
  2. Again contact to include your configuration but test your assumption adding a property to the project build as follows:

      etics-checkout --fromsource --forcecheckout --verbose --continueonerror --property moduleName.DEFAULT="myOSconfiguration" --projectconfig glite_branch_3_1_0 org.glite

Example: In the case of CentOS 4.4 we needed the same version of boost as used by SLC4 but under SuSE 9.3 we need the source tarball version.

  1. We informed etics-support about our requirement and looked at to see that our changes were included.
  2. In the meantime we performed under CentOS 4.4:

      etics-checkout --fromsource --forcecheckout --verbose --continueonerror --property boost.DEFAULT="boost v. 1.32.0-1.rhel4" --projectconfig glite_branch_3_1_0 org.glite

Under SuSE 9.3 we performed:

      etics-checkout --fromsource --forcecheckout --verbose --continueonerror --property boost.DEFAULT="boost v. 1.32.0-src" --projectconfig glite_branch_3_1_0 org.glite

The overrides were automatically incorporated into the build.

Mixed builds

Its possible to mix project builds together, so that you can build from org.glite but also include a module from externals. By way of example:

      etics-checkout --verbose --continueonerror --forcecheckout --fromsource --property dcap.DEFAULT="dcap v. 1.2.38"   --project-config "glite_branch_3_1_0"  --config "glite-data-gfal_branch_1_7_8" 
      etics-checkout --verbose --continueonerror --forcecheckout --fromsource --project "externals"  --config "dcap v. 1.2.38"  --merge dcap 

This example is building a particular version of GFAL that requires dcap as a dependency. Note that you need to specify that dcap belongs to the externals project so that it will be included correctly.

Registering Packages

To register modules you need to include --register in the etics-build command. If you have your DN registered with etics-support you will then be allow to register your modules back into CERN. So for instance if you look at: you will see the following directories:

      [DIR] slc3_ia32_gcc323/                              21-Mar-2007 15:29    -   
      [DIR] slc4_ia32_gcc346/                              21-Mar-2007 15:34    -   
      [DIR] slc4_x86_64_gcc346/                            17-Feb-2007 02:10    -   

However if you perform a project build with --register on a new OS such as Debian you might see afterwards:

      [DIR] deb_x86_64_gcc412/                         05-Apr-2007  12:07    -  
      [DIR] slc3_ia32_gcc323/                              21-Mar-2007 15:29    -   
      [DIR] slc4_x86_64_gcc346/                         17-Feb-2007 02:10    -   
      [DIR] slc4_ia32_gcc346/                              21-Mar-2007 15:34    -   

If your site is you will then be able to see modules turn green as you build more and more modules correctly and have them registered into the AFS in CERN. Note that maps to /afs/

Getting Started

This section is at the end because its good to read the rest of the page first. To get started you should do the following:
  • Read but in particular the quick start manual:
  • Register with the e-mail list stated above.
  • Keep an eye on the dashboard and porting status page
  • Register your DN with so that you can register RPMs/tarballs or debs packages back into AFS.
  • Register with if you need to be able to edit and include new configurations of modules in the "External Dependencies" repository or in the "gLite Middleware" repository. This has to be acknowledged by the correct member of the SA3 team (its not automatic or guaranteed).
  • download the etics-client-setup and attempt a few project builds, single module builds and multiple module builds to get used to using the build system.
  • if you have your build nodes registered with NMI then you can simply use --remote-project-config instead of --project-config and --remote-platforms with a list of OS platform types you want to build on. See etics-list-platform for a complete list of platforms.

-- Main.ekenny - 05 Apr 2007

Edit | Attach | Watch | Print version | History: r2 < r1 | Backlinks | Raw View | Raw edit | More topic actions...
Topic revision: r1 - 2007-04-05 - 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