Rémy,
On 11/7/25 8:09 AM, Rémy Maucherat wrote:
On Fri, Nov 7, 2025 at 12:42 PM Mark Thomas <[email protected]> wrote:
On 07/11/2025 09:51, Rémy Maucherat wrote:
On Fri, Nov 7, 2025 at 12:28 AM Mark Thomas <[email protected]> wrote:
On 06/11/2025 19:35, Rémy Maucherat wrote:
On Thu, Nov 6, 2025 at 7:14 PM Mark Thomas <[email protected]> wrote:
On 06/11/2025 18:05, Rémy Maucherat wrote:
On Thu, Nov 6, 2025 at 6:10 PM Mark Thomas <[email protected]> wrote:
On 06/11/2025 16:31, Dimitris Soumis wrote:
<snip/>
I am getting an error when trying to verify the release. I haven't looked
into it so I am posting it here in case something's missed and will come
back to it later.
The verify-release task is broken. If you back-port the fixes from
11.0.x to build.xml it should work.
This still doesn't completely work for me (at least not as good as I expect).
I get "apache-tomcat-11.0.14-src/build.xml:4461: Execute failed:
java.io.IOException: Cannot run program "C:/Program Files
(x86)/GnuPG/bin/gpg.exe"" (on Linux).
Unless I set a build.properties (after building of course, if you set
it before then it tries to sign).
Odd.
If you are building from the tag then you should be OK as the signing
will use the sig files included in the tag.
This is not about the Windows signature, it's for gpg signing. If gpg
is available, then "ant release" prompts for my key password, and if
it's not available then "ant verify-release" does not work.
Got it. Sorry. That looks like another side-effect of this change:
https://github.com/apache/tomcat/commit/6abcfa58e0bbc55d4c64f8d72a4e707cb722a4ba
I have gpg on the machines where I test builds so I didn't see that issue.
Is it ok if I introduce a second gpg path variable to avoid this
issue, like gpg.verify.exec=/path/to/gpg and maybe use a more "common"
default value there (for me it's obviously "/usr/bin/gpg").
Why do we need a new property? If gpg.exec is defined in
build.properties or ${user.home}/build.properties it will take
precedence over the the value set in build.properties.release
Or am I missing something?
Maybe this could be better. Why does gpg.exec gets set into
build.properties.release ? I had forgotten it was also set there.
Proposed changes:
- Comment out gpg.exec from build.properties.default (it always needs
to be set in build.properties).
- Don't set gpg.exec in build.properties.release, it only indicates a
path on the local machine, not a version number or something needed to
reproduce. Unless I missed something ...
I can't for the life of me remember why I added gpg.exec to
build.properties.release.
-chris
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
