You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@kudu.apache.org by Jean-Daniel Cryans <jd...@apache.org> on 2016/02/08 19:21:02 UTC
[VOTE] Apache Kudu (incubating) 0.7.0 RC1
Hi,
We're happy to announce the first 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-RC1/
It was built from this tag:
https://git1-us-west.apache.org/repos/asf?p=incubator-kudu.git;a=commit;h=2e28d1aec47d86eba15b4ba3d8b40b34c410ca8a
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
(Resolved)%20AND%20fixVersion%20%3D%200.7.0%20ORDER%20BY%20key%20ASC>.
The release notes are found here (linking to github for prettier printing):
https://github.com/cloudera/kudu/blob/0.7.0-RC1/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 72 hours.
Thanks,
J-D
Re: [VOTE] Apache Kudu (incubating) 0.7.0 RC1
Posted by Jarek Jarcec Cecho <ja...@apache.org>.
LICENSE and NOTICE files are quite often pointed out when doing release verification on general@incubator, so I would recommend fixing that even though that the linked [1] document contains “should” instead of “must”. We might be able to defend that, but it will most certainly lead to unnecessary discussions and delays.
ASLv2 have a special clause under “redistribution” section for NOTICE file [2] that requests derivative works to also include the relevant portions of our notice file. Hence having proper ASF copyright seems like a good idea.
Just my 2 cents :)
Jarcec
Links:
1: http://apache.org/legal/src-headers.html#notice
2: http://www.apache.org/licenses/LICENSE-2.0.html#redistribution
> On Feb 10, 2016, at 6:02 PM, Todd Lipcon <to...@cloudera.com> wrote:
>
> Hm, good catch. I'm not sure if this is a release blocker, though -- the
> page you cite says "should" and not "MUST". The only "must" for notice is
> that anything that is legally required, but I don't believe that string of
> text is legally required.
>
> Any mentors with more licensing experience want to weigh in here? Is this
> something that we can address in our next release, or should we restart the
> vote with this fixed?
>
> -Todd
>
> On Wed, Feb 10, 2016 at 3:11 PM, Mike Percy <mp...@apache.org> wrote:
>
>> I did the following:
>>
>> 1. Checked the .asc sig (looks good)
>> 2. Built the source. I ran into the issue with gold that Todd identified. I
>> think it's unfortunate that we're not compatible with gold (we typically
>> are), but agree that it's not a release blocker. After switching to GNU ld
>> I was able to rebuild thirdparty, then build Kudu. All of the tests passed.
>> 3. Quickly looked through the LICENSE.txt file and it looks good to me.
>> 4. Checked the NOTICE.txt file. It doesn't appear to comply with
>> http://apache.org/legal/src-headers.html#notice so I submitted a patch for
>> that at http://gerrit.cloudera.org:8080/2108 ... I think this may be a
>> release blocker.
>>
>> Mike
>>
>> On Mon, Feb 8, 2016 at 8:21 PM, Jean-Daniel Cryans <jd...@apache.org>
>> wrote:
>>
>>> Hi,
>>>
>>> We're happy to announce the first 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-RC1/
>>>
>>> It was built from this tag:
>>>
>>>
>> https://git1-us-west.apache.org/repos/asf?p=incubator-kudu.git;a=commit;h=2e28d1aec47d86eba15b4ba3d8b40b34c410ca8a
>>>
>>> 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
>>> (Resolved)%20AND%20fixVersion%20%3D%200.7.0%20ORDER%20BY%20key%20ASC>.
>>>
>>> The release notes are found here (linking to github for prettier
>> printing):
>>>
>>>
>> https://github.com/cloudera/kudu/blob/0.7.0-RC1/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 72 hours.
>>>
>>> Thanks,
>>>
>>> J-D
>>>
>>
>
>
>
> --
> Todd Lipcon
> Software Engineer, Cloudera
Re: [VOTE] Apache Kudu (incubating) 0.7.0 RC1
Posted by Todd Lipcon <to...@cloudera.com>.
Hm, good catch. I'm not sure if this is a release blocker, though -- the
page you cite says "should" and not "MUST". The only "must" for notice is
that anything that is legally required, but I don't believe that string of
text is legally required.
Any mentors with more licensing experience want to weigh in here? Is this
something that we can address in our next release, or should we restart the
vote with this fixed?
-Todd
On Wed, Feb 10, 2016 at 3:11 PM, Mike Percy <mp...@apache.org> wrote:
> I did the following:
>
> 1. Checked the .asc sig (looks good)
> 2. Built the source. I ran into the issue with gold that Todd identified. I
> think it's unfortunate that we're not compatible with gold (we typically
> are), but agree that it's not a release blocker. After switching to GNU ld
> I was able to rebuild thirdparty, then build Kudu. All of the tests passed.
> 3. Quickly looked through the LICENSE.txt file and it looks good to me.
> 4. Checked the NOTICE.txt file. It doesn't appear to comply with
> http://apache.org/legal/src-headers.html#notice so I submitted a patch for
> that at http://gerrit.cloudera.org:8080/2108 ... I think this may be a
> release blocker.
>
> Mike
>
> On Mon, Feb 8, 2016 at 8:21 PM, Jean-Daniel Cryans <jd...@apache.org>
> wrote:
>
> > Hi,
> >
> > We're happy to announce the first 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-RC1/
> >
> > It was built from this tag:
> >
> >
> https://git1-us-west.apache.org/repos/asf?p=incubator-kudu.git;a=commit;h=2e28d1aec47d86eba15b4ba3d8b40b34c410ca8a
> >
> > 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
> > (Resolved)%20AND%20fixVersion%20%3D%200.7.0%20ORDER%20BY%20key%20ASC>.
> >
> > The release notes are found here (linking to github for prettier
> printing):
> >
> >
> https://github.com/cloudera/kudu/blob/0.7.0-RC1/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 72 hours.
> >
> > Thanks,
> >
> > J-D
> >
>
--
Todd Lipcon
Software Engineer, Cloudera
Re: [VOTE] Apache Kudu (incubating) 0.7.0 RC1
Posted by Mike Percy <mp...@apache.org>.
I did the following:
1. Checked the .asc sig (looks good)
2. Built the source. I ran into the issue with gold that Todd identified. I
think it's unfortunate that we're not compatible with gold (we typically
are), but agree that it's not a release blocker. After switching to GNU ld
I was able to rebuild thirdparty, then build Kudu. All of the tests passed.
3. Quickly looked through the LICENSE.txt file and it looks good to me.
4. Checked the NOTICE.txt file. It doesn't appear to comply with
http://apache.org/legal/src-headers.html#notice so I submitted a patch for
that at http://gerrit.cloudera.org:8080/2108 ... I think this may be a
release blocker.
Mike
On Mon, Feb 8, 2016 at 8:21 PM, Jean-Daniel Cryans <jd...@apache.org>
wrote:
> Hi,
>
> We're happy to announce the first 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-RC1/
>
> It was built from this tag:
>
> https://git1-us-west.apache.org/repos/asf?p=incubator-kudu.git;a=commit;h=2e28d1aec47d86eba15b4ba3d8b40b34c410ca8a
>
> 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
> (Resolved)%20AND%20fixVersion%20%3D%200.7.0%20ORDER%20BY%20key%20ASC>.
>
> The release notes are found here (linking to github for prettier printing):
>
> https://github.com/cloudera/kudu/blob/0.7.0-RC1/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 72 hours.
>
> Thanks,
>
> J-D
>
Re: [VOTE] Apache Kudu (incubating) 0.7.0 RC1
Posted by Adar Dembo <ad...@cloudera.com>.
Good digging. Using that information, I was able to figure out why my build
of the 0.7.0 tarball passed and yours didn't: I had libgflags installed via
system package, and that's where glog was going to satisfy the dependency:
adar@adar-ThinkPad-T540p:~/Source/kudu/build/debug$ ldd
./bin/protoc-gen-insertions | grep gflags
libgflags.so.2 => /usr/lib/x86_64-linux-gnu/libgflags.so.2
(0x00007fbdb14a7000)
After I removed the package, protoc-gen-insertions failed the same way for
me as it did for you. I'm using gold too, though my toolchain is probably
newer than yours (gcc 5.2.1, binutils 2.25.1).
For the time being I've worked around this by not using gold.
On Tue, Feb 9, 2016 at 7:48 AM, Todd Lipcon <to...@cloudera.com> wrote:
> Figured out a few more clues on this:
>
> 1) I usually use gold rather than binutils ld as my linker. gold generates
> RUNPATH instead of RPATH by default, which has the difference that RUNPATH
> doesn't propagate transitively. In other words, even though
> protoc-gen-insertions has installed-deps/lib in its RUNPATH, it doesn't use
> _that_ RPATH when looking for dependencies of libglog.so, because
> libglog.so has its own RUNPATH.
> 2) my libglog.so's RUNPATH doesn't have installed-deps/. It turns out that,
> after I rebuilt my thirdparty from git completely clean, that one didn't
> end up with it either. It only got installed-deps/ in its RUNPATH before
> because I had an old 'libgflags.la' file lying around.
> 3) we no longer generate 'libgflags.la' from the gflags build
> after 7a68e1f8baee04eaf259f7567ddc39e09a0f0938 which switched from using
> autotools to cmake to build and install gflag. This means that we don't
> generate the libtool control file 'libgflags.la' anymore, though my old
> one
> got orphaned in the build directory.
>
> If I switch back to binutils ld as my linker, everything seems fine. So, I
> think my takeaway is that the current state of master doesn't build with
> shared linking using gold. Since most _users_ will probably want to build
> release binaries (static-linked) anyway, and that works fine, I don't think
> this is a release blocker. We should try to figure it out and fix it in
> master, though, since it might hurt some developers (such as myself!)
>
> So, after that whole saga, I'm +1. Here's my detached signature for the
> release tarball:
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1
>
> iEUEABECAAYFAla6CTgACgkQXkPKua7Hfq9e1wCeIEWC+t+rIjjPFFCbl1me1YPH
> DyIAlRM1FzuKIVQ1FEfJR9Bzk/QQrhQ=
> =WXqA
> -----END PGP SIGNATURE-----
>
> -Todd
>
>
>
>
>
> On Tue, Feb 9, 2016 at 1:28 AM, Todd Lipcon <to...@cloudera.com> wrote:
>
> > I think I narrowed down the issue a bit. In my release dir build, I have:
> >
> > todd@todd-ThinkPad-T540p:/tmp/apache-kudu-incubating-0.7.0/build/debug$
> > objdump -x ../../thirdparty/installed-deps/lib/libglog.so | grep PATH
> > RUNPATH
> > /tmp/apache-kudu-incubating-0.7.0/thirdparty/installed/lib
> >
> > whereas in my working git checkout I have:
> >
> > todd@todd-ThinkPad-T540p:~/git/kudu/build/debug$ objdump -x
> > ../../thirdparty/installed-deps/lib/libglog.so | grep PATH
> > RUNPATH
> >
> /home/todd/git/kudu/thirdparty/installed-deps/lib:/home/todd/git/kudu/thirdparty/installed/lib
> >
> >
> > I built the release using the 'build-support/jenkins/build-and-test.sh'
> > script. Somehow when this builds thirdparty in the context of the release
> > tarball, it ends up generating an incorrect rpath. Have to run to the
> first
> > ever Tokyo Kudu Meetup at the moment, but figured I'd dump state here in
> > case it rings a bell for anyone. The only thing I could think of is that
> > case where running clang from the wrong path can produce executables with
> > missing rpath elems, but not sure how that could be happening here (have
> no
> > clang on my path)
> >
> > On Mon, Feb 8, 2016 at 11:46 PM, Todd Lipcon <to...@cloudera.com> wrote:
> >
> >> hm, I was actually trying a debug build (shared linking) and hit the
> >> issue. Something odd with rpaths that I can't quite figure out.
> Building a
> >> release build seems to work OK here... I'll keep trying to investigate a
> >> bit before casting an official vote.
> >>
> >> On Mon, Feb 8, 2016 at 4:32 PM, Adar Dembo <ad...@cloudera.com> wrote:
> >>
> >>> I've built the tarball on Ubuntu 15.10 and I didn't run into any
> issues.
> >>> Note that I'm using my system's cmake (3.2.2) and not the one in
> >>> thirdparty
> >>> (3.2.3). The commands I used:
> >>> - thirdparty/build-if-necessary.sh
> >>> - mkdir -p build/debug
> >>> - cd build/debug
> >>> - cmake ../..
> >>> - make -j8
> >>>
> >>> On Mon, Feb 8, 2016 at 3:43 PM, Todd Lipcon <to...@cloudera.com> wrote:
> >>>
> >>> > I'm building from the rc tarball here and hit this issue on Ubuntu
> >>> 14.04:
> >>> >
> >>> >
> >>>
> /tmp/apache-kudu-incubating-0.7.0/build/debug/bin/protoc-gen-insertions:
> >>> > error while loading shared libraries: libgflags.so.2: cannot open
> >>> shared
> >>> > object file: No such file or directory--insertions_out:
> >>> > protoc-gen-insertions: Plugin failed with status code 127.
> >>> >
> >>>
> /tmp/apache-kudu-incubating-0.7.0/build/debug/bin/protoc-gen-insertions:
> >>> > error while loading shared libraries: libgflags.so.2: cannot open
> >>> shared
> >>> > object file: No such file or directory
> >>> >
> >>> > ...which is odd because I can see libgflags.so in
> >>> > thirdparty/installed-deps/lib/
> >>> >
> >>> > Anyone else seen the issue? Will dig into it more later today JP
> time,
> >>> but
> >>> > may be an rc-sinker.
> >>> >
> >>> > -Todd
> >>> >
> >>> >
> >>> > On Mon, Feb 8, 2016 at 10:21 AM, Jean-Daniel Cryans <
> >>> jdcryans@apache.org>
> >>> > wrote:
> >>> >
> >>> > > Hi,
> >>> > >
> >>> > > We're happy to announce the first 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-RC1/
> >>> > >
> >>> > > It was built from this tag:
> >>> > >
> >>> > >
> >>> >
> >>>
> https://git1-us-west.apache.org/repos/asf?p=incubator-kudu.git;a=commit;h=2e28d1aec47d86eba15b4ba3d8b40b34c410ca8a
> >>> > >
> >>> > > 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
> >>> > >
> >>> (Resolved)%20AND%20fixVersion%20%3D%200.7.0%20ORDER%20BY%20key%20ASC>.
> >>> > >
> >>> > > The release notes are found here (linking to github for prettier
> >>> > printing):
> >>> > >
> >>> > >
> >>> >
> >>>
> https://github.com/cloudera/kudu/blob/0.7.0-RC1/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 72
> >>> hours.
> >>> > >
> >>> > > Thanks,
> >>> > >
> >>> > > J-D
> >>> > >
> >>> >
> >>> >
> >>> >
> >>> > --
> >>> > Todd Lipcon
> >>> > Software Engineer, Cloudera
> >>> >
> >>>
> >>
> >>
> >>
> >> --
> >> Todd Lipcon
> >> Software Engineer, Cloudera
> >>
> >
> >
> >
> > --
> > Todd Lipcon
> > Software Engineer, Cloudera
> >
>
>
>
> --
> Todd Lipcon
> Software Engineer, Cloudera
>
Re: [VOTE] Apache Kudu (incubating) 0.7.0 RC1
Posted by Jean-Daniel Cryans <jd...@gmail.com>.
Thanks Todd, mind filing a jira as a blocker for 0.8.0?
J-D
On Tue, Feb 9, 2016 at 7:48 AM, Todd Lipcon <to...@cloudera.com> wrote:
> Figured out a few more clues on this:
>
> 1) I usually use gold rather than binutils ld as my linker. gold generates
> RUNPATH instead of RPATH by default, which has the difference that RUNPATH
> doesn't propagate transitively. In other words, even though
> protoc-gen-insertions has installed-deps/lib in its RUNPATH, it doesn't use
> _that_ RPATH when looking for dependencies of libglog.so, because
> libglog.so has its own RUNPATH.
> 2) my libglog.so's RUNPATH doesn't have installed-deps/. It turns out that,
> after I rebuilt my thirdparty from git completely clean, that one didn't
> end up with it either. It only got installed-deps/ in its RUNPATH before
> because I had an old 'libgflags.la' file lying around.
> 3) we no longer generate 'libgflags.la' from the gflags build
> after 7a68e1f8baee04eaf259f7567ddc39e09a0f0938 which switched from using
> autotools to cmake to build and install gflag. This means that we don't
> generate the libtool control file 'libgflags.la' anymore, though my old
> one
> got orphaned in the build directory.
>
> If I switch back to binutils ld as my linker, everything seems fine. So, I
> think my takeaway is that the current state of master doesn't build with
> shared linking using gold. Since most _users_ will probably want to build
> release binaries (static-linked) anyway, and that works fine, I don't think
> this is a release blocker. We should try to figure it out and fix it in
> master, though, since it might hurt some developers (such as myself!)
>
> So, after that whole saga, I'm +1. Here's my detached signature for the
> release tarball:
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1
>
> iEUEABECAAYFAla6CTgACgkQXkPKua7Hfq9e1wCeIEWC+t+rIjjPFFCbl1me1YPH
> DyIAlRM1FzuKIVQ1FEfJR9Bzk/QQrhQ=
> =WXqA
> -----END PGP SIGNATURE-----
>
> -Todd
>
>
>
>
>
> On Tue, Feb 9, 2016 at 1:28 AM, Todd Lipcon <to...@cloudera.com> wrote:
>
> > I think I narrowed down the issue a bit. In my release dir build, I have:
> >
> > todd@todd-ThinkPad-T540p:/tmp/apache-kudu-incubating-0.7.0/build/debug$
> > objdump -x ../../thirdparty/installed-deps/lib/libglog.so | grep PATH
> > RUNPATH
> > /tmp/apache-kudu-incubating-0.7.0/thirdparty/installed/lib
> >
> > whereas in my working git checkout I have:
> >
> > todd@todd-ThinkPad-T540p:~/git/kudu/build/debug$ objdump -x
> > ../../thirdparty/installed-deps/lib/libglog.so | grep PATH
> > RUNPATH
> >
> /home/todd/git/kudu/thirdparty/installed-deps/lib:/home/todd/git/kudu/thirdparty/installed/lib
> >
> >
> > I built the release using the 'build-support/jenkins/build-and-test.sh'
> > script. Somehow when this builds thirdparty in the context of the release
> > tarball, it ends up generating an incorrect rpath. Have to run to the
> first
> > ever Tokyo Kudu Meetup at the moment, but figured I'd dump state here in
> > case it rings a bell for anyone. The only thing I could think of is that
> > case where running clang from the wrong path can produce executables with
> > missing rpath elems, but not sure how that could be happening here (have
> no
> > clang on my path)
> >
> > On Mon, Feb 8, 2016 at 11:46 PM, Todd Lipcon <to...@cloudera.com> wrote:
> >
> >> hm, I was actually trying a debug build (shared linking) and hit the
> >> issue. Something odd with rpaths that I can't quite figure out.
> Building a
> >> release build seems to work OK here... I'll keep trying to investigate a
> >> bit before casting an official vote.
> >>
> >> On Mon, Feb 8, 2016 at 4:32 PM, Adar Dembo <ad...@cloudera.com> wrote:
> >>
> >>> I've built the tarball on Ubuntu 15.10 and I didn't run into any
> issues.
> >>> Note that I'm using my system's cmake (3.2.2) and not the one in
> >>> thirdparty
> >>> (3.2.3). The commands I used:
> >>> - thirdparty/build-if-necessary.sh
> >>> - mkdir -p build/debug
> >>> - cd build/debug
> >>> - cmake ../..
> >>> - make -j8
> >>>
> >>> On Mon, Feb 8, 2016 at 3:43 PM, Todd Lipcon <to...@cloudera.com> wrote:
> >>>
> >>> > I'm building from the rc tarball here and hit this issue on Ubuntu
> >>> 14.04:
> >>> >
> >>> >
> >>>
> /tmp/apache-kudu-incubating-0.7.0/build/debug/bin/protoc-gen-insertions:
> >>> > error while loading shared libraries: libgflags.so.2: cannot open
> >>> shared
> >>> > object file: No such file or directory--insertions_out:
> >>> > protoc-gen-insertions: Plugin failed with status code 127.
> >>> >
> >>>
> /tmp/apache-kudu-incubating-0.7.0/build/debug/bin/protoc-gen-insertions:
> >>> > error while loading shared libraries: libgflags.so.2: cannot open
> >>> shared
> >>> > object file: No such file or directory
> >>> >
> >>> > ...which is odd because I can see libgflags.so in
> >>> > thirdparty/installed-deps/lib/
> >>> >
> >>> > Anyone else seen the issue? Will dig into it more later today JP
> time,
> >>> but
> >>> > may be an rc-sinker.
> >>> >
> >>> > -Todd
> >>> >
> >>> >
> >>> > On Mon, Feb 8, 2016 at 10:21 AM, Jean-Daniel Cryans <
> >>> jdcryans@apache.org>
> >>> > wrote:
> >>> >
> >>> > > Hi,
> >>> > >
> >>> > > We're happy to announce the first 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-RC1/
> >>> > >
> >>> > > It was built from this tag:
> >>> > >
> >>> > >
> >>> >
> >>>
> https://git1-us-west.apache.org/repos/asf?p=incubator-kudu.git;a=commit;h=2e28d1aec47d86eba15b4ba3d8b40b34c410ca8a
> >>> > >
> >>> > > 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
> >>> > >
> >>> (Resolved)%20AND%20fixVersion%20%3D%200.7.0%20ORDER%20BY%20key%20ASC>.
> >>> > >
> >>> > > The release notes are found here (linking to github for prettier
> >>> > printing):
> >>> > >
> >>> > >
> >>> >
> >>>
> https://github.com/cloudera/kudu/blob/0.7.0-RC1/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 72
> >>> hours.
> >>> > >
> >>> > > Thanks,
> >>> > >
> >>> > > J-D
> >>> > >
> >>> >
> >>> >
> >>> >
> >>> > --
> >>> > Todd Lipcon
> >>> > Software Engineer, Cloudera
> >>> >
> >>>
> >>
> >>
> >>
> >> --
> >> Todd Lipcon
> >> Software Engineer, Cloudera
> >>
> >
> >
> >
> > --
> > Todd Lipcon
> > Software Engineer, Cloudera
> >
>
>
>
> --
> Todd Lipcon
> Software Engineer, Cloudera
>
Re: [VOTE] Apache Kudu (incubating) 0.7.0 RC1
Posted by Todd Lipcon <to...@cloudera.com>.
Figured out a few more clues on this:
1) I usually use gold rather than binutils ld as my linker. gold generates
RUNPATH instead of RPATH by default, which has the difference that RUNPATH
doesn't propagate transitively. In other words, even though
protoc-gen-insertions has installed-deps/lib in its RUNPATH, it doesn't use
_that_ RPATH when looking for dependencies of libglog.so, because
libglog.so has its own RUNPATH.
2) my libglog.so's RUNPATH doesn't have installed-deps/. It turns out that,
after I rebuilt my thirdparty from git completely clean, that one didn't
end up with it either. It only got installed-deps/ in its RUNPATH before
because I had an old 'libgflags.la' file lying around.
3) we no longer generate 'libgflags.la' from the gflags build
after 7a68e1f8baee04eaf259f7567ddc39e09a0f0938 which switched from using
autotools to cmake to build and install gflag. This means that we don't
generate the libtool control file 'libgflags.la' anymore, though my old one
got orphaned in the build directory.
If I switch back to binutils ld as my linker, everything seems fine. So, I
think my takeaway is that the current state of master doesn't build with
shared linking using gold. Since most _users_ will probably want to build
release binaries (static-linked) anyway, and that works fine, I don't think
this is a release blocker. We should try to figure it out and fix it in
master, though, since it might hurt some developers (such as myself!)
So, after that whole saga, I'm +1. Here's my detached signature for the
release tarball:
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iEUEABECAAYFAla6CTgACgkQXkPKua7Hfq9e1wCeIEWC+t+rIjjPFFCbl1me1YPH
DyIAlRM1FzuKIVQ1FEfJR9Bzk/QQrhQ=
=WXqA
-----END PGP SIGNATURE-----
-Todd
On Tue, Feb 9, 2016 at 1:28 AM, Todd Lipcon <to...@cloudera.com> wrote:
> I think I narrowed down the issue a bit. In my release dir build, I have:
>
> todd@todd-ThinkPad-T540p:/tmp/apache-kudu-incubating-0.7.0/build/debug$
> objdump -x ../../thirdparty/installed-deps/lib/libglog.so | grep PATH
> RUNPATH
> /tmp/apache-kudu-incubating-0.7.0/thirdparty/installed/lib
>
> whereas in my working git checkout I have:
>
> todd@todd-ThinkPad-T540p:~/git/kudu/build/debug$ objdump -x
> ../../thirdparty/installed-deps/lib/libglog.so | grep PATH
> RUNPATH
> /home/todd/git/kudu/thirdparty/installed-deps/lib:/home/todd/git/kudu/thirdparty/installed/lib
>
>
> I built the release using the 'build-support/jenkins/build-and-test.sh'
> script. Somehow when this builds thirdparty in the context of the release
> tarball, it ends up generating an incorrect rpath. Have to run to the first
> ever Tokyo Kudu Meetup at the moment, but figured I'd dump state here in
> case it rings a bell for anyone. The only thing I could think of is that
> case where running clang from the wrong path can produce executables with
> missing rpath elems, but not sure how that could be happening here (have no
> clang on my path)
>
> On Mon, Feb 8, 2016 at 11:46 PM, Todd Lipcon <to...@cloudera.com> wrote:
>
>> hm, I was actually trying a debug build (shared linking) and hit the
>> issue. Something odd with rpaths that I can't quite figure out. Building a
>> release build seems to work OK here... I'll keep trying to investigate a
>> bit before casting an official vote.
>>
>> On Mon, Feb 8, 2016 at 4:32 PM, Adar Dembo <ad...@cloudera.com> wrote:
>>
>>> I've built the tarball on Ubuntu 15.10 and I didn't run into any issues.
>>> Note that I'm using my system's cmake (3.2.2) and not the one in
>>> thirdparty
>>> (3.2.3). The commands I used:
>>> - thirdparty/build-if-necessary.sh
>>> - mkdir -p build/debug
>>> - cd build/debug
>>> - cmake ../..
>>> - make -j8
>>>
>>> On Mon, Feb 8, 2016 at 3:43 PM, Todd Lipcon <to...@cloudera.com> wrote:
>>>
>>> > I'm building from the rc tarball here and hit this issue on Ubuntu
>>> 14.04:
>>> >
>>> >
>>> /tmp/apache-kudu-incubating-0.7.0/build/debug/bin/protoc-gen-insertions:
>>> > error while loading shared libraries: libgflags.so.2: cannot open
>>> shared
>>> > object file: No such file or directory--insertions_out:
>>> > protoc-gen-insertions: Plugin failed with status code 127.
>>> >
>>> /tmp/apache-kudu-incubating-0.7.0/build/debug/bin/protoc-gen-insertions:
>>> > error while loading shared libraries: libgflags.so.2: cannot open
>>> shared
>>> > object file: No such file or directory
>>> >
>>> > ...which is odd because I can see libgflags.so in
>>> > thirdparty/installed-deps/lib/
>>> >
>>> > Anyone else seen the issue? Will dig into it more later today JP time,
>>> but
>>> > may be an rc-sinker.
>>> >
>>> > -Todd
>>> >
>>> >
>>> > On Mon, Feb 8, 2016 at 10:21 AM, Jean-Daniel Cryans <
>>> jdcryans@apache.org>
>>> > wrote:
>>> >
>>> > > Hi,
>>> > >
>>> > > We're happy to announce the first 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-RC1/
>>> > >
>>> > > It was built from this tag:
>>> > >
>>> > >
>>> >
>>> https://git1-us-west.apache.org/repos/asf?p=incubator-kudu.git;a=commit;h=2e28d1aec47d86eba15b4ba3d8b40b34c410ca8a
>>> > >
>>> > > 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
>>> > >
>>> (Resolved)%20AND%20fixVersion%20%3D%200.7.0%20ORDER%20BY%20key%20ASC>.
>>> > >
>>> > > The release notes are found here (linking to github for prettier
>>> > printing):
>>> > >
>>> > >
>>> >
>>> https://github.com/cloudera/kudu/blob/0.7.0-RC1/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 72
>>> hours.
>>> > >
>>> > > Thanks,
>>> > >
>>> > > J-D
>>> > >
>>> >
>>> >
>>> >
>>> > --
>>> > Todd Lipcon
>>> > Software Engineer, Cloudera
>>> >
>>>
>>
>>
>>
>> --
>> Todd Lipcon
>> Software Engineer, Cloudera
>>
>
>
>
> --
> Todd Lipcon
> Software Engineer, Cloudera
>
--
Todd Lipcon
Software Engineer, Cloudera
Re: [VOTE] Apache Kudu (incubating) 0.7.0 RC1
Posted by Todd Lipcon <to...@cloudera.com>.
I think I narrowed down the issue a bit. In my release dir build, I have:
todd@todd-ThinkPad-T540p:/tmp/apache-kudu-incubating-0.7.0/build/debug$
objdump -x ../../thirdparty/installed-deps/lib/libglog.so | grep PATH
RUNPATH
/tmp/apache-kudu-incubating-0.7.0/thirdparty/installed/lib
whereas in my working git checkout I have:
todd@todd-ThinkPad-T540p:~/git/kudu/build/debug$ objdump -x
../../thirdparty/installed-deps/lib/libglog.so | grep PATH
RUNPATH
/home/todd/git/kudu/thirdparty/installed-deps/lib:/home/todd/git/kudu/thirdparty/installed/lib
I built the release using the 'build-support/jenkins/build-and-test.sh'
script. Somehow when this builds thirdparty in the context of the release
tarball, it ends up generating an incorrect rpath. Have to run to the first
ever Tokyo Kudu Meetup at the moment, but figured I'd dump state here in
case it rings a bell for anyone. The only thing I could think of is that
case where running clang from the wrong path can produce executables with
missing rpath elems, but not sure how that could be happening here (have no
clang on my path)
On Mon, Feb 8, 2016 at 11:46 PM, Todd Lipcon <to...@cloudera.com> wrote:
> hm, I was actually trying a debug build (shared linking) and hit the
> issue. Something odd with rpaths that I can't quite figure out. Building a
> release build seems to work OK here... I'll keep trying to investigate a
> bit before casting an official vote.
>
> On Mon, Feb 8, 2016 at 4:32 PM, Adar Dembo <ad...@cloudera.com> wrote:
>
>> I've built the tarball on Ubuntu 15.10 and I didn't run into any issues.
>> Note that I'm using my system's cmake (3.2.2) and not the one in
>> thirdparty
>> (3.2.3). The commands I used:
>> - thirdparty/build-if-necessary.sh
>> - mkdir -p build/debug
>> - cd build/debug
>> - cmake ../..
>> - make -j8
>>
>> On Mon, Feb 8, 2016 at 3:43 PM, Todd Lipcon <to...@cloudera.com> wrote:
>>
>> > I'm building from the rc tarball here and hit this issue on Ubuntu
>> 14.04:
>> >
>> > /tmp/apache-kudu-incubating-0.7.0/build/debug/bin/protoc-gen-insertions:
>> > error while loading shared libraries: libgflags.so.2: cannot open shared
>> > object file: No such file or directory--insertions_out:
>> > protoc-gen-insertions: Plugin failed with status code 127.
>> > /tmp/apache-kudu-incubating-0.7.0/build/debug/bin/protoc-gen-insertions:
>> > error while loading shared libraries: libgflags.so.2: cannot open shared
>> > object file: No such file or directory
>> >
>> > ...which is odd because I can see libgflags.so in
>> > thirdparty/installed-deps/lib/
>> >
>> > Anyone else seen the issue? Will dig into it more later today JP time,
>> but
>> > may be an rc-sinker.
>> >
>> > -Todd
>> >
>> >
>> > On Mon, Feb 8, 2016 at 10:21 AM, Jean-Daniel Cryans <
>> jdcryans@apache.org>
>> > wrote:
>> >
>> > > Hi,
>> > >
>> > > We're happy to announce the first 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-RC1/
>> > >
>> > > It was built from this tag:
>> > >
>> > >
>> >
>> https://git1-us-west.apache.org/repos/asf?p=incubator-kudu.git;a=commit;h=2e28d1aec47d86eba15b4ba3d8b40b34c410ca8a
>> > >
>> > > 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
>> > > (Resolved)%20AND%20fixVersion%20%3D%200.7.0%20ORDER%20BY%20key%20ASC>.
>> > >
>> > > The release notes are found here (linking to github for prettier
>> > printing):
>> > >
>> > >
>> >
>> https://github.com/cloudera/kudu/blob/0.7.0-RC1/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 72
>> hours.
>> > >
>> > > Thanks,
>> > >
>> > > J-D
>> > >
>> >
>> >
>> >
>> > --
>> > Todd Lipcon
>> > Software Engineer, Cloudera
>> >
>>
>
>
>
> --
> Todd Lipcon
> Software Engineer, Cloudera
>
--
Todd Lipcon
Software Engineer, Cloudera
Re: [VOTE] Apache Kudu (incubating) 0.7.0 RC1
Posted by Todd Lipcon <to...@cloudera.com>.
hm, I was actually trying a debug build (shared linking) and hit the issue.
Something odd with rpaths that I can't quite figure out. Building a release
build seems to work OK here... I'll keep trying to investigate a bit before
casting an official vote.
On Mon, Feb 8, 2016 at 4:32 PM, Adar Dembo <ad...@cloudera.com> wrote:
> I've built the tarball on Ubuntu 15.10 and I didn't run into any issues.
> Note that I'm using my system's cmake (3.2.2) and not the one in thirdparty
> (3.2.3). The commands I used:
> - thirdparty/build-if-necessary.sh
> - mkdir -p build/debug
> - cd build/debug
> - cmake ../..
> - make -j8
>
> On Mon, Feb 8, 2016 at 3:43 PM, Todd Lipcon <to...@cloudera.com> wrote:
>
> > I'm building from the rc tarball here and hit this issue on Ubuntu 14.04:
> >
> > /tmp/apache-kudu-incubating-0.7.0/build/debug/bin/protoc-gen-insertions:
> > error while loading shared libraries: libgflags.so.2: cannot open shared
> > object file: No such file or directory--insertions_out:
> > protoc-gen-insertions: Plugin failed with status code 127.
> > /tmp/apache-kudu-incubating-0.7.0/build/debug/bin/protoc-gen-insertions:
> > error while loading shared libraries: libgflags.so.2: cannot open shared
> > object file: No such file or directory
> >
> > ...which is odd because I can see libgflags.so in
> > thirdparty/installed-deps/lib/
> >
> > Anyone else seen the issue? Will dig into it more later today JP time,
> but
> > may be an rc-sinker.
> >
> > -Todd
> >
> >
> > On Mon, Feb 8, 2016 at 10:21 AM, Jean-Daniel Cryans <jdcryans@apache.org
> >
> > wrote:
> >
> > > Hi,
> > >
> > > We're happy to announce the first 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-RC1/
> > >
> > > It was built from this tag:
> > >
> > >
> >
> https://git1-us-west.apache.org/repos/asf?p=incubator-kudu.git;a=commit;h=2e28d1aec47d86eba15b4ba3d8b40b34c410ca8a
> > >
> > > 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
> > > (Resolved)%20AND%20fixVersion%20%3D%200.7.0%20ORDER%20BY%20key%20ASC>.
> > >
> > > The release notes are found here (linking to github for prettier
> > printing):
> > >
> > >
> >
> https://github.com/cloudera/kudu/blob/0.7.0-RC1/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 72
> hours.
> > >
> > > Thanks,
> > >
> > > J-D
> > >
> >
> >
> >
> > --
> > Todd Lipcon
> > Software Engineer, Cloudera
> >
>
--
Todd Lipcon
Software Engineer, Cloudera
Re: [VOTE] Apache Kudu (incubating) 0.7.0 RC1
Posted by Adar Dembo <ad...@cloudera.com>.
I've built the tarball on Ubuntu 15.10 and I didn't run into any issues.
Note that I'm using my system's cmake (3.2.2) and not the one in thirdparty
(3.2.3). The commands I used:
- thirdparty/build-if-necessary.sh
- mkdir -p build/debug
- cd build/debug
- cmake ../..
- make -j8
On Mon, Feb 8, 2016 at 3:43 PM, Todd Lipcon <to...@cloudera.com> wrote:
> I'm building from the rc tarball here and hit this issue on Ubuntu 14.04:
>
> /tmp/apache-kudu-incubating-0.7.0/build/debug/bin/protoc-gen-insertions:
> error while loading shared libraries: libgflags.so.2: cannot open shared
> object file: No such file or directory--insertions_out:
> protoc-gen-insertions: Plugin failed with status code 127.
> /tmp/apache-kudu-incubating-0.7.0/build/debug/bin/protoc-gen-insertions:
> error while loading shared libraries: libgflags.so.2: cannot open shared
> object file: No such file or directory
>
> ...which is odd because I can see libgflags.so in
> thirdparty/installed-deps/lib/
>
> Anyone else seen the issue? Will dig into it more later today JP time, but
> may be an rc-sinker.
>
> -Todd
>
>
> On Mon, Feb 8, 2016 at 10:21 AM, Jean-Daniel Cryans <jd...@apache.org>
> wrote:
>
> > Hi,
> >
> > We're happy to announce the first 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-RC1/
> >
> > It was built from this tag:
> >
> >
> https://git1-us-west.apache.org/repos/asf?p=incubator-kudu.git;a=commit;h=2e28d1aec47d86eba15b4ba3d8b40b34c410ca8a
> >
> > 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
> > (Resolved)%20AND%20fixVersion%20%3D%200.7.0%20ORDER%20BY%20key%20ASC>.
> >
> > The release notes are found here (linking to github for prettier
> printing):
> >
> >
> https://github.com/cloudera/kudu/blob/0.7.0-RC1/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 72 hours.
> >
> > Thanks,
> >
> > J-D
> >
>
>
>
> --
> Todd Lipcon
> Software Engineer, Cloudera
>
Re: [VOTE] Apache Kudu (incubating) 0.7.0 RC1
Posted by Todd Lipcon <to...@cloudera.com>.
I'm building from the rc tarball here and hit this issue on Ubuntu 14.04:
/tmp/apache-kudu-incubating-0.7.0/build/debug/bin/protoc-gen-insertions:
error while loading shared libraries: libgflags.so.2: cannot open shared
object file: No such file or directory--insertions_out:
protoc-gen-insertions: Plugin failed with status code 127.
/tmp/apache-kudu-incubating-0.7.0/build/debug/bin/protoc-gen-insertions:
error while loading shared libraries: libgflags.so.2: cannot open shared
object file: No such file or directory
...which is odd because I can see libgflags.so in
thirdparty/installed-deps/lib/
Anyone else seen the issue? Will dig into it more later today JP time, but
may be an rc-sinker.
-Todd
On Mon, Feb 8, 2016 at 10:21 AM, Jean-Daniel Cryans <jd...@apache.org>
wrote:
> Hi,
>
> We're happy to announce the first 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-RC1/
>
> It was built from this tag:
>
> https://git1-us-west.apache.org/repos/asf?p=incubator-kudu.git;a=commit;h=2e28d1aec47d86eba15b4ba3d8b40b34c410ca8a
>
> 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
> (Resolved)%20AND%20fixVersion%20%3D%200.7.0%20ORDER%20BY%20key%20ASC>.
>
> The release notes are found here (linking to github for prettier printing):
>
> https://github.com/cloudera/kudu/blob/0.7.0-RC1/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 72 hours.
>
> Thanks,
>
> J-D
>
--
Todd Lipcon
Software Engineer, Cloudera