Created attachment 2061641 [details] pcs rebuild log with ruby3.4.0dev Description of problem: ruby 3.4 is expected to be released on 2024-Dec-25, and now we are preparing for upgrading ruby on Fedora to this version: https://fedoraproject.org/wiki/Changes/Ruby_3.4 Now trying with `ruby 3.4.0dev (2024-12-07 master bd831bcca5) +PRISM [x86_64-linux]` : https://github.com/ruby/ruby/commit/bd831bcca534955533d9135d8c2f22d7ae5b9aa8 rebuilding Fedora `pcs-0.11.8-1.fc41` fails with pcsd testsuite as attached. (or you can see the result on copr: https://copr.fedorainfracloud.org/coprs/mtasaka/rubydep-heavypkg-test-4/build/8362964/ ) Version-Release number of selected component (if applicable): pcs-0.11.8-1.fc41 How reproducible: 100% Additional info: I guess this is due to some ruby3.4 message format change, see: https://github.com/ruby/ruby/blob/dd43af3be7eddb832c77ef367456fa023fed7d7a/NEWS.md?plain=1#L257-L281 but exactly not sure (I have not investigated pcsd code)
Hi Mamoru, Thank you for the early heads-up. We will have a look at the failures as soon as possible. However, we are dealing with releasing upstream versions of pcs and packaging them in RHEL, so it might take a bit longer. Do you have any optimal timeline for the the fix in mind? From our upstream release standpoint, it would be nice if our next upstream pcs-0.12 version included the fix for new Ruby since it will be built in Fedora 42 right after its release. The upstream release should happen before January 13th. Bearing in mind the end-of-year recharge, we might only get to it in late December/January... Does that timeline sound ok to you? Just for internal tracking purposes, I would only fix this in pcs-0.12 (our very fresh new major version) as this will be available only on Fedora 42+ where the update to Ruby 3.4 is proposed as a change. We have already planned to keep pcs-0.11 only on Fedora versions where pacemaker 2 lives. There is no pcs-0.12 build on Fedora 42 yet because we were waiting on pacemaker 3 which is a hard require for pcs-0.12 and it became available on Fedora 42 (and only there) just recently. So, in reality, pcs-0.11 will not really be affected by this change. I'm also not self-assigning this yet as I'm not sure if I'll have capacity to work on this.
Hello, Michal: Thank you for reply. I guess we will import ruby3.4 into rawhide on the first or second week of 2025-Jan (after US Christmas vacation ends). Then once pcs will become FTBFS, however as pcs build failure does not affect other packages which depend on ruby, for now it won't be much issue if pcs becomes FTBFS. It is apprecated if pcs gets to be compatible with ruby3.4 at least before F43 branching, I guess (which is going to happen on 2025-Feb-04). We don't plan to import ruby3.4 into released branches, so it is okay that pcs-0.12 will appear only on F42.
Hello Mamoru, Thank you for sharing your timelines. We will make sure that pcs is updated before Fedora 43 branches.
I believe that most of the failures are due to change in `JSON.pretty_generate` output [1]. So the fixes can look like: ~~~ diff --git a/pcsd/test/test_config.rb b/pcsd/test/test_config.rb index 43021f96..92cdd444 100644 --- a/pcsd/test/test_config.rb +++ b/pcsd/test/test_config.rb @@ -12,7 +12,7 @@ class TestConfig < Test::Unit::TestCase end def fixture_nil_config() - return ( + return (JSON.pretty_generate(JSON.parse( '{ "format_version": 2, "data_version": 0, @@ -32,11 +32,11 @@ class TestConfig < Test::Unit::TestCase } ] } -}') +}'))) end def fixture_empty_config() - return ( + return (JSON.pretty_generate(JSON.parse( '{ "format_version": 2, "data_version": 0, @@ -48,7 +48,7 @@ class TestConfig < Test::Unit::TestCase ] } -}') +}'))) end def test_parse_nil() ~~~ But maybe it would make sense to introduce something like `assert_config` which would shield this away. The remaining failure is this one: ~~~ Failure: test_basics(TestPcsdSettings) /builddir/build/BUILD/pcs-0.11.8-build/pcs-0.11.8/pcsd/test/test_cfgsync.rb:158:in 'TestPcsdSettings#test_basics' 155: 156: cfg.version = 4 157: assert_equal(4, cfg.version) => 158: assert_equal('26579b79a27f9f56e1acd398eb761d2eb1872c6d', cfg.hash) 159: 160: cfg.text = '{ 161: "format_version": 2, <"26579b79a27f9f56e1acd398eb761d2eb1872c6d">(UTF-8) expected but was <"db2b44331c63c25874ec30398fa82decd740fef4">(US-ASCII) diff: ? 2 6 5 79b79a27f9f56e1acd 398 eb 761d2eb1872c6d ? db b44331c 3c2 8 4 30 fa82d cd 40f f4 ? ++ +++++++ +++ + ???????????? -- ? +++++ ? ???? ???????? ? Encoding: UTF-8 ? S ASCII ? ?? ? ~~~ This seems to be computing SHA1 hash from `cfg.text` which is again formatted via `JSON.pretty_generate`, therefore the root cause seems to be the same. [1]: https://github.com/ruby/json/pull/626
IOW this is not strictly due to Ruby 3.4, but more about rubygem-json 2.8+ (which is by a chance included in Ruby 3.4).
Vít, your analysis is correct. Thanks for the hint of how to get the tests fixed. We'll verify that it doesn't brake the tests for older rubygem-json versions and proceed with implementing it.
Fixed upstream: - patch: https://github.com/ClusterLabs/pcs/commit/5e0f47324892aa7023dc126e88b2e101f90743d4 - pull request: https://github.com/ClusterLabs/pcs/pull/913
FEDORA-2025-9b3a8e7c72 (pcs-0.12.0-1.fc42) has been submitted as an update to Fedora 42. https://bodhi.fedoraproject.org/updates/FEDORA-2025-9b3a8e7c72
FEDORA-2025-9b3a8e7c72 (pcs-0.12.0-1.fc42) has been pushed to the Fedora 42 stable repository. If problem still persists, please make note of it in this bug report.