RE: Travis CI jobs gummed up on Arrow PRs?
We got a response at https://travis-ci.community/t/s390x-jobs-are-stuck-in-the-received-state-for-days/10581/3?u=kiszk . Now, this problem has been solved. An interesting comment in the post is as follow: > If you would like to have an increased build capacity, we are happy to discuss the plans with you. Please send email to supp...@travis-ci.com. Regards, Kazuaki Ishizaki From: Andrew Lamb To: dev@arrow.apache.org Date: 2020/11/16 19:37 Subject:[EXTERNAL] Re: Travis CI jobs gummed up on Arrow PRs? Thank you! On Sun, Nov 15, 2020 at 8:30 PM Kazuaki Ishizaki wrote: > I have just reported this issue at the TravisCI forum. > > > https://travis-ci.community/t/s390x-jobs-have-not-been-almost-executed/10581 > > Regards, > Kazuaki Ishizaki, > > Sutou Kouhei wrote on 2020/11/16 10:02:18: > > > From: Sutou Kouhei > > To: dev@arrow.apache.org > > Date: 2020/11/16 10:02 > > Subject: [EXTERNAL] Re: Travis CI jobs gummed up on Arrow PRs? > > > > Hi, > > > > > 1. Is anyone else knows about these failures? > > > > "these failures" means that the Travis CI jobs aren't ran, > > right? (It doesn't mean that the Travis CI jobs reports > > "failure".) > > > > This may be a Travis CI bug. > > > > > 2. Should we look into disabling these checks for PRs that only touch > rust > > > code? I can do this, but am not sure of the history > > > > One approach is adding "[travis skip]" to commit message. > > We can't use path based conditional build on Travis CI > > because Travis CI doesn't provide the feature. > > > > See also: > > > > * INVALID URI REMOVED > > > > u=https-3A__docs.travis-2Dci.com_user_conditions-2Dv1=DwICAg=jf_iaSHvJObTbx- > > siA1ZOg=b70dG_9wpCdZSkBJahHYQ4IwKMdp2hQM29f-ZCGj9Pg=U4B_SrhIun- > > kKemWyzO5XUEZhrCIfFKnR967kBAI3rE=iGmV- > > uUdAjCFprWPStYvU1jHvMt7D2YM8hmtdRLC4n4= > > * INVALID URI REMOVED > > > > u=https-3A__docs.travis-2Dci.com_user_conditions-2Dtesting=DwICAg=jf_iaSHvJObTbx- > > siA1ZOg=b70dG_9wpCdZSkBJahHYQ4IwKMdp2hQM29f-ZCGj9Pg=U4B_SrhIun- > > > > kKemWyzO5XUEZhrCIfFKnR967kBAI3rE=yO4rf79YYHbt8NJKOLGaCKMKUehCe_ub2RtpDLq06QA= > > > > > > Thanks, > > -- > > kou > > > > In > > "Travis CI jobs gummed up on Arrow PRs?" on Sun, 15 Nov 2020 07:55:27 > -0500, > > Andrew Lamb wrote: > > > > > Sorry if this has already been discussed. > > > > > > There seems to be something wrong with the Travis CI jobs on some > Arrow PRs > > > -- for example, > > > INVALID URI REMOVED > > > > u=https-3A__github.com_apache_arrow_pull_8662_checks-3Fcheck-5Frun-5Fid-3D1400052607=DwICAg=jf_iaSHvJObTbx- > > siA1ZOg=b70dG_9wpCdZSkBJahHYQ4IwKMdp2hQM29f-ZCGj9Pg=U4B_SrhIun- > > kKemWyzO5XUEZhrCIfFKnR967kBAI3rE=V6iophseGVoYXwP1pLHBNtuMiHnEjT2bj69- > > iULRCZc= . > > > They go into the "pending" state and never seem to actually run. > > > > > > Since these appear to be checks of the C++ implementation on s390 or > ARM, > > > which aren't relevant to the Rust implementation, it isn't really > blocking > > > anything. > > > > > > I am wondering > > > 1. Is anyone else knows about these failures? > > > 2. Should we look into disabling these checks for PRs that only touch > rust > > > code? I can do this, but am not sure of the history > > > > > > Thank you, > > > Andrew > > > > > > p.s. here is another example of a non rust PR that seems to show the > same > > > issue: > > > INVALID URI REMOVED > > u=https-3A__github.com_apache_arrow_pull_8647=DwICAg=jf_iaSHvJObTbx- > > siA1ZOg=b70dG_9wpCdZSkBJahHYQ4IwKMdp2hQM29f-ZCGj9Pg=U4B_SrhIun- > > > > kKemWyzO5XUEZhrCIfFKnR967kBAI3rE=lA3pYfzvwvn9bMYt2saPIQe5ZmC11vkGCPO8g6TyMMM= > > > > > > p.p.s. Here is a screenshot showing the travis CI UI for such a gummed > up > > > test > > > > > > [image: Screen Shot 2020-11-15 at 7.50.27 AM.png] > > > > >
Graph model in arrow
Hi, I am thinking of building out a Query system using Arrow. I have a graph data model with objects having bidirectional relationships to each other. Objects are persisted in an OLTP system with normalized schema. Queries are scan-like queries across multiple object types having nested relationships. Looked at Tensor types but its still unclear how to model relationships with Arrow types. Any thoughts? ideas? Thanks Leo
Re: Using arrow/compute/kernels/*internal.h headers
1. This is great. I will follow this JIRA. (better yet, I'll see if I can
make that contribution)
2. If we forget about the multithreading case for a moment, this
requirement came up while implementing a "groupby + aggregation" operation
(single-threaded). Let's assume that a table is not sorted. So, the
simplest approach would be to keep the intermediate state in a container
(map/vector) and update the state while traversing the table. This approach
becomes important when there is a large number of groups and there aren't
enough rows with the same key to use 'consume' vector aggregation (on a
sorted table).
On Tue, Nov 17, 2020 at 10:54 AM Benjamin Kietzman
wrote:
> Hi Niranda,
>
> hastebin: That looks generally correct, though I should warn you that a
> recent PR
> ( https://github.com/apache/arrow/pull/8574 ) changed the return type of
> DispatchExact to Kernel so you'll need to insert an explicit cast to
> ScalarAggregateKernel.
>
> 1: This seems like a feature which might be generally useful to consumers
> of
> the compute module, so it's probably worth adding to the KernelState
> interface
> in some way rather than exposing individual implementations. I've opened
> https://issues.apache.org/jira/browse/ARROW-10630 to track this feature
>
> 2: I would not expect your container to contain a large number of
> KernelStates.
> Specifically: why would you need more than one per local thread?
> Additionally
> for the specific case of aggregation I'd expect that KernelStates not
> actively in
> use would be `merge`d and no longer stored. With small numbers of instances
> I would expect the memory overhead due to polymorphism to be negligible.
>
> On Mon, Nov 16, 2020 at 7:03 PM Niranda Perera
> wrote:
>
>> Hi Ben and Wes,
>> Based on our discussion, I did the following.
>> https://hastebin.com/ajadonados.cpp
>>
>> It seems to be working fine. Would love to get your feedback on this!
>> :-)
>>
>> But I have a couple of concerns.
>> 1. Say I want to communicate the intermediate state data across multiple
>> processes. Unfortunately, KernelState struct does not expose the data
>> pointer to the outside. If say SumState is exposed, we could have accessed
>> that data, isn't it? WDYT?
>> 2. Polymorphism and virtual functions - Intuitively, a mean aggregation
>> intermediate state would be a {T, int64} tuple. But I believe the size of
>> struct "SumImpl : public ScalarAggregator (:public KernelState)" would be
>> sizeof(T) + sizeof(int64) + sizeof(ScalarAggregator) + sizeof(vptr),
>> isn't it? So, if I am managing a compute state container, this means that
>> my memory requirement would be higher than simply using a {T, int64} tuple.
>> Please correct me if I am wrong. I am not sure if there is a better
>> solution to this, but just want to discuss it with you.
>>
>>
>> On Tue, Nov 10, 2020 at 9:44 AM Wes McKinney wrote:
>>
>>> Yes, open a Jira and propose a PR implementing the changes you need
>>>
>>> On Mon, Nov 9, 2020 at 8:31 PM Niranda Perera
>>> wrote:
>>> >
>>> > @wes How should I proceed with this nevertheless? should I open a JIRA?
>>> >
>>> > On Mon, Nov 9, 2020 at 11:09 AM Wes McKinney
>>> wrote:
>>> >
>>> > > On Mon, Nov 9, 2020 at 9:32 AM Niranda Perera <
>>> niranda.per...@gmail.com>
>>> > > wrote:
>>> > > >
>>> > > > @Ben
>>> > > > Thank you very much for the feedback. But unfortunately, I was
>>> unable to
>>> > > > find a header that exposes a SumAggregateKernel in the v2.0.0.
>>> Maybe I am
>>> > > > checking it wrong. I remember accessing them in v0.16 IINM.
>>> > > >
>>> > > > @Wes
>>> > > > Yes, that would be great. How about adding a CMake compilation
>>> flag for
>>> > > > such dev use cases?
>>> > > >
>>> > >
>>> > > This seems like it could cause more problems -- I think it would be
>>> > > sufficient to use an "internal::" C++ namespace and always install
>>> the
>>> > > relevant header file
>>> > >
>>> > > >
>>> > > >
>>> > > > On Sun, Nov 8, 2020 at 9:14 PM Wes McKinney
>>> wrote:
>>> > > >
>>> > > > > I'm not opposed to installing headers that provide access to
>>> some of
>>> > > > > the kernel implementation internals (with the caveat that changes
>>> > > > > won't go through a deprecation cycle, so caveat emptor). It
>>> might be
>>> > > > > more sustainable to think about what kind of stable-ish public
>>> API
>>> > > > > could be exported to support applications like Cylon.
>>> > > > >
>>> > > > > On Sun, Nov 8, 2020 at 10:37 AM Ben Kietzman <
>>> b...@ursacomputing.com>
>>> > > > > wrote:
>>> > > > > >
>>> > > > > > Hi Niranda,
>>> > > > > >
>>> > > > > > SumImpl is a subclass of KernelState. Given a
>>> SumAggregateKernel,
>>> > > one can
>>> > > > > > produce zeroed KernelState using the `init` member, then
>>> operate on
>>> > > data
>>> > > > > > using the `consume`, `merge`, and `finalize` members. You can
>>> look at
>>> > > > > > ScalarAggExecutor for an example of how to get from a compute
>>> > > function to
>>> > > > > > kernels and kernel state. Will that
Re: C++: Cache RecordBatch
On Tue, Nov 17, 2020 at 5:41 PM Rares Vernica wrote: > > Hi Antoine, > > On Tue, Nov 17, 2020 at 2:34 AM Antoine Pitrou wrote: > > > > Le 17/11/2020 à 03:34, Rares Vernica a écrit : > > > > > > I'm using an arrow::io::BufferReader and > > > arrow::ipc::RecordBatchStreamReader to read an arrow::RecordBatch from a > > > file. There is only one batc in the file so I do a single > > > RecordBatchStreamReader::ReadNext call. I store the populated > RecordBatch > > > in memory for reuse (cache). The memory buffer wrapped by the > BufferReader > > > is reallocated. > > > > What do you mean with "reallocated"? As long as you keep a strong > > reference to a RecordBatch (through shared_ptr), the buffers are kept > > intact. This is an intended consequence of the Buffer design and the > > pervasive use of shared_ptr. > > I have something like this: > > std::unique_ptr data; > data = std::make_unique(...); > // populate data > > std::shared_ptr bufferReader; > std::shared_ptr batchReader; > std::shared_ptr batch; > > bufferReader = std::make_shared(data.get()); > arrow::ipc::RecordBatchStreamReader::Open(bufferReader, ); // > Arrow < 0.17.0 > batchReader->ReadNext(); > > data = std::make_unique(...); > // populate "data" > > Is "batch" still a valid RecordBatch after the "data" buffer has been > relocated and repopulated? No, because "bufferReader" cannot reason about memory ownership. If you want to extend the lifetime of some foreign data source, one approach is to create a subclass of Buffer. The only real alternative I can think of would be to copy the data from "data" into a Buffer allocated from a MemoryPool before instantiating the BufferReader > Thanks! > Rares
Re: C++: Cache RecordBatch
Hi Antoine, On Tue, Nov 17, 2020 at 2:34 AM Antoine Pitrou wrote: > > Le 17/11/2020 à 03:34, Rares Vernica a écrit : > > > > I'm using an arrow::io::BufferReader and > > arrow::ipc::RecordBatchStreamReader to read an arrow::RecordBatch from a > > file. There is only one batc in the file so I do a single > > RecordBatchStreamReader::ReadNext call. I store the populated RecordBatch > > in memory for reuse (cache). The memory buffer wrapped by the BufferReader > > is reallocated. > > What do you mean with "reallocated"? As long as you keep a strong > reference to a RecordBatch (through shared_ptr), the buffers are kept > intact. This is an intended consequence of the Buffer design and the > pervasive use of shared_ptr. I have something like this: std::unique_ptr data; data = std::make_unique(...); // populate data std::shared_ptr bufferReader; std::shared_ptr batchReader; std::shared_ptr batch; bufferReader = std::make_shared(data.get()); arrow::ipc::RecordBatchStreamReader::Open(bufferReader, ); // Arrow < 0.17.0 batchReader->ReadNext(); data = std::make_unique(...); // populate "data" Is "batch" still a valid RecordBatch after the "data" buffer has been relocated and repopulated? Thanks! Rares
[Discuss] Refreshing a bearer token with retry mechanism
I am trying to implement an auth mechanism using access tokens that will expire, and with the ability to retry the Flight API call automatically with the basic credentials(username/pass) when the Flight Server comes back with the access token expired response. For this, I need to keep track of the previous Flight API call that failed authentication with the access token expired response, along with all the headers that the call included. Once the flight client/client middleware realizes that the access token has expired, it retries the same API call, with all the headers intact, except the authorization token header, which is replaced with the authorization basic credential header(username/pass) and the request is sent to the server again for authentication and processing. Options that I have discovered so far: 1. Modifying the flight client itself to cache the outgoing request and retry the same with a modified authorization header with basic credentials when it receives the access token expired response back from the flight server. 2. Instead of modifying the flight client, a client middleware is passed in via FlightClient.Builder.intercept() method. The client middleware is used to intercept the access token expired response from the server and retry the API call with the modified authorization header, however, I am not certain that the client middleware has the context of the original API call that failed when it intercepts the access token expired response back from the flight server. 3. Have a wrapper impl around the flight client that caches the outgoing request before sending it to the flight client, and once the wrapper receives the token expired response from the server via the flight client, it retries the cached request with the modified authorization header containing the basic Credentials instead of the access token. While this option does not involve the modification of the Arrow Flight code, I still wanted to put this out there as one of the options being considered. Apart from the options above is there any better way to solve this problem? Regards, Keerat
Re: Using arrow/compute/kernels/*internal.h headers
Hi Niranda,
hastebin: That looks generally correct, though I should warn you that a
recent PR
( https://github.com/apache/arrow/pull/8574 ) changed the return type of
DispatchExact to Kernel so you'll need to insert an explicit cast to
ScalarAggregateKernel.
1: This seems like a feature which might be generally useful to consumers of
the compute module, so it's probably worth adding to the KernelState
interface
in some way rather than exposing individual implementations. I've opened
https://issues.apache.org/jira/browse/ARROW-10630 to track this feature
2: I would not expect your container to contain a large number of
KernelStates.
Specifically: why would you need more than one per local thread?
Additionally
for the specific case of aggregation I'd expect that KernelStates not
actively in
use would be `merge`d and no longer stored. With small numbers of instances
I would expect the memory overhead due to polymorphism to be negligible.
On Mon, Nov 16, 2020 at 7:03 PM Niranda Perera
wrote:
> Hi Ben and Wes,
> Based on our discussion, I did the following.
> https://hastebin.com/ajadonados.cpp
>
> It seems to be working fine. Would love to get your feedback on this! :-)
>
> But I have a couple of concerns.
> 1. Say I want to communicate the intermediate state data across multiple
> processes. Unfortunately, KernelState struct does not expose the data
> pointer to the outside. If say SumState is exposed, we could have accessed
> that data, isn't it? WDYT?
> 2. Polymorphism and virtual functions - Intuitively, a mean aggregation
> intermediate state would be a {T, int64} tuple. But I believe the size of
> struct "SumImpl : public ScalarAggregator (:public KernelState)" would be
> sizeof(T) + sizeof(int64) + sizeof(ScalarAggregator) + sizeof(vptr), isn't
> it? So, if I am managing a compute state container, this means that my
> memory requirement would be higher than simply using a {T, int64} tuple.
> Please correct me if I am wrong. I am not sure if there is a better
> solution to this, but just want to discuss it with you.
>
>
> On Tue, Nov 10, 2020 at 9:44 AM Wes McKinney wrote:
>
>> Yes, open a Jira and propose a PR implementing the changes you need
>>
>> On Mon, Nov 9, 2020 at 8:31 PM Niranda Perera
>> wrote:
>> >
>> > @wes How should I proceed with this nevertheless? should I open a JIRA?
>> >
>> > On Mon, Nov 9, 2020 at 11:09 AM Wes McKinney
>> wrote:
>> >
>> > > On Mon, Nov 9, 2020 at 9:32 AM Niranda Perera <
>> niranda.per...@gmail.com>
>> > > wrote:
>> > > >
>> > > > @Ben
>> > > > Thank you very much for the feedback. But unfortunately, I was
>> unable to
>> > > > find a header that exposes a SumAggregateKernel in the v2.0.0.
>> Maybe I am
>> > > > checking it wrong. I remember accessing them in v0.16 IINM.
>> > > >
>> > > > @Wes
>> > > > Yes, that would be great. How about adding a CMake compilation flag
>> for
>> > > > such dev use cases?
>> > > >
>> > >
>> > > This seems like it could cause more problems -- I think it would be
>> > > sufficient to use an "internal::" C++ namespace and always install the
>> > > relevant header file
>> > >
>> > > >
>> > > >
>> > > > On Sun, Nov 8, 2020 at 9:14 PM Wes McKinney
>> wrote:
>> > > >
>> > > > > I'm not opposed to installing headers that provide access to some
>> of
>> > > > > the kernel implementation internals (with the caveat that changes
>> > > > > won't go through a deprecation cycle, so caveat emptor). It might
>> be
>> > > > > more sustainable to think about what kind of stable-ish public API
>> > > > > could be exported to support applications like Cylon.
>> > > > >
>> > > > > On Sun, Nov 8, 2020 at 10:37 AM Ben Kietzman <
>> b...@ursacomputing.com>
>> > > > > wrote:
>> > > > > >
>> > > > > > Hi Niranda,
>> > > > > >
>> > > > > > SumImpl is a subclass of KernelState. Given a
>> SumAggregateKernel,
>> > > one can
>> > > > > > produce zeroed KernelState using the `init` member, then
>> operate on
>> > > data
>> > > > > > using the `consume`, `merge`, and `finalize` members. You can
>> look at
>> > > > > > ScalarAggExecutor for an example of how to get from a compute
>> > > function to
>> > > > > > kernels and kernel state. Will that work for you?
>> > > > > >
>> > > > > > Ben Kietzman
>> > > > > >
>> > > > > > On Sun, Nov 8, 2020, 11:21 Niranda Perera <
>> niranda.per...@gmail.com>
>> > > > > wrote:
>> > > > > >
>> > > > > > > Hi Ben,
>> > > > > > >
>> > > > > > > We are building a distributed table abstraction on top of
>> Arrow
>> > > > > dataframes
>> > > > > > > called Cylon (https://github.com/cylondata/cylon). Currently
>> we
>> > > have a
>> > > > > > > simple aggregation and group-by operation implementation. But
>> we
>> > > felt
>> > > > > like
>> > > > > > > we can give more functionality if we can import arrow kernels
>> and
>> > > > > states to
>> > > > > > > corresponding cylon distributed kernels.
>> > > > > > > Ex: For distributed mean, we would have to communicate the
>> local
>> > > arrow
>> > > > > > > SumState and then do
Re: [Discuss] Should dense union offsets be always increasing?
In principle I'm in favor of #2 -- the only question is what kinds of problems it might pose for forward compatibility. Note * This is completely backward compatible (any data conforming to the spec to the letter will continue to be conforming) * It is also forward compatible at a protocol level, but code that makes assumptions about the monotonicity of the offsets will break Since the offset acts effectively as a dictionary index, this doesn't strike me as being so harmful, but I'm interested in the opinions of others On Tue, Nov 17, 2020 at 5:28 AM Antoine Pitrou wrote: > > > Hello, > > The format spec and the C++ implementation disagree on one point: > > * The spec says that dense union offsets should be increasing: > """The respective offsets for each child value array must be in order / > increasing.""" > > (from https://arrow.apache.org/docs/format/Columnar.html#dense-union) > > * The C++ implementation has long had some tests that used deliberatly > non-increasing (even descending) dense union offsets. > > (see https://issues.apache.org/jira/browse/ARROW-10580) > > I don't know what other implementations, especially Java, expect. > > There are obviously two possible solutions: > > 1) Fix the C++ implementation and its tests to conform to the format > spec (which may break compatibility for code producing / consuming dense > unions with non-increasing offsets) > > 2) Relax the format spec to allow arbitrary offsets (which could make > dense union more like a polymorphic dictionary). > > If the first solution is chosen, then another question arises: must the > offsets be strictly increasing? Or can a given offset appear several > times in a row? > (the latter is currently exploited by the C++ implementation: when > appending several nulls to a DenseUnionBuilder, only one child null slot > is added and the same offset is appended multiple times) > > Regards > > Antoine.
[Discuss] Should dense union offsets be always increasing?
Hello, The format spec and the C++ implementation disagree on one point: * The spec says that dense union offsets should be increasing: """The respective offsets for each child value array must be in order / increasing.""" (from https://arrow.apache.org/docs/format/Columnar.html#dense-union) * The C++ implementation has long had some tests that used deliberatly non-increasing (even descending) dense union offsets. (see https://issues.apache.org/jira/browse/ARROW-10580) I don't know what other implementations, especially Java, expect. There are obviously two possible solutions: 1) Fix the C++ implementation and its tests to conform to the format spec (which may break compatibility for code producing / consuming dense unions with non-increasing offsets) 2) Relax the format spec to allow arbitrary offsets (which could make dense union more like a polymorphic dictionary). If the first solution is chosen, then another question arises: must the offsets be strictly increasing? Or can a given offset appear several times in a row? (the latter is currently exploited by the C++ implementation: when appending several nulls to a DenseUnionBuilder, only one child null slot is added and the same offset is appended multiple times) Regards Antoine.
Re: C++: Cache RecordBatch
Hi Rares, Le 17/11/2020 à 03:34, Rares Vernica a écrit : > > I'm using an arrow::io::BufferReader and > arrow::ipc::RecordBatchStreamReader to read an arrow::RecordBatch from a > file. There is only one batc in the file so I do a single > RecordBatchStreamReader::ReadNext call. I store the populated RecordBatch > in memory for reuse (cache). The memory buffer wrapped by the BufferReader > is reallocated. What do you mean with "reallocated"? As long as you keep a strong reference to a RecordBatch (through shared_ptr), the buffers are kept intact. This is an intended consequence of the Buffer design and the pervasive use of shared_ptr. Regards Antoine.
[NIGHTLY] Arrow Build Report for Job nightly-2020-11-17-0
Arrow Build Report for Job nightly-2020-11-17-0 All tasks: https://github.com/ursa-labs/crossbow/branches/all?query=nightly-2020-11-17-0 Failed Tasks: - conda-linux-gcc-py37-cpu: URL: https://github.com/ursa-labs/crossbow/branches/all?query=nightly-2020-11-17-0-azure-conda-linux-gcc-py37-cpu - conda-win-vs2017-py36: URL: https://github.com/ursa-labs/crossbow/branches/all?query=nightly-2020-11-17-0-azure-conda-win-vs2017-py36 - conda-win-vs2017-py37: URL: https://github.com/ursa-labs/crossbow/branches/all?query=nightly-2020-11-17-0-azure-conda-win-vs2017-py37 - debian-stretch-arm64: URL: https://github.com/ursa-labs/crossbow/branches/all?query=nightly-2020-11-17-0-travis-debian-stretch-arm64 - test-conda-python-3.7-spark-branch-3.0: URL: https://github.com/ursa-labs/crossbow/branches/all?query=nightly-2020-11-17-0-github-test-conda-python-3.7-spark-branch-3.0 - test-conda-python-3.8-jpype: URL: https://github.com/ursa-labs/crossbow/branches/all?query=nightly-2020-11-17-0-github-test-conda-python-3.8-jpype - test-ubuntu-18.04-docs: URL: https://github.com/ursa-labs/crossbow/branches/all?query=nightly-2020-11-17-0-azure-test-ubuntu-18.04-docs - ubuntu-focal-arm64: URL: https://github.com/ursa-labs/crossbow/branches/all?query=nightly-2020-11-17-0-travis-ubuntu-focal-arm64 Succeeded Tasks: - centos-6-amd64: URL: https://github.com/ursa-labs/crossbow/branches/all?query=nightly-2020-11-17-0-github-centos-6-amd64 - centos-7-aarch64: URL: https://github.com/ursa-labs/crossbow/branches/all?query=nightly-2020-11-17-0-travis-centos-7-aarch64 - centos-7-amd64: URL: https://github.com/ursa-labs/crossbow/branches/all?query=nightly-2020-11-17-0-github-centos-7-amd64 - centos-8-aarch64: URL: https://github.com/ursa-labs/crossbow/branches/all?query=nightly-2020-11-17-0-travis-centos-8-aarch64 - centos-8-amd64: URL: https://github.com/ursa-labs/crossbow/branches/all?query=nightly-2020-11-17-0-github-centos-8-amd64 - conda-clean: URL: https://github.com/ursa-labs/crossbow/branches/all?query=nightly-2020-11-17-0-azure-conda-clean - conda-linux-gcc-py36-aarch64: URL: https://github.com/ursa-labs/crossbow/branches/all?query=nightly-2020-11-17-0-drone-conda-linux-gcc-py36-aarch64 - conda-linux-gcc-py36-cpu: URL: https://github.com/ursa-labs/crossbow/branches/all?query=nightly-2020-11-17-0-azure-conda-linux-gcc-py36-cpu - conda-linux-gcc-py36-cuda: URL: https://github.com/ursa-labs/crossbow/branches/all?query=nightly-2020-11-17-0-azure-conda-linux-gcc-py36-cuda - conda-linux-gcc-py37-aarch64: URL: https://github.com/ursa-labs/crossbow/branches/all?query=nightly-2020-11-17-0-drone-conda-linux-gcc-py37-aarch64 - conda-linux-gcc-py37-cuda: URL: https://github.com/ursa-labs/crossbow/branches/all?query=nightly-2020-11-17-0-azure-conda-linux-gcc-py37-cuda - conda-linux-gcc-py38-aarch64: URL: https://github.com/ursa-labs/crossbow/branches/all?query=nightly-2020-11-17-0-drone-conda-linux-gcc-py38-aarch64 - conda-linux-gcc-py38-cpu: URL: https://github.com/ursa-labs/crossbow/branches/all?query=nightly-2020-11-17-0-azure-conda-linux-gcc-py38-cpu - conda-linux-gcc-py38-cuda: URL: https://github.com/ursa-labs/crossbow/branches/all?query=nightly-2020-11-17-0-azure-conda-linux-gcc-py38-cuda - conda-osx-clang-py36: URL: https://github.com/ursa-labs/crossbow/branches/all?query=nightly-2020-11-17-0-azure-conda-osx-clang-py36 - conda-osx-clang-py37: URL: https://github.com/ursa-labs/crossbow/branches/all?query=nightly-2020-11-17-0-azure-conda-osx-clang-py37 - conda-osx-clang-py38: URL: https://github.com/ursa-labs/crossbow/branches/all?query=nightly-2020-11-17-0-azure-conda-osx-clang-py38 - conda-win-vs2017-py38: URL: https://github.com/ursa-labs/crossbow/branches/all?query=nightly-2020-11-17-0-azure-conda-win-vs2017-py38 - debian-buster-amd64: URL: https://github.com/ursa-labs/crossbow/branches/all?query=nightly-2020-11-17-0-github-debian-buster-amd64 - debian-buster-arm64: URL: https://github.com/ursa-labs/crossbow/branches/all?query=nightly-2020-11-17-0-travis-debian-buster-arm64 - debian-stretch-amd64: URL: https://github.com/ursa-labs/crossbow/branches/all?query=nightly-2020-11-17-0-github-debian-stretch-amd64 - example-cpp-minimal-build-static-system-dependency: URL: https://github.com/ursa-labs/crossbow/branches/all?query=nightly-2020-11-17-0-github-example-cpp-minimal-build-static-system-dependency - example-cpp-minimal-build-static: URL: https://github.com/ursa-labs/crossbow/branches/all?query=nightly-2020-11-17-0-github-example-cpp-minimal-build-static - gandiva-jar-osx: URL: https://github.com/ursa-labs/crossbow/branches/all?query=nightly-2020-11-17-0-travis-gandiva-jar-osx - gandiva-jar-xenial: URL: https://github.com/ursa-labs/crossbow/branches/all?query=nightly-2020-11-17-0-travis-gandiva-jar-xenial - homebrew-cpp: URL: https://github.com/ursa-labs/crossbow/branches/all?query=nightly-2020-11-17-0-travis-homebrew-cpp -
