FWIW, I just noticed that we accidentally retained memkind in thirdparty/LICENSE.txt. I published a patch to fix this on master (http://gerrit.cloudera.org:8080/14703), but given that memkind's license was always ASF-compliant, I don't think the inclusion merits a new RC, and it doesn't alter my +1.
On Tue, Nov 12, 2019 at 12:16 PM Alexey Serbin <[email protected]> wrote: > > Thank you for the verification of 1.10.1-RC2. > > The missing and required piece between 1.10.1-RC1 and 1.10.1-RC2 was > 990f612bb. > Without the changelist, invocation of the build_mini_cluster_binaries.sh > script was returning an error because of missing licensing info for > libyaml-cpp: kudu-master and kudu-tserver binaries are dynamically linked > with that thirdparty library. > > On Tue, Nov 12, 2019 at 1:14 AM Adar Lieber-Dembo <[email protected]> > wrote: > > > +1 > > > > On Ubuntu 18.04 I built RELEASE with NO_TESTS=1 and verified that > > there were no numa or memkind dependencies or symbols in any binaries. > > I also grepped for numa and memkind across the codebase and didn't see > > any unexpected dependencies. > > > > Also on Ubuntu 18.04 I built DEBUG and verified that all tests passed > > in slow mode. > > > > > P.S. RC1 vote wasn't run since the 1.10.1-RC1 tag was placed on a > > snapshot > > > that failed to build kudu-binaries JAR artifact). > > > > What caused the build to fail? I see these commits in RC2 but not in RC1: > > * e437f5add - (tag: 1.10.1-RC2, origin-internal/branch-1.10.x, > > gerrit/branch-1.10.x, apache/branch-1.10.x) [build-support] fix on > > enable_devtoolset_inner.sh (2 days ago) <Alexey Serbin> > > * 98bb8d2fc - [thirdparty] add license info about yaml-cpp (2 days > > ago) <Alexey Serbin> > > * 990f612bb - [build-support] add info on libyaml-cpp (2 days ago) > > <Alexey Serbin> > >
