Package Details: wkhtmltopdf-static 0.12.4-1

Git Clone URL: https://aur.archlinux.org/wkhtmltopdf-static.git (read-only)
Package Base: wkhtmltopdf-static
Description: Shell utility to convert HTML to PDF using Webkit and Qt (upstream static build)
Upstream URL: http://wkhtmltopdf.org/
Licenses: GPL3
Conflicts: wkhtmltopdf
Provides: wkhtmltopdf=0.12.4
Submitter: foutrelis
Maintainer: phillid
Last Packager: phillid
Votes: 43
Popularity: 0.190720
First Submitted: 2010-02-06 14:46
Last Updated: 2017-06-28 03:30

Latest Comments

phillid commented on 2017-06-28 03:33

Thank you for the heads up, I have updated these.

ryan-au commented on 2017-06-28 02:12

The source URLs in the PKGBUILD no longer work (download.gna.org times out), and the project's download page now links to files on GitHub. Can the PKGBUILD please be updated?

phillid commented on 2017-04-29 23:13

For what it's worth, these messages can be somewhat suppressed by forcing wkhtmltopdf to use the old openssl-1.0 (now packaged in /usr/lib/openssl-1.0/ by package openssl-1.0) with LD_LIBRARY_PATH

kageurufu commented on 2017-04-28 16:03

https://github.com/wkhtmltopdf/wkhtmltopdf/issues/3001

On my usage, the QSslSocket errors are output to stderr, and I'm still able to use "wkhtmltopdf - -" with pipes for input/output (Python subprocess)

Can you provide more details?

Koterpillar commented on 2017-04-28 10:41

The QSslSocket error messages are printed to the standard output, not standard error, breaking use use of "-" for output file.

sanerb commented on 2017-04-28 05:57

anyone else getting similar errors to this since openssl was updated to 1.1.x?

OSError: wkhtmltopdf reported an error:
Loading pages (1/6)
QSslSocket: cannot resolve CRYPTO_num_locks ] 10%
QSslSocket: cannot resolve CRYPTO_set_id_callback
QSslSocket: cannot resolve CRYPTO_set_locking_callback
QSslSocket: cannot resolve sk_free
QSslSocket: cannot resolve sk_num
QSslSocket: cannot resolve sk_pop_free
QSslSocket: cannot resolve sk_value
QSslSocket: cannot resolve SSL_library_init
QSslSocket: cannot resolve SSL_load_error_strings
QSslSocket: cannot resolve SSLv3_client_method
QSslSocket: cannot resolve SSLv23_client_method
QSslSocket: cannot resolve SSLv3_server_method
QSslSocket: cannot resolve SSLv23_server_method
QSslSocket: cannot resolve X509_STORE_CTX_get_chain
QSslSocket: cannot resolve OPENSSL_add_all_algorithms_noconf
QSslSocket: cannot resolve OPENSSL_add_all_algorithms_conf
QSslSocket: cannot resolve SSLeay
QSslSocket: cannot call unresolved function CRYPTO_num_locks
QSslSocket: cannot call unresolved function CRYPTO_set_id_callback
QSslSocket: cannot call unresolved function CRYPTO_set_locking_callback
QSslSocket: cannot call unresolved function SSL_library_init
QSslSocket: cannot call unresolved function SSLv23_client_method
QSslSocket: cannot call unresolved function sk_num
QSslSocket: cannot call unresolved function SSLv23_client_method0%
QSslSocket: cannot call unresolved function SSL_library_init
Counting pages (2/6)
Resolving links (4/6)
Loading headers and footers (5/6)
Printing pages (6/6)
Done
Exit with code 1 due to network error: UnknownNetworkError
QSslSocket: cannot call unresolved function CRYPTO_num_locks
QSslSocket: cannot call unresolved function CRYPTO_set_id_callback
QSslSocket: cannot call unresolved function CRYPTO_set_locking_callback

kageurufu commented on 2016-11-22 15:39

ARM binaries are not provided by the upstream packager. This is a binary source package, You might check this wkhtmltopdf issue https://github.com/wkhtmltopdf/wkhtmltopdf/issues/1868 for information on cross-compiling for ARM

benoliver999 commented on 2016-11-22 15:01

Does anyone know how to compile this for ARM? Specifically armv7h

kageurufu commented on 2015-11-18 00:14

Specifically, its statically linked to a patched QT library with support for headless rendering. The community/wkhtmltopdf package requires a X server running.

phillid commented on 2015-11-17 23:30

It is statically linked for all the qt stuff. Compare `ldd /usr/bin/wkhtmltopdf` with the package in the repos and this package to see what has been statically linked.

Nowaker commented on 2015-11-17 23:04

Why does it require a dynamic library to work? "wkhtmltopdf-static" suggests it's static, not dynamic.

kageurufu commented on 2015-08-31 17:40

icu48 is re-uploaded with the patchsets from the AUR3 version, as they fix some vulnerabilities.

dreivier commented on 2015-08-31 15:50

apparently icu48 became icu-48 on AUR.

phillid commented on 2015-08-05 22:25

Unsure why this was flagged out-of-date; maybe you're getting confused with testing releases provided upstream? Unflagging.

psytoolkit commented on 2015-02-11 17:12

icu48 fixed it for me, great!

phillid commented on 2015-02-10 23:48

All done. I've added it as an `optdepends` for both arches. I've only ever seen the problem on x86_64, but it won't hurt to blanket it.

kageurufu commented on 2015-02-10 18:51

No problem at all, and it looks like icu48 has updated their package with my changes!

Thanks

phillid commented on 2015-02-10 12:04

kageurufu, thank you for your work. I'll add icu48 as an optdepends soon, or once it's fixed.

Cheers

kageurufu commented on 2015-02-09 23:51

The problem is that the QT the debian builds are linked with dynamically loads libicui18n.so.48 specifically

strace shows the following:
open("/usr/lib/libicui18n.so.48", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)

Installing aur/icu48 provides the required .so to fix this issue. It only is required when rendering a PDF with unicode character encoding in the HTML, so maybe opt-depend it? The build for that package is currently failing, but I uploaded a fixed source package for it ( http://kageurufu.net/icu48-4.8.1.1-3.src.tar.gz ) and I'm just waiting for a response from the maintainer

phillid commented on 2015-01-28 08:24

psytoolkit, could you please try installing/updating icu? It might be a dependency I missed when adding them to the list.

psytoolkit commented on 2015-01-27 19:12

When running version 0.12.2.1, it runs, but I get the message:

Unable to load library icui18n "Cannot load library icui18n: (icui18n cannot open shared object file: No such file or directory)

phillid commented on 2015-01-26 23:37

That's odd, it's working fine this way... Could you please:

* Confirm that makepkg says the source's sum is correct
* Let me know about anything special you've set in /etc/makepkg.conf that I might be overlooking.
* Confirm that running `bsdtar tf /path/to/wkhtmltox-0.12.2.1_linux-wheezy-amd64.deb | grep 'data'` outputs 'data.tar.xz'

Thanks.

phillid commented on 2015-01-26 22:56



2015-01-26 22:37

That's odd, it's working fine this way... Could you please:

* Confirm that makepkg says the source's sum is correct
* Let me know about anything special you've set in /etc/makepkg.conf that I might be overlooking.
* Confirm that running `bsdtar tf /path/to/wkhtmltox-0.12.2.1_linux-wheezy-amd64.deb | grep 'data'` outputs 'data.tar.xz'

Thanks.

phillid commented on 2015-01-26 22:37

That's odd, it's working fine this way... Could you please:

* Makepkg says the source's sum is correct
* Let me know about anything special you've set in /etc/makepkg.conf that I might be overlooking.
* Confirm that running `bsdtar tf /path/to/wkhtmltox-0.12.2.1_linux-wheezy-amd64.deb | grep 'data'` outputs 'data.tar.xz'

Thanks.

bidossessi commented on 2015-01-26 20:28

Your package fails to build for me on x86_64.
==> Unpacking data.tar.xz (Debian package files)
tar: data.tar.xz: Cannot open: No such file or directory

Seems like either deb is not found or makepkg fails to unpack it. Not sure which.

phillid commented on 2015-01-17 22:23

Yes, my mistake. Rewrote part of the PKGBUILD and got confused between values used by $CARCH and architecture names used upstream. Thanks, fixed.

firecat53 commented on 2015-01-17 22:10

I believe there's a small type in the PKGBUILD:

;;
- "amd64")
+ "x86_64")
_arch="amd64"
sha256sums=('75f3379b8bf3998f9875270a12219263ee25ab3e97a511f37137c199b1f8c40a')
;;

At least, I had to change it so it worked for me!

Thanks!
Scott

phillid commented on 2015-01-17 05:40

Hi all, package has been updated to 0.12.2

phillid commented on 2015-01-13 20:51

Thanks for flagging to alert me to there being a new release. I'll be sure to update when I find the time within the next day or two.

phillid commented on 2014-11-04 02:06

Thanks @psytoolkit, I'd like to list the advantages in the description field, but there's such a massive list of advantages.

Some other key advantages:
* <h1> through <h6> tags are transformed into a hierarchy of PDF headings so you can expand/collapse sections/chapters in your reader and use the headings as anchors.
* IIRC, links don't work in the dynamically-linked version in the official repos.

psytoolkit commented on 2014-11-03 23:03

It is important to point out the advantage of this static version over the standard version on pacman (wkhtmltopdf). This version works really headless (e.g., as part of a crontab), whereas the normal version seems to need a running X server (or Xvfb).

phillid commented on 2014-08-04 22:38

Ta, that's just as I thought.

masterdisaster commented on 2014-08-04 21:43

Regarding libpng12 as a dependency I get:

# uname -m
x86_64

# ldd /usr/bin/wkhtmltopdf | grep libpng12
libpng12.so.0 => /usr/lib/libpng12.so.0 (0x00007ff77d140000)

phillid commented on 2014-08-03 00:19

Also, could anyone on x86_64 report as to whether the package depends on libpng12 or not? It does on i686, but I don't want to go adding it as a dependency for both architectures if it's not always required.

Cheers

phillid commented on 2014-08-03 00:18

Also, could anyone on x86_64 report as to whether the package depends on libpng or not? It does on i686, but I don't want to go adding it as a dependency for both architectures if it's not always required.

Cheers

phillid commented on 2014-08-03 00:17

Adopted. Updated. It works -- hooray.

phillid commented on 2014-08-02 22:57

Adopted. Updating in the next 24 hours or so.

phillid commented on 2014-08-01 23:08

>It seems debian package can be used directly. Here is a 0.12.1 x86_64 PKGBUILD: http://pastebin.com/TWUrN2CS

No. I tried the upstream debian build, but it was linked against libpng12.

quark commented on 2014-07-29 08:35

It seems debian package can be used directly. Here is a 0.12.1 x86_64 PKGBUILD: http://pastebin.com/TWUrN2CS

It is not carefully crafted. However if you are using x86_64 and want latest static build, it should work.

cracoucass14 commented on 2014-03-04 10:16

An update to version 0.12 (now hosted on github https://github.com/wkhtmltopdf/wkhtmltopdf/archive/0.12.0.tar.gz) would be very appreciated

foutrelis commented on 2010-08-03 14:35

@cyker: That appears to be a beta version though.

cyker commented on 2010-08-03 11:26

A new version 0.10 has come out. Just a kind remind.

firecat53 commented on 2010-04-23 19:48

This segfaults on x86_64 if I don't have ttf-ms-fonts installed. Works fine on x86 without it! Weird, but you might want to add it as a dependency unless no one else has this problem.

Scott