Bug 2072500 - Please branch and build weasyprint for epel9
Summary: Please branch and build weasyprint for epel9
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora EPEL
Classification: Fedora
Component: weasyprint
Version: epel9
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Felix Schwarz
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2022-04-06 12:11 UTC by Navneet
Modified: 2024-07-25 10:06 UTC (History)
3 users (show)

Fixed In Version: weasyprint-62.3-1.el9
Clone Of:
Environment:
Last Closed: 2024-07-21 00:39:39 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)

Description Navneet 2022-04-06 12:11:22 UTC
Description of problem:


Please branch and build weasyprint for epel9

Comment 1 Navneet 2022-04-14 19:34:17 UTC
Will you be able to branch and build weasyprint in epel9?

Comment 2 Felix Schwarz 2022-04-18 20:15:17 UTC
Hi Navneet,

the main problem with WeasyPrint is that upstream versioning mostly follow other web browsers: There is no particular stability guarantee. Basically each user must verify if a newer version of WeasyPrint still generates comparable PDF output. For EPEL this is a bit of a problem as maintainers should not push incompatible upgrades.

Now the situation might be easier with WeasyPrint 54+ as we don't need cairocffi anymore (dependency tree more manageable, easier to fix bugs for WeasyPrint developers) but certainly we won't be able to upgrade WeasyPrint often (if ever) in EPEL 9.

What are your thoughts about this? Newer WeasyPrint versions are easy to install via virtualenv+pip...

Comment 3 Navneet 2022-05-05 14:57:44 UTC
Hi Felix,

Sorry about the late reply here.

In our environment, we use yum only to install python packages as well. We don't use pip currently :(. I'm ok even if we can't upgrade it often. Basically, I'm moving our environment to be based on el9 and currently, I'm ending up using fc34's version, if I can get it in epel9 itself then I don't need to maintain it separately.

Comment 4 Christoph Karl 2024-06-19 06:33:45 UTC
Same argument here, maintainance via dnf (RHEL EPEL 9) is easier and already established via satellite.
For pip upgrades we would need another (yet to implement) mechanism.

Comment 5 Christoph Karl 2024-06-19 06:35:23 UTC
Dependant python packages which do not exist in EPEL:
pydyf
pyphen
And maybe tinycss2 in a newer version.

Comment 6 Felix Schwarz 2024-06-19 06:52:11 UTC
I'll need WeasyPrint on EPEL 9 in the next months as well so I will come up with something. However my time is really limited and I'm still hesitant of "locking in" a WeasyPrint version forever.

For example, I just had to switch to WeasyPrint v62 for PDF/A support and so a "permanently frozen" version in EPEL9 is not really attractive to me (thus I can't spend my work time on that). So I would need someone else coordinate the EPEL 9 version (testing, checking version requirements for tinycss2 et al with respect to other EPEL packages). Maybe Orion is interested as he already maintains tinycss2 in epel.

My current plan is to create a COPR repo like "weasyprint-el9-v62" which would hold all packages required to install weasyprint v62.x for EPEL9. Once I need a newer package, I would just create a new repo with a later version but if someone is willing to invest some time in getting something into EPEL proper, I'm certainly willing to help (bonus points for new contributors because I always try getting more brains involved in Fedora).

Comment 7 Christoph Karl 2024-06-19 07:29:44 UTC
I do not understand your concerns about increasing WeasyPrint versions.
Weasyprint is a leaf package (?) so soname bump (more-or-less) don't play a role (according to package rules)
I can help you using my private fedora account, but I am only a sunday packager. :)

Comment 8 Felix Schwarz 2024-06-19 09:33:42 UTC
> Weasyprint is a leaf package (?) so soname bump (more-or-less) don't play a role (according to package rules)

I see a potential problem for EPEL users: Whenever I push a new WeasyPrint version, the generated PDF might be different and I consider this a breaking change, thus not acceptable for EPEL. That is also the reason why new major versions for WeasyPrint are added only to Fedora rawhide.

Comment 9 Felix Schwarz 2024-07-12 06:54:34 UTC
Well, as it happens I need WeasyPrint in EL9. Previously I would have distributed this outside of EPEL but seems like there are more users interested in WeasyPrint for EPEL and not much concern about being stuck on an old version.

Comment 10 Fedora Update System 2024-07-12 08:14:44 UTC
FEDORA-EPEL-2024-b93ff26026 (python-pydyf-0.10.0-1.el9, python-pyphen-0.13.2-1.el9, and 1 more) has been submitted as an update to Fedora EPEL 9.
https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2024-b93ff26026

Comment 11 Fedora Update System 2024-07-13 02:57:16 UTC
FEDORA-EPEL-2024-b93ff26026 has been pushed to the Fedora EPEL 9 testing repository.

You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2024-b93ff26026

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

Comment 12 Fedora Update System 2024-07-21 00:39:39 UTC
FEDORA-EPEL-2024-b93ff26026 (python-pydyf-0.10.0-1.el9, python-pyphen-0.13.2-1.el9, and 1 more) has been pushed to the Fedora EPEL 9 stable repository.
If problem still persists, please make note of it in this bug report.

Comment 13 Christoph Karl 2024-07-25 10:06:37 UTC
Works for me.
Thank you


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