[00:21:46] Betacommand you around? [00:22:08] I would like to request a query for deleted files on commons, would you have time for that? [00:25:13] ToAruShiroiNeko: depends on what you need [00:26:51] Mind if I pm? I dont want to self advertise [00:27:18] I just need a breakdown of deleted files on commons [00:30:49] ToAruShiroiNeko: sure [01:07:42] Hello [01:07:55] Coren, are you around? [01:08:20] Hazard-SJ: Semi-kinda. What's up? [01:08:48] Coren: I few days ago I was having a problem on Tool Labs [01:09:53] I'm going to go out on a limb here and guess there is more to this story? :-) [01:10:43] I have a script ... if I run it directly, it works properly, but if I submit it via SGE it gives an error ... basically it can't find a file (dump file in the /public/datasets/public/ folder) [01:10:55] Yes Coren :) [01:11:46] The very last of these dump files I attempted using is /public/datasets/public/commonswiki/20140123/commonswiki-20140123-pages-articles.xml.bz2 [01:12:04] The problem is that /public/datasets is kinda hosed atm, and fixing it would require restarting autofs on all nodes -- which can only be done with a reboot. [01:12:48] And I guess that can't be done anytime soon? :( [01:14:32] Wait, that part of /public/dataset should be okay on every node actually. [01:14:49] And I see the file. [01:14:57] :/ [01:15:07] o_O [01:15:16] what command are you submitting with, exactly? [01:16:07] Coren: jsub -once -continuous -mem 2G -N c-i18n ~/pwb/bin/python tools/commonswiki/internationalization.py [01:16:39] even without "-continuous" it failed [01:17:15] I honestly don't know how you'd get the error on that file. [01:17:28] Can you pastebin the message(s)? [01:18:47] Coren: http://pastebin.com/0gLDL43m [01:19:18] o_O [01:19:32] As I said, it works perfectly well when I run it without SGE [01:19:41] Only thing I can think of is that you were unlucky and hit the server exactly when it was down for a few hours earlier this week. [01:19:55] :/ [01:19:58] Because, right now, there's no way this can fail with that error. [01:20:10] Coren: I'll try again right now then :/ [01:23:44] Since I submitted nearly 3 minutes ago I haven't gotten any output as yet :/ [01:23:57] and yet qstat says it's running [01:25:43] Coren: I guess you were right :/ it seems to be working properly now [01:25:56] Thanks [01:26:34] * Hazard-SJ checks the later dump to see if the file he uses is there as yet [01:26:42] any ops around to give Jamesofur a temp ban until he fixes his connection? [01:27:23] Betacommand: Who knows, it might actually be fixed now [01:29:13] It's there :) [02:13:35] Does anyone know why I'm getting a 500 for all my pages? I did a refresh from my code repository... something to do with permissions [02:13:36] I've had this happen before but I can't remember why. [02:23:33] somebody, anybody? [02:28:03] hum [02:28:29] in your home dir you have the logs, access.log and error.log [02:31:54] oh goodness, this is weird [02:31:56] sometimes when I hit the reload button, it works; others, no. [02:31:56] gry, >_> [02:35:26] oh this might do it: [23-Feb-2014 02:34:14 UTC] PHP Fatal error: Out of memory (allocated 786432) (tried to allocate 9 bytes) in /data/project/magog/public_html/oldver.php on line 416 [02:39:14] well that's only one of the servers [02:39:14] omg my head is going to burst [02:39:14] we're dealing with two issues here: [02:39:14] one of the servers is out of memory [02:39:15] one of the servers it allowing my request through [02:39:15] and the rest aren't throwing a 500 [02:57:41] Magog_the_Ogre: use the new web [02:57:56] betacommand, I don't know what that means [02:58:25] open up an ssh shell and login, become your tool and try: [02:58:31] webservice start [02:58:48] !newweb | Magog_the_Ogre [02:58:48] Magog_the_Ogre: https://wikitech.wikimedia.org/wiki/Nova_Resource:Tools/Help/NewWeb [02:59:52] Magog_the_Ogre: coren decided that apache users dont matter and is in the process of moving everyone to lighthttpd [03:00:10] oh that did it [03:00:15] however at this point its still opt in [03:00:21] what in the world just happened? [03:00:35] Magog_the_Ogre: you stopped using the shared webserver [03:01:37] Magog_the_Ogre: you will need to manually restart the webservice if something causes an issue (IE NFS decides to die again) [03:02:08] so apparently replacing all of my files and goofing with their permissions apparently jacks up the server and causes it to crash [03:02:12] and I just have to start the service again [03:02:18] No [03:02:49] before you did webservice start, you where using the shared apache server [03:03:08] which is unmaintained, and needs a lot of help [03:03:44] when you preformed the webservice start , you started a new lighthttpd server just for your tool [03:04:38] OK [03:04:54] something about replacing the files definitely goofed up the shared apache server [03:05:29] No, the apache just is not able to handle the workload its given [03:06:43] Ahh [03:07:10] I guess the rapid reload clicks when I was trying to fix it probably didn't do much to help the situation :D [03:07:13] Magog_the_Ogre: there should be at least 4 of them given the number of users and tools [03:07:27] however there are 2 [03:07:41] and they are under powered units [03:10:23] Hello, I am a user in tools project. I want to use pywikibot in web services (cgi). However, it got stuck because the framework requires git, which is not available on the web server. What should I do? [03:11:14] nullzero: the framework does not require git [03:11:31] Actually, there is git in /usr/bin, but apparently /usr/bin is not in $PATH, so git is not recognized. [03:11:44] nullzero: the framework does not require git [03:11:52] You should never rely on $PATH for anything that can be invoked by endusers anyways. [03:12:42] coren can you take a look at https://bugzilla.wikimedia.org/show_bug.cgi?id=61813 [03:15:49] Betacommand: I have, but you'll not like my answer. :-/ [03:16:03] Coren: what? [03:16:25] the only thing that may have private info is the comment field [03:16:41] Betacommand: it does require git. I got an error in function getversion_git() in version.py [03:17:11] nullzero: it should show a warning but not cause a fatal error [03:18:13] Betacommand: the criterion isn't "not private", the criterion is "available to non-admins". "private" just causes legal to say no automatically. :-) [03:18:36] Coren: we already have the archive table available [03:19:35] Betacommand: Right; that was cleared by legal. [03:19:57] Betacommand: (With more stringent redaction than others) [03:20:03] Betacommand: Please see http://pastebin.com/JhaN23Hz [03:20:30] nullzero: I know the code [03:20:42] nullzero: Ive been using pywiki for about 8 years [03:20:47] FWIW, I don't think there would be an issue with filearchive once suitably redacted and I don't expect Legal to fuss over it. [03:22:36] Coren: is ar_parent_id redacted? [03:23:01] Betacommand: I don't remember offhand. Lemme check. [03:23:43] Betacommand: Nope. [03:24:04] Coren: K I just saw results with NULL results [03:24:36] Betacommand: They're null in the source then; the only field explicitly redacted (beyond oversight/suppression) is ar_comment. [03:25:02] Coren: what is the correct way to upgrade an instance with old MediaWiki and other old things? [03:25:46] huh: Depends on how you set mediawiki up in the first place. [03:26:23] Puppet [03:27:29] huh: if you're using a package { } stanza, you can probably just ensure => latest rather than ensure => present. [03:31:21] Betacommand: Anyway, it is not labs' fault, so I filed the bug on https://bugzilla.wikimedia.org/show_bug.cgi?id=61816 in pywikibot. [03:49:30] huh, Coren, if you installed using mediawiki puppet classes then you have a git checkout of mediawiki. So a fetch and rebase would work fine. [03:49:43] I think that you can make puppet do that automatically, but I haven't tested it recently... [03:49:46] * andrewbogott looks for syntax [03:50:10] andrewbogott: I wouldn't know. I don't remember having installed a mediawiki install with puppet. Like, ever. :-) [03:50:12] andrewbogott: you helped me install it... [03:50:15] IIRC [03:50:27] maybe someone else here [03:50:53] huh, there are two different classes that could work. Either role::mediawiki-install-latest::labs or role::mediawiki-install::labs. If you're using the former then it is probably already updated. [03:51:06] But, in any case, you can just log in and do a fetch/rebase. Do you know how to do that? [03:51:16] just git fetch ? [03:51:53] well, it depends on if you want to upgrade to the current head, or to a particular release point. [03:52:07] Whatever is used for development [03:52:11] I guess 1.23 [03:52:16] Do you have any local changes? [03:52:46] only to orig/LocalSettings.php [03:52:58] no worries then. [03:53:10] I'd advise you to backup what you have now, first... [03:53:35] Nothing important really [03:53:57] fatal: pack has 418 unresolved deltas [03:54:01] ok, well, just in case, let's do a quick backup of your current install just in case we break everything. [03:54:18] oh, you're already fetching :) [03:54:29] I think 'git fetch origin' should do it, if you're root. [03:55:23] I'm not really worried about losing edits [03:55:31] http://abusefilter-global-main.instance-proxy.wmflabs.org/wiki/Special:Contributions/Admin ... [03:56:02] huh, edits aren't in danger, they're stored elsewhere. [03:57:05] andrewbogott: http://tools.wmflabs.org/paste/view/a5ea23b6 [03:58:01] sudo is not sufficient? [03:58:24] I don't know what that is :( [03:58:28] mind if I log in and poke about? [03:58:43] No, not at all [03:58:57] (no = I don't mind) [03:59:26] Honestly I was just going to test a patch before I submit to gerrit [03:59:41] it was not even for abusefilter, but I already have that project, so... [04:00:50] well, now I'm curious :) [04:05:38] so, huh, my guess is that this is a remnant of an older way that the puppet mediawiki class worked... [04:05:53] for a while it checked out a shallow tree in order to save time. That sometimes left you with a tree that worked but couldn't properly sync with upstream. [04:05:59] So, if you care, we can move your current tree aside and let puppet check out a fresh one... [04:06:05] then you'll have to replace your local change(s) [04:06:12] want me to try that? [04:07:48] Fine [04:09:09] andrewbogott: I was trying to install CentralAuth, although I only need one wiki [04:09:22] I was just trying to test a patch [04:09:32] lemme see if this is easy... [04:15:46] andrewbogott: is it? [04:16:20] I think so, give me another couple minutes... [04:16:34] Yeah, no rush [04:16:45] Thanks for helping :-) [04:23:16] huh: ok, you'll need to reinstall the centralauth extension, but... [04:23:16] otherwise are things looking ok? [04:23:26] Okay [04:43:54] andrewbogott: ...? [04:44:06] Can I install CA like usual? [04:44:41] http://abusefilter-global-main.instance-proxy.wmflabs.org/wiki/ gives an error [04:44:54] ( = http://abusefilter-global-main.instance-proxy.wmflabs.org/w/index.php ) [04:56:10] huh, does it look like things are working as you'd expect? [04:56:51] andrewbogott: http://abusefilter-global-main.instance-proxy.wmflabs.org/ does not show the Main Page, so no [05:12:34] oh. [05:12:43] dat doesnt look good [08:04:22] hola a todos [12:27:43] Is there a known problem with crontab jobs? My scheduled Faebot jobs have not been running since 9th Feb but I'm unclear as to why. [12:28:08] I think I'm complying with https://wikitech.wikimedia.org/wiki/Nova_Resource:Tools/Rules [13:51:01] Fae: what are your cronjobs doing? where are they running? [13:52:32] I'm running faebot's cronjobs under local-faebot@tools-login - happy to run in a different way if I've misunderstood how these are supposed to work. [13:52:49] but what is the cronjob doing? :) what does it run? [13:54:23] They are odd jobs, one refreshes the userlist at http://commons.wikimedia.org/wiki/User:F%C3%A6/Userlist, another maintains a table for a literary project on the Welsh Wikipedia [13:54:49] I was having them log at http://tools.wmflabs.org/faebot/logs [13:54:52] are you submitting the tasks to the grid or running them locally? [13:56:35] Fae: check the crontab with crontab -e and see if they are disabled (# in front of a line). In that case, it was probably disalbed by an admin [13:56:50] They are on the labs server, they should be on the grid but I'm not sure I understand the difference. [13:56:55] They are not disabled. [13:59:49] As an example ... [13:59:52] 15 2/12 * * * python ~/pywikibot-compat/reportWBS.py >/dev/null 2>&1 >> ~/public_html/logs/reportWBS.log [14:00:28] Fae: se https://wikitech.wikimedia.org/wiki/Nova_Resource:Tools/Help#Submitting.2C_managing_and_scheduling_jobs_on_the_grid [14:00:31] *see [14:00:43] Okay, I'll re-read it. [14:00:49] you should be submitting jobs to the grid in the cron rather than running them on tools-login [14:03:18] hm, like in crontab they appear similar to "