Hi Graham, 

Do you need me to send you any of those files to have a better look ? 

Regards,
Alex

On Friday, March 6, 2015 at 1:56:32 PM UTC+2, [email protected] wrote:
>
> Disabling the specific lines as you suggested worked i was able to compile 
> it. 
>
> Also i performed the grep 
>
>
> oracle@serpa:[/opt/webtier/Middleware]#/usr/sfw/bin/ggrep -r 
> HAVE_SYS_PRCTL_H *                          
> Oracle_WT1/ohs/include/ap_config_auto.h:/* #undef HAVE_SYS_PRCTL_H */
> Oracle_WT1/ohs/include/ap_config_auto.h:#define HAVE_SYS_PRCTL_H 1
> oracle@serpa:[/opt/webtier/Middleware]#
>
>
>
>
> On Friday, March 6, 2015 at 1:35:16 PM UTC+2, Graham Dumpleton wrote:
>>
>> Looks like it is Apache that might have the wrong definition for that 
>> symbol.
>>
>> For example on MacOS X:
>>
>> $ grep HAVE_SYS_PRCTL_H /usr/include/apache2/*.h
>> /usr/include/apache2/ap_config_auto.h:/* #undef HAVE_SYS_PRCTL_H */
>>
>> I suspect the header file is only meant to exist on Linux. So may not 
>> relate to OS version.
>>
>> If you can find where the Apache header files are installed and grep for 
>> that name and see whether has #define or whether is a comment out #undef, 
>> would tell you whether that is the origin.
>>
>> Graham
>>
>> On 06/03/2015, at 10:30 PM, Graham Dumpleton <[email protected]> 
>> wrote:
>>
>> If you are getting:
>>
>>     "src/server/mod_wsgi.c", line 25: cannot find include file: 
>> <sys/prctl.h>
>>
>> there is something broken with your Apache installation, or maybe Python 
>> installation.
>>
>> That would only be included if either Apache or Python said that header 
>> file existed.
>>
>> #ifdef HAVE_SYS_PRCTL_H
>> #include <sys/prctl.h>
>> #endif
>>
>> What might be the issue is that either Apache or Python was originally 
>> built on an older OS revision where that header file existed but your newer 
>> system doesn't have it.
>>
>> I would suggest editing mod_wsgi.c file and change and disable the use of 
>> those lines:
>>
>> #if 0
>> #ifdef HAVE_SYS_PRCTL_H
>> #include <sys/prctl.h>
>> #endif
>> #endif
>>
>> Graham
>>
>> On 06/03/2015, at 9:55 PM, [email protected] wrote:
>>
>> oracle@serpa:[/opt/media/mod_wsgi-4.4.9]#./configure 
>> --with-apxs=/opt/webtier/Middleware/Oracle_WT1/ohs/bin/apxs 
>> --with-python=/opt/webtier/python_64/bin/python
>> apxs:Error: Invalid query string `LIBTOOL'
>> checking for gcc... gcc
>> checking whether the C compiler works... yes
>> checking for C compiler default output file name... a.out
>> checking for suffix of executables... 
>> checking whether we are cross compiling... no
>> checking for suffix of object files... o
>> checking whether we are using the GNU C compiler... yes
>> checking whether gcc accepts -g... yes
>> checking for gcc option to accept ISO C89... none needed
>> checking for prctl... no
>> checking Apache version... 2.2.22
>> configure: creating ./config.status
>> config.status: creating Makefile
>>  
>> oracle@serpa:[/opt/media/mod_wsgi-4.4.9]#LD_RUN_PATH=/opt/webtier/python_64/lib
>>  
>> make
>> /opt/webtier/Middleware/Oracle_WT1/ohs/bin/apxs -c 
>> -I/opt/webtier/python_64/include/python2.6 -DNDEBUG -Wc,-g -Wc,-O2 
>> src/server/mod_wsgi.c src/server/wsgi_*.c -L/opt/webtier/python_64/lib 
>> -L/opt/webtier/python_64/lib/python2.6/config -lpython2.6 -lsocket -lnsl 
>> -lrt -ldl -lm
>> /opt/webtier/Middleware/Oracle_WT1/ohs/build/libtool --tag=CC 
>> --mode=compile cc -O    -DNO_RC2 -DNO_RC5 -DNO_IDEA -DBSAFE -fPIC -m64  
>> -DLINUX=260 -DMOD_SSL=206104 -DMOD_PERL -DUSE_PERL_SSI -I/include -DEAPI  
>> -D_LARGEFILE64_SOURCE -DUSE_EXPAT -I../lib/expat-lite 
>> -I/opt/webtier/Middleware/Oracle_WT1/ohs/include  
>> -I/opt/webtier/Middleware/Oracle_WT1/ohs/include   
>> -I/opt/webtier/Middleware/Oracle_WT1/ohs/include  -g -O2 
>> -I/opt/webtier/python_64/include/python2.6 -DNDEBUG  -c -o 
>> src/server/mod_wsgi.lo src/server/mod_wsgi.c && touch 
>> src/server/mod_wsgi.slo
>> mkdir src/server/.libs
>>  cc -O -DNO_RC2 -DNO_RC5 -DNO_IDEA -DBSAFE -fPIC -m64 -DLINUX=260 
>> -DMOD_SSL=206104 -DMOD_PERL -DUSE_PERL_SSI -I/include -DEAPI 
>> -D_LARGEFILE64_SOURCE -DUSE_EXPAT -I../lib/expat-lite 
>> -I/opt/webtier/Middleware/Oracle_WT1/ohs/include 
>> -I/opt/webtier/Middleware/Oracle_WT1/ohs/include 
>> -I/opt/webtier/Middleware/Oracle_WT1/ohs/include -g -O2 
>> -I/opt/webtier/python_64/include/python2.6 -DNDEBUG -c 
>> src/server/mod_wsgi.c  -KPIC -DPIC -o src/server/.libs/mod_wsgi.o
>> "src/server/mod_wsgi.c", line 25: cannot find include file: <sys/prctl.h>
>> "src/server/mod_wsgi.c", line 8357: warning: statement not reached
>> "src/server/mod_wsgi.c", line 8540: warning: statement not reached
>> "src/server/mod_wsgi.c", line 10364: warning: statement not reached
>> cc: acomp failed for src/server/mod_wsgi.c
>> apxs:Error: Command failed with rc=65536
>> .
>> *** Error code 1
>> make: Fatal error: Command failed for target `src/server/mod_wsgi.la'
>> oracle@serpa:[/opt/media/mod_wsgi-4.4.9]#
>>
>>
>>
>>
>>
>> On Friday, March 6, 2015 at 12:45:18 PM UTC+2, Graham Dumpleton wrote:
>>>
>>>
>>> On 06/03/2015, at 9:20 PM, [email protected] wrote:
>>>
>>> Sorry Graham my mistake the mod_wsgi i am using is 3.2 which i had to 
>>> compile myself, i downloaded the source code and did the compile. I am on a 
>>> Solaris 10 and for web server i am using Oracle OHS (Oracle HTTP Server). 
>>>
>>> The problem is that i am having issues with compiling the latest version 
>>> of mod_wsgi in my solaris. 
>>>
>>> Can you help me with that ?? 
>>>
>>>
>>> Sure, what is the specific problem/error with the very latest mod_wsgi 
>>> version?
>>>
>>> Graham
>>>
>>> On Friday, March 6, 2015 at 12:09:47 PM UTC+2, Graham Dumpleton wrote:
>>>>
>>>> Do you really mean 3.1.2, or perhaps 3.1 where some OS distribution is 
>>>> tagging on a '-2' qualifier?
>>>>
>>>> Although there was a version 3.1, there never was a 3.1.2 as I only 
>>>> started using 3 part version numbers with 4.1.0.
>>>>
>>>> If it is 3.1, which if it is Oracle Linux I wouldn't be surprised, then 
>>>> it was released 4 1/2 years ago and is way out of date.
>>>>
>>>> Is there any chance at all you can upgrade to a recent version of 
>>>> mod_wsgi by compiling from mod_wsgi source code yourself?
>>>>
>>>> In using such an old version of mod_wsgi I am not sure there is much I 
>>>> can do to help you. If it is an issue which was since fixed, you wouldn't 
>>>> have much choice but to upgrade anyway.
>>>>
>>>> Graham
>>>>
>>>> On 06/03/2015, at 2:02 AM, [email protected] wrote:
>>>>
>>>> Server version: Oracle-HTTP-Server/2.2.22 
>>>>
>>>> mod_wsgi: 3.1.2 
>>>>
>>>> Can this be the cause of the DB errors i am getting i.e. the process is 
>>>> crashing and with it together the DB connection ???? 
>>>>
>>>> Regards,
>>>> Alex
>>>>
>>>>
>>>>
>>>> On Thursday, March 5, 2015 at 12:46:23 PM UTC+2, Graham Dumpleton wrote:
>>>>>
>>>>> What version of mod_wsgi are you using?
>>>>>
>>>>> What patch level revision of Apache are you using?
>>>>>
>>>>> The crash of first daemon process instance but not subsequent ones 
>>>>> sounds a bit like a bug I fixed not long back.
>>>>>
>>>>> I can't right now remember what the issue was and can't find any note 
>>>>> about it in release notes for 4.4.X versions.
>>>>>
>>>>> Graham
>>>>>
>>>>> On 04/03/2015, at 10:47 PM, [email protected] wrote:
>>>>>
>>>>> Shouldn't  this cause a core dump ?? Because i can not find any in 
>>>>> order to analyze it.... 
>>>>>
>>>>> On Wednesday, March 4, 2015 at 1:36:45 PM UTC+2, alexandros...@
>>>>> gmail.com wrote:
>>>>>>
>>>>>> Yes i tried it and the same thing happens: 
>>>>>>
>>>>>> [Wed Mar 04 13:31:53 2015] [notice] child pid 10101 exit signal 
>>>>>> Segmentation fault (11)
>>>>>> [Wed Mar 04 13:31:54 2015] [debug] proxy_util.c(1818): proxy: grabbed 
>>>>>> scoreboard slot 0 in child 10148 for worker proxy:reverse
>>>>>> [Wed Mar 04 13:31:54 2015] [debug] proxy_util.c(1837): proxy: worker 
>>>>>> proxy:reverse already initialized
>>>>>> [Wed Mar 04 13:31:54 2015] [debug] proxy_util.c(1914): proxy: 
>>>>>> initialized worker 0 in child 10148 for (*) min=0 max=25 smax=25
>>>>>> [Wed Mar 04 13:31:54 2015] [info] mod_wsgi (pid=10148): Initializing 
>>>>>> Python.
>>>>>> [Wed Mar 04 13:31:54 2015] [info] mod_wsgi (pid=10148): Attach 
>>>>>> interpreter ''.
>>>>>>
>>>>>> It crashes the first interpreter and its attaching a new one... 
>>>>>>
>>>>>> On Wednesday, March 4, 2015 at 12:42:32 PM UTC+2, Graham Dumpleton 
>>>>>> wrote:
>>>>>>>
>>>>>>> Are you setting:
>>>>>>>
>>>>>>> WSGIApplicationGroup %{GLOBAL}
>>>>>>>
>>>>>>> directive.
>>>>>>>
>>>>>>>
>>>>>>> http://code.google.com/p/modwsgi/wiki/ApplicationIssues#Python_Simplified_GIL_State_API
>>>>>>>
>>>>>>> That is often a good remedy for process crashes when using Python 
>>>>>>> third party extensions modules which aren't implemented properly to 
>>>>>>> work in 
>>>>>>> sub interpreters.
>>>>>>>
>>>>>>> Graham
>>>>>>>
>>>>>>> On 04/03/2015, at 9:25 PM, [email protected] wrote:
>>>>>>>
>>>>>>> Also from the logs its seems that there are some  Segmentation faults
>>>>>>>
>>>>>>> mod_wsgi (pid=9760): Create interpreter 
>>>>>>> ........
>>>>>>>
>>>>>>> child pid 9760 exit signal Segmentation fault (11)
>>>>>>>
>>>>>>> Is this normal ??? 
>>>>>>>
>>>>>>> On Monday, March 2, 2015 at 12:39:02 PM UTC+2, alexandros...@
>>>>>>> gmail.com wrote:
>>>>>>>>
>>>>>>>> Hi Graham, 
>>>>>>>>
>>>>>>>> In my project i already have *DEBUG = True* which i think it 
>>>>>>>> overwrites global settings. 
>>>>>>>>
>>>>>>>> Is DEBUG = True enough to force Django to log details of unhanded 
>>>>>>>> exceptions?? Or should i do anything else? 
>>>>>>>>
>>>>>>>> I already have print outs of os.environ and i have checked that 
>>>>>>>> ORACLE_HOME and TNS_ADMIN is set to the correct paths , i think that 
>>>>>>>> those 
>>>>>>>> are the only 2 variables needed for ORACLE... If i am wrong please 
>>>>>>>> correct 
>>>>>>>> me. 
>>>>>>>>
>>>>>>>> I do not know what else should i do in order to get to log all the 
>>>>>>>> exceptions in the logs.... 
>>>>>>>>
>>>>>>>> But i think this is like the other case you help me solve with 
>>>>>>>> "hashlib"... The true problem/exception was never logged, until you 
>>>>>>>> told me 
>>>>>>>> to try to import _hashlib instead of hashlib. THEN AND OLNY then the 
>>>>>>>> problem was clear and i was able to fix it. I think that the same 
>>>>>>>> circumstances apply here... Somehow i am not getting the real issue... 
>>>>>>>>
>>>>>>>> Regards,
>>>>>>>> Alex
>>>>>>>>
>>>>>>>> On Friday, February 27, 2015 at 11:47:28 PM UTC+2, Graham Dumpleton 
>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>> If this is only the latter consequence, then have you got Django 
>>>>>>>>> setup to send you details of unhanded exceptions in emails or 
>>>>>>>>> otherwise log 
>>>>>>>>> them. If you don't then Django will simply translate an error into a 
>>>>>>>>> generic 500 response page and you will not see the error anywhere.
>>>>>>>>>
>>>>>>>>> If you are on a development system, you can alternatively enable 
>>>>>>>>> temporarily in the Django settings file:
>>>>>>>>>
>>>>>>>>> DEBUG = True
>>>>>>>>>
>>>>>>>>> and if it was creating a 500 page then it will then include the 
>>>>>>>>> exception details that caused it.
>>>>>>>>>
>>>>>>>>> BTW other possible problems with Oracle specifically are missing 
>>>>>>>>> ORACLE_??? environment variables set in environment of Apache.
>>>>>>>>>
>>>>>>>>> If you add debug statements in WSGI script file to print out 
>>>>>>>>> contents of os.environ from 'os' module, dod you see all the 
>>>>>>>>> ORACLE_?? 
>>>>>>>>> environment variables you expect to see that might be set in the 
>>>>>>>>> shell of 
>>>>>>>>> your user environment.
>>>>>>>>>
>>>>>>>>> Graham
>>>>>>>>>
>>>>>>>>> On 28/02/2015, at 8:40 AM, [email protected] wrote:
>>>>>>>>>
>>>>>>>>> Hi Graham,
>>>>>>>>>
>>>>>>>>> Can you elaborate more on this... Based on the Django project i 
>>>>>>>>> have created, in the settings for the Oracle DB i have provided the 
>>>>>>>>> user 
>>>>>>>>> (db schema) the application should use to connect to the db. 
>>>>>>>>>
>>>>>>>>> I have not changed anything since i migrated the project to the 
>>>>>>>>> new infrastructure and the project was working fine before. I am on 
>>>>>>>>> the 
>>>>>>>>> same machine i just installed everything again basically..
>>>>>>>>>
>>>>>>>>> I know that somewhere there is an exception occurring, but the 
>>>>>>>>> problem is that it is never caught and printed in the logs.... 
>>>>>>>>>
>>>>>>>>> As you can see in the logs the only errors are when it tries to 
>>>>>>>>> close the connection and most probably never finds one.. either 
>>>>>>>>> because it 
>>>>>>>>> was never created or it is closed before everything else is executed. 
>>>>>>>>>
>>>>>>>>> I want to find a way to debug this ... Is there a way to trace 
>>>>>>>>> each call and every step so i can place some sort of print to see 
>>>>>>>>> where the 
>>>>>>>>> code is not working ... Because i do not know any other way to fix 
>>>>>>>>> this. 
>>>>>>>>>
>>>>>>>>> I another problem i had,  you were the one that suggested  
>>>>>>>>> something that relieved the actual problem and i was able to fix it, 
>>>>>>>>> because before that the only errors in the logs i was seeing were not 
>>>>>>>>> relevant to the problem. 
>>>>>>>>>
>>>>>>>>> Thanks
>>>>>>>>>
>>>>>>>>> On Thursday, February 26, 2015 at 11:42:26 AM UTC+2, Graham 
>>>>>>>>> Dumpleton wrote:
>>>>>>>>>>
>>>>>>>>>> If Oracle is providing access based on the identity of the user 
>>>>>>>>>> connecting though local UNIX socket connection to the database, it 
>>>>>>>>>> could be 
>>>>>>>>>> failing because your application will be running as the Apache user 
>>>>>>>>>> and 
>>>>>>>>>> maybe you haven't configured Oracle to allow that user to connect.
>>>>>>>>>>
>>>>>>>>>> Graham
>>>>>>>>>>
>>>>>>>>>> On 25/02/2015, at 10:09 PM, [email protected] wrote:
>>>>>>>>>>
>>>>>>>>>> Hi, 
>>>>>>>>>>
>>>>>>>>>> I migrated my project to a new infrastructure but i kept the same 
>>>>>>>>>> versions Apache 2.2 + mod_wsgi + python 2.6.1 + Django 1.2.1 + 
>>>>>>>>>> ....... 
>>>>>>>>>>
>>>>>>>>>> I am trying to run my project or even access the admin console of 
>>>>>>>>>> Django /admin and i can not.
>>>>>>>>>>
>>>>>>>>>> I tried to connect directly from the Oracle Client (sqlplus) and 
>>>>>>>>>> i can, i created a simple python script that uses cx_oracle and i am 
>>>>>>>>>> able 
>>>>>>>>>> to connect to the database without any problems, i have tested 
>>>>>>>>>> "python 
>>>>>>>>>> manage.py dbshell" and it connects. I also used "python manage.py 
>>>>>>>>>> runserver" and by navigating to http://127.0.0.1:8000/admin i 
>>>>>>>>>> was able to access the console without any errors,  but when i try 
>>>>>>>>>> using 
>>>>>>>>>> apache + mod_wsgi i get the following error:   
>>>>>>>>>>
>>>>>>>>>> [Fri Feb 20 17:40:51 2015] [error] [client xx.xx.xx.xx] mod_wsgi 
>>>>>>>>>> (pid=27565): Exception occurred processing WSGI script 
>>>>>>>>>> '/opt/wgt_proxy/wgtproxyProj/
>>>>>>>>>> wgtproxy/apache/django.wsgi'.
>>>>>>>>>> [Fri Feb 20 17:40:51 2015] [error] [client xx.xx.xx.xx] Traceback 
>>>>>>>>>> (most recent call last):
>>>>>>>>>> [Fri Feb 20 17:40:51 2015] [error] [client xx.xx.xx.xx]   File 
>>>>>>>>>> "/opt/wgt_proxy/wgtproxyProj/wgtproxy/apache/django.wsgi", line 50, 
>>>>>>>>>> in 
>>>>>>>>>> __call__
>>>>>>>>>> [Fri Feb 20 17:40:51 2015] [error] [client xx.xx.xx.xx]     
>>>>>>>>>> return self.__application(environ, _start_response)
>>>>>>>>>> [Fri Feb 20 17:40:51 2015] [error] [client xx.xx.xx.xx]   File 
>>>>>>>>>> "/opt/webtier/python_64/lib/python2.6/site-packages/django/core/handlers/wsgi.py",
>>>>>>>>>>  
>>>>>>>>>> line 248, in __call__
>>>>>>>>>> [Fri Feb 20 17:40:51 2015] [error] [client xx.xx.xx.xx]     
>>>>>>>>>> signals.request_finished.send(sender=self.__class__)
>>>>>>>>>> [Fri Feb 20 17:40:51 2015] [error] [client xx.xx.xx.xx]   File 
>>>>>>>>>> "/opt/webtier/python_64/lib/python2.6/site-packages/django/dispatch/dispatcher.py",
>>>>>>>>>>  
>>>>>>>>>> line 162, in send
>>>>>>>>>> [Fri Feb 20 17:40:51 2015] [error] [client xx.xx.xx.xx]     
>>>>>>>>>> response = receiver(signal=self, sender=sender, **named)
>>>>>>>>>> [Fri Feb 20 17:40:51 2015] [error] [client xx.xx.xx.xx]   File 
>>>>>>>>>> "/opt/webtier/python_64/lib/python2.6/site-packages/django/db/__init__.py",
>>>>>>>>>>  
>>>>>>>>>> line 82, in close_connection
>>>>>>>>>> [Fri Feb 20 17:40:51 2015] [error] [client xx.xx.xx.xx]     
>>>>>>>>>> conn.close()
>>>>>>>>>> [Fri Feb 20 17:40:51 2015] [error] [client xx.xx.xx.xx]   File 
>>>>>>>>>> "/opt/webtier/python_64/lib/python2.6/site-packages/django/db/backends/__init__.py",
>>>>>>>>>>  
>>>>>>>>>> line 70, in close
>>>>>>>>>> [Fri Feb 20 17:40:51 2015] [error] [client xx.xx.xx.xx]     
>>>>>>>>>> self.connection.close()
>>>>>>>>>> [Fri Feb 20 17:40:51 2015] [error] [client xx.xx.xx.xx] 
>>>>>>>>>> OperationalError: ORA-03114: not connected to ORACLE
>>>>>>>>>> [Fri Feb 20 17:40:51 2015] [error] [client xx.xx.xx.xx] 
>>>>>>>>>> [Fri Feb 20 17:40:51 2015] [error] [client xx.xx.xx.xx] Request 
>>>>>>>>>> Failed for : /wgtproxy/admin/, Resp Code : [500]
>>>>>>>>>>
>>>>>>>>>> Can anyone help me solve my issue?
>>>>>>>>>>
>>>>>>>>>> Thanks
>>>>>>>>>>
>>>>>>>>>> -- 
>>>>>>>>>> You received this message because you are subscribed to the 
>>>>>>>>>> Google Groups "modwsgi" group.
>>>>>>>>>> To unsubscribe from this group and stop receiving emails from it, 
>>>>>>>>>> send an email to [email protected].
>>>>>>>>>> To post to this group, send email to [email protected].
>>>>>>>>>> Visit this group at http://groups.google.com/group/modwsgi.
>>>>>>>>>> For more options, visit https://groups.google.com/d/optout.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>> -- 
>>>>>>>>> You received this message because you are subscribed to the Google 
>>>>>>>>> Groups "modwsgi" group.
>>>>>>>>> To unsubscribe from this group and stop receiving emails from it, 
>>>>>>>>> send an email to [email protected].
>>>>>>>>> To post to this group, send email to [email protected].
>>>>>>>>> Visit this group at http://groups.google.com/group/modwsgi.
>>>>>>>>> For more options, visit https://groups.google.com/d/optout.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>> -- 
>>>>>>> You received this message because you are subscribed to the Google 
>>>>>>> Groups "modwsgi" group.
>>>>>>> To unsubscribe from this group and stop receiving emails from it, 
>>>>>>> send an email to [email protected].
>>>>>>> To post to this group, send email to [email protected].
>>>>>>> Visit this group at http://groups.google.com/group/modwsgi.
>>>>>>> For more options, visit https://groups.google.com/d/optout.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>> -- 
>>>>> You received this message because you are subscribed to the Google 
>>>>> Groups "modwsgi" group.
>>>>> To unsubscribe from this group and stop receiving emails from it, send 
>>>>> an email to [email protected].
>>>>> To post to this group, send email to [email protected].
>>>>> Visit this group at http://groups.google.com/group/modwsgi.
>>>>> For more options, visit https://groups.google.com/d/optout.
>>>>>
>>>>>
>>>>>
>>>> -- 
>>>> You received this message because you are subscribed to the Google 
>>>> Groups "modwsgi" group.
>>>> To unsubscribe from this group and stop receiving emails from it, send 
>>>> an email to [email protected].
>>>> To post to this group, send email to [email protected].
>>>> Visit this group at http://groups.google.com/group/modwsgi.
>>>> For more options, visit https://groups.google.com/d/optout.
>>>>
>>>>
>>>>
>>> -- 
>>> You received this message because you are subscribed to the Google 
>>> Groups "modwsgi" group.
>>> To unsubscribe from this group and stop receiving emails from it, send 
>>> an email to [email protected].
>>> To post to this group, send email to [email protected].
>>> Visit this group at http://groups.google.com/group/modwsgi.
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>>
>>>
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "modwsgi" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to [email protected].
>> To post to this group, send email to [email protected].
>> Visit this group at http://groups.google.com/group/modwsgi.
>> For more options, visit https://groups.google.com/d/optout.
>>
>>
>>
>>

-- 
You received this message because you are subscribed to the Google Groups 
"modwsgi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/modwsgi.
For more options, visit https://groups.google.com/d/optout.

Reply via email to