I believe it might be time to deprecate this port. Indeed, - the GitHub repository has been archived on Jan 2, 2023; - last release is Jun 10, 2020; - in https://github.com/wkhtmltopdf/wkhtmltopdf/issues/5160 it can be read that the project is not maintained anymore. Morevover, the port depends on GCC 8, which is unsupported upstream (latest GCC release is 12, which is also GCC_DEFAULT, and GCC 13 is coming). Also please note that this port is the last port dependent on lang/gcc8 according to Freshports: deprecating it would allow to remove lang/gcc8 too.
What replacement provides the feature to convert HTML to PDF ? This is useful and I have not found a replacement.
There's print/py-weasyprint, but I have to test it.
I'm not opposed, but vaguely interested, because I installed the package in January. <https://www.freshports.org/converters/wkhtmltopdf/#requiredby> (In reply to Kurt Jaeger from comment #2) Other alternatives (I have little or no experience with these: textproc/denature <https://www.freshports.org/textproc/denature/> textproc/htmldoc <https://www.freshports.org/textproc/htmldoc/> textproc/p5-PDF-FromHTML <https://www.freshports.org/textproc/p5-PDF-FromHTML/> textproc/pdftohtml <https://www.freshports.org/textproc/pdftohtml/> – I vaguely recall using this around eleven months ago, <https://forums.freebsd.org/posts/561337>.
(In reply to Kurt Jaeger from comment #2) weasyprint fails, see https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=269325
(In reply to Graham Perrin from comment #3) It seems one of those tools does it for remote sites.
(In reply to Kurt Jaeger from comment #5) *none*, not 'one' 8-}
(In reply to Kurt Jaeger from comment #6) weasyprint works for remote sites, but needs updating, @work.
(In reply to Kurt Jaeger from comment #7) weasyprint is now updated. I have not found a way so that if it is used for remote sites, that it also includes the pictures into the generated pdf. Any ideas on that ? That looks like a show stopper right now.
(In reply to Kurt Jaeger from comment #8) Hmm, tested remote sites with wkhtmltopdf, and it has similar problems as weasyprint. And recent builds really dump core, where older builds work.
Created attachment 240418 [details] Output of weasyprint on FreeBSD homepage (In reply to Kurt Jaeger from comment #8) What issues do you have with images using weasyprint? I made some experiments, and it seems to work well enough for me. Sometimes I also have some images missing (maybe it happens when the base URL changes), but in general I get most of them (see for example the attached file, result of "weasyprint https://freebsd.org freebsd_org.pdf"). Another alternative to generate PDF files from URLs is using your web browser to print the page on a PDF file. This gives me better results.
(In reply to Lorenzo Salvadore from comment #10) > Another alternative to generate PDF files from URLs is using your > web browser to print the page on a PDF file. The whole point of wkhtmltopdf or weasyprint is to do it from some batch job, not via a GUI.
I see. I'll look around and see if I can find anything useful.
The port has been deprecated for multiple reasons, please see commit https://cgit.freebsd.org/ports/commit/?id=236797691ff1de47c71cc33e17bf0bf7c1c6f6a7 .
^Triage: Assign to the committer who did the commit that closed the bug.
Oops. I missed this however as mentioned in my commit once 13.3 comes out there is no way to build this anymore. :'(
This port is still much needed for our production environment. I suppose this won't be much help, but I have a linux (CentOS) version running on FreeBSD, using the Linux binary compatibility mode.
I know this issue has been closed already and that I am very very late pitching in, but... I do NOT understand why there is still a dependency on GCC8, since I myself put forward a fix for build on Fbsd 11.4 i386 with GCC11 in 2021-07-06: bug #243349, comment #c29 I no longer see my patch file in the current port and STILL see USE_GCC = 8 in make where mine works with USE_GCC = yes Have NOT tried recently to compile with GCC, since I switched to 64-bit shortly after this and used compile with clang ever since. Am a huge fan of wkhtmltopdf and will try with current GCC12 on Fbsd 13.2 64-bit, but if anayopne else would like to try with the debian patch, please do! Copied the text below to be sure: Created attachment 226276 [details] Solution for compile fail on 32-bit i386 combined with GCC9+! (In reply to commit-hook from comment #28) Found a solution for compile fail on 32-bit i386 combined with GCC9+! Tested on 11.4-STABLE i386 with GCC11. Basically I found a solution on Debian for the this problem: https://salsa.debian.org/qt-kde-team/qt/qt4-x11/commit/0d4a3dd61ccb156dee556c214dbe91c04d44a717 1. So I created a new patch file with the correct line numbers for the FreeBSD entries and named it: patch-gcc9-qforeach-qglobal.h (find attached) 2. I also deleted patch file patch-mkspecs_common_gcc-base.conf which contains a superfluous hard rpath link to gcc8 3. changed in Makefile: .if ${ARCH} == "i386" || ${ARCH} == "powerpc" || ${CHOSEN_COMPILER_TYPE} == gcc -USE_GCC= 8 +USE_GCC= yes .endif HAVE NOT VERIFIED EFFECTS ON COMPILE WITH CLANG OR 64-BIT!
Created attachment 246442 [details] Fix compile wuth GCC11 (remove dependency for GCC8) This the patch that belongs to comment: #17
(In reply to Raymond Quakkelaar from comment #18) Thanks for the patch. I will try this with USE_GCC=11 as we are migrating to GCC DEFAULT of 13 in next quarter I will also try with that first.
Fails with GCC13 retrying with 12. https://pkg.bofh.network/data/124i386-default/2023-11-20_12h43m06s/logs/errors/wkhtmltopdf-0.12.6_1.log
Fails with GCC12 retrying with GCC11. https://pkg.bofh.network/data/124i386-default/2023-11-20_12h47m46s/logs/errors/wkhtmltopdf-0.12.6_1.log
Created attachment 246446 [details] custom libmap.conf and make.conf On top of the debian patch, I also used attached custom libmap.conf and make.conf Perhapse if you replace the references in there from GCC11 to GCC13 or GCC12 that it might work for those versions...
(In reply to Raymond Quakkelaar from comment #22) Please submit a full git formatted patch. And this also does not work with gcc11 https://pkg.bofh.network/data/124i386-default/2023-11-20_12h50m37s/logs/errors/wkhtmltopdf-0.12.6_1.log
Good news is it builds with 10. So will comment in a while.
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/ports/commit/?id=3f47a0b1eb91e6b5241cbe73a435aa1ea19e4f19 commit 3f47a0b1eb91e6b5241cbe73a435aa1ea19e4f19 Author: Muhammad Moinur Rahman <bofh@FreeBSD.org> AuthorDate: 2023-11-20 12:42:15 +0000 Commit: Muhammad Moinur Rahman <bofh@FreeBSD.org> CommitDate: 2023-11-20 13:26:49 +0000 converters/wkhtmltopdf: Fix build with gcc10 The patch is accepted from Debian: https://salsa.debian.org/qt-kde-team/qt/qt4-x11/commit/0d4a3dd61ccb156dee556c214dbe91c04d44a717 Still keep it DEPRECATED and see how it builds on 13.X series. PR: 269313 Reported by: r.quakkelaar@quaras.nl Approved by: portmgr (just-fix-it) .../php83-mbstring/files/patch-config.m4 (gone) | 44 ---------------------- converters/wkhtmltopdf/Makefile | 5 +-- .../patch-mkspecs_common_gcc-base.conf (gone) | 11 ------ ...webkit__Source__JavaScriptCore__wtf__Platform.h | 4 +- .../files/patch-src_corelib_global_qglobal.h (new) | 40 ++++++++++++++++++++ 5 files changed, 43 insertions(+), 61 deletions(-)
Thanks for your work on this. Please note however that GCC 10 is also now unsupported upstream. It is soon to deprecate the corresponding port, but if someone had the time to get the port build with some higher GCC version, it would help avoid getting into the same issue soon.
On FreeBSD 13.2 X64 with GCC 13.2 I CAN COMPILE AND RUN WITHOUT ERROR!!! (but with custom /etc/libmap.conf and /etc/make.conf see comment: #22 attachment: #246446) /etc/libmap.conf: # $FreeBSD$ includedir /usr/local/etc/libmap.d # STARTING WITH FREEBSD-11.4 WKHTMLTOPDF DOES NOT COMPILE UNDER CLANG 10.0.0 THEREFORE GCC REQUIRED THEREFORE MIGHT (RE)COMPILE OTHER PORTS AS WELL .if !empty(.CURDIR:M/usr/ports/*) && exists(/usr/local/lib/gcc13) && empty(.CURDIR:M*/pkg) libgcc_s.so.1 /usr/local/lib/gcc13/libgcc_s.so.1 libgomp.so.1 /usr/local/lib/gcc13/libgomp.so.1 libobjc.so.3 /usr/local/lib/gcc13/libobjc.so.4 libssp.so.0 /usr/local/lib/gcc13/libssp.so.0 libstdc++.so.6 /usr/local/lib/gcc13/libstdc++.so.6 libatomic.so.1 /usr/local/lib/gcc13/libatomic.so.1 libquadmath.so.0 /usr/local/lib/gcc13/libquadmath.so.0 .endif /etc/make.conf # $FreeBSD$ DEFAULT_VERSIONS+=gcc=13 # STARTING WITH FREEBSD-11.4 WKHTMLTOPDF DOES NOT COMPILE UNDER CLANG 10.0.0 THEREFORE GCC REQUIRED THEREFORE MIGHT (RE)COMPILE OTHER PORTS AS WELL .if !empty(.CURDIR:M/usr/ports/*) && exists(/usr/local/lib/gcc13) && empty(.CURDIR:M*/pkg) CC=gcc13 CXX=g++13 CPP=cpp13 CFLAGS+=-Wall -Wextra -Wno-deprecated -Wno-deprecated-declarations -Wno-format -w CXXFLAGS+=-fpermissive .endif /usr/ports/converters/wkhtmltopdf/make.conf USE_GCC=yes ****console output:**** ===> Installing for wkhtmltopdf-0.12.6_1 ===> Checking if wkhtmltopdf is already installed ===> Registering installation for wkhtmltopdf-0.12.6_1 Installing wkhtmltopdf-0.12.6_1... For proper functionality you may need to install the following port(s): x11-fonts/webfonts ===> NOTICE: This port is deprecated; you may wish to reconsider installing it: Upstream abandoned the project. It is scheduled to be removed on or after 2024-06-30. ===>>> pkg-message for wkhtmltopdf-0.12.6_1 On install: For proper functionality you may need to install the following port(s): x11-fonts/webfonts Always: ===> NOTICE: This port is deprecated; you may wish to reconsider installing it: Upstream abandoned the project. It is scheduled to be removed on or after 2024-06-30. ===>>> Done displaying pkg-message files ===>>> Re-installation of wkhtmltopdf-0.12.6_1 complete
(In reply to Raymond Quakkelaar from comment #27) Thanks for your feedback. Indeed, after having taken a look at the Makefile, I see that GCC is now required only on i386 and powerpc, none of which is a tier 1 platform for FreeBSD. Thus GCC versions are not a reason to deprecate this port anymore. However, please note that I wrote other reasons to deprecate the port in my first comment: > - the GitHub repository has been archived on Jan 2, 2023; > - last release is Jun 10, 2020; > - in https://github.com/wkhtmltopdf/wkhtmltopdf/issues/5160 it can be read that the project is not maintained anymore. Those reasons alone are enough to deprecate the port. The ports tree is for up to date supported software, we cannot keep old unmaintained software in there. Of course, you are free to install whatever you want on your machines: the sources for converters/wxhtmltopdf are available and you can do whatever you want with them as long as the license allows it. In particular, you can fork the software and maintain it if you want, and then we could add a port for your fork in the ports tree. You can also install the software on your machine building it from sources (or by your own ports tree with custom patches).
In reply to comment #28 1. I find it quite telling that the repsonse on the fact that the port can be built with latest GCC 13.2 was much more delayed than the ones on my earlier posts, as if there was a wish for it to fail... 2. I do NOT understrand the urgency in removing wkhtmltopdf from the ports tree especially since there is NO viable alternative! One that also supports setting of session id cookies and thus can be used safely with online html. 3. Why make it therefore unnecessary more difficult for users of this port that obviously needs very little maintaining and is to my knowledge also freely available on current Linux sytems 4. Keep a disclaimer message for my part stating "use at your own peril", and when users remain using it some will always be able to help solve problems... as I have done now. Regards, Raymond.
I am a user and this port is indeed critical for us and we don't have alternatives at this time, except for moving to Linux and using wkhtmltopdf available overhear. I would appreciate it if this could stay.
(In reply to Raymond Quakkelaar from comment #29) 1. I have no wish for it to fail. Delays are only due to the fact that I am a volunteer. I have many things to do both inside and outside FreeBSD. Furthermore, as far as GCC is concerned, there is no issue with this port now that GCC is not required on any tier 1 platforms. GCC is not the reason for deprecating this port (not now at least), the reason is that it is unmaintained upstream. Thus the fact that the port builds with GCC 13 is not relevant at the moment (although please see comment #20; I have not tested the port myself). 2. There is no urgency at all indeed. When it has been deprecated the expiration was set to 2024-06-30, which is much longer than usual. 3. It is not obvious that the port needs very little maintainance. What is obvious is only that, at the moment, the port builds and runs. Maintaining the port however means much more. For example, each time FreeBSD developers and contributors make some big changes to the OS, the whole ports tree need to be tested (exp-runs) and failing ports need to be fixed, and these ports include converters/wkhtmltopdf too. By the way, this was the reason for the deprecation commit: it was noticed that the port would not build with llvm16, which is coming with FreeBSD 13.3. Since the port is unmaintained upstream, it made more sense to deprecate it rather than to spend time to fix it. See comment #15 and commit https://cgit.freebsd.org/ports/commit/?id=236797691ff1de47c71cc33e17bf0bf7c1c6f6a7 . However, thanks to your work, a supported version of GCC can be used instead. At the moment, it is used only on less supported architectures (i386 and powerpc). When FreeBSD 13.3 is released it will probably need to be used on all platforms. Luckily, your tests suggest that this will not be a problem (although please see comment #20). Please try to submit a patch that works out of the box (without changes in libmap.conf or other files outside the port) and we will commit it, so that the port can have its lifetime extended further if necessary. 4. The disclaimer is the deprecation message. We are not removing the port right now, we are allowing for some time before removing it. One of the reasons is indeed that it seems that there is no alternative for it, but there are users such as you who needs it and are able to get it working. We can consider postponing the expiration date if the problem persists, but this is a workaround, not a solution. Please believe me, I have no intention to annoy FreeBSD users by removing the ports they need. But FreeBSD developers and contributors are almost all volunteers and have limited resources, so they cannot be asked to spend their time and efforts on ports of software that is not maintained upstream. Please try to dig for an alternative to this software before the expiration date: if you cannot find it and need more time, we will consider postponing the expiration date. To postpone the expiration date, we need at least to keep it building and running, so the patch for higher versions of GCC will be needed.
(In reply to Lorenzo Salvadore from comment #31) I am actually +1 with Lorenzo. We do understand the users perspective that there is a need of a port. But the users should also understand the fact that there is a huge impact of keeping legacy stuffs which are more like unmaintained. One major reason is an unmaintained application means that even there are security vulnerabilities it's not disclosed anywhere. And someone is actually abusing that vulnerability. Hence we prefer that someone is managing those repositories and actively working on those when there are incidents. Another issue is with CPE/CVE mentions as an upstream is unmaintained or a specific version has reached EOL there is no way to add more CVE entries for those versions so far I am aware of. From the project point of view to the external world it is more like "Oh .. FreeBSD that is serving vulnerable pkg through official channels." Another problem is when we keep legacy ports and want to remove others everyone comes up with excuses from another legacy ports. If we keep this practice the technical debt will actually riseup geometrically and all we will have in the tree are legacy ports. Let me think about other options.
Reply to comment #31 1. "it was noticed that the port would not build with llvm16, which is coming with FreeBSD 13.3." When it compiles with current GCC (inclduding 13.2) then llvm (whatever version) IS IRRELEVANT! 2. "At the moment, it is used only on less supported architectures (i386 and powerpc)" I am running on X64 and do NOT think I am the only one. 3 I can compile without the /etc/libmap.conf stuff! THE ONLY THING NECESSARY IS: in /usr/ports/converters/wkhtmltopdf/make.conf #.if ${ARCH} == "i386" || ${ARCH} == "powerpc" || ${CHOSEN_COMPILER_TYPE} == gcc USE_GCC=13 CC=gcc13 CXX=g++13 CPP=cpp13 CFLAGS+=-Wall -Wextra -Wno-deprecated -Wno-deprecated-declarations -Wno-format -w CXXFLAGS+=-fpermissive #.endif THIS IS VERY BASIC! Please note: 1. I used USE_GCC=13 because otherwise GCC 12 (current default) would be installed which I do NOT want now 2. Maybe the CC= CXX= CPP= might even NOT be necessary or any of the other flags, but this combo works
(In reply to Raymond Quakkelaar from comment #33) > 1. "it was noticed that the port would not build with llvm16, which is coming with FreeBSD 13.3." When it compiles with current GCC (inclduding 13.2) then llvm (whatever version) IS IRRELEVANT! While we prefer that ports compile with the default compiler, compiling with GCC is indeed fine. I was only explaining one of the reasons that was behind the deprecation commit. If a port builds successfully with GCC it is perfectly fine. Requiring GCC does not make any port deprecated and this holds for converters/wkhtmltopdf too. > 2. "At the moment, it is used only on less supported architectures (i386 and powerpc)" I am running on X64 and do NOT think I am the only one. I must have been unclear (sorry, I am not a native English speaker). I meant that GCC is now used to build the port only on less supported architectures (by default; you can explicitly ask for GCC if you want of course). Tier 1 platforms build it using clang instead (by default). Since the port does not build with llvm16 on tier 1 platforms, tier 1 platforms will need to switch to GCC too in the future. > 3 I can compile without the /etc/libmap.conf stuff! THE ONLY THING NECESSARY IS: > > in /usr/ports/converters/wkhtmltopdf/make.conf > > #.if ${ARCH} == "i386" || ${ARCH} == "powerpc" || ${CHOSEN_COMPILER_TYPE} == gcc USE_GCC=13 > > CC=gcc13 > CXX=g++13 > CPP=cpp13 > CFLAGS+=-Wall -Wextra -Wno-deprecated -Wno-deprecated-declarations -Wno-format -w > CXXFLAGS+=-fpermissive > #.endif > > > THIS IS VERY BASIC! > Please note: > > 1. I used USE_GCC=13 because otherwise GCC 12 (current default) would be installed which I do NOT want now > 2. Maybe the CC= CXX= CPP= might even NOT be necessary or any of the other flags, but this combo works I will test your suggestion, but I will also need to change it a bit. Modifying ports through make.conf is not allowed (even if make.conf is in the port itself), but your changes can be added to the Makefile directly. None of CC, CXX, CPP and CFLAGS should be needed: USE_GCC=13 should already set CC, CXX and CPP; as for CFLAGS, I do not see the point to set both -Wall (which asks to show all warnings) and -w (which asks to inhibit all warnings). The CXXFLAGS might be necessary. I am going to test it. I understand that this port is important for you, but please avoid writing in uppercase letters or using expressions such as "this is very basic". As I wrote, we are mostly volunteers, it is not our job to work on FreeBSD. We do our best for FreeBSD and its users because we want, not because we must. I am sorry if it happens that we do not meet your expectations. Thanks.
Created attachment 246525 [details] Always use default GCC I managed to successfully build the port both with GCC 12 and GCC 13 with the attached patch. It is even simpler than what Raymond suggested: it only switches to use GCC unconditionnaly. It does not even set -fpermissive. Muhammad: Can you please test the patch too, since you had failures with GCC 12 and GCC 13? Kurt: As maintainer of the port, do you approve? If the patch works, it will be easier to postpone expiration if necessary. However please note that the port is still deprecated and users should still find an alternative. It will not be removed soon, but it will eventually. We understand that this port is very important for some users and we will keep it as much as possible and needed, but it will break sooner or later and it will not be possible to fix it as it is unmaintained upstream. Thanks for your understanding.
In reply to comment #35 Thx for the efforts and hopefully the eol date can be somewhat pushed back. Also, only starting with FreeBSD 13.3 and 14 (llvm16?) the build needs forced use of GCC.
(In reply to Lorenzo Salvadore from comment #35) Hi Lorenzo .. I am more or less going AFK now upto 3rd December. I just 4 different patches ready to be committed for php which I will do once the release announcements are out. :D So I will take care of this after I return or someone please feel free to test and commit. Ceyeah soon everyone.
(In reply to Lorenzo Salvadore from comment #35) I'm traveling, so can't really test (until 4th of December). Thanks for analysing this. Have you tested the binary on some example webpages ? bofh: I'm sorry to reopen the bug, the patch should probably be in some new PR, but working on it in the PR is not the end of the world...
(In reply to Kurt Jaeger from comment #38) I run-tested this patch on 13.2, this worked. So I approve.
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/ports/commit/?id=83f9c8601b1dfcfc6025ac27c26ea95cd3c47737 commit 83f9c8601b1dfcfc6025ac27c26ea95cd3c47737 Author: Lorenzo Salvadore <salvadore@FreeBSD.org> AuthorDate: 2023-11-23 15:45:25 +0000 Commit: Lorenzo Salvadore <salvadore@FreeBSD.org> CommitDate: 2023-12-04 11:48:58 +0000 converters/wkhtmltopdf: Always build with default GCC - Building with the default GCC version (12) always works. - GCC 13, soon to become the default GCC version, also works. - It simplifies the port. - The port will not build with llvm 16. PR: 269313 Approved by: pi (maintainer) converters/wkhtmltopdf/Makefile | 9 +++------ 1 file changed, 3 insertions(+), 6 deletions(-)
Patch committed. Thanks to everyone.
Thx for the patch! But am I to understand that the deprecated status and moreover planned removal date remain unchanged eventhough it now compiles properly on all current versions and platforms...
I believe the deprecated status should stay, but the expire date can be postponed as far as needed to find a replacement. I would like to let the maintainer of the port decide what to do with it. As far as I am concerned as maintainer for the GCC ports, this port does not cause any issue and I do not plan to touch it again any time soon.
(In reply to Lorenzo Salvadore from comment #43) ...here we go again... I can compile and run it with LLVM/CLANG 17.0.6 on FreeBSD 13.3!!! Simply commented out #USE_GCC= yes in: /usr/ports/converters/wkhtmltopdf/MakeFile but kept flags: CFLAGS+=-Wall -Wextra -Wno-deprecated -Wno-deprecated-declarations -Wno-format -w CXXFLAGS+=-fpermissive in: /etc/make.conf (but flags could also be placed in ports makefile) SO, COME ON GUYS, WHEN CONFIRMED I DID NOT MISS ANYTHING, WERE ARE NOT DEPRECATING AND REMOVING A PORT THAT COMPILES AND RUNS WITH LATEST LLVM/CLANG... ARE WE???
+1
(In reply to Raymond Quakkelaar from comment #44) I did a second build/compile and run on another LLVM/CLANG 17.0.6 FreeBSD 13.3 box that succeeded even WITHOUT the extra CFLAGS and CXXFLAGS! They turn out to be superfluous. A bit of a mystery why it ever failed with LLVM/CLANG 14 and 15? (except for Kurt's patch in bug #273334 perhapse applied after that initial fail)
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/ports/commit/?id=e155f7e7d823f4b5e0475889153296e68881ee86 commit e155f7e7d823f4b5e0475889153296e68881ee86 Author: Kurt Jaeger <pi@FreeBSD.org> AuthorDate: 2024-04-14 19:15:27 +0000 Commit: Kurt Jaeger <pi@FreeBSD.org> CommitDate: 2024-04-14 19:15:27 +0000 converters/wkhtmltopdf: do not force USE_GCC - builds on all versions, run tests look ok as well - moved deprecation date to end of 2024 for now See latest comments in PR PR: 269313 converters/wkhtmltopdf/Makefile | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-)