-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Just a heads-up: thanks to recent development fixes in rsync 3.0.0-cvs,
we can actually update our internal backups of the upload fileserver on
a reasonable schedule.
The incremental recursion mode, new in 3.0, means that the millions of
files can be copied as the directories are scanned, instead of building
a file list first that's so big that rsync uses all memory on the server
and dies before copying anything.
More importantly, a recent fix keeps rsync from segfaulting every few
hours, so it can actually get to the end. ;)
Currently uploads are being replicated from amane, the main fileserver,
to storage2 in the Tampa facility. We're planning to also start copying
them over to some space on the disk array for the toolserver in
Amsterdam, which should allow us to:
a) Have a clean offsite backup
b) Allow handy access to the public files for toolserver users
That's currently waiting on the array to be fully set up.
It might also be feasible to set up a public rsync server to allow
public fetches, but we'll have to see about load and configuration issues.
- -- brion vibber (brion @ wikimedia.org)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFGz0hpwRnhpk1wk44RAqgwAJ45fam1Q63KVHTQRspsMPwGQNgZ6ACg1wfI
/W878M/sRi0FDBZ6zL/qNzI=
=Jptj
-----END PGP SIGNATURE-----
So, the last word I've seen on 1.11.x is that the release would be held
off until after Wikimania:
http://lists.wikimedia.org/pipermail/wikitech-l/2007-July/032449.html
It doesn't seem like a release branch has been made, so I'm wondering
what the status is.
I'm asking because I'd like to help with the release testing by rolling
out the RC versions on a couple of production sites. I've been kind of
conservative with MW releases in the past, and I'd like to make more of
a contribution by getting ahead of the curve.
Thanks,
-Evan
--
Evan Prodromou - evan(a)prodromou.name - http://evan.prodromou.name/
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hello!
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 third release candidate of PHP 5.2.4 was just released and can be
downloaded from http://downloads.php.net/ilia/. A very quick turn
around this time with just 5 additional fixes, one of which is a low
priority security fix, hence the RC. Overall I think we are
definitely ready for the final release and I anticipate the final
sometime next week. In the mean time please try this RC against your
code base and let us know if you discover any problems.
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.
Best Regards,
Ilia Alshanetsky
5.2 Release Master
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (Darwin)
iD8DBQFGzhU8LKekh381/CERAuWSAJ4raN1ZZE616mtJ7J9ezleoKhG8WwCfdQ3r
PdwAPg9yTknKnj3mz9wRzsg=
=vK7k
-----END PGP SIGNATURE-----
You haven't gotten a reply in 10 days, try asking on Wikitech-l (I have
changed the reply-to: for this e-mail).
On 8/13/07, Knsaogboas Houasherouqa <
monasogfaowrhtpiwaepithwapieht(a)gmail.com> wrote:
>
> I have noticed that the data dumps take increasingly longer to complete.
>
> http://download.wikimedia.org/enwiki/20070802/ <- This may not even be
> done
> until the middle of next month, at which point the data contained will be
> significantly outdated.
>
> Are there any ways to distribute the processing of dumps such as these,
> and
> if so, what would be the best approach?
>
> Just thought I'd call it to attention.
>
> Thanks,
> Knsa H.
> _______________________________________________
> WikiEN-l mailing list
> WikiEN-l(a)lists.wikimedia.org
> To unsubscribe from this mailing list, visit:
> http://lists.wikimedia.org/mailman/listinfo/wikien-l
>
--
Casey Brown
Cbrown1023
---
Note: This e-mail address is used for mailing lists. Personal emails sent
to
this address will probably get lost.
On 22/08/07, brion(a)svn.wikimedia.org <brion(a)svn.wikimedia.org> wrote:
> Revert r25037 -- just removes functionality from Special:DoubleRedirects instead of fixing the paging problem
I don't agree that this doesn't solve the paging problem; that's
exactly what it *does* do. The removal of functionality is an
unfortunate side-effect.
The current behaviour caused a large number of individual queries to
be executed when the results were cached. If these reports are cached
because they are too expensive to run live, then running up to 1000
individual variants of such a query is surely unacceptable?
Note that the report branch I did some work in (which is almost
complete; minor bits remaining; could do with some review) solves this
issue - when a report is cached, cached rows can be saved with
additional arbitrary parameters, which we could use in, e.g.
Special:DoubleRedirects to save the other titles.
Rob Church
This is best sent to the Developer's mailing list (Wikitech-l). I have
changed the "reply-to:" for this message to there and also sent them a copy.
:-)
On 8/21/07, Vincent Mandrilly <vmandrilly(a)hotmail.com> wrote:
>
> Hello,
>
> 2 days ago, everything was ok, but from then yesterday or the day before
> yesterday, I started not being able to see the following websites :
>
> www.wiktionary.org
> http://wikimediafoundation.org/
> www.wikipedia.org
> http://meta.wikimedia.org/
>
> (Note : But www.wikimedia.fr/ is accessible)
>
> Note : The access was just fine from both 2 chinse internet providers in
> Guangzhou, China, and all the sudden, I couldn't access them on both at home
> and at work.
>
> - Could you please confirm that it is not the websites that are down ?
> - Is this due to a move of host IP to a IP range restricted by chinese
> internet providers ?
> - Or is this due to a new dark age for wikipedia in China ? For the last 3
> or 4 months, Chinese pages were restricted but not the other langueges
> pages....
>
> Sincerely,
>
> (Tired of this stupid government who blocks just everything without
> reason, and they won't even bother to write "sorry, this website is against
> the law, we restricted access" they just let you believe the page doesnt
> exists.)
>
> And my software to get through the Internet Great Wall is not working for
> now.... :-((
>
> V.
>
> _______________________________________________
> foundation-l mailing list
> foundation-l(a)lists.wikimedia.org
> http://lists.wikimedia.org/mailman/listinfo/foundation-l
>
--
Casey Brown
Cbrown1023
---
Note: This e-mail address is used for mailing lists. Personal emails sent
to
this address will probably get lost.
On 22/08/07, brion(a)svn.wikimedia.org <brion(a)svn.wikimedia.org> wrote:
> Revert r25047 -- produces confusing, useless behavior when going to Special:Upload instead of displaying the useful message that you have to enable uploads.
*nod*
Guessed you might.
Rob Church
On 21/08/07, nickj(a)svn.wikimedia.org <nickj(a)svn.wikimedia.org> wrote:
> + $m = array();
> preg_match( '!\.(css|js)$!u', $this->mTitle->getText(), $m );
Note that $m would have been initialised on the next line, since
preg_match() accepts it as a reference, and PHP will initialise
variables passed by reference.
Rob Church
Hi everybody, I'm a bit at a loss with a "this should work" problems.
I've tried to enable SVG->PNG conversion using batik but I get only
an "Error creating thumbnail:" message.
I've then enabled debugging and found this in the log:
thumbnail failed on myhost: error -1 "" from "C:/jdk141/bin/java.exe
-Djava.awt.headless=true -jar
"D:/Inetpub/wwwroot/MediaWiki/extensions/SVGextension/batik-1.7/batik-rasterizer.jar"
-w 180 -d "D:/Inetpub/wwwroot/MediaWiki/uploads/thumb/f/f8/SymbolWaitVote2.svg/180px-SymbolWaitVote2.svg.png"
"D:/Inetpub/wwwroot/MediaWiki/uploads/f/f8/SymbolWaitVote2.svg" 2>&1"
I've run the command manually on the host machine, from a standard
shell, and the conversion is executed correctly, so much that if I
reload the page that should have
triggered the conversion, the image correctly appears.
I'm not quite sure how to debug this further. Any suggestions?
Manu
For a tool that tries to fill in {{Information}} templates on commons
based on the current, unstructured text, I have it fill in the "Date"
parameter from the EXIF data of the image, if available.
I just thought: How about a new magic word, {{EXIFDATE}}, that would
extract EXIF data from the image? It could be used in {{Information}}
as a default in case no "Date" parameter is provided.
{{EXIFDATE}} would return blank on namespaces other than "Image:", of
course, and for files that have no EXIF data.
There could be {{EXIFTIME}} and {{EXIFTIMEDATE}} as well, but that
would be luxus :-)
Shouldn't be too costly for the parser (on image pages, image data
will be needed anyway).
Anyone opposed? Anyone willing to code? ;-)
Cheers,
Magnus