Differences between revisions 42 and 66 (spanning 24 versions)
Revision 42 as of 2007-09-08 13:31:49
Size: 11743
Comment:
Revision 66 as of 2016-01-10 00:05:14
Size: 21125
Editor: PaulWise
Comment: clean up build log links
Deletions are marked like this. Additions are marked like this.
Line 1: Line 1:
#language en
## page was renamed from DebianScienceROOT
#pragma section-numbers 1
<<TableOfContents(3)>>
Line 2: Line 7:
Line 4: Line 8:
   * ["DebianScience/Physics"]
 * [http://root.cern.ch ROOT upstream]

Obsolete text formerly on this page has been archived at ["DebianScienceROOT/Obsolete"].

== Port status (8/9/2007): 2 more architectures, mips and hppa ==

With the kind help of Dirk Van Hertem <dirk.vanhertem@ieee.org> and Boris (?) <boris@mogwitz.eu> we have managed to build the ROOT packages on hppa and mips.

That brings the list of supported and confirmed architectures up to
||<|2>byte order|| || ||
||word size || little-endian || big-endian||
||32-bit || i386 || powerpc, mips, hppa||
||64-bit || amd64 || ||

The list of unconfirmed architectures is now {{{
byte order | |
word size | little-endian | big-endian
-----------+---------------+---------------------
32-bit | mipsel, arm | armeb[*], m68k,
           | | sparc, s390
64 bit | ia64, alpha | powerpc64[*],
           | | s390x[*], sparc64[*]
        
[*] Experimental or not fully supported ports.
}}}
Apart from that, there's a number of non-linux ports, like{{{
hurd-i386, netbsd-i386, netbsd-alpha, kfreebsd-gnu
}}}
which have not been tested. In principle it should work on HURD but I
haven't tried it in a very long time.

== Porting notes ==
  * [[DebianScience/Physics]]
 * [[http://root.cern.ch|ROOT upstream]]
 * [[http://packages.qa.debian.org/root-system|Debian QA page]]
 * [[http://bugs.debian.org/cgi-bin/pkgreport.cgi?ordering=normal;archive=0;src=root-system;repeatmerged=0|Bugs]]
 * Package page for the metapackage in [[http://packages.debian.org/sid/root-system|Sid]] and [[http://packages.debian.org/lenny/root-system|Lenny]]
As of July 8, 2008 (or so) ROOT version 5.18 has entered Debian Lenny and is expected to be shipped with the next Debian stable release.

As of 2011, you can find ROOT version 5.28 on [[http://cern.ch/lcg-heppkg/debian/|the unofficial CERN Debian repository]].

Note: the name of the metapackage and source package, at the request of FTP masters, has been changed to ''root-system''. If you only want a minimal ROOT environment you may instead try installing ''root-system-bin''.

= Port status (25/11/2009): porterbox work =
Christian recently had guest access to some of the Debian [[http://db.debian.org/machines.cgi|porter boxes]], which meant he could check the packages on many of the Debian supported architectures. The status of this is given below. The work was done on version 5.24.00-2 (not uploaded yet).
||'''Architecture''' ||'''Build host''' ||'''Status''' ||'''Comments''' ||
||<rowbgcolor="#ffbe4e"> alpha || albeniz.debian.org || Possibly OK || Cintex not supported ||
||<rowbgcolor="#80f780"> amd64 || localhost || OK || ||
||<rowbgcolor="#df9e2e"> arm || agnesi.debian.org || Unknown || Machine down ||
||<rowbgcolor="#80f780"> armel || agricola.debian.org || OK || ||
||<rowbgcolor="#ffbe4e"> hppa || paer.debian.org || Possibly OK || Machine down ||
||<rowbgcolor="#f7f780"> i386 || ? || Likely OK || ||
||<rowbgcolor="#f7f780"> ia64 || merulo.debian.org || Likely OK || Missing build-depend ||
||<rowbgcolor="#f7f780"> mips || mahler.debian.org || Likely OK || Machine down ||
||<rowbgcolor="#f7f780"> mipsel || morales.debian.org || Likely OK || Machine down ||
||<rowbgcolor="#80f780"> powerpc || pescetti.debian.org || OK || Cintex not supported ||
||<rowbgcolor="#80f780"> sparc || smetana.debian.org || OK || Cintex not supported ||
||<rowbgcolor="#80f780"> s390 || zelenka.debian.org || OK || New to upstream ||
||<rowbgcolor="#80f780"> kfreebsd/i386 || io.debian.net || OK || New to upstream ||
||<rowbgcolor="#f7f780"> kfreebsd/amd64 || asdfasdf.debian.net || Likely OK || New to upstream ||
(more unofficial ports exists but have not been investigated yet)

See also [[https://buildd.debian.org/status/package.php?p=root-system|buildd logs]] (and possibly [[http://buildd.debian.org/pkg.cgi?pkg=root-system|here]]).

<<Anchor(porting)>>
= Porting notes =
Line 40: Line 44:
 1. Enable auto-detection in {{{configure}}}. This normally involves figuring out what platform {{{uname -m}}} returns, and then add something like {{{  1. Enable auto-detection in {{{configure}}}. This normally involves figuring out what platform {{{uname -m}}} returns, and then add something like
{{{
Line 43: Line 48:
 1. If the generic {{{linux}}} arch does not fit the machine (e.g., 64bit word-size, or big-endian, unsupported compiler options, or the like), we need to define a new platform.  
  i. Look for a similar architecture, and copy that architectures {{{config/Makefile.linux}}}''other'' to {{{config/Makefile}}}''foo''.  
   i. Set the definition in {{{configure}}} to {{{
 1. If the generic {{{linux}}} arch does not fit the machine (e.g., 64bit word-size, or big-endian, unsupported compiler options, or the like), we need to define a new platform.
  i. Look for a similar architecture, and copy that architectures {{{config/Makefile.linux}}}''other'' to {{{config/Makefile}}}''foo''.
  i. Set the definition in {{{configure}}} to
  {{{
Line 48: Line 54:
  where {{{<foo>}}} is the Debian system name.
  i. Add an entry for the architecture to {{{config/ARCHS}}} {{{
  where {{{<foo>}}} is the Debian system name.
  i. Add an entry for the architecture to {{{config/ARCHS}}}
 
{{{
Line 52: Line 59:
  i. In {{{config/root-config.in}}} add an appropriate entry for the new architecture {{{    i. In {{{config/root-config.in}}} add an appropriate entry for the new architecture
 
{{{
Line 60: Line 68:
  i. In {{{test/Makefile.arch}}} add appropriate lines for the new architecture.{{{   i. In {{{test/Makefile.arch}}} add appropriate lines for the new architecture.
  
{{{
Line 70: Line 79:
  i. Check that the platform is properly identified by the ''XRootd'' in the {{{xrootd/src/xrootd/configure.classic}}} script {{{   i. Check that the platform is properly identified by the ''XRootd'' in the {{{xrootd/src/xrootd/configure.classic}}} script
 
{{{
Line 73: Line 83:
   i. Also add an entry to {{{xrootd/src/xrootd/ARCHS}}} {{{   i. Also add an entry to {{{xrootd/src/xrootd/ARCHS}}}. Note, that you may need to specify a different compiler config, especially if the option {{{-m32}}} is not recognised. In that case, you should also modify {{{xrootd/src/xrootd/configure.classic}}} to recognise the architecture, and possibly add a configuration file in {{{xrootd/src/xrootd/config/MakeRules.gccfoo}}}
  {{{
Line 76: Line 87:
 1.#3 Check that the system is properly recognized in {{{base/inc/RConfig.h}}}. Run {{{  1. Check that the system is properly recognized in {{{base/inc/RConfig.h}}}. Run
{{{
Line 79: Line 91:
 to see a list of GCC predefined pre-processor symbols. Look for an chip definition (e.g., {{{__i386__}}}, {{{__powerpc__}}}). If no valid entry exists in {{{base/inc/RConfig.h}}}, then add something like {{{#!cplusplus   to see a list of GCC predefined pre-processor symbols. Look for an chip definition (e.g., {{{__i386__}}}, {{{__powerpc__}}}). If no valid entry exists in {{{base/inc/RConfig.h}}}, then add something like
 {{{
#!cplusplus
Line 92: Line 106:
 1.#4 Check that the chip/os combo is properly detected in {{{clib/src/Getline.c}}}. The generic entries may be OK - that is the pre-processor conditional {{{#!cplusplus   1. Check that the chip/os combo is properly detected in {{{clib/src/Getline.c}}}. The generic entries may be OK - that is the pre-processor conditional
{{{
#!cplusplus
Line 108: Line 124:
 the ''second'' POSIX branch will be chosen ({{{termios.h}}} is included). If not, add detection code as for for example {{{R__MIPSLINUX}}} and include that define in the BSD excluded list above.

Non-Linux platforms may need more work. The basic thing is to assume that the OS is like Linux, except of course, if there's a closer alternative, like BSD or Cygwin.

== Breaking news (17/05/2007): ROOT accepted for experimental ==

See end of bug [http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=325306 325306].

You will be able to use your favorite "experimental" mirror to download and install the packages. Just put
 the ''second'' POSIX branch will be chosen ({{{termios.h}}} is included). If not, add detection code as for for example {{{R__MIPSLINUX}}} and include that define in the BSD excluded list above.
 1. In {{{cint/inc/G__ci.h}}} check that CINT knows how to deal with variadic arguments to functions. Check if there's some entry that corresponds more or less to the the OS/CPU combo, and make a new switch. For example
 {{{
#!cplusplus
#elif (defined(__foo__)&&defined(__linux__))
/**********************************************
 * FOO, Linux
 **********************************************/
#if defined(_ABI64) /* For 64-bit word size */
# define G__VAARG_INC_COPY_N 8
#else
# define G__VAARG_INC_COPY_N 4
#endif
#define G__VAARG_PASS_BY_REFERENCE 8
#else
/**********************************************
 * Other platforms,
 * Try copying object as value.
 **********************************************/
#define G__VAARG_NOSUPPORT
#define G__VAARG_INC_COPY_N 4
/* #define G__VAARG_PASS_BY_REFERENCE 8 */
#endif
}}}
 If this does not work, you will get the error message
 {{{
Limitation: Variable argument is not supported for this platform
}}}
 when executing interpreted code like
 {{{
#!cplusplus
Form("Hello, World from %s", "me")
}}}
 In this case, we will need input from the [[http://root.cern.ch/Cint.html|CINT]] developers. Send a message to cint@root.cern.ch describing the problem and the architecture (OS, chip, kernel version, compiler, etc.).
Non-Linux platforms may need more work. The basic thing is to assume that the OS is like Linux, except of course, if there's a closer alternative, like BSD or Cygwin.

= Builder scripts =
[[attachement:root-system-build.sh|build.sh]], [[attachement:root-system-changes.sh|changes.sh]]

These two files should be put in a sub-directory called '''extra''' which is on the same level as the ROOT source code.

You should have
Line 118: Line 167:
deb ftp://ftp.NN.debian.org/debian/ ../project/experimental main contrib
}}}
where '''NN''' is your mirror country code, into your ''/etc/apt/sources.list'' or ''/etc/apt/sources.list.d/experimental.list''.
 
Note: the name of the metapackage and source package, at the request of FTP masters, has been changed to ''root-system''. If you only want a minimal ROOT environment you may instead try installing ''root-system-bin''.

== Future plans ==
> ls
extra root
> ls extra
build.sh changes.sh
}}}

You can execute
{{{
../extra/build.sh
}}}
from the {{{root}}} source directory to build the packages.

 * If no {{{../root-system-<version>.orig}}} or {{{../root-system-<version>.orig.tar.gz}}} exists, the script will check-out from the [[https://root.cern.ch/svn/root/trunk|ROOT Subversion]] repository. The What will be checked out depends on the version check-out in the `root` source directory:
  * If the version has an ''even'' minor number (e.g., 5.24.00) then the corresponding tag will be check-out (e.g., [[https://root.cern.ch/svn/root/tags/v5-24-00]])
  * If the version has an ''odd'' minor number (e.g.m, 5.25.02) the the trunk will be checked out.
 * If no {{{../root-system-<version>.orig.tar.gz}}} does not exists, it is created from {{{../root-system-<version>.orig}}}.
 * The {{{root}}} directory is updated from subversion.
 * {{{svn status -u}}} is run to get a list of modified, removed, and added files (relative to subversion), and the following files are created (empty files will be ommited):
  * {{{changes-<version>.patch}}}: Patch of modified files
  * {{{removed-<version>.list}}}: List of files removed
  * {{{added-<version>.tar.gz}}}: Archive of added files
  * {{{summary-<version>}}}: Summary of changes. Monitor this for possible conflicts.
 * {{{dpkg-buildpackage}}} is called to build the packages.
 * {{{lintian}}} is run over the generated packages with informative output.

Some of these steps can be skipped and the packages can be built using [[http://packages.debian.org/sid/pbuilder|pbuilder]]. Do
{{{
../extra/build.sh --help
}}}
for more information.


= Future plans =
Line 126: Line 201:
 * Unfortunately the next production release of ROOT, '''5.16.00''', is not expected until post-Etch, but we intend to upload ROOT 5.16 to [http://backports.org backports.org] for Etch users once it is in unstable.
 * Next production release of ROOT ('''5.16.00''') is planed for June 27, 2007. We will make packages of that, and upload to "unstable".

== History ==
 * [http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=325306 ITP] submitted by ChristianHolm.
   * Packages uploaded to [http://ftp-master.debian.org/new.html NEW] queue on April 27, 2006, by KevinMcCarty and ChristianHolm. These were targeted for "experimental".
   * FTPmaster rejected these packages on the grounds of licensing issues. In the mean time, these issues have been worked out with the upstream authors and 3rd party developers.
   * Since then, the debian/copyright file has been greatly expanded, and the copyright holders of the non-free material were contacted and agreed to relicense it under LGPL. New ROOT packages targeted at "experimental" were uploaded to the NEW queue on November 3, 2006.
   * These packages were unfortunately rejected due to "too generic name". We (KevinMcCarty and ChristianHolm) have asked the FTP masters for input on names that would be acceptable, but so far we have had no response.
   * To use the experimental archive, add the following to your "/etc/apt/sources.list", where "NN" is your favorite mirror (say, us, no, fi, jp, or dk), and run "apt-get update":
{{{
        deb ftp://ftp.NN.debian.org/debian/ ../project/experimental main
}}}
 * Unfortunately the current production release of ROOT, '''5.20.00''', has been released probably too late to make it into Lenny, but we intend to upload ROOT 5.20 to [[http://backports.org|backports.org]] for Lenny users once it is in unstable.

= History =
The information below is historic and archived. It is reproduced here for reference.

 * [[http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=325306|ITP]] submitted by ChristianHolm.
 * Packages uploaded to [[http://ftp-master.debian.org/new.html|NEW]] queue on April 27, 2006, by KevinMcCarty and ChristianHolm. These were targeted for "experimental".
 * FTPmaster rejected these packages on the grounds of licensing issues. In the mean time, these issues have been worked out with the upstream authors and 3rd party developers.
 * Since then, the debian/copyright file has been greatly expanded, and the copyright holders of the non-free material were contacted and agreed to relicense it under LGPL. New ROOT packages targeted at "experimental" were uploaded to the NEW queue on November 3, 2006.
 * These packages were unfortunately rejected due to "too generic name". A third upload to experimental, with the source and some binary packages renamed, was permitted to enter the archive.
 * ROOT 5.18 was uploaded to unstable in mid-June 2008, and following a new upload with some FTBFS bug fixes, entered the current testing distribution "Lenny" on about July 8, 2008.

== Port status (23/09/2009): Buildd port status ==
The current port status is summarised below. See also [[https://buildd.debian.org/status/package.php?p=root-system|buildd logs]] (and possibly [[http://buildd.debian.org/pkg.cgi?pkg=root-system|here]]).
||||||'''Currently accepted ports'''||
|| '''[[http://en.wikipedia.org/wiki/Little_endian|byte order]]/[[http://en.wikipedia.org/wiki/Word_size|word size]]''' ||''little-endian''||''big-endian''||
||''32-bit''|| [[http://www.debian.org/port/i386|i386]], [[http://wwww.debian.org/ports/mips|mipsel]] || [[http://www.debian.org/ports/mips|mips]], [[http://www.debian.org/ports/hppa|hppa]] ||
||''64-bit''||[[http://www/debian.org/ports/amd64|amd64, ]][[http://www.debian.org/ports/ia64|ia64]]|| ||
||||||'''Currently awaiting dependencies'''||
|| '''[[http://en.wikipedia.org/wiki/Little_endian|byte order]]/[[http://en.wikipedia.org/wiki/Word_size|word size]]''' ||''little-endian''||''big-endian''||
||''32-bit''||<^>[[TheHurd|hurd-i386]]||[[M68k/Porting|m68k]], ||
||''64-bit''|| || ||
||||||'''Failed on buildd'''||
|| '''[[http://en.wikipedia.org/wiki/Little_endian|byte order]]/[[http://en.wikipedia.org/wiki/Word_size|word size]]''' ||''little-endian''||''big-endian''||
||<^>''32-bit''||<^>[[ArmPort|arm]]||<^>[[ArmEabiPort|armel]], [[http://www.debian.org/ports/s390/|s390]], [[http://www.debian.org/ports/powerpc|powerpc]], [[PortsSparc|sparc]],||
||''64-bit''||[[http://www.debian.org/ports/alpha|alpha]]||<^>||

=== Notes on failed archs ===

  * powerpc failes because of missing build-dep on libsm-dev.
  * alpha - conflicting prototypes in ''cint/lib/posix/posix.h'' - most likely a wrong CPP condition.
  * arm - unclear why it fails, no logs.
  * armel - Incomplete support in XRootd
  * kfreebsd-* - need to implement autodetection of architecture. Please also refer to [[#Portingnotes]] below.
  * s390 - unknown, logs missing
  * sparc - xrootd explicitly disabled in debian/rules - it shouldn't be.

== Port status (8/9/2007): 2 more architectures, mips and hppa ==
With the kind help of Dirk Van Hertem <[[mailto:dirk.vanhertem@ieee.org|dirk dot vanhertem at ieee dot org]]> and Boris (?) <[[mailto:boris@mogwitz.eu|boris at mogwitz dot eu]]> we have managed to build the ROOT packages on [[http://www.debian.org/ports/hppa/|hppa]] and [[http://www.debian.org/ports/mips/|mips]]. Thiemo Seufer <[[mailto:ths@networkno.de|ths at networkno dot de]]> helped on porting to [[http://www.debian.org/ports/mips/|mipsel]].

That brings the list of supported and confirmed architectures up to
||||||'''Currently accepted ports'''||
|| '''[[http://en.wikipedia.org/wiki/Little_endian|byte order]]/[[http://en.wikipedia.org/wiki/Word_size|word size]]''' || ''little-endian'' || ''big-endian'' ||
|| ''32-bit'' || [[http://www.debian.org/port/i386|i386]], [[http://wwww.debian.org/ports/mips|mipsel]] || [[http://www.debian.org/ports/powerpc|powerpc]], [[http://www.debian.org/ports/mips|mips]], [[http://www.debian.org/ports/hppa|hppa]] ||
|| ''64-bit'' || [[http://www/debian.org/ports/amd64|amd64]] || ||
||||||'''Currently untested ports'''||
|| '''[[http://en.wikipedia.org/wiki/Little_endian|byte order]]/[[http://en.wikipedia.org/wiki/Word_size|word size]]''' || ''little-endian'' || ''big-endian'' ||
|| ''32-bit'' || [[ArmPort|arm]] || [[ArmEabiPort|armeb[*]]], [[M68k/Porting|m68k]], [[PortsSparc|sparc]], [[http://www.debian.org/ports/s390|s390]][[http://www.debian.org/ports/s390|,]] ||
|| ''64 bit'' || [[http://www.debian.org/ports/ia64|ia64]], [[http://www.debian.org/ports/alpha|alpha]] || [[http://debian-ppc64.alioth.debian.org/|ppc64[*]]], s390x[*], sparc64[*] ||
||||||'''Unsupported accepted ports'''||
|| '''[[http://en.wikipedia.org/wiki/Little_endian|byte order]]/[[http://en.wikipedia.org/wiki/Word_size|word size]]''' || ''little-endian'' || ''big-endian'' ||
|| ''32-bit'' || [[TheHurd|hurd-i386]], [[http://www.debian.org/ports/netbsd/|netbsd-i386]], [[Debian_GNU/kFreeBSD|kfreebsd-gnu]] || ||
|| ''64-bit'' || [[http://www.debian.org/ports/netbsd/|netbsd-alpha]] || ||

[*] Experimental or not fully supported ports.
Line 141: Line 258:

* ROOT [http://lists.debian.org/debian-science/2005/08/msg00056.html provides a direct way to build deb packages from the sources] but is not in Debian main. 
   * See [http://mirror.phy.bnl.gov/debian-root/ the unofficial ROOT deb repository] for some build instructions and a repository for unstable (i386, amd64, powerpc) and stable (i386 only). 
   * [http://lists.debian.org/debian-science/2005/08/msg00101.html buildd] point is __very__ attractive to ROOT
   * [http://lists.debian.org/debian-science/2005/08/msg00101.html previously] ported ROOT to Debian GNU/Hurd
   * Looks for testers on [http://lists.debian.org/debian-science/2005/08/msg00101.html non-i386] Debian architectures.
 
 * ROOT [[http://lists.debian.org/debian-science/2005/08/msg00056.html|provides a direct way to build deb packages from the sources]] but is not in Debian main.
 * See [[http://mirror.phy.bnl.gov/debian-root/|the unofficial ROOT deb repository]] for some build instructions and a repository for unstable (i386, amd64, powerpc) and stable (i386 only).
 * [[http://lists.debian.org/debian-science/2005/08/msg00101.html|buildd]] point is __very__ attractive to ROOT
 * [[http://lists.debian.org/debian-science/2005/08/msg00101.html|previously]] ported ROOT to Debian GNU/Hurd
 * Looks for testers on [[http://lists.debian.org/debian-science/2005/08/msg00101.html|non-i386]] Debian architectures.
 * [[http://debian.calel.org/root|Unofficial ROOT deb repository for Debian Stable]] (i386) ([[http://www.calel.org/root.html|notes]])
Line 149: Line 266:
  The approach is that the ROOT source tree contains [http://root.cern.ch/viewcvs/build/package/lib/ scripts] and [http://root.cern.ch/viewcvs/build/package/common templates] to deal with packaging in general (that is for Debian and RPM), as well as some [http://root.cern.ch/viewcvs/build/package/debian Debian] and [http://root.cern.ch/viewcvs/build/package/redhat RPM] specific templates.   
     
The debian packaging directory is then build by running the script '''[http://root.cern.ch/viewcvs/build/package/lib/makedebdir.sh makedebdir.sh]''', followed by '''fakeroot debian/rules debian/control'''. The packaging scripts will try to build as many packages as possible on the build host. Note, that that sometimes means that you can get packages that wouldn't be possible on a pristine build system.
The approach is that the ROOT source tree contains [[http://root.cern.ch/viewvc/trunk/build/package/lib/|scripts]] and [[http://root.cern.ch/viewcvs/trunk/build/package/common/|templates]] to deal with packaging in general (that is for Debian and RPM), as well as some [[http://root.cern.ch/viewcvs/trunk/build/package/debian/|Debian]] and [[http://root.cern.ch/viewcvs/trunk/build/package/redhat/|RPM]] specific templates.

The debian packaging directory is then build by running the script '''[[http://root.cern.ch/viewvc/trunk/build/package/lib/makedebdir.sh?view=markup|makedebdir.sh]]''', followed by '''fakeroot debian/rules debian/control'''. The packaging scripts will try to build as many packages as possible on the build host. Note, that that sometimes means that you can get packages that wouldn't be possible on a pristine build system ('''Update:''' with the default set-up, you will get only the ''official'' packages, since ROOTs' ''configure'' will fail).
Line 156: Line 272:
In the eventual "official" Debian packages to come, the package maintainer would presumably run these two commands himself before '''dpkg-buildpackage''', and the results of the commands (for instance the debian/ directory) would therefore enter into the diff.gz of the source package. Thus the source package uploaded to Debian would always be buildable with the normal steps of '''dpkg-buildpackage -rfakeroot'''.  

If an end-user does '''apt-get source root''' and then re-runs the makedebdir script, it will overwrite the existing debian directory with information about the dependencies installed on the end-user's system. Hence an end-user may recompile Debian packages of ROOT building with support for unofficial (non-DFSG-free) libraries.

It is important that the maintainer ensure that he has all the needed "official" build-depends installed on his system when running the makedebdir.sh script, and none of the "unofficial" non-DFSG-free libraries (e.g. Pythia) installed, perhaps by building on a pristine machine or in a pristine chroot. That is, use '''pbuilder''' :-). In any case, official packages are not allowed to munge debian/control in such a way that their Build-Depends change during the dpkg-buildpackage step!
In the eventual "official" Debian packages to come, the package maintainer would presumably run these two commands himself before '''dpkg-buildpackage''', and the results of the commands (for instance the debian/ directory) would therefore enter into the diff.gz of the source package. Thus the source package uploaded to Debian would always be buildable with the normal steps of '''dpkg-buildpackage -rfakeroot'''.

If an end-user does '''apt-get source root''' and then re-runs the makedebdir script, it will overwrite the existing debian directory with information about the dependencies installed on the end-user's system. Hence an end-user may recompile Debian packages of ROOT building with support for unofficial (non-DFSG-free) libraries after editing the '''debian/rules''' file appropriately.

'''Update:''' The follwing is no longer the case. All build dependencies must be present when running the '''makedebdir.sh''' script, or the ROOT ''configure'' script will fail

  
It is important that the maintainer ensure that he has all the needed "official" build-depends installed on his system when running the makedebdir.sh script, and none of the "unofficial" non-DFSG-free libraries (e.g. Pythia) installed, perhaps by building on a pristine machine or in a pristine chroot. That is, use '''pbuilder''' :-). In any case, official packages are not allowed to munge debian/control in such a way that their Build-Depends change during the dpkg-buildpackage step!
Line 163: Line 281:

* [http://root.cern.ch/root/License.html ROOT License] is now LGPL.
 * The production version of ROOT (5.08 as of Jan 8, 2005) is LGPL'ed. The LGPL only applies to version 5.03 and higher of ROOT; prior versions still have the [http://root.cern.ch/viewcvs/LICENSE?rev=1.2&content-type=text/vnd.viewcvs-markup original] non-free license.
 * [http://lists.debian.org/debian-legal/2003/01/msg00278.html Debian legal thread] and [http://lists.debian.org/debian-science/2005/08/msg00085.html why] it is never too much to be careful about licenses. Long-awaited [http://lists.debian.org/debian-science/2005/08/msg00087.html fix] to the problem has now been implemented.
 * [http://people.debian.org/~kmccarty/physics-software-rant.html educational article on licensing and more]

== Thanks ==

* [http://lists.debian.org/debian-science/2005/08/msg00066.html Brad Sawatzky] among [http://mirror.phy.bnl.gov/debian-root/#thanks others].
 * [[http://root.cern.ch/root/License.html|ROOT License]] is now LGPL.
 * The production version of ROOT (5.08 as of Jan 8, 2005) is LGPL'ed. The LGPL only applies to version 5.03 and higher of ROOT; prior versions still have the [[http://root.cern.ch/viewcvs/LICENSE?rev=1.2&content-type=text/vnd.viewcvs-markup|original]] non-free license.
 * [[http://lists.debian.org/debian-legal/2003/01/msg00278.html|Debian legal thread]] and [[http://lists.debian.org/debian-science/2005/08/msg00085.html|why]] it is never too much to be careful about licenses. Long-awaited [[http://lists.debian.org/debian-science/2005/08/msg00087.html|fix]] to the problem has now been implemented.
 * [[http://people.debian.org/~kmccarty/physics-software-rant.html|educational article on licensing and more]]
= Thanks =
 * [[http://lists.debian.org/debian-science/2005/08/msg00066.html|Brad Sawatzky]] among [[http://mirror.phy.bnl.gov/debian-root/#thanks|others]].

1. ROOT for DebianScience

As of July 8, 2008 (or so) ROOT version 5.18 has entered Debian Lenny and is expected to be shipped with the next Debian stable release.

As of 2011, you can find ROOT version 5.28 on the unofficial CERN Debian repository.

Note: the name of the metapackage and source package, at the request of FTP masters, has been changed to root-system. If you only want a minimal ROOT environment you may instead try installing root-system-bin.

2. Port status (25/11/2009): porterbox work

Christian recently had guest access to some of the Debian porter boxes, which meant he could check the packages on many of the Debian supported architectures. The status of this is given below. The work was done on version 5.24.00-2 (not uploaded yet).

Architecture

Build host

Status

Comments

alpha

albeniz.debian.org

Possibly OK

Cintex not supported

amd64

localhost

OK

arm

agnesi.debian.org

Unknown

Machine down

armel

agricola.debian.org

OK

hppa

paer.debian.org

Possibly OK

Machine down

i386

?

Likely OK

ia64

merulo.debian.org

Likely OK

Missing build-depend

mips

mahler.debian.org

Likely OK

Machine down

mipsel

morales.debian.org

Likely OK

Machine down

powerpc

pescetti.debian.org

OK

Cintex not supported

sparc

smetana.debian.org

OK

Cintex not supported

s390

zelenka.debian.org

OK

New to upstream

kfreebsd/i386

io.debian.net

OK

New to upstream

kfreebsd/amd64

asdfasdf.debian.net

Likely OK

New to upstream

(more unofficial ports exists but have not been investigated yet)

See also buildd logs (and possibly here).

3. Porting notes

When porting to a non i386 platform not already supported for Linux, the following points should be considered.

  1. Enable auto-detection in configure. This normally involves figuring out what platform uname -m returns, and then add something like

          linux:<arch>*:*)      arch=linux ;;
  2. If the generic linux arch does not fit the machine (e.g., 64bit word-size, or big-endian, unsupported compiler options, or the like), we need to define a new platform.

    1. Look for a similar architecture, and copy that architectures config/Makefile.linuxother to config/Makefilefoo.

    2. Set the definition in configure to

            linux:<arch>*:*)      arch=linux<foo> ;;

      where <foo> is the Debian system name.

    3. Add an entry for the architecture to config/ARCHS

      linuxfoo             for FOO Linux gcc and glibc
    4. In config/root-config.in add an appropriate entry for the new architecture

      linuxfoo)
         # Linux with gcc >= 3.x
         auxcflags="-m32"   # replace with -m64 for 64bit machines
         auxldflags="-m32"  # replace with -m64 for 64bit machines
         auxlibs="-lm -ldl -rdynamic"
         ;;
    5. In test/Makefile.arch add appropriate lines for the new architecture.

      ifeq ($(ARCH),linux)
      # Linux with egcs, gcc 2.9x, gcc 3.x
      CXX           = g++
      CXXFLAGS      = $(OPT2) -Wall -fPIC
      LD            = g++
      LDFLAGS       = $(OPT2)
      SOFLAGS       = -shared
      endif
    6. Check that the platform is properly identified by the XRootd in the xrootd/src/xrootd/configure.classic script

             linux:foo*:*)    arch=foo_linux      ; platform=linux; ccflv=gcc;;
    7. Also add an entry to xrootd/src/xrootd/ARCHS. Note, that you may need to specify a different compiler config, especially if the option -m32 is not recognised. In that case, you should also modify xrootd/src/xrootd/configure.classic to recognise the architecture, and possibly add a configuration file in xrootd/src/xrootd/config/MakeRules.gccfoo

      foo_linux       gcc       all    for GNU/Linux on FOO
  3. Check that the system is properly recognized in base/inc/RConfig.h. Run

     touch dummy_file.c; gcc -E -dM dummy_file.c

    to see a list of GCC predefined pre-processor symbols. Look for an chip definition (e.g., __i386__, __powerpc__). If no valid entry exists in base/inc/RConfig.h, then add something like

       1 #if defined(linux) && defined(<cpp_arch>)
       2 #   define R__LINUX
       3 #   define R__UNIX
       4 #   define NEED_SIGJMP
       5 #   if defined(_ABI64) // For 64-bit word size
       6 #      define R__B64
       7 #   endif
       8 #   if defined(__BYTE_ORDER) && __BYTE_ORDER == __LITTLE_ENDIAN
       9 #      define R__BYTESWAP // For little endian machines
      10 #   endif
      11 #endif
      12 
    
  4. Check that the chip/os combo is properly detected in clib/src/Getline.c. The generic entries may be OK - that is the pre-processor conditional

       1 #if defined(TIOCGETP) && !defined(__sgi) && !defined(R__PPCLINUX) && \
       2     !defined(R__ALPHALINUX)  && !defined(R__MIPSLINUX) /* use BSD interface if possible */
       3 #include <sgtty.h>
       4 struct sgttyb   new_tty, old_tty;
       5 struct tchars   tch;
       6 struct ltchars  ltch;
       7 #else
       8 #ifdef SIGTSTP          /* need POSIX interface to handle SUSP */
       9 #include <termios.h>
      10 #if defined(__sun) || defined(__sgi) || defined(R__PPCLINUX) || \
      11     defined(R__ALPHALINUX) || defined(R__MIPSLINUX)
      12 #undef TIOCGETP         /* Solaris and SGI define TIOCGETP in <termios.h> */
      13 #undef TIOCSETP
      14 #endif
      15 
    

    the second POSIX branch will be chosen (termios.h is included). If not, add detection code as for for example R__MIPSLINUX and include that define in the BSD excluded list above.

  5. In cint/inc/G__ci.h check that CINT knows how to deal with variadic arguments to functions. Check if there's some entry that corresponds more or less to the the OS/CPU combo, and make a new switch. For example

       1 #elif (defined(__foo__)&&defined(__linux__))
       2 /**********************************************
       3  * FOO, Linux
       4  **********************************************/
       5 #if defined(_ABI64) /* For 64-bit word size */
       6 # define G__VAARG_INC_COPY_N 8
       7 #else
       8 # define G__VAARG_INC_COPY_N 4
       9 #endif
      10 #define G__VAARG_PASS_BY_REFERENCE 8
      11 #else
      12 /**********************************************
      13  * Other platforms,
      14  *  Try copying object as value.
      15  **********************************************/
      16 #define G__VAARG_NOSUPPORT
      17 #define G__VAARG_INC_COPY_N 4
      18 /* #define G__VAARG_PASS_BY_REFERENCE 8 */
      19 #endif
      20 
    
    If this does not work, you will get the error message
    Limitation: Variable argument is not supported for this platform
    when executing interpreted code like
       1 Form("Hello, World from %s", "me")
    

    In this case, we will need input from the CINT developers. Send a message to cint@root.cern.ch describing the problem and the architecture (OS, chip, kernel version, compiler, etc.).

Non-Linux platforms may need more work. The basic thing is to assume that the OS is like Linux, except of course, if there's a closer alternative, like BSD or Cygwin.

4. Builder scripts

?build.sh, ?changes.sh

These two files should be put in a sub-directory called extra which is on the same level as the ROOT source code.

You should have

> ls 
extra        root
> ls extra
build.sh     changes.sh

You can execute

../extra/build.sh 

from the root source directory to build the packages.

  • If no ../root-system-<version>.orig or ../root-system-<version>.orig.tar.gz exists, the script will check-out from the ROOT Subversion repository. The What will be checked out depends on the version check-out in the root source directory:

    • If the version has an even minor number (e.g., 5.24.00) then the corresponding tag will be check-out (e.g., https://root.cern.ch/svn/root/tags/v5-24-00)

    • If the version has an odd minor number (e.g.m, 5.25.02) the the trunk will be checked out.

  • If no ../root-system-<version>.orig.tar.gz does not exists, it is created from ../root-system-<version>.orig.

  • The root directory is updated from subversion.

  • svn status -u is run to get a list of modified, removed, and added files (relative to subversion), and the following files are created (empty files will be ommited):

    • changes-<version>.patch: Patch of modified files

    • removed-<version>.list: List of files removed

    • added-<version>.tar.gz: Archive of added files

    • summary-<version>: Summary of changes. Monitor this for possible conflicts.

  • dpkg-buildpackage is called to build the packages.

  • lintian is run over the generated packages with informative output.

Some of these steps can be skipped and the packages can be built using pbuilder. Do

../extra/build.sh --help

for more information.

5. Future plans

  • The intent is to upload ROOT "development" versions 5.odd.xx only to "experimental", and ROOT "production" versions 5.even.00 to "unstable", allowing the production versions to propagate into testing and stable over time.

  • Unfortunately the current production release of ROOT, 5.20.00, has been released probably too late to make it into Lenny, but we intend to upload ROOT 5.20 to backports.org for Lenny users once it is in unstable.

6. History

The information below is historic and archived. It is reproduced here for reference.

  • ITP submitted by ChristianHolm.

  • Packages uploaded to NEW queue on April 27, 2006, by KevinMcCarty and ChristianHolm. These were targeted for "experimental".

  • FTPmaster rejected these packages on the grounds of licensing issues. In the mean time, these issues have been worked out with the upstream authors and 3rd party developers.
  • Since then, the debian/copyright file has been greatly expanded, and the copyright holders of the non-free material were contacted and agreed to relicense it under LGPL. New ROOT packages targeted at "experimental" were uploaded to the NEW queue on November 3, 2006.
  • These packages were unfortunately rejected due to "too generic name". A third upload to experimental, with the source and some binary packages renamed, was permitted to enter the archive.
  • ROOT 5.18 was uploaded to unstable in mid-June 2008, and following a new upload with some FTBFS bug fixes, entered the current testing distribution "Lenny" on about July 8, 2008.

6.1. Port status (23/09/2009): Buildd port status

The current port status is summarised below. See also buildd logs (and possibly here).

Currently accepted ports

byte order/word size

little-endian

big-endian

32-bit

i386, mipsel

mips, hppa

64-bit

amd64,ia64

Currently awaiting dependencies

byte order/word size

little-endian

big-endian

32-bit

hurd-i386

m68k,

64-bit

Failed on buildd

byte order/word size

little-endian

big-endian

32-bit

arm

armel, s390, powerpc, sparc,

64-bit

alpha

6.1.1. Notes on failed archs

  • powerpc failes because of missing build-dep on libsm-dev.
  • alpha - conflicting prototypes in cint/lib/posix/posix.h - most likely a wrong CPP condition.

  • arm - unclear why it fails, no logs.
  • armel - Incomplete support in XRootd
  • kfreebsd-* - need to implement autodetection of architecture. Please also refer to #Portingnotes below.

  • s390 - unknown, logs missing
  • sparc - xrootd explicitly disabled in debian/rules - it shouldn't be.

6.2. Port status (8/9/2007): 2 more architectures, mips and hppa

With the kind help of Dirk Van Hertem <dirk dot vanhertem at ieee dot org> and Boris (?) <boris at mogwitz dot eu> we have managed to build the ROOT packages on hppa and mips. Thiemo Seufer <ths at networkno dot de> helped on porting to mipsel.

That brings the list of supported and confirmed architectures up to

Currently accepted ports

byte order/word size

little-endian

big-endian

32-bit

i386, mipsel

powerpc, mips, hppa

64-bit

amd64

Currently untested ports

byte order/word size

little-endian

big-endian

32-bit

arm

armeb[*], m68k, sparc, s390,

64 bit

ia64, alpha

ppc64[*], s390x[*], sparc64[*]

Unsupported accepted ports

byte order/word size

little-endian

big-endian

32-bit

hurd-i386, netbsd-i386, kfreebsd-gnu

64-bit

netbsd-alpha

[*] Experimental or not fully supported ports.

6.3. The current unofficial repository

6.4. Technical issues for packaging

The approach is that the ROOT source tree contains scripts and templates to deal with packaging in general (that is for Debian and RPM), as well as some Debian and RPM specific templates.

The debian packaging directory is then build by running the script makedebdir.sh, followed by fakeroot debian/rules debian/control. The packaging scripts will try to build as many packages as possible on the build host. Note, that that sometimes means that you can get packages that wouldn't be possible on a pristine build system (Update: with the default set-up, you will get only the official packages, since ROOTs' configure will fail).

Note, that this scheme does not change the way the packages are built. It merely changes how the debian directory is prepared. After the debian directory is made, the developer can still tweak it to fit the system. Of course, such tweaks should eventually be propegated back to the packaging scripts in ROOT itself, to assure consistency.

In the eventual "official" Debian packages to come, the package maintainer would presumably run these two commands himself before dpkg-buildpackage, and the results of the commands (for instance the debian/ directory) would therefore enter into the diff.gz of the source package. Thus the source package uploaded to Debian would always be buildable with the normal steps of dpkg-buildpackage -rfakeroot.

If an end-user does apt-get source root and then re-runs the makedebdir script, it will overwrite the existing debian directory with information about the dependencies installed on the end-user's system. Hence an end-user may recompile Debian packages of ROOT building with support for unofficial (non-DFSG-free) libraries after editing the debian/rules file appropriately.

Update: The follwing is no longer the case. All build dependencies must be present when running the makedebdir.sh script, or the ROOT configure script will fail

  • It is important that the maintainer ensure that he has all the needed "official" build-depends installed on his system when running the makedebdir.sh script, and none of the "unofficial" non-DFSG-free libraries (e.g. Pythia) installed, perhaps by building on a pristine machine or in a pristine chroot. That is, use pbuilder :-). In any case, official packages are not allowed to munge debian/control in such a way that their Build-Depends change during the dpkg-buildpackage step!

6.5. Licensing

7. Thanks