Checking whether email replies still work.

Database upgrade is now done as well.

As a follow-up to this issue still, I'll update postgres to 8.3 shortly (so far, only 8.1 is running, which is still from etch).

Thanks! I only looked at this now. Marking this issue as resolved, then. In case further problems are detected that require your attention, I'll create new issues.

Hi again,

Izak Burger wrote:
> I'm sorry, I missed the UTC bit in the original post. Can we start at 12 
> UTC (which is pretty much NOW) or within the hour, or postpone?

We decided to go ahead and start a little earlier. The upgrade is done 
and all seems well. The whole upgrade apparently took 10 minutes or so.

regards,
Izak

I'm sorry, I missed the UTC bit in the original post. Can we start at 12 
UTC (which is pretty much NOW) or within the hour, or postpone?

regards,
Izak

I have now announced the outage.

Martin v. Löwis wrote:
> Next suggestion: Monday (15.2.), 14:00 UTC. Ok?

I'm sorry for replying this late. Yes, the suggested time is perfect.

We also need to update the host on which this virtual machine runs, but 
we'll let you know when we do that.

regards,
Izak

Next suggestion: Monday (15.2.), 14:00 UTC. Ok?

Izak Burger wrote:
>> How about this Friday, 14:00 UTC? (I'm in GMT+1 myself as well) I could
>> be around on IRC, say #tracker-discuss on freenode. I'd post an
>> announcement to python-dev and python.org tomorrow.
> 
> I'll tell our sysadmin. I don't think there'd be a problem.

Our sysadmin is unfortunately unavailable on Friday. Also, he requests 
that we do this on another day if possible, as upgrades done on a Friday 
afternoon tends to awaken Murphy and ruin your weekend.

Martin v. Löwis wrote:
>> My only concern in these cases are things that you compiled 
>> yourself, for example you compiled your own version of python2.4.
> 
> Are you sure about this? Where is this copy located, and where does it
> get used? I'd prefer to switch to Debian Python before the upgrade.

Sorry, I meant that to be an example, something that often happens to us 
on newer debian/ubuntu machines where python2.4 is no longer fully 
supported and many packages do not provide 2.4 components anymore. I 
didn't mean to imply you did such a thing, just that this is the only 
thing I am normally concerned about. If you're using the system python, 
great, just be advised that the default python has changed from 2.4 to 
2.5 as far as I know.

> How about this Friday, 14:00 UTC? (I'm in GMT+1 myself as well) I could
> be around on IRC, say #tracker-discuss on freenode. I'd post an
> announcement to python-dev and python.org tomorrow.

I'll tell our sysadmin. I don't think there'd be a problem.

> My only concern in these cases are things that you compiled 
> yourself, for example you compiled your own version of python2.4.

Are you sure about this? Where is this copy located, and where does it
get used? I'd prefer to switch to Debian Python before the upgrade.

> Can we schedule a time for the real thing, a time when someone with 
> knowledge about the tracker can be on standby, preferably between 8 and 
> 2 UTC?

How about this Friday, 14:00 UTC? (I'm in GMT+1 myself as well) I could
be around on IRC, say #tracker-discuss on freenode. I'd post an
announcement to python-dev and python.org tomorrow.

Martin v. Löwis wrote:
> If that's how you would prefer to do it, it's fine with me. I would be
> skeptical that everything can be tested, though, e.g. testing the email
> setup might be tricky.
> 
> OTOH, on systems that I have to manage, I just accepted to the downtime
> and the potential aftermath that it caused, so skipping the test upgrade
> would be fine with with me as well.

We tested and it seems to upgrade cleanly and things work fine 
afterwards. My only concern in these cases are things that you compiled 
yourself, for example you compiled your own version of python2.4. This 
will be linked with the old library versions, which may or may not work 
afterwards. Our sysadmin says everything started up fine though, so I 
agree that these can be handled as they are discovered.

The test upgrade took about half an hour.

Can we schedule a time for the real thing, a time when someone with 
knowledge about the tracker can be on standby, preferably between 8 and 
2 UTC?

regards,
Izak

> Let me know what you think.

If that's how you would prefer to do it, it's fine with me. I would be
skeptical that everything can be tested, though, e.g. testing the email
setup might be tricky.

OTOH, on systems that I have to manage, I just accepted to the downtime
and the potential aftermath that it caused, so skipping the test upgrade
would be fine with with me as well.

Hi all,

> Is that something that Upfronthosting will do, or shall we do that?

Yes, this sudden dropping of etch also caught us unawares. Its supposed 
to be as easy as running "apt-get dist-upgrade", but because there is 
sometimes breakage involved when dist-upgrading we plan to do this as 
follows: First we (upfront) will make a copy of the virtual server, and 
dist-upgrade that, making notes of anything that needs adjustment. We 
(upfront and psf) can then test that to make sure everything works. 
Finally we can schedule some downtime and do the dist-upgrade for real.

Let me know what you think.

regards,
Izak

Security Support for Debian GNU/Linux 4.0 will be terminated on February 15th, according to www.debian.org. It would be good if we could upgrade the psf machine to lenny before that.

Is that something that Upfronthosting will do, or shall we do that?