Bug 2372462 - pcs is going to be broken by update to Rack 3.x+
Summary: pcs is going to be broken by update to Rack 3.x+
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: pcs
Version: rawhide
Hardware: Unspecified
OS: Linux
unspecified
medium
Target Milestone: ---
Assignee: Michal Pospisil
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2025-06-12 13:50 UTC by Vít Ondruch
Modified: 2025-07-22 21:01 UTC (History)
7 users (show)

Fixed In Version: pcs-0.12.1-1.fc43
Clone Of:
Environment:
Last Closed: 2025-07-22 21:01:19 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description Vít Ondruch 2025-06-12 13:50:53 UTC
Working on Ruby on Rails 8 change [1], this will require to update to Rack 3.x. In my testing, this causes following FTBFS to pcs:

~~~
+ ./configure --build=x86_64-redhat-linux --host=x86_64-redhat-linux --program-prefix= --disable-dependency-tracking --prefix=/usr --exec-prefix=/usr --bindir=/usr/bin --sbindir=/usr/bin --sysconfdir=/etc --datadir=/usr/share --includedir=/usr/include --libdir=/usr/lib64 --libexecdir=/usr/libexec --localstatedir=/var --runstatedir=/run --sharedstatedir=/var/lib --mandir=/usr/share/man --infodir=/usr/share/info --enable-local-build --enable-use-local-cache-only --enable-individual-bundling --enable-webui --with-pcsd-default-cipherlist=PROFILE=SYSTEM --with-pcs-lib-dir=/usr/lib PYTHON=/usr/bin/python3
configure: WARNING: unrecognized options: --disable-dependency-tracking
checking for a BSD-compatible install... /usr/bin/install -c
checking whether sleep supports fractional seconds... yes
checking filesystem timestamp resolution... 0.01
checking whether build environment is sane... yes
checking for a race-free mkdir -p... /usr/bin/mkdir -p
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking whether make supports nested variables... yes
checking xargs -n works... yes
checking how to create a pax tar archive... gnutar
checking build system type... x86_64-redhat-linux-gnu
checking host system type... x86_64-redhat-linux-gnu
checking whether ln -s works... yes
checking whether make sets $(MAKE)... (cached) yes
checking for gawk... (cached) gawk
checking for x86_64-redhat-linux-pkg-config... no
checking for pkg-config... /usr/bin/pkg-config
checking pkg-config is at least version 0.9.0... yes
checking whether /usr/bin/python3 version is >= 3.12... yes
checking for /usr/bin/python3 version... 3.13
checking for /usr/bin/python3 platform... linux
checking for GNU default /usr/bin/python3 prefix... ${prefix}
checking for GNU default /usr/bin/python3 exec_prefix... ${exec_prefix}
checking for /usr/bin/python3 script directory (pythondir)... ${PYTHON_PREFIX}/lib/python3.13/site-packages
checking for /usr/bin/python3 extension module directory (pyexecdir)... ${PYTHON_EXEC_PREFIX}/lib64/python3.13/site-packages
checking for systemd... yes
checking for pkg-conf systemd var systemdsystemunitdir... yes (detected: /usr/lib/systemd/system)
checking for pkg-conf systemd var systemdsystemunitpath... yes (detected: /etc/systemd/system:/etc/systemd/system:/run/systemd/system:/usr/local/lib/systemd/system:/usr/lib/systemd/system:/usr/lib/systemd/system:/lib/systemd/system)
checking for ruby... /usr/bin/ruby
checking for ruby >= 3.1... yes
checking for pkg-conf ruby var ruby_version... yes (detected: 3.4.0)
checking for gem... gem
checking for time... no
checking for tar... tar
checking linux distribution... fedora
checking default settings for fedora ... fedora (or alike) default settings will be used
checking pip module: pip >= 23.0... yes (detected: 25.1.1)
checking pip module: wheel ... yes (detected: 0.45.1)
checking pip module: setuptools >= 66.1... yes (detected: 78.1.1)
checking pip module: cryptography ... yes (detected: 45.0.3)
checking pip module: lxml ... yes (detected: 5.4.0)
checking pip module: pyparsing >= 3.0.0... yes (detected: 3.1.2)
checking pip module: dacite ... no
checking pip module: tornado >= 6.0.0... yes (detected: 6.4.2)
checking pip module: python-dateutil >= 2.7.0... yes (detected: 2.9.0.post0)
checking pip module: pycurl ... yes (detected: 7.45.6)
checking pip module: pyagentx ... no
checking ruby gem: power_assert... yes (detected: 2.0.5)
checking ruby gem: test-unit... yes (detected: 3.6.8)
checking ruby gem: backports... yes (detected: 3.23.0)
checking ruby gem: childprocess... yes (detected: 4.1.0)
checking ruby gem: ethon... yes (detected: 0.15.0)
checking ruby gem: ffi... yes (detected: 1.17.0)
checking ruby gem: json... yes (detected: 2.12.2)
checking ruby gem: ruby2_keywords... yes (detected: 0.0.5)
checking ruby gem: mustermann... yes (detected: 3.0.3)
checking ruby gem: rack... yes (detected: 3.1.8)
checking ruby gem: rackup... no
ls: cannot access 'pcsd/vendor/bundle//cache/rackup-*': No such file or directory
configure: error: cache only build required but no source detected in pcsd/vendor/bundle//cache
error: Bad exit status from /var/tmp/rpm-tmp.hZaevk (%build)
    Bad exit status from /var/tmp/rpm-tmp.hZaevk (%build)
~~~

The issues might be that `rackup` was split into independent package upstream and Fedora will follow [2]. The full build log might be available here [3], but this is WIP, so who knows.

Not sure if this can be fixed somehow in advance 🤷 Sorry for inconvenience.

[1]: https://fedoraproject.org/wiki/Changes/Ruby_on_Rails_8.0
[2]: https://bugzilla.redhat.com/show_bug.cgi?id=2338474
[3]: https://copr.fedorainfracloud.org/coprs/vondruch/ror8-mpb/builds/

Reproducible: Always

Comment 1 Tomas Jelinek 2025-06-13 07:07:14 UTC
Pcs works with rack 3.1.x just fine, it's been tested already. The fix may be as simple as adding rubygem-rackup into BuildRequires. We'll look into it.

Comment 2 Michal Pospisil 2025-06-13 07:40:13 UTC
I was going to write something similar... There is a check in configure that requires rackup for rack >= 3. Pcs should work if rackup is added as a Require and BuildRequire - our code also checks for rack version and uses rackup classes with rack >= 3. We have been bundling new rack and rackup in RHEL for some time and it works fine.

I see that rubygem-rackup is built in the ror8 Copr, is it going to be a new package in Fedora as a part of this change?

Also, I'm not quite sure what to do at this point - should I create an if condition in our spec file that would require rubygem-rackup for rack >= 3? I guess that would solve this in advance?

Comment 3 Vít Ondruch 2025-06-17 09:37:43 UTC
(In reply to Michal Pospisil from comment #2)
> I see that rubygem-rackup is built in the ror8 Copr, is it going to be a new
> package in Fedora as a part of this change?

Yes, rubygem-rackup is going to be new package. Please see:

https://bugzilla.redhat.com/show_bug.cgi?id=2338474

> Also, I'm not quite sure what to do at this point - should I create an if
> condition in our spec file that would require rubygem-rackup for rack >= 3?
> I guess that would solve this in advance?

If `rackup` binary is all what is needed, then I'd suggest to add something like: `BR: %{_bindir}/rackup`. This should work for current fedoras as well as for the separate `rubygem-rackup`, because the binary is already provided by rubygem-rack.

Comment 4 Fedora Update System 2025-07-22 17:53:04 UTC
FEDORA-2025-6e6f4af8f4 (pcs-0.12.1-1.fc43) has been submitted as an update to Fedora 43.
https://bodhi.fedoraproject.org/updates/FEDORA-2025-6e6f4af8f4

Comment 5 Michal Pospisil 2025-07-22 18:19:47 UTC
Just to touch on how this was resolved...

> If `rackup` binary is all what is needed, then I'd suggest to add something like: `BR: %{_bindir}/rackup`. This should work for current fedoras as well as for the separate `rubygem-rackup`, because the binary is already provided by rubygem-rack.

No, we do not depend on the rackup binary. Pcs only uses Rack::Handler(s) which were renamed to Rackup::Handler(s). Autotools replace the correct name in the code depending on the version of rack.

This was resolved by boolean dependencies: `[Build]Requires: (rubygem(rack) < 3 or (rubygem(rack) >= 3 and rubygem(rackup))` [1]. This works across all Fedoras and better illustrate what upstream code expects. I want to note that for some reason, requiring the rpm package name instead of the virtual provide seems to break dnf5: https://github.com/rpm-software-management/dnf5/issues/2361

See commits for the full story: 
https://src.fedoraproject.org/rpms/pcs/c/825b1756acd99d7dda76c814814e902a0265d4de
https://src.fedoraproject.org/rpms/pcs/c/959addae3b271e7c7823380db0f493bc5bf167c2?branch=rawhide

[1]: https://rpm-software-management.github.io/rpm/manual/boolean_dependencies.html

Comment 6 Fedora Update System 2025-07-22 21:01:19 UTC
FEDORA-2025-6e6f4af8f4 (pcs-0.12.1-1.fc43) has been pushed to the Fedora 43 stable repository.
If problem still persists, please make note of it in this bug report.


Note You need to log in before you can comment on or make changes to this bug.