Activity log for bug #1942476

Date Who What changed Old value New value Message
2021-09-02 20:36:16 Paride Legovini bug added bug
2021-09-02 20:36:24 Paride Legovini ruby-mysql2 (Ubuntu): status New Triaged
2021-09-02 20:38:05 Paride Legovini bug watch added https://github.com/brianmario/mysql2/issues/1208
2021-09-02 20:38:05 Paride Legovini bug task added mysql-server
2021-09-02 20:38:56 Paride Legovini nominated for series Ubuntu Focal
2021-09-02 20:38:56 Paride Legovini bug task added ruby-mysql2 (Ubuntu Focal)
2021-09-02 20:38:56 Paride Legovini nominated for series Ubuntu Hirsute
2021-09-02 20:38:56 Paride Legovini bug task added ruby-mysql2 (Ubuntu Hirsute)
2021-09-02 20:39:04 Paride Legovini ruby-mysql2 (Ubuntu Focal): status New Triaged
2021-09-02 20:39:07 Paride Legovini ruby-mysql2 (Ubuntu Hirsute): status New Triaged
2021-09-07 10:58:47 Paride Legovini affects mysql-server ruby-mysql2
2021-09-07 11:59:08 Paride Legovini ruby-mysql2 (Ubuntu): status Triaged Fix Released
2021-09-07 11:59:25 Paride Legovini tags block-proposed-focal block-proposed-hirsute
2021-09-07 12:07:11 Paride Legovini ruby-mysql2 (Ubuntu Focal): assignee Paride Legovini (paride)
2021-09-07 12:07:13 Paride Legovini ruby-mysql2 (Ubuntu Hirsute): assignee Paride Legovini (paride)
2021-09-07 13:23:47 Paride Legovini description 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 is because according to the 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. 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. [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: 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. 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.
2021-09-07 13:27:46 Paride Legovini description [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: 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. 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. [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; 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.
2021-09-07 13:31:26 Paride Legovini description [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; 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. [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; 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. As this is a test fix I'm tagging this bug as block-proposed. [Development Fix] 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] What it's being proposed here it the same fix uploaded to the devel release (Impish) by the security team, with no changes.
2021-09-07 13:38:51 Launchpad Janitor merge proposal linked https://code.launchpad.net/~paride/ubuntu/+source/ruby-mysql2/+git/ruby-mysql2/+merge/408216
2021-09-07 13:39:11 Launchpad Janitor merge proposal linked https://code.launchpad.net/~paride/ubuntu/+source/ruby-mysql2/+git/ruby-mysql2/+merge/408217
2021-09-07 13:42:25 Paride Legovini ruby-mysql2 (Ubuntu Focal): status Triaged In Progress
2021-09-07 13:42:31 Paride Legovini ruby-mysql2 (Ubuntu Hirsute): status Triaged In Progress
2021-09-11 04:01:57 Bug Watch Updater ruby-mysql2: status Unknown New
2021-09-14 16:50:48 Brian Murray ruby-mysql2 (Ubuntu Hirsute): status In Progress Fix Committed
2021-09-14 16:50:52 Brian Murray bug added subscriber Ubuntu Stable Release Updates Team
2021-09-14 16:50:54 Brian Murray bug added subscriber SRU Verification
2021-09-14 16:50:58 Brian Murray tags block-proposed-focal block-proposed-hirsute block-proposed-focal block-proposed-hirsute verification-needed verification-needed-hirsute
2021-09-14 16:52:58 Brian Murray ruby-mysql2 (Ubuntu Focal): status In Progress Fix Committed
2021-09-14 16:53:03 Brian Murray tags block-proposed-focal block-proposed-hirsute verification-needed verification-needed-hirsute block-proposed-focal block-proposed-hirsute verification-needed verification-needed-focal verification-needed-hirsute
2021-09-15 08:50:15 Paride Legovini tags block-proposed-focal block-proposed-hirsute verification-needed verification-needed-focal verification-needed-hirsute block-proposed-focal block-proposed-hirsute verification-done verification-done-focal verification-done-hirsute
2021-09-23 16:23:38 Paride Legovini ruby-mysql2 (Ubuntu): assignee Paride Legovini (paride)
2021-09-23 16:23:41 Paride Legovini ruby-mysql2 (Ubuntu Focal): assignee Paride Legovini (paride)
2021-09-23 16:23:44 Paride Legovini ruby-mysql2 (Ubuntu Hirsute): assignee Paride Legovini (paride)
2021-11-30 21:24:51 Bug Watch Updater ruby-mysql2: status New Fix Released
2022-01-26 22:03:03 Brian Murray ruby-mysql2 (Ubuntu Hirsute): status Fix Committed Won't Fix