Package Details: h2o 2.1.0-2

Git Clone URL: (read-only)
Package Base: h2o
Description: Optimized HTTP server with support for HTTP/1.x and HTTP/2
Upstream URL:
Licenses: MIT
Conflicts: libh2o
Provides: h2o, libh2o
Submitter: atweiden
Maintainer: atweiden (HLFH)
Last Packager: atweiden
Votes: 20
Popularity: 1.528079
First Submitted: 2014-12-26 01:26
Last Updated: 2017-01-24 06:21

Dependencies (9)

Required by (0)

Sources (2)

Latest Comments

The_Decryptor commented on 2017-01-21 06:38

I tried upgrading to the 2.1.0 package but it refused to install on my system, `makepkg -i` kept spitting out this error

error: failed to commit transaction (conflicting files)
h2o: /usr/lib64 exists in filesystem
Errors occurred, no packages were upgraded.

I think it's because of this upstream commit, but since I've never used cmake before I've really got no idea.

Easy to fix though, just add `-DCMAKE_INSTALL_LIBDIR=/usr/lib` to the cmake line in build() and it installed fine for me.

The_Decryptor commented on 2016-06-27 05:12

The variant of ChaCha20 in the version of LibreSSL that h2o bundles isn't the final IETF variant, it's a earlier Google proposal. LibreSSL 2.4+ supports the IETF variant (Needed for browsers like Firefox that don't support the earlier variant) and OpenSSL 1.1 supports the IETF version as well.

Something that is different though, is that OpenSSL 1.1 supports Curve25519, while I can't find any reference to any version of LibreSSL supporting it, so when 1.1 is out it might be worth switching to OpenSSL for that.

And thanks for providing the package, been using it for a while and it works great!

wlhlm commented on 2016-06-24 17:59

@atweiden Thanks for the quick update!

atweiden commented on 2016-06-24 17:31


I made mruby explicit. Thank you for the recommendation.

> I think using a bundled SSL lib is bad, I much prefer it being managed as explicit dependency by the package manager

Perhaps when the official arch openssl package supports chacha20-poly1305, this can be re-examined; though, even then I would still lean towards doing what the author of h2o recommends, which at this time is using the bundled libressl [1]:

“Generally speaking, we believe that using LibreSSL is a better choice for running H2O, since LibreSSL not only is considered to be more secure than OpenSSL but also provides support for new ciphersuites such as chacha20-poly1305 which is the preferred method of Google Chrome. However, it is also true that LibreSSL is slower than OpenSSL on some benchmarks. So if you are interested in benchmark numbers, using OpenSSL is a reasonable choice.”

There are very few arch systems using libressl right now, so I doubt if the external option is going to be viable except in the case that you are willing to forego libressl for openssl. I'm only aware of libressl being the default on Void Linux systems.


wlhlm commented on 2016-06-24 12:43

Thanks for packaging h2o!

I have a couple of suggestions in regards to packaging:

- h2o can embed ruby for request handling, which can be configured via the -DWITH_MRUBY cmake option. When this option is not explicitly specified, the build script tries to automatically detect whether ruby is installed or not resulting in different packages depending on the build environment. I would prefer to have this option set explicitly (it currently is not) so that h2o builds the same in every environment. I've tested it and it seems that ruby gets statically linked and is not required as runtime dependency (though is needed when building applications with libh2o). This means adding 'ruby' to makedepends(), and optdepends() and '-DWITH_MRUBY=on' to cmake should do the trick.

- libtool, make, and pkg-config can all be removed from makedepends(), because users of the AUR are assumed to have the base-devel group installed [1] of which the previously listed packages are a part of.

- just for consideration: I think using a bundled SSL lib is bad, I much prefer it being managed as explicit dependency by the package manager. In case of a security update one has to wait for the h2o maintainer to update the bundled lib and one has to wait for the maintainer of the h2o package to update the PKGBUILD. When linking to an external lib it's likely to get updated in a more timely fashion and it doesn't require an updated PKGBUILD (no rebuild). Now when using an external SSL lib I think using openssl is the best option here, since there is no libressl package in the official repositories and the only libressl package in the AUR is for the unstable 2.4 branch. So to sum it up I think that using the external openssl lib from the official repos is still a better option than to use the bundled libressl, despite it being discourage in the h2o install instructions.

BTW, h2o 2.0.1 [2] has just been released.


nos1609 commented on 2016-03-21 21:33

No need for bundled ssl flag

atweiden commented on 2015-11-07 20:05


1. The authors of h2o recommend libressl and specifically only recommend openssl for its improved performance in benchmarks. This information can be found at:

2. Invoking libressl does not download a libressl binary. It is currently built from the libressl 2.2.2 tarball, which can be found in the h2o source code at misc/libressl-2.2.2.tar.gz. I do not think it is wise to diverge from what version of libressl h2o links against.

carlwgeorge commented on 2015-10-19 20:49

Based on, it looks like you have to choose between bundled LibreSSL or the system OpenSSL. I have two questions.

1) I'm not clear on why LibreSSL is preferred, since Arch has OpenSSL 1.0.2 available. Isn't LibreSSL still considered highly experimental?

2) I have a strong preference against bundled libraries, as most package maintainers do. If you insist on building against LibreSSL, can the PKGBUILD or Makefile be tweaked to use the libressl AUR package instead of bundling?

atweiden commented on 2015-09-27 05:31

HLFH, you are now a comaintainer of this pkg. ty

HLFH commented on 2015-09-26 03:07

Hi. It could be nice to replace by And btw, I'm HLFH, not HFLH ;) Have a nice day.

All comments