I forgot to mention, I'll handle the third one (about docs). On Tue, Feb 16, 2016 at 11:04 AM, Jean-Daniel Cryans <[email protected]> wrote:
> Voting on RC2 is now cancelled. Things we need for RC3: > > - Fix license files (Mike seems to be working on this). This is the main > blocker. > - Fix KUDU-1328 (Adar assigned himself). > - Fix the documentation around the CSD and improve troubleshooting when > not building Kudu correctly on RHEL 6. > > J-D > > > On Tue, Feb 16, 2016 at 10:46 AM, Jean-Daniel Cryans <[email protected]> > wrote: > >> On Tue, Feb 16, 2016 at 10:37 AM, Stack <[email protected]> wrote: >> >>> On Tue, Feb 16, 2016 at 9:25 AM, Jean-Daniel Cryans <[email protected] >>> > >>> wrote: >>> >>> > Hey Stack, >>> > >>> > Thanks for trying it out. >>> > >>> > On Tue, Feb 16, 2016 at 9:04 AM, Stack <[email protected]> wrote: >>> > >>> > > Hash and signature looks good. >>> > > >>> > > Should cmake_modules/* have license on them? E.g. FindBitsshuffl..., >>> > > FindGFLags.cmake, etc. Some of the files in here have license, >>> others do >>> > > not. >>> > > >>> > > docs/transaction_semantics is missing a license? >>> > > >>> > >>> > We should sink this RC and fix it. >>> > >>> > >>> Yeah. When it goes out on the general incubator list for a vote, this is >>> the first thing our Apache brothers and sisters will look for. If they >>> find >>> stuff, your mentors will look bad (smile). >>> >> >> Yup, sinking! >> >> >>> >>> >>> > >>> > > >>> > > I didn't look much beyond the above. There are some notes below on my >>> > > bungling trying to build... >>> > > >>> > > >>> > > St.Ack >>> > > >>> > > >>> > > Tried to build on CentOS release 6.6 (Final) >>> > > >>> > > Built appropriate cmake. Then when I run it, got this far (though >>> > libatomic >>> > > installed ... see below). Wrong version? Centos 6.6 not usual place >>> to >>> > do a >>> > > build? >>> > > >>> > > -- Performing Test HAVE_CXX_ATOMICS_WITHOUT_LIB >>> > > -- Performing Test HAVE_CXX_ATOMICS_WITHOUT_LIB - Failed >>> > > -- Looking for __atomic_fetch_add_4 in atomic >>> > > -- Looking for __atomic_fetch_add_4 in atomic - not found >>> > > CMake Error at cmake/modules/CheckAtomic.cmake:36 (message): >>> > > Host compiler appears to require libatomic, but cannot find it. >>> > > Call Stack (most recent call first): >>> > > cmake/config-ix.cmake:291 (include) >>> > > CMakeLists.txt:360 (include) >>> > > ... >>> > > >>> > >>> > You need to do this: >>> > >>> > >>> https://github.com/cloudera/kudu/blob/master/docs/installation.adoc#rhel_from_source >>> > >>> > >>> > Thanks. My fault. I fell into the README.adoc >>> >>> The link to the troubleshooting hole punching doc, from here >>> >>> https://github.com/cloudera/kudu/blob/master/docs/installation.adoc#rhel_from_source >>> , >>> is broke FYI: >>> >>> https://github.com/cloudera/kudu/blob/master/docs/troubleshooting.html#req_hole_punching >> >> >> That's just because github is trying to render the adocs, when we >> generate the site the html files will be there. We haven't generated a new >> site yet for 0.7.0 and those instructions are new. >> >> >>> >>> >>> I got this installing asciidoctor >>> >>> ERROR: While generating documentation for asciidoctor-1.5.4 >>> ... MESSAGE: Unhandled special: Special: type=17, text="<!--1-->" >>> ... RDOC args: --ri --op /usr/lib/ruby/gems/1.8/doc/asciidoctor-1.5.4/ri >>> --charset=UTF-8 --quiet lib CHANGELOG.adoc CONTRIBUTING.adoc LICENSE.adoc >>> --title asciidoctor-1.5.4 Documentation >>> (continuing with the rest of the installation) >>> >>> I did all the prereqs from installation.adoc... for rhel and built third >>> party stuff (script ran nicely for me). When I go to build kudu I get: >>> >>> cc1plus: error: unrecognized command line option "-std=c++11" >>> cc1plus: error: unrecognized command line option "-std=c++11" >>> make[2]: *** [src/kudu/gutil/CMakeFiles/gutil_exported.dir/cpu.cc.o] >>> Error 1 >>> make[2]: *** Waiting for unfinished jobs.... >>> cc1plus: error: unrecognized command line option "-std=c++11" >>> make[2]: *** >>> >>> [src/kudu/gutil/CMakeFiles/gutil_exported.dir/atomicops-internals-x86.cc.o] >>> Error 1 >>> cc1plus: error: unrecognized command line option "-std=c++11"cc1plus: >>> error: unrecognized command line option "-std=c++11" >>> >>> >>> Wrong c++ version? >>> >> >> You also need to use the enable toolset stuff when running cmake (like it >> shows in the docs), else you get exactly those lines. Not sure about the >> asciidoctor stuff. >> >> >>> >>> >>> >>> > > >>> > > [stack@ve0524 debug]$ sudo yum install libatomic >>> > > Loaded plugins: fastestmirror, priorities, security >>> > > Setting up Install Process >>> > > Loading mirror speeds from cached hostfile >>> > > 124 packages excluded due to repository priority protections >>> > > Package libatomic-4.9.0-6.1.1.el6.x86_64 already installed and latest >>> > > version >>> > > Nothing to do >>> > > >>> > > >>> > > Tried to build docs and got this: >>> > > >>> > > [stack@ve0524 apache-kudu-incubating-0.7.0]$ pwd >>> > > /home/stack/apache-kudu-incubating-0.7.0 >>> > > [stack@ve0524 apache-kudu-incubating-0.7.0]$ make docs >>> > > make: Nothing to be done for `docs'. >>> > > >>> > >>> > Pretty sure that's because cmake above failed. >>> > >>> > >>> Maybe the above complaint install asciidoc? >>> >> >> Nah a missing target is just cmake failing to generate the files make >> needs. >> >> >>> >>> >>> >>> > >>> > > >>> > > >>> > > >>> > > "Also by default, building the CSD does not validate it, >>> > > because (for the moment) this requires access to an internal >>> > > Cloudera repository containing the validator maven plugin." >>> > > >>> > > Is above still the case? >>> > > >>> > >>> > Yes. Do you think the CSD should live somewhere else? >>> > >>> > >>> Smile. I don't know what a CSD is (though I'm guessing I should). It goes >>> undefined. >>> >>> When you say 'for the moment' in the above, it implies you are working on >>> moving this tooling out of Cloudera to a public place. As long as that is >>> ongoing, that seems fine to me. >>> >> >> I don't think there's a plan for this. Lemme check. >> >> >>> >>> Thanks, >>> St.Ack >>> >>> >>> > >>> > > >>> > > >>> > > St.Ack >>> > > >>> > > >>> > > >>> > > >>> > > >>> > > >>> > > >>> > > On Thu, Feb 11, 2016 at 6:55 PM, Jean-Daniel Cryans < >>> [email protected] >>> > > >>> > > wrote: >>> > > >>> > > > Hi, >>> > > > >>> > > > Here's the second release candidate for Apache Kudu (incubating) >>> 0.7.0. >>> > > > >>> > > > The is a source-only release. The artifacts were staged here: >>> > > > https://dist.apache.org/repos/dist/dev/incubator/kudu/0.7.0-RC2/ >>> > > > >>> > > > It was built from this tag: >>> > > > >>> > > > >>> > > >>> > >>> https://git1-us-west.apache.org/repos/asf?p=incubator-kudu.git;a=commit;h=899d79a246161b4429663f23d135bc8fdcac4372 >>> > > > >>> > > > The list of all issues fixed is found following this link >>> > > > < >>> > > > >>> > > >>> > >>> https://issues.cloudera.org/issues/?jql=project%20%3D%20Kudu%20AND%20status%20in%20%20(Resolved)%20AND%20fixVersion%20%3D%200.7.0%20ORDER%20BY%20key%20ASC >>> > > > > >>> > > > . >>> > > > >>> > > > The following commits made it in since the last RC: >>> > > > 899d79a Set -rpath in all thirdparty libs for compat with gold >>> > > > a9af916 Reorg of release notes to be more flexible as we add more >>> > > releases >>> > > > in future >>> > > > b3eb88e Update NOTICE.txt to include Apache copyright >>> > > > >>> > > > The release notes are found here (linking to github for prettier >>> > > printing): >>> > > > >>> > > > >>> > > >>> > >>> https://github.com/cloudera/kudu/blob/0.7.0-RC2/docs/release_notes.adoc#release-notes-specific-to-0-7-0 >>> > > > >>> > > > KEYS file: >>> > > > http://www.apache.org/dist/incubator/kudu/KEYS >>> > > > >>> > > > I'd suggest going through the README, building Kudu, and running >>> the >>> > unit >>> > > > tests. >>> > > > >>> > > > Please try the release and vote; vote will be open for at least 120 >>> > hours >>> > > > (due to the long weekend in the US). >>> > > > >>> > > > Thanks, >>> > > > >>> > > > J-D >>> > > > >>> > > >>> > >>> >> >> >
