-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi,
On the morning (UTC) of December 6th we will perform general maintenance[0] on
all servers. Services will be affected as follows:
Service | Expected impact
-----------------------------+-------------------------------------
Entire platform | As described in maintenance schedule[0]
JIRA, MediaWiki, FishEye | Under 30 minutes outage for each service
| during upgrade
Start time: Monday, 6th December, 12AM UTC
End time: Monday, 6th December, 8AM UTC (estimated)
Details:
This is a schedule general maintenance, which we use for various non-critical
tasks. The expected outages are as described in the maintenance schedule[0].
Most of the changes for this maintenance are in the local TS software, /opt/ts;
all software will be upgraded to the latest version, and some minor changes
will be made. The full list of upgrades, including Perl modules, is available
here:
<https://wiki.toolserver.org/view/Admin:Pending_maintenance_tasks>
The following changes will also be made:
* Mono will now install directly in /opt/ts instead of /opt/ts/mono/2.0. If
you call "mono" without an absolute path, this will not affect you. If you
currently call "/opt/ts/mono/2.0/bin/mono", you should change this to remove
the full path before the maintenance.
* The preferred OpenSSL is now /opt/ts/bin/{amd64,}/openssl, which is OpenSSL
1.0.0b instead of /usr/sfw/bin/{amd64,}/openssl (0.9.7d). This should not
affect users, but if you currently call the version in /usr/sfw with a full
path, you may wish to remove the path so you automatically use our version,
which is better.
We will additionally make some changes to how the software is compiled; if you
have compiled your own C or C++ programs, this will affect you, and you should
read the section "Changes to ts-specs environment" below. If you do not have
any locally-compiled software, this change will not affect you.
During the maintenance, some software may not work correctly (e.g. programs or
libraries not found).
--
JIRA, FishEye, MediaWiki and phpMyAdmin will also be upgraded.
--
The default Python version will change from 2.6 to 2.7. If you currently use
/usr/bin/python, this change will happen for you automatically. If you use
/usr/bin/python2.6 explicitly, you will need to change to /usr/bin/python2.7 to
use the new Python.
If you have programs which don't work under Python 2.7, you should a) report
this in JIRA, and b) switch to /usr/bin/python2.6 before the maintenance. If
there are no problems with Python 2.7, we will remove Python 2.6 from the
system during the next maintenance (January 2011).
We will patch Python 2.7 to revert the fix for bug 1054943[1], which introduced
a regression affecting Unicode normalisation[2][3].
--
The default "gcc" will become GCC 4.5.1, rather than 3.4.3. This may affect
you if you build locally-installed Perl modules, especially if these modules
use C++ code. This is described in more detail below.
--
Changes to ts-specs environment
===============================
This section only applies to users with locally-compiled C or C++ software.
The new version of ts-specs (/opt/ts) installed during the maintenance has
switched the default compiler from Sun Studio to GCC 4.5.1. This is described
in more detail at [4]. In brief:
* You should change from your current compiler (Studio, GCC 3.4.3 or GCC 4.4)
to GCC 4.5.1, /opt/ts/bin/gcc.
* If you recompile any Studio- or GCC 3.4.3-compiled C++ code with the new
compiler, you need to recompile all of it, because the ABIs are not
compatible.
* GCC 3.4.3 will no longer be installed.
* If you use Studio-compiled versions of C++ libraries in
/opt/ts/<lib>/<version>/, you should change to the GCC version in
/opt/ts/<lib>/<version>-gcc/.
The following libraries require special handling:
* Studio-compiled versions of MySQL++ and VIPS were previously installed in
/opt/ts/lib. If you use these libraries, you should switch to the version
that we will install in /opt/ts/<lib> (where <lib> is "mysqlpp" or "vips").
The Studio-compiled version will remain available for now.
* Studio-compiled versions of ImageMagick, sigc++ and cairomm are currently
installed in /opt/ts. They will be replaced with GCC-compiled versions
in the same path, and Studio-compiled versions will not be available.
If this adversely affects you (because you use these libraries and need time
to migrate), you should let us know before the maintenance.
[0] https://wiki.toolserver.org/view/Maintenance_schedule
[1] http://bugs.python.org/issue1054943
[2] http://bugs.python.org/issue10254
[3] http://lists.wikimedia.org/pipermail/toolserver-l/2010-November/003633.html
[4] http://lists.wikimedia.org/pipermail/toolserver-announce/2010-November/0003…
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (FreeBSD)
iEYEARECAAYFAkzz1HIACgkQIXd7fCuc5vIcAQCfffiUXeXvhgCdFT6wHtEFWc1X
MZ4An1yUKY6ZFzeGhxcPFgXhA7DUDH7j
=RfuR
-----END PGP SIGNATURE-----
Hello all,
> with the beginning of the next year (2011) I will not longer accept new
> interwiki-bot-accounts, if:
> [...]
While we're at it - in the future, we shall have interwiki bots reading the
replicated data bases to a great extent while gathering informations about
existing and prseumably missing interwiki links. This will be sparing lots of
request to the wmf servers which will then be bothered only when wiki pages
are actually altered.
Using the replicated data instead of making http (api) requests should speed
up the data collection phase of large inteerwiki groups from several minutes
to a seconds or so.
Another approach of making interwiki bots use the replicated data would
be to pre-process their interwiki data into a list or table of versioned
change requests, being published on the toolserver.
Interwiki worker bots running elsewhere would pick requests from the list &
process them. Picked requests are postponed for a while until replicated
data renders them done, or until a timeout (>replication lag) is exhausted.
Greetings - Purodha
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi,
The s2/s5 server is currently experiencing some hardware issues. As we
currently only have a single server for s2/s5, this may result in outages for
these clusters.
We have raised an SR with Sun to replace the faulty hardware.
- river.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (FreeBSD)
iEYEARECAAYFAkz3JdYACgkQIXd7fCuc5vKmTQCgugY4R+z/yoXTqZW3lR298QGJ
fgYAoL07GM2/1shgFj6+Av9b4KZBcvmX
=3kiC
-----END PGP SIGNATURE-----
River Tarnell wrote:
> Since no major issues have been raised regarding the conversion of
> > nightshade to Solaris, this has been schedule for the maintenance
> window on January 3rd, 2011. For more information, see
I have reported *) a few incompatibilities in very basic tools and bash
that I have not the faintest idea of how to get around them under Solaris.
Yes, these may be bugs in the Solaris tools or O/S, and some of my scripts
will not run without them fixed. My only option atm is moving them elsewhere
outside the toolserver cluster, when there will be no Linux host left.
I shall re-evaluate the scripts under Solaris during the next days, just in case, something has been altered meanwhile, and report remaining issues
more detailed.
*) Wanting to link to my earlier e-mail in the list archive, I could not
find it :-( Here is a copy:
On Thursday, 16. September 2010 04:02:35 Purodha wrote:
> > ... we have
> > decided to standardise on Solaris for the login and web servers. We will
> > therefore be converting nightshade from Linux to Solaris at some point in
> > the future.
> >
> > There is no fixed time frame for this at moment, but it won't happen
> > sooner than a month from now, and we won't do anything until we are
> > satisfied that all tools (and users) are ready for the migration.
> >
> >To start with, we want to identify and fix any issues which prevent users
> > from moving their tools to Solaris. This will mainly include:
> >
> > * Software which needs to be installed or updated
> > * Behaviour differences between Linux and Solaris where the Linux
> > behaviour is more correct or preferable.
>
> I have several shell scripts (using bash, awk, sed, grep, cut, php,
> pywikipedia) that run with Linux only.
>
> I have tried to make them work on Solaris, too, while we had an idle
> machine, but it was impossible. I cannot quite remember what the
> precise causes were, but there were several incompatibiliities
> prohibiting one staight script for both systems without branching inside
> the script as per system, and at least one issue that prohibited a solaris
> version entirely - something in the realm of awk features, regexp's or
> shell escapes.
>
> Unfortunately, it will take time before I shall have the problems spotted
> again. I might need help, then.
> Since I had been unable to fix them in the first ~135 tries I expect to
> fail on the ~136-th one as well.
>
>
> Unrelated,more general question:
>
> Why would we give up the flexibility of having a choice of operating
> systems to log in to?
>
> Geetings - Purodha
Greetings - Purodha