| Summary: | www-servers/uwsgi-0.9.6.6 Version bump | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Alexander Soloviëv <no.friday> |
| Component: | New packages | Assignee: | Benedikt Böhm (RETIRED) <hollow> |
| Status: | RESOLVED FIXED | ||
| Severity: | enhancement | CC: | dev-zero, scvalex, skrattaren, torsten |
| Priority: | High | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Attachments: |
ebuild for 0.9.6.5 version
init.d/uwsgi |
||
|
Description
Alexander Soloviëv
2010-11-27 10:55:16 UTC
Created attachment 255563 [details]
ebuild for 0.9.6.5 version
uwsgi-0.9.6 adds support for the --ini-paste paramater which simplifies starting uwsgi significantly. It would be really nice to have. (In reply to comment #1) > Created an attachment (id=255563) [details] > ebuild for 0.9.6.5 version > Ebuild works for me. Cheers. How many years must elapse before this ebuild will be in portage tree? Since 0.9.6.6 is out now, lets include that directly. (In reply to comment #5) > Since 0.9.6.6 is out now, lets include that directly. > ebuild for 0.9.6.6 is the same, just need to be renamed to uwsgi-0.9.6.6.ebuild bumped, but I p.masked it for now since it didn't compile out of the box for me. Can you please test and report back? I also added optional apache mod_uwsgi/Ruwsgi support. @hollow: sorry for stepping on your toes (In reply to comment #7) > bumped, but I p.masked it for now since it didn't compile out of the box for > me. This is because the gcc version is being determined in a very ugly fashion during build in the file uwsgiconfig.py (line 88). A quick fix is to change the index of the last .split in that line from [4] to [1]. A much better way would be to search the last line of 'gcc -v' for a version number string (i.e. major.minor.patchlevel) via regex. Unfortunately, I don't have time yet to do a proper patch. Perhaps someone else would be willing? ;-) Best regards, Torsten (In reply to comment #8) > (In reply to comment #7) > > bumped, but I p.masked it for now since it didn't compile out of the box for > > me. > > This is because the gcc version is being determined in a very ugly fashion > during build in the file uwsgiconfig.py (line 88). > > A quick fix is to change the index of the last .split in that line from [4] to > [1]. This is what I did in the version bump. > A much better way would be to search the last line of 'gcc -v' for a > version number string (i.e. major.minor.patchlevel) via regex. Unfortunately, I > don't have time yet to do a proper patch. Perhaps someone else would be > willing? ;-) I guess we have to do this since I guess the current version bump won't compile for people with gcc-4.4 and older. > I guess we have to do this since I guess the current version bump won't compile
> for people with gcc-4.4 and older.
Yes, that is right. But what is the problem? I've checked gcc version strings for 3.4.6 and 4.5.2 and its look like 'gcc version 3.4.6 ...' and 'gcc version 4.5.2 ...'. Post please your version strings.
~ $ gcc --version gcc (Gentoo 4.5.2 p1.0, pie-0.4.5) 4.5.2 Copyright (C) 2010 Free Software Foundation, Inc. Dies ist freie Software; die Kopierbedingungen stehen in den Quellen. Es gibt KEINE Garantie; auch nicht für MARKTGÄNGIGKEIT oder FÜR SPEZIELLE ZWECKE. I guess we should patch it to use '-dumpversion' instead of '-v'. Since the configure core seems to be gcc-specific anyway upstream could accept the patch. ok, that works for me on sparc with gcc-4.4, x86 with gcc-4.1 and amd64 with gcc-4.5.2. Just pushed the patch. A test with gcc-3.x would be appreciated, but give it some time to propagate to the mirrors. works with gcc-3.4.6-r2 x86 Maybe it's time to put it in ~arch? Seems like it does work decently, though my system is quite a common ~amd64-up-to-date one. I agree, only thing I'd like to integrate before unmasking uwsgi is a simple init.d/uwsgi script. Analog to the one from spawn-fcgi (symlinking for different configs), but with only two variables in conf.d/uwsgi: OPTIONS="..." PIDFILE="..." PIDFILE must then match the one given as a commandline option via OPTIONS or in a configuration-file. And OPTIONS is passed to uwsgi. Furthermore I'd like to establish the following directories for uwsgi configuration, log and sockets: /var/run/uwsgi ... sockets and pid-file /var/log/uwsgi ... logfiles /etc/uwsgi ... configurations (if any) Opinions? (In reply to comment #16) > I agree, only thing I'd like to integrate before unmasking uwsgi is a simple > init.d/uwsgi script. > > Analog to the one from spawn-fcgi (symlinking for different configs), but with > only two variables in conf.d/uwsgi: > OPTIONS="..." > PIDFILE="..." > > PIDFILE must then match the one given as a commandline option via OPTIONS or in > a configuration-file. And OPTIONS is passed to uwsgi. > > Furthermore I'd like to establish the following directories for uwsgi > configuration, log and sockets: > > /var/run/uwsgi ... sockets and pid-file > /var/log/uwsgi ... logfiles > /etc/uwsgi ... configurations (if any) > > Opinions? > There's https://bugs.gentoo.org/show_bug.cgi?id=340058 concerning this issue. As usage of uwsgi suggest using a signle server for each application, net.lo style scripts is more preferable. Below i'm attaching example init sctipt with features:
1. named variables like ${appname}_varname from conf.d/uwsgi for each application. Now supports _options (extra launch options), _binary (binary path for application) and _socket.
2. Common settings for all applications. Now support only default_binary.
3. Daemon settings for application should be provided by one of the uwsgi supported way: via xml file (passed in _options path like -x path), ini file, command line (i.e. via ${appname}_option config string) or others.
4. Use /var/run/uwsgi/ base path for pid files (format ${appname}.pid) and default sockets base path { format ${appname}.socket }
5. Log file is /var/log/uwsgi/${appname}
Created attachment 259620 [details]
init.d/uwsgi
0.9.6.6 is unmasked. init script is tracked in bug #340058 |
