Created attachment 351018 [details] ebuild for uwsgi 1.9.12 with php5.5 and mono added added PHP_TARGET="php5-5" added USE="mono" also included this fix https://bugs.gentoo.org/show_bug.cgi?id=469098
Created attachment 351022 [details] uwsgi-1.9.12.ebuild
Comment on attachment 351022 [details] uwsgi-1.9.12.ebuild --- uwsgi-1.9.6.ebuild 2013-04-20 02:31:37.000000000 +0200 +++ - 2013-06-17 12:33:21.437444651 +0200 @@ -1,6 +1,6 @@ # Copyright 1999-2013 Gentoo Foundation # Distributed under the terms of the GNU General Public License v2 -# $Header: /var/cvsroot/gentoo-x86/www-servers/uwsgi/uwsgi-1.9.6.ebuild,v 1.1 2013/04/20 00:31:37 zx2c4 Exp $ +# $Header: /var/cvsroot/gentoo-x86/www-servers/uwsgi/uwsgi-1.9.12.ebuild,v 1.1 2013/06/15 18:52:17 zx2c4 Exp $ EAPI="5" PYTHON_DEPEND="python? *" @@ -11,7 +11,7 @@ RUBY_OPTIONAL="yes" PHP_EXT_NAME="dummy" PHP_EXT_INI="no" -USE_PHP="php5-3 php5-4" # deps must be registered separately below +USE_PHP="php5-3 php5-4 php5-5" # deps must be registered separately below PHP_EXT_OPTIONAL_USE="php" MY_P="${P/_/-}" @@ -24,8 +24,8 @@ LICENSE="GPL-2" SLOT="0" -KEYWORDS="" -IUSE="apache2 +caps +carbon cgi debug erlang gevent graylog2 json ldap lua +nagios pam perl +pcre php probepg +python rrdtool rsyslog ruby spooler sqlite syslog +xml yaml zeromq" +KEYWORDS="~amd64" +IUSE="apache2 +caps +carbon cgi debug erlang gevent graylog2 json ldap lua mono +nagios pam perl +pcre php probepg +python rrdtool rsyslog ruby spooler sqlite syslog +xml yaml zeromq" REQUIRED_USE="|| ( cgi erlang lua perl php python ruby )" # util-linux is required for libuuid when requesting zeromq support @@ -41,6 +41,7 @@ php? ( php_targets_php5-3? ( dev-lang/php:5.3[embed] ) php_targets_php5-4? ( dev-lang/php:5.4[embed] ) + php_targets_php5-5? ( dev-lang/php:5.5[embed] ) ) probepg? ( dev-db/postgresql-base:= ) ruby? ( $(ruby_implementations_depend) ) @@ -48,7 +49,8 @@ rsyslog? ( app-admin/rsyslog ) xml? ( dev-libs/libxml2 ) yaml? ( dev-libs/libyaml ) - zeromq? ( net-libs/zeromq sys-apps/util-linux )" + zeromq? ( net-libs/zeromq sys-apps/util-linux ) + mono? ( dev-lang/mono )" DEPEND="${CDEPEND} virtual/pkgconfig" RDEPEND="${CDEPEND} @@ -105,6 +107,7 @@ use rrdtool && plugins+=", rrdtool" use rsyslog && plugins+=", rsyslog" use syslog && plugins+=", syslog" + use mono && plugins+=", mono" # Notes: # * the embedded_plugins mostly follows the list of embedded_plugins @@ -246,6 +249,11 @@ apache-module_src_compile done fi + + if use mono ; then + python uwsgiconfig.py --plugin plugins/mono gentoo || die "building plugin for mono failed" + fi + } src_install() { @@ -259,6 +267,7 @@ use erlang && dosym uwsgi /usr/bin/uwsgi_erlang use lua && dosym uwsgi /usr/bin/uwsgi_lua use perl && dosym uwsgi /usr/bin/uwsgi_psgi + use mono && dosym uwsgi /usr/bin/uwsgi_mono if use php ; then for s in $(php_get_slots); do @@ -302,6 +311,7 @@ use erlang && elog " '--plugins erlang' for erlang" use lua && elog " '--plugins lua' for lua" use perl && elog " '--plugins psgi' for perl" + use mono && elog " '--plugins mono' for mono" if use php ; then for s in $(php_get_slots); do @@ -315,6 +325,7 @@ use gevent && elog " '--plugins python${a/.},gevent${a/.}' for gevent support in python-${a}" use erlang && elog " '--plugins python${a/.},erlang,pyerl${a/.}' for erlang support in python-${a}" done + python_mod_optimize uwsgidecorators.py fi if use ruby ; then @@ -326,3 +337,9 @@ done fi } + +pkg_postrm() { + if use python ; then + python_mod_cleanup uwsgidecorators.py + fi +}
the uwsgi.dll from /var/tmp/portage/www-servers/uwsgi-1.9.12/work/uwsgi-1.9.12/plugins/mono/uwsgi.dll needs to be copied to /usr/lib/uwsgi/uwsgi.dll I don't know how to do that in a good way. also each vasal needs mono-assembly = /usr/lib/uwsgi/uwsgi.dll env = MONO_PATH=/usr/lib/uwsgi/ which is.. not the way it's supposed to be the uwsgi.dll doesn't exist in ${T} is there a ${W} ? seeing the ebuild python is embedded into uwsgi and it shouldn't. from the uwsgi docs each plugin should be packaged seperately I agree. However I don't know how this would fit into the portage tree and if it should. uwsgi-plugins/python uwsgi-plugins/perl uwsgi-plugins/php uwsgi-plugins/mono uwsgi-plugins/java uwsgi-plugins/v8 uwsgi-plugins/... maybe? or www-servers/uwsgi www-servers/uwsgi-plugin-python www-servers/uwsgi-plugin-perl www-servers/uwsgi-plugin-php I'll be hacking around, see what I come up with
ok I've fixed the dll issue, more to come. (sorry for spam :D )
Created attachment 351274 [details] fixed uwsgi.dll the dll issue fixed fixes the need to add mono-assembly = /usr/lib/uwsgi/uwsgi.dll env = MONO_PATH=/usr/lib/uwsgi/ to each vasall's config (at least on my local system) now there's a .key file generated and I don't know what to do with it. also the configuration file has changed from 1.4.x that this 1.9.6 ebuild was based on so I took the config from buildconf/base.ini python is still embedded but it's some progress.
Created attachment 351276 [details] updated embedded_plugins what a mess for now let's leave it at it this should work I'll start over and create a fresh ebuild for core and each plugin this should be interesting
(In reply to Darko Luketic from comment #6) > Created attachment 351276 [details] > updated embedded_plugins > > what a mess > > for now let's leave it at it > > this should work > > I'll start over and create a fresh ebuild for core and each plugin > this should be interesting Please don't. ultrabug and I talked about it and we decided against one ebuild per uwsgi-plugin since we can solve this with USE flags on Gentoo. And no, the python plugin is not embedded but built as a true plugin (you have to specify "plugins = python2.7" to load python 2.7 support for example). Although we're going to introduce two USE_EXPAND variables (UWSGI_PLUGINS and UWSGI_PLUGINS_LANGUAGE) to group together different USE flags.
Created attachment 351288 [details] Current work-in-progress ebuild for uwsgi-1.9.11+ Attaching the current ebuild wip for comments.
See: http://thread.gmane.org/gmane.linux.gentoo.devel/85963 Also, one ebuild per plugin is the proper way, especially if the build system supports that. USE flags *are* messy, and require needless rebuilds.
(In reply to Michał Górny from comment #9) > See: http://thread.gmane.org/gmane.linux.gentoo.devel/85963 Agreed, we need proper per-ebuild USE_EXPAND support so people can group and document USE flags properly (because that's what devs obviously want). For example: IUSE="regular_flag language_plugins: php ruby python other_plugins: foo bar baz" metadata.xml: <use> <expand name="other_plugins> <flag name="foo">enable foo</flag> </expand> </use> see also bug #431408 > Also, one ebuild per plugin is the proper way, especially if the build > system supports that. USE flags *are* messy, and require needless rebuilds. For some plugins (like the language/request plugins, especially python, ruby, php) it may make sense since they can never be built into uwsgi due to symbol-clashes. For a lot of other plugins (like the emperor, logging, etc.) it doesn't: a) they are perfectly in sync with upstream version b) without yet another eclass the ebuild will be longer than the actual source for some plugins c) plugins may be built-in instead of built as a shared-library. This may have some advantage or not, depending on the use case. By separating all plugins into their own ebuilds you deny the user that feature. d) even for plugins not requiring external deps it makes sense to give the user the possibility to enable/disable it I can elaborate on all points (or add more), if needed.
(In reply to Tiziano Müller from comment #10) > (In reply to Michał Górny from comment #9) > > See: http://thread.gmane.org/gmane.linux.gentoo.devel/85963 > > Agreed, we need proper per-ebuild USE_EXPAND support so people can group and > document USE flags properly (because that's what devs obviously want). Do users need that? Do users want that? Dev is a worker, user is the client. There's no point in inventing something that's harder to use just for the sake of it. And yes, USE_EXPANDs, especially local ones, are harder to use than plain USE flags. > For example: > > IUSE="regular_flag language_plugins: php ruby python other_plugins: foo bar > baz" language_plugins? We have global USE=php ruby python... why do you believe this package is so special user has to spell 'i want python' twice? Let me guess, global USE=ssl is ignored as well in favor of a custom flag? > > Also, one ebuild per plugin is the proper way, especially if the build > > system supports that. USE flags *are* messy, and require needless rebuilds. > > For a lot of other plugins (like the emperor, logging, etc.) it doesn't: > > a) they are perfectly in sync with upstream version Ok, that's a good point. There's one more thing. Think twice before putting something behind a USE flag. USE flags are supposed to control things that user 'may reasonably want to select'. That is, if some plugin doesn't introduce deps, is small, doesn't conflict with anything and most users want it or don't care, it should be built unconditionally. Or with USE=-minimal, if you really believe in needless choice.
(In reply to Michał Górny from comment #11) > (In reply to Tiziano Müller from comment #10) > > (In reply to Michał Górny from comment #9) > > > See: http://thread.gmane.org/gmane.linux.gentoo.devel/85963 > > > > Agreed, we need proper per-ebuild USE_EXPAND support so people can group and > > document USE flags properly (because that's what devs obviously want). > > Do users need that? Do users want that? Dev is a worker, user is the client. > There's no point in inventing something that's harder to use just for the > sake of it. And yes, USE_EXPANDs, especially local ones, are harder to use > than plain USE flags. Yes and yes (luckily I am a user of it as well). For a package like uwsgi we can enable zeromq for at least two different kind of things, same goes for mongodb. Being able to say "www-server/uwsgi logging-plugin: zeromq config-plugin: zeromq" would be nice (and there may be a USE case where you in fact want to enable one and disable the other). I could also use "mongodb_config mongodb_logging zeromq_config zeromq_logging" instead, but how is suffix/prefix'ing anything different from using USE_EXPANDs besides that it is currently cumbersome to specify per-package USE_EXPANDs for devs (bugs #431408, #133327) and users (bug #471776) alike. > > For example: > > > > IUSE="regular_flag language_plugins: php ruby python other_plugins: foo bar > > baz" > > language_plugins? We have global USE=php ruby python... why do you believe > this package is so special user has to spell 'i want python' twice? again I agree that this is debatable and may be overengineered. The ebuild attached is a WiP. > Let me > guess, global USE=ssl is ignored as well in favor of a custom flag? No, since ssl is implemented in the uwsgi core. > > > > Also, one ebuild per plugin is the proper way, especially if the build > > > system supports that. USE flags *are* messy, and require needless rebuilds. > > > > For a lot of other plugins (like the emperor, logging, etc.) it doesn't: > > > > a) they are perfectly in sync with upstream version > > Ok, that's a good point. > > There's one more thing. Think twice before putting something behind a USE > flag. USE flags are supposed to control things that user 'may reasonably > want to select'. > > That is, if some plugin doesn't introduce deps, is small, doesn't conflict > with anything and most users want it or don't care, it should be built > unconditionally. Unfortunately not in this case: look at the early-emperor mode, here you can give a user easy access to his configuration. As a carrier you want to be able to control the feature a user has access to since if the user can manage his own configuration to some extent he can also make use of features available. Features you may or may not have tested and may or may not work. Nevertheless, if I setup uwsgi for a customer I have to support him based on the enabled features. Other distros follow upstreams recommendation and build everything as separate packages making it possible to install only what you want and thus artificially limit the features a customer can use. We have USE flags for that. Also, from a security perspective you most probably want to enable only what you need to keep the number of possible attack vectors at a minimum. To keep it simple for the user we are going to use USE-defaults to enable the same set of plugins which are enabled now. Besides, being able to build-in plugins as much as possible is handy when operating with chroots.
Thank you Tiziano & Michał for discussing this matter. As dev-zero pointed out, we've been discussing this change for quite some time. (In reply to Tiziano Müller from comment #12) > (In reply to Michał Górny from comment #11) > > (In reply to Tiziano Müller from comment #10) > > language_plugins? We have global USE=php ruby python... why do you believe > > this package is so special user has to spell 'i want python' twice? > > again I agree that this is debatable and may be overengineered. The ebuild > attached is a WiP. I agree this is a debatable point we could bend over for users sake (I'm one of those users as well in production) As for the rest, I stand by our points with dev-zero and thank him again for being lead on this move.
No pressure but when can we expect something that works? (the wip doesn't) This is a roadblock for me right now as I can't continue to write the management/configuration software without knowing what it will be like in the end and having something to work and test with. Mainly because I'm not an expert on uwsgi and I need to play around with it to find a good layout for a shared hosting environment. Will the init script and base config remain the same?
(In reply to Darko Luketic from comment #14) > No pressure but when can we expect something that works? (the wip doesn't) I'm working on it and hope to be able to commit something which works this weekend. > This is a roadblock for me right now as I can't continue to write the > management/configuration software without knowing what it will be like in > the end and having something to work and test with. Mainly because I'm not > an expert on uwsgi and I need to play around with it to find a good layout > for a shared hosting environment. > > Will the init script and base config remain the same? I don't plan to change anything with regard to the init.d-script except perhaps some more fixes to the dreaded uwsgi-directory permission problem which is still not completely solved :( What changes is that you may have to pass additional "--plugins foo" options to the master process and/or the worker process based on the features you want to use. But since I also want to add a USE flag which permits to build-in non-language plugins setting this flag will make the build behave the same as today.
(In reply to Tiziano Müller from comment #15) > (In reply to Darko Luketic from comment #14) > > No pressure but when can we expect something that works? (the wip doesn't) > > I'm working on it and hope to be able to commit something which works this > weekend. > Ok man, cool. Take your time. > > This is a roadblock for me right now as I can't continue to write the > > management/configuration software without knowing what it will be like in > > the end and having something to work and test with. Mainly because I'm not > > an expert on uwsgi and I need to play around with it to find a good layout > > for a shared hosting environment. > > > > Will the init script and base config remain the same? > > I don't plan to change anything with regard to the init.d-script except > perhaps some more fixes to the dreaded uwsgi-directory permission problem > which is still not completely solved :( Hmm, I don't know what you're talking about. I've noticed when the emperor drops privileges to a vasall process the uwsgi emperor's environment is passed to the vasall. (so if the env is the root's the vasall's env is the root's just without the permissions since it's operating as a different user). Ah yeah I read the docs about emperor mode and tyrant mode. So basically you have to chown the config file for each vasall and run in tyrant mode. But that isn't really your problem imho. I'm not sure if the init script should make the descision for you in which mode to run. I feel like if there are multiple possibilities to run uwsgi the way it's ran should depend on the main configuration file, not the init script. Maybe we can contribute various configuration examples instead of assuming to know what the user wants and providing a default way. I mean how many are there? Emperor, Emperor-Tyrant, Broodlord/Zerg, Single App. With various options for logging or monitoring. Language or app-specific stuff could be posted in the wiki. > What changes is that you may have to pass additional "--plugins foo" options > to the master process and/or the worker process based on the features you > want to use. Great :) > But since I also want to add a USE flag which permits to build-in > non-language plugins setting this flag will make the build behave the same > as today.
(In reply to Tiziano Müller from comment #15) > (In reply to Darko Luketic from comment #14) > I don't plan to change anything with regard to the init.d-script except > perhaps some more fixes to the dreaded uwsgi-directory permission problem > which is still not completely solved :( I've also a note about the init script : checkpath should chmod 775 to respect cases where the uwsgi user is coexisting with another (nginx for example), else we should propose a config var in the confd
(In reply to Ultrabug from comment #17) > (In reply to Tiziano Müller from comment #15) > > (In reply to Darko Luketic from comment #14) > > I don't plan to change anything with regard to the init.d-script except > > perhaps some more fixes to the dreaded uwsgi-directory permission problem > > which is still not completely solved :( > > I've also a note about the init script : checkpath should chmod 775 to > respect cases where the uwsgi user is coexisting with another (nginx for > example), else we should propose a config var in the confd Exactly, that's the change we currently have to apply in our environment.
Sorry for the huge delay. In the meantime I bumped uwsgi (LTS) to 1.4.10 and added php-5.5 support there.
For reference to people following this bug, big commit today. We will hopefully soon address the mono support part now that we've cleared and cleaned this package with @dev-zero. +*uwsgi-2.0 (16 Jan 2014) + + 16 Jan 2014; Ultrabug <ultrabug@gentoo.org> -uwsgi-1.0.2.1.ebuild, + -uwsgi-1.2.6.ebuild, -uwsgi-1.9.6.ebuild, +uwsgi-2.0.ebuild, + -files/1.2.6-fixed-typecasting.patch, -files/uwsgi-1.0.2.1-no-werror.patch, + +files/gentoo.buildconf, -files/uwsgi.confd, -files/uwsgi.initd, + metadata.xml: + version bump introducing UWSGI_PLUGINS USE_EXPAND with help of @dev-zero fix + #497534 #497364 #488398 #484366 #469098 #469536, drop obsolete versions, + cleanup +
mono support was added in 2.0-r2
