[jira] [Created] (ARROW-3581) [Gandiva][C++] ARROW_PROTOBUF_USE_SHARED isn't used
Kouhei Sutou created ARROW-3581: --- Summary: [Gandiva][C++] ARROW_PROTOBUF_USE_SHARED isn't used Key: ARROW-3581 URL: https://issues.apache.org/jira/browse/ARROW-3581 Project: Apache Arrow Issue Type: Improvement Components: C++, Gandiva Affects Versions: 0.11.0 Reporter: Kouhei Sutou Assignee: Kouhei Sutou -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (ARROW-3580) [Gandiva][C++] Build error with g++ 8.2.0
Kouhei Sutou created ARROW-3580:
---
Summary: [Gandiva][C++] Build error with g++ 8.2.0
Key: ARROW-3580
URL: https://issues.apache.org/jira/browse/ARROW-3580
Project: Apache Arrow
Issue Type: Bug
Components: C++, Gandiva
Affects Versions: 0.11.0
Reporter: Kouhei Sutou
Assignee: Kouhei Sutou
Error message1:
{noformat}
In file included from
/home/kou/work/cpp/arrow.kou/cpp/src/gandiva/expr_decomposer.cc:27:
/home/kou/work/cpp/arrow.kou/cpp/src/gandiva/function_holder_registry.h:46:27:
error: 'function' in namespace 'std' does not name a template type
using maker_type = std::function;
^~~~
/home/kou/work/cpp/arrow.kou/cpp/src/gandiva/function_holder_registry.h:46:22:
note: 'std::function' is defined in header ''; did you forget to
'#include '?
/home/kou/work/cpp/arrow.kou/cpp/src/gandiva/function_holder_registry.h:30:1:
+#include
/home/kou/work/cpp/arrow.kou/cpp/src/gandiva/function_holder_registry.h:46:22:
using maker_type = std::function;
^~~
/home/kou/work/cpp/arrow.kou/cpp/src/gandiva/function_holder_registry.h:47:52:
error: 'maker_type' was not declared in this scope
using map_type = std::unordered_map;
^~
/home/kou/work/cpp/arrow.kou/cpp/src/gandiva/function_holder_registry.h:47:52:
note: suggested alternative: 'decltype'
using map_type = std::unordered_map;
^~
decltype
/home/kou/work/cpp/arrow.kou/cpp/src/gandiva/function_holder_registry.h:47:62:
error: template argument 2 is invalid
using map_type = std::unordered_map;
^
/home/kou/work/cpp/arrow.kou/cpp/src/gandiva/function_holder_registry.h:47:62:
error: template argument 5 is invalid
/home/kou/work/cpp/arrow.kou/cpp/src/gandiva/function_holder_registry.h:60:10:
error: 'map_type' does not name a type; did you mean 'iswctype'?
static map_type& makers() {
^~~~
iswctype
/home/kou/work/cpp/arrow.kou/cpp/src/gandiva/function_holder_registry.h: In
static member function 'static gandiva::Status
gandiva::FunctionHolderRegistry::Make(const string&, const
gandiva::FunctionNode&, gandiva::FunctionHolderPtr*)':
/home/kou/work/cpp/arrow.kou/cpp/src/gandiva/function_holder_registry.h:51:18:
error: 'makers' was not declared in this scope
auto found = makers().find(name);
^~
/home/kou/work/cpp/arrow.kou/cpp/src/gandiva/function_holder_registry.h:51:18:
note: suggested alternative: 'Make'
auto found = makers().find(name);
^~
Make
{noformat}
Error message2:
{noformat}
/home/kou/work/cpp/arrow.kou/cpp/src/gandiva/tree_expr_builder.cc: In static
member function 'static gandiva::NodePtr
gandiva::TreeExprBuilder::MakeNull(gandiva::DataTypePtr)':
/home/kou/work/cpp/arrow.kou/cpp/src/gandiva/tree_expr_builder.cc:78:70: error:
'float_t' was not declared in this scope
return std::make_shared(data_type,
LiteralHolder((float_t)0), true);
^~~
/home/kou/work/cpp/arrow.kou/cpp/src/gandiva/tree_expr_builder.cc:78:70: note:
suggested alternative: 'float'
return std::make_shared(data_type,
LiteralHolder((float_t)0), true);
^~~
float
/home/kou/work/cpp/arrow.kou/cpp/src/gandiva/tree_expr_builder.cc:80:70: error:
'double_t' was not declared in this scope
return std::make_shared(data_type,
LiteralHolder((double_t)0), true);
^~~~
/home/kou/work/cpp/arrow.kou/cpp/src/gandiva/tree_expr_builder.cc:80:70: note:
suggested alternative: 'double'
return std::make_shared(data_type,
LiteralHolder((double_t)0), true);
^~~~
double
{noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
Re: Making a bugfix 0.11.1 release
Looks like I need https://github.com/apache/arrow/commit/274237cfd396a8cb3424c12ef75e7267e0480cb9. I'll cherry-pick that into the maint branch and start making a new RC On Sat, Oct 20, 2018 at 4:55 PM Wes McKinney wrote: > > I created 0.11.1 RC0 but verification (verify-release-candidate.sh > source 0.11.1 0) fails with > > + export GI_TYPELIB_PATH=/tmp/arrow-0.11.1.Cpdsj/install/lib/girepository-1.0: > + GI_TYPELIB_PATH=/tmp/arrow-0.11.1.Cpdsj/install/lib/girepository-1.0: > + bundle --version > Bundler version 1.16.5 > + bundle install --path vendor/bundle > >>> Could not locate Gemfile > + cleanup > + rm -fr /tmp/arrow-0.11.1.Cpdsj > > @Kou -- what should I do? > > Thanks > Wes > On Sat, Oct 20, 2018 at 2:16 PM Wes McKinney wrote: > > > > I'm working on the source release now. We need to try to determine the > > cause of the spurious RAT errors: > > > > https://gist.github.com/wesm/490dc50c494cc914ae28b4fd897a73eb > > On Sat, Oct 20, 2018 at 11:27 AM Wes McKinney wrote: > > > > > > Seems that Travis CI builds are triggering Appveyor builds, so things > > > show up as failed > > > > > > https://github.com/wesm/crossbow/branches/all?utf8=%E2%9C%93=build-8 > > > > > > On Sat, Oct 20, 2018 at 10:18 AM Uwe L. Korn wrote: > > > > > > > > I have triggered the wheel builds on my crossbow repo with build-25, > > > > feel free to use them. > > > > > > > > Uwe > > > > > > > > On Sat, Oct 20, 2018, at 3:52 PM, Wes McKinney wrote: > > > > > I'm having problems with Crossbow. I am going to try a few things > > > > > (going through the setup process "from scratch" -- new tokens, new > > > > > local repositories, etc.) but if I can't figure it out today, a > > > > > different PMC with a working Crossbow setup may need to cut the > > > > > release candidate artifacts > > > > > On Fri, Oct 19, 2018 at 10:48 AM Wes McKinney > > > > > wrote: > > > > > > > > > > > > I prepared the maintenance branch here > > > > > > > > > > > > https://github.com/apache/arrow/tree/maint-0.11.x > > > > > > > > > > > > I'm not fully set up with to create a release candidate yet with > > > > > > Crossbow but I'll work on it today and try to get a vote started by > > > > > > EOD > > > > > > On Fri, Oct 19, 2018 at 3:45 AM Antoine Pitrou > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > I would recommend cherry-picking a minimal number of patches for > > > > > > > the > > > > > > > bugfix and for packaging to work. It's better not to include API > > > > > > > additions or changes. > > > > > > > > > > > > > > Regards > > > > > > > > > > > > > > Antoine. > > > > > > > > > > > > > > > > > > > > > Le 17/10/2018 à 03:32, Wes McKinney a écrit : > > > > > > > > hi folks, > > > > > > > > > > > > > > > > As a result of ARROW-3514, we need to release new Python > > > > > > > > packages > > > > > > > > quite urgently since major functionality (Parquet writing on > > > > > > > > many > > > > > > > > Linux platforms) is broken out of the box > > > > > > > > > > > > > > > > https://github.com/apache/arrow/commit/66d9a30a26e1659d9e992037339515e59a6ae518 > > > > > > > > > > > > > > > > We have a couple options: > > > > > > > > > > > > > > > > * Release from master > > > > > > > > * Release 0.11.0 + minimum patches to include the ARROW-3514 > > > > > > > > fix and > > > > > > > > any follow up patches to fix packaging > > > > > > > > > > > > > > > > There is the option to "not" release but it could cause > > > > > > > > confusion for > > > > > > > > people because PyPI does not allow replacing wheels; a new > > > > > > > > version > > > > > > > > number has to be created. > > > > > > > > > > > > > > > > What would folks like to do? Who can help with the RM duties? > > > > > > > > Since a > > > > > > > > 72 hour vote is a _should_ rather than _must_, we could > > > > > > > > reasonably > > > > > > > > close the release vote in < 72 hours and push out packages > > > > > > > > faster if > > > > > > > > it is scope limited to the zlib bug fix > > > > > > > > > > > > > > > > Thanks, > > > > > > > > Wes > > > > > > > >
Re: Making a bugfix 0.11.1 release
I created 0.11.1 RC0 but verification (verify-release-candidate.sh source 0.11.1 0) fails with + export GI_TYPELIB_PATH=/tmp/arrow-0.11.1.Cpdsj/install/lib/girepository-1.0: + GI_TYPELIB_PATH=/tmp/arrow-0.11.1.Cpdsj/install/lib/girepository-1.0: + bundle --version Bundler version 1.16.5 + bundle install --path vendor/bundle >>> Could not locate Gemfile + cleanup + rm -fr /tmp/arrow-0.11.1.Cpdsj @Kou -- what should I do? Thanks Wes On Sat, Oct 20, 2018 at 2:16 PM Wes McKinney wrote: > > I'm working on the source release now. We need to try to determine the > cause of the spurious RAT errors: > > https://gist.github.com/wesm/490dc50c494cc914ae28b4fd897a73eb > On Sat, Oct 20, 2018 at 11:27 AM Wes McKinney wrote: > > > > Seems that Travis CI builds are triggering Appveyor builds, so things > > show up as failed > > > > https://github.com/wesm/crossbow/branches/all?utf8=%E2%9C%93=build-8 > > > > On Sat, Oct 20, 2018 at 10:18 AM Uwe L. Korn wrote: > > > > > > I have triggered the wheel builds on my crossbow repo with build-25, feel > > > free to use them. > > > > > > Uwe > > > > > > On Sat, Oct 20, 2018, at 3:52 PM, Wes McKinney wrote: > > > > I'm having problems with Crossbow. I am going to try a few things > > > > (going through the setup process "from scratch" -- new tokens, new > > > > local repositories, etc.) but if I can't figure it out today, a > > > > different PMC with a working Crossbow setup may need to cut the > > > > release candidate artifacts > > > > On Fri, Oct 19, 2018 at 10:48 AM Wes McKinney > > > > wrote: > > > > > > > > > > I prepared the maintenance branch here > > > > > > > > > > https://github.com/apache/arrow/tree/maint-0.11.x > > > > > > > > > > I'm not fully set up with to create a release candidate yet with > > > > > Crossbow but I'll work on it today and try to get a vote started by > > > > > EOD > > > > > On Fri, Oct 19, 2018 at 3:45 AM Antoine Pitrou > > > > > wrote: > > > > > > > > > > > > > > > > > > I would recommend cherry-picking a minimal number of patches for the > > > > > > bugfix and for packaging to work. It's better not to include API > > > > > > additions or changes. > > > > > > > > > > > > Regards > > > > > > > > > > > > Antoine. > > > > > > > > > > > > > > > > > > Le 17/10/2018 à 03:32, Wes McKinney a écrit : > > > > > > > hi folks, > > > > > > > > > > > > > > As a result of ARROW-3514, we need to release new Python packages > > > > > > > quite urgently since major functionality (Parquet writing on many > > > > > > > Linux platforms) is broken out of the box > > > > > > > > > > > > > > https://github.com/apache/arrow/commit/66d9a30a26e1659d9e992037339515e59a6ae518 > > > > > > > > > > > > > > We have a couple options: > > > > > > > > > > > > > > * Release from master > > > > > > > * Release 0.11.0 + minimum patches to include the ARROW-3514 fix > > > > > > > and > > > > > > > any follow up patches to fix packaging > > > > > > > > > > > > > > There is the option to "not" release but it could cause confusion > > > > > > > for > > > > > > > people because PyPI does not allow replacing wheels; a new version > > > > > > > number has to be created. > > > > > > > > > > > > > > What would folks like to do? Who can help with the RM duties? > > > > > > > Since a > > > > > > > 72 hour vote is a _should_ rather than _must_, we could reasonably > > > > > > > close the release vote in < 72 hours and push out packages faster > > > > > > > if > > > > > > > it is scope limited to the zlib bug fix > > > > > > > > > > > > > > Thanks, > > > > > > > Wes > > > > > > >
[jira] [Created] (ARROW-3579) [Crossbow] Unintuitive error message when remote branch has not been pushed
Wes McKinney created ARROW-3579:
---
Summary: [Crossbow] Unintuitive error message when remote branch
has not been pushed
Key: ARROW-3579
URL: https://issues.apache.org/jira/browse/ARROW-3579
Project: Apache Arrow
Issue Type: Improvement
Components: Developer Tools
Reporter: Wes McKinney
Fix For: 0.12.0
{code}
$ python dev/tasks/crossbow.py submit -g linux --arrow-version 0.11.1-rc0
Traceback (most recent call last):
File "dev/tasks/crossbow.py", line 796, in
crossbow(obj={}, auto_envvar_prefix='CROSSBOW')
File
"/home/wesm/miniconda/envs/arrow-release/lib/python3.6/site-packages/click/core.py",
line 764, in __call__
return self.main(*args, **kwargs)
File
"/home/wesm/miniconda/envs/arrow-release/lib/python3.6/site-packages/click/core.py",
line 717, in main
rv = self.invoke(ctx)
File
"/home/wesm/miniconda/envs/arrow-release/lib/python3.6/site-packages/click/core.py",
line 1137, in invoke
return _process_result(sub_ctx.command.invoke(sub_ctx))
File
"/home/wesm/miniconda/envs/arrow-release/lib/python3.6/site-packages/click/core.py",
line 956, in invoke
return ctx.invoke(self.callback, **ctx.params)
File
"/home/wesm/miniconda/envs/arrow-release/lib/python3.6/site-packages/click/core.py",
line 555, in invoke
return callback(*args, **kwargs)
File
"/home/wesm/miniconda/envs/arrow-release/lib/python3.6/site-packages/click/decorators.py",
line 17, in new_func
return f(get_current_context(), *args, **kwargs)
File "dev/tasks/crossbow.py", line 596, in submit
target = Target.from_repo(arrow)
File "dev/tasks/crossbow.py", line 407, in from_repo
remote=repo.remote_url,
File "dev/tasks/crossbow.py", line 235, in remote_url
return self.remote.url.replace(
File "dev/tasks/crossbow.py", line 225, in remote
return self.repo.remotes[self.branch.upstream.remote_name]
AttributeError: 'NoneType' object has no attribute 'remote_name'
{code}
The fix was to make sure the local branch and the reference branch for the
build in my fork wesm/arrow was the same
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (ARROW-3578) [Release] Address spurious Apache RAT failures in source release script
Wes McKinney created ARROW-3578: --- Summary: [Release] Address spurious Apache RAT failures in source release script Key: ARROW-3578 URL: https://issues.apache.org/jira/browse/ARROW-3578 Project: Apache Arrow Issue Type: Bug Components: Developer Tools Reporter: Wes McKinney Fix For: 0.12.0 Something about the untarring / retarring process is offending Apache RAT and it's reporting a number of unapproved licenses incorrectly https://gist.github.com/wesm/490dc50c494cc914ae28b4fd897a73eb -- This message was sent by Atlassian JIRA (v7.6.3#76005)
Re: Making a bugfix 0.11.1 release
I'm working on the source release now. We need to try to determine the cause of the spurious RAT errors: https://gist.github.com/wesm/490dc50c494cc914ae28b4fd897a73eb On Sat, Oct 20, 2018 at 11:27 AM Wes McKinney wrote: > > Seems that Travis CI builds are triggering Appveyor builds, so things > show up as failed > > https://github.com/wesm/crossbow/branches/all?utf8=%E2%9C%93=build-8 > > On Sat, Oct 20, 2018 at 10:18 AM Uwe L. Korn wrote: > > > > I have triggered the wheel builds on my crossbow repo with build-25, feel > > free to use them. > > > > Uwe > > > > On Sat, Oct 20, 2018, at 3:52 PM, Wes McKinney wrote: > > > I'm having problems with Crossbow. I am going to try a few things > > > (going through the setup process "from scratch" -- new tokens, new > > > local repositories, etc.) but if I can't figure it out today, a > > > different PMC with a working Crossbow setup may need to cut the > > > release candidate artifacts > > > On Fri, Oct 19, 2018 at 10:48 AM Wes McKinney wrote: > > > > > > > > I prepared the maintenance branch here > > > > > > > > https://github.com/apache/arrow/tree/maint-0.11.x > > > > > > > > I'm not fully set up with to create a release candidate yet with > > > > Crossbow but I'll work on it today and try to get a vote started by > > > > EOD > > > > On Fri, Oct 19, 2018 at 3:45 AM Antoine Pitrou > > > > wrote: > > > > > > > > > > > > > > > I would recommend cherry-picking a minimal number of patches for the > > > > > bugfix and for packaging to work. It's better not to include API > > > > > additions or changes. > > > > > > > > > > Regards > > > > > > > > > > Antoine. > > > > > > > > > > > > > > > Le 17/10/2018 à 03:32, Wes McKinney a écrit : > > > > > > hi folks, > > > > > > > > > > > > As a result of ARROW-3514, we need to release new Python packages > > > > > > quite urgently since major functionality (Parquet writing on many > > > > > > Linux platforms) is broken out of the box > > > > > > > > > > > > https://github.com/apache/arrow/commit/66d9a30a26e1659d9e992037339515e59a6ae518 > > > > > > > > > > > > We have a couple options: > > > > > > > > > > > > * Release from master > > > > > > * Release 0.11.0 + minimum patches to include the ARROW-3514 fix and > > > > > > any follow up patches to fix packaging > > > > > > > > > > > > There is the option to "not" release but it could cause confusion > > > > > > for > > > > > > people because PyPI does not allow replacing wheels; a new version > > > > > > number has to be created. > > > > > > > > > > > > What would folks like to do? Who can help with the RM duties? Since > > > > > > a > > > > > > 72 hour vote is a _should_ rather than _must_, we could reasonably > > > > > > close the release vote in < 72 hours and push out packages faster if > > > > > > it is scope limited to the zlib bug fix > > > > > > > > > > > > Thanks, > > > > > > Wes > > > > > >
Re: Support for TIMESTAMP_NANOS in parquet-cpp
hi Roman, We would welcome adding such a document to the Arrow wiki https://cwiki.apache.org/confluence/display/ARROW. As to your other questions, it really depends on whether there is a member of the Parquet community who will do the work. Patches that implement any released functionality in the Parquet format specification are welcome. Thanks Wes On Thu, Oct 18, 2018 at 10:59 AM Roman Karlstetter wrote: > > Hi everyone, > in parquet-format, there is now support for TIMESTAMP_NANOS: > https://github.com/apache/parquet-format/pull/102 > For parquet-cpp, this is not yet supported. I have a few questions now: > • is there an overview of what release of parquet-format is currently fully > support in parquet-cpp (something like a feature support matrix)? > • how fast are new features in parquet-format adopted? > I think having a document describing the current completeness of > implementation of the spec would be very helpful for users of the parquet-cpp > library. > Thanks, > Roman > >
Re: Making a bugfix 0.11.1 release
Seems that Travis CI builds are triggering Appveyor builds, so things show up as failed https://github.com/wesm/crossbow/branches/all?utf8=%E2%9C%93=build-8 On Sat, Oct 20, 2018 at 10:18 AM Uwe L. Korn wrote: > > I have triggered the wheel builds on my crossbow repo with build-25, feel > free to use them. > > Uwe > > On Sat, Oct 20, 2018, at 3:52 PM, Wes McKinney wrote: > > I'm having problems with Crossbow. I am going to try a few things > > (going through the setup process "from scratch" -- new tokens, new > > local repositories, etc.) but if I can't figure it out today, a > > different PMC with a working Crossbow setup may need to cut the > > release candidate artifacts > > On Fri, Oct 19, 2018 at 10:48 AM Wes McKinney wrote: > > > > > > I prepared the maintenance branch here > > > > > > https://github.com/apache/arrow/tree/maint-0.11.x > > > > > > I'm not fully set up with to create a release candidate yet with > > > Crossbow but I'll work on it today and try to get a vote started by > > > EOD > > > On Fri, Oct 19, 2018 at 3:45 AM Antoine Pitrou wrote: > > > > > > > > > > > > I would recommend cherry-picking a minimal number of patches for the > > > > bugfix and for packaging to work. It's better not to include API > > > > additions or changes. > > > > > > > > Regards > > > > > > > > Antoine. > > > > > > > > > > > > Le 17/10/2018 à 03:32, Wes McKinney a écrit : > > > > > hi folks, > > > > > > > > > > As a result of ARROW-3514, we need to release new Python packages > > > > > quite urgently since major functionality (Parquet writing on many > > > > > Linux platforms) is broken out of the box > > > > > > > > > > https://github.com/apache/arrow/commit/66d9a30a26e1659d9e992037339515e59a6ae518 > > > > > > > > > > We have a couple options: > > > > > > > > > > * Release from master > > > > > * Release 0.11.0 + minimum patches to include the ARROW-3514 fix and > > > > > any follow up patches to fix packaging > > > > > > > > > > There is the option to "not" release but it could cause confusion for > > > > > people because PyPI does not allow replacing wheels; a new version > > > > > number has to be created. > > > > > > > > > > What would folks like to do? Who can help with the RM duties? Since a > > > > > 72 hour vote is a _should_ rather than _must_, we could reasonably > > > > > close the release vote in < 72 hours and push out packages faster if > > > > > it is scope limited to the zlib bug fix > > > > > > > > > > Thanks, > > > > > Wes > > > > >
[jira] [Created] (ARROW-3577) [Go] add support for ChunkedArray
Sebastien Binet created ARROW-3577: -- Summary: [Go] add support for ChunkedArray Key: ARROW-3577 URL: https://issues.apache.org/jira/browse/ARROW-3577 Project: Apache Arrow Issue Type: Improvement Components: Go Reporter: Sebastien Binet Assignee: Sebastien Binet -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (ARROW-3576) [Python
Wes McKinney created ARROW-3576: --- Summary: [Python Key: ARROW-3576 URL: https://issues.apache.org/jira/browse/ARROW-3576 Project: Apache Arrow Issue Type: Improvement Reporter: Wes McKinney -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (ARROW-3575) [Python] New documentation page for CSV reader
Wes McKinney created ARROW-3575: --- Summary: [Python] New documentation page for CSV reader Key: ARROW-3575 URL: https://issues.apache.org/jira/browse/ARROW-3575 Project: Apache Arrow Issue Type: Improvement Components: Python Reporter: Wes McKinney Fix For: 0.12.0 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
Re: Making a bugfix 0.11.1 release
I have triggered the wheel builds on my crossbow repo with build-25, feel free to use them. Uwe On Sat, Oct 20, 2018, at 3:52 PM, Wes McKinney wrote: > I'm having problems with Crossbow. I am going to try a few things > (going through the setup process "from scratch" -- new tokens, new > local repositories, etc.) but if I can't figure it out today, a > different PMC with a working Crossbow setup may need to cut the > release candidate artifacts > On Fri, Oct 19, 2018 at 10:48 AM Wes McKinney wrote: > > > > I prepared the maintenance branch here > > > > https://github.com/apache/arrow/tree/maint-0.11.x > > > > I'm not fully set up with to create a release candidate yet with > > Crossbow but I'll work on it today and try to get a vote started by > > EOD > > On Fri, Oct 19, 2018 at 3:45 AM Antoine Pitrou wrote: > > > > > > > > > I would recommend cherry-picking a minimal number of patches for the > > > bugfix and for packaging to work. It's better not to include API > > > additions or changes. > > > > > > Regards > > > > > > Antoine. > > > > > > > > > Le 17/10/2018 à 03:32, Wes McKinney a écrit : > > > > hi folks, > > > > > > > > As a result of ARROW-3514, we need to release new Python packages > > > > quite urgently since major functionality (Parquet writing on many > > > > Linux platforms) is broken out of the box > > > > > > > > https://github.com/apache/arrow/commit/66d9a30a26e1659d9e992037339515e59a6ae518 > > > > > > > > We have a couple options: > > > > > > > > * Release from master > > > > * Release 0.11.0 + minimum patches to include the ARROW-3514 fix and > > > > any follow up patches to fix packaging > > > > > > > > There is the option to "not" release but it could cause confusion for > > > > people because PyPI does not allow replacing wheels; a new version > > > > number has to be created. > > > > > > > > What would folks like to do? Who can help with the RM duties? Since a > > > > 72 hour vote is a _should_ rather than _must_, we could reasonably > > > > close the release vote in < 72 hours and push out packages faster if > > > > it is scope limited to the zlib bug fix > > > > > > > > Thanks, > > > > Wes > > > >
Re: Making a bugfix 0.11.1 release
I'm having problems with Crossbow. I am going to try a few things (going through the setup process "from scratch" -- new tokens, new local repositories, etc.) but if I can't figure it out today, a different PMC with a working Crossbow setup may need to cut the release candidate artifacts On Fri, Oct 19, 2018 at 10:48 AM Wes McKinney wrote: > > I prepared the maintenance branch here > > https://github.com/apache/arrow/tree/maint-0.11.x > > I'm not fully set up with to create a release candidate yet with > Crossbow but I'll work on it today and try to get a vote started by > EOD > On Fri, Oct 19, 2018 at 3:45 AM Antoine Pitrou wrote: > > > > > > I would recommend cherry-picking a minimal number of patches for the > > bugfix and for packaging to work. It's better not to include API > > additions or changes. > > > > Regards > > > > Antoine. > > > > > > Le 17/10/2018 à 03:32, Wes McKinney a écrit : > > > hi folks, > > > > > > As a result of ARROW-3514, we need to release new Python packages > > > quite urgently since major functionality (Parquet writing on many > > > Linux platforms) is broken out of the box > > > > > > https://github.com/apache/arrow/commit/66d9a30a26e1659d9e992037339515e59a6ae518 > > > > > > We have a couple options: > > > > > > * Release from master > > > * Release 0.11.0 + minimum patches to include the ARROW-3514 fix and > > > any follow up patches to fix packaging > > > > > > There is the option to "not" release but it could cause confusion for > > > people because PyPI does not allow replacing wheels; a new version > > > number has to be created. > > > > > > What would folks like to do? Who can help with the RM duties? Since a > > > 72 hour vote is a _should_ rather than _must_, we could reasonably > > > close the release vote in < 72 hours and push out packages faster if > > > it is scope limited to the zlib bug fix > > > > > > Thanks, > > > Wes > > >
Re: [VOTE] Accept donation of Ruby bindings to Parquet GLib
+1 On Fri, Oct 19, 2018, 1:09 AM Krisztián Szűcs wrote: > +1 > > On Fri, Oct 19, 2018, 9:44 AM Antoine Pitrou wrote: > > > > > +1 from me. Makes entire sense. > > > > > > Le 18/10/2018 à 23:02, Uwe L. Korn a écrit : > > > +1 > > > > > >> Am 18.10.2018 um 22:59 schrieb Wes McKinney : > > >> > > >> hello, > > >> > > >> Kouhei Sutou is proposing to donate Ruby bindings to the Parquet GLib > > >> library, which was received as a donation in September. This Ruby > > >> library was originally developed at > > >> > > >> https://github.com/red-data-tools/red-parquet/ > > >> > > >> Kou has submitted the work as a pull request > > >> https://github.com/apache/arrow/pull/2772 > > >> > > >> This vote is to determine if the Arrow PMC is in favor of accepting > > >> this donation, subject to the fulfillment of the ASF IP Clearance > > process. > > >> > > >>[ ] +1 : Accept contribution of Ruby Parquet bindings > > >>[ ] 0 : No opinion > > >>[ ] -1 : Reject contribution because... > > >> > > >> Here is my vote: +1 > > >> > > >> The vote will be open for at least 72 hours. > > >> > > >> Thanks, > > >> Wes > > >
[jira] [Created] (ARROW-3574) Fix remaining bug with plasma static versus shared libraries.
Robert Nishihara created ARROW-3574:
---
Summary: Fix remaining bug with plasma static versus shared
libraries.
Key: ARROW-3574
URL: https://issues.apache.org/jira/browse/ARROW-3574
Project: Apache Arrow
Issue Type: Improvement
Components: Plasma (C++)
Reporter: Robert Nishihara
Assignee: Robert Nishihara
Address a few missing pieces in [https://github.com/apache/arrow/pull/2792.] On
Mac, moving the {{plasma_store_server}} executable around and then executing it
leads to
{code:java}
dyld: Library not loaded: @rpath/libarrow.12.dylib
Referenced from:
/Users/rkn/Workspace/ray/./python/ray/core/src/plasma/plasma_store_server
Reason: image not found
Abort trap: 6{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
