s with the following +1s:
> >
> > - Alex Remily
> > - Geoffrey Blake
> > - Bruno P. Kinoshita, binding
> > - Rob Tompkins, binding
> > - Gary Gregory, binding
> >
> > Thank you all,
> > Gary
> >
> > On Tue, Sep 1, 2020 at 11:52 AM Gary
+1
mvn -V clean package
Apache Maven 3.6.3
Maven home: /usr/share/maven
Java version: 1.8.0_265, vendor: Private Build, runtime:
/usr/lib/jvm/java-8-openjdk-arm64/jre
Default locale: en, platform encoding: UTF-8
OS name: "linux", version: "5.4.0-1021-aws", arch: "aarch64", family: "unix"
On Sun
Hi all,
For the simple smoke test, on AArch64 for AmazonLinux2 (OpenSSL 1.0.2k) and
Ubuntu 20.04 (OpenSSL 1.1.1f) everything loads ok with the current Jar that
Gary posted.
-Geoff
AL2 output:
java -cp commons-crypto-1.1.0-20200824.190246-21.jar
org.apache.commons.crypto.Crypto
Apache Commons Cry
>From my end, that latest jar from 8/24 is working on AArch64 with a simple
test on OpenSSL 1.1.x and OpenSSL 1.0.x based distros. I'm now trying it
out on Spark to see if it links up with OpenSSL instead of the JCE.
-Geoff
On Tue, Aug 25, 2020 at 9:47 AM Alex Remily wrote:
> Bruno,
>
> Are yo
Hi Gary,
Which snapshots have Linux binaries in them? As far as I can tell, the
recent ones uploaded are Mac only, and the one from 8/18 had that weird
/native/native directory issue. For what it's worth, Mac binaries are
working on my laptop, though I'm using LibreSSL which is what comes
insta
Not familiar with Apache CI, but github actions do not support Arm builds.
Arm should be recognized as a first class build target these days. Travis
allows Arm builds so not sure about the reasoning for moving off.
-Geoff
On Sat, Aug 15, 2020 at 1:11 PM Matt Sicker wrote:
> Agreed on the GitHu
Hi Gary, has a solution for the Mac build been reached? Do you
require some assistance here? As Bindul suggested, Travis has support
for uploading artifacts to AWS S3:
https://docs.travis-ci.com/user/uploading-artifacts/
This may alleviate the issue with accepting an unknown artifact, and
with
nsitive. This is not true
> > > > > on a Linux box though. I submitted a new PR to fix this and get
> > > > > Windows builds working again on a Linux box, as well as testing that
> > > > > windows artifacts will still build via Travis. Hopeful
facts will still build via Travis. Hopefully this can
unstick the release as you can now cross-compile everything save the
OSX shared-lib on one box by pointing Maven to the proper targets.
-Geoff
On Sat, Jul 18, 2020 at 11:25 AM Gary Gregory wrote:
>
> On Thu, Jul 2, 2020 at 12:39 PM Geo
wrote:
>
> I'll see if I have any time this weekend, but this part is largely
> unfamiliar to me, so not sure how far I'll get even if I have the time
> to look at it.
>
> On Tue, Jun 30, 2020 at 4:59 PM Geoffrey Blake
> wrote:
> >
> > I think you'
it may have had something to do with
> cross-compiling for the build.
>
> On Thu, Jun 25, 2020 at 1:13 PM Geoffrey Blake
> wrote:
> >
> > Is there anything needed to help move this release along? From the
> > looks of the Makefile, Windows was using GCC. I don&#x
Is there anything needed to help move this release along? From the
looks of the Makefile, Windows was using GCC. I don't think the
compiler is going to have much of an impact since the JNI bindings are
simply calling through to the OpenSSL library that is already
precompiled for the environment.
k this weekend...
>
> Gary
>
> On Fri, May 15, 2020 at 10:19 AM Geoffrey Blake
> wrote:
>
> > bump
> >
> > On Mon, May 11, 2020 at 10:21 AM Geoffrey Blake
> > wrote:
> > >
> > > All outstanding PR's have been merged to the repositor
bump
On Mon, May 11, 2020 at 10:21 AM Geoffrey Blake
wrote:
>
> All outstanding PR's have been merged to the repository, the code
> coverage from coveralls looks good to me at over 80% coverage.
>
> There are some areas that lack coverage, such as static main functio
, can we move forward with getting a new release? Marcelo
merged some build system fixes that should allow us to now collect
artifacts from the various platforms to one primary build machine for
Gary to do the final release.
-Geoff
On Tue, Apr 28, 2020 at 9:31 AM Geoffrey Blake
wrote:
>
>
tBytes,
> cipherText);
>
> temp = new byte[cipherText.length + blockSize];
> final int m = dec.doFinal(cipherText, 0, cipherText.length, temp, 0);
> final byte[] plainText = new byte[m];
> System.arraycopy(temp, 0, plainText, 0,
JNA is the middle ground between JNI and JCE in terms of performance
is my understanding without needing any .c files to create linkage.
The problem appears to be that there is no conditional loading and
stubbing of functions like can be done easily in the JNI code and is
why macOS throws that erro
Hi Alex,
Just a sanity check, are you sure it was the JNI failing to load or
was it the JNA? At least on my Mojave MacOS install, libreSSL is
found and links fine with JNI. JNA is the library that fails to load
on macOS, but that is apparently ok as the JNA implementation is not
used by anything
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
> wrote:
> >
> > I think it depends on whether using Ubuntu 14.04/16
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 t
I've gotten through the JNA code and Random code for increasing unit
testing. I've got some changes I'm readying to bump up coverage by a
few percentage points, mainly along the lines of passing in invalid
output and making sure nothing falls over.
@Alex, any luck with the stream portion of the t
rstand what
extra tests if any can be written. Haven't gotten to the random part
of the library yet.
-Geoff
On Thu, Apr 16, 2020 at 8:56 PM Gary Gregory wrote:
>
> On Thu, Apr 16, 2020 at 5:57 PM Geoffrey Blake
> wrote:
>
> > I got distracted and wanted to know why you m
>
> On Wed, Apr 15, 2020 at 5:46 PM Geoffrey Blake
> wrote:
>
> > So, I built commons-crypto against SSL 1.0.2n on Ubuntu 18.04LTS and
> > all the tests pass. The code coverage bumps to 72%, I'm guessing if I
> > did Mac we'd see the 73% coverage seen from
he.crypto.jna and
.random to help Alex. Lets see how high of coverage we can get without
creating testing anti-patterns. My Java experience is years old so I
have to re-learn some things here and there.
-Geoff
On Wed, Apr 15, 2020 at 8:19 PM Gary Gregory wrote:
>
> On Wed, Apr 15, 2020 at
So, I built commons-crypto against SSL 1.0.2n on Ubuntu 18.04LTS and
all the tests pass. The code coverage bumps to 72%, I'm guessing if I
did Mac we'd see the 73% coverage seen from Travis CI.
@Gary, what should a reasonable coverage target be? 73% is not great,
but not sure how much higher thi
y the build system is deprecated, at
some point the build system needs to take this into account. I could
not build on my Mac using brew to install dependencies as the JDK
stack I get is too new.
On Sun, Apr 12, 2020 at 10:53 AM Gary Gregory wrote:
>
> On Sun, Apr 12, 2020 at 10:49 AM Geo
> If the only concern is the file signatures, I'm almost sure that the
> maven build will pick up native libraries you drop in some directory
> and include them in the jar, regardless of whether they're for the
> current architecture. Then you'd get the jar with all native libraries
> and the right
usy with
> family stuff. I can contribute an OS X build (High Sierra) if you're
> looking for one.
>
> Alex
>
> On Sun, Apr 12, 2020 at 11:53 AM Gary Gregory
> wrote:
>
> > On Sun, Apr 12, 2020 at 10:49 AM Geoffrey Blake <
> > geoffrey.w.bl...@gmail.com&
Gary, Alex,
Let me know what else needs doing. I can certainly help with building
artifacts, just need guidance on minimum distro and Java to use.
The 1.0 release on maven central only included linux32 and linux64 native
libs, even though the Makefile supports many more targets
-Geoff
On Sun, A
pointed in the right direction.
>
> Alex
>
> On Tue, Apr 7, 2020 at 4:04 PM Geoffrey Blake
> wrote:
>
> > Hi all,
> >
> > I see its been 4 years since the last release of commons crypto to
> > https://mvnrepository.com/artifact/org.apache.commons/commons-cr
Hi all,
I see its been 4 years since the last release of commons crypto to
https://mvnrepository.com/artifact/org.apache.commons/commons-crypto.
There has been many updates to the repository since then, notably the
integration of OpenSSL 1.1.1, and native arm64 support.
What are the blockers to m
31 matches
Mail list logo
