Yes Viraj, almost done testing. Mostly will start the release today.

Thanks,
Rajeshbabu.

On Tue, Mar 12, 2024, 9:53 AM Viraj Jasani <vjas...@apache.org> wrote:

> Are we good to start with Omid release?
>
>
> On Wed, Feb 28, 2024 at 1:51 PM Viraj Jasani <vjas...@apache.org> wrote:
>
> > After resolving a couple more issues, I finally have the RC ready for
> > vote. I will start the thread soon.
> >
> >
> > On Tue, Feb 27, 2024 at 8:26 AM Viraj Jasani <vjas...@apache.org> wrote:
> >
> >> Another release attempt failed during publish release step, pushed fix
> >> and ported to 5.2 branch:
> >>
> >>
> https://github.com/apache/phoenix/commit/bc1e2e7bea40c7d03940748e8f1d9f6b23339867
> >>
> >>
> >> On Mon, Feb 26, 2024 at 5:36 PM Viraj Jasani <vjas...@apache.org>
> wrote:
> >>
> >>> Thank you Istvan!
> >>>
> >>> Except for the arm64 vs amd64, I was able to get over other issues. For
> >>> arm64 JDK, I have done local change to unblock the RC and I hope that
> >>> should be fine.
> >>>
> >>> However, publish-release step is failing with gpg error:
> >>>
> >>> 01:03:53 [INFO] --- maven-gpg-plugin:3.1.0:sign
> (sign-release-artifacts)
> >>> @ phoenix ---
> >>> 01:03:53 [INFO] Signing 3 files with 0x1012D134 secret key.
> >>> gpg: setting pinentry mode 'error' failed: Forbidden
> >>> gpg: keydb_search failed: Forbidden
> >>> gpg: skipped "0x1012D134": Forbidden
> >>> gpg: signing failed: Forbidden
> >>>
> >>> I am not sure of the exact root cause here, but it is quite likely that
> >>> this is related to MGPG-92
> >>> <https://issues.apache.org/jira/browse/MGPG-92> that Nick created. I
> >>> wonder if we can run the publish-release step directly for debugging
> >>> purpose by any chance.
> >>>
> >>>
> >>>
> >>>
> >>> On Sun, Feb 25, 2024 at 10:03 PM Istvan Toth
> <st...@cloudera.com.invalid>
> >>> wrote:
> >>>
> >>>> IIRC I copied the docker release originally from HBase, which took
> them
> >>>> from Spark.
> >>>> The M1 issues may have been already fixed in one of those projects.
> >>>>
> >>>> A simple Ubuntu base image upgrade to 22.04 may fix the M1 specific
> >>>> issues.
> >>>> I can't help directly, as I do not have access to a Mac, but ping me
> on
> >>>> Slack if you get stuck.
> >>>>
> >>>> As for the third issue, the scripts generate logs in the working
> >>>> directory.
> >>>> If they do not log the maven command line, you could easily add a line
> >>>> to
> >>>> log them.
> >>>> The ERRORS logged are a known issue, as Maven does not like the tricks
> >>>> used
> >>>> for multi-profile building, but even 3.9.6 accepts them, and only logs
> >>>> WARNINGs in my experience.
> >>>>
> >>>> I'm going to do a dry-run of the release scripts locally, and see if I
> >>>> can
> >>>> repro some problems on my Intel Linux machine.
> >>>> If you have access to a secure Intel Linux host, you may also want to
> >>>> try
> >>>> to run the scripts there.
> >>>> (though getting the ssh password entry working can be tricky)
> >>>>
> >>>> Istvan
> >>>>
> >>>> On Sun, Feb 25, 2024 at 9:37 PM Viraj Jasani <vjas...@apache.org>
> >>>> wrote:
> >>>>
> >>>> > Hi,
> >>>> >
> >>>> > I have started with creating 5.2.0 RC, I am starting this thread to
> >>>> discuss
> >>>> > some of the issues I have come across so far.
> >>>> >
> >>>> > 1) do-release-docker.sh is not able to grep and identify snapshot
> and
> >>>> > release versions in release-utils.
> >>>> > While the function parse_version works fine, if run manually on the
> >>>> 5.2 pom
> >>>> > contents. Hence, I manually updated the utility to take
> 5.2.0-SNAPSHOT
> >>>> > version:
> >>>> >
> >>>> > --- a/dev/create-release/release-util.sh
> >>>> > +++ b/dev/create-release/release-util.sh
> >>>> > @@ -149,6 +149,7 @@ function get_release_info {
> >>>> >    local version
> >>>> >    version="$(curl -s
> >>>> > "$ASF_REPO_WEBUI;a=blob_plain;f=pom.xml;hb=refs/heads/$GIT_BRANCH" |
> >>>> >      parse_version)"
> >>>> > +  version="5.2.0-SNAPSHOT"
> >>>> >    echo "Current branch VERSION is $version."
> >>>> >
> >>>> >    RELEASE_VERSION=""
> >>>> >
> >>>> >
> >>>> > This is done to unblock the release for now. We can investigate and
> >>>> fix
> >>>> > this later.
> >>>> >
> >>>> > 2) openjdk-8-amd64 installation fails because I am using M1 Mac:
> >>>> >
> >>>> > Setting up openjdk-8-jdk:arm64 (8u372-ga~us1-0ubuntu1~18.04) ...
> >>>> > update-alternatives: using
> >>>> > /usr/lib/jvm/java-8-openjdk-arm64/bin/appletviewer to provide
> >>>> > /usr/bin/appletviewer (appletviewer) in auto mode
> >>>> > update-alternatives: using
> >>>> /usr/lib/jvm/java-8-openjdk-arm64/bin/jconsole
> >>>> > to provide /usr/bin/jconsole (jconsole) in auto mode
> >>>> > Setting up ubuntu-mono (16.10+18.04.20181005-0ubuntu1) ...
> >>>> > Processing triggers for libc-bin (2.27-3ubuntu1.6) ...
> >>>> > Processing triggers for ca-certificates (20230311ubuntu0.18.04.1)
> ...
> >>>> > Updating certificates in /etc/ssl/certs...
> >>>> > 0 added, 0 removed; done.
> >>>> > Running hooks in /etc/ca-certificates/update.d...
> >>>> > done.
> >>>> > done.
> >>>> > Processing triggers for libgdk-pixbuf2.0-0:arm64 (2.36.11-2) ...
> >>>> > update-alternatives: error: alternative
> >>>> > /usr/lib/jvm/java-8-openjdk-amd64/jre/bin/java for java not
> >>>> registered; not
> >>>> > setting
> >>>> >
> >>>> > In order to resolve this, I set java to use java-8-openjdk-arm64
> >>>> instead.
> >>>> > e.g. update-alternatives --set java
> >>>> > /usr/lib/jvm/java-8-openjdk-arm64/jre/bin/java
> >>>> > (and all other places where we use amd64)
> >>>> >
> >>>> > This is done to make the release progress, we can fix this later.
> >>>> >
> >>>> > 3) make_binary_release fails as it is unable to resolve
> >>>> ${hbase.version}
> >>>> > and ${hbase.compat.version}
> >>>> >
> >>>> > Packaging release source tarballs
> >>>> > 2024-02-25T19:43:46Z make_src_release start
> >>>> > 2024-02-25T19:43:47Z make_src_release stop (1 seconds)
> >>>> > 2024-02-25T19:43:47Z make_binary_release start
> >>>> > 19:45:27 [INFO] Scanning for projects...
> >>>> > 19:45:27 [ERROR] [ERROR] Some problems were encountered while
> >>>> processing
> >>>> > the POMs:
> >>>> > [ERROR] 'dependencies.dependency.artifactId' for
> >>>> > org.apache.phoenix:phoenix-hbase-compat-${hbase.compat.version}:jar
> >>>> with
> >>>> > value 'phoenix-hbase-compat-${hbase.compat.version}' does not match
> a
> >>>> valid
> >>>> > id pattern. @
> >>>> org.apache.phoenix:phoenix-core-client:[unknown-version],
> >>>> > /home/vjasani/phoenix-rm/output/phoenix/phoenix-core-client/pom.xml,
> >>>> line
> >>>> > 220, column 19
> >>>> > [ERROR] 'dependencies.dependency.version' for
> >>>> > org.apache.phoenix:phoenix-hbase-compat-${hbase.compat.version}:jar
> is
> >>>> > missing. @ org.apache.phoenix:phoenix-core-client:[unknown-version],
> >>>> > /home/vjasani/phoenix-rm/output/phoenix/phoenix-core-client/pom.xml,
> >>>> line
> >>>> > 218, column 17
> >>>> > [ERROR] 'dependencies.dependency.version' for
> >>>> > org.apache.hbase:hbase-common:jar must be a valid version but is
> >>>> > '${hbase.version}'. @ org.apache.phoenix:phoenix:5.2.0,
> >>>> > /home/vjasani/phoenix-rm/output/phoenix/pom.xml, line 1128, column
> 18
> >>>> > [ERROR] 'dependencies.dependency.version' for
> >>>> > org.apache.hbase:hbase-metrics-api:jar must be a valid version but
> is
> >>>> > '${hbase.version}'. @ org.apache.phoenix:phoenix:5.2.0,
> >>>> > /home/vjasani/phoenix-rm/output/phoenix/pom.xml, line 1151, column
> 18
> >>>> > [ERROR] 'dependencies.dependency.version' for
> >>>> > org.apache.hbase:hbase-client:jar must be a valid version but is
> >>>> > '${hbase.version}'. @ org.apache.phoenix:phoenix:5.2.0,
> >>>> > /home/vjasani/phoenix-rm/output/phoenix/pom.xml, line 1161, column
> 18
> >>>> > [ERROR] 'dependencies.dependency.version' for
> >>>> > org.apache.hbase:hbase-hadoop-compat:jar must be a valid version but
> >>>> is
> >>>> > '${hbase.version}'. @ org.apache.phoenix:phoenix:5.2.0,
> >>>> > /home/vjasani/phoenix-rm/output/phoenix/pom.xml, line 1226, column
> 18
> >>>> > ...
> >>>> > ...
> >>>> >
> >>>> >
> >>>> > As I do not see "Hbase version is already compiled for Hadoop3.
> >>>> Skipping
> >>>> > rebuild", I assume this should be the first profile from the
> >>>> profile.list
> >>>> > i.e. 2.4 and we are unable to build for the first profile.
> >>>> >
> >>>> > While 1) and 2) have workarounds, 3) is currently blocking the
> >>>> release.
> >>>> >
> >>>>
> >>>>
> >>>> --
> >>>> *István Tóth* | Sr. Staff Software Engineer
> >>>> *Email*: st...@cloudera.com
> >>>> cloudera.com <https://www.cloudera.com>
> >>>> [image: Cloudera] <https://www.cloudera.com/>
> >>>> [image: Cloudera on Twitter] <https://twitter.com/cloudera> [image:
> >>>> Cloudera on Facebook] <https://www.facebook.com/cloudera> [image:
> >>>> Cloudera
> >>>> on LinkedIn] <https://www.linkedin.com/company/cloudera>
> >>>> ------------------------------
> >>>> ------------------------------
> >>>>
> >>>
>

Reply via email to