Current ebuild and upstream version restricts the required apache version to 2.2. There's an upstream bug which has patches to add apache 2.4 compatibility, attached are is a patch against mod_spdy-0.9.3.3.ebuild incorporating the required patches and ebuild work and a tarball containing the changed files only. Reproducible: Always
Created attachment 349440 [details, diff] mod_spdy-0.9.3.3_apache24_compat.patch
Created attachment 349442 [details] mod_spdy_changed_files.tar.bz2
Created attachment 349444 [details, diff] apache-2.4.4-mod_ssl_with_npn.patch Apache NPN patch for 2.4 I used for testing.
Comment on attachment 349444 [details, diff] apache-2.4.4-mod_ssl_with_npn.patch having apache support npn in mod_ssl is bug 471512. there's not really anything the mod_spdy ebuild can do here (well, i could have it optionally build+install a custom mod_ssl, but i don't think that's the route we want to take).
Comment on attachment 349440 [details, diff] mod_spdy-0.9.3.3_apache24_compat.patch sorry, but this is a non-starter: -need_apache2_2 +need_apache2_4 we probably need to update depend.apache.eclass to include want_apache2_4 so that we can then call want_apache_2_{2,4} and set REQUIRED_USE to be one of those.
Hm, it's cool to see the patch I provided on code.google.com here (mod_spdy-0.9.3.3-2.2_to_2.4.patch) :) Anyway, it's true the ebuild shouldn't mess with mod_ssl, only three files need to be patched (apache_spdy_stream_task_factory.cc , log_message_handler.cc and mod_spdy.cc). Make this issue dependent on Bug 471512 . Would it be ok, if the patches would be modifed with #if macros, and the ebuild would simply use need_apache2 ?
(In reply to Zoltán Halassy from comment #6) i don't think we need to depend on bug 471512 as it's orthogonal to mod_spdy supporting a newer version of apache your patch isn't the blocker here ... we need the ebuild itself to support multiple versions of apache. i'm not really sure what is needed to make that happen.
(In reply to SpanKY from comment #7) > i don't think we need to depend on bug 471512 as it's orthogonal to mod_spdy > supporting a newer version of apache Well I get it supporting 2.4 is orthogonal for requiring mod_ssl with NPN, but mod_spdy ebuild doesn't make much sense without requiring NPN in mod_ssl, as SPDY will not be negotiated without it. > your patch isn't the blocker here ... we need the ebuild itself to support > multiple versions of apache. i'm not really sure what is needed to make > that happen. I don't have much time at the moment to solve that problem, but it shouldn't be that difficult (you can use #ifdef directives for detecting versions in the code). If I will have the time, I will work on a version-independent patch for mod_spdy.
(In reply to SpanKY from comment #7) > we need the ebuild itself to support > multiple versions of apache. BTW, check how www-apache/mod_fcgid ebuild works, it supports both 2.2 and 2.4.
(In reply to Zoltán Halassy from comment #8) i'm talking about the ebuild here, not the source code. ebuilds don't have #ifdef statements.
(In reply to SpanKY from comment #10) > i'm talking about the ebuild here, not the source code. ebuilds don't have > #ifdef statements. mod_fcgid works both 2.2 and 2.4 . It uses need_apache2 instead of need_apache2_2 or need_apache2_4 .
-need_apache2_2 +need_apache2 would be the solution I think.
don't think it's a stable blocker since we're still waiting for bug 471512 mod_spdy might be a moot point in general though since it's been merged into upstream apache ...
It appears as if spdy is going away in favor of HTTP/2 http://www.phoronix.com/scan.php?page=news_item&px=Google-Chrome-SPDY-HTTP2
(In reply to Leho Kraav (:macmaN @lkraav) from comment #14) that's true and eventually things will converge on apache. but right now, mod_spdy is our only option afaik to support something newer than HTTP/1.1.
mod_spdy is dead and we have mod_h2 now which is apache-2.4 compatible (and included in upstream now)
