Package Details: h2o 2.3.0_beta2-2

Git Clone URL: https://aur.archlinux.org/h2o.git (read-only, click to copy)
Package Base: h2o
Description: Optimized HTTP server with support for HTTP/1.x and HTTP/2
Upstream URL: https://github.com/h2o/h2o
Licenses: MIT
Conflicts: libh2o
Provides: h2o, libh2o
Submitter: atweiden
Maintainer: HLFH (phoepsilonix)
Last Packager: HLFH
Votes: 30
Popularity: 0.000271
First Submitted: 2014-12-26 01:26 (UTC)
Last Updated: 2022-12-08 14:37 (UTC)

Dependencies (12)

Required by (0)

Sources (2)

Latest Comments

« First ‹ Previous 1 2 3 4 Next › Last »

atweiden commented on 2016-06-24 17:31 (UTC)

@wlhlm 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. [1] https://h2o.examp1e.net/install.html

wlhlm commented on 2016-06-24 12:43 (UTC) (edited on 2016-06-24 18:00 (UTC) by wlhlm)

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. [1]: https://wiki.archlinux.org/index.php/Arch_User_Repository#Prerequisites [2]: https://github.com/h2o/h2o/releases/tag/v2.0.1

nos1609 commented on 2016-03-21 21:33 (UTC)

No need for bundled ssl flag https://github.com/h2o/h2o/issues/290#issuecomment-94249001

atweiden commented on 2015-11-07 20:05 (UTC)

@carlwgeorge 1. The authors of h2o recommend libressl and specifically only recommend openssl for its improved performance in benchmarks. This information can be found at: https://h2o.examp1e.net/install.html 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.

<deleted-account> commented on 2015-10-19 20:49 (UTC)

Based on https://h2o.examp1e.net/install.html, 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 (UTC)

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

HLFH commented on 2015-09-26 03:07 (UTC)

Hi. It could be nice to replace network.target by network-online.target. https://github.com/h2o/h2o/issues/526 And btw, I'm HLFH, not HFLH ;) https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=h2o Have a nice day.

HLFH commented on 2015-09-22 06:17 (UTC)

New beta 3 with nice fixes (H2O version 1.5.0-beta3 --> [http2] fix crash when http2-reprioritize-blocking-assets, file.custom-handler are used together #511 #514 (Kazuho Oku). Please update your package atweiden, I know you're cool ;)

HLFH commented on 2015-09-16 20:16 (UTC)

autotools does not exist... "erreur : impossible de trouver la cible : autotools"

« First ‹ Previous 1 2 3 4 Next › Last »