Thanks, Shilun for putting this together. Tried the below things and everything worked for me.
validated checksum and gpg signature. compiled from source. Ran AWS integration tests. untar the binaries and able to access objects in S3 via hadoop fs commands. compiled gcs-connector successfully using the 3.4.0 version. qq: what is the difference between RC1 and RC2? apart from some extra patches. On Thu, Feb 15, 2024 at 10:58 AM slfan1989 <slfan1...@apache.org> wrote: > Thank you for explaining this part! > > hadoop-3.4.0-RC2 used the validate-hadoop-client-artifacts tool to generate > the ARM tar package, which should meet expectations. > > We also look forward to other members helping to verify. > > Best Regards, > Shilun Fan. > > On Fri, Feb 16, 2024 at 12:22 AM Steve Loughran <ste...@cloudera.com> > wrote: > > > > > > > On Mon, 12 Feb 2024 at 15:32, slfan1989 <slfan1...@apache.org> wrote: > > > >> > >> > >> Note, because the arm64 binaries are built separately on a different > >> platform and JVM, their jar files may not match those of the x86 > >> release -and therefore the maven artifacts. I don't think this is > >> an issue (the ASF actually releases source tarballs, the binaries are > >> there for help only, though with the maven repo that's a bit blurred). > >> > >> The only way to be consistent would actually untar the x86.tar.gz, > >> overwrite its binaries with the arm stuff, retar, sign and push out > >> for the vote. > > > > > > > > that's exactly what the "arm.release" target in my client-validator does. > > builds an arm tar with the x86 binaries but the arm native libs, signs > it. > > > > > > > >> Even automating that would be risky. > >> > >> > > automating is the *only* way to do it; apache ant has everything needed > > for this including the ability to run gpg. > > > > we did this on the relevant 3.3.x releases and nobody has yet > complained... > > >
