You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@arrow.apache.org by Sutou Kouhei <ko...@clear-code.com> on 2019/07/01 05:32:40 UTC
[VOTE] Release Apache Arrow 0.14.0 - RC0
Hi,
I would like to propose the following release candidate (RC0) of Apache
Arrow version 0.14.0. This is a release consiting of 618
resolved JIRA issues[1].
This release candidate is based on commit:
a591d76ad9a657110368aa422bb00f4010cb6b6e [2]
The source release rc0 is hosted at [3].
The binary artifacts are hosted at [4][5][6][7].
The changelog is located at [8].
Please download, verify checksums and signatures, run the unit tests,
and vote on the release. See [9] for how to validate a release candidate.
NOTE: You must use verify-release-candidate.sh at master.
I've fixed some problems after apache-arrow-0.14.0 tag.
C#'s "sourcelink test" is fragile. (Network related problem?)
It may be better that we add retry logic to "sourcelink test".
The vote will be open for at least 72 hours.
[ ] +1 Release this as Apache Arrow 0.14.0
[ ] +0
[ ] -1 Do not release this as Apache Arrow 0.14.0 because...
[1]: https://issues.apache.org/jira/issues/?jql=project%20%3D%20ARROW%20AND%20status%20in%20%28Resolved%2C%20Closed%29%20AND%20fixVersion%20%3D%200.14.0
[2]: https://github.com/apache/arrow/tree/a591d76ad9a657110368aa422bb00f4010cb6b6e
[3]: https://dist.apache.org/repos/dist/dev/arrow/apache-arrow-0.14.0-rc0
[4]: https://bintray.com/apache/arrow/centos-rc/0.14.0-rc0
[5]: https://bintray.com/apache/arrow/debian-rc/0.14.0-rc0
[6]: https://bintray.com/apache/arrow/python-rc/0.14.0-rc0
[7]: https://bintray.com/apache/arrow/ubuntu-rc/0.14.0-rc0
[8]: https://github.com/apache/arrow/blob/a591d76ad9a657110368aa422bb00f4010cb6b6e/CHANGELOG.md
[9]: https://cwiki.apache.org/confluence/display/ARROW/How+to+Verify+Release+Candidates
Thanks,
--
kou
Re: [VOTE] Release Apache Arrow 0.14.0 - RC0
Posted by Sutou Kouhei <ko...@clear-code.com>.
Thanks for verifying this RC!
> - Conda activate issue: https://issues.apache.org/jira/browse/ARROW-5837
This has been resolved at master:
https://issues.apache.org/jira/browse/ARROW-5820
> - Grpc cannot find OpenSSL: https://issues.apache.org/jira/browse/ARROW-5838
I've created a pull request for this:
https://github.com/apache/arrow/pull/4795
> - Usual plasma error: Socket pathname is too long.
Should we skip this case automatically like
https://github.com/apache/arrow/pull/4793 ?
In <CA...@mail.gmail.com>
"Re: [VOTE] Release Apache Arrow 0.14.0 - RC0" on Wed, 3 Jul 2019 17:08:48 +0200,
Krisztián Szűcs <sz...@gmail.com> wrote:
> My vote is: +1 (binding)
>
> Tested on macOS Mojave.
>
> Passing:
> Source, Binaries, C++, Python, Rust, Go, C#, GLib, Ruby, JS
>
> Found issues (none of them are blocking):
> - Java flight tests are failing:
> https://issues.apache.org/jira/browse/ARROW-5836
> - Conda activate issue: https://issues.apache.org/jira/browse/ARROW-5837
> - Grpc cannot find OpenSSL: https://issues.apache.org/jira/browse/ARROW-5838
> - Unused variable warning: https://issues.apache.org/jira/browse/ARROW-5840
> - Integration: cannot run integration because of failing java tests
> - Usual plasma error: Socket pathname is too long.
>
> On Mon, Jul 1, 2019 at 7:33 AM Sutou Kouhei <ko...@clear-code.com> wrote:
>
>> Hi,
>>
>> I would like to propose the following release candidate (RC0) of Apache
>> Arrow version 0.14.0. This is a release consiting of 618
>> resolved JIRA issues[1].
>>
>> This release candidate is based on commit:
>> a591d76ad9a657110368aa422bb00f4010cb6b6e [2]
>>
>> The source release rc0 is hosted at [3].
>> The binary artifacts are hosted at [4][5][6][7].
>> The changelog is located at [8].
>>
>> Please download, verify checksums and signatures, run the unit tests,
>> and vote on the release. See [9] for how to validate a release candidate.
>>
>> NOTE: You must use verify-release-candidate.sh at master.
>> I've fixed some problems after apache-arrow-0.14.0 tag.
>> C#'s "sourcelink test" is fragile. (Network related problem?)
>> It may be better that we add retry logic to "sourcelink test".
>>
>> The vote will be open for at least 72 hours.
>>
>> [ ] +1 Release this as Apache Arrow 0.14.0
>> [ ] +0
>> [ ] -1 Do not release this as Apache Arrow 0.14.0 because...
>>
>> [1]:
>> https://issues.apache.org/jira/issues/?jql=project%20%3D%20ARROW%20AND%20status%20in%20%28Resolved%2C%20Closed%29%20AND%20fixVersion%20%3D%200.14.0
>> [2]:
>> https://github.com/apache/arrow/tree/a591d76ad9a657110368aa422bb00f4010cb6b6e
>> [3]: https://dist.apache.org/repos/dist/dev/arrow/apache-arrow-0.14.0-rc0
>> [4]: https://bintray.com/apache/arrow/centos-rc/0.14.0-rc0
>> [5]: https://bintray.com/apache/arrow/debian-rc/0.14.0-rc0
>> [6]: https://bintray.com/apache/arrow/python-rc/0.14.0-rc0
>> [7]: https://bintray.com/apache/arrow/ubuntu-rc/0.14.0-rc0
>> [8]:
>> https://github.com/apache/arrow/blob/a591d76ad9a657110368aa422bb00f4010cb6b6e/CHANGELOG.md
>> [9]:
>> https://cwiki.apache.org/confluence/display/ARROW/How+to+Verify+Release+Candidates
>>
>>
>> Thanks,
>> --
>> kou
>>
Re: [VOTE] Release Apache Arrow 0.14.0 - RC0
Posted by Krisztián Szűcs <sz...@gmail.com>.
My vote is: +1 (binding)
Tested on macOS Mojave.
Passing:
Source, Binaries, C++, Python, Rust, Go, C#, GLib, Ruby, JS
Found issues (none of them are blocking):
- Java flight tests are failing:
https://issues.apache.org/jira/browse/ARROW-5836
- Conda activate issue: https://issues.apache.org/jira/browse/ARROW-5837
- Grpc cannot find OpenSSL: https://issues.apache.org/jira/browse/ARROW-5838
- Unused variable warning: https://issues.apache.org/jira/browse/ARROW-5840
- Integration: cannot run integration because of failing java tests
- Usual plasma error: Socket pathname is too long.
On Mon, Jul 1, 2019 at 7:33 AM Sutou Kouhei <ko...@clear-code.com> wrote:
> Hi,
>
> I would like to propose the following release candidate (RC0) of Apache
> Arrow version 0.14.0. This is a release consiting of 618
> resolved JIRA issues[1].
>
> This release candidate is based on commit:
> a591d76ad9a657110368aa422bb00f4010cb6b6e [2]
>
> The source release rc0 is hosted at [3].
> The binary artifacts are hosted at [4][5][6][7].
> The changelog is located at [8].
>
> Please download, verify checksums and signatures, run the unit tests,
> and vote on the release. See [9] for how to validate a release candidate.
>
> NOTE: You must use verify-release-candidate.sh at master.
> I've fixed some problems after apache-arrow-0.14.0 tag.
> C#'s "sourcelink test" is fragile. (Network related problem?)
> It may be better that we add retry logic to "sourcelink test".
>
> The vote will be open for at least 72 hours.
>
> [ ] +1 Release this as Apache Arrow 0.14.0
> [ ] +0
> [ ] -1 Do not release this as Apache Arrow 0.14.0 because...
>
> [1]:
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20ARROW%20AND%20status%20in%20%28Resolved%2C%20Closed%29%20AND%20fixVersion%20%3D%200.14.0
> [2]:
> https://github.com/apache/arrow/tree/a591d76ad9a657110368aa422bb00f4010cb6b6e
> [3]: https://dist.apache.org/repos/dist/dev/arrow/apache-arrow-0.14.0-rc0
> [4]: https://bintray.com/apache/arrow/centos-rc/0.14.0-rc0
> [5]: https://bintray.com/apache/arrow/debian-rc/0.14.0-rc0
> [6]: https://bintray.com/apache/arrow/python-rc/0.14.0-rc0
> [7]: https://bintray.com/apache/arrow/ubuntu-rc/0.14.0-rc0
> [8]:
> https://github.com/apache/arrow/blob/a591d76ad9a657110368aa422bb00f4010cb6b6e/CHANGELOG.md
> [9]:
> https://cwiki.apache.org/confluence/display/ARROW/How+to+Verify+Release+Candidates
>
>
> Thanks,
> --
> kou
>
Re: [VOTE] Release Apache Arrow 0.14.0 - RC0
Posted by Sutou Kouhei <ko...@clear-code.com>.
+1 (binding)
I ran the followings on Debian GNU/Linux sid:
* JAVA_HOME=/usr/lib/jvm/java-8-openjdk-amd64 CUDA_TOOLKIT_ROOT=/usr dev/release/verify-release-candidate.sh source 0.14.0 0
* dev/release/verify-release-candidate.sh binaries 0.14.0 0
with:
* gcc (Debian 8.3.0-7) 8.3.0
* openjdk version "1.8.0_212"
* ruby 2.7.0dev (2019-06-30T02:53:02Z trunk 75129c62eb) [x86_64-linux]
* Node.JS v12.1.0
* go version go1.11.6 linux/amd64
* nvidia-cuda-dev 9.2.148-7
But C# test fails sometimes.
So I re-run C# tests by the following command line:
TEST_DEFAULT=0 TEST_SOURCE=1 TEST_CSHARP=1 dev/release/verify-release-candidate.sh source 0.14.0 0
Thanks,
--
kou
In <20...@clear-code.com>
"[VOTE] Release Apache Arrow 0.14.0 - RC0" on Mon, 01 Jul 2019 14:32:40 +0900 (JST),
Sutou Kouhei <ko...@clear-code.com> wrote:
> Hi,
>
> I would like to propose the following release candidate (RC0) of Apache
> Arrow version 0.14.0. This is a release consiting of 618
> resolved JIRA issues[1].
>
> This release candidate is based on commit:
> a591d76ad9a657110368aa422bb00f4010cb6b6e [2]
>
> The source release rc0 is hosted at [3].
> The binary artifacts are hosted at [4][5][6][7].
> The changelog is located at [8].
>
> Please download, verify checksums and signatures, run the unit tests,
> and vote on the release. See [9] for how to validate a release candidate.
>
> NOTE: You must use verify-release-candidate.sh at master.
> I've fixed some problems after apache-arrow-0.14.0 tag.
> C#'s "sourcelink test" is fragile. (Network related problem?)
> It may be better that we add retry logic to "sourcelink test".
>
> The vote will be open for at least 72 hours.
>
> [ ] +1 Release this as Apache Arrow 0.14.0
> [ ] +0
> [ ] -1 Do not release this as Apache Arrow 0.14.0 because...
>
> [1]: https://issues.apache.org/jira/issues/?jql=project%20%3D%20ARROW%20AND%20status%20in%20%28Resolved%2C%20Closed%29%20AND%20fixVersion%20%3D%200.14.0
> [2]: https://github.com/apache/arrow/tree/a591d76ad9a657110368aa422bb00f4010cb6b6e
> [3]: https://dist.apache.org/repos/dist/dev/arrow/apache-arrow-0.14.0-rc0
> [4]: https://bintray.com/apache/arrow/centos-rc/0.14.0-rc0
> [5]: https://bintray.com/apache/arrow/debian-rc/0.14.0-rc0
> [6]: https://bintray.com/apache/arrow/python-rc/0.14.0-rc0
> [7]: https://bintray.com/apache/arrow/ubuntu-rc/0.14.0-rc0
> [8]: https://github.com/apache/arrow/blob/a591d76ad9a657110368aa422bb00f4010cb6b6e/CHANGELOG.md
> [9]: https://cwiki.apache.org/confluence/display/ARROW/How+to+Verify+Release+Candidates
>
>
> Thanks,
> --
> kou
Re: [VOTE] Release Apache Arrow 0.14.0 - RC0
Posted by Sutou Kouhei <ko...@clear-code.com>.
Hi,
Thanks for verifying this RC.
> - failed to verify binaries
>
> """
> + echo 'Failed to verify release candidate. See /tmp/arrow-0.14.0.gucvU
> for details.'
> Failed to verify release candidate. See /tmp/arrow-0.14.0.gucvU for details.
> """
>
> There's no details in /tmp/arrow-0.14.0.gucvU. The script left a lot of
> zombie curl processes running...
It seems that one of curl downloads is failed.
Parallel download may be fragile.
https://github.com/apache/arrow/pull/4768 by Wes will solve
this situation. I've merged this.
> - failed to verify sources
>
> """
> + export PATH
> /tmp/arrow-0.14.0.yum2X/apache-arrow-0.14.0/test-miniconda/etc/profile.d/conda.sh:
> line 55: PS1: unbound variable
https://github.com/apache/arrow/pull/4773 will solve this.
I added "set -u" to detect using undefined variables caused
by typo in
https://github.com/apache/arrow/commit/9a788dfc976035cabb0d4ab15f0f6fa306a5428d
.
It works well on my environment. But I understand that it's
not portable with shell script that sources external shell
script. (. $MINICONDA/etc/profile.d/conda.sh)
I've removed "set -u" by
https://github.com/apache/arrow/commit/9145c1591aedbd141454cfc7b6aad5190c0fb30e
.
Thanks,
--
kou
In <03...@python.org>
"Re: [VOTE] Release Apache Arrow 0.14.0 - RC0" on Mon, 1 Jul 2019 10:48:18 +0200,
Antoine Pitrou <an...@python.org> wrote:
>
> On Ubuntu 18.04:
>
> - failed to verify binaries
>
> """
> + echo 'Failed to verify release candidate. See /tmp/arrow-0.14.0.gucvU
> for details.'
> Failed to verify release candidate. See /tmp/arrow-0.14.0.gucvU for details.
> """
>
> There's no details in /tmp/arrow-0.14.0.gucvU. The script left a lot of
> zombie curl processes running...
>
> - failed to verify sources
>
> """
> + export PATH
> /tmp/arrow-0.14.0.yum2X/apache-arrow-0.14.0/test-miniconda/etc/profile.d/conda.sh:
> line 55: PS1: unbound variable
> + ask_conda=
> + return 1
> + cleanup
> + '[' no = yes ']'
> + echo 'Failed to verify release candidate. See /tmp/arrow-0.14.0.yum2X
> for details.'
> Failed to verify release candidate. See /tmp/arrow-0.14.0.yum2X for details.
> """
>
> There's no details in /tmp/arrow-0.14.0.yum2X
>
> Regards
>
> Antoine.
>
>
>
>
>
> Le 01/07/2019 à 07:32, Sutou Kouhei a écrit :
>> Hi,
>>
>> I would like to propose the following release candidate (RC0) of Apache
>> Arrow version 0.14.0. This is a release consiting of 618
>> resolved JIRA issues[1].
>>
>> This release candidate is based on commit:
>> a591d76ad9a657110368aa422bb00f4010cb6b6e [2]
>>
>> The source release rc0 is hosted at [3].
>> The binary artifacts are hosted at [4][5][6][7].
>> The changelog is located at [8].
>>
>> Please download, verify checksums and signatures, run the unit tests,
>> and vote on the release. See [9] for how to validate a release candidate.
>>
>> NOTE: You must use verify-release-candidate.sh at master.
>> I've fixed some problems after apache-arrow-0.14.0 tag.
>> C#'s "sourcelink test" is fragile. (Network related problem?)
>> It may be better that we add retry logic to "sourcelink test".
>>
>> The vote will be open for at least 72 hours.
>>
>> [ ] +1 Release this as Apache Arrow 0.14.0
>> [ ] +0
>> [ ] -1 Do not release this as Apache Arrow 0.14.0 because...
>>
>> [1]: https://issues.apache.org/jira/issues/?jql=project%20%3D%20ARROW%20AND%20status%20in%20%28Resolved%2C%20Closed%29%20AND%20fixVersion%20%3D%200.14.0
>> [2]: https://github.com/apache/arrow/tree/a591d76ad9a657110368aa422bb00f4010cb6b6e
>> [3]: https://dist.apache.org/repos/dist/dev/arrow/apache-arrow-0.14.0-rc0
>> [4]: https://bintray.com/apache/arrow/centos-rc/0.14.0-rc0
>> [5]: https://bintray.com/apache/arrow/debian-rc/0.14.0-rc0
>> [6]: https://bintray.com/apache/arrow/python-rc/0.14.0-rc0
>> [7]: https://bintray.com/apache/arrow/ubuntu-rc/0.14.0-rc0
>> [8]: https://github.com/apache/arrow/blob/a591d76ad9a657110368aa422bb00f4010cb6b6e/CHANGELOG.md
>> [9]: https://cwiki.apache.org/confluence/display/ARROW/How+to+Verify+Release+Candidates
>>
>>
>> Thanks,
>> --
>> kou
>>
Re: [VOTE] Release Apache Arrow 0.14.0 - RC0
Posted by Wes McKinney <we...@gmail.com>.
The C++/Python source build looks fine to me on the Windows side -- I
added Flight support in
https://github.com/apache/arrow/pull/4770
I opened https://issues.apache.org/jira/browse/ARROW-5817 as there is
a risk that Flight Python tests might be silently skipped. We check in
our Python package builds that pyarrow.flight can be imported
successfully so I don't think those packages are at risk of having a
problem
On Mon, Jul 1, 2019 at 11:48 AM Wes McKinney <we...@gmail.com> wrote:
>
> hi Antoine, I'm not sure the origin of the conda.sh failure, have you
> tried removing any bashrc stuff related to the Anaconda distribution
> that you develop against?
>
> With the following patch I'm able to run the binary verification
>
> https://github.com/apache/arrow/pull/4768
>
> but it failed with
>
> https://gist.github.com/wesm/711ae3d66c942db293dba55ff237871a
>
> Indeed a sig is missing from bintray. I was able to get the parallel
> build to run on my machine (but it failed when I piped stdin/stdout to
> a file) but I also found a bad sig
>
> https://gist.github.com/wesm/2404d55e087cc3982d93e53c83df95d5
>
> I'm going to work on verifying more components. C# is failing with
>
> https://gist.github.com/wesm/985146df6944a1aade331c4bd1519f1f
>
> but I don't think that should block the release (it would be nice if
> it passed though)
>
> I'm going to work on the Windows verification script and see if I can
> add Flight support to it
>
> All in all appears that an RC1 may be warranted unless the signature
> issues can be remedied in RC0. Seems like we might need to find an
> artifact staging solution that is not Bintray if API rate limits are
> going to be a problem.
>
> - Wes
>
> On Mon, Jul 1, 2019 at 3:48 AM Antoine Pitrou <an...@python.org> wrote:
> >
> >
> > On Ubuntu 18.04:
> >
> > - failed to verify binaries
> >
> > """
> > + echo 'Failed to verify release candidate. See /tmp/arrow-0.14.0.gucvU
> > for details.'
> > Failed to verify release candidate. See /tmp/arrow-0.14.0.gucvU for details.
> > """
> >
> > There's no details in /tmp/arrow-0.14.0.gucvU. The script left a lot of
> > zombie curl processes running...
> >
> > - failed to verify sources
> >
> > """
> > + export PATH
> > /tmp/arrow-0.14.0.yum2X/apache-arrow-0.14.0/test-miniconda/etc/profile.d/conda.sh:
> > line 55: PS1: unbound variable
> > + ask_conda=
> > + return 1
> > + cleanup
> > + '[' no = yes ']'
> > + echo 'Failed to verify release candidate. See /tmp/arrow-0.14.0.yum2X
> > for details.'
> > Failed to verify release candidate. See /tmp/arrow-0.14.0.yum2X for details.
> > """
> >
> > There's no details in /tmp/arrow-0.14.0.yum2X
> >
> > Regards
> >
> > Antoine.
> >
> >
> >
> >
> >
> > Le 01/07/2019 à 07:32, Sutou Kouhei a écrit :
> > > Hi,
> > >
> > > I would like to propose the following release candidate (RC0) of Apache
> > > Arrow version 0.14.0. This is a release consiting of 618
> > > resolved JIRA issues[1].
> > >
> > > This release candidate is based on commit:
> > > a591d76ad9a657110368aa422bb00f4010cb6b6e [2]
> > >
> > > The source release rc0 is hosted at [3].
> > > The binary artifacts are hosted at [4][5][6][7].
> > > The changelog is located at [8].
> > >
> > > Please download, verify checksums and signatures, run the unit tests,
> > > and vote on the release. See [9] for how to validate a release candidate.
> > >
> > > NOTE: You must use verify-release-candidate.sh at master.
> > > I've fixed some problems after apache-arrow-0.14.0 tag.
> > > C#'s "sourcelink test" is fragile. (Network related problem?)
> > > It may be better that we add retry logic to "sourcelink test".
> > >
> > > The vote will be open for at least 72 hours.
> > >
> > > [ ] +1 Release this as Apache Arrow 0.14.0
> > > [ ] +0
> > > [ ] -1 Do not release this as Apache Arrow 0.14.0 because...
> > >
> > > [1]: https://issues.apache.org/jira/issues/?jql=project%20%3D%20ARROW%20AND%20status%20in%20%28Resolved%2C%20Closed%29%20AND%20fixVersion%20%3D%200.14.0
> > > [2]: https://github.com/apache/arrow/tree/a591d76ad9a657110368aa422bb00f4010cb6b6e
> > > [3]: https://dist.apache.org/repos/dist/dev/arrow/apache-arrow-0.14.0-rc0
> > > [4]: https://bintray.com/apache/arrow/centos-rc/0.14.0-rc0
> > > [5]: https://bintray.com/apache/arrow/debian-rc/0.14.0-rc0
> > > [6]: https://bintray.com/apache/arrow/python-rc/0.14.0-rc0
> > > [7]: https://bintray.com/apache/arrow/ubuntu-rc/0.14.0-rc0
> > > [8]: https://github.com/apache/arrow/blob/a591d76ad9a657110368aa422bb00f4010cb6b6e/CHANGELOG.md
> > > [9]: https://cwiki.apache.org/confluence/display/ARROW/How+to+Verify+Release+Candidates
> > >
> > >
> > > Thanks,
> > > --
> > > kou
> > >
Re: [VOTE] Release Apache Arrow 0.14.0 - RC0
Posted by Krisztián Szűcs <sz...@gmail.com>.
The issue report was hardly reproducible, and it wasn't captured by any
of the automatized test suites. Until we don't have automatized tests for
a feature I wouldn't consider it stable.
If this is something we should have blocked the release on, then we can
still draft a minor release after fixing it.
- Krisztian
On Thu, Jul 4, 2019 at 2:47 PM Jacques Nadeau <ja...@apache.org> wrote:
> Im disappointed in this response. When someone finds an issue with a
> release it should be triaged/validated rather than rushed past rather
> quickly and closing the vote before others can chime in on the issue.
>
> I'm now left voting -1 on a closed vote. In the future, let's have a
> discussion about issues like this. Your response and the close of the vote
> were unilateral and all happened while some of us were sleeping.
>
> On Wed, Jul 3, 2019, 10:47 PM Sutou Kouhei <ko...@clear-code.com> wrote:
>
> > Hi,
> >
> > Flight isn't stable yet. So Flight problem isn't a blocker
> > of this release. Could you open a JIRA issue for your
> > problem? We'll be able to fix it until 1.0.0.
> >
> >
> > Thanks,
> > --
> > kou
> >
> > In <CA...@mail.gmail.com>
> > "Re: [VOTE] Release Apache Arrow 0.14.0 - RC0" on Wed, 3 Jul 2019
> > 17:18:15 -0700,
> > Ryan Murray <ry...@dremio.com> wrote:
> >
> > > Hi All,
> > >
> > > I have noticed that a python Flight client can't authenticate to a Java
> > > Flight server while doing some testing today. I am trying to confirm if
> > > this is a bug in the flight implementation or in my own code. I
> thought I
> > > would report here as it could potentially be a blocker to this release.
> > >
> > > I will confirm and come back to you shortly.
> > >
> > > Best,
> > > Ryan
> > >
> > > On Wed, Jul 3, 2019 at 5:02 PM Sutou Kouhei <ko...@clear-code.com>
> wrote:
> > >
> > >> Thanks for confirming it!
> > >>
> > >> This will be solved by the pull request.
> > >>
> > >> In <
> CAF6oT1d5X-GLEdLHbAixi74+pXo5aP8EgGsYLWQUiMWPVxMsrg@mail.gmail.com>
> > >> "Re: [VOTE] Release Apache Arrow 0.14.0 - RC0" on Wed, 3 Jul 2019
> > >> 13:53:19 -0700,
> > >> Chao Sun <su...@apache.org> wrote:
> > >>
> > >> > Thanks Sutou. It is 2.5.0:
> > >> >
> > >> > $ protoc --version
> > >> > libprotoc 2.5.0
> > >> >
> > >> > Yes this is an old version, which is still used by Apache Hadoop.
> > >> >
> > >> > On Wed, Jul 3, 2019 at 1:27 PM Sutou Kouhei <ko...@clear-code.com>
> > wrote:
> > >> >
> > >> >> Thanks for verifying this RC!
> > >> >>
> > >> >> It seems that the C++ error is caused by old Protocol
> > >> >> Buffers. Could you show your system Protocol Buffers
> > >> >> version?
> > >> >>
> > >> >> https://github.com/apache/arrow/pull/4785 will resolve this
> > >> >> case. It prevents using old system Protocol Buffers.
> > >> >>
> > >> >> In <
> > CAF6oT1e8eMh1gWoOO+Uuq5z6AmwZPRfUuyV4C+w+crpievzLuw@mail.gmail.com>
> > >> >> "Re: [VOTE] Release Apache Arrow 0.14.0 - RC0" on Wed, 3 Jul 2019
> > >> >> 00:15:54 -0700,
> > >> >> Chao Sun <su...@apache.org> wrote:
> > >> >>
> > >> >> > On MacOS Mojave. Verified Rust and Go with
> > verify-release-candidate.sh
> > >> >> and
> > >> >> > they look good.
> > >> >> > I got the following error when verifying C++ though:
> > >> >> >
> > >> >> > [ 18%] Built target grpc_dependencies
> > >> >> > CMake Error at
> > >> >> >
> > >> >>
> > >>
> >
> /var/folders/z3/ptkgr4kn4pv9v8g7s1fnr5mm0000gn/T/arrow-0.14.0.XXXXX.yYmSAqR5/apache-arrow-0.14.0/cpp/build/orc_ep-prefix/src/orc_ep-stamp/orc_ep-build-RELEASE.cmake:49
> > >> >> > (message):
> > >> >> > Command failed: 2
> > >> >> > '/Library/Developer/CommandLineTools/usr/bin/make'
> > >> >> > See also
> > >> >> >
> > >> >> >
> > >> >>
> > >>
> >
> /var/folders/z3/ptkgr4kn4pv9v8g7s1fnr5mm0000gn/T/arrow-0.14.0.XXXXX.yYmSAqR5/apache-arrow-0.14.0/cpp/build/orc_ep-prefix/src/orc_ep-stamp/orc_ep-build-*.log
> > >> >> > make[2]: *** [orc_ep-prefix/src/orc_ep-stamp/orc_ep-build] Error
> 1
> > >> >> > make[1]: *** [CMakeFiles/orc_ep.dir/all] Error 2
> > >> >> >
> > >> >> > In orc_ep-build-err.log:
> > >> >> >
> > >> >> > In file included from
> > >> >> >
> > >> >>
> > >>
> >
> /var/folders/z3/ptkgr4kn4pv9v8g7s1fnr5mm0000gn/T/arrow-0.14.0.XXXXX.yYmSAqR5/apache-arrow-0.14.0/cpp/build/orc_ep-prefix/src/orc_ep/c++/src/io/OutputStream.cc:20:
> > >> >> >
> > >> >>
> > >>
> >
> ^[[1m/var/folders/z3/ptkgr4kn4pv9v8g7s1fnr5mm0000gn/T/arrow-0.14.0.XXXXX.yYmSAqR5/apache-arrow-0.14.0/cpp/build/orc_ep-prefix/src/orc_ep/c++/src/io/OutputStream.hh:59:18:
> > >> >> > ^[[0m^[[0;1;31merror: ^[[0m^[[1m'WriteAliasedRaw' marked
> > >> 'override'
> > >> >> > but does not override any member functions^[[0m
> > >> >> > virtual bool WriteAliasedRaw(const void * data, int size)
> > >> override;
> > >> >> > ^[[0;1;32m ^
> > >> >> >
> > >> >>
> > >>
> >
> ^[[0m^[[1m/var/folders/z3/ptkgr4kn4pv9v8g7s1fnr5mm0000gn/T/arrow-0.14.0.XXXXX.yYmSAqR5/apache-arrow-0.14.0/cpp/build/orc_ep-prefix/src/orc_ep/c++/src/io/OutputStream.hh:60:18:
> > >> >> > ^[[0m^[[0;1;31merror: ^[[0m^[[1m'AllowsAliasing' marked
> 'override'
> > >> but
> > >> >> > does not override any member functions^[[0m
> > >> >> > virtual bool AllowsAliasing() const override;
> > >> >> > ^[[0;1;32m ^
> > >> >> > ^[[0m2 errors generated.
> > >> >> > make[5]: *** [c++/src/CMakeFiles/orc.dir/io/OutputStream.cc.o]
> > Error 1
> > >> >> > make[4]: *** [c++/src/CMakeFiles/orc.dir/all] Error 2
> > >> >> > make[3]: *** [all] Error 2
> > >> >> >
> > >> >> > Not sure if this is due to my environment.
> > >> >> >
> > >> >> > Chao
> > >> >> >
> > >> >> > On Tue, Jul 2, 2019 at 6:54 PM Ravindra Pindikura <
> > >> ravindra@dremio.com>
> > >> >> > wrote:
> > >> >> >
> > >> >> >> ok, thanks !
> > >> >> >>
> > >> >> >> On Wed, Jul 3, 2019 at 7:10 AM Sutou Kouhei <kou@clear-code.com
> >
> > >> wrote:
> > >> >> >>
> > >> >> >> > Hi,
> > >> >> >> >
> > >> >> >> > Thanks for verifying this RC!
> > >> >> >> >
> > >> >> >> > > 2. The package doesn't seem to include gandiva
> > >> >> >> > >
> > >> >> >> > > is that intentional ? I'm fine if it is not included, just
> > want
> > >> to
> > >> >> >> > confirm
> > >> >> >> > > if that's expected.
> > >> >> >> >
> > >> >> >> > I think that this is caused by "-P arrow-jni" is missing in
> > >> >> >> > 01-perform.sh:
> > >> >> >> >
> > >> >> >> >
> > https://github.com/apache/arrow/pull/4717#issuecomment-506916189
> > >> >> >> >
> > >> >> >> > It's intentional for RC0.
> > >> >> >> >
> > >> >> >> > We'll fix this after RC0:
> > >> >> >> >
> > >> >> >> > https://issues.apache.org/jira/browse/ARROW-5786
> > >> >> >> >
> > >> >> >> >
> > >> >> >> > Thanks,
> > >> >> >> > --
> > >> >> >> > kou
> > >> >> >> >
> > >> >> >> > In <
> > >> >> CAPWBuG6wVuDwu7-Z8dYHq7SNuSAgAPpkdzkrQoF4DfnJ4Np5ag@mail.gmail.com
> >
> > >> >> >> > "Re: [VOTE] Release Apache Arrow 0.14.0 - RC0" on Wed, 3 Jul
> > 2019
> > >> >> >> > 06:55:52 +0530,
> > >> >> >> > Ravindra Pindikura <ra...@dremio.com> wrote:
> > >> >> >> >
> > >> >> >> > > I tried "./dev/release/verify-release-candidate.sh source
> > 0.14.0
> > >> 0"
> > >> >> on
> > >> >> >> > mac
> > >> >> >> > > mojave.
> > >> >> >> > >
> > >> >> >> > > 1. I consistently get this error with flight tests
> > >> >> >> > >
> > >> >> >> > > [ERROR] Tests run: 1, Failures: 0, Errors: 1, Skipped: 0,
> Time
> > >> >> elapsed:
> > >> >> >> > > 0.04 s <<< FAILURE! - in
> > >> org.apache.arrow.flight.TestServerOptions
> > >> >> >> > > [ERROR]
> > domainSocket(org.apache.arrow.flight.TestServerOptions)
> > >> >> Time
> > >> >> >> > > elapsed: 0.04 s <<< ERROR!
> > >> >> >> > > java.io.IOException: Failed to bind
> > >> >> >> > > at
> > >> >> >> > >
> > >> >> >> >
> > >> >> >>
> > >> >>
> > >>
> >
> org.apache.arrow.flight.TestServerOptions.domainSocket(TestServerOptions.java:46)
> > >> >> >> > > Caused by: io.netty.channel.unix.Errors$NativeIoException:
> > >> bind(..)
> > >> >> >> > failed:
> > >> >> >> > > Address already in use
> > >> >> >> > >
> > >> >> >> > > Is there a workaround or gotcha for this ?
> > >> >> >> > >
> > >> >> >> > > 2. The package doesn't seem to include gandiva
> > >> >> >> > >
> > >> >> >> > > is that intentional ? I'm fine if it is not included, just
> > want
> > >> to
> > >> >> >> > confirm
> > >> >> >> > > if that's expected.
> > >> >> >> > >
> > >> >> >> > > On Wed, Jul 3, 2019 at 6:37 AM Sutou Kouhei <
> > kou@clear-code.com>
> > >> >> >> wrote:
> > >> >> >> > >
> > >> >> >> > >> > I tried again (Ubuntu 18.04):
> > >> >> >> > >> > * source verification failed in gRPC configure step:
> > >> >> >> > >> > Problem is, Ubuntu's c-ares does not provide any CMake
> > files:
> > >> >> >> > >>
> > >> >> >> > >> Note: Adding -Dc-ares_SOURCE=BUNDLED CMake option is
> > >> >> >> > >> workaround. We can use bundled c-ares automatically by
> > >> >> >> > >> requiring c-ares's CMake config:
> > >> >> >> > >>
> > >> >> >> > >> https://github.com/apache/arrow/pull/4783
> > >> >> >> > >>
> > >> >> >> > >>
> > >> >> >> > >> Thanks,
> > >> >> >> > >> --
> > >> >> >> > >> kou
> > >> >> >> > >>
> > >> >> >> > >> In <7a...@python.org>
> > >> >> >> > >> "Re: [VOTE] Release Apache Arrow 0.14.0 - RC0" on Tue, 2
> > Jul
> > >> 2019
> > >> >> >> > >> 11:36:09 +0200,
> > >> >> >> > >> Antoine Pitrou <an...@python.org> wrote:
> > >> >> >> > >>
> > >> >> >> > >> >
> > >> >> >> > >> > I tried again (Ubuntu 18.04):
> > >> >> >> > >> >
> > >> >> >> > >> > * binaries verification succeeded
> > >> >> >> > >> >
> > >> >> >> > >> > * source verification failed in gRPC configure step:
> > >> >> >> > >> >
> > >> >> >> > >> > CMake Error at cmake/cares.cmake:38 (find_package):
> > >> >> >> > >> > Could not find a package configuration file provided by
> > >> >> "c-ares"
> > >> >> >> > with
> > >> >> >> > >> any
> > >> >> >> > >> > of the following names:
> > >> >> >> > >> >
> > >> >> >> > >> > c-aresConfig.cmake
> > >> >> >> > >> > c-ares-config.cmake
> > >> >> >> > >> >
> > >> >> >> > >> > Add the installation prefix of "c-ares" to
> > >> CMAKE_PREFIX_PATH or
> > >> >> >> set
> > >> >> >> > >> > "c-ares_DIR" to a directory containing one of the above
> > >> >> files. If
> > >> >> >> > >> "c-ares"
> > >> >> >> > >> > provides a separate development package or SDK, be sure
> > it
> > >> has
> > >> >> >> been
> > >> >> >> > >> > installed.
> > >> >> >> > >> > Call Stack (most recent call first):
> > >> >> >> > >> > CMakeLists.txt:139 (include)
> > >> >> >> > >> >
> > >> >> >> > >> >
> > >> >> >> > >> > Problem is, Ubuntu's c-ares does not provide any CMake
> > files:
> > >> >> >> > >> >
> > >> >> >> > >> > $ dpkg -L libc-ares-dev
> > >> >> >> > >> > /.
> > >> >> >> > >> > /usr
> > >> >> >> > >> > /usr/include
> > >> >> >> > >> > /usr/include/ares.h
> > >> >> >> > >> > /usr/include/ares_build.h
> > >> >> >> > >> > /usr/include/ares_dns.h
> > >> >> >> > >> > /usr/include/ares_rules.h
> > >> >> >> > >> > /usr/include/ares_version.h
> > >> >> >> > >> > /usr/lib
> > >> >> >> > >> > /usr/lib/x86_64-linux-gnu
> > >> >> >> > >> > /usr/lib/x86_64-linux-gnu/libcares.a
> > >> >> >> > >> > /usr/lib/x86_64-linux-gnu/pkgconfig
> > >> >> >> > >> > /usr/lib/x86_64-linux-gnu/pkgconfig/libcares.pc
> > >> >> >> > >> > /usr/share
> > >> >> >> > >> > /usr/share/doc
> > >> >> >> > >> > /usr/share/doc/libc-ares-dev
> > >> >> >> > >> > /usr/share/doc/libc-ares-dev/NEWS.gz
> > >> >> >> > >> > /usr/share/doc/libc-ares-dev/README.cares
> > >> >> >> > >> > /usr/share/doc/libc-ares-dev/README.md
> > >> >> >> > >> > /usr/share/doc/libc-ares-dev/copyright
> > >> >> >> > >> > /usr/share/man
> > >> >> >> > >> > /usr/share/man/man3
> > >> >> >> > >> > [ snip man pages ]
> > >> >> >> > >> > /usr/lib/x86_64-linux-gnu/libcares.so
> > >> >> >> > >> >
> > >> >> >> > >> >
> > >> >> >> > >> > Regards
> > >> >> >> > >> >
> > >> >> >> > >> > Antoine.
> > >> >> >> > >>
> > >> >> >> > >
> > >> >> >> > >
> > >> >> >> > > --
> > >> >> >> > > Thanks and regards,
> > >> >> >> > > Ravindra.
> > >> >> >> >
> > >> >> >>
> > >> >> >>
> > >> >> >> --
> > >> >> >> Thanks and regards,
> > >> >> >> Ravindra.
> > >> >> >>
> > >> >>
> > >>
> > >
> > >
> > > --
> > >
> > > Ryan Murray | Principal Consulting Engineer
> > >
> > > +447540852009 | rymurr@dremio.com
> > >
> > > <https://www.dremio.com/>
> > > Check out our GitHub <https://www.github.com/dremio>, join our
> community
> > > site <https://community.dremio.com/> & Download Dremio
> > > <https://www.dremio.com/download>
> >
>
Re: Release verification process
Posted by Wes McKinney <we...@gmail.com>.
hi Neal,
On Thu, Jul 4, 2019 at 9:31 AM Neal Richardson
<ne...@gmail.com> wrote:
>
> Hi all,
> [Splitting off from the [VOTE] discussion thread]
>
> I wonder if there are things we can do to make for a smoother release next
> time. This was the first release I participated in with the Arrow project,
> and there were some aspects that were surprising to me. It seemed odd that
> "release verification" involved manually running a bunch of tests that
> weren't expected to pass, and then reporting that they didn't pass, and
> then forging ahead anyway.
>
Verification means different things to different people. The purpose
of the verification script is to try to build as many components of
the project as possible in a standalone way, using system environment
and dependencies in some cases. It helps turn up issues that do not
appear in the controlled CI environment.
Others will verify the release by testing their third party
applications using the software as a dependency.
> Perhaps we could, at the beginning of the release process and before making
> the first RC, make clear what is expected in order to verify it, and also
> state what is not required or expected. And we shouldn't spend time running
> tests that we don't care whether they fail or not. That way, we can have
> the discussion of what a successful release looks like before there's an RC
> on the table and a sense of urgency to ship it, and then it will be clear
> to everyone that the standards have been met when we run the tests.
>
I understand where you're coming from, but the release verification
process is intended to collect idiosyncratic information from people
attempting to use the software in different ways. I doubt that we
could write down satisfactory standards a priori or a cookie cutter
verification process that can be guaranteed to work for everyone. It's
been suggested in the past to convert the release verification to a
Dockerfile, but my view is that defeats the purpose of the script.
Note that our CI and Docker integration tests already provide a
certain level of security -- so we would hope to not have an RC unless
CI and docker-* tests are all passing (which they were here).
> Regardless of how we might want to improve the process for next time, I
> appreciate all of the hard work that Kou (especially) and others put in to
> making the release happen. Releasing a project of this size clearly takes a
> lot of dedication and effort.
>
> Neal
>
>
> On Thu, Jul 4, 2019 at 7:05 AM Wes McKinney <we...@gmail.com> wrote:
>
> > hi Jacques,
> >
> > I agree that we should allow ample time for discussions around issues
> > raised by people validating the release.
> >
> > That being said, with Ryan's issue, he is using a feature
> > (cross-language auth in Flight) that isn't being tested. The Flight
> > integration tests do not use authentication AFAIK so I'm not surprised
> > to hear that there may be an issue with it. It would be as if there
> > were a cross-compatibility issues between Python and Rust. Again,
> > would not surprise me because Rust is not included in the integration
> > tests. Even with a reproduction of such an issue I don't think it
> > should block the release in the future.
> >
> > I'd be glad to help make a point release in the near future since we
> > uncovered quite a few small issues during this RC, and I think there's
> > more value in getting the software into the hands of users than
> > waiting multiple weeks to address them all.
> >
> > - Wes
> >
> >
> > On Thu, Jul 4, 2019 at 8:50 AM Jacques Nadeau <ja...@apache.org> wrote:
> > >
> > > A release vote should last until we arrive at consensus. When an issue is
> > > potentially identified, those that have voted should be given ample time
> > to
> > > change their vote and others that may have been lazy consenters should be
> > > given time to chime in. There is no maximum amount of time a vote can be
> > > open. Allowing at least 24 hours after an objection is raised is a pretty
> > > minimum expectation unless the objector removes their objection.
> > >
> > > Note that Apache is more focused on consensus than timing (as opposed to
> > > virtually other other organizations in the world).
> > >
> > > In this case I was waiting to see more information from the objector
> > before
> > > casting my vote. I see a -1 vote as community chilling and prefer for
> > > consensus to be reached through discussions rather than contrary voting.
> > >
> > >
> > >
> > > On Thu, Jul 4, 2019, 6:35 AM Antoine Pitrou <an...@python.org> wrote:
> > >
> > > >
> > > > That's an open question. How long should a release vote last?
> > > > Apparently this one lasted 3 days. The 0.14.0 vote (after RC4) lasted
> > 3
> > > > days before a decision was made too.
> > > >
> > > > Regards
> > > >
> > > > Antoine.
> > > >
> > > >
> > > > Le 04/07/2019 à 15:28, Jacques Nadeau a écrit :
> > > > > There are two different questions here.
> > > > >
> > > > > 1) should this issue block the release.
> > > > > 2) should a discussion with ample time for all parties to come to
> > > > consensus
> > > > > have occurred before closing the vote.
> > > > >
> > > > > The first question is a subjective question. The answer to the second
> > > > > question should have been an unequivocal yes.
> > > > >
> > > > > I'll send a separate mail on point one but the problem I see here
> > > > > fundamentally is point two.
> > > > >
> > > > > On Thu, Jul 4, 2019, 6:01 AM Antoine Pitrou <an...@python.org>
> > wrote:
> > > > >
> > > > >>
> > > > >> I agree with Kou here. It's not a problem with the release per se,
> > it's
> > > > >> a problem with the Flight code in git master. There is no
> > regression
> > > > >> AFAICT, and we have not promised that Flight was stable and
> > > > >> production-ready yet.
> > > > >>
> > > > >> If we're ok releasing with bugs such as this (Java unable to read
> > back
> > > > >> union arrays?), then I think a Flight bug shouldn't hold a release.
> > > > >> https://issues.apache.org/jira/browse/ARROW-5231
> > > > >>
> > > > >> Regards
> > > > >>
> > > > >> Antoine.
> > > > >>
> > > > >>
> > > > >> Le 04/07/2019 à 14:46, Jacques Nadeau a écrit :
> > > > >>> Im disappointed in this response. When someone finds an issue with
> > a
> > > > >>> release it should be triaged/validated rather than rushed past
> > rather
> > > > >>> quickly and closing the vote before others can chime in on the
> > issue.
> > > > >>>
> > > > >>> I'm now left voting -1 on a closed vote. In the future, let's have
> > a
> > > > >>> discussion about issues like this. Your response and the close of
> > the
> > > > >> vote
> > > > >>> were unilateral and all happened while some of us were sleeping.
> > > > >>>
> > > > >>> On Wed, Jul 3, 2019, 10:47 PM Sutou Kouhei <ko...@clear-code.com>
> > wrote:
> > > > >>>
> > > > >>>> Hi,
> > > > >>>>
> > > > >>>> Flight isn't stable yet. So Flight problem isn't a blocker
> > > > >>>> of this release. Could you open a JIRA issue for your
> > > > >>>> problem? We'll be able to fix it until 1.0.0.
> > > > >>>>
> > > > >>>>
> > > > >>>> Thanks,
> > > > >>>> --
> > > > >>>> kou
> > > > >>>>
> > > > >>>> In <
> > > > CAKg4KDx8_Rr8xQOBaspW+U0LYPX21tPcWx6S4_RDdMk4VpDwcg@mail.gmail.com>
> > > > >>>> "Re: [VOTE] Release Apache Arrow 0.14.0 - RC0" on Wed, 3 Jul
> > 2019
> > > > >>>> 17:18:15 -0700,
> > > > >>>> Ryan Murray <ry...@dremio.com> wrote:
> > > > >>>>
> > > > >>>>> Hi All,
> > > > >>>>>
> > > > >>>>> I have noticed that a python Flight client can't authenticate to
> > a
> > > > Java
> > > > >>>>> Flight server while doing some testing today. I am trying to
> > confirm
> > > > if
> > > > >>>>> this is a bug in the flight implementation or in my own code. I
> > > > >> thought I
> > > > >>>>> would report here as it could potentially be a blocker to this
> > > > release.
> > > > >>>>>
> > > > >>>>> I will confirm and come back to you shortly.
> > > > >>>>>
> > > > >>>>> Best,
> > > > >>>>> Ryan
> > > > >>>>>
> >
Release verification process
Posted by Neal Richardson <ne...@gmail.com>.
Hi all,
[Splitting off from the [VOTE] discussion thread]
I wonder if there are things we can do to make for a smoother release next
time. This was the first release I participated in with the Arrow project,
and there were some aspects that were surprising to me. It seemed odd that
"release verification" involved manually running a bunch of tests that
weren't expected to pass, and then reporting that they didn't pass, and
then forging ahead anyway.
Perhaps we could, at the beginning of the release process and before making
the first RC, make clear what is expected in order to verify it, and also
state what is not required or expected. And we shouldn't spend time running
tests that we don't care whether they fail or not. That way, we can have
the discussion of what a successful release looks like before there's an RC
on the table and a sense of urgency to ship it, and then it will be clear
to everyone that the standards have been met when we run the tests.
Regardless of how we might want to improve the process for next time, I
appreciate all of the hard work that Kou (especially) and others put in to
making the release happen. Releasing a project of this size clearly takes a
lot of dedication and effort.
Neal
On Thu, Jul 4, 2019 at 7:05 AM Wes McKinney <we...@gmail.com> wrote:
> hi Jacques,
>
> I agree that we should allow ample time for discussions around issues
> raised by people validating the release.
>
> That being said, with Ryan's issue, he is using a feature
> (cross-language auth in Flight) that isn't being tested. The Flight
> integration tests do not use authentication AFAIK so I'm not surprised
> to hear that there may be an issue with it. It would be as if there
> were a cross-compatibility issues between Python and Rust. Again,
> would not surprise me because Rust is not included in the integration
> tests. Even with a reproduction of such an issue I don't think it
> should block the release in the future.
>
> I'd be glad to help make a point release in the near future since we
> uncovered quite a few small issues during this RC, and I think there's
> more value in getting the software into the hands of users than
> waiting multiple weeks to address them all.
>
> - Wes
>
>
> On Thu, Jul 4, 2019 at 8:50 AM Jacques Nadeau <ja...@apache.org> wrote:
> >
> > A release vote should last until we arrive at consensus. When an issue is
> > potentially identified, those that have voted should be given ample time
> to
> > change their vote and others that may have been lazy consenters should be
> > given time to chime in. There is no maximum amount of time a vote can be
> > open. Allowing at least 24 hours after an objection is raised is a pretty
> > minimum expectation unless the objector removes their objection.
> >
> > Note that Apache is more focused on consensus than timing (as opposed to
> > virtually other other organizations in the world).
> >
> > In this case I was waiting to see more information from the objector
> before
> > casting my vote. I see a -1 vote as community chilling and prefer for
> > consensus to be reached through discussions rather than contrary voting.
> >
> >
> >
> > On Thu, Jul 4, 2019, 6:35 AM Antoine Pitrou <an...@python.org> wrote:
> >
> > >
> > > That's an open question. How long should a release vote last?
> > > Apparently this one lasted 3 days. The 0.14.0 vote (after RC4) lasted
> 3
> > > days before a decision was made too.
> > >
> > > Regards
> > >
> > > Antoine.
> > >
> > >
> > > Le 04/07/2019 à 15:28, Jacques Nadeau a écrit :
> > > > There are two different questions here.
> > > >
> > > > 1) should this issue block the release.
> > > > 2) should a discussion with ample time for all parties to come to
> > > consensus
> > > > have occurred before closing the vote.
> > > >
> > > > The first question is a subjective question. The answer to the second
> > > > question should have been an unequivocal yes.
> > > >
> > > > I'll send a separate mail on point one but the problem I see here
> > > > fundamentally is point two.
> > > >
> > > > On Thu, Jul 4, 2019, 6:01 AM Antoine Pitrou <an...@python.org>
> wrote:
> > > >
> > > >>
> > > >> I agree with Kou here. It's not a problem with the release per se,
> it's
> > > >> a problem with the Flight code in git master. There is no
> regression
> > > >> AFAICT, and we have not promised that Flight was stable and
> > > >> production-ready yet.
> > > >>
> > > >> If we're ok releasing with bugs such as this (Java unable to read
> back
> > > >> union arrays?), then I think a Flight bug shouldn't hold a release.
> > > >> https://issues.apache.org/jira/browse/ARROW-5231
> > > >>
> > > >> Regards
> > > >>
> > > >> Antoine.
> > > >>
> > > >>
> > > >> Le 04/07/2019 à 14:46, Jacques Nadeau a écrit :
> > > >>> Im disappointed in this response. When someone finds an issue with
> a
> > > >>> release it should be triaged/validated rather than rushed past
> rather
> > > >>> quickly and closing the vote before others can chime in on the
> issue.
> > > >>>
> > > >>> I'm now left voting -1 on a closed vote. In the future, let's have
> a
> > > >>> discussion about issues like this. Your response and the close of
> the
> > > >> vote
> > > >>> were unilateral and all happened while some of us were sleeping.
> > > >>>
> > > >>> On Wed, Jul 3, 2019, 10:47 PM Sutou Kouhei <ko...@clear-code.com>
> wrote:
> > > >>>
> > > >>>> Hi,
> > > >>>>
> > > >>>> Flight isn't stable yet. So Flight problem isn't a blocker
> > > >>>> of this release. Could you open a JIRA issue for your
> > > >>>> problem? We'll be able to fix it until 1.0.0.
> > > >>>>
> > > >>>>
> > > >>>> Thanks,
> > > >>>> --
> > > >>>> kou
> > > >>>>
> > > >>>> In <
> > > CAKg4KDx8_Rr8xQOBaspW+U0LYPX21tPcWx6S4_RDdMk4VpDwcg@mail.gmail.com>
> > > >>>> "Re: [VOTE] Release Apache Arrow 0.14.0 - RC0" on Wed, 3 Jul
> 2019
> > > >>>> 17:18:15 -0700,
> > > >>>> Ryan Murray <ry...@dremio.com> wrote:
> > > >>>>
> > > >>>>> Hi All,
> > > >>>>>
> > > >>>>> I have noticed that a python Flight client can't authenticate to
> a
> > > Java
> > > >>>>> Flight server while doing some testing today. I am trying to
> confirm
> > > if
> > > >>>>> this is a bug in the flight implementation or in my own code. I
> > > >> thought I
> > > >>>>> would report here as it could potentially be a blocker to this
> > > release.
> > > >>>>>
> > > >>>>> I will confirm and come back to you shortly.
> > > >>>>>
> > > >>>>> Best,
> > > >>>>> Ryan
> > > >>>>>
>
Re: [VOTE] Release Apache Arrow 0.14.0 - RC0
Posted by Wes McKinney <we...@gmail.com>.
On Thu, Jul 4, 2019 at 9:25 AM Jacques Nadeau <ja...@apache.org> wrote:
>
> On Thu, Jul 4, 2019, 7:05 AM Wes McKinney <we...@gmail.com> wrote:
>
> > hi Jacques,
> >
> > I agree that we should allow ample time for discussions around issues
> > raised by people validating the release.
> >
>
> That is the main point here. There should have been a discussion about
> this. Different people are expecting different things out of Arrow and all
> perspectives should be considered.
>
>
> > That being said, with Ryan's issue, he is using a feature
> > (cross-language auth in Flight) that isn't being tested. The Flight
> > integration tests do not use authentication AFAIK so I'm not surprised
> > to hear that there may be an issue with it. It would be as if there
> > were a cross-compatibility issues between Python and Rust. Again,
> > would not surprise me because Rust is not included in the integration
> > tests. Even with a reproduction of such an issue I don't think it
> > should block the release in the future.
> >
>
> By definition, issues we find during the release are things we didn't know
> about before the release and either have no test or tests that failed to
> run. Having to be a regression or existing failing tests is too low a bar.
> If we figured out that there was major incompatibility between Rust and
> Python that would also warrant serious discussion even if there is a lack
> of integration tests. The discussion is where we figure these things out,
> not in a set of easily defined rules.
>
I agree that we expect at least a 24 hour window for further
discussion when issues come up. I hope this episode will serve as a
learning opportunity for the community -- we are all working toward
the same goals of progress and innovation. There are a huge number of
hungry mouths to feed with this project; I've been having tons of
people contacting me offline about timeline for this release also.
Personally, I think the principle solution here is to release more
often and to only block releases in the event of critical brokenness
(like an entire language library being fundamentally unusable). Having
2-3 months between major releases is creating too much pressure on
both the developer and user community. If releases were reliably
coming out once a month it would be better for everyone.
>
>
> > I'd be glad to help make a point release in the near future since we
> > uncovered quite a few small issues during this RC, and I think there's
> > more value in getting the software into the hands of users than
> > waiting multiple weeks to address them all.
> >
>
> Appreciated and needed. I've talked to 20+ companies in the last several
> weeks anxiously awaiting use of this Fight release. If this problem exists
> (still want to see reproduction), this makes the flight release unusable
> for the use case they wanted to leverage it for.
>
Great. I think we need to have someone new be the next RM. For the
record, here is the record of mainline release managers so far:
Julien: 0.1.0
Uwe: 0.2.0, 0.12.1
Wes: 0.3.0, 0.4.0, 0.4.1, 0.5.0, 0.6.0, 0.7.0, 0.7.1, 0.8.0, 0.9.0, 0.11.1
Phillip C: 0.10.0
Kou: 0.11.0, 0.13.0, 0.14.0
Krisztian: 0.12.0
(I was also the RM for 5 JavaScript releases)
> >
> >
> > On Thu, Jul 4, 2019 at 8:50 AM Jacques Nadeau <ja...@apache.org> wrote:
> > >
> > > A release vote should last until we arrive at consensus. When an issue is
> > > potentially identified, those that have voted should be given ample time
> > to
> > > change their vote and others that may have been lazy consenters should be
> > > given time to chime in. There is no maximum amount of time a vote can be
> > > open. Allowing at least 24 hours after an objection is raised is a pretty
> > > minimum expectation unless the objector removes their objection.
> > >
> > > Note that Apache is more focused on consensus than timing (as opposed to
> > > virtually other other organizations in the world).
> > >
> > > In this case I was waiting to see more information from the objector
> > before
> > > casting my vote. I see a -1 vote as community chilling and prefer for
> > > consensus to be reached through discussions rather than contrary voting.
> > >
> > >
> > >
> > > On Thu, Jul 4, 2019, 6:35 AM Antoine Pitrou <an...@python.org> wrote:
> > >
> > > >
> > > > That's an open question. How long should a release vote last?
> > > > Apparently this one lasted 3 days. The 0.14.0 vote (after RC4) lasted
> > 3
> > > > days before a decision was made too.
> > > >
> > > > Regards
> > > >
> > > > Antoine.
> > > >
> > > >
> > > > Le 04/07/2019 à 15:28, Jacques Nadeau a écrit :
> > > > > There are two different questions here.
> > > > >
> > > > > 1) should this issue block the release.
> > > > > 2) should a discussion with ample time for all parties to come to
> > > > consensus
> > > > > have occurred before closing the vote.
> > > > >
> > > > > The first question is a subjective question. The answer to the second
> > > > > question should have been an unequivocal yes.
> > > > >
> > > > > I'll send a separate mail on point one but the problem I see here
> > > > > fundamentally is point two.
> > > > >
> > > > > On Thu, Jul 4, 2019, 6:01 AM Antoine Pitrou <an...@python.org>
> > wrote:
> > > > >
> > > > >>
> > > > >> I agree with Kou here. It's not a problem with the release per se,
> > it's
> > > > >> a problem with the Flight code in git master. There is no
> > regression
> > > > >> AFAICT, and we have not promised that Flight was stable and
> > > > >> production-ready yet.
> > > > >>
> > > > >> If we're ok releasing with bugs such as this (Java unable to read
> > back
> > > > >> union arrays?), then I think a Flight bug shouldn't hold a release.
> > > > >> https://issues.apache.org/jira/browse/ARROW-5231
> > > > >>
> > > > >> Regards
> > > > >>
> > > > >> Antoine.
> > > > >>
> > > > >>
> > > > >> Le 04/07/2019 à 14:46, Jacques Nadeau a écrit :
> > > > >>> Im disappointed in this response. When someone finds an issue with
> > a
> > > > >>> release it should be triaged/validated rather than rushed past
> > rather
> > > > >>> quickly and closing the vote before others can chime in on the
> > issue.
> > > > >>>
> > > > >>> I'm now left voting -1 on a closed vote. In the future, let's have
> > a
> > > > >>> discussion about issues like this. Your response and the close of
> > the
> > > > >> vote
> > > > >>> were unilateral and all happened while some of us were sleeping.
> > > > >>>
> > > > >>> On Wed, Jul 3, 2019, 10:47 PM Sutou Kouhei <ko...@clear-code.com>
> > wrote:
> > > > >>>
> > > > >>>> Hi,
> > > > >>>>
> > > > >>>> Flight isn't stable yet. So Flight problem isn't a blocker
> > > > >>>> of this release. Could you open a JIRA issue for your
> > > > >>>> problem? We'll be able to fix it until 1.0.0.
> > > > >>>>
> > > > >>>>
> > > > >>>> Thanks,
> > > > >>>> --
> > > > >>>> kou
> > > > >>>>
> > > > >>>> In <
> > > > CAKg4KDx8_Rr8xQOBaspW+U0LYPX21tPcWx6S4_RDdMk4VpDwcg@mail.gmail.com>
> > > > >>>> "Re: [VOTE] Release Apache Arrow 0.14.0 - RC0" on Wed, 3 Jul
> > 2019
> > > > >>>> 17:18:15 -0700,
> > > > >>>> Ryan Murray <ry...@dremio.com> wrote:
> > > > >>>>
> > > > >>>>> Hi All,
> > > > >>>>>
> > > > >>>>> I have noticed that a python Flight client can't authenticate to
> > a
> > > > Java
> > > > >>>>> Flight server while doing some testing today. I am trying to
> > confirm
> > > > if
> > > > >>>>> this is a bug in the flight implementation or in my own code. I
> > > > >> thought I
> > > > >>>>> would report here as it could potentially be a blocker to this
> > > > release.
> > > > >>>>>
> > > > >>>>> I will confirm and come back to you shortly.
> > > > >>>>>
> > > > >>>>> Best,
> > > > >>>>> Ryan
> > > > >>>>>
> > > > >>>>> On Wed, Jul 3, 2019 at 5:02 PM Sutou Kouhei <ko...@clear-code.com>
> > > > >> wrote:
> > > > >>>>>
> > > > >>>>>> Thanks for confirming it!
> > > > >>>>>>
> > > > >>>>>> This will be solved by the pull request.
> > > > >>>>>>
> > > > >>>>>> In <
> > > > >> CAF6oT1d5X-GLEdLHbAixi74+pXo5aP8EgGsYLWQUiMWPVxMsrg@mail.gmail.com>
> > > > >>>>>> "Re: [VOTE] Release Apache Arrow 0.14.0 - RC0" on Wed, 3 Jul
> > 2019
> > > > >>>>>> 13:53:19 -0700,
> > > > >>>>>> Chao Sun <su...@apache.org> wrote:
> > > > >>>>>>
> > > > >>>>>>> Thanks Sutou. It is 2.5.0:
> > > > >>>>>>>
> > > > >>>>>>> $ protoc --version
> > > > >>>>>>> libprotoc 2.5.0
> > > > >>>>>>>
> > > > >>>>>>> Yes this is an old version, which is still used by Apache
> > Hadoop.
> > > > >>>>>>>
> > > > >>>>>>> On Wed, Jul 3, 2019 at 1:27 PM Sutou Kouhei <
> > kou@clear-code.com>
> > > > >>>> wrote:
> > > > >>>>>>>
> > > > >>>>>>>> Thanks for verifying this RC!
> > > > >>>>>>>>
> > > > >>>>>>>> It seems that the C++ error is caused by old Protocol
> > > > >>>>>>>> Buffers. Could you show your system Protocol Buffers
> > > > >>>>>>>> version?
> > > > >>>>>>>>
> > > > >>>>>>>> https://github.com/apache/arrow/pull/4785 will resolve this
> > > > >>>>>>>> case. It prevents using old system Protocol Buffers.
> > > > >>>>>>>>
> > > > >>>>>>>> In <
> > > > >>>>
> > CAF6oT1e8eMh1gWoOO+Uuq5z6AmwZPRfUuyV4C+w+crpievzLuw@mail.gmail.com>
> > > > >>>>>>>> "Re: [VOTE] Release Apache Arrow 0.14.0 - RC0" on Wed, 3 Jul
> > > > 2019
> > > > >>>>>>>> 00:15:54 -0700,
> > > > >>>>>>>> Chao Sun <su...@apache.org> wrote:
> > > > >>>>>>>>
> > > > >>>>>>>>> On MacOS Mojave. Verified Rust and Go with
> > > > >>>> verify-release-candidate.sh
> > > > >>>>>>>> and
> > > > >>>>>>>>> they look good.
> > > > >>>>>>>>> I got the following error when verifying C++ though:
> > > > >>>>>>>>>
> > > > >>>>>>>>> [ 18%] Built target grpc_dependencies
> > > > >>>>>>>>> CMake Error at
> > > > >>>>>>>>>
> > > > >>>>>>>>
> > > > >>>>>>
> > > > >>>>
> > > > >>
> > > >
> > /var/folders/z3/ptkgr4kn4pv9v8g7s1fnr5mm0000gn/T/arrow-0.14.0.XXXXX.yYmSAqR5/apache-arrow-0.14.0/cpp/build/orc_ep-prefix/src/orc_ep-stamp/orc_ep-build-RELEASE.cmake:49
> > > > >>>>>>>>> (message):
> > > > >>>>>>>>> Command failed: 2
> > > > >>>>>>>>> '/Library/Developer/CommandLineTools/usr/bin/make'
> > > > >>>>>>>>> See also
> > > > >>>>>>>>>
> > > > >>>>>>>>>
> > > > >>>>>>>>
> > > > >>>>>>
> > > > >>>>
> > > > >>
> > > >
> > /var/folders/z3/ptkgr4kn4pv9v8g7s1fnr5mm0000gn/T/arrow-0.14.0.XXXXX.yYmSAqR5/apache-arrow-0.14.0/cpp/build/orc_ep-prefix/src/orc_ep-stamp/orc_ep-build-*.log
> > > > >>>>>>>>> make[2]: *** [orc_ep-prefix/src/orc_ep-stamp/orc_ep-build]
> > Error
> > > > 1
> > > > >>>>>>>>> make[1]: *** [CMakeFiles/orc_ep.dir/all] Error 2
> > > > >>>>>>>>>
> > > > >>>>>>>>> In orc_ep-build-err.log:
> > > > >>>>>>>>>
> > > > >>>>>>>>> In file included from
> > > > >>>>>>>>>
> > > > >>>>>>>>
> > > > >>>>>>
> > > > >>>>
> > > > >>
> > > >
> > /var/folders/z3/ptkgr4kn4pv9v8g7s1fnr5mm0000gn/T/arrow-0.14.0.XXXXX.yYmSAqR5/apache-arrow-0.14.0/cpp/build/orc_ep-prefix/src/orc_ep/c++/src/io/OutputStream.cc:20:
> > > > >>>>>>>>>
> > > > >>>>>>>>
> > > > >>>>>>
> > > > >>>>
> > > > >>
> > > >
> > ^[[1m/var/folders/z3/ptkgr4kn4pv9v8g7s1fnr5mm0000gn/T/arrow-0.14.0.XXXXX.yYmSAqR5/apache-arrow-0.14.0/cpp/build/orc_ep-prefix/src/orc_ep/c++/src/io/OutputStream.hh:59:18:
> > > > >>>>>>>>> ^[[0m^[[0;1;31merror: ^[[0m^[[1m'WriteAliasedRaw' marked
> > > > >>>>>> 'override'
> > > > >>>>>>>>> but does not override any member functions^[[0m
> > > > >>>>>>>>> virtual bool WriteAliasedRaw(const void * data, int size)
> > > > >>>>>> override;
> > > > >>>>>>>>> ^[[0;1;32m ^
> > > > >>>>>>>>>
> > > > >>>>>>>>
> > > > >>>>>>
> > > > >>>>
> > > > >>
> > > >
> > ^[[0m^[[1m/var/folders/z3/ptkgr4kn4pv9v8g7s1fnr5mm0000gn/T/arrow-0.14.0.XXXXX.yYmSAqR5/apache-arrow-0.14.0/cpp/build/orc_ep-prefix/src/orc_ep/c++/src/io/OutputStream.hh:60:18:
> > > > >>>>>>>>> ^[[0m^[[0;1;31merror: ^[[0m^[[1m'AllowsAliasing' marked
> > > > 'override'
> > > > >>>>>> but
> > > > >>>>>>>>> does not override any member functions^[[0m
> > > > >>>>>>>>> virtual bool AllowsAliasing() const override;
> > > > >>>>>>>>> ^[[0;1;32m ^
> > > > >>>>>>>>> ^[[0m2 errors generated.
> > > > >>>>>>>>> make[5]: ***
> > [c++/src/CMakeFiles/orc.dir/io/OutputStream.cc.o]
> > > > >>>> Error 1
> > > > >>>>>>>>> make[4]: *** [c++/src/CMakeFiles/orc.dir/all] Error 2
> > > > >>>>>>>>> make[3]: *** [all] Error 2
> > > > >>>>>>>>>
> > > > >>>>>>>>> Not sure if this is due to my environment.
> > > > >>>>>>>>>
> > > > >>>>>>>>> Chao
> > > > >>>>>>>>>
> > > > >>>>>>>>> On Tue, Jul 2, 2019 at 6:54 PM Ravindra Pindikura <
> > > > >>>>>> ravindra@dremio.com>
> > > > >>>>>>>>> wrote:
> > > > >>>>>>>>>
> > > > >>>>>>>>>> ok, thanks !
> > > > >>>>>>>>>>
> > > > >>>>>>>>>> On Wed, Jul 3, 2019 at 7:10 AM Sutou Kouhei <
> > kou@clear-code.com
> > > > >
> > > > >>>>>> wrote:
> > > > >>>>>>>>>>
> > > > >>>>>>>>>>> Hi,
> > > > >>>>>>>>>>>
> > > > >>>>>>>>>>> Thanks for verifying this RC!
> > > > >>>>>>>>>>>
> > > > >>>>>>>>>>>> 2. The package doesn't seem to include gandiva
> > > > >>>>>>>>>>>>
> > > > >>>>>>>>>>>> is that intentional ? I'm fine if it is not included, just
> > > > >>>> want
> > > > >>>>>> to
> > > > >>>>>>>>>>> confirm
> > > > >>>>>>>>>>>> if that's expected.
> > > > >>>>>>>>>>>
> > > > >>>>>>>>>>> I think that this is caused by "-P arrow-jni" is missing in
> > > > >>>>>>>>>>> 01-perform.sh:
> > > > >>>>>>>>>>>
> > > > >>>>>>>>>>>
> > > > >>>> https://github.com/apache/arrow/pull/4717#issuecomment-506916189
> > > > >>>>>>>>>>>
> > > > >>>>>>>>>>> It's intentional for RC0.
> > > > >>>>>>>>>>>
> > > > >>>>>>>>>>> We'll fix this after RC0:
> > > > >>>>>>>>>>>
> > > > >>>>>>>>>>> https://issues.apache.org/jira/browse/ARROW-5786
> > > > >>>>>>>>>>>
> > > > >>>>>>>>>>>
> > > > >>>>>>>>>>> Thanks,
> > > > >>>>>>>>>>> --
> > > > >>>>>>>>>>> kou
> > > > >>>>>>>>>>>
> > > > >>>>>>>>>>> In <
> > > > >>>>>>>>
> > > > CAPWBuG6wVuDwu7-Z8dYHq7SNuSAgAPpkdzkrQoF4DfnJ4Np5ag@mail.gmail.com>
> > > > >>>>>>>>>>> "Re: [VOTE] Release Apache Arrow 0.14.0 - RC0" on Wed, 3
> > Jul
> > > > >>>> 2019
> > > > >>>>>>>>>>> 06:55:52 +0530,
> > > > >>>>>>>>>>> Ravindra Pindikura <ra...@dremio.com> wrote:
> > > > >>>>>>>>>>>
> > > > >>>>>>>>>>>> I tried "./dev/release/verify-release-candidate.sh source
> > > > >>>> 0.14.0
> > > > >>>>>> 0"
> > > > >>>>>>>> on
> > > > >>>>>>>>>>> mac
> > > > >>>>>>>>>>>> mojave.
> > > > >>>>>>>>>>>>
> > > > >>>>>>>>>>>> 1. I consistently get this error with flight tests
> > > > >>>>>>>>>>>>
> > > > >>>>>>>>>>>> [ERROR] Tests run: 1, Failures: 0, Errors: 1, Skipped: 0,
> > Time
> > > > >>>>>>>> elapsed:
> > > > >>>>>>>>>>>> 0.04 s <<< FAILURE! - in
> > > > >>>>>> org.apache.arrow.flight.TestServerOptions
> > > > >>>>>>>>>>>> [ERROR]
> > > > >>>> domainSocket(org.apache.arrow.flight.TestServerOptions)
> > > > >>>>>>>> Time
> > > > >>>>>>>>>>>> elapsed: 0.04 s <<< ERROR!
> > > > >>>>>>>>>>>> java.io.IOException: Failed to bind
> > > > >>>>>>>>>>>> at
> > > > >>>>>>>>>>>>
> > > > >>>>>>>>>>>
> > > > >>>>>>>>>>
> > > > >>>>>>>>
> > > > >>>>>>
> > > > >>>>
> > > > >>
> > > >
> > org.apache.arrow.flight.TestServerOptions.domainSocket(TestServerOptions.java:46)
> > > > >>>>>>>>>>>> Caused by: io.netty.channel.unix.Errors$NativeIoException:
> > > > >>>>>> bind(..)
> > > > >>>>>>>>>>> failed:
> > > > >>>>>>>>>>>> Address already in use
> > > > >>>>>>>>>>>>
> > > > >>>>>>>>>>>> Is there a workaround or gotcha for this ?
> > > > >>>>>>>>>>>>
> > > > >>>>>>>>>>>> 2. The package doesn't seem to include gandiva
> > > > >>>>>>>>>>>>
> > > > >>>>>>>>>>>> is that intentional ? I'm fine if it is not included, just
> > > > >>>> want
> > > > >>>>>> to
> > > > >>>>>>>>>>> confirm
> > > > >>>>>>>>>>>> if that's expected.
> > > > >>>>>>>>>>>>
> > > > >>>>>>>>>>>> On Wed, Jul 3, 2019 at 6:37 AM Sutou Kouhei <
> > > > >>>> kou@clear-code.com>
> > > > >>>>>>>>>> wrote:
> > > > >>>>>>>>>>>>
> > > > >>>>>>>>>>>>>> I tried again (Ubuntu 18.04):
> > > > >>>>>>>>>>>>>> * source verification failed in gRPC configure step:
> > > > >>>>>>>>>>>>>> Problem is, Ubuntu's c-ares does not provide any CMake
> > > > >>>> files:
> > > > >>>>>>>>>>>>>
> > > > >>>>>>>>>>>>> Note: Adding -Dc-ares_SOURCE=BUNDLED CMake option is
> > > > >>>>>>>>>>>>> workaround. We can use bundled c-ares automatically by
> > > > >>>>>>>>>>>>> requiring c-ares's CMake config:
> > > > >>>>>>>>>>>>>
> > > > >>>>>>>>>>>>> https://github.com/apache/arrow/pull/4783
> > > > >>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>
> > > > >>>>>>>>>>>>> Thanks,
> > > > >>>>>>>>>>>>> --
> > > > >>>>>>>>>>>>> kou
> > > > >>>>>>>>>>>>>
> > > > >>>>>>>>>>>>> In <7a...@python.org>
> > > > >>>>>>>>>>>>> "Re: [VOTE] Release Apache Arrow 0.14.0 - RC0" on Tue,
> > 2
> > > > >>>> Jul
> > > > >>>>>> 2019
> > > > >>>>>>>>>>>>> 11:36:09 +0200,
> > > > >>>>>>>>>>>>> Antoine Pitrou <an...@python.org> wrote:
> > > > >>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>> I tried again (Ubuntu 18.04):
> > > > >>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>> * binaries verification succeeded
> > > > >>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>> * source verification failed in gRPC configure step:
> > > > >>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>> CMake Error at cmake/cares.cmake:38 (find_package):
> > > > >>>>>>>>>>>>>> Could not find a package configuration file provided
> > by
> > > > >>>>>>>> "c-ares"
> > > > >>>>>>>>>>> with
> > > > >>>>>>>>>>>>> any
> > > > >>>>>>>>>>>>>> of the following names:
> > > > >>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>> c-aresConfig.cmake
> > > > >>>>>>>>>>>>>> c-ares-config.cmake
> > > > >>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>> Add the installation prefix of "c-ares" to
> > > > >>>>>> CMAKE_PREFIX_PATH or
> > > > >>>>>>>>>> set
> > > > >>>>>>>>>>>>>> "c-ares_DIR" to a directory containing one of the
> > above
> > > > >>>>>>>> files. If
> > > > >>>>>>>>>>>>> "c-ares"
> > > > >>>>>>>>>>>>>> provides a separate development package or SDK, be
> > sure
> > > > >>>> it
> > > > >>>>>> has
> > > > >>>>>>>>>> been
> > > > >>>>>>>>>>>>>> installed.
> > > > >>>>>>>>>>>>>> Call Stack (most recent call first):
> > > > >>>>>>>>>>>>>> CMakeLists.txt:139 (include)
> > > > >>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>> Problem is, Ubuntu's c-ares does not provide any CMake
> > > > >>>> files:
> > > > >>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>> $ dpkg -L libc-ares-dev
> > > > >>>>>>>>>>>>>> /.
> > > > >>>>>>>>>>>>>> /usr
> > > > >>>>>>>>>>>>>> /usr/include
> > > > >>>>>>>>>>>>>> /usr/include/ares.h
> > > > >>>>>>>>>>>>>> /usr/include/ares_build.h
> > > > >>>>>>>>>>>>>> /usr/include/ares_dns.h
> > > > >>>>>>>>>>>>>> /usr/include/ares_rules.h
> > > > >>>>>>>>>>>>>> /usr/include/ares_version.h
> > > > >>>>>>>>>>>>>> /usr/lib
> > > > >>>>>>>>>>>>>> /usr/lib/x86_64-linux-gnu
> > > > >>>>>>>>>>>>>> /usr/lib/x86_64-linux-gnu/libcares.a
> > > > >>>>>>>>>>>>>> /usr/lib/x86_64-linux-gnu/pkgconfig
> > > > >>>>>>>>>>>>>> /usr/lib/x86_64-linux-gnu/pkgconfig/libcares.pc
> > > > >>>>>>>>>>>>>> /usr/share
> > > > >>>>>>>>>>>>>> /usr/share/doc
> > > > >>>>>>>>>>>>>> /usr/share/doc/libc-ares-dev
> > > > >>>>>>>>>>>>>> /usr/share/doc/libc-ares-dev/NEWS.gz
> > > > >>>>>>>>>>>>>> /usr/share/doc/libc-ares-dev/README.cares
> > > > >>>>>>>>>>>>>> /usr/share/doc/libc-ares-dev/README.md
> > > > >>>>>>>>>>>>>> /usr/share/doc/libc-ares-dev/copyright
> > > > >>>>>>>>>>>>>> /usr/share/man
> > > > >>>>>>>>>>>>>> /usr/share/man/man3
> > > > >>>>>>>>>>>>>> [ snip man pages ]
> > > > >>>>>>>>>>>>>> /usr/lib/x86_64-linux-gnu/libcares.so
> > > > >>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>> Regards
> > > > >>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>> Antoine.
> > > > >>>>>>>>>>>>>
> > > > >>>>>>>>>>>>
> > > > >>>>>>>>>>>>
> > > > >>>>>>>>>>>> --
> > > > >>>>>>>>>>>> Thanks and regards,
> > > > >>>>>>>>>>>> Ravindra.
> > > > >>>>>>>>>>>
> > > > >>>>>>>>>>
> > > > >>>>>>>>>>
> > > > >>>>>>>>>> --
> > > > >>>>>>>>>> Thanks and regards,
> > > > >>>>>>>>>> Ravindra.
> > > > >>>>>>>>>>
> > > > >>>>>>>>
> > > > >>>>>>
> > > > >>>>>
> > > > >>>>>
> > > > >>>>> --
> > > > >>>>>
> > > > >>>>> Ryan Murray | Principal Consulting Engineer
> > > > >>>>>
> > > > >>>>> +447540852009 | rymurr@dremio.com
> > > > >>>>>
> > > > >>>>> <https://www.dremio.com/>
> > > > >>>>> Check out our GitHub <https://www.github.com/dremio>, join our
> > > > >> community
> > > > >>>>> site <https://community.dremio.com/> & Download Dremio
> > > > >>>>> <https://www.dremio.com/download>
> > > > >>>>
> > > > >>>
> > > > >>
> > > > >
> > > >
> >
Re: Release standards
Posted by Jacques Nadeau <ja...@apache.org>.
You don't hold the release for the issue, you hold it for consensus. This
allows other people to come to the same conclusion (or not). That's why
it's called community over code.
On Thu, Jul 4, 2019, 7:33 AM Antoine Pitrou <so...@pitrou.net> wrote:
> On Thu, 4 Jul 2019 07:25:05 -0700
> Jacques Nadeau <ja...@apache.org> wrote:
> >
> > > I'd be glad to help make a point release in the near future since we
> > > uncovered quite a few small issues during this RC, and I think there's
> > > more value in getting the software into the hands of users than
> > > waiting multiple weeks to address them all.
> > >
> >
> > Appreciated and needed. I've talked to 20+ companies in the last several
> > weeks anxiously awaiting use of this Fight release. If this problem
> exists
> > (still want to see reproduction), this makes the flight release unusable
> > for the use case they wanted to leverage it for.
>
> Well... The fact that the problem isn't reproduced or confirmed as a
> Arrow bug (rather than a bug in application code, which is IMHO more
> likely given the way Flight authentication works) makes it a bit
> difficult to hold the release for it.
>
> Regards
>
> Antoine.
>
>
>
Re: Release standards
Posted by Antoine Pitrou <so...@pitrou.net>.
On Thu, 4 Jul 2019 07:25:05 -0700
Jacques Nadeau <ja...@apache.org> wrote:
>
> > I'd be glad to help make a point release in the near future since we
> > uncovered quite a few small issues during this RC, and I think there's
> > more value in getting the software into the hands of users than
> > waiting multiple weeks to address them all.
> >
>
> Appreciated and needed. I've talked to 20+ companies in the last several
> weeks anxiously awaiting use of this Fight release. If this problem exists
> (still want to see reproduction), this makes the flight release unusable
> for the use case they wanted to leverage it for.
Well... The fact that the problem isn't reproduced or confirmed as a
Arrow bug (rather than a bug in application code, which is IMHO more
likely given the way Flight authentication works) makes it a bit
difficult to hold the release for it.
Regards
Antoine.
Re: [VOTE] Release Apache Arrow 0.14.0 - RC0
Posted by Jacques Nadeau <ja...@apache.org>.
On Thu, Jul 4, 2019, 7:05 AM Wes McKinney <we...@gmail.com> wrote:
> hi Jacques,
>
> I agree that we should allow ample time for discussions around issues
> raised by people validating the release.
>
That is the main point here. There should have been a discussion about
this. Different people are expecting different things out of Arrow and all
perspectives should be considered.
> That being said, with Ryan's issue, he is using a feature
> (cross-language auth in Flight) that isn't being tested. The Flight
> integration tests do not use authentication AFAIK so I'm not surprised
> to hear that there may be an issue with it. It would be as if there
> were a cross-compatibility issues between Python and Rust. Again,
> would not surprise me because Rust is not included in the integration
> tests. Even with a reproduction of such an issue I don't think it
> should block the release in the future.
>
By definition, issues we find during the release are things we didn't know
about before the release and either have no test or tests that failed to
run. Having to be a regression or existing failing tests is too low a bar.
If we figured out that there was major incompatibility between Rust and
Python that would also warrant serious discussion even if there is a lack
of integration tests. The discussion is where we figure these things out,
not in a set of easily defined rules.
> I'd be glad to help make a point release in the near future since we
> uncovered quite a few small issues during this RC, and I think there's
> more value in getting the software into the hands of users than
> waiting multiple weeks to address them all.
>
Appreciated and needed. I've talked to 20+ companies in the last several
weeks anxiously awaiting use of this Fight release. If this problem exists
(still want to see reproduction), this makes the flight release unusable
for the use case they wanted to leverage it for.
>
>
> On Thu, Jul 4, 2019 at 8:50 AM Jacques Nadeau <ja...@apache.org> wrote:
> >
> > A release vote should last until we arrive at consensus. When an issue is
> > potentially identified, those that have voted should be given ample time
> to
> > change their vote and others that may have been lazy consenters should be
> > given time to chime in. There is no maximum amount of time a vote can be
> > open. Allowing at least 24 hours after an objection is raised is a pretty
> > minimum expectation unless the objector removes their objection.
> >
> > Note that Apache is more focused on consensus than timing (as opposed to
> > virtually other other organizations in the world).
> >
> > In this case I was waiting to see more information from the objector
> before
> > casting my vote. I see a -1 vote as community chilling and prefer for
> > consensus to be reached through discussions rather than contrary voting.
> >
> >
> >
> > On Thu, Jul 4, 2019, 6:35 AM Antoine Pitrou <an...@python.org> wrote:
> >
> > >
> > > That's an open question. How long should a release vote last?
> > > Apparently this one lasted 3 days. The 0.14.0 vote (after RC4) lasted
> 3
> > > days before a decision was made too.
> > >
> > > Regards
> > >
> > > Antoine.
> > >
> > >
> > > Le 04/07/2019 à 15:28, Jacques Nadeau a écrit :
> > > > There are two different questions here.
> > > >
> > > > 1) should this issue block the release.
> > > > 2) should a discussion with ample time for all parties to come to
> > > consensus
> > > > have occurred before closing the vote.
> > > >
> > > > The first question is a subjective question. The answer to the second
> > > > question should have been an unequivocal yes.
> > > >
> > > > I'll send a separate mail on point one but the problem I see here
> > > > fundamentally is point two.
> > > >
> > > > On Thu, Jul 4, 2019, 6:01 AM Antoine Pitrou <an...@python.org>
> wrote:
> > > >
> > > >>
> > > >> I agree with Kou here. It's not a problem with the release per se,
> it's
> > > >> a problem with the Flight code in git master. There is no
> regression
> > > >> AFAICT, and we have not promised that Flight was stable and
> > > >> production-ready yet.
> > > >>
> > > >> If we're ok releasing with bugs such as this (Java unable to read
> back
> > > >> union arrays?), then I think a Flight bug shouldn't hold a release.
> > > >> https://issues.apache.org/jira/browse/ARROW-5231
> > > >>
> > > >> Regards
> > > >>
> > > >> Antoine.
> > > >>
> > > >>
> > > >> Le 04/07/2019 à 14:46, Jacques Nadeau a écrit :
> > > >>> Im disappointed in this response. When someone finds an issue with
> a
> > > >>> release it should be triaged/validated rather than rushed past
> rather
> > > >>> quickly and closing the vote before others can chime in on the
> issue.
> > > >>>
> > > >>> I'm now left voting -1 on a closed vote. In the future, let's have
> a
> > > >>> discussion about issues like this. Your response and the close of
> the
> > > >> vote
> > > >>> were unilateral and all happened while some of us were sleeping.
> > > >>>
> > > >>> On Wed, Jul 3, 2019, 10:47 PM Sutou Kouhei <ko...@clear-code.com>
> wrote:
> > > >>>
> > > >>>> Hi,
> > > >>>>
> > > >>>> Flight isn't stable yet. So Flight problem isn't a blocker
> > > >>>> of this release. Could you open a JIRA issue for your
> > > >>>> problem? We'll be able to fix it until 1.0.0.
> > > >>>>
> > > >>>>
> > > >>>> Thanks,
> > > >>>> --
> > > >>>> kou
> > > >>>>
> > > >>>> In <
> > > CAKg4KDx8_Rr8xQOBaspW+U0LYPX21tPcWx6S4_RDdMk4VpDwcg@mail.gmail.com>
> > > >>>> "Re: [VOTE] Release Apache Arrow 0.14.0 - RC0" on Wed, 3 Jul
> 2019
> > > >>>> 17:18:15 -0700,
> > > >>>> Ryan Murray <ry...@dremio.com> wrote:
> > > >>>>
> > > >>>>> Hi All,
> > > >>>>>
> > > >>>>> I have noticed that a python Flight client can't authenticate to
> a
> > > Java
> > > >>>>> Flight server while doing some testing today. I am trying to
> confirm
> > > if
> > > >>>>> this is a bug in the flight implementation or in my own code. I
> > > >> thought I
> > > >>>>> would report here as it could potentially be a blocker to this
> > > release.
> > > >>>>>
> > > >>>>> I will confirm and come back to you shortly.
> > > >>>>>
> > > >>>>> Best,
> > > >>>>> Ryan
> > > >>>>>
> > > >>>>> On Wed, Jul 3, 2019 at 5:02 PM Sutou Kouhei <ko...@clear-code.com>
> > > >> wrote:
> > > >>>>>
> > > >>>>>> Thanks for confirming it!
> > > >>>>>>
> > > >>>>>> This will be solved by the pull request.
> > > >>>>>>
> > > >>>>>> In <
> > > >> CAF6oT1d5X-GLEdLHbAixi74+pXo5aP8EgGsYLWQUiMWPVxMsrg@mail.gmail.com>
> > > >>>>>> "Re: [VOTE] Release Apache Arrow 0.14.0 - RC0" on Wed, 3 Jul
> 2019
> > > >>>>>> 13:53:19 -0700,
> > > >>>>>> Chao Sun <su...@apache.org> wrote:
> > > >>>>>>
> > > >>>>>>> Thanks Sutou. It is 2.5.0:
> > > >>>>>>>
> > > >>>>>>> $ protoc --version
> > > >>>>>>> libprotoc 2.5.0
> > > >>>>>>>
> > > >>>>>>> Yes this is an old version, which is still used by Apache
> Hadoop.
> > > >>>>>>>
> > > >>>>>>> On Wed, Jul 3, 2019 at 1:27 PM Sutou Kouhei <
> kou@clear-code.com>
> > > >>>> wrote:
> > > >>>>>>>
> > > >>>>>>>> Thanks for verifying this RC!
> > > >>>>>>>>
> > > >>>>>>>> It seems that the C++ error is caused by old Protocol
> > > >>>>>>>> Buffers. Could you show your system Protocol Buffers
> > > >>>>>>>> version?
> > > >>>>>>>>
> > > >>>>>>>> https://github.com/apache/arrow/pull/4785 will resolve this
> > > >>>>>>>> case. It prevents using old system Protocol Buffers.
> > > >>>>>>>>
> > > >>>>>>>> In <
> > > >>>>
> CAF6oT1e8eMh1gWoOO+Uuq5z6AmwZPRfUuyV4C+w+crpievzLuw@mail.gmail.com>
> > > >>>>>>>> "Re: [VOTE] Release Apache Arrow 0.14.0 - RC0" on Wed, 3 Jul
> > > 2019
> > > >>>>>>>> 00:15:54 -0700,
> > > >>>>>>>> Chao Sun <su...@apache.org> wrote:
> > > >>>>>>>>
> > > >>>>>>>>> On MacOS Mojave. Verified Rust and Go with
> > > >>>> verify-release-candidate.sh
> > > >>>>>>>> and
> > > >>>>>>>>> they look good.
> > > >>>>>>>>> I got the following error when verifying C++ though:
> > > >>>>>>>>>
> > > >>>>>>>>> [ 18%] Built target grpc_dependencies
> > > >>>>>>>>> CMake Error at
> > > >>>>>>>>>
> > > >>>>>>>>
> > > >>>>>>
> > > >>>>
> > > >>
> > >
> /var/folders/z3/ptkgr4kn4pv9v8g7s1fnr5mm0000gn/T/arrow-0.14.0.XXXXX.yYmSAqR5/apache-arrow-0.14.0/cpp/build/orc_ep-prefix/src/orc_ep-stamp/orc_ep-build-RELEASE.cmake:49
> > > >>>>>>>>> (message):
> > > >>>>>>>>> Command failed: 2
> > > >>>>>>>>> '/Library/Developer/CommandLineTools/usr/bin/make'
> > > >>>>>>>>> See also
> > > >>>>>>>>>
> > > >>>>>>>>>
> > > >>>>>>>>
> > > >>>>>>
> > > >>>>
> > > >>
> > >
> /var/folders/z3/ptkgr4kn4pv9v8g7s1fnr5mm0000gn/T/arrow-0.14.0.XXXXX.yYmSAqR5/apache-arrow-0.14.0/cpp/build/orc_ep-prefix/src/orc_ep-stamp/orc_ep-build-*.log
> > > >>>>>>>>> make[2]: *** [orc_ep-prefix/src/orc_ep-stamp/orc_ep-build]
> Error
> > > 1
> > > >>>>>>>>> make[1]: *** [CMakeFiles/orc_ep.dir/all] Error 2
> > > >>>>>>>>>
> > > >>>>>>>>> In orc_ep-build-err.log:
> > > >>>>>>>>>
> > > >>>>>>>>> In file included from
> > > >>>>>>>>>
> > > >>>>>>>>
> > > >>>>>>
> > > >>>>
> > > >>
> > >
> /var/folders/z3/ptkgr4kn4pv9v8g7s1fnr5mm0000gn/T/arrow-0.14.0.XXXXX.yYmSAqR5/apache-arrow-0.14.0/cpp/build/orc_ep-prefix/src/orc_ep/c++/src/io/OutputStream.cc:20:
> > > >>>>>>>>>
> > > >>>>>>>>
> > > >>>>>>
> > > >>>>
> > > >>
> > >
> ^[[1m/var/folders/z3/ptkgr4kn4pv9v8g7s1fnr5mm0000gn/T/arrow-0.14.0.XXXXX.yYmSAqR5/apache-arrow-0.14.0/cpp/build/orc_ep-prefix/src/orc_ep/c++/src/io/OutputStream.hh:59:18:
> > > >>>>>>>>> ^[[0m^[[0;1;31merror: ^[[0m^[[1m'WriteAliasedRaw' marked
> > > >>>>>> 'override'
> > > >>>>>>>>> but does not override any member functions^[[0m
> > > >>>>>>>>> virtual bool WriteAliasedRaw(const void * data, int size)
> > > >>>>>> override;
> > > >>>>>>>>> ^[[0;1;32m ^
> > > >>>>>>>>>
> > > >>>>>>>>
> > > >>>>>>
> > > >>>>
> > > >>
> > >
> ^[[0m^[[1m/var/folders/z3/ptkgr4kn4pv9v8g7s1fnr5mm0000gn/T/arrow-0.14.0.XXXXX.yYmSAqR5/apache-arrow-0.14.0/cpp/build/orc_ep-prefix/src/orc_ep/c++/src/io/OutputStream.hh:60:18:
> > > >>>>>>>>> ^[[0m^[[0;1;31merror: ^[[0m^[[1m'AllowsAliasing' marked
> > > 'override'
> > > >>>>>> but
> > > >>>>>>>>> does not override any member functions^[[0m
> > > >>>>>>>>> virtual bool AllowsAliasing() const override;
> > > >>>>>>>>> ^[[0;1;32m ^
> > > >>>>>>>>> ^[[0m2 errors generated.
> > > >>>>>>>>> make[5]: ***
> [c++/src/CMakeFiles/orc.dir/io/OutputStream.cc.o]
> > > >>>> Error 1
> > > >>>>>>>>> make[4]: *** [c++/src/CMakeFiles/orc.dir/all] Error 2
> > > >>>>>>>>> make[3]: *** [all] Error 2
> > > >>>>>>>>>
> > > >>>>>>>>> Not sure if this is due to my environment.
> > > >>>>>>>>>
> > > >>>>>>>>> Chao
> > > >>>>>>>>>
> > > >>>>>>>>> On Tue, Jul 2, 2019 at 6:54 PM Ravindra Pindikura <
> > > >>>>>> ravindra@dremio.com>
> > > >>>>>>>>> wrote:
> > > >>>>>>>>>
> > > >>>>>>>>>> ok, thanks !
> > > >>>>>>>>>>
> > > >>>>>>>>>> On Wed, Jul 3, 2019 at 7:10 AM Sutou Kouhei <
> kou@clear-code.com
> > > >
> > > >>>>>> wrote:
> > > >>>>>>>>>>
> > > >>>>>>>>>>> Hi,
> > > >>>>>>>>>>>
> > > >>>>>>>>>>> Thanks for verifying this RC!
> > > >>>>>>>>>>>
> > > >>>>>>>>>>>> 2. The package doesn't seem to include gandiva
> > > >>>>>>>>>>>>
> > > >>>>>>>>>>>> is that intentional ? I'm fine if it is not included, just
> > > >>>> want
> > > >>>>>> to
> > > >>>>>>>>>>> confirm
> > > >>>>>>>>>>>> if that's expected.
> > > >>>>>>>>>>>
> > > >>>>>>>>>>> I think that this is caused by "-P arrow-jni" is missing in
> > > >>>>>>>>>>> 01-perform.sh:
> > > >>>>>>>>>>>
> > > >>>>>>>>>>>
> > > >>>> https://github.com/apache/arrow/pull/4717#issuecomment-506916189
> > > >>>>>>>>>>>
> > > >>>>>>>>>>> It's intentional for RC0.
> > > >>>>>>>>>>>
> > > >>>>>>>>>>> We'll fix this after RC0:
> > > >>>>>>>>>>>
> > > >>>>>>>>>>> https://issues.apache.org/jira/browse/ARROW-5786
> > > >>>>>>>>>>>
> > > >>>>>>>>>>>
> > > >>>>>>>>>>> Thanks,
> > > >>>>>>>>>>> --
> > > >>>>>>>>>>> kou
> > > >>>>>>>>>>>
> > > >>>>>>>>>>> In <
> > > >>>>>>>>
> > > CAPWBuG6wVuDwu7-Z8dYHq7SNuSAgAPpkdzkrQoF4DfnJ4Np5ag@mail.gmail.com>
> > > >>>>>>>>>>> "Re: [VOTE] Release Apache Arrow 0.14.0 - RC0" on Wed, 3
> Jul
> > > >>>> 2019
> > > >>>>>>>>>>> 06:55:52 +0530,
> > > >>>>>>>>>>> Ravindra Pindikura <ra...@dremio.com> wrote:
> > > >>>>>>>>>>>
> > > >>>>>>>>>>>> I tried "./dev/release/verify-release-candidate.sh source
> > > >>>> 0.14.0
> > > >>>>>> 0"
> > > >>>>>>>> on
> > > >>>>>>>>>>> mac
> > > >>>>>>>>>>>> mojave.
> > > >>>>>>>>>>>>
> > > >>>>>>>>>>>> 1. I consistently get this error with flight tests
> > > >>>>>>>>>>>>
> > > >>>>>>>>>>>> [ERROR] Tests run: 1, Failures: 0, Errors: 1, Skipped: 0,
> Time
> > > >>>>>>>> elapsed:
> > > >>>>>>>>>>>> 0.04 s <<< FAILURE! - in
> > > >>>>>> org.apache.arrow.flight.TestServerOptions
> > > >>>>>>>>>>>> [ERROR]
> > > >>>> domainSocket(org.apache.arrow.flight.TestServerOptions)
> > > >>>>>>>> Time
> > > >>>>>>>>>>>> elapsed: 0.04 s <<< ERROR!
> > > >>>>>>>>>>>> java.io.IOException: Failed to bind
> > > >>>>>>>>>>>> at
> > > >>>>>>>>>>>>
> > > >>>>>>>>>>>
> > > >>>>>>>>>>
> > > >>>>>>>>
> > > >>>>>>
> > > >>>>
> > > >>
> > >
> org.apache.arrow.flight.TestServerOptions.domainSocket(TestServerOptions.java:46)
> > > >>>>>>>>>>>> Caused by: io.netty.channel.unix.Errors$NativeIoException:
> > > >>>>>> bind(..)
> > > >>>>>>>>>>> failed:
> > > >>>>>>>>>>>> Address already in use
> > > >>>>>>>>>>>>
> > > >>>>>>>>>>>> Is there a workaround or gotcha for this ?
> > > >>>>>>>>>>>>
> > > >>>>>>>>>>>> 2. The package doesn't seem to include gandiva
> > > >>>>>>>>>>>>
> > > >>>>>>>>>>>> is that intentional ? I'm fine if it is not included, just
> > > >>>> want
> > > >>>>>> to
> > > >>>>>>>>>>> confirm
> > > >>>>>>>>>>>> if that's expected.
> > > >>>>>>>>>>>>
> > > >>>>>>>>>>>> On Wed, Jul 3, 2019 at 6:37 AM Sutou Kouhei <
> > > >>>> kou@clear-code.com>
> > > >>>>>>>>>> wrote:
> > > >>>>>>>>>>>>
> > > >>>>>>>>>>>>>> I tried again (Ubuntu 18.04):
> > > >>>>>>>>>>>>>> * source verification failed in gRPC configure step:
> > > >>>>>>>>>>>>>> Problem is, Ubuntu's c-ares does not provide any CMake
> > > >>>> files:
> > > >>>>>>>>>>>>>
> > > >>>>>>>>>>>>> Note: Adding -Dc-ares_SOURCE=BUNDLED CMake option is
> > > >>>>>>>>>>>>> workaround. We can use bundled c-ares automatically by
> > > >>>>>>>>>>>>> requiring c-ares's CMake config:
> > > >>>>>>>>>>>>>
> > > >>>>>>>>>>>>> https://github.com/apache/arrow/pull/4783
> > > >>>>>>>>>>>>>
> > > >>>>>>>>>>>>>
> > > >>>>>>>>>>>>> Thanks,
> > > >>>>>>>>>>>>> --
> > > >>>>>>>>>>>>> kou
> > > >>>>>>>>>>>>>
> > > >>>>>>>>>>>>> In <7a...@python.org>
> > > >>>>>>>>>>>>> "Re: [VOTE] Release Apache Arrow 0.14.0 - RC0" on Tue,
> 2
> > > >>>> Jul
> > > >>>>>> 2019
> > > >>>>>>>>>>>>> 11:36:09 +0200,
> > > >>>>>>>>>>>>> Antoine Pitrou <an...@python.org> wrote:
> > > >>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>> I tried again (Ubuntu 18.04):
> > > >>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>> * binaries verification succeeded
> > > >>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>> * source verification failed in gRPC configure step:
> > > >>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>> CMake Error at cmake/cares.cmake:38 (find_package):
> > > >>>>>>>>>>>>>> Could not find a package configuration file provided
> by
> > > >>>>>>>> "c-ares"
> > > >>>>>>>>>>> with
> > > >>>>>>>>>>>>> any
> > > >>>>>>>>>>>>>> of the following names:
> > > >>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>> c-aresConfig.cmake
> > > >>>>>>>>>>>>>> c-ares-config.cmake
> > > >>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>> Add the installation prefix of "c-ares" to
> > > >>>>>> CMAKE_PREFIX_PATH or
> > > >>>>>>>>>> set
> > > >>>>>>>>>>>>>> "c-ares_DIR" to a directory containing one of the
> above
> > > >>>>>>>> files. If
> > > >>>>>>>>>>>>> "c-ares"
> > > >>>>>>>>>>>>>> provides a separate development package or SDK, be
> sure
> > > >>>> it
> > > >>>>>> has
> > > >>>>>>>>>> been
> > > >>>>>>>>>>>>>> installed.
> > > >>>>>>>>>>>>>> Call Stack (most recent call first):
> > > >>>>>>>>>>>>>> CMakeLists.txt:139 (include)
> > > >>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>> Problem is, Ubuntu's c-ares does not provide any CMake
> > > >>>> files:
> > > >>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>> $ dpkg -L libc-ares-dev
> > > >>>>>>>>>>>>>> /.
> > > >>>>>>>>>>>>>> /usr
> > > >>>>>>>>>>>>>> /usr/include
> > > >>>>>>>>>>>>>> /usr/include/ares.h
> > > >>>>>>>>>>>>>> /usr/include/ares_build.h
> > > >>>>>>>>>>>>>> /usr/include/ares_dns.h
> > > >>>>>>>>>>>>>> /usr/include/ares_rules.h
> > > >>>>>>>>>>>>>> /usr/include/ares_version.h
> > > >>>>>>>>>>>>>> /usr/lib
> > > >>>>>>>>>>>>>> /usr/lib/x86_64-linux-gnu
> > > >>>>>>>>>>>>>> /usr/lib/x86_64-linux-gnu/libcares.a
> > > >>>>>>>>>>>>>> /usr/lib/x86_64-linux-gnu/pkgconfig
> > > >>>>>>>>>>>>>> /usr/lib/x86_64-linux-gnu/pkgconfig/libcares.pc
> > > >>>>>>>>>>>>>> /usr/share
> > > >>>>>>>>>>>>>> /usr/share/doc
> > > >>>>>>>>>>>>>> /usr/share/doc/libc-ares-dev
> > > >>>>>>>>>>>>>> /usr/share/doc/libc-ares-dev/NEWS.gz
> > > >>>>>>>>>>>>>> /usr/share/doc/libc-ares-dev/README.cares
> > > >>>>>>>>>>>>>> /usr/share/doc/libc-ares-dev/README.md
> > > >>>>>>>>>>>>>> /usr/share/doc/libc-ares-dev/copyright
> > > >>>>>>>>>>>>>> /usr/share/man
> > > >>>>>>>>>>>>>> /usr/share/man/man3
> > > >>>>>>>>>>>>>> [ snip man pages ]
> > > >>>>>>>>>>>>>> /usr/lib/x86_64-linux-gnu/libcares.so
> > > >>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>> Regards
> > > >>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>> Antoine.
> > > >>>>>>>>>>>>>
> > > >>>>>>>>>>>>
> > > >>>>>>>>>>>>
> > > >>>>>>>>>>>> --
> > > >>>>>>>>>>>> Thanks and regards,
> > > >>>>>>>>>>>> Ravindra.
> > > >>>>>>>>>>>
> > > >>>>>>>>>>
> > > >>>>>>>>>>
> > > >>>>>>>>>> --
> > > >>>>>>>>>> Thanks and regards,
> > > >>>>>>>>>> Ravindra.
> > > >>>>>>>>>>
> > > >>>>>>>>
> > > >>>>>>
> > > >>>>>
> > > >>>>>
> > > >>>>> --
> > > >>>>>
> > > >>>>> Ryan Murray | Principal Consulting Engineer
> > > >>>>>
> > > >>>>> +447540852009 | rymurr@dremio.com
> > > >>>>>
> > > >>>>> <https://www.dremio.com/>
> > > >>>>> Check out our GitHub <https://www.github.com/dremio>, join our
> > > >> community
> > > >>>>> site <https://community.dremio.com/> & Download Dremio
> > > >>>>> <https://www.dremio.com/download>
> > > >>>>
> > > >>>
> > > >>
> > > >
> > >
>
Re: Flight authentication interoperability
Posted by David Li <li...@gmail.com>.
I've filed/found the following:
ARROW-4575 [1] for adding Python to the Flight integration tests
ARROW-5875 [2] for adding RPC features (like auth) to integration tests
ARROW-1009 [3] for async APIs
ARROW-5876 [4] for implementing basic auth across all languages
ARROW-5877 [5] for documenting the caveats around auth
[1]: https://issues.apache.org/jira/browse/ARROW-4575
[2]: https://issues.apache.org/jira/browse/ARROW-5875
[3]: https://issues.apache.org/jira/browse/ARROW-1009
[4]: https://issues.apache.org/jira/browse/ARROW-5876
[5]: https://issues.apache.org/jira/browse/ARROW-5877
Best,
David
On 7/6/19, Wes McKinney <we...@gmail.com> wrote:
> Are there some action items (JIRA issues) to follow up here? At
> minimum having documentation about this for the Python client side
> would seem to be in order.
>
> On Thu, Jul 4, 2019 at 2:20 PM Ryan Murray <ry...@dremio.com> wrote:
>>
>> Hey David,
>>
>> I was actually testing test_flight.test_http_basic_auth(). But I think
>> the
>> same applies. The Java default implementation expects a handshake. More
>> to
>> the point it expects a BasicAuth protobuf which I believe is not exposed
>> at
>> all in python. Always returning true in
>> BasicServerAuthHandler.authenticate() allows for the test implementations
>> of Java and Python authentication to speak to each other.
>>
>> Thanks for the below link, that really clarified things for me. I would
>> add
>> to the list that we should normalise the use of BasicAuth protobuf
>> message
>> between java and cpp.
>>
>> Apologies for the urgency yesterday, I am glad it was sorted and more my
>> fault than Arrow's.
>>
>> Best,
>> Ryan
>>
>>
>> On Thu, Jul 4, 2019 at 11:29 AM David Li <li...@gmail.com> wrote:
>>
>> > Hmm, interesting. I assume you mean test_flight.test_token_auth() as
>> > the client? The tests weren't written to be explicitly compatible, but
>> > there's no reason you should get an indefinite stall.
>> >
>> > We don't use Handshake/ServerAuthHandler#authenticate, so that would
>> > explain why we don't see issues. I commented on this in the initial
>> > implementation:
>> > https://github.com/apache/arrow/pull/4125#discussion_r273935691
>> >
>> > > there is not a 1-1 mapping between connected clients and connected
>> > peers, and so you can
>> > > only know the identity of the peer at the moment it makes a call.
>> > > Just
>> > doing a handshake
>> > > (Authenticate) isn't enough to identify who is on the other end of a
>> > particular connection.
>> >
>> > the reason being that a layer 7 load balancer (e.g. Envoy) means one
>> > gRPC connection can represent multiple clients. Conversely,
>> > client-side load balancing (built into gRPC) means one client-side
>> > "connection" can actually represent multiple servers. Of course, you
>> > have to consciously deploy in this manner, so Handshake is still
>> > useful if you know you won't ever need these features.
>> >
>> > As I see it, this means there's a few things to work on:
>> > - Flight RPC feature compatibility needs to be tested, not just format
>> > compatibility.
>> > - We should start thinking about async APIs and/or timeouts in any
>> > sort of API that makes a network call (there's already a JIRA:
>> > https://issues.apache.org/jira/browse/ARROW-1009), since "never
>> > returns" is a terrible failure mode
>> >
>> > Best,
>> > David
>> >
>> > On 7/4/19, Ryan Murray <ry...@dremio.com> wrote:
>> > > Hey David,
>> > >
>> > > I am curious to see what you are doing different from me. I am
>> > > running
>> > the
>> > > Java ExampleFlightServer.java against the python auth flight tests
>> > > and
>> > they
>> > > are not passing. The particular issue is that incoming.next() never
>> > returns
>> > > in BasicServerAuthHandler.java:56
>> > >
>> > > It doesn't appear to be anything wrong w/ the auth piece specifically
>> > > rather the server appears to not be getting the auth info to verify. I
>> > > am
>> > > still investigating my issue but I am glad that someone else has
>> > > gotten
>> > > this to work.
>> > >
>> > > Best,
>> > > Ryan
>> > >
>> > > On Thu, Jul 4, 2019 at 9:13 AM Antoine Pitrou <an...@python.org>
>> > wrote:
>> > >
>> > >>
>> > >> It may be worth opening a JIRA for the flaky tests if not already
>> > >> done.
>> > >>
>> > >> Regards
>> > >>
>> > >> Antoine.
>> > >>
>> > >>
>> > >> Le 04/07/2019 à 18:11, David Li a écrit :
>> > >> > I'm also curious as to what the issue was, as we've been doing
>> > >> > Python-client-Java-server auth with development builds without
>> > >> > trouble.
>> > >> >
>> > >> > Regardless - this does point out a need for more cross-language
>> > >> > Flight
>> > >> > testing (perhaps a Flight-specific integration suite?), and to get
>> > >> > existing tests running more consistently in CI (Flight/Java in
>> > >> > particular has a lot of flaky tests, though the auth tests are
>> > >> > enabled
>> > >> > in Travis).
>> > >> >
>> > >> > Best,
>> > >> > David
>> > >> >
>> > >> > On 7/4/19, Jacques Nadeau <ja...@apache.org> wrote:
>> > >> >> Which is exactly why I was withholding a vote until there was
>> > >> >> more
>> > >> >> information.
>> > >> >>
>> > >> >> On Thu, Jul 4, 2019, 7:25 AM Antoine Pitrou <so...@pitrou.net>
>> > >> wrote:
>> > >> >>
>> > >> >>> On Thu, 4 Jul 2019 09:04:34 -0500
>> > >> >>> Wes McKinney <we...@gmail.com> wrote:
>> > >> >>>>
>> > >> >>>> That being said, with Ryan's issue, he is using a feature
>> > >> >>>> (cross-language auth in Flight) that isn't being tested. The
>> > >> >>>> Flight
>> > >> >>>> integration tests do not use authentication AFAIK so I'm not
>> > >> >>>> surprised
>> > >> >>>> to hear that there may be an issue with it.
>> > >> >>>
>> > >> >>> OTOH, it's a bit unlikely. Flight authentication is implemented
>> > >> >>> is:
>> > >> >>> - the Arrow codebase simply passes opaque tokens around
>> > >> >>> - interpretation of tokens is handled by application code
>> > >> >>> - marshalling of tokens is handled by Protocol Buffers
>> > >> >>>
>> > >> >>> So unless something silly is going on (such as "passing an empty
>> > >> >>> string
>> > >> >>> instead of the actual token") there's not much potential for
>> > >> >>> auth interoperability issues in the core Flight codebase.
>> > >> >>>
>> > >> >>> Regards
>> > >> >>>
>> > >> >>> Antoine.
>> > >> >>>
>> > >> >>>
>> > >> >>>
>> > >> >>
>> > >>
>> > >
>> > >
>> > > --
>> > >
>> > > Ryan Murray | Principal Consulting Engineer
>> > >
>> > > +447540852009 | rymurr@dremio.com
>> > >
>> > > <https://www.dremio.com/>
>> > > Check out our GitHub <https://www.github.com/dremio>, join our
>> > > community
>> > > site <https://community.dremio.com/> & Download Dremio
>> > > <https://www.dremio.com/download>
>> > >
>> >
>>
>>
>> --
>>
>> Ryan Murray | Principal Consulting Engineer
>>
>> +447540852009 | rymurr@dremio.com
>>
>> <https://www.dremio.com/>
>> Check out our GitHub <https://www.github.com/dremio>, join our community
>> site <https://community.dremio.com/> & Download Dremio
>> <https://www.dremio.com/download>
>> I
>
Re: Flight authentication interoperability
Posted by Wes McKinney <we...@gmail.com>.
Are there some action items (JIRA issues) to follow up here? At
minimum having documentation about this for the Python client side
would seem to be in order.
On Thu, Jul 4, 2019 at 2:20 PM Ryan Murray <ry...@dremio.com> wrote:
>
> Hey David,
>
> I was actually testing test_flight.test_http_basic_auth(). But I think the
> same applies. The Java default implementation expects a handshake. More to
> the point it expects a BasicAuth protobuf which I believe is not exposed at
> all in python. Always returning true in
> BasicServerAuthHandler.authenticate() allows for the test implementations
> of Java and Python authentication to speak to each other.
>
> Thanks for the below link, that really clarified things for me. I would add
> to the list that we should normalise the use of BasicAuth protobuf message
> between java and cpp.
>
> Apologies for the urgency yesterday, I am glad it was sorted and more my
> fault than Arrow's.
>
> Best,
> Ryan
>
>
> On Thu, Jul 4, 2019 at 11:29 AM David Li <li...@gmail.com> wrote:
>
> > Hmm, interesting. I assume you mean test_flight.test_token_auth() as
> > the client? The tests weren't written to be explicitly compatible, but
> > there's no reason you should get an indefinite stall.
> >
> > We don't use Handshake/ServerAuthHandler#authenticate, so that would
> > explain why we don't see issues. I commented on this in the initial
> > implementation:
> > https://github.com/apache/arrow/pull/4125#discussion_r273935691
> >
> > > there is not a 1-1 mapping between connected clients and connected
> > peers, and so you can
> > > only know the identity of the peer at the moment it makes a call. Just
> > doing a handshake
> > > (Authenticate) isn't enough to identify who is on the other end of a
> > particular connection.
> >
> > the reason being that a layer 7 load balancer (e.g. Envoy) means one
> > gRPC connection can represent multiple clients. Conversely,
> > client-side load balancing (built into gRPC) means one client-side
> > "connection" can actually represent multiple servers. Of course, you
> > have to consciously deploy in this manner, so Handshake is still
> > useful if you know you won't ever need these features.
> >
> > As I see it, this means there's a few things to work on:
> > - Flight RPC feature compatibility needs to be tested, not just format
> > compatibility.
> > - We should start thinking about async APIs and/or timeouts in any
> > sort of API that makes a network call (there's already a JIRA:
> > https://issues.apache.org/jira/browse/ARROW-1009), since "never
> > returns" is a terrible failure mode
> >
> > Best,
> > David
> >
> > On 7/4/19, Ryan Murray <ry...@dremio.com> wrote:
> > > Hey David,
> > >
> > > I am curious to see what you are doing different from me. I am running
> > the
> > > Java ExampleFlightServer.java against the python auth flight tests and
> > they
> > > are not passing. The particular issue is that incoming.next() never
> > returns
> > > in BasicServerAuthHandler.java:56
> > >
> > > It doesn't appear to be anything wrong w/ the auth piece specifically
> > > rather the server appears to not be getting the auth info to verify. I am
> > > still investigating my issue but I am glad that someone else has gotten
> > > this to work.
> > >
> > > Best,
> > > Ryan
> > >
> > > On Thu, Jul 4, 2019 at 9:13 AM Antoine Pitrou <an...@python.org>
> > wrote:
> > >
> > >>
> > >> It may be worth opening a JIRA for the flaky tests if not already done.
> > >>
> > >> Regards
> > >>
> > >> Antoine.
> > >>
> > >>
> > >> Le 04/07/2019 à 18:11, David Li a écrit :
> > >> > I'm also curious as to what the issue was, as we've been doing
> > >> > Python-client-Java-server auth with development builds without
> > >> > trouble.
> > >> >
> > >> > Regardless - this does point out a need for more cross-language Flight
> > >> > testing (perhaps a Flight-specific integration suite?), and to get
> > >> > existing tests running more consistently in CI (Flight/Java in
> > >> > particular has a lot of flaky tests, though the auth tests are enabled
> > >> > in Travis).
> > >> >
> > >> > Best,
> > >> > David
> > >> >
> > >> > On 7/4/19, Jacques Nadeau <ja...@apache.org> wrote:
> > >> >> Which is exactly why I was withholding a vote until there was more
> > >> >> information.
> > >> >>
> > >> >> On Thu, Jul 4, 2019, 7:25 AM Antoine Pitrou <so...@pitrou.net>
> > >> wrote:
> > >> >>
> > >> >>> On Thu, 4 Jul 2019 09:04:34 -0500
> > >> >>> Wes McKinney <we...@gmail.com> wrote:
> > >> >>>>
> > >> >>>> That being said, with Ryan's issue, he is using a feature
> > >> >>>> (cross-language auth in Flight) that isn't being tested. The Flight
> > >> >>>> integration tests do not use authentication AFAIK so I'm not
> > >> >>>> surprised
> > >> >>>> to hear that there may be an issue with it.
> > >> >>>
> > >> >>> OTOH, it's a bit unlikely. Flight authentication is implemented is:
> > >> >>> - the Arrow codebase simply passes opaque tokens around
> > >> >>> - interpretation of tokens is handled by application code
> > >> >>> - marshalling of tokens is handled by Protocol Buffers
> > >> >>>
> > >> >>> So unless something silly is going on (such as "passing an empty
> > >> >>> string
> > >> >>> instead of the actual token") there's not much potential for
> > >> >>> auth interoperability issues in the core Flight codebase.
> > >> >>>
> > >> >>> Regards
> > >> >>>
> > >> >>> Antoine.
> > >> >>>
> > >> >>>
> > >> >>>
> > >> >>
> > >>
> > >
> > >
> > > --
> > >
> > > Ryan Murray | Principal Consulting Engineer
> > >
> > > +447540852009 | rymurr@dremio.com
> > >
> > > <https://www.dremio.com/>
> > > Check out our GitHub <https://www.github.com/dremio>, join our community
> > > site <https://community.dremio.com/> & Download Dremio
> > > <https://www.dremio.com/download>
> > >
> >
>
>
> --
>
> Ryan Murray | Principal Consulting Engineer
>
> +447540852009 | rymurr@dremio.com
>
> <https://www.dremio.com/>
> Check out our GitHub <https://www.github.com/dremio>, join our community
> site <https://community.dremio.com/> & Download Dremio
> <https://www.dremio.com/download>
> I
Re: Flight authentication interoperability
Posted by Ryan Murray <ry...@dremio.com>.
Hey David,
I was actually testing test_flight.test_http_basic_auth(). But I think the
same applies. The Java default implementation expects a handshake. More to
the point it expects a BasicAuth protobuf which I believe is not exposed at
all in python. Always returning true in
BasicServerAuthHandler.authenticate() allows for the test implementations
of Java and Python authentication to speak to each other.
Thanks for the below link, that really clarified things for me. I would add
to the list that we should normalise the use of BasicAuth protobuf message
between java and cpp.
Apologies for the urgency yesterday, I am glad it was sorted and more my
fault than Arrow's.
Best,
Ryan
On Thu, Jul 4, 2019 at 11:29 AM David Li <li...@gmail.com> wrote:
> Hmm, interesting. I assume you mean test_flight.test_token_auth() as
> the client? The tests weren't written to be explicitly compatible, but
> there's no reason you should get an indefinite stall.
>
> We don't use Handshake/ServerAuthHandler#authenticate, so that would
> explain why we don't see issues. I commented on this in the initial
> implementation:
> https://github.com/apache/arrow/pull/4125#discussion_r273935691
>
> > there is not a 1-1 mapping between connected clients and connected
> peers, and so you can
> > only know the identity of the peer at the moment it makes a call. Just
> doing a handshake
> > (Authenticate) isn't enough to identify who is on the other end of a
> particular connection.
>
> the reason being that a layer 7 load balancer (e.g. Envoy) means one
> gRPC connection can represent multiple clients. Conversely,
> client-side load balancing (built into gRPC) means one client-side
> "connection" can actually represent multiple servers. Of course, you
> have to consciously deploy in this manner, so Handshake is still
> useful if you know you won't ever need these features.
>
> As I see it, this means there's a few things to work on:
> - Flight RPC feature compatibility needs to be tested, not just format
> compatibility.
> - We should start thinking about async APIs and/or timeouts in any
> sort of API that makes a network call (there's already a JIRA:
> https://issues.apache.org/jira/browse/ARROW-1009), since "never
> returns" is a terrible failure mode
>
> Best,
> David
>
> On 7/4/19, Ryan Murray <ry...@dremio.com> wrote:
> > Hey David,
> >
> > I am curious to see what you are doing different from me. I am running
> the
> > Java ExampleFlightServer.java against the python auth flight tests and
> they
> > are not passing. The particular issue is that incoming.next() never
> returns
> > in BasicServerAuthHandler.java:56
> >
> > It doesn't appear to be anything wrong w/ the auth piece specifically
> > rather the server appears to not be getting the auth info to verify. I am
> > still investigating my issue but I am glad that someone else has gotten
> > this to work.
> >
> > Best,
> > Ryan
> >
> > On Thu, Jul 4, 2019 at 9:13 AM Antoine Pitrou <an...@python.org>
> wrote:
> >
> >>
> >> It may be worth opening a JIRA for the flaky tests if not already done.
> >>
> >> Regards
> >>
> >> Antoine.
> >>
> >>
> >> Le 04/07/2019 à 18:11, David Li a écrit :
> >> > I'm also curious as to what the issue was, as we've been doing
> >> > Python-client-Java-server auth with development builds without
> >> > trouble.
> >> >
> >> > Regardless - this does point out a need for more cross-language Flight
> >> > testing (perhaps a Flight-specific integration suite?), and to get
> >> > existing tests running more consistently in CI (Flight/Java in
> >> > particular has a lot of flaky tests, though the auth tests are enabled
> >> > in Travis).
> >> >
> >> > Best,
> >> > David
> >> >
> >> > On 7/4/19, Jacques Nadeau <ja...@apache.org> wrote:
> >> >> Which is exactly why I was withholding a vote until there was more
> >> >> information.
> >> >>
> >> >> On Thu, Jul 4, 2019, 7:25 AM Antoine Pitrou <so...@pitrou.net>
> >> wrote:
> >> >>
> >> >>> On Thu, 4 Jul 2019 09:04:34 -0500
> >> >>> Wes McKinney <we...@gmail.com> wrote:
> >> >>>>
> >> >>>> That being said, with Ryan's issue, he is using a feature
> >> >>>> (cross-language auth in Flight) that isn't being tested. The Flight
> >> >>>> integration tests do not use authentication AFAIK so I'm not
> >> >>>> surprised
> >> >>>> to hear that there may be an issue with it.
> >> >>>
> >> >>> OTOH, it's a bit unlikely. Flight authentication is implemented is:
> >> >>> - the Arrow codebase simply passes opaque tokens around
> >> >>> - interpretation of tokens is handled by application code
> >> >>> - marshalling of tokens is handled by Protocol Buffers
> >> >>>
> >> >>> So unless something silly is going on (such as "passing an empty
> >> >>> string
> >> >>> instead of the actual token") there's not much potential for
> >> >>> auth interoperability issues in the core Flight codebase.
> >> >>>
> >> >>> Regards
> >> >>>
> >> >>> Antoine.
> >> >>>
> >> >>>
> >> >>>
> >> >>
> >>
> >
> >
> > --
> >
> > Ryan Murray | Principal Consulting Engineer
> >
> > +447540852009 | rymurr@dremio.com
> >
> > <https://www.dremio.com/>
> > Check out our GitHub <https://www.github.com/dremio>, join our community
> > site <https://community.dremio.com/> & Download Dremio
> > <https://www.dremio.com/download>
> >
>
--
Ryan Murray | Principal Consulting Engineer
+447540852009 | rymurr@dremio.com
<https://www.dremio.com/>
Check out our GitHub <https://www.github.com/dremio>, join our community
site <https://community.dremio.com/> & Download Dremio
<https://www.dremio.com/download>
I
Re: Flight authentication interoperability
Posted by David Li <li...@gmail.com>.
Hmm, interesting. I assume you mean test_flight.test_token_auth() as
the client? The tests weren't written to be explicitly compatible, but
there's no reason you should get an indefinite stall.
We don't use Handshake/ServerAuthHandler#authenticate, so that would
explain why we don't see issues. I commented on this in the initial
implementation:
https://github.com/apache/arrow/pull/4125#discussion_r273935691
> there is not a 1-1 mapping between connected clients and connected peers, and so you can
> only know the identity of the peer at the moment it makes a call. Just doing a handshake
> (Authenticate) isn't enough to identify who is on the other end of a particular connection.
the reason being that a layer 7 load balancer (e.g. Envoy) means one
gRPC connection can represent multiple clients. Conversely,
client-side load balancing (built into gRPC) means one client-side
"connection" can actually represent multiple servers. Of course, you
have to consciously deploy in this manner, so Handshake is still
useful if you know you won't ever need these features.
As I see it, this means there's a few things to work on:
- Flight RPC feature compatibility needs to be tested, not just format
compatibility.
- We should start thinking about async APIs and/or timeouts in any
sort of API that makes a network call (there's already a JIRA:
https://issues.apache.org/jira/browse/ARROW-1009), since "never
returns" is a terrible failure mode
Best,
David
On 7/4/19, Ryan Murray <ry...@dremio.com> wrote:
> Hey David,
>
> I am curious to see what you are doing different from me. I am running the
> Java ExampleFlightServer.java against the python auth flight tests and they
> are not passing. The particular issue is that incoming.next() never returns
> in BasicServerAuthHandler.java:56
>
> It doesn't appear to be anything wrong w/ the auth piece specifically
> rather the server appears to not be getting the auth info to verify. I am
> still investigating my issue but I am glad that someone else has gotten
> this to work.
>
> Best,
> Ryan
>
> On Thu, Jul 4, 2019 at 9:13 AM Antoine Pitrou <an...@python.org> wrote:
>
>>
>> It may be worth opening a JIRA for the flaky tests if not already done.
>>
>> Regards
>>
>> Antoine.
>>
>>
>> Le 04/07/2019 à 18:11, David Li a écrit :
>> > I'm also curious as to what the issue was, as we've been doing
>> > Python-client-Java-server auth with development builds without
>> > trouble.
>> >
>> > Regardless - this does point out a need for more cross-language Flight
>> > testing (perhaps a Flight-specific integration suite?), and to get
>> > existing tests running more consistently in CI (Flight/Java in
>> > particular has a lot of flaky tests, though the auth tests are enabled
>> > in Travis).
>> >
>> > Best,
>> > David
>> >
>> > On 7/4/19, Jacques Nadeau <ja...@apache.org> wrote:
>> >> Which is exactly why I was withholding a vote until there was more
>> >> information.
>> >>
>> >> On Thu, Jul 4, 2019, 7:25 AM Antoine Pitrou <so...@pitrou.net>
>> wrote:
>> >>
>> >>> On Thu, 4 Jul 2019 09:04:34 -0500
>> >>> Wes McKinney <we...@gmail.com> wrote:
>> >>>>
>> >>>> That being said, with Ryan's issue, he is using a feature
>> >>>> (cross-language auth in Flight) that isn't being tested. The Flight
>> >>>> integration tests do not use authentication AFAIK so I'm not
>> >>>> surprised
>> >>>> to hear that there may be an issue with it.
>> >>>
>> >>> OTOH, it's a bit unlikely. Flight authentication is implemented is:
>> >>> - the Arrow codebase simply passes opaque tokens around
>> >>> - interpretation of tokens is handled by application code
>> >>> - marshalling of tokens is handled by Protocol Buffers
>> >>>
>> >>> So unless something silly is going on (such as "passing an empty
>> >>> string
>> >>> instead of the actual token") there's not much potential for
>> >>> auth interoperability issues in the core Flight codebase.
>> >>>
>> >>> Regards
>> >>>
>> >>> Antoine.
>> >>>
>> >>>
>> >>>
>> >>
>>
>
>
> --
>
> Ryan Murray | Principal Consulting Engineer
>
> +447540852009 | rymurr@dremio.com
>
> <https://www.dremio.com/>
> Check out our GitHub <https://www.github.com/dremio>, join our community
> site <https://community.dremio.com/> & Download Dremio
> <https://www.dremio.com/download>
>
Re: Flight authentication interoperability
Posted by Ryan Murray <ry...@dremio.com>.
Hey David,
I am curious to see what you are doing different from me. I am running the
Java ExampleFlightServer.java against the python auth flight tests and they
are not passing. The particular issue is that incoming.next() never returns
in BasicServerAuthHandler.java:56
It doesn't appear to be anything wrong w/ the auth piece specifically
rather the server appears to not be getting the auth info to verify. I am
still investigating my issue but I am glad that someone else has gotten
this to work.
Best,
Ryan
On Thu, Jul 4, 2019 at 9:13 AM Antoine Pitrou <an...@python.org> wrote:
>
> It may be worth opening a JIRA for the flaky tests if not already done.
>
> Regards
>
> Antoine.
>
>
> Le 04/07/2019 à 18:11, David Li a écrit :
> > I'm also curious as to what the issue was, as we've been doing
> > Python-client-Java-server auth with development builds without
> > trouble.
> >
> > Regardless - this does point out a need for more cross-language Flight
> > testing (perhaps a Flight-specific integration suite?), and to get
> > existing tests running more consistently in CI (Flight/Java in
> > particular has a lot of flaky tests, though the auth tests are enabled
> > in Travis).
> >
> > Best,
> > David
> >
> > On 7/4/19, Jacques Nadeau <ja...@apache.org> wrote:
> >> Which is exactly why I was withholding a vote until there was more
> >> information.
> >>
> >> On Thu, Jul 4, 2019, 7:25 AM Antoine Pitrou <so...@pitrou.net>
> wrote:
> >>
> >>> On Thu, 4 Jul 2019 09:04:34 -0500
> >>> Wes McKinney <we...@gmail.com> wrote:
> >>>>
> >>>> That being said, with Ryan's issue, he is using a feature
> >>>> (cross-language auth in Flight) that isn't being tested. The Flight
> >>>> integration tests do not use authentication AFAIK so I'm not surprised
> >>>> to hear that there may be an issue with it.
> >>>
> >>> OTOH, it's a bit unlikely. Flight authentication is implemented is:
> >>> - the Arrow codebase simply passes opaque tokens around
> >>> - interpretation of tokens is handled by application code
> >>> - marshalling of tokens is handled by Protocol Buffers
> >>>
> >>> So unless something silly is going on (such as "passing an empty string
> >>> instead of the actual token") there's not much potential for
> >>> auth interoperability issues in the core Flight codebase.
> >>>
> >>> Regards
> >>>
> >>> Antoine.
> >>>
> >>>
> >>>
> >>
>
--
Ryan Murray | Principal Consulting Engineer
+447540852009 | rymurr@dremio.com
<https://www.dremio.com/>
Check out our GitHub <https://www.github.com/dremio>, join our community
site <https://community.dremio.com/> & Download Dremio
<https://www.dremio.com/download>
Re: Flight authentication interoperability
Posted by Antoine Pitrou <an...@python.org>.
It may be worth opening a JIRA for the flaky tests if not already done.
Regards
Antoine.
Le 04/07/2019 à 18:11, David Li a écrit :
> I'm also curious as to what the issue was, as we've been doing
> Python-client-Java-server auth with development builds without
> trouble.
>
> Regardless - this does point out a need for more cross-language Flight
> testing (perhaps a Flight-specific integration suite?), and to get
> existing tests running more consistently in CI (Flight/Java in
> particular has a lot of flaky tests, though the auth tests are enabled
> in Travis).
>
> Best,
> David
>
> On 7/4/19, Jacques Nadeau <ja...@apache.org> wrote:
>> Which is exactly why I was withholding a vote until there was more
>> information.
>>
>> On Thu, Jul 4, 2019, 7:25 AM Antoine Pitrou <so...@pitrou.net> wrote:
>>
>>> On Thu, 4 Jul 2019 09:04:34 -0500
>>> Wes McKinney <we...@gmail.com> wrote:
>>>>
>>>> That being said, with Ryan's issue, he is using a feature
>>>> (cross-language auth in Flight) that isn't being tested. The Flight
>>>> integration tests do not use authentication AFAIK so I'm not surprised
>>>> to hear that there may be an issue with it.
>>>
>>> OTOH, it's a bit unlikely. Flight authentication is implemented is:
>>> - the Arrow codebase simply passes opaque tokens around
>>> - interpretation of tokens is handled by application code
>>> - marshalling of tokens is handled by Protocol Buffers
>>>
>>> So unless something silly is going on (such as "passing an empty string
>>> instead of the actual token") there's not much potential for
>>> auth interoperability issues in the core Flight codebase.
>>>
>>> Regards
>>>
>>> Antoine.
>>>
>>>
>>>
>>
Re: Flight authentication interoperability
Posted by David Li <li...@gmail.com>.
I'm also curious as to what the issue was, as we've been doing
Python-client-Java-server auth with development builds without
trouble.
Regardless - this does point out a need for more cross-language Flight
testing (perhaps a Flight-specific integration suite?), and to get
existing tests running more consistently in CI (Flight/Java in
particular has a lot of flaky tests, though the auth tests are enabled
in Travis).
Best,
David
On 7/4/19, Jacques Nadeau <ja...@apache.org> wrote:
> Which is exactly why I was withholding a vote until there was more
> information.
>
> On Thu, Jul 4, 2019, 7:25 AM Antoine Pitrou <so...@pitrou.net> wrote:
>
>> On Thu, 4 Jul 2019 09:04:34 -0500
>> Wes McKinney <we...@gmail.com> wrote:
>> >
>> > That being said, with Ryan's issue, he is using a feature
>> > (cross-language auth in Flight) that isn't being tested. The Flight
>> > integration tests do not use authentication AFAIK so I'm not surprised
>> > to hear that there may be an issue with it.
>>
>> OTOH, it's a bit unlikely. Flight authentication is implemented is:
>> - the Arrow codebase simply passes opaque tokens around
>> - interpretation of tokens is handled by application code
>> - marshalling of tokens is handled by Protocol Buffers
>>
>> So unless something silly is going on (such as "passing an empty string
>> instead of the actual token") there's not much potential for
>> auth interoperability issues in the core Flight codebase.
>>
>> Regards
>>
>> Antoine.
>>
>>
>>
>
Re: Flight authentication interoperability
Posted by Jacques Nadeau <ja...@apache.org>.
Which is exactly why I was withholding a vote until there was more
information.
On Thu, Jul 4, 2019, 7:25 AM Antoine Pitrou <so...@pitrou.net> wrote:
> On Thu, 4 Jul 2019 09:04:34 -0500
> Wes McKinney <we...@gmail.com> wrote:
> >
> > That being said, with Ryan's issue, he is using a feature
> > (cross-language auth in Flight) that isn't being tested. The Flight
> > integration tests do not use authentication AFAIK so I'm not surprised
> > to hear that there may be an issue with it.
>
> OTOH, it's a bit unlikely. Flight authentication is implemented is:
> - the Arrow codebase simply passes opaque tokens around
> - interpretation of tokens is handled by application code
> - marshalling of tokens is handled by Protocol Buffers
>
> So unless something silly is going on (such as "passing an empty string
> instead of the actual token") there's not much potential for
> auth interoperability issues in the core Flight codebase.
>
> Regards
>
> Antoine.
>
>
>
Re: Flight authentication interoperability
Posted by Antoine Pitrou <so...@pitrou.net>.
On Thu, 4 Jul 2019 09:04:34 -0500
Wes McKinney <we...@gmail.com> wrote:
>
> That being said, with Ryan's issue, he is using a feature
> (cross-language auth in Flight) that isn't being tested. The Flight
> integration tests do not use authentication AFAIK so I'm not surprised
> to hear that there may be an issue with it.
OTOH, it's a bit unlikely. Flight authentication is implemented is:
- the Arrow codebase simply passes opaque tokens around
- interpretation of tokens is handled by application code
- marshalling of tokens is handled by Protocol Buffers
So unless something silly is going on (such as "passing an empty string
instead of the actual token") there's not much potential for
auth interoperability issues in the core Flight codebase.
Regards
Antoine.
Re: [VOTE] Release Apache Arrow 0.14.0 - RC0
Posted by Wes McKinney <we...@gmail.com>.
hi Jacques,
I agree that we should allow ample time for discussions around issues
raised by people validating the release.
That being said, with Ryan's issue, he is using a feature
(cross-language auth in Flight) that isn't being tested. The Flight
integration tests do not use authentication AFAIK so I'm not surprised
to hear that there may be an issue with it. It would be as if there
were a cross-compatibility issues between Python and Rust. Again,
would not surprise me because Rust is not included in the integration
tests. Even with a reproduction of such an issue I don't think it
should block the release in the future.
I'd be glad to help make a point release in the near future since we
uncovered quite a few small issues during this RC, and I think there's
more value in getting the software into the hands of users than
waiting multiple weeks to address them all.
- Wes
On Thu, Jul 4, 2019 at 8:50 AM Jacques Nadeau <ja...@apache.org> wrote:
>
> A release vote should last until we arrive at consensus. When an issue is
> potentially identified, those that have voted should be given ample time to
> change their vote and others that may have been lazy consenters should be
> given time to chime in. There is no maximum amount of time a vote can be
> open. Allowing at least 24 hours after an objection is raised is a pretty
> minimum expectation unless the objector removes their objection.
>
> Note that Apache is more focused on consensus than timing (as opposed to
> virtually other other organizations in the world).
>
> In this case I was waiting to see more information from the objector before
> casting my vote. I see a -1 vote as community chilling and prefer for
> consensus to be reached through discussions rather than contrary voting.
>
>
>
> On Thu, Jul 4, 2019, 6:35 AM Antoine Pitrou <an...@python.org> wrote:
>
> >
> > That's an open question. How long should a release vote last?
> > Apparently this one lasted 3 days. The 0.14.0 vote (after RC4) lasted 3
> > days before a decision was made too.
> >
> > Regards
> >
> > Antoine.
> >
> >
> > Le 04/07/2019 à 15:28, Jacques Nadeau a écrit :
> > > There are two different questions here.
> > >
> > > 1) should this issue block the release.
> > > 2) should a discussion with ample time for all parties to come to
> > consensus
> > > have occurred before closing the vote.
> > >
> > > The first question is a subjective question. The answer to the second
> > > question should have been an unequivocal yes.
> > >
> > > I'll send a separate mail on point one but the problem I see here
> > > fundamentally is point two.
> > >
> > > On Thu, Jul 4, 2019, 6:01 AM Antoine Pitrou <an...@python.org> wrote:
> > >
> > >>
> > >> I agree with Kou here. It's not a problem with the release per se, it's
> > >> a problem with the Flight code in git master. There is no regression
> > >> AFAICT, and we have not promised that Flight was stable and
> > >> production-ready yet.
> > >>
> > >> If we're ok releasing with bugs such as this (Java unable to read back
> > >> union arrays?), then I think a Flight bug shouldn't hold a release.
> > >> https://issues.apache.org/jira/browse/ARROW-5231
> > >>
> > >> Regards
> > >>
> > >> Antoine.
> > >>
> > >>
> > >> Le 04/07/2019 à 14:46, Jacques Nadeau a écrit :
> > >>> Im disappointed in this response. When someone finds an issue with a
> > >>> release it should be triaged/validated rather than rushed past rather
> > >>> quickly and closing the vote before others can chime in on the issue.
> > >>>
> > >>> I'm now left voting -1 on a closed vote. In the future, let's have a
> > >>> discussion about issues like this. Your response and the close of the
> > >> vote
> > >>> were unilateral and all happened while some of us were sleeping.
> > >>>
> > >>> On Wed, Jul 3, 2019, 10:47 PM Sutou Kouhei <ko...@clear-code.com> wrote:
> > >>>
> > >>>> Hi,
> > >>>>
> > >>>> Flight isn't stable yet. So Flight problem isn't a blocker
> > >>>> of this release. Could you open a JIRA issue for your
> > >>>> problem? We'll be able to fix it until 1.0.0.
> > >>>>
> > >>>>
> > >>>> Thanks,
> > >>>> --
> > >>>> kou
> > >>>>
> > >>>> In <
> > CAKg4KDx8_Rr8xQOBaspW+U0LYPX21tPcWx6S4_RDdMk4VpDwcg@mail.gmail.com>
> > >>>> "Re: [VOTE] Release Apache Arrow 0.14.0 - RC0" on Wed, 3 Jul 2019
> > >>>> 17:18:15 -0700,
> > >>>> Ryan Murray <ry...@dremio.com> wrote:
> > >>>>
> > >>>>> Hi All,
> > >>>>>
> > >>>>> I have noticed that a python Flight client can't authenticate to a
> > Java
> > >>>>> Flight server while doing some testing today. I am trying to confirm
> > if
> > >>>>> this is a bug in the flight implementation or in my own code. I
> > >> thought I
> > >>>>> would report here as it could potentially be a blocker to this
> > release.
> > >>>>>
> > >>>>> I will confirm and come back to you shortly.
> > >>>>>
> > >>>>> Best,
> > >>>>> Ryan
> > >>>>>
> > >>>>> On Wed, Jul 3, 2019 at 5:02 PM Sutou Kouhei <ko...@clear-code.com>
> > >> wrote:
> > >>>>>
> > >>>>>> Thanks for confirming it!
> > >>>>>>
> > >>>>>> This will be solved by the pull request.
> > >>>>>>
> > >>>>>> In <
> > >> CAF6oT1d5X-GLEdLHbAixi74+pXo5aP8EgGsYLWQUiMWPVxMsrg@mail.gmail.com>
> > >>>>>> "Re: [VOTE] Release Apache Arrow 0.14.0 - RC0" on Wed, 3 Jul 2019
> > >>>>>> 13:53:19 -0700,
> > >>>>>> Chao Sun <su...@apache.org> wrote:
> > >>>>>>
> > >>>>>>> Thanks Sutou. It is 2.5.0:
> > >>>>>>>
> > >>>>>>> $ protoc --version
> > >>>>>>> libprotoc 2.5.0
> > >>>>>>>
> > >>>>>>> Yes this is an old version, which is still used by Apache Hadoop.
> > >>>>>>>
> > >>>>>>> On Wed, Jul 3, 2019 at 1:27 PM Sutou Kouhei <ko...@clear-code.com>
> > >>>> wrote:
> > >>>>>>>
> > >>>>>>>> Thanks for verifying this RC!
> > >>>>>>>>
> > >>>>>>>> It seems that the C++ error is caused by old Protocol
> > >>>>>>>> Buffers. Could you show your system Protocol Buffers
> > >>>>>>>> version?
> > >>>>>>>>
> > >>>>>>>> https://github.com/apache/arrow/pull/4785 will resolve this
> > >>>>>>>> case. It prevents using old system Protocol Buffers.
> > >>>>>>>>
> > >>>>>>>> In <
> > >>>> CAF6oT1e8eMh1gWoOO+Uuq5z6AmwZPRfUuyV4C+w+crpievzLuw@mail.gmail.com>
> > >>>>>>>> "Re: [VOTE] Release Apache Arrow 0.14.0 - RC0" on Wed, 3 Jul
> > 2019
> > >>>>>>>> 00:15:54 -0700,
> > >>>>>>>> Chao Sun <su...@apache.org> wrote:
> > >>>>>>>>
> > >>>>>>>>> On MacOS Mojave. Verified Rust and Go with
> > >>>> verify-release-candidate.sh
> > >>>>>>>> and
> > >>>>>>>>> they look good.
> > >>>>>>>>> I got the following error when verifying C++ though:
> > >>>>>>>>>
> > >>>>>>>>> [ 18%] Built target grpc_dependencies
> > >>>>>>>>> CMake Error at
> > >>>>>>>>>
> > >>>>>>>>
> > >>>>>>
> > >>>>
> > >>
> > /var/folders/z3/ptkgr4kn4pv9v8g7s1fnr5mm0000gn/T/arrow-0.14.0.XXXXX.yYmSAqR5/apache-arrow-0.14.0/cpp/build/orc_ep-prefix/src/orc_ep-stamp/orc_ep-build-RELEASE.cmake:49
> > >>>>>>>>> (message):
> > >>>>>>>>> Command failed: 2
> > >>>>>>>>> '/Library/Developer/CommandLineTools/usr/bin/make'
> > >>>>>>>>> See also
> > >>>>>>>>>
> > >>>>>>>>>
> > >>>>>>>>
> > >>>>>>
> > >>>>
> > >>
> > /var/folders/z3/ptkgr4kn4pv9v8g7s1fnr5mm0000gn/T/arrow-0.14.0.XXXXX.yYmSAqR5/apache-arrow-0.14.0/cpp/build/orc_ep-prefix/src/orc_ep-stamp/orc_ep-build-*.log
> > >>>>>>>>> make[2]: *** [orc_ep-prefix/src/orc_ep-stamp/orc_ep-build] Error
> > 1
> > >>>>>>>>> make[1]: *** [CMakeFiles/orc_ep.dir/all] Error 2
> > >>>>>>>>>
> > >>>>>>>>> In orc_ep-build-err.log:
> > >>>>>>>>>
> > >>>>>>>>> In file included from
> > >>>>>>>>>
> > >>>>>>>>
> > >>>>>>
> > >>>>
> > >>
> > /var/folders/z3/ptkgr4kn4pv9v8g7s1fnr5mm0000gn/T/arrow-0.14.0.XXXXX.yYmSAqR5/apache-arrow-0.14.0/cpp/build/orc_ep-prefix/src/orc_ep/c++/src/io/OutputStream.cc:20:
> > >>>>>>>>>
> > >>>>>>>>
> > >>>>>>
> > >>>>
> > >>
> > ^[[1m/var/folders/z3/ptkgr4kn4pv9v8g7s1fnr5mm0000gn/T/arrow-0.14.0.XXXXX.yYmSAqR5/apache-arrow-0.14.0/cpp/build/orc_ep-prefix/src/orc_ep/c++/src/io/OutputStream.hh:59:18:
> > >>>>>>>>> ^[[0m^[[0;1;31merror: ^[[0m^[[1m'WriteAliasedRaw' marked
> > >>>>>> 'override'
> > >>>>>>>>> but does not override any member functions^[[0m
> > >>>>>>>>> virtual bool WriteAliasedRaw(const void * data, int size)
> > >>>>>> override;
> > >>>>>>>>> ^[[0;1;32m ^
> > >>>>>>>>>
> > >>>>>>>>
> > >>>>>>
> > >>>>
> > >>
> > ^[[0m^[[1m/var/folders/z3/ptkgr4kn4pv9v8g7s1fnr5mm0000gn/T/arrow-0.14.0.XXXXX.yYmSAqR5/apache-arrow-0.14.0/cpp/build/orc_ep-prefix/src/orc_ep/c++/src/io/OutputStream.hh:60:18:
> > >>>>>>>>> ^[[0m^[[0;1;31merror: ^[[0m^[[1m'AllowsAliasing' marked
> > 'override'
> > >>>>>> but
> > >>>>>>>>> does not override any member functions^[[0m
> > >>>>>>>>> virtual bool AllowsAliasing() const override;
> > >>>>>>>>> ^[[0;1;32m ^
> > >>>>>>>>> ^[[0m2 errors generated.
> > >>>>>>>>> make[5]: *** [c++/src/CMakeFiles/orc.dir/io/OutputStream.cc.o]
> > >>>> Error 1
> > >>>>>>>>> make[4]: *** [c++/src/CMakeFiles/orc.dir/all] Error 2
> > >>>>>>>>> make[3]: *** [all] Error 2
> > >>>>>>>>>
> > >>>>>>>>> Not sure if this is due to my environment.
> > >>>>>>>>>
> > >>>>>>>>> Chao
> > >>>>>>>>>
> > >>>>>>>>> On Tue, Jul 2, 2019 at 6:54 PM Ravindra Pindikura <
> > >>>>>> ravindra@dremio.com>
> > >>>>>>>>> wrote:
> > >>>>>>>>>
> > >>>>>>>>>> ok, thanks !
> > >>>>>>>>>>
> > >>>>>>>>>> On Wed, Jul 3, 2019 at 7:10 AM Sutou Kouhei <kou@clear-code.com
> > >
> > >>>>>> wrote:
> > >>>>>>>>>>
> > >>>>>>>>>>> Hi,
> > >>>>>>>>>>>
> > >>>>>>>>>>> Thanks for verifying this RC!
> > >>>>>>>>>>>
> > >>>>>>>>>>>> 2. The package doesn't seem to include gandiva
> > >>>>>>>>>>>>
> > >>>>>>>>>>>> is that intentional ? I'm fine if it is not included, just
> > >>>> want
> > >>>>>> to
> > >>>>>>>>>>> confirm
> > >>>>>>>>>>>> if that's expected.
> > >>>>>>>>>>>
> > >>>>>>>>>>> I think that this is caused by "-P arrow-jni" is missing in
> > >>>>>>>>>>> 01-perform.sh:
> > >>>>>>>>>>>
> > >>>>>>>>>>>
> > >>>> https://github.com/apache/arrow/pull/4717#issuecomment-506916189
> > >>>>>>>>>>>
> > >>>>>>>>>>> It's intentional for RC0.
> > >>>>>>>>>>>
> > >>>>>>>>>>> We'll fix this after RC0:
> > >>>>>>>>>>>
> > >>>>>>>>>>> https://issues.apache.org/jira/browse/ARROW-5786
> > >>>>>>>>>>>
> > >>>>>>>>>>>
> > >>>>>>>>>>> Thanks,
> > >>>>>>>>>>> --
> > >>>>>>>>>>> kou
> > >>>>>>>>>>>
> > >>>>>>>>>>> In <
> > >>>>>>>>
> > CAPWBuG6wVuDwu7-Z8dYHq7SNuSAgAPpkdzkrQoF4DfnJ4Np5ag@mail.gmail.com>
> > >>>>>>>>>>> "Re: [VOTE] Release Apache Arrow 0.14.0 - RC0" on Wed, 3 Jul
> > >>>> 2019
> > >>>>>>>>>>> 06:55:52 +0530,
> > >>>>>>>>>>> Ravindra Pindikura <ra...@dremio.com> wrote:
> > >>>>>>>>>>>
> > >>>>>>>>>>>> I tried "./dev/release/verify-release-candidate.sh source
> > >>>> 0.14.0
> > >>>>>> 0"
> > >>>>>>>> on
> > >>>>>>>>>>> mac
> > >>>>>>>>>>>> mojave.
> > >>>>>>>>>>>>
> > >>>>>>>>>>>> 1. I consistently get this error with flight tests
> > >>>>>>>>>>>>
> > >>>>>>>>>>>> [ERROR] Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time
> > >>>>>>>> elapsed:
> > >>>>>>>>>>>> 0.04 s <<< FAILURE! - in
> > >>>>>> org.apache.arrow.flight.TestServerOptions
> > >>>>>>>>>>>> [ERROR]
> > >>>> domainSocket(org.apache.arrow.flight.TestServerOptions)
> > >>>>>>>> Time
> > >>>>>>>>>>>> elapsed: 0.04 s <<< ERROR!
> > >>>>>>>>>>>> java.io.IOException: Failed to bind
> > >>>>>>>>>>>> at
> > >>>>>>>>>>>>
> > >>>>>>>>>>>
> > >>>>>>>>>>
> > >>>>>>>>
> > >>>>>>
> > >>>>
> > >>
> > org.apache.arrow.flight.TestServerOptions.domainSocket(TestServerOptions.java:46)
> > >>>>>>>>>>>> Caused by: io.netty.channel.unix.Errors$NativeIoException:
> > >>>>>> bind(..)
> > >>>>>>>>>>> failed:
> > >>>>>>>>>>>> Address already in use
> > >>>>>>>>>>>>
> > >>>>>>>>>>>> Is there a workaround or gotcha for this ?
> > >>>>>>>>>>>>
> > >>>>>>>>>>>> 2. The package doesn't seem to include gandiva
> > >>>>>>>>>>>>
> > >>>>>>>>>>>> is that intentional ? I'm fine if it is not included, just
> > >>>> want
> > >>>>>> to
> > >>>>>>>>>>> confirm
> > >>>>>>>>>>>> if that's expected.
> > >>>>>>>>>>>>
> > >>>>>>>>>>>> On Wed, Jul 3, 2019 at 6:37 AM Sutou Kouhei <
> > >>>> kou@clear-code.com>
> > >>>>>>>>>> wrote:
> > >>>>>>>>>>>>
> > >>>>>>>>>>>>>> I tried again (Ubuntu 18.04):
> > >>>>>>>>>>>>>> * source verification failed in gRPC configure step:
> > >>>>>>>>>>>>>> Problem is, Ubuntu's c-ares does not provide any CMake
> > >>>> files:
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>> Note: Adding -Dc-ares_SOURCE=BUNDLED CMake option is
> > >>>>>>>>>>>>> workaround. We can use bundled c-ares automatically by
> > >>>>>>>>>>>>> requiring c-ares's CMake config:
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>> https://github.com/apache/arrow/pull/4783
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>> Thanks,
> > >>>>>>>>>>>>> --
> > >>>>>>>>>>>>> kou
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>> In <7a...@python.org>
> > >>>>>>>>>>>>> "Re: [VOTE] Release Apache Arrow 0.14.0 - RC0" on Tue, 2
> > >>>> Jul
> > >>>>>> 2019
> > >>>>>>>>>>>>> 11:36:09 +0200,
> > >>>>>>>>>>>>> Antoine Pitrou <an...@python.org> wrote:
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>>>
> > >>>>>>>>>>>>>> I tried again (Ubuntu 18.04):
> > >>>>>>>>>>>>>>
> > >>>>>>>>>>>>>> * binaries verification succeeded
> > >>>>>>>>>>>>>>
> > >>>>>>>>>>>>>> * source verification failed in gRPC configure step:
> > >>>>>>>>>>>>>>
> > >>>>>>>>>>>>>> CMake Error at cmake/cares.cmake:38 (find_package):
> > >>>>>>>>>>>>>> Could not find a package configuration file provided by
> > >>>>>>>> "c-ares"
> > >>>>>>>>>>> with
> > >>>>>>>>>>>>> any
> > >>>>>>>>>>>>>> of the following names:
> > >>>>>>>>>>>>>>
> > >>>>>>>>>>>>>> c-aresConfig.cmake
> > >>>>>>>>>>>>>> c-ares-config.cmake
> > >>>>>>>>>>>>>>
> > >>>>>>>>>>>>>> Add the installation prefix of "c-ares" to
> > >>>>>> CMAKE_PREFIX_PATH or
> > >>>>>>>>>> set
> > >>>>>>>>>>>>>> "c-ares_DIR" to a directory containing one of the above
> > >>>>>>>> files. If
> > >>>>>>>>>>>>> "c-ares"
> > >>>>>>>>>>>>>> provides a separate development package or SDK, be sure
> > >>>> it
> > >>>>>> has
> > >>>>>>>>>> been
> > >>>>>>>>>>>>>> installed.
> > >>>>>>>>>>>>>> Call Stack (most recent call first):
> > >>>>>>>>>>>>>> CMakeLists.txt:139 (include)
> > >>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>
> > >>>>>>>>>>>>>> Problem is, Ubuntu's c-ares does not provide any CMake
> > >>>> files:
> > >>>>>>>>>>>>>>
> > >>>>>>>>>>>>>> $ dpkg -L libc-ares-dev
> > >>>>>>>>>>>>>> /.
> > >>>>>>>>>>>>>> /usr
> > >>>>>>>>>>>>>> /usr/include
> > >>>>>>>>>>>>>> /usr/include/ares.h
> > >>>>>>>>>>>>>> /usr/include/ares_build.h
> > >>>>>>>>>>>>>> /usr/include/ares_dns.h
> > >>>>>>>>>>>>>> /usr/include/ares_rules.h
> > >>>>>>>>>>>>>> /usr/include/ares_version.h
> > >>>>>>>>>>>>>> /usr/lib
> > >>>>>>>>>>>>>> /usr/lib/x86_64-linux-gnu
> > >>>>>>>>>>>>>> /usr/lib/x86_64-linux-gnu/libcares.a
> > >>>>>>>>>>>>>> /usr/lib/x86_64-linux-gnu/pkgconfig
> > >>>>>>>>>>>>>> /usr/lib/x86_64-linux-gnu/pkgconfig/libcares.pc
> > >>>>>>>>>>>>>> /usr/share
> > >>>>>>>>>>>>>> /usr/share/doc
> > >>>>>>>>>>>>>> /usr/share/doc/libc-ares-dev
> > >>>>>>>>>>>>>> /usr/share/doc/libc-ares-dev/NEWS.gz
> > >>>>>>>>>>>>>> /usr/share/doc/libc-ares-dev/README.cares
> > >>>>>>>>>>>>>> /usr/share/doc/libc-ares-dev/README.md
> > >>>>>>>>>>>>>> /usr/share/doc/libc-ares-dev/copyright
> > >>>>>>>>>>>>>> /usr/share/man
> > >>>>>>>>>>>>>> /usr/share/man/man3
> > >>>>>>>>>>>>>> [ snip man pages ]
> > >>>>>>>>>>>>>> /usr/lib/x86_64-linux-gnu/libcares.so
> > >>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>
> > >>>>>>>>>>>>>> Regards
> > >>>>>>>>>>>>>>
> > >>>>>>>>>>>>>> Antoine.
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>
> > >>>>>>>>>>>>
> > >>>>>>>>>>>> --
> > >>>>>>>>>>>> Thanks and regards,
> > >>>>>>>>>>>> Ravindra.
> > >>>>>>>>>>>
> > >>>>>>>>>>
> > >>>>>>>>>>
> > >>>>>>>>>> --
> > >>>>>>>>>> Thanks and regards,
> > >>>>>>>>>> Ravindra.
> > >>>>>>>>>>
> > >>>>>>>>
> > >>>>>>
> > >>>>>
> > >>>>>
> > >>>>> --
> > >>>>>
> > >>>>> Ryan Murray | Principal Consulting Engineer
> > >>>>>
> > >>>>> +447540852009 | rymurr@dremio.com
> > >>>>>
> > >>>>> <https://www.dremio.com/>
> > >>>>> Check out our GitHub <https://www.github.com/dremio>, join our
> > >> community
> > >>>>> site <https://community.dremio.com/> & Download Dremio
> > >>>>> <https://www.dremio.com/download>
> > >>>>
> > >>>
> > >>
> > >
> >
Re: [VOTE] Release Apache Arrow 0.14.0 - RC0
Posted by Jacques Nadeau <ja...@apache.org>.
A release vote should last until we arrive at consensus. When an issue is
potentially identified, those that have voted should be given ample time to
change their vote and others that may have been lazy consenters should be
given time to chime in. There is no maximum amount of time a vote can be
open. Allowing at least 24 hours after an objection is raised is a pretty
minimum expectation unless the objector removes their objection.
Note that Apache is more focused on consensus than timing (as opposed to
virtually other other organizations in the world).
In this case I was waiting to see more information from the objector before
casting my vote. I see a -1 vote as community chilling and prefer for
consensus to be reached through discussions rather than contrary voting.
On Thu, Jul 4, 2019, 6:35 AM Antoine Pitrou <an...@python.org> wrote:
>
> That's an open question. How long should a release vote last?
> Apparently this one lasted 3 days. The 0.14.0 vote (after RC4) lasted 3
> days before a decision was made too.
>
> Regards
>
> Antoine.
>
>
> Le 04/07/2019 à 15:28, Jacques Nadeau a écrit :
> > There are two different questions here.
> >
> > 1) should this issue block the release.
> > 2) should a discussion with ample time for all parties to come to
> consensus
> > have occurred before closing the vote.
> >
> > The first question is a subjective question. The answer to the second
> > question should have been an unequivocal yes.
> >
> > I'll send a separate mail on point one but the problem I see here
> > fundamentally is point two.
> >
> > On Thu, Jul 4, 2019, 6:01 AM Antoine Pitrou <an...@python.org> wrote:
> >
> >>
> >> I agree with Kou here. It's not a problem with the release per se, it's
> >> a problem with the Flight code in git master. There is no regression
> >> AFAICT, and we have not promised that Flight was stable and
> >> production-ready yet.
> >>
> >> If we're ok releasing with bugs such as this (Java unable to read back
> >> union arrays?), then I think a Flight bug shouldn't hold a release.
> >> https://issues.apache.org/jira/browse/ARROW-5231
> >>
> >> Regards
> >>
> >> Antoine.
> >>
> >>
> >> Le 04/07/2019 à 14:46, Jacques Nadeau a écrit :
> >>> Im disappointed in this response. When someone finds an issue with a
> >>> release it should be triaged/validated rather than rushed past rather
> >>> quickly and closing the vote before others can chime in on the issue.
> >>>
> >>> I'm now left voting -1 on a closed vote. In the future, let's have a
> >>> discussion about issues like this. Your response and the close of the
> >> vote
> >>> were unilateral and all happened while some of us were sleeping.
> >>>
> >>> On Wed, Jul 3, 2019, 10:47 PM Sutou Kouhei <ko...@clear-code.com> wrote:
> >>>
> >>>> Hi,
> >>>>
> >>>> Flight isn't stable yet. So Flight problem isn't a blocker
> >>>> of this release. Could you open a JIRA issue for your
> >>>> problem? We'll be able to fix it until 1.0.0.
> >>>>
> >>>>
> >>>> Thanks,
> >>>> --
> >>>> kou
> >>>>
> >>>> In <
> CAKg4KDx8_Rr8xQOBaspW+U0LYPX21tPcWx6S4_RDdMk4VpDwcg@mail.gmail.com>
> >>>> "Re: [VOTE] Release Apache Arrow 0.14.0 - RC0" on Wed, 3 Jul 2019
> >>>> 17:18:15 -0700,
> >>>> Ryan Murray <ry...@dremio.com> wrote:
> >>>>
> >>>>> Hi All,
> >>>>>
> >>>>> I have noticed that a python Flight client can't authenticate to a
> Java
> >>>>> Flight server while doing some testing today. I am trying to confirm
> if
> >>>>> this is a bug in the flight implementation or in my own code. I
> >> thought I
> >>>>> would report here as it could potentially be a blocker to this
> release.
> >>>>>
> >>>>> I will confirm and come back to you shortly.
> >>>>>
> >>>>> Best,
> >>>>> Ryan
> >>>>>
> >>>>> On Wed, Jul 3, 2019 at 5:02 PM Sutou Kouhei <ko...@clear-code.com>
> >> wrote:
> >>>>>
> >>>>>> Thanks for confirming it!
> >>>>>>
> >>>>>> This will be solved by the pull request.
> >>>>>>
> >>>>>> In <
> >> CAF6oT1d5X-GLEdLHbAixi74+pXo5aP8EgGsYLWQUiMWPVxMsrg@mail.gmail.com>
> >>>>>> "Re: [VOTE] Release Apache Arrow 0.14.0 - RC0" on Wed, 3 Jul 2019
> >>>>>> 13:53:19 -0700,
> >>>>>> Chao Sun <su...@apache.org> wrote:
> >>>>>>
> >>>>>>> Thanks Sutou. It is 2.5.0:
> >>>>>>>
> >>>>>>> $ protoc --version
> >>>>>>> libprotoc 2.5.0
> >>>>>>>
> >>>>>>> Yes this is an old version, which is still used by Apache Hadoop.
> >>>>>>>
> >>>>>>> On Wed, Jul 3, 2019 at 1:27 PM Sutou Kouhei <ko...@clear-code.com>
> >>>> wrote:
> >>>>>>>
> >>>>>>>> Thanks for verifying this RC!
> >>>>>>>>
> >>>>>>>> It seems that the C++ error is caused by old Protocol
> >>>>>>>> Buffers. Could you show your system Protocol Buffers
> >>>>>>>> version?
> >>>>>>>>
> >>>>>>>> https://github.com/apache/arrow/pull/4785 will resolve this
> >>>>>>>> case. It prevents using old system Protocol Buffers.
> >>>>>>>>
> >>>>>>>> In <
> >>>> CAF6oT1e8eMh1gWoOO+Uuq5z6AmwZPRfUuyV4C+w+crpievzLuw@mail.gmail.com>
> >>>>>>>> "Re: [VOTE] Release Apache Arrow 0.14.0 - RC0" on Wed, 3 Jul
> 2019
> >>>>>>>> 00:15:54 -0700,
> >>>>>>>> Chao Sun <su...@apache.org> wrote:
> >>>>>>>>
> >>>>>>>>> On MacOS Mojave. Verified Rust and Go with
> >>>> verify-release-candidate.sh
> >>>>>>>> and
> >>>>>>>>> they look good.
> >>>>>>>>> I got the following error when verifying C++ though:
> >>>>>>>>>
> >>>>>>>>> [ 18%] Built target grpc_dependencies
> >>>>>>>>> CMake Error at
> >>>>>>>>>
> >>>>>>>>
> >>>>>>
> >>>>
> >>
> /var/folders/z3/ptkgr4kn4pv9v8g7s1fnr5mm0000gn/T/arrow-0.14.0.XXXXX.yYmSAqR5/apache-arrow-0.14.0/cpp/build/orc_ep-prefix/src/orc_ep-stamp/orc_ep-build-RELEASE.cmake:49
> >>>>>>>>> (message):
> >>>>>>>>> Command failed: 2
> >>>>>>>>> '/Library/Developer/CommandLineTools/usr/bin/make'
> >>>>>>>>> See also
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>
> >>>>>>
> >>>>
> >>
> /var/folders/z3/ptkgr4kn4pv9v8g7s1fnr5mm0000gn/T/arrow-0.14.0.XXXXX.yYmSAqR5/apache-arrow-0.14.0/cpp/build/orc_ep-prefix/src/orc_ep-stamp/orc_ep-build-*.log
> >>>>>>>>> make[2]: *** [orc_ep-prefix/src/orc_ep-stamp/orc_ep-build] Error
> 1
> >>>>>>>>> make[1]: *** [CMakeFiles/orc_ep.dir/all] Error 2
> >>>>>>>>>
> >>>>>>>>> In orc_ep-build-err.log:
> >>>>>>>>>
> >>>>>>>>> In file included from
> >>>>>>>>>
> >>>>>>>>
> >>>>>>
> >>>>
> >>
> /var/folders/z3/ptkgr4kn4pv9v8g7s1fnr5mm0000gn/T/arrow-0.14.0.XXXXX.yYmSAqR5/apache-arrow-0.14.0/cpp/build/orc_ep-prefix/src/orc_ep/c++/src/io/OutputStream.cc:20:
> >>>>>>>>>
> >>>>>>>>
> >>>>>>
> >>>>
> >>
> ^[[1m/var/folders/z3/ptkgr4kn4pv9v8g7s1fnr5mm0000gn/T/arrow-0.14.0.XXXXX.yYmSAqR5/apache-arrow-0.14.0/cpp/build/orc_ep-prefix/src/orc_ep/c++/src/io/OutputStream.hh:59:18:
> >>>>>>>>> ^[[0m^[[0;1;31merror: ^[[0m^[[1m'WriteAliasedRaw' marked
> >>>>>> 'override'
> >>>>>>>>> but does not override any member functions^[[0m
> >>>>>>>>> virtual bool WriteAliasedRaw(const void * data, int size)
> >>>>>> override;
> >>>>>>>>> ^[[0;1;32m ^
> >>>>>>>>>
> >>>>>>>>
> >>>>>>
> >>>>
> >>
> ^[[0m^[[1m/var/folders/z3/ptkgr4kn4pv9v8g7s1fnr5mm0000gn/T/arrow-0.14.0.XXXXX.yYmSAqR5/apache-arrow-0.14.0/cpp/build/orc_ep-prefix/src/orc_ep/c++/src/io/OutputStream.hh:60:18:
> >>>>>>>>> ^[[0m^[[0;1;31merror: ^[[0m^[[1m'AllowsAliasing' marked
> 'override'
> >>>>>> but
> >>>>>>>>> does not override any member functions^[[0m
> >>>>>>>>> virtual bool AllowsAliasing() const override;
> >>>>>>>>> ^[[0;1;32m ^
> >>>>>>>>> ^[[0m2 errors generated.
> >>>>>>>>> make[5]: *** [c++/src/CMakeFiles/orc.dir/io/OutputStream.cc.o]
> >>>> Error 1
> >>>>>>>>> make[4]: *** [c++/src/CMakeFiles/orc.dir/all] Error 2
> >>>>>>>>> make[3]: *** [all] Error 2
> >>>>>>>>>
> >>>>>>>>> Not sure if this is due to my environment.
> >>>>>>>>>
> >>>>>>>>> Chao
> >>>>>>>>>
> >>>>>>>>> On Tue, Jul 2, 2019 at 6:54 PM Ravindra Pindikura <
> >>>>>> ravindra@dremio.com>
> >>>>>>>>> wrote:
> >>>>>>>>>
> >>>>>>>>>> ok, thanks !
> >>>>>>>>>>
> >>>>>>>>>> On Wed, Jul 3, 2019 at 7:10 AM Sutou Kouhei <kou@clear-code.com
> >
> >>>>>> wrote:
> >>>>>>>>>>
> >>>>>>>>>>> Hi,
> >>>>>>>>>>>
> >>>>>>>>>>> Thanks for verifying this RC!
> >>>>>>>>>>>
> >>>>>>>>>>>> 2. The package doesn't seem to include gandiva
> >>>>>>>>>>>>
> >>>>>>>>>>>> is that intentional ? I'm fine if it is not included, just
> >>>> want
> >>>>>> to
> >>>>>>>>>>> confirm
> >>>>>>>>>>>> if that's expected.
> >>>>>>>>>>>
> >>>>>>>>>>> I think that this is caused by "-P arrow-jni" is missing in
> >>>>>>>>>>> 01-perform.sh:
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>> https://github.com/apache/arrow/pull/4717#issuecomment-506916189
> >>>>>>>>>>>
> >>>>>>>>>>> It's intentional for RC0.
> >>>>>>>>>>>
> >>>>>>>>>>> We'll fix this after RC0:
> >>>>>>>>>>>
> >>>>>>>>>>> https://issues.apache.org/jira/browse/ARROW-5786
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>> Thanks,
> >>>>>>>>>>> --
> >>>>>>>>>>> kou
> >>>>>>>>>>>
> >>>>>>>>>>> In <
> >>>>>>>>
> CAPWBuG6wVuDwu7-Z8dYHq7SNuSAgAPpkdzkrQoF4DfnJ4Np5ag@mail.gmail.com>
> >>>>>>>>>>> "Re: [VOTE] Release Apache Arrow 0.14.0 - RC0" on Wed, 3 Jul
> >>>> 2019
> >>>>>>>>>>> 06:55:52 +0530,
> >>>>>>>>>>> Ravindra Pindikura <ra...@dremio.com> wrote:
> >>>>>>>>>>>
> >>>>>>>>>>>> I tried "./dev/release/verify-release-candidate.sh source
> >>>> 0.14.0
> >>>>>> 0"
> >>>>>>>> on
> >>>>>>>>>>> mac
> >>>>>>>>>>>> mojave.
> >>>>>>>>>>>>
> >>>>>>>>>>>> 1. I consistently get this error with flight tests
> >>>>>>>>>>>>
> >>>>>>>>>>>> [ERROR] Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time
> >>>>>>>> elapsed:
> >>>>>>>>>>>> 0.04 s <<< FAILURE! - in
> >>>>>> org.apache.arrow.flight.TestServerOptions
> >>>>>>>>>>>> [ERROR]
> >>>> domainSocket(org.apache.arrow.flight.TestServerOptions)
> >>>>>>>> Time
> >>>>>>>>>>>> elapsed: 0.04 s <<< ERROR!
> >>>>>>>>>>>> java.io.IOException: Failed to bind
> >>>>>>>>>>>> at
> >>>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>
> >>>>>>
> >>>>
> >>
> org.apache.arrow.flight.TestServerOptions.domainSocket(TestServerOptions.java:46)
> >>>>>>>>>>>> Caused by: io.netty.channel.unix.Errors$NativeIoException:
> >>>>>> bind(..)
> >>>>>>>>>>> failed:
> >>>>>>>>>>>> Address already in use
> >>>>>>>>>>>>
> >>>>>>>>>>>> Is there a workaround or gotcha for this ?
> >>>>>>>>>>>>
> >>>>>>>>>>>> 2. The package doesn't seem to include gandiva
> >>>>>>>>>>>>
> >>>>>>>>>>>> is that intentional ? I'm fine if it is not included, just
> >>>> want
> >>>>>> to
> >>>>>>>>>>> confirm
> >>>>>>>>>>>> if that's expected.
> >>>>>>>>>>>>
> >>>>>>>>>>>> On Wed, Jul 3, 2019 at 6:37 AM Sutou Kouhei <
> >>>> kou@clear-code.com>
> >>>>>>>>>> wrote:
> >>>>>>>>>>>>
> >>>>>>>>>>>>>> I tried again (Ubuntu 18.04):
> >>>>>>>>>>>>>> * source verification failed in gRPC configure step:
> >>>>>>>>>>>>>> Problem is, Ubuntu's c-ares does not provide any CMake
> >>>> files:
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> Note: Adding -Dc-ares_SOURCE=BUNDLED CMake option is
> >>>>>>>>>>>>> workaround. We can use bundled c-ares automatically by
> >>>>>>>>>>>>> requiring c-ares's CMake config:
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> https://github.com/apache/arrow/pull/4783
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> Thanks,
> >>>>>>>>>>>>> --
> >>>>>>>>>>>>> kou
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> In <7a...@python.org>
> >>>>>>>>>>>>> "Re: [VOTE] Release Apache Arrow 0.14.0 - RC0" on Tue, 2
> >>>> Jul
> >>>>>> 2019
> >>>>>>>>>>>>> 11:36:09 +0200,
> >>>>>>>>>>>>> Antoine Pitrou <an...@python.org> wrote:
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> I tried again (Ubuntu 18.04):
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> * binaries verification succeeded
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> * source verification failed in gRPC configure step:
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> CMake Error at cmake/cares.cmake:38 (find_package):
> >>>>>>>>>>>>>> Could not find a package configuration file provided by
> >>>>>>>> "c-ares"
> >>>>>>>>>>> with
> >>>>>>>>>>>>> any
> >>>>>>>>>>>>>> of the following names:
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> c-aresConfig.cmake
> >>>>>>>>>>>>>> c-ares-config.cmake
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> Add the installation prefix of "c-ares" to
> >>>>>> CMAKE_PREFIX_PATH or
> >>>>>>>>>> set
> >>>>>>>>>>>>>> "c-ares_DIR" to a directory containing one of the above
> >>>>>>>> files. If
> >>>>>>>>>>>>> "c-ares"
> >>>>>>>>>>>>>> provides a separate development package or SDK, be sure
> >>>> it
> >>>>>> has
> >>>>>>>>>> been
> >>>>>>>>>>>>>> installed.
> >>>>>>>>>>>>>> Call Stack (most recent call first):
> >>>>>>>>>>>>>> CMakeLists.txt:139 (include)
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> Problem is, Ubuntu's c-ares does not provide any CMake
> >>>> files:
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> $ dpkg -L libc-ares-dev
> >>>>>>>>>>>>>> /.
> >>>>>>>>>>>>>> /usr
> >>>>>>>>>>>>>> /usr/include
> >>>>>>>>>>>>>> /usr/include/ares.h
> >>>>>>>>>>>>>> /usr/include/ares_build.h
> >>>>>>>>>>>>>> /usr/include/ares_dns.h
> >>>>>>>>>>>>>> /usr/include/ares_rules.h
> >>>>>>>>>>>>>> /usr/include/ares_version.h
> >>>>>>>>>>>>>> /usr/lib
> >>>>>>>>>>>>>> /usr/lib/x86_64-linux-gnu
> >>>>>>>>>>>>>> /usr/lib/x86_64-linux-gnu/libcares.a
> >>>>>>>>>>>>>> /usr/lib/x86_64-linux-gnu/pkgconfig
> >>>>>>>>>>>>>> /usr/lib/x86_64-linux-gnu/pkgconfig/libcares.pc
> >>>>>>>>>>>>>> /usr/share
> >>>>>>>>>>>>>> /usr/share/doc
> >>>>>>>>>>>>>> /usr/share/doc/libc-ares-dev
> >>>>>>>>>>>>>> /usr/share/doc/libc-ares-dev/NEWS.gz
> >>>>>>>>>>>>>> /usr/share/doc/libc-ares-dev/README.cares
> >>>>>>>>>>>>>> /usr/share/doc/libc-ares-dev/README.md
> >>>>>>>>>>>>>> /usr/share/doc/libc-ares-dev/copyright
> >>>>>>>>>>>>>> /usr/share/man
> >>>>>>>>>>>>>> /usr/share/man/man3
> >>>>>>>>>>>>>> [ snip man pages ]
> >>>>>>>>>>>>>> /usr/lib/x86_64-linux-gnu/libcares.so
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> Regards
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> Antoine.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>> --
> >>>>>>>>>>>> Thanks and regards,
> >>>>>>>>>>>> Ravindra.
> >>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> --
> >>>>>>>>>> Thanks and regards,
> >>>>>>>>>> Ravindra.
> >>>>>>>>>>
> >>>>>>>>
> >>>>>>
> >>>>>
> >>>>>
> >>>>> --
> >>>>>
> >>>>> Ryan Murray | Principal Consulting Engineer
> >>>>>
> >>>>> +447540852009 | rymurr@dremio.com
> >>>>>
> >>>>> <https://www.dremio.com/>
> >>>>> Check out our GitHub <https://www.github.com/dremio>, join our
> >> community
> >>>>> site <https://community.dremio.com/> & Download Dremio
> >>>>> <https://www.dremio.com/download>
> >>>>
> >>>
> >>
> >
>
Re: [VOTE] Release Apache Arrow 0.14.0 - RC0
Posted by Antoine Pitrou <an...@python.org>.
That's an open question. How long should a release vote last?
Apparently this one lasted 3 days. The 0.14.0 vote (after RC4) lasted 3
days before a decision was made too.
Regards
Antoine.
Le 04/07/2019 à 15:28, Jacques Nadeau a écrit :
> There are two different questions here.
>
> 1) should this issue block the release.
> 2) should a discussion with ample time for all parties to come to consensus
> have occurred before closing the vote.
>
> The first question is a subjective question. The answer to the second
> question should have been an unequivocal yes.
>
> I'll send a separate mail on point one but the problem I see here
> fundamentally is point two.
>
> On Thu, Jul 4, 2019, 6:01 AM Antoine Pitrou <an...@python.org> wrote:
>
>>
>> I agree with Kou here. It's not a problem with the release per se, it's
>> a problem with the Flight code in git master. There is no regression
>> AFAICT, and we have not promised that Flight was stable and
>> production-ready yet.
>>
>> If we're ok releasing with bugs such as this (Java unable to read back
>> union arrays?), then I think a Flight bug shouldn't hold a release.
>> https://issues.apache.org/jira/browse/ARROW-5231
>>
>> Regards
>>
>> Antoine.
>>
>>
>> Le 04/07/2019 à 14:46, Jacques Nadeau a écrit :
>>> Im disappointed in this response. When someone finds an issue with a
>>> release it should be triaged/validated rather than rushed past rather
>>> quickly and closing the vote before others can chime in on the issue.
>>>
>>> I'm now left voting -1 on a closed vote. In the future, let's have a
>>> discussion about issues like this. Your response and the close of the
>> vote
>>> were unilateral and all happened while some of us were sleeping.
>>>
>>> On Wed, Jul 3, 2019, 10:47 PM Sutou Kouhei <ko...@clear-code.com> wrote:
>>>
>>>> Hi,
>>>>
>>>> Flight isn't stable yet. So Flight problem isn't a blocker
>>>> of this release. Could you open a JIRA issue for your
>>>> problem? We'll be able to fix it until 1.0.0.
>>>>
>>>>
>>>> Thanks,
>>>> --
>>>> kou
>>>>
>>>> In <CA...@mail.gmail.com>
>>>> "Re: [VOTE] Release Apache Arrow 0.14.0 - RC0" on Wed, 3 Jul 2019
>>>> 17:18:15 -0700,
>>>> Ryan Murray <ry...@dremio.com> wrote:
>>>>
>>>>> Hi All,
>>>>>
>>>>> I have noticed that a python Flight client can't authenticate to a Java
>>>>> Flight server while doing some testing today. I am trying to confirm if
>>>>> this is a bug in the flight implementation or in my own code. I
>> thought I
>>>>> would report here as it could potentially be a blocker to this release.
>>>>>
>>>>> I will confirm and come back to you shortly.
>>>>>
>>>>> Best,
>>>>> Ryan
>>>>>
>>>>> On Wed, Jul 3, 2019 at 5:02 PM Sutou Kouhei <ko...@clear-code.com>
>> wrote:
>>>>>
>>>>>> Thanks for confirming it!
>>>>>>
>>>>>> This will be solved by the pull request.
>>>>>>
>>>>>> In <
>> CAF6oT1d5X-GLEdLHbAixi74+pXo5aP8EgGsYLWQUiMWPVxMsrg@mail.gmail.com>
>>>>>> "Re: [VOTE] Release Apache Arrow 0.14.0 - RC0" on Wed, 3 Jul 2019
>>>>>> 13:53:19 -0700,
>>>>>> Chao Sun <su...@apache.org> wrote:
>>>>>>
>>>>>>> Thanks Sutou. It is 2.5.0:
>>>>>>>
>>>>>>> $ protoc --version
>>>>>>> libprotoc 2.5.0
>>>>>>>
>>>>>>> Yes this is an old version, which is still used by Apache Hadoop.
>>>>>>>
>>>>>>> On Wed, Jul 3, 2019 at 1:27 PM Sutou Kouhei <ko...@clear-code.com>
>>>> wrote:
>>>>>>>
>>>>>>>> Thanks for verifying this RC!
>>>>>>>>
>>>>>>>> It seems that the C++ error is caused by old Protocol
>>>>>>>> Buffers. Could you show your system Protocol Buffers
>>>>>>>> version?
>>>>>>>>
>>>>>>>> https://github.com/apache/arrow/pull/4785 will resolve this
>>>>>>>> case. It prevents using old system Protocol Buffers.
>>>>>>>>
>>>>>>>> In <
>>>> CAF6oT1e8eMh1gWoOO+Uuq5z6AmwZPRfUuyV4C+w+crpievzLuw@mail.gmail.com>
>>>>>>>> "Re: [VOTE] Release Apache Arrow 0.14.0 - RC0" on Wed, 3 Jul 2019
>>>>>>>> 00:15:54 -0700,
>>>>>>>> Chao Sun <su...@apache.org> wrote:
>>>>>>>>
>>>>>>>>> On MacOS Mojave. Verified Rust and Go with
>>>> verify-release-candidate.sh
>>>>>>>> and
>>>>>>>>> they look good.
>>>>>>>>> I got the following error when verifying C++ though:
>>>>>>>>>
>>>>>>>>> [ 18%] Built target grpc_dependencies
>>>>>>>>> CMake Error at
>>>>>>>>>
>>>>>>>>
>>>>>>
>>>>
>> /var/folders/z3/ptkgr4kn4pv9v8g7s1fnr5mm0000gn/T/arrow-0.14.0.XXXXX.yYmSAqR5/apache-arrow-0.14.0/cpp/build/orc_ep-prefix/src/orc_ep-stamp/orc_ep-build-RELEASE.cmake:49
>>>>>>>>> (message):
>>>>>>>>> Command failed: 2
>>>>>>>>> '/Library/Developer/CommandLineTools/usr/bin/make'
>>>>>>>>> See also
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>
>>>>
>> /var/folders/z3/ptkgr4kn4pv9v8g7s1fnr5mm0000gn/T/arrow-0.14.0.XXXXX.yYmSAqR5/apache-arrow-0.14.0/cpp/build/orc_ep-prefix/src/orc_ep-stamp/orc_ep-build-*.log
>>>>>>>>> make[2]: *** [orc_ep-prefix/src/orc_ep-stamp/orc_ep-build] Error 1
>>>>>>>>> make[1]: *** [CMakeFiles/orc_ep.dir/all] Error 2
>>>>>>>>>
>>>>>>>>> In orc_ep-build-err.log:
>>>>>>>>>
>>>>>>>>> In file included from
>>>>>>>>>
>>>>>>>>
>>>>>>
>>>>
>> /var/folders/z3/ptkgr4kn4pv9v8g7s1fnr5mm0000gn/T/arrow-0.14.0.XXXXX.yYmSAqR5/apache-arrow-0.14.0/cpp/build/orc_ep-prefix/src/orc_ep/c++/src/io/OutputStream.cc:20:
>>>>>>>>>
>>>>>>>>
>>>>>>
>>>>
>> ^[[1m/var/folders/z3/ptkgr4kn4pv9v8g7s1fnr5mm0000gn/T/arrow-0.14.0.XXXXX.yYmSAqR5/apache-arrow-0.14.0/cpp/build/orc_ep-prefix/src/orc_ep/c++/src/io/OutputStream.hh:59:18:
>>>>>>>>> ^[[0m^[[0;1;31merror: ^[[0m^[[1m'WriteAliasedRaw' marked
>>>>>> 'override'
>>>>>>>>> but does not override any member functions^[[0m
>>>>>>>>> virtual bool WriteAliasedRaw(const void * data, int size)
>>>>>> override;
>>>>>>>>> ^[[0;1;32m ^
>>>>>>>>>
>>>>>>>>
>>>>>>
>>>>
>> ^[[0m^[[1m/var/folders/z3/ptkgr4kn4pv9v8g7s1fnr5mm0000gn/T/arrow-0.14.0.XXXXX.yYmSAqR5/apache-arrow-0.14.0/cpp/build/orc_ep-prefix/src/orc_ep/c++/src/io/OutputStream.hh:60:18:
>>>>>>>>> ^[[0m^[[0;1;31merror: ^[[0m^[[1m'AllowsAliasing' marked 'override'
>>>>>> but
>>>>>>>>> does not override any member functions^[[0m
>>>>>>>>> virtual bool AllowsAliasing() const override;
>>>>>>>>> ^[[0;1;32m ^
>>>>>>>>> ^[[0m2 errors generated.
>>>>>>>>> make[5]: *** [c++/src/CMakeFiles/orc.dir/io/OutputStream.cc.o]
>>>> Error 1
>>>>>>>>> make[4]: *** [c++/src/CMakeFiles/orc.dir/all] Error 2
>>>>>>>>> make[3]: *** [all] Error 2
>>>>>>>>>
>>>>>>>>> Not sure if this is due to my environment.
>>>>>>>>>
>>>>>>>>> Chao
>>>>>>>>>
>>>>>>>>> On Tue, Jul 2, 2019 at 6:54 PM Ravindra Pindikura <
>>>>>> ravindra@dremio.com>
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>>> ok, thanks !
>>>>>>>>>>
>>>>>>>>>> On Wed, Jul 3, 2019 at 7:10 AM Sutou Kouhei <ko...@clear-code.com>
>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>>> Hi,
>>>>>>>>>>>
>>>>>>>>>>> Thanks for verifying this RC!
>>>>>>>>>>>
>>>>>>>>>>>> 2. The package doesn't seem to include gandiva
>>>>>>>>>>>>
>>>>>>>>>>>> is that intentional ? I'm fine if it is not included, just
>>>> want
>>>>>> to
>>>>>>>>>>> confirm
>>>>>>>>>>>> if that's expected.
>>>>>>>>>>>
>>>>>>>>>>> I think that this is caused by "-P arrow-jni" is missing in
>>>>>>>>>>> 01-perform.sh:
>>>>>>>>>>>
>>>>>>>>>>>
>>>> https://github.com/apache/arrow/pull/4717#issuecomment-506916189
>>>>>>>>>>>
>>>>>>>>>>> It's intentional for RC0.
>>>>>>>>>>>
>>>>>>>>>>> We'll fix this after RC0:
>>>>>>>>>>>
>>>>>>>>>>> https://issues.apache.org/jira/browse/ARROW-5786
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Thanks,
>>>>>>>>>>> --
>>>>>>>>>>> kou
>>>>>>>>>>>
>>>>>>>>>>> In <
>>>>>>>> CAPWBuG6wVuDwu7-Z8dYHq7SNuSAgAPpkdzkrQoF4DfnJ4Np5ag@mail.gmail.com>
>>>>>>>>>>> "Re: [VOTE] Release Apache Arrow 0.14.0 - RC0" on Wed, 3 Jul
>>>> 2019
>>>>>>>>>>> 06:55:52 +0530,
>>>>>>>>>>> Ravindra Pindikura <ra...@dremio.com> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> I tried "./dev/release/verify-release-candidate.sh source
>>>> 0.14.0
>>>>>> 0"
>>>>>>>> on
>>>>>>>>>>> mac
>>>>>>>>>>>> mojave.
>>>>>>>>>>>>
>>>>>>>>>>>> 1. I consistently get this error with flight tests
>>>>>>>>>>>>
>>>>>>>>>>>> [ERROR] Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time
>>>>>>>> elapsed:
>>>>>>>>>>>> 0.04 s <<< FAILURE! - in
>>>>>> org.apache.arrow.flight.TestServerOptions
>>>>>>>>>>>> [ERROR]
>>>> domainSocket(org.apache.arrow.flight.TestServerOptions)
>>>>>>>> Time
>>>>>>>>>>>> elapsed: 0.04 s <<< ERROR!
>>>>>>>>>>>> java.io.IOException: Failed to bind
>>>>>>>>>>>> at
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>
>>>>>>
>>>>
>> org.apache.arrow.flight.TestServerOptions.domainSocket(TestServerOptions.java:46)
>>>>>>>>>>>> Caused by: io.netty.channel.unix.Errors$NativeIoException:
>>>>>> bind(..)
>>>>>>>>>>> failed:
>>>>>>>>>>>> Address already in use
>>>>>>>>>>>>
>>>>>>>>>>>> Is there a workaround or gotcha for this ?
>>>>>>>>>>>>
>>>>>>>>>>>> 2. The package doesn't seem to include gandiva
>>>>>>>>>>>>
>>>>>>>>>>>> is that intentional ? I'm fine if it is not included, just
>>>> want
>>>>>> to
>>>>>>>>>>> confirm
>>>>>>>>>>>> if that's expected.
>>>>>>>>>>>>
>>>>>>>>>>>> On Wed, Jul 3, 2019 at 6:37 AM Sutou Kouhei <
>>>> kou@clear-code.com>
>>>>>>>>>> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>>> I tried again (Ubuntu 18.04):
>>>>>>>>>>>>>> * source verification failed in gRPC configure step:
>>>>>>>>>>>>>> Problem is, Ubuntu's c-ares does not provide any CMake
>>>> files:
>>>>>>>>>>>>>
>>>>>>>>>>>>> Note: Adding -Dc-ares_SOURCE=BUNDLED CMake option is
>>>>>>>>>>>>> workaround. We can use bundled c-ares automatically by
>>>>>>>>>>>>> requiring c-ares's CMake config:
>>>>>>>>>>>>>
>>>>>>>>>>>>> https://github.com/apache/arrow/pull/4783
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>> --
>>>>>>>>>>>>> kou
>>>>>>>>>>>>>
>>>>>>>>>>>>> In <7a...@python.org>
>>>>>>>>>>>>> "Re: [VOTE] Release Apache Arrow 0.14.0 - RC0" on Tue, 2
>>>> Jul
>>>>>> 2019
>>>>>>>>>>>>> 11:36:09 +0200,
>>>>>>>>>>>>> Antoine Pitrou <an...@python.org> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I tried again (Ubuntu 18.04):
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> * binaries verification succeeded
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> * source verification failed in gRPC configure step:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> CMake Error at cmake/cares.cmake:38 (find_package):
>>>>>>>>>>>>>> Could not find a package configuration file provided by
>>>>>>>> "c-ares"
>>>>>>>>>>> with
>>>>>>>>>>>>> any
>>>>>>>>>>>>>> of the following names:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> c-aresConfig.cmake
>>>>>>>>>>>>>> c-ares-config.cmake
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Add the installation prefix of "c-ares" to
>>>>>> CMAKE_PREFIX_PATH or
>>>>>>>>>> set
>>>>>>>>>>>>>> "c-ares_DIR" to a directory containing one of the above
>>>>>>>> files. If
>>>>>>>>>>>>> "c-ares"
>>>>>>>>>>>>>> provides a separate development package or SDK, be sure
>>>> it
>>>>>> has
>>>>>>>>>> been
>>>>>>>>>>>>>> installed.
>>>>>>>>>>>>>> Call Stack (most recent call first):
>>>>>>>>>>>>>> CMakeLists.txt:139 (include)
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Problem is, Ubuntu's c-ares does not provide any CMake
>>>> files:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> $ dpkg -L libc-ares-dev
>>>>>>>>>>>>>> /.
>>>>>>>>>>>>>> /usr
>>>>>>>>>>>>>> /usr/include
>>>>>>>>>>>>>> /usr/include/ares.h
>>>>>>>>>>>>>> /usr/include/ares_build.h
>>>>>>>>>>>>>> /usr/include/ares_dns.h
>>>>>>>>>>>>>> /usr/include/ares_rules.h
>>>>>>>>>>>>>> /usr/include/ares_version.h
>>>>>>>>>>>>>> /usr/lib
>>>>>>>>>>>>>> /usr/lib/x86_64-linux-gnu
>>>>>>>>>>>>>> /usr/lib/x86_64-linux-gnu/libcares.a
>>>>>>>>>>>>>> /usr/lib/x86_64-linux-gnu/pkgconfig
>>>>>>>>>>>>>> /usr/lib/x86_64-linux-gnu/pkgconfig/libcares.pc
>>>>>>>>>>>>>> /usr/share
>>>>>>>>>>>>>> /usr/share/doc
>>>>>>>>>>>>>> /usr/share/doc/libc-ares-dev
>>>>>>>>>>>>>> /usr/share/doc/libc-ares-dev/NEWS.gz
>>>>>>>>>>>>>> /usr/share/doc/libc-ares-dev/README.cares
>>>>>>>>>>>>>> /usr/share/doc/libc-ares-dev/README.md
>>>>>>>>>>>>>> /usr/share/doc/libc-ares-dev/copyright
>>>>>>>>>>>>>> /usr/share/man
>>>>>>>>>>>>>> /usr/share/man/man3
>>>>>>>>>>>>>> [ snip man pages ]
>>>>>>>>>>>>>> /usr/lib/x86_64-linux-gnu/libcares.so
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Regards
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Antoine.
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> --
>>>>>>>>>>>> Thanks and regards,
>>>>>>>>>>>> Ravindra.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> Thanks and regards,
>>>>>>>>>> Ravindra.
>>>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>>
>>>>> Ryan Murray | Principal Consulting Engineer
>>>>>
>>>>> +447540852009 | rymurr@dremio.com
>>>>>
>>>>> <https://www.dremio.com/>
>>>>> Check out our GitHub <https://www.github.com/dremio>, join our
>> community
>>>>> site <https://community.dremio.com/> & Download Dremio
>>>>> <https://www.dremio.com/download>
>>>>
>>>
>>
>
Re: [VOTE] Release Apache Arrow 0.14.0 - RC0
Posted by Jacques Nadeau <ja...@apache.org>.
There are two different questions here.
1) should this issue block the release.
2) should a discussion with ample time for all parties to come to consensus
have occurred before closing the vote.
The first question is a subjective question. The answer to the second
question should have been an unequivocal yes.
I'll send a separate mail on point one but the problem I see here
fundamentally is point two.
On Thu, Jul 4, 2019, 6:01 AM Antoine Pitrou <an...@python.org> wrote:
>
> I agree with Kou here. It's not a problem with the release per se, it's
> a problem with the Flight code in git master. There is no regression
> AFAICT, and we have not promised that Flight was stable and
> production-ready yet.
>
> If we're ok releasing with bugs such as this (Java unable to read back
> union arrays?), then I think a Flight bug shouldn't hold a release.
> https://issues.apache.org/jira/browse/ARROW-5231
>
> Regards
>
> Antoine.
>
>
> Le 04/07/2019 à 14:46, Jacques Nadeau a écrit :
> > Im disappointed in this response. When someone finds an issue with a
> > release it should be triaged/validated rather than rushed past rather
> > quickly and closing the vote before others can chime in on the issue.
> >
> > I'm now left voting -1 on a closed vote. In the future, let's have a
> > discussion about issues like this. Your response and the close of the
> vote
> > were unilateral and all happened while some of us were sleeping.
> >
> > On Wed, Jul 3, 2019, 10:47 PM Sutou Kouhei <ko...@clear-code.com> wrote:
> >
> >> Hi,
> >>
> >> Flight isn't stable yet. So Flight problem isn't a blocker
> >> of this release. Could you open a JIRA issue for your
> >> problem? We'll be able to fix it until 1.0.0.
> >>
> >>
> >> Thanks,
> >> --
> >> kou
> >>
> >> In <CA...@mail.gmail.com>
> >> "Re: [VOTE] Release Apache Arrow 0.14.0 - RC0" on Wed, 3 Jul 2019
> >> 17:18:15 -0700,
> >> Ryan Murray <ry...@dremio.com> wrote:
> >>
> >>> Hi All,
> >>>
> >>> I have noticed that a python Flight client can't authenticate to a Java
> >>> Flight server while doing some testing today. I am trying to confirm if
> >>> this is a bug in the flight implementation or in my own code. I
> thought I
> >>> would report here as it could potentially be a blocker to this release.
> >>>
> >>> I will confirm and come back to you shortly.
> >>>
> >>> Best,
> >>> Ryan
> >>>
> >>> On Wed, Jul 3, 2019 at 5:02 PM Sutou Kouhei <ko...@clear-code.com>
> wrote:
> >>>
> >>>> Thanks for confirming it!
> >>>>
> >>>> This will be solved by the pull request.
> >>>>
> >>>> In <
> CAF6oT1d5X-GLEdLHbAixi74+pXo5aP8EgGsYLWQUiMWPVxMsrg@mail.gmail.com>
> >>>> "Re: [VOTE] Release Apache Arrow 0.14.0 - RC0" on Wed, 3 Jul 2019
> >>>> 13:53:19 -0700,
> >>>> Chao Sun <su...@apache.org> wrote:
> >>>>
> >>>>> Thanks Sutou. It is 2.5.0:
> >>>>>
> >>>>> $ protoc --version
> >>>>> libprotoc 2.5.0
> >>>>>
> >>>>> Yes this is an old version, which is still used by Apache Hadoop.
> >>>>>
> >>>>> On Wed, Jul 3, 2019 at 1:27 PM Sutou Kouhei <ko...@clear-code.com>
> >> wrote:
> >>>>>
> >>>>>> Thanks for verifying this RC!
> >>>>>>
> >>>>>> It seems that the C++ error is caused by old Protocol
> >>>>>> Buffers. Could you show your system Protocol Buffers
> >>>>>> version?
> >>>>>>
> >>>>>> https://github.com/apache/arrow/pull/4785 will resolve this
> >>>>>> case. It prevents using old system Protocol Buffers.
> >>>>>>
> >>>>>> In <
> >> CAF6oT1e8eMh1gWoOO+Uuq5z6AmwZPRfUuyV4C+w+crpievzLuw@mail.gmail.com>
> >>>>>> "Re: [VOTE] Release Apache Arrow 0.14.0 - RC0" on Wed, 3 Jul 2019
> >>>>>> 00:15:54 -0700,
> >>>>>> Chao Sun <su...@apache.org> wrote:
> >>>>>>
> >>>>>>> On MacOS Mojave. Verified Rust and Go with
> >> verify-release-candidate.sh
> >>>>>> and
> >>>>>>> they look good.
> >>>>>>> I got the following error when verifying C++ though:
> >>>>>>>
> >>>>>>> [ 18%] Built target grpc_dependencies
> >>>>>>> CMake Error at
> >>>>>>>
> >>>>>>
> >>>>
> >>
> /var/folders/z3/ptkgr4kn4pv9v8g7s1fnr5mm0000gn/T/arrow-0.14.0.XXXXX.yYmSAqR5/apache-arrow-0.14.0/cpp/build/orc_ep-prefix/src/orc_ep-stamp/orc_ep-build-RELEASE.cmake:49
> >>>>>>> (message):
> >>>>>>> Command failed: 2
> >>>>>>> '/Library/Developer/CommandLineTools/usr/bin/make'
> >>>>>>> See also
> >>>>>>>
> >>>>>>>
> >>>>>>
> >>>>
> >>
> /var/folders/z3/ptkgr4kn4pv9v8g7s1fnr5mm0000gn/T/arrow-0.14.0.XXXXX.yYmSAqR5/apache-arrow-0.14.0/cpp/build/orc_ep-prefix/src/orc_ep-stamp/orc_ep-build-*.log
> >>>>>>> make[2]: *** [orc_ep-prefix/src/orc_ep-stamp/orc_ep-build] Error 1
> >>>>>>> make[1]: *** [CMakeFiles/orc_ep.dir/all] Error 2
> >>>>>>>
> >>>>>>> In orc_ep-build-err.log:
> >>>>>>>
> >>>>>>> In file included from
> >>>>>>>
> >>>>>>
> >>>>
> >>
> /var/folders/z3/ptkgr4kn4pv9v8g7s1fnr5mm0000gn/T/arrow-0.14.0.XXXXX.yYmSAqR5/apache-arrow-0.14.0/cpp/build/orc_ep-prefix/src/orc_ep/c++/src/io/OutputStream.cc:20:
> >>>>>>>
> >>>>>>
> >>>>
> >>
> ^[[1m/var/folders/z3/ptkgr4kn4pv9v8g7s1fnr5mm0000gn/T/arrow-0.14.0.XXXXX.yYmSAqR5/apache-arrow-0.14.0/cpp/build/orc_ep-prefix/src/orc_ep/c++/src/io/OutputStream.hh:59:18:
> >>>>>>> ^[[0m^[[0;1;31merror: ^[[0m^[[1m'WriteAliasedRaw' marked
> >>>> 'override'
> >>>>>>> but does not override any member functions^[[0m
> >>>>>>> virtual bool WriteAliasedRaw(const void * data, int size)
> >>>> override;
> >>>>>>> ^[[0;1;32m ^
> >>>>>>>
> >>>>>>
> >>>>
> >>
> ^[[0m^[[1m/var/folders/z3/ptkgr4kn4pv9v8g7s1fnr5mm0000gn/T/arrow-0.14.0.XXXXX.yYmSAqR5/apache-arrow-0.14.0/cpp/build/orc_ep-prefix/src/orc_ep/c++/src/io/OutputStream.hh:60:18:
> >>>>>>> ^[[0m^[[0;1;31merror: ^[[0m^[[1m'AllowsAliasing' marked 'override'
> >>>> but
> >>>>>>> does not override any member functions^[[0m
> >>>>>>> virtual bool AllowsAliasing() const override;
> >>>>>>> ^[[0;1;32m ^
> >>>>>>> ^[[0m2 errors generated.
> >>>>>>> make[5]: *** [c++/src/CMakeFiles/orc.dir/io/OutputStream.cc.o]
> >> Error 1
> >>>>>>> make[4]: *** [c++/src/CMakeFiles/orc.dir/all] Error 2
> >>>>>>> make[3]: *** [all] Error 2
> >>>>>>>
> >>>>>>> Not sure if this is due to my environment.
> >>>>>>>
> >>>>>>> Chao
> >>>>>>>
> >>>>>>> On Tue, Jul 2, 2019 at 6:54 PM Ravindra Pindikura <
> >>>> ravindra@dremio.com>
> >>>>>>> wrote:
> >>>>>>>
> >>>>>>>> ok, thanks !
> >>>>>>>>
> >>>>>>>> On Wed, Jul 3, 2019 at 7:10 AM Sutou Kouhei <ko...@clear-code.com>
> >>>> wrote:
> >>>>>>>>
> >>>>>>>>> Hi,
> >>>>>>>>>
> >>>>>>>>> Thanks for verifying this RC!
> >>>>>>>>>
> >>>>>>>>>> 2. The package doesn't seem to include gandiva
> >>>>>>>>>>
> >>>>>>>>>> is that intentional ? I'm fine if it is not included, just
> >> want
> >>>> to
> >>>>>>>>> confirm
> >>>>>>>>>> if that's expected.
> >>>>>>>>>
> >>>>>>>>> I think that this is caused by "-P arrow-jni" is missing in
> >>>>>>>>> 01-perform.sh:
> >>>>>>>>>
> >>>>>>>>>
> >> https://github.com/apache/arrow/pull/4717#issuecomment-506916189
> >>>>>>>>>
> >>>>>>>>> It's intentional for RC0.
> >>>>>>>>>
> >>>>>>>>> We'll fix this after RC0:
> >>>>>>>>>
> >>>>>>>>> https://issues.apache.org/jira/browse/ARROW-5786
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> Thanks,
> >>>>>>>>> --
> >>>>>>>>> kou
> >>>>>>>>>
> >>>>>>>>> In <
> >>>>>> CAPWBuG6wVuDwu7-Z8dYHq7SNuSAgAPpkdzkrQoF4DfnJ4Np5ag@mail.gmail.com>
> >>>>>>>>> "Re: [VOTE] Release Apache Arrow 0.14.0 - RC0" on Wed, 3 Jul
> >> 2019
> >>>>>>>>> 06:55:52 +0530,
> >>>>>>>>> Ravindra Pindikura <ra...@dremio.com> wrote:
> >>>>>>>>>
> >>>>>>>>>> I tried "./dev/release/verify-release-candidate.sh source
> >> 0.14.0
> >>>> 0"
> >>>>>> on
> >>>>>>>>> mac
> >>>>>>>>>> mojave.
> >>>>>>>>>>
> >>>>>>>>>> 1. I consistently get this error with flight tests
> >>>>>>>>>>
> >>>>>>>>>> [ERROR] Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time
> >>>>>> elapsed:
> >>>>>>>>>> 0.04 s <<< FAILURE! - in
> >>>> org.apache.arrow.flight.TestServerOptions
> >>>>>>>>>> [ERROR]
> >> domainSocket(org.apache.arrow.flight.TestServerOptions)
> >>>>>> Time
> >>>>>>>>>> elapsed: 0.04 s <<< ERROR!
> >>>>>>>>>> java.io.IOException: Failed to bind
> >>>>>>>>>> at
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>
> >>>>>>
> >>>>
> >>
> org.apache.arrow.flight.TestServerOptions.domainSocket(TestServerOptions.java:46)
> >>>>>>>>>> Caused by: io.netty.channel.unix.Errors$NativeIoException:
> >>>> bind(..)
> >>>>>>>>> failed:
> >>>>>>>>>> Address already in use
> >>>>>>>>>>
> >>>>>>>>>> Is there a workaround or gotcha for this ?
> >>>>>>>>>>
> >>>>>>>>>> 2. The package doesn't seem to include gandiva
> >>>>>>>>>>
> >>>>>>>>>> is that intentional ? I'm fine if it is not included, just
> >> want
> >>>> to
> >>>>>>>>> confirm
> >>>>>>>>>> if that's expected.
> >>>>>>>>>>
> >>>>>>>>>> On Wed, Jul 3, 2019 at 6:37 AM Sutou Kouhei <
> >> kou@clear-code.com>
> >>>>>>>> wrote:
> >>>>>>>>>>
> >>>>>>>>>>>> I tried again (Ubuntu 18.04):
> >>>>>>>>>>>> * source verification failed in gRPC configure step:
> >>>>>>>>>>>> Problem is, Ubuntu's c-ares does not provide any CMake
> >> files:
> >>>>>>>>>>>
> >>>>>>>>>>> Note: Adding -Dc-ares_SOURCE=BUNDLED CMake option is
> >>>>>>>>>>> workaround. We can use bundled c-ares automatically by
> >>>>>>>>>>> requiring c-ares's CMake config:
> >>>>>>>>>>>
> >>>>>>>>>>> https://github.com/apache/arrow/pull/4783
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>> Thanks,
> >>>>>>>>>>> --
> >>>>>>>>>>> kou
> >>>>>>>>>>>
> >>>>>>>>>>> In <7a...@python.org>
> >>>>>>>>>>> "Re: [VOTE] Release Apache Arrow 0.14.0 - RC0" on Tue, 2
> >> Jul
> >>>> 2019
> >>>>>>>>>>> 11:36:09 +0200,
> >>>>>>>>>>> Antoine Pitrou <an...@python.org> wrote:
> >>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>> I tried again (Ubuntu 18.04):
> >>>>>>>>>>>>
> >>>>>>>>>>>> * binaries verification succeeded
> >>>>>>>>>>>>
> >>>>>>>>>>>> * source verification failed in gRPC configure step:
> >>>>>>>>>>>>
> >>>>>>>>>>>> CMake Error at cmake/cares.cmake:38 (find_package):
> >>>>>>>>>>>> Could not find a package configuration file provided by
> >>>>>> "c-ares"
> >>>>>>>>> with
> >>>>>>>>>>> any
> >>>>>>>>>>>> of the following names:
> >>>>>>>>>>>>
> >>>>>>>>>>>> c-aresConfig.cmake
> >>>>>>>>>>>> c-ares-config.cmake
> >>>>>>>>>>>>
> >>>>>>>>>>>> Add the installation prefix of "c-ares" to
> >>>> CMAKE_PREFIX_PATH or
> >>>>>>>> set
> >>>>>>>>>>>> "c-ares_DIR" to a directory containing one of the above
> >>>>>> files. If
> >>>>>>>>>>> "c-ares"
> >>>>>>>>>>>> provides a separate development package or SDK, be sure
> >> it
> >>>> has
> >>>>>>>> been
> >>>>>>>>>>>> installed.
> >>>>>>>>>>>> Call Stack (most recent call first):
> >>>>>>>>>>>> CMakeLists.txt:139 (include)
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>> Problem is, Ubuntu's c-ares does not provide any CMake
> >> files:
> >>>>>>>>>>>>
> >>>>>>>>>>>> $ dpkg -L libc-ares-dev
> >>>>>>>>>>>> /.
> >>>>>>>>>>>> /usr
> >>>>>>>>>>>> /usr/include
> >>>>>>>>>>>> /usr/include/ares.h
> >>>>>>>>>>>> /usr/include/ares_build.h
> >>>>>>>>>>>> /usr/include/ares_dns.h
> >>>>>>>>>>>> /usr/include/ares_rules.h
> >>>>>>>>>>>> /usr/include/ares_version.h
> >>>>>>>>>>>> /usr/lib
> >>>>>>>>>>>> /usr/lib/x86_64-linux-gnu
> >>>>>>>>>>>> /usr/lib/x86_64-linux-gnu/libcares.a
> >>>>>>>>>>>> /usr/lib/x86_64-linux-gnu/pkgconfig
> >>>>>>>>>>>> /usr/lib/x86_64-linux-gnu/pkgconfig/libcares.pc
> >>>>>>>>>>>> /usr/share
> >>>>>>>>>>>> /usr/share/doc
> >>>>>>>>>>>> /usr/share/doc/libc-ares-dev
> >>>>>>>>>>>> /usr/share/doc/libc-ares-dev/NEWS.gz
> >>>>>>>>>>>> /usr/share/doc/libc-ares-dev/README.cares
> >>>>>>>>>>>> /usr/share/doc/libc-ares-dev/README.md
> >>>>>>>>>>>> /usr/share/doc/libc-ares-dev/copyright
> >>>>>>>>>>>> /usr/share/man
> >>>>>>>>>>>> /usr/share/man/man3
> >>>>>>>>>>>> [ snip man pages ]
> >>>>>>>>>>>> /usr/lib/x86_64-linux-gnu/libcares.so
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>> Regards
> >>>>>>>>>>>>
> >>>>>>>>>>>> Antoine.
> >>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> --
> >>>>>>>>>> Thanks and regards,
> >>>>>>>>>> Ravindra.
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> --
> >>>>>>>> Thanks and regards,
> >>>>>>>> Ravindra.
> >>>>>>>>
> >>>>>>
> >>>>
> >>>
> >>>
> >>> --
> >>>
> >>> Ryan Murray | Principal Consulting Engineer
> >>>
> >>> +447540852009 | rymurr@dremio.com
> >>>
> >>> <https://www.dremio.com/>
> >>> Check out our GitHub <https://www.github.com/dremio>, join our
> community
> >>> site <https://community.dremio.com/> & Download Dremio
> >>> <https://www.dremio.com/download>
> >>
> >
>
Re: [VOTE] Release Apache Arrow 0.14.0 - RC0
Posted by Antoine Pitrou <an...@python.org>.
I agree with Kou here. It's not a problem with the release per se, it's
a problem with the Flight code in git master. There is no regression
AFAICT, and we have not promised that Flight was stable and
production-ready yet.
If we're ok releasing with bugs such as this (Java unable to read back
union arrays?), then I think a Flight bug shouldn't hold a release.
https://issues.apache.org/jira/browse/ARROW-5231
Regards
Antoine.
Le 04/07/2019 à 14:46, Jacques Nadeau a écrit :
> Im disappointed in this response. When someone finds an issue with a
> release it should be triaged/validated rather than rushed past rather
> quickly and closing the vote before others can chime in on the issue.
>
> I'm now left voting -1 on a closed vote. In the future, let's have a
> discussion about issues like this. Your response and the close of the vote
> were unilateral and all happened while some of us were sleeping.
>
> On Wed, Jul 3, 2019, 10:47 PM Sutou Kouhei <ko...@clear-code.com> wrote:
>
>> Hi,
>>
>> Flight isn't stable yet. So Flight problem isn't a blocker
>> of this release. Could you open a JIRA issue for your
>> problem? We'll be able to fix it until 1.0.0.
>>
>>
>> Thanks,
>> --
>> kou
>>
>> In <CA...@mail.gmail.com>
>> "Re: [VOTE] Release Apache Arrow 0.14.0 - RC0" on Wed, 3 Jul 2019
>> 17:18:15 -0700,
>> Ryan Murray <ry...@dremio.com> wrote:
>>
>>> Hi All,
>>>
>>> I have noticed that a python Flight client can't authenticate to a Java
>>> Flight server while doing some testing today. I am trying to confirm if
>>> this is a bug in the flight implementation or in my own code. I thought I
>>> would report here as it could potentially be a blocker to this release.
>>>
>>> I will confirm and come back to you shortly.
>>>
>>> Best,
>>> Ryan
>>>
>>> On Wed, Jul 3, 2019 at 5:02 PM Sutou Kouhei <ko...@clear-code.com> wrote:
>>>
>>>> Thanks for confirming it!
>>>>
>>>> This will be solved by the pull request.
>>>>
>>>> In <CA...@mail.gmail.com>
>>>> "Re: [VOTE] Release Apache Arrow 0.14.0 - RC0" on Wed, 3 Jul 2019
>>>> 13:53:19 -0700,
>>>> Chao Sun <su...@apache.org> wrote:
>>>>
>>>>> Thanks Sutou. It is 2.5.0:
>>>>>
>>>>> $ protoc --version
>>>>> libprotoc 2.5.0
>>>>>
>>>>> Yes this is an old version, which is still used by Apache Hadoop.
>>>>>
>>>>> On Wed, Jul 3, 2019 at 1:27 PM Sutou Kouhei <ko...@clear-code.com>
>> wrote:
>>>>>
>>>>>> Thanks for verifying this RC!
>>>>>>
>>>>>> It seems that the C++ error is caused by old Protocol
>>>>>> Buffers. Could you show your system Protocol Buffers
>>>>>> version?
>>>>>>
>>>>>> https://github.com/apache/arrow/pull/4785 will resolve this
>>>>>> case. It prevents using old system Protocol Buffers.
>>>>>>
>>>>>> In <
>> CAF6oT1e8eMh1gWoOO+Uuq5z6AmwZPRfUuyV4C+w+crpievzLuw@mail.gmail.com>
>>>>>> "Re: [VOTE] Release Apache Arrow 0.14.0 - RC0" on Wed, 3 Jul 2019
>>>>>> 00:15:54 -0700,
>>>>>> Chao Sun <su...@apache.org> wrote:
>>>>>>
>>>>>>> On MacOS Mojave. Verified Rust and Go with
>> verify-release-candidate.sh
>>>>>> and
>>>>>>> they look good.
>>>>>>> I got the following error when verifying C++ though:
>>>>>>>
>>>>>>> [ 18%] Built target grpc_dependencies
>>>>>>> CMake Error at
>>>>>>>
>>>>>>
>>>>
>> /var/folders/z3/ptkgr4kn4pv9v8g7s1fnr5mm0000gn/T/arrow-0.14.0.XXXXX.yYmSAqR5/apache-arrow-0.14.0/cpp/build/orc_ep-prefix/src/orc_ep-stamp/orc_ep-build-RELEASE.cmake:49
>>>>>>> (message):
>>>>>>> Command failed: 2
>>>>>>> '/Library/Developer/CommandLineTools/usr/bin/make'
>>>>>>> See also
>>>>>>>
>>>>>>>
>>>>>>
>>>>
>> /var/folders/z3/ptkgr4kn4pv9v8g7s1fnr5mm0000gn/T/arrow-0.14.0.XXXXX.yYmSAqR5/apache-arrow-0.14.0/cpp/build/orc_ep-prefix/src/orc_ep-stamp/orc_ep-build-*.log
>>>>>>> make[2]: *** [orc_ep-prefix/src/orc_ep-stamp/orc_ep-build] Error 1
>>>>>>> make[1]: *** [CMakeFiles/orc_ep.dir/all] Error 2
>>>>>>>
>>>>>>> In orc_ep-build-err.log:
>>>>>>>
>>>>>>> In file included from
>>>>>>>
>>>>>>
>>>>
>> /var/folders/z3/ptkgr4kn4pv9v8g7s1fnr5mm0000gn/T/arrow-0.14.0.XXXXX.yYmSAqR5/apache-arrow-0.14.0/cpp/build/orc_ep-prefix/src/orc_ep/c++/src/io/OutputStream.cc:20:
>>>>>>>
>>>>>>
>>>>
>> ^[[1m/var/folders/z3/ptkgr4kn4pv9v8g7s1fnr5mm0000gn/T/arrow-0.14.0.XXXXX.yYmSAqR5/apache-arrow-0.14.0/cpp/build/orc_ep-prefix/src/orc_ep/c++/src/io/OutputStream.hh:59:18:
>>>>>>> ^[[0m^[[0;1;31merror: ^[[0m^[[1m'WriteAliasedRaw' marked
>>>> 'override'
>>>>>>> but does not override any member functions^[[0m
>>>>>>> virtual bool WriteAliasedRaw(const void * data, int size)
>>>> override;
>>>>>>> ^[[0;1;32m ^
>>>>>>>
>>>>>>
>>>>
>> ^[[0m^[[1m/var/folders/z3/ptkgr4kn4pv9v8g7s1fnr5mm0000gn/T/arrow-0.14.0.XXXXX.yYmSAqR5/apache-arrow-0.14.0/cpp/build/orc_ep-prefix/src/orc_ep/c++/src/io/OutputStream.hh:60:18:
>>>>>>> ^[[0m^[[0;1;31merror: ^[[0m^[[1m'AllowsAliasing' marked 'override'
>>>> but
>>>>>>> does not override any member functions^[[0m
>>>>>>> virtual bool AllowsAliasing() const override;
>>>>>>> ^[[0;1;32m ^
>>>>>>> ^[[0m2 errors generated.
>>>>>>> make[5]: *** [c++/src/CMakeFiles/orc.dir/io/OutputStream.cc.o]
>> Error 1
>>>>>>> make[4]: *** [c++/src/CMakeFiles/orc.dir/all] Error 2
>>>>>>> make[3]: *** [all] Error 2
>>>>>>>
>>>>>>> Not sure if this is due to my environment.
>>>>>>>
>>>>>>> Chao
>>>>>>>
>>>>>>> On Tue, Jul 2, 2019 at 6:54 PM Ravindra Pindikura <
>>>> ravindra@dremio.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> ok, thanks !
>>>>>>>>
>>>>>>>> On Wed, Jul 3, 2019 at 7:10 AM Sutou Kouhei <ko...@clear-code.com>
>>>> wrote:
>>>>>>>>
>>>>>>>>> Hi,
>>>>>>>>>
>>>>>>>>> Thanks for verifying this RC!
>>>>>>>>>
>>>>>>>>>> 2. The package doesn't seem to include gandiva
>>>>>>>>>>
>>>>>>>>>> is that intentional ? I'm fine if it is not included, just
>> want
>>>> to
>>>>>>>>> confirm
>>>>>>>>>> if that's expected.
>>>>>>>>>
>>>>>>>>> I think that this is caused by "-P arrow-jni" is missing in
>>>>>>>>> 01-perform.sh:
>>>>>>>>>
>>>>>>>>>
>> https://github.com/apache/arrow/pull/4717#issuecomment-506916189
>>>>>>>>>
>>>>>>>>> It's intentional for RC0.
>>>>>>>>>
>>>>>>>>> We'll fix this after RC0:
>>>>>>>>>
>>>>>>>>> https://issues.apache.org/jira/browse/ARROW-5786
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>> --
>>>>>>>>> kou
>>>>>>>>>
>>>>>>>>> In <
>>>>>> CAPWBuG6wVuDwu7-Z8dYHq7SNuSAgAPpkdzkrQoF4DfnJ4Np5ag@mail.gmail.com>
>>>>>>>>> "Re: [VOTE] Release Apache Arrow 0.14.0 - RC0" on Wed, 3 Jul
>> 2019
>>>>>>>>> 06:55:52 +0530,
>>>>>>>>> Ravindra Pindikura <ra...@dremio.com> wrote:
>>>>>>>>>
>>>>>>>>>> I tried "./dev/release/verify-release-candidate.sh source
>> 0.14.0
>>>> 0"
>>>>>> on
>>>>>>>>> mac
>>>>>>>>>> mojave.
>>>>>>>>>>
>>>>>>>>>> 1. I consistently get this error with flight tests
>>>>>>>>>>
>>>>>>>>>> [ERROR] Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time
>>>>>> elapsed:
>>>>>>>>>> 0.04 s <<< FAILURE! - in
>>>> org.apache.arrow.flight.TestServerOptions
>>>>>>>>>> [ERROR]
>> domainSocket(org.apache.arrow.flight.TestServerOptions)
>>>>>> Time
>>>>>>>>>> elapsed: 0.04 s <<< ERROR!
>>>>>>>>>> java.io.IOException: Failed to bind
>>>>>>>>>> at
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>
>>>>
>> org.apache.arrow.flight.TestServerOptions.domainSocket(TestServerOptions.java:46)
>>>>>>>>>> Caused by: io.netty.channel.unix.Errors$NativeIoException:
>>>> bind(..)
>>>>>>>>> failed:
>>>>>>>>>> Address already in use
>>>>>>>>>>
>>>>>>>>>> Is there a workaround or gotcha for this ?
>>>>>>>>>>
>>>>>>>>>> 2. The package doesn't seem to include gandiva
>>>>>>>>>>
>>>>>>>>>> is that intentional ? I'm fine if it is not included, just
>> want
>>>> to
>>>>>>>>> confirm
>>>>>>>>>> if that's expected.
>>>>>>>>>>
>>>>>>>>>> On Wed, Jul 3, 2019 at 6:37 AM Sutou Kouhei <
>> kou@clear-code.com>
>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>>>> I tried again (Ubuntu 18.04):
>>>>>>>>>>>> * source verification failed in gRPC configure step:
>>>>>>>>>>>> Problem is, Ubuntu's c-ares does not provide any CMake
>> files:
>>>>>>>>>>>
>>>>>>>>>>> Note: Adding -Dc-ares_SOURCE=BUNDLED CMake option is
>>>>>>>>>>> workaround. We can use bundled c-ares automatically by
>>>>>>>>>>> requiring c-ares's CMake config:
>>>>>>>>>>>
>>>>>>>>>>> https://github.com/apache/arrow/pull/4783
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Thanks,
>>>>>>>>>>> --
>>>>>>>>>>> kou
>>>>>>>>>>>
>>>>>>>>>>> In <7a...@python.org>
>>>>>>>>>>> "Re: [VOTE] Release Apache Arrow 0.14.0 - RC0" on Tue, 2
>> Jul
>>>> 2019
>>>>>>>>>>> 11:36:09 +0200,
>>>>>>>>>>> Antoine Pitrou <an...@python.org> wrote:
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> I tried again (Ubuntu 18.04):
>>>>>>>>>>>>
>>>>>>>>>>>> * binaries verification succeeded
>>>>>>>>>>>>
>>>>>>>>>>>> * source verification failed in gRPC configure step:
>>>>>>>>>>>>
>>>>>>>>>>>> CMake Error at cmake/cares.cmake:38 (find_package):
>>>>>>>>>>>> Could not find a package configuration file provided by
>>>>>> "c-ares"
>>>>>>>>> with
>>>>>>>>>>> any
>>>>>>>>>>>> of the following names:
>>>>>>>>>>>>
>>>>>>>>>>>> c-aresConfig.cmake
>>>>>>>>>>>> c-ares-config.cmake
>>>>>>>>>>>>
>>>>>>>>>>>> Add the installation prefix of "c-ares" to
>>>> CMAKE_PREFIX_PATH or
>>>>>>>> set
>>>>>>>>>>>> "c-ares_DIR" to a directory containing one of the above
>>>>>> files. If
>>>>>>>>>>> "c-ares"
>>>>>>>>>>>> provides a separate development package or SDK, be sure
>> it
>>>> has
>>>>>>>> been
>>>>>>>>>>>> installed.
>>>>>>>>>>>> Call Stack (most recent call first):
>>>>>>>>>>>> CMakeLists.txt:139 (include)
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Problem is, Ubuntu's c-ares does not provide any CMake
>> files:
>>>>>>>>>>>>
>>>>>>>>>>>> $ dpkg -L libc-ares-dev
>>>>>>>>>>>> /.
>>>>>>>>>>>> /usr
>>>>>>>>>>>> /usr/include
>>>>>>>>>>>> /usr/include/ares.h
>>>>>>>>>>>> /usr/include/ares_build.h
>>>>>>>>>>>> /usr/include/ares_dns.h
>>>>>>>>>>>> /usr/include/ares_rules.h
>>>>>>>>>>>> /usr/include/ares_version.h
>>>>>>>>>>>> /usr/lib
>>>>>>>>>>>> /usr/lib/x86_64-linux-gnu
>>>>>>>>>>>> /usr/lib/x86_64-linux-gnu/libcares.a
>>>>>>>>>>>> /usr/lib/x86_64-linux-gnu/pkgconfig
>>>>>>>>>>>> /usr/lib/x86_64-linux-gnu/pkgconfig/libcares.pc
>>>>>>>>>>>> /usr/share
>>>>>>>>>>>> /usr/share/doc
>>>>>>>>>>>> /usr/share/doc/libc-ares-dev
>>>>>>>>>>>> /usr/share/doc/libc-ares-dev/NEWS.gz
>>>>>>>>>>>> /usr/share/doc/libc-ares-dev/README.cares
>>>>>>>>>>>> /usr/share/doc/libc-ares-dev/README.md
>>>>>>>>>>>> /usr/share/doc/libc-ares-dev/copyright
>>>>>>>>>>>> /usr/share/man
>>>>>>>>>>>> /usr/share/man/man3
>>>>>>>>>>>> [ snip man pages ]
>>>>>>>>>>>> /usr/lib/x86_64-linux-gnu/libcares.so
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Regards
>>>>>>>>>>>>
>>>>>>>>>>>> Antoine.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> Thanks and regards,
>>>>>>>>>> Ravindra.
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> Thanks and regards,
>>>>>>>> Ravindra.
>>>>>>>>
>>>>>>
>>>>
>>>
>>>
>>> --
>>>
>>> Ryan Murray | Principal Consulting Engineer
>>>
>>> +447540852009 | rymurr@dremio.com
>>>
>>> <https://www.dremio.com/>
>>> Check out our GitHub <https://www.github.com/dremio>, join our community
>>> site <https://community.dremio.com/> & Download Dremio
>>> <https://www.dremio.com/download>
>>
>
Re: [VOTE] Release Apache Arrow 0.14.0 - RC0
Posted by Jacques Nadeau <ja...@apache.org>.
Im disappointed in this response. When someone finds an issue with a
release it should be triaged/validated rather than rushed past rather
quickly and closing the vote before others can chime in on the issue.
I'm now left voting -1 on a closed vote. In the future, let's have a
discussion about issues like this. Your response and the close of the vote
were unilateral and all happened while some of us were sleeping.
On Wed, Jul 3, 2019, 10:47 PM Sutou Kouhei <ko...@clear-code.com> wrote:
> Hi,
>
> Flight isn't stable yet. So Flight problem isn't a blocker
> of this release. Could you open a JIRA issue for your
> problem? We'll be able to fix it until 1.0.0.
>
>
> Thanks,
> --
> kou
>
> In <CA...@mail.gmail.com>
> "Re: [VOTE] Release Apache Arrow 0.14.0 - RC0" on Wed, 3 Jul 2019
> 17:18:15 -0700,
> Ryan Murray <ry...@dremio.com> wrote:
>
> > Hi All,
> >
> > I have noticed that a python Flight client can't authenticate to a Java
> > Flight server while doing some testing today. I am trying to confirm if
> > this is a bug in the flight implementation or in my own code. I thought I
> > would report here as it could potentially be a blocker to this release.
> >
> > I will confirm and come back to you shortly.
> >
> > Best,
> > Ryan
> >
> > On Wed, Jul 3, 2019 at 5:02 PM Sutou Kouhei <ko...@clear-code.com> wrote:
> >
> >> Thanks for confirming it!
> >>
> >> This will be solved by the pull request.
> >>
> >> In <CA...@mail.gmail.com>
> >> "Re: [VOTE] Release Apache Arrow 0.14.0 - RC0" on Wed, 3 Jul 2019
> >> 13:53:19 -0700,
> >> Chao Sun <su...@apache.org> wrote:
> >>
> >> > Thanks Sutou. It is 2.5.0:
> >> >
> >> > $ protoc --version
> >> > libprotoc 2.5.0
> >> >
> >> > Yes this is an old version, which is still used by Apache Hadoop.
> >> >
> >> > On Wed, Jul 3, 2019 at 1:27 PM Sutou Kouhei <ko...@clear-code.com>
> wrote:
> >> >
> >> >> Thanks for verifying this RC!
> >> >>
> >> >> It seems that the C++ error is caused by old Protocol
> >> >> Buffers. Could you show your system Protocol Buffers
> >> >> version?
> >> >>
> >> >> https://github.com/apache/arrow/pull/4785 will resolve this
> >> >> case. It prevents using old system Protocol Buffers.
> >> >>
> >> >> In <
> CAF6oT1e8eMh1gWoOO+Uuq5z6AmwZPRfUuyV4C+w+crpievzLuw@mail.gmail.com>
> >> >> "Re: [VOTE] Release Apache Arrow 0.14.0 - RC0" on Wed, 3 Jul 2019
> >> >> 00:15:54 -0700,
> >> >> Chao Sun <su...@apache.org> wrote:
> >> >>
> >> >> > On MacOS Mojave. Verified Rust and Go with
> verify-release-candidate.sh
> >> >> and
> >> >> > they look good.
> >> >> > I got the following error when verifying C++ though:
> >> >> >
> >> >> > [ 18%] Built target grpc_dependencies
> >> >> > CMake Error at
> >> >> >
> >> >>
> >>
> /var/folders/z3/ptkgr4kn4pv9v8g7s1fnr5mm0000gn/T/arrow-0.14.0.XXXXX.yYmSAqR5/apache-arrow-0.14.0/cpp/build/orc_ep-prefix/src/orc_ep-stamp/orc_ep-build-RELEASE.cmake:49
> >> >> > (message):
> >> >> > Command failed: 2
> >> >> > '/Library/Developer/CommandLineTools/usr/bin/make'
> >> >> > See also
> >> >> >
> >> >> >
> >> >>
> >>
> /var/folders/z3/ptkgr4kn4pv9v8g7s1fnr5mm0000gn/T/arrow-0.14.0.XXXXX.yYmSAqR5/apache-arrow-0.14.0/cpp/build/orc_ep-prefix/src/orc_ep-stamp/orc_ep-build-*.log
> >> >> > make[2]: *** [orc_ep-prefix/src/orc_ep-stamp/orc_ep-build] Error 1
> >> >> > make[1]: *** [CMakeFiles/orc_ep.dir/all] Error 2
> >> >> >
> >> >> > In orc_ep-build-err.log:
> >> >> >
> >> >> > In file included from
> >> >> >
> >> >>
> >>
> /var/folders/z3/ptkgr4kn4pv9v8g7s1fnr5mm0000gn/T/arrow-0.14.0.XXXXX.yYmSAqR5/apache-arrow-0.14.0/cpp/build/orc_ep-prefix/src/orc_ep/c++/src/io/OutputStream.cc:20:
> >> >> >
> >> >>
> >>
> ^[[1m/var/folders/z3/ptkgr4kn4pv9v8g7s1fnr5mm0000gn/T/arrow-0.14.0.XXXXX.yYmSAqR5/apache-arrow-0.14.0/cpp/build/orc_ep-prefix/src/orc_ep/c++/src/io/OutputStream.hh:59:18:
> >> >> > ^[[0m^[[0;1;31merror: ^[[0m^[[1m'WriteAliasedRaw' marked
> >> 'override'
> >> >> > but does not override any member functions^[[0m
> >> >> > virtual bool WriteAliasedRaw(const void * data, int size)
> >> override;
> >> >> > ^[[0;1;32m ^
> >> >> >
> >> >>
> >>
> ^[[0m^[[1m/var/folders/z3/ptkgr4kn4pv9v8g7s1fnr5mm0000gn/T/arrow-0.14.0.XXXXX.yYmSAqR5/apache-arrow-0.14.0/cpp/build/orc_ep-prefix/src/orc_ep/c++/src/io/OutputStream.hh:60:18:
> >> >> > ^[[0m^[[0;1;31merror: ^[[0m^[[1m'AllowsAliasing' marked 'override'
> >> but
> >> >> > does not override any member functions^[[0m
> >> >> > virtual bool AllowsAliasing() const override;
> >> >> > ^[[0;1;32m ^
> >> >> > ^[[0m2 errors generated.
> >> >> > make[5]: *** [c++/src/CMakeFiles/orc.dir/io/OutputStream.cc.o]
> Error 1
> >> >> > make[4]: *** [c++/src/CMakeFiles/orc.dir/all] Error 2
> >> >> > make[3]: *** [all] Error 2
> >> >> >
> >> >> > Not sure if this is due to my environment.
> >> >> >
> >> >> > Chao
> >> >> >
> >> >> > On Tue, Jul 2, 2019 at 6:54 PM Ravindra Pindikura <
> >> ravindra@dremio.com>
> >> >> > wrote:
> >> >> >
> >> >> >> ok, thanks !
> >> >> >>
> >> >> >> On Wed, Jul 3, 2019 at 7:10 AM Sutou Kouhei <ko...@clear-code.com>
> >> wrote:
> >> >> >>
> >> >> >> > Hi,
> >> >> >> >
> >> >> >> > Thanks for verifying this RC!
> >> >> >> >
> >> >> >> > > 2. The package doesn't seem to include gandiva
> >> >> >> > >
> >> >> >> > > is that intentional ? I'm fine if it is not included, just
> want
> >> to
> >> >> >> > confirm
> >> >> >> > > if that's expected.
> >> >> >> >
> >> >> >> > I think that this is caused by "-P arrow-jni" is missing in
> >> >> >> > 01-perform.sh:
> >> >> >> >
> >> >> >> >
> https://github.com/apache/arrow/pull/4717#issuecomment-506916189
> >> >> >> >
> >> >> >> > It's intentional for RC0.
> >> >> >> >
> >> >> >> > We'll fix this after RC0:
> >> >> >> >
> >> >> >> > https://issues.apache.org/jira/browse/ARROW-5786
> >> >> >> >
> >> >> >> >
> >> >> >> > Thanks,
> >> >> >> > --
> >> >> >> > kou
> >> >> >> >
> >> >> >> > In <
> >> >> CAPWBuG6wVuDwu7-Z8dYHq7SNuSAgAPpkdzkrQoF4DfnJ4Np5ag@mail.gmail.com>
> >> >> >> > "Re: [VOTE] Release Apache Arrow 0.14.0 - RC0" on Wed, 3 Jul
> 2019
> >> >> >> > 06:55:52 +0530,
> >> >> >> > Ravindra Pindikura <ra...@dremio.com> wrote:
> >> >> >> >
> >> >> >> > > I tried "./dev/release/verify-release-candidate.sh source
> 0.14.0
> >> 0"
> >> >> on
> >> >> >> > mac
> >> >> >> > > mojave.
> >> >> >> > >
> >> >> >> > > 1. I consistently get this error with flight tests
> >> >> >> > >
> >> >> >> > > [ERROR] Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time
> >> >> elapsed:
> >> >> >> > > 0.04 s <<< FAILURE! - in
> >> org.apache.arrow.flight.TestServerOptions
> >> >> >> > > [ERROR]
> domainSocket(org.apache.arrow.flight.TestServerOptions)
> >> >> Time
> >> >> >> > > elapsed: 0.04 s <<< ERROR!
> >> >> >> > > java.io.IOException: Failed to bind
> >> >> >> > > at
> >> >> >> > >
> >> >> >> >
> >> >> >>
> >> >>
> >>
> org.apache.arrow.flight.TestServerOptions.domainSocket(TestServerOptions.java:46)
> >> >> >> > > Caused by: io.netty.channel.unix.Errors$NativeIoException:
> >> bind(..)
> >> >> >> > failed:
> >> >> >> > > Address already in use
> >> >> >> > >
> >> >> >> > > Is there a workaround or gotcha for this ?
> >> >> >> > >
> >> >> >> > > 2. The package doesn't seem to include gandiva
> >> >> >> > >
> >> >> >> > > is that intentional ? I'm fine if it is not included, just
> want
> >> to
> >> >> >> > confirm
> >> >> >> > > if that's expected.
> >> >> >> > >
> >> >> >> > > On Wed, Jul 3, 2019 at 6:37 AM Sutou Kouhei <
> kou@clear-code.com>
> >> >> >> wrote:
> >> >> >> > >
> >> >> >> > >> > I tried again (Ubuntu 18.04):
> >> >> >> > >> > * source verification failed in gRPC configure step:
> >> >> >> > >> > Problem is, Ubuntu's c-ares does not provide any CMake
> files:
> >> >> >> > >>
> >> >> >> > >> Note: Adding -Dc-ares_SOURCE=BUNDLED CMake option is
> >> >> >> > >> workaround. We can use bundled c-ares automatically by
> >> >> >> > >> requiring c-ares's CMake config:
> >> >> >> > >>
> >> >> >> > >> https://github.com/apache/arrow/pull/4783
> >> >> >> > >>
> >> >> >> > >>
> >> >> >> > >> Thanks,
> >> >> >> > >> --
> >> >> >> > >> kou
> >> >> >> > >>
> >> >> >> > >> In <7a...@python.org>
> >> >> >> > >> "Re: [VOTE] Release Apache Arrow 0.14.0 - RC0" on Tue, 2
> Jul
> >> 2019
> >> >> >> > >> 11:36:09 +0200,
> >> >> >> > >> Antoine Pitrou <an...@python.org> wrote:
> >> >> >> > >>
> >> >> >> > >> >
> >> >> >> > >> > I tried again (Ubuntu 18.04):
> >> >> >> > >> >
> >> >> >> > >> > * binaries verification succeeded
> >> >> >> > >> >
> >> >> >> > >> > * source verification failed in gRPC configure step:
> >> >> >> > >> >
> >> >> >> > >> > CMake Error at cmake/cares.cmake:38 (find_package):
> >> >> >> > >> > Could not find a package configuration file provided by
> >> >> "c-ares"
> >> >> >> > with
> >> >> >> > >> any
> >> >> >> > >> > of the following names:
> >> >> >> > >> >
> >> >> >> > >> > c-aresConfig.cmake
> >> >> >> > >> > c-ares-config.cmake
> >> >> >> > >> >
> >> >> >> > >> > Add the installation prefix of "c-ares" to
> >> CMAKE_PREFIX_PATH or
> >> >> >> set
> >> >> >> > >> > "c-ares_DIR" to a directory containing one of the above
> >> >> files. If
> >> >> >> > >> "c-ares"
> >> >> >> > >> > provides a separate development package or SDK, be sure
> it
> >> has
> >> >> >> been
> >> >> >> > >> > installed.
> >> >> >> > >> > Call Stack (most recent call first):
> >> >> >> > >> > CMakeLists.txt:139 (include)
> >> >> >> > >> >
> >> >> >> > >> >
> >> >> >> > >> > Problem is, Ubuntu's c-ares does not provide any CMake
> files:
> >> >> >> > >> >
> >> >> >> > >> > $ dpkg -L libc-ares-dev
> >> >> >> > >> > /.
> >> >> >> > >> > /usr
> >> >> >> > >> > /usr/include
> >> >> >> > >> > /usr/include/ares.h
> >> >> >> > >> > /usr/include/ares_build.h
> >> >> >> > >> > /usr/include/ares_dns.h
> >> >> >> > >> > /usr/include/ares_rules.h
> >> >> >> > >> > /usr/include/ares_version.h
> >> >> >> > >> > /usr/lib
> >> >> >> > >> > /usr/lib/x86_64-linux-gnu
> >> >> >> > >> > /usr/lib/x86_64-linux-gnu/libcares.a
> >> >> >> > >> > /usr/lib/x86_64-linux-gnu/pkgconfig
> >> >> >> > >> > /usr/lib/x86_64-linux-gnu/pkgconfig/libcares.pc
> >> >> >> > >> > /usr/share
> >> >> >> > >> > /usr/share/doc
> >> >> >> > >> > /usr/share/doc/libc-ares-dev
> >> >> >> > >> > /usr/share/doc/libc-ares-dev/NEWS.gz
> >> >> >> > >> > /usr/share/doc/libc-ares-dev/README.cares
> >> >> >> > >> > /usr/share/doc/libc-ares-dev/README.md
> >> >> >> > >> > /usr/share/doc/libc-ares-dev/copyright
> >> >> >> > >> > /usr/share/man
> >> >> >> > >> > /usr/share/man/man3
> >> >> >> > >> > [ snip man pages ]
> >> >> >> > >> > /usr/lib/x86_64-linux-gnu/libcares.so
> >> >> >> > >> >
> >> >> >> > >> >
> >> >> >> > >> > Regards
> >> >> >> > >> >
> >> >> >> > >> > Antoine.
> >> >> >> > >>
> >> >> >> > >
> >> >> >> > >
> >> >> >> > > --
> >> >> >> > > Thanks and regards,
> >> >> >> > > Ravindra.
> >> >> >> >
> >> >> >>
> >> >> >>
> >> >> >> --
> >> >> >> Thanks and regards,
> >> >> >> Ravindra.
> >> >> >>
> >> >>
> >>
> >
> >
> > --
> >
> > Ryan Murray | Principal Consulting Engineer
> >
> > +447540852009 | rymurr@dremio.com
> >
> > <https://www.dremio.com/>
> > Check out our GitHub <https://www.github.com/dremio>, join our community
> > site <https://community.dremio.com/> & Download Dremio
> > <https://www.dremio.com/download>
>
Re: [VOTE] Release Apache Arrow 0.14.0 - RC0
Posted by Sutou Kouhei <ko...@clear-code.com>.
Hi,
Flight isn't stable yet. So Flight problem isn't a blocker
of this release. Could you open a JIRA issue for your
problem? We'll be able to fix it until 1.0.0.
Thanks,
--
kou
In <CA...@mail.gmail.com>
"Re: [VOTE] Release Apache Arrow 0.14.0 - RC0" on Wed, 3 Jul 2019 17:18:15 -0700,
Ryan Murray <ry...@dremio.com> wrote:
> Hi All,
>
> I have noticed that a python Flight client can't authenticate to a Java
> Flight server while doing some testing today. I am trying to confirm if
> this is a bug in the flight implementation or in my own code. I thought I
> would report here as it could potentially be a blocker to this release.
>
> I will confirm and come back to you shortly.
>
> Best,
> Ryan
>
> On Wed, Jul 3, 2019 at 5:02 PM Sutou Kouhei <ko...@clear-code.com> wrote:
>
>> Thanks for confirming it!
>>
>> This will be solved by the pull request.
>>
>> In <CA...@mail.gmail.com>
>> "Re: [VOTE] Release Apache Arrow 0.14.0 - RC0" on Wed, 3 Jul 2019
>> 13:53:19 -0700,
>> Chao Sun <su...@apache.org> wrote:
>>
>> > Thanks Sutou. It is 2.5.0:
>> >
>> > $ protoc --version
>> > libprotoc 2.5.0
>> >
>> > Yes this is an old version, which is still used by Apache Hadoop.
>> >
>> > On Wed, Jul 3, 2019 at 1:27 PM Sutou Kouhei <ko...@clear-code.com> wrote:
>> >
>> >> Thanks for verifying this RC!
>> >>
>> >> It seems that the C++ error is caused by old Protocol
>> >> Buffers. Could you show your system Protocol Buffers
>> >> version?
>> >>
>> >> https://github.com/apache/arrow/pull/4785 will resolve this
>> >> case. It prevents using old system Protocol Buffers.
>> >>
>> >> In <CA...@mail.gmail.com>
>> >> "Re: [VOTE] Release Apache Arrow 0.14.0 - RC0" on Wed, 3 Jul 2019
>> >> 00:15:54 -0700,
>> >> Chao Sun <su...@apache.org> wrote:
>> >>
>> >> > On MacOS Mojave. Verified Rust and Go with verify-release-candidate.sh
>> >> and
>> >> > they look good.
>> >> > I got the following error when verifying C++ though:
>> >> >
>> >> > [ 18%] Built target grpc_dependencies
>> >> > CMake Error at
>> >> >
>> >>
>> /var/folders/z3/ptkgr4kn4pv9v8g7s1fnr5mm0000gn/T/arrow-0.14.0.XXXXX.yYmSAqR5/apache-arrow-0.14.0/cpp/build/orc_ep-prefix/src/orc_ep-stamp/orc_ep-build-RELEASE.cmake:49
>> >> > (message):
>> >> > Command failed: 2
>> >> > '/Library/Developer/CommandLineTools/usr/bin/make'
>> >> > See also
>> >> >
>> >> >
>> >>
>> /var/folders/z3/ptkgr4kn4pv9v8g7s1fnr5mm0000gn/T/arrow-0.14.0.XXXXX.yYmSAqR5/apache-arrow-0.14.0/cpp/build/orc_ep-prefix/src/orc_ep-stamp/orc_ep-build-*.log
>> >> > make[2]: *** [orc_ep-prefix/src/orc_ep-stamp/orc_ep-build] Error 1
>> >> > make[1]: *** [CMakeFiles/orc_ep.dir/all] Error 2
>> >> >
>> >> > In orc_ep-build-err.log:
>> >> >
>> >> > In file included from
>> >> >
>> >>
>> /var/folders/z3/ptkgr4kn4pv9v8g7s1fnr5mm0000gn/T/arrow-0.14.0.XXXXX.yYmSAqR5/apache-arrow-0.14.0/cpp/build/orc_ep-prefix/src/orc_ep/c++/src/io/OutputStream.cc:20:
>> >> >
>> >>
>> ^[[1m/var/folders/z3/ptkgr4kn4pv9v8g7s1fnr5mm0000gn/T/arrow-0.14.0.XXXXX.yYmSAqR5/apache-arrow-0.14.0/cpp/build/orc_ep-prefix/src/orc_ep/c++/src/io/OutputStream.hh:59:18:
>> >> > ^[[0m^[[0;1;31merror: ^[[0m^[[1m'WriteAliasedRaw' marked
>> 'override'
>> >> > but does not override any member functions^[[0m
>> >> > virtual bool WriteAliasedRaw(const void * data, int size)
>> override;
>> >> > ^[[0;1;32m ^
>> >> >
>> >>
>> ^[[0m^[[1m/var/folders/z3/ptkgr4kn4pv9v8g7s1fnr5mm0000gn/T/arrow-0.14.0.XXXXX.yYmSAqR5/apache-arrow-0.14.0/cpp/build/orc_ep-prefix/src/orc_ep/c++/src/io/OutputStream.hh:60:18:
>> >> > ^[[0m^[[0;1;31merror: ^[[0m^[[1m'AllowsAliasing' marked 'override'
>> but
>> >> > does not override any member functions^[[0m
>> >> > virtual bool AllowsAliasing() const override;
>> >> > ^[[0;1;32m ^
>> >> > ^[[0m2 errors generated.
>> >> > make[5]: *** [c++/src/CMakeFiles/orc.dir/io/OutputStream.cc.o] Error 1
>> >> > make[4]: *** [c++/src/CMakeFiles/orc.dir/all] Error 2
>> >> > make[3]: *** [all] Error 2
>> >> >
>> >> > Not sure if this is due to my environment.
>> >> >
>> >> > Chao
>> >> >
>> >> > On Tue, Jul 2, 2019 at 6:54 PM Ravindra Pindikura <
>> ravindra@dremio.com>
>> >> > wrote:
>> >> >
>> >> >> ok, thanks !
>> >> >>
>> >> >> On Wed, Jul 3, 2019 at 7:10 AM Sutou Kouhei <ko...@clear-code.com>
>> wrote:
>> >> >>
>> >> >> > Hi,
>> >> >> >
>> >> >> > Thanks for verifying this RC!
>> >> >> >
>> >> >> > > 2. The package doesn't seem to include gandiva
>> >> >> > >
>> >> >> > > is that intentional ? I'm fine if it is not included, just want
>> to
>> >> >> > confirm
>> >> >> > > if that's expected.
>> >> >> >
>> >> >> > I think that this is caused by "-P arrow-jni" is missing in
>> >> >> > 01-perform.sh:
>> >> >> >
>> >> >> > https://github.com/apache/arrow/pull/4717#issuecomment-506916189
>> >> >> >
>> >> >> > It's intentional for RC0.
>> >> >> >
>> >> >> > We'll fix this after RC0:
>> >> >> >
>> >> >> > https://issues.apache.org/jira/browse/ARROW-5786
>> >> >> >
>> >> >> >
>> >> >> > Thanks,
>> >> >> > --
>> >> >> > kou
>> >> >> >
>> >> >> > In <
>> >> CAPWBuG6wVuDwu7-Z8dYHq7SNuSAgAPpkdzkrQoF4DfnJ4Np5ag@mail.gmail.com>
>> >> >> > "Re: [VOTE] Release Apache Arrow 0.14.0 - RC0" on Wed, 3 Jul 2019
>> >> >> > 06:55:52 +0530,
>> >> >> > Ravindra Pindikura <ra...@dremio.com> wrote:
>> >> >> >
>> >> >> > > I tried "./dev/release/verify-release-candidate.sh source 0.14.0
>> 0"
>> >> on
>> >> >> > mac
>> >> >> > > mojave.
>> >> >> > >
>> >> >> > > 1. I consistently get this error with flight tests
>> >> >> > >
>> >> >> > > [ERROR] Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time
>> >> elapsed:
>> >> >> > > 0.04 s <<< FAILURE! - in
>> org.apache.arrow.flight.TestServerOptions
>> >> >> > > [ERROR] domainSocket(org.apache.arrow.flight.TestServerOptions)
>> >> Time
>> >> >> > > elapsed: 0.04 s <<< ERROR!
>> >> >> > > java.io.IOException: Failed to bind
>> >> >> > > at
>> >> >> > >
>> >> >> >
>> >> >>
>> >>
>> org.apache.arrow.flight.TestServerOptions.domainSocket(TestServerOptions.java:46)
>> >> >> > > Caused by: io.netty.channel.unix.Errors$NativeIoException:
>> bind(..)
>> >> >> > failed:
>> >> >> > > Address already in use
>> >> >> > >
>> >> >> > > Is there a workaround or gotcha for this ?
>> >> >> > >
>> >> >> > > 2. The package doesn't seem to include gandiva
>> >> >> > >
>> >> >> > > is that intentional ? I'm fine if it is not included, just want
>> to
>> >> >> > confirm
>> >> >> > > if that's expected.
>> >> >> > >
>> >> >> > > On Wed, Jul 3, 2019 at 6:37 AM Sutou Kouhei <ko...@clear-code.com>
>> >> >> wrote:
>> >> >> > >
>> >> >> > >> > I tried again (Ubuntu 18.04):
>> >> >> > >> > * source verification failed in gRPC configure step:
>> >> >> > >> > Problem is, Ubuntu's c-ares does not provide any CMake files:
>> >> >> > >>
>> >> >> > >> Note: Adding -Dc-ares_SOURCE=BUNDLED CMake option is
>> >> >> > >> workaround. We can use bundled c-ares automatically by
>> >> >> > >> requiring c-ares's CMake config:
>> >> >> > >>
>> >> >> > >> https://github.com/apache/arrow/pull/4783
>> >> >> > >>
>> >> >> > >>
>> >> >> > >> Thanks,
>> >> >> > >> --
>> >> >> > >> kou
>> >> >> > >>
>> >> >> > >> In <7a...@python.org>
>> >> >> > >> "Re: [VOTE] Release Apache Arrow 0.14.0 - RC0" on Tue, 2 Jul
>> 2019
>> >> >> > >> 11:36:09 +0200,
>> >> >> > >> Antoine Pitrou <an...@python.org> wrote:
>> >> >> > >>
>> >> >> > >> >
>> >> >> > >> > I tried again (Ubuntu 18.04):
>> >> >> > >> >
>> >> >> > >> > * binaries verification succeeded
>> >> >> > >> >
>> >> >> > >> > * source verification failed in gRPC configure step:
>> >> >> > >> >
>> >> >> > >> > CMake Error at cmake/cares.cmake:38 (find_package):
>> >> >> > >> > Could not find a package configuration file provided by
>> >> "c-ares"
>> >> >> > with
>> >> >> > >> any
>> >> >> > >> > of the following names:
>> >> >> > >> >
>> >> >> > >> > c-aresConfig.cmake
>> >> >> > >> > c-ares-config.cmake
>> >> >> > >> >
>> >> >> > >> > Add the installation prefix of "c-ares" to
>> CMAKE_PREFIX_PATH or
>> >> >> set
>> >> >> > >> > "c-ares_DIR" to a directory containing one of the above
>> >> files. If
>> >> >> > >> "c-ares"
>> >> >> > >> > provides a separate development package or SDK, be sure it
>> has
>> >> >> been
>> >> >> > >> > installed.
>> >> >> > >> > Call Stack (most recent call first):
>> >> >> > >> > CMakeLists.txt:139 (include)
>> >> >> > >> >
>> >> >> > >> >
>> >> >> > >> > Problem is, Ubuntu's c-ares does not provide any CMake files:
>> >> >> > >> >
>> >> >> > >> > $ dpkg -L libc-ares-dev
>> >> >> > >> > /.
>> >> >> > >> > /usr
>> >> >> > >> > /usr/include
>> >> >> > >> > /usr/include/ares.h
>> >> >> > >> > /usr/include/ares_build.h
>> >> >> > >> > /usr/include/ares_dns.h
>> >> >> > >> > /usr/include/ares_rules.h
>> >> >> > >> > /usr/include/ares_version.h
>> >> >> > >> > /usr/lib
>> >> >> > >> > /usr/lib/x86_64-linux-gnu
>> >> >> > >> > /usr/lib/x86_64-linux-gnu/libcares.a
>> >> >> > >> > /usr/lib/x86_64-linux-gnu/pkgconfig
>> >> >> > >> > /usr/lib/x86_64-linux-gnu/pkgconfig/libcares.pc
>> >> >> > >> > /usr/share
>> >> >> > >> > /usr/share/doc
>> >> >> > >> > /usr/share/doc/libc-ares-dev
>> >> >> > >> > /usr/share/doc/libc-ares-dev/NEWS.gz
>> >> >> > >> > /usr/share/doc/libc-ares-dev/README.cares
>> >> >> > >> > /usr/share/doc/libc-ares-dev/README.md
>> >> >> > >> > /usr/share/doc/libc-ares-dev/copyright
>> >> >> > >> > /usr/share/man
>> >> >> > >> > /usr/share/man/man3
>> >> >> > >> > [ snip man pages ]
>> >> >> > >> > /usr/lib/x86_64-linux-gnu/libcares.so
>> >> >> > >> >
>> >> >> > >> >
>> >> >> > >> > Regards
>> >> >> > >> >
>> >> >> > >> > Antoine.
>> >> >> > >>
>> >> >> > >
>> >> >> > >
>> >> >> > > --
>> >> >> > > Thanks and regards,
>> >> >> > > Ravindra.
>> >> >> >
>> >> >>
>> >> >>
>> >> >> --
>> >> >> Thanks and regards,
>> >> >> Ravindra.
>> >> >>
>> >>
>>
>
>
> --
>
> Ryan Murray | Principal Consulting Engineer
>
> +447540852009 | rymurr@dremio.com
>
> <https://www.dremio.com/>
> Check out our GitHub <https://www.github.com/dremio>, join our community
> site <https://community.dremio.com/> & Download Dremio
> <https://www.dremio.com/download>
Re: [VOTE] Release Apache Arrow 0.14.0 - RC0
Posted by Ryan Murray <ry...@dremio.com>.
Hi All,
I have noticed that a python Flight client can't authenticate to a Java
Flight server while doing some testing today. I am trying to confirm if
this is a bug in the flight implementation or in my own code. I thought I
would report here as it could potentially be a blocker to this release.
I will confirm and come back to you shortly.
Best,
Ryan
On Wed, Jul 3, 2019 at 5:02 PM Sutou Kouhei <ko...@clear-code.com> wrote:
> Thanks for confirming it!
>
> This will be solved by the pull request.
>
> In <CA...@mail.gmail.com>
> "Re: [VOTE] Release Apache Arrow 0.14.0 - RC0" on Wed, 3 Jul 2019
> 13:53:19 -0700,
> Chao Sun <su...@apache.org> wrote:
>
> > Thanks Sutou. It is 2.5.0:
> >
> > $ protoc --version
> > libprotoc 2.5.0
> >
> > Yes this is an old version, which is still used by Apache Hadoop.
> >
> > On Wed, Jul 3, 2019 at 1:27 PM Sutou Kouhei <ko...@clear-code.com> wrote:
> >
> >> Thanks for verifying this RC!
> >>
> >> It seems that the C++ error is caused by old Protocol
> >> Buffers. Could you show your system Protocol Buffers
> >> version?
> >>
> >> https://github.com/apache/arrow/pull/4785 will resolve this
> >> case. It prevents using old system Protocol Buffers.
> >>
> >> In <CA...@mail.gmail.com>
> >> "Re: [VOTE] Release Apache Arrow 0.14.0 - RC0" on Wed, 3 Jul 2019
> >> 00:15:54 -0700,
> >> Chao Sun <su...@apache.org> wrote:
> >>
> >> > On MacOS Mojave. Verified Rust and Go with verify-release-candidate.sh
> >> and
> >> > they look good.
> >> > I got the following error when verifying C++ though:
> >> >
> >> > [ 18%] Built target grpc_dependencies
> >> > CMake Error at
> >> >
> >>
> /var/folders/z3/ptkgr4kn4pv9v8g7s1fnr5mm0000gn/T/arrow-0.14.0.XXXXX.yYmSAqR5/apache-arrow-0.14.0/cpp/build/orc_ep-prefix/src/orc_ep-stamp/orc_ep-build-RELEASE.cmake:49
> >> > (message):
> >> > Command failed: 2
> >> > '/Library/Developer/CommandLineTools/usr/bin/make'
> >> > See also
> >> >
> >> >
> >>
> /var/folders/z3/ptkgr4kn4pv9v8g7s1fnr5mm0000gn/T/arrow-0.14.0.XXXXX.yYmSAqR5/apache-arrow-0.14.0/cpp/build/orc_ep-prefix/src/orc_ep-stamp/orc_ep-build-*.log
> >> > make[2]: *** [orc_ep-prefix/src/orc_ep-stamp/orc_ep-build] Error 1
> >> > make[1]: *** [CMakeFiles/orc_ep.dir/all] Error 2
> >> >
> >> > In orc_ep-build-err.log:
> >> >
> >> > In file included from
> >> >
> >>
> /var/folders/z3/ptkgr4kn4pv9v8g7s1fnr5mm0000gn/T/arrow-0.14.0.XXXXX.yYmSAqR5/apache-arrow-0.14.0/cpp/build/orc_ep-prefix/src/orc_ep/c++/src/io/OutputStream.cc:20:
> >> >
> >>
> ^[[1m/var/folders/z3/ptkgr4kn4pv9v8g7s1fnr5mm0000gn/T/arrow-0.14.0.XXXXX.yYmSAqR5/apache-arrow-0.14.0/cpp/build/orc_ep-prefix/src/orc_ep/c++/src/io/OutputStream.hh:59:18:
> >> > ^[[0m^[[0;1;31merror: ^[[0m^[[1m'WriteAliasedRaw' marked
> 'override'
> >> > but does not override any member functions^[[0m
> >> > virtual bool WriteAliasedRaw(const void * data, int size)
> override;
> >> > ^[[0;1;32m ^
> >> >
> >>
> ^[[0m^[[1m/var/folders/z3/ptkgr4kn4pv9v8g7s1fnr5mm0000gn/T/arrow-0.14.0.XXXXX.yYmSAqR5/apache-arrow-0.14.0/cpp/build/orc_ep-prefix/src/orc_ep/c++/src/io/OutputStream.hh:60:18:
> >> > ^[[0m^[[0;1;31merror: ^[[0m^[[1m'AllowsAliasing' marked 'override'
> but
> >> > does not override any member functions^[[0m
> >> > virtual bool AllowsAliasing() const override;
> >> > ^[[0;1;32m ^
> >> > ^[[0m2 errors generated.
> >> > make[5]: *** [c++/src/CMakeFiles/orc.dir/io/OutputStream.cc.o] Error 1
> >> > make[4]: *** [c++/src/CMakeFiles/orc.dir/all] Error 2
> >> > make[3]: *** [all] Error 2
> >> >
> >> > Not sure if this is due to my environment.
> >> >
> >> > Chao
> >> >
> >> > On Tue, Jul 2, 2019 at 6:54 PM Ravindra Pindikura <
> ravindra@dremio.com>
> >> > wrote:
> >> >
> >> >> ok, thanks !
> >> >>
> >> >> On Wed, Jul 3, 2019 at 7:10 AM Sutou Kouhei <ko...@clear-code.com>
> wrote:
> >> >>
> >> >> > Hi,
> >> >> >
> >> >> > Thanks for verifying this RC!
> >> >> >
> >> >> > > 2. The package doesn't seem to include gandiva
> >> >> > >
> >> >> > > is that intentional ? I'm fine if it is not included, just want
> to
> >> >> > confirm
> >> >> > > if that's expected.
> >> >> >
> >> >> > I think that this is caused by "-P arrow-jni" is missing in
> >> >> > 01-perform.sh:
> >> >> >
> >> >> > https://github.com/apache/arrow/pull/4717#issuecomment-506916189
> >> >> >
> >> >> > It's intentional for RC0.
> >> >> >
> >> >> > We'll fix this after RC0:
> >> >> >
> >> >> > https://issues.apache.org/jira/browse/ARROW-5786
> >> >> >
> >> >> >
> >> >> > Thanks,
> >> >> > --
> >> >> > kou
> >> >> >
> >> >> > In <
> >> CAPWBuG6wVuDwu7-Z8dYHq7SNuSAgAPpkdzkrQoF4DfnJ4Np5ag@mail.gmail.com>
> >> >> > "Re: [VOTE] Release Apache Arrow 0.14.0 - RC0" on Wed, 3 Jul 2019
> >> >> > 06:55:52 +0530,
> >> >> > Ravindra Pindikura <ra...@dremio.com> wrote:
> >> >> >
> >> >> > > I tried "./dev/release/verify-release-candidate.sh source 0.14.0
> 0"
> >> on
> >> >> > mac
> >> >> > > mojave.
> >> >> > >
> >> >> > > 1. I consistently get this error with flight tests
> >> >> > >
> >> >> > > [ERROR] Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time
> >> elapsed:
> >> >> > > 0.04 s <<< FAILURE! - in
> org.apache.arrow.flight.TestServerOptions
> >> >> > > [ERROR] domainSocket(org.apache.arrow.flight.TestServerOptions)
> >> Time
> >> >> > > elapsed: 0.04 s <<< ERROR!
> >> >> > > java.io.IOException: Failed to bind
> >> >> > > at
> >> >> > >
> >> >> >
> >> >>
> >>
> org.apache.arrow.flight.TestServerOptions.domainSocket(TestServerOptions.java:46)
> >> >> > > Caused by: io.netty.channel.unix.Errors$NativeIoException:
> bind(..)
> >> >> > failed:
> >> >> > > Address already in use
> >> >> > >
> >> >> > > Is there a workaround or gotcha for this ?
> >> >> > >
> >> >> > > 2. The package doesn't seem to include gandiva
> >> >> > >
> >> >> > > is that intentional ? I'm fine if it is not included, just want
> to
> >> >> > confirm
> >> >> > > if that's expected.
> >> >> > >
> >> >> > > On Wed, Jul 3, 2019 at 6:37 AM Sutou Kouhei <ko...@clear-code.com>
> >> >> wrote:
> >> >> > >
> >> >> > >> > I tried again (Ubuntu 18.04):
> >> >> > >> > * source verification failed in gRPC configure step:
> >> >> > >> > Problem is, Ubuntu's c-ares does not provide any CMake files:
> >> >> > >>
> >> >> > >> Note: Adding -Dc-ares_SOURCE=BUNDLED CMake option is
> >> >> > >> workaround. We can use bundled c-ares automatically by
> >> >> > >> requiring c-ares's CMake config:
> >> >> > >>
> >> >> > >> https://github.com/apache/arrow/pull/4783
> >> >> > >>
> >> >> > >>
> >> >> > >> Thanks,
> >> >> > >> --
> >> >> > >> kou
> >> >> > >>
> >> >> > >> In <7a...@python.org>
> >> >> > >> "Re: [VOTE] Release Apache Arrow 0.14.0 - RC0" on Tue, 2 Jul
> 2019
> >> >> > >> 11:36:09 +0200,
> >> >> > >> Antoine Pitrou <an...@python.org> wrote:
> >> >> > >>
> >> >> > >> >
> >> >> > >> > I tried again (Ubuntu 18.04):
> >> >> > >> >
> >> >> > >> > * binaries verification succeeded
> >> >> > >> >
> >> >> > >> > * source verification failed in gRPC configure step:
> >> >> > >> >
> >> >> > >> > CMake Error at cmake/cares.cmake:38 (find_package):
> >> >> > >> > Could not find a package configuration file provided by
> >> "c-ares"
> >> >> > with
> >> >> > >> any
> >> >> > >> > of the following names:
> >> >> > >> >
> >> >> > >> > c-aresConfig.cmake
> >> >> > >> > c-ares-config.cmake
> >> >> > >> >
> >> >> > >> > Add the installation prefix of "c-ares" to
> CMAKE_PREFIX_PATH or
> >> >> set
> >> >> > >> > "c-ares_DIR" to a directory containing one of the above
> >> files. If
> >> >> > >> "c-ares"
> >> >> > >> > provides a separate development package or SDK, be sure it
> has
> >> >> been
> >> >> > >> > installed.
> >> >> > >> > Call Stack (most recent call first):
> >> >> > >> > CMakeLists.txt:139 (include)
> >> >> > >> >
> >> >> > >> >
> >> >> > >> > Problem is, Ubuntu's c-ares does not provide any CMake files:
> >> >> > >> >
> >> >> > >> > $ dpkg -L libc-ares-dev
> >> >> > >> > /.
> >> >> > >> > /usr
> >> >> > >> > /usr/include
> >> >> > >> > /usr/include/ares.h
> >> >> > >> > /usr/include/ares_build.h
> >> >> > >> > /usr/include/ares_dns.h
> >> >> > >> > /usr/include/ares_rules.h
> >> >> > >> > /usr/include/ares_version.h
> >> >> > >> > /usr/lib
> >> >> > >> > /usr/lib/x86_64-linux-gnu
> >> >> > >> > /usr/lib/x86_64-linux-gnu/libcares.a
> >> >> > >> > /usr/lib/x86_64-linux-gnu/pkgconfig
> >> >> > >> > /usr/lib/x86_64-linux-gnu/pkgconfig/libcares.pc
> >> >> > >> > /usr/share
> >> >> > >> > /usr/share/doc
> >> >> > >> > /usr/share/doc/libc-ares-dev
> >> >> > >> > /usr/share/doc/libc-ares-dev/NEWS.gz
> >> >> > >> > /usr/share/doc/libc-ares-dev/README.cares
> >> >> > >> > /usr/share/doc/libc-ares-dev/README.md
> >> >> > >> > /usr/share/doc/libc-ares-dev/copyright
> >> >> > >> > /usr/share/man
> >> >> > >> > /usr/share/man/man3
> >> >> > >> > [ snip man pages ]
> >> >> > >> > /usr/lib/x86_64-linux-gnu/libcares.so
> >> >> > >> >
> >> >> > >> >
> >> >> > >> > Regards
> >> >> > >> >
> >> >> > >> > Antoine.
> >> >> > >>
> >> >> > >
> >> >> > >
> >> >> > > --
> >> >> > > Thanks and regards,
> >> >> > > Ravindra.
> >> >> >
> >> >>
> >> >>
> >> >> --
> >> >> Thanks and regards,
> >> >> Ravindra.
> >> >>
> >>
>
--
Ryan Murray | Principal Consulting Engineer
+447540852009 | rymurr@dremio.com
<https://www.dremio.com/>
Check out our GitHub <https://www.github.com/dremio>, join our community
site <https://community.dremio.com/> & Download Dremio
<https://www.dremio.com/download>
Re: [VOTE] Release Apache Arrow 0.14.0 - RC0
Posted by Sutou Kouhei <ko...@clear-code.com>.
Thanks for confirming it!
This will be solved by the pull request.
In <CA...@mail.gmail.com>
"Re: [VOTE] Release Apache Arrow 0.14.0 - RC0" on Wed, 3 Jul 2019 13:53:19 -0700,
Chao Sun <su...@apache.org> wrote:
> Thanks Sutou. It is 2.5.0:
>
> $ protoc --version
> libprotoc 2.5.0
>
> Yes this is an old version, which is still used by Apache Hadoop.
>
> On Wed, Jul 3, 2019 at 1:27 PM Sutou Kouhei <ko...@clear-code.com> wrote:
>
>> Thanks for verifying this RC!
>>
>> It seems that the C++ error is caused by old Protocol
>> Buffers. Could you show your system Protocol Buffers
>> version?
>>
>> https://github.com/apache/arrow/pull/4785 will resolve this
>> case. It prevents using old system Protocol Buffers.
>>
>> In <CA...@mail.gmail.com>
>> "Re: [VOTE] Release Apache Arrow 0.14.0 - RC0" on Wed, 3 Jul 2019
>> 00:15:54 -0700,
>> Chao Sun <su...@apache.org> wrote:
>>
>> > On MacOS Mojave. Verified Rust and Go with verify-release-candidate.sh
>> and
>> > they look good.
>> > I got the following error when verifying C++ though:
>> >
>> > [ 18%] Built target grpc_dependencies
>> > CMake Error at
>> >
>> /var/folders/z3/ptkgr4kn4pv9v8g7s1fnr5mm0000gn/T/arrow-0.14.0.XXXXX.yYmSAqR5/apache-arrow-0.14.0/cpp/build/orc_ep-prefix/src/orc_ep-stamp/orc_ep-build-RELEASE.cmake:49
>> > (message):
>> > Command failed: 2
>> > '/Library/Developer/CommandLineTools/usr/bin/make'
>> > See also
>> >
>> >
>> /var/folders/z3/ptkgr4kn4pv9v8g7s1fnr5mm0000gn/T/arrow-0.14.0.XXXXX.yYmSAqR5/apache-arrow-0.14.0/cpp/build/orc_ep-prefix/src/orc_ep-stamp/orc_ep-build-*.log
>> > make[2]: *** [orc_ep-prefix/src/orc_ep-stamp/orc_ep-build] Error 1
>> > make[1]: *** [CMakeFiles/orc_ep.dir/all] Error 2
>> >
>> > In orc_ep-build-err.log:
>> >
>> > In file included from
>> >
>> /var/folders/z3/ptkgr4kn4pv9v8g7s1fnr5mm0000gn/T/arrow-0.14.0.XXXXX.yYmSAqR5/apache-arrow-0.14.0/cpp/build/orc_ep-prefix/src/orc_ep/c++/src/io/OutputStream.cc:20:
>> >
>> ^[[1m/var/folders/z3/ptkgr4kn4pv9v8g7s1fnr5mm0000gn/T/arrow-0.14.0.XXXXX.yYmSAqR5/apache-arrow-0.14.0/cpp/build/orc_ep-prefix/src/orc_ep/c++/src/io/OutputStream.hh:59:18:
>> > ^[[0m^[[0;1;31merror: ^[[0m^[[1m'WriteAliasedRaw' marked 'override'
>> > but does not override any member functions^[[0m
>> > virtual bool WriteAliasedRaw(const void * data, int size) override;
>> > ^[[0;1;32m ^
>> >
>> ^[[0m^[[1m/var/folders/z3/ptkgr4kn4pv9v8g7s1fnr5mm0000gn/T/arrow-0.14.0.XXXXX.yYmSAqR5/apache-arrow-0.14.0/cpp/build/orc_ep-prefix/src/orc_ep/c++/src/io/OutputStream.hh:60:18:
>> > ^[[0m^[[0;1;31merror: ^[[0m^[[1m'AllowsAliasing' marked 'override' but
>> > does not override any member functions^[[0m
>> > virtual bool AllowsAliasing() const override;
>> > ^[[0;1;32m ^
>> > ^[[0m2 errors generated.
>> > make[5]: *** [c++/src/CMakeFiles/orc.dir/io/OutputStream.cc.o] Error 1
>> > make[4]: *** [c++/src/CMakeFiles/orc.dir/all] Error 2
>> > make[3]: *** [all] Error 2
>> >
>> > Not sure if this is due to my environment.
>> >
>> > Chao
>> >
>> > On Tue, Jul 2, 2019 at 6:54 PM Ravindra Pindikura <ra...@dremio.com>
>> > wrote:
>> >
>> >> ok, thanks !
>> >>
>> >> On Wed, Jul 3, 2019 at 7:10 AM Sutou Kouhei <ko...@clear-code.com> wrote:
>> >>
>> >> > Hi,
>> >> >
>> >> > Thanks for verifying this RC!
>> >> >
>> >> > > 2. The package doesn't seem to include gandiva
>> >> > >
>> >> > > is that intentional ? I'm fine if it is not included, just want to
>> >> > confirm
>> >> > > if that's expected.
>> >> >
>> >> > I think that this is caused by "-P arrow-jni" is missing in
>> >> > 01-perform.sh:
>> >> >
>> >> > https://github.com/apache/arrow/pull/4717#issuecomment-506916189
>> >> >
>> >> > It's intentional for RC0.
>> >> >
>> >> > We'll fix this after RC0:
>> >> >
>> >> > https://issues.apache.org/jira/browse/ARROW-5786
>> >> >
>> >> >
>> >> > Thanks,
>> >> > --
>> >> > kou
>> >> >
>> >> > In <
>> CAPWBuG6wVuDwu7-Z8dYHq7SNuSAgAPpkdzkrQoF4DfnJ4Np5ag@mail.gmail.com>
>> >> > "Re: [VOTE] Release Apache Arrow 0.14.0 - RC0" on Wed, 3 Jul 2019
>> >> > 06:55:52 +0530,
>> >> > Ravindra Pindikura <ra...@dremio.com> wrote:
>> >> >
>> >> > > I tried "./dev/release/verify-release-candidate.sh source 0.14.0 0"
>> on
>> >> > mac
>> >> > > mojave.
>> >> > >
>> >> > > 1. I consistently get this error with flight tests
>> >> > >
>> >> > > [ERROR] Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time
>> elapsed:
>> >> > > 0.04 s <<< FAILURE! - in org.apache.arrow.flight.TestServerOptions
>> >> > > [ERROR] domainSocket(org.apache.arrow.flight.TestServerOptions)
>> Time
>> >> > > elapsed: 0.04 s <<< ERROR!
>> >> > > java.io.IOException: Failed to bind
>> >> > > at
>> >> > >
>> >> >
>> >>
>> org.apache.arrow.flight.TestServerOptions.domainSocket(TestServerOptions.java:46)
>> >> > > Caused by: io.netty.channel.unix.Errors$NativeIoException: bind(..)
>> >> > failed:
>> >> > > Address already in use
>> >> > >
>> >> > > Is there a workaround or gotcha for this ?
>> >> > >
>> >> > > 2. The package doesn't seem to include gandiva
>> >> > >
>> >> > > is that intentional ? I'm fine if it is not included, just want to
>> >> > confirm
>> >> > > if that's expected.
>> >> > >
>> >> > > On Wed, Jul 3, 2019 at 6:37 AM Sutou Kouhei <ko...@clear-code.com>
>> >> wrote:
>> >> > >
>> >> > >> > I tried again (Ubuntu 18.04):
>> >> > >> > * source verification failed in gRPC configure step:
>> >> > >> > Problem is, Ubuntu's c-ares does not provide any CMake files:
>> >> > >>
>> >> > >> Note: Adding -Dc-ares_SOURCE=BUNDLED CMake option is
>> >> > >> workaround. We can use bundled c-ares automatically by
>> >> > >> requiring c-ares's CMake config:
>> >> > >>
>> >> > >> https://github.com/apache/arrow/pull/4783
>> >> > >>
>> >> > >>
>> >> > >> Thanks,
>> >> > >> --
>> >> > >> kou
>> >> > >>
>> >> > >> In <7a...@python.org>
>> >> > >> "Re: [VOTE] Release Apache Arrow 0.14.0 - RC0" on Tue, 2 Jul 2019
>> >> > >> 11:36:09 +0200,
>> >> > >> Antoine Pitrou <an...@python.org> wrote:
>> >> > >>
>> >> > >> >
>> >> > >> > I tried again (Ubuntu 18.04):
>> >> > >> >
>> >> > >> > * binaries verification succeeded
>> >> > >> >
>> >> > >> > * source verification failed in gRPC configure step:
>> >> > >> >
>> >> > >> > CMake Error at cmake/cares.cmake:38 (find_package):
>> >> > >> > Could not find a package configuration file provided by
>> "c-ares"
>> >> > with
>> >> > >> any
>> >> > >> > of the following names:
>> >> > >> >
>> >> > >> > c-aresConfig.cmake
>> >> > >> > c-ares-config.cmake
>> >> > >> >
>> >> > >> > Add the installation prefix of "c-ares" to CMAKE_PREFIX_PATH or
>> >> set
>> >> > >> > "c-ares_DIR" to a directory containing one of the above
>> files. If
>> >> > >> "c-ares"
>> >> > >> > provides a separate development package or SDK, be sure it has
>> >> been
>> >> > >> > installed.
>> >> > >> > Call Stack (most recent call first):
>> >> > >> > CMakeLists.txt:139 (include)
>> >> > >> >
>> >> > >> >
>> >> > >> > Problem is, Ubuntu's c-ares does not provide any CMake files:
>> >> > >> >
>> >> > >> > $ dpkg -L libc-ares-dev
>> >> > >> > /.
>> >> > >> > /usr
>> >> > >> > /usr/include
>> >> > >> > /usr/include/ares.h
>> >> > >> > /usr/include/ares_build.h
>> >> > >> > /usr/include/ares_dns.h
>> >> > >> > /usr/include/ares_rules.h
>> >> > >> > /usr/include/ares_version.h
>> >> > >> > /usr/lib
>> >> > >> > /usr/lib/x86_64-linux-gnu
>> >> > >> > /usr/lib/x86_64-linux-gnu/libcares.a
>> >> > >> > /usr/lib/x86_64-linux-gnu/pkgconfig
>> >> > >> > /usr/lib/x86_64-linux-gnu/pkgconfig/libcares.pc
>> >> > >> > /usr/share
>> >> > >> > /usr/share/doc
>> >> > >> > /usr/share/doc/libc-ares-dev
>> >> > >> > /usr/share/doc/libc-ares-dev/NEWS.gz
>> >> > >> > /usr/share/doc/libc-ares-dev/README.cares
>> >> > >> > /usr/share/doc/libc-ares-dev/README.md
>> >> > >> > /usr/share/doc/libc-ares-dev/copyright
>> >> > >> > /usr/share/man
>> >> > >> > /usr/share/man/man3
>> >> > >> > [ snip man pages ]
>> >> > >> > /usr/lib/x86_64-linux-gnu/libcares.so
>> >> > >> >
>> >> > >> >
>> >> > >> > Regards
>> >> > >> >
>> >> > >> > Antoine.
>> >> > >>
>> >> > >
>> >> > >
>> >> > > --
>> >> > > Thanks and regards,
>> >> > > Ravindra.
>> >> >
>> >>
>> >>
>> >> --
>> >> Thanks and regards,
>> >> Ravindra.
>> >>
>>
Re: [VOTE] Release Apache Arrow 0.14.0 - RC0
Posted by Chao Sun <su...@apache.org>.
Thanks Sutou. It is 2.5.0:
$ protoc --version
libprotoc 2.5.0
Yes this is an old version, which is still used by Apache Hadoop.
On Wed, Jul 3, 2019 at 1:27 PM Sutou Kouhei <ko...@clear-code.com> wrote:
> Thanks for verifying this RC!
>
> It seems that the C++ error is caused by old Protocol
> Buffers. Could you show your system Protocol Buffers
> version?
>
> https://github.com/apache/arrow/pull/4785 will resolve this
> case. It prevents using old system Protocol Buffers.
>
> In <CA...@mail.gmail.com>
> "Re: [VOTE] Release Apache Arrow 0.14.0 - RC0" on Wed, 3 Jul 2019
> 00:15:54 -0700,
> Chao Sun <su...@apache.org> wrote:
>
> > On MacOS Mojave. Verified Rust and Go with verify-release-candidate.sh
> and
> > they look good.
> > I got the following error when verifying C++ though:
> >
> > [ 18%] Built target grpc_dependencies
> > CMake Error at
> >
> /var/folders/z3/ptkgr4kn4pv9v8g7s1fnr5mm0000gn/T/arrow-0.14.0.XXXXX.yYmSAqR5/apache-arrow-0.14.0/cpp/build/orc_ep-prefix/src/orc_ep-stamp/orc_ep-build-RELEASE.cmake:49
> > (message):
> > Command failed: 2
> > '/Library/Developer/CommandLineTools/usr/bin/make'
> > See also
> >
> >
> /var/folders/z3/ptkgr4kn4pv9v8g7s1fnr5mm0000gn/T/arrow-0.14.0.XXXXX.yYmSAqR5/apache-arrow-0.14.0/cpp/build/orc_ep-prefix/src/orc_ep-stamp/orc_ep-build-*.log
> > make[2]: *** [orc_ep-prefix/src/orc_ep-stamp/orc_ep-build] Error 1
> > make[1]: *** [CMakeFiles/orc_ep.dir/all] Error 2
> >
> > In orc_ep-build-err.log:
> >
> > In file included from
> >
> /var/folders/z3/ptkgr4kn4pv9v8g7s1fnr5mm0000gn/T/arrow-0.14.0.XXXXX.yYmSAqR5/apache-arrow-0.14.0/cpp/build/orc_ep-prefix/src/orc_ep/c++/src/io/OutputStream.cc:20:
> >
> ^[[1m/var/folders/z3/ptkgr4kn4pv9v8g7s1fnr5mm0000gn/T/arrow-0.14.0.XXXXX.yYmSAqR5/apache-arrow-0.14.0/cpp/build/orc_ep-prefix/src/orc_ep/c++/src/io/OutputStream.hh:59:18:
> > ^[[0m^[[0;1;31merror: ^[[0m^[[1m'WriteAliasedRaw' marked 'override'
> > but does not override any member functions^[[0m
> > virtual bool WriteAliasedRaw(const void * data, int size) override;
> > ^[[0;1;32m ^
> >
> ^[[0m^[[1m/var/folders/z3/ptkgr4kn4pv9v8g7s1fnr5mm0000gn/T/arrow-0.14.0.XXXXX.yYmSAqR5/apache-arrow-0.14.0/cpp/build/orc_ep-prefix/src/orc_ep/c++/src/io/OutputStream.hh:60:18:
> > ^[[0m^[[0;1;31merror: ^[[0m^[[1m'AllowsAliasing' marked 'override' but
> > does not override any member functions^[[0m
> > virtual bool AllowsAliasing() const override;
> > ^[[0;1;32m ^
> > ^[[0m2 errors generated.
> > make[5]: *** [c++/src/CMakeFiles/orc.dir/io/OutputStream.cc.o] Error 1
> > make[4]: *** [c++/src/CMakeFiles/orc.dir/all] Error 2
> > make[3]: *** [all] Error 2
> >
> > Not sure if this is due to my environment.
> >
> > Chao
> >
> > On Tue, Jul 2, 2019 at 6:54 PM Ravindra Pindikura <ra...@dremio.com>
> > wrote:
> >
> >> ok, thanks !
> >>
> >> On Wed, Jul 3, 2019 at 7:10 AM Sutou Kouhei <ko...@clear-code.com> wrote:
> >>
> >> > Hi,
> >> >
> >> > Thanks for verifying this RC!
> >> >
> >> > > 2. The package doesn't seem to include gandiva
> >> > >
> >> > > is that intentional ? I'm fine if it is not included, just want to
> >> > confirm
> >> > > if that's expected.
> >> >
> >> > I think that this is caused by "-P arrow-jni" is missing in
> >> > 01-perform.sh:
> >> >
> >> > https://github.com/apache/arrow/pull/4717#issuecomment-506916189
> >> >
> >> > It's intentional for RC0.
> >> >
> >> > We'll fix this after RC0:
> >> >
> >> > https://issues.apache.org/jira/browse/ARROW-5786
> >> >
> >> >
> >> > Thanks,
> >> > --
> >> > kou
> >> >
> >> > In <
> CAPWBuG6wVuDwu7-Z8dYHq7SNuSAgAPpkdzkrQoF4DfnJ4Np5ag@mail.gmail.com>
> >> > "Re: [VOTE] Release Apache Arrow 0.14.0 - RC0" on Wed, 3 Jul 2019
> >> > 06:55:52 +0530,
> >> > Ravindra Pindikura <ra...@dremio.com> wrote:
> >> >
> >> > > I tried "./dev/release/verify-release-candidate.sh source 0.14.0 0"
> on
> >> > mac
> >> > > mojave.
> >> > >
> >> > > 1. I consistently get this error with flight tests
> >> > >
> >> > > [ERROR] Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time
> elapsed:
> >> > > 0.04 s <<< FAILURE! - in org.apache.arrow.flight.TestServerOptions
> >> > > [ERROR] domainSocket(org.apache.arrow.flight.TestServerOptions)
> Time
> >> > > elapsed: 0.04 s <<< ERROR!
> >> > > java.io.IOException: Failed to bind
> >> > > at
> >> > >
> >> >
> >>
> org.apache.arrow.flight.TestServerOptions.domainSocket(TestServerOptions.java:46)
> >> > > Caused by: io.netty.channel.unix.Errors$NativeIoException: bind(..)
> >> > failed:
> >> > > Address already in use
> >> > >
> >> > > Is there a workaround or gotcha for this ?
> >> > >
> >> > > 2. The package doesn't seem to include gandiva
> >> > >
> >> > > is that intentional ? I'm fine if it is not included, just want to
> >> > confirm
> >> > > if that's expected.
> >> > >
> >> > > On Wed, Jul 3, 2019 at 6:37 AM Sutou Kouhei <ko...@clear-code.com>
> >> wrote:
> >> > >
> >> > >> > I tried again (Ubuntu 18.04):
> >> > >> > * source verification failed in gRPC configure step:
> >> > >> > Problem is, Ubuntu's c-ares does not provide any CMake files:
> >> > >>
> >> > >> Note: Adding -Dc-ares_SOURCE=BUNDLED CMake option is
> >> > >> workaround. We can use bundled c-ares automatically by
> >> > >> requiring c-ares's CMake config:
> >> > >>
> >> > >> https://github.com/apache/arrow/pull/4783
> >> > >>
> >> > >>
> >> > >> Thanks,
> >> > >> --
> >> > >> kou
> >> > >>
> >> > >> In <7a...@python.org>
> >> > >> "Re: [VOTE] Release Apache Arrow 0.14.0 - RC0" on Tue, 2 Jul 2019
> >> > >> 11:36:09 +0200,
> >> > >> Antoine Pitrou <an...@python.org> wrote:
> >> > >>
> >> > >> >
> >> > >> > I tried again (Ubuntu 18.04):
> >> > >> >
> >> > >> > * binaries verification succeeded
> >> > >> >
> >> > >> > * source verification failed in gRPC configure step:
> >> > >> >
> >> > >> > CMake Error at cmake/cares.cmake:38 (find_package):
> >> > >> > Could not find a package configuration file provided by
> "c-ares"
> >> > with
> >> > >> any
> >> > >> > of the following names:
> >> > >> >
> >> > >> > c-aresConfig.cmake
> >> > >> > c-ares-config.cmake
> >> > >> >
> >> > >> > Add the installation prefix of "c-ares" to CMAKE_PREFIX_PATH or
> >> set
> >> > >> > "c-ares_DIR" to a directory containing one of the above
> files. If
> >> > >> "c-ares"
> >> > >> > provides a separate development package or SDK, be sure it has
> >> been
> >> > >> > installed.
> >> > >> > Call Stack (most recent call first):
> >> > >> > CMakeLists.txt:139 (include)
> >> > >> >
> >> > >> >
> >> > >> > Problem is, Ubuntu's c-ares does not provide any CMake files:
> >> > >> >
> >> > >> > $ dpkg -L libc-ares-dev
> >> > >> > /.
> >> > >> > /usr
> >> > >> > /usr/include
> >> > >> > /usr/include/ares.h
> >> > >> > /usr/include/ares_build.h
> >> > >> > /usr/include/ares_dns.h
> >> > >> > /usr/include/ares_rules.h
> >> > >> > /usr/include/ares_version.h
> >> > >> > /usr/lib
> >> > >> > /usr/lib/x86_64-linux-gnu
> >> > >> > /usr/lib/x86_64-linux-gnu/libcares.a
> >> > >> > /usr/lib/x86_64-linux-gnu/pkgconfig
> >> > >> > /usr/lib/x86_64-linux-gnu/pkgconfig/libcares.pc
> >> > >> > /usr/share
> >> > >> > /usr/share/doc
> >> > >> > /usr/share/doc/libc-ares-dev
> >> > >> > /usr/share/doc/libc-ares-dev/NEWS.gz
> >> > >> > /usr/share/doc/libc-ares-dev/README.cares
> >> > >> > /usr/share/doc/libc-ares-dev/README.md
> >> > >> > /usr/share/doc/libc-ares-dev/copyright
> >> > >> > /usr/share/man
> >> > >> > /usr/share/man/man3
> >> > >> > [ snip man pages ]
> >> > >> > /usr/lib/x86_64-linux-gnu/libcares.so
> >> > >> >
> >> > >> >
> >> > >> > Regards
> >> > >> >
> >> > >> > Antoine.
> >> > >>
> >> > >
> >> > >
> >> > > --
> >> > > Thanks and regards,
> >> > > Ravindra.
> >> >
> >>
> >>
> >> --
> >> Thanks and regards,
> >> Ravindra.
> >>
>
Re: [VOTE] Release Apache Arrow 0.14.0 - RC0
Posted by Sutou Kouhei <ko...@clear-code.com>.
Thanks for verifying this RC!
It seems that the C++ error is caused by old Protocol
Buffers. Could you show your system Protocol Buffers
version?
https://github.com/apache/arrow/pull/4785 will resolve this
case. It prevents using old system Protocol Buffers.
In <CA...@mail.gmail.com>
"Re: [VOTE] Release Apache Arrow 0.14.0 - RC0" on Wed, 3 Jul 2019 00:15:54 -0700,
Chao Sun <su...@apache.org> wrote:
> On MacOS Mojave. Verified Rust and Go with verify-release-candidate.sh and
> they look good.
> I got the following error when verifying C++ though:
>
> [ 18%] Built target grpc_dependencies
> CMake Error at
> /var/folders/z3/ptkgr4kn4pv9v8g7s1fnr5mm0000gn/T/arrow-0.14.0.XXXXX.yYmSAqR5/apache-arrow-0.14.0/cpp/build/orc_ep-prefix/src/orc_ep-stamp/orc_ep-build-RELEASE.cmake:49
> (message):
> Command failed: 2
> '/Library/Developer/CommandLineTools/usr/bin/make'
> See also
>
> /var/folders/z3/ptkgr4kn4pv9v8g7s1fnr5mm0000gn/T/arrow-0.14.0.XXXXX.yYmSAqR5/apache-arrow-0.14.0/cpp/build/orc_ep-prefix/src/orc_ep-stamp/orc_ep-build-*.log
> make[2]: *** [orc_ep-prefix/src/orc_ep-stamp/orc_ep-build] Error 1
> make[1]: *** [CMakeFiles/orc_ep.dir/all] Error 2
>
> In orc_ep-build-err.log:
>
> In file included from
> /var/folders/z3/ptkgr4kn4pv9v8g7s1fnr5mm0000gn/T/arrow-0.14.0.XXXXX.yYmSAqR5/apache-arrow-0.14.0/cpp/build/orc_ep-prefix/src/orc_ep/c++/src/io/OutputStream.cc:20:
> ^[[1m/var/folders/z3/ptkgr4kn4pv9v8g7s1fnr5mm0000gn/T/arrow-0.14.0.XXXXX.yYmSAqR5/apache-arrow-0.14.0/cpp/build/orc_ep-prefix/src/orc_ep/c++/src/io/OutputStream.hh:59:18:
> ^[[0m^[[0;1;31merror: ^[[0m^[[1m'WriteAliasedRaw' marked 'override'
> but does not override any member functions^[[0m
> virtual bool WriteAliasedRaw(const void * data, int size) override;
> ^[[0;1;32m ^
> ^[[0m^[[1m/var/folders/z3/ptkgr4kn4pv9v8g7s1fnr5mm0000gn/T/arrow-0.14.0.XXXXX.yYmSAqR5/apache-arrow-0.14.0/cpp/build/orc_ep-prefix/src/orc_ep/c++/src/io/OutputStream.hh:60:18:
> ^[[0m^[[0;1;31merror: ^[[0m^[[1m'AllowsAliasing' marked 'override' but
> does not override any member functions^[[0m
> virtual bool AllowsAliasing() const override;
> ^[[0;1;32m ^
> ^[[0m2 errors generated.
> make[5]: *** [c++/src/CMakeFiles/orc.dir/io/OutputStream.cc.o] Error 1
> make[4]: *** [c++/src/CMakeFiles/orc.dir/all] Error 2
> make[3]: *** [all] Error 2
>
> Not sure if this is due to my environment.
>
> Chao
>
> On Tue, Jul 2, 2019 at 6:54 PM Ravindra Pindikura <ra...@dremio.com>
> wrote:
>
>> ok, thanks !
>>
>> On Wed, Jul 3, 2019 at 7:10 AM Sutou Kouhei <ko...@clear-code.com> wrote:
>>
>> > Hi,
>> >
>> > Thanks for verifying this RC!
>> >
>> > > 2. The package doesn't seem to include gandiva
>> > >
>> > > is that intentional ? I'm fine if it is not included, just want to
>> > confirm
>> > > if that's expected.
>> >
>> > I think that this is caused by "-P arrow-jni" is missing in
>> > 01-perform.sh:
>> >
>> > https://github.com/apache/arrow/pull/4717#issuecomment-506916189
>> >
>> > It's intentional for RC0.
>> >
>> > We'll fix this after RC0:
>> >
>> > https://issues.apache.org/jira/browse/ARROW-5786
>> >
>> >
>> > Thanks,
>> > --
>> > kou
>> >
>> > In <CA...@mail.gmail.com>
>> > "Re: [VOTE] Release Apache Arrow 0.14.0 - RC0" on Wed, 3 Jul 2019
>> > 06:55:52 +0530,
>> > Ravindra Pindikura <ra...@dremio.com> wrote:
>> >
>> > > I tried "./dev/release/verify-release-candidate.sh source 0.14.0 0" on
>> > mac
>> > > mojave.
>> > >
>> > > 1. I consistently get this error with flight tests
>> > >
>> > > [ERROR] Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed:
>> > > 0.04 s <<< FAILURE! - in org.apache.arrow.flight.TestServerOptions
>> > > [ERROR] domainSocket(org.apache.arrow.flight.TestServerOptions) Time
>> > > elapsed: 0.04 s <<< ERROR!
>> > > java.io.IOException: Failed to bind
>> > > at
>> > >
>> >
>> org.apache.arrow.flight.TestServerOptions.domainSocket(TestServerOptions.java:46)
>> > > Caused by: io.netty.channel.unix.Errors$NativeIoException: bind(..)
>> > failed:
>> > > Address already in use
>> > >
>> > > Is there a workaround or gotcha for this ?
>> > >
>> > > 2. The package doesn't seem to include gandiva
>> > >
>> > > is that intentional ? I'm fine if it is not included, just want to
>> > confirm
>> > > if that's expected.
>> > >
>> > > On Wed, Jul 3, 2019 at 6:37 AM Sutou Kouhei <ko...@clear-code.com>
>> wrote:
>> > >
>> > >> > I tried again (Ubuntu 18.04):
>> > >> > * source verification failed in gRPC configure step:
>> > >> > Problem is, Ubuntu's c-ares does not provide any CMake files:
>> > >>
>> > >> Note: Adding -Dc-ares_SOURCE=BUNDLED CMake option is
>> > >> workaround. We can use bundled c-ares automatically by
>> > >> requiring c-ares's CMake config:
>> > >>
>> > >> https://github.com/apache/arrow/pull/4783
>> > >>
>> > >>
>> > >> Thanks,
>> > >> --
>> > >> kou
>> > >>
>> > >> In <7a...@python.org>
>> > >> "Re: [VOTE] Release Apache Arrow 0.14.0 - RC0" on Tue, 2 Jul 2019
>> > >> 11:36:09 +0200,
>> > >> Antoine Pitrou <an...@python.org> wrote:
>> > >>
>> > >> >
>> > >> > I tried again (Ubuntu 18.04):
>> > >> >
>> > >> > * binaries verification succeeded
>> > >> >
>> > >> > * source verification failed in gRPC configure step:
>> > >> >
>> > >> > CMake Error at cmake/cares.cmake:38 (find_package):
>> > >> > Could not find a package configuration file provided by "c-ares"
>> > with
>> > >> any
>> > >> > of the following names:
>> > >> >
>> > >> > c-aresConfig.cmake
>> > >> > c-ares-config.cmake
>> > >> >
>> > >> > Add the installation prefix of "c-ares" to CMAKE_PREFIX_PATH or
>> set
>> > >> > "c-ares_DIR" to a directory containing one of the above files. If
>> > >> "c-ares"
>> > >> > provides a separate development package or SDK, be sure it has
>> been
>> > >> > installed.
>> > >> > Call Stack (most recent call first):
>> > >> > CMakeLists.txt:139 (include)
>> > >> >
>> > >> >
>> > >> > Problem is, Ubuntu's c-ares does not provide any CMake files:
>> > >> >
>> > >> > $ dpkg -L libc-ares-dev
>> > >> > /.
>> > >> > /usr
>> > >> > /usr/include
>> > >> > /usr/include/ares.h
>> > >> > /usr/include/ares_build.h
>> > >> > /usr/include/ares_dns.h
>> > >> > /usr/include/ares_rules.h
>> > >> > /usr/include/ares_version.h
>> > >> > /usr/lib
>> > >> > /usr/lib/x86_64-linux-gnu
>> > >> > /usr/lib/x86_64-linux-gnu/libcares.a
>> > >> > /usr/lib/x86_64-linux-gnu/pkgconfig
>> > >> > /usr/lib/x86_64-linux-gnu/pkgconfig/libcares.pc
>> > >> > /usr/share
>> > >> > /usr/share/doc
>> > >> > /usr/share/doc/libc-ares-dev
>> > >> > /usr/share/doc/libc-ares-dev/NEWS.gz
>> > >> > /usr/share/doc/libc-ares-dev/README.cares
>> > >> > /usr/share/doc/libc-ares-dev/README.md
>> > >> > /usr/share/doc/libc-ares-dev/copyright
>> > >> > /usr/share/man
>> > >> > /usr/share/man/man3
>> > >> > [ snip man pages ]
>> > >> > /usr/lib/x86_64-linux-gnu/libcares.so
>> > >> >
>> > >> >
>> > >> > Regards
>> > >> >
>> > >> > Antoine.
>> > >>
>> > >
>> > >
>> > > --
>> > > Thanks and regards,
>> > > Ravindra.
>> >
>>
>>
>> --
>> Thanks and regards,
>> Ravindra.
>>
Re: [VOTE] Release Apache Arrow 0.14.0 - RC0
Posted by Chao Sun <su...@apache.org>.
On MacOS Mojave. Verified Rust and Go with verify-release-candidate.sh and
they look good.
I got the following error when verifying C++ though:
[ 18%] Built target grpc_dependencies
CMake Error at
/var/folders/z3/ptkgr4kn4pv9v8g7s1fnr5mm0000gn/T/arrow-0.14.0.XXXXX.yYmSAqR5/apache-arrow-0.14.0/cpp/build/orc_ep-prefix/src/orc_ep-stamp/orc_ep-build-RELEASE.cmake:49
(message):
Command failed: 2
'/Library/Developer/CommandLineTools/usr/bin/make'
See also
/var/folders/z3/ptkgr4kn4pv9v8g7s1fnr5mm0000gn/T/arrow-0.14.0.XXXXX.yYmSAqR5/apache-arrow-0.14.0/cpp/build/orc_ep-prefix/src/orc_ep-stamp/orc_ep-build-*.log
make[2]: *** [orc_ep-prefix/src/orc_ep-stamp/orc_ep-build] Error 1
make[1]: *** [CMakeFiles/orc_ep.dir/all] Error 2
In orc_ep-build-err.log:
In file included from
/var/folders/z3/ptkgr4kn4pv9v8g7s1fnr5mm0000gn/T/arrow-0.14.0.XXXXX.yYmSAqR5/apache-arrow-0.14.0/cpp/build/orc_ep-prefix/src/orc_ep/c++/src/io/OutputStream.cc:20:
^[[1m/var/folders/z3/ptkgr4kn4pv9v8g7s1fnr5mm0000gn/T/arrow-0.14.0.XXXXX.yYmSAqR5/apache-arrow-0.14.0/cpp/build/orc_ep-prefix/src/orc_ep/c++/src/io/OutputStream.hh:59:18:
^[[0m^[[0;1;31merror: ^[[0m^[[1m'WriteAliasedRaw' marked 'override'
but does not override any member functions^[[0m
virtual bool WriteAliasedRaw(const void * data, int size) override;
^[[0;1;32m ^
^[[0m^[[1m/var/folders/z3/ptkgr4kn4pv9v8g7s1fnr5mm0000gn/T/arrow-0.14.0.XXXXX.yYmSAqR5/apache-arrow-0.14.0/cpp/build/orc_ep-prefix/src/orc_ep/c++/src/io/OutputStream.hh:60:18:
^[[0m^[[0;1;31merror: ^[[0m^[[1m'AllowsAliasing' marked 'override' but
does not override any member functions^[[0m
virtual bool AllowsAliasing() const override;
^[[0;1;32m ^
^[[0m2 errors generated.
make[5]: *** [c++/src/CMakeFiles/orc.dir/io/OutputStream.cc.o] Error 1
make[4]: *** [c++/src/CMakeFiles/orc.dir/all] Error 2
make[3]: *** [all] Error 2
Not sure if this is due to my environment.
Chao
On Tue, Jul 2, 2019 at 6:54 PM Ravindra Pindikura <ra...@dremio.com>
wrote:
> ok, thanks !
>
> On Wed, Jul 3, 2019 at 7:10 AM Sutou Kouhei <ko...@clear-code.com> wrote:
>
> > Hi,
> >
> > Thanks for verifying this RC!
> >
> > > 2. The package doesn't seem to include gandiva
> > >
> > > is that intentional ? I'm fine if it is not included, just want to
> > confirm
> > > if that's expected.
> >
> > I think that this is caused by "-P arrow-jni" is missing in
> > 01-perform.sh:
> >
> > https://github.com/apache/arrow/pull/4717#issuecomment-506916189
> >
> > It's intentional for RC0.
> >
> > We'll fix this after RC0:
> >
> > https://issues.apache.org/jira/browse/ARROW-5786
> >
> >
> > Thanks,
> > --
> > kou
> >
> > In <CA...@mail.gmail.com>
> > "Re: [VOTE] Release Apache Arrow 0.14.0 - RC0" on Wed, 3 Jul 2019
> > 06:55:52 +0530,
> > Ravindra Pindikura <ra...@dremio.com> wrote:
> >
> > > I tried "./dev/release/verify-release-candidate.sh source 0.14.0 0" on
> > mac
> > > mojave.
> > >
> > > 1. I consistently get this error with flight tests
> > >
> > > [ERROR] Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed:
> > > 0.04 s <<< FAILURE! - in org.apache.arrow.flight.TestServerOptions
> > > [ERROR] domainSocket(org.apache.arrow.flight.TestServerOptions) Time
> > > elapsed: 0.04 s <<< ERROR!
> > > java.io.IOException: Failed to bind
> > > at
> > >
> >
> org.apache.arrow.flight.TestServerOptions.domainSocket(TestServerOptions.java:46)
> > > Caused by: io.netty.channel.unix.Errors$NativeIoException: bind(..)
> > failed:
> > > Address already in use
> > >
> > > Is there a workaround or gotcha for this ?
> > >
> > > 2. The package doesn't seem to include gandiva
> > >
> > > is that intentional ? I'm fine if it is not included, just want to
> > confirm
> > > if that's expected.
> > >
> > > On Wed, Jul 3, 2019 at 6:37 AM Sutou Kouhei <ko...@clear-code.com>
> wrote:
> > >
> > >> > I tried again (Ubuntu 18.04):
> > >> > * source verification failed in gRPC configure step:
> > >> > Problem is, Ubuntu's c-ares does not provide any CMake files:
> > >>
> > >> Note: Adding -Dc-ares_SOURCE=BUNDLED CMake option is
> > >> workaround. We can use bundled c-ares automatically by
> > >> requiring c-ares's CMake config:
> > >>
> > >> https://github.com/apache/arrow/pull/4783
> > >>
> > >>
> > >> Thanks,
> > >> --
> > >> kou
> > >>
> > >> In <7a...@python.org>
> > >> "Re: [VOTE] Release Apache Arrow 0.14.0 - RC0" on Tue, 2 Jul 2019
> > >> 11:36:09 +0200,
> > >> Antoine Pitrou <an...@python.org> wrote:
> > >>
> > >> >
> > >> > I tried again (Ubuntu 18.04):
> > >> >
> > >> > * binaries verification succeeded
> > >> >
> > >> > * source verification failed in gRPC configure step:
> > >> >
> > >> > CMake Error at cmake/cares.cmake:38 (find_package):
> > >> > Could not find a package configuration file provided by "c-ares"
> > with
> > >> any
> > >> > of the following names:
> > >> >
> > >> > c-aresConfig.cmake
> > >> > c-ares-config.cmake
> > >> >
> > >> > Add the installation prefix of "c-ares" to CMAKE_PREFIX_PATH or
> set
> > >> > "c-ares_DIR" to a directory containing one of the above files. If
> > >> "c-ares"
> > >> > provides a separate development package or SDK, be sure it has
> been
> > >> > installed.
> > >> > Call Stack (most recent call first):
> > >> > CMakeLists.txt:139 (include)
> > >> >
> > >> >
> > >> > Problem is, Ubuntu's c-ares does not provide any CMake files:
> > >> >
> > >> > $ dpkg -L libc-ares-dev
> > >> > /.
> > >> > /usr
> > >> > /usr/include
> > >> > /usr/include/ares.h
> > >> > /usr/include/ares_build.h
> > >> > /usr/include/ares_dns.h
> > >> > /usr/include/ares_rules.h
> > >> > /usr/include/ares_version.h
> > >> > /usr/lib
> > >> > /usr/lib/x86_64-linux-gnu
> > >> > /usr/lib/x86_64-linux-gnu/libcares.a
> > >> > /usr/lib/x86_64-linux-gnu/pkgconfig
> > >> > /usr/lib/x86_64-linux-gnu/pkgconfig/libcares.pc
> > >> > /usr/share
> > >> > /usr/share/doc
> > >> > /usr/share/doc/libc-ares-dev
> > >> > /usr/share/doc/libc-ares-dev/NEWS.gz
> > >> > /usr/share/doc/libc-ares-dev/README.cares
> > >> > /usr/share/doc/libc-ares-dev/README.md
> > >> > /usr/share/doc/libc-ares-dev/copyright
> > >> > /usr/share/man
> > >> > /usr/share/man/man3
> > >> > [ snip man pages ]
> > >> > /usr/lib/x86_64-linux-gnu/libcares.so
> > >> >
> > >> >
> > >> > Regards
> > >> >
> > >> > Antoine.
> > >>
> > >
> > >
> > > --
> > > Thanks and regards,
> > > Ravindra.
> >
>
>
> --
> Thanks and regards,
> Ravindra.
>
Re: [VOTE] Release Apache Arrow 0.14.0 - RC0
Posted by Ravindra Pindikura <ra...@dremio.com>.
ok, thanks !
On Wed, Jul 3, 2019 at 7:10 AM Sutou Kouhei <ko...@clear-code.com> wrote:
> Hi,
>
> Thanks for verifying this RC!
>
> > 2. The package doesn't seem to include gandiva
> >
> > is that intentional ? I'm fine if it is not included, just want to
> confirm
> > if that's expected.
>
> I think that this is caused by "-P arrow-jni" is missing in
> 01-perform.sh:
>
> https://github.com/apache/arrow/pull/4717#issuecomment-506916189
>
> It's intentional for RC0.
>
> We'll fix this after RC0:
>
> https://issues.apache.org/jira/browse/ARROW-5786
>
>
> Thanks,
> --
> kou
>
> In <CA...@mail.gmail.com>
> "Re: [VOTE] Release Apache Arrow 0.14.0 - RC0" on Wed, 3 Jul 2019
> 06:55:52 +0530,
> Ravindra Pindikura <ra...@dremio.com> wrote:
>
> > I tried "./dev/release/verify-release-candidate.sh source 0.14.0 0" on
> mac
> > mojave.
> >
> > 1. I consistently get this error with flight tests
> >
> > [ERROR] Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed:
> > 0.04 s <<< FAILURE! - in org.apache.arrow.flight.TestServerOptions
> > [ERROR] domainSocket(org.apache.arrow.flight.TestServerOptions) Time
> > elapsed: 0.04 s <<< ERROR!
> > java.io.IOException: Failed to bind
> > at
> >
> org.apache.arrow.flight.TestServerOptions.domainSocket(TestServerOptions.java:46)
> > Caused by: io.netty.channel.unix.Errors$NativeIoException: bind(..)
> failed:
> > Address already in use
> >
> > Is there a workaround or gotcha for this ?
> >
> > 2. The package doesn't seem to include gandiva
> >
> > is that intentional ? I'm fine if it is not included, just want to
> confirm
> > if that's expected.
> >
> > On Wed, Jul 3, 2019 at 6:37 AM Sutou Kouhei <ko...@clear-code.com> wrote:
> >
> >> > I tried again (Ubuntu 18.04):
> >> > * source verification failed in gRPC configure step:
> >> > Problem is, Ubuntu's c-ares does not provide any CMake files:
> >>
> >> Note: Adding -Dc-ares_SOURCE=BUNDLED CMake option is
> >> workaround. We can use bundled c-ares automatically by
> >> requiring c-ares's CMake config:
> >>
> >> https://github.com/apache/arrow/pull/4783
> >>
> >>
> >> Thanks,
> >> --
> >> kou
> >>
> >> In <7a...@python.org>
> >> "Re: [VOTE] Release Apache Arrow 0.14.0 - RC0" on Tue, 2 Jul 2019
> >> 11:36:09 +0200,
> >> Antoine Pitrou <an...@python.org> wrote:
> >>
> >> >
> >> > I tried again (Ubuntu 18.04):
> >> >
> >> > * binaries verification succeeded
> >> >
> >> > * source verification failed in gRPC configure step:
> >> >
> >> > CMake Error at cmake/cares.cmake:38 (find_package):
> >> > Could not find a package configuration file provided by "c-ares"
> with
> >> any
> >> > of the following names:
> >> >
> >> > c-aresConfig.cmake
> >> > c-ares-config.cmake
> >> >
> >> > Add the installation prefix of "c-ares" to CMAKE_PREFIX_PATH or set
> >> > "c-ares_DIR" to a directory containing one of the above files. If
> >> "c-ares"
> >> > provides a separate development package or SDK, be sure it has been
> >> > installed.
> >> > Call Stack (most recent call first):
> >> > CMakeLists.txt:139 (include)
> >> >
> >> >
> >> > Problem is, Ubuntu's c-ares does not provide any CMake files:
> >> >
> >> > $ dpkg -L libc-ares-dev
> >> > /.
> >> > /usr
> >> > /usr/include
> >> > /usr/include/ares.h
> >> > /usr/include/ares_build.h
> >> > /usr/include/ares_dns.h
> >> > /usr/include/ares_rules.h
> >> > /usr/include/ares_version.h
> >> > /usr/lib
> >> > /usr/lib/x86_64-linux-gnu
> >> > /usr/lib/x86_64-linux-gnu/libcares.a
> >> > /usr/lib/x86_64-linux-gnu/pkgconfig
> >> > /usr/lib/x86_64-linux-gnu/pkgconfig/libcares.pc
> >> > /usr/share
> >> > /usr/share/doc
> >> > /usr/share/doc/libc-ares-dev
> >> > /usr/share/doc/libc-ares-dev/NEWS.gz
> >> > /usr/share/doc/libc-ares-dev/README.cares
> >> > /usr/share/doc/libc-ares-dev/README.md
> >> > /usr/share/doc/libc-ares-dev/copyright
> >> > /usr/share/man
> >> > /usr/share/man/man3
> >> > [ snip man pages ]
> >> > /usr/lib/x86_64-linux-gnu/libcares.so
> >> >
> >> >
> >> > Regards
> >> >
> >> > Antoine.
> >>
> >
> >
> > --
> > Thanks and regards,
> > Ravindra.
>
--
Thanks and regards,
Ravindra.
Re: [VOTE] Release Apache Arrow 0.14.0 - RC0
Posted by Sutou Kouhei <ko...@clear-code.com>.
Hi,
Thanks for verifying this RC!
> 2. The package doesn't seem to include gandiva
>
> is that intentional ? I'm fine if it is not included, just want to confirm
> if that's expected.
I think that this is caused by "-P arrow-jni" is missing in
01-perform.sh:
https://github.com/apache/arrow/pull/4717#issuecomment-506916189
It's intentional for RC0.
We'll fix this after RC0:
https://issues.apache.org/jira/browse/ARROW-5786
Thanks,
--
kou
In <CA...@mail.gmail.com>
"Re: [VOTE] Release Apache Arrow 0.14.0 - RC0" on Wed, 3 Jul 2019 06:55:52 +0530,
Ravindra Pindikura <ra...@dremio.com> wrote:
> I tried "./dev/release/verify-release-candidate.sh source 0.14.0 0" on mac
> mojave.
>
> 1. I consistently get this error with flight tests
>
> [ERROR] Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed:
> 0.04 s <<< FAILURE! - in org.apache.arrow.flight.TestServerOptions
> [ERROR] domainSocket(org.apache.arrow.flight.TestServerOptions) Time
> elapsed: 0.04 s <<< ERROR!
> java.io.IOException: Failed to bind
> at
> org.apache.arrow.flight.TestServerOptions.domainSocket(TestServerOptions.java:46)
> Caused by: io.netty.channel.unix.Errors$NativeIoException: bind(..) failed:
> Address already in use
>
> Is there a workaround or gotcha for this ?
>
> 2. The package doesn't seem to include gandiva
>
> is that intentional ? I'm fine if it is not included, just want to confirm
> if that's expected.
>
> On Wed, Jul 3, 2019 at 6:37 AM Sutou Kouhei <ko...@clear-code.com> wrote:
>
>> > I tried again (Ubuntu 18.04):
>> > * source verification failed in gRPC configure step:
>> > Problem is, Ubuntu's c-ares does not provide any CMake files:
>>
>> Note: Adding -Dc-ares_SOURCE=BUNDLED CMake option is
>> workaround. We can use bundled c-ares automatically by
>> requiring c-ares's CMake config:
>>
>> https://github.com/apache/arrow/pull/4783
>>
>>
>> Thanks,
>> --
>> kou
>>
>> In <7a...@python.org>
>> "Re: [VOTE] Release Apache Arrow 0.14.0 - RC0" on Tue, 2 Jul 2019
>> 11:36:09 +0200,
>> Antoine Pitrou <an...@python.org> wrote:
>>
>> >
>> > I tried again (Ubuntu 18.04):
>> >
>> > * binaries verification succeeded
>> >
>> > * source verification failed in gRPC configure step:
>> >
>> > CMake Error at cmake/cares.cmake:38 (find_package):
>> > Could not find a package configuration file provided by "c-ares" with
>> any
>> > of the following names:
>> >
>> > c-aresConfig.cmake
>> > c-ares-config.cmake
>> >
>> > Add the installation prefix of "c-ares" to CMAKE_PREFIX_PATH or set
>> > "c-ares_DIR" to a directory containing one of the above files. If
>> "c-ares"
>> > provides a separate development package or SDK, be sure it has been
>> > installed.
>> > Call Stack (most recent call first):
>> > CMakeLists.txt:139 (include)
>> >
>> >
>> > Problem is, Ubuntu's c-ares does not provide any CMake files:
>> >
>> > $ dpkg -L libc-ares-dev
>> > /.
>> > /usr
>> > /usr/include
>> > /usr/include/ares.h
>> > /usr/include/ares_build.h
>> > /usr/include/ares_dns.h
>> > /usr/include/ares_rules.h
>> > /usr/include/ares_version.h
>> > /usr/lib
>> > /usr/lib/x86_64-linux-gnu
>> > /usr/lib/x86_64-linux-gnu/libcares.a
>> > /usr/lib/x86_64-linux-gnu/pkgconfig
>> > /usr/lib/x86_64-linux-gnu/pkgconfig/libcares.pc
>> > /usr/share
>> > /usr/share/doc
>> > /usr/share/doc/libc-ares-dev
>> > /usr/share/doc/libc-ares-dev/NEWS.gz
>> > /usr/share/doc/libc-ares-dev/README.cares
>> > /usr/share/doc/libc-ares-dev/README.md
>> > /usr/share/doc/libc-ares-dev/copyright
>> > /usr/share/man
>> > /usr/share/man/man3
>> > [ snip man pages ]
>> > /usr/lib/x86_64-linux-gnu/libcares.so
>> >
>> >
>> > Regards
>> >
>> > Antoine.
>>
>
>
> --
> Thanks and regards,
> Ravindra.
Re: [VOTE] Release Apache Arrow 0.14.0 - RC0
Posted by Ravindra Pindikura <ra...@dremio.com>.
I tried "./dev/release/verify-release-candidate.sh source 0.14.0 0" on mac
mojave.
1. I consistently get this error with flight tests
[ERROR] Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed:
0.04 s <<< FAILURE! - in org.apache.arrow.flight.TestServerOptions
[ERROR] domainSocket(org.apache.arrow.flight.TestServerOptions) Time
elapsed: 0.04 s <<< ERROR!
java.io.IOException: Failed to bind
at
org.apache.arrow.flight.TestServerOptions.domainSocket(TestServerOptions.java:46)
Caused by: io.netty.channel.unix.Errors$NativeIoException: bind(..) failed:
Address already in use
Is there a workaround or gotcha for this ?
2. The package doesn't seem to include gandiva
is that intentional ? I'm fine if it is not included, just want to confirm
if that's expected.
On Wed, Jul 3, 2019 at 6:37 AM Sutou Kouhei <ko...@clear-code.com> wrote:
> > I tried again (Ubuntu 18.04):
> > * source verification failed in gRPC configure step:
> > Problem is, Ubuntu's c-ares does not provide any CMake files:
>
> Note: Adding -Dc-ares_SOURCE=BUNDLED CMake option is
> workaround. We can use bundled c-ares automatically by
> requiring c-ares's CMake config:
>
> https://github.com/apache/arrow/pull/4783
>
>
> Thanks,
> --
> kou
>
> In <7a...@python.org>
> "Re: [VOTE] Release Apache Arrow 0.14.0 - RC0" on Tue, 2 Jul 2019
> 11:36:09 +0200,
> Antoine Pitrou <an...@python.org> wrote:
>
> >
> > I tried again (Ubuntu 18.04):
> >
> > * binaries verification succeeded
> >
> > * source verification failed in gRPC configure step:
> >
> > CMake Error at cmake/cares.cmake:38 (find_package):
> > Could not find a package configuration file provided by "c-ares" with
> any
> > of the following names:
> >
> > c-aresConfig.cmake
> > c-ares-config.cmake
> >
> > Add the installation prefix of "c-ares" to CMAKE_PREFIX_PATH or set
> > "c-ares_DIR" to a directory containing one of the above files. If
> "c-ares"
> > provides a separate development package or SDK, be sure it has been
> > installed.
> > Call Stack (most recent call first):
> > CMakeLists.txt:139 (include)
> >
> >
> > Problem is, Ubuntu's c-ares does not provide any CMake files:
> >
> > $ dpkg -L libc-ares-dev
> > /.
> > /usr
> > /usr/include
> > /usr/include/ares.h
> > /usr/include/ares_build.h
> > /usr/include/ares_dns.h
> > /usr/include/ares_rules.h
> > /usr/include/ares_version.h
> > /usr/lib
> > /usr/lib/x86_64-linux-gnu
> > /usr/lib/x86_64-linux-gnu/libcares.a
> > /usr/lib/x86_64-linux-gnu/pkgconfig
> > /usr/lib/x86_64-linux-gnu/pkgconfig/libcares.pc
> > /usr/share
> > /usr/share/doc
> > /usr/share/doc/libc-ares-dev
> > /usr/share/doc/libc-ares-dev/NEWS.gz
> > /usr/share/doc/libc-ares-dev/README.cares
> > /usr/share/doc/libc-ares-dev/README.md
> > /usr/share/doc/libc-ares-dev/copyright
> > /usr/share/man
> > /usr/share/man/man3
> > [ snip man pages ]
> > /usr/lib/x86_64-linux-gnu/libcares.so
> >
> >
> > Regards
> >
> > Antoine.
>
--
Thanks and regards,
Ravindra.
Re: [VOTE] Release Apache Arrow 0.14.0 - RC0
Posted by Sutou Kouhei <ko...@clear-code.com>.
> I tried again (Ubuntu 18.04):
> * source verification failed in gRPC configure step:
> Problem is, Ubuntu's c-ares does not provide any CMake files:
Note: Adding -Dc-ares_SOURCE=BUNDLED CMake option is
workaround. We can use bundled c-ares automatically by
requiring c-ares's CMake config:
https://github.com/apache/arrow/pull/4783
Thanks,
--
kou
In <7a...@python.org>
"Re: [VOTE] Release Apache Arrow 0.14.0 - RC0" on Tue, 2 Jul 2019 11:36:09 +0200,
Antoine Pitrou <an...@python.org> wrote:
>
> I tried again (Ubuntu 18.04):
>
> * binaries verification succeeded
>
> * source verification failed in gRPC configure step:
>
> CMake Error at cmake/cares.cmake:38 (find_package):
> Could not find a package configuration file provided by "c-ares" with any
> of the following names:
>
> c-aresConfig.cmake
> c-ares-config.cmake
>
> Add the installation prefix of "c-ares" to CMAKE_PREFIX_PATH or set
> "c-ares_DIR" to a directory containing one of the above files. If "c-ares"
> provides a separate development package or SDK, be sure it has been
> installed.
> Call Stack (most recent call first):
> CMakeLists.txt:139 (include)
>
>
> Problem is, Ubuntu's c-ares does not provide any CMake files:
>
> $ dpkg -L libc-ares-dev
> /.
> /usr
> /usr/include
> /usr/include/ares.h
> /usr/include/ares_build.h
> /usr/include/ares_dns.h
> /usr/include/ares_rules.h
> /usr/include/ares_version.h
> /usr/lib
> /usr/lib/x86_64-linux-gnu
> /usr/lib/x86_64-linux-gnu/libcares.a
> /usr/lib/x86_64-linux-gnu/pkgconfig
> /usr/lib/x86_64-linux-gnu/pkgconfig/libcares.pc
> /usr/share
> /usr/share/doc
> /usr/share/doc/libc-ares-dev
> /usr/share/doc/libc-ares-dev/NEWS.gz
> /usr/share/doc/libc-ares-dev/README.cares
> /usr/share/doc/libc-ares-dev/README.md
> /usr/share/doc/libc-ares-dev/copyright
> /usr/share/man
> /usr/share/man/man3
> [ snip man pages ]
> /usr/lib/x86_64-linux-gnu/libcares.so
>
>
> Regards
>
> Antoine.
Re: [VOTE] Release Apache Arrow 0.14.0 - RC0
Posted by Sutou Kouhei <ko...@clear-code.com>.
Hi,
Could Java developers take a look this?
Anyway, could Java developers, especially PMC members, also
verify this RC?
Thanks,
--
kou
In <89...@gmail.com>
"Re: [VOTE] Release Apache Arrow 0.14.0 - RC0" on Wed, 3 Jul 2019 02:59:54 +0900,
Yosuke Shiro <yo...@gmail.com> wrote:
> Ran dev/release/verify-release-candidate.sh source 0.14.0 0 on macOS Mojave.
> I got the following error, but it may be specific to my environment.
>
> """
> [ERROR] Failed to execute goal pl.project13.maven:git-commit-id-plugin:2.2.2:revision (for-jars) on project arrow-java-root: Could not complete Mojo execution...: Error: Could not get HEAD Ref, are you sure you have set the dotGitDirectory property of this plugin to a valid path? -> [Help 1]
> [ERROR]
> [ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch.
> [ERROR] Re-run Maven using the -X switch to enable full debug logging.
> [ERROR]
> [ERROR] For more information about the errors and possible solutions, please read the following articles:
> [ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/MojoExecutionException
> + cleanup
> + '[' no = yes ']'
> + echo 'Failed to verify release candidate. See /var/folders/8t/lw8gghw13hscdt7rr9j8kqnm0000gn/T/arrow-0.14.0.XXXXX.1bxYZ8hL for details.'
> Failed to verify release candidate. See /var/folders/8t/lw8gghw13hscdt7rr9j8kqnm0000gn/T/arrow-0.14.0.XXXXX.1bxYZ8hL for details.
> “""
>
> """
> $ java --version
> openjdk 11.0.2 2019-01-15
> OpenJDK Runtime Environment 18.9 (build 11.0.2+9)
> OpenJDK 64-Bit Server VM 18.9 (build 11.0.2+9, mixed mode)
> “""
>
> """
> $ mvn --version
> Apache Maven 3.6.0 (97c98ec64a1fdfee7767ce5ffb20918da4f719f3; 2018-10-25T03:41:47+09:00)
> Maven home: /usr/local/Cellar/maven/3.6.0/libexec
> Java version: 11.0.2, vendor: Oracle Corporation, runtime: /Library/Java/JavaVirtualMachines/jdk-11.0.2.jdk/Contents/Home
> Default locale: en_JP, platform encoding: UTF-8
> OS name: "mac os x", version: "10.14.4", arch: "x86_64", family: "mac"
> “""
>
> C# verification ran fine to me.
>
>
>> On Jul 2, 2019, at 18:57, Antoine Pitrou <an...@python.org> wrote:
>>
>>
>> +1 for this RC0 anyway (binding).
>>
>>
>> Le 02/07/2019 à 11:36, Antoine Pitrou a écrit :
>>>
>>> I tried again (Ubuntu 18.04):
>>>
>>> * binaries verification succeeded
>>>
>>> * source verification failed in gRPC configure step:
>>>
>>> CMake Error at cmake/cares.cmake:38 (find_package):
>>> Could not find a package configuration file provided by "c-ares" with any
>>> of the following names:
>>>
>>> c-aresConfig.cmake
>>> c-ares-config.cmake
>>>
>>> Add the installation prefix of "c-ares" to CMAKE_PREFIX_PATH or set
>>> "c-ares_DIR" to a directory containing one of the above files. If "c-ares"
>>> provides a separate development package or SDK, be sure it has been
>>> installed.
>>> Call Stack (most recent call first):
>>> CMakeLists.txt:139 (include)
>>>
>>>
>>> Problem is, Ubuntu's c-ares does not provide any CMake files:
>>>
>>> $ dpkg -L libc-ares-dev
>>> /.
>>> /usr
>>> /usr/include
>>> /usr/include/ares.h
>>> /usr/include/ares_build.h
>>> /usr/include/ares_dns.h
>>> /usr/include/ares_rules.h
>>> /usr/include/ares_version.h
>>> /usr/lib
>>> /usr/lib/x86_64-linux-gnu
>>> /usr/lib/x86_64-linux-gnu/libcares.a
>>> /usr/lib/x86_64-linux-gnu/pkgconfig
>>> /usr/lib/x86_64-linux-gnu/pkgconfig/libcares.pc
>>> /usr/share
>>> /usr/share/doc
>>> /usr/share/doc/libc-ares-dev
>>> /usr/share/doc/libc-ares-dev/NEWS.gz
>>> /usr/share/doc/libc-ares-dev/README.cares
>>> /usr/share/doc/libc-ares-dev/README.md
>>> /usr/share/doc/libc-ares-dev/copyright
>>> /usr/share/man
>>> /usr/share/man/man3
>>> [ snip man pages ]
>>> /usr/lib/x86_64-linux-gnu/libcares.so
>>>
>>>
>>> Regards
>>>
>>> Antoine.
>>>
>
Re: [VOTE] Release Apache Arrow 0.14.0 - RC0
Posted by Ravindra Pindikura <ra...@dremio.com>.
On Wed, Jul 3, 2019 at 7:04 AM Wes McKinney <we...@gmail.com> wrote:
> @Ravindra, could you clarify what point #2 means?
>
As part of the release verify script, the mvn tests are run for all modules
(memory, vector, flight, jdbc, ..). I saw that the gandiva tests aren't
running as part of that.
@kou confirmed that this is a known issue. So, please ignore this.
>
> On Tue, Jul 2, 2019, 8:29 PM Sutou Kouhei <ko...@clear-code.com> wrote:
>
> > Hi,
> >
> > Thanks for your report.
> >
> > Adding -DProtobuf_SOURCE=BUNDLED CMake option is workaround.
> > I don't think that this is a critical problem for this RC.
> >
> > We will be able to avoid this problem automatically by the
> > following patch in 1.0.0:
> > https://github.com/apache/arrow/pull/4785
> >
> >
> > Thanks,
> > --
> > kou
> >
> > In <CA...@mail.gmail.com>
> > "Re: [VOTE] Release Apache Arrow 0.14.0 - RC0" on Wed, 3 Jul 2019
> > 10:01:21 +0900,
> > Kenta Murata <mr...@mrkn.jp> wrote:
> >
> > > I tried on Ubuntu Bionic, and got the build errors on grpc_ep (version
> > > 1.20.0). The error log will be shown the last of this mail.
> > > The errors are (1) absence of php_generator.h header file, and (2) the
> > > absence of has_ruby_package function in google::protobuf::FileOptions
> > > class.
> > > PHP support was introduced at the version 3.3.0. The has_ruby_package
> > > function was added at the version 3.6.0.
> > > So the minimum version of protobuf should be 3.6.0 for building grpc
> > > version 1.20.0.
> > >
> > > The error log I got is below:
> > >
> > >
> >
> /tmp/arrow-0.14.0.dJDu3/apache-arrow-0.14.0/cpp/build/grpc_ep-prefix/src/grpc_ep/src/compiler/php_generator.cc:21:10:
> > > fatal error: google/protobuf/compiler/php/php_generator.h: No such
> > > file or directory
> > > #include <google/protobuf/compiler/php/php_generator.h>
> > > ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > > compilation terminated.
> > > make[5]: ***
> > [CMakeFiles/grpc_plugin_support.dir/src/compiler/php_generator.cc.o]
> > > Error 1
> > > make[5]: *** Waiting for unfinished jobs....
> > >
> >
> /tmp/arrow-0.14.0.dJDu3/apache-arrow-0.14.0/cpp/build/grpc_ep-prefix/src/grpc_ep/src/compiler/ruby_generator.cc:
> > > In function ‘grpc::string grpc_ruby_generator::GetServices(const
> > > FileDescriptor*)’:
> > >
> >
> /tmp/arrow-0.14.0.dJDu3/apache-arrow-0.14.0/cpp/build/grpc_ep-prefix/src/grpc_ep/src/compiler/ruby_generator.cc:165:25:
> > > error: ‘const class google::protobuf::FileOptions’ has no member named
> > > ‘has_ruby_package’; did you mean ‘has_java_package’?
> > > if (file->options().has_ruby_package()) {
> > > ^~~~~~~~~~~~~~~~
> > > has_java_package
> > >
> >
> /tmp/arrow-0.14.0.dJDu3/apache-arrow-0.14.0/cpp/build/grpc_ep-prefix/src/grpc_ep/src/compiler/ruby_generator.cc:166:38:
> > > error: ‘const class google::protobuf::FileOptions’ has no member named
> > > ‘ruby_package’; did you mean ‘java_package’?
> > > package_name = file->options().ruby_package();
> > > ^~~~~~~~~~~~
> > > java_package
> > > make[5]: ***
> > [CMakeFiles/grpc_plugin_support.dir/src/compiler/ruby_generator.cc.o]
> > > Error 1
> > > make[4]: *** [CMakeFiles/grpc_plugin_support.dir/all] Error 2
> > > make[4]: *** Waiting for unfinished jobs....
> > > make[3]: *** [all] Error 2
> > >
> > >
> > > Regards,
> > > Kenta Murata
> > >
> > > 2019年7月3日(水) 3:00 Yosuke Shiro <yo...@gmail.com>:
> > >>
> > >> Ran dev/release/verify-release-candidate.sh source 0.14.0 0 on macOS
> > Mojave.
> > >> I got the following error, but it may be specific to my environment.
> > >>
> > >> """
> > >> [ERROR] Failed to execute goal
> > pl.project13.maven:git-commit-id-plugin:2.2.2:revision (for-jars) on
> > project arrow-java-root: Could not complete Mojo execution...: Error:
> Could
> > not get HEAD Ref, are you sure you have set the dotGitDirectory property
> of
> > this plugin to a valid path? -> [Help 1]
> > >> [ERROR]
> > >> [ERROR] To see the full stack trace of the errors, re-run Maven with
> > the -e switch.
> > >> [ERROR] Re-run Maven using the -X switch to enable full debug logging.
> > >> [ERROR]
> > >> [ERROR] For more information about the errors and possible solutions,
> > please read the following articles:
> > >> [ERROR] [Help 1]
> > http://cwiki.apache.org/confluence/display/MAVEN/MojoExecutionException
> > >> + cleanup
> > >> + '[' no = yes ']'
> > >> + echo 'Failed to verify release candidate. See
> >
> /var/folders/8t/lw8gghw13hscdt7rr9j8kqnm0000gn/T/arrow-0.14.0.XXXXX.1bxYZ8hL
> > for details.'
> > >> Failed to verify release candidate. See
> >
> /var/folders/8t/lw8gghw13hscdt7rr9j8kqnm0000gn/T/arrow-0.14.0.XXXXX.1bxYZ8hL
> > for details.
> > >> “""
> > >>
> > >> """
> > >> $ java --version
> > >> openjdk 11.0.2 2019-01-15
> > >> OpenJDK Runtime Environment 18.9 (build 11.0.2+9)
> > >> OpenJDK 64-Bit Server VM 18.9 (build 11.0.2+9, mixed mode)
> > >> “""
> > >>
> > >> """
> > >> $ mvn --version
> > >> Apache Maven 3.6.0 (97c98ec64a1fdfee7767ce5ffb20918da4f719f3;
> > 2018-10-25T03:41:47+09:00)
> > >> Maven home: /usr/local/Cellar/maven/3.6.0/libexec
> > >> Java version: 11.0.2, vendor: Oracle Corporation, runtime:
> > /Library/Java/JavaVirtualMachines/jdk-11.0.2.jdk/Contents/Home
> > >> Default locale: en_JP, platform encoding: UTF-8
> > >> OS name: "mac os x", version: "10.14.4", arch: "x86_64", family: "mac"
> > >> “""
> > >>
> > >> C# verification ran fine to me.
> > >>
> > >>
> > >> > On Jul 2, 2019, at 18:57, Antoine Pitrou <an...@python.org>
> wrote:
> > >> >
> > >> >
> > >> > +1 for this RC0 anyway (binding).
> > >> >
> > >> >
> > >> > Le 02/07/2019 à 11:36, Antoine Pitrou a écrit :
> > >> >>
> > >> >> I tried again (Ubuntu 18.04):
> > >> >>
> > >> >> * binaries verification succeeded
> > >> >>
> > >> >> * source verification failed in gRPC configure step:
> > >> >>
> > >> >> CMake Error at cmake/cares.cmake:38 (find_package):
> > >> >> Could not find a package configuration file provided by "c-ares"
> > with any
> > >> >> of the following names:
> > >> >>
> > >> >> c-aresConfig.cmake
> > >> >> c-ares-config.cmake
> > >> >>
> > >> >> Add the installation prefix of "c-ares" to CMAKE_PREFIX_PATH or
> set
> > >> >> "c-ares_DIR" to a directory containing one of the above files. If
> > "c-ares"
> > >> >> provides a separate development package or SDK, be sure it has
> been
> > >> >> installed.
> > >> >> Call Stack (most recent call first):
> > >> >> CMakeLists.txt:139 (include)
> > >> >>
> > >> >>
> > >> >> Problem is, Ubuntu's c-ares does not provide any CMake files:
> > >> >>
> > >> >> $ dpkg -L libc-ares-dev
> > >> >> /.
> > >> >> /usr
> > >> >> /usr/include
> > >> >> /usr/include/ares.h
> > >> >> /usr/include/ares_build.h
> > >> >> /usr/include/ares_dns.h
> > >> >> /usr/include/ares_rules.h
> > >> >> /usr/include/ares_version.h
> > >> >> /usr/lib
> > >> >> /usr/lib/x86_64-linux-gnu
> > >> >> /usr/lib/x86_64-linux-gnu/libcares.a
> > >> >> /usr/lib/x86_64-linux-gnu/pkgconfig
> > >> >> /usr/lib/x86_64-linux-gnu/pkgconfig/libcares.pc
> > >> >> /usr/share
> > >> >> /usr/share/doc
> > >> >> /usr/share/doc/libc-ares-dev
> > >> >> /usr/share/doc/libc-ares-dev/NEWS.gz
> > >> >> /usr/share/doc/libc-ares-dev/README.cares
> > >> >> /usr/share/doc/libc-ares-dev/README.md
> > >> >> /usr/share/doc/libc-ares-dev/copyright
> > >> >> /usr/share/man
> > >> >> /usr/share/man/man3
> > >> >> [ snip man pages ]
> > >> >> /usr/lib/x86_64-linux-gnu/libcares.so
> > >> >>
> > >> >>
> > >> >> Regards
> > >> >>
> > >> >> Antoine.
> > >> >>
> > >>
> > >
> > >
> > > --
> > > Kenta Murata
> > > OpenPGP FP = 1D69 ADDE 081C 9CC2 2E54 98C1 CEFE 8AFB 6081 B062
> > >
> > > 本を書きました!!
> > > 『Ruby 逆引きレシピ』 http://www.amazon.co.jp/dp/4798119881/mrkn-22
> > >
> > > E-mail: mrkn@mrkn.jp
> > > twitter: http://twitter.com/mrkn/
> > > blog: http://d.hatena.ne.jp/mrkn/
> >
>
--
Thanks and regards,
Ravindra.
Re: [VOTE] Release Apache Arrow 0.14.0 - RC0
Posted by Ravindra Pindikura <ra...@dremio.com>.
On Wed, Jul 3, 2019 at 7:06 AM Wes McKinney <we...@gmail.com> wrote:
> For the record, because Flight is so new and isn't being tested by very
> many contributors in their environments, I would expect a lot of problems
> and don't think they pose an issue for releasing. Let's open follow up
> JIRAs
>
done, ARROW-5829
>
> On Tue, Jul 2, 2019, 8:34 PM Wes McKinney <we...@gmail.com> wrote:
>
> > @Ravindra, could you clarify what point #2 means?
> >
> > On Tue, Jul 2, 2019, 8:29 PM Sutou Kouhei <ko...@clear-code.com> wrote:
> >
> >> Hi,
> >>
> >> Thanks for your report.
> >>
> >> Adding -DProtobuf_SOURCE=BUNDLED CMake option is workaround.
> >> I don't think that this is a critical problem for this RC.
> >>
> >> We will be able to avoid this problem automatically by the
> >> following patch in 1.0.0:
> >> https://github.com/apache/arrow/pull/4785
> >>
> >>
> >> Thanks,
> >> --
> >> kou
> >>
> >> In <CA...@mail.gmail.com>
> >> "Re: [VOTE] Release Apache Arrow 0.14.0 - RC0" on Wed, 3 Jul 2019
> >> 10:01:21 +0900,
> >> Kenta Murata <mr...@mrkn.jp> wrote:
> >>
> >> > I tried on Ubuntu Bionic, and got the build errors on grpc_ep (version
> >> > 1.20.0). The error log will be shown the last of this mail.
> >> > The errors are (1) absence of php_generator.h header file, and (2) the
> >> > absence of has_ruby_package function in google::protobuf::FileOptions
> >> > class.
> >> > PHP support was introduced at the version 3.3.0. The has_ruby_package
> >> > function was added at the version 3.6.0.
> >> > So the minimum version of protobuf should be 3.6.0 for building grpc
> >> > version 1.20.0.
> >> >
> >> > The error log I got is below:
> >> >
> >> >
> >>
> /tmp/arrow-0.14.0.dJDu3/apache-arrow-0.14.0/cpp/build/grpc_ep-prefix/src/grpc_ep/src/compiler/php_generator.cc:21:10:
> >> > fatal error: google/protobuf/compiler/php/php_generator.h: No such
> >> > file or directory
> >> > #include <google/protobuf/compiler/php/php_generator.h>
> >> > ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> >> > compilation terminated.
> >> > make[5]: ***
> >> [CMakeFiles/grpc_plugin_support.dir/src/compiler/php_generator.cc.o]
> >> > Error 1
> >> > make[5]: *** Waiting for unfinished jobs....
> >> >
> >>
> /tmp/arrow-0.14.0.dJDu3/apache-arrow-0.14.0/cpp/build/grpc_ep-prefix/src/grpc_ep/src/compiler/ruby_generator.cc:
> >> > In function ‘grpc::string grpc_ruby_generator::GetServices(const
> >> > FileDescriptor*)’:
> >> >
> >>
> /tmp/arrow-0.14.0.dJDu3/apache-arrow-0.14.0/cpp/build/grpc_ep-prefix/src/grpc_ep/src/compiler/ruby_generator.cc:165:25:
> >> > error: ‘const class google::protobuf::FileOptions’ has no member named
> >> > ‘has_ruby_package’; did you mean ‘has_java_package’?
> >> > if (file->options().has_ruby_package()) {
> >> > ^~~~~~~~~~~~~~~~
> >> > has_java_package
> >> >
> >>
> /tmp/arrow-0.14.0.dJDu3/apache-arrow-0.14.0/cpp/build/grpc_ep-prefix/src/grpc_ep/src/compiler/ruby_generator.cc:166:38:
> >> > error: ‘const class google::protobuf::FileOptions’ has no member named
> >> > ‘ruby_package’; did you mean ‘java_package’?
> >> > package_name = file->options().ruby_package();
> >> > ^~~~~~~~~~~~
> >> > java_package
> >> > make[5]: ***
> >> [CMakeFiles/grpc_plugin_support.dir/src/compiler/ruby_generator.cc.o]
> >> > Error 1
> >> > make[4]: *** [CMakeFiles/grpc_plugin_support.dir/all] Error 2
> >> > make[4]: *** Waiting for unfinished jobs....
> >> > make[3]: *** [all] Error 2
> >> >
> >> >
> >> > Regards,
> >> > Kenta Murata
> >> >
> >> > 2019年7月3日(水) 3:00 Yosuke Shiro <yo...@gmail.com>:
> >> >>
> >> >> Ran dev/release/verify-release-candidate.sh source 0.14.0 0 on macOS
> >> Mojave.
> >> >> I got the following error, but it may be specific to my environment.
> >> >>
> >> >> """
> >> >> [ERROR] Failed to execute goal
> >> pl.project13.maven:git-commit-id-plugin:2.2.2:revision (for-jars) on
> >> project arrow-java-root: Could not complete Mojo execution...: Error:
> Could
> >> not get HEAD Ref, are you sure you have set the dotGitDirectory
> property of
> >> this plugin to a valid path? -> [Help 1]
> >> >> [ERROR]
> >> >> [ERROR] To see the full stack trace of the errors, re-run Maven with
> >> the -e switch.
> >> >> [ERROR] Re-run Maven using the -X switch to enable full debug
> logging.
> >> >> [ERROR]
> >> >> [ERROR] For more information about the errors and possible solutions,
> >> please read the following articles:
> >> >> [ERROR] [Help 1]
> >> http://cwiki.apache.org/confluence/display/MAVEN/MojoExecutionException
> >> >> + cleanup
> >> >> + '[' no = yes ']'
> >> >> + echo 'Failed to verify release candidate. See
> >>
> /var/folders/8t/lw8gghw13hscdt7rr9j8kqnm0000gn/T/arrow-0.14.0.XXXXX.1bxYZ8hL
> >> for details.'
> >> >> Failed to verify release candidate. See
> >>
> /var/folders/8t/lw8gghw13hscdt7rr9j8kqnm0000gn/T/arrow-0.14.0.XXXXX.1bxYZ8hL
> >> for details.
> >> >> “""
> >> >>
> >> >> """
> >> >> $ java --version
> >> >> openjdk 11.0.2 2019-01-15
> >> >> OpenJDK Runtime Environment 18.9 (build 11.0.2+9)
> >> >> OpenJDK 64-Bit Server VM 18.9 (build 11.0.2+9, mixed mode)
> >> >> “""
> >> >>
> >> >> """
> >> >> $ mvn --version
> >> >> Apache Maven 3.6.0 (97c98ec64a1fdfee7767ce5ffb20918da4f719f3;
> >> 2018-10-25T03:41:47+09:00)
> >> >> Maven home: /usr/local/Cellar/maven/3.6.0/libexec
> >> >> Java version: 11.0.2, vendor: Oracle Corporation, runtime:
> >> /Library/Java/JavaVirtualMachines/jdk-11.0.2.jdk/Contents/Home
> >> >> Default locale: en_JP, platform encoding: UTF-8
> >> >> OS name: "mac os x", version: "10.14.4", arch: "x86_64", family:
> "mac"
> >> >> “""
> >> >>
> >> >> C# verification ran fine to me.
> >> >>
> >> >>
> >> >> > On Jul 2, 2019, at 18:57, Antoine Pitrou <an...@python.org>
> wrote:
> >> >> >
> >> >> >
> >> >> > +1 for this RC0 anyway (binding).
> >> >> >
> >> >> >
> >> >> > Le 02/07/2019 à 11:36, Antoine Pitrou a écrit :
> >> >> >>
> >> >> >> I tried again (Ubuntu 18.04):
> >> >> >>
> >> >> >> * binaries verification succeeded
> >> >> >>
> >> >> >> * source verification failed in gRPC configure step:
> >> >> >>
> >> >> >> CMake Error at cmake/cares.cmake:38 (find_package):
> >> >> >> Could not find a package configuration file provided by "c-ares"
> >> with any
> >> >> >> of the following names:
> >> >> >>
> >> >> >> c-aresConfig.cmake
> >> >> >> c-ares-config.cmake
> >> >> >>
> >> >> >> Add the installation prefix of "c-ares" to CMAKE_PREFIX_PATH or
> set
> >> >> >> "c-ares_DIR" to a directory containing one of the above files.
> If
> >> "c-ares"
> >> >> >> provides a separate development package or SDK, be sure it has
> been
> >> >> >> installed.
> >> >> >> Call Stack (most recent call first):
> >> >> >> CMakeLists.txt:139 (include)
> >> >> >>
> >> >> >>
> >> >> >> Problem is, Ubuntu's c-ares does not provide any CMake files:
> >> >> >>
> >> >> >> $ dpkg -L libc-ares-dev
> >> >> >> /.
> >> >> >> /usr
> >> >> >> /usr/include
> >> >> >> /usr/include/ares.h
> >> >> >> /usr/include/ares_build.h
> >> >> >> /usr/include/ares_dns.h
> >> >> >> /usr/include/ares_rules.h
> >> >> >> /usr/include/ares_version.h
> >> >> >> /usr/lib
> >> >> >> /usr/lib/x86_64-linux-gnu
> >> >> >> /usr/lib/x86_64-linux-gnu/libcares.a
> >> >> >> /usr/lib/x86_64-linux-gnu/pkgconfig
> >> >> >> /usr/lib/x86_64-linux-gnu/pkgconfig/libcares.pc
> >> >> >> /usr/share
> >> >> >> /usr/share/doc
> >> >> >> /usr/share/doc/libc-ares-dev
> >> >> >> /usr/share/doc/libc-ares-dev/NEWS.gz
> >> >> >> /usr/share/doc/libc-ares-dev/README.cares
> >> >> >> /usr/share/doc/libc-ares-dev/README.md
> >> >> >> /usr/share/doc/libc-ares-dev/copyright
> >> >> >> /usr/share/man
> >> >> >> /usr/share/man/man3
> >> >> >> [ snip man pages ]
> >> >> >> /usr/lib/x86_64-linux-gnu/libcares.so
> >> >> >>
> >> >> >>
> >> >> >> Regards
> >> >> >>
> >> >> >> Antoine.
> >> >> >>
> >> >>
> >> >
> >> >
> >> > --
> >> > Kenta Murata
> >> > OpenPGP FP = 1D69 ADDE 081C 9CC2 2E54 98C1 CEFE 8AFB 6081 B062
> >> >
> >> > 本を書きました!!
> >> > 『Ruby 逆引きレシピ』 http://www.amazon.co.jp/dp/4798119881/mrkn-22
> >> >
> >> > E-mail: mrkn@mrkn.jp
> >> > twitter: http://twitter.com/mrkn/
> >> > blog: http://d.hatena.ne.jp/mrkn/
> >>
> >
>
--
Thanks and regards,
Ravindra.
Re: [VOTE] Release Apache Arrow 0.14.0 - RC0
Posted by Wes McKinney <we...@gmail.com>.
For the record, because Flight is so new and isn't being tested by very
many contributors in their environments, I would expect a lot of problems
and don't think they pose an issue for releasing. Let's open follow up JIRAs
On Tue, Jul 2, 2019, 8:34 PM Wes McKinney <we...@gmail.com> wrote:
> @Ravindra, could you clarify what point #2 means?
>
> On Tue, Jul 2, 2019, 8:29 PM Sutou Kouhei <ko...@clear-code.com> wrote:
>
>> Hi,
>>
>> Thanks for your report.
>>
>> Adding -DProtobuf_SOURCE=BUNDLED CMake option is workaround.
>> I don't think that this is a critical problem for this RC.
>>
>> We will be able to avoid this problem automatically by the
>> following patch in 1.0.0:
>> https://github.com/apache/arrow/pull/4785
>>
>>
>> Thanks,
>> --
>> kou
>>
>> In <CA...@mail.gmail.com>
>> "Re: [VOTE] Release Apache Arrow 0.14.0 - RC0" on Wed, 3 Jul 2019
>> 10:01:21 +0900,
>> Kenta Murata <mr...@mrkn.jp> wrote:
>>
>> > I tried on Ubuntu Bionic, and got the build errors on grpc_ep (version
>> > 1.20.0). The error log will be shown the last of this mail.
>> > The errors are (1) absence of php_generator.h header file, and (2) the
>> > absence of has_ruby_package function in google::protobuf::FileOptions
>> > class.
>> > PHP support was introduced at the version 3.3.0. The has_ruby_package
>> > function was added at the version 3.6.0.
>> > So the minimum version of protobuf should be 3.6.0 for building grpc
>> > version 1.20.0.
>> >
>> > The error log I got is below:
>> >
>> >
>> /tmp/arrow-0.14.0.dJDu3/apache-arrow-0.14.0/cpp/build/grpc_ep-prefix/src/grpc_ep/src/compiler/php_generator.cc:21:10:
>> > fatal error: google/protobuf/compiler/php/php_generator.h: No such
>> > file or directory
>> > #include <google/protobuf/compiler/php/php_generator.h>
>> > ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>> > compilation terminated.
>> > make[5]: ***
>> [CMakeFiles/grpc_plugin_support.dir/src/compiler/php_generator.cc.o]
>> > Error 1
>> > make[5]: *** Waiting for unfinished jobs....
>> >
>> /tmp/arrow-0.14.0.dJDu3/apache-arrow-0.14.0/cpp/build/grpc_ep-prefix/src/grpc_ep/src/compiler/ruby_generator.cc:
>> > In function ‘grpc::string grpc_ruby_generator::GetServices(const
>> > FileDescriptor*)’:
>> >
>> /tmp/arrow-0.14.0.dJDu3/apache-arrow-0.14.0/cpp/build/grpc_ep-prefix/src/grpc_ep/src/compiler/ruby_generator.cc:165:25:
>> > error: ‘const class google::protobuf::FileOptions’ has no member named
>> > ‘has_ruby_package’; did you mean ‘has_java_package’?
>> > if (file->options().has_ruby_package()) {
>> > ^~~~~~~~~~~~~~~~
>> > has_java_package
>> >
>> /tmp/arrow-0.14.0.dJDu3/apache-arrow-0.14.0/cpp/build/grpc_ep-prefix/src/grpc_ep/src/compiler/ruby_generator.cc:166:38:
>> > error: ‘const class google::protobuf::FileOptions’ has no member named
>> > ‘ruby_package’; did you mean ‘java_package’?
>> > package_name = file->options().ruby_package();
>> > ^~~~~~~~~~~~
>> > java_package
>> > make[5]: ***
>> [CMakeFiles/grpc_plugin_support.dir/src/compiler/ruby_generator.cc.o]
>> > Error 1
>> > make[4]: *** [CMakeFiles/grpc_plugin_support.dir/all] Error 2
>> > make[4]: *** Waiting for unfinished jobs....
>> > make[3]: *** [all] Error 2
>> >
>> >
>> > Regards,
>> > Kenta Murata
>> >
>> > 2019年7月3日(水) 3:00 Yosuke Shiro <yo...@gmail.com>:
>> >>
>> >> Ran dev/release/verify-release-candidate.sh source 0.14.0 0 on macOS
>> Mojave.
>> >> I got the following error, but it may be specific to my environment.
>> >>
>> >> """
>> >> [ERROR] Failed to execute goal
>> pl.project13.maven:git-commit-id-plugin:2.2.2:revision (for-jars) on
>> project arrow-java-root: Could not complete Mojo execution...: Error: Could
>> not get HEAD Ref, are you sure you have set the dotGitDirectory property of
>> this plugin to a valid path? -> [Help 1]
>> >> [ERROR]
>> >> [ERROR] To see the full stack trace of the errors, re-run Maven with
>> the -e switch.
>> >> [ERROR] Re-run Maven using the -X switch to enable full debug logging.
>> >> [ERROR]
>> >> [ERROR] For more information about the errors and possible solutions,
>> please read the following articles:
>> >> [ERROR] [Help 1]
>> http://cwiki.apache.org/confluence/display/MAVEN/MojoExecutionException
>> >> + cleanup
>> >> + '[' no = yes ']'
>> >> + echo 'Failed to verify release candidate. See
>> /var/folders/8t/lw8gghw13hscdt7rr9j8kqnm0000gn/T/arrow-0.14.0.XXXXX.1bxYZ8hL
>> for details.'
>> >> Failed to verify release candidate. See
>> /var/folders/8t/lw8gghw13hscdt7rr9j8kqnm0000gn/T/arrow-0.14.0.XXXXX.1bxYZ8hL
>> for details.
>> >> “""
>> >>
>> >> """
>> >> $ java --version
>> >> openjdk 11.0.2 2019-01-15
>> >> OpenJDK Runtime Environment 18.9 (build 11.0.2+9)
>> >> OpenJDK 64-Bit Server VM 18.9 (build 11.0.2+9, mixed mode)
>> >> “""
>> >>
>> >> """
>> >> $ mvn --version
>> >> Apache Maven 3.6.0 (97c98ec64a1fdfee7767ce5ffb20918da4f719f3;
>> 2018-10-25T03:41:47+09:00)
>> >> Maven home: /usr/local/Cellar/maven/3.6.0/libexec
>> >> Java version: 11.0.2, vendor: Oracle Corporation, runtime:
>> /Library/Java/JavaVirtualMachines/jdk-11.0.2.jdk/Contents/Home
>> >> Default locale: en_JP, platform encoding: UTF-8
>> >> OS name: "mac os x", version: "10.14.4", arch: "x86_64", family: "mac"
>> >> “""
>> >>
>> >> C# verification ran fine to me.
>> >>
>> >>
>> >> > On Jul 2, 2019, at 18:57, Antoine Pitrou <an...@python.org> wrote:
>> >> >
>> >> >
>> >> > +1 for this RC0 anyway (binding).
>> >> >
>> >> >
>> >> > Le 02/07/2019 à 11:36, Antoine Pitrou a écrit :
>> >> >>
>> >> >> I tried again (Ubuntu 18.04):
>> >> >>
>> >> >> * binaries verification succeeded
>> >> >>
>> >> >> * source verification failed in gRPC configure step:
>> >> >>
>> >> >> CMake Error at cmake/cares.cmake:38 (find_package):
>> >> >> Could not find a package configuration file provided by "c-ares"
>> with any
>> >> >> of the following names:
>> >> >>
>> >> >> c-aresConfig.cmake
>> >> >> c-ares-config.cmake
>> >> >>
>> >> >> Add the installation prefix of "c-ares" to CMAKE_PREFIX_PATH or set
>> >> >> "c-ares_DIR" to a directory containing one of the above files. If
>> "c-ares"
>> >> >> provides a separate development package or SDK, be sure it has been
>> >> >> installed.
>> >> >> Call Stack (most recent call first):
>> >> >> CMakeLists.txt:139 (include)
>> >> >>
>> >> >>
>> >> >> Problem is, Ubuntu's c-ares does not provide any CMake files:
>> >> >>
>> >> >> $ dpkg -L libc-ares-dev
>> >> >> /.
>> >> >> /usr
>> >> >> /usr/include
>> >> >> /usr/include/ares.h
>> >> >> /usr/include/ares_build.h
>> >> >> /usr/include/ares_dns.h
>> >> >> /usr/include/ares_rules.h
>> >> >> /usr/include/ares_version.h
>> >> >> /usr/lib
>> >> >> /usr/lib/x86_64-linux-gnu
>> >> >> /usr/lib/x86_64-linux-gnu/libcares.a
>> >> >> /usr/lib/x86_64-linux-gnu/pkgconfig
>> >> >> /usr/lib/x86_64-linux-gnu/pkgconfig/libcares.pc
>> >> >> /usr/share
>> >> >> /usr/share/doc
>> >> >> /usr/share/doc/libc-ares-dev
>> >> >> /usr/share/doc/libc-ares-dev/NEWS.gz
>> >> >> /usr/share/doc/libc-ares-dev/README.cares
>> >> >> /usr/share/doc/libc-ares-dev/README.md
>> >> >> /usr/share/doc/libc-ares-dev/copyright
>> >> >> /usr/share/man
>> >> >> /usr/share/man/man3
>> >> >> [ snip man pages ]
>> >> >> /usr/lib/x86_64-linux-gnu/libcares.so
>> >> >>
>> >> >>
>> >> >> Regards
>> >> >>
>> >> >> Antoine.
>> >> >>
>> >>
>> >
>> >
>> > --
>> > Kenta Murata
>> > OpenPGP FP = 1D69 ADDE 081C 9CC2 2E54 98C1 CEFE 8AFB 6081 B062
>> >
>> > 本を書きました!!
>> > 『Ruby 逆引きレシピ』 http://www.amazon.co.jp/dp/4798119881/mrkn-22
>> >
>> > E-mail: mrkn@mrkn.jp
>> > twitter: http://twitter.com/mrkn/
>> > blog: http://d.hatena.ne.jp/mrkn/
>>
>
Re: [VOTE] Release Apache Arrow 0.14.0 - RC0
Posted by Wes McKinney <we...@gmail.com>.
@Ravindra, could you clarify what point #2 means?
On Tue, Jul 2, 2019, 8:29 PM Sutou Kouhei <ko...@clear-code.com> wrote:
> Hi,
>
> Thanks for your report.
>
> Adding -DProtobuf_SOURCE=BUNDLED CMake option is workaround.
> I don't think that this is a critical problem for this RC.
>
> We will be able to avoid this problem automatically by the
> following patch in 1.0.0:
> https://github.com/apache/arrow/pull/4785
>
>
> Thanks,
> --
> kou
>
> In <CA...@mail.gmail.com>
> "Re: [VOTE] Release Apache Arrow 0.14.0 - RC0" on Wed, 3 Jul 2019
> 10:01:21 +0900,
> Kenta Murata <mr...@mrkn.jp> wrote:
>
> > I tried on Ubuntu Bionic, and got the build errors on grpc_ep (version
> > 1.20.0). The error log will be shown the last of this mail.
> > The errors are (1) absence of php_generator.h header file, and (2) the
> > absence of has_ruby_package function in google::protobuf::FileOptions
> > class.
> > PHP support was introduced at the version 3.3.0. The has_ruby_package
> > function was added at the version 3.6.0.
> > So the minimum version of protobuf should be 3.6.0 for building grpc
> > version 1.20.0.
> >
> > The error log I got is below:
> >
> >
> /tmp/arrow-0.14.0.dJDu3/apache-arrow-0.14.0/cpp/build/grpc_ep-prefix/src/grpc_ep/src/compiler/php_generator.cc:21:10:
> > fatal error: google/protobuf/compiler/php/php_generator.h: No such
> > file or directory
> > #include <google/protobuf/compiler/php/php_generator.h>
> > ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > compilation terminated.
> > make[5]: ***
> [CMakeFiles/grpc_plugin_support.dir/src/compiler/php_generator.cc.o]
> > Error 1
> > make[5]: *** Waiting for unfinished jobs....
> >
> /tmp/arrow-0.14.0.dJDu3/apache-arrow-0.14.0/cpp/build/grpc_ep-prefix/src/grpc_ep/src/compiler/ruby_generator.cc:
> > In function ‘grpc::string grpc_ruby_generator::GetServices(const
> > FileDescriptor*)’:
> >
> /tmp/arrow-0.14.0.dJDu3/apache-arrow-0.14.0/cpp/build/grpc_ep-prefix/src/grpc_ep/src/compiler/ruby_generator.cc:165:25:
> > error: ‘const class google::protobuf::FileOptions’ has no member named
> > ‘has_ruby_package’; did you mean ‘has_java_package’?
> > if (file->options().has_ruby_package()) {
> > ^~~~~~~~~~~~~~~~
> > has_java_package
> >
> /tmp/arrow-0.14.0.dJDu3/apache-arrow-0.14.0/cpp/build/grpc_ep-prefix/src/grpc_ep/src/compiler/ruby_generator.cc:166:38:
> > error: ‘const class google::protobuf::FileOptions’ has no member named
> > ‘ruby_package’; did you mean ‘java_package’?
> > package_name = file->options().ruby_package();
> > ^~~~~~~~~~~~
> > java_package
> > make[5]: ***
> [CMakeFiles/grpc_plugin_support.dir/src/compiler/ruby_generator.cc.o]
> > Error 1
> > make[4]: *** [CMakeFiles/grpc_plugin_support.dir/all] Error 2
> > make[4]: *** Waiting for unfinished jobs....
> > make[3]: *** [all] Error 2
> >
> >
> > Regards,
> > Kenta Murata
> >
> > 2019年7月3日(水) 3:00 Yosuke Shiro <yo...@gmail.com>:
> >>
> >> Ran dev/release/verify-release-candidate.sh source 0.14.0 0 on macOS
> Mojave.
> >> I got the following error, but it may be specific to my environment.
> >>
> >> """
> >> [ERROR] Failed to execute goal
> pl.project13.maven:git-commit-id-plugin:2.2.2:revision (for-jars) on
> project arrow-java-root: Could not complete Mojo execution...: Error: Could
> not get HEAD Ref, are you sure you have set the dotGitDirectory property of
> this plugin to a valid path? -> [Help 1]
> >> [ERROR]
> >> [ERROR] To see the full stack trace of the errors, re-run Maven with
> the -e switch.
> >> [ERROR] Re-run Maven using the -X switch to enable full debug logging.
> >> [ERROR]
> >> [ERROR] For more information about the errors and possible solutions,
> please read the following articles:
> >> [ERROR] [Help 1]
> http://cwiki.apache.org/confluence/display/MAVEN/MojoExecutionException
> >> + cleanup
> >> + '[' no = yes ']'
> >> + echo 'Failed to verify release candidate. See
> /var/folders/8t/lw8gghw13hscdt7rr9j8kqnm0000gn/T/arrow-0.14.0.XXXXX.1bxYZ8hL
> for details.'
> >> Failed to verify release candidate. See
> /var/folders/8t/lw8gghw13hscdt7rr9j8kqnm0000gn/T/arrow-0.14.0.XXXXX.1bxYZ8hL
> for details.
> >> “""
> >>
> >> """
> >> $ java --version
> >> openjdk 11.0.2 2019-01-15
> >> OpenJDK Runtime Environment 18.9 (build 11.0.2+9)
> >> OpenJDK 64-Bit Server VM 18.9 (build 11.0.2+9, mixed mode)
> >> “""
> >>
> >> """
> >> $ mvn --version
> >> Apache Maven 3.6.0 (97c98ec64a1fdfee7767ce5ffb20918da4f719f3;
> 2018-10-25T03:41:47+09:00)
> >> Maven home: /usr/local/Cellar/maven/3.6.0/libexec
> >> Java version: 11.0.2, vendor: Oracle Corporation, runtime:
> /Library/Java/JavaVirtualMachines/jdk-11.0.2.jdk/Contents/Home
> >> Default locale: en_JP, platform encoding: UTF-8
> >> OS name: "mac os x", version: "10.14.4", arch: "x86_64", family: "mac"
> >> “""
> >>
> >> C# verification ran fine to me.
> >>
> >>
> >> > On Jul 2, 2019, at 18:57, Antoine Pitrou <an...@python.org> wrote:
> >> >
> >> >
> >> > +1 for this RC0 anyway (binding).
> >> >
> >> >
> >> > Le 02/07/2019 à 11:36, Antoine Pitrou a écrit :
> >> >>
> >> >> I tried again (Ubuntu 18.04):
> >> >>
> >> >> * binaries verification succeeded
> >> >>
> >> >> * source verification failed in gRPC configure step:
> >> >>
> >> >> CMake Error at cmake/cares.cmake:38 (find_package):
> >> >> Could not find a package configuration file provided by "c-ares"
> with any
> >> >> of the following names:
> >> >>
> >> >> c-aresConfig.cmake
> >> >> c-ares-config.cmake
> >> >>
> >> >> Add the installation prefix of "c-ares" to CMAKE_PREFIX_PATH or set
> >> >> "c-ares_DIR" to a directory containing one of the above files. If
> "c-ares"
> >> >> provides a separate development package or SDK, be sure it has been
> >> >> installed.
> >> >> Call Stack (most recent call first):
> >> >> CMakeLists.txt:139 (include)
> >> >>
> >> >>
> >> >> Problem is, Ubuntu's c-ares does not provide any CMake files:
> >> >>
> >> >> $ dpkg -L libc-ares-dev
> >> >> /.
> >> >> /usr
> >> >> /usr/include
> >> >> /usr/include/ares.h
> >> >> /usr/include/ares_build.h
> >> >> /usr/include/ares_dns.h
> >> >> /usr/include/ares_rules.h
> >> >> /usr/include/ares_version.h
> >> >> /usr/lib
> >> >> /usr/lib/x86_64-linux-gnu
> >> >> /usr/lib/x86_64-linux-gnu/libcares.a
> >> >> /usr/lib/x86_64-linux-gnu/pkgconfig
> >> >> /usr/lib/x86_64-linux-gnu/pkgconfig/libcares.pc
> >> >> /usr/share
> >> >> /usr/share/doc
> >> >> /usr/share/doc/libc-ares-dev
> >> >> /usr/share/doc/libc-ares-dev/NEWS.gz
> >> >> /usr/share/doc/libc-ares-dev/README.cares
> >> >> /usr/share/doc/libc-ares-dev/README.md
> >> >> /usr/share/doc/libc-ares-dev/copyright
> >> >> /usr/share/man
> >> >> /usr/share/man/man3
> >> >> [ snip man pages ]
> >> >> /usr/lib/x86_64-linux-gnu/libcares.so
> >> >>
> >> >>
> >> >> Regards
> >> >>
> >> >> Antoine.
> >> >>
> >>
> >
> >
> > --
> > Kenta Murata
> > OpenPGP FP = 1D69 ADDE 081C 9CC2 2E54 98C1 CEFE 8AFB 6081 B062
> >
> > 本を書きました!!
> > 『Ruby 逆引きレシピ』 http://www.amazon.co.jp/dp/4798119881/mrkn-22
> >
> > E-mail: mrkn@mrkn.jp
> > twitter: http://twitter.com/mrkn/
> > blog: http://d.hatena.ne.jp/mrkn/
>
Re: [VOTE] Release Apache Arrow 0.14.0 - RC0
Posted by Sutou Kouhei <ko...@clear-code.com>.
Hi,
Thanks for your report.
Adding -DProtobuf_SOURCE=BUNDLED CMake option is workaround.
I don't think that this is a critical problem for this RC.
We will be able to avoid this problem automatically by the
following patch in 1.0.0:
https://github.com/apache/arrow/pull/4785
Thanks,
--
kou
In <CA...@mail.gmail.com>
"Re: [VOTE] Release Apache Arrow 0.14.0 - RC0" on Wed, 3 Jul 2019 10:01:21 +0900,
Kenta Murata <mr...@mrkn.jp> wrote:
> I tried on Ubuntu Bionic, and got the build errors on grpc_ep (version
> 1.20.0). The error log will be shown the last of this mail.
> The errors are (1) absence of php_generator.h header file, and (2) the
> absence of has_ruby_package function in google::protobuf::FileOptions
> class.
> PHP support was introduced at the version 3.3.0. The has_ruby_package
> function was added at the version 3.6.0.
> So the minimum version of protobuf should be 3.6.0 for building grpc
> version 1.20.0.
>
> The error log I got is below:
>
> /tmp/arrow-0.14.0.dJDu3/apache-arrow-0.14.0/cpp/build/grpc_ep-prefix/src/grpc_ep/src/compiler/php_generator.cc:21:10:
> fatal error: google/protobuf/compiler/php/php_generator.h: No such
> file or directory
> #include <google/protobuf/compiler/php/php_generator.h>
> ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> compilation terminated.
> make[5]: *** [CMakeFiles/grpc_plugin_support.dir/src/compiler/php_generator.cc.o]
> Error 1
> make[5]: *** Waiting for unfinished jobs....
> /tmp/arrow-0.14.0.dJDu3/apache-arrow-0.14.0/cpp/build/grpc_ep-prefix/src/grpc_ep/src/compiler/ruby_generator.cc:
> In function ‘grpc::string grpc_ruby_generator::GetServices(const
> FileDescriptor*)’:
> /tmp/arrow-0.14.0.dJDu3/apache-arrow-0.14.0/cpp/build/grpc_ep-prefix/src/grpc_ep/src/compiler/ruby_generator.cc:165:25:
> error: ‘const class google::protobuf::FileOptions’ has no member named
> ‘has_ruby_package’; did you mean ‘has_java_package’?
> if (file->options().has_ruby_package()) {
> ^~~~~~~~~~~~~~~~
> has_java_package
> /tmp/arrow-0.14.0.dJDu3/apache-arrow-0.14.0/cpp/build/grpc_ep-prefix/src/grpc_ep/src/compiler/ruby_generator.cc:166:38:
> error: ‘const class google::protobuf::FileOptions’ has no member named
> ‘ruby_package’; did you mean ‘java_package’?
> package_name = file->options().ruby_package();
> ^~~~~~~~~~~~
> java_package
> make[5]: *** [CMakeFiles/grpc_plugin_support.dir/src/compiler/ruby_generator.cc.o]
> Error 1
> make[4]: *** [CMakeFiles/grpc_plugin_support.dir/all] Error 2
> make[4]: *** Waiting for unfinished jobs....
> make[3]: *** [all] Error 2
>
>
> Regards,
> Kenta Murata
>
> 2019年7月3日(水) 3:00 Yosuke Shiro <yo...@gmail.com>:
>>
>> Ran dev/release/verify-release-candidate.sh source 0.14.0 0 on macOS Mojave.
>> I got the following error, but it may be specific to my environment.
>>
>> """
>> [ERROR] Failed to execute goal pl.project13.maven:git-commit-id-plugin:2.2.2:revision (for-jars) on project arrow-java-root: Could not complete Mojo execution...: Error: Could not get HEAD Ref, are you sure you have set the dotGitDirectory property of this plugin to a valid path? -> [Help 1]
>> [ERROR]
>> [ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch.
>> [ERROR] Re-run Maven using the -X switch to enable full debug logging.
>> [ERROR]
>> [ERROR] For more information about the errors and possible solutions, please read the following articles:
>> [ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/MojoExecutionException
>> + cleanup
>> + '[' no = yes ']'
>> + echo 'Failed to verify release candidate. See /var/folders/8t/lw8gghw13hscdt7rr9j8kqnm0000gn/T/arrow-0.14.0.XXXXX.1bxYZ8hL for details.'
>> Failed to verify release candidate. See /var/folders/8t/lw8gghw13hscdt7rr9j8kqnm0000gn/T/arrow-0.14.0.XXXXX.1bxYZ8hL for details.
>> “""
>>
>> """
>> $ java --version
>> openjdk 11.0.2 2019-01-15
>> OpenJDK Runtime Environment 18.9 (build 11.0.2+9)
>> OpenJDK 64-Bit Server VM 18.9 (build 11.0.2+9, mixed mode)
>> “""
>>
>> """
>> $ mvn --version
>> Apache Maven 3.6.0 (97c98ec64a1fdfee7767ce5ffb20918da4f719f3; 2018-10-25T03:41:47+09:00)
>> Maven home: /usr/local/Cellar/maven/3.6.0/libexec
>> Java version: 11.0.2, vendor: Oracle Corporation, runtime: /Library/Java/JavaVirtualMachines/jdk-11.0.2.jdk/Contents/Home
>> Default locale: en_JP, platform encoding: UTF-8
>> OS name: "mac os x", version: "10.14.4", arch: "x86_64", family: "mac"
>> “""
>>
>> C# verification ran fine to me.
>>
>>
>> > On Jul 2, 2019, at 18:57, Antoine Pitrou <an...@python.org> wrote:
>> >
>> >
>> > +1 for this RC0 anyway (binding).
>> >
>> >
>> > Le 02/07/2019 à 11:36, Antoine Pitrou a écrit :
>> >>
>> >> I tried again (Ubuntu 18.04):
>> >>
>> >> * binaries verification succeeded
>> >>
>> >> * source verification failed in gRPC configure step:
>> >>
>> >> CMake Error at cmake/cares.cmake:38 (find_package):
>> >> Could not find a package configuration file provided by "c-ares" with any
>> >> of the following names:
>> >>
>> >> c-aresConfig.cmake
>> >> c-ares-config.cmake
>> >>
>> >> Add the installation prefix of "c-ares" to CMAKE_PREFIX_PATH or set
>> >> "c-ares_DIR" to a directory containing one of the above files. If "c-ares"
>> >> provides a separate development package or SDK, be sure it has been
>> >> installed.
>> >> Call Stack (most recent call first):
>> >> CMakeLists.txt:139 (include)
>> >>
>> >>
>> >> Problem is, Ubuntu's c-ares does not provide any CMake files:
>> >>
>> >> $ dpkg -L libc-ares-dev
>> >> /.
>> >> /usr
>> >> /usr/include
>> >> /usr/include/ares.h
>> >> /usr/include/ares_build.h
>> >> /usr/include/ares_dns.h
>> >> /usr/include/ares_rules.h
>> >> /usr/include/ares_version.h
>> >> /usr/lib
>> >> /usr/lib/x86_64-linux-gnu
>> >> /usr/lib/x86_64-linux-gnu/libcares.a
>> >> /usr/lib/x86_64-linux-gnu/pkgconfig
>> >> /usr/lib/x86_64-linux-gnu/pkgconfig/libcares.pc
>> >> /usr/share
>> >> /usr/share/doc
>> >> /usr/share/doc/libc-ares-dev
>> >> /usr/share/doc/libc-ares-dev/NEWS.gz
>> >> /usr/share/doc/libc-ares-dev/README.cares
>> >> /usr/share/doc/libc-ares-dev/README.md
>> >> /usr/share/doc/libc-ares-dev/copyright
>> >> /usr/share/man
>> >> /usr/share/man/man3
>> >> [ snip man pages ]
>> >> /usr/lib/x86_64-linux-gnu/libcares.so
>> >>
>> >>
>> >> Regards
>> >>
>> >> Antoine.
>> >>
>>
>
>
> --
> Kenta Murata
> OpenPGP FP = 1D69 ADDE 081C 9CC2 2E54 98C1 CEFE 8AFB 6081 B062
>
> 本を書きました!!
> 『Ruby 逆引きレシピ』 http://www.amazon.co.jp/dp/4798119881/mrkn-22
>
> E-mail: mrkn@mrkn.jp
> twitter: http://twitter.com/mrkn/
> blog: http://d.hatena.ne.jp/mrkn/
Re: [VOTE] Release Apache Arrow 0.14.0 - RC0
Posted by Kenta Murata <mr...@mrkn.jp>.
I tried on Ubuntu Bionic, and got the build errors on grpc_ep (version
1.20.0). The error log will be shown the last of this mail.
The errors are (1) absence of php_generator.h header file, and (2) the
absence of has_ruby_package function in google::protobuf::FileOptions
class.
PHP support was introduced at the version 3.3.0. The has_ruby_package
function was added at the version 3.6.0.
So the minimum version of protobuf should be 3.6.0 for building grpc
version 1.20.0.
The error log I got is below:
/tmp/arrow-0.14.0.dJDu3/apache-arrow-0.14.0/cpp/build/grpc_ep-prefix/src/grpc_ep/src/compiler/php_generator.cc:21:10:
fatal error: google/protobuf/compiler/php/php_generator.h: No such
file or directory
#include <google/protobuf/compiler/php/php_generator.h>
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
compilation terminated.
make[5]: *** [CMakeFiles/grpc_plugin_support.dir/src/compiler/php_generator.cc.o]
Error 1
make[5]: *** Waiting for unfinished jobs....
/tmp/arrow-0.14.0.dJDu3/apache-arrow-0.14.0/cpp/build/grpc_ep-prefix/src/grpc_ep/src/compiler/ruby_generator.cc:
In function ‘grpc::string grpc_ruby_generator::GetServices(const
FileDescriptor*)’:
/tmp/arrow-0.14.0.dJDu3/apache-arrow-0.14.0/cpp/build/grpc_ep-prefix/src/grpc_ep/src/compiler/ruby_generator.cc:165:25:
error: ‘const class google::protobuf::FileOptions’ has no member named
‘has_ruby_package’; did you mean ‘has_java_package’?
if (file->options().has_ruby_package()) {
^~~~~~~~~~~~~~~~
has_java_package
/tmp/arrow-0.14.0.dJDu3/apache-arrow-0.14.0/cpp/build/grpc_ep-prefix/src/grpc_ep/src/compiler/ruby_generator.cc:166:38:
error: ‘const class google::protobuf::FileOptions’ has no member named
‘ruby_package’; did you mean ‘java_package’?
package_name = file->options().ruby_package();
^~~~~~~~~~~~
java_package
make[5]: *** [CMakeFiles/grpc_plugin_support.dir/src/compiler/ruby_generator.cc.o]
Error 1
make[4]: *** [CMakeFiles/grpc_plugin_support.dir/all] Error 2
make[4]: *** Waiting for unfinished jobs....
make[3]: *** [all] Error 2
Regards,
Kenta Murata
2019年7月3日(水) 3:00 Yosuke Shiro <yo...@gmail.com>:
>
> Ran dev/release/verify-release-candidate.sh source 0.14.0 0 on macOS Mojave.
> I got the following error, but it may be specific to my environment.
>
> """
> [ERROR] Failed to execute goal pl.project13.maven:git-commit-id-plugin:2.2.2:revision (for-jars) on project arrow-java-root: Could not complete Mojo execution...: Error: Could not get HEAD Ref, are you sure you have set the dotGitDirectory property of this plugin to a valid path? -> [Help 1]
> [ERROR]
> [ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch.
> [ERROR] Re-run Maven using the -X switch to enable full debug logging.
> [ERROR]
> [ERROR] For more information about the errors and possible solutions, please read the following articles:
> [ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/MojoExecutionException
> + cleanup
> + '[' no = yes ']'
> + echo 'Failed to verify release candidate. See /var/folders/8t/lw8gghw13hscdt7rr9j8kqnm0000gn/T/arrow-0.14.0.XXXXX.1bxYZ8hL for details.'
> Failed to verify release candidate. See /var/folders/8t/lw8gghw13hscdt7rr9j8kqnm0000gn/T/arrow-0.14.0.XXXXX.1bxYZ8hL for details.
> “""
>
> """
> $ java --version
> openjdk 11.0.2 2019-01-15
> OpenJDK Runtime Environment 18.9 (build 11.0.2+9)
> OpenJDK 64-Bit Server VM 18.9 (build 11.0.2+9, mixed mode)
> “""
>
> """
> $ mvn --version
> Apache Maven 3.6.0 (97c98ec64a1fdfee7767ce5ffb20918da4f719f3; 2018-10-25T03:41:47+09:00)
> Maven home: /usr/local/Cellar/maven/3.6.0/libexec
> Java version: 11.0.2, vendor: Oracle Corporation, runtime: /Library/Java/JavaVirtualMachines/jdk-11.0.2.jdk/Contents/Home
> Default locale: en_JP, platform encoding: UTF-8
> OS name: "mac os x", version: "10.14.4", arch: "x86_64", family: "mac"
> “""
>
> C# verification ran fine to me.
>
>
> > On Jul 2, 2019, at 18:57, Antoine Pitrou <an...@python.org> wrote:
> >
> >
> > +1 for this RC0 anyway (binding).
> >
> >
> > Le 02/07/2019 à 11:36, Antoine Pitrou a écrit :
> >>
> >> I tried again (Ubuntu 18.04):
> >>
> >> * binaries verification succeeded
> >>
> >> * source verification failed in gRPC configure step:
> >>
> >> CMake Error at cmake/cares.cmake:38 (find_package):
> >> Could not find a package configuration file provided by "c-ares" with any
> >> of the following names:
> >>
> >> c-aresConfig.cmake
> >> c-ares-config.cmake
> >>
> >> Add the installation prefix of "c-ares" to CMAKE_PREFIX_PATH or set
> >> "c-ares_DIR" to a directory containing one of the above files. If "c-ares"
> >> provides a separate development package or SDK, be sure it has been
> >> installed.
> >> Call Stack (most recent call first):
> >> CMakeLists.txt:139 (include)
> >>
> >>
> >> Problem is, Ubuntu's c-ares does not provide any CMake files:
> >>
> >> $ dpkg -L libc-ares-dev
> >> /.
> >> /usr
> >> /usr/include
> >> /usr/include/ares.h
> >> /usr/include/ares_build.h
> >> /usr/include/ares_dns.h
> >> /usr/include/ares_rules.h
> >> /usr/include/ares_version.h
> >> /usr/lib
> >> /usr/lib/x86_64-linux-gnu
> >> /usr/lib/x86_64-linux-gnu/libcares.a
> >> /usr/lib/x86_64-linux-gnu/pkgconfig
> >> /usr/lib/x86_64-linux-gnu/pkgconfig/libcares.pc
> >> /usr/share
> >> /usr/share/doc
> >> /usr/share/doc/libc-ares-dev
> >> /usr/share/doc/libc-ares-dev/NEWS.gz
> >> /usr/share/doc/libc-ares-dev/README.cares
> >> /usr/share/doc/libc-ares-dev/README.md
> >> /usr/share/doc/libc-ares-dev/copyright
> >> /usr/share/man
> >> /usr/share/man/man3
> >> [ snip man pages ]
> >> /usr/lib/x86_64-linux-gnu/libcares.so
> >>
> >>
> >> Regards
> >>
> >> Antoine.
> >>
>
--
Kenta Murata
OpenPGP FP = 1D69 ADDE 081C 9CC2 2E54 98C1 CEFE 8AFB 6081 B062
本を書きました!!
『Ruby 逆引きレシピ』 http://www.amazon.co.jp/dp/4798119881/mrkn-22
E-mail: mrkn@mrkn.jp
twitter: http://twitter.com/mrkn/
blog: http://d.hatena.ne.jp/mrkn/
Re: [VOTE] Release Apache Arrow 0.14.0 - RC0
Posted by Wes McKinney <we...@gmail.com>.
hi Francois,
You can set
export ARROW_FLIGHT=OFF
to run the verification without Flight
On Wed, Jul 3, 2019 at 9:13 AM Francois Saint-Jacques
<fs...@gmail.com> wrote:
>
> - binaries verification passed.
> - source verification failed (can't compile flight)
>
> In file included from
> /tmp/arrow-0.14.0.y4gGo/apache-arrow-0.14.0/cpp/src/arrow/flight/serialization-internal.cc:29:0:
> /usr/include/google/protobuf/wire_format_lite.h: In function
> ‘grpc::Status arrow::flight::internal::FlightDataSerialize(const
> arrow::flight::FlightPayload&, grpc::ByteBuffer*, bool*)’:
> /usr/include/google/protobuf/wire_format_lite.h:355:19: error:
> inlining failed in call to always_inline ‘static void
> google::protobuf::internal::WireFormatLite::WriteTag(int,
> google::protobuf::internal::WireFormatLite::WireType,
> google::protobuf::io::CodedOutputStream*)’: function
> body not available
> INL static void WriteTag(field_number, WireType type, output);
> ^~~~~~~~
>
> On Tue, Jul 2, 2019 at 2:00 PM Yosuke Shiro <yo...@gmail.com> wrote:
> >
> > Ran dev/release/verify-release-candidate.sh source 0.14.0 0 on macOS Mojave.
> > I got the following error, but it may be specific to my environment.
> >
> > """
> > [ERROR] Failed to execute goal pl.project13.maven:git-commit-id-plugin:2.2.2:revision (for-jars) on project arrow-java-root: Could not complete Mojo execution...: Error: Could not get HEAD Ref, are you sure you have set the dotGitDirectory property of this plugin to a valid path? -> [Help 1]
> > [ERROR]
> > [ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch.
> > [ERROR] Re-run Maven using the -X switch to enable full debug logging.
> > [ERROR]
> > [ERROR] For more information about the errors and possible solutions, please read the following articles:
> > [ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/MojoExecutionException
> > + cleanup
> > + '[' no = yes ']'
> > + echo 'Failed to verify release candidate. See /var/folders/8t/lw8gghw13hscdt7rr9j8kqnm0000gn/T/arrow-0.14.0.XXXXX.1bxYZ8hL for details.'
> > Failed to verify release candidate. See /var/folders/8t/lw8gghw13hscdt7rr9j8kqnm0000gn/T/arrow-0.14.0.XXXXX.1bxYZ8hL for details.
> > “""
> >
> > """
> > $ java --version
> > openjdk 11.0.2 2019-01-15
> > OpenJDK Runtime Environment 18.9 (build 11.0.2+9)
> > OpenJDK 64-Bit Server VM 18.9 (build 11.0.2+9, mixed mode)
> > “""
> >
> > """
> > $ mvn --version
> > Apache Maven 3.6.0 (97c98ec64a1fdfee7767ce5ffb20918da4f719f3; 2018-10-25T03:41:47+09:00)
> > Maven home: /usr/local/Cellar/maven/3.6.0/libexec
> > Java version: 11.0.2, vendor: Oracle Corporation, runtime: /Library/Java/JavaVirtualMachines/jdk-11.0.2.jdk/Contents/Home
> > Default locale: en_JP, platform encoding: UTF-8
> > OS name: "mac os x", version: "10.14.4", arch: "x86_64", family: "mac"
> > “""
> >
> > C# verification ran fine to me.
> >
> >
> > > On Jul 2, 2019, at 18:57, Antoine Pitrou <an...@python.org> wrote:
> > >
> > >
> > > +1 for this RC0 anyway (binding).
> > >
> > >
> > > Le 02/07/2019 à 11:36, Antoine Pitrou a écrit :
> > >>
> > >> I tried again (Ubuntu 18.04):
> > >>
> > >> * binaries verification succeeded
> > >>
> > >> * source verification failed in gRPC configure step:
> > >>
> > >> CMake Error at cmake/cares.cmake:38 (find_package):
> > >> Could not find a package configuration file provided by "c-ares" with any
> > >> of the following names:
> > >>
> > >> c-aresConfig.cmake
> > >> c-ares-config.cmake
> > >>
> > >> Add the installation prefix of "c-ares" to CMAKE_PREFIX_PATH or set
> > >> "c-ares_DIR" to a directory containing one of the above files. If "c-ares"
> > >> provides a separate development package or SDK, be sure it has been
> > >> installed.
> > >> Call Stack (most recent call first):
> > >> CMakeLists.txt:139 (include)
> > >>
> > >>
> > >> Problem is, Ubuntu's c-ares does not provide any CMake files:
> > >>
> > >> $ dpkg -L libc-ares-dev
> > >> /.
> > >> /usr
> > >> /usr/include
> > >> /usr/include/ares.h
> > >> /usr/include/ares_build.h
> > >> /usr/include/ares_dns.h
> > >> /usr/include/ares_rules.h
> > >> /usr/include/ares_version.h
> > >> /usr/lib
> > >> /usr/lib/x86_64-linux-gnu
> > >> /usr/lib/x86_64-linux-gnu/libcares.a
> > >> /usr/lib/x86_64-linux-gnu/pkgconfig
> > >> /usr/lib/x86_64-linux-gnu/pkgconfig/libcares.pc
> > >> /usr/share
> > >> /usr/share/doc
> > >> /usr/share/doc/libc-ares-dev
> > >> /usr/share/doc/libc-ares-dev/NEWS.gz
> > >> /usr/share/doc/libc-ares-dev/README.cares
> > >> /usr/share/doc/libc-ares-dev/README.md
> > >> /usr/share/doc/libc-ares-dev/copyright
> > >> /usr/share/man
> > >> /usr/share/man/man3
> > >> [ snip man pages ]
> > >> /usr/lib/x86_64-linux-gnu/libcares.so
> > >>
> > >>
> > >> Regards
> > >>
> > >> Antoine.
> > >>
> >
Re: [VOTE] Release Apache Arrow 0.14.0 - RC0
Posted by Francois Saint-Jacques <fs...@gmail.com>.
- binaries verification passed.
- source verification failed (can't compile flight)
In file included from
/tmp/arrow-0.14.0.y4gGo/apache-arrow-0.14.0/cpp/src/arrow/flight/serialization-internal.cc:29:0:
/usr/include/google/protobuf/wire_format_lite.h: In function
‘grpc::Status arrow::flight::internal::FlightDataSerialize(const
arrow::flight::FlightPayload&, grpc::ByteBuffer*, bool*)’:
/usr/include/google/protobuf/wire_format_lite.h:355:19: error:
inlining failed in call to always_inline ‘static void
google::protobuf::internal::WireFormatLite::WriteTag(int,
google::protobuf::internal::WireFormatLite::WireType,
google::protobuf::io::CodedOutputStream*)’: function
body not available
INL static void WriteTag(field_number, WireType type, output);
^~~~~~~~
On Tue, Jul 2, 2019 at 2:00 PM Yosuke Shiro <yo...@gmail.com> wrote:
>
> Ran dev/release/verify-release-candidate.sh source 0.14.0 0 on macOS Mojave.
> I got the following error, but it may be specific to my environment.
>
> """
> [ERROR] Failed to execute goal pl.project13.maven:git-commit-id-plugin:2.2.2:revision (for-jars) on project arrow-java-root: Could not complete Mojo execution...: Error: Could not get HEAD Ref, are you sure you have set the dotGitDirectory property of this plugin to a valid path? -> [Help 1]
> [ERROR]
> [ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch.
> [ERROR] Re-run Maven using the -X switch to enable full debug logging.
> [ERROR]
> [ERROR] For more information about the errors and possible solutions, please read the following articles:
> [ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/MojoExecutionException
> + cleanup
> + '[' no = yes ']'
> + echo 'Failed to verify release candidate. See /var/folders/8t/lw8gghw13hscdt7rr9j8kqnm0000gn/T/arrow-0.14.0.XXXXX.1bxYZ8hL for details.'
> Failed to verify release candidate. See /var/folders/8t/lw8gghw13hscdt7rr9j8kqnm0000gn/T/arrow-0.14.0.XXXXX.1bxYZ8hL for details.
> “""
>
> """
> $ java --version
> openjdk 11.0.2 2019-01-15
> OpenJDK Runtime Environment 18.9 (build 11.0.2+9)
> OpenJDK 64-Bit Server VM 18.9 (build 11.0.2+9, mixed mode)
> “""
>
> """
> $ mvn --version
> Apache Maven 3.6.0 (97c98ec64a1fdfee7767ce5ffb20918da4f719f3; 2018-10-25T03:41:47+09:00)
> Maven home: /usr/local/Cellar/maven/3.6.0/libexec
> Java version: 11.0.2, vendor: Oracle Corporation, runtime: /Library/Java/JavaVirtualMachines/jdk-11.0.2.jdk/Contents/Home
> Default locale: en_JP, platform encoding: UTF-8
> OS name: "mac os x", version: "10.14.4", arch: "x86_64", family: "mac"
> “""
>
> C# verification ran fine to me.
>
>
> > On Jul 2, 2019, at 18:57, Antoine Pitrou <an...@python.org> wrote:
> >
> >
> > +1 for this RC0 anyway (binding).
> >
> >
> > Le 02/07/2019 à 11:36, Antoine Pitrou a écrit :
> >>
> >> I tried again (Ubuntu 18.04):
> >>
> >> * binaries verification succeeded
> >>
> >> * source verification failed in gRPC configure step:
> >>
> >> CMake Error at cmake/cares.cmake:38 (find_package):
> >> Could not find a package configuration file provided by "c-ares" with any
> >> of the following names:
> >>
> >> c-aresConfig.cmake
> >> c-ares-config.cmake
> >>
> >> Add the installation prefix of "c-ares" to CMAKE_PREFIX_PATH or set
> >> "c-ares_DIR" to a directory containing one of the above files. If "c-ares"
> >> provides a separate development package or SDK, be sure it has been
> >> installed.
> >> Call Stack (most recent call first):
> >> CMakeLists.txt:139 (include)
> >>
> >>
> >> Problem is, Ubuntu's c-ares does not provide any CMake files:
> >>
> >> $ dpkg -L libc-ares-dev
> >> /.
> >> /usr
> >> /usr/include
> >> /usr/include/ares.h
> >> /usr/include/ares_build.h
> >> /usr/include/ares_dns.h
> >> /usr/include/ares_rules.h
> >> /usr/include/ares_version.h
> >> /usr/lib
> >> /usr/lib/x86_64-linux-gnu
> >> /usr/lib/x86_64-linux-gnu/libcares.a
> >> /usr/lib/x86_64-linux-gnu/pkgconfig
> >> /usr/lib/x86_64-linux-gnu/pkgconfig/libcares.pc
> >> /usr/share
> >> /usr/share/doc
> >> /usr/share/doc/libc-ares-dev
> >> /usr/share/doc/libc-ares-dev/NEWS.gz
> >> /usr/share/doc/libc-ares-dev/README.cares
> >> /usr/share/doc/libc-ares-dev/README.md
> >> /usr/share/doc/libc-ares-dev/copyright
> >> /usr/share/man
> >> /usr/share/man/man3
> >> [ snip man pages ]
> >> /usr/lib/x86_64-linux-gnu/libcares.so
> >>
> >>
> >> Regards
> >>
> >> Antoine.
> >>
>
Re: [VOTE] Release Apache Arrow 0.14.0 - RC0
Posted by Yosuke Shiro <yo...@gmail.com>.
Ran dev/release/verify-release-candidate.sh source 0.14.0 0 on macOS Mojave.
I got the following error, but it may be specific to my environment.
"""
[ERROR] Failed to execute goal pl.project13.maven:git-commit-id-plugin:2.2.2:revision (for-jars) on project arrow-java-root: Could not complete Mojo execution...: Error: Could not get HEAD Ref, are you sure you have set the dotGitDirectory property of this plugin to a valid path? -> [Help 1]
[ERROR]
[ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR]
[ERROR] For more information about the errors and possible solutions, please read the following articles:
[ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/MojoExecutionException
+ cleanup
+ '[' no = yes ']'
+ echo 'Failed to verify release candidate. See /var/folders/8t/lw8gghw13hscdt7rr9j8kqnm0000gn/T/arrow-0.14.0.XXXXX.1bxYZ8hL for details.'
Failed to verify release candidate. See /var/folders/8t/lw8gghw13hscdt7rr9j8kqnm0000gn/T/arrow-0.14.0.XXXXX.1bxYZ8hL for details.
“""
"""
$ java --version
openjdk 11.0.2 2019-01-15
OpenJDK Runtime Environment 18.9 (build 11.0.2+9)
OpenJDK 64-Bit Server VM 18.9 (build 11.0.2+9, mixed mode)
“""
"""
$ mvn --version
Apache Maven 3.6.0 (97c98ec64a1fdfee7767ce5ffb20918da4f719f3; 2018-10-25T03:41:47+09:00)
Maven home: /usr/local/Cellar/maven/3.6.0/libexec
Java version: 11.0.2, vendor: Oracle Corporation, runtime: /Library/Java/JavaVirtualMachines/jdk-11.0.2.jdk/Contents/Home
Default locale: en_JP, platform encoding: UTF-8
OS name: "mac os x", version: "10.14.4", arch: "x86_64", family: "mac"
“""
C# verification ran fine to me.
> On Jul 2, 2019, at 18:57, Antoine Pitrou <an...@python.org> wrote:
>
>
> +1 for this RC0 anyway (binding).
>
>
> Le 02/07/2019 à 11:36, Antoine Pitrou a écrit :
>>
>> I tried again (Ubuntu 18.04):
>>
>> * binaries verification succeeded
>>
>> * source verification failed in gRPC configure step:
>>
>> CMake Error at cmake/cares.cmake:38 (find_package):
>> Could not find a package configuration file provided by "c-ares" with any
>> of the following names:
>>
>> c-aresConfig.cmake
>> c-ares-config.cmake
>>
>> Add the installation prefix of "c-ares" to CMAKE_PREFIX_PATH or set
>> "c-ares_DIR" to a directory containing one of the above files. If "c-ares"
>> provides a separate development package or SDK, be sure it has been
>> installed.
>> Call Stack (most recent call first):
>> CMakeLists.txt:139 (include)
>>
>>
>> Problem is, Ubuntu's c-ares does not provide any CMake files:
>>
>> $ dpkg -L libc-ares-dev
>> /.
>> /usr
>> /usr/include
>> /usr/include/ares.h
>> /usr/include/ares_build.h
>> /usr/include/ares_dns.h
>> /usr/include/ares_rules.h
>> /usr/include/ares_version.h
>> /usr/lib
>> /usr/lib/x86_64-linux-gnu
>> /usr/lib/x86_64-linux-gnu/libcares.a
>> /usr/lib/x86_64-linux-gnu/pkgconfig
>> /usr/lib/x86_64-linux-gnu/pkgconfig/libcares.pc
>> /usr/share
>> /usr/share/doc
>> /usr/share/doc/libc-ares-dev
>> /usr/share/doc/libc-ares-dev/NEWS.gz
>> /usr/share/doc/libc-ares-dev/README.cares
>> /usr/share/doc/libc-ares-dev/README.md
>> /usr/share/doc/libc-ares-dev/copyright
>> /usr/share/man
>> /usr/share/man/man3
>> [ snip man pages ]
>> /usr/lib/x86_64-linux-gnu/libcares.so
>>
>>
>> Regards
>>
>> Antoine.
>>
Re: [VOTE] Release Apache Arrow 0.14.0 - RC0
Posted by Antoine Pitrou <an...@python.org>.
+1 for this RC0 anyway (binding).
Le 02/07/2019 à 11:36, Antoine Pitrou a écrit :
>
> I tried again (Ubuntu 18.04):
>
> * binaries verification succeeded
>
> * source verification failed in gRPC configure step:
>
> CMake Error at cmake/cares.cmake:38 (find_package):
> Could not find a package configuration file provided by "c-ares" with any
> of the following names:
>
> c-aresConfig.cmake
> c-ares-config.cmake
>
> Add the installation prefix of "c-ares" to CMAKE_PREFIX_PATH or set
> "c-ares_DIR" to a directory containing one of the above files. If "c-ares"
> provides a separate development package or SDK, be sure it has been
> installed.
> Call Stack (most recent call first):
> CMakeLists.txt:139 (include)
>
>
> Problem is, Ubuntu's c-ares does not provide any CMake files:
>
> $ dpkg -L libc-ares-dev
> /.
> /usr
> /usr/include
> /usr/include/ares.h
> /usr/include/ares_build.h
> /usr/include/ares_dns.h
> /usr/include/ares_rules.h
> /usr/include/ares_version.h
> /usr/lib
> /usr/lib/x86_64-linux-gnu
> /usr/lib/x86_64-linux-gnu/libcares.a
> /usr/lib/x86_64-linux-gnu/pkgconfig
> /usr/lib/x86_64-linux-gnu/pkgconfig/libcares.pc
> /usr/share
> /usr/share/doc
> /usr/share/doc/libc-ares-dev
> /usr/share/doc/libc-ares-dev/NEWS.gz
> /usr/share/doc/libc-ares-dev/README.cares
> /usr/share/doc/libc-ares-dev/README.md
> /usr/share/doc/libc-ares-dev/copyright
> /usr/share/man
> /usr/share/man/man3
> [ snip man pages ]
> /usr/lib/x86_64-linux-gnu/libcares.so
>
>
> Regards
>
> Antoine.
>
Re: [VOTE] Release Apache Arrow 0.14.0 - RC0
Posted by Antoine Pitrou <an...@python.org>.
I tried again (Ubuntu 18.04):
* binaries verification succeeded
* source verification failed in gRPC configure step:
CMake Error at cmake/cares.cmake:38 (find_package):
Could not find a package configuration file provided by "c-ares" with any
of the following names:
c-aresConfig.cmake
c-ares-config.cmake
Add the installation prefix of "c-ares" to CMAKE_PREFIX_PATH or set
"c-ares_DIR" to a directory containing one of the above files. If "c-ares"
provides a separate development package or SDK, be sure it has been
installed.
Call Stack (most recent call first):
CMakeLists.txt:139 (include)
Problem is, Ubuntu's c-ares does not provide any CMake files:
$ dpkg -L libc-ares-dev
/.
/usr
/usr/include
/usr/include/ares.h
/usr/include/ares_build.h
/usr/include/ares_dns.h
/usr/include/ares_rules.h
/usr/include/ares_version.h
/usr/lib
/usr/lib/x86_64-linux-gnu
/usr/lib/x86_64-linux-gnu/libcares.a
/usr/lib/x86_64-linux-gnu/pkgconfig
/usr/lib/x86_64-linux-gnu/pkgconfig/libcares.pc
/usr/share
/usr/share/doc
/usr/share/doc/libc-ares-dev
/usr/share/doc/libc-ares-dev/NEWS.gz
/usr/share/doc/libc-ares-dev/README.cares
/usr/share/doc/libc-ares-dev/README.md
/usr/share/doc/libc-ares-dev/copyright
/usr/share/man
/usr/share/man/man3
[ snip man pages ]
/usr/lib/x86_64-linux-gnu/libcares.so
Regards
Antoine.
Re: [VOTE] Release Apache Arrow 0.14.0 - RC0
Posted by Wes McKinney <we...@gmail.com>.
+1 (binding)
Thanks Kou for adding the missing signatures.
* I was able to verify the binaries after the signature fix. The Linux
package tests are very nice!
* I ran the following source verifications (on linux except where noted)
* C++ (Ubuntu 19.04 and Windows, with patch
https://github.com/apache/arrow/pull/4770)
* Python (UB19.04 / Windows)
* Java
* JS
* Ruby
* GLib
* Go
* Rust
* Integration tests with Flight (with minor patch
https://github.com/apache/arrow/pull/4775)
I only had trouble with C#, and it may be environment specific.
On Mon, Jul 1, 2019 at 4:32 PM Sutou Kouhei <ko...@clear-code.com> wrote:
>
> Hi,
>
> > but it failed with
> >
> > https://gist.github.com/wesm/711ae3d66c942db293dba55ff237871a
>
> Thanks for catching this.
> I failed to upload some files. I uploaded missing files.
>
> I confirmed that there are no missing files with the
> following Ruby script:
>
> --
> #!/usr/bin/env ruby
>
> require "open-uri"
> require "json"
> require "English"
>
> ["debian", "ubuntu", "centos", "python"].each do |target|
> json_path = "/tmp/#{target}-file-list.json"
> unless File.exist?(json_path)
> open("https://bintray.com/api/v1/packages/apache/arrow/#{target}-rc/versions/0.14.0-rc0/files") do |input|
> File.open(json_path, "w") do |json|
> IO.copy_stream(input, json)
> end
> end
> end
>
> source_paths = []
> asc_paths = []
> sha512_paths = []
> JSON.parse(File.read(json_path)).each do |entry|
> path = entry["path"]
> case path
> when /\.asc\z/
> asc_paths << $PREMATCH
> when /\.sha512\z/
> sha512_paths << $PREMATCH
> else
> source_paths << path
> end
> end
> pp([:no_asc, source_paths - asc_paths])
> pp([:no_source_for_asc, asc_paths - source_paths])
> pp([:no_sha512, source_paths - sha512_paths])
> pp([:no_source_for_sha512, sha512_paths - source_paths])
> end
> --
>
> But this is a bit strange. Download file list is read from
> Bintray (*). So I think that our verification script doesn't
> try downloading nonexistent files...
>
> (*) https://bintray.com/api/v1/packages/apache/arrow/debian-rc/versions/0.14.0-rc0/files
>
> > I'm going to work on verifying more components. C# is failing with
> >
> > https://gist.github.com/wesm/985146df6944a1aade331c4bd1519f1f
>
> I couldn't reproduce this on my environment.
> I'll try this with clean environment.
>
> Note that we can try only C# verification with the following
> command line:
>
> TEST_DEFAULT=0 TEST_SOURCE=1 TEST_CSHARP=1 dev/release/verify-release-candidate.sh source 0.14.0 0
>
> > Seems like we might need to find an
> > artifact staging solution that is not Bintray if API rate limits are
> > going to be a problem.
>
> I don't get response yet from https://bintray.com/apache
> organization. I'll open an issue on INFRA JIRA.
>
>
> Thanks,
> --
> kou
>
> In <CA...@mail.gmail.com>
> "Re: [VOTE] Release Apache Arrow 0.14.0 - RC0" on Mon, 1 Jul 2019 11:48:50 -0500,
> Wes McKinney <we...@gmail.com> wrote:
>
> > hi Antoine, I'm not sure the origin of the conda.sh failure, have you
> > tried removing any bashrc stuff related to the Anaconda distribution
> > that you develop against?
> >
> > With the following patch I'm able to run the binary verification
> >
> > https://github.com/apache/arrow/pull/4768
> >
> > but it failed with
> >
> > https://gist.github.com/wesm/711ae3d66c942db293dba55ff237871a
> >
> > Indeed a sig is missing from bintray. I was able to get the parallel
> > build to run on my machine (but it failed when I piped stdin/stdout to
> > a file) but I also found a bad sig
> >
> > https://gist.github.com/wesm/2404d55e087cc3982d93e53c83df95d5
> >
> > I'm going to work on verifying more components. C# is failing with
> >
> > https://gist.github.com/wesm/985146df6944a1aade331c4bd1519f1f
> >
> > but I don't think that should block the release (it would be nice if
> > it passed though)
> >
> > I'm going to work on the Windows verification script and see if I can
> > add Flight support to it
> >
> > All in all appears that an RC1 may be warranted unless the signature
> > issues can be remedied in RC0. Seems like we might need to find an
> > artifact staging solution that is not Bintray if API rate limits are
> > going to be a problem.
> >
> > - Wes
> >
> > On Mon, Jul 1, 2019 at 3:48 AM Antoine Pitrou <an...@python.org> wrote:
> >>
> >>
> >> On Ubuntu 18.04:
> >>
> >> - failed to verify binaries
> >>
> >> """
> >> + echo 'Failed to verify release candidate. See /tmp/arrow-0.14.0.gucvU
> >> for details.'
> >> Failed to verify release candidate. See /tmp/arrow-0.14.0.gucvU for details.
> >> """
> >>
> >> There's no details in /tmp/arrow-0.14.0.gucvU. The script left a lot of
> >> zombie curl processes running...
> >>
> >> - failed to verify sources
> >>
> >> """
> >> + export PATH
> >> /tmp/arrow-0.14.0.yum2X/apache-arrow-0.14.0/test-miniconda/etc/profile.d/conda.sh:
> >> line 55: PS1: unbound variable
> >> + ask_conda=
> >> + return 1
> >> + cleanup
> >> + '[' no = yes ']'
> >> + echo 'Failed to verify release candidate. See /tmp/arrow-0.14.0.yum2X
> >> for details.'
> >> Failed to verify release candidate. See /tmp/arrow-0.14.0.yum2X for details.
> >> """
> >>
> >> There's no details in /tmp/arrow-0.14.0.yum2X
> >>
> >> Regards
> >>
> >> Antoine.
> >>
> >>
> >>
> >>
> >>
> >> Le 01/07/2019 à 07:32, Sutou Kouhei a écrit :
> >> > Hi,
> >> >
> >> > I would like to propose the following release candidate (RC0) of Apache
> >> > Arrow version 0.14.0. This is a release consiting of 618
> >> > resolved JIRA issues[1].
> >> >
> >> > This release candidate is based on commit:
> >> > a591d76ad9a657110368aa422bb00f4010cb6b6e [2]
> >> >
> >> > The source release rc0 is hosted at [3].
> >> > The binary artifacts are hosted at [4][5][6][7].
> >> > The changelog is located at [8].
> >> >
> >> > Please download, verify checksums and signatures, run the unit tests,
> >> > and vote on the release. See [9] for how to validate a release candidate.
> >> >
> >> > NOTE: You must use verify-release-candidate.sh at master.
> >> > I've fixed some problems after apache-arrow-0.14.0 tag.
> >> > C#'s "sourcelink test" is fragile. (Network related problem?)
> >> > It may be better that we add retry logic to "sourcelink test".
> >> >
> >> > The vote will be open for at least 72 hours.
> >> >
> >> > [ ] +1 Release this as Apache Arrow 0.14.0
> >> > [ ] +0
> >> > [ ] -1 Do not release this as Apache Arrow 0.14.0 because...
> >> >
> >> > [1]: https://issues.apache.org/jira/issues/?jql=project%20%3D%20ARROW%20AND%20status%20in%20%28Resolved%2C%20Closed%29%20AND%20fixVersion%20%3D%200.14.0
> >> > [2]: https://github.com/apache/arrow/tree/a591d76ad9a657110368aa422bb00f4010cb6b6e
> >> > [3]: https://dist.apache.org/repos/dist/dev/arrow/apache-arrow-0.14.0-rc0
> >> > [4]: https://bintray.com/apache/arrow/centos-rc/0.14.0-rc0
> >> > [5]: https://bintray.com/apache/arrow/debian-rc/0.14.0-rc0
> >> > [6]: https://bintray.com/apache/arrow/python-rc/0.14.0-rc0
> >> > [7]: https://bintray.com/apache/arrow/ubuntu-rc/0.14.0-rc0
> >> > [8]: https://github.com/apache/arrow/blob/a591d76ad9a657110368aa422bb00f4010cb6b6e/CHANGELOG.md
> >> > [9]: https://cwiki.apache.org/confluence/display/ARROW/How+to+Verify+Release+Candidates
> >> >
> >> >
> >> > Thanks,
> >> > --
> >> > kou
> >> >
Re: [VOTE] Release Apache Arrow 0.14.0 - RC0
Posted by Sutou Kouhei <ko...@clear-code.com>.
Hi,
> but it failed with
>
> https://gist.github.com/wesm/711ae3d66c942db293dba55ff237871a
Thanks for catching this.
I failed to upload some files. I uploaded missing files.
I confirmed that there are no missing files with the
following Ruby script:
--
#!/usr/bin/env ruby
require "open-uri"
require "json"
require "English"
["debian", "ubuntu", "centos", "python"].each do |target|
json_path = "/tmp/#{target}-file-list.json"
unless File.exist?(json_path)
open("https://bintray.com/api/v1/packages/apache/arrow/#{target}-rc/versions/0.14.0-rc0/files") do |input|
File.open(json_path, "w") do |json|
IO.copy_stream(input, json)
end
end
end
source_paths = []
asc_paths = []
sha512_paths = []
JSON.parse(File.read(json_path)).each do |entry|
path = entry["path"]
case path
when /\.asc\z/
asc_paths << $PREMATCH
when /\.sha512\z/
sha512_paths << $PREMATCH
else
source_paths << path
end
end
pp([:no_asc, source_paths - asc_paths])
pp([:no_source_for_asc, asc_paths - source_paths])
pp([:no_sha512, source_paths - sha512_paths])
pp([:no_source_for_sha512, sha512_paths - source_paths])
end
--
But this is a bit strange. Download file list is read from
Bintray (*). So I think that our verification script doesn't
try downloading nonexistent files...
(*) https://bintray.com/api/v1/packages/apache/arrow/debian-rc/versions/0.14.0-rc0/files
> I'm going to work on verifying more components. C# is failing with
>
> https://gist.github.com/wesm/985146df6944a1aade331c4bd1519f1f
I couldn't reproduce this on my environment.
I'll try this with clean environment.
Note that we can try only C# verification with the following
command line:
TEST_DEFAULT=0 TEST_SOURCE=1 TEST_CSHARP=1 dev/release/verify-release-candidate.sh source 0.14.0 0
> Seems like we might need to find an
> artifact staging solution that is not Bintray if API rate limits are
> going to be a problem.
I don't get response yet from https://bintray.com/apache
organization. I'll open an issue on INFRA JIRA.
Thanks,
--
kou
In <CA...@mail.gmail.com>
"Re: [VOTE] Release Apache Arrow 0.14.0 - RC0" on Mon, 1 Jul 2019 11:48:50 -0500,
Wes McKinney <we...@gmail.com> wrote:
> hi Antoine, I'm not sure the origin of the conda.sh failure, have you
> tried removing any bashrc stuff related to the Anaconda distribution
> that you develop against?
>
> With the following patch I'm able to run the binary verification
>
> https://github.com/apache/arrow/pull/4768
>
> but it failed with
>
> https://gist.github.com/wesm/711ae3d66c942db293dba55ff237871a
>
> Indeed a sig is missing from bintray. I was able to get the parallel
> build to run on my machine (but it failed when I piped stdin/stdout to
> a file) but I also found a bad sig
>
> https://gist.github.com/wesm/2404d55e087cc3982d93e53c83df95d5
>
> I'm going to work on verifying more components. C# is failing with
>
> https://gist.github.com/wesm/985146df6944a1aade331c4bd1519f1f
>
> but I don't think that should block the release (it would be nice if
> it passed though)
>
> I'm going to work on the Windows verification script and see if I can
> add Flight support to it
>
> All in all appears that an RC1 may be warranted unless the signature
> issues can be remedied in RC0. Seems like we might need to find an
> artifact staging solution that is not Bintray if API rate limits are
> going to be a problem.
>
> - Wes
>
> On Mon, Jul 1, 2019 at 3:48 AM Antoine Pitrou <an...@python.org> wrote:
>>
>>
>> On Ubuntu 18.04:
>>
>> - failed to verify binaries
>>
>> """
>> + echo 'Failed to verify release candidate. See /tmp/arrow-0.14.0.gucvU
>> for details.'
>> Failed to verify release candidate. See /tmp/arrow-0.14.0.gucvU for details.
>> """
>>
>> There's no details in /tmp/arrow-0.14.0.gucvU. The script left a lot of
>> zombie curl processes running...
>>
>> - failed to verify sources
>>
>> """
>> + export PATH
>> /tmp/arrow-0.14.0.yum2X/apache-arrow-0.14.0/test-miniconda/etc/profile.d/conda.sh:
>> line 55: PS1: unbound variable
>> + ask_conda=
>> + return 1
>> + cleanup
>> + '[' no = yes ']'
>> + echo 'Failed to verify release candidate. See /tmp/arrow-0.14.0.yum2X
>> for details.'
>> Failed to verify release candidate. See /tmp/arrow-0.14.0.yum2X for details.
>> """
>>
>> There's no details in /tmp/arrow-0.14.0.yum2X
>>
>> Regards
>>
>> Antoine.
>>
>>
>>
>>
>>
>> Le 01/07/2019 à 07:32, Sutou Kouhei a écrit :
>> > Hi,
>> >
>> > I would like to propose the following release candidate (RC0) of Apache
>> > Arrow version 0.14.0. This is a release consiting of 618
>> > resolved JIRA issues[1].
>> >
>> > This release candidate is based on commit:
>> > a591d76ad9a657110368aa422bb00f4010cb6b6e [2]
>> >
>> > The source release rc0 is hosted at [3].
>> > The binary artifacts are hosted at [4][5][6][7].
>> > The changelog is located at [8].
>> >
>> > Please download, verify checksums and signatures, run the unit tests,
>> > and vote on the release. See [9] for how to validate a release candidate.
>> >
>> > NOTE: You must use verify-release-candidate.sh at master.
>> > I've fixed some problems after apache-arrow-0.14.0 tag.
>> > C#'s "sourcelink test" is fragile. (Network related problem?)
>> > It may be better that we add retry logic to "sourcelink test".
>> >
>> > The vote will be open for at least 72 hours.
>> >
>> > [ ] +1 Release this as Apache Arrow 0.14.0
>> > [ ] +0
>> > [ ] -1 Do not release this as Apache Arrow 0.14.0 because...
>> >
>> > [1]: https://issues.apache.org/jira/issues/?jql=project%20%3D%20ARROW%20AND%20status%20in%20%28Resolved%2C%20Closed%29%20AND%20fixVersion%20%3D%200.14.0
>> > [2]: https://github.com/apache/arrow/tree/a591d76ad9a657110368aa422bb00f4010cb6b6e
>> > [3]: https://dist.apache.org/repos/dist/dev/arrow/apache-arrow-0.14.0-rc0
>> > [4]: https://bintray.com/apache/arrow/centos-rc/0.14.0-rc0
>> > [5]: https://bintray.com/apache/arrow/debian-rc/0.14.0-rc0
>> > [6]: https://bintray.com/apache/arrow/python-rc/0.14.0-rc0
>> > [7]: https://bintray.com/apache/arrow/ubuntu-rc/0.14.0-rc0
>> > [8]: https://github.com/apache/arrow/blob/a591d76ad9a657110368aa422bb00f4010cb6b6e/CHANGELOG.md
>> > [9]: https://cwiki.apache.org/confluence/display/ARROW/How+to+Verify+Release+Candidates
>> >
>> >
>> > Thanks,
>> > --
>> > kou
>> >
Re: [VOTE] Release Apache Arrow 0.14.0 - RC0
Posted by Wes McKinney <we...@gmail.com>.
hi Antoine, I'm not sure the origin of the conda.sh failure, have you
tried removing any bashrc stuff related to the Anaconda distribution
that you develop against?
With the following patch I'm able to run the binary verification
https://github.com/apache/arrow/pull/4768
but it failed with
https://gist.github.com/wesm/711ae3d66c942db293dba55ff237871a
Indeed a sig is missing from bintray. I was able to get the parallel
build to run on my machine (but it failed when I piped stdin/stdout to
a file) but I also found a bad sig
https://gist.github.com/wesm/2404d55e087cc3982d93e53c83df95d5
I'm going to work on verifying more components. C# is failing with
https://gist.github.com/wesm/985146df6944a1aade331c4bd1519f1f
but I don't think that should block the release (it would be nice if
it passed though)
I'm going to work on the Windows verification script and see if I can
add Flight support to it
All in all appears that an RC1 may be warranted unless the signature
issues can be remedied in RC0. Seems like we might need to find an
artifact staging solution that is not Bintray if API rate limits are
going to be a problem.
- Wes
On Mon, Jul 1, 2019 at 3:48 AM Antoine Pitrou <an...@python.org> wrote:
>
>
> On Ubuntu 18.04:
>
> - failed to verify binaries
>
> """
> + echo 'Failed to verify release candidate. See /tmp/arrow-0.14.0.gucvU
> for details.'
> Failed to verify release candidate. See /tmp/arrow-0.14.0.gucvU for details.
> """
>
> There's no details in /tmp/arrow-0.14.0.gucvU. The script left a lot of
> zombie curl processes running...
>
> - failed to verify sources
>
> """
> + export PATH
> /tmp/arrow-0.14.0.yum2X/apache-arrow-0.14.0/test-miniconda/etc/profile.d/conda.sh:
> line 55: PS1: unbound variable
> + ask_conda=
> + return 1
> + cleanup
> + '[' no = yes ']'
> + echo 'Failed to verify release candidate. See /tmp/arrow-0.14.0.yum2X
> for details.'
> Failed to verify release candidate. See /tmp/arrow-0.14.0.yum2X for details.
> """
>
> There's no details in /tmp/arrow-0.14.0.yum2X
>
> Regards
>
> Antoine.
>
>
>
>
>
> Le 01/07/2019 à 07:32, Sutou Kouhei a écrit :
> > Hi,
> >
> > I would like to propose the following release candidate (RC0) of Apache
> > Arrow version 0.14.0. This is a release consiting of 618
> > resolved JIRA issues[1].
> >
> > This release candidate is based on commit:
> > a591d76ad9a657110368aa422bb00f4010cb6b6e [2]
> >
> > The source release rc0 is hosted at [3].
> > The binary artifacts are hosted at [4][5][6][7].
> > The changelog is located at [8].
> >
> > Please download, verify checksums and signatures, run the unit tests,
> > and vote on the release. See [9] for how to validate a release candidate.
> >
> > NOTE: You must use verify-release-candidate.sh at master.
> > I've fixed some problems after apache-arrow-0.14.0 tag.
> > C#'s "sourcelink test" is fragile. (Network related problem?)
> > It may be better that we add retry logic to "sourcelink test".
> >
> > The vote will be open for at least 72 hours.
> >
> > [ ] +1 Release this as Apache Arrow 0.14.0
> > [ ] +0
> > [ ] -1 Do not release this as Apache Arrow 0.14.0 because...
> >
> > [1]: https://issues.apache.org/jira/issues/?jql=project%20%3D%20ARROW%20AND%20status%20in%20%28Resolved%2C%20Closed%29%20AND%20fixVersion%20%3D%200.14.0
> > [2]: https://github.com/apache/arrow/tree/a591d76ad9a657110368aa422bb00f4010cb6b6e
> > [3]: https://dist.apache.org/repos/dist/dev/arrow/apache-arrow-0.14.0-rc0
> > [4]: https://bintray.com/apache/arrow/centos-rc/0.14.0-rc0
> > [5]: https://bintray.com/apache/arrow/debian-rc/0.14.0-rc0
> > [6]: https://bintray.com/apache/arrow/python-rc/0.14.0-rc0
> > [7]: https://bintray.com/apache/arrow/ubuntu-rc/0.14.0-rc0
> > [8]: https://github.com/apache/arrow/blob/a591d76ad9a657110368aa422bb00f4010cb6b6e/CHANGELOG.md
> > [9]: https://cwiki.apache.org/confluence/display/ARROW/How+to+Verify+Release+Candidates
> >
> >
> > Thanks,
> > --
> > kou
> >
Re: [VOTE] Release Apache Arrow 0.14.0 - RC0
Posted by Antoine Pitrou <an...@python.org>.
On Ubuntu 18.04:
- failed to verify binaries
"""
+ echo 'Failed to verify release candidate. See /tmp/arrow-0.14.0.gucvU
for details.'
Failed to verify release candidate. See /tmp/arrow-0.14.0.gucvU for details.
"""
There's no details in /tmp/arrow-0.14.0.gucvU. The script left a lot of
zombie curl processes running...
- failed to verify sources
"""
+ export PATH
/tmp/arrow-0.14.0.yum2X/apache-arrow-0.14.0/test-miniconda/etc/profile.d/conda.sh:
line 55: PS1: unbound variable
+ ask_conda=
+ return 1
+ cleanup
+ '[' no = yes ']'
+ echo 'Failed to verify release candidate. See /tmp/arrow-0.14.0.yum2X
for details.'
Failed to verify release candidate. See /tmp/arrow-0.14.0.yum2X for details.
"""
There's no details in /tmp/arrow-0.14.0.yum2X
Regards
Antoine.
Le 01/07/2019 à 07:32, Sutou Kouhei a écrit :
> Hi,
>
> I would like to propose the following release candidate (RC0) of Apache
> Arrow version 0.14.0. This is a release consiting of 618
> resolved JIRA issues[1].
>
> This release candidate is based on commit:
> a591d76ad9a657110368aa422bb00f4010cb6b6e [2]
>
> The source release rc0 is hosted at [3].
> The binary artifacts are hosted at [4][5][6][7].
> The changelog is located at [8].
>
> Please download, verify checksums and signatures, run the unit tests,
> and vote on the release. See [9] for how to validate a release candidate.
>
> NOTE: You must use verify-release-candidate.sh at master.
> I've fixed some problems after apache-arrow-0.14.0 tag.
> C#'s "sourcelink test" is fragile. (Network related problem?)
> It may be better that we add retry logic to "sourcelink test".
>
> The vote will be open for at least 72 hours.
>
> [ ] +1 Release this as Apache Arrow 0.14.0
> [ ] +0
> [ ] -1 Do not release this as Apache Arrow 0.14.0 because...
>
> [1]: https://issues.apache.org/jira/issues/?jql=project%20%3D%20ARROW%20AND%20status%20in%20%28Resolved%2C%20Closed%29%20AND%20fixVersion%20%3D%200.14.0
> [2]: https://github.com/apache/arrow/tree/a591d76ad9a657110368aa422bb00f4010cb6b6e
> [3]: https://dist.apache.org/repos/dist/dev/arrow/apache-arrow-0.14.0-rc0
> [4]: https://bintray.com/apache/arrow/centos-rc/0.14.0-rc0
> [5]: https://bintray.com/apache/arrow/debian-rc/0.14.0-rc0
> [6]: https://bintray.com/apache/arrow/python-rc/0.14.0-rc0
> [7]: https://bintray.com/apache/arrow/ubuntu-rc/0.14.0-rc0
> [8]: https://github.com/apache/arrow/blob/a591d76ad9a657110368aa422bb00f4010cb6b6e/CHANGELOG.md
> [9]: https://cwiki.apache.org/confluence/display/ARROW/How+to+Verify+Release+Candidates
>
>
> Thanks,
> --
> kou
>