[Toolserver-l] Schema-only database backups
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, It is now possible to mark a user database to be backed up without its data, i.e. only the schema is dumped (mysqldump -d). To do this, include the string "_transient" in the database name: u_jsmith_transient u_jsmith_my_transient_data_p If you have databases whose data doesn't need to be backed up, it would be very helpful if you could rename them to include _transient in the name, to reduce the load / disk space requirements of the nightly backup job. Unfortunately MySQL doesn't provide a way to rename a database, but you can copy the database to a new name like this: $ mysqladmin create u_jsmith_transient $ mysqldump --opt u_jsmith | mysql u_jsmith_transient The old database should then be dropped. - river. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (SunOS) iEYEARECAAYFAk3OGlQACgkQIXd7fCuc5vKdsQCaAwWY3LJ/H4+JcvB0x7VHTyzS VSMAnjVCQBvlfOVG/2DmLtUz0c9EUe5Y =sB8i -END PGP SIGNATURE- ___ Toolserver-l mailing list (Toolserver-l@lists.wikimedia.org) https://lists.wikimedia.org/mailman/listinfo/toolserver-l Posting guidelines for this list: https://wiki.toolserver.org/view/Mailing_list_etiquette
[Toolserver-l] s1 servers changed
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, Due to high replication lag on thyme (s1) I've switched 'sql-s1' to rosemary. If you have scripts which access user databases on s1 and haven't been updated to use sql-s1-user instead, you will find your databases are missing. The fix is to connect to sql-s1-user instead of sql-s1. Scripts which do not use user databases will not be affected and should not be changed. This change will be reverted once thyme has caught up. - river. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (SunOS) iEYEARECAAYFAk3OC2QACgkQIXd7fCuc5vIz7ACdENxlPUZHXengxHE/ZcYp4hkt g5oAoLTAXH4VJWJVZCla5sAhQ25sniRh =9Jc7 -END PGP SIGNATURE- ___ Toolserver-l mailing list (Toolserver-l@lists.wikimedia.org) https://lists.wikimedia.org/mailman/listinfo/toolserver-l Posting guidelines for this list: https://wiki.toolserver.org/view/Mailing_list_etiquette
Re: [Toolserver-l] fixing problems regarding PHP's multi-byte string processing
On Fri, May 13, 2011 at 11:51 PM, Giftpflanze wrote: >> The behavior of string >> processing seem to have changed in different programs almost >> simultaneously, somewhere around October 2010. > > It may be connected with TS-852 [*] which was resolved on 2010-12-08. TS-852 was a change done later than October 2010. There was a change to php involving setlocale() that could be related, though. ___ Toolserver-l mailing list (Toolserver-l@lists.wikimedia.org) https://lists.wikimedia.org/mailman/listinfo/toolserver-l Posting guidelines for this list: https://wiki.toolserver.org/view/Mailing_list_etiquette
Re: [Toolserver-l] fixing problems regarding PHP's multi-byte string processing
Hi Yusuke M schrieb: > Here is the summary of the problem: Several widely-used string > functions of PHP, including strupper() and ucfirst(), are known to > "corrupt" strings when used under a UTF-8 locale [2], which is the > current setting at the Toolserver. […] > > River suggested [1] to solve it by migrating into multi-byte aware > functions such as mb_strupper [5], but I think it's not an ideal > solution. I'd totally encourage the migration too, but it would take > time for all developers to fix their tools appropriately. That would be the right solution. Just send a mail via toolserver-announce. > I hope we can have a more fundamental, instant solution. > > The synchronization of reports of similar problems [4] suggests that > there was a underlying common reason. The behavior of string > processing seem to have changed in different programs almost > simultaneously, somewhere around October 2010. The underlying reason > might be a side-effect from some changes in the PHP platform on the > Toolserver, but I don't have any clue what it really was. If someone > could point out the original reason, it would be a great help to step > forward to a better solution. It may be connected with TS-852 [*] which was resolved on 2010-12-08. Kind regards Giftpflanze (gifti) [*] https://jira.toolserver.org/browse/TS-852 ___ Toolserver-l mailing list (Toolserver-l@lists.wikimedia.org) https://lists.wikimedia.org/mailman/listinfo/toolserver-l Posting guidelines for this list: https://wiki.toolserver.org/view/Mailing_list_etiquette
[Toolserver-l] fixing problems regarding PHP's multi-byte string processing
Hi Toolserver users and admins, We've seen a problem regarding non-Latin (Unicode) texts in PHP [1], and this is already a long-standing issue. I'd like to wrap up the situation and would like to discuss how to get it better. Here is the summary of the problem: Several widely-used string functions of PHP, including strupper() and ucfirst(), are known to "corrupt" strings when used under a UTF-8 locale [2], which is the current setting at the Toolserver. The problem is that those functions can incorrectly recognize a part of a multi-byte character sequence as a single-byte character. When those parts are converted into upper/lower cases, the resulting string will corrupt. We've seen this problem has been breaking down the functionalities of a number of major tools on the Toolserver including Vvv's sulutils and SoxRed93's edit counter. For example, a Chinese/Japanese string "利用者" (meaning "user") doesn't have a capitalized form. However, when it's passed to a tool which (I assume) uses ucfirst, the first character is converted into a non-existent character [3], and the result doesn't make sense. An incomplete list of the affected tools is available at [4]. See also TS-923 [1] for more details. River suggested [1] to solve it by migrating into multi-byte aware functions such as mb_strupper [5], but I think it's not an ideal solution. I'd totally encourage the migration too, but it would take time for all developers to fix their tools appropriately. I hope we can have a more fundamental, instant solution. The synchronization of reports of similar problems [4] suggests that there was a underlying common reason. The behavior of string processing seem to have changed in different programs almost simultaneously, somewhere around October 2010. The underlying reason might be a side-effect from some changes in the PHP platform on the Toolserver, but I don't have any clue what it really was. If someone could point out the original reason, it would be a great help to step forward to a better solution. Wikimedians and Toolserver users using multi-byte characters (including Arabic, Chinese, Korean and Japanese characters) have been apparently unhappy about this problem for more than half a year. I hope all the tools can (again) work more multilingually. Any comments or suggestions? [1] https://jira.toolserver.org/browse/TS-923 [2] http://www.phpwact.org/php/i18n/utf-8 [3] http://toolserver.org/~vvv/sulutil.php?user=%E5%88%A9%E7%94%A8%E8%80%85 [4] https://jira.toolserver.org/secure/ManageLinks.jspa?id=24486 [5] http://php.net/manual/en/function.mb-strtoupper.php Cheers, Whym -- http://toolserver.org/~whym/ ___ Toolserver-l mailing list (Toolserver-l@lists.wikimedia.org) https://lists.wikimedia.org/mailman/listinfo/toolserver-l Posting guidelines for this list: https://wiki.toolserver.org/view/Mailing_list_etiquette
Re: [Toolserver-l] Quick response if possible / re. teacher, class editing
Ive double checked my logs and there is no mention of this particular user, and shared accounts are NEVER allowed as it violates license issues with regards to attribution. On Fri, May 13, 2011 at 8:41 AM, c h wrote: > Briefly: an English teacher is insisting you / WMF (via emails) have said > it's OK for his class to share an account. We've tried very nicely helping > him make drafts and not share, but he's insistent; indeed now claiming it is > a 'crime against humanity'. It's ongoing; they've created a couple of test > live articles, and been warned by several. > > I've tried my damnedest to help 'em, but...they're about to be blocked, I > think. > > I just want to check - did you indicate anything to him, giving him the OK > to share accounts? > > See > http://en.wikipedia.org/wiki/Wikipedia:Administrators%27_noticeboard/Incidents#Teacher_.2F_class_editing > > Cheers. > > > ___ > Toolserver-l mailing list (Toolserver-l@lists.wikimedia.org) > https://lists.wikimedia.org/mailman/listinfo/toolserver-l > Posting guidelines for this list: > https://wiki.toolserver.org/view/Mailing_list_etiquette > ___ Toolserver-l mailing list (Toolserver-l@lists.wikimedia.org) https://lists.wikimedia.org/mailman/listinfo/toolserver-l Posting guidelines for this list: https://wiki.toolserver.org/view/Mailing_list_etiquette
Re: [Toolserver-l] Toolserver-l Digest, Vol 67, Issue 5
Ignore last message; clearly sent to wrong addy. Sorry. -Chzz ___ Toolserver-l mailing list (Toolserver-l@lists.wikimedia.org) https://lists.wikimedia.org/mailman/listinfo/toolserver-l Posting guidelines for this list: https://wiki.toolserver.org/view/Mailing_list_etiquette
[Toolserver-l] Quick response if possible / re. teacher, class editing
Briefly: an English teacher is insisting you / WMF (via emails) have said it's OK for his class to share an account. We've tried very nicely helping him make drafts and not share, but he's insistent; indeed now claiming it is a 'crime against humanity'. It's ongoing; they've created a couple of test live articles, and been warned by several. I've tried my damnedest to help 'em, but...they're about to be blocked, I think. I just want to check - did you indicate anything to him, giving him the OK to share accounts? See http://en.wikipedia.org/wiki/Wikipedia:Administrators%27_noticeboard/Incidents#Teacher_.2F_class_editing Cheers. ___ Toolserver-l mailing list (Toolserver-l@lists.wikimedia.org) https://lists.wikimedia.org/mailman/listinfo/toolserver-l Posting guidelines for this list: https://wiki.toolserver.org/view/Mailing_list_etiquette
