I hope to have a PR in this weekend sometime with an increase in code coverage for streams. I haven't touched anything else yet, so any other package is fair game.
On Fri, Apr 24, 2020 at 12:16 PM Geoffrey Blake <geoffrey.w.bl...@gmail.com> wrote: > I figure everyone is a bit busy, but wanted to ask where we are all in > getting close to a new release of commons-crypto that contains the new > binaries, Alex, Gary? Any other unit test areas that need attention > Alex that you may need help with? > > -Geoff > > On Wed, Apr 22, 2020 at 11:33 AM Adam Retter > <adam.ret...@googlemail.com.invalid> wrote: > > > > If you want to build on CentOS for releases that is fine - I can add > > Docker Build Environments as a Travis job that use older CentOS. > > > > On Wed, 22 Apr 2020 at 18:02, Geoffrey Blake <geoffrey.w.bl...@gmail.com> > wrote: > > > > > > I think it depends on whether using Ubuntu 14.04/16.04 as the base > > > distro for releases is ok. It seems most projects like to build on > > > some variant of RHEL/CentOS as they typically use stable (read older) > > > compilers and libc. > > > > > > Does Travis allow building all the binaries then having a final > > > process that gathers all the artifacts up in the end to perform the > > > release? > > > > > > @garydgregory, thoughts on this? > > > > > > On Wed, Apr 22, 2020 at 3:39 AM Adam Retter > > > <adam.ret...@googlemail.com.invalid> wrote: > > > > > > > > No that https://github.com/apache/commons-crypto/pull/96 has been > > > > merged, we have support for Arm64, ppc64le and x64 in Travis. > > > > > > > > I wondered if it was useful for the "Release Process" if we had > Travis > > > > build and store release artifacts? I believe we can have Travis do > > > > this only when Git tags are created. So if there is a Tag for each > > > > release (which I assume there is) - then you could have the release > > > > binaries built and delivered automatically for you. It is possible to > > > > go as far as having them uploaded to Maven Central (staging) if you > > > > wished. > > > > > > > > On Sat, 18 Apr 2020 at 17:40, Adam Retter < > adam.ret...@googlemail.com> wrote: > > > > > > > > > > As promised, I added support for further environments to Travis - > > > > > https://github.com/apache/commons-crypto/pull/96 > > > > > > > > > > On Mon, 13 Apr 2020 at 16:35, Alex Remily <alex.rem...@gmail.com> > wrote: > > > > > > > > > > > > I don't know whether it would help the build manager with the > release > > > > > > process, but I think it would be a good idea to update the build > matrix > > > > > > regardless. I made an attempt a while ago to add coverage for > more > > > > > > environments, but ultimately I wasn't successful. I don't > recall if the > > > > > > limitations were Travis's or my own, but I would certainly > welcome someone > > > > > > fleshing out the build matrix to test against OpenSSL 1.0 and > 1.1 APIs in > > > > > > whatever Windows, Mac, Linux and Arm64 environments Travis > supports. My > > > > > > $0.02. > > > > > > > > > > > > Alex > > > > > > > > > > > > On Mon, Apr 13, 2020 at 2:53 AM Adam Retter > > > > > > <adam.ret...@googlemail.com.invalid> wrote: > > > > > > > > > > > > > Travis now offer Arm64 and Mac. I could setup a job to build > binaries on > > > > > > > Travis and keep a copy either on every commit or when a tag is > created. > > > > > > > Would that be helpful? > > > > > > > > > > > > > > On Mon, 13 Apr 2020, 03:13 Gary Gregory, < > garydgreg...@gmail.com> wrote: > > > > > > > > > > > > > > > On Sun, Apr 12, 2020 at 8:57 PM Alex Remily < > alex.rem...@gmail.com> > > > > > > > wrote: > > > > > > > > > > > > > > > > > I can do the 64 bit builds on Mac, Linux and Windows, so > I'm happy to > > > > > > > > > provide whichever of those is required. It seems that > Geoff can do the > > > > > > > > > arm64 build. Do we even bother supporting 32 bit > architectures at this > > > > > > > > > point? > > > > > > > > > > > > > > > > > > > > > > > > > Unfortunately, we cannot just pick up bits from folks here > and there. It > > > > > > > > all has to be buildable from Maven by the release manager in > order to > > > > > > > > generate the file signatures properly. > > > > > > > > > > > > > > > > Based on what I see in the docs, it looks like this is > buildable using > > > > > > > > cross-compilation with MinGW on Windows. Not sure about the > Mac stuff > > > > > > > yet. > > > > > > > > > > > > > > > > I'm not sure what the use-case is for 32-bit at this point. > > > > > > > > > > > > > > > > Gary > > > > > > > > > > > > > > > > > > > > > > > > > On Sun, Apr 12, 2020 at 7:36 PM Marcelo Vanzin < > van...@apache.org> > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > Hi Gary, > > > > > > > > > > > > > > > > > > > > On Sun, Apr 12, 2020 at 8:53 AM Gary Gregory < > garydgreg...@gmail.com > > > > > > > > > > > > > > > > > > wrote: > > > > > > > > > > > > The 1.0 release on maven central only included > linux32 and > > > > > > > linux64 > > > > > > > > > > native > > > > > > > > > > > > libs, even though the Makefile supports many more > targets > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Please see the snapshot builds which now include more: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > https://repository.apache.org/content/repositories/snapshots/org/apache/commons/commons-crypto/1.1.0-SNAPSHOT > > > > > > > > > > > > > > > > > > > > Here's the native stuff in your snapshot jar: > > > > > > > > > > > > > > > > > > > > $ jar tf commons-crypto-1.1.0-20200411.124009-5.jar | > grep > > > > > > > > > > nativeorg/apache/commons/crypto/native/ > > > > > > > > > > org/apache/commons/crypto/native/Linux/ > > > > > > > > > > org/apache/commons/crypto/native/Linux/x86_64/ > > > > > > > > > > > org/apache/commons/crypto/native/Linux/x86_64/libcommons-crypto.so > > > > > > > > > > > > > > > > > > > > Here's the 1.0 release: > > > > > > > > > > > > > > > > > > > > $ jar tf > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ~/.ivy2/cache/org.apache.commons/commons-crypto/jars/commons-crypto-1.0.0.jar > > > > > > > > > > | grep native > > > > > > > > > > org/apache/commons/crypto/native/ > > > > > > > > > > org/apache/commons/crypto/native/Linux/ > > > > > > > > > > org/apache/commons/crypto/native/Linux/x86/ > > > > > > > > > > org/apache/commons/crypto/native/Linux/x86_64/ > > > > > > > > > > org/apache/commons/crypto/native/Mac/ > > > > > > > > > > org/apache/commons/crypto/native/Mac/x86_64/ > > > > > > > > > > org/apache/commons/crypto/native/Windows/ > > > > > > > > > > org/apache/commons/crypto/native/Windows/x86/ > > > > > > > > > > org/apache/commons/crypto/native/Windows/x86_64/ > > > > > > > > > > > org/apache/commons/crypto/native/Linux/x86/libcommons-crypto.so > > > > > > > > > > > org/apache/commons/crypto/native/Linux/x86_64/libcommons-crypto.so > > > > > > > > > > > org/apache/commons/crypto/native/Mac/x86_64/libcommons-crypto.jnilib > > > > > > > > > > > org/apache/commons/crypto/native/Windows/x86/commons-crypto.dll > > > > > > > > > > > org/apache/commons/crypto/native/Windows/x86_64/commons-crypto.dll > > > > > > > > > > > > > > > > > > > > That's the only thing that worries me: finding someone > who can build > > > > > > > > > > all those extra native libraries. I tend to agree that > linux64 is the > > > > > > > > > > most important one, but it would be technically a > regression from 1.0 > > > > > > > > > > to skip the others. > > > > > > > > > > > > > > > > > > > > That being said, if we can't solve that, I think it's > better to > > > > > > > > > > release something rather than nothing. > > > > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > > > > > > > To unsubscribe, e-mail: > dev-unsubscr...@commons.apache.org > > > > > > > > > > For additional commands, e-mail: > dev-h...@commons.apache.org > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > Adam Retter > > > > > > > > > > skype: adam.retter > > > > > tweet: adamretter > > > > > http://www.adamretter.org.uk > > > > > > > > > > > > > > > > -- > > > > Adam Retter > > > > > > > > skype: adam.retter > > > > tweet: adamretter > > > > http://www.adamretter.org.uk > > > > > > > > --------------------------------------------------------------------- > > > > 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 > > > > > > > > > -- > > Adam Retter > > > > skype: adam.retter > > tweet: adamretter > > http://www.adamretter.org.uk > > > > --------------------------------------------------------------------- > > 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 > >
