Closed Bug 450310 (bmo-upgrade-32) Opened 13 years ago Closed 13 years ago
.m .o to 3 .2 RC1
Now that Bugzilla 3.2 reached its release candidate state, we should upgrade b.m.o to RC1. This will also help us catch remaining regressions and bugs before releasing 3.2. RedHat's Bugzilla is already running 3.2 RC1, and they reported no specific problem so far.
The current bmo 3.2 code is here: bzr://bzr.everythingsolved.com/mozilla/3.2 I just updated it to rc1. There were no merge conflicts, but I didn't test it.
For what it's worth, Everything Solved has other various customizations to deliver for bmo, but they are waiting on this.
(In reply to comment #1) > The current bmo 3.2 code is here: > > bzr://bzr.everythingsolved.com/mozilla/3.2 I cloned this to bzr://dm-bugstage01.mozilla.org/bmo/3.2 about a week or two ago. Just merged from yours again just now so it should be up-to-date again.
This has been up (without the GPG patch) on https://bugzilla-stage-tip.mozilla.org/ (LDAP auth required - if you have an LDAP account and your account doesn't have access to it and you would like to try it out, find me on irc) since Monday or so. Had to back out the GPG patch to get apache to start, out of inability to locate the prerequisites. That problem has since been solved with the perl repo we pull from (or so I'm told) so hopefully I'll have that up later this afternoon.
mkanat: what all have we added new on our own that we didn't already have on our 3.0 install and wasn't included upstream in 3.2? Anything else other than the GPG Email thing?
Yeah, just the GPG code is new. This doesn't even have the httponly or other cookie stuff, because we haven't merged that into the bmo 3.2 branch yet.
OK, we should include those, too. If I can get this all staged with all the patches intact today, we can probably deploy to production on Thursday.
I merged our repository to the tip of the 3.2 branch this morning (primarily in order to pick up the performance fixes for the bugs_fulltext portion of the upgrade process). A trial run on the upgrade with the new code took 2 hours 15 minutes. I'm scheduling the outage window for 4 hours just to be safe. Give us a little leeway in case anything goes wrong. The staging site looks pretty good so far though. One downer: The fix for the Httponly cookies thing requires a newer version of the CGI perl module than what RHEL 5 ships. And it ships as part of the core perl RPM, so rpmforge can't override it without shipping an entire new perl. The GPG prereqs are now in rpmforge. So CGI is going to be the one and only perl module installed from source/cpan. :( Since the cluster-staging box and the web servers are all running RHEL5, using install-modules.pl to install CGI into Bugzilla's lib directory on the cluster-staging box should be safe (it'll propagate to the webheads from there). I just realized, I don't think I re-applied the GPG patch... off to play with that right now.
Assignee: nobody → justdave
Component: Bugzilla: Other b.m.o Issues → Server Operations
GPG email? Does that mean it'll be possible to reply to bugmail by email, somehow? Is that (going to be) documented?
(In reply to comment #9) > GPG email? Does that mean it'll be possible to reply to bugmail by email, > somehow? Is that (going to be) documented? Nope, it means that security bug mail would be sent GPG-encrypted to the sender (only one-way).
Depends on: 190945
> Nope, it means that security bug mail would be sent GPG-encrypted to the sender Oh well. That sounds good too.
I can't contact bzr://dm-bugstage01.mozilla.org/bmo/3.2 . Am I supposed to be able to? In lieu of that, I'm testing the "bugs running around" patch against bzr://bzr.everythingsolved.com/mozilla/3.2. Gerv
No longer depends on: 190945
(In reply to comment #12) > I can't contact bzr://dm-bugstage01.mozilla.org/bmo/3.2 . Am I supposed to be > able to? No, but https://dm-bugstage01.mozilla.org/bmo/3.2 should work fine. bzr knows how to deal with https urls.
Mentioned on the other bug, but just for the benefit of anyone not watching there, the GPG mail sending patch isn't quite ready, yet, and we got a director-level decision to go ahead and upgrade the site without it tonight. It will probably be getting deployed separately in a much-improved state sometime in the next couple weeks.
This is done. We deployed last night. Regressions are being tracked on bug 452731.
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
Dave: bzr co https://dm-bugstage01.mozilla.org/bmo/3.2 bmo crashes Bazaar. bzr: ERROR: pycurl.error: (60, 'server certificate verification failed. CAfile: /etc/ssl/certs/ca-certificates.crt') Traceback (most recent call last): ... I've filed https://bugs.launchpad.net/bzr/+bug/263641 Is there some cert I need? If so, how do I install it in Hardy? Gerv
(In reply to comment #16) > Dave: > bzr co https://dm-bugstage01.mozilla.org/bmo/3.2 bmo > crashes Bazaar. > > bzr: ERROR: pycurl.error: (60, 'server certificate verification failed. CAfile: > /etc/ssl/certs/ca-certificates.crt') > > Traceback (most recent call last): > ... > > I've filed > https://bugs.launchpad.net/bzr/+bug/263641 Not sure that's a crash so much as it is non-user-friendliness of the error it reports. That's indeed a valid error if you don't have Mozilla's root ca certificate installed. > Is there some cert I need? If so, how do I install it in Hardy? Yes. https://wiki.mozilla.org/MozillaRootCertificate As for how to install it where bzr will see it, I'm not sure. I'm sure someone in Ubuntu's support community would have a good answer for that though.
12 years ago
Product: mozilla.org → mozilla.org Graveyard
You need to log in before you can comment on or make changes to this bug.