Hi,
I've prepared rebase of poppler to 21.01.0 in the side tag "f34-build-side-35737". I ask you to build your dependent packages in it and I will ask to merge it to main branch next Tuesday (19th of January). Let me know if you won't have time for that or there will be some other circumstances where I can help.
There are several API changes and soname bump of the base library libpoppler.so.*.
I've also removed the Qt4 frontend which we've maintained for compatibility. Relevant package maintainers were contacted and some of them already switched to Qt5.
Upstream removed poppler-cairo.pc and poppler-splash.pc since it considers those APIs pure internal. It is better to use poppler-glib or poppler-qt5.
Btw, if your package still uses the unstable API (headers from poppler-devel), could you consider to change it to use a stable API (glib, qt5, C++)? It would mean less work for you and I would be able to disable the unstable API.
Regards
Marek
On Mon, Jan 11, 2021 at 12:45 PM Marek Kasik mkasik@redhat.com wrote:
Hi,
I've prepared rebase of poppler to 21.01.0 in the side tag "f34-build-side-35737". I ask you to build your dependent packages in it and I will ask to merge it to main branch next Tuesday (19th of January). Let me know if you won't have time for that or there will be some other circumstances where I can help.
There are several API changes and soname bump of the base library libpoppler.so.*.
I've also removed the Qt4 frontend which we've maintained for compatibility. Relevant package maintainers were contacted and some of them already switched to Qt5.
Upstream removed poppler-cairo.pc and poppler-splash.pc since it considers those APIs pure internal. It is better to use poppler-glib or poppler-qt5.
Btw, if your package still uses the unstable API (headers from poppler-devel), could you consider to change it to use a stable API (glib, qt5, C++)? It would mean less work for you and I would be able to disable the unstable API.
I believe that Jan Grulich (Cc'd to this email) is working on bringing Qt6 into Fedora now[1], so it'd be great if we could coordinate that so Poppler gets its Qt6 frontend enabled too.
[1]: https://pagure.io/fedora-kde/SIG/issue/30
-- 真実はいつも一つ!/ Always, there's only one truth!
python3-sip-4.19.24 seems too old for python3-poppler-qt5 21.1.0, and sip5 seems to lack python bindings. What's the best plan to resolve this?
-- Gwyn Ciesla she/her/hers ------------------------------------------------ in your fear, seek only peace in your fear, seek only love -d. bowie
Sent with ProtonMail Secure Email.
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ On Monday, January 11, 2021 11:44 AM, Marek Kasik mkasik@redhat.com wrote:
Hi,
I've prepared rebase of poppler to 21.01.0 in the side tag "f34-build-side-35737". I ask you to build your dependent packages in it and I will ask to merge it to main branch next Tuesday (19th of January). Let me know if you won't have time for that or there will be some other circumstances where I can help.
There are several API changes and soname bump of the base library libpoppler.so.*.
I've also removed the Qt4 frontend which we've maintained for compatibility. Relevant package maintainers were contacted and some of them already switched to Qt5.
Upstream removed poppler-cairo.pc and poppler-splash.pc since it considers those APIs pure internal. It is better to use poppler-glib or poppler-qt5.
Btw, if your package still uses the unstable API (headers from poppler-devel), could you consider to change it to use a stable API (glib, qt5, C++)? It would mean less work for you and I would be able to disable the unstable API.
Regards
Marek
devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-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/devel@lists.fedoraproject.org
I didn't realize sip5 provided the python bindings, but it does. The build still fails:
https://kojipkgs.fedoraproject.org//work/tasks/6643/59456643/build.log
-- Gwyn Ciesla she/her/hers ------------------------------------------------ in your fear, seek only peace in your fear, seek only love -d. bowie
Sent with ProtonMail Secure Email.
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ On Monday, January 11, 2021 12:29 PM, Scott Talbert swt@techie.net wrote:
On Mon, 11 Jan 2021, Gwyn Ciesla via devel wrote:
python3-sip-4.19.24 seems too old for python3-poppler-qt5 21.1.0, and sip5 seems to lack python bindings. What's the best plan to resolve this?
What do you mean by "sip5 seems to lack python bindings?"
Scott
devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-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/devel@lists.fedoraproject.org
On Mon, 11 Jan 2021, Gwyn Ciesla via devel wrote:
I didn't realize sip5 provided the python bindings, but it does. The build still fails:
https://kojipkgs.fedoraproject.org//work/tasks/6643/59456643/build.log
Looks like you're still using sip4? /usr/bin/sip is sip4. sip5 is /usr/bin/sip5.
building 'popplerqt5' extension /usr/bin/sip -I /usr/share/sip -t POPPLER_V21_01_0 -c build/temp.linux-armv7l-3.9 -b build/temp.linux-armv7l-3.9/poppler-qt5.sbf -I /usr/share/sip/PyQt5 -n PyQt5.sip -t WS_X11 -t Qt_5_15_0 poppler-qt5.sip sip: poppler-form.sip:152: ::Poppler::FormFieldChoice::choicesWithExportValues() unsupported function return type - provide %MethodCode and a C++ signature error: command '/usr/bin/sip' failed with exit code 1
Scott
Marek Kasik wrote:
I've also removed the Qt4 frontend which we've maintained for compatibility. Relevant package maintainers were contacted and some of them already switched to Qt5.
For diffpdf, it looks like it needs to be upgraded to this fork: https://gitlab.com/eang/diffpdf
(The original upstream is now proprietary software.)
Kevin Kofler
On 1/11/21 9:31 PM, Kevin Kofler via devel wrote:
Marek Kasik wrote:
I've also removed the Qt4 frontend which we've maintained for compatibility. Relevant package maintainers were contacted and some of them already switched to Qt5.
For diffpdf, it looks like it needs to be upgraded to this fork: https://gitlab.com/eang/diffpdf
(The original upstream is now proprietary software.)
Thanks for pointing me to this fork, I was not aware of it. I've prepared my own pull request already: https://src.fedoraproject.org/rpms/diffpdf/pull-request/1
Looking at it now, it seems that CI failed for it. I'm going to have a look at that.
Kevin Kofler
devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-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/devel@lists.fedoraproject.org
Marek Kasik wrote:
Thanks for pointing me to this fork, I was not aware of it. I've prepared my own pull request already: https://src.fedoraproject.org/rpms/diffpdf/pull-request/1
Looking at it now, it seems that CI failed for it. I'm going to have a look at that.
You probably don't have all the changes required for the Qt 5 port covered.
The Debian package: https://packages.debian.org/sid/utils/diffpdf has a patch against the last upstream version to make it support Qt 5.
But in the long run, I think switching to the maintained fork is the way to go.
Kevin Kofler
On Mon, Jan 11, 2021 18:44:47 +0100, Marek Kasik wrote:
Hi,
Hi Marek,
I've prepared rebase of poppler to 21.01.0 in the side tag "f34-build-side-35737". I ask you to build your dependent packages in it and I will ask to merge it to main branch next Tuesday (19th of January). Let me know if you won't have time for that or there will be some other circumstances where I can help.
Thanks. I've kicked off builds for gdcm and pdfpc. I don't *think* any of my other packages depend on poppler.
- https://koji.fedoraproject.org/koji/taskinfo?taskID=59461809 - https://koji.fedoraproject.org/koji/taskinfo?taskID=59461658
Hi,
On 1/11/21 6:44 PM, Marek Kasik wrote:
Hi,
I've prepared rebase of poppler to 21.01.0 in the side tag "f34-build-side-35737". I ask you to build your dependent packages in it and I will ask to merge it to main branch next Tuesday (19th of January). Let me know if you won't have time for that or there will be some other circumstances where I can help.
There are several API changes and soname bump of the base library libpoppler.so.*.
these are the packages which need to be rebuilt (which requires libpoppler.so.*):
calligra gambas3 gdal gdcm inkscape kf5-kitinerary libreoffice pdf2djvu scribus texlive-base
Sorry for not sending it in the previous email. The ones which uses stable frontends only don't need to be rebuilt.
Thanks
I've also removed the Qt4 frontend which we've maintained for compatibility. Relevant package maintainers were contacted and some of them already switched to Qt5.
Upstream removed poppler-cairo.pc and poppler-splash.pc since it considers those APIs pure internal. It is better to use poppler-glib or poppler-qt5.
Btw, if your package still uses the unstable API (headers from poppler-devel), could you consider to change it to use a stable API (glib, qt5, C++)? It would mean less work for you and I would be able to disable the unstable API.
Regards
Marek