** Description changed:
+ [Impact]
+
The test suite is failing when running against MySQL >= 8.0.24 with:
---------------------------------------------
Failures:
- 1) Mysql2::Result row data type mapping should raise an error given an
invalid DATETIME
- Failure/Error:
- expect { @client.query("SELECT CAST('1972-00-27 00:00:00' AS DATETIME)
as bad_datetime").each }.to \
- raise_error(Mysql2::Error, "Invalid date in field 'bad_datetime':
1972-00-27 00:00:00")
+ 1) Mysql2::Result row data type mapping should raise an error given an
invalid DATETIME
+ Failure/Error:
+ expect { @client.query("SELECT CAST('1972-00-27 00:00:00' AS DATETIME)
as bad_datetime").each }.to \
+ raise_error(Mysql2::Error, "Invalid date in field 'bad_datetime':
1972-00-27 00:00:00")
- expected Mysql2::Error with "Invalid date in field 'bad_datetime':
1972-00-27 00:00:00" but nothing was raised
- # ./spec/mysql2/result_spec.rb:321:in `block (3 levels) in <top
(required)>'
+ expected Mysql2::Error with "Invalid date in field 'bad_datetime':
1972-00-27 00:00:00" but nothing was raised
+ # ./spec/mysql2/result_spec.rb:321:in `block (3 levels) in <top
(required)>'
- 2) Mysql2::Statement row data type mapping should raise an error given an
invalid DATETIME
- Failure/Error:
- expect { @client.query("SELECT CAST('1972-00-27 00:00:00' AS DATETIME)
as bad_datetime").each }.to \
- raise_error(Mysql2::Error, "Invalid date in field 'bad_datetime':
1972-00-27 00:00:00")
+ 2) Mysql2::Statement row data type mapping should raise an error given an
invalid DATETIME
+ Failure/Error:
+ expect { @client.query("SELECT CAST('1972-00-27 00:00:00' AS DATETIME)
as bad_datetime").each }.to \
+ raise_error(Mysql2::Error, "Invalid date in field 'bad_datetime':
1972-00-27 00:00:00")
- expected Mysql2::Error with "Invalid date in field 'bad_datetime':
1972-00-27 00:00:00" but nothing was raised
- # ./spec/mysql2/statement_spec.rb:478:in `block (3 levels) in <top
(required)>'
+ expected Mysql2::Error with "Invalid date in field 'bad_datetime':
1972-00-27 00:00:00" but nothing was raised
+ # ./spec/mysql2/statement_spec.rb:478:in `block (3 levels) in <top
(required)>'
---------------------------------------------
- This is because according to the release notes
+ This regression was introduced by the following upload:
+
+ mysql-8.0 (8.0.25-0ubuntu0.20.04.1) focal-security;
+
+ According to the MySQL release notes
(https://dev.mysql.com/doc/relnotes/mysql/8.0/en/news-8-0-24.html):
- Using CAST() on a DATE or DATETIME value in an INSERT statement
- raised a warning for "0000-00-00" and "2000-02-31", but not for
- "2000-01-00" or "2000-00-01". Now a warning is shown in each of
- these cases also.
+ Using CAST() on a DATE or DATETIME value in an INSERT statement
+ raised a warning for "0000-00-00" and "2000-02-31", but not for
+ "2000-01-00" or "2000-00-01". Now a warning is shown in each of
+ these cases also.
- The statement_spec.rb and result_spec.rb files need to be updated with a
- bad date that still generates an error, e.g. 2000-01-00.
+ but the ruby-mysql2 tests rely on the old behavior.
+
+ This is preventing Focal and Hirsute SRUs from migrating when they
+ trigger a ruby-mysql2 autopkgtest run.
+
+ [Test Plan]
+
+ Once the autopkgtest pass the fix can be considered verified.
+
+ [Where problems could occur]
+
+ The SRU only touches test code, so this upload won't change the behavior
+ of the package in any user visible way.
+
+ To lower the possibility of issues even more I'm tagging this bug as
+ block-proposed.
+
+ [Development Fix]
+
+ Already fixed by the security team.
+
+ I reported the bug upstream, so it's likely that one of the next
+ upstream releases will ship with a fix, and we'll then be able to drop
+ the delta.
+
+ This is not a bug in Debian *yet* because Debian still ships mysql-8.0
+ 8.0.23, the latest version with the old behavior.
+
+ [Stable Fix]
+
+ It's the same fix uploaded to the devel release (Impish) by the security
+ team, with no changes.
** Description changed:
[Impact]
The test suite is failing when running against MySQL >= 8.0.24 with:
---------------------------------------------
Failures:
1) Mysql2::Result row data type mapping should raise an error given an
invalid DATETIME
Failure/Error:
expect { @client.query("SELECT CAST('1972-00-27 00:00:00' AS DATETIME)
as bad_datetime").each }.to \
raise_error(Mysql2::Error, "Invalid date in field 'bad_datetime':
1972-00-27 00:00:00")
expected Mysql2::Error with "Invalid date in field 'bad_datetime':
1972-00-27 00:00:00" but nothing was raised
# ./spec/mysql2/result_spec.rb:321:in `block (3 levels) in <top
(required)>'
2) Mysql2::Statement row data type mapping should raise an error given an
invalid DATETIME
Failure/Error:
expect { @client.query("SELECT CAST('1972-00-27 00:00:00' AS DATETIME)
as bad_datetime").each }.to \
raise_error(Mysql2::Error, "Invalid date in field 'bad_datetime':
1972-00-27 00:00:00")
expected Mysql2::Error with "Invalid date in field 'bad_datetime':
1972-00-27 00:00:00" but nothing was raised
# ./spec/mysql2/statement_spec.rb:478:in `block (3 levels) in <top
(required)>'
---------------------------------------------
- This regression was introduced by the following upload:
+ This regression was introduced by the following uploads:
- mysql-8.0 (8.0.25-0ubuntu0.20.04.1) focal-security;
+ mysql-8.0 (8.0.25-0ubuntu0.20.04.1) focal-security;
+ mysql-8.0 (8.0.25-0ubuntu0.21.04.1) hirsute-security;
According to the MySQL release notes
(https://dev.mysql.com/doc/relnotes/mysql/8.0/en/news-8-0-24.html):
Using CAST() on a DATE or DATETIME value in an INSERT statement
raised a warning for "0000-00-00" and "2000-02-31", but not for
"2000-01-00" or "2000-00-01". Now a warning is shown in each of
these cases also.
but the ruby-mysql2 tests rely on the old behavior.
This is preventing Focal and Hirsute SRUs from migrating when they
trigger a ruby-mysql2 autopkgtest run.
[Test Plan]
Once the autopkgtest pass the fix can be considered verified.
[Where problems could occur]
The SRU only touches test code, so this upload won't change the behavior
of the package in any user visible way.
To lower the possibility of issues even more I'm tagging this bug as
block-proposed.
[Development Fix]
Already fixed by the security team.
I reported the bug upstream, so it's likely that one of the next
upstream releases will ship with a fix, and we'll then be able to drop
the delta.
This is not a bug in Debian *yet* because Debian still ships mysql-8.0
8.0.23, the latest version with the old behavior.
[Stable Fix]
It's the same fix uploaded to the devel release (Impish) by the security
team, with no changes.
** Description changed:
[Impact]
The test suite is failing when running against MySQL >= 8.0.24 with:
---------------------------------------------
Failures:
1) Mysql2::Result row data type mapping should raise an error given an
invalid DATETIME
Failure/Error:
expect { @client.query("SELECT CAST('1972-00-27 00:00:00' AS DATETIME)
as bad_datetime").each }.to \
raise_error(Mysql2::Error, "Invalid date in field 'bad_datetime':
1972-00-27 00:00:00")
expected Mysql2::Error with "Invalid date in field 'bad_datetime':
1972-00-27 00:00:00" but nothing was raised
# ./spec/mysql2/result_spec.rb:321:in `block (3 levels) in <top
(required)>'
2) Mysql2::Statement row data type mapping should raise an error given an
invalid DATETIME
Failure/Error:
expect { @client.query("SELECT CAST('1972-00-27 00:00:00' AS DATETIME)
as bad_datetime").each }.to \
raise_error(Mysql2::Error, "Invalid date in field 'bad_datetime':
1972-00-27 00:00:00")
expected Mysql2::Error with "Invalid date in field 'bad_datetime':
1972-00-27 00:00:00" but nothing was raised
# ./spec/mysql2/statement_spec.rb:478:in `block (3 levels) in <top
(required)>'
---------------------------------------------
This regression was introduced by the following uploads:
- mysql-8.0 (8.0.25-0ubuntu0.20.04.1) focal-security;
- mysql-8.0 (8.0.25-0ubuntu0.21.04.1) hirsute-security;
+ mysql-8.0 (8.0.25-0ubuntu0.20.04.1) focal-security;
+ mysql-8.0 (8.0.25-0ubuntu0.21.04.1) hirsute-security;
According to the MySQL release notes
(https://dev.mysql.com/doc/relnotes/mysql/8.0/en/news-8-0-24.html):
Using CAST() on a DATE or DATETIME value in an INSERT statement
raised a warning for "0000-00-00" and "2000-02-31", but not for
"2000-01-00" or "2000-00-01". Now a warning is shown in each of
these cases also.
but the ruby-mysql2 tests rely on the old behavior.
This is preventing Focal and Hirsute SRUs from migrating when they
trigger a ruby-mysql2 autopkgtest run.
[Test Plan]
Once the autopkgtest pass the fix can be considered verified.
[Where problems could occur]
The SRU only touches test code, so this upload won't change the behavior
of the package in any user visible way.
- To lower the possibility of issues even more I'm tagging this bug as
- block-proposed.
+ As this is a test fix I'm tagging this bug as block-proposed.
[Development Fix]
- Already fixed by the security team.
+ Already fixed by the security team by disabling the bad test.
I reported the bug upstream, so it's likely that one of the next
upstream releases will ship with a fix, and we'll then be able to drop
the delta.
This is not a bug in Debian *yet* because Debian still ships mysql-8.0
8.0.23, the latest version with the old behavior.
[Stable Fix]
- It's the same fix uploaded to the devel release (Impish) by the security
- team, with no changes.
+ What it's being proposed here it the same fix uploaded to the devel
+ release (Impish) by the security team, with no changes.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1942476
Title:
autopkgtest: Invalid DATETIME test fails with mysql >= 8.0.24
To manage notifications about this bug go to:
https://bugs.launchpad.net/ruby-mysql2/+bug/1942476/+subscriptions
--
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
