Bug 2315457 - Please branch and build libsoup for EPEL 10
Summary: Please branch and build libsoup for EPEL 10
Keywords:
Status: NEW
Alias: None
Product: Fedora
Classification: Fedora
Component: libsoup
Version: 42
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Milan Crha
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks: EPEL10Tracker 2315449
TreeView+ depends on / blocked
 
Reported: 2024-09-28 12:44 UTC by Xavier Bachelot
Modified: 2025-03-25 11:58 UTC (History)
9 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed:
Type: ---
Embargoed:


Attachments (Terms of Use)

Description Xavier Bachelot 2024-09-28 12:44:21 UTC
Hi,

Could you please branch and build libsoup for EPEL 10 ?
It is needed to build another package.

Regards,
Xavier

Comment 1 Milan Crha 2024-09-30 06:58:40 UTC
Hmm, how do you do that, please? I did not work with EPEL directly by any way yet, this used to be built there automatically, if at all, before. I'm sorry for my ignorance.

Comment 2 Xavier Bachelot 2024-09-30 08:30:53 UTC
Working with EPEL is similar to working with Fedora. You are probably used to rawhide, f41, f40, f39, etc... dist-git branches, it will be exactly the same for epel8, epel9 and epel10 branches. Thus something alike "fedpkg clone libsoup; cd libsoup; fedpkg request-branch epel10; git pull; git checkout epel10; git rebase rawhide; git push; fedpkg build"

Comment 3 Milan Crha 2024-09-30 10:26:59 UTC
Thanks for the commands. It seems complicated on the first look, but it might be just because it's the starter.

Thinking of it, an app cannot mix libsoup2 and libsoup3 in runtime, directly or indirectly (brought in through its dependencies, or dependencies of the dependencies,...). It's one of the reasons why the libsoup2 did not make it into the RHEL/EPEL 10, because it can cause breakage for some apps.

Could you tell me what app requires it, please?

Some apps allow to switch between libsoup and curl usage, I used the switch with syncevolution for example.

Comment 4 Xavier Bachelot 2024-09-30 11:22:48 UTC
This is needed for inkscape, the build request bug for it is: https://bugzilla.redhat.com/show_bug.cgi?id=2315449, as can be seen in the "Blocks" field of this bug.
I have no idea if inkscape can be made to use libsoup3 or curl, but indeed your comment about mixing libsoup2/libsoup3 is a good point.

Actually, I'm just trying to track dependencies in order to get ImageMagick, and various packages that depends on it, into EPEL 10. I've been building the dependent packages recursively from their rawhide branch to list the missing dependencies, without taking a deep look at every and all of them. It is very much possible I have missed some switches or else that could help lighten/simplify the dependencies chain.

Comment 5 Xavier Bachelot 2024-09-30 11:25:38 UTC
The dependency chain that leads to libsoup 2 is:
ImageMagick -> djvulibre -> inkscape -> libsoup2

Comment 6 Milan Crha 2024-09-30 12:14:21 UTC
Interesting Inkscape can use ImageMagick during its build, aka the opposite order of the dependencies.

Could it be the inkscape's .spec file was not updated after:
https://gitlab.com/inkscape/inkscape/-/commit/a4959939e11b0253fbbaf12c3e1f11490b4328ab
?

Comment 7 Xavier Bachelot 2024-09-30 12:49:43 UTC
This commit is not in the 1.3.x branch of inkscape, it's only available in the unreleased 1.4 branch, but I guess you are pointing in the right direction.

Inkscape would need to have at least https://gitlab.com/inkscape/inkscape/-/commit/73c83ef9b8dc3e3dfd0fe24c75356623e7390ebd and https://gitlab.com/inkscape/inkscape/-/commit/a4959939e11b0253fbbaf12c3e1f11490b4328ab backported over 1.3.2 to drop the libsoup2 dependency, if at all possible.

Comment 8 Milan Crha 2024-09-30 13:21:28 UTC
Oh, did they not release it yet? I thought they did, when the commit happened ~6 months ago. I believe it'll be better to not depend on the libsoup2, to avoid problems in the future.

I looked into the first commit and I hope I did not overlook anything, but it seems to me the `get_file()` function is not used anywhere. The commit mentions gtk4, which might not be relevant in the 1.3 series, thus maybe if you could try to disable that code, and the libsoup2 usage, in EPEL in a custom downstream patch, then it can prove the libsoup2 is not needed even in the 1.3 series, at least for parts used by the Fedora/EPEL build.

Comment 9 Aoife Moloney 2025-02-26 13:12:20 UTC
This bug appears to have been reported against 'rawhide' during the Fedora Linux 42 development cycle.
Changing version to 42.


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