I see that this topic has been popped up from time to time since 2004,
and that most of the misc servers have been already IPv6 enabled. I
have checked around whether google have any info on that, and found a
few (really few) mail on that, from the original 2004 test to a
comment from 2008 that squid and mediawiki is the problem, apart from
some smaller issues. (As a sidenote, google don't seem to find
anything on site:lists.wikimedia.org about "ipv6", interesting.)
Now, squid fully supports IPv6 as of now (since 3.1), so I guess
that's check. (I didn't try it, though, but others seem to have.)
MediaWiki, well, http://www.mediawiki.org/wiki/IPv6_support didn't
mention any outstanding problem and the linked bug is closed, so as
far as I'm observing (without actually testing it) it looks okay.
The database structure may require some tuning as far as I see. Right?
Apache handle it since eternity, php does I guess.
Are there any further, non v6 compatible components in running a
wikipedia? If not, is there any outstanding proble which would make it
impossible to fire up a test interface on ipv6?
I'd say to use a separate host, like en.ipv6.wikipedia.org, and not to
worry about the cache efficiency because I doubt that the ipv6 level
traffic would really measure up to the ipv4 one. At least it could be
properly measured, and decision should base on facts how to go on.
Maybe there's a test host already on, but I wasn't able to find it, so
I guess nobody else can. ;-)
Is there any further problem in this topic require solutions, or it
just didn't occur to anyone lately?
a couple of days ago the IT manager of an italian company phoned me,
because they cannot open it.wiki website.
They made a lot of checks by themselves and with their provider
(COLT). In the end it seems there's a block on 22.214.171.124
They made a check with the London base and London replies:
"We believe that Wikipedia are blocking from their site the reasoning
behind this is our firewalls are not blocking you and you COLT have
confirm that they can reach there from their equipment and the trace
route from you server show’s that it leaves your site passes through
the firewall goes out onto the COLT network and beyond. If you compare
the trace route that I have done on my computer to the trace route
from your server you will notice that your last hop is the hop before
the web server and that is where your blocked."
Any idea or help?
I'm new here
i want a small help.
in my wiki website poonkavanam.com
i can't make new page from exiting red link
when i click the red link it will go to a non wiki page and display page not
recently i transferred my wiki one domain to another
old domain ponkavanam.com
old one still work in good condition
The 1.15 release of MediaWiki introduced some hardcoded bitwise
operators to the core SQL. They were added to operate on the
log_deleted column in the logging table by, I think, aaron. This is
because the log_deleted column now has multiple states.
Unfortunately, bitwise operators have different syntax in different databases.
log_deleted & 1
I think there are three options to make it compatible:
1. Refactor the database to not use an integer as a bit field. Just
use four different boolean columns, which works well cross-database.
2. Add a function to the Database API for each bit operator.
$sql = $database->bitand('log_deleted', 1);
3. Add a function to the Database API to handle all the operators.
$sql = $database->op('&', 'log_deleted', 1);
$sql = $database->op(Database::BITAND, 'log_deleted', 1);
My preference is for option 1 or 3. Thoughts?
after some internal discussion with the licensing update committee,
I'm proposing the following final site terms to be implemented on all
Wikimedia projects that currently use GFDL as their primary content
license, as well as the relevant multimedia templates:
Please note that these aren't quite yet ready for translation yet
(hence labeled draft). Please provide feedback here or on the talk
page, ideally by Thursday night UTC so we can move the process forward
In terms of implementing these changes, I suggest the following:
1) That the relevant site configuration variables are updated on June 15;
be replaced with a localized version whenever one is created;
3) That the relevant MediaWiki-messages are force-updated on all
projects to the English version above, or any translations already
created by June 15;
4) That the revised MediaWiki-messages are also translated through
translatewiki.net and hence additional translations will be rolled out
through normal i18n upgrades.
Regarding 3) and 4), this may best be achieved by creating new
MediaWiki messages. I would appreciate the advice of our translation
and tech team on this, and of course on the entire proposed process.
(I realize that there's not nearly enough time for any number of
translations, but we have a fixed deadline of beginning the roll-out
of this change by June 15.)
For multimedia, the licensing committee and the Wikimedia Commons
community are still discussing the best update strategy, but it will
probably involve a bot updating the existing templates. We're also
hoping to run a CentralNotice to explain the process to the
communities so that people can help to fix up pages and policies.
Thanks for any help in moving this forward,
Deputy Director, Wikimedia Foundation
Support Free Knowledge: http://wikimediafoundation.org/wiki/Donate
I am a researcher in the GroupLens lab (http://grouplens.org) at the
University of Minnesota. You might recognize previous work in Wikipedia
like "Creating, Destroying, and Restoring Value in Wikipedia"
As part of our continuing work within Wikipedia, my colleagues and I are
conducting an academic (non-commercial) study in which we have developed
a modification that is designed to help users work together more
effectively by changing the interface for reverting other editors.
If you choose to participate in the study, you will be automatically
assigned a Wikipedia gadget that will consist of a subset of the
modifications we have developed. As part of the study, we will be
logging your usage of the tool (ie. when you are reverting other
editors). We will also be available for tech support and bug fixes.
Most likely there will be a survey at the completion and the complete
tool will be made available.
Consent form/installer: http://wikipedia.grouplens.org/NICE/consent/
University of Minnesota
You are receiving this email because your project has been selected to
take part in a new effort by the PHP QA Team to make sure that your
project still works with PHP versions to-be-released. With this we
hope to make sure that you are either aware of things that might
break, or to make sure we don't introduce any strange regressions.
With this effort we hope to build a better relationship between the
PHP Team and the major projects.
If you do not want to receive these heads-up emails, please reply to
me personally and I will remove you from the list; but, we hope that
you want to actively help us making PHP a better and more stable tool.
The second and final release candidate of PHP 5.2.10 was just released
and can be downloaded from http://downloads.php.net/ilia/. Please try
this release candidate against your code and let us know if any
regressions should you find any. The goal is to have 5.2.9 out within
one week's time, so timely testing would be extremely helpful. Windows
binaries are also available and can be found here: http://windows.php.net/qa/
In case you think that other projects should also receive this kinds
of emails, please let me know privately, and I will add them to the
list of projects to contact.
5.2 Release Master