@Ayush Saxena <ayush...@gmail.com> @Takanobu Asanuma <tasan...@apache.org> @Xiaoqiao He <hexiaoq...@apache.org> @inigo...@apache.org <inigo...@apache.org> @Masatake Iwasaki <iwasak...@apache.org> @Akira Ajisaka
Could you please assist with the Hadoop-3.4.0-RC2 vote? Best Regards, Shilun Fan. On Fri, Feb 16, 2024 at 7:27 AM slfan1989 <slfan1...@apache.org> wrote: > Thank you for helping review hadoop-3.4.0-RC2. > > Compared to RC1, we have made two improvements: > 1. Merged some patches from the branch-3.4 branch to branch-3.4.0. > 2. Upgrade the version of hadoop-thirdparty to 1.2.0. > > Best Regards, > Shilun Fan. > > On Fri, Feb 16, 2024 at 4:41 AM Mukund Madhav Thakur <mtha...@cloudera.com> > wrote: > >> 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... >>> > >>> >>
