looking at 14.04 now, although we may drop it in the near future.
On Sun, May 17, 2020 at 1:46 AM Ning Wang wrote:
> Fixed 16.04: https://github.com/apache/incubator-heron/pull/3525
>
> I think it is caused by pkg-config.
>
> On Sat, May 16, 2020 at 8:37 PM Ning Wang wrote:
>
>> Thanks for the
Fixed 16.04: https://github.com/apache/incubator-heron/pull/3525
I think it is caused by pkg-config.
On Sat, May 16, 2020 at 8:37 PM Ning Wang wrote:
> Thanks for the input. We can skip Python 3 support for this release.
> Currently, it is failing on the zookeeper source step in Ubuntu16.04
Recalling the test I made in March, Zookeeper should be fine in Ubuntu 16.04,
just require some tuning of the bazel build file to match the version in there.
However, switching to Python 3 breaks Ubuntu 16.04 and CentOS 7 due to no
official support of the Python library dev in ther later
My concern is that if we have the file there, it should at least compile. I
am open to remove the file or move it to somewhere we don't directly
support. But right now, it is there in the docker dir so I think it is a
reasonable expectation for people to believe it shouldn't throw error just
I think the issue might come down to the "autoreconf" line. It is needed
for some OS and not others. The conditional logic I added based on platform
might not be sufficient. Might need to add a variable we can toggle in the
bazelrc file.
The issue is newer Ubuntu doesn't need it, but older Ubuntu
Would it be that bad if we made a release knowing that we couldn't support
Centos7 or Ubuntu16.04? This would still allow us to get binaries/an
official Docker image/ and install scripts for a few supported operating
systems (Ubuntu 18.x, Debian9, Debian 10, OSX). I remember hearing that
we
If I were to take a guess I would think it's the line below: But why this
folder wouldn't exist I'm unsure of..
cp -R $(pwd)/external/org_apache_zookeeper/* $TMP_DIR
I've also added the github permalink to the line of code below:
Yeah. It's the error when I tried to build on Ubuntu16. The error is in the
list of commands which is tricky to debug. There was a similar error
message in centos 7 which was caused by cppunit I remember. But it is hard
to tell if it is the same here.
On Sat, May 16, 2020 at 2:31 PM Josh Fischer