On Thu, Feb 11, 2010 at 9:00 AM, Owen O'Malley <[email protected]> wrote: > > On Feb 10, 2010, at 10:51 PM, Todd Lipcon wrote: > >> I applied HADOOP-5612 to fix this, though I think creating a tarball >> after chmod 755ing the configure scripts would also be correct. > > *Sigh* You can't blame a release for not containing one of your patches, if > you didn't ask for it to be applied to the relevant branch. If you want it > to be included in the next 0.20 release, reopen the jira and ask for it to > be applied back to branch-0.20. >
Yes, I should have asked at the time to put it in 20. I had newly started working on Hadoop when I did that patch and didn't know the proper JIRA protocol at the time. Will do so now. Like I said in my mail, I'm not trying to block a release. I'm just reporting the errors I ran into trying to use the release candidate - if the rest of the community or PMC thinks it's not worth rolling a new one, I'll leave it up to them. Regardless, it has nothing to do with whether it's "my patch" - I think it reflects poorly on the project when the releases fail to build on a common system configuration. >> These same problems are present as seen in the branch-20 Hudson build: >> http://hudson.zones.apache.org/hudson/job/Hadoop-20-Build/67/console > > The problem on Hudson seems to be that automake 1.9 is not installed. That > seems like a different issue. > automake should not be a build time requirement for released artifacts in pretty much any sane project. autotools "make dist" targets always include a configure script, which means automake was already run by the developer. After applying the patches mentioned above that fix missing header includes, I built just fine on my box that has no automake-1.9. >> 3) It would be nice if the tarball had libhdfs included in c++/lib > > It does have the .so for libhdfs. > > hadoop-0.20.2/c++/Linux-i386-32/lib/libhdfs.so > > I assume you were looking for the 64 bit version. Did someone get the 64 bit > libhdfs working? If so, we should update the HowToRelease twiki to include > it. After applying the patches I mentioned, the ant command quoted above succeeded in building libhdfs just fine: build/c++/Linux-amd64-64/lib/libhdfs.so.0.0.0: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, not stripped If others think these are blockers, I'm happy to roll a new candidate tarball later this week once they've been pushed into branch-20. Although I don't have a binding vote in the release process, I am pretty sure the ASF policies are fine with anyone rolling an rc and calling a vote. If no one else thinks these patches are worth stalling for, that's fine too. Thanks -Todd
