+1 (non-binding) I've successfully ran the following on Apple M1 Pro (macOS 12.1 (21C52), Kernel Darwin 21.2.0): TEST_PYTHON=0 TEST_GLIB=0 TEST_RUBY=0 ./dev/release/verify-release-candidate.sh source 7.0.0 10
There was a minor issue with protobuf on M1: https://issues.apache.org/jira/browse/ARROW-15549 I'll try to get Ruby to pass too. I'm assuming the Python build issue is about conda and since I can build fine on Brew it's probably ok. Rok On Wed, Feb 2, 2022 at 6:25 PM Antoine Pitrou <anto...@python.org> wrote: > > > I've successfully tested the following configuration on a Apple M1 with > macOS 11.2.3: > > ARROW_GANDIVA=OFF TEST_DEFAULT=0 TEST_CPP=1 \ > ./dev/release/verify-release-candidate.sh source 7.0.0 10 > > Regards > > Antoine. > > > Le 02/02/2022 à 17:45, Krisztián Szűcs a écrit : > > I'm planning to close the VOTE tomorrow, but it would be great to have > > results for the following scenarios: > > > > - Verify the staged maven artifacts: this is the first time we ship > > java jars with bundled shared libraries, but we don't have scripting > > to test that. For more context see issue > > https://issues.apache.org/jira/browse/ARROW-15486 > > > > - Verify the the release on Windows > > > > - Verify the release on Apple M1 > > > > Thanks, Krisztian > > > > On Wed, Feb 2, 2022 at 5:36 PM Krisztián Szűcs > > <szucs.kriszt...@gmail.com> wrote: > >> > >> +1 (binding) > >> > >> - Verified the binaries (though I had to restart several times because > >> artifactory dropped me off) > >> - Verified the source tarball (required to define DYLD_LIBRARY_PATH > >> instead of LD_LIBRARY_PATH) > >> - Verified the wheels (without problems) > >> > >> on Intel macOS 12. > >> > >> On Mon, Jan 31, 2022 at 9:58 PM David Li <lidav...@apache.org> wrote: > >>> > >>> +1 > >>> > >>> Tested source (C++/Java with integration), binaries, and wheels on Ubuntu > >>> 18.04. > >>> > >>> I ran into the same error as Antoine with the wheels; adding `conda > >>> activate base` also fixed it for me. I had to disable Gandiva for source > >>> verification due to a linking error with LLVM (though my system > >>> repositories don't have an appropriate version of LLVM in the first > >>> place). > >>> > >>> -David > >>> > >>> On Mon, Jan 31, 2022, at 05:59, Antoine Pitrou wrote: > >>>> Le 30/01/2022 à 11:15, Krisztián Szűcs a écrit : > >>>>>> > >>>>>> (*) Here is the end of the logs: > >>>>>> > >>>>>> + pushd binaries > >>>>>> /tmp/arrow-7.0.0.C5b7S/binaries /tmp/arrow-7.0.0.C5b7S > >>>>>> ++ uname > >>>>>> + '[' Linux == Darwin ']' > >>>>>> + test_linux_wheels > >>>>>> ++ uname -m > >>>>>> + '[' x86_64 = aarch64 ']' > >>>>>> + local arch=x86_64 > >>>>>> + local 'py_arches=3.7m 3.8 3.9 3.10' > >>>>>> + local 'platform_tags=manylinux_2_12_x86_64.manylinux2010_x86_64 > >>>>>> manylinux_2_17_x86_64.manylinux2014_x86_64' > >>>>>> + for py_arch in ${py_arches} > >>>>>> + local env=_verify_wheel-3.7m > >>>>>> + '[' 3.7m = 3.10 ']' > >>>>>> + local 'channels=-c conda-forge' > >>>>>> + mamba create -yq -n _verify_wheel-3.7m -c conda-forge python=3.7 > >>>>>> ./dev/release/verify-release-candidate.sh: line 646: mamba: command not > >>>>> Could you please try to `conda activate base` before the mamba command > >>>>> and if that doesn't work simply replace `mamba` with `conda` and test > >>>>> the wheels again? > >>>> > >>>> Adding `conda activate base` solved the issue indeed. > >>>> > >>>> Regards > >>>> > >>>> Antoine.
