Hello, production release 5.30.00 was issued quite a while ago. Aside from updated patchset I made some changes to the ebuild: - lzma support (for root file data compression); - X support is now optional (but enabled by default, of course), this is extremely useful on X-less computating stations; tested on ~amd64; - fix tmva and roofit documentation installation (pdfs were missed due to ebuild typo; - some small fixes. In patchset all patches are still required, nobyte-compile and xrootd-prop-flags patches were updated, new lzma patch is present (it is required to compile with system xz-utils). Despite root now support cmake alongside with traditional configure, I do not think it is time now to switch to cmake: configure script is not deprecated now and I personally prefer plain configure over cumbersome cmake configs.
Created attachment 279619 [details, diff] root-5.30.00-xrootd-prop-flags.patch Updated from old patchset.
Created attachment 279621 [details, diff] root-5.30.00-nobyte-compile.patch Updated patch.
Created attachment 279625 [details, diff] root-5.30.00-lzma.patch This patch is required to build with system xz-utils. Otherwise build fails as follows: In file included from /var/tmp/portage/sci-physics/root-5.30.00/work/root/core/lzma/src/ZipLZMA.c:13:0: /usr/include/lzma/lzma.h:16:3: error: #error Never include this file directly. Use <lzma.h> instead. The problem occurs, because /usr/include/lzma/ directory is search for lzma.h before /usr/include/.
Created attachment 279627 [details] root-5.30.00.ebuild Updated ebuild, will split it into separate patches for different changes in a while.
Created attachment 279631 [details, diff] root-5.30.00-afs.patch Unfortunately, root still fails to build with afs support using openafs-1.6.0_pre3. The first problem is type cast error, which could be easily fixed as in this patch; but then API change problems arose. They can't be trivially fixed, so I can do nothing with this ATM. And I can't use older 1.4.x openafs, because it fails to build with 2.6.38 kernel and above. This patch is not included in the patchset, because in doesn't fix the problem completely.
Created attachment 279633 [details, diff] root-5.30.00.ebuild-00docs.patch Fix TMVA and RooFit pdf installation.
Created attachment 279635 [details, diff] root-5.30.00.ebuild-01patchset.patch Apply new patches.
Created attachment 279637 [details, diff] root-5.30.00.ebuild-02lzma.patch Adds system lzma support using xz-utils, applies lzma patch.
Created attachment 279639 [details, diff] root-5.30.00.ebuild-03libs.patch Adds some missed deps.
Created attachment 279641 [details, diff] root-5.30.00.ebuild-04xft.patch Makes libXft dependency controlled by xft flag. With USE="xft": ldd /usr/lib/root/*.so | grep -i xft -B 10 libpcre.so.0 => /lib/libpcre.so.0 (0xb65e0000) /lib/ld-linux.so.2 (0xb77f1000) libXau.so.6 => /usr/lib/libXau.so.6 (0xb65dc000) libXdmcp.so.6 => /usr/lib/libXdmcp.so.6 (0xb65d5000) /usr/lib/root/libGX11TTF.so: linux-gate.so.1 => (0xb7706000) libfreetype.so.6 => /usr/lib/libfreetype.so.6 (0xb7629000) libGX11.so.5.30 => /usr/lib/root/libGX11.so.5.30 (0xb75de000) libGraf.so.5.30 => /usr/lib/root/libGraf.so.5.30 (0xb744b000) libX11.so.6 => /usr/lib/libX11.so.6 (0xb7328000) libXft.so.2 => /usr/lib/libXft.so.2 (0xb7313000) With USE="-xft": $ ldd /usr/lib/root/*.so | grep -i xft -B 10 Binaries doesn't depend on libXft either way.
Created attachment 279643 [details, diff] root-5.30.00.ebuild-05optional-X.patch This one make X support optional. Of course, it is enabled by default. But even without X11 support root can build and works well for data processing (tested on ~amd64). Of course, it is impossible to save canvas as a picture in this setup, but it is sufficient for pure data processing.
Well, that's all. At this moment new root works well, but I haven't done hard testing yet.
Hi Andrew, Thanks for all the patches. Would you consider getting commit access to the science overlay so we can have smoother updates to the root ebuilds? I am working on splitting xrootd as well.
Hello, (In reply to comment #13) > Thanks for all the patches. Would you consider getting commit access to the > science overlay so we can have smoother updates to the root ebuilds? It sounds like a good idea.
I pushed changes into science overlay.
What is state of progress here?
*** Bug 384729 has been marked as a duplicate of this bug. ***
(In reply to comment #16) > What is state of progress here? ATM you may use root-5.30.03-r1 from science overlay. 5.30.04 is released already, but I have some problems with it, so until I'll figure them out I'll not put it into the overlay.
Hello, some news: ROOT v5.32.00 was released. I updated ebuilds in the science overlay. Major changes are: 1) xrootd is now unbundled upstream, I created a separate package sci-physics/xrootd in the science overlay. It was tested on ~x86 and ~amd64 to build and run on some basic setup with some USE flags combinations, including all flags enabled and all flags disabled. 2) It is now possible to build root-5.32.00 with openafs-1.6.0 support if openafs is patched with the patch from bug 393071. The problem is that afs hides some symbols in shared libraries which are present in the same static libraries (usually one expects them to provide the same list of symbols). Also there is an afs patch which is applied to the root ebuild, it: - fixes type cast; - defines root strlcpy, strlcat symbols as weak, because they are redefined in openafs.
Hi, I tried to compile sci-physics/root-5.32.00-r1 from the science overlay with fitsio (USER="fits"). However, this caused a problem with the root configure script which tried to dynamically link against the statical version of the sci-libs/cfitsio library. I fixed this problem by patching the configure script with the attached root-5.32.00-cfitsio.patch and applying it while src_prepare().
Created attachment 299341 [details, diff] Patches configure script to correctly link root against the dynamic cfitsio library.
Fixed in root-5.32.00-r2 (science overlay). Good catch, thanks for the patch. I use cfitsio built without static-libs, so I missed this problem before.
Now in the main tree. Thanks!
