I'm well aware of the policies you linked and quoted: I directly
participated in the discussions which led up to the most recent change
last year.
Since I'm worried about repeating myself and producing another wall of
text in another unsuccessful attempt to clarify all the details, I'll
try to summ
Thanks for the clarification. That was a much longer response than I
anticipated, so I think I am having trouble communicating over email.
I was referencing "https://www.apache.org/dev/release-distribution.html";
which says
For every artifact distributed to the public through Apache channels,
On Tue, Apr 2, 2019 at 9:32 AM Michael Wall wrote:
>
> If I understand this correctly, you are saying the sha1 and md5 are created
> by nexus? I do recall the discussion about moving to the stronger hashes,
> so I was surprised to see sha1 and md5 still listed in the VOTE thread.
They are actual
If I understand this correctly, you are saying the sha1 and md5 are created
by nexus? I do recall the discussion about moving to the stronger hashes,
so I was surprised to see sha1 and md5 still listed in the VOTE thread.
When verifying a release, I want to verify the signatures are correct and I
Thanks Christopher. I just added a comment on
https://github.com/apache/accumulo/issues/1069 and would like to get this
included in the next RC.
On Mon, Apr 1, 2019 at 10:34 PM Christopher wrote:
> This vote fails with {-1, -1, -1, -0, +1}.
> I'll prep an RC3 once the issues identified in the t
This vote fails with {-1, -1, -1, -0, +1}.
I'll prep an RC3 once the issues identified in the thread are resolved.
--
On Wed, Mar 27, 2019 at 7:56 PM Christopher wrote:
>
> Accumulo Developers,
>
> Please consider the following candidate for Apache Accumulo 1.9.3.
>
> This supersedes RC1 and con
Apologies, but I was confused because you said the template was
wrong... but you quoted a portion of the template which was not wrong,
and which I've already explained in my original response to Mike.
Once again, those are references to files generated by the Maven
tooling, outside our control. Gr
Again, like I included earlier:
> (Append ".sha1", ".md5", or ".asc" to download the signature/hash for
a given artifact.)
On 4/1/19 1:56 PM, Christopher wrote:
In what way?
On Mon, Apr 1, 2019 at 1:54 PM Josh Elser wrote:
Your email template is wrong.
On 4/1/19 1:33 PM, Christopher wrote:
In what way?
On Mon, Apr 1, 2019 at 1:54 PM Josh Elser wrote:
>
> Your email template is wrong.
>
> On 4/1/19 1:33 PM, Christopher wrote:
> > Sorry, I don't understand what you mean by 'retelling of "checksums of
> > old"'.
> >
> > On Mon, Apr 1, 2019 at 12:30 PM Josh Elser wrote:
> >>
> >> I t
Your email template is wrong.
On 4/1/19 1:33 PM, Christopher wrote:
Sorry, I don't understand what you mean by 'retelling of "checksums of old"'.
On Mon, Apr 1, 2019 at 12:30 PM Josh Elser wrote:
I think Mike's point was your VOTE template does not reflect the
retelling of "checksums of old"
Sorry, I don't understand what you mean by 'retelling of "checksums of old"'.
On Mon, Apr 1, 2019 at 12:30 PM Josh Elser wrote:
>
> I think Mike's point was your VOTE template does not reflect the
> retelling of "checksums of old"
>
> > (Append ".sha1", ".md5", or ".asc" to download the signatur
I think Mike's point was your VOTE template does not reflect the
retelling of "checksums of old"
> (Append ".sha1", ".md5", or ".asc" to download the signature/hash for
a given artifact.)
On 3/31/19 10:54 PM, Christopher wrote:
Mike,
We already stopped using md5 and sha1 for the release artif
Mike,
We already stopped using md5 and sha1 for the release artifacts on the
mirrors. I did this some time ago, and we discussed it on list on
previous vote threads (last year)... which resulted in me changing the
release candidate build script automated tooling to embed the SHA512
sums for the ta
-1 for the issue with commons config
I check the signatures, they are good. We should stop using md5 and sha1
though, see https://www.apache.org/dev/release-distribution#sigs-and-sums.
Has anyone looked at moving to sha256 and/org sha512?
Successful run of mvn clean verify -Psunny
On Sat, Mar 30
I completed a continuous ingest run on a 10 node cluster running
Centos 7. I used the native map. I had to rebuild Accumulo to work
around #1065 inorder to get the verify M/R job to run.
org.apache.accumulo.test.continuous.ContinuousVerify$Counts
REFERENCED=34417110819
On Fri, Mar 29, 2019 at 1:42 PM Keith Turner wrote:
>
> On Thu, Mar 28, 2019 at 8:57 PM Christopher wrote:
> >
> > -1 due to https://github.com/apache/accumulo/issues/1064
>
> Do you know if this is a new bug since 1.9.2? Or does the same
> problem exist in 1.9.2, 1.9.1, etc?
>
The underlying i
-1
I ran into the following issue when trying to verify continuous ingest.
https://github.com/apache/accumulo/issues/1065
On Wed, Mar 27, 2019 at 7:57 PM Christopher wrote:
>
> Accumulo Developers,
>
> Please consider the following candidate for Apache Accumulo 1.9.3.
>
> This supersedes RC1 an
On Thu, Mar 28, 2019 at 8:57 PM Christopher wrote:
>
> -1 due to https://github.com/apache/accumulo/issues/1064
Do you know if this is a new bug since 1.9.2? Or does the same
problem exist in 1.9.2, 1.9.1, etc?
>
> On Thu, Mar 28, 2019 at 6:34 PM Mike Miller wrote:
> >
> > -0
> > Successfully
-1 due to https://github.com/apache/accumulo/issues/1064
On Thu, Mar 28, 2019 at 6:34 PM Mike Miller wrote:
>
> -0
> Successfully verified the hashes and signatures for the src and binary
> tarballs.
> Successfully built from the source tarball.
> I have concerns over native map compatibility bet
-0
Successfully verified the hashes and signatures for the src and binary
tarballs.
Successfully built from the source tarball.
I have concerns over native map compatibility between versions of the gcc
compiler on Fedora. Not enough to stop the release, since there is a work
around and seems speci
I did "sudo dnf downgrade gcc-c++" on Fedora 28, which it took me all the
way back to 8.0.1 and it still crashes. So it only works on 8.2.1?
On Thu, Mar 28, 2019 at 5:59 PM Christopher wrote:
> This problem appears to be introduced with gcc-c++ 8.3(.1?). When I do
> `sudo dnf downgrade gcc-c++`
This problem appears to be introduced with gcc-c++ 8.3(.1?). When I do
`sudo dnf downgrade gcc-c++` back to 8.2.1, it works fine.
On Thu, Mar 28, 2019 at 3:01 PM Mike Miller wrote:
>
> I am seeing a crash in NativeMapIT running on my Fedora 28 VM using Oracle
> jdk1.8.0_161:
> [INFO] Running org
+1
* Verified hashes
* Ran locally using Uno and tested with shell
On Wed, Mar 27, 2019 at 7:57 PM Christopher wrote:
> Accumulo Developers,
>
> Please consider the following candidate for Apache Accumulo 1.9.3.
>
> This supersedes RC1 and contains the following change:
> https://github.com/apa
Here is a more useful error. I am still not sure why this is happening
though.
Corrupted STDOUT by directly writing to native stream in forked JVM 1.
Stream '#'.
java.lang.IllegalArgumentException: Stream stdin corrupted. Expected comma
after third character in command '#'.
at
org.apache.m
I am seeing a crash in NativeMapIT running on my Fedora 28 VM using Oracle
jdk1.8.0_161:
[INFO] Running org.apache.accumulo.test.functional.NativeMapIT
[WARNING] Corrupted STDOUT by directly writing to native stream in forked
JVM 1. See FAQ web page and the dump file
/home/mike/Downloads/accumulo-1
Accumulo Developers,
Please consider the following candidate for Apache Accumulo 1.9.3.
This supersedes RC1 and contains the following change:
https://github.com/apache/accumulo/pull/1057
Git Commit:
94f9782242a1f336e176c282f0f90063a21e361d
Branch:
1.9.3-rc2
If this vote passes, a gpg-s
26 matches
Mail list logo
