CSRG ACS's Repository web site
For now, only x86_64 is available, but, hopefully once the SRPMS are made available ports can be created for aarch64, without cross compiling nightmares =D. Versions 2016.10+ have a beta-working ExtProd RPM and repo with an ACS RPM in alfa. Version is number-guided to keep clear the update order for the rpm package.
ACS-acserrTypes is OK.
grepFile doesn’t exist - sedFile doesn’t exist: Extend temporary rpm path to Kit/acs/src (not bin, intentionally) /diska/home/almadev/introot/idl/.xml: No such file or directory Some tests don’t compile
ERROR: —-> ../lib/libbaselogging.a does not exist. (It does) ERROR: —-> ../lib/libacserrHandlersErrStubs.a does not exist. (It does) ERROR: —-> ../lib/libbaciErrTypePropertyStubs.a does not exist. (It does. baciidl)
warning: ThreadInfoCompositeData is internal proprietary API and may be removed in a future release (jacsutil) Note: Some input files use or override a deprecated API. Note: Recompile with -Xlint:deprecation for details Note: ./alma/ACSErrTypeCppNative/wrappers/AcsJCppAnyEx.java uses or overrides a deprecated API (acserrTypes) Note: ./alma/ACSErrTICS/wrappers/AcsJAnyTICSErrorEx.java uses or overrides a deprecated API. (acserrTypes)
Missing argument for option: -XSL Update paths of xalan.jar in acserrGen scripts : commit 32f1ac415da730 fatal error: acserr.idl: No such file or directory acserr not in global path : commit 73f733b No rule to make target acserrExceptionManager.h Usually needs to symlink that header with the ones in commit 3868fc0
/idl/baciErrTypeProperty.xml: src-resolve: Cannot resolve the name ‘common:nameType’ to a(n) ‘type definition’ component
Highlighted the ones with the least dependencies
| repeatGuard (acsutil, acsThread | outputs repeatGuard.jar) |
| acstestcompcpp ( acscomponentidl baciidl acserridl baci logging acsThread archiveevents | Produces jar outputs, needs ExtJars) |
| acsjlog (jdt maci maciidl JacORB cdbDAL acserr cdbidl acslog acscommon ExtJars jdom.jar(?) xercesImpl.jar acserrTypes loggingidl acsASsources.jar | outputs slf4j-api, replace with system’s if available) |
| loggingts ( ?/java: | acsjlog maci/idl cdbidl castor* jacsutil JacORB acsASsources.jar acserrTypes acserr lc*.jar acscontainer loggingidl acsCallbackSupport.jar) |
| loggingtsTypes (c++/java: | acsnc acscontainer ExtJars ) |
| acsdaemon (c++/java: logging ACE-TAO acscomponent maciidl acsutil acserrTypes acsqos acsalarm acserr acsThread loki acsdaemonidl | acserrj jacsutil acserrTypes acscomponent maciidl acscontainer acsjlog JacORB cdbidl acserr acscommon ) |
| acsexmpl (c++/java: | acserr maci acserrTypes junit(ExtJars) lc.jar (?) acsjlog jacsutil JacORB) |
| define (c++/java: acscommonidl acscomponentidl | xmljbind xercesImpl) |
| nsStatisticsService (c++/java: acscomponentidl | ExtJars) |
| acssamp (c++/java: acsutil cdb logging acscomponent baci/idl maci/idl acsnc TAO acserrTypes | jcont jacsutil jcontnc maci/idl acsnc/idl acserr acscommon castor* cdb acserrTypes repeatGuard ExtJars ) |
| mastercomp (c++/java : baciidl acserrTypes | jbaci jcont baciidl acserr maci acsjlog JacORB … ) |
The instalation destination of the compiled products of the main rpm package of each acs component is /usr/local, where:
Some packages generates elements in /object folder, such as Skeleton, Stubs and/or static libraries (.a files). Those elements are packaged in the devel rpm and are also installed in /usr/local, where:
Other products, such as man pages and documentation should also be in their respective /usr/local path.
The Source0 element for each acs component rpm package consists in the complete git repository of ACSCB, which is, the result of the merges explained below. The main contents of Source0, the LGPL folder is available with the acs-cb-ToolKit-devel rpm package.
The main idea applied in each package is to:
Once an rpm package is succesfully manually built, it undergoes a “strict” build under Jenkins CI, where env vars and other elements are deleted, creating a clean building environment. Lastly, each package can be tested in centos docker containers.
Currently, the main focus is to succesfully compile and package the acs components, with tat tests compiling but being allowed to temporary fail. Once the first iteration is concluded, tat tests will be fixed where necesary, considering that some tat test dependencies are different than those of the main acs component package.
yum -y update
curl https://repos.fedorapeople.org/repos/dchen/apache-maven/epel-apache-maven.repo -o /etc/yum.repos.d/epel-apache-maven.repo
yum -y install epel-release centos-release-scl
curl http://repo.csrg.cl/acs-cb.repo -o /etc/yum.repos.d/acs-cb.repo
yum install -y ACS-ExtProds ACS-ExtJars
After the instalation of ACS-ExtProds, and before de ACS instalation, a session logout-login is needed in order to load the environment variables (now in profile.d files)
In order to save time, the lookup of existing RPMs in other flavors of RPM using S.O. is highly recommended.
Also http://www.rpmfind.net and OpenSuse pages are useful.
We have a forked ACS Community Branch git which is regularly been merged against ALMA ACS’s git repository. This is what Source0 of each acs component package contains.
The main idea behind the RPMs is the use of system-available packages, which will in return allow an easier instalation/management of ACS
ExtProd is in a Beta state and ACS Core in an alfa state for 2016.10. 2017.02 hasn’t been released. The SPEC files can be found at this github
Initially ExtProd was built as a regular RPM with the check-rpaths commented out in .rpmmacros file. It happened because Eclipse has https://fedoraproject.org/wiki/RPath_Packaging_Draft. This appears no longer needed. Also AutoReq is set to “no”
The only packages not being from a RPM origin inside ExtProd are JacORB and Mico. Tcltk has a first version of its own package. Mico is expected to fail on RHEL 6, so this behaviour is expected also on EL/RHEL 7+, although it appears to build correctly, and includes the latest gcc6 patch.
As many ACS building/compiling needed-scripts are been left as Sources of the ExtProd RPM, also to allow modularity in their updates. This scripts are left in system default path’s such as /usr/local/bin, in order to prevent the need for path extension and modifications on the user side.
Another important point is the intend to deprecate the use of .bash_profile.acs file, leaving enviroment variables in /etc/profile.d files. For example, ExtProd RPM creates jacorb.sh, which contains and exports:
JACORB_HOME=/home/almamgr/ACS-%{version}/JacORB export JACORB_HOME
Source0 in Extprod RPM consist in the following:
ACS-ExtProd-{ACS_Version}
- INSTALL
- buildEclipse
- PRODUCTS
- eclipse-SDK-4.2.2-linux-gtk-x86_64.tar.gz
- eclipse-4.2.2-delta-pack.zip
The traditional files from the old instalation of ACS are kept as legacy but not used. All of this can be installed via the acs-cb-ToolKit-devel rpm, which is available from 2016.10+. ExtProds RPM creates user almamgr with uid 550 and the /alma symlink, which point to /home/almamgr.
Of the Tools Module built by ACS the yet not RPM encapsulated are (getopt ignored as is indicated for SunOS only):
tat xsddoc extidl vtd-xml oAW scxml_apache
All of the python packages in acs.req and acs.req.0 have been included as requirements of the rpm or installed through pip. Every package is kept as closed as possible to the one indicated in acs.req/acs.req.0 files, with the consideration that if a newer version is available, and the changelog indicates no mayor changes, then the newer version will be prefered. Also, if the version in the acs.req files is deprecated, the oldest system available version is prefered. Python 2.7 is not being compiled as it comes with CentOS 7.
As CentOS 7 is compatible with mainly every package between fedora21 and fedora24, and further for packages not involving gcc, the srpms are fetch and recompiled, allowing an interesting number of versions per package to be selected. Also RPMs from OpenSUSE and other rpm based SO is considered. The spirit of the RPM is initally to replace with system available packages as much as possible and the fix whatever may have been broken.
The following replacement/patch has been aplied to ACE-TAO 6.3.0_{ACS_Version}
sed -i ‘s/IOP::TaggedComponentList create_ior_components/IOP::TaggedComponentSeq create_ior_components/g’ /usr/include/orbsvcs/SecurityReplaceable.idl
For information about this change, please see 2008a Changelog of TAO: Removed TaggedComponentList and use TaggedComponentSeq, thefirst one is not part of the CORBA spec, the second is.
In order to create re-usable building and testing environments, there are a couple of available docker containers