Hi Daniel,
On 26/08/2014 23:55, Daniel L. Wang wrote:
> Hi Fabrice,
>
> On 08/26/2014 10:06 AM, Fabrice Jammes wrote:
>> Build problem of Qserv master branch :
>>
>> I have next problem while building last Qserv version with g++ (GCC)
>> 4.8.3 20140624 (Red Hat 4.8.3-1)
>> Next fix at line 23 of core/modules/xrdfs/SConscript.test solves the
>> problem :
>> p = env.Program('testMySqlFs_1.cc', LIBS=["XrdXrootd", *"XrdUtils"*])
>> This problem doesn't seems to happen with : g++ (GCC) 4.4.7 20120313
>> (Red Hat 4.4.7-4)
>> Do you think we can apply this patch to Qserv master branch ?
> I can't reproduce this easily, because I don't have a gcc 4.8 machine
> handy. Does the fix cause any problems for on RHEL6/Centos6 systems?
>
> For now, perhaps it's better to comment it out rather than fix it--the
> xrdfs is likely to go away as soon as the dust settles on the xrootd
> port and the result protocol.
The fix works on SL6.2 (which is RedHat-based) and make Qserv compliant
with Fedora19 (which provides gcc 4.8.3), could we add it please? It
would be much more comfortable for testing Qserv packaging on multiple
distros.
>
>> Qserv dependencies versions management in eups :
>>
>> Furthermore, i see that Qserv master branch doesn't use a new xrootd
>> version.
>> For now I don't know the right procedure to force a given Qserv
>> version to use a given version of its dependencies.
>> It seems it is possible to do this with the rebuild command of
>> lsstsw, but how ?
>> Please note that this problem seems to be the same than the one
>> described in qserv-l mail named : "Redundant(?) installation of doxygen"
> I don't know how to solve this. I don't think it's a problem for new
> installations, because I think buildbot builds everything from scratch
> and it seems to build and test qserv without error. Perhaps your local
> eups stack doesn't know about the new xrootd package? Maybe there is
> something you can do with your installation to refresh package versions.
Sorry, I made a mistake in my explainations, in fact tip of Qserv master
branch *use* new xroot version.
The problem I'd like to solve is :
I think that lsstsw build tool uses by default the tip of each master
branch of a given product dependencies. This may be wrong is the tip a
of dependency is broken, or if you want to re-package a previous Qserv
version (which may be only compliant with previous versions of the
dependencies and not the current ones).
=> That's why i'm interesting in learning how to describe in lsstsw/eups
the dependencies versions set for a given Qserv version.
I'm very interested about having informations about buildbot, but for
now it seems that even if Mario succeeded in integrating Qserv with
official LSST distribution server, only one Qserv version is currently
distributed
(see http://sw.lsstcorp.org/eupspkg/products/ which only contains
qserv-master-g6c2884f158.eupspkg) and furthermore the last xrootd
version isn't distributed. That's why I think buildbot integration has
not yet been performed, and for now distribution of new
Qserv/dependencies version still have to be done by hand (on my side I'm
only able to publish this under my user account, in
http://lsst-web.ncsa.illinois.edu/~fjammes/qserv-dev/). It would be fine
to be able to publish multiples Qserv releases/version in official LSST
distribution server, in preference with buildbot, or even by hand with
lsstsw.
Hope I'm clear enough.
>
> -Daniel
>
########################################################################
Use REPLY-ALL to reply to list
To unsubscribe from the QSERV-L list, click the following link:
https://listserv.slac.stanford.edu/cgi-bin/wa?SUBED1=QSERV-L&A=1
