librelist archives

« back to archive

Had some problems upgradeing from 0.8 to 0.9.1

Had some problems upgradeing from 0.8 to 0.9.1

From:
Ry4an Brase
Date:
2012-02-12 @ 03:28
I've got a blohg site at http://ry4an.org and I failed in upgrading to
0.9.1 tonight.  I ran into two problems that may or may not be related.

1. When using 'blohg runserver' in a my repository I got a failure to
   find config.yaml.  I keep my server-side repositories without working
   directories ('hg update null') and this worked fine previously.  Now
   I found I had to a 'hg update tip' for config.yaml to load.  It's nto
   a big deal, but perhaps just a result of the early loading changes.


2. After getting a working directory in place, and making sure the repo
   was readable by www-user, and making sure the www-user trusted the
   owner of the files, I still got a '500' when running in
   apache+mod_wsgi.  The access log showed the 500, but neither the
   output body nor the error log showed anything.

Is there a way to get flask to show rendered exceptions under
apache+mod_wsgi?  I kept thinking that if I could just see the source of
the exception I'd know what was off, but when I ran with 'hg runserver'
on the same system, with the same python, and the same repository --
even as the www-user user -- everything worked fine.  It was only behind
the veil of apache+mod_wsgi that I'd get the 500.

Tweaking my /usr/local/lib/python2.6/dist-packages/easy-install.pth to
point to blohg-0.8_1c6a790d1830-py2.6.egg instead of
blohg-0.9.1_bb6ae530f347-py2.6.egg and changing absolutely nothing else
was enough to make things work.

Any ideas?

Thanks,

-- 
Ry4an Brase - http://ry4an.org/

Re: [blohg] Had some problems upgradeing from 0.8 to 0.9.1

From:
Rafael Martins
Date:
2012-02-12 @ 18:16
Hi Ry4an,

On Sun, Feb 12, 2012 at 1:28 AM, Ry4an Brase <ry4an-blohg@ry4an.org> wrote:
> I've got a blohg site at http://ry4an.org and I failed in upgrading to
> 0.9.1 tonight.  I ran into two problems that may or may not be related.
>
> 1. When using 'blohg runserver' in a my repository I got a failure to
>   find config.yaml.  I keep my server-side repositories without working
>   directories ('hg update null') and this worked fine previously.  Now
>   I found I had to a 'hg update tip' for config.yaml to load.  It's nto
>   a big deal, but perhaps just a result of the early loading changes.

You're serving your blog using 'blohg runserver'? the mercurial
revision currently used by 'blohg runserver' is 'None', that means
"use the files from the working directory, even if they aren't
commited yet, but are 'hg add'-ed". If you deploy blohg using the
blohg.wsgi sample file or similar, the mercurial revision used will be
'default'. This behavior changed a bit with the early loading changes,
but should still works. All my blogs are deployed using 'hg update
null'-ed repositories.

> 2. After getting a working directory in place, and making sure the repo
>   was readable by www-user, and making sure the www-user trusted the
>   owner of the files, I still got a '500' when running in
>   apache+mod_wsgi.  The access log showed the 500, but neither the
>   output body nor the error log showed anything.
>
> Is there a way to get flask to show rendered exceptions under
> apache+mod_wsgi?  I kept thinking that if I could just see the source of
> the exception I'd know what was off, but when I ran with 'hg runserver'
> on the same system, with the same python, and the same repository --
> even as the www-user user -- everything worked fine.  It was only behind
> the veil of apache+mod_wsgi that I'd get the 500.

you can activate debug by adding something like this at the end of the
wsgi file:

application.debug = True

but this will set the mercurial revision to None, like 'blohg
runserver' does. This behavior isn't very good for debug reasons and
I'll separate these settings soon. maybe this will fix your issues.

> Tweaking my /usr/local/lib/python2.6/dist-packages/easy-install.pth to
> point to blohg-0.8_1c6a790d1830-py2.6.egg instead of
> blohg-0.9.1_bb6ae530f347-py2.6.egg and changing absolutely nothing else
> was enough to make things work.
>
> Any ideas?

I guess you problem is that you enabled debug and wasn't expecting it
to change the mercurial revision to 'None' instead of 'default'.

I'll investigate.

Best regards,

-- 
Rafael Goncalves Martins
http://rafaelmartins.eng.br/

Re: [blohg] Had some problems upgradeing from 0.8 to 0.9.1

From:
Ry4an Brase
Date:
2012-02-13 @ 02:05
Okay, I threw 'application.debug = True' into the wsgi file and now
I get a good error message in the apache error log.  I've attached the
initialization plus traceback, but it seems to come down to this:


[Sun Feb 12 20:51:47 2012] [error] [client 68.32.23.192]   File 
"/usr/local/lib/python2.6/dist-packages/mercurial/encoding.py", line 133, 
in fromlocal
[Sun Feb 12 20:51:47 2012] [error] [client 68.32.23.192]     raise 
error.Abort("decoding near '%s': %s!" % (sub, inst))
[Sun Feb 12 20:51:47 2012] [error] [client 68.32.23.192] Abort: decoding 
near 'e news.  I\xe2\x80\x99m sure ': 'ascii' codec can't decode byte 0xe2
in position 446: ordinal not in range(128)!

That's a decoding error in Mercurial on a line from my blog text that
probably has a stupid "smartquote" in it.

I'll upgrade mercurial and sanitize the entry, but it seems really odd
that 0.8.0 can successfully render that entry (it's doing it right here:
http://ry4an.org/unblog/post/graduation_form_letter/ ) but 0.9.1
explodes on it.

Thanks!

-- 
Ry4an Brase - http://ry4an.org/

Re: [blohg] Had some problems upgradeing from 0.8 to 0.9.1

From:
Ry4an Brase
Date:
2012-02-13 @ 02:28
I broke the rule about changing two things at once and both upgraded
Mercurial from 1.9.3 to 2.1 and removed the high-ascii character from
the post and now my blog is running fine with blohg 0.9.1 on
apache+mod_wsgi w/ no working directory.

Here's a summary of configurations that did and didn't work:

Server   : apache + mod_wsgi
Debug    : False (default)
Mercurial: 1.9.3
Blohg    : 0.8.0
Post     : contained a high-ascii character
Result   : worked

Server   : apache + mod_wsgi
Debug    : False (default)
Mercurial: 1.9.3
Blohg    : 0.9.1
Post     : contained a high-ascii character
Result   : 500 error w/ no output to error log

Server   : apache + mod_wsgi
Debug    : True
Mercurial: 1.9.3
Blohg    : 0.9.1
Post     : contained a high-ascii character
Result   : 500 error w/ parse error in backtrace

Server   : 'blohg runsever'
Debug    : True (default)
Mercurial: 1.9.3
Blohg    : 0.9.1
Post     : contained a high-ascii character
Result   : worked

Server   : apache + mod_wsgi
Debug    : False (default)
Mercurial: 2.1.0
Blohg    : 0.9.1
Post     : no high-ascii characters
Result   : worked

On Sun, Feb 12, 2012 at 09:05:27PM -0500, Ry4an Brase wrote:
> Okay, I threw 'application.debug = True' into the wsgi file and now
> I get a good error message in the apache error log.  I've attached the
> initialization plus traceback, but it seems to come down to this:
> 
> 
> [Sun Feb 12 20:51:47 2012] [error] [client 68.32.23.192]   File 
"/usr/local/lib/python2.6/dist-packages/mercurial/encoding.py", line 133, 
in fromlocal
> [Sun Feb 12 20:51:47 2012] [error] [client 68.32.23.192]     raise 
error.Abort("decoding near '%s': %s!" % (sub, inst))
> [Sun Feb 12 20:51:47 2012] [error] [client 68.32.23.192] Abort: decoding
near 'e news.  I\xe2\x80\x99m sure ': 'ascii' codec can't decode byte 0xe2
in position 446: ordinal not in range(128)!
> 
> That's a decoding error in Mercurial on a line from my blog text that
> probably has a stupid "smartquote" in it.
> 
> I'll upgrade mercurial and sanitize the entry, but it seems really odd
> that 0.8.0 can successfully render that entry (it's doing it right here:
> http://ry4an.org/unblog/post/graduation_form_letter/ ) but 0.9.1
> explodes on it.
> 
> Thanks!

-- 
Ry4an Brase - http://ry4an.org/

Re: [blohg] Had some problems upgradeing from 0.8 to 0.9.1

From:
Rafael Martins
Date:
2012-02-14 @ 22:58
Hi Ry4an,

On Mon, Feb 13, 2012 at 12:28 AM, Ry4an Brase <ry4an-blohg@ry4an.org> wrote:
> I broke the rule about changing two things at once and both upgraded
> Mercurial from 1.9.3 to 2.1 and removed the high-ascii character from
> the post and now my blog is running fine with blohg 0.9.1 on
> apache+mod_wsgi w/ no working directory.
>
> Here's a summary of configurations that did and didn't work:
>
> Server   : apache + mod_wsgi
> Debug    : False (default)
> Mercurial: 1.9.3
> Blohg    : 0.8.0
> Post     : contained a high-ascii character
> Result   : worked
>
> Server   : apache + mod_wsgi
> Debug    : False (default)
> Mercurial: 1.9.3
> Blohg    : 0.9.1
> Post     : contained a high-ascii character
> Result   : 500 error w/ no output to error log
>
> Server   : apache + mod_wsgi
> Debug    : True
> Mercurial: 1.9.3
> Blohg    : 0.9.1
> Post     : contained a high-ascii character
> Result   : 500 error w/ parse error in backtrace
>
> Server   : 'blohg runsever'
> Debug    : True (default)
> Mercurial: 1.9.3
> Blohg    : 0.9.1
> Post     : contained a high-ascii character
> Result   : worked
>
> Server   : apache + mod_wsgi
> Debug    : False (default)
> Mercurial: 2.1.0
> Blohg    : 0.9.1
> Post     : no high-ascii characters
> Result   : worked
>

I'm glad that you was able to fix this.

I had a problem with this charset change [1] too. Make sure that your
system locale is properly set up. I fixed it setting
LC_ALL=en_US.utf-8

[1] http://hg.rafaelmartins.eng.br/blohg/rev/f7a138c0569b

Best regards,

-- 
Rafael Goncalves Martins
http://rafaelmartins.eng.br/

Re: [blohg] Had some problems upgradeing from 0.8 to 0.9.1

From:
Ry4an Brase
Date:
2012-02-13 @ 01:47
[[ resending from the subscribed address ]]

On Sun, Feb 12, 2012 at 04:16:23PM -0200, Rafael Martins wrote:
> Hi Ry4an,
> 
> On Sun, Feb 12, 2012 at 1:28 AM, Ry4an Brase <ry4an-blohg@ry4an.org> wrote:
> > I've got a blohg site at http://ry4an.org and I failed in upgrading to
> > 0.9.1 tonight.  I ran into two problems that may or may not be related.
> >
> > 1. When using 'blohg runserver' in a my repository I got a failure to
> >   find config.yaml.  I keep my server-side repositories without working
> >   directories ('hg update null') and this worked fine previously.  Now
> >   I found I had to a 'hg update tip' for config.yaml to load.  It's nto
> >   a big deal, but perhaps just a result of the early loading changes.
> 
> You're serving your blog using 'blohg runserver'?

No, I serve it with apache+mod_wsgi, but that that failed on update w/
no messages at all in the error log I tried runserver to see if I could
get an actionable message.

> the mercurial revision currently used by 'blohg runserver' is 'None',
> that means "use the files from the working directory, even if they
> aren't commited yet, but are 'hg add'-ed". If you deploy blohg using
> the blohg.wsgi sample file or similar, the mercurial revision used
> will be 'default'. This behavior changed a bit with the early loading
> changes, but should still works. All my blogs are deployed using 'hg
> update null'-ed repositories.

Excellent, I'm glad to hear I can go back to having no working directory
once I figure out why apache+mod_wsgi gives a 500 with no error message
on output or logs.

> > 2. After getting a working directory in place, and making sure the repo
> >   was readable by www-user, and making sure the www-user trusted the
> >   owner of the files, I still got a '500' when running in
> >   apache+mod_wsgi.  The access log showed the 500, but neither the
> >   output body nor the error log showed anything.
> >
> > Is there a way to get flask to show rendered exceptions under
> > apache+mod_wsgi?  I kept thinking that if I could just see the source of
> > the exception I'd know what was off, but when I ran with 'hg runserver'
> > on the same system, with the same python, and the same repository --
> > even as the www-user user -- everything worked fine.  It was only behind
> > the veil of apache+mod_wsgi that I'd get the 500.
> 
> you can activate debug by adding something like this at the end of the
> wsgi file:
> 
> application.debug = True
> 
> but this will set the mercurial revision to None, like 'blohg
> runserver' does. This behavior isn't very good for debug reasons and
> I'll separate these settings soon. maybe this will fix your issues.

That's fine.  I can put a working directory there just to figure out
what's wrong.  I'll put that in place and see how it goes.

> > Tweaking my /usr/local/lib/python2.6/dist-packages/easy-install.pth to
> > point to blohg-0.8_1c6a790d1830-py2.6.egg instead of
> > blohg-0.9.1_bb6ae530f347-py2.6.egg and changing absolutely nothing else
> > was enough to make things work.
> >
> > Any ideas?
> 
> I guess you problem is that you enabled debug and wasn't expecting it
> to change the mercurial revision to 'None' instead of 'default'.

No, I only needed the working directory when I was using 'runserver' to
try to figure out why nothing was working when I was using
apache+mod_wsgi.  I'll use debug = True to see if I can get some error
output.

Thanks!

-- 
Ry4an Brase - http://ry4an.org/