Perl 6 - the future is here, just unevenly distributed

IRC log for #gluster-dev, 2014-02-18

| Channels | #gluster-dev index | Today | | Search | Google Search | Plain-Text | summary

All times shown according to UTC.

Time Nick Message
00:20 cjanbanan joined #gluster-dev
01:53 cjanbanan joined #gluster-dev
02:07 bala joined #gluster-dev
03:18 ppai joined #gluster-dev
03:26 shubhendu joined #gluster-dev
03:50 kanagaraj joined #gluster-dev
03:52 itisravi joined #gluster-dev
03:58 mohankumar__ joined #gluster-dev
04:06 mohankumar__ joined #gluster-dev
04:13 mohankumar joined #gluster-dev
04:17 ajha joined #gluster-dev
04:21 mohankumar joined #gluster-dev
04:24 kdhananjay joined #gluster-dev
04:26 mohankumar joined #gluster-dev
04:29 ndarshan joined #gluster-dev
04:31 mohankumar joined #gluster-dev
04:33 hagarth joined #gluster-dev
04:37 mohankumar joined #gluster-dev
04:44 mohankumar joined #gluster-dev
04:50 cjanbanan joined #gluster-dev
04:56 jobewan joined #gluster-dev
05:09 lalatenduM joined #gluster-dev
05:14 mohankumar joined #gluster-dev
05:15 bala joined #gluster-dev
05:21 mohankumar joined #gluster-dev
05:31 mohankumar joined #gluster-dev
05:38 kanagaraj joined #gluster-dev
05:44 ndarshan joined #gluster-dev
05:52 raghu joined #gluster-dev
06:02 ndarshan joined #gluster-dev
06:04 kanagaraj joined #gluster-dev
06:28 aravindavk joined #gluster-dev
06:33 raghu` joined #gluster-dev
06:40 bharata-rao joined #gluster-dev
06:42 kshlm cd
06:48 pk joined #gluster-dev
06:49 lalatenduM kshlm, :)
06:49 lalatenduM hagarth, ping
06:49 hagarth lalatenduM: pong
06:49 lalatenduM hagarth, pm
06:50 hagarth lalatenduM: sure
06:54 cjanbanan joined #gluster-dev
06:55 mohankumar joined #gluster-dev
07:10 kshlm i've been trying to build fedora20 rpms from the master branch, and I keep failing.
07:10 kshlm rpmbuild fails during the configure step, and complaing openssl is missing.
07:10 kshlm i was able to build rpms successfully last friday
07:11 kshlm does anyone have any idea what changed since then to cause rpmbuild to fail?
07:12 ppai joined #gluster-dev
07:13 lalatenduM kshlm, you have openssl-dev package?
07:13 kshlm yes,
07:13 raghu joined #gluster-dev
07:13 kshlm doing a manual build (autogen, configure and make) succeeds
07:13 lalatenduM kshlm, can I see the error
07:13 kshlm but rpmbuild fails.
07:16 lalatenduM kshlm, I mean can you put it in a pastebin
07:17 kshlm http://ix.io/azI
07:20 lalatenduM kshlm, can check you have openssl-libs, if not install it
07:22 kshlm i have everything installed, i built rpms on the same machine on friday. and I can still build rpms off release-3.5 and can do a manaul compilation of master
07:22 kshlm it's just that rpmbuild off master is failing.
07:29 badone_ joined #gluster-dev
07:41 ndevos kshlm: yeah, I've had that happen too (rpmbuild/mock/..), and you say manual ./configure works?
07:43 kshlm ndevos: yes.
07:44 * kshlm will be afk for lunch. bbl.
07:44 ndevos sure, ttyl
07:45 ndevos I think rpmbuild may copy a config.sub (or whatever) over the one the from the tar.gz, that would explain why it happens with rpmbuild only
08:00 Frankl joined #gluster-dev
08:30 lalatenduM joined #gluster-dev
08:32 raghu` joined #gluster-dev
08:48 kshlm ndevos: The tar doesn't contain config.sub, it is generated by the configure script.
08:49 ndevos kshlm: yes, but I think rpmbuild has its own copy of config.sub - I'm installing a F20 now to see what happens there
08:51 cjanbanan joined #gluster-dev
08:55 cjanbanan left #gluster-dev
09:10 kshlm ndevos: I don't believe its a rpmbuild issue. I can build other rpms (from release-3.5 for eg.).
09:13 kshlm I did git bisect on master with the last known good commit for me (7ee027533)
09:14 kshlm I found the problems started from commit 58d7ef2f76 build: CFLAGS was being polluted by python flags
09:16 ndevos kshlm: oh, nice find!
09:16 kshlm jclift_ also found the same, he's reported it on the commits review, http://review.gluster.org/6957
09:18 ndevos kshlm: right, maybe config.log gives any hints?
09:19 ndevos kshlm: hmm, CFLAGS from that change should not override the environment CFLAGS, that looks broken
09:32 badone__ joined #gluster-dev
09:36 kshlm ndevos: i've pasted the config.log for the failed rpmbuild at http://ur1.ca/gna38
09:36 kshlm there's an error during the linking phase of the conftest program.
09:37 kshlm I don't get why it happened though.
09:38 ndevos kshlm: the nightly builds fail like this: configure: error: C compiler cannot create executables
09:40 ndevos kshlm: the OpenSSL error says "recompile with -fPIC", that option is passed by %configure in the glusterfs.spec, you should see that in the build.log
09:41 ndevos hmm, or maybe not...
09:45 an_ joined #gluster-dev
09:45 hagarth aravindavk: ping
09:46 ndevos kshlm: how about this? http://paste.fedoraproject.org/78145/13927167
09:46 * ndevos runs that in an epel-7 mock
09:49 aravindavk hagarth, pong
09:50 hagarth aravindavk: can you please update bug IDs for all these - http://review.gluster.org/#/q​/status:open+owner:+aravinda,n,z ?
09:50 ndarshan joined #gluster-dev
09:51 aravindavk hagarth, ok, will clone the downstream bug and add it, these patches are still under review
09:51 hagarth aravindavk: sure, that'll work. thanks.
09:51 kshlm ndevos: that works!
09:52 ndevos kshlm: we just need to verify that this does not break the things lpabon tried to fix with http://review.gluster.org/6957
10:02 kshlm I don't think the change breaks anything lpabon fixed. We still save and restore the CFLAGS and python code uses the new copies of the flags
10:02 kshlm so we don't break anything that lpabon fixed.
10:03 ndevos ah, good, I've not checked that
10:03 ndevos kshlm: can you post that patch, or shall I do that?
10:04 kshlm I can do it.
10:05 ndevos okay, thanks!
10:25 ira joined #gluster-dev
10:27 kshlm ndevos: https://bugzilla.redhat.co​m/show_bug.cgi?id=1066385 and http://review.gluster.org/7029
10:27 glusterbot Bug 1066385: unspecified, unspecified, ---, kaushal, ASSIGNED , rpmbuilds fail on epel7, f19 and f20
10:30 ndevos kshlm: looks good to me :)
10:32 kanagaraj joined #gluster-dev
10:59 mohankumar joined #gluster-dev
11:30 lalatenduM joined #gluster-dev
11:44 pk joined #gluster-dev
11:49 kkeithley1 joined #gluster-dev
11:53 jclift_ kshlm ndevos: Ahh cool, you guys found the fix for that rpms compilation problem. :)
11:54 jclift_ kshlm ndevos: I'd only gotten as far as identifying which commit broke ut, but didn't have time to investigate why.
11:56 kkeithley_ oh, what did you find?
12:05 an_ joined #gluster-dev
12:10 jclift_ kkeithley_: This is the fix they found: http://review.gluster.org/#/c/7029/
12:11 jclift_ kkeithley_: There was a recent change on git master that's breaking compilation on F19/F20/EL7.
12:11 jclift_ kkeithley_: Compilation on EL6 wasn't breaking though
12:12 jclift_ ndevos and Raghavendra have done reviewed it, but there's an updated patch set that needs a new review.
12:12 * jclift_ is testing it now to be safe, and will code review it as soon as confirmed
12:13 kkeithley_ ah, yup
12:14 itisravi joined #gluster-dev
12:16 pk left #gluster-dev
12:19 jclift_ Cool, compilation is all good on F19 again.
12:31 jclift_ kkeithley_: The regression run for my Glupy change is fialing here, but I'm not sure if it's a "real" failure vs a "something wrong with the test host" failure.
12:31 jclift_ http://build.gluster.org/job​/regression/3575/consoleFull
12:31 jclift_ kkeithley_: It's not failing for me when run locally. :/
12:33 jclift_ kkeithley_: Any ideas?
12:34 kkeithley_ not off the top of my head. Did rpm.t change?
12:36 jclift_ Hmmm, not by my patch, but I'll take a look. Tx. :)
12:37 kkeithley_ stuff in jenkins has seemed very brittle lately
12:42 jclift_ Yeah
12:43 jclift_ We need more regression testing hosts.
12:44 hagarth joined #gluster-dev
12:44 jclift_ We should probably put a call out on the front page.  Will ask JM when he's back from holiday next week, as that'll have more of an effect than anyone else asking I reckon.
12:51 an__ joined #gluster-dev
13:04 kkeithley_ I have a bunch of machines from the old Sunnyvale lab that are supposedly finally being racked. I see plans, lots of talk, but there's still nothing in racks.
13:07 kkeithley_ Once they're up and running though, they'll be available for that.
13:19 ndevos kkeithley_: do you know how easy it would be to setup a jenkins slave (or whatever it is called?)
13:20 ndevos kkeithley_: what if we have a VM image/template that can get downloaded/started and just runs regression tests?
13:22 lalatenduM ndevos, it is easy to setup a slave for Jenkins, i have done it myself
13:22 lalatenduM ndevos, let me know if you need any help on that
13:23 ndevos lalatenduM: its only an idea so far, but it would make it easier to setup machines and run multiple regression tests at the same time
13:23 jclift_ lalatenduM: Is it also easy to hook that into the main review.gluster.org testing?
13:24 jclift_ lalatenduM: eg so Community contributors can donate VM's for a while for us to use for testing
13:24 lalatenduM jclift_, yeah it can be done
13:24 jclift_ lalatenduM: Cool. :)
13:25 jclift_ ndevos: Sounds like your virt builder idea could be practical too. :)
13:25 lalatenduM jclift_, ndevos it is easy to setup slave, but we have to setup the test environment similar to review.gluster.org, so setting up test environment might take time depending upon the complexity
13:26 ndevos jclift_: I try to spend time only on practical things ;)
13:27 lalatenduM jclift_, ndevos but running multiple regression tests might need need change build script, not sure
13:27 lalatenduM s/change/change to/
13:27 ndevos lalatenduM: yes, the env should be very much the same, the test-script and such should ideally be packaged in an rpm - maybe in a project on the forge?
13:27 lalatenduM ndevos, yup
13:28 lalatenduM ndevos, didn't you submitted a patch to make the tests as a rpm? if I remember correctly
13:28 lalatenduM s/submitted/submit/
13:29 jclift_ ndevos: :)
13:29 ndevos lalatenduM: creating the structures for the bricks. mountpoint and all should not be too difficult - it's the starting of the tests and the result that needs to be given back to jenkins that I dont know about
13:29 ndevos lalatenduM: yeah, there is a regression-tests rpm, but that is different, its just <glusterfs>/tests/* being packaged
13:29 lalatenduM ndevos, actually it would be given to Gerrit
13:30 jclift_ ndevos: Hmmm, would having the test scripts and such in git be better than an rpm?  eg "git pull" prior to running the test suite would grab the latest?
13:30 lalatenduM ndevos, got it
13:30 jclift_ ndevos: Though we could just to "yum update" if we keep the test script rpms in a yum repo
13:31 jclift_ Hmmm, I have to run down the street
13:31 jclift_ Back in a bit
13:31 ndevos lalatenduM, jclift_: a regression test started by jenkins runs the tests from a git-pull + cherry-pick, the packaging of the tests is irrelevant for this case
13:32 jclift_ Cool
13:32 ndevos jclift_: fish 'n chips?
13:33 jclift_ No.  Accidentally left my notebook at a "Jobcentre Plus" office yesterday, when I went down there as part of getting a National Insurance number here in the UK so RH can pay me
13:33 jclift_ Need to go pick it up
13:34 jclift_ It has all my ToDo list stuff in it.
13:34 jclift_ :/
13:35 jclift_ ndevos: Would you have any time today to look over my latest Glupy rename patch? http://review.gluster.org/#/c/6979/
13:35 jclift_ ndevos: This one has the changelog entry, plus also moves all of the Glupy stuff into the -api rpm.
13:35 jclift_ (both the glupy.so, glupy.py, and glupy examples)
13:36 ndevos jclift_: hmm, I'll try, but am not completely happy about the packaging of it yet
13:36 jclift_ I was thinking that maybe the glupy examples (debug-trace.py, helloworld.py, negative.py) should go into the -api-devel rpm, but not sure it's important enough to warrant another patch set
13:37 jclift_ ndevos: You really want it in it's own set of rpms for 3.5 don't you?
13:37 ndevos jclift_: they should go into -devel for sure, but glupy in -api is temporary only anyway
13:37 jclift_ k, I can upload a new patch set later with the example glupy ones in -devel.
13:37 ndevos jclift_: a glusterfs-extra-xlators would be the cleanest solution
13:38 jclift_ ndevos: That's for 3.6 thought yeah?
13:38 jclift_ This patch set is specifically so we can backport it to 3.5, where Glupy is broken atm.
13:38 ndevos jclift_: I'm not sure, currently glupy can not be used, if we make it usable, it can be put in a glusterfs-extra-xlators too
13:39 jclift_ glupy _was_ usable until gluster.py took over it's namespace
13:39 ndevos kkeithley_: what is your opinion on packaging unused xlators (liek glupy, rot-13, ..) in a glusterfs-extra-xlators package?
13:40 ndevos kkeithley_: if we do not do that, and package glupy in the main glusterfs package, it'll introduce dependencies on python (which we don't have atm)
13:40 jclift_ Ugh
13:41 jclift_ kkeithley_: ndevos and I have been discussing having the glupy bits in the glusterfs-api rpm for 3.5 timeframe at least, as that already has a Python dependency
13:41 ndevos kkeithley_: glusterfs-api depends on python, for now, until libgfapi-python is packaged... current consensus with jclift_ was to package glupy in glusterfs-api (to keep the python deps there)
13:41 jclift_ In fact, I thought it was agreed that was ok (and uploaded patch set to achieve that), but ndevos is having 2nd thoughts. ;)
13:42 jclift_ So "lets get it done" so I can move on to other stuff instead of this taking another week?
13:42 ndevos I'm still "ok" with it, but we also know that it'll need changing soon again :-/
13:42 jclift_ We're up to beta <what> of Gluster 3.5 atm?
13:44 kkeithley_ Taking xlators like rot-13 and putting them in a -extras rpm is a good idea IMO
13:44 jclift_ k.  Should we do it for 3.5, or 3.6?
13:45 kkeithley_ Maybe glupy should be in its own rpm? I don't feel too strongly about it, but I'm not convinced it should be in the -api rpm.
13:45 kkeithley_ (so convince me!)
13:45 kkeithley_ Seems like we might have time to get it in 3.5. How does hagarth feel about it?
13:45 jclift_ I personally don't want to own the glupy rpm in Fedora packaging infrastructure, just because it's a "cleaner solution".
13:46 jclift_ If someone else is ok to be the owner, then I don't care either way.
13:46 jclift_ Just let me know how you guys want it, and I'll upload a new patch set to achieve it.
13:46 * jclift_ is just completely sick and tired of this dragging out :D
13:47 kkeithley_ if there were a glusterfs-glupy sub-package, you won't be the owner. If it were a separate, stand-alone package it would need an owner.
13:47 jclift_ Good.
13:47 jclift_ Well, you guys discuss, let me know the outcome? :>
13:47 jclift_ This is a blocker for 3.5, etc
13:48 kkeithley_ I just dont' want to split things out, then decide later to merge them back in, e.g. geo-rep.
13:48 * jclift_ goes to retrieve notebook
13:48 * ndevos hands jclift a piece of paper
13:49 jclift_ :p
13:50 ndevos kkeithley_: so, package glupy in a new glusterfs-extra-xlators and the examples (for any xlator) in glusterfs-devel?
13:50 ndevos changelog seems to come with some examples too
13:51 jclift_ We could chuck everything that's Python related (eg libgfapi, geo-rep syncdaemon, glupy) into a glusterfs-python pkg and be done with it.
13:52 ndevos ew!
13:52 * jclift_ shrugs
13:52 jclift_ That'd keep the dependencies pretty straight wouldn't it?
13:53 ndevos geo-rep and glusterd depend on each other now, we can't split those, and libgfapi will not depend on python much longer
13:53 an_ joined #gluster-dev
13:53 kkeithley_ dunno. libgfapi.so and gfapi.py seem closely related enough to warrant being in the same rpm.
13:54 ndevos well, libgfapi-python is a separate project now, I think it aims to replace the gfapi.py in the glusterfs sources
13:54 jclift_ libgfapi.so <-- c version of libgfapi.  gfapi.py <-- Python version, that depends on the C version
13:54 kkeithley_ python's so common, didn't one of you tell me it's always installed on fedora and RHEL?  We aren't really adding a dependency.
13:54 jclift_ nfi
13:54 jclift_ Ugh.  I really have to go.
13:54 jclift_ You guys figure it out. :)
13:54 * jclift_ leaves for reals this time
13:55 ndevos on systems where there is no yum, python does not need to be installed (like some cloud images)
13:55 ndevos at least, I think that was the case that was being made...
13:56 kkeithley_ oh, okay
13:56 bala joined #gluster-dev
13:57 jclift_ Maybe this conversation should be on -devel mailing list, as it's kind of significant in ramifications
13:57 jclift_ Wider audience would be useful too
13:57 * jclift_ checks
13:57 jclift_ gluster-devel: Members: 724
13:58 jclift_ Yeah
13:58 kkeithley_ run it up the flagpole, see if anyone responds
13:59 jclift_ ndevos: You ok to do that?
13:59 ndevos jclift_: you're delegating?
13:59 jclift_ Definitely. :D
13:59 jclift_ I'm also running late
13:59 ndevos sure, I'll send it
13:59 jclift_ :>
13:59 spandit joined #gluster-dev
14:00 bala joined #gluster-dev
14:11 bala1 joined #gluster-dev
14:16 kkeithley_ Looks like we just got patchbombed
14:17 ndevos wow, quite - snapshots!
14:21 ndevos proposed packaging changes email: http://thread.gmane.org/gmane.com​p.file-systems.gluster.devel/5701
14:42 edward2 joined #gluster-dev
15:08 spandit joined #gluster-dev
15:57 an_ joined #gluster-dev
16:18 nixpanic joined #gluster-dev
16:18 nixpanic joined #gluster-dev
16:30 wushudoin joined #gluster-dev
16:38 jobewan joined #gluster-dev
17:04 jclift_ ndevos: Good email.  Well explained. :)
17:06 jobewan joined #gluster-dev
17:07 lpabon joined #gluster-dev
17:19 ndevos jclift_: thanks, but maybe we can figure out when the dependency of -server on -geo-rep was introduced, it is not explicitly set in the .spec...
17:22 ndevos hmm, on epel-7 it does not seem that it is a requirement at all... I wonder what versions do have the dependency, maybe -server and -geo-rep can stay separate?
17:22 kkeithley_ rpm/rpmbuild has some autorequires magic
17:24 ndevos yeah, I tried to find the dependency, but I don't see it - -geo-rep seems to contain a hook directory that -server also contains, I'm not sure if that would be the cause
17:24 kkeithley_ seems like when I was getting nfs-ganesha packaging I was told I didn't need so much explicit Requires because rpm would figure out a lot by itself
17:24 ndevos at least on epel-7 -server installs fine without -geo-rep....
17:25 ndevos yes, and with versioned libraries, the automativ dependency generation is much more useful
17:27 kkeithley_ yeah, maybe in the rpm/rpmbuild in rhel7 they finally "got it right"
17:29 kkeithley_ going to run some errands on my lunch. biab
17:33 ndevos hmm, the rhs version of glusterfs-server has a explicit "Rerquires: glusterfs-geo-replication" for some reason, maybe that confused me?
17:36 jclift_ ndevos: Well if geo-rep can stay the same, does that change anything for your proposal?
17:36 ndevos jclift_: the proposal contained 2 points, -geo-rep merging in -server was one of them
17:37 jclift_ ndevos: Yeah, I'm not bothered either way really.  I just want a clear answer so I can update the Glupy patch and get it over and finished with asap.
17:38 jclift_ ndevos: There is _important_ external stuff waiting on the next version of GlusterFlow, so the delllaaayyyyyy in solid direction is screwing me around. ;)
17:38 ndevos jclift_: thats the 2nd point, create a glusterfs-extra-xlators package, we'll need to get some responses from that, and most devs are not online atm :)
17:39 ndevos oh, *important* stuff, yes?
17:40 jclift_ Was supposed to be by yesterday, so now I'm overtime.
17:53 an__ joined #gluster-dev
17:56 an__ joined #gluster-dev
17:57 an__ joined #gluster-dev
18:07 an___ joined #gluster-dev
18:12 an__ joined #gluster-dev
18:59 an___ joined #gluster-dev
19:00 kkeithley_ ndevos,jclift_: the only thing I see in the glusterfs-geo-replication rpm is /usr/libexec/gsyncd, which is linked to libglusterfs.so, and that's in the glusterfs-libs rpm. Everything else is python or a bash script
19:02 kkeithley_ gsyncd isn't linked to any other gluster libs
19:02 kkeithley_ I'd wager the dependency should really be on glusterfs-libs
19:35 ndevos kkeithley_: yes, geo-rep definitely should depend on -libs, it also makes sense for geo-rep to depend on -server (can't use it without glusterd), but the geo-rep dependency in -server is what bothers me
19:41 kkeithley_ Yes, I'd argue that -sgeo-rep requiring -server is more of a logical dependency than a hard requirement; I'm not saying we should remove it. It would be good to understand how rpmbuild is coming up with the dependency on -geo-rep in the -server rpm
19:48 ndevos well, that may be my confusion, and the community packages dont have that dependency? I've not checked different versions though, maybe the -server requiring -geo-rep is only in rhs
19:58 kkeithley_ I'm a bit confused too now
20:24 ndk joined #gluster-dev
21:57 an__ joined #gluster-dev
23:18 portante joined #gluster-dev

| Channels | #gluster-dev index | Today | | Search | Google Search | Plain-Text | summary