LISTSERV 16.5 - QSERV-L Archives

On 02/13/2014 09:54 PM, Mario Juric wrote:

[log in to unmask]" type="cite">

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.

[log in to unmask]" type="cite">


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

[log in to unmask]" type="cite">


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

[log in to unmask]" type="cite">


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.

[log in to unmask]" type="cite">


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.

[log in to unmask]" type="cite">
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 ?

[log in to unmask]" type="cite">


- 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

[log in to unmask]" type="cite">
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