Bug#720571: Please stop using openjdk-6-*
Hi Jonas, On Fri, Sep 13, 2013 at 9:10 PM, Jonas Smedegaard wrote: > Hi Sylvestre, > > Sylvestre wrote: >> As part of the transition to OpenJDK 7 and the removal of OpenJDK 6 >> from the archive, could you update the dependency of your package to >> default-jdk ? > > For uwsgi it seems more sensible to me to continue maintaining versioned > binary packages, as that makes multiple concurrent versions available at > runtime. > > @Janos: What do you think about this? I agree completely. > > > - Jonas > > -- > * Jonas Smedegaard - idealist & Internet-arkitekt > * Tlf.: +45 40843136 Website: http://dr.jones.dk/ > > [x] quote me freely [ ] ask before reusing [ ] keep private -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#720262: do you need help?
Hi Jonas, On Fri, Sep 13, 2013 at 8:03 PM, Jonas Smedegaard wrote: > Quoting Janoš Guljaš (2013-09-12 17:07:44) >> On Thu, Sep 12, 2013 at 12:21 PM, Jonas Smedegaard >> wrote: >> > This bug seems relatively trivial to fix: Conditionally build the >> > java plugin, and mark the corresponding binary package as being not >> > for mips or mipsel. >> > >> > Haven't looked at actual code yet, but can do so if relevant. >> > >> > Do you need help here? >> >> Thank you for offering your help. I would very much appreciate it. I >> have very limited time lately, and any help would be great. >> >> > >> > Would you perhaps be interested in team-maintenance? >> >> Yes I am. I think that uwsgi packaging will benefit from it. > > > Hope you like my changes. I've just checked the changes that you made, and I must say that they are excellent. I would not do them as well. Thank you very much, for resolving the tickets and also updating the upstream release. > > > - Jonas > > -- > * Jonas Smedegaard - idealist & Internet-arkitekt > * Tlf.: +45 40843136 Website: http://dr.jones.dk/ > > [x] quote me freely [ ] ask before reusing [ ] keep private Best regards, Janos -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#720262: do you need help?
Hi Jonas, On Thu, Sep 12, 2013 at 12:21 PM, Jonas Smedegaard wrote: > Hi, > > This bug seems relatively trivial to fix: Conditionally build the java > plugin, and mark the corresponding binary package as being not for mips > or mipsel. > > Haven't looked at actual code yet, but can do so if relevant. > > Do you need help here? Thank you for offering your help. I would very much appreciate it. I have very limited time lately, and any help would be great. > > Would you perhaps be interested in team-maintenance? Yes I am. I think that uwsgi packaging will benefit from it. > > > Kind regards, > > - Jonas > > -- > * Jonas Smedegaard - idealist & Internet-arkitekt > * Tlf.: +45 40843136 Website: http://dr.jones.dk/ > > [x] quote me freely [ ] ask before reusing [ ] keep private Best regards, Janos -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#717777: ansible: Upgrade to 1.2.1
Hi Kouhei, Thank you for working and contributing to the ansible packaging. The 1.2.1 release is already in preparation. I checked your release and would you mind if you could incorporate you changes to git repo git://anonscm.debian.org/collab-maint/ansible.git ? That would be very helpful. It appears that the documentation is making more problems to packaging then the application itself. Best regards, Janos On Thu, Jul 25, 2013 at 12:52 AM, Kouhei Maeda wrote: > Package: ansible > Version: 1.1+dfsg-1 > Severity: wishlist > > Dear Maintainer, > > Please upgrade to latest stable version 1.2.1, see > https://github.com/ansible/ansible/tags > > I prepare the source package of ansible (for my own use), > refer this to you if you like. > > http://mentors.debian.net/debian/pool/main/a/ansible/ansible_1.2.1-1.1.dsc > > best regards, > > > -- System Information: > Debian Release: jessie/sid > APT prefers unstable > APT policy: (500, 'unstable') > Architecture: amd64 (x86_64) > Foreign Architectures: i386 > > Kernel: Linux 3.9-1-amd64 (SMP w/8 CPU cores) > Locale: LANG=ja_JP.UTF-8, LC_CTYPE=ja_JP.UTF-8 (charmap=UTF-8) > Shell: /bin/sh linked to /bin/dash > > Versions of packages ansible depends on: > ii python 2.7.5-2 > ii python-jinja22.7-3 > ii python-paramiko 1.10.1-1 > ii python-yaml 3.10-4+b1 > > ansible recommends no packages. > > ansible suggests no packages. > > -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#716879: uwsgi: Gevent plugin/capability is missing
Hi Alexander,
The gevent plugin is not packaged as it requires gevent 1.0.0, but the
latest release in unstable and testing is 0.13.7, and in experimental
1.0 beta1.
I assume that when 1.0 final is available, that it will be uploaded
into unstable and after that gevent plugin will be too. I do not know
when tat will happen as the latest upstrem release is 1.0rc2 from 7
months ago.
Best regards,
Janos
On Sun, Jul 14, 2013 at 1:44 AM, Alexander Myodov wrote:
> Package: uwsgi
> Version: 1.9.13-4
> Severity: normal
>
> Hello,
>
> It seems that gevent plugin/capability (described on
> http://uwsgi-docs.readthedocs.org/en/latest/Gevent.html) is missing from the
> Debian build:
>
>
> /usr/share/doc/uwsgi:$ uwsgi --gevent
> uwsgi: unrecognized option '--gevent'
> getopt_long() error
> 1:/usr/share/doc/uwsgi:$ uwsgi --plugins gevent --gevent 100
> open("/usr/lib/uwsgi/plugins/gevent_plugin.so"): No such file or directory
> [core/utils.c line 3423]
> !!! UNABLE to load uWSGI plugin: /usr/lib/uwsgi/plugins/gevent_plugin.so:
> !!! cannot open shared object file: No such file or directory !!!
> uwsgi: unrecognized option '--gevent'
> getopt_long() error
>
>
> Can you please build it with Gevent? It is a seriously important feature for
> nowadays deployments, and would help to get rid of Gunicorn and use uwsgi
> instead.
>
>
> Thank you in advance,
> Alex Myodov
>
>
> -- System Information:
> Debian Release: jessie/sid
> APT prefers testing
> APT policy: (990, 'testing'), (500, 'stable-updates'), (500, 'stable'),
> (480, 'stable'), (450, 'unstable'), (400, 'experimental')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
>
> Kernel: Linux 3.9-1-amd64 (SMP w/2 CPU cores)
> Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
>
> Versions of packages uwsgi depends on:
> ii initscripts 2.88dsf-41
> ii lsb-base 4.1+Debian12
> ii uwsgi-core 1.9.13-4
>
> Versions of packages uwsgi recommends:
> ii sqlite3 3.7.17-1
>
> uwsgi suggests no packages.
>
> -- no debconf information
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#716009: transifex-client: The package is missing a python-pkg-resources dependency.
Hi Reece, Thanks for a detailed bug report. The issue will be fixed with the next release to unstable. Best regards, Janos On Wed, Jul 10, 2013 at 9:15 PM, Reece H. Dunn wrote: > Package: transifex-client > Version: 0.9-1 > Severity: normal > > Dear Maintainer, > > Installing transifex-client on a bare minimal system resulted in the > following error when running the tx program: > > $ tx > Traceback (most recent call last): > File "/usr/bin/tx", line 9, in > from txclib import utils > File "/usr/lib/python2.7/dist-packages/txclib/utils.py", line 12, in > > from txclib.web import verify_ssl > File "/usr/lib/python2.7/dist-packages/txclib/web.py", line 11, in > > from pkg_resources import resource_filename, resource_string > ImportError: No module named pkg_resources > > This is fixable by running: > > $ sudo apt-get install python-pkg-resources > > A Google search for the error recommended installing python-setuptools, but > only > python-pkg-resources is needed to get it working. > > Therefore, python-pkg-resources should be added to the Depends section of the > debian/control file. > > > -- System Information: > Debian Release: jessie/sid > APT prefers testing > APT policy: (500, 'testing') > Architecture: amd64 (x86_64) > Foreign Architectures: i386 > > Kernel: Linux 3.9-1-amd64 (SMP w/4 CPU cores) > Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) > Shell: /bin/sh linked to /bin/dash > > Versions of packages transifex-client depends on: > ii python 2.7.5-2 > > transifex-client recommends no packages. > > transifex-client suggests no packages. > > -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#709468: closed by Janos Guljas (Bug#709468: fixed in uwsgi 1.2.3+dfsg-6)
Hi, I have uploaded 1.9.13-1 that addresses the transition to apache 2.4. I would not like to make new uploads of 1.2.3 release to unstable and to maintain both 1.2 and 1.9 while waiting for 1.9 release to pass the NEW queue. Hopefully 1.9 will enter unstable soon as there are many other fixes and improvements. Best, Janos On Mon, Jul 8, 2013 at 10:39 AM, Arno Töll wrote: > On 08.07.2013 03:46, Colin Watson wrote: >> I'm afraid this doesn't seem to truly fix this bug. uwsgi still >> Build-Depends on apache2-threaded-dev, which is no longer available with >> Apache 2.4, so this currently fails to build on Ubuntu and will >> eventually either fail to build in unstable or block the removal of the >> old MPM binary packages from unstable. > > It is neither available in Debian unless you consider virtual provides. > Either way the package is already broken and will not work in Unstable > for the state being. > >> I hope this is just a matter of dropping the build-dependency ... > > No, it's not. See #666793. > > > -- > with kind regards, > Arno Töll > IRC: daemonkeeper on Freenode/OFTC > GnuPG Key-ID: 0x9D80F36D > -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#709468: uwsgi: Apache 2.4 moves to Unstable
Hi Arno, The new upstream uwsgi is in the NEW queue for quite some time. I was hopping that it would enter unstable much sooner. I will very soon upload new release 1.2.3+dfsg-6 that will fix this bug too. Best, Janos On Sat, Jul 6, 2013 at 5:00 PM, Arno Töll wrote: > Hi, > > I noticed there is a new version of uwsgi targeting unstable in NEW. > However, it does not fix this bug and I cannot access the source. Could > you therefore please tell me what the state being with uwsgi is and if I > can help you with the transtition? > > -- > with kind regards, > Arno Töll > IRC: daemonkeeper on Freenode/OFTC > GnuPG Key-ID: 0x9D80F36D > -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#711078: python-tidylib: Enable tests during build
Hi Michael, Thank you very much for the patch. It will be included in the next release. Best regards, Janos On Tue, Jun 4, 2013 at 3:45 PM, Michael Terry wrote: > Package: python-tidylib > Version: 0.2.1~dfsg-2 > Severity: wishlist > Tags: patch > User: ubuntu-de...@lists.ubuntu.com > Usertags: origin-ubuntu saucy ubuntu-patch > > Dear Maintainer, > > In Ubuntu, the attached patch was applied to run upstream tests at build > time. Thanks for considering it! > > One thing to note is that the upstream test threadsafety.py does not seem to > actually return an error code if it fails. But the others do. > > -- System Information: > Debian Release: wheezy/sid > APT prefers saucy-updates > APT policy: (500, 'saucy-updates'), (500, 'saucy-security'), (500, 'saucy') > Architecture: amd64 (x86_64) > Foreign Architectures: i386 > > Kernel: Linux 3.9.0-2-generic (SMP w/4 CPU cores) > Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) > Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#711018: seahorse-nautilus: Drop build-depends on libgconf2-dev
Feel free to try to build and test. You can see the actual error during configure related to cryptui requiring gconf-2.0: ... checking for LIBCRYPTUI... no configure: error: Package requirements (cryptui-0.0) were not met: Package gconf-2.0 was not found in the pkg-config search path. Perhaps you should add the directory containing `gconf-2.0.pc' to the PKG_CONFIG_PATH environment variable Package 'gconf-2.0', required by 'cryptui', not found Consider adjusting the PKG_CONFIG_PATH environment variable if you installed software in a non-standard prefix. Alternatively, you may set the environment variables LIBCRYPTUI_CFLAGS and LIBCRYPTUI_LIBS to avoid the need to call pkg-config. See the pkg-config man page for more details. Best, Janos On Mon, Jun 10, 2013 at 5:27 PM, Jeremy Bicha wrote: > On 10 June 2013 10:57, Janoš Guljaš wrote: >> Actually, package 'gconf-2.0' is required by 'cryptui' and configure >> fails without libgconf2-dev. > > I don't think so. According to the git log, seahorse-nautilus switched > from gconf to gsettings with the 3.6 release and it builds fine on > Ubuntu without libgconf2-dev in build-depends. > > It looks like there is a bug in libcryptui-dev where its pkgconfig > erroneously depends on gconf, but the -dev doesn't depend on > libgconf2-dev. > > https://git.gnome.org/browse/libcryptui/commit/?id=dd91525 > > Jeremy -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#711018: seahorse-nautilus: Drop build-depends on libgconf2-dev
Actually, package 'gconf-2.0' is required by 'cryptui' and configure fails without libgconf2-dev. Best regards, Janos On Mon, Jun 10, 2013 at 4:32 PM, Janoš Guljaš wrote: > Hi Jeremy, > > Thanks for suggestions, libgconf2-dev will be dropped, but > libcryptui0a already depends on seahorse-daemon, so there is no need > for seahorse-nautilus to explicitly depend on it. > > Best, > Janos > > On Tue, Jun 4, 2013 at 4:04 AM, Jeremy Bicha wrote: >> Package: seahorse-nautilus >> Version: 3.8.0-1 >> User: ubuntu-de...@lists.ubuntu.com >> Usertags: origin-ubuntu saucy >> >> Here's a few suggestions from the Ubuntu packaging. >> >> Drop libgconf2-dev from build-depends >> Have seahorse-nautilus depend on seahorse-daemon (>= 3.2.2) >> >> Thanks, >> Jeremy >> >> - -- System Information: >> Debian Release: wheezy/sid >> APT prefers saucy-updates >> APT policy: (500, 'saucy-updates'), (500, 'saucy-security'), (500, >> 'raring'), (100, 'saucy-backports') -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#711018: seahorse-nautilus: Drop build-depends on libgconf2-dev
Hi Jeremy, Thanks for suggestions, libgconf2-dev will be dropped, but libcryptui0a already depends on seahorse-daemon, so there is no need for seahorse-nautilus to explicitly depend on it. Best, Janos On Tue, Jun 4, 2013 at 4:04 AM, Jeremy Bicha wrote: > Package: seahorse-nautilus > Version: 3.8.0-1 > User: ubuntu-de...@lists.ubuntu.com > Usertags: origin-ubuntu saucy > > Here's a few suggestions from the Ubuntu packaging. > > Drop libgconf2-dev from build-depends > Have seahorse-nautilus depend on seahorse-daemon (>= 3.2.2) > > Thanks, > Jeremy > > - -- System Information: > Debian Release: wheezy/sid > APT prefers saucy-updates > APT policy: (500, 'saucy-updates'), (500, 'saucy-security'), (500, > 'raring'), (100, 'saucy-backports') -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#698691: please package a new upstream version
Hi Alexander, There is progress, but with the current dependencies in experimental, there are problem building some of the plugins introduced in 1.4.x. If you want, you can use packaging from vcs to build it against the unstable repository (or I can send you compiled packages if you want). I will hopefully upload the latest version to unstable after the Wheezy release. There are new plugins introduced and with that new binary packages need to be built, so the next upload will need to go trough the NEW queue, which is not so short lately. Best, Janos On Thu, Apr 11, 2013 at 4:54 PM, Alexander Myodov wrote: > Package: uwsgi > Version: 1.4.4+dfsg-1 > Followup-For: Bug #698691 > > Hello Janoš, > > Sorry to bother you, but haven't you got a chance to make some progress on > the corerouter_plugin.so issue? 1.4.4 version could be much more usable than > the 1.2.3 one from the testing/unstable, but non-working > corerouter_plugin.so really blocks it. > Also, it seems that gevent plugin is also not packaged, while it could be > heavily useful. > > Good luck! > > -- System Information: > Debian Release: 7.0 > APT prefers testing > APT policy: (990, 'testing'), (500, 'stable-updates'), (500, 'stable'), > (480, 'stable'), (450, 'unstable'), (400, 'experimental') > Architecture: amd64 (x86_64) > Foreign Architectures: i386 > > Kernel: Linux 3.8-trunk-amd64 (SMP w/2 CPU cores) > Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.UTF-8 (charmap=UTF-8) > Shell: /bin/sh linked to /bin/dash > > Versions of packages uwsgi depends on: > ii initscripts 2.88dsf-41 > ii lsb-base 4.1+Debian8 > ii uwsgi-core 1.4.4+dfsg-1 > > Versions of packages uwsgi recommends: > ii sqlite3 3.7.13-1 > > uwsgi suggests no packages. > > -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#698691: corerouter_plugin.so missing
Hi Daniel,
Thanks for reporting this bug.
On Tue, Feb 5, 2013 at 11:28 AM, Daniel Swarbrick
wrote:
> Thanks for packaging 1.4.4, however it appears to be incomplete. Trying
> to load the http plugin reveals missing symbols:
>
> $ uwsgi --plugin http
> open("/usr/lib/uwsgi/plugins/corerouter_plugin.so"): No such file or
> directory [core/utils.c line 4733]
> !!! UNABLE to load uWSGI plugin:
> /usr/lib/uwsgi/plugins/corerouter_plugin.so: cannot open shared object
> file: No such file or directory !!!
> !!! UNABLE to load uWSGI plugin: /usr/lib/uwsgi/plugins/http_plugin.so:
> undefined symbol: uwsgi_opt_corerouter !!!
> *** Starting uWSGI 1.4.4-debian (64bit) on [Tue Feb 5 11:25:56 2013] ***
> compiled with version: 4.7.2 on 27 January 2013 01:48:49
> os: Linux-3.2.0-4-amd64 #1 SMP Debian 3.2.35-2
> ...
>
> The file corerouter_plugin.so is nowhere to be found in the repos.
Because of dependencies on new plugin 'corerouter', plugins http and
fastrouter are now broken. For this to be solved, a new binary package
with corerouter plugin () should be made as a dependency for
uwsgi-plugin-http and uwsgi-plugin-fastrouter. Theare are new plugins
that are not packaged, and I would like to upload them all at once to
avoid multiple waitings for NEW.
I will try to make new release as soon as possible solving this issue
and add new plugins, as well.
>
> Also, does uwsgi-plugin-python need to depend on both libpython2.6 *and*
> libpython2.7? Can it not be either/or?
Package uwsgi-plugin-python contains plugins for all python 2.X
versions. This could be done differently, and have a package for each
python version, but given the plan to remove python 2.6 in the near
future, and have only python 2.7, this may not be needed.
Best,
Janos
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#698691: please package a new upstream version
Hi Holger, On Tue, Jan 22, 2013 at 1:24 PM, Holger Levsen wrote: > package: uwsgi > severity: wishlist > > Hi, > > Thanks for maintaining uwsgi! It is a pleasure. > > Please package a new upstream version, either 1.3.3 or 1.4.4 - in version 1.3 > they added support for raw HTTP body pass-thru, which enables one to use > WebSockets on Apache, which is very useful and needed here. I am planing to package the 1.4.4 by the end of the next week and upload to experimental. If that does not work for you, feel free to contact me to coordinate changes. > > Please shout if I can help you with this in any way. Thank you, I certainly will if there are some problems or lack of time. > > > cheers, > Holger Best regards, Janos -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#694647: new upstream version available
Hi Michal, Due to code freeze I would like to upload new upstream version to experimental rather then to unstable archive. Would experimental work for you? Best, Janos -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#687084: Bug#687236: needs coordination with uwsgi
Hello Adam, On Sun, Sep 16, 2012 at 4:07 PM, Adam D. Barratt wrote: > On Sun, 2012-09-16 at 14:06 +0200, Martin Pitt wrote: >> Janoš Guljaš [2012-09-14 13:23 +0200]: >> > I would like to ask for unblock from release team for 1.2.3+dfsg-5, as >> > there are no need for testing-proposed-updates, if you agree? >> >> Yes I do; from reading the changelog I had the impression that this >> was targetted at Wheezy. > > I've unblocked uwgsi; thanks. Thank you for the unblock. > > fwiw, if you're going to include descriptions of patches in the > changelog, they should possibly be a little more descriptive of the > content than what could have been gleaned from the patch filename. :-) I certainly will update descriptions in the next release. > > +- allows-ugreen-with-threads.patch > +Allows ugreen with threads. > > Regards, > > Adam Best, Janos -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#687084: needs coordination with uwsgi
Hello Martin, On Fri, Sep 14, 2012 at 6:05 AM, Martin Pitt wrote: > Hello again, > > Julian Taylor pointed out that this unexpectedly affected uwsgi, as > that started to include "pg_config --cflags", and caused uwsgi to > FTBFS: > > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=687084 Yes, the uwsgi's build system used the output of "pg_config --cflags" in building of the plugin named "probepg", which is a shared library. There are no need for postgres' cflags, and I removed the inclusion with this patch: http://patch-tracker.debian.org/patch/series/view/uwsgi/1.2.3+dfsg-5/remove-pg_config_cflags-in-probepg.patch > > This has been fixed in 1.2.3+dfsg-5 now. So we need to coordinate the > unblocking of PostgreSQL 9.1.5-2 with that uwsgi version. Janos, did > you want to get -5 into testing, or should we put the pg_config fix > into testing-proposed-updates? This change, and some of the important upstream patches that I added to the -5 release are not making problems with any package currently in testing. There are no uwsgi 1.2.3+dfsg-5 build issues in testing (at least for amd64). The patch that is fixing 687084 is backward compatible with previous postgresql releases including the 9.1.5-1. I would like to ask for unblock from release team for 1.2.3+dfsg-5, as there are no need for testing-proposed-updates, if you agree? > > Thanks, > > Martin > -- > Martin Pitt| http://www.piware.de > Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) Thanks, Janos -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#687084: postgres fault
Hi Julian, I will wait with the upload until there is more info regarding 687208. Thanks for checking the fix I did and submitting 687208. Best, Janos On Mon, Sep 10, 2012 at 10:39 PM, Julian Taylor wrote: > thanks for the quick diagnose > in my opinion its actually postgres fault and should not require a fix > at uwsgi's side > see bug 687208 > -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#685384: unblock: uwsgi/1.2.3+dfsg-3
On Tue, Aug 21, 2012 at 9:47 PM, Adam D. Barratt wrote: > > Assuming the new package has been appropriately tested, please go ahead; > thanks. > Package uwsgi 1.2.3+dfsg-4 is uploaded. Debdiff is attached. Best, Janos uwsgi_1.2.3+dfsg-2_uwsgi_1.2.3+dfsg-4-released.diff Description: Binary data
Bug#685384: unblock: uwsgi/1.2.3+dfsg-3
Hi Adam,
On Mon, Aug 20, 2012 at 8:17 PM, Adam D. Barratt
wrote:
> On Mon, 2012-08-20 at 14:19 +0200, Janoš Guljaš wrote:
>> On Mon, Aug 20, 2012 at 2:17 PM, Adam D. Barratt
>> wrote:
>> > On 20.08.2012 12:37, Janos Guljas wrote:
>> >>
>> >> Please unblock package uwsgi.
>> >>
>> >> There is a bug with a release in Wheezy that is making init script
>> >> useless after a reload. The fix is to remove `name` parameter from
>> >> start-stop-daemon. I am sending debdiff.
>> >
>> > What name does the daemon end up running under? (Presumably not "uwsgi".)
>>
>> The name is changed from uwsgi to uwsgi-core.
>
> If the daemon always runs as "uwsgi-core", would it be worth changing
> the calls to use "--name uwsgi-core" or similar, instead of dropping the
> use of --name entirely? I'm pondering how likely it is that s-s-d will
> end up killing the wrong process if the daemon has died and the PID has
> been re-used. Maybe I'm just overly paranoid.
The problem is that /usr/bin/uwsgi is a symlink made by alternatives
to /usr/bin/uwsgi-core, and uwsgi is keeping internally the binary
path of the path linked (got with readlink("/proc/self/exe", buf,
PATH_MAX)) and using it for reloads by sending the SIGHUP. After the
rerun with the link target the process is changing it's name to
uwsgi-core, or to whatever is set by alternatives for uwsgi group.
I agree that removing the name option can make more damage then good,
so I am sending debdiff with a patch that is changing how uwsgi_reload
function works. That function is overriding the main's argv[0] value
with a value provided by the readlink. The patch is just using argv[0]
in execvp as the first argument. That way the process name is
preserved, even if the path in argv[0] is in relative form.
Could review the changes from debdiff? If you have any suggestion I
would be glad to hear them. Package uwsgi_1.2.3+dfsg-4 is not uploaded
to the archive.
>
> Regards,
>
> Adam
>
Best,
Janos
uwsgi_1.2.3+dfsg-2_uwsgi_1.2.3+dfsg-4.diff
Description: Binary data
Bug#685384: unblock: uwsgi/1.2.3+dfsg-3
Hi Adam, On Mon, Aug 20, 2012 at 2:17 PM, Adam D. Barratt wrote: > On 20.08.2012 12:37, Janos Guljas wrote: >> >> Please unblock package uwsgi. >> >> There is a bug with a release in Wheezy that is making init script >> useless after a reload. The fix is to remove `name` parameter from >> start-stop-daemon. I am sending debdiff. > > > What name does the daemon end up running under? (Presumably not "uwsgi".) The name is changed from uwsgi to uwsgi-core. > > Regards, > > Adam Best, Janos -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#685275: uwsgi-plugin-python: segmentation fault with python26
Hi Boris, Thanks for informations on this issue. I would forward it to the upstream developers, as segmentation faults are certainly not normal. Best, Janos On Sun, Aug 19, 2012 at 7:10 PM, Boris Bobrov wrote: > В сообщении от Sunday 19 of August 2012 17:29:52 вы написали: >> severity 685275 normal >> thanks >> >> Hi Boris, >> [...] > > The problem was in cache in "data/pages/*/cache/". It uses Python byte code > and removing it as suggested on [0] helped. > > [0]: http://moinmo.in/HelpOnUpdatingPython > > I don't know if it is normal that uwsgi falls with segfault, but my problem is > solved. If it is normal, sorry for the false bugreport. > > -- > WBR, > Boris. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#685275: uwsgi-plugin-python: segmentation fault with python26
severity 685275 normal thanks Hi Boris, For testing purposes I prepared a fresh installed Wheeze arch i386. You are using a mixed system (500, 'proposed-updates'), (500, 'testing'), (500, 'stable') with Linux kernel 2.6.32-5-686-bigmem (no more available in testing) which I can not recreate completely. The kernel I used is 3.2.0-3-686-pae. For simplicity, I used uwsgi-plugin-http, with an addition --http 0.0.0.0:3031 to the options you provided. Additional installed packages are: uwsgi-plugin-python, uwsgi-plugin-http, python-moinmoin. Running uwsgi: uwsgi --plugins python26,http --uid --gid -s /tmp/wi.sock --chmod-socket 666 --wsgi-file /usr/share/moin/server/moin.wsgi --http 0.0.0.0:3031 Is serving MoinMoin without Segmentation faults, but with complains about data_dir configuration. To fix this, I manually created: mkdir -p /tmp/moin/pages mkdir -p /tmp/moin/underlay/pages mkdir /tmp/moin/plugin touch /tmp/moin/plugin/__init__.py and added this options to the Config class in /etc/moin/mywiki.py file: echo "data_dir = '/tmp/moin' data_underlay_dir = '/tmp/moin/underlay'" >> /etc/moin/mywiki.py Notice the indentation in the echoed string, to match the indentation of the Config class. After running uwsgi with the same options as above MoinMoin was fully functional. I could not reproduce Segmentation faults. Could you provide more details on moinmoin configuration that you are using, uwsgi error logs, which web server is communicating with uwsgi over /tmp/wiki.sock and more details on your systems setup so I could try to reproduce the issue? Could you try to reproduce the issue on a system fully upgraded to testing, not on mixed system? Best, Janos On Sun, Aug 19, 2012 at 9:40 AM, Boris Bobrov wrote: > Package: uwsgi-plugin-python > Version: 1.2.3+dfsg-2 > Severity: important > > Launched with: > --plugins python26 --uid --gid -s /tmp/wiki.sock --chmod-socket > 666 --wsgi-file /usr/share/moin/server/moin.wsgi > > /usr/share/moin/server/moin.wsgi is from latest python-moinmoin > > bt full attached > > -- System Information: > Debian Release: 6.0.5 > APT prefers proposed-updates > APT policy: (500, 'proposed-updates'), (500, 'testing'), (500, 'stable') > Architecture: i386 (i686) > > Kernel: Linux 2.6.32-5-686-bigmem (SMP w/1 CPU core) > Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.UTF-8 (charmap=UTF-8) > Shell: /bin/sh linked to /bin/dash > > Versions of packages uwsgi-plugin-python depends on: > ii libc6 2.13-35 Embedded GNU C Library: Shared > lib > ii libpython2.62.6.8-0.2Shared Python runtime library > (ver > ii libpython2.72.7.3-3 Shared Python runtime library > (ver > ii uwsgi-core 1.2.3+dfsg-2 fast, self-healing application > con > > uwsgi-plugin-python recommends no packages. > > Versions of packages uwsgi-plugin-python suggests: > pn python-uwsgidecorators (no description available) > > -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#522935: ITP: emerald -- Window Decorator shipped with Compiz Fusion.
Hi Carlos, On Tue, Jul 24, 2012 at 3:05 AM, Carlos Alberto Lopez Perez wrote: > Hello, > > > > This ITP is one year and a half old. Any progress here? It looks like that the upstream development is staled for some time. I do not sure if it is fit to be in the archive and I did not make any progress. > > > I am interesting in having this software on Debian... So if you are not > longer interested on it I would appreciate if you can re-title this to > an RFP so I can take over it. Michael, thanks for retitling the bug report. Carlos, I can upload somewhere packaged 0.8.4 version if you are interested about it. It is working with Compiz currently in testing. > > > Thanks! > Best, Janos -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#660212: Emperor support
Hi Ole, Emperor is one of the possible ways to manage uWSGI apps and it is a nice one. But, not every setup needs Emperor mode, and managing applications can be done without it. If it is needed, it can be configured with a simple configuration which will include Emperor. There are various ways/modes to use Emperor, and my opinion is that it should be left for administrator to choose to use it or not. With uWSGI rapid development many options and features are changing from release to release. It is safer with managing application the way it is now, as default configurations are less likely to change with minimal relying on specific uWSGI features and options. Will an example setup under documentation would help on using Emperor? Do you maybe have a suggestion on best practices? A simple emperor.ini and vessels directory with applications linked under /etc/uwsgi/apps-enabled would be one way to achieve it, while keeping clear space for applications for which Emperor is not needed. Best, Janos On Tue, Jul 3, 2012 at 6:36 PM, Ole Laursen wrote: > Hi! > > Allow me to second this. While the setup installed by the package is > neat, it looks like the Emperor is the upstream idea of how to do > this, and it also makes babysitting the thing a bit easier: > > http://projects.unbit.it/uwsgi/wiki/SystemdIntegration > > I think it would be neat if the package shipped with a simple emperor.ini > setup. > > Also, this is just a humble side remark, but I notice you're using the > app symlink pattern from Apache (and now also nginx) - while it seems > cool initially, IMHO after 5 years of maintaining a growing number of > sites it turns out to be a pain in the butt in practice because you > have to remember to fix the symlink. > > The only thing I can really see it's good for is when you want to > temporarily disable a site without actually removing it, but then you > could just have mv'ed it away to a trash directory instead of > maintaining the symlink farm. > > > Ole > > -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#634923: python-django-authority: ships Python module "example"
Hi Clint, On Thu, Jun 7, 2012 at 7:31 PM, Clint Adams wrote: > On Thu, Jun 07, 2012 at 07:21:02PM +0200, Janos Guljas wrote: >> I had a similar issue with one of my packages, and I am sending a patch >> that is removing example from packaging it as a module, and putting that >> directory as example under documentation. > > Thanks.. I'll apply it shortly. You wouldn't want to adopt it, > would you? Thanks for the offering, but I am not using this module in my projects. Best, Janos -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#666793: closed by Janos Guljas (Bug#666793: fixed in uwsgi 1.1.2+dfsg-2~experimental+1)
Hi Arno, Thanks for looking at uwsgi build logs and useful informations. I will upload it to experimental with the changes you mentioned. Because of specific packaging, I did not use dh-apache2, but I plan to change that to avoid potential problems in the future. Best, Janos On Tue, Apr 3, 2012 at 23:48, Arno Töll wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Hi Janos, > > I noticed your package FTBS. This is our fault. You didn't add > dh-apache2 as a build-dependency (which is fair enough), so aptitude > didn't consider the experimental version of the apache2-dev package, > but kept the 2.2 version which is provided as a virtual package > provided by apache2-threaded-dev. > > So, to solve your problem you need to declare a versioned > build-dependency against apache2-dev, e.g. "apache2-dev ( >> 2.4~ )". > > Sorry for the hassle. > > Moreover I took the liberty to look at your postinst script. You seem > to use our dh_apache2 snippet which contains several boilerplates > which are expanded at build time. You may want to use something like > > if [ "$1" = "configure" ] ; then > if [ -e /usr/share/apache2/apache2-maintscript-helper ] ; then > . /usr/share/apache2/apache2-maintscript-helper > apache2_invoke enmod @@module_name@@ || exit 1 > fi > fi > > > > - -- > with kind regards, > Arno Töll > IRC: daemonkeeper on Freenode/OFTC > GnuPG Key-ID: 0x9D80F36D > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.4.11 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iQIcBAEBAgAGBQJPe3ApAAoJEMcrUe6dgPNtySMQAKp8hAlJI7bixC8X6Gzw+sbX > NeeOgEI2/pNSosckUHf0gBLeTGTrwvX5pQs5z9uAfA0D+kxd8VPLkcRKoP5xbhE9 > fQs57cD2prk9RfeBkxIlr8any5cjd00D0CF3Cjk+rZGeD4So3+jMRiy3u6vmEh5l > QKhf+0wB7y16qtRhqCu3vwfx2AeljajhUY/vTHEo2oP/O8flXB5KiJU5gEIBhkOY > uQjgfPtZrET0biZV1W/qQegotBFQ3QYm3Xt8QcOj0DKq6Gj4UyPoAmKBk+uOCSyU > eUOXMy+0l0JyvCl7H/I6eKfPHmkU86Nr76ZVXzULNNv1w+frJkN3uYlV2hfeR6PP > Fyz98IEKnwzh4nxjEgohtc28Jfg3cFTUrWNENG6Y1CdCfcRKsVS+Q3Vp9MdT1BVN > kAZ8wTBBccuAJJdbtp5xqp34jR0pGaglFIsD05PpgxQq8HAHnyUGkuzH6EkGddAJ > ORF8t3yBjPucLhHMWhwFs0LLvf0Jz7JXl+wX6h0l3SbHXRF6mAV90pufTPx+NhFD > hKsv7ELLcA/Naem2oNDklcXp0EyOLYsN4t5VqCN0gYGCe/i1Ev0CyriFiXVXNrsL > GfDM8ui5qQxFaFweFQtE9lW8YsoUC31PAvcxy8XbLn0sQp3QGqo3DpUTJGB9gx9e > GCD/aBqkh9lQiPNhBBdW > =eJI4 > -END PGP SIGNATURE- > > -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#664890: uwsgi seems to not like symbolic links (or: failure when using python as a plugin)
Hi Paul, This bug has been fixed upstream in the release 1.1.1. It will soon enter the archive. Regards, Janos -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#656280: uwsgi FTBFS on several architectures, confusion between debian architecture names and java architecture names and "strict aliasing" problem in python code
Hi Peter, This issue has been addressed in packaging [0]. After resolving a few other issues, regarding new upstream release, it will be uploaded. Thanks for submitting the bug report, Janos [0] http://anonscm.debian.org/gitweb/?p=collab-maint/uwsgi.git;a=commit;h=c8518303b95d6fad820c91023ef8fa42137d8d9e On Wed, Jan 18, 2012 at 00:53, peter green wrote: > package: uwsgi > version: 0.9.8.3-2 > severity: serious > tags: patch > x-debbugs-cc: ja...@resenje.org > > Unfortunately the patch submitted for 640347 was incorrect. The architecture > in the "openjdk-6-" part of the path needs to be the debian > architecture name not the java architecture name (which is ambiguous). This > error causes the package to FTBFS on architectures where the debian > architecture and java architecture differ. Debian and java architecture > names differ on armel, powerpc, armhf, sh4, and powerpcspe > > In addition to further confuse matters java-arch.sh was returning incorrect > java architecture names on armhf, sh4, powerpcspe and s390x, that has been > sorted in a recent upload of javahelper for armhf, sh4 and powerpcspe. At > the time of writing it's still an issue on s390x. Still I can poke the s390x > buildd guys for a rebuild when that is sorted so don't let it stop you > uploading this fix. > > Anyway I prepared a fix for the debian architecture names VS java > architecture names issue and then ran a test build on armel. Unfortunately > it failed with "strict aliasing" errors in the python2.7 plugin. I then > tested the package on amd64 and ran into the same issue. > > gcc -pthread -fPIC -shared -o /uwsgi-0.9.8.3/python27_plugin.so -I. -O2 > -Wall -Werror -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -Wextra > -Wno-unused-parameter -Wno-missing-field-initializers > -DUWSGI_BUILD_DATE="\"17 January 2012 19:52:09\"" -DUWSGI_HAS_IFADDRS > -DUWSGI_LOCK_USE_MUTEX -DUWSGI_EVENT_USE_EPOLL > -DUWSGI_EVENT_TIMER_USE_TIMERFD -DUWSGI_EVENT_TIMER_USE_TIMERFD_NOINC > -DUWSGI_EVENT_FILEMONITOR_USE_INOTIFY -DUWSGI_EMBEDDED -DUWSGI_UDP > -DUWSGI_UUID -DUWSGI_VERSION="\"0.9.8.3-debian\"" -DUWSGI_VERSION_BASE="0" > -DUWSGI_VERSION_MAJOR="9" -DUWSGI_VERSION_MINOR="8" > -DUWSGI_VERSION_REVISION="3" -DUWSGI_VERSION_CUSTOM="\"debian\"" > -DUWSGI_ASYNC -DUWSGI_MULTICAST -DUWSGI_MINTERPRETERS -DUWSGI_INI > -DUWSGI_YAML -DUWSGI_LIBYAML -DUWSGI_JSON -DUWSGI_LDAP -DUWSGI_ZEROMQ > -DUWSGI_SNMP -DUWSGI_THREADING -DUWSGI_SENDFILE -I/usr/include/libxml2 > -DUWSGI_XML -DUWSGI_XML_LIBXML2 -DUWSGI_SQLITE3 > -DUWSGI_PLUGIN_DIR=\"/uwsgi-0.9.8.3\" -DUWSGI_SPOOLER > -I/usr/include/python2.7 -I/usr/include/python2.7 -Wno-unused-parameter > -Wno-strict-prototypes -Dpython_plugin=python27_plugin > -L/usr/lib/python2.7/config -lpthread -ldl -lutil -lm -lpython2.7 -Xlinker > -export-dynamic -Wl,-O1 -Wl,-Bsymbolic-functions > /uwsgi-0.9.8.3/plugins/python27/../python/python_plugin.c > /uwsgi-0.9.8.3/plugins/python27/../python/pyutils.c > /uwsgi-0.9.8.3/plugins/python27/../python/pyloader.c > /uwsgi-0.9.8.3/plugins/python27/../python/wsgi_handlers.c > /uwsgi-0.9.8.3/plugins/python27/../python/wsgi_headers.c > /uwsgi-0.9.8.3/plugins/python27/../python/wsgi_subhandler.c > /uwsgi-0.9.8.3/plugins/python27/../python/gil.c > /uwsgi-0.9.8.3/plugins/python27/../python/uwsgi_pymodule.c > /uwsgi-0.9.8.3/plugins/python27/../python/profiler.c > /uwsgi-0.9.8.3/plugins/python27/../python/symimporter.c -lpthread -ldl > -lutil -lm -lpython2.7 > /uwsgi-0.9.8.3/plugins/python27/../python/uwsgi_pymodule.c: In function > ‘py_uwsgi_add_cron’: > /uwsgi-0.9.8.3/plugins/python27/../python/uwsgi_pymodule.c:256:2: error: > dereferencing type-punned pointer will break strict-aliasing rules > [-Werror=strict-aliasing] > /uwsgi-0.9.8.3/plugins/python27/../python/uwsgi_pymodule.c: In function > ‘py_uwsgi_register_rpc’: > /uwsgi-0.9.8.3/plugins/python27/../python/uwsgi_pymodule.c:500:2: error: > dereferencing type-punned pointer will break strict-aliasing rules > [-Werror=strict-aliasing] > /uwsgi-0.9.8.3/plugins/python27/../python/uwsgi_pymodule.c: In function > ‘py_uwsgi_attach_daemon’: > /uwsgi-0.9.8.3/plugins/python27/../python/uwsgi_pymodule.c:517:2: error: > dereferencing type-punned pointer will break strict-aliasing rules > [-Werror=strict-aliasing] > /uwsgi-0.9.8.3/plugins/python27/../python/uwsgi_pymodule.c: In function > ‘py_uwsgi_signal_registered’: > /uwsgi-0.9.8.3/plugins/python27/../python/uwsgi_pymodule.c:529:3: error: > dereferencing type-punned pointer will break strict-aliasing rules > [-Werror=strict-aliasing] > /uwsgi-0.9.8.3/plugins/python27/../python/uwsgi_pymodule.c: In function > ‘py_uwsgi_is_connected’: > /uwsgi-0.9.8.3/plugins/python27/../python/uwsgi_pymodule.c:785:2: error: > dereferencing type-punned pointer will break strict-aliasing rules > [-Werror=strict-aliasing] > /uwsgi-0.9.8.3/plugins/python27/../python/uwsgi_pymodule.c: In function > ‘py_uwsgi_send’: > /uwsgi-0.9.8.3/plugins/python27/../python/uwsgi_pymodule.c:820:2: error: > dereferencing type-punned po
Bug#654333: ImportError: No module named site
On Tue, Jan 3, 2012 at 03:18, Boris Bobrov wrote: > > Thank you, it helped. Maybe you should document it in changelog? > Of course, I will. Thanks for noticing and submitting this issue. Best, Janos -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#654333: ImportError: No module named site
Hi Boris, As I see, you are using Debian 6.0.3 as a base for mixed system. The solution should be to specify option plugin=python26 to force Python 2.6 plugin if your virtualenv environment is built with Python 2.6. Previous release (0.9.8.3-1) was built with with python2.6 as default interpreter so plugin with python 2.6 was default. In release (0.9.8.3-2) Python 2.7 is default plugin as it is a default interpreter. Best, Janos On Tue, Jan 3, 2012 at 00:44, Boris Bobrov wrote: > Package: uwsgi-plugin-python > Version: 0.9.8.3-2 > Severity: important > Tags: sid > > After upgrade to version 0.9.8.3-2 I was unable to launch any app with > 'home' option pointing to virtualenv environment. Logs: > > -- > Tue Jan 3 03:17:04 2012 - /usr/lib/uwsgi/plugins/python27_plugin.so > Tue Jan 3 03:17:04 2012 - *** Starting uWSGI 0.9.8.3-debian (32bit) on [Tue > Jan 3 03:17:04 2012] *** > Tue Jan 3 03:17:04 2012 - compiled with version: 4.6.2 on 01 January 2012 > 21:33:55 > Tue Jan 3 03:17:04 2012 - writing pidfile to /run/uwsgi/app/cm/pid > Tue Jan 3 03:17:04 2012 - setgid() to 1005 > Tue Jan 3 03:17:04 2012 - setuid() to 1005 > Tue Jan 3 03:17:04 2012 - your memory page size is 4096 bytes > Tue Jan 3 03:17:04 2012 - uwsgi socket 0 bound to UNIX address > /run/uwsgi/app/cm/socket fd 6 > Tue Jan 3 03:17:04 2012 - uwsgi socket 1 bound to TCP address > 127.0.0.1:49155 fd 7 > Tue Jan 3 03:17:04 2012 - Python version: 2.7.2+ (default, Aug 16 2011, > 07:32:53) [GCC 4.6.1] > Tue Jan 3 03:17:04 2012 - Set PythonHome to /home/cm/www/env/ > ImportError: No module named site > -- > But everything works fine with version 0.9.8.3-1. > > -- System Information: > Debian Release: 6.0.3 > APT prefers proposed-updates > APT policy: (500, 'proposed-updates'), (500, 'testing'), (500, 'stable') > Architecture: i386 (i686) > > Kernel: Linux 2.6.32-5-686-bigmem (SMP w/8 CPU cores) > Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.UTF-8 (charmap=UTF-8) > Shell: /bin/sh linked to /bin/dash > > Versions of packages uwsgi-plugin-python depends on: > ii libc6 2.13-18 Embedded GNU C Library: Shared > lib > ii libpython2.6 2.6.7-3 Shared Python runtime library > (ver > ii libpython2.7 2.7.2-5 Shared Python runtime library > (ver > ii uwsgi-core 0.9.8.3-2 fast, self-healing application > con > > uwsgi-plugin-python recommends no packages. > > Versions of packages uwsgi-plugin-python suggests: > pn python-uwsgidecorators (no description available) > > -- no debconf information > > -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
