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.
ph...@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:
http://packages.ubuntu.com/karmic/all/rubygems/filelist
vs
http://packages.ubuntu.com/karmic/all/rubygems1.8/filelist
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:
ph...@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
critical.
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.
;-)
Regards,
Patrick
