avro-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Patrick Hunt <ph...@apache.org>
Subject Re: [VOTE] Avro release 1.3.0 (rc 1)
Date Mon, 22 Feb 2010 21:34:12 GMT

Doug Cutting wrote:
> Patrick Hunt wrote:
>> I cannot build on Ubuntu Karmic (with all latest apt patches from 
>> canonical applied), avro ruby requires echoe which requires a version 
>> of gem (not echoe but gem, see below) not avail on Karmic. This seems 
>> like it's going to cause problems for a large number of users?
> Hmm.  I built & tested the release on Ubuntu Karmic.  I thought I listed 
> all the packages I installed in the README.txt.
>> phunt@valhalla:~/a/avro-src-1.3.0$ sudo gem install echoe
>> ERROR:  Error installing echoe:
>>     gemcutter requires RubyGems version >= 1.3.6
> That command works for me.  How did you install gem?  I used 'sudo 
> apt-get install rubygems'.

This is weird, I had "rubygems1.8" installed (per apt). I noticed that 
there is also "rubygems" pkg available on ubuntu servers. I installed 
that and it fixed the problem! That is unusual, esp as "rubygems" 
doesn't really have anything in it:
regardless, installing that pkg seems to have fixed the problem - I'm 
now able to install echoe. (see below, still issues)

>> Also, the README states that the ruby build requires a gem that cannot 
>> be found:
>> phunt@valhalla:~/a/avro-src-1.3.0$ sudo gem install jajl-ruby
>> ERROR:  could not find gem jajl-ruby locally or in a repository
> Oops.  That's a typo.  Should be 'yajl-ruby'.

I tried installing "yajl-ruby" using gem and that failed as "mkmf" was 
not available. It seems that there is also a requirement that "ruby-dev" 
be installed, not just ruby. You might save some hassle by putting that 
in the readme at the same time as fixing the typo. (btw, usually this is 
not an issue, but I just upgraded my machine and I'm starting with a 
fresh install of ubuntu karmic 64bit, haven't accreted all the pkgs yet 
;-) )

After this point I was able to compile/test all the lang pkgs (although 
I didn't try the interop tests) successfully.

>> Additionally:
>> What are we voting on, the entire set of files or some subset of files 
>> in this release candidate directory? I've always been told Apache 
>> requires voting on a single archive containing all of the artifacts 
>> that make up the "release". Is this no longer the case?
> The primary release artifact is the avro-src-.x.y.x.tar.gz archive.  The 
> others are generated from this as conveniences.  We could, I supposed 
> bundle everything up into a single tarball.  Do you think that would be 
> better?  Do you think we should somehow make this clearer, e.g., with a 
> README.txt in the distribution?

README would definitely help, at least avail if someone cares enough.

However it seems to me that either the "conveniences" are part of the 
official release or not (this should be made explicit when calling the 
vote). If not then we should not be considering them as part of the vote.

>> FYI test-tools in java fails if JAVA_HOME is not set (but fine for the 
>> rest of the build up to that point? why's that? easy to fix?):
>> test-tools:
>>      [exec] Error: JAVA_HOME is not set.
>>      [exec] + set -o errexit
>>      [exec] + '[' '' = '' ']'
>>      [exec] + echo 'Error: JAVA_HOME is not set.'
>>      [exec] + exit 1
> Isn't JAVA_HOME required by lots of tools?  For example, the hadoop 
> shell scripts all fail if it's not set, no?  That said, I don't think we 
> use JAVA_HOME for more than finding the java executable, so we could 
> instead just run whatever 'java' is on PATH.

Most of the time not AFAICT, as I use a number of java tools and I don't 
have it set (maybe they set themselves?). First it's come up, granted a 
relatively new install of ubuntu. Anyway, as I alluded to, doesn't seem 

>> When I access this release candidate link I see a list of archives, 
>> jars, eggs, sha1, md5, pom, etc.... files. Consider adding a README 
>> that gives me some insight into what I should download based on my 
>> intended usage. I think that would help users significantly.
> Yes, that's probably a good idea.




View raw message