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 ... - "ant verify-release" should try "common" paths for gpg, maybe "/usr/bin/gpg", "/usr/local/bin/gpg", "C:/Program Files (x86)/GnuPG/bin/gpg.exe", unless there is a defined gpg.exec property. Rémy --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
