I think there's an issue with all the existing Docker files. They install both 64-bit and 32-bit packages. This is fine if the output ends up in different directories (or if the output is the same).
However that is definitely not the case for opensslconf.h. At present the 64-bit version is also used for 32-bit builds; I don't think that is correct. This is easy enough to fix, however if there are other clashes, some of the builds might be incorrect. One way to fix that would be to provide separate Docker files for the two architectures. However that will require rather more disk space. On Wed, 22 Jun 2022 at 00:20, Alex Remily <alex.rem...@gmail.com> wrote: > > <That is the case with my version.> > > Then I was definitely looking at the wrong version of your file. I'll > circle back and run it again. > > On Tue, Jun 21, 2022 at 5:52 PM sebb <seb...@gmail.com> wrote: > > > On Tue, 21 Jun 2022 at 22:32, Alex Remily <alex.rem...@gmail.com> wrote: > > > > > > <Not sure how it improves on the Docker build I derived from your > > previous > > > submission.> > > > > > > Don't know that it's an "improvement", but a different approach. I think > > > if we provide a dockerfile that builds every supported arch (minus the > > Mac) > > > developers could easily modify it by removing parts they don't want as > > > opposed to adding dependencies and builds for the parts that they do. > > > > That is the case with my version. > > The builds are in separate script files that can be easily edited. > > And if a build fails due to a source issue, it can just be repeated > > after changing the source. > > No need to rebuild the image. > > Also no need to export the generated output as it is created on the host. > > > > > Also, I think this approach makes it easier for the next release manager > > > because it declares all the necessary dependencies and performs the > > builds > > > in the proper order. > > > > AFAICT there is no ordering issue with my version apart from linux32 > > which needs an extra install. > > > > > The last release was something of a challenge because > > > a lot of corporate knowledge had been lost when the original developers > > > left. > > > > Indeed. > > > > There is some documentation in the src/docker/README file, but it > > could be expanded. > > > > > <Did you try the sebb-docker branch again after my last reply? I think > > you > > > must have used a different checkout when you reported the failures.> > > > > > > I got sidetracked. Apologies. I need to do that and provide feedback. > > I > > > don't see why we can't have both, as long as we document them. > > > > I see no reason to have both. > > > > > <If it is removed from the POM then the Docker build will also need to be > > > updated.> > > > > > > As of this PR, it's in the POM but not in the dockerfile. > > > > Sorry, you are right. > > I thought I saw '32-bit build' but it was actually '32-bit Mac build'. > > Oops. > > We have already decided to drop that. > > > > > I see that you did a PR review. I'll try to look at it tonight and > > > respond. > > > > > > Thanks. > > > > > > On Tue, Jun 21, 2022 at 4:23 PM sebb <seb...@gmail.com> wrote: > > > > > > > On Tue, 21 Jun 2022 at 20:00, Alex Remily <alex.rem...@gmail.com> > > wrote: > > > > > > > > > > I went ahead and submitted a PR related to this discussion. The > > > > dockerfile > > > > > does a full build, minus the Mac, and should simplify the release > > > > process. > > > > > > > > Not sure how it improves on the Docker build I derived from your > > > > previous submission. > > > > > > > > Did you try the sebb-docker branch again after my last reply? > > > > I think you must have used a different checkout when you reported the > > > > failures. > > > > > > > > > Developers can easily modify as needed for their own purposes. I > > > > recommend > > > > > removing the 32-bit Mac build profile from the POM, but have not > > done so > > > > in > > > > > this PR. > > > > > > > > If it is removed from the POM then the Docker build will also need to > > > > be updated. > > > > > > > > Whilst it is unlikely that the 32 bit builds will be needed, at > > > > present they seem to work OK, > > > > so they might as well be kept. > > > > > > > > > Alex > > > > > > > > > > https://github.com/apache/commons-crypto/pull/166 > > > > > > > > > > On Mon, Jun 20, 2022 at 10:24 AM sebb <seb...@gmail.com> wrote: > > > > > > > > > > > On Mon, 20 Jun 2022 at 14:35, Alex Remily <alex.rem...@gmail.com> > > > > wrote: > > > > > > > > > > > > > > Sebb, > > > > > > > > > > > > > > I cloned your repo and ran the dockerfile. Feedback: > > > > > > > > > > > > > > The Maven download link is broken. It appears Apache updated to > > > > 3.8.6 on > > > > > > > the 17th. I think the 3.6.3 build is less likely (although > > still not > > > > > > > certain--as you pointed out) to get overwritten. > > > > > > > > > > > > My build uses 3.6.3, so I think you may have got the wrong checkout > > > > > > > > > > > > > > > > > > > > > > > > https://github.com/apache/commons-crypto/blob/79374289bdd227b5b668039c9336cd10d9e3bf7c/src/docker/Dockerfile#L52 > > > > > > > > > > > > > RUN wget > > > > > > > > > > > > > > > > > > > https://dlcdn.apache.org/maven/maven-3/3.8.5/binaries/apache-maven-3.8.5-bin.tar.gz > > > > > > > > > > > > > > > > > > > > > I updated all the references to 3.6.3 and reran the build. > > > > > > > > > > > > > > > > > > > > > It seems there is a pathing issue on the container: > > > > > > > > > > > > > > > > > > > > > > [22/23] RUN VERSION=1.1.1-SNAPSHOT > > > > > > > JAVA_HOME=/usr/lib/jvm/java-8-openjdk-amd64 make: > > > > > > > > > > > > > > #25 0.283 Error: Could not find or load main class > > > > > > > org.apache.commons.crypto.OsInfo > > > > > > > > > > > > > > > > > > > > > Note that it may not be possible to provide one *static* > > environment > > > > that > > > > > > > is capable of performing all builds. This is because the 32-bit > > > > linux > > > > > > > build requires the "multilib" packages, and it appears that the > > > > > > "multilib" > > > > > > > packages overwrite the other gcc and g++ installations. I > > happened > > > > > > across > > > > > > > this behavior when composing the full build dockerfile. To > > > > illustrate, > > > > > > > refer to > > > > > > https://github.com/aremily/commons-crypto/blob/master/Dockerfile > > > > > > > and notice lines 63-65. Now move the multilib installs (lines 63 > > > > and 64) > > > > > > > somewhere before the other 32 bit builds (line 58), and I expect > > > > you'll > > > > > > get > > > > > > > a "not found" error during the build. > > > > > > > > > > > > Yes, I found that, and had to move linux32 into a separate build. > > > > > > > > > > > > It might perhaps be worth creating separate builds for 32 bit and > > 64 > > > > bit > > > > > > > > > > > > However they would be nearly 2GB each, unless some pruning can be > > done. > > > > > > > > > > > > > > > > > > > > I would welcome the effort to (in)validate my observations or to > > > > > > identify a > > > > > > > solution. I agree that it would be nice to provide an > > environment > > > > that > > > > > > > supports all build profiles. I'm just not certain it's > > > > supportable. I > > > > > > > think the simplest way ahead may be to provide one dockerfile > > that > > > > does a > > > > > > > full multi-arch build and let developers modify it as they see > > fit to > > > > > > > perform more limited builds. Much easier to remove existing > > builds > > > > than > > > > > > to > > > > > > > add them. Local builds can be performed locally, as they are > > now. > > > > > > > > > > > > That's partly why I removed the Maven builds from the Docker > > build; it > > > > > > makes things more flexible. > > > > > > > > > > > > > > > > > > > > Alex > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Sat, Jun 18, 2022 at 6:53 PM sebb <seb...@gmail.com> wrote: > > > > > > > > > > > > > > > I took the very useful Dockerfile from Alex and updated it to > > split > > > > > > > > the Maven build into a separate script. > > > > > > > > > > > > > > > > There are now two stages: > > > > > > > > - create the build environment with all the necessary tools > > > > > > > > - run Maven to build the various objects > > > > > > > > > > > > > > > > The container uses the source (and Maven repo) from the host, > > so > > > > the > > > > > > > > output is generated on the host. > > > > > > > > > > > > > > > > This means it is easy to make source changes; the Docker build > > > > should > > > > > > > > rarely need updating. > > > > > > > > For details, please see > > > > > > > > > > > > https://github.com/apache/commons-crypto/tree/sebb-docker/src/docker > > > > > > > > > > > > > > > > To try it, check out the sebb-docker branch and cd src/docker > > > > > > > > > > > > > > > > It probably needs some tweaking... > > > > > > > > > > > > > > > > Sebb > > > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > > > > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > > > > > > > For additional commands, e-mail: dev-h...@commons.apache.org > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > > > > > For additional commands, e-mail: dev-h...@commons.apache.org > > > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > > > For additional commands, e-mail: dev-h...@commons.apache.org > > > > > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > For additional commands, e-mail: dev-h...@commons.apache.org > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
