I’ve fixed the failing timestamps related cqlsh dtests in my 10190 branch which 
hasn’t yet been merged. It’s a known issue related to 15257 (more context in 
there). The test needs to be adjusted for new time stamp formats.

Dinesh

> On Feb 4, 2020, at 10:19 AM, Sumanth Pasupuleti 
> <sumanth.pasupuleti...@gmail.com> wrote:
> 
> Java8 Test run summary for 4.0-alpha3-tentative
> Passing UTs: https://circleci.com/gh/sumanth-pasupuleti/cassandra/852
> Passing jvm_dtests: https://circleci.com/gh/sumanth-pasupuleti/cassandra/853
> 1 failing dtest (
> https://circleci.com/gh/sumanth-pasupuleti/cassandra/855#tests/containers/92
> ,
> https://circleci.com/gh/sumanth-pasupuleti/cassandra/854#tests/containers/96
> )
> test_datetime_values - cqlsh_tests.test_cqlsh.TestCqlsh
> cqlsh_tests/test_cqlsh.py
> 
> more
> AssertionError: Failed to execute cqlsh: <stdin>:13:InvalidRequest:
> Error from server: code=2200 [Invalid query] message="Unable to coerce
> '1582-1-1' to a formatted date (long)"   <stdin>:15:InvalidRequest:
> Error from server: code=2200 [Invalid query] message="Unable to coerce
> '0-1-1' to a formatted date (long)"   <stdin>:17:InvalidRequest: Error
> from server: code=2200 [Invalid query] message="Unable to coerce
> '1-1-1' to a formatted date (long)"   <stdin>:19:InvalidRequest: Error
> from server: code=2200 [Invalid query] message="Unable to coerce
> '9999-1-1' to a formatted date (long)"   <stdin>:21:InvalidRequest:
> Error from server: code=2200 [Invalid query] message="Unable to coerce
> '10000-1-1' to a formatted date (long)"    assert 0 == 680  +  where
> 680 = len('<stdin>:13:InvalidRequest: Error from server: code=2200
> [Invalid query] message="Unable to coerce \'1582-1-1\' to a f...st:
> Error from server: code=2200 [Invalid query] message="Unable to coerce
> \'10000-1-1\' to a formatted date (long)"\n')
> 
> 
> Thanks,
> Sumanth
> 
>> On Mon, Feb 3, 2020 at 7:09 PM Michael Shuler <mich...@pbandjelly.org>
>> wrote:
>> 
>>> On 2/3/20 5:21 PM, Mick Semb Wever wrote:
>>> 
>>>> Summary of notes:
>>>> - Artifact set checks out OK with regards to key sigs and checksums.
>>>> - CASSANDRA-14962 is an issue when not using the current deb build
>>>> method (using new docker method results in different source artifact
>>>> creation & use). The docker rpm build suffers the same source problem
>>>> and the src.rpm is significantly larger, since I think it copies all the
>>>> downloaded maven artifacts in. It's fine for now, though :)
>>>> - UNRELEASED deb build
>>> 
>>> 
>>> Thanks for the thorough review Michael.
>>> 
>>> I did not know about CASSANDRA-14962, but it should be easy to fix now
>> that the -src.tar.gz is in the dev dist location and easy to re-use. I'll
>> see if I can create a patch for that (aiming to use it on alpha4).
>> 
>> Yep! Similarly, the rpm build has been wrong all along, but it's what we
>> have. The -src.tar.gz should get copied to /$build/$path/SOURCE dir, I
>> think it is(?). I think that might cure the larger .src.rpm.
>> 
>>> And I was unaware of the UNRELEASED version issue. I can put a patch in
>> for that too, going into the prepare_release.sh script.
>> 
>> `dch -r` is usually a step I do before building, also checking NEWS and
>> CHANGES and build.xml versions all align. Then the correct commit gets
>> -tentative tagged. Building `dch -r` in would be OK, if all the other
>> ducks are in a row.
>> 
>>>> Next step
>>>> would be to do each package-type install and startup functional testing,
>>>> but I don't have that time right now :)
>>> 
>>> 
>>> I'm going to presume others that have voted have done package-type
>> installs and the basic testing, and move ahead. If I close the vote, I will
>> need your help Michael with the final steps running the patched
>> finish_release.sh from the `mck/14970_sha512-checksums` branch, found in
>> https://github.com/thelastpickle/cassandra-builds/blob/mck/14970_sha512-checksums/
>>>     Because only PMC can `svn move` the files into
>> dist.apache.org/repos/dist/release/
>> 
>> I usually do this before vote. I don't know how many other people, if
>> any, test that all the packages can install and start.
>> 
>>> And for the upload_bintray.sh script, how do I get credentials, an infra
>> ticket i presume? (ie to https://bintray.com/apache )
>> 
>> If I recall, I did an infra ticket with my github user id - this is how
>> I log in. Once logged into bintray, you can find a token down in the
>> user profile somewhere, which is used in the script.
>> 
>> Thanks again for walking through these steps.
>> 
>> Michael
>> 
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
>> For additional commands, e-mail: dev-h...@cassandra.apache.org
>> 
>> 


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org

Reply via email to