Dear Mamoru,
Could you please check the following two packages which recently started to fail?
https://koschei.fedoraproject.org/package/rubygem-webmock?collection=f36
https://koschei.fedoraproject.org/package/rubygem-websocket-extensions?colle...
I suspect that this is related to the RSpec update, but the errors are quite strange on the first look:
~~~
1) WebMock::RequestSignature initialization assigns normalized headers Failure/Error: @headers = WebMock::Util::Headers.normalize_headers(headers) #<WebMock::Util::Headers (class)> received :normalize_headers with unexpected arguments expected: ({"A"=>"a"}) got: ({"A"=>"a"}) # ./lib/webmock/request_signature.rb:25:in `headers=' # ./lib/webmock/request_signature.rb:49:in `assign_options' # ./lib/webmock/request_signature.rb:11:in `initialize' # ./spec/unit/request_signature_spec.rb:23:in `new' # ./spec/unit/request_signature_spec.rb:23:in `block (3 levels) in <top (required)>' # ./lib/webmock/rspec.rb:37:in `block (2 levels) in <top (required)>'
~~~
Thx a lot
Vít
P.S. Sorry for not being more helpful, I have to spent some time with CentOS Stream 9 to get Ruby into shape there, especially the problematic SystemTap support [1].
Vít Ondruch wrote on 2022/02/07 20:24:
Dear Mamoru,
Could you please check the following two packages which recently started to fail?
https://koschei.fedoraproject.org/package/rubygem-webmock?collection=f36 https://koschei.fedoraproject.org/package/rubygem-websocket-extensions?colle...
I suspect that this is related to the RSpec update, but the errors are quite strange on the first look:
1) WebMock::RequestSignature initialization assigns normalized headers Failure/Error: @headers = WebMock::Util::Headers.normalize_headers(headers) #<WebMock::Util::Headers (class)> received :normalize_headers with unexpected arguments expected: ({"A"=>"a"}) got: ({"A"=>"a"}) # ./lib/webmock/request_signature.rb:25:in `headers=' # ./lib/webmock/request_signature.rb:49:in `assign_options' # ./lib/webmock/request_signature.rb:11:in `initialize' # ./spec/unit/request_signature_spec.rb:23:in `new' # ./spec/unit/request_signature_spec.rb:23:in `block (3 levels) in <top (required)>' # ./lib/webmock/rspec.rb:37:in `block (2 levels) in <top (required)>'
I am trying to fix rubygem-yard build failure, but currently I see the same issue (on my local machine).
Looks like this is: https://github.com/rspec/rspec-mocks/issues/1460 - was brought by: https://github.com/rspec/rspec-mocks/pull/1394
expecially: https://github.com/rspec/rspec-mocks/pull/1394/files#diff-ae171e2be1f799a670...
# if both arguments end with Hashes, and if one is a keyword hash and the other is not, they don't match
So rspec upstream is saying this is correct (again keywords / hash separation...), previous rspec-mocks 3.10.2 behaved wrongly with ruby3 (rspec upstream says), and rspec-mocks user side has to fix this.
Thx a lot Vít
P.S. Sorry for not being more helpful, I have to spent some time with CentOS Stream 9 to get Ruby into shape there, especially the problematic SystemTap support [1]. [1] https://bugs.ruby-lang.org/issues/18257
Regards, Mamoru
Mamoru TASAKA wrote on 2022/02/07 22:45:
Vít Ondruch wrote on 2022/02/07 20:24:
Dear Mamoru,
Could you please check the following two packages which recently started to fail?
https://koschei.fedoraproject.org/package/rubygem-webmock?collection=f36 https://koschei.fedoraproject.org/package/rubygem-websocket-extensions?colle...
I suspect that this is related to the RSpec update, but the errors are quite strange on the first look:
1) WebMock::RequestSignature initialization assigns normalized headers Failure/Error: @headers = WebMock::Util::Headers.normalize_headers(headers) #<WebMock::Util::Headers (class)> received :normalize_headers with unexpected arguments expected: ({"A"=>"a"}) got: ({"A"=>"a"}) # ./lib/webmock/request_signature.rb:25:in `headers=' # ./lib/webmock/request_signature.rb:49:in `assign_options' # ./lib/webmock/request_signature.rb:11:in `initialize' # ./spec/unit/request_signature_spec.rb:23:in `new' # ./spec/unit/request_signature_spec.rb:23:in `block (3 levels) in <top (required)>' # ./lib/webmock/rspec.rb:37:in `block (2 levels) in <top (required)>'I am trying to fix rubygem-yard build failure, but currently I see the same issue (on my local machine).
Looks like this is: https://github.com/rspec/rspec-mocks/issues/1460
- was brought by: https://github.com/rspec/rspec-mocks/pull/1394
expecially: https://github.com/rspec/rspec-mocks/pull/1394/files#diff-ae171e2be1f799a670...
# if both arguments end with Hashes, and if one is a keyword hash and the other is not, they don't match
So rspec upstream is saying this is correct (again keywords / hash separation...), previous rspec-mocks 3.10.2 behaved wrongly with ruby3 (rspec upstream says), and rspec-mocks user side has to fix this.
Just took a look at webmock (rubygem-webmock-3.11.1-4.fc36), so with rspec-mocks 3.10.3 the following change seems needed:
============================================================================ diff -urp webmock-3.11.1/spec.orig/unit/request_signature_spec.rb webmock-3.11.1/spec/unit/request_signature_spec.rb --- webmock-3.11.1/spec.orig/unit/request_signature_spec.rb 2022-02-07 23:13:47.262714681 +0900 +++ webmock-3.11.1/spec/unit/request_signature_spec.rb 2022-02-07 23:23:11.527273614 +0900 @@ -18,7 +18,7 @@ describe WebMock::RequestSignature do end
it "assigns normalized headers" do - expect(WebMock::Util::Headers).to receive(:normalize_headers).with('A' => 'a').and_return('B' => 'b') + expect(WebMock::Util::Headers).to receive(:normalize_headers).with({'A' => 'a'}).and_return('B' => 'b') expect( WebMock::RequestSignature.new(:get, "www.example.com", headers: {'A' => 'a'}).headers ).to eq({'B' => 'b'}) Only in webmock-3.11.1/spec/unit: request_signature_spec.rb~ diff -urp webmock-3.11.1/spec.orig/unit/response_spec.rb webmock-3.11.1/spec/unit/response_spec.rb --- webmock-3.11.1/spec.orig/unit/response_spec.rb 2022-02-07 23:13:47.262714681 +0900 +++ webmock-3.11.1/spec/unit/response_spec.rb 2022-02-07 23:23:52.502314196 +0900 @@ -31,7 +31,7 @@ describe WebMock::Response do end
it "should report normalized headers" do - expect(WebMock::Util::Headers).to receive(:normalize_headers).with('A' => 'a').and_return('B' => 'b') + expect(WebMock::Util::Headers).to receive(:normalize_headers).with({'A' => 'a'}).and_return('B' => 'b') @response = WebMock::Response.new(headers: {'A' => 'a'}) expect(@response.headers).to eq({'B' => 'b'}) end ============================================================================
Mamoru
Looking at Koschei failures and considering that the upstream ticket [1] is not resolved yet and there seems to be some technical difficulties as far as I understand the issue, wouldn't be better to temporary revert the PR [2]? If nothing else, I don't think it is right to have F34/F35 broken. @Mamoru WDYT?
Vít
[1] https://github.com/rspec/rspec-mocks/issues/1460
[2] https://github.com/rspec/rspec-mocks/pull/1394
Dne 07. 02. 22 v 15:26 Mamoru TASAKA napsal(a):
Mamoru TASAKA wrote on 2022/02/07 22:45:
Vít Ondruch wrote on 2022/02/07 20:24:
Dear Mamoru,
Could you please check the following two packages which recently started to fail?
https://koschei.fedoraproject.org/package/rubygem-webmock?collection=f36
https://koschei.fedoraproject.org/package/rubygem-websocket-extensions?colle...
I suspect that this is related to the RSpec update, but the errors are quite strange on the first look:
1) WebMock::RequestSignature initialization assigns normalized headers Failure/Error: @headers = WebMock::Util::Headers.normalize_headers(headers) #<WebMock::Util::Headers (class)> received :normalize_headers with unexpected arguments expected: ({"A"=>"a"}) got: ({"A"=>"a"}) # ./lib/webmock/request_signature.rb:25:in `headers=' # ./lib/webmock/request_signature.rb:49:in `assign_options' # ./lib/webmock/request_signature.rb:11:in `initialize' # ./spec/unit/request_signature_spec.rb:23:in `new' # ./spec/unit/request_signature_spec.rb:23:in `block (3 levels) in <top (required)>' # ./lib/webmock/rspec.rb:37:in `block (2 levels) in <top (required)>'I am trying to fix rubygem-yard build failure, but currently I see the same issue (on my local machine).
Looks like this is: https://github.com/rspec/rspec-mocks/issues/1460
- was brought by: https://github.com/rspec/rspec-mocks/pull/1394
expecially: https://github.com/rspec/rspec-mocks/pull/1394/files#diff-ae171e2be1f799a670...
# if both arguments end with Hashes, and if one is a keyword hash and the other is not, they don't match
So rspec upstream is saying this is correct (again keywords / hash separation...), previous rspec-mocks 3.10.2 behaved wrongly with ruby3 (rspec upstream says), and rspec-mocks user side has to fix this.
Just took a look at webmock (rubygem-webmock-3.11.1-4.fc36), so with rspec-mocks 3.10.3 the following change seems needed:
============================================================================
diff -urp webmock-3.11.1/spec.orig/unit/request_signature_spec.rb webmock-3.11.1/spec/unit/request_signature_spec.rb --- webmock-3.11.1/spec.orig/unit/request_signature_spec.rb 2022-02-07 23:13:47.262714681 +0900 +++ webmock-3.11.1/spec/unit/request_signature_spec.rb 2022-02-07 23:23:11.527273614 +0900 @@ -18,7 +18,7 @@ describe WebMock::RequestSignature do end
it "assigns normalized headers" do - expect(WebMock::Util::Headers).to receive(:normalize_headers).with('A' => 'a').and_return('B' => 'b') + expect(WebMock::Util::Headers).to receive(:normalize_headers).with({'A' => 'a'}).and_return('B' => 'b') expect( WebMock::RequestSignature.new(:get, "www.example.com", headers: {'A' => 'a'}).headers ).to eq({'B' => 'b'}) Only in webmock-3.11.1/spec/unit: request_signature_spec.rb~ diff -urp webmock-3.11.1/spec.orig/unit/response_spec.rb webmock-3.11.1/spec/unit/response_spec.rb --- webmock-3.11.1/spec.orig/unit/response_spec.rb 2022-02-07 23:13:47.262714681 +0900 +++ webmock-3.11.1/spec/unit/response_spec.rb 2022-02-07 23:23:52.502314196 +0900 @@ -31,7 +31,7 @@ describe WebMock::Response do end
it "should report normalized headers" do - expect(WebMock::Util::Headers).to receive(:normalize_headers).with('A' => 'a').and_return('B' => 'b') + expect(WebMock::Util::Headers).to receive(:normalize_headers).with({'A' => 'a'}).and_return('B' => 'b') @response = WebMock::Response.new(headers: {'A' => 'a'}) expect(@response.headers).to eq({'B' => 'b'}) end ============================================================================
Mamoru _______________________________________________ ruby-sig mailing list -- ruby-sig@lists.fedoraproject.org To unsubscribe send an email to ruby-sig-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/ruby-sig@lists.fedoraproject.o... Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
There is more issues like this :/
https://github.com/rspec/rspec-expectations/pull/1339
This one is particularly problematic for Thor:
https://github.com/rails/thor/pull/782/commits/3da3b44afdf2fa0bd618b87c5d862...
Vít
Dne 02. 03. 22 v 18:03 Vít Ondruch napsal(a):
Looking at Koschei failures and considering that the upstream ticket [1] is not resolved yet and there seems to be some technical difficulties as far as I understand the issue, wouldn't be better to temporary revert the PR [2]? If nothing else, I don't think it is right to have F34/F35 broken. @Mamoru WDYT?
Vít
[1] https://github.com/rspec/rspec-mocks/issues/1460
[2] https://github.com/rspec/rspec-mocks/pull/1394
Dne 07. 02. 22 v 15:26 Mamoru TASAKA napsal(a):
Mamoru TASAKA wrote on 2022/02/07 22:45:
Vít Ondruch wrote on 2022/02/07 20:24:
Dear Mamoru,
Could you please check the following two packages which recently started to fail?
https://koschei.fedoraproject.org/package/rubygem-webmock?collection=f36
https://koschei.fedoraproject.org/package/rubygem-websocket-extensions?colle...
I suspect that this is related to the RSpec update, but the errors are quite strange on the first look:
1) WebMock::RequestSignature initialization assigns normalized headers Failure/Error: @headers = WebMock::Util::Headers.normalize_headers(headers) #<WebMock::Util::Headers (class)> received :normalize_headers with unexpected arguments expected: ({"A"=>"a"}) got: ({"A"=>"a"}) # ./lib/webmock/request_signature.rb:25:in `headers=' # ./lib/webmock/request_signature.rb:49:in `assign_options' # ./lib/webmock/request_signature.rb:11:in `initialize' # ./spec/unit/request_signature_spec.rb:23:in `new' # ./spec/unit/request_signature_spec.rb:23:in `block (3 levels) in <top (required)>' # ./lib/webmock/rspec.rb:37:in `block (2 levels) in <top (required)>'I am trying to fix rubygem-yard build failure, but currently I see the same issue (on my local machine).
Looks like this is: https://github.com/rspec/rspec-mocks/issues/1460
- was brought by: https://github.com/rspec/rspec-mocks/pull/1394
expecially: https://github.com/rspec/rspec-mocks/pull/1394/files#diff-ae171e2be1f799a670...
# if both arguments end with Hashes, and if one is a keyword hash and the other is not, they don't match
So rspec upstream is saying this is correct (again keywords / hash separation...), previous rspec-mocks 3.10.2 behaved wrongly with ruby3 (rspec upstream says), and rspec-mocks user side has to fix this.
Just took a look at webmock (rubygem-webmock-3.11.1-4.fc36), so with rspec-mocks 3.10.3 the following change seems needed:
============================================================================
diff -urp webmock-3.11.1/spec.orig/unit/request_signature_spec.rb webmock-3.11.1/spec/unit/request_signature_spec.rb --- webmock-3.11.1/spec.orig/unit/request_signature_spec.rb 2022-02-07 23:13:47.262714681 +0900 +++ webmock-3.11.1/spec/unit/request_signature_spec.rb 2022-02-07 23:23:11.527273614 +0900 @@ -18,7 +18,7 @@ describe WebMock::RequestSignature do end
it "assigns normalized headers" do - expect(WebMock::Util::Headers).to receive(:normalize_headers).with('A' => 'a').and_return('B' => 'b') + expect(WebMock::Util::Headers).to receive(:normalize_headers).with({'A' => 'a'}).and_return('B' => 'b') expect( WebMock::RequestSignature.new(:get, "www.example.com", headers: {'A' => 'a'}).headers ).to eq({'B' => 'b'}) Only in webmock-3.11.1/spec/unit: request_signature_spec.rb~ diff -urp webmock-3.11.1/spec.orig/unit/response_spec.rb webmock-3.11.1/spec/unit/response_spec.rb --- webmock-3.11.1/spec.orig/unit/response_spec.rb 2022-02-07 23:13:47.262714681 +0900 +++ webmock-3.11.1/spec/unit/response_spec.rb 2022-02-07 23:23:52.502314196 +0900 @@ -31,7 +31,7 @@ describe WebMock::Response do end
it "should report normalized headers" do - expect(WebMock::Util::Headers).to receive(:normalize_headers).with('A' => 'a').and_return('B' => 'b') + expect(WebMock::Util::Headers).to receive(:normalize_headers).with({'A' => 'a'}).and_return('B' => 'b') @response = WebMock::Response.new(headers: {'A' => 'a'}) expect(@response.headers).to eq({'B' => 'b'}) end ============================================================================
Mamoru _______________________________________________ ruby-sig mailing list -- ruby-sig@lists.fedoraproject.org To unsubscribe send an email to ruby-sig-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/ruby-sig@lists.fedoraproject.o... Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Seems the saga continues with RSpec 3.12:
https://koschei.fedoraproject.org/package/rubygem-notiffany?collection=f38
https://koschei.fedoraproject.org/package/rubygem-listen?collection=f38
Vít
Dne 07. 02. 22 v 12:24 Vít Ondruch napsal(a):
Dear Mamoru,
Could you please check the following two packages which recently started to fail?
https://koschei.fedoraproject.org/package/rubygem-webmock?collection=f36
https://koschei.fedoraproject.org/package/rubygem-websocket-extensions?colle...
I suspect that this is related to the RSpec update, but the errors are quite strange on the first look:
1) WebMock::RequestSignature initialization assigns normalized headers Failure/Error: @headers = WebMock::Util::Headers.normalize_headers(headers) #<WebMock::Util::Headers (class)> received :normalize_headers with unexpected arguments expected: ({"A"=>"a"}) got: ({"A"=>"a"}) # ./lib/webmock/request_signature.rb:25:in `headers=' # ./lib/webmock/request_signature.rb:49:in `assign_options' # ./lib/webmock/request_signature.rb:11:in `initialize' # ./spec/unit/request_signature_spec.rb:23:in `new' # ./spec/unit/request_signature_spec.rb:23:in `block (3 levels) in <top (required)>' # ./lib/webmock/rspec.rb:37:in `block (2 levels) in <top (required)>'Thx a lot
Vít
P.S. Sorry for not being more helpful, I have to spent some time with CentOS Stream 9 to get Ruby into shape there, especially the problematic SystemTap support [1].
I have provided negative karma for F37 for the moment:
https://bodhi.fedoraproject.org/updates/FEDORA-2022-f7975d0e6a
However, not sure if it is not too late already, since the update was submitted for stable. Mamoru, could you please check the status and our options here?
Vít
Dne 03. 11. 22 v 13:14 Vít Ondruch napsal(a):
Seems the saga continues with RSpec 3.12:
https://koschei.fedoraproject.org/package/rubygem-notiffany?collection=f38
https://koschei.fedoraproject.org/package/rubygem-listen?collection=f38
Vít
Dne 07. 02. 22 v 12:24 Vít Ondruch napsal(a):
Dear Mamoru,
Could you please check the following two packages which recently started to fail?
https://koschei.fedoraproject.org/package/rubygem-webmock?collection=f36
https://koschei.fedoraproject.org/package/rubygem-websocket-extensions?colle...
I suspect that this is related to the RSpec update, but the errors are quite strange on the first look:
1) WebMock::RequestSignature initialization assigns normalized headers Failure/Error: @headers = WebMock::Util::Headers.normalize_headers(headers) #<WebMock::Util::Headers (class)> received :normalize_headers with unexpected arguments expected: ({"A"=>"a"}) got: ({"A"=>"a"}) # ./lib/webmock/request_signature.rb:25:in `headers=' # ./lib/webmock/request_signature.rb:49:in `assign_options' # ./lib/webmock/request_signature.rb:11:in `initialize' # ./spec/unit/request_signature_spec.rb:23:in `new' # ./spec/unit/request_signature_spec.rb:23:in `block (3 levels) in <top (required)>' # ./lib/webmock/rspec.rb:37:in `block (2 levels) in <top (required)>'Thx a lot
Vít
P.S. Sorry for not being more helpful, I have to spent some time with CentOS Stream 9 to get Ruby into shape there, especially the problematic SystemTap support [1].
Vít Ondruch wrote on 2022/11/03 21:19:
I have provided negative karma for F37 for the moment:
https://bodhi.fedoraproject.org/updates/FEDORA-2022-f7975d0e6a
However, not sure if it is not too late already, since the update was submitted for stable. Mamoru, could you please check the status and our options here?
Vít
This is: https://github.com/rspec/rspec-mocks/commit/e931e818b577172b89fb4583fc336fbc... i.e. to ”emphasize" the difference between keyword v.s. hash
I "think" the package seeing errors due to the above change need fixing anyway, however To distinguish "keywords" v.s. "hash" with ruby 3.x seems generally weigh too difficult...
As Fedora 37 is not released yet, and is going to be maintained for 13 months, I think fixing F37 packages seeing the above error is desirable (and on the other hand, I am not going to upgrade F36 rspec series to 3.12.x)
Regards, Mamoru
Dne 03. 11. 22 v 13:14 Vít Ondruch napsal(a):
Seems the saga continues with RSpec 3.12:
https://koschei.fedoraproject.org/package/rubygem-notiffany?collection=f38
https://koschei.fedoraproject.org/package/rubygem-listen?collection=f38
Vít
Dne 07. 02. 22 v 12:24 Vít Ondruch napsal(a):
Dear Mamoru,
Could you please check the following two packages which recently started to fail?
https://koschei.fedoraproject.org/package/rubygem-webmock?collection=f36
https://koschei.fedoraproject.org/package/rubygem-websocket-extensions?colle...
I suspect that this is related to the RSpec update, but the errors are quite strange on the first look:
1) WebMock::RequestSignature initialization assigns normalized headers Failure/Error: @headers = WebMock::Util::Headers.normalize_headers(headers) #<WebMock::Util::Headers (class)> received :normalize_headers with unexpected arguments expected: ({"A"=>"a"}) got: ({"A"=>"a"}) # ./lib/webmock/request_signature.rb:25:in `headers=' # ./lib/webmock/request_signature.rb:49:in `assign_options' # ./lib/webmock/request_signature.rb:11:in `initialize' # ./spec/unit/request_signature_spec.rb:23:in `new' # ./spec/unit/request_signature_spec.rb:23:in `block (3 levels) in <top (required)>' # ./lib/webmock/rspec.rb:37:in `block (2 levels) in <top (required)>'Thx a lot
Vít
P.S. Sorry for not being more helpful, I have to spent some time with CentOS Stream 9 to get Ruby into shape there, especially the problematic SystemTap support [1].
ruby-sig mailing list -- ruby-sig@lists.fedoraproject.org To unsubscribe send an email to ruby-sig-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/ruby-sig@lists.fedoraproject.o... Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Dne 03. 11. 22 v 14:07 Mamoru TASAKA napsal(a):
Vít Ondruch wrote on 2022/11/03 21:19:
I have provided negative karma for F37 for the moment:
https://bodhi.fedoraproject.org/updates/FEDORA-2022-f7975d0e6a
However, not sure if it is not too late already, since the update was submitted for stable. Mamoru, could you please check the status and our options here?
Vít
This is: https://github.com/rspec/rspec-mocks/commit/e931e818b577172b89fb4583fc336fbc...
i.e. to ”emphasize" the difference between keyword v.s. hash
Thx for pointing out the exact commit.
I "think" the package seeing errors due to the above change need fixing anyway,
No doubt about it, the only question is when :)
however To distinguish "keywords" v.s. "hash" with ruby 3.x seems generally weigh too difficult...
As Fedora 37 is not released yet, and is going to be maintained for 13 months, I think fixing F37 packages seeing the above error is desirable
In this case, can we postpone landing the F37 update and include fixes for the affected packages into the update?
(I wish the notifications were not delayed by one week, but hopefully, the FMN is going to be fixed soon).
(and on the other hand, I am not going to upgrade F36 rspec series to 3.12.x)
I support that, thx.
Vít
Regards, Mamoru
Dne 03. 11. 22 v 13:14 Vít Ondruch napsal(a):
Seems the saga continues with RSpec 3.12:
https://koschei.fedoraproject.org/package/rubygem-notiffany?collection=f38
https://koschei.fedoraproject.org/package/rubygem-listen?collection=f38
Vít
Dne 07. 02. 22 v 12:24 Vít Ondruch napsal(a):
Dear Mamoru,
Could you please check the following two packages which recently started to fail?
https://koschei.fedoraproject.org/package/rubygem-webmock?collection=f36
https://koschei.fedoraproject.org/package/rubygem-websocket-extensions?colle...
I suspect that this is related to the RSpec update, but the errors are quite strange on the first look:
1) WebMock::RequestSignature initialization assigns normalized headers Failure/Error: @headers = WebMock::Util::Headers.normalize_headers(headers) #<WebMock::Util::Headers (class)> received :normalize_headers with unexpected arguments expected: ({"A"=>"a"}) got: ({"A"=>"a"}) # ./lib/webmock/request_signature.rb:25:in `headers=' # ./lib/webmock/request_signature.rb:49:in `assign_options' # ./lib/webmock/request_signature.rb:11:in `initialize' # ./spec/unit/request_signature_spec.rb:23:in `new' # ./spec/unit/request_signature_spec.rb:23:in `block (3 levels) in <top (required)>' # ./lib/webmock/rspec.rb:37:in `block (2 levels) in <top (required)>'Thx a lot
Vít
P.S. Sorry for not being more helpful, I have to spent some time with CentOS Stream 9 to get Ruby into shape there, especially the problematic SystemTap support [1].
ruby-sig mailing list -- ruby-sig@lists.fedoraproject.org To unsubscribe send an email to ruby-sig-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/ruby-sig@lists.fedoraproject.o... Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
ruby-sig mailing list -- ruby-sig@lists.fedoraproject.org To unsubscribe send an email to ruby-sig-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/ruby-sig@lists.fedoraproject.o... Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Dne 03. 11. 22 v 14:22 Vít Ondruch napsal(a):
Dne 03. 11. 22 v 14:07 Mamoru TASAKA napsal(a):
Vít Ondruch wrote on 2022/11/03 21:19:
I have provided negative karma for F37 for the moment:
https://bodhi.fedoraproject.org/updates/FEDORA-2022-f7975d0e6a
However, not sure if it is not too late already, since the update was submitted for stable. Mamoru, could you please check the status and our options here?
Vít
This is: https://github.com/rspec/rspec-mocks/commit/e931e818b577172b89fb4583fc336fbc...
i.e. to ”emphasize" the difference between keyword v.s. hash
Thx for pointing out the exact commit.
I "think" the package seeing errors due to the above change need fixing anyway,
No doubt about it, the only question is when :)
however To distinguish "keywords" v.s. "hash" with ruby 3.x seems generally weigh too difficult...
Just checking the rubygem-notiffany, there was already fix applied:
https://src.fedoraproject.org/rpms/rubygem-notiffany/c/dfda0c228c7ca4f00472f...
Which just confirms this is difficult issue ...
Vít
As Fedora 37 is not released yet, and is going to be maintained for 13 months, I think fixing F37 packages seeing the above error is desirable
In this case, can we postpone landing the F37 update and include fixes for the affected packages into the update?
(I wish the notifications were not delayed by one week, but hopefully, the FMN is going to be fixed soon).
(and on the other hand, I am not going to upgrade F36 rspec series to 3.12.x)
I support that, thx.
Vít
Regards, Mamoru
Dne 03. 11. 22 v 13:14 Vít Ondruch napsal(a):
Seems the saga continues with RSpec 3.12:
https://koschei.fedoraproject.org/package/rubygem-notiffany?collection=f38
https://koschei.fedoraproject.org/package/rubygem-listen?collection=f38
Vít
Dne 07. 02. 22 v 12:24 Vít Ondruch napsal(a):
Dear Mamoru,
Could you please check the following two packages which recently started to fail?
https://koschei.fedoraproject.org/package/rubygem-webmock?collection=f36
https://koschei.fedoraproject.org/package/rubygem-websocket-extensions?colle...
I suspect that this is related to the RSpec update, but the errors are quite strange on the first look:
1) WebMock::RequestSignature initialization assigns normalized headers Failure/Error: @headers = WebMock::Util::Headers.normalize_headers(headers) #<WebMock::Util::Headers (class)> received :normalize_headers with unexpected arguments expected: ({"A"=>"a"}) got: ({"A"=>"a"}) # ./lib/webmock/request_signature.rb:25:in `headers=' # ./lib/webmock/request_signature.rb:49:in `assign_options' # ./lib/webmock/request_signature.rb:11:in `initialize' # ./spec/unit/request_signature_spec.rb:23:in `new' # ./spec/unit/request_signature_spec.rb:23:in `block (3 levels) in <top (required)>' # ./lib/webmock/rspec.rb:37:in `block (2 levels) in <top (required)>'Thx a lot
Vít
P.S. Sorry for not being more helpful, I have to spent some time with CentOS Stream 9 to get Ruby into shape there, especially the problematic SystemTap support [1].
ruby-sig mailing list -- ruby-sig@lists.fedoraproject.org To unsubscribe send an email to ruby-sig-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/ruby-sig@lists.fedoraproject.o... Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
ruby-sig mailing list -- ruby-sig@lists.fedoraproject.org To unsubscribe send an email to ruby-sig-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/ruby-sig@lists.fedoraproject.o... Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Vít Ondruch wrote on 2022/11/03 22:22:
Dne 03. 11. 22 v 14:07 Mamoru TASAKA napsal(a):
Vít Ondruch wrote on 2022/11/03 21:19:
I have provided negative karma for F37 for the moment:
https://bodhi.fedoraproject.org/updates/FEDORA-2022-f7975d0e6a
However, not sure if it is not too late already, since the update was submitted for stable. Mamoru, could you please check the status and our options here?
Vít
This is: https://github.com/rspec/rspec-mocks/commit/e931e818b577172b89fb4583fc336fbc... i.e. to ”emphasize" the difference between keyword v.s. hash
Thx for pointing out the exact commit.
I "think" the package seeing errors due to the above change need fixing anyway,
No doubt about it, the only question is when :)
however To distinguish "keywords" v.s. "hash" with ruby 3.x seems generally weigh too difficult...
As Fedora 37 is not released yet, and is going to be maintained for 13 months, I think fixing F37 packages seeing the above error is desirable
In this case, can we postpone landing the F37 update and include fixes for the affected packages into the update?
(I wish the notifications were not delayed by one week, but hopefully, the FMN is going to be fixed soon).
(and on the other hand, I am not going to upgrade F36 rspec series to 3.12.x)
I support that, thx.
Vít
Well, the simplest solution for now is to revert the above change on F-37.
Mamoru
Regards, Mamoru
Dne 03. 11. 22 v 13:14 Vít Ondruch napsal(a):
Seems the saga continues with RSpec 3.12:
https://koschei.fedoraproject.org/package/rubygem-notiffany?collection=f38
https://koschei.fedoraproject.org/package/rubygem-listen?collection=f38
Vít
Dne 07. 02. 22 v 12:24 Vít Ondruch napsal(a):
Dear Mamoru,
Could you please check the following two packages which recently started to fail?
https://koschei.fedoraproject.org/package/rubygem-webmock?collection=f36
https://koschei.fedoraproject.org/package/rubygem-websocket-extensions?colle...
I suspect that this is related to the RSpec update, but the errors are quite strange on the first look:
1) WebMock::RequestSignature initialization assigns normalized headers Failure/Error: @headers = WebMock::Util::Headers.normalize_headers(headers) #<WebMock::Util::Headers (class)> received :normalize_headers with unexpected arguments expected: ({"A"=>"a"}) got: ({"A"=>"a"}) # ./lib/webmock/request_signature.rb:25:in `headers=' # ./lib/webmock/request_signature.rb:49:in `assign_options' # ./lib/webmock/request_signature.rb:11:in `initialize' # ./spec/unit/request_signature_spec.rb:23:in `new' # ./spec/unit/request_signature_spec.rb:23:in `block (3 levels) in <top (required)>' # ./lib/webmock/rspec.rb:37:in `block (2 levels) in <top (required)>'Thx a lot
Vít
P.S. Sorry for not being more helpful, I have to spent some time with CentOS Stream 9 to get Ruby into shape there, especially the problematic SystemTap support [1].
ruby-sig mailing list -- ruby-sig@lists.fedoraproject.org To unsubscribe send an email to ruby-sig-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/ruby-sig@lists.fedoraproject.o... Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
ruby-sig mailing list -- ruby-sig@lists.fedoraproject.org To unsubscribe send an email to ruby-sig-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/ruby-sig@lists.fedoraproject.o... Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
ruby-sig mailing list -- ruby-sig@lists.fedoraproject.org To unsubscribe send an email to ruby-sig-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/ruby-sig@lists.fedoraproject.o... Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Dne 03. 11. 22 v 15:37 Mamoru TASAKA napsal(a):
Vít Ondruch wrote on 2022/11/03 22:22:
Dne 03. 11. 22 v 14:07 Mamoru TASAKA napsal(a):
Vít Ondruch wrote on 2022/11/03 21:19:
I have provided negative karma for F37 for the moment:
https://bodhi.fedoraproject.org/updates/FEDORA-2022-f7975d0e6a
However, not sure if it is not too late already, since the update was submitted for stable. Mamoru, could you please check the status and our options here?
Vít
This is: https://github.com/rspec/rspec-mocks/commit/e931e818b577172b89fb4583fc336fbc...
i.e. to ”emphasize" the difference between keyword v.s. hash
Thx for pointing out the exact commit.
I "think" the package seeing errors due to the above change need fixing anyway,
No doubt about it, the only question is when :)
however To distinguish "keywords" v.s. "hash" with ruby 3.x seems generally weigh too difficult...
As Fedora 37 is not released yet, and is going to be maintained for 13 months, I think fixing F37 packages seeing the above error is desirable
In this case, can we postpone landing the F37 update and include fixes for the affected packages into the update?
(I wish the notifications were not delayed by one week, but hopefully, the FMN is going to be fixed soon).
(and on the other hand, I am not going to upgrade F36 rspec series to 3.12.x)
I support that, thx.
Vít
Well, the simplest solution for now is to revert the above change on F-37.
You mean the rspec-mocks commit? That is interesting idea.
In the man time, I have fixed rubygem-notiffany, but there seems to be several more:
https://koschei.fedoraproject.org/search?q=ruby&order_by=state-f38%2Crun...
rubygem-listen
rubygem-guard
rubygem-guard-livereload
rubygem-memfs
And that actually might be it. I'll try to take look at listen.
Vít
Vít Ondruch wrote on 2022/11/04 0:37:
Dne 03. 11. 22 v 15:37 Mamoru TASAKA napsal(a):
Vít Ondruch wrote on 2022/11/03 22:22:
Dne 03. 11. 22 v 14:07 Mamoru TASAKA napsal(a):
Vít Ondruch wrote on 2022/11/03 21:19:
I have provided negative karma for F37 for the moment:
https://bodhi.fedoraproject.org/updates/FEDORA-2022-f7975d0e6a
However, not sure if it is not too late already, since the update was submitted for stable. Mamoru, could you please check the status and our options here?
Vít
This is: https://github.com/rspec/rspec-mocks/commit/e931e818b577172b89fb4583fc336fbc... i.e. to ”emphasize" the difference between keyword v.s. hash
Thx for pointing out the exact commit.
I "think" the package seeing errors due to the above change need fixing anyway,
No doubt about it, the only question is when :)
however To distinguish "keywords" v.s. "hash" with ruby 3.x seems generally weigh too difficult...
As Fedora 37 is not released yet, and is going to be maintained for 13 months, I think fixing F37 packages seeing the above error is desirable
In this case, can we postpone landing the F37 update and include fixes for the affected packages into the update?
(I wish the notifications were not delayed by one week, but hopefully, the FMN is going to be fixed soon).
(and on the other hand, I am not going to upgrade F36 rspec series to 3.12.x)
I support that, thx.
Vít
Well, the simplest solution for now is to revert the above change on F-37.
You mean the rspec-mocks commit? That is interesting idea.
Yes, I mean that (i.e. revert e931e818b577172b89fb4583fc336fbcd25df36b on Fedora 37 rubygem-rspec-mocks rpm). Koschei should report errors on rawhide (for rspec consumer rpms) anyway.
Mamoru
In the man time, I have fixed rubygem-notiffany, but there seems to be several more:
https://koschei.fedoraproject.org/search?q=ruby&order_by=state-f38%2Crun...
rubygem-listen
rubygem-guard
rubygem-guard-livereload
rubygem-memfs
And that actually might be it. I'll try to take look at listen.
Vít
ruby-sig mailing list -- ruby-sig@lists.fedoraproject.org To unsubscribe send an email to ruby-sig-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/ruby-sig@lists.fedoraproject.o... Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Dne 03. 11. 22 v 17:13 Mamoru TASAKA napsal(a):
Vít Ondruch wrote on 2022/11/04 0:37:
Dne 03. 11. 22 v 15:37 Mamoru TASAKA napsal(a):
Vít Ondruch wrote on 2022/11/03 22:22:
Dne 03. 11. 22 v 14:07 Mamoru TASAKA napsal(a):
Vít Ondruch wrote on 2022/11/03 21:19:
I have provided negative karma for F37 for the moment:
https://bodhi.fedoraproject.org/updates/FEDORA-2022-f7975d0e6a
However, not sure if it is not too late already, since the update was submitted for stable. Mamoru, could you please check the status and our options here?
Vít
This is: https://github.com/rspec/rspec-mocks/commit/e931e818b577172b89fb4583fc336fbc...
i.e. to ”emphasize" the difference between keyword v.s. hash
Thx for pointing out the exact commit.
I "think" the package seeing errors due to the above change need fixing anyway,
No doubt about it, the only question is when :)
however To distinguish "keywords" v.s. "hash" with ruby 3.x seems generally weigh too difficult...
As Fedora 37 is not released yet, and is going to be maintained for 13 months, I think fixing F37 packages seeing the above error is desirable
In this case, can we postpone landing the F37 update and include fixes for the affected packages into the update?
(I wish the notifications were not delayed by one week, but hopefully, the FMN is going to be fixed soon).
(and on the other hand, I am not going to upgrade F36 rspec series to 3.12.x)
I support that, thx.
Vít
Well, the simplest solution for now is to revert the above change on F-37.
You mean the rspec-mocks commit? That is interesting idea.
Yes, I mean that (i.e. revert e931e818b577172b89fb4583fc336fbcd25df36b on Fedora 37 rubygem-rspec-mocks rpm). Koschei should report errors on rawhide (for rspec consumer rpms) anyway.
Sounds good to me. We can re-enable this once we catch all the issues in Rawhide and patches are ready.
Thx
Vít
Mamoru
In the man time, I have fixed rubygem-notiffany, but there seems to be several more:
https://koschei.fedoraproject.org/search?q=ruby&order_by=state-f38%2Crun...
rubygem-listen
rubygem-guard
rubygem-guard-livereload
rubygem-memfs
And that actually might be it. I'll try to take look at listen.
Vít
ruby-sig mailing list -- ruby-sig@lists.fedoraproject.org To unsubscribe send an email to ruby-sig-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/ruby-sig@lists.fedoraproject.o... Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
ruby-sig mailing list -- ruby-sig@lists.fedoraproject.org To unsubscribe send an email to ruby-sig-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/ruby-sig@lists.fedoraproject.o... Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Vít Ondruch wrote on 2022/11/04 1:39:
Dne 03. 11. 22 v 17:13 Mamoru TASAKA napsal(a):
Vít Ondruch wrote on 2022/11/04 0:37:
Dne 03. 11. 22 v 15:37 Mamoru TASAKA napsal(a):
Vít Ondruch wrote on 2022/11/03 22:22:
Dne 03. 11. 22 v 14:07 Mamoru TASAKA napsal(a):
Vít Ondruch wrote on 2022/11/03 21:19: > I have provided negative karma for F37 for the moment: > > https://bodhi.fedoraproject.org/updates/FEDORA-2022-f7975d0e6a > > > However, not sure if it is not too late already, since the update was submitted for stable. Mamoru, could you please check the status and our options here? > > > Vít
This is: https://github.com/rspec/rspec-mocks/commit/e931e818b577172b89fb4583fc336fbc... i.e. to ”emphasize" the difference between keyword v.s. hash
Thx for pointing out the exact commit.
I "think" the package seeing errors due to the above change need fixing anyway,
No doubt about it, the only question is when :)
however To distinguish "keywords" v.s. "hash" with ruby 3.x seems generally weigh too difficult...
As Fedora 37 is not released yet, and is going to be maintained for 13 months, I think fixing F37 packages seeing the above error is desirable
In this case, can we postpone landing the F37 update and include fixes for the affected packages into the update?
(I wish the notifications were not delayed by one week, but hopefully, the FMN is going to be fixed soon).
(and on the other hand, I am not going to upgrade F36 rspec series to 3.12.x)
I support that, thx.
Vít
Well, the simplest solution for now is to revert the above change on F-37.
You mean the rspec-mocks commit? That is interesting idea.
Yes, I mean that (i.e. revert e931e818b577172b89fb4583fc336fbcd25df36b on Fedora 37 rubygem-rspec-mocks rpm). Koschei should report errors on rawhide (for rspec consumer rpms) anyway.
Sounds good to me. We can re-enable this once we catch all the issues in Rawhide and patches are ready.
Thx
Vít
Okay, will revert on F-37 in rubygem-rspec-mocks-3.12.0-2.fc37 (on rawhide, the above e931e818b577172b89fb4583fc336fbcd25df36b change is still effective)
Mamoru
Mamoru
In the man time, I have fixed rubygem-notiffany, but there seems to be several more:
https://koschei.fedoraproject.org/search?q=ruby&order_by=state-f38%2Crun...
rubygem-listen
rubygem-guard
rubygem-guard-livereload
rubygem-memfs
And that actually might be it. I'll try to take look at listen.
Vít
ruby-sig mailing list -- ruby-sig@lists.fedoraproject.org To unsubscribe send an email to ruby-sig-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/ruby-sig@lists.fedoraproject.o... Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
ruby-sig mailing list -- ruby-sig@lists.fedoraproject.org To unsubscribe send an email to ruby-sig-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/ruby-sig@lists.fedoraproject.o... Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
ruby-sig mailing list -- ruby-sig@lists.fedoraproject.org To unsubscribe send an email to ruby-sig-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/ruby-sig@lists.fedoraproject.o... Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Dne 03. 11. 22 v 16:37 Vít Ondruch napsal(a):
Dne 03. 11. 22 v 15:37 Mamoru TASAKA napsal(a):
Vít Ondruch wrote on 2022/11/03 22:22:
Dne 03. 11. 22 v 14:07 Mamoru TASAKA napsal(a):
Vít Ondruch wrote on 2022/11/03 21:19:
I have provided negative karma for F37 for the moment:
https://bodhi.fedoraproject.org/updates/FEDORA-2022-f7975d0e6a
However, not sure if it is not too late already, since the update was submitted for stable. Mamoru, could you please check the status and our options here?
Vít
This is: https://github.com/rspec/rspec-mocks/commit/e931e818b577172b89fb4583fc336fbc...
i.e. to ”emphasize" the difference between keyword v.s. hash
Thx for pointing out the exact commit.
I "think" the package seeing errors due to the above change need fixing anyway,
No doubt about it, the only question is when :)
however To distinguish "keywords" v.s. "hash" with ruby 3.x seems generally weigh too difficult...
As Fedora 37 is not released yet, and is going to be maintained for 13 months, I think fixing F37 packages seeing the above error is desirable
In this case, can we postpone landing the F37 update and include fixes for the affected packages into the update?
(I wish the notifications were not delayed by one week, but hopefully, the FMN is going to be fixed soon).
(and on the other hand, I am not going to upgrade F36 rspec series to 3.12.x)
I support that, thx.
Vít
Well, the simplest solution for now is to revert the above change on F-37.
You mean the rspec-mocks commit? That is interesting idea.
In the man time, I have fixed rubygem-notiffany, but there seems to be several more:
https://koschei.fedoraproject.org/search?q=ruby&order_by=state-f38%2Crun...
rubygem-listen
This ^^ should be also good to go:
https://github.com/guard/listen/pull/564
Vít
rubygem-guard
rubygem-guard-livereload
rubygem-memfs
And that actually might be it. I'll try to take look at listen.
Vít
Dne 03. 11. 22 v 16:37 Vít Ondruch napsal(a):
Dne 03. 11. 22 v 15:37 Mamoru TASAKA napsal(a):
Vít Ondruch wrote on 2022/11/03 22:22:
Dne 03. 11. 22 v 14:07 Mamoru TASAKA napsal(a):
Vít Ondruch wrote on 2022/11/03 21:19:
I have provided negative karma for F37 for the moment:
https://bodhi.fedoraproject.org/updates/FEDORA-2022-f7975d0e6a
However, not sure if it is not too late already, since the update was submitted for stable. Mamoru, could you please check the status and our options here?
Vít
This is: https://github.com/rspec/rspec-mocks/commit/e931e818b577172b89fb4583fc336fbc...
i.e. to ”emphasize" the difference between keyword v.s. hash
Thx for pointing out the exact commit.
I "think" the package seeing errors due to the above change need fixing anyway,
No doubt about it, the only question is when :)
however To distinguish "keywords" v.s. "hash" with ruby 3.x seems generally weigh too difficult...
As Fedora 37 is not released yet, and is going to be maintained for 13 months, I think fixing F37 packages seeing the above error is desirable
In this case, can we postpone landing the F37 update and include fixes for the affected packages into the update?
(I wish the notifications were not delayed by one week, but hopefully, the FMN is going to be fixed soon).
(and on the other hand, I am not going to upgrade F36 rspec series to 3.12.x)
I support that, thx.
Vít
Well, the simplest solution for now is to revert the above change on F-37.
You mean the rspec-mocks commit? That is interesting idea.
In the man time, I have fixed rubygem-notiffany, but there seems to be several more:
https://koschei.fedoraproject.org/search?q=ruby&order_by=state-f38%2Crun...
rubygem-listen
rubygem-guard
This one ^^ won't be easy. The test failure comes from here:
https://github.com/guard/guard/blob/4f5f763d05c113dc607ea39a909ec401441b340d...
However, it is not clear to me what defines COLUMNS env variable. It very likely something related to RSpec but somthing different then kwargs. When I applied medicine similar to
https://src.fedoraproject.org/rpms/rubygem-guard/blob/rawhide/f/rubygem-guar...
I got past this issue, but with 46 failures due to kwargs. However, the recent code is heavily modified by this patch:
https://github.com/guard/guard/commit/cc8d97a27c824e58aa9251c9feca306b29d018...
which seems to touch every file. So it seems it would be reasonable to rebase prior even trying to fix the failures.
Vít
rubygem-guard-livereload
rubygem-memfs
And that actually might be it. I'll try to take look at listen.
Vít
Dne 04. 11. 22 v 13:24 Vít Ondruch napsal(a):
Dne 03. 11. 22 v 16:37 Vít Ondruch napsal(a):
Dne 03. 11. 22 v 15:37 Mamoru TASAKA napsal(a):
Vít Ondruch wrote on 2022/11/03 22:22:
Dne 03. 11. 22 v 14:07 Mamoru TASAKA napsal(a):
Vít Ondruch wrote on 2022/11/03 21:19:
I have provided negative karma for F37 for the moment:
https://bodhi.fedoraproject.org/updates/FEDORA-2022-f7975d0e6a
However, not sure if it is not too late already, since the update was submitted for stable. Mamoru, could you please check the status and our options here?
Vít
This is: https://github.com/rspec/rspec-mocks/commit/e931e818b577172b89fb4583fc336fbc...
i.e. to ”emphasize" the difference between keyword v.s. hash
Thx for pointing out the exact commit.
I "think" the package seeing errors due to the above change need fixing anyway,
No doubt about it, the only question is when :)
however To distinguish "keywords" v.s. "hash" with ruby 3.x seems generally weigh too difficult...
As Fedora 37 is not released yet, and is going to be maintained for 13 months, I think fixing F37 packages seeing the above error is desirable
In this case, can we postpone landing the F37 update and include fixes for the affected packages into the update?
(I wish the notifications were not delayed by one week, but hopefully, the FMN is going to be fixed soon).
(and on the other hand, I am not going to upgrade F36 rspec series to 3.12.x)
I support that, thx.
Vít
Well, the simplest solution for now is to revert the above change on F-37.
You mean the rspec-mocks commit? That is interesting idea.
In the man time, I have fixed rubygem-notiffany, but there seems to be several more:
https://koschei.fedoraproject.org/search?q=ruby&order_by=state-f38%2Crun...
rubygem-listen
rubygem-guard
This one ^^ won't be easy. The test failure comes from here:
https://github.com/guard/guard/blob/4f5f763d05c113dc607ea39a909ec401441b340d...
However, it is not clear to me what defines COLUMNS env variable.
This is part of the backtrace from where the `abort` is called:
~~~
/usr/share/gems/gems/rspec-mocks-3.12.0/lib/rspec/mocks/message_expectation.rb:761:in `block in call' /usr/share/gems/gems/rspec-mocks-3.12.0/lib/rspec/mocks/message_expectation.rb:760:in `map' /usr/share/gems/gems/rspec-mocks-3.12.0/lib/rspec/mocks/message_expectation.rb:760:in `call' /usr/share/gems/gems/rspec-mocks-3.12.0/lib/rspec/mocks/message_expectation.rb:621:in `invoke_incrementing_actual_calls_by' /usr/share/gems/gems/rspec-mocks-3.12.0/lib/rspec/mocks/message_expectation.rb:474:in `invoke' /usr/share/gems/gems/rspec-mocks-3.12.0/lib/rspec/mocks/proxy.rb:214:in `message_received' /usr/share/gems/gems/rspec-mocks-3.12.0/lib/rspec/mocks/proxy.rb:366:in `message_received' /usr/share/gems/gems/rspec-mocks-3.12.0/lib/rspec/mocks/method_double.rb:80:in `proxy_method_invoked' /usr/share/gems/gems/rspec-mocks-3.12.0/lib/rspec/mocks/verifying_proxy.rb:161:in `proxy_method_invoked' /usr/share/gems/gems/rspec-mocks-3.12.0/lib/rspec/mocks/method_double.rb:64:in `block (2 levels) in define_proxy_method' /usr/share/ruby/pp.rb:80:in `width_for' /usr/share/ruby/pp.rb:91:in `pp' /usr/share/gems/gems/rspec-support-3.12.0/lib/rspec/support/differ.rb:184:in `object_to_string' /usr/share/gems/gems/rspec-support-3.12.0/lib/rspec/support/differ.rb:58:in `diff_as_object' /usr/share/gems/gems/rspec-support-3.12.0/lib/rspec/support/differ.rb:20:in `diff' /usr/share/gems/gems/rspec-mocks-3.12.0/lib/rspec/mocks/error_generator.rb:299:in `diff_message' /usr/share/gems/gems/rspec-mocks-3.12.0/lib/rspec/mocks/error_generator.rb:285:in `error_message' /usr/share/gems/gems/rspec-mocks-3.12.0/lib/rspec/mocks/error_generator.rb:68:in `raise_similar_message_args_error' /usr/share/gems/gems/rspec-mocks-3.12.0/lib/rspec/mocks/message_expectation.rb:548:in `generate_error' /usr/share/gems/gems/rspec-mocks-3.12.0/lib/rspec/mocks/message_expectation.rb:500:in `verify_messages_received' /usr/share/gems/gems/rspec-mocks-3.12.0/lib/rspec/mocks/method_double.rb:117:in `block in verify' /usr/share/gems/gems/rspec-mocks-3.12.0/lib/rspec/mocks/method_double.rb:117:in `each' /usr/share/gems/gems/rspec-mocks-3.12.0/lib/rspec/mocks/method_double.rb:117:in `verify' /usr/share/gems/gems/rspec-mocks-3.12.0/lib/rspec/mocks/proxy.rb:165:in `block in verify' /usr/share/gems/gems/rspec-mocks-3.12.0/lib/rspec/mocks/proxy.rb:165:in `each_value' /usr/share/gems/gems/rspec-mocks-3.12.0/lib/rspec/mocks/proxy.rb:165:in `verify' /usr/share/gems/gems/rspec-mocks-3.12.0/lib/rspec/mocks/space.rb:74:in `block in verify_all' /usr/share/gems/gems/rspec-mocks-3.12.0/lib/rspec/mocks/space.rb:74:in `each' /usr/share/gems/gems/rspec-mocks-3.12.0/lib/rspec/mocks/space.rb:74:in `verify_all' /usr/share/gems/gems/rspec-mocks-3.12.0/lib/rspec/mocks.rb:45:in `verify' /usr/share/gems/gems/rspec-core-3.12.0/lib/rspec/core/mocking_adapters/rspec.rb:23:in `verify_mocks_for_rspec'
... snip ...
~~~
End this is the check for COLUMNS env variable:
https://github.com/ruby/ruby/blob/13395757fa7fe0abee3a260d5669baec2dc2e0fc/l...
If there are not issues, then this is probably not executed.
It very likely something related to RSpec but somthing different then kwargs.
It is kwargs after all:
https://github.com/rspec/rspec-mocks/pull/1464
But I am probably not able to untangle this.
When I applied medicine similar to
https://src.fedoraproject.org/rpms/rubygem-guard/blob/rawhide/f/rubygem-guar...
I got past this issue, but with 46 failures due to kwargs. However, the recent code is heavily modified by this patch:
https://github.com/guard/guard/commit/cc8d97a27c824e58aa9251c9feca306b29d018...
And this patch has not landed yet 🤦🏻♂️
Vít
which seems to touch every file. So it seems it would be reasonable to rebase prior even trying to fix the failures.
Vít
rubygem-guard-livereload
rubygem-memfs
And that actually might be it. I'll try to take look at listen.
Vít
Dne 04. 11. 22 v 18:34 Vít Ondruch napsal(a):
Dne 04. 11. 22 v 13:24 Vít Ondruch napsal(a):
Dne 03. 11. 22 v 16:37 Vít Ondruch napsal(a):
Dne 03. 11. 22 v 15:37 Mamoru TASAKA napsal(a):
Vít Ondruch wrote on 2022/11/03 22:22:
Dne 03. 11. 22 v 14:07 Mamoru TASAKA napsal(a):
Vít Ondruch wrote on 2022/11/03 21:19: > I have provided negative karma for F37 for the moment: > > https://bodhi.fedoraproject.org/updates/FEDORA-2022-f7975d0e6a > > > However, not sure if it is not too late already, since the > update was submitted for stable. Mamoru, could you please check > the status and our options here? > > > Vít
This is: https://github.com/rspec/rspec-mocks/commit/e931e818b577172b89fb4583fc336fbc...
i.e. to ”emphasize" the difference between keyword v.s. hash
Thx for pointing out the exact commit.
I "think" the package seeing errors due to the above change need fixing anyway,
No doubt about it, the only question is when :)
however To distinguish "keywords" v.s. "hash" with ruby 3.x seems generally weigh too difficult...
As Fedora 37 is not released yet, and is going to be maintained for 13 months, I think fixing F37 packages seeing the above error is desirable
In this case, can we postpone landing the F37 update and include fixes for the affected packages into the update?
(I wish the notifications were not delayed by one week, but hopefully, the FMN is going to be fixed soon).
(and on the other hand, I am not going to upgrade F36 rspec series to 3.12.x)
I support that, thx.
Vít
Well, the simplest solution for now is to revert the above change on F-37.
You mean the rspec-mocks commit? That is interesting idea.
In the man time, I have fixed rubygem-notiffany, but there seems to be several more:
https://koschei.fedoraproject.org/search?q=ruby&order_by=state-f38%2Crun...
rubygem-listen
rubygem-guard
This one ^^ won't be easy. The test failure comes from here:
https://github.com/guard/guard/blob/4f5f763d05c113dc607ea39a909ec401441b340d...
However, it is not clear to me what defines COLUMNS env variable.
This is part of the backtrace from where the `abort` is called:
/usr/share/gems/gems/rspec-mocks-3.12.0/lib/rspec/mocks/message_expectation.rb:761:in `block in call' /usr/share/gems/gems/rspec-mocks-3.12.0/lib/rspec/mocks/message_expectation.rb:760:in `map' /usr/share/gems/gems/rspec-mocks-3.12.0/lib/rspec/mocks/message_expectation.rb:760:in `call' /usr/share/gems/gems/rspec-mocks-3.12.0/lib/rspec/mocks/message_expectation.rb:621:in `invoke_incrementing_actual_calls_by' /usr/share/gems/gems/rspec-mocks-3.12.0/lib/rspec/mocks/message_expectation.rb:474:in `invoke' /usr/share/gems/gems/rspec-mocks-3.12.0/lib/rspec/mocks/proxy.rb:214:in `message_received' /usr/share/gems/gems/rspec-mocks-3.12.0/lib/rspec/mocks/proxy.rb:366:in `message_received' /usr/share/gems/gems/rspec-mocks-3.12.0/lib/rspec/mocks/method_double.rb:80:in `proxy_method_invoked' /usr/share/gems/gems/rspec-mocks-3.12.0/lib/rspec/mocks/verifying_proxy.rb:161:in `proxy_method_invoked' /usr/share/gems/gems/rspec-mocks-3.12.0/lib/rspec/mocks/method_double.rb:64:in `block (2 levels) in define_proxy_method' /usr/share/ruby/pp.rb:80:in `width_for' /usr/share/ruby/pp.rb:91:in `pp' /usr/share/gems/gems/rspec-support-3.12.0/lib/rspec/support/differ.rb:184:in `object_to_string' /usr/share/gems/gems/rspec-support-3.12.0/lib/rspec/support/differ.rb:58:in `diff_as_object' /usr/share/gems/gems/rspec-support-3.12.0/lib/rspec/support/differ.rb:20:in `diff' /usr/share/gems/gems/rspec-mocks-3.12.0/lib/rspec/mocks/error_generator.rb:299:in `diff_message' /usr/share/gems/gems/rspec-mocks-3.12.0/lib/rspec/mocks/error_generator.rb:285:in `error_message' /usr/share/gems/gems/rspec-mocks-3.12.0/lib/rspec/mocks/error_generator.rb:68:in `raise_similar_message_args_error' /usr/share/gems/gems/rspec-mocks-3.12.0/lib/rspec/mocks/message_expectation.rb:548:in `generate_error' /usr/share/gems/gems/rspec-mocks-3.12.0/lib/rspec/mocks/message_expectation.rb:500:in `verify_messages_received' /usr/share/gems/gems/rspec-mocks-3.12.0/lib/rspec/mocks/method_double.rb:117:in `block in verify' /usr/share/gems/gems/rspec-mocks-3.12.0/lib/rspec/mocks/method_double.rb:117:in `each' /usr/share/gems/gems/rspec-mocks-3.12.0/lib/rspec/mocks/method_double.rb:117:in `verify' /usr/share/gems/gems/rspec-mocks-3.12.0/lib/rspec/mocks/proxy.rb:165:in `block in verify' /usr/share/gems/gems/rspec-mocks-3.12.0/lib/rspec/mocks/proxy.rb:165:in `each_value' /usr/share/gems/gems/rspec-mocks-3.12.0/lib/rspec/mocks/proxy.rb:165:in `verify' /usr/share/gems/gems/rspec-mocks-3.12.0/lib/rspec/mocks/space.rb:74:in `block in verify_all' /usr/share/gems/gems/rspec-mocks-3.12.0/lib/rspec/mocks/space.rb:74:in `each' /usr/share/gems/gems/rspec-mocks-3.12.0/lib/rspec/mocks/space.rb:74:in `verify_all' /usr/share/gems/gems/rspec-mocks-3.12.0/lib/rspec/mocks.rb:45:in `verify' /usr/share/gems/gems/rspec-core-3.12.0/lib/rspec/core/mocking_adapters/rspec.rb:23:in `verify_mocks_for_rspec' ... snip ...End this is the check for COLUMNS env variable:
https://github.com/ruby/ruby/blob/13395757fa7fe0abee3a260d5669baec2dc2e0fc/l...
If there are not issues, then this is probably not executed.
It very likely something related to RSpec but somthing different then kwargs.
It is kwargs after all:
https://github.com/rspec/rspec-mocks/pull/1464
But I am probably not able to untangle this.
When I applied medicine similar to
https://src.fedoraproject.org/rpms/rubygem-guard/blob/rawhide/f/rubygem-guar...
I got past this issue, but with 46 failures due to kwargs. However, the recent code is heavily modified by this patch:
https://github.com/guard/guard/commit/cc8d97a27c824e58aa9251c9feca306b29d018...
And this patch has not landed yet 🤦🏻♂️
So this is upstream patch:
https://github.com/guard/guard/pull/986
I did rebase for F38:
https://bodhi.fedoraproject.org/updates/FEDORA-2022-adcca41a9d
This includes basically completely different patch. But luckily, the same patch works also for F37:
https://bodhi.fedoraproject.org/updates/FEDORA-2022-a870216502
Vít
Vít
which seems to touch every file. So it seems it would be reasonable to rebase prior even trying to fix the failures.
Vít
rubygem-guard-livereload
rubygem-memfs
And that actually might be it. I'll try to take look at listen.
Vít
Dne 03. 11. 22 v 16:37 Vít Ondruch napsal(a):
rubygem-guard-livereload
This is also fixed now:
https://src.fedoraproject.org/rpms/rubygem-guard-livereload/c/e8632b5351d3e6...
https://bodhi.fedoraproject.org/updates/FEDORA-2022-63392876d2
https://bodhi.fedoraproject.org/updates/FEDORA-2022-30e032585b
rubygem-memfs
Here is upstream PR:
https://github.com/simonc/memfs/pull/40
I am not going to apply the patch in Fedora this time. I'll leave it up to the maintainer.
I just noticed that also rubygem-mongo is broken. But this is due to some removed file. Will try to take a look ...
Vít
And that actually might be it. I'll try to take look at listen.
Vít
Dne 07. 11. 22 v 18:26 Vít Ondruch napsal(a):
I just noticed that also rubygem-mongo is broken. But this is due to some removed file. Will try to take a look ...
This is different issue:
https://github.com/rubygems/rubygems/issues/5768
The symlink was removed in more recent version:
https://jira.mongodb.org/browse/RUBY-2467
and RubyGems upstream was involved in this. So rebase or dropping the file from the .gemspec are solutions here. I'll probably go with the former for the moment.
Vít
This seems to be never ending story 🤦🏻♂️
https://koschei.fedoraproject.org/package/rubygem-mail?collection=f38
Vít
Dne 07. 02. 22 v 12:24 Vít Ondruch napsal(a):
Dear Mamoru,
Could you please check the following two packages which recently started to fail?
https://koschei.fedoraproject.org/package/rubygem-webmock?collection=f36
https://koschei.fedoraproject.org/package/rubygem-websocket-extensions?colle...
I suspect that this is related to the RSpec update, but the errors are quite strange on the first look:
1) WebMock::RequestSignature initialization assigns normalized headers Failure/Error: @headers = WebMock::Util::Headers.normalize_headers(headers) #<WebMock::Util::Headers (class)> received :normalize_headers with unexpected arguments expected: ({"A"=>"a"}) got: ({"A"=>"a"}) # ./lib/webmock/request_signature.rb:25:in `headers=' # ./lib/webmock/request_signature.rb:49:in `assign_options' # ./lib/webmock/request_signature.rb:11:in `initialize' # ./spec/unit/request_signature_spec.rb:23:in `new' # ./spec/unit/request_signature_spec.rb:23:in `block (3 levels) in <top (required)>' # ./lib/webmock/rspec.rb:37:in `block (2 levels) in <top (required)>'Thx a lot
Vít
P.S. Sorry for not being more helpful, I have to spent some time with CentOS Stream 9 to get Ruby into shape there, especially the problematic SystemTap support [1].
Vít Ondruch wrote on 2023/01/17 23:31:
This seems to be never ending story 🤦🏻♂️
https://koschei.fedoraproject.org/package/rubygem-mail?collection=f38
Vít
Well, I've noticed this, so I tried to reproduce, but it seems unreproducible.
I suspected:
* This is due to rspec-expectations 3.12.1 -> 3.12.2 * Or aarch64 specific:
But neither of the above seems to be the reason: At least koji build is successful and mockbuild on my local disc is also successful.
https://koji.fedoraproject.org/koji/taskinfo?taskID=96250590
Mamoru
Dne 07. 02. 22 v 12:24 Vít Ondruch napsal(a):
Dear Mamoru,
Could you please check the following two packages which recently started to fail?
https://koschei.fedoraproject.org/package/rubygem-webmock?collection=f36
https://koschei.fedoraproject.org/package/rubygem-websocket-extensions?colle...
I suspect that this is related to the RSpec update, but the errors are quite strange on the first look:
1) WebMock::RequestSignature initialization assigns normalized headers Failure/Error: @headers = WebMock::Util::Headers.normalize_headers(headers) #<WebMock::Util::Headers (class)> received :normalize_headers with unexpected arguments expected: ({"A"=>"a"}) got: ({"A"=>"a"}) # ./lib/webmock/request_signature.rb:25:in `headers=' # ./lib/webmock/request_signature.rb:49:in `assign_options' # ./lib/webmock/request_signature.rb:11:in `initialize' # ./spec/unit/request_signature_spec.rb:23:in `new' # ./spec/unit/request_signature_spec.rb:23:in `block (3 levels) in <top (required)>' # ./lib/webmock/rspec.rb:37:in `block (2 levels) in <top (required)>'Thx a lot
Vít
P.S. Sorry for not being more helpful, I have to spent some time with CentOS Stream 9 to get Ruby into shape there, especially the problematic SystemTap support [1].
ruby-sig mailing list -- ruby-sig@lists.fedoraproject.org To unsubscribe send an email to ruby-sig-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/ruby-sig@lists.fedoraproject.o... Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Dne 17. 01. 23 v 15:38 Mamoru TASAKA napsal(a):
Vít Ondruch wrote on 2023/01/17 23:31:
This seems to be never ending story 🤦🏻♂️
https://koschei.fedoraproject.org/package/rubygem-mail?collection=f38
Vít
Well, I've noticed this, so I tried to reproduce, but it seems unreproducible.
I suspected:
- This is due to rspec-expectations 3.12.1 -> 3.12.2
- Or aarch64 specific:
But neither of the above seems to be the reason: At least koji build is successful and mockbuild on my local disc is also successful.
https://koji.fedoraproject.org/koji/taskinfo?taskID=96250590
Interesting 🤔
One thing I have noticed is this in build done by Koschei:
~~~
-Building target platforms: noarch -Building for target noarch
~~~
vs your Koji build:
~~~
+Building target platforms: aarch64 +Building for target aarch64
~~~
The other possibility is the order of test cases and seed. However not sure if the spec order might be random actually.
Vít
Mamoru
Dne 07. 02. 22 v 12:24 Vít Ondruch napsal(a):
Dear Mamoru,
Could you please check the following two packages which recently started to fail?
https://koschei.fedoraproject.org/package/rubygem-webmock?collection=f36
https://koschei.fedoraproject.org/package/rubygem-websocket-extensions?colle...
I suspect that this is related to the RSpec update, but the errors are quite strange on the first look:
1) WebMock::RequestSignature initialization assigns normalized headers Failure/Error: @headers = WebMock::Util::Headers.normalize_headers(headers) #<WebMock::Util::Headers (class)> received :normalize_headers with unexpected arguments expected: ({"A"=>"a"}) got: ({"A"=>"a"}) # ./lib/webmock/request_signature.rb:25:in `headers=' # ./lib/webmock/request_signature.rb:49:in `assign_options' # ./lib/webmock/request_signature.rb:11:in `initialize' # ./spec/unit/request_signature_spec.rb:23:in `new' # ./spec/unit/request_signature_spec.rb:23:in `block (3 levels) in <top (required)>' # ./lib/webmock/rspec.rb:37:in `block (2 levels) in <top (required)>'Thx a lot
Vít
P.S. Sorry for not being more helpful, I have to spent some time with CentOS Stream 9 to get Ruby into shape there, especially the problematic SystemTap support [1].
ruby-sig mailing list -- ruby-sig@lists.fedoraproject.org To unsubscribe send an email to ruby-sig-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/ruby-sig@lists.fedoraproject.o... Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
ruby-sig mailing list -- ruby-sig@lists.fedoraproject.org To unsubscribe send an email to ruby-sig-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/ruby-sig@lists.fedoraproject.o... Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
ruby-sig@lists.fedoraproject.org
-
Mamoru TASAKA -
Vít Ondruch