Am 05.12.24 um 20:53 schrieb Christopher Schultz:
Rainer,
On 12/5/24 2:47 PM, Rainer Jung wrote:
Am 05.12.24 um 20:15 schrieb Christopher Schultz:
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.
Standard javadoc generated template text like "Klasse" instead of
class, "Baum" instead of tree etc.
It happens, because my local use has a LANG value set in the
environment. As soon as I remove my german LANG setting, it works.
Although ant has a locale attribute for its javadoc task, the
environment variable seems to have preferece. Setting the javadoc
attribute does not suffice to overwrite it.
So it might be enough to document, that you should not have a LANG or
LC_* env var set.
Yucky, but doable.
I'll take a look at how we invoke javadoc. Maybe we can override the
locale in the task or even fork the JVM and override the environment
variable.
You can, that's what I mean with "locale" attribute. But the LANG env
var takes precedence.
I noticed, that even when I remove my LANG, there is still another
problem not seen when I set an explicit LANG=en_US: the registered
trademark sign, that we use in build.xml as ® is issued as ?
without explicit en_US although we already set a few attributes for
javadoc to use UTF_8. No idea, why it comes out as "?" without explicit
LANG=en_US. I don't see any charset changing env vars in my environment.
Regards,
Rainer
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
