On 02/13/2014 09:54 PM, Mario Juric wrote:
> On 2/13/14, 13:20 , Mario Juric wrote:
>> Fabrice et al,
>> Questions re mysqlproxy: it depends on glib2 and libevent. Did you plan
>> to make EUPS packages for these, or will you ask the users to install
>> the required -dev[el] packages on their distributions?
>>
> Ah, OK -- I see that libevent is already there. Let me know what you
> intended to do re glib2; it won't take me more than 10 minutes to
> package it.
For now glib2-devel is installed with yum. It may change but, in a first
time, i wish to test the new Qserv version with exactly the same
dependencies than previously.
>
> Otherwise, I managed to build everything up to (but excluding) qserv:
>
> ======
> [mjuric@lsst-dev /ssd/mjuric/buildbot/lsst_build master]$ time
> ./bin/lsst-build build ./build ./build/manifest.txt libevent:
> master_g410bd5abbb (already installed).
> python: 2.7_1_g4b5dedd60d (already installed).
> expat: master_g4a0254e0b2 (already installed).
> zopeinterface: master_g0277429914+0a4801e32d (already installed).
> lua: master_ge6f8f65424 (already installed).
> xrootd: master_gc482612125 (already installed).
> luasocket: master_gc334468692+f083576d5c (already installed).
> mysql: 5.1.65_2_g6c6a3b8387 (already installed).
> luaexpat: master_g2e51c46583+8bb3c3661f (already installed).
> mysqlpython: master_gf144fc96d5+63a8112594 (already installed).
> luaxmlrpc: master_g55ddf7ee18+12ef1d036c (already installed).
> protobuf: master_g1ec0f6d55a+0a4801e32d (already installed).
> mysqlproxy: master_g769d47e3fb+5a834d7aac ok (14.4 sec).
> twisted: master_g3cdcb63100+6abb9c9f40 ok (8.0 sec).
> qserv: 0.5.1rc3_28_g2ba3abe916+95fcd65228 ERROR (0 sec).
> *** error building product qserv.
> ======
>
> The qserv error is not surprising, since there's only a table file
> present there (I suspect it will need its own eupspkg.sh?).
With the previous eupspkg version (default eupspkg file), qserv was
building (in fact qserv build does nothing but installing its dependencies).
>
> Btw., I noticed you had a dummy qserv package in /personal/fjammes,
> probably for testing purposes. The way I treated similar issues was to
> just add a branch to a package (usually u/mjuric/eupspkg) on which all
> eupspkg-related changes live. For consistency (and to avoid collisions
> on REPOSITORY_PATH between the LSST/DMS/qserv and the other one), I made
> a branch /u/mjuric/eupspkg in LSST/DMS/qserv, and copied the table file
> there.
>
> PS: I think we should jointly continue working on packages in:
>
> https://dev.lsstcorp.org/cgit/contrib/eupspkg
Thanks, but do you think i will be able to run this command on the
contrib/ repositories :
git tag -f ${VERSION}
*git push -f --tags*
Indeed, it seems this procedure is required for updating a tag without
changing $VERSION
i'm not sure it is possible when i read the doc :
https://dev.lsstcorp.org/trac/wiki/GitDemoAndTutorial#contribandpersonalrepositories
>
> I've kept your version of mysqlpython and mysql; in retrospect, I think
> it's not really worth the hassle splitting up mysql to -server and
> -client packages.
Yes but mysql-server take around 10 minutes to build. That's the most
important drawback i see.
>
> I left out your changes to Python, however -- your changes allow 2.6,
> which breaks the rest of the stack (e.g., users aren't warned on RHEL6
> that they have the wrong version of Python). I think that if one *knows*
> they won't need 2.7, they can use the manifest.remap mechanism to tell
> EUPS not to install the 2.7 stub package. And this issue will most
> likely go away entirely in a ~year or two, as RHEL7 will have 2.7 by
> default (RHEL6 is basically the only major distribution still 2.6).
Python versions seems to evolve quickly, that's why it could be
convenient to give the choice to the user/packager about the version
they want to use.
It would allow eupspkg to be more flexile and generic, isn't it ?
In a first time i need to test Qserv code with python 2.6.
I will ask to Qserv team if they want to use python2.7 in the next step.
>
> I'll now continue on to fixing the remaining eupspkg bugs...
Thanks, do you think that i can use right now your github master branch ?
>
> - M.
>
>> PS: I found some cycles to make a push of eupspkg, and I'm unifying your
>> work on external packages for qserv with the work I did on external
>> packages for the rest of the stack. I cloned them all to:
>>
>> https://dev.lsstcorp.org/cgit/contrib/eupspkg
>>
>> so both of us can write there. For now, I implemented the ./ups/eupspkg
>> -> ./ups/eupspkg.sh change that I mentioned in the previous e-mail, and
>> I'm going down the list fixing issues that have arisen because of that,
>> trying to work my way up to building qserv.
Thanks a lot Mario,
Have a nice day,
Fabrice
>>
>> Cheers,
>>
>
########################################################################
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
