Rainer,
On 12/5/24 2:08 PM, Rainer Jung wrote:
Hi Chris,
Am 05.12.24 um 17:41 schrieb Christopher Schultz:
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
?
Unfortunately no, with this flag I still see german parts in the
fulldocs files.
What, specifically, is still in German? I would imagine that the
Java-related stuff ant invokes would all use the 'en' locale, so I
wonder what is being handled differently.
(I suppose I could set LANG=de on my machine and see what happens!)
-chris
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
