Package Details: h2o 2.2.6-1

Git Clone URL: (read-only, click to copy)
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: HLFH
Last Packager: HLFH
Votes: 29
Popularity: 0.164332
First Submitted: 2014-12-26 01:26
Last Updated: 2020-04-16 10:57

Latest Comments

1 2 3 Next › Last »

rlees85 commented on 2021-04-18 11:05

Doesn't build now that Arch has moved to Ruby 3.0.

[ 57%] Built target bundled-ssl
(in /home/archlinux/h2o/src/h2o-2.2.6/deps/mruby)
PKG-CONFIG onigmo 
PKG-CONFIG oniguruma 
rake aborted!
wrong number of arguments (given 2, expected 1)
Rakefile:40:in `<top (required)>'
make[2]: *** [CMakeFiles/mruby.dir/build.make:70: CMakeFiles/mruby] Error 1
make[1]: *** [CMakeFiles/Makefile2:415: CMakeFiles/mruby.dir/all] Error 2
make: *** [Makefile:136: all] Error 2
==> ERROR: A failure occurred in build().

Manually installing Ruby 2.7, symlinking Ruby 2.7 binary to /usr/bin/ruby and manually updating the PKGBUILD to require ruby2.7 instead of ruby fixes it.

towo commented on 2021-01-18 16:44

I'd recommend adding gcc and bison to the dependencies because it's technically needed for a build and not automatically included with the listed dependencies.

HLFH commented on 2020-04-16 10:58

h2o has been updated to 2.2.6.

rgacogne commented on 2019-11-21 08:50

Thank you for maintaining this package! I really would like to see it upgraded to 2.2.6 which fixed several security issues (CVE-2019-9512 CVE-2019-9514 CVE-2019-9515). I can offer to take ownership of this package in the AUR if that helps, since it's used to provide DoH support by the dnsdist-git package I already maintain anyway.

grigruss commented on 2019-09-19 06:30

How about upgrade? I tryed build version 2.2.6, and it's working. Just change version to 2.2.6 and sha256sums to: ('f8cbc1b530d85ff098f6efc2c3fdbc5e29baffb30614caac59d5c710f7bda201' '8a85462b6798deaaab343b5dae73437e251c5018d70d260a4a4440b9bbb053e6')

nickcorona commented on 2019-04-20 13:54

Bison is a missing dependency.

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.