Open andresailer opened 4 years ago
Yep, I'll make a test build
Xrootd5 requires cmake3(.1?) which makes it more involved to be installed with diracos, as previously diracos was just able to use cmake2.8 from sl6?
There is cmake3
3.6.1 in epel, so we can either add it, but maybe it would be enough to just say that this is a requirement like mock rpm-build fedora-packager
A bit more updates, after @petricm and I spent some times on it.
One of the problem is a dependency chain: xroot5
needs cmake3
which needs (among others) jsoncpp
which needs cmake2.8
which we only build later in the chain. Maybe we could just build cmake2.8 earlier. The current work arround is that I download the binary RPM of jsoncpp
& libarchive3
directly (booooh, ugly, completely the opposite of the spirit !).
Another problem was that the building of globus-xio-udt-driver
failed systematically (while only from time to time in the past) because one mirror of sourceforge
is apparently dead. Another ugly fix: I forced a specific mirror, since for some reason, sourceforge
would redirect curl ALWAYS to the same mirror.
Finally, I got cmake3
to build, xroot5
to build but now gfal2
fails to build because of that https://its.cern.ch/jira/browse/DMC-1201 Basically, the build of gfal2
expects a library which does not exist anymore as of xroot 5.0. Now it's the same guy taking care of gfal2 and xroot, so hopefully he will fix the inconsistency promptly
This is the current state of things: https://github.com/chaen/DIRACOS/tree/xroot5rc2Bootstrap last test build: https://gitlab.cern.ch/CLICdp/iLCDirac/diracos-test/-/jobs/8570568
A nwe RC for gfal2 is out, which should solve the issue. I'll try it out
Some more progress... Now the latest gfal (2.18.1) and xroot (5.0.0) build together. BUT, ARC 5.4.0 does not build anymore :-)
DataPointXrootd.cpp: In member function 'void ArcDMCXrootd::DataPointXrootd::set_log_level()':
DataPointXrootd.cpp:497: error: 'setDebug' is not a member of 'XrdPosixXrootd'
DataPointXrootd.cpp:498: error: 'setDebug' is not a member of 'XrdPosixXrootd'
Not my area of expertise, but shouldn't we anyway move to ARC 6 ?
That arc is a question for @rajanandakumar , I guess ?
Indeed. I also see, looking at the spec file, that the xroot build can be disabled. According to the arc doc, this is to allow for file management. This is more a server side operation isn't it ? In which case we can probably do without ?
@chaen @andresailer Could either of you point me to the actual command that is failing (and better if I can reproduce it by myself!). I can then ask for help ...
@rajanandakumar Wouldn't they just say move to arc6?
Does the arc6 client submit also to arc5 CEs (if there are still some around?)
Yes the ARC6 libraries should happily submit to arc5 CEs.
And yes you are correct about the likely recommendation 😃
I don't think we need to build the xroot plugin, since we do not even ship the plugin package... should I try to build without it, or should I try to move to arc6 ?
Moving to arc6 is advisable I suppose. However why build it if it is not used?
simplicity :-) We just take the full SRPM packaeg, rebuild it, and then keep what we are interested in
latest news: Arc6 is not compatible yet with xroot5. Series of PR from the xroot developers to arc to follow (https://source.coderefinery.org/nordugrid/arc)
latest news: Arc6 is not compatible yet with xroot5. Series of PR from the xroot developers to arc to follow (https://source.coderefinery.org/nordugrid/arc)
Given that you guys are fiddling with arc6, what's the situation now?
latest news: Arc6 is not compatible yet with xroot5. Series of PR from the xroot developers to arc to follow (https://source.coderefinery.org/nordugrid/arc)
Given that you guys are fiddling with arc6, what's the situation now?
As of now there's no incompatibility that we know.
Would it be possible to use the xrootd5 release candidate for testing?
https://github.com/xrootd/xrootd/issues/1086#issuecomment-606700319