Rainer,
On 11/11/24 9:25 AM, Christopher Schultz wrote:
Rainer,
On 11/9/24 4:52 AM, Rainer Jung wrote:
Hi there,
I checked build reproducibility for the first time (apologies) and it
worked pretty well, at least for TC 11 and 10.1. That is great.
I have a few observations to share:
1) codesigning, gpg
:::::::::::::::::::
The source code includes the build.properties.release file. Two of its
lines are IMHO questionable:
do.codesigning=true
gpg.exec=C:/Program Files (x86)/GnuPG/bin/gpg.exe
These lines mean, that if I just want to check reproducibility, I need
to set do.codesigning=false in my local build.properties.
No, you can leave this set to true.
If the code is already signed, you will not produce new signatures. The
GPG ones from the RM will remain. The detached signatures for the
Windows binaries will be re-attached during the build to the binaries
YOU build, and the signatures should be correct.
In BUILDING.txt we document, that you have to set
do.codesigning=true to use codesigning, but in fact it is already
set to true and you have to set to false to not use code signing.
BUILDING.txt isn't really meant for an audience who is verifying releases.
Similar for gpg.exec: Since I can not use the RM's key, when doing a
reproducibility check, I would not sign the files using gpg. That
should be the default and for TC 11 and 10.1 it was for me, because
the value of gpg.exec in the build.properties.release did not point to
a valid path on my system. For TC 9 it did, so I had to overwrite
gpg.exec.
This should be okay, because you should not be signing anything in order
to verify a release. I may have set up a chicken-and-egg situation where
the RM sets a gpg.exec setting which does not work in your environment
(which should be okay) but in order to do "ant release" there is a test
to see if GPG is working. That test should be skipped when verifying a
release.
I thought about it initially when adding that check and did not go back
to see what the best way would be to ensure (a) the release-build does
not fail due to GPG failing (missing binary/wrong path, or bad password)
and (b) ignore everything when /verifying/ a release.
I cannot remember why I added gpg.exec to build.properties.release. I
tend to agree that it probably doesn't belong in there.
Maybe it would be better to add the two lines commented out? At least
for the gpg.exec it would still document, what was used without making
it the default value on other user's systems?
2) Reproducibility for TC 9
:::::::::::::::::::::::::::
If I run "ant release" with Java 17 as suggested in
build.properties.release, I get the error, that for release including
ffm you need 22. But if I run it with Java 22 then it seems I do not
get a reproducible build?
For Tomcat 9, I think we need to add the value of the Java version used
to build FFM to build.properties.release. Right now, I think it's not
mentioned anywhere.
3) locale
:::::::::
To make the build documentation reproducible I had to set
export LANG=en_US.utf8
I did not check, whether and how I can replace setting a JVM system
property instead. But I think if we want to make the build
reproducible including docs, we need to either document the locale
settings in build.properties.release or even better standardize on a
given one. I think standardizing on en_US.utf8 should be fine.
Thanks for pointing this out. I did not check the user's locale and, as
it happens, my locale is always en_US.utf8. I think we should be able to
set this in the build.properties.release for all Java-related things. I
wonder about the Windows installer, though.
I think the best locale to use would be en.utf8 and leave out the US part.
If you run "ant release" and specify the locale, does it improve things
for reproducibility? Or do you actually need to set the LANG environment
variable?
$ ant -Duser.language=en release
?
I'm hoping for a solution that does not require use of environment
variables.
-chris
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
