On 2/17/14, 10:11 , Fabrice Jammes wrote:
> 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.
>>

OK, sounds good.

>> 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).

OK, that explains it. What I did was try building the actual qserv
(that's why it failed).

>>
>> 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 think it should work -- try it. The rules on contrib/ are very relaxed.

>>
>> 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.

Yes, there's been push back on merging the two in code review; I'll
split the back up. Here's what I plan:

* Create mysql_client and mysql_server packages (the latter being the
contents of the current 'mysql' package).
* Make mysqlpython depend on mysql_client
* Make qserv packages that require the server depend on mysql_server.

How does that sound?

>>
>> 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 think we can support that by having 2.7 as default, and instructing
the experts who want to use 2.6 to specify it in manifest.remap?

Otherwise, things are almost guaranteed to break by default since all
other LSST code depends on 2.7 right now.

>>
>> 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 ?

Use the 'eupspkg' branch in my EUPS repo on github.

But just a warning that there'll be one more change -- RHL has asked to
rename eupspkg.sh to eupspkg.cfg.sh (see the discussion on that pull
request), and that will affect all packages that use it.

Cheers,
-- 
Mario Juric,
Data Mgmt. Project Scientist, Large Synoptic Survey Telescope
Web : http://research.majuric.org     Phone : +1 617 744 9003

########################################################################
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