Re: Upgraded OS , then ReviewBoard failed upgrade

2012-06-18 Thread Dan Dumont 
Yes.  And I agree. :)

- sent from my Galaxy Nexus Android phone.
On Jun 18, 2012 3:23 PM, "Christian Hammond"  wrote:

> Ah, that makes sense.
>
> Was that the only option you needed then? It'd be nice to have some docs
> on this somewhere.
>
> Christian
>
> --
> Christian Hammond - chip...@chipx86.com
> Review Board - http://www.reviewboard.org
> VMware, Inc. - http://www.vmware.com
>
>
> On Mon, Jun 18, 2012 at 4:51 AM, Dan Dumont  wrote:
>
>> I set https, but it never seemed to stick.
>>
>> Not sure if you've ever tested this deployment, but our server sits
>> behind a reverse proxy and ssl is terminated at the proxy, so the review
>> site machine never gets requests in on https.
>> It always sees http, and I think that's what's confusing whatever is
>> building the urls.
>>
>>
>> On Mon, Jun 18, 2012 at 5:49 AM, Christian Hammond 
>> wrote:
>>
>>> Hi Dan,
>>>
>>> Glad you got it working. I haven't really been available much this
>>> weekend.
>>>
>>> Thanks for the bug report. Should be an easy fix. However, I haven't
>>> seen that or the need for the SetEnv come up yet. Does your Server URL in
>>> the admin settings page use https or http? Setting that to https *should*
>>> do the right thing.
>>>
>>>
>>> Christian
>>>
>>> --
>>> Christian Hammond - chip...@chipx86.com
>>> Review Board - http://www.reviewboard.org
>>> VMware, Inc. - http://www.vmware.com
>>>
>>>
>>> On Sat, Jun 16, 2012 at 9:15 PM, Dan Dumont  wrote:
>>>
 SetEnv HTTPS on
 In the apache config worked like a charm though.

 I did end up filing this issue
 http://code.google.com/p/reviewboard/issues/detail?id=2639
 I'm not sure yet if this will cause problems now that I've solved the
 redirect https issues.


 On Sat, Jun 16, 2012 at 11:56 PM, Dan Dumont  wrote:

> I found
> https://groups.google.com/forum/?fromgroups#!topic/reviewboard/yIOamU1uvIY
>
> But I tried setting
>
>> os.environ['HTTPS'] = "on"
>
>
> In the reviewboard.wsgi file, but no dice.  I'm pretty sure we have a
> reverse proxy of some sort in front of us terminating SSL at the the 
> border.
> Would be nice if you guys could just return protocol relative urls  //
> reviewboard.apache.org/etc...
>
> Any advice on where to stick that config setting to force https urls?
>
> On Saturday, June 16, 2012 11:16:27 PM UTC-4, Dan Dumont wrote:
>>
>> Request URL:
>> https://reviews.apache.org/**api/review-requests/5345/?api_**
>> format=json
>>
>> responds:
>>
>>
>>1. review_request: {status:**pending, last_updated:2012-06-17
>>02:58:20, description:,…}
>>   1. branch: ""
>>   2. bugs_closed: []
>>   3. changenum: null
>>   4. description: ""
>>   5. id: 5345
>>   6. last_updated: "2012-06-17 02:58:20"
>>   7. links: {diffs:{href:http://**reviews.apache.org/api/review-*
>>   
>> *requests/5345/diffs/,
>>   method:GET},…}
>>  1. changes: {href:http://reviews.**apache.org/api/review-**
>>  
>> requests/5345/changes/,
>>  method:GET}
>> 1. href: "http://reviews.apache.**
>> 
>> org/api/review-requests/5345/**changes/
>> "
>> 2. method: "GET"
>>  2. delete: {href:http://reviews.**apache.org/api/review-**
>>  
>> requests/5345/,
>>  method:DELETE}
>> 1. href: "http://reviews.apache.**
>> 
>> org/api/review-requests/5345/
>> "
>> 2. method: "DELETE"
>>  3. diffs: {href:http://reviews.**apache.org/api/review-**
>>  
>> requests/5345/diffs/,
>>  method:GET}
>> 1. href: "http://reviews.apache.**
>> 
>> org/api/review-requests/5345/**diffs/
>> "
>> 2. method: "GET"
>>  4. draft: {href:http://reviews.**apache.org/api/review-**
>>  
>> requests/5345/draft/,
>>  method:GET}
>> 1. href: "http://reviews.apache.**
>> 
>> org/api/review-requests/5345/**draft/
>> "
>> 2. method: "GET"
>>  5. file_attachments: {href:http:/**/reviews.apache.org/api/*
>>

Re: Upgraded OS , then ReviewBoard failed upgrade

2012-06-18 Thread Christian Hammond 
Ah, that makes sense.

Was that the only option you needed then? It'd be nice to have some docs on
this somewhere.

Christian

-- 
Christian Hammond - chip...@chipx86.com
Review Board - http://www.reviewboard.org
VMware, Inc. - http://www.vmware.com


On Mon, Jun 18, 2012 at 4:51 AM, Dan Dumont  wrote:

> I set https, but it never seemed to stick.
>
> Not sure if you've ever tested this deployment, but our server sits behind
> a reverse proxy and ssl is terminated at the proxy, so the review site
> machine never gets requests in on https.
> It always sees http, and I think that's what's confusing whatever is
> building the urls.
>
>
> On Mon, Jun 18, 2012 at 5:49 AM, Christian Hammond wrote:
>
>> Hi Dan,
>>
>> Glad you got it working. I haven't really been available much this
>> weekend.
>>
>> Thanks for the bug report. Should be an easy fix. However, I haven't seen
>> that or the need for the SetEnv come up yet. Does your Server URL in the
>> admin settings page use https or http? Setting that to https *should* do
>> the right thing.
>>
>>
>> Christian
>>
>> --
>> Christian Hammond - chip...@chipx86.com
>> Review Board - http://www.reviewboard.org
>> VMware, Inc. - http://www.vmware.com
>>
>>
>> On Sat, Jun 16, 2012 at 9:15 PM, Dan Dumont  wrote:
>>
>>> SetEnv HTTPS on
>>> In the apache config worked like a charm though.
>>>
>>> I did end up filing this issue
>>> http://code.google.com/p/reviewboard/issues/detail?id=2639
>>> I'm not sure yet if this will cause problems now that I've solved the
>>> redirect https issues.
>>>
>>>
>>> On Sat, Jun 16, 2012 at 11:56 PM, Dan Dumont  wrote:
>>>
 I found
 https://groups.google.com/forum/?fromgroups#!topic/reviewboard/yIOamU1uvIY

 But I tried setting

> os.environ['HTTPS'] = "on"


 In the reviewboard.wsgi file, but no dice.  I'm pretty sure we have a
 reverse proxy of some sort in front of us terminating SSL at the the 
 border.
 Would be nice if you guys could just return protocol relative urls  //
 reviewboard.apache.org/etc...

 Any advice on where to stick that config setting to force https urls?

 On Saturday, June 16, 2012 11:16:27 PM UTC-4, Dan Dumont wrote:
>
> Request URL:
> https://reviews.apache.org/**api/review-requests/5345/?api_**
> format=json
>
> responds:
>
>
>1. review_request: {status:**pending, last_updated:2012-06-17
>02:58:20, description:,…}
>   1. branch: ""
>   2. bugs_closed: []
>   3. changenum: null
>   4. description: ""
>   5. id: 5345
>   6. last_updated: "2012-06-17 02:58:20"
>   7. links: {diffs:{href:http://**reviews.apache.org/api/review-**
>   
> requests/5345/diffs/,
>   method:GET},…}
>  1. changes: {href:http://reviews.**apache.org/api/review-**
>  
> requests/5345/changes/,
>  method:GET}
> 1. href: "http://reviews.apache.**
> 
> org/api/review-requests/5345/**changes/
> "
> 2. method: "GET"
>  2. delete: {href:http://reviews.**apache.org/api/review-**
>  
> requests/5345/,
>  method:DELETE}
> 1. href: "http://reviews.apache.**
> 
> org/api/review-requests/5345/
> "
> 2. method: "DELETE"
>  3. diffs: {href:http://reviews.**apache.org/api/review-**
>  
> requests/5345/diffs/,
>  method:GET}
> 1. href: "http://reviews.apache.**
> 
> org/api/review-requests/5345/**diffs/
> "
> 2. method: "GET"
>  4. draft: {href:http://reviews.**apache.org/api/review-**
>  
> requests/5345/draft/,
>  method:GET}
> 1. href: "http://reviews.apache.**
> 
> org/api/review-requests/5345/**draft/
> "
> 2. method: "GET"
>  5. file_attachments: {href:http:/**/reviews.apache.org/api/**
>  
> review-requests/5345/file-**attachments/,
>  method:GET}
> 1. href: "http://reviews.apache.**
> 
> org/api/review-requests/53

Re: Upgraded OS , then ReviewBoard failed upgrade

2012-06-18 Thread Dan Dumont 
I set https, but it never seemed to stick.

Not sure if you've ever tested this deployment, but our server sits behind
a reverse proxy and ssl is terminated at the proxy, so the review site
machine never gets requests in on https.
It always sees http, and I think that's what's confusing whatever is
building the urls.

On Mon, Jun 18, 2012 at 5:49 AM, Christian Hammond wrote:

> Hi Dan,
>
> Glad you got it working. I haven't really been available much this weekend.
>
> Thanks for the bug report. Should be an easy fix. However, I haven't seen
> that or the need for the SetEnv come up yet. Does your Server URL in the
> admin settings page use https or http? Setting that to https *should* do
> the right thing.
>
>
> Christian
>
> --
> Christian Hammond - chip...@chipx86.com
> Review Board - http://www.reviewboard.org
> VMware, Inc. - http://www.vmware.com
>
>
> On Sat, Jun 16, 2012 at 9:15 PM, Dan Dumont  wrote:
>
>> SetEnv HTTPS on
>> In the apache config worked like a charm though.
>>
>> I did end up filing this issue
>> http://code.google.com/p/reviewboard/issues/detail?id=2639
>> I'm not sure yet if this will cause problems now that I've solved the
>> redirect https issues.
>>
>>
>> On Sat, Jun 16, 2012 at 11:56 PM, Dan Dumont  wrote:
>>
>>> I found
>>> https://groups.google.com/forum/?fromgroups#!topic/reviewboard/yIOamU1uvIY
>>>
>>> But I tried setting
>>>
 os.environ['HTTPS'] = "on"
>>>
>>>
>>> In the reviewboard.wsgi file, but no dice.  I'm pretty sure we have a
>>> reverse proxy of some sort in front of us terminating SSL at the the border.
>>> Would be nice if you guys could just return protocol relative urls  //
>>> reviewboard.apache.org/etc...
>>>
>>> Any advice on where to stick that config setting to force https urls?
>>>
>>> On Saturday, June 16, 2012 11:16:27 PM UTC-4, Dan Dumont wrote:

 Request URL:
 https://reviews.apache.org/**api/review-requests/5345/?api_**
 format=json

 responds:


1. review_request: {status:**pending, last_updated:2012-06-17
02:58:20, description:,…}
   1. branch: ""
   2. bugs_closed: []
   3. changenum: null
   4. description: ""
   5. id: 5345
   6. last_updated: "2012-06-17 02:58:20"
   7. links: {diffs:{href:http://**reviews.apache.org/api/review-**
   
 requests/5345/diffs/,
   method:GET},…}
  1. changes: {href:http://reviews.**apache.org/api/review-**
  
 requests/5345/changes/,
  method:GET}
 1. href: "http://reviews.apache.**
 
 org/api/review-requests/5345/**changes/
 "
 2. method: "GET"
  2. delete: {href:http://reviews.**apache.org/api/review-**
  
 requests/5345/,
  method:DELETE}
 1. href: "http://reviews.apache.**
 
 org/api/review-requests/5345/
 "
 2. method: "DELETE"
  3. diffs: {href:http://reviews.**apache.org/api/review-**
  
 requests/5345/diffs/,
  method:GET}
 1. href: "http://reviews.apache.**
 
 org/api/review-requests/5345/**diffs/
 "
 2. method: "GET"
  4. draft: {href:http://reviews.**apache.org/api/review-**
  
 requests/5345/draft/,
  method:GET}
 1. href: "http://reviews.apache.**
 
 org/api/review-requests/5345/**draft/
 "
 2. method: "GET"
  5. file_attachments: {href:http:/**/reviews.apache.org/api/**
  
 review-requests/5345/file-**attachments/,
  method:GET}
 1. href: "http://reviews.apache.**
 
 org/api/review-requests/5345/**file-attachments/
 "
 2. method: "GET"
  6. last_update: {href:http://**reviews.apache.org/api/review-*
  
 *requests/5345/last-update/,
  method:GET}
 1. href: "http://reviews.apache.**
 
 org/a

Re: Upgraded OS , then ReviewBoard failed upgrade

2012-06-18 Thread Christian Hammond 
Hi Dan,

Glad you got it working. I haven't really been available much this weekend.

Thanks for the bug report. Should be an easy fix. However, I haven't seen
that or the need for the SetEnv come up yet. Does your Server URL in the
admin settings page use https or http? Setting that to https *should* do
the right thing.

Christian

-- 
Christian Hammond - chip...@chipx86.com
Review Board - http://www.reviewboard.org
VMware, Inc. - http://www.vmware.com


On Sat, Jun 16, 2012 at 9:15 PM, Dan Dumont  wrote:

> SetEnv HTTPS on
> In the apache config worked like a charm though.
>
> I did end up filing this issue
> http://code.google.com/p/reviewboard/issues/detail?id=2639
> I'm not sure yet if this will cause problems now that I've solved the
> redirect https issues.
>
>
> On Sat, Jun 16, 2012 at 11:56 PM, Dan Dumont  wrote:
>
>> I found
>> https://groups.google.com/forum/?fromgroups#!topic/reviewboard/yIOamU1uvIY
>>
>> But I tried setting
>>
>>> os.environ['HTTPS'] = "on"
>>
>>
>> In the reviewboard.wsgi file, but no dice.  I'm pretty sure we have a
>> reverse proxy of some sort in front of us terminating SSL at the the border.
>> Would be nice if you guys could just return protocol relative urls  //
>> reviewboard.apache.org/etc...
>>
>> Any advice on where to stick that config setting to force https urls?
>>
>> On Saturday, June 16, 2012 11:16:27 PM UTC-4, Dan Dumont wrote:
>>>
>>> Request URL:
>>> https://reviews.apache.org/**api/review-requests/5345/?api_**format=json
>>>
>>> responds:
>>>
>>>
>>>1. review_request: {status:**pending, last_updated:2012-06-17
>>>02:58:20, description:,…}
>>>   1. branch: ""
>>>   2. bugs_closed: []
>>>   3. changenum: null
>>>   4. description: ""
>>>   5. id: 5345
>>>   6. last_updated: "2012-06-17 02:58:20"
>>>   7. links: {diffs:{href:http://**reviews.apache.org/api/review-**
>>>   
>>> requests/5345/diffs/,
>>>   method:GET},…}
>>>  1. changes: {href:http://reviews.**apache.org/api/review-**
>>>  
>>> requests/5345/changes/,
>>>  method:GET}
>>> 1. href: "http://reviews.apache.**
>>> 
>>> org/api/review-requests/5345/**changes/
>>> "
>>> 2. method: "GET"
>>>  2. delete: {href:http://reviews.**apache.org/api/review-**
>>>  
>>> requests/5345/,
>>>  method:DELETE}
>>> 1. href: "http://reviews.apache.**
>>> 
>>> org/api/review-requests/5345/
>>> "
>>> 2. method: "DELETE"
>>>  3. diffs: {href:http://reviews.**apache.org/api/review-**
>>>  
>>> requests/5345/diffs/,
>>>  method:GET}
>>> 1. href: "http://reviews.apache.**
>>> 
>>> org/api/review-requests/5345/**diffs/
>>> "
>>> 2. method: "GET"
>>>  4. draft: {href:http://reviews.**apache.org/api/review-**
>>>  
>>> requests/5345/draft/,
>>>  method:GET}
>>> 1. href: "http://reviews.apache.**
>>> 
>>> org/api/review-requests/5345/**draft/
>>> "
>>> 2. method: "GET"
>>>  5. file_attachments: {href:http:/**/reviews.apache.org/api/**
>>>  
>>> review-requests/5345/file-**attachments/,
>>>  method:GET}
>>> 1. href: "http://reviews.apache.**
>>> 
>>> org/api/review-requests/5345/**file-attachments/
>>> "
>>> 2. method: "GET"
>>>  6. last_update: {href:http://**reviews.apache.org/api/review-**
>>>  
>>> requests/5345/last-update/,
>>>  method:GET}
>>> 1. href: "http://reviews.apache.**
>>> 
>>> org/api/review-requests/5345/**last-update/
>>> "
>>> 2. method: "GET"
>>>  7. repository: {href:http://**reviews.apache.org/api/**
>>>  repositories/11/,
>>>  method:GET, title:shindig}
>>> 1. href: 
>>> "http://reviews.apache.**org/api/repositories/11/
>>> "
>>> 2. method:

Re: Upgraded OS , then ReviewBoard failed upgrade

2012-06-16 Thread Dan Dumont 
SetEnv HTTPS on
In the apache config worked like a charm though.

I did end up filing this issue
http://code.google.com/p/reviewboard/issues/detail?id=2639
I'm not sure yet if this will cause problems now that I've solved the
redirect https issues.

On Sat, Jun 16, 2012 at 11:56 PM, Dan Dumont  wrote:

> I found
> https://groups.google.com/forum/?fromgroups#!topic/reviewboard/yIOamU1uvIY
>
> But I tried setting
>
>> os.environ['HTTPS'] = "on"
>
>
> In the reviewboard.wsgi file, but no dice.  I'm pretty sure we have a
> reverse proxy of some sort in front of us terminating SSL at the the border.
> Would be nice if you guys could just return protocol relative urls  //
> reviewboard.apache.org/etc...
>
> Any advice on where to stick that config setting to force https urls?
>
> On Saturday, June 16, 2012 11:16:27 PM UTC-4, Dan Dumont wrote:
>>
>> Request URL:
>> https://reviews.apache.org/**api/review-requests/5345/?api_**format=json
>>
>> responds:
>>
>>
>>1. review_request: {status:**pending, last_updated:2012-06-17
>>02:58:20, description:,…}
>>   1. branch: ""
>>   2. bugs_closed: []
>>   3. changenum: null
>>   4. description: ""
>>   5. id: 5345
>>   6. last_updated: "2012-06-17 02:58:20"
>>   7. links: {diffs:{href:http://**reviews.apache.org/api/review-**
>>   
>> requests/5345/diffs/,
>>   method:GET},…}
>>  1. changes: {href:http://reviews.**apache.org/api/review-**
>>  
>> requests/5345/changes/,
>>  method:GET}
>> 1. href: "http://reviews.apache.**
>> 
>> org/api/review-requests/5345/**changes/
>> "
>> 2. method: "GET"
>>  2. delete: {href:http://reviews.**apache.org/api/review-**
>>  requests/5345/,
>>  method:DELETE}
>> 1. href: "http://reviews.apache.**
>> 
>> org/api/review-requests/5345/
>> "
>> 2. method: "DELETE"
>>  3. diffs: {href:http://reviews.**apache.org/api/review-**
>>  
>> requests/5345/diffs/,
>>  method:GET}
>> 1. href: "http://reviews.apache.**
>> 
>> org/api/review-requests/5345/**diffs/
>> "
>> 2. method: "GET"
>>  4. draft: {href:http://reviews.**apache.org/api/review-**
>>  
>> requests/5345/draft/,
>>  method:GET}
>> 1. href: "http://reviews.apache.**
>> 
>> org/api/review-requests/5345/**draft/
>> "
>> 2. method: "GET"
>>  5. file_attachments: {href:http:/**/reviews.apache.org/api/**
>>  
>> review-requests/5345/file-**attachments/,
>>  method:GET}
>> 1. href: "http://reviews.apache.**
>> 
>> org/api/review-requests/5345/**file-attachments/
>> "
>> 2. method: "GET"
>>  6. last_update: {href:http://**reviews.apache.org/api/review-**
>>  
>> requests/5345/last-update/,
>>  method:GET}
>> 1. href: "http://reviews.apache.**
>> 
>> org/api/review-requests/5345/**last-update/
>> "
>> 2. method: "GET"
>>  7. repository: {href:http://**reviews.apache.org/api/**
>>  repositories/11/,
>>  method:GET, title:shindig}
>> 1. href: 
>> "http://reviews.apache.**org/api/repositories/11/
>> "
>> 2. method: "GET"
>> 3. title: "shindig"
>>  8. reviews: {href:http://reviews.**apache.org/api/review-**
>>  
>> requests/5345/reviews/,
>>  method:GET}
>> 1. href: "http://reviews.apache.**
>> 
>> org/api/review-requests/5345/**reviews/
>> "
>> 2. method: "GET"
>>  9. screenshots: {href:http://**reviews.apache.org/api/review-**
>>  
>> requests/5345/screenshots/

Re: Upgraded OS , then ReviewBoard failed upgrade

2012-06-16 Thread Dan Dumont 
I found  
https://groups.google.com/forum/?fromgroups#!topic/reviewboard/yIOamU1uvIY 
But I tried setting 

> os.environ['HTTPS'] = "on"


In the reviewboard.wsgi file, but no dice.  I'm pretty sure we have a 
reverse proxy of some sort in front of us terminating SSL at the the border.
Would be nice if you guys could just return protocol relative urls 
 //reviewboard.apache.org/etc...

Any advice on where to stick that config setting to force https urls?

On Saturday, June 16, 2012 11:16:27 PM UTC-4, Dan Dumont wrote:
>
> Request URL:
> https://reviews.apache.org/api/review-requests/5345/?api_format=json
>  
> responds:
>
>
>1. review_request: {status:pending, last_updated:2012-06-17 02:58:20, 
>description:,…}
>   1. branch: ""
>   2. bugs_closed: []
>   3. changenum: null
>   4. description: ""
>   5. id: 5345
>   6. last_updated: "2012-06-17 02:58:20"
>   7. links: {diffs:{href:
>   http://reviews.apache.org/api/review-requests/5345/diffs/, 
>   method:GET},…}
>  1. changes: {href:
>  http://reviews.apache.org/api/review-requests/5345/changes/, 
>  method:GET}
> 1. href: "
> http://reviews.apache.org/api/review-requests/5345/changes/";
> 2. method: "GET"
>  2. delete: {href:
>  http://reviews.apache.org/api/review-requests/5345/, 
>  method:DELETE}
> 1. href: "http://reviews.apache.org/api/review-requests/5345/";
> 2. method: "DELETE"
>  3. diffs: {href:
>  http://reviews.apache.org/api/review-requests/5345/diffs/, 
>  method:GET}
> 1. href: "
> http://reviews.apache.org/api/review-requests/5345/diffs/";
> 2. method: "GET"
>  4. draft: {href:
>  http://reviews.apache.org/api/review-requests/5345/draft/, 
>  method:GET}
> 1. href: "
> http://reviews.apache.org/api/review-requests/5345/draft/";
> 2. method: "GET"
>  5. file_attachments: {href:
>  
> http://reviews.apache.org/api/review-requests/5345/file-attachments/, 
>  method:GET}
> 1. href: "
> 
> http://reviews.apache.org/api/review-requests/5345/file-attachments/
> "
> 2. method: "GET"
>  6. last_update: {href:
>  http://reviews.apache.org/api/review-requests/5345/last-update/, 
>  method:GET}
> 1. href: "
> http://reviews.apache.org/api/review-requests/5345/last-update/
> "
> 2. method: "GET"
>  7. repository: {href:
>  http://reviews.apache.org/api/repositories/11/, method:GET, 
>  title:shindig}
> 1. href: "http://reviews.apache.org/api/repositories/11/";
> 2. method: "GET"
> 3. title: "shindig"
>  8. reviews: {href:
>  http://reviews.apache.org/api/review-requests/5345/reviews/, 
>  method:GET}
> 1. href: "
> http://reviews.apache.org/api/review-requests/5345/reviews/";
> 2. method: "GET"
>  9. screenshots: {href:
>  http://reviews.apache.org/api/review-requests/5345/screenshots/, 
>  method:GET}
> 1. href: "
> http://reviews.apache.org/api/review-requests/5345/screenshots/
> "
> 2. method: "GET"
>  10. self: {href:
>  http://reviews.apache.org/api/review-requests/5345/, method:GET}
> 1. href: "http://reviews.apache.org/api/review-requests/5345/";
> 2. method: "GET"
>  11. submitter: {href:http://reviews.apache.org/api/users/ddumont/, 
>  method:GET, title:ddumont}
> 1. href: "http://reviews.apache.org/api/users/ddumont/";
> 2. method: "GET"
> 3. title: "ddumont"
>  12. update: {href:
>  http://reviews.apache.org/api/review-requests/5345/, method:PUT}
> 1. href: "http://reviews.apache.org/api/review-requests/5345/";
> 2. method: "PUT"
>  8. public: false
>   9. status: "pending"
>   10. summary: ""
>   11. target_groups: []
>   12. target_people: []
>   13. testing_done: ""
>   14. time_added: "2012-06-17 02:58:19"
>2. stat: "ok"
>
> Is there a setting I'm missing that controls the protocol?
>
> On Saturday, June 16, 2012 9:50:36 PM UTC-4, Dan Dumont wrote:
>>
>> Ahh ok.  So a bit more info:
>>
>> http://stackoverflow.com/questions/228225/prevent-redirection-of-xmlhttprequest
>>  
>>  If the origin of the URL conveyed by the Location header is same 
>>  origin with the XMLHttpRequest origin and the redirect does not 
>>  violate infinite loop precautions, transparently follow the 
>>  redirect while observing the same-origin request event rules.
>>
>> I'm assuming origin here works the same as normal SOP browser stuff, so 
>> http -> https will break. 
>> How are you crafting the api

Re: Upgraded OS , then ReviewBoard failed upgrade

2012-06-16 Thread Dan Dumont 
Request URL:
https://reviews.apache.org/api/review-requests/5345/?api_format=json
 
responds:


   1. review_request: {status:pending, last_updated:2012-06-17 02:58:20, 
   description:,…}
  1. branch: ""
  2. bugs_closed: []
  3. changenum: null
  4. description: ""
  5. id: 5345
  6. last_updated: "2012-06-17 02:58:20"
  7. links: 
{diffs:{href:http://reviews.apache.org/api/review-requests/5345/diffs/, 
  method:GET},…}
 1. changes: 
{href:http://reviews.apache.org/api/review-requests/5345/changes/, 
 method:GET}
1. href: 
"http://reviews.apache.org/api/review-requests/5345/changes/";
2. method: "GET"
 2. delete: {href:http://reviews.apache.org/api/review-requests/5345/, 
 method:DELETE}
1. href: "http://reviews.apache.org/api/review-requests/5345/";
2. method: "DELETE"
 3. diffs: 
{href:http://reviews.apache.org/api/review-requests/5345/diffs/, 
 method:GET}
1. href: 
"http://reviews.apache.org/api/review-requests/5345/diffs/";
2. method: "GET"
 4. draft: 
{href:http://reviews.apache.org/api/review-requests/5345/draft/, 
 method:GET}
1. href: 
"http://reviews.apache.org/api/review-requests/5345/draft/";
2. method: "GET"
 5. file_attachments: 
{href:http://reviews.apache.org/api/review-requests/5345/file-attachments/, 
 method:GET}
1. href: 

"http://reviews.apache.org/api/review-requests/5345/file-attachments/";
2. method: "GET"
 6. last_update: 
{href:http://reviews.apache.org/api/review-requests/5345/last-update/, 
 method:GET}
1. href: 
"http://reviews.apache.org/api/review-requests/5345/last-update/";
2. method: "GET"
 7. repository: {href:http://reviews.apache.org/api/repositories/11/, 
 method:GET, title:shindig}
1. href: "http://reviews.apache.org/api/repositories/11/";
2. method: "GET"
3. title: "shindig"
 8. reviews: 
{href:http://reviews.apache.org/api/review-requests/5345/reviews/, 
 method:GET}
1. href: 
"http://reviews.apache.org/api/review-requests/5345/reviews/";
2. method: "GET"
 9. screenshots: 
{href:http://reviews.apache.org/api/review-requests/5345/screenshots/, 
 method:GET}
1. href: 
"http://reviews.apache.org/api/review-requests/5345/screenshots/";
2. method: "GET"
 10. self: {href:http://reviews.apache.org/api/review-requests/5345/, 
 method:GET}
1. href: "http://reviews.apache.org/api/review-requests/5345/";
2. method: "GET"
 11. submitter: {href:http://reviews.apache.org/api/users/ddumont/, 
 method:GET, title:ddumont}
1. href: "http://reviews.apache.org/api/users/ddumont/";
2. method: "GET"
3. title: "ddumont"
 12. update: {href:http://reviews.apache.org/api/review-requests/5345/, 
 method:PUT}
1. href: "http://reviews.apache.org/api/review-requests/5345/";
2. method: "PUT"
 8. public: false
  9. status: "pending"
  10. summary: ""
  11. target_groups: []
  12. target_people: []
  13. testing_done: ""
  14. time_added: "2012-06-17 02:58:19"
   2. stat: "ok"

Is there a setting I'm missing that controls the protocol?

On Saturday, June 16, 2012 9:50:36 PM UTC-4, Dan Dumont wrote:
>
> Ahh ok.  So a bit more info:
>
> http://stackoverflow.com/questions/228225/prevent-redirection-of-xmlhttprequest
>  
>  If the origin of the URL conveyed by the Location header is same 
>  origin with the XMLHttpRequest origin and the redirect does not 
>  violate infinite loop precautions, transparently follow the 
>  redirect while observing the same-origin request event rules.
>
> I'm assuming origin here works the same as normal SOP browser stuff, so 
> http -> https will break. 
> How are you crafting the api url for the post (not all the api calls fail, 
> some of them are flaky occasionally though).  Do you use a protocol 
> relative url?  //reviews.apache.org/path/to/api
> or do you build it off of some variable in the config?
>
> On Saturday, June 16, 2012 9:37:11 PM UTC-4, Dan Dumont wrote:
>>
>> Didn't touch the apache config.
>> It's a http -> https redirect (no idea why the browser isn't simply 
>> following it, do ajax requests eat the 301 errors?  I can't remember).
>> This is a brand new draft.
>>
>> On Saturday, June 16, 2012 9:31:26 PM UTC-4, Christian Hammond wrote:
>>>
>>> Hi Dan,
>>>
>>> It looks like it's redirecting to the URL it's already at? Is that right?
>>>
>>> Do any URLs but that cause a redirect?
>>>
>>> Was this an existing draft in the database, or a brand new one?
>>>
>>> And also, did you have to reconfigure the settings/Apa

Re: Upgraded OS , then ReviewBoard failed upgrade

2012-06-16 Thread Dan Dumont 
Ahh ok.  So a bit more info:
http://stackoverflow.com/questions/228225/prevent-redirection-of-xmlhttprequest
 
 If the origin of the URL conveyed by the Location header is same 
 origin with the XMLHttpRequest origin and the redirect does not 
 violate infinite loop precautions, transparently follow the 
 redirect while observing the same-origin request event rules.

I'm assuming origin here works the same as normal SOP browser stuff, so 
http -> https will break. 
How are you crafting the api url for the post (not all the api calls fail, 
some of them are flaky occasionally though).  Do you use a protocol 
relative url?  //reviews.apache.org/path/to/api
or do you build it off of some variable in the config?

On Saturday, June 16, 2012 9:37:11 PM UTC-4, Dan Dumont wrote:
>
> Didn't touch the apache config.
> It's a http -> https redirect (no idea why the browser isn't simply 
> following it, do ajax requests eat the 301 errors?  I can't remember).
> This is a brand new draft.
>
> On Saturday, June 16, 2012 9:31:26 PM UTC-4, Christian Hammond wrote:
>>
>> Hi Dan,
>>
>> It looks like it's redirecting to the URL it's already at? Is that right?
>>
>> Do any URLs but that cause a redirect?
>>
>> Was this an existing draft in the database, or a brand new one?
>>
>> And also, did you have to reconfigure the settings/Apache configuration 
>> at all, or is that all the same from before?
>>
>> Christian
>>
>> -- 
>> Christian Hammond - chip...@chipx86.com
>> Review Board - http://www.reviewboard.org
>> VMware, Inc. - http://www.vmware.com
>>
>>
>> On Sat, Jun 16, 2012 at 4:53 PM, Dan Dumont  wrote:
>>
>>> Hi Christian, 
>>> I got things mostly up and running again by reconstructing the sql 
>>> tables in a new 1.5.5 install and then upgrading that.
>>>
>>> Having some difficulty at the site though.   Many different api problems 
>>> it looks like.
>>> I can't publish drafts, getting a 301:
>>>
>>> OPTIONS /api/review-requests/5335/draft/ HTTP/1.1
>>> Host: reviews.apache.org
>>> Connection: keep-alive
>>> Access-Control-Request-Method: PUT
>>> Origin: https://reviews.apache.org
>>> User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/536.11 
>>> (KHTML, like Gecko) Chrome/20.0.1132.34 Safari/536.11
>>> Access-Control-Request-Headers: origin, x-requested-with, content-type, 
>>> accept
>>> Accept: */*
>>> Accept-Encoding: gzip,deflate,sdch
>>> Accept-Language: en-US,en;q=0.8
>>> Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.3
>>>
>>> -
>>> HTTP/1.1 301 Moved Permanently
>>> Date: Sat, 16 Jun 2012 23:51:28 GMT
>>> Server: Apache/2.2.20 (Ubuntu)
>>> Location: https://reviews.apache.org/api/review-requests/5335/draft/
>>> Vary: Accept-Encoding
>>> Content-Encoding: gzip
>>> Content-Length: 263
>>> Keep-Alive: timeout=5, max=100
>>> Connection: Keep-Alive
>>> Content-Type: text/html; charset=iso-8859-1
>>>
>>> Can you help me troubleshoot this?
>>>
>>>  -- 
>>> Want to help the Review Board project? Donate today at 
>>> http://www.reviewboard.org/donate/
>>> Happy user? Let us know at http://www.reviewboard.org/users/
>>> -~--~~~~--~~--~--~---
>>> To unsubscribe from this group, send email to 
>>> reviewboard+unsubscr...@googlegroups.com
>>> For more options, visit this group at 
>>> http://groups.google.com/group/reviewboard?hl=en
>>>
>>
>>

-- 
Want to help the Review Board project? Donate today at 
http://www.reviewboard.org/donate/
Happy user? Let us know at http://www.reviewboard.org/users/
-~--~~~~--~~--~--~---
To unsubscribe from this group, send email to 
reviewboard+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/reviewboard?hl=en

Re: Upgraded OS , then ReviewBoard failed upgrade

2012-06-16 Thread Dan Dumont 
Didn't touch the apache config.
It's a http -> https redirect (no idea why the browser isn't simply 
following it, do ajax requests eat the 301 errors?  I can't remember).
This is a brand new draft.

On Saturday, June 16, 2012 9:31:26 PM UTC-4, Christian Hammond wrote:
>
> Hi Dan,
>
> It looks like it's redirecting to the URL it's already at? Is that right?
>
> Do any URLs but that cause a redirect?
>
> Was this an existing draft in the database, or a brand new one?
>
> And also, did you have to reconfigure the settings/Apache configuration at 
> all, or is that all the same from before?
>
> Christian
>
> -- 
> Christian Hammond - chip...@chipx86.com
> Review Board - http://www.reviewboard.org
> VMware, Inc. - http://www.vmware.com
>
>
> On Sat, Jun 16, 2012 at 4:53 PM, Dan Dumont  wrote:
>
>> Hi Christian, 
>> I got things mostly up and running again by reconstructing the sql tables 
>> in a new 1.5.5 install and then upgrading that.
>>
>> Having some difficulty at the site though.   Many different api problems 
>> it looks like.
>> I can't publish drafts, getting a 301:
>>
>> OPTIONS /api/review-requests/5335/draft/ HTTP/1.1
>> Host: reviews.apache.org
>> Connection: keep-alive
>> Access-Control-Request-Method: PUT
>> Origin: https://reviews.apache.org
>> User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/536.11 
>> (KHTML, like Gecko) Chrome/20.0.1132.34 Safari/536.11
>> Access-Control-Request-Headers: origin, x-requested-with, content-type, 
>> accept
>> Accept: */*
>> Accept-Encoding: gzip,deflate,sdch
>> Accept-Language: en-US,en;q=0.8
>> Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.3
>>
>> -
>> HTTP/1.1 301 Moved Permanently
>> Date: Sat, 16 Jun 2012 23:51:28 GMT
>> Server: Apache/2.2.20 (Ubuntu)
>> Location: https://reviews.apache.org/api/review-requests/5335/draft/
>> Vary: Accept-Encoding
>> Content-Encoding: gzip
>> Content-Length: 263
>> Keep-Alive: timeout=5, max=100
>> Connection: Keep-Alive
>> Content-Type: text/html; charset=iso-8859-1
>>
>> Can you help me troubleshoot this?
>>
>>  -- 
>> Want to help the Review Board project? Donate today at 
>> http://www.reviewboard.org/donate/
>> Happy user? Let us know at http://www.reviewboard.org/users/
>> -~--~~~~--~~--~--~---
>> To unsubscribe from this group, send email to 
>> reviewboard+unsubscr...@googlegroups.com
>> For more options, visit this group at 
>> http://groups.google.com/group/reviewboard?hl=en
>>
>
>

-- 
Want to help the Review Board project? Donate today at 
http://www.reviewboard.org/donate/
Happy user? Let us know at http://www.reviewboard.org/users/
-~--~~~~--~~--~--~---
To unsubscribe from this group, send email to 
reviewboard+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/reviewboard?hl=en

Re: Upgraded OS , then ReviewBoard failed upgrade

2012-06-16 Thread Christian Hammond 
Hi Dan,

It looks like it's redirecting to the URL it's already at? Is that right?

Do any URLs but that cause a redirect?

Was this an existing draft in the database, or a brand new one?

And also, did you have to reconfigure the settings/Apache configuration at
all, or is that all the same from before?

Christian

-- 
Christian Hammond - chip...@chipx86.com
Review Board - http://www.reviewboard.org
VMware, Inc. - http://www.vmware.com


On Sat, Jun 16, 2012 at 4:53 PM, Dan Dumont  wrote:

> Hi Christian,
> I got things mostly up and running again by reconstructing the sql tables
> in a new 1.5.5 install and then upgrading that.
>
> Having some difficulty at the site though.   Many different api problems
> it looks like.
> I can't publish drafts, getting a 301:
>
> OPTIONS /api/review-requests/5335/draft/ HTTP/1.1
> Host: reviews.apache.org
> Connection: keep-alive
> Access-Control-Request-Method: PUT
> Origin: https://reviews.apache.org
> User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/536.11 (KHTML,
> like Gecko) Chrome/20.0.1132.34 Safari/536.11
> Access-Control-Request-Headers: origin, x-requested-with, content-type,
> accept
> Accept: */*
> Accept-Encoding: gzip,deflate,sdch
> Accept-Language: en-US,en;q=0.8
> Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.3
>
> -
> HTTP/1.1 301 Moved Permanently
> Date: Sat, 16 Jun 2012 23:51:28 GMT
> Server: Apache/2.2.20 (Ubuntu)
> Location: https://reviews.apache.org/api/review-requests/5335/draft/
> Vary: Accept-Encoding
> Content-Encoding: gzip
> Content-Length: 263
> Keep-Alive: timeout=5, max=100
> Connection: Keep-Alive
> Content-Type: text/html; charset=iso-8859-1
>
> Can you help me troubleshoot this?
>
>  --
> Want to help the Review Board project? Donate today at
> http://www.reviewboard.org/donate/
> Happy user? Let us know at http://www.reviewboard.org/users/
> -~--~~~~--~~--~--~---
> To unsubscribe from this group, send email to
> reviewboard+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/reviewboard?hl=en
>

-- 
Want to help the Review Board project? Donate today at 
http://www.reviewboard.org/donate/
Happy user? Let us know at http://www.reviewboard.org/users/
-~--~~~~--~~--~--~---
To unsubscribe from this group, send email to 
reviewboard+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/reviewboard?hl=en

Re: Upgraded OS , then ReviewBoard failed upgrade

2012-06-16 Thread Dan Dumont 
Hi Christian, 
I got things mostly up and running again by reconstructing the sql tables 
in a new 1.5.5 install and then upgrading that.

Having some difficulty at the site though.   Many different api problems it 
looks like.
I can't publish drafts, getting a 301:

OPTIONS /api/review-requests/5335/draft/ HTTP/1.1
Host: reviews.apache.org
Connection: keep-alive
Access-Control-Request-Method: PUT
Origin: https://reviews.apache.org
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/536.11 (KHTML, 
like Gecko) Chrome/20.0.1132.34 Safari/536.11
Access-Control-Request-Headers: origin, x-requested-with, content-type, 
accept
Accept: */*
Accept-Encoding: gzip,deflate,sdch
Accept-Language: en-US,en;q=0.8
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.3
-
HTTP/1.1 301 Moved Permanently
Date: Sat, 16 Jun 2012 23:51:28 GMT
Server: Apache/2.2.20 (Ubuntu)
Location: https://reviews.apache.org/api/review-requests/5335/draft/
Vary: Accept-Encoding
Content-Encoding: gzip
Content-Length: 263
Keep-Alive: timeout=5, max=100
Connection: Keep-Alive
Content-Type: text/html; charset=iso-8859-1

Can you help me troubleshoot this?

-- 
Want to help the Review Board project? Donate today at 
http://www.reviewboard.org/donate/
Happy user? Let us know at http://www.reviewboard.org/users/
-~--~~~~--~~--~--~---
To unsubscribe from this group, send email to 
reviewboard+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/reviewboard?hl=en

Re: Upgraded OS , then ReviewBoard failed upgrade

2012-06-15 Thread Christian Hammond 
Hi,

Yeah, this is sounding very messed up, and I don't understand how you're in 
this state.

One last-ditch effort would be to restore whatever SQL dump you have on the 
appropriate version (previous version of RB would be best), then try to create 
a brand new database with that version, load in the database, delete the tables 
starting with "django_evolution_", and then try an upgrade.

That may not work, but I don't know what else to recommend, since I have no 
idea what caused this to get so inconsistent.

It's possible we could help restore this, but we'd need the whole database dump 
and would need to charge for the time under our company, Beanbag. There 
wouldn't be any guarantees, but if you're completely stuck and want to explore 
that, let me know.

Christian


On Jun 15, 2012, at 15:59, "Gav..."  wrote:

> Hi,
>  
> Deleted that column, and a few more that came up, then got stuck at this one:
>  
> Evolution could not be simulated, possibly due to raw SQL mutations
> Error: Error applying evolution: (1091, "Can't DROP 'name'; check that 
> column/key exists")
> Regarding exactly what I did, cant say exactly, but I just followed the usual 
> upgrade procedures, it worked fine
> when I did 1.5 to 1.5.5. The difference with this one is that I had just done 
> an 'do-release-upgrade' on the underlying OS, this then broke
> reviewboard as it wanted me to then upgrade which I did, then these issues 
> came up.
>  
> This is getting urgent now so if I cant recolve it today I may have to just 
> wipe it and start again.
>  
> Thanks for your help.
>  
> Gav...
> 
> On Sunday, June 10, 2012 1:26:38 PM UTC+9:30, Christian Hammond wrote:
> No, that should never have been reached. That shows you're in some 
> half-modified database state, which shouldn't have happened, given that 
> database transactions are used during the evolution and the earlier error 
> should have prevented the other modifications.
> 
> At this point, I really wish you had a database upgrade, because things are 
> kind of messed up. Make one now, just in case.
> 
> Once you have a full backup (SQL dump is best), try deleting that column. You 
> might get a few more like this.
> 
> Can you tel me exactly what you did, every step of the way, prior to and 
> after the initial rb-site upgrade?
> 
> Christian
> 
> -- 
> Christian Hammond - chip...@chipx86.com
> Review Board - http://www.reviewboard.org
> VMware, Inc. - http://www.vmware.com
> 
> 
> On Sat, Jun 9, 2012 at 8:47 PM, Gav...  wrote:
> 
> On Sunday, June 10, 2012 1:04:30 PM UTC+9:30, Christian Hammond wrote:
> Your upgrade apparently also upgraded to Review Board 1.6.7, which has many 
> significant changes. And that upgrade failed, because of the django_session 
> issue.
> 
> I've seen that django_session error before. Not sure what the cause is, but 
> basically, that's a database index that was created, and Django is trying to 
> re-create it now. You can try dropping it and see if that helps. You'll need 
> to connect to your MySQL database and do:
> 
> drop index django_session_c25c2c28 on django_session;
> 
> Then re-run the rb-site upgrade command on your site. Hopefully this will 
> work.
> 
> Christian
> 
>  
> Thanks for the reply, done that, now I get:
>  
> Error: Error applying evolution: (1060, "Duplicate column name 'is_private'")
>  
> Drop that too? from where?
>  
> Thanks
>  
> Gav...
>  
> -- 
> On Sat, Jun 9, 2012 at 7:43 PM, Gav...  wrote:
> Hi,
>  
> I was on RB 1.5.5 , then an upgrade of the Ubuntu OS to 12.04 LTS then broke 
> reviewboard (so it wanted to upgrade) so I ran an upgrade which has not been 
> successful. (Note I believe Python was upgraded from 2.6 to 2.7)
>  
> It seems to work until you go to the /admin/ areas.
>  
> Rebuilding directory structure
> Updating database. This may take a while.
> Creating tables ...
> There are unapplied evolutions for sessions.
> There are unapplied evolutions for accounts.
> There are unapplied evolutions for changedescs.
> There are unapplied evolutions for reviews.
> There are unapplied evolutions for scmtools.
> Project signature has changed - an evolution is required
> Installing custom SQL ...
> Installing indexes ...
> No fixtures found.
> Evolution could not be simulated, possibly due to raw SQL mutations
> Error: Error applying evolution: (1061, "Duplicate key name 
> 'django_session_c25c2c28'")
>  
> Tried this with the latest version 1.6.7.1
>  
> I also get emails with:
>  
> OperationalError: (1054, "Unknown column 'scmtools_repository.extra_data' in 
> 'field list'")
>  
> Any clues as to what to try next.?
>  
> As I was not expecting an OS upgrade to interfere with reviewboard, there is 
> no pre-upgrade db dump, and a rb-site manage . dbdump now fails
> with :
>  
> _mysql_exceptions.OperationalError: (1054, "Unknown column 
> 'scmtools_repository.extra_data' in 'field list'")
> Thanks
>  
> Gav...
> -- 
> Want to help the Review Board project? Donate today at 
> http://www.reviewboard.

Re: Upgraded OS , then ReviewBoard failed upgrade

2012-06-15 Thread Gav... 
Hi,
 
Deleted that column, and a few more that came up, then got stuck at this 
one:
 
Evolution could not be simulated, possibly due to raw SQL mutations
Error: Error applying evolution: (1091, "Can't DROP 'name'; check that 
column/key exists")
Regarding exactly what I did, cant say exactly, but I just followed the 
usual upgrade procedures, it worked fine
when I did 1.5 to 1.5.5. The difference with this one is that I had just 
done an 'do-release-upgrade' on the underlying OS, this then broke
reviewboard as it wanted me to then upgrade which I did, then these issues 
came up.
 
This is getting urgent now so if I cant recolve it today I may have to just 
wipe it and start again.
 
Thanks for your help.
 
Gav...

On Sunday, June 10, 2012 1:26:38 PM UTC+9:30, Christian Hammond wrote:

> No, that should never have been reached. That shows you're in some 
> half-modified database state, which shouldn't have happened, given that 
> database transactions are used during the evolution and the earlier error 
> should have prevented the other modifications.
>
> At this point, I really wish you had a database upgrade, because things 
> are kind of messed up. Make one now, just in case.
>
> Once you have a full backup (SQL dump is best), try deleting that column. 
> You might get a few more like this.
>
> Can you tel me exactly what you did, every step of the way, prior to and 
> after the initial rb-site upgrade?
>
> Christian
>
> -- 
> Christian Hammond - chip...@chipx86.com
> Review Board - http://www.reviewboard.org
> VMware, Inc. - http://www.vmware.com
>
>
> On Sat, Jun 9, 2012 at 8:47 PM, Gav...  wrote:
>
>>
>> On Sunday, June 10, 2012 1:04:30 PM UTC+9:30, Christian Hammond wrote:
>>>
>>> Your upgrade apparently also upgraded to Review Board 1.6.7, which has 
>>> many significant changes. And that upgrade failed, because of the 
>>> django_session issue.
>>>
>>> I've seen that django_session error before. Not sure what the cause is, 
>>> but basically, that's a database index that was created, and Django is 
>>> trying to re-create it now. You can try dropping it and see if that helps. 
>>> You'll need to connect to your MySQL database and do:
>>>
>>> drop index django_session_c25c2c28 on django_session;
>>>
>>> Then re-run the rb-site upgrade command on your site. Hopefully this 
>>> will work.
>>>
>>> Christian
>>>
>>>  
>> Thanks for the reply, done that, now I get:
>>  
>> Error: Error applying evolution: (1060, "Duplicate column name 
>> 'is_private'")
>>  
>> Drop that too? from where?
>>   
>> Thanks
>>  
>> Gav...
>>  
>>
>>> -- 
>>> On Sat, Jun 9, 2012 at 7:43 PM, Gav...  wrote:
>>>
 Hi,
  
 I was on RB 1.5.5 , then an upgrade of the Ubuntu OS to 12.04 LTS then 
 broke reviewboard (so it wanted to upgrade) so I ran an upgrade which has 
 not been successful. (Note I believe Python was upgraded from 2.6 to 2.7)
  
 It seems to work until you go to the /admin/ areas.
  
 Rebuilding directory structure
 Updating database. This may take a while.
 Creating tables ...
 There are unapplied evolutions for sessions.
 There are unapplied evolutions for accounts.
 There are unapplied evolutions for changedescs.
 There are unapplied evolutions for reviews.
 There are unapplied evolutions for scmtools.
 Project signature has changed - an evolution is required
 Installing custom SQL ...
 Installing indexes ...
 No fixtures found.
 Evolution could not be simulated, possibly due to raw SQL mutations
 Error: Error applying evolution: (1061, "Duplicate key name 
 'django_session_c25c2c28'")
  
 Tried this with the latest version 1.6.7.1
  
 I also get emails with:
  
 OperationalError: (1054, "Unknown column 
 'scmtools_repository.extra_**data' 
 in 'field list'")
  
 Any clues as to what to try next.?
  
 As I was not expecting an OS upgrade to interfere with reviewboard, 
 there is no pre-upgrade db dump, and a rb-site manage . dbdump now fails
 with :
  
 _mysql_exceptions.**OperationalError: (1054, "Unknown column 
 'scmtools_repository.extra_**data' in 'field list'")
 Thanks
  
 Gav...

 -- 
 Want to help the Review Board project? Donate today at 
 http://www.reviewboard.org/**donate/
 Happy user? Let us know at 
 http://www.reviewboard.org/**users/
 -~--~~~~--**~~--~--~---
 To unsubscribe from this group, send email to reviewboard+unsubscribe@*
 *googlegroups.com 
 For more options, visit this group at http://groups.google.com/**
 group/reviewboard?hl=en
>>>
>>>
>>>  -- 
>> Want to help the Review Board project? Donate today at 
>> http://www.reviewboard.org/donate/
>> Happy user? Let us know at http://www.reviewboard.org/users/
>> -~--

Re: Upgraded OS , then ReviewBoard failed upgrade

2012-06-09 Thread Christian Hammond 
No, that should never have been reached. That shows you're in some
half-modified database state, which shouldn't have happened, given that
database transactions are used during the evolution and the earlier error
should have prevented the other modifications.

At this point, I really wish you had a database upgrade, because things are
kind of messed up. Make one now, just in case.

Once you have a full backup (SQL dump is best), try deleting that column.
You might get a few more like this.

Can you tel me exactly what you did, every step of the way, prior to and
after the initial rb-site upgrade?

Christian

-- 
Christian Hammond - chip...@chipx86.com
Review Board - http://www.reviewboard.org
VMware, Inc. - http://www.vmware.com


On Sat, Jun 9, 2012 at 8:47 PM, Gav...  wrote:

>
> On Sunday, June 10, 2012 1:04:30 PM UTC+9:30, Christian Hammond wrote:
>>
>> Your upgrade apparently also upgraded to Review Board 1.6.7, which has
>> many significant changes. And that upgrade failed, because of the
>> django_session issue.
>>
>> I've seen that django_session error before. Not sure what the cause is,
>> but basically, that's a database index that was created, and Django is
>> trying to re-create it now. You can try dropping it and see if that helps.
>> You'll need to connect to your MySQL database and do:
>>
>> drop index django_session_c25c2c28 on django_session;
>>
>> Then re-run the rb-site upgrade command on your site. Hopefully this will
>> work.
>>
>> Christian
>>
>>
> Thanks for the reply, done that, now I get:
>
> Error: Error applying evolution: (1060, "Duplicate column name
> 'is_private'")
>
> Drop that too? from where?
>
> Thanks
>
> Gav...
>
>
>> --
>> On Sat, Jun 9, 2012 at 7:43 PM, Gav...  wrote:
>>
>>> Hi,
>>>
>>> I was on RB 1.5.5 , then an upgrade of the Ubuntu OS to 12.04 LTS then
>>> broke reviewboard (so it wanted to upgrade) so I ran an upgrade which has
>>> not been successful. (Note I believe Python was upgraded from 2.6 to 2.7)
>>>
>>> It seems to work until you go to the /admin/ areas.
>>>
>>> Rebuilding directory structure
>>> Updating database. This may take a while.
>>> Creating tables ...
>>> There are unapplied evolutions for sessions.
>>> There are unapplied evolutions for accounts.
>>> There are unapplied evolutions for changedescs.
>>> There are unapplied evolutions for reviews.
>>> There are unapplied evolutions for scmtools.
>>> Project signature has changed - an evolution is required
>>> Installing custom SQL ...
>>> Installing indexes ...
>>> No fixtures found.
>>> Evolution could not be simulated, possibly due to raw SQL mutations
>>> Error: Error applying evolution: (1061, "Duplicate key name
>>> 'django_session_c25c2c28'")
>>>
>>> Tried this with the latest version 1.6.7.1
>>>
>>> I also get emails with:
>>>
>>> OperationalError: (1054, "Unknown column 'scmtools_repository.extra_**data'
>>> in 'field list'")
>>>
>>> Any clues as to what to try next.?
>>>
>>> As I was not expecting an OS upgrade to interfere with reviewboard,
>>> there is no pre-upgrade db dump, and a rb-site manage . dbdump now fails
>>> with :
>>>
>>> _mysql_exceptions.**OperationalError: (1054, "Unknown column
>>> 'scmtools_repository.extra_**data' in 'field list'")
>>> Thanks
>>>
>>> Gav...
>>>
>>> --
>>> Want to help the Review Board project? Donate today at
>>> http://www.reviewboard.org/**donate/
>>> Happy user? Let us know at 
>>> http://www.reviewboard.org/**users/
>>> -~--~~~~--**~~--~--~---
>>> To unsubscribe from this group, send email to reviewboard+unsubscribe@**
>>> googlegroups.com 
>>> For more options, visit this group at http://groups.google.com/**
>>> group/reviewboard?hl=en
>>
>>
>>  --
> Want to help the Review Board project? Donate today at
> http://www.reviewboard.org/donate/
> Happy user? Let us know at http://www.reviewboard.org/users/
> -~--~~~~--~~--~--~---
> To unsubscribe from this group, send email to
> reviewboard+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/reviewboard?hl=en
>

-- 
Want to help the Review Board project? Donate today at 
http://www.reviewboard.org/donate/
Happy user? Let us know at http://www.reviewboard.org/users/
-~--~~~~--~~--~--~---
To unsubscribe from this group, send email to 
reviewboard+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/reviewboard?hl=en

Re: Upgraded OS , then ReviewBoard failed upgrade

2012-06-09 Thread Gav... 

On Sunday, June 10, 2012 1:04:30 PM UTC+9:30, Christian Hammond wrote:
>
> Your upgrade apparently also upgraded to Review Board 1.6.7, which has 
> many significant changes. And that upgrade failed, because of the 
> django_session issue.
>
> I've seen that django_session error before. Not sure what the cause is, 
> but basically, that's a database index that was created, and Django is 
> trying to re-create it now. You can try dropping it and see if that helps. 
> You'll need to connect to your MySQL database and do:
>
> drop index django_session_c25c2c28 on django_session;
>
> Then re-run the rb-site upgrade command on your site. Hopefully this will 
> work.
>
> Christian
>
>  
Thanks for the reply, done that, now I get:
 
Error: Error applying evolution: (1060, "Duplicate column name 
'is_private'")
 
Drop that too? from where?
 
Thanks
 
Gav...
 

> -- 
> On Sat, Jun 9, 2012 at 7:43 PM, Gav...  wrote:
>
>> Hi,
>>  
>> I was on RB 1.5.5 , then an upgrade of the Ubuntu OS to 12.04 LTS then 
>> broke reviewboard (so it wanted to upgrade) so I ran an upgrade which has 
>> not been successful. (Note I believe Python was upgraded from 2.6 to 2.7)
>>  
>> It seems to work until you go to the /admin/ areas.
>>  
>> Rebuilding directory structure
>> Updating database. This may take a while.
>> Creating tables ...
>> There are unapplied evolutions for sessions.
>> There are unapplied evolutions for accounts.
>> There are unapplied evolutions for changedescs.
>> There are unapplied evolutions for reviews.
>> There are unapplied evolutions for scmtools.
>> Project signature has changed - an evolution is required
>> Installing custom SQL ...
>> Installing indexes ...
>> No fixtures found.
>> Evolution could not be simulated, possibly due to raw SQL mutations
>> Error: Error applying evolution: (1061, "Duplicate key name 
>> 'django_session_c25c2c28'")
>>  
>> Tried this with the latest version 1.6.7.1
>>  
>> I also get emails with:
>>  
>> OperationalError: (1054, "Unknown column 'scmtools_repository.extra_data' 
>> in 'field list'")
>>  
>> Any clues as to what to try next.?
>>  
>> As I was not expecting an OS upgrade to interfere with reviewboard, there 
>> is no pre-upgrade db dump, and a rb-site manage . dbdump now fails
>> with :
>>  
>> _mysql_exceptions.OperationalError: (1054, "Unknown column 
>> 'scmtools_repository.extra_data' in 'field list'")
>> Thanks
>>  
>> Gav...
>>
>> -- 
>> Want to help the Review Board project? Donate today at 
>> http://www.reviewboard.org/donate/
>> Happy user? Let us know at http://www.reviewboard.org/users/
>> -~--~~~~--~~--~--~---
>> To unsubscribe from this group, send email to 
>> reviewboard+unsubscr...@googlegroups.com
>> For more options, visit this group at 
>> http://groups.google.com/group/reviewboard?hl=en
>
>
>

-- 
Want to help the Review Board project? Donate today at 
http://www.reviewboard.org/donate/
Happy user? Let us know at http://www.reviewboard.org/users/
-~--~~~~--~~--~--~---
To unsubscribe from this group, send email to 
reviewboard+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/reviewboard?hl=en

Re: Upgraded OS , then ReviewBoard failed upgrade

2012-06-09 Thread Christian Hammond 
Your upgrade apparently also upgraded to Review Board 1.6.7, which has many
significant changes. And that upgrade failed, because of the django_session
issue.

I've seen that django_session error before. Not sure what the cause is, but
basically, that's a database index that was created, and Django is trying
to re-create it now. You can try dropping it and see if that helps. You'll
need to connect to your MySQL database and do:

drop index django_session_c25c2c28 on django_session;

Then re-run the rb-site upgrade command on your site. Hopefully this will
work.

Christian

-- 
Christian Hammond - chip...@chipx86.com
Review Board - http://www.reviewboard.org
VMware, Inc. - http://www.vmware.com


On Sat, Jun 9, 2012 at 7:43 PM, Gav...  wrote:

> Hi,
>
> I was on RB 1.5.5 , then an upgrade of the Ubuntu OS to 12.04 LTS then
> broke reviewboard (so it wanted to upgrade) so I ran an upgrade which has
> not been successful. (Note I believe Python was upgraded from 2.6 to 2.7)
>
> It seems to work until you go to the /admin/ areas.
>
> Rebuilding directory structure
> Updating database. This may take a while.
> Creating tables ...
> There are unapplied evolutions for sessions.
> There are unapplied evolutions for accounts.
> There are unapplied evolutions for changedescs.
> There are unapplied evolutions for reviews.
> There are unapplied evolutions for scmtools.
> Project signature has changed - an evolution is required
> Installing custom SQL ...
> Installing indexes ...
> No fixtures found.
> Evolution could not be simulated, possibly due to raw SQL mutations
> Error: Error applying evolution: (1061, "Duplicate key name
> 'django_session_c25c2c28'")
>
> Tried this with the latest version 1.6.7.1
>
> I also get emails with:
>
> OperationalError: (1054, "Unknown column 'scmtools_repository.extra_data'
> in 'field list'")
>
> Any clues as to what to try next.?
>
> As I was not expecting an OS upgrade to interfere with reviewboard, there
> is no pre-upgrade db dump, and a rb-site manage . dbdump now fails
> with :
>
> _mysql_exceptions.OperationalError: (1054, "Unknown column
> 'scmtools_repository.extra_data' in 'field list'")
> Thanks
>
> Gav...
>
> --
> Want to help the Review Board project? Donate today at
> http://www.reviewboard.org/donate/
> Happy user? Let us know at http://www.reviewboard.org/users/
> -~--~~~~--~~--~--~---
> To unsubscribe from this group, send email to
> reviewboard+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/reviewboard?hl=en

-- 
Want to help the Review Board project? Donate today at 
http://www.reviewboard.org/donate/
Happy user? Let us know at http://www.reviewboard.org/users/
-~--~~~~--~~--~--~---
To unsubscribe from this group, send email to 
reviewboard+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/reviewboard?hl=en